Cloud Attack Surface Review for AWS/GCP

The last cloud breach you read about almost certainly started with a credential, not an exploit. Nobody burned a zero-day on your load balancer. Someone found a long-lived access key in a public repo, ran aws sts get-caller-identity to see what it was, assumed a role it should never have been able to assume, and walked out with an S3 bucket — and CloudTrail logged every call, because it was all legitimate API traffic. In the cloud the perimeter isn’t a firewall. It’s the set of IAM policies and API permissions nobody has read end to end since the account was six months old.

This Cloud Attack Surface Review looks at your AWS and GCP environments the way that attacker did — identity sprawl, exposed storage, leaky CI/CD, the paths that actually chain into a breach. It is deliberately not a compliance sweep. A green compliance dashboard and a trivially exploitable iam:PassRole chain coexist happily, and this review is aimed at the second thing.

Identity Is Your New Perimeter

In AWS and GCP, one over-privileged role is a full-organisation compromise waiting for the right typo in a web app. Identity is where the blast radius lives, so it’s where the review spends most of its time.

The vectors that actually turn into breaches:

• Identity Sprawl: Too many principals with too much access, dormant service accounts nobody owns, and cross-account trust relationships that quietly stitch together an access path no single person ever designed. The dangerous ones are rarely a single bad policy — they’re a chain of individually-reasonable grants that compose into AdministratorAccess.
• Storage Exposure: Public S3 buckets, Cloud Storage objects with permissive ACLs, unencrypted EBS snapshots left lying around. A snapshot is a full disk copy, and its permissions are a separate setting people forget the moment the volume itself is locked down.
• CI/CD Weakness: Hardcoded secrets in the repo, GitHub Actions runners holding far more permission than any single workflow needs, deployment roles scoped for convenience rather than least privilege. The pipeline can legitimately deploy to production, which is exactly why owning it is better than owning a server.
• Network Gaps: Over-broad security groups, Kubernetes services exposed to the internet, WAFs that a slightly-shaped request walks straight past. Worth naming the limit here: network controls are the outer layer, and in an identity-first breach they’re often never touched at all.

How We Actually Do This

We work from read-only access — nothing gets changed, and that’s a deliberate constraint, not a limitation. A review that can only observe can’t accidentally take down production, and it forces the findings to be about configuration you can verify rather than exploitation you have to trust. What we examine:

1. Find Everything That’s Exposed: Every region, VPC, API gateway and load balancer — including the resources in regions nobody remembers turning on. Attackers enumerate all regions; defenders usually watch three.
2. Audit Your IAM: Hunt the escalation primitives — iam:PassRole, sts:AssumeRole chains, lambda:CreateFunction paired with a rich execution role — check whether MFA is actually enforced rather than merely available, and model the blast radius of a single stolen key.
3. Review Your Compute: EC2, GCP Compute Engine, container registries, Kubernetes clusters — what’s the baseline, and specifically, what identity does each workload carry? An instance profile is a credential the moment the app in front of it has an SSRF bug.
4. Lock Down Your Data: S3, KMS, databases. The test is simple and unforgiving: can this data be reached from outside the organisation’s identity boundary? If yes, that’s the finding, regardless of how unlikely the path looks.
5. Check Your Logging: Is CloudTrail (and the GCP equivalent) actually recording, in every region, shipping somewhere tamper-resistant? The silent failure that matters: audit logging is not retroactive, so logging enabled today tells you nothing about last month — and a management-event trail that omits data-plane events won’t show the bucket being read.

Tools We Use

Nothing exotic — the tools that hold up in practice, with the honest caveat that every scanner produces false positives and the manual review is where the value is:

• Cloud CLIs: AWS CLI and gcloud to pull configuration straight from the source of truth
• Security Scanners: Prowler and ScoutSuite to surface misconfigurations fast — a first pass, not a verdict
• IAM Analysis: Cloudsplaining to map privilege-escalation paths through the policy graph, which is exactly the part humans read wrong
• Exposure Checks: Shodan and Nmap to confirm what’s genuinely reachable from the internet, since a security group and reality sometimes disagree
• Secret Scanning: GitHub’s native scanning and TruffleHog to find committed credentials — and treat every hit as live until rotated, because a key that was ever public should be assumed harvested

What You Actually Get

Not a generic compliance PDF that ages on a shelf. A remediation backlog your DevOps team can work top-down:

• Cloud Attack Surface Map: A visual inventory of what’s exposed, how accounts trust one another, and where an attacker pivots — the trust edges especially, because those are what a spreadsheet of resources can’t show you.
• IAM Risk List: Every over-privileged principal, ranked by the damage it does when compromised rather than by how it scored on a checklist. Priority is blast radius, not severity in the abstract.
• Storage & Exposure Report: Public buckets, over-open security groups, APIs facing the internet that shouldn’t be.
• CI/CD Risks: Where secrets are leaking and which deployment roles hold more power than any workflow uses.
• 45-Day Fix Plan: Prioritised, sequenced remediation aligned to CIS and ISO — starting with anything that is a live credential rather than a latent weakness.

Typical Cloud Risk Matrix

Risk Priority	Control Gap / Finding	Attack Vector & Business Impact	Remediation Owner
Critical	Over-privileged EC2 Instance Profile	An SSRF vulnerability in a web app could allow an attacker to query the metadata service, retrieve credentials, and assume an AdministratorAccess role.	DevOps / IAM Admin
High	Publicly Writable S3 Bucket	Misconfigured bucket ACLs allow unauthenticated users to overwrite deployment artifacts, leading to potential supply chain compromise.	Cloud Engineering
Medium	Hardcoded AWS Keys in GitHub	Long-lived access keys found in a legacy repository; while inactive, they pose a severe risk if the repository is made public or compromised.	SecOps / Dev Team
Low	Missing CloudTrail Log Encryption	CloudTrail logs are collected but not encrypted at rest via KMS, marginally increasing the risk of log tampering.	Security Engineering

Fix It in 45 Days

The order below is deliberate: stop the bleeding, then remove the class of problem, then build the detection that catches the next one.

• Week 1 (Emergency Lockdown): The live stuff first. Rotate exposed secrets — rotate, not just delete, since anything public was likely already scraped. Lock public buckets, pull back the roles that grant org-wide admin.
• Weeks 2–3 (Right-Size Access): Retire long-lived access keys in favour of short-lived credentials (IAM Roles Anywhere, OIDC, instance/workload identity) and enforce MFA everywhere. Expect friction — a script somewhere depends on a static key, and finding it is part of the work, not a sign the plan is wrong.
• Weeks 4–5 (Harden the Edges): Tighten security groups to what’s actually used, constrain egress (data leaves through outbound, and default-allow egress is how exfiltration goes unnoticed), and put a WAF in front of public apps understanding it’s a speed bump, not a wall.
• Week 6+ (Detection): Confirm logs actually reach the SIEM — a broken log sink fails silently and every downstream alert with it — and alert on the identity events that precede a breach: new trust relationships, AssumeRole from unexpected principals, first-time bulk data access.

Cloud security stops being hard the moment you stop treating it like a datacentre with someone else’s servers. The model is different, the attacker’s path is different, and once the review makes that path visible, most of the fixes are configuration, not spend.