You can't roll back a secret that's already been read

Picture a document safe with some valuable intellectual property in it. A hired spy opens it, photographs the papers inside, closes it again, and walks out. The next morning the safe looks just as it did the night before: same door, same combination, nothing moved. There is nothing to put back, because in the terms a recovery tool understands, nothing was taken. The loss already left the building as a copy.

That is the uncomfortable shape of a large class of Active Directory attacks, and it is why the industry's favorite defensive story has a hole in the middle of it.

For a decade, the Active Directory security market has competed on a single axis: how fast you can undo a malicious change. Catch the bad write, alert on it, then revert to a known-good state. Tamperproof change tracking and automated rollback are the entire pitch. As a recovery story that is a good one, and recovery genuinely matters. But it concedes the point that actually counts. The change already happened, and some changes cannot be un-happened.

The Active Directory attacks that finish before you can revert them

Consider how the fastest AD attacks actually run. Ransomware crews chain flaws like noPac, the sAMAccountName spoofing pair behind CVE-2021-42278 and CVE-2021-42287, to climb from an ordinary account to domain dominance in minutes. Once an attacker holds that position, the techniques that follow are not noisy vandalism you can tidy up afterward. They are reads and impersonations that complete their work before a rollback has anything to grab.

DCSync is the clearest example and parallel to the depicted document safe story. Abusing the directory's own replication protocol by asking a domain controller for account password hashes, the perpetrator then receives them as would a fellow controller. No altered object is left sitting in the directory for a recovery tool to notice and reverse. The change, such as it is, is a copy of your credentials that has already gone. You can reset every password afterward, and you should, but at that point you are cleaning up after a theft rather than stopping one.

DCShadow works from the other direction. It registers a rogue, illegitimate domain controller and pushes attacker-chosen changes into the directory through the replication channel, bypassing the ordinary write path your monitoring watches. Here the effective control refuses the rogue replication at the instant it is attempted, so the injected change never enters the directory to be reverted in the first place.

Now take a malicious Group Policy Object edit, the kind that pushes a ransomware payload to every machine that reads the policy, or a quiet addition to a privileged group. Roll the object back and the directory state is restored. Yet the policy already distributed and the payload it carried already ran. Restoring the object does nothing about the blast radius it created.

This is where the recovery story runs out of room. For this entire category, detection and rollback arrive structurally too late, and prevention is not a faster version of the same idea — it is a different discipline. Detection confirms that something dangerous already reached the directory. Prevention stops the operation before the directory ever accepts it.

Detection vs. prevention: a GPO attack, reasoned both ways

Suppose an attacker edits a GPO linked to your servers to deploy a payload at the next policy refresh. Reason it through on the recovery model first. The malicious setting is detected and reverted, and the GPO returns to its prior state; on paper the incident is closed. In practice, every machine that pulled the policy in the window between the edit and the revert has already run the payload, and no amount of restoring the object un-runs it.

Now reason it through the other way. The write to that GPO is evaluated inline and rejected before Active Directory commits it. The policy never changes, so it never distributes, and there is no payload execution left to investigate. Same attack, two defensive models, and only one of them leaves you with nothing to clean up.

Why the word is prevention, not fast detection

That second outcome is only available to a control that sits in the write path itself. This is the mechanism behind Netwrix Threat Manager: it evaluates operations inline (changes to critical objects and GPOs, privileged group modifications, and replication requests) and blocks them at the source, before the directory commits the write. It also captures those events at their point of origin even when native logging has been disabled or cleared, so an attacker cannot blind the control by wiping the logs first. That is what earns the word prevention, rather than fast detection wearing stronger language.

None of this means prevention replaces detection. Some attacks can only be caught and answered after the fact, and pretending otherwise fails the first blunt question any competent CISO will ask. Overclaiming invites the response it deserves. The defensible posture is narrower and stronger than a slogan: prevention-first for the changes you can deterministically block, detection-and-response for everything that remains.

There is a consistent worldview underneath this. Insisting on blocking a dangerous change at the moment it is attempted is the resilience-side counterpart to insisting on knowing who holds access at the moment they use it. Both insist on acting at the instant of the action rather than in the cleanup that follows.

Which returns us to the safe that looked untouched. Rollback is a promise that you can undo the damage quickly. Prevention is a guarantee that there was no damage to undo. For the Active Directory attacks that copy a secret, impersonate a controller, or detonate before you can revert them, only one of those two is a claim the mechanism can actually keep, and it is made by the control that never let the change commit.