Подробный технический разбор цепочки доставки Amatera Stealer

Эта Fake CAPTCHA не взламывает систему — она ждёт, пока вы сделаете всё правильно

Введение

Современные вредоносные кампании всё реже полагаются на эксплуатацию уязвимостей. В условиях зрелых EDR, поведенческого анализа и автоматических песочниц ставка смещается с «быстрого взлома» на гарантированное, корректное и малозаметное выполнение. В центре внимания оказывается не payload, а путь, по которому он доставляется.

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

Общая архитектура атаки

Финальным пейлоадом кампании является Amatera Stealer — известное семейство инфостилеров. Однако ключевая ценность данного кейса заключается не в самом вредоносном ПО, а в архитектуре доставки.

Цепочка атаки построена вокруг следующих принципов:

строго пользовательское выполнение
использование подписанных компонентов Windows в роли LOLBIN
многоуровневые execution gate
активная фильтрация среды выполнения
динамическая реконструкция кода
отказ от стандартных PowerShell-механизмов
использование доверенной сторонней инфраструктуры
полное выполнение в памяти
переход из PowerShell в нативный shellcode

Каждый элемент этой цепочки снижает вероятность детекта и повышает надёжность заражения.

Этап 1. Fake CAPTCHA как точка входа

Атака начинается с социальной инженерии. Пользователю отображается Fake CAPTCHA, в рамках которой предлагается вручную скопировать и выполнить команду через окно Run. Это подаётся как обязательная проверка на «человечность».

Такой подход сразу решает несколько задач:

обход всех exploit-ориентированных защит
гарантия ручного выполнения
формирование доверенного контекста запуска

Критически важно, что команда не запускает PowerShell напрямую.

Злоупотребление SyncAppvPublishingServer.vbs

Вместо прямого вызова PowerShell используется подписанный Microsoft-скрипт SyncAppvPublishingServer.vbs, относящийся к компонентам Application Virtualization (App-V).

Запуск происходит через wscript.exe, формируя следующую цепочку процессов:

explorer.exe → wscript.exe → SyncAppvPublishingServer.vbs → powershell.exe

Такая цепочка выглядит легитимно на системах, где App-V используется в корпоративных сценариях, и значительно менее заметна для сигнатурных и поведенческих правил.

Фильтрация целевых систем

App-V присутствует только в редакциях Windows Enterprise и Education, а также в серверных версиях. На Home и Pro выполнение не происходит.

Это приводит к естественной селекции:

атака не работает на большинстве домашних ПК
выполнение срывается в песочницах
приоритет получают корпоративные системы

Таким образом, фильтрация целей начинается уже на первом этапе.

Execution gate №1: маркер ручного запуска

Во время первичного выполнения создаётся временная переменная окружения ALLUSERSPROFILE_X со случайным значением.

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

Динамическая реконструкция PowerShell

Начальный PowerShell-код избегает прямого использования чувствительных cmdlet’ов. Вместо этого применяются:

алиасы
wildcard-разрешение
динамическое сопоставление строк
восстановление имён функций во время выполнения

Например, Invoke-Expression никогда не фигурирует в явном виде. Такой подход существенно снижает эффективность статического анализа и сигнатур.

Шумовой этап: маскировка логики

Следующий скрипт представляет собой тысячи переменных с псевдо-cmdlet-именами, каждая из которых хранит короткий base64-фрагмент.

Во время выполнения:

фрагменты собираются
конкатенируются
декодируются
исполняются через ScriptBlock.Create

Назначение этого этапа — утопить полезную нагрузку в шуме и затруднить анализ.

Отказ от стандартных PowerShell-сетевых функций

Декодированный загрузчик реализует собственную HTTPS-логику:

TCP-соединение
SslStream
ручная сборка HTTP-запроса
парсинг ответа

Это позволяет избежать телеметрии, завязанной на Invoke-WebRequest и Invoke-RestMethod.

Execution gate №2: проверка буфера обмена

Перед продолжением загрузчик проверяет буфер обмена на наличие маркера, связанного с ALLUSERSPROFILE_X.

При отсутствии маркера:

отображаются отвлекающие сообщения
поток уходит в бесконечное ожидание через ManualResetEvent().WaitOne()

Скрипт не завершает работу и не генерирует ошибок, что крайне эффективно против песочниц.

Использование Google Calendar как конфигурационного сервиса

После прохождения execution gate загрузчик получает конфигурацию из публичного Google Calendar (.ics).

Преимущества подхода:

доверенная инфраструктура
отсутствие жёстко зашитых URL
возможность оперативной смены параметров
повышение живучести кампании

Извлекается поле DESCRIPTION, содержащее base64-конфигурацию.

Персонализация под жертву

Из параметров окружения формируется строка, вычисляется MD5-хэш, и первые 8 hex-символов используются как поддомен.

Это снижает повторяемость сетевых индикаторов и усложняет корреляцию.

Ключевой этап: использование WMI для передачи управления

Архитектурная роль WMI

На этом этапе атакующий сознательно прерывает линейную PowerShell-цепочку и использует Windows Management Instrumentation (WMI) для запуска следующей стадии.

WMI — это нативная инфраструктура Windows, предназначенная для администрирования, мониторинга и управления системами. В корпоративных средах WMI используется повсеместно, что делает её активность малозаметной и редко вызывающей подозрения.

В данной кампании WMI используется не для постоянства, а как механизм скрытой передачи управления между стадиями.

Почему именно WMI

Использование WMI решает сразу несколько задач:

Разрыв родительской цепочки процессов
Новый PowerShell-процесс создаётся не напрямую, а через инфраструктуру управления.
Обход поведенческих корреляций EDR
Цепочки вида PowerShell → PowerShell менее очевидны.
Минимизация командной строки
Код передаётся в закодированном виде.
Имитация легитимной административной активности
Особенно в доменных средах.

Техническая реализация

Загрузчик:

динамически формирует PowerShell-код
кодирует его в Unicode
затем в base64
передаёт в Win32_Process.Create

В результате создаётся скрытый 32-битный процесс PowerShell, полностью отделённый от предыдущего контекста.

Этот переход:

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

Почему WMI — идеальный транспортный слой

WMI:

встроен в Windows
активно используется администраторами
редко блокируется
не требует записи файлов
работает одинаково локально и удалённо

Использование WMI превращает передачу управления в административно выглядящее событие, а не в очевидный вредоносный переход.

PNG-стеганография как следующий этап

После WMI-перехода загрузчик:

использует WinINet через нативные API
загружает PNG с публичных CDN
извлекает данные через LSB-стеганографию

Первые 64 бита определяют длину пейлоада, далее происходит детерминированное восстановление байтов.

Расшифровка и выполнение в памяти

Извлечённые данные:

расшифровываются XOR-ключом
распаковываются GZip
интерпретируются как PowerShell-код
исполняются без записи на диск

Финальный переход в нативный код

Последний PowerShell-этап:

расшифровывает shellcode
выделяет память через NtAllocateVirtualMemory
меняет права через NtProtectVirtualMemory
передаёт управление shellcode

Shellcode загружает и исполняет Amatera Stealer.

Значение кампании

Этот кейс наглядно демонстрирует:

payload может быть известным
доставка — решающий фактор
WMI становится ключевым элементом fileless-архитектур

Атака оптимизирована не под скорость, а под выживаемость.

Заключение

Fake CAPTCHA, App-V, execution gate, Google Calendar, WMI, PNG-стеганография и shellcode образуют единую систему. Каждая стадия подтверждает предыдущую и отсекает нежелательные сценарии.

В современных условиях защита должна отвечать не только на вопрос «что было запущено», но и на вопрос:

«каким образом и почему этому позволили выполниться».

Понимание роли WMI и подобных механизмов передачи управления становится критически важным для анализа реальных атак и построения эффективной защиты.