Sudo and Sudo Caching

Executive Summary

Sudo and Sudo Caching (T1548.003) is a MITRE ATT&CK technique associated with Privilege Escalation. Adversaries may perform sudo caching and/or use the sudoers file to elevate privileges.

Why Attackers Use It

Attackers use Sudo and Sudo Caching because it provides a reliable way to advance their objective within the Privilege Escalation tactic, often with a favorable balance of impact versus detectability on Linux, macOS environments. Defenders should assess this behavior in the context of the affected platform and adjacent activity rather than treating it as a standalone indicator.

MITRE Description

Adversaries may perform sudo caching and/or use the sudoers file to elevate privileges. Adversaries may do this to execute commands as other users or spawn processes with higher privileges.

Within Linux and MacOS systems, sudo (sometimes referred to as "superuser do") allows users to perform commands from terminals with elevated privileges and to control who can perform these commands on the system. The <code>sudo</code> command "allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments."(Citation: sudo man page 2018) Since sudo was made for the system administrator, it has some useful configuration features such as a <code>timestamp_timeout</code>, which is the amount of time in minutes between instances of <code>sudo</code> before it will re-prompt for a password. This is because <code>sudo</code> has the ability to cache credentials for a period of time. Sudo creates (or touches) a file at <code>/var/db/sudo</code> with a timestamp of when sudo was last run to determine this timeout. Additionally, there is a <code>tty_tickets</code> variable that treats each new tty (terminal session) in isolation. This means that, for example, the sudo timeout of one tty will not affect another tty (you will have to type the password again).

The sudoers file, <code>/etc/sudoers</code>, describes which users can run which commands and from which terminals. This also describes which commands users can run as other users or groups. This provides the principle of least privilege such that users are running in their lowest possible permissions for most of the time and only elevate to other users or permissions as needed, typically by prompting for a password. However, the sudoers file can also specify when to not prompt users for passwords with a line like <code>user1 ALL=(ALL) NOPASSWD: ALL</code>.(Citation: OSX.Dok Malware) Elevated privileges are required to edit this file though.

Adversaries can also abuse poor configurations of these mechanisms to escalate privileges without needing the user's password. For example, <code>/var/db/sudo</code>'s timestamp can be monitored to see if it falls within the <code>timestamp_timeout</code> range. If it does, then malware can execute sudo commands without needing to supply the user's password. Additional, if <code>tty_tickets</code> is disabled, adversaries can do this from any tty for that user.

In the wild, malware has disabled <code>tty_tickets</code> to potentially make scripting easier by issuing <code>echo 'Defaults !tty_tickets' >> /etc/sudoers</code>.(Citation: cybereason osx proton) In order for this change to be reflected, the malware also issued <code>killall Terminal</code>. As of macOS Sierra, the sudoers file has <code>tty_tickets</code> enabled by default.

Attack Flow

1. Attacker gains the prerequisite access or context described below.
2. Attacker executes Sudo and Sudo Caching to achieve its tactical objective (Privilege Escalation).
3. Resulting access/data/effect is leveraged to advance the broader attack chain (see Related Techniques).

Prerequisites

• Platform(s): Linux, macOS
• ATT&CK does not define one universal permission requirement for this technique. Establish the required access from the observed implementation and affected platform.

Common Tools

• Tool attribution is implementation-specific. Use ATT&CK procedure examples and local telemetry to identify the binaries, services, scripts, accounts, or cloud resources involved.

Commands

No universal command represents Sudo and Sudo Caching. Capture the exact command line, arguments, parent process, account, host, and execution time from the investigated environment; do not operationalize unverified examples.

Network Traffic

• Network observability is implementation-dependent. Review DNS, proxy, firewall, flow, authentication, and packet telemetry around the activity window, then correlate remote endpoints and protocol behavior with host evidence.

Windows Events

Sysmon Events

Detection Opportunities

No MITRE detection guidance published for this technique.

Relevant ATT&CK Data Sources: N/A

Sigma Rules

A universal Sigma rule would create unreliable results because this technique has no single guaranteed observable. Build detection logic from a documented behavior and supported data source, scope it to the affected platform, and validate it against benign administrative activity before deployment.

Splunk Queries

Start with the data sources named in the detection section. Scope searches by asset, identity, and time window; correlate the primary behavior with preceding access and subsequent actions. A portable query is intentionally not provided where the technique lacks a universal schema or observable.

Investigation Workflow

1. Confirm that the observed behavior is consistent with Sudo and Sudo Caching and rule out expected administrative or application activity.
2. Establish the first-seen time, initiating identity, source system, target system, and affected resources.
3. Collect relevant host, identity, network, cloud, and application telemetry for the surrounding time window.
4. Correlate parent and child activity, remote connections, file or configuration changes, and related ATT&CK techniques.
5. Determine scope by searching for the same observable across peer assets and identities.
6. Preserve volatile evidence and record confidence, assumptions, and telemetry gaps before containment.

Containment

1. Isolate affected host(s)/account(s) identified during investigation.
2. Revoke or rotate any credentials/tokens potentially exposed.
3. Apply the mitigations listed below where not already enforced.
4. Validate no related techniques (see Related Techniques) were chained against the same asset.

Mitigation

• M1022 -- Restrict File and Directory Permissions: Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files.
• M1028 -- Operating System Configuration: Operating System Configuration involves adjusting system settings and hardening the default configurations of an operating system (OS) to mitigate adversary exploitation and prevent abuse of system functionality.
• M1026 -- Privileged Account Management: Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts).

Related Techniques

• T1056.002
• T1059.004
• T1543.001
• T1548
• T1685