Event ID 4720: A User Account Was Created — Who Created It, and How

What it records

Event 4720 is the Audit User Account Management subcategory recording that a user object was created. Microsoft’s description is deliberately broad: “This event generates every time a new user object is created”, and it “generates on domain controllers, member servers, and workstations”. That means one event covers both a helpdesk creating a domain user in Active Directory Users and Computers and a process creating a local account on a workstation — the Computer field and the new account’s Account Domain are what separate the two cases.

The event has three useful blocks. Subject names who made the change: Security ID, Account Name, Account Domain and Logon ID, the last of which Microsoft describes as a value “that can help you correlate this event with recent events that might contain the same Logon ID”, giving event 4624 as its example. New Account names the object that was created, with its SID, name and domain. Attributes is the snapshot of the object as created: SAM Account Name, Display Name, User Principal Name, Home Directory, Home Drive, Script Path, Profile Path, User Workstations, Password Last Set, Account Expires, Primary Group ID, Allowed To Delegate To, Old UAC Value, New UAC Value, User Parameters, SID History and Logon Hours. Old UAC Value, per the documentation, “is always ‘0x0’ for new accounts”. A final Privileges field lists the user privileges used during the operation, and may appear as a hyphen.

When it matters

Account creation is a normal administrative act in most environments, so severity comes from who did it, where, when, and what the object looks like. Microsoft notes that “Some organizations monitor every 4720 event” — a reasonable position on domain controllers and on servers where no accounts should ever be created.

Pattern	Reading
4720 on a member server or workstation with no local-account process	A local account created outside your build process, often for persistence
4720 followed within minutes by 4732 adding the new SID to Administrators	Account creation plus privilege grant — treat as one action
Creator is an account that never administers users, or a session from an unfamiliar source	Follow the Subject Logon ID back to its 4624
SAM Account Name or User Principal Name empty or a hyphen	Microsoft’s table says the field must contain the user account name, and that an empty value “might indicate an anomaly”
Home Directory, Home Drive, Script Path, Profile Path or User Workstations populated	Microsoft: “Typically these fields are - for new user accounts. Other values might indicate an anomaly and should be monitored.”
Primary Group ID not 513	Microsoft: “Typically, the Primary Group value is 513 for domain and local users. Other values should be monitored.”
SID History populated when no account was migrated	Microsoft: “This field will always be set to - unless the account was migrated from another domain.”
New UAC Value with ‘Server Trust Account’ enabled	Microsoft: “Should never be enabled for user accounts. Applies only to domain controller (computer) accounts.”

An account created disabled and later used will fail its logons with 0xC0000072, which is a cheap way to find backdoor accounts that were never enabled correctly.

How to investigate

Start with every creation and who performed it:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4720
| project TimeGenerated, Computer,
          Creator = strcat(SubjectDomainName, "\\", SubjectUserName), SubjectLogonId,
          NewAccount = strcat(TargetDomainName, "\\", TargetUserName), TargetSid
| order by TimeGenerated desc

Then apply Microsoft’s attribute recommendations by reading the values out of the event XML, which is where they live:

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4720
| parse EventData with * 'SamAccountName">' SamName '<' *
| parse EventData with * 'UserPrincipalName">' Upn '<' *
| parse EventData with * 'PrimaryGroupId">' PrimaryGroupId '<' *
| parse EventData with * 'ScriptPath">' ScriptPath '<' *
| parse EventData with * 'SidHistory">' SidHistory '<' *
| parse EventData with * 'NewUacValue">' NewUacValue '<' *
| where SamName in ("", "-") or PrimaryGroupId != "513" or ScriptPath != "-" or SidHistory != "-"
| project TimeGenerated, Computer, SubjectUserName, TargetUserName, TargetDomainName,
          SamName, Upn, PrimaryGroupId, ScriptPath, SidHistory, NewUacValue
| order by TimeGenerated desc

Remember that User Principal Name is a hyphen for local users, so filter on it only for domain accounts.

The highest-value pivot is the new account’s SID. Join it to the member additions that followed, which is the creation-plus-privilege pattern:

let created = SecurityEvent
    | where TimeGenerated > ago(7d) and EventID == 4720
    | project CreateTime = TimeGenerated, Computer, Creator = SubjectUserName,
              NewAccount = TargetUserName, NewSid = TargetSid;
SecurityEvent
| where TimeGenerated > ago(7d) and EventID == 4732
| project GroupTime = TimeGenerated, GroupHost = Computer, AddedBy = SubjectUserName,
          Group = TargetUserName, MemberSid, MemberName
| join kind=inner created on $left.MemberSid == $right.NewSid
| where GroupTime between (CreateTime .. CreateTime + 1h)
| project CreateTime, GroupTime, Computer, Creator, NewAccount, Group, AddedBy, GroupHost
| order by CreateTime desc

From there, take the Subject Logon ID back to the 4624 that created the administrator’s session and to 4672 if that session held special privileges, and follow the new SID forward through 4722, 4724, 4738 and its first 4624. If the account was deleted again (4726) shortly after use, or the audit log was cleared (1102) around the same window, treat the creation as part of an intrusion rather than an administrative mistake. Without a SIEM, export the Security log as XML from Event Viewer and load it into the free browser log analyzer.