Introduction to Targeted Log Collection
In the first post of the series, we mentioned domain and DNS log collection guidance in the industry including NSA. These configurations and publications are usually born out of defense research, completing the life cycle from offensive research, defense, and then back to the implementers of SIEM and telemetry systems. NSA published Spotting the Adversary report, for example, and JPCERT (Coordination Center) in Japan analyzed which log events were due to known malware tools such as Windows EventID 5156, which indicates a new network connection event. We also covered a log deployment sample, but only covering the numbers, to give us an idea of the scale of telemetry collection in an enterprise environment.
In this part of the series, we will be focusing on the relationship and role of logging metadata with defensive security (blue/purple teaming). It also helps to consider previous research work conducted in the past.
Log Sources and MITRE ATT&CK
A lack of targeted approach to security logging can lead to performance issues by the log agents, excessive SIEM and agent licensing and subscription costs, excessive infrastructure requirements, noise and alert fatigue, insufficient log collection, and more. OWASP has even advised not to log too much (as well as too little) as a security logging implementation best practice. In addition to following the guidance and resources from the inaugural post of this series, another blue team and defensive practice is to map out log sources with frameworks like MITRE ATT&CK to ensure that log data elevates threat hunting and security operations can configure better alerts and triage rules.
What is the MITRE ATT&CK Framework
MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. Above is a screenshot of the MITRE ATT&CK Navigator v4.0 for Enterprise, also available on GitHub.
Specific MITRE ATT&CK Log Sources
The following are log sources that relate to a MITRE ATT&CK Tactic. These logs are specific to use cases that DomainTools cover for Iris Detect, Iris Investigate, and APIs such as:
- Finding domain IOCs via Risk Score, Threat Profile, or investigations in the Iris Investigate UI.
- Finding valuable metadata, such as email addresses, as a seed term for investigations on the Iris web platform.
- Using the APIs, such as the Reverse IP API, to find domains associated with an IP address.
Which Sources Do Defenders Need to Add for Their Log Collection Scope?
Post-Exploitation Hunting with Logs: Mimikatz, a Credential Stealing Tool
The following are types of log source examples* to detect a Mimikatz attack but is more related to logs showing DNS, IP, and domain-related metadata:
- Windows Sysmon Logs
- Sysmon is a utility tool that offers a robust and extended log collection capacity. For example, one can configure Sysmon to help log the trail of utility tools that attackers use with Sysmon process logging.
- You can also use Sysmon to collect DNSQuery events, FileDelete events, WMI (Windows Management Instrumentation) related events, and more.
- Windows PowerShell Event Log and Logging via
- PowerShell is a common utility tool that is used to automate tasks in a Windows environment. The PowerShell event source itself can be targeted, such as attackers disabling event tracing of the Windows PowerShell ETW Event Provider.
- It is possible to not only log PowerShell Windows Events (via Windows Event Log or Event Tracing for Windows) but also PowerShell logging can be enabled via editing the GPO settings.
- The Invoke-Mimikatz script is recorded via the Microsoft-Windows-PowerShell/Operational channel (from JPCERT CC) as well as the Destination IP address/Host name/Port number upon success.
- Windows DNS Debug Logging
- Very verbose source of DNS logs that contains very detailed data of DNS information sent and received by the DNS server. Available from Windows Server DNS (2012R2 onwards with this hotfix).
- Windows DNS Analytical Logging
- “Informational” type of events available from Windows Server DNS (2012R2 onwards with the above hotfix). The types of events include RESPONSE_SUCCESS events which contain the destination IP address, QNAME (or, the Query Name like example.com).
*These examples are from the “Hunting for Post-Exploitation Stage Attacks with Elastic Stack and the MITRE ATT&CK Framework” research. We have the Elastic App integration to provide a better understanding of threats in your network utilizing logs collected from your network such as proxy logs.
The Challenges of Processing Metadata
Even after log source collection, there is still the challenge of processing (structuring, extracting, enriching) the valuable metadata within these logs. Parsing the metadata benefits security operations because it leads to more targeted rules (for dashboards, search indexes, or to filter for investigations), alerts, or to use the data for additional analysis like investigating domain IOCs within your SIEM/SOAR.
Which Log Sources Reveal IP/Hostname Exfiltration?
Let’s take a look at a couple of log sources mentioned previously in the MITRE ATT&CK Tactics section. In this case, we look at the Exfiltration MITRE Tactic and see which log sources are relevant for domain/hostname/IP related IOC investigations.
Detection: Collect PowerShell logs from the Windows PowerShell ETW Provider
These logs contain metadata of commands that attackers use on PowerShell. New network connections made or attempted will be logged and include the IP (internal or external) as the destination. These are signs of exfiltration (uploading and sending data to a malicious endpoint).
Even if the payload were base64 obfuscated commands or data, thus making it difficult to parse and create rules for since rules depend on certain patterns, collecting such logs can still help to find any outliers. There are additional analysis tools like the ee-outlier tool by NVISO-BE for these types of tasks.
Detection: Finding DNS Tunneling via Logging and Monitoring or DNS Queries and Responses
DNS Tunneling (a method of Exfiltration Over Alternative Protocol) is where “adversaries may steal data by exfiltrating it over a different protocol than that of the existing command and control channel.” Attackers can use the DNS subdomain field to exfiltrate data, in addition to other ways to misuse the DNS protocol for attacks
DNS tunneling to a command and control server uses the DNS protocol as a way to obfuscate attacks. One of the reasons for this technique is that defenders have an easier time monitoring for bad activity on the more common endpoints such as RDP, DNS tunneling abuses the DNS protocol to sneak in commands and data like exfiltration. Finding DNS tunneling attacks involves logging DNS queries and responses.
Note: If you are interested to learn more about these types of logs and metadata, upcoming parts of this series will focus more on log deployments and log samples.
The Value of Log Collection
In this part of the series, we further read into the security value gleaned from targeted log collection. Targeted log collection is to be aware that not all log sources are the same in terms of log event reliability and quality. Ensuring these log sources are part of your exposure helps provide indicators of compromise (IOCs) to move forward with an Iris investigation pathway, or investigations via the API or a DomainTools integration.
Every so often, we receive requests for (possible) post-exploitation help and to dive into domain data to find post-exploitation clues. While the series does not delve into operational parts of threat hunting, it is important that deployments see the value of increasing log exposure, despite the challenges of managing log sources (and their log types, metadata, any missing fields, and so on). In the next series, we get into the specifics of these, covering the opportunities and challenges in both Windows and Linux platforms respectively.
To learn how to identify and track adversary operations in DomainTools Iris Investigate visit our product page.
Heading
