Detecting Unauthorized Group Membership Changes via Privilege Escalation Audit Logs

Why This Matters

Adding an account to a privileged group is one of the simplest and most persistent forms of privilege escalation available to an attacker. On Linux, membership in the docker, sudo, adm, or wheel group can provide a trivial path to root. On Windows, membership in Administrators, Domain Admins, or Remote Desktop Users grants broad access that may persist indefinitely if not detected. Because group membership changes are recorded in specific event IDs and log lines, they are highly detectable — the challenge for analysts is ensuring that the detection coverage exists and that alerts are acted upon promptly.

Core Concept

Group-based privilege escalation occurs when an attacker adds a controlled account to a privileged group, gaining capabilities associated with group membership rather than the account's baseline permissions. This is distinct from SUID exploitation or sudo abuse because the elevated access is persistent — the account retains group membership across sessions until explicitly removed.

Linux indicators: - /etc/group modification: the file's mtime changes. diff /etc/group /etc/group.bak reveals additions. - usermod -aG <group> <user> appears in bash history (if not cleared), process logs, or auditd execve records. - auditd: -w /etc/group -p wa -k group_change records all writes to /etc/group with the responsible process. - getent group sudo docker wheel adm shows current group membership for comparison against baseline.

Windows indicators: - Event 4728: A member was added to a security-enabled global group (e.g., Domain Admins) - Event 4732: A member was added to a security-enabled local group (e.g., Administrators) - Event 4756: A member was added to a security-enabled universal group - All three events record: SubjectUserName (who made the change), MemberSid (the added account), and GroupName.

Technical Deep-Dive

# Linux: detect /etc/group modification via auditd
# Rule to add to /etc/audit/rules.d/groups.rules:
# -w /etc/group -p wa -k group_change
# -w /etc/gshadow -p wa -k group_change

ausearch -k group_change --interpret | grep -A10 "type=PATH"

# Manual comparison against baseline snapshot
diff <(sort /etc/group.baseline) <(sort /etc/group) 
  | grep "^>" | grep -E ":(sudo|docker|wheel|adm|root):"

# Check current members of high-privilege groups
for group in sudo docker wheel adm lxd disk video; do
  members=$(getent group $group | cut -d: -f4)
  [ -n "$members" ] && echo "$group: $members"
done

# Linux: search bash history for usermod/gpasswd invocations
grep -r "usermod|gpasswd|adduser.*sudo|adduser.*docker" 
  /root/.bash_history /home/*/.bash_history 2>/dev/null

# auditd: correlate execve records with /etc/group write
ausearch -k group_change --interpret 
  | grep -E "(usermod|gpasswd|adduser|addgroup)"

-- Splunk: detect Windows group membership additions (4728, 4732, 4756)
index=wineventlog EventCode IN (4728, 4732, 4756)
| eval group_type = case(
    EventCode=4728, "Global Security Group",
    EventCode=4732, "Local Security Group",
    EventCode=4756, "Universal Security Group"
  )
| where match(Group_Name, "(?i)(admin|domain admin|enterprise admin|remote desktop|backup operator)")
| table _time ComputerName SubjectUserName Group_Name MemberSid group_type
| sort _time

-- Splunk: alert on Docker group additions (common Linux privesc via SIEM-forwarded syslog)
index=syslog "usermod" "docker"
OR (index=syslog "gpasswd" "-a" "docker")
| table _time host _raw
| sort _time

Analytical Methodology

1. On Windows: search for Events 4728, 4732, and 4756 across all domain controllers for the investigation period. Focus on additions to Administrators, Domain Admins, Enterprise Admins, Schema Admins, Backup Operators, and Remote Desktop Users.
2. For each group addition event, identify: the SubjectUserName (the account that made the change), the MemberSid (the account added), and the GroupName. Resolve MemberSid to account name.
3. Verify whether the SubjectUserName is authorised to modify group membership. Unauthorised group changes by a standard user account indicate prior privilege escalation.
4. Pivot to the SubjectUserName's recent activity: what did this account do before making the group change? Look for credential dumping, LSASS access, or unusual logon events preceding the group modification.
5. On Linux: query auditd for /etc/group write events (-k group_change). Identify the calling process UID and parent process. If the modification was made by a shell process owned by a non-root user, escalation is confirmed.
6. Examine bash history files for all users on the compromised host. usermod -aG sudo <attacker_account> is a one-liner that leaves a permanent trace in history unless the attacker explicitly deleted it.
7. Compare the current /etc/group against the baseline (from backup, configuration management, or a known-good image snapshot). Every added member that is not in the baseline is a finding.
8. Determine whether the group addition was used: check auth.log for sudo commands, su transitions, or Docker container launches from the added account after the membership change.

Common Analytical Errors

• Only monitoring Domain Admins: Attackers often add accounts to less-watched privileged groups (Backup Operators, Print Operators, Account Operators) that provide sufficient access for their objectives without triggering Domain Admins alerts.
• Ignoring Linux local groups: The docker group provides root-equivalent access via docker run -v /:/host --privileged. Not all organisations monitor docker group membership changes, yet it is a trivial escalation path.
• Not correlating the SubjectUserName back: The account that made the group change may itself be compromised. Investigating only the added account misses the true attacker account.
• Overlooking nested group membership: On Windows, an attacker may add an account to a group that is itself a member of Administrators (nested group). Event 4728/4732 records only the direct addition; nested effective permissions require graph analysis of group memberships.

NICE Framework Alignment

Further Reading

• MITRE ATT&CK T1098: Account Manipulation — group membership sub-technique
• Linux man page: usermod(8), gpasswd(8) — command syntax and log footprint
• Microsoft Docs: Monitoring Active Directory for Signs of Compromise — group change monitoring section
• CIS Benchmarks for Linux and Windows — privileged group baseline membership controls
• Elastic detection rules: "User Added to Privileged Group" (GitHub elastic/detection-rules)