反惡意軟件掃描接口(AMSI)如何幫助您防御惡意軟件

有關Windows防惡意軟件掃描接口（Antimalware Scan Interface，AMSI）的介紹，請參閱Antimalware Scan Interface (AMSI)。

作為應用程序開發人員，您可以積極參與惡意軟件防御。具體而言，您可以幫助保護您的客戶免受基于動態腳本的惡意軟件和非傳統網絡攻擊的威脅。

舉個例子，假設您的應用程序支持腳本化：它接受任意腳本，并通過腳本引擎執行。在準備將腳本提供給腳本引擎執行時，您的應用程序可以調用Windows AMSI API來請求對內容進行掃描。這樣，您可以在決定是否執行腳本之前，安全地確定腳本是否是惡意的。

即使腳本是在運行時生成的，這一點仍然適用。腳本（無論是惡意的還是其他類型的）可能經過多次解混淆的過程。但最終，您需要向腳本引擎提供明文、未混淆的代碼。這就是您調用AMSI API的時機。

下面是AMSI架構的示例，其中您自己的應用程序被表示為其中一個“Other Application”框。

Windows的AMSI接口是開放的，這意味著任何應用程序都可以調用它，任何注冊的防惡意軟件引擎都可以處理提交給它的內容。

我們不需要將討論局限于腳本引擎。也許您的應用程序是一款通信應用程序，在向客戶顯示即時消息之前會對其進行病毒掃描。或者您的軟件是一款游戲，在安裝插件之前會對其進行驗證。使用AMSI有很多機會和場景可供使用。

AMSI應用

讓我們來看看AMSI的實際運行情況。在這個例子中，Windows Defender是調用AMSI API的應用程序。但您也可以從自己的應用程序中調用相同的API。

下面是一個使用異或編碼技術隱藏意圖的腳本示例（無論這個意圖是良性的還是惡意的）。為了說明，我們可以假設這個腳本是從互聯網上下載的。

為了增加趣味性，我們可以在命令行中手動輸入這個腳本，這樣就沒有實際的文件可供監視。這反映了所謂的“無文件威脅”。這不像簡單地掃描磁盤上的文件那樣簡單。這種威脅可能是一種僅存在于計算機內存中的后門。

下面是在Windows PowerShell中運行該腳本的結果。您將看到，僅通過使用標準的AMSI測試樣本簽名，Windows Defender就能夠在這種復雜的情況下檢測到AMSI測試樣本。

下面的示例描述了另一個示例的端到端流程，其中我們展示了AMSI與Microsoft Office中宏執行的集成。

◆用戶收到一個包含（惡意）宏的文檔，該宏通過使用混淆、密碼保護文件或其他技術來規避靜態防病毒軟件的掃描。

◆然后，用戶打開包含（惡意）宏的文檔。如果文檔在受保護視圖中打開，則用戶點擊“啟用編輯”以退出受保護視圖。

◆用戶點擊“啟用宏”以允許宏運行。

◆當宏運行時，VBA運行時使用循環緩沖區來記錄與調用Win32、COM和VBA API相關的數據和參數。

◆當觀察到特定的被認為是高風險的Win32或COM API（也稱為觸發器）[2]時，宏執行被停止，并且循環緩沖區的內容被傳遞給AMSI。

◆注冊的AMSI反惡意軟件服務提供商會回復一個判決，以指示宏行為是否惡意。

◆如果行為是非惡意的，則宏繼續執行。

◆否則，如果行為是惡意的，則Microsoft Office會響應警報[3]并關閉會話，而防病毒軟件可以對文件進行隔離處理。

對于Windows用戶來說，任何使用混淆和規避技術的惡意軟件都會在Windows 10內置的腳本宿主中被自動進行比以往更深入的檢查，提供額外的保護層級。

作為應用程序開發人員，如果您希望從（并保護您的客戶免受）潛在惡意內容的額外掃描和分析中受益，請考慮讓您的應用程序調用Windows AMSI接口。

作為防病毒軟件供應商，您可以考慮實現對AMSI接口的支持。這樣做可以讓您的引擎對應用程序（包括Windows 10內置的腳本宿主）認為可能是惡意的數據有更深入的了解。

您可能對Windows AMSI旨在幫助您防御的無文件威脅類型的更多背景信息感興趣。在本節中，我們將看一下在惡意軟件生態系統中所發生的傳統貓鼠游戲。

我們將以PowerShell為例。但是，您可以利用我們將演示的相同技術和流程來處理任何動態語言，比如VBScript、Perl、Python、Ruby等。

這是一個惡意的PowerShell腳本示例。

雖然這個腳本只是在屏幕上顯示一條消息，但惡意軟件通常更加惡毒。但是，您可以輕松編寫一個簽名來檢測這個腳本。例如，該簽名可以在用戶打開的任何文件中搜索字符串"Write-Host 'pwnd!'"。太好了，我們已經檢測到了我們的第一個惡意軟件！

然而，在被我們的第一個簽名檢測到之后，惡意軟件的作者會做出回應。他們會創建像這個示例一樣的動態腳本來應對檢測。

在這種情況下，惡意軟件作者創建一個表示要運行的PowerShell腳本的字符串。但是，他們使用簡單的字符串連接技術來破解我們之前的簽名。如果您查看一個充滿廣告的網頁的源代碼，您會看到許多這種技術的實例，用于避開廣告攔截軟件。

最后，惡意軟件作者將這個連接后的字符串傳遞給Invoke-Expression命令，這是PowerShell在運行時評估組合或創建的腳本的機制。

作為回應，反惡意軟件軟件開始進行基本的語言仿真。例如，如果我們看到兩個字符串被連接起來，那么我們會模擬這兩個字符串的連接，然后在結果上運行我們的簽名。不幸的是，這種方法相當脆弱，因為語言往往有許多表示和連接字符串的方式。

因此，在被這個簽名捕捉到之后，惡意軟件作者會采用更復雜的方法，例如在下面的示例中將腳本內容進行Base64編碼。

為了應對這種情況，大多數反惡意軟件引擎也實現了Base64解碼仿真。因此，既然我們也實現了Base64解碼仿真，我們在一段時間內領先一步。

作為回應，惡意軟件作者會采用算法混淆，例如在他們運行的腳本中使用簡單的異或編碼機制。

到了這個階段，我們通常已經超過了反病毒引擎所能仿真或檢測的范圍，所以我們不一定能檢測到這個腳本在做什么。然而，我們可以開始編寫針對混淆和編碼技術的簽名。實際上，這是針對基于腳本的惡意軟件的絕大多數簽名的原因。

但是，如果混淆器非常簡單，看起來像許多行為良好的腳本怎么辦？對它進行簽名將產生不可接受的大量誤報。這是一個樣本分階段腳本，單獨來看它是無害的，無法被檢測出來。

在這個示例中，我們正在下載一個網頁，并調用其中的一些內容。以下是Visual Basic腳本中的等效代碼示例。

這兩個示例中更糟糕的是，反病毒引擎檢查用戶打開的文件。如果惡意內容僅存在于內存中，那么攻擊有可能不被檢測到。

本節展示了使用傳統簽名進行檢測的局限性。但是，雖然惡意腳本可能經歷了多次解混淆的過程，但最終它需要向腳本引擎提供明文、未混淆的代碼。在這一點上，正如我們在上面的第一節中所描述的那樣，Windows 10內置的腳本宿主調用AMSI API請求掃描這些未受保護的內容。您的應用程序也可以做同樣的事情。