 This is red versus blue, modern active directory attacks and defense. I'm Sean Metcalf. What's up, DevCon? You guys having fun? Who here wants to see some cool active directory attacks? All right, let's get into it. So I'm the CTO of Dance Solutions, a company that provides Microsoft engineering solutions and a lot of cool security stuff. I'm one of about 100 Microsoft certified masters in the world in active directory. And I do security research, specifically in active directory and the Microsoft enterprise. I post this information at asecurity.org. Who here has checked out that blog? Awesome. Thank you. And I speak occasionally now. So we're going to get right into the agenda. I'm not going to add a whole lot of fluff. If you've been in another presentation that I did, I'm not going to belabor the point. But basically we're going to jump in and we're going to look at what attackers are doing once they get on the network. So we know that malware is getting on systems on the network, right? It's easier to spearfishing users. Users click on everything. So we're going to start not with that, but once the attackers on the network and what they do at that point. And then I'm going to talk about some defensive techniques that are practical and that can be used to defend against these sort of attacks. So we've got to start with red team, right? What is the red team after? What are the attackers after? What motivates them other than maybe sharks with freaking laser beams on their heads? I don't know. I'd go for the raptor. So PowerShell is being used as an attack method. We know this. PowerSploit has been around for a while. I actually saw it at one hotel after a con. There was a Mimicat, invoke Mimicat screen up on the kiosk. So yeah, we know PowerSploit is being used. Just this Tuesday at B-slides Las Vegas, 6-dub and HarmJoy released PowerShell Empire. This thing is a beast. If you haven't heard of it, check it out. Effectively, this is one of the new post-exploitation tools that if you're a red team or you're going to be using. So when an attacker gets on the network, are they going to port scan? Not anymore. Port scanning is too obvious, right? We look for a bunch of different IPs. We connect to some random ports. Maybe we get a banner back. Maybe we don't. This information is an active directory. We don't even need to do port scanning. We just ask the domain controller, hey, tell me all of your SQL servers. And where are they and what port are they running on? The DC says, sure, here you go. That's my job. So all I need to do as an attacker is request this information and I'm going to get it. Because the service principle name, or SPIN, is what's needed for a service to support Kerberos authentication. I'm pretty sure that just about every application on the network now, at least if it's a service running on a server, supports Kerberos. So we can find this through SPINs. So what can we find using SPINs? I've listed a few here. But if you've heard of PowerShell remoting, it leverages WinRM. We can look for the WSMAN SPIN. What about FIM, or front identity manager? A lot of environments are deploying this in order to manage groups. FIM has a SPIN. And guess what? We can search for it. We can use PowerShell to find these things. We can PowerShell for it. We can also look for these service accounts. So if I know there's a SQL server running as a service account on the network, I can find it. I go, hey, Mr. Domain Controller, please tell me all of the user accounts in this environment, in this Active Directory forest that have service principle names. These service principle names include the server name, includes the port if we're talking about SQL, maybe some of the others, or the instance name. And what do you think I'm going to do with this information? I'm going to attack it. So I'm going to use a tool called Kerberos, which was released at DerbyCon last year by Tim Medine. It's a Python based cracking tool. So as an attacker, I get code on a system that has Domain User logged on. I am that Domain User now. I'm going to request from the Domain Controller a service ticket. Ticket granting service, TGS, whatever you want to call it, a service ticket. I'm going to get that service ticket. That service ticket, I was only able to get because I asked for a specific service principle name. That spin is associated with an account. Why is that? Well, that service ticket is encrypted using that service account's password data. Following? So now, I can attempt to guess that password, and if I can guess that password, I can open up that ticket. No elevated rights are required. I don't need to be an admin. I don't need to touch a DC other than just doing normal user stuff. And there's no traffic sent to the target. This is all normal Active Directory stuff. So at the top, I'm going to send a PowerShell command, say Domain Controller, I need a service ticket for this service principle name. And at the bottom, you can see that I get this ticket. I export this ticket from memory. I'm a user. I have access to my own memory space. Because that's where my tickets are. So I export this to a file. Then I'm going to send this file up to a server that I have running on, I don't know, AWS or Azure or something like that. As long as I got some power behind it, I can go ahead and crack this ticket. When I crack the password for this ticket, I know the password for the service account, which means I own that service account. Why is that possible? How long are service account passwords? Exactly the same as the domain minimum. So if the domain minimum is eight characters, my service account passwords, well, they might be ten, but probably eight. And if I'm lucky, the domain password minimum is 14. That's pretty easy to crack, especially if I'm using like a Bitcoin rig. So what's the mitigation of this? Longer character passwords. You have to make the passwords longer. I'm sorry, blue teamers. I'm sorry, admins of services, but you have to do that because you don't want your service account to be the reason why your entire domain has gotten compromised. There's a new feature called managed service accounts that Microsoft put out there with earlier versions of Windows, I believe it was 2008 R2, 2012, which is where the active directory and domain controller itself actually changes those passwords. Now, if you want to detect this, it's going to be a little bit difficult because if I'm a sneaky attacker, I'm going to just ask for a couple of service principle names every so often. How are you going to notice that with this flood of 47, 69 events that are coming in? Then there's group policy preferences. Red teamers love group policy preferences. Microsoft released this with Windows Server 2008, well, a while ago. A few years ago, someone realized that while the password data, the credentials for group policy preferences was a 256-bit encrypted, Microsoft published the private key on MSDN. Really? My guess is this was for third-party interoperability because Microsoft gets trash when it comes to that. So as an attacker, what do I do? I scan SysFall, I run through and I look for XML files. I'm going to check those XML files and look for a C password attribute. When I find that C password attribute, that blob of data that's in quotes after that is the AES encrypted blob of data. That is the password. All I've got to do is run an AES decrypt function against it and I have the password. That's a pretty good password. Note to self I've changed my password now. Once an attacker has that information, how are they going to leverage it? How is group policy preference typically used? Well, most of the time, from what I've seen, it's been used to change the local admin password for a large number of computers. But we've just given the attacker that data, which means that they are effectively the local admin on hundreds if not thousands of computers. What can they do now? Well, Microsoft Windows is very friendly, very helpful. So if I have a computer over here and the local admin account and password is the same as the computer on here, local accounts, they can go ahead and communicate. I can log in over here and then connect the resources over here as an admin. So the whole local thing is a bit of a misnomer. So as far as group policy preferences, we need to make sure that we're not using it to store credentials anymore because we know that they can be reversed very easily. Installing this patch will prevent someone from typing in the credentials, which means it won't be stored in SysFall anymore. But that doesn't remove it from SysFall. So you have to actually scan and then pull that data out. Detecting this, the best way that I've seen is setting up an XML file, dropping it in SysFall, actling it so that no one can access it, and then audit it to see who's trying to access it. And then you get a good event on your domain controller. As far as preventing the pivoting of an attacker once they get a local admin account, there's two different approaches to this, or two parts to the ultimate solution. One is making sure that password is randomized and unique on every computer in your environment. It's been a big challenge. We thought that, you know, at least group policy preferences would help us along with that. It doesn't. So Microsoft released a tool in May called LAPS. It's decent, it works. Better than nothing. There's a couple of others that are out there that are pay or free. But the other thing you can do is deploy KB2871997, which is effectively a back port of the security features and functionality from 2012 R2 and Windows 8.1. And what that does is it adds a couple of new local SIDS on those computers. And you can use those local SIDS in a group policy where you say local users cannot log in over the network. That just makes sense. The other thing is we need to stop allowing workstation to workstation communication. Our networks are very flat. Attackers love this. I can spear fish a user over here and then I can connect over here to the president's workstation. I can access the server over here. I can access this over there. We need to stop with the flat networks. And ultimately what we need to do is identify where our sensitive data is. Does it make sense for any random user on our network to be able to access the back end HR server, finance server, badge system? So Mimicats. Everyone knows Mimicats. You can read. Dump credentials, dump curve roast tickets, inject those tickets, use them, forge golden and silver tickets. This is what it looks like. You've never actually seen it. So the Windows developers thought it was a great idea in order to make sure that if a user ever got prompted for credentials that they could just go ahead and handle that request from memory. So the clear text password, or at least a reversible version of it, was placed in LSAS. That protected space and memory. So you can see there's passwords there. And on the left side is a user account. It's actually Han Solo. He's a great server admin. Nice guy. But his credentials are now stolen because he's logged on recently into the server. But worse than that, any service that's running on the system with explicit credentials, meaning that they were typed in or they were configured within some sort of tool, are exposed here also. So if you have services running as domain admin on work stations, in this sort of scenario, your whole domain is going to be compromised after one work station, or maybe a single server is compromised. So what do attackers do to get the credentials for AD? Well, one, they can look for that nts.did file, that act directory database, or they can grab a domain admin's credential. So how do they find this? Backups. We have to back up our domain controllers, right? We don't want them to fail and then not be able to recover. We have corruption that could happen. Sometimes users delete, or admins delete users, and we want to make sure we can recover them. So where's the domain controller storage? Is it on a NAS or a SAN or some other device that has a bunch of hard drives in it? But let's talk about the virtual environment. I'm not going to ask people to raise hands, but I'm sure that most environments now have at least one virtual DC. It saves money, it's efficient. But are you considering that your virtual admins are effectively domain admins? Are you treating this such? Because in VMware, all I need to do as a VMware administrator is clone of virtual DC, take that clone DC VM, I don't have to start it, and I copy down the storage associated with it to my computer. So guess what I have? I have a DIT. So the other thing that's interesting is if I'm an attacker and I drop myself on a server, very sensitive, I don't want to run some hacking tools on it, I can just use Task Manager to then dump the LSAS process to a file. And once I have that, I can copy it off somewhere else, and I can use Mimicaster or another tool to then crack that open and get the credentials from it for whoever was logged on to memory at that time or recently. And if it's a domain admin, then I own the domain now. This is what it looks like once I get those credentials and I dump the domain. In red is a default administrator account for the domain, and then the next one that's in yellow is the CurbTVT account. So now I can create golden tickets. But there's a tool called NTSU-Till that administrators use for Active Directory. So if I have a whole bunch of DCs I need to stand up quickly or if I have a DC that's in a branch office and it's failed and I need to stand up a new one, what am I going to do? I run DC promo and it has to copy the data from the DC and the headquarters. Or I can run NTSU-Till, create an IFM, install a media set, and copy that over to that server and then when I run DC promo I just point to it. And it seeds that DC promo process with a copy of the database. So now it just needs to copy down the deltas over the wire. Well, what's interesting about this is that's the ntsus.dit file, has the system hive, has a security hive, so this key's in there. So if I'm an attacker and I really want to own this domain and I can't get access to a domain controller or something else, maybe I can get on that server because it's not yet a domain controller. It's probably not protected at the same level as a domain controller. Or maybe some enterprising domain admin said, you know what, let's just do an IFM set and let's put it up on a share and that way we can use it for when we were promoting our DCs. Well, if I'm the attacker and I get that, I now own that Active Directory environment because I can do one command in Kali using the impact of Python tool and dump it. Now I have the curb TGT account password hash so that means that I can create golden tickets. Just Sunday, Benjamin Delphi tweeted this post, DC sync. I'm sure a lot of people were very interested as far as what this does. Basically this says when you run it as a domain admin in the environment, you go, hey, I'm a domain controller, can I have the password hashes for curb TGT please? And guess what happens? The DC provides that information. What else does it provide? It provides the history of the passwords for that user. So right now it's one user at a time but I think it's pretty easy to power shell it and get some very interesting accounts. Yeah, personated domain controller to get password hashes? I agree with Brad Pitt. That's pretty bad. So the detection of this is kind of difficult but the mitigation is pretty straightforward. At least it seems fairly obvious. It's not easy to do in an environment but what we need to ensure we do is protect our admin credentials. We need to ensure that our admins are logging on only specific systems. We need to limit where these credentials are stored or placed so that way we don't end up with them all over our network. And at this point we need to seriously consider if you're not already doing it, special admin work stations specifically for your admins. Be they domain admins or server admins, even work station admins. But we cannot continue where domain admins are logging on to the same sort of systems as everyone else. November of last year Microsoft released an out of band patch for a serious Kerberos vulnerability in the way that the domain controller validated the pack. Now the pack is privilege attribute certificate. It's the way that the group membership information is stored within that Kerberos ticket. And so the domain controller wasn't actually properly validating this meaning that an attacker could modify a ticket and say I'm a domain admin, I'm an enterprise admin. That's kind of a problem. So try explaining that to an executive. So I love Gavin Millard's analogy where you have a boarding pass when you're getting on a plane before you get there, you take a sharpie, you write pilot, you hand it over to the flight attendant and say oh welcome captain come on over, here's the cockpit. Have a seat. Would you like coffee before we take off? It's exactly what this is. Basically going from a domain user to a domain admin in about five minutes. So what's the exploit? Well there were exploits in the wild when Microsoft released this patch. Two weeks after the patch there was a Python tool for this, PyCat. I believe it was the first, I know Golden Pack came out around the same time and there's been a couple others since then. But what it does is it requests ATGT of that authentication ticket from the domain controller. It says I don't need a pack, don't put one in there. Then it creates a forged pack saying domain admin, enterprise admin, pretty much all the good stuff. And then sends back the TGT from the DC and that forged pack as an authenticator and goes here you go. DC gets all confused with the service request and goes whoa wait a second. You have a TGT, no pack, you have an authenticator. I'll tell you what, I'm going to dump that TGT, I'm going to create a new one and put that forged pack into it and give it back to you. Golden ticket done. So Benjamin Delphi earlier this year updated his Keckio suite with a tool that exploits this and he proved on a little bit. It actually scans and identifies vulnerable DCs in the environment. So if you thought you were safe with kind of a herd protect mentality that doesn't work. So vulnerable DCs don't have the patch. It finds it, checks with one, gets an error, checks with another one, gets an error, checks another one, gets a success. Golden ticket. The other thing that Keckio does that's very interesting is he added a step at the end where it takes that TGT with the forged pack which is only viable, it's only usable against that DC that's vulnerable, it's not patched. And now it uses that and requests a delegation ticket. So now it will work on any DC. So you have one DC that's unpatched, it doesn't matter. We can pass that ticket to another one. So yeah, Kitty Kat says use your admin in five minutes. The response to this is simple. Make sure your server build, your server image includes this patch. Because if you stand up at DC that's not patched against this, you will get owned. Very quickly. Highly recommend you add a step just before you run DC promo as part of your QA where you check for this hot fix. You don't get that result back, don't run DC promo. So now the cool death con part, right? Was anyone here that was at my black hat talk a couple days ago? This wasn't in it. This is new. So I'm going to talk about some sneaky active directory persistence tricks. What happens when an attacker gets admin access to a demand controller for five minutes? Now an attacker can do an infinite number of things, right? We all know that. Kind of, we have no idea what's being done. But there are a finite number of pathways. I'm going to talk about a couple of them. One's on the left. So directory services restore mode. See a hand. Anyone know what this is? Excellent. You ever changed the password for it? You ever used it? Okay, a couple. So this is the break glass account for active directory. It's actually a local admin account for a domain controller. That sounds odd. The password is set at DC promo and doesn't change after that. And the process to change it is mostly manual. Probably the best way to change it is with server 2008, it now supports syncing with an account in active directory. So you can see in that white box I have an account called the SRM text test. I've dumped it with Mimicat so I can see what the account password is and at the bottom I've actually done a SAM dump so that way I can see what the administrator account on the domain controller's password is. The same. That's interesting. How can I use that? Well, in order to log in and use these DSRM creds, I have to reboot DSRM. It's directory services restore mode. That was 2003, 2000. But in 2008, I can now set a reg key to one. Well, I have to stop the active directory service. I don't want to do that. So I set it to two. Now I don't have to stop it. But I still need console log in. Remember that DSRM was developed in 2000. What's changed? We can now log in over the network. Console is no longer just on the console in that server room anymore. We have virtual machines, virtual clients. We have lights out capability, out of bound capability. We have network KBMs. So if it is an attacker, I still have access to that. And I've changed the DSRM password, I can still get into that domain controller. On to that file system and do whatever I want. So make sure you change your DSRM passwords. There's another interesting way that was updated in Mimicast last year called the security service provider, SSP. So if we modify this or if we add our own to the list of SSPs that are there, then we can actually interact with LSATs. The SSP is a way to plug in a new authentication method into Windows. So if we inject in either memory or we update a registry key and drop a DLL on there, whenever someone logs on to this box, it gets saved to a file, including the domain controller computer account password and any service account data that runs on it, service account credentials. Well, that's interesting but if we save that file to where LSATs is, I'm not going to be able to access it to the main user if I get dumped out as an admin. How can I get access to this? So let's talk SysFall. In SysFall, you have this share that's accessible to every domain user, every authenticated user. And this is what a group policy template file looks like in one of these random group policies. What if I redirect my SSP to point to that location? Now as a domain user, I can get access to all the password data and credentials of those who log on to ADC. Skeleton key earlier this year, Dell Secureworks identified in memory malware on some domain controllers at a customer site where LSATs was patched in real time. And what this meant was that the attackers had their own master password they could use for any user account. So if this room is the active directory domain and everyone in here is a user, you have your own individual password. You're logging in, you're doing your work, you're doing everything you need to. Me as the attacker, I've dropped Skeleton key on this domain controller using Mimicats and I can log on as you. In this example, I show at the top I've logged on as admin with one password and then I've logged on as admin with another password. Now let's talk SID history. SID history is a legacy capability that Microsoft added so that in a migration scenario where you have an old domain and a new domain, you have a user that's moved from the old domain to the new domain, they can still access the resources in the old domain. How do they do this? They said well, the old domain user has a SID, the new domain user has a SID. That's creating an attribute called SID history and just take that SID from that old user and put it in there. So when that user logs on, all the SIDs are evaluated as to whether or not they should have access to a resource and then based on that data they get access or not. So what's interesting about this is why it was originally intended to work across domains or across forests, it actually works in the same domain. So I can inject the default administrator account SID into the SID history of any user I want. So I use Boba Fett because that's the one I created because he's a spy. And so here you can see a quick PowerShell example of what Boba Fett's member group membership is, member of his blank. And then Boba Fett's SID is 3103 and just below that is the Dash 500 account for the same domain. So that's interesting, that probably shouldn't happen. Well it shouldn't because now Boba Fett can log on to a workstation, PowerShell remote to a domain controller and when running who am I on that, it shows it's Boba Fett logged on. And now through PowerShell remoting we can run Mimicats to dump the CurbDT account, password hash. So this just came out a couple of weeks ago, Jared Atkinson developed a custom WMI class and normal usage looks like Netstat. But it actually enables arbitrary command execution such as PowerShell code. So again I can run Mimicats as a user on this box but it runs a system and there's no Mimicats that shows up in the task manager in the process list because it runs under the context of WMI. So I worked with Casey Smith soon after that. He was a big help, he wrote a custom provider for me because I said hey we're really great if this custom WMI provider would enable remote access for a domain user and then run system on the domain controller. And so we did that. So you drop a DLL in the box, you run PowerShell script and so I'm system even though I'm logging in as a user and here you can see again I can execute Mimicats.exe on that box or another PowerShell command that I want. I know it's a little difficult to see but at the bottom it says I'm Joe user. But this command runs a system on the domain controller. The task list, this is part of WMI. WMI supports this. Supports remote execution. So this pops up for about 30 seconds and it disappears. So you probably have known some of this but let's talk about PowerShell Empire for a minute. I'm really impressed with this because it's a PowerShell based rat with modules including Mimicats. So we can do it all through PowerShell. So if I get access to a domain controller or an admin server, an admin jump box, whatever you want to call it. I can use PowerShell Empire and inject into a process of my choosing the PowerShell listener for Empire. And what's highlighted here is LSAS. I can also dump credentials and pull that back. Very sneaky. So how do you protect against these things? The SRM, you got to change the passwords. SSP, you're going to look for this registry configuration. Skeleton key, there's some interesting ticket encryption data that shows up. You'll want to start scanning your user accounts for any interesting SID history and then looking at WMI to see what's out there, what's available. And these custom WMI providers have WMI methods that are quite unusual. Matt Graber and his colleagues are actually talking about WMI persistence and some interesting things and how to detect this further tomorrow at one o'clock. Highly recommend you see that. But ultimately it comes down to protecting your AD admins. So golden tickets are forged TGT, that authentication ticket I mentioned earlier. And so what's interesting about this is because I've created that TGT locally, I don't have to ask the DC for it. It's going to create it. So any login restrictions or anything else like smart card is required isn't going to be in that TGT because I'm not going to put that in there. So I can be anyone I want, if anyone's access, impersonate anyone. I can say I'm the janitor but I have access to all the groups that the CEO and the director of R&D have. But there was a bit of a limitation with this, so to speak. If you know having access to wherever you want the domain can be called a limitation. And a multiple domain act directory forest. If we dump the curb TGT account password hash in that domain and the enterprise admin group is not hosted by that domain, then this golden ticket is bounded by that domain. It won't provide admin rights to another one. But I did some research on this and figured out that if we added SID history to it, I reached out to Benjamin Delpy, he added this to MiniCats. We add SID history to the golden ticket and now can cross that domain boundary because of what I talked about earlier. This is inside of an act directory forest. I can say I'm an EA from a child domain when I communicate or connect to resources in other domains. And it works. Silver tickets are probably the misunderstood younger brother of golden tickets. What's interesting about silver tickets is while they're forged service tickets and they're limited to that scope of that service on that box, I can still be an admin, but what's really interesting about it is there's no communication with the domain controller at all. Because I've created that service ticket that's encrypted by that password data for that service count on that server. So if you're not looking at service or your security event logs on your servers, you're only looking at DCs, you're going to miss this. In certain scenario, silver tickets can be more dangerous than golden tickets. Well what might that be? Every computer account and act of directory has a password. When you join a computer to the domain and associate a computer account that's created for that computer and has a password changed about every 30 days. Well if the attacker dumps the domain credentials for the entire domain, they now know all those credentials including the domain controller computer account credentials, computer account password hash. So even if Corp IT changes all the user and the admin and the service account passwords and the Curb TTT twice, they still have the domain controller computer passwords. If they haven't changed, I can do this. I can take a silver ticket, create a silver ticket for the HTTB service for that domain controller and it's encrypted with that domain controller's computer account which means it's valid for that service. It's going to open it up. I'm saying I'm a domain admin. Then I'm going to create another silver ticket for WSMAN. What are these two cover? WinRM and PowerShell Remoting. So now I can take my silver tickets, PowerShell remote to the DC and dump the Curb TTT account password hash, those taking my silver tickets and turning them into golden tickets. Let's talk about problems with trusts. So I presented last month on Kerberos trust and how Kerberos tickets work across them. When you have the blue domain controller, blue domain and the green domain and you want users in the blue domain to access green domain resources, the blue domain admin creates a password, types it in, sends it over to the green domain, domain admin and they type it in and the trust is created. Well that password is typically shared over email or something like that and it doesn't change for 30 days. So if an attacker can get access to that, I can forage a cross-forest TTT saying that I am whoever I want to be in the blue domain and provide that information to the green domain. Once I do that, I can access whatever I want on the green domain provided it's been accoled for users or groups in the blue domain. This gets really interesting when you talk about an active directory forest scenario where you have multiple domains. So if I compromise the blue domain in this active directory forest, I can create a trust ticket jumping over to the green domain, say I'm a domain admin, I'm an enterprise admin and it'll accept it. So detection of this. Earlier this year I came up with some anomalies, discovered some anomalies with the domain fields within these events on the bottom. Mimicast was updated in late April and now you have this attribute on the bottom, this field on the bottom. So these indicators don't work as well as they used to but they may still work. But I'll talk about a different way that you can potentially detect this and do a pretty good job of it. So let's talk blue team. I know the computer defense often feels like 300 versus 300,000. I'm not going to ask the blue teamers in the room to raise your hand because that would just be wrong. When we have what, 16,000 people at DEF CON, how many are blue teamers? Smaller percentage probably. Let's talk about how we can defend against these attacks. Starts with PowerShell attack detection. It starts with logging your PowerShell activity. How do you do this? You've got to get PowerShell version 3 out on all your computers. Enable PowerShell module logging, be a group policy. Once you do this, you'll start getting events that show up in the PowerShell log and the PowerShell operation log of what commands are actually being run in your environment. And from this information which you can feed into your SIM tool, you can look for some really interesting activity. Attacker activity in PowerShell usually starts with .NET web client download, invoke expression, encoded command, which is a base 64 encoded command of PowerShell, and some others. So I highly recommend that you start looking at who is remoting to your servers. Tracking and ultimately limiting who is accessing PowerShell over a remote session, which leverages WinRM. You can do this by adjusting the WinRM listener scope on the server. So that way, say you have exchange, you're not going to be able to kill PowerShell loading on that. What you can do is you can adjust the PowerShell listener, which is the WinRM listener, to just a few admin subnets. You'll want to track who's actually remoting in your system. You're going to look at the events that are triggered or logged by that, and then audit and meter PowerShell usage. You can audit it by using AppLocker in auto mode, or you can track and meter PowerShell usage with something like SCCM software metering or something similar. Because if you realize that Joe user was running PowerShell on like 10 different computers in what, two hours? That could be a problem. But the story gets better with PowerShell version 5, which based on a tweet I saw this morning from Microsoft should be out later in Q4, so probably in a few months. Of course, if you want it today, you have to install Windows 10, but I don't think anyone's that daring, except for maybe me who put Windows 10 on my presentation laptop, so I like to live in here. So let's start with CrippLock logging. What's great about this is that encoded command that I mentioned earlier, where even if you had PowerShell logging enabled, it would just give you what that encoded command was. Which doesn't really help when you're trying to create similar. What's great about this is it actually logs the final command that is executed by PowerShell. So PowerShell de-opiscates, decrypts, decodes whatever that command is, and passes it over to the processor. When it does that, it logs that. So now we can create some really interesting alerts in our sim tool. Also, we get system-wide transcripts, which means that all activity the users are doing on every computer can get logged to a transcript file. Historically, you just had one little transcript for this activity or whatever and couldn't capture everything. So we can create a group policy to have this data go to a share, which we can accl so that users can access it, but they can be copied, the data can be copied up there but not deleted later. And we can ingest that information into our sim tool, such as Splunk or something else, and create alerts on it. And get good information like what the host application was. So if we have host application equals word.exe or excel or something like that, that could be a problem. I don't know about you, but I don't usually run PowerShell from word or excel. So there's also constrain PowerShell, which I think is really interesting. Constrain PowerShell language mode or constrain language mode PowerShell, something that's been around for a couple years, but there hasn't been a lot of information on how to leverage it. It is core PowerShell, which means that the advanced techniques that attackers typically use and leverage won't work because they won't have the .NET functionality and the more advanced functionality that is available within PowerShell by default. So constrain PowerShell locks it down to that core component. This gets enabled automatically if you have app locker and allow mode when you have PowerShell version 5 on your clients. And then in Windows 10, the story gets even better because you get the anti-malware scan interface, which means that before any code gets executed by PowerShell, it gets kicked over to the AMSI, the anti-malware scan interface, which means that whatever anti-malware software you have installed is actually going to check that code and PowerShell is not going to execute it until it gets a status okay. This is pretty strong for blue teamers in about five years from now when Windows 10. But at least we're moving in the right direction, right? Because stuff like invoke, uh, Mimicast is not going to work off the web. It's not going to work when run locally because it's going to be blocked by this. And it's going to be blocked by either code snippets or, uh, signatures or even URL reputation. So you might even be able to block PowerShell execution from GitHub, for example. But maybe not Bank of America. So to summarize some of the mitigation that I've been talking about, this is what I call low complexity level or low implementation level. It starts with making sure that users aren't adventants. Seems really obvious. Unfortunately, we use group, we love group nesting in Active Directory. We use it all the time. And because of group nesting, we end up with this group and that group and this group and that group. And it's a spider web. And so we end up with a situation where people don't really know what this group is for anymore or what it was delegated to. And so we go ahead and put people in it where we add another group and then all of a sudden we have like 500 domain admins. I don't hear anyone laughing so I'm guessing that's a true story. Followed up by nervous laughter so I'm really concerned now. So the other thing or the other part of this, these mitigations is making sure that the admin accounts are protected but also your service counts as I mentioned earlier. And a good way to protect your admins is to look at RDP restricted admin mode. Which is where when an admin logs in or RDPs into a server their credentials aren't actually stored in LSAS over there. That interactive login is turned into a network login. Which means there's no credentials in LSAS to be stolen there. So we move on to level two, moderate and we start again with a randomizing computer local admin account passwords protecting our service count admins or our service counts hardening those up. Basically we need to push back on our vendors because whenever a vendor has come into your organization what do they always say the rights that are required for your service count. Domain admins, exactly. What do we say? Okay. You have this product. I want this functionality. Yes, of course. Where do I sign? But it's usually because the developers have not fully tested this product with anything but domain admins. And it may be domain admins for that initial install. So we also want to make sure that our service counts are limited in scope and that we don't have service counts that are running as domain admins everywhere. We need to limit where they're running. So if we have service counts that are running in domain admins we don't want them running on workstations. So level three it's complicated. It starts with emptying your domain admin group. We cannot use domain admins anymore. It's way too powerful. Anyone want to guess where domain admins came from? Windows NT. Who loves Windows NT? Domain admins is 1990s mentality. It's 1990s thinking. It's the 1990s approach to managing an enterprise. I love the 90s. Sure. But it's time to move on. We need to look at what the roles are that our admins actually need and not just put them in domain admins. I've been in customer sites where there were a lot of different groups that were in domain admins that never did anything with active directory administration. So we need to separate these out. We need to protect them. We need to drop the level of rights down. We need to clear out domain admins. We need to ensure that service count are not members of groups that they don't need to be members of. And we need to make sure that domain admins are only logging on to domain controllers, special admin servers, special admin workstations and also look at that for the lower tiers as well. The lower tiers being server admins and workstation admins. Because once an attacker compromises a domain admin account, it's over right? We also should be looking at temporal group membership. I'm sure that there's some domain admins here in this room. You're in Vegas, partying, you're at DEF CON. You're not back working. Your domain admin account is still active. So we need to look at ways to limit our surface, our attack surface for these accounts. Network segmentation is part of this, as I mentioned earlier. At least in Windows 10, we have some really great protection. Well, I went to the Microsoft presentation at Black Hat a couple of days ago. And it sounds like there's a bunch of requirements, which is going to take a couple of years for us to get there. But again, at least we're moving in the right direction. So what has traditionally been the Windows OS is now moved into the blue box. The high level OS sits on a hypervisor. We now have a new micro kernel called isolated user mode, IUM, or virtual secure mode, VSM, or whatever Microsoft wants to call it today. That's that green box. That's that micro kernel. No third party code runs in it. And the only way that the regular OS can communicate with it is through trustlets. These are really small purpose built processes which run within the IUM, or within that scope. So there's the credentials, or at least what we're used to being credentials, those secrets are no longer in LSAS. They have been moved over to a new process in the IUM or VSM called LSA-LSO. Microsoft rehearses this in the Oracle because LSAS can request the information, but never the secrets are divulged over to LSAS. So it's going to be really interesting to see how this develops and how well this works in practice as we start rolling this out again, and hopefully two to three, four, maybe ten years. So as the attackers approach has become more sophisticated, I'm not going to use the advanced word. More sophisticated, we need more sophisticated attack detection. Microsoft recognize this and they're doing a better job. They bought a product or a company called a Rado late last year. They have taken and integrated this company's product and technology into a new tool or a product called Microsoft Advanced Threaded Analytics which is coming out this month or is out already. I don't work for Microsoft but I find this very exciting because finally we're looking at things from where we need to look at them. This doesn't look at event logs. There's no event log parsing, there's no agent to be installed, this is a straight up tap the network device in front of your domain controllers, it watches the authentication traffic to and from that DC and gains real intelligence about where users are logging on and what they're doing. That ATA sensor data is sent over to the ATA center and then it's crunched and then there's some user behavior analysis that's that's extracted out of this. And it says this user logs onto these two computers and these four resources is what they access but that's it. So if any user steps out of that lane its flag is abnormal but what's interesting about this is that's user behavior it's got deterministic behavior or deterministic detection as well on the bottom of the slide you can see the detection capability a lot of the advanced attacks I said it I know. Sophisticated attacks that we're seeing now are the ones that I've listed at the bottom which ATA can can help us identify including recon which is not going to show up in your event logs. So I'm up for looking at a new solution apparently if you have an enterprise cow and software assurance with Microsoft if you're a big enterprise you may actually already own this so you might want to look into it. But this is what it looks like credential theft detection pass the ticket over pass the hash the MS-1406 exploit because it can identify the communication patterns and behaviors for that. Golden ticket skeleton key and some others. So there's a couple more mitigations that I recommend again mostly common sense but now we need to start looking at if we're in a breach recovery scenario that we change our computer account passwords as well as all the others. We need to change our current TTT account password at least when an act directory admin or domain admin leaves. But the fact of the matter is that we need to change them on a fairly regular basis I put twice a year here but maybe once a year because if someone pulls that backup file they have this account. So in summary attackers will get code running on your system at some point. So what they're able to do how far they're able to get what data they're able to access what level of privilege they're able to attain is entirely based on your defensive posture and it's time for us to change our defensive posture from the way that we've been doing for the past 10 to 20 years. Thank you very much for your time that has been mine.