 So hi and welcome to our talk here to stay gaining persistence by abusing advanced authentication mechanisms. I'm Marina, I'm here today with EGAL, we're both security researchers at Microsoft at the ATA Group. So today I want to discuss with you some legitimate mechanisms in Active Directory which might get abused by attackers in order to get persistence in the environment. So first of all they're relatively easy to exploit that do not require the search for any zero-day exploits. Also they can be very easily automated and last and worst of all those are usually not monitored which may allow attackers to stay under the radar and gain persistence without being detected for a long time. After presenting some of those we'll discuss some of the detection methods what you can do in order to prevent this from happening in your own environment. Also if you have any feedback we'd love to hear from you after this talk. So what's our agenda for today? We'll begin with an introduction to some key terms which are important to understand the attacks in ours we're going to show a bit later on. We'll begin with an intro to Keros and Keros delegation. Then we'll dive in into our main subject of a talk how attackers can gain persistence in an Active Directory environment. Specifically we will focus on the stage in which attackers have already gained high privileges and they're interested in maintaining them for as long as possible without being detected. We'll also introduce a new concept that we call malicious adjustment time administration which I'll define a bit later on. Also we're gonna try and go with the live demo and finally show some integrations and takeaways from our talk. All right so let's take a few minutes to discuss Keros. So Keros is a ticket based authentication protocol. Say some domain user wants to access some application server in the domain how the authentication process work. First of all the Keros client will issue an address request to the domain controller requesting a special ticket to a service called the Care PGD. In response you will get a special ticket called the ticket granting ticket which is then used in the second stage. So the second stage would be the client sending a TGS request to the ticket granting service. This time requesting a ticket for that specific service that he wanted access to. So he will attach the ticket granting ticket here along with additional authentication data and if the authentication is successful he will get in return that service ticket for that specific service. Third and final stage would be using that ticket to access that application service. So the thing to remember here is the difference between the ticket granting ticket and the service ticket. While the service ticket can only be used to access that specific service, the ticket granting ticket can be used in multiple TGS requests to request more service tickets and access more domain resources. So a ticket granting ticket in a way is more powerful than a regular service ticket and it is sort of the master ticket for every user. This is why attackers would usually target those tickets since it can allow them to access more domain resources. Alright let's move on to Keros delegation. So first of all why is delegation needed? So it's needed in scenarios in which an application needs to reuse user credentials. Let's take for example a user authenticating to some web server which then in return needs to access some SQL server and perform some operations on behalf of that user. So the question is how can the web server access that SQL server on behalf of the user since the web server is not aware of the user credentials and also we don't want it to be. So for those scenarios exactly is why the delegation mechanism was introduced. It means that the web server will be allowed to delegate Keros tickets to the SQL server. Technically this means that the web server is going to be able to request for service tickets on behalf of other users. So in this case the web server would request a service ticket to that SQL server on behalf of the authenticating user. Third stage would be just accessing the SQL server using that ticket and performing any operations using the user's privileges. So as you can hear this is not a trivial functionality since it allows the servers to impersonate other users and use their privileges so defining it requires additional privileges which we'll discuss a bit later on. So there are two types of delegations. The first one is the unconstrained delegation which means that a single server can request tickets to any other service in the domain. As you can hear this is way too much power for a single service and it's not recommended to use on any account which is not a domain controller. This is exactly why the constrained delegation functionality was introduced. It means that a single service can only perform delegation to a single service or a few services which were defined in advance. So this makes a lot more sense. It means that a service would only be allowed to request for service tickets on behalf of other users only to specific services. This is the scenario that we'll focus on today. All right so let's see how attackers can gain persistence in active directory environments. First of all just a quick look at the attack stages. Attackers get into the network. They do not have any privileges. They do not have any access to any domain resources and the first stage would be to search for that initial access which usually comes in the form of credentials. So they send any phishing emails or anything else and at the end they would get either a domain account or a local system access to one of the domain computers. Second stage would be moving from that domain account, regular domain user to a domain admin. So this is the lateral movement phase. They perform a lot of recon. They move from one machine to the next each time dumping more credentials using them to connect to more machines until they finally reach the credentials of the domain admin. So usually this stage does not take more than 48 hours and unfortunately in a lot of times it takes even a lot less since admin credentials as you know as not as well secured as they should be. Also monitoring systems many times focus on this stage to catch attackers so the attackers might get busted some year along the way. However if all detections fail it's very important to be aware of that last and final stage which is a last chance to get the attackers in our environment. So the third and final stage would be getting from that domain admin account to full persistence of the environment. First of all why is it a domain admin account not enough to already gain persistence? Well what happens if that domain admin account is discovered and its password is reset? So attackers are gonna lose their high privileges and they're gonna start this entire process all over again. This is why attackers would like the moment they have the domain admin credentials to make sure that they would remain and have those high privileges for as long as possible without being detected. And this is exactly the stage that we will focus on. What attackers might do once they already have that domain administrator to ensure that even if they lose a whole of that account they would be able to elevate their privileges at any stage. Alright so let's discuss what attackers might do to get from a domain admin to full persistence in the Active Directory environment. Before moving on to the methods we want to talk to you today let's just mention shortly a few of the common methods that attackers may use today. One of the most common methods is to of course dump the entity as did file from the Active Directory which contains all domain secrets, all user hashes they can later on use to access any domain resource. Also they can use the golden ticket attack in which they forge a ticket granting ticket for an administrative account later on use it to request more service tickets and access more domain resources. Also there is the skeleton key or any other backdoor which can be left on the domain controller. So each of those has its own weaknesses for example replication requests using the DRS UAPI from a non-domain controller machine can be detected by analyzing network traffic. Also there are some ways to detect crafted tickets and any backdoor that is left on the domain controller has its own signature for example the skeleton key can be detected by an encryption downgrade activity from the domain controller. So those are just some of the methods that attackers use today to gain persistence and today we want to discuss a few different methods which all rely on the new concept that we want to introduce to you today which is called the malicious just-in-time administration. So before discussing about the malicious concept let's mention what the just-in-time administration concept means. So it's not recommended to have users that have permanent high privilege in the environments since obviously those serve as very valuable targets for attackers. Attackers would target those users that have permanent high privileges and would enable them to gain access to any domain resource. For this reason exactly the JIT administration concept was introduced it means that users will not have permanent high privileges in the environment. However at any stage if a user requires high privileges to perform an operation he would request those privileges if he's authorized to get them he would get them just for a limited amount of time usually just a few hours and when the time period expires the high privileges would be revoked. So if the user would need those high privileges again he would need to go through this entire process once again. So as you can see this reduces the attack surface since it makes the life of the attackers a bit harder it's gonna be harder to find a user that has the privileges of that domain admin. So while this concept was introduced to protect the environment from attackers a very similar concept can be abused by attackers in order to evade most of the detection mechanisms that are in place today. This is exactly what brings us to the malicious just-in-time concept. So what this concept means is that attackers might have limited access in the environment. However at any stage they would be able to perform a few short steps in order to regain those high privileges perform any malicious operations and then immediately erase the footprints the lethal traces from the environment that they ever had those privileges in order to to avoid all the detections that might be in place in the system. So we're going to talk about what attackers might do when they have the domain admin account in order to ensure themselves they would be able to perform a malicious general operation at any time and regain those high privileges possibly without being detected. So we'll show three scenarios to illustrate this concept. The first is the delegation scenario and then we'll discuss two concepts involving the admin as the holder object. So at this stage Eagle will discuss the first delegation scenario and I'll come back in a bit later. All right thank you Marina. How's everybody doing so far? All right we're now going to explore several malicious JIT attack scenarios but those scenarios are just the tip of the iceberg what can be done by using the JIT concept. I'd like to emphasize that the malicious JIT is just a concept which can be implemented in many different ways. So I hope the following examples will give you some ideas as a base that you can expand and develop on later on. So let's begin this section by reviewing the Tuki concept which relates to object security. So almost everything in Active Directory is an object and those objects need to be protected from unauthorized access. So there are several different security mechanisms which protects those Active Directory objects and one of the main ones is called the access control list. So an access control list is a list of access control entries or ACEs and each ACE in access control identifies security principle and specifies the access write allow the night for that account. So basically access control is a list of permissions for specific users on that object. So in addition to an access list we have something called an object ownership or an object owner. The owner of an object can modify permissions and give other users the right to take ownership or have full control over that object. So a short example would be if a user receives a new laptop from the Help this team and he joined that laptop to the Active Directory what happened behind this scene is that a new computer account object will be created and the owner of that computer account will be the user because this user was the first one created that object. The first one touches that object. In some other cases when IT staff create an object in Active Directory by default that administrator group will be the owner of those objects. So what is so special about object ownership? Well an owner of an object has a special permission which allow him to regain himself full read and write permission to that object. So basically if you are an owner of an object you can always regain yourself full permissions also we can gain this permission to other user accounts. So now that we have explored those two concepts we can move to our first attack scenario. So before giving in I would like to mention that each attack scenario we show you today is divided into two main parts. The first part will explain what steps need to be followed in order to remain persistent in environments during the time that attacker have a full domain privileges and the second stage explain what steps need to be followed in order to regain those privileges after losing the access to the environment. So let's get going by showing how attackers can adopt the malicious GIT concept and abuse the Kerberos delegation mechanism. So the first step attackers need to follow will be adding a new computer account and you're probably asking yourself so why do we need to create a new computer account we can use just an existing computer account but actually we prefer to create a new computer account because we're only creating an Active Directory object so there is no physical computer behind it and in that way the encryption key of that computer account will be generated once and attackers can then save this encryption key and this is important because we're going to use this computer account to authenticate again the domain control later on. In addition to that attackers need to change the owner of that computer account to some account that they hold on to and in our example we're going to use a malicious user just a regular domain user we created so as you see on the screen we created a new computer account which is called the client one and the owner of that computer account is the malicious user. So just to sum up we added a new computer account and changed its owner to the user account in the attacker possession. Later on also the attackers needed to save the encryption key of that computer account and we also changed the owner of that computer account so attackers can regain themselves full privileges to that computer account object. So although the attackers can regain full right new permission to that object there are a few special attributes and properties which allow which require additional permissions and additional user right and because we are showing you today the delegation scenario this malicious user will need to have a special user right so the next step will be going to the domain controller group policy and searching for a special user right which is called enable computer and user accounts to be trusted for delegation so we register our malicious user to possess this special user right we're showing you it in the GUI but it can be done easily using PowerShell or some other scripting language and now the attackers will be able to edit any delegation properties and attributes on that computer account object. All right that's all the steps that attackers need to prepare in advance in order to be ready for the malicious G2 operation so now we're going to discuss the second stage in which we will explain what steps need to be followed in order to regain those privileges so right now we have a computer account and the owner of that computer account is the previously created the malicious user account and but actually we don't have any effective read or we have read permission but we don't have any right permission on that object so the first step will be regaining our self full permission to that object after that we can edit any property of that object so we're just showing you that we added this malicious user into the access list of that computer account object. All right next step will be searching a special attribute which is called the msds allow to delegate to this attribute is basically a list of service principal names to which this specific computer account is allowed to delegate to meaning to which services this computer account is allowed to request service tickets on behalf of other users so we're going to use this computer account like a service and this computer account will will impersonate some user so it will request tickets on behalf of domain users so you can see that we added a special service principal name which is called the CARB TGT so as Marina mentioned in the intro section before a user can request specific service tickets they first need to grant themselves the ticket granting ticket and the way to do that will be approaching the CARB TGT service this is basically a service which represents the KDC the CARB ROSE mechanism so if authentication is successful the user will receive a valid ticket granting ticket with this ticket he can request additional service tickets so we added this CARB TGT service to the list and now we can use this computer account to act on behalf of other users and request approach this CARB TGT service so we're going to impersonate the administrator account so we're gonna request a ticket granting ticket on behalf of the administrator account in if everything goes well the domain controller will return a valid ticket granting ticket so meaning now attackers have full access to any resources in the domain environment for the next 10 hours and this ticket also can be renewed by default for the next seven days so with a few steps attackers are able to regain themselves full access to the domain environment so last step to complete our malicious githcon the last step will be removing footprint and removing traces so we need to remove the CARB TGT service principle name from this attribute and remove our malicious user from the access list of that computer account object so the only thing left will be this computer account the new computer account we created and the owner of that computer account which belong to malicious user so now we're gonna show you a short demo of this attack all right so don't worry if you haven't been able to follow all the technicalities we'll show a live demo which would hopefully be a bit more clear and show every single step that eagle just explained all right so as we said we have just make a we have two steps in a malicious gith scenario first of all what attackers and I do once they have the domain admin account in order to ensure that they can regain high privileges and at a later stage and what happens once they lost lost those admin privileges and they want to regain them so the first stage attackers gain that domain admin what does they need to do in order to prepare the environment for for a malicious gith operation so first of all eagle created here a new computer account called client one and as you can see the malicious user is not part of the ACL of this computer however if we examine more carefully we can see that our malicious user is the owner of this object so all we have now is just a simple computer account with a user as its owner and this computer of course is not allowed to perform the ligation so we just have a normal computer account nothing suspicious about this any user can usually add up to 10 domain computers to the domain second thing would be adding that malicious user is not a domain admin just a regular domain account that is under the control of the attackers and grant him the special permission to edit the delegation attributes of active directory objects so here we added our malicious user and by default only the administrators should be present in that group policy so what happens next is that the attackers have lost their domain admin privileges and they want to regain them by performing a malicious gith operation so now we're connected from a remote machine in hold of the attackers as the malicious user just a regular domain user without administrative privileges as you can see he cannot access the c drive on the domain controller no spells no special privileges there so we have a few tickets here in memory all the tickets are for that malicious user we're gonna go ahead and delete all those tickets from the memory right so we're gonna clear the tickets cash great so now we do not have any tickets and what we're gonna do is we have prepared a script in advance which performs our malicious operation let's go ahead and run our script real quick and see how it affected the domain controller environment so let's get back to the domain controller and let's see what happened as a result of this script so first of all we added the malicious user to the acl of that computer now granting granting him full control of that object second thing and most important is that now this computer is enabled to perform delegation you can see in the UI that you do not see any services to which this computer is allowed to perform delegation to however if we look at the attribute editor we can see that this computer is allowed to perform delegation to the care tgt account meaning we have now a computer account that is able to obtain ticket granting tickets on behalf of other users so of course the last stage would be simply getting a ticket granting ticket for an administrative account using this privilege so in order to do this we use the open source tool mit care boroughs we didn't use any windows apis and as a result we can see that we got the ticket of an administrator all right let's take a look at the files that we have in our directory as we can see we have a ccache file that was created right now as a result from us running this script so this file contains all the tickets we got as a result from running our command what we're going to do in the next stage is load those tickets from the ccache file to our current sessions memory okay so we use the mit care roles for that as well and let's take a look at the tickets we have in memory now so as you can see now we have a ticket to the care tgt for the administrative account let's see whether we can access the c drive now and we were successful now we were able to access the thank you so yeah life demos are hard but so we were able to access the c drive as that computer using that computer account so by a simple thing is using that computer account along with that special user right we were able to get an administrative ticket all we need is to just get the ticket and immediately immediately we can remove all traces for from the environment that we ever performed this operation meaning we will immediately disable this computer from performing delegation and removing the user from the acl of that computer object so we saw how you can so just one example of how you can perform a malicious due to operation get a ticket granting ticket immediately remove the footprints and then you can use this ticket along with renewals for up to a week so this was our first example now ego will discuss the second attack scenario thanks marina so technical problems are common here as you understand just a sec we'll try that again all right so have a look at the attack delegation scenario we can now move on and speak about our admin as they hold their manipulation so recently there are a lot of online buzz about how the attackers can abuse access this active directory access list and how those accesses can be used in order to elevate privileges and or remain persistent in the environment so to illustrate how access list elevation or privilege work let's look at the built-in domain administrator group if a compromised account has right permission on this group object attackers will be able to add new members as needed and get full domain access but actually all the built-in groups are protected by special mechanism which is called the admin as they hold your mechanism so what happened behind the scenes that we have a special process which is called the sd pro process and this process runs every hour on all the protected groups and their members recursively and inspect the access list of those group if for some reason there is a new entries on those access list and that's the pro process basically compare those access list against the access list which defined on the admin as they hold their object so an admin as they hold their object is just a rebel active directory object which which is its its own access list and this access list acts like a template so every time as the process run he inspect the access list of the protected groups and compares those access list against the access list of the admin as they hold their if there are any new changes to those access list he will copy the access list from the admin as they hold their object and replace the access list defined on the protected group so actually as you can see it's it's not so it's not so simple to edit or add new entries to access list of protected groups there are also sorry about that i'm a bit nervous today so there are also a non-technique which explains how attackers what how attackers can use the admin as they hold their object in order to remain persistent in the environment so instead of editing the protected group access list what attackers can do they can go and change the access list of the admin as they hold their object and in that way after one hour when the sd process runs and he will copy the new entry of that access list to all top protected groups meaning attackers will have again full access to any resources but this technique considered to be a bit noisy and because it's propagate to all the building groups so today we're going to show you a bit different technique which does not involve any editing of the admin as they hold their object instead what we're going to do is just exclude one of the building groups there are four building groups which can be excluded from the sd prop mechanisms you see those on the screen one of those is the backup operator group which is also considered to be a highly sensitive group so in order to perform this operation attackers need to search for a special attribute which is called the ds realistic attribute and exclude this group so we excluded this group from the sd prop inspection and now when the sd process will run he will bypass this specific group so now attackers can go ahead and add a new entry to the access list of this building group but they adding the only one entry only to this specific group without affecting any other building groups so it's a more stealthy technique so after adding a malicious user to the accesses of that group attackers can add themselves as a member of that group and the backup operator group provided special permissions to its members which allow them to backup any domain machine including the domain controllers so attackers can authenticate against the domain controller down the locker hard drive which also include the ntds.d file which is the active directory database and extracts from them all the necessary user accounts so performing by performing a few steps attacker can easily regain themselves again full access to the domain environment so the last step will be of course removing this malicious user from being a member of the backup operator group and that will complete the malicious read concept so now marina will present you the last attack scenario so the third and final scenario also deals with the manipulation of the admin as the holder in order to gain persistence so in this step all the attackers might do when they have that domain admin account is simply change the owner of the admin as the holder object so here we're changing the owner of our malicious to our malicious user that we used before just a regular domain user not a domain admin so what brought us into looking into this owner attribute so one of the other steps that attackers use to gain persistence in the environment was simply by adding a new domain domain admin account to the environment however since high privileged group memberships started to be monitored it's not that easy to get away with the new domain admin this is why now there was a lot of talk about how attackers can gain persistence by abusing ACLs also Will and Andy gave a great talk about that at Blackhead and Defcon and so if for example you have an ACL granting you full control of the domain admins group you can get to a domain admin account in a single step by simply adding a new domain member domain admin member however as a result we have now a new bunch of new tools emerging that are scanning the environment and attempting to find any ACLs misconfiguration that might be abused by attackers this is why we took another step back and we're looking at the owner of the object which is not part of the ACL so for example if you have ownership over the domain admin group you can get to a domain admin privileges in two steps first of all you can grant yourself an access control entry giving you full control of that object and second stage simply just add a new domain admin so between those three attack techniques the owner attribute is the least monitored one and hopefully after this talk this will change so back to our example we just changed the owner of the admin as the holder object next step attackers lost their administrative privileges let's see how they can abuse the previous stage in order to perform a malicious jid operation so what they can do is that just before the SD proc process runs they would add a malicious user to the admin as the holder ACL granting him full control of the admin as the holder object since he's the owner of the objects he can add the ACL as he wants as ego explained what's going to happen when the SD proc process runs is that that this access control entry is going to be copied to all protected groups and users in the domain so now our malicious users user has full control of the domain environment specifically his full control of the domain admin group so obviously from this stage it's pretty easy to get to domain admin privileges he would simply add a new domain admin to an environment and get an administrative ticket granting ticket so in order to not raise any flags and complete entirely the malicious jid operation he would of course need to delete all traces from the environment immediately remove the traces so they would remove the malicious user from the ACL of the admin as the holder and in order to not keep that access control entry on all protected groups and users until the next time the SD proc process runs which should be in another hour they can just force the SD proc process to run which would immediately remove that malicious access control entry from all the protected groups and users so last step would be removing the malicious users from the domain admin's group so as you can see the access control entry and the group membership was present in the environment for just a few seconds which was enough for attackers to get a ticket granting ticket and potentially avoid any detection mechanisms which are scanning the environment so we showed an example about how the owner of the admin as the holder object can be abused to gain persistence but of course a similar manner in a similar manner you can use this to gain persistence by editing the owner of any protected group in the environment all right so now that we've discussed the attack techniques let's discuss some of the mitigations if you're a defender let's see what you can do in order to protect yourself from such attack scenarios so first of all we want to detect any delegation misconfiguration of course we need to monitor the group policy that enables account accounts to edit the delegation attributes of active directory objects and so we saw what this privileges does we really need to monitor this and only domain admins or administrators should be able to do this also we need to monitor the accounts that are trusted to perform delegation who are the accounts that are allowed to request service tickets on behalf of other users also of course we need to monitor the allow to delegate to attribute which states to which services exactly this account is allowed to perform delegation no reason for the pair tgt account to be present there whatsoever another important thing is that on every active directory object there is a checkbox stating that this account is sensitive and cannot be delegated what it means is that even if a service is allowed to perform delegation and request service tickets on behalf of other users it will not be able to request service tickets on behalf of those sensitive users so we we recommend to turn this on for any high privileged users in the environment in order to not allow services to use those accounts privileges also we need to monitor the admin as the holder object of course the access control list which is very important and is then copied to all protected users and groups in the domain also the owner of this object since we saw how attackers can abuse this and of any other protected group in the domain also monitor the excluded groups from the admin as the holder protection monitor they they're in cl as well why they're excluded and their access control list of course we recommend using any event logging to see whether there was a suspicious change on any active directory object so what we want you to take from this talk whether you're from the blue team or the red team is the malicious just in time concept so in which attackers may not have constant high privileges in the environment however at any stage they have the ability to regain their privileges regain high privileges perform any of malicious operations and then immediately delete all the traces in order to avoid most of the detection systems that are in place so we showed a few examples that illustrate this concept but of course it can be used and extended in a lot of similar scenarios so as a defender it's very important to be aware of any such escalation path and when you scan the environment to see whether attackers currently hold persistence of the environment don't just scan the stage in which attackers already have that domain admin account but also monitor all the stages in between which might allow him to lead to quick privilege escalation at any time all right so this is all we have time for thanks for listening guys