--- title: 專題報告草稿 tags: - 第一組 --- # 惡意程式特徵分析與樣本情資整合系統 Malware Feature Analysis and Sample Intelligence Integration System ## 摘要 (Abstract) 隨著全球網路攻擊事件逐年攀升,進階持續性威脅(Advanced Persistent Threat, APT)組織頻繁利用客製化惡意程式進行資料竊取與橫向移動。威脅情資分析人員需透過惡意樣本分析提取入侵指標(Indicators of Compromise, IoC),並進一步歸納攻擊者的戰術、技術與程序(Tactics, Techniques, and Procedures, TTPs),以支援防禦決策。然而,傳統分析流程高度仰賴人工經驗,導致分析成本高昂,且分析知識難以有效累積與重用。 本研究提出一套以惡意行為特徵為核心的 Malware Explorer 平台,結合輕量級檢索增強生成(Retrieval-Augmented Generation, RAG)技術,對未知惡意程式樣本之行為特徵進行比對與語義關聯分析。系統整合 YARA 規則、MITRE ATT&CK 框架與行為標籤,建立樣本與特徵之間的統一語義關聯機制,並將經驗導向的人工分析流程轉化為可搜尋、可擴充之特徵知識架構,作為威脅情資分析之輔助工具。 本研究之主要目標在於評估上述特徵導向分析方法結合 RAG 技術於惡意程式樣本分析與威脅情資輔助工作中的可行性與實務適用性。透過實際設計與實作 Malware Explorer 平台,探討該方法在實際分析流程中的應用潛力,並評估其作為人工分析輔助工具之實務價值。 ## 致謝 (Acknowledgements) ## 目錄 (Table of Contents) ## 圖目錄 (List of Figures) ## 表目錄 (List of Tables) ## 第 1 章 緒論 隨著數位轉型深入政府、金融、醫療與關鍵基礎設施的各個層面,網路安全已不再僅是技術維運問題,而是攸關國家安全與經濟穩定的核心戰略議題。2024 年至 2025 年間,全球網路威脅情勢呈現出前所未有的複雜性與破壞力,攻擊者與防禦者之間的技術競賽已進入「機器對抗機器」的新階段。 ### 1.1 研究背景 #### 1.1.1 全球惡意程式威脅現況 當前的威脅環境正經歷顯著的典範轉移。根據 CrowdStrike 的 2025 年全球威脅報告,攻擊者的行動速度已大幅提升,從入侵到橫向移動或資料竊取的「突破時間」(Breakout Time)顯著縮短。數據顯示,最快的 eCrime 突破時間已縮短至驚人的 51 秒,平均時間也降至 48 分鐘 。這意味著防禦者在偵測到初始入侵跡象後,僅有極短的時間窗口進行遏制與應變,傳統依賴人工分析與回應的流程已難以追趕此一速度。 此外,惡意程式即服務(MaaS)模式的成熟,使得網路犯罪呈現高度商業化與模組化。Bitsight 的研究指出,截至 2025 年上半年,諸如 Fog、Acreed 與 Lumma 等 MaaS 平台在暗網市場極為活躍 。這些平台不僅提供勒索軟體(Ransomware)與資訊竊取程式(Infostealers)的生成器,還整合了自動化的混淆加密(Crypters)、流量導引與洗錢服務,大幅降低了發動高複雜度攻擊的技術門檻。這導致惡意程式變種數量呈現爆炸性增長,攻擊者能輕易產出具備多型態特徵的樣本,直接挑戰傳統防毒軟體的偵測極限。 - https://fusion.vsp.virginia.gov/wp-content/uploads/2025/07/CrowdStrikeGlobalThreatReport2025.pdf - https://www.bitsight.com/blog/current-malware-trends-2025 #### 1.1.2 台灣面臨的 APT 攻擊態勢 台灣處於地緣政治的敏感樞紐,長期以來是亞太地區網路攻擊的熱區與試驗場。根據 ESET 與 Recorded Future 的情資報告,與中國相關的 APT 組織(如 RedNovember, Mustang Panda, Flax Typhoon, Charcoal Typhoon)持續加大對台灣政府機關、半導體產業、醫療體系及關鍵基礎設施的滲透力度 。這些攻擊活動往往與特定的地緣政治事件高度相關,且攻擊手法日益隱蔽。 值得注意的是,攻擊者不再單純依賴傳統的二進位惡意程式,而是轉向利用「離地攻擊」(Living-off-the-Land, LotL)技術。例如,CrowdStrike 觀察到攻擊者頻繁利用 RMM(Remote Monitoring and Management)工具與系統內建的 PowerShell、WMI 進行操作,這使得僅基於檔案掃描的防禦手段日益失效 。此外,針對邊緣設備(Edge Devices)如 VPN 閘道器、防火牆的漏洞利用也成為主流,RedNovember 組織便曾針對台灣科技公司的邊界設備進行大規模偵察與滲透 。在這種高強度的攻防環境下,台灣的資安情資團隊面臨著巨大的分析壓力,必須在極短時間內解析出未知樣本的行為特徵與關聯家族,以產出具備實戰價值的威脅情資(Cyber Threat Intelligence, CTI)。 - https://www.welivesecurity.com/en/eset-research/eset-apt-activity-report-q2-2025-q3-2025/ - https://www.recordedfuture.com/research/rednovember-targets-government-defense-and-technology-organizations - https://www.crowdstrike.com/en-us/global-threat-report/ #### 1.1.3 情資分析的實務挑戰 儘管資安社群已發展出多種分析工具,但在實務操作中,情資分析仍面臨嚴峻挑戰,這與 NTT Security 等機構對 2025 年網路安全的觀察一致: 1. 逆向工程的技術門檻極高:要從二進位檔案(Binary)還原攻擊邏輯,分析人員需精通組合語言(Assembly)、作業系統核心原理以及編譯器優化技術。這是一條極其漫長的學習曲線,導致資深逆向工程師(Reverse Engineer)在全球範圍內極度短缺。 2. 知識管理的困境:在傳統作業流程中,分析師的發現往往散落在個人的筆記、未結構化的文檔或腦海中。當面對一個新樣本時,分析師往往難以快速查詢「這個加密函式是否在三年前的某個樣本中出現過?」。缺乏系統化的特徵知識庫,導致分析工作往往是重複造輪子,無法有效累積團隊經驗。 3. 現有工具缺乏語義理解:業界標準工具如 Yara 雖然強大,但其本質是基於字節(Byte)或字串(String)的模式匹配。如果攻擊者對同一段原始碼進行重新編譯或微幅修改指令順序(Instruction Scheduling),Yara 規則極易失效。現有工具缺乏對「程式碼行為語義」的理解能力,無法識別「功能相同但實作細節不同」的程式碼片段。相關研究亦指出,隨著 LLM 被用於惡意程式生成與 Prompt Injection 攻擊,此一技術缺口將更為顯著。 - https://fusion.vsp.virginia.gov/wp-content/uploads/2025/07/CrowdStrikeGlobalThreatReport2025.pdf - https://group.ntt/en/topics/2024/12/19/cybersecurity2025.html - https://www.sentinelone.com/labs/prompts-as-code-embedded-keys-the-hunt-for-llm-enabled-malware/ - https://copilot.bugbase.ai/blogs/llm-malware-creation-prompt-injection ### 1.2 研究動機 面對日益氾濫的惡意程式變種,分析人員在實務上常需耗時進行重複性的逆向工程。特別是當攻擊者透過重新編譯、指令重排或調整實作細節來規避偵測時,傳統依賴雜湊值或靜態特徵字串的比對方式往往失效,難以有效辨識出家族間的行為關聯,導致分析工作缺乏效率與一致性。 本團隊在實務工作中觀察到,逆向工程往往需投入極高的人力,才能從組語中還原出關鍵的演算法邏輯。然而,現行流程缺乏一套標準化的特徵保存機制,導致這些分析成果僅能以非結構化的形式散落於個人筆記或結案報告中,無法被有效索引與重用。這使得分析人員在面對相同或相似的惡意行為時,經常陷入「重複造輪子」的困境,必須再次投入資源進行分析。 此外,既有的樣本管理多屬靜態紀錄,一旦發現新特徵,往往難以回溯並更新舊樣本的標籤,造成新舊情資斷鏈,大幅降低了歷史資料的參考價值。 有鑑於此,本研究希望利用大型語言模型(LLM)在程式碼理解上的優勢,將非結構化的分析經驗轉化為可檢索的知識。透過導入檢索增強生成(RAG)技術,我們期望能建立一套整合「特徵庫」與「樣本情資」的輔助機制,從語義層面解決變種比對難題,並解決知識碎片化的困境,此即為本研究之核心動機。 ### 1.3 研究目標 針對前述研究動機,本研究提出並實作「惡意程式特徵分析與樣本情資整合系統(Malware Explorer)」。本研究以行為特徵為基礎,導入檢索增強生成(RAG)技術,期能透過以下三項具體目標,建立一套可累積分析經驗並提供實務輔助的平台: - 特徵知識庫與標準化架構:逆向工程往往需耗費大量時間,才能還原出關鍵的程式邏輯與演算法。為避免分析成果僅止於一次性使用,本目標致力於建立標準化的特徵保存架構,將程式碼片段(Pseudo-C/Assembly)進行結構化留存。確保這些技術細節能被有效累積,未來若面對相同邏輯時,不需再次投入資源進行逆向的重複工作。 - 樣本管理與情資關聯:樣本管理的價值不僅止於檔案儲存,更在於分析經驗的累積與傳承。本目標致力於建構能夠持續更新的情資架構,使分析人員能針對新舊樣本隨時增補報告、修訂標籤與建立特徵關聯。藉由將個人的分析轉化為樣本的永久紀錄,確保知識能跨越人員異動與時間限制,在團隊內部有效傳承與延續,避免情資因缺乏維護而失去參考價值。 - 應用 RAG 程式碼特徵檢索:本目標利用檢索增強生成(RAG)技術,建構以程式碼為核心的分析引擎。透過 AI 作為橋樑,讓分析人員能直接針對程式碼片段進行資料庫的檢索。此機制不僅能比對出相似的歷史特徵,更能進一步連結至具備相同特徵的關聯樣本,協助分析人員快速掌握潛在的家族關係與威脅脈絡。 ### 1.4 預期貢獻 本研究整合大型語言模型與檢索增強生成(RAG)技術,建構一套以特徵為核心的分析與管理架構。針對逆向工程中需耗時解析的關鍵邏輯,本研究建立標準化保存機制,將程式碼片段與行為標籤轉化為結構化資產。藉此,分析人員能透過 AI 檢索,快速識別庫中既有或具相似邏輯的行為特徵,直接引用過往分析成果,避免對已知功能重複投入逆向工作。同時,本系統建立支援動態增補的情資管理體系,將個人分析觀點轉化為跟隨樣本的永久紀錄,確保分析經驗能跨越人員異動在團隊內有效傳承,提供具實務價值的輔助研判基礎。 ### 1.5 專題專案管理與成本分析 本專案採用 GitHub 進行版本控制,並依據成員專長分配工作,確保開發與研究同步進行。 | 工作項目 | 起始時間 | 結束時間 | | ----------- | ------ | ------- | | 方向論與規劃 | 2024/6 | 2024/7 | | 惡意程式樣本分析 | 2024/8 | 2025/8 | | 資料蒐集 | 2025/1 | 2025/5 | | 需求/架構設計 | 2025/3 | 2025/5 | | 前端 UI/UX 設計 | 2025/4 | 2025/6 | | 後端 API/功能開發 | 2025/5 | 2025/7 | | LLM 語言模型整合 | 2025/7 | 2025/9 | | 測試與修正 | 2025/8 | 2025/10 | | 文件撰寫與成果準備 | 2025/9 | 2025/11 | ![image](https://hackmd.io/_uploads/SJJ35lpXWx.png) | 工作內容 | 羅崧瑋 | 陳威瀚 | 方健宇 | | - | - | - | - | | 惡意程式分析 | 33% | 33% | 33% | | 後端開發 | 40% | 10% | 50% | | 前端開發 | 30% | 60% | 10% | | 海報 | 80% | 10% | 10% | | 書面報告 | | | | ## 第 2 章 文獻探討 ### 2.1 惡意程式分析流程與挑戰 #### 2.1.1 惡意程式分析方法概述 惡意程式分析的目的在於解析可疑程式的內部運作邏輯、潛在危害行為,以及其可能的來源與關聯性。透過系統化且具結構性的分析流程,研究人員得以深入理解惡意程式的攻擊手法與影響範圍,並據此產出可用於偵測與防禦的成果,例如入侵指標(IoCs,如雜湊值、可疑網域/IP、檔名)、行為特徵(如持久化方式、程序注入、異常網路通訊),以及後續事件回應與防護策略設計所需的技術依據。 依據分析過程中是否實際執行樣本,惡意程式分析技術主要可分為靜態分析與動態分析兩大類。靜態分析係在不執行程式的前提下,透過反組譯與反編譯等逆向工程技術,檢視程式結構與控制流程,以推測其可能行為;動態分析則是在受控或隔離的執行環境中實際運行樣本,觀察其於系統層級所產生的行為變化,例如檔案存取、系統設定修改與網路通訊活動。於實務應用中,自動化沙箱可視為動態分析的重要實作形式之一,能夠快速蒐集大量樣本的行為特徵與網路活動資訊,以支援大規模樣本分析。 #### 2.1.2 靜態分析與工具(IDA Pro、Ghidra) 靜態分析常用工具包含 IDA Pro、Binary Ninja 與 Ghidra。然而,現代惡意程式常使用混淆技術(Obfuscation),如控制流平坦化(Control Flow Flattening)、垃圾代碼(Junk Code)、虛擬機保護殼(VM Protect)或 API Hashing,導致傳統反組譯工具難以還原程式邏輯,大幅增加了逆向工程的難度。 ![Binary Ninja](https://hackmd.io/_uploads/r1JUP987Wg.png) #### 2.1.3 動態分析與工具(Procmon、x64Dbg、API Monitor) 動態分析利用 x64Dbg 進行除錯,或使用 Procmon、API Monitor 監控作業系統事件。此方法能捕捉程式運行時的真實行為,但若惡意程式具備反除錯(Anti-Debugging)或反虛擬機(Anti-VM)機制,分析可能受阻。 ![圖片](https://hackmd.io/_uploads/SJE5s8t7Ze.png) #### 2.1.4 沙箱分析工具(Cuckoo、Any.Run) 自動化沙箱(如 Cuckoo Sandbox, Any.Run)能快速產出網路封包與 API 序列報告。然而,沙箱報告通常僅提供高層次的行為概覽,缺乏對核心惡意演算法(如加解密邏輯)的深入解析。 ![Screenshot 2025-12-25 at 00-17-09 Analysis https __sav.sendio.net_goldberglawcenter.com_msg ua doug&amp sa Jordan.Hall_40topgolf.com&amp id 1766522257.2363504.1.0.d0243736.0dc3 No threats detected - Interactive analysis ANY.RUN](https://hackmd.io/_uploads/rJs8Gqt7-x.png) #### 2.1.5 傳統分析流程的瓶頸 主要瓶頸在於「高重複性」。不同分析師在不同時間點面對相同的惡意特徵(例如某個常見的 Shellcode Loader),若缺乏資訊同步機制,便會重複投入時間進行逆向分析,造成資源浪費。 #### 2.1.6 知識管理的困境 現行分析結果多以靜態報告形式保存,缺乏結構化的特徵整理,使分析知識難以查詢與傳承,新進分析人員往往需投入大量時間理解既有樣本。 #### 2.1.7 新人培訓成本分析 由於逆向工程高度仰賴實務經驗與系統底層知識,培育具備獨立分析能力的惡意程式分析師需投入大量時間與人力成本。 ### 2.2 威脅情資平台現況 #### 2.2.1 開源平台 (MISP, OpenCTI) 目前主流的開源威脅情資平台如 MISP (Malware Information Sharing Platform) 和 OpenCTI,在情資共享上扮演關鍵角色,但也存在特定侷限: - MISP 的侷限:MISP 提供結構化指標(IoC)如 IP、Domain、Hash 的儲存與關聯,並透過 PyMISP 提供自動化介面 。然而,MISP 對於「非結構化」的程式碼片段或二進位函式相似度的支援相當有限。它缺乏對程式碼進行語義搜尋(Semantic Search)的原生能力,分析師難以在 MISP 中查詢「類似於此解密演算法的其他樣本」。 - OpenCTI 的侷限:OpenCTI 提供了基於 STIX 2.1 標準的強大知識圖譜,能夠視覺化攻擊者(Threat Actor)、戰役(Campaign)與 TTPs 之間的關係 。雖然近期引入了 Malware Analysis 功能 ,但其主要仍聚焦於高層次的威脅建模,對於底層逆向工程產出的程式碼特徵管理與比對,尚未有深度的整合方案。 本研究提出的系統旨在填補此一缺口,專注於「程式碼層級(Code Level)」的特徵管理與比對,並可作為 MISP 或 OpenCTI 的上游分析工具。 #### 2.2.2 公開資料庫 VirusTotal 與 Malware Bazaar 紀錄了豐富的 Metadata 與偵測率,但這些平台主要以「檔案(File)」為單位,較難針對檔案內部的特定「函式(Function)」進行細粒度的比對與搜尋。 #### 2.2.3 現有工具的不足 | | 樣本管理 | 特徵管理 | 自動化分析 | 情資管理 | | - | - | - | - | - | | MISP | v | x | x | v | | OpenCTI | v | x | x | v | | Virus Total | v | x | v | v | | Malware Explorer(本專案) | v | v | x | v | ### 2.3 RAG 技術在資安領域的應用 檢索增強生成(RAG)結合了檢索系統與生成式 AI 的優勢。在資安領域,RAG 可用於自動化解釋腳本、查詢資安規範或生成事件報告。然而,將 RAG 應用於「組合語言」或「偽代碼(Pseudo C)」的相似度比對,仍是較新的研究方向。 #### 2.3.1 RAG 原理與架構 檢索增強生成(RAG)結合資訊檢索與生成式模型,先從既有資料庫中篩選相關內容,再由大型語言模型進行語義理解與生成,藉此降低幻覺並提升回應的準確性。 #### 2.3.2 資料庫與語義搜尋 在 RAG 架構中,資料庫扮演知識來源的角色,透過結構化欄位或標籤進行初步篩選,再進行語義層級的比對,可有效縮小搜尋空間並提升比對效率。 #### 2.3.3 LLM 在惡意程式分析的角色 LLM 已被證明具備解釋程式碼功能、撰寫 Yara 規則與摘要行為的能力。然而,受限於 Context Window 大小,直接將整個二進位檔案丟給 LLM 分析並不可行,因此結合 RAG 針對特定函式進行分析是較佳策略。 #### 2.3.4 最新研究成果與應用案例 近年研究開始探討利用 LLM 輔助逆向工程(如 LLM4Decompile),但多數聚焦於單一程式碼解釋,鮮少有系統整合歷史情資庫進行大規模的比對與關聯分析。 [Feasibility Study for Supporting Static Malware Analysis Using LLM](https://link.springer.com/chapter/10.1007/978-3-031-82362-6_1) ### 2.4 特徵比對與家族歸屬方法 #### 2.4.1 字節特徵比對 (Signature) 字節特徵比對屬於簽章式偵測方法,主要針對二進位檔案(Binary)中的十六進位字串(Hex String)或特定字串樣式進行比對,其中最常見的實作即為 YARA 規則。透過在檔案內容中搜尋特定位元組序列或特徵片段,YARA 能快速判定樣本是否與既有惡意程式或家族特徵相符。例如,分析工具 Detect It Easy(DIE)內建多組 YARA 規則,命中結果可直接呈現在介面上,協助分析人員完成初步篩選與樣本分類。 然而,此方法仰賴固定字節特徵,一旦樣本經過混淆、重編譯或加殼處理,原始特徵即可能失效。因此雖適合快速定位已知威脅,但對於多型變種或新型樣本的偵測能力仍然有限。 #### 2.4.2 靜態特徵分析 (Function) 靜態特徵分析著重於函數層級之語義與行為模式,例如 API 呼叫序列、檔案與註冊表操作類型,以及常見的加密或混淆邏輯。以 CAPA 為例,其透過規則庫比對函數語意特徵,判斷是否符合已知惡意行為樣式,分析結果具備可解釋性並有助於家族歸屬判定。 然而,此方法仍依賴規則庫完整性與更新頻率,對於經過強度混淆或加殼處理後的函數,偵測能力可能下降,且需投入人力持續維護規則內容。 #### 2.4.3 動態行為監控 (Behavior) 動態行為監控則從程式執行層面觀察樣本行為,以辨識其攻擊目的與操作手法。傳統作法常以 API 呼叫序列、檔案與登錄變更、網路連線行為等運作軌跡進行比對或分群,以建立行為層級之相似性判斷。 然而,動態特徵容易受到執行環境、觸發條件與反分析機制影響,導致行為表徵缺乏穩定性,不利於進行長期知識累積與跨樣本檢索。 #### 2.4.4 MITRE ATT&CK 框架應用 MITRE ATT&CK 是企業常用的威脅情報框架,用於歸類惡意程式及攻擊行為的戰術與技術,提供統一命名與分類標準,便於跨組織共享與分析情資,並支援對攻擊手法的追蹤與防禦策略制定。 ### 2.5 研究缺口與本研究定位 現有工具多著重於 IoC 層級的共享,缺乏針對「程式碼行為邏輯」的私有知識庫。本研究填補此缺口,提供以函式特徵為中心的分析輔助系統,並透過 RAG 技術解決變種比對難題。 #### 2.5.1 現有工具比較總結 綜合前述平台與工具可觀察到,現有解決方案多以檔案或指標(IoC)為管理單位,分工明確但彼此斷裂。以 MISP、OpenCTI 為代表的情資平台擅長管理 IoC、Actor、Campaign 與 TTP 等高層次關聯,適合共享與視覺化情資;VirusTotal、MalwareBazaar 等公開資料庫提供大量樣本與偵測結果,利於快速查詢與樣本背景補充。在工具方面 Cuckoo、Any.Run 等沙箱則能自動化產出行為概覽,支援大量樣本初步分析,IDA Pro、Ghidra 等逆向工具可提供函式與控制流程的深入理解,但分析成果多停留在個人產出,難以被系統化保存與跨樣本檢索。 因此,現有工具雖能涵蓋樣本蒐集、行為觀測、IoC 管理、建立為威脅圖譜等需求,但在「程式碼/函式層級的特徵知識管理」與「跨樣本語義相似度搜尋」方面仍明顯不足,導致分析師面對變種樣本時,仍高度依賴人工經驗與重複比對。 #### 2.5.2 研究缺口分析 本研究聚焦的缺口可歸納為三點: 1. 缺乏函式層級的可重用知識庫 多數平台以檔案或 IoC 為主體,難以把逆向工程中的「關鍵函式特徵」(如 loader、decryptor、persistence routine)以可搜尋、可累積的形式保存。 2. 缺乏語義層級的相似度檢索機制 傳統比對多依賴 hash 或 YARA bytes/string pattern。當攻擊者進行重新編譯、指令順序重排、混淆或改用不同 API 實作同一目的時,規則容易失效,且難以回答「這段程式碼在行為意圖上像不像某個已知特徵」這類語義問題。 3. 分析產出與情資框架未形成閉環 實務上分析結果常散落在報告、筆記與個人記憶中,即使有 ATT&CK 或 YARA 仍缺乏一個流程把程式碼片段、行為摘要/標籤、TTP 對應、偵測產物系統化串起來,導致知識難以標準化、難以共享也難以支援新人快速上手 #### 2.5.3 本研究的創新點 針對上述缺口,本研究提出的 Malware Explorer 具備以下創新設計: 1. 以「函式特徵」為核心的資料模型與知識管理 將程式碼片段(Pseudo-C/Assembly)、行為摘要、標籤、YARA 規則與 MITRE ATT&CK 技術編號混和為單一特徵,並支援「一個特徵對應多個樣本」的關聯模式,讓分析成果可長期保存與跨樣本重用。 2. LLM + 輕量 RAG 的語義比對流程 以 LLM 將輸入程式碼抽象成摘要與標籤,先用標籤快速縮小候選集合再對候選進行語義評分與排序,提升對變種樣本的辨識能力,並把「像不像」轉為可解釋的排序結果。 3. 把比對結果直接落到可用情資產物 系統比對的輸出不只是一個分數,而是可回推到相關特徵、對應 TTP、以及可部署的偵測規則。因此整體流程形成分析、累積、產出與檢索的閉環,降低重複逆向成本,並提升情資產出效率與一致性。 ## 第 3 章 系統設計與架構 ### 3.1 整體系統架構 本系統採用微服務架構(Microservices Architecture)設計,確保可擴展性與維護性。前端透過 HTTP 請求與 NGINX Gateway 溝通,後端 API 服務處理業務邏輯並存取 PostgreSQL 資料庫,AI 分析模組則作為獨立服務與 LLM 介接。 ### 3.2 核心模組設計 本系統採用現代化 Web 架構與微服務設計,前後端分離,並以 NGINX 作為 API Gateway,後端介接關聯式資料庫。 系統整合四大核心模組: - 使用者管理模組:權限控管與操作軌跡紀錄。 - 特徵管理模組:惡意特徵的 CRUD 與標籤化管理。 - 樣本管理模組:樣本上傳、解析與報告撰寫。 - 搜尋引擎模組:整合 LLM 的語義搜尋核心。 本系統的預期貢獻在於將惡意程式分析中零散的個人經驗,轉化為可查詢、可累積的特徵知識庫,提升整體分析效率。 #### 3.2.1 統一特徵知識管理模組 本模組以「惡意行為特徵」為核心,負責特徵資料的儲存、索引與關聯管理。每一項特徵可包含對應的程式碼片段、行為標籤、文字化摘要,以及關聯的 Yara 規則與 MITRE ATT&CK 技術編號,並支援單一特徵對應多個樣本的關聯模式。 系統依據 MITRE ATT&CK 框架建立一致的特徵分類體系,將低階技術特徵(如 Assembly 與 Pseudo-C)與高階行為語意進行對應,使分析結果能以標準化形式儲存,提升跨樣本比對與情資重用的效率。 #### 3.2.2 樣本生命週期管理模組 此模組負責惡意程式樣本自匯入至分析完成的整體流程管理,包含基本靜態資訊解析(如雜湊值與檔案結構)、特徵關聯,以及分析成果的彙整。 系統將樣本、對應特徵與分析文件進行整合管理,使分析過程中所產出的知識能即時轉化為可重用的特徵資料,並提供一致化的樣本管理介面,降低分析流程中的資訊分散問題。 #### 3.2.3 LLM 驅動 RAG 特徵比對模組 本模組為系統之核心分析引擎,負責將使用者提交的程式碼片段轉換為可比對的行為特徵,並與既有知識庫進行語義層級的比對。 系統採用多階段的 RAG 分析流程,先對輸入程式碼進行高層次的行為語義抽象,生成對應的行為摘要與關鍵標籤,作為後續比對的語義表示;接著根據這些語義資訊,自知識庫中篩選出具高度相關性的歷史特徵作為候選集合;最後再針對候選特徵進行語義層級的相似度評估,產出具排序性的比對結果,輔助分析人員快速判斷程式碼行為的關聯性。 ### 3.3 開發環境與部署 #### 3.3.1 開發環境配置 - 前端開發環境:採用 pnpm 作為套件管理工具,以提升套件安裝速度並降低磁碟空間使用量,確保前端開發流程的效率與一致性。 - 後端開發環境:使用 uv(Python)進行相依套件管理與虛擬環境建置,提供快速且穩定的依賴解析機制,降低不同開發環境設定差異對專案流程的影響。 #### 3.3.2 Docker Compose 部署 本系統透過 Docker Compose 進行容器化部署,整合 Web Server、後端 API 服務與 PostgreSQL 資料庫,統一管理各服務之啟動與設定。此部署方式可確保系統於不同執行環境下具備一致行為,並有效降低環境建置與部署的複雜度,使系統具備快速部署與後續擴展的能力。 #### 3.3.3 CI/CD 流程 本專案導入 GitHub Actions 建立持續整合流程,並搭配 Git Hooks 與 pre-commit 機制,於開發階段即強制執行程式碼格式化與靜態檢查(Linting/Formatting),以維持程式碼品質與風格一致性。此外,透過 OpenAPI Client Generation 自動產生用戶端介面,降低前後端整合成本,提升整體專案的可維護性與開發效率。 ## 第 4 章 系統實作與關鍵技術 ### 4.1 RAG 流程實作細節 當使用者在前端輸入一段未知的程式碼片段(Query Code)時,系統後端會觸發以下自動化流程: #### 第一階段:特徵提取與摘要 (Extraction & Summarization) - 輸入:原始程式碼(Pseudo C 或 Assembly)。 - 處理:呼叫 LLM (Gemini) 進行初步分析。 - Prompt 設計:系統使用特定的 Prompt (call_llm_for_summary_and_tags),要求 LLM 扮演「惡意程式碼分析助理」。 - 關鍵約束:要求 LLM 僅 回傳原始 JSON 格式 {"summary": "...", "tags": [...]},嚴禁使用 Markdown 程式碼區塊(如 ```json)。這是為了避免後端 Parser 解析錯誤,提高系統穩定性。 - 標籤指引:Prompt 中提供了標準化的標籤範例(如 process-hollowing, reg-write, privesc),引導模型使用統一的術語,而非自由發揮,這對於後續的資料庫檢索至關重要 。 - 輸出:生成一段行為摘要與 3-8 個行為標籤。 #### 第二階段:候選檢索 (Retrieval) - 機制:這是 RAG 的「檢索」部分。系統不直接將查詢代碼與資料庫中數萬筆特徵逐一比對(那樣太慢且昂貴)。 - 實作:系統利用第一階段生成的「標籤(Tags)」作為索引鍵,在 PostgreSQL 中進行 SQL 查詢。 - 使用 SQL ILIKE,快速篩選出具有相同或相似標籤的歷史特徵作為「候選集(Candidates)」。 - 此步驟大幅縮小了搜尋空間,將比對範圍從全庫縮小至數十筆高度相關的特徵。 #### 第三階段:語義比對與評分 (Ranking & Scoring) - 機制:這是 RAG 的「生成」部分,也是系統智慧的核心。 - Prompt 設計:系統使用 `call_llm_for_scoring` Prompt,將「查詢代碼的摘要」與「候選特徵的描述」成對送入 LLM。 - 評分量表 (Scoring Rubric):為了抑制 LLM 的幻覺並統一標準,Prompt 中定義了極為嚴格的評分標準 : - 0.9 - 1.0: 代碼/文本幾乎完全相同。 - 0.8 - 0.89: 結構相同且 API 呼叫序列一致(即使變數名稱不同)。 - 0.6 - 0.79: 僅結構相似(Control Flow Graph 相似)。 - 0.4 - 0.59: 部分 API 或函式重疊。 - 0.2 - 0.39: 僅行為標籤重疊(如都涉及檔案寫入,但實作邏輯不同)。 - 0.0 - 0.19: 無意義的匹配。 - 輸出要求:強制 LLM 使用繁體中文輸出,並回傳結構化的 JSON,包含 feature_id, score, reason 和 reason_details。這確保了分析結果可以直接被前端讀取並展示給分析師使用。 ### 4.2 Prompt 工程優化 #### 4.2.1 初期 Prompt 設計與問題 初期的設計詳細列出所有規則,要求 LLM 詳細解釋判斷依據的原因。雖然準確度高,但平均回應時間長達 60 秒,嚴重影響使用者體驗。 #### 4.2.2 優化策略與效能提升 透過精簡提示詞(Prompt Pruning),移除不必要的背景敘述、註解,並強制截斷輸入內容,再加上 libdiff 的參考準確度,成功將平均回應時間縮短至 30 秒左右,且未顯著犧牲準確度。 #### 4.2.3 幻覺問題處理 為降低大型語言模型(LLM)產生未經證實推論(hallucination)的風險,本研究於 Prompt 設計中加入負面約束(Negative Constraints),明確要求模型在證據不足或無法判定時回傳「未知」,避免進行臆測性描述,例如「若無法確定功能,請回答未知,不可臆測」。此設計並非宣稱可完全消除模型幻覺行為,而是作為一種輸出行為層級的限制機制,以降低模型在不確定情境下給出具體推論的機率。此外,系統後端亦透過程式邏輯驗證模型回傳之 JSON 結構完整性,確保輸出結果符合預期格式。 ### 4.3 系統實作細節 #### 4.3.1 前端技術選型 本系統前端選用 Next.js 作為主要開發框架,以建構具備高互動性與可維護性的單頁應用(Single Page Application, SPA)。Next.js 基於 React 架構,支援模組化元件設計與 App Router 機制,能有效拆分頁面職責,適合用於功能模組明確、頁面互動頻繁的系統。 為提升分析人員在處理惡意程式查詢時的效率與可操作性,查詢介面設計著重於: - 即時系統反饋:針對耗時 API 請求,介面顯示 Loading Spinner 與 Skeleton Loading,提供明確進度反饋,降低使用者等待焦慮。 - 降低操作中斷:使用 側拉式抽屜(Sheet)與模態視窗(Dialog)呈現樣本與特徵細節,操作完成後可無縫返回原列表頁面,維持分析流程連貫性。 - 快速資訊檢索:實作伺服器端分頁與多欄位篩選,支援快速搜尋與批次分析,提升資料定位與操作效率。 #### 4.3.2 後端 API 設計 後端以 RESTful API 風格規劃,依功能模組拆分為多個 Router,統一掛載於 /api 下,以資源為核心設計 URL ( `/malware`、`/features` )透過 HTTP 方法(GET/POST/PUT/DELETE)對應 CRUD 操作,以維持介面一致性與可擴充性,並利用 FastAPI 內建 OpenAPI 自動產出文件,降低前後端串接與測試成本。核心端點方面共分為三個部分別為 - 分析資源(`/api/analyze`) - 負責處理核心分析請求。考量到輸入內容可能包含大量程式碼片段或二進位資料,採用 POST 方法傳送 JSON Body,以觸發後端的特徵提取與 LLM 分析流程。 - 特徵資源(`/api/features`) - 負責特徵知識庫的管理。為支援多維度的檢索需求(如依標籤、類型篩選),查詢介面 (GET) 大量運用 Query Parameters 進行過濾。同時完整實作 POST、PUT、DELETE 方法,分別對應特徵的新增、更新與刪除,確保知識庫的動態維護能力。 - 樣本資源(`/api/malware`) - 負責惡意程式樣本的生命週期管理。針對樣本上傳 (POST),採用 multipart/form-data 格式以支援二進位檔案傳輸,並在後端接收時即時計算雜湊值進行去重複化檢查。查詢介面 (GET) 則提供樣本 Metadata 檢索,並支援下載原始樣本與分析報告,實現從樣本入庫到情資取用的完整流程。 ![Screenshot 2025-12-25 at 00-26-35 Malware Explorer API - Swagger UI](https://hackmd.io/_uploads/SyZuEqYX-x.png) #### 4.3.3 資料庫優化 本系統採用 PostgreSQL 作為核心資料庫,並透過 SQLModel (結合 SQLAlchemy 與 Pydantic) 進行 ORM 操作。為了確保系統在處理大量惡意軟體樣本與特徵資料時的效能,我們實作了以下優化策略 1. JSON 型別應用 針對家族、MITRE ATT&CK 編號、標籤,採用 PostgreSQL 的 JSONB 欄位儲存減少可能需要建立多個小型關聯表的需求且透過 GIN 索引(Generalized Inverted Index),大幅提升搜尋速度。 2. 記數欄位 我們在特徵與樣本資料庫中皆有記數欄位可以快速得知關聯的資料數量,避免每次查詢時都需要對多對多關聯表進行昂貴的 COUNT(*) 進而降低後端負擔 3. 預先載入 在讀取樣本或特徵關聯資料時本系統使用了 SQLAlchemy 的函式 selectinload() 確保在查詢樣本或特徵資料時會單獨透過一條 SQL 查詢一次性取出,而非對每一筆樣本都重新發送查詢,這可以大幅降低資料庫往返次數,減少不必要的效能與時間浪費。 <!-- 針對 PostgreSQL 進行效能調校,對 JSONB 格式的標籤欄位建立 GIN 索引(Generalized Inverted ,大幅提升標籤搜尋速度。 --> ![圖片](https://hackmd.io/_uploads/rJKJrqYQbe.png) ### 4.5 系統功能展示 ![查詢頁面](https://hackmd.io/_uploads/ryYKJ8CGZg.png) ![分析報告頁面](https://hackmd.io/_uploads/BkSpk8CGbl.png) ![特徵資訊](https://hackmd.io/_uploads/r1wleURM-e.png) ![儀錶板](https://hackmd.io/_uploads/rycGe8AMWl.png) ![樣本上傳](https://hackmd.io/_uploads/S1fUlUCzWl.png) ![樣本資訊](https://hackmd.io/_uploads/S1AcxUAMZe.png) ## 第 5 章 研究成果與評估 ### 5.1 實際案例分析 #### 5.1.1 Pseudo C 程式碼比對案例 本案例選用 DOPLUG 家族樣本中擷取的 Pseudo C 函式片段作為查詢輸入。系統首先對輸入片段產生行為摘要與標準化標籤,並以標籤在特徵知識庫中檢索候選集合,最後輸出排序後的相似特徵清單與比對理由。從結果可觀察到,系統能將查詢片段對應到知識庫中已建立的相似特徵,並提供具體的語義理由(例如流程結構相近、關鍵 API/操作目的一致),使分析師可快速確認該函式在家族中的角色,並回推到相關樣本與既有分析紀錄,降低重新逆向的成本。 > 補圖片 #### 5.4.2 Assembly 特徵比對案例 > ... 待補,或需要嗎? #### 5.4.3 跨家族相似特徵發現 為驗證系統在「跨家族重用特徵」的能力,本案例以常見的攻擊功能作為觀察目標(例如下載器、持久化相關例程)。系統在比對過程中可產生跨樣本的相似特徵候選,顯示不同家族間可能共享相近的實作邏輯或行為目的。此能力有助於分析師在面對未知樣本時,不僅能定位家族內相似特徵,也能擴展到「功能層級」的關聯探索,支援後續威脅歸因或戰術行為彙整。 ### 5.5 系統限制與討論 #### 5.5.1 當前限制 - 輸入表示方式的限制:目前系統在類 C 偽代碼與組合語言片段的表現較佳,若輸入極短片段或 - LLM 幻覺與一致性問題:即使透過結構化輸出與負面約束降低幻覺,模型仍可能在功能判斷上產生不確定或不一致的描述,因此系統結果仍需由分析師進行最終確認。 - 標籤檢索的瓶頸:現階段候選集合主要依賴標籤搜尋縮小範圍,若標籤過於稀疏、同義詞未覆蓋或標籤粒度不一致,可能造成漏召回或候選集合偏大,影響比對效率與準確性。 #### 5.5.2 適用場景分析 本研究提出之 Malware Explorer 以函式層級特徵為核心,目的在於解決實務上惡意程式分析的高重複性、知識難以累積重用、以及傳統規則缺乏語義理解等問題。因此本系統最適用於下列情境,作為情資分析流程中的「輔助定位、輔助歸納與輔助產出」工具: 1. 團隊分析經驗 此場景適用於資安團隊進行日常逆向工程後的知識保存階段。當分析人員完成針對特定函式(如 Shellcode Loader 或解密演算法)的分析後,常面臨分析筆記過於零散、難以標準化的問題。在此情境下,分析師可利用本系統將非結構化的 Pseudo-C 代碼、行為邏輯摘要,與標準化的 YARA 規則及 MITRE ATT&CK 技術編號進行整合錄入。透過此流程,將原本依賴個人記憶的經驗轉化為結構化的團隊資產,便於後續遇到相同特徵時能直接調閱,解決經驗難以傳承與重用的問題。 2. 團隊分析知識 針對分析成果過往多散落於個人筆記或非結構化報告,導致團隊面臨人員流動即造成知識斷層的困境。本系統適用於建構組織內部的核心知識庫,透過將程式碼片段、行為摘要、YARA 規則與 MITRE ATT&CK 編號進行結構化綁定,並建立「特徵—樣本」的雙向索引。此機制確保了每一項分析成果皆能轉化為可被檢索與重用的數位資產,實現分析經驗的長期累積與團隊內部的無縫傳承。 3. 跨維度之特徵與樣本情資關聯檢索 本系統適用於建構完整的威脅情資脈絡。透過導入檢索增強生成(RAG)技術,系統突破了單純比對程式碼的侷限,轉化為整合「特徵知識」與「樣本情資」的綜合分析引擎。利用 AI 模型作為語義橋樑,分析人員可直接針對未知程式碼片段進行跨資料庫的關聯檢索,不僅能精確識別相似的歷史特徵,更能自動連結至所有具備該特徵的關聯樣本。此機制協助分析師從微觀的程式碼分析,快速擴展至宏觀的家族關係判定與威脅脈絡掌握,實現從特徵到情資的深度整合。 ## 第 6 章 結論與未來發展 ### 6.1 研究成果總結 Malware Explorer 成功展示了將 RAG (Retrieval-Augmented Generation) 技術應用於惡意程式分析的可行性與巨大潛力。透過微服務架構整合 LLM 與資料庫檢索,本系統解決了傳統靜態分析中「語義理解不足」與「知識管理碎片化」的難題。實證顯示,系統能將原本耗時的人工比對流程自動化,大幅縮短分析時間,並透過結構化的知識庫實現經驗的有效累積與傳承。這對於資源有限但威脅嚴峻的台灣資安防禦體系而言,提供了一種高效的 AI 輔助解決方案。 ### 6.2 貢獻與創新點 - 提出以函式特徵為核心的惡意程式分析與管理架構 - 將 RAG 實際應用於程式碼語義比對 ### 6.3 未來研究方向 - 自動化特徵提取 - 使用 disassembler + unicorn 執行 byte code 取得 API 序列,搭配反編譯提取 - 整合外部情資資料 - e.g. Virus Total, Malware Barzzar, Any.Run - 社群協作的知識庫 - 利用開源的力量,讓系統更有價值 ## 參考文獻 (References) ## 附錄 (Appendices) ### 附錄 A: 系統操作手冊 ### 附錄 B: API 文件 ### 附錄 C: 資料庫 Schema ### 附錄 D: 實驗數據詳細結果 --- 以下是原始草稿 [toc] :::spoiler 這個大綱比較好 目錄 第 1 章 緒論 ....................................... 1 1.1 研究背景與動機 ................................. 2 1.2 問題陳述 ....................................... 4 1.3 研究目標 ....................................... 5 1.4 系統特色與預期貢獻 ............................. 6 1.5 論文架構 ....................................... 7 第 2 章 文獻探討 ................................... 8 2.1 惡意程式分析流程與挑戰 ......................... 9 2.1.1 傳統逆向工程流程 ........................... 9 2.1.2 知識管理的困境 ............................. 11 2.1.3 新人培訓成本分析 ........................... 12 2.2 威脅情資平台現況 ............................... 13 2.2.1 MISP 與 OpenCTI .............................. 13 2.2.2 VirusTotal 與 Hybrid Analysis ............... 15 2.2.3 商業解決方案 ............................... 16 2.2.4 現有工具的不足 ............................. 17 2.3 RAG 技術在資安領域的應用 ....................... 19 2.3.1 RAG 原理與架構 ............................. 19 2.3.2 向量資料庫與語義搜尋 ....................... 21 2.3.3 LLM 在惡意程式分析的角色 ................... 23 2.3.4 最新研究成果 ............................... 25 2.4 特徵比對與家族歸屬技術 ......................... 27 2.4.1 Yara 規則比對 ............................... 27 2.4.2 行為相似度分析 ............................. 28 2.4.3 MITRE ATT&CK 框架應用 ....................... 29 2.5 研究缺口與本研究定位 ........................... 31 第 3 章 系統設計與架構 ............................. 33 3.1 整體系統架構 ................................... 34 3.1.1 架構設計理念 ............................... 34 3.1.2 資料流程圖 ................................. 36 3.1.3 技術選型決策 ............................... 37 3.2 核心模組設計 ................................... 39 3.2.1 樣本生命週期管理模組 ....................... 39 3.2.2 AI 驅動 RAG 特徵比對模組 .................... 42 3.2.3 統一特徵知識管理模組 ....................... 47 3.2.4 微服務架構與 API 設計 ....................... 50 3.3 資料庫設計 ..................................... 53 3.3.1 Schema 設計 ................................. 53 3.3.2 特徵與樣本關聯設計 ......................... 55 3.3.3 查詢優化策略 ............................... 56 3.4 前端介面設計 ................................... 58 3.4.1 使用者操作流程 ............................. 58 3.4.2 特徵比對結果呈現 ........................... 60 3.4.3 知識圖譜視覺化 ............................. 61 3.5 開發環境與部署 ................................. 63 3.5.1 開發環境配置 ............................... 63 3.5.2 Docker Compose 部署 ......................... 64 3.5.3 CI/CD 流程 .................................. 65 第 4 章 系統實作與關鍵技術 ......................... 66 4.1 RAG 流程實作細節 ............................... 67 4.1.1 特徵提取與標籤生成 ......................... 67 4.1.2 同義詞擴展策略 ............................. 70 4.1.3 SQL 模糊比對與語義搜尋 ..................... 72 4.1.4 LLM 相似度評分機制 .......................... 74 4.2 Prompt 工程優化 ................................. 77 4.2.1 初期 Prompt 設計與問題 ...................... 77 4.2.2 優化策略與效能提升 ......................... 79 4.2.3 幻覺問題處理 ............................... 81 4.3 特徵管理實作 ................................... 83 4.3.1 Yara 規則整合 ............................... 83 4.3.2 MITRE ATT&CK 對應 ............................ 85 4.3.3 多語言程式碼支援 ........................... 87 4.4 系統功能展示 ................................... 89 4.4.1 樣本上傳與分析 ............................. 89 4.4.2 特徵比對演示 ............................... 91 4.4.3 家族關聯展示 ............................... 93 4.4.4 IoC 匯出功能 ................................ 95 第 5 章 實驗與評估 ................................. 97 5.1 實驗環境與資料集 ............................... 98 5.1.1 硬體與軟體環境 ............................. 98 5.1.2 測試資料集說明 ............................. 99 5.2 效能評估 ....................................... 101 5.2.1 分析時間測試 ............................... 101 5.2.2 Prompt 優化前後對比 ......................... 103 5.2.3 系統回應時間 ............................... 105 5.3 準確率評估 ..................................... 107 5.3.1 特徵比對準確率 ............................. 107 5.3.2 家族歸屬正確率 ............................. 109 5.3.3 信心度評分可靠性 ........................... 111 5.4 實際案例分析 ................................... 113 5.4.1 Pseudo C 程式碼比對案例 ..................... 113 5.4.2 Assembly 特徵比對案例 ....................... 115 5.4.3 跨家族相似特徵發現 ......................... 117 5.5 系統限制與討論 ................................. 119 5.5.1 當前限制 ................................... 119 5.5.2 適用場景分析 ............................... 120 第 6 章 結論與未來工作 ............................. 122 6.1 研究成果總結 ................................... 123 6.2 貢獻與創新點 ................................... 124 6.3 未來研究方向 ................................... 125 6.3.1 MOTIF 資料集整合 ............................ 125 6.3.2 自動化特徵提取 ............................. 126 6.3.3 協作式知識庫 ............................... 127 6.3.4 多模態分析整合 ............................. 128 參考文獻 .......................................... 129 ::: # 惡意程式特徵分析與樣本情資整合系統 Malware Feature Analysis and Sample Intelligence Integration System 會用到的參考資料 - [(eset):research APT Activity Report 2024 – March 2025](https://web-assets.esetstatic.com/wls/en/papers/threat-reports/eset-apt-activity-report-q4-2024-q1-2025.pdf) - [Threat Group Cards: A Threat Actor Encyclopedia](https://apt.etda.or.th/cgi-bin/aptstats.cgi) - 台灣位居 Victims 前段班(No. 11) - [2024年威脅態勢回顧: 網路攻擊的模糊地帶](https://teamt5.org/tw/posts/apt-threat-landscape-in-apac-2024/) - 487 個攻擊行動,上生 76 - https://www.ithome.com.tw/news/166623 ## 第一章 緒論 ### 1.1 研究背景 ### 1.2 研究動機 ### 1.3 研究目標 ## 第二章 文獻探討 ### 2.1 惡意程式分析方法 - 什麼是惡意程式分析? - 靜態分析與工具 - 動態分析與工具 - 優缺點比較 refs: - [Malware Analysis Framework - First.org](https://www.first.org/global/sigs/malware/ma-framework/) - [Malware Analysis Explained - crowdstrike.com](https://www.crowdstrike.com/en-us/cybersecurity-101/malware/malware-analysis/) - [Malware analysis for beginners (step-by-step) - hackthebox.com](https://www.hackthebox.com/blog/malware-analysis-guide) ### 2.2 現有 IoC 管理平台 - Virus Total - Malware Bazaar refs: - [Top 10 Malware Analysis Platforms & Tools](https://socradar.io/blog/top-10-malware-analysis-platforms-and-tools/) - [Top 10 Free IoC Search & Enrichment Platforms](https://socradar.io/blog/top-10-free-ioc-search-enrichment-platforms/) ### 2.3 AI 在資安領域的應用 ## 第三章 系統設計 ### 3.1 整體架構 ### 3.2 核心模組詳細設計 - 特徵管理模組 - 樣本管理模組 - 分析模組 ### 3.3 API 設計 ## 第四章 實作與性能評估 ## 第五章 結論 ### 5.1 研究成果 ### 5.2 貢獻與創新點 ### 5.3 限制與未來工作