Короткий ответ
После компрометации ротируйте все секреты, которые эта идентичность могла знать или которые кешировались: пароль AD/Linux, SSH-ключи, API-токены, VPN, пароли сервисов в браузере, Kerberos (смена пароля + logoff), при компрометации уровня DC/DA с признаками подделки билетов — krbtgt дважды по документации Microsoft с ожиданием репликации. Новый секрет не отправляйте в тот же ящик/тот же туннель. Не reuse старого пароля с «!».
Узкие случаи: админ, VPN, почта, ноут.
Симптомы и как отличить
Ротация нужна, когда:
- вход чужой подтверждён;
- фишинг пароля;
- malware на ПК админа;
- утечка файла с паролями.
Не путать с плановой сменой по политике 90 дней — там нет IR-охвата ключей и токенов.
| Секрет | Инвалидируется сменой пароля AD? |
|---|---|
| Kerberos TGT этой учётки | постепенно, нужен logoff |
| Refresh token Entra | нет, нужен revoke |
| SSH key | нет |
| PSK VPN сайта | нет |
| Пароль SQL в конфиге | нет |
| krbtgt | отдельная процедура |
Возможные причины
- Сменили только AD, забыли облако.
- Ключ в
authorized_keysна 15 серверах. - Saved Credentials в Windows Vault.
- Token CI в
~/.git-credentialsнаWS-042. - LAPS единый, который видел DA.
- krbtgt не трогали, когда надо было — или трогали, когда не надо.
Диагностика
Get-ADUser 'ivan.petrov' -Properties PasswordLastSet, PasswordNeverExpires, MemberOf, Enabled
Get-ADComputer 'WS-042' -Properties PasswordLastSetsudo grep -R 'ivan.petrov\|ssh-rsa\|ssh-ed25519' /home/*/ .ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null
sudo passwd -S ivan.petrovПочта: методы MFA, приложения OAuth. VPN: группа и сертификат. Документация vault: какие записи открывал.
Не «сканируйте» пароли в файлах всей шары поиском password= как атака — точечно по домашнему каталогу и известным конфигам с IR-носителя.
Решение
1. Сдерживание учётки
Disable или снять все дистанционные группы. Logoff сессий. Потом секрет.
Disable-ADAccount -Identity 'ivan.petrov'
Set-ADAccountPassword -Identity 'ivan.petrov' -Reset
# Enable позже, когда новый секрет передан вторым каналомsudo passwd ivan.petrov
sudo passwd -l ivan.petrov # если ещё рано пускать2. SSH-ключи
Новая пара на чистом ПК. Старые строки удалить везде. authorized_keys не дополнять, а заменить известным списком.
3. Токены
- Entra: revoke sessions.
- API keys в панели облака: reissue.
- Windows:
cmdkey /listна чистом, не на грязном как истина; creds на грязном считайте украденными. - Git/npm/docker tokens.
4. Служебные пароли, которые он мог знать
Панели, SNMP community, локальный Administrator, задокументированные в wiki. Меняйте по приоритету: AD, VPN, почта, инфраструктура, приложения.
5. krbtgt — только при необходимости
Триггеры обсуждения с владельцем AD: компрометация DA/EA и возможность, что выписывались произвольные TGT (долгоживущие билеты после смены пароля DA, доступ к DC). Процедура Microsoft: сброс пароля krbtgt два раза, между сбросами — репликация всех DC (repadmin /replsummary), окно с возможным разрывом логонов. Backup NTDS до окна. Не скрипт с форума. Не третий сброс «для верности» сразу.
# проверка репликации — до и после окна krbtgt
repadmin /replsummary
Get-ADUser krbtgt -Properties PasswordLastSetСама смена — штатный Reset пароля учётки krbtgt в контролируемом окне, не в этой статье пошаговый «эксплойт билетов».
6. Computer account / LAPS
Если WS-042 скомпрометирован: переустановка или смена пароля машины (reboot в домен), LAPS заново. Не возвращайте тот же локальный пароль.
Сервисы, SPN и второй каталог
Смена пароля ivan.petrov ломает scheduled tasks и службы, где он зашит: инвентарь до Enable. На host.example обновите systemd EnvironmentFile и cron, не оставляйте старый пароль в unit. Hybrid: сброс on-prem без Entra (и наоборот) оставляет живой секрет. Computer WS-042$ после компрометации ПК: LAPS/пароль машины заново, не только user. Источник 10.0.10.55 после Reset — см. выше.
Токены: cloud API, Grafana, Git, панели хостинга — то, что открывал браузер на грязном ПК. Не верьте «я пароли не сохранял». 10.0.10.55 как источник успешных логонов после Reset — значит секрет не тот (ключ, сертификат, вторая учётка). krbtgt не заменяет Disable DA и logoff hop-ов; это отдельное окно с backup NTDS. Документируйте, какие секреты сознательно не трогали и почему.
Передача нового пароля: HR-телефон, лично, не тот же Outlook и не SMS на номер, который только что добавили в MFA атакующие.
Как проверить, что проблема устранена
PasswordLastSetсвежий.- Disable/Enable согласованы с бизнесом.
- Нет Accept SSH старым ключом (
last, journal). - Revoke: нет Success облака со старого refresh.
- VPN со старым паролем не пускает.
- Если krbtgt: оба PasswordLastSet, логон тестового пользователя, репликация без ошибок.
- Список «что сменили / что сознательно нет» в тикете.
Если не помогло
- Вход жив: второй фактор/ключ/дубль учётки (
ivan.petrovvsivan.petrov@contoso.example). - Hybrid: хэш не синхронизировался.
- Задание в Планировщике с сохранённым паролем — 4648, обновите задание.
- krbtgt сделали один раз — дочитайте процедуру, спланируйте второй.
- Сервис сломался после смены svc-пароля — это ожидаемо, обновляйте SPN/службы по списку, не откатывайте на украденный.
Профилактика
- Vault, не Excel.
- MFA, запрет reuse.
- Privileged ≠ daily.
- Короткоживущие токены.
- Инвентарь ключей SSH.
- Учения смены svc без простоя.
FAQ
Менять ли пароли всем сотрудникам?
Нет автоматически. Да — если украден DA и мог дампить NTDS/много хешей: тогда массовая смена по решению IR, это уже кризис идентичности.
Можно ли оставить старый пароль, добавив MFA?
Нет, если пароль известен атакующему. MFA обходят сессиями и усталостью. Пароль всё равно новый.
Ключ с passphrase — достаточно passphrase?
Если ключ украден с диска без агента — passphrase помогает. Если агент на WS-042 держал ключ в памяти — считайте скомпрометированным, ротируйте.
krbtgt в маленькой конторе «на всякий» после ransomware ПК
Сначала DA/сессии. krbtgt — если privileged identity под вопросом. Не как шаг 2 после одного WS-042 бухгалтера.
Куда отдать новый пароль Ивану?
Телефон из HR, лично, второй мессенджер, не тот Outlook. Временный пароль с принудительной сменой.