Эта статья является первой частью серии по анализу 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-события в куда более сложные структуры.
