Detecting the Elusive: Active Directory Threat Hunting

we good in the back thumbs up cool so this is detecting the elusive active directory threat hunting and i am sean metcalf i'm the founder of trimark security company a microsoft certified master and active director there's about 100 in the world i'm also a microsoft mvp i've spoken about active directory attack and defense at a number of conferences and i'm security consultant and researcher and as we just found out i run 80security.org where i post a lot of interesting security information about the microsoft platform so what are we going to talk about so i call this active directory thread hunting thread hunting has a lot of different connotations or ideas behind it but i like to boil that down to what really

do we care about we need to log the events that will actually detect unusual or malicious or anomalous activity and flow that into our sim tool whatever that may be and then configure some sort of alerting on that system so that we can get the data we need to figure out what's going on so working backwards from that what are some of the data sources that we actually need so we need some powershell logs to figure out what's going on with powershell because a lot of attackers are using powershell they're obfuscating powershell so how do we figure out when they're doing that and how do we look at attacker activity in active directory how are they moving

around how do we get information about what they're doing on windows systems and how can we detect a common attack method called kerberos thing which is what we're going to get into so i'm pretty sure everyone's familiar with something like this right any sock analysts here any people that look at these screens show of hands all right so i'm sure that when you get in the morning and you look at the screen you might as well be looking at this right where's wally the european version of where's waldo this is one of the toughest wally pictures that i've seen i thought this is a good metaphor we're looking at the event alert data that our sim is

flooding us with and we might as well be looking at this trying to figure out where wally is how do we detect the attacker among all of the noise how do we dig into this well we need some pointers we need some help so we need to go from this to this and ultimately ideally to this it's a bit of a cheat i think it's just his head right so we need to get to this point where we can see exactly where the attacker activity is or at least something that's completely unusual or anomalous in our environment so how do we figure that out oh we've got to make sure we're getting the right data like i said powershell

system security events there's specific events that we event ids that we need is this logging data properly flowing from our systems into our sim tool and are we seeing these events so we have our sim tool collecting it we have some sort of agent or whatever that's sending it to there but how do we know if those events stop flowing from sources how do we know when those events are no longer coming from systems that we expect them to and how do we correlate this to something that is useful how do we get the events that we really need to see or the alerts that we need to see it all starts with what is

normal right have we baselined our environment do we know what we would expect to see if we have set up a splunk query and we get a ton of data or results in it how do we filter that down to what really matters because we need to figure this part out in order to figure this part out we need to go from normal to anomalous the unusual things the suspicious things the things that we know will be bad in our environment i said i had about five minutes of fluff let's move on to the good stuff enabling this logging provides tremendous insight into what's going on in your environment but the logging is only step one we need

to flow this data into our sim into our central event management system we want to understand what kind of command prompt tools or command line tools are being run in our environment we want to see powershell tools that are powershell commands that are being run we want to have a good understanding of what sort of activity is there and flow it into our sim tool because ultimately the battle is being fought on our endpoints on our workstations and most organizations are not pulling events from their workstations not if you agree yeah i see a lot of head nods i won't have people raise hands on that and so how do we get the data from our

workstations into our sim a lot of times people say i don't want to push agents out to all those systems i don't want to put another agent on a computer that already has five or six different agents because the users are already complaining about all these agents and the contention for resources that they already have so microsoft wef is a great opportunity or great tool to do that you don't need an agent and definitely look into sysmon sysmon is a good way to get enhanced auditing of windows system activity and so with sysmon it's part of the cis internal suite that microsoft bought a number of years ago i bought the company bought uh mark russinovich was one of the founders

they brought him in i made him a technical fellow he's now the cto of azure at microsoft but there's an install that configures a windows service with a device driver for 32 and 64-bit versions of windows and the configuration is stored in the registry but effectively there's some key components that it monitors and there's a number of things here like uh process activity with hashes image load driver loads file creation time changes network connections so this is the one that i really like about sysmont is network connections we can also look for injection into winlogon and lsas we can look at raw disk polls from the from the from the file system so for example invoke ninja

copy is a powershell tool powersport tool that can actually pull the ntds.dip file off the domain controller while it's running because it's doing raw access reads off of that off of that file system but like i said i really like looking at sysmond for what applications are actually connecting on the network which ones are connected to the internet because things like notepad probably shouldn't and we want to ignore most of the microsoft signed image loads there are some exceptions so casey smith aka sub t has identified a number of microsoft signed binaries that do some very interesting things some of these actually enable you to connect to the internet pull down code and execute it

this bypasses white listing and oftentimes the attacker doesn't need to use powershell or any other command line utility because of these tools with sysmon we go ahead and run the top command we can push it out via group policy we can push it out via your standard application deployment tool we can look at the configuration using sysmon-c but we want to know where swiper is right we want to know when he's sneaking around what is what is happening what's going on so with sysmon we can get an event like this notepad connected to the network it connected to destination 151.101.32.133 that's interesting that's on the internet that's not on my internal network i'm a 10 dot this actually resolves to

rod at github usercontent.com and in this instance i reached out and using notepad i connected to github and i opened up invoke minicats in notepad now i can go through modify that and i could save it somewhere and run it or figure out a number of different ways executed on the system without something that's monitoring what applications are connecting to the network you're probably going to miss this so windows event forwarding i mentioned it a little a little bit ago it's critical to get our workstation logs into our sim and how do we get them there microsoft has this built into windows there's no agent so it uses winram kerberos in order to pull that data back you can

configure a windows event collector on a server or technically a workstation i would use a server and then use group policy to configure your clients to send their events there you don't need all of them 10 to 20 event ids getting this information specifically for powershell and specific events that i'm going to mention in a bit will give you tremendous insight into what's going on in your environment especially in your workstations now there is a bit of an initial learning curve there's a great reference here at the bottom aka dot ms slash wef on some pointers on how to configure wef in your environment it is so when you configure a web collector you can point your clients to one web

collector but there's not any load balancing on that or fault tolerance yet so let's talk about powershell we know that attackers are using powershell they're doing a lot of interesting things with powershell so we need to log powershell and see what's going on because this is what they're doing they're sending out these malicious word documents that have macros these macros are running powershell code or doing other things on the system because macros are code third-party code from untrusted sources running on your network running on your your systems this gives an attacker initial foothold well the last document i showed you isn't that interesting from a perspective of i wouldn't click on that or why would i click on that but what

about one of these what about the one that says it's protected by mcafee or the one that says it's confidential with the docusign logo on it or the one that says microsoft office enterprise protection or the one that says office 365 and proofpoint these are fairly compelling and it's likely that many of your users would click on enable content when they got one of these these are in the wild these are live samples of what attackers are using we can't blame the users for opening these if you're in finance or sorry contracts and you get a document like this that says docusign confidential encrypted they're probably going to open it because a lot of contracts are using

docusign why they're getting a word document via email i don't know but people are busy they have a job to get done we need to better control macros in our environment though even if we do control macros we need to make sure that we're controlling all elite ole is a way to embed an object that can that includes code into an email so when the user double clicks on it and opens it it actually executes this code it looks like a word document but it's really code we can disable this in outlook via reg key and i have a url at the bottom by the way all these slides will be available probably tonight or tomorrow on or on

trimarksecurity.com so i have a link at the last slide that where the presentation will be so module logging who's got powershell module logging enabled or some sort of powershell logging okay a few and that's typically what we see with our customers is there's a handful of people that are logging powershell you definitely want to log powershell because again this is where this is what attackers are using they love powershell powershell gives them tremendous capability without a whole lot of issues or compatibility concerns because pretty much all versions of windows now have powershell on it it's logging in is enhanced in v4 you need b3 in order to get powershell module logging but powershell version 5 is really where

it's at you definitely want to deploy powershell version 5 on all your workstations win10 has it built in and look to deploy it on your servers because we have something called script lock logging which basically logs the smallest component of a powershell script that powershell script block and in doing so it can actually provide some more information about what the code is and what it's trying to do because that's effectively the code that's delivered to the engine to be interpreted to be executed so a lot of the older style obfuscation gets removed before it gets locked whereas with module logging you might get a lot of that obfuscation and probably wouldn't get a lot of good insight

system-wide transcripts are pretty impressive and and i think very useful because what you do is you set up a share on your network write one share so that the systems whenever someone runs anything from powershell it gets logged to a systemwide transcript file on onto that system or onto that share into that file just put on that share and you can pull the data from that chair from the street transcript files so you can actually see what the person is typing and running in in that transcript file i have found interesting activity in the transcript file that i could not find within the event log or within the event that were powershell events on systems

anti-malware the anti-malware system integration for scan interface amsi and windows 10 is really great this is a tool that provides the capability to on a windows 10 system when someone runs powershell code be it in memory downloaded from the internet a file on the system or just typed in manually when it gets delivered to the powershell engine powershell actually kicks it over to amsi and when there's a registered anti-malware solution that supports amsi it can give amc a thumbs up or a thumbs down if it's a thumbs down the powershell engine will not run it this works for all of the powershell scripting supported scripting tools so c script jscript wsh vbscript if the anti-malware

solution understands and and is watching the amc um event flow then it can be blocked here's the problem though our vendors are not listening they don't seem to care please please please reach out to your antivirus vendor and say we are going to be deploying windows 10 we want you to support amsi microsoft defender supports it and avg is on board eset is on board as well the big ones they say we do memory scraping okay that's nice but how do you know you're not missing something and you're letting it run amc can block it so with powershell a lot of customers say you know what we're just going to block powershell and that way we won't

have to worry about it well there's some benefits in actually locking powershell down powershell.exe down so that way potentially code won't run but let's talk about running powershell code from an executable from a compile binary because microsoft provides this nice script code here on the right on msdn on how to execute powershell code from an executable and ben 10 actually put out a tool called not powershell it looks like powershell the powershell console but it's nps.exe and it just calls the powershell engine and then runs the powershell code and we can do this from any dotnet executable or any through.net within from any executable using powershell ps equals powershell create the tool i do want to mention which i

think is very interesting is ps attack ps.exe is a self-contained custom powershell console which includes many of the popular offensive powershell tools and what's interesting about it is they're encrypted within that executable when you run ps attack they get decrypted and loaded directly into memory so guess what antivirus vendors you're not going to see that amc can catch this so it gets decrypted loaded into memory and we have a number of interesting tools we can run like invoke mimikats and powershell.exe is not running on this system what we're running is ps attack.exe which is calling the powershell engine another interesting thing is that powershell has different language modes constrained language mode is a way that

you can lock down powershell to its core element and it's things like invoke many cats don't work in train language mode microsoft made the design decision that any executable that's calling powershell engine the powershell engine with powershell code uses the full language mode so on this system we have constrained language mode enabled by using ps attack we can still run invoke mimikats the other interesting thing about this is on windows 7 it had powershell version 2 by default we then put powershell version 4 on it or version 5 or version 3. running ps attack actually runs the powershell code connecting to the powershell v2 engine there are no advanced security features in powershell v2 there's no module logging there's no

script block logging there's no transcription so that means that we run we when we run invoke mini cats from within ps attack it's connected to that powershell v2 engine and it doesn't show up in the operational lock so all that logging just isn't there and we can do this normally just by doing powershell dash version 2 calling powershell and then running ps sorry git process which won't show up in our log but if we open up powershell normally and we run get service that it'll be there so how do we detect this sort of thing if we have a tool where we can look at the processes on a system and see what modules actually get loaded we can look

for system.management.automation which is the powershell engine it's that dll so we can see here powershell powershell ps attack well i could have renamed ps attack but it's more interesting when i don't and when we dig into this we can look at the modules that are there and they're system.management.ni which is just the imagefile.dll which is called by ps attack so how do we detect this if our nice new powershell logging isn't working we look at the old powershell logging this is the engine started the engine stopped and you can see here it says the host name and the host version of that of that tool and then at the bottom it says engine version equals two well

now we know that it called powershell version two if we have powershell v3 v4 v5 deployed everywhere and we see this we know that this is something that's a little suspicious we need to look into why this is happening but it starts with getting these logs back from our endpoints and our servers and getting them into splunk or our sim tool or whatever else we have for central logging we can detect this like i said event 400 800 the standard powershell logging by looking for an engine version that's less than our standard deployment of powershell looking for system management.automation hosted in these non-standard processes this is not a ps attack problem this is a powershell problem

because ps attack is calling powershell we could just as easily drop an executable that does everything we wanted to and have it do those calls right we don't necessarily need powershell to do that when we can run any executable on our system that we want so you want to remove the powershell v2 engine when it's not being used you can do this starting in windows 8 and 2012 and newer it still requires the net framework 3.5 for someone to actually leverage that powershell v2 but a lot of organizations have already deployed this broadly to their systems so info confiscation is a tool that was released by daniel bohannon at derbycon last year and this takes obfuscation to the next

level effectively what it does you can feed it script code you can feed it a script and it'll go through and completely obfuscate it rendering a lot of the signatures that have been used by blue teams for a while now to look for malicious powershell just don't work anymore same thing with antivirus so i took this function from invoke minicaps get image nt headers it's one of the core components of mimik and bookmanycats so we go through here and we can signature off the function name or off a number of these different things like hdr 64 magic but when we run this through input invoke obfuscation it looks like this and all those signatures don't work anymore

this is at a base level within the invoke invoke obfuscation so i took the power power view tool that will schroeder wrote which is a great way to do ad recon get information about the active directory environment from powershell and i ran that through in book i'm sorry i'll get to that minute but um it basically bypasses av so when we run invoke mini cats normally it doesn't work when we run the obfuscated version it does run so that's what i meant when i said it gets around antivirus so let's look at the power view sample so when i ran power view through invoke obfuscation it looks like this we're not going to be able to signature

off of that pretty easily because if i ran it through at a higher level deeper obfuscation it almost starts looking like machine code so we're not going to be able to look for standard english words phrases etc in in this jumble so what do we do to to find this well lee holmes who wrote all of the security features in powershell v5 in october he did this blog post on his on his site and he pointed out how when looking at three to five hundred powershell scripts from uh down the download script library he saw that the top nine from standard powershell scripts were letters on the right he looked at a bunch of obfuscated code

and he saw that they're all characters so by looking at the type and distribution of the characters in the script we can pretty easily determine whether it's obfuscated or not so this leads us to the next question how do we find it well we get powershell v5 out we enable power script block logging we look we can look at the length of the powershell command because obfuscation is going to add a whole lot of extraneous characters to it and symbols in order to do the obfuscation look for brackets look for lots of quotes there's a lot more of these than you would you would typically see in your normal powershell code and we can look for other things that

are like random so last year when i was here i talked about powershell security some of these slides are very familiar to you if you're sat in that i also showed the offensive powershell detection cheat sheet which i've updated since then and update regularly but this is a good way to start looking for malicious offensive powershell use in your environment pull the powershell log data back put it in your sim tool and then use these indicators to look for it stuff like kernel32.dll is going to be more noisy but i looked at all of it was 80 powershell offensive tool kits and identified what the most common calls were in them basically the key functionality and what they needed from

windows to work and i got this list and i've used this list to actually detect some interesting behavior at customer sites all right sean that's powershell we're here to talk about act directory right so let's get into auditing attack activity and environment let's figure out how we can see what's going on so when we talk about windows logging originally there was nine audit settings in windows 7 20 2008 r2 we get 53 now the problem is that a lot of times in organizations that have had windows over the years and had active directory since 2000 2003 they're still operating with these original nine audit settings and the other thing that we get with win7200ar2 is special log on auditing which is

fantastic because there's companies that i work with that can't log all of the logon data from all their systems right it's a lot of us but what we can do is we can look in particular at specific groups specific accounts and audit when they log on and where they log on so this is the advanced audit policy as we can see here there's a lot of granular data that we can get out of this by configuring success and failure and this top left configuration within the audit policy within the group policy we want to make sure that we enable this it says audit force audit policy subcategory settings window vista or later to override audit policy category settings

so if you don't have that set and you have the standard audit policy setting and the advanced ones windows is going to use this which means you're not getting all of that more more granular event id data you're not going to get the real the things that you really need to figure out what's going on in your environment so how do you figure this out well auditpawl.exe is a great way to get information about how that system is configured so you certainly want to run this on one of your domain controllers to see what sort of event log data auditing you actually have in our capturing i usually recommend these settings for auditing on domain controllers they're very

similar for auditing on other systems and again these slides will be available later and i'm going to call out specifically kerberos service ticket operations and special logon and i'll show you in a bit why that why that matters special audit logon or special logon auditing logs event id 4964 when a user who's a member of one of these groups that you've configured within this the special logon group auditing when they log on and so you can track this uh track these logons based on who's in these groups they're logged on the system to which the user authenticates so if a domain admin logs onto a workstation and you have domain admins configured with auditing and you're flowing that

data from that workstation to your sim you're going to see that log on activity and you're going to be able to talk to that domain admin and say well how are you logging onto this workstation that's not a good idea but jessica payne did a great article and i have the the link here on the bottom to this article talking about recommendations how to configure this and these are groups that she recommends and i recommend as well create a custom group call it whatever you want add it to this and then any users that are of interest maybe they're executives maybe there's uh have special powers within the organization that aren't actually administrators add them to this special group and that

way you can see where they're logging on pull this event id from all your systems so we configure this we configure audit special logon success and failure we need the sids for each of our groups in active directory so here we do domain admins enterprise admins special group auditing which is a group i created got the sid for that in this group policy we need to configure a registry key which is lsa audit special groups and then we put in the sids for the ones the groups that we want to audit once we do that and deploy it these systems will log event id 4908 and it'll list the special groups that it's it's auditing for

auditing logons for on the right we can see that luke skywalker the domain admin in this in this uh active directory environment he logged on to this system and he's also a member of the special group auditing so a couple different groups that said why he's getting uh audited when he logs on so someone asked me before this started it would be really great to have a list of all the event ids on that we need to get from like the main controllers and windows what do you guys think wouldn't that be useful have you found that anywhere no our sim vendors have said hey log these events throw them in this event id bubble

let's get what those are let's capture those right has that event id bubble turned into a crystal ball where we can see malicious activity on our networks what's that it gets murkier yeah exactly so let's talk about the event ids of matter and domain controllers kerberos auth ticket was requested this is the initial kerberos login uh kerberos service ticket request custom special group log on tracking log on failure sid history added or attempted dsrm account password change attempt this is the local administrator account on domain controllers apple set on admin accounts domain policy kerberos policy changing attempt to reset account password specifically for admins or sensitive accounts and then a number of group modifications and active directory modifications

the bottom one we can use to monitor for group policy changes this is a really good idea especially to see who's changing group policies at the domain level the domain the default uh the domain controllers ou and where our accounts are where our workstations are where our servers are but more than domain controllers we want to also audit specific event ids on all windows systems so someone cleared the event log local security authority modification this is the logon system this is what stores the logged on credentials into lsas that protected memory space explicit credential log on handle to an object report requested this is typically accessing the local sam on a windows system or the act directory database on a domain

controller special group auditing account password change new service was installed new schedule task was created or a scheduled task is modified this is how attackers are persisting on networks today if we're not monitoring this we're missing it and then of course modifications of the local group on a windows system so modification of administrators attackers love creating another user account on a system and adding it to the local administrators group why because it's a great way to persist and very few companies are monitoring for this and newer versions of windows with 8.1 and 2012 r2 and newer we get lsas auditing basically anything that tries to inject or connect plug into lsa which again is our key authentication

component mimikatz does this so we can enable auditing to see which tools or components plug-ins drivers etc connect into lsas and are communicating with it keep in mind though before you do this you do want to test because if you have a security product that shims lsas to get information about what's happening on that windows system it will cause problems so be careful but you definitely want to test these out and use these advanced features looking at drivers that fail to load connecting the lsat lsa you can protect it and say only sign binaries can connect to lsa and plug into it so a note about logon types then id 4624 this is like the most numerous event id

you will find in any network system log on type 0 occurs sometimes but attackers based on specific activity that they use you may see this logged so the ones in bold are the ones that you definitely want to pull you don't need all 4624s but the logon types in bold you definitely want batch and service so a scheduled task started a service started or scheduled tasks ran and service started what the account name was that was used to start those or run those new credentials run as net only or remote interactive which is rdp so let's talk about run as net only people have heard of using honey tokens and you know using run as net only to put honey tokens into

systems i'm not talking about that let's look at an interesting situation that jessica payne with microsoft again pointed out this is a way to lock down your workstations so domain admins cannot log into them which makes sense you prevent them from logging on interactively they can't connect they can't rdp they can't run batch service batch jobs or services even if they log on as a regular user account they cannot do run apps makes sense however with run as net only it just loads us into memory and that credential is leveraged when it's called this means that this da account can run the act directory users and computers mmc after logging on as a regular user

which is pretty interesting so this is a way that a domain admin could bypass these security controls because maybe they don't understand why the security controls are there in the first place so we also have to make sure that the admins understand why the security controls are there because by doing this the da has just loaded their credentials into memory which could be pulled by something like mimikats way to mitigate this obviously you can block run ads from specific groups that are logged onto that system so let's talk about password spraying password spring is really interesting because it's automated password guessing so there's a list of passwords that we're going to try we start with the first one we use that

first password to authenticate as every single user in active directory we run through the list lockout threshold is five so we can try four for every user and then we wait for 30 minutes 31 minutes and then we try again and this works a lot of the time because users have bad passwords we can connect to an smb share or a network service so let's start with connections to the pdcs in that logon chair we run it through we get a bunch of passwords 4625 logon failure well most organizations are logging that so we should be able to see that if we're looking for a whole bunch at a time or we can also look at the user

attribute of when they last a bad password was last attempted so we can see here it's within the same time frame that's unusual but let's say instead of connecting smb we connect to the ldap service on a domain controller what happens no more 4625s wow where did they go a lot of organizations are monitoring for 4625s but if we connect to the ldap service for password spraying you wouldn't see this you have to get 4770 once kerberos pre-authentication failed that's not very useful why would i log that so we password spray we see 4771's last bad password attempt shows up and we look at this event 4771 failure code is zero by 18. that means

bad password we also get 4648s on the workstation or the system that the attacker is running password spraying on so we'll see a bunch of these where joe user logged on and attempted to use the credentials for alexis phillips or christopher kelly or whoever and a bunch of those within seconds of each other so that's pretty unusual so with one of the methods that attackers use is something that i call spin scanning which is basically asking active directory for what are the services that are using kerberos in the environment because in order for kerberos authentication to work a service has to have a service principal name associated with it that service principal name associates that service account

with a service running on a server so it looks like this and we can do something like i said spin scanning we can get information on all the service of the sql servers in the environment because they have spins registered we get the port number we can get the instance name we know what the sql service count is associated with it and again we can do this by asking the domain controller we don't need to do any kind of port scanning and at the bottom all we need to do is get a list of all of the users in the in the domain that have a service principal name those are service counts so that's useful because then we can do

something called kerberos we get a list of all the service accounts in the organization because they have service principal names we pull a service principal name from each of them we request a service ticket using rc4 encryption for each of those we get a service ticket encrypted with rc4 which means that it's encrypted with that service accounts and tlm password hash it's interesting right cool thing about this is we do this as a user and we never connect to any of those servers we just ask the domain controller it looks like this we use a powershell tool or powershell command at the top uh which enables us to request this the service ticket for the service principal

name and at the bottom we run a k list and we can see that we got that service ticket in this instance it's adsdb01 it's a sql server and it's rc4 so we can use minicats to pull this out of the user memory space but since it is user memory space the user has access to this ticket we can use a powershell tool in order to do it or something else to just pull it out save it as a file offload it to our attacker system on the internet somewhere and run kerberos which is what tim median released the derby con a few years ago and since then most of the password crackers have been updated for this

so you can use your heavy duty password cracking rig gpus to crack service account passwords offline and if humans have created these generally they can be cracked if your minimum account password length for your domain is the default which is seven we're going to crack all of these probably because most people go with whatever the minimum is even if it's 10 or 12 it's very likely it can be cracked so how do we detect this about a year and a half ago i put up a blog post on potential detection tgs rec packets with rc4 are looking at the network searching for excessive 4769 events so recently i decided to look at this again and go how can we detect this

so i put up a post on the tri-mark security website as well as on 80 security and this is the the nuts and bolts of it look at event id 4769 with specific options as well as ticket encryption 0x17 which is rc4 filter out service accounts we filter our computers in the search name the account name field keeping in mind that interforce tickets use rc4 by default adfs tends to use it as well but by doing this we can take those 4769 events which we may have millions of them and take it down to maybe a thousand or so at that point we're really digging into looking at what's going on in our environment and when we do that when an attacker

does something like this is sample code on how to basically kerberos get those service tickets for all those different service principal names in the in the organization domain k list all of these are rc4s so when we look here we see rc4 we see rsc4 rc4 so all they're doing is requesting rc4 service tickets and we can look at that by using these indicators so we see joe user at 936 requested the service ticket for citrix vdi microsoft biztalk business objects microsoft's agpm group policy management console and four different sql servers all within a couple seconds of each other that is extremely suspicious i don't know what joe's doing maybe he's trying to work overtime or figure out some security

stuff but he's up to something like up to no good all right sean but what if the attacker decided to request these but like did one a day we would really never see that right how would we know that joe's doing something he shouldn't so i figured if we actually set up a honeypot account where we created a new service principal name that doesn't exist i made it up it's not associated with an application no one should ever request it and we set admin count to one which makes it look like it could be a an account with domain admin rights or domain level rights so when the attacker goes through and says i want to know all of the user accounts

that have admin count as one could be admins and a service principal name give them to me we see kerberos honeypot hopefully they don't actually look at the service principal name they requested for because it's a trap and we can see that it's an rc4 ticket pretty standard and then we go back to our indicator and our search and we see that kerberos honeypot is there now we know that joe is up to no good he is requesting service principal names uh for a system that does not exist on this network and if we just look for that specific service name which we don't have to name honeypot we call it something else we can see that it happened so from

millions to thousands to one one guaranteed high fidelity event attackers are doing this but there's more in the newer versions of windows when you have them on your domain controllers you get these new checkboxes this account supports kerberos yes 128 256 right so if you set this on a service principle or service count that has a search principle name and your application supports aes kerberos which most of the windows ones do this changes the game because now when we run this standard kerberosing method powershell code script they get an aes ticket which changes the game so this isn't going to work 100 percent of the time because this basically tells the dc it prefers aes give them an

aes ticket and there's a way to say i really need an rc4 ticket give that to me but that's another indicator that's other activity that you can look for the key to this is not necessarily saying i need to detect all bad activity right attacker's dilemma defender's dilemma we've heard this several times the attacker you know can can just throw things at it and once they get through then they're good the defender has to be right a hundred percent of the time this is false do not think that it's not the way it works when the attacker gets on the network and they're moving around they have to be right 100 of the time they have to avoid all of your traps and

tricks and logging that you have on your network if you configure those and you're alerting on these things and you're pulling what you need they have to trip over one single tripwire that you've set up and then you know they're there

yeah i mean so if you use gmsas like group managers accounts absolutely i've talked before about mitigation of that specifically we're talking about detecting but yes long passwords for service counts 20 30 characters great very difficult to crack nation states are probably in that area but like most of us are not defending against nation states we're defending against ransomware and other other types of things but yes absolutely you want long complex passwords for service counts ideally a system creates it like group managed service accounts where ad actually manages the passwords for those for those accounts we want to make sure that we can protect those set up a fine grain password policy create a new group called

all service accounts add all service accounts into that into that group and apply that fine grain password policy to that group and then all your service counts now you can tell them they have to be 25 characters long whenever they get changed yeah great great question thank you so in conclusion we've had this event id bubble we've thrown all these event ids in we haven't got a lot of a lot of benefit out of it but we can track this activity if we're looking at the right things because most attackers are following the same procedures they run through the same parts of the playbook we want them to go past the first page further back into their playbook to

figure out how to avoid the logging that we have configured we can detect kerber roasting which is a huge help to us because curb roasting is something a lot of attackers are using and i just want to call out and thank jessica payne for her resources she also helped me identify some of the key event ids i also have friends at mandiant so devin was a help there as well slides will be on presentations presentations.adsecurity.org thank you very much for your time that has been mine and we'll open up for questions [Applause] so i think we have a few minutes for questions please raise your hand yes

how effective is the microsoft ata tool of defecting at detecting attacker activity ata has pretty decent detection of specific types of attacks and the user behavior analysis component of it is maturing if you want to talk about it in more detail i'll be at the trimark security booth after this i don't sell products but yeah i'll be happy to talk in more detail off mike any other questions great well like i said i'll be at the trimark security booth in the vendor area after this if you have any questions thanks very much appreciate it enjoy