如何識(shí)別并分析反惡意軟件掃描接口AMSI組件

這篇文章將為大家詳細(xì)講解有關(guān)如何識(shí)別并分析反惡意軟件掃描接口AMSI組件，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

AMSI為終端安全供應(yīng)商提供了豐富的接口以幫助他們更好地對(duì)目標(biāo)組件進(jìn)行內(nèi)存緩沖區(qū)安全掃描，或選擇需要掃描的內(nèi)容。根據(jù)微軟提供的信息，AMSI支持的組件有如下幾種：

1、用戶賬戶控制（UAC）

2、PowerShell（腳本、交互使用和動(dòng)態(tài)代碼計(jì)算）

3、Windows腳本主機(jī)（wscript.exe和cscript.exe）

4、JavaScript和VBScript

5、Office VBA宏

針對(duì)從事安全防御檢測(cè)的工程師和防御者，以及對(duì)成熟規(guī)避技術(shù)感興趣的攻擊端研究人員，我給大家提出了以下幾個(gè)問題：

1、AMSI所支持的這些組件跟哪些實(shí)際的PE文件有關(guān)聯(lián)？

2、微軟提供的信息是否準(zhǔn)確，或者說上面的列表缺少了哪些組件？

3、是否可以在不需要注冊(cè)AMSI程序作為終端安全提供商的情況下，使用AMSI呢？

AMSI組件枚舉

為了解決前兩個(gè)問題，我們需要想辦法自動(dòng)識(shí)別和發(fā)現(xiàn)AMSI組件。整個(gè)過程需要涉及到一系列包含了ASCII或Unicode字符串“amsi.dll”的EXE或DLL文件。那么我們?yōu)槭裁匆阉鳌癮msi.dll”字符串呢？

1、amsi.dll可以提供掃描緩沖區(qū)所需的函數(shù)，即AmsiScanBuffer、AmsiScanString和AmsiUacScan。

2、這個(gè)字符串意味著EXE或DLL會(huì)通過靜態(tài)導(dǎo)入（比如說，它能夠以ASCII字符串的形式存儲(chǔ)在PE文件中）或在運(yùn)行時(shí)動(dòng)態(tài)加載（比如說，它能夠以Unicode字符串的形式存儲(chǔ)在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，是因?yàn)樗趪L試訪問其無權(quán)訪問的文件時(shí)，有可能引發(fā)異常。

接下來，它會(huì)使用Select-String（相當(dāng)于PowerShell中的grep）來掃描每個(gè)文件，并查找文件中的ASCII和Unicode文本字符串-“amsi.dll”。

對(duì)結(jié)果進(jìn)行過濾后，找到了下列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

通過研究之后，我們按照微軟提供的文檔對(duì)上述的AMSI組件進(jìn)行分類：

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，即常見語言運(yùn)行時(shí)，微軟在.NET 4.8提到過這個(gè)組件，它的作用是掃描內(nèi)存中的編譯加載。目前，已經(jīng)有研究人員在研究相關(guān)的繞過機(jī)制了，參考資料見本文末尾。接下來我們會(huì)對(duì)fastprox.dll進(jìn)行分析，大家莫急。

WMI與AMSI

fastprox.dll位于System32\wbem目錄內(nèi)，并且fastprox.dll的描述為“WMI自定義Marshaller”，不言而喻，它很明顯與WMI有關(guān)。為了進(jìn)一步驗(yàn)證，我們可以使用PowerShell來識(shí)別fastprox.dll的加載跟哪一個(gè)進(jìn)程有關(guān)：

> 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進(jìn)程對(duì)應(yīng)的服務(wù)：

> 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 -AutoSizeProcessId Name         StartMode State   Status ExitCode--------- ----         --------- -----   ------ --------2956      Netman       Manual    Running OK     03376      iphlpsvc     Auto      Running OK     03648      Winmgmt      Auto      Running OK     06728      SharedAccess Manual    Running OK     011520     BITS         Auto      Running OK     0

由此看來，似乎任何希望與WMI交互的進(jìn)程都需要用到這個(gè)DLL?，F(xiàn)在，我們直接查看代碼來確定fastprox.dll如何與amsi.dll交互。目前，唯一的“amsi.dll”引用出現(xiàn)在JAmsi::JAmsiInitialize函數(shù)中，下面是相關(guān)代碼：

首先，只有在當(dāng)前進(jìn)程不是%windir%\System32\wbem\wmiprvse.exe時(shí)，該函數(shù)才會(huì)初始化AMSI。通過對(duì)amsi.dll中l(wèi)oadlibrary的調(diào)用以及所需的相關(guān)導(dǎo)出函數(shù)（如amsiscanbuffer）進(jìn)行解析后，我們發(fā)現(xiàn)amsiscanbuffer的唯一交叉引用是JAmsi::JAmsiRunScanner函數(shù)：

JAmsiRunScanner由JAmsi::JAmsiProcessor調(diào)用，而這個(gè)函數(shù)會(huì)有下列函數(shù)進(jìn)行調(diào)用：

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 (called by CWbemInstance::SetPropValue)

除了最后一個(gè)函數(shù)，其他的函數(shù)都對(duì)對(duì)應(yīng)了IWbemServices接口所實(shí)現(xiàn)的方法，而最后一個(gè)函數(shù)很可能對(duì)應(yīng)的是IWbemClassObject::Put方法。

接下來，我們需要運(yùn)行l(wèi)ogman來捕捉所有的AMSI事件，并嘗試捕獲相關(guān)的WMI事件：

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

接下來，運(yùn)行下列代碼進(jìn)行事件觸發(fā)測(cè)試：

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

上述命令可以創(chuàng)建一個(gè)本地CIM會(huì)話來枚舉遠(yuǎn)程WMI連接，完成WMI交互之后，停止事件捕捉：

logman stop AMSITrace -ets

接下來，使用PowerShell來識(shí)別任意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/2019 12:14:51 PMActivityId           : 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 -ClassName Win32_Service -Filter "ProcessId = $($AMSIEvents[5].ProcessId)"ProcessId Name  StartMode State   Status ExitCode--------- ----  --------- -----   ------ --------7184      WinRM Auto      Running OK     0

首先，第六個(gè)事件（索引5）是唯一的第四個(gè)屬性值中包含“wmi”的事件。另外，第八個(gè)屬性值包含了看起來像由Unicode字符串組成的二進(jìn)制數(shù)據(jù)。解碼后，它反映了上面示例中win32_process create的執(zhí)行。值得注意的是，記錄的進(jìn)程ID-7184是AMSI事件的來源，它是一個(gè)svchost.exe進(jìn)程。

WMI非常的“混亂”，操作系統(tǒng)會(huì)定期使用WMI進(jìn)行合法操作，而可疑的操作同樣會(huì)涉及到WMI，而且很多WMI操作都不會(huì)被記錄。背后的原因很明顯，就是因?yàn)橹挥挟?dāng)JAmsi::JAmsiIsScannerNeeded返回TRUE時(shí)，JAmsi::JAmsiRunScanner才會(huì)執(zhí)行。

WMI的操作上下文字符串有一個(gè)專門計(jì)算的CRC校驗(yàn)和，只有它們的校驗(yàn)和與白名單中的值匹配時(shí)才會(huì)記錄WMI事件：

研究過程中，我們發(fā)現(xiàn)白名單中包含下列CRC校驗(yàn)和：

0x788c9917、0x96b23e8a、0xb8da804e、0xc0b29b3d、0xd16f4088、0xd61d2ea7、0xef726924、0x46b9d093、0xf837efc3

很明顯，只要攻擊者能夠恢復(fù)出白名單中的校驗(yàn)和，他們就可以繞過操作系統(tǒng)針對(duì)WMI操作的記錄，接下來的結(jié)果，想必大家心知肚明了吧！

關(guān)于如何識(shí)別并分析反惡意軟件掃描接口AMSI組件就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。