Posted on 2026-09-02by Matt Strahanin Industry
Five years ago I had a moment where I was staring at my screen with only one thought in my mind: This is going to be super annoying.
I was tasked with doing penetration testing of a healthcare application that would be running in hospitals. The application talked back to the server with what looked like gobbledegook and I was looking at it, realising I would have to figure out what all of this random nonsense meant.
I can be honest now, can’t I? If I wasn’t being paid to hack that app I’d have definitely gone “that is way too much trouble” and left it alone. Analysing a non-standard binary protocol is annoying at the best of times. It relies on a bunch of careful analysis, trial and error, keeping track of what each number could possibly mean, and carefully writing code because you know a single typo will ruin everything.
Back then, an attacker would have left it alone and put it in the “too hard” bucket. Now? It’s all different. Everything about this situation has changed with LLMs and AI. It has been so transformed by the incredible pattern recognition of AI that it’s no longer hard - analysing a binary protocol has become a simple problem.
The end of “security through obscurity”
Security through obscurity was a bad thing*. I put an asterisk there because, even though it’s what you’d hear again and again in your security courses, in practice security through obscurity works and is highly effective.
In essence, all of security is attempting to make the attacker put your system in the “too hard” bucket. With enough resources, time, money, and access you can hack any system you want. There’s no such thing as absolutely secure, just secure enough to stop the threats you’re facing and make them target something else. A traditionalist would scoff at me for saying this, but obscurity is just one of those factors that make something harder to hack and that makes threat actors more likely to try and hack something else.
For that healthcare application, the only reason I went to the trouble of analysing that binary protocol was because that’s what the client wanted. I did the work to find glaring issues with authentication and authorisation in that silly protocol, cursing the coders the entire time. At the same time, though, it was likely that the obscurity of the protocol would have protected the application despite the vulnerabilities that lay hidden. Finding those vulnerabilities would have required specialised skills and a lot of patience.
I was recently facing a similar kind of situation. This time it wasn’t a custom written binary protocol, but a mobile application with mild obfuscation applied. Nowadays I don’t even hesitate - I fired up Anthropic Claude and made it take a look. Suddenly the layers of obfuscation and obscurity don’t even affect me any more. The AI just removes that layer entirely as if it weren’t there at all.
Industrial control systems under threat like never before
This is an underrated shift that AIs have brought forward. We’ve now gotten to the end of security through obscurity being effective. It brings monumental changes to whole industries and the way they approach cyber security. While I’ve focused on binary protocols and obfuscation so far, the biggest change is with SCADA and industrial control systems. They are now at risk in a way they never were before.
Previously, if attackers saw an industrial control system that had some kind of custom MODBUS or binary protocol it was often put into the “too hard” basket just as that damned healthcare app I was testing. Not any more. Now we just get out our AI and ask it to write a script that will interact with that specific model. That is then what we can analyse and assess, figuring out weird edge cases and potential vulnerabilities that we could use to break it.
The custom factor that used to be a virtue of sorts of these systems suddenly becomes a drawback. They weren’t as well known and assessed as your standard third party off-the-shelf software, but that just means their vulnerabilities haven’t been assessed either. You’re more likely to find critical issues that have just been hidden under that layer of obscurity. It’s gone from “too hard” to “too easy”!
For attackers, that becomes a simple investment analysis. Is the trouble of analysing these systems worth the potential monetisation opportunities? Before with the layers of obscurity the answer was a clear no. Now, I’m not so sure.
The threat model has now changed for all organisations with industrial control systems. Now that industrial control systems can’t rely on security through obscurity any more, their often critical vulnerabilities are laid bare to attackers, allowing them to target them in their ransomware and extortion attacks.
We’re seeing this more and more, with industrial control systems being hacked directly. Just a few days ago US authorities alerted on attacks on water supplies. Last year Asahi’s logistics systems were down from a cyber incident leading to ongoing outages and costs. With the barrier for entry of hacking industrial control systems being slashed, it’s likely we’ll see more and more of these attacks.
The exposure of industrial control systems only heightening
This is all coming at a time where organisations have moved forward with the integration of IT and OT environments.
In the past, organisations with industrial technology often had a split between Information Technology, where your servers and workstations would live, and Operational Technology, where your industrial control systems and Programmable Logic Controllers (PLCs) would live. These two environments would be managed by different teams and use different sets of networking devices, security controls, and procurement practices.
Personally, as someone who has had experience in both IT and OT, I’ve always been sceptical of the need for separation in how they’re managed. I know OT is about solving engineering problems rather than informational systems problems, but at their heart they’re still computers.
As the complexity of OT infrastructure raises, especially when it comes with management reporting and interconnected logistics, these OT systems need to be connected to the organisational network. Really it’s just about solving problems - you might want, for instance, the throughput of one process of a factory to be dependent on the stock being held at the warehouse. Automating this requires both the warehouse and the factory to be interconnected in some way. Nowadays that means the internet and SD-WANs. This means the separation of IT and OT becomes infeasible and the exposure of the OT environment is increased immensely.
The expectation for factories is to run 24/7 with downtime only being dependent on the supply chain. Efficiency leads to slim expectations for downtime and maintenance.
The opportunity for extortion
I’m going to peer into the future a little bit. The compromises that we’ve seen lead to downtime have often been compromises of IT systems. With healthy backup and restoration processes, though, IT systems are often easier to restore from backups and the internal staff are used to being able to restore these systems without major issues.
This is just not the case with OT systems and industrial control systems. They’re often harder to restore and there’s a safety aspect that cannot be ignored. Usually restoration could include retrieving images and configurations from the vendor and could even need a physical trip from the vendor’s technicians. Targeting these systems in a ransomware attack could make it more difficult to recover and to avoid paying the ransom.
The OT and industrial control systems weren’t a target simply due to it being too hard. Ransomware scripts would have to be specifically written for each system and the layer of obscurity made it easier for the ransomware operator to look elsewhere. I don’t think that’s the case any more. I see AIs being used to target the individual OT systems with automatically generated ransomware scripts.
What should organisations do to defend themselves?
In the new age of AI, the fundamentals of security have become more and more important. Organisations can work to further improve the security of their internal OT environment by creating layers of protection, limiting the access to the OT systems, and solidifying their threat model.
Know your attack surface and exposure
Each organisation with OT infrastructure needs to deeply understand their attack surface and threat models.
I might be a bit biased here, but personally I find the only way to know your attack surface is to try and break it. When going into organisations with a heavy OT environment I find that they have assumptions about what can and cannot get through to their OT systems that are optimistic at best. The air gaps they think they have tend to become a bit less air gappy when you look closely. The strict separation of access control tends to rely a lot more on their internal Active Directory environment, potentially even online Microsoft 365 accounts, than they were expecting. They end up being in the situation where a good phishing attack can bring down their critical infrastructure.
Once you have practically mapped out your exposure, you can then work towards mapping the dependencies and limiting the attack surface of the environment.
Assume your OT systems are potentially vulnerable in your assessments
With the layer of obscurity now taken away, the underlying vulnerabilities and security flaws of OT systems are now much easier for attackers to take advantage of. Even if you don’t know explicitly that there are vulnerabilities in your OT systems, it’s usually safer to just assume they’re there. We would then carry that assumption into our threat models, our security architecture, and the overall assessment of the attack surface.
Once you’ve just accepted the vulnerability of OT devices, you can then take steps to implement network based access controls that prevent any communication with the OT devices unless the source of that communication has been explicitly authorised. This could be through jump hosts, API gateways, network based access control, or proxy channels. The point of this is to use the standard, reliable security controls that are more thoroughly tested and understood to prevent attackers from even getting network access to the less understood OT devices.
You can use LLMs yourself, but use them carefully!
While it might be tempting to just say “release the agents”, this is one area where you absolutely must have someone skilled who can appropriately direct and interact with the agents. This is an area where the wrong hallucination from an LLM can bring down operations in a factory or cause business operations to completely halt. The wrong hallucination from an LLM can rewrite firmware on a PLC or change the configuration of a controller in a way that would require a full safety certification to start running again.
This means at all times LLMs should be governed by a skilled consultant with appropriate restrictions and guard rails in place. While LLMs have their place in the defensive side of things, they must be used carefully and with complete understanding of the potential risks and impacts.
We have been using large language models in our penetration testing and have been identifying where they help and limiting the risks. Understanding those risks are key to appropriately leveraging LLMs.
Volkis is here to help
If you need help with assessing your internal OT environment, please reach out. You can contact us here.
About the author
Matthew Strahan is Co-Founder and Managing Director at Volkis. He has over a decade of dedicated cyber security experience, including penetration testing, governance, compliance, incident response, technical security and risk management. You can catch him on LinkedIn.
If you need help with your security, get in touch with Volkis.
Follow us on Twitter and LinkedIn