Cloud Penetration Testing in Australia: What It Covers
Cloud penetration testing is a hands on security test of the parts of your cloud environment that you control: your identity and access setup, your network and workloads, your applications, and your data stores. It does not test the cloud provider’s own infrastructure, because AWS, Microsoft and Google test that themselves and publish audit reports instead. For most Australian businesses, a cloud penetration test takes 5 to 10 business days of testing and answers one question: if someone got a foothold in our cloud account, how far could they go?
That definition matters because the phrase is used loosely. Some vendors sell an automated configuration scan as a cloud penetration test. Others sell a traditional external network test and call it cloud because the servers happen to sit in AWS. Neither is wrong, exactly, but neither tells you what an attacker could do with a leaked access key, and that is usually the finding that matters most.
What is cloud penetration testing?
Cloud penetration testing is manual, authorised testing of a cloud environment to find weaknesses an attacker could exploit. A tester works with real credentials or from an anonymous starting position, and attempts to gain access, escalate privileges and reach data, exactly as an attacker would, then writes up what worked and how to fix it.
The difference from a traditional penetration test is where the attack surface sits. In a data centre, the interesting weaknesses are usually in exposed services and unpatched servers. In a cloud account, the interesting weaknesses are usually in identity: an over privileged role, a long lived access key in a code repository, a service account that can assume a more powerful role, or a storage bucket that is readable by anyone who knows the name.
Automated tools can find some of this. A cloud security posture scanner will flag a public bucket. What it will not do is chain three medium risk misconfigurations into full account takeover and then show you the path, which is what a penetration test is for. If you are weighing the two approaches, our guide to penetration testing versus vulnerability scanning covers where each one earns its keep.
How does penetration testing change when you move to the cloud?
Moving to the cloud changes who is responsible for what, and a penetration test can only cover the half that belongs to you. AWS, Microsoft Azure and Google Cloud operate a shared responsibility model: they secure the physical facilities, the hardware and the virtualisation layer, and you secure everything you configure on top of it. That boundary is the single most important thing to understand before you scope a test.
In practice this means three changes. First, the control plane becomes a target in its own right, because whoever controls the management console controls everything inside it. Second, the perimeter is no longer a firewall, it is a set of identities and permissions. Third, a mistake can be global rather than local: one misconfigured policy can expose every bucket in an account, not just one server.
What does a cloud penetration test actually cover?
A cloud penetration test covers the layers you configure, which for most Australian businesses means five areas: identity and access management, the cloud control plane and its logging, exposed network services and workloads, the applications you run, and the data stores behind them. A tester will usually work through all five rather than pick one, because the useful findings are the paths that join them together.
| Area tested | Typical findings | Why it matters |
|---|---|---|
| Identity and access | Over privileged roles, unused admin accounts, long lived keys | One leaked key becomes full account access |
| Control plane and logging | Logging disabled in some regions, no alerting on policy changes | An attacker operates without leaving a trail you will read |
| Network and workloads | Management ports open to the internet, unpatched images | The oldest attack still works if nobody is watching |
| Applications | Broken access control, weak authentication, injection flaws | Most breaches start with the application, not the platform |
| Data stores | Public buckets, unencrypted snapshots, over shared databases | This is the part that turns an incident into a notifiable breach |
If your cloud environment mostly hosts a web application, a cloud penetration test and a web application penetration test overlap but are not the same engagement. The application test goes deep on one product. The cloud test goes wide across the account that hosts it.
What are you not allowed to test on AWS, Azure or Google Cloud?
Every major cloud provider publishes rules about what customers may test, and those rules are part of the scope conversation. As a general position, the major providers permit customer penetration testing of your own resources without prior approval for a defined list of services, and they prohibit testing that affects other tenants. Denial of service and distributed denial of service simulation is the usual exception and needs a separate process.
You also cannot test the provider’s physical sites, their hypervisor, or another customer’s data on shared hardware. That is not a gap in your assurance, it is the part the provider covers, and the evidence you get instead is their audit reports. A buyer asking about your cloud security is entitled to your penetration test report and the provider’s certifications, not a test of the provider.
Before any test starts, confirm the current position directly with the provider. AWS publishes its customer support policy for penetration testing, and Microsoft publishes its penetration testing rules of engagement. Read them at the time you scope, because the permitted service lists change.
How do you scope a cloud penetration test?
Scoping a cloud penetration test means naming four things: which accounts and subscriptions are in scope, which regions, what starting position the tester is given, and what is explicitly off limits. Getting these written down before the engagement is what stops a test from drifting into a configuration review or missing the environment that actually matters.
- List the accounts. Most businesses have more than they think. Production, staging, a legacy account from a migration, and a personal account somebody opened with a company card.
- Decide the starting position. An unauthenticated test shows what an outsider sees. An authenticated test, where the tester is given a low privilege identity, shows what an attacker does after a phishing email works. The second usually finds more.
- Name the crown jewels. Tell the tester which data set would hurt most if it left the building, so the test measures the path to that, not just the count of findings.
- Write the off limits list. Production databases during business hours, any managed service you do not own, and anything that would disrupt a customer.
- Agree the retest. A finding is not fixed until someone has proven it is fixed.
Our step by step guide to scoping a penetration test walks through the same questions for any engagement type, and the guide to reading a penetration test report covers what to do with the results once they land.
How often should an Australian business test its cloud?
Most Australian businesses test their cloud environment once a year, and again after any significant change to the environment. A significant change means a new production account, a migration between providers, a new customer facing application, or a restructure of who has administrative access. Annual testing is also what most compliance frameworks and customer contracts expect, so the cadence is usually set for you.
Annual testing has a known weakness: cloud environments change weekly, and a test is a snapshot. The practical answer is to pair an annual penetration test with continuous configuration monitoring, so drift is caught between tests rather than eleven months later. Our article on how often to run penetration testing sets out the cadence by business type.
One more point on who does the work. Accreditation is worth checking, because it tells you the tester has been assessed by somebody other than their own marketing team. Our explanation of why CREST accreditation matters covers what the assessment involves.
Common questions
What is cloud penetration testing?
Cloud penetration testing is authorised, manual security testing of the parts of a cloud environment that a customer controls, including identity and access management, the control plane, network services, applications and data stores. It does not include testing the provider’s own physical infrastructure or hypervisor. The output is a report showing which weaknesses an attacker could exploit, in what order, and how to fix them.
Why is penetration testing important to cloud security?
Penetration testing is important to cloud security because automated tools list misconfigurations in isolation while attackers chain them together. A scanner reports an over permissive role and a public storage bucket as two separate medium risks. A penetration test shows that one leads to the other and ends with your customer database, which changes how quickly the issue gets fixed.
How do you do cloud penetration testing?
Cloud penetration testing runs in five stages: agree the scope and rules of engagement, check the provider’s testing policy, review the control plane and identity configuration, actively test workloads and applications for exploitable weaknesses, then report and retest once fixes are in. For a typical small Australian business the testing takes 5 to 10 business days, with about a week for reporting.
Is penetration testing a control?
Penetration testing is treated as a control by most frameworks, though it is a detective control rather than a preventive one. ISO 27001 expects technical vulnerabilities to be identified and managed, SOC 2 examinations commonly look for evidence of testing, and many Australian customer contracts require an annual test. Penetration testing does not fix anything on its own. The remediation that follows it is what reduces risk.
What is involved in testing a cloud environment?
Testing a cloud environment involves enumerating accounts and regions, reviewing identity and access policies for privilege escalation paths, checking whether logging and alerting would detect an intruder, probing exposed services and workloads, testing the applications running on top, and checking data stores for weak encryption or public exposure. The tester then attempts to chain findings into a realistic attack path and documents it.
Where to start
If you have never tested your cloud environment, start by listing every account and subscription your business owns, and who holds administrative access to each. That list alone often finds a problem. Then scope an authenticated test against the account that holds your most sensitive data, because that is where a real attacker will end up.
Siege Cyber is a CREST accredited Australian penetration testing firm and we test cloud environments across AWS, Azure and Google Cloud for businesses of 2 to 100 staff. You can see what an engagement includes on our penetration testing service page, or get in touch to talk through scope. If you would rather start with continuous coverage instead, our vulnerability assessment service is the lighter option, and our penetration testing pricing guide explains what drives cost.