 Well, we have a great opportunity to see the best looking speaker. Oh, here he is. Sorry, at least that's what he tells me. So anyway, we're going to be learning a little bit about some Active Directory attacks this afternoon. Thanks. Hi, Defcon. So I'm Nikhil Mittal, and I'm going to talk about minimal rights and ACE for Active Directory dominance. So let's get started. Couple of things about me. I'm a hacker. I like to research stuff when it comes to Windows security, mostly on the user line part, that too on PowerShell, on Active Directory, et cetera. I speak. I train at conferences. I'm with pentesteracademy.com. You can find me on Twitter as Nikhil underscore MIWT. So please take a pic and tag me there. I blog regularly on labofherpenetrationtester.com. And I maintain few open source toolkits for offensive security research like Nishang. There was one, there's one for the defensive part as well, called Deploy Deception, which I released last year. I generally like to learn and research about methodologies to break into environments, of course, where I have the permissions to do so. I've previously spoken at DEF CON, of course, at Black Hat and few more conferences. So what we are going to discuss today is, this is the agenda, right? That is, we will begin with a very quick introduction to what ACEs or ACLs are when it comes to the access control model in Active Directory. Then the philosophy of minimal rights, what do I mean by minimal rights? Why are they required? Then we have a quick look at a toolkit called RACE, which I'm going to release with today's talk. Then persistence, how we can use different methodologies, commands from RACE for persistence and on-demand privilege escalation. These would be covered both for non-domain controller machines and member, both for domain controller and member machines in Active Directory. Then we look for some attacks which are specific to the domain controller. And then a quick look at defenses, past work, future, et cetera. So those of you who are not really familiar with how access control model works in Active Directory, this is how it works. When you want or a process wants to access a resource, which in the SDDL lingo is called Secureable, whenever you want to access that, your thread or process token has the following information. It contains your user sids, that's visible, right? Your user sids, your group sids, privilege information and other access information like SID, et cetera. When the process token presents itself to the target object or the Secureable, the system does the following checks. It compares with, now the system has an ACL, an access control list, the one which we are interested in right now is called DECL, which is, it's a list, it is made up of entries. Now the system checks each and every is for any particular specific allow or deny entry for your access token. It keeps checking for each entry as long as it founds either an allow or a deny. That's how basically access control model works. Now when we talk about, let's say, there's an access control entry, let's say for each and every trustee, right? The list contains entries for different trustees. Now when we talk about let's say domain admins, we say domain admins have, and we have seen that we know that domain admins have privileges or permissions over all the objects or most of the objects in a domain. So why is that? It is because domain admins have entries or aces on multiple objects, on all the objects in the entire domain, right? That is what allows domain admins to be domain admins, right, to control different objects. Now that was, I'm not going to delve deeper into how SDDL looks like or how ACLs look like, et cetera, that I saved for a longer discussion. Now once we understand that, once we know that how access control model works in Active Directory, how important aces or ACLs are, then we can begin a discussion on minimal permissions. So domain admins or other high privilege groups or users usually have full control permissions over different objects on machines or in domain. Now that's good, right? Full control is awesome, but that is something which we do not desire all the time. Why don't we stick to only those permissions which are required for a specific attack, right? For example, if you want to reset password of a domain user, do we really need full permissions or full control or generic all over that particular user object? No, we don't. And that is something what the philosophy or the methodology of minimal permissions is. We stick to whatever we require for a particular task so that we are a lot more stealthy, a lot more silent, and we can still get the objectives or the goals of our assessment or our attack or whatsoever. So for example, let's take this as an example. You want to connect to a domain controller or any machine using PowerShell Remoting. Now by default, you must be a part, a member of the local administrator's group, right? Now why is it possible? It is because administrators or the local group administrators, it has full access on the ACL of the PowerShell endpoint. We're taking just an example. It has full control over the ACL of the PowerShell endpoint to which you connect, which allows them to access it. Now what if we add permissions for a user which we control, which is our proxy user or a foothold user. We add the permissions for that particular user to the ACL of the PowerShell Remoting endpoint. But in place of having full control, which is not required here, we go ahead and selectively choose the permissions required. That is what the minimal permissions part is, right? And throughout the talk, that is something which we are going to use. We sort out what minimal permissions or rights are required to access a particular resource or a secureable object. And then we modify the permissions, get those privileges, and execute the task. We are going to avoid full control or generic all as long as possible. Now we are going to use the REST toolkit, which would be available on my GitHub repository. It is a PowerShell module, which you can use, which has a lot of functions and code, which you can use to execute the attacks which we are going to discuss. REST makes use of Microsoft Sign Active Directory module, the one which you will find on any machine where the ADR set is installed. So I maintain a mirror of that. Or you can copy it from any domain controller or any machine where the ADR set is installed. So let's get started. We are going to discuss both persistence and privilege escalation. Please note that we are not going to use any patchable exploit. There is no exploit discussion in the talk. In cases we talk specifically about modifying ACLs, we have to assume that on member machines we have the local admin privileges. And on the domain controllers, we have the domain admin privileges. So when we do the modification of ACLs and when we abuse that, in a real world assessment or during a real world attack, there is a time gap. You once have the local admin privileges, now you need to hold on to that. That is something which we are going to discuss. So please don't be disappointed that we already have those privileges. This is a persistence or a backdoor scenario which we will be discussing in most of the cases. So we'll begin with very simple, well-known techniques, not well-known ones probably, simple ones. Then we'll move on to a bit more complex ones as we move ahead. So let's pick up PowerShell, remoting the thing which we started the discussion. Now to allow code execution without administrator rights, we need to modify the permissions or the ACL of the PowerShell endpoint. If you run, for example, get PSSessionConfiguration on any Windows machine, you will get a list of all the remoting endpoints enabled on that particular box. So we are going to modify the ACLs of the default one, the default endpoint, and provide one of the users we control privileges to connect to that machine. So from the race toolkit, if you use the following command, we are trying to add or modify the privileges, sorry, modify the ACL of the PowerShell remoting on the machine specified in the computer name parameter for the user lab user. So let's have a look at its demonstration. So what we are going to do, we are going to modify the ACL of the default PowerShell remoting endpoint on a domain controller with domain admin privileges. That's what we are looking at. So we use overpass the hash to start a session as domain admin. Once we have those privileges, we can go ahead and modify the ACL on the domain controller using this command. You may get this error when you run this particular command because we modify the ACL of the PowerShell remoting endpoint for this current session. So you may get an IO operation error, which we can safely ignore. Now what we did was to modify the ACL for the lab user. Now as lab user, that is the current user for this particular machine, we can access the domain controller. You may like to keep in mind that the privileges will still be of that non-special user. So could you please give me a so what, really loud? Thank you. So we'll see what is the benefit of having privileges on a domain controller, even as a normal user. So similarly, we can go for WMI. WMI, if you know that WMI is a two-part authentication process, you must have privileges one to connect to the DCOM endpoint. Second, you must have the privileges or permissions to connect to a particular namespace. So when we do the similar stuff for WMI, we need to modify multiple ACLs for the DCOM endpoint as well as the WMI namespaces. So WMI is another method of replicating the similar attack. Now one failure which I would like to share with you is for the WMI permanent event consumers. So WMI supports permanent event consumers, which are fantastic for persistence. They persist across reboots, execute your commands with system privileges, which is desirable when you want to backdoor a target machine. Now when I tried the same stuff with modifying the ACL of the root subscription namespace, which is used by the permanent event consumers, it was possible to create permanent events, but it was not possible to get a command execution out of it. So if this interests you, you may like to explore this further. Or if you really have used WMI, you really know it well, you may like to correct me later on. Now what if you would like to have on-demand privilege escalation? That is, we have persistence with privileges. For example, the two scenarios we saw, PowerShell, Remoting, and WMI, in that case, we did not have local admin privileges or administrator privileges with persistence. What if you would like to have the persistence along with high privileges? In that case, one very useful option is using or abusing Windows services ACLs. Now ACLs have their own, sorry, services have their own ACLs, right, or security descriptors. We can modify that as well to get backdoors or persistence with administrative privileges. Now unlike the WMI and PowerShell Remoting part, which no one really cares about, there is minimal logging. Other than the access logs, there is absolutely no logging by default when you modify ACL of a PowerShell Remoting endpoint. But of course, in case of services, this is not going to be the same. This is a bit, not a bit, this is noisy in the logs as simple as that. Now there could be a plethora of services which are interesting. Service control manager or SCM is the one which is of the interest, which is of the interest, right? SCM provides, this is the service manager, right? It provides the ability to create, configure, start, stop services. So if we have generic all, so in this case, we need generic all. If we have generic all permissions on the SC manager service, we can create, config, start, stop services, which means that we can, for example, we can create a new service which runs a system and a user which we control has the permissions to start and stop the service, right? Or we can simply go ahead, create a service and provide a user V control, generic all permissions on that particular service. What would that mean? That means the user V control can modify the configuration of the service, make it run a system, and change the executable path of the service to run the payload we desire, right? That is something which we are doing here. We provide a user, once again, we are going to use lab user as our proxy user all the time. We provide lab user rights which are equivalent to what the built-in administrators have on SC manager on the target machine. That's one. Then we create a new service, EVL-SVC, for example, which runs as local system. And lab user has permissions to start it or configure it, right? Once the service is started, there is another user. You can use the same user or another proxy user to the local administrator's group. So really not silent, but that is the easiest way you can abuse the services, right? Now, if you use SC manager, creating a service is still a lot more noisy than simply reconfiguring a service. So in place of that, what we can do, because we are assuming the local administrator privileges on the target machine, we reconfigure an existing service and provide our proxy user, all permissions on that particular service, so that our proxy user can reconfigure the service, run it as system, and point it to the payload we want, right? So that is the service permissions issue. Let's have a look at this one. So we start a partial session with privileges of a user who is a local admin on the target machine. We load up the race toolkit and modify the ALG service on the target machine so that the user lab user, which we control, has the permissions to change whatever we want on the target service. So here you can see that the SDDL of the ALG service has these entries for the built-in administrator's group, right? This BA stands for the built-in administrator here. So what we simply did was to copy that entry and provide it to one of the users which we control, right? Once that is done, then as lab user, we go ahead and run the following command as the user for which we modified it. So we run it, and we change the configuration of the ALG. How could we do that? Because we modified the SDDL or ACL of the target service. So although the service start failed, let's try to access the target machine now using PowerShell Remoting because by default we need administrative privileges for that. So we run this. We can successfully connect to the target machine. Just to be sure, let's have a look at the membership of the local administrator's group there. You can see that our current user, our proxy user, has access to a member of the local administrator's group, right? Now, we have seen two interesting methods, three interesting methods. So PowerShell Remoting and WMI provides two of the ways to access a machine. Third one is Remote Registry. Now, Remote Registry is not enabled by default on the desktop OS like Windows 10, but it is enabled on the server versions of Windows. We can use, Registry stores a lot of interesting information. It provides you command execution privileges remotely. For example, we can abuse the permissions on well-known auto-runs keys to get command execution. Now, you will like to notice that not only the domain objects, but services and registraries have permissions as well. So as a very simple example, we can modify ACLs of the popular or the infamous remote registry key, which allows us to connect to Remote Registry even without having local admin privileges. And then we modify the permissions of the image file execution key. What does this mean? With this command executed on any target machine, this is the famous sticky keys option, right? I chose this as a very simple example. You modify these keys on a machine. The command also disables NLA. If you use MSDSC or RDP to connect to this machine, you will get the login prompt. And then you press Shift keys five times, and you will have your payload executed as a system. That's what it does. Very famous. Probably may be detected by some antiviruses. Even that is possible. But I chose this one because this is an example, which is the most easiest one to understand. Now, when we discussed WMI, I say that WMI is a two-part authentication. We need to be able to authenticate to the Decom endpoint as well as to the namespace. Now, if we are already modifying the ACLs of the Decom endpoint, why don't we use that to execute commands on the target machine? That is exactly what this particular command does. You modify the privileges or ACL of the Decom endpoint, and then you can run command on that particular machine using Decom. There is no need to modify ACLs of any namespace whatsoever. Now, another interesting option, when it comes to PowerShell Remoting, Microsoft introduced JEA, which is also pronounced or called as JAW, just enough administration a few years back. Now, JAW, which is a DSC technology, what it does is it is useful for allowing non-admins to do admin tasks. And how does it happen, how it works? By default, anyone connecting to the JAW endpoint using PowerShell Remoting will have admin privileges. Regardless of what privileges they have in the domain, on the domain machines they will have, whosoever is connecting to the JAW endpoint, will have local admin privileges, and on the domain controller, they will have the domain admin privileges, which doesn't sound right. But the access is controlled by the number of commands or commandlets they can run. Whenever you configure a JAW endpoint, you need to define a role capability. That role capability severely limits what commands you can run on a target machine, even with admin privileges. For example, let's say you just want to provide restart permissions to a group or a user. You can simply expose just a single commandlet, restart dash computer with a single parameter called, let's say, dash force. That is the type of control which JAW provides you. So as I said, for domain controllers, the domain admin privileges you get are limited to the domain controller. You cannot access any network resource with those privileges. Now, how are the privileges provided to anyone connecting to the JAW endpoint? There is a virtual user created for every connection. Now, the problem, of course, is if you specify asterisk while defining the role capability file, it is possible to expose all the commands, not only the PowerShell commands or commandlets, but also the built-in commands, the executables. That can also be exposed on a JAW endpoint. Because we are discussing a persistence mechanism or on-demand privilege escalation with persistence, what we are going to do, we are going to create or register a new JAW endpoint, which allows everything, every command, every command led to anyone who connects to that particular endpoint. And the results are terrific or terrifying, depending on what side you belong. So once again, if we have administrative privileges on a machine, on a member machine, or on a domain controller, we can create a new, remoting endpoint or a JAW endpoint. And then we can simply go ahead and connect to this. Here you can see that in place of normal ENTER-PS session and the computer name parameter, we are also adding a configuration name. This is the name of configuration which gets added onto the target machine. Are there any logs? Not at all. This is as silent as it can be. Of course, there will be access logs all the time, a 4624 and a 4634. And that would be for this virtual user, right? So it would still be possible to track you if someone is looking at the access logs. Other than that, there are, I mean, access logs are there even if you run NAT user slash DOM. So that is something which is not very, doesn't really stand out. Now let's have a look at its demo. So what we are going to do here is we are going to create a JAW endpoint onto the domain controller so that when we connect to it, we get local admin privileges on the DC, right? So we run this on the DC. Here you can see that we create Microsoft PowerShell 64 config. Then when we run this particular command, as the user which we control, we can see that we can access the DC. Let's have a look at our privileges. So we are running as this virtual user. And if we have a look at our privileges, those are useful for local administration on the DC, but not useful for accessing any network resource, right? So this is very useful and very silent. So now we can go ahead. The registry stores a lot of interesting credentials as well. So what we can do by modifying permissions for multiple registry keys, we can go ahead and extract credentials from them. What are the credentials stored in registry? Machine account hash, local users hash, domain cache credentials. So right now, we are going to make use of a code from Damp Toolkit. That's what included in the Race Toolkit as well. So by using following commands, we can access or we can extract information from the registry. Now to answer the so what, which I asked you guys to shout, if even if remote registry is not running on the target machine or it is filtered out on the firewall, we can simply go ahead, modify the PowerShell Remoting ACL, then we can run the commands to extract credentials from the registry without having domain admin privileges. And what is the least which we can do with the machine account hash of the DC? At least the DC sync attack, right? So I think I'm running out of time, so let's skip past the demo. Another interesting group is DNS admins. DNS admins is basically the domain admin if you are running DNS service on your domain controller. It is also not a part of the protected users group. So we can either modify the ACL of the domain, the DNS object, or the DNS admins group is not a protected group. And we can have our privileges back. This is very specific to the DC, right? Same goes for the DSRM admin, which is the built-in administrator on the DC, the local administrator on the DC. Its logon behavior is controlled with a particular registry key, which we can modify the permissions to. So once we have the machine, the local account hash, let's define the permissions, then we can modify the permissions of the registry key, the logon behavior, and we can access the domain controller as a local admin. Same goes for the resource-based constraint delegation part, the RBCD, right? Exchange groups are also very interesting. Exchange groups are not part of the protected groups. Their ACLs are not protected by admin SD holder. So we can modify the ACL of the Exchange Windows Permissions group, which itself has rights to modify the ACL of the domain object. So by using this cascading effect, we can actually run attacks like at least DC sync on the domain object, right? So I need to skip pass through this one actually. Then there are some well-known ones, like user object ACL. We can modify the ACL of a user object to reset its password or to force set an SPN of the user and then curb roast it. Or we can modify the permissions of the admin SD holder. This is very well-known, right? Or we can run the DC sync attack by modifying the ACL of the domain object itself. This is also very well-known. Finally, we can run the DC shadow attack. If you have not used it, this is very well-known for us for this mechanism. By default, you need domain admin privileges to run the DC shadow attack. But it is possible to use minimal permissions. We can filter these permission to run DC shadow without having to have privileges. So this is a summary of whatever we have discussed. So this is more of a reference slide for those who did not attend the talk so that they can come back and have a look at it later on. Now, this is not something which was discovered just months back. The minimal permissions have been in use for so long that when I was researching, I found articles at least which date back to 2001 where they discuss the ACLs of the decom endpoint. So in slide notes, we will find that there is one for decom from 2001, another one for WMI from 2002. And there was some phenomenal work which is in French. I think this was in 2014. A couple of years back at DEF CON, there was a very excellent presentation about decal backdoors. In fact, DC SYNC and admin S.T. Holder are one of some of the attacks which these guys discussed in much detail. Now, of course, event logs are our best bet when it comes to detecting these attacks other than, of course, protecting your domain administrators or local administrators, right? If someone would not have that access in the first place, these attacks would not be possible. By default, ACL modification has no detection at all. Even though, even if you enable it, it is easier for the domain objects for services, WMI points, for official remote points, it is still hard to detect these attacks or best. Other than that, as we discussed earlier, access logs are the best things which you have 4624 and a 4634 in case of a non-admin access, 4672 in case of an admin access, right? You can refer to this document or this article from Microsoft to have a look at why or how to detect ACL changes. The tools which we can use for ACL auditing other than logging, Bloodhound, of course, AD ACL scanner and Ping Castle, you can use all of these three, anyone which you want to detect or to audit ACLs. And also a shameless self-flood, you can use Deploy Deception, the tool I wrote, to create Deploy users and objects which have interesting ACLs to trap or deceive an attacker using that, right? So for future work, what we have, what I have not explored is, when you change service permissions, those are stored in the Windows registry. So that would be a very interesting part to discover or to have a look at. As we discussed earlier, WMI Permanent Event Consumers, not really successful, I was not really successful with that, but that may be an interesting point. For the race toolkit specifically, I have not worked on hiding the ACs once we have modified the ACL, that would be an interesting part. More registry utterance would also be really interesting. So that would be all. Please fire your questions right now or you can contact me on Twitter or on my email. That would be all.