0xC0000072: Logon Failed Because the Account Is Disabled

What it means

0xC0000072 is the NTSTATUS value STATUS_ACCOUNT_DISABLED: “The referenced account is currently disabled and cannot be logged on to.” In Microsoft’s 4625 documentation the code carries the note “User logon to account disabled by administrator.” Windows recognised the account name and refused the logon because the account’s disabled flag is set.

In event 4625 the code usually appears as the Sub Status, under the general account-restriction Status 0xC000006E; on domain controllers it can also appear as the Error Code of an NTLM credential validation (event 4776). The Kerberos form of the same refusal is 0x12 KDC_ERR_CLIENT_REVOKED, and in Entra ID sign-in logs the cloud equivalent is AADSTS50057 (UserDisabled).

Because the account exists, the code is useful in a way “unknown user” failures such as 0xC0000064 are not: it points at a specific identity that someone, or something, still expects to work.

Is it an attack?

Pattern	Reading
Same account, same source host, failures at a regular interval	A service, scheduled task or mapped drive still configured with the account
Logon type 5 (service) or 4 (batch)	Almost certainly a stale service or task — find it on the source host
Account of someone who just left, from their old laptop or phone	A forgotten device still signing in
Account of someone who left months ago, from an unfamiliar address	Possible misuse of known credentials — investigate
One source failing against many accounts with 0xC0000072, 0xC000006A and 0xC0000064 mixed	Password spraying or guessing across a username list
Failures shortly before the account is re-enabled	Someone may be waiting for the account to come back

Disabled accounts are attractive to attackers precisely because nobody watches them: a former employee’s or a decommissioned service’s credentials may still be valid elsewhere, and a re-enabled account inherits its old group memberships. A failure stream against a disabled privileged account deserves more urgency than one against an ordinary user.

How to investigate

Group the failures by account, source and logon type:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4625 and (Status =~ "0xc0000072" or SubStatus =~ "0xc0000072")
| summarize Failures = count(), Sources = make_set(IpAddress, 10), Workstations = make_set(WorkstationName, 10),
            LogonTypes = make_set(LogonType, 5), Hosts = make_set(Computer, 10),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by TargetUserName, TargetDomainName
| order by Failures desc

Then look at the sources from the other side — a single source failing across many accounts is guessing, not a stale service:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4625
| summarize Accounts = dcount(TargetUserName), Disabled = dcountif(TargetUserName, SubStatus =~ "0xc0000072" or Status =~ "0xc0000072"),
            WrongPassword = dcountif(TargetUserName, SubStatus =~ "0xc000006a"), UnknownUser = dcountif(TargetUserName, SubStatus =~ "0xc0000064")
    by IpAddress, WorkstationName
| where Disabled > 0 and Accounts >= 5
| order by Accounts desc

For a stale service, go to the source host named in Workstation Name or the source address and find the service, task or stored credential still using the account; replace it with a dedicated service account or a group managed service account. For anything you cannot attribute, keep the account disabled, check whether the same credentials succeed against other systems (VPN, cloud, applications that do not use Active Directory), and check when the account was disabled and by whom — event 4725, “A user account was disabled” — and whether a 4722 re-enable followed. The Windows 4625 password-spray rule covers the many-accounts-from-one-source shape. With no SIEM, export the Security log as XML and load it into the free browser log analyzer.