0x00 前言

AMSI（Antimalware Scan Interface，反恶意软件扫描接口）是微软提供的一个接口，可以方便端点安全厂商获取某些组件的内存缓冲区数据。根据微软官方文档，如下组件可以接入AMSI：

• UAC（User Account Control，用户账户控制，安装执行EXE、COM、MSI或者ActiveX时用来提升权限）

• PowerShell（脚本、交互式使用以及动态代码执行）

• Windows Script Host（wscript.exe以及cscript.exe）

• JavaScript以及VBScript

• Office VBA宏

防御方关心的是检测引擎，攻击方关注的是如何发展规避技术。从这两者的角度出发，我主要思考了如下几个问题：

• 接入AMSI接口的这些组件实际对应的究竟是哪些PE文件？

• 官方提供的文档是否准确，是否还有其他组件没有在列表上？

• 作为端点安全厂商，是否可以在不注册AMSI provider的情况下，使用AMSI服务？

0x01 枚举AMSI组件

为了解决前面两个问题，我们需要找到能够自动发现AMSI组件的方法。这里我们的思路是寻找文件中包含amsi.dll这个ASCII或者Unicode字符串的EXE或者DLL文件。那么为什么要搜索amsi.dll这个字符串？原因有如下两点：

• amsi.dll用来提供扫描缓冲区所需的导出函数：AmsiScanBuffer、AmsiScanString以及AmsiUacScan；

• 如果包含这个字符串，则代表EXE或者DLL会通过静态导入（将其作为ASCII字符串存储在PE中）或者在运行时动态导入（将其作为Unicode字符串存储在PE中）的方式来加载amsi.dll。

我们可以通过如下PowerShell命令寻找相关结果：

$UserPEs = Get-CimInstance -ClassName CIM_DataFile -Filter 'Drive = "C:" and (Extension = "exe" or Extension = "dll")' -Property 'Name' | Select -ExpandProperty Name $AMSIReferences1 = $UserPEs | % { Select-String -Encoding ascii -LiteralPath $_ -Pattern 'amsi\.dll' } $AMSIReferences2 = $UserPEs | % { Select-String -Encoding unicode -LiteralPath $_ -Pattern 'amsi\.dll' } $AMSIReferences1.Path $AMSIReferences2.Path

如上PowerShell代码使用WMI来枚举所有EXE以及DLL。之所以不使用Get-ChildItem，是因为这个cmdlet在尝试访问无法访问的文件时，可能会抛出异常结束运行。接下来，代码会使用Select-String（PowerShell版的grep）扫描每个文件，（以正则表达式）判断是否存在ASCII或者Unicode的amsi.dll字符串。

梳理结果，我们找到了如下AMSI组件：

%windir%\System32\consent.exe%windir%\System32\jscript.dll%windir%\System32\vbscript.dll%windir%\System32\wbem\fastprox.dll%windir%\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll%windir%\Microsoft.NET\Framework64\v4.0.30319\clr.dll%ProgramFiles%\WindowsApps\Microsoft.Office.Desktop_16051.11929.20300.0_x86__8wekyb3d8bbwe\VFS\ProgramFilesCommonX86\Microsoft Shared\VBA\VBA7.1\VBE7.DLL

经过一番调查研究后，我们根据微软的文档把这些AMSI组件分为如下几类：

• UAC：consent.exe

• PowerShell：System.Management.Automation.dll

• JavaScript以及VBScript：jscript.dll及vbscript.dll

• Office VBA宏：VBE7.dll

• 未归类：clr.dll、fastprox.dll

在未归类的AMSI组件中，clr.dll是通用语言运行时（Common Language Runtime），微软的确提到过从.NET 4.8开始，Windows会扫描加载至内存的assembly。目前已经有一些研究人员研究过如何绕过这种机制，大家可以参考如下资料：

• g_amsiContext corruption PoC

• How Red Teams Bypass AMSI and WLDP for .NET Dynamic Code

• .NET AMSI component hooking

• Donut v0.9.1 “Apple Fritter” — Dual-Mode Shellcode, AMSI, and More

还有一个是fastprox.dll，下面我们将对这个dll进行分析。

0x02 针对WMI的AMSI

由于fastprox.dll位于System32\wbem目录中，且该文件的描述为“WMI Custom Marshaller”，因此该文件与WMI密切相关。为了进一步验证这一点，我们可以使用PowerShell来确定哪个进程加载了fastprox.dll：

> Get-Process | Where-Object { $_.Modules.ModuleName -contains 'fastprox.dll' } Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName ------- ------ ----- ----- ------ -- -- ----------- 2196 274 219988 232044 14,573.92 1192 5 chrome 1162 47 85544 38524 803.86 14580 5 mmc 692 42 129920 55564 1,081.20 2408 5 powershell 874 47 77144 87852 73.48 4040 5 powershell 686 39 71132 42608 42.78 12620 5 powershell 229 13 2596 10072 0.13 2956 0 svchost 480 20 3840 6728 69.66 3376 0 svchost 613 34 26776 17356 4,370.64 3648 0 svchost 217 43 2572 4148 18.64 6728 0 svchost 564 33 11276 16544 4.34 11520 0 svchost 129 7 1496 2196 0.77 5232 0 unsecapp 1650 67 318004 256536 99.28 16576 5 vmconnect 898 29 62664 23660 1,267.36 4776 0 vmms 386 16 8492 13408 21.77 14220 0 WmiPrvSE 176 10 2684 8592 1.36 15772 0 WmiPrvSE

我们可以使用如下一行PowerShell命令，将svchost.exe进程解析到对应的服务：

> Get-Process | Where-Object { $_.Modules.ModuleName -contains 'fastprox.dll' -and $_.ProcessName -eq 'svchost' } | ForEach-Object { Get-CimInstance -ClassName Win32_Service -Filter "ProcessId = $($_.Id)" } | Format-Table -AutoSize ProcessId Name StartMode State Status ExitCode --------- ---- --------- ----- ------ -------- 2956 Netman Manual Running OK 0 3376 iphlpsvc Auto Running OK 0 3648 Winmgmt Auto Running OK 0 6728 SharedAccess Manual Running OK 0 11520 BITS Auto Running OK 0

根据输出结果，如果任何进程想与WMI交互，似乎都需要使用这个DLL。现在我们可以直接观察代码，了解fastprox.dll如何与amsi.dll交互。

我只在JAmsi::JAmsiInitialize中找到了对amsi.dll的引用，相关的反汇编代码如下所示：

首先，只有当前进程不是%windir%\System32\wbem\wmiprvse.exe时，该函数才会初始化AMSI。我认为代码想通过这种方式减少没必要的处理逻辑，主要捕捉远程WMI操作，然而我不知道这种猜测是否准确。

接下来代码会调用LoadLibrary加载amsi.dll，解析所需的相关导出函数，比如AmsiScanBuffer。对AmsiScanBuffer的唯一一处交叉引用位于JAmsi::JAmsiRunScanner函数中：

JAmsiRunScanner由JAmsi::JAmsiProcessor调用，而如下函数会调用JAmsiProcessor：

CWbemSvcWrapper::XWbemServices::ExecNotificationQueryAsync CWbemSvcWrapper::XWbemServices::CreateInstanceEnum CWbemSvcWrapper::XWbemServices::ExecQueryAsync CWbemSvcWrapper::XWbemServices::ExecQuery CWbemSvcWrapper::XWbemServices::CreateInstanceEnumAsync CWbemSvcWrapper::XWbemServices::GetObjectW CWbemSvcWrapper::XWbemServices::ExecMethod CWbemSvcWrapper::XWbemServices::ExecMethodAsync CWbemSvcWrapper::XWbemServices::ExecNotificationQuery CWbemSvcWrapper::XWbemServices::GetObjectAsync JAmsi::JAmsiProcessor（由CWbemInstance::SetPropValue调用）

除了最后一个函数，其他都对应IWbemServices接口中实现的方法。最后一个函数很可能对应的是IWbemClassObject::Put方法。

现在我们需要澄清端点安全产品可能获取哪些WMI事件。我在之前关于ETW的一篇文章中介绍了如何使用AmsiScanBuffer将所有事件记录到Microsoft-Antimalware-Scan-Interface provider中。使用AmsiScanBuffer进行检测有一个优点，那就是可以跟踪调用AmsiScanBuffer的任何进程所对应的AMSI缓冲区。如果大家想进一步了解ETW机制以及跟踪技术，可以详细参考那篇文章。这里我们可以使用logman来捕捉所有AMSI事件，获取相关的WMI事件：

logman start trace AMSITrace -p Microsoft-Antimalware-Scan-Interface (Event1) -o amsi.etl -ets

开始跟踪后，我们可以与WMI交互，看一下是否生成了一些事件。我使用了如下测试命令：

$CimSession = New-CimSession -ComputerName . Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{CommandLine = 'notepad.exe'} -CimSession $CIMSession $CIMSession | Remove-CimSession

这条命令中，我创建了一个本地CIM会话，用来模拟远程WMI连接。在这个过程中，我注意避免在wmiprvse.exe上下文中跟踪，前面提到过，该进程会被排除在AMSI处理过程之外。

完成与WMI的交互后，使用如下命令停止跟踪：

logman stop AMSITrace -ets

然后我使用PowerShell来查找WMI事件，的确发现了一个结果：

> $AMSIEvents = Get-WinEvent -Path .\amsi.etl -Oldest > $AMSIEvents[5] | Format-List * Message : AmsiScanBuffer Id : 1101 Version : 0 Qualifiers : Level : 4 Task : 0 Opcode : 0 Keywords : -9223372036854775807 RecordId : 5 ProviderName : Microsoft-Antimalware-Scan-Interface ProviderId : 2a576b87-09a7-520e-c21a-4942f0271d67 LogName : ProcessId : 7184 ThreadId : 8708 MachineName : COMPY486 UserId : TimeCreated : 10/3/2019 12:14:51 PM ActivityId : 95823c06-72e6-0000-a133-8395e672d501 RelatedActivityId : ContainerLog : c:\users\testuser\desktop\amsi.etl MatchedQueryIds : {} Bookmark : System.Diagnostics.Eventing.Reader.EventBookmark LevelDisplayName : Information OpcodeDisplayName : Info TaskDisplayName : KeywordsDisplayNames : {} Properties : {System.Diagnostics.Eventing.Reader.EventProperty, System.Diagnostics.Eventing.Reader.EventProperty...} > $AMSIEvents[5].Properties Value ----- 0 1 1 WMI 300 300 {67, 0, 73, 0...} {131, 136, 119, 209...} False > [Text.Encoding]::Unicode.GetString($AMSIEvents[5].Properties[7].Value) CIM_RegisteredSpecification.CreateInstanceEnum(); Win32_Process.GetObjectAsync(); Win32_Process.GetObject(); SetPropValue.CommandLine("notepad.exe"); > Get-CimInstance -ClassName Win32_Service -Filter "ProcessId = $($AMSIEvents[5].ProcessId)" ProcessId Name StartMode State Status ExitCode --------- ---- --------- ----- ------ -------- 7184 WinRM Auto Running OK 0

那么现在我们如何理解目前搜集到的所有信息呢？首先，解析跟踪到的每个事件后，我们发现第6个事件（索引值为5）是唯一一个在第4个Properties属性中包含WMI的事件。此外，第8个Properties值包含一段二进制数据，这些数据看上去由Unicode字符串所构成。解码字符串后，该字符串对应的是我在前面执行的Win32_Process Create操作。这里我们还需要注意AMSI事件来源的进程ID：7184，对应的是svchost.exe进程。使用Win32_Service WMI类来解析对应的服务，可以发现实际进程对应的是WinRM服务。这一点非常正常，因为CIM cmdlet基于WSMan，而后者是WimRM服务所使用的协议。

作为防御方及端点安全厂商，我们可以将这种上下文信息纳入可疑的WMI操作。现在WMI服务的应用范围非常广泛，系统会在许多合法操作中用到WMI，这种场景会不会影响对AMSI缓冲区的其他使用场景呢？经过测试后，我发现我显式执行的许多WMI操作并没有被记录下来。经过一些逆向分析后，我找到了背后的原因：只有当JAmsi::JAmsiIsScannerNeeded返回True时，系统才会调用JAmsi::JAmsiRunScanner：

简单分析JAmsi::JAmsiIsScannerNeeded的实现后，我发现系统会计算WMI操作对应的上下文字符串的CRC校验和，只有当校验和满足如下白名单值时才会记录这些操作：

在本文撰写时，白名单中的CRC值包括：0x788C9917、0x96B23E8A、0xB8DA804E、0xC0B29B3D、0xD16F4088、0xD61D2EA7、0xEF726924、0x46B9D093以及0xF837EFC3。

我没有专门针对这些校验和进行暴力破解，但考虑到系统会记录下Win32_Process Create操作，因此我们可以推测这些校验和对应的是常见的WMI攻击行为。我们可以将计算这些字符串的校验和当成一种安全机制，vbscript.dll以及jscrit.dll中也会计算这些校验和。

通过这部分的分析，我们发现微软一直在向安全厂商以及防御方提供更多安全信息，拓宽安全视角。一旦找到了白名单对应的值，我相信这种安全机制就很容易被绕过。安全攻防领域从来没有万灵膏药，这也是我们往正确方向迈出的重要一步。

大家可能还有个问题：如何解释Get-WinEvent返回事件中的Properties字段值？下文我们将详细介绍解决该问题的方法。

0x03 解析AMSI事件中的字段名

如果想将事件字段名称与.ETL日志关联起来，最简单的一种方法就是将日志文件载入Event Viewer，该应用会将跟踪记录转换为EVTX文件，在后台解析出AMSI ETW provider对应的manifest信息，并将字段名对应地附加到生成的.evtx文件中。比如，我们可以在“Details”窗口中看到如下信息：

此外，我们还可以使用perfview.exe，将ETW provider信息恢复成XML格式。恢复出来的字段名顺序对应Get-WinEvent返回的Properties值顺序。

根据对AmsiScanBuffer有限的逆向分析结果，Event ID 1101（AMSI扫描事件）中相应的字段描述如下所示：

• session：会话标识符。如果通过AmsiOpenSession来建立AMSI扫描会话，就会出现该字段。字段值通过调用IAmsiStream::GetAttribute（指定AMSI_ATTRIBUTE_SESSION参数）来获取。如果出现了这个字段，我们可以通过该值关联来自同一会话的多次扫描。比如，如果攻击者执行了经过混淆的PowerShell脚本，那么从理论上讲，与该操作相关的所有脚本块（scriptblock）都会使用相同的会话标识符。

• scanStatus：这似乎是个boolean值，我没见过除1之外的其他值，没有进一步调查。

• scanResult：这是端点产品扫描完缓冲区后返回的AMSI_RESULT值。在这里1对应的是AMSI_RESULT_NOT_DETECTED。

• appname：通过AmsiInitialize appName参数传递的应用程序名。对于fastprox.dll，appName对应的是硬编码的WMI。

• contentname：如果扫描的内容源自于文件，那么这个字段就包含完整的文件路径。

• contentsize：如果内容被过滤，那么该字段代表的是过滤后的内容大小，会比originalsize值小。在实际测试中，我没有看到被过滤后的内容。

• originalsize：未过滤内容的大小。我们可以通过调用IAmsiStream::GetAttribute方法（指定AMSI_ATTRIBUTE_CONTENT_SIZE参数）来获取这个值。

• content：被扫描的payload对应的原始字节。根据组件的实现方式，该字段可能对应Uincode字符串或者raw字节。比如，对于clr.dll，该字段值为加载到内存中需要扫描的assembly对应的完整PE。

• hash：被扫描缓冲区对应的SHA256哈希。

• contentFiltered：代表内容是否被截断（truncated）/过滤（filtered）。在本文撰写时，AmsiScanBuffer将这个字段设置为false，目前我没有找到将该值设为true的代码逻辑。

0x04 总结

本文的目标是介绍能够识别AMSI组件的一种方法，分析这些组件的实现方式（以WMI组件为例），并从AMSI ETW事件中进一步挖掘信息。攻击者可以使用这种方法来规避AMSI检测机制，防御方也能借鉴这种方法来解析ETW事件。目前我们尚不清楚微软是否会正式公布AMSI所有组件的文档，但根据本文分析，微软一直在改进AMSI，完善系统安全性。

在后续研究中，我会将AMSI ETW跟踪功能加入我的恶意软件分析工具中，该功能可以帮我们捕捉被高度混淆的恶意软件样本所使用的脚本、WMI以及.NET assembly。