 Hey everybody. Welcome to our talk, Adventures in Meetemland, using Meetem to attack active directory authentication schemes. So, first, let me introduce us. I'm Yaron, manager on the engineering team at CrowdStrike. I've presented two times before at Blackhead and one time at DEF CON, did a lot of research on authentication protocols, a YAL, an engineer previously presented on Blackhead, and SEGI also an engineer with extensive background as a security researcher on many organizations. So, what is this talk about? So, this talk is about an extensive research that we did to see what we can achieve if we have a machine in the middle. So, a machine in the middle is a technique that has a lot of potential, one slide back, so that has a lot of potential. So, if you're at a pentest or an attack and you reach a point where you have no credentials and no zero days, sometimes a man in the middle is a great technique to move laterally inside a subnet. And our area of focus for this research was active directory and active directory has very old protocols. And by default, most of the protocols don't use TLS but rely on Windows authentication. So, let's begin with a short introduction to Kerberos and NTLM, which are the AD authentication protocols. So, in NTLM, a client machine wants to authenticate to a server, so it sends an NTLM negotiate request. The server creates nones and sends it in a challenge request. And the client machine signs the nones with the user's password. The server does not know how to validate the user password. So, over the NetLogan channel, it sends the NTLM authenticate message. And the this either approves or rejects the user authentication by validating the user password. Now, onto Kerberos. So, with Kerberos, the client machine first logs, the user first logs in. And in order to log in, the client machine sends an AS request, which for that it gets back TGT, a ticket granting ticket. Now, using that ticket granting ticket, the machine requests a TGS rack, which is a ticket granting service. And the DC gets a ticket, the ticket granting service is signed with the server's password, not the user's password. And now, when the client machine connects to the server, over any channel, the channel can be SMB or LDAP or HTTP. It will send a Kerberos message, which is called AP request, and would send the TGS, the ticket granting service. One more click. And the server is able to authenticate the tickets and the service ticket is signed with the server's password. So, as you can see, Kerberos offers a lot more security than NTLM. There's plenty of material online for any of the attacks or issues that I've mentioned here. One most critical issue with NTLM is that NTLM allows for NTLM relay, which is also a short introduction. So, with NTLM relay, the setting is that the client wants to connect to a server. The server is compromised and the attacker on the server wants to use the credentials from the client machine to attack another target, another server. So, it relays the negotiate message to the server and to the attack target. The attack target sends the challenge back with a nonce. This is relayed to the client machine back. The client machine signs the nonce with the user secret. The server relays that NTLM authenticate message. The attack target would validate it over the network on channel and the DC would approve it since it's the user's correct secret. And the attack would succeed. So, there's plenty of network and plenty of research on NTLM relay. One talk you might want to review is a talk in DEF CON I did with Marina Simakov in 2019, which really dives deep into NTLM relay internals. And with that, I'll pass the stage to Yal. As Yaron mentioned, NTLM relay only works if the server does not enforce a signable encryption on the target. Sylvan found that one could authenticate to a certain RPC interface the task schedule and it does not enforce signing on the graphic. It's even written in the specs. So, using the classical technique of NTLM relay, one could relay the authentication to the server and afterwards send an unsigned packet that would cause it to run an arbitrary task. This would result effectively in a remote code execution vulnerability. What allowed this attack is the way that RPC handles security. The level of security in RPC session is determined by the authentication level of it. Some RPC servers require packet privacy. That means required that the session would be encrypted while other only require packet integrity that is signing. The authentication requirement is determined on an interface by interface basis. In fact, the registration API requires the caller to set up a special function to check for security requirements for an advocate authentication level. It does not rely as one would expect on the SMB signing settings on other secure default. You see, when an interface allows for a packet for authentication level of connect, it would be vulnerable to NTLM relay anywhere on any computer, even on a DC. The question is, does this interface has a potential security impact? And indeed, while most of the interfaces implemented by Microsoft in Windows are protected, there might be some instances where the developer neglected this thing. So now we switch to a very different vulnerability and we'll see how it is related. And one of the recent vulnerabilities involving print spoiler, one should say one of the many, many recent vulnerabilities of print spoiler was discovered by Pele, Gada, and Tomer Bar. And in this vulnerability, you exploit a lack of access check in order to achieve writing arbitrary files in the system. So how does it work? To print something, one needs to specify which printer, printing driver and by which part it communicates with the printer. The current implementation allows for any user to install a print driver, a printer driver, and also, of course, the print. So the simplest driver there is is called a generic text driver that simply passes the input it gets into the port. Well, the port could be something like COM1 or COM2 where the printer is connected to, it can also be a file. And this means that the user can call this simple printer to print to a file it wants. But what makes all of this a vulnerability is that the access checks were done from a certain execution path, but it was on the client side. So all of this allows effectively a local privilege escalation in which an unprivileged user can write a file, a file to an important location that doesn't have privileges to do so. So instead of relying on the document, okay, now we switch to our contribution. And instead of relying on the documentation of the RPC interfaces like Pellegr Tomer B, we develop a small scanning tool to allow us to find additional vulnerable interfaces. One of the results was the print-polar interface. And we know from previous slides that a print-polar interface could allow one to write arbitrary files. Even after it is fixed, one could write files if it has sufficient privilege. So we can combine both vulnerabilities or both our insight into a working gecko. So notice that the setting of the previous vulnerability 1048 are local unprivileged users, but we start from a setting of remote privileged users that contact a certain server and we relay this request, whatever the request is, to another server using MTL-MVLA. Then what we execute on the target server is similar to what happened in the original vulnerability. So let's see how it's done. First, we have an authentication request by the client machine that is passed to a work server. And now we create a channel with the target server with the attacker and we bind to the print-polar interface. We relay the authentication and get a challenge that we relate to the client back. And the client sends us the response to the challenge. We relate back to the decision. So now it has an authenticated session that is valid and we can send commands without encryption to this session. Now we first install a printer driver. Then we do all the things that you need. We add a form to install a printer and we start to write to a file and that is it. Now we can see the demo. Okay, so what happens here is that we first use a metasploit. We use here a endpoint mapping query and we list all the different RPC interface that we see on the remote computer. This remote computer is a DC and we see here we have many interfaces. Some of them are local RPC and others are remote. And now we just reformat the output so it will match a script that we are about to run. And what this script will do is it will try to try different interfaces, the same that we found earlier and it will send a it will connect, send a garbage packet. And using this packet we can know, okay, we can know if it's vulnerable. Now you see we found the printer's print spooler interface there and the error code is unsupported and we have another interface with error of bad stuff data. The error of bad stuff data means that the server handled this garbage and it understand that it's garbage and so it rejects it. The unsupported error on the other end is simply inconclusive and it actually requires an additional that we send an additional object ID for it to work. So once we did that we found that the print spooler is indeed vulnerable and now I can show you the second demo which is how to do MTLM relay to the print spooler and write a file. We do it against the DC and we see here that we first open our menu in the middle server and the client access share point it types the its username and password and we will shortly see that in the target computer a file is being written. So we write a file to the sysvol volume which would be present on any computer on the network. So this would allow one to take over the domain and now I pass, now followed me is Sagi and he will discuss his vulnerability. So actually Yaron is speaking now. So now I want to highlight another vulnerability that was not discovered by us that was discovered on 2015 by Luke Jennings and Luke Jennings essentially research the GPO retrieval process and wondered what would happen if I meet him would attack that scenario and he actually found many attacks that can be done. One attack is actually still exploitable which is that if you have a low privileged user and a medium you could manipulate the GPO using the credentials and inject a malicious GPO. The other one is an attack that requires only meet him and uses MTLM and in that attack which Microsoft actually fixed is an attack that we want to focus on since we've improved this attack and found new avenues to attack it. So if we have a client machine and the client machine wishes to download GPOs it would perform an added bind and then if the GPO retrieval is authenticated with MTLM and MTLM negotiate message would appear and since we're intercepting this request instead of the DC we will send an MTLM challenge request and would name the target name as the rogue server. The client machine does not authenticate or validate the MTLM challenge and even though the machine initially connected the DC it doesn't reject the requests where the MTLM challenge names another machine as the target and just send an MTLM authenticate message with the rogue server name. Now our machine can in its own network on challenge send the MTLM authenticate and the DC would respect this request since the target of the request is reported to be our rogue server and the DC would send us back a reply and the reply would have the session key. So now we have a session key and we can send an accept complete signaling the client it can send requests over the LDAP channel and even though the request might be signed or sealed even if the requests are signed or sealed they are signed and sealed with the session key that we know and we can send back any malicious response that we like. In the original vulnerability the response was a redirect stating that the GPOs are at some malicious UNC that's on our control. Now this exact attack can happen on LDAP as we displayed but you can let the LDAP be relayed to the DC without any manipulation and then when the client machine downloads using SMB the GPO files themselves we can do the same technique over SMB. So ours Microsoft fixed that issue so now the default is that group policy objects cannot be downloaded using NTLM and there's a new registry key for that and for the SMB case Microsoft even went deeper they've added a new configuration called hardened UNC paths and that configuration basically forces Kerberos authentication and not NTLM for any UNC over SMB that is on a file on some regexes. The default for this configuration is that there's a sysvol regex and a net logon regex and this actually stops any chance of intervening with the group policy download process and with that I'll pass the stage back to Eyal who's going to present our new attacks. Thank you Eyal. So now we will discuss the Azure AD Connect and the Azure AD Connect is part of the vision of the Microsoft of CMOS sign-on. So in this perspective where I use that that is connected to the web can use its internal compute company credentials to access some external resources like Office 365 or some internal application without meeting VPN. So how does it work? It works by synchronizing the important Active Directory data to the cloud with the help of a special server that is called AD Connect Server. The server connects to a domain controller, replicates the password and other data and then it's exported hash to the Azure Active Directory. However, one needs to make sure that it is actually talking to the right domain controller. For instance, you could do it by picking the protocol that supports mutual authentication and certainly not working in NPLM. So what happens there is that a traffic that means to the original DC might end up in a work server and the things would work just fine as Eyal demonstrated. So what we need to assume for this attack to work is a full menu in the middle, including BNS, Kerberos, DCRPC and then we first make Kerberos fail and allowing LDAP to pass to the DC. We relate to the actual DC and we wait for a domain replication. When it appears, we inject a new chain that involves a new password for an account of our choice and afterwards it syncs with the Azure AD and we can login into Azure AD with the injected password. So let's see the demo. Okay, so what happens here is we have a first we want to change the password into NPLM injection. Now we see that the password of this user ekTest is now not NPLM injection but other password and we have two windows here. One, the first one contains a modified version of Mimiket. In this modified version, we specified the target user and the password that we want and the other window is doing simply forwarding LDAP traffic to the DC and now I adjusted the speed of the demo so we can we can see what happened. The interesting part and it took around a minute or two minutes until we get to it and then now we got to it and we see that it pulled our fake change and we can now login and with our new password hopefully it will work. Let's see. Okay, so it doesn't work. Try again. It still doesn't work. Yeah, it sometimes takes time for the synchronization to occur and we see that it got the sign on request okay and we have access to office. So now we can look at the traffic itself and we can see the buying packet which is directed to our ROG server that is that for workstation 01 and indeed that is the response that it returns and we can also see the LDAP buying packet that are all returned from the DC itself and you can see it here. So that really concludes the demo. Thanks a lot and now Sagi will continue. Now let's talk a bit about Kerlos relay. It's basically the same scenario as the entry learn just with Kerlos. So a client wants to connect to some service in the target server and the start of that it sends an AP request. The attacker intercepts that AP request using some written technique and uses it to establish a session of its own against the target server with the client's credential. Since the AP request is valid and was actually intended for the target server it will work. This will of course this will work only if the signing and encryption flags are not turned off inside the AP request or the protocol the attacker chooses supports turning those off as part of the protocol negotiation. Also this works against more services since most of them do not validate the service principle name and any STN can be used. Let's see a specific example using SMB relay. An attacker will intercept some AP request that was made to a target server and then establish a new SMB session of its own against the same target server while negotiating signing and encryption off. Then uses the same AP request intercepted to authenticate in that SMB session and basically get an SMB session with the client's credentials. And of course this will as I said work only if the target server does not enforce the signing and encryption. And as you can understand the solution for this problem, for the KELOS relay problem is turning on as I said signing or encryption which is done in the protocol level and uses a shared circuit that is negotiated inside the AP request response process. Okay so encryption in the protocol level solves the relay problem but what happens when we use a TLS challenge? Since the encryption is done in the transport layer there is no connection to the underlying authentication in the protocol and we get a new relay problem. So this is where EPA comes into play. Using EPA we cover the authentication process to the TLS challenge using the certificate funding that was presented during the TLS challenge negotiation. The funding is inserted inside the checksum field of the AP request authenticator and servers that support EPA use that field to validate that the certificate hash that was presented during the TLS negotiation is in fact their own and if not they reject this connection. EPA is used in many important services like LDAP, ADSS and the IS and it usually requires full enforcement. It requires some settings to be turned on and usually they are not on by default. So can we bypass EPA? Of course for an example of an NTLM bypass, again check out your own and Marina's talk from DEF CON 19 and as for KELOS let's see what happens when we don't include the checksum field inside the AP request. So here's an example of LDAPS pickup, of course it's decrypted so that's why you see the traffic. Here we took a regular AP request that was generated by a Windows client and we tried to relay it inside the LDAPS session and to authenticate with it to the DC. The DC is set to fully enforce EPA and as you can see the Windows client included a zero out hash in the checksum field and the DC verified the hash. Obviously it's not its own hash so the DC rejected the connection. Now in this pickup which is also an LDAPS decrypted the network traffic, we relayed an AP request that was generated by IOM packet which by default does not include the checksum field. We relayed it to the same DC that is set to enforce EPA and as you can see since the checksum field is not there the DC approved the connection and answered our LDAPS search. And obviously for that attack scenario to work we need to find a vulnerable client in the network that does not include the checksum field inside the authenticate. Now let's talk about KDC spoofing. It's a very old technique that usually used to bypass authentication server. So the basic scenario goes like this. A user authenticates to server using plaintext credentials of course usually over some encrypted channel like SSH or HTTPS. The server takes that credentials and using it it creates an AP request and attacker intercepts that AP request and returns a fake TGT, a fake ticket and now the server has no ability to validate that TGT and since it got one it just approved the connection of the user and the user is locked on. Now let's see how the this problem was solved. We begin with the same basic scenario. A user authenticates to the server with plaintext credentials and AP request is generated. DC returns a valid TGT and as I said the server has no ability to validate that ticket. At this part the server uses the the TGT to ask for a service ticket to itself. The DC approves the request and returns the TGS that is intended to the server and with that the server decrypts the TGS, validates that his own secret secret was actually used to decrypt to sign the ticket and thus it can validate that the DC is a is a genuine DC. Now let's see how it looks in the traffic. Here in this scenario a user locked on to workstation and AP request an AS request was generated the DC returned the TGT and then that workstation used that TGT to ask for a service ticket to itself in this case with the host SPN. Usually in this scenario the host SPN will be used. So we can't manipulate TGS and TGT so what can we do? Let's look at the DC selection process. In this process the machine does some unsecured queries using mostly LDAP and DNS also some CLDAP until it gets enough information and can decide what DC is best for it. As I said until this stage all queries are done unsecured and can be temporary. Now at this point a standard Windows client will create a network on channel against the chosen DC and send some messages over it. This step is the most important one since the creation of a network on channel actually validates the DC since for establishing the channel the target server must know the client machine feature. So if this channel was established correctly and at least one message passed it means that the target server is a genuine DC. So what does it mean? It means that as long as the target server or service does not validate the DC using a network on or other means it means we can interject in the process and inject a whole DC of our own and then serve data to the target data like LDAP, SMB or DCR to see traffic. Let's see the attack scenario. A client machine boots up and wants to select a DC. As I said we can intervene in the process since it's done totally unsecured and we inject our own work DC. Now as long as the target server or service does not validate the DC when a user logs in the same process we discussed earlier begins the machine creates an else request. We take this as request related to the DC and relate back the response. Now the verification of the DC by the host request to the machine begins. Again we relay this message to the DC and the response back to the client and since this actual DC serves those requests the machine gets a valid ticket and it pulls the user forward again. Now at this stage usually machines or servers will actually want to know more details about the user such as display and group memberships, profile paths and other data. So usually an LDAP session will be initiated. This session is of course established against the DC which in this case is our work DC. So a service ticket to the work DC will be asked. We will relay this request to the DC and return back a genuine TGS for the work DC. At this point since TGS is used the target for it is our work DC we can serve any protocol such as LDAP, SNB or DCRPC signed or encrypted. So let's say in this scenario the machine will initiate an LDAP search we will approve it and get return responses with malicious data such as wrong group memberships or malicious profile paths and any other example. So what do we need for that attack scenario? We need a service that uses kernels that ingest data from the DC that does not have a fixed DC configuration and of course we need a meeting between that server and the DC and we need that service to not validate the DC using network or other needs. The attack for the attack it serves we using medium we redirect the traffic to our work DC and every time the client wants to query the DC queries us and we can inject any data we want. For this to work we need to for our work DC to have registered SPNs like LDAP or some other stuff who might need. Okay so how can we protect against this attack? We should only use servers and services that use a wider network line to validate the DC or use LDAPS with a certificate validation. It is also possible to turn on Kermos armoring though we haven't tested it fully so we can vouch for that and as a side note Windows GPO is still safe since the Windows GPO client only pulls GPO after there is a valid network on session against the target DC. If there is not one the GPO client will not pull any GPO. Now we wanted to show you demos of this attack but unfortunately the vendors we worked with weren't able to fully fix the problem yet and so statement for updates and as a side note this particular problem is pretty common in Linux client and basically any non-windows native clients. So let's get back to Yaron. Okay so we have shown you basically four issues an NTLM relay and NTLM injection and a Kerberos relay and a Kerberos injection for the NTLM relay and Microsoft has fixed the issue that we've reported we've also noted that there might be other open interfaces and Microsoft actually asked for any interface we found it to be exploitable to report separately and we've not had the proper time to investigate each interface. For the Azure AD Microsoft actually says that metam is basically not a security boundary and I can actually understand the point since Azure AD sits in the data center and the DC should also sit in the data center so that connection should probably be more secure but if this connection is not secure on your network you should probably have it secured. For the channel bindings issue the Kerberos over TLS or Microsoft has chosen not to fix this issue and for the Kerberos injection as Segi mentioned that issue is probably very widespread and we've notified a few vendors and you can expect updates soon. So closing remarks so when we started this research we weren't sure if how seriously what our metam vulnerability is being taken and we can see that in some cases metam is not considered a security vulnerability or a security boundary I'm sorry and like technically what we shown you is that Kerberos is not validating this identity properly if not using NetLogon which is not always the case and GSS API encryption simply does not guarantee privacy in NTLM that's by design and in Kerberos if no NetLogon is performed and basically just protecting protocols for metam is hard you need to carefully validate that any parties are completely authenticated and when you're using external libraries and protocols that's not always easy to ascertain so a couple of tips for defenders so obviously you should harden your networks enable server signing and client signing when server signing and client signing are not enabled or not enforced then a lot easier attacks a lot simpler attacks are able to be achieved you should regularly patch your software and you should treat critical servers like Azure AD connect the same way you would the DC the connection should probably be secured maybe it should be over secure sockets for the Kerberos injection basically what Sagi showed is that in order to launch the attack then you need to register the LDAP SPN on a machine that is not a DC so this is something you can hunt for to look for a successful attacks or attack attempts and jokes aside avoid the Microsoft recommendation that you should not be metam so metam is a technique that often can be mitigated by properly configuring your network equipment you need to turn on mitigations for ARP spoofing for DHCP spoofing for Slack these are mitigations that are known to work well so there's plenty of resources out there on how to protect yourself from metams you need to patch your network equipment and that's it thanks for listening to our talk we hope you enjoyed it