Статья Атаки через Microsoft Teams: кража учётных данных и обход MFA — техники и защита

Device code phishing через штатный OAuth-флоу Microsoft, кража сессионных токенов в обход MFA (полный разбор этих и смежных техник - в гайде по атакам на аутентификацию), вишинг через Teams с захватом рабочих станций через Quick Assist - эти векторы атак на Microsoft 365 фиксируются всё чаще. Кампании затрагивают сотни организаций за считанные недели. И в каждом случае Teams - точка входа, а почтовые фильтры вообще не при делах. Ни один из этих векторов не проходит через email.

Kill chain: Teams в роли точки входа​

Microsoft Teams - не мессенджер для стикеров. Это OAuth-клиент с доступом к Microsoft Graph API, файловым хранилищам SharePoint и Entra ID (Azure AD). Компрометация через Teams даёт атакующему не пароль в открытом виде, а живой токен с правами пользователя внутри тенанта. Поэтому identity attack Microsoft 365 всё чаще начинается не с почтового ящика, а с чата.

Маппинг атак через Microsoft Teams на MITRE ATT&CK:

Этап	Техника MITRE ATT&CK	Как это работает в Teams
Initial Access	Spearphishing via Service (T1566.003)	Фишинг через External Access или Guest Access
Credential Access	MFA Interception (T1111)	AiTM-прокси перехватывает токен при аутентификации
Credential Access	MFA Request Generation (T1621)	Бомбардировка push-уведомлениями после получения пароля
Credential Access	Steal Web Session Cookie (T1539)	Кража сессионных cookie через AiTM или малварь
Lateral Movement	Internal Spearphishing (T1534)	Фишинг от скомпрометированного аккаунта внутри тенанта
Collection	Messaging Applications (T1213.005)	Извлечение данных из чатов, файлов, записей звонков
Persistence	Cloud Accounts (T1078.004)	Удержание доступа через refresh-токены облачного аккаунта

После получения токена через любой из векторов атакующий действует внутри легитимной инфраструктуры Microsoft 365. Для SOC это выглядит как обычная работа пользователя - пока не настроены правильные корреляции.

Три вектора фишинга через Microsoft Teams​

Вишинг: звонки от «ИТ-поддержки»​

Кампания, зафиксированная Microsoft (по данным secpost.ru), шла через банальную социальную инженерию в корпоративном мессенджере. Атакующий отправлял сотрудникам внешние запросы на переписку в Teams, представляясь службой поддержки. Несколько человек отказались - но один предоставил удалённый доступ через Quick Assist, встроенный инструмент Windows. Одного хватило.

Дальше цепочка разворачивалась без участия пользователя:

1. Через Quick Assist атакующий получил интерактивный доступ к рабочей станции
2. Жертву перенаправили на подконтрольный сайт с поддельной формой входа - там были введены корпоративные учётные данные
3. Загружен MSI-пакет с вредоносной DLL, установивший C2-канал
4. Дальше - стандартные административные инструменты (living-off-the-land) для перемещения внутри сети, зашифрованные загрузчики и прокси для сокрытия активности

Контекст применимости: вектор работает в любой организации, где разрешён External Access в Teams и не заблокирован Quick Assist через GPO/Intune. Тип инфраструктуры - modern или legacy - не принципиален, потому что эксплуатируется человеческий фактор, а не техническая уязвимость.

Ограничение вектора: вишинг не масштабируется. Один оператор обрабатывает одну жертву за раз. В описанной кампании зафиксировано несколько неудачных попыток перед успешной - атакующий просто перебирал сотрудников, пока кто-то не клюнул.

Device Code Phishing: MFA бесполезна by design​

Device code flow - легитимный механизм OAuth 2.0 для устройств без клавиатуры (Smart TV, IoT). Пользователь заходит на microsoft.com/devicelogin, вводит код и проходит полную аутентификацию, включая MFA. Результирующий токен передаётся на устройство, инициировавшее запрос. В случае атаки это инфраструктура злоумышленника. Всё.

По публичным отчётам, современные PhaaS-платформы (Phishing-as-a-Service) автоматизируют device code phishing до состояния конвейера: фишинговые страницы генерируют device code динамически при заходе жертвы, устраняя ограничение по времени действия кода. AI-модули персонализируют приманки под конкретные workflow - строительные тендеры, DocuSign-документы, формы Microsoft. Пользователь проходит аутентификацию на настоящем сайте Microsoft - ничего в процессе не выглядит подозрительным.

Такие платформы распространяются через Telegram по подписке и предлагают автоматическое сканирование почты и календаря жертвы после захвата токена, генерируя follow-on атаки (wire fraud) за минуты вместо часов ручной работы.

Почему MFA bypass здесь работает для Push/SMS/TOTP: пользователь проходит настоящую аутентификацию на настоящем сайте Microsoft. Push, SMS, TOTP, и даже FIDO2 - всё срабатывает штатно. Токен просто уходит не туда. Это обход многофакторной аутентификации by design, а не эксплуатация уязвимости. По документам - MFA защищает. На практике - нет.

Контекст применимости: любой тенант Microsoft 365, где не заблокирован device code flow через Conditional Access. Особенно опасен для организаций с удалёнными сотрудниками, привыкшими к OAuth-авторизациям различных сервисов.

AiTM: adversary-in-the-middle через прокси​

По публичным отчётам, AiTM-атаки регулярно используются в рамках многоступенчатого фишинга с темами вроде «code of conduct review». Подобные кампании, по оценкам исследователей, затрагивают десятки тысяч пользователей в тысячах организаций по всему миру - здравоохранение, финансы, professional services, технологический сектор.

Цепочка атаки:

1. Email с PDF-вложением (тема: «Internal case log issued under conduct policy»)
2. Ссылка «Review Case Materials» в PDF ведёт на домен атакующего (поддельный домен, имитирующий Microsoft-сервисы)
3. Cloudflare CAPTCHA - фильтрация автоматического анализа и песочниц
4. Промежуточная страница: «документ зашифрован, требуется аутентификация»
5. Redirect на легитимную страницу входа Microsoft через AiTM-прокси
6. Перехват сессионного токена после прохождения любой MFA

По данным Obsidian Security, adversary-in-the-middle AiTM атаки значительно выросли за последний год (точные цифры зависят от методологии подсчёта и периода наблюдения). Коммерчески доступны минимум 11 AiTM-фишинг-китов: Tycoon 2FA, EvilProxy, Mamba, Evilginx2 и другие.

Для SOC критично: жертва видит абсолютно нормальный процесс входа. Sign-in logs показывают успешную аутентификацию с корректным MFA. Единственная аномалия - IP-адрес и характеристики устройства, не совпадающие с обычным профилем пользователя. Если вы не смотрите на эту аномалию - вы не видите атаку.

Какая MFA защищает - и от чего нет​

Большинство Blue Team-команд трактуют MFA как единый контроль. На практике разные типы второго фактора закрывают принципиально разные атаки - и тут начинаются неприятные сюрпризы.

Вектор атаки	Push MFA	SMS/TOTP	FIDO2/Passkeys	Conditional Access
Device Code Phishing	Не защищает	Не защищает	Не защищает	Защищает (блокировка device code flow)
AiTM прокси (Evilginx2, EvilProxy)	Не защищает	Не защищает	Защищает (привязка к домену, только при отсутствии fallback на TOTP/Push - требуется Authentication Strength = Phishing-resistant MFA)	Частично (device compliance, геолокация)
MFA Fatigue (T1621)	Уязвим	Не применимо	Защищает	Частично (number matching снижает риск)
Вишинг + Quick Assist	Не применимо	Не применимо	Не применимо	Не применимо - блокировать Quick Assist

FIDO2/passkeys - единственный тип MFA, устойчивый к AiTM и MFA fatigue, потому что криптографически привязан к конкретному домену. Но даже passkeys бессильны против device code phishing: пользователь проходит аутентификацию на легитимном microsoft.com, и FIDO2 подтверждает именно этот домен. Единственная защита от device code вектора - блокировка самого flow через Conditional Access.

Отдельный случай - вишинг: никакая техническая MFA не защищает от сотрудника, который сам отдал удалённый доступ. Тут работает только организационная мера (блокировка Quick Assist) и обучение. Технология бессильна против человека, который хочет помочь «айтишнику».

Detection: что искать в логах​

Требования к окружению​

• SIEM с коннектором к Entra ID Sign-in Logs: Microsoft Sentinel, Splunk с Azure Add-on, Elastic с модулем Azure
• Unified Audit Log включён для Microsoft 365 (по умолчанию включён, но проверьте - бывают сюрпризы)
• Дополнительно: Microsoft 365 Defender для расширенного hunting (Cloud App Events)
• Ретенция логов: минимум 90 дней для ретроспективного анализа

Device code flow - аномальная аутентификация​

В Microsoft Sentinel KQL-запрос для обнаружения device code аутентификации:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Что агрегировать для повышения точности алертов:

• Аутентификация из нового географического региона + обращение к Microsoft Graph API в течение 15 минут - признак token replay после AiTM
• Регистрация нового устройства (Register Device event) с последующей device code аутентификацией - типичный приём закрепления в device code phishing кампаниях
• Множественные MemberAdded или ChatCreated события в Teams с участием #EXT# (внешних) пользователей - разведка через Teams внешний доступ
• Создание New-InboxRule с перенаправлением или удалением писем после успешного входа - типичный пост-эксплуатационный шаг для сокрытия компрометации учётных записей Office 365

Hardening-чеклист: что закрыть сегодня​

Чеклист выстроен по приоритету - от максимального impact с минимальными усилиями:

1. Conditional Access: блокировка device code flow. CA policy → Conditions → Authentication Flows → Device code flow → Block. Исключения - только для конкретных сервисных аккаунтов conference room devices. Закрывает самый опасный и наименее детектируемый вектор. Пять минут работы
2. Teams External Access: ограничить домены. Teams Admin Center → External Access → разрешить только конкретные домены партнёров вместо «Allow all external domains». Проверьте текущее состояние: Get-CsTenantFederationConfiguration | Select-Object AllowedDomains, AllowFederatedUsers, AllowTeamsConsumer. Если AllowFederatedUsers = True и AllowedDomains пуст - любой внешний пользователь Teams пишет вашим сотрудникам. Прямо сейчас
3. Quick Assist: заблокировать. AppLocker или WDAC policy для QuickAssist.exe. Альтернатива - удаление. Для legacy-версии (Windows Capability): Remove-WindowsCapability -Online -Name App.Support.QuickAssist~~~~0.0.1.0. Для современного Store-варианта: Get-AppxPackage MicrosoftCorporationII.QuickAssist | Remove-AppxPackage -AllUsers
4. MFA: миграция на FIDO2/passkeys. Минимум для привилегированных аккаунтов (Global Admin, Security Admin, финансы). Push MFA с number matching - допустимый промежуточный вариант, снижающий риск MFA fatigue
5. Token lifetime: сократить. Conditional Access → Session → Sign-in frequency → 4-8 часов. По умолчанию refresh token живёт до 90 дней inactive - это огромное окно для использования украденного токена. Принудительная reauth через Sign-in frequency сокращает его до приемлемых рамок
6. Continuous Access Evaluation (CAE): включить. Позволяет отзывать токены в near-real-time при смене IP или пометке аккаунта как скомпрометированного. Поддерживается Exchange Online, SharePoint Online, Teams
7. Safe Links для Teams: активировать. Defender for Office 365 → Safe Links policy → включить для Teams. Сканирует Microsoft Teams вредоносные ссылки в момент клика
8. OAuth consent: ограничить. Entra ID → Enterprise Applications → User consent settings → разрешить consent только для проверенных издателей. Admin consent workflow - обязателен для остальных

За последние полтора года атаки на корпоративные мессенджеры прошли путь от ручного вишинга до автоматизированных PhaaS-платформ с AI-персонализацией. Проблема на стороне защиты - фундаментальная: большинство SOC-команд мониторят Teams как «ещё один SaaS-сервис», а не как полноценный вектор initial access. Sign-in logs собирают - но device code flow не фильтруют. External Access не ограничивают, потому что «бизнесу нужно общаться с подрядчиками». Quick Assist не блокируют, потому что helpdesk его «иногда использует».

В итоге атакующий сидит внутри тенанта с валидным токеном, SOC видит «успешный вход пользователя» - и ни одного алерта. Логи есть, данные есть, корреляции строятся за день. Проблема в приоритизации: защитные команды фокусируются на email-фишинге и малвари на эндпоинтах - там, где Defender for Office и EDR дают покрытие. А Teams, через который прямо сейчас работают группы уровня Storm-2372, остаётся в слепой зоне.

CA policy для блокировки device code flow - пять минут настройки. Она остановила бы кампании device code phishing на уровне аутентификации. Через год device code flow, вероятно, будет заблокирован в Entra ID по умолчанию - Microsoft уже движется в этом направлении. Вопрос - сколько инцидентов случится до этого. Если detection по identity-атакам через мессенджеры в вашем SOC пока не настроен - на yg140.servegame.com обсуждают подобные кейсы с конкретными KQL-запросами и Sigma-правилами под разные SIEM-стеки.