Suspicious Process Execution in Containers from Transient Directories

This threat brief details a technique where adversaries, having gained initial access to a container, leverage transient or low-trust directories such as /tmp, /dev/shm, /var/tmp, /run, /var/run, /mnt, /media, and /boot to stage and execute malicious payloads. This approach is primarily used to evade detection, establish persistence, and prepare for data exfiltration or further pivoting within the environment. Attackers often gain a shell via methods like kubectl exec, then download or copy tools (e.g., reverse shells, tunneling utilities) into these volatile directories, executing them interactively. By utilizing locations outside the container's image filesystem, they circumvent image-based security controls and complicate forensic analysis, signalling live operator control and attempts to bypass policy.

Attack Chain

1. Initial Access: An adversary gains a shell into a container, potentially via a compromised application vulnerability, misconfigured API, or through mechanisms like kubectl exec or attach into a running pod.
2. Staging Malicious Tools: The attacker uploads or downloads malicious binaries, scripts, or tools (e.g., static reverse shells, tunneling tools) into transient or low-trust directories within the compromised container, such as /tmp, /dev/shm, or /var/tmp.
3. Execution from Suspicious Directory: The adversary executes these staged malicious tools or interactive shells directly from these transient directories. This avoids writing to the immutable parts of the container image, making detection and forensic analysis more challenging.
4. Defense Evasion: By leveraging volatile storage locations and interactive execution, the attacker evades traditional image-based security controls and potentially established forensic collection mechanisms designed for persistent storage.
5. Command and Control (C2): The executed malicious tools establish C2 communication, often involving external callbacks or tunnels, to an attacker-controlled infrastructure for remote management and further instructions.
6. Data Exfiltration / Impact: The attacker uses the established access to pivot within the environment, siphon sensitive data, establish persistence, or perform other malicious actions that may lead to further compromise or impact on the host system or other containers.

Impact

Successful exploitation allows adversaries to maintain live operator control over compromised containers, enabling data theft and potentially pivoting to other parts of the cloud or Kubernetes environment. This technique facilitates evasion of forensic analysis and policy controls, leading to prolonged presence and unchecked malicious activities. Specific risks include exfiltration of sensitive data, establishment of persistence on the host or in other containers, and privileged access if the affected pod has elevated permissions or host namespace access, potentially leading to full cluster compromise. Uncontained threats can allow writes to critical system directories like /boot or exposure of credentials.

Recommendation

• Deploy the Sigma rule in this brief to your SIEM and tune for your environment, paying particular attention to process creation logs for Linux containers.
• Review Kubernetes API server audit logs for pod/exec or attach events around any alert, correlating them with the initiating user, source IP, and service account to identify the initial access vector.
• Harden Kubernetes deployments by enforcing readOnlyRootFilesystem with seccomp and AppArmor, and mounting /tmp and /dev/shm with noexec, nodev, nosuid flags where appropriate to restrict execution from these paths.
• Use admission policies to allowlist executable paths within containers and deny interactive TTYs for production workloads, preventing unauthorized process execution.
• Implement NetworkPolicies to apply deny-all egress rules by default for production pods, then explicitly allow only necessary outbound connections to prevent C2 and data exfiltration.