Microsoft обнаружила фишинговую кампанию, в которой техника ASCII smuggling использовалась не против ИИ-ассистентов, а против обычных почтовых фильтров: на пике в конце февраля система видела более 2,37 млн таких писем. Для русскоязычных команд безопасности это неприятный сигнал: приемы из исследований по AI security быстро переезжают в старый добрый спам, где масштаб важнее изящества.
О кампании сообщает The Register со ссылкой на исследователей Microsoft Ноама Кохави и Сару Волстенкрофт. По их данным, первые срабатывания сигнатуры появились в начале февраля 2026 года: 8 февраля было зафиксировано около 21 тыс. сообщений, а уже на следующий день объем вырос до более чем 1,3 млн. Основной пик пришелся на 26 февраля, когда число писем превысило 2,37 млн.
Сама идея выглядит почти раздражающе простой. В классическом варианте ASCII smuggling прячет текст внутри невидимых или неотображаемых Unicode-символов. В контексте ИИ это чаще обсуждали как способ подсунуть модели скрытую инструкцию: человек открывает документ или страницу и ничего подозрительного не видит, а модель считывает невидимые символы как текст и может выполнить нежелательную команду. Microsoft ожидала найти именно такие скрытые промпты, но обнаружила более прозаичный трюк.
Злоумышленники вставляли невидимые Unicode tag characters внутрь финансовых слов в письмах. Например, слово вроде funding разбивалось невидимым символом между буквами. Для человека оно по-прежнему читалось нормально, а простая проверка по ключевому слову, регулярному выражению или буквальной сигнатуре могла не сработать. Это не атака на большую языковую модель, не хитрая jailbreak-конструкция и не демонстрация из лаборатории. Это массовая попытка пролезть через фильтры, которые слишком буквально смотрят на текст.
Большая часть писем шла примерно со 150 доменов с финансовой тематикой. Поведение кампании тоже было характерным: активность резко росла по будням и почти замирала на выходных. После первой интенсивной фазы объемы держались на уровне 1-2,37 млн сообщений в рабочие дни, затем к концу марта снизились примерно на 80% относительно пиковых значений. После 15 мая активность заметно просела, но отдельные меньшие всплески продолжались как минимум до середины июня.
Для защитников главный урок здесь не в том, что Unicode снова оказался сложнее, чем кажется. Это и так знают все, кто хоть раз разбирал проблемы с нормализацией строк, похожими символами и многоязычным вводом. Важнее другое: фильтры, которые работают с текстом до нормализации, дают атакующим дешевый способ ломать совпадения. Если система ищет финансовые приманки по словам, сигнатурам или regex-правилам, она должна сначала привести входной текст к форме, где невидимые и неотрисовываемые кодовые точки удалены или свернуты.
Microsoft прямо указывает на нормализацию и токенизацию как на ключевую линию защиты. Все, что дальше попадает в keyword matching, сигнатуры, регулярные выражения, антиспам-эвристику или ML-классификатор, должно обрабатываться согласованно. Иначе одна часть пайплайна видит слово целиком, другая видит разорванную последовательность, третья вообще сохраняет невидимые символы как значимые. В такой архитектуре атакующему не нужно быть гением: достаточно знать, где почтовый шлюз смотрит на строку слишком наивно.
Есть и второй практический слой: поведенческие индикаторы. В этой кампании они были довольно громкими — резкий рост tag-block characters, концентрация вокруг финансовых отправителей, массовая рассылка с одноразовых доменов, включение по будням и выключение на выходные. Такой профиль полезен не только для почтовых команд, но и для SOC: если контентная проверка промахнулась, а телеметрия по доменам, расписанию и аномальным символам собрана нормально, кампанию все еще можно поймать.
Для разработчиков корпоративных продуктов это еще один аргумент не относиться к Unicode как к «проблеме фронтенда». Почтовые клиенты, CRM, helpdesk, DLP, SIEM-коннекторы и внутренние ИИ-ассистенты все чаще проглатывают одни и те же письма, документы и тикеты. Если один компонент очищает невидимые символы, а другой передает их дальше в LLM или поисковый индекс, поверхность атаки остается. Особенно неприятно это для компаний, которые уже подключают ИИ к почте, базе знаний и финансовым workflow: старый фишинг и новые AI-риски начинают делить один и тот же входной поток.
История с ASCII smuggling хорошо показывает, как быстро исследовательские приемы теряют лабораторный блеск и превращаются в расходный материал для массовых рассылок. Следующий вопрос для команд безопасности простой и не очень удобный: сколько их фильтров, парсеров и ИИ-интеграций проверяют текст уже после нормализации, а сколько все еще верят, что если слово выглядит нормальным для человека, то машина увидит то же самое?