Event ID 4720 and 4732: Account Created, Added to Admins

Event ID 4720 means "A user account was created": Windows writes it to the Security log every time a new user object is made, on domain controllers, member servers and workstations. Event ID 4732 means a member was added to a security-enabled local group, such as the built-in Administrators group, and its siblings 4728 and 4756 do the same for global and universal domain groups.

Each is routine IT work on its own. Together, a new account followed minutes later by a group add into Administrators or Domain Admins is one of the clearest persistence patterns in a Windows log. This post covers the fields that matter, how to join the two in Splunk and Sentinel, and what normal looks like. For the full list of IDs worth knowing, see our Windows Event Log IDs cheat sheet.

What do event IDs 4720, 4722, 4732, 4728 and 4756 mean?

All five live in the Security log. Here is Microsoft's title for each, and where it can be generated.

Two details trip people up. First, 4732 is not only for workstations. The built-in Administrators group on a domain controller is a local (Builtin) group, so adding someone to it there is a 4732, not a 4728. Second, Domain Admins is a global group (4728), while Enterprise Admins and Schema Admins are universal groups (4756). If your detection only watches 4728, it misses two of the most powerful groups in the forest.

4722 matters because attackers do not always create a new account. Re-enabling an old disabled one gets them the same thing with less noise, and that shows up as 4722 with no 4720 in front of it.

Which audit policy enables them?

The events come from two Advanced Audit Policy subcategories under Account Management:

• Audit User Account Management: 4720, 4722, and related events such as 4724 (password reset attempt), 4725 (disabled), 4726 (deleted) and 4738 (account changed).
• Audit Security Group Management: 4732, 4728, 4756, plus the removals (4733, 4729, 4757) and group creation and change events.

Microsoft rates both as low volume and recommends Success auditing on domain controllers, member servers and workstations. Security Group Management has no Failure events at all. You set them in Group Policy under Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Management, or check a single machine from an elevated prompt:

auditpol /get /category:"Account Management"

If a host shows "No Auditing" for either subcategory, it will never send you these events.

Which fields matter: Subject vs New Account vs Member

Every one of these events has a Subject section. The Subject is who did it. The second section is who it was done to, and its name changes by event: New Account on 4720, Target Account on 4722, Member and Group on 4732, 4728 and 4756. Mixing those up is the most common beginner mistake with these IDs.

Note that TargetUserName means the new account on 4720 but the group on 4732. Read the event ID before you read the field.

The MemberName detail matters for detection. Microsoft's documentation says that for local groups this field typically shows -, even when the new member is a domain account. So if you try to match a 4720 to a 4732 by name, it will often fail. Match on the SID instead: the new account's TargetSid on 4720 equals the MemberSid on the group event.

On 4720 itself, Microsoft lists values worth a second look: a Primary Group ID other than 513, SID History that is not - on an account that was not migrated, or flags like 'Don't Require Preauth' or 'Trusted For Delegation' enabled on a brand new user.

What normal looks like

Most 4720s in a domain are boring. A help desk technician or an identity provisioning service creates new starters during business hours, the Subject is a known admin or service account, and the new account lands in Domain Users. Group adds follow your joiner and mover process: someone gets added to a department group, a project group, a VPN group.

Normal has a shape: names that follow your convention, created by the same small set of Subjects every time. Learn it and the odd one stands out.

What attacker activity looks like

Once an attacker has admin rights, a backup account they control is cheap insurance. MITRE ATT&CK tracks this as T1136 Create Account (T1136.001 Local Account, T1136.002 Domain Account) under Persistence. Putting that account in a privileged group is T1098.007 Additional Local or Domain Groups, a sub-technique of T1098 Account Manipulation, under Persistence and Privilege Escalation. MITRE's own example tools for the group add are net localgroup and net group.

On a workstation or server, the pattern looks like this:

net user svc_backup P@ssw0rd123! /add
net localgroup Administrators svc_backup /add

That produces a 4720 for svc_backup, then a 4732 where the Group is Administrators in the Builtin domain and the MemberSid matches the new account's SID. The domain version swaps in net user ... /add /domain and net group "Domain Admins" ... /add /domain, which gives you a 4720 and a 4728 on a domain controller.

Things that make it worse:

• The two events are seconds or minutes apart and share the same Subject.
• The Subject is not one of your known admin or provisioning accounts.
• The name imitates a service or vendor account (svc_, support, admin1) but matches no ticket.
• A 4722 re-enables an account that has been disabled for months, then a group add follows.

If you collect process creation, the command lines above also appear in 4688 and in Sysmon Event ID 1, with the parent process that ran them. That tells you whether net.exe came from an admin's console or from a web server process.

How to detect account creation followed by a group add

Both searches below find a new account that was added to a security group within an hour of being created, and join on the SID rather than the name.

Splunk

This assumes Security events are collected by the Splunk Add-on for Microsoft Windows as XML (sourcetype="XmlWinEventLog:Security"), so the add-on extracts EventCode plus the XML field names shown in the table above. Change the index to match yours.

index=wineventlog sourcetype="XmlWinEventLog:Security" EventCode IN (4720, 4732, 4728, 4756)
| eval account_sid=if(EventCode=4720, TargetSid, MemberSid)
| eval created=if(EventCode=4720, _time, null()), added=if(EventCode=4720, null(), _time)
| eval new_account=if(EventCode=4720, TargetUserName, null()), grp=if(EventCode=4720, null(), TargetUserName)
| stats min(created) as created min(added) as added values(new_account) as new_account values(grp) as groups values(SubjectUserName) as actors values(host) as hosts by account_sid
| where isnotnull(created) AND isnotnull(added) AND added>=created AND added-created<=3600
| convert ctime(created) ctime(added)

One row per account SID: when it was made, which groups it joined, and who did it. Filter groups to your privileged groups if it is noisy.

KQL (Microsoft Sentinel)

This uses Sentinel's SecurityEvent table, where TargetAccount and SubjectAccount are the domain-qualified names.

let window = 1h;
let created = SecurityEvent
| where TimeGenerated > ago(1d) and EventID == 4720
| project CreatedTime = TimeGenerated, NewAccount = TargetAccount, NewSid = TargetSid, CreatedBy = SubjectAccount, Computer;
SecurityEvent
| where TimeGenerated > ago(1d) and EventID in (4732, 4728, 4756)
| project AddedTime = TimeGenerated, Group = TargetAccount, MemberSid, AddedBy = SubjectAccount, EventID
| join kind=inner created on $left.MemberSid == $right.NewSid
| where AddedTime between (CreatedTime .. (CreatedTime + window))
| project CreatedTime, AddedTime, Computer, NewAccount, Group, EventID, CreatedBy, AddedBy

A good second rule is simpler: alert on any 4732, 4728 or 4756 into a privileged group, new account or not.

False positives

These events are low volume, but not rare. Expect:

• Help desk and joiner processes. A technician creates a user and adds them to groups in one sitting. That is exactly the create-then-add pattern. Check the Subject against your list of help desk accounts and the ticket queue.
• Identity provisioning tools. HR-driven provisioning systems and sync services create accounts and set group membership automatically, often in bulk, from one service account. Allowlist that Subject, then alert if it ever adds someone to a privileged group it does not normally touch.
• Vendor and support accounts. A vendor install may create its own local account and group. Confirm it against the change record before you close it.

The question is never just "was an account created?" It is "did the expected account, created by the expected Subject, land in the expected group?"

Related event IDs

• 4724, 4738, 4725, 4726: password reset, account changed, disabled, deleted. A 4726 shortly after a 4720 can be an attacker cleaning up.
• 4733, 4729, 4757: the matching "member removed" events for local, global and universal groups.
• 4624: the logon behind the change. Match the SubjectLogonId to find where the actor logged on from. See Event ID 4624 logon types.
• 4688 and Sysmon Event ID 1: the net.exe or PowerShell command that made the change. See Event ID 4688 and Sysmon Event ID 1.

Sysmon has no account creation event; its value here is the process that made the change.

FAQs

What is event ID 4720?

Event ID 4720 is "A user account was created." It is logged in the Security log whenever a new user object is created, locally or in Active Directory, if Audit User Account Management is enabled.

What is the user creation event ID in Windows?

User creation is event ID 4720. Re-enabling an existing account is 4722. Computer accounts have their own event, so 4720 is the one to watch for new users.

What does event ID 4732 mean?

It means a member was added to a security-enabled local group, such as Builtin Administrators. It also covers domain local groups on domain controllers. Match its MemberSid to a 4720's TargetSid to see if a brand new account was the one added.

What is the difference between 4728, 4732 and 4756?

They are the same event for different group scopes: 4732 for local and domain local groups, 4728 for global groups such as Domain Admins, and 4756 for universal groups such as Enterprise Admins.

Which audit policy logs account creation?

Audit User Account Management for 4720 and 4722, and Audit Security Group Management for 4732, 4728 and 4756. Both sit under Account Management in Advanced Audit Policy.

TL;DR

4720 means an account was created, 4722 means one was enabled, and 4732, 4728 and 4756 mean a member was added to a local, global or universal security group. Turn on Audit User Account Management and Audit Security Group Management. Read the Subject as "who did it" and the New Account or Member as "who it was done to". Join 4720 to the group events on SID, not name, and alert when a new account lands in Administrators, Domain Admins or Enterprise Admins within an hour. Allowlist your help desk and provisioning accounts, then watch everything else.

How EpicDetect Can Help

Knowing the event ID is step one. Deciding whether a new admin account is a help desk ticket or an intruder is the actual job. Our free cases give you a briefing, evidence in a SIEM-style log search or endpoint console, and a verdict to ship with its IOCs, like a real ticket.

Adventures Season Zero is a free, story-driven first week as a new analyst, and the Atlas maps what to learn next across SOC, detection and threat intel, plus Security+ prep if you are still working on the cert.

Start free. No card needed.