The most prevalent endpoint operating system that responders will have to examine related to an incident is by far the Windows OS. Due to the overwhelming market share that Microsoft has, the vast majority of enterprise endpoints will be Microsoft desktop/laptop, server, or virtual systems. As a result, it is critical that responders have a solid understanding of how to leverage the Windows event logs for incident analysis.

The Windows event logs provide extensive data on the actions of the operating systems, connections from other systems, and credential use, along with the use of PowerShell. Adversarial tactics from initial compromise using malware or other exploits, credential accessing, and elevation and lateral movement using the Windows operating system's internal tools are often captured via the Windows event logs.

The specific logs that are captured during the operating system's activities are largely dependent on how the organization has configured them. Most enterprises utilize the Group Policy settings to configure which actions the system logs, as well as the storage space allocated for log files. Depending on the organization's log management practices, the Windows OS can be configured to log the use of PowerShell, Server Message Block (SMB) usage, application activity, DHCP client administration, and Task Scheduler maintenance.

Most often, log management configurations are managed via the Windows Group Policy. Here, administrators have the ability to manage a wide range of systems via one policy.

To determine which logs are available on a local system, proceed as follows:

1. Search for Event Viewer in the Search field located in the Windows taskbar. Click on Event Viewer, and the following window will open:

2. From this viewer, the responder can get a good sense of what is being logged, and can even search for specific log entries. To access the logs directly for offline analysis, navigate to the default file path for log storage, at C:WindowsSystem32winevtlogs. This will show the variety of events that can be logged, as follows:

As previously stated, there are Windows event logs for a wide range of activities performed by the operating system. For the purposes of this chapter, the focus will be on three of the more pertinent Windows event log types. These types cover a wide range of activities and are useful in determining which actions have taken place on a potentially compromised system, and are detailed as follows:

• Security logs: These logs contain data entries concerning the security of the system. This includes logons, logoffs, security group membership, and program execution.
• Application logs: Application developers determine which types of activity applications will log. These are aggregated in the application log file.
• System logs: Often utilized to troubleshoot non-malicious activity, the system logs maintain data that the Windows OS creates.

There are several hundred Windows event log types. Depending on how the operating system is used, some of these are seldom—if ever—observed on the system. Others can be very common and are seen constantly in use, even in normal circumstances. The following are some of the more useful Windows event log types for responders:

• 4624 and 4634—logon and logoff: These event log entries show the use of credentials on a potentially compromised system. In addition, the 4624 event IDs can show whether the logon was performed on the local system or through a remote connection, which is critical to finding lateral movement using the Windows SMB protocol.
• 4625—account failed logon: One or two of these entries may not mean much. A few entries of this nature may indicate a fat-fingered logon here and there, but an excessive amount of these log entries is indicative of an adversary attempting to brute-force credentials.
• 4672—special privileges assigned to new logon: This is the Windows OS equivalent of a user account attempting to elevate to root- or administrator-level privileges. This can be used to determine if an adversary is escalating privileges with a compromised account.
• 4688—a new process has been created: This log entry documents every time a program is run. While there may be a lot to sift through in the logs, in terms of how many executables are run, threat hunters can focus on well-known abused programs, such as PsExec, CMD.EXE, or Whami.exe, to zero in on potentially malicious behavior.
• 4768-4773—Kerberos service: There are several well-known exploits used by adversaries where the Kerberos Ticket Granting Ticket is utilized for elevated privileges. This attack—often referred to as Kerberoasting—is particularly devastating, as it allows attackers to run through the network with valid credentials.
• 5140—a network share object was accessed: This activity is logged when a user account first logs on to a network share. Anomalies in time or user activity may be indicative of an adversary attempting to obtain confidential data, or ransomware attempting to infect network shares.
• 7045—a new service was installed: This log entry occurs when a new service was installed by the user indicated within the log entry. Some strains of malware will install themselves as a service. A review of these log entries may indicate the presence of malicious code.

For more information please check the list of event logs in the Appendix.

As previously stated, there are over a hundred specific Windows event types available. The specific ones in use are often determined by the organization and have to be weighed against the amount of storage space that is available, and against the usefulness of the specific log entries during an investigation.

There are a number of resources that can be leveraged to better understand Windows event logs. The first of these is the site ultimatewindowssecurity.com. This site provides a searchable database of the various Windows event log types by event ID. This is very useful in those circumstances where responders may come across a more obscure event ID. The MITRE Corporation also provides the ATT&CK knowledge database. This knowledge base can be searched for Windows event log IDs that may be pertinent to an investigation. For example, a responder is examining a system for indications that the system has been infected with the Carbanak malware. From the ATT&CK knowledge database, the responder is able to determine that Carbanak has created an account, and the Windows event ID for that is 4720. From here, the responder would be able to search systems for that specific event ID, and determine if there were any additional accounts that appeared suspicious.

As can be seen, the Windows Operating System has a significant number of log event types and IDs. The following section will provide the responder with a method to collect and analyze these log files.