【資安快訊】2026-11月｜AI 滲透測試代理變攻擊武器！AntiFox 靠有效憑證 30 分鐘摸走 AWS 正式環境金鑰

本文由 耘鼎科技 GERTECH 整理撰寫分享

發布日期：2026/11/13

事件分類：攻擊手法預警

風險等級：High（無 CVE、無 CVSS 評分；等級為本文依已確認的入侵結果所做的判斷）

原始來源：Arctic Wolf Labs｜AntiFox 警示與獵捕資料

本文同時整理 BleepingComputer、The Hacker News、iThome、Help Net Security、Cybersecurity Dive 等 2026/11 的報導，以及 Unit 42、Microsoft、CrowdStrike 被轉述的研究。各項資訊以來源頁面當時的內容為準，見文末免責聲明。

重點整理

• 出了什麼事？ Arctic Wolf Labs 於 2026/11/10 揭露，攻擊者把開源的 AI 代理滲透測試平臺 AntiFox 架在阿里雲上，拿來打對外的網站服務與背後的 AWS 環境。其中一起事件先攻陷公開的 Windows IIS 伺服器、植入 ASPX Web Shell，再用有效的 IAM 憑證與 EC2 角色探索 AWS，約 30 分鐘內切換多個身分、發出數百次 API 請求，並成功讀到正式環境的機密。
• 誰要擔心？ 同時有這兩件事的組織：對外的網站應用程式（這次是 IIS），以及寫在應用程式設定檔裡、或掛在主機角色上的 AWS 憑證。AWS 本身沒有漏洞，AWS 說攻擊者用的是從客戶被入侵的應用程式拿到的憑證。
• 嚴重程度？ 沒有 CVE 可以打分數。已確認的結果是正式環境機密被讀取，另一起事件有 S3 物件被讀取、複製與刪除。這也不是單一事件：AntiFox 的源頭 ARTEX 在一個月內被多家資安業者點名，另一款同類工具 Cairn 也在 11/12 被揭露用於間諜活動。
• 要做什麼？ ① 把 IIS 上的 Web Shell 活動和 AWS 的異常存取放在一起看；② 在一大串「拒絕存取」裡找出少數成功的呼叫，尤其是 GetSecretValue；③ 撤銷受影響的工作階段與金鑰，並更換曾出現在應用程式檔案裡的憑證。

先搞懂幾個名詞

事件摘要

近一個月同類事件時間軸

這類攻擊到底怎麼發生？

Arctic Wolf 看到兩種起點。

第一種，從 IIS 進來。 攻擊者攻陷對外的 IIS 應用程式，透過 IIS 工作行程 w3wp.exe 建立 ASPX Web Shell，接著執行作業系統指令：

1. 用 whoami、icacls 確認自己的身分與權限，並測試能不能把檔案寫進網站根目錄。
2. 用 PowerShell 搜尋 web.config 與其備份，讀出應用程式設定與資料庫連線字串。
3. 列出除錯與錯誤紀錄的目錄，並嘗試用設定檔裡的憑證連內部的正式資料庫。
4. 把設定檔與紀錄複製到可從網際網路存取的上傳目錄，方便取走。

第二種，直接拿著有效的 AWS 憑證進來。 這些憑證怎麼外洩的，目前不清楚。

兩條路最後都走到 AWS。攻擊者先確認身分與權限，再快速探索約 18 項服務，包括 IAM、EC2、S3、Lambda、Secrets Manager、KMS、RDS、EKS、Systems Manager 與 Amazon Bedrock。多數請求回傳 AccessDenied，但部分探索與讀取機密的呼叫成功，至少有一次 GetSecretValue 讀到正式環境的機密。

至於為什麼最近集中爆發，原因在工具。Check Point 觀察到，操作者常常只下一個目標，剩下的交給一整批代理去完成。一個技術有限的人，也能同時對很多目標做偵察與利用。

一長串被拒絕的請求，不代表攻擊失敗。要找的是夾在裡面那幾筆成功的。

可能造成什麼影響

1. 應用程式機密外洩：web.config 裡的資料庫連線字串、API 金鑰與雲端憑證被讀走，並被複製到外部可下載的位置。
2. 雲端正式環境的機密被讀取：Secrets Manager 裡的內容一旦被讀出，影響會延伸到這些機密保護的資料庫與第三方服務。
3. S3 資料被讀取、複製、刪除：另一起事件裡，攻擊者用有效身分執行 GetObject、CopyObject、DeleteObject。刪除代表不只是外洩，還有可用性的問題。
4. 入侵速度超過人工應變：Help Net Security 提到的一個 ARTEX 案例，代理從搜尋 GitHub 到偷走資料只花了五分鐘。

以上是已公開事件裡確認發生的事。受害組織的名稱與數量，Arctic Wolf 沒有公布。

風險評估：到底多危險？

目前仍待確認的三件事

1. IIS 是怎麼被打進去的：Arctic Wolf 沒有辨識出被利用的漏洞。所以不能靠「修某一個 CVE」來排除，要看的是 Web Shell 的痕跡。
2. 有效的 AWS 憑證從哪裡來：部分事件一開始就有有效憑證，來源不明。AWS 的說法是來自客戶被入侵的應用程式，但這不一定涵蓋每一起。
3. 數字與日期在各家報導裡不一致：曝露的 ARTEX 主機，Censys 算 1,465 臺，Check Point 算 2,557 套；ARTEX 轉為閉源的日期，有報導寫 10/08，也有整理寫 11/04。引用時請註明出處，不要混在一起。

修補版本

這次沒有修補版本可以安裝。問題不在 IIS 或 AWS 的某個版本，而是工具被拿來自動化既有的手法。

可以對應到「修補」的，是下面這幾項組態。後四項是 AWS 回應這起事件時提出的建議。

自己檢查：我的機器有沒有問題？

下面是在查檔案與紀錄，不是在測試攻擊。指令是本文依 Arctic Wolf 的描述整理的一般查法；Arctic Wolf 的報告另有獵捕指引與入侵指標，請一併對照。

IIS 主機：找近 30 天新增的腳本檔（路徑請換成實際的網站目錄）

Get-ChildItem -Path C:\inetpub\wwwroot -Recurse -Include *.aspx,*.ashx,*.asmx |
  Where-Object { $_.CreationTime -gt (Get-Date).AddDays(-30) } |
  Select-Object FullName, CreationTime

• 出現你們沒有部署過的檔案，尤其在上傳目錄：當成可能的 Web Shell。
• 上傳目錄裡出現 web.config 的複本或紀錄檔：對應到這次「把設定檔複製到可對外存取的目錄」的手法。
• 端點紀錄裡若有 w3wp.exe 啟動 cmd.exe 或 powershell.exe，再執行 whoami、icacls：正常網站很少這樣做。

AWS：找成功讀取機密的紀錄

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
  --start-time 2026-10-01T00:00:00Z --max-results 50

• 看每一筆的來源 IP 與身分。來自不認得的雲端位址、或平常不讀機密的身分，就要追下去。
• 同一個身分在短時間內對十幾種服務出現大量 AccessDenied，中間夾著幾筆成功：這是這次事件的樣子。
• lookup-events 只涵蓋近 90 天的管理事件。S3 的 GetObject、DeleteObject 屬於資料事件，要先前有開啟資料事件記錄才查得到。

金鑰盤點

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

報告裡可以看到每把長期金鑰的建立時間與最後使用時間。很久沒換、或最後使用的服務與地區不合理的，列為優先。

處置建議

第一階段：已經看到跡象（P0）

1. 先保存證據。把 IIS 紀錄、可疑檔案與對應時間的 CloudTrail 紀錄另存一份，再動手清理。
2. 停用受影響的金鑰，並撤銷角色的既有工作階段。

aws iam update-access-key --user-name <使用者> --access-key-id <金鑰ID> --status Inactive

角色的部分，在 IAM 主控臺對該角色執行「撤銷作用中的工作階段」。

3. 更換所有曾出現在應用程式檔案裡的憑證，包括資料庫密碼與第三方 API 金鑰。被 GetSecretValue 讀過的機密，一律視為外洩。
4. 被植入 Web Shell 的主機，用可信的來源重建。只刪掉那一個檔案，不能證明對方已經離開。

第二階段：還沒看到跡象，但條件符合（P1）

1. 把應用程式設定檔裡的長期金鑰移走，改用主機角色或機密管理服務。
2. 檢視 EC2 角色的權限，移除用不到的服務，並強制 IMDSv2。
3. 啟用 GuardDuty，並對「短時間大量 AccessDenied 之後出現成功呼叫」建立告警。
4. 掃描自家程式碼儲存庫，確認沒有提交過金鑰。

第三階段：長期（P2）

1. 把網站主機的端點紀錄與 CloudTrail 放進同一個調查流程。這次的入侵跨了兩邊，分開看都只看到一半。
2. 內部若使用 AI 代理滲透測試工具，控制臺不要對外開放，並限定可以測試的目標範圍。
3. 演練時把時間壓力算進去：對方的動作以分鐘計，應變流程若要等到隔天上班才啟動，就來不及。

耘鼎觀點

這一波事件容易被看成「又一個新工具」，然後等它退燒。但從 ARTEX 到 AntiFox 再到 Cairn，換的只是名字，走的路是同一條：攻陷對外應用程式、讀設定檔、拿憑證進雲端。這些手法都不新，新的是一個人可以同時對很多目標做，而且每一步之間幾乎沒有空檔。

另一個落差在紀錄的讀法。過去看到一整排 AccessDenied，多半會當成掃描雜訊關掉。這次 Arctic Wolf 特別提醒，成功的那幾筆就藏在裡面。AI 代理不在乎被拒絕幾百次，它只需要成功一次。

• 先問三件事：對外應用程式的設定檔裡有沒有憑證、主機角色能讀到哪些機密、CloudTrail 有沒有人在看。
• 告警要看成功的呼叫，不要只算被拒絕的次數。
• 憑證出現在檔案裡，就當成遲早會外洩。
• 自架的 AI 滲透測試工具本身也是資產，要列入清冊並限制存取。

若網站主機清單和雲端帳號的權限對不起來，耘鼎科技 GERTECH 可以協助清查哪些應用程式帶著雲端憑證、以及這些身分實際能讀到什麼。設定檔裡的金鑰與 CloudTrail 的機密讀取紀錄這兩項，沒有導入服務也可以自己查。

參考資料

• Arctic Wolf Labs｜AntiFox 警示與獵捕資料（原始研究，2026/11/10）
• BleepingComputer｜Hackers use AntiFox AI agents in AWS credential-theft attacks（媒體報導，2026/11/11，含 AWS 回應）
• The Hacker News｜AntiFox AI Pentesting Platform Linked to Attacks That Accessed AWS Production Secrets（媒體報導，2026/11/11）
• Security Affairs｜AI Pentest Tool AntiFox Abused To Steal AWS Credentials（媒體報導，2026/11/11）
• Help Net Security｜ARTEX goes from pentesting tool to attacker staple in three months（媒體報導，2026/11/09）
• Cybersecurity Dive｜Agentic pen-testing tool employed in multiple espionage campaigns around the globe（媒體報導，2026/11/02）
• Security Boulevard｜Attackers are Using Agentic AI Offensive Tools to Automate Intrusions（媒體報導，2026/11/12）
• SOCRadar｜ARTEX AI Pentest Tool: What Security Teams Need to Know（廠商整理，2026/11/04）
• Bright Defense｜Attackers Abuse Cairn AI Penetration Testing Tool（轉述 Unit 42 研究，2026/11/12）

延伸閱讀

• 【資安快訊】2026-11月｜Linux 驚爆危機！OpenSSH 「SSHhole」漏洞 CVE-2026-123158 靠超長密碼秒攻破
• 2026-11月 CVE-2026-98432 Linux 核心 TCP 重大 漏洞警報！

---

本文依據 Arctic Wolf Labs 2026/11/10 報告的公開轉述，以及上列媒體於 2026/11 的報導整理。Unit 42、Microsoft、CrowdStrike 的內容為第二手轉述，引用前請對照原始報告。檢查指令為一般查法，不代表 Arctic Wolf 的獵捕規則。

© Gertech 耘鼎科技 資安情資分享

想進一步討論這個主題？

歡迎來電 02-2748-8522，或填寫諮詢表單，由耘鼎顧問與您聯繫。

預約諮詢 →