Наука и технологии

Netskope нашла цепочку ClickFix с payload в блокчейне и Amatera

Цепочка из цепей с цифровыми огнями в блокчейне Netskope

Netskope Threat Labs разобрала цепочку атак, в которой вредоносный код для ClickFix хранится в смарт-контракте на Base, а завершающей нагрузкой выступает Amatera. Кампания бьёт по скомпрометированным WordPress-сайтам и использует сервис-воркер в браузере, чтобы переживать очистку на стороне сервера.

По данным Netskope, исследователи впервые увидели связку, где service worker получает payload не с обычного сервера, а прямо из смарт-контракта. В заражённом WordPress-сайте злоумышленники размещают rogue must-use plugin, который автоматически загружается на каждый запрос и регистрирует сервис-воркер у посетителя.

Дальше цепочка работает в браузере. Сервис-воркер удаляет заголовок Content-Security-Policy, внедряет скрипт и подсовывает фальшивую reCAPTCHA с инструкцией открыть окно Windows Run и вставить команду. Для пользователей Windows в буфере оказывается команда mshta с переходом на stage-2 хост, а для macOS показывается безвредная заглушка.

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

Проверка подтверждения в браузере с сети и блокировка добавления с помощью Netskope
Источник изображения: bleepingcomputer

Цепочка атак ClickFix

После клика по поддельной проверке браузер загружает ethers.js, подключается к Base и читает смарт-контракт по адресу 0x58460d0b3d4d6b03761c89120393c0c676676496. Контракт хранит HTML для lure-страницы и работает как реестр payload и скриптов. Netskope относит такой подход к EtherHiding: вредоносный код лежит не на скомпрометированном сайте, а в блокчейне, где его можно переписать без замены файлов на сервере.

Дальше начинается классический ClickFix. Пользователю предлагают вручную выполнить команду, и этим убирают из цепочки привычные для защитников точки контроля вроде загрузки файла или вложения. В исследованной версии команда ведёт к MP3 и HTA-полифилу, который запускает mshta, а затем создаёт скрытую задачу планировщика и поднимает PowerShell.

Следующий этап уже живёт в памяти. PowerShell обходит Constrained Language Mode, подменяет amsiContext на 0x41414141, собирает сведения о хосте и передаёт следующую стадию через стандартный ввод cmd.exe. После этого в цепочке появляется загрузчик Emmenhtal, который берёт payload с изображения на легитимном CDN, а затем подгружает Amatera как reflective loader без записи на диск.

Диаграмма WebRTC и пример Malwaere-схемы с атаками WebRTC
Источник изображения: bleepingcomputer

Финальная нагрузка определяется как Amatera, которую Proofpoint связывает с переименованным ACR Stealer. Она выдаёт себя за WPA.exe, связывается с gw.proxyvector[.]cc и использует DNS-over-HTTPS через dns.google и cloudflare-dns.com. По данным Netskope, это позволяет прятать C2-обращения внутри зашифрованного DNS-трафика и усложняет наблюдение за тем, что делает стейлер.

Почему цепочка держится

Netskope отдельно отмечает, что в этой кампании злоумышленники собрали вместе несколько техник, которые сами по себе известны, но редко встречаются в одной связке. Здесь есть постоянство через сервис-воркер, доставка через блокчейн, запуск по схеме paste-and-run, файл-полифилл, подмена AMSI, загрузка через стеганографию и запуск без следов на диске. В результате защитникам почти нечего хэшировать или изымать.

У кампании есть и вторая ветка доставки. Помимо сервис-воркера, тот же rogue plugin внедряет inline-конфигурацию, которую читает runtime loader. Обе ветки используют один и тот же контракт Base, один beacon ultraspeed[.]pro/collect и одинаковую логику исполнения; исследователи свели их к одной операции.

В конце отчёта Netskope пишет, что защиту проще всего строить вокруг ранних этапов цепочки: блокировать beacon и stage-2 хост на сети, удалять сервис-воркеры при ремедиации и отслеживать обращения к смарт-контракту. Оператор может менять payload прямо в блокчейне, поэтому этот контракт остаётся точкой, по которой можно заметить следующую итерацию атаки.

Источники: Netskope, Github, Netskope
Марта Баринова
Редактор новостного отдела, специализирующийся на аналитике программного обеспечения, стриминговых сервисов и изменениях в политике глобальных технологических платформ. В своих материалах Марта подробно освещает обновления Windows, функциональные изменения в Spotify и Google, а также исследует вопросы антимонопольного регулирования магазинов приложений. Автор более 140 публикаций, помогающих пользователям ориентироваться в быстро меняющемся ландшафте цифровых сервисов.

    Оставить комментарий