Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1609: Container Administration Command

Adversaries may abuse a container administration service to execute commands within a container. A container administration service such as the Docker daemon, the Kubernetes API server, or the kubelet may allow remote management of containers within an environment.[1][2][3]

In Docker, adversaries may specify an entrypoint during container deployment that executes a script or command, or they may use a command such as docker exec to execute a command within a running container.[4][5] In Kubernetes, if an adversary has sufficient permissions, they may gain remote execution in a container in the cluster via interaction with the Kubernetes API server, the kubelet, or by running a command such as kubectl exec.[6]

EnterpriseT1609TechniqueObject v1.3 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Container Administration Command matters because normal container management paths can become execution paths when the wrong identity, service account, network path, or administrator interface is exposed. For leaders, the risk is not just “a command ran in a container”; it is that Docker, Kubernetes API server, or kubelet access may let an intruder turn legitimate administration into remote execution inside production workloads.

Executive priority

Prioritize this as a cloud/container governance and resilience issue. Ask whether container administration interfaces are reachable only by approved operators and systems, whether privileged and user account permissions are lifecycle-managed, and whether audit evidence can show who executed commands in containers. This technique is especially relevant to budget and control decisions around Kubernetes/Docker access management, privileged account governance, network exposure reduction, and SOC visibility for container operations.

Technical view

T1609 is an execution technique for Containers. The supplied ATT&CK description identifies abuse of Docker daemon, Kubernetes API server, kubelet, Docker entrypoint behavior, Docker exec, and kubectl exec-style administration to run commands inside containers when sufficient permissions exist. SOC and IR teams should validate visibility into container administration events rather than only host or workload process telemetry. Relationship context includes a detection strategy, DET0065, but the official ATT&CK detection field for this object is not provided, so local detection engineering must define and test the concrete analytics.

Likely telemetry

  • Kubernetes API server audit logs showing exec-related requests and authenticated subject context
  • Kubelet access and operational logs where available
  • Docker daemon logs and container lifecycle events
  • Container runtime events for command execution, entrypoint changes, or interactive session activity
  • Identity and access records for users, service accounts, and privileged roles allowed to administer containers

Detection direction

  • Validate DET0065 or equivalent local analytics against the organization’s actual Kubernetes and Docker logging sources; do not assume coverage because container platforms are deployed.
  • Baseline legitimate administrative exec activity by user, service account, namespace, workload, time, and source network location to reduce false positives from normal troubleshooting.
  • Alert on unusual or high-risk container administration command execution, especially from unexpected identities, service accounts, namespaces, or network paths.
  • Correlate administration command events with privileged account use and management-plane access rather than relying only on in-container process logs.
  • Check blind spots where kubelet, Docker daemon, or Kubernetes API audit logging is disabled, incomplete, short-retained, or not forwarded to the SOC.

Mitigation priorities

  • Start with User Account Management: ensure users and service accounts with container administration rights have a valid business need and are removed or changed promptly when roles change.
  • Apply Privileged Account Management: restrict privileged container and cluster administration roles, enforce least privilege, and monitor privileged usage with accountability.
  • Limit Access to Resource Over Network: restrict network reachability to Docker daemon, Kubernetes API server, and kubelet management surfaces to approved users, systems, and administration paths.
  • Use Execution Prevention where applicable to limit unauthorized code or script execution in containerized environments.
  • Disable or remove unnecessary administration features, services, or exposed interfaces that are not required for operations.
Analyst notes and limits

Relationship context shows this technique is used by TeamTNT and by software/tools including Kinsing, Hildegard, Siloscape, and Peirates. Treat that as threat-context for prioritization and detection testing, not as evidence of activity in any specific environment. The most useful local questions are: who can execute commands in containers, from where, against which workloads, and can the SOC prove it from retained logs?

The official ATT&CK detection text for T1609 is not provided. The supplied material supports Containers as the platform and execution as the tactic, with Docker, Kubernetes API server, and kubelet administration paths named in the description. Specific detections, control effectiveness, exposure, and incident impact require local architecture, IAM, network, and logging evidence.

Official MITRE ATT&CK definition

Container Administration Command

Adversaries may abuse a container administration service to execute commands within a container. A container administration service such as the Docker daemon, the Kubernetes API server, or the kubelet may allow remote management of containers within an environment.[1][2][3]

In Docker, adversaries may specify an entrypoint during container deployment that executes a script or command, or they may use a command such as docker exec to execute a command within a running container.[4][5] In Kubernetes, if an adversary has sufficient permissions, they may gain remote execution in a container in the cluster via interaction with the Kubernetes API server, the kubelet, or by running a command such as kubectl exec.[6]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Associated objects

Groups, software, and campaigns

Group Enterprise

G0139: TeamTNT

TeamTNT is a threat group that has primarily targeted cloud and containerized environments. The group as been active since at least October 2019 and has mainly focused its efforts on leveraging cloud and container resources to deploy cryptocurrency miners in victim environments.[1][2][3][4][5][6][7][8][9]

Tool Enterprise

S0683: Peirates

Peirates is a post-exploitation Kubernetes exploitation framework with a focus on gathering service account tokens for lateral movement and privilege escalation. The tool is written in GoLang and publicly available on GitHub.[1]

Containers
Malware Enterprise

S0601: Hildegard

Hildegard is malware that targets misconfigured kubelets for initial access and runs cryptocurrency miner operations. The malware was first observed in January 2021. The TeamTNT activity group is believed to be behind Hildegard. [1]

LinuxContainersIaaS
Malware Enterprise

S0599: Kinsing

Kinsing is Golang-based malware that runs a cryptocurrency miner and attempts to spread itself to other hosts in the victim environment. [1][2][3]

ContainersLinux
Relationship explorer

All related ATT&CK context

uses · Group G0139: TeamTNT Enterprise uses · Tool S0683: Peirates Enterprise uses · Malware S0601: Hildegard Enterprise mitigates · Mitigation M1018: User Account Management Enterprise detects · Detection Strategy DET0065: Detection Strategy for Container Administration Command Abuse Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise mitigates · Mitigation M1042: Disable or Remove Feature or Program Enterprise uses · Malware S0623: Siloscape Enterprise uses · Malware S0599: Kinsing Enterprise mitigates · Mitigation M1035: Limit Access to Resource Over Network Enterprise mitigates · Mitigation M1038: Execution Prevention Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1018: User 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. This mitigation can be implemented through the following measures:

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.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Mitigation Enterprise

M1042: Disable or Remove Feature or Program

Disable or remove unnecessary and potentially vulnerable software, features, or services to reduce the attack surface and prevent abuse by adversaries. This involves identifying software or features that are no longer needed or that could be exploited and ensuring they are either removed or properly disabled. This mitigation can be implemented through the following measures:

Remove Legacy Software:

- Use Case: Disable or remove older versions of software that no longer receive updates or security patches (e.g., legacy Java, Adobe Flash). - Implementation: A company removes Flash Player from all employee systems after it has reached its end-of-life date.

Disable Unused Features:

- Use Case: Turn off unnecessary operating system features like SMBv1, Telnet, or RDP if they are not required. - Implementation: Disable SMBv1 in a Windows environment to mitigate vulnerabilities like EternalBlue.

Control Applications Installed by Users:

- Use Case: Prevent users from installing unauthorized software via group policies or other management tools. - Implementation: Block user installations of unauthorized file-sharing applications (e.g., BitTorrent clients) in an enterprise environment.

Remove Unnecessary Services:

- Use Case: Identify and disable unnecessary default services running on endpoints, servers, or network devices. - Implementation: Disable unused administrative shares (e.g., C$, ADMIN$) on workstations.

Restrict Add-ons and Plugins:

- Use Case: Remove or disable browser plugins and add-ons that are not needed for business purposes. - Implementation: Disable Java and ActiveX plugins in web browsers to prevent drive-by attacks.

Mitigation Enterprise

M1035: Limit 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. This mitigation can be implemented through the following measures:

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

Mitigation Enterprise

M1038: Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions. This mitigation can be implemented through the following measures:

Application Control:

- Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution. - Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.xml"`)

Script Blocking:

- Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources. - Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g., `Set-ExecutionPolicy AllSigned`)

Executable Blocking:

- Use Case: Prevent execution of binaries from suspicious locations, such as `%TEMP%` or `%APPDATA%` directories. - Implementation: Block execution of `.exe`, `.bat`, or `.ps1` files from user-writable directories.

Dynamic Analysis Prevention: - Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time. - Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.3
Created
Modified
Raw hash
f9674589a485f2e1...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.3 Current bundle f9674589a485…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Docker Daemon CLI

    Docker. (n.d.). DockerD CLI. Retrieved March 29, 2021.

    Open source URL
  2. [2]
    Kubernetes API

    The Kubernetes Authors. (n.d.). The Kubernetes API. Retrieved March 29, 2021.

    Open source URL
  3. [3]
    Kubernetes Kubelet

    The Kubernetes Authors. (n.d.). Kubelet. Retrieved March 29, 2021.

    Open source URL
  4. [4]
    Docker Entrypoint

    Docker. (n.d.). Docker run reference. Retrieved March 29, 2021.

    Open source URL
  5. [5]
    Docker Exec

    Docker. (n.d.). Docker Exec. Retrieved March 29, 2021.

    Open source URL
  6. [6]
    Kubectl Exec Get Shell

    The Kubernetes Authors. (n.d.). Get a Shell to a Running Container. Retrieved March 29, 2021.

    Open source URL
  7. [7]
    mitre-attack T1609
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use