Threat Hunting в действии

материалы

Введение

В предыдущей статье мы поговорили о том, что такое Threat Hunting, и показали его силу в обнаружении современных киберугроз. Также на небольших примерах мы рассмотрели различные подходы к хантингу, такие как IoC-, Tool-, TTPs-based, и показали, в чем их различия. В этом материале мы предлагаем вам окунуться глубже и посмотреть на Threat Hunting в действии на примере специально созданного нами инцидента. После описания самого инцидента мы покажем, как выглядит процесс генерации гипотез хантерами и как они используют различные подходы для детектирования вредоносной активности. Для поиска следов такой активности мы будем использовать события аудита ОС Windows и утилиты Sysmon из набора Sysinternals, а для централизованного хранения и анализа собранных событий — платформу Threat Hunting на базе Elastic Stack.

Описание инцидента

В результате фишинговой атаки ничего не подозревающий пользователь открывает вложение к письму — документ Microsoft Excel с интересным названием «Annual_Salary_Bonuses.xlsm». Файл содержит вредоносный макрос, который, обманом получив у пользователя разрешение на запуск, выполняет следующую последовательность действий (рис. 1):

подключается к серверу управления атакующего и скачивает файл viewpage.php, содержащий полезную нагрузку — meterpter reverse shell;
переименовывает загруженный файл и сохраняет его в каталоге %TEMP% под именем sysprov32.dll;
прописывает в ключ реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Run значение userprep со следующим содержимым: rundll32 C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll,#0;
запускает полезную нагрузку, которая содержится в файле sysprov32.dll, командой rundll32 C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll,#0.

После запуска reverse shell атакующий получает удаленный доступ к компьютеру пользователя и при помощи PowerShell-скрипта Invoke-Mimikatz.ps1 выполняет дамп учетных данных пользователей из локальной базы SAM (Security Accounts Manager). Однако дамп учетных данных из памяти процесса LSASS (Local Security Authentication Service) завершается неудачей, так как скрипт Invoke-Mimikatz.ps1 содержит в себе не работающую на машине пользователя версию утилиты Mimikatz. Поэтому атакующий загружает на компьютер пользователя последнюю версию утилиты Mimikatz в виде исполняемого PE-файла и сохраняет его в каталоге c:\Users\vadmin\Documents\ с именем m.exe. После запуска этого файла атакующий крадет учетные данные из оперативной памяти.

Рис. 1. Последовательность событий атаки

Формирование гипотез

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

Как правило, все начинается с зацепки, которую охотник получил в результате отработки первичной гипотезы. Найденная зацепка позволяет «раскрутить» весь инцидент по цепочке и восстановить его полную картину. В качестве первичной может быть использована гипотеза, сформированная с использованием одного из трех подходов: IoC-, Tool- или TTPs-based. Давайте пойдем от простого к сложному и начнем с подхода IoC-based.

Охота с использованием подхода IoC-based

Генерация гипотезы при использовании подхода IoC-based основана на поиске индикаторов компрометации в защищаемой инфраструктуре. В случае нашего инцидента таким индикатором может быть IP-адрес сервера управления атакующего, полученный из базы Threat Intelligence.

Предположим, для отработки гипотезы мы выбрали индикатор, представленный на рис. 2.

Рис. 2. Выбор индикатора компрометации из базы Threat Intelligence

Согласно данным Threat Intelligence, IP-адрес 31.179.135.186 используется вредоносным программным обеспечением.

Теперь сгенерируем первоначальную гипотезу. Она может звучать следующим образом: в нашей инфраструктуре есть скомпрометированный хост или группа хостов, которые осуществляли или продолжают осуществлять подключения к вредоносному серверу управления с IP-адресом 31.179.135.186.

Используя платформу Threat Hunting и доступную телеметрию, попробуем подтвердить или опровергнуть данную гипотезу. Пример запроса и его результаты представлены на рис. 3.

Текст запроса

event_type:NetworkConnection AND (net_src_ipv4:31.179.135.186 OR net_dst_ipv4:31.179.135.186)

Рис. 3. Отработка гипотезы IoC-based на платформе Threat Hunting

Результаты запроса показывают, что хост DESKTOP-HVS4327 выполнял сетевые подключения к вредоносному IP-адресу на порты 443 и 8443.

Гипотеза подтвердилась — можно сделать вывод о том, что данный хост скомпрометирован.

События Sysmon Event ID 3 и Windows Event ID 5156 содержат поле с именем процесса, создавшего сетевое подключение. Проверим, какие процессы выполняли сетевые подключения к вредоносному хосту (рис. 4).

Рис. 4. Процессы, создавшие подключения к вредоносному IP-адресу

Первое подключение было выполнено процессом C:\Program Files (x86)\Microsoft Office\Office16\excel.exe, что логично, так как инцидент начался с открытия пользователем вредоносного вложения Microsoft Excel. Также мы видим ряд подключений процессом rundll.32.exe. В результате проверки гипотезы инцидент был обнаружен.

Помимо IP-адреса, для обнаружения нашего инцидента могут быть использованы и другие индикаторы, например файлы sysprov32.dll, Annual_Salary_Bonuses.xlsm или значение реестра userprep. Однако атакующий может легко изменить все перечисленные индикаторы, что позволит ему избежать обнаружения подходом IoC-based.

Охота с использованием подхода Tool-based

Теперь посмотрим, как можно обнаружить вредоносную активность в рамках нашего инцидента, используя подход Tool-based. Как мы помним из предыдущей статьи, этот подход основан на выделении характерных признаков хакерских инструментов, например командных строк, именованных каналов, PowerShell-командлетов или сетевых сигнатур.

Для кражи учетных данных пользователей атакующий использовал хорошо известную утилиту Mimikatz и ее PowerShell-версию Invoke-Mimikatz, применяющую технику reflective PE injection для загрузки Mimikatz в память.

В качестве гипотезы Tool-based возьмем предположение о том, что в нашей инфраструктуре для дампа учетных данных пользователей могли быть использованы утилиты Mimikatz или Invoke-Mimikatz. Поиск специфичных командных строк мы будем выполнять по событиям старта процессов (Windows Security Event ID 4688 и Sysmon Event ID 1), а PowerShell-командлетов — по событиям журналов Windows PowerShell (Event IDs 400, 800) и Microsoft-Windows-PowerShell/Operational (Event ID 4104). Пример запроса для отработки нашей гипотезы на платформе Threat Hunting и его результаты представлены ниже на рис. 5.

Текст запроса

( (cmdline:(*powershell* OR *SyncAppvPublishingServer* OR *pwsh*) OR proc_file_originalfilename:"PowerShell.EXE" OR proc_file_productname:"PowerShell Core 6" OR proc_file_description:"Windows PowerShell" OR event_log_source:PowerShell AND event_id:400) AND  cmdline:("Invoke-Mimikatz" OR "Invoke-ReflectivePEInjection" OR "Invoke-ReflectiveDllInjection" OR "Write-BytesToMemory" OR "Enable-SeDebugPrivilege" OR "Create-RemoteThread") ) OR (( (event_log_source:PowerShell AND event_id:800) OR (event_log_source:"Microsoft-Windows-PowerShell" AND event_id:4104) ) AND script_text:("Invoke-Mimikatz" OR "Invoke-ReflectivePEInjection" OR "Invoke-ReflectiveDllInjection" OR "Write-BytesToMemory" OR "Enable-SeDebugPrivilege" OR "Create-RemoteThread"))

Рис. 5. Обнаружение специфичных командлетов утилиты Invoke-Mimikatz

С помощью запроса мы обнаружили выполнение характерных для утилиты Invoke-Mimikatz командлетов. Выполним еще один запрос, который позволит нам проверить наличие специфичных командных строк утилиты Mimikatz в событиях старта процессов (рис. 6).

Текст запроса

(cmdline:(*mimikatz* *DumpCerts* *DumpCreds* "*invoke\-mimikatz*")) OR (cmdline:(*kerberos* *sekurlsa* *logonpasswords* *lsadump* *privilege*) AND cmdline.keyword:*\:\:*)

Рис. 6. Обнаружение специфичных командных строк утилиты Mimikatz

Проверка гипотезы выявила использование утилит Invoke-Mimikatz и Mimikatz на хосте DESKTOP-HVS4327. Судя по командным строкам, атакующий выполнил дамп учетных данных локальных пользователей из базы SAM, а также дамп учетных данных из памяти процесса LSASS.

Как видите, подход Tool-based довольно надежен. Чтобы обойти такое детектирование, атакующему понадобится либо кастомизировать свои любимые инструменты, либо вовсе отказаться от их использования.

Охота с использованием подхода TTPs-based

Подход TTPs-based направлен на детектирование тактик, техник и процедур атакующего или, иными словами, его поведенческих паттернов. Поэтому при использовании охотниками этого подхода злоумышленнику будет сложнее всего избежать обнаружения.

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

Гипотеза 1: подключение к вредоносному хосту от процесса офисного приложения

Для отработки гипотезы нам понадобится интеграция с источником Threat Intelligence. При наличии определенных индикаторов компрометации в событиях (например хеш-сумм, IP-адресов, доменных имен, адресов электронной почты и т. д.) они могут быть обогащены специальным тегом, например malicious.

На нашей платформе Threat Hunting для всех событий типа NetworkConnection реализовано обогащение IP-адресов по базе Threat Intelligence, что позволяет проверить гипотезу следующим несложным запросом (рис. 7).

Текст запроса

event_type:NetworkConnection AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND (enrich.ti.net_dst_ipv4.categories:Malware OR enrich.ti.net_src_ipv4.categories:Malware)

Рис. 7. Обращение к вредоносным хостам от процессов приложений Microsoft Office

Проверка гипотезы показала наличие сетевых подключений процесса C:\Program Files (x86)\Microsoft Office\Office16\excel.exe к вредоносному хосту с IP-адресом 31.179.135.18.

Несмотря на кажущееся сходство с детектом по IP-адресу, описанному в начале статьи, такой подход имеет ряд преимуществ перед ним. Первое — мы не используем один конкретный индикатор, а работаем сразу со всеми индикаторами из базы Threat Intelligence. Второе — даже если бы в базе TI-платформы не оказалось IP-адреса атакующего, мы бы заметили, что офисное приложение подключается к внешнему IP-адресу. А этот факт сам по себе заслуживает внимания и требует тщательного анализа.

Гипотеза 2: создание исполняемого файла офисным приложением

Атакующие зачастую используют вредоносные макросы в составе документов в качестве легковесного кода, предназначенного для доставки основной полезной нагрузки с сервера управления. В таком случае процесс офисного приложения может сохранить в файловой системе файл с полезной нагрузкой для его последующего запуска. Если атакующий не замаскировал расширение файла под более безобидное, мы можем использовать событие FileCreate Sysmon (Event ID 1) для обнаружения подобной активности.

Выполним следующий запрос на платформе Threat Hunting — он покажет нам, создавались ли на каком-нибудь хосте исполняемые файлы процессом офисного приложения (рис. 8).

Текст запроса

event_type:FileCreate AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND file_path.keyword:(*.exe OR *.dll OR *.cpl OR *.msi OR *.sys)

Рис. 8. Создание исполняемых файлов приложением Microsoft Excel

Наша гипотеза снова подтвердилась. Результаты запроса показывают, что на хосте DESKTOP-HVS4327 процессом C:\Program Files (x86)\Microsoft Office\Office16\excel.exe был создан исполняемый файл C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll.

Однако в тех случаях, когда файл с полезной нагрузкой будет иметь более безобидное расширение, наш запрос не вернет никаких результатов.

Гипотеза 3: запуск командного интерпретатора cmd офисным приложением

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

Запуск процессом офисного приложения командного интерпретатора cmd — аномальное событие. Оно может свидетельствовать об исполнении вредоносного кода, встроенного в документ, например макроса или DDE. Результаты следующего запроса покажут, встречались ли в нашей инфраструктуре подобные аномалии (рис. 9).

Текст запроса

event_type:ProcessCreate AND proc_p_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe")  AND (proc_file_path:"\\cmd.exe" OR cmdline:(cmd.exe "*cmd *"))

Рис. 9. Запуск приложением Microsoft Excel командного интерпретатора cmd

Из результатов видно, что на хосте DESKTOP-HVS4327 процессом C:\Program Files (x86)\Microsoft Office\Office16\excel.exe был запущен командный интерпретатор cmd с командной строкой C:\Windows\System32\cmd.exe /c rundll32 C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll,#0. Наша гипотеза подтвердилась.

Помимо интерпретатора cmd, гипотеза может быть расширена поиском следов запуска интерпретаторов PowerShell и скриптовых интерпретаторов Cscript\Wscript.

Гипотеза 4: использование rundll32 для вызова функции dll-библиотеки по порядковому номеру

Для исполнения полезной нагрузки, содержащейся в файле sysprov32.dll, атакующий использовал программу rundll32.

Rundll32.exe — легитимная программа ОС Windows, которая позволяет запускать код из произвольной dll-библиотеки. С помощью rundll32 злоумышленники могут проксировать исполнение вредоносного кода для обхода средств защиты, например механизма Application whitelisting.

Применить какие-либо превентивные средства против данной техники трудно. Запретить исполнение rundll32 в системе практически невозможно, так как она активно используется операционной системой для выполнения легитимных операций, а попытки обнаружения защитниками всех вызовов rundll32 могут привести к большому числу ложноположительных срабатываний.

Однако решение есть. Rundll32.exe обладает одной интересной особенностью, позволяющей вызывать функции dll-библиотек не по имени, а по их порядковому номеру. Такие вызовы rundll32 встречаются довольно редко при выполнении легитимных операций и часто используются вредоносным программным обеспечением для обхода сигнатурного детектирования. При помощи следующего запроса мы можем проверить гипотезу о наличии таких аномальных вызовов rundll32 в нашей инфраструктуре, используя события старта процесса (рис. 10).

Текст запроса

proc_file_path:"\\rundll32.exe" AND cmdline.keyword:/.*\#[0-9]+/

Рис. 10. Аномальные вызовы rundll32.exe

Результаты выполненного запроса показали наличие аномальных вызовов rundll32.exe на хосте DESKTOP-HVS4327.

Гипотеза 5: изменение офисным приложением ключа реестра, отвечающего за автозагрузку

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

Для сохранения доступа после перезагрузки атакующие используют различные техники закрепления в системе (Persistence). Одна из таких техник — прописывание полезной нагрузки в ключи реестра, отвечающие за автозагрузку и выполнение кода при входе пользователя в систему.

В случае нашего инцидента полезная нагрузка была сохранена в ключе реестра HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Прописывание офисными приложениями каких-либо значений в ключи реестра, отвечающие за автозагрузку, является аномальным и может свидетельствовать о попытках вредоносного кода закрепиться в системе. Давайте выполним запрос, проверяющий нашу гипотезу (рис. 11).

Текст запроса

event_type:RegistryValueSetPersistence AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND reg_key_path:("\\Microsoft\\Windows\\CurrentVersion\\Run" OR "\\Microsoft\\Windows\\CurrentVersion\\RunOnce" OR "\\Microsoft\\Windows\\CurrentVersion\\RunServices" OR "\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce")

Рис.11. Изменение процессом Microsoft Excel ключа реестра, отвечающего за автозагрузку

Результаты выполненного запроса показали, что процессом C:\Program Files (x86)\Microsoft Office\Office16\excel.exe в ключе реестра HKU\S-1-5-21-3921924719-2751751025-4067464375-1003\Software\Microsoft\Windows\CurrentVersion\Run было создано значение userprep с содержимым rundll32 C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll,#0.

Обратите внимание, что для обнаружения подобной активности может быть использовано как событие Sysmon Event ID 13, так и аудит событий безопасности ОС Windows (Event ID 4657). Чтобы событие Windows начало генерироваться, предварительно необходимо установить SACL (System Access Control List) на соответствующие ключи реестра.

Подводим итоги

Использованные нами подходы к Threat Hunting позволили обнаружить вредоносную активность на всех этапах инцидента. Особенно эффективными оказались гипотезы, сформулированные в соответствии с подходом TTPs-based.

Однако применение исключительно ручного подхода для отработки гипотез не всегда рационально и требует много времени. Чтобы повысить эффективность Threat Hunting, каждое упражнение по отработке гипотезы должно заканчиваться анализом на предмет возможной автоматизации и разработки детектирующего правила. Такая организация процесса позволит существенно сократить dwell time и сэкономить время команды охотников.

Ниже представлена итоговая таблица с правилами, разработанными на основе наших гипотез, требуемой телеметрией, а также их маппингом в тактики и техники матрицы MITRE ATT&CK.

Название правила	Техника MITRE	Текст запроса	Требуемая телеметрия
Подключение к вредоносному хосту от процесса офисного приложения	T1071 — Standard Application Layer Protocol T1043 — Commonly Used Port	event_type:NetworkConnection AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND (enrich.ti.net_dst_ipv4.categories:Malware OR enrich.ti.net_src_ipv4.categories:Malware)	Windows Security Event ID 5156 Sysmon Event ID 3 Интеграция с Threat Intelligence
Создание исполняемого файла офисным приложением	T1105 — Remote File Copy T1204 — User Execution	event_type:FileCreate AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND file_path.keyword:(.exe OR .dll OR .cpl OR .msi OR *.sys)	Sysmon Event ID 11
Запуск командного интерпретатора cmd офисным приложением	T1059 — Command-line interfaces T1204 — User Execution	event_type:ProcessCreate AND proc_p_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND (proc_file_path:"\\cmd.exe" OR cmdline:(cmd.exe "cmd "))	Windows Security Event ID 4688 Sysmon Event ID 1
Использование rundll32 для вызова функции dll-библиотеки по порядковому номеру	T10865 — rundll32	proc_file_path:"\\rundll32.exe" AND cmdline.keyword:/.*\#[0-9]+/	Windows Security Event ID 4688 Sysmon Event ID 1
Изменение офисным приложением ключа реестра, отвечающего за автозагрузку	T1060 — Registry Run Keys / Startup Folder T1204 — User Execution	event_type:RegistryValueSet AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND reg_key_path:("\\Microsoft\\Windows\\CurrentVersion\\Run" OR "\\Microsoft\\Windows\\CurrentVersion\\RunOnce" OR "\\Microsoft\\Windows\\CurrentVersion\\RunServices" OR "\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce")	Windows Security Event ID 4657 Sysmon Event ID 13

Заключение

Примерно так выглядит Threat Hunting в действии.

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

В то же время с развитием решений класса EDR (Endpoint Detection and Response) приемы атакующих становятся все более изощренными и зачастую позволяют им обходить правила детектирования, использующие штатные возможности аудита операционной системы и бесплатных инструментов. Обнаружение таких техник требует уже более продвинутой телеметрии и специальных инструментов, о чем мы и поговорим в нашей следующей статье.