Detecting Attackers in a Windows Active Directory Network

TL;DR If you know Pass the hash, Mimikatz, and BloodHound, jump down to the detection section.

The Pain

Windows and the Active Directory environment are pervasive in the corporate world. Due to high adoption and lax patching and misconfiguration issues on many fronts, the “AD network” is often the first thing that an attacker or red team looks at.

Since time immemorial, attackers of Windows have known that any authenticated user can enumerate the list of local admins on a Windows machine. Slightly less known, is that authenticated users can also enumerate session info on a Windows machine, that is, who is logged in. The rise of Mimikatz and Invoke-Mimikatz has made life hard on defenders. Mimikatz steals tokens, hashes, and depending on settings, plaintext passwords, of any user interactively logged into a machine.

Using the admin and session enumeration tools allows an attacker with the tiniest foothold to leverage Mimikatz, extend the foothold, and collect more credential. If you don’t know pass the hash and cred theft there are only two sources you need to get up to speed. The important thing to know is that the attacker moves from machine to machine collecting an ever-growing set of credentials.  As the set of credentials grows, they have a larger set of machines they can exploit. This is often exponential. The attacker’s Mount Everest is getting access to Domain Administrator credentials.  Once the attacker has these, they can get to all the data on all the machines in the domain, and can setup unbeatable persistence.     

Enter BloodHound

As a defender, BloodHound is your worst enemy. It is the leading tool, by miles, in mapping trust relationships in an Active Directory domain. Watch this video and feel your world crumble. Unleash the tool in your environment and you won’t sleep for weeks. But, I digress…

BloodHound uses lists of admins on hosts, AD group memberships, AD ACLs, logged in sessions, and a bit more, to map where an attacker can use Mimikatz next, what credentials they will get there and what new access they will gain with the new creds. The BloodHund team refers to the extension of the attack and the escalation chain as derived admin rights. In the past, finding these was trial and error and went one step at a time.  That is, the attacker gets some access and tests everywhere to see if the cred works to gain admin rights. The attacker gets a little more access and tests everything again and so on. This is slow and noisy. BloodHound assesses all this with regular user access before any exploit tool is ever run. A typical attack graph looks like this.

There are even plugins that have been written to automate the attack path, once found, so that the exploitation can occur quickly before defenders can cut off access.

Prior Detections

Unless the defender has the tools and understands their expected net flow, the discovery done by tools like BloodHound blends into standard Windows traffic.  Keep in mind that almost every Windows admin has, at some point, been told that 40% of LAN traffic is Windows’ super chatty browser and NetBIOS traffic.

One of the reasons that plugins are needed to exploit an attack path quickly is that most detections are based on AV or anti-malware tools. They are likely to draw actual attention. Once the attacker has gotten this far, the horse is out of the barn and it is often a race to try to detect and cut off all of their persistence mechanisms and find all the other compromised hosts.  Many shops never even detect any of this.  *sad emoji*

Detecting the Foothold

As stated, the attacker only needs a tiny foothold to start enumerating your Windows environment. They don’t even need local admin rights on their initial compromised host. They only need a domain user account to perform the enumeration. At some point, they will need admin rights to steal creds, or they can phish them, or … so many paths to destruction.

Enumeration of local admins and user sessions generates traffic that we can log. No one seems to log it though, probably because the settings seem useless and probably noisy, but in practice, the noise is easily filtered. If you use a lot of SMB file sharing, you will get many useless logs, but they are easily scrubbed.

In both enumeration cases, the attacker connects to the \\machine\IPC$ share of the host it enumerates.

Since Windows 7 and 2008 R2, we have had the option to “Audit File Share”.  In your Group Policy, this is under “Object Access” in “Advanced Audit Policy Configuration”.

This setting is little used, probably because warnings say it can be chatty and even the file server teams at Microsoft don’t suggest turning it on. I’ll cover it more later, but the good news is, you don’t need the setting on busy file servers or Domain Controllers, as long as you have the setting on a lot of other machines.

The event we are looking for is in the Security event log and is event ID 5140. The Share Name of \\*\IPC$ is the key here. You can toss out any 5140 that does not have this value. The Subject Account Name and Domain will be that of the comprised account that is running the scan. The Source Address is the IP address of the host running the scan. You can filter out the source IP of 127.0.0.1 to reduce noise. The computer that logs this, of course, is the target of the attack.

Don’t call security just yet.  There are other legitimate reasons that something might access your IPC$, but they are far and few between. One of my monitoring systems generates a ton of these so I filter its IP address out. Going back to what I said earlier about not having to put this on your DCs and file servers, so you don’t get buried in logs… the key with this detection is to collect the logs on a large set of machines. You can do a simple group by source IP and count to see that some IPs are clearly doing something bad. Attacker detected!  *happy jumping guy emoji*

In two weeks, with very few hosts logging this event, I have had great success. I have found two blue teams scanning our user network. In our prod network, I have detected two red teams, numerous legitimate vulnerability scanners, and one other curiosity that I am investigating. *slightly smug nerdy guy emoji*

Looking at the Logs

One of the places I collect my logs, that is VERY handy for this situation, is Microsoft Operations Management Suite Online (OMS). I can setup email alerts every time we see an IPC$ event.  The basic query look like this.

(Type=SecurityEvent) EventID=5140 \\\\*\\IPC$

I have some known good destinations that I filter out:

(Type=SecurityEvent) EventID=5140 "\\\\*\\IPC$" NOT (Computer="server.domain.com" OR Computer="otherone.domain.com")

I can pipe that to a SQLish query and see who the top talkers are.  This is key to finding the attacker and not just a little legitimate noise.

Based on the size of your environment you will want to scope the number of hits from a single IP and a time range.  That said, even very few hits, from one IP to several sources, is likely an attack.

One easy and low cost way to get these events at scale might be Windows Event Forwarding. Without correlating the scans across many hosts, you are likely to chase many false positives.

Call to Arms

Stop giving out local admin rights like candy.

As a defender, map your environment with BloodHound. You may want to get the Xanax ready first.

Monitor those IPC$ connections.

Read my next piece on blinding enumeration tools.