Event ID 4732 is the Windows Security event logged when a member is added to a security-enabled local group, including the built-in Administrators group and domain-local groups on a domain controller. It records who made the change (Subject), which principal was added (Member SID) and which group received it, making it a primary privilege escalation signal.
Event ID 4732 comes from the Audit Security Group Management subcategory and fires every time a new member lands in a security-enabled local group. Microsoft's documentation states that it generates on domain controllers, member servers and workstations, and that every added member produces its own 4732. Add three users to a group in one PowerShell call and you get three events, each carrying one Member SID.
The phrase "security-enabled local group" trips people up. It does not mean "a group on a workstation". In Active Directory terms it means a group with the Security type (not Distribution) and Domain local scope. On a domain controller that covers plenty of high-value objects: the built-in Administrators group in the Builtin container, Account Operators, Server Operators, Backup Operators, Print Operators, Remote Desktop Users, and any domain-local group your team created to delegate rights on file shares or GPOs. The sample XML on Microsoft's own page is exactly that case: DC01.contoso.local logging a user being added to AccountOperators.
On a member server or workstation the same event covers the SAM-managed local groups, above all BUILTIN\Administrators. So one event ID spans two very different scopes, and the Group Domain field is how you tell them apart: it reads Builtin for a built-in group, the computer name for a machine-local group, and the domain name for a domain-local group defined in AD.
Two smaller behaviours are worth knowing before you build a rule. First, Microsoft notes you will typically see a 4735 (security-enabled local group was changed) with no visible changes immediately before the 4732; that is normal and not a second modification. Second, 4732 does not fire when a member is removed. The removal counterpart is 4733, so a group that was quietly emptied and refilled produces a pair, not a single event.
| Field | What it tells you | Simulated value |
|---|---|---|
SubjectUserSid | Security ID of the account that requested the add-member operation. In this event the Subject is the actor, not a system process. | S-1-5-21-424242-1050 |
SubjectUserName | Account Name of the account that requested the add-member operation. | adm.lopez |
SubjectDomainName | Account Domain of the Subject: domain NetBIOS or DNS name, the computer name for local accounts, or NT AUTHORITY for well-known principals. | corp.socsimulator.example |
SubjectLogonId | Logon ID, a hexadecimal session value that correlates this change to the Subject's 4624 logon event. | 0x4e1c7a |
MemberSid | Member Security ID: the SID of the account that was added to the group. The only reliable identifier of the new member. | S-1-5-21-424242-1342 |
MemberName | Member Account Name: distinguished name of the added account. For local groups this field typically contains a dash, even when the member is a domain account. | - |
TargetSid | Group Security ID: the SID of the group that received the new member. Built-in groups sit under S-1-5-32. | S-1-5-32-544 |
TargetUserName | Group Name of the group that received the new member, for example Administrators or ServiceDesk. | Administrators |
TargetDomainName | Group Domain: domain or computer name of the group; reads Builtin for built-in groups. | Builtin |
PrivilegeList | Privileges used during the operation, for example SeBackupPrivilege. Often not captured and shown as a dash. | - |
Click a field to inspect the full simulated value, the way you would expand it in a SIEM event view.
A representative Security entry for Event 4732, generated deterministically by our telemetry engine so every field holds a realistic, internally consistent value.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" />
<EventID>4732</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2025-01-16T05:52:55.000Z" />
<EventRecordID>143698</EventRecordID>
<Channel>Security</Channel>
<Computer>WS-SIM-001.corp.socsimulator.example</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-5-21-424242-1050</Data>
<Data Name="SubjectUserName">adm.lopez</Data>
<Data Name="SubjectDomainName">corp.socsimulator.example</Data>
<Data Name="SubjectLogonId">0x4e1c7a</Data>
<Data Name="MemberSid">S-1-5-21-424242-1342</Data>
<Data Name="MemberName">-</Data>
<Data Name="TargetSid">S-1-5-32-544</Data>
<Data Name="TargetUserName">Administrators</Data>
<Data Name="TargetDomainName">Builtin</Data>
<Data Name="PrivilegeList">-</Data>
</EventData>
</Event>Key on TargetSid, not the group name: Administrators is localised and renameable, the SID is neither.
index=wineventlog EventCode=4732 Group_Security_ID="S-1-5-32-544" | table _time, host, Account_Name, Account_Domain, Logon_ID, Member_Security_ID, Member_Name, Group_Name, Group_Domain
Lucene is the base filter; sequence 4720 to 4732/4728 on the SID in your SIEM. The join key is the 4720 TargetSid matched against the 4732 MemberSid.
index=wineventlog (EventCode=4720 OR EventCode=4732 OR EventCode=4728)
| eval member_sid=if(EventCode=4720, Group_Security_ID, Member_Security_ID)
| transaction member_sid maxspan=10m startswith=(EventCode=4720) endswith=(EventCode=4732 OR EventCode=4728)
| search Group_Security_ID IN ("S-1-5-32-544","S-1-5-32-555","S-1-5-32-551") OR Group_Security_ID="*-512"
| table _time, duration, host, member_sid, Account_Name, Group_Name, Group_Security_IDAllowlist by Subject SID rather than username so a renamed or lookalike account cannot slip through. Keep S-1-5-18 (SYSTEM) in the list only if you separately watch installer windows.
index=wineventlog EventCode=4732 | search NOT [| inputlookup approved_group_admins.csv | fields Security_ID] | stats count as additions values(Group_Name) as groups values(Member_Security_ID) as members min(_time) as first_seen by Account_Name, Account_Domain, Security_ID, host | sort - additions
Domain controllers, ADFS, PKI, backup and hypervisor hosts should see zero 4732 events outside a change record. Alert on presence, not on pattern.
index=wineventlog EventCode=4732 | search [| inputlookup frozen_membership_hosts.csv | fields host] | table _time, host, Account_Name, Logon_ID, Group_Name, Group_Security_ID, Group_Domain, Member_Security_ID
Adjust the 07:00 to 19:00 window and weekend days to your change policy. In Lucene the @timestamp range uses date math relative to the search day, so run it as a scheduled daily search.
index=wineventlog EventCode=4732 | eval hour=tonumber(strftime(_time,"%H")), dow=strftime(_time,"%a") | where hour<7 OR hour>=19 OR dow="Sat" OR dow="Sun" | table _time, host, Account_Name, Account_Domain, Group_Name, Group_Security_ID, Member_Security_ID
Most Windows audit events name a Subject that turns out to be SYSTEM or the machine account, and analysts learn to ignore it. 4732 is different. Subject Security ID, Account Name, Account Domain and Logon ID describe the account that requested the "add member to the group" operation, and unless the addition was made by an installer running as SYSTEM, that account is a person or a service credential someone controls.
Subject Logon ID is the field to keep. It is the same hexadecimal session identifier stamped on that account's 4624 logon, so pivoting on it gives you the logon type (interactive, RDP, network), the source workstation and the timestamp of the session that performed the change. If the Subject is a domain admin credential and the 4624 shows Logon Type 10 from an unmanaged IP at 02:00, you have your story before you read anything else.
Subject Account Domain tells you whether the operator was a domain principal, a local account on the box, or NT AUTHORITY. An addition to a server's Administrators group performed by a local account rather than a domain admin is unusual in a managed environment and deserves a question of its own.
The Member block has two fields and one well-known gotcha. Member Security ID is the SID of the principal that was added. Member Account Name is documented as the distinguished name of that principal, for example CN=Auditor,CN=Users,DC=contoso,DC=local, but Microsoft's page states plainly that for local groups this field typically contains "-", even when the new member is a domain account. The same dash appears for well-known principals such as LOCAL SERVICE or ANONYMOUS LOGON.
In practice that means a 4732 from a workstation or member server will tell you who was added only as a SID string like S-1-5-21-3457937927-2839227994-823803824-1104. Event Viewer resolves it for you when it can; your SIEM usually will not. If your parser maps MemberName to a "target account" column, a large share of your rows will simply say "-", and any rule keyed on a username will silently miss local-group additions.
The fix is a lookup at ingest or query time: enrich MemberSid against an AD export (objectSid to sAMAccountName) or, for machine-local accounts, against the host's SAM. Two SID shapes deserve attention on their own, no resolution needed. A RID of 500 on a domain SID is the built-in Administrator account. A SID from a domain other than your own, or from a workgroup machine, appearing as a Member on a domain-joined server means a foreign principal was granted local rights.
Group Security ID, Group Name and Group Domain identify the receiving group. In the XML these are TargetSid, TargetUserName and TargetDomainName, which confuses first-time readers because "Target" sounds like the account, not the group. Key your rules on TargetSid rather than the display name: names vary by locale (Administratoren, Administrateurs) and groups can be renamed, SIDs cannot.
The built-in groups all live under S-1-5-32 and their RIDs are fixed on every Windows installation, so this table is portable across your fleet:
| Group | SID | What membership grants an attacker |
|---|---|---|
| Administrators | S-1-5-32-544 | Full control of the host: credential dumping from LSASS, service installation, log clearing, disabling the EDR sensor. On a domain controller this is effective domain control. |
| Remote Desktop Users | S-1-5-32-555 | Interactive RDP logon without administrative rights. The quiet way to keep a foothold on a jump box or a server nobody rebuilds. |
| Backup Operators | S-1-5-32-551 | SeBackupPrivilege and SeRestorePrivilege: read any file regardless of ACL, including the SAM and SYSTEM hives on a member server or ntds.dit on a domain controller. |
| Power Users | S-1-5-32-547 | Largely legacy since Vista, but still an escalation path where old ACLs grant the group write access to Program Files or service binaries. |
| Remote Management Users | S-1-5-32-580 | WinRM and PowerShell Remoting access. Pairs with Administrators for fully scripted lateral movement, and is often left out of monitoring. |
| Distributed COM Users | S-1-5-32-562 | Permission to launch and activate DCOM objects remotely, which feeds DCOM-based lateral movement such as MMC20.Application abuse. |
| Account Operators | S-1-5-32-548 | On a domain controller: create and modify most user and group accounts. A stepping stone toward Domain Admins without touching that group directly. |
| Server Operators | S-1-5-32-549 | On a domain controller: log on locally, manage services and shares, back up and restore files. A swapped service binary here runs as SYSTEM on the DC. |
The first three rows are the ones to alert on immediately. Rows four through eight belong in a lower-severity hunt that runs daily. Group Domain reading Builtin is your cheap pre-filter: if the receiving group is not a built-in one, you are looking at a custom domain-local or machine-local group and need your own list of which of those carry privilege.
The event is written locally on whichever machine holds the group. A change to a workstation's Administrators group is logged on that workstation and nowhere else; if you do not forward Security logs from endpoints, you will never see it. A change to a domain-local group is logged on the domain controller that processed the write, not on every DC, so complete coverage means forwarding from all of them.
Windows splits group-membership auditing by scope, which is why three sibling events exist. 4732 covers local scope. 4728 covers security-enabled global groups, which is where Domain Admins lives. 4756 covers security-enabled universal groups, where Enterprise Admins and Schema Admins live in a multi-domain forest. They share the same field layout, so one parser and one SID lookup serve all three, but a rule that only watches 4732 will never see a Domain Admins addition, and a rule that only watches 4728 will never see local Administrators. Cover all three in the correlation rule, then split alert severity by TargetSid.
Volume varies wildly by environment. Legitimate sources of 4732 are easy to enumerate: software installers that add a service account to Administrators or Distributed COM Users during setup, imaging and provisioning pipelines that stamp a management account onto every new build, LAPS or privileged-access tooling that adds and later removes a just-in-time admin, and helpdesk staff granting Remote Desktop Users to a contractor for a week. Each of these has a recognisable Subject: an installer runs as SYSTEM or a deployment service account, imaging happens from a known server during a known window, and helpdesk additions come from named helpdesk identities.
The false positive population is therefore not "any 4732" but "4732 whose Subject, host and group all match a known workflow". Build that allowlist as tuples, not as three independent lists. A helpdesk technician adding someone to Remote Desktop Users on a workstation is a match; the same technician adding a member to Administrators on a domain controller is not, even though each individual value would pass a one-column allowlist.
The true positive signals stack in a familiar order. A Subject that has never performed a group change before. A Member SID that resolves to an account created minutes earlier, or to an account in a domain you do not trust. A receiving group of Administrators, Backup Operators or Remote Desktop Users on a server whose membership has not changed in months. A timestamp outside the change window. Any two of these together justify a ticket; three justify isolating the host.
One caution on the other side: a 4732 where the Subject is SYSTEM and the Member is a service SID such as NT SERVICE\MSSQLSERVER during a documented install is the most common benign pattern and the most common source of alert fatigue. Suppress by Subject SID S-1-5-18 plus a known installer window rather than by suppressing the group.
At 23:41 a file server, FS-PROD-02, logs 4720: local account svc_backup2 created, Subject jmorales.adm. At 23:45 the same host logs 4732: MemberSid ending in -1012, MemberName "-", TargetUserName Administrators, TargetSid S-1-5-32-544, TargetDomainName Builtin, Subject again jmorales.adm, SubjectLogonId 0x8f2c41.
The correlation query below fires on the 4720-to-4732 pair inside a ten-minute window. Triage runs in order: resolve the Member SID (RID 1012 matches the TargetSid of the 4720, so it is the new account), pivot on SubjectLogonId 0x8f2c41 to the 4624 (Logon Type 10, source IP from the VPN pool, session started 23:38), then check the change queue (no ticket for FS-PROD-02, and jmorales is on leave). The name svc_backup2 sits one character away from the real svc_backup, which is the naming trick that survives a glance at Computer Management.
Verdict: true positive, credential compromise plus persistence through a local admin account (T1078 for the stolen credential, T1098 for the group manipulation). Response: disable svc_backup2, reset jmorales.adm, pull the 4624 source IP through the VPN logs, and check every other host for 4732 events with the same SubjectLogonId or the same MemberSid pattern, because an attacker who scripted this once did not stop at one server.
Event 4732 telemetry feeds detections for these ATT&CK® techniques:
Reading about a member was added to a security-enabled local group is one thing. Working the detection inside a live console is another. These free SOCSimulator operations cover the attack techniques Event 4732 helps you detect:
A finance analyst's Microsoft Entra account is accessed without MFA from Moldova 18 minutes after their normal London sign-in. Impossible travel confirmed. The unauthorized session reads the inbox via Graph and adds an external recovery address. Work the Entra audit trail to identify the attacker IP, the compromised mailbox, and the persistence mechanism.
Investigate an adversary-in-the-middle (AiTM) credential phishing campaign that lured an employee to a lookalike Microsoft 365 login page. Working entirely from SIEM logs, you will identify the lookalike domain, reconstruct the multi-hop redirect chain through a compromised legitimate site, uncover a secondary phishing wave against another employee, and confirm account takeover in Azure AD sign-in logs via impossible travel and session-token replay. You finish by choosing the containment action that actually evicts an attacker holding a valid session token. Foundational skills for SOC analysts in lookalike-domain analysis and identity-centric incident response.
The file-transfer portal that Tideglow Logistics' partners upload to spent a morning returning host files it was never meant to publish, and finished it running an administrator session nobody had logged into. The root cause is CVE-2024-4040 in CrushFTP 10.6.0. Walk the access logs and firewall traffic step by step to trace how a client holding no credentials turned a request parameter into a read of the host, and that read into a takeover.
“Official description, subcategory (Audit Security Group Management), generation scope (DCs, member servers, workstations), one event per member, the 4735 pre-event, the field descriptions including the Member Account Name dash behaviour for local groups, and Microsoft's security monitoring recommendations.”
“T1098 (Account Manipulation) is the ATT&CK technique covering the modification of group membership to maintain or elevate access; the 4732 detection guidance maps to it.”
“Well-known SID reference for the BUILTIN groups under S-1-5-32 (Administrators 544, Power Users 547, Account Operators 548, Server Operators 549, Backup Operators 551, Remote Desktop Users 555, Distributed COM Users 562, Remote Management Users 580) used in the group reference table.”
“Current #1 SERP result; used to establish the coverage gaps listed in information_gain (no queries, no correlation, no SID capability table).”
Event ID 4728 fires when someone joins a security-enabled global group. Learn to catch Domain Admins additions and the a…
Read more Event IDEvent ID 4723 fires when a user changes their own password. Learn the difference from 4724, the Audit Failure signal, an…
Read more Event IDEvent ID 4724 fires when someone resets another account's password. Learn the Subject/Target fields, the 4724 vs 4723 di…
Read more GlossaryPersistence is the set of techniques an adversary uses to keep access to a compromised system after whatever gave them t…
Read more GlossaryThe principle of least privilege states that users, processes, and systems should hold only the minimum access rights re…
Read more GlossarySecurity Information and Event Management (SIEM) is a platform that aggregates, normalizes, and correlates log data from…
Read more Career PathTier 1 SOC Analysts are the front line. You monitor alert queues, triage incoming detections, classify them as true or f…
Read more Career PathIncident Responders lead the technical response when confirmed breaches happen. You coordinate containment, run forensic…
Read more TechniqueAccount Manipulation keeps an already-compromised account usable by changing its properties rather than creating a new o…
Read more TechniqueValid Accounts is among the hardest abuses to spot because nothing is technically broken, the adversary simply authentic…
Read more ComparisonSOCSimulator wins on operational realism. You get multi-tool shift simulation with SLA pressure, noise injection, and al…
Read more Event IDWindows Security and Sysmon event IDs with simulated log samples, field tables, and tested detection queries.
Read more