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

T1613: Container and Resource Discovery

Adversaries may attempt to discover containers and other resources that are available within a containers environment. Other resources may include images, deployments, pods, nodes, and other information such as the status of a cluster.

These resources can be viewed within web applications such as the Kubernetes dashboard or can be queried via the Docker and Kubernetes APIs.[1][2] In Docker, logs may leak information about the environment, such as the environment’s configuration, which services are available, and what cloud provider the victim may be utilizing. The discovery of these resources may inform an adversary’s next steps in the environment, such as how to perform lateral movement and which methods to utilize for execution.

EnterpriseT1613TechniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Container and Resource Discovery matters because it helps an intruder understand how a container environment is built before choosing where to move next. In Kubernetes or Docker environments, visibility into pods, nodes, deployments, images, cluster status, dashboards, APIs, or leaked logs can reveal operational structure and cloud/provider context. For leaders, this is a control-validation issue: can the organization prove that only legitimate identities and systems can enumerate container resources, and that suspicious enumeration would be visible to the SOC?

Executive priority

Prioritize this where container platforms support critical services, regulated workloads, or cloud-connected operations. The business risk is not discovery alone; it is that discovery can guide later lateral movement or execution choices. Executives should ask whether container API access, dashboard exposure, account privileges, and network reachability are governed, logged, and reviewable as compliance and incident-response evidence.

Technical view

This is an enterprise ATT&CK discovery technique for Containers. The supplied ATT&CK description points to Kubernetes dashboards, Docker APIs, Kubernetes APIs, and logs as places where adversaries may learn about containers, images, deployments, pods, nodes, cluster status, services, configuration, and cloud-provider context. SOC and IR teams should validate whether API enumeration and dashboard access are logged, whether those logs identify the calling user, service account, workload, source, and requested resource type, and whether unusual resource-listing activity can be distinguished from normal orchestration and administration. ATT&CK lists DET0490 as a detection strategy for this technique, but no official detection text is provided in the supplied object.

Likely telemetry

  • Kubernetes API audit or access records for resource listing and cluster-status queries
  • Docker Engine API access records where available
  • Kubernetes dashboard authentication and access logs
  • Container and platform logs that may expose configuration, services, or cloud-provider context
  • Identity and account activity for users or service accounts accessing container APIs

Detection direction

  • Baseline legitimate administrative, automation, and orchestration-driven enumeration of pods, nodes, deployments, images, and cluster status before alerting on volume alone.
  • Validate that container API and dashboard access logs contain enough identity, source, resource, and action detail to support triage.
  • Look for unusual discovery patterns by non-administrative users, unexpected service accounts, unfamiliar sources, or workloads that normally should not enumerate broad cluster resources.
  • Tune carefully for false positives from deployment tools, monitoring systems, schedulers, and routine cluster administration.
  • Use relationship context conservatively: ATT&CK associates this technique with TeamTNT, Hildegard, and Peirates, so detections should consider container/cloud post-exploitation context without assuming attribution.

Mitigation priorities

  • Apply User Account Management by enforcing least privilege for users and service accounts that can view container and cluster resources.
  • Limit Access to Resource Over Network so Docker and Kubernetes APIs, dashboards, and related services are reachable only from systems and identities with a business need.
  • Use Network Segmentation to reduce unnecessary paths to container control-plane and management interfaces.
  • Review logs and configuration exposure so routine container logs do not unnecessarily disclose services, environment configuration, or cloud-provider details.
  • Confirm that access-control decisions and logging evidence are documented for incident response, audit, and compliance readiness.
Analyst notes and limits

The most important validation question is whether the organization can see and govern resource enumeration in container environments. This technique is especially relevant to managed detection, cloud/container security, identity and access management, and incident response because discovery activity can be an early signal that an actor is mapping the environment before choosing lateral movement or execution options.

The supplied ATT&CK object provides no official detection text, and DET0490 is referenced without detailed detection logic. Local platform configuration, logging maturity, Kubernetes/Docker deployment model, and normal administrative workflows are required to determine practical detection coverage. No active exploitation, customer exposure, or guaranteed detection is implied.

Official MITRE ATT&CK definition

Container and Resource Discovery

Adversaries may attempt to discover containers and other resources that are available within a containers environment. Other resources may include images, deployments, pods, nodes, and other information such as the status of a cluster.

These resources can be viewed within web applications such as the Kubernetes dashboard or can be queried via the Docker and Kubernetes APIs.[1][2] In Docker, logs may leak information about the environment, such as the environment’s configuration, which services are available, and what cloud provider the victim may be utilizing. The discovery of these resources may inform an adversary’s next steps in the environment, such as how to perform lateral movement and which methods to utilize for execution.

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

All related ATT&CK context

uses · Tool S0683: Peirates Enterprise mitigates · Mitigation M1030: Network Segmentation Enterprise uses · Group G0139: TeamTNT Enterprise uses · Malware S0601: Hildegard Enterprise detects · Detection Strategy DET0490: Detection Strategy for Container and Resource Discovery Enterprise mitigates · Mitigation M1035: Limit Access to Resource Over Network Enterprise mitigates · Mitigation M1018: User Account Management Enterprise
Mitigations

Mitigation direction

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

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

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.1
Created
Modified
Raw hash
5f1c2f4070be6220...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 5f1c2f4070be…
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]
    mitre-attack T1613
    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