Monday, August 7, 2017

Week of Evading Microsoft ATA - Announcement and Day 1

I have been playing with Microsoft Advanced Threat Analytics (ATA) for past few months. I found it useful for Blue Teams and scary as a Red Teamer as it detects many Active Directory (AD) tools and techniques. Naturally, I needed ways to bypass it and that is something which motivated me to spend weekends and nights looking for ways out. I found some methods to bypass ATA, some to avoid it and some to attack the ATA installation. 

I gave a talk about Evading Microsoft ATA for Active Directory Dominance at Black Hat USA last week (slides at the end of the post) and would speak at 44CON and BruCON on some of the additional research I am doing. 

What I found mostly during my research was it is not really difficult to evade detection by ATA as long as we are not running tools blindly without understanding what they do. So, to generate interest on using offensive tools more wisely and modifying techniques based on the detection mechanisms, in addition to my talks at multiple conferences, I announce a Week of Evading Microsoft ATA beginning from 7th of August 2017.

We will see interesting stuff the whole week which includes whatever discussed in my talk and more:

Day 1 - Introduction, detection and bypassing/avoiding Recon and Brute-force detection
Day 2 - Detection and bypass of overpass-the-hash and golden ticket

Let's get started with Day 1:

What is ATA?
ATA is a platform which listens to certain protocols going to the Domain Controllers (DC) of a domain. It can integrate with syslog, SIEM etc. It can detect attacks based on anomaly and user behaviour. AFAIK, for anomaly detection there is no learning period for some attacks (one week for certain attacks) and for behavioural detection there is a learning period of 21 days. We are going to focus only on the anomaly based attacks.

ATA Architecture
ATA needs to see the traffic being sent to the DC. Here is how it looks like:

ATA Gateway is that part which reads the traffic and parses it. ATA Center is that part which stores the parsed traffic, do analysis, stores everything in a mongodb and hosts ATA console where we can see alerts. The Gateway can either be a separate box or a lightweight one which can be installed on to a DC. More on architecture here.

Lab Setup
The lab setup uses a Lightweight ATA Gateway with ATA 1.8 (started with 1.7) which is the latest at the time of writing - 30th July 2017.  I use this installation in my PowerShell and Active Directory training and therefore, the installation has been tested by more than 400 hackers and infosec professionals in last 7 months. 

What attacks can ATA detect?
Many! Have a look at this link: What threats does ATA look for?
The attacks which we are interested in:

- Account enumeration
- NetSession enumeration
- Directory services enumeration. 
Above attacks result in enumeration of users, computers, group membership, sessions etc. 

Compromise Credentials
- Brute-force
- Unusual protocol implementation

Lateral Movement
- Pass the ticket
- Pass the hash
- Overpass-the-hash

Domain Dominance
- Golden Ticket
- Malicious replication requests

Once we understand the architecture, let's jump in and have a look at various attacks. We will follow a simple "attack chain" where we begin with a normal domain user privileges and then work our way up to domain dominance. We will see ATA detects us and how it can be bypassed at each step.


We assume that we have a normal domain user privileges. We start with the domain enumeration and try to list computers, group membership of domain admins etc. This enumeration is fine with ATA most of the times. But for some enumeration there are alerts. For example, if you enumerate all users and groups in a domain using PowerView, there are no alerts but if the native net.exe is used that may be detected as "Reconnaissance using directory services enumeration":

Why so? Because ATA currently detects such enumeration done using SAMR protocol which is used by net.exe. PowerView uses LDAP queries which ATA does not care about currently for enumeration. In fact, ATA is mostly interested in the authentication related data when it comes to LDAP.

To avoid detection WMI queries can also be used. This was covered by Chris Thompson (@retBandit) in his DEF CON talk:

Get all users in the domain "opsdc"
Get all domain groups:
Get membership of the Domain Admins group:
Because we have enough information now, let's move ahead with some more enumeration. Let's start hunting for local admin privileges on other boxes.
Let's hunt for a machine where a DA token is available and we have local admin privileges:
Both the above activities are detected by ATA as Reconnaissance using SMB session enumeration:
Now, if we look at the alert closely. ATA complains about Recon against only the DC. What does that mean? That means, if we gather the information from the DC but do not run user hunting against the DC it would be possible to bypass this detection. To avoid running user hunting against the DC, we need to use the -ComputerFile parameter of Invoke-UserHunter or Find-LocalAdminAccess and provide a list of computers which does not contain the name or IP of the DC.

This is how it looks like in the lab:
And above will not be detected by ATA! A simple but effective bypass ;) As long as we keep our communication with the DC minimum, chances of detection would be low.

Another enumeration technique, not caught by ATA right now, is using SPN scanning. Read this article to know more about SPNs. We will touch SPN scanning on Day 4.

Once we know a machine where token of a DA is available, we may like to have local admin access to it so as to possibly extract credentials (hashes, keys or passwords) for the DA and use that. There are so many ways to achieve it. Since we already have a list of users, let's try brute-force attack against all the users in the domain. This is how a detection looks like:

We will use only one password and therefore, a single attempt against all the users. This is a well known technique. We will use Invoke-BruteForce from Nishang for this:

And this doesn't get detected! I have another brute-force bypass under research and I will present that during my talk at BruCON.

Once we have local admin credentials (brute-force) or access (Find-LocalAdminAccess) to the box where DA tokens are available, we will pull the credentials for DA. That will be covered on Day 2 :)

Hope you enjoyed the post!

The slides of the BlackHat talk are below:

No comments:

Post a Comment