Linux & Cloud Detection Engineering - Getting Started with Defend for Containers (D4C)
Elastic has introduced Defend for Containers (D4C) in version 9.3.0, providing runtime visibility and detection capabilities for Linux container workloads in Kubernetes environments. The integration captures process and file activity enriched with orchestration metadata, enabling detection engineers to build robust, behavior-based security policies.
Key Takeaways
- Elastic released Defend for Containers (D4C) in version 9.3.0 to provide runtime security and visibility for Linux container workloads.
- D4C uses a policy-driven model with selectors and responses to monitor process executions and file modifications (write-intent only).
- Telemetry is enriched with deep container context, including Linux capabilities (e.g., CAP_SYS_ADMIN) and interactive execution flags.
- Current beta limitations include a lack of network event capture, lack of read-only file access monitoring, and missing file event telemetry on Azure AKS.
Affected Systems
- Linux
- Kubernetes
- Amazon EKS
- Google GKE
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: Yes
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
- Platforms: Elastic Security
Elastic provides a container-specific detection ruleset built into Elastic Security 9.3.0+ that can be queried using KQL or ES|QL.
Detection Engineering Assessment
EDR Visibility: High — Defend for Containers provides deep runtime visibility into container processes, file modifications, and Linux capabilities via eBPF/BPF. Network Visibility: None — The article explicitly states that the current Beta does not capture network events. Detection Difficulty: Moderate — While D4C provides rich telemetry, detection engineers must carefully tune policies using selectors and exclusions to avoid false positives in dynamic container environments.
Required Log Sources
- cloud_defend.process
- cloud_defend.file
- Elastic Agent
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Attackers may spawn interactive shells within production containers to conduct reconnaissance or execute commands. | Process events where process.interactive is true and the container image is not a known administrative tool. | Execution | Medium |
| Attackers may attempt to modify or create executables in system directories within a container to establish persistence. | File events with event.action of createExecutable or modifyExecutable targeting paths like /usr/bin/** or /etc/**. | Persistence | Low |
Control Gaps
- Network traffic visibility
- Read-only file access (e.g., secret scraping)
- File events on Azure AKS
Key Behavioral Indicators
- process.interactive
- process.thread.capabilities.effective
- container.security_context.privileged
- cloud_defend.matched_selectors
False Positive Assessment
- Medium
Recommendations
Immediate Mitigation
- Deploy Defend for Containers in monitoring mode to baseline normal workload behavior.
- Enable the pre-built container detection rules in Elastic Security 9.3.0+.
Infrastructure Hardening
- Ensure containers run with the minimum required Linux capabilities.
- Avoid running containers in privileged mode unless strictly necessary.
- Treat container filesystems as immutable to prevent unauthorized executable creation.
User Protection
- N/A
Security Awareness
- Train detection engineers on container-specific telemetry, including namespaces, capabilities, and interactive execution flags.
MITRE ATT&CK Mapping
- T1609 - Container Administration Command
- T1611 - Escape to Host
- T1552.007 - Unsecured Credentials: Container API
