Без дизассемблера: как предварительный анализ документа GOFFEE раскрыл всю цепочку заражения

Киберугрозы постоянно эволюционируют, и для эффективного противодействия важно понимать тактики и инструменты злоумышленников. Группировка GOFFEE, также известная как Paper Werewolf, представляет собой яркий пример такой угрозы:

GOFFEE демонстрирует высокую адаптивность, постоянно обновляя свои схемы заражения. Исследователи отмечают, что во второй половине 2024 года группировка активно внедряла свой имплант PowerModul, написанный на PowerShell, который способен загружать и выполнять дополнительные скрипты с командного сервера. Наряду с этим, GOFFEE использует инструменты для похищения данных с USB-накопителей, такие как FlashFileGrabber, и даже распространяет свою нагрузку через зараженные съемные носители. Несколько атак с использованием Zero-day уязвимостей было замечено летом 2025 года.

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

Меня зовут Александр, я вирусный аналитик и реверс инженер.

Приступим!

Этап 1. Анализ входных данных

Всё начинается с письма с вложением. По легенде аналитики SOC обнаружили, как сотрудникам компании был направлен следующий документ:

Прежде, чем открывать его и смотреть на поведение ОС, можно поискать информацию в открытых источниках. Например, по вычисленной хэш-сумме файла можно проверить, встречался ли он в публичных онлайн-песочницах. Для этого отлично подходит утилита HashMyFiles ^[1]. После открытия файла в утилите, можно увидеть следующую картину:

Полученный хэш SHA-256: 8f7c38804d63d89a83d11c5c112850febf6d5e302f63f367860e78ac72f09e4c

Поискав этот хэш в VirusTotal, мы выяснили, что документ уже числится во многих антивирусных базах:

Подсказка «Code Insights» помогает догадаться, что внутри документа зашит какой-то макрос. Но что делать, если информации о вредоносном документе ещё не появилось? Правильно, анализировать вручную! Для анализа метаданных документа можно воспользоваться утилитой ExifTool ^[2]. В выводе видим много полезной информации:

Следующим этапом с помощью скрипта oleid ^[3] определим структуру вредоносного образца. Как видно из вывода работы скрипта, исследуемый файл содержит макросы VBA:

Далее с помощью утилиты olevba ^[4] можно получить сам макрос с целью его дальнейшего глубокого изучения:

На данном этапе мы определили, что исследуемый файл представляет собой документ (.docx) Misrosoft Word, содержащий в себе Macros VBA. Извлекли макрос с помощью утилиты olevba. Следующим шагом при глубоком анализе нам необходимо использовать инструменты для просмотра и отладки VBS-макросов (что в рамках текущей статьи мы делать не будем).

Также не стоит забывать, что файл DOCX — это не монолитный файл, а, по сути, архив в формате ZIP, содержащий набор XML-файлов и других ресурсов, которые вместе описывают содержимое, стили, настройки и медиа-файлы документа. Его можно разархивировать обычным 7-Zip. Чуть более подробно про структуру .docx файла можно почитать здесь ^[5]. Нам же интересен единственный файл – document.xml - "cердце" документа. Здесь хранится весь текстовый контент в виде XML-тегов. Абзацы, таблицы, пробелы и сам текст. В самом конце этого файла можно обнаружить странную сигнатуру, с закодированной в Base64 текст, разделенный ключевым словом «Checksum»:

Декодировав строки, мы обнаружим следующие интересные зацепки:

В первом случае код представляет собой обфусцированный вредоносный скрипт, создающий файлы UserCacheHelper.lnk.js и UserCache.ini в директории %USERPROFILE%. Также для создания скрытых процессов скрипт использует WMI.

В случае с декодированной последовательностью после «Checksum», можно наблюдать ещё одну Base64-закодированную строку, и, судя по переменной $code, в ней содержится какая-то исполняемая часть, и здесь мы попали прямо в точку:

Судя по всему, этот код создает постоянное соединение с командным сервером для удаленного управления зараженной системой.

Этап 2. Поведенческий анализ

Пришло время запустить вредоносный образец, чтобы посмотреть в динамике на его поведение. Для этого будем использовать утилиты Process Monitor ^[6], System Informer ^[7] и Fakenet-NG ^[8]. Запустим их. После запуска файла видим закодированный текст:

Чтобы отобразить весь текст, MS Word предлагает нажать кнопку «Enable Content». System Informer отобразил появившийся процесс Winword.exe и его PID = 2264. Поставим фильтр в Process Monitor по этому PID и начнем запись событий. Далее отобразим весь контент:

Process Monitor сразу же отобразил следующие события:

Видим создание двух файлов в директории %USERPROFILE% - UserCache.ini.hta и UserCache.ini. В эти файлы записана как раз та нагрузка, которую мы обнаружили в ходе анализа document.xml. Также в каталоге %USERPROFILE% мы можем наблюдать файл UserCacheHelper.lnk.js:

Этот js файл маскируется под ярлык (на это указывает расширение .lnk). Внутри можем наблюдать ещё один обфусцированный js, который, как несложно догадаться, выполняет скрытый запуск файла UserCache.ini через WMI.

Теперь проверим как вредонос закрепляется в системе с помощью Autoruns ^[9]

Fakenet-NG также зафиксировал подозрительную активность на адресе 45.84.1[.]150 – правда подключиться к этому адресу не удастся:

По исследованиям ^[10] специалистов из Лаборатории Касперского ответы с этого адреса содержали скрипты для управления зараженным устройством.

Этап 3. Собираем всё вместе

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

Цепочка компрометации группировки GOFFEE:

1. Фишинговое письмо → Документ maldoc.doc с социальной инженерией (имитация официального письма) T1566 ^[11], T1589 ^[12];

2. Активация макроса → Пользователь нажимает "Enable Content" T1059.005 ^[13];

3. Извлечение нагрузки → Макрос декодирует Base64-строки из document.xml T1027 ^[14] T1059.005 ^[13];

4. Создание файлов → В %USERPROFILE% появляются:

   • UserCache.ini (PowerShell-лоадер) T1059.001 ^[15];

   • UserCache.ini.hta (исполнитель);

   • UserCacheHelper.lnk.js (обфусцированный JavaScript) T1059.007 ^[13]

5. Закрепление → HTA-файл регистрируется в автозагрузке реестра T1547.001 ^[16];

6. Запуск импланта → Через цепочку HTA → JS → WMI выполняется PowerModul T1059.003 ^[17], T1047 ^[18];

7. Установление связи → подключение к C2: http[:]//45.84.1[.]150:80 T1071.001 ^[19].