В первом полугодии 2026 года на мошеннические схемы пришлось почти 46% всех срабатываний Gen, а на malvertising — еще около 30%. Но важнее не сами доли, а подмена платежей внутри привычных процессов: одно письмо из реального корпоративного ящика и один copy-paste адреса кошелька оказались достаточными, чтобы увести деньги. Для ИТ-команд это неприятный, но полезный сигнал: атакующие все реже ломятся в дверь и все чаще заходят через доверенные сценарии.
По данным BleepingComputer, Gen Threat Labs в отчете H1 2026 отдельно разобрала две кампании. Первая выглядела как обычная деловая переписка, но с неприятным апгрейдом: письма о доставке, счете или «скане документа» отправлялись не с поддельных доменов, а из уже скомпрометированных корпоративных ящиков. Целями были пользователи в Чехии, Словакии, Польше и Литве. Дальше цепочка шла по ступеням: JavaScript-дроппер, PowerShell, shellcode и банковская нагрузка, которую исследователи связали с GepyS; в финале вредонос менял прокси-настройки и ставил расширение в браузер, чтобы оказаться рядом с банковской сессией жертвы.
Здесь особенно неприятно то, что базовые почтовые проверки не обязаны были сработать. Если письмо уходит через легитимную инфраструктуру захваченной компании, SPF и DKIM могут спокойно пройти проверку, а репутационные фильтры увидят «нормального» отправителя с историей переписки. Пользователю нужно было сделать всего одну ошибку — открыть вложение. Остальное добирали скрипты и промежуточные загрузчики, причем один из них специально тормозил быстрый статический разбор: исследователи увидели мусорные MMX- и SSE-инструкции, прыжки в середину команд и схему расшифровки с LFSR-потоком и XOR. Ничего фантастического, но для SOC это ровно тот уровень трения, из-за которого инцидент доживает до банковской операции. И да, компрометация почтового ящика тут уже не прелюдия, а часть той же инфраструктуры доставки.
Контекст у отчета тоже показательный. Gen пишет, что за первые шесть месяцев 2026 года заблокировала 114,2 млн атак на фальшивые интернет-магазины и 20,3 млн атак в стиле tech support scam. На этом фоне две разобранные цепочки выглядят не как редкая экзотика, а как логичное развитие рынка: злоумышленники берут знакомый процесс и подкручивают в нем одну-две детали, которые трудно заметить в спешке. В Италии похожие сценарии вели от фальшивых PDF-счетов, в том числе с приманками под Booking.com, к скриптам на Vercel, PowerShell-этапам на Blogspot и XWorm. В Польше счета и накладные использовались для доставки стеганографического .NET-загрузчика, который ставил Remcos RAT. Региональность здесь тоже не случайна: атакующие не изобретают универсальную легенду, а подстраиваются под местные деловые привычки, знакомые сервисы и типичные документы. Проще говоря, они не ломают новую дверь, а тихо переставляют ручку на уже знакомой.
Вторая кампания была проще по действию и, пожалуй, опаснее по вероятности успеха. Финальной нагрузкой там выступал клиппер, скомпилированный на Rust: он следил за буфером обмена, распознавал адреса кошельков в 21 блокчейне, включая BTC, ETH и LTC, и подменял их на адреса злоумышленников. Криптография кошелька при этом не ломается, блокчейн не компрометируется, подпись остается валидной — меняется только получатель еще до подтверждения операции. Именно поэтому подмена платежей работает так хорошо: длинные адреса плохо читаются, а многие пользователи по привычке сверяют лишь начало и конец строки. Для атакующего этого вполне достаточно.
Отдельный интерес вызывает и способ связи с инфраструктурой. Через технику EtherHiding вредонос использовал Binance Smart Chain не как хранилище всего backend, а как публичный справочник указателей: читал данные из смарт-контракта и уже по ним выходил на текущий домен, URL или IP. Такой дизайн неприятен для защитников по очень практической причине. Текущий адрес командного сервера можно заблокировать или снять, но сама on-chain-запись остается читаемой и помогает вредоносу получить следующую точку входа. Поэтому простой список сетевых IoC в такой схеме стареет почти мгновенно. Нормальное расследование здесь должно смотреть на всю связку сразу: адрес контракта, способ чтения данных, возвращаемое значение и уже потом инфраструктуру, к которой обращается зараженная машина.
Для разработчиков и бизнеса мораль тут довольно приземленная. Если почта, рабочая станция, браузер и платежный контур живут у вас в разных мирах, такие цепочки атак пройдут между ними без особого сопротивления. Если у вас фишинг заканчивается на почтовом шлюзе, endpoint-телеметрия сидит в своей панели, а платежные проверки живут у финансовой команды без связи с ИБ, сигнал почти гарантированно потеряется между очередями и владельцами процессов. В банковском сценарии надо собирать в одну историю запуск JavaScript из вложения, PowerShell-загрузку следующих стадий, выполнение shellcode, неожиданные изменения прокси и появление нового расширения браузера. В сценарии с криптой — ловить процессы, которые меняют буфер обмена, распознают шаблоны адресов кошельков или зачем-то делают blockchain-запросы, хотя их роль в системе этого не требует. Практические меры у Gen без сюрпризов, зато по делу: ограничивать интерпретаторы скриптов там, где они не нужны, применять контроль запуска к скачанным вложениям, мониторить захват почтовых ящиков и не считать письмо безопасным только потому, что у него честно прошли SPF и DKIM. Для операций с криптовалютой совет еще скучнее, но полезнее любой магии: подтверждать полный адрес получателя на устройстве подписи, а не первые и последние символы, и относиться к новым или изменившимся реквизитам как к отдельному событию риска.
Главный тренд здесь не в конкретных семьях вредоносов и не в очередном наборе индикаторов. И почтовая атака, и клиппер показывают одну вещь: подмена платежей все чаще происходит не через взлом «ядра» системы, а через аккуратное редактирование доверенного маршрута между письмом, браузером, буфером обмена и кнопкой подтверждения. Для команд защиты это означает сдвиг от охоты за одиночными артефактами к сборке полной последовательности действий пользователя и процесса. Детали разбора опубликованы в материале .