Due to the architecture of Active Directory, once a domain-joined computer is breached, the attacker is able to map the network, locate sensitive accounts and assets, and estimate vulnerabilities. The process is possible by querying the Active Directory (AD) using the LDAP protocol.
What is the difference between LDAP and Active Directory:
LDAP (Lightweight Directory Access Protocol) is a cross-platform protocol used for authentication to the directory services. LDAP is used for the communication between the application and the directory services servers which store and share information about users, passwords, and computer accounts.
LDAP is the communication protocol with the AD. Many different directory services (not only Microsoft AD) can understand the LDAP protocol.
LDAP Reconnaissance:
LDAP reconnaissance is one of the first steps and the foundation of almost every AD attack. An attacker can use this technique to gather data without credentials. By using tools such as Bloodhound and PowerView, the attacker can map your network, find sensitive assets, domain admins, and vulnerable services.
An example of a Bloodhound generated map to find Domain Admin.
How the attack works:
- An attacker gets access to a user in the domain (via phishing or any other method).
- The attacker uses PowerShell to create queries against AD objects to find out information about:
- * User objects containing Service Principal Names (SPN) that will indicate if the account has the privileges to run services to support applications like SQL server.
- * Whether the user is a member of Sensitive Security Groups such as Domain, Enterprise, and Schema Admins. This allows the attacker to list the highest privileged accounts in the domain.
- * Location of high profile assets like file servers, databases, and AD Domain Controllers.
The LDAP is deployed as a default part of the domain controller services, and in most environments stays like that. This means that with default configurations every account in the domain has the permission to perform reconnaissance. So basically, a single point of failure on any standard user account can lead to a large-scale breach.
What can be done to lower the risk for an LDAP Reconnaissance attack:
Because it is essential to allow LDAP queries to the users in the domain, preventing LDAP reconnaissance by changing configuration will dramatically harm your production. The next option is based on auditing and hunting LDAP based attacks. This is done mainly by using LDAP search filters and system auditing configurations.
-
Detecting Anomalies:
Unusual queries that can be suspected to be part of malicious reconnaissance need to be searched for. For example, an LDAP query that aims to collect many different entities from the domain can be a sign for malicious activity:
Process: sharphound.exe
DistinguishName: DC=lmsdn,DC=local
ScopeOfSearch: SubTree
AttributeList: [“objectsid”,”distiguishedname”,”samaccountname”,
“distinguishedname”,”samaccounttype”,”member”,”cn”,”primarygroupid”,
“dnshostname”,”ms-mcs-admpwdexpirationtime”]
SearchFilter:
(|
(|(samaccounttype=268435456)(samaccounttype=268435457)(samaccounttype=536870912)(smaccounttype=536870913)(primarygroupid=*))
(&(sAMAccountType=805306369)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
(objectclass=domain)
)
The following list was compiled by Microsoft Defender ATP Research Team and contains suspicious search filter queries, used with recon tools, that highlights LDAP query filters originating from fileless of file-based execution:
| Recon tool
|
Filter
|
| enum_ad_user_comments (Metasploit) | (&(&(objectCategory=person)(objectClass=user))(| (description=*pass*)(comment=*pass*))) |
| enum_ad_computers (Metasploit) | (&(objectCategory=computer)(operatingSystem=*server*)) |
| enum_ad_groups (Metasploit) | (&(objectClass=group)) |
| enum_ad_managedby_groups
(Metasploit) |
(&(objectClass=group)(managedBy=*)),
(&(objectClass=group)(managedBy=*)(groupType:1.2.840.113556.1.4.803:=2147483648)) |
| Get-NetComputer (PowerView) | (&(sAMAccountType=805306369)(dnshostname=*)) |
| Get-NetUser – Users (Powerview) | (&(samAccountType=805306368)(samAccountName=*) |
| Get-NetUser – SPNs (Powerview) | (&(samAccountType=805306368)(servicePrincipalName=*) |
| Get-DFSshareV2 (Powerview) | (&(objectClass=msDFS-Linkv2)) |
| Get-NetOU
(PowerView) |
(&(objectCategory =organizationalUnit)(name=*)) |
| Get-DomainSearcher (Empire) | (samAccountType=805306368) |
Once you spot anomalies in the queries, it is important to try and search for additional activities that can incriminate that it was indeed done maliciously. Having a suspicious query is often not enough to decide whether an attack is occurring or not.
-
Having a Good Audit Policy:
Configure 'Audit Policy: Account Management: Application Group Management' to 'success and failure'.
The default configuration of this object in most OS versions is 'No Auditing'. Changing configuration will report each event of application group management on a computer. If you enable this Audit policy setting, administrators can track events to detect suspicious actions. Among others are:
- * 4790: An LDAP query group was created.
- * 4792: An LDAP query group was deleted.
