Detection proposal: dMSA (BadSuccessor) abuse via predecessor link without superseded-account link

Open
#4,384 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
yaml
Domain
security

Research direction

Start with the two proposed analytics: a TTP on Security 5136/5137 that correlates msDS-ManagedAccountPrecededByLink with msDS-SupersededManagedAccountLink by DN, and an Anomaly on 5137 with ObjectClass msDS-DelegatedManagedServiceAccount. Check with maintainers first whether these fit under Active Directory Privilege Escalation, since the proposal is still open. Done means both analytics build with contentctl-ng and pass against the attached lab dataset.

Written by the indexing model from the issue text.

Description

enhancement

Detection proposal: dMSA (BadSuccessor) abuse via predecessor link without superseded-account link

Gap. security_content has no analytics for delegated Managed Service Accounts (dMSA, Windows Server 2025), so BadSuccessor (CVE-2025-53779) is not covered. Elastic alerts on any write to msDS-ManagedAccountPrecededByLink, which also fires on every legitimate migration.

Proposal. Two experimental analytics on Security 5136/5137:

  • Windows AD dMSA Predecessor Link Without Superseded Account Link (TTP): msDS-ManagedAccountPrecededByLink is written on a dMSA, but no matching msDS-SupersededManagedAccountLink is written on that predecessor. The two changes are correlated by DN, in either order.
  • Windows AD dMSA Object Creation (Anomaly): 5137 with ObjectClass msDS-DelegatedManagedServiceAccount.

Evidence. Windows Server 2025 (build 26100) lab DC. Microsoft's Start-/Complete-ADServiceAccountMigration writes both sides of the link: on the dMSA, and on the predecessor (msDS-SupersededManagedAccountLink, msDS-SupersededServiceAccountState). A direct predecessor-link write, the BadSuccessor primitive, changes only the dMSA. An attacker abusing BadSuccessor has no rights over the privileged predecessor, so they cannot add the second side. The lab data (49 events) gives 1/1 for the TTP: the direct write is detected and the legitimate migration is not. The Anomaly gives 2/2, with no hits on the gMSA or user creations. contentctl-ng build passes.

Would these fit under Active Directory Privilege Escalation? I can open the PR and publish the dataset to attack_data. Related: #4382, #4383.

Dominant language
Python
Stars
1.7k
Forks
507
Avg merge
2d 17h
Merged PRs (30d)
35

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from splunk/security_content

All issues in splunk/security_content

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.