Advisory

Cloud Penetration Testing for AWS, Azure and Google Cloud

Find the identity, configuration and workload weaknesses that let an attacker move through your cloud, tested by hand by a CREST-accredited team.

Cloud penetration testing in Australia for AWS, Azure and Google Cloud.

Cloud penetration testing shows how an attacker could break into your cloud accounts and what they could reach once inside. We test Amazon Web Services, Microsoft Azure and Google Cloud, along with Microsoft 365 and Entra ID. In the cloud, the weak point is often an identity or a setting rather than a software bug, so we concentrate on permissions, exposed services and the trust between accounts, workloads and pipelines. Vectra is a CREST-accredited penetration testing provider, and our testers are based in Australia. Every High-severity finding is proven by hand and comes with practical remediation guidance.

Cloud Penetration Testing

What a cloud penetration test involves.

Topic Cloud penetration testing
Platforms Amazon Web Services, Microsoft Azure, Google Cloud, Microsoft 365 and Entra ID
Focus Identity and permissions, exposed services and storage, workloads, Kubernetes and pipelines
Starting point No access, a leaked credential, or a low-privilege user or role you provide
Provider rules Testing stays inside each cloud provider's published testing policy
Deliverables Executive narrative, attack-path findings, ranked remediation and an engineer debrief
Retest Retest of every High-severity finding and above
Quote Scoped and quoted to your accounts, subscriptions and projects

What we test in a cloud penetration test.

Cloud attacks rarely need an exploit. They chain small permission and configuration mistakes, so we test each area and how they connect.

IAM and privilege escalation

We look for roles, policies and permissions that let a low-privilege identity become an administrator, directly or through a chain of steps.

Storage and data exposure

We check buckets, blobs, snapshots and databases for public access, weak encryption key control and data that should never be reachable.

Network exposure and security groups

We test security groups, firewall rules and public endpoints to find management interfaces and services that are open to the internet.

Kubernetes and containers

We assess managed clusters, container registries and runtime settings, including service accounts and the routes from a pod into the wider cloud.

Serverless functions

We review function permissions, triggers and environment variables, because an over-privileged function can act as a quiet doorway into other services.

Microsoft 365 and Entra ID

We test tenant settings, conditional access, app consent and guest access, since this identity layer often controls both cloud and on-premises systems.

CI/CD pipelines and secrets

We look for credentials stored in pipelines, repositories and build logs, and test whether a pipeline could be abused to deploy to production.

Cross-account and tenant trust

We map the trust between accounts, subscriptions and projects to see whether one compromised environment can unlock the others.

In the cloud, one over-permissive role can matter more than a missing patch.

A cloud penetration test follows permissions the way an attacker does, and shows where a single stolen credential could take them.

Get a scoped quote

How we run a cloud penetration test.

Our CREST-aligned six steps, adapted for cloud platforms where identity and configuration matter as much as code.

  1. Step 1: Scope and kick-off

    We confirm the accounts, subscriptions and projects in scope, the starting access and the provider testing rules that apply to each platform.

  2. Step 2: Threat modelling

    We identify the cloud assets that matter most, such as customer data stores, production workloads and deployment pipelines, and the attackers most likely to target them.

  3. Step 3: Reconnaissance

    We enumerate identities, roles, public endpoints, storage and network rules, building a map of how your resources trust and reach each other.

  4. Step 4: Exploitation

    We attempt to abuse weak permissions, exposed services and leaked secrets by hand, with a proof-of-exploit for every High-severity finding and above.

  5. Step 5: Post-exploitation

    From each foothold, we follow role chains and cross-account trust to measure the blast radius and record what your cloud logging captured.

  6. Step 6: Reporting and retest

    Findings are written as attack paths with the exact policy or setting to change, followed by a debrief and a retest of fixed issues.

AWS, Azure and Google Cloud penetration testing.

AWS penetration testing

We examine how IAM roles, policies and trust relationships combine across your AWS organisation, and what an attacker could reach from a compromised workload.

  • IAM roles, policies and trust relationships
  • S3 buckets and key access
  • EC2, Lambda and EKS workloads
  • Cross-account access in AWS Organizations

Azure penetration testing

We test Entra ID roles, app registrations and managed identities alongside the Azure resources they can control.

  • Entra ID roles and app registrations
  • Storage accounts and Key Vault
  • Virtual machines, Functions and AKS
  • Management groups and subscriptions

Google Cloud penetration testing

We review IAM bindings, service accounts and organisation policies, then test whether workloads and storage can be reached or misused.

  • IAM bindings and service account keys
  • Cloud Storage buckets
  • Compute Engine, Cloud Functions and GKE
  • Organisation and folder policies

Cloud penetration testing vs a cloud security posture review.

A posture review checks your settings against a baseline and lists what is misconfigured. A penetration test takes those weaknesses and tries to exploit them, showing which ones combine into a real attack path.

The two work well together. Posture tools such as Wiz, Prisma Cloud and Microsoft Defender for Cloud watch your estate continuously. A penetration test verifies, at a point in time, what an attacker could actually achieve.

Cloud security posture management

  • Posture review

    Broad, continuous and tool-led, comparing every setting with a documented benchmark.

  • Penetration test

    Deep, focused and manual, chaining weaknesses together to prove business impact.

  • Using both

    Posture management keeps settings in line every day, while penetration testing before go-live and after major change proves they hold.

When you need a cloud penetration test.

Cloud environments change faster than most networks, so a test from last year may no longer describe what an attacker would find today. These are the moments when a cloud pentest earns its place.

  • Before go-live

    Test a new platform, landing zone or customer-facing service before real data arrives.

  • After a migration

    Moving workloads from a data centre often carries old trust and admin habits into a new environment.

  • After identity changes

    New single sign-on, federation, conditional access rules or a tenant merger all change who can reach what.

  • When customers or regulators ask

    Customer security questionnaires, APRA CPS 234 and ISO 27001 audits often ask for independent cloud testing.

  • After an incident

    Confirm the attacker's path is closed and look for others like it.

What you receive after a cloud penetration test.

Cloud findings are only useful if your platform and DevOps engineers can act on them quickly. Every report names the exact role, policy or setting to change. Our penetration testing services page lists everything included in a Vectra engagement.

Penetration testing services

  • Attack-path findings

    Each finding shows the route from the first foothold to the impact, with evidence and the identities involved.

  • Remediation by owner

    Fixes are grouped for platform, identity and application teams, ranked by risk.

  • Executive narrative

    A plain-language summary of cloud risk for executives, boards and auditors.

  • Debrief, retest and portal

    An engineer walkthrough, a retest of every High-severity finding and above, and 90 days of portal access to track remediation.

Compliance a cloud penetration test supports.

Our reports can be mapped to the frameworks you answer to. Cloud testing is especially relevant to these.

  • APRA CPS 234. Regulated entities must systematically test their information security controls, including those run by cloud providers on their behalf. See APRA CPS 234.
  • ISO 27001. Testing gives evidence for cloud service security and technical vulnerability management. See ISO 27001.
  • IRAP and the ISM. Government workloads in the cloud are assessed against the Information Security Manual, and penetration testing supports that assurance. See IRAP.
  • PCI DSS. If card data is processed in the cloud, requirement 11.4 penetration testing applies to that environment too. See our PCI DSS services.
  • SOC 2. Independent cloud testing is common evidence for SOC 2 readiness. See SOC 2 readiness.

Cloud penetration testing near you

Our city pages cover the sectors, compliance needs and procurement routes that matter to buyers in each location. See Penetration Testing Sydney and Penetration Testing Melbourne.

Related tests and cloud services.

Network penetration testing

External and internal testing for the networks your cloud connects to.

Network testing

API penetration testing

The APIs your cloud workloads expose, tested for broken authorisation and data exposure.

API testing

Red and purple teaming

Cloud objectives such as IAM role chaining, token theft and cross-tenant escalation inside a goal-led attack.

Red team

Cloud security solutions

Landing-zone review, posture management and workload protection across AWS, Azure and Google Cloud.

Cloud solutions

Get a scoped cloud penetration testing quote.

Tell us which platforms, accounts and services you want tested. We scope each engagement to your environment and quote to that scope.

Get a scoped quote

Cloud penetration testing FAQs.

Do we need permission from AWS, Azure or Google to run a cloud pentest?

Usually not. AWS, Microsoft and Google each publish a testing policy that lets customers test their own resources for most services without asking first. Each policy also bans certain activity, such as denial-of-service testing or attacking other tenants. We check the current policy for every platform in scope when we plan the engagement, and we keep our testing inside it.

What is the difference between a cloud pen test and a cloud security posture review?

A posture review compares your settings with a benchmark and lists what is misconfigured, usually with tooling that runs all the time. A cloud penetration test takes those weaknesses and tries to exploit them by hand, the way an attacker would. It shows which issues join into a real attack path, so you can prioritise the fixes that matter.

Can you test a multi-cloud or hybrid environment?

Yes. Many organisations run workloads in more than one cloud, connected to on-premises networks and a shared identity platform such as Entra ID. We scope the test across those connections, because attackers often move between platforms through shared identities, synchronised accounts or network links. A combined scope with an internal network test is common.

Is our data kept in Australia during a cloud penetration test?

Our testers are based in Australia. Before testing starts, we agree how evidence and sensitive data will be collected, accessed, stored, reported and securely destroyed, and those rules sit in the rules of engagement. If you have specific data residency obligations, tell us during scoping so the engagement is planned around them.

What access do you need for a cloud penetration test?

That depends on the question you want answered. For an outside-in view, we start with no access. For an assumed-breach test, we start from a low-privilege user, role or access key you provide. Read-only access to configuration also lets us find attack paths faster and cover more of your estate in the same time.

Start with a conversation.

Speak to us about your cyber governance and compliance requirements.

Send us a message

What can we help with?

A sentence or two is plenty. We'll ask for detail when we reply.