如何理解反惡意軟件掃描接口對抗學習

這篇文章主要介紹“如何理解反惡意軟件掃描接口對抗學習”，在日常操作中，相信很多人在如何理解反惡意軟件掃描接口對抗學習問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何理解反惡意軟件掃描接口對抗學習”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

我們可以知道Windows防病毒掃描界面(AMSI)是一個通用的接口標準，是開放給防病毒產品調用的一個接口。
這個接口支持允許不單單可以用來掃描腳本、代碼、命令或者cmdlet，也可以用來掃描任何文件、內存或者數據流，如字符串、即時消息、圖像或者視頻等等

我認為這個Amsi（Antimalware Scan Interface）主要是針對腳本來說的，目前來說腳本逐漸成為針對性攻擊的武器，諸如JavaScript，VBScript和PowerShell之類的腳本為我們攻擊提供了巨大的好處。它們是系統合法的軟件，并且執行文件不落地在內存中加載。

腳本語言比exe等等Pe文件要好混淆，可以從遠端或注冊表加載執行，并且腳本的動態特性允許攻我們容易地逃避反惡意軟件和類似的端點防護產品的檢測與分析。并且執行文件可以不落地直接在內存中加載。

那么 Windows 10可以通過反惡意軟件掃描接口（AMSI）提供查殺腳本的功能，還可以以腳本解釋程序的相同方式查看腳本內容 ，這樣的話就可以未加密和未混淆的形式來查看我們的攻擊腳本。

目前在微軟的文檔中我們可以知道
AMSI功能已集成到Windows 10的這些組件中。

用戶帳戶控制或UAC（EXE，COM，MSI或ActiveX）
PowerShell（腳本，交互使用和動態代碼評估）
Windows腳本主機（wscript.exe和cscript.exe）
JavaScript和VBScript
Office VBA宏

Amsi（Antimalware Scan Interface）的工作流程。

As an application developer, you can actively participate in malware

1. Specifically, you can help protect your customers from

2. script-based malware, and from non-traditional avenues of

cyberattack.

By way of an example, let's say that your application is scriptable:
it accepts arbitrary script, and executes it via a scripting engine.
At the point when a script is ready to be supplied to the scripting
engine, your application can call the Windows AMSI APIs to request a
scan of the content. That way, you can safely determine whether or not
the script is malicious before you decide to go ahead and execute it.

This is true even if the script was generated at runtime. Script
(malicious or otherwise), might go through several passes of
de-obfuscation. But you ultimately need to supply the scripting engine
with plain, un-obfuscated code. And that's the point at which you
invoke the AMSI APIs.

從微軟的文檔中我們可以看到Amsi中的工作流程。
如果有一個應用程序接受任意腳本，并通過腳本引擎執行該腳本。
那么殺毒軟件可以調用amsi來查殺腳本。
可能有同學有疑問：殺毒軟件不是也能不靠amsi查殺腳本嗎？不不不 amsi的意義在于：無論我們的惡意腳本是經過多次模糊處理還是遠程執行amsi都可以在腳本注入內存前檢測到。而普通的靜態殺毒軟件是沒辦法的。

我們可以看微軟文檔給出的工作流程圖來理解：

其實不難理解，首先我們要知道我們的惡意腳本是如何注入內存執行的
bypass 殺毒軟件時我們的腳本一定是模糊處理的，但是無論我們什么樣模糊處理到注入內存執行的時候一定是純凈，清晰的代碼，不然腳本引擎無法理解和執行我們的惡意腳本。
那么問題就是在這里，amsi在腳本解密到注入內存之前去掃描查殺。這才是調用amsi的意義。

我們可以調用powershell來執行我們的惡意代碼來更好理解Amsi

AMSI的一個簡單測試是在PowerShell提示符–中鍵入AMSI旁路中常用的字符串amsiutils。如果端點安全產品支持AMSI，并且檢測到該字符串，那么PowerShell提示符將顯示錯誤，表明輸入的命令是惡意的。

PS C:\Users\（123223Li）> amsiutils
所在位置 行:1 字符: 1
+ amsiutils
+ ~~~~~~~~~
此腳本包含惡意內容，已被你的防病毒軟件阻止。
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : ScriptContainedMaliciousContent

很好Amsi查殺并阻止了power shell執行命令。
我們來處理一下amsiutils，比如我們常用的base64加密和XOR編碼技術。

$bytes = [convert]::FromBase64String('YW1zaXV0aWxz') # YW1zaXV0aWxz為amsiutils的base64編碼
$string = -join ($bytes | % {[char] ($_ -bxor 0x33)}) #進行XOR編碼
iex $string #執行命令

然后我們使用powershell ISE 執行來模擬我們在實戰中的無文件落地直接內存加載執行的手法

毫不意外，amsi檢測到并攔截了powershell去執行我們的腳本。

我們可以使用下面命令來查看amsi中的查殺結果

Get-WinEvent 'microssoft-windows-windows defender/operational' | Where-Object id -EQ 1116 | format-list

當然amsi也可以檢測vba和Java script
在實戰中，使用宏攻擊（釣魚）也是我們常用的手法，所以我們要知道amsi對宏文件的檢測流程

在微軟文檔中我們可以看到

The user receives a document containing a (malicious) macro, which
evades static antivirus software scans by employing techniques such as
obfuscation, password-protected files, or other. The user then opens
the document containing the (malicious) macro. If the document opens
in Protected View, then the user clicks Enable Editing to exit
Protected View. The user clicks Enable Macros to allow macros to run.
As the macro runs, the VBA runtime uses a circular buffer to log [1]
data and parameters related to calls to Win32, COM, and VBA APIs. When
specific Win32 or COM APIs that are considered high risk (also known
as triggers) [2] are observed, macro execution is halted, and the
contents of the circular buffer are passed to AMSI. The registered
AMSI anti-malware service provider responds with a verdict to indicate
whether or not the macro behavior is malicious. If the behavior is
non-malicious, then macro execution proceeds. Otherwise, if the
behavior is malicious, then Microsoft Office closes the session in
response to the alert [3], and the AV can quarantine the file.

微軟文檔中也給出了一個流程圖

通過閱讀理解微軟文檔我們可以知道amsi對宏的檢測查殺流程：

1.word等等釣魚文件加載宏
2.VBA宏運行時,運行時會有一個循環的緩沖區中記錄數據和參數調用Win32,COM, VBA等等api的情況。
3.amsi監控著緩沖區中的情況，一旦我們的宏調用了一些敏感的API或一些敏感的數據交互，就會觸發amsi的觸發器。
4.amsi停止宏執行并從循環緩沖區取出內容傳遞。
5.amsi從循環緩沖區取出內容傳遞給殺毒軟件。
6.殺毒軟件拿到數據后判斷宏是否為惡意的。
6.如果行為是無惡意的,那么宏可以執行。否則,關閉宏會話并發出響應警報和處理惡意文件。

我們可以看一個例子來理解amsi檢測查殺vba的流程：
跟powershell一樣我們也使用遠程加載powershell惡意代碼。這樣更貼近實戰。

1.使用cobat Strike生成我們的惡意代碼

2.使用宏遠程加載我們的惡意代碼

#使用宏調用powershell遠程加載ps1
 Sub AutoOpen()
        Call Shell("powershell -Sta -Nop -Window Hidden -EncodedCommand shell")
End Sub

在沒有開amsi的情況下可以執行上線!

在開了amsi的情況下無法執行了

amsi是所有殺毒軟件都可以調用嗎？并不是！

amsi是在Windows 10 和Windows Server 2016 之后才有的，然后并不是所有的殺毒軟件都可以調用amsi接口。國內的基本不可以哈哈哈。

在github上有一個項目記錄了可以調用amsi的殺毒軟件

https://github.com/subat0mik/whoamsi/wiki/Which-Endpoint-Protection-is-Using-AMSI%3F

殺軟對抗是一個動態對抗的過程，殺毒有新技術，免殺就有新手法。只有熟透殺軟才能更好免殺。

amsi解決的是遠程加載執行惡意腳本無文件落地的攻擊手法，過兩天看看跟大家學習一下bypass AMsi的手法。

我們學習了Antimalware Scan Interface（AMSI）的一些知識。作為滲透測試的我們了解殺軟是為了更好地進行免殺。

在對抗殺毒軟件的手法中，在大層面來說：

一就是破壞殺毒軟件，使其無法正常運行；
二是繞過殺毒軟件，使其無法檢測到。

從小的層面來說：

靜態免殺
動態免殺
沙盒對抗
等等

前面我們說到AMSI是windows開放的一個接口，注冊的殺毒軟件可以通過調用amsi接口來完成監控查殺。
既然是接口，那么我們是不是可以使殺毒軟件無法調用這個amsi接口來bypass？

首先我們得知道殺毒軟件是如何調用amsi的：

在微軟文檔中給出了2種調用amsi接口的方法

There are two ways in which you can interface with AMSI in your application.

By using the AMSI Win32 APIs. By using the AMSI COM interfaces.

分別是：
1.通過使用AMSI Win32 API

Functions that your application can call to request a scan. AMSI provides the following functions. 
#函數,應用程序可以通過調用amsi，amsi提供以下函數

Function #函數    Description #功能
AmsiCloseSession    Close a session that was opened by AmsiOpenSession.#關閉打開的會話
AmsiInitialize    Initialize the AMSI API.#初始化AMSI API。
AmsiOpenSession    Opens a session within which multiple scan requests can be correlated.#打開一個會話中關聯多個掃描請求。
AmsiResultIsMalware    Determines if the result of a scan indicates that the content should be blocked.#    確定掃描的結果表明,內容應該是屏蔽
AmsiScanBuffer    Scans a buffer-full of content for malware. #    掃描惡意軟件的緩沖區已滿的內容。
AmsiScanString    Scans a string for malware.#惡意軟件掃描一個字符串。
AmsiUninitialize    Remove the instance of the AMSI API that was originally opened by AmsiInitialize.#刪除的實例AMSI API,

其中每個函數的調用方法有興趣可以去微軟種查看。

https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-functions

2.通過使用AMSI COM接口

這個中調用的是IAmsiStream接口(amsi.h)代表一個流被掃描，微軟文檔中給出了示例，

https://docs.microsoft.com/en-us/windows/win32/api/amsi/nf-amsi-iamsistream-getattribute

Inheritance The IAmsiStream interface inherits from the IUnknown
interface. IAmsiStream also has these types of members:
 
Methods Methods The IAmsiStream interface has these methods.
 
METHODS Method    Description IAmsiStream::GetAttribute    Returns a
requested attribute from the stream. IAmsiStream::Read    Requests a
buffer-full of content to be read. Requirements REQUIREMENTS
            Minimum supported client    Windows 10 [desktop apps only] 
          Minimum supported server    Windows Server 2016 [desktop apps only] Target
Platform    Windows Header    amsi.h

然后上面我們知道了如何調用amsi，但是調用amsi還要注冊才能調用,所以我們也得看看amsi是如何注冊的:

As a creator of antimalware products, you can choose to author and
register your own in-process COM server (a DLL) to function as an AMSI

1. That AMSI provider must implement the IAntimalwareProvider
   interface, and it must run in-process.

Note that, after Windows 10, version 1709 (the Fall 2017 Creators'
Update), your AMSI provider DLL may not work if it depends upon other
DLLs in its path to be loaded at the same time. To prevent DLL
hijacking, we recommend that your provider DLL load its dependencies
explicitly (with a full path) using secure LoadLibrary calls, or equivalent.
We recommend this instead of relying on the LoadLibrary search behavior.

The section below shows how to register your AMSI provider. For full
sample code showing how to author your own AMSI provider DLL, see the
IAntimalwareProvider interface sample application.

Register your provider DLL with AMSI To begin with, you need to ensure
that these Windows Registry keys exist.

HKLMSOFTWAREMicrosoftAMSIProviders HKLMSOFTWAREClassesCLSID An
AMSI provider is an in-process COM server. Consequently, it needs to
register itself with COM. COM classes are registered in
HKLMSOFTWAREClassesCLSID.

當然在微軟文檔中也給出了示例，但是我們是要做免殺，理解一些必要的東西就行。
在微軟的文檔中我們可以知道

Note that, after Windows 10, version 1709 (the Fall 2017 Creators'
Update), your AMSI provider DLL may not work if it depends upon other
DLLs in its path to be loaded at the same time. To prevent DLL
hijacking, we recommend that your provider DLL load its dependencies
explicitly (with a full path) using secure LoadLibrary calls, orequivalent.
We recommend this instead of relying on the LoadLibrarysearch behavior.search behavior.

微軟中說：

也就是說存在dll劫持的例子。我們復現一下歷史上的amsi.dll劫持吧。

劫持amsi.dll bypass amsi復現

我們以powershell為例子吧：
我們在學習了上面的基礎之后我們可以知道powershell中調用amsi的過程

當打開一個PowerShell時,poweershell會從磁盤把AMSI.DLL加載到powershell的地址空間。
然后會調用AMSI.DLL中函數AmsiScanBuffer()的功能用來掃描腳本的內容。
PowerShell中任何提供的腳本內容會先被送到AmsiScanBuffer()檢測查殺后再執行。
隨后,AmsiScanBuffer()將與注冊殺毒檢查,確定是否創建了簽名。
如果內容被認為是惡意的,它將被處理

我們可以知道powershell是加載amsi.dll的，那么這里就存在一個可劫持點。就是劫持amsi.dll來bypass amsi

DLL(Dynamic Link
Library)文件為動態鏈接庫文件，又稱"應用程序拓展"，是軟件文件類型。在Windows中，許多應用程序并不是一個完整的可執行文件，它們被分割成一些相對獨立的動態鏈接庫，即DLL文件，放置于系統中。當我們執行某一個程序時，相應的DLL文件就會被調用。一個應用程序可使用多個DLL文件，一個DLL文件也可能被不同的應用程序使用，這樣的DLL文件被稱為共享DLL文件。

如果在進程嘗試加載一個DLL時沒有指定DLL的絕對路徑，那么Windows會嘗試去按照順序搜索這些特定目錄時下查找這個DLL,只要黑客能夠將惡意的DLL放在優先于正常DLL所在的目錄，就能夠欺騙系統優先加載惡意DLL，來實現"劫持"

dll的劫持需要滿足兩個條件（這里指win7以上的版本）

1.目標DLL沒有在HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerKnownDLLs注冊表中

凡是此項下的DLL文件就會被禁止從exe自身所在的目錄下調用，而只能從系統目錄即SYSTEM32目錄下調用

dll沒有在KnownDLLs注冊表中就會以下順序加載

1. 進程對應的應用程序所在目錄（可理解為程序安裝目錄比如C:\ProgramFiles\uTorrent）
2. 系統目錄（即%windir%system32）；
3. 16位系統目錄（即%windir%system）；
4. Windows目錄（即%windir%）；
5. 當前目錄（運行的某個文件所在目錄，比如C:\Documents and Settings\Administrator\Desktop\test）；
6. PATH環境變量中的各個目錄

2.目標文件目錄或者我們需要寫進dll的目標我們具有可寫權限

默認情況下，如果軟件安裝在c盤根目錄，而不是c:\Program Files，那經過身份驗證的用戶具有該目錄的寫權限，另外，perl，python，ruby等軟件通常都添加到path變量中。那攻擊者可以在當前目錄中編寫惡意DLL，只要重新運行exe程序就會中招。

ok我們知道powershell是amsi.dll來監控查殺腳本的，我們可以使用Process Mointor來監控powershell進程在運行中執行了那些API調用，打開/創建了注冊表項，加載了DLL等。

設置process中的過濾器規則來查看只有powershell.exe的進程。

應用規則，我們可以看到只有powershell.exe進程的所有調用情況。

太多事件了，我們可以加一條規則來查看在powershell中僅僅是調用amsi.dll的事件。

查看ProcMon的輸出，我們發現了第一個可能的DLL劫持。

我們直接跳轉過去文件的路徑中

可以看到路徑中并沒有amsi.dll，那么我們可以寫入一個惡意的amsi.dll進去。這里使用cobalt strike生成的惡意dll來演示，當然這個dll我們也進行了免殺處理。

把生成的惡意dll更改名字為amsi.dll后拉進我們上面的文件路徑中

然后打開powershell 可以看到powershell中出錯了，然后Cobalt strike上線了（打開powershell直接上線）。但是沒關系，一般在實戰中我們會處理我們的惡意dll來同時實現目標dll的功能和執行我們的惡意函數來上線的，這里不多說。

在powershell加載amsi.dll過程中還存在一個劫持點，就是：

C:\Windows\System32\WindowsPowerShell\v1.0

有興趣的同學可以自行了解下

破壞amsi.dll bypass Asmi

國外有個老哥寫了個腳本直接破壞amsi來執行命令。
在復現他的手法時我們要知道powershell與amsi.dll之間的一些知識：
amsi.dll會為每一個powershell.exe進程加載一個amsi.dll.

然后因為那個老哥的github上的ps1不在了，我修改下然后上傳到我的GitHub上去了，方便以后使用。

https://github.com/dnsil/bypassAsmi

使用手法不難，直接加載執行就行。

但是windwos defender已經報毒，自行處理一下就好

然后這里還要注意一個點,打開一個powershell.exe加載一個amsi.dll
不同的powershell.exe都有自己的amsi.dll守護，然后上面的腳本只會破壞在運行時powershell.exe進程的amsi.dll，如果再打開一個powershell的話還是會加載amsi.dll。

我們可以看一個例子：

powershell ISE中是執行了腳本的，可以看到成功執行“amsiscanbuffer”，而在powershell.exe中就不可以，提示amsi查殺了。

呃呃呃呃，我們看看在powershel ISE中的情況吧

哈哈哈，還是嚴謹一點好

其它的話，大家可以自行測試。

二是繞過amsi

AMSI使用“基于字符串”的檢測措施來確定PowerShell代碼是否為惡意代碼。

例子：“amsicanbuffer”

可以看到“amsicanbuffer”觸發了amsi，amsi監控查殺了。

我們都知道，字符串檢測（特征碼）非常容易繞開，只是不要從字面上使用禁止的字符串。使用編碼或將其拆分為多個塊，然后重新組合可以繞過。那么我們看看能不能繞過amsi監控

PS C:\Users\（123223Li）> $a = "amsis"
PS C:\Users\（123223Li）> $b = "canbuffer"
PS C:\Users\（123223Li）> $c = $a + $b
PS C:\Users\（123223Li）> $c

定義一個變量a 賦值“amsis” 定義一個變量b 賦值“canbuffer”
然后定義一個變量c 賦值為a+b 那么c = a+b = "amsis" + "canbuffer" = amsiscanbuffer
然后直接執行變量c ok 我們來看看能不能繞過amsi吧

哈哈哈哈
我認為行的

果不其然，當然這個不能表示什么，因為一個惡意腳本遠不止幾個特征碼，從定位到修改最后到免殺才是真正的難點，這里變量的轉換是一個繞過點

我們來看下一種常見手法，字符串分割：amsicanbuffer

PS C:\Users\（123223Li）> "amsican" + "buffer"
amsicanbuffer

也是可以繞過的

上面是繞過的，下面是沒有繞過的，對比一下。

我們來看第3種的常見繞過手法base64編碼

我們base64編碼一下：

然后在使用powershell來解碼base64并執行。這里為大家好理解，我把命令一步一步來執行

PS C:\Users\（123223Li）> $a = [Convert]::FromBase64String("YW1zaXNjYW5idWZmZXI=") //解碼base64
PS C:\Users\（123223Li）> $b = [Text.encoding]::UTF8.GetString($a) //Utf-8轉換
PS C:\Users\（123223Li）> $b //執行$b
amsiscanbuffer

也是可以繞過amsi的

這里要注意，[Convert]::FromBase64String("YW1zaXNjYW5idWZmZXI=") 解碼出來powershell是不能識別的所以我們要轉換一下

這里說一句題外話，我們可以看看Cobalt strike中的powershell的木馬

可以看到也是經過base64編碼的，但是為什么不免殺？單字符免殺不難，但是一個惡意腳本遠不止幾個特征碼，從定位到修改最后到免殺才是真正的難點，當然這里并沒有考慮動態，沙盒這些東西。

字符串的免殺的還要10進制編碼，16進制編碼，hex編碼，加密，ox等等手法，也可以多個手法反復使用等等這里就不一一演示，免殺是一個動態對抗的過程。

加油，同路人

給你們看看靜態全0的ps1，免殺手法也是基于上面說的。

到此，關于“如何理解反惡意軟件掃描接口對抗學習”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！