External network
Internet-facing services, perimeter VPN, exposed admin interfaces, mail and DNS, attack-surface drift.
Know what an attacker can reach before a real intrusion shows you.
Network and cloud penetration testing across your perimeter, internal environment, and AWS, Azure, or GCP account — the attack paths real intrusions use.
What's at risk
Most cloud breaches start with a misconfiguration you did not know was there.
An over-permissive IAM role. A storage bucket open to the internet. An internal service reachable from the VPN without authentication. These are not exotic findings — they show up in the majority of network and cloud pentests.
Need to satisfy an auditor asking for external and internal network testing, or validate that segmentation actually contains a compromised workload? This engagement answers both.
What we cover
Six attack paths we close — both classical and cloud-native.
Internal network
Lateral movement paths, AD weaknesses, kerberoasting, NTLM relay, segmentation gaps, credential reuse.
Cloud configuration
AWS, Azure, GCP — IAM trust paths, public storage, network exposure, key handling, default policies.
Cloud workloads
EC2/VM hardening, container and Kubernetes RBAC, serverless permissions, secrets in CI and metadata.
Identity and SSO
Federation trust, SCIM provisioning, MFA bypass, conditional-access drift, OAuth scope abuse.
Network segmentation
Validate that segmentation actually contains a compromised endpoint or workload.
How we test
Four phases, every engagement.
- 01
Surface mapping
External recon plus cloud account, IAM, and topology review.
- 02
Targeted testing
Manual exploitation of weaknesses; safe proofs only; no destructive payloads.
- 03
Lateral and trust paths
Map what one foothold or IAM role can reach. Validate segmentation holds.
- 04
Reporting and walkthrough
Findings with evidence and remediation, mapped to CIS Benchmarks and your compliance framework.
Not sure what your cloud or network scope covers?
A quick scoping call gives you a fixed scope, price, and date.
Get a straight answer Typical scenarios
Three patterns we see most often.
Cloud-native startup
You run on AWS, Azure, or GCP and want IAM trust paths and configuration tested.
Enterprise with offices
External plus internal network testing across an office or VPN perimeter.
Segmentation validation
Validate that your CDE, ePHI, or sensitive workload is actually isolated.
Adjacent engagements
Most teams pair network/cloud testing with one of these.
Red team operations →
If detection and response is the question, not just configuration.
Compliance pentest →
Map findings to SOC 2, ISO, PCI, HIPAA, and 800-53.
Vulnerability scanning →
Continuous coverage between annual network pentests.
Web application testing →
Cover the apps running inside the cloud account.
By compliance framework
Mapped to the audit you're under.
Each framework page covers the scoping, control mapping, and report format the auditor for that framework expects.
SOC 2 penetration testing →
Findings tagged to the Trust Services Criteria your SOC 2 auditor reaches for first.
PCI DSS penetration testing →
External, internal, and segmentation testing aligned to v4.0.1 Requirement 11.4.
HIPAA penetration testing →
Technical safeguards under §164.312, scoped against the ePHI boundary.
ISO 27001 penetration testing →
Annex A 8.8, 8.29, 8.34 evidence against your Statement of Applicability.
GLBA penetration testing →
Safeguards Rule 314.4 evidence for financial services SaaS.
Compliance pentest index →
Cross-framework view of how a single engagement maps to multiple audits.
Further reading
Background from our team.
Cloud Penetration Testing: AWS, Azure, and GCP →
Shared responsibility, common misconfigurations, and testing methodology across the three major clouds.
Zero-Day Vulnerabilities: What Scanners Miss →
The categories of issues automated tools cannot reason about — and why they drive most real intrusions.
FAQ
Network and cloud testing — common questions
What is the difference between network and cloud pentesting?
Network pentesting targets perimeter, internal services, and Active Directory environments. Cloud pentesting targets IAM trust paths, configurations, and workload exposure inside AWS, Azure, or GCP. Most engagements combine both.
Do you test inside our cloud account?
Yes. We use read-only access where possible and time-boxed write access only when a specific test requires it. IAM role, scope, and rollback plan are agreed before testing starts.
How long does a network and cloud engagement take?
3–5 weeks of testing plus a week of reporting for typical mid-size environments. Multi-cloud environments run longer.
Do you require an internal pivot box or implant?
We agree on the access model up front — options include a jump host you provision, a tester-on-site engagement, or an assumed-breach foothold.
Will the report cover CIS Benchmarks?
Yes. Cloud findings are mapped to CIS Benchmarks for the relevant provider plus SOC 2, ISO, PCI, or HIPAA as applicable.
Want a credible answer when a customer, auditor, or your board asks how secure you are?
A quick scoping call with the senior tester who would run your engagement. No slides, no pitch — we look at what you have, tell you what we would test first, and give you a fixed scope, price, and date.