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

T1552.007: Container API

Adversaries may gather credentials via APIs within a containers environment. APIs in these environments, such as the Docker API and Kubernetes APIs, allow a user to remotely manage their container resources and cluster components.[1][2]

An adversary may access the Docker API to collect logs that contain credentials to cloud, container, and various other resources in the environment.[3] An adversary with sufficient permissions, such as via a pod's service account, may also use the Kubernetes API to retrieve credentials from the Kubernetes API server. These credentials may include those needed for Docker API authentication or secrets from Kubernetes cluster components.

EnterpriseT1552.007Sub-techniqueObject v1.2 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Container API access can turn a container or Kubernetes foothold into a credential exposure problem. If Docker or Kubernetes APIs are reachable and the calling identity has enough permission, an adversary may pull logs or query cluster resources that contain cloud, container, or Kubernetes secrets. For leaders, the issue is less “container compromise” in isolation and more whether API permissions, secrets handling, and audit visibility prevent one workload identity from becoming broader access across the environment.

Executive priority

Prioritize this where containers or Kubernetes support critical services, cloud access, or regulated workloads. The business question is whether container management APIs are restricted, service account permissions are minimal, and teams can prove through logs and access reviews that secrets are not broadly retrievable. This technique should inform cloud/container security funding, identity governance, incident response playbooks for suspected cluster compromise, and audit evidence around privileged access and network exposure.

Technical view

ATT&CK places this sub-technique under Credential Access and the parent technique Unsecured Credentials, with the Containers platform. SOC, detection engineering, and IR teams should validate visibility into Docker API and Kubernetes API activity, especially requests that retrieve logs, secrets, service account tokens, or cluster component credentials. The relationship to DET0198 indicates a detection strategy exists for abuse of container APIs for credential access; teams should map that strategy to local Kubernetes API server audit logging, container runtime/API logs, network access records, and identity/RBAC context. The Peirates relationship is useful context because ATT&CK describes it as a Kubernetes post-exploitation framework focused on gathering service account tokens for lateral movement and privilege escalation; detections should therefore consider suspicious service-account-driven API activity, not only human administrator activity.

Likely telemetry

  • Kubernetes API server audit logs showing resource access, especially secrets, service accounts, pods, and logs
  • Docker API access logs or daemon logs where available, including remote API usage
  • Container and pod logs that may contain exposed credentials or access tokens
  • Kubernetes RBAC and service account bindings for authorization context
  • Network telemetry showing access to Docker or Kubernetes API endpoints

Detection direction

  • Confirm whether DET0198-style detection logic is implemented against the telemetry actually collected in the environment.
  • Baseline expected Kubernetes API access by service accounts, administrators, and automation, then alert on unusual retrieval of secrets, service account token access, or broad log collection.
  • Review Docker API exposure and monitor remote management API access, especially where logs may contain credentials.
  • Correlate API calls with RBAC permissions so alerts distinguish expected controllers and CI/CD automation from unexpected workload identities.
  • Tune for common false positives from backup tools, operators/controllers, deployment automation, and legitimate troubleshooting that reads logs or secrets.

Mitigation priorities

  • Start with user account management and service account lifecycle controls: remove stale accounts and ensure identities have a documented business purpose.
  • Apply privileged account management to cluster administrator roles and high-permission service accounts, using least privilege and accountability for privileged actions.
  • Restrict access to Docker and Kubernetes APIs over the network so only authorized users, systems, and workloads can reach management endpoints.
  • Use network segmentation to limit exposure of container management APIs and reduce opportunities for lateral movement after a workload compromise.
  • Review Kubernetes RBAC and service account permissions to reduce unnecessary ability to read secrets, logs, or cluster-wide resources.
Analyst notes and limits

This object is specifically about credential gathering through container environment APIs, including Docker API log access and Kubernetes API retrieval of credentials or secrets when permissions allow it. The supplied relationships support emphasis on account management, privileged account management, network segmentation, limiting network access to resources, and detection strategy alignment. Local implementation details matter: the same API call may be benign for a controller or administrator and suspicious for an unexpected workload identity.

The official ATT&CK detection field for this object is not provided, so detection guidance must be validated against the related DET0198 strategy and local telemetry. The supplied data does not justify claims of active exploitation, organization-specific exposure, guaranteed detection, or impact beyond credential access risk in container environments.

Official MITRE ATT&CK definition

Container API

Adversaries may gather credentials via APIs within a containers environment. APIs in these environments, such as the Docker API and Kubernetes APIs, allow a user to remotely manage their container resources and cluster components.[1][2]

An adversary may access the Docker API to collect logs that contain credentials to cloud, container, and various other resources in the environment.[3] An adversary with sufficient permissions, such as via a pod's service account, may also use the Kubernetes API to retrieve credentials from the Kubernetes API server. These credentials may include those needed for Docker API authentication or secrets from Kubernetes cluster components.

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.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1552 Unsecured Credentials This object subtechnique of Unsecured Credentials.
Associated objects

Groups, software, and campaigns

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
Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1552: Unsecured Credentials Enterprise detects · Detection Strategy DET0198: Detect Abuse of Container APIs for Credential Access Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise uses · Tool S0683: Peirates Enterprise mitigates · Mitigation M1035: Limit Access to Resource Over Network Enterprise mitigates · Mitigation M1030: Network Segmentation Enterprise mitigates · Mitigation M1018: User Account Management Enterprise
Mitigations

Mitigation direction

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

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

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

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.

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.

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.2
Created
Modified
Raw hash
a00451bc97558cf4...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle a00451bc9755…
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 API

    Docker. (n.d.). Docker Engine API v1.41 Reference. Retrieved March 31, 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]
    Unit 42 Unsecured Docker Daemons

    Chen, J.. (2020, January 29). Attacker's Tactics and Techniques in Unsecured Docker Daemons Revealed. Retrieved March 31, 2021.

    Open source URL
  4. [4]
    mitre-attack T1552.007
    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