Loading

Passwordless Sudo Probing

This rule detects passwordless sudo probing activity on Linux systems. Passwordless sudo probing can be an indication of an attacker attempting to enumerate it's allowed commands and potential privilege escalation.

Rule type: eql
Rule indices:

  • auditbeat-*
  • endgame-*
  • logs-auditd_manager.auditd-*
  • logs-crowdstrike.fdr*
  • logs-endpoint.events.process*
  • logs-sentinel_one_cloud_funnel.*

Rule Severity: low
Risk Score: 21
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Endpoint
  • OS: Linux
  • Use Case: Threat Detection
  • Tactic: Discovery
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Auditd Manager
  • Data Source: Crowdstrike
  • Data Source: SentinelOne
  • Resources: Investigation Guide

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2

This rule requires data coming in from Elastic Defend.

Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

  • Fleet is required for Elastic Defend.
  • To configure Fleet Server refer to the documentation.
  • Go to the Kibana home page and click "Add integrations".
  • In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
  • Click "Add Elastic Defend".
  • Configure the integration name and optionally add a description.
  • Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
  • Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. Helper guide.
  • We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
  • Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. For more details on Elastic Agent configuration settings, refer to the helper guide.
  • Click "Save and Continue".
  • To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. For more details on Elastic Defend refer to the helper guide.

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

This rule catches a Linux user running sudo -n true, a quiet check for passwordless sudo that reveals whether the account can elevate without user interaction. Attackers often issue this immediately after gaining a shell to test privilege-escalation paths, then pivot to sudo -l or directly launch an allowed root command if the probe succeeds.

  • Identify the originating user, session type, parent shell or service, and authentication source to determine whether the probe came from normal administration, automation, or a potentially compromised interactive login.
  • Review activity immediately before and after the alert for follow-on actions such as privilege enumeration, attempts to launch root-level utilities, service manipulation, credential access, or edits to sudo and persistence-related files.
  • Confirm the account’s effective sudo privileges by inspecting sudoers policy, included drop-in rules, and centralized identity policy to verify whether passwordless elevation is expected and which commands are allowed.
  • Correlate the same user, host, and source address across authentication, process, and network telemetry to spot unusual login patterns, lateral movement, or repeated probing on additional Linux systems.
  • If the behavior is not attributable to approved tooling or maintenance, isolate the affected session or host, preserve volatile evidence and shell history, and rotate any credentials or keys that may have been exposed.
  • Administrative scripts, cron jobs, or service-account maintenance tasks may run sudo -n true to confirm non-interactive privilege is available before continuing privileged work; verify the parent process, executing user, script location, and timing against approved operational activity.
  • Sudoers validation during account provisioning, system configuration, or post-change testing can legitimately execute sudo -n true after privilege updates; verify recent changes to sudo policy or user permissions and confirm the account is expected to have passwordless sudo access.
  • Isolate the affected Linux host from the network and terminate the malicious user session or shell while preserving shell history, sudo logs, and any temporary scripts under /tmp, /var/tmp, or the user’s home directory for incident handling.
  • Remove attacker access by disabling the involved account, revoking exposed SSH keys, rotating passwords and tokens, and deleting unauthorized entries in authorized_keys, sudoers drop-ins, cron jobs, systemd services, and startup scripts.
  • Inspect and reverse any privileged changes made after the sudo probe, including new local users, modified /etc/sudoers or /etc/sudoers.d files, altered PAM or SSH configuration, unexpected package installs, and binaries replaced outside approved change windows.
  • If the probe was followed by successful sudo use, new root persistence, credential theft activity, or similar behavior on additional Linux hosts, escalate immediately to incident response as a suspected privileged-compromise case and expand containment to related systems and accounts.
  • Restore the host to a known-good state by rebuilding from a trusted image or verified backup when root-level execution occurred, then validate system integrity, reapply approved sudo policy, and restrict passwordless sudo to only documented commands.
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name == "sudo" and process.args in ("-n", "--non-interactive") and process.args == "true"

Framework: MITRE ATT&CK