Эта статья является первой частью серии по анализу Sysmon-угроз. Все остальные части серии:
Часть 1. Знакомство с анализом логов Sysmon
Часть 2. Использование данных из Sysmon-событий для выявления угроз (мы тут)
Часть 3. Углубленный анализ Sysmon-угроз с помощью графов
В этом разделе мы углубимся и начнём использовать детализированную информацию, которую предоставляет нам Sysmon. Вот три основных момента, которые мы будем прорабатывать:
- Использование PowerShell для прямого доступа к гранулированной информации о процессах;
- Построение и визуализация иерархии процессов – первый важный шаг в поиске угроз;
- Использование метаданных Sysmon для формирования важных метрик, полезных при углублённом расследовании угроз, таких как подсчёт частоты, с которой запускаются конкретные процессы.
Использование Get-Sysmonlogs
Давайте теперь подробнее рассмотрим мою замечательную команду, которая преобразовывает Sysmon-события в объекты PowerShell. Я в какой-то степени горжусь тем, что мне не пришлось прописывать вручную отдельные строки кода для каждого из полей. И вот, собственно, великое раскрытие кода:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 }
foreach ($event in $events) {
$ev = $event.Message -split "`r`n"
$jsons="{ "
foreach ($line in $ev) {
$line=$line -replace "\\","\\" `
-replace "\{"," " `
-replace "\}"," " `
-replace '"','\"' `
-replace "`n"," "
$line=$line -replace '(\s*[\w\s]+):\s*(.*)', '"$1":"$2",'
$jsons = $jsons + $line }
$jsons =$jsons + '"blah" : "blah" }'
ConvertFrom-Json -InputObject $jsons
}
}
Весь код сейчас выложен на GitHub и вы можете его скачать и импортировать как Sysmon-модуль для собственного проекта. Единственная нестабильность связана с удалением нескольких неприятных символов — скобки, бекслэши, символы конца строки, кавычки — чтобы сделать вывод приближённым к JSON.
Итак, классическим сигналом нарушителя, копошащимся вокруг системы, является использование команды «whoami», и зачастую следующей после «hostname». Хакер (или, возможно, инсайдер), заполучивший чью-то учётную запись, хочет убедиться, что имперсонализация работает, поэтому он часто набирает вышеуказанные команды, как только оказывается на сервере жертвы. Для остальных же «whoami» и «hostname» – это не те слова, которые они будут вводить в консоли собственной системы, даже если они когда-либо пользуются командной строкой.
С помощью моей аккуратной команды, дающей доступ ко всем записям лога Sysmon, мы легко можем состряпать цепочку, фильтрующую имя процесса (как мы это сделали в первой части). При этом с Sysmon мы можем подойти к вопросу ещё более гранулярно, заглянув в командную строку родительского процесса.
Обычно, когда хакер проникает в сеть и получает доступ к командой строке, она представляет из себя устаревшую cmd – кстати, именно так и происходит в случае взлома при помощи psexec или smbexec. Используя вывод get-symonlogs, можно отловить процессы whoami, которые были порождены этими устаревшими шеллами, и это будет хорошим доказательством угрозы.
Внимание: Whoami запустился через устаревший шелл cmd
С практической же точки зрения поиск по «сырым» логам журнала событий Windows и сопоставления процессов просто невозможно. Как мы только что видели, записи в Sysmon открывают множество возможностей для анализа угроз. Поэтому давайте продолжим наше исследование посредством сопоставления Sysmom-данных в более сложные структуры.
Азы структур данных: списки и графы
Логи Sysmon не только предоставляют нам командную строку родительского процесса, но и идентификатор этого процесса!
Я думаю, вы уже догадались, что это значит. Но всё же: теперь мы можем соединить воедино процессы в иерархии и, не побоюсь этого сказать, сети. Вспомнив базовые понятия информатики, можно обнаружить естественные структуры данных для получения такой информации – связные списки и графы первыми приходят на ум.
Сначала я думал, что мне придётся сдувать пыль с моей копии «Структуры данных для поэтов и су-шефов», но тут меня выручили интернеты. Я наткнулся на шикарную коллекцию базовых алгоритмов Дага Финке (Doug Finke) на Gihub, написанную на PowerShell. Спасибо тебе, Даг!
После преодоления некоторой кривой обучения, я смог использовать его алгоритмы для структуризации моих событий Sysmon. Я построил структуры данных в виде списка и графа, а затем, с использованием API, написал PowerShell-функцию поиска команды и вывода иерархии процесса. Круто.
Я назвал её show-threat-path. Она осуществляет поиск в глубину по иерархии процесса и выводит имена приложений и ассоциированные с ними команды для корневого приложения, указанного в качестве входного параметра. В качестве моего первого теста я поискал по «whoami.exe». И вот что увидел:
Иерархия процессов: процесс 2452 выглядит подозрительным!
Дополнительный бонус тому, кто заметил на выводе выше, что whoami, ассоциированный с процессом 2452, был вызван через устаревший шелл cmd, который уже в свою очередь был запущен exe-файлом со странным именем в папке Windows.
Хммм. Если вы знакомы с механиками удалённых вызовов psexec, описанными здесь , то мысленно должны уже бить в колокола. Но я расскажу вам маленький секрет: играя роль хакера, я предварительно запустил данный whoami с удалённого сервера Linux с помощью python-скриптов Impacket.
Целью является демонстрация того, что с помощью обогащённых Sysmon логов и небольшой порции PowerShell, можно приготовить вполне практичную утилиту по выявлению уязвимостей, как я это только что проделал с show-threat-path.
Охота на угрозы с помощью направленных графов
Пришло время заняться более странными вещами. Обладая всей этой информацией о процессах, полученной из Sysmon, можно взглянуть на связи в более общем виде. Другими словами, я хочу рассматривать запущенные приложения — PowerShell.exe, Explorer.exe, и т.д. — как вершины графа и связать их с тем приложением, которое в свою очередь их запустило. В результате получится схема, показывающая, каким образом приложения взаимодействуют друг с другом (вместо создания отдельной вершины на каждый инстанс процесса).
С технической точки зрения речь идёт о направленном графе, в котором путь, если можно так выразиться, представляет из себя одностороннюю дорогу от приложения к его родительскому процессу.
На данном этапе было бы неплохо взглянуть на визуализацию того, о чём я веду речь. К счастью, существует великолепная утилита визуализации PowerShell графов под названием GraphViz, у которой есть чрезвычайно простые оболочки, доступные через PSQuickGraph. Тогда с помощью небольшого куска кода…
#Let's graph it!!!
$gv = New-Graph -Type BiDirectionalGraph # PSQuickGraph
foreach ($e in $g.getAllEdges() ) { $g from Doug Fink's functions
$vs= $e.startvertex
$ve= $e.endvertex
PSQuickGraph\Add-Edge -From $vs.value.Key -To $ve.value.Key -Graph $gv |Out-Null
}
Show-GraphLayout -Graph $gv
… можно визуализировать сложные взаимодействия между приложениями через интерфейс GraphViz:
GraphViz: Библиотека PowerShell для визуализации иерархий процессов
Что это даёт? По сути – это графический способ выявлять угрозы. Вместо того, чтобы искать определённую сигнатуру текста, как мы это делали раньше с командой show-threat-path, теперь мы можем попытаться найти аномалии на графе.
Идея заключается в понимании того, что является нормальной картиной соседства графов и подграфов — обычно они выглядят как связные структуры на визуализации — а затем в попытке обнаружить вершины, выглядящие как более обособленные. И на самом деле наши глаза неплохо приспособлены под эту задачу. Но к счастью, также имеется и несколько простых алгоритмов обнаружения соседства и выявления угроз. И когда-то давно ваш покорный слуга даже написал пост об использовании техники выявления соседств в сети социальных связей, ассоциированной со… знаменитым героем революции в США.
Преимущество данного подхода в поиске злоумышленников заключается в том, что хакеры могут менять свои техники и обфусцировать свои атаки, но им непросто скрыть свои паттерны графов.
В третьей части нашего обзора мы углубимся в анализ и применение алгоритмов и методов для поиска уязвимостей. Оставайтесь с нами!
