Pivoting Across Three Hosts to Recover a Vault Token and Flag
The challenge
You have a foothold on web01 inside an internal network. A secrets vault is somewhere on the same subnet, but you cannot reach it directly. Scan the network, pivot through the intermediate host with the key you find, recover the vault token, and read the flag the vault returns.
What you'll learn
- Map an internal subnet with nmap to find reachable hosts and ports
- Spot and reuse a leaked SSH private key to pivot to another host
- Recover a service token from a host's deploy notes and history
- Authenticate to an HTTP API with a token header to read a secret
- Explain why network segmentation alone fails when keys and tokens leak
Skills tested
Prerequisites
- Comfortable with ssh, nmap, curl and basic shell commands
- Understand how an SSH private key authenticates a login
- Know that an API token is passed in a request header
How it works
Real internal networks are layered. The host you land on first is rarely the host that holds the prize - it is a stepping stone. Here web01 sits in the DMZ and can talk to the app tier, but the secrets vault on vault03 only accepts requests that already carry a valid token, and that token is supposed to live on the app tier, never on the web node. The challenge is to move from where you are to where the secret is.
The first move is reconnaissance. nmap over the 10.0.0.0/24 segment reveals three live hosts: your foothold, app02 with SSH open on 22, and vault03 with the vault API on 8200. Hitting the vault directly returns 403 missing client token - you can reach it on the network, but you have no credential. The path forward is the intermediate host, and the key to it is sitting on disk: a deploy private key under /var/www/deploy/.ssh/id_rsa that authenticates as deploy@app02.
Once you pivot with ssh -i, the app tier gives up the missing piece. The deploy runbook on app02 documents the exact API call, token and all: curl -H "X-Vault-Token: s.7Hk2mQ9pZ" http://10.0.0.30:8200/v1/secret/data/flag. The shell history confirms the operator ran it the same way. Replaying that request from inside the app tier returns the flag. The whole exercise is a chain - scan, pivot, loot token, authenticate - where each link is only reachable after the previous one.
Common mistakes
- Trying to curl the vault from web01. The vault answers
403 missing client tokenthere - you need the token, and the token never sits on the web node. - Skipping the network scan. Without
nmapyou do not know app02 has SSH or that vault03 even exists; guessing wastes the whole exercise. - Ignoring the SSH key on disk. The deploy key under
/var/www/deploy/.ssh/id_rsais the only way onto app02 - the pivot is mandatory, not optional. - Forgetting the token header. A bare
curlto the vault still fails on app02; the request must carryX-Vault-Tokento be authorised.
How to defend against it
Segmentation slowed the attacker but did not stop them, because the keys and tokens that cross the segments were left readable. The fixes harden each link of the chain:
- Never store a long-lived SSH private key in a world-readable web directory - issue short-lived, certificate-based SSH credentials scoped to a single jump host.
- Keep vault tokens out of deploy notes and shell history - inject them at runtime and use short TTLs so a leaked token expires quickly.
- Restrict the vault to accept tokens only from approved client identities, not just anyone on the subnet who holds the string.
- Monitor lateral SSH and unusual vault reads so a pivot from the DMZ into the app tier raises an alert.
Treat any token found on disk or in history as compromised: revoke it, rotate the deploy key, and review what that identity could reach.
