午夜精品久久久久久久爽,国产精品乱,香蕉视频亚洲

針對 Windows 事件跟蹤日志篡改的攻防研究

責編：gltian ｜2018-12-29 10:29:47

前言

Windows事件跟蹤(Event Tracing for Windows,ETW)是Windows用于跟蹤和記錄系統事件的機制。攻擊者經常通過清除事件日志來掩蓋他們的蹤跡。雖然清除事件日志會生成事件，但熟悉ETW的攻擊者可能會利用篡改技術暫時中止甚至永久停止日志記錄，并且整個過程不會生成任何事件日志。

Windows事件日志是Palantir應急小組的警報和檢測策略的數據源，因此熟悉事件日志篡改操作對我們至關重要。我們不斷地評估關于事件數據源完整性的假設，記錄盲點，并調整實現。這篇文章的目的是與社區分享ETW背景和基礎知識、事件日志篡改技術和檢測策略。

ETW和事件日志

ETW結構分為三個部分：事件提供者(provider)、事件消費者(consumers)和事件跟蹤會話(tracing session)。跟蹤會話負責從提供者收集事件，并傳送到日志文件和消費者。會話由控制者(controller)創建和配置，比如內置的logman.exe命令行工具。下面是一些常用的命令，用于搜索現有的跟蹤會話和各自的ETW提供者；請注意，這些命令通常需要足夠的權限才能運行。

列出所有正在運行的跟蹤會話

> logman query -ets
Data Collector Set                Type    Status
-------------------------------------------------
Circular Kernel Context Logger    Trace   Running
AppModel                          Trace   Running
ScreenOnPowerStudyTraceSession    Trace   Running
DiagLog                           Trace   Running
EventLog-Application              Trace   Running
EventLog-System                   Trace   Running
LwtNetLog                         Trace   Running
NtfsLog                           Trace   Running
TileStore                         Trace   Running
UBPM                              Trace   Running
WdiContextLog                     Trace   Running
WiFiSession                       Trace   Running
UserNotPresentTraceSession        Trace   Running
Diagtrack-Listener                Trace   Running
MSDTC_TRACE_SESSION               Trace   Running
WindowsUpdate_trace_log           Trace   Running

列出所有訂閱跟蹤會話的提供者

> logman query "EventLog-Application" -ets
Name:                 EventLog-Application
Status:               Running
Root Path:            %systemdrive%PerfLogsAdmin
Segment:              Off
Schedules:            On
Segment Max Size:     100 MB

Name:                 EventLog-ApplicationEventLog-Application
Type:                 Trace
Append:               Off
Circular:             Off
Overwrite:            Off
Buffer Size:          64
Buffers Lost:         0
Buffers Written:      242
Buffer Flush Timer:   1
Clock Type:           System
File Mode:            Real-time

Provider:
Name:                 Microsoft-Windows-SenseIR
Provider Guid:        {B6D775EF-1436-4FE6-BAD3-9E436319E218}
Level:                255
KeywordsAll:          0x0
KeywordsAny:          0x8000000000000000 (Microsoft-Windows-SenseIR/Operational)
Properties:           65
Filter Type:          0

Provider:
Name:                 Microsoft-Windows-WDAG-Service
Provider Guid:        {728B02D9-BF21-49F6-BE3F-91BC06F7467E}
Level:                255
KeywordsAll:          0x0
KeywordsAny:          0x8000000000000000
Properties:           65
Filter Type:          0

...

Provider:
Name:                 Microsoft-Windows-PowerShell
Provider Guid:        {A0C1853B-5C40-4B15-8766-3CF1C58F985A}
Level:                255
KeywordsAll:          0x0
KeywordsAny:          0x9000000000000000 (Microsoft-Windows-PowerShell/Operational,Microsoft-Windows-PowerShell/Admin)
Properties:           65
Filter Type:          0

該命令詳細說明了跟蹤會話的配置，還有每個訂閱會話的提供者的配置，包括以下參數：

Name: 提供者的名稱。提供者只有在有已注冊的manifest的情況下才有名稱，但它始終具有唯一的GUID。
Provider GUID: 提供者的GUID。在對特定提供者進行分析或操作時，GUID和（或）提供者的名稱非常有用。
Level: 指定日志記錄級別。標準的日志記錄級別是：0-Log Always；1-?Critical；2-Error；3-Warning；4-?Informational；5-Verbose。也可以自定義日志記錄級別，但級別6-15是保留的。每個ORing級別可以捕獲多個日志記錄級別；通常使用255(0xFF)捕獲所有支持的日志記錄級別。
KeywordsAll: 關鍵字用于篩選特定類別的事件。日志記錄級別用于按事件詳細/重要性進行篩選，而關鍵字允許按事件類別進行篩選。關鍵字對應于特定的位值。所有這些都表明，對于由KeywordsAny匹配的給定關鍵字，應該根據KeywordsAll中的特定位掩碼進行進一步的篩選。這個字段通常設置為零。在這里可以找到更多信息。
KeywordsAny：基于指定的任意關鍵字組合啟用篩選。這可以看作是邏輯或，而KeywordsAll是邏輯和。低位的6個字節指定特定提供者的關鍵字。高位的兩個字節是在Windows SDK中的WinMeta.xml中保留和定義的。例如，在與事件日志相關的跟蹤會話中，可以看到設置為特定值的高位字節。這對應于下面的一個或多個事件通道：
```
  0x01 - Admin channel
  0x02 - Debug channel
  0x04 - Analytic channel
  0x08 - Operational channel
```

Properties: 在寫入事件時可以指定的可選ETW屬性。目前支持的值(更多信息查看這里)：

  0x001 - EVENT_ENABLE_PROPERTY_SID
  0x002 - EVENT_ENABLE_PROPERTY_TS_ID
  0x004 - EVENT_ENABLE_PROPERTY_STACK_TRACE
  0x008 - EVENT_ENABLE_PROPERTY_PSM_KEY
  0x010 - EVENT_ENABLE_PROPERTY_IGNORE_KEYWORD_0
  0x020 - EVENT_ENABLE_PROPERTY_PROVIDER_GROUP
  0x040 - EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0
  0x080 - EVENT_ENABLE_PROPERTY_PROCESS_START_KEY
  0x100 - EVENT_ENABLE_PROPERTY_EVENT_KEY
  0x200 - EVENT_ENABLE_PROPERTY_EXCLUDE_INPRIVATE

從檢測的角度來看，EVENT_ENABLE_PROPERTY_SID、EVENT_ENABLE_PROPERTY_TS_ID、EVENT_ENABLE_PROPERTY_PROCESS_START_KEY是值得收集的字段。例如，EVENT_ENABLE_PROPERTY_PROCESS_START_KEY生成唯一標識進程的值。注意，Process ID不是進程實例的唯一標識符。

篩選器（Filter Type）：提供者可以選擇其他篩選；支持的篩選器是在提供者manifest中定義的。實際上在所有注冊的提供者上運行TdhEnumerateProviderFilters時，內置提供者都沒有運行過濾器。eventprov.h(在Windows SDK中)中的一些預定義的篩選器類型：

0x00000000 - EVENT_FILTER_TYPE_NONE
0x80000000 - EVENT_FILTER_TYPE_SCHEMATIZED
0x80000001 - EVENT_FILTER_TYPE_SYSTEM_FLAGS
0x80000002 - EVENT_FILTER_TYPE_TRACEHANDLE
0x80000004 - EVENT_FILTER_TYPE_PID
0x80000008 - EVENT_FILTER_TYPE_EXECUTABLE_NAME
0x80000010 - EVENT_FILTER_TYPE_PACKAGE_ID
0x80000020 - EVENT_FILTER_TYPE_PACKAGE_APP_ID
0x80000100 - EVENT_FILTER_TYPE_PAYLOAD
0x80000200 - EVENT_FILTER_TYPE_EVENT_ID
0x80000400 - EVENT_FILTER_TYPE_EVENT_NAME
0x80001000 - EVENT_FILTER_TYPE_STACKWALK
0x80002000 - EVENT_FILTER_TYPE_STACKWALK_NAME
0x80004000 - EVENT_FILTER_TYPE_STACKWALK_LEVEL_KW

列出所有已注冊的ETW提供者

logman query providers命令列出所有已注冊的ETW提供者，還有它們的名稱和GUID。如果將二進制manifest保存在HKLMSOFTWAREMicrosoftWindowsCurrentVersionWINEVTPublishers{PROVIDER_GUID}注冊表項中，則將注冊ETW提供者。例如，Microsoft-Windows-PowerShell提供者具有以下注冊表值：

ETW和事件日志知道如何根據在ResourceFileName注冊表值中列出的二進制文件中的WEVT_TEMPLATE的序列化二進制信息正確地解析事件信息并向用戶顯示事件信息。該資源是工具清單(instrumentation manifest)的二進制表示。我們沒有關于WEVT_Template二進制結構的說明文檔，但至少有兩個工具可用于幫助解析和恢復事件模式(event schema)：WEPExplorer和Perfview。

單獨查看提供者

logman打印提供者的基本信息。例如：

> logman query providers Microsoft-Windows-PowerShell
Provider                        GUID
----------------------------------------------------------------------
Microsoft-Windows-PowerShell    {A0C1853B-5C40-4B15-8766-3CF1C58F985A}

Value               Keyword              Description
----------------------------------------------------------------------
0x0000000000000001  Runspace             PowerShell Runspace
0x0000000000000002  Pipeline             Pipeline of Commands
0x0000000000000004  Protocol             PowerShell remoting protocol
0x0000000000000008  Transport            PowerShell remoting transport
0x0000000000000010  Host                 PowerShell remoting host proxy calls
0x0000000000000020  Cmdlets              All remoting cmdlets
0x0000000000000040  Serializer           The serialization layer
0x0000000000000080  Session              All session layer
0x0000000000000100  Plugin               The managed PowerShell plugin worker
0x0000000000000200  PSWorkflow           PSWorkflow Hosting And Execution Layer
0x0001000000000000  win:ResponseTime     Response Time
0x8000000000000000  Microsoft-Windows-PowerShell/Operational Microsoft-Windows-PowerShell/Operational
0x4000000000000000  Microsoft-Windows-PowerShell/Analytic Microsoft-Windows-PowerShell/Analytic
0x2000000000000000  Microsoft-Windows-PowerShell/Debug Microsoft-Windows-PowerShell/Debug
0x1000000000000000  Microsoft-Windows-PowerShell/Admin Microsoft-Windows-PowerShell/Admin

Value        Level                Description
--------------------------------------------------------------------
0x02         win:Error            Error
0x03         win:Warning          Warning
0x04         win:Informational    Information
0x05         win:Verbose          Verbose
0x14         Debug                Debug level defined by PowerShell (which is above Informational defined by system)

PID          Image
----------------------------------------------------------------------
0x00000730   C:WindowsSystem32WindowsPowerShellv1.0powershell.exe
0x0000100c   C:WindowsSystem32WindowsPowerShellv1.0powershell.exe

結果顯示了可用的關鍵字和日志記錄值，以及通過該提供者注冊發出事件的所有進程。這些輸出對于了解現有跟蹤會話如何在提供者上篩選非常有用，還有助于初步發現其他有趣的信息，這些信息可以通過ETW跟蹤收集。

特別要注意的是，PowerShell提供者似乎支持基于在定義的關鍵字中的保留關鍵字進行日志記錄。并不是所有的ETW提供者都用于事件日志；相反，許多ETW提供者只是用于低級別的跟蹤、調試和最近應用的安全測試。例如，Windows Defender Advanced Threat Protection嚴重依賴ETW作為補充的檢測數據源。

查看所有接收特定進程事件的提供者

另一種發現目標提供者的方法是查看所有接收特定進程事件的提供者。例如，下面顯示了與MsMpEng.exe(Windows Defender服務，在本例中通過PID 5244運行)相關的所有提供者：

> logman query providers -pid 5244
Provider                                 GUID
-------------------------------------------------------------------------------
FWPUCLNT Trace Provider                  {5A1600D2-68E5-4DE7-BCF4-1C2D215FE0FE}
Microsoft-Antimalware-Protection         {E4B70372-261F-4C54-8FA6-A5A7914D73DA}
Microsoft-Antimalware-RTP                {8E92DEEF-5E17-413B-B927-59B2F06A3CFC}
Microsoft-Antimalware-Service            {751EF305-6C6E-4FED-B847-02EF79D26AEF}
Microsoft-IEFRAME                        {5C8BB950-959E-4309-8908-67961A1205D5}
Microsoft-Windows-AppXDeployment         {8127F6D4-59F9-4ABF-8952-3E3A02073D5F}
Microsoft-Windows-ASN1                   {D92EF8AC-99DD-4AB8-B91D-C6EBA85F3755}
Microsoft-Windows-AsynchronousCausality  {19A4C69A-28EB-4D4B-8D94-5F19055A1B5C}
Microsoft-Windows-CAPI2                  {5BBCA4A8-B209-48DC-A8C7-B23D3E5216FB}
Microsoft-Windows-COM-Perf               {B8D6861B-D20F-4EEC-BBAE-87E0DD80602B}
Microsoft-Windows-COM-RundownInstrumentation {2957313D-FCAA-5D4A-2F69-32CE5F0AC44E}
Microsoft-Windows-COMRuntime             {BF406804-6AFA-46E7-8A48-6C357E1D6D61}
Microsoft-Windows-Crypto-BCrypt          {C7E089AC-BA2A-11E0-9AF7-68384824019B}
Microsoft-Windows-Crypto-NCrypt          {E8ED09DC-100C-45E2-9FC8-B53399EC1F70}
Microsoft-Windows-Crypto-RSAEnh          {152FDB2B-6E9D-4B60-B317-815D5F174C4A}
Microsoft-Windows-Deplorch               {B9DA9FE6-AE5F-4F3E-B2FA-8E623C11DC75}
Microsoft-Windows-DNS-Client             {1C95126E-7EEA-49A9-A3FE-A378B03DDB4D}
Microsoft-Windows-Heap-Snapshot          {901D2AFA-4FF6-46D7-8D0E-53645E1A47F5}
Microsoft-Windows-Immersive-Shell-API    {5F0E257F-C224-43E5-9555-2ADCB8540A58}
Microsoft-Windows-Kernel-AppCompat       {16A1ADC1-9B7F-4CD9-94B3-D8296AB1B130}
Microsoft-Windows-KnownFolders           {8939299F-2315-4C5C-9B91-ABB86AA0627D}
Microsoft-Windows-MPS-CLNT               {37945DC2-899B-44D1-B79C-DD4A9E57FF98}
Microsoft-Windows-Networking-Correlation {83ED54F0-4D48-4E45-B16E-726FFD1FA4AF}
Microsoft-Windows-NetworkProfile         {FBCFAC3F-8459-419F-8E48-1F0B49CDB85E}
Microsoft-Windows-RPC                    {6AD52B32-D609-4BE9-AE07-CE8DAE937E39}
Microsoft-Windows-RPC-Events             {F4AED7C7-A898-4627-B053-44A7CAA12FCD}
Microsoft-Windows-Schannel-Events        {91CC1150-71AA-47E2-AE18-C96E61736B6F}
Microsoft-Windows-Shell-Core             {30336ED4-E327-447C-9DE0-51B652C86108}
Microsoft-Windows-URLMon                 {245F975D-909D-49ED-B8F9-9A75691D6B6B}
Microsoft-Windows-User Profiles General  {DB00DFB6-29F9-4A9C-9B3B-1F4F9E7D9770}
Microsoft-Windows-User-Diagnostic        {305FC87B-002A-5E26-D297-60223012CA9C}
Microsoft-Windows-WebIO                  {50B3E73C-9370-461D-BB9F-26F32D68887D}
Microsoft-Windows-Windows Defender       {11CD958A-C507-4EF3-B3F2-5FD9DFBD2C78}
Microsoft-Windows-WinHttp                {7D44233D-3055-4B9C-BA64-0D47CA40A232}
Microsoft-Windows-WinRT-Error            {A86F8471-C31D-4FBC-A035-665D06047B03}
Microsoft-Windows-Winsock-NameResolution {55404E71-4DB9-4DEB-A5F5-8F86E46DDE56}
Network Profile Manager                  {D9131565-E1DD-4C9E-A728-951999C2ADB5}
Security: SChannel                       {37D2C3CD-C5D4-4587-8531-4696C44244C8}
Windows Defender Firewall API            {28C9F48F-D244-45A8-842F-DC9FBC9B6E92}
WMI_Tracing                              {1FF6B227-2CA7-40F9-9A66-980EADAA602E}
WMI_Tracing_Client_Operations            {8E6B6962-AB54-4335-8229-3255B919DD0E}
{05F95EFE-7F75-49C7-A994-60A55CC09571}   {05F95EFE-7F75-49C7-A994-60A55CC09571}
{072665FB-8953-5A85-931D-D06AEAB3D109}   {072665FB-8953-5A85-931D-D06AEAB3D109}
{7AF898D7-7E0E-518D-5F96-B1E79239484C}   {7AF898D7-7E0E-518D-5F96-B1E79239484C}
... output truncated ...

帶有GUID的是缺少manifest的提供者。它們通常與WPP或TraceLogging有關，這些都超出了本文的范圍?？梢詸z索這些提供者類型的名稱和事件元數據。例如，下面是解析后一些上面未命名提供者的名稱：

05F95EFE-7F75–49C7-A994–60A55CC09571 Microsoft.Windows.Kernel.KernelBase
072665FB-8953–5A85–931D-D06AEAB3D109 Microsoft.Windows.ProcessLifetimeManage
7AF898D7–7E0E-518D-5F96-B1E79239484C Microsoft.Windows.Defender

事件提供者的內部

查看內置Windows二進制文件中的ETW相關代碼，可以幫助你了解ETW事件是如何構造的，以及它們是如何在事件日志中顯示的。下面是兩個示例，System.Management.Automation.dll(PowerShell程序集核心)和amsi.dll。

System.Management.Automation.dll事件跟蹤

PowerShell v.5最大的安全特性之一是scriptblock autologging；啟用后，如果腳本包含任何可疑代碼，則在Microsoft-Windows-PowerShell/Operational事件日志中自動記錄腳本內容和事件ID 4104(警告級別)。執行以下C#代碼以生成事件日志：

if (scriptBlock._scriptBlockData.HasSuspiciousContent)
{
  PSEtwLog.LogOperationalWarning(PSEventId.ScriptBlock_Compile_Detail, PSOpcode.Create, PSTask.ExecuteCommand, PSKeyword.UseAlwaysAnalytic, new object[]
  {
    segment + 1,
    segments,
    textToLog,
    scriptBlock.Id.ToString(),
    scriptBlock.File ?? string.Empty
  });
}

LogOperationalWarning方法實現如下：

internal static void LogOperationalInformation(PSEventId id, PSOpcode opcode, PSTask task, PSKeyword keyword, params object[] args)
{
  PSEtwLog.provider.WriteEvent(id, PSChannel.Operational, opcode, PSLevel.Informational, task, keyword, args);
}

WriteEvent方法實現如下：


internal void WriteEvent(PSEventId id, PSChannel channel, PSOpcode opcode, PSLevel level, PSTask task, PSKeyword keyword, params object[] args)
{
  long keywords;
  if (keyword == PSKeyword.UseAlwaysAnalytic || keyword == PSKeyword.UseAlwaysOperational) {
    keywords = 0L;
  } else {
    keywords = (long)keyword;
  }

  EventDescriptor eventDescriptor = new EventDescriptor((int)id, 1, (byte)channel, (byte)level, (byte)opcode, (int)task, keywords);
  PSEtwLogProvider.etwProvider.WriteEvent(ref eventDescriptor, args);
}

最后整理事件信息，并調用EventWriteTransfer，將事件數據發送給Microsoft-Windows-PowerShell提供者。

發送
給EventWriteTransfer的相關數據如下：

Microsoft-Windows-PowerShell提供者的GUID:?{A0C1853B-5C40-4b15-8766-3CF1C58F985A}
Event ID:?PSEventId.ScriptBlock_Compile_Detail - 4104
通道值（Channel value）：PSChannel.Operational - 16，使用通道值表明提供者將被事件日志一起使用。這里可以查看PowerShell ETW manifest的通道定義。當未提供顯式通道值時，Message Compiler(mc.exe)將分配從16開始的默認值。由于首先定義了操作通道，因此分配了16條。
Opcode值（Opcode value）:?PSOpcode.Create - 15
日志記錄級別（Logging Level）:?PSLevel.Warning - 3
任務值（Task value）:?PSTask.CommandStart-102
關鍵字值（Keyword value）:PSKeyword.UseAlwaysAnalytic-0x40000000000000。如上面的代碼塊所示，這個值之后被轉換為0。通常情況下，不會記錄這個事件，但是因為應用程序事件日志跟蹤會話為其所有提供者設置了EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0 Enable，盡管未指定關鍵字值，但所有提供者都將記錄該事件。
事件數據（Event data）：代碼內容和事件字段

PowerShell ETW提供者接收到事件后，事件日志服務將解析二進制WEVT_TEMPLATE?schema(原始XML schema)，并顯示可讀的、已解析的事件屬性/字段：

amsi.dll事件跟蹤

你可能已經注意到Windows 10有一個通常為空的AMSI/Operational事件日志。要理解為什么沒有將事件記錄到該事件日志，必須首先檢查數據如何被輸入AMSI ETW提供者(Microsoft-Antimalware-Scan-Interface - {2A576B87-09A7-520E-C21A-4942F0271D67})，然后觀察事件日志跟蹤會話(EventLog-Application)如何訂閱AMSI ETW提供者。我們首先查看事件日志中的提供者注冊情況。使用以下PowerShell命令查看：

> Get-EtwTraceProvider -SessionName EventLog-Application -Guid '{2A576B87-09A7-520E-C21A-4942F0271D67}'
SessionName     : EventLog-Application
Guid            : {2A576B87-09A7-520E-C21A-4942F0271D67}
Level           : 255
MatchAnyKeyword : 0x8000000000000000
MatchAllKeyword : 0x0
EnableProperty  : {EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0, EVENT_ENABLE_PROPERTY_SID}

注意下面的信息：

捕獲操作通道事件(由MatchAnyKeyword值的0x8000000000000000設置)
捕獲所有日志記錄級別
即使事件關鍵字值為零，也應該捕獲事件，通過EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0設置。

這些信息本身并不說明為什么AMSI事件不被記錄，但它提供了在檢查amsi.dll如何將事件寫入ETW時所需的上下文信息。把amsi.dl加載到IDA中，我們可以看到CAmsiAntimalware::GenerateEtwEvent函數中有一個對EventWrite函數的調用：

調用EventWrite的相關部分是EventDescriptor參數。以下是一些關于將EVENT_DESCRIPTOR結構類型應用于_AMSI_SCANBUFFER的信息：

EventDescriptor上下文提供了相關信息：

事件ID（Event ID）：1101(0x44D)，事件的詳細信息可以從提取的manifest中獲取，這里。
通道（Channel）：16(0x10)，操作事件日志通道
級別（Level）：4(Informational)
關鍵詞（Keyword）：0x80000000000001(AMSI/Operationor Event1)。這些值是通過運行logman query providers Microsoft-Antimalware-Scan-Interface命令得到的。

現在我們了解到，1101事件沒有被記錄到ApplicationEvent日志，因為它只考慮關鍵字值與0x8000000000000000匹配的事件。為了解決這個問題并將事件寫入事件日志，需要修改事件日志跟蹤會話(不建議使用，并且需要SYSTEM權限)，也可以創建自己的持久跟蹤會話(例如autologger)，以便在事件日志中捕獲AMSI事件。下面的PowerShell腳本創建這樣一個跟蹤會話：

$AutoLoggerGuid = "{$((New-Guid).Guid)}"
New-AutologgerConfig -Name MyCustomAutoLogger -Guid $AutoLoggerGuid -Start Enabled
Add-EtwTraceProvider -AutologgerName MyCustomAutoLogger -Guid '{2A576B87-09A7-520E-C21A-4942F0271D67}' -Level 0xff -MatchAnyKeyword 0x80000000000001 -Property 0x41

運行上述命令后，重新啟動，將開始寫入AMSI事件日志。

逆向分析顯示，scanResult字段引用的是AMSI_RESULT?enum，在本例中，32768映射到AMSI_RESULT_DETECTED，這表明緩沖區(內容字段中的Unicode編碼緩沖區)被確定為是惡意的。

如果不了解ETW的內部結構，防御者就無法確定是否可以將額外的數據源(在本例中為AMSI日志)輸入到事件日志中。同時不得不猜測AMSI事件是如何被錯誤配置的，以及錯誤配置是否是故意的。

ETW篡改技術

如果攻擊者的目標是破壞事件日志記錄，那么ETW提供了一種隱蔽的機制來保護日志記錄，而不會生成事件日志跟蹤。下面是部分篡改技術，攻擊者可以使用這些技術來切斷特定事件日志的事件來源。

持久性——需要重新啟動。也就是說，在攻擊生效之前必須重新啟動。更改可以恢復，但需要重新啟動。這些攻擊涉及更改autologger，持久化ETW跟蹤會話和注冊表中的設置。與暫時的攻擊相比，持久性攻擊的類型更多，而且它們通常更容易被檢測到。
暫時的——也就是說，可以在不重新啟動的情況下攻擊。

刪除autologger提供者

篡改類別：?持久性, 需要重啟

最低權限：?Administrator

檢測方法：?刪除注冊表項:
HKLMSYSTEMCurrentControlSetControlWMIAutologgerAUTOLOGGER_NAME{PROVIDER_GUID}

描述：?這項技術涉及從配置的autologger中刪除提供者條目。從autologger中刪除提供者注冊將導致事件停止傳輸相應的跟蹤會話。

示例：?下面的PowerShell代碼禁用Microsoft-WindowsPowerShell事件日志記錄：

Remove-EtwTraceProvider -AutologgerName EventLog-Application -Guid '{A0C1853B-5C40-4B15-8766-3CF1C58F985A}'

在上面的例子中，A0C1853B-5C40-4B15-8766-3CF1C58F985A引用了MicrosoftWindows-PowerShell ETW提供者。該命令最終會刪除HKLMSystemCurrentControlSetControlWMIAutologgerEventLog-Application{a0c1853b-5c40-4b15-8766-3cf1c58f985a}注冊表項。

修改提供者“Enable”屬性

篡改類別：?持久性, 需要重啟

最低權限：?Administrator

檢測方法：?刪除注冊表項：HKLMSYSTEMCurrentControlSetControlWMIAutologgerAUTOLOGGER_NAME{PROVIDER_GUID}-EnableProperty(REG_DWORD)

描述：?這種技術涉及autologger的Enable關鍵字。例如，默認情況下，EventLog-Application?autoologger會話中的所有ETW提供者項都設置為0x41，這將轉換為EVENT_ENABLE_PROPERTY_SID和EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0。事件_Enable_Property_Enable_關鍵字_0沒有文檔說明；它指定即使關鍵字值設置為0，也應該記錄為提供者生成的任何事件。攻擊者可以將EVENT_ENABLE_PROPERTY_ENABLE_KEYWORD_0替換為Event_Enable_Property_NORE_KEKEY_0，結果值為0x11，這將導致所有關鍵字為0的事件不啟用日志記錄。例如，PowerShell事件在其事件中提供了一個0關鍵字值，導致禁用了PowerShell事件日志。

示例：?下面的PowerShell代碼禁用Microsoft-WindowsPowerShell事件日志記錄：

Set-EtwTraceProvider -Guid '{A0C1853B-5C40-4B15-8766-3CF1C58F985A}' -AutologgerName 'EventLog-Application' -Property 0x11

在上面的例子中，A0C1853B-5C40-4B15-8766-3CF1C58F985A引用了Microsoft Windows-PowerShell ETW提供者。該命令將最終將HKLMSystemCurrentControlSetControlWMIAutologgerEventLog-Application{a0c1853b-5c40-4b15-8766-3cf1c58f985a}EnableProperty設置為0x11。重新啟動后，將停用PowerShell事件日志。

攻擊者不受限制，僅使用[Set-EtwTraceProvider](https://docs.microsoft.com/en-us/powershell/module/eventtracmancmdlets/set-etwtraceprovider?view=win10-ps)就能執行該攻擊。攻擊者可以直接修改注冊表中的值。Set-EtwTraceProvider提供了一個抽象的 autologger。

其他檢測方法：?如果可能，建議檢測HKLMSYSTEMCurrentControlSetControlWMIAutologgerAUTOLOGGER_NAME{PROVIDER_GUID}注冊表項中值的改動。請注意，修改EnableProperty只是一個特定的例子，攻擊者也可以通過其他方式更改ETW提供者。

從跟蹤會話中刪除ETW提供者

篡改類別：?暫時

最低權限：?SYSTEM

檢測方法：?不幸的是，沒有任何文件、注冊表或事件日志與該事件相關聯。雖然下面的技術示例表明logman.exe用于執行攻擊，但攻擊者可以直接使用Win32 API、WMI、DCOM、PowerShell等進行混淆。

描述：?該技術涉及從跟蹤會話中移除ETW提供者，切斷事件日志記錄，直到遇到重新啟動，或直到攻擊者恢復提供者。雖然攻擊者必須擁有執行該攻擊的系統權限，但如果攻擊者依賴事件日志進行威脅檢測，則不太可能注意到這種攻擊。

示例：?下面的PowerShell代碼會禁用Windows-PowerShell事件日志記錄，直到重新啟動或攻擊者恢復ETW提供者：

logman update trace EventLog-Application --p Microsoft-Windows-PowerShell -ets

其他方法：

Microsoft-Windows-Kernel-EventTracing/Analytic日志中的事件ID 12指定何時修改跟蹤會話，但它沒有提供已刪除的提供者名稱或GUID，因此使用該事件很難確定是否發生可疑事件。
到目前為止，已經有幾個引用包含在EventTracingManagement模塊中的ETW PowerShell命令，這個模塊本身就是一個基于CDXML的模塊。這意味著EventTracingManagement中的所有命令都由WMI類支持。例如，Get-EtwTraceProvider命令由ROOT/Microsoft/Windows/EventTracingManagement:MSFT_EtwTraceProvider類支持。考慮到ETW提供者可以WMI類實例的形式表示，可以創建一個永久WMI事件訂閱，記錄所有從特定跟蹤會話到事件日志刪除提供者的操作。這段代碼創建一個NtEventLogEventConsumer實例，用于在事件日志跟蹤會話EventLog-Application中刪除提供者時將事件ID 8記錄到事件日志(Source：WSH)。記錄的事件如下所示：
目前尚不清楚在大型環境中從事件日志中移除提供者的頻率。但我們仍然建議環境中記錄logman.exe、wpr.exe和PowerShell的執行情況。