Note: Updated March 30, 2022
At a past Hybrid Identity Protection Conference, several of us spoke about the ongoing 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 of security research and discussion about the different paths to compromise within AD. A variety of clever methods take 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.
Related reading
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).
Semperis friend Michael Dubinsky (@MichaelDubinsky) 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, AD Hidden Object Detector, that accomplishes the goal of finding hidden Active Directory objects using a novel approach. He essentially uses the same API calls that our Directory Services Protector 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 active directory objects, well, it might be time to dig in deeper and see who’s lurking about!
