Penetration Testing Hub › Penetration Testing Explained
Cloud Penetration Testing on Azure & Microsoft 365
Only test cloud tenants and subscriptions you own or have explicit written permission to test. Unauthorised access is a criminal offence in Ireland under the Criminal Justice (Offences Relating to Information Systems) Act 2017, and cloud providers have their own testing rules you must also follow. Everything below assumes an authorised assessment of your own environment.
For most Irish organisations, the cloud tenant is now the biggest attack surface they have. Identity is the new perimeter: an attacker doesn't need to breach a firewall if they can phish a token or find an over-privileged service principal. This page covers testing Azure and Microsoft 365 specifically, because that's where Irish business mostly lives, what you can check in your own tenant, and the provider rules you need to know.
1. How it's done
Cloud testing is a configuration and identity review
Unlike a network test, cloud assessment is mostly about how the tenant is configured and how identity is managed. The tester reviews Entra ID (Azure AD): conditional access policies, MFA coverage, privileged roles, service principals and their permissions, guest access, and legacy authentication. Misconfiguration, not un-patched software, is the dominant risk.
Identity attack paths
The recurring theme: over-privileged identities. A service principal with more rights than it needs, a global admin without MFA, a token that can be replayed, an app registration anyone can consent to. Tools that map Azure/M365 attack paths (the cloud cousins of BloodHound) show how a low-privilege account or a phished user can escalate to tenant admin.
Storage, secrets and workloads
Then the resources: publicly-exposed storage, secrets left in code or pipelines, over-permissive network security groups, key vault access policies, and workloads (VMs, containers, functions) that inherit too much identity. In M365 specifically: sharing settings, external forwarding rules, and application permissions on the tenant.
What it usually finds
Legacy authentication still enabled, MFA gaps on admin or service accounts, a global admin count in double digits, service principals with owner rights, guest users with more access than intended, and storage or SharePoint sharing set wider than anyone realised.
2. What to look for — the self-check
- MFA is enforced for every user, and especially every admin — via conditional access, not per-user toggles.
- Legacy authentication is blocked tenant-wide.
- Global Administrator count is minimal (single digits) and all use privileged identity management (PIM) / just-in-time access.
- Service principals and app registrations are inventoried; none has more permission than it needs.
- No storage accounts or SharePoint sites are shared publicly by accident.
- External sharing and mail-forwarding rules are reviewed and controlled.
- Guest access is limited and reviewed regularly.
- Secure Score is monitored and the high-impact recommendations are actioned.
- Sign-in and audit logs are retained and someone actually reviews the alerts.
Provider rules matter
Microsoft permits customer-led penetration testing of your own Azure/M365 resources under its testing terms, but there are rules — no testing of shared infrastructure, no denial-of-service, and Microsoft's own services are off-limits. A competent provider knows exactly where the line is. Always confirm current provider rules before any active cloud testing.
3. What to expect if you hire out
Scoping: which subscriptions and tenants, and a read-only reviewer account (plus any roles needed for deeper testing). Cloud testing is usually grey or white box — there's little value in pretending the tester knows nothing about your tenant.
Duration: a tenant configuration review is often days to a week; broader testing scales with the number of subscriptions and workloads.
Production risk: configuration review is low-risk. Active identity or workload testing is scoped carefully and follows provider rules.
The report: misconfigurations and identity paths by severity, mapped to concrete Azure/M365 settings to change, and a re-test.
4. When you need a pro
You can — and should — run the self-check, monitor your Secure Score, and fix the identity and sharing basics yourself; a lot of cloud risk closes with configuration you already control. Bring in a professional when you want the full identity attack-path analysis, when service-principal and workload permissions get complex, or when a compliance framework needs independent evidence. The cheapest wins (MFA everywhere, kill legacy auth, cut global admins) don't need anyone — do those first.
Download: Azure & Microsoft 365 Security Checklist
A printable one-page version of the self-check above. No email required. Open the Azure & Microsoft 365 Security Checklist
Common questions
Are you allowed to penetration test Azure and Microsoft 365?
Yes — Microsoft permits customers to test their own Azure and M365 resources under its published testing terms, with limits: no testing of shared or Microsoft-operated infrastructure and no denial-of-service. You're testing your configuration and identity, not Microsoft's platform. Always confirm the current provider rules before active testing.
What's the biggest cloud security risk?
Identity misconfiguration — over-privileged accounts and service principals, missing MFA, and legacy authentication. In the cloud, identity is the perimeter, so an attacker who phishes a token or finds an over-permissioned service principal often doesn't need to breach anything else. Most of it is fixable with configuration you already control.
Can I check my own Microsoft 365 security?
Yes. Enforce MFA via conditional access, block legacy authentication, minimise global admins, review external sharing and forwarding rules, and watch your Secure Score. That self-check closes a large share of real cloud risk before any professional testing, and every step is something you can do in your own tenant.
If you'd rather we reviewed your Azure or M365 tenant and mapped the identity paths that matter, here's how a CyberLabs cloud engagement works.
No prices on this page and no hard sell.
This page is educational and not legal advice. Only test systems you own or are explicitly authorised to test. · ↑ Back to top