How could an adversary deliberately trip your automated account-disable rule to lock your own responders out?

### The trick Automated response closes a loop: a rule produces a verdict, and the platform acts on it. The adversary's move is to feed the front of that loop so the back of it does his work. If a rule disables any account associated with a credential-dumping artefact on disk, he does not need to compromise the break-glass account - he only needs to make it *look* associated. Drop the matching file in a path attributed to that account, write the account name into a log field the detection reads, or run the tooling once in a context that names it. Within seconds, the accounts you would use to recover are disabled, and the platform's own log shows it acting confidently and correctly by its own lights. The action log excerpt above is the shape of it: one rule, one confidence value, three accounts that recovery depends on, three seconds apart, no human named anywhere in the record. ### Why this is not a tuning problem Raising the confidence threshold does not help, because the adversary is not producing a marginal detection - he is producing a textbook one. Nor does adding more rules, because each new automated destructive action is another actuator. The generalisable statement, and the thing a strong candidate says out loud, is: > **Any adversary-writable input that drives an automated destructive action is a control surface you have handed to the adversary.** Attacker-writable inputs are more common than people expect: filenames and paths, a username string in an application log, a user-agent or hostname field, a submitted file's hash, an email header, a tag on a cloud resource. Compare those with telemetry that is expensive to forge *on somebody else's behalf*: process ancestry and command line captured on a host the adversary would have to already control, an authentication event from the identity provider itself, a control-plane record written by the provider rather than by the workload. ### The defences - **A never-act list for recovery principals.** Break-glass accounts, the backup service account, the response platform's own service principals, and the responders' administrative accounts. These may be alerted on loudly - and should be - but never disabled by automation. This is the identity twin of the critical-host exemption. - **Corroboration before a destructive action.** Require the verdict to rest on at least one source the adversary cannot write, or on two independent surfaces agreeing. A single attacker-controllable field should never be sufficient on its own to disable a privileged principal. - **A mass-action circuit breaker.** Cap actions per unit time and per privilege class. Beyond the cap, the platform stops and pages instead of continuing. This is the single control that turns a machine-speed catastrophe into a human decision, and it also catches an unannounced test that isolates forty hosts in ninety seconds. - **An out-of-band recovery path.** If the automation disables accounts in the identity provider, recovery cannot depend solely on that same identity provider. Keep a documented path - a local administrator credential in a vault with a separate trust root, a provider-side support route - and rehearse it. - **Treat the automation's own output as telemetry.** Every automated action against a privileged principal should raise an alert of its own, and a burst of them should be handled as a candidate incident rather than as a productive night. ### Telling a deliberate trip from a real mass compromise They look identical from inside the rule, which is the point. What separates them is evidence the rule did not use: who or what actually wrote the artefact, whether the accounts share anything besides matching that rule, whether the affected principals were even in use at the time, and whether the same behaviour appears on the hosts those accounts touch. This is why the circuit breaker's job is not to decide, but to stop and hand the decision to a person who can go and look. ### One more direction error to avoid Disabling the account is not eviction. An already-issued Kerberos ticket-granting ticket remains valid until it expires - ten hours by default - and existing OAuth refresh tokens and live session cookies survive a disable or a password reset unless sessions are explicitly revoked. So an adversary who trips your rule may get the full outage cost without you getting the containment benefit: the defenders are locked out, and he is not.