Притча о том, как я разбирался с dMSA при тестировании BadSuccessor-like сценариев

Берем за основу вот этот сплойтик → https://github.com/ibaiC/BadSuccessor

Сначала логика казалась простой:

есть пользователь
есть OU
выдаем ему CreateChild на dMSA
он создает dMSA
потом меняет нужные атрибуты

И как итог:

Но на практике для детекта этого все оказалось… не так просто.

Что я ожидал увидеть

Для BadSuccessor-like сценария я ожидал примерно такую цепочку событий:

Создание dMSA-объекта.
Здесь нас интересует объект класса:
msDS-DelegatedManagedServiceAccount
Ожидаемое событие:
5137 - A directory service object was created
Изменение чувствительных dMSA-атрибутов.
В первую очередь:
msDS-ManagedAccountPrecededByLink
msDS-DelegatedMSAState
Дополнительно может быть интересен:
msDS-GroupMSAMembership
Ожидаемое событие:
5136 - A directory service object was modified
Если смотреть уже не только изменение объекта, а дальнейшее использование dMSA, то дополнительно могут быть интересны события Kerberos/authentication-уровня:
2946 - события, связанные с dMSA authentication
4769 - запросы service ticket
4624 - успешные logon-события

Но моя задача была проще: проверить именно момент создания/модификации dMSA и понять, какие события должны появляться на DC.

Что получилось сначала

Запускаю PoC в лабе:

.\BadSuccessor.exe escalate -targetOU OU=target_ou,DC=test,DC=lab -dmsa escalate60 -targetUser CN=Administrator,CN=users,DC=test,DC=lab -dnshostname escal -machine winws10$ -dc-ip 10.10.10.10

p.s. да, попыток было много… мои коллеги постарались это раскурить.

Пользователь действительно мог создать dMSA:

В ADUC объект появляется… атрибуты на месте.

Все выглядит так, будто сценарий успешно отработал… но дальше начинается странное.

Смотрю… а события модификации нет…

Окей… пытаюсь отдельно изменить уже созданный dMSA через Set-ADObject и получаю:

Set-ADObject : Insufficient access rights to perform the operation
At C:\Users\Administrator\Desktop\test.ps1:1 char:1
+ Set-ADObject `
+ ~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (CN=escalate60,O...,DC=test,DC=lab:ADObject) [Set-ADObject], ADException
    + FullyQualifiedErrorId : ActiveDirectoryServer:8344,Microsoft.ActiveDirectory.Management.Commands.SetADObject

То есть пользователь может создать dMSA, но не может его редактировать.

Я был примерно такой:

На первый взгляд это выглядит нелогично:

Как так? Он же создал объект. Почему он не может его изменить?

Вопросиков у меня было очеееень много…

Где была ошибка в логике

Ошибка была в том, что я смешал две разные операции:

LDAP Add и LDAP Modify

Для Active Directory это не одно и то же.

Когда пользователь создает dMSA, это операция создания объекта:

LDAP Add / create object

Для нее достаточно права:

CreateChild

На нужный object class, в данном случае:

msDS-DelegatedManagedServiceAccount

Но когда объект уже создан и мы потом отдельно меняем ему атрибуты, это уже другая операция:

LDAP Modify

А для нее нужны отдельные права на запись атрибутов:

WriteProperty

например на:

msDS-ManagedAccountPrecededByLink

msDS-DelegatedMSAState

Именно поэтому у меня получилась такая картина:

создать dMSA пользователь может
изменить уже существующий dMSA не может
отдельного события модификации нужного атрибута нет
но атрибуты при этом могут оказаться заполненными, если они были переданы сразу при создании объекта

О да… знаете сколько мне потребовалось времени чтобы найти эти параметры?

Я почти всего pink гая пересмотрел на фоне…

Самый важный нюанс

Если атрибуты задаются сразу при создании dMSA, то для AD это может выглядеть как одна операция:

LDAP Add / create object
  objectClass = msDS-DelegatedManagedServiceAccount 
  msDS-ManagedAccountPrecededByLink = ... 
  msDS-DelegatedMSAState = 2 
CommitChanges()

Это создание объекта…

А не отдельная модификация!!!

То есть событие 5136 на изменение атрибута может не появиться просто потому, что отдельной операции Modify не было.

Был Add.

И если детект завязан только на:

“поймать изменение msDS-ManagedAccountPrecededByLink” то он может пропустить сценарий, где этот атрибут был установлен сразу на этапе создания dMSA.

Почему после добавления прав все заработало

Потом я добавил пользователю права на изменение нужных атрибутов для объектов dMSA.

И Я УВИДЕЛ ЗАВЕТНОЕ:

После этого сценарий стал работать уже в две фазы:

LDAP Add / create object
CommitChanges()

LDAP Modify
  msDS-ManagedAccountPrecededByLink = ...
CommitChanges()

И вот тут уже появляется то, что я ожидал увидеть:

объект dMSA создан
потом отдельно модифицирован
появляется событие модификации
детект на изменение атрибута начинает срабатывать

То есть проблема была не в том, что “события нет вообще”

Проблема была в том, что я ожидал Modify, а на деле у меня происходил Add с уже заполненными атрибутами.

Казалось бы… загадка разгадана!

Можно ощущать себя так:

Но… в голове летают 2 вопроса:

Почему если я добавлю моего юзера в практически любую системную группу AD, событие будет?
Почему без прав “все применилось”, но события Modify не было?

Почему через группу все нормально

Если пользователя добавить в группу с нужными правами, например в группу, которая имеет возможность модифицировать объекты/атрибуты в нужной OU, то все начинает работать.

Почему?

Потому что AD проверяет не только прямые права пользователя.

AD проверяет effective access, неожиданно правда?

В access token пользователя входят:

SID самого пользователя
SID его групп
SID nested-групп или как они там называются…
остальные security identifiers, которые применимы к этой сессии.

Если в ACL есть ACE не на самого пользователя, а на группу, в которой он состоит, операция пройдет.

Поэтому картина может быть такой:

Прямой ACE на пользователя нет -> но пользователь состоит в группе -> а у группы есть WriteProperty / GenericWrite / GenericAll -> Modify проходит

Это нормальное поведение AD.

Важно только помнить: после добавления пользователя в группу нужна новая сессия/новый токен.

Старый logon token сам по себе не всегда сразу увидит новую группу.

Почему без прав “все применилось”, но события Modify не было

Это был главный момент.

Как мы уже выяснили без прав на модификацию пользователь не мог выполнить отдельный Modify.

Но если PoC или код задает часть атрибутов прямо во время создания объекта, то они появляются как часть LDAP Add.

Снаружи выглядит так → атрибуты записались, но с точки зрения AD это не было отдельным изменением уже существующего объекта.

Поэтому отдельного события модификации и нет.

Вывод

Короткая формула всей истории:

CreateChild != WriteProperty

LDAP Add != LDAP Modify

5137 != 5136

Создать объект - не значит иметь право потом его редактировать.

Установить атрибут при создании объекта - не то же самое, что изменить атрибут после создания объекта.

Права пользователя - это не только прямые ACE, но и effective access через группы.

Именно из-за этого мой первый подход к детекту оказался неполным.

Я ждал событие модификации.

А надо было сначала понять, была ли вообще модификация… иногда это просто создание объекта с уже заполненными атрибутами.

Как-то оно так…