Cloud Pentest Checklist: AWS, Azure and Microsoft 365

A cloud pentest tests the part of the cloud that is yours: identities, permissions, network rules, storage settings, workloads and logging. The provider secures the data centre and the hypervisor; everything above that line is your configuration, and that is where almost every cloud breach starts. This checklist is what we cover in a cloud pentest of AWS, Azure and Microsoft 365, and what we find most often.

Before the test: rules and preparation

Provider rules. AWS allows penetration tests of the common services (EC2, RDS, Lambda, API Gateway, CloudFront and others) without prior approval; denial-of-service tests, DNS zone walking and flooding are excluded, and DDoS simulations need a separate request. Microsoft publishes rules of engagement for its cloud services that apply without notification; DoS, access to other customers’ data and post-compromise actions such as lateral movement inside Microsoft infrastructure are forbidden. We check both policies against the current scope before day one.

What we ask for.

• A read-only audit role (AWS SecurityAudit, Azure Reader plus Security Reader, Microsoft 365 Global Reader) for the configuration review.
• A list of accounts, subscriptions and tenants in scope, with the owner of each.
• One low-privileged user per role for the attacker’s view from the inside.
• Written authorisation and a contact for findings that need immediate attention.

Checklist 1: Identity and access

Identity is the perimeter in the cloud, and it is where we find the most critical issues.

• Long-lived access keys for IAM users, often unused for months and sometimes committed to repositories.
• Users and service accounts without multi-factor authentication, including break-glass accounts.
• Policies with "Action": "*" or iam:PassRole on *, which allow privilege escalation to administrator.
• Cross-account trust without an ExternalId or with a wildcard principal.
• In Entra ID: legacy authentication still allowed, so Conditional Access is bypassed; application consent open to all users; privileged roles assigned permanently instead of through Privileged Identity Management; guest accounts with more rights than intended.
• Service principals and managed identities with Contributor on the whole subscription.

Checklist 2: Storage and data

• S3 buckets and Azure Blob containers with public read or list access, or with policies that grant access to any authenticated AWS account.
• Shared access signatures (SAS) with long lifetimes in client code.
• Database snapshots, AMIs and disk images shared publicly or across accounts.
• Backups in the same account as production, so one compromised identity deletes both.
• Missing encryption at rest for databases that hold personal data, or keys managed outside Key Vault or KMS.

Checklist 3: Compute and network

• Security groups and network security groups open to 0.0.0.0/0 on SSH, RDP, database and management ports.
• EC2 instances with IMDSv1 enabled, so any SSRF in a web application yields role credentials.
• Secrets in user data, environment variables and container definitions.
• Containers running as root or with privileged mode; Kubernetes dashboards and APIs reachable from the internet.
• Flat networks: production and development in one VPC or VNet without segmentation.
• Serverless functions with permissions far beyond what they call.

Checklist 4: Logging and detection

• CloudTrail not enabled in every region, or logs that can be deleted by the same identities they monitor.
• GuardDuty, Defender for Cloud or Microsoft 365 unified audit logging switched off or never looked at.
• Alerting that nobody receives. We test this: we trigger a few noisy actions and ask who noticed.

Checklist 5: Microsoft 365 specifics

• Mailbox rules that forward mail outside the organisation, a classic sign of a compromised account.
• Anonymous sharing links on SharePoint and OneDrive with no expiry.
• External access in Teams open to any domain.
• No Conditional Access for unmanaged devices, so a stolen password from a home PC is enough.
• Legacy protocols (IMAP, POP, SMTP AUTH) still enabled.

The findings we see most

Finding	Typical severity	Why it matters
Admin privileges reachable from a low-privileged identity	Critical	One phished developer owns the account
Public storage with customer data	Critical	Data breach without any exploit
IMDSv1 plus SSRF in an application	High	Web bug becomes cloud credentials
Legacy authentication allowed in Entra ID	High	MFA and Conditional Access bypassed
Logs missing or deletable	Medium	Incidents are not seen or cannot be investigated

How we test

A cloud pentest at Zyberum combines three views. The configuration review with an audit role against the CIS Benchmarks and our own checks finds the gaps across the whole estate in a few days. The external view tests everything reachable from the internet: exposed services, storage, web applications and APIs. The assumed-breach view starts with a low-privileged user or a leaked key and tries to reach administrator, data and production. Every finding comes with the exact resource, the CVSS score, the reproduction steps and the fix, as a policy snippet or a console setting where possible.

What to do first

• Enforce MFA for every human identity and remove long-lived keys.
• Block legacy authentication and require managed devices for Microsoft 365.
• Close public storage and public management ports; alert when one opens.
• Turn on and protect the logs, then test that someone reacts.
• Have the environment tested before a migration or a certification audit, not after.

See cloud pentest for scope and prices, or book a free 15-minute call.