The Token Names the Host: Recon From a Captured Service JWT
The challenge
You captured a service-to-service JWT on an internal network. It is meant to be opaque, but a JWT payload is just base64 and decodes without any key. One of its claims quietly names an internal system the service is allowed to talk to. Decode the payload in the workbench and submit that internal hostname.
What you'll learn
- Understand that a JWT payload decodes to plain claims with no key
- Identify the iss, aud, and scope claims in a service token
- Extract an internal hostname from the audience claim
- Explain how captured tokens leak environment intelligence
- Recognise why service tokens must be short-lived and sent over encrypted channels
Skills tested
Prerequisites
- A JWT is three base64url parts: header, payload, signature
- Standard claims like iss and aud carry issuer and audience
How it works
Service-to-service authentication often uses JWTs, and like any JWT the payload is base64url - encoded, not encrypted. Anyone who captures the token (by sniffing internal traffic, reading a log, or pulling it from a config) can decode the claims instantly without a key.
Decoding this token gives {"iss":"auth.acme","aud":"vault.internal.acme","scope":"read"}. Standard claims are a recon goldmine: iss (issuer) names the authentication server, scope hints at what the holder may do, and aud (audience) names the service the token is meant for. Here the audience is vault.internal.acme - an internal hostname an outside attacker would have no other way to learn. That single string tells them a secrets vault exists, what it is called, and that a path to it exists on the network.
No forging is needed for this kind of leak. The value of a captured token is partly the access it grants and partly the intelligence it carries: hostnames, endpoints, account ids, and scopes that map out the environment for the next move.
Common mistakes
- Treating the token as encrypted. It is base64 - decode it directly, no key or cracking required.
- Reading the issuer instead of the audience.
issisauth.acme; the internal host you want is theaudclaim. - Adding a scheme or path. The answer is the bare hostname
vault.internal.acme, not a URL. - Trying to forge the token. This is a read-only recon task; nothing needs changing.
How to defend against it
Assume every claim in a service token is readable by anyone who intercepts it, and minimise what it reveals.
- Transmit tokens only over TLS so they cannot be sniffed off the wire in the first place.
- Keep service tokens short-lived and tightly scoped so a captured token is quickly useless.
- Avoid putting sensitive internal hostnames or topology hints in claims where an opaque identifier would do.
- Monitor for tokens used from unexpected sources, which can flag a capture-and-replay.