The Token Names the Host: Recon From a Captured Service JWT

Réseau & Infrastructure Niveau 2/4 ~3 min 2026-08-09

Le défi

Vous avez capturé un JWT de service à service sur un réseau interne. Il est censé être opaque, mais la charge utile d'un JWT n'est que du base64 et se décode sans aucune clé. L'une de ses revendications nomme discrètement un système interne avec lequel le service est autorisé à communiquer. Décodez la charge utile dans l'atelier et soumettez ce nom d'hote interne.

Ce que tu vas apprendre

  • 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

Compétences testées

JWT decodingReconnaissanceToken claim analysis

Prérequis

  • A JWT is three base64url parts: header, payload, signature
  • Standard claims like iss and aud carry issuer and audience

Comment ça marche

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.

Erreurs fréquentes

  • Treating the token as encrypted. It is base64 - decode it directly, no key or cracking required.
  • Reading the issuer instead of the audience. iss is auth.acme; the internal host you want is the aud claim.
  • 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.

Comment s'en protéger

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.

Solution complète

Les membres Pro et Max débloquent la solution complète étape par étape.

Passer Pro

Statistiques de la communauté

105 résolutions
83% taux de réussite
M2F14M3 Premier sang

Hacks du jour associés

20 000+ Hackers 100+ Labs & Cours Gratuit
Commencer Gratuitement