Penetration testing
Cloud Security 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.
Why it matters
What this protects you from
-
Identity is the perimeter now
One over-privileged role or one leaked access key is the whole environment. Most cloud incidents begin with credentials, not exploits.
-
Defaults stay public until someone says otherwise
Buckets, blob containers, snapshots and database endpoints become reachable through one setting. Nobody notices until it is indexed.
-
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 fully and attack paths are confirmed by hand. 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
Full enumeration of identities, policies, storage, networking and compute across the agreed scope, using the provider APIs directly.
-
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, within agreed limits, with evidence captured as we go. Nothing destructive, ever.
-
Reporting and remediation
Findings written against the specific resource, 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 affected resources 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, so testing never puts your account standing at risk.
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 published thresholds.
- Attack path diagrams
The confirmed routes from initial access to impact, drawn against your actual resources rather than a generic picture.
- 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.