VAPT

VAPT of Cloud Platforms

Cloud environments are rarely breached through a flaw in the provider. They are breached through an identity with more permission than anyone realised, a storage object made public during a migration, or a workload role that a compromised container can assume. The assessment therefore treats identity as the perimeter, because in cloud it is.

Methodology

01
Inventory and exposure mapping
Every account, subscription or project enumerated, with all internet-reachable resources identified — load balancers, storage, functions, databases and management endpoints.
02
Identity and access review
Every principal, role, policy and trust relationship collected. Effective permissions are computed rather than read, because a policy document rarely states what a principal can actually do.
03
Privilege escalation path analysis
Known escalation primitives tested against the environment's actual policy set: pass-role, policy-version, function creation, and their equivalents on each platform.
04
Data exposure assessment
Storage buckets, blobs, snapshots, images and backups checked for public access, over-broad grants and sensitive content in places nobody intended to publish.
05
Workload and network assessment
Compute, container and serverless configuration; security groups and network rules; metadata service version and reachability from workloads.
06
Logging and detection review
Whether CloudTrail, Azure Activity or Cloud Audit Logs are enabled everywhere, retained, protected from deletion, and actually monitored.
07
Exploitation
Confirmed escalation paths demonstrated within an agreed blast radius, so the finding is a proven path rather than a theoretical one.
08
Reporting and retest
Technical report and executive summary together, then a retest evidencing closure.

Approach to testing

Read-only assessment role by default, with exploitation of specific paths agreed separately in writing. A cloud environment is production and an unbounded test is an outage.
Effective permissions are computed, not read. Inherited policies, permission boundaries, SCPs and resource policies interact in ways that make the written policy a poor guide.
Multi-account and multi-subscription structures are assessed as one estate, because the escalation path usually crosses the boundary the org chart assumes is solid.
The assessment covers what the client configured, not the provider's own platform. Testing the provider is prohibited by their terms and finds nothing useful.
Infrastructure as code is reviewed where available, because fixing the console leaves the next deployment to reintroduce the finding.

Types of assessment

Configuration and identity review (default)

Read-only assessment across the estate. The highest yield per unit of effort and the safest for production.

Privilege escalation assessment

Starts from a low-privileged principal and attempts to reach administrative access, demonstrating real paths rather than listing risky permissions.

External attack surface test

From the internet with no credentials, against everything the estate exposes. Answers what an attacker sees before any access.

Breach simulation

Starts from a compromised workload — a container or instance — and tests what its role can reach. The most realistic model of a modern cloud incident.

Frameworks and standards

CIS Benchmarks for AWS / Azure / GCP: The configuration baseline the environment is scored against.
AWS Well-Architected Security Pillar: Design-level reference where the engagement covers architecture, not only configuration.
Microsoft Cloud Security Benchmark: Azure equivalent, mapped to CIS and NIST controls.
MITRE ATT&CK for Cloud: Technique mapping for the detection team.
NIST SP 800-53 / 800-171: Where the client has a compliance obligation requiring control mapping.
CWE / CVSS v3.1: Classification and severity for findings that are vulnerabilities rather than configuration.

Tools used

Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.

ScoutSuite

Multi-cloud configuration assessment and baseline reporting.

Prowler

AWS CIS benchmark checks and compliance mapping.

Pacu

AWS exploitation framework for demonstrating confirmed escalation paths.

PMapper / Cloudsplaining

Computing effective IAM permissions and identifying escalation primitives.

ROADrecon / AzureHound

Entra ID and Azure resource enumeration and path analysis.

Trivy / Checkov

Container image and infrastructure-as-code scanning.

Cloud provider CLIs

Direct enumeration and verification, because tool output is always confirmed against the source.

Checklist approach

The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.

Identity and access

Root and global administrator account usage and MFA
Over-permissive policies, including wildcards on action or resource
Unused principals, keys and roles still enabled
Cross-account and cross-tenant trust relationships
Permission boundaries and service control policies
Federation and identity provider configuration

Privilege escalation

Pass-role and service-role assumption paths
Policy version and attachment rights
Function and workflow creation as an escalation primitive
Instance profile and managed identity reach
Secrets readable by principals that should not have them

Data exposure

Public storage buckets, blobs and containers
Snapshots and machine images shared publicly or cross-account
Database instances reachable from the internet
Encryption at rest and key management
Backup access controls and retention

Network and workload

Security group and NSG rules permitting broad ingress
Management ports exposed to the internet
Metadata service version and workload reachability
Container escape and privileged pod configuration
Serverless function permissions and environment secrets

Logging and detection

Audit logging enabled in every region and account
Log retention, immutability and deletion protection
Alerting on privileged actions and policy changes
Guard rails: config rules, policy enforcement, drift detection

How findings are scored

Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.

Critical: Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
High: Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
Medium: Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
Low: Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
Informational: A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.

Scan types selected

Safe Checks
Standard / OWASP Top 10
Destructive
SANS Top 25
Business Logic Vulnerability Testing

Standard toolset by stage

OSINT: Datasploit, Google Dorks, Shodan
Enumeration & Scanning: Nmap, Wfuzz, Unicornscan
Domain Enumeration: Nikto, DnsRecon, Knock
Crawling & Fuzzing: Burp Suite, Acunetix, Netsparker
Vulnerability Analysis: OpenSSL, sqlmap, CVE-Details
Exploitation: Metasploit, Netcat, Exploit-DB

Free toolkit

Penetration Testing Checklists

Sixteen assessment checklists covering the targets we test: web applications, Android, iOS, APIs, networks, Active Directory, thick clients, WiFi, SCADA and ATMs — plus red team test cases, firewall audit, malware analysis and vendor security assessment.

16 checklists · ZIP · 775 KB

Download the toolkit

Deliverables

Technical assessment report (PDF)
Executive summary (PDF, one page)
Finding register (spreadsheet) mapped to CIS controls
Effective permission analysis for privileged principals
Infrastructure-as-code remediation snippets
Remediation walkthrough with the platform team
Retest report evidencing closure

Frequency

One-time: A first assessment, a migration gate, or a customer or regulatory requirement against a named environment.
Quarterly: Estates under active development, multi-account structures, or where a previous assessment found systemic identity issues.
Biannually: Stable estates with strong change control and continuous configuration monitoring already in place.
Continuous: Configuration monitoring running permanently against the benchmark, with a full assessment annually or biannually on top.

Resource deployment

Cloud assessment runs remotely by default — the estate is reachable from anywhere by design, and an on-site tester has no advantage. On-site deployment is available where the client requires the assessment role to be used only from within their network, where a regulator requires the work to be witnessed, or during remediation where sitting with the platform team is faster than asynchronous review. A typical on-site component is two to three days during remediation rather than during assessment.

How CSS tests

A unified swarm of agents, for blind spot detection

AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.

Effective permission computation across thousands of principals and policies is combinatorial. A tester spot-checks the roles that look risky; agents compute the full effective set, and the dangerous role is usually one nobody flagged.
Multi-account estates hide escalation paths that cross account boundaries — each account looks fine in isolation and the path only exists in the join.
Public exposure drifts continuously. Enumerating every storage object and snapshot across every region is machine work that a manual assessment samples.
Escalation primitives have known preconditions; checking every principal against every primitive is enumeration rather than insight.

Every agent finding is validated by a human tester, and nothing is exploited without explicit written authorisation and an agreed blast radius. The swarm decides what to look at; it does not act on a production estate.

Why this differs

What CSS does that most vendors do not

Every one of these is checkable. Ask any vendor for the same and compare the answers.

Effective permissions, not policy documents

Most cloud reviews read policies and flag wildcards. CSS computes what each principal can actually do once inheritance, boundaries and resource policies are resolved, which is a different and much shorter list of real problems.

Exploited, not scanned

Escalation paths are demonstrated within an agreed blast radius, so the client sees a proven path rather than a tool's risk score.

Both reports, always

Technical report and executive summary together, written for two audiences.

Fixed in code, not in the console

Remediation is worked into the infrastructure-as-code that produced the environment. A console fix is undone by the next deployment.

Reporting

Two documents, two audiences

Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.

Technical assessment report

For the engineers who will fix it

Disclaimer, and Limitations on Disclosure and Use
Risk Level & Description — the five levels above, scored on CVSS 3.1
Scan Type — which of the five assessment types were selected
Assessment Scope — the control areas covered
Assessment Date — the exact testing window
Objective of the Assessment — objectives listed against completion status
Tools Utilization — manual and automated tooling by stage
Summary of the Assessment
Overall Recommendations, split into Must Have and Should Have
Vulnerability Overall Classifications as per Organization
Security Issues Highlighted
The Key Findings — each with evidence and detailed recommendation
Summary of Findings & Conclusion

For this assessment specifically

Scope: accounts, subscriptions, projects, regions and the assessment role used
Every finding with CIS benchmark reference and CVSS where applicable
Demonstrated escalation paths with the exact API calls involved
Evidence: CLI output, policy excerpts, screenshots
Effective permission analysis for privileged and anomalous principals
MITRE ATT&CK for Cloud technique mapping
Infrastructure-as-code remediation examples, not console instructions
Retest results appended against each original finding

Executive summary

For the people who will fund the fix

Objectives, each against a completion status
Overall Finding of the Assessment — total threats identified, broken down by component and severity
Summary of the Assessment
Artefacts of the Assessment — the key findings as a numbered register with severity
Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
Overall Recommendation, including a Business Enabling Recommendation sequence
Must Have and Should Have actions

For this assessment specifically

What is exposed to the internet, and what an attacker with one compromised principal could reach
Severity distribution and movement since the previous assessment
The three changes that most reduce blast radius
Compliance position against the applicable benchmark, as a percentage with the gaps named
Remediation timeline and retest date
One page

Case studies

What this finds in practice

Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.

A fintech running roughly 40 AWS accounts under an organisation.

Finding: A CI/CD role in the shared services account could assume a deployment role in every other account, including production. The CI system itself authenticated with a long-lived access key stored in a repository variable, so anyone with repository write access effectively held production administrator.
Recommendation: Replace the static key with OIDC federation, scope the deployment role per account and per environment, and add a permission boundary preventing the CI role from modifying IAM.
Outcome: OIDC federation implemented across all accounts within a month. The permission boundary subsequently blocked a misconfigured pipeline from granting itself additional rights.

A media company migrating from on-premises to Azure.

Finding: Storage containers created during migration were set to allow anonymous blob access to simplify the transfer and never changed. Around 90,000 files, including contracts and unreleased content, were readable by anyone with the URL pattern.
Recommendation: Disable anonymous access at the storage account level so it cannot be re-enabled per container, and add an Azure Policy denying public containers estate-wide.
Outcome: Access disabled within hours. The policy is now applied at management group level, which prevents recurrence in any new subscription.

A SaaS provider running workloads on Google Kubernetes Engine.

Finding: Pods ran with a node service account that held broad project-level permissions. A container escape or an application vulnerability in any pod would have granted access to every storage bucket and secret in the project.
Recommendation: Move to Workload Identity with per-workload service accounts scoped to only what each needs, and remove project-level grants from the node account.
Outcome: Workload Identity rolled out over two sprints. The breach simulation was re-run and the compromised pod reached only its own bucket.

Scope this assessment

Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.

Start a conversation All VAPT capabilities