APOLLOSEC

Cloud security assessments for AWS, Azure and Google Cloud

A review of how your cloud is configured, and a test of what an attacker could do with it. We look for the small misconfigurations that turn one leaked key into access to everything.

Cloud breaches are rarely clever

Cloud breaches rarely involve breaking anything. They involve a storage bucket left public, an access key committed to a code repository, or an identity with far more permission than it needs. Each is a small mistake. Together they make an attack path.

Configuration scanners list hundreds of issues and call most of them urgent. We combine a configuration review with hands-on testing, so you learn which issues really chain into a breach and which can wait.

What we test

  • Identity and access

    IAM roles and policies, privilege escalation paths, unused and long-lived keys, cross-account trust and federation.

  • Storage and data

    Public or over-shared buckets and blobs, snapshots, backups and database exposure.

  • Network controls

    Security groups, firewall rules, public endpoints and private connectivity.

  • Workloads

    Virtual machines, containers, Kubernetes and serverless functions, including metadata service abuse and secrets in environment variables.

  • Logging and detection

    Whether the activity an attacker would generate is recorded, and whether anyone would be alerted.

  • Microsoft 365 and Entra ID

    Conditional access, MFA coverage, guest access, application consents and privileged roles.

How the engagement runs

  1. Read-only access

    You grant a read-only audit role in each account, subscription or project. We never need standing write access.

  2. Configuration review

    We review configuration against CIS Benchmarks and provider guidance, and map identities and trust relationships.

  3. Attack path testing

    From agreed starting points, such as a leaked key or a compromised workload, we test how far an attacker could get.

  4. Report and retest

    Prioritised findings with the policy or setting to change, the report within five working days, then a retest.

What you get

  • Attack paths drawn from a realistic starting point to your most sensitive data.
  • Configuration findings by service, each with the exact setting to change.
  • A short list of fixes that remove the most risk.

When to commission it

  • After migrating workloads to the cloud or adding a new provider.
  • When infrastructure is built by several teams or suppliers, each with their own accounts.
  • After an incident involving leaked keys or credentials.
  • Yearly, with internet-facing cloud assets watched continuously on the platform.

Questions we get asked

Is this a configuration review or a penetration test?

Both. The configuration review finds the weaknesses. The testing shows which of them an attacker could chain together, and that is what decides priority.

Do we need permission from AWS, Microsoft or Google?

Not for most testing. All three publish policies allowing customers to test their own resources without prior approval, within limits such as no denial of service. We work within those policies.

Which platforms do you cover?

AWS, Microsoft Azure and Google Cloud, plus Microsoft 365 and Entra ID. If you run Kubernetes, we cover the cluster as well as the cloud around it.

What access do you need?

Read-only access to the accounts in scope, through a dedicated role you can revoke when we finish. For attack path testing we agree starting points with you, such as a low-privilege user or a test workload.

Find the path from one leaked key to your data.

Talk to us