Unwrap the C2 Beacon: Reversing Base64 and a Multi-byte XOR
Le défi
Une machine compromise envoyait sans cesse de courts paquets base64 vers un serveur inconnu. Votre bac à sable a capturé une charge utile de balise ci-dessous. La rétro-ingénierie de l'implant montre qu'il encode une commande en base64 après l'avoir chiffrée par XOR avec une clé répétée. Récupérez la commande en clair et soumettez le flag (HDNA{...}).
Ce que tu vas apprendre
- Identify base64 as the outer transport layer of beacon traffic
- Recover plaintext from a repeating-key XOR with a known key
- Distinguish a multi-byte XOR key from a single-byte one by its output
- Peel stacked transforms in the correct inverse order
- Reason about why a hardcoded XOR key gives C2 no real confidentiality
Compétences testées
Prérequis
- Comfort with base64
- Understanding that XOR is its own inverse
- Familiarity with the idea of command-and-control traffic
Comment ça marche
A command-and-control beacon is just a small, regular message an implant sends home. Authors almost never use real cryptography for it - the binary would have to ship the key anyway - so they reach for a repeating-key XOR and base64 the result so it survives as printable text over HTTP. That keeps the payload out of a casual strings dump but does nothing against an analyst who has the sample.
Peel the layers in reverse. The captured packet is printable base64 ending in =, so decode that first to get the raw XOR-encrypted bytes. Then XOR those bytes with the implant's key. XOR is symmetric, so the same operation with the same key undoes the encryption, because A XOR B XOR B = A. The key here is the six bytes beacon, repeated across the message. Recognising it as multi-byte rather than single-byte is the real step up at this difficulty: a one-byte XOR leaves a tell-tale repeating structure this output does not have.
In the workbench, add From Base64, then XOR with key beacon, and the command resolves live. The remaining palette operations (hex, Vigenere, ROT, atbash, reverse, URL-decode) are decoys whose input shapes never fit the data at any stage.
Erreurs fréquentes
- XOR-ing the base64 text directly. Base64 is the outer layer; decode it before XOR-ing.
- Assuming a single-byte key. A one-byte XOR will not produce readable text here - the key is the word 'beacon'.
- Brute-forcing the key. Reverse-engineering of the implant already gave you the key; read the brief first.
- Adding decoys. hex-decode or Vigenere look plausible but their inputs do not match - check the data shape before each op.
Comment s'en protéger
For defenders, the lesson is that base64-plus-XOR is an obfuscation pattern you should be able to peel on sight, both when hunting beacons and when reviewing your own code for misplaced trust. A hardcoded XOR key in a binary is recoverable by anyone with the sample, so it protects nothing.
- Hunt for short, regular outbound base64 payloads and auto-XOR-scan them during triage.
- Extract hardcoded keys from captured implants and use them to decode historical C2 traffic.
- Never treat a static XOR key as confidentiality - use authenticated encryption with a managed key when it actually matters.
- Alert on beaconing by timing and destination regularity, not only on payload content.