Hunting Unexpected Windows Account Creation: Event 4720 with KQL and Splunk

An unexpected Windows account can provide a new access path. This hunt starts with Event 4720, identifies who created the account, and checks its scope and subsequent use with read-only KQL and Splunk searches.

Why it matters

Account creation is also routine provisioning. A detection becomes useful when it explains why this account, creator or host differs from an approved workflow. The goal is an evidence-backed decision, not a list of every new username.

Microsoft documents Event 4720 under Audit User Account Management. It records creation of a user object and can appear on domain controllers, member servers and workstations. Subject fields describe the requester; target fields describe the new account. The account SID is important for tracking identity even when display names change.

For confirmed adversarial local-account creation, the relevant mapping is MITRE ATT&CK T1136.001, Create Account: Local Account. Establish scope before applying that mapping: an account created in a directory is not automatically a local account.

Original evidence trail. Creation, privileges and actual use are separate questions.

Enlarge the account evidence trail

Prepare the evidence

Verify successful user-account-management auditing and collection on relevant endpoints and domain controllers.
Collect the creation event with original XML, creator identity, new account SID, account domain and timestamp.
Obtain authorized account inventory, provisioning tickets, relevant group-change records and authentication history.
Check collector health and retention. An empty search is not proof that no account was created.

KQL: review new accounts

This query targets Microsoft Sentinel’s SecurityEvent schema. Check connector mappings against a known creation record first.

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4720
| project TimeGenerated, Computer,
    SubjectUserName, SubjectDomainName, SubjectUserSid,
    TargetUserName, TargetDomainName, TargetSid, EventData
| order by TimeGenerated desc

Start with the complete event set for a bounded period. Then prioritize deviations using verified host roles and provisioning ownership. Avoid filtering only on suspicious-looking names: legitimate-looking names can still be unauthorized.

Splunk: retain source context

Replace index and sourcetype with your collection. This example assumes XML-style Windows event extractions; validate field names if your add-on uses different aliases.

index=windows sourcetype="XmlWinEventLog:Security" earliest=-24h EventCode=4720
| table _time Computer host SubjectUserName SubjectDomainName
    SubjectUserSid TargetUserName TargetDomainName TargetSid _raw
| sort 0 - _time

Test and adapt both read-only queries in authorized environments. They are teaching examples and have not been executed against your tenant. Preserve the source event when normalized fields are missing, and do not interpret blank extractions as an absent identity.

Six steps from signal to finding

Confirm the event. Preserve the original creation record, collection source and time zone. Confirm it is a new account event rather than a similarly named account update.
Resolve scope. Compare the target domain, host role and authoritative account inventory. Keep local and directory identity namespaces separate.
Identify the creator. Review the subject’s ownership, expected provisioning privileges and contemporaneous activity. A service account name is not sufficient proof of automation.
Check authorization. Reconcile the exact account, host and time with an approved request or deployment record. Verify the owner through a trusted channel.
Review subsequent access. Search group membership changes and authentication records using the correct identity fields for each event type. A creation event’s target SID and a group-add event’s member SID represent different roles; do not join blindly on generic target names.
Document a bounded conclusion. Record what was created, by whom, which privileges and uses were established, and where telemetry was unavailable. Separate confirmed observations from hypotheses.

Two fictional scenarios

Provisioning: A deployment service creates a support account on an approved test workstation. The ticket, owner and intended lifetime match, and subsequent use aligns with testing. Record the evidence and the planned account removal date.

Unexplained access path: A new account appears on a production server outside its normal provisioning process. The creator cannot explain the action, and independent records show an unexpected privilege change. Escalate for incident response. Do not infer data theft or domain-wide compromise from account creation alone.

Tuning and containment

Baseline creator, asset role and provisioning workflow together. Scope exceptions to a specific controlled process, assign an owner and review expiry. Keep deviations in account lifetime, destination host and privileges visible instead of excluding all activity by a deployment identity.

When evidence supports unauthorized creation, coordinate with the system and identity owners. Preserve records and assess dependencies before disabling the account or containing the host under the approved response procedure. Review the creator’s access as well: removing the new account does not explain how creation became possible.

Open the case-note checklist

Creation event and immutable identity recorded?
Local versus directory scope verified?
Creator authorization and ticket reconciled?
Privileges and observed use supported by separate evidence?
Containment owner, residual risk and follow-up date assigned?

Key takeaways

Start with Event 4720, preserve identity scope and follow the new SID through available evidence. A good finding explains authorization, privileges and use without overstating what a single event proves.

Continue with RDP authentication investigations or the Knowledge Base. Sources reviewed October 4, 2026; examples are fictional.