Cloud Application Penetration Testing

An application on AWS, Azure or GCP sits inside an identity and network fabric that a traditional test ignores. We pay attention to it. An SSRF in a URL-fetch feature is a minor bug on a bare server and a critical one when it can reach 169.254.169.254 and pull the instance’s credentials. We test for that reach specifically, because in cloud-hosted apps it is one of the most reliable routes from web bug to infrastructure access.

We usually work grey-box: you give us credentials for each role and a basic description of the architecture, and we test with that knowledge. It is the most cost-effective approach, because we spend the budget finding real flaws rather than guessing at things you could simply tell us. Pure black-box and full white-box reviews are both available when the goal calls for them.

We proxy the application through Burp Suite and map every route, parameter, API call and hidden function, using ffuf and nmap to widen coverage where it helps. We fingerprint the stack and the hosting so we know which cloud-specific attacks are worth pursuing before we spend time on them.

This is where a penetration test earns its name. We do not stop at “this parameter looks injectable”. We confirm the SQL injection, establish what it reaches, and check whether it hands us credentials that open another door. We take the SSRF and see whether it reaches the metadata service. We chain the information leak, the weak access control and the misconfiguration into the shortest realistic path to your crown-jewel data, then write that path up so it is undeniable.

Privilege escalation

Once we have a foothold as one user, we push. Horizontal movement to other users’ data, vertical movement to admin functions, and where the app touches cloud identity, an attempt to trade an application-level foothold for infrastructure access.

Post-exploitation, done responsibly

We prove impact without causing damage. We demonstrate that we could read the database rather than exfiltrating it, and that we could reach other tenants rather than tampering with their records. The rules of engagement are agreed in writing before we start.

Every engagement ends in a report written for two audiences: leadership who need the risk in business terms, and developers who need to reproduce and fix each issue precisely.

Still the most common critical finding. We enumerate objects and confirm whether one account can reach another’s data, then show the exact request. It maps to OWASP Top 10 A01, and in multi-tenant SaaS it is usually the finding that stops the release.

In cloud environments SSRF is a headline risk, not a footnote. Any feature that fetches a URL, renders a PDF from a link or imports from a remote source is a candidate. We test blocklist bypasses, redirect tricks and scheme switches, and we check whether the target of the request can be pointed at internal services or the cloud metadata API.

SQL injection remains alive in filters, sorting and legacy reporting features, frequently blind. We confirm it with careful, controlled queries and, where useful, sqlmap to validate a finding we have already established by hand. Command and template injection get the same treatment where the app builds shell commands or renders templates from input.

No scanner finds these. A checkout that applies a discount twice, a workflow that can be completed out of order to skip a payment step, a quota that resets when you call the endpoint directly. These require an engineer who understands what the application is for, and they are often the most valuable findings in the report.

A concise read for decision-makers: overall risk, the attack chains that matter, and what they would cost you if an outsider found them first.

For each finding: affected component, CVSS score, business impact, full reproduction steps with request and response evidence, and a prioritized, specific fix. Where findings chain, we document the chain end to end so the severity is understood in context, not per isolated bug.

After you fix, we re-test every finding at no charge and update the report. On request we provide an attestation letter suitable for customers, auditors and procurement.

Testing maps to the OWASP Top 10 and OWASP ASVS, and where you want an adversary framing, findings tie to relevant MITRE ATT&CK techniques so your defenders can trace what detection would have caught.

PCI DSS 4.0 requirement 11.4 calls for regular penetration testing of in-scope applications. ISO 27001, SOC 2, GDPR and DORA all expect demonstrable security testing. The report and attestation letter are written to satisfy these, so a single engagement serves both your security and your audit.

The instance metadata service is the classic pivot. Where an app still allows IMDSv1 or an SSRF can force a request to it, temporary role credentials are one request away. We check whether the metadata is reachable and what those credentials could touch, from S3 buckets to secrets in Parameter Store.

Both expose their own metadata and managed-identity endpoints, and both hand back tokens if an app can be steered into requesting them. We test the same SSRF-to-identity path, then assess what the resulting token opens: storage accounts, key vaults, or service accounts with more scope than anyone intended.

Apps built on functions, containers and managed databases move the risk around rather than removing it. We look at how the application authenticates to those services and whether a compromised request inherits more permission than the feature needs.