This module is centered on detecting intrusions targeting Windows and Active Directory. With Splunk as the foundational tool for probing, this module is designed to endow learners with the knowledge to proficiently spot Windows-centric threats, tapping into the insights of Windows Event Logs and Zeek network logs. Additionally, participants will have access to genuine PCAP files related to the explored Windows and Active Directory incursions, further amplifying their grasp on specific attack trajectories and tactics.
This module will provide proficiency in detecting:
- User/domain reconnaissance
- Via native tools
- Using BloodHound/SharpHound
- Password spraying
- LLMNR poisoning
- Techniques like Kerberoasting and AS-REProasting
- Methods like Pass-the-hash and Overpass-the-Hash
- Golden and Silver tickets
- Unconstrained and Constrained delegation attacks
- DCSync and DCShadow attacks
- RDP Brute Force Attacks
- Beaconing Malware
- Nmap Port Scanning
- Kerberos Brute Force Attacks
- Cobalt Strike's PSExec
- Exfiltration via HTTP(S) and DNS
Key Learning Areas:
Insight into Windows Event Logs:
- Delve into the essence of Windows Event Logs and their significance in safeguarding Active Directory.
- Bolster analytical prowess to spot anomalies and possible security compromises within the logs.
Understanding Zeek Network Logs:
- Traverse the landscape of network threats targeting Active Directory, facilitated by Zeek logs.
- Cultivate the ability to distinguish between harmless network flows and suspicious activities.
Analysis of PCAP Files:
- Engage with authentic PCAP files extracted from documented Windows & Active Directory attacks.
- Thoroughly examine these data to discern prevalent intrusion paths and techniques.
This module is broken into sections with accompanying hands-on exercises to practice the techniques we cover. The module ends with a practical hands-on skills assessment to gauge your understanding of the various topic areas.
As you work through the module, you will see detection examples for the topics introduced. It is worth reproducing as many of these examples as possible to reinforce further the concepts presented in each section. You can do this in the target host provided in the interactive sections or your virtual machine.
You can start and stop the module anytime and pick up where you left off. There is no time limit or "grading," but you must complete all of the exercises and the skills assessment to receive the maximum number of cubes and have this module marked as complete in any paths you have chosen.
The module is classified as "medium" and assumes basic knowledge of Windows event logs, Zeek logs, and common attack principles
A firm grasp of the following modules can be considered prerequisites for successful completion of this module:
- Windows Event Logs & Finding Evil
- Understanding Log Sources & Investigating with Splunk
- Working with IDS/IPS
Detecting Common User/Domain Recon
Active Directory (AD) domain reconnaissance represents a pivotal stage in the cyberattack lifecycle. During this phase, adversaries endeavor to gather information about the target environment, seeking to comprehend its architecture, network topology, security measures, and potential vulnerabilities.
While conducting AD domain reconnaissance, attackers focus on identifying crucial components such as Domain Controllers, user accounts, groups, trust relationships, organizational units (OUs), group policies, and other vital objects. By gaining insights into the AD environment, attackers can potentially pinpoint high-value targets, escalate their privileges, and move laterally within the network.
User/Domain Reconnaissance Using Native Windows Executables
An example of AD domain reconnaissance is when an adversary executes the
net group command to obtain a list of
Common native tools/commands utilized for domain reconnaissance include:
wmic computersystem get domain
net user /domain
net group "Domain Admins" /domain
For detection, administrators can employ PowerShell to monitor for unusual scripts or cmdlets and process command-line monitoring.
User/Domain Reconnaissance Using BloodHound/SharpHound
BloodHound is an open-source domain reconnaissance tool created to analyze and visualize the Active Directory (AD) environment. It is frequently employed by attackers to discern attack paths and potential security risks within an organization's AD infrastructure. BloodHound leverages graph theory and relationship mapping to elucidate trust relationships, permissions, and group memberships within the AD domain.
Sharphound is a C# data collector for BloodHound. An example of usage includes an adversary running Sharphound with all collection methods (
BloodHound Detection Opportunities
Under the hood, the BloodHound collector executes numerous LDAP queries directed at the Domain Controller, aiming to amass information about the domain.
However, monitoring LDAP queries can be a challenge. By default, the Windows Event Log does not record them. The best option Windows can suggest is employing
Event 1644 - the LDAP performance monitoring log. Even with it enabled, BloodHound may not generate many of the expected events.
A more reliable approach is to utilize the Windows ETW provider
Microsoft-Windows-LDAP-Client. As showcased previously in the
SOC Analyst path, SilkETW & SilkService are versatile C# wrappers for ETW, designed to simplify the intricacies of ETW, providing an accessible interface for research and introspection.
SilkService supports output to the Windows Event Log, which streamlines log digestion. Another useful feature is the ability to employ
Yara rules for hunting suspicious LDAP queries.
In addition, Microsoft's ATP team has compiled a list of LDAP filters frequently used by reconnaissance tools.
Armed with this list of LDAP filters, BloodHound activity can be detected more efficiently.
Let's now navigate to the bottom of this section and click on "Click here to spawn the target system!". Then, access the Splunk interface at http://[Target IP]:8000 and launch the Search & Reporting Splunk application. The vast majority of searches covered from this point up to end of this section can be replicated inside the target, offering a more comprehensive grasp of the topics presented.
Detecting User/Domain Recon With Splunk
You'll observe that a specific timeframe is given when identifying each attack. This is done to concentrate on the relevant events, avoiding the overwhelming volume of unrelated events.
Now let's explore how we can identify the recon techniques previously discussed, using Splunk.
Detecting Recon By Targeting Native Windows Executables
index=main source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventID=1 earliest=1690447949 latest=1690450687 | search process_name IN (arp.exe,chcp.com,ipconfig.exe,net.exe,net1.exe,nltest.exe,ping.exe,systeminfo.exe,whoami.exe) OR (process_name IN (cmd.exe,powershell.exe) AND process IN (*arp*,*chcp*,*ipconfig*,*net*,*net1*,*nltest*,*ping*,*systeminfo*,*whoami*)) | stats values(process) as process, min(_time) as _time by parent_process, parent_process_id, dest, user | where mvcount(process) > 3
Filtering by Index and Source: The search begins by selecting events from the main index where the source is
XmlWinEventLog:Microsoft-Windows-Sysmon/Operational, which is the XML-formatted Windows Event Log for Sysmon (System Monitor) events. Sysmon is a service and device driver that logs system activity to the event log.
EventID Filter: The search is further filtered to only select events with an
1. In Sysmon, Event ID 1 corresponds to
Process Creationevents, which log data about newly created processes.
Time Range Filter: The search restricts the time range of events to those occurring between the Unix timestamps 1690447949 and 1690450687. These timestamps represent the earliest and latest times in which the events occurred.
Process Name Filter: The search then filters events to only include those where the process_name field is one of a list of specific process names (e.g.,
ipconfig.exe, etc.) or where the
powershell.exeand the process field contains certain substrings. This step is looking for events that involve certain system or network-related commands, as well as events where these commands were run from a Command Prompt or PowerShell session.
Statistics: The stats command is used to aggregate events based on the fields
user. For each unique combination of these fields, the search calculates the following statistics:
values(process) as process: This captures all unique values of the
process fieldas a multivalue field named
min(_time) as _time: This captures the earliest time (
_time) that an event occurred within each group.
Filtering by Process Count: The where command is used to filter the results to only include those where the count of the process field is greater than
3. This step is looking for instances where multiple processes (more than three) were executed by the same parent process.
Detecting Recon By Targeting BloodHound
index=main earliest=1690195896 latest=1690285475 source="WinEventLog:SilkService-Log" | spath input=Message | rename XmlEventData.* as * | table _time, ComputerName, ProcessName, ProcessId, DistinguishedName, SearchFilter | sort 0 _time | search SearchFilter="*(samAccountType=805306368)*" | stats min(_time) as _time, max(_time) as maxTime, count, values(SearchFilter) as SearchFilter by ComputerName, ProcessName, ProcessId | where count > 10 | convert ctime(maxTime)
Filtering by Index and Source: The search starts by selecting events from the main index where the source is
WinEventLog:SilkService-Log. This source represents Windows Event Log data gathered by
Time Range Filter: The search restricts the time range of events to those occurring between the Unix timestamps 1690195896 and 1690285475. These timestamps represent the earliest and latest times in which the events occurred.
Path Extraction: The
spathcommand is used to extract fields from the
Messagefield, which likely contains structured data such as
spathcommand automatically identifies and extracts fields based on the data structure.
Field Renaming: The
renamecommand is used to rename fields that start with
XmlEventData.to the equivalent field names without the
XmlEventData.prefix. This is done for easier reference to the fields in later stages of the search.
Tabulating Results: The
tablecommand is used to display the results in a tabular format with the following columns:
tablecommand only includes these fields in the output.
sortcommand is used to sort the results based on the
_timefield in ascending order (from oldest to newest). The
0argument means that there is no limit on the number of results to sort.
Search Filter: The search command is used to filter the results to only include events where the
SearchFilterfield contains the string
*(samAccountType=805306368)*. This step is looking for events related to LDAP queries with a specific filter condition.
statscommand is used to aggregate events based on the fields
ProcessId. For each unique combination of these fields, the search calculates the following statistics:
min(_time) as _time: The earliest time (
_time) that an event occurred within each group.
max(_time) as maxTime: The latest time (
_time) that an event occurred within each group.
count: The number of events within each group.
values(SearchFilter) as SearchFilter: All unique values of the
SearchFilterfield within each group.
Filtering by Event Count: The
wherecommand is used to filter the results to only include those where the
countfield is greater than
10. This step is looking for instances where the same process on the same computer made more than ten search queries with the specified filter condition.
Time Conversion: The
convertcommand is used to convert the
maxTimefield from Unix timestamp format to human-readable format (