Field Notes: SSRF to Cloud Takeover

The most damaging findings often start with a single innocuous request. On a recent web and cloud engagement for a mid-market fintech, our operators turned one server-side request forgery flaw into a path toward full cloud account takeover. The application looked well built, the team was capable, and the flaw was the kind that hides in a helpful feature. That is exactly why it is worth writing up.

These field notes are anonymised. No client is named, no real data appears, and the specifics are generalised so the lessons carry across without exposing anyone. The aim is to show how an SSRF cloud metadata attack unfolds in the real world, and how a few layered controls would have stopped it turning into a crisis.

The Setup

The engagement covered a customer-facing web application and its supporting API, hosted in a major public cloud. Fintech environments make attractive targets because they combine sensitive data, real money movement and the pressure to ship features quickly. The scope was a grey-box test: we had a normal user account and a general understanding of the platform, much as a motivated attacker would after signing up.

We spent the early phase mapping the application's behaviour, watching how it handled input and, in particular, where it fetched things on a user's behalf. Any feature that makes the server go and retrieve something is worth close attention, because those are the features an attacker can try to redirect. This kind of careful, attacker-minded review is the heart of application-focused penetration testing.

Initial Foothold

The weak point was a document preview feature. Users could supply a link to a resource, and the server would fetch it and render a preview. It is a common, useful pattern, and it is also a classic source of server-side request forgery.

The application filtered for obviously dangerous inputs, but the checks were built around blocking known-bad patterns rather than allowing only known-good destinations. That distinction matters. Blocklists are brittle, because there is always another way to express a destination the filter did not anticipate. Through careful crafting of the supplied link, we confirmed the server could be made to request an internal address of our choosing rather than a legitimate external document.

At that point we had not stolen anything. We had simply demonstrated that we could steer the server's own outbound requests. In a cloud environment, that capability points at one target above all others.

Escalation

Cloud instances expose an internal metadata endpoint, reachable only from the instance itself, that returns configuration details and, on setups that have not been hardened, temporary credentials tied to the workload's assigned role. It exists so an instance can discover its own settings without hard-coded secrets. It is enormously convenient, and it sits at a fixed, well-known internal address.

We pointed the vulnerable preview feature at that endpoint. The server, doing exactly what it was told, fetched the metadata and returned it to us through the preview. Among the response were short-lived credentials for the role attached to the instance. The hardened version of the metadata service, which requires a signed session token that a simple forged request cannot obtain, had not been enforced. That single hardening step would have blocked this route outright.

With temporary credentials in hand, the severity depended entirely on what that role was permitted to do. Here the second problem surfaced. The role was over-permissioned, granted broad access early in the project for convenience and never trimmed back. Using the harvested credentials, we could enumerate cloud resources well beyond anything the preview feature needed. That included access to a storage location holding configuration files, and within them, secrets that had been stored in plaintext rather than in a managed vault.

Impact

We stopped once the path was proven and did not touch customer data or move money. In a test of this kind, demonstrating reach and documenting it responsibly is the whole point.

The chain we established led from an anonymous preview request to temporary cloud credentials, then to exposed secrets that would have unlocked further systems. In a fintech context that trajectory points toward account takeover of the cloud environment itself: the ability to read sensitive records, tamper with services and undermine the platform customers trust with their money. We kept the impact qualitative and tied to demonstrated access rather than inventing figures, because the reach was serious enough on its own. The important message for the client was that one overlooked feature connected directly to the crown jewels.

What Went Wrong

As with most high-severity findings, no single mistake was catastrophic. The damage came from several ordinary gaps lining up:

• A fetch feature that trusted a blocklist instead of allowlisting safe destinations.
• The hardened metadata service not enforced, leaving credentials reachable by a basic forged request.
• An instance role granted far more privilege than the workload needed.
• Secrets stored in plaintext configuration rather than a managed vault.
• No monitoring to flag metadata access arriving from an unexpected code path.

Any one of those controls, applied properly, would have broken the chain. Together, their absence turned a preview bug into a route to takeover.

How to Prevent This

The reassuring part is that each fix is well understood, and you only need to hold one link to stop the attack.

• Enforce the hardened metadata service that requires a signed session token. It blocks the most common SSRF path to credentials and should be on everywhere by default.
• Validate outbound requests with an allowlist of permitted destinations, rather than trying to blocklist dangerous ones. Deny by default, then permit the specific hosts the feature genuinely needs.
• Apply least privilege to every instance role. If a stolen credential can do almost nothing, an SSRF flaw becomes a contained incident instead of a takeover.
• Keep secrets in a managed vault with tight access policies, never in plaintext configuration or storage.
• Monitor for metadata access from unusual code paths and for cloud credentials being used from unexpected places, so a live attempt shows up while there is still time to respond.

Above all, test the way these pieces connect. A scanner might flag the SSRF, and a cloud review might note the broad role, but only an engagement that chains them shows how a preview feature ends at the crown jewels. That is the value of combined application and cloud-focused penetration testing, reinforced by regular vulnerability assessments and, where appropriate, the adversary-emulation depth of AI-driven offensive security.

If you run sensitive workloads in the cloud and are not certain how far a single application flaw could reach, that is a question worth answering deliberately. Our expert operators run these engagements across Australia from our Brisbane base, and we are glad to talk it through. Get in touch or call 1300 654 898 to start the conversation.