In this episode of Know Your Adversary, Jared Atkinson and Justin Kohler sit down with SpecterOps researcher Raj Patel to discuss his discovery of vulnerabilities that bypass SMB and LDAP signing protections through reauthentication and NTLM relay attacks. What began as research into Kerberos relay led to findings that challenge long-standing assumptions about one of Active Directory’s most trusted security defenses.
Raj walks through the discovery process, the role of AI-assisted research using OpenAI Codex, and how these vulnerabilities could enable attackers to compromise Active Directory environments through techniques like shadow credentials and DC Sync. The conversation also explores Microsoft’s patches, the ongoing risks of NTLMv1, and what defenders should prioritize to better protect their domain controllers.
00:00:04.040 — 00:00:24.960 · Speaker 1
Raj Patel set out to research Kerberos relay. What he found challenged a defense that security teams had trusted for years. We follow his research from SMB to Ldap. Explore AI's role in their discovery and discuss what it means for protecting Active Directory. This is Know Your Adversary by Specter Ops.
00:00:26.320 — 00:00:41.880 · Speaker 2
Welcome back to the No Your Adversary podcast. I'm Jared Atkinson. I'm Justin Koehler and today we're joined by our colleague of specter ops, Raj Patel. Raj, do you want to maybe give us a little bit of an introduction to you? Tell us a little bit about yourself, how you got started in cybersecurity, where you find yourself today.
00:00:41.920 — 00:00:44.240 · Speaker 3
So I started in cybersecurity
00:00:45.440 — 00:01:25.900 · Speaker 3
six years ago, I think, and I started as an intern in a pen testing team. So my professor told me, if you get your OCP, then you can get into the offensive space of cyber. And that's what I did. I landed my first job as an intern worked my way up through here, and I'm here at Specter Ops now. It's been almost three years.
My primary role is consulting, so I'm a consultant. I do pen testing, red teaming, and a little bit of research whenever I get some time. And I also teach our identity driven offensive tradecraft course and the red team. Operator. So, um. Yeah. Um, anything that is thrown my way, I do it.
00:01:25.900 — 00:01:56.180 · Speaker 2
Awesome. And today we wanted to have you on because you just dropped a blog post about an Ldap signing bug that you that you discovered. Um, but there's there's a little bit of a backstory about this whole thing about, uh, how you discovered it, and then it ended up getting patched because maybe somebody else found it at the same time.
And there's all kinds of there's all kinds of, uh, work that went into that. So maybe you could tell us a little bit of the story about what the bug or the bugs are that you, that you found, how you went about finding them and kind of what that that experience was for you.
00:01:56.500 — 00:04:33.200 · Speaker 3
Yep. So I started researching for Kerberos Relay initially, and the Kerberos relay led into this SMB and Ldap signing bypasses that I found. So I was looking at the session key stuff. Right. So that was one of the the factors where where you cannot use the TGS with Kerberos. Right. So you need that session key to do a authenticator and stuff.
Right. Craft and authenticator. Send it to the domain controller to request more service tickets or access a final service. Right. So session key was the, um, the final bit that we needed to bypass anything. Right. And I had codecs configured in my laptop and in my lab environment. And I through Codex edit and go and tell me and find anything about session key that you can for Kerberos.
Right. So it did identify like within within a few days I think it identified that there is something wrong with the session key where you can reuse or re authenticate or basically send someone else's credentials through the existing session key that you already established with your target or the the resource that you want to access.
So that's when things got interesting. And I initially found this in August. And the way Codex was explaining things to me, even I wasn't understanding it at first. Right. So it took me took me a few iterations. And then in the second week of September, when I came back to this research, that's when I really found the SMB signing, um, bypass with it.
And as I was chatting with Codex, doing more research on Kerberos and TLM, I identified that we can use this this bug that codex found to perform TLM relay against a target that requires SMB signing. So that was my first initial discovery, and I had codecs to write a POC for me. Perform reverse engineering.
Tell me if this bug that you told me does really exist because it's going to break the internet and, um, yeah, I was I verified like 100 times, manually verified, reverse engineered, all the DLLs, many, uh, check the POCs. Right. So sometimes, um, I have seen codecs do hardcode stuff into the, the POC to make it work.
And so if you keep telling codecs like, hey, there is something here, there's something here, eventually it will put something in there to make it work.
00:04:33.320 — 00:04:35.520 · Speaker 2
Just to satisfy you basically. Yeah.
00:04:35.560 — 00:05:08.100 · Speaker 3
Yeah, exactly. So, um, yeah, I, I manually verified everything a hundred times before even telling anybody. So that's when I told my colleagues, I think you were on the call, Gerrit, where we discussed the initial finding. And then, um, from there, people threw ideas around, Around eight, so I. I went back to my lab to tell Codex, hey, go look at this thing.
Go look at this thing. Go look at this thing. And that's when I narrowed down the research to bypassing the SMB signing.
00:05:08.980 — 00:06:33.960 · Speaker 2
Yeah. And and maybe, uh, Justin and I kind of preface this call with the idea that, uh, we are not red teamers, and we will kind of be the, uh, take on the responsibility of the viewer and kind of interrogate some of this stuff to make it a little bit simpler to understand, potentially. The, uh, previously specter ops released, uh, in TLM attack pass in Bloodhound, and one of the security controls that we had to take into account is SMB signing, um, or potentially Ldap signing as well, depending on the type of relay that we're talking about.
And, uh, for years and years, uh, enabling SMB signing has been the security control that, uh, like red teamers have told their customers they need to implement to fight off the these attacks. Right. So this NTL em relay attack, which is ubiquitous across all all these big companies and and so the idea is, is that if you have control of any authenticated user, you can establish an SMB session and that gives you a signing key.
And then later on you could inject your own, you could inject a relayed credential for some other user that did not establish a session into that prior. Prior, uh, established a session. And now you can authenticate that way and continue to do the relay despite the fact that that security control is in place.
Is that kind of an accurate description of what's going on?
00:06:34.000 — 00:06:54.220 · Speaker 3
Yep. It's very accurate for the SMB signing bypass. So first you establish a SMB connection with a credentials that, you know, and then you keep the session key. And then you relay a victim and you send the victim's and TLM messages through that existing SMB session and sign it using the session key that you already know.
00:06:54.700 — 00:08:31.040 · Speaker 2
I was just going to say the the the credentials, you know, is if you fished a user. There are myriad ways for you to know their credentials essentially. And so the idea is, is that you always know at least one user's credentials, basically. And then it's a matter of finding somebody whose credentials you do not know to be able to establish that relay connection and privilege escalate within the within the domain, for instance.
Yeah. So like I'm going to I'm going to go even like like a little bit dumber than that. I'm going to say like NTL m relay was a really bad thing. And we could go from a low privileged user to like very high privilege, like domain admin, enterprise admin. Right. And the protection for that, like you guys said, was SMB signing.
And so part of the value of of seeing that in Bloodhound Enterprise or Bloodhound in either either product, actually you can see the relay targets was you could see the ones that were still susceptible to a relay kind of kind of attack. Um, but that was all under the assumption that SMB signing was a security control that could prevent this.
And then and then like we got notice of this internally and we were basically saying like, oh God, Rodge just broke Active Directory. Like, like this, this thing that everybody has put a control around is not actually a control. And there's no way to block it. Like there's no there's no other. The only possible way to protect against this is a patch which is available now.
And that's why we're talking about it. But it was like, this is extremely bad. Like Roger's like, I don't know if you're if you felt that way when you heard it across here, you're like, oh my God. Like what I just found could be like.
00:08:31.440 — 00:08:46.440 · Speaker 3
To be honest, I wasn't able to believe anything at first because, uh, Codex told me Codex figured it out. Right. But after I knew, like, this is this is really existing and it's working. That's when I found, like, A.D. is on fire now.
00:08:46.720 — 00:09:08.780 · Speaker 2
Yeah, yeah. And that's like. So we're, uh, we're we're partners with OpenAI. Right. And so you're using their cyber models and, like, doing, like, targeted research. And that's like kind of the value of, of us working back and forth to that. And like a skilled adversary like you like going off on a specific research initiative.
Um, but it must have been a little bit jarring. You're like, oh my gosh, this is true. Like, this is really, really bad.
00:09:08.860 — 00:09:09.420 · Speaker 3
Yeah.
00:09:09.860 — 00:11:32.100 · Speaker 2
I just just to give Roches flowers the, uh. So we have a daily research stand up. And this is where he kind of, like, initially told some of us about it, and, uh, Andy Robbins and Gary Foster, two people who I'm sure people listening to this podcast are familiar with their work. They were both there and they were flabbergasted by this.
Uh, and and I just recall it was like, okay, Raj, we we probably need to test that this continued that this actually works on like every version of windows, including the most up to date one. You know, it's like somebody has to have found this before and and eventually he came back and was like, nope. It still works on like the most recent Latest.
Latest patch. Uh, obviously that was. That was prior to the the new patch coming out, but, um, it affected every version of windows, so. So I'm going to spell this again for people who don't understand like you, you any authenticated user does not need system level access on a host. Any authenticated user with this, uh, this vulnerability could initiate an NTM relay attack.
And long story short, do a DC sync become domain admin. There's no way to block it. Fair. Assuming they have access to the credentials to relay. I'm sure is probably the caveat there. But, uh, you know, one of the things that I, that I used to do in these compromised assessments that we used to do back in the day, kind of before EDR really took off.
Uh, there are scanners that are scanned, like people have products that are scanning their environment all the time, and those are usually highly privileged scanners. And those scanners are usually, exposing their credentials for relay all over the place. And so, um, there's, there's, there's usually ample opportunity to just kind of passively capture, capture those types of credentials.
So this this is an extremely impactful finding. And so part of why why we're doing this podcast. I mean, you're just released the blog post. We're like, we want to get this information out to our customers and we send notices out to them. We put like, banners in Bloodhound Enterprise to let them know that they should patch this as fast as they can.
Um, but like, if you could think of a like the what is this? What did you walk away with? Uh, using things like Codex and doing this targeted research, like, is anything safe? I guess I don't know if that's a fair question for you, but, like, you're like, oh, I found this flaw. What else is.
00:11:32.740 — 00:12:12.239 · Speaker 3
Yep. So I think signing was the answer to protecting against relay attacks for last 20 years. 25 years, I think. Yeah, and Codex broke it within a couple of weeks, so I now I feel like we are unsafe no matter what. Like we have to do things the right way to protect ourselves from such such attacks. Right. And we have been keep telling our customers or on our reports.
Right. Enable signing and then not to use NTM because it's like it has many flaws in it and customers keep using it. And I think
00:12:13.320 — 00:12:24.000 · Speaker 3
that that takes it even, um, to the next level. So that breaks things much more, um, make things worse for the customers basically.
00:12:24.320 — 00:12:36.680 · Speaker 2
Maybe, maybe it's worth, uh, so there were two bugs, one, uh, as I understand it, but feel free to correct me was until Im signing and like a vulnerability, an interim sign. And another was an Ldap signing.
00:12:36.720 — 00:14:46.100 · Speaker 3
No. So first one was the SMB signing bypass, and the second one was the lip signing by password. So yeah, when I was testing, when I found it, and then I continued testing against other versions of windows. Um, it was patched, right. Um, I think within a couple of days it was patched because it was the, the Microsoft Patch Tuesday coming up in that week, and it got patched in that one.
So, um, I was trying to bypass that. I was focused too much on, on bypassing this bug because it was super huge and I wasn't able to bypass it. And that's when Elena told me to go look at lip signing and see if there's, um, a same bug that exists in Ldap. So that's what I did. I went after Ldap, and um, eventually I found another bug within Ldap that we can, if you, um, chain them together, then you can bypass the lip signing.
And it works very similarly. So first you establish a lip connection with the domain controller In this case, it can be an anonymous connection, so you don't even need credentials for establishing this connection against a domain controller. So once you do that, you keep the session key, and now you relay the victim and you put the NTL message and the operation that you want to perform in that same packet or the same Cecil record, and you send it everything in one packet to domain controller.
Right. So now the domain controller will use the session key that you already negotiated with it on the existing LTP connection. It will use that to verify if it's signed or not. And then it will switch the authentication to your victim and then execute the Ldap operation as the victim's authorization.
So that what makes it more powerful where you can relay one domain controller, Sorry. Coerce one domain controller and relay to another domain controller and instantaneously take over the domain.
00:14:46.580 — 00:14:55.820 · Speaker 2
Can you maybe enumerate a couple examples of what what types of operations can I use to take over the domain via Ldap?
00:14:55.940 — 00:15:30.980 · Speaker 3
Yep. So two that comes to my mind is the resource based control delegate. Resource based constrained delegation. And the second one is shadow credentials. So with that the first one with the first one you can write to MSDS allowed to act on behalf of other identity attribute of Ldap with a Ssid that you control, or with an accounts set that you control.
And or you can perform shadow credentials. And after that you can do DC sync and get password hashes of any user in the environment.
00:15:31.300 — 00:16:04.480 · Speaker 2
Yeah. And you mentioned coercion. So by default there are services again. This is I'm saying it as a statement, but feel free to correct everything that I say, because I'm kind of just repeating what I've heard from other people. So by default, there are services running on every domain controller that have coercion primitives kind of embedded in them.
A coercion primitive is basically when you are able to get a computer to authenticate back to you, and then that that would expose the credentials of that computer for, for relay. Does that sound right so far?
00:16:04.600 — 00:16:04.960 · Speaker 3
Yep.
00:16:04.960 — 00:16:14.560 · Speaker 2
It's good. Okay. And then but the problem was is that domain controllers by default have have I guess Ldap signing turned on.
00:16:15.160 — 00:16:30.960 · Speaker 3
Not by default. So I think after 2025 is when they enforce started enforcing signing on domain controllers for SSA. But SMB signing I think was enabled in servers even before that I see.
00:16:31.000 — 00:16:58.620 · Speaker 2
Okay, so but it's probably most common for signing to be enabled on domain controllers as composed as compared to, say, some arbitrary computer throughout, like some workstation throughout the enterprise. And so that that made it to where despite the fact that this coercion primitive existed, it wasn't obvious that you would be able to leverage that coercion primitive to authenticate as a domain controller until signing no longer works as people thought it did, said Schultz.
00:16:59.100 — 00:17:07.579 · Speaker 1
Thank you for listening. If you're enjoying this episode, please like and subscribe. It really helps us spring conversations like these to life. Now let's get back to the chat.
00:17:08.060 — 00:17:49.000 · Speaker 2
Maybe an interesting thing that popped in my mind as you were talking about kind of your your approach. You started with the SMB signing, uh, vulnerability, and then you said that it was patched. And this is this is actually a really common, uh, kind of paradigm. It's almost creates kind of this natural selection type activity, which is you you're going to take the path of least resistance to some degree for your research Until that that opportunity is no longer there.
And once that's taken away, there's kind of this imperative for you to find some new ground to, to discover. And that's that sounds like that's what kind of led you to the the Ldap signing vulnerability. Yep. Exactly.
00:17:49.040 — 00:18:57.140 · Speaker 3
And even the so Ldap signing got patched. So I we we found it. We were talking internally about it. It's a huge deal. Right. And then we were writing the report uh to you report to MSK. And then we submitted that on October 6th I think. And on October 13th, I think the the patch came out where it it's no longer vulnerable.
So I and after we released the blog post, I had a couple other researchers reach out to me. They said they saw something similar with Ldap. Um, not exactly what I found, but something similar. Yeah, um, in Ldap and they had reported it to Microsoft, and I think that may have led them to look into other bugs that may have existed in Ldap or SMB and fix it.
Right. And um, before we we published the Ldap signing blog a day before that, the SMB signing blog post came out. So that was also identified by another researcher. And, um, yeah, I think we simultaneously found it. Yeah.
00:18:57.300 — 00:19:54.080 · Speaker 2
It's good. It's good to see, like, I mean, uh, Microsoft has been inundated, like if you see any of their internal charts in terms of how many vulnerabilities there they're getting both internally and externally. Source like, it's cool. Like they're they're making work on these things. Um, the so you said it came out on October 13th.
So, uh, if our customers have have that patched up to the up to that date, then they are safe comma for now. But but long story short, like, uh, the, the industry has been trying to move away from an TLM. So like that's kind of like we still would say you should just get rid of TLM. Like, yes, this is a a you can't secure it by using Ldap signing and SMB signing on this version.
But kind of takeaway here is there's probably going to be something else. And you don't don't rest on trying to get rid of NEM. So for those that have like high five you don't need to worry about this problem.
00:19:55.320 — 00:20:12.239 · Speaker 3
Something crazy, uh, that I'm going to reveal in this podcast is that neon V1 extended security session is always vulnerable to, um, SMB signing bypass and lip signing bypass. So
00:20:13.560 — 00:20:23.080 · Speaker 3
the the fix that Microsoft came up with only affects until v2, not until V1. So it's like a distinction.
00:20:23.520 — 00:21:51.520 · Speaker 2
So if anybody has an TLM v1 still running. Yeah. And you didn't feel bad before You should feel really, really, really, really bad now. Yeah. But that's also been, you know, for as long as people have been, I think of Sean Metcalfe as the person that's been on the like, upgrade your intelligence bandwagon for since I've joined the industry basically.
But yeah, it's, you know, that that recommendation to upgrade to NTM v2 has been around as long as the recommendation to enable SMB signing, uh, has been, has been around. And so, you know, obviously in in practice sometimes it's harder to get that 100%, uh, than, than it might seem. But that's always that always should be the goal of the direction that we pursue.
Well, I think that's the, the, um, historically, like let's say rewind time, like at least one year ago or maybe 2 or 3, like you could potentially obscure it in complexity, you know, like maybe it would take in a skilled adversary, like. But, uh, Raj, you're saying like the SDKs that you wrote, like in some tools, it's it's pretty easy, right?
And like, I don't think that we're going to see that go away anytime soon. I mean, the, the ability for, uh, AI and large language models to wrap something where it previously took somebody very, very skilled like we used it conversation or this statement internally. It's so easy just an can do it like it's probably so easy.
I could do it right. Like it doesn't take a skilled person to to execute these anymore. Yeah. If you do it just and it won't be pretty, but it'll be fun. I mean, it would work though. Yeah.
00:21:53.040 — 00:22:05.840 · Speaker 2
All right. Awesome. So, Raj, thanks for joining us and telling us about your research. Do you have anything you want to? I know you had that reveal at the end about, uh, NTM v1, but, uh, is there anything else that you want to add before we, we go?
00:22:06.480 — 00:22:09.120 · Speaker 3
Nope. Just batch your domain controllers.
00:22:09.760 — 00:23:13.340 · Speaker 2
Awesome. Yeah. And so, uh, that's that's a really good point, is that, you know, I did I did a podcast with, uh, I don't even remember what company I was from, but one of the typical vulnerability scanning companies that maybe koalas, uh, for instance. And one of the things that he really emphasized was this idea that you, uh, we don't have to treat every system as the same.
And so in your patching workflow, it's useful to differentiate between the systems that need to receive patches faster and those that maybe are a little bit more, uh, you know, not not quite as important to your overarching enterprise. And so that that recommendation that you just made of focus on your domain controllers, and then you could worry about the other systems later or as, as time allows.
I think that's that's very good advice for people to really focus in on. Awesome. Well, thank you again, Raj. Um, super scary stuff. Nice to know that there's a patch out for it, because I remember when we were talking about this internally, we're like, oh, this is going to be a very long, coordinated, uh, disclosure timeline.
Um, but good to know it's there. Just, uh, again emphasizing, please pass your domain controllers today.
00:23:13.460 — 00:23:14.580 · Speaker 4
Thanks for having me.
00:23:14.900 — 00:23:16.700 · Speaker 2
Thanks, Rosha. Thank you everybody.
00:23:17.060 — 00:23:22.660 · Speaker 1
That's another episode of Know Your Adversary. Thank you for listening. Like and subscribe so you don't miss the next one.