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

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

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

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

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

基于簽名的檢測(cè)

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

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

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

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

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

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

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

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

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

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

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

基于掛鉤的Win32 API檢測(cè)可以通過(guò)取消掛鉤或直接/間接使用Syscall來(lái)繞過(guò)。

基于熵的檢測(cè)將檢測(cè)到許多封隔器，因?yàn)橛行ж?fù)載的加密將由于隨機(jī)性而導(dǎo)致非常高的熵。這可以通過(guò)在生成的二進(jìn)制中添加數(shù)千個(gè)單詞來(lái)繞過(guò)，因?yàn)檫@再次降低了熵。

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

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

2.行為檢測(cè)；

3.攻擊者。

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

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

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

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

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

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

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

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

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

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

內(nèi)存加密。

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

繞過(guò)基于行為的內(nèi)存掃描是比較困難的，這取決于你的有效負(fù)載的行為。試想一下Mimikatz的行為（例如，用OpenProcess打開(kāi)LSASS的句柄）會(huì)觸發(fā)一次掃描，此時(shí)，無(wú)法從內(nèi)存中隱藏Mimikat，因?yàn)樗枰M(jìn)行加密才能工作。因此，Mimikatz不會(huì)選擇內(nèi)存加密。

對(duì)于像Cobalt Strike這樣著名的C2框架，最常見(jiàn)的選擇是內(nèi)存加密。但是如果你沒(méi)有訪問(wèn)源代碼的權(quán)限，就不可能修改它以避免內(nèi)存檢測(cè)。一般來(lái)說(shuō)，C2框架是這項(xiàng)技術(shù)的優(yōu)先選擇，因?yàn)樗鼈兇蟛糠謺r(shí)間都處于休眠狀態(tài)。如果一個(gè)程序什么也不做，它的內(nèi)存內(nèi)容可以在這個(gè)時(shí)間段內(nèi)被加密，而不會(huì)出現(xiàn)任何問(wèn)題。

基于行為檢測(cè)的一些示例和繞過(guò)

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

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

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

Fodhelper UAC繞過(guò)示例

基于行為的檢測(cè)的一個(gè)很好的示例是帶有Windows Defender的Fodhelper UAC繞過(guò)。這個(gè)方法非常流行，但也很容易被利用，因?yàn)樗恍枰獎(jiǎng)?chuàng)建一個(gè)注冊(cè)表項(xiàng)，然后調(diào)用fodhelper.exe：

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

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

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

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

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

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

基于Meterpreter行為的檢測(cè)

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

我不會(huì)在本文介紹執(zhí)行Shellcode的方式，因?yàn)槲抑幌胝故拘袨闄z測(cè)，但通常您需要以下內(nèi)容：

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

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

在這種情況下，無(wú)需修補(bǔ)AMSI/ETW即可使Meterpreter運(yùn)行。

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

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

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

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

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

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

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

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

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

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

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

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

注意：這是繞過(guò)Meterpeter防御行為檢測(cè)的唯一可能方法。

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

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

Cobalt Strike檢測(cè)

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

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

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

1.禁用Malleable配置文件中的分段，如果啟用了該功能，你的植入程序幾乎會(huì)立即被終止，因?yàn)橛性S多Internet范圍內(nèi)的自動(dòng)掃描器下載第二階段來(lái)分析和共享它。

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

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

植入程序的最低要求：

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

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

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

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

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

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

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

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

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

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

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

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

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

真的需要這些繞過(guò)技巧嗎？

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

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

如果你正在使用內(nèi)部工具或經(jīng)過(guò)大量修改的開(kāi)放源代碼，AMSI將永遠(yuǎn)不會(huì)發(fā)現(xiàn)你，因?yàn)樗谒阉饕阎暮灻?/p>

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

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