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.
