В корпоративной безопасности до сих пор живёт опасный рефлекс: нашли компрометацию — всем срочно меняем пароли. В Active Directory это часто не решает проблему. Злоумышленник может работать не с паролем, а с хэшем, Kerberos-ticket, токеном, правами репликации или служебным ключом KRBTGT. Такой доступ не исчезает от кнопки «Reset password».
Active Directory остается сердцем Windows-инфраструктуры. Через нее проходят входы пользователей, доступ к серверам, групповые политики, сервисные учетные записи, администраторские права и Kerberos-аутентификация. Потеря контроля над AD часто означает, что домен больше нельзя считать доверенным.
CISA и партнёры в руководстве по защите Active Directory подчеркивают: атакующие используют слабые места конфигурации AD для повышения привилегий, перемещения по сети и полного захвата домена. В документе также разбираются Kerberoasting, злоупотребление старыми алгоритмами шифрования, избыточные права сервисных аккаунтов и трудность детектирования атак, которые выглядят как штатная работа домена.
Пароль — уже не главный секрет
Обычный пользователь думает так: пароль украли — пароль поменяли — доступ закрыли. Но в домене Windows схема сложнее.
После входа пользователь получает набор временных материалов: Kerberos-билеты, сессионные ключи, токены, кэшированные данные. Администратор или сервисная учётная запись оставляют следы на серверах, рабочих станциях, файловых хранилищах и системах управления. Если злоумышленник успел забрать эти материалы, новый пароль не всегда способен закрыть ему путь.
Вот несколько сценариев:
Pass-the-Hash. Атакующему не нужен открытый пароль. Ему достаточно NTLM-хэша. MITRE описывает эту технику как использование украденного хэша для аутентификации без знания пароля. Внутри сети это превращается в тихое и незаметное перемещение между машинами, особенно если локальные админские пароли повторяются или привилегированные учётки заходят на рабочие станции.
Pass-the-Ticket. Здесь воруют не пароль и не хэш, а Kerberos-Ticket. Система считает, что тикет — нормальное подтверждение личности. Пользователь уже мог сменить пароль, но старый билет ещё действителен — до истечения срока действия.
Неисправленные уязвимости. Это уже известные ошибки в ПО, для которых есть исправления, но они не были установлены. Active Directory Domain Services зависит от безопасности Windows Server и связанных компонентов: если в системе остаются незакрытые уязвимости, атакующий может использовать их для первичного доступа, повышения привилегий или движения внутри домена.
Golden Ticket. Если атакующий получил ключ KRBTGT, он может выпускать поддельные Kerberos-билеты и выдавать себя за нужного пользователя. Microsoft описывает Golden Ticket как атаку с использованием украденного ключа KRBTGT, которая даёт скрытый и устойчивый доступ к домену.
KRBTGT: маленькая служебная учётка, большой пожар
KRBTGT — служебная учётная запись Kerberos в каждом домене Active Directory. Её ключ используется для подписи TGT тикетов, то есть базовых Kerberos-ticket, так называемых golden tickets, с которыми пользователь потом получает доступ к сервисам.
Если обычный пароль — это ключ от двери, то KRBTGT ближе к печати охраны, которой заверяют пропуска. Смена пароля у сотрудника не ломает поддельный пропуск, если злоумышленник уже получил печать.
MITRE указывает: для сдерживания уже созданного Golden Ticket пароль KRBTGT нужно сбросить дважды. Первый сброс выполняется, затем нужно дождаться репликации, после этого проводят второй сброс. Такой порядок нужен для инвалидирования тикетов, созданных со старым ключом KRBTGT.
При нормальной эксплуатации это болезненная операция. Ошибка в ротации KRBTGT может сломать Kerberos-аутентификацию, особенно в больших доменах с несколькими контроллерами, старыми сервисами и нестабильной репликацией. Поэтому важнее сменить не пароли, а KRBTGT, проверить репликацию, время жизни старых тикетов и наличие признаков Golden Ticket.
DCSync: домен сам отдаёт секреты
DCSync — один из самых неприятных сценариев после повышения привилегий. Атакующий имитирует контроллер домена и запрашивает репликацию данных Active Directory. Для домена такой запрос может выглядеть легитимно: контроллеры действительно обмениваются данными репликации.
Проблема начинается, когда права на такую операцию получает лишняя учётная запись. MITRE описывает DCSync как злоупотребление интерфейсом контроллера домена для имитации репликации и доступа к учётным данным. Через DCSync можно получить хэши паролей, в том числе для KRBTGT и администраторов.
В этом месте массовая смена паролей превращается в бег по кругу. Компания меняет пароли, атакующий снова делает DCSync и забирает обновлённые хэши. Проблема не в старом пароле, а в правах, которые позволяют читать секреты домена.
Microsoft в материалах по защите Active Directory связывает Golden Ticket с DCSync и выгрузкой учётных данных. Среди рекомендаций — убрать DCSync-права у неадминистративных аккаунтов, включить защиту LSA на контроллерах домена, вести Kerberos-аудит и ротировать KRBTGT не реже одного раза в 180 дней с двойным сбросом.
Kerberoasting: сервисные учетки как тихая уязвимость
Ещё один частый путь — Kerberoasting. Атакующий запрашивает сервисный Kerberos-ticket для учетной записи с SPN, затем пытается оффлайн подобрать пароль к этому тикету. Домен при этом делает обычную работу: выдает тикет для доступа к сервису. Запросы TGS сами по себе не являются вредоносными.
Австралийский центр кибербезопасности ACSC в совместном гайде пишет, что Kerberoasting эксплуатирует пользовательские объекты с Service Principal Name. Если пароль сервисной учётной записи удаётся раскрыть, атакующий может аутентифицироваться от её имени. Риск резко растёт, когда такая учётка входит в Domain Admins или другую привилегированную группу.
Смена пароля пользователя здесь не даёт ничего, если взломана сервисная учётка. Нужны отдельные действия: длинные уникальные пароли, управляемые сервисные аккаунты gMSA, минимум прав, отказ от RC4 там, где это возможно, и мониторинг массовых TGS-запросов. В том же гайде ACSC указано, что RC4 для TGS-билетов упрощает взлом, а AES заметно повышает стоимость атаки.
Кейс NotPetya: когда украденные учётки разнесли сеть быстрее патчей
NotPetya в 2017 году часто вспоминают как «шифровальщик», но технически это был разрушительный вайпер. Для компаний важнее другое: вредонос активно использовал украденные учетные данные и штатные инструменты администрирования.
CISA писала, что NotPetya распространялся несколькими методами, а самый эффективный в большинстве случаев использовал модифицированную версию Mimikatz для кражи учетных данных Windows. Дальше заражение шло через легитимные механизмы удаленного выполнения, включая PsExec и WMI.
CrowdStrike в техническом разборе называл NotPetya «тройной угрозой»: шифрование файлов, повреждение MFT и кража учетных данных. В таком сценарии смена одного пароля уже не спасает: вредонос собирает доступы из памяти, идет дальше по сети и использует доверие Windows-инфраструктуры против самой компании.
Maersk стал самым известным бизнес-кейсом этой атаки. Исследование Columbia University разбирает, как системы компании были быстро скомпрометированы, а последствия тянулись еще несколько дней. В документе отдельно выделены два урока: нужна сегментация сети и рабочий план восстановления данных.
На этом примере хорошо видно, почему смена паролей — слабый ответ на угрозу. Когда домен уже используется как транспорт для распространения, нужно изолировать сегменты, проверять контроллеры домена, восстанавливать инфраструктуру из чистых резервных копий и разбирать, где именно были украдены учётные данные.
Кейс Colonial Pipeline: один пароль, старый VPN и цена учётной записи
Colonial Pipeline — не классический пример захвата AD. В 2021 году атака DarkSide началась с доступа через старый VPN-профиль без многофакторной аутентификации. CISA описывает инцидент как момент, когда уязвимость связанной цифровой инфраструктуры стала национальной проблемой для США.
Расследователи указывали, что использовался скомпрометированный VPN-пароль. Аккаунт был связан с устаревшим доступом, а MFA на нём не применялась. Главный вывод для AD-сред тот же: пароль может быть уже давно в утечке, учётка может считаться «неактивной», а доступ всё ещё работать.
Для корпоративной инфраструктуры это напоминание о том, что необходимо закрывать старые точки входа, отключать неиспользуемые аккаунты, проверять VPN, RDP, сервисные учётки, внешние публикации, доверенные домены и группы доступа.
Кейс NOBELIUM и AD FS: когда пароль вне фокуса
Гибридные среды добавляют еще один слой риска. В компаниях, где локальный Active Directory связан с облачными сервисами через AD FS или похожие механизмы, атакующий может охотиться за токенами и сертификатами.
Microsoft описывала MagicWeb — вредоносный модуль, который NOBELIUM использовал после компрометации. Он работал с Active Directory Federation Services и позволял манипулировать утверждениями в токенах, которые выдаёт AD FS. Для установки MagicWeb атакующим сначала понадобились высокопривилегированные учетные данные и доступ к AD FS-серверу.
Пароль пользователя в такой атаке может не быть главным объектом. Если захвачен сервер федерации, сертификаты, токены или механизм выпуска утверждений, простой сброс паролей не возвращает доверие. Нужно проверять AD FS, сертификаты подписи, конфигурацию федерации, сервисные аккаунты и журналы выдачи токенов.
Microsoft отдельно разбирала Golden SAML как атаку, где украденный сертификат подписи позволяет выпускать поддельные SAML-токены и обходить обычную проверку пароля. Для гибридных доменов это тот же класс проблемы: атакующий крадёт не пароль, а механизм доверия.
Что остаётся у атакующего после смены пароля
После сброса пароля у злоумышленника могут сохраниться несколько типов доступа.
- Активные сессии. Пользователь сменил пароль, но где-то уже есть открытое подключение, токен или процесс, запущенный от его имени.
- NTLM-хэш. Если среда допускает NTLM и у атакующего есть хэш, он может использовать Pass-the-Hash для перемещения по сети.
- Kerberos-ticket. Тикет живёт до истечения срока действия. Старый пароль уже не актуален, но тикет ещё принимается.
- Сервисная учётная запись. Пароли сервисных аккаунтов часто не ротируются годами, а прав у них больше, чем нужно.
- KRBTGT. При компрометации этой учётной записи атакующий может выпускать Golden Ticket. Здесь нужен двойной сброс KRBTGT и проверка репликации.
- DCSync-права. Если они остались у лишней учётки, атакующий сможет заново вытащить хэши после ротации.
- Бэкапы. В старых резервных копиях могут лежать NTDS.dit, системные состояния контроллеров домена, конфиги AD FS, секреты приложений и старые хэши.
Как массовый сброс вредит расследованию
Массовая смена паролей может быть нужной, но плоха как первое хаотичное действие. Она меняет состояние среды и усложняет восстановление таймлайна: какие учётки действительно использовались, какие входы были легитимными, какие события связаны с атакой, а какие появились из-за администраторской суеты?
План реагирования должен начинаться с фиксации картины: какие контроллеры домена видели подозрительную активность, были ли DCSync-запросы, какие машины обращались к LSASS, где запускались PsExec, WMI, PowerShell Remoting, какие учётки входили на нетипичные хосты, появлялись ли новые администраторы, менялись ли GPO и ACL.
Fidelis в плейбуке по восстановлению AD выделяет несколько обязательных шагов: изоляция скомпрометированных систем, временная остановка репликации при необходимости, расследование, восстановление учетных данных, ротация KRBTGT, проверка резервных копий и валидация репликации после восстановления.
Как реагировать на инциденты с Active Directory
После подозрения на компрометацию AD нужно действовать не по шаблону «всем сменить пароли», а по цепочке.
Сначала фиксируется масштаб: какие учётки, хосты, контроллеры домена и сервисы затронуты. Затем проверяются признаки кражи учётных данных: дамп LSASS, Mimikatz-подобная активность, подозрительные обращения к NTDS.dit, DCSync, DCShadow, массовые Kerberos-запросы, нестандартные типы шифрования, TGS без нормального предшествующего поведения.
Дальше идёт сдерживание: изоляция машин, отключение подозрительных аккаунтов, отзыв активных сессий там, где это возможно, закрытие старых VPN-профилей, блокировка лишних путей удалённого администрирования.
Потом — восстановление доверия: ротация паролей пользователей и сервисных учёток, проверка локальных админских паролей через Windows LAPS, пересмотр групп Domain Admins, Enterprise Admins, Account Operators, Backup Operators, проверка прав репликации, двойной сброс KRBTGT, ревизия AD FS и облачных токенов в гибридных средах.
В конце — усиление: отдельные админские учётки, запрет входа доменных админов на рабочие станции, tier-модель администрирования, MFA на внешнем доступе, отказ от лишнего NTLM, AES для сервисных билетов, мониторинг событий 4768, 4769, 4624, 4672, 4662, 5136 и сетевой активности между контроллерами домена.
Заключение
Смена паролей в Active Directory нужна, но она не равна устранению компрометации. Она помогает, когда украден именно пароль и злоумышленник не успел закрепиться. При хэшах, Kerberos-тикетах, DCSync, Golden Ticket, AD FS-токенах и скомпрометированных контроллерах домена пароль становится только одним элементом большой аварии.
