Home/ATT&CK Technique/Deploy Container
ATT&CK Technique

Deploy Container

T1610 · execution

Adversaries may deploy a container into an environment to facilitate execution or evade defenses. In some cases, adversaries may deploy a new container to execute processes associated with a particular image or deployment, such as processes that execute or download malware. In others, an adversary may deploy a new container configured without network rules, user limitations, etc. to bypass existing defenses within the environment.

In Kubernetes environments, an adversary may attempt to deploy a privileged or vulnerable container into a specific node in order to Escape to Host and access other containers running on the node. Containers can be deployed by various means, such as via Docker's create and start APIs or via a web application such as the Kubernetes dashboard or Kubeflow. In Kubernetes environments, containers may be deployed through workloads such as ReplicaSets or DaemonSets, which can allow containers to be deployed across multiple nodes.

Adversaries may deploy containers based on retrieved or built malicious images or from benign images that download and execute malicious payloads at runtime.

Containers

Actors Using This

1
ransomware_raas_hive_lineage_disputed_rebrandHunters International

Atomic Tests

1
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
bashcontainersDeploy Docker 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

Mitigations

4
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1018User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies.

Enforcing the Principle of Least Privilege
  • Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted.
  • Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions. Implementing Strong Password Policies.
  • Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse.
  • Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks. Managing Dormant and Orphaned Accounts.
  • Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits.
  • Use Case: Eliminates dormant accounts that could be exploited by attackers. Account Lockout Policies.
  • Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes.
  • Use Case: Mitigates automated attack techniques that rely on repeated login attempts. Multi-Factor Authentication (MFA) for High-Risk Accounts.
  • Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics.
  • Use Case: Prevents unauthorized access, even if credentials are stolen. Restricting Interactive Logins.
  • Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions.
  • Use Case: Protects sensitive accounts from misuse or exploitation.
Tools for Implementation Built-in Tools
  • Microsoft Active Directory (AD): Centralized account management and RBAC enforcement.
  • Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.
Identity and Access Management (IAM) Tools
  • Okta: Centralized user provisioning, MFA, and SSO integration.
  • Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.
Privileged Account Management (PAM)
  • CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.
M1030Network Segmentation

Network segmentation involves dividing a network into smaller, isolated segments to control and limit the flow of traffic between devices, systems, and applications. By segmenting networks, organizations can reduce the attack surface, restrict lateral movement by adversaries, and protect critical assets from compromise. Effective network segmentation leverages a combination of physical boundaries, logical separation through VLANs, and access control policies enforced by network appliances like firewalls, routers, and cloud-based configurations.

Segment Critical Systems
  • Identify and group systems based on their function, sensitivity, and risk. Examples include payment systems, HR databases, production systems, and internet-facing servers.
  • Use VLANs, firewalls, or routers to enforce logical separation.
Implement DMZ for Public-Facing Services
  • Host web servers, DNS servers, and email servers in a DMZ to limit their access to internal systems.
  • Apply strict firewall rules to filter traffic between the DMZ and internal networks.
Use Cloud-Based Segmentation
  • In cloud environments, use VPCs, subnets, and security groups to isolate applications and enforce traffic rules.
  • Apply AWS Transit Gateway or Azure VNet peering for controlled connectivity between cloud segments.
Apply Microsegmentation for Workloads
  • Use software-defined networking (SDN) tools to implement workload-level segmentation and prevent lateral movement.
Restrict Traffic with ACLs and Firewalls
  • Apply Access Control Lists (ACLs) to network devices to enforce "deny by default" policies.
  • Use firewalls to restrict both north-south (external-internal) and east-west (internal-internal) traffic.
Monitor and Audit Segmented Networks
  • Regularly review firewall rules, ACLs, and segmentation policies.
  • Monitor network flows for anomalies to ensure segmentation is effective.
Test Segmentation Effectiveness
  • Perform periodic penetration tests to verify that unauthorized access is blocked between network segments.
M1035Limit Access to Resource Over Network

Restrict access to network resources, such as file shares, remote systems, and services, to only those users, accounts, or systems with a legitimate business requirement. This can include employing technologies like network concentrators, RDP gateways, and zero-trust network access (ZTNA) models, alongside hardening services and protocols.

Audit and Restrict Access
  • Regularly audit permissions for file shares, network services, and remote access tools.
  • Remove unnecessary access and enforce least privilege principles for users and services.
  • Use Active Directory and IAM tools to restrict access based on roles and attributes.
Deploy Secure Remote Access Solutions
  • Use RDP gateways, VPN concentrators, and ZTNA solutions to aggregate and secure remote access connections.
  • Configure access controls to restrict connections based on time, device, and user identity.
  • Enforce MFA for all remote access mechanisms.
Disable Unnecessary Services
  • Identify running services using tools like netstat (Windows/Linux) or Nmap.
  • Disable unused services, such as Telnet, FTP, and legacy SMB, to reduce the attack surface.
  • Use firewall rules to block traffic on unused ports and protocols.
Network Segmentation and Isolation
  • Use VLANs, firewalls, or micro-segmentation to isolate critical network resources from general access.
  • Restrict communication between subnets to prevent lateral movement.
Monitor and Log Access
  • Monitor access attempts to file shares, RDP, and remote network resources using SIEM tools.
  • Enable auditing and logging for successful and failed attempts to access restricted resources.
Tools for Implementation File Share Management
  • Microsoft Active Directory Group Policies.
  • Samba (Linux/Unix file share management)
AccessEnum (Windows access auditing tool) Secure Remote Access
  • Microsoft Remote Desktop Gateway.
  • Apache Guacamole (open-source RDP/VNC gateway)
  • Zero Trust solutions: Tailscale, Cloudflare Zero Trust Service and Protocol Hardening:.
  • Nmap or Nessus for network service discovery.
  • Windows Group Policy Editor for disabling SMBv1, Telnet, and legacy protocols.
  • iptables or firewalld (Linux) for blocking unnecessary traffic Network Segmentation:.
  • pfSense for open-source network isolation.
M1047Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements.

The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures. Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.

System Audit
  • Use Case: Regularly assess system configurations to ensure compliance with organizational security policies.
  • Implementation: Use tools to scan for deviations from established benchmarks.
Permission Audits
  • Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation.
  • Implementation: Run access reviews to identify users or groups with excessive permissions.
Software Audits
  • Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector.
  • Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.
Configuration Audits
  • Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA).
  • Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.
Network Audits
  • Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections.
  • Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Detection Coverage

1/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) none
Analytics (MITRE CAR) none
Runtime / container (Falco) 6
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none

Falco Runtime Rules

6
Container / Linux runtime detections that fire on this technique.
INFOLaunch Sensitive Mount Container
Detect the initial process launched within a container that has a mount from a sensitive host directory (e.g. /proc). Exceptions are made for known trusted images. This rule holds value for generic auditing; however, its noisiness varies based on your environment.
view condition
container_started and sensitive_mount and not falco_sensitive_mount_containers and not user_sensitive_mount_containers
INFOContainer Run as Root User
Container detected running as the root user. This should be taken into account especially when policies disallow containers from running with root user privileges. Note that a root user in containers doesn't inherently possess extensive power, as modern container environments define privileges through Linux capabilities. To learn more, check out the rule "Launch Privileged Container".
view condition
spawned_process and container and proc.vpid=1 and user.uid=0 and not user_known_run_as_root_container
INFOLaunch Privileged Container
Detect the initial process initiation within a privileged container, with exemptions for known and trusted images. This rule primarily serves as an excellent auditing mechanism since highly privileged containers, when compromised, can result in significant harm. For instance, if another rule triggers within such a privileged container, it could be seen as more suspicious, prompting a closer inspection.
view condition
container_started and container.privileged=true and not falco_privileged_containers and not user_privileged_containers and not redhat_image
INFOLaunch Excessively Capable Container
Identify containers that start with a powerful set of capabilities, with exceptions for recognized trusted images. Similar to the "Launch Privileged Container" rule, this functions as a robust auditing rule. Compromised highly privileged containers can lead to substantial harm. For instance, if another rule is triggered within such a container, it might raise suspicion, prompting closer scrutiny.
view condition
container_started and excessively_capable_container and not falco_privileged_containers and not user_privileged_containers
WARNINGLaunch Disallowed Container
Detect the initial process launched within a container that is not in a list of allowed containers. This rule holds value for generic auditing; however, this rule requires a good understanding of your setup and consistent effort to keep the list of allowed containers current. In some situations, this can be challenging to manage.
view condition
container_started and not allowed_containers
WARNINGKubernetes Client Tool Launched in Container
Detect the execution of a Kubernetes client tool (like docker, kubectl, crictl) within a container, which is typically not expected behavior. Although this rule targets container workloads, monitoring the use of tools like crictl on the host over interactive access could also be valuable for broader auditing objectives.
view condition
spawned_process and container and not user_known_k8s_client_container_parens and proc.name in (k8s_client_binaries)

Comply & Defend

Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
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