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