Event ID 4799: A security-enabled local group membership was enumerated

Event 4799 fires whenever a process lists the members of a specific security-enabled local group, most commonly the built-in Administrators group. The direction of the query is the entire distinction from its sibling event, 4798: here, TargetUserName identifies the group being inspected, Administrators, Remote Desktop Users, Backup Operators, or any other local group, while 4798's TargetUserName identifies a user account instead. Confusing the two fields' meaning across the two events is the single most common mistake analysts make when working with this pair.

SubjectUserSid, SubjectUserName, and SubjectLogonId identify who ran the enumeration, correlating back to that Subject's own 4624 logon. TargetSid carries the group's SID, and for built-in groups this SID sits under the well-known S-1-5-32 prefix, S-1-5-32-544 for Administrators specifically, a value stable across every Windows machine regardless of hostname or domain. CallerProcessId and CallerProcessName name the executable performing the query, the same field that carries the real detection value for 4798 and does so again here.

As with 4798, this event fires constantly from entirely benign sources: management agents checking local admin membership as part of routine compliance reporting, installer packages verifying the current user's privilege level, and legitimate administrators using net localgroup administrators for ordinary troubleshooting. Raw occurrence tells you almost nothing; CallerProcessName, target-group sensitivity, and enumeration breadth are what turn this into a usable signal.

The Administrators group specifically deserves elevated scrutiny compared to lower-privilege local groups, since knowing exactly who holds local admin rights on a given host is precisely the reconnaissance question an attacker needs answered before deciding whether that host is worth escalating on or moving laterally from. A query against Administrators from a known recon binary, net.exe, net1.exe, an interactive PowerShell session, on a host where that kind of manual enumeration is not part of normal operations is a meaningfully stronger signal than the same query against a lower-sensitivity group like Remote Desktop Users.

Breadth works the same way it does for 4798, inverted to groups instead of users: one Subject account enumerating many distinct local groups in a short window is a systematic mapping pattern with little ordinary operational justification, since a legitimate administrator troubleshooting a specific access problem typically checks one or two groups relevant to that problem, not a sweep across every group defined on the host.

The pattern unique to this event, and the highest-confidence signal on this page, is temporal correlation with an actual privilege change: a 4799 against Administrators followed within minutes by a 4732, member added to a local group, for the same Subject account. That sequence, enumerate the target group, then add a member to it, is the natural shape of active privilege-escalation staging rather than passive discovery, and it is detectable only by joining this event against its downstream sibling rather than looking at either in isolation.

Treat raw 4799 volume the same way you would 4798's: as background noise that any per-event alert will drown in. The signal lives in three layers stacked together, CallerProcessName, target-group sensitivity, and enumeration breadth, and the strongest confirmatory layer, correlation with a subsequent group-membership change, sits on top of all three.

CallerProcessName narrows meaningfully without resolving the question alone. net.exe, net1.exe, and interactive PowerShell sessions appearing in this field on a workstation used for routine administration are unremarkable; the same processes appearing on a server that should only ever see automated management-agent queries, or appearing from an account that does not normally perform manual command-line administration, is worth a closer look regardless of which specific group was queried.

Target-group sensitivity should drive your alerting tier the same way Target-account sensitivity drives 4725's. Enumeration of Administrators and any other group with meaningful local privilege deserves tighter scrutiny than enumeration of low-privilege groups like Users or Guests, and any environment doing this well maintains an explicit tier list rather than treating every local group identically.

Breadth catches the sweep pattern: one Subject account querying many distinct local groups across many hosts, or many distinct groups on one host, in a tight window has little benign equivalent at the volume a scripted discovery tool produces. Baseline against your own admin team's normal troubleshooting cadence, since a busy help-desk workstation used by several technicians will naturally show higher raw counts than a single end-user machine, and the anomaly is in the shape of the sweep, not the absolute number.

The enumerate-then-add correlation is close to a standalone true-positive indicator on its own. Legitimate administrators occasionally check current membership before adding someone, but the combination of checking Administrators specifically and then adding a member for the same Subject within a short window, especially when that Subject is not on your list of accounts authorized to manage local admin rights, should be treated as active privilege-escalation staging until the specific change is confirmed as expected. False positives here are rare enough that the correlation query alone, run continuously, is one of the higher-value additions a SOC can make to its account-management detection coverage without needing extensive baseline tuning first.