Threat Hunting. Охота на продвинутые тактики и техники атакующих

Введение

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

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

Вспоминая прошлый инцидент

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

Рис. 1. Схема исходного инцидента

Данный инцидент можно разбить на 4 этапа:

Первичная компрометация и доставка вредоносного кода на скомпрометированный хост — шаги 1–3.
Исполнение доставленного вредоносного кода — шаг 4.
Закрепление атакующего в системе для обеспечения себе доступа даже в случае перезагрузки скомпрометированного хоста — шаг 5.
И наконец, — постэксплуатация, которая включает в себя подключение атакующего к скомпрометированному хосту (6), дамп учетных данных пользователей из базы SAM (7) и памяти процесса LSASS (8) с использованием утилиты Mimikatz.

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

Первичная компрометация и доставка вредоносного кода (Initial Access)

Модификация этапа инцидента

В предыдущем инциденте в качестве вектора первичной компрометации использовалось фишинговое письмо с документом Microsoft Excel, содержащим вредоносный макрос. Пользователь открыл документ и разрешил выполнение макроса. В свою очередь макрос загрузил с подконтрольного атакующему командного центра исполняемый файл с основной полезной нагрузкой (DLL-библиотека Reverse Shell-а) и сохранил его в каталоге временных файлов под именем sysprov32.dll. При этом адрес командного центра, с которого была выполнена загрузка файла, на момент инцидента уже был известен сообществу специалистов по кибербезопасности и фигурировал во множестве источников Threat Intelligence как вредоносный.

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

обращение процесса приложения Microsoft Office к адресу, который фигурирует в используемых источниках Threat Intelligence как вредоносный;
взаимодействия процесса приложения Microsoft Office с внешними адресами;
создание процессом приложения Microsoft Office файла с исполняемым расширением.

Давайте теперь модифицируем данный этап инцидента, сделав невозможным использование выше приведенных паттернов. Способ доставки вредоносного документа мы оставим без изменений — это все также будет электронная почта. Однако вместо Excel-документа в этот раз мы используем документ Microsoft Word (хотя это и не особо принципиально), также содержащий вредоносный макрос, но с измененным кодом.

Изменим шаг 3 — загрузку исполняемого файла с ресурса, который, по данным источников Threat Intelligence, является вредоносным. Вместо непосредственно контролируемого атакующим выделенного сервера, адрес которого может достаточно быстро попасть в различные черные списки, атакующий может использовать в качестве командного центра какой-либо из широко известных интернет-сервисов типа Twitter, Gmail, Github, Dropbox и так далее. В матрице атак MITRE ATT&CK соответствующая техника имеет номер T1102 и называется Web Service. Ее использование позволяет скрыть сетевые коммуникации атакующего и избежать детектирования на базе черных списков адресов, так как адреса серверов широко известных сервисов не попадают в эти самые черные списки. Конечно, у атакующего остается риск того, что владельцы подобного сервиса могут на периодической основе выполнять проверку всего загружаемого контента на вредоносность или удалять подобный контент на основании жалоб пользователей. Однако, как правило, это не происходит моментально, а соответственно у атакующего, скорее всего, будет достаточно времени для достижения своих целей, пока владельцы публичного сервиса доберутся до вредоносного контента.

Для нашего инцидента мы заменим загрузку исполняемого файла с контролируемого атакующим сервера, адрес которого присутствует во многих источника Threat Intelligence, на загрузку с сервиса pastebin.com. При этом, так как данный сервис предназначен для публикации текстовых данных, нам необходимо конвертировать DLL-библиотеку с Reverse Shell в некоторое текстовое представление. Для этого отлично подходит алгоритм кодирования Base64. Ниже на рис. 2 — пример загруженного на Pastebin исполняемого файла, закодированного с использованием Base64.

Рис. 2. Загруженный на Pastebin исполняемый файл, закодированный с использованием алгоритма Base64

Pastebin позволяет получить загруженные данные по сгенерированной прямой ссылке. Таким образом, атакующий может использовать данную ссылку для загрузки Base64-строки, далее выполнить ее декодирование и сохранить полученный исполняемый файл на диск для его дальнейшего запуска. Все это, безусловно, возможно выполнить непосредственно из макроса. Однако у опытного аналитика взаимодействие процесса приложения Microsoft Office с серверами pastebin.com может вызвать подозрение, так как это крайне нетипичная для данных приложений активность.

И тут мы плавно подошли ко второму паттерну, использованному для детектирования нашего прошлого инцидента — «взаимодействия процесса приложения Microsoft Office с внешними адресами». Для обхода соответствующего детекта атакующему нужно каким-то образом либо скрыть сетевое взаимодействие приложения MS Office с сервисом Pastebin, либо выполнить это взаимодействие от имени другого процесса, для которого это уже не является аномальным. Соответственно, вряд ли на эту активность обратят внимание аналитики. И здесь операционная система Windows предоставляет атакующим замечательную возможность в виде COM-объекта браузера Internet Explorer. Данный COM-объект реализован как DLL-библиотека C:\Windows\System32\ieproxy.dll, которая при загрузке в адресное пространство клиентского процесса позволяет выполнять взаимодействие с интернет-ресурсами, в том числе и загрузку файлов от имени процесса браузера Internet Explorer. Иными словами, для средств мониторинга на конечных точках сетевая активность, которую инициировало клиентское приложение (например, из макроса документа Microsoft Office), будет исходить от имени процесса браузера Internet Explorer (C:\Program Files (x86)\Internet Explorer\iexplore.exe), а не от клиентского приложения, использующего соответствующий COM-объект. Таким образом, в модифицированном инциденте для загрузки закодированного с помощью base64-файла с полезной нагрузкой наш вымышленный атакующий воспользуется описанным COM-объектом.

Загруженная c Pastebin base64-строка должна быть декодирована, для чего в макрос добавлена соответствующая функция. Возвращенный данной функцией результат в виде байтового массива исполняемого PE-файла необходимо сохранить на диск для его дальнейшего использования. Давайте посмотрим, как можно сделать это незаметно. Будем учитывать, что штатный аудит WIndows, Sysmon, а также многие коммерческие EDR-решения не содержат в своих событиях создания/изменения файлов информации о типе файла, что дает аналитикам возможность оперировать только лишь расширением в качестве признака «исполняемоcти». Зная это, злоумышленник может выполнить сохранение загруженного исполняемого файла без исполняемого расширения (в нашем случае без .dll) под именем и в каталоге, типичных для соответствующего приложения (например, файл с расширением dotm в каталоге шаблонов C:\Users\user_name\AppData\Roaming\Microsoft\Templates). Тем самым атакующий обойдет детектирующее правило, которое выявляет создание приложением MS Office файла с исполняемым расширением.

В результате применения описанных изменений модифицированный вымышленным атакующим этап первичной компрометации будет выглядеть следующим образом (рис. 3):

Рис. 3. Модификация этапа первичной компрометации и доставки вредоносного кода (Initial Access)

Детектирование модифицированного этапа

Теперь давайте посмотрим, как могут быть детектированы техники модифицированного этапа первичной компрометации и доставки вредоносного кода. Для этого выдвинем несколько гипотез и попытаемся найти их подтверждение в имеющихся в нашем распоряжении событиях от Sysmon и EDR-решения BI.ZONE SENSORS.

Гипотеза 1: Атакующий может использовать в скриптах или макросах COM-объект браузера Internet Explorer для взаимодействия с интернет-ресурсами

COM-объект браузера Internet Explorer представляет собой DLL-библиотеку, расположенную по пути C:\Windows\System32\ieproxy.dll. Чтобы использовать данный COM-объект клиентским приложением (например, из макроса), соответствующая библиотека должна быть загружена в адресное пространство приложения. Загрузка данной библиотеки нетипичным приложением (например, приложениями Microsoft Office или скриптовыми интерпретаторами) может указывать на попытку атакующего использовать соответствующую технику. Таким образом, указанный паттерн может быть использован для проверки нашей первой гипотезы. При этом здесь нам понадобятся события загрузки процессами DLL-библиотек. К сожалению, штатные возможности по аудиту событий операционной системы Windows тут не помогут. Необходимые нам события могут быть получены либо от Sysmon, либо от агента EDR.

Выполним следующий запрос для проверки нашей первой гипотезы (рис. 4):

event_type:ImageLoad AND file_path:"*\\ieproxy.dll" AND proc_file_path:("\\cscript.exe" OR "\\wscript.exe" OR "\\powershell.exe" OR "\\winword.exe" OR "\\excel.exe" "\\powerpnt.exe" OR "\\mspub.exe" OR "\\visio.exe" OR "\\msaccess.exe" OR "\\regsvr32.exe")

Рис. 4. Детектирование по событиям EDR/Sysmon загрузки DLL-библиотеки COM-объекта браузера Internet Explorer нетипичным процессом

Результат выполненного запроса показал нам, что на хосте codered.shockwave.local процесс Microsoft Word выполнил загрузку DLL-библиотеки ieproxy.dll, что потенциально может указывать на попытку использования COM-объекта браузера Internet Explorer из макроса.

Гипотеза 2: Атакующий может использовать paste-сервисы (pastebin.com, gist.github.com и т.п.) в качестве командного центра

В модифицированном нами инциденте мы заменили использованный ранее атакующим командный центр, адрес которого упоминается в различных источниках Threat Intelligence как вредоносный, на легитимный веб-сервис pastebin.com. Атакующий может размещать на данном сервисе в виде текстовых сниппетов отдельные команды и даже исполняемые файлы целиком. Для выявления в инфраструктуре вредоносного программного обеспечения, использующего paste-сервисы в качестве командного центра, конечно, можно попытаться анализировать весь исходящий из корпоративной сети трафик к данным сервисам. Однако в крупной инфраструктуре такого трафика может быть слишком много.

Чтобы сузить выборку событий до приемлемого для анализа объема, потребуется использовать дополнительные фильтры. Так, например, при наличии событий на DNS-запросы от процессов мы можем выбрать все попытки резолва доменных имен известных paste-сервисов не браузерными процессами. Однако в этом случае мы отфильтруем запросы к данным сервисам, инициированные с использованием COM-объекта браузера Internet Explorer, так как такие запросы будут как раз исходить от процесса браузера Internet Explorer. Чтобы этого избежать, нам необходимо немного скорректировать предложенный поисковый паттерн на следующий: попытки резолва доменных имен известных paste-сервисов не браузерными процессами, а также COM-объектами браузеров. Иными словами, нам необходимо отобрать все DNS-запросы на резолв имен соответствующих сервисов, вызванные НЕ действиями пользователя.

У внимательного читателя тут может возникнуть вопрос: а как мы можем отличить DNS-запросы, инициированные внешним приложением, использующим COM-объект браузера для взаимодействия с интернетом, от DNS-запросов, вызванных серфингом пользователя по интернет-пространству с использованием того же самого браузера? Ведь в обоих приведенных случаях в качестве процесса, инициировавшего запрос, будет значится процесс браузера. Здесь на помощь нам приходит обогащение события DNS-запроса информацией о родительском процессе, а если быть точнее — командной строкой родительского процесса. Так, в случае использования COM-объекта браузера Internet Explorer родителем процесса Internet Explorer (iexplore.exe) будет также процесс с аналогичным исполняемым файлом, но содержащий в командной строке аргумент -Embedding. Это и является признаком использования COM-объекта (это, кстати, справедливо не только для Internet Explorer, но и для многих других приложений Microsoft).

Ниже представлен пример события EDR на DNS-запрос, инициированный вследствие взаимодействия с интернет-ресурсами с использованием COM-объекта браузера Internet Explorer (рис. 5).

Рис. 5. Пример события на DNS-запрос, инициированный вследствие взаимодействия с интернет-ресурсами с использованием COM-объекта браузера Internet Explorer

Теперь мы обладаем всей необходимой информацией, чтобы сформировать поисковый запрос для проверки нашей второй гипотезы (рис. 6).

event_type:DNSReq AND
dns_rname:("pastebin.com" OR "gist.githubusercontent.com" OR "raw.githubusercontent.com") AND
(
(-proc_file_path:("\\firefox.exe" OR "\\iexplore.exe" OR "\\application\\browser.exe" OR "\\chrome.exe" OR "\\amigo.exe" OR "\\opera.exe" OR "\\microsoftedgecp.exe" OR "\\microsoftedge.exe" OR  "\\vivaldi.exe" OR "\\safari.exe" OR "\\ieuser.exe" OR "\\qqbrowser.exe" OR "\\spartan.exe" OR "\\spartan_edge.exe" OR "\\spartan_legacy.exe" OR "\\ucbrowser.exe" OR "\\qqbrowser.exe" OR "\\sogouexplorer.exe" OR "\\icedragon.exe" OR "\\maxthon.exe" OR "\\waterfox.exe")) OR
(proc_file_path:"\\iexplore.exe" AND proc_p_file_path:"\\iexplore.exe" AND proc_p_cmdline:*Embedding*)
)

Рис. 6. Доступ к Paste-сервисам (pastebin и т.п.) не от браузеров, а также от браузерных COM-объектов

Как мы можем видеть, из результата выполнения нашего запроса на хосте codered.shockwave.local предположительно осуществлялось взаимодействие с сервисом pastebin.com через COM-объект браузера Internet Explorer. В совокупности с результатом проверки предыдущей гипотезы мы можем сделать вывод, что исходным процессом, выполнявшим взаимодействие с сервисом pastebin.com, является процесс приложения Microsoft Word.

Гипотеза 3: Атакующий может загрузить в систему исполняемый файл и выполнить его сохранение без исполняемого расширения

Данные, загружаемые в модифицированном инциденте процессом Microsoft Word с pastebin.com, представляют собой закодированный с использованием base64 PE-файл. Выполнив декодирование этих данных, процесс MS Word сохраняет получившийся PE-файл на диск без исполняемого расширения. Это позволяет обойти наше предыдущее детектирующее правило, выявляющее создание процессами приложений Microsoft Office файлов с исполняемыми или скриптовыми расширениями. В случае отсутствия такового расширения единственный способ понять, что сохраняемый файл является исполняемым — это анализировать первые несколько байт в начале файла.

Все PE-файлы начинаются с так называемого MZ-заголовка, который представляет собой ASCII-строку MZ (4D5A в HEX-представлении). Этот заголовок может быть использован для детектирования создания исполняемых файлов, даже когда у файла нет исполняемого расширения. К сожалению, ни штатный аудит Windows, ни Sysmon не осуществляют такой проверки для событий на файловые операции, поэтому мы не можем их использовать для проверки выдвинутой гипотезы. В то же время некоторые коммерческие EDR-решения это делать умеют. Ниже (рис. 7) представлен запрос над событиями используемого нами EDR-решения (BI.ZONE SENSORS), выполняющий выборку событий создания исполняемых файлов приложениями Microsoft Office, в том числе и без исполняемых расширений (по полю file_magic, содержащему первые несколько байт с начала файла).

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 OR *.scr) OR file_magic:4D5A*)

Рис. 7. Детектирования по событиям EDR создания исполняемых файлов без исполняемых расширений

Запрос нам вернул одно событие, указывающие на создание на хосте codered.shockwave.local файла под видом шаблона Microsoft Word, который на самом деле является исполняемым PE-файлом, на что нам указывает содержимое поля file_magic: файл начинается с MZ-заголовка (4D5A).

Для выбора обнаруженного приведенным запросом события можно также использовать еще один — создание файла, который начинается с MZ-заголовка, но не имеет исполняемого расширения:

event_type:FileCreate AND file_magic:4D5A* AND -file_path.keyword:(*.msi OR *.ocx OR *.cpl OR *.ax OR *.sys OR *.scr OR *.com OR *.vxd OR *.dll OR *drv OR *.exe OR *.pif)

Наличие в событиях создания/изменения файла так называемого Magic-а (первые несколько байт с начала файла) существенно увеличивает область применения данных событий и позволяют находить интересные файловые операции, не только оперируя именами и расширениями, но и известными сигнатурами файлов различных типов.

Гипотеза 4: Атакующий может использовать документы с макросами для первичной компрометации инфраструктуры

В наших предыдущих гипотезах мы делали предположение, что выявляемая в результате их проверки активность, скорее всего, была инициирована из макроса. Давайте теперь попробуем убедиться в этом. Каждый раз, когда в открытом приложением Microsoft Office документе пользователь разрешает выполнение макросов, соответствующий процесс приложения выполняет загрузку DLL-библиотеки VBE7.DLL. Данный поведенческий паттерн является довольно надежным признаком того, что документ содержит макрос, выполнение которого разрешил пользователь. Давайте сформируем на базе этого признака поисковый запрос для проверки нашей гипотезы (рис. 8).

event_type:ImageLoad AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe" OR "\\msaccess.exe" OR "\\mspub.exe" OR "\\outlook.exe") AND file_path:"\\VBE7.DLL"

Рис. 8. Событие, указывающее на разрешенный пользователем запуск макроса в документе Microsoft Word

Наша гипотеза подтвердилась, — действительно, вся выявленная нами активность была инициирована вредоносным макросом.

На этом закончим с этапом первичной компрометации и доставки вредоносного кода и перейдем к этапу непосредственного запуска доставленного кода.

Выполнение вредоносного кода (Execution)

Модификация этапа инцидента

Загруженный c Pastebin код, декодированный и сохраненный без исполняемого расширения под видом шаблона MS Office, нашему вымышленному атакующему необходимо каким-либо образом выполнить в системе. В прошлый раз мы использовали для этого штатную утилиту rundll32. В качестве параметров командной строки мы передавали ей путь к загруженной библиотеке и порядковый номер функции, которую необходимо было вызвать из библиотеки. Последнее (вызов функции по порядковому номеру) мы использовали для детектирования соответствующего этапа, поскольку утилита rundll32 крайне редко используется таким образом в легитимных целях. Кроме того, запуск утилиты rundll32 мы производили из консоли cmd, запущенной прямо из макроса, что также использовали как паттерн для детектирования — запуск консольного интерпретатора приложением MS Office.

Сейчас давайте попробуем обойти разработанные в прошлый раз детектирующие правила. Начнем с утилиты rundll32, которую в модифицированном инциденте мы также будем использовать для запуска кода из загруженной DLL-библиотеки, однако немного другим способом — через технику COM Hijacking (T1122). Непосредственно из макроса, используя утилиту reg.exe и функцию восстановления ключа/ветки реестра (Restore, подробнее об этом — в следующем разделе), в системе регистрируется новый COM-объект, в качестве DLL-библиотеки которого указывается библиотека, полученная в результате декодирования загруженного с pastebin.com кода (рис. 9).

Рис. 9. Регистрация в реестре COM-объекта с CLSID {018D5C66-4533-4307-9B53-224DE2ED1FE7}

После регистрации COM-объекта запуск кода из соответствующей библиотеки может быть осуществлен с использованием малоизвестного параметра -sta командной строки утилиты rundll32.exe. Вместе с данным параметром необходимо указать GUID COM-объекта. В результате rundll32.exe осуществит загрузку в память DLL-библиотеки соответствующего COM-объекта и передаст в нее управление по точке входа DLL_PROCESS_ATTACH. Пример соответствующей командной строки rundll32.exe — rundll32 -sta {018D5C66-4533-4307-9B53-224DE2ED1FE7}.

Однако, если запуск rundll32 будет осуществляться непосредственно процессом приложения Microsoft Office, это будет крайне подозрительно и может заинтересовать дотошного аналитика. Давайте разрушим данную связь «родитель — потомок», воспользовавшись техникой Parent PID Spoofing (T1502). Начиная с WIndows Vista, операционная система дает возможность в функции CreateProcess указать handle процесса, который будет выступать в качестве родителя запускаемого дочернего процесса. То есть в данном случае родителем запущенного процесса будет в итоге не тот процесс, который непосредственно вызвал CreateProcess, а тот, handle которого был указан в одном из параметров функции CreateProcess. Данная техника позволяет обходить детектирующие правила, основанные на аномалиях «родитель — потомок», так как штатные возможности аудита Windows, Sysmon, а также ряд EDR-решений не позволяют установить истинного инициатора запуска процесса. В нашем инциденте мы используем данную технику для сокрытия того, что истинным инициатором запуска rundll32 является процесс Microsoft Word.

Мы пойдем немного дальше и попытаемся сделать запуск rundll32 максимально правдоподобным, чтобы даже самый дотошный аналитик не обратил на него внимание. Для этого мы подделаем не только родительский процесс, но и командную строку, воспользовавшись техникой Command Line Spoofing, — она позволяет скрыть для инструментов мониторинга реальную командную строку, использованную для запуска процесса. Таким образом, комбинируя в модифицированном инциденте вместе Parent Process Spoofing и Command Line Spoofing, мы запустим из макроса утилиту rundll32, которая приведет к выполнению нашего вредоносного кода. При этом для инструментов мониторинга данный запуск будет выглядеть максимально правдоподобно. Ниже на рис. 10 представлен пример событий штатного аудита Windows (сверху) и Sysmon (снизу), сгенерированных в результате применения комбинации описанных техник спуфинга.

Рис.10. Пример событий Windows и Sysmon на запуск процесса со спуфингом командной строки и родительского процесса

Ничего подозрительного даже для самого опытного аналитика в данных событиях нет. Все выглядит как абсолютной легитимный запуск оснастки управления настройками экранной заставки, хотя на самом деле процесс Microsoft Word осуществил запуск вредоносного кода командой rundll32 -sta {018D5C66-4533-4307-9B53-224DE2ED1FE7}.

В результате применения описанных техник этап исполнения вредоносного кода нашего модифицированного инцидента будет выглядеть следующим образом (рис. 11):

Рис. 11. Модификация этапа выполнения вредоносного кода (Execution)

Детектирование модифицированного этапа

Несмотря на кажущуюся сложность выявления примененных нами техник обхода, все же это возможно. Операционная система предоставляет возможность получения информации об истинном инициаторе запуска процесса. Соответственно, если используемое для мониторинга конечных точек решение умеет извлекать данную информацию, то оно может поставлять ее в событиях старта процесса. Что же касается спуфинга командной строки, то здесь все немного сложнее, но тем не менее возможно выявлять и эту технику. Для этого необходимо отслеживать модификацию PEB-процессов (Process Environment Block), запускаемых в Suspended-состоянии.

Гипотеза 5: Для обхода детектов, основанных на аномалиях «родитель — потомок», атакующий может использовать технику Parent PID Spoofing

Используемое в нашей демонстрации EDR-решение умеет получать информацию об истинном инициаторе запуска процесса. При этом в большинстве случаев инициатор запуска процесса совпадает с его родителем. Поэтому в целях экономии ресурсов атрибуты процесса-инициатора (CreatorProcess...) заполняются в событии старта процесса только в том случае, если инициатор запуска процесса (CreatorProcess) отличается от родителя процесса (ParentProcess). Ниже представлен пример такого события (рис.12).

Рис. 12. Пример события EDR на запуск процесса со спуфингом командной строки и родительского процесса

Теперь, когда мы знаем особенность событий создания процессов используемого нами EDR-решения, давайте попробуем составить поисковый запрос для проверки нашей гипотезы. Нам необходимо выбрать события запуска процессов с не пустыми полями атрибутов процесса-инициатора (начинающиеся с CreatorProcess..., которые в используемой нами модели данных индексируются в поля, начинающиеся с proc_c_...), исключая те процессы, для которых это является нормальным (запуск с повышением через UAC, запуск от имени другого пользователя, активность процесса WerFault и другие) (рис. 13).

event_type:ProcessCreate AND proc_c_file_path:* AND proc_p_file_path:* AND -proc_file_path:"\\WerFault.exe" AND -(proc_c_file_path:"\\system32\\svchost.exe" AND proc_c_cmdline:(*seclogo* *appinfo* * netsvcs*))

Рис. 13. Детектирование по событиям EDR процессов, запущенных со спуфингом родителя

Наш запрос вернул одно событие, соответствующее запуску штатной утилиты rundll32 с родительским процессом Explorer.exe. Однако истинным инициатором данного запуска является процесс приложения Microsoft Word, использованного для открытия вредоносного документа.

Закрепление в скомпрометированной системе (Persistence)

Модификация этапа инцидента

В исходном инциденте для закрепления в скомпрометированной системе атакующий создал новое значение в ключе реестра Run. Модификация данного значения производилась непосредственно из вредоносного макроса, что мы и использовали для детектирования — крайне подозрительно, когда процесс приложения Microsoft Office выполняет изменение данных значения ключа реестра Run.

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

Используем одновременно оба приема. Вместо модификации реестра напрямую из макроса мы воспользуемся утилитой reg.exe, для которой внесение изменений в реестр является штатным функционалом. Однако это может быть крайне подозрительно, когда процесс приложения Microsoft Office является родителем процесса reg.exe. Для нарушения данной связи «родитель — потомок» мы воспользуемся еще одной техникой — запуском процесса из макроса через механизм WMI. В случае использования данного механизма запускаемый процесс утилиты reg.exe будет иметь в качестве родителя не процесс приложения Microsoft Office, а системный процесс wmiprvse.exe, что, собственно, и нарушает связь «родитель — потомок». Ниже (рис. 14) приведены примеры соответствующих событий запуска процесса из журнала Security (сверху) и Sysmon (снизу).

Рис. 14. Пример событий Windows и Sysmon на запуск процесса через WMI

Данные события соответствуют запуску утилиты reg.exe через механизм WMI, инициированному из макроса документа Microsoft Word. Как видно из событий, в них нет ничего, что бы указывало на процесс Microsoft Word, а соответственно связь «родитель — потомок» нарушена.

Теперь давайте посмотрим, как мы можем прописать новое значение автозапуска в ключ Run незаметно для мониторинга. Вместо изменения значения ключа реестра с использованием функций RegSetValueA/RegSetValueW/RegSetValueExA/RegSetValueExW, которые контролируются аудитом операционной системы, Sysmon и практически всеми существующими EDR-решениями, можно использовать менее типичные для данной операции функции RegRestoreKeyA/RegRestoreKeyW/RegReplaceKeyA/RegReplaceKeyW/RegLoadKeyA/RegLoadKeyW, которые также позволяют изменить значение ключа реестра.

Как вы уже, наверное, могли заметить на примере представленных выше событий, в нашем случае мы выполним модификацию реестра с использованием RegRestore. Она позволяет восстановить целый ключ или даже куст реестра со всеми значениями из файла. При этом для экономии времени мы воспользуемся утилитой reg.exe вместо разработки своего кода данной операции.

Тут опытный читатель мог бы отметить, что в целом запуск через WMI утилиты reg.exe, содержащей в командной строке упоминания ключа реестра *\Windows\CurrentVersion\Run, сам по себе является очень подозрительным и может быть детектирован по нативным событиям старта процессов операционной системы. Да, это действительно так, однако еще раз отметим, что использовали утилиту reg.exe исключительно для экономии времени. В реальном же инциденте вместо нее можно бы было напрямую восстановить значение ключа реестра Run из макроса без вызова дополнительных утилит, что не оставило бы в штатных логах Windows и логах Sysmon следов в виде событий старта процесса reg.exe и модификации ключа Run, так как, к сожалению, данные инструменты не позволяют отслеживать использование функций RegRestoreKeyA/RegRestoreKeyW.

Таким образом, модифицированный этап закрепления в систему выглядит следующим образом: используя COM-объект браузера Internet Explorer на скомпрометированный хост, осуществляется загрузка файла-экспорта ключа реестра и его сохранение под именем NormalMail.dotm в каталоге шаблонов приложений Microsoft Office. Данный файл содержит предустановленные атакующим значения для записи в ключ Run. Кроме того, данный файл также используется и для прописывания в реестр COM-объекта, необходимого на описанном ранее этапе исполнения вредоносного кода. Восстановление значений ключей реестра из данного файла осуществляется с использованием утилиты reg.exe, запускаемой макросом через WMI.

В результате применения описанных изменений схема модифицированного вымышленным атакующим инцидента будет теперь выглядеть следующим образом (рис. 15):

Рис. 15. Модификация этапа закрепления атакующего в скомпрометированной системе (Persistence)

Детектирование модифицированного этапа

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

Гипотеза 6: Для модификации ключей реестра атакующий может использовать нестандартные функции RegRestoreKeyA / RegRestoreKeyW / RegReplaceKeyA / RegReplaceKeyW / RegLoadKeyA / RegLoadKeyW / RegRenameKey

Для проверки данной гипотезы нам потребуются события от EDR-решения, которое позволяет контролировать использование обозначенных функций. Ниже представлен пример одного из таких событий (рис. 16).

Рис. 16. Пример события EDR на восстановление содержимого ключа реестра с использованием API RegRestoreKey

Теперь давайте сформируем запрос для нашей платформы Threat Hunting, который позволит подтвердить или опровергнуть нашу гипотезу (рис. 17):

event_type:(RegistryRestore OR RegistryLoad OR RegistryReplace OR RegistryRename) AND reg_key_path:("\\Microsoft\\Windows\\CurrentVersion\\Run" OR "\\Microsoft\\Windows\\CurrentVersion\\RunOnce" OR "\\InprocServer32" OR "\\Windows NT\\CurrentVersion\\Windows" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\GPExtensions\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Notify\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\WOW\\Boot\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Run" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load" OR "\\CurrentControlSet\\services\\" OR "\\ControlSet001\\services\\" OR "\\ControlSet002\\services\\" OR "\\ControlSet003\\services\\" OR "\\Control\\Lsa" OR "\\Control\\SecurityProviders" OR "\\Control\\Print\\Monitors\\" OR "\\Control\\Session Manager" OR "\\Microsoft\\NetSh" OR "\\Scripts\\Logon\\" OR "\\Scripts\\Logoff\\" OR "\\Scripts\\Startup\\" OR "\\Scripts\\Shutdown\\")

Рис. 17. Детектирование по событиям EDR-изменений, отвечающих за автозагрузку ключей реестра с помощью нестандартных функций (RegRestoreKey/RegReplaceKey/RegLoadKey/RegRenameKey)

Как мы можем видеть, запрос позволил выявить модификацию ключа Run и регистрацию COM-объекта с использованием RegRestore. Наша гипотеза подтвердилась!

Гипотеза 7: Для нарушения связи «родитель — потомок» вредоносный макрос из документа Microsoft Office может запускать процессы с использованием механизма WMI

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

Давайте теперь посмотрим, как соответствующая активность может быть выявлена. Для этого нам понадобится источник, который поставляет события на WMI-команды, выполняемые процессами. Этом может быть как EDR, так и штатный аудит событий Windows, в лице журнала Microsoft-Windows-WMI-Activity/Debug, который предварительно необходимо разрешить.

Пример запроса для отработки нашей гипотезы на платформе Threat Hunting и его результаты представлены ниже (рис. 18).

event_type:WMICommand AND wmi_command:"*Win32_Process::Create*" AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe" OR "\\mspub.exe" OR "\\visio.exe" OR "\\msaccess.exe")

Рис. 18. Детектирование по событиям EDR попыток запуска приложением MS Office исполняемых файлов через WMI

Постэксплуатация (Postexploitation)

Модификация этапа инцидента

И наконец, этап постэксплуатации, на котором в нашем прошлом инциденте атакующий использовал утилиту Mimikatz как в бинарном виде, так и ее PowerShell-версию Invoke-Mimikatz для дампа учетных данных пользователей из базы SAM и памяти процесса LSASS. Данные утилиты широко известны и детектируются большинством антивирусных вендоров. Их использование без какой-либо модификации является не самым лучшим решением, если атакующий хоть немного заботится о сокрытии своего присутствия в скомпрометированной системе.

В прошлый раз мы детектировали использование Mimikatz по характерным командным строкам и именам PowerShell-функций/-скриплетов. В этот же раз давайте обойдемся вообще без использования каких-либо дополнительных утилит для дампа учетных данных, тем более без таких шумных, как не кастомизированные версии утилиты Mimikatz.

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

Так, для дампа базы SAM воспользуемся штатной утилитой reg.exe, которая помимо восстановления ключей и веток реестра из файла (что мы использовали для скрытного прописывания в автозагрузку) также позволяет и экспортировать ключи/ветки реестра в файл, используя для этого API-функцию RegSaveKey. База SAM представляет собой ветку реестра Windows (HKLM\SAM). Соответственно она может быть экспортирована с использованием RegSave. Ниже представлен пример соответствующих команд (наряду с дампом ветки SAM атакующим также необходимо выполнить и дамп ветки SYSTEM, в которой содержится ключ, используемый системой для шифрования содержимого SAM):

Рис. 19. Использование утилиты reg.exe для дампа веток реестра, содержащих аутентификационные данные учетных записей

Для дампа памяти процесса LSASS мы воспользуемся функцией MiniDump из DLL-библиотеки C:\Windows\System32\comsvcs.dll, которую запустим штатной утилитой rundll32.exe. Данная техника стала известна не так давно. Она позволяет выполнить дамп памяти любого процесса в системе из консоли без использования каких-либо сторонних инструментов. Ниже представлен пример ее использования нашим вымышленным атакующим:

Рис. 20. Создание дампа памяти процесса LSASS с помощью утилиты rundll32.exe и библиотеки comsvcs.dll

Таким образом, измененный этап постэксплуатации будет выглядеть следующим образом (рис. 21):

Рис. 21. Модификация этапа постэксплуатации (Postexploitation)

Давайте теперь посмотрим, как приведенные техники могут быть детектированы.

Детектирование модифицированного этапа

Гипотеза 8: Атакующий может выполнить дамп базы SAM путем экспорта соответствующей ветки реестра

Такой экспорт может быть сделан не только с помощью утилиты reg.exe, поэтому мы опустим детектирования данной техники по специфично командной строке конкретной утилиты, а сконцентрируемся на уровне ниже — используемых API-функциях. Экспорт может быть выполнен с помощью следующих функций: RegSaveKeyA/RegSaveKeyW/RegSaveKeyExA/RegSaveKeyExW.

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

Ниже на рис. 22 представлен пример соответствующего поискового запроса для нашей платформы Threat Hunting и его результат.

event_type:RegistrySave AND reg_key_path.keyword:(*\\SAM OR *\\SYSTEM OR *\\SECURITY)

Рис. 22. Детектирование по событиям EDR попыток дампа веток реестра, содержащих аутентификационные данные учетных записей

Наша гипотеза подтвердилась: на хосте codered.shockwave.local атакующий выполнил дамп трех чувствительных веток реестра, из которых можно извлечь хеши локальных учетных записей, пароли сервисных учетных записей, а также закешированные учетные данные доменных пользователей, позволяющие доменным пользователям входить в систему даже в случае недоступности контроллеров домена.

Гипотеза 9: Атакующий может создать дамп памяти процесса LSASS для последующего извлечения из него учетных данных пользователей

Как и в случае предыдущей техники, мы не будем концентрироваться на детекте специфичной командной строки (в нашем случае утилиты rundll32), а попытаемся разработать универсальный запрос, позволяющий выявлять попытки дампа памяти процесса LSASS вне зависимости от используемых для этого инструментов.

Для создания дампа памяти какого-либо процесса вне зависимости от используемого для этого инструмента необходимо получить handle на этот самый процесс, для чего большинство инструментов используют API-функцию OpenProcess. Таким образом, имея в распоряжении источник, который позволяет отслеживать получение процессом handle-а на память другого процесса, возможно детектировать приведенную технику вне зависимости от инструмента. Такую возможность предоставляют Sysmon, большинство EDR-решений и даже штатный аудит операционной системы Windows.

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

Нам необходимо уточнить паттерн для сужения выборки. Для этого следует знать, что большинство утилит создания дампов памяти, включая и штатные инструменты WIndows, используют метод MiniDumpWriteDump из библиотеки C:\Windows\System32\dbgcore.dll (в некоторых версиях ОС WIndows — из C:\Windows\System32\dbghelp.dll). Соответственно, доступ к памяти целевого процесса (дамп памяти которого создается) в случае использования MiniDumpWriteDump будет осуществляться из библиотеки dbgcore.dll/dbghelp.dll.

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

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

Имея в своем распоряжении событие, удовлетворяющее обозначенным требованиям, охотник за угрозами может разработать поисковый запрос для поиска обращений к памяти процесса LSASS, инициированных из библиотек C:\Windows\System32\dbgcore.dll и C:\Windows\System32\dbghelp.dll. Выбранные таким запросом события практически со стопроцентной вероятностью будут указывать на попытки создания дампа памяти процесса LSASS.

Благо, соответствующие события Sysmon и ряда EDR-решений такую информацию содержат. Ниже на рис. 23 представлен пример таких событий (Sysmon — снизу, BI.ZONE SENSORS — сверху).

Рис. 23. Пример событий Sysmon и EDR на доступ к памяти процесса LSASS

Определить источник можно по стеку вызовов потока. В данном стеке видно, что сначала процесс rundll32 вызвал функцию MiniDumpW из библиотеки comsvcs.dll (именно ее мы и указывали в параметрах командной строки rundll32), а уже оттуда непосредственно был осуществлен вызов функции MiniDumpWriteDump из dbgcore.dll, которая и привела в конечном счете к доступу памяти процесса LSASS (обратите внимание на верхний фрейм в стеке вызовов, соответствующий вызову API-функции NtOpenProcess из ntdll.dll).

Понимая, каким образом формируется стек вызовов, давайте разработаем наш запрос для проверки гипотезы о создании атакующим дампа памяти процесса LSASS (рис. 24).

event_type:ProcessAccess AND proc_tgt_file_path:"\\system32\\lsass.exe" AND proc_calltrace:(*dbghelp* OR *dbgcore* OR *MiniDumpWriteDump*)

Рис. 24. Детектирование по событиям EDR/Sysmon попыток создания дампов памяти процесса LSASS

В результате выполнения запроса мы видим события Sysmon и EDR, указывающие на доступ к памяти процесса lsass.exe процессом rundll32.exe для создания дампа.

Напоследок давайте посмотрим на еще один паттерн, который можно использовать для проверки гипотез о создании атакующим дампов веток реестра и памяти процесса LSASS — выявления создания на диске файлов, по структуре являющихся приведенными дампами. Данные файлы не имеют хорошо известных специфичных расширений, а значит не могут быть идентифицированы по расширению. Однако по аналогии с упомянутыми выше PE-файлами они имеют хорошо известные заголовки, которые могут быть использованы для их идентификации: "regf" (72 65 67 66) — дампы веток реестра, "MDMP"§" (4D 44 4D 50 93 A7) — дампы памяти. Таким образом, имея в распоряжении EDR-решение, умеющее определять тип создаваемых файлов, либо же поставляющее в событиях создания файлов первые несколько байт с начала файла (file magic), мы можем выявлять создание в системы файлов, по структуре соответствующих дампам памяти или дампам веток реестра. Такой детект будет очень хорошим дополнением к приведенным выше. Соответствующий запрос к платформе Threat Hunting может выглядеть следующим образом (рис. 25):

event_type:FileCreate AND file_magic:(4D444D5093A7* OR 72656766*)

Рис. 25. Детектирование по событиям EDR попыток создания файлов дампов памяти процесса LSASS и веток реестра, содержащих аутентификационные данные учетных записей

Запрос вернул нам события создания файлов дампов веток реестра и памяти процесса LSASS, соответствующие запускавшимся в нашем инциденте штатным утилитам WIndows reg.exe и rundll32.exe для создания соответствующих дампов.⁠

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

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

Получившийся в итоге модифицированный инцидент уже не является настолько простым. Для его детектирования недостаточно просто настроить политику аудита событий операционной системы, а требуется применение дополнительных инструментов, которые собирают расширенную телеметрию с конечных точек (Sysmon, коммерческие EDR-решения).

Давайте взглянем, что же у нас получилось в итоге (рис. 26).

Рис. 26. Схема модифицированного инцидента

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

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

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

Название правила	Техники MITRE ATT&CK	Текст запроса	Требуемая телеметрия
Запуск макроса в документе MS Office	T1204: User Execution T1064: Scripting	event_type:ImageLoad AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe" OR "\\msaccess.exe" OR "\\mspub.exe" OR "\\outlook.exe") AND file_path:"\\VBE7.DLL"	Sysmon Event ID 7 EDR Library Load event
Загрузка DLL-библиотеки COM-объекта Internet Explorer нетипичным процессом	T1071: Standard Application Layer Protocol	event_type:ImageLoad AND file_path:"*\\ieproxy.dll" AND proc_file_path:("\\cscript.exe" OR "\\wscript.exe" OR "\\powershell.exe" OR "\\winword.exe" OR "\\excel.exe" "\\powerpnt.exe" OR "\\mspub.exe" OR "\\visio.exe" OR "\\msaccess.exe" OR "\\regsvr32.exe")	Sysmon Event ID 7 EDR Library Load event
Доступ к Paste-сервисам (Pastebin и т.п.) не от браузеров, а также от браузерных COM-объектов	T1102: Web Service	event_type:DNSReq AND dns_rname:("pastebin.com" OR "gist.githubusercontent.com" OR "raw.githubusercontent.com") AND ( (-proc_file_path:("\\firefox.exe" OR "\\iexplore.exe" OR "\\application\\browser.exe" OR "\\chrome.exe" OR "\\amigo.exe" OR "\\opera.exe" OR "\\microsoftedgecp.exe" OR "\\microsoftedge.exe" OR "\\vivaldi.exe" OR "\\safari.exe" OR "\\ieuser.exe" OR "\\qqbrowser.exe" OR "\\spartan.exe" OR "\\spartan_edge.exe" OR "\\spartan_legacy.exe" OR "\\ucbrowser.exe" OR "\\qqbrowser.exe" OR "\\sogouexplorer.exe" OR "\\icedragon.exe" OR "\\maxthon.exe" OR "\\waterfox.exe")) OR (proc_file_path:"\\iexplore.exe" AND proc_p_file_path:"\\iexplore.exe" AND proc_p_cmdline:Embedding) )	Sysmon Event ID 22 EDR DNS Query event
Создание приложением Microsoft Office исполняемого файла	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 OR .scr) OR file_magic:4D5A*)	Sysmon Event ID 11 EDR File Create event
Создание исполняемого файла без исполняемого расширения	T1036: Masquerading	event_type:FileCreate AND file_magic:4D5A* AND -file_path.keyword:(.msi OR .ocx OR .cpl OR .ax OR .sys OR .scr OR .com OR .vxd OR .dll OR drv OR .exe OR .pif)	EDR File Create event
Спуфинг родительского процесса	T1502: Parent PID Spoofing	event_type:ProcessCreate AND proc_c_file_path:* AND proc_p_file_path:* AND -proc_file_path:"\\WerFault.exe" AND -(proc_c_file_path:"\\system32\\svchost.exe" AND proc_c_cmdline:(seclogo appinfo * netsvcs*))	EDR Process Create event
Модификация ключей реестра, отвечающих за автозагрузку, используя нестандартные функции	T1060: Registry Run Keys / Startup Folder	event_type:(RegistryRestore OR RegistryLoad OR RegistryReplace OR RegistryRename) AND reg_key_path:("\\Microsoft\\Windows\\CurrentVersion\\Run" OR "\\Microsoft\\Windows\\CurrentVersion\\RunOnce" OR "\\InprocServer32" OR "\\Windows NT\\CurrentVersion\\Windows" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\GPExtensions\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Notify\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\WOW\\Boot\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Run" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load" OR "\\CurrentControlSet\\services\\" OR "\\ControlSet001\\services\\" OR "\\ControlSet002\\services\\" OR "\\ControlSet003\\services\\" OR "\\Control\\Lsa" OR "\\Control\\SecurityProviders" OR "\\Control\\Print\\Monitors\\" OR "\\Control\\Session Manager" OR "\\Microsoft\\NetSh" OR "\\Scripts\\Logon\\" OR "\\Scripts\\Logoff\\" OR "\\Scripts\\Startup\\" OR "\\Scripts\\Shutdown\\")	EDR Registry Restore Key event EDR Registry Load Key event EDR Registry Rename Key event EDR Registry Replace Key event
Запуск приложением Microsoft Office дочернего процесса через WMI	T1204: User Execution T1047: Windows Management Instrumentation	event_type:WMICommand AND wmi_command:"Win32_Process::Create" AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe" OR "\\mspub.exe" OR "\\visio.exe" OR "\\msaccess.exe")	EDR WMI Command event
Дамп веток реестра, содержащих учетные данные пользователей	T1003: Credential Dumping	event_type:RegistrySave AND reg_key_path.keyword:(\\SAM OR \\SYSTEM OR *\\SECURITY)	EDR Registry Save Key event
Создание дампа памяти процесса LSASS	T1003: Credential Dumping	event_type:ProcessAccess AND proc_tgt_file_path:"\\system32\\lsass.exe" AND proc_calltrace:(dbghelp OR dbgcore OR MiniDumpWriteDump)	Sysmon Event ID 10 EDR Process Access event
Создание на диске файлов дампов веток реестра или памяти	T1003: Credential Dumping	event_type:FileCreate AND file_magic:(4D444D5093A7* OR 72656766*)	EDR File Create event

Заключение

Это была заключительная статья из цикла, посвященного подходу Threat Hunting. Мы начали с теоретических основ и описали компоненты, которые требуются для применения данного подхода. Затем мы плавно перешли к практике и показали, как Threat Hunting можно применять для выявления как простых, так и продвинутых техник атакующих на примере специально подготовленных нами инцидентов. Несмотря на то, что эти инциденты полностью синтетические, атакующие применяют продемонстрированные техники и в рамках реальных инцидентов.

Злоумышленники становятся все более квалифицированными и изощренными, вынуждая защитников менять свои привычки. Нарушается формировавшаяся годами идиллия реактивной безопасности, когда мы могли предпринимать активные действия только после сообщения о возможной проблеме. Если раньше достаточно было сидеть и ждать сигналов «алерт» от применяемых средств защиты, то сегодня такой подход может привести к тому, что атакующий будет месяцами или даже годами оставаться незамеченным. Именно поэтому все большую популярность приобретает проактивный подход к выявлению угроз, коим и является Threat Hunting.

Надеемся, что наша серия публикаций немного приподняла завесу над данным подходом, и желаем вам удачной охоты!