Фишинг-кит Kali365, о котором ФБР публично предупреждало в мае, перестал быть узкой историей про Microsoft 365. По данным исследователей, теперь фишинг-кит Kali365 имитирует вход не только в M365, но и в AWS, Okta, Xerox DocuShare, а также в российские интернет-сервисы. Для русскоязычной IT-аудитории это неприятный сигнал: атака, которая обходит MFA без кражи пароля, уже работает не в одном корпоративном контуре, а сразу в нескольких привычных экосистемах.
О расширении инфраструктуры Kali365 сообщает Dark Reading со ссылкой на отчет Arctic Wolf. Исследователи описывают эволюцию сервиса phishing-as-a-service: если раньше он ассоциировался в первую очередь с компрометацией аккаунтов Microsoft 365, то теперь превращается в более универсальную платформу для захвата цифровых идентичностей. Самая заметная деталь в новой выборке целей — MAX Messenger, государственно продвигаемый российский мессенджер с аудиторией более 80 млн пользователей. Кроме него, в списке фигурируют Mail.ru, Yandex Disk и «Одноклассники».
Технически схема не нова, но по-прежнему работает слишком хорошо. Kali365 использует device code phishing — злоупотребление штатным механизмом авторизации для устройств без полноценного браузера или клавиатуры, вроде телевизоров, приставок, принтеров и другой техники, где вход подтверждается на втором устройстве. Пользователь получает письмо или другой фишинговый стимул, видит легитимный код подтверждения, вводит его на настоящей странице входа и честно проходит MFA. После этого сервис выдает токены доступа не жертве, а атакующей стороне. Пароль при этом можно вообще не красть, и именно поэтому классическое «включите многофакторку» здесь уже не выглядит достаточной мерой защиты.
Это и объясняет, почему история вышла на уровень ФБР. В своем майском предупреждении бюро отдельно указывало, что Kali365 снижает порог входа для менее квалифицированных злоумышленников: им доступны сгенерированные ИИ приманки, автоматизированные шаблоны кампаний, панели отслеживания целей в реальном времени и механика перехвата OAuth-токенов. Иначе говоря, речь не о редкой технике из арсенала одной сильной группы, а о модели, которую можно тиражировать как подписочный сервис. Для рынка это всегда плохая новость: чем проще эксплуатация, тем шире круг операторов и тем быстрее масштабируется шум.
Arctic Wolf удалось привязать активность Kali365 к живой C2-инфраструктуре и выделить кластер из 126 вредоносных хостов, активных в период с начала до конца мая. Все они обслуживали один и тот же набор инструментов, но маскировались под разные сервисы. Среди приманок были Microsoft Outlook, Microsoft Live, Okta SSO, Xerox DocuShare, немецкий почтовый провайдер GMX и даже naming conventions Amazon Web Services. Сам по себе этот список важнее отдельных брендов: перед нами уже не специализированный набор для атак на корпоративную почту Microsoft, а модульная фишинговая платформа, которую можно быстро адаптировать под нужную аудиторию, отрасль и регион.
Появление российских платформ в этой линейке особенно показательно. Arctic Wolf прямо пишет о последовательном интересе операторов к российскому потребительскому интернет-сегменту параллельно с западными корпоративными целями. Если злоумышленник умеет массово перехватывать аккаунты в крупном мессенджере, он получает не только доступ к переписке, но и канал для дальнейшего распространения атак через доверенные контакты. Для бизнеса это означает старую проблему в новой упаковке: компрометация личных или полурабочих аккаунтов сотрудников начинает влиять на корпоративный периметр, даже если исходная точка лежит вне домена компании.
На этом фоне важен и более широкий контекст. Kali365 — не единственный инструмент такого класса. Dark Reading упоминает Tycoon2FA, Venom и CYB3R, а Push Security недавно зафиксировала резкий всплеск активности device code phishing и насчитала как минимум 14 подобных наборов в открытом обороте. Часть из них — это старые phishing-as-a-service-платформы, к которым просто добавили поддержку device code flow. Часть — новые сборки, изначально заточенные под такую механику. Для защитников это означает неприятный сдвиг: раньше device code flow оставался нишевой темой для IAM-архитекторов и интеграторов, теперь его приходится учитывать в практической модели угроз наравне с классическими фишинговыми ссылками и поддельными страницами логина.
Отдельная проблема в том, что «просто запретить device code logins» на практике получается не везде. Push Security прямо предупреждает: в идеальном мире этот путь авторизации стоило бы блокировать, но для части сред это вызовет серьезные сбои, а некоторые приложения вообще не дают достаточных инструментов для тонкой настройки. Для разработчиков и DevOps-команд отсюда следует скучная, но важная работа. Нужно понимать, где в компании реально используется device authorization grant, какие сервисы выдают токены через такой сценарий, кто из сотрудников чаще взаимодействует с облачными консолями и SSO-платформами, и какие аномалии можно увидеть в логах уже после того, как пароль и MFA формально «отработали правильно».
Для CISO, IAM-команд и продуктовых владельцев облачных платформ это еще и повод пересмотреть учебные сценарии для пользователей. Обычная антифишинговая памятка про «не вводите пароль по ссылке из письма» здесь не закрывает риск, потому что пользователь действительно попадает на легитимную страницу и видит знакомый процесс входа. Значит, обучение должно объяснять саму механику device code phishing: почему неожиданный запрос на ввод кода для «доступа к документу», «проверки безопасности» или «подключения сервиса» нельзя считать нормой, даже если домен страницы выглядит безупречно. Иначе фишинг-кит Kali365 и его аналоги продолжат выигрывать за счет того, что ломают не пароль, а пользовательскую модель доверия.
Главный вопрос теперь не в том, перерастет ли device code phishing в массовую технику, а в том, насколько быстро крупные SaaS-платформы и корпоративные заказчики начнут относиться к этому потоку как к базовой, а не экзотической угрозе. Пока рынок обсуждает AI-приманки и качество шаблонов, злоумышленники уже продают более неприятную вещь: способ заставить пользователя собственноручно передать валидный токен туда, куда он точно не собирался.