Windows Event Logs & Finding Evil Module
PreviousSecurity Monitoring & SIEM Fundamentals ModuleNextIntroduction to Threat Hunting & Hunting With Elastic Module
Last updated
Last updated
Windows Event Logs are an intrinsic part of the Windows Operating System, storing logs from different components of the system including the system itself, applications running on it, ETW providers, services, and others.
The default Windows event logs consist of Application, Security, Setup, System, and Forwarded Events. While the first four logs cover application errors, security events, system setup activities, and general system information, the "Forwarded Events" section is unique, showcasing event log data forwarded from other machines. This central logging feature proves valuable for system administrators who desire a consolidated view.
When examining Application logs, we encounter two distinct levels of events: information and error.
Information events provide general usage details about the application, such as its start or stop events. Conversely, error events highlight specific errors and often offer detailed insights into the encountered issues.
To streamline our analysis, we can create custom XML queries to identify related events using the "Logon ID" as a starting point. By navigating to "Filter Current Log" -> "XML" -> "Edit Query Manually," we gain access to a custom XML query language that enables more granular log searches.
The "Subject Logon ID" with a value of 0x3E7 in Windows Security Event Logs refers to the unique identifier for the session of the local system account, also known as the LocalSystem account. This account is a built-in account used by the operating system for system-level operations and has extensive privileges on the system.
Windows System Logs
Event ID 1074 (System Shutdown/Restart)
Event ID 6005 (The Event log service was started)
Event ID 6006 (The Event log service was stopped)
Event ID 6013 (Windows uptime)
Event ID 7040 (Service status change)
Windows Security Logs
Event ID 1102 (The audit log was cleared)
Event ID 1116 (Antivirus malware detection)
Event ID 1118 (Antivirus remediation activity has started)
Event ID 1119 (Antivirus remediation activity has succeeded)
Event ID 1120 (Antivirus remediation activity has failed)
Event ID 4624 (Successful Logon)
Event ID 4625 (Failed Logon)
Event ID 4648 (A logon was attempted using explicit credentials)
Event ID 4656 (A handle to an object was requested)
Event ID 4672 (Special Privileges Assigned to a New Logon)
Event ID 4698 (A scheduled task was created)
Event ID 4700 & Event ID 4701 (A scheduled task was enabled/disabled)
Event ID 4702 (A scheduled task was updated)
Event ID 4719 (System audit policy was changed)
Event ID 4738 (A user account was changed)
Event ID 4771 (Kerberos pre-authentication failed)
Event ID 4776 (The domain controller attempted to validate the credentials for an account)
Event ID 5001 (Antivirus real-time protection configuration has changed)
Event ID 5140 (A network share object was accessed)
Event ID 5142 (A network share object was added)
Event ID 5145 (A network share object was checked to see whether client can be granted desired access)
Event ID 5157 (The Windows Filtering Platform has blocked a connection)
Event ID 7045 (A service was installed in the system)
Remember, one of the key aspects of threat detection is having a good understanding of what is "normal" in our environment. Anomalies that might indicate a threat in one environment could be normal behavior in another. It's crucial to tune our monitoring and alerting systems to our environment to minimize false positives and make real threats easier to spot.
Let's proceed to solve the questions.
For the first question, let's solve it using two methods: directly from the Event Viewer and via PowerShell.
1) Open the Event Viewer and navigate to Windows Logs -> Security .
2) Let's Analyze the event with ID 4624, within this log, we find crucial details, including the "Logon ID", which allows us to correlate this logon with other events sharing the same "Logon ID". Another important detail is the "Logon Type", indicating the type of logon. In this case, it specifies a Service logon type, suggesting that "SYSTEM" initiated a new service. However, further investigation is required to determine the specific service involved, utilizing correlation techniques with additional data like the "Logon ID".
3) Let's create a custom XML query based on the logon ID.
4) I analyzed event ID 4907 occurrences after "8/3/2022 at 10:23:25" and identified a process named "TiWorker.exe", it's the executable responsible for the modification of the auditing settings.
We can address this directly using PowerShell. Let's proceed.
I implemented this code in the solution using three parameters: Event ID, Start Time, and End Time.
1) I saved the code in a file named Get-Security.psm1 and then imported it.
2) I used this command to list all events with ID 4907 that occurred after the login attempt on 8/3/2022 at 10:23:25.
For the second question, I used two methods to solve it: an XML query and PowerShell. Let's begin with the XML query method.
After applying the query, I got two events only and found the answer.
Another approach involves using PowerShell; we will proceed with this method.
I utilized the previously employed function to retrieve the solution, filtering for instances where the Object Name matches (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\WPF\wpfgfx_v0400.dll).
System Monitor (Sysmon) is a Windows system service and device driver that remains resident across system reboots to monitor and log system activity to the Windows event log. Sysmon provides detailed information about process creation, network connections, changes to file creation time, and more.
Sysmon's primary components include:
A Windows service for monitoring system activity.
A device driver that assists in capturing the system activity data.
An event log to display captured activity data.
Sysmon's unique capability lies in its ability to log information that typically doesn't appear in the Security Event logs, and this makes it a powerful tool for deep system monitoring and cybersecurity forensic analysis.
Sysmon categorizes different types of system activity using event IDs, where each ID corresponds to a specific type of event. For example, Event ID 1 corresponds to "Process Creation" events, and Event ID 3 refers to "Network Connection" events. The full list of Sysmon event IDs can be found here.
For a comprehensive configuration, we can visit: https://github.com/SwiftOnSecurity/sysmon-config.
To get started, you can install Sysmon by downloading it from the official Microsoft documentation (https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon). Once downloaded, open an administrator command prompt and execute the following command to install Sysmon.
To utilize a custom Sysmon configuration, execute the following after installing Sysmon.
Let's proceed to solve the questions.
Let's address the first question using two methods: directly through the Event Viewer and via PowerShell.
1) To detect DLL hijacks, we modify Event Id 7 in the sysmonconfig-export file from "include" to "exclude" to ensure all data is captured.
2) Then to utilize the updated Sysmon configuration, execute the following.
3) Let's attempt the hijack using "calc.exe" and "reflective_dll.x64.dll" . I copied the files to to a writable directory and renamed reflective_dll.x64.dll to WININET.dlland executing calc.exe, we achieve success. Instead of the Calculator application, a MessageBox is displayed.
4) Next, let's attempt to detect this attack. First, we filter the event logs to focus on Event ID 7, which represents module load events, by clicking "Filter Current Log" .
5) I used "Find Next" to search for instances of "calc.exe" and identify the DLL load linked to our hijack.
Now, we can observe several indicators of compromise, let's explore these IOCs:
"calc.exe", originally located in System32, should not be found in a writable directory. Therefore, a copy of "calc.exe" in a writable directory serves as an IOC, as it should always reside in System32 or potentially Syswow64.
"WININET.dll", originally located in System32, should not be loaded outside of System32 by calc.exe.
The original "WININET.dll" is Microsoft-signed, while our injected DLL remains unsigned.
Here is an alternative solution for the first question using PowerShell directory. Let's review it.
properties[4].value -like "*calc.exe" filters the events where the 5th property (index 4) contains "calc.exe". This property likely represents the image (executable) name.
properties[5].value -like "*WININET.dll" filters the events where the 6th property (index 5) contains "WININET.dll". This property likely represents the ImageLoaded.
Here is the code for the Get-SysmonEvent function.
Next, we will address the second question, which concerns Unmanaged PowerShell attacks.
Let's gain a brief understanding of C# and its runtime environment. C# is considered a "managed" language, meaning it requires a backend runtime to execute its code. The Common Language Runtime (CLR) serves as this runtime environment. Managed code does not directly run as assembly; instead, it is compiled into a bytecode format that the runtime processes and executes. Consequently, a managed process relies on the CLR to execute C# code.
1) In this attack, we will utilize "spoolsv.exe"; let's examine it in Process Hacker.
2) We have identified that spoolsv.exe is unmanaged. Let’s proceed with the attack to observe its response.
Spoolsv.exe is now managed. Let's explore how to detect the attack.
3) First, we'll use Event Viewer to detect the attack, then PowerShell. I searched for spoolsv.exe using Ctrl + F and found it.
The presence of "Microsoft .NET Runtime...", clr.dll, and clrjit.dll should attract our attention. These 2 DLLs are used when C# code is ran as part of the runtime to execute the bytecode. If we observe these DLLs loaded in processes that typically do not require them, it suggests a potential execute-assembly or unmanaged PowerShell injection attack.
Let’s proceed with the second method using PowerShell. First, we'll create a function called Get-SysmonEvent to utilize Sysmon.
Let's create the file, save the code in it, and then import it.
We can now use the function to retrieve the logs.
For the third question, which concerns a Credential Dumping attack, we were required to obtain the NTLM hash of the administrator.
Another critical aspect of cybersecurity is detecting credential dumping activities. One widely used tool for credential dumping is Mimikatz, offering various methods for extracting Windows credentials. One specific command, "sekurlsa::logonpasswords", enables the dumping of password hashes or plaintext passwords by accessing the Local Security Authority Subsystem Service (LSASS). LSASS is responsible for managing user credentials and is a primary target for credential-dumping tools like Mimikatz.
In the realm of effective threat detection and incident response, we often find ourselves relying on the limited log data at our disposal. However, this approach falls short of fully harnessing the immense wealth of information that can be derived from the powerful resource known as Event Tracing for Windows (ETW). Unfortunately, this oversight can be attributed to a lack of awareness and appreciation for the comprehensive and intricate insights that ETW can offer.
According to Microsoft, Event Tracing For Windows (ETW) is a general-purpose, high-speed tracing facility provided by the operating system. Using a buffering and logging mechanism implemented in the kernel, ETW provides a tracing mechanism for events raised by both user-mode applications and kernel-mode device drivers.
ETW, functioning as a high-performance event tracing mechanism deeply embedded within the Windows operating system, presents an unparalleled opportunity to bolster our defense capabilities. Its architecture facilitates the dynamic generation, collection, and analysis of various events occurring within the system, resulting in the creation of intricate, real-time logs that encompass a wide spectrum of activities.
Logman is a pre-installed utility for managing Event Tracing for Windows (ETW) and Event Tracing Sessions. This tool is invaluable for creating, initiating, halting, and investigating tracing sessions.
For each provider subscribed to the session, we can acquire critical data:
Name / Provider GUID: This is the exclusive identifier for the provider.
Level: This describes the event level, indicating if it's filtering for warning, informational, critical, or all events.
Keywords Any: Keywords create a filter based on the kind of event generated by the provider.
By using the logman query providers command, we can generate a list of all available providers on the system, including their respective GUIDs.
Due to the high number of providers, it's usually advantageous to filter them using findstr. For instance, you will see multiple results for "Winlogon" in the given example.
By specifying a provider with Logman, we gain a deeper understanding of the provider's function. This will inform us about the Keywords we can filter on, the available event levels, and which processes are currently utilizing the provider.
Let's work on the lab, which involves executing Seatbelt and providing the ManagedInteropMethodName.
For demonstrative purposes, let's emulate a malicious .NET assembly load by executing a precompiled version of Seatbelt that resides on disk. Seatbelt is a well-known .NET assembly, often employed by adversaries who load and execute it in memory to gain situational awareness on a compromised system.
Relying solely on Sysmon Event ID 7 for detecting attacks can be challenging due to the large volume of events it generates (especially if not configured properly). Additionally, while it informs us about the DLLs being loaded, it doesn't provide granular details about the actual content of the loaded .NET assembly.
1) Let's use SilkETW to collect data from the Microsoft-Windows-DotNETRuntime provider. After that, we can proceed to simulate the attack again to evaluate whether ETW can furnish us with more detailed and actionable intelligence regarding the loading and execution of the 'Seatbelt' .NET assembly.
By using Microsoft-Windows-DotNETRuntime, developers can gain a better understanding of how their .NET applications are performing and identify areas for improvement.
2) Let's emulate a malicious .NET assembly load by executing a precompiled version of Seatbelt that resides on disk. Seatbelt is a well-known .NET assembly, often employed by adversaries who load and execute it in memory to gain situational awareness on a compromised system.
3) Once the attack is complete, open the etw.json file and search for ManagedInteropMethodName to find the answer.
The Get-WinEvent cmdlet is an indispensable tool in PowerShell for querying Windows Event logs en masse. The cmdlet provides us with the capability to retrieve different types of event logs, including classic Windows event logs like System and Application logs, logs generated by Windows Event Log technology, and Event Tracing for Windows (ETW) logs.
To quickly identify the available logs, we can leverage the -ListLog parameter in conjunction with the Get-WinEvent cmdlet. By specifying * as the parameter value, we retrieve all logs without applying any filtering criteria.
Additionally, we can explore the event log providers associated with each log using the -ListProvider parameter. Event log providers serve as the sources of events within the logs.
Retrieving events from the System log. This example retrieves the first 50 events from the System log.
Retrieving events from Microsoft-Windows-WinRM/Operational log.
Retrieving events from .evtx Files.
Filtering events with FilterHashtable, this command retrieves events with IDs 1 and 3 from the Microsoft-Windows-Sysmon/Operational event log, selects specific properties from those events, and displays them in a table format.
For exported events the equivalent command is the following.
If we want the get event logs based on a date range (5/28/23 - 6/2/2023), this can be done as follows.
Filtering events with FilterHashtable & XML. Consider an intrusion detection scenario where a suspicious network connection to a particular IP (52.113.194.132) has been identified.
If we were looking for anomalous clr.dll and mscoree.dll loading activity in processes that ordinarily wouldn't require them. The command below is leveraging Sysmon's Event ID 7 to detect the loading of abovementioned DLLs.
Filtering events with FilterXPath. To use XPath queries with Get-WinEvent, we need to use the -FilterXPath parameter. This allows us to craft an XPath query to filter the event logs.
Suppose we want to investigate any network connections to a particular suspicious IP address (52.113.194.132) that Sysmon has logged. To do that we could use the following command.
Filtering events based on property values. The -Property * parameter, when used with Select-Object, instructs the command to select all properties of the objects passed to it.
Let's now see an example of a command that retrieves Process Create events from the Microsoft-Windows-Sysmon/Operational log, checks the parent command line of each event for the string -enc, and then displays all properties of any matching events as a list.
The lab requires me to use the Get-WinEvent cmdlet to search all event logs in the "C:\Tools\chainsaw\EVTX-ATTACK-SAMPLES\Lateral Movement" directory and find when the *\PRINT share was added. Enter the time of the event in the format HH:MM:SS.
Here I used Event ID 5142 in the Windows Security log indicates a "A network share object was added." This event is logged when a new network share is created on a system. Monitoring this event can be useful for detecting unauthorized or suspicious activity, particularly in the context of lateral movement within a network.
Let's complete this lab to apply what we've learned in this module.
In the first question, we need to examine the logs in the "C:\Logs\DLLHijack" directory to identify the process responsible for a DLL hijacking attack.
Let's solve this question first using Event Viewer, then using PowerShell.
1) Open the DLLHijack log file in Event Viewer and filter the current log by Event ID 7.
The DismCore.dll is not digitally signed, indicating it is responsible for executing a DLL hijacking attack.
Explanation of "Signed: false"
The attribute "Signed: false" indicates that the file C:\ProgramData\DismCore.dll is not digitally signed.
This means there is no digital signature present in the file to verify its source or integrity.
A digital signature is a cryptographic technique used to validate the authenticity and integrity of a file. When a file is digitally signed, it means that a certificate, issued by a trusted Certificate Authority (CA), is used to sign the file. This signature serves as a proof of origin and ensures that the file has not been altered since it was signed.
We can solve this with a single PowerShell command. Let's take a look.
1) I utilized the previously used Get-SysmonEvent function to obtain the solution.
For the second question, we need to review the logs in the "C:\Logs\PowershellExec" directory to identify the process that ran unmanaged PowerShell code.
1) I opened the PowershellExec log file in Event Viewer and filtered for Event ID 7.
The presence of "Microsoft .NET Runtime...", clr.dll, and clrjit.dll should attract our attention. These 2 DLLs are used when C# code is ran as part of the runtime to execute the bytecode. If we observe these DLLs loaded in processes that typically do not require them, it suggests a potential execute-assembly or unmanaged PowerShell injection attack.]
Let's solve this question with a single PowerShell command.
In the third question, we need to review the logs in the "C:\Logs\PowershellExec" directory and determine the process that injected into the process that executed unmanaged PowerShell code.
1) I opened the PowershellExec log file in Event Viewer and filtered for Event ID 8.
We used Event ID 8 and will search for CreateRemoteThread because:
CreateRemoteThread is a Windows API function often used by malicious actors to inject code into another process.
Event ID 8 is related to specific logging or security events that capture details about process injection or similar activities.
We can also achieve this by searching for Calculator.exe and filtering by Event ID 8, but let's proceed with a PowerShell solution.
For the fourth question, we need to examine the logs in the "C:\Logs\Dump" directory to identify the process that performed an LSASS dump.
1) Let's open the log file at C:\Logs\Dump\LsassDump in Event Viewer and filter by Event ID 10.
LSASS: This process is responsible for enforcing security policies on the system. It verifies users logging on to the computer, handles password changes, and creates access tokens.
Dumping LSASS: Attackers often target LSASS to dump its memory because it contains sensitive information like user credentials (password hashes, Kerberos tickets, etc.).
Event ID 10 in Windows Event Logs often corresponds to WMI (Windows Management Instrumentation) activities or process accesses that are unusual. Specifically, this ID can be linked to the following:
WMI Activity: When a process interacts with WMI to execute commands or gather data.
Process Access: When a suspicious process attempts to access or interact with another process (like LSASS), especially using tools or methods known for credential dumping.
2) I searched for the SourceImage responsible for the LSASS dump using the TargetImage: C:\Windows\System32\lsass.exe.
The access mask 0x1400 indicates specific rights that were granted to the source process over the target process. This value includes permissions like PROCESS_VM_READ and PROCESS_QUERY_INFORMATION, which are often used to read the memory of another process. This access is typical in the context of process manipulation and dumping.
We can also obtain the solution using PowerShell. First, let's find the path for lsass.exe.
| Where-Object {$_.Message -match 'TargetImage:\s+C:\\Windows\\system32\\lsass.exe' -and $_.Message -notmatch 'SourceImage:\s+C:\\Windows\\system32\\svchost.exe'}:
{$_.Message -match 'TargetImage:\s+C:\\Windows\\system32\\lsass.exe': Filters events where the Message property matches the regular expression for TargetImage: C:\Windows\system32\lsass.exe.
\s+: Matches one or more whitespace characters.
-and: Logical AND operator to combine conditions.
$_.Message -notmatch 'SourceImage:\s+C:\\Windows\\system32\\svchost.exe'}: Further filters out events where the Message property matches the regular expression for SourceImage: C:\Windows\system32\svchost.exe.
-notmatch: Operator for checking that a string does not match a regular expression pattern.
For the fifth question, we need to examine the logs in the "C:\Logs\Dump" directory to determine if there was a malicious login after the LSASS dump.
After an LSASS dump, various types of logon events can occur, depending on the nature of the attack and subsequent activities by the attacker.
Interactive (Logon Type 2):
This logon type occurs when a user logs on to the system interactively by entering credentials at the local console (e.g., via physical access or remote desktop).
RemoteInteractive (Logon Type 10):
Similar to Interactive logon, but performed via Remote Desktop Services (RDP). An attacker might attempt to gain remote access to the system after compromising LSASS.
To determine if an ill-intended login took place after an LSASS dump, you need to correlate the events related to the LSASS dump with subsequent login events.
Define Logon Types: $logonTypes = @(2, 10) specifies the logon types of interest (2 for Interactive and 10 for RemoteInteractive):
Identify Login Events: $loginEvents retrieves all login events (Event ID 4624) from the Security log:
Identify LSASS Dump Events: $lsassDumpEvents uses your existing command to filter LSASS dump events based on the specified criteria:
This block iterates over each LSASS dump event stored in $lsassDumpEvents. For each LSASS dump event:
It retrieves the time of the LSASS dump event ($lsassTime).
It filters the login events ($loginEvents) to find those that occurred after the LSASS dump event and match the logon types specified in $suspiciousLogonTypes. This is done using the Where-Object cmdlet, where the logon type is extracted from the event's properties (assuming it is at index 8).
If there are any suspicious logins ($suspiciousLogins), it outputs a message indicating that an LSASS dump was detected at the specified time and lists the suspicious logins with their details (time created, event ID, and message).
Therefore, no login attempts were made after the LSASS dump occurred.
For the final question, we need to review the logs located in the "C:\Logs\StrangePPID" directory, determine a process that was used to temporarily execute code based on a strange parent-child relationship.
1) Let's open the StrangePPID log file located at C:\Logs\StrangePPID in Event Viewer and filter by Event ID 1.
Event ID 1: This event ID is generated by the Sysmon (System Monitor) utility from Sysinternals, a suite of advanced system utilities provided by Microsoft. Event ID 1 specifically logs process creation events.
The WerFault.exe process was used to temporarily execute code due to an unusual parent-child relationship. Let's investigate the reasons behind this.
Unexpected Parent Process:
WerFault.exe: This executable is the Windows Error Reporting tool, which handles errors and crashes for Windows applications. It is not common for werfault.exe to spawn a command prompt (cmd.exe). This unusual behavior can indicate that the error reporting process is being misused to execute commands, possibly as part of an exploitation or persistence mechanism.
Command Execution:
Command Line: cmd.exe /c whoami is a benign command that simply outputs the current user. However, the fact that it was initiated by werfault.exe makes it suspicious. Attackers sometimes run simple commands to test the waters before executing more harmful payloads.
User Context:
User: DESKTOP-R4PEEIF\waldo is the user under which both processes are running. This information alone isn't suspicious but combined with the unusual parent-child relationship, it adds to the concern.
Current Directory:
Current Directory: C:\ProgramData\ is a common location where malware might operate from, as it often has read/write permissions for all users and is less scrutinized than system directories like C:\Windows.
As the module concludes, I hope you found it helpful and enjoyable. Thank you for your time.
