BadSuccessor: How the Feature That Killed Service-Account Attacks Became Domain Admin

1. One ACE, No Password Reset, Domain Admin#

UserA is nobody. She sits in no privileged group, owns no server, and holds exactly one delegated permission: the right to create child objects in a single, forgotten organizational unit that some administrator carved out years ago and never revisited. Twelve minutes later she is authenticating to every machine in the forest as the built-in Administrator, and she never touched the Administrator account, never reset a password, never added herself to a group, never dumped LSASS, and never extracted the krbtgt key.

Here is the whole path, at altitude. UserA creates one object in that OU, a new account type called a delegated Managed Service Account. She writes two attributes on it: a link that names the Administrator as the account this new object succeeds, and a small integer that declares the succession already finished.

Then she points a machine she controls at a domain controller and asks for a Kerberos ticket for her new account. The domain controller reads the succession link, believes it, and stamps the Administrator's identity into her ticket. That is the attack. Akamai, who disclosed it, describes the result exactly: the operator can "act with the privileges of any user in Active Directory, without modifying the target object" ^[1].

Sit with the negative space, because it is the entire point. No Domain Admin password changed. No membership was added to any privileged group. No access-control entry on the Administrator object ever fired, because the Administrator object was never opened, read, or written ^[1]. Nothing was cracked offline. No replication right was invoked. Every classic Active Directory takeover leaves one of those marks; this one leaves none of them, because the target is a bystander to its own impersonation ^[2].

The account type Microsoft engineered to end service-account attacks -- to make stolen and cracked service credentials a thing of the past -- briefly became the cleanest domain takeover in years. That is not a contradiction to explain away. It is the thing this article explains: a single feature can be a genuine security improvement and an escalation primitive at the same time, and the reason is precise.

Two facts keep that framing honest, and I will hold them in view for the whole article rather than spring them at the end. First, this was never a universal exposure. It requires a domain running at least one Windows Server 2025 domain controller with a generated KDS root key, and at disclosure Tenable's Satnam Narang estimated that only about 0.7% of Active Directory domains met that bar ^{[3] [2]}.

Second, the window was short. Yuval Gordon of Akamai disclosed the technique, named BadSuccessor, on May 21, 2025 ^[4], and Microsoft closed the direct escalation with CVE-2025-53779 in the August 2025 update ^{[5] [3]}.

To see how a safety feature became the cleanest takeover in years, we have to start where its designers started: with the problem it was built to solve.

2. The Service-Account Problem#

Ask a question that only sounds simple: how does a background service prove who it is? A human logs in and types a password. A batch job, a database engine, or a web application has no one at the keyboard, yet it still needs a domain identity so it can request tickets, read shares, and talk to other servers under least privilege.

For roughly two decades the standard answer in Active Directory was the same: give the service an ordinary user account, register a Service Principal Name on it so clients can ask Kerberos for tickets to it, and set a password by hand.

That one sentence -- "set a password by hand" -- is the whole weakness, and it took years to see how deep it ran. The account's long-term Kerberos key is derived directly from its password. And here is the property nobody designed on purpose: any authenticated user in the domain can request a service ticket for any SPN.

Put those two facts together and a quiet catastrophe falls out. An attacker asks the KDC for a service ticket to some svc_sql account, receives a blob encrypted under that account's password-derived key, and walks away to crack it offline, on their own hardware, at their own pace, with zero packets ever sent to the SQL host. A service password of Summer2024! falls in seconds. This is Kerberoasting, and it is the design pressure behind everything that follows.

Medin's own framing of the talk names the danger with unusual economy: it is "a way to attack the credentials of a remote service without sending traffic to the service as well as rewriting tickets to access systems" ^[7]. The full attack surface of legacy service accounts -- shared secrets, stale passwords, over-broad rights -- extends well beyond this post; here only one property matters.

Any authenticated user can request a service ticket for any SPN, and that ticket is encrypted under a key derived from a human-chosen password. The password is therefore crackable offline, by anyone, with no traffic to the service.

That is the shift the rest of this story depends on. A service account is not "just an account with a password you keep secret." Its secret is broadcast, on request, to every member of the domain, in a form built to be attacked at leisure.

The only durable fix is to make the secret itself uncrackable: machine-generated, long, and rotated automatically, so that "request a ticket, crack the key" stops paying. Microsoft would eventually say exactly this in its own guidance, recommending managed service accounts precisely because "AD machine account credentials are long and randomly generated" and so make brute force impractical ^[8].

Microsoft's first attempt to take the human out of the password lifecycle shipped in 2009, and it immediately hit a wall.

3. Two Generations of Managed Accounts: sMSA and gMSA#

If the fix is "let the machine own the secret," why did it take three tries and sixteen years? Because each generation solved the previous one's failure and quietly exposed a new one. The lineage is not a story of incompetence; it is a story of residuals, where every honest improvement leaves exactly one thing still wrong, and the next generation is built to answer that one thing.

flowchart LR
A["Legacy service account, static password"] --> B["sMSA 2009, single-host managed password"]
B --> C["gMSA 2012, multi-host via KDS root key"]
C --> D["dMSA 2024, machine-bound secret, one-click migration"]
D --> E["BadSuccessor May 2025, succession link abused"]
E --> F["CVE-2025-53779 Aug 2025, KDC validates the link"]
K["Kerberoasting 2014, offline key cracking"] -.-> D

Generation one: the standalone MSA (sMSA), 2009. Shipped with Windows Server 2008 R2, the standalone Managed Service Account removed the human from the password lifecycle entirely ^[10]. The operating system generates the account's password, rotates it automatically, and manages the SPN, so there is no admin-chosen secret left to crack. Microsoft's own summary is that these accounts "eliminate the need for an administrator to manually administer" the SPN and credentials ^[11]. It worked, and it defeated the specific thing Kerberoasting preyed on -- for services that live on a single machine.

That last clause is the residual. An sMSA is bound to one host, so it "can't be shared among multiple computers" and "can't be used in server clusters" ^[11]. The moment a service is load-balanced across a farm or clustered for availability -- which is most services worth protecting -- the sMSA model breaks, and teams fall back to an ordinary shared-password account. Kerberoasting comes right back in through that fallback.

Generation two: the group MSA (gMSA), 2012. Windows Server 2012 generalized the managed secret to a group of hosts. A domain-wide key, the KDS root key, lets every authorized host derive the same managed password for the account, so a clustered or load-balanced service can finally run under one managed identity. Microsoft states it plainly: the gMSA "provides the same functionality within the domain and also extends that functionality over multiple servers," and the Microsoft Key Distribution Service (kdssvc.dll) "lets you securely obtain the latest key" for the account ^[10].

The gMSA solved the farm problem, and it left its own residual, one Microsoft names without flinching in the dMSA documentation: although gMSAs use "machine generated and autorotated passwords, the passwords are still not machine bound and can be stolen" ^[13]. The secret is machine-retrievable, not machine-bound. Any host authorized in msDS-GroupMSAMembership, or anyone who can read the password blob with sufficient rights, can compute the real password. On top of that, moving a running legacy service onto a gMSA is a manual, disruptive project that many teams simply never finish.

The table makes the residual chain explicit.

Two demands were left for generation three: make the secret genuinely un-retrievable, so it never leaves the domain controller, and make migration one-click, so the manual project that stalled everyone finally becomes trivial. The first demand is the one everybody wanted. The second is the one that introduced the machinery BadSuccessor would break.

4. dMSA and the Supervised Migration#

The delegated Managed Service Account is generation three, and it arrived with Windows Server 2025, which reached general availability on November 1, 2024 ^{[15] [16]}. It answers both leftover demands: it makes the secret genuinely un-retrievable, and it makes migration one-click. To deliver that one-click migration, it teaches the KDC to honor a succession link -- and that single design choice is the entire story of this article.

Start with what dMSA got right, because it is a real advance. A dMSA's authentication is bound to a machine identity mapped in Active Directory, so only specified machines can use it. Its secret is a randomized value "derived from the machine account credential" and held by the domain controller, and Microsoft is explicit that it "can't be retrieved or found anywhere other than on the DC" ^[13]. Where a gMSA password could be computed by any authorized host, a dMSA secret never leaves the domain controller at all, and it can be further sealed by Credential Guard.

Now the load-bearing novelty: the supervised in-place migration. Instead of the manual, disruptive gMSA cutover that teams abandoned, a dMSA can supersede a legacy account. Password authentication to the old account is blocked, and authentication is redirected through the Local Security Authority to the dMSA, which, in Microsoft's own words, "has access to everything the previous account could access in AD" ^[13].

During the supervised migration, the dMSA takes over the resources the legacy account was using, and the two can co-exist for a time until that account is disabled. The successor "has access to everything the previous account could access in AD." -- Microsoft, Delegated Managed Service Accounts overview ^[13]

How does the successor inherit that access? Through the directory, driven by two PowerShell cmdlets that write a small set of attributes. Start-ADServiceAccountMigration opens the migration: it sets the dMSA's msDS-DelegatedMSAState to 1, points msDS-ManagedAccountPrecededByLink at the legacy account, sets msDS-SupersededAccountState to 1 and msDS-SupersededManagedServiceAccountLink back at the dMSA, and grants the legacy account Generic Read on all of the dMSA's properties plus Write on msDS-GroupMSAMembership, so it can participate.

Complete-ADServiceAccountMigration closes it: it sets msDS-DelegatedMSAState to 2, copies the SPNs, the msDS-AllowedToDelegateTo delegation settings, and the authentication policy onto the dMSA, sets msDS-SupersededServiceAccountState to 2, and disables the old account ^[13].

flowchart TD
S0["Legacy service account, still active"] --> S1["Start-ADServiceAccountMigration"]
S1 --> A1["dMSA msDS-DelegatedMSAState set to 1, begun"]
S1 --> A2["dMSA msDS-ManagedAccountPrecededByLink points at legacy account"]
S1 --> A3["Legacy account granted Generic Read on all dMSA properties, plus Write on msDS-GroupMSAMembership"]
A1 --> C1["Complete-ADServiceAccountMigration"]
A2 --> C1
A3 --> C1
C1 --> B1["dMSA msDS-DelegatedMSAState set to 2, completed"]
C1 --> B2["SPNs, delegation, and auth policy copied to dMSA"]
C1 --> B3["Legacy account disabled"]
B1 --> KDC["At login, KDC honors the link and copies the predecessor security context into the dMSA PAC"]

The attribute types matter, so hold two of them apart. msDS-ManagedAccountPrecededByLink is a distinguished-name link, a back-reference that names the predecessor. msDS-DelegatedMSAState is a state integer: 1 means the migration has begun, 2 means it has completed ^[13]. When the dMSA later authenticates, the KDC reads that link and duplicates the named predecessor's security context onto the successor's Privilege Attribute Certificate.

The safety premise is hiding in the word supervised. In the legitimate flow, the real superseded account participates: it is granted read on the dMSA and it refreshes its own ticket-granting ticket as part of the handover. Microsoft even fences the feature to keep it coherent, noting that "you can't migrate from a managed service account or a gMSA to a dMSA" ^[13]. The migration is designed to be safe because the predecessor is in the loop.

The following model reads a succession record the way the KDC does. Notice how little it takes to look "completed."

// msDS-DelegatedMSAState: 0 = none, 1 = migration begun, 2 = migration completed
const stateNames = { 0: 'none', 1: 'begun', 2: 'completed' };

function readSuccession(record) {
const state = stateNames[record.delegatedMSAState] || 'unknown';
const linked = record.precededByLink || '(none)';
console.log('dMSA:        ' + record.name);
console.log('State:       ' + record.delegatedMSAState + ' (' + state + ')');
console.log('Preceded by: ' + linked);
// The only two things the pre-patch KDC needs to inherit a context:
const willInherit = record.delegatedMSAState === 2 && Boolean(record.precededByLink);
console.log('KDC inherits predecessor SIDs and keys? ' + (willInherit ? 'YES' : 'no'));
}

// A legitimately completed migration record:
readSuccession({
name: 'svc-web-dmsa',
delegatedMSAState: 2,
precededByLink: 'CN=svc-web,OU=Service Accounts,DC=corp,DC=local'
});

The migration is safe because the superseded account participates. But look again at what the KDC actually reads: a state integer and a link. What happens if nobody ever checks that the predecessor participated at all?

5. BadSuccessor: The KDC Trusts the Link#

In May 2025, Yuval Gordon of Akamai asked the question the migration's designers apparently never wrote down: before the KDC duplicates a predecessor's security context onto a successor, what does it actually verify? Not that an administrator approved the migration. Not that the predecessor participated. Not even that the predecessor is aware it has a successor. The answer is nothing. The KDC reads the link and believes it.

The KDC "blindly trusts any value set in the msDS-ManagedAccountPrecededByLink attribute of the dMSA ... to duplicate the preceded account's security context on the dMSA's ... PAC." -- Jim Sykora, SpecterOps ^[2]

That is the whole vulnerability, and everything else is consequence. The legitimate migration writes a link and a state integer; so can anyone who can create a dMSA. The attacker forges a completed migration that never happened. Three writes do it, and all three land on the attacker's own new object ^[2]:

1. Set msDS-ManagedAccountPrecededByLink to the distinguished name of any chosen victim -- a Domain Admin, for instance.
2. Set msDS-DelegatedMSAState to 2, declaring the migration already complete.
3. Add a principal the attacker controls to msDS-GroupMSAMembership, which "can be any security principal(s), including a group" and is "abusable directly to a user account," so the attacker can actually request the dMSA's tickets ^[2].

// BadSuccessor forges a COMPLETED migration the KDC will trust.
// It is three attribute writes on an attacker-created dMSA -- and zero writes to the victim.
function forgeSuccession(victimDN, attackerPrincipal) {
const dmsa = { name: 'attacker-dmsa', delegatedMSAState: 0, precededByLink: null, groupMSAMembership: [] };

dmsa.precededByLink = victimDN;             // Write 1: name any victim as predecessor
dmsa.delegatedMSAState = 2;                  // Write 2: declare migration complete
dmsa.groupMSAMembership.push(attackerPrincipal); // Write 3: authorize attacker to use it

const victimTouched = false;                 // the victim object is never opened
console.log('Forged record: ' + JSON.stringify(dmsa));
console.log('Victim object modified? ' + victimTouched);
const willStamp = dmsa.delegatedMSAState === 2 && Boolean(dmsa.precededByLink);
console.log('KDC stamps victim SIDs into the PAC? ' + willStamp);
}

forgeSuccession('CN=Administrator,CN=Users,DC=corp,DC=local', 'UserA');

From a host running Windows Server 2025 or Windows 11 24H2, the attacker then simply asks for the dMSA's ticket-granting ticket. The KDC honors the link and issues it.

sequenceDiagram
participant UserA as UserA, one OU permission
participant DIR as Active Directory
participant KDC as KDC on a Server 2025 DC
participant Res as Any domain resource
UserA->>DIR: Create a dMSA in the OU UserA controls
UserA->>DIR: Write ManagedAccountPrecededByLink to a Domain Admin
UserA->>DIR: Write DelegatedMSAState to 2 and add self to GroupMSAMembership
UserA->>KDC: Request a TGT for the new dMSA
KDC->>DIR: Read the succession link, run no consent check
KDC-->>UserA: TGT whose PAC carries the Domain Admin SIDs
UserA->>Res: Authenticate as the Domain Admin
Res-->>UserA: Access granted, target object never touched

Two primitives, not one#

The research names two distinct payoffs from the same staging, and they matter separately.

Impersonation. The KDC stamps the victim's SIDs -- including Domain Admins, if that is who you named -- into the successor's PAC, and the attacker authenticates anywhere as the victim. Akamai's summary is exact: the operator can "act with the privileges of any user in Active Directory, without modifying the target object" ^[1]. No group changed, no password reset, no access-control entry on the victim ever evaluated, because the victim was never opened. The PAC's group-SID fields carry the impersonation; our KRBTGT article explains why "the KDC decides who you are" is the crux of domain trust.

Credential theft. This is the quieter, arguably worse primitive. Akamai found that the succession link "doesn't just link the dMSA to the superseded account for permission purposes, it also lets the dMSA inherit its keys," and that "the KDC includes the previous account's keys in the new dMSA's key package structure" ^[18]. Because the attacker chose the predecessor, the response hands over the victim's actual Kerberos keys.

That is not a one-shot impersonation. It is durable credential material that survives the dMSA's deletion and opens a path to full forest compromise -- the same end state as DCSync, without the replication rights our DCSync and DCShadow article requires.

The difference between the legitimate operation and the attack is a single fact: whether the predecessor was ever in the room.

flowchart TD
subgraph LEGIT["Legitimate migration"]
L1["Admin runs Start- and Complete-ADServiceAccountMigration"] --> L2["Predecessor granted read on the dMSA, refreshes its own TGT"]
L2 --> L3["Predecessor participates, consent is real in practice"]
L3 --> L4["KDC copies the context to a genuine successor"]
end
subgraph ABUSE["BadSuccessor"]
X1["Attacker creates a dMSA, writes the link plus state 2"] --> X2["Predecessor is never contacted"]
X2 --> X3["No participation, no consent, target untouched"]
X3 --> X4["KDC copies the context anyway"]
end

Exactly what it takes#

Precision here is what keeps the argument honest. BadSuccessor is gated, not universal. The environmental gate is two things together: at least one Windows Server 2025 domain controller, and a generated KDS root key in the domain -- the same root key a dMSA needs to function ^{[2] [3]}.

The permission is CreateChild for the msDS-DelegatedManagedServiceAccount class on an organizational unit or a container -- or any right that yields it: GenericAll, WriteDACL, WriteOwner, or object ownership on the parent ^{[2] [20]}. The attacker also needs a principal they control placed in the dMSA's msDS-GroupMSAMembership, and a Windows Server 2025 or Windows 11 24H2 host from which to request the dMSA's ticket ^{[21] [22]}.

The safety mechanism is the primitive. The KDC never verifies consent; it trusts msDS-ManagedAccountPrecededByLink on its face. So writing one link and one state integer on a dMSA I created makes the KDC impersonate anyone I name, up to Domain Admins, and hand me their keys -- while the target object is never opened, read, or written ^{[2] [1]}.

One ACE. No target modification. Deterministic, not probabilistic. And it yields both impersonation and durable key theft from the same three writes. The obvious next question is the one every defender asked in the summer of 2025: in the real world, how bad is this?

6. Exploitation, Tooling, and the 91%#

A primitive is only as dangerous as it is easy. What made BadSuccessor land so hard was not the mechanism alone but the measurement Akamai published alongside it: most examined environments were already stageable by ordinary users. Akamai's audit script, Get-BadSuccessorOUPermissions.ps1, reports which identities can create dMSAs and where, and its headline finding is blunt -- the technique "works in the default configuration," and "In 91% of the environments we examined, non-admin users had the required permissions" ^[1].

"In 91% of the environments we examined, non-admin users had the required permissions" to stage BadSuccessor. -- Akamai ^[1]

Why is that number so high? Because the permission is not the rare-sounding "CreateChild for the dMSA class." It collapses, through the ordinary Windows security model, to "any OU you already control at all."

flowchart LR
A["Attacker can create a dMSA in an OU"] --> B["Creator becomes the object Owner"]
B --> C["Owner has implicit WriteDACL, checked before any Deny ACE"]
C --> D["Owner grants self GenericAll on the dMSA"]
D --> E["GenericAll yields WriteProperty on the succession attributes"]
E --> F["Forge the completed migration"]

SpecterOps walks the chain: the principal that creates an object is highly likely to be set as its Owner, and an Owner holds an implicit WriteDACL that the access check evaluates before any Deny access-control entry ^[2]. So an attacker who can create a dMSA becomes its Owner, uses that implicit WriteDACL to grant themselves GenericAll, and thereby has WriteProperty on the succession attributes.

Equivalently, GenericAll, WriteDACL, WriteOwner, or ownership on the parent OU each collapse to "can create and weaponize a dMSA here." That is why an obscure-sounding right turns out to be held by non-admins in nine out of ten domains.

The following model is the logic of the audit script: given the environment and a list of OU access-control entries, who can stage the attack?

// Given the environment and OU access-control entries, can a non-admin stage BadSuccessor?
const enablingRights = ['CreateChild', 'GenericAll', 'WriteDacl', 'WriteOwner', 'Owns'];

function canStageBadSuccessor(env, ouAces) {
if (!env.hasServer2025DC || !env.hasKdsRootKey) {
  return 'Not exposed: gate not met (needs a Server 2025 DC and a KDS root key).';
}
const risky = ouAces.filter(function (ace) {
  return !ace.isPrivilegedGroup && enablingRights.includes(ace.right);
});
if (risky.length === 0) return 'No non-admin principal can create-and-weaponize a dMSA here.';
const who = risky.map(function (a) { return a.principal + ' (' + a.right + ')'; }).join(', ');
return 'EXPOSED via: ' + who;
}

const env = { hasServer2025DC: true, hasKdsRootKey: true };
const ouAces = [
{ principal: 'HelpDesk', right: 'GenericAll', isPrivilegedGroup: false },
{ principal: 'UserA', right: 'CreateChild', isPrivilegedGroup: false },
{ principal: 'Domain Admins', right: 'GenericAll', isPrivilegedGroup: true }
];
console.log(canStageBadSuccessor(env, ouAces));

On the offensive side, the tooling that emerged made the work factor a single command. SharpSuccessor, a .NET proof of concept by Logan Goins, "fully weaponiz[es]" the attack: one invocation stages the dMSA and its three attributes, after which the operator uses Rubeus ※ Rubeus is GhostPack's widely used C# toolkit for Kerberos ticket abuse. , which added a /dmsa code path, to request and pass the successor's ticket ^[21]. There is no cracking step, no race, and no waiting.

Where kerberoasting's expected work grows with password entropy -- on the order of $O(2^{b})$ for a $b$-bit key -- BadSuccessor's cost is a constant $O(1)$: one object creation and three writes, whatever the victim's privilege.

Defenders got a graph model in the same window. SpecterOps and Jim Sykora expressed "who can BadSuccessor whom" as BloodHound edges -- SupersededBy, ImpersonateSupersededAccount, and CompromiseSupersededAccountPreviousKeys -- so the exposure becomes a single query over principals that can control an OU without being Tier Zero ^[4]. Our BloodHound article explains why turning attack paths into graph edges changes what defenders can see.

This is why BadSuccessor is not filed as "just another ACL abuse." It violates the Clean Source Principle by letting a non-Tier-Zero principal control a Tier-Zero outcome ^[23]; it requires no modification of the target; and it delivers both impersonation and key theft from one primitive. Inside its 0.7%-of-domains gate and its 91%-of-those-domains prevalence, calling it the cleanest domain takeover in years is a judgment, not a measurement -- but it is a defensible one ^{[3] [1]}.

If it is this clean and this available, the fair question is how it compares to the other one-step-to-Domain-Admin primitives the reader already fears.

7. BadSuccessor Among the Escalation Primitives#

Every Active Directory attacker keeps a mental table titled "one step to Domain Admin." The value of placing BadSuccessor precisely is that it explains the feeling practitioners reported in May 2025 -- that this one felt different -- in terms of properties rather than adjectives.

Line up the usual entries. Kerberoasting recovers a service account's password, but it is offline and probabilistic: it needs a weak human-chosen password and pays off only if cracking succeeds ^[6]. AD CS ESC1 and its siblings mint an authentication certificate for any identity, but they need a misconfigured certificate template to exist first, which our Certified Pre-Owned article catalogs in full ^[24].

DCSync pulls any account's hashes, but it requires the two directory-replication rights that a principal near Domain Admin already holds ^[25]. Golden Ticket forges any ticket-granting ticket, but it presupposes you already have the krbtgt key -- that is, you have already won ^[26].

The nearest relative is not on that list by name. It is Resource-Based Constrained Delegation abuse.

The matrix isolates why BadSuccessor felt uniquely clean.

Read the columns as a single argument. Every rival needs one of three things BadSuccessor did not: a pre-existing high-value secret you must already hold (Golden Ticket, DCSync), a misconfiguration or weakness on the target or template (Kerberoasting, ESC1, RBCD), or a probabilistic crack that might fail (Kerberoasting). BadSuccessor asked for a single access-control entry on a single OU, inside the 0.7% environmental gate, and it modified nothing on the target ^{[1] [2]}. It is also the only row that yields both impersonation and durable key recovery.

BadSuccessor's rivals are all either noisy or gated by a scarce prerequisite. BadSuccessor was neither. Which forces an uncomfortable question: if a low-privileged user can become Domain Admin this cleanly, why did none of the standard detections fire?

8. Why It Was Nearly Invisible#

Surely, the objection goes, some EDR, SIEM, or Kerberos-ticket monitor flags a helpdesk account suddenly wielding Domain Admin. It does not, and the reason is a proof from first principles, not a gap someone forgot to close.

Start with the ticket, because that is where defenders instinctively look. The ticket-granting ticket the attacker receives is cryptographically genuine: signed by the KDC, carrying a valid PAC, issued for a dMSA that the directory itself says was superseded. An abusive succession and a legitimate one produce identical tickets, because they exercise the identical code path with the identical inputs. There is no field that differs, no flag that flips.

It follows that no ticket-inspection detector can classify the ticket as malicious -- not because the vendors were lazy, but because there is nothing in the ticket to classify. The logon it produces (Event 4624) and the service-ticket requests that follow (Event 4769) are, likewise, requests for a dMSA the KDC genuinely blessed ^{[28] [29]}.

Watch the write, not the ticket. The malice lives entirely in the directory change that forged the succession, never in the ticket that change produces. Any detection strategy that inspects tickets is chasing a signal that, by construction, is not there ^[2].

If the ticket is a dead end, only two other places can carry signal.

flowchart TD
S["A low-privileged user just became Domain Admin. Where is the signal?"] --> Q1
S --> Q2
S --> Q3
Q1{"Inspect the issued ticket?"} -->|Legitimate by construction| D1["Dead end: KDC-signed, valid PAC, real dMSA"]
Q2{"Inspect the directory write?"} -->|SACL present| D2["Events 5136 and 5137 can fire"]
Q2 -->|No SACL, the default| D3["No event at all"]
Q3{"Inspect behavior over time?"} -->|MDI enabled| D4["Suspicious DMSA related activity alert"]

The first is the anomalous directory write itself. With the Audit Directory Service Changes subcategory enabled, Active Directory can emit Event 5136 when an object is modified and Event 5137 when one is created -- exactly the writes to msDS-ManagedAccountPrecededByLink, msDS-GroupMSAMembership, and msDS-DelegatedMSAState, and the dMSA's creation. But the same Microsoft primary states the load-bearing caveat: "Audit events are generated only for objects with configured system access control lists (SACLs)" ^[30]. The signal exists only where someone deliberately placed an auditing SACL in advance, which is not the default, and the event volume on domain controllers is high ^[30].

The second place is behavioral analytics. Microsoft Defender for Identity added an XDR alert named "Suspicious DMSA related activity detected" (detector xdr_SuspiciousDmsaAction, severity High, mapped to MITRE T1555) that flags anomalous dMSA activity after the fact ^{[31] [32]}. Community teardown also records Event 2946 as a corroborating signal in the right configuration ^[33]. Our Microsoft Defender for Identity article covers the detections added after disclosure.

Notice the last row. The event most AD detections lean on, directory-service-access on the target object, cannot help, because the target object is never accessed ^[2]. The same design coherence that made the feature clean made the abuse quiet: a detection can flag the anomalous write, but it can never call the ticket malicious, because the ticket is legitimate.

Detection could not see it, and, as the next section shows, access-control fixes could not fully stop it either. Only Microsoft could close it at the KDC -- and for three months, Microsoft said it would not.

9. The Patch and What It Left Standing#

The remediation arc is the argument for the thesis's most important word: briefly. It is a short story with a slow beginning.

When Akamai disclosed BadSuccessor in May 2025, Microsoft's Security Response Center rated it Medium, assigned no CVE, and declined to ship a scheduled fix, saying a fix "will be worked on over time" ^[2]. For roughly three months, the cleanest domain takeover in years had an official severity of Medium and no patch on the calendar.

That changed on August 12, 2025. Microsoft assigned CVE-2025-53779, described as a "relative path traversal in Windows Kerberos" (CWE-23) with a CVSS 3.1 base score of 7.2 (High) and vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H ^[5]. The advisory confirmed that an attacker "who successfully exploited this vulnerability could gain domain administrator privileges" while rating exploitation "less likely" ^{[3] [34]}. The fix shipped for Windows Server 2025 in build 26100.4946, delivered by KB5063878 ^{[5] [35]}.

What did the patch actually change? Akamai's follow-up analysis is specific: "changes in kdcsvc.dll force the KDC to validate the relationship at ticket time," so that "a one-way link from dMSA to the target no longer works," and "succeeding now requires controlling the account's object itself -- not just the dMSA" ^[36]. ※ kdcsvc.dll is the Key Distribution Center service that runs on every domain controller; patching it changes how the KDC itself evaluates a succession. In other words, the KDC now demands a mutual succession relationship before it will inherit a context, which the attacker's forged one-way link cannot satisfy.

flowchart LR
subgraph BEFORE["Before the patch"]
A1["Attacker writes a one-way link from dMSA to victim"] --> A2["KDC honors it, inheritance granted"]
end
subgraph AFTER["After CVE-2025-53779"]
B1["Attacker writes a one-way link from dMSA to victim"] --> B2["KDC checks for a mutual link at ticket time"]
B2 --> B3["One-way link rejected, escalation blocked"]
end

Now the honest part, because the patch is narrower than the headline suggests. The enforcement went into the KDC, not into directory-side protection of the attribute -- msDS-ManagedAccountPrecededByLink is still writable. Akamai's own residual analysis notes that dMSA-based credential-acquisition and lateral-movement scenarios persist under some post-patch conditions, that the "migration still works even if the target account remains enabled," and that the fix closes the instant one-way escalation without touching the root cause ^[36].

That root cause is the 91%: over-broad CreateChild, GenericAll, WriteDACL, and WriteOwner rights on OUs, entirely unchanged by a Kerberos patch. A schema-modification caveat remains as well, since altering the schema could expose the dMSA class under other parents.

There was always a cleaner fix available, and it is worth naming because it defines what "fully closed" would mean. Consent-verified succession -- gating the inheritance behind a privilege or extended right, the way Active Directory already gates sensitive operations with SeEnableDelegationPrivilege and per-attribute add authorization -- would make the KDC demand proof of authorization rather than a bare link. The machinery exists: MS-ADTS already defines per-attribute authorization for LDAP Add operations ^{[37] [2]}. But building it is Microsoft's call, not a defender's.

The window closed. The lesson -- that a feature can ship an escalation primitive alongside it -- did not. So what should a defender or an operator actually do with all this?

10. What a Defender and an Operator Actually Do#

Strip the drama and BadSuccessor becomes a checklist. Here it is, prioritized, for the two people who have to act on it.

For the defender, the order matters as much as the items. Inventory first: run Akamai's Get-BadSuccessorOUPermissions.ps1 to learn who can create dMSAs and in which OUs, because you cannot prune what you have not measured ^[1]. Then reclassify: dMSA-creation rights -- CreateChild for the dMSA class, plus GenericAll, WriteDACL, WriteOwner, or ownership on OUs and containers -- are a Tier Zero permission, and they should be pruned to Tier Zero principals just like domain-controller logon rights, as our AD tiering article argues.

Then patch your Windows Server 2025 domain controllers to build 26100.4946 via KB5063878 to close the one-way escalation ^[35]. Finally, make the invisible visible: pre-place auditing SACLs so Events 5136 and 5137 actually fire on the succession attributes and on msDS-GroupMSAMembership, watch dMSA ticket requests (Event 4769) ^[29], and deploy the Microsoft Defender for Identity alert xdr_SuspiciousDmsaAction ^{[30] [31]}.

Where you cannot patch immediately, interim access-control mitigations exist: Jim Sykora's Add-BadSuccessorOUDenyACEs.ps1 applies three ACEs per OU -- deny Authenticated Users the CreateChild of dMSA objects, restrict OwnerRights to replace the implicit WriteDACL, and deny writes to the succession link -- and the KB5008383 dSHeuristics flags 28 and 29 harden LDAP-Add authorization and disable implicit owner rights on computer-derived classes ^{[4] [38] [37]}.

For the operator working an assumed-breach or red-team engagement, the mirror-image checklist is shorter. Confirm the environmental gate before spending any effort: at least one Windows Server 2025 domain controller and a generated KDS root key ^[21]. Discover the permission with the same audit logic a defender would run. And understand the trajectory: this is a post-2025-DC-adoption concern whose reach grows as Windows Server 2025 spreads, not a legacy technique on its way out ^[21].

Finally, the pitfalls, because most of the wrong reactions to BadSuccessor are predictable: assuming every domain is exposed (it is not -- mind the gate); assuming CreateChild is the only door (GenericAll, WriteDACL, WriteOwner, and ownership are equivalent doors); trusting a root-level Deny ACE (moot if the attacker holds WriteDACL); expecting the ticket to look malicious (it never will); auditing without SACLs (you will see nothing); and assuming the target must log in or be modified (it is a bystander throughout).

The mitigation is identity hygiene, not "turn off dMSA." The account type is a genuine improvement, and it does defeat kerberoasting; the flaw was in succession authorization, not in the account. Which leaves the sharp questions readers keep asking -- and the one sentence this whole story comes down to.

11. Frequently Asked Questions#

The Sentence It Comes Down To#

Trace the whole arc and the thesis stops being a slogan and becomes a conclusion. Service accounts were the softest target in Active Directory because their secrets were human-chosen and crackable offline, which is what kerberoasting weaponized ^[7]. Sixteen years of engineering -- sMSA, then gMSA, then dMSA -- drove the secret out of human hands, then off the member host, then onto the domain controller alone ^{[10] [13]}.

The final step, dMSA, added the one thing everyone still wanted: a one-click migration. To make that migration seamless, the KDC was taught to honor a succession link. And because the KDC honored the link without ever checking that the superseded account consented, the very feature engineered to end service-account theft handed a low-privileged user the ability to inherit any account's identity and keys -- Domain Admin included -- from a single permission on a single forgotten OU ^{[2] [18]}.

The honest qualifiers are the ones that make the claim precise rather than sensational. The exposure was conditional: a Windows Server 2025 domain controller and a KDS root key, roughly 0.7% of domains at disclosure ^[3]. The window was brief: disclosed in May 2025, closed by CVE-2025-53779 in August ^[5]. But "brief" and "conditional" do not undo the lesson. A feature can be a real security improvement and ship an escalation primitive in the same box, because the property that makes it convenient and the property that makes it dangerous can be the same property, read two ways.

The feature built to end service-account attacks briefly became the cleanest domain takeover in years. The patch closed the window. The lesson -- that a convenience feature can carry an escalation primitive inside it -- outlives the patch.

That is why dMSA-creation rights belong in Tier Zero, why "watch the write, not the ticket" is the detection rule, and why the next feature that lets one account inherit another's power deserves the question the KDC never asked: says who?