Event ID 4720 and 4732: new accounts and new admins

An alert says Event ID 4720 fired on a file server at 02:14, and two seconds later an Event ID 4732 added the same account to the local Administrators group. Nobody on the team was working at 02:14. That pairing, a new account followed almost immediately by admin rights, is one of the most common ways attackers keep access after the first foothold, because it survives a password reset on the account they originally stole.

Most 4720 and 4732 events are boring: new hires, helpdesk work, software installers. The job is to separate those from the one that isn't, and to do it quickly. Here is how I read them.

What does Event ID 4720 mean?

4720 is "A user account was created." It is written to the Security log of the machine that created the account. For a domain account that is the domain controller that handled the request, so you need logs from every DC, not just the one you happen to be logged into. For a local account it is the workstation or server itself.

Two sections matter. Subject is who did it, including a Logon ID. New Account is the account that was created. The Attributes block below that (SAM Account Name, UPN, User Account Control) is useful for spotting odd names but rarely decides the case.

Computer accounts do not show up here. A machine joined to the domain logs 4741, so a flood of 4720s is always about user accounts.

What does Event ID 4732 mean?

4732 is "A member was added to a security-enabled local group." On a member server or workstation, that covers the local Administrators and Remote Desktop Users groups. On a domain controller, the built-in groups such as Administrators, Account Operators and Backup Operators are domain local groups, so additions to them also log 4732.

Domain Admins is a global group, though, and that change is 4728. Enterprise Admins and Schema Admins are universal groups and log 4756. If your alert only watches 4732, it misses the most valuable group in the domain.

How do I tell a legitimate account from a backdoor?

I check four things, in this order, because the first two settle most cases.

1. Who is the Subject? Your provisioning service account or a named helpdesk admin creating j.tan during office hours is routine. A regular user account, a service account that has never created anything before, or SYSTEM (a script or tool running as a service) deserves attention.
2. Is there a ticket or HR record? New hires come with a start date. Ask before you dig further; it often saves an hour.
3. How fast did the group change follow? A person using Active Directory Users and Computers takes a minute or more between creating an account and adding groups. A script like the one below does it in a second or two, from one Logon ID.
4. What does the name look like? Names that imitate built-in accounts (support, admin1, svc_backup when you have no such service) or end in $. An account named helpdesk$ is a normal user account, but net user hides it from its list, which is exactly why attackers like it.

A typical attacker sequence on a single host looks like this, and it produces a 4720 then a 4732 with the same Subject Logon ID:

net user helpdesk$ Winter2026! /add
net localgroup administrators helpdesk$ /add

Which 4720 and 4732 events are usually noise?

• Provisioning and IAM tools that create accounts on a schedule under one service account.
• Windows setup, which creates a temporary defaultuser0 account on new or reimaged machines.
• Device enrolment and join: joining a device to Entra ID adds administrator role SIDs to the local Administrators group, which can show up as 4732 during setup.
• Software installers for some backup, database and monitoring agents that create their own local accounts.

Rather than suppressing these by event ID, allow-list the specific Subject accounts that do them. That way the same event from anyone else still alerts.

How do I find who created the account and from where?

The Subject's Logon ID links the change to a logon session. Search for a 4624 on the same machine whose New Logon > Logon ID matches. That event gives you the logon type and the source IP, which tells you whether the creator was at the console, on RDP (type 10), or came over the network (type 3). The Windows logon types guide covers how to read those.

If the 4624 shows an internet IP, or the same account had a run of failures beforehand, follow the pattern in the Event ID 4625 guide: assume the creator's own credentials are compromised.

Hunting for new accounts and admin grants

First make sure the events are being logged at all. Both live under the Account Management category:

auditpol /get /category:"Account Management"

You want User Account Management and Security Group Management set to at least Success. Then pull the last week on a host with PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720,4728,4732,4756; StartTime=(Get-Date).AddDays(-7)} |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
      Time      = $_.TimeCreated
      Id        = $_.Id
      By        = $d.SubjectUserName
      LogonId   = $d.SubjectLogonId
      Target    = $d.TargetUserName   # new account (4720) or group (47xx)
      MemberSid = $d.MemberSid
    }
  } | Sort-Object Time | Format-Table -AutoSize

In Microsoft Sentinel, this query finds accounts that were created and then added to a group within ten minutes:

let created = SecurityEvent
| where TimeGenerated > ago(7d) and EventID == 4720
| project CreatedTime = TimeGenerated, CreatedOn = Computer, MemberSid = TargetSid, NewAccount = TargetAccount, CreatedBy = SubjectAccount;
SecurityEvent
| where TimeGenerated > ago(7d) and EventID in (4728, 4732, 4756)
| project AddedTime = TimeGenerated, AddedOn = Computer, MemberSid, Group = TargetAccount
| join kind=inner created on MemberSid
| where AddedTime between (CreatedTime .. CreatedTime + 10m)
| project CreatedTime, AddedTime, CreatedOn, AddedOn, NewAccount, Group, CreatedBy

It joins on the account's SID rather than the computer name, so it still matches when one domain controller created the account and another handled the group change.

On a single host, Get-LocalGroupMember -Group Administrators shows the current members. Compare it against what that server should have; an account the logs no longer cover can still be sitting there.

What to do if the account isn't legitimate

1. Disable it, don't delete it. Deleting removes the SID and attributes you will want for the timeline. Remove it from the privileged group at the same time.
2. Treat the creator as compromised. Reset the Subject account's password, revoke its sessions, and check where else that account logged on.
3. Check whether the new account was used. Search 4624 for the new account name across all hosts.
4. Look for the rest of the persistence. On the same host and time window: password resets (4724), account changes (4738), new services (7045) and scheduled tasks (4698).

FAQ

Why don't I see 4720 on my domain controller when I know an account was created?

Each DC only logs the changes it processed itself, so the event is on whichever DC handled the request. Check all of them, or forward them to one place. If none of them have it, the User Account Management audit subcategory is probably not enabled.

Does adding someone to Domain Admins log 4732?

No. Domain Admins is a global group, so the change logs 4728. Watch 4728, 4732 and 4756 together and filter on the group name or SID (Domain Admins ends in -512, Builtin Administrators is S-1-5-32-544).

Is 4732 for Remote Desktop Users worth alerting on?

It isn't admin rights, but it is new remote access, and attackers add accounts there to keep RDP access to a server. Treat it as medium priority, and as high if it's on a server exposed to the internet.

Do Entra ID or Microsoft 365 accounts create Event ID 4720?

No. Cloud-only accounts are created in Entra ID and logged in the Entra audit log as "Add user". Only accounts created in on-premises Active Directory or in a machine's local account database produce 4720.