Windows Event ID 4725 — User Account Disabled

Why It Matters

Disabling an admin account locks out the owner without the visibility of a deletion (4726) — the account still exists in AD, it is just unusable. Attackers who have compromised one admin account may disable other admins' accounts to prevent a defensive response. Ransomware operators sometimes disable IT admin accounts in bulk before deploying the payload, ensuring helpdesk cannot intervene quickly. A domain admin account disabled by an unexpected Subject Account is one of the highest-urgency events in Windows logs — it may indicate the legitimate owner is being locked out in real time.

Key Fields

Investigation Tips

1. 1.An admin account disabled by a non-IT or unexpected account is a critical incident — the attacker is attempting to lock out defenders. Do not assume it is an offboarding error; treat it as active until verified.
2. 2.Mass disable pattern: multiple admin or service accounts disabled in rapid succession from the same Subject Account Name. This is ransomware pre-staging or an attacker clearing defensive access. Alert on 3+ account disables within 5 minutes from one actor.
3. 3.Cross-reference with HR records — legitimate offboarding generates a predictable pattern (specific account, during business hours, matching a departure date). Out-of-pattern disables — wrong timing, wrong account type, or no corresponding HR action — are suspicious.
4. 4.Disabling without a prior 4738 (account changed) may indicate abrupt removal rather than a planned offboarding process. Compare to your standard offboarding SOP, which typically involves attribute changes before disabling.
5. 5.Check for 4722 (re-enabled) events in the 24–48 hours preceding the disable — an attacker who re-enabled a dormant account and now realizes the account is being reviewed may disable it again to remove traces of activity.

Related Event IDs

Frequently Asked Questions

Is Event ID 4725 always a security concern?

No — account disabling is normal and frequent in any organization with standard offboarding. The concern threshold depends on: which account was disabled (admin accounts are highest priority), who disabled it (Subject Account Name — should be IT or HR provisioning), when it happened (off-hours disables without matching HR records are suspicious), and what happened around it (mass disables, or disables followed by ransomware activity in System logs, are critical). A single standard-user account disabled during business hours by the helpdesk account is routine; a domain admin account disabled at 3am by an unfamiliar account is an incident.

How do ransomware operators use account disabling before launching their payload?

Before deploying ransomware, sophisticated operators often disable IT admin accounts to slow the incident response. Without working admin credentials, the response team cannot stop encryption or restore backups quickly. The pattern in Windows event logs: multiple 4725 events for domain admin or helpdesk accounts in rapid succession (often within minutes of each other), from a compromised account acting as the Subject, shortly before large-scale file creation/modification events (Sysmon 11) or service stops (Event ID 7036). If you see this pattern, assume ransomware deployment is imminent or has already started.

What is the difference between disabling (Event ID 4725) and deleting (Event ID 4726) an account?

Disabling (4725) prevents logon while preserving the account object, group memberships, and all associated permissions. The account can be re-enabled (4722) at any time, restoring full access. Deleting (4726) permanently removes the account object — it cannot be restored without recreating it and reassigning all permissions. Attackers who want to do cleanup after an operation prefer deletion (4726) because it removes evidence. Attackers who want to lock out defenders prefer disabling (4725) because it is faster and less likely to trigger immediate alerts than a deletion.