Unwrap the C2 Beacon: Reversing Base64 and a Multi-byte XOR
The challenge
A compromised host kept sending short base64 packets to an unknown server. Your sandbox captured one beacon payload below. Reverse engineering of the implant shows it base64-wraps a command after XOR-encrypting it with a repeating key. Recover the plaintext command and submit the flag (HDNA{...}).
What you'll learn
- 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
Skills tested
Prerequisites
- Comfort with base64
- Understanding that XOR is its own inverse
- Familiarity with the idea of command-and-control traffic
How it works
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.
Common mistakes
- 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.
How to defend against it
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.