反惡意代碼掃描介面 （AMSI） 如何協助您抵禦惡意代碼
如需 Windows Antimalware 掃描介面 （AMSI） 的簡介，請參閱 反惡意代碼掃描介面 （AMSI） 。
身為應用程式開發人員，您可以積极參與惡意代碼防禦。 具體而言，您可以協助保護客戶免於動態腳本型惡意代碼，以及防範非傳統網路攻擊途徑。
透過範例，假設您的應用程式可編寫腳本：它接受任意腳本，並透過腳本引擎執行。 當文稿準備好提供給腳本引擎時，您的應用程式可以呼叫 Windows AMSI API 來要求掃描內容。 如此一來，您就可以在決定繼續執行腳本之前，安全地判斷腳本是否為惡意。
即使腳本是在運行時間產生，也是如此。 腳本（惡意或其他），可能會經歷數次模糊化。 但您最終需要提供腳本引擎，並提供一般、未混淆的程序代碼。 這就是您叫用AMSI API的點。
以下是AMSI架構的圖例，其中您自己的應用程式是由其中一個[其他應用程式]方塊表示。
Windows AMSI 介面已開啟。 這表示任何應用程式都可以呼叫它;和任何已註冊的反惡意代碼引擎都可以處理提交給它的內容。
我們也不需要將討論限制在腳本引擎上。 也許您的應用程式是通訊應用程式，它會先掃描立即訊息是否有病毒，再向您的客戶顯示病毒。 或者，您的軟體可能是在安裝外掛程式之前先驗證外掛程式的遊戲。 使用AMSI有很多機會和案例。
AMSI 運作中
讓我們看看AMSI運作情形。 在此範例中，Windows Defender 是呼叫 AMSI API 的應用程式。 但您可以從自己的應用程式內呼叫相同的 API。
以下是使用 XOR 編碼技術隱藏其意圖的腳本範例（該意圖是否良性）。 在此圖例中，我們可以想像此腳本是從因特網下載的。
為了讓事情變得更有趣，我們可以在命令行手動輸入此腳本，讓沒有任何實際的檔案可監視。 這會反映所謂的「無檔案威脅」。 它不像掃描磁碟上的檔案那麼簡單。 威脅可能是只存在於計算機記憶體中的後門。
以下是在 Windows PowerShell 中執行腳本的結果。 您會看到 Windows Defender 能夠在此複雜案例中偵測 AMSI 測試範例，只是使用標準 AMSI 測試範例簽章。
AMSI 與 JavaScript/VBA 整合
以下說明的工作流程說明另一個範例的端對端流程，在此範例中，我們示範 AMSI 與 Microsoft Office 內宏執行的整合。
- 使用者會收到包含 （惡意） 宏的檔，該宏會採用模糊化、受密碼保護的檔案或其他技術，以逃避靜態防病毒軟體掃描。
- 然後，用戶會開啟包含 （惡意） 宏的檔。 如果檔在受保護的檢視中開啟，則使用者按兩下 [啟用編輯 ] 以結束受保護的檢視。
- 用戶按兩下 [啟用宏 ] 以允許宏執行。
- 當宏執行時，VBA 運行時間會使用迴圈緩衝區來記錄與 Win32、COM 和 VBA API 呼叫相關的 [1] 數據和參數。
- 當觀察到被視為高風險的特定 Win32 或 COM API [2] 時，宏執行會停止，並將迴圈緩衝區的內容傳遞至 AMSI。
- 已註冊的 AMSI 反惡意代碼服務提供者會回應判決，以指出宏行為是否為惡意。
- 如果行為非惡意，則會繼續執行宏。
- 否則，如果行為是惡意的，則 Microsoft Office 會關閉工作階段以回應警示 [3]，而 AV 可以隔離檔案。
對您來說這代表什麼？
對於 Windows 使用者，任何在 Windows 內建腳本主機上使用混淆和逃避技術的惡意軟體，都會在比以往更深入的層級自動檢查，以提供額外的保護層級。
身為應用程式開發人員，如果您想要從潛在惡意內容的額外掃描和分析中獲益，請考慮讓應用程式呼叫 Windows AMSI 介面。
身為防病毒軟體廠商，您可以考慮實作AMSI介面的支援。 當您這麼做時，您的引擎將更深入地了解應用程式（包括 Windows 的內建腳本主機）視為潛在的惡意數據。
關於無檔案威脅的更多背景資訊
您可能對 Windows AMSI 設計來協助您防禦的無檔案威脅類型有更多背景資訊感到好奇。 在本節中，我們將探討在惡意代碼生態系統中播放的傳統貓鼠遊戲。
我們將使用PowerShell作為範例。 但是，您可以運用我們將會使用任何動態語言來示範的相同技術和程式：VBScript、Perl、Python、Ruby 等等。
以下是惡意 PowerShell 腳本的範例。
雖然此腳本只會將訊息寫入畫面，但惡意代碼通常比較惡意。 但是，您可以輕鬆地撰寫簽章來偵測此簽章。 例如，簽章可以在用戶開啟的任何檔案中搜尋字串 「Write-Host』pwnd！』」。 很好：我們偵測到我們的第一個惡意代碼！
不過，在第一個簽章偵測到之後，惡意代碼作者將會回應。 他們會藉由建立例如此範例的動態腳本來回應。
在該案例中，惡意代碼作者會建立代表要執行的 PowerShell 腳本的字串。 但是他們會使用簡單的字串串連技術來中斷我們先前的簽章。 如果您曾經檢視過廣告載入網頁的來源，您會看到許多此技術實例用來避免廣告封鎖軟體。
最後，惡意代碼作者會將此串連字串傳遞至 Invoke-Expression Cmdlet—PowerShell 的機制，以評估在運行時間撰寫或建立的腳本。
作為回應，反惡意代碼軟體會開始執行基本語言模擬。 例如，如果我們看到兩個字串正在串連，則我們會模擬這兩個字元串的串連，然後在結果上執行簽章。 不幸的是，這是一種相當脆弱的方法，因為語言往往有很多方法來表示和串連字元串。
因此，在此簽章攔截之後，惡意代碼作者會移至更複雜的內容，例如，在Base64中編碼腳本內容，如下一個範例所示。
在資源上，大部分的反惡意代碼引擎也會實作Base64譯碼模擬。 因此，由於我們也實作Base64譯碼模擬，因此我們會提前一段時間。
作為回應，惡意代碼作者會移至演算法模糊化，例如他們執行的腳本中的簡單 XOR 編碼機制。
此時，我們通常會超過防病毒軟體引擎會模擬或偵測的內容，因此我們不一定會偵測此腳本正在執行的動作。 不過，我們可以開始針對模糊化和編碼技術撰寫簽章。 事實上，這就是大部分腳本型惡意代碼簽章的考慮。
但是，如果模糊器是如此微不足道，它看起來像許多表現良好的腳本呢？ 其簽章會產生無法接受的誤判數目。 以下是無法自行偵測的範例 分段器 腳本。
在此範例中，我們會下載網頁，並從中叫用一些內容。 以下是 Visual Basic 腳本中的對等專案。
這兩個範例變得更糟的是，防毒引擎會檢查使用者正在開啟的檔案。 如果惡意內容只存在於記憶體中，則攻擊可能會無法偵測到。
本節顯示使用傳統簽章偵測的限制。 但是，雖然惡意腳本可能會經過數次反混淆，但最終需要提供腳本引擎，並提供一般、未混淆的程序代碼。 此時，如上一節所述，Windows 的內建腳本主機會呼叫 AMSI API 來要求掃描此未受保護的內容。 您的應用程式可以執行相同的動作。