ShinyHunters回顧：了解哪些應用程式需要抵禦人工智慧驅動的攻擊

某個 Telegram 群組裡可能藏著你公司的金鑰。為什麼？因為人工智慧。也因為很多人不小心把大量機密資訊洩漏到了很多公開發布的應用程式中。 

在2026年9月的威脅情報報告中，Anthropic記錄了一起由一名與ShinyHunters生態系統有關聯的法語操作者發起的憑證竊取行動。該行動的流程運行在十個AWS EC2工作節點上，從多個應用商店來源批量下載了180萬個不同的Android APK文件，對每個文件進行反編譯，並使用TruffleHog掃描輸出結果，以查找硬編碼的密鑰，例如API密鑰、雲憑證和後端令牌。驗證通過的竊取結果會即時路由到Telegram，並進行排序，以便操作者能夠優先處理進入生產系統的憑證。同時，另一個並行流程則用於竊取暴露的GitHub個人存取權杖。 

用Anthropic的話來說，這兩個資料流「為與該攻擊者相關的絕大多數已確認的入侵事件提供了初始存取憑證」。當然，他們的行動遠不止於此！在入侵一家SaaS提供者後，攻擊者又攻擊了該公司約200家下游客戶組織，並在短短34小時內，向40多個企業租戶洩漏了超過2,100個Azure AD令牌集。 Anthropic指出，幾乎所有工作都是由人工智慧代理完成的。哎呀。 

特工們做了什麼？下載。反編譯。掃描。 

沒有使用模擬器，沒有使用實體設備，沒有root權限，沒有使用任何偵測框架，也沒有進行任何形式的執行。事實上，該應用程式根本沒有運行過。這純粹是靜態分析，目的是快速尋找可見的、有價值的數據，重複進行了近兩百萬次。 

了解問題的範圍

這對大多數團隊如何看待行動應用安全來說，是一個令人不安的啟示；而對於我們公司內部如何談論自己的產品，這也是一個誠實的啟示。 Digital.ai運行時保護，例如篡改檢測、root 和越獄檢測、反檢測、RASP 等，固然重要，但在這裡卻完全無關緊要。在應用運行時觸發的防禦措施，對於從未運行過應用的攻擊毫無作用。任何聲稱針對此攻擊活動有效的供應商，都是在兜售對此類情況毫無幫助的產品。 

這也解釋了攻擊規模之大。運行一個應用程式成本很高：它需要一台設備或模擬器、一個可用的帳戶、（有時）登入訊息，以及一個人工來判斷發生了什麼。讀取文件則成本很低。事實上，人工智慧已經將讀取和理解二進位檔案的成本降至幾乎為零，這使得行動團隊多年來一直默默承受的那個問題——「我們的應用程式是否足夠有趣，值得有人費心？」——徹底過時了。沒有人認為這些應用程式值得投入精力。也沒有人努力分配資源。相反，攻擊者會說：“如果我撒一張足夠大的網，肯定能捕到一些有趣的東西。”  

我們早就知道：如果行動應用程式中編譯了長期有效的特權憑證，正確的解決方法是將其移除。特權憑證應保留在伺服器端。讓應用程式進行身份驗證，然後為用戶端實際需要的特定操作頒發有效期短、作用範圍窄的令牌。增加使用配額、應用限制以及經過實際測試的輪換路徑，而不是僅使用運行手冊中的現有路徑。 

任何客戶端保護措施都無法改變這項建議。你發佈到你無法控制的設備上的應用程序，從定義上講，就落入了你所要防範的對象手中。混淆並不能從架構上將客戶端安全地隱藏起來。 safe以及 Digital.ai 它並未聲稱自己有這種行為。 

先跟你的團隊說這些。然後再進行第二次對話，這才是這次活動真正要討論的內容。 

硬化會改變什麼：提取成本 

第二個討論點在於提高提取成本。並非所有金鑰都能明天轉移到伺服器端，二進位檔案中洩漏的某些資訊根本就不是憑證，而且修復漏洞需要花費大量時間，而掃描流程只需幾秒鐘。因此，在考慮如何最有效地利用有限的安全資源時，真正有用的問題不是“我的應用程式是否堅不可摧”，而是“我的應用程式的處理成本是否低廉”。 

這種差異正是此次攻擊機制的核心所在。一個處理 1.8 萬個二進位檔案的管線會優化吞吐量。它不會花二十分鐘去破解第 395,423 號應用程式的保護機制！相反，它會放棄這個應用程序，轉而攻擊其他 1.79 萬個無需任何成本的應用程式。任何將簡單的靜態讀取操作轉換為針對每個應用程式的動態操作的保護機制，都會將你從這個管線中移除。我們常開玩笑說，你不需要比熊跑得快，只需要比同行的人跑得快就行了。在這個例子中，你只需要不要因為是羚羊群邊緣一隻生病或虛弱的羚羊而顯得格格不入。  

能力、它們的作用以及它們為何在此至關重要

字串加密防護－行動應用程式加固（DEX 6.9.1，原生 ARM 16.6.0）將字串字面量替換為運行時解密調用，因此靜態反編譯無法取得任何可讀資訊。它直接繞過了此操作符自動化的靜態字串掃描步驟，並強制執行針對每個應用的動態攻擊——這種攻擊方式無法擴展到 1.8 萬個應用程式。

白盒加密：代理 1.1.1 的憑證透過 `hideAndStore()` 存儲，並透過 `fetchAndUnhide()` 檢索，而不是作為綁定到應用程式包標識和簽章憑證的普通常量存在。它專為保護 API 金鑰和 OAuth 令牌而設計。其彈性超越了靜態提取，可抵禦已 root、越獄和已調試的設備——這比單純的字串加密更進一步。

字串加密是一種建置時配置。白盒加密是開發者有意整合的功能，而不是一個可以隨意切換的標誌——這需要投入大量精力，您可以在這裡了解更多資訊。首先重要的是可能性：僅以加密資料塊形式存在於簽章憑證中的憑證，無法透過 grep 指令找到，也不會被任何以吞吐量為最佳化目標的管線所忽略。 

最後一個問題是：你們團隊中是否有人反編譯了目前的生產版本並閱讀了編譯結果？ 

對大多數組織而言，答案是否定的——並非出於疏忽，而是因為常規工具鏈中沒有任何機制可以揭示這一點。靜態分析讀取原始碼，組合分析讀取相依性。兩者都無法向你展示攻擊者接收到的工件，而這正是此類流水線所能接觸到的應用程式的唯一形式。

找出你頻道裡的內容。然後決定你想在這個管道投入多少精力。 

Digital.ai 應用保護可以幫助團隊降低針對不受其控制的應用進行 AI 輔助逆向工程和篡改的成本。如果您希望立即找到應用程式中隱藏的敏感訊息，請註冊。 免費應用評估 ——或閱讀更多內容 移動應用加固 以及 白盒密碼學

來源

Anthropic，《偵測與因應人工智慧濫用：2026 年 9 月*（威脅群集 GTG-50014）》。產品詳情來自 Digital.ai 行動應用加固（DEX 6.9.1，原生 ARM 16.6.0）和白盒加密：代理 1.1.1 使用者指南。