 Thank you, everybody. Excuse the profanities in advance. And let's get started. So the title of my talk is spooky authentication at the distance, I don't care about your passwords. So let's start about me. I have a day job and a night job. I'm working in two shifts. A day job is at a company called Seconds Alt. We are mostly prevalent in Europe and Asia. Not much here in the States. And I am from the Swiss division. So I'm working at Switzerland. My night job, I run under the alias of Skelsack. I am an open source developer. I have a lot of open source tools created over the years and published mostly under MIT license. And I'm a proud member of Porcetta Industries or Porcetta Industries for some of the audiences. And we have an awesome logo over there. So the biggest project maybe that you might have heard of is PyPyCats. Anybody has heard of PyPyCats? Anybody is using it? Nice. Thank you. Thank you. And also I have a tendency of rewriting libraries for my own abusement. So AIO SMB is basically in packet, rewritten from scratch. MSLDAP is like my own LDAP library and I have like Kerberos, NTLM, SSH, whatever. I'm a big fan of networking protocols, if one can tell. And yeah, all of these are open source except for Octopon. Octopon is a special project. And actually while developing Octopon, I started looking a bit into like nested things that one can do with Windows integrated authentication. And hence this talk was born. Yeah, also I like to just go and ramble about everything. So I have a promise for you today or this afternoon. In this presentation, you will see a novel technique that will allow you to basically if you manage to execute code in a user context of machine A, then from machine B, which is like your machine, the attacker machine, you will be able to perform authentication in the context of user A, but from your own target machine. This means that it will basically the code, like the attacking code itself is going to be executed on your machine and hopefully you haven't installed XDR or AV or whatever on your machine because why would you? This will allow you to, if you manage to sufficiently hide the proxy binary and I will give you some hints on how you can do that. It's a really small proxy binary. Then you're basically golden because you usually don't really necessarily care about the initial point of compromise. So like you don't really care about like what is on the HR machine or the HR lady who double-clicked on the spam that you crafted. You are mostly caring about like what is on the servers and like over SMB or LDAP that you can reach using the HR person's authentication context, right? So in summary, I'm going to talk about first like just a brief overview, like a really gentle overview of Windows authentication protocol. This is going to be in a test tomorrow. So I hope that you are going to take notes. A general description, we are going to use LDAP as an example and I'm going to like take your hand and walk you through on how NTLM, Kerberos place together with S.P. Nego and we are just going to skim over and I have two demos for you, not live demos because they told me I'm not really allowed to plug in random USB sticks on this machine. We are going to talk about SSPI and basically how to authenticate locally, but remotely, but also locally part. So Windows authentication protocols in a nutshell. Before this first slide about authentication protocol, one thing that I want to mention is most of the people that I talk about, that I talk with about authentication protocol, they have this weird notion that like the authentication protocol basically stops being useful after you perform the authentication itself and basically it's either a yes or no decision whether you get access to the resource or not from the server. However, I would like to point out and I'm going to point it out multiple times that it is not the case because usually modern authentication protocols also do key exchange and you will have to do something with the encryption and the encryption key context. So yeah, as I said, there is going to be a lot of letters. No worries if you cannot read it. It's actually quite readable. I was really afraid of this one. So basically, if you take like a random network protocol, generic overview, client would like to log into the server. How to do this? Like if you would be willing or if you wish to implement your own custom protocol and you would like to have some authentication on it, then basically like this is the generic rundown how it should look like. So you would obviously want to have some version negotiation between the client and the server because probably your protocol is not going to come out right at the first time. So you will need to have some versioning and the client and the server should be using like the same version of the or the dialect of the protocol. Oops, we are already at SMB, whatever. Yeah, so after the version has been negotiated, then you will see the authentication protocol negotiation. This can be in the version negotiation as well. And then both the client and the server agreed on authentication. Then I put it in a separate logical container. The authentication client and the authentication server are going to initialize. And usually everything that these two generic like authentication concepts are willing to communicate with each other are just going to be interposed on the actual network protocol. We are going to see it in like in great detail later on. And this back and forth of the out messages are going to go until the authentication either succeeds or not. Obviously currently we are not touching the authorization part because we don't have like a day of explaining every single bit of information here. So after the authentication is finished, then usually both the client or the authentication client and the authentication server are going to end up with a shared secret. And this shared secret is used or not used depending on what the protocol would like to like the actual network protocol would like to do in the future. They have the option to use the shared secret to basically encrypt or protect the integrity of the protocol. So moving on, this is a continuation of the slides before. So authentication protocols, so encryption and decryption, user would like to list the shares for example, it double clicks on or like it types like slash slash IP address because we are still in the NTLM times and we don't want to use Kerberos anyhow. This is going to be translated inside of the client to like a series of messages. And these are plain text messages. So basically the client can request the authentication protocol to encrypt the message. Then the encrypted message is going to be dispatched to the server. The server is going to dispatch it to the authentication protocol which does the decryption and or the integrity verification and going to be like turtles all the way down from here. These encrypted and decrypted calls are going to go on till the protocol terminates or like the network connection terminates. So here as I was explaining, we are going to use LDAP as like a case study because it supports like all the authentication protocols and more than that shows like the generational weaknesses in, I would say like in any single place, but whatever. We are going to, the alcohol is hitting me, we are going to see like what LDAP supports as authentication methods and how we can maybe proxify some of these. Moving on. Yes, so LDAP has a Sicily authentication. How many of you are familiar with the Sicily authentication in LDAP? Yeah, I am not really seeing many hands around here. So Sicily authentication is actually raw NTLM authentication that has been like forced inside of the LDAP protocol thanks to Microsoft because they, when they came up with this whole NTLM stuff, they wanted to like stuff it like literally everywhere. And this is one of the main reasons why we cannot really get rid of it. So basically what is happening here is that like you can have like a root query before authentication that basically explains like it's kind of like the version negotiation part. Then you have the binge request where you specify Sicily. And if you want to check it in Viershark, this is the place where Viershark fails basically. The sector just fails because not because of security issues but because like it's just like simply put a badly made protocols. Nobody is really using it except for nefarious reasons. One might want to use it anyhow. So binge request, binge response, NTLM client is going to kick in. NTLM client, like the LDAP client is going to ask the NTLM client, hey, what is the first structure that I need to send to the server so authentication can proceed. And NTLM is going to say that's like, okay, like let's negotiate. No, that might be an issue there. But the point is that NTLM has like basically three date structures, the authenticate, the challenge and the negotiate. Yes, okay, then it's negotiate. Sorry about that. So basically like NTLM messages are being interposed on top of the LDAP protocol, passing them back and forth till the authentication finished. And then you have a shared secret available. And if for example like LDAP integrity protection is enabled, then this is the shared secret that is going to be used for either encrypt and or integrity protect your LDAP messages in the future. Okay. So quick word about Espinego. Espinego is basically an authentication protocol selector protocol. That's that's a tongue twister that supports LDAP, Kerberos, the other type of Kerberos and potentially it could support other authentication protocols as sub protocols. But mostly like these are the like NTLM Kerberos are the two main ones that are being used in in a normal day to day life. So Espinego itself does not provide authentication. It is just a way for the client and the server to agree on an authentication protocol to be used in the future. And one of the tidbits is that Espinego has has an added integrity protection in itself. So basically it is to protect against downgrade attack like not downgrade attacks, depending on if you think like NTLM is more secure or less secure than Kerberos. But this integrity, integrity protection requires after the NTLM authentication finished as the sub authentication module to use the secret key to sign the Espinego packet that has been sent by the client from the server. So it verifies that the client in fact requested only NTLM authentication and not somebody was doing it my man in the middle and removing the Kerberos part from the request. Yeah, so LDAP. LDAP supports like these the following three main authentication protocol classes. One is called SIMPL. The SIMPL can have a plane which is like user and password. Obviously there is no security protection and no secret key exchange after that because you are literally sending the username and plain text password. There is also none which is we call anonymous bind. There is Sicily which is like it still bugs me that it's still enabled everywhere. And we have the SASL. And inside of the SASL you can find Espinego and GSS API. And the external one is really, really interesting because it basically the external one presumes that you have created like an MTLS connection already to the LDAP server and the external does not provide any other information. It just says that's like hey I already authenticated to you but over TLS or SSL so please like verify that one and since I'm verified then just let me in. And this is really, really useful if you are doing like ADCS attacks for example depending. So just a quick rundown on the on how the LDAP SASL, Espinego, NTLM authentication works. And I believe like this is going to be the most complex one. I don't want to torture you further. So basically, LDAP client kicks in, connects to the server via TCP hopefully. There is some version negotiation with root query Espinego client kicks in. Espinego client is going to like instruct the LDAP client to send basically the supported authentication protocols to the LDAP server. LDAP server is going to kick in the Espinego server saying that hey I got a new client, this is what they support. What should I reply? It should like the reply of the Espinego server is then interposed on to the LDAP client and LDAP client relays it to the Espinego client and you know, you get the gist. Like you don't need to read it through. Maybe at home because there's going to be a test tomorrow. So how Kerberos authentication works if Kerberos, if we are not talking about mutual authentication for Kerberos, then it's going to be really simple. The reason why it is so simple is because the actual Kerberos communication is not being shown on this slide because the complexity is on the other side of the other end. So basically then LDAP is just basically using Espinego to instruct the Kerberos client to request a ticket and then they just send this ticket and this ticket already contains the shared secret. So let's talk about SMB encryption decryption because it is a bit different than like Kerberos and normal NTLM. So Kerberos and NTLM themselves provide encryption and decryption algorithms to be used, which are specified by RFC and NTLM encryption decryption, RFC, the Arata is larger than the actual RFC. That should tell you something, but mostly like besides LDAP, not many other protocols are actually taking advantage of NTLM encryption decryption probably because it's based on RC4, but I don't know that part. Yeah, so how SMB does it, however, is that SMB says it's like, oh, it's really nice and cute that you are defining your own RFC and your own encryption and decryption methods, but actually I am Microsoft, I don't really care about it. So how about just give me the secret key and I'll deal with the rest. And this is going to be super important later for us when we are actually trying to rebuild some authentication context in our own machines. So yeah, Microsoft has this SSPI. SSPI is a set of APIs that allows you to interface with Alsus in a programmatic way. And SSPI is basically created because as some of you might know, Alsus cashes some credentials. I don't know if it's a big secret or not, but yeah, it cashes some credentials, sometimes plain text, sometimes not really plain text credentials, but they are there. The reason why they are there is because you have like a million processes running on your computer in a Windows domain environment and these processes at Othoq want to connect to the DC or to some other servers. And yeah, it's not really nice if we ping the user every time of a random background process which is to authenticate to the DC just to get the credentials every single time. So SSPI is the way that like a user land application or user land process would perform like an authentication either with or without the user consent or yeah, they don't really care about consent in this part, but like there is a way to set it up that it prompts the user, but like why would you use that if you are on the attacker side of course. So SSPI defines a kind of handful of API calls, but for the sake of this discussion, we only need to take five into account, acquire credential, handle, initialize security context, query context attributes, encrypt and decrypt message. This is how we roll. Like if you have like a legit or an illegit process, then this is all only the five that you would need to implement to get the authentication action rolling. So again, generalization how it looks like. So basically client would like to connect to the, would like to authenticate to the server. So client on its own and is going to first invoke acquire credential handle that is going to create like an authentication context like on the else's level then for every single like authentication message that needs to be passed between the client and the server, the client is going to constantly invoke the initialize security context part. Up till to the point where the initialize security context actually from the client part comes back to the network client and says this like okay, we are finished and like I believe that we have like a good go at this authentication part. So if the result is okay, then there is going to be a shared secret like the shared secret that we were explaining on the, in the general overview. This shared secret however is going to be kept in the assas process or something like no, it's probably it's in that, like it is in the assas process. Sorry. And then there is a problem. So like so far so good because like you are not, you're not an administrator or some high integrity process so you cannot get out these keys. However there is actually an API call because what happens if for example in SMB's case SMB decides to implement their own encryption and decryption algorithms and they would need to have the key for that like the shared key, right? What happens if like some like my process would like to have that as well. So therefore we have the query context attributes API call which you can invoke after the authentication has finished successfully and the query context attribute like this API, I'm not going to say it again, is actually there to query like a lot of different aspects of the current authentication context and one of these aspects is to actually give you back the secret key, like the shared key that has been generated based on like either Kerberos or NTLM or credit SSP whatever. And this is super useful for us actually because yeah almost almost. So this is super useful for us because what we can do here is that now like we can like from our machine can instruct Alsace to perform authentication for us. So authentication is done. What we need is the secret key and we can now request like we can request Alsace to give us the secret key. Well what happens if like we can we do it remotely? I mean like it's just like four API calls. So like if you build like an RPC that is wrapping these four or five API calls then you should be golden, right? Now there is kind of a problem because there is a special case that like Kerberos mutual authentication. In Kerberos mutual authentication you will need to have like in anyways sorry you will need to have not just the secret key but also the IV. But how are you going to get the IV? The query contest attributes API does not tell you the IV at all. And in normal like in normal situations like in NTLM you don't need the IV because it's RC4 so why would you need an IV? For Kerberos case the IV if it's not mutual then you can read it out from the ticket itself. But if it's a mutual authentication that means that like the actual client and the server are going to do like another round trip of exchanging tickets then the session key like the ticket that finally you end up with in the client is going to contain the IV but you cannot decrypt that part of the ticket that contains the IV. And ASUS doesn't give you that. So this gave me a bit of a hard time to figure out but then it clicked on me. Basically we have the encrypt message and decrypt message so taking the encrypt message is going to wrap our data whatever data that we are encrypting in a token and that token must have the current initialization vector otherwise like the other side would not be able to decrypt it. So this was the missing piece of the puzzle. Now we have basically we can make ASUS authenticate. We can have the initialization vector and we can have the secret key as well. So you're ASUS but on my machine. The goal is basically to create wrappers for these four API calls well sorry five API calls and that is the easy part. The hard part is that now you have two choices. Now you either need to modify your own attacking machine's ASUS process to interface with this to be leveraging this new newly created like RPC or you would rewrite each and every single like authentication protocol that you want to deal with. And since I love authentication protocols, guess what where I ended up. So it took I would say like roughly two years. But yeah so I came up with an authentication library that look for Python that is like that is used by all of my like network implementations that leverages these type of like RPC calls. How does it look like? So again you don't have to read it. Oh it's actually okay. I kind of like how it turned out. Basically what you're seeing here is that you can perform these RPC calls. I'm not going to go over each and every step because I don't want to make this presentation one and a half hours long. The final part of this is, I'm sorry, yes. So basically what we were discussing before is that there are like two ways that you can do the encryption decryption part because my first instinct since I could not get the IV out, like I could not figure out how to get the IV. What I did is that's like for each and every encrypt and decrypt message call I was performing yet another set of RPC calls to inject back the encrypted data from my machine back to the victim's machine and make the else's decrypt this and send back the raw data. Now this is not really the, let's say it's not really a useful solution because it just hogs the bandwidth. However, here what you have is that with this, with the previously explained get session key and then encrypt message with some random message and unwrapping the response token, you can basically have the entire encryption and decryption context back in your home machine from the target, from the victim's target machine. So I would like to show you two use cases for it, actually multiple use cases, but like two, which I have a demo for. One is, oh, how does it get, how did it get here? Sorry. One is just basically the proof of concept code is going to be executed on the victim's machine and then from another machine we are going to perform an authentication to the domain controller. Let's hope that the codec works this time. I see the video here, just a second. Oh, that's nice because now I have to look over here. Just a second. Okay. So the attacker machine is on top. It's a Ubuntu machine and the victim machine is on the bottom. So at first we are just going to show that we are not administrators. We are not like in a highly privileged users group. And then if everything finished then we are going to execute this proxy binary. And this proxy binary, let's stop here. This proxy binary currently is just like listening on the port on the victim machine. Obviously this is not the way that you would do it in a real life scenario. This is just for proof of concept sake. And yeah, on the target machine what you see here is that basically V told the library, the SMB library to yeah, sorry. We told the SMB library not to use any actual credentials, but to use the user name, sorry, the RPC server on the IP address and port of the victim machine. And as soon as basically I executed the, like I gave the instruction, let's just go back to the URL quickly if we can. Oh, sorry, here. So on top, basically that is the only information that the SMB client is using. So we have the IP address of the target machine two times basically because no, just one time, sorry. And the port is by default it's set to something. Doesn't really matter. So the point is SMB connection is going to basically work immediately and we can oops, yeah, sorry. We can perform an authentication here. Thank you. So yeah, it's just, I deliberately printed out all the debug data so we can see what is happening there. And for the other protocol is basic oops, sorry, going back. There. So just to show that it actually works so like it lists the shares and I can, like we can actually download the file from the destination. Yes. So that was for SMB and we have one for LDAP as well. And that should be coming soon. Yeah. Basically the command is exactly the same and yeah, we logged in to the DC via LDAP. And here we are listing the SPN, like the Kerberos users for the time being. Okay. Sorry, I just need to speed it up because times is of the essence. Yeah, that was the first demo. So this was one use case. The second use case is that basically you can use this technique by grabbing a Raspberry Pi, like a single one. You can make it a USB dongle. You can add some clever techniques to make it act as a keyboard, like a rubber ducky, for example, and also to act as a USB Ethernet device. If you set up DHCP server, Wi-Fi access point, whatever, then you can create a really, really neat attack tool with it. Because as we have seen it in the previous slides, this technique does not require the attacker to know anything prior about the target domain. If there is a user account that is actually active and the user has executed this proxy library, then everything else can happen like all the authentication and all the attacks are happening from another machine. Okay. And the basic domain information can be pulled, for example, like the set log on server, like various log on server or whatnot. And since all users can pull information from the LDAP, then it just basically trickles down and you don't need to add any, you don't need to, like if you have an embedded system, you don't need to add any specific, like target specific code. This means that, like, if you put everything together in a small Raspberry Pi, which is kind of like on the desk, for example, then what you are going to end up with is, like, a Pwn everything toolkit. Because if the proxy is going to, is successfully executed and the way that it's being executed is that if you plug it in, I'm just going to ramble, sorry. So if you plug this device in, then it's going to show it's to the target machine, an unlocked target machine. What is going to show itself as a keyboard, like an HID keyboard, and a USB internet device, right? With the HID keyboard, your attacker code, like just like with the rubber ducky, you control the key code, you can instruct the machine to execute the binary, like the proxy binary. And the proxy binary is not going to go out to the internet because you don't know if there is an internet or not on the target machine. But what you know is that it has access to at least one network because you provided this network to it via the Raspberry Pi. And then this proxy machine can connect back to the Raspberry Pi, and then whatever application is running inside of this Raspberry Pi can immediately leverage the user authentication context of the, of the target machine. So basically, like with some clever engineering, with this technique, you can do like a upon all Raspberry Pi that works on ad gap networks as well. Like the target doesn't need to have any type of access to the internet. So demo. Stop, stop, stop, stop, stop. Okay. This is the victim's machine. The victim's machine is currently just like, okay, thank you. The victim's machine is basically just a standard Windows 10 machine. And I have plugged in this device. Like you will have to believe me. I wanted to do it on the stage, but they told me that it's probably better to have video of everything. So what are we going to see now is that we have to wait till it boots. And then virtual keyboard immediately starts executing the code. The actual like reverse proxy binary is served via HTTP from HTTP server of the Raspberry Pi device as well. And yes, at this point, what you would see is that the proxy is executed and you will see two host names and port addresses. Those, those two host names are the active directory server and over the LDAP port. Yeah, it's too small. I, I'd be able to make it bigger, but no. Yeah. But this is, this is not the point. The point comes afterwards. So what we can do is a bit of clever engineering. We can open the browser. Now, usually this is not what you would do on the target machine. This is what you would do somewhere else. Where is the somewhere else? Since I explained that the Raspberry Pi has a Wi-Fi like access point, this service that I'm going to open, oops, what happened? Oh yeah. So this service is actually my Octopon project. I was explaining Octopon on area 41, like DEF CON Switzerland a year ago. And this Octopon integrates this attack technique into itself. So what we are seeing here is that basically we already have a lot of information available to us via the tool because like between the time that the proxy connected back to Octopon's like handler server and the time that I opened this, the automation immediately started enumerating the domain. So what we are seeing here is like there is some SMB browser as well. So like the SMB connection is working. There is no, and there has been absolutely no prior like user secret configured on this device. And we are going to perform Kerberos thing soon. So we have, this part is the handler of the agent like the reverse proxy agent. And currently like Kerberos thing is set as a separate entity. So if I'm going to basically instruct the Kerberos logic to use the already, you already created LDAP session that has been created by the proxy authentication to the target domain via the proxy library. It will basically allow me to perform Kerberos thing on the target machine. And then basically like we have all the Kerberos tickets that we can send to hash get to crack. And, okay, tickets, speed up a little. Who made this video? Okay, yeah. And what is happening here on this session while we were Kerberos thing, it also started domain enumeration over LDAP and SMB, which is basically not bloodhound but bloodhound. So like I basically, I rewrote bloodhound in Python from scratch just for this. So what we are going to see here is that there's going to be a cut. And after the enumeration has finished, we just like I'm listing here that's like all the IP addresses and ports that the tool is being, the tool is connecting to right now. And yeah, we did the SMB enumeration since it's a workshop domain. There is not many, there aren't many SMB hosts. And this is actually, this is the representation layer of the tool like my bloodhound implementation. It's called Jagdo. And we can see that it's already like loading in the database that was generated from the other session. And soon, if it's loaded, what we are going to end up with is a canvas, hopefully. And a second now. Yes, canvas. And then here are all the paths to the domain administrator. After, yes. Here you go. And this is fully automated. Thank you. And yeah, I have some other slides as well. But this is basically the gist of it. And I hope you have, oh, sorry. I hope you have some questions. So I think we can, oh no, sorry. Really quickly, I would like to do some shout outs. Hopefully the persons are inside of this room. So there is future research to be done with this one. Because I don't want you people to be forced using my tools. Everything, by the way, except for the octopon part, everything is going to be open source. It is actually already open source. I published it yesterday. No, today. Afternoon. And the future of this research would be the, to have basically like all windows based tools, leveraging this type of technique, which can be done. And there was a gentleman, hopefully he's here, called ethical chaos. And a few years ago he created a tool. And this tool is basically allows, like, it hooks every single, like, processes on your, like, attacker machine and overtakes the SSPI calls. Or, like, not just the SSPI calls, but like it could use to be overtaking the SSPI calls as well. This is some modification needed. And it could be integrated, like it could be used with this technique. That would allow basically like every already existing windows process on your target, on your attacker windows machines, your PowerShell scripts, your SQL, browser, whatever, to leverage this technique. So you don't have to deploy these scripts on the remote end. And it would be really nice to do. However, I have my own platform. So thank you very much. I already put like a lot of time into this one. But if somebody would like to do it then, yes, go for it. Just hit me up. I can help if you need. The other shout out is that the other future research that can be done is that there are a handful of other API calls that can be added here to support Piki in it. And other, like, Windows Hello, like, certificate-based services to basically use the exact same type of, like, authentication proxying, which might be interesting. Interesting. I am going to work on this part, definitely, because I know at least one person who might be really interested in this. And yes, so thank you for everybody who is on these slides. Your research has helped me tremendously. And also here are the links with all the, like, open source tools that you have seen here on this talk. The WSNet-dot-net is the actual, like, proxy that has been used here. And QA time, if you have time. There is a gentleman next to the camera that I, for sure, see. But I mean, like, currently, no, because it is, like, it's been, like, I don't know the English name for it, but, like, what this process does is similar to any other process that would use SSPI would be doing. So, like, there is no, no, like, nefarious running around here. Also, like, it's a fresh tool, so, you know, like, maybe in two hours it will be detected. I wouldn't know. But I already implemented it in Rust and NIM, but I'm not going to provide that part. So, any other questions? No? Thank you very much.