Microsoft refers to the logs created by the Windows operating system as event logs. Event logs are generated by the system-wide auditing and monitoring mechanisms built into the Windows operating system. 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.
From a computer forensic standpoint, Windows event logs help examiners learn what a user has done on a computer at a particular time. Acquiring the Windows event logs is a straightforward file acquisition task. When event logs are analyzed, the most common approach is to export logs and then review them on the forensics workstation. Each log is stored in a separate file in paths specified within the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\
On Windows XP, Windows Server 2003, and prior operating systems, the default event log paths are:
|
Event Log |
Location |
|
Application |
|
|
System |
|
|
Security |
|
EVT files are in a proprietary format that cannot be read or examined without special tools. However, starting from Vista and Server 2008, significant changes were implemented in the event logs structure, types, and locations on the filesystem. The original version of the Event Logs system was a heavy load for system performance. A new version was developed to fix some issues related to performance too. The new .evtx format of event logs was introduced. However, the most significant changes touched the structure of the event logs. The default paths were also slightly changed to the following:
Event Log | Location |
Application | |
System | |
Security | |
Microsoft also added a second category of logs, Applications and Services, that are used by individual installed applications or system components. These logs are also stored in EVTX files located within the directory:
%SYSTEMROOT%\System32\Winevt\Logs\As mentioned earlier, each log is stored in a separate file in paths specified within the following registry key. When a custom path is set, a key is generated at the registry location.:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\The Application log provides a space where any application that wants to use the Windows-provided APIs can note significant events to that application. An example of a program that takes advantage of this feature is a third-party antivirus product. Records of updates, detected malware, disabling or activation of the application, and so on can be recorded in the Application log.
The System log is where Windows stores the majority of the information that relates to system operation and maintenance. Many different types of events can be recorded in the System event log, and administrators rely heavily on this log for diagnosing and troubleshooting problems on Windows systems. The majority of the data recorded in this log is only of marginal use in a DFIR investigation, but there are some nuggets of useful data to be found. When a program registers as a service or when a service is stopped or started or when a device driver is loaded, an event is recorded in the System event log. Depending on the nature of an attack, the System log can contain useful information hidden amid the many events that are of more use to an administrator than to an investigator.
The Security log is the log in which forensic investigators will spend the most time. Events regarding log-ons, file access, authentication, account creation, privilege use, and other security-related events are recorded in this log. Obviously, these types of events are critical to any forensic investigation because they address questions such as which user accounts were being used, which machines were accessed, and which files were accessed or altered. Events in the security log are often called audits. An audit allows applying security settings to itself so that all modifications of audit policy can be traced. Audit policies determine what is recorded in the security log. These can be configured by the system administrator in three different ways: via local policy, via group policy, and directly from the command line with the tool auditpol.exe. Since this post deals with investigation rather than administration, I will not dwell on the mechanics or strategies used to structure an adequate auditing policy, but a basic understanding of the auditing capabilities will serve to assist you in analyzing the resulting event logs.
Due to its nature, the Security Log has more protections than System and Application event logs. Starting from Windows XP SP2, the API for applications that send events to the Security event log was deprecated, excluding the Windows Security Service. Now this possibility is available only for Local Security Authority System Service (LSASS) because it is responsible for applying security policies in the system. Moreover, only users with administrator permissions can review, export, or clear the Security event log.
Know Your Event IDs
Analyzing Windows event logs is a detailed process. One challenge that is often encountered by responders is the sheer number of logs that they may have to potentially analyze during an incident. In the case of multiple systems, the responder may have to contend with millions of separate event log entries. Cutting them down requires the use of specialized tools and processes, starting with the acquisition, moving into triage, and then, finally, focusing on analyzing the key event logs that are pertinent to the incident investigation. Every type of event tracked in Windows event logs has an associated ID value. These IDs are often more useful than the event message itself when you are trying to research, filter, or cross-reference log entries.
It is impossible and also not necessary to remember all Event IDs and error codes that are related to them. Fortunately, there are a number of resources that can be leveraged, to better understand Windows event logs. The first of these is Ultimate Windows Security. This site provides a searchable database of the various Windows event log types by event ID. This is very useful in those circumstances where investigators may come across a more obscure event ID. Microsoft recommends a list of Windows log events to be monitored because they can give a sign of compromise. You can find the list here. 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. By correlating Windows Event IDs with the techniques outlined in the MITRE ATT&CK framework, security analysts and investigators can identify and respond to potential threats more effectively. One of the best resources available for discovering which attack techniques match which event IDs is The Windows ATT&CK Logging Cheatsheet by Malware Archaeology. According to the cheat sheet, Windows event IDs have around 83% coverage of Windows-specific enterprise attack techniques (see top figure), which gives a great spread across the tactics on the MITRE ATT&CK framework (excluding Impact). Green-coloured techniques have strong coverage and yellow has some. As the cheat sheet was last updated in Q3 2018, it is missing some new attack techniques that have been added to ATT&CK, which can most likely also be detected using event logs.
 |
| MITRE ATT&CK Matrix coverage of Windows event IDs from cheatsheet [Q3 2018] - 220/266 ~83% (Excluding impact) |
Another very good resource for mapping MITRE ATT&CK to Windows Event log IDs is SOC Investigations. It is worth noting that MITRE ATT&CK is a continuously evolving framework, and new techniques are regularly added to reflect the evolving threat landscape. Therefore, it is important to keep up with the latest updates from MITRE to ensure accurate mapping between Windows Event IDs and ATT&CK techniques.
Note: The investigator should be aware that Microsoft changed the Event IDs for some (but not all) types of events between NT Kernel 5 (2000, XP, 2003) and 6 (Vista, 7, 2008 and newer versions). The newer Event IDs often (but not always) equal the old value plus 4096 (for example, Successful Network Logon changed from 540 to 4624, whereas service start/stop events remained as Event ID 7036).
Understanding Logon Event
Nearly any Windows investigation you perform will include tracking and analyzing logon events. You may need to prove how a legitimate user accessed their own system, or how a malicious attacker gained remote access to it. You may need to track failed logon attempts indicative of password brute forcing, or you may need to determine how a compromised account was reused throughout an environment. To understand the logon event and what each key fields mean, let us consider the event log below.
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 9/9/2020 2:18:27 PM
Event ID: 4624
Task Category: Logon
Level: Information
Keywords: Audit Success
User: N/A
Computer: MSEDGEWIN10
Description:
An account was successfully logged on.
Subject:
Security ID: S-1-5-21-3461203602-4096304019-2269080069-1000
Account Name: IEUser
Account Domain: MSEDGEWIN10
Logon ID: 0x79E59
Logon Information:
Logon Type: 2
Restricted Admin Mode: -
Virtual Account: No
Elevated Token: Yes
Impersonation Level: Impersonation
New Logon:
Security ID: S-1-5-21-3461203602-4096304019-2269080069-1000
Account Name: IEUser
Account Domain: MSEDGEWIN10
Logon ID: 0x1CD8F6
Linked Logon ID: 0x1CD964
Network Account Name: -
Network Account Domain: -
Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID: 0x1358
Process Name: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Network Information:
Workstation Name: MSEDGEWIN10
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Chrome
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
- Account Name - The account used to log on
- Account Domain - The domain associated with the Account name. If the Account name is a local account, this field will contain the system’s host name.
- Logon ID - A unique session identifier. You can use this value as a search term or filter to find all event log entries associated with this specific logon session.
- Logon Type - One of the useful information that Successful/Failed Logon event provide is how the user/process tried to logon (Logon Type) but Windows display this information as a number.
|
Logon Type Codes |
||
|
Code |
Type |
Description |
|
2 |
Interactive |
The user logged on from the console of the computer. You’ll see type 2 logons when a user attempts to logon at the local keyboard and screen whether with a domain account or a local account from the computer’s local SAM. To tell the difference between an attempt to logon with a local or domain account look for the domain or computer name preceding/after the account name in the event’s description. Don’t forget that logon’s through an KVM over IP component or a server’s proprietary “lights-out” remote KVM feature are still interactive logons from the standpoint of Windows and will be logged as such. |
|
3 |
Network |
Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well such as most logons to IIS. |
|
4 |
Batch |
This logon type occurs when a batch job executes on a computer, typically using a Task Scheduler or a similar mechanism. |
|
5 |
Service |
This logon type occurs when a service starts and logs on to the system using its configured credentials. Service logons are typically performed by system services or background processes. |
|
6 |
Proxy |
Microsoft defines this as “a proxy-type logon.” We have yet to see this type of event in the wild, or any documentation explaining how it may be generated. |
|
7 |
Unlock |
This logon type occurs when a system is unlocked (for example, after resuming from the screensaver). It indicates that a user has regained access to their previously locked session. |
|
8 |
NetworkCleartext |
This logon type occurs when a user logs on to a network using plaintext authentication, such as sending credentials in clear text over the network. |
|
9 |
NewCredentials |
This logon type occurs when a user provides new credentials after authenticating to the system. It typically happens when using "Run as different user" option or when accessing a network resource. |
|
10 |
RemoteInteractive |
When you access a computer through Terminal Services, Remote Desktop, or Remote Assistance windows logs the logon attempt with logon type 10 which makes it easy to distinguish true console logons from a remote desktop session. Note however that prior to XP, Windows 2000 doesn’t use logon type 10 and terminal services logons are reported as logon type 2. |
|
11 |
CacheInteractive |
The user logged on with domain credentials that were validated using locally cached data rather than contacting the domain controller. |
- Logon Process - The process that initiated the logon event. Common options include NtLmSsp, Kerberos, User32, and Advapi.
- Authentication Package - The security and authentication protocol used to process the logon event. Common options include NTLM, Kerberos, and Negotiate.
- Workstation Name - The source system from which the logon originated. This is not always captured in the event log entry.
- Source Network Address - The source IP address from which the logon originated. This is not always captured in the event log entry.
Event Log Triage
To address the large datasets that are often encountered in Windows event log analysis, responders can utilize the DeepBlueCLI tool. This PowerShell script, developed by Eric Conrad (a SANS fellow), detects suspicious Windows event log entries, such as service creation, account creation, a high number of logon failures, and malicious PowerShell usage. By focusing on these more critical event types, responders will be able to analyze more log files and potentially identify suspicious activity.
To run DeepBlueCLI, clone the tool from its GitHub repository, unzip it, Open Powershell as Administrator, and navigate to the directory containing the file DeepBlue.ps1. Before executing the script, you might want to examine your system's Powershell execution policy by taking the following step:
- Enter the command Get-ExecutionPolicy. If the execution policy is set to "Restricted" which is the default, you will have to change it. Choose the appropriate policy based on your security requirements:
- Restricted - No scripts are allowed (Default).
- AllSigned - Only scripts signed by a trusted publisher are allowed.
- RemoteSigned - All local scripts can run, but remote scripts need to be signed by a trusted publisher.
- Unrestricted - All scripts are allowed (least secure, and not recommended please).
- To change the execution policy, enter the following command:
Set-ExecutionPolicy -ExecutionPolicy <Policy>To run the script, enter the following command .\DeepBlue.ps1 <path to the .evt/.evtx file> as shown below:
.\DeepBlue.ps1 C:\kali_shared\EVTX-ATTACK-SAMPLES-master\EVTX-ATTACK-SAMPLES-master\CredentialAccess\CA_keepass_KeeThief_Get-KeePassDatabaseKey.evtx
In this case, the DeepBlueCLI script was run against Windows security event logs from a potentially compromised system. A review of the output indicated some potential signs that the system was attacked by an adversary, as can be seen in the following screenshot:
The one major drawback with Windows event log triage tools such as DeepBlueCLI is that they often focus on finding the low-hanging fruit, or those event logs that are often clearly indicative of abuse. They do make it easier for responders to triage a larger dataset, but responders should be aware that they are not foolproof, and there is a chance that an event log entry or entries may be missed.
Once a responder has been able to narrow down the entries that are important, there are several tools and techniques that can be leveraged to analyze the important log files.
Event Log Analysis Tools
Event log analysis tools provide the ability to acquire, view, search, sort, and filter EVT and EVTX files since they are not intrinsically “human readable.” There are many programs, both free and commercial, available to analyze Windows event logs. The following are just a few of them:
- Log Parser - Query Windows event log using the SQL query language.
- Log Parser Lizard GUI - It uses SQL to query the Windows event logs, IIS logs, the registry, the file system, the active directory services, and more. This is a commercial application; a free trial is available.
- Event Viewer - This is built into the Windows Operating system. It allows you to open acquired event log files as well as search/filter via keyword or Xpath.
- Event Log Explorer - This allows you to load, consolidate, filter, and search event logs. High performance on large log files. It is a commercial application.
If you’re tracking down a suspicious but yet-to-be-categorized activity on a system, be sure to check the Application event log to see if any antivirus alerts were generated during your period of interest. This may help point you in the direction of suspicious files, and even help you determine whether your investigative leads were due to a common, nontargeted malware infection or something warranting further review.
Post a Comment