{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/splunk-add-on-for-unix-and-linux/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud","Splunk Add-on for Unix and Linux"],"_cs_severities":["medium"],"_cs_tags":["auditd","linux","anomaly","endpoint"],"_cs_type":"advisory","_cs_vendors":["Splunk","Red Hat"],"content_html":"\u003cp\u003eThis detection identifies abnormal terminations of the Linux audit daemon (auditd) by monitoring for DAEMON_ABORT events within audit logs. Such terminations suggest a critical failure in the auditing subsystem, potentially stemming from resource exhaustion, data corruption, or malicious actions aimed at disrupting the logging process. Unlike a graceful shutdown, a DAEMON_ABORT event implies that audit logging may have been disabled unexpectedly, compromising system observability and security monitoring. Defenders should prioritize investigating these events, correlating them with DAEMON_START, DAEMON_END, and overall system logs to pinpoint the root cause. Recurring aborts or the absence of a subsequent DAEMON_START signal indicate a high-severity issue requiring immediate attention to ensure continued log integrity and security posture.\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 (e.g., through exploiting a vulnerability or using stolen credentials).\u003c/li\u003e\n\u003cli\u003eAttacker escalates privileges to a level where they can interact with system services.\u003c/li\u003e\n\u003cli\u003eAttacker attempts to corrupt auditd\u0026rsquo;s configuration or data files, causing it to fail.\u003c/li\u003e\n\u003cli\u003eThe auditd daemon encounters an unrecoverable error and generates a DAEMON_ABORT event in the audit logs.\u003c/li\u003e\n\u003cli\u003eThe system administrator may not immediately notice the auditd failure, leaving a gap in security monitoring.\u003c/li\u003e\n\u003cli\u003eAttacker performs malicious activities without being properly logged by auditd.\u003c/li\u003e\n\u003cli\u003eAttacker attempts to remove evidence of the auditd failure from system logs.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data theft or system compromise, with reduced risk of detection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leading to auditd daemon aborts can severely compromise an organization\u0026rsquo;s security monitoring capabilities. With audit logging disabled or unreliable, malicious activities can go undetected, leading to data breaches, system compromise, and other security incidents. The absence of reliable audit logs can also hinder incident response efforts and forensic investigations, making it difficult to determine the scope and impact of an attack. Organizations in regulated industries may also face compliance issues due to the lack of complete audit trails.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Linux auditd logging to capture DAEMON_ABORT events (see \u003ccode\u003edata_source\u003c/code\u003e in search definition).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect DAEMON_ABORT events and tune the rule based on your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected DAEMON_ABORT events by correlating them with DAEMON_START, DAEMON_END, and system logs to determine the root cause.\u003c/li\u003e\n\u003cli\u003eMonitor the time between DAEMON_ABORT and DAEMON_START events to identify potential issues requiring further investigation.\u003c/li\u003e\n\u003cli\u003eUse Splunk Add-on for Unix and Linux (\u003ca href=\"https://splunkbase.splunk.com/app/833\"\u003ehttps://splunkbase.splunk.com/app/833\u003c/a\u003e) to ensure proper parsing and categorization of auditd data.\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-linux-auditd-daemon-abort/","summary":"Detection of abnormal Linux audit daemon (auditd) termination via DAEMON_ABORT events, indicating potential auditing subsystem failure due to resource exhaustion, corruption, or malicious interference.","title":"Linux Auditd Daemon Abort Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-linux-auditd-daemon-abort/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud","Splunk Add-on for Unix and Linux"],"_cs_severities":["high"],"_cs_tags":["defense-evasion","persistence","privilege-escalation","firewall"],"_cs_type":"advisory","_cs_vendors":["Splunk"],"content_html":"\u003cp\u003eThis detection identifies attempts to disable or modify system firewalls on Linux systems, a common tactic used by attackers to weaken defenses and maintain unauthorized access. The detection focuses on monitoring \u003ccode\u003eauditd\u003c/code\u003e logs for \u003ccode\u003eSERVICE_STOP\u003c/code\u003e events targeting \u003ccode\u003efirewalld\u003c/code\u003e and \u003ccode\u003eufw\u003c/code\u003e, two popular Linux firewall management tools. Successful exploitation can lead to a compromised system, unauthorized access to sensitive data, or a wider breach affecting the entire network. The rule is based on research from Splunk and is intended to identify living-off-the-land techniques used for privilege escalation and persistence within a compromised Linux environment. The affected product is the Splunk platform using the Splunk Add-on for Unix and Linux.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Linux system (e.g., via compromised credentials or vulnerability exploitation).\u003c/li\u003e\n\u003cli\u003eAttacker attempts to disable the \u003ccode\u003efirewalld\u003c/code\u003e service using a command-line utility such as \u003ccode\u003esystemctl stop firewalld\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eauditd\u003c/code\u003e daemon logs the \u003ccode\u003eSERVICE_STOP\u003c/code\u003e event with \u003ccode\u003eunit=firewalld\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker attempts to disable the \u003ccode\u003eufw\u003c/code\u003e service using \u003ccode\u003eufw disable\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eauditd\u003c/code\u003e daemon logs the \u003ccode\u003eSERVICE_STOP\u003c/code\u003e event with \u003ccode\u003eunit=ufw\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies firewall rules to allow unauthorized access, potentially using \u003ccode\u003eiptables\u003c/code\u003e or \u003ccode\u003enftables\u003c/code\u003e directly.\u003c/li\u003e\n\u003cli\u003eThese rule modifications further weaken the host defenses.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence and maintains unauthorized access to the system, potentially escalating privileges and exfiltrating sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising the system firewall allows attackers to bypass network segmentation and access other systems. A successful attack can result in complete system compromise, data theft, and further lateral movement within the network. Systems that are critical to business operations, such as database servers or application servers, could be severely impacted. This could lead to significant financial losses, reputational damage, and regulatory fines.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnsure \u003ccode\u003eauditd\u003c/code\u003e is properly configured and ingesting events related to service management on Linux endpoints.\u003c/li\u003e\n\u003cli\u003eInstall and configure the Splunk Add-on for Unix and Linux to properly parse \u003ccode\u003eauditd\u003c/code\u003e logs as described in the \u0026ldquo;How to Implement\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Linux Auditd Disable Or Modify System Firewall\u0026rdquo; to your SIEM and tune based on the filter macros for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the service stop events.\u003c/li\u003e\n\u003cli\u003eReview and harden Linux firewall configurations across the environment to prevent unauthorized modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T10:00:00Z","date_published":"2024-01-03T10:00:00Z","id":"/briefs/2024-01-linux-firewall-modification/","summary":"The analytic detects suspicious disabling or modification of the system firewall on Linux systems, which can indicate unauthorized access or attempts to maintain control over a system by disabling host protections.","title":"Linux Auditd Detects Firewall Modification or Disabling","url":"https://feed.craftedsignal.io/briefs/2024-01-linux-firewall-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Splunk Enterprise","Splunk Enterprise Security","Splunk Cloud","Splunk Add-on for Unix and Linux","Red Hat Enterprise Linux"],"_cs_severities":["medium"],"_cs_tags":["linux","auditd","anomaly"],"_cs_type":"advisory","_cs_vendors":["Splunk","Red Hat"],"content_html":"\u003cp\u003eThis analytic detects the (re)initialization of the Linux audit daemon (auditd) by identifying log entries of type \u003ccode\u003eDAEMON_START\u003c/code\u003e. This event indicates that the audit subsystem has resumed logging after being stopped or has started during system boot. While \u003ccode\u003eDAEMON_START\u003c/code\u003e may be expected during reboots or legitimate configuration changes, it can also signal attempts to re-enable audit logging after evasion, or restarts with modified or reduced rule sets. Monitoring this event in correlation with \u003ccode\u003eDAEMON_END\u003c/code\u003e, \u003ccode\u003eDAEMON_ABORT\u003c/code\u003e, and \u003ccode\u003eauditctl\u003c/code\u003e activity provides visibility into the continuity and integrity of audit logs. Frequent or unexplained \u003ccode\u003eDAEMON_START\u003c/code\u003e events should be investigated, especially if they are not accompanied by valid administrative or system activity. This detection is relevant for environments utilizing auditd for security monitoring and compliance.\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.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies that auditd is enabled and logging events.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to disable auditd to evade detection, possibly using \u003ccode\u003eauditctl -s disable\u003c/code\u003e or similar commands.\u003c/li\u003e\n\u003cli\u003eAfter performing malicious actions, the attacker may attempt to re-enable auditd, potentially with a modified configuration to avoid logging their activities, triggering a \u003ccode\u003eDAEMON_START\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the audit rules to exclude specific users, processes, or file paths from being logged.\u003c/li\u003e\n\u003cli\u003eThe attacker restarts the auditd service using \u003ccode\u003esystemctl restart auditd\u003c/code\u003e or a similar command, generating a \u003ccode\u003eDAEMON_START\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe system resumes logging with the modified audit rules, potentially missing critical security events.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to a compromised Linux host where malicious activities are not properly logged, hindering incident response and forensic investigations. Attackers could manipulate audit logs by stopping and restarting the service with altered configurations, reducing the effectiveness of security monitoring. The impact includes a loss of visibility into attacker actions, potentially leading to prolonged compromise and data breaches.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eLinux Auditd Daemon Start\u003c/code\u003e to your SIEM and tune for your environment to detect unexpected auditd restarts.\u003c/li\u003e\n\u003cli\u003eCorrelate \u003ccode\u003eDAEMON_START\u003c/code\u003e events with \u003ccode\u003eDAEMON_END\u003c/code\u003e and \u003ccode\u003eDAEMON_ABORT\u003c/code\u003e events to identify anomalies in auditd service management.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eauditctl\u003c/code\u003e activity for unauthorized modifications to audit rules.\u003c/li\u003e\n\u003cli\u003eInvestigate frequent or unexplained \u003ccode\u003eDAEMON_START\u003c/code\u003e events, especially those not accompanied by valid administrative or system activity, as highlighted in the overview.\u003c/li\u003e\n\u003cli\u003eEnsure proper ingestion and normalization of auditd logs using the Splunk Add-on for Unix and Linux, as mentioned in the \u0026ldquo;How to Implement\u0026rdquo; section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-linux-auditd-daemon-start/","summary":"Detection of Linux audit daemon (auditd) re-initialization events, which can indicate attempts to re-enable audit logging after evasion or restarts with modified rule sets.","title":"Linux Auditd Daemon (Re)Initialization Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-02-linux-auditd-daemon-start/"}],"language":"en","title":"CraftedSignal Threat Feed — Splunk Add-on for Unix and Linux","version":"https://jsonfeed.org/version/1.1"}