Короткий ответ

Подозрение на взлом ivan.petrov@contoso.example: сначала отрежьте сессию, потом пароль, потом MFA-методы, потом почтовые закладки. Порядок: Disable или Risk-block → Revoke-MgUserSignInSession → сброс пароля (и временный запрет смены самим, если атакующий ещё в сессии) → revoke refresh tokens фактически тем же revoke → проверка MFA (удалить чужие телефоны/TOTP) → inbox rules и ForwardingSmtpAddress → OAuth grants → Audit. Параллельно читайте sign-in logs, не спорьте с пользователем «это точно вы из отпуска». Не отключайте MFA. Не сбрасывайте только пароль, оставив refresh token живым на сутки.

Админские роли на этой учётке — сразу в защиту администратора и отдельный инцидент привилегий.

Симптомы и как отличить

  • Исходящие, которых человек не писал; часто на английском, про счёт/крипту.
  • Hidden inbox rule, «strange» forwarding — переадресация.
  • Entra: Failed MFA потом Success legacy; или Success из IP хостинга.
  • Коллеги получают NDR/спам «как от Ивана»; репутация тенанта.
  • OneDrive/SharePoint sharing наружу.

Отличите от легитимного ESP и от делегата с Full Access. Отличите от «Outlook просит пароль» без аномальных логов.

Возможные причины

  1. Фишинг пароля + отсутствующая/обойденная MFA (исключение CA, legacy auth).
  2. Украден refresh token / session cookie (adversary-in-the-middle). Тогда одной смены пароля мало, нужен revoke и, часто, смена MFA.
  3. Consent malicious OAuth («разрешить приложение»).
  4. Пароль из другой дыры, reuse.
  5. Компрометация админа, который сбросил MFA Ивану.
  6. Shared пароль ящика.

Не выдумывайте CVE на Outlook как обязательную причину.

Диагностика

Делайте параллельно сдерживанию, не «сначала неделя логов».

1. Sign-in logs (факт)

Entra → Sign-in logs: UPN, 7–30 дней. Поля: IP, location, device, client app (Browser / Mobile / Exchange Web Services / IMAP), MFA result, Conditional Access, Resource (Microsoft Graph, Office 365 Exchange Online). Методика чтения — расследование входа.

Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
# фильтр по UPN в GUI надёжнее для первого часа; Graph — для выгрузки

2. Почтовые закладки

Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-Mailbox ivan.petrov@contoso.example |
  Format-List ForwardingSmtpAddress, ForwardingAddress, AuditEnabled
Get-InboxRule -Mailbox ivan.petrov@contoso.example
Get-MailboxPermission ivan.petrov@contoso.example |
  Where-Object { $_.IsInherited -eq $false }

3. OAuth / приложения

Entra → User → Applications / Enterprise applications → user consent. Ищите недавно добавленные с Mail.ReadWrite, full_access_as_user.

4. Исходящий спам

Message Trace: всплеск Sent. Defender outbound quarantine.

Решение

Сдерживание (минуты)

  1. Блок входа: Disable-MgUser / блок risk / CA emergency — по вашей IR-процедуре. Если нужен ящик для расследования получать почту — иногда оставляют receive, режут client apps. Не оставляйте IMAP открытым.
  2. Revoke sessions:
Revoke-MgUserSignInSession -UserId ivan.petrov@contoso.example
  1. Сброс пароля в Entra, сброс «password hash sync» если hybrid — пароль на on-prem, не только в облаке.
  2. Authentication methods: удалить phone/FIDO/TOTP, которые пользователь не узнаёт; зарегистрировать заново под контролем Helpdesk.

Чистка почты

Удалить внешний forward и правила. Зафиксировать имена правил в тикете. Проверить Sent и deleted. При массовом спаме — снять ящик с отправки (Set-Mailbox -ProhibitSendQuota не для этого; используйте -AccountDisabled на уровне пользователя или временный -LitigationHold только если нужно сохранить улики, не как наказание).

Практично: Set-Mailbox ivan.petrov@contoso.example -MailTip не лечит. Для стопа исходящих — disable user / revoke / CA block.

OAuth

Отозвать consent, отключить подозрительное Enterprise App, проверить, не Global Admin consent.

Коммуникация

Не писать «мы взломаны» всем внешним контактам без шаблона IR. Внутри — сменить пароли, если Иван был админом общих ящиков: пересмотреть ACL.

В тенанте contoso.onmicrosoft.com проверьте, не стоял ли Иван в ролях Exchange/User admin: тогда смотрите audit на reset чужих MFA и consent. Параллельно карантин исходящих: Defender outbound, чтобы тенант не продолжал слать спам, пока вы читаете логи.

Просмотрите делегатов Get-MailboxPermission и Get-RecipientPermission: атакующий часто добавляет себя Full Access. Снимите неизвестные ACE. Sent Items: не удаляйте оптом до копии в IR-хранилище — иначе потеряете образцы фишинга «как от Ивана».

Если есть Microsoft 365 Defender: User compromise alerts, email forwarding incidents, unusual volume. Не заменяют sign-in log, но ускоряют. После revoke подождите и повторите Get-InboxRule: persistence через оставшийся OAuth — частая причина «мы всё сняли, правило вернулось». Тогда enterprise app + consent, не третий сброс пароля без отзыва приложений.

Как проверить, что проблема устранена

  1. Sign-in: нет Success с плохих IP после revoke; пользователь входит только с известного устройства с MFA.
  2. Inbox rules / forwarding чисты (повтор через час — атакующий мог вернуть, если сессия жива).
  3. Outbound volume нормальный, трейс без спам-пачки.
  4. Consent list без неизвестных apps.
  5. Пользователь на новом MFA-методе, старые удалены.

Если не помогло

  • Сразу снова правило: токен жив (другой клиент, persistent cookie, malicious app). Повторный revoke, блок user, смотреть Audit «New-InboxRule».
  • Hybrid: on-prem пароль не сменился — атакующий входит через PTA/PHS старым хешем.
  • Админская роль: считать тенант под угрозой, не один ящик.
  • Репутация EO: открыть кейс в Microsoft 365 admin после чистки, не до.

Профилактика

  • MFA без дыр, запрет legacy, PIM для админов.
  • Алерт: новое inbox rule + forward + impossible travel.
  • User consent ограничен (admin consent workflow).
  • Запрет автофорварда по умолчанию.

FAQ

Достаточно ли «смените пароль в Outlook»?

Нет. Без revoke сессия OAuth живёт. Без чистки правил утечка продолжится.

Блокировать пользователя или нет?

Если атака активна — да, на часы. Согласуйте с бизнесом, но безопасность сессии важнее «чтобы Иван читал почту с телефона злоумышленника».

Нужно ли пересоздавать ящик?

Обычно нет. Правила и delegates чистятся. Пересоздание теряет историю и ломает SMTP.

Стоит ли снести все устройства в Entra?

Неизвестные — да. Корпоративные hybrid Azure AD joined — проверьте Compliance, не обязательно wipe всех.

Это точно взлом, если IP «Москва» а человек в Москве?

Смотрите User agent, ночь, правило, невозможную скорость перемещения. IP города недостаточно для вердикта и недостаточно для оправдания.