GHOSTENGINE: что внутри у призрака

О чем статья

Поговорим о ВПО GHOSTENGINE (оно же HIDDENSHOVEL), а точнее, о его модуле kill.png, который способен завершать процессы средств защиты. Рассмотрим, как происходит заражение и как можно обнаружить вредоносную активность с помощью EDR-системы

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

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

Этапы работы шеллкода

1. Получение адресов API‑функций по хеш-значениям, которые указаны во внутренней структуре данных (по адресу 169D26F00005 (см. рис. 2 и рис. 3)).

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

Всего модифицируются четыре функции:

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

3. Расшифровка встроенной DLL-библиотеки, формирование таблицы импорта и ее ручной маппинг в памяти. Этот подход называется reflective DLL injection. В расшифрованной библиотеке содержится интересующий нас список средств защиты, процессы которых принудительно завершает ВПО (см. рис. 9).

ВПО может завершать процессы средств защиты благодаря применению техники BYOVD и скачиванию на предыдущих этапах уязвимых драйверов — aswArPot.sys и IObitUnlocker.sys. Уязвимости в этих драйверах относятся к классу LPE и позволяют от имени непривилегированного пользователя завершать процессы и удалять файлы (обычно для этого нужны расширенные права доступа).

Нам удалось установить, что в основе работы шеллкода лежит проект Donut. Что на это указывает:

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

Для сравнения приведу скриншоты кода после импорта структур и некоторых переименований.

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

• удалены выводы отладочных строк (функция DPRINT: см. рис. 11, 12, 14, 15, 16);
• функции для работы с ETW не модифицируются (см. рис. 13 (строка 67) и рис. 15 (строка 257));
• структура donut_instance расположена по адресу 169D26F00005 и упоминается в начале статьи) содержит изменения, поэтому некоторые поля на скриншотах отображаются неверно. Например, см. рис. 13 (строки 63–67): вместо donut_instance → password и donut_instance → wldp должно быть donut_ instance → module → x и donut_instance → bypass.

Как MaxPatrol EDR обнаруживает ВПО

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

Далее происходит автореагирование — вредоносный файл удаляется (см. рис. 18).

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

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

Мы видим закрепление в системе путем создания запланированной задачи defaultbrowserupdate (см. рис. 21).

Кроме того, отмечаем обращение к С2-серверу для скачивания модулей (см. рис. 22).

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

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

Но вернемся к нашему вредоносу. Он проводит манипуляции с реестром для отключения Windows Defender (см. рис. 26).

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

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

Затем в системе устанавливаются уязвимые драйверы (см. рис. 30–31).

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

***

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