Event ID 4798: A user's local group membership was enumerated

Event 4798 fires whenever a process asks Windows which local groups a specific user account belongs to. That question gets asked constantly by entirely benign machinery: logon processing itself checks group membership to build the user's access token, management agents check it as part of routine health reporting, and countless application installers and configuration tools query it in passing. The result is one of the highest-volume, lowest-signal-per-occurrence events in the entire Security log on a healthy host.

SubjectUserSid, SubjectUserName, and SubjectLogonId identify the account under whose session the enumeration ran. TargetUserName and TargetSid identify the account whose local group memberships were listed, the account being inspected, not the one doing the inspecting. CallerProcessId and CallerProcessName are the two fields that actually make this event usable: they name the specific executable that performed the query, and that is the only practical way to separate a system health check from a reconnaissance script.

Because raw volume is meaningless here, detection has to start from the process, not the event. A small set of tools shows up disproportionately in real-world enumeration abuse: net.exe and net1.exe, the classic net user command-line path, whoami.exe, particularly whoami /groups, and PowerShell sessions invoking equivalent .NET membership APIs. None of these are inherently malicious; system administrators use them constantly for entirely legitimate troubleshooting. What matters is the context around the call, not the call itself.

The single most useful pattern to build detection around is breadth: one Subject account enumerating the local group membership of many distinct Target accounts within a short window. A legitimate administrator troubleshooting a specific user's access checks that one user, maybe a handful if the ticket touches multiple accounts. A discovery script or an attacker mapping the environment after an initial foothold checks dozens, systematically, often alphabetically or against a harvested list of usernames, a shape that has no ordinary operational reason to occur.

Target sensitivity compounds the breadth signal. Enumeration of a privileged or service account's group membership by an account outside your designated help-desk or IT-admin group is worth flagging even in isolation, since the only realistic legitimate reason to check a service account's local group memberships is troubleshooting by someone specifically responsible for that system, a narrow population that should already be known and allowlisted.

MITRE catalogs this behavior under T1069, Permission Groups Discovery, one of the standard early steps in an intrusion where an attacker who has landed on a host tries to understand what access is actually available before deciding where to move next. 4798 covers the user-centric direction of that discovery question; its sibling event, 4799, covers the same discovery goal from the opposite direction, listing who belongs to a specific group rather than what groups a specific user belongs to.

Given how constantly this event fires from routine system activity, the honest starting point is that the overwhelming majority of 4798 events on any host are not worth an analyst's attention individually, and any detection strategy that tries to alert on raw occurrence will drown in noise within hours. Real signal requires narrowing to CallerProcessName, volume shape, and target sensitivity together, not any one of them alone.

CallerProcessName narrows the field meaningfully but does not resolve it on its own. Seeing net.exe or whoami.exe in this field is common during legitimate troubleshooting, scripted health checks, and countless management-tool workflows; it becomes worth a closer look specifically when it appears on a host or from an account where that kind of manual command-line troubleshooting is unusual, for example a database server that should only ever see automated management-agent queries, never an interactive net.exe invocation.

The breadth pattern, one Subject sweeping many Target accounts in a short window, is the strongest independent signal this event offers, because it has almost no benign equivalent at scale. A single administrator troubleshooting a handful of tickets in a day produces a low, irregular count; a discovery script produces a rapid, mechanical count against many accounts in a tight time window. Set the volume threshold against your own environment's baseline rather than a fixed number, since a shared IT-admin workstation used by a busy help-desk team will naturally run higher than a typical end-user machine.

Enumeration of a privileged account's memberships by a non-admin account is the clearest individual true-positive shape available from this event, since there is rarely a legitimate reason for a standard user session to be checking a service account's group memberships at all. Pair this check against your existing privileged-account inventory and an allowlist of accounts authorized to administer those systems, and the false-positive rate on this specific pattern should be close to zero.

The pattern to watch for as an escalation trigger, not just a discovery signal, is a 4798 sweep followed shortly afterward by an actual privilege-relevant action, a group-membership change, a password reset, or a new logon type the Subject account has not used before. Discovery alone is common and often benign; discovery immediately followed by action against one of the specific accounts or groups just enumerated is the correlation that turns a noisy, low-priority event into a genuine indicator worth immediate review.