Pivoting Across Three Hosts to Recover a Vault Token and Flag
Le défi
Vous avez un point d'appui sur web01 dans un reseau interne. Un coffre de secrets se trouve quelque part sur le meme sous-reseau, mais vous ne pouvez pas l'atteindre directement. Scannez le reseau, pivotez via l'hote intermediaire avec la cle que vous trouvez, recuperez le jeton du coffre et lisez le drapeau renvoye par le coffre.
Ce que tu vas apprendre
- 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
Compétences testées
Prérequis
- 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
Comment ça marche
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.
Erreurs fréquentes
- 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.
Comment s'en protéger
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.
