diff --git a/rules/integrations/aws/collection_s3_unauthenticated_bucket_access_by_rare_source.toml b/rules/integrations/aws/collection_s3_unauthenticated_bucket_access_by_rare_source.toml index a05e3d797..ba92d830c 100644 --- a/rules/integrations/aws/collection_s3_unauthenticated_bucket_access_by_rare_source.toml +++ b/rules/integrations/aws/collection_s3_unauthenticated_bucket_access_by_rare_source.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/17" integration = ["aws"] maturity = "production" -updated_date = "2025/01/20" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -20,7 +20,43 @@ index = ["filebeat-*", "logs-aws.cloudtrail*"] language = "kuery" license = "Elastic License v2" name = "AWS S3 Unauthenticated Bucket Access by Rare Source" -note = """## Investigating AWS S3 Unauthenticated Bucket Access by Rare Source +note = """## Triage and analysis + +> **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. + +### Investigating AWS S3 Unauthenticated Bucket Access by Rare Source + +Amazon S3 is a scalable storage service used for data storage and retrieval. Misconfigured bucket policies can inadvertently allow public access, posing a risk of unauthorized data exposure. Adversaries exploit this by using unauthenticated requests to access data. The detection rule identifies unusual access attempts from new IP addresses, signaling potential misuse and prompting further investigation. + +### Possible investigation steps + +- Review the CloudTrail logs to identify the specific S3 bucket involved in the unauthenticated access attempt and determine the nature of the accessed data. +- Examine the source IP address from the `source.address` field to assess its origin and determine if it is associated with known malicious activity or if it is a legitimate but misconfigured source. +- Check the S3 bucket policy and permissions to identify any misconfigurations that might allow public access, focusing on policies that include "Principal": "*". +- Investigate the `aws.cloudtrail.user_identity.type` field to confirm if the access was made by an "AWSAccount" or "Unknown" identity, and determine if this aligns with expected behavior. +- Assess the `event.action` field to understand the type of operation performed (e.g., "GetObject", "PutObject") and evaluate the potential impact of the access. +- Review recent changes to the S3 bucket configuration or IAM policies that might have inadvertently allowed public access, and correlate these with the timing of the alert. +- If unauthorized access is confirmed, take immediate steps to secure the bucket by updating the bucket policy to restrict access and consider enabling logging and monitoring for future access attempts. + +### False positive analysis + +- Frequent access from known internal IP addresses may trigger the rule. To manage this, create exceptions for IP addresses that are part of your organization's network and regularly access S3 buckets without authentication. +- Automated scripts or tools used for legitimate business processes might use unauthenticated requests. Identify these scripts and exclude their IP addresses from triggering the rule by adding them to an allowlist. +- Third-party services that require access to your S3 buckets might appear as unauthenticated sources. Verify these services and, if deemed safe, exclude their IP addresses from the rule to prevent false positives. +- Temporary testing environments or development setups might use unauthenticated access for convenience. Ensure these environments are documented and their IP addresses are excluded from the rule to avoid unnecessary alerts. + +### Response and remediation + +- Immediately revoke public access to the affected S3 bucket by updating the bucket policy to restrict access to only authorized users and roles. +- Identify and terminate any unauthorized sessions or connections from the IP addresses flagged in the alert to prevent further unauthorized access. +- Conduct a thorough review of the S3 bucket's access logs to determine the extent of data exposure and identify any sensitive data that may have been accessed. +- Notify the security team and relevant stakeholders about the potential data exposure incident and provide them with details of the affected resources and actions taken. +- Implement additional monitoring and alerting for unusual access patterns to S3 buckets, focusing on unauthenticated access attempts and access from rare IP addresses. +- Escalate the incident to the organization's incident response team for further investigation and to determine if additional containment or remediation actions are necessary. +- Review and update the organization's cloud security policies and access controls to prevent similar misconfigurations in the future, ensuring that all S3 buckets have appropriate access restrictions. + +## Investigating AWS S3 Unauthenticated Bucket Access by Rare Source This rule detects requests to an AWS S3 bucket by an unauthenticated source, which could indicate a misconfigured bucket policy allowing public access. Adversaries can exploit this misconfiguration by using tools or AWS CLI options like `--no-sign-request` to access bucket contents. diff --git a/rules/linux/discovery_polkit_version_discovery.toml b/rules/linux/discovery_polkit_version_discovery.toml index 05e7f8721..1ea639d81 100644 --- a/rules/linux/discovery_polkit_version_discovery.toml +++ b/rules/linux/discovery_polkit_version_discovery.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -50,6 +50,7 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -62,6 +63,39 @@ event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( (process.name == "pkaction" and process.args == "--version") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating Polkit Version Discovery + +Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers. + +### Possible investigation steps + +- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction". +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target. +- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities. +- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous. + +### False positive analysis + +- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions. +- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule. +- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments. +- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands. +- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities. +- Apply any available security patches or updates to the Polkit service to address known vulnerabilities. +- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_executable_stack_execution.toml b/rules/linux/execution_executable_stack_execution.toml index 2aa82a9f1..db15ac7e5 100644 --- a/rules/linux/execution_executable_stack_execution.toml +++ b/rules/linux/execution_executable_stack_execution.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/07" integration = ["system"] maturity = "production" -updated_date = "2025/01/07" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -44,7 +44,8 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Execution", - "Data Source: System" + "Data Source: System", + "Resources: Investigation Guide" ] timestamp_override = "event.ingested" type = "query" @@ -52,6 +53,40 @@ query = ''' host.os.type:"linux" and event.dataset:"system.syslog" and process.name:"kernel" and message:"started with executable stack" ''' +note = """## Triage and analysis + +> **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. + +### Investigating Process Started with Executable Stack + +In Linux environments, processes with executable stacks can pose security risks as they may allow code execution from the stack, a behavior often exploited by attackers to run arbitrary code. Adversaries might leverage this to execute malicious scripts or commands. The detection rule monitors syslog for kernel messages indicating such processes, flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the syslog entries to identify the specific process that triggered the alert, focusing on the message field containing "started with executable stack". +- Investigate the process name and associated command-line arguments to understand the nature and purpose of the process. +- Check the process's parent process to determine if it was spawned by a legitimate application or service. +- Analyze the user account under which the process is running to assess if it aligns with expected behavior and permissions. +- Look for any recent changes or anomalies in the system that might correlate with the process start time, such as new software installations or configuration changes. +- Cross-reference the process with known threat intelligence sources to identify if it matches any known malicious patterns or indicators. + +### False positive analysis + +- Development tools and environments may intentionally use executable stacks for legitimate purposes, such as certain debugging or testing scenarios. Users can create exceptions for these specific tools by identifying their process names and excluding them from the detection rule. +- Some legacy applications might require executable stacks due to outdated coding practices. Users should verify the necessity of these applications and, if deemed non-threatening, add them to an exclusion list based on their process names or paths. +- Custom scripts or applications developed in-house might inadvertently use executable stacks. Conduct a review of these scripts to ensure they are safe, and if so, exclude them from monitoring by specifying their unique identifiers. +- Certain system utilities or libraries might trigger this rule during normal operations. Users should consult documentation or vendor support to confirm if these are expected behaviors and exclude them accordingly if they pose no risk. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate the suspicious process identified with an executable stack to halt any ongoing malicious activity. +- Conduct a thorough analysis of the process and its associated files to identify any malicious payloads or scripts that may have been executed. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats. +- Implement stack protection mechanisms such as stack canaries or non-executable stack configurations to prevent future exploitation. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_unusual_pkexec_execution.toml b/rules/linux/execution_unusual_pkexec_execution.toml index 620418592..5eb52fac3 100644 --- a/rules/linux/execution_unusual_pkexec_execution.toml +++ b/rules/linux/execution_unusual_pkexec_execution.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/16" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -66,6 +66,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" @@ -74,6 +75,41 @@ event.category:process and host.os.type:linux and event.type:start and event.action:(exec or exec_event or start or ProcessRollup2) and process.name:pkexec and process.args:pkexec and process.parent.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) ''' +note = """## Triage and analysis + +> **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. + +### Investigating Unusual Pkexec Execution + +`Pkexec` is a command-line utility in Linux environments that allows users to execute commands as another user, often with elevated privileges. Adversaries may exploit `pkexec` to escalate privileges or execute unauthorized actions by invoking it through shell processes. The detection rule identifies atypical `pkexec` executions initiated by common shell interpreters, flagging potential misuse by monitoring specific process attributes and execution patterns. + +### Possible investigation steps + +- Review the process tree to understand the context of the pkexec execution, focusing on the parent process names such as bash, dash, sh, tcsh, csh, zsh, ksh, or fish, as these are indicative of shell-based invocations. +- Examine the command-line arguments passed to pkexec to determine the intended action and assess whether it aligns with expected administrative tasks or appears suspicious. +- Check the user account associated with the pkexec execution to verify if the account has legitimate reasons to perform such actions, and investigate any anomalies in user behavior or account activity. +- Investigate the timing and frequency of the pkexec executions to identify patterns or correlations with other suspicious activities or known attack timelines. +- Cross-reference the alert with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Crowdstrike, or SentinelOne to gather additional context and corroborate findings. +- Assess the system's current state for signs of compromise, such as unauthorized changes, unexpected network connections, or the presence of known malicious files or processes. + +### False positive analysis + +- Routine administrative tasks: System administrators may use pkexec for legitimate purposes, such as performing maintenance tasks. To handle this, create exceptions for known administrator accounts or specific maintenance scripts that regularly invoke pkexec. +- Automated scripts: Some automated scripts or cron jobs might use pkexec to perform scheduled tasks. Identify these scripts and exclude their specific process names or paths from the rule to prevent false alerts. +- Software updates: Certain software update processes might use pkexec to apply patches or updates. Monitor and document these processes, then configure exceptions for recognized update mechanisms. +- Development environments: Developers might use pkexec during testing or development. Establish a list of development machines or user accounts and exclude them from the rule to reduce noise. +- Custom user applications: Users may have custom applications that require pkexec for legitimate functionality. Review these applications and whitelist their specific execution patterns to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious `pkexec` processes identified by the alert to halt unauthorized actions or privilege escalation attempts. +- Review and analyze the parent shell process and its command history to understand the context and origin of the `pkexec` execution. +- Reset credentials and review permissions for the user accounts involved to mitigate any unauthorized access or privilege escalation. +- Conduct a thorough scan of the affected system for additional indicators of compromise or persistence mechanisms that may have been deployed. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar `pkexec` misuse attempts in the future, ensuring comprehensive coverage of shell processes and privilege escalation activities.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_boot_file_copy.toml b/rules/linux/persistence_boot_file_copy.toml index 65a286452..f1ffa8af6 100644 --- a/rules/linux/persistence_boot_file_copy.toml +++ b/rules/linux/persistence_boot_file_copy.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -60,6 +60,7 @@ tags = [ "Data Source: Auditd Manager", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -72,6 +73,39 @@ process.name in ("cp", "mv") and process.parent.executable != null and process.a process.parent.args like~ ("/usr/bin/mkinitcpio", "/var/tmp/rpm-tmp.*") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating Boot File Copy +The `/boot` directory in Linux systems is crucial for storing files necessary for booting, such as the kernel. Adversaries may exploit this by copying or moving files to alter the boot process, potentially gaining persistent access. The 'Boot File Copy' detection rule identifies suspicious file operations in this directory, excluding legitimate processes, to flag potential unauthorized modifications. + +### Possible investigation steps + +- Review the process details to identify the specific file operation by examining the process name and arguments, particularly focusing on the use of 'cp' or 'mv' commands with paths involving '/boot/*'. +- Investigate the parent process executable and name to determine if the operation was initiated by a known legitimate process or script, ensuring it is not one of the excluded processes like 'update-initramfs' or 'grub-mkconfig'. +- Check the user account associated with the process to assess whether it is a privileged account and if the activity aligns with typical user behavior. +- Analyze recent system logs and audit records for any other suspicious activities or anomalies around the time of the alert to identify potential patterns or related events. +- Verify the integrity and authenticity of the files in the /boot directory to ensure no unauthorized modifications have been made, focusing on critical files like the kernel and initramfs images. +- If possible, correlate the alert with other data sources such as Elastic Endgame or Crowdstrike to gather additional context and confirm whether this is part of a broader attack pattern. + +### False positive analysis + +- System updates and maintenance tasks often involve legitimate processes that interact with the /boot directory. Processes like update-initramfs, dracut, and grub-mkconfig are common during these operations. Users can exclude these processes by adding them to the exception list in the detection rule. +- Custom scripts or administrative tasks that require copying or moving files to the /boot directory may trigger false positives. Identify these scripts and add their parent process names or paths to the exclusion criteria. +- Package management operations, such as those involving dpkg or rpm, may also interact with the /boot directory. Exclude paths like /var/lib/dpkg/info/* and /var/tmp/rpm-tmp.* to prevent these from being flagged. +- Temporary system recovery or installation processes might use directories like /tmp/newroot. Exclude these paths to avoid unnecessary alerts during legitimate recovery operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized 'cp' or 'mv' operations in the /boot directory. +- Conduct a thorough review of the /boot directory to identify and remove any unauthorized files or modifications. Restore any altered files from a known good backup if necessary. +- Check for any unauthorized changes to boot configuration files, such as GRUB or LILO, and restore them to their original state. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized access attempts or modifications. +- Review and update access controls and permissions for the /boot directory to ensure only authorized processes and users can make changes.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_dbus_service_creation.toml b/rules/linux/persistence_dbus_service_creation.toml index 739487ac3..cf7b3a78f 100644 --- a/rules/linux/persistence_dbus_service_creation.toml +++ b/rules/linux/persistence_dbus_service_creation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -57,6 +57,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: SentinelOne", "Data Source: Elastic Endgame", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -95,6 +96,41 @@ file.extension in ("service", "conf") and file.path like~ ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating D-Bus Service Created + +D-Bus is an inter-process communication system in Linux, enabling applications to communicate. Adversaries may exploit D-Bus by creating unauthorized service files to maintain persistence or escalate privileges. The detection rule identifies suspicious service file creations in key directories, excluding known legitimate processes, to flag potential malicious activity. + +### Possible investigation steps + +- Review the file path and extension to confirm if the created file is located in one of the monitored directories such as /usr/share/dbus-1/system-services/ or /etc/dbus-1/system.d/, and ensure it has a .service or .conf extension. +- Examine the process executable that created the file to determine if it is listed as a known legitimate process in the exclusion list. If not, investigate the process further to understand its origin and purpose. +- Check the process name and path for any unusual or unexpected patterns, especially if it is not part of the known exclusions like ssm-agent-worker or platform-python*. +- Investigate the file creation time and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of the alert. +- Look into the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Search for any related alerts or logs that might indicate a broader attack pattern, such as other unauthorized file creations or modifications in the system. + +### False positive analysis + +- Package manager operations can trigger false positives when legitimate service files are created during software installations or updates. To manage this, exclude processes associated with known package managers like dpkg, rpm, and yum from the detection rule. +- System service updates may also result in false positives. Exclude processes such as systemd and crond that are responsible for legitimate system service management. +- Development and testing environments often involve the creation of temporary or test service files. Exclude paths and processes specific to these environments, such as those under /tmp or /dev/fd, to reduce noise. +- Automation tools like Puppet and Chef can create service files as part of their configuration management tasks. Exclude these tools by adding their executable paths to the exception list. +- Custom scripts or tools that mimic package manager behavior might also cause false positives. Identify and exclude these specific scripts or tools by their process names or paths if they are known to be benign. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes associated with the creation of unauthorized D-Bus service files to halt potential malicious activity. +- Remove any unauthorized D-Bus service files identified in the specified directories to eliminate persistence mechanisms. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred. +- Restore the system from a known good backup if unauthorized changes or damage to the system are detected. +- Monitor the system and network for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml b/rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml index 18c5fc3cc..3ed85e11d 100644 --- a/rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml +++ b/rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/21" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -56,6 +56,7 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -68,6 +69,41 @@ process.parent.name == "dbus-daemon" and process.args_count > 1 and not ( process.executable like~ ("/usr/lib/*", "/usr/local/lib/*", "/usr/libexec/*", "/tmp/newroot/*") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating Unusual D-Bus Daemon Child Process + +The D-Bus daemon is a crucial component in Linux environments, facilitating inter-process communication by allowing applications to exchange information. Adversaries may exploit this by spawning unauthorized child processes to execute malicious code or gain elevated privileges. The detection rule identifies anomalies by monitoring child processes of the D-Bus daemon, excluding known benign processes and paths, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process details to identify the unusual child process spawned from the dbus-daemon, focusing on the process name and executable path to determine if it is known or potentially malicious. +- Examine the command-line arguments (process.args) of the unusual child process to understand its intended function and assess if it aligns with typical usage patterns. +- Investigate the parent process arguments (process.parent.args) to confirm whether the dbus-daemon was running in a session context or another mode that might explain the unusual child process. +- Check the process start time and correlate it with other system events or logs to identify any related activities or anomalies occurring around the same time. +- Look into the user context under which the unusual child process was executed to determine if it was initiated by a legitimate user or potentially compromised account. +- Search for any network connections or file modifications associated with the unusual child process to identify potential data exfiltration or lateral movement activities. + +### False positive analysis + +- Known benign processes such as gnome-keyring-daemon and abrt-dbus may trigger the rule. Users can exclude these processes by adding them to the exception list in the detection rule. +- Processes executed from common library paths like /usr/lib/ or /usr/local/lib/ are typically non-threatening. Users should review these paths and consider excluding them if they are consistently generating false positives. +- The dbus-daemon with the --session argument is generally safe. Users can ensure this argument is included in the exception criteria to prevent unnecessary alerts. +- Specific applications like software-properties-dbus and serviceHelper.py are known to be benign. Users should verify these applications' legitimacy in their environment and exclude them if they are frequently flagged. +- Regularly review and update the exception list to include any new benign processes or paths that are identified over time, ensuring the rule remains effective without generating excessive false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious child processes spawned by the dbus-daemon that are not recognized as legitimate or necessary for system operations. +- Conduct a thorough review of the affected system's logs to identify any unauthorized access or changes made by the suspicious process. +- Restore any altered or compromised system files from a known good backup to ensure system integrity. +- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring on the dbus-daemon to prevent unauthorized process execution in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_dracut_module_creation.toml b/rules/linux/persistence_dracut_module_creation.toml index 01f7f2377..80ce77595 100644 --- a/rules/linux/persistence_dracut_module_creation.toml +++ b/rules/linux/persistence_dracut_module_creation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -53,6 +53,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: SentinelOne", "Data Source: Elastic Endgame", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -80,6 +81,41 @@ file.path like~ ("/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*") and n (process.name == "sed" and file.name : "sed*") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating Dracut Module Creation + +Dracut is a utility for generating initramfs images, crucial for booting Linux systems. It uses modules, which are scripts executed during image creation. Adversaries may exploit this by crafting malicious modules to execute code at boot, ensuring persistence. The detection rule identifies unauthorized module creation by monitoring file paths and excluding known legitimate processes, helping to flag potential threats. + +### Possible investigation steps + +- Review the file path of the created Dracut module to determine if it matches known legitimate paths or if it appears suspicious, focusing on paths like "/lib/dracut/modules.d/*" and "/usr/lib/dracut/modules.d/*". +- Identify the process that created the Dracut module by examining the process.executable field, and verify if it is listed in the known legitimate processes or if it is an unexpected process. +- Check the file extension of the created module to ensure it is not one of the excluded extensions such as "swp", "swpx", "swx", or "dpkg-remove". +- Investigate the history and behavior of the process that created the module, including its parent process and any associated network activity, to assess if it has been involved in other suspicious activities. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest malicious activity. +- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or file path involved in the alert. + +### False positive analysis + +- Package managers like dpkg, rpm, and yum may trigger false positives when they update or install packages. To handle this, ensure these processes are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can create or modify Dracut modules as part of their configuration management tasks. Add these tools to the exclusion list to prevent false alerts. +- System updates or maintenance scripts that run as part of regular system operations might be flagged. Review these scripts and add their executables to the exclusion list if they are verified as non-threatening. +- Custom scripts or applications that interact with Dracut modules for legitimate purposes should be reviewed and, if deemed safe, added to the exclusion list to avoid unnecessary alerts. +- Temporary files or backup files with extensions like swp or dpkg-remove may be mistakenly flagged. Ensure these extensions are included in the exclusion criteria to reduce false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Conduct a thorough review of the Dracut module files located in the specified directories (/lib/dracut/modules.d/*, /usr/lib/dracut/modules.d/*) to identify and remove any unauthorized or suspicious modules. +- Restore the system from a known good backup if malicious Dracut modules are confirmed, ensuring that the backup predates the unauthorized changes. +- Implement additional monitoring on the affected system to detect any further unauthorized Dracut module creation or other suspicious activities. +- Review and tighten access controls and permissions for the directories and processes involved in Dracut module creation to prevent unauthorized modifications. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance detection capabilities to include alerts for any future unauthorized Dracut module creation attempts, leveraging the specific indicators identified in this incident.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_extract_initramfs_via_cpio.toml b/rules/linux/persistence_extract_initramfs_via_cpio.toml index 5c6e3982a..bd4c2e51b 100644 --- a/rules/linux/persistence_extract_initramfs_via_cpio.toml +++ b/rules/linux/persistence_extract_initramfs_via_cpio.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -59,6 +59,7 @@ tags = [ "Data Source: Auditd Manager", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -70,6 +71,40 @@ process.name == "cpio" and process.args in ("-H", "--format") and process.args = process.parent.executable like~ ("/usr/share/initramfs-tools/*", "/nix/store/*") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating Initramfs Extraction via CPIO + +Initramfs is a temporary filesystem used during the Linux boot process, containing essential drivers and scripts. Attackers may exploit the `cpio` command to extract and modify initramfs, embedding malicious files to ensure persistence. The detection rule identifies suspicious `cpio` usage by monitoring process execution patterns, excluding legitimate parent processes, to flag potential threats. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the cpio command with arguments "-H" or "--format" and "newc" to ensure the alert is not a false positive. +- Investigate the parent process of the cpio command to determine if it is an unexpected or unauthorized process, as legitimate processes like mkinitramfs or dracut should be excluded. +- Check the execution path of the parent process to verify if it matches any known legitimate paths such as "/usr/share/initramfs-tools/*" or "/nix/store/*". +- Analyze the timeline of events around the cpio execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or persistence mechanism. +- Examine the system for any unauthorized modifications or additions to the initramfs image that could indicate tampering or the presence of malicious files. +- Correlate the alert with other security data sources like Elastic Endgame, Elastic Defend, or Crowdstrike to gather additional context and assess the scope of the potential threat. + +### False positive analysis + +- Legitimate system updates or maintenance activities may trigger the rule when tools like mkinitramfs or dracut are used. To handle this, ensure these processes are excluded by verifying that the parent process is mkinitramfs or dracut. +- Custom scripts or automation tools that manage initramfs might use cpio in a non-malicious context. Review these scripts and add their parent process names or paths to the exclusion list if they are verified as safe. +- Systems using non-standard initramfs management tools located in directories like /usr/share/initramfs-tools or /nix/store may cause false positives. Confirm these tools' legitimacy and update the exclusion paths accordingly. +- Development or testing environments where initramfs is frequently modified for legitimate reasons can generate alerts. Consider creating environment-specific exceptions to reduce noise while maintaining security in production systems. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware. +- Terminate any suspicious processes related to the `cpio` command that do not have legitimate parent processes, such as `mkinitramfs` or `dracut`. +- Conduct a thorough review of the extracted initramfs contents to identify and remove any unauthorized or malicious files. +- Restore the initramfs from a known good backup to ensure system integrity and remove any potential persistence mechanisms. +- Monitor the system for any further suspicious activity, particularly related to the `cpio` command, to ensure the threat has been fully mitigated. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Update security policies and procedures to include specific checks for unauthorized `cpio` usage and enhance detection capabilities for similar threats.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_grub_configuration_creation.toml b/rules/linux/persistence_grub_configuration_creation.toml index 2d3dfa3a9..44f71f9b1 100644 --- a/rules/linux/persistence_grub_configuration_creation.toml +++ b/rules/linux/persistence_grub_configuration_creation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -53,6 +53,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: SentinelOne", "Data Source: Elastic Endgame", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -83,6 +84,41 @@ file where host.os.type == "linux" and event.type == "creation" and process.exec (process.name == "sed" and file.name : "sed*") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating GRUB Configuration File Creation + +GRUB (Grand Unified Bootloader) is crucial for booting Linux systems, managing the boot process, and loading the OS. Adversaries may exploit GRUB by creating or altering configuration files to execute unauthorized code or gain elevated privileges, ensuring persistence. The detection rule identifies suspicious creation of GRUB files, excluding legitimate processes, to flag potential security threats. + +### Possible investigation steps + +- Review the file path and name to determine if it matches any known GRUB configuration files, as specified in the query (e.g., "/etc/default/grub", "/boot/grub2/grub.cfg"). +- Identify the process that created the file by examining the process.executable field, ensuring it is not one of the excluded legitimate processes. +- Check the timestamp of the file creation event to correlate it with any other suspicious activities or changes in the system around the same time. +- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Analyze the contents of the newly created or modified GRUB configuration file for any unauthorized or suspicious entries that could indicate malicious intent. +- Cross-reference the event with other security logs or alerts to identify any related activities or patterns that could suggest a broader attack or compromise. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum may trigger false positives when they update or modify GRUB configuration files during routine package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they manage GRUB configurations as part of their configuration management tasks. Consider adding these tools to the exclusion list if they are part of your environment. +- Virtualization and containerization tools like Docker, Podman, and VirtualBox might modify GRUB files as part of their operations. Verify these processes and exclude them if they are legitimate in your setup. +- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for GRUB configuration files. Ensure these extensions are part of the exclusion criteria to prevent unnecessary alerts. +- Custom scripts or administrative tasks that modify GRUB configurations for legitimate reasons should be reviewed and, if deemed safe, added to the exclusion list to avoid repeated false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access. +- Review the GRUB configuration files identified in the alert to confirm unauthorized modifications or creations. Restore any altered files from a known good backup if necessary. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or backdoors that may have been introduced. +- Change all system and user passwords on the affected machine to prevent unauthorized access using potentially compromised credentials. +- Monitor the system for any further suspicious activity, particularly focusing on processes attempting to modify GRUB configuration files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional logging and monitoring for GRUB configuration changes to enhance detection capabilities and prevent future unauthorized modifications.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_grub_makeconfig.toml b/rules/linux/persistence_grub_makeconfig.toml index 80e42fd02..9b8d54398 100644 --- a/rules/linux/persistence_grub_makeconfig.toml +++ b/rules/linux/persistence_grub_makeconfig.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -52,6 +52,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -65,6 +66,39 @@ process.parent.executable != null and process.name in ("grub-mkconfig", "grub2-m ) ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating GRUB Configuration Generation through Built-in Utilities + +GRUB, the Grand Unified Bootloader, is crucial for loading the Linux kernel during system startup. It uses configuration files to determine boot parameters. Adversaries may exploit utilities like `grub-mkconfig` to alter these files, embedding malicious parameters for persistence. The detection rule identifies suspicious executions of these utilities, especially when initiated by atypical parent processes, signaling potential misuse. + +### Possible investigation steps + +- Review the process execution details to identify the parent process of the suspicious GRUB configuration utility execution. Check if the parent process is unusual or unexpected based on the query's exclusion list. +- Examine the command-line arguments used in the execution of the GRUB configuration utility to identify any potentially malicious kernel parameters or boot options. +- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. +- Check the system's recent changes or updates, especially those related to bootloader configurations, to identify any unauthorized modifications. +- Analyze system logs for any other suspicious activities or anomalies around the time of the GRUB configuration utility execution to gather additional context. + +### False positive analysis + +- Routine system updates or maintenance tasks may trigger the rule when legitimate processes like package managers (e.g., pacman, dnf, yum) or system utilities (e.g., sudo) execute GRUB configuration commands. Users can mitigate this by adding these processes to the exception list in the rule configuration. +- Automated scripts or cron jobs that regularly update GRUB configurations for legitimate reasons might be flagged. To handle this, identify these scripts and add their parent process names or paths to the exclusion criteria. +- Custom administrative scripts that manage bootloader settings could also cause false positives. Review these scripts and, if verified as safe, include their parent process details in the rule's exceptions. +- Some Linux distributions may have specific utilities or services that interact with GRUB as part of their normal operation. Investigate these utilities and consider excluding them if they are confirmed to be benign and necessary for system functionality. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes related to `grub-mkconfig`, `grub2-mkconfig`, or `update-grub` that were initiated by atypical parent processes. +- Review and restore the GRUB configuration file from a known good backup to ensure no malicious parameters are present. +- Conduct a thorough examination of the system for additional signs of compromise, focusing on persistence mechanisms and unauthorized changes to boot parameters. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement monitoring for future unauthorized executions of GRUB configuration utilities, ensuring alerts are generated for similar suspicious activities. +- Review and update access controls and permissions to restrict the execution of GRUB configuration utilities to authorized personnel only.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_manual_dracut_execution.toml b/rules/linux/persistence_manual_dracut_execution.toml index ac8590656..8f9cadc0c 100644 --- a/rules/linux/persistence_manual_dracut_execution.toml +++ b/rules/linux/persistence_manual_dracut_execution.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -56,6 +56,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -74,6 +75,39 @@ process.name == "dracut" and process.parent.executable != null and not ( process.parent.command_line like~ "/bin/sh -c if command -v mkinitcpio*" ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating Manual Dracut Execution + +Dracut is a utility in Linux systems used to create initramfs images, essential for booting. Adversaries might exploit Dracut to craft malicious initramfs, embedding backdoors for persistence. The detection rule identifies unusual Dracut executions by scrutinizing process origins and excluding legitimate parent processes, flagging potential unauthorized use. + +### Possible investigation steps + +- Review the process details to confirm the execution of the dracut command, focusing on the process.name and process.parent.executable fields to identify any unusual parent processes. +- Examine the command line arguments used with the dracut process by checking the process.parent.command_line field to understand the context of its execution. +- Investigate the user account associated with the dracut execution to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access. +- Check the system logs and any related security alerts around the time of the dracut execution to identify any correlated suspicious activities or anomalies. +- Assess the system for any changes to the initramfs image or other boot-related files that could indicate tampering or the presence of backdoors. + +### False positive analysis + +- Legitimate system updates or kernel installations may trigger the rule. To handle this, users can create exceptions for processes originating from known update paths like /usr/lib/kernel/* or /etc/kernel/install.d/*. +- Automated scripts or maintenance tasks that use dracut for legitimate purposes might be flagged. Users should identify these scripts and add their parent process names, such as dracut-install or run-parts, to the exclusion list. +- Custom administrative scripts executed by trusted users could be mistaken for suspicious activity. Users can exclude specific command lines or arguments associated with these scripts, such as /usr/bin/dracut-rebuild, to prevent false positives. +- Temporary or testing environments where dracut is used for non-malicious testing purposes might trigger alerts. Users can exclude these environments by specifying unique parent process paths or names that are characteristic of the testing setup. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious or unauthorized dracut processes identified on the system to halt any ongoing malicious activity. +- Conduct a thorough review of the initramfs images on the affected system to identify and remove any unauthorized or malicious modifications. +- Restore the system's initramfs from a known good backup to ensure the integrity of the boot process. +- Implement monitoring for any future unauthorized dracut executions by setting up alerts for similar process activities, ensuring quick detection and response. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions to limit the ability to execute dracut to only authorized personnel, reducing the risk of future exploitation.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_network_manager_dispatcher_persistence.toml b/rules/linux/persistence_network_manager_dispatcher_persistence.toml index 854146308..c0f3fb5b5 100644 --- a/rules/linux/persistence_network_manager_dispatcher_persistence.toml +++ b/rules/linux/persistence_network_manager_dispatcher_persistence.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -57,6 +57,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: SentinelOne", "Data Source: Elastic Endgame", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -83,6 +84,40 @@ file where host.os.type == "linux" and event.type == "creation" and file.path li (process.name == "sed" and file.name : "sed*") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating NetworkManager Dispatcher Script Creation + +NetworkManager dispatcher scripts are executed on Linux systems when network interfaces change state, allowing for automated responses to network events. Adversaries can exploit this by creating scripts that execute malicious code, ensuring persistence and evasion. The detection rule identifies unauthorized script creation by monitoring file creation events in the dispatcher directory, excluding known legitimate processes and file types, thus highlighting potential abuse. + +### Possible investigation steps + +- Review the file creation event details to identify the specific script created in the /etc/NetworkManager/dispatcher.d/ directory, noting the file path and name. +- Examine the process that created the script by checking the process.executable field to determine if it is an unexpected or suspicious process not listed in the known legitimate processes. +- Investigate the contents of the newly created script to identify any potentially malicious code or commands that could indicate an attempt to maintain persistence or execute unauthorized actions. +- Check the system's recent network events and changes to see if the script has been triggered and executed, which could provide further context on its intended use. +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. + +### False positive analysis + +- Package management tools like dpkg, rpm, and yum may trigger false positives when they create or modify dispatcher scripts during software installations or updates. To handle these, ensure that the process executables for these tools are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they deploy or update configurations. Verify that the executables for these tools are part of the exclusion criteria to prevent unnecessary alerts. +- Temporary files created by text editors like Vim may be mistakenly flagged. These files typically have extensions like swp or swpx. Ensure these extensions are included in the exclusion list to avoid false positives. +- Custom scripts or applications that are known to create or modify dispatcher scripts for legitimate purposes should be reviewed. If deemed safe, add their process executables to the exclusion list to prevent them from being flagged. +- Consider monitoring the frequency and context of script creation events. If certain scripts are frequently created by known processes, evaluate the need to adjust the rule to reduce noise while maintaining security efficacy. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit the attacker's ability to maintain persistence. +- Review and remove any unauthorized scripts found in the /etc/NetworkManager/dispatcher.d/ directory to eliminate the immediate threat. +- Conduct a thorough examination of the system for additional signs of compromise, such as unexpected processes or network connections, to identify any further malicious activity. +- Restore any affected systems from a known good backup to ensure the removal of any persistent threats that may have been established. +- Implement stricter access controls and monitoring on the /etc/NetworkManager/dispatcher.d/ directory to prevent unauthorized script creation in the future. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats, leveraging the MITRE ATT&CK framework for guidance on persistence and execution techniques.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_openssl_passwd_hash_generation.toml b/rules/linux/persistence_openssl_passwd_hash_generation.toml index 9d9927f15..f4dd830d1 100644 --- a/rules/linux/persistence_openssl_passwd_hash_generation.toml +++ b/rules/linux/persistence_openssl_passwd_hash_generation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -57,6 +57,7 @@ tags = [ "Data Source: Auditd Manager", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -65,6 +66,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and process.name == "openssl" and process.args == "passwd" ''' +note = """## Triage and analysis + +> **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. + +### Investigating OpenSSL Password Hash Generation + +OpenSSL is a robust cryptographic toolkit used for secure communications and data protection, including generating password hashes. Adversaries may exploit OpenSSL to create hashes for unauthorized user accounts or modify existing ones, aiding in persistent access to Linux systems. The detection rule identifies suspicious OpenSSL executions by monitoring specific process actions and arguments, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the "openssl" command with the "passwd" argument, as this indicates an attempt to generate a password hash. +- Identify the user account associated with the process execution to determine if the action was performed by a legitimate user or a potential adversary. +- Check the system logs and user activity around the time of the alert to identify any suspicious behavior or unauthorized access attempts. +- Investigate any recent changes to user accounts on the system, focusing on new account creations or password modifications that coincide with the alert. +- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the detected activity by considering the context of the system and its role within the organization, as well as any potential data exposure or system access implications. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators use OpenSSL to generate password hashes for legitimate user account management. To handle this, create exceptions for specific administrator accounts or processes that are known to perform these tasks regularly. +- Automated scripts for user account provisioning or maintenance that utilize OpenSSL for password hashing can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule. +- Security tools or compliance checks that periodically verify password strength or integrity using OpenSSL might be flagged. Review these tools and whitelist their operations to prevent unnecessary alerts. +- Development environments where OpenSSL is used for testing password hashing functions can generate alerts. Exclude these environments or specific test accounts from monitoring to reduce noise. +- Scheduled tasks or cron jobs that involve OpenSSL for password management purposes should be identified and excluded if they are part of regular system operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious OpenSSL processes identified by the detection rule to halt ongoing unauthorized password hash generation. +- Conduct a thorough review of user accounts on the affected system to identify any unauthorized accounts or changes to existing accounts, and revert any unauthorized modifications. +- Change passwords for all user accounts on the affected system, especially those with elevated privileges, to ensure that any compromised credentials are no longer valid. +- Implement additional monitoring on the affected system to detect any further unauthorized use of OpenSSL or similar tools, focusing on process execution and command-line arguments. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, and to assess potential impacts on other systems. +- Review and update access controls and authentication mechanisms to enhance security and prevent similar incidents in the future, ensuring that only authorized users can perform sensitive operations.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_polkit_policy_creation.toml b/rules/linux/persistence_polkit_policy_creation.toml index b56f8df6a..5b5dec3e7 100644 --- a/rules/linux/persistence_polkit_policy_creation.toml +++ b/rules/linux/persistence_polkit_policy_creation.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/16" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -28,6 +28,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: SentinelOne", "Data Source: Elastic Endgame", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -66,6 +67,41 @@ process.executable like~ ( ) ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating Polkit Policy Creation + +Polkit, or PolicyKit, is a system service in Linux environments that manages system-wide privileges, allowing non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by creating or modifying policy files to gain unauthorized access or maintain persistence. The detection rule monitors the creation of these files in critical directories, excluding known legitimate processes, to identify potential malicious activity. + +### Possible investigation steps + +- Review the file path and extension to confirm if the created file is located in one of the critical directories specified in the query, such as /etc/polkit-1/rules.d/ or /usr/share/polkit-1/actions/. +- Identify the process executable responsible for the file creation and verify if it is listed in the exclusion list of known legitimate processes. If not, this may warrant further investigation. +- Check the timestamp of the file creation event to determine if it coincides with any known maintenance or update activities, which could explain the file creation. +- Investigate the user account associated with the process that created the file to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. +- Examine any recent changes or updates to the system that might have triggered the creation of the Polkit policy file, such as software installations or configuration changes. +- Look for any related alerts or logs that might indicate a broader pattern of suspicious activity, such as unauthorized access attempts or other policy modifications. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum may create or modify Polkit policy files during legitimate software installations or updates. To handle these, ensure that the rule excludes processes associated with these package managers as specified in the rule's exception list. +- Container management tools such as Docker and Podman might also trigger false positives when managing containerized applications. Users should verify that these executables are included in the exclusion list to prevent unnecessary alerts. +- Automation tools like Puppet and Chef can modify policy files as part of their configuration management tasks. Confirm that these processes are part of the exclusion criteria to avoid false positives. +- Snap package installations and updates can lead to the creation of policy files. Ensure that paths related to Snap are covered in the exclusion patterns to minimize false alerts. +- Virtualization software such as VirtualBox may interact with Polkit policy files. Users should check that relevant paths and executables are included in the exceptions to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as creating or modifying Polkit policy files, especially those not listed in the known legitimate processes. +- Review and restore the integrity of the Polkit policy files by comparing them against a known good baseline or backup to ensure no unauthorized changes persist. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create or modify Polkit policy files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update access controls and permissions related to Polkit policy files to ensure only authorized processes and users can create or modify these files, reducing the risk of future exploitation.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_systemd_shell_execution.toml b/rules/linux/persistence_systemd_shell_execution.toml index 898845fd0..3a99e1bc8 100644 --- a/rules/linux/persistence_systemd_shell_execution.toml +++ b/rules/linux/persistence_systemd_shell_execution.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/16" integration = ["endpoint"] maturity = "production" -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -52,6 +52,7 @@ tags = [ "Tactic: Persistence", "Tactic: Privilege Escalation", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -60,6 +61,39 @@ process where host.os.type == "linux" and event.type == "info" and event.action process.parent.name == "systemd" and process.name in ("bash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.parent.command_line == "/sbin/init" and process.args_count >= 2 ''' +note = """## Triage and analysis + +> **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. + +### Investigating Systemd Shell Execution During Boot + +Systemd is a critical component in Linux, managing system and service initialization during boot. Adversaries may exploit systemd to execute shell commands at startup, ensuring persistence and potential privilege escalation. The detection rule identifies suspicious shell executions by monitoring processes initiated by systemd, focusing on those with specific characteristics indicative of unauthorized activity. + +### Possible investigation steps + +- Review the process details to confirm the parent process is indeed systemd and the command line used is "/sbin/init" to ensure the alert is not a false positive. +- Examine the specific shell process name (e.g., bash, sh, etc.) and its arguments to identify any unusual or suspicious commands being executed. +- Investigate the history and configuration of the systemd service or unit file associated with the suspicious process to determine if it has been modified or created recently. +- Check for any recent changes or anomalies in the initramfs or GRUB bootloader configurations that could indicate tampering or unauthorized modifications. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest a broader attack or persistence mechanism. + +### False positive analysis + +- Legitimate system maintenance scripts may trigger this rule if they are executed by systemd during boot. Users can create exceptions for known maintenance scripts by identifying their specific command lines and excluding them from the detection rule. +- Custom user scripts that are intentionally set to run at boot for automation purposes might be flagged. To handle this, users should document these scripts and adjust the rule to exclude their specific process names or command lines. +- Some Linux distributions may use shell scripts for legitimate boot-time operations. Users should verify the distribution's default boot scripts and exclude them if they are known to be safe and necessary for system operation. +- System updates or package installations that modify boot processes could cause false positives. Users should monitor for these events and temporarily adjust the rule to prevent unnecessary alerts during known update windows. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious shell processes identified as being executed by systemd during boot to halt potential malicious activity. +- Conduct a thorough review of systemd service files and configurations to identify and remove any unauthorized or malicious entries. +- Restore any modified system files or configurations from a known good backup to ensure system integrity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of the threat. +- Review and update access controls and permissions to limit the ability of unauthorized users to modify systemd configurations or execute shell commands during boot.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml b/rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml index dc335df9e..2ff447924 100644 --- a/rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml +++ b/rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/16" +updated_date = "2025/01/22" [rule] author = ["Elastic"] @@ -60,6 +60,7 @@ tags = [ "Data Source: Auditd Manager", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -68,6 +69,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and process.name == "unmkinitramfs" ''' +note = """## Triage and analysis + +> **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. + +### Investigating Initramfs Unpacking via unmkinitramfs + +Initramfs is a crucial component in Linux boot processes, containing essential drivers and scripts. The `unmkinitramfs` tool extracts its contents, which attackers might exploit to insert malicious code, ensuring persistence. The detection rule identifies the execution of `unmkinitramfs`, flagging potential unauthorized modifications by monitoring process initiation events on Linux systems. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the unmkinitramfs command, focusing on the process.name field to ensure it matches "unmkinitramfs". +- Check the user context under which the unmkinitramfs command was executed to determine if it aligns with expected administrative activities or if it was run by an unauthorized user. +- Investigate the parent process of the unmkinitramfs execution to understand how the command was initiated and if it was part of a legitimate script or an unexpected process chain. +- Examine recent system logs and audit logs for any other suspicious activities or anomalies around the time of the unmkinitramfs execution, such as unauthorized access attempts or changes to critical system files. +- Assess the integrity of the initramfs image by comparing it with a known good version, if available, to identify any unauthorized modifications or inclusions of malicious code. + +### False positive analysis + +- Routine system maintenance or updates may trigger the rule when legitimate processes unpack initramfs for kernel updates. Users can create exceptions for known maintenance scripts or processes that regularly perform these actions. +- Automated backup or recovery solutions might use unmkinitramfs to verify or restore system images. Identify and exclude these processes if they are part of trusted backup operations. +- Developers or system administrators testing or customizing initramfs images for legitimate purposes could trigger the rule. Establish a whitelist for specific user accounts or scripts that are authorized to perform these tasks. +- Security tools or monitoring solutions that analyze initramfs contents for integrity checks might inadvertently trigger the rule. Ensure these tools are recognized and excluded from detection to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the attacker. +- Terminate any suspicious processes related to `unmkinitramfs` to halt any ongoing malicious activity. +- Conduct a thorough review of the initramfs image and its contents to identify and remove any unauthorized modifications or malicious code. +- Restore the initramfs image from a known good backup to ensure system integrity and remove any potential backdoors. +- Monitor the system for any further attempts to execute `unmkinitramfs` and investigate any such occurrences to determine if they are legitimate or part of an ongoing attack. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement additional logging and monitoring for process execution events on Linux systems to enhance detection capabilities for similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/defense_evasion_right_to_left_override.toml b/rules/windows/defense_evasion_right_to_left_override.toml index ab81e74d0..b9666969c 100644 --- a/rules/windows/defense_evasion_right_to_left_override.toml +++ b/rules/windows/defense_evasion_right_to_left_override.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/20" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/20" +updated_date = "2025/01/22" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -38,6 +38,7 @@ tags = [ "Data Source: Sysmon", "Data Source: Microsoft Defender for Endpoint", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" @@ -49,6 +50,41 @@ any where host.os.type == "windows" and event.category in ("file", "process") an (event.type == "start" and process.name : "*\u{202E}*") ) ''' +note = """## Triage and analysis + +> **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. + +### Investigating File with Right-to-Left Override Character (RTLO) Created/Executed + +The RTLO character reverses text direction, often used to disguise file extensions, making malicious files appear benign. Adversaries exploit this to trick users into executing harmful files. The detection rule identifies suspicious file or process activities on Windows systems by scanning for RTLO characters in file paths or process names, helping to uncover potential masquerading attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific file path or process name containing the RTLO character by examining the file.path or process.name fields. +- Check the event.type field to determine whether the alert was triggered by a file creation or process start event, which can help prioritize the investigation focus. +- Investigate the origin of the file or process by examining the file's creation time, user account involved, and any associated network activity to identify potential sources or delivery methods. +- Analyze the file or process for malicious behavior by using endpoint detection tools or sandbox environments to execute and monitor its actions. +- Cross-reference the file or process with threat intelligence databases to check for known malicious indicators or similar attack patterns. +- Review system logs and other security alerts around the same timeframe to identify any additional suspicious activities or related incidents. + +### False positive analysis + +- Legitimate software installations or updates may use RTLO characters in file names to manage versioning or localization, which can trigger false positives. Users can create exceptions for known software vendors or specific installation directories to reduce these alerts. +- Some file management or backup applications might use RTLO characters in temporary file names for internal processing. Identifying these applications and excluding their specific file paths from monitoring can help minimize false positives. +- Custom scripts or tools developed in-house might inadvertently use RTLO characters for legitimate purposes. Reviewing these scripts and excluding their execution paths or file names from the detection rule can prevent unnecessary alerts. +- Certain international or multilingual applications may use RTLO characters as part of their normal operation. Users should identify these applications and configure exceptions based on their file paths or process names to avoid false positives. +- In environments where file names are dynamically generated and may include RTLO characters, consider implementing a whitelist of trusted file paths or process names to reduce the likelihood of false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes identified with the RTLO character in their names to halt any ongoing malicious activity. +- Quarantine the files containing the RTLO character to prevent execution and further analysis. +- Conduct a thorough scan of the isolated system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and analyze system logs and security alerts to determine the extent of the compromise and identify any lateral movement or additional affected systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary. +- Implement enhanced monitoring and detection rules to identify future attempts to use RTLO characters for masquerading, ensuring that similar threats are detected promptly.""" [[rule.threat]]