Contact
Phone & 24/7 emergency hotline+49 2932 465265-0 Emailinfo@rootsektor.deMon–Fri 8:00 a.m.–5:00 p.m. CET/CEST · outside business hours: 24/7 emergency hotline
Request a pentest quote Report an emergencyPenetration Testing
Spot attack paths before attackers use them.
In the cloud, a security incident rarely comes down to a single flaw – usually it’s the combination of overly broad permissions, exposed services, and forgotten resources. With cloud penetration testing, we assess your environment in AWS, Microsoft Azure, or Google Cloud from an attacker’s perspective and show which attack paths are actually exploitable.
Definition
Cloud penetration testing is an authorized, controlled attack on your cloud environment. We examine accounts, subscriptions, and projects, identities and roles, storage, workloads, networks, and management interfaces – and answer the question that matters for your risk: How far can an attacker get once they find a realistic entry point? That could be an accidentally published access key, a compromised developer account, or a vulnerable web application.
Every cloud pentest starts from the shared responsibility model: AWS, Microsoft, and Google secure their data centers, hardware, and virtualization layer. You are responsible for everything you configure in the cloud yourself – identities, permissions, network rules, data, and applications. That’s exactly where the vulnerabilities arise that attackers exploit in practice.
A cloud pentest differs from a configuration review in its approach. A review systematically compares settings against best practices such as the CIS Benchmarks; a penetration test shows whether and how individual weaknesses can be exploited and chained into an attack path. The two complement each other – for pure configuration analysis, we offer our Microsoft 365 & Azure Review and our AWS Security Review.
The results help you take targeted steps to harden your cloud environment and provide solid evidence for requirements such as Art. 32 GDPR, risk management under NIS2, DORA, or ISO/IEC 27001:2022 – clearly presented for your management and with hard technical details for your cloud team.
Our approach
We combine two perspectives. From the outside, we test what is reachable from the internet: public endpoints, storage, APIs, login pages, and management access. From the inside, we assume a compromised account (“assumed breach”) and analyze how privileges can be expanded from there – via roles, trust relationships, and service accounts into other accounts, subscriptions, or projects.
Tools such as Prowler, ScoutSuite, Pacu, or BloodHound speed up the analysis of large environments. But it’s the manual work that makes the difference: we verify potential attack paths hands-on, back them up with evidence, and separate exploitable vulnerabilities from purely theoretical findings.
Throughout, we comply with the providers’ testing policies. For most tests on AWS, Azure, and Google Cloud, no prior approval is required. Denial-of-service tests are not part of our standard scope, and the providers’ own infrastructure as well as other customers’ resources are always off-limits.
Common vulnerabilities
Policies that allow all actions via wildcards, service accounts with owner rights, or applications with far-reaching Microsoft Graph permissions. Even inconspicuous combinations such as iam:PassRole plus the right to create Lambda functions often enable full privilege escalation.
S3 buckets, Azure Blob containers, or Cloud Storage buckets with anonymous access, overly permissive SAS tokens, and publicly shared snapshots and backups expose data – often unnoticed.
SSH, RDP, databases, the Kubernetes API, or admin interfaces that are reachable from the entire internet via a security group or network security group give attackers a direct way in.
Access keys and passwords sit in code repositories, CI/CD variables, function environment variables, container images, or Terraform state files – readable by anyone who gains access there.
A server-side request forgery in a web application is enough to grab temporary credentials of the instance role via the metadata service – which is especially easy if IMDSv1 is still enabled on AWS.
Privileged pods, overly broad RBAC roles, automatically mounted service account tokens, and missing network policies enable a container escape all the way to a full cluster takeover.
Flat VPC or VNet structures, generous peering, VPN connections to your own data center, and synchronization services such as Microsoft Entra Connect link cloud and on-premises environments – for attackers, too.
If CloudTrail, the Azure activity log, or Cloud Audit Logs are incompletely configured, or if no one reviews the alerts, attacks go undetected for a long time.
Testing perspectives
Which perspective makes sense depends on your goal – for an AWS pentest just as for an Azure pentest or a test in Google Cloud. We advise you during scoping and combine the approaches as needed.
Black box
We start without credentials or prior knowledge – like an attacker on the internet.
Gray box
We receive an identity with typical privileges and test how far access can be expanded.
White box
With read access to the entire environment and your IaC definitions, we also uncover hidden paths.
Process
From the first alignment to the test certificate – transparent, in close collaboration with your cloud team, and following our proven approach to penetration testing.
We clarify providers, accounts, subscriptions or projects, relevant services, testing perspective, and objectives – for example: “Can an attacker get from the web application to the customer data?”
Within 24 hours of scoping (on business days), you receive a fixed-price quote with no hidden costs.
You set up test identities with the agreed privileges. Together, we define time windows, contacts, and abort criteria and check the test plan against the providers’ policies.
We catalog the reachable resources, analyze permissions and configurations, and identify potential attack paths.
We verify the paths hands-on – from privilege escalation to access to agreed target objects – in a controlled manner and fully documented.
You receive the report, a debrief on request, and a test certificate. We retest fixed vulnerabilities free of charge.
Reporting
Our report addresses two audiences: the executive summary puts the results into a business context and shows where action is needed. The technical section gives your cloud team everything it needs for remediation – affected resources, traceable evidence, and concrete measures, right down to the adjusted policy.
Tell us about your architecture and your goals. We’ll propose a suitable scope and send you a fixed-price quote within 24 hours of scoping (on business days).
FAQ
Didn’t find your question? Call us at +49 2932 465265-0 or email info@rootsektor.de.
Not for most tests. AWS, Microsoft Azure, and Google Cloud generally allow penetration testing of your own resources without prior notification, but they set rules – for example, on denial-of-service tests or the provider’s infrastructure. We align the test plan with these policies. You grant us authorization for your accounts in writing.
A configuration review checks your settings systematically and broadly against best practices. A penetration test goes deep: it shows which weaknesses can actually be exploited and chained into an attack. For a pure configuration check, we recommend our Microsoft 365 & Azure Review or our AWS Security Review – many companies combine both.
Typical occasions include a migration to the cloud, the go-live of a new platform, major architecture changes, new accounts or subscriptions, and requirements from customers, auditors, or insurers. Because cloud environments change constantly, we also recommend repeating the test regularly – at least once a year.
That depends on the testing perspective. For an external test, it’s enough to specify the target systems. For gray-box and white-box tests, read-only roles are usually sufficient – such as SecurityAudit on AWS, Reader and Global Reader in Azure or Entra ID, or Viewer in Google Cloud – supplemented by a test identity with typical privileges. We recommend time-limited access that is removed again after the test.
The risk is low: load and denial-of-service tests aren’t part of the standard scope, and we agree on time windows and abort criteria in advance. Actions that could change data or configurations are only performed after explicit agreement. On request, we test in a staging environment that mirrors production.
Yes – as technical evidence. The report and test certificate show that you have the effectiveness of your security measures reviewed, as required by Art. 32 GDPR, NIS2, or ISO/IEC 27001, for example. However, a penetration test replaces neither an audit nor an attestation.
The effort depends mainly on the number of accounts and subscriptions, the services in use, the testing perspective, and the depth of testing you need. After scoping, you receive a fixed-price quote within 24 hours (on business days) – with no additional charges for the agreed scope.
We use access exclusively for the agreed test and treat results and documents as strictly confidential. On request, we sign a non-disclosure agreement before scoping.
Briefly describe your environment – providers, number of accounts or subscriptions, and your most important goals. We’ll get back to you to arrange a no-obligation initial consultation.
Diese Seite gibt es auch auf Deutsch.