--- title: "ZTc for OT and Critical Infrastructure Incident Response" description: "A technical demo of adam:ONE achieving radio silence against C2 servers with DTTS and dynamic allow-listing while OT infrastructure keeps running." url: https://adamnet.works/videos/ztc-ot-critical-infrastructure-incident-response/ index: https://adamnet.works/llms.txt --- [All videos](https://adamnet.works/videos.md) Operational Technology · Critical Infrastructure · Incident Response # ZTc for OT and Critical Infrastructure Incident Response A technical demonstration of how ZTc ReflexAI dynamic allow-listing works with Don’t Talk To Strangers (DTTS) to achieve complete radio silence against C2 servers without losing operation of OT infrastructure. April 22, 2025 • 24 min ![ZTc for OT and Critical Infrastructure Incident Response](https://adamnet.works/assets/thumbs/yt-ES3Z7U63BnA.webp) At Black Hat, ADAMnetworks demonstrated rescuing a network under active multi-channel C2 attack: achieving radio silence to the attackers while maintaining critical operations, in under 10 minutes. This demonstration is based on the same concept but goes deeper into how it is achieved and how adam:ONE® establishes Zero Trust Connectivity (ZTc). It focuses on the value of ZTc for critical infrastructure, OT and IoT, and applies equally to any high-value asset, such as mission-critical IT operations, intellectual property or sensitive information at risk of exfiltration. The same approach contained a real ransomware attack in the [global manufacturer incident response case study](https://adamnet.works/case-studies/manufacturing-ransomware-incident-response.md). For the background to ZTc, watch [Zero Trust Connectivity (ZTc): A Full Introduction](https://adamnet.works/videos/zero-trust-connectivity-full-introduction.md). ## Full Transcript ### The lab and the two goals **Francois Driessen:** Okay, we are in David’s lab now, and David’s got a pretty cool setup for us here, complete with a fish and everything. **David Redekop:** Well, welcome to this operational technology business network incident response project. Don’t say that too fast. But we’re excited to basically show you what we have provisioned in a lab environment, where we have two key goals in this compromised network. And number one goal is to go radio silent to the attacker that currently has command and control access to this infrastructure. **Francois Driessen:** Okay. Right. So, got it. Goal one: go radio silent. **David Redekop:** Yeah, that’s exactly right. And goal number two is to get the operational technology up and running without the command and control channels being resumed. **Francois Driessen:** Of course. Yeah. Very good. **David Redekop:** So the way we’re going to achieve this is basically to sever every single connection from this site outbound out to the internet. And then, when we replace the gateway with Zero Trust Connectivity, we will automatically quarantine all assets and then only give access to those that are verified and necessary. And this can be done with a Reflex-based AI allow-listing mechanism. **Francois Driessen:** Right. **David Redekop:** So let’s look at the setup here. So what we have, very quick, is we have our initial point of entry that was a Bluetooth wireless bridge that was just keeping tab on our little fish. **Francois Driessen:** Okay, hold on. Hold on. I wonder how’s Mr. Bubbles doing here. Okay, he’s a pretty cool guy. So this is actually pretty cool, ’cause it’s based on a real-life event that I’ve heard of, that the point of entry was through not the fish, but the Bluetooth thermostat. Like, a Bluetooth thermostat, to make it a smart device, actually connects to some sort of wireless bridge, and the wireless bridge is the entry point. And then from there on they pivoted, and yeah, so, and then the nasties happen from there. **David Redekop:** That’s correct. So what we have is the wireless bridge then pivoted and infected a Windows computer, which is the controller for the PLC. So this is the setup that we have here: we have the wireless infection point and then lateral movement over to Windows, which controls the PLC. And so the ultimate target for an attacker is the PLC. **Francois Driessen:** Okay. So let’s say critical infrastructure is controlled by that PLC, and that’s ultimately what they want to get to. **David Redekop:** Okay. Yeah. So if the attacker can stop this, either with a denial of service or infect it, then they have a chance for a ransom or for a demand of some kind, right? **Francois Driessen:** But let’s up the game a little bit, right? Let’s say that it’s not just control or destruction of the PLC. Let’s say it’s also data exfiltration, either intellectual property that gets stolen by a nation state or whoever, or a competitor. **David Redekop:** Sure. Sure. Or, that’s right, for extortion. **Francois Driessen:** So, if either of the two things, like when the C2 connects and you can actively exfiltrate data, then we say that this would put it into a game-over state for what we’re trying to protect here. **David Redekop:** Okay, that’s exactly right. So in addition to the critical infrastructure, we also have obviously a managed switch, and we have a status quo gateway, and we’ve color-coded the cables here to indicate that the red is the internet connections, and yellow and green are internal connections. **Francois Driessen:** Okay. **David Redekop:** And then we have the star of the show, which is the guy we’re going to turn on here in a minute, which is the Zero Trust gateway that’s running adam:ONE®. So it’s not about hardware, because it’s exact same hardware, but this one runs the adam:ONE software, and we’ll connect that in a moment to show what happens to the command and control connection as we do that. ### The C2 implants **Francois Driessen:** Okay. So let’s get to some more fun stuff. Do you have the C2 up and running yet? **David Redekop:** I have the C2 up and running. Let’s take a look. Okay. So what we have here is two implants. I created an implant that runs over DNS, and I created an implant that runs over HTTPS directly to an IP address that would not use DNS. **Francois Driessen:** Nasty. **David Redekop:** Yeah. The cool thing about the DNS-based one is that it actually has no persistent connection out to the internet. So if you’re only looking at stuff that goes onto the internet and back, this will not register anything, because it does all of its command and control activities through DNS TXT record questions and waiting for the command and control server to respond. And therefore it’s super stealthy if the environment isn’t very carefully observing and protecting via DNS. **Francois Driessen:** Right. Right. **David Redekop:** But the other one is that, even if DNS is being carefully monitored and there is a DNS traditional firewall, it just doesn’t bother using it. It just uses TCP port 443. So it hides amongst all the other HTTPS traffic and isn’t obvious. So we have both implants running right now on this particular device. So this is the controller here. **Francois Driessen:** So we’re saying here that this is the controller for the PLC over there, right? **David Redekop:** That’s right. Okay. So this here is just running a packet capture on the command and control server to show that there’s traffic coming in. But if I take a look here at sessions now, I am now showing an alive session of a Windows computer with this username, coming from that IP address, that’s running right now. So we do have full remote command and control of the infected machine. So the attacker is controlling the attacked. **Francois Driessen:** Okay. So right now this network is already in a game-over or close to crash-and-burn state. **David Redekop:** That’s right. So they’re at least high checkmate. ### Swapping in the Zero Trust gateway **David Redekop:** So this is the rescue part. This is the fun part. So what we have here is a Zero Trust gateway. We’re not compromising at any standard modern features, right? 10 Gbit layer 3 traffic processing, SD-WAN for multiple internet connections if that’s what you have. All your internal network segments are all going through this one connection. But it’s not connected yet, because we need to first disconnect the status quo gateway and then instead connect the Zero Trust gateway. Okay. Now what we want to do is immediately take a look and see if we’ve achieved goal one, which is to sever connections. Let’s see what happened. All of a sudden, our packet capture on the command and control server just went dead. And if we take a look at our sessions now, now that remote session that we had connected to is now dead. **Francois Driessen:** Okay. Fine. **David Redekop:** It’s still attempting to make a connection, of course, because we haven’t touched the infected device yet. So now at this point you might say, sure, anybody can disconnect a network and it goes dead, right? But that is goal number one, only to be followed up with the next goal, which is how do we now get things up and running. **Francois Driessen:** And not just get stuff up and running; it was up and running before. **Francois Driessen:** Okay. **Francois Driessen:** How do we get it up and running without the attack continuing? Because it will not be running much longer. **Francois Driessen:** Right. Okay. Exactly. That’s the catch. **David Redekop:** That’s exactly right. Okay. So, couple of things we want to look at now. We have the adam:ONE dashboard that represents what this brain is doing by connecting with the cloud controller, because that’s who tells it how to operate. And we can see that it is online. Our security gateway is online. And we do have a default policy that is a holding tank quarantine. And we can now see that there are 22 devices in the holding tank quarantine. And we can also start to see what the devices are attempting to do, network traffic-wise. **Francois Driessen:** So this is a log down here, right? **David Redekop:** This is a live log, where everything in red is blocked and everything in green is allowed. So here, for example, this X1 Yoga, which is the infected device, it is making attempts to do its DNS-based command and control, but because it’s in a holding tank, it can no longer connect. **Francois Driessen:** Okay, fine. Fine. **David Redekop:** It’s also trying to connect to Microsoft for connectivity, and we’re like, “Yeah, let it think that it’s online.” **Francois Driessen:** Well, wait. You’re in the holding tank. We’re saying sever all connections. **David Redekop:** Yes, you do want to sever connections. However, most malware will not activate if it senses that it’s not online. So you do want to give the operating system the belief that it’s online, because only then will malware continue to run, right? And that’s what you want to be able to identify. So the holding tank did immediately sever connections and then only allow connectivity tests to get through, and that’s the state that we’re in right now. ### Device inventory and the ReflexAI™ policy **Francois Driessen:** Okay. Fine. Okay. But let’s just go back and look at the device inventory first, because that’s such an important part of this process, is that, you know, the moment that ADAM comes into the mix, it goes onto the edge, you have automatic device inventory. Suddenly you can see everything that’s on the network. So let’s have a look at that. **David Redekop:** Okay. So if we look at our device listing now, we will see a number of policies that have been set up, and some of the devices, for example, would have automatically connected over 802.1X, and so therefore they were automatically placed in the right policy by just authenticating on the network properly. If there was no user authentication, such as would be with OT devices, those are all going to be in the holding tank quarantine. Well, we can now take a look at what’s been discovered so far. **Francois Driessen:** Okay. So you’re kind of doing two steps in one already, because it’s not just inventory, but you’re automatically starting to move devices into policy, because your 802.1X was already set up for human or user-based assets, right? But all the machine-based assets, like the infected controller and so forth, that is still sitting in the holding tank, waiting for you to apply where it’s supposed to go. **David Redekop:** That’s exactly right. That’s exactly right. Okay. So now we’re in a position where we do know that we have a device here on the network that is ready to be moved into a policy where it can be operating again. This happens to be the controller for the PLC, and it’s in the holding tank quarantine. So let’s just go ahead and move it into our Reflex AI policy, and we will just allow it to view its own log, so I can show you in a minute what it looks like, and we’ll tag it as a verified asset. By making this change, we have now placed that infected computer into a policy that isn’t just a static allow list or static whitelist policy. It actually dynamically verifies assets in terms of destinations, and it also absolutely, positively blocks all connections that were not first asked for by DNS. So that’s the enforcement called Don’t Talk To Strangers. **Francois Driessen:** Okay. Right. Right. Right. So let’s just double-check that our C2… What state is this? **David Redekop:** It’s still dead. Okay. That’s right. It is still completely dead. Let’s check one more time. It is still completely dead. It is not able to connect. **Francois Driessen:** Okay. Very good. Okay, so automatic inventory is done. You’ve identified the device that you want. Now you’ve moved it into the policy. What should we expect to see it do right now? **David Redekop:** So what we should be seeing now is the implants still attempting to make a connection. As we can see here, it’s now trying to use DNS-based connections to still reach the command and control server, but it cannot, as you can see, as it’s in red and it’s blocked. But other destinations, like office.net, are automatically allowed by the Reflex policy. So what we’re seeing now is that the infected device is still infected. It hasn’t been cleaned yet. So the infection, or the beacon, is still attempting to reach the command and control operator. As we can see here, it’s now trying to use DNS-based mechanism to still connect to the command and control server. But if we take a look down the list here, all queries that the Reflex AI policy has deemed safe are successfully connecting. They’re resolving and successfully connecting without any trouble. **Francois Driessen:** So it’s essentially creating a DNS allow list dynamically, in real time, as the requests are coming in, right? **David Redekop:** That’s correct. **Francois Driessen:** Okay, good. **David Redekop:** That’s right. And on top of that, we still have to deal with the reality that malware doesn’t use DNS much of the time. So how do you deal with that? How can you rely on DNS-based dynamic allow-listing to then also make it leak-free? And that’s what we do with Don’t Talk To Strangers. So here you can see it in action: when the infected device is trying to reach Microsoft.com, it’s successfully getting through. But when it’s trying to reach the command and control operator… Remember, the system doesn’t know that that particular IP address contains a command and control server at all. What it does know is that that destination was not resolved by a dynamically allowed domain name, and so therefore it’s a stranger, and we don’t talk to strangers. **Francois Driessen:** Okay, great. So what this means is that just by changing one policy, you’ve already put that critical infrastructure back online while the command and control is still radio silent, right? **David Redekop:** That’s exactly right. **Francois Driessen:** Okay. Well, let’s see. **David Redekop:** Okay. So we’re going to launch a web browser and see if we can access our usual resources, where we’re looking to sign in to our Unicloud. Let’s take a look. Am I able to get in? So far, so good. Okay, there we go. Okay, I still have to go through the training here, apparently, but no, let’s just confirm that we’re actually able to see everything that we need to see. Here we have our PLC management. No problem. Everything is completely remotely controllable. Just to make really sure, we can access another resource. Let’s check our near bus. Are we able to log in here, or in some other service like draw\.io or some other server? There we go. **Francois Driessen:** Yeah. **David Redekop:** So we can do the same thing. Let’s check any other business resource that we need dynamically. We’re going to need to access diagrams.net or draw\.io. Yep. Looks like it’s all working. **David Redekop:** Okay. No problem. Okay, so the device is online, right? **David Redekop:** Correct. **Francois Driessen:** What about our C2? **David Redekop:** Ah, very good question. We’re still seeing nothing. It’s completely dead. Let’s check our sessions here. Completely dead. But I wonder if it’s still trying over here. Let’s look for blocked connections. As we can see here, it’s still trying continuously. Right up until the current minute, it’s still continuously trying to use DNS command and control. What about the traffic log? Same thing. If we look at just everything that’s being blocked here, we’re still seeing the command and control connections continuing to attempt and never succeeding. All right. ### Testing a circumvention tool **Francois Driessen:** Okay. So there’s going to be some of you guys that have questions, and I think by upping the game on the demo a little bit, some of those questions are going to be answered, right? So, you ready for it, David? So, here we go. Okay. Right. So let’s say this. Let’s say they launch some sort of circumvention tool, the mother of all circumvention tools. Why don’t we just fire up Psiphon, see if it can actually bypass, and in that way re-establish command and control, right? **David Redekop:** Let’s do it. So I have Psiphon 3 downloaded already. Let’s take a look. If we were to launch it right here, it’s going to immediately attempt to connect. What I’m curious to see now is if it will succeed. So I’ll be keeping my eye on the app here, whether it’s going to continue to say Psiphon is connecting. But over here I’m curious to see what other connection attempts it is trying to make. And so in particular, I’m interested in seeing what it’s trying to do over direct TCP connections. And you’ll see that it’s actually trying to use port 53 for UDP- or TCP-based tunneling. We’re seeing port 22, which is an attempt to do SSH tunneling. We’re seeing a variety of other random ports that are available for it to tunnel through. And these are all blocked connections. And if we were to see it without any filters, then we’re actually seeing the occasional green connection that’s being allowed through. But almost every single attempt here is being blocked. **Francois Driessen:** So those green connections are legitimate connections. The device is still online. Critical infrastructure still up, right? **David Redekop:** That’s right. **Francois Driessen:** And so the mother of all bypass tools is still having trouble connecting, right? **David Redekop:** That’s right. Connecting. It even says so: “Oh no, you seem to be having trouble connecting.” But let’s take a look if that’s really the issue, or if we’re pulling any tricks. Can I go to google.com? Sure, I can. I have no trouble getting to Google. Can I still visit Google on the browser? No problem there either. Okay, very good. So we have connectivity, but we’ve completely severed connections, and we’ve made command and control impossible to reconnect. Only the operational technology is able to get back online, doing what it needs to do. ### Comparing static default-deny allow-listing **Francois Driessen:** Okay. Okay. Just to take it a little deeper, even, to have more value for the guys that are looking at this. I don’t think we need to go back to compare this again to a status quo blacklist. That’s where we started. That’s how the network was attacked already. You know, trying to keep up with what’s bad, what’s known to be bad, it’s too late. You’ve already been attacked, right? But what about the guys who don’t really understand Zero Trust Connectivity, that are saying, “Well, we’re kind of doing this already with static default-deny allow-listing,” right? So you start with the default deny-all and you do static allow-listing. Why don’t we up it even more and go into that mode? You can do that with the ADAM muscle. Go into that mode, and then let’s see what the C2 does in this case. **David Redekop:** Okay. Sure. Challenge accepted. Except we’re going to make it so strict that nothing connects. Ready? Here we go. We’re going to use this policy that we… **Francois Driessen:** Wait, wait, wait, wait, wait. So if nothing can connect, then phase two, what we want to achieve, you’re not going to be able to achieve, right? Because now your operation will not be able to connect either. **David Redekop:** Correct. **Francois Driessen:** Okay. Fine. All right. Let’s go. **David Redekop:** Okay. So we had this device on the Reflex AI allow policy. Let’s put it onto the DNS allowlist policy. Now, this is our strictest of strict policy that we have right here, and it shows you right here that the default treatment is block, with only the rules below that are allow-list enabled, and none of them are enabled. **David Redekop:** Okay, including the automated Reflex is not enabled at all, right? **Francois Driessen:** Right. So this is the strictest of the strict standard status quo allow-listing. **Francois Driessen:** So right now phase two of what we need to achieve is broken. So this machine here should be completely dead, right? **David Redekop:** That’s exactly right. So if we now take a look at anything that we have, we have shortcuts here, we will have no internet for anything. Let’s just take a look. Do we have access here? No, we have no access to the internet. **David Redekop:** Okay, fine. But what about the bad actor? What about the guy who implanted malware? **David Redekop:** He’s going to have a surprise. Ah, look at that. I am seeing TCP traffic again on our command and control server. And look at that, the session shows that it reconnected. Now, if I look at sessions, our HTTPS connection is alive again. So we’re using DNS black-holing for everything, but the implant can still reach out. **Francois Driessen:** You’re in worse state than what you were in the beginning. This is still like an absolute game-over state. And what if the attack is even to stop operational technology from working? Right. So you’ve now actually done what the bad actors wanted you to do, right? **David Redekop:** By going this route, we’ve now disabled our operations, but we have not shut down the command and control by taking that traditional approach. **Francois Driessen:** So can you rescue us again? Can you take us back? Please take us back. I don’t like being in the place where it’s game over. ### Restoring Zero Trust Connectivity **David Redekop:** Right. Let’s go back. **Francois Driessen:** Let’s go back. Take us back to the Zero Trust. **David Redekop:** So we’re going to go back into the policy manager here, and let’s just put it back into the Reflex policy, and… **Francois Driessen:** Okay. Right. So you’ve applied the brain change here, moved it back into the policy. The muscle is now going to check in on the network edge and move it into the Zero Trust Connectivity. And once that’s taken effect, we should be back to where we were, right? We should be in a saved state, right? **David Redekop:** Okay, let’s see. Correct. So let’s take a look. Can we now access resources once again that we need access to? Can we access Unicloud? Yes, we can. Can we access Metro Cloud? Yes, we can. Can we access draw\.io? Everything’s working again. Fine. However, what about over here? I wonder if we’re… Oh my goodness. But once again, the command and control connection is completely dead, and we’re seeing no more TCP 443 traffic from our implant. So we’re back. **Francois Driessen:** Okay. Challenge one: radio silence to the attacker, right? **David Redekop:** Okay. Achieved. **Francois Driessen:** Achieved. We did it. Okay. Right. And two, to bring our operational technology back online, right? **David Redekop:** We do. **Francois Driessen:** Good stuff. Good job, David. Okay. And of course, I know the question on all of your minds right now is, “How about Mr. Bubbles? How’s the fish?” And the fish is still happy. **David Redekop:** Very happy. [Watch on YouTube](https://www.youtube.com/watch?v=ES3Z7U63BnA) ## Related reading Case Study ### [Ransomware Incident Response for a Global Manufacturer](https://adamnet.works/case-studies/manufacturing-ransomware-incident-response.md) June 20, 2023 Articles ### [Purdue 2.0? Rising to the Challenge to Secure OT with Zero Trust Connectivity](https://adamnet.works/blog/purdue-2-0-securing-ot-with-zero-trust-connectivity.md) October 8, 2025 Video ### [Zero Trust Connectivity (ZTc): A Full Introduction](https://adamnet.works/videos/zero-trust-connectivity-full-introduction.md) September 15, 2022 ## See it on your own network Zero Trust Connectivity reduces attack surface 7000:1 by denying egress by default. Talk to us about what that looks like in your environment. [Request a Demo](https://adamnet.works/contact.md) [How adam:ONE® Works](https://adamnet.works/how-it-works.md)