Hiding Inside Devices: Unveiling Vulnerabilities in Finance, Retail, and Logistics

John Vecchi:
Well, hello everybody. You’re listening to the IoT Security podcast live on Phosphorus Radio. I’m John Vecchi.

Brian Contos:
And I’m Brian Contos, and we’ve got an amazing guest today. Welcome to the show, Andres Andreu.

Andres Andreu:
Thank you. Thanks for having me.

John Vecchi:
Welcome, Andres.

Brian Contos:
Yeah, we’re real excited to have you on. Andres, before we get started, maybe you could give our listeners a little bit of background about you and how you came up in the industry and what it is that you do today.

Andres Andreu:
So I am the Chief Information Security Officer for 2U, an ed tech company. We’re a global company. Pretty sure we’re around the 70 million mark in terms of students all over the world at this point. Been in this industry, I’m going to date myself here, 31 years now. Got my start in the federal government and it’s been an amazing ride.

Brian Contos:
That’s fantastic. Now, what was it that initially got you interested in the cybersecurity side of things?

Andres Andreu:
My early career was on the software engineering side, and for some reason I just naturally evolved into security because I don’t know, I guess because I guess I’m just a paranoid person. And so every time I would build software of any sort, I was always thinking of all the angles, how someone could break it, take advantage of it. So really I was doing [inaudible 00:01:50] and pent testing way before those fields came about. As a matter of fact, real funny story real quick, when I wrote my book on pen testing, the editor told me, “Hey, use the term pen testing.” And I was like, “What is that?” She’s like, “That’s what you do.”

Brian Contos:
That’s what you do. That’s awesome. That’s awesome. Well, congratulations on that. Three decades in this space, you must have seen a lot of changes and probably a lot of stuff, maybe even staying the same, right? Given your public sector and private sector background.

Andres Andreu:
What stayed the same, that the human is the weakest link in any of this that has not changed. Tech stacks have obviously evolved, right? Compute power has evolved, but humans, those pesky humans, they’re the interesting link in the chain, especially by the way, software engineers, and I can say that I was one of them for many years.

John Vecchi:
Yeah, well, and also Andres, and that’s true. That’s a constant, right, across anything. But as you look back at all the various positions and organizations you’ve been at, and how has your discipline of security, your approach, your strategy to it, and how has that evolved and changed over the years?

Andres Andreu:
So one thing I’ve had to come to terms with is that in certain environments, the old heavy-handed security approach just doesn’t work. When you come from the government where those type of positions of authority are respected, you come out to the civilian world and you think it’s like that, it’s not like that. And so you have to really become flexible, loosen up a little bit, learn tactful ways.
That’s what the way I like to see it. Learn tactful ways to still achieve the end result without having to pound your fist on the table. It just doesn’t work in the corporate world. And so I will say this, having a simplistic approach to what you should be protecting helps me, right? Because it’s easy to over engineer, it’s easy to become complex and in the security space, I always pull myself back and I’m always asking myself, it’s almost like that crown jewels approach. I’m always asking myself, what is important to this organization? What should we protect? I can’t protect everything. So we have to be very strategic in terms of where we put protective resources. So that evolution, I guess it just comes with maturity, but that evolution has really helped me, or at least I feel it’s helped me become effective at what I do.

Brian Contos:
I’m really interested in your perspective on this because of your software engineering background mixed with your pent testing and your years of experience. So when we look at xIoT or the extended internet of things, everything from digital door locks and printers to programmable logic controllers and robotic systems and so on, why is it that you think they evolved to not really follow the same path as IT assets in terms of really clamping down on security right around the ’90s and early 2000s to try to get to that level of parody where now we’re looking at devices today and we’re saying, “Man, these are the same issues we had in it back in 1995.” Why was there that disconnect you think? Was it from a development perspective or just organizations didn’t really pay attention? Why’d that happen?

Andres Andreu:
So I think there are a couple dimensions at play. One, I’m very upfront, so I’m just going to make an upfront statement. Some people don’t like to hear this, but it’s the truth. Most software engineers consider anything security related to be soul draining work. So if you actually expect your typical software engineer to factor in [inaudible 00:05:55] cases, right? Use cases that may their software. Forget, it’s not going to happen.
Now, things have improved over the years, but I can tell you that that problem is still prevalent today. So couple that with the timeframe that you just touched on, Brian, the devices that you’re talking about were highly resource constrained. So you could not add a lot of secure functionality to these devices because they didn’t have the horsepower to actually use that functionality effectively. Or if they did, it would impact. For instance, a PLC runs on a very tight clock cycle.
If you introduce processes that take it out of sync with the actual clock cycle, you have a problem. And so you look at some of these resource constrained devices, and I did a lot of work with them when I was at Bayshore, you kind of see why nobody built anything protected into these devices because it would be a problem. Software engineers generally, and I think this statement still holds true today, are concerned first and foremost with functional aspects. Right?
They build functionality. They don’t build safe functionality, they build functionality and they want to hit deadlines. And those are two things that work against the security paradigm of a, for instance, the secure software development lifecycle. And so I think those dimensions really came together to build that horrible storm that we’ve lived with for the past two decades in terms of security problems. But I think those problems, by the way, still exist today, especially with embedded technology because you have … well, let’s put cell phones aside because they actually have a lot of horsepower these days, but most IoT type devices really don’t have a lot of resources.

John Vecchi:
Yeah.

Brian Contos:
Yeah.

John Vecchi:
It’s true. And it’s interesting because kind of what you’re saying is, and we know this because Brian and I talk about this a lot, that a lot of these devices, they’re Linux based, there’s a few specific types of firmware, whether it be Android, BSD, VxWorks, BusyBox, all these different things. It’s very easy to just use common shared libraries across these things. It’s easy, it’s effective.
The last thing they’re thinking about, like you said, is security or any kind of software development lifecycle and security, secure software lifecycle and these things. So they come out to the organizations that get deployed without really any embedded type of security. It sounds like to you that that’s big … you can’t put endpoint agents on these things like you can a typical IT asset. So it sounds like that’s one of the issues, right?
And then you think in terms of the fact that a lot of these things just don’t have the horsepower, but of course what we’re seeing today is some of them now, some of the modern devices are pretty powerful. The inherent traits of them are the same. You still can’t put Tanium or CrowdStrike or some type of agent on them. But some of these things are pretty powerful and it’s probably one of the reasons why they seem to be highly targeted for ransomware or nation states and things like that. Do you agree, Andres?

Andres Andreu:
Yeah. Look at [inaudible 00:09:17], right? [inaudible 00:09:19] took advantage of really resource constrained devices, but just at such a large volume that it became an effective force. It wreaked havoc, right? And so if you study the [inaudible 00:09:32] code, I don’t know if you guys ever looked at it, but I actually did some research on it. What fascinated me when I started looking at it, well, fascinated and disturbed me, I should say, is the fact that common username and passwords literally we’re just enumerated and we’re getting into millions of devices.
What does that tell you? Millions of people still focus on functionality. Hey, I bought a camera. Let me put it in place. The camera works, beautiful. I don’t want to change anything. I go about my business. You leave it wide open. Software engineers are no different. So for instance, I was just on a panel in California recently talking about supply chain and S-Bombs and all that beautiful stuff. And somebody on stage who’s a highly respected individual started talking about doing code review on everything in your S-Bomb.
And then I was like, oh my God, that is so unrealistic because if you’ve ever actually set up … for instance, open SSL, probably the most commonly used library on the planet, if we can agree on that. Then take a step back and go, “Who has ever audited every line of C code in Open SSL? Who is even able to do that?” Forget about who has, I don’t know many people that even have that type of skill anymore to look at that level of C code, that millions of lines and go, “Oh, here’s a whatever, divide by zero error,” or something very, very granular like that.
It’s almost a dead art these days, but yet Open SSL, if you look at most S-Bombs is probably included in most of them because they need cryptographic libraries. And so how realistic is it to give, for instance, somebody advice? “Oh yeah, you should audit all the code in your S-Bomb.” That’s just delusional at best.

Brian Contos:
And when people start talking about things like that, is it a good idea if you have the resources? Of course and to your point, not many people are going to have those resources. But what we see a lot of is, you know what, regardless if you’re going to audit the code or not, we’ll go into organizations that 50% of their cameras have the default password, which is why [inaudible 00:11:48] was so successful.
The ones that have changed their password most of the time it’s changed to something simple and it wasn’t changed for a decade. And they don’t follow best practices, uppercase, lowercase, special characters, things like that. They’re pretty blah. The ones that maybe have done that, they haven’t updated the firmware on these systems as well for probably at least half a decade. And then because of that, they’re filled with all these vulnerabilities. And from my perspective, and let me know what you think.
I think a lot of organizations, when it comes to xIoT, one, they got to figure out what do I have? First of all, I need some visibility into what I got out there. Second thing is, let me do the basics. And again, to my point about the 1990s, let’s update the passwords. Let’s rotate them every 90 days. Let’s make sure they follow best practices. Let’s automate that process because we’re not going to do it one at a time for 10,000, 50,000, a hundred thousand devices.
Let’s make sure we can update the firmware and mitigate the number of known level eight, nine, and 10 vulnerabilities. And let’s turn off stuff we don’t need if we don’t need wireless on, shut it off. If we don’t need to be running clear text anonymous, FTP, let’s shut that off. To me, it seems so weird, and I hate saying, “Boy, you got to get back to the basics.” But man, when it comes to xIoT, these are just glaring holes. And what a great attack surface for nation states and cyber criminals.

Andres Andreu:
A hundred percent agree. To me, basic hygiene, which is what you just described, is the one missing link because think about it, it’s not sexy, it’s not cool. Who wants to sit there and whatever? Write a script that’s going to rip through 15,000 devices on our network and change passwords or disable services? Everybody’s looking for that shiny red button, that cool toy. Now it’s gen AI and all that bullshit. The basics still matter, to your point, Brian.

Brian Contos:
Yep.

Andres Andreu:
I will tell you this. And the attack surface management vendors love and hate me because I speak about attack surface management a lot because it’s a strong passion of mine because I feel that nobody really does it properly. And proof of that is as soon as I talk to any vendor, I ask them, “How do you detect non-generic computing devices on my network?”
That’s the end of the conversation because none of us speak Modbus TCP, they don’t speak DMP3, they don’t speak the IEC families of protocols. They don’t know anything about that space. Yet, they claim that they can tell you what your attack surface looks like. But if you happen to have any of those devices on your attack surface, well then shit, you’re out of luck with that product, right?
So to me, you don’t have the full picture unless you can tell me which one of those devices are on my network. And mind you, if you’re in a corporate space, if that building has, for instance, HVAC equipment that is remotely maintained, guess what? You probably have some of this stuff on your network. You just don’t realize it. And so to me, if you’re going to try to tackle a problem like attack surface, which is so important, you have to know what you you’re dealing with in order to build the right protective mechanisms, you got to look at it holistically, and you have to look at every angle, and you have to do it at a granular level. And unless you speak the right protocols, you’re going to miss some pieces.

Brian Contos:
John and I see this all the time, and when I think assets, of course you’re thinking about IT assets like a laptop, a server. You’re thinking about identities and application, sure. But the whole xIoT side, and a lot of the way the legacy solutions, I think approach this for attack surface management. Maybe they’re looking at the Mac and they’re looking at the first few octets to try to determine what it is.
And lo and behold, everything looks like it’s a printer. Well, it’s not a printer. This is not a printer at all. Why do you think I have a hundred thousand printers? And it’s really scary how inaccurate a lot of those legacy solutions are. So I could see why the love, hate relationship exists with you in the attack service management because man, it’s been done honestly pretty poorly on that, on the xIoT side of the house for quite a while.

Andres Andreu:
Yeah. Well, even the vendors that look at Mac addresses, it depended on the network architecture. The actual legitimate Mac address may not even make it to your product, right?

Brian Contos:
Right. For sure.

Andres Andreu:
And so there are all of these factors that you have to weigh in on terms of how holistic you are looking at a given network. Not to mention if anybody wants to be a real whatever, pain, you could sit there and just literally, you could write a script and probably five lines of Python that’ll flutter network with tons of Mac addresses and just throw all of this type of gear. All I enjoy doing that just for fun. But

Brian Contos:
It says here, you have 25,000 robots sitting in this lab.

Andres Andreu:
Well, I’m going to tell you a funny story from my Bayshore days. We were brought into one of the three letter agencies. We were doing a prototype of our product in there, and they put the product into a non-production environment. Their team was POC in it. And day one went, no problem. We installed, we set up this and that. We hit the hotel. We came back the next day, and one of their CIS admins came into the room.
I’ll never forget this, and he was so elated, I think he wanted to show off for his bosses. And he tells me, to me directly, he says, “You lied to me.” And I was like, “Listen, I’m known for many things, but lying is not one of them. What did I tell you that’s so inaccurate?” So he says to me, “You told me your device was based on Linux, but I see it as a Windows device.”
And he shows me a report that one of his tools generated. And I started laughing, and I was like, “Well, if you’re so confident, why don’t we do this. Up on the big screen in front of everybody, why don’t you run that same tool five times in a row and I’m going to show you something?” And he ran it. And the tool enumerated my device five different ways. Each time as a totally different device. Because I wrote the product to not be enumerated. You can’t do recon on that product.

Brian Contos:
Sure.

Andres Andreu:
And this guy, you saw his confidence just shrink down into the size of a raisin. And it was like, “Dude, be thorough before you come in here making accusations like that.” But my point is, if a device on a network is sophisticated to that level, it’s very difficult to pinpoint certain things on our network. I think a lot of product vendors these days assume that nobody does anything sophisticated like that so they look for all the generic stuff.
They’ll literally go off of an open TCP port. Hell, you can run SSH on port 80, right? But they see port 80 and they go to web server. You go, “No, dude, you got to look at the protocol and see how it responds to certain requests. That’s the only proper way to say that device is X, or there’s a high likelihood that it is X.” And I just find that to be so unthorough and how it is, product vendors need to rush to market and sell product. You guys are in that space. You know.

Brian Contos:
Yep.

John Vecchi:
Yeah. And it’d be interesting to get your thoughts on just all of this challenge. And I love the way you talk about the attack surface, how we talk about it all the time. And again and again, we walk into very, very large organizations across manufacturing, utilities, energy, healthcare, finance, retail, logistics.
It almost doesn’t matter, right? And 2030, sometimes upwards of close to 40% of the attack surface includes all of these xIoT devices. And when we finally show them that visibility, they’re astonished. Like it couldn’t possibly be that many because it’s so hard. And so there are all these challenges you’re talking about. Hard to get the visibility, the passive monitoring tools. It’s tough. They want to listen. And unless those things are talking, there’s nothing to listen to. And at best, it’s kind of 40, 50, maybe on a good day, 60% certainty of what the heck that device is.
And of course, if you’re looking at kind of OT, ICS, industrial IoT devices, they’re very sensitive. Some of them are very old. You can’t just go, I call it waterboarding a lot, right? You can’t just go throw a vulnerability management tool and scan the things and throw them over a table and waterboard them because they’ll just die in many cases. So all of those things together make it so hard to just find these damn things. So finding them and understanding what they are and their posture and the risk assessment even before you think about at scale safely, like rotating credentials, like Brian said, basics, right? Rotating, let’s shut off extraneous ports and protocols. Maybe if the device allows it, and we can do that let’s patch some of this, the firmer that’s six, seven years old.
And even in many cases, I’d love to get your thoughts on just monitoring these, right? Because if you look at them from an IP Mac address, sorry. They move, they change. Yeah. Forget it. A lot of times, just monitoring these things to understand where they are, how they’re changing, if there’s drift from an environmental or configuration perspective. So there’s all these things. How do you even grasp all those and deal with it?

Andres Andreu:
So the firmware point to me is a very sensitive one. Unless you have validated signatures from the manufacturer of a device, you should never apply a firmware update anywhere. Now, this is coming from someone who ran a team who would modify firmware for research purposes. And if you didn’t have the original signature of that firmware file, because at the end of the day, it’s a binary file, right? If you didn’t have the signature from the manufacturer and you took ours, it applied cleanly to your device.
But now all of a sudden, one example is we actually took a piece of firmware, we modified it so that every packet that is saw, it split. It accepted the packet and then sent me a copy somewhere else. Now, unless you’re monitoring the network, you would never catch that. Your device was functioning properly. It said, “I have the latest firmware. No problem.” You got to Tommy Nation States don’t have those capabilities. If my team and I were able to do that in a weekend.
So unless you’re actually going through the pain, I’ll use that term loosely, through the pain of validating what it is you plan on applying, you should be very wary. This is where I am anti patching, because you need to know what it is you’re patching, what the patch is, make sure the firmware is good, because otherwise you could be asking for some serious trouble.
Now, in terms of monitoring, you brought up a very interesting use case that I struggled with for many years when I was in that the ICS space. Taking a look at the configurations of let’s say a PLC and being able to track it over time sounds easy. And you think, hey, PLCs don’t really change that much. The ladder logic doesn’t get changed often to my … at least I was in that space eight and a half years. I hardly met anybody who made lateral logic changes to their equipment. They knew what it was, but the lateral logic was built 20 years ago. The device works, don’t touch it.
So you would think it’s relatively easy to monitor that. Turns out to be quite challenging because the way you get to config remotely, over the network, the way you get to config from some of these devices always presents a slightly different picture, a set of deviations from previous reads of the config. And so setting that baseline turned out to be subtle, but challenging.
And so with the ICS space, there is that dimension to it. Some of that equipment is, to your point, finicky. I mean, how you run on a regular port scan on an old PLC, you’ll knock it over, right?

John Vecchi:
Oh, yeah.

Andres Andreu:
And so you have to be very careful when you deal with these devices. We were going to integrate with a vendor who, for instance, claimed to do passive reading of network trafficking, can read all the devices on your network. Turns out they were doing it by SNMP reads, but that assumes that you have SNMP traps, that you catch the actual SNMP traps as they go from point A to point B.
What happens if those traps don’t take place while you’re reading the network? Then you don’t know the devices there. So there’s that ever revolving challenge of do I do it in a passive way? Do I do it in an active way? Do I find a hybrid model? It’s not an easy problem to solve, especially with some of that older equipment.
I think things have changed now because a lot of the, from what I’ve seen, at least a lot of the newer equipment supports modern day protocols, which means that there’s a different level of resources and there’s a different level of sophistication and maturity in terms of what’s built into the devices. But I know for a fact from some of the environments I worked in, that the equipment that’s still out there is 30, 40 years old. Yeah.

Brian Contos:
Oh yeah. Yeah, John and I have even seen like Windows NT4.0 supporting devices. And that’s been end of life for what, 15 years or more, but you know.

Andres Andreu:
Well, let’s be careful because yes, NT has, and I don’t … I’m going to make a statement based on what an expert told me. I don’t touch Windows. I don’t run Windows anywhere in anything. Not at home, not at work. I don’t touch Microsoft products. Modern-day Windows still till today, still has an NTDLL that’s been carried over from the NT days. It’s still in the operating system today, and it’s still used by the operating system.

Brian Contos:
Sure.

Andres Andreu:
If that’s not disturbing, I don’t know what is.

Brian Contos:
Yeah. Yeah. And it’s crazy when you think about that. You’ve got these environments with old, new Windows, Linux, to your point, they’re speaking Modbus or DMP three maybe TCPIP, wired, wireless, Bluetooth, serial over ethernet, and everything in between. You’ve got this old and new combination, and it really makes it challenging, I think, for a lot of organizations.
But if you were to take a step back and let’s say you’re hired by a nation-state or a cyber criminal organization with really deep pockets, are there any specific types of devices that you think you might target? Is it the home wireless access points and doorbells and HVAC controllers? Is it the enterprise printers and digital cameras, or is it the industrial equipment, the PLCs, the robots, Siemens, things like that? Are there any particular devices that you’re like, “Man, this thing, this is just open range right now?”

Andres Andreu:
Yes. So I wrote most of the offensive code to test the capabilities of our products when I was at Bayshore. And one of the programs that I wrote was a … the word native is important here. It was a native DNP3 denial of service attack. So not a TCP denial service, not a UDP flood. A DNP3 denial of service attack. There wasn’t a product in the entire ecosystem of a major, and I mean major power distribution provider that we were working with. There wasn’t one product in their multimillion dollar stack that could stop that thing.

Brian Contos:
Wow.

Andres Andreu:
And I still have that script, by the way. I don’t think there’s anything today. I wrote a defensive mechanism into our product, so I know my product … well, the product that Ops SWAT now owns, I know they can stop it. But that script was just absolutely nasty because it spoke at a certain protocol that most IT security devices do not understand, and it took advantage of protocol level functions that are available in the power space via DMP3.
And it just took advantage of those function calls in such a way that it would literally knock over the actual devices on the other side. Now, once you’d knock over one of those DMP3 controllers, you have problems because once a power network, because you know they’re closed networks, once they go out of time sync, which they will when the control is out, you got problems because stuff, as a fail-safe stuff will start shutting down.
And it was so interesting watching the dominoes, right? Once we flipped that first one, by knocking over that controller, watching the … in a non-production environment, watching those dominoes go down, and these people, you could see it by the look on their faces, they were like, “Oh shit.”
Fortunately, I’m one of the good guys. So I would never release anything like that, but I always have to think how long before attackers learn these protocols and figure this stuff out? Because one point of interest on the ICS space, all of the attacks that you’ve seen touch the ICS space have been IT level attacks that happen to touch a machine that sits within a network of an ICS company. Show me a native ICS attack. They haven’t happened yet.

Brian Contos:
Sure.

Andres Andreu:
And so my question stands. How long before the nefarious actors figure out these protocols and start writing native attacks for that entire side of the world?

Brian Contos:
Yeah. Instead of trying to pivot over and yeah. No, that’s a really good point, actually. Very interesting. Well, let me ask you this as well. So I think most people intuitively understand, hey, if I attack a power and energy system or transportation, oil and gas pipeline, whatever, it’s a sabotage type level attack and stuff that can be done there. But I know, or I’ve heard, and I want to get your opinion on this, that a lot of the intellectual property and sensitive data for batch and discreet manufacturing, like a pharmaceutical for example, how they make a specific drug, what they mix it with, and temperature and ultraviolet light or whatever it’s doing. That’s not stored in some Oracle database or some flat file.
So all that intelligence, that sensitive data it’s kept on those OT devices and what exactly they do that are left open, is that really the case? And is that the case today that there’s just vast amounts of sensitive data that could be very valuable to a nation state that wants to steal that and then compete with that company potentially? Or has that been resolved? Is that no longer an issue?

Andres Andreu:
To my knowledge, the entire ICS space still operates the way you described.

Brian Contos:
Oh, wow.

Andres Andreu:
On the first half of your question. Think about it like this, look at the water manufacturing industry. For instance, the level of fluoride that gets released into water supplies is controlled between a PC with a human controllable interface to a piece of equipment, most likely a PLC. That PLC holds the value of how much fluoride it releases. It can’t exist anywhere else because you can’t just be making constant remote calls.
So it gets set in the configuration of that PLC. If you want to change it, you change it on the PC and then send the change over. But guess what? That means someone else, unless the network’s configured properly, someone else can send that same change request to the PLC. Unless that PLC is set to only accept requests from this one device, which unfortunately is usually done by Mac address, which is usually …, well, not usually. Can be easily spoofed.
There’s your conundrum, right? And so yes, it may not in the pharmaceutical use case, by the way, the entire formula won’t be stored in one device, but the pieces that are relevant to what that device is controlling are stored on those devices, on those endpoint devices. So you could holistically analyze the configuration of end devices on a network and reconstruct the entire formula.

John Vecchi:
Wow.

Brian Contos:
Yeah.

John Vecchi:
Wow. And so there’s a great example of potential IP theft, espionage kind of a thing. The other thing we’re seeing, Andres, I’m not sure if this is something that’s on your radar as far as a concern. You think in terms of OTICS industrial systems is given the fact we talked about the problem that most of these things are deployed with default credentials or if they’ve ever been changed, they were maybe changed once upon installation, provisioning by a non-security team.
It’s like a facilities or God knows what. Even going into the medical side, you could include in something like an infusion pump or monitoring. And so what we’re seeing now is the ransomware gangs potentially targeting these. And one of the things that we could see could happen is they could come in and immediately, because you can simply look up the credentials on Google if you wanted, it’s not like that’s a big secret on a lot of these things.
So if they know the default credentials, they could literally log into these devices and the first thing they could do is change the passwords, lock everybody out as part of a pretty effective ransomware attack and say, “I’ve just changed the passwords on all your devices. Good luck to you.” Does that seem a reality is some are worried about?

Andres Andreu:
A hundred percent. Put ransomware aside, I can pretty much guarantee you the next generation of APTs are going to be doing exactly this. What’s crazy with that is, and I just spoke about this yesterday, factor in all of these developments with LLMs, Large Language Models. Imagine a piece of APT sitting on a network with an LLM engine and the capability to extract data from your entire network and learn from it. Now all of a sudden you got razor sharp strategic attacks that become possible to anybody who just asks that LLM the right question.
Hell, if I can think it up, I know somebody else’s already. Right? That’s scary. Much scarier than a lot of the stuff we’ve spoken about during this session because now you’re starting to take out a lot of the guessing, the enumerating game, the recon game. All of the answers are sitting there waiting just for somebody to ask the right question of a particular NLP engine.
So I think the game is changing dramatically, literally as we speak. I think another thing that’s starting to become possible is the morphine type attacks, which make them super difficult to detect. I played in that space a little bit. For instance, again, we were working with a three letter agency and they were bragging to me about all of the equipment that they had that they could detect the port scan from anywhere and stop it instantly, this and that.
And I was like, “That’s great.” So I took that as a challenge. I went back to my hotel that night. I actually open sourced a piece of this because I had to and I said, “Okay, how could they possibly detect every type of port scan?” And so I wrote a port scanner, just hear me out that ran these 65,535 queries, each one per a different socket via Tour.
So you got 65,535 unique requests to see if this one port is open. But my code knew how to put all that together to get the final result. There’s no pattern for them to latch onto. Right? Unless you tell me, “Okay. Yeah. Well, the pattern is 65,535 ports each from a unique IP address.” Who can detect that? So that cat and mouse game, I think is starting to evolve to a point where things are going to get really, really tough for the defending side.

Brian Contos:
Yeah. Especially when you take that and maybe they say, “Okay, if something’s being hit 65,000 times, what if you do it low and slow? What if you decide to do this over a period of two months instead of two hours?” Right?

Andres Andreu:
Which by the way, you look at my code, it does that. You can just tell it what min and max random second interval you want to wait between each request. Yes.
Brian Contos:
Nice. Nice. Very cool. Very cool. Well, Andres, I can’t believe how quickly the time has passed here. But one last question I want to throw there out for you, or statement rather. There’s a lot of folks listening to this and they’ve got xIoT environments and they’re trying to figure out where do I start? What can I do? Obviously, we’re behind the curve. What steps can I take? Any advice for somebody that’s trying to get their arms around their IoT security?

Andres Andreu:
Yeah, be extremely diligent in terms of basic hygiene. I think basic hygiene covers your last mile issues. And also, I’m not a buzzword guide, but there is value to pursuing zero trust type models within this space, within the IoT space. And something very simple like an MTLS relationship between a client and server goes a long way in terms of implementing protected mechanisms to your ecosystem because if the server literally will only accept requests from a client that has the same exact private public key pair, O then all of a sudden you limited the surface that can speak to your server, and in turn, you bought yourself some protection.
It’s not foolproof but if you really wanted to start adding effective layers, that’s one layer that a lot of people overlook. MTLS to me is a very effective mechanism, especially like at an API level, super effective. But I would start with the basic hygiene and really understanding what’s in my environment? You have to open yourself to these other protocols that we touched upon when we spoke here today because they are part of your ecosystems.

John Vecchi:
Yeah. That’s great. Andres, thank you so much. That was really eye-opening and such an informative discussion. I’m sure our listeners really, really enjoyed that. And again, for our listeners, Andres, is there a place to reach you on social if our listeners want to find you?

Andres Andreu:
So the only social media I do is LinkedIn simply because it’s supposedly for professionals. But I do have my own site where I do blog often. Right now I’m working on my second book, so I’m not blogging as much, but I do blog pretty fairly regularly. So yeah, those are the only two real public areas.

John Vecchi:
Awesome. Well, Andres, thanks again so much for joining us.

Andres Andreu:
My pleasure. Thank you for having me. This was fun.

John Vecchi:
And again, remember everybody, the IoT Security podcast is brought to you by Phosphorus, the leading provider of proactive, full scope security management, and breach prevention for the extended internet of things. And until we see you again, I’m John Vecchi.

Brian Contos:
And I’m Brian Contos.

John Vecchi:
See you next time on Phosphorus Radio.