Active Directory has existed since Windows 2000 Server edition. It was designed to give companies and their users a great UX for single sign-on and easy integration with other applications. For a normal Active Directory Domain User, it’s like having a Google search engine inside yellow pages:

 

This enables the attacker to gather information without raising alarms in the target environment. The hacker uses reconnaissance to learn where sensitive data is and what the high privileged accounts are so that he can formulate a plan. From Microsoft’s perspective, this is not a vulnerability or security issue since it’s by design that they allow other great functionalities to work for the domain environment. From a hacker’s perspective, this “Google Search” of the company’s domain is GOLD.

Let’s start with the “hacking”:

We can see from the following screen that user “mike” is not part of any Admin group but only the Domain Users low-privileged group.
By default, the user cannot install anything with this group permission. BUT from an Active Directory point of view, he still has the ability to query the AD database:


 

Let’s see what information gathering you can do in that Domain User context.
 

The most basic and common reconnaissance to discover users and computers is to use the native “net” command:
net group “domain computers” /domain
net group “domain users” /domain
net group “domain admins” /domain

 
As you can see, from a network perspective, the command only goes to the DC using TCP port 445. It does NOT require a scan of the network to get a physical response from all PC’s:


There are a couple of ways to blacklist and block the network scan reconnaissance options, but obviously, we have more options to gather data from the AD. The attacker prefers this method because it is quiet, and he can’t be stopped.

 
LDAP can provide the attacker with much more data (basically any information that exists on the DC database except the passwords). This is the ADSI edit that most Admins are using on the DC:

 
The same option exists on any Windows machine that is not GUI based, and it doesn’t require anything to download. It is called the ADSIsearcher, and it exists inside the powershell/.net framework by default.
 
For example, if we want to get all the computers, we can filter the LDAP query using (objectClass=Computer):
 
([adsisearcher]”(objectcategory=Computer)”).FindAll()

If we want to filter the OS version only for Windows 2012, we can use another match criteria:

([adsisearcher]”(&(objectcategory=Computer)(operatingSystem=*2012*))”).FindAll()

And you can do the same, of course, for users information gathering:
([adsisearcher]'(objectcategory=user)’).FindAll()
 
You can query for much more low level data on each LDAP object, such as the entire user properties:
([adsisearcher]'(samaccountname=mike)’).Findone().properties


 
Or, to be even more specific, we can query only for last password set of that “mike” user:
$searcher1=New-Object DirectoryServices.DirectorySearcher
$searcher1.Filter=”(&(samaccountname= mike))”
$results=$searcher1.findone()
[datetime]::fromfiletime($results.properties.pwdlastset[0])


 

From a network perspective, you can see that packets are going only to the DC using the LDAP protocol TCP port 389:


 
 


 

*There are some non-native options to recon the domain like dsquery and Adfind, but it requires more packages to download which might raise flags for the security team.

 
 

This is a big elephant in the room – security reports highlighting major attack campaigns have showed us that the attackers prefer AD Recon to achieve their objective.

In the next post, I will talk about privilege escalation techniques and how the attackers can potentially move from a low-privileged Domain User to a Domain Admin—and compromise the entire Domain network.
 
 
 

[gs_lp_like_post] 0