>>This is Red vs Blue- modern active directory attacks and defense. 
I’m Sean Metcalf.  What's up, DEF CON?
  [ Cheers and applause ]
  Guys having fun?
  [Applause]
  Who here wants to see some cool attacks?
  Let's get into it.  I'm a CTO of DAn Solutions, a company that provides Microsoft engineering solutions lot of cool security stuff.  One of about 100 Microsoft certificate fights masters in the world in active directory.  I do security research specifically in active directory and Microsoft enterprise.  I post this information, who here check the out that blog?
  Awesome.  Thank you.  And I speak occasionally.  So, we're going to get right into the agenda I'm not going to add a lot of fluff.  You've been at other presentation that I did, I'm not going to belabor the point basically we'll jump in we're going to look at what attackers are doing once they get on the network.  We know that malware is getting on systems on the network, right?
  Easy sphere fish usee.  Click on everything.  We're going to start not with that but once the attackers on the network and what they do at that point.  Then I'm going to talk about some defensive techniques that are practical and that could be used to defend against these sort of attacks.
  So we 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 laser beams on their heads, I don't know.  I'd go for the raptor.  Powershell is being used as an attack method we know this.  Has been around for awhile.  Actually saw it one hotel after a Con there was a mimikatz screen up on the kiosk.  So, yeah, we know power Sploit is being used.  Just this Tuesday in Las Vegas harm joy released Powershell empire.  This thing is a beast.  You haven't heard of it check it out.
  Effectively this is one of the new post exploitation tools that if you're red team or going to be using.  So, when an attacker gets on the network, are they going to porch scan?
  Not any more.  Porch scanning is too obvious.  We look for a bunch of different IPs connect to random ports, get a banner back, maybe not.  This is in active directory we don't need to do porch scanning.
  We just ask the domain controller, hey, tell me all of your sql servers and where are they and what are they running on?
  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 Spn needed for a server to support 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.  We can find this through SPNS.  What can we find using Spns I've listed a few here.  But if you've heard of Powershell remoting it leverages Win RM.  We can look for the SPN what about FIM?
  Lot of environments are deploying this in order to manage groups.  Fim has a SPN guess what we can search for it.
  We can use Powershell toe find these things.  We can Powershell for it.  We can also look for the service accounts.  If I knew there's a SQL Server running a 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.  The 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 concern bears which was release -- kerberos.  A python-based cracking tool.  As an attacker, I get code on a system that has domain user logged on.  I am that domain user now.  I am 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 specific service principle name.  That SPN is associated with an account.  Why is that?
  Well, that service ticket is encrypted using that service accounts password data.  Following?
  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.  There's no traffic sent to the target.  This is all normal active directory stuff.  So, at the top I'm going to send -- going to send a Powershell command say, the 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.  To a file.  Then 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 password, it might be ten, probably eight.  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.  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 version of Windows I believe it was 2008 R2, 2012.  Which is where the active -- domain controller itself actually changes those passwords.  If you wanted to detect this it's difficult if I'm a sneaky attacker I'm going to ask for a couple of service principle names every so often.  How are you going to notice that with this flood of 4796 events coming out.  Then there's group policy preferences.  Red teamers love group policy preferences.  Microsoft released this with Windows server 2008.  Awhile ago.  Few years ago someone realized that while the password data, credentials for group policy preferences was ARES 267 encrypted.  Microsoft published the private key on MSDN.  My guess is this was for third party interoperability because Microsoft gets trashed when it comes to that.  So as ab a attacker what do I do, I scan Sys Fal I look for XML files.
  I'm going to check those files look for a C-password attribute.  When I find that attribute that blob of data in quotes after that is the AES encrypted blob ever data.  That is the password.  All I've got to do is run an EA 1 function against it and I have a password.  That's a pretty good password.  Note to self, I have to change my password now.
  Once in a an attack 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 local admin password for a large number of computers.  But we've just given the attacker that data which means that they are effectively local admin on hundreds if not thousands of computers.  What can they do now?
  Well, Microsoft Windows is very friendly, very helpful.  If I have a computer over here and the local admin account, password is the same as computer on here, local accounts, they can go ahead communicate I can log in over here then connect to 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 because 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 SCYFAL.  They have to Stan then pull that data out.  Detecting this, the best way that I've seen setting up an XML file dropping it in Sysfal.  Then audit it to see who is trying to access it.  Then you get good event on your domain controler.
  As far as preventing the pivoting of an attacker once they get a local admin account, there's two different approaches to this.  Two parts to the ultimate solution.  Make sure password is randomized and unique.  It's been a big challenge.  We thought that at least a group policy preferences would help us along with that.  It doesn't.  Microsoft released a tool in May called laps, it's decent, it works, better than nothing.  There is a couple others that are pay or free.  But other thing you can do deploy KB2871997 which is effectively a back port of the security features and functionality from 2012R2 and Windows 8.1.  Couple of new local Sids on the computers.  You can use those local Sids in 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 work station to work station communication.  Our networks are very flat.  Hackers love this.  I can spear fish user over here then I can connect over here to the president's work station.  I can access the server over here, I can access the server there.  We need to stop with the flat networks.  Ultimately what we need to do is identify where our sincetive 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.
  Mimikatz, everyone knows mimikatz.  You can read.  Dumb credentials, dumb tickets, inject those tickets, use them, forge golden and silver tickets, right?
  This is what it looks like.  You never actually seen it.  The Windows developers thought it was a great idea in order to make sure that if user ever got prompted for preR credentials just go ahead handle that request from memory.  So the clear text password or reversible version much it was placed in LSAL that protected.  You can see there is passwords there.  On the left side is user account, actually Hans Solo, nice guy.  But his credentials are now stolen because he's logged on recently to the server.  But worse than that, any service that's running on this system with explicit credentials they were typed in or configured within some sort of tool, are exposed here also.  If you have services running as domain admin on work stations, in this sort of scenario, your whole domain will be compromised after one work station or maybe single server is compromised.  What do attackers do to get the credentials for ad?
  Well, one, they can look for that file that active directory database.  Or they can grab a domain admin's credential.  
  How do they find this.  Backups.  We have to back up our domain controllers, right?
  Don't want them to fail and then not be able to recover.  We have corruption that could happen, some time users delete or admins delete users make sure we can recover them.  So, where is the domain controller on Az or San some other device that has a bunch of hard drives in it.  Let's talk about virtual environment.  Not going to ask people to raise hands I'm sure that most environments now have at least one virtual, saves money, efficient.  But are you considering that your virtual admins are effectively domain.  Treating them as such.  Because in VMware all I need to do as VMware administrator is clone a virtual DC, take that clone DCVM I don't have to start it, I can copy down the storage associated with it to my computer.  So, guess what I have.  I have a dip.  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.  The process.  To a file.  Once I have that I can copy it off somewhere else and I can use mimikatz for another tool to then crack that open get the credentials from it.  For whoever was logged on to memory at that time or recently.  If it's a domain admin then I own the domain now.  This is what it looks like once I get the credentials and I dump the domain.  In red is the default administrator account for the domain.  The next one that's in yellow is the account.  Now I can create golden tickets.  But there's a tool called NTS2 that administrators use.  If I have a whole bunch of BCs I need to if I have DC in branch office and it's failed I need a new one, what am I going to do?
  I run DC promo it has to copy the data from the DC in the headquarters.  Or I can run create an IFM install from media set copy that over to that server then when I run DC pro.  It sees that promo process with a copy of the database.  Now just needs to copy down the deltas over the wire.  What's interesting about this, that's the file, system hive, has a security hive.  SYS keys in there.  If I'm an attacker 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.  Probably not protected at the same level as domain controller or maybe some enterprising domain admin do an IFM set let's put it up on a share that we can use it for when we're promoting our DCs.  Well, I'm the attacker I get that I now own that active directory environment because I can do one command and use impact of the python tool and dump it.  Now I have the account, I can create golden tickets.  Just some day Benjamin Delpy tweeted this post.  DCSync, I'm sure 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 this please?
  Guess what happens, the DC provides that information.  What else does it provide?
  It provides the history of the passwords for that user.  Right now it's one user at a time but I think it's pretty easy to Powershell it and get some very interesting accounts.
  Yeah, domain controller get password hashes, I agree with Brad Pitt, that's pretty bad.  So, the detection is kind of difficult, but the mitigation is pretty straight forward at least it seems fairly obvious.  Not easy to do in an environment but what we need to ensure we do is protect our admin credentials.  Need to ensure that our admins are locking on only specific systems.  Need to limit where these credentials are stored or placed so that way don't end up with them all over our network.  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 we cannot continue where domain admins were 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.  Now, the pack is privileged attribute certificate, the way that the group membership information is stored within that kerberos ticket.  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 plaining that to an executive.  I love Gavin Miller's analogy where you have a boarding pass when you're getting on a plane, you take a sharpie and write "pilot" and hand it over, oh, welcome, captain, come on over, here is the cockpit, have seat.  Would you like coffee before we take off?
  Exactly what this is.  Basically going from a domain user to a domain admin in about five minutes.  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.  Py cat.  I believe the first, I know golden pack and been a couple of others since then.  But what it does it requests ATGT that authentication ticket that says, I don't need a pack, don't put one in there.  Sure, here you go.  Then it creates a forged pack saying, domain admin enterprise admin, pretty much all the good stuff.  Then sends back the TGT from the DC and that forge pack has authenticator goes, here you go, the DC gets all confused with the service request goes, wait a second, you have a TGT, no pack, you have authenticator I'm going to dump that TGT create a new one put that forged pack into it and give it back to you.  Golden ticket.  Done.
  Benjamin Delpy earlier this year updated his suite with a tool that exploits this he improved on it a little bit.  It actually scans and identifies vulnerable DCs on the environment.  So, if you thought you were safe with kind of a hard protect mentality that doesn't work.  Vulnerable DCs, don't have the patch.  It finds it.  Checks with one, gets an error.  Checks with another one, gets an error.  Success, golden ticket.  The other thing that Pecio 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, only usable against that DC that's vulnerable.  And now it uses that requests a delegation ticket.  Now work on any DC.  So you have one DC that's unpatched, doesn't matter we can pass that ticket to another one.  So, yeah, response to this is simple.  Next year server build, server imagine 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 DEF CON part.  Anyone here that was in my Black Hat talk a couple of days ago this wasn't in it, this is new.  I'm going to talk about some sneaky persistence tricks.  What happens when an attacker gets admin access to domain controller for five minutes.  Now, do any number of things, we all know that.  We have no idea what's being done, there are a finite number.  I'll talk about a couple of them, the ones on the left.
  >> inventory  services restore mode, see hands, anyone know what this is?
  Excellent.  Ever change the password for it?
  Ever used it?
  Couple.  This is the break glass account for active directory it's actually a local admin account for domain controller.  That sounds odd.  The password set at DC promo 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 now supports syncing with an account in active directory, you can see in that white box I have a account called DSRM test, I can see what the account password is at the bottom I've done a Sam dump that way I can see what the administrator account on the domain controller password is, they're 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 in DSRM, directory services -- that was 2008 I can now set Reg key to one.  I have to stop the directory service, I don't want to do that.  I said it to to I need console log in.  Remember the DSRM was developed in 2000.  What's changed?
  We can now log in over the network, console no longer just on the console in that server room any more.  We have virtual machines, virtual clients.  We have lights out capability, out of band capability, network KBMs so if an attacker, I still have access to that I change DSRM password I can get into that domain controller on to that file system do whatever I want.  So, make sure you change your DSRM passwords.
  There's another interesting way that was updated in mimikatz last year called the security service provide, SSPf, if we modify this or if we add our own to the list of SSPs that are there, then we can actually interact with LSAS.  The SSP is way to plug in a new authentication method into Windows.  
  If we inject either memory or we update registry key drop a DLL on there, whenever someone logs on to this box they get saved to a file.  Including the domain controller computer account password any service account data that runs on it.  Service account credentials.  Well, that's interesting, but if we save that file to where LSAS is I'm not going to be able to access if I get dumped out at domain admin.  How can I get access?
  So let's talk SYSfal you have this share accessible to every domain user, every authenticated.  This is what a group policy template file is 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 a DC.  Skeleton key, earlier this year, Dell secure works identified in memory mall way on domain controller at a customer site where LSAS was patched in realtime.
  What this meant was, the attackers had their own master password they could use for any user account.  So if this room is the active directory domain everyone in here is a user, you have your own individual password, you're logging in, you're doing your work, doing everything you need to.  Me as the attacker I drop skeleton key on this DC as mimikatz I can log on as you.  This example I show at the top I've logged on as admin with one password.  Then I've logged on as admin with another password.
  Now let's talk sid history.  It's a legacy capability that Microsoft added so that in a migration scenario where you have an old domain and 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?
  Well, the old domain user has a sid, the new has a sid create attribute called a sid history.  When that user logs on all the Syds are evaluated as to whether or not they should  have access to a resource then based on that data they get access or not.  What's interesting about this while 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 --  through the sid history of any user I want.  I use -- he's a spy.  So here you can see a quick Powershell example of what Bobafet's group membership is, member of is blank.  Is 103 just below that is the account.  That's interesting.  That probably shouldn't happen.  Well, it shouldn't because now Bobafet can log on to a work station, Powershell remote to domain controller running who am I on that, it shows it's Bobafet logged on now through Powershell remoting we can run mimikatz to dump the account.  This just came out a couple of weeks ago, Jared Atkinson developed a custom W-my class normal usage looks like net stat.  But it actually enables arbitrary command execution such as Powershell code.  So again I can run mimikatz as a user on this box, but it runs a system and there's no mimikatz shows up in the task manager.  The process list.  It runs under the context of W-my.  I worked with casey Smith soon after that, he was a big help he wrote a custom provider for me because I said, hey, would be great if this custom W-my provider would enable remote access for domain user.  Then run system on the domain controller and so he did that.  You drop a DLL in the box, you run Powershell script.  I'm system, even though I'm logging in as a user.  Here you can see again I can execute mimikatz.EXE on that box or another Powershell command that I want.  It's difficult to see.  At the bottom it says I'm Joe user.  But this command runs system on the domain control.  The task list this is part of Wmy, WMY supports remote execution.  This pops up for about 30 seconds and it disappears.
  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 mimikatz.  We can do it all through Powershell if I get access to a domain controller or admin server, 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.  What's highlighted here is LSAS.  I can also dump credentials pull that back.  Very sneaky.  So, how do you protect against these things?
  DSRM you have to change the passwords.  SSP look for registry configuration.  Skeleton key there's some interesting ticket encryption data that shows up.  You want to start scanning your user accounts for any interesting sid history.  Then looking at WMY to see what is out there, what's available.  These custom Wmy providers have WMY methods that are quite unusual.  Matt Graber and colleagues are talking about WMY how to protect this further tomorrow at 1:00.  Highly recommend you see that.  Ultimately comes down to protecting ad admin.  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.  Any log in restrictions or anything else like smart card is required.  Isn't going to be in that TG because I'm not going to put that in there.  I can be anyone I want, spoof anyone's access, impersonate, I could say I'm the janitor but I have access to all the groups that the CEO and director of R&D have.
  But there was bit of limitation with this so to speak.  Everything access to wherever you want domain can be called a limitation.  Multiple domain directory forest if we dump the TGT account password hash in that domain the enterprise admin group is not hosted by that domain this golden ticket is pounded by that domain it won't provide admin rights to another one.  But, I did some research figured out that if we looked at sid in history,  I reached out to Benjamin Delpy, he added to mimikatz.  It now can cross that domain boundary because what I talked about earlier.  This is inside of active directory.  I can say I'm an EA from a domain, when I communicate or connect to resources and 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 limit to that scope that have 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 on that serve.  If you're not looking at service -- your security event logs on your servers, only looking at DCs you're going to miss this.  Certain scenario, silver tickets can be more dangerous than golden tickets.  What might that be.
  Every computer account and active directory has a password, join a computer to the domain, associated account is created, it has a password change about every 30 days.  If the attacker dumps the main credentials for the entire domain, they know -- now know all those credentials including the domain controller computer account credentials, password hash.  So even if change all the user and admin and service account passwords and TGT twice, they still have the domain controller computer passwords.  If they -- they haven't changed I can do this.  I can take a silver ticket, create a silver ticket for the HTTP service for that domain controller it's encrypted with that domain controller account which means valid for that service.  It's going to open it up.  I'm saying I'm domain admin.  Then I'm going to create another silver ticket for WS man, what are these two cover?
  Win RM and Powershell remoting.  Now I can take my silver tickets, Powershell remote to the DC and dump the curb TGT account thus taking silver tickets turning them into golden tickets.  Let's talk about problems with trust.  I presented last month on kerberos trust and how kerberos tickets work across them.  When you have blue domain controller, blue domain and green domain and you want users in the blue domain to access green domain resources, blue domain admin creates a passwords, types it in.  Sends that over to the green domain, domain admin they type it in.  The trust is created.  Well that password is typically shared over e-mail or something like that.  It doesn't change for 30 days.  So if an attacker can get access to that I can forge cross force TGT 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 Ackled for users or groups in the blue domain.
  This gets really interested when you talk about active directory forest where you have multiple domainsf 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 domain admin, I'm an enterprise admin.  So detection of this.  Earlier this year I came up with some anomalies, discovered domain fields within these events on the bottom.  Mimikatz was updated in late April, now you have this field on the bottom.  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.  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 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.  Start with Powershell attack.  It starts with logging your Powershell activity.  How do you do this?
  You've got to get Powershell version 3 on all your computers, Powershell module logging, be a group policy.  Once you do this, you'll start getting events that show up in the Powershell log in 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 interesting activity.  Attacker -- usually starts with web client download, invoke expression.  Encoded command.  Which is bay 64 encoded command of Powershell.  And some others.  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 in or out.  You can do this by adjusting the win RM listener scope on the server, that way, say you have exchange, not be able to kill Powershell on that.  You can adjust the Powershell listener which is the win RM listener, to just a few admin subs, you want to track who is remoting in your system.  Look at the events that are triggered or logged by that.
  And then audit meter Powershell usage you can audit it by using app locker in audit mode or track and meter Powershell usage with something like SSCM software meet are or something similar.  If you realize that Joe user was running Powershell on like ten different computers in two hours, that could be a problem.  But the story gets better with Powershell version 5.  Which based on tweet I saw this morning from Microsoft should be out later in Q4.  Probably in a few months.  Of course if you want it today you have to install Windows 10 but I don't think anyone is that daring except me who put Windows 10 on my presentation laptop because I like to live dangerously.  Start with script lock logging.  The command I mentioned where if you had Powershell logging enabled it would just give you what that encoded command was.  To create Sim alerts.  It actually locks the final command that is executed by Powershell.  Powershell, decodes whatever that command is and passes it over to the processor when it does that it logs that.  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 just had one little transcript for this activity or whatever couldn't capture everything.
  We can create a group policy  to have this data go to a share which we can Ackle so users can access it but they can be copied, data can be copied up there but not deleted later.  We can ingest that information into our sim tool and create alerts on.  If we had a host -- that's could be a problem.
  I don't know about you but I don't usually run Powershell from excel.  There's also constrained Powershell which is really interesting.  Constained Powershell language mode or contrained language mode something that's been around a couple of years, but there hasn't been a lot of information on how to leverage it.  It is core Powershell which means that advance techniques that attackers typically use and leverage won't work.  Because they won't have the .Net functional that is available within Powershell by default.  Constrained Powershell locks it down to that core component.  This gets enabled if you have app locker in allow mode when you have Powershell version 5 on your client's.  Then in Windows 10 the stories gets better you get anti-malware scanner before any code gets executed by Powershell, it gets kicked over to the AMSI, the anti-malware scanner device which means that whatever anti-malware software you have installed is actually going to check that code and Powershell not going to execute it until it gets status okay.  This is pretty strong for blue teamers.  About five years from now with Windows 10.  But at least we're moving in the right direction, right?
  Because stuff like invoke mimikatz not going to work off the web, not going to work when run locally.  Because it can be blocked by this.  Can be blocked by either code snippets or signatures or even URL.  Block Powershell execution from GitHub.  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.  Starts with making sure that users aren't admins, really obvious.  Unfortunately we use group, love group nesting using it all the time.  Because of group nesting we end up with this group and that group and this group it's a spiderweb.  And so we end up with a situation where people don't really know what this group is for any more or what it was delegated to.  We go ahead put people in it where we add another group all of a sudden we have like 500 domain admins.
  I don't hear anyone laughing I'm guessing that's a true story.  Followed up by nervous laughter.  I'm really concerned now.
  The other beginning or other part of these mitigations making sure that the admin accounts are protected because also service accounts as I mentioned earlier.  Good way to protect your admins to look at RDP restricted admin mode.  Which is where when an admin logs in or RDPs into a server their credentials aren't stored in LSAS over there.  It's turned into a network log in.  Which means there's no credentials in LSAS to be stolen there.  We move on to level two, moderate.  And we start again with the randomizing computer local admin account passwords.  Protecting our service account admins, service accounts.  Hardening those up, basically we need to push back on our vendors because whenever a vendor comes into your organization what do they say the rights that are required for your service account.  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, may be -- may need domain admins for that initial install.
  So we also want to make sure that our service accounts are limited in scope and that we don't have service accounts that are running as domain admins.  We need limits where they're running.  Level three, it's complicated.  It starts with emptying your domain admin group.  We cannot use domain admins any more.  It's way too powerful.  Anyone want to guess where domain admins came from?
  Windows NT.  Who loves Windows NT?
  Not me.  Domain admins is 1990s mentality.  It's 1990s thinking approach to managing an enterprise.  I love the '90s.  Sure.  Time to move on.  We need to look at who the roles are that our admins need not just put them in domain admins.  I've beein in customer sites where there were lot of different groups that were in domain admin, is that never did anything with active directory administration.  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 account 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, work stations and also look at that for lower tiers as well.  Lower tiers being server admins and work station 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, in Vegas, partying, you're at DEF CON, you're not back working.  Your domain admin account is still active.  We need to look at ways to limit our attack surface for these accounts.  Network segmentation is part of this.  I mentioned earlier.  In Windows 10 we have some really great protection.  I went into the Microsoft presentation of Black Hat couple days ago, and it sound 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 is traditionally been the Windows OS now moved into the blue box.  High level OS.  Zits on a hypervisor now have a new micro kernel called isolated user mode, IUM or whatever Microsoft wants to call it today that's that green box, micro kernel, no third party code runs in it and the only way that reg  can communicate with it is through trust.  These are small purposes built processes which run within the IUM.  Or within that scope.
  The credentials 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 the SM called LSALSO.  Because LSAS can request but never the secrets are divulged.  Be interested to see how this develops and works in practice as we start rolling this out hopefully two to three, four 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 recognized this and they're doing a better job.  They ought a product or company called Lorado they have taken integrated this company's product and technology into a new tool or product called Microsoft advanced  threat 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, no agent to be installed.  This is a straight up tap the network device it watches the authentication traffic to and from that DC and gains real intelligence where users are logging on and what they're doing.  That ATA sensor data send over to the ASA center and then it's crunched then there's some user behavior analysis that's extracted out of this.  It says, this user logs on to these two computers and these four resources is what they access but that's it.  If any user steps out of that lane it flags that.  What's interesting that is user behavior it's got deterministic behavior or deterministic detection as well on the bottom of the slide you can see the detection capability.  Lot of the advanced attacks -- sophisticated attacks that we're seeing now are the ones that I've listed at the bottom which ATA can help us identify.  Including recon which is not going to show up in your event logs.
  If you have a big enterprise you may actually already own this.  Might want to look into it.  This is what it looks like.  Credential theft detection.  Pass the ticket, over pass the hash.  MS1406 exploit because it can identify the communication patterns and behaviors for that.  Golden ticket.  Skeleton key.  And some others.
  There's couple more mitigating -- again mostly common sense but now we need to start looking at if we're in breach recovery  scenario that we change our computer account passwords as well as all the others.  We need to change our TGT password at least when an directory 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.  Maybe once a year.  Because if someone pull, is that back up file they have this account.  In summary, attackers will get code running on your system at some point.  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.  It's time for us to change our defensive posture from the way we've been doing.  Thank you very much for your time.  That has been mine.
  [ Applause ]