Шифровальщики. Как реагировать на атаки с использованием программ-вымогателей - Олег Скулкин

Рис. 8.7. Часть вывода malfind

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

С помощью malfind мы извлекли несколько артефактов, но самый интересный из них имеет PID 9772 и связан с процессом rundll32.exe. Судя по выходным данным, это, скорее всего, инъекция кода. Обычно ИТ-специалисты и младшие аналитики службы безопасности игнорируют легитимный файл rundll32.exe, но его следует тщательно проверять, поскольку он очень часто оказывается мишенью злоумышленников.

Давайте продолжим и проверим дерево процессов с помощью плагина pstree.

Рис. 8.8. Часть результатов запуска pstree

Этот плагин показывает запущенные процессы в виде дерева. Теперь мы получили больше информации о рассматриваемом процессе — у него был родительский процесс с PID 5952. К сожалению, информации о процессе с таким PID нет. Но это не проблема — давайте подойдем с другой стороны. Мы можем собирать информацию о параметрах командной строки для каждого процесса с помощью подключаемого плагина cmdline.

Рис. 8.9. Часть вывода cmdline

Как видите, rundll32.exe использовался для запуска файла без расширения. dll и со случайно сгенерированным названием — jwkgphpq.euz. Очень подозрительно. Кроме того, файл находится в папке со случайным названием, а это еще один распространенный признак вредоносной активности.

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

Рис. 8.10. Часть вывода netscan

Первый подозрительный IP-адрес, который мы видим на рисунке 8.10, — 81.0.236.93. Давайте соберем о нем больше информации, используя граф Group-IB.

Рис. 8.11. Подозрительный IP-адрес на графе Group-IB

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

Рис. 8.12. Информация о вредоносных файлах на графе Group-IB

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

Давайте копнем немного глубже — воспользуемся аналитикой. Теперь у нас есть не только сетевой индикатор, но и хеш. Кроме того, как вы можете видеть на рисунке 8.12, этот файл доступен на VirusTotal. Найдем его по полученному значению хеша (рис. 8.13).

Рис. 8.13. Информация VirusTotal о вредоносных файлах

Похоже, что это Emotet. Несмотря на то, что его операторы были арестованы (см. главу 1 «История современных атак с использованием программ-вымогателей»), в ноябре 2021 г. инфраструктура Emotet начала восстанавливаться, и многие корпорации снова столкнулись с ее спам-кампаниями.

Несмотря на то, что мы идентифицировали семейство вредоносных программ, давайте копнем еще глубже. Например, попробуем извлечь больше индикаторов из netscan. Если просмотреть вывод, можно заметить еще один подозрительный IP-адрес — 163.172.50.82. С этим адресом, как показано на рисунке 8.14, также связано несколько вредоносных файлов.

Рассмотрим один из них подробнее (рис. 8.15).

Как видите, результат очень похож на предыдущий. Давайте снова воспользуемся хешем на VirusTotal (рис. 8.16).

Снова Emotet! Оба IP-адреса, которые мы получили в результате криминалистического анализа памяти, связаны с вредоносной активностью.

Теперь изучим энергонезависимые данные. Live Response Collection позволил нам получить не только образ оперативной памяти,

Рис. 8.14. Подозрительный IP-адрес на графе Group-IB

Рис. 8.15. Информация о вредоносном файле на графе Group-IB

но и множество источников артефактов, которые мы обсуждали в предыдущей главе, например файлы трассировки.

Мы уже знаем, что имеем дело с Emotet. Этот бот обычно доставляется через фишинговые электронные письма с вредоносными вложениями, такими как документы Microsoft Word или электронные таблицы Microsoft Excel.

Рис. 8.16. Информация VirusTotal о вредоносных файлах

Если мы посмотрим на собранные файлы, то легко найдем файл трассировки для winword.exe. Давайте разберем его с помощью PECmd и проверим файлы, на которые есть ссылки.

Рис. 8.17. Часть вывода PECmd

Очень интересно — во временной папке, используемой Microsoft Outlook, имеется подозрительный DOCM-файл: жертва, скорее всего, получила его по электронной почте.

Мы также видим имя пользователя — CARPC, поэтому теперь мы можем получить файл реестра NTUSER.DAT и извлечь данные, связанные с этим пользователем, с помощью RegRipper.

Прежде всего, анализируя ключ реестра, хранящий сведения о последних открытых документах, мы видим, что подозрительный DOCM-файл был открыт пользователем 16 ноября 2021 г. в 08:49:55 по Гринвичу.

Еще одна интересная находка — значение jwkgphpq.euz в ключе SoftwareMicrosoftWindowsCurrentVersionRun со следующими данными.

Выглядит знакомо, не правда ли? Это механизм закрепления в системе, используемый Emotet!

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

Действительно, в данном журнале есть интересная запись.

Что это означает? PowerShell использовали для загрузки с одного из семи URL-адресов, перечисленных в предыдущем сценарии. Программа была сохранена в C: ProgramData под случайным именем и запущена через rundll32.exe. Что еще более важно, это событие произошло сразу после того, как был открыт подозрительный DOCM-файл.

Подведем итоги. 16 ноября 2021 г. в 08:49:55 (UTC) пользователь CARPC открыл вредоносный документ FILE_24561806179285605525.docm, полученный им по электронной почте. После открытия документа и включения защищенного содержимого запустился PowerShell для загрузки и запуска Emotet с удаленного сервера. Бот скопировал себя в C: UsersCARPCAppDataLocalIqnmqmjwkgphpq.euz и обеспечил закрепление в скомпрометированной системе, записав путь к себе в SoftwareMicrosoftWindowsCurrentVersionRun. Для управления и контроля использовались удаленные серверы с IP-адресами 81.0.236.93 и 163.172.50.82.

Выводы

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

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

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

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