How an Attacker Could Use Instance Metadata to Breach Your App in AWS 

By on Apr 06, 2020

Moving to a cloud-native architecture for your enterprise applications can deliver tremendous business value, adding scale and agility while off-loading onerous tasks like patching and upgrading server infrastructure.  

However, in every cloud environment, whether AWS, Azure, GCP or others, there is a new category of risk. Cloud-native threats stem from the new context and configuration requirements you have in a cloud environment. Historically, default settings like public access to storage objects have left sensitive data out in the open, easy to steal by anyone crawling for these weaknesses. 

It’s easy to make mistakes in a new environment, with new settings introduced continuously as new capabilities are added by cloud providers. The configuration of your cloud environment is always your responsibility. AWS and others have no control over how you use their services. They are a template for you to build from.  

Not understanding the outcome of your configurations and how you build cloud-native applications can have catastrophic consequences.  

At RSA conference this year, my colleague and CTO of McAfee Steve Grobman demonstrated how one particular feature of AWS, Instance Metadata, could be leveraged to steal sensitive data. Let’s walk through this scenario to highlight some key learnings, then discuss how to prevent your own exposure to an attack like this.  

Instance Metadata Attacks 

All cloud providers have capabilities to manage credentials for resources in your cloud-native applications. When used correctly, these capabilities allow you to avoid storing credentials in the clear, or in a source code repository. In AWS, the Instance Metadata Service (IMDS) makes information about a compute instance, its network, and storage available to software running on the instance. IMDS also makes temporary, frequently rotated credentials available for any IAM role attached to the instance. IAM roles attached to an instance may for example, define that the instance and software running on it can access data in S3 storage buckets.  

Let’s look at a common scenario.  

A team of epidemiologists built a cloud-native application in AWS with a public dashboard to visually represent data showing their progress analyzing a virus genome.  


During the development phase of this application, the team ran into a challenge. Most of the resources in their Virtual Private Cloud (VPC) were supposed to be hidden from the internet. The only resource in their VPC intended for public view was the dashboard.  

The S3 bucket hosting their data needed to stay private. To pull data from S3 to the public dashboard, they added a reverse proxy, acting as a middleman. All it took was a quick Google search, and a few lines of code to add this to their application.  

For the team of epidemiologists, the reverse proxy was a basic, elegant solution that functioned perfectly for their use case. What they didn’t realize is that it set them up for a massive breach.  

The compute instance running the reverse proxy had been assigned an IAM role with permission to access their private S3 bucket. Credentials for the reverse proxy to access S3 were obtained from Instance Metadata.  

An attacker visiting the site and interested in their data noticed the team had referenced the reverse proxy’s IP address in the dashboard. The attacker then checked to see if they could connect to it. After confirming their connectivity, the attacker then checked to see if they could access Instance Metadata through the reverse proxy. Success. 

Through the reverse proxy and from the Instance Metadata, the attacker uncovered credentials to the team’s private S3 storage bucket.  

Now, with access to the S3 bucket, the attacker could steal highly sensitive data the team had stored for their application. The attacker simply synced the target S3 bucket to their own S3 bucket in another AWS account, and the data was theirs.  


This type of attack is just one of 43 techniques described by MITRE in their  ATT&CK framework for cloud environments: 

How AWS Mitigates Instance Metadata Attacks 

The Instance Metadata Service (IMDS) from AWS simplifies access between resources in a cloud-native application. To improve the security of this service, AWS released IMDSv2, which adds several new layers of protection.  

In IMDSv2, external users are blocked from receiving credentials, allowing only application resources to receive them. Read more about this layer of protection and IMDSv2 here: 

In the attack we just described, the reverse proxy was misconfigured to allow external requests to reach internal resources. If the team had configured their compute instance to use IMDSv2, unauthorized access by the external threat actor would have been blocked.  

How MVISION Cloud Can Help 

At McAfee we have several approaches which can help you detect and prevent attacks like this. MVISION Cloud is our cloud-native security platform that allows you to monitor and update configurations in AWS, Azure, GCP along with a wide range of additional security measures you can read about here.  

Using a direct API-integration with AWS, MVISION Cloud continuously monitors CloudWatch Metrics which tell you the version of IMDS you’re using in every EC2 instance.  

When AWS CloudWatch logs an instance actively using IMDSv1, MVISION Cloud generates a security incident, notifying you to update your configuration to IMDSv2, which will prevent unauthorized access to your credentials by external users.  


MVISION Cloud policy incidents for IMDS version configuration  

It is a best practice to enforce IMDSv2 on your AWS instances for all local code and users. Once you specify that IMDSv2 must be used, IMDSv1 will no longer function. AWS has step by step instructions on how to configure your instances to use IMDSv2 here.  

Beyond this attack example, MVISION Cloud allows you to implement a series of best practices to protect your cloud-native applications: 

  • Continuously audit your configurations. With MVISION Cloud you can scan CloudFormation templates before they enter production, and then detect any “drift” in your configurations over time. This allows you to detect misconfigurations and enforce a least-privilege model for resource permission.  
  • Enforce Zero-Trust. Use zero-trust as a methodology, where only specific resources are allowed to run and communicate with each other. Everything else is blocked. 
  • Scan for code vulnerabilities. Particularly with open software distribution models like Docker, it is important to monitor your application resources for vulnerabilities on a continuous basis.  
  • Detect anomalies and threats. With User and Entity Behavior Analytics (UEBA), you can assess millions of cloud events to uncover anomalous activity and real threats like credential theft. 
  • Run DLP on storage objects. Just like any other cloud service you sanction, your network, or endpoints, within AWS you can and should classify your data within S3 and run data loss prevention to stop exfiltration attempts.  

Get in touch with us to talk about implementing these measures at your own organization.  

Also check out Steve’s keynote at RSA for this attack scenario in his own words:  

About the Author

Kaushik Narayan

Kaushik Narayan is responsible for the Cloud Business Unit at McAfee’s technology vision and software architecture. He is the former Co-founder and CTO at Skyhigh (acquired by McAfee, January 2018) and brings over 20 years of experience driving technology and architecture strategy for enterprise-class products.

Read more posts from Kaushik Narayan

Categories: Cloud Security

Subscribe to McAfee Securing Tomorrow Blogs