T1610 CrowdStrike LogScale · LogScale

Detect Deploy Container in CrowdStrike LogScale

This detection identifies adversaries deploying containers with dangerous configurations to execute malicious payloads or escape defense controls. The detection monitors container runtime CLI invocations (docker, kubectl, podman, crictl) for high-risk flags such as --privileged, --net=host, --pid=host, and host filesystem volume mounts that are commonly abused by threat actors such as TeamTNT, Kinsing, and Doki to achieve container escape, cryptomining, and lateral movement. Risk scoring prioritizes privileged and host-mount combinations that enable direct node access in Kubernetes environments.

MITRE ATT&CK

Tactic
Defense Evasion Execution
Technique
T1610 Deploy Container
Canonical reference
https://attack.mitre.org/techniques/T1610/

LogScale Detection Query

CrowdStrike LogScale (LogScale)
cql
#event_simpleName=ProcessRollup2
| ImageFileName = /docker|kubectl|crictl|podman|nsenter|runc/i
| case {
    CommandHistory = /--privileged|nsenter.*pid.*1/i | RiskLevel := "Critical";
    CommandHistory = /--pid=host|--cap-add=SYS_ADMIN|--net=host/i | RiskLevel := "High";
    CommandHistory = /exec|run.*-it/i | RiskLevel := "Medium";
    * | RiskLevel := "Low"
  }
| where RiskLevel in ("Critical", "High", "Medium")
| table([@timestamp, UserName, ComputerName, ImageFileName, CommandHistory, RiskLevel])
high severity medium confidence

CrowdStrike Falcon LogScale CQL query for T1610 detection. Detects container deployment commands (docker, kubectl, podman) with high-risk flags associated with

Data Sources

ProcessRollup2 (Falcon sensor)

Required Tables

ProcessRollup2

False Positives & Tuning

  • Legitimate container infrastructure teams running privileged containers for monitoring agents (e.g., Datadog, Falco, Sysdig) that require host-level access
  • Kubernetes node-level tooling such as DaemonSets for log collection (Fluentd, Filebeat) that mount /var/log or /proc on the host
  • CI/CD pipelines (Jenkins, GitLab Runner, GitHub Actions self-hosted) that use docker-in-docker (DinD) with --privileged to build container images
  • Authorized security tooling like vulnerability scanners (Trivy, Anchore) that inspect host filesystems
  • Container runtime health checks by orchestration platforms that invoke crictl or ctr with management subcommands
Download portable Sigma rule (.yml)

Other platforms for T1610


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Deploy Privileged Container with Host Filesystem Mount

    Expected signal: Sysmon EventCode=1: Image=docker, CommandLine contains '--privileged' and '-v /:/host'. Follow-up EventCode=1 for 'docker exec' accessing /host/etc/passwd. Linux auditd EXECVE record for docker invocation.

  2. Test 2Deploy Container with Host Network and PID Namespace

    Expected signal: Sysmon EventCode=1: CommandLine contains '--net=host --pid=host'. DeviceNetworkEvents will show container traffic attributed to host network interface rather than docker0 bridge. Docker daemon log records container creation with HostConfig.NetworkMode=host.

  3. Test 3Deploy Privileged Pod via kubectl with hostPath Mount

    Expected signal: Sysmon EventCode=1: Image=kubectl, CommandLine='kubectl apply -f /tmp/atomic-t1610-pod.yaml'. Kubernetes API server audit log: CREATE verb on pods resource by current user with pod spec containing securityContext.privileged=true and hostPath volume. Second EventCode=1 for 'kubectl exec' access.

Unlock Pro Content

Get the full detection package for T1610 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections