八支惡意腳本有七支查不到，
因為它們只對特定訪客動手

一個什麼都沒壞的星期天下午

Cloudflare 的原文用一個畫面開場：星期天下午，一位客人用手機逛一家網路商店，點了一個商品。頁面沒有照平常那樣打開，而是在新分頁開了另一個商品頁，原本那個分頁則在背景很快地繞了一圈別人的推廣連結再回來。客人什麼都沒察覺，繼續逛、也許下了單。商店收到訂單，一切正常。

不正常的只有一件事：這張訂單在聯盟行銷的系統裡，被記成「某個推廣夥伴介紹來的」。商店要為一位自己走進來的客人，付一筆佣金給一個什麼都沒做的帳號。

這是 Cloudflare 在 2026 年 9 月 16 日公開的四波惡意 JavaScript 行動之一，iThome 在 9 月 21 日做了中文報導。四波共八支程式，藏在四家不同類型的購物與訂房網站裡。它們有一個共通點：不是對每個訪客都動手。要符合一串條件才會醒來，例如用的是手機、當地時間落在某個時段、是從付費廣告點進來的、連線不是公司網路也不是 VPN。條件不符，它就只是一段什麼都不做的程式。

這件事跟一般「網站被植入惡意程式」最大的差別就在這裡。站方發現不對勁時會做的第一件事，是自己打開網站看一下、或丟給線上掃描服務掃一次，而這兩個動作恰好都不符合啟動條件。Cloudflare 事後拿這八支去比對，七支在 VirusTotal（最多人用的惡意檔案查詢服務）完全沒有紀錄；URLScan（網址掃描服務）則是八支都沒有判成惡意。

先講清楚這份揭露的性質，因為它決定了這篇能走多遠。它是一家資安廠商的研究文章，同時也是它自家偵測產品的成果展示。受害商店全部去識別化，樣本的雜湊值沒有公開，所以「八支裡七支查不到」這句話外人沒辦法重做一次；能自己核對的，是原文貼出來的程式碼節錄、攻擊鏈描述，以及一份 15 個網域的指標清單。下面每個主張會標明是哪一種。

1. 2024-01
   其中一支後門腳本被 URLScan 直接掃過，結果是「沒有分類」
   Cloudflare 原文；該版本在 URLScan 上掛了將近兩年半都沒有被判定。
2. 2024-05-14
   仿冒網域 sdk-amazonaws[.]com 註冊
   本站以 WHOIS 查詢核對（原文只寫 2024 年）；真正的 amazonaws.com 是 2005 年註冊。
3. 2025-03-29
   仿冒網域 adtargett[.]com 註冊，比真的廣告公司網域多一個 t
   本站以 WHOIS 查詢核對；被模仿的 adtarget[.]com 註冊於 1998-11-04。
4. （年份不明）黑色星期五之後
   第一波行動的其中一版被設成暫停
   原文：暫停版的程式裡留有版本註解，寫明「黑色星期五之後暫停」。年份原文沒寫。
5. 未公開
   四家商店實際被植入的起訖時間
   原文沒有提供任何一家的受害期間。
6. 2026-09-16
   Cloudflare 發表研究文章，公開四波行動與 15 個網域指標
   Cloudflare Blog。
7. 2026-09-21
   iThome 中文報導
   iThome 新聞。

時間線上最值得看的不是揭露日，是第一列：那支程式兩年半前就被掃過了，掃描結果是「沒意見」。

發現它的不是商店，是流量經過的那一層

四家商店沒有一家是自己發現的，原文也沒有提到任何一家的客人或推廣夥伴先來反映。發現者是 Cloudflare：這些網站的流量經過它，它的瀏覽器端安全產品會持續看網站實際送給訪客的腳本。

它的做法分兩段。第一段是一個機器學習模型，不把 JavaScript 當成一串文字比對，而是拆成語法結構來看「誰呼叫誰、想藏什麼、最後連去哪裡」，所以程式被壓縮、改名、混淆過也還認得出形狀。被這個模型標成可疑的不到全部分析量的 0.3%，這一小撮再交給一個語言模型做第二次判斷，兩邊一致才通知客戶。偵測是自動的，人只在系統標記之後才進來確認。

到這裡，其實已經足夠理解整起事件：有一類惡意程式專門挑「不會有人在看的時候」才動手，所以偶爾檢查一次沒有用。

如果你關心的是自己的網站該怎麼辦，可以直接往〈如何避免〉繼續讀，中間幾節不看也不影響。如果你想知道這四波各自怎麼躲、公開資料能還原到哪一步，下面開始進入技術拆解。

四波行動，四種躲法

先用白話各講一句。

**第一波，下班後的佣金劫持。**只挑手機訪客、只在特定時段、而且同一台裝置動手一次之後會安靜三到五天。它等客人點商品的那一下，把點擊攔下來，開新分頁讓客人繼續逛，原分頁趁機繞一圈攻擊者的推廣連結，種下「這位客人是我介紹的」的標記。Cloudflare 抓到五個版本，兩個在跑、三個被設成暫停。

**第二波，連點都不用點。**受害的是一家旅遊訂房業者。程式在畫面外面放一個一像素大的隱藏框架，自動載入推廣連結；框架載不起來，就改成自己點一個看不見的連結。它用印度時區的時間、依奇數或偶數小時，在三組推廣設定之間輪替，每組動手後一小時內不重複。

**第三波，舊的廣告軟體改行當後門。**這支程式出自多年前藏在瀏覽器擴充功能裡的 Lnkr 家族，原本的工作是竄改搜尋結果。搬到購物網站之後，舊功能都睡著，醒著的只有兩件事：回報訪客資料，以及向攻擊者的伺服器要新的程式來執行。也就是說，攻擊者之後想讓這家店的客人跑什麼程式都可以，不必再碰網站一次。

**第四波，專挑你花錢買來的客人。**條件最多的一波：要是那一家商店、瀏覽器可視區域的寬度小於 477 像素（也就是手機）、是這次造訪的前兩頁、網址上帶著付費廣告或簡訊行銷的標記，而且連線必須是美國的一般手機網路。公司網路、雲端主機、VPN、代理、Tor 一律不動手，另外還內建一份 325 筆的 IP 黑名單和幾個排除的城市。全部通過之後，它把商店的九個監控與分析工具從頁面上拆掉，把廣告帳號與錄影分析工具換成攻擊者自己的，再把客服聊天與聯絡表單藏起來。

四波放在一起看，結論只有一句：**它們躲的不是防毒軟體，是「會回頭檢查網站的那種人」。**工程師用筆電、在公司網路、直接輸入網址進站，每一項都剛好不符合條件。

接下來這一段會稍微技術一些。你不需要先懂 MITRE ATT&CK（一套把攻擊手法編號的公開分類法），只要先記住一件事：這四波的「進門」那一格，有三波是空白的。

第 01 格的空白值得多講一句。這類事件最想知道的就是「它怎麼進來的」，而原文對三波都誠實地說不知道。

被拿走的不是密碼，是「這個客人算誰的」

這一起沒有傳統意義上的帳號密碼外洩。被動手腳的是幾種平常沒有人當成憑證看的東西：歸因標記、廣告帳號編號、分析專案編號。它們決定的是錢和數據最後流到誰那裡。

最後一列才是一般人以為的「外洩」，而它偏偏是整張表裡唯一沒有證據的一列。

這篇研究沒有回答的三個問題

原文對自己不知道的事寫得很清楚，這是它可信的地方之一。整理起來是三個缺口。

他們怎麼處理：通知，然後公開指標

公開資料能支持的處置只有兩步。偵測模型標記之後，語言模型複核一致就通知客戶，再由人確認；之後 Cloudflare 把去識別化的程式碼節錄、攻擊鏈與 15 個網域指標公開，讓其他網站可以自己比對。

四家商店各自怎麼清除、花了多久、有沒有通知推廣夥伴或客人、有沒有向聯盟網路追回佣金，原文都沒有提。這不是批評，去識別化的揭露本來就不會寫到這一層；只是要記得，這篇研究講的是「怎麼被看見」，不是「怎麼收拾」。

哪裡做對，哪裡做錯

揭露方做對的事不少：把「未觀察到」「無法判定」「未證實」寫在每一波的損失段落裡，沒有把程式碼能做的事說成已經發生的事；特別註明經過代碼管理工具送達不等於那個工具被入侵，也註明 AWS 與被模仿的行銷平台沒有受害；指標全部去武裝化後公開。需要保留的地方是它同時是一篇產品文，「公開掃描服務漏掉、我們抓到」這個對比沒有第三方能重做，而且 VirusTotal 與 URLScan 本來就不是設計來模擬「美國手機用戶從付費廣告點進來」的，拿它們當對照組，對掃描服務不算公平。

受害商店那一側，公開資料看不到他們做錯了什麼，只看得到結構上的弱點，而這個弱點幾乎每一家電商都有：行銷腳本是行銷部門加的，工程部門不審；代碼管理工具的好處就是「不用發版就能加程式」，而這正好也是攻擊者要的。第一波那條路徑上，每一環單獨看都是正常的商業工具。

這一點跟我們自己的兩起事件是同一個形狀。〈排程回報「找不到帳戶」，被停權的是整個專案〉裡，六條訊號都在紀錄裡，沒有一條會自己來找人；這次是程式每天都在跑，但只對不會回報的人跑。〈清單全部打勾的第 13 天〉裡，我們照著位置清單輪替金鑰，漏掉了清單以外的副本；這次是照著「原始碼裡看得到的腳本」檢查，漏掉了代碼管理工具在瀏覽器裡才載入的那些。兩次的教訓一樣：你檢查的那份清單，不是實際在執行的那一份。

如何避免

當天就能做的，是弄清楚你的網站實際載入了哪些外部腳本。不是看原始碼，是打開瀏覽器的開發者工具、切成手機寬度、網址後面加上付費廣告會帶的標記，再看一次網路分頁裡出現哪些網域。把這份清單跟你以為的那一份對一次，對不上的每一個網域都要有人答得出「這是誰加的、做什麼用」。文末的五個步驟就是這件事的唯讀版本。

一個月內補兩件事。第一，代碼管理工具的「發布」權限收斂到兩三個人，開啟容器變更的電子郵件通知，把自訂 HTML 類型的代碼列成清單逐一確認；它等於一個不必經過工程師就能改網站的後台，該用管後台的標準管它。第二，加上只回報不阻擋的內容安全政策（CSP Report-Only）：瀏覽器照常執行所有腳本，但會把實際載入的來源回報給你指定的網址。它最大的價值是回報來自真實訪客的瀏覽器，也就是那些符合啟動條件的人，而不是來自你的辦公室。

這一季要做的是把偵測線拉到營收那一側。聯盟行銷的佣金報表每月跟自家訂單資料對一次，留意點擊到下單時間極短、沒有來源頁的訂單比例；對「付費手機流量的分析回報量」與「客服詢問量」設基準線，因為第四波動手之後，商店看到的不是錯誤，是一片安靜。自己的網頁上有付款表單的商店還有一層義務：PCI DSS（信用卡產業的資料安全標準）4.0 的 6.4.3 與 11.6.1 兩項要求（付款頁上的每支腳本都要經過核可、有清單、能偵測被竄改）自 2025 年 3 月 31 日起已經是強制項目，這份腳本清單遲早要交。付款頁完全交給金流商代管的商店適用較輕的自評問卷，這兩項不在其中，但前提是你能確認自己的網站不會被腳本攻擊影響到付款流程。

台灣的電商用的是同一套堆疊：Google Tag Manager、幾家聯盟行銷網路、工作階段錄影工具。原文的四個案例看起來都在海外，但條件裡的國家、時區、城市只是設定值，換一組就能對準另一個市場。

這篇提到的項目要花多少錢

把文中提到的每個項目攤成成本。攻擊者那一側便宜得不成比例，防守這一側最貴的是人的時間，不是工具。

一個十幾美元的網域，對上的是半個人日的盤點。而且攻擊者那十幾美元可以重複用在很多家商店上，你的半個人日只能保護你自己這一家。

你可以學到什麼

先站到他的位置看一次。偷信用卡號的程式有人在抓，因為持卡人會打電話給銀行；把一張訂單的佣金算到自己頭上，沒有任何人會打電話。客人買到了東西，商店收到了錢，聯盟網路抽到了成，真正吃虧的那位推廣夥伴只會覺得這個月業績差了一點（這一段動機是推測，程式碼只證明它做了什麼）。所以他願意花力氣的地方不是更厲害的攻擊手法，而是更仔細的「什麼時候不要動手」：325 筆 IP、五個城市、三到五天的冷卻。他最怕的不是被擋下來，是被看見。

如果這段程式今天就在你的網站上，你最可能從哪裡先看到它？答案多半不是資安工具，而是一張對不起來的報表。在那之前，下面五步全部唯讀，十五分鐘做得完。指令看不懂沒關係，交給工程師跑，你只要看「代表什麼」那一欄。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。