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