You declared an intrusion at 02:00 on a burst of admin password-reset events that proved to be an approved bulk-reset script — what should the bar have required first?

## What the events said and did not say Windows Security event **4724** is logged when an attempt is made to reset an account's password — an administrative reset performed against another account, distinct from **4723**, which is the attempt to change a password by the account holder. A burst of 4724s across many accounts in a few minutes is exactly what a compromised administrative identity looks like as it takes control of the estate. It is also exactly what an approved bulk-reset script looks like. The record contains the subject account performing the reset and the target account; it does not contain, and cannot contain, whether anybody authorised it. ## The classification that matters This is not a false positive. The rule fired on activity that genuinely occurred and genuinely matched what it was written to find. It is a **benign true positive**: real, correctly detected, and authorised. The distinction is not pedantry, because the two have opposite remedies. A false positive means the logic is wrong and you tune the rule. A benign true positive means the logic is right and the missing thing is *context* — a way for the analyst to learn, quickly, that this instance was sanctioned. Tuning the rule away would blind you to the compromise case, which is the very scenario the rule exists for. ## The bar that should have been applied The general form of a declaration bar is an artefact that no legitimate process explains. The failure at 02:00 was skipping the second half of that sentence. For any artefact that privileged administration can also produce — mass credential changes, mass mailbox permission grants, a sudden export from an admin console, a firewall rule opened at midnight — the bar needs an explicit authorisation check before the word is said: 1. **The change record.** Is there an approved change or maintenance window covering this activity, this system, tonight? Search by system and by time, not by keyword — a bulk reset may be filed as an identity hygiene task, not as anything containing the word password. 2. **The source.** Which account issued it, from which host? A scheduled job running as its usual service account from its usual jump host is a very different picture from the same resets issued from a workstation at an unusual hour. 3. **The human.** One phone call to the named owner of that system, or to the platform on-call. Not an email, not a chat message into a channel nobody watches at 02:00. 4. **The time-box.** Fifteen minutes, or whatever your team can defend. If the check resolves it, close as a benign true positive with the evidence attached. If it does not resolve inside the box, declare. The asymmetry has not changed: a retracted declaration is embarrassing and recoverable, and a four-hour delay while you try to reach someone is not. Notice that the check must be genuinely capable of failing. A duty officer who calls, gets no answer, and therefore assumes it is fine has replaced a bar with a coin flip. ## Retracting properly A declaration that turns out to be benign is withdrawn, not allowed to evaporate. Send the retraction to exactly the distribution that received the declaration, in writing, stating the evidence that resolved it and who confirmed it. Tell counsel and the insurer that the notified circumstance is withdrawn, and record that you did — a circumstance left open on a policy has a way of resurfacing at renewal. Keep the artefacts you preserved; they cost nothing to hold and they are the proof that the resets were what you were told they were. Finally, log it as a retraction and not as a closed incident, because the count of retracted declarations is one of the few honest measures of whether the bar is calibrated. ## What actually changes afterwards The cheap reaction is to tune the detection, and it is usually wrong. The better fixes attach context to the artefact so the next duty officer resolves it in ninety seconds: require bulk administrative jobs to run from an identified service account so the source alone is informative, require a maintenance window entry that the SOC can query, or have the platform team drop a heads-up into the SOC's own channel before running one. If none of that is achievable, the change is to the bar itself and to the runbook that carries it — and to a fallback contact list that actually answers at 02:00. ## The other direction Be careful about the lesson a team draws from an embarrassing retraction. The natural over-correction is to raise the bar until nobody dares use the word, which is how organisations end up with three-day investigations that were intrusions from the first hour. State plainly in an interview that you would keep the bar where it is and add the authorisation check, rather than trading a retraction risk for a dwell-time risk.