Что внутри у призрака: разбираемся с вредоносом GHOSTENGINE  

Сегодня я хочу поговорить про вредоносное ПО, известное среди экспертов как HIDDENSHOVEL, или GHOSTENGINE. Примечательно то, какие техники используют атакующие на различных этапах его доставки и развертывания для запуска обычного майнера XMRig.

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

Интересно? Давайте разбираться вместе.

Впервые это вредоносное программное обеспечение было замечено в мае. Цепочка заражения начинается после того, как пользователь запускает вредоносный файл с именем TiWorker.exe. Этот файл маскируется под легитимный системный процесс, отвечающий за установку модулей Windows и обновлений операционной системы. Вредоносный процесс TiWorker запускает PowerShell и скачивает с С2‑сервера модули для дальнейших стадий атаки, одним из которых является kill.png.

Примечательно, что для затруднения анализа применяются как типичные подходы в виде кодирования Base64 и сжатия, так и более экзотические — распаковка и выполнение вредоносного кода сразу в виртуальной памяти процесса PowerShell. Так, модуль kill.png представляет собой обфусцированный PowerShell-скрипт, который после декодирования обращается к WinAPI-функции VirtualAlloc для выделения памяти, копирует туда шеллкод и запускает его. Все это происходит без сохранения файлов на диск.

Сам шеллкод имеет несколько стадий работы.

Во-первых, это получение адресов API‑функций по хеш-значениям, необходимых для работы шеллкода, которые указаны во внутренней структуре данных по адресу 169F26F00005.

Во-вторых, патчинг функций встроенных механизмов безопасности, чтобы они не могли обнаружить угрозу. Модификация затрагивает Antimalware Scan Interface (AMSI) и Windows Lockdown Policy (WLDP). AMSI выявляет вредоносное программное обеспечение по сигнатурам, а WLDP проверяет цифровую подпись динамического кода для блокировки потенциально нежелательного программного обеспечения, запускаемого из памяти. Всего модифицируется четыре функции:

• AMSI!AmsiScanString — сканирует переданную строку.
• AMSI!AmsiScanBuffer — сканирует переданный буфер.
• WLDP!WldpIsClassInApprovedList — проверяет, разрешен ли вызов COM-объекта, по идентификатору класса.
• WLDP!WldpQueryDynamicCodeTrust — проверяет, разрешен ли код для выполнения, согласно заданной политике Device Guard.

В-третьих, расшифрование встроенной DLL-библиотеки, формирование таблицы импорта и маппинг ее в памяти вручную. Такой подход называется Reflective DLL Injection. В этой расшифрованной библиотеке и содержится интересующий нас список названий средств защиты, которые принудительно завершаются ВПО.

Такая возможность возникает из-за применения техники BYOVD и скачивания на предыдущих этапах двух уязвимых драйверов — aswArPots.sys и IObitUnlockers.sys. Уязвимости в этих драйверах относятся к классу LPE и позволяют от имени непривилегированного пользователя завершать процессы и удалять файлы (для этого нужны расширенные права доступа).

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

Можно выделить следующие отличия от кода в паблике:

• удалены выводы отладочных строк;
• функции для работы с ETW не модифицируются;
• структура PDONUT_INSTANCE (которая расположена по адресу 169F26F00005 и упоминается в самом начале статьи) содержит изменения, поэтому некоторые поля на скриншотах отображаются неверно.

Теперь рассмотрим, как ВПО обнаруживается MaxPatrol EDR.

Благодаря гибкой настройке и постоянному обновлению индикаторов компрометации модуль проверки файлов по хеш‑значениям (file_hash_checker) обнаруживает ВПО на самом раннем этапе заражения.

Далее происходит автореагирование: вредоносный файл удаляется.

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

Как и ранее, происходит детект по хеш-сумме файла.

Далее видим закрепление в системе путем создания запланированной задачи defaultbrowserupdate.

Отмечаем обращение к С2-серверу для скачивания модулей.

Можно вручную отреагировать на это событие и, например, изолировать устройство.

Кроме того, в параметрах политики безопасности можно добавить адрес в модуль «Блокировка по IP-адресу». В результате, если под атаку попадут другие компьютеры, система защиты будет проактивно блокировать подключение к этому адресу.

Вернемся к вредоносу. Происходят манипуляции с реестром для отключения Windows Defender.

ВПО очищает системные журналы событий для сокрытия следов.

Из нестандартной папки (С:\Windows\Fonts) запускается утилита curl.exe, затем скачивается и запускается исполняемый файл (smartscreen.exe), который запускается оттуда же.

Устанавливаются уязвимые драйверы.

Выполняется модуль kill.png с доступом к WinAPI-функциям, в частности к выделению памяти для шеллкода.

Я подсветил только самые интересные моменты. На самом деле индикаторов, по которым можно обнаружить вредоносную активность, намного больше.

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

А вот список имён процессов, как и обещал: