如何識別并分析反惡意軟件掃描接口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 -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，是因為它在嘗試訪問其無權訪問的文件時，有可能引發異常。

接下來，它會使用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' }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 -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交互的進程都需要用到這個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 (called by CWbemInstance::SetPropValue)

除了最后一個函數，其他的函數都對對應了IWbemServices接口所實現的方法，而最后一個函數很可能對應的是IWbemClassObject::Put方法。

接下來，我們需要運行logman來捕捉所有的AMSI事件，并嘗試捕獲相關的WMI事件：

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

接下來，運行下列代碼進行事件觸發測試：

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

上述命令可以創建一個本地CIM會話來枚舉遠程WMI連接，完成WMI交互之后，停止事件捕捉：

logman stop AMSITrace -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/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

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

WMI非常的“混亂”，操作系統會定期使用WMI進行合法操作，而可疑的操作同樣會涉及到WMI，而且很多WMI操作都不會被記錄。背后的原因很明顯，就是因為只有當JAmsi::JAmsiIsScannerNeeded返回TRUE時，JAmsi::JAmsiRunScanner才會執行。

WMI的操作上下文字符串有一個專門計算的CRC校驗和，只有它們的校驗和與白名單中的值匹配時才會記錄WMI事件：

研究過程中，我們發現白名單中包含下列CRC校驗和：

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

很明顯，只要攻擊者能夠恢復出白名單中的校驗和，他們就可以繞過操作系統針對WMI操作的記錄，接下來的結果，想必大家心知肚明了吧！

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