Active Directory security covers two separate questions. Identity controls answer who can act: whether a credential is valid and what it is permitted to reach. Change enforcement answers what can change: whether a specific modification to a domain controller or protected system was authorized. A compromised privileged credential passes the first question and still has to answer the second.
Why Active Directory is the target
AD holds the authentication and authorization for most enterprise environments. Compromise it and you inherit the estate. Mandiant research cited across the industry puts AD in the path of the overwhelming majority of attacks, which is why a category of AD-specific security tooling exists at all.
The attack path is well understood. Reach a host, harvest credentials, escalate to a privileged account, modify AD to establish durable control, then move to the systems that matter. Every step after the first uses valid authentication.
The two questions
Who can act. This is the identity layer, and a mature set of tooling addresses it. Configuration assessment finds the misconfigurations that make privilege escalation easy. Identity threat detection recognizes when an account behaves like an attacker rather than a user. Access controls decide whether a login proceeds. Change auditing records what was modified in the directory. Recovery restores the forest when something goes wrong.
What can change. This question is asked less often. Once a credential is valid and the session is authenticated, something still has to determine whether a specific modification to a domain controller is authorized. Writing a binary to a DC, registering a service, altering a scheduled task, modifying configuration. Those are changes to a host, and they either fall inside what that host is authorized to run or they do not.
The gap matters because a compromised administrator credential is not an anomaly to the identity layer. It is a correctly authenticated privileged session. The identity controls worked. The attacker holds a valid credential, which is the entire point of stealing one.
Where Mimic fits
Mimic profiles each protected system, including domain controllers, in its authorized operational state and evaluates every attempted change against that baseline at the kernel before it executes. Enforcement is identity-agnostic, which means a valid privileged credential confers no additional authorization. Change Control produces a record of every attempted change to protected infrastructure, allowed and blocked.
Mimic does not assess AD configuration, does not detect identity threats through behavioral analytics, and does not perform AD recovery. Those are different problems solved by different products, several of them well. Mimic answers one question and it is the one that stays unanswered after identity has done its job.
What this hub links to
- What does this look like in a real environment? The REI case study: how REI defended its Active Directory. Mike Hughes, CISO, on protecting REI’s AD estate.
- How do attackers actually move through AD? How Active Directory attacks work.
- What should we be doing regardless of vendor? The Active Directory protection checklist.
- How does this fit with Semperis, Netwrix and Vectra? See the layers of AD security: how identity protection, AD auditing and change enforcement fit together.
- How does the enforcement work underneath? The known-good enforcement canonical page.
- What about ransomware specifically? Ransomware defense.
Active Directory security, answered.
What is the difference between identity security and change enforcement?
+Identity security determines who can act: whether a credential is valid, what it may reach, and whether the account is behaving abnormally. Change enforcement determines what can change: whether a specific modification to a protected system was authorized. A compromised privileged credential satisfies the identity question and still has to answer the change question.
Can a compromised admin account be stopped without detecting it?
+Yes, in the sense that matters. Establishing durable control through a compromised account requires modifying systems: writing binaries, creating services, altering configuration. Those modifications either fall inside the system’s authorized operating state or they do not, and that determination does not require recognizing that the account was compromised.
Is Mimic an ITDR product?
+No. Identity threat detection and response identifies attacks against identity infrastructure through behavioral analytics and posture assessment. Mimic does neither. It enforces at the kernel, evaluating whether a change to a protected system was authorized. It runs alongside ITDR tooling rather than in place of it.
Does Mimic replace Semperis or Netwrix?
+No. Semperis provides AD-specific threat monitoring, change rollback and forest recovery. Netwrix provides configuration assessment, change auditing and compliance reporting. Mimic does none of those. It enforces change at the host kernel, which is a different layer, and organizations serious about AD security generally need more than one of these.
How does Mimic protect domain controllers?
+By profiling each domain controller in its authorized operational state and evaluating every attempted change against that baseline at the kernel before it executes. Changes inside the baseline proceed. Changes outside it do not run, regardless of which credential requested them or whether the requesting session was correctly authenticated.
What does identity-agnostic enforcement mean?
+The enforcement decision does not consider who requested the change. It compares the change to the authorized baseline for that system. A domain administrator making a modification outside the baseline gets the same answer as an unauthenticated process, because the question is about the change rather than the actor.
Does Active Directory security require blocking legitimate admin work?
+No, and a control that did would not survive deployment. The baseline is built by profiling how each system actually runs in its approved state, so normal administration falls inside it. What gets blocked is change outside that profile, which is a much narrower set than "administrative activity."
