По телеметрии ANY.RUN, с кампанией Kali365 связано более 80 публичных sandbox-сессий в неделю, и основной фокус у нее, компании в США. Атака Kali365 опасна тем, что не крадет пароль через фальшивую форму, а заводит сотрудника на настоящую страницу входа Microsoft и просит подтвердить код, который заранее создал злоумышленник. Для команд, где Microsoft 365 держит почту, файлы и согласования, это плохая новость: доверенный логин больше нельзя считать безопасным по умолчанию.
5 августа 2026 года, как пишет The Hacker News, речь шла о фишинговом наборе, который злоупотребляет штатным device code flow Microsoft. Сценарий простой и неприятный: жертве показывают приманку под SharePoint, OneDrive или DocuSign, затем перекидывают на легитимный портал Microsoft для ввода кода устройства, а после подтверждения злоумышленник получает выпущенные для своей сессии access token и refresh token. В одной из публичных сессий ANY.RUN фигурировала приманка под SharePoint, но сама механика не привязана к одному бренду внутри Microsoft 365: подойдет любой сервис, которому сотрудники привыкли доверять без лишних вопросов.
Технически схема коварна еще и потому, что device code flow сам по себе легитимен: он нужен для устройств и сценариев, где неудобно вводить логин и пароль прямо в приложении. Kali365 не ломает этот механизм, а паразитирует на нем. Сотруднику кажется, что он просто подтверждает доступ к документу или сервису, а на деле завершает авторизацию для чужой сессии. Поэтому привычный совет «проверьте адресную строку» здесь работает заметно хуже: адрес может быть правильным, домен настоящим, а вредоносной частью становится контекст, в котором пользователя к этому домену подвели.
Именно это делает схему заметно противнее классического фишинга. Пользователь видит знакомый домен Microsoft, проходит обычный путь авторизации и не натыкается на очевидную подделку. Если токены выданы, атакующий может удерживать доступ к почте, документам и облачным ресурсам компании даже без повторного ввода пароля, а дальше начинается уже вполне приземленная корпоративная боль: подмена инвойсов, платежное мошенничество, сценарии BEC, утечка внутренних файлов, сбои в ежедневных коммуникациях и длинный, дорогой инцидент-респонс. Источник отдельно подчеркивает и комплаенс-риск: если под ударом клиентские или регулируемые данные, юридические последствия приходят почти сразу после технических.
На более широком уровне это продолжение тренда, который безопасники наблюдают не первый год: после ужесточения MFA преступники все чаще охотятся не за паролем, а за уже выданной сессией и токенами доступа. Атака Kali365 хорошо ложится в эту логику, потому что злоумышленнику не нужно обходить периметр Microsoft, он просто встраивается в легитимный процесс. Отсюда и неприятный вывод для SOC: почтового фильтра и проверки домена отправителя здесь мало. Сигналы опасности надо искать раньше, в приманке, редиректах, скриптах, поведении браузера и в том, откуда вообще взялся код устройства, который сотрудника просят подтвердить.
В статье много vendor-подачи от ANY.RUN, но несколько практических мыслей там полезны. Первая: индикаторы компрометации в таких кампаниях быстро устаревают, потому что операторы меняют домены, URL и хостинг по ходу атаки, значит свежие IOC нужно сразу прокидывать в SIEM, SOAR, TIP и сетевые средства блокировки. Вторая: аналитикам первой линии нужен не только вердикт «фишинг», а вся цепочка событий до входа в Microsoft, иначе расследование зависает на ложном ощущении, что пользователь просто нормально залогинился. Третья: охота за этой активностью уже требует не единичного алерта, а нормального threat hunting. В качестве примера приводится запрос threatName:"kali365" AND submissionCountry:"US", по которому в ANY.RUN видят активность в производстве, технологиях, здравоохранении, госсекторе, консалтинге и у MSSP.
По собственным оценкам ANY.RUN, их подход сокращает triage на 94%, уменьшает MTTR до 21 минуты на кейс, снижает нагрузку на Tier 1 до 20% и на 30% уменьшает число эскалаций на Tier 2. Эти цифры лучше читать как вендорскую оценку, а не как независимый бенчмарк, но проблема описана точно: фишинг через Microsoft 365 давно перестал быть историей только про почту. Для русскоязычных команд, особенно тех, кто работает с зарубежными клиентами и держит процессы в Microsoft 365, практический вывод простой: нужно уметь быстро отзывать токены и сессии, отслеживать подозрительные подтверждения device code и видеть не только факт успешного логина, но и всю цепочку до него. Иначе атака Kali365 будет выглядеть как обычная рабочая активность ровно до момента, когда из облака начнут уходить документы или в платежной цепочке появится «срочный» обновленный счет.
Kali365 неприятен не масштабом, а тем, что бьет по старому инстинкту доверия: если страница входа настоящая, значит все в порядке. В облачной инфраструктуре 2026 года это уже не работает. Следующий этап для корпоративной защиты, оценивать не только поддельность интерфейса, но и происхождение каждой авторизации, каждой сессии и каждого токена, который получает доступ к почте, файлам и бизнес-процессам. Подробнее об исходной кампании: .