Delegated Managed Service Account Abuse

Also calleddMSA abuse, BadSuccessor, msDS-DelegatedMSAState abuse

A superseded service account hands a new managed account its reach.

Needs
Directory Write
Gives
Account Access

How the Attack Works

Microsoft fixed the abuse path in 2025, so on an updated Windows Server 2025 domain a defender reads this as a check on who may write the migration attributes. A delegated managed service account, new in Windows Server 2025, can be set to supersede an existing service account, and the migration attributes msDS-DelegatedMSAState, msDS-ManagedAccountPrecededByLink and msDS-SupersededManagedServiceAccountLink decide which account it takes over. Where another principal can write those attributes, the takeover can be pointed at a privileged account, so a sign-in as the dMSA then carries that account's reach. MITRE maps the manipulation to Account Manipulation and the resulting read of the account's keys to Credentials from Password Stores.

Read first Kerberos Delegation, Password Hashes and Kerberos Keys

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

On dc-01 a defender finds a delegated managed service account's migration attributes written to supersede svc-backup, so a sign-in as the dMSA would carry that account's reach. Microsoft fixed the abuse path in 2025.Step through it

ws-042 Foothold

dc-01 Domain controller

  1. Step 1 of 3, Migration Link Set, ws-042 to dc-01
  2. Step 2 of 3, Supersedes the Account, on dc-01
  3. Step 3 of 3, Reach of the Account, ws-042 to dc-01

  1. Step 1 of 3: Migration Link Set

    ws-042 Foothold to dc-01 Domain controller

    A migration link written LDAP ModifyRequest LDAP, port 389

    A dMSA's migration attributes are written on dc-01 to point its takeover at svc-backup, an existing service account.

    Logged

    • 5136 A directory service object was modified

      On dc-01, in the Security log When enabled

      A dMSA migration attribute written, linking it to svc-backup.

    What Defenders See

    With Audit Directory Service Changes on and an audit entry on the service-account objects, dc-01 writes event 5136 showing the migration attributes changed.

  2. Step 2 of 3: Supersedes the Account

    On dc-01 Domain controller

    The dMSA now supersedes svc-backup, so the directory links the two and the dMSA inherits what svc-backup could reach.

    What Defenders See

    The directory shows the dMSA linked to a privileged service account. Defender for Identity raises its suspicious dMSA activity alert.

  3. Step 3 of 3: Reach of the Account

    ws-042 Foothold to dc-01 Domain controller

    A sign-in as the dMSA KRB_AS_REQ Kerberos, port 88

    A sign-in as the dMSA reaches whatever svc-backup could, since the directory now hands the dMSA that account's keys.

    What Defenders See

    The sign-in looks like the dMSA's own. Defender for Identity's dMSA alert, and its Golden gMSA alert for the sibling managed-account read, are the lead.

    Hooks into Kerberos AS Request

Needs First

What the attacker must already hold for this attack to be possible.

  • Write Access to a Directory ObjectWrite access to a dMSA's migration attributes, which point it at the account it supersedes.

Comes From

Gives the Attacker

What running it hands the attacker to use next.

  • Access as Another AccountA sign-in as the dMSA that carries the superseded service account's reach.

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and LogWritten OnLook ForSwitch It On
5136 A directory service object was modified (opens in a new tab) Security logDomain controllers, for objects with a matching audit entryA write to a dMSA migration attribute (msDS-ManagedAccountPrecededByLink or msDS-DelegatedMSAState) that points its takeover at a privileged account.Audit Directory Service Changes, and an audit entry (SACL) on the object

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

5136 A directory service object was modified

In the Security log on dc-01,

A dMSA migration link on dc-01 pointed at a service account.

  • The attribute that changed. It names the account a delegated managed service account supersedes, so a privileged target here is the signal.

    As Windows writes it: LDAP Display Name msDS-ManagedAccountPrecededByLink

  • The dMSA that gained the link. From the takeover on, a sign-in as it carries the superseded account's reach.

    As Windows writes it: DN CN=svc-app-dmsa,CN=Managed Service Accounts,DC=corp,DC=example

  • A value was added to the attribute. Read the linked account to see which service account the takeover now points at.

    As Windows writes it: Operation Type Value Added

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

  • Event 5136 needs Audit Directory Service Changes and an audit entry on the service-account objects, so without it the migration link leaves no event.
  • The migration attributes are a normal Windows Server 2025 feature, so judge a write by which account the takeover is pointed at, not by the write alone.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Sees It DirectlyAlertEvidence (Defender for Identity alerts) (documentation, opens in a new tab)

Needs Defender for Identity sensors on every DC. The alert fires on a suspicious dMSA migration and on the sibling managed-account read. Confirm by reading the dMSA's migration attributes and the account they point at.

KQLDefender XDR, Advanced hunting
// Defender for Identity dMSA and Golden gMSA alerts, with the accounts and machines they nameAlertEvidence| where Timestamp > ago(30d)| where Title contains "DMSA" or Title contains "gMSA"| summarize FirstSeen = min(Timestamp), Accounts = make_set_if(AccountName, isnotempty(AccountName)), Devices = make_set_if(DeviceName, isnotempty(DeviceName)), Addresses = make_set_if(RemoteIP, isnotempty(RemoteIP)) by AlertId, Title| order by FirstSeen desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Attacks tied to this one that its needs and gives do not already name, such as another form of it or its reverse, each with how the two connect.

  • Kerberoasting

    The offline-guessing weakness that managed service accounts, dMSAs included, were built to remove.

  • LAPS and gMSA Password Reads

    The older managed accounts, LAPS and gMSA, where the reach comes from reading a password the directory keeps.

Sources