 We will hear a bit about Microsoft domain quirks and how they can be exploited. About this, Jakuto will tell us now. So hello everyone, welcome to my talk which is called domain computers have accounts too. And in this talk we will abuse domain accounts to actually be able to own some machines through relink and delegation. And we will be abusing some old quirks, some new quirks and I hope we will have a lot of fun. Now I want to start by having a shout out to some guys who basically did all the hard work of figuring out ways to abuse machine accounts. I want to mention specifically these people which is Lee Christensen, Will Schroder, Matt Nelson, and Alex Shamir and Durgan. But there are a lot of others that basically over the years spend a lot of time digging into the Active Directory and Microsoft domains. So everybody else who paved way for this research, you did a great job. And I also want to thank my employer because it's nice to be able to do your own research without having to worry about paying the rent. So we will start with a very old technology that's part of Microsoft Active Directory and that's NTLM. NTLM stands for new technology line manager and the NT means it was introduced in Windows NT 4.0 which it was introduced in 1996 which incidentally the protocols are older than I am so it's a pretty ancient stuff. Now NTLM is a suite of protocols for security because there's a lot of terminology, a lot of confusing terminology when it comes to NTLM and we will call NTLM the whole package of different protocols that are used for basically everything you need to be able to communicate on the network securely. So challenge response authentication protocols, signing protocols, the whole package. And NTLM is best known for what's often called the NTLM hash which is a hash of the user password and basically everybody who used Mimikatz probably dumped their own NTLM hash of the password and there's a lot of talk about past the hash attacks but we will not talk about those because for this talk the most important thing from NTLM is the challenge response protocol. So the way challenge response protocols work in general is that there is a shared secret between the client and the server so there is something both of them know and therefore both of them can do a calculation based on some random challenge and both of them will get the same results if they really know the same secret. So the way it works as can be seen from this from this diagram is that when the client wants to authenticate to the server the server sends back a random 32-bit number in this case which is the server challenge and both of them calculate do the same calculation with the shared secret which in this case is the hash of the user's password and hopefully they will come to the same result so then the client sends the answer to the challenge to the server and the server can verify it and in version two there is also a voluntary client challenge step so also not only the server can be sure that the client knows the secret but also the client can verify that the server knows the secret as well. Now for this presentation I will have some footnotes. These are things that I think are interesting but are out of the scope for this talk so it's more like something that you can later check out when you check the slide deck or read if I'm talking about something you already know. So now the thing about challenge response protocols is that there are often vulnerable to what's called relaying attack and NTLM is unfortunately no different. So how does relaying work? What's important from this diagram is that as you can see the first thing that actually happens is that the client attempts to authenticate to the attacker which is the skull in the middle so the client goes to the attacker and says I want to authenticate to you using net NTLM and the attacker instead of generating a random challenge instead asks for the challenge a server it basically wants to authenticate to without knowing the shared secret and so it gets its own server challenge a random one and then just forwards it to the client using it as an oracle for calculating responses to the challenge so the client as it wanted to connect to the attacker it will happily comply it will calculate the answer to the challenge send it to the attacker and the attacker can then forward it to the server now obviously it can completely even if there is a random client challenge it can completely ignore it it's we as an attacker don't care whether the server really knows the the the secret we just want to authenticate and we can just happily kill the connection with the client and said something went wrong we are connection reset but so the two important things to take from this diagram about relaying is that in this scenario the attacker has absolutely no knowledge of of the shared secret I mean if the if the if the challenge challenge response calculation is is vulnerable to for example brute forcing he can try to to force brute force the the secret but this this attack by itself doesn't give the attacker any knowledge about the secret and the other important thing is that as I said earlier the client has to initiate the connection so or we have to have another way of forcing the client to connect to us now because this is a pretty big deal and it's been known for for quite a while there is actually a mitigation in net ntlm and that is that apart from just being used to prove that you have a knowledge of of a shared secret net ntlm can also derive a session key from the shared secret so as I said earlier because the attacker doesn't know the shared secret he can't calculate the session key there's no way he can guess it from the from the challenge response protocol and when signing is enforced or signing is negotiated between the two sides every message going through must be signed with that session key so you can relay authentication it will work it will go through fine but after that you can't basically create your own messages or even tamper with temper with messages coming from the client because you have you don't have any knowledge of the session key and therefore you can sign you can sign any messages however the interesting quirk is that not all protocols are supported support signing so you can't force signing for all protocols the most common protocols that are used with ntlm authentication which is smb and ldab which is used for accessing the basically the active directory the properties of objects and user accounts etc they do support signing but http doesn't at all so if you somehow force a client to try to connect to you over http and authenticate using net ntlm you can be sure that it won't ever ask for signing because it doesn't even attempt to ask for signing over http and another interesting thing about this is the first message that's actually sent which is the negotiation message the ntlm ssp negotiate contains a bit mask of requested security features it's the way how the client and server agree on how strong encryption they will use etc so it can for example say i don't want to do signing ever or i want to do signing if you can or i need signing don't even bother answering if you don't support it and willingness to use the first version of net ntlm which is way weaker than version 2 and the important thing is this message contains again a signature signature again based on the shared secret called the mic the message integrity code and therefore cannot be easily temperate and again say for implementation bugs because there was recently there was a drop the mic vulnerability that basically allowed you to completely throw away the message integrity code but that was a bug and was promptly fixed so it shouldn't be possible which means you can't easily downgrade a request for signing not only not only when the signing is enforced but for example if for smb you just have a client that says hey if you can do signing do it please then you can just you can only relay this message completely even with this bit set and therefore if also the server can do can do signing they will negotiate it even when you are many in the middle in their connection so even if even if the signing is only requested you are basically screwed and can't communicate easily which is again why why the fact that HTTP doesn't support signing is so important for us because it gives us a primitive that allows us to relay easily without having to worry about negotiation signing and so now this was a primer on until man and until I'm relaying and now let's get to the title of the talk which is domain computers have accounts too and actually every machine that's joined to a domain has its own account in active directory so I will again the terminology is kind of kind of awkward here but I will be using account to actually refer to to an item that's actually in the active directory and I will be using user accounts for accounts that are actually for users and machine accounts for accounts that are actually representing machines and the way you can recognize these these accounts is that the name of the account always ends with a dollar so for example if you have a desktop 8k cg bf6 registered in the domain it will have an account with this name with the dollar sign at the end now there are not many differences between user accounts and machine accounts the most important difference is that the machine accounts have very long I think it's like 32 characters randomly generated passwords which can even contain invalid utf 16 characters so it's basically 64 bytes random or maybe 42 bytes I'm not really sure here but the point is it's it's too long to brute force so guessing machine account passwords is basically impossible but apart from that it can do all the things that regular accounts can do so it can authenticate using ntlm it can get both tickets which we will talk about in a minute and it can be a victim of ntlm relaying so it can be a victim of the attack I showed before so the big question is can we own a computer by relaying its machine credentials let's say we have a way of asking of forcing the computer to authenticate to us using its machine credentials and we can relay it somewhere where do we relay it to own the computer is there even such a way and this was an open question for a long time and just recently in last year and this year we started to see some answers for it and to be able to answer this question we have to look at another authentication or another security protocol that's used on Microsoft domains and that is Kerberos now Kerberos is a protocol for distribution of symmetric keys so it's a very complex beast basically it was designed by in MIT and then Microsoft added a lot of its own stuff to it and it's a very complex beast so this is basically the topic that I will be simplifying the most and we will not care about distributing any keys etc we will just care about the authentication factor of this protocol and so bear with me as I try to explain the basics and I hope I will not end up like Swift on Swift on security so the first thing that you need to know about is what a TGT is it's it's a mouthful it's a ticket granting ticket and it's basically a proof that you authenticate it that you can later use to request tickets for services so the favorite infosec analogy here is an analogy with an amusement amusement park so if you come to an amusement park and ask for for a ticket for the whole day for you know for all the attractions you can basically buy it and this is what what is your TGT and later when you want to get for example coins for bumper cars or something you just go to the booth present your your whole day ticket and they will give you coins for the car ride which is the ticket for the for the service so and basically why you want to use a TGT is that you can only once authenticate using your password or using your password hash etc and then you have this ticket that doesn't have any relation to the users password that you can just go around and pass to everybody and your identity only needs to be checked once so you only need to authenticate once and all the other steps can be authorization so only can can this user access this not is it really that user so the way of getting a TGT is very simple you just ask for a TGT the Kerberos distribution center says that you need to pre authenticate so you again send send another request this time sending a password hash or a key or something that basically can prove who you are and you get your TGT now the other part of Kerberos after you have a TGT are services and don't think about services as in windows services which again the terminology sucks but think about different protocols so for example LDAP isn't service is a service HTTP is a service syfs which is another name for SMB file sharing is a service and every site service has an SPN or service principle name which is basically a unique identifier used in the domain for this particular service that you want to authenticate to so some examples of SPNs are LDAP slash dc.domain.com which is the LDAP service on the domain controller or syfs.filesdomain.com which is basically a file sharing service on a file sharing server so now when you already have a TGT authenticated to a service is simple you just go to the Kerberos distribution center ask for a ticket for for example syfs slash files domain.com prove yourself with the TGT and the Kerberos distribution center checks your TGT that is basically correct and gives you back a ticket that you can use to authenticate to the server to the fast domain.com server as I said earlier as Kerberos is more like a key distribution protocol you also apart from the of the authentication part you also get the key that you are supposed to use to encrypt the communication but but it's not important for this talk so one thing that is common to all complex and mature or I don't know how we want to call it protocols that take care of authentication is that they often want to provide some way of delegation or impersonation so some some primitive that allows you to pretend to be someone you really are not and this is useful they say it is useful for single sign-on for single sign-on so for example when you connect to a server and that server wants to for example connect to a backup server and then it can use your credentials so so it seems like if you directly connected to it and all of the all of the authorization all of the ACLs you have set up basically basically work and so it's it's something that these protocols often do and Kerberos or at least the Microsoft implementation of Kerberos is no different and the most powerful delegation is so-called unconstrained delegation it even had it in its name and what it basically means that if you set up a service or set up a machine therefore all services on that machine for unconstrained delegation it means that every ticket that the KDC generates for for this machine contains the TGT of the of the original user such that the service can decrypt it therefore once you you actually give this ticket pass this ticket to to the server you want to connect to it can decrypt it and it can do everything it would be able to do as if it authenticated with a password it basically has the the master ticket the ticket gun ticket it basically has a copy of your of your proof that of your proof of who you are however and this is very sensible is that by default this is something only domain administrator can set up because basically when when you compromise a host that has unconstrained delegation allowed every time you get somebody to to authenticate to you you basically stole their credentials or basically you can go around and tell everybody that I am domain administrator and and they will believe you so I again prepared a small diagram how it works it's almost the same as getting regular tickets but this time the KDC actually includes the TGT in the response but as it's encrypted with a key of the target you as a client can't really tell whether it's whether the TGT is in it or isn't isn't in it you just pass it to the server and it can see oh he gave me a TGT that's nice and this is very powerful but also very dangerous because basically when you trust somebody for unconstrained delegation they can go around your domain and pretend to be anybody to everyone else so Microsoft introduced what they call constraint delegation or as for you to proxy and this time actually the trust is not like a global whole domain thing but the trust is set up between two two services actually in the Microsoft implementation it's most often set between two machines which basically means that if PCA trusts PCB then every service on PCA trusts every service on PCB and it works very similarly but this time there's no TGT passing because if you pass your TGT to somebody there's no way anybody can limit you on what you can do but this time if the trusted service gets a for wearable ticket that actually authenticates user for the for the trusted service it can ask the KDC to turn it into a ticket authenticated the same user but for the trustee machine so in the example we had before when a user sends a ticket to SIFS at PCB the service can take this ticket use it as a proof that the user actually accessed it go to the KDC and get the ticket for for LDAP at PCA which basically trusts all tickets from PCB the way it were it looks like in in in a diagram is that yeah the ticket exchange is the same as always but now let's pretend that for example files.domain.com has a service that basically allows you to get an older version of the file and it wants to preserve all ACLs etc so the backup.domain.com trusts all tickets from files.domain.com so the files then says I have this ticket that authorizes user to access me please give me a ticket that authorizes the same user to access the backup server and as the constraint delegation is set up the KDC basically says yeah it's fine okay here is your ticket and the files.domain.com can go to the backup.domain.com and basically pretend to be you and so with constraint delegation originally we had the same limitation as with the unconstrained delegation it was just way more granular and that is the only domain administrator can set it and the old way of setting it up was that it was set on the trusted machine side however I don't know when but recently maybe 2016 or something like that Microsoft added a so-called resource-based constraint delegation which means that the trustee can now set constraint delegation for itself so if I am a victim machine I can basically go to the loadup server and say hey I want to trust all the kits that come from the attacker machine and this is the important primitive that we will be using to to be able to turn the relaying of machine accounts into something useful because once we are able to relay the authentication of the victim machine account to the to the domain controller we can basically then we can basically then set it to trust any other computer in the domain and there's still a piece missing which is actually a funny quirk that at the first side looks innocent but we will basically allow us to do anything we want it's that there's another another it's not delegation as much as it is a way to to basically do protocol transition which what basically it means is that often when you are a service or you are a machine and you have a ticket that for example authenticates to to Samba or something you can just create a ticket for the user for any other services you offer from thin air so basically the way it works is that when you are when you are a service you can always come to the go to the kdc and say hi I want to create a ticket that authenticates administrator to myself and what's more what's more important for us as these tickets work as proof for as for you to proxy so you can basically take this ticket that you generated out of thin air without any credentials without any password and say turn this into a ticket to another machine that trusts me and it works so this brings us to our plan of attack so the plan of attack is we own any domain join machine because we need somebody who can actually use the s4u to self to to create tickets out of thin air so we own a machine that has any service which is basically any machine and then we find the victim machine get it to authenticate to us using ntlm relay this authentication that it send us to LDAP and use it to configure so that the victim trusts all tickets that come from the attacker and now as we own the on the attacker we can just get the tgt for the attacker dollar account the machine account we can use s4u to self to generate an administrator that allows for for the attacker machine to that authenticates administrator to the attacking machine and then we can again go to the kdc and use s4u to proxy to turn this into an administrator ticket for the victim so a single relay and we have basically we we can authenticate as an administrator to any victim machine now i talked about the last four four points pretty horribly so i want to focus now on the first two points so how can we own any domain joint machine now there is a there is a funny thing in the active directory is that by default all accounts and even machine accounts can up up to five machines to the domain with just their credentials so i mean every sensible administrator disable this i i have yet to see a production domain that actually has this still enabled but if you find a domain with this enabled you can just go to the domain controller ask it to add the machine and it will happily do it and it's everything you need but and the funny thing is that as i said even machine accounts can add machines and these machine machine accounts can then add machines so if you are very clever you can basically skip the first step and when you are in the first first step and you are relaying the victim credentials to LDAP you can use LDAP to first create the attacker controller machine generate a new one and then set the trusting so you can do just one relaying and basically create a machine and set it as trusted uh and the other way is like the old ways so you find a an old windows server that is vulnerable to eternal blue war you for example uh but kali on a provided workstation and steal its credentials uh as long as it's not uh as long as it's not encrypted with bitlocker uh now so these all these steps were pretty easy and pretty often they are they are achievable but the hard part that remains is getting authentication from machines which is which is the part where we still need more powerful primitives so if you have any idea how to do this you can basically uh you can tell us and we'll be happy because uh right now uh the best way we have best ways we have are a man in the middle attacks which are kind of quirky so the the best one that always so far work for me is physical man in the middle where you literally take the machine when you have physical access to it and reconnect it to your computer which runs the acp server tells it you're the dns server and resolves every every single address to your to your attacker computer and once you reboot the machine windows eventually tries to download something uh most of them i've seen uh some windows update certificates which for some reason it thinks it's a good idea to download using HTTP and authenticates using machine credentials as after the reboot there are no other credentials to use so far so it will happily authenticate using them uh another way of achieving a man in the middle position in this way is actually remotely not physically is uh mitm 6 which is an interesting project where if the network where you are doesn't have ipv6 setup at all you can basically uh most of the windows machines are set up so they still try to look for uh ipv6 dhcp servers so you can just start your own dhcp6 servers and again uh tell everybody about the dns server as ns windows prefers ipv6 over ipv4 they will uh use you they will probably use you instead of the ipv4 dns server that is actually that is actually meant to be used in the domain uh there are also some funny and weird primitives for getting authentication from machines one of them is changing your rock skin or profile picture because for some reason uh when you when you change a profile picture it's actually downloaded uh downloaded using the machine account and there is a protocol called daf which is basically file access over http so it's really reliable reliably reliable if you know what i mean and um so you you can just change your lock screen to something like web daf relay at 80 slash folder slash damage apk and again the machine will try to authenticate it authenticate to your web daf relay and you can then relay the credentials and last thing i want to talk about is is also i think pretty interesting and it's the printer buck where buck is in quotes because microsoft says that it's by design and it's a feature uh it's this there's this modful remote procedure call called rpc remote find first printer change notification x and uh what this does is basically it asks the computer to register yourself as uh register some other server as a notification listener so if anything changes about any printer it will send you a message and tell you for example this printer is out of paper now as this works over uh as this notification as this notification goes over smb it basically means that when you register yourself uh on a remote machine as a notification hunter it will try to connect with you uh with you over smb using the machine account so so yeah if i register my attacker machine as a notification receiver i will get an smb connection now most configurations at least ask for signing the negotiation so it's usually not reliable to held up as reliable reliable reliable to held up which uh support signing so when the machine asks for it then the held up will happily want signed messages and you will not be able to able to uh craft your own messages now i i've been looking into the available exploits and they basically do two calls they do open printer and then do the change notification register registration and uh the open printer is basically you need to get a handle first before you can do the other course and what it does is that it opens the target machine as as the printer not not your listener which is kind of confusing but basically the way it works is that if you want to uh if you want to get an authentication from victim you connect to the victim you open printer the victim and then you register as a change notification your own computer your attacker computer and i've been reading the rpr and protocol docs and i found something interesting which is the the printer name that the open printer accept is actually defined as follows where not only you have the regular thing you would expect is server name and local printer name but there's also apparently something called a web print server that works over http so i was like yeah http is better over smb i wonder what happens if i change the open printer from self to uh attacker slash printer slash random slash dot printer and i've started uh my relaying software and this is basically the log that uh it output it i'm sorry for the censorship but i wanted this to be authentic so this is really the first time i saw it and what i saw here is i skipped through two lines and i saw like hey it received a http connection and then it tried to here is the authentication as the as the as the machine account so i was like hey it's authenticating over http as the machine account the relay failed for some reason but this is huge so i registered the talk at ccc camp but it turns out last week i was trying to reproduce this like crazy over and over but couldn't and turns out what really happened is that these two lines i blacked out here are really what's important and that um that the connection actually came from the the the credentials actually came over smb not over http so what happened i spent a lot of time debugging this and it turns out yeah i was just quickly hacking and i left the call to the change notification registration unmodified so the remote machine really connected over http in the open printer in the open printer call but they didn't send any meaning for credentials over that it basically authenticated as a no user with a no password which is not really useful but after that as i didn't change the printer change notification registration at all it did the the known the exploiting regular smb call and it sent over its credentials and that's what i saw in the log so as it was multi-freaded i wasn't able to to connect it with either the http or the smb connection so unfortunately this looks to be like a dead end and that we don't have a remote attack that can actually make machines authenticated to us using http so this all sounds great and theoretical but i actually have a demo for this so hopefully if the demo got approved of this we will first abuse the adding machine we will then use the physical man in the middle to get the victim to authenticate to our callie machine and we will relay these credentials use them to configure to trust the machine we just add it to the domain and then do the whole impersonation delegation attack so what i have here is a victim machine which is called desktop 8 3 bnfm yeah i know it's a weird name but we'll do and i have a callie machine that has two network cards one of them is connected to the domain and one of them is actually where i've set up the where i set up the dhcp to give ip addresses and to say i'm the router and i'm the domain name server so first what i want to do is uh at the computer as i've said so i can just use credentials imagine that i'm for example in a pentest so i have an unprivileged account to log into the to the domain machine to the to the dc so i just say i want to add at the random computer and it happily because it's enabled it happily created a random desktop machine with with this password which yeah so i so i now have a machine in the domain so what i want to do next is set up the dns server i will use a responder for that i only run it as as an dns server so all the smbn http servers are turned off and also i will start up the the ntlm relay x where i say i want to i want to relay to ldap on the domain computer i want to and i want to delegate access to the and here i need to type the the machine i just added so i want to delegate access to this one so now i just do what i said i will do i reconnect the machine to the network where i have set up my dhcp server and i reboot now there are already some as you can see there are some already some windows update http request which why in 2019 windows update is happily downloading over http is beyond me but we have to wait after the reboot so there's no other account than the machine account available so we wait for a while in those boots yeah and so now as you can see we already successfully it's somewhere here we already successfully relate these credentials as the as the as the target which is the 83 bn and we we uh there it says already performed so yeah uh somewhere here it in the log there will be yeah so the desktop xxhp which we added can now successfully impersonate users on the target we are as for you to proxy so this is everything we basically need to do so now let me just reconnect the target machine back to the domain so it sees the domain control and actually and actually verify verify that the ticket i give it is correct and so now there's a helpful script in impact that allows you to do all the tgt and as for you to self and as for you to proxy and so i just need to do get st which i say i want to take it for syfs which is samba at the victim desktop which is the 83 bn fm i want to impersonate administrator and here i basically say that i want to authenticate as the machine i i edit again which is which is this one and this is the password for the machine and bam i have a ticket that actually impersonates administrator for the machine so now i can just do secrets dump where i just say i want to use this cash to take it and i don't want to authenticate using password and this is the victim and when i now run it nothing happens yeah this is probably some oh i i accidentally connected the wrong network this needs to be on v minute seven not v minute eight which i will quickly fix numbers and now try again and bam here are your credentials so we successfully impersonate administrator to the target machine so yeah this is not good so how can we mitigate the problem is that most of the chain is by design it's something that's uh in kerberos it does this meant to be in kerberos that microsoft really thinks is useful and microsoft would have to change that for example one one thing i think would be clever is to somehow prohibit as for you to sell off tickets to be used as a proof for as for you to proxy but microsoft is currently not willing to do that so the only real mitigation is you have now right now is preventing relaying so for signing for all protocols where it is available and not only ask for it but actually force it and ban entail more authorization where not available so over http and uh actually uh as i said this is this is very new so last week uh microsoft actually released uh released an advisory that recommends that you turn on a sign specifically to stop these attacks that were coming out uh late that we're coming out right now so and one thing you can do as a defense in depth measure is that you can add critical users to to the protected users group or at least give them username delegated which prevents most of the delegation attacks and so uh this is the end of the presentation as you can see epic fail happened basically the the the reason i registered this talk was that i thought i had an exploit that i didn't have but such is life uh but i'd be more than happy to talk to you later here at at the cc camp or dme at twitter at iagoto and we are still looking for new for new ways to force remote machines to authenticate to us uh using their machine credentials as this is the last thing we are missing to have a really powerful really important attack chain so that's it and have you do you have any questions yeah that's right i would say that's a warm round of applause for this guy are there any questions we have two question angels in the middle um anybody can sit up go up is there a question from the internet no no questions from the internet no questions from the audience no one you have three two one yeah i guess let's have another warm round thank you thank you