Event ID 4799 records enumeration of a security-enabled local group’s membership. Attackers may use it to map privileges before lateral movement or escalation. Check the process name, process ID and account name to see which tool performed the query, and treat unexpected enumeration on sensitive systems as suspicious.
What Event ID 4799 actually tells you
Event ID 4799 is most useful as an early warning that someone queried local group membership on a Windows system. That activity is often legitimate administration, but it is also a common way to map privileges, identify useful groups, and prepare for later movement or escalation. The key question is whether the query fits the normal admin pattern for that host.
Because the event is about enumeration rather than direct modification, the context matters more than the code itself. A single check on a management server may be benign, while repeated or unexpected queries on sensitive endpoints, jump hosts, or domain-adjacent systems can indicate reconnaissance. Correlate the event with nearby logons, process creation, and remote access patterns before deciding whether it is routine.
The most important detail is attribution. The process name, process ID, and account name show which tool and which identity performed the query, which helps separate expected administrative activity from abuse. That makes Event ID 4799 valuable for triage, but only when you validate the source of the lookup against the system’s normal administrative workflow.
How attackers use local group enumeration
Attackers commonly enumerate group membership to understand where privilege exists, who belongs to high-value groups, and which accounts might be usable for lateral movement or escalation. Local group data can reveal whether the current host contains privileged operators, backup operators, remote management groups, or application-specific access that may be worth targeting next.
On its own, enumeration does not prove compromise. The signal becomes stronger when the event is paired with suspicious logons, service creation, remote execution, PowerShell activity, or other discovery steps that show an operator building a map of the environment. For Windows event interpretation, the broader Windows Event Log Guide is the best companion reference because it places Event ID 4799 in the context of related account, logon, and service events.
Event ID 4799 should also be read alongside endpoint telemetry if you have it. A tool that enumerates groups through a scripting host, admin console, or remote management channel may leave a clearer behavioral trail in process or PowerShell logging than in the Windows security log alone. The PowerShell Security Guide helps when the query is launched through PowerShell-based tradecraft.
What to verify before you treat it as hostile
First confirm whether the host is supposed to receive administrative enumeration at that time. If the system is a workstation, server with restricted administration, or a sensitive asset that should not be used for ad hoc discovery, the threshold for concern is lower. Then compare the account name and process path against your approved management tools, scripts, and operator accounts.
Next look for clustering. One event may be harmless, but repeated local group queries across multiple hosts, especially with the same account or from the same process family, can indicate reconnaissance at scale. If you have Sysmon, validate whether the same process also shows related process creation, network connections, or parent-child chains that reveal how the activity started. The Sysmon Guide is useful here because it links Windows security events to higher-fidelity endpoint observations.
Finally, determine whether the queried group is actually sensitive. Enumeration of local administrators, remote desktop users, backup operators, or delegated support groups is materially more important than casual checks on low-risk systems. If the event occurs on a crown-jewel host or a jump server, treat it as a stronger indicator of privilege discovery and review whether the account has already been used elsewhere.
Risk and Threat Considerations
Local group enumeration is risky because it helps an attacker reduce uncertainty before choosing a target, escalating privileges, or moving laterally. The event is often quiet, low-noise, and easy to blend into normal administration, so it can be a useful reconnaissance step even when no direct change is made.
Failure mechanism: An adversary or insider with some access queries group membership to identify privileged accounts, trust relationships, and reusable access paths, then combines that knowledge with a separate credential or remote-execution opportunity.
Impact: The result can be faster privilege escalation, better lateral movement decisions, and more targeted abuse of administrative groups, especially when enumeration occurs on systems that should not be used for ad hoc discovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1069.001 — Permission Groups Discovery: Local Groups | Local group enumeration maps directly to this discovery technique. |
| Recommendation — Map Event ID 4799 to T1069.001 and hunt for follow-on privilege and lateral-movement activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Event 4799 is only useful if audit records are reviewed and correlated for suspicious enumeration. |
| Recommendation — Review 4799 alongside adjacent audit records to identify anomalous group discovery. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | This event depends on collecting and retaining endpoint audit logs for later investigation. |
| Recommendation — Centralize and retain Windows security logs so 4799 can be investigated in context. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | The question is about interpreting security telemetry and validating suspicious activity. |
| Recommendation — Ensure security events are logged with enough context to attribute enumeration to a process and account. | ||
Practitioner Guidance
What to prioritise: Treat the process name and account name as the primary triage anchors, not the event code alone. If the process is unknown, unsigned, or unexpected for the host, escalate faster than you would for a familiar admin tool.
What to verify: Confirm whether the querying account, source host, and process lineage match an approved administrative workflow. If they do not, review nearby logons, remote management activity, and any later privilege-bearing actions on the same system.
Practitioner takeaway: Event ID 4799 is a reconnaissance signal, not a compromise verdict, so the right response is to validate whether the enumeration fits the host, the operator, and the surrounding activity pattern before you dismiss or escalate it.