Event ID 4725: A user account was disabled

Event 4725 records that an account was disabled, a state change that blocks the account from logging on anywhere in the domain while leaving the account object itself, its SID, its group memberships, and its attribute history, fully intact. That reversibility is the defining difference from deletion, 4726: a disabled account can be re-enabled in seconds by anyone with the right permission, which is exactly why disabling is the tool of choice for both routine offboarding and, less benignly, for deliberately locking someone out without the finality of removing them.

SubjectUserSid, SubjectUserName, and SubjectLogonId identify who performed the disable, correlating back to that Subject's own 4624 logon. TargetUserName, TargetSid, and TargetDomainName identify the account that was disabled. In the routine case this is IT or HR-driven: an employee's last day, a contractor's engagement ending, a compromised account being disabled defensively while an investigation runs. None of those cases need Subject and Target to be anything other than a known admin account and a known departing user.

The pattern that separates routine offboarding from something worth escalating is the Target's role, not the act of disabling itself. A standard user account disabled during business hours by a known HR-integrated provisioning tool or a known IT admin is the overwhelming majority case and rarely needs review beyond a periodic audit. A security-relevant service account, a backup agent's authentication identity, a monitoring tool's credential, or an EDR or SIEM forwarder's account disabled at any time is categorically different, because disabling those specific accounts does not remove a user's access, it removes a defense.

MITRE catalogs this second pattern under T1531, Account Access Removal, an impact-stage technique distinct from privilege escalation: the goal is not gaining more access, it is denying recovery capability to the defenders who would otherwise detect, respond to, or roll back an attack already underway. Disabling a backup service's account ahead of a destructive action removes the ability to restore from backup after the fact. Disabling a monitoring or SIEM-forwarding account blinds the very telemetry pipeline that would have caught the disable event itself, which is why this specific event, ironically, sometimes represents the last clean signal before visibility degrades.

A second pattern worth its own detection logic is volume: a wave of account disables hitting many distinct Target accounts inside a short window. Legitimate mass-disable events do happen, a scripted contractor-offboarding batch, a compliance-driven account cleanup, but they are traceable to a known automation identity and typically fall inside a documented change window. An unannounced, high-volume disable wave is a recognized precursor and companion action to ransomware deployment, used to lock users and responders out of the environment while the primary attack proceeds.

The baseline for 4725 in most organizations is narrow, similar in shape to 4724's reset pattern: a small, known set of HR-integrated provisioning tools and IT-admin accounts disabling standard user accounts during business hours, each one traceable to an offboarding ticket or an HR system event. That narrowness makes deviations comparatively easy to spot without heavy tuning.

Target role is the single highest-leverage triage axis for this event. Maintain an explicit, actively curated list of security-relevant service accounts, backup agents, EDR and SIEM forwarders, monitoring credentials, and any account whose disablement would blind or cripple your ability to detect or recover from an incident. Any 4725 against an account on that list, from any Subject, at any time, deserves an immediate page rather than a queued review, because the cost of a false alarm here is trivial compared to the cost of a missed one.

Subject identity remains the secondary check for standard-user disables: a disable performed by an account outside your known HR-provisioning or help-desk population is worth investigating even against a low-sensitivity Target, since it means someone or something outside the normal offboarding path is exercising this permission, and that alone is worth understanding regardless of whether the specific disable turns out to be legitimate.

Volume is the third axis and the one most directly tied to the impact-stage risk this event carries. A disable wave, many distinct Target accounts disabled within an hour, should trigger an alert regardless of which accounts are affected, because the pattern itself, independent of any single account's sensitivity, is the recognized precursor to environment-wide impact. Set the threshold low relative to your organization's normal offboarding cadence; a genuine HR-driven batch process is easy to allowlist by Subject account once identified, and everything outside that allowlist reaching the same volume threshold deserves scrutiny.

False positives concentrate almost entirely around under-documented automation: HR-system integrations, identity-governance platforms, and contractor-lifecycle tools that disable accounts as part of routine, policy-driven processes but were never explicitly added to the known-good Subject list. The fix, as with several of this event's siblings, is documenting and allowlisting those automation identities explicitly, since an undocumented account with disable rights is an audit gap that deserves closing on its own merits, independent of whether any specific disable it performs turns out to be malicious.