{
	"id": "8bc11f7e-5727-4bed-95ed-1d85310aa66a",
	"created_at": "2026-04-06T00:11:49.703111Z",
	"updated_at": "2026-04-10T03:21:13.71084Z",
	"deleted_at": null,
	"sha1_hash": "d7cfeedd3fd12d7538d7b0143df0510f4f383971",
	"title": "Tampering with Windows Event Tracing: Background, Offense, and Defense",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1032617,
	"plain_text": "Tampering with Windows Event Tracing: Background, Offense,\r\nand Defense\r\nBy Palantir\r\nPublished: 2019-02-28 · Archived: 2026-04-05 16:07:34 UTC\r\nPress enter or click to view image in full size\r\nEvent Tracing for Windows (ETW) is the mechanism Windows uses to trace and log system events. Attackers\r\noften clear event logs to cover their tracks. Though the act of clearing an event log itself generates an event,\r\nattackers who know ETW well may take advantage of tampering opportunities to cease the flow of logging\r\ntemporarily or even permanently, without generating any event log entries in the process.\r\nThe Windows event log is the data source for many of the Palantir Critical Incident Response Team’s Alerting and\r\nDetection Strategies, so familiarity with event log tampering tradecraft is foundational to our success. We\r\ncontinually evaluate our assumptions regarding the integrity of our event data sources, document our blind spots,\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 1 of 14\n\nand adjust our implementation. The goal of this blog post is to share our knowledge with the community by\r\ncovering ETW background and basics, stealthy event log tampering techniques, and detection strategies.\r\nIntroduction to ETW and event logging\r\nThe ETW architecture differentiates between event providers, event consumers, and event tracing sessions.\r\nTracing sessions are responsible for collecting events from providers and for relaying them to log files and\r\nconsumers. Sessions are created and configured by controllers like the built-in logman.exe command line utility.\r\nHere are some useful commands for exploring existing trace sessions and their respective ETW providers; note\r\nthat these must usually be executed from an elevated context.\r\nList all running trace sessions\r\n\u003e logman query -etsData Collector Set Type Status\r\n-------------------------------------------------\r\nCircular Kernel Context Logger Trace Running\r\nAppModel Trace Running\r\nScreenOnPowerStudyTraceSession Trace Running\r\nDiagLog Trace Running\r\nEventLog-Application Trace Running\r\nEventLog-System Trace Running\r\nLwtNetLog Trace Running\r\nNtfsLog Trace Running\r\nTileStore Trace Running\r\nUBPM Trace Running\r\nWdiContextLog Trace Running\r\nWiFiSession Trace Running\r\nUserNotPresentTraceSession Trace Running\r\nDiagtrack-Listener Trace Running\r\nMSDTC_TRACE_SESSION Trace Running\r\nWindowsUpdate_trace_log Trace Running\r\nList all providers that a trace session is subscribed to\r\n\u003e logman query \"EventLog-Application\" -etsName: EventLog-Application\r\nStatus: Running\r\nRoot Path: %systemdrive%\\PerfLogs\\Admin\r\nSegment: Off\r\nSchedules: On\r\nSegment Max Size: 100 MB\r\n Name: EventLog-Application\\EventLog-Application\r\nType: Trace\r\nAppend: Off\r\nCircular: Off\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 2 of 14\n\nOverwrite: Off\r\nBuffer Size: 64\r\nBuffers Lost: 0\r\nBuffers Written: 242\r\nBuffer Flush Timer: 1\r\nClock Type: System\r\nFile Mode: Real-time\r\n Provider:\r\nName: Microsoft-Windows-SenseIR\r\nProvider Guid: {B6D775EF-1436-4FE6-BAD3-9E436319E218}\r\nLevel: 255\r\nKeywordsAll: 0x0\r\nKeywordsAny: 0x8000000000000000 (Microsoft-Windows-SenseIR/Operational)\r\nProperties: 65\r\nFilter Type: 0\r\n Provider:\r\nName: Microsoft-Windows-WDAG-Service\r\nProvider Guid: {728B02D9-BF21-49F6-BE3F-91BC06F7467E}\r\nLevel: 255\r\nKeywordsAll: 0x0\r\nKeywordsAny: 0x8000000000000000\r\nProperties: 65\r\nFilter Type: 0\r\n ...\r\n Provider:\r\nName: Microsoft-Windows-PowerShell\r\nProvider Guid: {A0C1853B-5C40-4B15-8766-3CF1C58F985A}\r\nLevel: 255\r\nKeywordsAll: 0x0\r\nKeywordsAny: 0x9000000000000000 (Microsoft-Windows-PowerShell/Operational,Microsoft-Windows-Properties: 65\r\nFilter Type: 0\r\nThis command details the configuration of the trace session itself, followed by the configuration of each provider\r\nthat the session is subscribed to, including the following parameters:\r\nName: The name of the provider. A provider only has a name if it has a registered manifest, but it always\r\nhas a unique GUID.\r\nProvider GUID: The unique GUID for the provider. The GUID and/or name of a provider is useful when\r\nperforming research or operations on a specific provider.\r\nLevel: The logging level specified. Standard logging levels are: 0 — Log Always; 1 — Critical; 2 — Error;\r\n3 — Warning; 4 — Informational; 5 — Verbose. Custom logging levels can also be defined, but levels 6–\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 3 of 14\n\n15 are reserved. More than one logging level can be captured by ORing respective levels; supplying 255\r\n(0xFF) is the standard method of capturing all supported logging levels.\r\nKeywordsAll: Keywords are used to filter specific categories of events. While logging level is used to\r\nfilter by event verbosity/importance, keywords allow filtering by event category. A keyword corresponds to\r\na specific bit value. All indicates that, for a given keyword matched by KeywordsAny , further filtering\r\nshould be performed based on the specific bitmask in KeywordsAll . This field is often set to zero. More\r\ninformation on All vs. Any can be found here.\r\nKeywordsAny: Enables filtering based on any combination of the keywords specified. This can be thought\r\nof as a logical OR where KeywordsAll is a subsequent application of a logical AND. The low 6 bytes refer\r\nto keywords specific to the provider. The high two bytes are reserved and defined in WinMeta.xml in the\r\nWindows SDK. For example, in event log-related trace sessions, you will see the high byte (specifically,\r\nthe high nibble) set to a specific value. This corresponds to one or more event channels where the\r\nfollowing channels are defined:\r\n0x01 - Admin channel\r\n0x02 - Debug channel\r\n0x04 - Analytic channel\r\n0x08 - Operational channel\r\nProperties: This refers to optional ETW properties that can be specified when writing the event. The\r\nfollowing values are currently supported (more information here):\r\n0x001 - EVENT_ENABLE_PROPERTY_SID\r\n0x002 - EVENT_ENABLE_PROPERTY_TS_ID\r\n0x004 - EVENT_ENABLE_PROPERTY_STACK_TRACE\r\n0x008 - EVENT_ENABLE_PROPERTY_PSM_KEY\r\n0x010 - EVENT_ENABLE_PROPERTY_IGNORE_KEYWORD_0\r\n0x020 - EVENT_ENABLE_PROPERTY_PROVIDER_GROUP\r\n0x040 - EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0\r\n0x080 - EVENT_ENABLE_PROPERTY_PROCESS_START_KEY\r\n0x100 - EVENT_ENABLE_PROPERTY_EVENT_KEY\r\n0x200 - EVENT_ENABLE_PROPERTY_EXCLUDE_INPRIVATE\r\nFrom a detection perspective, EVENT_ENABLE_PROPERTY_SID, EVENT_ENABLE_PROPERTY_TS_ID,\r\nEVENT_ENABLE_PROPERTY_PROCESS_START_KEY are valuable fields to collect. For example,\r\nEVENT_ENABLE_PROPERTY_PROCESS_START_KEY generates a value that uniquely identifies a process.\r\nNote that Process IDs are not unique identifiers for a process instance.\r\nFilter Type: Providers can optionally choose to implement additional filtering; supported filters are\r\ndefined in the provider manifest. In practice, none of the built-in providers implement filters as confirmed\r\nby running TdhEnumerateProviderFilters over all registered providers. There are some predefined filter\r\ntypes defined in eventprov.h (in the Windows SDK):\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 4 of 14\n\n0x00000000 - EVENT_FILTER_TYPE_NONE\r\n0x80000000 - EVENT_FILTER_TYPE_SCHEMATIZED\r\n0x80000001 - EVENT_FILTER_TYPE_SYSTEM_FLAGS\r\n0x80000002 - EVENT_FILTER_TYPE_TRACEHANDLE\r\n0x80000004 - EVENT_FILTER_TYPE_PID\r\n0x80000008 - EVENT_FILTER_TYPE_EXECUTABLE_NAME\r\n0x80000010 - EVENT_FILTER_TYPE_PACKAGE_ID\r\n0x80000020 - EVENT_FILTER_TYPE_PACKAGE_APP_ID\r\n0x80000100 - EVENT_FILTER_TYPE_PAYLOAD\r\n0x80000200 - EVENT_FILTER_TYPE_EVENT_ID\r\n0x80000400 - EVENT_FILTER_TYPE_EVENT_NAME\r\n0x80001000 - EVENT_FILTER_TYPE_STACKWALK\r\n0x80002000 - EVENT_FILTER_TYPE_STACKWALK_NAME\r\n0x80004000 - EVENT_FILTER_TYPE_STACKWALK_LEVEL_KW\r\nEnumerating all registered ETW providers\r\nThe logman query providers command lists all registered ETW providers, supplying their name and GUID. An\r\nETW provider is registered if it has a binary manifest stored in the\r\nHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WINEVT\\Publishers\\{PROVIDER_GUID} registry key. For\r\nexample, the Microsoft-Windows-PowerShell provider has the following registry values:\r\nETW and the event log know how to properly parse and display event information to a user based on binary-serialized information in the WEVT_TEMPLATE resource present in the binaries listed in the ResourceFileName\r\nregistry value. This resource is a binary representation of an instrumentation manifest (i.e., the schema for an\r\nETW provider). The binary structure of WEVT_TEMPLATE is under-documented, but there are at least two tools\r\navailable to assist in parsing and recovering event schema, WEPExplorer and Perfview.\r\nViewing an individual provider\r\nThe logman tool prints basic information about a provider. For example:\r\nThe listings shows supported keywords and logging values, as well as all processes that are registered to emit\r\nevents via this provider. This output is useful for understanding how existing trace sessions filter on providers. It is\r\nalso useful for initial discovery of potentially interesting information that could be gathered from via an ETW\r\ntrace.\r\nNotably, the PowerShell provider appears to support logging to the event log based on the existence of the\r\nreserved keywords in the high nibble of the defined keywords. Not all ETW providers are designed to be ingested\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 5 of 14\n\ninto the event log; rather, many ETW providers are intended to be used solely for low-level tracing, debugging,\r\nand more recently-developed security telemetry purposes. For example, Windows Defender Advanced Threat\r\nProtection relies heavily upon ETW as a supplemental detection data source.\r\nViewing all providers that a specific process is sending events to\r\nAnother method for discovering potentially interesting providers is to view all providers to which events are\r\nwritten from a specific process. For example, the following listing shows all providers relevant to MsMpEng.exe\r\n(the Windows Defender service, running as pid 5244 in this example):\r\nEntries listed with GUID are providers lacking a manifest. They will typically be related to WPP or TraceLogging,\r\nboth of which are beyond the scope of this blog post. It is possible to retrieve provider names and event metadata\r\nfor these providers types. For example, here are some of the resolved provider names from the unnamed providers\r\nabove:\r\n05F95EFE-7F75–49C7-A994–60A55CC09571\r\nMicrosoft.Windows.Kernel.KernelBase\r\n072665FB-8953–5A85–931D-D06AEAB3D109\r\nMicrosoft.Windows.ProcessLifetimeManage\r\n7AF898D7–7E0E-518D-5F96-B1E79239484C\r\nMicrosoft.Windows.Defender\r\nEvent provider internals\r\nLooking at ETW-replated code snippets in built-in Windows binaries can help you understand how ETW events\r\nare constructed and how they surface in event logs. Below, we highlight two code samples,\r\nSystem.Management.Automation.dll (the core PowerShell assembly) and amsi.dll .\r\nSystem.Management.Automation.dll event tracing\r\nOne of the great security features of PowerShell version 5 is scriptblock autologging; when enabled, script content\r\nis automatically logged to the Microsoft-Windows-PowerShell/Operational event log with event ID 4104 (warning\r\nlevel) if the scriptblock contains any suspicious terms. The following C# code is executed to generate the event\r\nlog:\r\nFrom PowerShell\r\nThe LogOperationalWarning method is implemented as follows:\r\nFrom PowerShell\r\nThe WriteEvent method is implemented as follows:\r\nFrom PowerShell\r\nFinally, the event information is marshaled and EventWriteTransfer is called, supplying the Microsoft-Windows-PowerShell provider with event data.\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 6 of 14\n\nGet Palantir’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nThe relevant data supplied to EventWriteTransfer is as follows:\r\nMicrosoft-Windows-PowerShell provider GUID: {A0C1853B-5C40-4b15-8766-3CF1C58F985A}\r\nEvent ID: PSEventId.ScriptBlock_Compile_Detail - 4104\r\nChannel value: PSChannel.Operational - 16\r\nAgain, the usage of a channel value indicates that the provider is intended to be used with the event log.\r\nThe operational channel definition for the PowerShell ETW manifest can be seen here. When an explicit\r\nchannel value is not supplied, Message Compiler ( mc.exe ) will assign a default value starting at 16. Since\r\nthe operational channel was defined first, it was assigned 16.\r\nOpcode value: PSOpcode.Create - 15\r\nLogging level: PSLevel.Warning - 3\r\nTask value: PSTask.CommandStart - 102\r\nKeyword value: PSKeyword.UseAlwaysAnalytic - 0x4000000000000000\r\nThis value is later translated to 0 as seen in the code block above. Normally, this event would not be logged\r\nbut because the Application event log trace session specifies the\r\nEVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0 Enable flag for all of its providers which will log the event\r\ndespite a keyword value not being specified.\r\nEvent data: the scriptblock contents and event fields\r\nUpon receiving the event from the PowerShell ETW provider, the event log service parses the binary\r\nWEVT_TEMPLATE schema (original XML schema) and presents human-readable, parsed event properties/fields:\r\namsi.dll event tracing\r\nYou may have observed that Windows 10 has an AMSI/Operational event log that is typically empty. To\r\nunderstand why events are not logged to this event log, you would first have to inspect how data is fed to the\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 7 of 14\n\nAMSI ETW provider ( Microsoft-Antimalware-Scan-Interface - {2A576B87-09A7-520E-C21A-4942F0271D67} )\r\nand then observe how the Application event log trace session ( EventLog-Application ) subscribes to the AMSI\r\nETW provider. Let’s start by looking at the provider registration in the Application event log. The following\r\nPowerShell cmdlet will supply us with this information:\r\n\u003e Get-EtwTraceProvider -SessionName EventLog-Application -Guid '{2A576B87-09A7-520E-C21A-4942F0271D67\r\nGuid : {2A576B87-09A7-520E-C21A-4942F0271D67}\r\nLevel : 255\r\nMatchAnyKeyword : 0x8000000000000000\r\nMatchAllKeyword : 0x0\r\nEnableProperty : {EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0, EVENT_ENABLE_PROPERTY_SID}\r\nThe following properties should be noted:\r\nOperational channel events (as indicated by 0x8000000000000000 in the MatchAnyKeyword value) are\r\ncaptured.\r\nAll logging levels are captured.\r\nEvents should be captured even if an event keyword value is zero as indicated by the\r\nEVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0 flag.\r\nThis information on its own does not explain why AMSI events are not logged, but it supplies needed context\r\nupon inspecting how amsi.dll writes events to ETW. By loading amsi.dl into IDA, we can see that there was\r\na single call to the EventWrite function within the internal CAmsiAntimalware::GenerateEtwEvent function:\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 8 of 14\n\nThe relevant portion of the call to EventWrite is the EventDescriptor argument. Upon applying the\r\nEVENT_DESCRIPTOR structure type to _AMSI_SCANBUFFER , the following information was interpreted:\r\nThe EVENT_DESCRIPTOR context gives us the relevant information:\r\nEvent ID: 1101 (0x44D)\r\nThis events details can be extracted from a recovered manifest as seen here.\r\nChannel: 16 (0x10) referring to the operational event log channel\r\nLevel: 4 (Informational)\r\nKeyword: 0x8000000000000001 (AMSI/Operational OR Event1). These values are interpreted by running\r\nthe logman query providers Microsoft-Antimalware-Scan-Interface command.\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 9 of 14\n\nWe now understand that 1101 events not logged to the Application event log because it only considers events\r\nwhere the keyword value matches 0x8000000000000000. In order to fix this issue and get events pumping into\r\nthe event log, either the Application event log trace session would need to be modified (not recommended and\r\nrequires SYSTEM privileges) or you could create your own persistent trace session (e.g., an autologger) to capture\r\nAMSI events in the event log. The following PowerShell script creates such a trace session:\r\n$AutoLoggerGuid = \"{$((New-Guid).Guid)}\"\r\nNew-AutologgerConfig -Name MyCustomAutoLogger -Guid $AutoLoggerGuid -Start Enabled\r\nAdd-EtwTraceProvider -AutologgerName MyCustomAutoLogger -Guid '{2A576B87-09A7-520E-C21A-4942F0271D67}\r\nAfter running the above command, reboot, and the AMSI event log will begin to populate.\r\nSome additional reverse engineering showed that the scanResult field refers to the AMSI_RESULT enum\r\nwhere, in this case, 32768 maps to AMSI_RESULT_DETECTED , indicating that the buffer (the Unicode encoded\r\nbuffer in the content field) was determined to be malicious.\r\nWithout knowledge of ETW internals, a defender would not have been able to determine that additional data\r\nsources (the AMSI log in this case) can be fed into the event log. One would have to resort to speculation as to\r\nhow the AMSI event became to be misconfigured and whether or not the misconfiguration was intentional.\r\nETW tampering techniques\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 10 of 14\n\nIf the goal of an attacker is to subvert event logging, ETW provides a stealthy mechanism to affect logging\r\nwithout itself generating an event log trail. Below is a non-exhaustive list of tampering techniques that an attacker\r\ncan use to cut off the supply of events to a specific event log.\r\nTampering techniques can generally be broken down into two categories:\r\n1. Persistent, requiring reboot — i.e., a reboot must occur before the attack takes effect. Changes can be\r\nreverted, but would require another reboot. These attacks involve altering autologger settings — persistent\r\nETW trace sessions with settings in the registry. There are more types of persistent attacks than ephemeral\r\nattacks, and they are usually more straightforward to detect.\r\n2. Ephemeral — i.e., where the attack can take place without a reboot.\r\nAutologger provider removal\r\nTampering category: Persistent, requiring reboot\r\nMinimum permissions required: Administrator\r\nDetection artifacts: Registry key deletion:\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\WMI\\Autologger\\AUTOLOGGER_NAME\\{PROVIDER_GUID}\r\nDescription: This technique involves the removal of a provider entry from a configured autologger. Removing a\r\nprovider registration from an autologger will cause events to cease to flow to the respective trace session.\r\nExample: The following PowerShell code disables Microsoft-Windows-PowerShell event logging:\r\nRemove-EtwTraceProvider -AutologgerName EventLog-Application -Guid '{A0C1853B-5C40-4B15-8766-3CF1C58F\r\nIn the above example, A0C1853B-5C40-4B15-8766-3CF1C58F985A refers to the Microsoft-Windows-PowerShell\r\nETW provider. This command will end up deleting the\r\nHKLM\\System\\CurrentControlSet\\Control\\WMI\\Autologger\\EventLog-Application\\{a0c1853b-5c40-4b15-8766-\r\n3cf1c58f985a} registry key.\r\nProvider “Enable” property modification\r\nTampering category: Persistent, requiring reboot\r\nMinimum permissions required: Administrator\r\nDetection artifacts: Registry value modification:\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\WMI\\Autologger\\AUTOLOGGER_NAME\\{PROVIDER_GUID} - EnableProperty\r\n(REG_DWORD)\r\nDescription: This technique involves alerting the Enable keyword of an autologger session. For example, by\r\ndefault, all ETW provider entries in the EventLog-Application autologger session are set to 0x41 which\r\ntranslates to EVENT_ENABLE_PROPERTY_SID and EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0 .\r\nEVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0 is not documented; it specifies that any events generated for a\r\nprovider should be logged even if the keyword value is set to 0. An attacker could swap out\r\nEVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0 for EVENT_ENABLE_PROPERTY_IGNORE_KEYWORD_0 , resulting in a value\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 11 of 14\n\nof 0x11 , which would result in all events where the keyword is 0 to not be logged. For example, PowerShell\r\neventing supplies a 0 keyword value with its events, resulting in no logging to the PowerShell event log.\r\nExample: The following PowerShell code disables Microsoft-Windows-PowerShell event logging:\r\nSet-EtwTraceProvider -Guid '{A0C1853B-5C40-4B15-8766-3CF1C58F985A}' -AutologgerName 'EventLog-Applica\r\nIn the above example, A0C1853B-5C40-4B15-8766-3CF1C58F985A refers to the Microsoft-Windows-PowerShell\r\nETW provider. This command will end up setting\r\nHKLM\\System\\CurrentControlSet\\Control\\WMI\\Autologger\\EventLog-Application\\{a0c1853b-5c40-4b15-8766-\r\n3cf1c58f985a}\\EnableProperty to 0x11 . Upon rebooting, events will cease to be reported to the PowerShell\r\nevent log.\r\nAn attacker is not constrained to using just the Set-EtwTraceProvider cmdlet to carry out this attack. An attacker\r\ncould just modify the value directly in the registry. Set-EtwTraceProvider offers a convenient autologger\r\nconfiguration abstraction.\r\nAlternative detection artifacts/ideas: If possible, it is advisable to monitor for modifications of values within the\r\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\WMI\\Autologger\\AUTOLOGGER_NAME\\{PROVIDER_GUID} registry key.\r\nNote that modifying EnableProperty is just one specific example and that an attacker can alter ETW providers\r\nin other ways, too.\r\nETW provider removal from a trace session\r\nTampering category: Ephemeral\r\nMinimum permissions required: SYSTEM\r\nDetection artifacts: Unfortunately, no file, registry, or event log artifacts are associated with this event. While the\r\ntechnique example below indicates that logman.exe was used to perform the attack, an attacker can obfuscate\r\ntheir techniques by using Win32 APIs directly, WMI, DCOM, PowerShell, etc.\r\nDescription: This technique involves removing an ETW provider from a trace session, cutting off its ability to\r\nsupply a targeted event log with events until a reboot occurs, or until the attacker restores the provider. While an\r\nattacker must have SYSTEM privileges to perform this attack, it is unlikely that defenders will notice such an\r\nattack if they rely on event logs for threat detection.\r\nExample: The following PowerShell code immediately disables Microsoft-Windows-PowerShell event logging\r\nuntil a reboot occurs or the attacker restores the ETW provider:\r\nlogman update trace EventLog-Application --p Microsoft-Windows-PowerShell -ets\r\nAlternative detection artifacts/ideas:\r\nEvent ID 12 within the Microsoft-Windows-Kernel-EventTracing/Analytic log indicates when a trace\r\nsession is modified, but it doesn’t supply the provider name or GUID that was removed, so it would be\r\ndifficult to confidently determine whether or not something suspicious occurred using this event.\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 12 of 14\n\nThere have been several references thus far to the ETW PowerShell cmdlets housed in the\r\nEventTracingManagement module, which itself is a CDXML-based module. This means that all the\r\ncmdlets in the EventTracingManagement are backed by WMI classes. For example, the Get-EtwTraceProvider cmdlet is backed by the\r\nROOT/Microsoft/Windows/EventTracingManagement:MSFT_EtwTraceProvider class. Considering ETW\r\nproviders can be represented in the form of WMI class instances, you could craft a permanent WMI event\r\nsubscription that logs all provider removals from a specific trace session to the event log. This code sample\r\ncreates an NtEventLogEventConsumer instance that logs event ID 8 to the Application event log (source:\r\nWSH) any time a provider is removed from the Application event log trace session, EventLog-Application . The logged event looks like the following:\r\nThe frequency at which providers are removed from Application event logs in large environments is not\r\ncurrently known. As as fallback, it is still advised to log the execution of logman.exe , wpr.exe , and\r\nPowerShell in your environment.\r\nConclusion\r\nIdentifying blind spots and assumptions in Alerting and Detection Strategies is a crucial step in ensuring the\r\nresilience of detections. Since ETW is at the core of the event logging infrastructure, gaining an in-depth\r\nunderstanding of ETW tampering attacks is a valuable way to increase the integrity of security-related data\r\nsources.\r\nFurther Reading\r\nETW — Overview\r\nInstrumenting Your Code with ETW\r\nEvent Tracing for Windows: Reducing Everest to Pike’s Peak\r\nUse this not this: Logging / Event Tracing\r\nWriting an Instrumentation Manifest\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 13 of 14\n\nEvent Tracing Functions\r\nConfiguring and Starting an AutoLogger Session\r\nEvent Tracing\r\nTraceLogging\r\nSource: https://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nhttps://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63\r\nPage 14 of 14\n\nProvider performing GUID: research The unique GUID or operations for the provider. on a specific provider. The GUID and/or name of a provider is useful when\nLevel: The logging level specified. Standard logging levels are: 0-Log Always; 1- Critical; 2 -Error;\n3 -Warning; 4-Informational; 5-Verbose. Custom logging levels can also be defined, but levels 6-\n   Page 3 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63"
	],
	"report_names": [
		"tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63"
	],
	"threat_actors": [],
	"ts_created_at": 1775434309,
	"ts_updated_at": 1775791273,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d7cfeedd3fd12d7538d7b0143df0510f4f383971.pdf",
		"text": "https://archive.orkl.eu/d7cfeedd3fd12d7538d7b0143df0510f4f383971.txt",
		"img": "https://archive.orkl.eu/d7cfeedd3fd12d7538d7b0143df0510f4f383971.jpg"
	}
}