Proof of concept development¶
Showing what’s possible without actually doing it.
The Patrician has a saying about demonstrations of power: the most effective demonstration is the one you never quite have to perform. The credible threat of action is often more valuable than the action itself, particularly when the action in question might accidentally shut down half the city’s power supply or turn a water treatment plant into an unscheduled chemistry experiment.
Proof of concept development in OT penetration testing is the art of proving we could do something catastrophic without actually doing it.
This is rather more important in OT than in IT. In IT penetration testing, we might actually exfiltrate data (with permission) or actually compromise systems (in a controlled way) to prove impact. In OT, “actually demonstrating” that we can shut down the turbines by shutting down the turbines is the sort of thing that gets people hurt, gets us arrested, and gets the entire concept of security testing banned from the facility for the next decade.
The challenge is demonstrating sufficient proof that stakeholders take the findings seriously, without demonstrating so much proof that we cause actual harm. It’s a delicate balance, like explaining to the Archchancellor that his experimental thaumic reactor has a critical flaw without actually causing it to explode. We need to be convincing enough that he’ll fund the repairs, but not so convincing that we have created a smoking crater where the University used to be.
Understanding safe exploitation boundaries¶
Before writing a single line of exploit code, establish what we are allowed to do and what we are absolutely not allowed to do. These boundaries should be documented, signed off by people with authority, and reviewed by people who understand the actual physical processes involved.
Safe boundaries typically include things like reading data from systems, connecting to services, analysing network traffic, and testing authentication mechanisms against non-production systems. Unsafe boundaries typically include things like writing data to production PLCs, stopping running processes, modifying setpoints, or basically anything that could cause a safety system to activate or a production process to fail.
At UU P&L, our initial rules of engagement said we could “test all systems for vulnerabilities but should avoid disrupting operations”. This was fine in theory but useless in practice because it didn’t specify what “disrupting” meant. Was reading holding registers from a PLC disruptive? What about reading them repeatedly? What about reading them whilst the PLC was also controlling an active chemical process? We needed rather more specific boundaries.
Establish clear operational boundaries¶
Work with operations and engineering to define specifically what’s safe:
Which systems are production versus test?
Which operations are read-only versus write?
Which times are acceptable for testing?
Which physical processes must not be affected?
What happens if something goes wrong anyway?
Document these in the rules of engagement and reference them before every test. “The RoE says this is safe” is much better legal protection than “I thought it would probably be fine”.
Create a safety classification system¶
Not all tests carry equal risk. Classifying our tests:
Green (Safe):
Reading public data
Passive network observation
Testing against simulators
Credential testing on isolated systems
Static analysis of code or configurations
Amber (Proceed with caution):
Reading data from production PLCs
Active scanning of production networks
Testing authentication on production systems
Protocol fuzzing against simulators
Analysing safety system configurations
Red (Requires explicit approval each time):
Any write operations to production systems
Any testing that could trigger alarms
Any testing during critical operations
Testing safety systems
Any testing that requires bypassing safety controls
At UU P&L, we classified “reading the current turbine speed” as green, “reading the turbine speed setpoint” as amber (because it revealed operational information), and “writing a new turbine speed setpoint” as red (because it could actually change physical operations). Before any red test, we had to get explicit approval from operations, confirm that the process was in a safe state, and have someone standing by who could intervene physically if needed.
Read-only demonstrations¶
The safest form of proof of concept is demonstrating what we can read rather than what we can change. If we can read process values, configurations, and control parameters, we can often prove impact without actually modifying anything.
Demonstrate data access¶
Reading data from an OT system can demonstrate several impacts:
Intellectual property theft (process parameters, recipes, configurations)
Competitive intelligence (production rates, efficiency metrics)
Pre-attack reconnaissance (system states, normal baselines)
Safety information leakage (alarm thresholds, safety limits)
🐙 Proof of Concept: Read and display sensitive information.
This proof of concept demonstrates that we can access sensitive operational data, but it never writes anything. We can show stakeholders the output and explain that if we can read these values, a malicious actor could also read them, and could use that information to understand the system before planning an attack.
Demonstrate configuration analysis¶
If we have extracted configurations (ladder logic, HMI projects, SCADA configurations), we could show what an attacker could learn:
🐙 Proof of Concept: Ladder Logic Security Analysis
Simulation environments¶
The most convincing proof of concept is one that actually works, just not against production systems. Build a simulation environment that mirrors the production environment closely enough to demonstrate attacks, but safely enough that nothing real breaks.
Hardware simulation¶
If we have access to spare PLCs or other OT devices, build a test rig:
Test environment:
Same model PLC as production
Same firmware version
Same ladder logic (or simplified version)
Connected to HMI simulator or test HMI
No physical process connected
At UU P&L, we borrowed a decommissioned Turbine PLC, loaded it with a copy of the production ladder logic, and connected it to a HMI running on a laptop. We could then demonstrate attacks against the real hardware without any risk to actual turbines.
Software simulation¶
If hardware is not available, 🐙 software simulations can demonstrate many attacks.
Video proof of concepts¶
When we can not safely perform an attack against real systems, record a video of the attack against a simulator. This provides visual evidence that is more compelling than just a written description, without the risks of testing production systems.
Create professional demonstrations¶
A good PoC video should:
Clearly identify that it’s a simulation
Show the initial system state
Execute the attack with explanation
Show the resulting system state
Explain the production impact
Recording structure¶
[Opening screen]
"Proof of Concept: Unauthorised Turbine Control"
"Demonstration against SIMULATOR ONLY"
"UU P&L Penetration Test - December 2024"
[Screen 1: Network diagram]
Show the attack path from entry point to target
Highlight each step of lateral movement
"This demonstrates the attack path available in production"
[Screen 2: Normal operations]
Show HMI displaying normal turbine operation
Speed: 1500 RPM, Temperature: 72°C
"Current production state: Normal operations"
[Screen 3: Attack execution]
Terminal window showing the attack script
Execute the script step-by-step with commentary
Show each Modbus command and response
[Screen 4: Impact]
Show HMI displaying changed values
Speed setpoint now 0 RPM
Alarm indicators activating
"In production, this would cause emergency shutdown"
[Screen 5: Impact explanation]
Text overlay explaining consequences:
- Production loss
- Equipment stress
- Safety system activation
- Recovery time required
[Closing screen]
"This vulnerability exists in production"
"No authentication required for Modbus commands"
"Recommendation: Implement authentication and network segmentation"
At UU P&L, we created a video showing the entire attack chain from initial access to final impact. We started with a screen recording of connecting to the guest Wi-Fi, showed the pivot to the contractor laptop, demonstrated the lateral movement to the engineering workstation, and finally showed the connection to the PLC simulator and the execution of the attack. The video ran for eight minutes and was far more convincing than any written report could have been.
Documentation of theoretical impacts¶
When we can’t demonstrate an attack even in simulation (perhaps because we don’t have access to the specific hardware or the attack would require physical presence we haven’t been granted), document the theoretical impact with sufficient detail that stakeholders understand the risk.
Structure theoretical impact documentation¶
🐙 This level of documentation provides enough detail that stakeholders can understand the risk even without seeing a live demonstration. We have explained what is possible, why it is possible, what the impact would be, and what can be done about it.
Responsible disclosure considerations¶
If we discover vulnerabilities in commercial products during our testing, we have ethical obligations beyond just reporting to our client.
Vendor notification¶
If the vulnerability is in a product used by other organisations:
Notify the vendor first (before public disclosure)
Provide sufficient detail that they can reproduce
Allow reasonable time for patching (typically 90 days)
Coordinate disclosure with vendor
ICS-CERT coordination¶
For critical infrastructure vulnerabilities, notify the authority:
They can coordinate with vendors
They can issue advisories to other users
They can help with responsible disclosure timeline
Client notification boundaries¶
Our client needs to know about the vulnerabilities we found, but we should:
Not provide full exploit code unless necessary
Consider whether the report might be shared
Redact sensitive details if report will be widely distributed
Ensure exploits are not trivially weaponisable from report alone
At UU P&L, we discovered a zero-day vulnerability in a popular industrial firewall. The vulnerability allowed authentication bypass via a crafted HTTP request. We:
Notified the vendor immediately with proof of concept
Notified ICS-CERT with coordination details
Provided our client with detailed mitigation steps
Did not include full exploit code in the written report
Agreed on 90-day disclosure timeline with vendor
Published advisory after patch was available
The vendor patched within 45 days, we publicly disclosed at 90 days, and UU P&L received recognition for responsible disclosure. Everyone wins, except attackers who had a slightly smaller attack surface to work with.
The balance of proof and safety¶
The fundamental tension in OT penetration testing proof-of-concept development is this: we need to prove that something dangerous is possible without actually doing the dangerous thing. It’s like proving we could rob a bank by showing the vault’s blueprints, demonstrating that we can pick the lock on a replica, and explaining our exit strategy, all without actually taking any money from the actual bank.
This requires more creativity than IT penetration testing, where “proof” often means “I actually did it and here’s the data I exfiltrated”. In OT, proof means “I could have done it and here’s everything that makes that claim credible short of actually doing it”.
The more evidence we can provide short of actually manipulating production systems, the better. Simulator attacks are better than theoretical descriptions. Videos are better than static screenshots. Detailed technical analysis is better than “trust me, this would work”. But never, ever cross the line into actually doing something that could cause harm, no matter how certain we are that it would be safe. The moment something goes wrong, “I was sure it would be fine” stops being a defence and becomes evidence of negligence.
Document everything we can safely demonstrate, explain clearly what we can’t safely demonstrate and why, and trust that if we have done our job properly, the stakeholders will understand the risk even without seeing production systems fall over. If they don’t believe us without a live demonstration, they’re not going to respond appropriately to the findings anyway, and demonstrating on production systems will not fix that particular organisational problem.