Imagine a facility that powers your home, purifies your water, or manages critical infrastructure. What if it's digital defenses weren't quite as robust as they seem.
Yeah, it's a pretty critical thought.
Today we're taking a deep dive into the fascinating, definitely high stakes world of pen testing industrial control systems or icsm HM. And this isn't just about like standard IT computers. It's about the systems that literally make the world run.
That's right, the physical stuff.
Our main guide for this exploration is an Ethical Hackers Guide pen Testing Industrial Control Systems by Paul Smith. This book, it takes us on a journey through analyzing, compromising, mitigating, and securing these industrial processes.
It draws on a lot of experience to in nearly twenty years in automation control and industrial cybersecurity. Plus we're pulling in insights from others like Dimitri Komenko, who has tons of experience in OTIS security for major companies.
So our mission today is really to unpack the critical techniques ethical hackers used to test the security of these vital systems. We'll look at everything from setting up a virtual lab which is key, all the way to the real world implications if someone does manage a successful breach. We want to give you the essential nuggets you know, to understand this field quickly. Okay, let's unpack.
This sounds good and it's a truly vital area because, like you said, these industrial control systems are the very backbone of our modern world, think energy grids, water utilities, advanced manufacturing plants right everywhere. Securing them isn't just about data protection in the traditional sense. It's fundamentally about ensuring the physical world functions safely, continuously. The stakes, frankly couldn't be higher.
Absolutely, And the author Paul Smith, he actually got into this field by tackling what he called red herring problems. Oh yeah, like what well, things like weird measurement imbalances from flair sensor saturation or database migration mishaps that had unexpected knock got eifacts.
Ah, okay, operational problems that turned out to have a cyber.
Angle, exactly, real hands on issues that kind of nudged him into understanding the security side of these industrial systems. It really highlights how often the most critical vulnerabilities pop up in well, unexpected places.
That's so true. And what's fascinating. Often the deepest vulnerabilities lie in areas that are completely overlooked. I often ask IT and OT teams this, who truly controls the virtualization server where your critical application lives, you know, the ESX host or whatever. Oh yeah, and then what is your total exposure if that core virtualization management system like v center gets compromised.
I can imagine the looks on their faces.
The answers are almost universally shocking, sometimes terrifying. It reveals these fundamental security gaps in even large, supposedly well resourced organizations. Wow, it's just a stark reminder of how interconnected everything is and how much can rely on a single, often quite vulnerable component.
That is a chilling thought. So okay, given how complex and risky these line systems are, Yeah, what's the very first thing an ethical hacker does? You know, the non disruptive step to even start understanding them?
Right? Well, the absolute first step is building a safe, contained environment. You obviously can't just start poking around critical infrastructure in the real world. Okay, so the book really emphasizes the importance of creating your own virtual lab. This deep dive isn't just theory it's about getting hands on experience, but without risking a real world incident.
Okay, but how do you even begin to simulate something as complex as like an entire factory or power plant in a lab.
Well, the foundation is virtualization. Using something like the VMware ESXi hypervisor lets you create a virtual supervisory, control and data acquisition environment, a SCATA.
Environment, like a digital twin sort.
Of kind of, yeah, a scaled down but functional digital version of a real system. So inside this virtual world, you might spin up, say a nUbuntu server to act as a pseudo programmable logic controller a PLC, and maybe also as a PSEUDOSCATA server itself. Okay, Then you'd include a Windows engineering workstation because that's common in real environments, and critically a Kali Linux attack box that's your offensive toolkit.
And the network inside the lab it's not just one flat network. Is that you try to mimic a real industrial setup exactly right.
The setup often follows what's called a quasi perdue model. It's a theoretical framework, but it's all about segmenting the industrial network into different layers. Layers like from the top level enterprise it network down through control levels right down to the physical process layer.
And why is that layering so important?
Well, it's critical because it's designed to contain breaches. The idea is to prevent an attack that starts in the IT layer from immediately jumping down and impacting the critical physical processes below. So the lab lets you simulate and test those real world security boundaries.
That makes sense. What's really clever, though, is how you bridge the virtual and the physical. Even with all this virtualization you made, real hardware comes into play.
Yes, absolutely. For instance, a Coyo click PLC, specifically the co ten Ard model is a popular choice for labs.
Why that one, It's.
Relatively affordable, It has an Ethernet port for network comms, and the engineering software is free. Crucially, it lets you link your virtual processes to physical io like literally turning a light on and off exactly, you can wire up a light or a small motor. It provides that tangible feedback and gives you a much deeper understanding of how these commands translate into real world actions.
That's fascinating. But even in these setup phases just getting the software and hardware ready, are there overlook vulnerabilities that ethical hackers find even before they start any active testing.
Oh, absolutely, take the software for that Coyo click PLC the installation software. Something the book points out is that it often doesn't provide a cryptographic hash for a verification, you know, like an MD five or SAHA hash to check if the download is legit.
Ah, okay, so you can't be sure you got the real software precisely.
And this is a crucial detail because it opens the door to something called a watering hole attack. Watering hole, Yeah, an attacker could poison that software package, maybe alter it to include malware, and then host it on a compromise website that engineers might visit to download.
It, like a supply chain attack.
Almost exactly like that. We saw this kind of thing with solar winds. Right. The potential fallout from something like that happening in an industrial context it could be devastatingly wide.
That's a significant warning. So, okay, before an ethical hacker even touches the network properly, they need to gather intelligence. How do they go about that? What's the process?
Right? That's where open source intelligence or ostent becomes absolutely invaluable. It's all about finding publicly available information just googling. Well, yes, but it's more advanced. Ethical hackers use specific search techniques sometimes called Google dorking or Google hackings dorking.
Yeah.
It involves using specific commands within search and commands like siteineural, dot file type to filter results and glean sensitive details that are out there, publicly available but often overlooked.
So for you, the listener, the key insight here isn't just knowing these tools exist. It's realizing that in the ICs world, what's publicly available can sometimes paint an alarmingly complete picture of critical infrastructure vulnerabilities long before an attacker even needs to type a command.
That's it. You can easily build a profile of a target company, figure out its industry, maybe even identify specific ICs vendors. It uses like finding mentions of Schweitzer Engineering Laboratories or SEL, which is really common in the energy sector.
And LinkedIn too that seems more professional networking.
Oh, LinkedIn is an incredibly powerful ocent source. Think about it, over seven hundred and forty million users.
Wow.
You can quickly uncover company size, industry specific technologies mentioned in job descriptions or profiles, even find key employees by title or keyword searching for Stata engineer or maybe a specific vendor like televint administrator.
It's basically a huge searchable database of corporate.
Insights, exactly a gold mine of publicly available information for profiling.
But okay, beyond general web searches and looking at people's jobs, what about finding the actual industrial devices themselves, the ones that might be, you know, directly exposed to the Internet. Ah.
Right, that's where a specialized search engine like showdow dot io comes in. It offers a truly unique perspective. How So, showed in dot io calls itself the world's first search engine for Internet connected devices, and it's genuinely surprising, sometimes shocking, what it reveals. What kind of things, Well, it's not uncommon to find complete operator consoles, human machine interfaces, or even specific industrial tech like those coocli ckplcs we mentioned, just freely open accessible.
From the Internet. Seriously, just out there. Yeah.
I actually remember one engagement where showdown dot io led me straight to a company's Citrix VPN portal. Okay, from there, it took a bit of social engineering to get some credentials, but within no time I'd compromised one of their domain controllers. The whole engagement went remarkably smoothly. Really all starting from that one showdown discovery.
That's an incredible headstart for an engagement. And beyond just finding exposed devices, I assume ethical hackers also check known vulnerability databases.
Absolutely, places like EXPLOITDB and the National Vulnerability Database or MVD. These list known vulnerabilities, often with proof of concept code.
So you find a piece of tech with showdan, then check if there's a known way to break it.
Pretty much. For example, you might find an older Rockwell Scata exploit, say from twenty eighteen, documented with its CVE number. It'll detail the affected versions, maybe even give simple examples like cross site scripting payloads. It's all about associating the technology you discover with known flaws before you even start active testing.
Okay, so that deeper connaissance is done. The next move I guess is to get inside the wire, but maybe without making too much noise initially exactly.
Passive network monitoring becomes absolutely critical at this stage, listening before you talk.
Essentially, how do they do that without messing up the live operational network. That seems tricky.
Well, you use techniques like switch court analyzers often called span ports, or dedicated network test access points known as.
Teppeece span in tippiece okay.
These tools basically duplicate the network traffic and send a copy to your monitoring device. The crucial part is they do it without impacting the performance or operations of the actual live network.
And why is that so important?
It's vital because modern intrusion detection systems IDs, especially those designed for OT environments from vendors like Clarity, Nozomi Networks, Dragos, they heavily rely on these methods. They need to passively absorb data from the network to build awareness and detect threats. In the industrial cybersecurity space, They're.
Constantly trying to understand all the different industrial protocol exactly.
It's a constant evolution for these IDs systems.
And the go to tool for actually looking at all that capture traffic is wire shark, the network engineer's best front.
Absolutely, wire Shark is indispensable. It lets you capture and analyze literally all the bits of data moving through the network.
How deep do you have to go?
Well, a proper packet deep dive usually starts with understanding the OSI models layers you know, physical data, link, network, transport, session, presentation, application, go whole stack, all right. Understanding those layers is key because in ICs attacks often exploit vulnerabilities at very specific layers, maybe the application layer for protocols like modbus, so that layer by layer analysis is indispensable.
And once you've captured that traffic, maybe from say publicly available packet captures PC keys from conferences like for SICS, you can use wire sharks silters to find those gold nuggets.
Right, Oh, definitely Daine filtering the traffic and just finding admin dot admin or root dot root credentials sitting there in plaintext within HTTP basic authentication.
Wow, easily decoded from bas sicxty.
Four trivial, or maybe identifying an AKSIS network camera, finding its exact model and firmware version because it's advertising itself via FTP. Then you just take that info, cross reference it with EXPLOITDB, and.
Bam you might have a known vulnerability ready to go.
Exactly. It really demonstrates how surprisingly easy it can be to get critical information in a very short time just by passively listening to the network traffic.
So that passive approach often yields a lot before you even need to actively.
Interact significant results. Yeah, before any active scanning or interaction is even necessary.
Okay, So once you've listened, you've done the recon, you kind of know what you're looking for. Then you're ready to start interacting with the industrial gear through active scanning.
Right now, you start actively probing, but carefully.
What tools are essential here?
Well, NMP is foundational, still a cornerstone for port scannings, fingerprinting, identifying applications, and importantly, it has custom scripts specifically for ICs protocols that extend its capabilities significantly.
Okay, MP's the classic.
Any newer tools, Yeah, then you have newer, much faster tools like rust scan. It's often lauded for its speed, claims it can scan all sixty five thousand TCP ports in something like three seconds.
Three seconds. That's incredibly fast. But does that speed come with a tradeoff, especially in these sensitive industrial environments.
That is the critical question. Yes, there's a huge trade off. Rust scan speed generates a lot of network noise, and in my own experience, it can most certainly knock over sensitive legacy devices, old PLCs controllers, they just weren't designed for that kind of aggressive scanning.
So a real world cautionary tale absolutely.
In ICs pen testing, you have to be incredibly careful, much more so than standard IT PEN testing. You cannot inadvertently shut down production. IT demands this unique safety first mindset.
Right makes sense. Now, what about web interfaces. Lots of SCATA systems have web front ends now like Ignition Scata yep.
For those you'd use tools like gobuster or Fareroxbuster. They're designed for web enumeration and directory brute forcing trying to find hidden pages or directories.
And I guess the wordless you use are crucial.
Are absolutely critical. I always stress this. You are only as good as your word list, especially for finding industrial specific paths that standard weblists might miss, things like status can, fig reports, alarms. Finding those hidden resources can be key.
Okay, tools aside, What's really crucial you mentioned earlier is speaking in the language of ICs.
Yeah.
Understanding the actual industrial protocols.
Yes, this is non negotiable for any ethical hacker in this space. You have to understand how these devices talk to each other. Modbus, for example, is ubiquitous. It's relatively simple. Uses function codes over TCP port five oh two to read or write data to devices.
Like function code five.
Right, function code five rights to a single one bit think of it like flipping a digital light switch, read coil status as function code one, read holding registers is three, and so on. Simple but powerful.
And then there's ethernet T more common in North.
America, that's right widely adopted here. It's powered by the Common Industrial Protocol or CIP. A key part of it is the identity object.
What's in that.
It contains crucial device information, vendor ID, product board serial number, even the product name like maybe seventeen fifty six L five to five a ogi x five five five five for a rock Well controller. It's like the device's digital name plate.
And you can actually interact with these directly, like send commands.
Oh yeah, you can learn how simple scripting commands, maybe using Python libraries can directly interact with say that code click plc we talked about. Yeah, you can energize specific.
Coils, turning the lights on and off from your script.
Exactly turn physical outputs on and all off. But this leads us straight to a critical warning, the absolute importance of having clear, well defined rules of engagement, because you must never, and I really mean never, just randomly push data to coils or registers unless you are explicitly authorized and know exactly what you're doing.
What could happen.
You could easily inadvertently shut down production lines, maybe entire process trains, and this could have the adverse effect of creating a massive loss of revenue for your customer, or worse, create an unsafe condition. The physical impact is immediate and can be severe.
That's a very stark reminder of the responsibility involved here, huge physical and financial impact potential. Okay, shifting gear slightly. Modern ICs environments, they're rarely totally isolated anymore, are they?
No?
Not.
Usually they often connect to the corporate IT networks. This creates what we call a converged network.
And that opens up entirely new attack vectors right from the IT side into the OT side.
Precisely, so, to simulate this realistically in the lab, the book shows how you'd add elements like Windows twenty nineteen, domain controller running active directory DNS DHCP, and maybe a standard Windows ten workstation, just like you'd find in a corporate environment.
So now the attacker might try to compromise the corporate side first.
Often, yes, once an ethical hacker gets a foothold in that corporate network, active directory attacks become a primary focus. There's a whole suite of tools and techniques.
Like what well.
Tools like curb root can enumerate valid ad user names by sending curbero's requests. Then there are kerber roasting attacks.
Kerber roasting. Yeah.
An attacker, even with just a regular low privileged user account, can request service tickets for accounts associated with service principal names SPNs. The ticket they get back contains a hash of the service account's.
Password, which they can then try to crack.
Offline exactly, maybe revealing the password for an account like operator three.
And what about NTLM hashes? Are those still relevant?
Oh? Definitely. Tools like Responder are brilliant at capturing NTLM hashes. They work by poisoning local network name resolution services things like LLM and r NBTNS sometimes DNSM DNS. When a machine tries to connect to a non existent share, Responder tricks it into sending.
Its hash and you can crack those two.
Yes, often leading to cracked credentials like say Operator one dot password one. Once you have valid credentials, getting a foothold or getting shells is the next objective.
HOTI get shells.
Tools like evil WinRM are great for getting interactive command shells over Windows Remote management and PowerShell payloads are super common for delivering reverse shells where the compromise machine connects back out to the attacker's listening machine gives you control. Right, And here's a bit of practical wisdom from the field. Two is one and one is none, meaning if you only have one shell one way into a system, you
don't really have reliable access. What if it drops? You always need a backup plan, a second shell or method in case your primary session gets lost or detected and severed.
Okay, smart, So after getting that initial shell, the goal becomes privileged escalation right, moving.
Up the ladder exactly, moving from that less privileged account like Operator one up to maybe a local system administrator or the ultimate goal, domain administrator.
What tools help there? I've heard of.
Mimicats, ah, mimicats. It's a legendary tool, primarily famous for its ability to dump credentials, passwords, hashes, Carberos tickets directly from memory on a compromised Windows system. So you might run it as Operator one and find higher privileged credentials.
And you can use those dumped Carberos tickets.
Yes for pass the ticket or PTT attacks. You basically inject a captured ticket into your current session to impersonate another user, maybe an administrator. This can sometimes lead to achieving a golden ticket, the master key. Essentially, Yeah, a forged Carbrero's ticket granting ticket that gives you domain admin persistence, letting you create tickets for almost any user or service. It's like having the master key to the entire active directory domain.
Wow. Any tools to help find these escalation paths? Yeah?
Tools led windps are great. They automate the discovery process, scanning the system for common misconfigurations, vulnerable services, stored credentials, anything that could lead to higher privileges on Windows.
Okay, so you've got Domaine admin maybe on the IT side, but the real prize is the OT network. How do you get from IT to OT? Especially if there are firewalls?
Right, that's the next major hurdle pivoting through firewalls. You need to bridge the gap techniques like using proxy chains to tunnel traffic, standard SSH tunneling if SSH is available, or tools like Chisel.
Chisel.
Yeah, Chisel is a fantastic tool. It works as a TCPUUDP tunnel, often used to set up a reverse sec case proxy, the compromise machine inside connects out to the attacker, creating a tunnel back in effectively bypassing firewall rules that might block inbound connections.
And sometimes finding SSH open can be a surprise for the defenders.
Definitely. I've had stories, real anecdotes where security managers were genuinely shocked to discover SSH was active and enabled, even on servers and they're supposedly pure Windows based environments. Finding that allows attackers to establish tunnels that completely bypass network segmentation and get deep into the industrial network.
So that brings us to a common weakness credential reuse.
Oh, it's a massive pitfall. Many organizations suffer from widespread credential reuse across both IT and OT systems. If you find credentials on a domain connected system on the IT side.
There's a good chance they work on the OT side too.
A very high likelihood.
Yes.
I worked in engagement once where a domain service account, which should have been disabled after setting up some new computers, was actually still active and had privileges across many machines, including some in the OT zone.
What did that give you?
It granted access to analyze basically every user and machine in the domain, and ultimately that path led directly to controlling a distributed control system a DCS. It just highlights how one single point of failure in credential management can cascade catastrophically.
That's the ultimate goal, right, getting access to those SCAT user.
Interface often, yes, leveraging those compromise credentials, maybe that operator one dot password one we found earlier, to log straight into the ignition SCATA, UI or whatever hm I they're using. And once you're in, once inside, documentation is crucial. You need to figure out exactly what processes the SCATA system controls, what are its network connections, what specific equipment doesn't manage? Build that complete situational awareness.
But that warning again, yes.
Absolutely have to reiterate it. Just because you can gain this level of access, maybe see the controls to shut down a process does not mean you should ever implement or change anything without explicit written permission in the ROE, these types of unauthorized actions can absolutely land you in prison or worse cause a real world disaster.
Understood, It's not just UI access though, right, can you get deeper like script access?
Definitely? Sometimes you find misconfigured services like an FTP server, maybe running on the SCATA machine itself. Perhaps it allows anonymous access, or maybe the credential you found work and it has right permissions to the web directory.
Ah, so you could upload a webshell exactly.
You could upload a simple PHP webshell. Then you set up a netcat listener back on your Collie Lenox attack box brows to the webshell you uploaded.
And it connects back BINGO.
It triggers the shell, providing a full reverse command shell back to your listener. Now you likely have OS level access on the SCATA server itself, potentially granting full access to the network from top to bottom, depending on its connectivity.
Okay, so the PENTIS phase is done. You've potentially gained significant access. What's the critical final step? How do you close the loop?
The final step is the comprehensive report and providing actionable mitigation recommendations. The PENTIS report is really the core deliverable.
What goes into it.
It needs to clearly communicate where the security gaps are and how you leverage them to gain access. It's usually a structured document covering the attack vectors used, the likelihood and impact of the findings, the complexity and any existing security controls that failed or were bypassed.
And tying it back to business impact is key.
Right, Absolutely, The impact analysis has to tie everything together, the lateral movement, the privileged escalation back to tangible business risk. For instance, demonstrating that you could gain access to the scata UI and realistically lock every user out and shut down the entire system. That's a critical finding any organization needs to take extremely seriously.
You mentioned physical impact earlier.
Any examples, Yeah, I recall a story happened in the northern part of Canada. An engineering team apparently switched the configurations on two critical controllers by mistake, a simple human error. It led to a large compressor blowing its seals and a vital pump cavitating, basically destroying itself millions of dollars in damage and loss production from a simple control configuration mistake.
It just vividly underscores the immense physical and financial consequences of messing with control level settings, whether intentionally or accidentally.
That's terrifying. How can defenders the blue teams better understand these kinds of attacks?
The AIRIATT and CK framework, especially the one for ICs, is invaluable here. It provides a really great visual representation of adversarial tactics, techniques and procedures or TTPs.
How does it help?
It helps blue teams understand the specific methods attackers use, like using valid accounts for lateral movement or exploiting remote services. And importantly, it links these techniques to potential mitigations and detection strategies. It gives them a structured way to think about defense.
And finally, what about actual technological defenses? What should companies be putting in place?
Well, industrial firewalls are a key component products like the Cisco ISA three thousand for example. They often integrate with broader security ecosystems like Cisco ISIC or Cybervision. What they do They can enforce segmentation, control traffic flow based on industrial protocols, and sometimes even automatically quarantine new or suspicious devices found on the network or push specific security policies
using security group tags or sgts. This can cause immense frustration for pentesters who suddenly find their access roots blocked mid engagement.
And intrusion detection systems the IDs we mentioned earlier.
Yes, companies like Drago's Clarity and Nozomi Networks are leaders in the OTIDS space. They deploy sensors often connected via those SPAN ports or T texts, specifically designed to understand industrial protocols and baseline normal behavior.
What did they detect?
They look for anomalies new MS or IP addresses, appearing unusual protocol usage, unexpected communication paths between zones, connections to known malicious ips. If a company lacks ot specific IDs, it's almost always a top recommendation and appentest report.
It sounds like a constant arms race for the vendors to keep up with protocols.
It really is an ongoing arms race for protocol dissectors to understand and protect against threats targeting every possible industrial communication method.
Wow, what a journey we've really ventured through the intricate world of pen testing industrial control system They covered a lot, yeah, from those foundational lab setups and passive reconnaissance all the way through active exploitation, privileged escalation and navigating that delicate ITOT convergence. We've seen our curiosity, when it's combined with specific tools and techniques, can uncover really critical vulnerabilities in the systems that manage our most essential services.
And I think this deep dive has hopefully shown you, the listener, that securing these environments really demands a unique blend of skills. It's it knowledge, but it's also deep operational technology understanding.
Not just one or the other exactly.
It's an ongoing challenge, maybe even an arms race that requires continuous learning and crucially, a deep appreciation for the potential physical impact of purely digital actions.
Right, hopefully you now have a much more comprehensive understanding of the ethical hacker's mindset when they approach this high stakes domain.
That's the goal.
So what does this all mean for you? There's a quote from Walt Disney. He once said, there's really no secret about our approach. We keep moving forward, opening up new doors and doing new things because we're curious, and curiosity keeps leading us down new paths. We're always exploring and experimenting.
I like that curiosity.
In a world that's increasingly reliant on these connected industrial systems, how will your curiosity lead you to explore and maybe help secure the hidden paths of our critical infrastructure.
