HAProxy 執行檔遭植入後門：後端日誌為何可能毫無痕跡

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-07

Rapid7 發現一套針對南韓媒體及汽車業的 Linux 攻擊工具，其中名為 Ted 的後門被編入 HAProxy 負載平衡器。iThome 報道指出，遭竄改的程式表面仍可如常分流網站流量，卻可在代理層截取 HTTP 連線、蒐集登入工作階段 Cookie、執行遙距指令，並按目標訪客改寫網頁回應。對使用 Linux、反向代理及雲端架構的團隊而言，這類事件的重點不在於網站有否停擺，而是入口層一旦失守，正常服務表現可以掩蓋風險。

目前沒有資料顯示香港機構受影響，也沒有證據證實入侵者是利用 HAProxy 漏洞植入後門。iThome 引述 Rapid7 的分析稱，研究人員把部分基礎設施及攻擊手法與北韓相關活動連繫起來，但現有證據不足以把行動明確歸屬 APT37 或 Lazarus。因此，較準確的說法是，這是一宗高度針對性的程式竄改個案；現有資料未足以確認最初入侵途徑。，而非把所有 HAProxy 部署直接視作已知漏洞受害者。

攻擊者把控制通道放在流量入口

iThome 報道稱，攻擊者以 HAProxy 2.8.12 重新編譯惡意版本，把 Ted 直接嵌入程式，並借用 HAProxy 原有的 HTTP 處理能力介入流量。當控制端向指定網址發出請求，後門可在負載平衡器內接收指令，上傳、下載檔案或執行系統命令，而該請求不會再送往後端網站。換言之，原本用作保護、分流及統一管理入口流量的組件，反過來成為攻擊者與受害環境之間的中繼點。

這亦解釋為何只查後端 web server 的 access log 未必足夠。若惡意請求止於 HAProxy，後端日誌自然不會留下相應路徑、來源 IP 或狀態碼；iThome 又指出，Ted 可改動 HAProxy 的連線及流量統計，減少控制操作在監控數字上的異常。這並不代表日誌失去價值，而是其可見範圍有清楚邊界：它記錄到達後端的內容，不能自動證明入口代理曾經接收過甚麼、又丟棄了甚麼。

對登入安全的影響在於「選擇性」

Ted 的另一項能力，是按來源 IP、到訪網址、引薦頁面及瀏覽器資訊篩選訪客，對特定對象插入惡意網頁內容，同時蒐集登入 Cookie。這種做法的危險之處，在於攻擊者毋須向所有訪客展示異常畫面；大部分用戶和網站管理員看到的頁面仍然正常，只有被挑選的帳戶、員工或合作夥伴收到被改寫的回應。從防禦角度推論，單靠一般用戶回報、全站截圖或抽樣瀏覽測試，未必能覆蓋這種按條件觸發的行為。

報道亦提到，研究人員在相關環境找到 curlRAT、SSH 密碼竊取元件，以及被修改的 Linux 系統服務。負責安裝惡意程式的部分會調整檔案時間，並刪除系統日誌中的部分記錄，以淡化安裝痕跡。這些發現顯示調查範圍不宜局限於單一 HAProxy 設定檔或代理日誌；一旦懷疑入口層被竄改，應同步審視主機上的服務、程序、帳戶憑證與其他異常元件，才較有機會串連完整時間線。

核對工作可從四個層面入手

iThome 指出，Rapid7 建議管理員除檢查負載平衡器日誌外，亦要比對網絡流量、檢查 RAM 內的異常活動，以及確認系統執行檔有否被修改。實務上，團隊可把這理解為四組需要互相驗證的證據：官方或受信任建置來源的二進位檔與雜湊值、運行中 HAProxy 程序及其載入狀態、代理主機實際看到的入站及出站流量，以及套件安裝、設定管理和部署紀錄。任何一項單獨正常，都不足以排除其餘層面的問題。

對採用自動化部署的團隊，這事件也帶出一項流程問題：部署紀錄應能回答「此刻執行的是哪個建置產物、由誰批准、從哪個受信任來源取得」，而不只記錄設定有否成功套用。將已核實的 HAProxy 二進位檔、版本及雜湊納入資產清單，保留套件來源與變更審批紀錄，再把代理流量遙測與後端 access log 放在同一時間軸比對，可令日後調查不必完全依賴可能被避開或修改的單一資料源。這類控制未必可即時阻止入侵，但能縮短發現異常和界定影響的時間。

下一步是把代理層納入偵測範圍

對網站、app API 與內部系統共用入口代理的營運者，優先工作可放在確認實際運行檔是否來自受信任發布或既定建置流程，並檢視代理主機有否不合理的外連、陌生服務改動或流量與後端紀錄不一致的情況。如發現懷疑遭竄改的二進位檔或程序，應按既有事故應變程序保全證據、限制影響範圍，並評估涉及的登入 Cookie、SSH 密碼與管理憑證是否需要輪換。未來最值得觀察的是 Rapid7 能否補充最初入侵途徑，以及其他研究能否辨識相同竄改版本；在此之前，把 HAProxy 視為需要獨立監察的安全邊界，會比只相信後端日誌更穩妥。