Penetration testing of
cloud environments
In the cloud you rarely break in through a software vulnerability. One role with excessive permissions, one public storage bucket and one token leaked from a build pipeline are usually enough. We review AWS, Azure and Google Cloud configuration and how far access to a single resource can take an attacker.
- AWS, Azure and Google Cloud, plus Kubernetes clusters
- IAM privilege escalation paths, not just a list of configuration gaps
- Verification of whether your logging notices our activity at all
Cloud environments
- CIS Benchmarks for AWS, Azure, GCP and Kubernetes
- MITRE ATT&CK for Cloud
- OWASP Kubernetes Top 10
- PTES
What exactly we check
We tailor the scope to your environment, but these areas are always covered.
Identities and permissions (IAM)
Roles and policies broader than needed, long-lived keys instead of temporary credentials, accounts without a second factor, privilege escalation paths within and across accounts.
Data and storage
Public and over-shared S3, Blob and GCS buckets, encryption of data and keys, access to databases and snapshots, backups and their retention rules.
Network and exposure
Security group rules open to the whole internet, public addresses where a private link would do, edge service configuration, administrative access to virtual machines.
Containers and Kubernetes
RBAC permissions, pod service accounts, privileged containers and pod escape to the node, secrets in environment variables, image vulnerabilities and provenance.
Serverless and CI/CD
Function permissions and environment variables holding secrets, pipeline permissions and the ability to inject a step into the build process, trust in external dependencies and registries.
Logging and detection
Completeness of CloudTrail and its equivalents, protection against log deletion, detection service configuration, and which of our actions actually raised an alert.
What we find most often
Examples from our projects in this area. Client names and technical details stay in the reports.
- A full-privilege policy attached to a role with a single narrow task
- An S3 bucket with customer documents publicly readable
- An access key in a pipeline environment variable, visible in build logs
- An escalation path: permission to edit a policy leading to an administrator role
- A database with a public address and a security group open to the world
- A Kubernetes service account able to read every secret in the cluster
- Event logging disabled in some regions and subscriptions
- Disk snapshots shared outside the organisation
Selected tools
Tools take care of the repetitive work. The conclusions and attack chains are built by hand.
How the test runs and what you get
The testing process, the report format and the retest rules are the same across every scope.
See the full process and report contentsFrequently asked questions
Does the cloud provider have to be notified?
For a standard scope usually not, since AWS, Azure and Google allow testing of your own resources within their rules. We keep track of those rules for you and flag any part of the scope that needs prior notification.
What access do you need?
A read-only auditor account is enough for the configuration review. For escalation paths it also helps to have an account with typical user permissions, so we can see the environment through their eyes.
Is this the same as a compliance audit?
No. An audit checks conformance against a list of requirements. We look for working attack paths and demonstrate the impact. They work best together, since many of our findings directly support certification work.
Do you test hybrid environments?
Yes, and the interesting part is usually the seam: a cloud account that reaches the on-premise network, or a domain stretched across both. We combine that scope with internal infrastructure testing.
Other testing scopes
We combine scopes into a single project whenever that works better for your environment.
Web applications and APIs
We detect vulnerabilities from the OWASP Top 10 (including SQL Injection, XSS, SSRF, BOLA). We audit customer portals, e-commerce systems, CRMs and complex environments based on microservices and APIs (REST, GraphQL).
View scopeMobile applications
Reverse engineering of iOS and Android applications (including Flutter and React Native). We verify secure on-device data storage, correct server communication and flaws in authorization logic.
View scopeInternal infrastructure
We simulate an attack, for example from the perspective of a malicious employee or a compromised workstation. We examine network segmentation (VLAN), Active Directory, file servers and password policies.
View scopeExternal infrastructure
We attack internet-facing systems and services. We verify firewall configurations, VPN server vulnerabilities, outdated software versions and DNS misconfigurations.
View scopeWireless networks
We analyze the security of corporate Wi-Fi networks, guest network isolation, susceptibility to password interception, Evil Twin attacks and Rogue Access Points.
View scope