What access do you need?

A read-only role scoped to the accounts in question is enough for the configuration review, and a low-privileged principal is useful for testing escalation paths from a realistic starting position. Full administrative access is not required and is not asked for.

Do we need to tell AWS?

For most testing against your own resources, no notification is required under current policy, but the specific activities are checked against the provider's rules before anything runs and anything requiring authorisation is raised with you first.

The named service is AWS because that is where the depth is. The identity-graph approach transfers to other providers and the same work can be scoped there, with the caveat that provider-specific escalation paths differ and are researched per engagement.

Service

Cloud Penetration Testing (AWS)

Identity, storage and workload misconfiguration review across your cloud estate.

Cloud compromise is rarely a vulnerability in the provider. It is identity: a role broader than the workload needed, a trust policy that accepts more than it should, a set of credentials reachable from an application that was only supposed to fetch a URL. The work follows privilege paths the way an attacker does rather than linting policy documents in isolation.

How this works

Identity as the primary surface

Roles, policies and trust relationships are read as a graph rather than a list. The question is not whether a policy is over-permissive on its own but where a chain of individually defensible permissions ends up: which role can assume which, which can pass a role to a service, which can edit the policy that constrains it, and which can read the secret that unlocks the next one.

The instance metadata path

Any application that can be made to fetch a URL is one step from the credentials of the role attached to its compute. Whether IMDSv2 is enforced, whether the hop limit prevents a container reaching the host's metadata service, and what the attached role can do if it is reached, are checked directly rather than assumed from a configuration standard.

Storage and data paths

Bucket and object permissions, including the combinations of policy, ACL and account-level settings that produce public access nobody intended. Snapshots, images and backups are checked as first-class assets, since they are frequently readable when the live resource is not and contain the same data.

Blast radius, stated plainly

For each significant identity the report answers one question directly: if an attacker held these credentials for an hour, what is the worst outcome. That framing turns a policy review into something a team can act on and prioritise.

What we look for

Roles with permissions well beyond what the workload uses, measured against actual API usage where the data exists
Privilege escalation paths through policy editing, role assumption, role passing and function creation
IMDSv1 still reachable, and hop limits that let a container reach the host's metadata service
Storage exposed through the interaction of bucket policy, object ACLs and account settings
Snapshots, images and backups readable more widely than the resources they came from
Long-lived access keys where a short-lived role would do, and keys that have never been rotated
Logging disabled, unretained, or writable by the identities it is supposed to be watching
Cross-account trust relationships that accept more principals than intended

What you get

Privilege paths written out from a starting position to the data at the end of them
Blast radius per significant identity, expressed as what an hour with those credentials reaches
Findings mapped to the specific policy, resource or setting that produces them
Remediation that names the change, not the principle

What this does not include

Testing that violates your provider's acceptable use policy
Denial of service or resource exhaustion testing
Changes to your cloud configuration on your behalf
Cost optimisation, though over-provisioned identities and forgotten resources tend to surface anyway

Questions people ask

What access do you need?: A read-only role scoped to the accounts in question is enough for the configuration review, and a low-privileged principal is useful for testing escalation paths from a realistic starting position. Full administrative access is not required and is not asked for.
Do we need to tell AWS?: For most testing against your own resources, no notification is required under current policy, but the specific activities are checked against the provider's rules before anything runs and anything requiring authorisation is raised with you first.
Only AWS?: The named service is AWS because that is where the depth is. The identity-graph approach transfers to other providers and the same work can be scoped there, with the caveat that provider-specific escalation paths differ and are researched per engagement.

Discuss cloud penetration testing (aws)All services