Most cloud incidents are not exotic. They are an over-permissive role, a storage bucket that trusts the network it sits in, a token that was never rotated, or an application flaw that becomes an account compromise because the workload it runs as can do far more than the application needs.

We test the cloud the way an attacker reaches it: through the application. A finding only matters when it can be chained, so the question we answer is not “is this configuration ideal” but “starting from the outside, or from one ordinary user account, how far into your cloud can somebody get?”

Who this is for

  • Your application runs on AWS, Azure or GCP and nobody has tested the path from the application into the account behind it.
  • A customer, auditor or insurer has asked for a cloud security assessment and a configuration scan report is not going to satisfy them.
  • You have grown from one account to many — environments, sub-accounts, cross-account roles, third-party integrations — and the trust between them has never been examined.
  • Your build pipeline can deploy to production, and you want to know what an attacker who reaches it could do.

What we test

Identity, roles and privilege escalation

The part that decides how bad everything else gets. We map what each workload and each human identity can actually do, then look for the paths between them: roles that can be assumed by more principals than intended, policies that grant iam:PassRole or its equivalents, trust relationships that accept a wider audience than they should, and service accounts that have accumulated permissions nobody has ever removed.

The application, and what it runs as

An SSRF in a web application is a moderate finding on a server and a critical one in a cloud account, because it reaches the instance metadata service and returns credentials. Server-side request forgery, file upload handling, template injection and deserialisation are tested here for that reason — the exploitability changes with the environment. The application-layer catalogue applies in full.

Storage and data exposure

Object storage, databases, backups, snapshots, queues and logs: who can read them, who can write to them, whether public access is genuinely blocked rather than merely discouraged, whether pre-signed URLs expire and are scoped, and whether encryption keys are reachable by the identities that read the data.

Network and service boundaries

Security groups, firewall rules, private endpoints and peering. What is reachable from the internet, what is reachable from a compromised workload, and whether the internal network is treated as trusted — because it usually is.

Secrets, CI/CD and the supply chain

Where credentials live and how they are handed to workloads: secret managers, environment variables, build variables, repository files and container images. Build pipelines get direct attention — a pipeline that can deploy to production is production access, and it is frequently the least-protected way in.

Logging, detection and response

We record what we did and when, so you can check what your monitoring saw. An engagement that produces findings and no detection gaps has only told you half the story.

How the engagement runs

  1. Scoping. Which accounts, which environments, which applications, and what is explicitly out of bounds. You get a fixed scope, timeline and price.
  2. Access. A read-only audit identity for the configuration review, plus application credentials for every role. The two halves answer different questions and we run both.
  3. Testing. Hands-on-keyboard work against the application and the account, chaining findings to demonstrate real impact rather than listing settings.
  4. Report. Every finding with the exact reproduction, the identity it was performed as, the blast radius, and a fix a platform engineer can act on.
  5. Retest. Included, as on every engagement.

What you get

  • A report that separates what is exploitable now from what is merely misconfigured — the distinction that decides what gets fixed this week.
  • Attack paths drawn end to end, from the entry point to the account impact, so the severity argues for itself.
  • Remediation written for the people who own the infrastructure, not generic benchmark text.
  • A retest after you have fixed, included.

The test cases behind this service

A cloud assessment has two halves. The account layer — identity, roles, storage, network and the build pipeline — is described on this page and is not part of the published catalogue. The application layer is, and these are the categories that carry it — including the ones whose severity changes entirely in a cloud account, such as server-side request forgery reaching an instance metadata service.

64 test cases across 6 categories.

The full catalogue is at Attacks & Tests, and the coverage matrix shows which published standards these map onto. How much access the testers are given is a separate question — see testing modes.

Talk to us about testing your cloud environment

Tell us what runs where and what worries you about it. We will come back with scoping questions, a clear proposal and a realistic timeline — and if a cloud test is not what you need yet, we will say so. Get in touch.

See also: web application testing · API penetration testing · SaaS and multi-tenant testing · the full test catalogue.