Two NICs, Zero Trust - Pulling Apart a PAC Buried in Critical Infrastructure

A utility operator asked the team to look at Opto 22 programmable automation controllers, devices that bridge SCADA networks and plant networks. Because the hardware is fragile and often cannot be scanned or tested in the field, the researchers began with vendor documentation and public firmware images. That review suggested the programming and configuration interfaces had no authentication, so they built a bench setup and split the work into a programming track and a firmware track.

On the programming side, they captured the vendor's traffic, pulled stored project files off the controller, and rebuilt parts of the transfer in Python. The push path turned out to run a Forth interpreter on the device. They inserted a SOCKS4 proxy written in the controller's scripting language, so the device could forward traffic between its two network interfaces. On the firmware side, they reverse engineered a ColdFire image, found that the integrity check was a chunked CRC with no digital signature, and built a backdoor. They matched the vendor's TCP stack socket functions against an archived copy and ran the implant inside an existing network service.

The team demonstrated a remote path from the SCADA side into the OT side, and found internet-exposed devices through Shodan and Censys. The vendor responded constructively and is working on firmware signing, authentication for its programming language, and an API on newer lines that can disable legacy functions. The main takeaway is that testing the hardware and its firmware can reveal flaws a network-only penetration test would miss, and that older controllers may offer no way to turn off risky features.