Non-DC-shaped account exercises AD replication topology rights

Siemphony@siemphonymediumT1207unverified

AN0770 is a four-stage chain — nTDSDSA/server object creation, DRS-SPN usage, replication RPCs (DrsAddEntry, DrsReplicaAdd, GetNCChanges) from a non-DC host, and Kerberos auth against those SPNs — and this rule reaches two of the four stages with the three Security event IDs the brief actually supplies. The first arm matches 4928 and 4929 (a replication naming-context link was established or removed) on EventID alone: this corpus already has a rule for T1003.006/DCSync built on 4662 with the Get-Changes/Get-Changes-All extended rights, and its description explains why 4929 was left unused there — it is topology administration, not a secret pull. That is exactly the signal DCShadow needs instead: registering a rogue DC means creating a *new* replication partner, which is what 4928/4929 record. No field beyond EventID is used on this arm, because the Microsoft-documented schema for these two events (Naming Context, Source DRA, Destination DRA) was not confidently verifiable while authoring this rule, and AUTHORING.md is explicit that an unverified field name should not be guessed into a selector — so this arm cannot be narrowed to a specific naming context or partner, and fires on every legitimate topology change too. The second arm reuses T1003.006's 4662/AccessMask/Properties shape but with a different, deliberately non-overlapping GUID pair: DS-Replication-Manage-Topology (1131f6ac-9c07-11d1-f79f-00c04fc2dcd2) and DS-Replication-Synchronize (1131f6ab-9c07-11d1-f79f-00c04fc2dcd2), the rights that let a principal add itself as a replication partner and push a sync (DrsAddEntry/DrsReplicaAdd), rather than the Get-Changes pair that only pulls (DCSync). A principal or tool holding Get-Changes without Manage-Topology cannot register a rogue DC, which is why this arm does not fire on the Entra Connect/DSInternals false positives T1003.006 documents. This arm carries T1003.006's machine-account filter too (SubjectUserName not ending in '$'): unlike Get-Changes, which only Entra Connect and similar tools exercise under a user account, Synchronize is the right every real DC checks on essentially every routine replication pull from every partner, so leaving it unfiltered would make ordinary intra-site replication traffic — not any of the four false positives below — the rule's dominant, unlisted source of matches, firing under every DC's own machine account on every replication cycle. That filter is also the rule's blind spot, same as T1003.006's: a rogue DC registered under a stolen or spoofed computer account, or DCShadow launched from a machine context rather than a compromised admin user, is filtered out by design and this arm goes silent for it. The SuspiciousSPNs knob (the DRS SPN E3514235-4B06-11D1-AB04-00C04FC2DCD2) and the object-creation and Kerberos stages have no logsource in the brief that carries them — 5136/5137 (object creation) and 4769 (Kerberos service ticket) are absent from AN0770's logSources — and MITRE's TimeWindow (300s) correlation between object creation and replication traffic is a cross-event join lib/sigma cannot express, so a match here is one topology or rights event, not a confirmed DCShadow chain. Prerequisite: 4928/4929 need the *Directory Service Replication* audit subcategory; 4662 needs *Audit Directory Service Access* for Success plus an audit ACE on the domain naming context covering the two replication extended rights, matching T1003.006's prerequisite note — DS Access auditing is in the domain-controller baseline, but the SACL is worth confirming before trusting a quiet result. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0276 (AN0770), not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

SecurityEvent| where ((EventID == 4928 or EventID == 4929) or ((EventID == 4662 and AccessMask =~ "0x100" and (Properties contains "1131f6ac-9c07-11d1-f79f-00c04fc2dcd2" or Properties contains "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2")) and not (SubjectUserName endswith "$")))

Splunk · SPL

Run this as a search.

index=* ((EventID="4928" OR EventID="4929") OR ((EventID="4662" AND AccessMask="0x100" AND (Properties="*1131f6ac-9c07-11d1-f79f-00c04fc2dcd2*" OR Properties="*1131f6ab-9c07-11d1-f79f-00c04fc2dcd2*")) AND NOT (SubjectUserName="*$")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((event.code == 4928 OR event.code == 4929) OR ((event.code == 4662 AND TO_LOWER(AccessMask) == "0x100" AND (TO_LOWER(Properties) LIKE "*1131f6ac-9c07-11d1-f79f-00c04fc2dcd2*" OR TO_LOWER(Properties) LIKE "*1131f6ab-9c07-11d1-f79f-00c04fc2dcd2*")) AND NOT (TO_LOWER(user.name) LIKE "*$")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)(^4928$|^4929$)</field>    <description>Non-DC-shaped account exercises AD replication topology rights (1/2)</description>    <mitre>      <id>T1207</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4662$</field>    <field name="AccessMask" type="pcre2">(?i)^0x100$</field>    <field name="Properties" type="pcre2">(?i)(1131f6ac-9c07-11d1-f79f-00c04fc2dcd2|1131f6ab-9c07-11d1-f79f-00c04fc2dcd2)</field>    <field name="SubjectUserName" negate="yes" type="pcre2">(?i)\$$</field>    <description>Non-DC-shaped account exercises AD replication topology rights (2/2)</description>    <mitre>      <id>T1207</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: directory_object_tampering
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 59c0e624-79e6-4fab-b327-5f62de9ca43f

ATT&CKT1207

T1207Rogue Domain Controller

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessondirectory object tampering

directory object tamperingAI draft — unreviewed

01 · What this rule detects

This rule looks for the two pieces of a rogue-DC (DCShadow) registration that Windows Security logging actually surfaces: a new replication partner appearing in AD's topology, and a non-DC account exercising the rights needed to register and push that replication. MITRE's AN0770 describes a four-stage chain — object creation in the Configuration partition, DRS-SPN usage, replication RPCs from a non-DC host, and Kerberos auth against those SPNs — but the brief only supplies event IDs for stages one and part of three, so this rule reaches two of the four stages, not the whole chain. A match is one topology or rights event, not a confirmed DCShadow run.

02 · Telemetry you need

Windows Security events 4928, 4929 and 4662, windows/security logsource. 4928/4929 need the Directory Service Replication audit subcategory. 4662 needs Audit Directory Service Access success auditing plus an audit ACE on the domain naming context that actually covers the two replication extended rights used below — DS Access auditing is in the domain-controller baseline, but the SACL coverage is worth confirming directly rather than trusting a quiet result, since a missing ACE and "nothing happened" look identical.

03 · How the logic works

Two arms, OR'ed. selection_topology_change matches 4928/4929 on EventID alone — this corpus's T1003.006/DCSync rule already explains why 4929 was left out of that rule (it's topology administration, not a secret pull), which is exactly the signal DCShadow needs instead: registering a rogue DC means creating a new replication partner, and 4928/4929 record that. No field beyond EventID is used because the documented schema for these two events (Naming Context, Source DRA, Destination DRA) could not be confidently verified while authoring, and guessing a field name is against the authoring rules — so this arm cannot be narrowed to a specific partner and fires on every legitimate topology change too. selection_replication_management reuses T1003.006's 4662/AccessMask/Properties shape but with a different GUID pair: DS-Replication-Manage-Topology and DS-Replication-Synchronize, the rights that let a principal register itself as a partner and push a sync, rather than the Get-Changes pair that only pulls (DCSync). filter_machine_account excludes SubjectUserName ending in $. This filter matters more here than in the DCSync rule: Synchronize is a right every real DC checks on essentially every routine intra-site replication pull, so leaving it unfiltered would make ordinary DC-to-DC traffic — not any of the false positives below — the rule's dominant, undisclosed source of matches. The condition is selection_topology_change or (selection_replication_management and not filter_machine_account).

04 · Common false positives

The topology arm's highest-volume source by a wide margin is legitimate DC promotion or demotion (dcpromo, Install-/Uninstall-ADDSDomainController), which is exactly why it isn't scored high on its own. The Knowledge Consistency Checker recalculates topology on its own schedule — roughly every 15 minutes intra-site — and can add or remove naming-context links with no administrator involved. On the rights arm, AD migration tooling (Quest Migration Manager, ADMT) and AD-aware backup/restore agents both request Manage-Topology and Synchronize under non-machine service accounts, so they survive the $ filter and fire in sustained bursts during cutovers or restores.

05 · Detection maturity

tier_1: Lowest tier. Authored from MITRE's prose and the corpus's own T1003.006 precedent, never executed against a log. The machine-account filter is itself a blind spot borrowed from that sibling rule: a rogue DC registered under a stolen or spoofed computer account goes undetected by design until validated against real traffic.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

MITRE's AllowedReplicationPartners knob is not implemented — this rule has no way to check a source host against a known-DC list, so every legitimate dcpromo and KCC cycle will match the topology arm. Populate an allowlist downstream and filter on it. SuspiciousSPNs and MITRE's 300-second TimeWindow correlating object creation to replication traffic both require a cross-event join lib/sigma cannot express; nothing here confirms the four-stage chain, only that one of its two visible stages fired.

Declared by the author

Legitimate domain controller promotion or demotion (dcpromo / Install-ADDSDomainController / Uninstall-ADDSDomainController), which establishes or removes a naming-context replication link for the schema, configuration, domain and any application partitions as a normal, expected part of standing up or retiring a real DC — this is the highest-volume source for the topology-change arm and the reason it is not scored high on its own.
The Knowledge Consistency Checker (KCC) recalculating replication topology on its own schedule (roughly every 15 minutes intra-site, longer inter-site) in response to a site, subnet or bridgehead-server change, which can establish or remove naming-context links with no administrator action at all.
AD migration and forest-restructuring tooling (Quest Migration Manager, ADMT with SID-history migration, and similar products) that is temporarily granted Manage-Topology and Synchronize rights on a non-machine service account for the duration of a cutover, exercising the replication-management arm in sustained bursts and surviving the machine-account filter.
AD-aware backup and disaster-recovery agents (system-state backup/restore tooling) that request elevated directory-service rights, including replication management, under a non-machine service account to perform an authoritative or non-authoritative restore of the directory.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1207, evaluated against their — events.

Share this rule

/u/siemphony/59c0e624-79e6-4fab-b327-5f62de9ca43f

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Non-DC-shaped account exercises AD replication topology rights

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it