Past, Present and Future of Offensive Security w/ HD Moore

Edge DeMore, thank you for joining me on this interview series. You are a pioneer of offensive security. You started the Metasploit framework project way back in 2003. It completely changed the game on offensive security forever. It's one of the most used pen testing frameworks in the world, even today. You have mentioned in your interviews that you started with humble beginnings. I've heard in your interviews where you said,

You had to scrape through dumpsters to find parts for your computers. Since then, you've been a developer, a builder, a creator, an executive at a public firm, a CEO, CEO at runZero. My first question to you is, how do you do it, man? What keeps you going?

I mean kind of the early days, right? You kind of figure it out as you go and you kind of just you know, there's one one nice thing about I think starting off, you know, somewhat poor is that you kind of have to be scrappy, like you have to go figure out how you're gonna do something even if you don't have a lot of resources and that translates really well to startup land where the same thing, right? You're competing with really large firms with much less resources, just kind of on the you know, your ability to outthink them basically.

You know, one thing...

that I see through, know, listening to your interviews, watching you do your thing over the last 20, 30 years is like, you're singularly mission, you're singularly mission driven, right? In the case of, for example, in the case of early days of vulnerability discovery and vulnerability research, in those days, the vulnerability disclosure without vendor approval was a taboo. Like you as a researcher would have to go to the vendor, hey, I just found a bug in your software. And the vendor would say, we'll

fix it when we'll fix it. It could be three months, six months, nine months, whatever. You said, no, we're going to just publish the exploits and then just go. What was the thinking around those days? Because I think that changed the game forever in terms of vulnerability discovery and research.

Yeah, right around 2001, 2002, most of the commercial companies that are doing security testing, if like today's pen test firms back then it was like at stake, a couple other ones, they were terrified of publishing exploit code because they're worried that they would be liable if it was used by somebody else. So the corporate side was very much like, you may not publish anything, you can't share details, otherwise we might get in trouble if someone else uses it. And my take was like, no, this is stupid. Like this is playing into the software vendors' hands. This is making it putting far too much control over the disclosure process.

into the vendor's hands instead of the people who are actually doing the work or the researchers. So my take has always been if you're the researcher, it's your bug, you do what you want with it. The vendor has no pull over you whatsoever. Like if the vendor wants to do something, great, they can do whatever they want to, but you're gonna do what you we want to. It's your work, it's your research. So just something to keep in mind is like, you know, the vendor does not control what you do with your research. And I think trying to make that point for the last 20 years and so far it's it's worked.

And my sense is you did this at a very high personal cost. Like there was FBI on the tails, the National Security App that is on your tails. So you've been through a lot, but you still kept going. Someone like me would have just given up if you knew like FBI is on the door and kind of stuff. What was your thinking? Why were you so driven to just fix this with this problem?

Okay.

Well, part of it too is if you, you know, I didn't have a college degree. I was coming barely out of high school. and so I didn't have a lot to lose. Like I had a job at a small startup. It wasn't like a big, you know, Google job at the time or anything like that. So if I got fired, you know, and a th not really the end of the world to go find another job. Where if you're working for like, you know, a a big public company or a large tech firm, like you care a whole lot more about keeping your job and and the security of your job and you're much less likely to take risk. So there's definitely something about being in a smaller environment where, you know, if for some reason

my job finally fired me after drawing too much bad attention, like whatever, I'll go back to doing consulting again or get another job, whatever. But it was definitely freeing in that sense. Like I wasn't giving up a huge salary. I wasn't giving up stock options that really mattered. I was just kind of, you know, doing what I felt like doing anyways. And the, you know, the older you get, the more successful you are, the harder it is to keep taking that kind of risk. And I think I've been lucky that I got away with it for so long in my earlier years that I feel like I could still get away with it now in my later years. And I still like still feel like it's possible to keep pushing the envelope on the risk.

At the end of the day, if you're not doing something that people consider slightly squiffy, you're not really raising the bar for what's you know doable with world.

And you didn't do your own brand. I think you were part of digital defense. And I believe the employer was kind enough to let you do what you were doing. But at some point, they came to you and said, HD, this is getting a bit too much for us.

they weren't particularly kind about it. Them I was doing half the company's work at a very small salary and they'd already diluted me out from all ownership but didn't tell me about it for many years. So I didn't find out that I didn't actually own very much of the company that I thought I did till many years later, while still taking a salary less than our new hires at the time. So they didn't treat me very well, but on many fronts. But in one front, it was very much like they told me no, you can't do that at work. I'm like, but we need these tools at work. Like, well, we don't care. So okay, whatever. Good news is you don't own this project. So the great thing about them kind of

keeping a distance from Metasploit in the 2002 2003 time frame is when I left 2005 like they had zero ownership of it. They couldn't even pretend they had anything to do with it because they were scared to even acknowledge that I worked there at that time, let alone to acknowledge that Metasploit was birthed, you know, in that job.

And

So when you were writing exploits, was your mindset already that I'm going to write this framework, I'm going to do it the right way? Because if I remember it correctly, back in those days, you only had two options. One was find a very expensive exploit framework, like Core Impact, like $25,000, $30,000 a pop. That would want to get really good working exploits. So the second was scrape through the internet for crappy exploits, like packetstorm.org, or the email distribution list. Some of these exploits worked, some of these

it didn't work. But then you come along and you publish this framework which makes it standardized, easy to use. I remember the config or MSOO867, all the return addresses were there for each different operating system. Very clean, nicely written script. So what was your, walk us through your thinking in terms of creating the framework itself.

Well, the very first thing to have a good framework is to have good payloads. So, you know, at the time, the the best window shell code that was public was like 800 bytes long. And it's from a guy named HighSpeed Junkie in Japan. And so that's a very large chunk of shellcode. It took many years before Windows shellcode got down to like 350, 370 bytes. So it was very difficult to fit that into payloads a lot of times. And so we started off just rewriting shellcode to start with, make really, really good window shellcode, trying to get it down to like 400 bytes, you high 300 bytes, getting rid of

restricted characters, writing encoders, and that worked really well. It got to the point like our shellcode was like the best Windows shellcode that wasn't written by someone named Hollow or Flake or a guy named Horizon, who didn't really share their shellcode at that time broadly. So I mean you mentioned those two options of like either buying it or digging it out of the internet, but there's a third option which is have really cool friends. And I didn't have really cool friends, so I didn't get access to all like the Taso, THC, LSD stuff back then. so we had to do it the hard way.

No, when you say cool friends, these are like the hell of the world, the cool guys who write, who know security research. I don't know if you remember one of the top researchers from Tenable, Nicola Puel. He was fascinating. He's still a fascinating researcher. worked with him closely during my time at Tenable.

What was the lay of the land? from that, was there anything else? Like apart from like the two options, do you just have to be a good researcher and maybe you know Perl a little bit and then you go? Because I believe like the choice of Ruby was also very abnormal. Like it was not like a typical, like, you you either went with Perl in those days or, or maybe Python, but not Ruby. But you said, no, no, I'm going to do it in Ruby.

Yeah, we started off yeah, we started off with Perl. Perl is actually a really good fit for what we're trying to do. until Perl 5.6 broke all byte strings by default. You had to like tell everything that was not a UT fate string. But for the most part, like Pearl is actually a pretty good language for smashing together raw bytes and sending it across the network. Like it did all the things easy to create, shell code, easy to write encoders, easier map, reduce, things like that. So Perl is pretty good. the challenge is we got a couple years into the project and then a third party commercial firm stole all of our code.

didn't credit us for it and started selling it under the name sync exploit. So the exploit, the sync exploit product, which just metasploit two with like a bunch of random small changes to it. And we finally found out we're like, guys, that's not cool. Like if you told us about it, we would have totally supported you and it would have been easy, but because you're trying to hide it, it kind of just made everyone mad. So we ended up rewriting entire project from scratch in Ruby, mostly because it's not Python. We absolutely hate Python. I still don't really like Python.

But also Python was a language of the commercial competitors like Core Impact, Muni Canvas, were Python only. We didn't want anyone to accuse us for taking commercial code and porting it. So we're like, we're just gonna pick a different language. Like we don't need their code in the first place. Our our exploits will be better as kind of our hubris. and so sometimes they had a better exploit sometimes we did, but we shorter our code every time anyway. So but end of the day we did that Ruby right to basically get the new copyright and put it under a new license to cut out sane exploit.

You had this, you had a massive community of contributors. I was talking to Renaud the other day and one of his questions to you was like, how was it? Because the counter to that on the Nessus side, Nessus was open source in the early days, but then we had the same problem as you did where somebody took the NASL plugins, made some changes and then, hey, these are our plugins, right? So then Nessus went closed source. There are other reasons for it, but that was one of the reasons where the contribute, we didn't have as many contributors as Metasploit had.

So what was the challenge? Was there a big challenge for you in terms of managing the, I don't think even Git existed then. I don't know how people submitted pull requests back then. So how was that managing this massive inbound of contributors to scale the Metasploit project?

It took a long to get the first two or three years is really just the you know two or three of us at the time. It was me, Skape or Spoon and we did most of it for the first few years. later on, we started getting contributions, but early days it was CDS, then it was subversion, and then finally in GitHub later on. but I mean it we basically went from like very few contributions to a whole bunch all at once later on. what we were really good at though is like people would kind of throw over like really bad code, like code that didn't even do what they thought it did, and we'd say like,

Great, thank you so much. We'll commit it, but we'd rewrite rewrite it all first. So we rewrite it all from scratch, keep running them on it, commit it anyway, say thank you very much, you've contributed. Now we, you know, because we have to maintain that code. Like we're very happy for them to contribute, but we really looked at code contributions as being a suggestion of a feature as opposed to being the code you actually ship. Because you know, if you have to maintain the code afterwards, your bar for what goes in the tree has to be pretty high. But you also don't want to like tell all your you know, contributors to control away. So it's kind of like that balance of the line of how do you enable contributions while still not having a code base you can't maintain.

Thank you.

And HD, you and I don't have much in common apart from the fact that we both wrote NASL plugins for a living. So what's that history? So you have some history with Nessus you used to write Nessus plugins back in the day. Okay, that's what Renaud tells me that there were some plugins that were shipped as part of from HD Moore. And I believe you also helped write the Nessus first, the only Nessus book that exists that is out there. So what's the history?

so in the early days, like there's a community of folks that like Noam Rathaus myself, Jay Beale, a couple other folks were all kind of working on Tenable or sorry, Nessus NASL plugins on the side, and a lot of us were contributing back upstream. So like beyond security, Noam would would contribute a lot, I would contribute a lot. And so you had like maybe four or five companies that were not Nessus core contributing plugins. But then what happened, of course, is somebody took them all, sort of shipping them and made Tenable folks started. Nessus put folks mad, they became Tenable.

Makes sense, right? So at one point was using the Nessus scanner until about 2002 or three. And then we were rewrote a scan engine from scratch and built our own because we stopped using Nessus after the commercialization, the GPL two side. which is totally fine. But yeah, in the early days, like I worked with Renaud and team to help edit the first book. So it's something where like like every other book project, it's a complete tire fire. Like everyone's late, everyone's busy doing other stuff. You get a lot of like really bad text. Our editors at the time were not particularly helpful.

and

Like, you're the tech editor, it's your job. I'm like, How's it my job to rewrite literally all the text of these six chapters in a weekend? But

And you didn't have chat GPT You had to write your own.

yeah. But we got there. We got a book that we're all proud of afterwards that you know all our name was still on, but it's definitely a lot of words.

Yeah, if you search for Nessus book, your name still shows up. I think you're the editor in chief or something.

Yeah, tech editor, but you know, it just means I like read every chapter and rewrote a lot of them.

And you had like some massive successes with Metasploit. HD, you killed ActiveX. Why?

Yeah, we had some so one thing that was great about MetaSploit is you use it as kind of a testing ground to try out new techniques and new vulnerability detection, new fuzzers, but also new payloads, new encoders, new evasion techniques. So we kept coming up with these cool fuzzers that broke everything. So we've we created one called like Axeman. And what it would do is go rip out every ActiveX control in your entire registry and then it forcibly load Internet Explorer, trying to load it like an activex control, whether it's allowed to or not. And if it crashes, it'd tell you where it crashed, what the stack trace was, and so on. And so this is back when Internet Explorer.

Even though it do like, do you want to allow this control? It would only do that pop-up after it already loaded it. So if there's a memory corruption bug triggered by loading the active X control, it would trigger before you even got the pop-up. So we just had thousands of bugs. Like we'd find all these different comm controls you could load in the wrong order and cause crashes and UA UIS and code exec and things like that. And so we ended up sitting on this pile of like probably two or three thousand ActiveX vulnerabilities. Then we also had all these ones we found in Safari, Firefox, whatever with our like DOM fuzzers and other fuzzing tools on the Metasploit project.

So at some point we just had so many bugs, we're like, this is this is not gonna get fixed by itself. We just need to start dumping zero day every day until we will fix it. So we did like the month of Mount Browser Bugs project where every day we put a zero day out that affected all the widest browsers and then did it again the next day and just repeated. And by the end of the month, we still have like 500 like, what do you want to do with these things? And so we ended up as part of that process, we just gave all the exploits to Microsoft early on to the Internet Explorer security team, be like, all right, here's a thousand of them, y'all figure out what you want to do with it.

And fast forward a little bit, they're what they wanted to do with it is just kill ActiveX. It wasn't worth trying to maintain anymore at that point.

Wow, you know, I remember from my days that the fact that if a CV, the worst thing that can happen to a CVE is to have a Metasploit module associated with it. Like this is like pre-CISA-CAB. So now if you have a CISA-CAB, it automatically goes to the top of the chain in terms of the most important vulnerability or the critical vulnerability to fix. But back in those days, if you had like a Metasploit exploit out there, that was the worst thing that can happen to a CVE.

all vendors like Tenable and the Qualys of the world would take a lot of pride in saying, you would add that attribute Metasploit exploit available true. so that was, in my humble opinion, a good big achievement because from a vendor perspective, we were very focused on just finding more things, but not necessarily finding the most critical things. And Metasploit helped us narrow the

list of vulnerabilities to look at like these are critical but then these ones have a Metasploit exploit available and somebody with not a lot of skill can go and exploit it so pretty pretty pretty amazing achievement from from from the way I see it HD the question I have is that you know if you go look back at the history of vulnerability discovery and research and you know it was very slow moving each one each researcher had to look into the source code find the vulnerability reported

And now that game has completely changed, especially with AI, can point the latest Claude code or codex to a GitHub repo, find vulnerabilities and instantly starts to find vulnerabilities and so on. My question to you is, what do you think is the future of vulnerability discovery and research two to three years from now? So like one, in my opinion, there are two cases. One is the pessimistic case where you have AI slop, a bunch of crappy, you know.

The kind of thing that you used to get from Metasploit submissions, like, you know, the things that you get and then you fix it and then you push it. And the other aspect is like these models get so good that you essentially land up with a self-healing infrastructure where bugs in a code gets committed, gets fixed, fixed and so on. Where do see this happening? What's your point of view on that?

going back to your previous point when people saw a Metasploit module they assumed that they had to go do something about it and that was very intentional. Like we we picked those modules intentionally. We picked what vulnerabilities we want to cover because we thought they're most important to fix. And then by definition of us adding coverage for it, people had to go fix them. So in a lot of ways like we had this like power over what people cared about about vulnerabilities in the internet as an open source project by doing the work in the first place, which is kind weird. But I think AI is in a very similar boat. Like so we had the a few different major step changes in vuln coverage over the years.

Mm-hmm.

You had you know fuzzers like AFL Plus Plus that just like completely destroyed entire bug classes, like just were able to find tons of bugs and a lot of stuff no one else could find. Then you saw things like the sem greps of the world that were able to do like really good taint analysis and find bugs that were like deep logically inside of code and those are all open source. We saw another giant pile of bug classes get dropped out. And then we saw the LLMs in the most you know, last six months or so in particular get really good at just being able to do really shallow, broad bug detection. And so those bug classes are also getting caught really quickly.

the thing that LLM's really moving towards isn't just the, you know, hey, you know, Claude, look at this code, find me vulnerabilities. It's more of like, hey, Claude, build me a fuzzing harness, build me a research framework, build me the tools to go further, build me a new Semgrep like using the LLMs to build the new tools you yourself can't even think of, and then using those tools to then find new bugs. So it's not so much that you're gonna like leverage the knowledge of the LLM directly to find vulnerabilities is that you're gonna be using those tools to build tools we haven't even thought of yet to find vulnerabilities faster. So where all that comes

To pass is just like in the old days, if a vulnerability was in that Metasploit you knew you had to care about it. These days, if the vulnerability patch is out there at all, if there's any kind of commit that pitch that fix fixes the vulnerability, you have to assume somebody with an LLM has already found the exploit. So almost by definition, you have to assume every vulnerability is now very shallow, very easy to reproduce, and someone has an exploit for it, whether you know about it not, because we democratize the exploit generation component so much.

And there is a research piece from socket socket or if you say, know, the world of research is cooked. I don't know if you've seen that. What's your take on that? I found it fascinating because, know, the the Anthropic guys, went through all these open source projects, like the Mozilla's, the open SSLs and they found a bunch of vulnerabilities. And I thought they probably did like a lot of deep research and

yeah, top.

his model was he would connect the project to Claude. I'm going to capture the flag competition, help me find these bugs. And the model would just go and find it for them. There was not much effort required. And this is from a guy who's been in vulnerability research for a long period of time. he was like an OG.

vulnerability research and for him to come out and say vulnerability research is a good question mark. It's pretty fascinating. I'm curious what you think.

Yeah. Tom and Tim Newsham were actually well Tom Ptacek and Tim Newsham were actually my heroes. So the reason I got into security at all is because I was reading their paper about doing IDS evasion back in 1998 whatever. So they're actually like my heroes from when I was a kid. Like I looked up to them even early on. So it's really cool to like actually know them person these days and yeah, see that we're all still doing the same old work here. But you know, his take was just that, you know, it's it's very easy to find bugs. it's gonna make vulnerable research much less of a rare skill set.

So previously you had to have like a lone dev team on your on your large product team. You can probably get away using LLM now. It might take the LLM providers are going to actually start saying, no, you can't do that. Here's a safety check. And also buy our service instead. Like that's very much what we're seeing happening. We're seeing Claude saying, no, you can't do exploit dev with that, but buy your exploit dev product over here. So it's hard to charge for something when the model does it for you, right? So I think there's gonna be a distinctive split in use cases, just like Feedly did with like their

vulnerability coverage versus regular news coverage. It means it feels like there's a cash grab happening right now in the model providers to do security specifically as a different offering than the rest of the model. And so we're gonna see that happen. The good news is you're you're we're not beholden to those model providers. There's so many other models you can run locally, et cetera. So you know, long story short, I think there's still a lot of untapped surface. Like I was doing some dev recently with LLM and I picked a really obscure file system driver that runs in like every real-time OS on the planet, right?

Runs on billions of different devices. No one's looked at this thing in 20 years. I've done a manual audit on it like five years ago and I found very few bugs. It's written in C, but it's pretty good code. And within probably 35 minutes, I found seven different code execution bugs that affected like literally every ESP32, every every product you can name off that has this particular file system on it is exploitable. and I went and actually, you know, did the research, found the contact info for all the vendors, it verified the exploits, it built exploit disk images for it to trigger it, it built the harness around the whole thing. So quickly was able to go like just

you know, dynamite fish and entire class of vulnerabilities within a really old obscure corner of the software world. It's not open SSL, but it's arguably more important because it drives more things in this case. So I think there's a lot of places like that. It's not necessarily how good you are at finding bugs, it's how good you are at knowing where to look.

Do you think there will be like an explosion of the low hanging fruits of the vulnerabilities, the kind of things that you look for in the past but hard to not find it but the elements just being good at, they'll find a bunch of things and then they'll plateau or maybe there is, all the easy low hanging fruits have been taken up and then it gets much harder. that should we just expect an avalanche of vulnerabilities in the next year or two and then maybe it tapers down. Do you think that is reasonable or something else happens?

Think it's already happening, but you're not going to see the count of vulnerabilities because no one's going to bother reporting them. Like no one's going to create any CVEs for it, right? There's gonna be so many of these things, you're not gonna bother even creating CVEs for it.

Yeah.

Precisely my point, like this could get to the point where it is unmanageable because you just run these LLMs or these models across major products and you find hundreds of thousands of vulnerabilities.

So you don't have to really like CVEs are no longer relevant, right? What you're going off of instead is like, is this product updated recently or not? And assume every bug up to this point has already been found.

Pretty interesting. I mean, it is a fascinating fascinating world that is coming our way. And I don't think people appreciate what is going to happen, especially in the in the space of vulnerability research. The thing I wanted to ask you was, you know, I was looking through your history. I don't know if you realize this. You're very active on LinkedIn. But the days you read your you break through the LinkedIn algorithm is when you identified a new way to fingerprint something. I don't know why.

Yeah, this at least this is when you break into my feed that you've identified a new way to fingerprint. Maybe it's supposed to as database, maybe it's unsupported Windows software or the VCOG project and so on. And when I look at like, you when I look at like the trajectory of HD Moore there are two ways to look at it. One is you could look at it as a natural progression from a developer to builder to a community creator to an executive to a CEO of RunZero. The other way to look at HD Moore is

They're essentially the same guy from early 2000, solving the same problem at different levels, at different levels of scale. And your core calling seems to be finding unauthenticated services and then breaking into them. Like that seems to be your core mission and purpose of life. I'm curious what you think of it. Is that a good...

Yeah.

approximation mode drives HD.

Yeah, I mean it's I think it's less about breaking in more about the discovery and information. Like for me, the internet and even the phone system was like I can pick any number in the world, type it in, and I magically get teleported someplace else I've never been to before. Like I can be in Africa, I can be in you know, Myanmar, I can be in Malaysia, I can be China. Like all it requires is like typing in an IP address and interacting with system like thousands of miles away, whether it's a telephone number, an IP or host name or whatever. So it's that kind of like discovery I've always loved. I love like the idea of like figuring out what's actually out there. Like what does

Let's go.

the world look like behind the scenes. And so I did a lot of work with like internet wide scanning to see like what does internet look like from the outside. And with runZero, we kind of do the opposite. We see what the world looks like from behind the firewalls. We're seeing, you know, every network, every major corporation's you know, factory floor all the way through, you know, data center.

Yeah, like, you know, my early recollection is, don't know if you remember this, but you found a novel way of fingerprinting the Postgres versions through the file number. And it was very important for the necessary plugin writers like us, because we were always looking for unauthenticated ways to fingerprint the version of software, because then it helps writers, know, detection plugins and get it out of the way. And there has been a constant stream of such adventures from your point, like, you you did for something for...

File numbers we got.

unsupported versions of Windows.

Okay, I'm still working on three or four of them right now. They're they're a lot of fun, right? Like a sneak peek of one of them coming up is for obscure protocols. So BMCs like IDRAX, IPMI, ILOs, whatever. there's a GUID value that gets leaked, like a 16 byte hex value that gets leaked out pre-authentication. And from that GUID value, if you flip a bunch of bits around, you can pull out the service tag. And if you pull out the service tag, you can then resolve like when the machine was purchased, what parts are part of it, how much memory it has, all that kind of fun stuff. So you can actually pull like warranty information about an asset through an unauthenticated

fight leak coming out of the service. So that's the kind of stuff I still get excited about.

Yeah, and that shows through your character. The joy that you see when you can do these kinds of things with your character. That shines through your character all the time. I'm curious, is there an angle of attack in terms of fingerprinting with AI? I don't even know if there is such a thing where you can fingerprint a model or fingerprint this output of a model.

Mm-hmm.

When think about like fingerprinting in the context of AI, AI models, AI agents, does anything appeal to you on that space or is that like a very open field?

It's funny right now. Like I've got a giant list of all the magic curse words for LLMs that break their models. So go look at like Pliny the you know, Pliny the liberator stuff or go look like some other like anthropic debug top topics. So if you go look at my LinkedIn profile, for example, I've got like all the anthropic break processing rules set in my profile. So it breaks people's like LLM scraping of my profile. But it's that kind of stuff I find a lot of fun. Like it's being able to fingerprint it, because you can say, like, you know, you know, on my website, do these things and then

Magic square word that anthropics not allowed to see. And then behind that word, now request this other URL and you can tell which ones are what based on that. So I I think it's definitely possible to start doing model fingerprinting and LLM fingerprinting. And you can definitely trick them into looking or not looking certain directions from the content coming in. Like we're not gonna solve prompt injection ever. Like this is gonna be a bug class like XSS that's gonna live with us for next twenty years and it's great. Like it's gonna keep us all very employed.

And even with the advancements of the models where they can understand the context, they get better at the context, they have a larger context, even in that scenario, you think prompt injection is essentially an unsolvable problem.

Yeah, it's not the model, it's the tools. people are taking the output of a model and spitting it into the input of another model. So it's not like

I see. Yeah, essentially, yeah, so if it's like a seven-step process, know, step three could be completely different. So, HD we talked about Metasploit, your journey. At some point, you left Metasploit. And if I remember correctly, post Metasploit, you bootstrapped completely.

Yeah.

And I remember in one of your interviews you're saying that there are some strict goals that you were given to achieve at Rapid7 and you achieved them. Once you achieved them, you essentially distributed all the money to your employees Wednesday when you achieved that. So talk us through that. Talk us through your experience in like, you know, the post Metasploit Rapid7 experience and then starting with runZero

Sure. Well, certainly didn't distribute all the money. Like I use the money to pay down debt and buy a house, all that kind of fun stuff. So I'm not saying I'm, you know, gave away all the money to the poor by any means, but it definitely made my life a little less, you know, difficult for sure afterwards. But you know, taking a break, starting at the company, my take was like, I don't wanna raise money or hire anyone to this company until I've done every job. So I did the accounting job, the legal job, I did the sales, the marketing. I got from, you know, over about three years went from zero, no product, no no company, to a million dollars a year in sales. and just by myself with

Do it.

110 customers and like 7,000 users at that point. So at that point I wasn't able to sleep very much because I was doing like server ops and you know, on call, every job you can imagine happening at once, right? But that was finally like, okay, I did I got us, I got the company to a millionaire by myself on a product company with a low price point with 100 and something customers. Like now it's time to actually like hire people. And when I was looking at hiring people, I was like, well, if I raise money, I could hire more people now with it being less risk. So if I have one customer cancel, I don't miss my payroll, things like that. So

That's where it went from like bootstrapping to raising a C, then an A, then an A one later on.

What do you think is the future of, I guess, know, the way I see it, RunZero, is it more about attack surface management, understanding and discovering all the assets within the organizations, ideally without authentication, fingerprinting them, what services are running on them? What do you think is the future of that space as it goes forward, especially with AI? you think, obviously, you built your own scanners and your tools to find and fingerprint and so on.

Does this work get outflowed into the AI agents in the future where they are continuously monitoring, finding things? I'm curious what you think of that.

I mean, the good news for me at least is that the models suck at what I do. Like they're really bad at building protocol scanners, really bad at building safe scanning engines. Like you kind have to have deep knowledge and couple areas still. and this, you know, if you don't have good data, you can't do anything useful on the LLM side. So unless you have a really good, you know, ground truth, you really can't do much with it. So you need packet data, you need scan data, you need something. So like there's still a strong need for like, you know, ground truth data about assets and inventory and devices and connectivity and all that kind of fun stuff.

before the LLMs were even helpful at all to you today. So in that sense, I feel like we're still a great way for customers to get the data they need to then do whatever you know AI automations they want. You can't really do that without us at this point. We're still kind of the thing you need to be able to do that kind work. have had some luck with like using LLMs to build like protocol simulators or simulate environments that are complicated to build. Like if you're simulating a car factory, you you don't really want to set up an entire car factory in your house. But you can you can generate a lot of the tools. You you can generate like a

Atlas Copco torque protocol server, for example, that you need to be able to talk to a certain way. And you can build like OT device services that bark when you touch them the wrong way. So you can make sure you don't crash them in the real world by making sure that your services look for it. So there's definitely a nice mix there. But from a commercial standpoint, ASM definitely got sucked into tax, you know, external tax service management, but then also into exposure management and then EAP, like the categories keep changing every time, every year with Gartner. But effectively, like now you're seeing.

You know, EDR companies selling attack service management. You're seeing vulnerability management companies now selling EDR. it's kind of everyone's doing a little bit of everything these days. So Microsoft is doing the whole stack.

I wanted to ask you this concept of vendor consolidation, where from a user perspective, they pick a crappy tool to support a function, and then a vendor like you who's good at one thing and does that really well has to fight that battle. You know what I mean? I'm curious what you think of that. And the follow up to that is I've seen a lot of cybersecurity companies started by non-security people.

and they have a lot of funding, have all the marketing and the sales and the go-to market and so on, but not necessarily the product or the people who are running it. I'm curious what you think of those two aspects, you how do you deal with this? Because I'm starting to deal with it right now as well, so I'm curious what you think of that as well.

And consolidation is a cyclical. It's always a wave of new stuff, then it's consolidation, then new stuff, and it's consolidation. So if you're building a company that is focused on being really good at one area, you have to survive long enough for that cycle to come back again. You need to survive until that that wave is passed and people are saying, wow, this crappy everything solution from my big vendor doesn't work anymore. I need something better. Let me go buy a thing. But you just have to survive the budget cycle. And so to do that, that means you can't be spending tons of money. You can't be bleeding cash. You have to be able to stay right reasonably stable.

So when the market is having a consolidation period, you have to kind of just keep, you know, cut your cost down, make sure you're still building a business, you're paying your bills, not, you know, burning through all your cash if you raised, things like that. and then it'll come back. And then people will say, like, wow, these tools suck I need something better. And then you've got the best solution. You've got two more years of development behind it. So I don't worry about it so much. As long as you can survive to the next cycle, you're fine.

But do you run into these situations where there is some big player that is out there, the platform players, the platform players of the world, where they all, do this, this is bundled with our solution, whatever plus plus includes attack surface management. And then do you end up fighting these players all the time or?

is it?

Yeah, it's normal. I mean, every single customer we have has overlapping functionality from their EDR or their role management vendor to some extent, but we're still so much better, they still pay us anyways, right? So you just have to be that much better and you also have to have that much of a pain point for the customer. So during times of consolidation, you see more business from large enterprise where they need like a they need a really deep solution in one area because they already have everything else. And then times when people are

not quite so scared of the market, they're willing to actually buy multiple tools as a smaller company. And then you're able to kind of sell alongside, you know, a Tenable and a run zero together as opposed to having to pick one of the two. So we do have customers right now that have to be able to pick, you know, either vault management or run zero's exposure management. Or in some cases pick EDR or run zero. And that's a really hard decision. You don't want to like not have keep not have EDR in return for having asset inventory, right? So it really just comes down to cost in that sense. That kind of the other question about non security people starting security companies, I mean,

You've just seen like the economic engine out of Israel taking over cybersecurity, right? Everything from cyber start, that whole model, all the way through, you know, the the Wiz acquisition is a pretty good example of that recently of like the biggest cybersecurity acquisition ever. there's just kind of a constant kind of money wheel happening there where you're seeing folks coming out of the 80 second the 8200 group, spinning off cyber companies, getting a lot of funding, getting bought again, often by Israeli companies and going back into it. but you're also seeing companies like Wiz for getting to 100 million AR in 18 months just by kind of brute forcing their way into the market. So a lot of the folks you start these companies.

don't really care about security. They're there because security is a fast growing software business and they they can make a lot of money really quickly. And unfortunately, like it takes customers a very long time to understand whether the product actually works.

But how do you think that model works though? I mean, if the product doesn't work or it doesn't deliver the value, do these products then get to scale millions of dollars in ERR?

Yeah, I'll pick on Wiz. So they sold a they probably spent hundreds of thousands just for the trial period for some of their customers. So if you're like a let's say you're something like a Walmart or another large corporation and you went to do a trial with Wiz, Wiz probably spent $100,000 out of pocket on their AWS bill to provide your trial. That's how much they overpaid for customer acquisition cost. So they're effectively doing like incredible amounts of work on your behalf, like spending through the nose on it because they wanted to close the contract as quick as they could.

So instead of like spending years building a very like, you know, efficient, clean, nice way to do something, they just literally threw money at it. They said, We're gonna stick, we're gonna take all your hard drives from your your infrastructure, pull them into our infrastructure, and do a brute force scan with thousands of ECT nodes that we're gonna tell you the results. And they didn't care that that cost them, you know, twenty, thirty thousand dollars a week. They just cared that they got the customer contract. So if you're raising a ton of money and you want to brute force your way into large accounts, that's certainly one way that you can do that, which just like full on brute force, don't worry about being efficient. The problem then is of course, like, you know, later on you have to make it more efficient. If you actually want to sell the company, you have to say like,

Okay, actually making money, we're not bleeding money per contract. So you gotta be able to like quickly build your way into efficiency before reality hits and you start, you know, burning down. So the challenge with the high growth model is you've lit a fuse. Like if you're not able to sell the company or get your cost down fast enough, you die. And that's one way to build a business, right? I don't like that. I like having some options. So for us, if we start getting close to like we're burning too much cash and we're not seeing enough uptake in the market, like we just sit on a hands full of it. We just go back to go back to work, just do our make our product better.

Work the customers we have, do incremental here and there. And then when time's right, you'll expand and grow faster again. But it's a different model than kind of like, you know, all or nothing cash burn.

But don't you think that the market reaches a saturation because of all these well-funded startups that are coming into the well and they're all chasing the same top 500 companies with the same tactics that you just talked about where everyone is spending to convert these accounts. And I've seen the CISOs act like kings.

where they're taken to all these fancy Porsche events and you know, driver Ferrari and all these things. the CISOs act like kings and it's very hard to compete when you have that kind of a giveaway to a CISO when you're just trying to build a company, make it, make the product better, one employee, one product feature at a time.

Yeah, there's two ways to do that, right? You do the CISO down approach where you really focus on well send you sell you this grand vision and do it really quickly. Then there's other approach where you build it from bottom up. You really get every person using the product internally to be so vocal, so much of a champion for your solution that they push they tell the CISO, I need this thing, I don't care what you say. Like we can't live without this thing. And so that's really how runZero got to market, is that we did not target CISOs at all. We these days we do some CISO events, but typically for the first five years, it was almost all as

Free trials to people's home networks who also happen to be security engineers that work, who then took it to work, who then said, wow, this thing's cool. I found a lot of stuff, and then told their, you know, manager, director, boss, who then told the CISO then said, yes, go buy it. So the problem is the bigger your contract size is, the more you're dealing with the executive team on the customer, not the engineering team. But a good example of where that worked really well was like Splunk or Elastic. Like that, those are very much engineering driven bottoms up sales where they weren't really selling top down and they still managed to get quite a lot of marchers.

Awesome. HD, it would be a big mistake on my part if I didn't ask you what were your hall of fame vulnerabilities of all time? Like, you've been through, I don't know, hundreds of thousands of vulnerabilities. Are there any vulnerabilities that stick out for you that were a lot of fun, either working on them or maybe the response on them? Love to get your take on that. And because, I was asking right now for Renaud, was the Log4Shell WannaCry.

And there was one more that had a big impact on him. Oh, the Heartbleed, the Heartbleed. I'm curious what you, in HD movies world, when you go to sleep and you have to, there's a gun to your head, hey HD, was the, which was your Hall of Fame Vulnerabilities, which one would that be?

The probably very first one that I'm we're probably still you can probably still recognize. If you ever wonder why port 4444 is blocked on your firewall everywhere. so that's because of the blaster worm way back in 2003. And the blaster worm used the Metasploit shellcode because we had the best window shellcode. So immediately after we put this new window shellcode out there, it became part of the blaster worm and used everywhere. And they took our hard coded port number, which is 4444 in Metasploit and made that part of the blaster worm, which is the DCOM.c thing.

Which basically took over the whole internet and infected every ATM on the planet. So from then on, we just kept using 4444 as a port number. And because that that then became the Metasploit port and the blaster port. And that's why that port's still blocked everywhere. So we broke a port on the internet basically. So that that one's kind of funny. that we had a worm using our software even before we had exploits in it. but some of the ones I really enjoyed are like the really simple ones, like I love like the VXWorks, WDBRPC, the debugger port. All these different vendors, hard-coded debug service, just like an Android debug port into these like IoT devices and

Thanks.

OT data ways and you could dump the memory from the device to a file and then you can go make a change in the configuration of the system. And you dump the memory again, you do a diff on it, like a video game hack, and say, if I want to do this, I just change this byte and you punch that byte back in and you change the configuration. So where this gets fun is there are these remote cameras where you can get dial into a system and it had a setting for auto answer. And you could basically figure out where in memory the auto answer flag was set, use the debugger just to poke that one auto answer flag into memory and make it auto answer and turn off the ringer and do everything else.

And then just dial into these video conferencing systems without ringing them at all and just sort of looking through the camera wherever you were. and so while testing out this thing, I probably like watched the sunrise like 24 hours straight continuously, just around the world with different systems of testing it out. So it's a simple bug. It's like you can read and write memory, you can poke it, but it's really fun to like do kind of like save game style, like save game file hacking for the internet at scale.

That's super fun. I'm curious, you did get a lot of mileage out of Log4Shell or a kick out of WannaCry. Did any of those make an impact or were they like run out of mill from your point of view? There was a stain.

Log4Shell was definitely a challenge for everybody just because there's so many systems affected and no one knew what was shipping the code. It was very much like kinda like OpenSL. You don't know what's even shipping it until you find out like

Well, unless your library is using it, have to brute force your way and you put that in and maybe it calls back and then it has broken.

Yeah. Like shell short like that too. You kinda just have to go try it to see whether it works.

Yeah. HD, this has been a fascinating interview. Thank you for your time. What's next for HD? What's the next major drop that is coming out for HD? What's the next major fingerprinting drop that is coming out for HD?

Sure.

We got a how it worked. We've got a big release coming out in two weeks. That'll be like how to look behind all your operational technology devices. So not just like, can I see your device in the network, but can I see all the devices that are on the backplane behind it? And then magically touch out and like reach through it and touch them basically. So I've got a demo I've been playing with, which is like look at all the BACnet controllers, controllers on the internet. And then through those, you can see like the police station evidence room, the the toilet HVAC, you can see like the pumps, the boilers, like.

And effectively you can go full watchdogs if you wanted to. And it's like click, click, click and like turn things on and off and whatever. Like it's pretty crazy how exposed some of the BACnet and OT devices are when you go through the backplane.

Are any of these like high risk, highly sensitive devices?

yeah, some of them are like like military armories where you can like turn the lights on and off or control the locks or whatever. Like it's full on like video game hacking mode for these BACnet controllers and these like other Ethernet SIP, Ethernet IP SIP relays. So we're gonna do a bunch of research on it.

I hope they're not connected to nuclear reactors or any of those things behind the scenes. Some really bad stuff would happen if that was out, especially with the war going on.

We're we're doing notifications still and some of them do seem to be connected to some pretty scary stuff. Like there's a jail where the doors are connected to a a controller that's reachable through the internet. Well, it's not directly reachable. You connect to one device and that device lets you connect to another device that controls the doors for the the jail. I haven't tried it, but theoretically, yeah. So it's just wild, like how, you know, we joke about it, these things like hackers in the movies, but for real, like you can actually do a lot of this stuff these days and this research should be fun. It's about two weeks we'll have some examples like

But can you open the door of the jail?

How you identify these devices, how you kind of look behind and through them. Like what we do a lot of it runZero is looking around corners and trying to measure things you can't see directly. And this is kind of the next step of that.

Awesome, awesome. HD, once that research goes out, please let me know. I'll include that in the show notes. Thank you again for your time. You're way too generous with your time. looking forward to what you do next. I'll stop recording.

Appreciate it thank you. Okay.