Pentest Cloud
One over-permissive IAM role or an open bucket is enough to compromise your whole cloud.
We test your AWS, Azure and GCP environments both from the outside and with authenticated access. The goal is to measure what an attacker can reach from an exposed key, a misconfiguration or a poorly scoped role, then to prioritise the fixes. The review covers IAM, storage, networking and your container clusters.
France Cybersecurity Label Cloud attack surface
The cloud shifts the risk towards configuration
On AWS, Azure or GCP, most breaches come not from a provider flaw but from the way you configure your accounts: over-broad IAM roles, access keys left in a code repository, publicly reachable storage buckets and containers, security groups open to the internet, missing logging. The dynamic nature of these environments (infrastructure as code, multiple accounts, continuous deployment) multiplies the opportunities for error. Our test combines an external approach with an authenticated configuration review to reconstruct the privilege-escalation paths that are genuinely exploitable.
What we test
Four families covered across AWS, Azure and GCP
Identity and access (IAM)
Review of roles, policies and keys: over-broad permissions, privilege-escalation paths, over-privileged service accounts and access keys exposed in code or environment variables.
Misconfigurations
Exposed storage (S3 buckets, Blob Storage), plaintext secrets, security groups and networks open to the internet, missing encryption and logging too limited for detection.
Containers and orchestration
Docker images, Kubernetes configuration (RBAC, privileged pods, host mounts, secret handling) and container-escape risks towards the cluster control plane.
Network segmentation and benchmarks
VPC segmentation, exposure of internal services and configuration compared against the relevant provider's CIS Benchmarks to measure the gaps.
Frequently asked questions
What to know about a cloud pentest
How does a cloud pentest differ from an automated configuration scan?
A scanning tool (CSPM) flags isolated configuration gaps but does not chain them. Our test links those gaps into concrete attack paths: for example, an exposed key leading to an IAM role that is itself allowed to read a secrets bucket, which opens access to another account. We confirm each finding through controlled exploitation and discard false positives.
What access do you need for the configuration review?
For the authenticated part, a read-only role over the relevant scope (for example SecurityAudit on AWS, Reader on Azure, a Viewer role on GCP) is enough to inspect IAM, storage and networking without altering your environment. The external phase requires no access. The exact scope (accounts, subscriptions, projects, clusters) is set during scoping.
Does the test need to be declared to the cloud provider?
Most tests against your own resources are now allowed without prior declaration, but some operations remain governed by the provider's rules of engagement (AWS, Azure, GCP), denial-of-service testing in particular. We check those rules and prepare any required declarations during the scoping phase.
Other domains
Explore our other penetration tests
Pentest Web
Your web apps and APIs carry business logic that an automated scanner cannot probe.
Pentest Mobile
Find the flaws in your iOS and Android app before an attacker exploits them.
Pentest IoT
Before you ship, find out what an attacker can do with your connected device.
Pentest LLM
Your LLM applications open an attack surface that your usual tests do not cover.
Penetration testing overviewWhat is your cloud's real exposure?
Tell us about your environment (provider, accounts, scope) and we will send you a tailored quote within 48h.