Linux privilege escalation detection with Wazuh and auditd

At a glance

What this is: This is a detection-focused walkthrough showing how Linux privilege escalation techniques can be identified with Wazuh, Auditd, File Integrity Monitoring, and custom rules.

Why it matters: It matters because Linux privilege escalation is often indistinguishable from legitimate administration unless teams monitor commands, file changes, and process behaviour with identity-aware endpoint controls.

👉 Read Wazuh's analysis of Linux privilege escalation detection with auditd and FIM

Context

Privilege escalation is a control failure problem as much as a malware problem. On Linux, attackers often begin with a low-privileged account and then abuse trusted system features such as sudo, SUID, cron, or ptrace to move into root-level access. The primary security gap is not just the exploit technique itself, but the absence of enough telemetry to separate legitimate administration from malicious use.

This post sits at the intersection of endpoint security and identity governance because elevated access on Linux is still an identity question: who or what is allowed to run privileged commands, under what conditions, and with what traceability. That makes it relevant to PAM, IAM, and NHI teams that need to understand how runtime privilege abuse appears in operational logs and audit data.

Key questions

Q: What breaks when Linux privilege escalation controls are not tightly governed?

A: Low-privileged accounts can turn routine administration features into root access paths. The result is not only compromise, but also loss of trust in audit trails, because the attacker often uses legitimate commands that look normal unless privilege-bearing activity is specifically monitored.

Q: Why do sudo, SUID, and cron misconfigurations matter so much to Linux security?

A: They convert ordinary system features into trusted elevation paths. If a user can invoke a shell through sudo, inherit file-owner privileges through SUID, or trigger commands through cron, the attacker can move from user-level access to root without exploiting a kernel flaw.

Q: How do security teams know whether Linux privilege escalation detection is working?

A: They should see the right alerts for the right behaviours, such as sudo invocations, unexpected SUID changes, ptrace attachment, and cron file edits, while keeping noise low for approved administration. If those events are not visible, the monitoring model is incomplete.

Q: Who is accountable when Linux privilege escalation leads to wider environment compromise?

A: Accountability usually sits across platform operations, security engineering, and the owners of the affected workloads. The key governance issue is whether patching, telemetry, and containment were assigned clear ownership before exploitation. Frameworks such as NIST CSF and NIST SP 800-53 both expect control accountability, continuous monitoring, and timely remediation for exposed systems.

Technical breakdown

Sudo abuse and cached elevation

Sudo is an elevation control, not a login mechanism. When /etc/sudoers includes NOPASSWD rules or permits execution of powerful binaries, an attacker with a valid low-privileged account can move directly into a root shell by chaining allowed commands into shell escape paths. The abuse works because the system is doing exactly what it was configured to do, only outside the administrator's intent. Detection depends on watching command execution at the syscall layer and correlating it with known escalation-friendly binaries.

Practical implication: audit sudo execution paths and remove passwordless access to binaries that can be turned into shells.

SUID, SGID, and file permission drift

SUID and SGID bits let a program run with the file owner's or group's privileges, which is useful for legitimate utilities but dangerous when the bit appears on an unexpected binary. Attackers search for these files, copy shells into writable locations, or modify existing permissions to create a privileged execution path. File Integrity Monitoring is valuable here because the signal is often not the execution itself but the appearance of a new privileged binary or a permission change on an existing one.

Practical implication: monitor for new SUID binaries and permission-bit changes in writable paths such as /tmp, /var/tmp, and home directories.

Cron, linker hijacking, and process injection as privilege paths

Scheduled tasks, PATH resolution, dynamic linker behaviour, and ptrace all create opportunities to inherit higher privilege through trusted runtime behaviour. Cron and logrotate can execute attacker-controlled commands if configuration files or PATH entries are writable. Dynamic linker hijacking works when a privileged process loads attacker-influenced libraries, while ptrace-based injection abuses debugging interfaces to modify a live process's memory. These are distinct techniques, but they share a common property: the attacker does not need to break authentication if they can redirect legitimate execution.

Practical implication: protect scheduled-task directories, lock down PATH handling, and alert on ptrace activity from non-root processes.

Threat narrative

Attacker objective: The attacker wants root-level control of a Linux host so they can persist, evade monitoring, and expand the compromise.

1. Entry occurs when the attacker already has a low-privileged Linux account and begins enumerating privilege-bearing paths such as sudo rules, SUID files, cron jobs, and writable execution locations.
2. Escalation happens when the attacker abuses one of those trusted mechanisms, such as sudo NOPASSWD, SUID binaries, cron execution, or ptrace injection, to obtain root-equivalent execution.
3. Impact follows when the attacker disables defenses, modifies system configuration, persists as root, or exfiltrates data from the compromised endpoint.

NHI Mgmt Group analysis

Linux privilege escalation is an identity problem disguised as an endpoint problem. The article shows that attackers rarely need to invent a new access model when they can abuse existing privileged workflows such as sudo, SUID, cron, and ptrace. That is why PAM thinking matters on Linux endpoints as much as EDR thinking. Practitioners should treat root-path abuse as governed access, not just suspicious process activity.

Standing administrative privilege remains the core failure mode. The post repeatedly relies on persistent permissions being available long enough for an attacker to discover and reuse them. That is the same governance weakness that appears in over-privileged service accounts and unmanaged operational accounts. In identity terms, the control gap is not visibility alone, but the continued existence of privilege that can be discovered and repurposed.

File Integrity Monitoring and syscall auditing together form the minimum viable detection layer. Neither control is sufficient on its own because sudo abuse, permission drift, and scheduled-task manipulation produce different signals. The article's strength is that it maps those signals to real Linux behaviours rather than abstract policy. The practical conclusion is that endpoint telemetry must be tuned to privileged execution paths, not just malware signatures.

Privilege escalation through legitimate OS features creates governance debt. Every exception in sudoers, every unexpected SUID bit, and every writable cron path is a standing access decision that accumulates risk over time. This is where the identity and endpoint domains converge: if the privilege model is not continuously reviewed, the attack surface becomes a lifecycle problem. Practitioners should treat privileged runtime paths as assets with owners, expiry, and review cadence.

MITRE ATT&CK mapping improves operational consistency, but only when teams use it to drive response thresholds. The value here is not the taxonomy itself, but the discipline of classifying sudo abuse, process injection, and scheduled-task abuse as distinct privilege-escalation behaviours. That helps security teams decide which events are noise and which indicate a likely root compromise. Practitioners should tie ATT&CK mapping to alert severity and response playbooks.

What this signals

Privilege drift is the operational pattern behind many Linux escalation events. When privilege is granted once and never revisited, attackers only need one misconfiguration to turn an endpoint into a root shell. For identity teams, that means runtime privilege review needs to be part of the access lifecycle, not a separate security exercise.

Standing administrative paths are now a governance surface. sudoers files, SUID bits, cron ownership, and ptrace permissions should be treated as policy artefacts with owners and review dates. Teams that already track privileged access in PAM will find the same mindset applies to Linux endpoints, especially where workloads or automation users can inherit broad local power.

The visibility challenge is familiar across identity programmes: once privilege is delegated into multiple execution paths, it is hard to prove that the effective access model still matches policy. NHI Mgmt Group's view is that the most durable control is to reduce the number of places where privilege can be inherited silently, then monitor the remaining paths with high-fidelity audit signals.

For practitioners

• Harden sudoers entries Remove NOPASSWD rules wherever possible and restrict sudo to commands that cannot spawn shells or edit arbitrary files. Review all delegated commands for GTFOBins-style escape potential, especially find, vim, python, tar, and cp.
• Monitor privilege-bearing file changes Use FIM to watch for new SUID or SGID binaries and permission changes in writable directories such as /tmp, /var/tmp, /home, and custom application paths. Alert when privileged bits appear outside approved software packages.
• Audit runtime privilege abuse signals Track auditd events for sudo execution, chmod-based privilege-bit changes, ptrace attachment, and cron configuration edits. Correlate those events with user context so benign administration can be separated from escalation attempts.
• Lock down scheduled-task execution paths Protect /etc/cron.d, /etc/crontab, and /etc/logrotate.d from unauthorized edits and validate PATH values used by root-owned jobs. Treat writable directories in execution paths as potential privilege-escalation footholds.

Key takeaways

• Linux privilege escalation is usually an abuse of trusted administration paths, not a novel exploit chain.
• Wazuh's value here is in correlating Auditd, FIM, and custom rules to surface distinct escalation behaviours.
• The strongest preventive control is shrinking standing privilege and continuously reviewing every path that can elevate to root.

Key terms

• Privilege Escalation: An attack technique where a compromised identity — often an NHI with initially limited permissions — exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
• SUID and SGID: SUID and SGID are file permission bits that let an executable run with the owner's or group's privileges instead of the caller's. They are useful for administration, but they become dangerous when applied to unexpected binaries or writable paths.
• Auditd: Auditd is the Linux audit subsystem used to record system events such as file changes, command execution, and authentication-related activity. In privileged access environments, it provides detailed evidence, but the rules must be scoped carefully so the resulting logs remain reviewable and operationally useful.
• File Integrity Monitoring: File integrity monitoring is the practice of tracking critical files for unexpected changes in content, permissions, ownership, or metadata. It helps teams spot tampering, drift, and persistence attempts that can undermine identity and security controls. In mature programmes, it is tied to approved baselines and actionable change workflows.

What's in the full article

Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:

• Auditd rule snippets and endpoint configuration steps for detecting sudo abuse, SUID drift, ptrace attachment, and cron modification
• Wazuh dashboard screenshots and rule IDs that map specific Linux escalation behaviours to alerting logic
• Hands-on attack simulation commands for each technique, including cleanup steps after testing
• MITRE ATT&CK mappings for each privilege escalation technique so teams can align detections to adversary behaviour

👉 The full Wazuh post includes endpoint rules, test commands, and MITRE ATT&CK mappings for each technique.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to manage privileged access more systematically. It helps security teams connect identity controls to the broader operational risk surface.