Blog

Autonomous cloud penetration testing: SSRF, metadata and service-account chains

What it takes for an AI agent to turn one SSRF or one leaked key into cloud initial access on AWS, Azure and GCP — metadata tokens, gopher smuggling, Key Vault and storage exfiltration.

· 8 min read

Cloud penetration testing rarely turns on a single exploit. It turns on a chain: one small foothold — an SSRF, a leaked key, a public bucket — that an attacker walks, patiently, into the identity and data planes. Walking that chain by hand is slow, and the interesting part is not any one step but the decision of which step comes next. That is a good fit for an autonomous agent.

The foothold is almost never the goal

Take a server-side request forgery bug. On a laptop it is a curiosity. On a cloud VM it is a door to the metadata service — the endpoint every instance can reach to mint its own credentials. The agent recognises the host is cloud, pivots the SSRF at the metadata endpoint, and when a naive request is blocked because it cannot set the required header, it smuggles a full raw HTTP request through a gopher:// URL to slip that header in. Out comes a short-lived token. From there it is not a web bug any more; it is cloud access.

Every provider, the same instinct

  • AWS. IMDS token, then enumerate what the instance role can actually do, then privilege-escalate through the IAM edges that role exposes.
  • Azure. A recovered secret from a Key Vault becomes an identity when the password is reused; that identity holds the data-plane role the first account lacked, and the customer table falls.
  • GCP. A service-account token from the metadata server, used directly against the storage API, quietly lists and downloads the objects a public listing would never show.
  • Entra ID. Non-interactive token minting and UPN-derivation turn one contractor password into a tenant foothold.

Gated on evidence, not on guesswork

The dangerous failure mode for an automated cloud test is a false pivot — attacking a plane that is not really there because a name looked cloudy. Darkmoon's cloud agents are artifact-gated: they dispatch only when a concrete positive artifact names the plane — a token, an exposed metadata response, an operator-supplied key — never on inference. It is the same manual-only discipline serious testers already apply to Active Directory.

Proven on public labs

We ran these chains end to end against public training labs — SSRF-with-gopher to GCP initial access, an Azure Key Vault leading to a storage-table breach, and a GCS bucket cracked open — with the agent making every routing decision itself. The write-ups, with the exact calls and responses, are in our research repository.

What autonomy actually buys you

Not magic — coverage and speed. An autonomous penetration testing agent re-runs the same disciplined chain across every account, region and identity without getting bored, surfaces the one path that matters, and hands you a report where each step is proven. You still decide what to do about it.

Full disclosure: Darkmoon is our open-source project (GPL-3.0) — github.com/ASCIT31/Dark-Moon.

Run it against your own lab

Darkmoon is open source (GPL-3.0) and self hosted. Clone it, point it at a target you own, and read every line.