Исследователи Confiant в отчёте от 23 июля 2026 года описали малвертайзинг-операцию SourTrade, которая работает как минимум с конца 2024 года. Автор публикации, специалист по угрозам Michael Steele, обратил внимание на деталь, которая делает эту схему заметно отличной от обычной раздачи заражённых установщиков: итоговый исполняемый файл для Windows не скачивается целиком с какого-то одного адреса, а буквально собирается внутри браузера жертвы из кусков, каждый из которых сам по себе выглядит безобидно.
Мошенники маскируются под известные в трейдинге и криптомире бренды — TradingView, Solana и Luno. Целевая аудитория — розничные трейдеры и держатели криптовалюты, а география охвата впечатляет: кампания зафиксирована в 12 странах и переведена на 25 языков. Это не локальная афера на пару регионов, а вполне отлаженный конвейер, рассчитанный на массовый охват.
Первый барьер, с которым сталкивается любой, кто заходит на фейковую страницу, — это фингерпринтинг. Система пытается определить, кто перед ней: живой пользователь из целевой группы или исследователь безопасности, бот, автоматизированный сканер. Подозрительным посетителям показывают пустую страницу — там просто нет ничего интересного для анализа. А вот отобранным жертвам открывается убедительная копия сервиса, под который маскируется кампания, — с логотипами, интерфейсом и всем, что должно убедить человека, что перед ним настоящий TradingView, Solana или Luno.
Технически цепочка доставки не использует уязвимости браузера — эксплойтов здесь нет. Confiant честно признаёт, что их анализ ограничен именно доставкой файла на диск, а что происходит дальше — уже вопрос отдельный, и авторы отчёта даже не берутся утверждать, происходит ли финальное скачивание автоматически или требует клика пользователя.
Сама механика сборки выглядит так. Ещё до того как пользователь нажимает кнопку загрузки, страница регистрирует ServiceWorker по адресу /sw.js, привязанный к конкретной странице. Затем из JavaScript-кода, который уже встроен в саму страницу, создаётся SharedWorker — благодаря этому исходный код воркера никогда не появляется в виде отдельного сетевого запроса, что усложняет обнаружение. Этот SharedWorker обращается к /config, откуда получает шаблон файла, адрес второго домена с runtime и набор случайных значений, уникальных для сессии.
Дальше браузер скачивает и распаковывает чистый, легитимный Bun runtime со второго домена — в одном из образцов это был purelogicbox[.]org. Сам конфиг при этом содержит закодированные в Base64 куски будущего исполняемого файла: заголовок PE, таблицу секций и секцию.bun с вредоносным байткодом JavaScriptCore для файла app.js. Здесь стоит вспомнить, что Bun работает на движке JavaScriptCore от Apple и вполне легально умеет компилировать приложения и байткод в самостоятельные исполняемые файлы для Windows — злоумышленники просто использовали штатную возможность легитимного инструмента.
Чтобы усложнить обнаружение по хэшу, воркер генерирует большой псевдослучайный поток байт с помощью AES в режиме счётчика (AES-CTR). Каждый пользователь получает файл, собранный чуть иначе, чем предыдущий — ротация seed и размера в каждом ответе /config меняет хэш готового файла, хотя вредоносный код внутри остаётся тем же. После сборки страница передаёт готовый исполняемый файл сервис-воркеру как поток для чтения.
Steele формулирует суть приёма фразой: «Готового вредоноса в сети никогда не существует». Формулировка не совсем точная — как раз структуры PE-файла и байткод действительно передаются по сети, просто в виде закодированных Base64-фрагментов внутри /config, а не единым скомпонованным бинарником. Разница тонкая, но важная для тех, кто строит защиту на основе анализа трафика.
Есть и любопытный нюанс с Mark of the Web — меткой, которую Windows ставит на файлы, скачанные из интернета. MotW в этой схеме не удаляется вовсе, она остаётся на месте. Но поскольку файл технически формируется на странице лендинга, именно она и записывается как источник загрузки — а не домен, откуда на самом деле пришёл Bun runtime.
Схема эволюционировала. До 30 апреля 2026 года страницы напрямую подгружали открытую библиотеку StreamSaver.js (она отвечает за потоковую загрузку файлов) с GitHub Pages автора этой библиотеки — из-за этого в журнале загрузок фигурировал адрес GitHub. Нынешняя версия сохранила архитектуру потоковой передачи и даже названия сообщений вроде streamsaver:, но перестала напрямую обращаться к GitHub, убрав тем самым один из явных следов.
Confiant пытается связать SourTrade с другим кластером атак, о котором в сентябре 2025 года писала Bitdefender: там финальной нагрузкой был стилер, известный под именами JSCEAL (по классификации Check Point) и WeevilProxy (термин WithSecure), а сама Bitdefender детектировала его как Variant.DenoSnoop.Marte.1. В отчёте Confiant упоминается, что Bitdefender якобы обнаружила модифицированный исполняемый файл Bun именно в этом кластере, что и подтолкнуло исследователей провести параллель между кампаниями. Однако три опубликованных образца из SourTrade так и не были доказательно связаны с этим конкретным payload — Confiant говорит лишь об общих чертах кампании и исполняемого файла, но не о прямом совпадении.
Проверка The Hacker News дала иной результат: в самом сентябрьском посте Bitdefender, на который ссылается Confiant, никакого упоминания Bun не нашлось. Из этого следует, что функции, которые описывались в более ранней кампании — кража учётных данных, кейлоггинг, перехват трафика, воровство криптокошельков, удалённый доступ к системе — пока нельзя однозначно приписать нынешним файлам SourTrade. Редакция направила запрос в Confiant с просьбой прояснить это несоответствие и обещает обновить материал при получении ответа.
С точки зрения защиты патча для такой техники просто не существует — это не уязвимость софта, а особенность работы веб-стандартов ServiceWorker и SharedWorker. Сама Confiant признаёт, что реальный эффект обхода детекции скромнее, чем может показаться: уникальная сборка под каждую сессию мешает в первую очередь простому поиску по хэшу файла, но не более того. PE-структуры и вредоносный байткод, контролируемые атакующими, всё равно проходят по сети — просто не в виде одного цельного файла, а раздробленными на куски внутри JSON-ответа /config. Поэтому разумный подход для защитников — смотреть не на один артефакт, а на всю цепочку целиком: переход по рекламе, замаскированную страницу лендинга, запрос к /config, загрузку runtime со второго домена и итоговую передачу через ServiceWorker.
В качестве индикаторов компрометации Confiant опубликовала три хэша SHA-256 и список вредоносных доменов, который The Hacker News насчитала в объёме 96 записей. Конкретного актора угрозы за кампанией никто не назвал. И сама Confiant прямо говорит: анализ остановился в момент попадания файла на диск жертвы — что происходит при его запуске, исследователи не проверяли.
Мошенники маскируются под известные в трейдинге и криптомире бренды — TradingView, Solana и Luno. Целевая аудитория — розничные трейдеры и держатели криптовалюты, а география охвата впечатляет: кампания зафиксирована в 12 странах и переведена на 25 языков. Это не локальная афера на пару регионов, а вполне отлаженный конвейер, рассчитанный на массовый охват.
Первый барьер, с которым сталкивается любой, кто заходит на фейковую страницу, — это фингерпринтинг. Система пытается определить, кто перед ней: живой пользователь из целевой группы или исследователь безопасности, бот, автоматизированный сканер. Подозрительным посетителям показывают пустую страницу — там просто нет ничего интересного для анализа. А вот отобранным жертвам открывается убедительная копия сервиса, под который маскируется кампания, — с логотипами, интерфейсом и всем, что должно убедить человека, что перед ним настоящий TradingView, Solana или Luno.
Технически цепочка доставки не использует уязвимости браузера — эксплойтов здесь нет. Confiant честно признаёт, что их анализ ограничен именно доставкой файла на диск, а что происходит дальше — уже вопрос отдельный, и авторы отчёта даже не берутся утверждать, происходит ли финальное скачивание автоматически или требует клика пользователя.
Сама механика сборки выглядит так. Ещё до того как пользователь нажимает кнопку загрузки, страница регистрирует ServiceWorker по адресу /sw.js, привязанный к конкретной странице. Затем из JavaScript-кода, который уже встроен в саму страницу, создаётся SharedWorker — благодаря этому исходный код воркера никогда не появляется в виде отдельного сетевого запроса, что усложняет обнаружение. Этот SharedWorker обращается к /config, откуда получает шаблон файла, адрес второго домена с runtime и набор случайных значений, уникальных для сессии.
Дальше браузер скачивает и распаковывает чистый, легитимный Bun runtime со второго домена — в одном из образцов это был purelogicbox[.]org. Сам конфиг при этом содержит закодированные в Base64 куски будущего исполняемого файла: заголовок PE, таблицу секций и секцию.bun с вредоносным байткодом JavaScriptCore для файла app.js. Здесь стоит вспомнить, что Bun работает на движке JavaScriptCore от Apple и вполне легально умеет компилировать приложения и байткод в самостоятельные исполняемые файлы для Windows — злоумышленники просто использовали штатную возможность легитимного инструмента.
Чтобы усложнить обнаружение по хэшу, воркер генерирует большой псевдослучайный поток байт с помощью AES в режиме счётчика (AES-CTR). Каждый пользователь получает файл, собранный чуть иначе, чем предыдущий — ротация seed и размера в каждом ответе /config меняет хэш готового файла, хотя вредоносный код внутри остаётся тем же. После сборки страница передаёт готовый исполняемый файл сервис-воркеру как поток для чтения.
Steele формулирует суть приёма фразой: «Готового вредоноса в сети никогда не существует». Формулировка не совсем точная — как раз структуры PE-файла и байткод действительно передаются по сети, просто в виде закодированных Base64-фрагментов внутри /config, а не единым скомпонованным бинарником. Разница тонкая, но важная для тех, кто строит защиту на основе анализа трафика.
Есть и любопытный нюанс с Mark of the Web — меткой, которую Windows ставит на файлы, скачанные из интернета. MotW в этой схеме не удаляется вовсе, она остаётся на месте. Но поскольку файл технически формируется на странице лендинга, именно она и записывается как источник загрузки — а не домен, откуда на самом деле пришёл Bun runtime.
Схема эволюционировала. До 30 апреля 2026 года страницы напрямую подгружали открытую библиотеку StreamSaver.js (она отвечает за потоковую загрузку файлов) с GitHub Pages автора этой библиотеки — из-за этого в журнале загрузок фигурировал адрес GitHub. Нынешняя версия сохранила архитектуру потоковой передачи и даже названия сообщений вроде streamsaver:, но перестала напрямую обращаться к GitHub, убрав тем самым один из явных следов.
Confiant пытается связать SourTrade с другим кластером атак, о котором в сентябре 2025 года писала Bitdefender: там финальной нагрузкой был стилер, известный под именами JSCEAL (по классификации Check Point) и WeevilProxy (термин WithSecure), а сама Bitdefender детектировала его как Variant.DenoSnoop.Marte.1. В отчёте Confiant упоминается, что Bitdefender якобы обнаружила модифицированный исполняемый файл Bun именно в этом кластере, что и подтолкнуло исследователей провести параллель между кампаниями. Однако три опубликованных образца из SourTrade так и не были доказательно связаны с этим конкретным payload — Confiant говорит лишь об общих чертах кампании и исполняемого файла, но не о прямом совпадении.
Проверка The Hacker News дала иной результат: в самом сентябрьском посте Bitdefender, на который ссылается Confiant, никакого упоминания Bun не нашлось. Из этого следует, что функции, которые описывались в более ранней кампании — кража учётных данных, кейлоггинг, перехват трафика, воровство криптокошельков, удалённый доступ к системе — пока нельзя однозначно приписать нынешним файлам SourTrade. Редакция направила запрос в Confiant с просьбой прояснить это несоответствие и обещает обновить материал при получении ответа.
С точки зрения защиты патча для такой техники просто не существует — это не уязвимость софта, а особенность работы веб-стандартов ServiceWorker и SharedWorker. Сама Confiant признаёт, что реальный эффект обхода детекции скромнее, чем может показаться: уникальная сборка под каждую сессию мешает в первую очередь простому поиску по хэшу файла, но не более того. PE-структуры и вредоносный байткод, контролируемые атакующими, всё равно проходят по сети — просто не в виде одного цельного файла, а раздробленными на куски внутри JSON-ответа /config. Поэтому разумный подход для защитников — смотреть не на один артефакт, а на всю цепочку целиком: переход по рекламе, замаскированную страницу лендинга, запрос к /config, загрузку runtime со второго домена и итоговую передачу через ServiceWorker.
В качестве индикаторов компрометации Confiant опубликовала три хэша SHA-256 и список вредоносных доменов, который The Hacker News насчитала в объёме 96 записей. Конкретного актора угрозы за кампанией никто не назвал. И сама Confiant прямо говорит: анализ остановился в момент попадания файла на диск жертвы — что происходит при его запуске, исследователи не проверяли.
