Event 4720 belongs to the Audit User Account Management subcategory and fires the instant a new user security principal is created, whether that principal ends up as a domain account on a controller, a local account on a member server, or a local account on a plain workstation.
The event lands in the Security channel, generated by Microsoft-Windows-Security-Auditing, and it captures the state of the account at the moment of creation rather than any later change. That distinction matters because a single provisioning action in Active Directory Users and Computers, PowerShell's New-ADUser, net user /add, or a GUI wizard on a standalone box all collapse into the same event ID with the same shape.
The Subject fields (SubjectUserName, SubjectDomainName, SubjectUserSid, SubjectLogonId) describe the operator who ran the create operation, not the account being created. TargetUserName and TargetSid (recorded under the New Account section as Account Name and Security ID in the raw XML, but rendered as TargetUserName/TargetSid in most SIEM parsers) describe the account that now exists.
Conflating these two is the single most common analyst mistake with this event: SubjectUserName tells you which admin, service account, or compromised credential performed the provisioning; TargetUserName tells you the identity that now has a foothold. A helpdesk technician creating ksmith is SubjectUserName=jdoe.admin, TargetUserName=ksmith. An attacker who has already popped a domain admin account and stands up a backdoor identity produces the same shape but with a very different Subject.
Whether the created object is local or domain-scoped is inferred from context, not a dedicated boolean field. On a domain controller, 4720 for a domain user shows TargetDomainName as the AD domain name and the event correlates with directory replication. On a member server or workstation, a local account creation shows TargetDomainName as the machine's own NetBIOS name, and SAM (not AD) owns the object.
Analysts triaging fleet-wide 4720 volume should always split by whether the emitting host is a domain controller, because local-account creation on a DC is close to never legitimate, while local-account creation on a workstation happens for benign reasons (local admin recovery accounts, imaging tools, some legacy line-of-business installers).
The event's Attributes block is where the real diagnostic value sits. SamAccountName and DisplayName describe how the account presents; UserPrincipalName gives the login-style identity that should map to a real mailbox for domain accounts. HomeDirectory, HomePath, ScriptPath, ProfilePath, and UserWorkstations are almost always empty (rendered as a dash) for a freshly created account, because these get populated by later 4738 (account changed) events, not at creation time.
PasswordLastSet shows whether a password was set during creation or deferred; AccountExpires flags whether the account was built with a built-in expiration, which legitimate permanent employee accounts almost never have. PrimaryGroupId should read 513 (Domain Users, or the local equivalent) for a normal user; any other value at creation time is unusual enough to warrant a second look.
OldUacValue is always 0x0 because the account did not exist before, while NewUacValue encodes the initial account-control flags (disabled/enabled, password-not-required, don't-expire-password, and so on) as a bitmask, which is why the human-readable UserAccountControl string alongside it matters more for quick triage than decoding the hex by hand.
Event 4720 rarely appears alone. It is the first event in a predictable creation sequence a SOC learns to read as a unit. Immediately or shortly after 4720, a 4722 (account enabled) typically follows if the account was not created already-enabled, because many provisioning tools create disabled and then flip it on once the rest of the profile is populated.
A 4724 (attempt to reset password) or a password set during creation follows to give the account usable credentials. If the account is meant to carry elevated rights, a 4728 (member added to a global security group, most notably Domain Admins) or 4732 (member added to a local security group, notably local Administrators) shows up next, sometimes within seconds.
A legitimate onboarding workflow spreads these events across minutes to hours as a ticketing system walks through steps; an attacker standing up a persistence account frequently compresses the whole sequence, 4720 through a privileged 4728, into a handful of seconds because it is scripted.
On a domain controller, 4720 sits next to the directory-service events that come from AD replication and schema writes, but the Security-log event itself is generated locally on whichever DC processed the create request, then replicates the resulting object, not the event, to peers.
On a workstation or member server, 4720 is one of the few Account Management events an analyst expects to see at all outside of imaging day or a local recovery procedure, which is exactly why unexpected local 4720s on servers deserve automatic escalation.
Attackers who have already obtained privileged access use 4720 to build a backdoor identity that survives password resets on the compromised account they originally used to get in, and that blends into the noise of routine HR-driven provisioning if named carelessly. Because the event captures the creating Subject, an attacker using a stolen but legitimate admin credential produces a 4720 that looks procedurally correct even though the intent is malicious, which is why field-level attributes (password-never-expires flags, off-hours timestamps, PrimaryGroupId anomalies) carry more triage weight than the mere presence of the event.
