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

![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/d26d903b-0c8d-4253-9a1f-f811d891819c/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=a4b1bce22769536450e32e88cae998d65507acaadf7543e4a8a3cf49e56d0821&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject "full-width =1200x900")

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

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

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

И как итог:

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/556ce46d-331e-47f3-9052-14d26cfe4899/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=a49d08527a80795e1aeb13d2991744b36debc61905bd9222d10814651915b696&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =480x360")

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

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

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


1. Создание dMSA-объекта.

   Здесь нас интересует объект класса:

   `msDS-DelegatedManagedServiceAccount`

   Ожидаемое событие:

   `5137 - A directory service object was created`
2. Изменение чувствительных dMSA-атрибутов.

   В первую очередь:

   `msDS-ManagedAccountPrecededByLink`

   `msDS-DelegatedMSAState`

   Дополнительно может быть интересен:

   `msDS-GroupMSAMembership`

   Ожидаемое событие:

   `5136 - A directory service object was modified`
3. Если смотреть уже не только изменение объекта, а дальнейшее использование dMSA, то дополнительно могут быть интересны события Kerberos/authentication-уровня:

   `2946` - события, связанные с dMSA authentication

   `4769` - запросы service ticket

   `4624` - успешные logon-события

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

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

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

```bash
.\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:

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/869f2dff-1c44-44a4-a664-bb7a6dd9e094/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=fc0baf6c8fc2bc6c52b6221db3e92c163622a0017ed466bbd56603a1933375a0&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =583x461")

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

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

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

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

```bash
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, но не может его редактировать.

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

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/16843f89-cc40-4b76-88a8-c132053ab646/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=e0ebee2ed5e21e174ccb116d0e700aaec8b93fd21376966f67f252f4570f489e&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =456x403")

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

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

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

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

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

`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 гая пересмотрел на фоне…

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/df1a36bd-8693-4693-83dc-808bf1c0ecb6/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=3409fa52872537a8673148ce91f435cc1783bc1004c9a373ae2e183e8f729a62&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =512x512")

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

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

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

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

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

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

Был `Add`.

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

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

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

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

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

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/afdff858-4ecc-420e-91a3-22eba295bf0c/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=600e974452cd5fe30a5d85d705c7fdc913276864bc37cc69c3f01246a31156e3&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =414x61")

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

```bash
LDAP Add / create object
CommitChanges()

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

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

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

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

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

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

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

 ![](https://minio.binarybears-notes.ru/datawiki/uploads/2ba6af96-dd8f-4b8c-a54a-407b032139de/7f981874-860f-4001-ba1b-39982c8ce353/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=k1xoKWsik3tOODwj9qdO%2F20260924%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20260924T103000Z&X-Amz-Expires=86400&X-Amz-Signature=1f6c1e20a1930e3aab7338e6dd69314ae19655c79ab8ee03b75c5e0548e03914&X-Amz-SignedHeaders=host&x-amz-checksum-mode=ENABLED&x-id=GetObject " =406x318")

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

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

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

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

> **Почему?**

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

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

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

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

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

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

```bash
Прямой 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 через группы.

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

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

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


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