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

Подозрительный вход расследуют по журналу, не по ощущению VPN. В Entra Sign-in logs для ivan.petrov@contoso.example постройте таймлайн: время UTC, IP, geo (как оценку, не истину), Client app, Resource, MFA result, Conditional Access, Correlation ID. Затем почта: inbox rules, forwarding, Sent. Затем сессии: revoke, если вердикт «не он» или «неясно, но риск высокий». Не спорьте про город IP (CGNAT, VPN, mobile gateway). Не публикуйте CVE. Не ограничивайтесь «пароль сменили в чате».

Если роль админская — повысьте приоритет, см. защиту администратора.

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

Вход может быть:

  • легитимный с нового кафе/VPN;
  • фишинг пароля + MFA fatigue / AiTM;
  • legacy без MFA;
  • token replay после кражи cookie.

От не может войти отличайте: там Failure, здесь часто Success, который не нравится.

Поле логаЗачем
StatusSuccess/Failure
IP / ASNхостинг vs ISP
Client appBrowser vs IMAP vs Mobile
MFAsatisfied / not required
CAкакая политика
Device IDизвестный ПК или пусто

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

  1. Пользователь в поездке / split DNS VPN меняет IP каждые 5 минут.
  2. Exchange Online с общих IP Microsoft — не путать с входом пользователя.
  3. Компрометация: Success legacy, потом New-InboxRule.
  4. Identity Protection impossible travel из-за VPN-выхода в другой стране за минуты.
  5. Ошибочный UPN в алерте (похожие имена).

Диагностика

Портал: entra.microsoft.com → Monitoring → Sign-in logs (User sign-ins interactive и non-interactive отдельно). Non-interactive — refresh tokens, часто там продолжение кражи.

1. Отбор

Фильтр User: Иван. Время: с 24–48 ч до алерта по сейчас. Включите Failed и Success.

2. Чтение одной записи

Откройте Success, который «чужой»:

  • Authentication details: сколько факторов, какой method;
  • Device: managed?
  • Resource: Office 365 Exchange Online / Microsoft Graph / Azure Portal — портал важнее почты для админов;
  • User agent.

IP: lookup ASN. DigitalOcean/хостинг на «входе Ивана из 1С» подозрителен. Крупный мобильный NAT — слабый сигнал один.

3. MFA

Если MFA not required на Browser — дыра политики (MFA). Если MFA satisfied и пользователь клянётся — возможны fatigue (Approve случайно) или session hijack: всё равно inbox rules.

4. Почта сразу после входа

Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-InboxRule -Mailbox ivan.petrov@contoso.example
Get-Mailbox ivan.petrov@contoso.example |
  Format-List ForwardingSmtpAddress, ForwardingAddress
Get-MessageTrace -SenderAddress ivan.petrov@contoso.example `
  -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) |
  Select-Object Received, RecipientAddress, Subject, Status

Ищите внешние получатели и скрытые правила. Связка со статьёй переадресации.

5. Audit (если включён)

Unified Audit Log: New-InboxRule, Set-Mailbox, Add-MailboxPermission, Consent. Без audit вы слепы к закладкам — включите заранее, не в момент пожара.

6. Graph (выгрузка)

Connect-MgGraph -Scopes 'AuditLog.Read.All'
# GUI быстрее для одного человека; Graph — массово

Не требуйте от Helpdesk писать Filter с нуля в 3 ночи, если портал даёт ту же запись.

Решение

Вердиктная развилка:

A. Похоже на него (устройство известное, MFA, ASN ISP дома)

Зафиксировать, объяснить алерт. Не revoke всем подряд без нужды (оторвёте сессии почты).

B. Неясно / высокий риск

Работать как при взломе: сдержать, revoke, пароль, MFA methods, rules. Лучше лишний revoke, чем скрытый forward на неделю.

C. Явный legacy Success с паролем

Считать учётку голой. Закрыть basic, сбросить секрет, искать IMAP-клиент.

В тенанте contoso.onmicrosoft.com откройте оба журнала: Interactive и Non-interactive. После фишинга интерактивный MFA Success в 19:02, затем ночью non-interactive Graph с IP хостинга — token replay. Revoke обязателен даже если Иван «аппрувнул сам».

Связка с почтой обязательна: вход без inbox rule не равен чистому инциденту, но правило без аномального входа бывает от делегата. Смотрите Get-MailboxPermission на новые ACE в том же окне.

Таблица в тикете (пример строки): 2026-09-08 16:41 UTC | 203.0.113.88 | ASN hosting | Browser | MFA satisfied | Resource: Azure Portal. Если Resource — Azure Portal, а Иван не админ, это уже не «почта», а разведка каталога. Эскалируйте как взлом с упором на роли.

Не доверяйте «Sign-in risk: low» как разрешению закрыть тикет: risk — модель, не доказательство. Rules + forwarding + unknown ASN важнее зелёного risk.

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

  1. Таймлайн в тикете: таблица время–IP–app–MFA–действие.
  2. После containment: нет Success с плохих IP, rules чисты (повтор через час).
  3. Пользователь вошёл сам с MFA с известного устройства.
  4. Если был admin — PIM/ролей audit.

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

  • Non-interactive продолжаются: refresh token / persistent app. Повтор revoke, смотреть Enterprise apps.
  • IP «тот же город»: этого мало для закрытия тикета, если есть правило Redirect.
  • Нет логов старше срока хранения: повысьте retention лицензией/настройкой заранее.
  • Hybrid PTA: смотрите ещё DC security log, не только Entra.

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

  • Алерт: inbox rule + unfamiliar / unnamed location.
  • Запрет legacy, MFA baseline.
  • Audit On.
  • Учить пользователя не аппрувить MFA вслепую.
  • Для админов — отдельный канал расследования с более длинным retention.

FAQ

Geo в логе врёт?

Часто. Гео — справочник IP, CGNAT рисует чужой город. Смотрите ASN + поведение + почта.

Correlation ID кому отдавать?

В тикет Microsoft / внутренний IR, не в общий чат. Связывает события.

Non-interactive можно игнорировать?

Нет. Там живут токены Outlook/мобильных. Успешные ночные Graph с IP хостинга — плохой знак.

Нужен ли Defender for Identity?

Полезно в AD, но этот чеклист — облачный вход. Не подменяйте одно другим.

Пользователь подтвердил: «это я, VPN»

Сверьте Client app и MFA. VPN не объясняет скрытое правило, созданное в ту же минуту. Правило всё равно снимите, пока не доказан легитим.

Сколько хранить логи?

Штатно интерактивные логи Entra имеют ограниченное окно; расширяйте Audit/SIEM. Не начинайте расследование через 4 месяца без SIEM.