Украденная сессия: почему смена пароля не завершает identity incident

Проблема

Современный identity incident часто проходит без повторного ввода пароля. Злоумышленник работает через уже выданный token, создает inbox rule, добавляет OAuth grant или изменяет MFA/recovery state. Простая смена пароля может не отозвать все эти артефакты.

Исследование Microsoft по Storm-2755 показывает цепочку от ложной страницы входа и token theft до злоупотребления легитимными payroll-процессами. Главный вывод для защитника: расследовать нужно не login event, а весь authenticated workflow после него.

Решение: единый containment set

Containment должен атомарно или в строго контролируемой последовательности отозвать активные sessions и refresh tokens, заблокировать identity, удалить подозрительные inbox rules и delegates, отозвать OAuth grants, проверить MFA methods и связать действия с device compliance.

После восстановления нужен negative retest: старый token не работает, удаленное правило не появляется снова, старый device не проходит policy, а новые sign-ins соответствуют ожидаемому client, network и device profile.

Что собрать до изменений

• Sign-in, non-interactive sign-in и token-risk события с точным временем.
• Mailbox audit: rules, forwarding, delegates, send-as и recent message access.
• OAuth grants, enterprise applications и consent changes.
• MFA methods, recovery contacts, device registrations и Conditional Access decisions.
• Business actions после подозрительного login: payroll, invoice, profile, payment и admin changes.

Безопасный пример: корреляция identity timeline

Пример показывает defensive query-паттерн. Имена таблиц нужно адаптировать к вашей SIEM-схеме.

let window = 30m;
let risky = SignInEvents
  | where RiskLevel in ("medium", "high")
  | project UserId, SignInTime=Timestamp, SessionId, IPAddress, DeviceId;
let changes = IdentityAudit
  | where Operation in ("Add inbox rule", "Grant OAuth consent", "Register MFA method")
  | project UserId, ChangeTime=Timestamp, Operation, Target;
risky
  | join kind=inner changes on UserId
  | where ChangeTime between (SignInTime .. SignInTime + window)
  | project UserId, SignInTime, ChangeTime, Operation, SessionId, IPAddress, DeviceId

Типичные ошибки

• Менять пароль до preservation ключевых audit events и терять исходную timeline.
• Отзывать только access token, оставляя refresh token или OAuth grant.
• Не проверять inbox rules и delegates после Business Email Compromise.
• Возвращать identity в работу без negative retest старых session artifacts.

Evidence и критерий ретеста

• До и после containment сохранены hashes выгрузок sign-in, mailbox, OAuth и MFA state.
• Каждый revoked artifact имеет идентификатор и проверку, что он больше не действует.
• Business owner подтвердил отсутствие или исправление unauthorized workflow changes.