NTLM Reflection Is Dead, Long Live...: Story Of An Accidental Windows RCE

Hi everyone, thank you for listening to our talk. Today we'll talk about NLM reflection attack, a story of an accidental Windows RC. My name is Wilfred. I'm with my colleague Guom. We both work at Sactive and we're doing pentest and red team assessments. So let's talk about the vulnerability. A vulnerability came out this year in June with a CVS score of 8.8 and was classified by Microsoft for a Windows SMB client elevation of privilege vulnerability. We kind of disagree. We mostly think this is a remote command execution. Actually, this vulnerability is a trivial logical vulnerability that can be performed by authenticated users. It involves authentication reflection attacks and it only works on machine that does not requires SMB signing. So

basically every Windows version except the latest one. The venity was so trivial to discover and to exploit that it was found by at least seven people or companies within a short period of time. Shout out to Red Team Pentesting that was the first to discover and report to Microsoft. I'm also wondering how many people discover it and exploit it by accident without realizing it was a bug. You will see why why right after. Few words regarding our re research motivation. We already know that there's a lot of bugs related to reflection attacks. For instance, there was a searcher mentioning that cabus relay is way more powerful than NM relay and he show specific case targeting ADCS

environment last year in black black Asia. NLM reflection attacks also have a lot of bugs. The first one came out in 2008, then 2009, 2015, 2019 and since then we thought reflection attacks were no longer a thing. and we'll see that it was not the case. So before digging into the vulnerability, I will give you some core concept so everyone is on the same level in in order to understand. The first core concept will be authentication coercion. Authentication coercion was is when you force an identity, it can be a user or machine account to authenticate to a control server. There are several way to coersse a machine into authenticate to a given servers. Some are dataistic, some are

not. The most popular one is to force an to call an RPC service in order to access a file that points to an arbitary file share. So we can illustrate that on the top we have our target machine and on the bottom we have the attacker laptop. So first we perform that RPC call. There's few function that can be that allow us to perform the coercion. One of the most well known is EFS RPC encrypt files SRV. But what is important here is to notice there's a UNC path convention which spawns to a remote location here the attacker IP the machine will the FCC service on the machine will then talk to the SMB client

saying that okay you need to access this specific remote file. So the SMB client will perform an SMB connection to attacker laptop. The attacker laptop will host a SMB server and try to perform the authentication workflow. So it will ask please authenticate to us. The authentication offer will then go on and we receive an authentication blob. This is authentication coercion. Another concept will be authentication relay. Authentication relay is then when you force a client to authenticate to a control destination that was the coercion and then you relay the authentication to another server. Here for instance on the attacker we force the authentication coion on the machine A. We receive the authentication blob and then we we relay this authentication

blob to another machine here on service on the service on machine B. This way we are not authenticated as the client from machine A on the service on machine B. Another concept will be authentication reflection. Basically is the same. This is a special case where the client and the server are on the same machine. We receive the incomingation blob and they read back to the same to the same target. Microsoft describe describes it as a bug. So mitigation were in place in order to prevent reing back to the same theation to the same machine. That was the reflection attacks. Last concept will be carbos authentication coercion. We know that NLM relay is quite easy to perform but

actually for cabus it's more complicated. There's more requirements. The main difficulty is to receive the authentication blog. So the cabio authentication which stands for an AP rake message cab is using ticket with service principle name or SPN with the following format the CIFS/ SRV1 for instance SPN is constructed by the client based on the server host name of fully qualified domain name and the server host name or FQDN is resolved through DNS which is not on control. So if you want to illustrate that again with from the attacker laptop we try to perform coercion using the carbo protocol using the host name here SRV1. Then the the our target SRV1 will ask to the DNSer what is the associated IP

address. It needs to perform DNS resolution. Now you know how DNS works. the the DNS will now answer back to the client with the corre the associated IP and because this IP is only is it own will not receive any incoming authentication and we do not receive an APC message. So we thought at the start that ketoification question was not possible until a well-known security researcher James for discovered that a marshall credential target information structure can be added to the end of a SPN. Elsas during the authentication process will discard it before making the carbos ticket request. So actually when you request a ticket for CIFS/ SRV1 following by the specific B 6 B 64 encoded string it will actually

returns SPN for CIFS/SRV1 and that specific B 64 encoded structure is the Marshall credential target information and what is interesting also we know that KBOS is working with DNS and that specific record is a valid DNS record. So how we can exploit that for carbur authentication coion first we register that specific DNS record. What is interesting in it's that in active directory environments any authenticated user can create this specific record. We force we the machine into authenticate to that record. It will point to our attacker IP using the SMB protocol and then we will receive an APC message for the SPN that we want. So again we can illustrate that with the same scenario. First we'll add the DNS record SRV1

following by the Marshall target information structure. It will point to our attacker IP. Then we perform the authentication question using that specific crafted DNS record. Again the machine will ask to the DNS server what is the associated IP address. The DNS server will answer with the attacker IP and then we will receive the incoming authentication with an AP rack for the SPN that we want. This is how Cabrio's authentication question works. Okay. So now we have you have the concepts we can talk a bit more into the finality discovery. So at the start we were performing some cab research during reflection attacks and we know that some check and protection against reflection attack may be based on names. So we try to fiddle

with the target name during coercion and something interesting happened when we try to perform coercion to that specific DNS record using the the Marshall target information structure on the top. I'll do I'll perform the correction using pipotam with a low privilege user and that specific uh DNS record and at the start I'm trying to perform carros relay reflection attack. So I'm using the dedicated tool from impact which is an offensive python suit. So carrier relays.py Hi. And when performing the correction and receiving the AP rack to my control server, I received this this weird error message unsupported make type NLM SSP. I was quite confused because I'm not trying to perform any NLM authentication. I'm only

using host name or fully qualified domain name. And basically most of the time Windows prefer kios authentication over NLM. So I was quite surprised and I say okay if Windows wants to perform NLM authentication we can do that I can use the dedicated tool from impact that perform NLM relay which is called NLM rigs.py. So I do the same on the top I'm performing the correction which is the same command and on the bottom I start nlm.py Py targeting the same server and to my surprise the authentication first succeed and also it give us a privilege SMB session here by default NTM RX dumps the local SA some high hashes so I was quite confused I say okay

something is going weird is going on reflection attack are patch this this should not be working I know there's some specific registry keys that can allow this specific behavior but it was not the In my lab, the solution key was not set. So at first I I thought there was something not going on well in my lab. So I as to another colleague, I say, "Okay, I have this strange behavior. Can you test on your own lab?" At first he was thinking I was bluffing, he say, "No, this can be real." And before before telling me I was bluffing, he tried on his own. He say, "Okay, what the [ __ ] What is going on? It works."

And we were privileged. So basically this is how we discover the vulnerability by accident by performing researches but we cannot let the things like that we have to understand why does it works what is the root cause. So during the during the performing the analysis I want to perform first a network analysis and perform network diffing. So on the left I will do the same attack but instead of using the specific crafted DNS record I will use the the IP address of my attacker of my attacker laptop. So basically I'm trying to perform reflection attack but using my own IP on the right it will be using that specific DNS record that makes the attack work. And during the the NLM

exchange on the NLM SSP challenge part we we can notice two differences. On the left we can see there there's some specific flag that is not set. It's a bit small but you will it doesn't matter much. And on the right you will see also that specific flag using when using the specific DNS record it will be set. Also on the left when we are performing using the IP address we can see that field called reserved which is empty and on the right this field is not empty anymore. It has a value. So basically what's going on on the left we are performing standard NLM authentication and on the right we are performing local NLM authentication the flag what that

was set on the right is stands for local authentication so we have to understand what is local NLM authentication local NLM authentication will happen when we everything is going on the same machine so first the client will perform initial security context text it will discuss with Elsas and the dedicated provider here NLM SSP the the authentication workflow will start the NLM SSP will answer back to the client it will start the NLM exchange by performing the NLM negotiate message and then the client will forward this message to the service moving on the service will now discuss again with the LM SSP always within the same machine and it will perform accept security context during the NM negotiate

message and within the memory of the NLM SSP it will create a new context within a local context list it will create a new structure with a specific identifier for instance here 10,02 moving on we continue the the NLM authentication workflow the NTM SSP will now answer the NLM challenge back to the service and we think this challenge it will specify the context ID and then the service will forward the npm challenge back to the client again with that specific context ID and this is what we could see in wireshark we could see that specific context ID in the reserve field also it will set the flag for local authentication moving on during the moving on on the

authentication process now the client will perform initial security context when receiving the nm challenge change because now it have the context ID it can it can within the memory of the NLM SSP he can have his token handle to that specific structure. So now within the memory of the NLM SSP on that specific context ID we have the token associate associated to the client. Next we'll finish the last part of the NLM authentication. NTM SSP will now send back the NM authenticate back to the client. Basically, this message is almost empty because there's no need to compute the challenge since we are performing local authentication and then the client will send back the enticate to the service.

The last part will be the service discussing with NLM SSP. It will perform accept security context and it will still use the same context ID. And now because the service can find this specific context ID, the authentication will succeed and it will use the token handle associated to by the assetated to the client that was provided previously. So when we are performing performing networking, we can see that we are relaying a local NLM authentication over the network. But why does the server decide to perform local authentication? I will let go explain that. So to actually understand why the servers decide to perform local authentication, it's actually important to understand what happens when the SMB client um wants to authenticate to the

the DNS record with the B 64 Marshall the credential information. So first of all it will build an SPN of the form CIFS/ the DNS record the DNS record. It will uh try to initialize a security context which will actually be a call to the device driver KCD. The call will be routed to LSA SRV and then uh the magic will happen here via a call to LSAP check Marshall target info which will actually um check inside the SPN if there is a Marshal credential information and if yes it will strip it off the SPN. So afterward the uh context initialization will be routed to the correct SSP in this case NLM and the uh

SPN will just be CIFS/sv1. Another thing to understand is what we call NLM local authentication hinting. Basically, when the NLM client builds the first message to authenticate, it can decide whether or not to hint the server into performing local authentication. So the decision process is what you see now on the screen and I will illustrate it with a few examples. So the first example is if you try to curse a machine by giving it an IP address as the target. The SPN that will be constructed will be CIFS/ the IP address. Um via call to SPR get target host name the the service class will be stripped off. You'll be only left with the host part. In this

case it's the IP address. And now it will go through a series of checks. The first one being is the target either the host name, the FQDN, fully qualified domain name or the string local host. In this case, it's false because it's um the attacker IP address. The second check will be is the target one of the local IP address of the machine. It's also false. So the conclusion for this scenario will be to not hint the server into performing local authentication. But if you take another example, let's say you curse a machine into authenticated with the DNS record with credential marshall target information. As we saw earlier, the B 64 data will be stripped of the SPN and we'll be only

left with CIFS/sv1. the host part will be um extracted from the SPN. So we are only left with a surv one. And now we'll go through the same series of checks. So is the target either the host name of the machine the FQDN or the string local host? In this case it is SRV1 is the host name of the machine. So we'll go to the right. Are we requesting a null session? We are not. Did we provide explicit credentials? No, because we are using Windows implicit authentication. So the conclusion is to hint the server into performing local authentication. So depending on how you curse the machine, you'll get different behavior from the ENTM client. So the next uh

thing to explain is what actually is local authentication hinting. It's quite easy to spot if you do a little bit of network diffing again. Um so on the left uh the client does not hint um uh local authentication and on the right it does. Basically the only thing that changes is that the two fields calling workstation domain and calling workstation name are null on the left and are um filled with correct values on the right. So local authentication hinting is just including the the machine information inside the first NLM message and when the server receive this message it will parse these two values and will decide or not to perform local authentication. So to sum it up a bit

first Elsas discard the credential target information of the targets. So, SRV1 plus B 64 data just becomes SRV1. The NLM SSP client identifies that SRV1 is the local machine. So, it will hint the server into performing local authentication. And the NLM SSP server um retrieve these values, compares it with its own values and decides to ask the NLM client in the third message to perform local authentication. There is just one last question for NLM is why uh do we get a privilege SMB session? Well, it's kind of easy with uh what we just explained. The antilum client runs in the system process with run which runs as anti- authority system which mean that when the service will

try to impersonate the client it will impersonate the token of anti- authority system which will give us administrator access on the the target. So to illustrate it we've prepared a small video to um show you how easy the vulnerability is to exploit. On the top left, uh, we'll start our re our relay server. When it receives the connection, it will actually upload a binary and run it via the service manager. On the bottom, we start a reverse shell listener. And on the uh top right, we'll prepare our authentication corion with speam. You'll see that we use a low privilege user account and um that we caress uh the machine into authenticated to the record with the B 64 data.

So um we'll uh trigger the correction we'll receive the an authentication on the top left you'll see that uh the relay succeed um which will upload a binary and run it via service manager and on the bottom you see that we get a system shell on the machine that we cored which is workstation one. So that's it for NLM, but we also wanted to know if it would work on Kerbros and actually the answer is yes. Uh the vulnerability also affects Kerros. The only thing to keep in mind is that your relay server must not advertise NTLM when you receive the first SMB connection because uh there is a specific case for the the negotiate SSP

which the SMB client uses which will prefer NLM over Karos only in the case of local authentication. So um what does it look first for KROS? First you qu the machine into authenticated to the um B 64 DNS record. The machine forges an AP rack and send it to you. You take the AP rack, you forward it to the SMB service and you get a privilege session. Um two things to note the SMB client runs as NC authority system as I said. So every network authentication that will be done will be done as the machine account. a serve $1. So we are actually relaying the machine account. If you know a bit about machine accounts in

active directory domains, you'll notice that something is weird. The machine account is not privileged on its associated machine. So that's a bit weird that we um actually received a privilege SMB session. To understand it um we must do a little bit of reverse engineering of the Kerros SSP which I will explain uh now. So when the ker when the SMB client wants to uh authenticate v via keraros it will use initialize security context to contact the kerros SSP which will create what's called a sub key entry. It will uh which contains various information about the client. It will generate a random sub key and it will also store the token handle of the client. It will then include this entry

into a subkey entry list which is a global list that the KROS SSP maintains. It will forge an AP include the previously generated sub key inside and send it to the client. The client will forward the the AP rack to the service and the service will u validate the AP um by asking the Kerros SSP. The kerros SSP will decrypt the AP rack and compares the sub key with all the entries in the subkey list. If it finds an entry with a matching sub key, it will consider that the identity of the client is pointed by the token handle uh that was stored. So whenever the service will try to impersonate the clients, it will impersonate the token handle that

was stored uh in the sub key entry which explains why we get a system uh session. The last part of this talk will be um about the patch. So when Microsoft issued the patch, we were curious um about how they fixed it. Did they issue a patch for each protocol? Did it manage to do something global? to know where to look. Uh we remember that in the official advisory uh the vulnerability was labeled as Windows SMB client elevation of privilege vulnerability which means that the fix should be in the SMB client which is partly implemented in MRX SMB. We did a bit of patch defing and it was quite easy because only one function change which is SMB CE create SRV call

which is called when trying to access a resource over SMB. The check is actually quite simple. It will um parse the target and if it contains a Marshall credential target information, it would just abort the connection. So you cannot um coers a machine with this kind of record anymore. That's how they fix the vulnerability. And finally to conclude by doing this research and this presentation we wanted to highlight that high impact simple and stable logical vulnerabilities still exist in Windows. In our opinion um mitigation such as SMB signing are still underrated. In this very specific exploitation scenario, it would have blocked the vulnerability, but um it is still not enabled by default on Windows except Windows 11.

So now that this vulnerability is fixed, is it the end of authentication reflection vulnerabilities? Well, as you may have guessed, the answer is no. But that will be for another talk maybe. Thank you for listening.

THANK you very much for that very interesting story. Very enlightening. Do we have questions from the room? We have time for one question. Yep, we do. So, we do have a cube. Maybe somebody can get that so everybody can hear you clearly as well. Thank you very much. So since they only fixed the coercing part, would this attack still work if I control the DNS entry for the target system? >> You could um if you can control the DNS uh you could um uh trigger curros authentication. The thing is um later uh in the year so I I think it was uh in October Microsoft issued another patch for a different vulnerability using a partial control over SPN which is kind

of an equivalent to controlling uh DNS. And now um if you receive a local authentication from an IP address that is not um a local IP address the SMB server will just deny the connection. So, it would have worked um before October, but now it doesn't. >> Thank you, CO. >> Awesome. Thank you very much. So, in case you have further questions, because I'm pretty sure you do, I think you two can be found outside in front of the room. So, catch them, get a chance. And for now, before we head into a short break, it's just 10 minutes. So, we'll go to Munich in like 16:40 the next talk starts. But before that, let's give

another huge round of applause here. Thank you.