部落格

漏洞揭露量持續增加，但真正遭攻擊者利用的只占極少數。根據 Google Threat Intelligence Group（GTIC）統計，2026 年每月揭露的漏洞數量從 1 月的 5,045 個增加至 8 月的 10,740 個，成長超過一倍，但實際遭利用的僅占 0.23%[1]。 雪上加霜的是，在漏洞公開後，資安團隊的反應時間卻越來越短。根據 VulnCheck 統計，從漏洞公布到確認遭利用的時間中位數，從 2025 年的 120 天，到 2026 上半年，已縮短至 80 天，少了近三分之一的時間[2]。面對日益增加的漏洞與更短的反應時間，光是找出漏洞已不能滿足資安團隊真正的需求，而是如何更快辨識哪些風險需要優先關注。 而要做出這項判斷，單看漏洞數量或嚴重度並不夠。這些資訊能反映系統弱點與潛在衝擊，卻無法說明攻擊者是否正在利用某項漏洞、如何利用，以及可能留下哪些痕跡。當漏洞清單不斷增加，這些來自實際攻擊活動的資訊，正是資安團隊判斷風險優先順序與規劃後續處置的重要依據。 將攻擊者研究納入漏洞風險判讀 TeamT5 長期追蹤亞太駭客集團的行為模式與攻擊行動，研究漏洞在其實際攻擊中的利用方式，以及攻擊過程中留下的痕跡，並將這些研究成果進一步轉化為可實際應用的偵測能力，協助資安團隊在判讀漏洞風險時，能掌握來自駭客攻擊活動的線索： 漏洞的實際利用情況 了解哪些漏洞已出現在實際攻擊活動中，辨識需要提高關注程度的風險。 可能與入侵相關的跡象 從偵測到的技術線索中，辨識可能顯示漏洞已遭利用，或系統可能遭未授權存取的跡象。 後續處置方向 結合技術證據與風險資訊，協助團隊判斷應優先修補，或需要進一步查證與調查。 漏洞的優先順序，不應單由漏洞本身的風險程度決定，而是要納入「是否已在實際攻擊中利用」以及「是否發現攻擊者留下的痕跡」等關鍵資訊；從攻擊者視角出發，才能真正掌握最切身相關的真實風險。 參考資料： [1] Google Threat Intelligence Group，《 Vulnerability Discovery and Exploitation Trends in the AI Era 》，October 2026 [2] VulnCheck，《 VulnCheck State of Exploitation 1H-2026 》，July 2026

針對近期揭露的 PHP Session Upload Progress Use-After-Free（CVE-2026-109618 / CVE-2026-109619） 漏洞，TeamT5 已掌握相關攻擊手法，並將持續透過 ThreatSonar Anti-Ransomware 與 MDR 服務 ，協助客戶監控場域內的可疑攻擊行為，降低潛在資安風險。 漏洞說明 CVE-2026-109618 PHP 在發生記憶體不足（OOM）錯誤時，會使用 longjmp() 離開目前的執行環境，並中止該次請求的處理。然而，某些執行環境可能未妥善考量此情況，導致在執行記憶體配置前，部分請求記憶體仍處於未初始化狀態。後續的請求清理程序可能讀取這些記憶體，或根據其內容進行分支判斷。透過多種觸發 OOM 的方式，可穩定觸發此問題，進而導致遠端程式碼執行（RCE）。 官方安全公告： 連結 CVE-2026-109619 PHP 有多種全域狀態會暫時指向請求記憶體。在某些情況下，這些全域狀態可能未被正確重設，或在重設後再次被填入資料，導致其在請求記憶體釋放後，仍指向該記憶體。後續請求可能在這些狀態完成初始化前，讀取其中已失效的內容，或根據其內容進行分支判斷。透過多種方式可觸發此問題，進而導致遠端程式碼執行（RCE）。  官方安全公告： 連結 建議依據 PHP 官方安全公告更新至已修補版本。此外，TeamT5 為協助客戶掌握漏洞影響範圍，並提供以下防護與盤點措施： 一、ThreatSonar Anti-Ransomware：持續監控 PHP 相關攻擊行為 ThreatSonar Anti-Ransomware 已具備多項 PHP 相關威脅偵測規則，可協助識別攻擊者可能利用 PHP 執行惡意指令、WebShell、Reverse Shell 等異常行為，包含： php command reverse shell php_cgi_spawn_shell php_cgi_shell_exec_lolbas php-cgi webshell lolbas W3wp Suspicious php-cgi.exe process execution TeamT5 將持續關注上述 CVE 的攻擊手法與威脅情資，透過 ThreatSonar 監控客戶場域內的可疑活動，並依據最新攻擊趨勢持續評估與強化偵測能力。 二、MDR 服務：主動協助 PHP 資產盤點與修補通知 針對使用 TeamT5 MDR 服務 的客戶，我們後續將協助盤點場域內使用 PHP 軟體的端點清單，並透過既有通報管道提醒客戶確認 PHP 版本及執行必要的漏洞修補作業。 透過資產盤點與威脅監控相互配合，協助客戶優先處理可能受影響的系統，降低漏洞遭利用的風險。 三、ThreatSonar 平台的 Threat Hunter 功能：客戶自主查詢 PHP 端點 客戶亦可透過 ThreatSonar 平台的 Threat Hunter（威脅狩獵） 功能，自行搜尋場域內可能安裝或執行 PHP 的端點。 Windows 系統：可透過 Hunting Tag 搜尋「 Co The Php Group 」 Linux 系統：可透過 filename 搜尋「 ~php-fpm 」 透過上述查詢方式，可初步識別使用 PHP 的端點，進一步確認軟體版本、評估漏洞影響範圍並安排修補。 提醒您，查詢結果取決於 ThreatSonar 已蒐集的端點資訊，未查詢到結果不代表端點未安裝 PHP；建議搭配系統套件及軟體清單確認。 TeamT5 結合 ThreatSonar Anti-Ransomware 威脅偵測、 ThreatSonar 平台 的 Threat Hunter 資產盤點及 MDR 主動監控服務 ，協助企業掌握漏洞暴露範圍、加速修補作業，並及早發現潛在攻擊活動，強化整體資安防護。 另請注意，現有 PHP 相關偵測規則主要用於識別可疑攻擊行為，並非上述 CVE 的專屬漏洞利用偵測規則，因此未出現相關告警不代表不存在漏洞或遭入侵風險。

生成式 AI 正從「回答問題的工具」進一步發展為能自主執行任務的 AI Agent（AI 代理） 。企業開始利用 AI Agent 搜尋資料、操作應用程式、存取企業系統，甚至執行多步驟工作流程。然而，當 AI 從「提供建議」走向「採取行動」，企業面對的資安風險也隨之擴大。 這也使 AI 治理（AI Governance） 成為企業導入 AI 時的重要課題。AI 治理是企業針對 AI 的開發、導入與使用，建立政策、權責與風險管理機制，確保 AI 的使用符合組織規範、安全要求及相關法規。其範圍不只包含模型本身，也涉及資料使用、存取權限、資安控制、持續監督與稽核等面向。 對準備導入 AI Agent 的企業而言， 資安風險評估正是 AI 治理中的重要環節之一 。在正式部署前，除了評估 AI Agent 能帶來哪些效率與功能，更應先確認： AI Agent 能接觸哪些資料、擁有哪些權限，以及執行環境是否安全？ AI Agent 與一般生成式 AI 有什麼不同？ 一般生成式 AI 多半由使用者輸入 Prompt，再產生文字、程式碼或其他內容；AI Agent 則可能進一步串接企業內部系統、瀏覽器、API 或其他工具，依照目標自主規劃並執行任務。 這代表 AI Agent 的風險不只存在於模型本身，也延伸至 帳號權限、端點設備、資料存取與工具串接 等層面。一旦權限配置不當或端點環境存在弱點，AI Agent 所具備的自動化能力也可能放大既有的安全問題。 AI Agent 常見的 5 大資安風險 1. 敏感資料外洩 AI Agent 在執行任務時可能接觸企業文件、原始碼、客戶資料或帳號資訊。若資料存取範圍過大，或缺乏適當控管，敏感資訊可能被非預期地讀取、處理或傳送。 2. Prompt Injection 與惡意指令 AI Agent 可能從網頁、文件、Email 等外部內容取得資訊。攻擊者可將惡意指令藏在這些內容中，誘導 Agent 忽略原有規則、存取不應取得的資訊，甚至執行非預期操作。 3. 過度授權 為了讓 AI Agent 自動完成工作，企業可能授予檔案存取、系統操作或 API 呼叫等權限。若未遵循最小權限原則，一旦 Agent 被誤導或遭濫用，影響範圍可能進一步擴大。 4. 自主行為難以預測 AI Agent 可以根據任務自行規劃多個步驟，但其執行路徑未必完全符合使用者預期。若缺乏適當限制與人工確認機制，錯誤決策可能透過自動化流程被快速放大。 5. 端點環境與設定風險 AI Agent 最終仍需要在企業的電腦、伺服器或其他端點環境中運作。若設備本身存在漏洞、不安全設定、權限過高或缺乏必要的安全控制，即使 AI Agent 本身沒有遭到攻擊，仍可能形成新的攻擊面。 企業導入 AI Agent 前，應評估哪些風險？ AI Agent 安全並非單一產品或工具就能完全解決，而應納入企業既有的 AI 治理、身分與權限管理、資料安全及資安管理流程。 在正式部署前，可先從幾個問題進行盤點： 哪些端點正在使用或準備導入 AI Agent？ AI Agent 可以存取哪些企業資料與系統？ 是否授予超出工作需求的權限？ 執行 AI Agent 的端點是否存在漏洞或高風險設定？ 是否建立安全基線，並能持續確認端點符合要求？ 高風險操作是否需要人工確認或其他控制措施？ 從端點風險評估開始建立 AI Agent 安全基線 完整的 AI 治理涵蓋政策、資料、模型、權限、稽核、風險管理等多個面向，而 端點安全評估是其中一項重要的技術控制環節 。 企業可以在大規模部署 AI Agent 前，先盤點端點環境中的 AI Agent 使用情況、安全設定與潛在弱點，建立可檢視的安全基線，再依風險嚴重程度安排改善優先順序。 TeamT5 ThreatSonar Plus 即從端點安全評估角度切入，協助企業辨識 AI Agent 相關風險，並結合弱點與組態檢測，讓資安團隊在導入 AI Agent 前更清楚掌握端點的安全狀態。 AI Agent 能為企業帶來新的自動化能力，但「能不能使用」之外，更重要的問題是「 能不能安全地使用 」。先釐清資產、權限、設定與端點風險，才能為後續更完整的 AI 治理建立可靠的技術基礎。

本文來自 TeamT5 研究團隊近期的網路犯罪情資研究。如欲進一步了解 TeamT5 各種類的威脅情資報告，請與我們聯繫。 攻擊活動概覽 攻擊活動期間： 2026 年 1 月至 2026 年 5 月 攻擊手法： 網路釣魚（Phishing） 受害國家： 台灣 釣魚套件： Darcula 攻擊者研判： 簡體中文使用者 Campaign Snapshot Campaign Timeframe: Jan 2026 to May 2026 Delivery Methods: Phishing Victim Country: Taiwan Phishing Kit: Darcula Actor Assessment: Chinese-speaking Executive Summary In May, we intercepted a phishing campaign harvesting Taiwanese credit card data. The threat actor leveraged a fake Taiwanese e-invoice platform to lure victims into submitting their credit card information through phishing pages. Our technical analysis found that the campaign encrypts victim data using the Rabbit encryption algorithm. The Rabbit encryption algorithm is the same encryption mechanism previously observed in the Darcula phishing kit. Based on this technical overlap, we assess with high confidence that the campaign was conducted using the Darcula phishing kit. We list all the malicious URLs in the IoCs section below. 1. Phishing Emails In this campaign, the actor delivered the phishing emails from a compromised email account belonging to Korea University[1]. In these emails, the actor impersonated the Taiwanese e-commerce platform MOMO and instructed victims to click the malicious links to verify their e-invoice. The actor prepared several malicious URLs that direct victims to the fake e-invoice platform: - https://0023.ehrscripts.com/ - https://av11.pdjekqa.online/ - https://einvoiceg.com/gov/ - https://einvoicegs.com/gov/ 2. Fake Taiwanese E-invoice Platform At the time of our analysis, we were only able to access two URLs https://einvoiceg.com/gov/ and https://einvoicegs.com/gov/ . The two URLs show the page identical to the legitimate e-invoice platform. However, the icon of the page displays the logo of Taiwanese commercial bank CTBC rather than the logo of Ministry of Finance used by the legitimate site. Figure 1: The fake e-invoice platform While the fake e-invoice platform requires a phone number to sign in, we found that any number entered resulted in a successful login. Once logged in, the page requests credit card information so that the e-invoice can be linked with the credit card. This lure is effective because e-invoices in Taiwan are eligible for a government-run lottery, and residents routinely retain their invoices in the hope of winning a prize. Figure 2: The fake platform that requires phone number to sign in Our research shows that the phishing page performs basic validation of the credit card information. Notably, the error messages shown for invalid input are displayed in Simplified Chinese. Figure 3: Simplified Chinese error messages After the credit card information is submitted, the page redirects to a second page requesting two-factor authentication (2FA) information. We assess that this data is likely synchronized to the phishing kit's backend server in near real time. Figure 4: The page requesting 2FA authentication 3. Relations to Darcula Our technical analysis of the phishing kit’s source code reveals that the victim data is encrypted with the Rabbit algorithm. The algorithm has been previously documented in the Darcula analysis.[2] Specifically, we identify a file app/chunk/DgZYu39z.js that contains an encryption and decryption mechanism sharing the same structure as the Darcula phishing kit. Therefore, we assess with high confidence that the campaign was deployed using the Darcula phishing kit. Notably, the actor may have used AI during development, as we identified numerous Simplified Chinese strings along with emoji characters in the source code. Footnotes [1] Korea University https://www.korea.ac.kr/sites/ko/index.do [2] Exposing Darcula: a rare look behind the scenes of a global Phishing-as-a-Service operation https://www.mnemonic.io/resources/blog/exposing-darcula-a-rare-look-behind-the-scenes-of-a-global-phishing-as-a-service-operation

SEMI E187 為半導體設備建立了資安基準，規範設備在進入晶圓廠前應具備的安全能力。然而，對許多設備供應商與晶圓廠而言，最大的挑戰並不是理解標準，而是如何將條文真正落實到日常檢測流程。 如果檢測仍依賴人工確認文件、逐項比對設定，不僅耗時，也難以維持一致性。因此，建立一套可重複執行、可量化的設備安全檢測流程，才是落實 E187 的關鍵。 第一步：建立完整的設備資產盤點 任何安全管理都應從掌握設備開始。首先需盤點設備的作業系統版本、軟體清單、韌體版本及網路服務，確認設備仍在原廠支援期間，並建立完整的資產資訊，作為後續風險評估的基礎。 第二步：檢查設備是否符合 E187 要求 完成資產盤點後，可依照 E187 的核心要求進行檢查，包括： 作業系統是否仍受支援並定期更新 網路通訊是否採用加密機制 是否關閉不必要的 Port 與服務 是否具備漏洞修補與惡意程式防護能力 是否落實帳號、權限及存取控制 是否保留完整的日誌紀錄供稽核使用 這些項目共同構成設備進場前的基本安全能力，也是 E187 驗證的重要依據。 第三步：將人工判斷轉為自動化檢測 實務上，許多風險並無法僅靠文件確認。例如： 作業系統是否已停止支援？ 是否仍使用預設帳號？ HTTP 是否未加密？ 是否開放 VNC（5900）等高風險連接埠？ 通訊是否缺乏加密或身分驗證？ 若完全依賴人工確認，不僅容易遺漏，也難以維持一致性。透過自動化檢測工具，可直接盤點設備設定、比對漏洞資訊，並將原本模糊的風險轉換為可量化的檢測結果，大幅提升效率與準確性。 第四步：建立風險分級與報告機制 設備檢測不應只有「通過」或「未通過」。企業應將弱點依嚴重程度進行分類，統計 Critical、High、Medium、Low 等風險等級，並完整記錄修補狀態、Windows Hotfix、版本資訊及合規缺失，形成可供稽核與決策使用的報告。 第五步：從一次性檢測走向持續管理 E187 的精神並非完成一次驗證，而是建立持續性的設備資安治理。設備在交付、導入、生產與維護過程中，都可能因更新、組態變更或新增漏洞而產生新的風險。因此，企業應建立定期檢查、持續監控與事件應變機制，讓設備安全成為日常管理的一部分，而非驗證前的臨時工作。 從檢測到防護，強化資安韌性 SEMI E187 提供的是設備資安的共同語言，而真正的價值來自將標準轉化為可執行的檢測流程。從資產盤點、組態檢查、漏洞分析到持續監控，企業不僅能提升驗證效率，更能建立可量測、可追蹤、可持續改善的設備安全管理機制。當檢測流程成為日常營運的一部分，SEMI E187 便不再只是合規要求，而是提升半導體供應鏈韌性的重要基礎。 想知道您的設備是否符合 SEMI E187 要求？ 若您正規劃導入 SEMI E187 驗證，或希望快速掌握設備的資安狀態，TeamT5 可協助您建立符合 E187 的設備安全檢測流程。透過自動化資產盤點、漏洞分析、組態檢查及合規報告，協助您降低人工檢查成本，提升設備進場前的檢測效率與一致性。 立即了解 ThreatSonar Plus，體驗如何將 SEMI E187 標準轉化為可持續執行的設備安全管理流程。 附註 本文內容引用SEMI E187 標準文件，僅供教育與說明用途 標準文件之版權屬於SEMI（Semiconductor Equipment and Materials International） SEMI E187 正式要求與解釋應以 SEMI 官方發布版本為準

隨著半導體供應鏈對設備資安要求持續提升，SEMI E187 已逐漸成為設備供應商與晶圓廠共同遵循的重要標準。對設備製造商而言，E187 不只是「通過驗證」，更代表設備在交付前已具備基本的資安能力，降低供應鏈導入風險。 那麼，設備供應商該如何準備 E187 驗證？ SEMI E187 驗證重點是什麼？ SEMI E187 聚焦於設備本體的資安能力，適用於設備上的 Windows 或 Linux 運算裝置，要求供應商提供設備的資安資訊，並讓晶圓廠能夠驗證設備是否符合安全基準。檢查重點涵蓋作業系統、網路安全、端點防護、存取控制及日誌紀錄等項目。 E187 檢查清單 1. 作業系統管理 確認設備使用的作業系統版本仍在原廠支援期間（EOL），並建立完整的 Patch 與 Update 管理流程，避免使用已停止維護的系統。 2. 網路安全設定 檢查設備是否採用加密通訊，並盤點所有啟用的網路服務與 Port。Telnet、FTP 等高風險服務應停用，只保留必要通訊協定，以降低攻擊面。 3. 端點防護 建立漏洞修補機制，確認設備已完成惡意程式掃描，並具備防惡意程式保護能力。同時強化系統設定，例如限制 USB 使用、停用不必要服務及降低本機安裝權限。 4. 帳號與權限管理 停用預設帳號、建立密碼政策，避免共用帳號，並依角色設定不同權限，確保設備存取皆可追蹤。 5. 日誌與稽核能力 設備應完整記錄登入、設定變更、錯誤事件等 Log，作為日後稽核、事件調查與合規證明的重要依據。 不只是文件，更要證明設備安全 許多企業認為只要提供文件即可完成驗證，但實際上，E187 更重視設備是否真正具備可驗證的資安能力。例如設備是否仍有已知漏洞、是否使用預設帳號、是否開放高風險連接埠、是否採用未加密通訊，若僅依賴人工確認，不僅耗時，也容易遺漏風險。 因此，越來越多設備供應商開始導入自動化檢測工具，透過資產盤點、漏洞比對、組態檢查與合規報表，將原本仰賴人工判斷的項目轉換為可量化、可追蹤的檢測流程，提升驗證效率與一致性。 結語 SEMI E187 的目標並非增加企業負擔，而是建立半導體設備共同遵循的資安基準。對設備供應商而言，及早建立標準化檢測流程，不僅能提升驗證效率，也能降低供應鏈風險，強化客戶對設備安全性的信任，為未來持續的設備資安治理奠定基礎。 需要盡快完成 SEMI E187 檢測合規？ 立即聯絡 TeamT5 ，了解 ThreatSonar Plus 如何協助建立自動化設備資安檢測流程。 附註 本文內容引用SEMI E187 標準文件，僅供教育與說明用途 標準文件之版權屬於SEMI（Semiconductor Equipment and Materials International） SEMI E187 正式要求與解釋應以 SEMI 官方發布版本為準