Latest / Noise2Signal / EP 2. Past, Present and Future of Offensive Security w/ HD Moore

Transcript

EP 2. Past, Present and Future of Offensive Security w/ HD Moore · Noise2Signal

• Speaker 2: You started the Metasploite framework, completely changed the game on offensive security. Speaker 1: 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 in the world. Speaker 2: You killed Active X. Why? Speaker 1: Using the LMs to build the new tools you yourself can't even think of, and then using those tools to then find new bugs. Tom Tayshek Tanush and Russia My Heroes. Speaker 2: Do you think there will be like an explosion of, you know, the low hanging fruits of the vulnerabilities Speaker 1: There's gonna be so many of these things you're gonna bother even creating CDs for it. 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. Speaker 2: Is there an angle of attack in terms of fingerprinting with Speaker 1: Yeah, I I've got a giant list of all the magic curse words for LLMs that break their models. So a lot of folks who start these companies don't really care about security. Do you ever wonder why port four four four four is blocked on your firewall everywhere? ⁓ there's a jail where the doors are connected to a a controller that's reachable through the internet. Speaker 2: Ladies and gentlemen, please welcome H.D. Moore, creator of Metasploit Project, and founder and CEO of Run Zero. H.D. Moore, 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 you where you said you had to scrape through dumpsters to find parts for your for your computers. Since then you've been 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? Like what keeps you going? Speaker 1: 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 Speaker 2: You know, one thing that I see through, you know, listening to your interviews, watching you do your thing over the last twenty, thirty years is like you are 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, d 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, Well, we'll fix it when we'll fix it. It could be three months, six months, nine months, whatever. You said, nah, we're gonna 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. Speaker 1: Yeah, right around 2001, 2002, ⁓ most of the commercial companies that were 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 with the researchers. So my take has all has 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 twenty years and so far it's it's worked. Speaker 2: And I my sense is you did this at a very high personal cost. There was FBI on the tails, the national security apparatus at the on your tails. So you've you've been through a lot, but you still s you still kept going. Someone like me would have just given up like if you knew like FBI was on the door and kind of stuff. What was what was your thinking? Why were you so driven to just fix this with with this problem? Speaker 1: Well, part of it too is like 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 star wet. 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 you 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 you know 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 early 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 envelope on the risk. 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 the world. Speaker 2: And you you didn't do your own brand. You were I think you were part of digital defense. You were or a and I I I believe the employer was kind enough to to let you do what you were doing, but at some point they came to you and said, H D, this is getting a bit too bit too much for us. Speaker 1: Well, they weren't particularly kind about it. I was doing half the company's work at a very small salary and they'd already diluted me out from all ownership that didn't tell me about it for many years. So I didn't find out that I didn't actually own very much the company that I thought I did until 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 on 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 two thousand two, two thousand three time frame is when I left two thousand five, 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 Metasplate was birthed, you know, in that job. Speaker 2: And ⁓ in so when you were writing exploits, you your w 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, in back in those days, you only had two options. One was find a very expensive exploit framework, like you know, Core Impact, like twenty-five, thirty thousand dollars a pop, right? That I want to get like really good working exploits. So the second was scrape through the internet for crappy exploits. Like packetstorm.org style or like the email distribution list. You know, some of these exploits worked, some of these d didn't work. But then you come along and you like ⁓ you you publish this framework which makes it standardized, easy to use. I remember like the configureworm, the MSO867, like all the return addresses were there ⁓ for each different operating system. Very clean, nicely written script. And so what was your like you know, ⁓ walk us through like you're thinking in terms of creating the framework itself. Speaker 1: Well, the very first thing to have a good framework is to have good payloads. So, you know, ⁓ I'm the the best window shellcode that was public was like eight hundred 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 window 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 four hundred bytes, you high three hundred bytes, ⁓ getting rid of restricted characters, writing encoders. And that worked really well. It got to the point that like our shellcode like the best window shellcode that wasn't written by someone named Holler 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, T H C D, L S D stuff back then. ⁓ we had to do it the hard way. Speaker 2: No, but when you say cool friends, these are like the halvor halwer fakes of the world, the cool guys who write who know security research. I don't know if you remember the one of the top researchers from Tenable, Nicola Powell. He was a fascinating, he's still a facetic researcher. I worked with him closely ⁓ during my time at ⁓ Tenable. What was the lay of the land? Apart from that, was there anything else like apart from like the two options? W do you just have to be a good researcher and maybe you know pl Perl a little bit and then you go? Because I believe like it the choice of Ruby was also very abnormal. Like it was not like a typical like you know, you either went with Perl in those days or ⁓ or maybe Python, but not Ruby, but you said, No, no, no, I'm gonna do it with Ruby. What Speaker 1: Yeah, we started off with Perl. ⁓ Pearl is actually a really good fit for what we're trying to do. ⁓ until Pearl five point six broke all byte strings by default. You had to like tell everything that was not a UTVate string. But for the most part, like Pearl is actually a pretty good language for s 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, produce, things like that. So Perl's 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 is Metasploit 2 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 the 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 and Mini Canvas were Python only. We didn't want anyone to accuse us of 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 c or exploits will be better as kind of our hubris. ⁓ and so sometimes they had a better exploit, sometimes we did, but we shared our code every time anyway. So ⁓ but end of the day we did a Ruby right to basically get the new copyright and put it under a new license to cut out sane exploits. Speaker 2: You had this ⁓ you had a massive community of contributors. I was talking to Renault the other day and he one of his questions to you was like, How was it? Because ⁓ in the the counter to that on the Nessus side, Nessus was open source in the early days, but then we we had the same problem as you did where somebody took the NASA plugins, made some changes, and then hey, these are our plugins, right? So then Nessus went closed source to be s ⁓ 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. Right. 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, you know, massive inbound of contributors to scale the Metasploit Metasploit project? Speaker 1: To the long end the first two or three years is really just the, you know, two or three of us at the time. It was me, Scape, ⁓ or Spoon ⁓ And we did most of it for the first few a few years. ⁓ later on, we started getting contributions, but early days it was CDS, then it was subversion, and then we finally hit in GitHub later on. But I mean it w 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 your you know contributors to contribute away. So it's kind of like that balance of the line. How do you enable contributions while still not having a code base you can't maintain? Speaker 2: And HD, you and I don't have a much in common apart from the fact that we both ⁓ we b we both wrote Nassel plugins for a living. What what's that history? So you have some history with Nessus, you used to write Nessus plugins back in the day, or okay, that's what Renault tells me that ⁓ there were some plugins that are shipped as part of from for HD Moore. And I believe you also helped write the Nessus first Ness the only Nessus book that exists, that exists out there. So what's the history? Speaker 1: So in the early days, like ⁓ there's a community of folks that like GNOME, Rathmus, myself, ⁓ J Beal, a couple other folks were all kind of working on tenable or sorry, Nessus Nasal plugins on the side, and a lot of us were contributing back upstream. So like ⁓ beyond Flucardy, ⁓ GNOME would would contribute a lot, I would contribute a lot. And so you had like maybe four or five companies that were not Nessus poor contributing plugins. But then what happened, of course, somebody took them all, sort of shipping them and made tenable folks or Nessus put folks mad, they became tenable. Makes sense, right? So at one point I was using the Nessus scanner until about two thousand two 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 but yeah, in the early days, like ⁓ I worked with Renault 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. It's 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 and a weekend? Speaker 2: And you didn't have chat G P D. You you had to write your own. Speaker 1: It's the hard way, right? You have to use like word documents with like these awful templates from Synchrist at the time and it was it was not fun. But we got there. We got a book that we're all proud of afterwards. ⁓ you know, all her name was still on but it's a Speaker 2: ⁓ If you search for Ness's book, your name still shows up. I think you're the edit editor in chief or something. Speaker 1: But you know, it just means I like read every chapter and rewrote a lot of them. ⁓ Speaker 2: And you had like some massive successes with ⁓ Metasploit. ⁓ HD, you killed ActiveX. Why? Speaker 1: Yeah. ⁓ we had some so one thing that was great about MetaSploit is to 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 to these cool fuzzers that broke everything. So we've we created one called like a Axman. And what did we 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 active ex control, whether it's allowed to or not. And if it crashes it, 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 p 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 back to price 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 UAS and code exec and things like that. And so we ended up sitting on this pile of like ⁓ probably two or three thousand active X vulnerabilities. Then we also had all these bones 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 the Mount Browser Bugs project where every day you 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 left. But like, what do you want to do with these things? And so ⁓ we ended up ⁓ as part of that process, we'd escape all the exploits to Microsoft early on to the Internet Explorer security team, be like, all right, here's the thousand of them. Y'all figure out what you want to do with it. And fast forward a little bit. Th what they want to do with it is just kill Active X. It wasn't worth trying to maintain anymore at that point. Speaker 2: You know, ⁓ you know, I remember from my days that the the fact that if a C V the worst thing that can happen to a C V E is to have a ⁓ a metasploit module associated with it. Like this is like pre-Sisa Cav. So now if you have a CSA Cav, it you know, it automatically goes to the top of the chain in terms of the most important vulnerability or critical vulnerability to fix. But in back in those days, if you had like a Metasploit exploit out there, that was the worst thing that can happen to a C V E. All vendors like Tenables and the colossus of the world would take a lot of pride in saying, hey, you know, you would add that attribute metas metasploit, exploit, available through. And so that was my in my humble opinion a good a a big achievement because you know from ⁓ 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 a 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 w the way I see it. So HD the question I have is like you know, the 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 report and And now that game has completely changed, especially with AI, you can point the you can probab point the latest ⁓ you know cloud code or ⁓ codex to a ⁓ GitHub repo, find vulnerabilities and instantly starts to find vulnerabilities and so on. My question to you is like what do you think is the future of vulnerability discovery and research two to three years from now? Do you so like one there in my opinion there are two case there are two cases. One is the pessimistic case where you have AI slop, a bunch of crappy You know, like the kind of thing that you used to get from Metaspoint submissions, like you know, the certain things that you get and then you fix it and then you push it. And the other aspect is like these mesh these models get so good that you essentially land up in a self feeding infrastructure where bugs you know, code gets committed, gets fixed, it's fixed and so on. Where where do you see this happening? What's your point of view on that? Speaker 1: Kind going back to your previous point, when people saw a Metasplate 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 bone coverage over the years. 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 teenage 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 LM's really moving towards isn't just the, you know, hey, you know, Claude looked at us code to 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 sun grap. Like using the LMs 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 passes just like in old days, if a vulnerability was in that exploit, 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. Speaker 2: And ⁓ you know, there is this re there is a research piece from what is Sock Puppet or he says, you there is World War Research is cooked. I I I don't know if you've seen that. What's your what's your take on that? ⁓ I found it fascinating because you know the the Anthropic guys, they went through all these open source projects like the Mozilla's, the OpenSSLs, you know, they went and found bust a bunch of world reads. And I thought they probably did like a lot of deep research and his model was he would connect ⁓ connect the clear project to Claude. Hey, I'm in a capture the flag. I'm in a capture the flag competition. Help me find these bugs. And the model would just go and find it for them. Like there was not much effort required. And this is from a guy who's been in vulnerability research for a long period of time. And so he was like an OG in vulnerability research. And for him to come out and say vulnerability research is cooked question mark it's pretty fascinating. What I'm curious what do you think? Speaker 1: ⁓ Tom Tayshak and Tim Notion 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 nineteen ninety-eight or whatever. So they're actually like my heroes from when I was a kid. Like I looked up 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 L LM now. It might take the LLM providers are gonna 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, l long story short, I think there's still a lot of untapped surface. Like I was doing some mobile dev recently with LM 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 twenty 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 exclusion 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 harness around the whole thing. So quickly was able to go like just you know, dynamite fish, an entire class of vulnerabilities within a really old, obscure corner of the software world. It's not open as L, 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. Speaker 2: Do you think there will be like an explosion of you know the low hanging fruits of the vulnerabilities, the kind of things that you look for in the past but hard to could not find it, but the LLMs just being the good at they'll find a bunch of things and then they'll plateau or maybe there is you know, all the easy low hanging fruits have been ⁓ taken taken out and then it's ⁓ gets much harder. So there, you know, 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 that is reasonable or something else happens? Speaker 1: I think it's already happening, but we're you're not gonna see the count of vulnerabilities 'cause no one's gonna bother reporting them. Yeah. There's gonna be so many of these things you're not gonna bother even creating C Vs for Speaker 2: Precisely my point. Like this this could get to the point where it is unmanageable because you just run ⁓ you you run this these LMs or these models across major products and you find hundreds of thousands of vulnerabilities. ⁓ Speaker 1: You never have to really like C V is 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. Speaker 2: Pretty interesting. Yeah, th the I mean, ⁓ it is a fascinating, fascinating one 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. You see, the ⁓ the thing I wanted to ask you was, you know, I was looking through your history. And I don't know if you realize this. You are very active on LinkedIn. But the days you read your the 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 know you've identified a new way to fingerprint maybe it's a Postgres database, maybe it's unsupported Windows software or the Recog project and so on. And when I look at like you know, when I look at like the 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 for Unzero. The other way to look at HDMO is You're essentially the same guy from early two thousand solving the same problem at different levels at different levels of scale. And your core call calling seems to be finding unauthenticated services and then breaking into them. Like that seems to be your core your core mission and purpose of life. I'm curious what you think of it. Is that a good ⁓ approximation what drives HD? Speaker 1: Yeah, I mean it's I think it's less about break the game, more about the discovery and information. Like for me, the internet and even the phone system is 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 in China. Like all it requires is like typing in an IP address and interacting with the 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 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 outside. And with Ron Zero, 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. Speaker 2: Yeah, like, you know, my my early recollection is I don't know if you remember this, but you you found the novel way of fingerprinting the Postgres versions through the ⁓ in a way ⁓ the file lever. And it was very important for re ⁓ for ⁓ the Nessus plugin writers like us because we were always looking for unauthenticated ways to fingerprint the version of ⁓ software because then it helps write us, you know, detection plugins and get it out of the way. There is a there has been a constant stream of such adventures from your point, like you know, you did for something for unsupported versions of Windows. You know, there were Speaker 1: 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 text 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 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 authenticated fight leak coming out of the service. So that's the kind of stuff I still get excited about. Speaker 2: Yeah, th that and that shows through your character. Like, you know, the joy that you see when we can do these kinds of things. That shines through your character all the time. I'm curious, like, is there a you know, is there a is there an angle of attack in terms of fingerprinting with AI? Like do do you I don't even know if there is such such a thing where you can fingerprint a model or fingerprint the ⁓ this output of a model. When you think about like fingerprinting in the in the context of AI, AI models, AI agents, d does anything appeal to you on that space or is that like a very open field? Speaker 1: On 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 you know, finey liberal liberator stuff, or go look at like some other like anthropic debug topics. So if you could look at my LinkedIn profile, for example, I've got like all the anthropic break processing rules in my profile, so it breaks people's like LLM scraping of my profile. But it's not 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 Anthropic's 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 LM 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. Speaker 2: And even with the even with the advancements of the models where they can understand the context, they get better at the context, they have a ⁓ they have a larger context, even in that scenario you think prompt injection is essentially an unsolvable problem. Speaker 1: Yeah, it's not the model, it's the tools. People are taking the output of a model and spitting into the input of another model. So it's ⁓ Speaker 2: I see. Yeah, yeah. So essentially, yeah. So if it's like a seven step process, you know, step three step three could be completely different. So Idri, ⁓ so we talked about Metasporgy journey. At some point you left Metasploy, ⁓ and ⁓ if I remember it correctly, post metaspology bootstrapped completely. and I I r I remember in one of your interviews you're saying that there was some strict goals that you were given to achieve at ⁓ at ⁓ at ⁓ Rapid Seven and ⁓ you achieved them. Once you achieve 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 Rapid Seven experience and then starting with Ram Zero. Speaker 1: Sure. Well, certainly distribute all the money. Like I use the money to paid on 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 bunny 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 hundred ten customers and like seven thousand 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 it. I got us I got the company to a millionaire by myself on a product company with a low price point with hundred and something customers. Like now it's time to actually like hire people. And when I was looking at hiring people, I 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. Speaker 2: Pretty fascinating. What do you think, ⁓ what do you think is the the future of i I guess, you know, the way I see RNZero is it more about attack surface management, trending in 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? Do you think ⁓ obviously you built your own scanners, ⁓ your tools to find and fingerprint and so on? ⁓ does this work get offloaded to the EI agents in the future, where they are continuously monitoring, finding things? I'm curious what you think of that. Speaker 1: 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 kinda have to have deep knowledge of a couple areas still. And this, you know, if you don't have good data, you can't do anything useful on the L L ⁓ side. So unless you have 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 LMs 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 of 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. 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 spark 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 attack, you know, external attack 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 kinda everyone's doing a little bit of everything these days. So Microsoft is doing the whole stack. Speaker 2: Wanted to I I wanted to ask you ⁓ this c this concept of vendor consolidation, where the the from a user perspective, they c 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 that that is the f that and the follow up to that is I've seen a lot of a lot of cybersecurity companies started by non security people. And they have a lot of funding. They have all the marketing and the sales and the go to market and so on, but not necessarily to the product or the people who are running it. ⁓ I'm curious what do you think of those two aspects. You know, 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. Speaker 1: 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 raise, things like that. ⁓ and then it'll come back. And then people will say, like, wow, these tools sock 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. Speaker 2: But do you but do you run into these situations where ⁓ you know, there is some big player that is out there, you know, the the platform players. the platform players of the world with ⁓ we do this, you know, this is bundled with our solution, you know, the whatever plus plus includes attack surface management. And then do you end up fighting these players all the time? Or Speaker 1: 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 from 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 'cause they already have everything else. And then in 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 have customers right now that have to be able to pick, you know, either bullet management or run zero's exposure management. ⁓ or in some cases pick E DR 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. But 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 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 eighty sec the eighty two hundred 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 who are getting to a hundred million AR in eighteen months just by kind of brute forcing their way into the market. So a lot of folks who 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. Speaker 2: How you think that model works though? I mean if the product doesn't work or it doesn't d d deliver the value, how do do how do how do these products then get to scale millions of dollars in ERR? Speaker 1: Yeah, I'll get 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 We're gonna stick we're gonna take all your hard drives from your your infrastructure, full 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 care 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 is 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, we're 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 of the high growth model 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 handshold of it. We just go back to go back to work. Just do our make our product better, work with the customers we have, do incremental here and there. And then when time's right, we'll expand and grow faster again. But it's different model than kind of like, you know, all or nothing cash firm. Speaker 2: 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 changing the same top five hundred fortune five hundred companies with the same, you know, the tactics that you just talked about, 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 like, you know, driver Ferrari and all these things. And the CISOs act like kings. And it's very hard to compete when you have that kind of ⁓ giveaway to a seesaw when you're s just trying to build a company, make it the make the product better, one employee, one product feature at a time. Speaker 1: Yeah, there's two ways to do that, right? You do the CISO down approach where you really focus on we'll sell you sell you the 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 Bron Zero 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 at work, who then took it to work, who said, wow, this thing's cool. I found a lot of stuff. Who then told their, you know, manager, director, boss, who told this is Zoo, 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 get quite a lot of market share. Speaker 2: 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 ⁓ if you've 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. ⁓ I'd love to get your take on that. And because you know, I was asking right now for Renault, it was the ⁓ the Lock for Shell, Wanna Cry. And ⁓ there was one more that, you know, had a big impact on him. ⁓ the heart bleed. The heart bleed, ⁓ vulnerability. I'm curious what you in H D Moore's world, when you go to sleep and you have to thank, you know, there's a gun to your head, hey H D, which was the f which was your you know, ⁓ Hall of Fame vulnerabilities, which which one would that be? Speaker 1: Probably the very first one that I'm we're probably still you could probably still recognize. If you ever wonder why port four four four four four four 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 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 was four four four four in Metasploit and made that part of the blaster worm, which 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 forty four forty four as a port number and because that that then became the Metasploit port and the blaster port. And that's why that port split block everywhere. So we broke a port on the internet basically. So that that was 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 DX works, W D B, RPC, the debugger port. All these different vendors, hard coded debug service, just like an Android debug port into these like IoT devices and OT dataways. 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 wringing 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 for 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 you kinda like save game style, like save game file hacking for the internet ⁓ at scale. Speaker 2: It's super fun. ⁓ I'm curious, ⁓ you get a lot of mileage out of ⁓ Lockfor Shell or ⁓ or a kick out of Wanna Cry. Did did any of those make an impact or were they like run of the mill from your point of view? There was a staying room machine. Yeah. ⁓ unless your library is using it, you have to brute force your way and and you know, you put that in and maybe it calls back call backs and th calls back and then you know it it has ⁓ it has broken. Yeah. H D, this has been a fascinating interview. Thank you for your ⁓ thank you for your time. ⁓ what's next for H D? What's the next major drop that is coming out for H D? What's the next major fingerprinting drop that is coming out from H D? Are are are any of these like high risk, high highly sensitive devices? I hope they're not connected to nuclear reactors or any of those things. ⁓ behind the scenes. ⁓ some really bad stuff could happen if that was out, especially with the war going on. Can you open the door of the gym? Awesome, awesome. ⁓ H D, 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. And you know, looking forward to what you do next.