Threat Hunting в действии
Описание инцидента
В результате фишинговой атаки ничего не подозревающий пользователь открывает вложение к письму — документ Microsoft Excel с интересным названием Annual_Salary_Bonuses.xlsm. Файл содержит вредоносный макрос, который, обманом получив у пользователя разрешение на запуск, выполняет следующую последовательность действий (рис. 1):
- подключается к серверу управления атакующего и скачивает файл viewpage.php, содержащий полезную нагрузку — meterpreter 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 Authority Server Service) завершается неудачей, так как скрипт Invoke-Mimikatz.ps1 содержит в себе не работающую на машине пользователя версию утилиты Mimikatz. Поэтому атакующий загружает на компьютер пользователя последнюю версию утилиты Mimikatz в виде исполняемого PE-файла и сохраняет его в каталоге c:\Users\vadmin\Documents\ с именем m.exe. После запуска этого файла атакующий крадет учетные данные из оперативной памяти.
Рис. 1. Последовательность событий атаки
Формирование гипотез
Мы получили представление о последовательности действий, выполненных атакующим. Теперь посмотрим, как охотники могут обнаружить этот инцидент, используя каждый из трех подходов, о которых мы рассказывали в предыдущей статье.
Как правило, все начинается с зацепки, которую охотник получил в результате отработки первичной гипотезы. Найденная зацепка позволяет «раскрутить» весь инцидент по цепочке и восстановить его полную картину. В качестве первичной может быть использована гипотеза, сформированная с использованием одного из трех подходов: IoC-, Tool- или TTPs-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. Также мы видим ряд подключений процессом rundll32.exe. В результате проверки гипотезы инцидент был обнаружен.
Помимо IP-адреса, для обнаружения нашего инцидента могут быть использованы
и другие индикаторы, например файлы sysprov32.dll, Annual_Salary_Bonuses.xlsm или значение реестра userprep. Однако
атакующий может легко изменить все перечисленные индикаторы, что позволит ему избежать
обнаружения подходом IoC-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 направлен на детектирование тактик, техник и процедур атакующего, или, иными словами, его поведенческих паттернов. Поэтому при использовании охотниками этого подхода злоумышленнику будет сложнее всего избежать обнаружения.
Давайте еще раз посмотрим на схему инцидента и сгенерируем ряд гипотез, которые помогут его обнаружить на различных этапах.
Для отработки гипотезы нам понадобится интеграция с источником 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-адресу. А этот факт сам по себе заслуживает внимания и требует тщательного анализа.
Атакующие зачастую используют вредоносные макросы в составе документов в качестве легковесного кода, предназначенного для доставки основной полезной нагрузки с сервера управления. В таком случае процесс офисного приложения может сохранить в файловой системе файл с полезной нагрузкой для его последующего запуска. Если атакующий не замаскировал расширение файла под более безобидное, мы можем использовать событие 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.
Однако в тех случаях, когда файл с полезной нагрузкой будет иметь более безобидное расширение, наш запрос не вернет никаких результатов.
В основе этой гипотезы лежит популярная техника детектирования аномалий в паре «родительский процесс — дочерний процесс». Для ее использования необходимо хорошо знать целевую операционную систему и то, какие пары «родительский процесс — дочерний процесс» являются для нее нормальными.
Запуск процессом офисного приложения командного интерпретатора 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.
Для исполнения полезной нагрузки, содержащейся в файле 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.
Когда пользователь открыл вредоносный документ, атакующий получил удаленный доступ к компьютеру пользователя. Однако такой доступ не вечен и будет потерян при первой перезагрузке системы.
Для сохранения доступа после перезагрузки атакующие используют различные техники закрепления в системе (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 ATT&CK | Текст запроса | Требуемая телеметрия |
|---|---|---|---|
| Подключение к вредоносному хосту от процесса офисного приложения | 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 4688 Sysmon Event ID 1 |
Заключение
Примерно так выглядит Threat Hunting в действии.
Стоит отметить, что в нашем примере техники атакующего довольно простые — для их детектирования будет достаточно правильно настроенных штатных возможностей операционной системы или бесплатных инструментов. При этом даже такие простые техники часто встречаются в реальных инцидентах, включая и таргетированные атаки.
В то же время с развитием решений класса EDR (Endpoint Detection and Response) приемы атакующих становятся все более изощренными и зачастую позволяют им обходить правила детектирования, использующие штатные возможности аудита операционной системы и бесплатных инструментов. Обнаружение таких техник требует уже более продвинутой телеметрии и специальных инструментов, о чем мы и поговорим в нашей следующей статье.