July 1, 2022

Keeping It Open Source with Metasploit’s HD Moore

by Hacker Valley Red

Show Notes

This season of Hacker Valley Red wraps up with another interview of an incredible offensive cybersecurity legend. Known first and foremost for his work founding Metasploit and his recent work co-founding Rumble, HD Moore joins the show this week to talk about his journey from spiteful hacker to successful founder. HD walks through the history of Metasploit, the motivation behind their coding decisions, his opinions on open source software, and the excitement of exploration and discovery.

Timecoded Guide:

[04:57] Catching up on HD’s career from his hacking exploits in the ‘90s through his founding of Metasploit to his recent activities with Rumble

[11:41] Getting personal with the feelings and takeaways from a project as successful and impactful on the cyber industry as Metasploit

[18:52] Explaining HD’s personal philosophies around accessible education and the risk of sharing vulnerable information publicly 

[25:39] Diving deep into the technical stories of HD’s path of discovery and exploration during his time at Metasploit

[31:14] Giving advice for future founders and hackers looking to make a legendary impact on the cybersecurity community

 

Sponsor Links:

Thank you to our sponsors Axonius and PlexTrac for bringing this season of HVR to life!

Life is complex. But it’s not about avoiding challenges or fearing failure. Just ask Simone Biles — the greatest gymnast of all time. Want to learn more about how Simone controls complexity? Watch her video at axonius.com/simone

PlexTrac, the Proactive Cybersecurity Management Platform, brings red and blue teams together for better collaboration and communication. Check them out at plextrac.com/hackervalley

 

What were some of the trials, tribulations, and successes of Metasploit? 

Although Metasploit has had a lasting impact on the cyber world, HD Moore is not afraid to admit that part of Metasploit existed out of spite for critics, employers, and gatekeepers in the cybersecurity industry. In terms of trials and tribulations, HD saw a great deal of criticism come from his peers and from professionals ahead of him in the industry, often displaying rudeness towards the quality of the exploits and Metasploit’s audience of young hackers. Later, HD says that a surprising and amusing side effect of his success with the project was watching employers and peers go from criticizing to lifting up his work with Metasploit and attributing success of many hacking professionals to its creation.

“When we started the Metasploit project, we really wanted to open up to everybody. We wanted to make sure that, even if you barely knew how to program, you can still contribute something to Metasploit. So, we did our best to make it really easy for folks to get in touch with us, to submit code.”

 

Where does your philosophy land today on giving information freely?

HD has heard the same opinions many professionals that teach and give information freely have heard: “You’re making it easier for people to use this information the wrong way.” Instead of considering the worst possible outcomes of making hacking accessible, HD chooses to acknowledge the importance of accessible education and publicly provided information. According to HD, if someone is creating and teaching content to the next generation of red teamers, that content is theirs to use. Whether they’re a physical pen tester teaching lock picking or a hacker disclosing a vulnerability, what they choose to share with others has to be based on personal moral code and what others do with that information is up to them. 

“It comes down to: You do the work, you own the result. If you're teaching people how to do stuff, great, they can do what they want. You can decide to do that, you can decide not to do that, but it's your decision to spend your time training people or not training them.”

 

Is it possible to be a CEO, or a co-founder, and stay technical?

The downside of success in the cybersecurity industry is often stereotyped as losing the opportunity to be a hands-on hacker. However, for HD, his success has allowed him to do the exact opposite and instead prioritize his time to be technical. HD believes strongly in the ability to make this happen through proper delegation of duties, incorporating new leaders and managers in your company or project, and acknowledging when you may need the help to bring what you’re working on to the next level. HD is proud of his success with Metasploit and Rumble, and is happy that he was able to hand off certain duties to other professionals that he knew would do better if they had a chance in the founder’s shoes. 

“Don't let the growth of your company change what you enjoy about your work. That's really the big thing there, and there's lots of ways you can get there. You can hire folks to help out, you can promote your co-founder to CEO. You can bring on program managers or project managers to help with all the day to day stuff.”

 

What advice do you have for people looking to follow a similar cyber career path?

Content is the name of the game, especially when you’re looking to get more eyes on what you do. HD is the first to admit that putting himself out there in a blog post, on a podcast, or at a stage show is not always a walk in the park, taking him out of his comfort zone and often away from the tech that he spends his time on. However, publicly displaying himself and his work has brought attention to Rumble and Metasploit, and HD knows he would not have achieved this level of success without putting his content out into the world, hearing feedback from his peers, and even receiving his fair share of criticism from industry professionals.

“Not all of it is the most fun thing to do all the time, but it is crucially important, not just for growing yourself and getting out there and getting feedback from your peers, but for learning because you learn so much from the feedback you get from that effort.” 

-----------

Stay in touch with HD Moore on LinkedIn, Twitter, and his website.

Learn more about Rumble, Inc on LinkedIn and the Rumble website.

Keep up with Hacker Valley on our website, LinkedIn, Instagram, and Twitter.

Follow Ron Eddings on Twitter and LinkedIn

Catch up with Chris Cochran on Twitter and LinkedIn

Continue the conversation by joining our Discord



Transcript

Axonius Ad 00:21
Hey, everyone. It's me, Simone Biles. You might be wondering why you're hearing my voice on a cybersecurity podcast ad. Well, it's because I'm partnering with Axonius. Whether you're a gymnast like me, or an IT, or a security pro, complexity is inevitable, and I've learned that the key to success is focusing on what you can control. Go check out my video at Axonius.com/Simone.
Chris 00:47
This is the grand finale of Hacker Valley Red, where we're exploring the nexus between offensive cybersecurity and humanity with a hacker’s mindset. Finally, I'm one of your hosts. I'm Chris Cochran.
Ron 01:08
And I'm Ron Eddings. In this season, we explored the cybersecurity legends. We explored the topics, the people, the ideas that really make up red teaming, offensive operations, and alike. This season was incredible for me because I'm a son of cybersecurity. I'm someone that would say, "Cybersecurity help raise me," because when I was a teen and a kid, I felt lonely a lot, but when I was online, on technology, learning about hacking and cybersecurity, I felt whole. Speaking to some of the people that I used to look up to so much when I was first breaking in, is a dream come true.
Chris 01:44
Yeah, it's incredible. And we have a very, very special guest, but before we reveal exactly who it is, we got to talk for a minute about this season. This is the last episode, I learned a whole lot about the red side of cybersecurity, even though I spent a lot of time doing some of this stuff, but really talking to the folks that are legends in the space. Really, the red side seems to be misunderstood. There are miscommunications, there's a lack of understanding, a lack of awareness and empathy that I think we all need to consider when we're talking about the red side, making sure that that information from the red side gets put to good use on the blue side. What was one of the big things that you learned in this
season, Ron?
Ron 02:24
One of the biggest things that I learned is engagement, outreach, support. There's so much that we could do from a technical perspective. We could build the best tools and the best hacks and maybe even build the best company, but what happens when you don't have people to support you or support your ideas? And also, what happens when you're not supporting others' ideas and supporting the community? All things are going to start to fall apart, you're gonna have a breakdown in communication, a breakdown in operations, but also a breakdown and people feeling good about what they're doing and who they're doing it with.
Chris 02:50
100%. When was the first time you touched Metasploit?
Ron 02:56
That is a good question. The first time that I touched Metasploit, it was actually the second tool that I ever used in cybersecurity. The first tool that I use, it was called ProRat, it wasn't open source. I didn't Keeping It Open Source with Metasploit’s HD Moore Hacker Valley Red with Chris and Ron know how it worked, but the first tool that I used where I really felt confident was Metasploit, and I would say that was in 2007.
Chris 03:19
Huh, that's a long time ago.
Ron 03:21
What about you?
Chris 03:22
Yeah, I would say probably 2008ish. I would say the first tool I ever used was NMAP. The second tool I ever used was Metasploit. And that's why we have a very special guest for everyone out there, everyone that has been in the community, whether you've been to an ethical hacking course, whether you've played around with things like Metasploit, we have HD Moore, the epitome of a legend on the offensive side of cybersecurity. Tell everyone a little bit about the background of HD Moore, Ron.
Ron 03:54
You're going to have to listen to the full episode, but I'll give you a little taste. HD Moore is the founder and creator of Metasploit. He built it to have a community of 300+ people contributing to this one project, but HD is also a founder. He founded and co-founded Rumble, which is a network discovery tool. So, without further ado, let's go ahead and jump right into the interview with HD.
Chris 04:20
What's going on everybody? You are in the Hacker Valley Studio, with your hosts are Ron and Chris.
Ron 04:24
Yes sir.
Chris 04:27
Welcome back to the show.
Ron 04:30
Glad to be back again. And usually, I'm not on my own podcast, being a fanboy. We run into a lot, but today, I'm a complete fanboy. We have a legend on the podcast, a legend that is known for founding Metasploit, a legend also known for co-founding Rumble. Today, our guest is HD Moore, the founder of Metasploit, also co-founder of Rumble. HD, it's an honor and pleasure to have you on the podcast.
HD Moore 04:56
Thanks, Ron. Thanks, Chris, for having me.
Chris 04:57
Absolutely. You can't really go through any ethical hacking course without touching something like Metasploit, without being touched by the community that you basically created from that brain of yours, but for the folks out there that don't know who you are just yet, we'd love to hear a little bit about you and your origin story.
HD Moore 05:14
Yeah, sure. I kind of grew up in the '90s of hacking things through telephone wires, as opposed to internet, moved on to IRC and all the TCIP fun stuff in the early days there, and just kind of spent the rest of my career bouncing between consulting work, red team work and actually breaking into stuff, or building tools to automate the process of finding vulnerabilities, or exploiting stuff. So, I've spent a lot of my time, either just neck-deep in random bank networks tearing things apart, finding ways to pop ecommerce systems and steal credit cards, or going and writing the tools to find ways to automate exploitations for that stuff. So, I really love doing the kind of back and forth model of, get out there, go in the field, see what kind of crazy stuff exists in the world, and then go heads down for a few years, building products to exploit the heck out of them, or otherwise provide great data about them.
Ron 05:55
So, take us back a bit. When I first got into hacking and exploitation, really cybersecurity as a whole, it was because I got hacked, someone hacked me on AOL Instant Messenger. It was devastating, but the reason why I wanted to learn about it and do it myself was because I wanted to do it to my friends. I wanted them to have that same reaction that I felt and be surprised and have their CD ROM drive open up and close and the computer restart, but what was it for you that made you go so deep down this rabbit hole of exploitation, networking, and all of the things?
HD Moore 06:27
For a lot of it, it was just the computing side of things. It's the combination of like, I can write some code that does something on my behalf and it just goes off and does things, usually the wrong thing, but it's great to know that these problems are my problems, like it was my mistake that caused that. So, it's nice having that level of control and concise output. The other side is the discovery and understanding. I'm just really curious about the world, I really want to know what's out there, and when you're 15 years old, in your bedroom with a modem and you're dialing random 10-digit numbers, trying to find out where they land, you find the weirdest stuff, like the HVAC controls for target, radio station transmitters, all kinds of fun voice IVR systems. You find is really cool stuff and that same mentality is kind of just been the background of my career, all the way through for the last 20 years now. I spent some time doing scanned internet projects in the late 90s, did a few more rounds of those in the 2000s, few more rounds
in the 2010s. Like, I just love going in and figuring out: How are things connected? What's out there? What type of devices are people using? What businesses actually rely on what stuff? So, there's a bunch of fun projects where we went and took like, one interesting data point about the world like, UPnP exposure, and just went super, super deep on that, as far as we could, to figure out where we'd end up. What's the worst-case scenario you can do now that we've categorized the entire world's UPnP exposure? So, I love that stuff, but on the flip side, that information is only as good as what you do with it. So, it's also good to go build tools and say, "Great, now I've got a way to turn your video camera on remotely and log into your house, or open your door, or things like that." So, I feel like it's a combination of both, doing the exploration and the research and then, being able to actually make that practical.
Chris 07:49
Absolutely, we got to touch on the Metasploit project, the why of the project. What were some of the trials and tribulations and successes? What about the community impact? Tell us that whole story of how you got started and what you ended up doing today.
HD Moore 08:02
Oh, sure. I mean, like any project by probably a young male who was not well off, it was mostly driven by anger and spite. That's a great way to get things off the ground because you kind of need a lot, you need that chip on your shoulder to really go through some of the pushback you get in the early days. So, with Metasploit, everyone hated it, right? Like, my employer hated it, our customers hated it, my friends in the security space thought it was terrible. It was one of those things where the early prototypes in 2002 were so terrible that people just laugh at me, whatever. By 2003, they were like, "Oh, man, you're gonna like arm the script kiddies, and this is no good at all. Also, your exploits suck." By the time we get to 2004, I convinced a couple of folks to join the team and help out, and we were building some pretty useful stuff. Like, it was actually some of the best exploits for all the stuff out there, that was coming from Metasploit then, because of the combined efforts of the deep shellcode research by scape, the really interesting shellcode permutation IDS evasion work by folks like Brian Caswell.
HD Moore 08:51
So, we had these just really awesome open source teaming put together, and we were really just fighting against everybody else. It was fighting against the software vendors, just hot patching Internet Explorer vulnerability after vulnerability, repeatedly. And we just took dynamite to that approach, we basically built tools to find every possible vulnerability in a given space, and just blow it up until it's gone. So, the month of browser bugs project, we dropped a new Internet Explorer every single day for a month straight, and we still had 300 or 400 just stacked and waiting to go. We had so many active X bugs, because we just basically brute forced the entire space. We took that approach to a bunch of other vulnerabilities as well, and it was great kind of going down those paths and then, finding all those kind of weird, obscure things like, the debugging protocols. We kind of helped shine the light on a bunch of different areas of software configuration weakness that I think would have been really difficult
to do, if it was part of a commercial project, or not done to the community the way it was. So, on one hand, we were able to do all these huge amounts of public facing work, but we got a ton of flack for it. We had folks trying to get me fired all the time, getting dragged in front of boards, negative press articles, all kinds of fun stuff. Like, my employers hated the fact that I was involved with it, until it got popular enough that it became a thing they say, "Oh, look, we've got the Metasploit guy working for us." So, it was fun when that flipped sometime around 2007, or something like that. That was really funny watching that flip from being a liability to being an asset for the company I was working for.
Ron 10:04
I would say that I never felt that way, from somebody working in cybersecurity that this tool was out of spite and those enabling script kiddies, but there was one beef I had with Metasploit, HD. That beef was, I thought I was so clever, I was learning Pearl and I was learning Python. I was like, "I got my bases covered for cybersecurity," and then, I see Metasploit and it's all in Ruby. So, what made you go down that path of selecting Ruby, even though there were other programming languages that other people in cybersecurity were so interested and excited about?
HD Moore 10:05
It was definitely spite. So, that was funny, because we had a company called St Corporation, which built a vulnerability scanner written in Pearl. And out of the blue, they announced a product called St Exploit. We're like, "Well, that's kind of strange at this company that hasn't done the exploit work before all sudden has a commercial pen test product." And of course, one of our friends finally got a copy of it, they looked at it like, "Oh, that's basically Metasploit 2." They just copied huge chunks of Metasploit from exploits, shellcode, encoders, just code-for-code all the way through. We're like, "That's cool. It's open source, but contribute back." Get in touch, be a sponsor. We had no commercial aspirations by the point, we're just doing training to make the bills, but it would have been awesome to work with someone like that, with a company who was actually commercializing it. But they were just such jerks about it and denying the fact that even used our code, even though we're looking at the code. I knew
my shellcode. It was so funny. So, we find said screw it, we just basically went back and rewrote the entire thing in a language that was incompatible with everything else in the world. We put it under a commercial license temporarily for about eight months, or a year, where there were no commercial derivatives allowed, things like that, just really locked it all down just to get our house back in order, to feel like we actually owned our own code base again. We basically scraped the barnacles off that way, all the folks who are commercializing the product, I was like, "Great, have fun. Now we got this."
Chris 11:41
That's crazy. I had no idea that you did that out of spite. That's an interesting tidbit for everyone out there, for sure. Now that you've gone through that experience of developing Metasploit, bring folks together, what was it like knowing that people were basically learning about cybersecurity, learning about exploitation, learning about this community that we hold near and dear to our hearts? A lot of times, the first time they really interact with it, sometimes was with Metasploit. What were some of the feelings and some of the experiences that you came away with from that project?
HD Moore 12:12
Sure. I mean, the one thing that I never really enjoyed about this community, or even the industry later on, is the elitism, right? Unless you're one of the cool kids, you don't get access to the cool tools, you don't hear about stuff until it's too late. There's just very much a strict level of inclusiveness depending on who you are and who you know, and things like that, and how old you are, in a lot of cases. So, I was always like, three or four years younger than most of the folks that I looked up to in the community and I was never really in the first line to get the cool exploits. or talk to the cool folks. People just kind of thought I was an annoying script kid for most of my career, and probably still do and that's fine, I don't care, but it was one of those things were, as a result, when we started the Metasploit project, we really wanted to open up to everybody. We wanted to make sure that, even if you barely knew how to
program, you can still contribute something to Metasploit.
HD Moore 12:49
So, we did our best to make it really easy for folks to get in touch with us, to submit code. Often the code that someone submitted would definitely not be the code that we ended up committing. We were gonna basically take a submission that was barely Ruby, or barely Pearl, and then we'd spend two days rewriting it from scratch until it was perfect. And we'd say, "Thank you for your contribution to push it." So, that happened a lot. We did a lot of rewrites and cleanups, and part of that was like telling them, "Here, here's why we're doing it. Here's the code changes we're making. Here's why it is easier to maintain over time. Yeah, this is awesome. This is your contribution to the open source framework, but we have to maintain this thing indefinitely going forward, so we want to make sure it's killed we like too." So, there was that kind of push and pull on the community side.
HD Moore 13:23
The amazing thing about us, even before rapid seven acquisition, I believe we had something like 300 outside contributors to the project. And these are folks that were putting it on the resume saying, "Hey, I contributed this module to Metasploit, I worked on this tool." It was really awesome that so many folks were able to get their start in the community, or get a job they wouldn't have got before because they could point to this open source thing they worked on, even if it was under a pseudonym. There was a part of my life where I had to contribute to Metasploit under a pseudonym for about six weeks. It was hilarious. I was right between jobs, I didn't want one employer to find out I was doing some moonlight work as I was about to shift jobs to a different company. So, all the exploits that arose during that period got assigned to like someone called Thor Doomen, which was an anagram of Not HD Moore. So, it took years for everyone to figure out that those were all my bugs at some point, but it was fun. It's kind of
neat, having a platform where you can contribute anonymously and contribute other people's careers and serve as kind of a mini-mentor for folks. A lot of times people would show up out of the blue, they would kind of flail around a little bit trying to get them to get the ropes for it. We'd help them out and get things up and running, and then, they would disappear into the sunset. Then three years later, we'd hear from them saying, "Hey, I'm now a security manager at this company, holler if you need anything." So, it's really cool kind of seeing where all those careers led.
Ron 14:25
So, looking back, looking at where you started and where you're at today, I'm sure just so much has changed, from access perspective and accessibility, experiences that you have. I love the fact that you mentioned mentoring people from afar, like you don't have to know everyone to mentor them, and that's exactly why me and Chris started the podcast. We wanted to talk to cool people like yourself, but we didn't want these conversations to just be in a vacuum and not have everyone have access to them. There's almost this ebb and flow of open source in cybersecurity and technology. There’re moments where it's very prominent and then, other moments where it's very vendor-driven and gated, and you have to almost exchange value to get access to it. Tell us a bit about your experience over the course of your career, feeling as though you have access, or feeling as though you didn't have access to the
tools and technologies that you wanted to learn about.
HD Moore 15:16
Open source has been amazing for that and you're definitely right, there's an ebb and flow to it based on a lot of things. If you look at where security tools were in the beginning of the 2000s, you would not trust a tool unless it's open source. So, if you're on a pen test team or a security team, you're not going to use some compiled binary from some exploitation team in Germany, or something like that, without doing a lot of research on it first. You have no idea what the shellcode does, you don't want to use them your banking clients. So, open source really was a requirement for a long time for folks who want to use these tools, but then, we had the commercialization of security tools. You had folks selling commercial products, you had core impact, community canvas, st exploit, things like that. As folks got uncomfortable with the fact that security tools could be commercialized, they stopped caring quite as
much about them being open source and we've kind of seen that trend expand in the last probably 10 years in particular, people just don't care as much anymore whether the tools they use are open source. They just care like: Does it work right? Do I trust the company behind it? But the fact that it's open source and they can look at a code is no longer like step one of the requirements.
HD Moore 16:09
So, it's good and bad. I think a lot of it's been driven by the kind of rampant commercialization of open source. Whenever folks publish something, immediately all their competitors and take that and run with it and then build something. Even on my current job, we hear through the back channel, like, "Hey, this company is taking the stuff you're working at Rumble, the open source parts of it, and then embedding it into their new discovery product." We're like, "That's great. Hope they get in touch and collaborate because one way is no fun." Like, let's make this thing fun for everybody. But there's definitely a lot of, not underhanded, it just kind of like one-way open source use out there in the commercial world and it's a shame that it happens, but that's one of the reasons why you're seeing these not open source licenses being applied to clouds and databases, things like that, where they call it community licenses, which are really just not open source and pseudo commercial at that point. So, that's a shame that's going away, but it'll go back and forth. My guess is, in five years, we'll get back to BSD and MIT for
everything. I love the go language ecosystem, it is amazing because everything's basically one of those very liberal licenses by default. You have to go out of your way to use a jerk license like a GPL, or GPL 2 or 3, which are horrible for everybody, including the author for so many reasons I won't get into right now, but I'll fight that debate any day.
Ron 17:11
I was gonna say, let's go a little further into that, right? You now have sold Metasploit, kudos to you. I love the fact that you did. And you built companies, you're actually building a company now with Rumble. So, tell us a bit about this ebb and flow today with where you're at. Like, what parts of a product do you think should be free or open source? And then, what parts of a product should be productized and maybe even monetized?
HD Moore 17:37
Yeah, definitely depends: Where do you want the contributions, right? So, for us, the thing is that we wouldn't have a huge use for community interaction around how our scan engine works directly. Like, it's something very specific to how we do work, it doesn't really make sense to open source that because this is exactly our weird, narrow point of view that we take when we're doing discovery and it's not really broadly applicable. If we put this out in the community, folks would say, "Well, I want to do this, I want to do that, I want it to work this different way." And we're like, "That's cool, but we're doing it this way." So, it's one of those things where, because we've made some strong opinions about how we go about collecting data, the scan engine doesn't make sense for open source.
HD Moore 18:08
The things that do make sense, though, are all the fingerprints. So, we want to take as much of our fingerprinting as we can within Rumble and make it open source, collaborate with other companies on that, and it's working out really well. We use a project called recon, which started off rap seven when I was there, that was then pumped full of data from the project sonar stuff, where we scan the whole internet and made banners and things like that. It drives Metasploit, it drives insight VM these days, and it's about half of the fingerprints of Rumble as well. So, I love that we've got this open source fingerprint library that multiple companies are all collaborating and using. Lots and lots of people are using it, only a few are really collaborating to it, but that's kind of normal for the open source world. So, that's kind of our take today is like, we're closed core, but we're going to open around the libraries and the
fingerprints and edges of things, which is a little different than older open core model, where you then sell the plugins to it instead. So, we feel like we're going the opposite direction in this case.
Chris 18:52
Being open, sharing framework, sharing exploits, sharing information, I think is a powerful thing for community. I believe that knowledge is power, but we spoke briefly about some of the backlash that we can get from giving information pretty freely, right? I got a little bit of backlash because I used to teach physical pen testing, right? Teaching people how to pick locks, how to bypass alarm systems, and things like that because much like you, I heard, "Oh, you're making it easy for criminals to do the crimes." I feel like, if I had to guess, the folks that I taught on the positive side, the folks that we're trying to protect from these attacks happening far outweigh the folks that probably went into the class with malicious intent. Now that you've been through that entire experience, and you're thinking about open source, you're thinking about knowledge and arming people with awareness: Where does your philosophy really land today?
HD Moore 19:44
It comes down to: You do the work, you own the result. So, if you're teaching people how to do stuff, great, they can do what they want. You can decide to do that, you can decide not to do that, but it's your decision to spend your time training people or not training them. I feel the same way about vulnerability disclosure. If you find a cool bug in something great, do whatever you want with it. Hopefully, you don't go to jail and do something illegal. Don't sell it to North Korea, don't put on the blockchain, but at the end of the day, I can't tell you what's responsible or not. It's your relationship with a vendor, your relationship with your employer, with your own set of code and ethics and morals. The term responsible disclosure has always been this made up thing used by the vendors to somehow shame vulnerability researchers into doing what they want. At the end of the day, it's your bug, you do what you want. It's great.
HD Moore 20:22
I can't tell someone else to do something with their bug. Like, if I tried to tell Tavis, "Hey, Tavis, you shouldn't disclose this vulnerability," hopefully he would laugh on my face. Because it's not my job. It's not my role. I don't own that bug, just like I wouldn't tell him how to tie his shoes. It's not my business. So, I think folks really need to butt out. You can't walk around and get on your moral high horse and tell people that they should or shouldn't do things with their time or their skills and their effort, unless you're doing something different yourself. If you don't like what someone else is doing, do the opposite yourself, right? Create a movement for it, do some other work around it, create a response for disclosure framework, if that's what you really care about, or maybe don't say anything at all.
Ron 20:59
It takes me back to this concept of discovery. We said we were going to talk about discovery on this podcast and, when you look at discovery, whether it be a bug or an asset on an environment, there's two pieces of discovery. There is this technical experience of knowing how to ask questions of technology, or maybe even people, and then there's this aspect of learning, knowing how to ask the right questions, or knowing how to learn how to ask the right questions. I would imagine, with all the types of devices out there on the internet, or even at your home, or even that are custom made, there's always a way to discover something. So, tell us a bit about all of the crazy things that you've discovered over time, any highlights there, but also: What is your learning process for finding ways to discover?
HD Moore 21:44
Yeah, sure, there's actually a lot of parallels between the exploit development work I used to do a lot of and discovery. What you're trying to do is find ways to as safely and as quickly as possible determine what something is, to get lots of information from a very little amount of input or ability. Where my head's gone over the years on this is that, early on it's like, okay, if I send this packet, I get this HB header back and from there, I can see a version, therefore it means this thing. With exploit development, you can often say, "Oh, I can leak this, they have three bytes of address space and I know maps to this base address, I can use them for the return address, and whatever needs are returned to Lipsey, or whatever it's called." So, there's lots of ways you can use the small information links to get there, but over the years, what I've realized is like, all that's an API. End of the day, everything's an API feature to like one. So, you can use like, an ICMP packet and target like an AVI like, great I send that I make this request, I get a response back, I run through some rule sets, I know it's a Linux machine, three hops away with this TTL, this type of service, with these attributes, or I know it's not there, and the router upstream is this. You get so much information, just spend a little more time looking at the data coming back.
HD Moore 22:43
When you look at the traditional approach to vulnerability scanning on networks, you're really just looking for vulnerabilities. You're saying like, "Can I prove this thing is exploitable or not?" But you're really throwing away all the extra data you're getting back, you're throwing away all of the TTLs and the responses, all the closed port responses are actually really valuable, too. They tell you, hey, that ports not unused or the firewall is not in place. They also tell you things about the IP layer and about the routing path and window sizes and things like that. So, I think for me, discovery is a combination of trying to figure out how to enumerate an address space or a target space. How do you brute force addresses in the smartest possible way? How do you brute force session IDs the same way? It's no different than brute forcing ipv6 addresses in a giant slash 64, or brute forcing the most common open ports in a given network segment. So, it really comes down to, you've got your discovery aspect of determining what you need to go probe in the first place.
HD Moore 23:28
The second piece of that is, for every single bit that I get back, including the bits that are invisible, the timing bits: How long did it take to get a reply back from A versus B, or from B versus C? That's all just a ton of information you can then extract and work from and build rules around and do cool things with. So, there is this big push to use machine learning for everything in technology, including security. What I don't like about that is it really takes the focus away from building expert rule systems, which are really just kind of codifying your own knowledge about how something reacts and then using that to turn them to assertions and things like that. So, I've always been a huge proponent of building out expert rules, because you know better. The thing that machine learning is really good at is telling you something you
already know. We have machine learning classify an email as spam like, great I already know that spam, but if you can build a set of rules out that say this is a spam for these particular reasons. It's pretty reliable, at least I mean, you have to keep it up to date and as maintenance evolve, but it's not this magic wand, you just have to trust which results.
HD Moore 24:19
So, that was a bit of a rant there, but I love treating everything like an API, including the data you don't get. So, one of my favorite fingerprints is when you're trying to fingerprint a red hat enterprise Linux system, or Fedora, or CentOS, or any of the new derivatives of those these days, now that those are kind of ramped down, is that they tell you almost nothing. The generic, typical service footprint for those devices are ICMP responsive, and you get open a sage, open by default, and that's literally it. And with open a sage, the banner you get back for Ubuntu or the Debian based distros out there, tends to give you the package name as well. So, you can say, "Okay, no, it's version this, or I know it's a version of that," but with the REL line, you don't get any of it. You literally get nothing useful besides just a generic open to sage version, which could be anywhere, but the funny thing about that fingerprint is if you look at the entire world of sh fingerprints for that exact version, the only ones that do that are RHEL, and CentOS, and fedora. So you the lack of any other matched indicate that these things must be this particular type distribution. And then, you take a little bit further and say, "Great, now what kernels aren't using these platforms and what are the default of TCP window sizes?" Now you look at the TCP window size compared with the SH banner, you can now say, "I know this exactly Red Hat 8.5." And you do that without there really being any other information to pull from. So, we're able to pull some just crazy magic fingerprinting out of the box just by looking at the entire ocean of possible responses, figuring out where the gaps are in those, and using that to build out an expert rules system around it, and that's just one example.
Chris 25:39
Now, that's super cool. What's coming up from that little story that you just told is that you're really an explorer. You're using the pings, the packets, the ports, all of these things to your advantage, to discover, to learn, to realize these relationships between devices and technologies. Is there a story that, to this day, gets you jazzed up about you being on this path of discovery, this path of exploration? Where you're like, "Wow, that was the epitome of my exploration time."
HD Moore 26:08
Well, most of the research results in failure and sadness, but some of those are really fun, too. One that was sort of recent is, I was playing around with the SMTP protocol, I was trying to out do some enumeration and things like that. And so, it was a little different from SB one and it's got a bunch of fun tricks to it. Plus, SB three is kind of built on to so as you dig into it as the one of the neat things about SB two is it has a session ID. So just like a cookie, when you go to a website, it gives you like a big random number and says, “Here's a random number, you need to reconnect and come back and connect in this number.” And you know, session IDs are generally not supposed to be like sequential, they're supposed to be like random and people can't predict them. That's a kind of a standard security thing. But for some reason, all session IDs on Linux, and Mac OS, Linux with samba, as well as BSD is Darwin's SMB dx. And on Windows, they all had somewhat predictable session IDs for SMB two, and it just like stuck in my brain like, Okay, if session IDs we use for dedication, and they're predictable, what can we do with this, right, there's got to be some cool thing we can do with this.
HD Moore 27:00
So, I spent probably 2 weeks straight going through every possible packet exchange, looking at the authentication, looking at encryption, looking at keys. And they're actually ended up being two really cool things you can do, you can leak back a cryptographic primitive that is totally useless, but it probably somehow saw your password once before it got turned into a truncated hash of a hash of a hash, from someone else's session remotely by brute force, another session ID. Another thing you can do with that is because it's predictable, you can then use that to track the activity on a machine. So, over time, you can tell how many connections that happened to the server since I saw that last time, just by tracking, predicting the flow of IDs, and then falling into the form. So, that turned into a couple of really fun tools. So, one of the tools will basically tell you whether someone else already had an active
session on the machine, and it would actually kind of kill it too. So, if you have to brute force someone's SMB to save you dot c, terminate their SMB connection to from a different IP address totally unrelated to them with no knowledge of their session, just by brute force in this space, you found the SMB two session ID and trigger an error in the session, which is really fun. And that has a weird cryptographically been to where that was coming in.
HD Moore 27:54
The second part of that was you can tell how busy a server is. So, if you're doing a pen test, and you're scanning the network once a day during your two-week engagement, you can say, "Has anyone been logged into the server in those two weeks?" And you can easily tell by what SME said, what the answer to that question is. And the funniest part about all this is like, I was mostly focused on windows in this weird cryptographic primitive, because I thought it'd be some way to brute force the user's original password hash through it. And yes, kind of, but you have to know a whole bunch of other randomly generated key material, so it's difficult to do anything with it, but the funny thing about this is, when you look at the Linux and Mac OS version of this, they're leaking the kernel the application base address. So, in Mac OS, it actually leaks back 32-bit base address in the kernel. And on Linux, it leaks back the base of the session tables' pointer address. So, now just accidentally, we now have this memory leak
that tells us how we could probably exploit it, if we find another Samba bug or SMDX bug. So, just one little chain of research led into so many weird corner cases and potential vulnerabilities. None of these were CVSS10, they're not super exploitable, or a big deal, or anything like that, but it was just really fun to go dig into all the possible ways these bytes get turned into other bytes and get turned into a password they can verify and all kinds of fun side effects of remote monitoring the utilization of a server.
Ron 29:01
Going deep. That is definitely discovery and exploration, and that's one of the things that I've always admired about practitioners in cybersecurity is that they have to explore, they have to learn. You can't be in this industry without learning, at least somewhat regularly, if not every day, but what I would imagine other people I admire about you— This is one thing I admire about you is that you're also a businessman. You are a founder, you founded a tool, but you also founded a company, then you sold it, and you founded another company, but you still have your hands in this technical pot. So, tell us a bit about that. How does that work? Is it feasible to be a CEO, or a co-founder, and stay technical? Or, is this something that you just really love and are obsessed with?
HD Moore 29:44
I think you can definitely do both. I mean, it comes down to what you enjoy doing. Don't let the growth of your company change what you enjoy about your work. That's really the big thing there, and there's lots of ways you can get there. You can hire folks to help out, you can promote your co-founder to CEO, like I did in my case, which is awesome and I get to go spend more time in the tech weeds again. You can bring on program managers or project managers to help with all the day to day stuff, while you're still able to carve out some portion of your week to get deep and hands-on. So, there's ways to make it work. I mean, early on, I think the first almost two years Rumble was s me solo. So, juggling 150 customers and 12,000 users by myself was not a lot of fun, but I learned a lot of stuff like, all the state registrations and tax and things like that. I knew almost none of that walking into it on the sales and finance and tax side.
HD Moore 30:23
I didn't do an awesome job with it, but we got up and running at least. So, it was nice to be able to hand that off to folks who know better than me once I kind of got the wheels under. And now, it's working much better, of course, because it's not me running our taxes as much, but at the same time, it's great to know that I know how what I do on the tech side applies to how we do our sales tax tracking, or how we do our Nexus tracking, or how it impacts a given customers billing cycles or revenue recognition, and things like that. So, it was really useful for me to go do a little bit of all that stuff. One, even though we tend to hire people that are a little bit less senior than who other startups may drop in, and just have them basically hit the ground running, just eat and breathe the problems with that role for a few months before they bring people on below them, or promote them up to something else. So, we've done an
awesome job of finding more junior folks who could step up and really learn on the fly here and I love doing that because it's good for their careers and you also end up with team members who really know the space and know your problem set and your customers by the time they get there.
Chris 31:14
Outstanding, HD. This entire season was all about the legends of the offensive side of cybersecurity and we definitely think that you are one of those legends, but there are people out there that are just getting started. They're listening to this show. They're just getting deep into the weeds, whether they're developing exploits, or they're looking at IR programs and processes, whatever it is. They want to make that impact like you made on the community. What is that one piece of advice you'd have for that individual today?
HD Moore 31:44
Honestly, the thing that's hardest, even for me these days, just getting something out there. Like, get your blog posts out, publish your blog posts, push your tool, do your talk, do your presentation, get something on the internet, share what's on your head, put it on paper, put on a slide deck, put a video, and get it out there. Just get as much of your brain out in the world as you possibly can as quickly as you can, repeatedly, because even these days, I still have the stage fright of publishing a blog post. I still feel like, "Oh, this is stupid, no one is going to care about this, this makes me look like an idiot, I don't want to put this thing out there." I still hate giving talks, I still find them really, really stressful. I find podcasts really stressful. I don't like talking about myself. Even with 100+ security talks behind my belt now, I don't like it. I'm not good at it, but it's the only way to really get out there and tell people what you're working on and share where you're doing. I wouldn't have had a career if I didn't do all that stuff. So, even though the writing, the publishing, the speaking, the open source work, not all of it is the most fun thing to do all the time. It is crucially important, not just for growing yourself and getting out there and getting feedback from your peers, but for learning because you learn so much from the feedback you get from that effort. You learn like, "Okay, I got this thing wrong, or I got this thing right," or someone comes back says, "Oh, you really should go look at this other protocol instead." Like, so much of my career successes have been from publishing something that was crappy, someone telling me I could do it better by doing this thing instead, and saying, "Oh, you're right. I'm gonna go do that now. Thank you."
Chris 32:59
Outstanding, perfect advice for anyone out there trying to become that legend and make an impact on our community. HD, thank you so much for hopping on with us. For the folks out there that want to keep up to date with you, all the great things that you're doing with Rumble, keep up with all the contributions, or even in your past contributions with Metasploit, what are some of the best ways for people to stay up to date with you?
HD Moore 33:20
I'm on Twitter, just HD Moore. Rumble.run for work. We've got a blog where we post hacky stuff, like attack protocols, inquiries, things like that. I'm on GitHub, username is @hdm there. And of course, you can all email me at x@hdm.io, and I'm pretty responsive. I get busy every now and then, but I definitely try to get back people pretty quick.
Ron 33:36
Excellent. Well, everybody has your information now. Definitely reach out to HD, follow his great work. HD, thanks again and with that, we'll see everyone next time.
Chris 33:47
And with that, that is it. That is the end of Hacker Valley Red for this season. We ended it with a true legend in the space, but we have to talk about one of the reasons why we were even able to do this at all and that is our sponsors. One of our sponsors is PlexTrac. We talk about this communication of the red and the blue side to create something purple, where we are going to move that needle for our security posture. Ron, having something like PlexTrac, a place where people can have conversations about findings, about remediation, about pulling all that together. How important is that for someone that utilizes red information?
Ron 34:26
It's the most important element, whether you're a red teamer or a blue teamer, there's always threat intelligence, that's your background, information about the threats, about what damage can be done to your team, your organization. Typically, this is done with so many tools, but with a tool like PlexTrac, it's all in one place. There's a reporting aspect, there's a communication aspect, and there's also this remediation aspect, and I think that is one of the most valuable pieces of a tool like PlexTrac.
Chris 34:54
Definitely check out PlexTrac and what they got going on, even if it's just to see how those
communication pathways can occur. Be sure to check out PlexTrac.com/HackerValley, and tell them we sent you.
Ron 35:12
Yes, tell them we sent you and also, tell everybody about this episode and season that you can. We would love if you shared this content on social media, or on your favorite social platform, it would mean the world to us. We also have a community. We've been speaking a bit about community this entire season. So, Chris, before we wrap up, how important is community for you? How important is community for even offensive operations, red teaming, and cybersecurity?
Chris 35:42
When you talk about anything where you want to improve as a community, you're talking about the red side, the blue side, talking about sports. High tide raises all boats. The more knowledge you attain, the more innovations you create, the inventions, the ways of doing things, the more that you can contribute to the community, the better and it raises us all up together. So, I think community, communication, bringing folks together is the most important thing we can do as a community because if we keep everything to ourselves, we're gonna have to go through all the same trials and challenges, we'd have to go through all the hardship on our own. If we can learn from one another, that's how we can get better together faster and get ahead of the game.
Ron 36:24
We're doing it every day. Join our community, you can find it at HackerValley.com/Discord. We've built quite a big community in there. There's so much conversation and discussion, and we would love to have you, we would love to continue to build amazing content. We'll let you get back to the replay because it was such a great season. So, with that, we'll see everyone next time

Keeping It Open Source with Metasploit’s HD Moore

July 1, 2022 Hacker Valley Red

00:00:00