Эта статья является первой частью серии по анализу Sysmon-угроз. Все остальные части серии:
Часть 1. Знакомство с анализом логов Sysmon (мы тут)
Часть 2. Использование данных из Sysmon событий для выявления угроз
Часть 3. Углубленный анализ Sysmon-угроз с помощью графов
Если вы занимаетесь информационной безопасностью, наверняка вам часто приходится разбираться в происходящих атаках. Если у вас уже намётанный глаз, вы можете поискать нестандартную активность в сырых необработанных логах скажем, PowerShell-скрипт с запущенной командой DownloadString или VBS-скрипт, притворяющийся Word-файлом, просто пролистывая последнюю активность в журнале событий Windows. Но это реально большая головная боль. К счастью, Microsoft создал Sysmon, делающий анализ атак куда более простым.
Хотите разобраться в базовых идеях, стоящих за отображаемыми в логе Sysmon угрозами? Скачайте наше руководство WMI события как средство шпионажа и вы осознаете, как инсайдеры могут незаметно наблюдать за другими сотрудниками. Основной проблемой работы с журналом событий Windows является отсутствие информации о родительских процессах, т.е. из него нельзя понять иерархию процессов. В записях лога Sysmon же наоборот, содержатся идентификатор процесса родителя, его имя и запускаемая командная строка. Спасибо тебе, Microsoft.
В первой части нашей серии мы посмотрим, что можно сделать с базовой информацией из Sysmon. Во второй части мы в полной мере воспользуемся информацией о родительских процессах для создания более комплексных структур соответствия, которые известны как графы угроз. В третьей части мы рассмотрим простой алгоритм, который сканирует граф угроз для поиска нестандартной активности через анализ веса графа. А в конце в качестве вознаграждения вас ждет аккуратный (и понятный) вероятностный метод обнаружения угроз.
Часть 1: Знакомство с анализом логов Sysmon
Что поможет разобраться в сложностях журнала событий? В конечном итоге SIEM. Она производит нормализацию событий и упрощает их последующий анализ. Но нам не обязательно заходить так далеко, по крайне мере первое время. В начале для понимания принципов SIEM достаточно будет попробовать замечательную бесплатную утилиту Sysmon. И с ней на удивление легко работать. Так держать, Microsoft!
Какие есть возможности у Sysmon?
Если кратко полезная и читабельная информация о процессах (см. картинки ниже). Вы обнаружите кучу полезных деталей, которых нет в журнале событий Windows, но самое главное следующие поля:
- ID процесса (в десятичной форме, а не hex!)
- ID родительского процесса
- Командную строку процесса
- Командную строку родительского процесса
- Хэш образа файла
- Имена образов файла
Sysmon устанавливается одновременно и как драйвер устройства, и как служба подробнее здесь. Её ключевым преимуществом является возможность анализа логов из нескольких источников, корреляция информации и вывод результирующих значений в одну папку журнала событий, находящуюся по пути Microsoft -> Windows -> Sysmon -> Operational. В моих собственных расследованиях логов Windows, от которых волосы встают дыбом, мне постоянно приходилось переключаться между, скажем, папкой с логами PowerShell, и папкой Безопасность, пролистывая журналы событий в героический попытке как-то сопоставить значения между ними. Это ни разу не легкая задача, и как я потом понял, лучше было сразу запастись аспирином.
Sysmon же делает качественный скачок вперёд, предоставляя полезную (или как любят говорить вендоры действенную) информацию для помощи в понимании основополагающих процессов. Например, я запустил скрытную сессию wmiexec, симулирующую перемещение умного инсайдера внутри сети. Вот что при этом вы увидите в журнале событий Windows:
В журнале Windows видна какая-то информация о процессе, но она малополезна. Плюс идентификаторы процессов в шестнадцатеричной форме???
У профессионального ИТ-специалиста с пониманием основ хакинга должна вызвать подозрение командная строка. Использование cmd.exe для последующего запуска другой команды с перенаправлением вывода в файл со странным названием это явно похоже на действия софта по контролю и управлению command-and-control (C2): таким способом создаётся псевдо-шелл с помощью служб WMI.
Теперь давайте взглянем на эквивалент записи из Sysmon, обратив внимание на то, сколько дополнительной информации она нам даёт:
Возможности Sysmon на одном скриншоте: детальная информация о процессе в читабельной форме
Вы не только видите командую строку, но и имя файла, путь до исполняемого приложения, что Windows знает об этом (Windows Command Processor), идентификатор родительского процесса, командная строка родителя, запустившего cmd-шелл, а также реальное имя файла родительского процесса. Всё в одном месте, наконец-то!
Из лога Sysmon мы можем сделать вывод, что с высокой долей вероятности эта подозрительная командная строка, которую мы видели в сырых логах, не является результатом нормальной работы сотрудника. Скорее наоборот, она была сгенерирована C2-подобным процессом wmiexec, как я упоминал ранее и была напрямую порождена процессом WMI службы (WmiPrvSe). Теперь у нас есть индикатор того, что удалённый злоумышленник или инсайдер пробует корпоративную инфраструктуру на зуб.
Представляем Get-Sysmonlogs
Конечно замечательно, когда Sysmon располагает логи в одном месте. Но, наверное, было бы ещё лучше, если бы мы могли получить доступ к индивидуальным полям лога программным способом например, через команды PowerShell. В этом случае можно было бы написать небольшой PowerShell-скрипт, который бы автоматизировал поиск потенциальных угроз!
Не у меня первого возникла такая идея. И хорошо, что в некоторых постах форумов и GitHub проектах уже объяснено, как использовать PowerShell для парсинга Sysmon-лога. В моём случае мне хотелось избежать необходимости написания отдельных строк парсинг-скрипта для каждого поля Sysmon. Поэтому я использовал принцип ленивого человека и, как мне кажется, в результате придумал что-то интересное.
Первым важным моментом является возможность команды Get-WinEvent читать Sysmon логи, фильтровать нужные события и выводить результат в PS переменную, как здесь:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Если вы захотите самостоятельно проверить работу команды, то через отображение контента в первом элементе массива $events, $events[0].Message, на выходе можно получить серию текстовых строк с очень простым форматом: имя поля Sysmon, двоеточие и затем само значение.
Ура! Вывод Sysmon лога в готовый под JSON-формат
Вы думаете о том же, о чём и я? Приложив ещё немного усилий, можно сконвертировать вывод в отформатированную под JSON-строку и затем загрузить её напрямую в PS-объект с помощью мощной команды ConvertFrom-Json .
Я покажу PowerShell-код для конвертации он очень простой в следующей части. А пока что давайте глянем, что может делать моя новая команда под названием get-sysmonlogs, которую я установил как PS-модуль.
Вместо углубления в анализ логов Sysmon через неудобный интерфейс журнала событий, мы можем без усилий искать инкрементальную активность непосредственно из PowerShell-сессии, а также использовать PS-команду where (алиас ?) для сокращения результатов выдачи:
Список cmd-шеллов, запущенных через WMI. Анализ угроз задёшево с помощью нашей собственной команды Get-Sysmonlogs
Удивительно! Я создал инструмент опроса Sysmon-лога, как если бы он был базой данных. В нашей статье про EQL отмечалось, что эту функцию и выполнят описываемая в нём крутая утилита, хотя формально всё же через реальный SQL-подобный интерфейс. Да, EQL изящен, но мы коснёмся его в третьей части.
Sysmon и анализ графов
Давайте абстрагируемся и подумаем, что мы только что создали. По сути, у нас теперь есть база данных событий Windows, доступная через PowerShell. Как я отметил ранее, между записями существуют соединения или связи через ParentProcessId поэтому можно получить полную иерархию процессов.
Если вы читали серию Приключения неуловимой малвари, то знаете, что хакеры любят создавать сложные многоэтапные атаки, в которых каждый процесс выполняет свою маленькую роль и готовит плацдарм для следующего шага. Такие вещи крайне сложно отловить просто из сырого лога.
Но с моей командой Get-Sysmonlogs и дополнительной структурой данных, которую мы рассмотрим далее по тексту (конечно же, это граф), у нас появится практичный способ обнаружить угрозы для чего требуется лишь выполнить правильный поиск по вершинам.
Как всегда в наших DYI блог-проектах, чем больше вы работаете над анализом деталей угроз в небольшом масштабе, тем лучше вы осознаёте, насколько сложным является детектирование угроз на уровне организации. И это осознание является крайне важным моментом.
Мы встретим первые интересные сложности во второй части статьи, где начнём связывать друг с другом Sysmon-события в куда более сложные структуры.
