Skip to content

[New/Tuning] Misc. New D4C Rules and Tunings#5692

Open
Aegrah wants to merge 9 commits intomainfrom
high-value-dr-to-container-rules
Open

[New/Tuning] Misc. New D4C Rules and Tunings#5692
Aegrah wants to merge 9 commits intomainfrom
high-value-dr-to-container-rules

Conversation

@Aegrah
Copy link
Contributor

@Aegrah Aegrah commented Feb 6, 2026

Cloud Defend for Containers - New Detection Rules

This PR introduces 10 new detection rules and 4 rule updates for the Elastic Defend for Containers integration. These rules focus on detecting interactive threats within container environments, covering various tactics across the MITRE ATT&CK framework including Discovery, Execution, Defense Evasion, Command and Control, Credential Access, and Persistence.

Summary of Changes

Type Count
New Rules 10
Updated Rules 4

New Detection Rules

1. Interactive File Download Detected via Defend for Containers

File: command_and_control_interactive_file_download_from_internet.toml

Severity: Medium | Risk Score: 47

Description:
Detects when files are downloaded inside a container using curl or wget command-line tools during an interactive session. Adversaries commonly use these tools to download malicious payloads, establish C2 communication channels, or exfiltrate sensitive data.

Why it's relevant:
Containers should typically have pre-built dependencies. Interactive file downloads indicate potential post-exploitation activity where an attacker is staging additional tools or malware.

MITRE ATT&CK:

  • Command and Control (TA0011) - Application Layer Protocol: Web Protocols (T1071.001)
  • Execution (TA0002) - Command and Scripting Interpreter: Unix Shell (T1059.004)

2. Shell Command-Line History Deletion Detected via Defend for Containers

File: defense_evasion_deletion_of_shell_cmdline_history.toml

Severity: High | Risk Score: 73

Description:
Detects deletion or manipulation of shell command-line history files (.bash_history, .sh_history, .zsh_history) inside containers. This includes direct file deletion, truncation, symlinking to /dev/null, or using shell built-ins like history -c and unset HISTFILE.

Why it's relevant:
Attackers frequently clear command history to cover their tracks after executing malicious commands. This is a classic anti-forensics technique that indicates an attacker is trying to hide their activity.

MITRE ATT&CK:

  • Defense Evasion (TA0005) - Indicator Removal: Clear Command History (T1070.003)

3. Interactive Process Execution from Suspicious Directory Detected via Defend for Containers

File: defense_evasion_interactive_process_execution_from_suspicious_directory.toml

Severity: High | Risk Score: 73

Description:
Detects execution of interactive processes from world-writable or temporary directories such as /tmp, /dev/shm, /var/tmp, /run, /var/run, /mnt, /media, and /boot.

Why it's relevant:
These directories are commonly used by attackers to stage and execute malicious binaries because they're typically writable and may not be monitored as closely as standard binary locations.

MITRE ATT&CK:

  • Defense Evasion (TA0005) - Reflective Code Loading (T1620)
  • Execution (TA0002) - Command and Scripting Interpreter: Unix Shell (T1059.004)
  • Command and Control (TA0011) - Application Layer Protocol (T1071)

4. Potential Defense Evasion via Encoded Payload Detected via Defend for Containers

File: defense_evasion_potential_evasion_via_encoded_payload.toml

Severity: Medium | Risk Score: 47

Description:
Detects interactive execution of base64/encoding tools and interpreters with decode flags inside containers. Covers base64, xxd, openssl enc, and scripting languages (Python, Perl, Ruby) executing decode operations.

Why it's relevant:
Attackers frequently encode payloads to bypass security controls and obfuscate malicious commands. Decoding operations in interactive sessions often indicate payload execution or data exfiltration.

MITRE ATT&CK:

  • Defense Evasion (TA0005) - Obfuscated Files or Information (T1027), Deobfuscate/Decode Files or Information (T1140)
  • Execution (TA0002) - Command and Scripting Interpreter: Unix Shell (T1059.004), User Execution: Malicious File (T1204.002)

5. Kubelet Pod Discovery via Built-In Utilities Detected via Defend for Containers

File: discovery_kubelet_pod_discovery_via_builtin_utilities.toml

Severity: Low | Risk Score: 21

Description:
Detects use of common utilities (du, nice, find, locate, ls) to enumerate pod information in /var/lib/kubelet/pods/. Uses a sequence query requiring 5 runs within 5 seconds to reduce false positives.

Why it's relevant:
The kubelet pods directory contains sensitive information about running pods. Enumeration of this directory can reveal pod names, volumes, and service account tokens that can be leveraged for lateral movement.

MITRE ATT&CK:

  • Discovery (TA0007) - Container and Resource Discovery (T1613)

6. Privilege Boundary Enumeration from Interactive Process Detected via Defend for Containers

File: discovery_privilege_boundary_enumeration_from_interactive_process.toml

Severity: Low | Risk Score: 21

Description:
Detects execution of privilege enumeration commands (id, whoami, capsh, getcap, lsns) inside containers. Includes exclusions for common legitimate multi-process commands.

Why it's relevant:
These commands are typically the first reconnaissance steps an attacker takes after gaining container access to understand their privilege level and potential escalation paths.

MITRE ATT&CK:

  • Discovery (TA0007) - Container and Resource Discovery (T1613), System Information Discovery (T1082)

7. File Creation via Interactive Process Followed by Execution Detected via Defend for Containers

File: execution_interactive_file_creation_followed_by_execution.toml

Severity: Medium | Risk Score: 47

Description:
Detects when an interactive process creates a file followed by its execution within 3 seconds. Excludes legitimate package managers (apt, yum, dnf, etc.).

Why it's relevant:
This pattern indicates potential malware delivery or container breakout attempts where an attacker downloads a payload and immediately executes it.

MITRE ATT&CK:

  • Execution (TA0002) - Command and Scripting Interpreter: Unix Shell (T1059.004)
  • Command and Control (TA0011) - Application Layer Protocol (T1071)

8. File Creation via Interactive Process in System Binary Locations Detected via Defend for Containers

File: execution_interactive_file_creation_in_system_binary_locations.toml

Severity: Medium | Risk Score: 47

Description:
Detects file creation in sensitive system directories (/etc, /root, /bin, /usr/bin, /usr/local/bin, /entrypoint) by download tools or processes running from suspicious locations.

Why it's relevant:
Writing files to system binary locations can enable persistence, privilege escalation, or modification of container behavior. This is especially concerning when done by download tools or processes from temporary directories.

MITRE ATT&CK:

  • Execution (TA0002) - Command and Scripting Interpreter: Unix Shell (T1059.004)
  • Command and Control (TA0011) - Application Layer Protocol (T1071)
  • Defense Evasion (TA0005)

9. Suspicious Interactive Interpreter Command Execution Detected via Defend for Containers

File: execution_suspicious_interactive_interpreter_command_execution.toml

Severity: Medium | Risk Score: 47

Description:
Detects suspicious one-liner execution across multiple interpreters (Perl, PHP, Lua, Python, Ruby) with dangerous function calls including exec, system, eval, network operations, and encoding/decoding functions.

Why it's relevant:
Attackers frequently use scripting language one-liners for reverse shells, data exfiltration, or payload execution. This rule provides comprehensive coverage across the most commonly abused interpreters.

MITRE ATT&CK:

  • Execution (TA0002) - Command and Scripting Interpreter: Unix Shell (T1059.004), Python (T1059.006), Lua (T1059.011)
  • Command and Control (TA0011) - Application Layer Protocol: Web Protocols (T1071.001)

10. Suspicious Web Server Child Process Execution Detected via Defend for Containers

File: persistence_suspicious_webserver_child_process_execution.toml

Severity: Medium | Risk Score: 47

Description:
Detects shell execution spawned by web server processes or running as web server users (apache, www-data, nginx, etc.). Covers a comprehensive list of web servers including Apache, Nginx, Gunicorn, uWSGI, and many others.

Why it's relevant:
Web shells are a primary method for maintaining persistent access after web application exploitation. This rule detects the execution phase where an uploaded web shell spawns a command shell.

MITRE ATT&CK:

  • Persistence (TA0003) - Server Software Component: Web Shell (T1505.003)
  • Execution (TA0002) - Command and Scripting Interpreter: Unix Shell (T1059.004)
  • Command and Control (TA0011) - Application Layer Protocol (T1071)

Updated Detection Rules

1. Credential Access - Service Account Token or Certificate Read

File: credential_access_service_account_token_or_cert_read.toml

Changes:

  • Added logs-cloud_defend.process* to index patterns
  • Extended detection to include /run/secrets/ path (in addition to /var/run/secrets/)
  • Added process-based detection using cat, head, tail, more, less commands reading service account files
  • Changed from file event type to any event type to support both file and process events

Why:
Provides broader coverage for credential access attempts, catching both file-based access and command-line tools used to read sensitive Kubernetes credentials.


2. Discovery - Kubelet Certificate File Access

File: discovery_kubelet_certificate_file_access.toml

Changes:

  • Added logs-cloud_defend.process* to index patterns
  • Added process-based detection using cat, head, tail, more, less commands
  • Changed from file event type to any event type

Why:
Enhanced detection coverage to catch both direct file access and command-line reading of kubelet PKI certificates.


3. Discovery - Service Account Namespace Read

File: discovery_service_account_namespace_read.toml

Changes:

  • Added logs-cloud_defend.process* to index patterns
  • Extended detection to include /run/secrets/ path
  • Added process-based detection using common file reading utilities
  • Changed from file event type to any event type

Why:
Improved detection of namespace discovery attempts which can reveal cluster topology information to attackers.


4. Execution - Tool Installation

File: execution_tool_installation.toml

Changes:

  • Added shell interpreters to the monitored package list: bash, sh, dash, zsh, fish, tcsh, csh, ksh

Why:
Installing shell interpreters via package managers is suspicious in production containers and could indicate an attacker preparing for interactive access.


Technical Notes

  • All rules target Elastic Stack 9.3.0+ where the Defend for Containers integration was re-introduced
  • Rules use EQL (Event Query Language) for detection logic
  • All rules require process.interactive == true to focus on interactive (potentially attacker-controlled) sessions
  • Detection is scoped to Linux containers via host.os.type == "linux" and container.id like "*"

@Aegrah Aegrah self-assigned this Feb 6, 2026
@Aegrah Aegrah added OS: Linux Rule: New Proposal for new rule Rule: Tuning tweaking or tuning an existing rule container Integration: Cloud Defend Cloud Defend Integration Team: TRADE labels Feb 6, 2026
@github-actions
Copy link
Contributor

github-actions bot commented Feb 6, 2026

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

  • Detailed description of the rule.
  • List any new fields required in ECS/data sources.
  • Link related issues or PRs.
  • Include references.

Rule Metadata Checks

  • creation_date matches the date of creation PR initially merged.
  • min_stack_version should support the widest stack versions.
  • name and description should be descriptive and not include typos.
  • query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
  • min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
  • index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
  • integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
  • setup should include the necessary steps to configure the integration.
  • note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
  • tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
  • threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

  • building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
  • bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

  • Provide evidence of testing and detecting the expected threat.
  • Check for existence of coverage to prevent duplication.

1 similar comment
@github-actions
Copy link
Contributor

github-actions bot commented Feb 6, 2026

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

  • Detailed description of the rule.
  • List any new fields required in ECS/data sources.
  • Link related issues or PRs.
  • Include references.

Rule Metadata Checks

  • creation_date matches the date of creation PR initially merged.
  • min_stack_version should support the widest stack versions.
  • name and description should be descriptive and not include typos.
  • query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
  • min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
  • index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
  • integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
  • setup should include the necessary steps to configure the integration.
  • note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
  • tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
  • threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

  • building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
  • bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

  • Provide evidence of testing and detecting the expected threat.
  • Check for existence of coverage to prevent duplication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport: auto container Integration: Cloud Defend Cloud Defend Integration OS: Linux Rule: New Proposal for new rule Rule: Tuning tweaking or tuning an existing rule Team: TRADE

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant