This attack seems predicated on the broad ACE at the domain root and the specific priv to replicate. Seems like the simplest mitigation is to add an explicit Deny ACE for that very specific priv at the domain root. Explicit DENY ACE overrides explicit (or inherited) allow … and the only downside I can see is that Exchange might be making use of that priv (which is really hard to believe).   Of course, there’s probably other bad things that can happen based on that really broad ACE at the domain root and the ability to trick Exchange into letting you run stuff under its credentials, and this wouldn’t mitigate those other bad things.   Oh wait … if Exchange can change perms at the root … it can remove my explicit deny (and if anyone can be Exchange, then anyone can remove my explicit deny). Sigh. So much for that targeted mitigation.   Brian