Penetration testing
AWS and Azure Cloud Penetration Testing
Azure and AWS environments tested the way an attacker holding one leaked key would use them, not the way the diagram says they work.
Engagements from $5,000 CAD. Free scoping, a fixed price in writing before any work begins, and one retest included.
At a glance
Is this the right test?
- Best when
- You are launching, migrating, or changing identity and access, or the environment was built by many hands and nobody has compared it with what was intended.
- Covers
- Identity and access, privilege escalation paths, storage exposure, network rules, compute and serverless configuration, and logging.
- You learn
- The paths from a foothold to data or administrative control, each marked as demonstrated or inferred, with each fix given as the policy or setting to change.
Before we start
What we need from you
Scoping settles the details. These are the things that usually decide whether testing can start on the agreed date.
- Read-only auditor access to the accounts or subscriptions in scope (AWS: SecurityAudit; Azure: Reader plus Security Reader).
- Whether Entra ID or Microsoft 365, containers and serverless are in scope or scoped separately.
- Which regions are in scope, and anything excluded.
- Written approval before any step beyond read-only access.
Deliverables
What lands in your inbox
- Executive summary
A plain-language account of the environment's risk position, written for the people who approve the remediation budget.
- Overall security grade
A single grade derived from the most severe confirmed finding, using the thresholds set out in the report.
- Attack path diagrams
The routes from initial access to impact, drawn against your actual resources, each marked as demonstrated or as inferred from configuration.
- Detailed technical findings
Every finding with CVSS vector, CWE classification, affected resource identifiers and reproduction steps.
- Remediation as configuration
Where the fix is a policy or a setting, you get the policy or the setting, ready to apply.
- Retest summary
Issued after remediation, confirming what is closed and what remains exposed.
See a redacted excerpt from a real finding, and what the full report adds.
Why it matters
What this protects you from
-
Identity is the perimeter now
One over-privileged role or one leaked access key can open far more of the environment than it was meant to, and a credential needs no exploit.
-
One change can make it public
Buckets, blob containers, snapshots and database endpoints become reachable through one configuration or policy change. Exposure can persist until it is detected.
-
The diagram and the configuration disagree
Environments are built by many hands over years. Network rules, trust relationships and roles drift from what was intended.
-
Shared responsibility ends at the provider's line
Azure and AWS secure the platform. Everything you configure on it is yours, and that is where the findings are.
Coverage
What we test
-
Identity and access management
IAM policies, Entra ID roles, service principals, managed identities and access keys, tested for over-privilege and paths to administrative control.
-
Privilege escalation paths
How a compromised low-privilege identity reaches higher privilege through role assumption, policy gaps, automation accounts and metadata services.
-
Storage and data exposure
S3 buckets, blob containers, snapshots, backups and database endpoints reviewed for public access, weak policies and missing encryption.
-
Network exposure and segmentation
Security groups, network security groups, peering, public addresses and management ports, compared against what was intended.
-
Compute and serverless configuration
Virtual machines, containers, functions and their attached roles, plus secrets left in environment variables, user data and images.
-
Logging and detection
Whether CloudTrail, the Azure Activity Log, GuardDuty or Defender recorded what we did, so you learn where visibility exists and where it does not.
Approach
Three ways to run it
-
Black box
We start from an exposed identity or a public footprint and work inward, mirroring an attacker who has one leaked key and nothing else.
-
Grey box
Read-only auditor access across the account or subscription, so configuration is reviewed and attack paths are traced by hand. Exercising a path needs separate approval. The usual choice.
-
White box
Auditor access plus infrastructure code and architecture documentation, so drift between intent and reality is measured rather than guessed.
Process
How the engagement runs
-
Scoping and authorisation
Accounts, subscriptions, regions and exclusions agreed in writing, with read-only access provisioned and provider testing policies respected.
-
Configuration enumeration
Enumeration of identities, policies, storage, networking and compute across the agreed scope, using the provider APIs directly, with visibility limits recorded.
-
Attack path analysis
Individual misconfigurations combined into real paths from an initial foothold to data or administrative control.
-
Controlled exploitation
Confirmation of the paths that matter, with evidence captured as we go. Anything beyond read-only access happens only where the scope explicitly allows it, and destructive testing is excluded.
-
Reporting and remediation
Findings written against the specific resource and ranked by exploitability, business impact and what has to be fixed first, with remediation given as the policy, setting or code change rather than a link to a vendor page.
-
Retest
After remediation we re-check the reported findings, one round, requested within 60 days of the report, and issue a retest summary confirming closure.
Standards
What we test against
- CIS Benchmarks
- Configuration is compared against the CIS Foundations Benchmarks for AWS and Azure, so every setting-level finding cites a published control.
- MITRE ATT&CK
- Findings are mapped to the cloud matrix, so results line up with how your defensive team already models threats.
- NIST SP 800-115
- The assessment structure follows the NIST technical guide, which is what procurement and audit teams expect referenced.
- Provider testing policies
- Work stays inside the AWS and Azure penetration testing policies, which is what keeps a test from becoming an account-standing problem.