Is Event ID 4722 always suspicious?

No — IT helpdesk re-enables accounts routinely for employees who were temporarily offboarded, contractors returning, or service accounts that were incorrectly disabled. The red flags are: re-enablement by an account other than known IT admins or provisioning systems, re-enablement outside business hours without a corresponding helpdesk ticket, re-enablement of an account that was disabled as part of a security incident response, or re-enablement immediately followed by privileged group membership changes (4728). Context and the Subject Account Name are the primary filters.

What is the 4722 + 4728 attack chain?

The 4722+4728 sequence is the dormant backdoor activation pattern. An attacker who previously created and then disabled a backdoor account (or who knows about an existing dormant privileged account) re-enables the account (4722), then immediately adds it to Domain Admins or another privileged group (4728). This happens within seconds to minutes, using the same Subject Account Name for both events. The re-used account avoids generating a 4720 (new account) alert. Correlate on the Target Account Name across both events and alert when the elapsed time is under 60 seconds.

Why would an attacker re-enable a dormant account instead of creating a new one?

Three reasons: (1) many teams monitor for 4720 (new account creation) but not 4722 (re-enablement), so it is lower-visibility; (2) a dormant account may already have group memberships, delegation rights, and cached credentials that are immediately useful; (3) a dormant account with 'password never expires' and existing SPNs can be Kerberoasted as soon as it is re-enabled without requiring the attacker to configure anything. Attackers often stage dormant accounts in an environment before triggering detection — re-enabling one is faster and quieter than starting fresh.

How do I distinguish legitimate IT re-enablement from an attacker using Event ID 4722?

Check these four signals: (1) Subject Account Name — should be a known helpdesk or provisioning account, not a regular user or service account; (2) time — legitimate re-enablements happen during business hours and correlate with a helpdesk ticket; (3) what follows — legitimate re-enablement is followed by normal user activity, not immediately by group changes (4728) or privileged logons (4624 Type 3 to sensitive systems); (4) target account history — if the account was disabled as part of a security investigation, any re-enablement without explicit security team approval is an incident.

Scan your Security and Sysmon logs·Detection guides

Event ID 4722Audit SuccessSecurityT1078

Windows Event ID 4722 — User Account Enabled

Logged when a previously disabled user account is re-enabled. Attackers re-enable dormant accounts to gain access that inherits the original account's credentials, group memberships, and Service Principal Names — without triggering the 4720 (new account creation) alert that many teams monitor.

MITRE ATT&CK

Technique

T1078 · Valid Accounts

Tactic

Persistence

View on attack.mitre.org →

Why It Matters

A re-enabled dormant account is a lower-visibility persistence technique than creating a new account. The re-enabled account may retain Domain Admin membership, valid Kerberos SPNs (making it immediately Kerberoastable), and cached credentials on endpoints where it previously logged on. Attackers target accounts disabled during offboarding because these accounts are rarely reviewed after deprovisioning — they may still have delegation rights, password-never-expires flags, and access to resources that were never revoked. The 4722 + 4728 sequence (account re-enabled, then immediately added to a privileged group) is the backdoor activation IOC.

Key Fields

Target Account NameThe account that was re-enabled — check when it was last active and why it was disabled

Target Account DomainThe domain of the re-enabled account — unexpected domains or workgroup accounts on domain-joined systems are suspicious

Subject Account NameWho performed the re-enablement — should be IT helpdesk or an automated provisioning account. Any other actor is suspicious

Subject Logon IDSession that performed the re-enablement — correlate with 4624 to check the logon type and source IP of the account that did this

Service Principal NamesIf the re-enabled account has SPNs set (visible in AD), it is immediately Kerberoastable after re-enablement — attackers re-enable service accounts specifically for this

Investigation Tips

1.Cross-reference with your offboarding records — was this account deliberately disabled as part of an employee departure or security response? An unexplained re-enablement without a matching helpdesk ticket is an incident.
2.Backdoor activation chain: 4722 (re-enabled) followed by 4728 (added to Domain Admins or other privileged group) within 60 seconds using the same Subject Account Name. This is the attacker activating a pre-staged dormant account.
3.Check Subject Logon ID against 4624 — if the re-enabling session originated from an unusual IP, workstation, or used NTLM when Kerberos is expected, the admin account performing the re-enablement may itself be compromised.
4.Service accounts with SPNs: a re-enabled service account is immediately valid for Kerberoasting (4769 requests). Check for 4769 events targeting the re-enabled account's SPN within minutes of the 4722.
5.Review the re-enabled account's last logon date in AD. If the account has been dormant for months but had high privileges, treat any unexplained re-enablement as critical regardless of who performed it.

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

Analyze my logs →

Related Event IDs

4725Account disabled — the action this reverses

4624Successful logon — check for immediate logon by the re-enabled account

4728Added to privileged group — 4722+4728 within 60s = backdoor activation IOC

4769Kerberos service ticket — re-enabled SPNs are immediately Kerberoastable

4720Account created — compare: creating new vs re-enabling existing is a choice that changes detection visibility

Frequently Asked Questions

Is Event ID 4722 always suspicious?: No — IT helpdesk re-enables accounts routinely for employees who were temporarily offboarded, contractors returning, or service accounts that were incorrectly disabled. The red flags are: re-enablement by an account other than known IT admins or provisioning systems, re-enablement outside business hours without a corresponding helpdesk ticket, re-enablement of an account that was disabled as part of a security incident response, or re-enablement immediately followed by privileged group membership changes (4728). Context and the Subject Account Name are the primary filters.
What is the 4722 + 4728 attack chain?: The 4722+4728 sequence is the dormant backdoor activation pattern. An attacker who previously created and then disabled a backdoor account (or who knows about an existing dormant privileged account) re-enables the account (4722), then immediately adds it to Domain Admins or another privileged group (4728). This happens within seconds to minutes, using the same Subject Account Name for both events. The re-used account avoids generating a 4720 (new account) alert. Correlate on the Target Account Name across both events and alert when the elapsed time is under 60 seconds.
Why would an attacker re-enable a dormant account instead of creating a new one?: Three reasons: (1) many teams monitor for 4720 (new account creation) but not 4722 (re-enablement), so it is lower-visibility; (2) a dormant account may already have group memberships, delegation rights, and cached credentials that are immediately useful; (3) a dormant account with 'password never expires' and existing SPNs can be Kerberoasted as soon as it is re-enabled without requiring the attacker to configure anything. Attackers often stage dormant accounts in an environment before triggering detection — re-enabling one is faster and quieter than starting fresh.
How do I distinguish legitimate IT re-enablement from an attacker using Event ID 4722?: Check these four signals: (1) Subject Account Name — should be a known helpdesk or provisioning account, not a regular user or service account; (2) time — legitimate re-enablements happen during business hours and correlate with a helpdesk ticket; (3) what follows — legitimate re-enablement is followed by normal user activity, not immediately by group changes (4728) or privileged logons (4624 Type 3 to sensitive systems); (4) target account history — if the account was disabled as part of a security investigation, any re-enablement without explicit security team approval is an incident.

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 4722 in your logs

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

Analyze EVTX Logs Free →

← All detection guides·Analyze EVTX Logs Free →