Cloud breaches almost never start with a kernel exploit. They start with a forgotten S3 bucket, an over-permissive IAM role, or a Terraform module that drifted from its committed state. We test your cloud the way the people compromising it actually do: identity-first, configuration-aware, and grounded in what your providers can confirm went wrong.
What is Cloud Security testing?
Cloud security testing answers a different question than a traditional pentest. The infrastructure you’re testing isn’t a network you own. It’s a control plane operated by AWS, Azure, or GCP, where security is defined in IAM policies, resource configurations, and the trust relationships between accounts. Compromise rarely involves a remote code exploit. It involves an attacker becoming an identity that can read your data, and following the chain of trust until they reach it.
We test that chain. We map who can become whom across your accounts, which identities can reach which data, where your storage and databases are reachable from, and whether your IaC pipeline can be used as a path into production. The output is an attack-path graph grounded in your actual environment, not a generic best-practice list.
Why cloud security is its own discipline
Patterns we see in nearly every cloud environment:
- IAM permission creep: a role created for an engineer’s exploration task in 2022 still has full administrative access, and that role is now assumed nightly by a CI runner
- Implicit cross-account trust: a “shared services” account that can read into production for monitoring, becoming the single most valuable target in the environment
- Forgotten public objects: a bucket made public for a one-off vendor exchange, now hosting database backups
- Exposed management planes: RDP/SSH/kubelet open to the internet because a temporary debugging rule was never reverted
- CI/CD as a path to production: write access to a single repository granting deployment privileges into every environment via OIDC trust with no scoping
- Drift between IaC and reality: Terraform says the resource is private; the console shows it open to 0.0.0.0/0 because someone fixed an outage by hand
Each of these turns a “least privilege” cloud into a flat one for an attacker who knows where to look.
CyberBullet’s methodology
1. Scope & Account Inventory
We start with the list of accounts, subscriptions, or projects in scope, plus your IaC repositories. This defines the perimeter, and immediately surfaces accounts your security team didn’t know existed (shadow IT, acquired-company tenants, sandbox accounts that became production).
2. Identity & Trust-Path Mapping
For every in-scope account we enumerate principals (users, roles, service accounts), their attached policies, federation trusts, and the relationships between accounts. The output is a graph of who can become whom, including the indirect paths (assume-role chains, SCIM/SSO overrides, cross-account roles) that are easy to miss in a manual review.
3. External Attack Surface
From the internet, we enumerate every publicly reachable endpoint attributable to your environment: managed services, load balancers, API gateways, exposed object storage, and the management planes people forget about. We confirm exposure with read-only probes; we don’t exploit customer data.
4. Configuration & Hardening Review
Using a scoped read-only role, we evaluate your configuration against the CIS Foundations benchmark for each provider, plus the provider-specific hardening guides (AWS Well-Architected Security Pillar, Azure Security Benchmark, Google Cloud Security Foundations). Findings are deduplicated, ranked by reachable impact, and tied back to the IAM and attack-path analysis.
5. IaC Drift & Pipeline Trust
We pull your Terraform / CloudFormation state and compare it against the live environment to find resources that drifted (and the rules that changed without going through code review). For your CI/CD, we trace the OIDC and key-based trust paths from repositories to deployments, the most common modern path to production compromise.
6. Reporting & Detection Guidance
The report ties every finding to a specific attack path, ranks by reachable impact (not raw CVSS), and includes both immediate remediation (provider-native fix steps with IaC patches where applicable) and the detection guidance: CloudTrail / Azure Activity / GCP Audit Log queries that would have caught the activity if it had happened in production.
Frameworks we map findings to
- CIS Benchmarks: AWS Foundations, Azure Foundations, GCP Foundations
- NIST SP 800-53 Rev. 5: Access Control (AC), Configuration Management (CM), and System & Communications Protection (SC) families
- NIST CSF 2.0: Identify (ID.AM, ID.RA), Protect (PR.AC, PR.IP), and Detect (DE.CM) functions
- ISO/IEC 27017: cloud-specific extension to ISO 27002
- CSA Cloud Controls Matrix v4: provider-agnostic control mapping useful for multi-cloud environments
Our methodology
Every engagement runs through the same six phases. Manual validation isn't a finishing step. It's the product.
Scope & Authorize
16%We define the engagement boundary precisely before testing starts: in-scope assets, out-of-bounds targets, testing windows, and emergency-stop procedures.
- Written authorization letters exchanged before any packet leaves our infrastructure
- Signal / Slack channel established for real-time findings during the engagement
- Explicit rules of engagement reviewed with legal, IT, and business stakeholders
Passive Reconnaissance
33%Before a single packet touches your infrastructure, we map your external footprint using public sources only: DNS, CT logs, code repos, internet-wide scan data.
- Typically discovers 15-30% more attack surface than the client originally provided
- Certificate transparency, BGP, and GitHub exposure reporting
- OSINT profile for social engineering vectors if in scope
Active Discovery
50%We enumerate live services across in-scope assets (ports, software versions, auth mechanisms, and protocol configurations) correlated against current vuln data.
- Hand-tuned scanning profiles, not the default Nessus run
- Protocol-level inspection for TLS, SSH, SMB, Kerberos, LDAP
- Service fingerprinting to ground truth before any exploitation
Manual Validation
66%Every potential issue is validated by hand before it makes the report. No CVE-dumping. No false positives. This is what separates the engagement from a scan.
- Manual exploitation attempts for any finding of High severity or above
- Business-logic testing on top of the technical layer
- Chained vulnerabilities analyzed as a single attack path
Exploitation & Impact
83%For confirmed vulnerabilities with attacker value, we attempt exploitation to prove impact, not just that a CVE applies but what it gets you.
- Proof-of-exploit captured for every confirmed critical finding
- Pivot paths mapped to the actual crown-jewel data
- Interim notification inside 24 hours for anything critical
Report & Remediate
100%Every finding is paired with severity rated on real exploitability, reproducible proof-of-exploit, and remediation guidance your team can ship this sprint.
- Executive summary and technical deep-dive in a single report
- Findings mapped to CIS, NIST CSF, and relevant compliance families
- Retest included. We confirm the fix before we close the finding
What you walk away with
Frameworks we map to
Findings ship mapped to the control families your regulators and auditors actually check. Governance clients use these crosswalks directly in their program documentation.
- CIS Benchmarks (AWS / Azure / GCP Foundations)
- NIST SP 800-53 (AC, CM, SC families)
- ISO/IEC 27017 (cloud-specific controls)
- CSA Cloud Controls Matrix v4
Questions we get asked
How is this different from a cloud security audit?
An audit checks your configuration against a checklist of controls. A cloud security test confirms whether an attacker who already got a foothold (through a phished engineer, a leaked CI key, or an exposed service) could actually reach your data. We run the attacker's playbook against your environment with read-only API access (no exploitation of customer data), so you see the actual reachable blast radius, not a theoretical compliance score.
Do you need our cloud credentials, and how do you protect them?
Yes. For the configuration-review portion we use a scoped read-only IAM role you create for the duration of the engagement (no long-term keys, no write permissions, no access to data plane). For the external attack-path portion we work from publicly reachable surface only. Credentials are stored in our secrets manager, never written to disk on engineer laptops, and revoked at the end of the engagement with an attestation.
Which providers and services do you cover?
AWS, Azure, and Google Cloud at the platform level: IAM, networking, compute, storage, secrets, logging, and the managed services people forget to harden (S3, RDS, Cosmos DB, GKE, EKS, AKS, Lambda/Functions, API Gateway). For Kubernetes specifically we cover cluster hardening, RBAC, network policy, and workload identity in addition to the underlying cloud configuration.
