Модель подозрительной активности PowerShell создает аномалии на основе подозрительной активности, идентифицированной в журналах событий безопасности Microsoft PowerShell и Windows.
Чтобы модель активности PowerShell работала, необходимо вести журнал активности PowerShell на определенном уровне и добавить эти журналы в Splunk UBA.
Совместимые версии PowerShell с Splunk UBA
Модель PowerShell работает лучше всего с PowerShell 5.0 или последней версией PowerShell 4.0.
| Версия PowerShell | Требования PowerShell |
|---|---|
| 4.0 | Необходимо обновить Windows 7 и 2008 R2 до Windows Management Framework (WMF) 4.0 перед установкой WMF 5.0. |
| 5.0 | Windows 10 не требует обновлений программного обеспечения для поддержки расширенного журналирования PowerShell. |
События PowerShell записываются в журнал операций PowerShell Microsoft-Windows-PowerShell%4Operational.evtx.
Настройка журналирования модуля для PowerShell
Выполните следующие шаги, чтобы включить журналирование модуля:
- Включите мониторинг командной строки. Инструкции можно найти в документации Microsoft.
Настройка журналирования транскрипции
Настройки конфигурации хранятся в HKLM:SoftwarePoliciesMicrosoftWindowsPowerShellTranscription.
Проверка журналирования PowerShell
- Код события = 4103
- Код события = 4104
Если это был реальный сервер или машина, с которых вы экспортировали журналы, вам нужно переместить файлы evtx в chainsawLogs. Обычно я помещаю свои файлы .evtx в эту папку по отдельности, затем сканирую и смотрю, что получается, чтобы избежать путаницы.
В этом примере я собираюсь использовать три различных примера каждый из разных категорий, так что вы можете понять суть LogsPersistence, Execution, и т. Д.
Сначала мы начнем с команды Охота, они наиболее полезные, так как они проверяют все правила sigma и отображения:
./chainsaw hunt -r rules/ .LogsCredential_Access -s sigma/rules — mapping mappings/sigma-event-logs-all.ymlЗдесь мы видим, что злоумышленник намеренно удалил журнал событий с идентификатором события 1102, это используется для скрытия следов деятельности.
Предположим, вы хотите найти конкретный идентификатор события, вместо правил вы можете вызвать команду типа Поиск. Это отлично подходит, если у вас есть ключевое слово, которое вы хотите найти в журналах. Мы ищем идентификатор события 4662: Операция была выполнена над объектом, так как мы подозреваем, что произошли изменения разрешений, а также ищем процесс lsass.exe:
Идентификатор события найден!
Процессы lsass.exe доступны для просмотра.
Последний пример будет под категорией Execution. Это относится к выполнению полезной нагрузки:
./chainsaw hunt -r rules/ .LogsExecution -s sigma/rules — mapping mappings/sigma-event-logs-all.yml
Мы остановимся здесь на этом, так как, на мой взгляд, это дает вам общее представление о возможностях этого инструмента и разнообразии механизмов поиска, которые он использует. Имейте в виду, что это лишь краткое введение в то, что содержится в Chainsaw. Надеюсь, этот обзор поможет вам в ваших усилиях
Прошлый раз я показал, как использовать инструмент командной строки EVENTCREATE.EXE, чтобы создать собственные пользовательские записи в журнале событий. Сегодня я хочу продемонстрировать, как выполнить эту задачу с помощью Windows PowerShell. Здесь мы будем использовать командлет Write-EventLog. Первым шагом должно быть ознакомление с помощью команды.
При использовании этого командлета вам необходимо указать имя журнала, источник, идентификатор события и сообщение. В этом отношении он очень похож на EVENTCREATE.EXE. Но вы не можете использовать нестандартный источник или что-то импровизированное. Вы должны использовать предопределенный или существующий источник. Простой способ найти имена источников – использовать Windows Management Instrumentation (WMI).
Если один из этих источников кажется подходящим, тогда вы можете внести свою собственную запись следующим образом.
Тип записи по умолчанию – информация. Я создал свой собственный идентификатор события, который имеет свои недостатки.
Предположу, что если вы хотите иметь возможность выполнить поиск по идентификатору события или сообщению, вы можете мириться с незначительной ошибкой в сообщении.
Не идеально, но функционально. Хотя в теории можно зарегистрировать новые источники, если вы собираетесь пойти на такие длины, вам лучше создать новый журнал событий, используя командлет New-Eventlog. Обычно этот командлет предназначен для разработчиков приложений, создающих формальный журнал событий. Но IT-специалисты могут также использовать это. Я собираюсь создать пользовательский журнал и определить несколько источников также.
Что я только что создал?
Совершенно новый журнал. Давайте проверим мои источники.
Наконец, давайте что-то напишем по этому журналу.
Вы можете использовать любой идентификатор события на ваш выбор, но вам, вероятно, захочется определить их заранее.
Windows теперь не обращает внимания на идентификатор события. Если мне нужно добавить еще один источник, мне нужно всего лишь повторно выполнить командлет New-Eventlog:же.
Заключение
Командлет New-Eventlog имеет параметр -computername, поэтому очень легко определить новый журнал событий на всех серверах или рабочих станциях, где вам нужно сделать собственное пользовательское журналирование. Вы внедрили пользовательское журналирование? Если да, я бы хотел услышать об этом.
Скрипт Powershell для экспорта всех событий журналов Windows в zip-файл, а затем отправки на удаленный smb-сервер
Журналы для извлечения с сервера
Берет имя сервера, чтобы добавить его к извлечению файла в журнале
Укажите путь с окончанием для хранения извлечения файла журналов.
Проверяет последний символ пути назначения. Если он не заканчивается на , добавляет.
.+?\\$ +? означает любой символ, \ ищет обратный слеш $ – символ конца строки
Если путь назначения не существует, он будет создан
(( Путь ))
ТипЭлемента каталог Путь
Получите текущую дату в формате ГодМесяцДень
Запуск таймера процесса
При использовании Clear и backup
Сейчас происходит извлечение файла.
Извлеките каждый файл журнала, перечисленный в $logArray с локального сервера.
Write-Host Очистка $log файла сейчас.
Очистите журнал и создайте резервную копию в файле.
WevtUtil cl $log
Архивация папки
Пункт назначения пути
Сила рекурсивной силы
Скрипт выполнялся за считанные секунды.
Теперь, когда мы знаем, с каких журналов логов хорошо начать, пришло время сосредоточиться на конкретных идентификаторах событий (EID), которые будут критически важны для нашего исследования. Столкнувшись с этой проблемой, я понял, что значительное количество EID и необходимость выбора значимых не являются единственным вызовом, но также нормализация данных. И когда возникают проблемы масштабируемости, нормализации и уменьшения времени исследования, это свидетельствует о том, что настало время для автоматизации. Таким образом, мне пришла идея создать инструмент для быстрой начальной триажи событий журналов Windows – https://github.com/yarox24/EvtxHussar.
Вы можете проверить проект на github, чтобы посмотреть, как это работает. Если вы ищете только те EID, которые являются коронными драгоценностями, загляните сюда https://github.com/yarox24/EvtxHussar/tree/main/maps.
Инструмент написан на GoLang. Чтобы упростить импорт новых идентификаторов событий (EID), все EID сохранены как внешние файлы в формате YAML. Он поддерживает все файлы журналов из таблицы выше и содержит список важных EID. Минимальный набор EID, необходимый для начальной триажи, доступен здесь https://github.com/yarox24/EvtxHussar/tree/main/maps
В качестве ввода принимается путь к папке с несколькими файлами .evtx с различных компьютеров. Вывод будет разделен по именам компьютеров, присутствующим в файлах журналов. Если у вас есть логи из резервной копии или VSS, вы также должны предоставить их, так как события будут дедублицированы.
Результат сохраняется в различных категориях событий (входы в систему, PowerShell и т. д.) внутри одной директории с тем же именем компьютера.
Пример структуры каталогов для одного компьютера с именем хоста: DESKTOP-SecurityDive (с выходным форматом Excel):
Нормализация
Следующее испытание – нормализация. Действительно, это самая большая проблема, когда речь идет о парсинге логов. Цель, которую я поставил перед EvtxHusar, – минимизировать количество ненужных полей, особенно дубликатов, таких как Application, ApplicationName, ApplicationPath или ID, RuleID или ProcessName, Process. Для решения этой проблемы я реализовал простое сопоставление с параметром YAML: fields_remap.
fields_remap в FirewallUniversal.yamlТекстовая версия выступления на PHD12
Пару слов о проблеме
При реагировании на инциденты иногда необходимо просматривать журналы Windows машины, и аналитики создают утилиты для удобной фильтрации событий в журналах evtx. Это связано с тем, что способы фильтрации, предложенные Microsoft, выглядят крайне неудобно.
Live response — это область, которая занимается сбором информации с работающего компьютера, чтобы определить, произошел ли инцидент.
При проведении live response анализа, полезно быстро понять, что происходило с компьютером в последнее время.
Существуют различные инструменты для проведения live response: коммерческие, с открытым исходным кодом и встроенные возможности ОС.
Использование opensource и коммерческих инструментов связано с рядом проблем:
### Неудобство фильтрации оснасткой eventvwr.msc
Фильтрация evtx с помощью стандартной оснастки просмотра событий (eventvwr.msc) ограничена в возможностях.
Кроме того, стандартная оснастка просмотра событий не поддерживает все функции XPath, что может создавать дополнительные проблемы при фильтрации.
Ограничения XPath для фильтрации событий
Пример события в формате XML
Таким образом, недостатки XPath для фильтрации журналов событий Windows заключаются в ограниченных возможностях поиска по атрибутам вложенных элементов, отсутствии некоторых функций сравнения, а также отсутствии поддержки регулярных выражений.
Пример ниже позволяет найти все события из журнала Security c EventID = 4688. Атрибут Path в директиве Query можно опустить. Путь к журналу указывается в в атрибуте Path директивы Select.
В пример ниже добавляем использования логического оператора OR для поиска события с EventID 4688 или 4624.
Оператор Suppress позволяет исключить из конечной выборки события, которые подходят под условие в нем. В примере ниже, мы найдем все события 4624, в которых LogonType=5.
В пределах одного Query мы можем указывать несколько Select-запросов, также есть возможность запрашивать события из разных журналов.
В одном QueryList может быть несколько Query. Это удобно для логического разбиения запросов и их фильтрации.
Таким образом, фильтрация evtx с помощью стандартной оснастки просмотра событий и XPath 1.0 ограничена и не всегда удобна. Для более гибкой и удобной работы с журналами событий можно использовать специализированные инструменты для анализа журналов, которые предоставляют более широкие возможности фильтрации и поиска информации.
## Возможности CMD
Возможности CMD ограничены использованием двух основных утилит wevtutil и Findstr. wevtutil позволяет работать с параметрами журналов и создавать к ним запросы. Для запросов в wevtutil также используются XPath-запросы.
При использовании findstr, наши возможности расширяются для поиска интересующих нас строк.
## Возможности PowerShell
В Powershell для работы с журналами существуют два командлета Get-EventLog и Get-WinEvent. Мы рассмотри второй командлет так как он считается актуальным.
Ограничение при создании FilterHastale
Рассмотрим несколько примеров использования командлета Get-WinEvent и построения конвейеров с ним.
Следующим примером мы выведем 1000 событий из журнала Security.
Get-WinEvent -LogName Security -MaxEvents 1000
Тот же запрос, но используем Format-List для приведения вывода в читаемый.
Используем FilterHashtable. Выведем события из журнала Security с EventId 4688.
Для понимания дальнейших фильтров давайте посмотрим как представлено событие в Powershell, для этого выведем одно событие и воспользуемся командлетом Get-Member.
Свойство Properties – это список, который хранит основные параметры события, которые расположены в секции EventData xml-представления.
Powershell позволяет нам создавать группировки, используя командлет Group-Object. Следующим запросом сгруппируем события Sysmon EventId 3 по следующим полям: процесс, адрес получателя, доменное имя получателя, порт получателя.
Для поиска подстрок можем воспользоваться -Match или -Like.
Поиска событий с известным значением атрибута выполняется быстрее при использовании XPath запросов, чем конвейеров Powershell. Например: запрос ниже найдет все события, связанные с пользователем R00t1kVadim.
Poweshell позволяет представить сообщение в виде xml, выполнив следующий код.
Модуль Powershell Convert-EventLogRecord преобразовывает события в структуру данных, которая позволяет обращаться к атрибутам по их имени. Конвейер для фильтрации событий с Convert-EventLogRecord будет выполняться в 2-3 раза дольше, в отличие от ковейера без его использования.
Используя командлет Out-GridView мы можем вывести события в виде таблицы.
Для вывода нескольких событий в таблицу нужно учитывать, что порядковые номера атрибутов у разных EventId могут хранить разные данные.
Перед расследованием инцидентов, стоит уделить время первому этапу при реагировании – подготовка. Оказавшись в ситуации без флешки, с подготовленным софтом, Вы не растерялись и смогли понять, что происходило в журналах Windows. Во второй статье, рассмотрим утилиты, упомянутые в докладе.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Какими утилитами при реагировании на инциденты Вы пользуетесь?
Проголосовали 23 пользователя. Воздержались 10 пользователей.
Похожее:
«Изменение размера шрифта для устройств Nokia по сравнению с изменением общего масштаба шрифта приложения на Android с использованием Configuration.fontScale»? 
Что такое файл hosts, зачем он нужен и как его исправить? 
Windows 10 1080P, 2K, 4K, 5K HD wallpapers free download | Wallpaper Flare 
Windows 10 — Wikipedia Republished // WIKI 2