Once an adversary has access to the network, they’re going to begin the internal reconnaissance or ‘discovery’ phase to identify what level of access they have.
There are several ways to achieve this, which Vectra AI offers strong detection coverage for out of the box, but a prominent way is by querying active directory over LDAP (Lightweight Directory Access Protocol) which is an industry standard and a default protocol for Active Directory servers.
Using LDAP we can identify computers, accounts, groups and applications within the domain. Using this information, we can quickly identify targets of interest, why waste your time cracking passwords if the accounts won’t give you the permissions you need to RDP from your current host to the domain controller?
Common tools that leverage LDAP include Bloodhound, Sharphound and ADFind.
Detection Profile
Triggers
- This host is querying Active Directory using the LDAP protocol in a manner that appears like reconnaissance behavior
- The LDAP queries are either unusually broad in scope or are specifically targeting accounts and groups that have names which imply administrative privilege
Possible Root Causes
- An attacker is active inside the network and is mining information from one or more Active Directory servers in order to build a better map of assets in the network
- An admin is retrieving information from AD in order to complete a certain task or create a report • An auditing application installed on this host is retrieving information from AD as part of its core functionality
Steps to Verify
- Examine the Kerberos or Active Directory server logs for a more detailed view of activity by this host
- Inquire whether the host should be making the queries listed in the detection
- If the LDAP queries continue and remain unexplained, determine which process on the internal host is making the queries; in Windows systems, this can be done using a combination of netstat and tasklist commands
Business Impact
- A scan of information in an Active Directory server is an effective way for an attacker to determine what accounts are privileged inside an organization’s network and what the names of servers and infrastructure components are
- Reconnaissance within a network is a precursor to active attacks which ultimately exposes an organization to substantial risk of data acquisition and exfiltration
- This form of reconnaissance is often a lot less noticeable than a port sweep or a port scan so attackers feel they can use it with relatively little risk of detection
Example of a Suspicious LDAP Query
Starting in Vectra Recall Discover select the metadata_ldap* metastream and select a time period to begin, for this technique I’d start with a minimum of 24hr to ensure we have a sufficient data set. Next let’s get a picture of which servers are accepting LDAP requests by selecting the resp_ hostname on the left side of the screen.
I can see most of my requests are hitting IP-192.168.1.5, a hostname beginning with IP- is an IP host container and occurs when the Vectra AI platform hasn’t seen evidence on the network to identify the hostname associated with the IP address. This can sometimes occur for static IP addresses; we can improve hostname coverage by integrating RDNS and updating the setting page with static IP subnets such as ranges assigned to servers.
In my demo lab I know 192.168.1.5 is the primary domain controller and I’m going to filter for this specific IP by clicking on the magnifying glass with the + symbol. You’ll now see a pill filter added below the search bar.
These queries appear to be consistent, maybe it’s just some software running regular queries against my server? Using the same quick filters to the left of my screen I can quickly see the host ‘buckley-pc’ is responsible for all these requests. Typically, we wouldn’t expect to see such a large volume of requests from desktop or laptop unless there is some specific software that requires LDAP queries to function. I’ve only seen one example of this in the wild and that was for a manufacturing plant where the front-line manages ran local software to manage employees scheduling, that software made regular LDAP queries to get user information.
Next, I’m going to clean up my table view, I can do this by selecting the ‘x’ below each column header I want to remove, this will help me clean up the view and see the QUERY and RESULT fields better.
Once you have the right table view you can remove the query (objectClass=*), this is a common chatter query and although it returns all results I’m going to focus on targeted queries. Once this is complete, I can easily see what buckley-pc has been doing.
Straight away you should notice the times for these queries, these are far too fast for a user to manually query and must have been automated. The queries also appear to be very specific and iterating through different language variations of ‘Administrator’, lets break down one of these queries.
(&(objectcategory=person)(samaccountname=Administrator))
Very simply we can see two parameters, the first is the objectcategroy which is a single-valued property that contains the distinguished name of either the class of which the object is an instance or one of its superclasses. The second parameter is the logon name used to support clients and servers within Windows environments.
Taking another slightly more complicated example:
(&(objectCategory=computer) (userAccountControl1.2.840.113556.1.4.803=8192))
The new value here, userAccountControl, is the windows name for the User-Account-Control attribute and identifies the permission level of an account. Thankfully most of these user IDs are documented, the specific ID 1.2.840.113556.1.4.803 is used to identify objects that are domain controllers.
This activity is clearly reconnaissance type behavior and requires further analysis, but what have we learnt from this and how can we improve our hunting for next time? For a start we’ve identified a number of interesting queries the attacker was performing, how often do we see systems querying for Administrator account or looking for domain controllers? The following query will help us to determine this.
query:Administrator OR query:userAccountControl1.2.840.113556.1.4.803
I’ve now only got 70 hits total and all of these I’ve linked back to my attacker’s activity. If I’ve discovered an interesting account or query not common in my environment, I could consider creating a custom model and enabled it. The Vectra AI platform already has very good detection coverage for suspicious LDAP queries, but you might want to create some very specific models around unexpected queries for your environment.
For further information:
http://www.ldapexplorer.com/en/manual/109050000-famous-filters.htm