---
{
  "title": "Rogue Domain Controller",
  "summary": "A rogue domain controller introduces unauthorized directory replication or control relationships.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1207"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1207: Rogue Domain Controller",
      "url": "https://attack.mitre.org/techniques/T1207"
    }
  ],
  "editorialVersion": 2
}
---

## Directory replication is a sensitive trust relationship

A rogue domain controller introduces unauthorized behavior into a directory's replication or control relationships. In an Active Directory context, an actor may register or imitate a controller to manipulate directory data. This is not simply any unfamiliar computer joining the network; the relevant evidence concerns directory roles and replication behavior.

The technique depends on significant authority or access conditions. Avoid presenting it as something an ordinary user can perform without prerequisites. Investigators should establish the account privileges, directory changes, participating systems, and resulting data modifications.

## An unexpected replication participant

In a fictional organization, directory monitoring identifies a replication-related change involving a system not present in the approved controller inventory. The analyst works with directory administrators to review object changes, identity activity, topology, replication records, and the system's actual role.

A legitimate controller deployment, recovery, or decommissioning task could explain the discrepancy. Compare the change with the approved plan and exact object identifiers. An outdated inventory alone is not proof of a rogue controller.

The team checks whether the suspicious system merely had a registration or actually participated in relevant operations. Directory data changes and their provenance may provide stronger evidence than a name appearing in one administrative view.

## Protect the directory evidence

Directory relationships and identifiers can be complex, and display names may change or repeat. Preserve the relevant objects, timestamps, account context, and source records through an approved process. Avoid making broad directory changes before specialists understand the dependencies, unless immediate harm requires action.

[[account-manipulation]] and [[domain-or-tenant-policy-modification]] describe related identity changes. [[least-privilege]] guides review of sensitive directory authority, while [[logs-and-telemetry]] explains why collection coverage limits reconstruction.

Assess other changes made under the same authority. A single unauthorized replication relationship may be one part of a broader identity compromise, but scope conclusions should follow evidence rather than assuming every directory object was altered.

## Restore the intended trust state

Contain the abused identity or system as justified and coordinate removal of unauthorized relationships with directory owners. Review credentials, permissions, and data changes that may survive the first cleanup action. Verify normal directory operation after remediation.

For practice, compare an approved controller deployment with a fictional unexplained replication participant. Identify authorization, object, identity, topology, and operation evidence needed to distinguish them. Explain what can be concluded from registration alone and what requires evidence of actual activity. [[incident-response]] coordinates specialist decisions, while [[incident-reporting]] should keep the technical trust change and confirmed downstream effects separate.

## Related concepts

- [[mitre-attack]]
- [[access-token-manipulation]]