Windows Security Log · Event 4720

Event 4720: A user account was created

A new user account was created, either on the local machine or in the domain. In a managed environment every one of these should be traceable to a request. An account you cannot account for is one of the clearest findings available in the Windows log.

Also written as 4720Event ID 4720A user account was created

How oftenUncommon
Vendor calls itAudit Success
LogSecurity
SourceMicrosoft-Windows-Security-Auditing

What it means for you

On a personal computer

Someone added a new user to this PC. If that was not you, it matters — an extra account is a common way to keep access to a machine after a break-in. Check Settings, Accounts, Other users and remove anything you do not recognise.

For an analyst

Pair it with the group-membership events that usually follow. Creation alone is low signal; creation followed within minutes by addition to a privileged group and then a sign-in is the sequence worth alerting on. Watch for names designed to blend in, and for trailing dollar signs used to masquerade as computer accounts.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample

A user account was created.

Subject:
  Security ID:    CORP\jbrooks-adm
  Account Name:   jbrooks-adm
  Account Domain: CORP
  Logon ID:       0x3E9A11

New Account:
  Security ID:    CORP\svc-update
  Account Name:   svc-update
  Account Domain: CORP

Attributes:
  SAM Account Name: svc-update
  Display Name:     <value not set>
  User Principal Name: svc-update@corp.example
  Home Directory:   <value not set>
  Script Path:      <value not set>
  Password Last Set: <never>
  Account Expires:  <never>
  User Account Control:
    %%2080
    %%2082
    %%2084

The fields that decide it

Everything else in the log line is context.

TargetUserName: The name of the account that was created.
TargetSid: The security identifier of the new account. Use it rather than the name to follow the account, since names can be changed afterwards.
SubjectUserName: Who created it. This is the account to hold responsible, and the one to check next if the creation was not authorised.
SubjectLogonId: The session that performed the creation. Join it to the 4624 to find where the creator was signed in from.
SamAccountName: The account name as stored in SAM or Active Directory.
UserPrincipalName: The domain sign-in name, where one was set.

Ordinary reasons this happens

Most of the time it is one of these.

Ordinary onboarding through your normal account provisioning process.
Identity management or HR integration software creating accounts automatically.
An administrator creating a service account for a new application.
Software installers creating a dedicated local service account — several database and backup products do this.
Building a new machine from an image, which creates local accounts as part of setup.

When it is not ordinary

An attacker creating a backdoor account to keep access.

What gives it awayA creation outside change windows, by an account that does not normally provision users, quickly followed by a privileged group addition.

ATT&CK T1136.001

A local account created on a workstation to survive a domain password reset.

What gives it away4720 on a workstation rather than a domain controller, for an account not part of your build process.

ATT&CK T1136.001

An account named to blend into normal listings.

What gives it awayNames imitating service accounts or administrator accounts, or ending in a dollar sign to look like a computer.

ATT&CK T1036

Bulk provisioning by automated tooling after a compromise.

What gives it awaySeveral accounts created in quick succession by one session, with no matching change request.

ATT&CK T1136

What to do next

Read SubjectUserName. Whoever created the account is where the investigation starts.
Match the account name against your provisioning records or ticket system. No matching request is the finding.
Look at what happened next for the same target account — group additions, password sets, and the first sign-in tell you what it was for.
Check whether the creation happened on a domain controller or on a workstation. A local account created on a workstation is a different and often worse story.
Take the creator's Logon ID and find their 4624 to see where they were signed in from.
If the creation is not explainable, disable rather than delete the account so you keep the evidence.

Queries to run

kql The whole feed. Volume is low enough in most environments to read every one.

SecurityEvent | where EventID == 4720 | project TimeGenerated, Computer, NewAccount = TargetUserName, CreatedBy = SubjectUserName, SubjectLogonId | order by TimeGenerated desc

kql Account created and given privileges within half an hour. This sequence is the alert, not either event alone.

let created = SecurityEvent | where EventID == 4720 | project CreateTime = TimeGenerated, Computer, Account = TargetUserName;
let promoted = SecurityEvent | where EventID in (4728, 4732, 4756) | project PromoteTime = TimeGenerated, Account = MemberName, Group = TargetUserName;
created | join kind=inner promoted on Account | where PromoteTime - CreateTime between (0min .. 30min) | project CreateTime, Computer, Account, Group

powershell A month of account creations on one machine. Run it on workstations, where an unexpected local account is most likely to be found.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720; StartTime=(Get-Date).AddDays(-30)} | Select-Object TimeCreated, @{n='NewAccount';e={$_.Properties[0].Value}}, @{n='CreatedBy';e={$_.Properties[4].Value}}

splunk

index=wineventlog EventCode=4720 | table _time dest Account_Name Security_ID | sort -_time

Common questions

Someone created a user account on my PC and it was not me. What should I do?

Treat it as a possible compromise. Disable the account rather than deleting it so the evidence survives, check Event 4732 to see whether it was added to the Administrators group, change your own password from a different device, and look at Event 4624 to see whether the new account has been used and from where.

Why does Event 4720 show 'Password Last Set: never'?

Because account creation and password setting are two separate operations. The account exists at this point but has no usable password yet — the password arrives in a following Event 4724 or 4723. A 4720 with no 4724 after it means the account was never finished.

What is the difference between Event 4720 on a domain controller and on a workstation?

On a domain controller it is a domain account, visible everywhere and usually part of a normal provisioning process. On a workstation it is a local account that exists only on that machine — which is exactly why attackers create them, since a domain-wide password reset does not touch it.

Should I alert on every Event 4720?

In most environments yes, because the volume is low and every creation should map to a request. If your provisioning is automated, exclude the service account that performs it and alert on everything else — that exclusion is what keeps the rule useful rather than ignored.

Mentioned by

Vendor documentation

Last reviewed 28 August 2026