Category: Forensics / Network Difficulty: Medium
To connect to the Matrix, Neo and his friends are using a new portal for jacking in. However, a legacy portal that's vulnerable remains active. Recently, someone has successfully accessed the system through it, and you need to identify the user.
Flag format:
HACKDAY{secret@user@password}
In the challenge directory:
$ ls -al
total 304
drwxr-xr-x 2 fox fox 4096 Jan 24 12:41 .
drwxr-xr-x 3 fox fox 4096 Jan 24 12:41 ..
-rw-rw-rw- 1 fox fox 7714 Jan 23 02:29 gateway.bak
-rw-rw-rw- 1 fox fox 291406 Jan 23 02:29 LAN_Traffic.pcapFile types:
$ file *
gateway.bak: XML 1.0 document, ASCII text, with very long lines (7692)
LAN_Traffic.pcap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 262144)gateway.bak— looks like a pfSense backup / configuration, but its content is base64-encoded XML.LAN_Traffic.pcap— packet capture containing LAN traffic (likely VPN/RADIUS traffic as hinted by the description).
Opening gateway.bak:
$ cat gateway.bak
<?xml version="1.0"?>
PHBmc2Vuc2U+Cgk8dmVyc2lvbj4yNC4wPC92ZXJzaW9uPgoJPGxhc3RjaGFuZ2U+PC9sYXN0Y2hhbmdlPgoJPHN5c3RlbT4KCQk8b3B0aW1pemF0aW9uPm5vcm1hbDwvb3B0aW1pemF0aW9uPgoJCTxob3N0
...
[very long base64 blob]
...
PC9wZnNlbnNlPgo=The first line is a normal XML header, then the rest is clearly base64.
We decode everything except the XML header line:
$ tail -n +2 gateway.bak | base64 -d > gateway.xmlgateway.xml is now a readable pfSense configuration file.
Looking through the XML, we find:
-
L2TP/IPsec VPN configuration.
-
Two RADIUS authentication servers defined:
NPS-AD-VPNusing MSCHAPv2 (modern, more secure).NPS-AD-Legacyusing PAP (legacy, weak, vulnerable — matches the challenge story).
We also see some test credentials and shared secrets.
Example (simplified):
- One server with secret
123456(standard test value). - Another, more interesting one with:
<!-- Rotation to the forbidden --!>
<radius_secret>Y3t4plBar!fa3b</radius_secret>This is clearly the “legacy” secret the challenge is hinting at.
The comment Rotation to the forbidden suggests ROT13.
Applying ROT13 to that secret:
$ echo 'Y3t4plBar!fa3b' | tr 'A-Za-z' 'N-ZA-Mn-za-m'
L3g4cyOne!sn3oSo the actual RADIUS shared secret for the legacy server is:
L3g4cyOne!sn3o
The literal string before ROT13 (Y3t4plBar!fa3b) is just an obfuscated form.
We know from the config and story:
- There is a legacy RADIUS-based VPN portal.
- Protocol: RADIUS (UDP/1812) with PAP (password susceptible to recovery).
- Our task is to find who successfully authenticated through it, and with what credentials.
We are interested in RADIUS Access-Request packets:
$ tshark -r LAN_Traffic.pcap -Y "radius.code == 1" \
-T fields -e radius.User_Name -e radius.User_Password
trinity
tank
theoracle
cypher
cypher ��U��\n��A�
cypher
cypher /�9�&�Ͷ��͝k0�
cypher
cypher #����o¸�ĝ=���
n3o
n3o �=�,ۣX3ɫ\t�>
cypher
neo
switch
morpheusObservations:
- Multiple users from the Matrix universe:
trinity,tank,theoracle,cypher,n3o,neo,switch,morpheus. - For some entries,
User_Passwordappears as binary-looking junk. That is the RADIUS encrypted password.
To decrypt it, tshark needs to know the RADIUS shared secret.
We try providing the original secret from XML (Y3t4plBar!fa3b) to tshark:
$ echo '192.168.58.101:Y3t4plBar!fa3b' > radius_secrets
$ tshark -r LAN_Traffic.pcap -Y "radius.code == 1" \
-o 'radius.shared_secret:Y3t4plBar!fa3b' \
-T fields -e radius.User_Name -e radius.User_Password
trinity
tank
theoracle
cypher
cypher ��U��\n��A�
cypher
cypher /�9�&�Ͷ��͝k0�
cypher
cypher #����o¸�ĝ=���
n3o
n3o �=�,ۣX3ɫ\t�>
cypher
neo
switch
morpheusResult: still encrypted garbage. So this is not the correct shared secret used in the capture.
We now use the secret derived from the comment Rotation to the forbidden:
$ echo '192.168.58.101:L3g4cyOne!sn3o' > radius_secrets
$ tshark -r LAN_Traffic.pcap -Y "radius.code == 1" \
-o 'radius.shared_secret:L3g4cyOne!sn3o' \
-T fields -e radius.User_Name -e radius.User_Password
trinity
tank
theoracle
cypher
cypher cypher
cypher
cypher cypher
cypher
cypher cypher
n3o
n3o ImTheOne4242!!
cypher
neo
switch
morpheusNow tshark can successfully decrypt PAP passwords:
-
For user
cypher, the password fields decrypt tocypher(as expected, he is not very imaginative). -
For user
n3o, one Access-Request entry shows:- User_Name:
n3o - User_Password:
ImTheOne4242!!
- User_Name:
This clearly corresponds to the successful login via the legacy portal.
The challenge asks:
someone has successfully accessed the system through the legacy portal, and you need to identify the user.
From the decrypted RADIUS traffic on the legacy server:
- Shared secret (legacy portal):
L3g4cyOne!sn3o - User who logged in:
n3o - Password used:
ImTheOne4242!!
This matches the Matrix theme (Neo being “The One”).
Flag format:
HACKDAY{secret@user@password}
We use:
secret→L3g4cyOne!sn3ouser→n3opassword→ImTheOne4242
(Depending on the exact expected format, some instances keep or drop the trailing !!. In the working solution used here, the flag is:)
HACKDAY{L3g4cyOne!sn3o@n3o@ImTheOne4242}
-
Decode pfSense backup (
gateway.bak) intogateway.xmlvia base64. -
Inspect RADIUS/VPN configuration:
- Identify a legacy RADIUS server using PAP.
- Observe the commented hint
<!-- Rotation to the forbidden -->andradius_secretvalue.
-
Apply ROT13 to
Y3t4plBar!fa3b→L3g4cyOne!sn3o. -
Provide this secret to tshark/Wireshark to decrypt RADIUS User-Password fields.
-
Inspect Access-Request packets:
- Find user
n3owith cleartext passwordImTheOne4242!!.
- Find user
-
Build the flag as
HACKDAY{L3g4cyOne!sn3o@n3o@ImTheOne4242}.
This demonstrates how misconfigured legacy authentication (PAP + shared secret) combined with poor secret management and embedded hints in configuration backups lead directly to credential disclosure from network captures.