Чужие письма от Ивана: снимите правила и сессии до смены пароля в Outlook

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

Взломанный ящик ivan.petrov лечится не сменой пароля в уже открытом Outlook. Сначала оборвите сессии (OWA/MAPI/IMAP/ActiveSync/Graph), затем снимите пересылку и inbox rules, затем смените пароль и перерегистрируйте MFA. Новый секрет не отправляйте в этот же ящик. Сохраните список правил и Message Trace до массового удаления писем.

On-prem Exchange и Microsoft 365 отличаются консолью, логика одна. Подозрительный логон к ящику — вход. Вложение как входная точка — фишинг.

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

• Исходящие, которых человек не писал (счёт, крипта, «срочно CEO»).
• Письма Ивана не доходят внутренним: правило кладёт их в RSS/Deleted.
• Внешний forward на неизвестный SMTP.
• Клиенты жалуются на спам с вашего домена.
• На WS-042 Outlook открыт, параллельно OWA с 10.0.10.55.

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

1. Фишинг пароля + слабая/обойденная MFA.
2. Украден cookie/session (в том числе через вредонос на WS-042).
3. IMAP/POP без MFA (legacy).
4. Делегат Full Access, которого добавили тихо.
5. Скомпрометированный админ сменил MFA Ивану.
6. Пароль из VPN/другого сервиса, reuse — VPN.

Диагностика

1. On-prem Exchange (PowerShell с admin-станции)

Get-Mailbox 'ivan.petrov' | Format-List AuditEnabled, ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward
Get-InboxRule -Mailbox 'ivan.petrov' | Format-List Name, Enabled, Description, RedirectTo, ForwardTo, DeleteMessage, Hidden
Get-MailboxPermission 'ivan.petrov' | Where-Object { -not $_.IsInherited }
Get-MobileDeviceStatistics -Mailbox 'ivan.petrov' | Format-Table DeviceType, DeviceUserAgent, LastSuccessSync

IIS/HTTPProxy логи CAS: ищите URI OWA/EWS с 10.0.10.55. Не выкладывайте полный лог в открытый тикет с паролями Basic, если вдруг попали.

2. Microsoft 365 (если ящик там)

Sign-in logs, Get-InboxRule, ForwardingSmtpAddress, OAuth grants — та же последовательность: сессия → правила → MFA. Не дублируйте тут весь облачный runbook; важно не забыть два каталога, если hybrid.

3. Клиент на WS-042

Outlook-профиль мог закешировать. После revoke на сервере закройте Outlook, не оставляйте «работать офлайн» с исходящей очередью спама.

Get-Process Outlook -ErrorAction SilentlyContinue
# не Kill до экспорта правил, если админ смотрит GUI; после копии — закрыть

4. Linux-почта (Postfix на host.example как релея)

Если спам идёт сервером, а не ящиком Ивана — это уже WordPress/спам или скомпрометированный SASL. Проверьте mailq, sasl логи, не только mailbox.

sudo mailq | head
sudo journalctl -u postfix --since '24 hours ago' | grep -i ivan.petrov | tail

Решение

Сдерживание

1. Временно запретить вход: Disable AD / блок карантина почты / снять IMAP.
2. Отозвать сессии: IIS reset не как первый шаг на весь CAS; точечно — блокировка учётки + Clear-ActiveSyncDevice по чужим устройствам после списка.
3. Удалить внешний forward и скрытые правила, сохранив имена в тикете.

Get-InboxRule -Mailbox 'ivan.petrov' | Format-List | Out-File C:\IR\mailbox-ivan.petrov-rules.txt
# Remove-InboxRule — только после файла и фото GUI
Set-Mailbox 'ivan.petrov' -ForwardingSmtpAddress $null -ForwardingAddress $null -DeliverToMailboxAndForward $false

Секрет и MFA

Смена пароля AD/облака. Методы MFA: удалить неизвестный телефон/приложение, зарегистрировать заново при встрече/видео с паспортом по регламенту helpdesk. Пароль — ротация.

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

Внутренним: не открывать письма «от Ивана» за окно инцидента. Внешним — шаблон IR, не исповедь в Reply All.

Исходящая очередь и репутация

Пока ящик чистите, исходящий спам может уже сидеть в очереди транспорта или на смартфоне ActiveSync. На on-prem посмотрите очередь сервера транспорта (штатная консоль/Get-Queue), на Online — Message Trace за окно инцидента. Не разгребайте очередь удалением «всех писем Ивана за месяц» без копии: потеряете образцы. Если домен попал в блоклист, delist делайте после стопа сессий, иначе листинг вернётся за ночь. Учётка ivan.petrov на WS-042 с закешированным Outlook: закройте клиент, иначе он дошлёт черновики, которые атакующий положил в Outbox.

Сверьте, не использовался ли тот же пароль на VPN: параллельный туннель с 10.0.10.55 превращает почтовый инцидент в сетевой. Тогда VPN в том же тикете, не «завтра».

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

• Get-InboxRule пуст от неизвестного, forwarding null.
• Нет новых Success OWA/IMAP с 10.0.10.55.
• MFA-методы узнаёт пользователь.
• Message Trace / очередь без спам-пачки.
• Делегаты совпадают с матрицей.
• Outlook открыт заново, очередь исходящих пуста.

Повтор через 1–2 часа: правило могли вернуть живым токеном — тогда снова revoke и охота за приложением/устройством.

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

• Правило возвращается — жив токен или malicious OAuth / админский скрипт.
• Hybrid: пароль сменили только в облаке или только on-prem.
• Транспортное правило организации шлёт копии — это не inbox, ищите в mail flow.
• Репутация домена: после чистки ящика всё равно spamhaus — отдельный трек DNS/PTR, не третий сброс пароля Ивана.
• Спам идёт с host.example, не из ящика — смотрите веб и релея.

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

• MFA, запрет legacy IMAP/POP.
• Запрет автофорварда наружу по умолчанию.
• Алерт на новое inbox rule и ForwardingSmtpAddress.
• Админские ящики не для повседневной переписки.
• Обучение: пароль не вводить на страницах из письма.

FAQ

Удалить все письма за сегодня?

Сначала копия/удержание. Массовый delete убивает образцы фишинга «как от Ивана».

Пересоздать ящик?

Обычно нет: потеряете историю и SMTP-ссылки. Чистятся правила, делегаты, сессии.

Нужно ли менять пароль всех, кто получил спам?

Нет, как автоматическое правило. Нужна осторожность с вложениями. Пароли — у кого есть признаки перехода по фишингу.

ActiveSync телефон «незнакомый»

Снимите партнёрство устройства после записи DeviceId в IR. Свой телефон Иван подтверждает по IMEI/модели.

Это Exchange 2019 или Online?

Командлеты Get-InboxRule/Set-Mailbox живут в обоих мирах с нюансами подключения. Не подключайтесь к прод-Exchange скомпрометированной учётки Ивана.