When attacking or defending a network it is important to know the strategic points of the environment. In the case an environment is running Active Directory, as almost every organization in the world does, it is important to understand how rights and privilege relationships work, as well as how they are implemented. With relative ease, an attacker can take advantage of the fact that an unintended user was somehow added to a group with more elevated privileges than he/she needs. Once they are able to identify this the battle might be over before the defender has a chance to know what happened. In this blog post, we will go through how RSA NetWitness Network/Packets can be utilized to detect if BloodHound’s Data Collector (known as SharpHound) is being used in your environment to enumerate Group Membership via the LocalAdmin Collection method.
In order to automate the process of determining the privilege relationships in an environment, the incredibly talented group of @_wald0, @CptJesus, and @harmj0y created a very popular tool aptly named BloodHound. You can find this awesomeness at https://github.com/BloodHoundAD/BloodHound/. The tool is a single page Javascript web application, built on top of Linkurious, compiled with Electron, with a Neo4j database fed by a PowerShell/C# ingestor. The tool utilizes graph theory to reveal the hidden and often unintended relationships within an Active Directory environment. This is an incredibly awesome tool that provides a much needed insight into what is often a forgotten or mismanaged process. If you haven’t tried this out on your environment, offensive or defensive minded, I’d recommend it.
SharpHound is a completely custom C# ingestor written from the ground up to support collection activities. Two options exist for using the ingestor, an executable and a PowerShell script. Both ingestors support the same set of options. SharpHound is designed targeting .Net 3.5. SharpHound must be run from the context of a domain user, either directly through a logon or through another method such as RUNAS. The functionality we will be analyzing in this blog post is only a small percentage of what BloodHound/SharpHound can do and other portions will be covered in upcoming blog posts.
First let’s tackle some minimum requirements & some assumptions that we have put in place:
#1) This assumes you have a TAP location feeding your Decoder(s) somewhere between your workstations & your Domain Controllers (DC). This is a best practice to ensure that traffic flows to all critical devices, including DCs, are being captured.
#2) You’ve created a Feed with a list of your Domain Controllers & are tagging them appropriately. (While not 100% necessary this will definitely aid in analysis) This can easily be accomplished by modifying the Traffic Flow Lua Parser to include DC subnets, or one by one. Please see this guide for further details.
#3) BloodHound Data Collector is performing Local Admin Collection Method – SharpHound has several different enumeration options, as are listed on BloodHounds GitHub wiki, while it’s possible to catch some of these other options, this post will be focus in on how its Local Admin Collection Method works. Further technical details on how this method works can be found on @cptjesus's blog post here. CptJesus | SharpHound: Technical Details
#4) I am not an Active Directory or BloodHound expert by any stretch. What is detailed in this blog post is what a colleague (Christopher Ahearn) & I discovered by attempting to help our clients detect badness.
Now then, let’s begin.
Group Enumeration
As soon as SharpHound starts up it will attempt to connect to the workstation’s default Domain Controller over LDAP (TCP Port 389) with the current user’s privileges, in order to enumerate information about the domain. It is important to note the latest version (2.1) of SharpHound will grab a list of domain controllers available for each domain being enumerated, starting with the primary domain controller, and then do a quick port check to see if the LDAP service is available[1]. Once the first one is found, it will cache the domain controller for that domain and use it for LDAP queries. In our testing this traffic will contain LDAP searchRequests & binds, then becomes encrypted with SASL, which will provide no insight into what’s actually being enumerated, as depicted below. I know, frustrating.
However depending on the size of your domain this can be an indicator itself, as there can be a lot of data being transferred. Looking for one host with an abnormal amount of LDAP traffic can be a starting point to look for BloodHound, however, this is highly dependent on your environment as there may be legitimate reasons for the traffic.
What happens next can be used as a more high fidelity alert. The host running BloodHound will attempt to enumerate the group memberships for users found in the LDAP Queries. and does so in a unique manner. In order to enumerate this information the host creates an RPC over SMB connection to the Domain Controller. How this occurs is the host will first create a named pipe to SAMR - Security Account Manager (SAM) Remote Protocol (Client-to-Server) - over the IPC$ share.
Once this is accomplished the RPC Bind command is used to officially connect the RPC session. Now that the RPC session is available, SharpHound will attempt to request in the following order
- Connect5
- LookupDomain
- OpenDomain
- OpenAlias
- GetMembersInAlias
To start off, the SamrConnect5 method obtains a handle to a server object, while only requiring a string input for the ServerName. Next the session will call SamrLookupDomaininSamServer which required a handle to the server object provided by the SamrConnect5, in order to look up all the domains hosted by the server side protocol. Now that the session has a handle to work with, it then proceeds to look up the domain with and use SamrOpenDomain to obtain a handle for the Domain Object. As you can see this was an iterative process in order to get handle for first, the Server Object, then the Domain Object, which will then be used in SamrOpenAlias to obtain a handle to an alias. Finally the session will use the alias handle as input to the SamrGetMembersinAlias with the goal of enumerating the SIDs for the members of the specified alias object. After SamrGetMembersinAlias completes it’s response the SAMR session is then closed, and in it’s place an Local Security Authority (LSA) RPC session is started.
As the name states, the lsarpc interface is used to communicate with the LSA subsystem. Similar to how SharpHound had to find all the necessary handles in order to finally enumerate the SIDs in a given group, it must also find a Policy handle to convert the discovered SIDs from SamrGetMembership. In order to do that it utilizes OpenPolicy2, which only requires the SystemName, which in this case will be the DC. Once the OpenPolicy2 has finished & acquired the Policy Handle it then calls the LookupSids2 method in order to resolve the SIDs it acquired in the SamrGetMembersinAlias. Now the Data Collector has all the information it needs to provide information concerning what Users are in what groups.
During RSA’s enterprise testing of BloodHound, this unique way of enumerating Group Membership via SamrGetMembersinAlias, and subsequently looking up the acquired SIDs via LsarLookUpSids2 in the same session, has a very high detection rate of BloodHound activity. It should be noted that this activity has the potential to be normal activity depending on the various administration techniques being used by administrators, however, during our testing in various large environments we have not found an instance of its usage in that capacity.
Detecting with RSA NetWitness Packets
NetWitness packets does an incredible job dissecting the various different RPC & SMB actions that cross over capture points, which make creating detection rather simple. As the RPC session is being transported via SMB all of the necessary metadata found in our analysis is in one session.
The following application rule will flag sessions which contain this activity.
(service =139) && (directory = ‘\IPC$\') && (analysis.service = ‘named pipe’) && (filename = ‘samr’) && (action = ‘samrconnect5’) && (action = ‘SamrLookupDomaininSamServer’) && (action = ‘samropendomain’) && (action = ‘samropenalias’) && (action = ‘SamrGetMemberinAlias’) && (action = ‘lsaropenpolicy2’) && (action = ‘lsarlookupsids2’) |
Wrapping Up
This blog’s intent was to bring up new and interesting ways to detect BloodHound traffic with the specific context of running the LocalAdmin Collection method from a workstation in a domain to a DC. It’s possible that this traffic could be used legitimately via an Administrators script or it’s also possible that it might be an indicator for another tool using a similar enumeration method. Every environment is different from the next and each needs to be analyzed with the proper context in mind, including this traffic. If you are defending a network, I would encourage that you try out BloodHound, even if it’s just in a Lab environment, and see what your toolsets can detect. If you’re not already monitoring traffic going in and out of your DC’s I would also encourage you to try more play books aside this one attack vector, and to help determine potential visibility gaps. In the upcoming blog posts we’ll attempt detection of other methods used by Bloodhound.
[1] https://blog.cptjesus.com/posts/bloodhound21
1 Comment
