CAI 雲端蠕蟲專攻公開管理介面，Docker、Kubernetes 同 Ray 要即刻查

黑吃黑夠搶眼，入口先值得急查

攻擊者喺一部俾人入侵咗嘅 server 入面趕走其他惡意程式，聽落好似幫機主清垃圾，實情係 CAI 想霸住算力同偷返嚟嘅憑證。TechNews 科技新報報道，呢套由中央 C2 控制嘅 botnet 會掃描 Docker、Kubernetes、Redis、etcd、Kubelet 同 Ray，成功闖入後放低挖礦程式、憑證竊取工具同 Python 後門，亦會終止 TeamPCP、PCPJack 等對手嘅 process。

公開證據要分清楚。The Register 引述 Hunt.io 研究員話，團隊喺 6 月 15 日發現相關開放目錄，之後三星期睇住操作者由試 code 走到實際入侵；C2 紀錄同加密貨幣錢包活動亦令研究員相信已有多次成功個案。不過暫時冇公開受害機構名單、地區分布或香港個案，實際規模仍然未清楚。

個名撞咗，LLM 輔助亦未坐實

今次 CAI 係「Cloud AI Infrastructure Attack Framework」嘅簡稱，同 Alias Robotics 維護嘅開源 Cybersecurity AI 框架冇已知關係，搵資料時好容易撈亂。Hunt.io 只係按程式碼風格同註解判斷，認為開發過程可能用過 LLM；呢點屬研究員推斷，未有模型紀錄、開發者身份或其他獨立證據支持，唔應寫成 AI 已經自動整出成套蠕蟲。

管理工具一公開，權限本身已經夠危險

暫時公開資料冇列出完整 CVE 或受影響版本表，所以單靠更新版本未夠。Docker API 可以建立容器同掛載主機檔案，Docker 官方直指控制 daemon 嘅人有機會攞到主機 root 權限；Kubernetes API、Kubelet 同 etcd 就掂到 workload、Secret 同叢集狀態。Redis 原本預咗只俾可信環境使用，而 Ray 官方文件更寫明，任何人一旦掂到 Dashboard、Jobs 或 Client 相關連接埠，都可能喺叢集執行任意程式碼。呢類控制面一旦冇做好身份驗證同存取限制，攻擊者唔使等新 zero-day 都可能入到嚟。

第一輪先查清楚有咩露咗出街

由自家資產清單開始查。 對照雲端 security group、防火牆、load balancer、NAT、Kubernetes Service 同主機 listen socket，搵出邊啲管理服務可由公眾網上連入。常見預設連接埠包括 Docker 2375／2376、Redis 6379、Kubernetes API 6443、etcd 2379／2380、Kubelet 10250 同 Ray Dashboard 8265；團隊改過連接埠亦要一併查，唔好見預設號碼冇開就當安全。測試範圍應該限於自己獲授權管理嘅資產。

跟住收窄存取同補身份驗證。 Docker remote API 最穩陣係留喺 Unix socket，真係要遙距用就經 SSH、VPN 或雙向 TLS，兼只放行可信來源。Redis 官方安全指引建議用防火牆、指定 bind 介面、ACL、TLS 同 protected mode；Kubernetes 就要開 TLS、RBAC、Kubelet authentication／authorization、audit log，etcd 只准 API server 經雙向 TLS 存取。Ray 2.52.0 起支援 token authentication，不過官方都講明 token 只係多一層防線，叢集仍然要限制可信來源先連得入，亦要做好反向代理驗證。

有懷疑就當憑證可能已經走咗

如果管理介面曾經公開，又或者見到可疑 API 操作，先隔離相關主機同叢集，保存 audit log、程序資料同磁碟 snapshot，再喺乾淨裝置撤銷及輪換雲端 API key、kubeconfig、client certificate、service account token、container registry、CI/CD、SSH、Redis 同 Ray 憑證。優先處理可建立資源、讀 Secret 或改 IAM 權限嗰批身份，亦要取消舊 token，淨係改設定檔冇用。Kubernetes 安全指引亦建議縮短憑證壽命、定期輪換同保留 audit log。受污染節點最好用可信 image 重建；淨係刪走 miner，唔足以確認部機已經乾淨。

入侵跡象要跨幾層一齊睇。 主機突然長期食盡 CPU 或 GPU、雲端帳單急升、陌生 container／Pod／Job／image、可疑 Python process、systemd service 或 cron、異常外連同挖礦流量，都值得即刻追。控制面方面要查陌生來源呼叫 create、exec 或讀取 Secret、新增高權限 RBAC、service account、雲端 key，同 Redis 或 Ray 出現未經變更程序批准嘅操作。CAI 會清走其他惡意 process，所以某個已知 miner 消失，亦唔代表部機乾淨咗。

CAI 呢單最實際嘅提醒係：開發同 AI 團隊要把管理介面當高權限入口管。團隊應該先查清楚有咩資產外露，再補好存取限制、身份驗證、audit log 同憑證輪換，唔好等下一份惡意 IP 或錢包清單出現先郁手。

參考來源

• TechNews 科技新報 — 駭客圈上演黑吃黑，新型蠕蟲 CAI 清剿同行強占算力 — original report
• Michael R：CAI 初步披露 — Hunt.io 研究員公開講述目標服務同清除競爭惡意程式嘅行為
• The Register：CAI cloud worm investigation — 載有 Hunt.io 研究員訪問、發現時間線、入侵成效同 LLM 輔助開發判斷
• Docker Engine security — 核對 Docker daemon API 權限、TLS 同可信網絡要求
• Kubernetes：Securing a Cluster — 核對 API、Kubelet、etcd、audit log 同憑證輪換建議
• Redis Security — 核對 Redis 公開連線風險、ACL、protected mode 同網絡限制
• Ray Security — 核對 Ray Dashboard、Jobs 同 Client 可執行程式碼嘅權限風險
• Alias Robotics：Cybersecurity AI — 確認同名 CAI 開源資安框架身份，避免同今次惡意框架混淆

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。