This is Day 5 of Week of Evading Microsoft ATA. The week has been split in the following days:
Day 1 - Introduction, detection and bypassing/avoiding Recon and Brute-force detection
Day 2 - Detection and bypass of overpass-the-hash and golden ticket
Day 2 - Detection and bypass of overpass-the-hash and golden ticket
Day 5 - Attacking ATA deployment, limitations of research and mitigation
Find ATA Installation
Admin Access
Once we know that there is an ATA deployment in a domain we may try attacking it. There are a number of interesting things which can be done with it. If the ATA Center is the part of the target domain and we have escalated privileges to domain admin or have got local admin access to the Center, we can have much fun. ATA subscribes to the concept of "if its admin its game over". By default, all the members of the local administrators group (local admins, domain admins) on the ATA Center have administrative access to the ATA console. We can resolve alerts, add exclusions, enumerate honey tokens etc. with that access.
While this is nothing ground shattering, since ATA specifically targets domain dominance and lateral movement, having the ability to add exceptions for our IP, users and attacks is very useful.
Backend MongoDB
ATA Center uses MongoDB to store entities, entity profiles, Kerberos requests, suspicious activities and more. It listens only on localhost but needs no authentication to connect to! This means if we have administrative access to the ATA Center we can do very interesting things. Let's see two of them:
Tampering with alerts
Let's say we want to tamper with suspicious activities from our foothold user, say, labuser. Let's first look for SourceAccountId from the UniqueEntity collection for labuser. I am using RoboMongo for accessing the mongodb:
Once we have the id of our account, let's have a look in the SuspiciousActivity collection for alerts for our user:
Let's have a look at the latest suspicious activity for labuser:
An unusual protocol alert, most probably an overpass-the-hash, going by the time stamp and other details, this is the alert in the ATA console:
Now, we can simply lookup for id of another user, say termadmin, and replace that by editing the SourceAccountId for that particular alert in the SuspiciousActivity collection. Let's do it not only for labuser but other two user's in the above alert as well for the sake of demonstration:
Sweet, isn't it :D
We can do the same for Computers as well to "frame" some other computer for attacks like Malicious replication of directory services and so on.
Hiding the alerts
Let's say we simply want to hide an alert. Entries in the SuspiciousActivity collection has a proeprty called "IsVisible". Set it to false and the alert vanishes from the console. Let's go after the latest DCSync alert:
Let's look for "TitleKey" : "DirectoryServicesReplicationSuspiciousActivityTitle" in the SuspiciousActivity collection and edit the latest one to change "IsVisible" : true to "IsVisible" : false:
And the result is:
Nice! This helps us in covering tracks in a post-DA lateral movement scenario.
Of course, no surprise, we modified the database and the console displays the modified values. But as these are security alerts, having access to just one box - ATA Center - drastically reduces the security posture of the entire organisation.
Limitations of the research
Copy paste from my BlackHat slides:
- Focus of all the bypasses is on Anomaly based detections.
- Many behavior based detections could not be replicated in the lab and are more powerful and useful in a real environment.
- Behavior based detection may detect lateral movement even if the anomaly based detection is bypassed – use the avoidance techniques (Day 4) in such cases.
Evading ATA forever
What happens when the bypasses we discussed are fixed? We modify our methods and techniques. I have seen fellow red teamers using Golden ticket or Skeleton key just to brag about it in their reports. No matter how frustrating they are, we as good attackers need to focus on the goals of the assessment. Not only it helps in meeting those deadlines, it also helps in avoiding pesky detection mechanisms ;) For example, there is no need to go for DA if the goal of the assessment can be completed without it, stay focused!
Defences
More from my BlackHat slides:
Microsoft's Response
Microsoft's ATA team is awesome! They contacted me (and MSRC contacted me as well) when my talk was scheduled and we worked together to address and understand each other. I always found them very open to the idea that researches like this actually make a product better. It was actually fun exchanging ideas with them!
That is all for the week of Avading Microsoft ATA. Hope you enjoyed it as much as I enjoyed writing it :) Please leave questions, feedback and comemnts :)
Welcome to the last day of the Week of Evading ATA. We have seen how ATA can be bypassed and avoided during a security assessment. Today let's see how we can attack ATA deployment. We will also discuss limitations of the research against ATA, some closing thoughts and some general mitigation against AD attacks.
Attacking ATA
Find ATA Installation
So how do we spot ATA? Before 1.8, it was possible to simply run banner grabbing against web services running on port 443 and look for "Microsoft Advanced Threat Analytics". An example PowerShell command for this:
But ATA 1.8 uses Single Sign-On and it is not possible to grab the banner without authenticatiob. But we are not out of options. We can simply look for certificate used by the ATA console. By default, ATA console uses a self-signed certificate issued to "ATACenter".
ATA uses local users and groups of the ATA Center, the ATA documentation suggests having three types of role groups ATA Administrators, ATA Users and ATA Viewers. If the target deployment uses the exact same group names as suggested, we should be able to enumerate ATA by enumerating local groups on machines in the domain using PowerView:
Also, I am quite sure that smart folks out there (like from nmap or metasploit) will soon include ATA in their service identification.
Also, I am quite sure that smart folks out there (like from nmap or metasploit) will soon include ATA in their service identification.
Admin Access
Once we know that there is an ATA deployment in a domain we may try attacking it. There are a number of interesting things which can be done with it. If the ATA Center is the part of the target domain and we have escalated privileges to domain admin or have got local admin access to the Center, we can have much fun. ATA subscribes to the concept of "if its admin its game over". By default, all the members of the local administrators group (local admins, domain admins) on the ATA Center have administrative access to the ATA console. We can resolve alerts, add exclusions, enumerate honey tokens etc. with that access.
While this is nothing ground shattering, since ATA specifically targets domain dominance and lateral movement, having the ability to add exceptions for our IP, users and attacks is very useful.
Backend MongoDB
ATA Center uses MongoDB to store entities, entity profiles, Kerberos requests, suspicious activities and more. It listens only on localhost but needs no authentication to connect to! This means if we have administrative access to the ATA Center we can do very interesting things. Let's see two of them:
Tampering with alerts
Let's say we want to tamper with suspicious activities from our foothold user, say, labuser. Let's first look for SourceAccountId from the UniqueEntity collection for labuser. I am using RoboMongo for accessing the mongodb:
Let's have a look at the latest suspicious activity for labuser:
An unusual protocol alert, most probably an overpass-the-hash, going by the time stamp and other details, this is the alert in the ATA console:
Now, we can simply lookup for id of another user, say termadmin, and replace that by editing the SourceAccountId for that particular alert in the SuspiciousActivity collection. Let's do it not only for labuser but other two user's in the above alert as well for the sake of demonstration:
Sweet, isn't it :D
We can do the same for Computers as well to "frame" some other computer for attacks like Malicious replication of directory services and so on.
Hiding the alerts
Let's say we simply want to hide an alert. Entries in the SuspiciousActivity collection has a proeprty called "IsVisible". Set it to false and the alert vanishes from the console. Let's go after the latest DCSync alert:
Let's look for "TitleKey" : "DirectoryServicesReplicationSuspiciousActivityTitle" in the SuspiciousActivity collection and edit the latest one to change "IsVisible" : true to "IsVisible" : false:
Nice! This helps us in covering tracks in a post-DA lateral movement scenario.
Of course, no surprise, we modified the database and the console displays the modified values. But as these are security alerts, having access to just one box - ATA Center - drastically reduces the security posture of the entire organisation.
Limitations of the research
Copy paste from my BlackHat slides:
- Focus of all the bypasses is on Anomaly based detections.
- Many behavior based detections could not be replicated in the lab and are more powerful and useful in a real environment.
- Behavior based detection may detect lateral movement even if the anomaly based detection is bypassed – use the avoidance techniques (Day 4) in such cases.
What happens when the bypasses we discussed are fixed? We modify our methods and techniques. I have seen fellow red teamers using Golden ticket or Skeleton key just to brag about it in their reports. No matter how frustrating they are, we as good attackers need to focus on the goals of the assessment. Not only it helps in meeting those deadlines, it also helps in avoiding pesky detection mechanisms ;) For example, there is no need to go for DA if the goal of the assessment can be completed without it, stay focused!
Defences
More from my BlackHat slides:
- ATA even if can’t detect anomalies, provides interesting insight in the traffic exchanged with the Domain Controller. Use that to detect the attackers.
- Limit your DAs to login only to Domain Controllers. Remember prevention is better than cure.
-Implement possible architectural changes suggested here: https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access
Microsoft's ATA team is awesome! They contacted me (and MSRC contacted me as well) when my talk was scheduled and we worked together to address and understand each other. I always found them very open to the idea that researches like this actually make a product better. It was actually fun exchanging ideas with them!
That is all for the week of Avading Microsoft ATA. Hope you enjoyed it as much as I enjoyed writing it :) Please leave questions, feedback and comemnts :)