Stealing Amazon EC2 Creds via Server Side Request Forgery

PFiles: Stealing Amazon EC2 Creds via Server Side Request Forgery

Explore our technique of using Server Side Request Forgery (SSRF) to successfully retrieve EC2 credentials, demonstrating advanced cybersecurity tactics.

Conor O'Neill
Conor O'Neill
Chief Product Officer
July 21, 2022

Welcome to our Pentest Files blog series.

Each blog post will present an interesting or dangerous finding one of our testers has identified in an actual recent pen-test, so you can see the kinds of cool things our pen-testers get up to, and also to help you take steps to prevent similar vulnerabilities in your own assets.

These findings are taken from real reports, anonymised, and published with kind permission from our clients.

Tester: Adam

Vertical: Ed-Tech/Training/Learning

Impact: Compromise of AWS instance and all user data on the instance

What Happened?

Adam exploited a Server-Side Request Forgery flaw to devastating effect here, using it to eventually retrieve EC2 credentials.

Some Background

Ever heard of Server-Side Request Forgery? This flaw is very dangerous, but less well known than classic web vulnerabilities like SQL injection or Cross-Site Scripting. This class of issue is often more difficult to identify and exploit.

Essentially, an SSRF vulnerability occurs when an attacker can instruct an application to load an internal resource not normally accessible from an external perspective.

Below, you’ll read how Adam used the SSRF flaw on an application hosted on AWS to make a request to the AWS EC2 Instance metadata Service. This service provides a method for EC2 administrators to access user data and credentials associated with the particular EC2 instance.

The metadata is usually made accessible to the administrator over the internal link local address at

The Finding

In this instance, Adam found an SSRF vulnerability in a function that allowed users to ‘Download from URL’. The attack started by playing around with this URL.

Adam initially exploited this functionality by supplying an URL to an external tester-controlled server.

Adam had created a simple HTML page on our server running on this URL, which contained an image referencing the internal EC2 metadata API. As the URL Downloader functionality only accepted images, testers tricked it into believing the metadata API served images by appending the URL fragment #test.png at the end of the URL. This would not alter responses from the metadata API itself but would pass the sanity check of the URL Downloader plugin.

The HTML source of this page which Adam created was as follows - you can see the img tag containing the EC2 metadata service URL.

<html><img src=""></html>

Essentially, once the setup was complete, Adam caused the ‘download URL’ functionality to trigger a request to the MetaData service, with the response (i.e. the data from the MetaData Service) being available in the subsequently downloaded image.

The raw response from the downloaded image can be seen below. Boom!

SSRF Response

The Fix

Again, the fix is made by improving the configuration settings of the environment, namely by restricting acceptable ports to 443 only and restricting all internal IP ranges, including, the EC2 Metadata API on and their IPv6 equivalents.

In this instance, we also recommended removing the functionality altogether.


We actually found this same vulnerability across multiple tests, which turned out to be an issue with the software our client was using, Moodle, hosted in AWS. After research, it appeared that this vulnerability had previously been discovered by an external security researcher who had notified the Moodle team and some ongoing discussion and development work was ongoing to help remediate the issue.

While a patch from the vendor was not immediately available the first time we observed this issue, we recommended some immediate security mitigations for our client to help protect their deployment of the application whilst the Moodle team worked on a patch for the issue.

This patch was released by the Moodle team a few months later and modified some default Moodle configuration settings to make this issue more difficult to exploit.

OnSecurity recommends keeping your software regularly up to date with the latest patches and ensuring that any application configuration conforms to best practices.

Bedtime Reading

Want to check for yourself if your application is free from this kind of vulnerability? Why not get a quote or contact us to set up a pentest.

More recommended articles

© 2024 ONSECURITY TECHNOLOGY LIMITED (company registered in England and Wales. Registered number: 14184026 Registered office: Runway East, 101 Victoria Street, Bristol, England, BS1 6PU). All rights reserved.