Is Event ID 4767 suspicious?

Most 4767 events are routine helpdesk operations — users forget their passwords, accounts lock out, IT unlocks them. The event becomes suspicious when the Subject Account Name (who unlocked it) is not your expected helpdesk or admin account, when the unlock is immediately followed by a successful logon (4624) from an unexpected IP or workstation, or when the same account was unlocked multiple times in a short window. A 4767 that you cannot attribute to a helpdesk ticket warrants investigation, especially for admin accounts.

What is the difference between Event ID 4767 and Event ID 4722?

Event 4767 fires when a locked-out account is unlocked after exceeding the failed logon threshold set by your lockout policy. Event 4722 fires when a disabled account is re-enabled — a manual action that restores an account that was administratively turned off, not one that locked itself out through authentication failures. An attacker brute-forcing a password will trigger 4740 (lockout) and then need 4767 to proceed. An attacker activating a dormant backdoor account uses 4722 directly, without any preceding lockout event.

Can an attacker unlock their own brute-forced account?

Yes — if the attacker has compromised any account with the 'Reset Password' or 'Account Operators' permission in AD (including many helpdesk accounts), they can unlock any locked account. They would first brute-force to identify the correct password, trigger the lockout, then use the compromised admin account to perform the 4767 unlock, followed immediately by the 4624 successful logon. This is why correlating the Subject Account Name on 4767 events against your known helpdesk accounts matters: a non-helpdesk account performing an unlock is a high-priority signal.

Scan your Security and Sysmon logs·Detection guides

Event ID 4767Audit SuccessSecurityT1110

Windows Event ID 4767 — User Account Unlocked

Logged when a locked-out user account is unlocked by an administrator or automated system. Account lockouts (Event ID 4740) happen when failed logon attempts exceed the lockout policy threshold. The 4767 event identifies who unlocked the account — and when that actor is not the expected IT helpdesk, it may indicate an attacker unlocking an account they just brute-forced.

MITRE ATT&CK

Technique

T1110 · Brute Force

Tactic

Credential Access

View on attack.mitre.org →

Why It Matters

Account lockouts are one of the most reliable indicators of a credential attack in progress. The 4767 (unlock) event tells you what happened next: either IT helpdesk investigated and restored legitimate access, or someone — possibly the attacker — unlocked the account to complete a brute-force attack. An attacker who successfully brute-forces a password may need to unlock the account first (4767) before the successful logon (4624) will succeed, if the lockout occurred before they got the right credential. The pattern 4625 spike → 4740 → 4767 (non-IT Subject) → 4624 success is the full credential attack chain.

Key Fields

Target Account NameThe account that was unlocked — admin and privileged accounts require the most scrutiny; service accounts unlocked outside rotation windows warrant investigation

Subject Account NameWho performed the unlock — should be IT helpdesk, a domain admin, or an automated unlock system. Any other actor is immediately suspicious.

Subject Logon IDLinks to the unlocker's 4624 session — verify the admin performing the unlock came from a known workstation via the expected protocol

Target Account DomainThe domain of the unlocked account — domain account unlocks have broader impact than local account unlocks

Investigation Tips

1.The full attack chain: look for Event ID 4625 (failed logons) in the 5–30 minutes before 4740 (lockout) for the same account, then 4767 (unlock), then 4624 (successful logon). If the Subject Account Name on the 4767 is not your helpdesk account, and a 4624 immediately follows, the attacker brute-forced the password, triggered the lockout, had an account with the ability to unlock (or social-engineered IT into unlocking), and then logged in.
2.Automated unlock systems (e.g., self-service password reset portals) generate 4767 with a predictable Subject Account Name. Any unlock from a Subject that is not that system or your known helpdesk accounts should be flagged for review.
3.Multiple unlocks of the same account in a short window (3+ unlocks within an hour) suggest repeated lockout-unlock cycles — either the attacker is still guessing the wrong password, or there is a legitimate misconfiguration (expired service account credential causing lockout loops).
4.On domain controllers, unlocks are performed by the DC machine account or domain admin. An unlock where the Subject Account Domain does not match your expected domain is anomalous.
5.Correlate 4767 timing with 4624 events for the same account — a successful logon within 60 seconds of an admin unlock, from an unexpected source IP, is the completion of a brute-force attack.

Seeing Event ID 4767 in your own logs? Upload an .evtx file — EventPeeker flags user account unlocked automatically, maps it to MITRE ATT&CK, and writes the triage report. No account, files auto-deleted.

Analyze my logs →

Related Event IDs

4740Account lockout — the event that precedes an unlock

4625Failed logon — the authentication failures that caused the lockout

4624Successful logon — check for immediate logon after unlock, especially from new IPs

4722Account enabled — related: an attacker may enable a disabled account rather than unlock it

Frequently Asked Questions

Is Event ID 4767 suspicious?: Most 4767 events are routine helpdesk operations — users forget their passwords, accounts lock out, IT unlocks them. The event becomes suspicious when the Subject Account Name (who unlocked it) is not your expected helpdesk or admin account, when the unlock is immediately followed by a successful logon (4624) from an unexpected IP or workstation, or when the same account was unlocked multiple times in a short window. A 4767 that you cannot attribute to a helpdesk ticket warrants investigation, especially for admin accounts.
What is the difference between Event ID 4767 and Event ID 4722?: Event 4767 fires when a locked-out account is unlocked after exceeding the failed logon threshold set by your lockout policy. Event 4722 fires when a disabled account is re-enabled — a manual action that restores an account that was administratively turned off, not one that locked itself out through authentication failures. An attacker brute-forcing a password will trigger 4740 (lockout) and then need 4767 to proceed. An attacker activating a dormant backdoor account uses 4722 directly, without any preceding lockout event.
Can an attacker unlock their own brute-forced account?: Yes — if the attacker has compromised any account with the 'Reset Password' or 'Account Operators' permission in AD (including many helpdesk accounts), they can unlock any locked account. They would first brute-force to identify the correct password, trigger the lockout, then use the compromised admin account to perform the 4767 unlock, followed immediately by the 4624 successful logon. This is why correlating the Subject Account Name on 4767 events against your known helpdesk accounts matters: a non-helpdesk account performing an unlock is a high-priority signal.

Go deeper: the full Account Persistence — Backdoor Accounts and Unauthorized Group Changes guide

Builds on this page with the attack chain, step-by-step investigation, immediate containment actions, KQL/Sigma detection queries, and an annotated example log.

Read the Account Persistence — Backdoor Accounts and Unauthorized Group Changes guide →

See Event ID 4767 in your logs

Upload a Windows Event Log (.evtx) file — EventPeeker automatically detects user account unlocked patterns, maps findings to MITRE ATT&CK, and generates an AI triage report.

Analyze EVTX Logs Free →

← All detection guides·Analyze EVTX Logs Free →