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.
- 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, 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?
- 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.
- 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?
|The three observance states of process execution tracking|
Logging level 1: Process Tracking (no results)
Logging level 2: Detailed Tracking (are these malicious or routine maintenance)
Logging level 3: Command-line Enabled (Intent may now be discernable)
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.
|The three observance states of PowerShell Execution|
4688 (Security): Command-line logging
4103: PowerShell Module logging enabled
4104: PowerShell Script block logging
For details, visit PowerShell the Blue Team.
Authentication logs basics: Security
|4624, 4625, 4634: Login successful, failed, and logoff
4672: Special Privileges at login (Admin)
4748: Explicit Login (RunAs / User identity changes)
4800: The workstation was locked.
4801: The workstation was unlocked.
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
|4768: Kerberos authentication ticket (TGT) was requested
4769: Kerberos service ticket (TGS) was requested
4770: Kerberos service ticket was renewed
4771: Kerberos ticket requests
4776: DC attempted to validate credentials for account
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:
Account manipulation: Security
|4732: A member was added to a security-enabled local group
4703, 4704: A user's rights are assigned / changed
4720: A user account was created.
4722: A user account was enabled.
4723: An attempt was made to change an account's password.
4724: An attempt was made to reset an account's password.
4725: A user account was disabled.
4726: A user account was deleted.
4738: A user account was changed.
4740: A user account was locked out.
4766: An attempt to add SID History to an account failed.
4767: A user account was unlocked.
4741: A computer account was created.
4742: A computer account was changed.
4743: A computer account was deleted.
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
|4698: A scheduled task was created.
4699: A scheduled task was deleted.
4700: A scheduled task was enabled.
4701: A scheduled task was disabled.
4702: A scheduled task was updated.
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.
|Schtasks /create /RU SYSTEM /SC weekly /D SAT /TN IAmRoot /TR "C:\temp\ncat.exe -e cmd -l -p 40000" /ST 10:00:00|
For details on these event IDs, visit: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4698.
Windows services control: Security
|4697, 7045: New Service Installed|
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.
WMI monitoring: Microsoft-Windows-WMI-Activity/Operational
|5857: WMI DLL provider
5859: Permanent event filter
5860: Temporary event consumers
5861: The binded filter and consumer event
5858: Query errors
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.
|1: Name and Date of BITS job execution
4: Run-As Username and the number of files transferred
59: Lists URL contacted and bytes transferred
60: Job Stopped
204: Job responded with failed credentials
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
|6: Destination address - e.g., localhost:47001/WSMan?MSP=[GUID];PSVersion=4.0
47: Namespace of action - e.g., smb, wmi, storage, volume, directory
169: Begin of remoting activity showing authentication mechanism
400, 403: Start/end of a session
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).
Object monitoring: Security
|4661: Object request
4663: Object access success
4656: Object access attempts includes failures
5140: Network share checked
4659: A handle to an object was requested with intent to delete.
4660: An object was deleted.
4661: A handle to an object was requested.
4657: A registry value was modified.
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:
Host firewall logging: Security (optional)
|5156: Firewall-permitted connections
5157: Firewall-blocked connections
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
|GPO Object||GPO Entry||Value||Description|
|Credential Validation||Success||DC attempted to validate credentials for account|
|Account Logon||Kerberos Authentication Service||Success||Kerberos authentication ticket (TGT) was requested
Kerberos ticket requests
|Account Logon||Kerberos Service Ticket Operations||Success||Kerberos service ticket (TGS) was requested
Kerberos service ticket was renewed
|Account Logon||Other Account Logon Events||Success and Failure||Workstation was unlocked or locked. Screensaver was invoked or dismissed.|
|Account Management||Security Group Management||Success||A member was added to a security-enabled local group|
|Account Management||User Account Management||Success and Failure||A user account was altered.|
|Account Management||Computer Account Management||Success and Failure||A computer account was changed.|
Other Account Management
|Success and Failure||The password hash for an account was accessed.|
|DS Access||Directory Service Changes||Success and Failure||A directory service object was modified, created, undeleted, moved, or deleted.|
|Logon/Logoff||Logon||Success and Failure||Login successful, login failed
|Logon/Logoff||Account Lockout||Success||An Account was locked out|
|Logon/Logoff||Other Logon/Logoff Events||Success and Failure||The workstation was locked or unlocked|
|Logon/Logoff||Special Logon||Success and Failure||Special Privileges at login (Admin)|
|Object Access||Detailed File Share||Success||A network share object was checked to see whether the client can be granted desired access|
|Object Access||File Share||Success and Failure||Network share accessed|
|Object Access||SAM||Success||A handle to an object was requested or attempt made to access.|
|Object Access||Registry||Success||A registry value was modified.|
|Object Access||Filtering Platform Connection||Success||Firewall-permitted connections|
|Object Access||Filtering Platform Packet Drop||Success||Firewall-blocked connections|
|Object Access||Other Object Access Events||Success, Failure||A scheduled task was created, deleted, enabled, disabled, or updated.|
|Policy Change||Authorization Policy Change||Success and Failure||A user's rights are assigned / changed|
|Policy Change||Audit Policy Change||Success and Failure||System audit policy changed|
|Policy Change||Authentication Policy Change||Success and Failure||Kerberos, Domain policy, trusted domain info, System security access was changed.|
|Privileged Use||Sensitive Privilege Use||Success and Failure||Special privileges assigned to new logon|
|System||Security System Extension||Success||New Service Installed|
|System||Security State Change||Success||Windows starting up, shutting down, time change|
|System||System Integrity||Success||One of many integrity scenarios|
|System||Other System Events||Failure||Windows Firewall started, stopped|
Process creation with command-line logging
|GPO Object||GPO Entry||Value||Description|
|Audit Policy||Process Tracking||Success and Failure||Prerequisite for Process Creation|
|System Audit Policies, Detailed Tracking||Process Creation||Success and Failure||Process Creation|
|System Audit Policies, Detailed Tracking||Process Termination||Success||Process Termination|
|Administrative Templates, System, Audit Process Creation||Include command line in process creation events||Enabled||Include command line in process creation events|
PowerShell script block logging
|GPO Object||GPO Entry||Value||Description|
|Audit Policy||Enable Process Tracking||Success||Command-line logging|
Windows Components, Windows PowerShell
|Module Logging||Enable and specify the modules listed in the dialog box||PowerShell Module logging enabled|
Windows Components, Windows PowerShell
|Script block Logging||Enable||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.email@example.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.
 Terminator 2: Judgment day [Motion picture]. (2011). London: ITV2.