一個Linux后門在VirusTotal上的檢測數(shù)：0。不是低，是零。

Breakglass Intelligence的最新分析顯示，APT41正在用一款全新的Winnti家族后門，把AWS、Google Cloud、Azure和阿里云的Linux實例變成長期潛伏的憑證盜竊節(jié)點。這不是傳統(tǒng)意義上的"入侵后勒索"，而是更隱蔽的"寄生式"運營——留在里面，慢慢吸血。

檢測率歸零：傳統(tǒng)防御在云原生威脅面前的失靈

這款ELF格式的植入程序?qū)ｉT針對Linux工作負載設(shè)計。Breakglass的分析報告指出，樣本在報告發(fā)布時沒有任何安全引擎標記。零檢測意味著什么？意味著它通過了幾乎所有主流殺毒軟件的靜態(tài)分析，意味著它看起來"足夠正常"。

APT41選擇了一條阻力最小的路徑。沒有漏洞利用的噪音，沒有勒索軟件的倒計時彈窗，只有對云實例元數(shù)據(jù)服務(wù)的安靜遍歷。這種策略的核心假設(shè)很簡單：云環(huán)境的復雜性和規(guī)模本身，就是最好的掩護。

云原生安全工具通常專注于容器運行時、Kubernetes審計日志或網(wǎng)絡(luò)微分段。但一個偽裝成正常系統(tǒng)進程、只讀取本地配置文件的后門，往往處于這些防御層的縫隙之中。

SMTP端口25：一個被低估的隱蔽通道

這款后門的命令與控制（C2）設(shè)計頗具巧思。它沒有選擇HTTPS這類常見渠道，而是利用SMTP協(xié)議通過25端口通信。

這個選擇經(jīng)過精心計算。郵件流量在很多云網(wǎng)絡(luò)中受到較弱的出口過濾，安全團隊往往更關(guān)注443端口的異常連接，而對25端口的"正常業(yè)務(wù)郵件"放松警惕。后門把C2流量偽裝成郵件傳輸，實際上是在利用防御優(yōu)先級的心理盲區(qū)。

通信目的地是一組阿里云新加坡節(jié)點上的域名。這些域名采用阿里云的拼寫變體（typosquat），從網(wǎng)絡(luò)流量視角看，很容易被歸類為"區(qū)域內(nèi)正常業(yè)務(wù)往來"。

基礎(chǔ)設(shè)施的籌備同樣顯示出專業(yè)度。攻擊者在24小時內(nèi)通過NameSilo注冊商批量注冊了三個域名，分別冒充阿里云和中國網(wǎng)絡(luò)安全品牌奇安信（Qianxin），全部啟用了WHOIS隱私保護。這種緊湊的時間窗口和品牌模仿策略，是APT41的典型指紋。

代碼層面的關(guān)聯(lián)更加確鑿。Breakglass的分析將這款后門與早期Winnti家族的ELF植入程序PWNLNX和Linux版KEYPLUG建立了譜系聯(lián)系，完成了對APT41的歸因。

四云通吃：一套代碼遍歷所有主流憑證存儲

這款后門的核心模塊是一個系統(tǒng)化的云憑證收割引擎。它對每個主流云平臺的元數(shù)據(jù)服務(wù)和本地憑證存儲路徑都有針對性實現(xiàn)。

在AWS環(huán)境中，后門查詢169.254.169.254實例元數(shù)據(jù)端點提取IAM角色臨時憑證，同時讀取~/.aws/credentials文件中的長期訪問密鑰。GCP環(huán)境下，它從元數(shù)據(jù)服務(wù)器獲取服務(wù)賬戶令牌，并檢查應用默認憑證（ADC）配置。Azure場景中，后門從IMDS端點拉取托管身份令牌，并掃描~/.azure目錄下的配置文件。

阿里云作為攻擊者基礎(chǔ)設(shè)施的托管方，同樣沒有逃脫針對。后門專門提取ECS實例元數(shù)據(jù)中的RAM角色憑證，并檢查本地阿里云CLI的配置文件。

這種"全平臺覆蓋"的設(shè)計反映出APT41對多云環(huán)境的深刻理解。現(xiàn)代企業(yè)很少鎖定單一云廠商，攻擊者需要為各種混合架構(gòu)做好準備。一個后門解決所有場景，比針對每個環(huán)境定制工具更具運營效率。

收集到的憑證和配置秘密被用于橫向移動，深入云環(huán)境的更深層級。擁有有效的IAM角色憑證，意味著攻擊者可以發(fā)起新的API調(diào)用、創(chuàng)建額外資源、甚至建立更持久的訪問路徑——而這一切在日志中看起來都像是"正常"的自動化操作。

云安全的認知差：我們還在用主機時代的思維防御

這起 campaign 暴露出一個結(jié)構(gòu)性問題：云工作負載的安全模型仍在追趕實際威脅的演化速度。

傳統(tǒng)端點檢測與響應（EDR）工具的設(shè)計假設(shè)是"惡意軟件會表現(xiàn)出異常行為"——內(nèi)存注入、進程 hollow、注冊表修改。但這款Winnti后門的行為模式高度克制：讀取本地文件、發(fā)起出站SMTP連接、偶爾查詢元數(shù)據(jù)端點。這些操作在單個云實例的日常活動中并不突兀。

元數(shù)據(jù)服務(wù)本身是一個設(shè)計上的便利功能，讓實例無需硬編碼憑證就能獲取臨時權(quán)限。但這個便利也成為攻擊者的捷徑。169.254.169.254這個鏈路本地地址，在AWS、Azure、GCP、阿里云的設(shè)計中功能相似，攻擊者可以用幾乎相同的代碼邏輯遍歷所有目標。

防御方的應對需要重新校準。實例元數(shù)據(jù)服務(wù)的訪問需要更嚴格的監(jiān)控，特別是非預期進程發(fā)起的查詢。出口流量分析應當覆蓋"看起來正常"的協(xié)議，SMTP、DNS、甚至NTP都可能被濫用為隱蔽通道。憑證的生命周期管理需要縮短輪換周期，降低被盜憑證的窗口價值。

Breakglass Intelligence的發(fā)現(xiàn)時機值得注意。在報告發(fā)布時，這個樣本仍然是零檢測狀態(tài)。這意味著它可能已經(jīng)在某些環(huán)境中潛伏了相當時間，而安全團隊對此一無所知。

APT41的這次操作展示了一種"基礎(chǔ)設(shè)施即目標"的新范式。云服務(wù)器不再只是托管應用的計算資源，而是身份和訪問管理的樞紐。控制了一個云實例，往往意味著獲得了通往整個組織云資產(chǎn)的跳板。

攻擊者把云廠商的互操作性設(shè)計變成了自己的便利工具。多云策略本是為了避免供應商鎖定，卻也為跨平臺憑證盜竊創(chuàng)造了統(tǒng)一的技術(shù)接口。這種諷刺性的反轉(zhuǎn)，正是云安全領(lǐng)域最棘手的挑戰(zhàn)之一。

當檢測率從零開始上升時，還有多少類似的植入程序仍在靜默運行？