Киберпреступность
Скомпрометированный почтовый ящик теперь может раскрыть всю цепочку платежей
После операции Microsoft против EvilTokens нужно изменить ключевое допущение о мошенничестве: контроль над почтовым ящиком больше не служит надёжным подтверждением изменения платежа. Сервис сочетал фишинг через device code, кражу токенов и ИИ-анализ переписки для поиска доверенных связей и платёжных полномочий.

Раньше компрометация почтового ящика предполагала привычную последовательность действий: сменить пароль, проверить правила пересылки, предупредить контакты. Операция Microsoft против EvilTokens, объявленная 22 сентября, делает бизнес-последствие более конкретным. Получив контроль над ящиком, злоумышленники могут с помощью ИИ построить рабочую карту доверенных связей, платёжных полномочий и правдоподобных целей для имитации. Почтовый ящик — это не только похищенная переписка. Это материал для подготовки платёжного мошенничества.
Из этого следует изменить допущение, которое во многих компаниях всё ещё действует неявно: письмо с известного адреса не является достаточным доказательством для смены банковских реквизитов, необычного перевода или срочного платёжного указания. Оно может быть настоящим. Но его может составить и злоумышленник, уже прочитавший достаточно переписки, чтобы понять, кто утверждает платежи, каким поставщикам доверяют и каким языком обычно общаются стороны.
Что именно нарушила операция Microsoft
Microsoft назвала EvilTokens первым случаем, когда её подразделение Digital Crimes Unit приняло меры против сквозного киберпреступного сервиса с ИИ. По данным компании, санкционированная судом операция нарушила работу инфраструктуры, связанной с сервисом; параллельно Microsoft и Health-ISAC вели гражданское судебное дело. Microsoft сообщила об изъятии 50 сайтов и отключении более 150 дополнительных доменов. Coinbase, предоставившая материалы для гражданского дела, сообщила о 50 сайтах и более чем 175 доменах. Точные числа в этих сообщениях различаются, однако оба источника описывают состоявшееся нарушение инфраструктуры, а не предупреждение о гипотетической угрозе.
Microsoft связала EvilTokens с более чем 12 000 скомпрометированных почтовых ящиков в более чем 10 000 организациях, включая здравоохранение, финансовые услуги, строительство, недвижимость и высшее образование. Это наблюдаемые Microsoft показатели, а не независимо проверенная глобальная статистика. Отдельно Coinbase сообщила, что отследила около 1,1 млн долларов выручки сервиса на четырёх адресах Tron в период с октября 2025 года по июнь 2026 года: более 1 000 депозитов с более чем 700 адресов.
Сервис не использовал криптографическую уязвимость в аутентификации Microsoft и не взламывал многофакторную аутентификацию. Он злоупотреблял легитимным входом через device code. Жертву убеждали ввести код на настоящем сайте аутентификации Microsoft, после чего она сама авторизовала сессию злоумышленника. Затем EvilTokens сочетал этот доступ с инструментами работы с почтой и ИИ-анализатором, который искал в ящике полезные связи, платёжные паттерны и возможности для мошенничества.
Формулировка Coinbase хорошо передаёт операционное изменение: работа, которая прежде требовала часов ручного изучения почты, могла превращаться в почти мгновенный автоматизированный выбор цели. ИИ не был причиной всех сообщённых компрометаций и не был единственной частью схемы. Но он сократил время и требуемую квалификацию для превращения доступа в убедительную, адресную попытку мошенничества.
Что не изменилось
Операция не устраняет компрометацию деловой почты и мошенничество с применением ИИ. И Microsoft, и Coinbase рассматривают модель EvilTokens как ту, что, вероятно, будет воспроизводиться. Злоумышленникам по-прежнему требовалось убедить жертв авторизовать легитимный поток входа, а успешное мошенничество всё ещё зависит от того, примет ли организация ложное указание. Ликвидация инфраструктуры может прервать работу оператора. Но она не отменяет метод, соединяющий социальную инженерию, скомпрометированную идентичность и знания, извлечённые из обычной деловой переписки.
Это также не означает, что любое платёжное письмо следует считать мошенническим или что от электронной почты нужно отказаться как от делового канала. Практический вывод уже: письмо может запустить процесс изменения платежа, но не должно завершать проверку, необходимую для изменения реквизитов или утверждения нестандартного перевода. Контроль над ящиком — часть утверждения, но не независимое доказательство его достоверности.
Вынесите проверку платежа за пределы почты
Для руководителей финансов, закупок и кредиторской задолженности ближайшее решение — процессное. Запрос на изменение платёжных инструкций, перенаправление средств или исключительный перевод необходимо подтвердить по известному второму каналу. Слово «известному» здесь принципиально. Сотрудники должны использовать телефон, карточку контакта или защищённый процесс, уже имеющиеся у организации, а не реквизиты, указанные в проверяемом письме.
Контроль нужно проектировать вокруг последствий, а не вокруг убедительности письма. Запрос может прийти с настоящего аккаунта, ссылаться на реальный счёт и имитировать стиль реального руководителя. Ничто из этого не доказывает подлинность текущего указания. Для существенных изменений обязательным шагом должен быть независимо инициированный обратный звонок или другой установленный путь проверки — с записью, кто, что и когда подтвердил.
Это не только контроль службы безопасности. Это финансовый операционный контроль, поддержанный безопасностью. Командам кредиторской задолженности нужно ясное правило, позволяющее замедлить даже внешне срочный запрос. Руководители и поставщики должны знать, что обратный звонок — нормальная процедура, а не проявление недоверия. Лучший дизайн снимает усмотрение там, где социальное давление наиболее сильно: нет независимого подтверждения — нет изменения платёжных реквизитов.
Устраняйте сессию, а не только меняйте пароль
Компонент с device code меняет и реакцию на инцидент. Microsoft и Coinbase предупреждают: доступ злоумышленника может сохраниться после смены пароля, если не отозваны активные сессии и токены. Смена пароля необходима при подозрении на компрометацию, но сама по себе она не завершает восстановление.
Поэтому в планы реагирования следует прямо включить отзыв активных сессий и токенов, проверку несанкционированных регистраций устройств, а также проверку правил почтового ящика и других скрытых изменений. Организациям также следует оценить, нужно ли ограничить аутентификацию через device code для пользователей или сценариев, где она не требуется. Верная настройка зависит от того, как именно компания использует этот поток входа; массовое изменение без понимания операционных зависимостей само может вызвать сбой.
Эта последовательность важна, потому что каждый шаг закрывает отдельный путь сохранения доступа. Новый пароль меняет один учётный секрет. Отзыв токенов и сессий завершает уже авторизованный доступ. Проверка устройств и правил почты ищет механизмы, способные вернуть видимость или сохранить доступ после смены очевидного секрета. Если объединить всё в общую задачу «сбросить аккаунт», слишком легко провести лишь частичную очистку.
Граница безопасности теперь проходит через бизнес-процесс
EvilTokens примечателен не тем, что сделал каждого злоумышленника автономным, а тем, что ускорил интерпретацию после компрометации. Во входящих содержится организационный контекст: имена, линии подчинения, переписка с поставщиками, привычки согласования, сроки и исключения. ИИ-анализатор способен превратить этот контекст в короткий список возможностей для мошенничества быстрее, чем оператор, читающий письма по одному.
Адекватный ответ — не требовать от сотрудников распознать каждую качественно выполненную имитацию. Нужно сделать так, чтобы значимые бизнес-процессы не полагались на канал, наиболее полезный для имитатора. Платёжные процессы должны требовать независимого подтверждения; реагирование на инциденты — отзывать доступ, который не устраняет простая смена пароля; а команды должны отрепетировать эти действия до появления следующего срочного запроса.
Операция Microsoft нарушила работу одного сервиса и связанной с ним инфраструктуры. Это существенно. Но устойчивый вывод требовательнее: почтовый ящик доказывает лишь то, что сообщение прошло через этот ящик. Он не доказывает, что человек, который обычно им управляет, одобрил содержащееся в нём указание.

