At our recent Hybrid Identity Protection Conference, several of us spoke about the increasing use of Active Directory as a subject of interest in malware attacks. Whether it’s mining AD for information about privileged access, compromising user accounts that lead to increasing levels of privilege in AD, or purposefully targeting AD domain controllers with ransomware, Active Directory has a big bullseye on its back these days. As a result, there’s been a lot security research and discussion about the different paths to compromise within AD. One of those paths that’s been described as the “ACL (Access Control List) Attack Path” was presented in a recent BlackHat conference. This talk, presented by Andrew Robbins and Will Schroeder from SpecterOps, was entitled, “An ACE Up The Sleeve, Designing Active Directory DACL Backdoors”, and details a variety of clever methods for taking advantage of poorly delegated AD permissions to take control over privileged AD security principals. One of those methods involves getting to the point where the attacker can persist within the environment without being detected. And one of the ways to do that is to create or take control of a privileged user account in AD and then hide that account from prying administrators’ eyes.
As an example, if they have sufficient permissions on a user object, an attacker can take ownership of the user, set a Deny Read ACE for all users on that object, and the object is essentially hidden, as shown here:
You could further remove the user from being visible at all by other admins, by denying the “List Contents” permission to Everyone on the Hidden OU in the screen shot above. This would prevent any normal administrator from even noticing this user was there and an attacker could potentially use the account without being discovered (or at least found).
Recently our friend Michael Dubinsky, the Principal Program Manager at Microsoft for the ATA and Azure/ATP products, wrote a great blog post about this hiding phenomenon, along with a PowerShell script to detect hidden user objects by enumerating Relative Identifiers (RIDs) left in the AD RID pool and then trying to reach each object’s SID. If a looked-up SID cannot be found using a standard LDAP call, the script will indicate that you do not have access to that object, which could indicate a hidden object.
Our CTO, Guy Teverovsky came up with an alternative approach, and a utility, called AD Hidden Object Detector, that accomplishes the goal of finding hidden AD objects using a novel approach. He essentially uses the same API calls that our AD State Manager product uses, to query AD at the directory replication level. This lower-level call allows us to determine the number of objects that AD knows about, regardless of the ACLs in place on the object, and compare that to the number of objects we have permission to. The tool then returns any objects it found via our replication call, that we did not find through normal LDAP calls. The utility must be run as a privileged user in AD but easily finds my “Hidden User” object, as shown in the output of the utility below.
One nice thing about this utility is that it can find any type of hidden object—not just user objects. You can download the utility here <AD Hidden Object Detector> and give it a try. Let us know what you think and if you find hidden objects in your AD, well, it might be time to dig in deeper and see who’s lurking about!