Cloud attack paths & read-proof

What it is

A single misconfiguration is rarely the story. What matters is the path: how an internet-reachable foothold becomes access to your data. Umbra’s cloud scanner correlates findings into data-terminating attack paths across AWS, Google Cloud, and Azure, and it proves the exposure at each end rather than inferring it.

Data-terminating attack paths

A path chains an entry point to the specific data it reaches:

• AWS: an internet-facing EC2 instance that still allows IMDSv1 → an SSRF mints its role token → the named S3 buckets / Secrets Manager secrets / KMS keys that role can read. Or a public Lambda → its execution role → the data.
• Google Cloud: a public Compute VM → its service account → the specific Cloud Storage buckets / Secret Manager secrets / BigQuery datasets that SA can read.
• Azure: an internet-reachable VM → its managed identity → the storage / Key Vault / Cosmos / SQL that identity’s RBAC grants.

Each path names the terminal data, not “this role is over-privileged” but “this path reads customer-pii.” Paths are scored by blast radius, and the graph guards against a false all-clear: when the same data is reachable by more than one path, Umbra says so, so cutting one link doesn’t read as “safe.”

Read-proof: evidence, not inference

Most scanners flag a public bucket by reading its policy and guessing. Umbra confirms it: it makes an unauthenticated request for an object and checks for a 200, the exact thing an attacker would do. If a byte comes back with no credentials, the exposure is real; the finding records the confirmed object so a triager can reproduce it in one command. This works for S3, GCS, and Azure blob containers.

Confident-silence guard

The dangerous failure mode for any scanner is confident silence: a collector that succeeds but parses nothing draws no edges and reports a clean cloud that’s full of paths. Umbra guards against it: reachability that can’t be determined is attested, not assumed safe, and coverage is reported per technique family (ran / clean / not-evaluated) so an empty graph is explained, never mistaken for “no paths exist.”

Why it matters

A list of 200 misconfigurations doesn’t tell a team what to fix first. A path that terminates at customer-pii does. And because each end is proven (the entry is internet-reachable, the storage is anonymously readable) the path is an argument you can act on, not a theory to argue about.

How to use it

Run a cloud scan; attack paths surface on the scan page and in the account detail as a chain you can read left-to-right, each with the exact cut to break it.