Ars Technica 於二〇二六年十月二十二日報道，未知攻擊者曾劫持逾三百個 Tor 出口節點，把經 Tor 的 SSH 連線導向其控制的攔截伺服器，並調整出口政策以偏好未加密電郵流量；研究人員掃描約三千個出口節點後確認三百三十三個受影響，攔截端約十二台。來源真實性已對照 Ars Technica 主稿及公開技術細節核實。

Ars Technica：三百三十三個 Tor 出口節點遭劫持——導流 SSH 竊密、偏好明文電郵；約十二台攔截伺服器

Tor 網路依賴志願者營運的出口節點，把加密電路的最後一跳送往公開互聯網。二〇二六年十月二十二日，Ars Technica 引述 Tor 志願者「Kaba」的公開調查指出：攻擊者在約三日期間，把大量出口節點改寫成利於攔截 SSH 與明文電郵的組態；若使用者忽略主機金鑰變更警告並輸入密碼，攻擊者即可竊取憑證、旁觀指令，甚至進一步在目標主機植入 Linux 後門 Ebury。本文已對照 Ars Technica 報道所載時間線、節點數量與技術機制，來源真實性已驗證；攻擊者身分與部分伺服器如何被全面控制，調查仍標示為未解謎題。

一、核心事件：出口節點規模化改寫與 SSH 中間人

時間線與規模

據 Ars Technica，攻擊鏈的初始突破可追溯至八月下旬：攻擊者憑藉被重用的有效密碼進入一台 Tor 管理伺服器，並安裝流傳逾十二年的 Linux SSH 後門 Ebury；其後再從該管理節點連上名為 Switzerland2 的第二台 Tor 伺服器，同樣植入 Ebury，並改寫其所託管的出口節點設定。最終與 SSH／電郵攔截行動相關的出口中繼達三百三十三個；調查人員尚未完整釐清攻擊者如何取得其餘底層主機的控制權。

Kaba 於十月二日對 Tor 約三千個出口節點主動探測，發現三百三十三個會把 SSH 流量導向同一批約十二台攔截伺服器。報道指劫持活躍窗口約為十月二日至五日；其間出口政策被改寫，使經受感染出口的 Port 22 SSH 連線在使用者不知情下被導流。

使用者會看到甚麼

Kaba 描述：若電路剛好經由上述三百三十三個受感染出口之一，一般加密網頁流量仍可「看似正常」轉發；但當嘗試以 Port 22 建立 SSH 時，連線會被導向攔截伺服器。攔截端出示自己的主機金鑰，既有使用者會看到 OpenSSH 的「REMOTE HOST IDENTIFICATION HAS CHANGED」警告；若忽略警告並以密碼登入，攻擊者即可（1）竊取 SSH 密碼；（2）連上真實伺服器並觀察使用者輸入的指令；（3）再開第二條連線，嘗試以 Ebury 感染目標主機。Ars 引述攔截端曾出示的 ED25519 指紋為 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E。

電郵端口策略

第二組改寫封鎖用於多種加密電郵的端口（報道列舉包括 25、465、587、993、995 等），同時繼續允許接收未加密電郵的端口。若郵件服務被迫降級為明文，攻擊者即可憑出口節點存取取得未加密內容；報道亦指目前仍不清楚此類降級嘗試是否曾成功。

二、技術原理：出口政策、主機金鑰與密碼驗證邊界

Tor 出口政策如何被武器化

Tor 客戶端只會經允許目標端口的出口中繼離開網路。攻擊者改寫受控主機上的 torrc 出口政策，使大量節點開放或偏好 Port 22，並調整郵件相關端口組合，從而以「政策層」決定哪些協定會經過攻擊者可觀察或可導流的路徑。這與單純的網站中間人不同：重點在改寫中繼行為，令合法電路仍建立，但特定協定被導向惡意端點。

為何密碼登入特別危險、金鑰登入較難重放

SSH 會把密碼加密傳送到「對端伺服器」；在此攻擊中，對端其實是攔截伺服器，故密碼在驗證當下即可被讀取。攔截端再代為連上真實主機，令互動工作階段「看起來成功」，從而偷窺指令並嘗試後續植入。相對地，以 SSH 公鑰認證時，客戶端簽章綁定該次連線的工作階段識別；為攔截端簽出的簽章無法直接重放到真實伺服器，故金鑰登入難以被同樣手法重放利用。Ars 亦以此對比說明防禦重點：關閉密碼認證、改用金鑰，並嚴肅對待主機金鑰變更警告。

Ebury 與防禦縱深

報道指攻擊者在管理伺服器與 Switzerland2 上使用 Ebury；蜜罐觀察到攔截軟體嘗試登入並安裝與 Ebury 部署形式相符的安裝程式。Ebury 歷史悠久，能在 SSH 守護行程脈絡中收集憑證。調查仍留下多個未解問題：大量伺服器如何被取得控制、攻擊者身分，以及 Switzerland2 為何接受一把在授權金鑰清單中找不到對應證據的 RSA 金鑰。Ars 總結強調防禦縱深：電郵帳戶只接受加密流量並拒絕明文端口；SSH 停用密碼、改用金鑰，並把主機金鑰變更視為可能的中間人事件而非「按一下繼續」。

四、日常應用場景

1. 開發者與技術團隊

經 Tor 或以跳板機管理生產主機的工程師，應假設十月初若曾忽略主機金鑰警告並使用密碼，相關密碼可能已外洩，須立即輪替；全面改為金鑰或硬體金鑰，並為跳板機啟用嚴格的 known_hosts 與證書固定策略。自動化腳本若仍啟用密碼或把同一組管理密碼重用於備份／sudo，正是報道所述初始突破路徑的現實對照。

2. 企業與隱私敏感行業

金融、法律與醫療等行業的運維通道、供應商遠端支援與「隱私瀏覽」場景，一旦混用 Tor 出口與密碼 SSH，風險會由匿名網路的信任假設放大。資安團隊應盤點是否有員工或供應商經 Tor 管理內網資產，並把出口中繼異常、BadExit 類標記與主機金鑰告警納入監控與事件應變劇本。

3. 一般用戶

一般使用者較少經 Tor 登入 SSH，但仍應把「主機金鑰突然變更」視為高優先警告，而不是點擊忽略的提示。使用匿名網路收發郵件時，應堅持加密端口，避免服務端或客戶端降級為明文。

4. 香港與亞洲市場視角

香港企業普遍以雲端跳板、堡壘機與供應商遠端維運支撐跨境業務；密碼重用、明文管理通道與「警告點過就算」的操作慣性，並不限於 Tor。此次事件提醒：即使流量經過看似中立的中繼層，協定選擇與認證方式仍決定攻擊面。本地團隊宜同步檢視堡壘機是否禁用密碼、管理憑證是否分權、以及郵件與遠端桌面是否強制加密——這些與是否使用 Tor 無關，卻是同一套防禦縱深。

五、專業評價與潛在考量

優勢（對防禦方的啟示）

公開探測方法清晰：以固定測試主機比對 SSH 指紋，可規模化找出「導流至第三方」的出口異常。
事件再次驗證「主機金鑰警告」與「停用密碼認證」在真實大規模攻擊中的關鍵價值。
Tor 社群以 BadExit 等機制能在數日內降低受感染出口的可用性，顯示目錄共識與志願者應變仍具作用。

需要留意的地方

三百三十三這個數字來自特定日期的主動掃描；目錄數據分析對「政策吻合」中繼的統計可能更高或口徑不同，讀者不宜把單一數字絕對化。
攻擊者如何控制大部分底層主機、以及是否有更廣的營運商／託管層面入侵，公開報道仍標示為未完全釐清。
電郵降級是否造成實際明文外洩，Ars 稿件保持審慎，尚未當作已證實大規模成功。

結語

三百三十三個 Tor 出口節點在短短數日被改寫成 SSH 與明文電郵的陷阱，說明中繼層信任、密碼認證與「忽略金鑰警告」可以組合成可規模化的竊密路徑。對香港企業而言，重點不只是「有沒有用 Tor」，而是遠端維運是否仍依賴可被重放的密碼、郵件與管理通道是否允許降級，以及告警是否被當成手續而非事故訊號。若需要在香港檢視雲端與跳板機安全基線、加固遠端存取與持續監控，可參考 YSK Limited 的雲端遷移與網絡安全服務：https://ysk.hk/services/cloud-security。

參考來源

Ars Technica：333 Tor exit nodes hijacked to intercept SSH traffic and retrieve plaintext email — https://arstechnica.com/information-technology/2026/10/300-tor-exit-nodes-hijacked-to-intercept-ssh-traffic-and-retrieve-plaintext-email/
Yaamlabs（技術細節交叉核對）：Hijacked Tor exits stole SSH passwords in October — https://yaamlabs.com/blog/tor-exit-relays-ssh-interception
OSINT Sights（掃描與政策改寫摘要核對）：Attackers Hijack 300+ Tor Exit Relays to Intercept SSH Passwords — https://osintsights.com/attackers-hijack-300-tor-exit-relays-to-intercept-ssh-passwords