From ed784ec5392c6abdfad62de47e0067d64bd32d66 Mon Sep 17 00:00:00 2001 From: Aegrah Date: Wed, 12 Mar 2025 11:27:12 +0100 Subject: [PATCH 1/8] [D4C Conversion] Converting Compatible D4C Rules to DR --- ...s_aws_creds_search_inside_a_container.toml | 117 ++++++++++++++ ..._files_compression_inside_a_container.toml | 135 ++++++++++++++++ ...r_passwords_search_inside_a_container.toml | 118 ++++++++++++++ ...work_tool_launched_inside_a_container.toml | 147 ++++++++++++++++++ ...nt_binary_launched_inside_a_container.toml | 116 ++++++++++++++ ...ecutable_via_chmod_inside_a_container.toml | 127 +++++++++++++++ ...nteractive_process_inside_a_container.toml | 87 +++++++++++ ...h_process_launched_inside_a_container.toml | 138 ++++++++++++++++ ...n_debugfs_launched_inside_a_container.toml | 114 ++++++++++++++ ...ion_mount_launched_inside_a_container.toml | 114 ++++++++++++++ 10 files changed, 1213 insertions(+) create mode 100644 rules/linux/credential_access_aws_creds_search_inside_a_container.toml create mode 100644 rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml create mode 100644 rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml create mode 100644 rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml create mode 100644 rules/linux/execution_container_management_binary_launched_inside_a_container.toml create mode 100644 rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml create mode 100644 rules/linux/execution_unusual_interactive_process_inside_a_container.toml create mode 100644 rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml create mode 100644 rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml create mode 100644 rules/linux/privilege_escalation_mount_launched_inside_a_container.toml diff --git a/rules/linux/credential_access_aws_creds_search_inside_a_container.toml b/rules/linux/credential_access_aws_creds_search_inside_a_container.toml new file mode 100644 index 00000000000..41009c6a921 --- /dev/null +++ b/rules/linux/credential_access_aws_creds_search_inside_a_container.toml @@ -0,0 +1,117 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects the use of system search utilities like grep and find to search for AWS credentials inside a +container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or +facilitate a container breakout to the underlying cloud environment. +""" +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "AWS Credentials Searched For Inside A Container" +references = ["https://sysdig.com/blog/threat-detection-aws-cloud-containers/"] +risk_score = 47 +rule_id = "5749282b-7524-4c9d-af9a-e2b3e814e5d4" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "medium" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate") and +process.command_line like~ ( + "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", + "*access_key*", "*.aws/credentials*" +) +''' +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 Credentials Searched For Inside A Container + +Containers often house applications that interact with AWS services, necessitating the storage of AWS credentials. Adversaries may exploit this by using search utilities to locate these credentials, potentially leading to unauthorized access. The detection rule identifies suspicious use of search tools within containers, flagging attempts to locate AWS credentials by monitoring specific process names and arguments, thus helping to prevent credential theft and subsequent attacks. + +### Possible investigation steps + +- Review the process details to identify the specific search utility used (e.g., grep, find) and the arguments passed, focusing on those related to AWS credentials such as aws_access_key_id or aws_secret_access_key. +- Check the user context under which the suspicious process was executed to assess whether it aligns with expected behavior for that user or role within the container. +- Investigate the source of the container image to ensure it is from a trusted repository and has not been tampered with, which could indicate a supply chain compromise. +- Analyze recent activity logs for the container to identify any other suspicious behavior or anomalies that might correlate with the search for AWS credentials, such as unexpected network connections or file modifications. +- Review access logs for AWS services to detect any unauthorized or unusual access patterns that might suggest the use of compromised credentials. + +### False positive analysis + +- Routine maintenance scripts or automated processes may use search utilities to verify the presence of AWS credentials for legitimate configuration checks. To handle this, identify and whitelist these specific scripts or processes by their unique identifiers or execution paths. +- Developers or system administrators might manually search for AWS credentials during debugging or configuration tasks. Implement a policy to log and review these activities, and consider excluding known user accounts or roles from triggering alerts during specific time windows or in designated environments. +- Security audits or compliance checks often involve searching for sensitive information, including AWS credentials, to ensure proper security measures are in place. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods, or exclude specific audit tools from detection. +- Continuous integration and deployment (CI/CD) pipelines might include steps that search for AWS credentials to validate environment configurations. Identify these pipelines and exclude their associated processes or container environments from triggering alerts, ensuring that only authorized CI/CD tools are used. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network. +- Revoke any AWS credentials that were potentially exposed or accessed. This includes rotating keys and updating any services or applications that rely on these credentials. +- Conduct a thorough review of the container's file system to identify any unauthorized changes or additional malicious files that may have been introduced. +- Implement stricter access controls and monitoring on AWS credentials within containers, ensuring they are stored securely and accessed only by authorized processes. +- Escalate the incident to the cloud security team to assess the potential impact on the broader cloud environment and determine if further investigation or response is needed. +- Enhance logging and monitoring for similar activities across other containers and cloud environments to detect and respond to future attempts promptly. +- Review and update container security policies to include best practices for credential management and access control, reducing the risk of similar incidents.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1552" +name = "Unsecured Credentials" +reference = "https://attack.mitre.org/techniques/T1552/" + +[[rule.threat.technique.subtechnique]] +id = "T1552.001" +name = "Credentials In Files" +reference = "https://attack.mitre.org/techniques/T1552/001/" + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" diff --git a/rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml new file mode 100644 index 00000000000..437c40f64e4 --- /dev/null +++ b/rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml @@ -0,0 +1,135 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials +and system configurations inside a container. +""" +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "Sensitive Files Compression Inside A Container" +risk_score = 47 +rule_id = "d9faf1ba-a216-4c29-b8e0-a05a9d14b027" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "medium" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Collection", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process.name in ("zip", "tar", "gzip", "hdiutil", "7z") and +process.command_line like~ ( + "*/root/.ssh/*", "*/home/*/.ssh/*", "*/root/.bash_history*", "*/etc/hosts*", "*/root/.aws/*", "*/home/*/.aws/*", + "*/root/.docker/*", "*/home/*/.docker/*", "*/etc/group*", "*/etc/passwd*", "*/etc/shadow*", "*/etc/gshadow*" +) +''' +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 Sensitive Files Compression Inside A Container + +Containers are lightweight, portable environments used to run applications consistently across different systems. Adversaries may exploit compression utilities within containers to gather and exfiltrate sensitive files, such as credentials and configuration files. The detection rule identifies suspicious compression activities by monitoring for specific utilities and file paths, flagging potential unauthorized data collection attempts. + +### Possible investigation steps + +- Review the process details to confirm the use of compression utilities such as zip, tar, gzip, hdiutil, or 7z within the container environment, focusing on the process.name and process.args fields. +- Examine the specific file paths listed in the process.args to determine if they include sensitive files like SSH keys, AWS credentials, or Docker configurations, which could indicate unauthorized data collection. +- Check the event.type field for "start" to verify the timing of the process initiation and correlate it with any known legitimate activities or scheduled tasks within the container. +- Investigate the user or service account under which the process was executed to assess whether it has the necessary permissions and if the activity aligns with expected behavior for that account. +- Look for any related alerts or logs that might indicate a broader pattern of suspicious activity within the same container or across other containers in the environment. + +### False positive analysis + +- Routine backup operations may trigger the rule if they involve compressing sensitive files for storage. To handle this, identify and exclude backup processes or scripts that are known and trusted. +- Automated configuration management tools might compress configuration files as part of their normal operation. Exclude these tools by specifying their process names or paths in the exception list. +- Developers or system administrators might compress sensitive files during legitimate troubleshooting or maintenance activities. Establish a process to log and review these activities, and exclude them if they are verified as non-threatening. +- Continuous integration and deployment pipelines could involve compressing configuration files for deployment purposes. Identify these pipelines and exclude their associated processes to prevent false positives. +- Security tools that perform regular audits or scans might compress files for analysis. Ensure these tools are recognized and excluded from triggering the rule. + +### Response and remediation + +- Immediately isolate the affected container to prevent further data exfiltration or unauthorized access. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the compressed files and their contents to assess the extent of sensitive data exposure. Focus on the specific file paths identified in the alert. +- Change credentials and keys that may have been compromised, including SSH keys, AWS credentials, and Docker configurations. Ensure that new credentials are distributed securely. +- Review and update access controls and permissions for sensitive files within containers to minimize exposure. Ensure that only necessary processes and users have access to these files. +- Implement monitoring and alerting for similar compression activities in other containers to detect potential threats early. Use the identified process names and arguments as indicators. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Conduct a post-incident review to identify gaps in security controls and update container security policies to prevent recurrence.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1552" +name = "Unsecured Credentials" +reference = "https://attack.mitre.org/techniques/T1552/" + +[[rule.threat.technique.subtechnique]] +id = "T1552.001" +name = "Credentials In Files" +reference = "https://attack.mitre.org/techniques/T1552/001/" + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1560" +name = "Archive Collected Data" +reference = "https://attack.mitre.org/techniques/T1560/" + +[[rule.threat.technique.subtechnique]] +id = "T1560.001" +name = "Archive via Utility" +reference = "https://attack.mitre.org/techniques/T1560/001/" + +[rule.threat.tactic] +id = "TA0009" +name = "Collection" +reference = "https://attack.mitre.org/tactics/TA0009/" diff --git a/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml new file mode 100644 index 00000000000..6dbaf1d251c --- /dev/null +++ b/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml @@ -0,0 +1,118 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects the use of system search utilities like grep and find to search for private SSH keys or passwords +inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container +environment or facilitate a container breakout to the underlying host machine. +""" +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "Sensitive Keys Or Passwords Searched For Inside A Container" +references = ["https://sysdig.com/blog/cve-2021-25741-kubelet-falco/"] +risk_score = 47 +rule_id = "23cd4ba2-344e-41bf-bcda-655bea43fdbc" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "medium" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate") and +process.command_line like~ ( + "*BEGIN PRIVATE*", "*BEGIN OPENSSH PRIVATE*", "*BEGIN RSA PRIVATE*", "*BEGIN DSA PRIVATE*", "*BEGIN EC PRIVATE*", + "*pass*", "*ssh*", "*user*", "*id_rsa*", "*id_dsa*" +) +''' +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 Sensitive Keys Or Passwords Searched For Inside A Container + +Containers encapsulate applications, providing isolated environments. Adversaries may exploit search utilities like grep or find to locate sensitive credentials within containers, potentially leading to unauthorized access or container escape. The detection rule identifies suspicious searches for private keys or passwords, flagging potential credential access attempts by monitoring process activities and arguments. + +### Possible investigation steps + +- Examine the process.name and process.args fields to determine the exact command executed and assess whether it aligns with typical usage patterns or indicates malicious intent. +- Check the user context under which the process was executed to understand if the activity was performed by a legitimate user or an unauthorized entity. +- Investigate the container's recent activity logs to identify any other suspicious behavior or anomalies that might correlate with the search for sensitive keys or passwords. +- Assess the potential impact by determining if any sensitive files, such as private keys or password files, were accessed or exfiltrated following the search activity. +- If possible, correlate the event with network logs to identify any outbound connections that might suggest data exfiltration attempts. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators use grep or find to audit or manage SSH keys and passwords within containers. To mitigate this, create exceptions for known administrative scripts or processes that regularly perform these tasks. +- Automated backup or configuration management tools might search for sensitive files as part of their normal operation. Identify these tools and exclude their process IDs or specific command patterns from triggering the rule. +- Security scanning tools that check for the presence of sensitive files could be flagged. Whitelist these tools by their process names or arguments to prevent false positives. +- Developers or DevOps personnel might use search utilities during debugging or development processes. Establish a list of trusted users or roles and exclude their activities from the rule to reduce noise. +- Continuous integration/continuous deployment (CI/CD) pipelines may include steps that search for keys or passwords for validation purposes. Exclude these pipeline processes by identifying their unique process arguments or container IDs. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or potential container escape to the host system. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's logs and process activities to identify any unauthorized access or data exfiltration attempts. Pay special attention to the processes and arguments flagged by the detection rule. +- Rotate any potentially compromised credentials, including SSH keys and passwords, that were stored or accessed within the container. Ensure that new credentials are securely stored and managed. +- Assess the container's configuration and access controls to identify and rectify any security misconfigurations that may have allowed the unauthorized search for sensitive information. +- Implement additional monitoring and alerting for similar suspicious activities across other containers and the host environment to detect and respond to potential threats promptly. +- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread beyond the initial container. +- Review and update container security policies and practices to prevent recurrence, including enforcing least privilege access and using secrets management solutions to handle sensitive information securely.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1552" +name = "Unsecured Credentials" +reference = "https://attack.mitre.org/techniques/T1552/" + +[[rule.threat.technique.subtechnique]] +id = "T1552.001" +name = "Credentials In Files" +reference = "https://attack.mitre.org/techniques/T1552/001/" + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" diff --git a/rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml new file mode 100644 index 00000000000..fc5221b5848 --- /dev/null +++ b/rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml @@ -0,0 +1,147 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects commonly abused network utilities running inside a container. Network utilities like nc, nmap, dig, +tcpdump, ngrep, telnet, mitmproxy, zmap can be used for malicious purposes such as network reconnaissance, monitoring, +or exploitation, and should be monitored closely within a container. +""" +false_positives = [ + """ + There is a potential for false positives if the container is used for legitimate tasks that require the use of + network utilities, such as network troubleshooting, testing or system monitoring. It is important to investigate any + alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate + container activity. + """, +] +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "Suspicious Network Tool Launched Inside A Container" +references = ["https://sysdig.com/blog/cve-2021-25741-kubelet-falco/"] +risk_score = 21 +rule_id = "7290be75-2e10-49ec-b387-d4ed55b920ff" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "low" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Tactic: Command and Control", + "Tactic: Reconnaissance", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process.name in ( + "nc.traditional", "nc", "ncat", "netcat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", + "mitmproxy", "socat", "zmap", "masscan", "zgrab" +) +''' +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 Suspicious Network Tool Launched Inside A Container + +Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries exploit network tools within containers for reconnaissance or lateral movement, leveraging utilities like `nc` or `nmap` to map networks or intercept traffic. The detection rule identifies these tools' execution by monitoring process starts and arguments, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Examine the process arguments to understand the specific command or options used, which may provide insight into the intent of the tool's execution. +- Check the container's creation and modification timestamps to determine if the container was recently deployed or altered, which could indicate suspicious activity. +- Investigate the user or service account associated with the process start event to assess if it aligns with expected behavior or if it might be compromised. +- Analyze network logs and traffic patterns from the container to identify any unusual outbound connections or data exfiltration attempts. +- Correlate the alert with other security events or logs from the same container or host to identify potential lateral movement or further malicious activity. + +### False positive analysis + +- Development and testing environments often use network tools for legitimate purposes such as debugging or network configuration. To manage this, create exceptions for containers identified as part of these environments by tagging them appropriately and excluding them from the rule. +- Automated scripts or orchestration tools may trigger network utilities for routine checks or maintenance tasks. Identify these scripts and whitelist their associated container IDs or process names to prevent false alerts. +- Some monitoring solutions deploy containers with built-in network tools for performance analysis. Verify the legitimacy of these containers and exclude them from the rule by using specific labels or container IDs. +- Containers used for educational or training purposes might intentionally run network tools. Ensure these containers are marked and excluded from detection by setting up rules based on their unique identifiers or labels. + +### Response and remediation + +- Immediately isolate the affected container to prevent further network reconnaissance or lateral movement. This can be done by restricting its network access or stopping the container entirely. +- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data exfiltration attempts. Focus on the execution of the flagged network utilities. +- Remove any unauthorized or suspicious network tools from the container to prevent further misuse. Ensure that only necessary and approved utilities are present. +- Patch and update the container image to address any vulnerabilities that may have been exploited. Rebuild and redeploy the container using the updated image. +- Implement network segmentation to limit the container's access to sensitive resources and reduce the potential impact of similar threats in the future. +- Enhance monitoring and alerting for the execution of network utilities within containers, ensuring that any future occurrences are detected promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been compromised.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1046" +name = "Network Service Discovery" +reference = "https://attack.mitre.org/techniques/T1046/" + +[rule.threat.tactic] +id = "TA0007" +name = "Discovery" +reference = "https://attack.mitre.org/tactics/TA0007/" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1105" +name = "Ingress Tool Transfer" +reference = "https://attack.mitre.org/techniques/T1105/" + +[rule.threat.tactic] +id = "TA0011" +name = "Command and Control" +reference = "https://attack.mitre.org/tactics/TA0011/" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1595" +name = "Active Scanning" +reference = "https://attack.mitre.org/techniques/T1595/" + +[rule.threat.tactic] +id = "TA0043" +name = "Reconnaissance" +reference = "https://attack.mitre.org/tactics/TA0043/" diff --git a/rules/linux/execution_container_management_binary_launched_inside_a_container.toml b/rules/linux/execution_container_management_binary_launched_inside_a_container.toml new file mode 100644 index 00000000000..8a0b04bc303 --- /dev/null +++ b/rules/linux/execution_container_management_binary_launched_inside_a_container.toml @@ -0,0 +1,116 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects when a container management binary is run from inside a container. These binaries are critical +components of many containerized environments, and their presence and execution in unauthorized containers could +indicate compromise or a misconfiguration. +""" +false_positives = [ + """ + There is a potential for false positives if the container is used for legitimate administrative tasks that require + the use of container management utilities, such as deploying, scaling, or updating containerized applications. It is + important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity + or part of legitimate container activity. + """, +] +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "Container Management Utility Run Inside A Container" +risk_score = 21 +rule_id = "4b74d3b0-416e-4099-b432-677e1cd098cc" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "low" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process.name in ("dockerd", "docker", "kubelet", "kube-proxy", "kubectl", "containerd", "runc", "systemd", "crictl") +''' +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 Container Management Utility Run Inside A Container + +Container management utilities like Docker and Kubernetes are essential for orchestrating and managing containerized applications. They facilitate tasks such as deployment, scaling, and networking. However, adversaries can exploit these tools to execute unauthorized commands within containers, potentially leading to system compromise. The detection rule identifies suspicious execution of these utilities within containers, signaling possible misuse or misconfiguration, by monitoring specific process activities and event types. + +### Possible investigation steps + +- Examine the process name and command line arguments to understand the context of the execution and identify any anomalies or unauthorized commands. +- Check the user and permissions associated with the process to assess if it aligns with expected roles and access levels for container management tasks. +- Investigate the container's creation and deployment history to identify any recent changes or deployments that could explain the presence of the management utility. +- Analyze network activity associated with the container to detect any unusual connections or data transfers that might indicate malicious activity. +- Correlate the event with other security alerts or logs to identify patterns or related incidents that could provide additional context or evidence of compromise. + +### False positive analysis + +- Routine maintenance tasks within containers can trigger the rule. Exclude known maintenance scripts or processes by adding them to an allowlist if they frequently execute container management utilities. +- Development and testing environments often run container management commands for legitimate purposes. Consider excluding these environments from monitoring or adjust the rule to focus on production environments only. +- Automated deployment tools may execute container management commands as part of their workflow. Identify these tools and create exceptions for their activities to prevent false positives. +- System updates or patches might involve running container management utilities. Monitor update schedules and temporarily adjust the rule to avoid unnecessary alerts during these periods. +- Legitimate administrative actions by authorized personnel can trigger the rule. Implement user-based exceptions for known administrators to reduce false positives while maintaining security oversight. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or execution of commands. This can be done by stopping the container or disconnecting it from the network. +- Review the container's configuration and access controls to identify any misconfigurations or unauthorized access permissions that may have allowed the execution of container management utilities. +- Conduct a thorough analysis of the container's logs and process activities to determine the extent of the compromise and identify any additional malicious activities or lateral movement attempts. +- Remove any unauthorized or suspicious binaries and scripts from the container to prevent further exploitation. +- Patch and update the container image and underlying host system to address any known vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring on container management utilities to ensure they are only accessible by authorized users and processes. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader security measures across the container environment.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1609" +name = "Container Administration Command" +reference = "https://attack.mitre.org/techniques/T1609/" + +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" diff --git a/rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml new file mode 100644 index 00000000000..568bf5389e8 --- /dev/null +++ b/rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml @@ -0,0 +1,127 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects when chmod or chown are used to add the execute permission to a file inside a container. Modifying file +permissions to make a file executable could indicate malicious activity, as an attacker may attempt to run unauthorized +or malicious code inside the container. +""" +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "File Made Executable via Chmod Inside A Container" +risk_score = 21 +rule_id = "30d94e59-e5c7-4828-bc4f-f5809ad1ffe1" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "low" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process.name in ("chmod", "chown") and process.args in ("4755", "755", "000", "777", "444", "-x", "+x") +''' +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 Made Executable via Chmod Inside A Container + +Containers provide isolated environments for running applications, often on Linux systems. The `chmod` command is used to change file permissions, including making files executable. Adversaries may exploit this by altering permissions to execute unauthorized scripts or binaries, potentially leading to malicious activity. The detection rule identifies such actions by monitoring for `chmod` usage that grants execute permissions, focusing on specific permission patterns, and excluding benign cases. This helps in identifying potential threats where attackers attempt to execute unauthorized code within containers. + +### Possible investigation steps + +- Examine the process arguments to determine the exact permissions that were set and identify the file that was made executable. +- Investigate the origin of the `chmod` command by reviewing the process tree to understand which parent process initiated it and whether it aligns with expected behavior. +- Check the user account or service account that executed the `chmod` command to assess if it has legitimate access and reason to modify file permissions. +- Analyze the file that was made executable to determine its contents and origin, checking for any signs of unauthorized or malicious code. +- Correlate this event with other logs or alerts from the same container to identify any patterns or additional suspicious activities that might indicate a broader attack. + +### False positive analysis + +- Routine maintenance scripts or automated processes may use chmod to set execute permissions on files within containers. To handle these, identify and whitelist specific scripts or processes that are known to be safe and necessary for operations. +- Development environments often involve frequent changes to file permissions as developers test and deploy code. Consider excluding specific container IDs or paths associated with development environments to reduce noise. +- Some container orchestration tools might use chmod as part of their normal operation. Review the processes and arguments associated with these tools and create exceptions for known benign activities. +- System updates or package installations within containers might trigger this rule. Monitor and document regular update schedules and processes, and exclude these from triggering alerts if they are verified as non-threatening. +- If certain users or roles are responsible for legitimate permission changes, consider excluding their activities by user ID or role, ensuring that these exclusions are well-documented and reviewed regularly. + +### Response and remediation + +- Immediately isolate the affected container to prevent further execution of unauthorized code. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's file system to identify any unauthorized or suspicious files that have been made executable. Remove or quarantine these files as necessary. +- Analyze the container's logs to trace the source of the `chmod` command and determine if there are any other indicators of compromise or related malicious activities. +- If the unauthorized execution is confirmed, assess the potential impact on the host system and other containers. Implement additional security measures, such as enhanced monitoring or network segmentation, to protect other assets. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update container security policies to prevent unauthorized permission changes, such as implementing stricter access controls and using security tools that enforce policy compliance. +- Enhance detection capabilities by configuring alerts for similar suspicious activities, ensuring that any future attempts to modify file permissions within containers are promptly identified and addressed.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" + +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1222" +name = "File and Directory Permissions Modification" +reference = "https://attack.mitre.org/techniques/T1222/" + +[[rule.threat.technique.subtechnique]] +id = "T1222.002" +name = "Linux and Mac File and Directory Permissions Modification" +reference = "https://attack.mitre.org/techniques/T1222/002/" + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" diff --git a/rules/linux/execution_unusual_interactive_process_inside_a_container.toml b/rules/linux/execution_unusual_interactive_process_inside_a_container.toml new file mode 100644 index 00000000000..8e8e0436acf --- /dev/null +++ b/rules/linux/execution_unusual_interactive_process_inside_a_container.toml @@ -0,0 +1,87 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects when an unusual interactive process is launched inside a container. Interactive processes are typically +run in the foreground and require user input, which is unusual behavior for a containerized environment. This activity +could indicate an attacker attempting to gain access to the container environment or perform malicious actions. +""" +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "kuery" +license = "Elastic License v2" +name = "Unusual Interactive Process Launched in a Container" +risk_score = 47 +rule_id = "7020ff25-76d7-4a7d-b95b-266cf27d70e8" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "medium" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "new_terms" +query = ''' +event.category:process and event.type:start and event.action:exec and process.entry_leader.entry_meta.type:container and +process.interactive:true +''' + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" + +[[rule.threat.technique.subtechnique]] +id = "T1059.004" +name = "Unix Shell" +reference = "https://attack.mitre.org/techniques/T1059/004/" + +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" + +[rule.new_terms] +field = "new_terms_fields" +value = ["process.name"] + +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-14d" diff --git a/rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml new file mode 100644 index 00000000000..54512b5a745 --- /dev/null +++ b/rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml @@ -0,0 +1,138 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects an SSH or SSHD process executed from inside a container. This includes both the client ssh binary and +server ssh daemon process. SSH usage inside a container should be avoided and monitored closely when necessary. With +valid credentials an attacker may move laterally to other containers or to the underlying host through container +breakout. They may also use valid SSH credentials as a persistence mechanism. +""" +false_positives = [ + """ + SSH usage may be legitimate depending on the environment. Access patterns and follow-on activity should be analyzed + to distinguish between authorized and potentially malicious behavior. + """, +] +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "SSH Process Launched From Inside A Container" +references = [ + "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/SSH%20server%20running%20inside%20container/", + "https://www.blackhillsinfosec.com/sshazam-hide-your-c2-inside-of-ssh/", +] +risk_score = 47 +rule_id = "5c50ffa6-07f4-4cce-a1b7-c16928a2ed52" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "medium" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Lateral Movement", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process.name in ("sshd", "ssh", "autossh") +''' +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 SSH Process Launched From Inside A Container + +SSH (Secure Shell) is a protocol used for secure remote access and management of systems. Within container environments, SSH usage is atypical and can signal potential security risks. Adversaries may exploit SSH to move laterally between containers or escape to the host system. The detection rule identifies SSH processes initiated within containers, flagging potential unauthorized access or persistence attempts by monitoring process events and container identifiers. + +### Possible investigation steps + +- Examine the process start event details, including the process name (sshd, ssh, autossh) and event actions (fork, exec), to understand the context and nature of the SSH activity. +- Check for any recent changes or deployments related to the container to identify if the SSH process aligns with expected behavior or recent updates. +- Investigate the source and destination of the SSH connection to determine if it involves unauthorized or suspicious endpoints, potentially indicating lateral movement or an attempt to access the host system. +- Analyze user accounts and credentials used in the SSH session to verify if they are legitimate and authorized for container access, looking for signs of compromised credentials. +- Correlate the SSH activity with other security events or alerts to identify patterns or additional indicators of compromise within the container environment. + +### False positive analysis + +- Development and testing environments may intentionally use SSH for debugging or administrative tasks. Users can create exceptions for specific container IDs or hostnames associated with these environments to reduce noise. +- Automated scripts or orchestration tools might use SSH to manage containers. Identify these tools and exclude their process IDs or user accounts from triggering the rule. +- Some legacy applications might rely on SSH for internal communication. Review these applications and whitelist their specific process names or container images to prevent false alerts. +- Containers running SSH for legitimate remote access purposes, such as maintenance, should be documented. Exclude these containers by their unique identifiers or labels to avoid unnecessary alerts. +- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity. + +### Response and remediation + +- Immediately isolate the affected container to prevent potential lateral movement or further unauthorized access. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's logs and environment to identify any unauthorized access or changes. Pay special attention to SSH-related logs and any anomalies in user activity. +- Revoke any SSH keys or credentials that may have been compromised. Ensure that all SSH keys used within the container environment are rotated and that access is restricted to only necessary personnel. +- Assess the container image and configuration for vulnerabilities or misconfigurations that may have allowed the SSH process to be initiated. Patch any identified vulnerabilities and update the container image accordingly. +- Implement network segmentation to limit the ability of containers to communicate with each other and the host system, reducing the risk of lateral movement. +- Enhance monitoring and alerting for SSH activity within container environments to ensure rapid detection of similar threats in the future. This includes setting up alerts for any SSH process initiation within containers. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been affected.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1021" +name = "Remote Services" +reference = "https://attack.mitre.org/techniques/T1021/" + +[[rule.threat.technique.subtechnique]] +id = "T1021.004" +name = "SSH" +reference = "https://attack.mitre.org/techniques/T1021/004/" + +[rule.threat.tactic] +id = "TA0008" +name = "Lateral Movement" +reference = "https://attack.mitre.org/tactics/TA0008/" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1133" +name = "External Remote Services" +reference = "https://attack.mitre.org/techniques/T1133/" + +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" diff --git a/rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml b/rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml new file mode 100644 index 00000000000..51f0487ad77 --- /dev/null +++ b/rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml @@ -0,0 +1,114 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects the use of the built-in Linux DebugFS utility from inside a privileged container. DebugFS is a special +file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside +a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access +sensitive host level files which could be used for further privilege escalation and container escapes to the host +machine. +""" +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "File System Debugger Launched Inside a Container" +references = [ + "https://cyberark.wistia.com/medias/ygbzkzx93q?wvideo=ygbzkzx93q", + "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged", +] +risk_score = 47 +rule_id = "35c029c3-090e-4a25-b613-0b8099970fc1" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "medium" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process.name == "debugfs" and process.command_line like~ "/dev/sd*" and not process.args == "-R" +''' +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 System Debugger Launched Inside a Container + +DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in privileged containers, flagging potential misuse. + +### Possible investigation steps + +- Review the alert details to confirm the process name is "debugfs" and check the specific arguments used, particularly looking for "/dev/sd*" to identify potential access to host file systems. +- Verify the container's security context to ensure it is indeed privileged, as this increases the risk of host-level access. +- Investigate the origin of the container image and deployment configuration to determine if the use of a privileged container was intentional or necessary. +- Check the user or service account that initiated the process to assess if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine recent logs and events from the container and host to identify any unusual activities or patterns that coincide with the alert. +- Assess the potential impact by identifying any sensitive files or directories that may have been accessed or modified by the debugfs process. + +### False positive analysis + +- Routine maintenance tasks using DebugFS in privileged containers can trigger alerts. To manage this, identify and document regular maintenance processes and create exceptions for these specific processes. +- Automated scripts or tools that utilize DebugFS for legitimate monitoring or debugging purposes may cause false positives. Review these scripts and whitelist them by excluding their specific process arguments or execution contexts. +- Development and testing environments often run privileged containers with DebugFS for debugging purposes. Establish a separate set of rules or exceptions for these environments to prevent unnecessary alerts. +- Backup or recovery operations that involve direct disk access might use DebugFS. Ensure these operations are well-documented and create exceptions based on their unique process signatures or execution schedules. + +### Response and remediation + +- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or removing its network access. +- Conduct a thorough review of the container's security context and capabilities to ensure it does not have unnecessary privileges. Adjust the container's configuration to remove privileged access if not required. +- Analyze the container's logs and process history to identify any unauthorized access or actions taken by the DebugFS utility. This will help determine the extent of the potential breach. +- If unauthorized access to host files is confirmed, perform a security assessment of the host system to identify any changes or breaches. This may include checking for new user accounts, modified files, or unexpected network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. Provide them with all relevant logs and findings. +- Implement additional monitoring and alerting for similar activities across other containers and hosts to detect any recurrence of this threat. +- Review and update container deployment policies to enforce the principle of least privilege, ensuring containers only have the necessary permissions to perform their intended functions.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1611" +name = "Escape to Host" +reference = "https://attack.mitre.org/techniques/T1611/" + +[rule.threat.tactic] +id = "TA0004" +name = "Privilege Escalation" +reference = "https://attack.mitre.org/tactics/TA0004/" diff --git a/rules/linux/privilege_escalation_mount_launched_inside_a_container.toml b/rules/linux/privilege_escalation_mount_launched_inside_a_container.toml new file mode 100644 index 00000000000..e70fa3fc0fe --- /dev/null +++ b/rules/linux/privilege_escalation_mount_launched_inside_a_container.toml @@ -0,0 +1,114 @@ +[metadata] +creation_date = "2025/03/12" +integration = ["endpoint"] +maturity = "production" +updated_date = "2025/03/12" + +[rule] +author = ["Elastic"] +description = """ +This rule detects the use of the mount utility from inside a privileged container. The mount command is used to make a +device or file system accessible to the system, and then to connect its root directory to a specified mount point on the +local file system. When launched inside a privileged container--a container deployed with all the capabilities of the +host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation +and container escapes to the host machine. Any usage of mount inside a running privileged container should be further +investigated. +""" +from = "now-9m" +index = ["logs-endpoint.events.process*"] +language = "eql" +license = "Elastic License v2" +name = "Mount Launched Inside a Container" +references = [ + "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged", +] +risk_score = 47 +rule_id = "c73cc6ab-b30e-46bf-b5f2-29d9ab4caf7b" +setup = """## Setup + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "medium" +tags = [ + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +(process.name == "mount" or process.args == "mount") +''' +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 Mount Launched Inside a Container + +In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in privileged containers, flagging potential security threats for further investigation. + +### Possible investigation steps + +- Review the alert details to confirm that the process name or arguments include "mount" and that the container's security context is marked as privileged. +- Check the container's deployment configuration to verify if it was intentionally set as privileged and assess whether this level of privilege is necessary for its function. +- Investigate the user or process that initiated the mount command within the container to determine if it aligns with expected behavior or if it indicates potential malicious activity. +- Examine the mounted file systems and directories to identify any sensitive host files that may have been accessed or exposed. +- Review logs and historical data for any previous suspicious activities associated with the same container or user to identify patterns or repeated attempts at privilege escalation. + +### False positive analysis + +- Routine maintenance tasks within privileged containers may trigger the rule. Exclude known maintenance scripts or processes by adding them to an exception list based on their unique identifiers or command patterns. +- Backup operations that require mounting file systems might be flagged. Identify and exclude these operations by specifying the backup process names or arguments in the rule exceptions. +- Development or testing environments often use privileged containers for convenience. If these environments are known and controlled, consider excluding them by container IDs or labels to reduce noise. +- Automated deployment tools that use mount commands in privileged containers can be mistaken for threats. Review and whitelist these tools by their process names or specific arguments to prevent false alerts. +- Certain monitoring or logging solutions may use mount operations for data collection. Verify these solutions and exclude their processes if they are legitimate and necessary for system operations. + +### Response and remediation + +- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or disconnecting it from the network. +- Review and revoke any unnecessary privileges from the container's security context to prevent similar incidents. Ensure that containers run with the least privileges necessary. +- Conduct a thorough analysis of the container's file system and logs to identify any unauthorized access or modifications to host files. +- If unauthorized access is confirmed, perform a comprehensive audit of the host system to check for any signs of compromise or privilege escalation attempts. +- Patch and update the container image and host system to address any vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring for privileged containers, ensuring that only trusted users and processes can execute sensitive commands like `mount`. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.""" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1611" +name = "Escape to Host" +reference = "https://attack.mitre.org/techniques/T1611/" + +[rule.threat.tactic] +id = "TA0004" +name = "Privilege Escalation" +reference = "https://attack.mitre.org/tactics/TA0004/" From 187d9e6b2abb70c4b940726c79719502af05e6ca Mon Sep 17 00:00:00 2001 From: Aegrah Date: Wed, 12 Mar 2025 12:50:23 +0100 Subject: [PATCH 2/8] added host.os.type --- ...redential_access_aws_creds_search_inside_a_container.toml | 3 ++- ...ction_sensitive_files_compression_inside_a_container.toml | 4 ++-- ...ensitive_keys_or_passwords_search_inside_a_container.toml | 3 ++- ..._suspicious_network_tool_launched_inside_a_container.toml | 4 ++-- ...tainer_management_binary_launched_inside_a_container.toml | 3 ++- ...on_file_made_executable_via_chmod_inside_a_container.toml | 5 +++-- ...ution_unusual_interactive_process_inside_a_container.toml | 4 ++-- ...ral_movement_ssh_process_launched_inside_a_container.toml | 4 ++-- ...ilege_escalation_debugfs_launched_inside_a_container.toml | 5 +++-- ...ivilege_escalation_mount_launched_inside_a_container.toml | 4 ++-- 10 files changed, 22 insertions(+), 17 deletions(-) diff --git a/rules/linux/credential_access_aws_creds_search_inside_a_container.toml b/rules/linux/credential_access_aws_creds_search_inside_a_container.toml index 41009c6a921..a7cb2b14a59 100644 --- a/rules/linux/credential_access_aws_creds_search_inside_a_container.toml +++ b/rules/linux/credential_access_aws_creds_search_inside_a_container.toml @@ -57,7 +57,8 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate") and process.command_line like~ ( "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", diff --git a/rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml index 437c40f64e4..8903e78c926 100644 --- a/rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml +++ b/rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml @@ -56,8 +56,8 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and -process.name in ("zip", "tar", "gzip", "hdiutil", "7z") and +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ("zip", "tar", "gzip", "hdiutil", "7z") and process.command_line like~ ( "*/root/.ssh/*", "*/home/*/.ssh/*", "*/root/.bash_history*", "*/etc/hosts*", "*/root/.aws/*", "*/home/*/.aws/*", "*/root/.docker/*", "*/home/*/.docker/*", "*/etc/group*", "*/etc/passwd*", "*/etc/shadow*", "*/etc/gshadow*" diff --git a/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml index 6dbaf1d251c..21acccf17e7 100644 --- a/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml +++ b/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml @@ -57,7 +57,8 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate") and process.command_line like~ ( "*BEGIN PRIVATE*", "*BEGIN OPENSSH PRIVATE*", "*BEGIN RSA PRIVATE*", "*BEGIN DSA PRIVATE*", "*BEGIN EC PRIVATE*", diff --git a/rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml index fc5221b5848..aaaa526247c 100644 --- a/rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml +++ b/rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml @@ -67,8 +67,8 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and -process.name in ( +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ( "nc.traditional", "nc", "ncat", "netcat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab" ) diff --git a/rules/linux/execution_container_management_binary_launched_inside_a_container.toml b/rules/linux/execution_container_management_binary_launched_inside_a_container.toml index 8a0b04bc303..02aeac605ac 100644 --- a/rules/linux/execution_container_management_binary_launched_inside_a_container.toml +++ b/rules/linux/execution_container_management_binary_launched_inside_a_container.toml @@ -64,7 +64,8 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ("dockerd", "docker", "kubelet", "kube-proxy", "kubectl", "containerd", "runc", "systemd", "crictl") ''' note = """## Triage and analysis diff --git a/rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml index 568bf5389e8..04e8710762d 100644 --- a/rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml +++ b/rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml @@ -57,8 +57,9 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and -process.name in ("chmod", "chown") and process.args in ("4755", "755", "000", "777", "444", "-x", "+x") +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ("chmod", "chown") and +process.args in ("4755", "755", "000", "777", "444", "-x", "+x") ''' note = """## Triage and analysis diff --git a/rules/linux/execution_unusual_interactive_process_inside_a_container.toml b/rules/linux/execution_unusual_interactive_process_inside_a_container.toml index 8e8e0436acf..c70bddf41de 100644 --- a/rules/linux/execution_unusual_interactive_process_inside_a_container.toml +++ b/rules/linux/execution_unusual_interactive_process_inside_a_container.toml @@ -56,8 +56,8 @@ tags = [ timestamp_override = "event.ingested" type = "new_terms" query = ''' -event.category:process and event.type:start and event.action:exec and process.entry_leader.entry_meta.type:container and -process.interactive:true +event.category:process and host.os.type:linux and event.type:start and event.action:exec and +process.entry_leader.entry_meta.type:container and process.interactive:true ''' [[rule.threat]] diff --git a/rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml index 54512b5a745..90efac94a21 100644 --- a/rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml +++ b/rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml @@ -68,8 +68,8 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and -process.name in ("sshd", "ssh", "autossh") +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ("sshd", "ssh", "autossh") ''' note = """## Triage and analysis diff --git a/rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml b/rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml index 51f0487ad77..1531fd57948 100644 --- a/rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml +++ b/rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml @@ -62,8 +62,9 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and -process.name == "debugfs" and process.command_line like~ "/dev/sd*" and not process.args == "-R" +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name == "debugfs" and +process.command_line like~ "/dev/sd*" and not process.args == "-R" ''' note = """## Triage and analysis diff --git a/rules/linux/privilege_escalation_mount_launched_inside_a_container.toml b/rules/linux/privilege_escalation_mount_launched_inside_a_container.toml index e70fa3fc0fe..52573aa49a6 100644 --- a/rules/linux/privilege_escalation_mount_launched_inside_a_container.toml +++ b/rules/linux/privilege_escalation_mount_launched_inside_a_container.toml @@ -62,8 +62,8 @@ tags = [ timestamp_override = "event.ingested" type = "eql" query = ''' -process where event.type == "start" and event.action == "exec" and process.entry_leader.entry_meta.type == "container" and -(process.name == "mount" or process.args == "mount") +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name == "mount" ''' note = """## Triage and analysis From ec65ec1dfac4a48138e73e8c6ec663920f0cb8af Mon Sep 17 00:00:00 2001 From: Aegrah Date: Wed, 12 Mar 2025 13:08:18 +0100 Subject: [PATCH 3/8] Rename --- ...l => credential_access_aws_creds_search_inside_container.toml} | 0 ..._collection_sensitive_files_compression_inside_container.toml} | 0 ...cess_sensitive_keys_or_passwords_search_inside_container.toml} | 0 ...covery_suspicious_network_tool_launched_inside_container.toml} | 0 ...on_container_management_binary_launched_inside_container.toml} | 0 ...xecution_file_made_executable_via_chmod_inside_container.toml} | 0 ...> execution_unusual_interactive_process_inside_container.toml} | 0 ...> lateral_movement_ssh_process_launched_inside_container.toml} | 0 ...> privilege_escalation_debugfs_launched_inside_container.toml} | 0 ... => privilege_escalation_mount_launched_inside_container.toml} | 0 10 files changed, 0 insertions(+), 0 deletions(-) rename rules/linux/{credential_access_aws_creds_search_inside_a_container.toml => credential_access_aws_creds_search_inside_container.toml} (100%) rename rules/linux/{credential_access_collection_sensitive_files_compression_inside_a_container.toml => credential_access_collection_sensitive_files_compression_inside_container.toml} (100%) rename rules/linux/{credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml => credential_access_sensitive_keys_or_passwords_search_inside_container.toml} (100%) rename rules/linux/{discovery_suspicious_network_tool_launched_inside_a_container.toml => discovery_suspicious_network_tool_launched_inside_container.toml} (100%) rename rules/linux/{execution_container_management_binary_launched_inside_a_container.toml => execution_container_management_binary_launched_inside_container.toml} (100%) rename rules/linux/{execution_file_made_executable_via_chmod_inside_a_container.toml => execution_file_made_executable_via_chmod_inside_container.toml} (100%) rename rules/linux/{execution_unusual_interactive_process_inside_a_container.toml => execution_unusual_interactive_process_inside_container.toml} (100%) rename rules/linux/{lateral_movement_ssh_process_launched_inside_a_container.toml => lateral_movement_ssh_process_launched_inside_container.toml} (100%) rename rules/linux/{privilege_escalation_debugfs_launched_inside_a_container.toml => privilege_escalation_debugfs_launched_inside_container.toml} (100%) rename rules/linux/{privilege_escalation_mount_launched_inside_a_container.toml => privilege_escalation_mount_launched_inside_container.toml} (100%) diff --git a/rules/linux/credential_access_aws_creds_search_inside_a_container.toml b/rules/linux/credential_access_aws_creds_search_inside_container.toml similarity index 100% rename from rules/linux/credential_access_aws_creds_search_inside_a_container.toml rename to rules/linux/credential_access_aws_creds_search_inside_container.toml diff --git a/rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/linux/credential_access_collection_sensitive_files_compression_inside_container.toml similarity index 100% rename from rules/linux/credential_access_collection_sensitive_files_compression_inside_a_container.toml rename to rules/linux/credential_access_collection_sensitive_files_compression_inside_container.toml diff --git a/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_container.toml similarity index 100% rename from rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml rename to rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_container.toml diff --git a/rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/linux/discovery_suspicious_network_tool_launched_inside_container.toml similarity index 100% rename from rules/linux/discovery_suspicious_network_tool_launched_inside_a_container.toml rename to rules/linux/discovery_suspicious_network_tool_launched_inside_container.toml diff --git a/rules/linux/execution_container_management_binary_launched_inside_a_container.toml b/rules/linux/execution_container_management_binary_launched_inside_container.toml similarity index 100% rename from rules/linux/execution_container_management_binary_launched_inside_a_container.toml rename to rules/linux/execution_container_management_binary_launched_inside_container.toml diff --git a/rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/linux/execution_file_made_executable_via_chmod_inside_container.toml similarity index 100% rename from rules/linux/execution_file_made_executable_via_chmod_inside_a_container.toml rename to rules/linux/execution_file_made_executable_via_chmod_inside_container.toml diff --git a/rules/linux/execution_unusual_interactive_process_inside_a_container.toml b/rules/linux/execution_unusual_interactive_process_inside_container.toml similarity index 100% rename from rules/linux/execution_unusual_interactive_process_inside_a_container.toml rename to rules/linux/execution_unusual_interactive_process_inside_container.toml diff --git a/rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/linux/lateral_movement_ssh_process_launched_inside_container.toml similarity index 100% rename from rules/linux/lateral_movement_ssh_process_launched_inside_a_container.toml rename to rules/linux/lateral_movement_ssh_process_launched_inside_container.toml diff --git a/rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml b/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml similarity index 100% rename from rules/linux/privilege_escalation_debugfs_launched_inside_a_container.toml rename to rules/linux/privilege_escalation_debugfs_launched_inside_container.toml diff --git a/rules/linux/privilege_escalation_mount_launched_inside_a_container.toml b/rules/linux/privilege_escalation_mount_launched_inside_container.toml similarity index 100% rename from rules/linux/privilege_escalation_mount_launched_inside_a_container.toml rename to rules/linux/privilege_escalation_mount_launched_inside_container.toml From 8a2789f878890b6cf6b5fbc56a1029b7992a0af0 Mon Sep 17 00:00:00 2001 From: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com> Date: Thu, 13 Mar 2025 09:13:37 +0100 Subject: [PATCH 4/8] Update rules/linux/execution_container_management_binary_launched_inside_container.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com> --- ...n_container_management_binary_launched_inside_container.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/linux/execution_container_management_binary_launched_inside_container.toml b/rules/linux/execution_container_management_binary_launched_inside_container.toml index 02aeac605ac..0b005e34011 100644 --- a/rules/linux/execution_container_management_binary_launched_inside_container.toml +++ b/rules/linux/execution_container_management_binary_launched_inside_container.toml @@ -75,7 +75,7 @@ note = """## Triage and analysis ### Investigating Container Management Utility Run Inside A Container -Container management utilities like Docker and Kubernetes are essential for orchestrating and managing containerized applications. They facilitate tasks such as deployment, scaling, and networking. However, adversaries can exploit these tools to execute unauthorized commands within containers, potentially leading to system compromise. The detection rule identifies suspicious execution of these utilities within containers, signaling possible misuse or misconfiguration, by monitoring specific process activities and event types. +Container management utilities like Docker and Kubectl are essential for orchestrating and managing containerized applications. They facilitate tasks such as deployment, scaling, and networking. However, adversaries can exploit these tools to execute unauthorized commands within containers, potentially leading to system compromise. The detection rule identifies suspicious execution of these utilities within containers, signaling possible misuse or misconfiguration, by monitoring specific process activities and event types. ### Possible investigation steps From 293838c5a0a79c18a41840a280b96ef699a996cc Mon Sep 17 00:00:00 2001 From: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com> Date: Thu, 13 Mar 2025 09:13:47 +0100 Subject: [PATCH 5/8] Update rules/linux/privilege_escalation_debugfs_launched_inside_container.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com> --- .../privilege_escalation_debugfs_launched_inside_container.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml b/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml index 1531fd57948..657d75b8795 100644 --- a/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml +++ b/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml @@ -7,7 +7,7 @@ updated_date = "2025/03/12" [rule] author = ["Elastic"] description = """ -This rule detects the use of the built-in Linux DebugFS utility from inside a privileged container. DebugFS is a special +This rule detects the use of the built-in Linux DebugFS utility from inside a container. DebugFS is a special file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host From ca2ff377a86a1e3e79865119b94e5b9f588bfa9b Mon Sep 17 00:00:00 2001 From: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com> Date: Thu, 13 Mar 2025 09:13:53 +0100 Subject: [PATCH 6/8] Update rules/linux/privilege_escalation_debugfs_launched_inside_container.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com> --- .../privilege_escalation_debugfs_launched_inside_container.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml b/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml index 657d75b8795..94a0637e997 100644 --- a/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml +++ b/rules/linux/privilege_escalation_debugfs_launched_inside_container.toml @@ -73,7 +73,7 @@ note = """## Triage and analysis ### Investigating File System Debugger Launched Inside a Container -DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in privileged containers, flagging potential misuse. +DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in containers, flagging potential misuse. ### Possible investigation steps From 83a1ec8607098883c0eb7ed626a9bda0d7af6eae Mon Sep 17 00:00:00 2001 From: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com> Date: Thu, 13 Mar 2025 09:14:00 +0100 Subject: [PATCH 7/8] Update rules/linux/privilege_escalation_mount_launched_inside_container.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com> --- .../privilege_escalation_mount_launched_inside_container.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/linux/privilege_escalation_mount_launched_inside_container.toml b/rules/linux/privilege_escalation_mount_launched_inside_container.toml index 52573aa49a6..3eac789bbee 100644 --- a/rules/linux/privilege_escalation_mount_launched_inside_container.toml +++ b/rules/linux/privilege_escalation_mount_launched_inside_container.toml @@ -7,7 +7,7 @@ updated_date = "2025/03/12" [rule] author = ["Elastic"] description = """ -This rule detects the use of the mount utility from inside a privileged container. The mount command is used to make a +This rule detects the use of the mount utility from inside a container. The mount command is used to make a device or file system accessible to the system, and then to connect its root directory to a specified mount point on the local file system. When launched inside a privileged container--a container deployed with all the capabilities of the host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation From 5534757eeb3d7724cbcbfa206dd158a09e5446a0 Mon Sep 17 00:00:00 2001 From: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com> Date: Thu, 13 Mar 2025 09:14:12 +0100 Subject: [PATCH 8/8] Update rules/linux/privilege_escalation_mount_launched_inside_container.toml Co-authored-by: Isai <59296946+imays11@users.noreply.github.com> --- .../privilege_escalation_mount_launched_inside_container.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/linux/privilege_escalation_mount_launched_inside_container.toml b/rules/linux/privilege_escalation_mount_launched_inside_container.toml index 3eac789bbee..0c794a857d1 100644 --- a/rules/linux/privilege_escalation_mount_launched_inside_container.toml +++ b/rules/linux/privilege_escalation_mount_launched_inside_container.toml @@ -72,7 +72,7 @@ note = """## Triage and analysis ### Investigating Mount Launched Inside a Container -In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in privileged containers, flagging potential security threats for further investigation. +In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in containers, flagging potential security threats for further investigation. ### Possible investigation steps