Cybersecurity
Cloud penetration testing
A configuration review finds risky settings. A cloud penetration test tries to use them. We start from a defined foothold and see whether permissions, trust and exposed services lead to data or control.
The problem this service solves
In the cloud, access is mostly identity. A role, a service principal or a token decides what an attacker can do, and the paths between them are rarely drawn anywhere. A developer role that can pass another role, a storage bucket policy that trusts an entire account, or a build pipeline holding administrator credentials can each turn a small foothold into control.
We map those paths and test them within the scope you authorize, taking provider testing policies into account.
What is in scope
-
Starting positions
Compromised web workload, leaked access key, low-privilege user, third-party integration, or compromised CI job.
-
Identity and permissions
Privilege escalation through roles, policies, managed identities, service principals and trust relationships.
-
Data stores
Storage buckets, databases, snapshots, key management and secret stores reachable from the foothold.
-
Network exposure
Public endpoints, security groups, peering paths and metadata service access.
-
Compute and containers
Instance metadata, container escape paths, serverless function permissions and image contents.
-
Pipelines and secrets
CI/CD runners, infrastructure-as-code state files, repository secrets and deployment roles.
-
Logging and detection
Whether the actions we took were logged and visible, and whether logging could be disabled.
How the work runs
Define
Agree starting points and limits.
-
1
Scope and policy check
Confirm accounts and subscriptions, and review the cloud provider’s current testing policy for the services involved.
-
2
Foothold selection
Pick realistic starting positions: what an attacker is most likely to obtain.
Test
Follow the identity graph.
-
3
Permission enumeration
Collect effective permissions and build a graph of role assumptions and trust.
-
4
Escalation and lateral movement
Test the paths from the graph, from foothold toward sensitive data or administrative control.
-
5
Impact demonstration
Show minimal proof of access without extracting or altering sensitive data.
Report
Connect findings to fixes.
-
6
Attack path diagrams
Show each path from the foothold, with the permissions and trust that made it possible.
-
7
Detection review
List which actions appeared in logs and which would have triggered alerts.
-
8
Retest
Verify the paths are closed, and that closing one did not open another.
What you receive
- Executive summary
- Attack path diagrams with the permissions involved
- Findings with evidence, by provider and account
- Prioritized remediation guidance, including least-privilege policy suggestions
- Logging and detection observations
- Retest results
Tooling and technique
Tool categories describe how we work. They are not a claim of vendor partnership or certification.
Standards we map to
Mapping findings to a framework is not the same as certification against it.
Before we start
What we need from you
- A list of accounts, subscriptions or projects in scope
- A read-only audit role for a configuration pass, where appropriate
- Starting credentials or a test workload for the chosen foothold
- Contacts who can respond if testing triggers alerts
What this service is not
- A compliance audit
- A denial-of-service test against provider services
- Testing of the provider’s own infrastructure
What changes afterwards
- You can see the privilege paths in your cloud and which ones are real
- Permissions are reduced where they enable escalation
- Logging gaps are known and ready for detection work
Questions people ask
Do cloud providers need to approve the test?
The major providers allow testing of your own resources under published policies, with some activities restricted. We check the current policy for each service in scope.
How does this differ from a CSPM tool?
A posture tool continuously flags risky settings. A penetration test checks whether those settings, together with identity relationships, can be chained to reach something that matters. They complement each other.
Can you test Kubernetes clusters?
Yes, as part of a cloud test or as a separate engagement. See our Kubernetes security service.
Related
-
AWS security
Review of IAM, organizations, networking, storage, logging and workloads in AWS, with a fix plan ordered by what attackers use first.
-
Azure security
Assessment of Azure subscriptions, Entra ID integration, RBAC, networking, Defender for Cloud, Key Vault and logging.
-
Google Cloud security
Review of resource hierarchy, IAM, service accounts, VPC Service Controls, storage, GKE and logging in Google Cloud.
-
Kubernetes security
Assess cluster configuration, RBAC, admission control, network policy, secrets, images and runtime for EKS, AKS, GKE and self-managed clusters.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response