Большая охота. Практикуемся в Threat Hunting

Пер­вый этап реаги­рова­ния на ИБ‑инци­дент — это обра­бот­ка событий и поиск в них арте­фак­тов. Затем спе­циалист стро­ит тай­млай­ны и опре­деля­ет век­тор и вре­мя ата­ки. В этой статье мы погово­рим об инс­тру­мен­тах, которые облегча­ют этот труд и помога­ют в рас­сле­дова­нии, в осо­бен­ности ког­да дан­ных очень мно­го.

Иног­да быс­тро отде­лить зер­на от пле­вел прос­то. Дос­таточ­но вос­поль­зовать­ся под­ручны­ми средс­тва­ми или ути­лита­ми вро­де EvtxECmd и Timeline Explorer.

Но быва­ет, что задача серь­езнее: событий на вхо­де мно­го, и обра­ботать такой объ­ем дан­ных быс­тро или най­ти век­тор (и, что час­то слож­нее, опре­делить вре­мя инци­ден­та) доволь­но труд­но. Боль­но смот­реть на ИБ‑спе­циалис­тов, которые исполь­зуют для таких задач натив­ные инс­тру­мен­ты, нап­ример пре­дус­танов­ленный жур­нал прос­мотра событий Windows.

Вмес­то это­го сто­ит воору­жить­ся чуть более прод­винуты­ми инс­тру­мен­тами. Давай раз­берем нес­коль­ко ути­лит и их осо­бен­ности, а заод­но пос­мотрим на них в дей­ствии — на при­мерах событий жур­налов Windows вер­сий стар­ше 7.

Зна­комить­ся будем со сле­дующи­ми ути­лита­ми для Threat Hunting и Incident Response:

О Sigma-пра­вилах и их струк­туре уже написа­на не одна статья, поэто­му очень корот­ко: Sigma — опен­сор­сный про­ект, который ведет­ся с 2017 года и поз­воля­ет писать пра­вила (сиг­натуры) для обна­руже­ния вре­донос­ной активнос­ти. Сей­час обще­дос­тупные пра­вила пок­рыва­ют более 3 тысяч тех­ник и так­тик ата­кующих. Обна­руже­ние вре­донос­ной активнос­ти в инс­тру­мен­тах, о которых мы будем говорить (кро­ме DeepBlueCLI), тоже осно­вано на Sigma-пра­вилах. Они поз­воля­ют быс­тро находить ано­малии и вре­донос­ную активность в боль­шом количес­тве событий. Преж­де чем прис­тупать к ути­литам, ска­чаем Sigma-пра­вила:

git clone https://github.com/SigmaHQ/sigma

Нач­нем, пожалуй, с самого прос­того из выб­ранных инс­тру­мен­тов. DeepBlueСLI — модуль PowerShell, раз­работан­ный Эри­ком Кон­радом для поис­ка угроз в жур­налах событий Windows. В отли­чие от дру­гих инс­тру­мен­тов в этой статье, механизм обна­руже­ния здесь осно­ван не на Sigma-пра­вилах, а на обыч­ных про­вер­ках наличия тех или иных арте­фак­тов и количес­тве сра­баты­ваний для опре­делен­ных событий (нап­ример, попыток неус­пешно­го вхо­да).

На осно­ве этих дан­ных мож­но обна­ружи­вать, нап­ример, подоз­ритель­ные манипу­ляции с учет­ной записью (соз­дание, добав­ление в груп­пы, password spraying и про­чее).

.\DeepBlue.ps1 .\evtx\password-spray.evtx

Здесь замет­но, что были попыт­ки вой­ти в 41 уни­каль­ную учет­ную запись с одним паролем. И заод­но мы видим под­робное опи­сание резуль­тата.

Еще можем гля­нуть активность в коман­дной стро­ке и обо­лоч­ке PowerShell (есть поиск обфусци­рован­ных скрипт­бло­ков, запус­ков через PsExec и дру­гие воз­можнос­ти).

.\DeepBlue.ps1 .\evtx\psattack-security.evtx | Out-GridView

Так­же DeepBlue поз­воля­ет про­водить аудит служб, то есть искать попыт­ки соз­дания служб и дру­гие подоз­ритель­ные события.

По­лучен­ные пос­ле обра­бот­ки дан­ные мож­но вывес­ти в раз­ных удоб­ных фор­матах для даль­нейше­го ана­лиза: CSV, Out-GridView, Format-Table, HTML, JSON, XML.

Кро­ме того, ути­лита поз­воля­ет про­водить иссле­дова­ние на работа­ющей сис­теме, без экспор­та жур­налов событий.

Сре­ди дос­тоинств DeepBlue — воз­можность добав­лять новые про­вер­ки непос­редс­твен­но в код сце­нария на PowerShell. К при­меру, мож­но с лег­костью дописать детект password spraying в Active Directory (события 4771 и 4768).

Но из недос­татков я бы выделил отсутс­твие воз­можнос­ти ука­зать в качес­тве аргу­мен­та путь к дирек­тории с жур­налами. Это зна­чит, что таким инс­тру­мен­том будет слож­но поль­зовать­ся, если объ­ем логов занима­ет нес­коль­ко гигабай­тов. Зато сле­дующая ути­лита нам в этом поможет.

Chainsaw — инс­тру­мент для пер­вично­го реаги­рова­ния на инци­ден­ты и поис­ка арте­фак­тов в жур­налах событий Windows, таб­лицах Master File Table и System Resource Utilization Monitor. Для авто­мати­зации поис­ка угроз исполь­зуют­ся Sigma-пра­вила, но этим дело не огра­ничи­вает­ся. Мож­но искать отдель­ные сло­ва, исполь­зуя регуляр­ные выраже­ния, про­чесы­вать события при помощи кас­томных пра­вил, исполь­зовать кас­томные пра­вила для агре­гации получен­ных записей о сра­баты­вании. Есть дру­гие инте­рес­ные фичи, которые я покажу даль­ше.

Поп­робу­ем воз­можнос­ти на прак­тике. Пред­ставь, что в рам­ках реаги­рова­ния на инци­дент нам отгру­зили события в количес­тве 333 штук (131 Мбайт). Изу­чать жур­налы по отдель­нос­ти име­ет смысл, толь­ко если мы уже зна­ем, какой век­тор ата­ки и ког­да она была совер­шена. Это не наш слу­чай. Сей­час необ­ходимо взгля­нуть на ситу­ацию с высоты птичь­его полета, поэто­му вос­поль­зуем­ся ути­литой Chainsaw в режиме охо­ты на подоз­ритель­ные активнос­ти.

Что­бы вклю­чить режим охо­ты на угро­зы, зададим аргу­мент hunt, ука­жем пра­вила Sigma (флаг -s) и каталог с пра­вила­ми (мож­но исполь­зовать как дирек­торию, так и ре­пози­торий на GitHub). Так­же нуж­но задать каталог с дан­ными об инци­ден­те (жур­налы событий Windows) и путь к фай­лу YAML для мап­пинга пра­вил Sigma и событий (он нужен для сопос­тавле­ния полей из сырых событий и Sigma-пра­вил):

.\chainsaw.exe hunt CyberPolygon_Forensic_Artifacts\winevt\Logs/ -s ..\..\..\sigma\ --mapping ..\..\mappings\sigma-event-logs-all.yml

Ви­дим в кон­соли PowerShell при­ветс­твие Chainsaw и сооб­щение об успешной заг­рузке жур­налов событий и Sigma-пра­вил. Ути­лита работа­ет быс­тро и выда­ет таб­лицу с такими стол­бца­ми:

Са­мое инте­рес­ное здесь — это детект на осно­ве Sigma-пра­вил.

Нап­ример, на рисун­ке выше вид­но вре­мя, сра­ботав­шие пра­вила детек­та — Sigma Rules для событий PowerShell с EID 4104, а так­же путь, из которо­го был запущен сце­нарий PowerShell, и его началь­ное содер­жимое.

Важ­но пом­нить, что аудит PowerShell (события 4103 и 4104) по умол­чанию отклю­чен, рекомен­дует­ся его вклю­чать. Как это сде­лать, мож­но почитать в до­кумен­тации.

В кон­це таб­лицы получим спи­сок детек­тов по Sigma-пра­вилам и количес­тво про­ана­лизи­рован­ных жур­налов (пус­тые жур­налы были отбро­шены).

Ес­ли мы зна­ем, что подоз­ритель­ная активность (судя по детек­ту) была свя­зана со сце­нари­ями PowerShell, а имен­но с событи­ями с EID 4104, мы с лег­костью можем взгля­нуть на сырые события и их скрипт­бло­ки, вос­поль­зовав­шись вот такой коман­дой:

.\chainsaw.exe search -t 'Event.System.EventID: =4104' CyberPolygon_Forensic_Artifacts\winevt\Logs/

По­ищем так­же события с EID 4103:

.\chainsaw.exe search -t 'Event.System.EventID: =4103' CyberPolygon_Forensic_Artifacts\winevt\Logs/

По­луча­ем три сов­падения и узна­ём, с какими аргу­мен­тами запус­кались сце­нарии.

А так­же наб­люда­ем начало тела скрипт­бло­ка tmpA7Z2.ps1.

Кро­ме поис­ка по EID, мож­но исполь­зовать регуляр­ные выраже­ния. Давай поп­робу­ем най­ти все события, свя­зан­ные с запус­ком най­ден­ного сце­нария:

.\chainsaw.exe search -e 'tmpA7Z2.ps1' c56-CyberCorp\Downloads\CyberPolygon_Forensic_Artifacts\winevt\Logs

Ви­дим пер­вое событие, свя­зан­ное с запус­ком tmpA7Z2.ps1.

Да­вай пос­мотрим на весь сце­нарий, для это­го слу­жит флаг --full. Для удобс­тва работы выведем содер­жимое в фор­мате CSV.

.\chainsaw.exe hunt CyberPolygon_Forensic_Artifacts\winevt\Logs/ -s ..\..\..\sigma\ --mapping ..\..\mappings\sigma-event-logs-all.yml --full --csv -o c56-CyberCorp.csv

По­лучен­ный файл откры­ваем в Timeline Explorer.

Здесь видим информа­цию о запус­ке сце­нария, а так­же текст скрипт­бло­ков.

Еще одна фича Chainsaw — воз­можность исполь­зовать кас­томные пра­вила для агре­гации и груп­пиров­ки най­ден­ных арте­фак­тов. С ути­литой в наборе уже идут некото­рые кас­томные пра­вила (ищи их в катало­ге rules): поиск сра­баты­ваний анти­вирус­ного ПО (Kaspersky, MS Defender, Sophos и про­чие), хакер­ских тех­ник вро­де lateral movement, затира­ния и иска­жения событий и дру­гие.

Что­бы вос­поль­зовать­ся эти­ми пра­вила­ми, при­меним допол­нитель­ный флаг -r и ука­жем дирек­торию с пра­вила­ми /rules:

chainsaw.exe hunt -r rules/ Lateral Movement/ -s sigma/rules --mapping mappings/sigma-event-logs-all.yml

Пос­ле обра­бот­ки событий получа­ем отдель­ную таб­лицу с событи­ями, сви­детель­ству­ющи­ми о горизон­таль­ном переме­щении (или подоз­рени­ях на него).

Так­же получи­ли таб­лицу с событи­ями, свя­зан­ными с очис­ткой жур­нала Security.

Да­лее видим обна­руже­ния исклю­читель­но по общим Sigma-пра­вилам, где в том чис­ле наш­лась служ­ба Cobalt Srike Beacon.

На этом воз­можнос­ти Chainsaw не закан­чива­ются. Еще мож­но работать с Master File Table (MFT), System Resource Utilization Monitor (SRUM), выводить тай­млай­ны событий, а пос­ле их визу­али­зиро­вать. Но эти фун­кции я пред­лагаю тебе изу­чить самос­тоятель­но. А мы тем вре­менем поз­накомим­ся с нас­тоящим ком­бай­ном для обра­бот­ки боль­шого количес­тва событий — от десят­ков до сотен гигабайт.

Пра­виль­но и вов­ремя нас­тро­енная полити­ка ауди­та поз­воля­ет получить мно­го полез­ной информа­ции, сок­ратить вре­мя реаги­рова­ния на инци­дент и вре­мя рас­сле­дова­ния. О том, какие события необ­ходимо собирать и какой аудит вклю­чить, мож­но про­читать, нап­ример, в ре­пози­тории Yamato Security. Там же ты най­дешь bat-файл для акти­вации политик ауди­та.

Hayabusa — ути­лита для быс­трой генера­ции тай­млай­нов и поис­ка угроз в событи­ях.

Еще Hayabusa уме­ет опре­делять геопо­зицию по IP, для это­го добавь флаг -G (--GeoIP), но преж­де необ­ходимо соз­дать акка­унт сер­виса MaxMind. Такая воз­можность осо­бен­но полез­на при опре­деле­нии нес­тандар­тных под­клю­чений. Ути­лита так­же спо­соб­на ана­лизи­ровать сис­тему в live-режиме.

Как и Chainsaw, Hayabusa исполь­зует Sigma-пра­вила (с ней идет более 3500 пра­вил), а так­же исполь­зует для детек­тирова­ния собс­твен­ные пра­вила, написан­ные в виде YAML. Это поч­ти то же самое, что и Sigma-пра­вила, но с доработ­ками, которые не под­держи­вают­ся Sigma. Как писать свои пра­вила, под­робно опи­сано в до­кумен­тации.

Еще один плюс ути­литы — вывод обра­ботан­ных событий в фор­мате, который прек­расно понима­ет ути­лита визу­али­зации Timesketch (о том, что это за ути­лита и как ее раз­вернуть, мож­но почитать на сай­те раз­работ­чика.

Что­бы получить такой вывод, исполь­зуй флаг --RFC-3339, зада­ющий фор­мат вывода вре­мен­ных меток, а так­же ука­жи про­филь (-p timesketch-verbose) и вывод вре­мени в фор­мате UTC (флаг -U):

.\hayabusa-2.9.0-win-x64.exe csv-timeline -d E:\CyberDefenders\c56-CyberCorp\Downloads\CyberPolygon_Forensic_Artifacts\winevt\Logs --RFC-3339 -o timesketch-import_c56.csv -p timesketch-verbose -U -C -F

На выходе, кро­ме сра­ботав­ших кас­томных пра­вил (Rule Authors), получа­ем име­на компь­юте­ров и оцен­ку кри­тич­ности событий.

Ес­ли событий мно­го, их мож­но раз­делить по компь­юте­рам и уров­ню кри­тич­ности событий, а так­же тегам (теги здесь — так­тики по MITRE в духе attack.<tech_name>, нап­ример attack.persistence). Таким обра­зом работу лег­ко рас­пре­делить меж­ду чле­нами коман­ды реаги­рова­ния.

Ин­форма­ция о сра­баты­вани­ях агре­гиру­ется в таб­лицу с уров­нями кри­тич­ности и видом детек­та, по которо­му удоб­но искать в Timesketch.

Заг­рузим получив­ший­ся отчет в Timesketch. Здесь мож­но искать по тех­никам и при­менен­ным ути­литам, к при­меру поп­робу­ем най­ти «PsExec Lateral Movement» (наиме­нова­ние было взя­то из таб­лицы пос­ле обра­бот­ки событий в Hayabusa).

Вид­но тай­млайн для событий и сами события. Заг­лянем внутрь любого из них и уви­дим ском­про­мети­рован­ный хост, EID, MitreTags и MitreTactics — что очень удоб­но, к тому же по всем полям мож­но искать в Timesketch.

Что­бы сок­ратить вре­мя поис­ка вре­донос­ной активнос­ти в боль­шом количес­тве событий, мож­но вос­поль­зовать­ся фла­гами --proven-rules, --EID-filter, --enable-unsupported-rules. Флаг --remove-duplicate-data поменя­ет поля дуб­лиру­ющих­ся событий на DUP. При этом они будут учи­тывать­ся, но в вывод не попадут.

Да­вай выведем в кон­соли тай­млайн с час­тотой детек­та, исполь­зуя перечис­ленные фла­ги:

.\hayabusa-2.9.0-win-x64.exe csv-timeline -d Y:\Ransomware31012023\KapeEvidences\C\Windows\System32\winevt\logs --proven-rules --EID-filter --enable-unsupported-rules --visualize-timeline --remove-duplicate-data

Под­павшие под пра­вила события окра­шива­ются в раз­ные цве­та из таб­лицы Results, а их детали мож­но най­ти над гра­фиком.

С таким инс­тру­мен­том ско­рость обра­бот­ки событий уве­личи­вает­ся в разы, но не сто­ит забывать, что выход­ные дан­ные дают лишь пер­воначаль­ную кар­тину слу­чив­шегося и механизм может не обна­ружи­вать некото­рые события, оставляя им уро­вень low.

По­это­му на осно­ве общих пра­вил необ­ходимо писать свои пра­вила детек­тирова­ния и перехо­дить к более тща­тель­ному ана­лизу, сужая вре­мен­ную зону поис­ка. Для это­го исполь­зуй фла­ги --timeline-start, --timeline-end, --timeline-offset.

Да­вай сде­лаем это и оста­вим толь­ко детек­ты уров­ня critical:

Ути­лита отра­бота­ла в разы быс­трее (на малом объ­еме событий будет не слиш­ком замет­но) и выдала час­тотный гра­фик за ука­зан­ный про­межу­ток вре­мени, а из событий оста­лись толь­ко те, что помече­ны как кри­тич­ные.

Для сужения области поис­ка мож­но исполь­зовать и дру­гие фла­ги, нап­ример исклю­чить хос­ты или оста­вить толь­ко один целевой хост (для это­го есть фла­ги --include-computer и --exclude-computer). То же самое мож­но про­делы­вать и с событи­ями по их Event ID.

Еще один хороший при­ем при поис­ке арте­фак­тов в событи­ях — исполь­зовать pivot-keywords-list. На выходе получим спи­сок уни­каль­ных дан­ных для детек­тирова­ния подоз­ритель­ной активнос­ти. Поля, которые будут извле­кать­ся при поис­ке, мож­но най­ти по такому пути:

Hayabusa_dir\rules\config\pivot_keywords.txt

Сре­ди полей при нас­трой­ках по умол­чанию будут име­на поль­зовате­лей, хос­тов, IP-адре­са, про­цес­сы (LOLBINS и так далее) и дру­гие арте­фак­ты:

.\hayabusa-2.9.0-win-x64.exe pivot-keywords-list -d Y:\Ransomware31012023\KapeEvidences\C\Windows\System32\winevt\logs

На рисун­ке выше выведен спи­сок про­цес­сов, которые запус­кались на хос­те.

Еще одна фиш­ка Hayabusa — это наличие интегра­ции с Velociraptor, что поз­воля­ет собирать и сра­зу ана­лизи­ровать арте­фак­ты.

Так­же есть воз­можность работать не толь­ко с фай­лами с рас­ширени­ем .evtx, но и с фай­лами в фор­мате JSON и JSONL. Что­бы най­ти дру­гие инте­рес­ные воз­можнос­ти Hayabusa, рекомен­дую заг­лянуть в ее богатую докумен­тацию. Мы же перей­дем к сле­дующе­му инс­тру­мен­ту, соз­данно­му в Yamato Security.

Преж­де чем исполь­зовать Takajo, нуж­но под­готовить тай­млай­ны при помощи Hayabusa:

.\hayabusa-2.9.0-win-x64.exe json-timeline -d KapeEvidences\C\Windows\System32\winevt\logs -L -o ramsomware_timeline.jsonl

Те­перь мож­но ана­лизи­ровать события вхо­да в Takajo:

./takajo.exe timeline-logon -t .\ramsomware_timeline.jsonl -o ransomware_logon.csv

За­бира­ем все IP-адре­са из обра­ботан­ных Hayabusa дан­ных:

./takajo.exe list-ip-addresses -t ..\hayabusa-2.9.0-win-64-bit\cybercorp.jsonl -o cybercorp_ipaddr.txt

По умол­чанию берут­ся толь­ко пуб­личные IP-адре­са, для вклю­чения при­ват­ных нуж­но исполь­зовать флаг -p.

По­том мож­но будет про­верить эти IP на VirusTotal:

./takajo.exe vt-ip-lookup -a <YOUR_API_KEY> -I .\cybercorp_ipaddr.txt -o vt-ip-lookup.csv -r 1000 -j vt-ip-lookup.json

То же мож­но сде­лать и с дру­гими инди­като­рами ком­про­мета­ции: домена­ми и хеш‑сум­мами исполня­емых фай­лов (если событие было получе­но от Sysmon).

Takajo уме­ет выводить тай­млай­ны подоз­ритель­ных про­цес­сов (timeline-suspicious-processes) и стро­ить дерево про­цес­сов на осно­ве событий Sysmon (необ­ходимо ука­зать processGuid).

Опи­сан­ные в статье ути­литы при уме­лом исполь­зовании поз­воля­ют сущес­твен­но сок­ратить вре­мя, нуж­ное на реаги­рова­ние и поиск угроз. Одна­ко нель­зя полагать­ся толь­ко на инс­тру­мен­тарий и забывать, что тех­ники ата­кующих пос­тоян­но совер­шенс­тву­ются, поэто­му для успешно­го рас­сле­дова­ния пра­вила обна­руже­ния тоже нуж­но улуч­шать. В иде­але спе­циалист по реаги­рова­нию дол­жен уметь сам готовить и дораба­тывать такие пра­вила, а так­же быть в кур­се новей­ших тех­ник и инс­тру­мен­тов, которые при­меня­ются ата­кующи­ми.