Учётка администратора в чужих руках: сначала билеты и сессии, потом новый секрет

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

Компрометация администратора — не «ещё один логон». Отзовите живые сессии (RDP, WinRM, SSH, VPN, консоли), сбросьте Kerberos-билеты на hop-ах, смените пароль и SSH-ключи, проверьте группы (Domain Admins, sudo, локальные Administrators). Если украдена учётка из Domain Admins / эквивалент и есть признаки подделки билетов — планируйте ротацию krbtgt по документированной процедуре Microsoft (два сброса с репликацией), не «пароль DA в чат и забыли».

Порядок: стоп сессий → Disable или сброс секрета → аудит групп и новых учёток → полный список секретов. Вход как факт — подозрительный вход. Lateral — отдельная тема.

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

• 4624 Type 10/3 + 4672 на DC/jump с 10.0.10.55.
• 4728/4732: ivan.petrov добавлен в привилегированную группу, или он сам кого-то добавил.
• На host.example: sudo / новый ключ в /root/.ssh/authorized_keys.
• GPO/скрипты менялись вне окна change.

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

1. Daily-drive совпадал с privileged (почта и браузер под DA).
2. Фишинг / кража пароля jump без MFA.
3. Кража TGT/хеша с заражённого WS-042.
4. Утечка ключа SSH id_rsa без пароля.
5. Break-glass использовали в ежедневной работе.
6. Редко: компрометация самого DC — тогда это уже восстановление леса, не один Disable.

Диагностика

С чистого бастиона.

1. Кто и откуда

$u = 'ivan.petrov'
Get-ADUser $u -Properties MemberOf, Enabled, PasswordLastSet, LastLogonDate, SID
Get-ADPrincipalGroupMembership $u | Select-Object Name
Get-WinEvent -ComputerName 'DC01' -FilterHashtable @{ LogName='Security'; Id=4672,4624,4728,4732,4720; StartTime=(Get-Date).AddDays(-7) } |
  Where-Object { $_.Message -match $u }

2. Сессии

query user /server:DC01
Get-Process -ComputerName 'DC01' -ErrorAction SilentlyContinue | Where-Object { $_.ProcessName -match 'wsmprovhost|winlogon' }

WinRM/SSH с 10.0.10.55: журналы WinRM, journalctl -u ssh. Не сканируйте лес «как атакующий» — читайте логи.

3. Ключи Linux

sudo grep -R . /home/ivan.petrov/.ssh/authorized_keys /root/.ssh/authorized_keys
sudo last -F root ivan.petrov
sudo grep ivan.petrov /var/log/auth.log | tail

4. Признаки Golden Ticket уровня «надо krbtgt»

Не эвристика с форума. Практические триггеры, которые обсуждают с владельцем AD: долгоживущие TGT привилегированных учёток после смены пароля, невозможность объяснить 4624 DA с хостов вне jump, компрометация DC. Решение о двойном сбросе krbtgt — отдельное, с backup NTDS и окном. Не делайте его «на всякий» для локального админа одного ПК.

Решение

Сценарий A. Локальный / sudo на одном host.example

1. Завершить сессии loginctl terminate-user, TTY.
2. passwd / новые ключи, старые authorized_keys вычистить.
3. Проверить sudoers, новые UID, cron root.
4. Хост не считать чистым, пока не пройден процесс.

Сценарий B. Domain Admin / эквивалент

1. Disable ivan.petrov и его -adm, если разделены.
2. Сбросить пароль из другой учётки.
3. Снять с групп, которые не положены.
4. Ревизия недавно созданных пользователей и SPN.
5. Ротация секретов сервисов, которые этот админ мог знать (см. статью про учётные данные).
6. krbtgt — только по решению AD-владельца и runbook Microsoft, два раза с ожиданием репликации; не третьим пунктом «на автомате».

Disable-ADAccount -Identity 'ivan.petrov'
Set-ADAccountPassword -Identity 'ivan.petrov' -Reset -PassThru
# пароль передайте по регламенту, не в теле тикета открытым текстом навсегда

Сценарий C. Облачный админ параллельно

Revoke сессий Entra, PIM, break-glass проверить не его ли это был. Почта админа — ящик.

Запишите в тикет, с какого прыжка вы меняли секрет: не с WS-042.

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

• Учётка Disabled или включена с новым секретом, PasswordLastSet свежий.
• Нет 4672 с чужих IP после отсечки.
• Группы соответствуют матрице доступа.
• authorized_keys без неизвестных строк.
• Список hop-ов, где могли кешировать билет, прогнан (logoff/reboot hop по регламенту).
• Если делали krbtgt — репликация OK, тест логона рядовых пользователей, документация окна.

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

• Снова 4728 от той же учётки — секрет не сменили везде (hybrid, второй лес, Azure AD Connect).
• Вход идёт NTLM с старым хешем — пароль сменили, но не везде реплицировали DC; проверьте repadmin /replsummary, не «ещё раз Disable».
• Root на Linux с консоли гипервизора без SSH-лога — физический/OOB доступ, меняйте пароли BMC отдельно.
• Подозрение на DC implant — не «ещё раз сменить пароль», а IR + backup NTDS, вне этой статьи.

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

• Tiering: DA не на WS-042, только jump.
• MFA, PAM/PIM, короткие TTL.
• Отдельные SSH-ключи на бастион, passphrase, не копировать ключ DA на почту.
• Алерт 4728/4732 на Domain Admins, 4672 с не-jump.
• Регулярная смена break-glass по конверту.

FAQ

Сразу ли reset krbtgt при любом взломанном админе?

Нет. Сначала сессии и пароль этой учётки. krbtgt — когда есть основания считать, что могли выписать произвольные TGT. Это disruptive.

Нужно ли перезагружать все серверы?

Не как первый шаг. Logoff сессий и смена секрета важнее. Reboot hop-ов — по списку, где точно сидели билеты.

Можно ли оставить админа Enabled «чтобы чинил»?

Нет. Выдайте временную новую privileged-учётку после проверки личности, старую считайте грязной.

SSH-ключ украли, пароль нет

Ключ = секрет. Удалите строку из authorized_keys, выпустите новый ключ, проверьте agent forwarding на заражённом ПК.

Локальный Administrator RID-500 на каждой станции

Если его пароль был единый LAPS-нарушение — ротируйте LAPS/пароли локальных админов, это уже массовая ветка учёток.