{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/auditd/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Auditd Manager"],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","linux","auditd"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies potential privilege escalation attempts on Linux systems by monitoring for processes with a root effective user ID (EUID) but a non-root real user ID (RUID), combined with the use of the \u003ccode\u003e-p\u003c/code\u003e flag (commonly used to preserve privileges in shells like bash or dash) and execution from a non-standard path (outside of \u003ccode\u003e/bin\u003c/code\u003e, \u003ccode\u003e/sbin\u003c/code\u003e, \u003ccode\u003e/usr/bin\u003c/code\u003e, etc.).  Attackers may copy or link setuid-capable shells or similar helpers into writable locations to regain a root context after local exploitation. This behavior is often associated with post-exploitation activities where attackers attempt to maintain or regain elevated privileges.  The rule relies on Auditd data to provide visibility into process execution events and user context. The original rule was published on 2026-04-24 by Elastic.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to the system with limited privileges (e.g., through exploiting a vulnerability or using stolen credentials).\u003c/li\u003e\n\u003cli\u003eAttacker identifies a writable directory outside of standard system binary paths (e.g., \u003ccode\u003e/tmp\u003c/code\u003e, \u003ccode\u003e/var/tmp\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAttacker copies or creates a symbolic link to a setuid-capable shell (e.g., \u003ccode\u003e/bin/bash\u003c/code\u003e, \u003ccode\u003e/bin/dash\u003c/code\u003e) into the identified writable directory. This copied shell retains the setuid bit.\u003c/li\u003e\n\u003cli\u003eAttacker executes the copied or linked shell from the non-standard path with the \u003ccode\u003e-p\u003c/code\u003e flag (e.g., \u003ccode\u003e/tmp/bash -p\u003c/code\u003e). The \u003ccode\u003e-p\u003c/code\u003e flag instructs the shell to preserve privileges, effectively running with the effective user ID (EUID) of root.\u003c/li\u003e\n\u003cli\u003eAuditd logs this process execution event, capturing the non-standard path, the use of the \u003ccode\u003e-p\u003c/code\u003e flag, the root EUID, and the non-root RUID.\u003c/li\u003e\n\u003cli\u003eThe detection rule identifies the process execution event based on the criteria outlined above.\u003c/li\u003e\n\u003cli\u003eAttacker now has a root shell and can perform administrative tasks, install malware, or further compromise the system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation attack can grant an attacker complete control over the compromised system. This allows them to access sensitive data, install malicious software, modify system configurations, and potentially pivot to other systems on the network. This can lead to data breaches, system downtime, and significant financial losses.  The risk score for this type of activity is considered high due to the potential for significant impact.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003ePotential Root Effective Shell from Non-Standard Path via Auditd\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnsure that Auditd Manager or Auditbeat is properly configured to collect process execution events with relevant fields (\u003ccode\u003eevent.action\u003c/code\u003e, \u003ccode\u003euser.id\u003c/code\u003e, \u003ccode\u003euser.effective.id\u003c/code\u003e, \u003ccode\u003eprocess.args\u003c/code\u003e, and \u003ccode\u003eprocess.executable\u003c/code\u003e) as described in the rule setup to enable the rule to function correctly.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by this rule by inspecting \u003ccode\u003eprocess.executable\u003c/code\u003e, \u003ccode\u003eprocess.args\u003c/code\u003e, \u003ccode\u003eprocess.parent\u003c/code\u003e, and the full command line reconstructed in audit logs.\u003c/li\u003e\n\u003cli\u003eRegularly audit all setuid binaries on the filesystem to identify any unauthorized or malicious setuid executables.\u003c/li\u003e\n\u003cli\u003eImplement access controls and file integrity monitoring to prevent unauthorized modification of system binaries and writable directories.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T09:51:29Z","date_published":"2026-05-01T09:51:29Z","id":"/briefs/2024-01-potential-root-effective-shell/","summary":"This rule identifies process execution events where the effective user is root while the real user is not, the process arguments include the privileged shell flag commonly associated with setuid-capable shells, and the executable path is outside standard system binary directories, indicating potential privilege escalation.","title":"Potential Root Effective Shell from Non-Standard Path via Auditd","url":"https://feed.craftedsignal.io/briefs/2024-01-potential-root-effective-shell/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Auditd Manager"],"_cs_severities":["medium"],"_cs_tags":["command-and-control","execution","container","auditd","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies instances of \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e being executed from within containers managed by \u003ccode\u003erunc\u003c/code\u003e on Linux systems. The rule leverages Auditd Manager to monitor system calls and flags processes running with the title \u003ccode\u003erunc init\u003c/code\u003e that then execute \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e. This activity is noteworthy because attackers often use these tools to download malicious payloads (stagers, scripts, implants) or to exfiltrate data after compromising a container. While these tools can be used legitimately within containers, their execution in the context of \u003ccode\u003erunc init\u003c/code\u003e suggests a higher risk of malicious activity. The rule focuses on narrowing the signal to the container runtime boundary where unexpected download clients are more worthy of review. The rule specifically leverages Auditd Manager for data collection.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a host system, possibly through exploiting a vulnerability in an application running outside the container (e.g., web application).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a containerized application running on the compromised host.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits a vulnerability within the container, or abuses a privileged workload within the container, to gain elevated privileges or code execution within the container.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to download additional tools or scripts into the container. These tools might include reverse shells, credential dumping tools, or data exfiltration utilities.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the downloaded tools to further compromise the container or the underlying host.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to stage data for exfiltration to an external server. This may involve compressing and encoding data before transmission.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates the data exfiltration process using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to send the staged data to a remote server controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, which could include data theft, system disruption, or further lateral movement within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised containers can lead to data breaches, service disruptions, and further attacks on internal systems. Successful exploitation could allow attackers to steal sensitive data, install malware, or pivot to other parts of the network, impacting confidentiality, integrity, and availability. The number of affected systems depends on the scope of the container deployment and the privileges granted to the compromised container.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Curl or Wget Execution from Container Context\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Auditd Manager with syscall coverage including \u003ccode\u003eexecve\u003c/code\u003e to capture process execution and arguments within containers, as mentioned in the rule\u0026rsquo;s setup instructions.\u003c/li\u003e\n\u003cli\u003eCorrelate alerts from this rule with network logs to identify the destination IP addresses and domains contacted by the compromised container.\u003c/li\u003e\n\u003cli\u003eBaseline trusted images and exclude stable image digests or namespaces when noisy to reduce false positives, as suggested in the rule\u0026rsquo;s false positives section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-curl-wget-container-execution/","summary":"This rule detects the execution of curl or wget from within runc-backed containers on Linux systems monitored by Auditd Manager, indicating potential ingress tool transfer or data exfiltration by attackers who have compromised the container.","title":"Curl or Wget Execution from Container Context","url":"https://feed.craftedsignal.io/briefs/2024-01-curl-wget-container-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Agent Auditd Manager","EKS","Azure","gcloud","Docker"],"_cs_severities":["high"],"_cs_tags":["credential-access","linux","auditd"],"_cs_type":"advisory","_cs_vendors":["Elastic","Amazon","Microsoft","Google","Docker"],"content_html":"\u003cp\u003eThis detection focuses on identifying unauthorized access to sensitive identity files on Linux systems. It leverages Auditd to monitor file access events and flags processes that are commonly used for copying, scripting, or staging files from temporary directories. The targeted files include Kubernetes service account tokens, kubelet configurations, cloud CLI configurations for AWS, Azure, and Google Cloud, root SSH keys, and Docker configurations. These files are critical for authentication and authorization within the system, and unauthorized access could lead to credential theft, privilege escalation, or lateral movement. This is especially important in cloud environments and containerized deployments where these files are commonly used for managing access to resources. The rule is designed to exclude user home paths to avoid false positives and focus on system-level access.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Linux system through various means, such as exploiting a vulnerability or compromising credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a utility like \u003ccode\u003ecp\u003c/code\u003e, \u003ccode\u003ecat\u003c/code\u003e, or \u003ccode\u003ecurl\u003c/code\u003e to access sensitive files such as \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e or \u003ccode\u003e/root/.ssh/id_rsa\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAuditd logs the file access event, capturing details about the process, user, and file path.\u003c/li\u003e\n\u003cli\u003eThe detection rule identifies the suspicious process based on its name, executable path (e.g., \u003ccode\u003e/tmp/*\u003c/code\u003e), or command-line arguments.\u003c/li\u003e\n\u003cli\u003eThe rule checks if the accessed file is in the list of sensitive identity files.\u003c/li\u003e\n\u003cli\u003eIf both conditions are met, the rule triggers an alert, indicating potential unauthorized access to sensitive credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the stolen credentials or uses them to move laterally within the network.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen credentials to access cloud resources or other sensitive systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to the compromise of sensitive credentials, allowing attackers to gain unauthorized access to critical systems and data. This can result in data breaches, service disruptions, and financial losses. The targeted files contain credentials for Kubernetes clusters, cloud environments (AWS, Azure, Google Cloud), and SSH keys, potentially impacting a wide range of resources. The impact is particularly severe in environments where these credentials are used for managing critical infrastructure or accessing sensitive data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Auditd Manager integration with the specified audit rules in the provided setup steps to monitor access to sensitive identity files on Linux systems. Ensure auditd is properly configured and running (\u003ccode\u003eauditctl -l\u003c/code\u003e) to generate the necessary logs.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided to detect suspicious processes accessing sensitive identity files and tune them for your environment by excluding legitimate processes or users as needed.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rules, focusing on the process name, executable, parent command line, and the accessed file path to determine the legitimacy of the access.\u003c/li\u003e\n\u003cli\u003eReview and harden file permissions on shared credential stores to prevent unauthorized access. Rotate exposed keys and tokens and invalidate cloud sessions if a compromise is suspected, as suggested in the rule\u0026rsquo;s documentation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-sensitive-identity-file-access/","summary":"This rule detects suspicious processes, such as copy utilities or scripting tools, accessing sensitive identity files on Linux systems, including Kubernetes tokens, cloud CLI configurations, and root SSH keys, indicating potential credential theft.","title":"Suspicious Process Accessing Sensitive Identity Files via Auditd","url":"https://feed.craftedsignal.io/briefs/2024-01-sensitive-identity-file-access/"}],"language":"en","title":"CraftedSignal Threat Feed — Auditd","version":"https://jsonfeed.org/version/1.1"}