我們會在本文中介紹基于簽名的檢測和基于行為的檢測之間的主要區(qū)別。此外，還會舉例說明了繞過各個檢測的示例。

經(jīng)常會有人有疑問，為什么在有關(guān)Packer（封隔器）被發(fā)布后，MSF- 或CobaltStrike- (CS)有效負(fù)載仍然會被檢測到。答案無非有兩種：

1.基于簽名的檢測被繞過了；2.基于行為的檢測被觸發(fā)并終止進(jìn)程。

使用我們的自定義封隔器將導(dǎo)致反掃描。被封隔的MSF有效負(fù)載如下：

但這并不意味著，在運行時執(zhí)行時，這些殺毒程序不會檢測到有效負(fù)載。為什么會出現(xiàn)這種情況？

基于簽名的檢測

基于簽名的檢測非常簡單。最早的殺毒程序有一個帶有File-Hashes的簽名數(shù)據(jù)庫，他們只是將磁盤上任何可執(zhí)行文件的哈希與已知的惡意可執(zhí)行程序哈希進(jìn)行比較。例如，該數(shù)據(jù)庫包含Mimikatz發(fā)布二進(jìn)制文件的SHA1/MD5哈希。改變一個可執(zhí)行文件的哈希值就像操縱其中的一個字節(jié)一樣簡單，所以這種檢測并不可靠。

基于這一事實，安全供應(yīng)商轉(zhuǎn)而檢測特定的字節(jié)模式(Byte Pattern)簽名。因此，為了繼續(xù)使用Mimikatz的示例，具體的字節(jié)模式/十六進(jìn)制值被標(biāo)記如下：

可以看到，不僅要為每個已知的惡意二進(jìn)制文件/有效負(fù)載標(biāo)記一個模式，而且要使用多個常見模式。Mimikatz始終是基于簽名的檢測的一個很好的示例，因為通常供應(yīng)商有幾十種Mimikatz二進(jìn)制檢測的模式。通過這種方式，稍微修改過的版本也能被檢測到。

甚至可以使用yara規(guī)則構(gòu)建更高級的檢測。這些規(guī)則可以掃描文件或內(nèi)存內(nèi)容，并允許更復(fù)雜的條件和不同模式的組合。Mimikatz yara規(guī)則的一個示例如下：

在本示例中，如果在文件或內(nèi)存中找到上述三個字符串，則會觸發(fā)此規(guī)則，AV/EDR程序可以執(zhí)行警報或終止進(jìn)程等操作。例如，我們在構(gòu)建自定義Mimikatz二進(jìn)制代碼的文章中描述的技術(shù)就可以繞過這樣的檢測。

封隔器的內(nèi)部工作原理

首先要了解封隔器的基本工作原理，了解它能做什么，不可能做什么。最后利用一個程序?qū)⒁粋€有效負(fù)載封裝到另一個程序中，以避免對其進(jìn)行基于簽名的檢測。因此，如果像Mimikatz這樣的負(fù)載包含特定的字符串，那么這些字符串將在生成的二進(jìn)制文件中不再可見。包裝過程可以通過某種編碼/混淆或加密來完成。我個人更喜歡加密有效負(fù)載，因為這將產(chǎn)生最好的隨機(jī)性，因此基于簽名的檢測最少。

這種經(jīng)過編碼或加密的負(fù)載必須在生成的加載器程序中解碼/解密，以便可以從內(nèi)存中執(zhí)行明文負(fù)載。

根據(jù)有效負(fù)載的不同，封隔器也可以在當(dāng)前進(jìn)程或遠(yuǎn)程進(jìn)程中刪除更多檢測：

如果你的封隔器正在打補丁/繞過AMSI，你可以安全地從內(nèi)存執(zhí)行不同的已知惡意腳本(PS1,VBA,JS等)或c#程序集。

為了繞過基于ETW的檢測，封隔器還可以通過不同的發(fā)布技術(shù)修補/繞過ETW。

基于掛鉤的Win32 API檢測可以通過取消掛鉤或直接/間接使用Syscall來繞過。

基于熵的檢測將檢測到許多封隔器，因為有效負(fù)載的加密將由于隨機(jī)性而導(dǎo)致非常高的熵。這可以通過在生成的二進(jìn)制中添加數(shù)千個單詞來繞過，因為這再次降低了熵。

但是，即使所有這些技術(shù)都得到了應(yīng)用，仍然存在更多潛在的“問題”:

1.內(nèi)存掃描；

2.行為檢測；

3.攻擊者。

一般來說，使用封隔器也可以繞過內(nèi)存掃描，但這非常有限。

內(nèi)存掃描和常用的繞過技術(shù)

由于基于簽名的檢測很容易被封隔器技術(shù)繞過，越來越多的AV/EDR供應(yīng)商傾向于使用掃描進(jìn)行內(nèi)存分析。這些掃描通常不會在所有進(jìn)程中一直進(jìn)行，因為這會消耗太多資源，但可能會由特定條件觸發(fā)。

例如，內(nèi)存掃描通常在以下情況下出現(xiàn)：

生成一個新進(jìn)程，例如運行一個可執(zhí)行文件；

進(jìn)程的行為觸發(fā)內(nèi)存掃描；

第一個很容易繞過。例如，即使是封隔器也可以在解碼/解密真正的有效負(fù)載之前休眠一段時間。在這種情況下，將進(jìn)行內(nèi)存掃描，但不會發(fā)現(xiàn)任何東西，因為負(fù)載仍然是加密的。仍然有方法檢測Win32基于睡眠的內(nèi)存掃描繞過，例如這里演示的。作為使用Sleep的替代方案，你也可以在特定的時間內(nèi)執(zhí)行偽代碼或進(jìn)行計算。除了使用Sleep，還有許多其他替代方法。

但一般來說，繞過內(nèi)存掃描有以下三種方法：

更改/修改有效負(fù)載的源代碼，以避免基于簽名的檢測；

更改有效負(fù)載的行為，以便永遠(yuǎn)不會觸發(fā)內(nèi)存掃描；

內(nèi)存加密。

我個人更喜歡第一種選擇，它在每個程序中都是一次性的，只要新的代碼庫不公開，它也不應(yīng)該在未來被檢測到。

繞過基于行為的內(nèi)存掃描是比較困難的，這取決于你的有效負(fù)載的行為。試想一下Mimikatz的行為（例如，用OpenProcess打開LSASS的句柄）會觸發(fā)一次掃描，此時，無法從內(nèi)存中隱藏Mimikat，因為它需要進(jìn)行加密才能工作。因此，Mimikatz不會選擇內(nèi)存加密。

對于像Cobalt Strike這樣著名的C2框架，最常見的選擇是內(nèi)存加密。但是如果你沒有訪問源代碼的權(quán)限，就不可能修改它以避免內(nèi)存檢測。一般來說，C2框架是這項技術(shù)的優(yōu)先選擇，因為它們大部分時間都處于休眠狀態(tài)。如果一個程序什么也不做，它的內(nèi)存內(nèi)容可以在這個時間段內(nèi)被加密，而不會出現(xiàn)任何問題。

基于行為檢測的一些示例和繞過

但是，哪些行為會在運行時觸發(fā)AV/EDR操作或內(nèi)存掃描呢？基本上全都可以。將內(nèi)容寫入內(nèi)存，以特定的順序或時間框架加載特定的庫，創(chuàng)建注冊表項，執(zhí)行初始HTTP請求或任何其他操作。

我將在這里舉幾個例子，介紹相應(yīng)繞過技術(shù)。

根據(jù)我的個人經(jīng)驗，AV/EDR在檢測到特定行為后極少立即終止進(jìn)程。這是因為AV/EDR供應(yīng)商不希望有太多的誤報結(jié)果。由于誤報結(jié)果與終止進(jìn)程的行為會導(dǎo)致生產(chǎn)環(huán)境的中斷，這是非常糟糕的。所以他們需要幾乎100%的確定，一個行為肯定是惡意程序終止相應(yīng)的進(jìn)程。這也是為什么許多供應(yīng)商將行為檢測與內(nèi)存掃描結(jié)合起來，以驗證他們發(fā)現(xiàn)了惡意內(nèi)容。

Fodhelper UAC繞過示例

基于行為的檢測的一個很好的示例是帶有Windows Defender的Fodhelper UAC繞過。這個方法非常流行，但也很容易被利用，因為它只需要創(chuàng)建一個注冊表項，然后調(diào)用fodhelper.exe：

在啟用殺毒軟件的情況下執(zhí)行此操作將導(dǎo)致以下檢測：

此警報既不會終止正在執(zhí)行的進(jìn)程，也不會終止新生成的進(jìn)程，但仍會導(dǎo)致任何攻擊中的檢測。檢測本身不能繞過AMSI，修補ETW也無濟(jì)于事。因為這是觸發(fā)此警報的特定行為。

我對此處標(biāo)記的內(nèi)容進(jìn)行了一些簡單的試錯分析，發(fā)現(xiàn)殺毒軟件不喜歡HKCU:\Software\Classes\ms-settings\Shell\Open\command(Default) 條目以及目錄*C:\windows\system32*和*C:\windows \syswow64*中的任何.exe。

因此，觸發(fā)警報的行為是使用其中一個字符串在上述目錄中創(chuàng)建注冊表項。

幸運的是，我們不需要指定.exe來執(zhí)行二進(jìn)制文件，也不需要兩個目錄來進(jìn)行攻擊。因此，作為一種替代方案，我們可以直接將e.G. a C2-Stager復(fù)制到任何可寫目錄中，并使用UAC-Bypass執(zhí)行它，而無需調(diào)用擴(kuò)展名。

但到2022年，許多OffSec用戶將意識到，在安裝了AV/EDR的系統(tǒng)上運行任何未簽名的可執(zhí)行文件可能不是一個好主意。因此，作為一種替代方案，我們還可以執(zhí)行任何經(jīng)過簽名的可信可執(zhí)行文件，并將相應(yīng)的Sideloading-DLL放到相同的目錄中。還有第三種選擇，就是我們可以將rundll32.exe復(fù)制到我們的可寫目錄中并在那里執(zhí)行它。

基于Meterpreter行為的檢測

切記，不要使用分段有效負(fù)載，它們會被殺毒軟件捕獲。因此，在我們的示例中，我們將生成用于執(zhí)行的不分段的反向HTTPS Shellcode。這可以通過以下命令來實現(xiàn)：

我不會在本文介紹執(zhí)行Shellcode的方式，因為我只想展示行為檢測，但通常您需要以下內(nèi)容：

對Shellcode進(jìn)行加密并在運行時解密，以避免在磁盤上簽名，或者在運行時從遠(yuǎn)程Web服務(wù)器加載它；

使用直接或間接的系統(tǒng)調(diào)用執(zhí)行，否則Shellcode將在執(zhí)行前被標(biāo)記；

在這種情況下，無需修補AMSI/ETW即可使Meterpreter運行。

但是，即使你使用系統(tǒng)調(diào)用繞過了基于簽名的磁盤檢測和Shellcode檢測，你也應(yīng)該能夠看到一個新的 Meterpreter Session傳入：

但這只是意味著，我們的初始有效負(fù)載成功地執(zhí)行了。一秒鐘后，進(jìn)程被終止并出現(xiàn)以下檢測：

同樣，這是一個基于行為的檢測，由附加的DLL文件觸發(fā)，通過普通Win32 API和反射DLL注入技術(shù)加載。在本例中，stdapi-DLL的注入觸發(fā)了一個警報。

在msfconsole提示符中，你可以通過以下命令禁用stdapi DLL的加載：

這樣，你就應(yīng)該可以很好地接收Meterpreter Session：

然而，禁用stdapi加載將導(dǎo)致你的Meterpreter-Session中幾乎沒有命令/模塊，只有“內(nèi)核命令”可用。

等待幾分鐘后，你可以使用以下命令手動加載stdapi，但仍應(yīng)沒有檢測：

這種基于行為的檢測是關(guān)于什么的？我不能百分之百地肯定，但很可能是以下因素的組合：

1.新生成的進(jìn)程；

2.在調(diào)用用于反射加載DLL的特定Windows API之前，新進(jìn)程的時間框架x；

3.內(nèi)存掃描，用于驗證惡意內(nèi)容；

4.內(nèi)存中Meterpreter的檢測和終止進(jìn)程的操作。

注意：這是繞過Meterpeter防御行為檢測的唯一可能方法。

如上所述，繞過內(nèi)存掃描的一個通用方法是修改源代碼以避免內(nèi)存中的簽名。繞過內(nèi)存掃描的一個通用方法是修改源代碼以避免內(nèi)存中的簽名，因此修改源代碼是另一種選擇，Meterpreter源代碼混淆的自動化方法可以點擊這里。這樣做之后，就能夠在啟用autostdapi-Loading的情況下避免這種檢測。

第三種方法是內(nèi)存加密，這對于Meterpreter來說并不容易實現(xiàn)，因為在請求命令之前，HTTP/HTTPS源代碼不像許多其他c2框架那樣在時間框架x上休眠。它只是拋出許多HTTP(S)請求，其間有一些小延遲。所以內(nèi)存加密會中斷這個過程。如果你使用這個方法，那么你需要在源代碼中自己集成一個帶有內(nèi)存加密的自定義Sleep-function。

Cobalt Strike檢測

Cobalt Strike很可能是最復(fù)雜、分析最深入的C2框架。這很可能是因為在過去幾年里，它被許多不同的攻擊組織在野外使用。不更改默認(rèn)設(shè)置在大多數(shù)環(huán)境中是不可用的，因為這會立即被檢測到。

即使使用自定義的打包器/加載器和系統(tǒng)調(diào)用來執(zhí)行Shellcode，在許多環(huán)境中仍然會失敗。因此，我會解釋作為操作員在使用此框架時需要做的最低要求和修改。

C2服務(wù)器/基礎(chǔ)設(shè)施最低要求：

1.禁用Malleable配置文件中的分段，如果啟用了該功能，你的植入程序幾乎會立即被終止，因為有許多Internet范圍內(nèi)的自動掃描器下載第二階段來分析和共享它。

2.你必須使用帶有許多不同重要繞過設(shè)置的自定義Malleable C2-Profile來繞過一些檢測。

3.必須在C2服務(wù)器前面使用重定向器。此重定向程序應(yīng)釋放/阻止已知的沙盒分析IP范圍，并且僅允許和重定向那些符合Malleable C2配置文件的請求。RedWarden或RedGuard是實現(xiàn)此流程自動化的最佳工具。使用它還可以避免在第一次連接后對Cobalt Strike服務(wù)器進(jìn)行指紋識別和檢測。

植入程序的最低要求：

1.使用加密/混淆和運行時解密/反混淆打包Shellcode。如果你不這樣做，加載器將在磁盤或內(nèi)存中被簽名標(biāo)記（取決于加載方式）；

2.使用直接或間接的系統(tǒng)調(diào)用來執(zhí)行CS-Shellcode或從內(nèi)存加載工件。如果不這樣做，在大多數(shù)環(huán)境中都會導(dǎo)致即時檢測，因為Shellcode始終具有相同的IoC，并且很容易被AV/EDR掛鉤檢測到。

3.使用環(huán)境鍵控（environmental keying）繞過潛在的沙盒或自動EDR云提交分析。

4.你必須通過有關(guān)工具包修改Cobalt Strike中的默認(rèn)睡眠掩碼模板。如果在Malleable C2 Profile中啟用，信標(biāo)將加密堆和堆棧內(nèi)存，以在成功執(zhí)行后從內(nèi)存掃描程序中隱藏自身。但由于這個默認(rèn)的睡眠掩碼源代碼本身也被AV/EDR簽名嚴(yán)重攻擊，因此也會被內(nèi)存掃描器標(biāo)記。你不應(yīng)該使用任何未修改的公共Github睡眠加密代碼，因為這也會被標(biāo)記。

所有這些（除了睡眠掩碼的修改）都可以通過一個完全自定義的打包器/加載器或使用有關(guān)工具包（Arsenal Kit）來完成，Arsenal Kit已經(jīng)提供了很多模板代碼。如果你打算使用Arsenal Kit，那么你必須熟悉C/C++，并對模板代碼進(jìn)行大量自定義，以繞過檢測。

睡眠掩碼的修改也適用于原始的Shellcode輸出，所以當(dāng)你使用自己的自定義加載器時，你甚至可以在Arsenal Kit中對其進(jìn)行修改。不過通過上述修改，Microsoft Defender for Endpoint 在我的測試中仍然檢測到許多惡意行為。

注：即使你應(yīng)用了上述所有要求，你的植入程序仍然可以在成熟環(huán)境中檢測到。根據(jù)目標(biāo)環(huán)境中使用的EDR，這是不夠的。仍然存在一些問題：

如果你收到信標(biāo)連接，別以為你能夠發(fā)現(xiàn)什么。在許多環(huán)境中，我都能夠讓Beacon運行，但在發(fā)出一個命令/模塊后，植入程序立即被檢測到并終止。正如我所說，CS很可能是目前最復(fù)雜的框架，看看這些yara規(guī)則，你會發(fā)現(xiàn)，供應(yīng)商確實為每個命令/模塊實現(xiàn)了檢測規(guī)則。這些基于行為的檢測使我個人只能使用Cobalt Strike啟動反向Socks Connection，而不能避免本地系統(tǒng)IoC，通過Socks在網(wǎng)絡(luò)上完成所有事情。因此，在我的許多項目中，Cobalt Strike或多或少成為了一個獨立的socks5反向代理程序。

對于自動AV/EDR分析，一個簡單的內(nèi)存加密可能就可以了，但在這種情況下，你需要避免更多的IoC，如RWX/RX內(nèi)存權(quán)限，你不能使用Win32 Sleep，因為這很容易被檢測。

在某些環(huán)境中，我的Beacon/Process甚至在回調(diào)之前就被檢測到。說實話，我不知道這些監(jiān)測是干什么的，說實話，我也不知道如何繞過他們。

一些更有經(jīng)驗的Cobalt Strike用戶向我暗示，用戶定義的反射加載器(UDRL)幾乎有無限的可能性，比如TitanLdr。在成熟的環(huán)境中，通過可塑配置文件選項來調(diào)整Cobalt Strike行為是不夠的。例如，內(nèi)核將始終使用Win32 API（具有潛在的檢測功能），而不是直接使用Syscall。直到有人將系統(tǒng)調(diào)用選項與更新集成。但使用UDRL，你還可以使用導(dǎo)入地址表掛鉤修改所有Cobalt Strike 內(nèi)核行為。例如，你可以將內(nèi)核的Hook VirtualProtect設(shè)置為NtProtectVirtualMemory。

因此，由于CS內(nèi)核本身的局限性，它可能是堅持使用UDRL的最隱蔽的方式，而不是使用自定義打包器/加載器或經(jīng)過修改的Arsenal Kit。

對我個人來說，這已經(jīng)不是一個選擇了。掛鉤IAT修改一個閉源程序的內(nèi)核，只是為了繞過基于行為的檢測。在某種程度上，我決定至少在這一刻不會為了讓這個框架的c2連接運行而越來越深入地研究Windows內(nèi)部。在一年的時間里，我只開發(fā)了很少的沒有檢測的環(huán)境和一些有反向Socks代理的環(huán)境，我決定使用其他框架。以前沒有CS我也很好，將來也會很好。

真的需要這些繞過技巧嗎？

我認(rèn)為不需要，所有這些繞過技術(shù)最終只是用來繞過簽名。

如果你使用的是自己生成的Shellcode，你可以選擇再次堅持使用Win32 API。WriteProcessMemory或CreateThread將導(dǎo)致對輸入?yún)?shù)的檢測和對Shellcode入口點的分析。但如果沒有已知的惡意簽名，它將正常運行，不會被阻止。

如果你正在使用內(nèi)部工具或經(jīng)過大量修改的開放源代碼，AMSI將永遠(yuǎn)不會發(fā)現(xiàn)你，因為它正在搜索已知的簽名。

如果你使用的是一個混淆的開源C2框架，或者是一個自己開發(fā)的框架，內(nèi)存掃描不會發(fā)現(xiàn)你。

本文翻譯自：https:s3cur3th1ssh1t.github.io/Signature_vs_Behaviour///