Windows Malware Development：技術鏈與逆向註解

先把 Malware 看成一條行為鏈

只看單一 hash、domain 或 API 很容易誤判。較完整的模型是把樣本拆成多個階段，再為每一階段建立 artifact、telemetry 與假設：

Delivery / Staging
  → Execution / Loader
    → Discovery / Privilege Context
      → Persistence
        → Defense Evasion
          → Credential / Collection
            → Command and Control
              → Actions on Objectives

實際樣本不一定包含全部階段，也可能把不同功能拆到多個 processes、services 或 modules。分析目標不是替樣本貼一個家族名稱，而是回答：它做了什麼、在什麼條件下做、留下哪些可重現證據、我們能在哪一層阻止或偵測。

建立安全、可重複的分析環境

最低隔離要求

• 專用 VM，不使用日常工作帳號與真實瀏覽器資料。
• 分析前建立 snapshot，樣本與工具版本記錄在 case notes。
• 預設斷網；需要觀察流量時使用模擬 DNS／HTTP 服務或嚴格受控出口。
• 關閉 host integration、shared clipboard、shared folders 與不必要的 USB passthrough。
• 從乾淨基線產生 file、registry、service、scheduled task 與 process 差異。
• 所有時間來源統一，保留 timezone 與 clock drift 資訊。

證據處理

對每個樣本至少記錄：原始檔 SHA-256、取得來源、取得時間、檔案大小、簽章狀態、分析 VM build、工具版本與每次執行的命令列。原始樣本應設為唯讀保存；衍生檔、unpacked image、memory dump 與報告分開雜湊。

Triage：先決定從哪裡深入

1. 檔案與 PE 結構

第一輪的目的不是「靜態分析就定罪」，而是產生待驗證假設。例如 .text 很小、某高 entropy section 很大、imports 只剩幾個 loader API，可能表示執行時會解包；下一步就應在 entry point、memory protection change 與新 executable region 之間建立關聯。

2. Strings 與 configuration

將 strings 分為四類比全部丟進 IOC 清單更有效：

1. 功能字串：API、錯誤訊息、format string。
2. 基礎設施：domain、URI pattern、user-agent、certificate metadata。
3. 主機 artifact：mutex、pipe、service、task、registry path、file path。
4. 編譯 artifact：PDB path、language runtime、library signature。

需要確認字串是「真的被引用」還是未使用資料。加密 blob 則先辨識 framing：版本、長度、nonce、key identifier、compression marker 與 checksum；不要一看到 XOR loop 就假定所有資料使用同一 key。

Execution 與 Loader：觀察狀態變化

Loader 的本質是把某種 representation 轉成可執行狀態。防禦者不需要複作 loader，也能從狀態轉換辨識它：

輸入 bytes
  → allocation / section mapping
  → copy / decompress / decrypt
  → relocation 與 import resolution
  → protection transition
  → control transfer

正常 Windows loader 會建立 image mapping、處理 imports、TLS 與 loader bookkeeping。自訂 loader 或 reflective loading 可能產生不同 footprint，例如 executable private pages、PE-like bytes 不在 module list、thread stack 回到未命名 region，或 image mapping 與 disk file 不一致。

Memory region 的五個問題

對每段可疑記憶體依序問：

1. 它從哪裡來？ Allocation、section map、image load 或 copy-on-write？
2. 誰寫入？ 本 process、另一 process、kernel component 或 debugger？
3. Protection 如何變化？ RWX、RW→RX、image-backed executable 或 guard pages？
4. 誰執行？ Existing thread、new thread、APC、callback 或 exception path？
5. 內容像什麼？ PE、shellcode-like code、JIT code、decompressed config 或純資料？

int values[4] = { 10, 20, 30, 40 };
int a = 0;

values[a]     → 10
*(values + a) → 10
&values[a]    → 0x100040

API Resolution 與 Hashing：從分析角度還原

部分樣本不保留敏感 API 明文，而是在執行時走訪 export table，以 hash 或自訂比較函式選出目標。分析重點不是背某個 hash 常數，而是辨識 resolver 的輸入、正規化規則與輸出。

hash = seed
for each byte in export_name
hash = rotate_or_mix(hash, byte)
compare hash with constant
return resolved address

Resolver 還原流程

1. 找到遍歷 export directory 的 loop。
2. 記錄 module selection、name normalization 與 hash width。
3. 用獨立腳本對合法 DLL exports 批次計算。
4. 對 collision 保留所有候選，不要過早命名。
5. 依 call-site 參數、回傳用途與動態 trace 確認函式。
6. 將確認後的名稱回填 IDA/Ghidra，重跑 call graph 與 capability grouping。

這種方法也適用於 syscall wrappers、COM method table 與動態載入的 runtime symbols。

Process Injection：技術家族與證據鏈

MITRE ATT&CK 將 Process Injection 歸為 T1055，並拆成 DLL injection、PE injection、thread execution hijacking、APC、process hollowing 等子技術。不同實作共享的高階序列通常是：取得目標 process、把 code／data 放進其 address space、讓目標 execution context 使用它。

為什麼單一 API rule 不夠？

Debugger、accessibility software、security products、game overlays 與管理工具都可能跨 process 開 handle、讀寫記憶體或建立 thread。反之，攻擊者可用不同 native mechanisms 達成相同狀態。因此可靠偵測應聚合：

• Source process reputation、signer、integrity 與 parentage。
• Granted access 與 target sensitivity。
• Target memory region 的 type、protection 與 provenance。
• Execution 是否落在合法 loaded image。
• 前後是否伴隨 credential access、persistence 或 network beacon。

Persistence：看「自動啟動關係」而不是只背位置

Persistence 的共同目標是建立「某個 trigger 發生時，自動啟動攻擊者控制內容」的關係。可依 trigger 分類：

Autoruns 很適合做 cross-location inventory，但「有自動啟動項」不等於惡意。應回到 owner、change time、binary signer、command line、parent process 與 deployment context。

Defense Evasion 與 Anti-Analysis

常見樣本會延遲、分階段或條件式啟動。分析時把 evasive behavior 當成可量測條件：

• Sleep / timer：比較 wall-clock、CPU time 與 timer objects。
• Environment checks：記錄被查詢的 process、device、registry、firmware 與 system metadata。
• Debugger checks：觀察控制流程分支，不急著修改所有 check。
• Packing / obfuscation：找資料何時轉為 code、何時出現穩定 configuration。
• Telemetry tampering：驗證 provider／module state 與 clean baseline 差異。
• Unhooking / module replacement：比較 in-memory image、disk image、relocations 與合法 hotpatch。

最有價值的結果不是「成功騙過檢查」，而是列出每個 gate 的條件、true/false 路徑與它控制的 capability。這讓 sandbox 與 hunting team 能建立多組環境覆蓋不同分支。

Dynamic Analysis：建立時間線

將事件按照時間而非工具分類，可以避免各看各的：

T0  sample process created
T1  configuration / embedded resource read
T2  child process or target process opened
T3  memory allocation / mapping / write
T4  protection or thread context changed
T5  persistence artifact created
T6  DNS / network connection
T7  file cleanup or process termination

每個事件至少保留：timestamp、source PID/TID、target object、operation、result、stack 或 caller module（若有）、相關 hash/path 與收集來源。不同 telemetry 的 clocks 與 buffering 會造成順序偏差，因此保留原始時間與 correlation key。

Sysmon 能回答什麼？

Microsoft 將 Sysmon events 定位為 behavioral building blocks，而不是自動等於 alerts。常用關聯包括：

Network 與 C2 分析

不要只抽 IP/domain。完整 network profile 應包括：

• DNS query pattern、TTL、fallback 與 failed resolutions。
• Connection interval、jitter、session duration、bytes in/out。
• HTTP method、URI shape、header order、user-agent consistency。
• TLS SNI、certificate、ALPN、version 與可用的 fingerprint。
• Proxy awareness、system proxy 使用方式與 credential context。
• Request/response framing、message type、sequence number 與 retry logic。

對 encrypted traffic，重點通常是 metadata 與 endpoint behavior。若在授權 lab 中能從 process memory 或 instrumentation 取得 pre-encryption data，應清楚標記取得點與 chain of custody，不要把解密後內容誤當 wire bytes。

逆向註解：讓分析結果可以交接

我會把註解分成五層：

1. Semantic：函式真正做什麼。
2. State：輸入、輸出、global state 與 object lifetime。
3. Capability：這段支援哪個能力或 ATT&CK behavior。
4. Evidence：判斷依據與尚未確認的假設。
5. Detection：可在 endpoint、memory 或 network 哪裡觀察。

建議命名帶上信心程度，例如 decrypt_config_probable、resolve_api_hash_confirmed，而不是一開始就命名成特定 malware family。重要結構應還原 field offset、size、encoding、ownership 與使用點；call graph 上則標記 dispatcher、parser、crypto wrapper、transport 與 task handlers。

Function summary 範本

Name: parse_config_confirmed
Inputs: blob pointer, blob length
Outputs: validated config object or error
Side effects: allocates heap object; updates global campaign id
Evidence: 4 call sites; length checks; decoded fields consumed by network init
Open questions: field 0x24 meaning; optional extension after version 3
Detection value: mutex format and URI path become stable after this stage

從 IOC 提升到 Detection Engineering

高品質 detection 應包含 positive logic、known-good exclusions、required telemetry、performance cost、test corpus、預期 false positives 與失效條件。Rule 命中後要能告訴 analyst 下一步收集什麼，而不只是顯示「suspicious」。

報告應回答的問題

一份完整 malware report 至少要能回答：

1. 樣本身分與分析環境是什麼？
2. 執行需要哪些條件，哪些 branch 尚未覆蓋？
3. Capability 與 execution chain 是什麼？
4. 建立、修改或存取了哪些 objects 與 artifacts？
5. Memory、persistence 與 network 證據如何互相支持？
6. 哪些判斷已確認，哪些仍是推測？
7. 可立即封鎖什麼、可長期偵測什麼？
8. 清除後如何驗證沒有殘留，何時應直接重建主機？

常見誤區

• 看到 high entropy 就說加密：壓縮與媒體資料也可能高 entropy。
• 看到 RWX 就說 injection：需要 writer、executor 與 provenance。
• 只收 IOC、不寫行為鏈：IOC 很快失效，分析價值無法延伸。
• 把 sandbox 沒行為當安全：可能是條件未滿足、延遲或 telemetry 缺口。
• 依 process name 判斷合法：要看 path、signer、token、parent、memory 與行為。
• 將 ATT&CK technique 當檢測規則：ATT&CK 是行為分類，仍需具體 telemetry 與 analytic。
• 修改樣本太早：Patch 可能改變控制流程，使原始行為與報告失去一致性。

延伸閱讀

• MITRE ATT&CK：Process Injection — T1055
• Microsoft Learn：Understanding Sysmon events
• Microsoft Learn：Sysmon overview
• Microsoft Learn：Virtual Address Space
• MITRE：Cyber Analytics Repository

最終目標不是「重現攻擊者的每一行程式碼」，而是把 execution、memory、persistence 與 network 轉成可驗證、可交接、可偵測的證據鏈。