A Server-Side Request Forgery (SSRF) attack occurs when an attacker tricks a server into making requests to other internal or external services on behalf of the server itself. This can lead to unauthorized access to sensitive data, exploitation of internal systems, and even full system takeover.

At Sweet Security, we’ve seen a surge in SSRF attacks within cloud environments, with 80% of our customers reporting that they’ve experienced this type of attack attempt.

In this article, we dive into a unique SSRF attack attempt made against a Sweet customer in the Fintech space. We’ll share the attempt in detail and outline how the customer used Sweet’s multi-layered approach to cloud detection and response to protect against it.

Are SSRF Attacks Cloud Attacks?

SSRF attacks often leverage misconfigurations or vulnerabilities in web applications, enabling attackers to access resources that should otherwise be protected. Because these requests are made from the server’s context, they aren’t necessarily a cloud attack and can therefore bypass traditional cloud security measures like CNAPP and Cloud Detection and Response (CDR) solutions.

However, there are instances where an SSRF attack can become a cloud attack.

A Real SSRF Attack

In the case of our customer, a threat actor used a SSRF against an instance metadata service of EC2. In other words, they leveraged the cloud control plane to conduct the SSRF attack.

As a result, their CloudTrail logs erupted with alerts about unauthorized access attempts to their control plane from an API Gateway—an action that should never occur. Unfortunately, they were in the dark about:

1. The origin of this access
2. Whether the access was successful
3. If the access came from an internal or external source

Is SSRF Detected by CSPM or CDR?

SSRF attacks are essentially conducted by tweaking a machine, and without visibility into the relevant processes of the application, you can’t know whether the activity was human-driven, what role the machine had, or even if the process was successful. Without application-level visibility, the customer was left with only the machine name from their cloud security solution. This is because CSPMs only provide a snapshot of your security posture but fail to capture the dynamic activity that leads to a change in state. You don’t end up seeing the activity that actually changed the status of the environment. For instance, if an attacker disables audit logs, you may see that logs are off in one scan and on in another, but you won’t know who made that change or when.

Combining CDR & ADR: Sweet’s Layer 7 (L7) Correlation with Cloud Logs

This is where Sweet came into play. Sweet’s multi-layered detection and response combines:

• Cloud Infra / CDR: Insights from cloud logs and APIs
• Workloads / CWPP: Monitored using our eBPF sensor
• API + App / ADR: With L7 analysis from our eBPF sensor
• Network / NDR: Monitored using our eBPF sensor

Our solution provided Layer 7 (L7) insights via our eBPF sensor, which provided our customer the ability to link the suspicious API activity with a specific workload. They were then able to pinpoint the exact process and compromised role responsible for the unauthorized access, allowing them to halt the unauthorized activity for good.

Should We Rely Solely on Sensor Data and ADR?

The answer is no. Consider a scenario involving a supply chain attack on an identity provider. If an attacker obtains the golden ID of Company X, for example, they could potentially access X’s cloud infrastructure without triggering any alarms in the application layer. They could extract sensitive data from an S3 bucket, all while leaving no trace in the workload. This type of breach emphasizes that an attack can occur outside the application environment, targeting users directly and bypassing cloud security measures like ADR.

This highlights a critical lesson: while ADR sensors are vital, they are not a complete solution on their own.

‍

‍

The Bottom Line: Cross-Correlating Application Activity with Cloud Logs is Key

The takeaway is clear: neither ADR, CWPP/EDR or CSPM/CDR is sufficient in isolation. It’s the correlation between the three that uncovers hidden threats.

At Sweet Security, we go a step further by tracking session IDs across both cloud and application layers and comparing them to identify anomalies. When a session in the cloud matches a session in the application, it forms a complete picture of the activity, enabling us to detect and respond to threats that may otherwise go unnoticed. Our detection system utilizes advanced sensors (ADR) combined with comprehensive analysis of cloud logs (CDR), monitoring a wide array of sources, including:

AWS

• CloudTrail
• CloudWatch
• RDS Audit Logs
• DynamoDB Images
• S3 Data Events Logs
• AWS Flow Logs

Google Cloud

• Google Audit Logs
• Cloud Storage Data Access Logs
• VPC Flow Logs

Azure

• Azure Audit Logs
• Storage Account Container Logs
• SQL DB Audit Logs
• Azure Network Flow Logs

This multi-layered monitoring ensures that all potential attack vectors are analyzed, providing robust defense against evolving cybersecurity threats.