How to track rogue domain controllers

Why rogue DCs are uniquely dangerous

Domain controllers are not “just servers.” A DC is the security authority for authentication, Kerberos ticketing, LDAP directory reads/writes, and (critically) replication. If a rogue DC participates in those flows, it can become a stealthy pivot for credential theft, policy manipulation, or persistence.

If the underlying fundamentals of what a DC does need a quick refresher, start here: What are Domain Controllers?

Define “legitimate DC” with an inventory that can prove itself

Most environments “track DCs” by memory, a spreadsheet, or a stale CMDB. That’s not tracking—it's hoping. The goal is to maintain a DC inventory that is:

• Authoritative (derived from AD + DNS + network, not just human docs)
• Complete (includes hostnames, IPs, sites, OS versions, GC status, and owners)
• Auditable (changes are logged and reviewed like code)

Baseline checklist (minimum viable “DC truth”)

• List all domain controllers from AD and record: hostname, site, IPv4/IPv6, GC flag, and whenCreated
• Confirm each DC has expected DNS A/AAAA records and SRV records
• Confirm each DC appears in replication topology with expected partners
• Confirm each DC has expected FSMO role assignments (or explicitly “none”)

Rogue DC tracking becomes dramatically easier when the team understands replication mechanics and role placement. For background reading: Active Directory Replication: What it is and how it works and Active Directory FSMO Roles Explained.

High-signal indicators of a rogue (or newly introduced) DC

A “new DC” leaves fingerprints in multiple layers. The most reliable strategy is to monitor multiple independent signals and alert when they disagree.

1) Identity-layer signals (AD objects that should not change often)

• Computer account marked as a DC: the computer object’s flags indicate “server trust account” (DC capability).
• Placement in the Domain Controllers OU: unexpected new objects appearing there is suspicious by default.
• New NTDS Settings object under Active Directory Sites and Services (the directory’s own “this is a DC” identity).
• Unexpected group changes involving DC-related groups (rare in steady-state operations).

2) DNS-layer signals (clients trust DNS to find DCs)

• New or modified SRV records under _msdcs (DC locator)
• New A/AAAA records mapping a “DC-like” hostname to an unexpected IP range
• New GUID-alias (CNAME) records under _msdcs that don’t match the approved inventory

3) Replication-layer signals (the “hard proof” layer)

• Replication partners suddenly include an unknown server
• Connection objects appear that the team did not approve (KCC changes can happen, but unknown endpoints shouldn’t)
• Replication errors spike after a “new server” appears (often seen with mis-promotions or clones)

4) Network-layer signals (behavior that looks like a DC)

• Unexpected host receiving inbound auth traffic on typical DC ports (Kerberos/LDAP/LDAPS/SMB/RPC)
• New “KDC-like” behavior (Kerberos responses) from a host not on the DC inventory
• Clients switching their “logon server” to an unfamiliar system

Practical hunting: find “DC-like” systems with PowerShell

These checks are designed to be safe and defensive. Run from a management workstation with RSAT.

A) List approved DCs (the canonical list)

# Requires ActiveDirectory module


Get-ADDomainController -Filter * |
Select-Object HostName, IPv4Address, Site, IsGlobalCatalog, OperatingSystem, OperatingSystemVersion |
Sort-Object Site, HostName

B) Find “computer accounts that look like DCs”

Domain controllers have a server trust account flag. This query finds computers where that bit is set.

# SERVER_TRUST_ACCOUNT = 0x2000 = 8192


Get-ADComputer -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=8192)" -Properties whenCreated, DistinguishedName |
Select-Object Name, whenCreated, DistinguishedName |
Sort-Object whenCreated

C) Compare DC inventory vs. DNS records

A quick sanity test: do all known DC hostnames resolve to expected IPs, and do any unknown “DC-ish” names exist in DNS? (Implementation varies depending on whether DNS is AD-integrated and which zones you use.)

# Example pattern-based search (customize the filter to your naming conventions)


Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.yourforestroot.tld" -Type SRV

Tip: treat DNS as “client truth.” If DNS advertises a DC, clients will try it—whether it’s legitimate or not.

Audit configuration that makes rogue DC detection easier

Rogue DC investigations often fail because there isn’t enough telemetry to prove what changed, who changed it, and when. At a minimum, ensure domain controllers are configured to produce:

• Security auditing for computer account creation/changes and sensitive group membership changes
• Directory Service Changes auditing (to see creation/modification of critical AD objects)
• DNS auditing/logging appropriate for your environment (especially _msdcs changes)
• Replication/Directory Service logs centrally collected

The core principle: if promotion of a DC is a rare, high-impact operation, its signals should be treated like a privileged pipeline event—logged, alerted, and reviewed.

Confirming a rogue DC: a fast “prove or dismiss” workflow

1. Is it in the authoritative DC list? If AD lists it as a DC, it’s already in the blast radius.
2. Does it appear in Sites and Services with NTDS Settings? If yes, it’s a DC identity in directory metadata.
3. Does DNS advertise it as a DC? If clients can discover it via SRV records, it can intercept auth flows.
4. Is it in replication topology? Unknown replication partners are a top-tier red flag.
5. Does the host behave like a DC on the network? Kerberos/LDAP traffic patterns can confirm role-like behavior even when naming is deceptive.

Containment and response playbook (do this before “cleanup”)

If the DC is suspected malicious, treat it as an active compromise until proven otherwise. The safest flow is:

1) Contain (stop it from influencing the domain)

• Isolate the host at the network layer (quarantine VLAN / firewall rules) to stop auth and replication traffic.
• Block replication endpoints specifically if full isolation isn’t immediately possible.
• Preserve evidence (memory/disk imaging if your IR process supports it).

2) Stabilize (protect the rest of the forest)

• Check for unexpected changes to privileged groups, GPOs, and DC-related DNS records.
• Review replication health on known-good DCs (errors and topology changes can reveal scope).
• Validate time sync and Kerberos health (rogue DCs can create confusing auth symptoms).

3) Remove safely (metadata + DNS + replication convergence)

Once containment and investigation gates are satisfied, removal must be done cleanly—because stale metadata can keep the “ghost” alive. Use a proven metadata cleanup process to remove DC traces from AD and DNS and verify convergence: Managing AD metadata cleanup post-DC decommission: A Playbook.

Special note: branch office risk and RODCs

Remote sites are where rogue DC stories often start: weak physical security, rushed troubleshooting, or “temporary” fixes that become permanent. If the environment needs authentication in a low-trust site, a Read-Only Domain Controller (RODC) can reduce the blast radius—especially around credential caching. For fundamentals: What is a Read Only Domain Controller (RODC).

Operationalizing rogue DC tracking (make it boring)

The best outcome is when a rogue DC is detected like a smoke alarm—fast, consistent, and routine. Convert this into a lightweight operating model:

• Daily: alert on any new “DC-like” computer account flags, new NTDS Settings objects, and new DC locator DNS records.
• Weekly: reconcile DC inventory against AD, DNS, and replication topology; review drift as a change-control item.
• Monthly: run a tabletop scenario: “unknown DC appears in DNS” and test the containment-to-cleanup workflow.
• Always: treat DC promotion as a privileged change with ticketing, approvals, and post-change verification.