Собеседование на аналитика Active Directory security: что спрашивают и почему net user не спасёт

Три из пяти кандидатов на позицию аналитика безопасности Active Directory, которых я собеседовал за последний квартал, уверенно отвечали на вопрос «как получить список пользователей домена» — net user /domain. И тут же зависали на следующем: «у этого пользователя GenericAll на OU с сервисными аккаунтами — какой вектор атаки?». Вот эта дистанция между «знаю команды» и «понимаю модель безопасности» — ровно то, что отделяет проходной ответ от оффера. Ниже — реальные вопросы на собеседовании по Active Directory security: ACL, делегирование, Kerberos-атаки и разбор, где поверхностная подготовка ломается.

Что проверяют на собеседовании аналитика безопасности Active Directory

Active Directory (AD) — централизованный каталог пользователей, компьютеров, групп и политик безопасности в Windows-сетях. По сути, это основа управления доступом всей организации и одновременно — главная мишень при атаках на корпоративную инфраструктуру. Аналитик безопасности AD — человек, который видит не отдельные объекты, а связи между ними: кто кому может сбросить пароль, кто способен добавить себя в группу Domain Admins, какой сервер хранит «мастер-билеты» подключившихся пользователей.

Команда net user /domain покажет список учётных записей. Для базовой разведки — нормально, но на собеседовании проверяют не навык ввода команд, а понимание контекста. Вот что интервьюер ищет за ответом про net user:

• Модель разрешений: как устроены ACL (Access Control List — список, определяющий, кто и что может делать с объектом в AD) и почему одно «лишнее» право на OU (Organizational Unit — контейнер для группировки объектов) превращается в путь до Domain Admin.
• Делегирование: зачем оно существует, какие три типа есть в Kerberos (протокол аутентификации в AD) и как каждый из них эксплуатируется.
• Цепочки атак: не отдельная техника, а последовательность шагов — privilege escalation AD от низкопривилегированного пользователя до полного контроля над доменом.
• Привязка к фреймворкам: интервьюеры ожидают, что кандидат соотносит атаку с MITRE ATT&CK (открытая база тактик и техник атак; каждая техника имеет идентификатор вида Txxxx, например T1558.003 для Kerberoasting) и объясняет, к какой фазе атаки она относится.

На собеседовании по безопасности AD проверяют способность мыслить графами — связями между объектами, правами и доверием. От собеседования SOC-аналитика это отличается принципиально: там акцент на SIEM и реагировании, здесь — на архитектуре доступа.

ACL и DACL Active Directory: вопросы, на которых сыпятся кандидаты

Каждый объект в AD — пользователь, группа, компьютер, OU — имеет собственный DACL (Discretionary Access Control List — часть ACL, где записаны разрешения «кто может что делать с объектом»). Есть ещё SACL (System ACL) — он отвечает за аудит, логирование обращений к объекту. На собеседовании чаще спрашивают про DACL, потому что через него строятся пути эскалации привилегий.

Если работали с файловой системой NTFS — принцип знакомый: ACL определяет, кто может читать и записывать файлы. В AD — то же самое, но объекты другие: учётные записи, группы и политики. И «право на запись» здесь может означать возможность сбросить чужой пароль или добавить себя в группу администраторов домена. Концептуально это похоже на Broken Access Control из OWASP Top 10 (A01:2021 — риск №1 среди веб-уязвимостей, когда разрешения не соответствуют реальному назначению; аналогия иллюстративная — OWASP классифицирует уязвимости веб-приложений, а не AD).

ACE и цепочки прав Active Directory: как одно разрешение становится вектором атаки

DACL состоит из отдельных записей — ACE (Access Control Entry). Каждая ACE говорит: «субъект X имеет право Y на объект Z». Права бывают стандартные (чтение, запись, удаление) и расширенные — именно расширенные ACE permissions Windows создают проблемы. Ключевые, о которых спрашивают на собеседованиях (по данным SecureLayer7):

GenericAll — полный контроль над объектом. Можно сбросить пароль, изменить членство в группах, переписать любой атрибут. GenericWrite — запись атрибутов. Выглядит безобидно, но позволяет добавить SPN (Service Principal Name — идентификатор сервиса в Kerberos) на учётную запись и провести targeted Kerberoasting. WriteDACL — перезапись самого списка разрешений. Через него можно выдать себе GenericAll — и дальше делать что угодно. ForceChangePassword — сброс пароля без знания старого. AddMember — добавление аккаунтов в группу. Если группа — Domain Admins, комментарии излишни.

Критический момент, который проверяют на собеседовании: опасность не в одном праве, а в том, как права складываются в цепочку. Пример, описанный SecureLayer7:

1. Скомпрометированный пользователь имеет GenericWrite на сервисный аккаунт.
2. Через GenericWrite атакующий добавляет фальшивый SPN на этот аккаунт.
3. Аккаунт становится «kerberoastable» — можно запросить его TGS-тикет (Ticket Granting Service — сервисный тикет, зашифрованный паролем целевого аккаунта) и взломать пароль офлайн.
4. Если сервисный аккаунт привилегированный — эскалация завершена.

Одно «скучное» разрешение → полная компрометация. Ответ «у пользователя GenericWrite, это не критично» на собеседовании — провал.

Права в AD наследуются от родительских контейнеров. GenericAll для группы helpdesk на корневом OU означает контроль над всеми дочерними объектами. Со временем такие права накапливаются: сотрудник сменил отдел, подрядчик ушёл, а ACE остались. Semperis описывает это прямо: «legacy configurations remain in place, creating potential avenues for attackers». Знакомая картина — в каждом втором домене, который я видел, helpdesk имеет права, о которых сам helpdesk не подозревает.

BloodHound Active Directory: инструмент, который ждут на собеседовании

BloodHound — инструмент визуализации связей между объектами AD и поиска путей эскалации привилегий через ACL. Работает так: коллектор SharpHound (или Python-аналог bloodhound-python) собирает данные о пользователях, группах, компьютерах, ACL и активных сессиях через LDAP и SMB. BloodHound строит граф — узлы (объекты) и рёбра (права). SecureLayer7 формулирует прямо: «BloodHound exists precisely to find where these rights connect into a path».

Если кандидат на позицию аналитика безопасности Active Directory не может объяснить принцип работы BloodHound — это красный флаг. Типичные вопросы:

«Какие данные собирает SharpHound и как это обнаружить?» — массовые LDAP-запросы, перечисление SMB-сессий, RPC-вызовы. Обнаружение — по аномальному объёму LDAP-запросов с одного хоста за короткий период.

«Покажи встроенный запрос для поиска пути до Domain Admin.» — кандидат должен знать стандартные запросы интерфейса (Shortest Path to Domain Admins from Owned Principals) или описать логику Cypher-запроса в Neo4j.

«Как используешь BloodHound для защиты, а не для атаки?» — ключевой вопрос для аналитика. Ответ: регулярный аудит ACL, выявление и удаление избыточных прав, контроль изменений DACL на критичных объектах. Для тех же задач есть PowerView (модуль из PowerSploit) и штатный dsacls, но BloodHound даёт визуализацию, которой у них нет. Когда видишь граф с 12 рёбрами от helpdesk_user до Domain Admins — это убедительнее любого текстового отчёта.

Делегирование прав Active Directory: три вида и три вектора атаки

Делегирование в Kerberos — когда один сервис действует от имени пользователя. Представьте: вы заходите на внутренний веб-портал, а он обращается к базе данных «от вашего имени». Для этого порталу нужно право представляться вами. Это как доверенность: удобно, но если она попадёт не в те руки — последствия масштабные.

Вопросы про делегирование прав Active Directory — обязательная часть собеседования на аналитика AD security. Три типа делегирования — три разных уровня риска и три разных вектора Kerberos-атак на собеседовании.

Unconstrained delegation и кража TGT

Unconstrained delegation (неограниченное делегирование) — самый старый и самый опасный тип. Сервер с этим флагом получает TGT (Ticket Granting Ticket — «мастер-билет» Kerberos, дающий доступ к запросу любых сервисных тикетов в домене) каждого пользователя, который к нему подключается.

Механизм по данным adsecurity.org: при обращении пользователя к сервису на сервере с unconstrained delegation контроллер домена помещает копию TGT пользователя прямо внутрь сервисного тикета. Сервер извлекает TGT и сохраняет в LSASS (Local Security Authority Subsystem Service — процесс Windows, хранящий учётные данные в памяти). Результат: сервер может представляться этим пользователем где угодно в домене, без ограничений.

Вектор атаки: скомпрометировать сервер → заставить (через coercion-технику, например PrinterBug или PetitPotam) или дождаться подключения Domain Admin → извлечь его TGT → полный контроль домена. Sean Metcalf (adsecurity.org) формулирует жёстко: «No need to wait — the ticket can be used immediately to get the domain KRBTGT account password hash».

Как найти серверы с unconstrained delegation — частый вопрос на собеседовании. Нужен модуль ActiveDirectory для PowerShell (предустановлен на контроллерах домена; на рабочей станции — установите RSAT):

Get-ADComputer -Filter {TrustedForDelegation -eq $true} `
  -Properties TrustedForDelegation |
  Select-Object Name, TrustedForDelegation

Ожидаемый вывод: список компьютеров с TrustedForDelegation = True. Контроллеры домена всегда в этом списке — штатное поведение. Любой другой сервер — потенциальный риск, требующий обоснования.

Защита (ожидаемый ответ аналитика):

• Убрать unconstrained delegation со всех серверов, кроме контроллеров домена. Для бизнес-приложений — constrained delegation.
• Пометить привилегированные аккаунты флагом «Account is sensitive and cannot be delegated».
• Добавить критичные аккаунты в группу Protected Users (доступна с Windows Server 2012 R2). По данным adsecurity.org, для участников этой группы делегирование запрещено, NTLM не используется, TGT имеет сокращённый срок жизни без возможности продления, а NTLM-хэш и слабые Kerberos-ключи (DES/RC4) не кешируются в памяти.

Constrained delegation, RBCD и Kerberoasting через делегирование

Constrained delegation (ограниченное делегирование) — ограничивает перечень сервисов, которым аккаунт может представляться пользователем. Безопаснее unconstrained, но через механизм S4U (Service for User — расширение Kerberos для делегирования) атакующий, контролирующий такой аккаунт, может представляться пользователями для разрешённых сервисов. А при наличии флага protocol transition (TrustedToAuthForDelegation) — вообще любым пользователем.

Признак в AD: атрибут TrustedToAuthForDelegation = True и заполненный msDS-AllowedToDelegateTo.

RBCD (Resource-Based Constrained Delegation) — настраивается не на делегирующем аккаунте, а на целевом объекте через LDAP-атрибут msDS-AllowedToActOnBehalfOfOtherIdentity. По данным SecureLayer7: если атакующий может записать этот атрибут (через GenericWrite или WriteDACL на целевом объекте), он разрешает контролируемой машине представляться любым пользователем для целевого сервиса — включая Domain Admin.

Вот где ACL-abuse и delegation-abuse пересекаются: одно право записи на атрибут → полная эскалация привилегий. Именно поэтому на собеседовании вопросы по ACL delegation Active Directory всегда идут вместе — разделять их искусственно.

Targeted Kerberoasting через ACL — ещё один пример пересечения. Kerberoasting — атака, при которой запрашивается TGS-тикет для аккаунта с SPN и взламывается офлайн (тикет зашифрован паролем целевого аккаунта; если пароль слабый — ломается за минуты). Обычно атаке подвержены аккаунты с уже установленным SPN. Но если у атакующего есть GenericWrite — он сам добавляет SPN на любой аккаунт, делая его «kerberoastable». Знание связки Kerberoasting и delegation — маркер кандидата, который понимает, как ACL и Kerberos работают вместе.

Практический блок: разбираем вопрос с собеседования шаг за шагом

Типичная задача на собеседовании аналитика AD security: «Вам передали результаты BloodHound — обнаружен путь от пользователя helpdesk_user до Domain Admins через три промежуточных объекта. Опишите действия как аналитик безопасности».

Сильный ответ выглядит как чёткая последовательность:

Шаг 1. Определить конкретные ACE в цепочке.

Нужно понять, какие именно права задействованы на каждом ребре графа BloodHound — чтобы оценить реальность эксплуатации и приоритет устранения.

На контроллере домена (требуются права на чтение ACL — обычно есть у аналитика безопасности):

(Get-Acl "AD:\OU=ServiceAccounts,DC=corp,DC=local").Access |
  Where-Object {$_.IdentityReference -match "helpdesk"} |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Ожидаемый вывод: строки с правами GenericAll, WriteDacl, WriteProperty для пользователя или группы helpdesk. GenericAll на OU с сервисными аккаунтами — критическая находка. ReadProperty — штатная ситуация, не требует действий.

Шаг 2. Оценить бизнес-обоснование каждого права.

Не каждое «опасное» право — ошибка конфигурации. Helpdesk может легитимно иметь ForceChangePassword на пользовательские OU — типичная делегированная задача. GenericAll на OU с сервисными аккаунтами — почти наверняка конфигурационный дефект.

Для каждого ACE в цепочке задайте вопрос: «кто, когда и зачем это настроил?». Нет ответа — право подлежит удалению или замене на минимально необходимое.

Шаг 3. Устранить избыточные права и задокументировать.

Найти проблему — половина работы. Вторая — убрать её без поломки бизнес-процессов.

Если helpdesk нужен сброс паролей — оставить только ForceChangePassword на конкретные OU, убрать GenericAll. Привязать изменение к тикету. Semperis рекомендует встроить это в цикл: «continuous monitoring and maintenance of ACLs involves regularly reviewing and auditing permissions, identifying and remediating misconfigurations».

Шаг 4. Верифицировать результат.

Повторно запустить SharpHound и проверить в BloodHound, что путь до Domain Admins через эту цепочку больше не существует. Это доказательство, что remediation сработал. Без этого шага — работа не завершена.

Слабый ответ кандидата: «удалю права и закрою тикет». Сильный: полный цикл от анализа до верификации с учётом бизнес-контекста. Тиерная модель (Tier 0 — контроллеры домена и критичная AD-инфраструктура, Tier 1 — серверы приложений, Tier 2 — рабочие станции и учётные записи пользователей; описана Semperis как стратегия сегментации привилегий) — тот фреймворк, в котором аналитик обосновывает приоритеты устранения. Права, ведущие от Tier 2 к Tier 0, устраняются первыми.

Если посмотреть на русскоязычные материалы по подготовке к собеседованиям в ИБ — почти все про SOC: SIEM-системы, реагирование на инциденты, анализ сетевого трафика. Вопросы по Active Directory либо сводятся к «что такое групповая политика», либо не покрываются вообще. При этом AD security — одна из самых дефицитных специализаций: каждый пентест внутренней инфраструктуры проходит через AD, каждая команда защиты нуждается в людях, которые понимают модель разрешений и делегирования.

Основная проблема кандидатов, которую я наблюдаю, — разрыв между знанием отдельных команд и пониманием системы. Человек показывает Get-ADUser, net group "Domain Admins" /domain, даже запускает BloodHound — но не может объяснить, почему WriteDACL на контейнер AdminSDHolder опаснее, чем GenericAll на рядовую учётную запись. Этот разрыв — прямое следствие подготовки по чек-листам команд вместо изучения модели безопасности.

Моя позиция: если вы переходите в AD security из системного администрирования или SOC — начинайте не с инструментов, а с модели. Разберите, как устроен DACL объекта, как работает наследование ACE, зачем нужна тиерная модель. Потом подключайте BloodHound и PowerShell — они станут инструментами для проверки того, что вы уже понимаете, а не костылями для имитации знаний. Если переходите из IT в ИБ и нужна структура, а не набор разрозненных статей — IB Basics даёт эту базу за пару месяцев.