>>So, hi and welcome to our talk: “Here to stay- Gaining persistence by abusing advanced communication mechanisms.” I’m Marina. I’m here today with Igal. We’re both security researchers at Microsoft at the ATA group.


So today we 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, and you’re not required to 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 and orders we’re going to show a little bit later on. We’ll begin with an intro to kerberos and kerberos delegation. Then we’ll dive in into our main subject of the 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 just-in-time administration” which I’ll define a bit later on. Also, we’re going to try and go with a live demo and finally, show some mitigations and take aways from our talk. 


Alright, so let’s take a few minutes to discuss kerberos. So kerberos is a ticket-based authentication protocol. Say some domain user wants to access some communication server in the domain. How would the authentication process work? First of all, the kerberos client will issue an ask request to the domain controller, requesting a special ticket to a service called the krbtgt. 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 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 T-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 kerberos legations. First of all, why is legation needed? So it’s needed in scenarios in which an application needs to reuse user credentials. Let’s take for example the 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 scenario exa-exactly is why the delegation mechanism was introduced. It means that the web server would be allowed to delegate kerberos 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 in not a trivial functionality since it allows the servers to impersonate other users and use their, eh, user 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 the legation to a single service or a few services which were defined in advanced. 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 will focus on today. 


Alright. So let’s see how attackers can gain persistence active directory environments. First of all, just a quick look at 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-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 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 recall. They move 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 forty-eight hours, and unfortunately in a lot of times it takes even a lot less since admin credentials as you know as-are 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 here along the way. However, if all detections fail it’s very important to be aware of that last and final stage which is the 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 a domain admin not enough to already gain persistence? Well, what happens if that domain admin account is discovered and its password needs to be reset? So attackers are going to lose their high privileges and they’re going to 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 ahold 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 force down the NTD’s DIT file through the active  directory which contains all domain secrets, all the user hashes they can later on use to access any user domain resource. Also they can use the golden ticket attack in which they forge a ticket granting ticket for an administrative account and later on use it to request more service tickets and access more domain resources. Also there is the skeleton key or any other back door which can be left on the domain controller. 


So each of those has its own weaknesses. For example, replication requests using the DRS UPAI from a non domain controller machine can be detected by analyzing network traffic. Also, there’s some ways to detect crafted tickets. And to any backdoor that is left on the domain controller has own- 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’ll 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 environment since obviously those servers are 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, exact-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 will request those privileges. If he’s authorized to get them, he would get them, but 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 going to be harder to find a user that is- 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 tection- most of the detection mechanism there are 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 huge- a few short steps in order to regain those high privileges, perform any malicious operations, and then immediately erase their footprints, delete all traces from the environment that they ever had those privileges, in order to avoi-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 JIT 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 Igal will discuss the first delegation scenario and I’ll come back in a bit later. Alright.
 
>>Alright. Thank you Marina. How is everybody doing so far? Alright. So… We’re now going to explore several malicious JIT attacks scenarios, but, eh, those scenarios are just the tip of the iceberg what can be done by using the JIT concept. I 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 tic- two key concepts 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, eh, active directory object and one of the main ones called access control list. So an access control list is a list of access control entries or “ACE”s and each ACE is an access control identify security principle and specifies the access write allowed/denied for that account. So basically, eh, access control list is a list of permissions for specific, eh, users on, eh, that object. 


So in addition to an access list, we have something called 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 short example would be if user receive a new laptop from the [inaudible] esteem and he joined that laptop to the, eh, active directory. What happened behind the scene is that the 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 who created that object- the first one who touched 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, eh, an owner of an object has special permission which a-allow him to, eh, regain himself full written write, eh, permission to that object. So basically if you are an own-owner of an object, you can always regain yourself full permissions. Also you can, eh, gain permission to other, eh, user account. So now th- now that we have explored these concepts, we can move, eh, to our first attack scenario.


So before diving in, I would like to mention that each attack scenario we will show you today are divided into two main parts. The first is- part we’ll explain what steps need to be followed, eh, in order to remain persistence in environments. During the time the attacker have, eh, full, eh, domain privileges. And the second stage e-explain what steps need to be followed in order to regain those privileges after losing the, eh, access to the environment. 


So let’s get going by showing how attackers can adopt the malicious JIT concept and abuse the kerberos delegation mechanism. Alright. So the first step, eh, attackers need to follow would be adding a new computer account. And you’re probably asking yourself, “Why do we need to create a computer account? We can use just an existing computer account.” But actually, eh, eh, we prefer to create a new computer account because, eh, 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 controller later on.


In addition to that, eh, attackers need to change the owner of the computer account to some, em, eh, to some account that they hold on to. In our example, when they use a malicious user, it’s just a regular domain user, it’s-they created. So as you see on the screen, eh, we’ve created a new computer account which is called the Client One and the owner of that computer account is, eh, 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. Eh, later on also the attackers need to save the encryption key that can get into that computer account. And we also changed the owner of that computer account so attackers can’t regain themselves full privileges to that, eh, computer account object.


So although the attackers can regain full write/written permission to that object, there are a few special attributes and properties which, eh, allow, which require additional permissions, eh, and additional user right. And because we are showing you today the delegation scenario, eh, this, eh, malicious user would need to have special, eh, 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 registered our- registered our malicious user to possess this, eh, special user right. We are 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. 


Alright. That’s all the steps attackers need to prepare in advance in order to be ready for the malicious JIT 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. Alright.  


So right now we have a computer account and the owner of that computer account is the previously created, eh, the malicious user account. And- but actually we don’t have any effective, eh, read re- we have reader, eh, permissions but we don’t have any write permission on that object. So the first step would be regaining- regaining yourself full permission to that object. After that, we can edit any properties of that object so we just showing you that we edited this malicious user into the access list of that computer account object.


Alright. Next step will be, eh, searching a special, eh, attribute which is called the MSDS allowed 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 service is this computer account allowed to address service tickets on behalf of other users. So we’re going to use this computer account, eh, like a service, and, eh, this computer account will-will impersonate some user. So it will, eh, request tickets on behalf of domain users. 


So you can see that we edited a special service principal name which is called the krbtgt. So, eh, as Marina mentioned in the intro section, em, before the user can request specific, eh, service tickets, they first need to grant themselves the ticket granting ticket. And the way to do that will be approaching the, eh, s- eh, krbtgt service. These basically service trip the, eh, the KDC eh the kerberos mechanism. So if authentication is successful, eh, the user will see a v-valid ticket granting ticket with- a-and with this ticket he can address additional service tickets. So we added this krbtgt service to the list and now we can use this computer account to, uh, a-add on the behalf of other users and request, eh, eh, appropriate krbtgt service. So we’re going to impersonate that administrator account so we’re going to, eh, request the ticket granting ticket on behalf of that administrator account. And if everything, eh, goes well, eh, the domain controller will return a valid ticket granting ticket. So meaning now attackers have full, eh, access to any resources in the domain environment for the next ten 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, eh- to complete our malicious JIT concept, the last step would be removing footprint and removing traces. So we need to remove the krbtgt service principal name from this attribute and re-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 belongs to-to malicious user. 


So now we’re going to show you a short demo of this attack. 


>>Alright. So don’t worry if you haven’t been able to follow all the technicalities. We’ll sh-We’ll show a live demo which will hopefully be a bit more clear and show every single step that Igal just explained.


Alright. So as we said we have- just make, uh, duplicate- we have two steps in a malicious JIT scenario. First of all what attackers might do once they have the domain admin account, in order to ensure they can regain high privileges at a- at a later stage and what happens once they lost- lost tho-those admin privileges and they want to regain them. 


So the first stage attackers gain that domain admin. What do they need to do in order to prepare the environment fro-for malicious JIT operation? So first of all, Igal 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-a user as its owner, and this computer of course is not allowed to perform delegation so we just have a normal computer account- nothing suspicious about this. Any user can usually add up to ten domain computers to the domain.


Second thing would be adding that malicious user, who 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 a-domain admin privileges and they want to regain them by performing a malicious JIT operation. 


So now we’re connected from a remote machine in hold of the attackers as their malicious user- just a regular domain user without administrator privileges. As you can see he cannot access the C Drive on the domain controller- no spe- no special privileges there. So we have a few tickets here in memory. All the tickets are for that malicious user. We’re going to go ahead and delete all those tickets from the memory. Alright. So we’re going to clear the tickets cache. Great. So now we do not have any tickets and what we’re going to 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 happens as a result of the script. 


So first of all, we added the malicious user to the ACL of the computer, now granting the- granting him full control of that object. Second thing and most important is that now this computer is able 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 krbtgt 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, eh, MIT kerberos. We didn’t use any windows API’s. And a result we can see that we got the ticket of an administrator. 


Alright. Let’s take a look at the files that we have in our- in our directory. As we can see, we have a SKSH file that was created right now as a result from us running the script. So this file contains all the tickets we got in-as a result from running our command. What we’re going to do in the next stage is load those tickets from the SKSH file to our current session’s memory. 


Alright. So we use the MIT kerberos for that as well. And let’s too-take a look at the tickets we have in memory now. So as you can see, now we have a ticket to the krbtgt for that administrative account. Let’s see whether we can access the C Drive now. And we were successful. Now we are able to access the [applause] haha. Thank you. So yeah. Live demos are hard, but… So we were able to access the C Drive as that computer- using that computer account. So by a simple saying as using that computer account along with that special user right, we were able to get an administrator ticket. All we need is to just get the ticket and immediate-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 JIT 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 Igal will discuss the second attack scenario.


>>Thanks Marina. 


[inaudible]


>>So technical problems are common here as you understand. 


>>Just a second.


[inaudible]


>>Alright. We’re going to try that again.


[inaudible]


>>Alright. So having looked at the attack delegations, we can we can move on and speak, eh, about our, eh, admin as the holder manipulation. So recently, there were a lot of online boughts about how a-attackers can abuse access lists- active directory access lists. And how those access lists can be used in order to elevate privileges and or remain persistence in our environment. 


So, eh, to illustrate how access lists elevation of privilege work, let’s look at the building administrator group. If a compromised account has write permission on this group object, attackers will be able to add new members as needed and gain, eh, full domain access. But actually all the building groups are protected by a special mechanism which is called the the admin as the holder mechanism. 


So what happened behind this thing is that we have a special process which is called the SDPROP Process, and this process runs once every hour on all the protected groups and their members recoursery and inspects the access lists of those groups. If, eh, for some reason, there is a new entry on the those access list, eh, the SDPROP Process basically compare those access list against the access list which defined on the admin as the holder object. So an admin is the holder object is just a regular active directory object which- wis- with- its- its- its own access list. And this access list act like a template. So every time the process runs, he inspects the access list of the protected groups and compares those access lists against the access list of the admin as the holder. If there are any, eh, new changes to those access lists, he will copy the access list from the admin as the holder object, eh, and it will replace the access list defined on the protected group.


So, eh, actually a-as you can see, it-it’s not-not so simple to, eh, edit or add new entries to access list, eh, of protected groups. Eh, there-there are also, eh… Sorry about that. I’m a bit nervous today. So, eh, there also an old technique which, eh, explain how, eh, attackers what- how attackers can use the admin as the holder object, eh, in order to remain persistence in the environment. But instead of editing, eh, the protected group access list, eh, what attackers can do, they can go and-and change the access list of the admin as the holder object and in that way, after one hour when the SD Process runs, eh, he will copy the new entry of that access list to all-to all protected groups. Meaning attackers will have again, eh, full access to resources. But this technique considered to be a bit noisy, eh, 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, eh, admin as the holder object. Instead, what we’re going to do is, eh, just exclude one of the building groups. There are four building groups which can be excluded from the SDPROP mechanisms. You see those on the screen. One of those is the backup operator group which-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 dsHeuristic attribute and, eh, ex-exclude this, eh, group. 


So we excluded this group from the SDPROP 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- to the access list of speci- of this building group, but they’re adding, eh, only one entry only to this specific group without, eh, affecting any other building groups. So it’s a more specific technique. So after adding, eh, a malicious user to the access list 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 again the domain controller down the local hard drive which also include the NTD’s dot T file which is the active directory database, and extract from them, eh, all the necessary, eh, user accounts. So performing- by performing a-a few steps, attacker can easily regain themselves again full, eh, access to the domain environment. So the last step will be, of course, removing this, eh, ehm, malicious user from being a member of the backup operator group and the-tha-that will complete the malicious JIT concept. So now Marina will present you the last attack scenario.


>>Alright. So the third and final scenario also deals with ma-ma-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 is simply adding a new domain-domain admin account to the environment. However, since high privilege groups memberships started to be monitored, it’s not that easy to get away with a new domain admin. 


This is why now there is a lot of talk about how attackers can gain persistence by abusing ACL’s. Also Will and Andy gave a great talk, eh, about that at Black Ha-Black Hat and DEFCON. And so if, for example, you have a ACL granting you full control of the domain admin’s 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- a bunch of new tools emerging that are scanning the environment and attempting to find any ACL misconfigurations 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’s group, you can get any admin privileges in two steps. First of all you can grant yourself an access control entry giving you full control of tha-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 JIT operation. 


So they can do is the just before the- as the SDPROP Process runs, they would add a malicious user to the admin as the older ACL granting him full control of the admin as the holder object. Since he’s the owner of the object, he can edit the ACL as he wants. As Igal explained, what’s going to happen when the SDPROP 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 he has full control of the domain admin’s 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 JIT 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 SDPROP Process runs which would be in another hour, they can just force the SDPROP Process to run which would immediately remove that malicious access control entry from all the protected group and users. So last step would be removing the malicious users from the do-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 det-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.


Alright. 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’s 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 allowed to delegate to attribute, which states to which services exactly this account is allowed to perform delegation. No reason for the Care TG-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 even if a service is allowed to perform delegation and request service tickets on behalf of other users, it would not be able to request service tickets on behalf of those sensitive users. So we’re-we recommend to turn this off for any high privilege 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- their ACL as well, why they’re excluded, and their access control list. Of course, eh, we recommend using any VAN logging to see if there was a suspicious change on any active directory object. 


So what we want you to take from this talk whether you are 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 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 on the environment, don’t just scan the stage in which attackers already have that admin domain account. But also monitor all the stages in between which might allow him to leap to quick privilege escalation at any time. 


Alright. So this is all we have time for. Thanks for listening, guys.


[Applause]