0xC000006E: Windows Logon Blocked by an Account Restriction

What it means

0xC000006E is STATUS_ACCOUNT_RESTRICTION. Windows resolved the account name and accepted the authentication information, then refused the logon because of a restriction on the account itself. Microsoft’s example is time-of-day restrictions; the same status covers the family of “the credentials are fine, the account may not log on like this right now” conditions.

For triage the useful half of that sentence is the first half: the submitted credentials were valid. This is not a guessing failure like 0xC000006A (real account, wrong password) or 0xC0000064 (name does not exist). Someone, or something, had working credentials.

In event 4625 the code can appear in Status — in which case Sub Status carries the specific reason — or as the Sub Status itself. Read it together with Logon Type (3 network, 10 RemoteInteractive, 5 service, 4 batch) and Source Network Address, which tell you what kind of access was attempted and from where.

Is it an attack?

Pattern	Reading
One user, logon type 2 or 10, outside their working hours	Logon-hours or workstation restriction doing its job
Service or batch logon failing on a fixed schedule from one internal host	A scheduled task or service using an account whose restrictions exclude that host or time
A single account, repeatedly, right after an administrator disabled or expired it	Something still holds the old credentials — a stored password, a token, or a person
One external or unfamiliar address, one account, valid credentials each time	Credential theft or reuse blocked only by account state — escalate
One source, 0xC000006E across several accounts	Someone is working through a set of credentials they already have (T1078)

The distinction that matters: an account disabled during offboarding failing from the ex-employee’s laptop is cleanup; the same code from a host that should never touch that account is an incident.

How to investigate

Start by listing which accounts are hitting the restriction, from where, and with which specific Sub Status:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4625 and (Status =~ "0xc000006e" or SubStatus =~ "0xc000006e")
| summarize Attempts = count(), Sources = dcount(IpAddress),
            SubStatuses = make_set(SubStatus, 10), LogonTypes = make_set(LogonType, 5),
            SourceList = make_set(IpAddress, 20), Hosts = make_set(Computer, 10)
    by TargetUserName, TargetDomainName
| order by Attempts desc

Then answer the question that sets the severity — did the same account and source ever succeed once the restriction no longer applied?

let restricted = SecurityEvent
    | where TimeGenerated > ago(7d) and EventID == 4625
    | where Status =~ "0xc000006e" or SubStatus =~ "0xc000006e"
    | summarize Fails = count(), LastFail = max(TimeGenerated) by TargetUserName, IpAddress;
SecurityEvent
| where TimeGenerated > ago(7d) and EventID == 4624
| join kind=inner restricted on TargetUserName, IpAddress
| where TimeGenerated > LastFail
| project TimeGenerated, Computer, TargetUserName, IpAddress, LogonType, WorkstationName, Fails
| order by TimeGenerated desc

If the source is unrecognised, treat the password as compromised: reset it, check which sessions and tokens exist for the account, and review what the account could reach had the restriction not been there. If the source is a known server, confirm the account’s logon hours, its logon workstations list and any authentication policy before changing anything — the fix is usually configuration, not a reset. Without a SIEM, export the Security log as XML from Event Viewer and group the 4625 events by source and Sub Status in the free browser analyzer.