The BlueHat Podcast 1.8.25
Ep 44 | 1.8.25

Defending Against NTLM Relay Attacks with Rohit Mothe and George Hughey

Transcript

Nic Fillingham: Since 2005, BlueHat has been where the security research community and Microsoft come together as peers.

Wendy Zenone: To debate and discuss, share and challenge, celebrate and learn.

Nic Fillingham: On the BlueHat podcast, join me, Nick Fillingham.

Wendy Zenone: And me, Wendy Zenone, for conversations with researchers, responders, and industry leaders, both inside and outside of Microsoft.

Nic Fillingham: Working to secure the planet's technology and create a safer world for all.

Wendy Zenone: And now, on with the BlueHat podcast. [ Music ]

Nic Fillingham: Welcome to the BlueHat Podcast to George and Rohit. Gentlemen, welcome back to the podcast. We last spoke to you about, hey, you overflowed my integer. I think I got that right. But for folks that maybe haven't listened to that episode, could you reintroduce yourself to our audience? George, I'll start with you, please. Who are you and what do you do here?

George Hughey: Yeah, Nic, super happy to be here. Happy to be back on the podcast. My name is George Hughey. I've been in MSRC Vulnerabilities and Mitigations for just over five years now, which is pretty crazy to think about. So most of what I'm doing now is like vulnerability hunting, looking at some of the really great research we get from our external researchers and finders. And, yeah, just taking a look mostly at the Windows ecosystem and what's going on there.

Nic Fillingham: Awesome, and Rohit?

Rohit Mothe: Hey, yeah, great to be back on the podcast. Thank you for having me. I am a colleague of George, so I'm also in the Microsoft Security Response Center working in the same team as George. Basically, everything that George said I do, I just do it way better than him.

Nic Fillingham: I love it. And today we're here to talk about mitigating NTLM relay attacks by default. You two are co-authors of a blog that's just gone live on the MSRC blog talking about this topic. And we thought we'd take an opportunity to bring you back on the podcast, learn a bit more about NTLM relay attacks and channel binding and some fun stuff. But first, I think, George, if I could start with you. So the reason why this blog post is on the MSRC blog is sort of tied directly to the fact that MSRC sort of gets to see vulnerabilities and bugs that come in from the security community and gets this sort of really interesting sort of perspective that's maybe a little bit broader than an individual engineering org that might be building some of these products. Can you just sort of set the stage for us about why we're talking about this today and why this blog came out?

George Hughey: Yeah, that's right. So MSRC is essentially product agnostic because we get reports in every single product that Microsoft owns. And what that means for us as a team looking at the overall landscape is that we can end up having a really good idea of where trends are going, where researchers are going, and if one individual component has a problem, that problem might be reflected in another component as well. So with MSRC, what we're trying to do is apply some of the learnings that we get from going really deep into one component across the broader ecosystem at Microsoft, and that's exactly what we saw with NTLM because NTLM has been something recently and historically that has been exploited by attackers and that attackers are really interested in, and we've noticed them going after a few services, and we've really wanted to take a strong secure-by-default stance for NTLM, and that's what we're trying to do across the board for pretty much every Microsoft service.

Wendy Zenone: Could we give a brief overview for those that don't know what NTLM is? I mean, I'm a little bit of an expert on it, but I mean, for those that aren't, could you tell us what even is NTLM? And I know we had an episode about the desire to deprecate it and maybe where we potentially are with that. But then obviously we have not deprecated it because we are doing work to mitigate against risk. So can you give us a little overview on that?

George Hughey: I'm glad to hear you're an expert, Wendy, because the more I dig into it, the more confused I get. It's a complicated protocol, and that's part of what the issues are and where the issues stem from. This is a protocol that was designed in the 1980s to do authentication. And it's something that's essentially default for any Windows domains. When you're standing up a new Windows domain, this is the authentication protocol that you're going to use. So if you're trying to authenticate onto a workstation that's part of a domain, like if you go to a library or a school and you're part of that organization, you'll try and log in on your local machine, and those credentials will often get used in a challenge response protocol so that you can authenticate against the domain. And that challenge response protocol is NTLM in many cases. So there are different authentication protocols that can be used, but NTLM is essentially the de facto standard, and this is what's used in many domains today. And yeah, like we said, it's 40 years old at this point, and so it is something that we are trying to move away from. But there are challenges with that, and so part of what we're trying to do is move away from NTLM. And while we're doing that, also focus on what we can do to improve NTLM in the places where it's necessary right now.

Wendy Zenone: Thank you.

Nic Fillingham: And this blog is specifically talking about NTM relay attacks. So maybe Rohit, if I could ask you, we've reset the stage for what NTLM is. What is an NTLM relay attack?

Rohit Mothe: Yeah, great question. So as George mentioned, NTLM is a legacy protocol that we're trying to get users to not have dependencies on and move away to more modern protocols. The blog post specifically is about mitigations for a class of attacks that's pretty lucrative, and you've seen exploits in the wild before, which is NTLM relay. The fundamental way to think about that is when, back to the example that George just gave, right? When a client is trying to speak to a server machine and saying, hey, I need access to some resources and services that you can provide. And the server is trying to authenticate. The client can send some authentication data that the server can then use to prove that the client indeed is, you know, George or Rohit or whoever they claim to be. What ends up happening is there are scenarios where this authentication package, this bunch of data, can be stolen by an attacker if they cause the client to connect to them versus that server. This is one of the key limitations of NTLM. There's no mutual authentication. The client does not have a very good way of knowing who they're talking to is exactly who they intended to talk to, right? So if the attacker can get hold of this bundle of authentication data, they can then use that to, quote/unquote, "relay against the actual service," like Exchange Server, for instance, that the user was originally trying to talk to and say, hey, I'm George or hey, I'm Rohit, right? And the service can look at it and look at the data and decode it and say, yeah, this looks legitimate. That's essentially a problem with NTLM Relay and the mitigation that the block focuses on, which is defense against specific services like Exchange, Active Directory CS, and LDAP, which aim to prevent this kind of attack.

Nic Fillingham: So is this in some ways like a man in the middle attack?

George Hughey: Yeah, you can sort of think of it like that. There's a little bit of complexity to it. But yeah, you should think of it like a man-in-the-middle attack where somehow an attacker can convince a victim to authenticate to them rather than authenticating to the server that they were intending, and then that attacker forwards that authentication to a service. So essentially, they're in the middle of the authentication that's happening, and then they're able to impersonate the victim in that case.

Nic Fillingham: Got it. Okay, and so the blog post is talking about how this type of attack, this NTLM relay attack, is now going to be mitigated by default. So the mitigation already existed, but the thing that's changed here is that mitigation feature, or set of features, are now on by default. Is that correct?

Rohit Mothe: Right. We already have publicized some options that IT admins can use to configure these mitigations, and they've been on for over two years, if I remember correctly, for different services like Exchange and ADCS and LDAP, but those are all opt-in and require user configuration, right? The whole secure future initiative that Microsoft's executive leadership is driving, and basically all parts of the company are driving, is towards a secure-by-default nature. So the blog post talks about how we worked with various teams within Exchange, ADCS, and LDAP to make this opt-in basically enabled by default out of the box. So the majority of the users are protected, and if there are exceptional cases and circumstances where an IT admin wants to toggle them, they can, but by making them secure by default, it enforces a much stronger security posture.

Wendy Zenone: You've said a few acronyms. Could you explain what some of those are? I mean, we know NTLM as what it is that stands for something and same with LDAP and some of the other acronyms you were mentioning that are listed in this blog. What are some of those? What do they stand for?

Rohit Mothe: Yeah. NTLM is NT Lan Manager, and as George said, this is, what was it, 1980s when this came out?

Nic Fillingham: I don't think any of you were born, were you?

Wendy Zenone: Right.

Rohit Mothe: I certainly wasn't.

Nic Fillingham: And then with LDAP, what's LDAP stand for?

George Hughey: LDAP is the Lightweight Directory Access Protocol.

Wendy Zenone: Nice. This is a test, and you're passing.

Rohit Mothe: Yeah, and Exchange stands for Exchange. There's no acronym.

Nic Fillingham: All right. So then, great. We've covered the acronyms. There was a new sort of concept that I read in this blog post, which I'd never heard of before, but that's not really a sign of anything because I live under a rock. But what is channel binding, and how does that relate to today's blog? Sorry, the blog that's just come out.

Rohit Mothe: Yeah. So channel binding is something that's not new. This has also been around for quite a few years at this point. Essentially, what channel binding does is it staples the authentication that happens to the TLS layer in the authentication itself. And what this means is you can't do that man-in-the-middle attack like we were talking about before because in order to find the data that's part of the authentication, you would have to tear down the TLS connection and make a new one to forward that to the server. So as a result, it's impossible to now forward authentication because it has to be part of the initial connection that was made. So we'll talk about a few concepts today. Channel binding is the overall umbrella term for this mechanism. One of the things we'll be talking about is EPA, which stands for Extended Protection for Authentication, and you should think of EPA as one type of channel binding.

Nic Fillingham: All right. So where do we go next? We've covered our acronyms, sort of high-level overview of what happened in this blog. What do we need to explain to listeners? George, Rohit, up for grabs. Who wants to go next? No one. All right, Wendy, it's all you.

Wendy Zenone: Well, let me get started, but actually, I think Rohit's better at this, please.

Nic Fillingham: Oh, yeah.

Rohit Mothe: I think the highlight that we want listeners to focus on, which is part of the blog that just got released, is really the secure-by-default changes we've made in these services, and the blog goes into the current state of the mitigations and what the users can do specific to each of those three services, right? Exchange, Active Directory, CS, and LDAP. And also, while we talk about what we have done, it's not the end of the journey, obviously, right? We also, at the end of the blog post, as it mentions, what is the future of NTLM, right? And really, one of the key points that we want to highlight in our blog is NTLM is a legacy protocol, and there are various work streams within the company where we're trying to build secure-by-default mitigations like this and to really move the needle in NTLM security. And also, there are specific actions that users can take today to move away from the dependencies that they have built on NTLM and move over to more modern protocols like Kerberos, right? And the blog mentions one good win on the recent Windows Server 2025 where admins can actually enable an option to block NTLM over a specific service like SMB, which we've seen in many attacks before, and we know that this is lucrative. So there's all sorts of other work streams that are being worked in Microsoft, and I think the key kind of TLDR is we are really putting our muscle behind moving away from NTLM, right, and going towards a path of deprecation because I don't think it's just tenable at this point to continue using NTLM across future versions of Windows.

Nic Fillingham: But as I think maybe George said it, in parallel in working to fully deprecate NTLM and move to sort of more modern replacements, this work is being done now to not just mitigate attacks, but make sure those mitigations are turned on by default. I want to ask sort of more about the work that the two of you did. So maybe I'll start with you, George. So sort of what was your -- you talked about how MSRC has this sort of unique, broader view across products and multiple platforms. How do you fit into this picture and maybe some of the work that you've been doing, whether it's cases that you've been involved in or sort of reviews that you've done and looking for trends? Can you speak about your involvement?

George Hughey: Yeah, so like I said earlier, I've been here just about five and a half years. And it felt like every year or so we would get one of these NTLM-style attacks. So generally it's some sort of incident that happens, and these are all things that have been blogged about before and we've talked about externally and published guidance for, as well, on what to do in these cases. But every single one of these services that we're talking about today, which is Active Directory Certificate Services, ADCS, LDAP, the Lightweight Directory Protocol, and Exchange have all had pretty major incidents in each of them, specifically related to NTLM relaying attacks. And so we in MSRC can see these larger trends happening, right? We see attackers going after NTLM relaying in each of these individual services. And so we can help by trying to drive adoption of mitigations across the larger ecosystem. So these three are good examples of what we've done, but we're also trying to do this for other services, as well, and make improvements in the NTLM story beyond just these three services, too.

Wendy Zenone: So I have a question about the origin story of the blog. You two came on to speak about integer overflows, and then now we're talking about this. So are these researcher submissions? You know, you said you're seeing certain things, but do you work in tandem with researchers? And then you and Rohit are like, hey, let's get together and write a blog? How does that process work? What inspires the work? And then what is the impetus behind, I mean, obviously getting the word out and advising on next steps, but what does that process look like? And then how do you two come together and decide it's time for a blog?

Rohit Mothe: Well, the motivation for the research, as George said, is cases and exploits and incidents that we keep track of in MSRC, right? We have a pretty holistic view. We are the front door to all issues that come to Microsoft, and then George and I and the rest of the team, we look pretty keenly for patterns and trends to figure out where to solidify our defenses further. That was really the motivation of research, both for the integer overflow work that we did. That was more directly coming from just like the volume of cases, and integer overflow is a pretty systemic bug class that we decided to go after. This one's not so obvious, but it certainly has been used in the wild, and it's a serious security issue. The work that we did initially was with the Exchange server on-prem team because, as I mentioned earlier, there was a mitigation, but it was opt-in only, and this was not an oversight I just want to highlight, right? It's insanely difficult to turn something on by default, which has a wide impact across all the enterprises and customers that use Microsoft services. And as George said, this protocol has been out there, what, 40 years now, more than that? But George and I really wanted to move the needle, especially against Exchange. So this was work we did starting sometime in 2023, mid-2023 or early 2023, I can't quite remember. There was a specific incident that had happened where we saw some customers, Exchange servers, being exploited. And then we realized, oh, they did not turn on the mitigation that we recommended them to. And at that point, we got to think, well, if you always rely on user configuration, people are not going to be protected. So let's face that hurdle and cross that mountain with the Exchange team and get them to build this by default and then give away to opt-out for our customers. So really, the whole, as you said, motivation for this work was the trend analysis that we did, and this whole project started with Exchange, which we worked closely with the engineering team. And ultimately, I think Feb of this year was when with Exchange Server Cumulative Update 14, I want to say, is when we built this by default and Exchange team released an advisory notifying all the customers. And then ADCS and LDAP, we weren't directly involved with working with the engineering team, but these were really tremendous improvements coming from other teams across Microsoft that MSRC wanted to highlight because it fits into the story, our narrative on how to mitigate the end-to-end relay attack.

Nic Fillingham: Are you able to talk a little bit about how you go about identifying trends? Is it purely just data? You have a massive sort of tranche of data, and you're able to sort of run reports against it and look for blips and peaks and troughs or is it more sort of nuanced than that? So how do each of you sort of -- or how does your team or your org go about identifying some of these trends?

Rohit Mothe: The really short answer is that we work on the cases that come in. So like George and I and the rest of the team, we are the ones who triage and analyze all the vulnerabilities and exploits that come. So we have internal data that shows us trends where we can go and see, okay, what was the root cause of vulnerabilities in the last three months or six months that dominated more than others? So that's kind of the short answer, because we are working in the trenches. So we get to see the data, but yeah.

George Hughey: I think you nailed it. I mean, I think the really unique thing about MSRC, we are trying to fix individual issues, and we want to see the individual issues that are coming in and try to fix as fast as we can for that, but at the same time, we're also seeing the larger landscape, and we want to drive stuff across all Microsoft products. And that's where we can really provide the value, right? Fixing an individual bug is great and has a lot of value, but when we can do that across all services, that really amplifies that value.

Wendy Zenone: What is the threshold of a trend? Like at what point is it a trend? At what point is it like, okay, that was like four, but when you hit five, it's a trend. Does it really depend on the severity or is it like there's a couple and then there's a few, and once you get to three, it's a few. Is there any definition or is it just as they come in, then you kind of see things and define it as they go?

George Hughey: I think some are really obvious, right? Like sometimes we'll see something that's really clear. Integer overflow is a great example. We saw a couple hundred integer overflow bugs, and it's like, well, that's very clearly a trend that we're seeing, and that was increasing. But with something like authentication, it can be a little bit harder. We don't have as many researchers looking at authentication-style bugs. So it's not always as obvious what a trend is, but I think it is kind of exactly what you said. It's something to do with volume. It's something to do with impact. It's something to do with how it's being used, and when you take a look at the larger picture, that drives where we're looking and where we want to go next.

Rohit Mothe: Yeah, I think George nailed it. It's kind of a weird mix of art and science, I guess. So there's no fixed number, Wendy, back to your question on does this need to happen four or five times? There's no super objective line. It's all risk analysis, right? In terms of pure numbers, yeah, George is right. I think integer overflow bugs, we have way more data. Just the volume of it is much more to justify investments. But something like this, authentication issues, even though by raw volume, it might not be as much, the story is a little different, because when we analyze the risk, we realize we can keep fixing individual bugs that keep coming, even though the volume might be lowered, or we can just holistically fix that and prevent these issues from happening again. So I think we got in a little earlier in the game versus integer overflow, if you purely look at volume, but it's that holistic analysis of risk, and I wish I could give you like a super solid algorithm to objectively look at that. But yeah, when you're working in the space, it's a bit easier to -- well, I shouldn't say easier. It's still complex, and sometimes it's like hard decisions, but you just happen to build an app for identifying trends.

Nic Fillingham: I think it also obviously talks to the need for folks like the two of you and the folks on your team who are very skilled researchers, and also able to create, or see, maybe a bigger picture out of maybe more disparate or seemingly disconnected things. I think that is both testament to you two as individuals, but also for the sort of unique abilities of a human, perhaps, in this role versus maybe something that could be seen as just sort of a "just data problem." I'm doing air quotes here. Feel free to pat yourselves on the back if you agree with that or not. The other thing I was going to ask is, okay, so what's the opposite or what's sort of the inverse? What are some of the edge cases here where administrators, IT folks might want to turn this back off? They might not want to have this protection on. Do we know enough about sort of some of those edge cases? And I only ask that in terms of if someone is listening to this podcast episode and they think, okay, we either just deployed these updates or we're about to deploy these updates. This protection is going to go turned on by default. Does anyone need to sort of double check that and maybe think about turning it back off for some sort of very specific scenario? Do you guys know the answer to that question?

George Hughey: I think that as a default, EPA, channel binding, these are things that are always going to be a positive for security. They're always going to improve security. It's essentially strictly better to have these things on than off. And so I think that's important to keep in mind if you are considering turning one of these off. There are scenarios that we are aware of that do get broken by turning these things on. Generally, that happens when somewhere down the line in some corner of the service, it has to do something like forward authentication. Then all of a sudden, EPA is going to break that specific scenario. We think we've gotten a lot of them, and we think we've improved a lot of those specific stories, but it's possible that they still exist, and there are really complex environments out there that are in use. And so it can be difficult to know every single edge case and to be able to make some sort of improvement for all of those edge cases.

Rohit Mothe: Right, and I would also highlight what George said, that it should be the absolute last resort for IT admins to just holistically turn on this feature, because that's going to be insecure, but for people who know what they're doing and there's very specific exceptions they want to build, then the blog post has links for each of the services that we talk about, right? Exchange, Active Directory, Certificate Service, and the Lightweight Directory Access Port called LDAP. We have many links in the blog post, and the listeners can actually click on those links and go to specific guidance for each of these services, which will tell you how to toggle them. I won't say toggle them safely because the inherent action of you switching this off is making you insecure. But we understand there can be some corner cases where maybe the clients don't support CBT at all. I'd also like to reemphasize what George said. The big push and the big work that MSRC and, more importantly, all the feature teams and engineering teams did here was to identify a lot of the low-hanging fruit there and fix those edge cases to be able to turn this to default. So really, anything that's still missed are -- the whole web that we cast is going to be very limited. But yes, there is specific guidance that we have linked in the blog post that should enable listeners to go and switch this off. Again, not recommended, but there is that option.

Wendy Zenone: So looking forward, what else is Microsoft doing to improve the authentication ecosystem? Is there anything else in the works or anything that's happening or coming up or potentially that is related or not related, but within the ecosystem of the same vein?

Rohit Mothe: Yeah, this is something we kind of indirectly allude to in the blog post. We're obviously exploring more services that we can enable this feature on by default, even if there's like an opt-in version available today. So that's one set of changes, and the second set of changes that, really, Windows and a lot of teams in Microsoft are driving is reducing the reliance on NTLM. So all the dependencies and usages that we are aware of in the field with our customers, we are fixing kind of functionality issues when even when you're using modern protocols like Kerberos, for some edge cases, they might fall back to using NTLM, and then that is a big work. We're making improvements so that the dependency of having to fall back to this legacy protocol is minimized. So, yeah, lots of positive changes in the works. I obviously can't talk about specific details, but I think we should be looking forward to massive improvements over time in Windows around this.

George Hughey: Yeah, this is a really tough problem to solve because we don't necessarily control these clients anymore. We might have the ability to push out updates to the servers, the domain controllers, the people actually doing the authentication. But when it comes to the clients of these Active Directory machines, it might be impossible for us to push out an update. And in many cases, they're not even Microsoft or not even Windows related. So it can be really difficult to make a change for the ecosystem where we don't have control over the clients, and we don't have any way to update those clients. So I mean to say just this is a huge shout out to the teams who are working on authentication at Microsoft because this is a really tough problem. If we could have just turned off NTLM, we would have done it a long time ago, but this is something that we really pushed towards and that we're taking really seriously to improve in the short and medium term.

Nic Fillingham: I want to touch on something that I think Rohit said earlier, I think, which is really just interesting. That, obviously, mitigations for a bug, a class of bugs get engineered. They get put into the product, but in many instances, they're opt-in, right? So they're not on by default. You have to go and turn this thing on. And as I think Rohit, you said, that's always an intentional decision because, obviously, there are such enough potential use cases that the risk of disruption to standard sort of operating practices for customers is high. And so build a mitigation, put in the product, but it is off. It has to be opt-in, and then you sort of help send out education, information, how it works, and the IT teams go and turn it on. But what you said there, what I thought was really interesting, is that one of the things that MSRC does, and maybe the two of you and your team, is that you're actually helping to drive down all of these edge cases through whatever bugs or issues that may be in the way of them, so that those mitigations can get turned on by default, right? Like it feels like that's sort of in some ways a focus of the work that you're doing. It's, hey, the mitigation's there. It's in the product, but we can't put it on by default because there's still XYZ is a high risk of sort of being true with customers. So let's see what we can do to go and fix XYZ so that this feature can actually be turned on by default. I don't know if I picked that up, and maybe that's just specific to this particular topic, but does that sound like sort of how you guys approach this stuff?

Rohit Mothe: I think, yeah, no, you're right, but I also want to say that's generally true for complex beasts like NTLM. So that definitely applies to this project, right? Because it has built up so much dependency and it necessitated this phased approach, as you said, which was, one, give the options to the consumers and the customers, I mean, to enable it. And that's, again, not oversight or complacency or laziness from our point. It's hugely disruptive to just go turn on something, right, which has such dependency over four decades. Phase two is -- specific to this project, at least, is where we want a lot of these mitigations to be then worked on to a point where we can start turning them on by default, and it is a huge amount of work, as you said, notifying customers, socializing that change, giving them time, and then, from the engineering side, working on all the problems to make sure we can minimize disruption to the customers. So anyway, kind of zooming out, yes, what you said is correct, but I don't think it applies for every project. But yes, certainly for complex stuff like NTLM with huge dependencies, that definitely applies. For anything newer that we're building in terms of security features or even Windows features that are more modern, I don't think we'll just make them opt-in only, right, especially with the SFI, the Secure Feature Initiative push. Right now, we're making sure everything Microsoft builds from now on is secured by default. It's only for these things that have been baked in in the ecosystem for a while. There's no other way than this phased approach. But I mean, yeah, that's the best we've got. And yes, the goalposts keep moving, but we are always working towards the goal of secure by default in the end.

Nic Fillingham: That's a really important distinction, and yeah, we're really talking about 40-year-old CNC machines and weird printers that no one builds them anymore, but they're critical to like, just, you know, we're not talking about, you know, a bank or a company that's just using sort of more traditional and IT. We're talking about customers that have -- they're relying on legacy authentication because they probably are relying on legacy clients and legacy hardware and legacy IoT, or IoT and legacy probably doesn't make sense. But that's probably an important distinction in this conversation here.

Wendy Zenone: I know that the last episode, which came out on December 7, 2023, so I think every year we're going to have you two on. You know, it just kind of marks a new year.

Rohit Mothe: Okay. We'll be the post-Thanksgiving/pre-Christmas special. I love it.

Wendy Zenone: Yes. Yes. We'll have a whole jingle and everything. But so in that episode, we talked about how you both got started. And I think Rohit, was it something like your dad told you, you need to go into engineering or something like that? I don't remember. It was --

Rohit Mothe: Wow. Okay, sure. Let's say that.

Wendy Zenone: I might be blending you with someone else.

Rohit Mothe: My dad would be happy if he's listening. That's a good narrative. I hope I said that.

Wendy Zenone: But we already went through your origin story. So let's talk about now. What's going on in your lives that are not work related? George, I think you just moved.

George Hughey: Yeah, that's right. I just moved out of Seattle. So the last conversation we had, I was probably still there, and now I've moved out to Rhode Island. Quite a drive. It was a 47-hour drive in total of time in the car. So it's not easy.

Nic Fillingham: We have planes now, George. They can do that in a fraction of the time.

George Hughey: That's right, but they don't allow four-month-old puppies on the planes. So we got a puppy. That's part of it. Yeah, that also did not make the drive easy because we were stopping every two or three hours to let her out. Yeah, it was a journey, but we did it over five days and we got here in the end. I was only a little bit grumpy by the end of it, but we made it.

Wendy Zenone: I would have been grumpy like 10 hours into it.

Nic Fillingham: I would have been grumpy like 90 minutes in.

Wendy Zenone: Right.

Nic Fillingham: Are we there yet? How many diners, drive-ins, and dives? What's that, Guy Fieri? Did you visit any amazing little hole-in-the-wall on the side of the road and have amazing burgers and shakes and all that good stuff?

George Hughey: You know, honestly, we were just trying to go as fast as we could. I did really like South Dakota. It was actually a lot of fun. We stayed in some town that I can't remember the name of and probably has less than 1,000 people in it. It was so funny. You're driving across the country on I-90 or any of those big roads, and you get the signs that have the town on them, and they say population 955 or something like that, you know, something tiny. And they're all 20 miles apart, but I thought it was really cool, just seeing what the countryside looks like. It was a lot of fun.

Nic Fillingham: And you have alpacas? Is that right?

George Hughey: No, I'm not sure where this rumor came from. I do not personally own any alpacas.

Wendy Zenone: I totally made that up. [ Laughing ] You don't have an alpaca farm, George.

George Hughey: They probably would love the dogs, and the dogs would love that. So maybe it's a good idea.

Wendy Zenone: Rohit, what's going on with you?

Rohit Mothe: Okay, oh, geez. This is kind of putting me in an awkward position. George has way more fun updates than me. Okay, darn, I've got to think of something fun.

George Hughey: I have some fun updates about Rohit while he's waiting and trying to think. We had a lovely team lunch together and afterwards got to go bowling.

Nic Fillingham: Just you and Rohit?

George Hughey: No, no, it was the whole team. There were, like, ten of us or so. We went bowling, and we played two games and Rohit probably had about 25 gutter balls. It was a lot of fun.

Rohit Mothe: This is probably the last podcast we're doing together. Cancel the Christmas special.

Nic Fillingham: Your gutter balls were all the more impressive because you had bumpers up, right? Like, how did you manage to --

Wendy Zenone: Yeah.

Rohit Mothe: There were no bumpers, come on. I just wasn't able to tame my spin. I just spin so much. You have to remember, gutter balls in one lane are basically strikes in another lane. So it's just not focusing on the lane, right?

Nic Fillingham: No, the issue was the lane was either too freshly waxed or not freshly waxed enough, right?

Rohit Mothe: Yes, exactly. I don't think it was freshly oiled.

George Hughey: My ball was going straight, so I don't know about that.

Rohit Mothe: You're not bowling. You're just relying on luck.

Nic Fillingham: So what's next for both of you, either with your researcher hats on or with your future alpaca farmer hats on? What's next for you, George?

George Hughey: Well, there's lots of stuff going on. I got engaged recently, too, so that's pretty awesome.

Wendy Zenone: Congrats.

George Hughey: That happened over the summer. I wanted to do it before we moved out to Rhode Island, so she said yes. That's great.

Nic Fillingham: Oh, good. That was my next question.

George Hughey: So, yeah, we're just kind of getting our feet settled here, and then we'll figure out what we want to do. We have an eight-month lease on our house, so we've got a little bit of time to figure out exactly what it is we want to do. As for the professional side, I've got some projects in the works. I've got one I'm really excited about that Rohit is also working on me with. So it might be about this time next year that we're ready to talk about it externally, if he still wants to talk to me.

Nic Fillingham: We'll mark our calendars.

George Hughey: It's some really, really cool research, and I wish I could share it, but a little bit too early just yet.

Nic Fillingham: Can you hint just the domain that it's in, perhaps? Is there a little hint without giving anything away? Don't break into jail.

George Hughey: What do you think, Rohit?

Rohit Mothe: We can, but --

George Hughey: Yeah. Well --

Nic Fillingham: Is it those Tesla robots that look like waiters or something? Is that what it is?

Rohit Mothe: Oh, way, way more boring than that.

George Hughey: It's related to Mark of the Web, which is a feature that we've had a lot of recent incidents in and a lot of focus on. We're spending a lot of time and effort looking at Mark of the Web, and we've kind of carved out a little corner of it that we've really wanted to spend some time in, and we've made a lot of improvements, and a lot of improvements are on the way. So once those are all out, I'd love to come back and talk more about this.

Nic Fillingham: Sounds good. Rohit, what do you want to leave us with about what's next for you, either professionally or personally or just in your bowling career?

Rohit Mothe: My bowling career is pretty much dead on arrival. But yeah, I think professionally, yeah, I'm looking forward to the project that George kind of teased. I think it's going to be pretty epic, and hopefully, we can talk about it soon. There's lots of other fun projects that we're working on as well. Personal side, well, I'm going to Hawaii in December, Maui.

Wendy Zenone: Woo!

Rohit Mothe: Yeah, we wanted to go to Puerto Rico, but then planning fatigue kicked in, so we were like, let's just go to Hawaii.

Wendy Zenone: I know that planning fatigue. I've done that so many times. I've been on so many adventures, and I'm like, forget it. We're going to Disneyland.

Rohit Mothe: You would think Puerto Rico would be easy to plan until you actually start planning, and then you realize how far away it is. The shortest flight is 12 hours, I think, from up here in Seattle, yes.

Wendy Zenone: No. I'm going to scratch that off my list then. I'm going to Maui too.

Nic Fillingham: You should grab a puppy and drive there. See if you can do it in under 57 hours.

George Hughey: Yeah, it's a great idea.

Rohit Mothe: Do it the George way, yep.

Nic Fillingham: Well, on that note, gentlemen, thank you for returning to the BlueHat Podcast, and we look forward to talking to you hopefully before this time next year, but maybe this time next year on your next little project together. Thanks for joining us, and we'll make sure there are links in the show notes for all the various acronyms and blog posts and everything we mentioned so people don't have to write anything down, but thanks for joining us, guys. We'll talk to you again on another episode of the BlueHat Podcast.

George Hughey: Thank you so much, Nick and Wendy. Have a good one.

Rohit Mothe: Thank you, Nick and Wendy. [ Music ]

Wendy Zenone: Thank you for joining us for the BlueHat Podcast.

Nic Fillingham: If you have feedback, topic requests, or questions about this episode --

Wendy Zenone: Please email us at bluehat@microsoft.com or message us on Twitter @msftbluehat.

Nic Fillingham: Be sure to subscribe for more conversations and insights from security researchers and responders across the industry --

Wendy Zenone: By visiting bluehatpodcast.com or wherever you get your favorite podcasts. [ Music ]