До 2,37 млн фишинговых писем в день проходили через кампанию, где злоумышленники использовали ASCII smuggling: вставляли невидимые Unicode-символы внутрь финансовых слов, чтобы сбивать почтовые фильтры. Для русскоязычных IT-команд это неприятное напоминание: сигнатуры и списки ключевых слов ломаются не только сложной обфускацией, но и символом, которого пользователь вообще не видит.
О кампании сообщает BleepingComputer со ссылкой на исследователей Microsoft. По их данным, техника активно применялась в массовой финансовой фишинговой рассылке и достигла пика в конце февраля 2026 года. Высокий объем держался примерно три месяца после 9 февраля, а после 15 мая резко снизился. При этом Microsoft отдельно уточняет: эти даты описывают именно период наблюдаемого использования конкретного приема в телеметрии компании, а не всю кампанию целиком. Сама операция началась раньше и продолжалась уже без этой техники.
Механика атаки выглядит почти издевательски просто. В письмо вставляют приманку на тему финансирования, кредитов или бизнес-займов, но ключевые слова разрывают символами из Unicode-блока Tags, диапазон U+E0000–U+E007F. В интерфейсе почтового клиента такое слово выглядит нормальным или почти нормальным, а для фильтра, который ищет подозрительные термины по словарю или регулярному выражению, оно уже может оказаться другим набором символов. Условное слово «funding» превращается в конструкцию с невидимой вставкой посередине и перестает совпадать с ожидаемым шаблоном.
ASCII smuggling уже всплывал в другом контексте — в атаках на ИИ-ассистентов и prompt injection. Там невидимые Unicode-символы использовались для скрытия инструкций: человек видит один текст, модель или обработчик получает другой. Теперь тот же класс приема переехал в массовый фишинг. Ничего мистического: атакующие берут технику, которая помогает обмануть один слой обработки текста, и проверяют, какие еще системы достаточно доверчивы к «невидимому» вводу.
Microsoft обнаружила 9 февраля кластер из 148 доменов отправителей, связанных с финансовой тематикой. На них приходилось около 96% всех сообщений, которые новая логика поиска в Defender for Office 365 пометила по признакам Unicode-tag-сигнатур. В доменах и письмах встречались слова вроде funding, capital, loan, advance и credit, а сами сообщения продвигали финансирование бизнеса, займы и кредитные услуги. Рассылки шли через инфраструктуру, связанную с легитимной платформой email-маркетинга ActiveCampaign, что добавляет кампании правдоподобия: письмо приходит не с очевидно грязного сервера, а через сервис, которым действительно пользуются компании.
После сообщения Microsoft о злоупотреблении ActiveCampaign заявила, что ее системы модерации распознают невидимые Unicode-символы так же, как обычный текст без обфускации, а их массовое использование считают подозрительным сигналом. Это важная деталь для корпоративной почты: проблема не только в конкретной платформе рассылок, а в цепочке доверия. Маркетинговые сервисы, CRM, формы заявок, helpdesk-системы и почтовые шлюзы давно стали частью маршрута доставки сообщений. Если один из участков пропускает странный текст как нормальный, нагрузка уходит на следующий фильтр.
Хорошая новость в отчете тоже есть: по данным Microsoft, Defender все равно поймал более 99% таких писем за счет других сигналов — отправителя, IP-адреса, домена, репутационных проверок и связанных индикаторов. Плохая новость очевидна: если защита держится только на поиске слов в теле письма, она становится хрупкой. Для небольших компаний, которые используют самописные правила в почтовом шлюзе или простые регулярные выражения в антифрод-пайплайнах, невидимый Unicode может оказаться не экзотикой, а вполне практичным обходом.
Для разработчиков и security-инженеров главный вывод скучный, но рабочий: входящий текст нужно нормализовать до анализа. Microsoft рекомендует удалять или приводить к безопасному виду Unicode tag characters и другие невидимые кодовые точки до применения keyword matching, regex-правил и сигнатур. Неожиданные символы из Tags-блока стоит считать сильной аномалией, особенно в письмах, формах, тикетах и сообщениях, которые дальше попадают в автоматическую обработку. Это касается не только антифишинга: те же правила полезны перед передачей текста ИИ-ассистентам, чтобы снизить риск prompt injection через скрытые инструкции.
Для бизнеса история с ASCII smuggling показывает, что фишинг продолжает двигаться туда, где дешевле всего ломать защиту: не в сложную эксплуатацию уязвимостей, а в несоответствие между тем, что видит человек, и тем, что парсит машина. Чем больше процессов завязано на автоматическую обработку писем, лидов и заявок, тем важнее проверять не только «что написано», но и «какими символами это написано». Следующий виток, похоже, будет не про красивые фейковые логины, а про грязный текстовый ввод, который выглядит чистым ровно до первого нормализатора.