How LinPEAS reports cloud environments

How cloud detection works#

LinPEAS probes the well-known instance metadata endpoints — most famously http://169.254.169.254/ — and provider-specific signals (hypervisor UUIDs, DMI data). If a metadata service answers, LinPEAS walks what it exposes: instance identity, network config, user-data scripts, and, where the provider allows, temporary credentials attached to the instance's IAM role or managed identity.

How to read the cloud section#

• A detected provider line tells you which cloud you are in — this reshapes the whole engagement.
• Temporary credentials (AWS keys, GCP tokens, Azure tokens) are the crown jewels: they can grant API access far beyond the compromised host.
• User-data scripts often contain secrets, bootstrap credentials and internal hostnames.
• If LinPEAS reports no cloud context, the host is on-prem or metadata is blocked — both are useful facts.

Verify manually (authorised scope only)#

# AWS example — authorised testing only
curl -s http://169.254.169.254/latest/meta-data/ 2>/dev/null | head
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null
# GCP example
curl -s -H 'Metadata-Flavor: Google' http://metadata.google.internal/ 2>/dev/null | head
# Azure example
curl -s -H 'Metadata: true' 'http://169.254.169.254/metadata/instance?api-version=2021-02-01' 2>/dev/null | head -c 400

Handling cloud credentials responsibly#

1. 1

2. 2

3. 3

4. 4

How to fix cloud findings (defensive)#

• Enforce IMDSv2 on AWS (token-required metadata) to block simple SSRF-style credential theft.
• Apply least-privilege IAM roles: an instance role should do exactly what the workload needs, nothing more.
• Never put secrets in user-data scripts — use a secrets manager.
• Block the metadata endpoint where workloads do not need it (host firewall rules).
• Monitor CloudTrail / Activity Logs for credential use from unexpected places.
• Rotate any credential LinPEAS surfaced during an audit, then re-run to confirm.

The SSRF-to-metadata attack path#

The reason metadata endpoints matter offensively: any server-side request forgery (SSRF) in a web app running on the instance can be pointed at 169.254.169.254 to steal the instance's credentials — no shell needed. LinPEAS finding reachable metadata on a host tells you the same endpoint a web vulnerability could reach:

1. Attacker finds SSRF in the app (e.g. a URL-fetch feature).
2. Requests http://169.254.169.254/latest/meta-data/iam/security-credentials/ through it.
3. Receives temporary AWS keys for the instance role.
4. Uses them from anywhere — the blast radius is the role's permissions, not the host.

This is why cloud metadata is the highest-blast-radius section of a LinPEAS report, and why defenders treat metadata access as a first-class control.

Per-provider hardening notes#

What LinPEAS does not do here#

Honest limits of the cloud section, so you scope correctly:

• It enumerates what the metadata endpoint exposes — it does not brute-force hidden endpoints or bypass IMDSv2.
• It does not assess your IAM policies — an over-permissive role looks the same as a tight one until you test it (in scope).
• It cannot see other instances' metadata — only the host it runs on.
• On-prem hosts show an empty cloud section — that is a valid negative result, not a failure.
• For full cloud posture, pair LinPEAS with cloud-native tooling (Prowler, ScoutSuite, provider Security Hubs).

Credentials vs metadata: which to chase first#

When the cloud section shows both instance metadata and a local credential (an .env key, a history password), triage the cloud credential first: its blast radius is the whole account, while the local credential is one host. Then work the local credential with the normal credential workflow. When in doubt about scope, ask before touching either.

Related: containers (ECS/EKS overlap), is LinPEAS safe?, credential discovery.