Новые антианалитические тактики SLOW#TEMPEST: как усложняется борьба с современными угрозами

Эволюция тактики SLOW#TEMPEST

SLOW#TEMPEST распространяется через ISO-образы - это распространенный способ упаковки нескольких файлов, позволяющий избежать первичного обнаружения. В данном случае ISO содержит 11 файлов, два из которых являются вредоносными, а остальные - легитимными. Первый вредоносный файл, zlibwapi.dll (в статье именуемый как loader DLL), играет роль загрузчика: он расшифровывает и исполняет внедренный полезный код. Однако сам код внедрен нестандартным способом - он прикреплен к концу другой DLL-библиотеки под названием ipc_core.dll.

Для запуска вредоносного кода злоумышленники используют технику DLL side-loading - легитимная подписанная программа DingTalk.exe загружает loader DLL, что приводит к исполнению кода злоумышленников. Разделение загрузчика и полезной нагрузки усложняет детектирование, так как вредоносная активность проявляется только при наличии обоих файлов.

CFG-обфускация с использованием динамических переходов

Одним из ключевых методов антианализа, применяемых авторами SLOW#TEMPEST, является обфускация графа потока управления (CFG). Этот метод изменяет порядок выполнения инструкций программы, что делает статический и динамический анализ чрезвычайно сложным. В результате традиционные инструменты анализа, полагающиеся на линейные последовательности кода, становятся неэффективными.

CFG-обфускация с использованием динамических переходов (JMP RAX), при которой адрес перехода вычисляется во время выполнения. Это не позволяет декомпиляторам, таким как Hex-Rays, восстановить исходный код, так как путь выполнения программы заранее неизвестен. В результате декомпиляция выдает лишь фрагменты псевдокода, что значительно затрудняет анализ.

Исследователи Palo Alto использовали IDAPython-скрипты для выявления всех динамических переходов в коде. Оказалось, что перед каждым JMP RAX находится диспетчер - последовательность из девяти инструкций, которая вычисляет адрес перехода на основе состояния флагов процессора (ZF и CF). Этот механизм создает два возможных пути выполнения, что делает статический анализ крайне трудоемким. Чтобы автоматизировать процесс определения адресов переходов, исследователи применили фреймворк Unicorn. Эмуляция диспетчеров позволила заменить динамические переходы на прямые условные и безусловные JMP-инструкции, значительно упростив анализ кода.

Обфусцированные вызовы функций

Еще одной тактикой, затрудняющей анализ, являются обфусцированные вызовы функций. Вместо прямого вызова API-функций Windows вредоносный код использует косвенные вызовы (CALL RAX), где адрес функции вычисляется в процессе выполнения. Это осложняет идентификацию используемых API и понимание логики работы программы.

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

Анализ функциональности loader DLL

После снятия обфускации исследователи смогли изучить основную функциональность loader DLL. Было обнаружено, что вредоносный код выполняет проверку на наличие песочницы с помощью API-функции GlobalMemoryStatusEx. Если физическая память системы составляет менее 6 ГБ, загрузчик прекращает свою работу, что может указывать на попытку избежать анализа в виртуальных средах. В случае успешной проверки loader DLL распаковывает и исполняет в памяти основной вредоносный модуль.

SHA256

• 3583cc881cb077f97422b9729075c9465f0f8f94647b746ee7fa049c4970a978
• 3d3837eb69c3b072fdfc915468cbc8a83bb0db7babd5f7863bdf81213045023c
• a05882750f7caac48a5b5ddf4a1392aa704e6e584699fe915c6766306dae72cc