Failed privilege elevation attempts

Threat snapshot

On Linux and Unix systems, sudo is the primary mechanism for controlled privilege elevation. It allows specific users to run specific commands as root or as another user, with each attempt logged to the system authentication log. When a user who is not listed in the sudoers configuration attempts to run a command with sudo, the attempt is denied and a message is written to the auth log: the username, the command attempted, the terminal it was run from, and a note that the user is not in the sudoers file or that the command was not permitted.

A failed sudo attempt from a legitimate user is a routine occurrence. They may have misremembered their permissions, tried a command they are not authorised to run, or encountered a configuration they were not expecting. A cluster of failed sudo attempts from an account that does not normally attempt privilege elevation, from a service account, or from a user account during an unusual session is a different signal entirely. It is consistent with an attacker who has gained initial access under a low-privilege account and is probing for paths to elevated access, testing whether the account has any sudo rights, or attempting to guess which commands are permitted. Log360 detects this activity through the Sudo Access Denied rule, which fires on auth log entries indicating a failed privilege elevation attempt.

At a glance

How this attack works

When a user attempts to run a command with sudo and is not authorised to do so, Linux writes an entry to the auth log in the following format:

sudo: <username> : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/<username> ;
USER=root ; COMMAND=<command attempted>

This log entry contains everything needed to understand the context of the attempt: the account that tried to elevate, the command they wanted to run as root, the working directory, and the terminal the session was established from. The Sudo Access Denied rule monitors for these log entries and fires when they are detected.

In an attack context, failed sudo attempts occur in two distinct scenarios. In the first, an attacker who has compromised a standard user account is probing for privilege escalation paths. They may attempt sudo -l to list permitted commands, try common high-value commands such as sudo su, sudo bash, or sudo /bin/sh, or attempt to run specific tools that they know require root access, such as network packet capture utilities or system configuration tools. Each attempt that is denied generates a log entry, and a sequence of denied attempts across different commands reveals a systematic probe.

In the second scenario, an attacker or a malicious script is attempting to run a specific command that requires elevated privileges as part of a broader exploitation chain. They may have found a SUID binary, a writable sudoers configuration, or a sudo version vulnerable to a known privilege escalation. The failed attempt log appears before a successful exploitation attempt using a different technique, and detecting the failed sudo probe provides an opportunity to investigate before the escalation succeeds.

The value of failed attempts as an early indicator

A failed sudo attempt is not a successful attack. Its value is as an early warning. An attacker who successfully escalates privileges via a kernel exploit, a SUID binary, or a misconfigured sudoers entry will not necessarily generate a failed sudo log entry at all. The failed sudo signal is most valuable when it appears in combination with other indicators: an unusual logon session, a service account attempting interactive commands, or a sequence of probing commands that suggests systematic privilege discovery. In isolation, it is a low-severity signal. In context, it may be the first visible sign of a post-exploitation sequence.

Attack chain

The table below maps failed privilege elevation attempts to their position in a typical Linux intrusion sequence and the corresponding MITRE ATT&CK technique.

Real-world scenario

A web hosting company operates a fleet of Linux servers running customer web applications. Each server has a set of application service accounts that run the web processes, a small number of named administrator accounts in the sudo group, and no other accounts with elevated privileges. The application service accounts are explicitly not in the sudoers configuration.

An attacker who exploited a remote code execution vulnerability in one of the customer web applications has obtained a shell running as the web application's service account, www-data. From this shell, the attacker begins probing for privilege escalation. They first run sudo -l, which generates a failed sudo entry because www-data has no sudo permissions. They then attempt sudo su, sudo bash, and sudo /etc/init.d/ssh restart in sequence, each generating a further failed sudo log entry. The four failed attempts occur within 35 seconds.

Log360 fires the Sudo Access Denied alert after the first failure. The alert sits in the SOC queue for 8 minutes before being reviewed. By that time, the attacker has moved on from sudo probing and found that the server is running a version of sudo with a known privilege escalation vulnerability. They have exploited it successfully and now have a root shell. The failed sudo alerts were the first and only visible signal before the escalation succeeded.

Why this happens

Service accounts that run web applications, databases, and background jobs are not expected to attempt privilege elevation. When one does, it is almost certainly because an attacker has obtained code execution under that account and is exploring the system. The failed sudo signal from a service account is higher confidence than the same signal from a standard user account, because service accounts have no legitimate reason to run interactive sudo commands. Triage priority for this rule should be weighted by the account type: failed sudo from a service account is higher priority than failed sudo from a named user account.

Business impact: What can go wrong

Failed privilege elevation attempts are not successful attacks in themselves, but they indicate an attacker who is actively working toward root access. If escalation succeeds, the consequences depend on the system role:

• Full system compromise: root access on a Linux system provides complete control over all processes, files, network interfaces, and kernel operations. An attacker with root can read any file, modify any configuration, install any software, and eliminate any evidence of their presence.
• Credential harvesting: root access allows reading of /etc/shadow for password hash extraction, SSH private keys stored on the system, application configuration files containing database passwords and API keys, and environment variables in running processes that may contain secrets.
• Lateral movement: root on one Linux host frequently enables lateral movement to other hosts accessible via SSH, particularly in environments that use SSH key-based authentication with shared keys or that have the same root password across multiple systems.
• Data exfiltration: root access removes all file permission barriers. Every file on the system, including application data, database files, logs, and configuration, is readable and transferable.
• Persistence survival: attackers with root access can install rootkits that hide their tools from standard system utilities, modify init scripts to re-establish access after reboot, and add SSH keys to the root account for direct re-entry without any further exploitation.
• Multi-tenant risk: on shared hosting or virtualised environments, a compromised host with root access may provide a path to accessing other tenants or escaping the virtualisation boundary, multiplying the scope of the incident beyond the originally targeted system.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the Sudo Access Denied rule can fire reliably, ensure the following are in place:

• Linux auth log forwarding is configured on all monitored systems. The sudo denial messages are written to /var/log/auth.log on Debian and Ubuntu-based systems and to /var/log/secure on Red Hat, CentOS, and similar distributions. The Log360 agent must be configured to collect and forward these log files from all monitored Linux hosts.
• The Log360 agent is installed and active on all Linux systems in scope. Sudo denial events are generated at the endpoint level and must be forwarded to Log360 via the agent. Confirm agent status for Linux hosts under Log360 > Settings > Log Source Configuration.
• The sudo configuration on monitored systems is set to log both successful and failed attempts. Most default sudo configurations log all events, but verify that the Defaults logfile or syslog directive in the sudoers configuration is not suppressing log output. If sudo logging has been redirected to a custom file rather than syslog or auth.log, configure the Log360 agent to collect from that custom path.
• SSH session logging is configured to write authentication events to the same auth log or to a forwarded syslog stream. This provides the preceding logon context needed to confirm that a failed sudo attempt is associated with a new remote session rather than with a long-standing interactive session by a known administrator.

Note: On systems using systemd-journald as the primary logging mechanism (common on modern RHEL, Fedora, and Ubuntu systems), sudo denial messages may be written to the journal rather than directly to /var/log/auth.log or /var/log/secure. Verify that the Log360 agent is configured to collect from the correct log path for the distribution and systemd version in use. If journald is configured without persistent storage, sudo denial events may not survive a reboot and should be forwarded to Log360 in near-real-time.

Detecting failed privilege elevation attempts using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: Sudo Access Denied. Configure an alert profile for the same. Set the default severity to Attention, which reflects the context-dependent nature of this signal. The alert should route to the SOC triage queue for review rather than generating an immediate critical notification, unless the triggering account is a service account, in which case severity should be elevated.

Step 2: Tune the rule for your environment

After enabling the rule, review the following:

• Establish a baseline of expected failed sudo activity in your environment. Review the failed sudo log volume for the preceding two weeks across all monitored hosts. Identify which accounts, hosts, and time windows generate routine failures, such as developers occasionally running commands they are not permitted, and set the alert threshold above the daily noise floor for those known patterns.
• Create a high-priority alert variant for service accounts. Identify all service account names in use across your Linux fleet (www-data, nginx, apache, postgres, mysql, and any application-specific service accounts). Configure a separate alert or severity override that triggers immediately when a failed sudo entry is generated by any of these accounts, regardless of the failure count threshold.
• Identify hosts where failed sudo attempts are expected to be more common, such as developer workstations or training environments, and consider applying separate thresholds for those hosts versus production servers. Production server failed sudo attempts should have a lower alert threshold than developer workstations.
• Review the COMMAND field values that should generate immediate alerts regardless of failure count. Commands targeting shell spawning (bash, sh, su) or critical system utilities (passwd, useradd, visudo) attempted by non-administrative accounts indicate deliberate escalation attempts and should alert on the first failure rather than after a threshold is reached.

Step 3: Read the alert

When the rule fires, the alert will display the hostname, the username that attempted the sudo command, the command they attempted to run, the TTY of the session, and the timestamp. Review the username first. A service account name in this field is the highest-priority signal. A standard user account name warrants checking whether the account is expected to have admin rights on that host and whether the command attempted is consistent with their role. Then review the command: shell spawning commands are escalation probes, while routine system utility attempts may be user error.

Investigating an alert

When the Sudo Access Denied rule fires, an L1 or L2 analyst should work through the following steps:

• Identify the account type. Determine immediately whether the account that attempted sudo is a service account, a named user account, or an account that should not exist on the system at all. A service account attempting interactive privilege elevation is a confirmed high-priority event requiring immediate investigation. An unknown account attempting sudo is a confirmed incident.
• Review the session context. Check the SSH or authentication logs on the same host for logon events associated with the alerting account in the period before the failed sudo attempt. Determine the source IP of the session, the authentication method used (password or key), and whether the logon came from a known administrative IP or from an unrecognised external address.
• Check the command sequence. Review all commands run in the session surrounding the failed sudo attempt. Query the auth log and shell history (if accessible) for the session. Look for reconnaissance commands (id, whoami, uname -a, cat /etc/passwd, cat /etc/shadow, find / -perm -4000), download attempts (wget, curl, fetch), or file writes to system directories that would indicate the attacker has pivoted beyond the sudo probe.
• Check for multiple failed attempts. Review the auth log for additional sudo denial entries from the same account in the same session window. Three or more failed attempts across different commands confirms systematic probing rather than an accidental single attempt and significantly raises the confidence of a genuine attack.
• Assess whether privilege escalation may have succeeded via a different path. Check for any successful privilege escalation indicators on the same host: SUID binary execution logs, kernel exploit invocations, processes running as root that are associated with the session, or modifications to /etc/passwd, /etc/sudoers, or SSH authorised keys that occurred after the failed sudo attempts. A failed sudo probe that is followed by successful root access via another technique means the attacker is already elevated.
• Verify with the account owner. For named user accounts, contact the account owner to confirm whether they were actively working on the affected host at the time of the alert. An account owner who confirms they were not active at that time indicates credential compromise. An account owner who confirms they were active and inadvertently ran a command they are not authorised for confirms the false positive scenario.

Escalation trigger

Escalate immediately to L2 or L3 if the failed sudo attempt came from a service account rather than a named user account; if the session source IP is external or unrecognised; if three or more failed sudo attempts occurred in the same session across different commands; if any SUID binary execution, kernel exploit invocation, or root process associated with the session is identified after the failed sudo attempts; or if the account owner cannot confirm the activity. Any indication that privilege escalation succeeded via an alternative path after the sudo denial requires immediate host isolation.

Responding and remediating

Immediate containment

• If the session is still active, terminate it immediately. On the affected host, identify the active session using who or w, find the corresponding process ID using ps aux, and kill the session: kill -9 <pid>. Block the source IP at the host firewall using iptables or firewalld to prevent reconnection during the investigation.
• Lock the affected account to prevent further authentication attempts: usermod -L <username> for named user accounts, or systemctl stop <service> and disabling the service for service accounts that should not have an interactive shell.
• If privilege escalation is suspected to have succeeded after the failed sudo attempt, isolate the host from the network. A compromised root session on a Linux host has full control of the network stack and can be used for lateral movement to other systems on the same network segment.

Forensic preservation

• Export the full auth.log or secure log from the affected host covering the period from the first authentication event associated with the attacking session to the time of containment. This log contains the logon event, all sudo attempt entries, and any subsequent authentication events.
• Capture the current process list, network connections, and open files using ps aux, netstat -tulpn or ss -tulpn, and lsof before isolating the host. These captures provide a snapshot of what was running at the time of containment and may reveal tools deployed by the attacker.
• If possible, preserve a memory image of the affected host before any reboot using a Linux memory acquisition tool. An attacker who successfully escalated privileges may have loaded kernel modules or modified in-memory process structures that are only visible from a memory image.

Eradication and recovery

• Audit all recently modified files on the affected host: find / -newer /var/log/auth.log -type f -ls or using the modification timestamps relative to the session start time. Look for new files in /tmp, /var/tmp, /dev/shm, home directories, and system directories that could be attacker tools or backdoors.
• Check for modifications to /etc/passwd, /etc/shadow, /etc/sudoers, and all files under /etc/sudoers.d for new entries or changes made after the session start time. An attacker who gained root will often modify these files to establish persistent access.
• Review all SSH authorised_keys files for all accounts on the system, including root, for keys added after the incident window. An attacker with root access frequently adds their own SSH public key to /root/.ssh/authorised_keys for persistent no-password access.
• Rotate the credentials for the compromised account and for any accounts whose password hashes or SSH keys were potentially readable during the session.

False positive guidance

Failed sudo attempts are common in Linux environments. The following scenarios regularly produce false positive alerts:

• Developers running commands above their permission level: developers who work on Linux servers often attempt commands that require root without realising their account does not have that specific sudo permission. This is particularly common on systems where the sudoers configuration grants access to specific commands rather than unrestricted sudo. Verify the source IP matches the developer's known workstation, the command attempted is consistent with their role, and there is only a single failure rather than a sequence. Contact the developer to confirm.
• Scripts and automation running under the wrong account: deployment scripts, configuration management tools, and automated jobs sometimes run under accounts that do not have the sudo permissions they expect. These will generate failures from a specific service or automation account, typically at consistent times aligned with a scheduled job. Identify the script responsible, verify it has a legitimate purpose, and either correct the sudo configuration or update the script to run under an account with appropriate permissions.
• Administrators using a non-privileged account by mistake: administrators who manage multiple accounts sometimes accidentally run privileged commands from a standard account session when they intended to be in their admin session. A single failed sudo attempt from a named admin account who also holds a separate privileged account on the same host is typically a false positive. Verify with the administrator.
• Shared accounts and handover situations: in environments with shared accounts or during account handovers, a new user of the account may attempt commands that the previous user had access to or that they assumed the account would have. A failed sudo attempt shortly after a new person begins using a shared account is likely a false positive if the pattern does not repeat.

Key differentiator

Legitimate failed sudo attempts are isolated, come from a known source IP associated with the account owner, involve a single command that is plausibly related to the user's role, and stop after the first failure when the user realises they do not have permission. Attacker-initiated sudo probing involves multiple commands across a short window, comes from an unfamiliar source IP or from an account that has no business running interactive commands, and includes commands designed to spawn shells or access system files. The combination of a service account, an unrecognised source IP, and more than one command attempt in the same session requires immediate investigation regardless of individual signal confidence.

Hardening and prevention

The following controls reduce the risk of privilege escalation via sudo abuse on Linux systems:

• Apply the principle of least privilege in sudoers configuration. Grant sudo access to specific commands required for each role rather than unrestricted sudo access. Use the NOPASSWD directive only where operationally necessary and document each instance. Regularly audit the sudoers configuration and /etc/sudoers.d directory for unnecessary permissions.
• Disable interactive shell access for service accounts. Service accounts that run application processes should have their shell set to /usr/sbin/nologin or /bin/false in /etc/passwd. This prevents interactive logins and makes it significantly harder for an attacker who has exploited a service account to establish a usable shell.
• Deploy auditd on all Linux hosts and configure audit rules for sudo, su, and privilege-related commands. Auditd provides more detailed privilege escalation telemetry than the auth log alone, including file access attempts and system call records that can reveal exploitation attempts against SUID binaries and kernel vulnerabilities.
• Keep the sudo binary and the kernel patched against known privilege escalation vulnerabilities. CVE-2021-3156 (Heap-Based Buffer Overflow in Sudo) and similar vulnerabilities have been exploited specifically after failed sudo probe attempts revealed the installed sudo version. Regular patching removes these alternative escalation paths.
• Restrict SSH access to Linux servers to known, documented source IPs where operationally feasible. Limiting which IP addresses can authenticate via SSH reduces the attack surface for initial access and makes anomalous sessions from unrecognised IPs immediately visible in the auth log.
• Enable PAM (Pluggable Authentication Modules) account lockout after a defined number of failed sudo attempts. Configuring pam_tally2 or pam_faillock to lock accounts after repeated authentication failures limits the effectiveness of password-based sudo probing.

Next steps

Enable the following related rules in Log360's Rule Library alongside Sudo Access Denied to build broader coverage of the Linux privilege escalation and post-exploitation threat chain: