Silver Fox использовала поддельные сайты загрузки для доставки вредоносного ПО

Silver Fox использовала многоэтапную цепочку доставки через SEO-оптимизированные поддельные сайты загрузки программного обеспечения, имитировавшие бренды SteelSeries и Bcut. Сайты обращались к пулу ретрансляторов, а сервер выдавал либо фактическую полезную нагрузку, либо легитимный установщик WeChat, WeChatWin_4.1.13.exe, в зависимости от домена из запроса. Фактическую полезную нагрузку наблюдали по адресу www.0akw8w.com/down910.

Изменение логики выдачи полезной нагрузки

Поддельные сайты использовали статические шаблоны и клиентский JavaScript. Скрипт получал информацию о ретрансляторах из noah-ssh.com.cn/relays.json, а затем отправлял запросы к /api.php через пул ретрансляторов. В запросах передавались заголовки Referer и Origin поддельного сайта. По их значениям сервер определял домен, инициировавший запрос.

Изначально API ретрансляторов возвращал URL для загрузки вредоносного ПО любому запросившему. Затем Silver Fox добавила белый список. Полезная нагрузка доставлялась только при совпадении значения заголовка Referer с активным поддельным доменом. Исследователи в области информационной безопасности могли отправлять запросы с кандидатами в домены, включая недавно зарегистрированные домены-двойники, и выявлять активную инфраструктуру Silver Fox, если API возвращал подлинную полезную нагрузку.

После пакетного зондирования логику доставки изменили на облачное управление чёрным списком. Домены из чёрного списка получали легитимный установщик WeChat, WeChatWin_4.1.13.exe. Домены, не включённые в список, продолжали получать фактическую полезную нагрузку. К ним относились новые домены, несвязанные домены и запросы без заголовка Referer.

Тестирование показало, что решение принималось по значению домена, а не по пользовательскому агенту, пути URL, схеме, поддомену или временным параметрам. Домены, возвращавшие пакет WeChat, стали индикаторами ранее раскрытых или деактивированных поддельных сайтов.

Особенности клиентского фреймворка

Клиентский фреймворк применял параметры обхода кэша с метками времени и заголовок cache: no-store. Данные о ретрансляторах сохранялись в localStorage под ключом noah_relay_pool. Фреймворк поддерживал переключение между несколькими ретрансляторами, то есть multi-relay failover, и использовал короткие тайм-ауты.

Клиент принимал любые значения download_link, которые предоставлял сервер, без проверки файла. Это позволяло менять выдаваемый файл на стороне сервера без модификации фишинговых шаблонов. Загрузка запускалась через скрытые якоря или iframe, в том числе в запросах без заголовка Referer.

Дополнительные характеристики для обнаружения давали маркер NOAH_DL_REV = 'r6' и внедрённый код диспетчеризации. Этот код присутствовал даже в ответах 404.

Индикаторы инфраструктуры

К другим индикаторам относились:

• междоменные запросы к workers.dev;
• аналитика 51.LA;
• общие TLS-сертификаты на фишинговых доменах;
• несовпадающие TLS-сертификаты на фишинговых доменах.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.