T1552.005: Cloud Instance Metadata API

Cloud Instance Metadata API access matters because a compromised IaaS workload or vulnerable public-facing application can become a path to cloud credentials and sensitive instance data. For leaders, this is not just a cloud configuration issue; it affects how quickly an attacker could move from one virtual instance to broader cloud resources if metadata credentials or UserData secrets are reachable.

Executive priority

Prioritize this where IaaS workloads host public-facing services, hold cloud roles, or depend on UserData and instance metadata for operations. Executive questions should focus on whether teams can prove metadata access is restricted where possible, whether SSRF risk is managed for exposed applications, and whether SOC/IR teams can identify suspicious use of credentials obtained from an instance. This also supports audit and compliance evidence around least privilege, network restriction, and cloud credential handling.

Technical view

This is an ATT&CK credential-access sub-technique under Unsecured Credentials for IaaS. Defenders should validate controls and detections around access to the cloud metadata endpoint commonly hosted at 169.254.169.254, especially from workloads that should not need metadata access or from web application paths that could indicate SSRF-mediated access. Because ATT&CK provides no official detection text, use the related detection strategy, Detect Access to Cloud Instance Metadata API (IaaS), as a prompt to test whether host, workload, proxy, and cloud audit evidence can reconstruct metadata access and subsequent credential use. Relationship context also shows relevance to cloud/container-focused activity and tools, including TeamTNT, Hildegard, Peirates, Shai-Hulud, and TruffleHog, but local telemetry is required to determine exposure or activity.

Likely telemetry

Host or workload network telemetry showing requests to 169.254.169.254 where collection is available
Web server, reverse proxy, and application logs that could reveal SSRF-style requests toward the metadata service
Cloud audit logs showing use of instance-associated credentials against additional resources
Endpoint or workload process/network telemetry identifying which process initiated metadata access
Cloud configuration evidence for instance metadata, UserData usage, security groups, and network filtering controls

Detection direction

Baseline legitimate metadata API access per workload, then alert on unexpected processes, services, containers, or application paths accessing the metadata endpoint.
Tune for false positives from cloud agents and applications that legitimately require metadata, but require documented business need for recurring access.
Correlate metadata access with later cloud API activity by the instance role or credentials associated with the instance.
Pay special attention to public-facing web applications and proxies where SSRF could relay requests to the metadata API.
Account for blind spots: link-local metadata traffic may not traverse centralized network sensors, and ATT&CK does not provide official detection logic for this object.

Mitigation priorities

Apply least-privilege access to cloud roles and resources so metadata-exposed credentials have limited reach.
Use network access restrictions and filtering controls, aligned to M1035 and M1037, to limit which systems or workloads can reach sensitive network resources and services.
Disable or remove unnecessary metadata-related features or exposed data where supported and not required, aligned to M1042.
Review UserData and instance metadata practices to avoid placing secrets where metadata access could expose them.
Include SSRF prevention and validation in application security reviews for public-facing services that can make outbound requests.

Analyst notes and limits

This object is a sub-technique of T1552 Unsecured Credentials and replaces revoked technique T1522. The supplied relationship set includes one detection strategy and three mitigations, plus group/software usage relationships that indicate this behavior is represented in ATT&CK threat context. Use those relationships for prioritization, not as proof of current activity in any environment.

ATT&CK provides no official detection text for this technique, and the supplied fields do not specify provider-specific configuration options or guaranteed telemetry sources. Actual coverage depends on the cloud provider, workload architecture, logging configuration, and whether host or application-level visibility exists for metadata API access.

Official MITRE ATT&CK definition

Cloud Instance Metadata API

Adversaries may attempt to access the Cloud Instance Metadata API to collect credentials and other sensitive data.

Most cloud service providers support a Cloud Instance Metadata API which is a service provided to running virtual instances that allows applications to access information about the running virtual instance. Available information generally includes name, security group, and additional metadata including sensitive data such as credentials and UserData scripts that may contain additional secrets. The Instance Metadata API is provided as a convenience to assist in managing applications and is accessible by anyone who can access the instance.[1] A cloud metadata API has been used in at least one high profile compromise.[2]

If adversaries have a presence on the running virtual instance, they may query the Instance Metadata API directly to identify credentials that grant access to additional resources. Additionally, adversaries may exploit a Server-Side Request Forgery (SSRF) vulnerability in a public facing web proxy that allows them to gain access to the sensitive information via a request to the Instance Metadata API.[3]

The de facto standard across cloud service providers is to host the Instance Metadata API at http[:]//169.254.169.254.

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.

Filter related techniques 2 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1522	Cloud Instance Metadata API	Cloud Instance Metadata API revoked by this object.
Enterprise	T1552	Unsecured Credentials	This object subtechnique of Unsecured Credentials.

Associated objects

Groups, software, and campaigns

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]

S9009: TruffleHog

TruffleHog is an open-source secrets-discovery tool that is used to search for credentials, API keys, and encryption keys across a variety of data sources and environments.[1][2] TruffleHog has the ability to discover credentials and secrets stored in code repositories, git history, CI/CD pipelines, among other common storage locations to include filesystems and cloud storage buckets.[1][3][2] TruffleHog was first released by its author in 2016.[2]

IaaSLinuxSaaS

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

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

S9008: Shai-Hulud

Shai-Hulud is a supply chain worm, first reported in September 2025, that spreads through code repositories, including GitHub and NPM packages. It exploits CI/CD pipeline dependencies to propagate to victims and poisons the supply chain by publishing malicious packages. Once inside a victim environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows.[1][2][3][4][5][6][7]

LinuxSaaSWindows

Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0001: Detect Access to Cloud Instance Metadata API (IaaS) Enterprise mitigates · Mitigation M1035: Limit Access to Resource Over Network Enterprise revoked by · Technique T1522: Cloud Instance Metadata API Enterprise uses · Group G0139: TeamTNT Enterprise uses · Tool S9009: TruffleHog Enterprise mitigates · Mitigation M1042: Disable or Remove Feature or Program Enterprise uses · Tool S0683: Peirates Enterprise uses · Malware S0601: Hildegard Enterprise uses · Malware S9008: Shai-Hulud Enterprise mitigates · Mitigation M1037: Filter Network Traffic Enterprise subtechnique of · Technique T1552: Unsecured Credentials Enterprise

Mitigations

Mitigation direction

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

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.

M1037: Filter Network Traffic

Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic. This includes protocol-based filtering, enforcing firewall rules, and blocking or restricting traffic based on predefined conditions to limit adversary movement and data exfiltration. This mitigation can be implemented through the following measures:

Ingress Traffic Filtering:

- Use Case: Configure network firewalls to allow traffic only from authorized IP addresses to public-facing servers. - Implementation: Limit SSH (port 22) and RDP (port 3389) traffic to specific IP ranges.

Egress Traffic Filtering:

- Use Case: Use firewalls or endpoint security software to block unauthorized outbound traffic to prevent data exfiltration and command-and-control (C2) communications. - Implementation: Block outbound traffic to known malicious IPs or regions where communication is unexpected.

Protocol-Based Filtering:

- Use Case: Restrict the use of specific protocols that are commonly abused by adversaries, such as SMB, RPC, or Telnet, based on business needs. - Implementation: Disable SMBv1 on endpoints to prevent exploits like EternalBlue.

Network Segmentation:

- Use Case: Create network segments for critical systems and restrict communication between segments unless explicitly authorized. - Implementation: Implement VLANs to isolate IoT devices or guest networks from core business systems.

Application Layer Filtering:

- Use Case: Use proxy servers or Web Application Firewalls (WAFs) to inspect and block malicious HTTP/S traffic. - Implementation: Configure a WAF to block SQL injection attempts or other web application exploitation techniques.

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.4
Created: Feb 11, 2020, 18:47 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: aba71bed8f0b82c6...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.4	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`aba71bed8f0b…`

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]
AWS Instance Metadata API

AWS. (n.d.). Instance Metadata and User Data. Retrieved July 18, 2019.
Open source URL
[2]
Krebs Capital One August 2019

Krebs, B.. (2019, August 19). What We Can Learn from the Capital One Hack. Retrieved March 25, 2020.
Open source URL
[3]
RedLock Instance Metadata API 2018

Higashi, Michael. (2018, May 15). Instance Metadata API: A Modern Day Trojan Horse. Retrieved July 16, 2019.
Open source URL
[4]
mitre-attack T1552.005
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

Analyst context for executives and security teams