如需 Windows Antimalware 掃描介面 （AMSI） 的簡介，請參閱 反惡意代碼掃描介面 （AMSI）。
身為應用程式開發人員，您可以積极參與惡意代碼防禦。 具體而言，您可以協助保護客戶免於動態腳本型惡意代碼，以及防範非傳統網路攻擊途徑。
透過範例，假設您的應用程式可編寫腳本：它接受任意腳本，並透過腳本引擎執行。 當文稿準備好提供給腳本引擎時，您的應用程式可以呼叫 Windows AMSI API 來要求掃描內容。 如此一來，您就可以在決定繼續執行腳本之前，安全地判斷腳本是否為惡意。
即使腳本是在執行期間產生，也是如此。 腳本（惡意或其他），可能會經歷數次模糊化。 最終您需要提供腳本引擎清晰明瞭且未混淆的程式碼。 這就是您開始使用 AMSI API 的時機。
以下是AMSI架構的圖例，其中您自己的應用程式是由其中一個[其他應用程式]方塊表示。
Windows AMSI 介面已開啟。 這表示任何應用程式都可以呼叫它;和任何已註冊的反惡意代碼引擎都可以處理提交給它的內容。
我們也不需要將討論限制在腳本引擎上。 也許您的應用程式是一款通訊應用，它會在將即時訊息顯示給客戶之前，先掃描這些訊息是否有病毒。 或者，您的軟體可能是在安裝外掛程式之前先驗證外掛程式的遊戲。 使用AMSI有很多機會和案例。
AMSI 運作中
讓我們看看AMSI運作情形。 在此範例中，Windows Defender 是呼叫 AMSI API 的應用程式。 但您可以從自己的應用程式內呼叫相同的 API。
以下是一個使用 XOR 編碼技術來隱藏其意圖（無論該意圖是良性還是惡意）的腳本範例。 在此圖例中，我們可以想像此腳本是從因特網下載的。
以Base64範例腳本
為了讓事情變得更有趣，我們可以在命令行手動輸入此腳本，讓沒有任何實際的檔案可監視。 這會反映所謂的「無檔案威脅」。 它不像掃描磁碟上的檔案那麼簡單。 威脅可能是只存在於計算機記憶體中的後門。
以下是在 Windows PowerShell 中執行腳本的結果。 您會看到 Windows Defender 能夠在此複雜的情境中偵測到 AMSI 測試範例，只是藉由使用標準的 AMSI 測試範例簽章。
AMSI 與 JavaScript/VBA 整合
以下說明的工作流程說明另一個範例的端對端流程，在此範例中，我們示範 AMSI 與 Microsoft Office 內巨集執行的整合。
- 使用者會收到包含 （惡意） 巨集的檔，該巨集會採用模糊化、受密碼保護的檔案或其他技術，以逃避靜態防病毒軟體掃描。
- 用戶然後會開啟含有惡意巨集的文件。 如果檔在 [受保護的檢視] 中開啟，則使用者按兩下 [啟用編輯] 以結束 [受保護的檢視]。
- 用戶按一下 [啟用巨集] 以允許巨集執行。
- 當巨集執行時，VBA 執行環境會使用循環緩衝區來記錄與 Win32、COM 和 VBA API 函數呼叫相關的數據及其參數。
- 當觀察到被視為高風險的特定 Win32 或 COM API（也稱為 觸發器）時，就會停止巨集執行，並將環形緩衝區的內容傳遞至 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 腳本中的等效內容。
在 Visual Basic 腳本中，
這兩個範例變得更糟的是，防毒引擎會檢查使用者正在開啟的檔案。 如果惡意內容只存在於記憶體中，則攻擊可能會無法偵測到。
本節顯示使用傳統簽章偵測的限制。 但是，雖然惡意腳本可能會經過數次反混淆，但最終需要向腳本引擎提供一般、未混淆的代碼。 此時，如上一節所述，Windows 的內建腳本主機會呼叫 AMSI API 來要求掃描此未受保護的內容。 您的應用程式可以執行相同的動作。