Correlating Audit Events Across Linux and Windows Privilege Escalation Transitions

Why This Matters

Privilege escalation converts a low-value compromise (a standard user account, a web shell running as www-data) into high-value control (root, SYSTEM, Domain Admin). The Uber breach of 2022 progressed from a contractor account compromise to full administrative access in part because privilege escalation artefacts in logs went unnoticed. Recognising the event IDs and log entries that mark the boundary between normal and privileged operation — on both Windows and Linux — is one of the most operationally important skills in SIEM-based detection work.

Core Concept

Privilege escalation in logs manifests differently across operating systems but follows the same pattern: a process or user account obtains capabilities exceeding its authorised baseline. Key indicators:

Windows: - Event 4672 (Special Privileges Assigned to New Logon): generated when an account logs on with sensitive privileges such as SeDebugPrivilege, SeTcbPrivilege, or SeTakeOwnershipPrivilege. These privileges allow process injection, credential dumping, and arbitrary file access respectively. - Event 4688 (A new process has been created): with process command-line auditing enabled, reveals privilege-escalating tool execution (whoami, net user, reg.exe touching sensitive keys). - Event 4728/4732/4756 (Member added to security group): an account added to Administrators, Domain Admins, or Schema Admins indicates privilege escalation via group membership manipulation.

Linux: - /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS): records sudo commands, su attempts, and PAM authentication events. - auditd: kernel-level audit framework. Rules defined in /etc/audit/rules.d/ record syscalls, file accesses, and command executions. Key syscalls: setuid, setgid, execve. Key files: /etc/sudoers, /etc/passwd, /etc/shadow.

Technical Deep-Dive

# Linux: examine sudo usage from auth.log
grep "sudo:" /var/log/auth.log | grep -v "pam_unix"
# Shows: user, TTY, PWD, command executed

# auditd: watch for setuid/setgid syscalls
# Add to /etc/audit/rules.d/privesc.rules:
# -a always,exit -F arch=b64 -S setuid -S setgid -F auid!=4294967295 -k privesc
ausearch -k privesc --interpret | head -40

# auditd: watch for execve of known escalation paths
ausearch -k exec_su_sudo --interpret 
  | grep -E "(sudo|su |python|perl|bash|sh)" | head -20

-- Splunk: detect Event 4672 for non-admin accounts (filter out known admin SIDs)
index=wineventlog EventCode=4672
| eval account_lower = lower(Account_Name)
| where NOT match(account_lower, "^(system|local service|network service|.*$$)")
| stats count values(PrivilegeList) AS privs BY Account_Name ComputerName earliest(_time)
| where count > 0
| sort earliest(_time)

-- Splunk: detect Event 4688 for suspicious processes indicating privesc
index=wineventlog EventCode=4688
| where match(New_Process_Name, "(?i)(whoami|net.exe|reg.exe|sc.exe|schtasks|wmic)")
| table _time ComputerName Account_Name New_Process_Name Process_Command_Line
| sort _time

# Linux: check for recently added users or group modifications
# New entries in /etc/passwd
grep -vE "^#" /etc/passwd | awk -F: '$3 == 0 {print "ROOT UID:", $0}'
# UID 0 accounts besides root are a red flag

# Recent group membership changes (auditd)
ausearch -f /etc/group --interpret | tail -30

Analytical Methodology

1. On Windows: search for Event 4672 across all hosts in the incident scope. Focus on accounts that are not in the privileged administrator baseline. Any non-standard account appearing with SeDebugPrivilege or SeTcbPrivilege requires immediate investigation.
2. Correlate Event 4672 with Event 4624 for the same account and timestamp — confirm the account actually logged on and was not a phantom event. Then search for Event 4688 from that account in the same session window.
3. Look for group membership changes (Events 4728, 4732, 4756). An account added to a privileged group is a high-fidelity escalation indicator. Note the account that made the change (SubjectUserName) — this may itself be a compromised account.
4. On Linux: run grep sudo /var/log/auth.log. Any sudo command executing an interpreter (python, perl, vim, less, awk, find) should be cross-referenced against GTFOBins — these are standard sudo escape paths.
5. Query auditd for setuid syscall events: ausearch -k privesc. Identify the calling process UID and the target UID. UID transition from non-zero to zero confirms root escalation.
6. Check /etc/passwd for any account with UID 0 other than root. Check /etc/sudoers and /etc/sudoers.d/ for unusual entries (ALL=(ALL) NOPASSWD, env_keep abuse).
7. Correlate the escalation event timestamp with subsequent privileged actions: file access, account creation, service installation, or network connections to external IPs. This establishes the impact of the escalation.
8. Document: the escalation method, the source account, the target privilege level achieved, timestamp, and the first privileged action taken after escalation.

Common Analytical Errors

• Ignoring Event 4672 for service accounts: Service accounts legitimately receive special privileges at logon. Build a baseline of expected accounts for Event 4672 and alert only on deviations, otherwise alert fatigue suppresses real detections.
• Missing auditd rule coverage: auditd only captures events covered by loaded rules. If the privesc watch rule was not loaded at the time of the attack, there will be no auditd evidence. Check auditctl -l output from the host image to verify what rules were active.
• Overlooking PAM module logs: On Linux, privilege escalation via PAM-aware services (su, sudo, sshd) generates PAM log entries in auth.log that precede the auditd execve records. Combine both sources for a complete picture.
• Confusing temporary with persistent escalation: Running a SUID binary is a one-time escalation; adding an account to the sudo group is persistent. Distinguish between transient and persistent escalation in your report.

NICE Framework Alignment

Further Reading

• MITRE ATT&CK: Privilege Escalation tactic (TA0004) — full technique catalogue
• GTFOBins (gtfobins.github.io) — sudo, SUID, and capability escalation via Linux binaries
• Microsoft Docs: Security auditing — Event 4672 field definitions and privilege list constants
• Linux Audit Documentation: audit.rules syntax and syscall reference
• SANS FOR508: Advanced DFIR — Windows privilege escalation artefacts module