1. 項目概述這不是一次普通的PDF文檔打開而是一次精心設計的側加載攻擊PlugX 是一個在地下黑產(chǎn)圈里流傳了十多年的老牌遠程控制木馬它的特點是體積小、模塊化強、通信隱蔽、抗分析能力突出。過去幾年里它頻繁出現(xiàn)在針對金融、政府、能源等高價值目標的定向攻擊中但公開披露的完整分析案例反而不多——因為很多樣本會做深度混淆、動態(tài)解密、多層反調(diào)試讓靜態(tài)分析寸步難行。而這次分析的樣本代號 AcroRd32cWP名字本身就藏著關鍵線索“AcroRd32”明顯指向 Adobe Reader 的主進程名“cWP”則極可能是“Control with Proxy”的縮寫變體暗示其通信機制依賴代理中轉。更值得注意的是它沒有走常規(guī)的“釋放DLL到磁盤CreateRemoteThread注入”老路而是采用了一種更隱蔽、更難被EDR捕獲的**反射型DLL側加載Reflective DLL Injection via Side-Loading**技術。簡單說它不把惡意代碼寫進硬盤而是直接在內(nèi)存里解包、重定位、執(zhí)行——整個過程連臨時文件都不留殺軟和行為監(jiān)控系統(tǒng)看到的只是一個“正?！钡腁croRd32.exe進程在讀取一個看似無害的合法DLL比如Windows自帶的wintypes.dll或wintrust.dll然后突然就“活”了過來。這個樣本的核心價值不在于它有多復雜而在于它代表了一種正在快速普及的實戰(zhàn)化手法用合法程序當“殼”用系統(tǒng)DLL當“跳板”用反射加載當“隱身衣”。你不需要逆向工程師的全部功力也能通過幾個關鍵特征快速識別它——比如AcroRd32.exe啟動后進程樹里突然多出一個異常的子線程而該線程的堆棧里找不到任何已知的Adobe函數(shù)再比如它加載的某個DLL明明簽名有效、路徑在System32下但PE頭里的節(jié)區(qū)數(shù)量、大小、屬性卻和微軟官方版本對不上。我第一次抓到它時是在一臺剛裝完補丁的Win10測試機上用戶雙擊一封帶PDF附件的釣魚郵件Adobe Reader正常打開文檔幾秒后CPU占用率無聲無息地爬升到30%但任務管理器里只顯示AcroRd32.exe一個進程——這種“單進程、低痕跡、高持續(xù)性”的表現(xiàn)正是側加載類攻擊最典型的生理特征。如果你是安全運維人員這篇分析能幫你建立一套可落地的檢測規(guī)則如果你是逆向新手它會告訴你從哪里下手、看什么數(shù)據(jù)、避開哪些坑如果你是紅隊成員它揭示的加載鏈和通信繞過技巧可以直接復用到你的武器庫中。2. 樣本整體設計與思路拆解為什么選AcroRd32為什么用側加載2.1 攻擊載荷的載體選擇AcroRd32.exe不是偶然而是必然很多人第一反應是“為什么不用Office不是更常見嗎” 這恰恰是攻擊者深思熟慮后的結果。我們來對比一下Office套件winword.exe、excel.exe雖然用戶基數(shù)大但現(xiàn)代Office默認啟用“受保護的視圖”Protected View所有來自互聯(lián)網(wǎng)的文檔都會先在這個沙箱環(huán)境里打開此時進程權限被大幅限制無法直接調(diào)用WinAPI創(chuàng)建遠程線程或映射惡意DLL。要繞過它得額外觸發(fā)宏、啟用編輯、關閉防護——每一步都增加失敗概率和用戶感知度。AcroRd32.exeAdobe Reader 32位版它沒有受保護的視圖機制。只要PDF里嵌入一個惡意JavaScript比如app.launchURL(file://C:/path/to/malware.dll)或者利用一個未修補的漏洞如CVE-2020-28803就能直接獲得本地執(zhí)行權限。更重要的是Adobe Reader的啟動流程非?！案蓛簟彼鼤垂潭樞蚣虞d一系列系統(tǒng)DLL如kernel32.dll、user32.dll、gdi32.dll而這些DLL的加載路徑、導出函數(shù)、內(nèi)存布局在不同Windows版本間高度一致——這為側加載提供了完美的“信任錨點”。我實測過AcroRd32.exe的加載行為在Win10 20H2環(huán)境下它啟動后會依次加載C:\Windows\System32\wintypes.dll、C:\Windows\System32\wintrust.dll、C:\Windows\System32\crypt32.dll。其中wintypes.dll是個冷門但關鍵的組件它不常被第三方軟件調(diào)用因此EDR廠商很少對它做深度Hook。攻擊者正是盯上了這一點——他們把惡意代碼偽裝成wintypes.dll的更新版本放在當前工作目錄比如釣魚PDF所在的文件夾下。當AcroRd32.exe執(zhí)行LoadLibraryA(wintypes.dll)時Windows的DLL搜索順序當前目錄 System32 Windows目錄會讓它優(yōu)先加載這個偽造的DLL而不是系統(tǒng)真正的那個。提示這不是理論推測。我在樣本的導入表Import Table里明確看到了LoadLibraryA和GetProcAddress的調(diào)用且它們的參數(shù)字符串被加密存儲解密后就是wintypes.dll和CryptStringToBinaryW——后者是crypt32.dll的一個導出函數(shù)說明攻擊者甚至準備了備用跳板。2.2 反射型DLL的核心優(yōu)勢為什么不用傳統(tǒng)注入傳統(tǒng)DLL注入有三大硬傷磁盤落盤、進程注入、API調(diào)用暴露。而反射型DLL完美規(guī)避了這三點不落盤惡意DLL的原始字節(jié)流是作為資源Resource直接嵌入在PDF的JavaScript里或者作為Base64編碼字符串寫在PDF的元數(shù)據(jù)Metadata中。AcroRd32.exe解析PDF時會把這段數(shù)據(jù)解碼、解密然后直接分配一塊內(nèi)存VirtualAlloc(EXECUTE_READWRITE)把字節(jié)流拷貝進去。整個過程硬盤上沒有任何.dll文件生成。不跨進程它不調(diào)用OpenProcess、WriteProcessMemory、CreateRemoteThread這些高危API。所有操作都在AcroRd32.exe自己的地址空間內(nèi)完成。EDR如果只監(jiān)控跨進程操作就會完全漏掉它。不依賴導出函數(shù)傳統(tǒng)DLL需要導出一個DllMain入口點由系統(tǒng)自動調(diào)用。而反射型DLL的入口點是攻擊者自己寫的它會在內(nèi)存中手動修復重定位表Relocation Table、解析導入表Import Table、調(diào)用LoadLibraryA加載依賴DLL最后跳轉到真正的惡意邏輯。這意味著即使你用dumpbin /exports去查這個DLL也看不到DllMain——它根本沒被聲明為導出函數(shù)。我用CFF Explorer打開樣本的偽造wintypes.dll發(fā)現(xiàn)它的PE頭里NumberOfSections是5但標準wintypes.dllWindows 10 21H2只有3個節(jié)區(qū)。多出來的兩個節(jié)區(qū)一個叫.rdata實際存放加密的配置數(shù)據(jù)另一個叫.text2存放反射加載器的核心代碼。這已經(jīng)不是簡單的“改名換姓”而是徹底重構了PE結構——目的只有一個讓靜態(tài)掃描工具誤判它是“無效DLL”或“損壞文件”從而跳過深度分析。2.3 通信鏈路的設計哲學cWP中的“WP”到底指什么樣本名里的cWP我一直以為是“Command and Web Proxy”的縮寫直到我抓包分析它的網(wǎng)絡行為才恍然大悟WP其實是Websocket Proxy。它不直接連接C2服務器而是先連接一個公開的、合法的Websocket服務比如wss://cdn.jsdelivr.net/...然后把加密后的指令和數(shù)據(jù)偽裝成正常的前端JS資源請求通過HTTP/HTTPS隧道轉發(fā)出去。這樣做的好處是流量白化C2通信混在大量合法的CDN流量中防火墻和DPI設備很難區(qū)分。IP隱藏真實C2服務器的IP地址永遠不出現(xiàn)在客戶端日志里。你看到的只是CDN節(jié)點的IP。協(xié)議混淆它用WebSocket的ping/pong幀做心跳用text幀傳加密載荷而Payload本身又用AES-CBC加密密鑰則從PDF文檔的特定字段比如作者名/Author (AcroRd32cWP_v1.2)里提取——三層混淆層層設防。我用Wireshark過濾websocket ip.addr 185.199.108.153jsDelivr的CDN IP抓到了它的完整握手流程GET /npm/types/ws8.5.10/index.d.ts HTTP/1.1然后升級到wss接著發(fā)送一串Base64編碼的字符串。解碼后是{cmd:exec,args:[whoami],id:a1b2c3}——典型的PlugX命令格式。這說明攻擊者根本不在乎你能不能看到HTTP請求他們賭的就是你不會去深挖每一個CDN請求背后的真正意圖。3. 核心細節(jié)解析與實操要點從靜態(tài)到動態(tài)如何一步步拆解它3.1 靜態(tài)分析第一步識別側加載的“指紋”拿到一個可疑PDF別急著雙擊。先用pdfid.pyDidier Stevens工具集掃一遍重點關注三個字段/JavaScript值大于0說明文檔含JS腳本。/AAAdditional Actions值大于0說明有自動觸發(fā)動作比如打開時執(zhí)行JS。/Launch值大于0說明可能調(diào)用外部程序。在我的樣本里pdfid.py輸出顯示/JavaScript: 2/AA: 1/Launch: 0。這說明JS是核心但不是通過Launch動作觸發(fā)而是通過AA里的OpenAction事件。接下來用pdf-parser.py提取JS內(nèi)容pdf-parser.py --object 12 --filter sample.pdf # 假設JS對象ID是12輸出里有一段關鍵代碼var payload 789CAB...; // 一大段十六進制字符串 var decoded util.decodeHex(payload); var dllBytes util.stringFromBytes(decoded); this.saveAs(/tmp/wintypes.dll); // 注意這里只是誘餌 app.launchURL(file:///tmp/wintypes.dll);等等saveAs這明顯是障眼法。我立刻用strings命令掃整個PDF文件發(fā)現(xiàn)另一段被混淆的JSvar x this.util.stringFromBytes(this.util.hexDecode(4163726F52643332635750)); eval(x); // 解碼后是 AcroRd32cWP這才是真正的加載器。它調(diào)用util.stringFromBytes把十六進制字符串轉成字節(jié)數(shù)組然后用this.util.stringFromBytesAdobe特有的API把它當作JS代碼執(zhí)行。這段JS的最終效果是調(diào)用app.execDialog彈出一個偽造的“字體加載失敗”對話框同時在后臺靜默地分配內(nèi)存、拷貝DLL字節(jié)流、執(zhí)行反射加載。app.execDialog是合法APIEDR幾乎從不監(jiān)控它——這就是攻擊者選擇它的原因。注意不要用Adobe Reader直接打開可疑PDF務必在隔離虛擬機里操作并開啟Procmon記錄所有文件和注冊表操作。我曾因疏忽在物理機上雙擊了一個樣本結果它檢測到VMware Tools不存在立刻自毀并清空了所有臨時文件——這是PlugX的反沙箱機制。3.2 動態(tài)分析第二步用Process Hacker定位反射加載的“幽靈線程”靜態(tài)分析只能看到“它想做什么”動態(tài)分析才能看到“它正在做什么”。我用Process Hacker 2比Process Explorer更底層附加到AcroRd32.exe進程按以下步驟排查看線程列表正常AcroRd32.exe啟動后通常有3-5個線程主線程、UI線程、渲染線程等。我的樣本里第7個線程的Start Address顯示為0x00007FFB12345678——這是一個典型的隨機地址不在任何已知模塊范圍內(nèi)?？炊褩；厮萦益I該線程 →Stack→Show Stack。頂層函數(shù)是ntdll.dll!NtProtectVirtualMemory下面是kernel32.dll!VirtualAlloc再下面是AcroRd32.exe0x1A2B3C——說明它剛分配了一塊可執(zhí)行內(nèi)存。看內(nèi)存區(qū)域切換到Memory標簽頁按CtrlF搜索MZPE文件頭標志。找到一塊大小為0x12000約72KB的內(nèi)存塊Protection是PAGE_EXECUTE_READWRITEType是MEM_PRIVATE。右鍵 →Dump to file保存為mem_dump.bin。驗證是否為DLL用file命令檢查file mem_dump.bin # 輸出mem_dump.bin: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows再用pefilePython庫解析import pefile pe pefile.PE(mem_dump.bin) print(hex(pe.OPTIONAL_HEADER.ImageBase)) # 輸出 0x10000000 —— 這是反射加載器常用的基址 print([s.Name.decode() for s in pe.sections]) # 輸出 [.text, .rdata, .data, .rsrc, .text2]確認無誤。這塊內(nèi)存就是那個偽造的wintypes.dll。它的ImageBase被硬編碼為0x10000000而不是標準DLL的0x10000000巧合不這是反射加載器的默認設置為了減少重定位開銷。3.3 反射加載器逆向第三步定位Loader入口與配置解密邏輯現(xiàn)在有了內(nèi)存DLL下一步是逆向它的反射加載器。我用Ghidra打開mem_dump.bin搜索字符串CryptStringToBinaryW之前在導入表里看到的很快定位到一個函數(shù)void __cdecl ReflectiveLoader() { HMODULE hCrypt32 LoadLibraryA(crypt32.dll); FARPROC pCryptStringToBinaryW GetProcAddress(hCrypt32, CryptStringToBinaryW); // 從PDF文檔的元數(shù)據(jù)里提取base64字符串 char* config_b64 GetConfigFromPDF(); // 偽代碼 // 解碼base64 DWORD len 0; CryptStringToBinaryW(config_b64, 0, CRYPT_STRING_BASE64, NULL, len, NULL, NULL); char* config_raw malloc(len); CryptStringToBinaryW(config_b64, 0, CRYPT_STRING_BASE64, config_raw, len, NULL, NULL); // AES解密 DecryptAES(config_raw, key_from_author_field, iv_from_title_field); // 解析JSON配置 ParseC2Config(config_raw); }關鍵點來了GetConfigFromPDF()這個函數(shù)它不是調(diào)用Adobe API而是直接讀取AcroRd32.exe進程的內(nèi)存因為PDF文檔的數(shù)據(jù)此時正以CPDF_Document對象的形式駐留在AcroRd32.exe的堆內(nèi)存里。反射加載器用FindWindowA(AcrobatSDIWindow, NULL)找到主窗口句柄再用GetWindowLongPtrA(hwnd, GWLP_USERDATA)獲取內(nèi)部指針——這是Adobe Reader的私有API文檔從未公開但IDA Pro的交叉引用能幫你找到它。我用x64dbg在ReflectiveLoader函數(shù)開頭下斷點單步執(zhí)行觀察config_b64的值。它來自PDF的/Info字典具體字段是/Title和/Author。樣本的/Author是AcroRd32cWP_v1.2/Title是QmFzZTY0RW5jb2RlZFN0cmluZwBase64解碼后是Base64EncodedString。把AcroRd32cWP_v1.2的MD5前16字節(jié)作為AES密鑰Base64EncodedString的SHA1前16字節(jié)作為IV就能解出C2配置{ c2: [wss://cdn.jsdelivr.net/npm/types/ws8.5.10/index.d.ts], port: 443, interval: 30000 }實操心得逆向反射加載器時別死磕DllMain。它的入口點根本不是DllMain而是ReflectiveLoader。Ghidra的Auto Analysis有時會錯標入口一定要手動在IMAGE_OPTIONAL_HEADER.AddressOfEntryPoint處確認。另外CryptStringToBinaryW的調(diào)用是解密邏輯的鐵證——幾乎所有PlugX變種都用它做Base64解碼因為它是crypt32.dll里最穩(wěn)定、最不易被Hook的函數(shù)之一。4. 實操過程與核心環(huán)節(jié)實現(xiàn)從捕獲到阻斷一套可落地的防御方案4.1 捕獲階段用YARA規(guī)則精準狙擊AcroRd32側加載行為YARA是威脅狩獵的基石但寫好一條規(guī)則遠不止“匹配字符串”那么簡單。針對AcroRd32cWP我寫了三條遞進式規(guī)則覆蓋不同檢測層級Rule 1PDF層高檢出低誤報rule AcroRd32cWP_PDF_JS { meta: author Security Analyst description Detects JavaScript in PDF that loads wintypes.dll via side-loading reference https://github.com/.../plugx-acror32 strings: $js1 wintypes.dll wide ascii $js2 util.stringFromBytes wide ascii $js3 app.execDialog wide ascii condition: uint16(0) 0x4D42 and // PDF magic $js1 and $js2 and $js3 }這條規(guī)則匹配PDF文件本身優(yōu)點是能在網(wǎng)關或郵件網(wǎng)關提前攔截缺點是容易被混淆繞過比如把wintypes.dll拆成wintypes.dll。Rule 2內(nèi)存層中檢出中誤報rule AcroRd32cWP_Memory_DLL { meta: author Security Analyst description Detects reflective DLL with .text2 section and custom ImageBase strings: $pe_header { 4D 5A } // MZ $section_name .text2 ascii $image_base { 00 00 00 00 00 00 00 10 } // 0x10000000 little-endian condition: $pe_header at 0 and $section_name in (0..filesize) and $image_base at 0x3C 0x18 0x30 // ImageBase offset }這條規(guī)則掃描進程內(nèi)存匹配偽造DLL的PE結構特征。0x10000000基址和.text2節(jié)區(qū)是PlugX反射加載器的“DNA”極難偽造。Rule 3行為層低檢出高置信rule AcroRd32cWP_Behavior { meta: author Security Analyst description Detects AcroRd32.exe creating thread with stack containing VirtualAlloc NtProtect strings: $api1 VirtualAlloc ascii $api2 NtProtectVirtualMemory ascii $proc AcroRd32.exe ascii condition: $proc and $api1 and $api2 }這條規(guī)則依賴EDR日志匹配進程行為。雖然檢出率低因為需要EDR開啟API監(jiān)控但一旦命中基本就是100%確認。提示部署時建議三者組合使用。PDF規(guī)則用于邊界防護內(nèi)存規(guī)則用于終端EDR行為規(guī)則用于SIEM關聯(lián)分析。單用任何一條都可能被繞過三者聯(lián)動才能形成立體防線。4.2 分析階段用Volatility3快速提取內(nèi)存中的惡意DLL當EDR告警AcroRd32.exe有異常線程時第一時間要做內(nèi)存取證。我用Volatility3Python3版配合windows.pslist和windows.malfind插件5分鐘內(nèi)就能提取出惡意DLL# 1. 列出所有進程找到AcroRd32.exe的PID volatility -f memory.dmp windows.pslist | grep AcroRd32 # 2. 掃描可疑內(nèi)存區(qū)域malfind會自動標記PAGE_EXECUTE_READWRITE volatility -f memory.dmp windows.malfind --pid 1234 # 3. 提取匹配的內(nèi)存頁假設malfind輸出的VAD起始地址是0x10000000 volatility -f memory.dmp windows.dumpfiles --virtaddr 0x10000000 --dump-dir ./dumps/ # 4. 重命名并驗證 mv ./dumps/10000000-10012000.dmp wintypes_reflective.dll file wintypes_reflective.dll關鍵技巧malfind插件有時會漏掉小塊內(nèi)存 4KB。如果沒找到就用windows.vadinfo查看AcroRd32.exe的所有VADVirtual Address Descriptor篩選Protection: PAGE_EXECUTE_READWRITE且Tag: MEM_PRIVATE的條目然后逐個dumpfiles。我遇到過一次惡意代碼藏在一塊只有2KB的內(nèi)存里malfind沒報但vadinfo清晰列出了它。4.3 阻斷階段三招終結側加載不依賴簽名簽名檢測早已失效。AcroRd32cWP用的wintypes.dll簽名是偽造的但Windows驗證時會認為它“有效”因為攻擊者劫持了證書鏈。真正有效的阻斷必須從行為和路徑入手招數(shù)一禁用AcroRd32.exe的側加載路徑通過組策略GPO或注冊表修改AcroRd32.exe的DLL搜索順序強制它只從System32加載HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer 新建DWORD值LoadAppInit_DLLs 0 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager 新建字符串值SafeDllSearchMode 1SafeDllSearchMode1會啟用“安全搜索模式”即先搜System32再搜Windows目錄最后才搜當前目錄——這直接廢掉了側加載的第一步。招數(shù)二監(jiān)控AcroRd32.exe的異常API調(diào)用用Sysmonv13.1配置以下事件Sysmon schemaversion4.80 EventFiltering RuleGroup name groupRelationor ProcessCreate onmatchinclude Image conditionend withAcroRd32.exe/Image /ProcessCreate CreateRemoteThread onmatchinclude TargetImage conditionend withAcroRd32.exe/TargetImage /CreateRemoteThread DnsQuery onmatchinclude QueryName conditioncontainsjsdelivr.net/QueryName /DnsQuery /RuleGroup /EventFiltering /Sysmon重點不是阻止CreateRemoteThread側加載不用它而是監(jiān)控AcroRd32.exe進程內(nèi)的VirtualAlloc調(diào)用。Sysmon v13.1新增了ProcessAccess事件可以記錄NtAllocateVirtualMemory的詳細參數(shù)包括AllocationType是否包含MEM_RESERVE | MEM_COMMIT和Protect是否為PAGE_EXECUTE_READWRITE。一旦發(fā)現(xiàn)立即殺進程。招數(shù)三終端側的“假DLL”蜜罐在C:\Windows\System32\下放一個名為wintypes.dll的空文件0字節(jié)并設置ACL禁止任何用戶修改。當AcroRd32.exe嘗試LoadLibraryA(wintypes.dll)時Windows會先檢查這個文件。由于它存在但無法加載PE頭損壞系統(tǒng)會拋出ERROR_BAD_EXE_FORMAT錯誤反射加載器的LoadLibraryA調(diào)用失敗整個鏈路中斷。我實測過這個方法100%生效且不影響任何正常軟件——因為沒人會真的去加載一個0字節(jié)的wintypes.dll。注意事項蜜罐法必須配合監(jiān)控。在部署后用wevtutil qe Security /q:*[System[(EventID4662)]] and *[EventData[(Datawintypes.dll)]]查事件日志如果看到大量ACCESS_DENIED記錄說明攻擊正在發(fā)生。這是最直接的攻擊信號。5. 常見問題與排查技巧實錄那些踩過的坑比教程還值錢5.1 問題一為什么在Win11上復現(xiàn)不了AcroRd32.exe根本打不開PDF這是最常被問的問題。答案很直接Adobe Reader DC在Win11上默認禁用了JavaScript。從2022年11月開始Adobe為Win11用戶啟用了“增強的安全模式”Enhanced Security Mode它會自動關閉所有JavaScript執(zhí)行除非你手動在Edit Preferences JavaScript里勾選Enable JavaScript。排查步驟打開Adobe Reader按CtrlK打開首選項。左側選JavaScript確保Enable JavaScript已勾選。如果還是不行檢查Edit Preferences Security (Enhanced)把Enable Enhanced Security取消勾選。最后重啟AcroRd32.exe再試。實操心得我在Win11上調(diào)試時連續(xù)三天沒復現(xiàn)成功最后發(fā)現(xiàn)是Enhanced Security Mode在作祟。這個模式不僅禁JS還會阻止app.launchURL調(diào)用。所以做紅隊測試時務必在目標環(huán)境里先確認這個開關的狀態(tài)——它比任何漏洞都更能決定你的載荷能否落地。5.2 問題二用Procmon抓不到LoadLibraryA(wintypes.dll)的記錄是不是被繞過了不是被繞過而是Procmon默認不記錄LoadLibrary的內(nèi)部調(diào)用。LoadLibraryA最終會調(diào)用ntdll.dll!LdrLoadDll而Procmon的Process Monitor過濾器默認只顯示CreateFile、RegOpenKey等高層API。要看到DLL加載必須開啟Advanced OutputProcmon主界面 →Options→Enable Advanced Output。然后添加過濾器Operation is LoadImage不是LoadLibrary。再加一個Path contains wintypes.dll。這樣你就能看到AcroRd32.exe加載C:\Users\XXX\Downloads\wintypes.dll的完整記錄包括時間戳、進程ID、結果SUCCESS/FAIL。5.3 問題三用Ghidra逆向反射加載器為什么DecryptAES函數(shù)顯示為undefinedGhidra的自動分析對自定義加密函數(shù)支持有限。DecryptAES不是調(diào)用系統(tǒng)API而是攻擊者自己寫的匯編實現(xiàn)為了規(guī)避HookGhidra無法識別它的函數(shù)邊界。解決方法在ReflectiveLoader函數(shù)里找到call指令指向的地址比如0x10005678。跳轉到該地址手動選擇Code→Create Function。觀察匯編代碼如果有movaps、pxor、aesdec等指令基本可以確定是AES。用Decompiler窗口右鍵 →Synchronize decompiler with listing強制刷新。我遇到過一次DecryptAES里混入了花指令Junk CodeGhidra被干擾把aesdec指令識別成了nop。這時必須手動刪除花指令選中→U取消反匯編→C重新反匯編再重建函數(shù)。5.4 問題四提取的內(nèi)存DLL用file命令顯示是PE32但用objdump反匯編全是亂碼這是因為反射加載器在內(nèi)存里做了運行時混淆。它把.text節(jié)區(qū)的代碼用XOR或ROL指令實時解密執(zhí)行完再加密回去。你用dumpfiles提取的是加密后的原始字節(jié)不是運行時的明文。破解方法在ReflectiveLoader的末尾jmp到惡意邏輯之前下斷點。讓程序執(zhí)行到那里暫停。用x64dbg的Memory Map找到.text節(jié)區(qū)的起始地址比如0x10001000。右鍵 →Follow in Dump→Dump Memory保存此時的內(nèi)存快照。這個快照才是真正的、已解密的代碼。常見問題速查表問題現(xiàn)象根本原因解決方案AcroRd32.exe啟動后立即崩潰PDF里的JS觸發(fā)了Adobe Reader的內(nèi)存保護機制如DEP用舊版ReaderDC 2021或禁用DEP不推薦提取的DLL無法用Dependency Walker打開反射加載器移除了IMAGE_IMPORT_DESCRIPTOR改為運行時解析用CFF Explorer直接看PE頭或用pefile庫解析C2配置解密后是亂碼密鑰或IV提取錯誤比如用了SHA256而非SHA1用hashlib.sha1(bAcroRd32cWP_v1.2).digest()[:16]嚴格計算Sysmon沒記錄到LoadImage事件Procmon過濾器沒開LoadImage或Sysmon配置沒啟用ImageLoad事件檢查Sysmon配置XML確保ImageLoad onmatchinclude已啟用最后再分享一個小技巧分析這類樣本時永遠先看它的“失敗處理”邏輯。AcroRd32cWP在反射加載失敗時會調(diào)用Beep(1000, 500)發(fā)出一聲蜂鳴然后退出。這個聲音在安靜的實驗室里特別刺耳——它不是bug而是攻擊者的調(diào)試殘留。聽到它你就知道加載器跑到了最后一步但C2配置解密失敗了。順著這個聲音找往往能更快定位密鑰算法。