Разборы реальных инцидентов

Пользователи филиала жалуются, что новый пароль «не работает» — но только в филиале. В центре всё нормально.

1. 1repadmin /replsummary — один DC филиала с ошибками уже 14 дней.
2. 2В журнале Directory Service событие 1988 — Lingering Object.
3. 3Выяснилось: этот DC был выключен два месяца во время ремонта, и никто не заметил.
4. 4Проверили мониторинг — алерта на репликацию не было вовсе.

DC, отключённый дольше Tombstone Lifetime, хранил уже удалённые объекты, и AD заблокировал с ним репликацию.

Вывели DC, почистили метаданные (ntdsutil metadata cleanup) и подняли заново с нуля. Смена паролей заработала через час.

Мониторить репликацию не менее важно, чем «сервер жив». DC может отвечать на ping и быть мёртвым для AD.

Один руководитель заблокирован каждое утро в 08:10. Разблокировка помогает на пару часов.

1. 1На PDC Emulator нашли 4740 — Caller Computer Name указал на терминальный сервер.
2. 2На сервере: события 4625 с Logon Type 3 каждые несколько минут.
3. 3Проверили сессии: висела отключённая RDP-сессия трёхнедельной давности под этим пользователем.

Старая сессия держала предыдущий пароль и повторно отправляла его после смены пароля пользователем.

Закрыли сессию и добавили политику завершения отключённых сессий через 8 часов. Блокировки прекратились.

Повторная блокировка — всегда симптом. Не разблокируйте по кругу, ищите Caller Computer Name.

После замены роутера в филиале интернет есть, но вход в домен странный, а GPO старые.

1. 1ipconfig /all на клиенте: DNS = 192.168.1.1 (роутер).
2. 2nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.local — ответа нет.
3. 3В журнале System событие 1058 — не читается SYSVOL.

Новый роутер раздавал свой DHCP со своим DNS, и клиенты перестали находить DC.

Отключили DHCP на роутере, вернули scope на Windows-сервер с DNS = DC, затем ipconfig /renew.

В домене DNS клиентов всегда указывает на DC. «Интернет есть» не значит, что домен работает.

SOC получил алерт: обычный пользователь запросил 40 сервисных билетов за 3 минуты, все на RC4.

1. 1События 4769 с Encryption Type 0x17 от одной учётки — классическая подпись Kerberoasting.
2. 2Проверили учётки с SPN: нашли svc_backup с PasswordLastSet 2017 года.
3. 3Событие 4672 показало: через час svc_backup вошёл на файловый сервер с высокими правами.

Короткий старый пароль на сервисной учётке с SPN — атакующий сломал его офлайн за минуты.

Сменили пароль на 30 символов, затем перевели сервис на gMSA и поэтапно отключили RC4 в домене.

Каждая сервисная учётка с SPN — пароль, атакуемый офлайн. gMSA закрывает это навсегда.

После «починки» в виртуализации часть пользователей не входит, а несколько серверов потеряли доверие домену.

1. 1События 5722/5723 в журнале DC — пароли учёток компьютеров не совпадают.
2. 2repadmin показал USN rollback на одном из DC.
3. 3У команды виртуализации выяснили: откатили снапшот двухнедельной давности.

Откат снапшота возвращает базу AD назад и вызывает USN Rollback: новые изменения больше не реплицируются.

Вывели повреждённый DC, почистили метаданные и подняли заново. Клиентов починили Test-ComputerSecureChannel -Repair.

DC не восстанавливают из снапшота. Используйте Windows Server Backup / VM-Generation ID или поднимайте новый DC.

В SIEM внезапная тишина от одного сервера, а наутро в его журнале одно событие: 1102.

1. 1Забрали логи со сборщика — там история сохранилась.
2. 2За полчаса до: 4624 Type 3 с незнакомой машины, затем 7045 — новая служба со случайным именем.
3. 3Далее 4728 — добавление в Domain Admins.

Атакующий вошёл через машину со слабым паролем, дошёл до сервера, получил админа и очистил журнал.

Изоляция, двойной сброс krbtgt, смена привилегированных паролей и обязательная пересылка логов в реальном времени.

Лог, лежащий только на машине, — не доказательство. Пересылка логов наружу — самая дешёвая защита.