 All right. Hi everyone and thanks for coming to our talk. Relay in credentials has never been easier. How to easily bypass the latest NTLM relay mitigations. I'm Marina Simacov. I'm Yaron Zinner. We're both security researchers from preempt and today we want to talk to you about some of the vulnerabilities that we were able to discover this year. So we have a lot of ground to cover. Let's see the agenda for this talk. We'll begin with a short introduction to Active Directory. We'll see some common attacks and we'll focus a lot on the NTLM protocol. We'll see its design weaknesses, the NTLM relay attack and some of the, bless you, and some of the offered mitigations that we have against NTLM relay attack. Then we'll move on to talk about some of the vulnerabilities. We'll see some known vulnerabilities against this attack and then we'll see the new vulnerabilities that we discovered this year, allowing us to bypass all the mitigations against NTLM relay. We'll also show you how NTLM can be used in order to attack ADFS servers and we'll present something new that we like to call reverse care roasting and finish with some takeaways. I guess most of you are familiar with Active Directory but I'll give just a brief overview just in case. Active Directory is the main secret storage of the domain. It stores the password hashes of all the accounts and it's in charge of authenticating accounts against domain resources. This can be done using three different protocols, LDAP, NTLM or Kerberos and today we'll focus on NTLM, the NTLM protocol and the NTLM relay attack. So you might be scratching your heads thinking is NTLM even still relevant? And even though we've had Kerberos for quite a while now we haven't been able to see a single environment which doesn't, which disables NTLM entirely so if attackers can use it they can attack you using it and we'll tell you, we'll show you the vulnerabilities that we were able to find. So it's quite relevant. Now let's see the flow of this protocol. Let's say we have some user that wants to authenticate against some domain server. Let's see how the authentication process would work. The client would send an NTLM negotiate message to the server. The server would respond with a challenge and now the client would need to encrypt the challenge using the password hash of the user's account and send it back to the server in the NTLM authenticate message. Now since the server does not store the password hashes of the users it cannot validate that the challenge was encrypted using the correct password hash. So that's where the domain controller comes in. The server would send a net logon request to the domain controller with the challenge and the response and the domain controller would validate whether it was encrypted using the expected password hash and respond with an approve or reject response accordingly. One of the problems with this protocol is that the NTLM protocol is not bound to the target server. So if the server in the middle gets compromised it can relay the NTLM authentication in order to establish a connection against another server. This is exactly what happens in the NTLM really attack. Let's see the flow of this attack. We'll have a client connect to a compromised server using an NTLM negotiate message. So this can be done by attackers compromising server which users constantly connect to or by sending a phishing email to the user when the user clicks on the link an NTLM authentication is initiated. Now attackers would choose a target in the domain which they want to relay the credentials to and relay the NTLM negotiate to the target. Receive a challenge, relay it back to the client machine. The client would now encrypt the challenge using the required password hash, send it back to the compromised server and now all the attackers need to do is simply relay that last message back to the attack target and since the challenge was encrypted using the correct password hash the domain controller would approve the request and now attackers have an authenticated session against that attack target. So notice that at any stage the attackers did not have knowledge of the password hash of the user. All they did was relay messages back and forth between the client and the server and if that authenticated user is a local admin on the target machine attackers can now remotely execute code on that machine, dump files or entirely compromise their computers. This is a pretty serious attack vector. So let's see some of the mitigations that we have against this attack. So the two most critical mitigations that we have are session signing, we have SMB and LDAP signing and also we have EPA and channel binding which we'll be focusing on today and we'll show you how we're able to bypass both those mitigations. Okay let's give a brief overview of what each mitigation means. The session signing means that after the NTLM authentication is completed all the communication between the client and the server would need to be signed. Now the signing key would be derived from the authenticating user's password hash. So since the client has this password hash it will simply calculate it by itself and the server does not have the password hash so it will be getting the signing key from the domain controller in the NetLogOn response. Now if we have a relayer in the middle it will simply have no way to retrieve the signing key. It would not be able to send any signed packets to the attack target and the attack would fail. This is a very important mitigation. However unfortunately not enough servers enforce session signing by default today. Okay so let's see the flow of this mitigation will have a client connecting to a compromised server. Attackers would relay the NTLM negotiation challenge and response and then the attack target would send the NetLogOn message to the domain controller. It would also receive that session signing key. And also the client would calculate the signing key by itself so both the client and the attack target have the signing key. However the compromised server in the middle has no way to retrieve that key. It cannot send any signed packets to the target and the attack fails. Alright second mitigation that we want to discuss with you today is EPA enhanced protection for authentication. And here the goal is to protect NTLM authentications from being relayed over a TLS session. So the goal is to buy the NTLM authentication to the TLS session over which the authentication occurs. And the implementation is done by adding an additional field to the last NTLM authenticate message called channel binding. This field is based on the hash of the target service certificate. So if you have a relayer in the middle it would be using a different certificate than the attack target and the value provided by the client in the channel binding field would be based on the certificate of the compromised server. So if an attacker tries to relay that message to another target the attack would simply fail because of an incorrect channel binding field. Okay let's clarify this with an example. Again we'll have a client connecting using a TLS to a compromised server and initiating an NTLM authentication. Now attackers would target a server which enforces EPA and establish a TLS session relay that NTLM negotiate message, get a challenge relayed back to the client and here's the difference. Now when the client responds with an NTLM authenticate message the message would also include this channel binding field which would be based on the target certificate of the compromised server. So if attackers now try to relay this message back to the attack target the attack target is using a different certificate and the channel binding field would not be valid. So the attack would fail and the attack target would not need to verify the credentials against the domain controller. Okay so we've seen some of the mitigations let's now discuss some of the vulnerabilities we'll show you some old vulnerabilities which were previously discovered and then we'll show you how we bypassed all the mitigations that I've just presented. Thanks Marina for that great introduction. Offer the ears many vulnerabilities were found that allowed attackers to launch successful NTLM relay attacks allow review of few of them. So the first vulnerability I want to talk about is LDAP S relay. That vulnerability was discovered by our team in 2017. So as Marina mentioned NTLM is not protected by default from NTLM relay. To protect a specific application you'll need to either enable server signing or EPA. For LDAP servers on the domain controllers there is a GPO for enabling LDAP server signing. When that GPO is enabled the LDAP server would accept LDAP requests that are signed but also it would accept any LDAP request over TLS. This is sometimes referred to as LDAP S. This means that LDAP servers were completely vulnerable to NTLM relay over LDAP S. We have disclosed this vulnerability to Microsoft two years ago and they fixed it by enabling EPA on LDAP S sessions. It is important to note that LDAP is still vulnerable by default since the GPO is not enabled by default and EPA is not enabled by default on LDAP S sessions. The next vulnerability I want to discuss was disclosed in 2017 by Core Security by Alberto Solino. This is a generic bypass of NTLM server signing. So the attack begins like a normal NTLM relay attack. The attack target generates an NT a net logon message and receives a session key in the response. Since it enforces SMB signing we cannot launch an attack without having the session key. But as it turned out any machine in the network that knew the challenge and the challenge response could simply spoof a net logon message and receive the same session key. Once the attacker has a session key he can simply send any SMB packet that he'd like. So Microsoft fixed that vulnerability and the fix is a bit more complex so I'm going to dive deep into NTLM to explain all the details. The first part I want to explain is the NTLM challenge message. In the NTLM challenge message there's a target info field. This field contains constructs named AVPERS that identify the target. One of these fields is the net bios computer name identifying the net bios of the target NTLM machine. In the example you see you see the name test-01. When this message is received by the NTLM client the NTLM client will echo all the AVPERS fields that it received. You can see that it echoed the name test-01. But the important part is that when he signs the message the anti-proof STR signs all the AVPERS. This means that an attacker cannot modify or temper with any of the AVPERS and needs to relay them directly. So what was the fix that Microsoft applied? Microsoft simply compared the net bios computer name to the net logon originator. Since it's a bit complex let's review the flow. So again we have a normal NTLM relay attack. The attack target which is the legitimate target of the NTLM session sends a net logon message and receives a session key. Now the session will also send a spoofed net logon message. The DC would compare the net logon originator which is the compromised server and the AVPERS that identifies the attack target as the original target. See the discrepancy and simply reject the request. Since no session key was presented the attacker cannot use the SMB session that he just established. Okay that's it for the old vulnerabilities. Now let's move on to the new vulnerabilities we have discovered. Overall I plan to present, we plan to present three new vulnerabilities. The first your session key is my session key is another generic bypass for SMB and all NTLM server signing requirements. The second drop the meek is another vulnerability bypassing another NTLM mechanism the message integrity code or meek which we will explain later. And the third bypassing EPA. That's correct during our research we have bypassed all NTLM mitigations. Let's deep dive into the first vulnerability. So if you recall the fix I just explained for the 2015 vulnerability was for the DC to verify that the net bios name or in the end net logon message is the same as the net logon originator. We've asked ourselves what if we'll simply remove the net bios name from the AVPERS. So in the NTLM challenge message there's an AVPERS for the net bios computer name and we're the relayer we have full control over that packet. So we'll simply remove that field. Okay what happens if we remove this field? Now there's a series of surprising things. First the NTLM client receives the NTLM challenge message respects it even though it's malformed and generates an NTLM authenticate message. This NTLM authenticate message would have no net bios computer name since we haven't given no net bios computer name. The second surprising thing is that the NTLM server would accept this malformed NTLM authenticate message and would generate a net logon message and now for the third surprising thing the DC would also respect this rogue net logon session and would give a session key. Now once it gives a session key anyone can send this net logon message since it can't be authenticated whatsoever. So there is one last obstacle we need to overcome and that's the MIC. The MIC is a message integrity code that sign all three NTLM messages. They negotiate, challenge and authenticate. The MIC is there to protect from any tampering that is done to any of the NTLM messages. But wait we did tamper with the NTLM messages specifically with the NTLM challenge. But if you'll see the session key for the MIC is the same session key for the SMB signing. So what are we going to do? We're simply going to recalculate the MIC and send the NTLM authenticate message to the server. Let's review the flow. So once the attacker receives an NTLM challenge message it would tamper with this message sending a new NTLM message with no net bios computer name. The client machine would respect this message sending an NTLM authenticate message also with no net bios computer name. Now we'll spoof a net logon message. The DC cannot verify that this is the correct origin and we'll send back a session key. Now that we have a session key we can recalculate the MIC forward the new tampered NTLM authenticate message. The attack target would send a similar net logon message and we'll receive a session key. Now both sides have the same session key and SMB session is established and the attack can work. So I just want to emphasize one last thing. SMB signing is the only mitigation for domain controllers. This means if we're in possession of a privileged account NTLM session we can relay that session to a domain controller and establish SMB or RPC sessions. This means we can dump any credential in the domain or execute code remotely on the DC. This is a pretty serious attack. Now let's see a demo of the attack. In the demo we have two machines. One of the machines is a browser running a privileged account session and the second is the compromised server. Okay. That's strange. Let's try. Okay so first three. First we run the attack. That's why we made the video. Yeah. Yeah. No one said that hacking is easy. Okay. So the first the first time we run the attack without our exploit and the attack fails. If we look at the packet we see that the NTLM authenticate message contains a net bios computer name. So we can't spoof the net logon message and the session is not signed. You can see that the signature field is zeroed. This is why the server rejects the domain controller rejects our SMB packets. Now let's try running the same attack with our exploit. Okay so you can see two new fields. One is the computer's account hash. We need this to spoof the net logon message and the second field is the removed target removing the net bios computer name from the NTLM challenge message. So you can see that now the attack worked. We were able to retrieve a session signing key and we were able to dump hashes from the remote machine. Let's look at the network traffic to see what just happened. So okay the first NTLM challenge message as a net bios computer name. When we relayed it to the HTTP session there's no net bios computer name. The NTLM also doesn't have a net bios computer name. The net logon message is not present because it's encrypted. But you can see that we've retrieved a session signing key and the session is signed. Okay now I need to open the slide deck again. Okay so just to summarize with our exploit any machine in the network can get an NTLM session key and sign SMB sessions to remote machine. Okay we have disclosed this issue to Microsoft and they've issued a patch back in June. The patch works by giving NTLM servers the option to validate if the NTLM authenticate message. If the NTLM authenticate message contains no net bios computer name the server will simply reject the NTLM authenticate message. This works in general but there are some few caveats we want to mention. The first is that NTLM v1 does not have AV pairs. This means that the attack we've just presented will always work in NTLM v1 and it is unmitigated. The second is that sense patch is not applied directly on the domain controllers but on target servers. Older Windows versions and non mean Windows OS are still vulnerable. And the third maybe a little tidbit is that since again it's not applied directly on the DC any machine that even if it's patched was not restarted is still vulnerable. And in a domain with thousands of computers surely some are not restarted and are still vulnerable. With that I'm going to pass the stage back to Marina to present the two additional vulnerabilities. Yeah it's actually we'll be presenting three more so bear with us. The second one is drop the mic the message integrity code. So as Yaron mentioned the message integrity code is calculated by applying an HMAC MD5 using the session signing key on the three NTLM messages. And the goal is to make sure that attackers didn't tamper with any of the NTLM messages. Now let's see an example of why we might need this mic field in the message. Let's say we have a client sending an NTLM negotiate message to the compromise to some compromise server in the environment. And let's assume that this client supports signing and it sets the negotiate sign flag in the last NTLM in the first sorry NTLM negotiate message as you can see in this packet. Now if attackers try to relay this message to a target server that supports signing all they would get is a signed session with no way to retrieve the session key. Let's assume that all the servers are patched and attackers cannot retrieve the session key. So it's not possible what attackers however might try to do is simply to remove the signing flag from the message. In order to establish a non-signed session against that target. However this would not be possible because if attackers remove even a single bit from one of the three NTLM messages the mic would be no longer valid and the attack would fail. We have SMB clients that turn on this negotiate flag this negotiate signing flag by default and also use a mic. And this is why it was considered very hard or even impossible to perform NTLM relay from SMB to other protocols simply because the session would need to be signed. However other protocols don't set the signing flag such as HTTP so much easier to relay NTLM from HTTP to another protocol. Let's say we're persistent and we want to remove this signing negotiation flag from an SMB authentication. How can we do this? We've seen a way that we can modify the message integrity code but in order to modify it we need to have possession of the session signing key. Let's assume we don't have a way to do this. Well it turns out we can simply remove the mic from the message. We've actually talked to the few people yesterday that tried doing that but it's not enough to just remove the mic from the message. We also needed to remove the version field and change some of the negotiation fields. But at the end it was as easy as removing the mic entirely in order to bypass its protection. And the way we discovered it was quite funny because we were working on a completely unrelated vulnerability and the mic was interfering from what we were trying to achieve. So then we removed the mic from the message and continued to working on that other vulnerability. And at the end we had to look back and think wait do we need to disclose this one as well? Did we just find another problem? And turned out that we have. So by removing the mic attackers can tamper with any of the NTLM messages. Here you can see an example we have an original NTLM authenticate message which has the mic field and the version and our tampered authenticate message without those fields. Okay so let's see the flow of this attack. We have a client sending an NTLM negotiate packet to a compromise server stating that it supports signing. Now relays cannot relay this message as is to an attack target because they would not have a way to retrieve the signing key. So what they can do is simply remove the signing flag from the message and relay it back to the attack target. They would then receive a challenge and if the attack target does not enforce signing it would return a challenge and state that no signing was negotiated for the session. Now attackers can relay this back to the client and usually clients don't enforce session signing so they would accept it and send an NTLM authenticate message signing the required challenge and also adding a message integrity code to the message. However the message integrity code signs the messages between the client and the server. And the NTLM negotiate message that was signed was the one that states that it supports signing but attackers tampered with this message so they cannot relay the SMIC to the attack target. So they simply remove it in order to bypass its protection. Now the domain controller verifies the credentials, sends an approved response and attackers have established a non-signed session against the attack target. Let's see why this is even possible. Turns out there is an AV pair called flags inside the last NTLM authenticate message and if the second bit of this attribute, this flag's attribute is set it means that the client is providing a MIC in the authenticate message. However it doesn't matter what this flag states because the attack target upon receiving such a message doesn't validate that a MIC is present even if this flag is set. And this is exactly what allowed us to bypass this mitigation. So no one actually does the verification that if a client states that it provides a MIC, that it indeed provided a MIC. So we just dropped it from the message. Okay, let's discuss the fix. Now that we know what the flags attribute does, we know how to easily fix the issue. All Microsoft needed to do is for servers to verify that if they receive a flag's value which indicates that a MIC is present, just verify that a MIC is present. Some issues with this because some clients don't add a MIC by default and also, sorry, don't add a MIC such as Firefox on Linux machine or Mac OS machines. So those clients would still be vulnerable to NTLM session tampering. So attackers can still remove the sign in negotiation for such a client. But the more serious issue is they were able to bypass this mitigation and we have vulnerability that we like to call drop the MIC too. However, Microsoft hasn't patched this issue yet. So we'll have a blog coming about this in a couple of days. Alright, the next bypass that we want to talk to you about is the EPA bypass. So the goal of EPA is to bind the authentication, the NTLM authentication to the TLS session over which it is established. And some of the service that can be protected by EPA include ADFS servers, OA servers, LDPAS on domain controllers, or other HTTP servers which support Windows integrated authentication. Unfortunately, by default, none of those servers enforce EPA. So all of those would be vulnerable to the simplest NTLM relay attack. So attackers wouldn't even need to bypass the protection of the EPA. However, let's assume we have a very safe environment and EPA was enforced on all those servers. How can we bypass this feature as well? So the implementation of EPA is by adding an additional field to the last NTLM authenticate message which is called channel bindings. And this field, as I've mentioned, is based on the target servers certificate. And since attackers would be using a different certificate, they would not be able to relay this message to another target which enforces EPA. What they might try to do is maybe modify this field. However, that would not be possible because this field is also signed using the user's password hash. So attackers have no knowledge of that hash and they would not be able to modify this field. So we cannot tamper with the NTLM authenticate message. Let's see what we can do. Let's look at the NTLM challenge message. We know that when a client receives an NTLM challenge, it echoes the fields in that message and puts them inside the NTLM authenticate. So what happens if we compute the channel binding required in order to bypass EPA in advance? It is based on public values of the certificate and inject it into the NTLM challenge. What would the client do? Okay, so what the client would do is put our rogue channel binding field into the NTLM authenticate message. So we have a rogue channel binding inside the message signed using the user's password hash. In addition, the client would add an additional channel binding which would be set to all zeros. The only question left is what will the server do when receiving a message that has two different channel binding fields? Well, it turns out that it will only take the first one. And the first one is the one that we calculated in advance in order to fit what the server expects. So we're able to bypass EPA because the server simply takes the value that we computed in advance. So the last obstacle that we might have here is the message integrity code. So what happens is that we just modify the challenge message and the message integrity code is no longer valid. However, we already know what to do with the MIC. We simply remove it from the message. Let's see the entire attack flow because it was quite complicated. So we have a client sending an NTLM negotiate message to a compromised server and attackers now establish a TLS session against an attack target which enforces EPA and relay that NTLM negotiate message to the attack target. The target would send us an NTLM challenge message. We will compute the required channel binding field that is needed in order to bypass EPA on that server and inject it inside the NTLM challenge message. The client would respond with an NTLM authenticate message with the injected channel binding and an additional one which the server would ignore and also adds a MIC. We cannot relay this MIC because we modified the challenge so we just remove it from the message and we have our injected channel binding. The attack target checks the field, sees that it is compatible to what it's expecting and we're able to bypass the EPA feature. Okay, so now attackers can compromise that server which can be an ADFS and OWA or even a domain controller using LDS. Okay, so let's see a demo of this attack. Sorry guys for some reason the video is not working from inside the presentation. Okay, so what we'll show you now is that we'll have our HTTP relay server and when a client would connect to this relay server we would relay the authentication to a domain controller which enforces LDS channel binding. We'll show you the first attack which would fail without our vulnerability and in the second one we'll be adding our rogue channel binding and removing the MIC and we'll show you how we're able to escalate the privileges of a user to an enterprise admin by reeling the credentials of a privileged account. Okay, so first of all we run the HTTP server without our vulnerability and the let's connect to our rogue HTTP server and we can see in the console that the attack failed. We're trying to reconnect back to the target all the time and we fail. You can see that in the challenge we don't have any channel binding field. However, in the authentication the client sends this field to zeros and this is the one that we relay back to the domain controller. So we can see the channel binding is set to zero and this is not what the domain controller is expecting for the LDS channel binding so the attack simply fails. Okay, so we'll try to run it again with two additional fields. First of all we'll be removing the message integrity code and second is we'll be adding our rogue channel binding to the message. Let's see what happens when we run out vulnerability now. Okay, so we're connecting using our HTTP client to our rogue server and you can see in the console that first of all the authentication was successful and then that we were also able to escalate the privileges of a test user to an enterprise admins group. Let's see what happened in the network traffic. We can see that the original challenge didn't have any channel binding field inside but the one that we sent to the HTTP client does have one and this is the one that we calculated in advance. Now when the client responds to our message we see our rogue channel binding and an additional one set to all zeros. Okay, so now we need to relay this back to the domain controller. You can see this is the field we injected and this is the all zeros one and also there is no mick in the message, however the original message did contain a mick. And now the domain controller simply accepts our authentication. We're able to escalate the privileges of that test user to an enterprise admins simply by relaying the credentials and bypassing EPA by injecting our rogue channel binding and then removing the message integrity code. Oh, now it's working. Great. Okay, so that was the channel binding bypass. Let's discuss the fix. So the fix is pretty simple and it is based on, it's based on detecting a signature of this attack. So if a server receives an anti-LM authenticate message with two channel binding fields it would simply deny their request. Still have some issues with this as well because some clients don't support EPA and also don't add a mick. So those are the same ones that I've discussed in the previous vulnerability. Those would still be, would still be vulnerable to the EPA bypass. So attackers would still be able to inject a malicious channel binding. The client doesn't support EPA so it would not add an additional field and attackers can relay that to any target which enforces EPA. Okay, so our last vulnerability today would be how we can use anti-LM in order to attack ADFS servers as well. Thanks Marina. So we have discussed a couple of anti-LM relay vulnerabilities but anti-LM has other issues except anti-LM. First, if an attacker has possession of an anti-LM session he can use that session to do offline cracking of the user's password. Apart from that, using anti-LM, attackers can brute force or do perform credential spraying and password brute force attacks. We'll now discuss how we can leverage these features to attack the ADFS server. First, let's understand what the ADFS server is. ADFS is a server that allows users to perform claim-based web authentication using their domain credentials. The server allows users to use Windows integrated authentication as well as simple form-based authentication. ADFS supports both SAML and WFS Federation protocol. So in many cases you want to allow users to authenticate from external networks like the internet. Two common examples are OWA which is a popular Microsoft mail server and Office 365. A lot of networks don't want to sync their passwords to the cloud so they're using ADFS to authenticate Office 365. So since ADFS is a very critical server usually it is not open to external networks and typically you deploy an ADFS proxy that ADFS proxy receives the authentication requests and forwards them to the ADFS. Now I want to talk about our NTLM password brute force work and then we'll return to ADFS. So this time the rogue machine is the client machine and not the server machine. And if we want to brute force some user account we'll generate an NTLM authenticate message. This message could be over any protocol that supports NTLM. If we're dealing with insider threats this would probably be SMB since SMB is open on all machines in the network. But if it's an external attacker working from the internet for example SMB usually doesn't pass the firewall so it would be another protocol. For ADFS it would be HTTP. So if the packet is received by the server it would send an NTLM challenge message. This message will use our guest password and encrypt an NTLM authenticate message. The server would send it a net log on to the DC and if the password is rejected we know it's a wrong password and if it's accepted we've locked out and we've able to crack an account. The really cool thing is that in NTLM you can spoof the origin name. So if we look at it from the DC perspective the DC logs don't contain any IP of the attacker or the correct machine name. So if we'll analyze this log we'll have a hard time figuring out the attack origin. If we'll go back to ADFS and we've said that ADFS is open to the internet an attacker that has no physical access to our network can connect to ADFS and perform brute force attempts either with NTLM or with a form based authentication. So this is a pretty serious attack and it can have two consequences. If our network has account lockout policy if our network doesn't have account lockout policy at some point the attack would succeed some password will be guessed, accounts will be compromised and eventually data will be leaked. If our network does have account lockout policy it doesn't get that much better since now the attacker can de-dose our network with no physical access and lock all the user accounts. Microsoft is aware of this issue and they have an extranet lockout policy. When the extranet lockout policy is enabled the ADFS after a few authentication failures stop respecting authentication attempts that originating from external networks. So now let's move on to the vulnerabilities we have discovered. So as it turned out you could do windows integrated authentications from external networks to ADFS. This is a bit surprising but that's not it. We've found that if you use a Windows integrated authentication and specifically NTLM the extranet lockout policy is simply ignored. This means that we were able to bypass the extranet lockout policy entirely. We have disclosed this issue to Microsoft and they've issued a fix back in July. Now I want to, before I explain the fix I want to add one last note and this is about Kerberos. Sorry not all the talk is about NTLM. So we've asked the reason that the vulnerability worked is because the ADFS accepts Windows integrated authentication from external networks and we've asked ourselves can we also exploit this issue with Kerberos. And the answer was yes. So since our time is short I'll be brief and I'll mention that with Kerberos we can brute force only the ADFS service account. This is done by forging service tickets using guest password issues. We call this technique reverse Kerberos thing. This is a small attack surface but it has a huge impact. If we'll be able to crack the ADFS service account we can create any silver ticket and authenticate as any user to the ADFS completely compromising the ADFS infrastructure. It took us a while but we've convinced Microsoft that the correct fix was to simply block Windows integrated authentication from external networks and that's what they did. So what are the takeaways we think you should take from this lecture? First obviously patch all your machines. Second we recommend that you not use NTLM at all since it's very risky but if you use NTLM make sure all your servers are enforcing server signing and EPA. Third if you're using NTLM V1 please stop. It was already published it was already published that any NTLM V1 session can be correct since it's using weak desk encryption. We have now shown that any NTLM V1 session on fully patched machines can be relayed. Seriously just stop using NTLM V1. Some credits are in due. Ayal, Karnian, Segi, Sheinfeld from our team have also contributed to this research and Alberto Solino helped us integrate our code into IM packet. IM packet is an awesome tool that we use all the time and all the demos you've seen today were using IM packet. Okay so we recommend you stop using NTLM but if you do use if you can't resist we hope after this talk you won't get relayed. Thanks.