Inside the March AWS EC SSRF Campaign: How Attackers Exploited Legacy Metadata Services

A Silent Storm: SSRF Exploitation in the Cloud

In March 2025, a sophisticated cyberattack campaign emerged, targeting websites hosted on Amazon Web Services (AWS) EC2 instances. The attackers exploited a web vulnerability known as Server-Side Request Forgery (SSRF) to access sensitive metadata and IAM credentials stored in the outdated Instance Metadata Service version 1 (IMDSv1).

Discovered and analyzed by F5 Labs, this campaign operated in stealth, leveraging outdated configurations and unpatched flaws to breach cloud defenses. The attack was systematic, well-orchestrated, and likely the work of a single threat actor. It serves as a stark reminder of how legacy technologies, if not upgraded or protected, become gateways for full-scale data breaches in modern cloud environments.

What Happened: A 30-Line Breakdown of the Campaign

A targeted cyber campaign exploited SSRF vulnerabilities in websites hosted on AWS EC2 instances.
Attackers used SSRF to trick servers into making internal HTTP requests on their behalf.
This gave them unauthorized access to the EC2 metadata endpoint, especially the insecure IMDSv1.
The exposed metadata included IAM credentials, allowing privilege escalation.
With stolen credentials, attackers could access or manipulate AWS services like S3 buckets.
This could lead to data leaks, service manipulation, or full account compromise.
The campaign was detected by F5 Labs and occurred between March 13–25, 2025.
Malicious traffic behavior pointed to a single, highly organized threat actor.
Attacks started with basic probes, then scaled up quickly within two days.
IP addresses involved were mostly traced to France and Romania.
Attackers used six different query parameter names to evade detection.
They rotated these along with multiple subpaths like /meta-data/ and /user-data.
Their methodical approach highlights strong reconnaissance and automation skills.
The flaw existed only in instances still using IMDSv1, which lacks strong authentication.

– IMDSv2,

Many organizations continue to rely on IMDSv1 due to legacy systems or lack of awareness.
Broader context: The campaign was featured in F5 Labs’ March 2025 threat trends report.
It appeared alongside a list of the most exploited vulnerabilities that month.
Notably, 40% of those vulnerabilities were more than four years old.
This indicates a consistent industry issue: delayed patching and weak cyber hygiene.
The four most targeted CVEs involved old RCE flaws in PHPUnit, Guangzhou ONU, TP-Link, and ThinkPHP.
The SSRF exploitation method isn’t new, but its effectiveness lies in poor cloud hardening.
Attackers used a clear pattern: identify weak EC2 targets → SSRF injection → metadata access.
Metadata access gave them IAM credentials → which enabled further AWS exploitation.
The attack vector was especially dangerous because it bypassed traditional perimeter defenses.
The vulnerable websites were likely unaware of the internal requests being made.
Once inside, the attacker could act like a legitimate AWS user.
This included reading or writing to S3 buckets, launching new instances, or deleting backups.
The campaign proves that cloud misconfigurations are just as dangerous as software bugs.
AWS provides guidelines to disable IMDSv1 and enforce IMDSv2—but many fail to implement them.
Organizations are urged to review EC2 metadata access policies urgently.
Without action, attackers can quietly take over entire cloud infrastructures.

What Undercode Say: The Hidden Risks in Cloud Negligence

The March 2025 AWS EC2 campaign offers more than just a timeline of events—it reveals deep-seated issues in modern cloud security practices.

First, it exposes the danger of relying on outdated systems like IMDSv1. While AWS introduced IMDSv2 in 2019 with token-based authentication to secure metadata access, many organizations have failed to adopt it. This oversight leaves a wide-open door for attackers exploiting SSRF flaws. What makes this campaign particularly disturbing is not its sophistication, but how easily it succeeded due to poor configuration and legacy practices.

The attackers showed methodical precision: rotating parameters, probing internal metadata endpoints, and targeting only those vulnerable to SSRF. Their tactics weren’t just clever—they were built for scale. That level of automation indicates reconnaissance across hundreds (or even thousands) of AWS instances, suggesting that this wasn’t a random attack but a targeted, global campaign.

What’s striking is the speed. Within just 12 days, the attacker went from probing to full-scale exploitation. That timeline reflects either a pre-established script or prior testing—perhaps both. It underscores that in cloud environments, delay equals danger. Any unpatched system is just waiting to be discovered.

Another concerning aspect is the broader trend revealed in F5’s report. Legacy vulnerabilities—some over five years old—are still actively exploited. It suggests that patch management is still a weak link in many organizations’ security strategies. Attackers don’t need zero-days when old bugs remain unpatched. That’s a chilling reality.

SSRF itself isn’t a new threat vector. But its power is often underestimated. When used in cloud environments, SSRF becomes a pathway into the very heart of an organization’s digital operations. Through SSRF, attackers aren’t just stealing credentials—they’re inheriting identity within the cloud itself.

Moreover, the campaign illustrates how misconfigured or poorly secured EC2 instances can become liability zones. By compromising IAM credentials, an attacker effectively becomes the AWS root user for the duration of the credentials’ validity. From there, it’s not just about reading data—it’s about total control. And because it’s happening through legitimate AWS APIs, detection becomes harder.

To mitigate this, organizations must do more than patch—they need cloud-native security policies. That includes enforcing IMDSv2, setting up metadata access controls, and monitoring unusual internal traffic from EC2 instances.

The bigger takeaway is this: cloud doesn’t mean secure by default. Every configuration choice is a security decision. When developers leave metadata endpoints exposed or fail to disable legacy services, they create weaknesses attackers are eager to exploit.

The lesson from this campaign isn’t just to upgrade IMDS—it’s to recognize that attackers are constantly scanning for the low-hanging fruit. Don’t be that fruit.