Cloud penetration testing from a single foothold
GreySurface cloud penetration testing starts from one realistic foothold, such as a leaked key, and follows how far it reaches through identity, storage and network.
What does a cloud penetration test cover?
The path an attacker walks once inside. We test which roles one identity can assume, which storage answers the internet, which networks reach each other and which secrets sit in pipelines.
Identity and access
Roles and policies that let one identity become a stronger one.
For example, assume-role: *Exposed storage
Buckets, queues and databases that answer anyone on the internet.
For example, exports bucketSee the sample findingNetwork reachability
Whether test, staging and production can reach each other at all.
For example, 10.0.0.0/8 openSecrets in pipelines
Keys and tokens left in code, pipelines and build logs.
For example, ci env: CLOUD_KEYLogging and detection
Whether risky actions are logged and whether any alert fires.
For example, audit log: offWorkload permissions
Functions and containers that run with far more access than they need.
For example, task-role: *Account guardrails
Account-wide settings such as root access, MFA and public sharing.
For example, root mfa: off
What we need from you
- The accounts in scope
- One agreed starting foothold
- A named contact for the window
On live systems
Live systems by default, inside agreed windows, with a named contact and no destructive actions.
Four steps from one agreed foothold
We agree the accounts and the one foothold we start from, then map what that identity can touch. Each step is taken by hand, with a named contact and no destructive actions.
Agree the foothold
What the tester does
We agree the one realistic way in that the test starts from.
What you learn
Where a leaked key would put an attacker before anything else.
Map the reach
What the tester does
We map what that identity can assume, read and reach today.
What you learn
Every role, bucket and network that identity can touch now.
Climb by hand
What the tester does
We take each step on the path by hand, inside the agreed window.
What you learn
The exact chain from the foothold to the data at the end.
Name the break
What the tester does
Each finding names the setting that cuts the path in one place.
What you learn
The one change that closes the whole route at a single point.
A tester leads every step. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.
Three attack paths inside one cloud account
Each sample ends somewhere different: a stronger role, a public store of customer data, and a network that trusts whatever sits inside it.
- Sample
A leaked key climbs to admin
A leaked key assumes a deployment role, and that role assumes another. The chain ends at full admin.
- Sample
Customer exports open to anyone
Nightly customer exports sit in a public bucket. Anyone with its address downloads them, unseen.
- Sample
One box reaches the whole network
A tricked web server hands over its role credentials. The flat network takes them on to production.
How far can one leaked key or role reach?
We take a single foothold and follow it, assuming stronger roles and reaching into storage and networks, until the scope ends or the path does.
Customer exports readable by anyone on the internet
Whereexports.acme-corp.com
Request from outside, signed out
$ curl exports.acme-corp.com
Response, no credentials asked
HTTP/1.1 200 OK customer-export.csv customer-export-old.csv
- Business risk
- Anyone who finds the storage address can download customer export files.
- Fix
- Block public access on the bucket and require signed, expiring links.
Removed: block_public_access = false
Added: block_public_access = true
Checked by a tester before it reached the report.
The one change that cuts each attack path
Each finding names the role, policy or setting that lets the path continue, and the one change that cuts it. A short list of fixes closes the whole route.
Report
Findings, proof and fixes
Fix guidance
The role, policy or setting that closes the path
Executive briefing
How far one foothold reached
One retest within 30 days of the report
Bucket now private
Built for products that run in cloud accounts
Teams whose product lives in a cloud account, where one leaked key or an over-trusting role could open customer data to the internet.
Cloud-native products
Products built on managed services, where identity is the real perimeter.
Fast-moving teams
Teams shipping infrastructure as code, where a default can drift open.
Data-heavy platforms
Platforms holding customer data in buckets and databases worth reaching.
When to book it
- Before a cloud launchYou are putting a new product or account into production.
- After an IAM changeA new role, policy or trust change moves who can reach what.
- When a key leaksA secret turned up where it should not, and you need its blast radius.
- For a security reviewA customer or auditor asks for an independent cloud test.
Aligned with NIST and MITRE for cloud accounts
NIST SP 800-115
Technical guide to security testing and assessment
MITRE ATT&CK
Adversary tactics and techniques
CWE Top 25
The most dangerous software weaknesses
Aligned with, never certified by. Names belong to their owners; no endorsement implied.
Scoping a cloud penetration test
We reply to every quote request within one business day, from info@greysurface.com.
Where does a cloud test start?
From one realistic foothold you agree, such as a leaked key or a low-privilege role, and we follow it as far as your scope allows.
Do you test live cloud accounts?
Yes, by default. We test inside an agreed window, with a named contact and no destructive actions on your account or data.
What access do you need to the account?
The starting foothold we agree, such as a low-privilege role or a leaked key. We ask for no more than the attacker you are modelling would have.
What do you need from us to start?
The accounts in scope and a named contact for the window. Tell us the providers if you know them, and we agree the foothold together.
What does the report show for each finding?
The role, policy or setting that let the path continue, with proof of exploit, the business risk and the change that cuts it. Leadership receives an executive briefing.
Is a retest included?
Yes. One retest of the findings we reported is included, within 30 days of the report, so you can confirm each fix closed the path.