如何识别并分析反恶意软件扫描接口AMSI组件

魁首哥

作者

如何识别并分析反恶意软件扫描接口AMSI组件

这篇文章将为大家详细讲解有关如何识别并分析反恶意软件扫描接口AMSI组件，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

AMSI为终端安全供应商提供了丰富的接口以帮助他们更好地对目标组件进行内存缓冲区安全扫描，或选择需要扫描的内容。根据微软提供的信息，AMSI支持的组件有如下几种：

1、用户账户控制（UAC）
2、PowerShell（脚本、交互使用和动态代码计算）
3、Windows脚本主机（wscript.exe和cscript.exe）
4、JavaScript和VBScript
5、Office VBA宏

针对从事安全防御检测的工程师和防御者，以及对成熟规避技术感兴趣的攻击端研究人员，我给大家提出了以下几个问题：

1、AMSI所支持的这些组件跟哪些实际的PE文件有关联？
2、微软提供的信息是否准确，或者说上面的列表缺少了哪些组件？
3、是否可以在不需要注册AMSI程序作为终端安全提供商的情况下，使用AMSI呢？

AMSI组件枚举

为了解决前两个问题，我们需要想办法自动识别和发现AMSI组件。整个过程需要涉及到一系列包含了ASCII或Unicode字符串“amsi.dll”的EXE或DLL文件。那么我们为什么要搜索“amsi.dll”字符串呢？

1、amsi.dll可以提供扫描缓冲区所需的函数，即AmsiScanBuffer、AmsiScanString和AmsiUacScan。
2、这个字符串意味着EXE或DLL会通过静态导入（比如说，它能够以ASCII字符串的形式存储在PE文件中）或在运行时动态加载（比如说，它能够以Unicode字符串的形式存储在PE文件中）amsi.dll。

下面这段PowerShell代码也许可以回答我们的疑问：

$UserPEs=Get-CimInstance-ClassNameCIM_DataFile-Filter'Drive="C:"and(Extension="exe"orExtension="dll")'-Property'Name'|Select-ExpandPropertyName$AMSIReferences1=$UserPEs|%{Select-String-Encodingascii-LiteralPath$_-Pattern'amsi\.dll'}$AMSIReferences2=$UserPEs|%{Select-String-Encodingunicode-LiteralPath$_-Pattern'amsi\.dll'}$AMSIReferences1.Path$AMSIReferences2.Path

上面这段PowerShell代码段使用了WMI来枚举所有的EXE和DLL。之所以选择这种方法，而不选择Get-ChildItem，是因为它在尝试访问其无权访问的文件时，有可能引发异常。

接下来，它会使用Select-String（相当于PowerShell中的grep）来扫描每个文件，并查找文件中的ASCII和Unicode文本字符串-“amsi.dll”。

对结果进行过滤后，找到了下列AMSI组件：

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

通过研究之后，我们按照微软提供的文档对上述的AMSI组件进行分类：

1、用户账户控制：consent.exe
2、PowerShell：System.Management.Automation.dll
3、JavaScript和VBScript：jscript.dll, vbscript.dll
4、Office VBA宏：VBE7.dll
5、未分类：clr.dll, fastprox.dll

那这些未分类的AMSI组件是什么呢？clr.dll，即常见语言运行时，微软在.NET 4.8提到过这个组件，它的作用是扫描内存中的编译加载。目前，已经有研究人员在研究相关的绕过机制了，参考资料见本文末尾。接下来我们会对fastprox.dll进行分析，大家莫急。

WMI与AMSI

fastprox.dll位于System32\wbem目录内，并且fastprox.dll的描述为“WMI自定义Marshaller”，不言而喻，它很明显与WMI有关。为了进一步验证，我们可以使用PowerShell来识别fastprox.dll的加载跟哪一个进程有关：

>Get-Process|Where-Object{$_.Modules.ModuleName-contains'fastprox.dll'}HandlesNPM(K)PM(K)WS(K)CPU(s)IdSIProcessName--------------------------------------------219627421998823204414,573.9211925chrome1162478554438524803.86145805mmc69242129920555641,081.2024085powershell87447771448785273.4840405powershell68639711324260842.78126205powershell229132596100720.1329560svchost480203840672869.6633760svchost6133426776173564,370.6436480svchost217432572414818.6467280svchost5643311276165444.34115200svchost1297149621960.7752320unsecapp16506731800425653699.28165765vmconnect8982962664236601,267.3647760vmms3861684921340821.77142200WmiPrvSE17610268485921.36157720WmiPrvSE

我们可以使用下列PowerShell命令来解析svchost.exe进程对应的服务：

>Get-Process|Where-Object{$_.Modules.ModuleName-contains'fastprox.dll'-and$_.ProcessName-eq'svchost'}|ForEach-Object{Get-CimInstance-ClassNameWin32_Service-Filter"ProcessId=$($_.Id)"}|Format-Table-AutoSizeProcessIdNameStartModeStateStatusExitCode-----------------------------------------2956NetmanManualRunningOK03376iphlpsvcAutoRunningOK03648WinmgmtAutoRunningOK06728SharedAccessManualRunningOK011520BITSAutoRunningOK0

由此看来，似乎任何希望与WMI交互的进程都需要用到这个DLL。现在，我们直接查看代码来确定fastprox.dll如何与amsi.dll交互。目前，唯一的“amsi.dll”引用出现在JAmsi::JAmsiInitialize函数中，下面是相关代码：

首先，只有在当前进程不是%windir%\System32\wbem\wmiprvse.exe时，该函数才会初始化AMSI。通过对amsi.dll中loadlibrary的调用以及所需的相关导出函数（如amsiscanbuffer）进行解析后，我们发现amsiscanbuffer的唯一交叉引用是JAmsi::JAmsiRunScanner函数：

JAmsiRunScanner由JAmsi::JAmsiProcessor调用，而这个函数会有下列函数进行调用：

1、CWbemSvcWrapper::XWbemServices::ExecNotificationQueryAsync2、CWbemSvcWrapper::XWbemServices::CreateInstanceEnum3、CWbemSvcWrapper::XWbemServices::ExecQueryAsync4、CWbemSvcWrapper::XWbemServices::ExecQuery5、CWbemSvcWrapper::XWbemServices::CreateInstanceEnumAsync6、CWbemSvcWrapper::XWbemServices::GetObjectW7、CWbemSvcWrapper::XWbemServices::ExecMethod8、CWbemSvcWrapper::XWbemServices::ExecMethodAsync9、CWbemSvcWrapper::XWbemServices::ExecNotificationQuery10、CWbemSvcWrapper::XWbemServices::GetObjectAsync11、JAmsi::JAmsiProcessor(calledbyCWbemInstance::SetPropValue)

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

接下来，我们需要运行logman来捕捉所有的AMSI事件，并尝试捕获相关的WMI事件：

logmanstarttraceAMSITrace-pMicrosoft-Antimalware-Scan-Interface(Event1)-oamsi.etl-ets

接下来，运行下列代码进行事件触发测试：

$CimSession=New-CimSession-ComputerName.Invoke-CimMethod-ClassNameWin32_Process-MethodNameCreate-Arguments@{CommandLine='notepad.exe'}-CimSession$CIMSession$CIMSession|Remove-CimSession

上述命令可以创建一个本地CIM会话来枚举远程WMI连接，完成WMI交互之后，停止事件捕捉：

logmanstopAMSITrace-ets

接下来，使用PowerShell来识别任意WMI事件：

>$AMSIEvents=Get-WinEvent-Path.\amsi.etl-Oldest>$AMSIEvents[5]|Format-List*Message:AmsiScanBufferId:1101Version:0Qualifiers:Level:4Task:0Opcode:0Keywords:-9223372036854775807RecordId:5ProviderName:Microsoft-Antimalware-Scan-InterfaceProviderId:2a576b87-09a7-520e-c21a-4942f0271d67LogName:ProcessId:7184ThreadId:8708MachineName:COMPY486UserId:TimeCreated:10/3/201912:14:51PMActivityId:95823c06-72e6-0000-a133-8395e672d501RelatedActivityId:ContainerLog:c:\users\testuser\desktop\amsi.etlMatchedQueryIds:{}Bookmark:System.Diagnostics.Eventing.Reader.EventBookmarkLevelDisplayName:InformationOpcodeDisplayName:InfoTaskDisplayName:KeywordsDisplayNames:{}Properties:{System.Diagnostics.Eventing.Reader.EventProperty,System.Diagnostics.Eventing.Reader.EventProperty...}>$AMSIEvents[5].PropertiesValue-----011WMI300300{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-ClassNameWin32_Service-Filter"ProcessId=$($AMSIEvents[5].ProcessId)"ProcessIdNameStartModeStateStatusExitCode-----------------------------------------7184WinRMAutoRunningOK0

首先，第六个事件（索引5）是唯一的第四个属性值中包含“wmi”的事件。另外，第八个属性值包含了看起来像由Unicode字符串组成的二进制数据。解码后，它反映了上面示例中win32_process create的执行。值得注意的是，记录的进程ID-7184是AMSI事件的来源，它是一个svchost.exe进程。

WMI非常的“混乱”，操作系统会定期使用WMI进行合法操作，而可疑的操作同样会涉及到WMI，而且很多WMI操作都不会被记录。背后的原因很明显，就是因为只有当JAmsi::JAmsiIsScannerNeeded返回TRUE时，JAmsi::JAmsiRunScanner才会执行。