Статья TDS малварь распространение через фейковые сайты open-source: от SEO poisoning до Remus Stealer

Больше 5 000 сэмплов на VirusTotal, свыше 100 активных фейковых доменов и три семейства малвари на выходе. Check Point Research задокументировали кампанию, в которой атакующие клонировали сайты Ghidra, dnSpy и ILSpy - инструменты, которые реверс-инженеры и аналитики малвари гуглят и скачивают каждую неделю. Кнопка "Download" на ghidralite.com при наведении показывала настоящую ссылку на GitHub, но первый клик уходил не туда - CloudFront-скрипт перехватывал событие mousedown и запускал цепочку TDS-редиректов с гео-фильтрацией, проверкой ASN и частотным кэппингом. TDS малварь распространение через фейковые сайты open-source проектов - вектор не новый, но техническая реализация этой кампании задаёт планку для тех, кто разбирает цепочки заражения руками.

Я разбирал подобные цепочки раньше, но здесь впервые увидел настолько чистую эксплуатацию доверия к open-source инфраструктуре. Атакуют не бухгалтеров - атакуют нас.

Drive-by download атаки через вредоносные клоны сайтов: бизнес-логика​

Зачем кому-то клонировать сайт Ghidra? Деньги! По данным Check Point, основная цель операторов фейковых сайтов - захват и монетизация поискового трафика. Встраивая TDS-слой в цепочку загрузки, операторы превращаются в звено инфраструктуры распространения, чьими клиентами "ниже по потоку" становятся дистрибьюторы вредоносного ПО.

Финансовый импакт для жертв - многоуровневый. Remus Stealer - один из пейлоадов этой кампании - извлекает данные из 20+ браузеров, сотен расширений, криптокошельков, 2FA-инструментов и менеджеров паролей. Украденные учётные данные продаются на даркнет-маркетах, а полученный доступ к корпоративным аккаунтам перепродаётся группировкам, включая ransomware-операторов.

ФБР в публичных предупреждениях (PSA) прямо указывало на связку TDS и ransomware: "Доступ к учётным записям жертв, полученный через сетевой доступ, может продаваться за плату другим злоумышленникам, включая группировки-вымогатели". Для пентестера эта кампания опасна вдвойне - атакуют не абстрактных пользователей, а рабочие станции security-специалистов: ghidralite.com, dnspy.org, ilspy.org, grpcurl.com, mqttexplorer.com, mfcmapi.com. Компрометация через drive-by download атаки на такой машине - это каскадная утечка VPN-конфигов, SSH-ключей и токенов доступа к клиентским инфраструктурам. Представьте: один скачанный "Ghidra" - и через час кто-то гуляет по сети вашего заказчика с вашими ключами.

SEO poisoning малварь: отравление поисковой выдачи для фейковых порталов​

Отравление поисковой выдачи - главный вектор доставки трафика на вредоносные клоны. По наблюдениям Check Point и Fullstory, ряд фейковых доменов ранжировался в Google выше реальных сайтов проектов.

Механика: каждый домен эксплуатирует узнаваемость и поисковую популярность оригинального проекта. Фейковый сайт содержит контент, оптимизированный под название инструмента, описание функций и ключевые слова из официальной документации. Сайты выглядят профессионально и ссылаются на реальные GitHub-репозитории - визуальная проверка проходит без подозрений. По оценке исследователей, "многие сайты находятся в топе выдачи Google по релевантным запросам, зачастую обгоняя реальный сайт проекта. Это превращает их видимость в актив".

С точки зрения MITRE ATT&CK SEO poisoning малварь маппится на технику T1608.006 (SEO Poisoning), а регистрация доменов - на T1583.001 (Domains). Атакующие инвестируют в подготовку инфраструктуры задолго до раздачи пейлоадов: по данным исследователей, кампания была активна несколько месяцев до начала раздачи малвари. Сначала регистрировались домены и набирался поисковый авторитет, затем встраивались TDS-скрипты, и лишь потом начиналось распространение пейлоадов. Этот лаг в несколько месяцев между регистрацией домена и переходом к active exploitation - и есть окно для проактивной детекции. Если вы его проспите - будете разбирать инцидент, а не предотвращать.

Помимо SEO poisoning, атакующие могут использовать смежные техники: malvertising (вредоносная реклама в поисковой выдаче) и typosquatting (регистрация доменов с опечатками). В этой кампании речь именно об impersonation - полноценном клонировании сайта проекта с профессиональным дизайном, а не о банальной опечатке в URL.

Как TDS редиректы доставляют малварь: анатомия цепочки​

Traffic distribution system в контексте кибербезопасности - сеть редиректов с тремя типами узлов: точки входа (entry), промежуточные ноды (intermediate) и посадочные страницы (landing). По данным Unit 42 (Palo Alto Networks), вредоносные TDS-цепочки отличаются от легитимных по трём топологическим признакам:

• Примерно 25% вредоносных TDS имеют цепочки длиннее 4 хопов (против 10% у легитимных)
• Медианное число URL в вредоносной TDS - 126, в легитимной - 80
• 40% вредоносных TDS представляют собой единый связный подграф (все URL взаимосвязаны), против 20% у легитимных

Эти метрики - не абстракция. Когда в логах прокси или при passive DNS-мониторинге вы видите цепочку из 5-6 редиректов через разные домены с высокой взаимной связностью - это статистически значимый индикатор вредоносного TDS-редиректа. Запомните: 4+ хопа и связный граф - красный флаг.

JavaScript-ловушка на фейковом сайте open-source​

Ключевой трюк кампании - перехват клика на уровне браузера. Фейковый сайт загружает JavaScript с CloudFront CDN по URL вида https://d33f51dyacx7bd.cloudfront.net/?aydfd=1237183.

Скрипт подменяет обработчик кликов: по реконструкции исследователей, в Chrome перехватывается mousedown, в Firefox - click. При первом взаимодействии с кнопкой "Download" скрипт сохраняет оригинальный URL назначения, генерирует runtime-URL для TDS и открывает TDS-URL через cached window.open, опережая штатную навигацию. preventDefault() на mousedown сам по себе не блокирует переход по href - скрипт использует дополнительную логику (перехват на capture-фазе click или динамическую подмену href) для предотвращения навигации на оригинальный URL. Упрощённый псевдокод для иллюстрации концепции (реконструкция; реальный скрипт содержит дополнительную логику для блокировки навигации по href):

const cachedOpen = window.open;
document.addEventListener(isChromeDesktop() ? "mousedown" : "click", (event) => {
  if (!isEligibleClick(event.target)) return;
  const url = generateRuntimeURL({ referrer: location.href,
    userDestination: extractClickedLink(event.target) });
  cachedOpen(url, "_blank");
  event.stopImmediatePropagation();
  event.preventDefault();
}, true);

Принципиальный момент: href на кнопке остаётся легитимным - status bar браузера показывает GitHub-ссылку. Но первый клик перехватывается. Повторный клик, обновление страницы или возврат на сайт с того же IP могут вернуть нормальное поведение - скрипт использует localStorage для частотного кэппинга. Тут-то и начинается головная боль для аналитика: пытаешься повторить вредоносный редирект - получаешь чистый установщик. Классическая "ловушка воспроизводимости". Скрипт также передаёт URL, на который пользователь пытался перейти, вниз по цепочке - TDS знает, что жертва хотела скачать.

Фильтрация жертв: traffic distribution system в кибербезопасности​

После перехвата клика жертва попадает в TDS-цепочку, которая принимает решение о маршрутизации:

• IP и ASN: VPN-провайдеры, датацентры и сети security-компаний фильтруются - им выдаётся легитимное ПО (браузер Opera или безобидное расширение)
• Геолокация: трафик из нецелевых регионов перенаправляется на чистые ресурсы
• User-Agent и fingerprint: тип устройства, версия браузера, признаки автоматизации
• Состояние визита: первый визит vs повторный (cookies + localStorage)
• Anti-bot логика: проверка на headless-браузер, подозрительные паттерны скролла

По данным FBI PSA, вредоносный TDS "может определить пользователей в регионах, которые не являются целевыми, что позволяет избежать обнаружения, показывая безопасный контент нежелательным целям, включая исследователей безопасности". Для аналитика это означает: забудьте про датацентровый VPN. Нужна ротация IP через резидентные прокси, подмена User-Agent и полная очистка localStorage между попытками. Иначе TDS вас раскусит и подсунет чистый бинарь.

Stealer через фейковый сайт: Remus Stealer и другие пейлоады​

Кампания раздаёт три семейства малвари:

Remus Stealer - инфостилер, распространяемый по модели malware-as-a-service (MaaS). По данным Check Point, имеет пересечения по функциям с Lumma Stealer и вытаскивает данные из 20+ браузеров, включая сотни расширений, криптокошельки, 2FA-инструменты и менеджеры паролей.

SessionGate - многоступенчатый обфусцированный лоадер, ранее не описанный в публичных исследованиях. Доставляет потенциально нежелательные приложения (PUA), но содержит развитую anti-analysis логику: при обнаружении sandbox-окружения переключается на установку легитимного ПО. Пейлоад уникален для каждого клиента и доставляется только после полного прохождения TDS-цепочки. По данным VirusTotal, зафиксировано от 2 000 до 3 500 сэмплов SessionGate - основные загрузки из Турции, Польши, Бразилии, Германии, Франции, России и Великобритании. Финальный DLL-пейлоад связывается с внешним сервером, получает зашифрованную конфигурацию, извлекает URL загрузки и запускает следующую стадию через cmd.exe.

AnimateClipper - криптоклиппер, подменяющий адреса кошельков в буфере обмена, с поддержкой более 20 блокчейн-экосистем. По некоторым данным, может доставляться через ClickFix-приманку (фейковые CAPTCHA/ошибки браузера), но в контексте этой TDS-кампании вектор доставки через ClickFix не подтверждён исследователями Check Point.

Модульная архитектура делает каждый этап заменяемым: оператор TDS может переключить downstream-пейлоад без изменения entry-инфраструктуры. Тот же трафиковый конвейер, который обеспечивает «серую» монетизацию, селективно маршрутизирует реальных пользователей к вредоносным нагрузкам. По сути - конвейер с горячей заменой боеголовки.

Практический перехват TDS-цепочки через mitmproxy​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

На что смотреть в перехваченном трафике:

• CloudFront в первом хопе - легитимный CDN, но query-параметры с идентификаторами кампании (?wbbcd=, ?aydfd=) нетипичны для стандартного использования
• Set-Cookie с трекинговым session ID - передаётся между хопами для связывания сессии
• X-Forwarded-For в запросе - TDS-бэкенд использует реальный IP клиента для маршрутизации; подмена этого заголовка через прокси - один из способов обойти гео-фильтр
• Передача referrer и User-Agent через query-параметры - TDS-нода собирает fingerprint для фильтрации
• Имя файла в финальном URL - setup_ghidra_v11.exe вместо ghidra_11.2_PUBLIC.zip с официального сайта; несовпадение с каноничным именем релиза - надёжный индикатор подмены

Если TDS классифицирует запрос как исследовательский (по ASN, датацентровому IP, headless User-Agent), финальный Location указывает на легитимный файл - браузер Opera или безобидное расширение. Вот почему sandbox-анализ и автоматические краулеры не видят вредоносного поведения. TDS буквально подсовывает разный контент - аналитику и жертве.

Место в kill chain: MITRE ATT&CK маппинг​

Полная цепочка от регистрации домена до доставки пейлоада покрывает несколько тактик:

Этап	Техника ATT&CK	Описание в контексте кампании
Подготовка инфраструктуры	Domains (T1583.001)	Регистрация ghidralite.com, dnspy.org и 100+ доменов
SEO-продвижение	SEO Poisoning (T1608.006)	Вывод фейковых сайтов в топ Google по запросам open-source инструментов
Подготовка площадки	Drive-by Target (T1608.004, Resource Development)	Встраивание CloudFront TDS-скриптов в страницы загрузки
Первичный доступ	Drive-by Compromise (T1189, Initial Access)	Жертва заходит на фейковый сайт из поисковой выдачи
Выполнение	Malicious Link (T1204.001, Execution)	Клик по "Download" запускает TDS-цепочку
Маскировка	Match Legitimate Resource Name or Location (T1036.005, Defense Evasion)	Имя файла имитирует легитимный установщик проекта
Маршрутизация	Multi-hop Proxy (T1090.003, C2)	TDS-цепочка из 4+ промежуточных нод для обфускации
Доставка	Ingress Tool Transfer (T1105, C2)	Скачивание Remus Stealer / SessionGate на машину жертвы

Для red team эта цепочка демонстрирует зрелый подход к resource development: разделение фаз (SEO, TDS, payload) позволяет каждый элемент заменять независимо. При блокировке одного landing-домена TDS перенаправляет трафик на альтернативный, а entry-инфраструктура остаётся нетронутой. Тот же принцип применим к управлению C2: TDS-подобная маршрутизация с промежуточными нодами повышает устойчивость к takedown.

Ограничения и детекция TDS-кампаний​

Что работает​

Метод	Что покрывает	Чего не видит	Когда применять
Passive DNS (DomainTools, PassiveTotal)	Кластеры доменов, WHOIS-связи	Клиентский JS, runtime-URL	Проактивный threat hunting
Active crawling (urlscan.io)	HTTP-редиректы, скриншоты	TDS фильтрует краулеры по UA/ASN	Первичная разведка домена
mitmproxy + реальный браузер	Полная TDS-цепочка с JS-перехватом	Требует ручной работы, не масштабируется	IR, анализ конкретной кампании
Endpoint monitoring (Sysmon)	Запуск wscript/cscript/PowerShell	Не видит pre-delivery этап	SOC, post-execution detection

Контроль расширений файлов: FBI рекомендует изменить дефолтные ассоциации для .js-файлов, чтобы предотвратить случайный запуск JavaScript-пейлоадов, доставленных через TDS.

Мониторинг endpoint'ов: отслеживание подозрительного запуска wscript.exe, cscript.exe и PowerShell-скриптов, инициирующих веб-запросы на скачивание .js, .ps1 или .svg файлов - прямая рекомендация FBI PSA.

Верификация загрузок: сверка SHA-256 хеша скачанного файла с официальным репозиторием (GitHub Release checksums). Простейший контроль, но работает. Сколько из вас реально проверяют хеш после скачивания? Вот то-то.

Где детекция буксует​

TDS-операторы целенаправленно обходят автоматизированные сканеры. SessionGate детектирует sandbox-окружение и переключается на установку легитимного ПО. Частотный кэппинг и проверка localStorage делают повторный анализ с того же профиля бесполезным.

Для исследователей это означает необходимость "чистого" окружения при каждой попытке: новый browser profile, новый IP (резидентный, не датацентровый), полная очистка cookies и storage. Автоматизированный обход гео-фильтров TDS через Python-скрипты с ротацией резидентных прокси - стандартный подход, но формула на бумаге понятна, а на практике TDS-операторы регулярно меняют правила фильтрации. Если хочется отработать анализ подобных цепочек в контролируемой среде, готовый стенд есть на HackerLab.pro (https://hackerlab.pro) - на платформе представлены категории web и forensics, где встречаются задачи с redirect-цепочками и анализом вредоносного трафика (нужна регистрация).

Кампания с фейковыми open-source сайтами наглядно показывает сдвиг, который я наблюдаю последние полтора года при разборе цепочек заражения: TDS малварь распространение всё реже строится на одной уязвимости или одном фишинговом письме и всё чаще - на инфраструктурных конвейерах, где каждое звено заменяемо. TDS в этой схеме - не новая технология, а грамотно переосмысленный инструмент из легитимного маркетинга. CloudFront как CDN, законные URL в status bar, гео-таргетинг - ничего из этого не вызывает срабатываний у стандартных средств защиты.

Главное - не в конкретных IoC, которые устареют через неделю, а в методологии. Атакующие вкладываются в SEO-продвижение фейковых сайтов месяцами до начала раздачи малвари. Окно для проактивной детекции - не когда пейлоад уже летит, а когда домен-двойник только набирает поисковый авторитет. Команды threat intelligence, которые мониторят регистрации доменов, совпадающих с названиями популярных open-source проектов, получают фору в несколько месяцев. Те, кто ждёт срабатывания IDS на известный IoC, рискуют получить Remus Stealer на рабочей станции аналитика.

Следующий логичный шаг для TDS-операторов - расширение на разработческий стек: VS Code extensions, npm-пакеты, Docker images. Модель "проверяй хеш перед установкой" на этот объём не масштабируется. Нужны ML-модели поверх DNS-телеметрии, аналогичные тем, что уже строит Unit 42 на основе топологического анализа TDS-графов. А пока - хотя бы перестаньте качать инструменты из первой ссылки в Google.