Event ID 4732 is logged in the Security log each time a member is added to a security-enabled local group. One event is written per added member, and it records the group, the new member, and the account that made the change. Enable Audit Security Group Management.
The Security log records Event ID 4732 when a security-enabled local group gains a new member. The event is written once for each added member and includes the target group, the member added, and the account that made the change. Because this is an audit event, the key control question is whether group management changes are being captured reliably.
What Event ID 4732 Tells You About Local Group Change Activity
Event 4732 is a membership change record, not a general permissions record. It is most useful when you want to prove that a local group was modified, who performed the change, and which principal was added. In practice, that makes it an audit trail for privileged access drift, local administrator exposure, and unexpected local group expansion.
Local groups are often used to control access on workstations and servers, so even a single added member can meaningfully alter the security posture of the host. If the group is privileged, the event becomes a high-value signal for change tracking, incident review, and baseline comparison. If the group is non-privileged, it still matters because it can reveal abuse of local trust paths or mismanaged administrative processes.
One useful way to read the event is as a three-part fact pattern: the group, the new member, and the actor that made the change. That combination helps separate legitimate administration from unauthorized modification, especially where local admin rights are already broad and poorly documented. It also helps investigators reconstruct whether the change was manual, scripted, or part of a wider administrative workflow.
Why the Audit Setting Matters for Seeing It
Event 4732 depends on audit collection being enabled for security group management. Without that policy, the change may still occur, but it will not produce the record you expect in the Security log. That means detection gaps are often configuration gaps rather than logging product failures.
For defenders, the practical issue is not just whether the event exists in theory, but whether the environment consistently emits it across all relevant hosts. Missing audit coverage on a single server can leave an important blind spot if an attacker or insider uses local group changes to broaden access. If your monitoring program relies on this event, verify that the audit policy is actually applied where local group changes matter most.
How to Use Event 4732 in Investigation and Monitoring
Event 4732 is most valuable when correlated with adjacent account-management and logon activity. A sudden local group addition paired with a new logon session, an unexpected administrative action, or a change outside normal maintenance windows is often more informative than the event alone. The event should therefore be treated as a pivot point, not a complete conclusion.
It is also useful for detecting unauthorized privilege creep over time. Repeated local group additions, especially to built-in administrator-style groups, may indicate weak change control, overuse of local admin rights, or an attempt to preserve access after compromise. If the added member is a service account, review whether that account actually needs interactive or local administrative access.
For teams that centralize Windows telemetry, Windows Event Log Guide is a useful companion for understanding where Event ID 4732 sits among other account and group management events. If you also want host telemetry that can complement Windows Security logging, the Sysmon Guide helps with collection, filtering, and SIEM forwarding. For activity that may have been driven from the shell, the PowerShell Security Guide gives the logging context that often helps explain how the change was made.
Risk and Threat Considerations
Local group membership changes can be a fast path to privilege expansion on a Windows host. If an attacker, insider, or compromised admin account can add a member to a privileged local group, the resulting access may be enough to tamper with the system, stage further tooling, or hide follow-on activity. The risk is highest where local admin use is routine and review is weak.
Failure mechanism: Abuse of local administrative rights or stolen credentials allows an actor to add an account, service account, or backdoor principal to a security-enabled local group, creating durable access that may persist until someone reviews the membership.
Impact: The host can move from controlled administration to unauthorized privilege, which may enable persistence, data access, defense evasion, or lateral movement if the same credentials or group pattern is reused elsewhere.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Event 4732 is a Security log audit event and needs defined logging coverage. |
| AU-6 — Audit Record Review, Analysis, and Reporting | The event is only valuable when membership changes are reviewed for anomalies. | |
| AC-2 — Account Management | Local group membership changes directly alter account access and privilege. | |
| Recommendation — Define audit events for local group changes and ensure they are captured consistently. Review local group change events for unexpected or privileged additions. Restrict and monitor group membership changes through formal account management. | ||
Practitioner Guidance
What to verify: Confirm that Event 4732 is enabled wherever local group membership matters, and verify that the Security log is forwarded so the event is not trapped on the endpoint. Also check that the event includes enough context in your pipeline to identify the target group, the added member, and the actor without manual logon tracing.
Decision rule: If the target group is privileged, treat the event as a security-relevant change and review it immediately. If the group is non-privileged but the member is unusual, review it as a potential misconfiguration or misuse of delegated administration rather than dismissing it as routine.
What good looks like: Group membership changes are rare, intentional, and traceable to approved change records. The team can quickly answer who changed the group, why it changed, and whether the new member was expected for that host and role.
Practitioner takeaway: Event 4732 is only useful when it is both collected and operationally reviewed, because the real control value comes from detecting unexpected local privilege expansion before it becomes persistence.