Active Directory Security Assessments Explained
How Active Directory assessments work: attack paths, assumed-breach testing, common weaknesses such as Kerberoasting and AD CS, and how tests stay safe.
Infrastructure testing
Cloud Security Testing (AWS, Azure, GCP)
We review your cloud configuration and test how an attacker with limited access could escalate to your most sensitive data and services.
- CIS Benchmarks
- Cloud provider security guidance
Overview
In the cloud, identity is the perimeter. A single over-permissive role, a leaked access key or a pipeline with admin rights can give an attacker more than any network flaw ever could, and these issues tend to build up quietly as teams ship.
We combine a configuration review of your AWS, Azure or GCP environment with hands-on, authenticated attack-path testing. All testing respects each provider’s testing policy. You get a clear picture of how small permissions could become full control, and the specific changes that close those paths.
Scope
What we test
- IAM roles, policies and privilege escalation paths
- Cross-account and cross-project trust relationships
- Storage buckets, blobs and snapshots for unintended exposure
- Network exposure, security groups and firewall rules
- Secrets management and hard-coded credentials
- Logging, monitoring and alerting gaps
- Kubernetes and container configuration
- Serverless functions and their permissions
- CI/CD pipeline access to cloud environments
- Instance metadata service access and protection
- Encryption settings and key management
Findings
Common issues we find
Generic examples of what this kind of testing tends to uncover. Every engagement is different, and we never share client findings.
Critical
Roles that can grant themselves more power
Permissions such as creating policy versions or passing roles that turn limited access into administrator access.
High
Publicly readable storage
Buckets, blobs or snapshots containing backups, exports or logs that anyone can access.
High
Long-lived access keys
Static keys in code, CI variables or developer laptops with broad permissions and no rotation.
High
CI/CD with too much access
Build pipelines that hold production admin rights, making the pipeline a path to the whole account.
High
Overly broad network rules
Databases, management ports or internal services open to the whole internet.
Medium
Logging gaps
Audit logging disabled in some regions or accounts, leaving attacks without a trace.
Medium
Weak Kubernetes defaults
Over-privileged service accounts, missing network policies or workloads running as root.
Severity shown is typical, not fixed. We rate each finding on its real impact in your environment.
Approach
How we test it
Agree scope within provider rules
We confirm accounts, subscriptions or projects in scope and plan the test within each provider's published testing policy.
Review the configuration
With read-only access, we review IAM, storage, networking, logging and workloads against good practice and CIS Benchmarks.
Test attack paths
Starting from realistic footholds, such as a leaked developer key or a compromised workload, we test how far an attacker could escalate.
Prioritise by blast radius
Findings are rated by what an attacker could actually reach, so you fix the paths to your most sensitive data first.
Deliverables
What you receive
Every finding comes with proof-of-concept evidence, so your engineers can reproduce it and your auditors can trust it.
Executive summary
A plain-English view of risk for leadership, boards and customers.
Technical findings
Each issue with impact, evidence, reproduction steps and a clear fix.
Free retest
Once you’ve fixed the findings, we retest them and update the report.
Attestation letter
A letter you can share with customers and auditors to show testing was done.
Preparation
What we need from you
We'll confirm the details during scoping. Having these ready helps testing start on time.
- Read-only audit access to the in-scope accounts, subscriptions or projects
- A low-privilege identity to use as the starting point for attack-path testing
- An overview of the architecture and the most sensitive data and services
- A list of anything out of scope, such as shared or third-party-managed resources
- A technical contact and an agreed testing window
FAQ
Cloud (AWS, Azure, GCP) testing questions
Do cloud providers allow penetration testing?
AWS, Azure and GCP all permit customers to test their own resources, within published rules. Those rules exclude things like denial-of-service testing and attacks on the provider's own infrastructure. We plan every test to stay within them.
Is this different from a cloud posture scanning tool?
Yes. Posture tools list misconfigurations. We confirm which ones matter, chain them into real attack paths and show the impact, which is what auditors and customers usually want to see.
What access do you need?
Typically, read-only audit access for the configuration review and a separate low-privilege identity for attack-path testing. We never need your root or global administrator credentials.
Can you test multiple clouds in one engagement?
Yes. Many teams run workloads across more than one provider, and identity links between them are a common source of risk. We scope multi-cloud tests as one engagement.
Guides
SOC 2 Penetration Testing: What Auditors Expect
What SOC 2 actually says about penetration testing, what auditors look for in a pentest report, and how to time your test around the audit window.
Related services
External Network Penetration Testing
Testing of everything you expose to the internet, from forgotten admin panels to VPN gateways, with every finding manually validated.
Internal Network & Active Directory Testing
Assumed-breach testing of your internal network and Active Directory, delivered remotely, to show how far one compromised laptop could go.
Web Application Penetration Testing
Manual testing of your web app's authentication, access control and business logic, the places scanners can't reach.
Need a pentest for an audit, a customer, or peace of mind?
Tell us what you need tested. You’ll get a fixed-fee proposal with tester-days and timeline stated, usually within a few days of the scoping call.