When is Event ID 4799 logged?

What Event ID 4799 tells you about local group activity

Event ID 4799 is an audit signal for local group enumeration, so its value is less about a single login event and more about detecting who is looking at group membership on the endpoint. That makes it useful for spotting discovery activity against administrative or other security-sensitive local groups, especially when the process is unfamiliar or the timing does not match normal administration.

The event is generated in the Security log, which means your first check should be whether auditing is actually enabled for security group management on the host. If the log exists but the audit policy is off, you will miss the telemetry entirely. For investigation, the most important fields are the group name, the process name, and the process ID, because those three together connect the enumeration to the actor that performed it.

To read the event correctly, separate local endpoint enumeration from directory-based administration. The direct answer already notes that Event ID 4799 is not logged for enumeration through Active Directory Users and Computers, so the event should be treated as host-local evidence rather than a universal signal for every group browse operation. That distinction matters when you are correlating security logs with administrative tooling and trying to decide whether the activity was routine or more suspicious.

Why 4799 matters for reconnaissance and privilege discovery

Local group membership is a small but valuable map of who can administer the system, run privileged tasks, or inherit sensitive access paths. Enumeration of those members can be a low-noise reconnaissance step before lateral movement or privilege escalation, because it helps an operator identify which accounts or processes are worth targeting next. On a hardened endpoint, repeated or unexpected enumeration attempts deserve attention even when no other obvious abuse is visible.

Operationally, the signal is strongest when the enumerating process does not match the expected admin workflow, when the same host is queried repeatedly, or when the group being enumerated is privileged enough to influence local control. A single event is not proof of compromise, but it can be an early sign that an attacker or insider is mapping the environment before taking the next step.

For defenders, this event is most useful when paired with related Windows auditing and process telemetry. The Windows Event Log Guide gives the broader auditing context needed to interpret 4799 alongside other account and process events, while the Sysmon Guide helps when you want richer process visibility around the executable that performed the enumeration.

How to investigate and tune detection for 4799

Start by validating whether the host should ever generate this event under normal operations. Domain-admin workflows, helpdesk tooling, and scripts can legitimately enumerate local group membership, but they should do so from known management paths and known process names. If the source process is unfamiliar, unsigned, or spawning from an unexpected parent, treat the event as a lead rather than a benign audit artifact.

Then correlate the process ID with surrounding process creation, command-line, and logon activity so you can determine who launched the process and from where. That correlation is often the difference between a useful detection and an isolated log line. If you already collect PowerShell telemetry, the PowerShell Security Guide is especially relevant when the enumeration was driven by administrative scripting rather than a graphical tool.

Finally, make sure the audit configuration is intentional. If you are not collecting Security Group Management events consistently across your fleet, 4799 will be uneven and hard to trust for detection engineering. Strong detections usually combine the event itself with allowlisted admin tools, known maintenance windows, and endpoint context so you can suppress routine activity without blind spots.

Practitioner Guidance

What to verify: Confirm that the host is actually logging Security Group Management events and that the enumerating process aligns with an approved administrative path before you suppress the alert.

Decision rule: If 4799 comes from an unexpected process or appears on a sensitive endpoint outside normal admin activity, treat it as reconnaissance and check for adjacent process creation, logon, and privilege events.

What good looks like: Known administration tools generate the event in predictable maintenance windows, while unfamiliar processes are rare, explainable, and tied to approved change activity.

Practitioner takeaway: Event ID 4799 is most valuable when you use it as process-linked reconnaissance evidence, not as a standalone sign of compromise.

Related resources from NHI Mgmt Group

• What makes Shai Hulud 2.0 different from a normal npm malware event?
• When is Event ID 4624 logged?
• When is Event ID 4648 logged?
• When is Event ID 4625 logged?