Sniffing Out the Bloodhound

Summary:

This blog post discusses the importance of assuming a company is already compromised when analyzing its attack lifecycle for early detection, which can reduce remediation costs. Neil Desai mentions Veris’s Adaptive Threat Division (ATD) using PowerShell for reconnaissance, lateral movement, and privilege escalation, mimicking advanced attackers to help defenders improve their security measures. John Lambert compares the approaches of defenders and attackers, highlighting how BloodHound, a project from Veris’s ATD, uses graph theory applied to Active Directory information to visualize pathways for gaining Domain Admin access, identifying internal network vulnerabilities and potential attack paths. Defenders can effectively detect such activities using tools like BloodHound by not relying solely on file signatures or hashes but instead focusing on the version of PowerShell being used, its setup in the environment, volume of related events, and the ratio between false positives and actual attacks. To gain more insights into BloodHound's functionality and detection methods, setting up a lab environment with specific configurations is recommended. For network traffic analysis, monitoring LDAP (TCP port 389) traffic and observing sessions that take significantly longer than others can indicate unusual activity warranting deeper investigation. Honeytokens are used to detect malicious activity by creating dummy accounts in Active Directory, which can be audited for attempts to enumerate these objects. Proper configuration of honeytokens includes enabling auditing and customizing the SmartConnector for better log consumption. The document emphasizes the importance of understanding BloodHound's functionality for future detection strategies and highlights shifting detection from easily bypassed signature-based detections to network and AD event logs, allowing organizations to remain undetected while monitoring specific triggers.

Details:

In this blog post, Neil Desai discusses the importance of companies assuming they are already compromised in their attack lifecycle, as early detection can reduce remediation costs. He mentions Veris’s Adaptive Threat Division (ATD) for abusing PowerShell for reconnaissance, lateral movement, and privilege escalation, mimicking advanced attackers to help defenders improve their security measures. John Lambert's post highlights the difference between how defenders and attackers approach security by comparing them to graph theory. Attackers think in graphs while defenders rely on lists of assets connected through security relationships. BloodHound, a project from Veris’s ATD, uses graph theory applied to Active Directory information to visualize pathways for gaining Domain Admin access, providing insights into internal network vulnerabilities and potential attack paths. The text discusses the use of Bloodhound and similar tools by defenders to minimize noise and focus on specific targets for detection. It emphasizes that while easy paths might be eliminated, the continuous cat and mouse game between defenders and attackers means monitoring activity is crucial. To effectively detect such activities using tools like BloodHound, it's important not to rely solely on file signatures or hashes, as these can be easily bypassed. Instead, attention should be paid to the version of PowerShell being used, its setup in the environment (e.g., WEF and configuration), volume of related events, and the ratio between false positives and actual attacks. To gain insights into BloodHound's functionality and detection methods, setting up a lab environment is recommended. This includes deploying Windows servers with specific configurations to mimic real-world scenarios. Additionally, examining the source code on Github, reading through the wiki pages, and watching presentations can provide valuable information about how these tools operate and where they can be detected. The text describes the use of ArcSight SmartConnector (Windows Native) for monitoring security, application, and system logs on a domain controller. It mentions Bloodhound, which is used for data ingestion and visualization within an enterprise network. BloodHound relies on Powerview for its reconnaissance capabilities due to its ability to work with PowerShell version 2.0 without additional modules or RSTAT (Remote Server Administration Tools). This allows it to run smoothly on Windows 7 or newer operating systems, even by non-administrative users. To utilize BloodHound effectively, the user needs to enable Windows Event Logging on the domain controller and configure auditing for all categories/subcategories related to both success and failure events using commands like "AUDITPOL /SET /CATEGORY:* /SUCCESS:ENABLE /FAILURE:ENABLE" and "AUDITPOL /GET CATEGORY:*". Prior to running BloodHound, baselines are established by monitoring the number of events generated across two active channels—one for all Windows events and another specifically tracking activities related to a target user. Additionally, Wireshark is used without any capture filters to observe traffic patterns associated with BloodHound during its operation. In this lab setup with multiple hosts, we focus on monitoring traffic directed towards the domain controller (DC). After employing BloodHound for analysis, we observe that generated logs are minimal despite the absence of any running services in the lab. In a real-world scenario, such as a production environment, these logs would be significantly more noticeable due to increased network activity related to BloodHound's operations. Utilizing Wireshark for network traffic capture and analysis, we notice that one specific conversation accounts for 70M bytes of data—a substantial portion compared to the rest of the conversations combined. The majority of this traffic is LDAP (TCP port 389). Further protocol breakdown in Wireshark reveals that most of the traffic is indeed LDAP-related. When examining regular event logs, we find they are unhelpful since all events pertain to LDAP and do not trigger Kerberos or NTLM logon events beyond initial authentication for LDAP queries. This lack of detailed logging makes it difficult to glean useful information from these logs. For network traffic analysis, if you have flow or sFlow logs, consider enabling rules to log high volumes of LDAP traffic. Additionally, look for sessions that take significantly longer than others—these are typically indicative of unusual activity and warrant deeper investigation. Each environment will require its own specific approach; a useful method involves running BloodHound while monitoring with a network capture tool to understand the typical data volume and response times in your setup. Since LDAP is primarily used for information search, queries should be focused on specific items and thus quick with minimal data transfer. An example of abnormal behavior is when BloodHound enumerates all user accounts, which deviates from normal LDAP query patterns. Honeytokens are a method used to detect malicious activity, especially from users. They work by creating dummy accounts in directories like Active Directory, which can then be audited for any attempts to enumerate these objects. To effectively use honeytokens for detection, follow these steps: 1. Enable "Directory Service Access" subcategory under "DS Access." 2. Create user and group accounts with a spread-out naming convention across the alphabet. 3. Ensure group accounts contain both regular user accounts and honeytoken accounts. 4. Enable "Advanced Features" in the "Active Directory Users and Computers" MMC. 5. Set up auditing by:

• Clicking on the Security tab for the object.

• Navigating to "Advanced (1)-> Auditing (2) -> Add (3)."

• Setting Principal to Everyone, Applies to to This object only, and Permissions to Read all properties.

6. Enable auditing event ID 4662 by enabling proper settings. 7. Customize the SmartConnector for better log consumption:

• Add a parser override to normalize GUIDs.

• Create map files to map schema GUIDs (user and group) and user/group-specific information.

These steps ensure that honeytokens are effectively used to detect malicious activity in directory services. This document discusses implementing auditing in Active Directory (AD) environments to detect internal reconnaissance tools like BloodHound. The primary goal is to track user enumeration of AD objects without revealing the tool's presence through audit events. After enabling auditing, running BloodHound will show logged audit events; these indicate the username of the person enumerating the objects but not the specific host or device used. To effectively implement this, a one-week review period is recommended to investigate any accounts that are performing AD user/group object enumeration. During this time, it's crucial to differentiate between legitimate servers and applications that require such activities from potential adversaries. Postpone filtering out known systems after thorough vetting. The conclusion emphasizes the importance of understanding BloodHound's functionality for better detection in future strategies. By shifting detection to network and AD event logs, organizations can remain undetected while monitoring for specific triggers rather than relying on easily bypassed signature-based detections. The document also provides references to external resources that further discuss related topics and tools like Microsoft Enterprise Cloud Red Teaming, FireEye's threat research, and BloodHound's GitHub repositories and wiki pages.

Disclaimer:

The content in this post is for informational and educational purposes only. It may reference technologies, configurations, or products that are outdated or no longer supported. If there are any comments or feedback, kindly leave a message and will be responded.