Win the hearts of incident responders with Windows logging

While breaches come in many different forms—ransomware, intellectual property theft, defacement—incident responders look for one commonality: traces of an attacker.

According to Locard's exchange principle, in physical forensics, every contact leaves behind a trace—for example, fingerprints, blood, or a shoe impression. In digital forensics, we look for traces in memory, on the network, or within any of a number of filesystem artifacts on disk. Each source has its own strengths and weaknesses, and artifact gathering is a team sport that engages network engineering, Windows and Linux administration, and cloud teams.

While many artifacts exist across these disciplines, it’s Windows event logs that provide the most bang for the buck on endpoints. Whether raw or ingested into a SIEM, they are what incident responders most commonly request.

Their effectiveness, however, is another story. It depends on what they are set to store or ignore, with  the definition of proper logging differing by role:

• IT Workstation Support
• IT Domain Administrator
• Audit and Compliance / Management
• Security Operations Center (SOC) Analyst
• Incident Responder

For this reason, it’s important to understand who architected your current log configuration and why. If the who is your Windows administrators, then while priorities can vary by role, typical responsibilities include maintaining a Windows domain and applications, ensuring access to business resources, meeting uptime SLAs, patching operating systems and applications, and satisfying audit compliance. Responsibilities may also extend to architecture, including both physical components and virtual environments. The point is that log configurations are often not oriented to benefit a future investigation.

For mature environments, log configuration input may come from a compliance team, information security, or a commercial product as an automatic default build. When the machine goes production, do you know if it will satisfy an incident responder’s needs? How sure are you that attacker actions are sufficiently recorded when you learn an attacker deployed ransomware from your domain controller? Have your logs run the IR gauntlet?

“Hope in the form of glorious combat, battle is the great redeemer, the fiery crucible in which the only true heroes are forged.“  - Master Sergeant Farell from Edge of Tomorrow

This quote sums up why I’m writing this blog. I want to put my experience into the hands of those who haven’t yet compiled the mountains of possibilities. After the why comes the what, which is the importance of what we can log. Let’s start with the MITRE ATT&CK® framework that has input from the global security community. The ATT&CK matrix is a framework that defines the tactics and techniques that an attacker may use to advance towards their goals. As an incident responder, my goal is to both satisfy the logging needs for what is most commonly needed for ATT&CK detection as well as what is most useful for an IR engagement. I consider this a “phase 0” transformation because it does not require architecting in a new solution. Without an upfront investment in technology, our research shows this exercise grows host visibility while maximizing existing ROI by intelligently double-downing on basic logging.

Before I dive into the most effective sources in detecting the techniques described in the ATT&CK matrix, I must emphasize a few core logging musts.

1. Maintain a central repository.

If logs aren't available, it won’t matter how much effort you put into their preparation. For example, what if endpoint log retention lacks the history to roll back time for any reason? The answer could include pulling from backups or a volume shadow copy, but these are often targeted by ransomware-lobbing attackers. A central logging solution solves the problem by storing forwarded logs in near real-time. If the remote host becomes a smoldering mess like a T-800 being lowered into molten metal[1], you’ll know that the last-generated log is safe. A central logging solution doesn't necessarily mean a monitoring platform, but since you have these logs, why not take advantage of the data?

2. Choose a log size to match the log volume.

During an incident response, detailed logs are crucial for extracting key activities. Accurate logs produce a faster IR, resulting in a higher-confidence report at a lower cost. Without log forwarding, the single source of logs is on the endpoint in an unknown state with an unknown amount of history.

Unfortunately, it’s common to find security event logs without enough history to cover the time period of an incident. With an insufficient log size, the busier the host, the less history is available. It's also not uncommon for a short flood of login attempts to cause the log to roll and leave one hour of activity.

Spend the time to do the math, set the Group Policy Objects (GPO), sample the results, and refine the configuration.

3. Ensure maximal coverage and make alternate accommodations for exceptions.

To help with decisions, consider:

• • Are all Windows endpoints joined to the domain?
  • Is log configuration within a central GPO policy applied to all hosts?
  • Is your team auditing GPO changes to ensure full adoption?

Let's get technical: What’s important to incident responders

Incident responders must answer the who, what, when, where, and how as quickly as possible—and to do so, we start with the highest fidelity logs. The following table is built from the Accenture Security IR team’s detect ruleset. The table lists the categories of event log sources that are used to detect an attacker’s action within each ATT&CK tactic. The tactics on the x-axis from “Initial Access” to “Impact” are the order in which an attacker progresses towards their goals. The numbers are the frequency of ATT&CK queries that use this data source during a single technique. For visual emphasis, the larger numbers are red while the smaller are green.

Frequency of log source in Accenture Security’s MITRE ATT&CK®-based queries

<<< Start >>>

<<< End >>>

Process execution logging: Security

Process execution is the most important event for adding context to all user activity—and it’s also the easiest way to learn of actions performed without diving into less detailed artifacts. The Accenture Security ATT&CK queries we use in investigations contain 146 lookups using process execution (Event ID 4688) as the source of data. For the most important log, it’s the least often enabled.

Below, see if you can spot the differences in logging detail that we often see during investigations. Try to answer these three questions.

• What did the account execute?
• Was the use of net.exe suspicious and worth pursuing?
• To what other data can I pivot and investigate?

To determine intent in anything but full logging, you will need to transition to other artifacts of execution.

For details, visit Cyber Security Corner to read “Enable Command Line and PowerShell Audit For Better Threat Hunting.”

PowerShell logging: Microsoft-Windows-PowerShell/Operational

Similar to process execution, with PowerShell logging, you want to answer the same questions but for items run within PowerShell. We can't stress enough the value-add of full script block logging. It should be noted that transaction logging is available but not recommended as a permanent fixture. Transaction logging will provide a deobfuscated result, but be cautious because transaction output may contain sensitive data that all users can access.

Below is a responder’s visibility, where you can see the difference in output without module and script block logging enabled. This assumes command-line logging 4688 is enabled.

For details, visit PowerShell the Blue Team.

Authentication logs basics: Security

Both successful and failed login attempts are important as they differentiate between a failed or successful brute-force login attempt. In cases of account compromise, it allows for the tracking of who, how, from where, and when within the investigation. A logoff shows a distinct end of a session. A logon ID is a hexadecimal value found in security event logs that allows for user session tracking across multiple log entries. Explicit login means an account has changed context to another account—for example, why is Fred switching to John's SA account? The most common false positive reason is when a non-privileged user switches to a privileged account.

For details, visit Hacking Articles.

Authentication logs advanced: Security

If an adversary (or a red team) is attempting to acquire new credentials and elevate privileges to gain administrator rights, there are many trivial methods for acquiring a password hash or valid Kerberos key. Once acquired, they will likely use Kerberoasting, pass-the-hash, pass-the-ticket, or a golden ticket—all elements a defender must understand well. It’s not easy to detect these activities, but event IDs can help. Some attacks can be determined with only workstation logs, while others require domain controller logs. Without knowledge of how attackers act, defenders will heavily underestimate evil on the wire. For more information, please see the links regarding Kerberoasting and the Bloodhound tool.

For details, visit:
https://www.sans.org/blog/kerberos-in-the-crosshairs-golden-tickets-silver-tickets-mitm-and-more/,
https://www.praetorian.com/blog/active-directory-visualization-for-blue-teams-and-threat-hunters

Account manipulation: Security

When you understand what’s happening to an account, some actions stand out.

• Why are marketing users being added to a security-enabled group?
• Why are disabled ex-employee accounts now enabled?
• What accounts were created since an incident?
• Why did a user account change its name to match the scheme of a service account?
• What user accounts have, but don’t deserve, elevated permissions?
• Did brute force login attempts lock out any users?

For details, visit Hacking Articles.

 Scheduled tasks: Security + TaskScheduler

By setting a scheduled task job to run at intervals, attackers can gain persistence and maintain access beyond reboots and installed software inspection. If attackers create a scheduled job using administrative access, they can run code as SYSTEM.

For details on these event IDs, visit: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4698.

Windows services control: Security

Because attackers have many uses for new or altered services, it’s critical to have visibility over service additions, changes, and deletions.

• Persistence: If the machine is restarted, the service can execute malicious code to rerun the attacker's malware.
• Lateral movement: Remote execution with psexec creates a service on the remote host.
• Defense evasion: Since a service is started by services.exe, it hides under a legitimate parent process.
• Privilege escalation: Run a process not as the attacker but as a service account.

For details, visit:
https://az4n6.blogspot.com/2017/10/finding-and-decoding-malicious.html
https://attack.mitre.org/techniques/T1543/003/

WMI monitoring: Microsoft-Windows-WMI-Activity/Operational

Attackers can use Windows Management Instrumentation (WMI) for persistence through code execution using defense evasion (who monitors WMI execution, anyway) and WMI’s concept of binding a consumer to a filter. The details of WMI are reserved for offline reading, but attackers can use WMI to execute PowerShell.

For details, visit:
https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/wp-windows-management-instrumentation.pdf
https://github.com/esecrpm/WMI_Forensics

BITSAdmin: Microsoft-Windows-Bits-Client

Bitsadmin is a Microsoft tool for downloading Windows updates; however, it can be utilized by any account. It's an alternative method for downloading malicious files that avoids PowerShell and Process Creation logging. As a defender, you want to find the mechanism by which an attacker fetches a malware payload in order to ultimately find patient zero. Finding this mechanism allows you to sweep the environment for the same tactics, techniques, and procedures, and remediate the attack vector.

For details, visit https://mgreen27.github.io/posts/2018/02/18/Sharing_my_BITS.html.

WinRM (Remote PowerShell): Microsoft-Windows-WinRM/Operational

When remote PowerShell is enabled, WinRM logs the session, but other event logs record all the detailed actions. The process ID within WinRM logs correlates to events within PowerShell/Operational and WMI-Activity/Operational logs. If you enable process execution, you can further link it to the process execution event. If you are hunting, ensure that your filters perform a temporal search (i.e., You must group PIDs not only by host but also by time window since PIDs will repeat over time).

For details, visit:
https://www.blackhat.com/docs/us-14/materials/us-14-Kazanciyan-Investigating-Powershell-Attacks-WP.pdf.

Object monitoring: Security

If malware puts its grubby fingers on a key in the registry, a network share, or removable storage, object monitoring will log that operation. Forensic timelining accessed files, executables, directories, and network shares adds context to what we already know. Enabling object audit functionalities dramatically increases the log volume. Choose wisely.

For details, access:
https://www.netsurion.com/articles/auditing-file-shares-windows-security-log.

Host firewall logging: Security (optional)

East-west firewall traffic references network data between two internal hosts. This is seldom available due to cost and complexity. If the Windows host firewall logging is enabled, the endpoints can store network traffic. You can use host firewall logging to help identify cross-traffic, but enablement comes at a cost in terms of storage. Event ID 5156 records the who, what, and when of network traffic. Event ID 5157 provides the same answers but only connections blocked by the firewall.

Host firewall logging is valuable for answering questions like:

• Why is one workstation talking to another directly?
• Why is Person A in HR connecting to a DB server?
• What remote access protocols by port number and source IP are in use?
• Is witnessed port scanning originating from corporate vulnerability scanners?

Configuring logging with group policy

Below is the guide to configuring GPO to what was described above. It’s an à la carte approach and accounts for the hard decision to not enable logging that either has too high of a cost or is not relevant for an environment.

To start, open the Group Policy editor, and navigate to the following section:

Windows Settings, Security Settings, Advanced Audit Policy configuration

Process creation with command-line logging

PowerShell script block logging

Highly optional: Enable DNS client logging

If DNS query and response logging isn’t available, each Windows host can log its lookups. There is no group policy entry supporting it. It should be run on each endpoint.

• wevtutil sl Microsoft-Windows-DNS-Client/Operational /e:true

If you would like additional information on ways to leverage Windows logging for incident response, contact a member of our CIFR team 24/7/365 by phone 888-RISK-411 or email CIFR.hotline@accenture.com.

Accenture Security is a leading provider of end-to-end cybersecurity services, including advanced cyber defense, applied cybersecurity solutions and managed security operations. We bring security innovation, coupled with global scale and a worldwide delivery capability through our network of Advanced Technology and Intelligent Operations centers. Helped by our team of highly skilled professionals, we enable clients to innovate safely, build cyber resilience and grow with confidence. Follow us @AccentureSecure on Twitter or visit us at www.accenture.com/security.

This document is produced by consultants at Accenture as general guidance. It is not intended to provide specific advice on your circumstances. If you require advice or further details on any matters referred to, please contact your Accenture representative. This document makes descriptive reference to trademarks that may be owned by others. The use of such trademarks herein is not an assertion of ownership of such trademarks by Accenture and is not intended to represent or imply the existence of an association between Accenture and the lawful owners of such trademarks.

Copyright © 2020 Accenture. All rights reserved. Accenture, and its logo are trademarks of Accenture.

___

[1] Terminator 2: Judgment day [Motion picture]. (2011). London: ITV2.