Nightmare on NTLM Street: Legacy's Revenge

Ouch. No, it wasn't the badge. Sorry. No magic smoke here yet. So, welcome to the afternoon. Thank you for indulging our small delay. Let's just make sure everyone had time to get lunch. And thank you, Marina also for for that. And so, without further ado, Marina, welcome back. And the stage is yours. Thank you.

All right, technical difficulties resolved. Hi everyone, my name is Marina. Thank you very much for joining after lunch. Thank you Bruno and George for the invitation. I was here last year. It's actually my very first cyber security presentation. Uh and since then I've done quite a few more and also organized besides Amsterdam which is on Thursday. Uh so I'm not being very responsible right now but um I do have a clicker actually if it'll work. Yes. So um about the director uh I live in Amsterdam. I currently work at zsert which is the sectoralert for the healthc care sector in the Netherlands. Um been there for a couple months now. Uh I am obsessed with cats. Um I think that's

the main aspects of my personality honestly. Um so I'm yeah I'm very happy to be here. There have been some really really great talks and I'm very grateful to be in the lineup uh one more time. So um yeah this talk has some disclaimers. Um does anyone uh so I have to uh see if I can actually see my notes. Um yeah I need to do a disclaimer. So none of the talks sorry none of the opinions I have none of the mistakes I talk about are uh related to any previous current employers uh all opinions and mistakes are my own um and this is also not a uh this is not a cyber security talk this is

non-consensual group therapy and I need this more than you do and I've made this talk a few times and it's about a project that was a thorn in my side for a couple yeah a couple years actually. Uh it's for a company that I no longer work for. So I'm limited in the details I can share and that also unfortunately means no screenshots of the actual environment. Um hopefully you won't need them. I think the point will get across anyway. But yeah, you may be wondering, um, sorry, I have a bit of a disconnect. Um, I don't know what's happening. One moment. All right. Yes. So, NTLM, uh, it was kind of a pain in the ass. I'll be

honest. The original goal of that project, spoiler alert, actually failed. Um, that was that was unfortunate. But my goal today is to share some of the lessons learned, hopefully help someone else avoid a dumpster fire of their own. Um, that would be really great. I uh yeah, it was it was an experience and um I will sorry I really don't know what's wrong here. Um yeah. Ah. Okay. Yes. Sorry. This is a very rough start. I don't think I've ever done that before. But since this this this is non-consensual group therapy, I will be asking some questions that might seem rhetorical, but they're not rhetorical. So, I'd like you, the audience, to answer them with me. Uh, as

an example, aren't we having a great conference so far? >> Fantastic. Aren't you so excited to listen about a 40-year-old legacy authentication protocol? I did not expect that one to be that loud. So, you may be wondering, uh, since we're here, what is NLM doing at a cyber security conference? That wasn't a rhetorical question. Um, counter question. Does anyone here know what NLM is? >> All right, a bit. Uh, does anyone here know it from the IT or CIS admin side? All right. Does anyone know it from the offensive side and be really loud? >> This is why NLM is at a cyber security conference. Does anyone here work at Microsoft? Okay, I think we're safe.

So before I I continue to where everything is on fire and nothing's working and everything's breaking, I'm going to provide some context. So I had just started at this company. Um and I wanted to make my mark. I wanted to prove my worth, proof my value. I was going to make an impact. And being the humble and sensible person that I am, I picked a project that was unresolved with no progress for several years at that point. There had been a few attempts to finish it. None had succeeded. That project was removing NLM in all its forms from the company. So you might consider uh why that happened. I did not. To me, this was a

security problem and I was a security person. It seemed straightforward enough. So, I was going to tackle it. It would be fine. Um, and I only so I didn't know what NLM was when I agreed to finish the project within six months. That might have been helpful. But, uh, yeah, I just I don't know. I had faith or or delusion, whatever you call it. And when I started researching, I realized that it was not at all straightforward as I had thought. When you go to research NLM, you may encounter any number of these terms. They're not always used in a consistent manner. They're not defined the same way everywhere, not even by Microsoft who invented it.

Uh, none of this is interesting and I don't want to put anyone back to sleep, so I'm not going to talk about any of this, but if you need a translation chart, come see me after. I'm happy to share it with you. But what I found out was that the whole NLM authentication protocol family started with LAN manager. So back when dinosaurs went to school, land manager was used in the LAN man software suite of Microsoft year was 1987. Now LAN man is a challenge response mechanism. Uh I think we're all familiar with those. Client wants to authenticate to a server. Server sends back a challenge. The client sends back the challenge with its hash some other

stuff. And if that is the value the server expects, then it grants it access. And if not, then you know, too bad. There are several problems with it. So for one, it uses dees, which is not great. Uh the LM hash also really sucks. the the there is no minimum password length and the maximum length is 14 because uh you take like it takes the the password into two seven character bits and then kind of remashes them together. So if you have more characters those get cut off. If you have fewer then they get padded. So that makes the whole key space cracking space very small very arbitrary to crack. uh there is no mutual authentication between the

client and the server which is bad because while the client has to prove its identity to the server, the server doesn't have to do that to the client. So your client could be authenticating to a server, a domain controller, or I don't know, anything else you put in front of it. So that makes it vulnerable to man-in-the-middle attacks or adversary in the middle, but that's too many syllables. Um so the passwords are also case insensitive. So whatever you put in as the password gets uh just put into uppercase. So that also limits your amount of entropy that you can put. Uh there's no MFA possible. This was legacy. They didn't have such a thing. So I could go into some more detail

about how it works and how everything gets packaged up for backwards compatibility. Or I could just show you uh the cracking of an LM hash using a rainbow table in less than a minute and 30 seconds. So if you have a an extra seven terabytes of disk space, you can try this at home. So that sucks. Um what do they do about it? So yeah, um you don't even have to go through all the effort if you just get in there. That's our lovely man-in-the-middle attack. And because kind of the the functional vulnerability I guess you could call is that the password hash is used exactly the same way as a password. So you don't even

need to crack the password if you can just take the hash and then shuffle it around the rest of the environment. So that is not ideal. So in the year of Jurassic Park, the very first movie, uh they came up with NLM. At the time it was just NLM. Now we call it NLM1, but it works basically the same way with some minor improvements. Uh instead of using desk for the hash of the password itself, it uses uh MD4, which is weak but slightly better. Um, it still uses dees. It still doesn't Yeah, I forgot to mention no salting of the password. So, very much decreases your entropy. Uh, so still no salting here. Uh, you do have a

longer password. You can do uppercase and lowerase, which also good, but it's kind of a basic thing. So, no mutual authentication still. So, you can still do man-in-the-middle attacks. And there's no multiffactor authentication. So I don't know what took them six years to develop. So in uh just a few years later, coincidentally, this was the year my parents got married, so I wasn't on this earth yet. Um but NLM version two, again, some improvements. A big one is that it uses HMAC MD5 instead of DUS, uh which makes it significantly harder to crack, but again, not impossible. Uh, it also sends the challenge back with its own client challenge plus a timestamp. So, this means you can't really reuse

the hash like you could previously. Um, and it still though unfortunately is unsalted. Uh, MD5 is still vulnerable. You know, we're recommended not to use it. Uh, and again, no mutual authentication and no multiffactor authentication. So not great. Then just three years later uh Karos came about. I am older than Karose thankfully. Uh it is it is way too complicated to go through now. Um I'm not going to waste time on that but it is significantly better. So it uses AES which is much more difficult to crack. So you can't really you know you can do offline attacks which is called career roasting but uh it's not as easy. It does require mutual authentication so

it's not as trivial to do man-in-the-middle attacks. Um it does salt uh it does give you timespecific sorry machine specific and time limited tickets. So you can't really reuse the same way but you can still use an NLM hash to get a careerose ticket uh which is called overpass the hash and there are a few other you know catchy vulnerability names. So you know objectively karosa is better in every way and uh in fact NLM is so vulnerable I went and and did some research just to find a list. It was too long to put on a single slide but anyways Microsoft uh got rid of it already in some of its software additions. Um, it has been telling us to

get rid of it for a while and last year it was finally deprecated. So nothing is under construction. It's been telling us, Microsoft has been telling us we have to get rid of it. We have to stop using it. But Microsoft tells us we have to do lots of things. Doesn't mean that we actually do them. But in this case, there is a genuine reason. I'm not a redteamer. So, I'm not going to talk about any of these tools or any of these, you know, tactics, techniques, and procedures because I'll probably explain them wrong and I don't want anyone to get mad at me. But, um, this is a very well doumented vulnerability and exploit. Tons of these things have

happened in the wild. So, again, these are just a few examples. Uh, at the bottom, this is just MITER. I, you know, listing every group that has used abused NLM in some form or another. Um, probably all their moms know it too. But this last example uh was actually given to me by a guy at TU Einhovven. So, a technical university in Einhovven in the Netherlands. And they had a breach because NLM1 was still activated. And like me, they had also tried to get rid of it before that happened. And magically, um, at the time they didn't have the budget, but somehow after the incident, money just tends to appear. So anyways, Carros is better in every

way and NLM is just this gross barnacle that has been sticking around. And in fact, there are so many vulnerabilities that at some point they stopped writing them out. individually by hand and they just uh started copy and pasting the same text and just changing certain things about it which I kind of get to be honest you know efficiency whatever but yeah I think now you understand why this company wanted to get rid of it and at first glance it seemed fine uh you know we were aware of some legacy servers that definitely couldn't be upgraded oh well they were going to be segregated. But for the rest, it seemed okay. I mean, Care Bros had been the

default for over 20 years at that point. And I don't know, Microsoft had been telling us to stop using it. So, they clearly must have been ready. So, you know, after researching, I wanted to get a lay of the land, do some inventorization, and thankfully a billion, multi-billion dollar company like Microsoft provides you adequate tooling and communication that lets you find exactly where NLM is used within your IT infrastructure. Uh, it tells you, you know, you can see what happens if you get rid of it. Tells you how to how to move to Kerros. helps you do all of these things, right? Wrong. But, you know, the fact that the Microsoft documentation is so short and limited, it probably means

that it's not that big a deal and it's not that complicated to get rid of, right? >> Also, wrong stuff is nondescript. links are broken. Documentation that is referenced to other documentation doesn't exist anymore. Uh so it's yeah it's not very easy. Luckily there were some good Samaritan CIS admins that have done a lot of research on this. Uh most of them are not affiliated with Microsoft. They did this in their own time at their own cost. So I think that's also important to note. But anyway the project was kind of officially underway. So when you go about disabling NLM, you first have to enable specific NTLM authentication logs that tell you where NLM is being used.

These are not enabled by default. So we had no historical view. So you know have to turn it off and then wait for a while see what comes up. But luckily our favorite 4624 logs happen to tell us which NLM package is being used. It's not from the company. It's just a general example. But if you go digging around in your own environment, that's probably what you'll see. So decided to use those and you know, take a look. So I did that and uh what I saw was this LM. I didn't even think it was being used. I just thought I was tackling NLM version one and two, but it was absolutely everywhere. So, I saw that and I

panicked and then I did some more digging and apparently, I don't know why, please don't ask me any questions about this, but things were using LM and NLM1 and TLM2 and there seemed to be no rhyme or reason. It was just all over. So basically I uh you know cross reference cross referenced everything and I could see that everything that was using NLM 102 was also using LM. So you could probably turn off LM for those and it would be fine except for all those legacy Windows 2003 servers that were exclusively using LM or NLM1. Um, those were old enough to drink at that point in the US. So, okay, that was not nice to find out,

but it's always better to find out before you turn something off rather than after. So, okay, we keep going. Um, so I decided to uh start working on NLM1 for real this time, not sidetracked by LM. And uh this is the point in the story where the narrator says something about the main character not being prepared. Um which would be accurate. But anyways, uh you got to make a start somewhere. So I just I was looking at NLM logs and I saw this the worst offender of them all. Anonymous log on. So again, I panicked and then did some more digging. And this is thankfully a red herring. Don't ask me why, but lots of

Windows functions like IIIS and something else uh will log connections and things as NLM1. Even though they're not actual authentications, even though there's no data being transferred, it still gets logged this way. I know the magic of Windows. But anyways, so now we had a list of everything using NLM one and two. And the next step was just to uh see what applications what servers it could be disabled on and then do that and move to Karos. Right. Thank you. Absolutely not. Uh nothing with Microsoft fortunately is that simple or logical or easy. So I don't know how it works in other people's environments but in this one you could see where the connection was going to

but you couldn't see. So you could see that, let me backtrack. You could see the connection being made from the client. So you could see that someone was trying to authenticate, but you couldn't see where they were going. And that why behind those connections was exactly what we needed to find out what could be safely disabled, what could safely use KROS, and what couldn't. So I, you know, all of these go through a domain controller. So you see one part of the connection and then where it goes after the authentication just kind of disappears into the ether. And I dived into a rabbit hole trying to figure out what was on the other side of

that connection. And it is genuinely disappointing to say that I never reached the bottom because I really wanted to make a tool or find a method or do something that would simplify this for other people facing the same problem. Uh it was really frustrating and I tried honestly I tried everything I could think of. Uh I looked at loon ids but those always changed as soon as the you know new authentication session had been started. Uh I couldn't use process ids because the NLM SSP process was always handling authentications. Um we didn't collect client side logs so I looked on those can't see where they're going either. Uh looked on server application logs. Those weren't even

populated. They weren't enabled or being connected. So, I looked everywhere that I could think of. I tried network sniffing. That didn't really show me anything. And there were a few things I could kind of figure out and sort of guess where they were going, but I needed something that would verify with certainty at scale. I did not come up with that. It's really likely that I missed something or I made a mistake somewhere. Um, if anyone here is able to point that out, please tell me and I'll be genuinely happy to know because I really wanted to solve this problem. Um, and I, you know, I would have been happy to dig for hours or days working on

this. I like understanding why things work and why they don't. I get a lot of satisfaction out of fixing them. But I did not have hours or days to keep digging. This was not my only project. This was not my only responsibility. I still had to answer tickets, you know, do investigations for legal. I still had to do incident response. I still had to do all of these other things with various degrees of urgency. And the IT guy that was the only other person on the ground with me doing this was in exactly the same position. So neither of us had sufficient time and attention and resources to properly take care of this. But do you know why I had to go down

such a rabbit hole? You don't have to answer that. Um, I'll answer it for you. Microsoft does not tell you what uses NLM. Nowhere. They give a few estimates, but nowhere is there a list or a catalog of every Windows utility and function that is dependent on NLM one or two or LM. Like it's it doesn't exist. Um, and some of you might be wondering at this point if we reached out to Microsoft support. And if you have done that, I smell smoke, so I'm just going to take that out. Um, if you have ever worked with Microsoft support, you know that we did do that over many months. Absolutely made no progress. we would keep getting the

same, I don't know, copy pasted troubleshooting answers to questions that weren't being answered. There was things we had already tried that didn't solve the problem and then they would close the ticket saying like the problem was resolved and it absolutely was not resolved. And at this point, despite not being a CIS admin, I knew more about NLM than any support specialist we got. So, it was increasingly frustrating. And then they like they started doing this other thing which I am still very resentful about. Um when you log a Microsoft support ticket, you get the option to choose how you'd like to be contacted either by phone or by email. I personally have the attention span of an

overly caffeinated squirrel. I need everything in writing. Everything has to have a paper trail. I never choose by phone. I always choose by email. So what would they do? They would call, they would let the phone ring once, they'd hang up, and then they'd close the ticket saying I was unavailable. I really I need a therapist, I think. Like, that messed me up. But anyways, we were we were getting nowhere fast. And this was the point where I gave up. I went to management. I told them everything that I had tried. I told them everything I had managed to not really achieve. Uh but we did give them what we did know, gave them an estimate for what

we didn't know and uh I proposed a very conservative plan to very gradually start rolling out this disablement of the protocol and they accepted. So we got to work. It was very exciting and you know as always we started with a small group of pilot IT workstations in our IT team and we disabled LM NLM1 and NLM 2 and everything started breaking because apparently despite Microsoft telling you that everything can work with Care Bose that isn't true. If you have any of these in your environment, turning off NLM will cause them to fail. Do you know a business that can survive without all of these things? I was waiting for a no, but that also

works. No, absolutely not. and some, not all of these can be reconfigured to use Karos. Is this a straightforward process? No. Does it always work? Also no. The thing about Kerros is that it needs to have a direct So as a a client you need to have a direct line of sight to a domain controller. If for whatever reason you don't have that, you can't authenticate. So for example, if you are using a VPN or a proxy server, you can't use Karos. Uh or I don't know if your DNS is having issues because that never happens. Uh and it starts using IP addresses instead of domain names, you also can't use Karos. It will automatically fall back to NLM1.

So that's not very helpful of Microsoft, is it? But anyways, uh realized we had to compromise. Uh maybe it was not going to be possible to get rid of NLM2 everywhere, but certainly we could do that with LM and NLM1. We had identified some exceptions. Um you know, those crusty Windows 2003 servers that I mentioned earlier. Uh but everything else, you know, was probably going to be probably going to be fine. So we started and it worked like we were getting some kind of progress. So the way that you actually disable the protocol is in the is using a registry key kind of linked to a group policy. So this is the LM compatibility level. It's the registry

values that you have and we were dramatic moment here at level zero and we needed to be here at level five. So what you do is you gradually increase the level from one to the other. And we started with clients. Everything seemed to be going fine. People were having some printer issues, but that is business as usual. Uh and after we were done with clients, we did this region by region. We did lots of communication to IT teams, to some end users. Uh so everybody was aware and we had no major incidents here. So then we moved on to servers and there we had some more difficulties. Um this is also where I learned about

the Dutch expression peep test which is where you make a change you don't tell anyone about it and then you just wait for people to complain and the American version of peep test is scream test which I think says something about our cultural differences. Um so yeah at the end of the PEEP test we found a list about of yeah 10 exceptions or or so uh that could not use anything but what they were using. So we segregated them. We moved on. It was fine. And at the end you know throughout this whole process we had been monitoring our seam to see if um and NLM1 connections were happening and they weren't. And that meant we had finally

gotten rid of them. like we had disabled LM and NLM1 and it felt [ __ ] amazing like you could smell the light at the end of the tunnel. So we like we were you know it was very exciting. We had finally made progress. I you know young naive person I had made progress on a project no one else had been able to to fix so far. So I was quite chuffed and um yeah we did this with servers we did this with clients we gradually moved up from LM NLM1 uh and NLM2 for rest of the things that could do it and the last step was just to to move the LM compatibility level for domain

controllers. So it wasn't being used in the environment anyway like we had verified that. So it really like it was really just you know dotting the eyes, crossing the tees. Uh it was really the last step we you know we could consider that we were done. All we needed to do was was change that last setting just for domain controllers. And then I went on vacation which in hindsight was pretty dumb. Um but I thought again I thought it had been fine for a period. There had been no incidents. I had done all the communication I could think of. I had um you know put in roll back plans and procedures again for things that I could

think of. Doing some heavy foreshadowing here. Uh and I I handed everything off to my IT colleague. I left my phone in a drawer or on my desk of my home in Amsterdam and then I flew to Canada wearing a USA hat and uh this was when the whole company shut down. That's a marmet by the way.

Now, I didn't know about this at the time because again, I left my workphone in another country, but something happened between the Wednesday the change was supposed to happen and the following start of the week that logged out every employee out of their device. To this day, no one knows exactly what happened, but a mistake was made. So uh instead of you know moving the level for domain controllers from four to five the maximum just one step what happened was the level for clients went from five to zero and the LM compatibility level for domain controllers went from four to five. Can anyone see a problem with this? So suddenly clients were exclusively authenticating using the only protocols that domain

controllers explicitly forbade. But nobody knew about this because there was no communication about when the change was actually made. So they thought it was a cyber attack. And after I don't know like almost 24 hours of incident response and handling and digging it was my IT colleague sorry my security colleague who saved the day. Uh because at this point you could not log in to a single endpoint. No enduser workstations, no servers, no domain controllers. So you had no idea what was happening. No error message, no triage, no nothing. But our EDR was still working. So he used that, not an IT tool, a cyber security tool to go digging in the domain controller logs

and the authentication logs. This time there were no 4624s. There were only 4625s. um and he saw a weird line that said something about you know NLM and he had a thought that maybe this was related to my project. So uh with the you know live response tool he logged into all the domain controllers and at the instruction of management moved the level from five down to three. So the incident was resolved I think like less than 24 hours later somewhere around 4 in the morning. Um incident was resolved. Everyone was happy. However, the Oh, I missed the best slide. My bad. But however, the initial goal had not been solved because when a domain

controller is down to level three, it means they accept NLM 2, NLM 1 and LM. So we had ended up back at square one except now even though I pinky promised this would never happen again, we had identified the root cause of the issue. Uh nobody wanted to take the last step. because I shut down the whole company which fair but you know it was it was unfortunate but I I learned some things from this experience. I think the most obvious one is that you should not go on vacation at the same time you have a major change happening. I was young and naive. Please learn from me. Um, I should have, you know, moved one or the

other to make sure I was fully available for this happening. Um, because if I were there, we would have have more, you know, more cohesion, as I mentioned earlier, more communication. I could have prepped way more communication as well. Uh, I did not tell nearly enough people that this thing was happening. Um but another another surprising thing I realized was that you know we had all this like change management software but that didn't prevent this from happening. So clearly there was a disconnect between the internal bureaucracy and how people actually behave. I don't know if anyone else has ever experienced this. Um, but I also realized how important it is to be kind because my IT colleague who

made the error was ruthlessly mobbed and bullied both by colleagues and by management. Um, but nobody died. Like the company went down for a day. That is very inconvenient. I'm sure that had a business impact, but nobody died. Nobody was physically harmed or injured. Uh I don't think anyone was permanently traumatized except maybe me and my IT colleague. Um but I don't think you know the stock prices didn't fall, the company didn't disintegrate. Nobody's end user devices exploded. Uh it was very inconvenient. I don't think any of that is worth being an [ __ ] about. And the thing is that you will always have human error in systems where there are humans. the fact that a simple

mistake caused such a wide outage. I personally, you know, I take responsibility for my mistakes. Um, but I don't think that is a responsibility of the individual. I think that's a failure of the organization because you should not have that amount of power with that little kind of oversight and tracking at the same time. But what about Microsoft? Where have they been in this whole situation? They they made this insecure protocol. They put it into absolutely everything and then they told us to stop using it without providing any tools or adequate communication to actually do that. Even like Microsoft's own support specialists couldn't help us do the thing they were telling us to do. How how do you work with that then? How

do you how do you move forward? How do you succeed? I'm not a business person. I don't know what goes on behind the scenes. I'm an ops gal. But it sure looks like to me that Microsoft created this huge problematic dependency and is now pulling the plug and making it the end user's responsibility to fix it. I personally am not happy with that. I was not happy about it then. I'm not chuffed about it now. And I'm not the only one. Uh, this is from their official Reddit post, which is an interesting form of communication, but this is their post in the CISA admin subreddit. Uh, any frequent flyers here? CISA admin or other way around. I'm dyslexic. But

anyway, I'm not the only one who feels this way. Here was someone who also felt under supported. Uh, here was somebody else who is also like me. they were overwhelmed. They were struggling. They didn't have enough time or resources to do all of this. Um, this is someone who had the same documentation issue that I did, uh, where you just you can't find anything. And then there's this guy who is clearly not at his first rodeo. So, it was not a fun experience. It was educational, but it wasn't fun. And I'm not just trying to bash Microsoft here, although they do make it very easy to do that. Um, I think this is common of all

squillion dollar companies that they put their things into everything. They close source, they make you dependent, they make interoperability impossible or difficult or prohibitively expensive. Then on the other hand, businesses see it and security as a cost, not as the thing that allows them to survive. And that results in IT teams being underfunded and understaffed. It results in defenders being defunded and defanged. And it also results in attackers having more and more access with uh fewer and fewer consequences it seems like too. So this problem is beyond a single protocol, company or organization. And that kind of creates a chicken and egg problem because when you continue to produce, to develop, and to sell insecure products, you're not actually

encouraging anybody to move past them. Microsoft has been maintaining backwards compatibility because if they don't, the world breaks. But that doesn't help security, does it? When you have things leave left open, when you have things lowhanging fruit, very easy to uh crack, very easy to man in the middle, very easy to pass the hash. not just NLM, it's tons of other protocols that are vulnerable to these kinds of things that are used everywhere. So, um, nonetheless, in the grand scheme of things, despite the fact that they didn't provide adequate communication or infrastructure, in my opinion, to uh safely help people when they pull the plug, I do think this is a big step in favor of security. Um I'm sure that we

will see more of this happening. Uh so be prepared, right? Uh take into account the fact that you have aging devices or aging systems or aging protocols in your environment. Uh think about the future. Think about when when there are no tools, when there is no one to help, when access suddenly gets cut off. For example, with NLM, uh, NLM one has already been removed entirely from Windows 11. So, it's not even a feature in there anymore. And in future Windows Servers editions, uh, NLM 2 will also be completely removed. So, those will be fully Cararos only. Again, I'm not sure how they're going to go about that. Um, you know, unfortunately, NLM is not

truly going anywhere. And I think that's kind of I think that's kind of the problem is that we're in a situation a little bit that we can't really get out of on a large scale. Um but yeah on that happy note if any of you wants to try this at home I have compiled a list of sources that tell you how to understand how to identify how to abuse and how to remove NLM protocol family from your organization. I also have some examples of actual hacks due to NTLM that have happened in companies in case you need some tangible examples to bring to your management as evidence that hey this is an actual risk. This is not theoretical. This

actually happens. And if any of you want to commiserate uh or complain or share you know Microsoft trauma stories, please add me on LinkedIn or please find me on the floor afterwards. I'm here for the rest of the conference and I want to thank you very much for your attention and I will leave it there and anyone can talk to me anyone can message me anytime I can share any sources I don't bite unless you work for Microsoft thank

Oh, I see some questions. Great great presentation and kudos for the the management. Uh I didn't catch where the clients stopped using uh or dropped back to to the zero level and started only using NLM. >> Yes. So what happened was instead of so the the clients were at level five so they had stopped using LM and NLM1 and they were using Karos whenever possible and occasionally falling back to NLM 2 and the domain controllers were at level four. So they were uh still accepting LM sorry they were still accepting NTLM1 uh and instead of going to just five um they went to yeah they went to five while the LM compatibility level for the clients got changed. So that

should have stayed the same. It should have just been the domain controllers going up. So the clients were already at five. Sorry I'm explaining this very badly. Um they got put down to zero by accident. And then the domain controllers were at five. After the incident was handled, they were down to three. And the client stayed at level zero. So they were using everything. And the domain controllers were allowing everything. >> Okay. So the clients should have should have also been uh pulled into the five. Is that it? >> Well, they should have stayed at the five. Yeah. Okay. So we had taken care of clients. We had taken care of servers. Everyone was only at five and

then that got bumped down. >> All right, great takeaways here. Thanks.

It didn't want to let me move forward. Okay, I guess this also just first plays. There you go. Anyone else?

Cool. Well, I am around and I am perpetually online. So, uh, thank you very much for your attention.