資安術語表Glossary

流程是這樣：使用者造訪被入侵或惡意的網站，畫面顯示「請完成驗證以繼續」之類的提示，指示他按下 Win+R（Windows）或開啟終端機（macOS），然後按 Ctrl+V 貼上並執行。使用者不知道的是，網頁在他點擊的瞬間已經把一段指令悄悄寫進剪貼簿。

這個手法的巧妙之處在於它繞過的不是技術控制，而是使用者的判斷：

- 沒有檔案下載，所以以下載為觸發點的防護不會啟動
- 執行動作由使用者本人在合法的系統工具中完成，權限完全正當
- 使用者以為自己在做的是通過驗證，不是安裝軟體

對防守方而言，最有效的不是技術管制而是一條具體到動作的規則：任何網頁要求你按 Win+R、開啟 PowerShell 或終端機並貼上東西，一律是攻擊，沒有例外。合法的人機驗證從來不需要你離開瀏覽器。

技術面可補的措施：以群組原則限制一般使用者的執行對話框、監控 explorer.exe 直接生成 powershell.exe 且命令列含編碼字串的行為。

The flow: the user lands on a compromised or malicious site showing something like "complete verification to continue", instructing them to press Win+R (Windows) or open Terminal (macOS), then Ctrl+V and run. What they do not know is that the page quietly wrote a command to their clipboard the moment they clicked.

What makes it effective is that it bypasses the user's judgement rather than a technical control:

- No file is downloaded, so download-triggered protections never fire
- The execution is performed by the user in a legitimate system tool, with entirely valid privileges
- The user believes they are passing a verification check, not installing software

For defenders the most effective measure is not a technical control but a rule concrete enough to act on: any web page telling you to press Win+R, open PowerShell, or open Terminal and paste something is an attack, without exception. Legitimate human verification never asks you to leave the browser.

Technical measures that help: restrict the Run dialog for standard users via group policy, and alert on explorer.exe spawning powershell.exe with an encoded command line.

在 CVE 出現之前，同一個漏洞在不同廠商的公告裡有不同名字，比對資訊極為痛苦。CVE 解決的就是這個命名問題——它是識別碼，不是資料庫，也不是評分。

編號由 CNA（CVE Numbering Authority，編號授權機構）指派。大型廠商如 Microsoft、Google、Red Hat 都是自己的 CNA，可為自家產品直接配號。

常見的誤解要澄清：

- CVE 編號本身不含嚴重性資訊。嚴重性看 CVSS，實際威脅看 KEV
- 配號不等於已公開細節。編號可在協同揭露期間先保留，公告日才釋出內容
- 不是所有漏洞都有 CVE。雲端服務的漏洞常在廠商端直接修掉，不配號，因為使用者無事可做

查詢時常用的來源：NVD（美國國家漏洞資料庫，附 CVSS 評分與受影響版本）、廠商自己的安全公告（通常最準確、最早），以及 CVE Program 官網。

Before CVE, the same flaw carried different names in every vendor's advisory, making correlation painful. CVE solves that naming problem — it is an identifier, not a database and not a score.

Identifiers are assigned by CNAs (CVE Numbering Authorities). Large vendors such as Microsoft, Google, and Red Hat are their own CNAs and assign IDs for their products directly.

Common misconceptions worth clearing up:

- A CVE ID carries no severity information. Severity comes from CVSS; actual threat from KEV
- Assignment does not mean details are public. IDs can be reserved during coordinated disclosure and populated on publication day
- Not every vulnerability gets a CVE. Cloud-service flaws are often fixed on the provider side without an ID, because customers have nothing to act on

Useful lookup sources: NVD (the US National Vulnerability Database, with CVSS scores and affected versions), the vendor's own advisory (usually the most accurate and earliest), and the CVE Program site.

分數由攻擊路徑（是否可從網路發動）、攻擊複雜度、所需權限、是否需要使用者互動，以及對機密性／完整性／可用性的影響等指標組合而成。一般分級：9.0–10.0 重大、7.0–8.9 高、4.0–6.9 中、0.1–3.9 低。

最需要理解的是它的限制：

- CVSS 衡量的是理論嚴重性。一個 CVSS 9.8 但沒有公開 exploit、也沒人在用的漏洞，實際風險低於 CVSS 7.5 但正被勒索軟體大量利用的漏洞
- 一般看到的是 Base Score，未考慮你的環境。同一個漏洞在對外開放的伺服器與內網封閉系統上，風險天差地遠。CVSS 有 Temporal 與 Environmental 指標可調整，但實務上很少人算
- 因此不要只用 CVSS 排修補順序。搭配 KEV（是否已遭利用）與資產暴露程度，才是可行的排序方式

目前並行的版本有 CVSS v3.1 與 v4.0，兩者分數不能直接比較，看到分數時要留意標的是哪一版。

The score combines metrics such as attack vector (is it reachable over the network), attack complexity, privileges required, whether user interaction is needed, and impact on confidentiality, integrity, and availability. Typical bands: 9.0–10.0 critical, 7.0–8.9 high, 4.0–6.9 medium, 0.1–3.9 low.

What matters most is understanding its limits:

- CVSS measures theoretical severity. A CVSS 9.8 with no public exploit and no attacker interest carries less real risk than a CVSS 7.5 being used at scale by ransomware
- What you usually see is the base score, which knows nothing about your environment. The same flaw on an internet-facing server and on an isolated internal system are worlds apart. CVSS has temporal and environmental metrics for this; almost nobody computes them
- So do not order patching by CVSS alone. Combine it with KEV (is it being exploited) and your asset exposure

CVSS v3.1 and v4.0 are both in use and their scores are not directly comparable — check which version a score refers to.

裝置授權流程原本是為了電視盒、CLI 工具這類「不方便輸入密碼」的裝置設計的：裝置顯示一組代碼，使用者到另一台裝置的官方網址輸入該代碼並登入，完成後裝置就拿到權杖。

攻擊者把自己當成那個「裝置」：

1. 攻擊者發起裝置授權流程，取得一組使用者代碼
2. 誘使受害者到真正的官方登入頁輸入該代碼（常見話術是 IT 支援、會議加入、系統升級）
3. 受害者正常登入，包含完整通過 MFA
4. 權杖發給攻擊者的裝置

這個手法可怕在使用者做的每一件事都是對的：正確的官方網域、有效的 TLS 憑證、真實的 MFA、沒有把密碼交給任何第三方。瀏覽器不會示警，網址列檢查完全無效，傳統的釣魚教育在這裡失靈。而且 MFA 確實被完整通過了，只是通過的是攻擊者的登入請求。

最有效的防禦是在身分提供者關掉這個流程（Entra ID 可用 Conditional Access 的 authentication flows 條件封鎖），有需求的情境再限定特定應用程式與受信任網路。偵測面：篩選登入記錄中 authentication protocol 為 Device Code 的事件——多數組織極少用到，基數低、訊噪比高。

The device authorization grant exists for devices where typing a password is awkward — TV boxes, CLI tools. The device shows a code; the user enters it at an official URL on another device and signs in; the device receives a token.

The attacker becomes that "device":

1. The attacker starts a device authorization flow and gets a user code
2. They persuade the victim to enter that code on the genuine official sign-in page (common pretexts: IT support, joining a meeting, a system upgrade)
3. The victim signs in normally, MFA included
4. The token is issued to the attacker's device

What makes it dangerous is that the user does everything right: correct official domain, valid TLS certificate, real MFA, no password given to a third party. No browser warning, address-bar checks useless, traditional phishing training defeated. And MFA genuinely was satisfied — it just satisfied the attacker's sign-in request.

The most effective defence is turning the flow off at the identity provider (in Entra ID, block it with a Conditional Access authentication-flows condition), re-enabling it only for specific applications on trusted networks. For detection, filter sign-in logs for an authentication protocol of Device Code — rare in most organisations, so the baseline is low and the signal excellent.

傳統防毒的判斷基礎是「這個檔案是不是壞的」，比對特徵碼或雜湊值。問題是現代攻擊大量使用系統內建工具（PowerShell、certutil、rundll32），沒有惡意檔案可以掃。

EDR 改看行為與因果關係：哪個程序生成了哪個程序、命令列參數是什麼、碰了哪些檔案與登錄檔、連了哪裡。這些事件持續送回伺服器，比對已知的攻擊模式。所以 EDR 抓得到「Word 開啟後生成了 PowerShell 並下載執行檔」這種每個步驟單獨看都合法的攻擊鏈。

「R」是 response：偵測到之後能隔離該台主機、終止程序、回收檔案，不必等人跑到現場。這在勒索軟體場景很關鍵——反應時間以分鐘計。

EDR 的代價是它會產生大量告警，需要有人看。買了沒人看的 EDR，價值接近零，這也是 MDR（代管式偵測與回應）這類服務存在的原因。

Antivirus asks "is this file bad?", matching signatures or hashes. The problem is that modern attacks lean on built-in system tools (PowerShell, certutil, rundll32) — there is no malicious file to scan.

EDR looks at behaviour and causality instead: which process spawned which, with what command line, touching which files and registry keys, connecting where. Those events stream to a server and get matched against known attack patterns. That is how EDR catches "Word opened, then spawned PowerShell, which downloaded an executable" — a chain where every individual step is legitimate.

The "R" is response: once detected, it can isolate the host, kill the process, and quarantine files without anyone walking to the desk. In a ransomware scenario that matters — response time is measured in minutes.

The cost of EDR is that it generates a lot of alerts and someone has to read them. An EDR nobody operates is worth close to nothing, which is why managed services like MDR exist.

惡意程式不會附原始碼。要知道一個可疑執行檔到底做了什麼——連去哪裡、寫了什麼檔案、怎麼加密通訊——就得把機器碼反推回人看得懂的形式，這就是反組譯器的工作。

Hopper 的定位是 IDA Pro 的輕量替代品：功能不如 IDA 完整，但價格低很多，介面對初學者友善，在 macOS 上的體驗尤其好。核心功能包括反組譯成組合語言、產生近似 C 的虛擬碼、繪製控制流程圖、以及用 Python 腳本自動化分析。

同類工具還有 Ghidra（NSA 開源、免費、跨平台，功能與 IDA 接近）與 radare2 / rizin（開源、命令列導向）。如果你剛開始接觸逆向且預算為零，Ghidra 通常是更務實的起點。

這類工具本身是中性的：惡意程式分析、韌體稽核、相容性研究、找自家產品的漏洞都用得上。只逆向你有合法權利分析的程式——授權條款與當地法令都可能限制反向工程。

Malware does not ship with source. To learn what a suspicious binary actually does — where it connects, what files it writes, how it encrypts its traffic — you have to turn machine code back into something readable. That is what a disassembler does.

Hopper positions itself as a lightweight alternative to IDA Pro: less complete, considerably cheaper, friendlier to newcomers, and especially pleasant on macOS. Core features are disassembly to assembly, C-like pseudocode generation, control-flow graphs, and Python scripting for automation.

Comparable tools include Ghidra (open-sourced by the NSA, free, cross-platform, close to IDA in capability) and radare2 / rizin (open source, command-line oriented). If you are starting out with zero budget, Ghidra is usually the more practical entry point.

These tools are neutral: malware analysis, firmware audits, compatibility research, and finding bugs in your own products all use them. Only reverse engineer what you have the legal right to analyse — licence terms and local law may both restrict it.

每年公告的 CVE 有數萬個，全部修完既不可能也沒必要。絕大多數 CVE 從未被實際利用過。 問題是怎麼分辨。

CVSS 分數幫助有限，因為它衡量的是理論嚴重性，不是實際威脅。一個 CVSS 9.8 但沒有可用 exploit、也沒人攻擊的漏洞，優先順序其實低於一個 CVSS 7.5 但正在被勒索軟體大量利用的漏洞。

KEV 的價值就在這裡：它的收錄門檻是「有實際遭利用的證據」，不是理論風險。列在 KEV 上代表有人正在用它攻擊真實目標。這使它成為修補排序最實用的單一依據。

幾個使用要點：

- KEV 對美國聯邦機構具強制力（依 CISA 的 BOD 指令，需在期限內修補），對其他組織是強烈建議
- 清單以 JSON 與 CSV 免費提供，可直接接進自動化流程比對自家資產
- KEV 是落後指標：漏洞被列入時，攻擊已經在發生。它幫你排序，不能取代及時修補
- 沒列在 KEV 不等於安全，只是還沒觀察到被利用

Tens of thousands of CVEs are published each year. Patching all of them is neither possible nor necessary — the vast majority are never exploited. The problem is telling which is which.

CVSS scores help only so much, because they measure theoretical severity rather than actual threat. A CVSS 9.8 with no working exploit and no attacker interest is genuinely lower priority than a CVSS 7.5 being used at scale by ransomware crews.

That is KEV's value: the bar for inclusion is evidence of exploitation in the wild, not theoretical risk. Being on KEV means someone is using it against real targets right now, which makes it the single most practical input to patch ordering.

Points to keep in mind:

- KEV is binding on US federal agencies (CISA BOD directives set remediation deadlines) and strongly advisory for everyone else
- The catalog is free as JSON and CSV, so you can wire it straight into automation against your asset inventory
- KEV is a lagging indicator: by the time something is listed, attacks are already underway. It helps you order work; it does not replace timely patching
- Absence from KEV does not mean safe — only that exploitation has not been observed

OWASP 不是廠商也不是官方機構，是由志願者維護的社群。它的影響力來自產出的東西被廣泛引用：法規、稽核清單、招標文件、教育訓練都在用。

最為人所知的是 OWASP Top 10 ——每隔幾年更新一次的網站應用程式十大風險清單。要理解它的定位：這是風險意識清單，不是完整的安全檢核表。通過 Top 10 不等於安全，只是代表沒有犯最常見的錯。把 Top 10 當作稽核的全部範圍是常見的誤用。

其他值得知道的產出：

- ASVS（Application Security Verification Standard）——比 Top 10 細得多的驗證標準，分三級，適合真的拿來當檢核表
- Cheat Sheet Series ——各主題的實作建議，寫得具體，開發時查很好用
- ZAP（Zed Attack Proxy）——開源的網站弱點掃描代理工具
- Top 10 for LLM Applications ——針對 AI 應用的獨立清單，見該條目

所有內容都在 owasp.org 免費取得，沒有付費牆。

OWASP is neither a vendor nor a government body — it is a volunteer-maintained community. Its influence comes from how widely its output is cited: in regulations, audit checklists, procurement documents, and training.

The best known is the OWASP Top 10, a list of the ten most critical web application risks, refreshed every few years. Understand its position: it is an awareness list, not a complete security checklist. Passing the Top 10 does not mean you are secure; it means you have avoided the most common mistakes. Treating it as the entire audit scope is a common misuse.

Other output worth knowing:

- ASVS (Application Security Verification Standard) — far more granular than the Top 10, in three levels, genuinely usable as a checklist
- Cheat Sheet Series — concrete implementation guidance by topic, handy during development
- ZAP (Zed Attack Proxy) — an open-source web vulnerability scanning proxy
- Top 10 for LLM Applications — a separate list for AI applications; see that entry

Everything is free at owasp.org, with no paywall.

傳統的 OWASP Top 10 假設攻擊者透過輸入欄位攻擊確定性的程式邏輯。LLM 應用打破了這個假設：系統指令與使用者輸入混在同一個上下文裡、模型的行為不確定、而且應用常被授權去呼叫工具或存取資料。

幾個最需要理解的項目：

提示注入（Prompt Injection） 是這份清單的頭號風險，也是最難根治的。它分兩種：直接注入是使用者自己下指令試圖繞過系統提示；間接注入更危險——惡意指令藏在模型會讀到的外部內容裡（網頁、文件、郵件、程式碼註解），模型讀到後把它當成指令執行。本質問題是模型無法可靠區分「該遵循的指令」與「該當成資料處理的內容」。

過度代理（Excessive Agency） 指的是給了模型超出必要的權限或工具。當模型可能被注入操控時，它能做的每件事都是攻擊者能做的事。

對輸出過度信任（Overreliance） ——把模型產出的程式碼、SQL、指令直接執行或採信，不加驗證。

供應鏈 ——模型權重、訓練資料集、第三方套件都可能被投毒。

實務上最重要的心法：把模型輸出當成不可信任的使用者輸入來處理。該做的輸出編碼、參數化查詢、權限最小化，一樣都不能省。

The traditional OWASP Top 10 assumes an attacker hits deterministic program logic through input fields. LLM applications break that assumption: system instructions and user input share one context, model behaviour is non-deterministic, and the application is often authorised to call tools or reach data.

The items most worth understanding:

Prompt injection heads the list and is the hardest to fix. It comes in two forms. Direct injection is a user trying to talk their way past the system prompt. Indirect injection is more dangerous: malicious instructions hidden in external content the model will read — a web page, document, email, or code comment — which the model then treats as instructions. The underlying problem is that a model cannot reliably distinguish instructions it should follow from content it should merely process.

Excessive agency means granting the model more permissions or tools than it needs. When the model can be manipulated by injection, everything it can do is something an attacker can do.

Overreliance is executing or trusting model-produced code, SQL, or commands without verification.

Supply chain covers poisoned model weights, training datasets, and third-party packages.

The practical mindset that matters most: treat model output as untrusted user input. Output encoding, parameterised queries, and least privilege all still apply.

PhaaS 把釣魚產業化。訂閱者付月租就能取得：仿冒各大服務的登入頁範本、代管的基礎設施、繞過偵測的技巧、竊得憑證的管理後台，有些甚至附客服與更新日誌。營運方式與 SaaS 幾乎無異。

技術上最關鍵的演進是 AiTM（adversary-in-the-middle，中間人）：假登入頁不再只是複製外觀，而是把使用者的每個請求即時轉發到真正的服務、再把回應轉回來。使用者看到的是真實的登入流程（因為內容確實來自真服務），完成 MFA 後，攻擊者攔截的是已通過驗證的 session cookie——拿到之後不需要密碼也不需要再過 MFA，直接接管帳號。

這對防禦的意涵是：「有 MFA 就安全」已經不成立。要真正擋住 AiTM，需要防釣魚的 MFA——FIDO2／passkey 這類把驗證綁定到來源網域的方式，代理網域不符就無法完成驗證。簡訊或 TOTP 驗證碼擋不住，因為它們可以被即時轉送。

偵測面可留意：非預期地理位置的 session、同一 session 在短時間內出現裝置指紋變化、以及新增的郵件轉寄規則（攻擊者接管後的常見動作）。

PhaaS industrialised phishing. A subscription buys login-page templates for major services, hosted infrastructure, detection-evasion techniques, and an admin panel for harvested credentials — some even ship support and changelogs. Operationally it looks like any SaaS business.

The key technical evolution is AiTM (adversary-in-the-middle): the fake login page no longer just copies the look, it proxies every request to the real service in real time and relays the response back. The user sees a genuine login flow, because the content genuinely comes from the real service. Once MFA completes, the attacker intercepts the authenticated session cookie — after which they need neither password nor MFA to take over the account.

The defensive implication: "we have MFA" no longer means safe. Stopping AiTM requires phishing-resistant MFA — FIDO2 / passkeys, which bind authentication to the origin domain, so a proxy domain simply cannot complete the ceremony. SMS codes and TOTP do not help, because they can be relayed in real time.

For detection, watch for sessions from unexpected geographies, device-fingerprint changes within one session, and newly created mail forwarding rules — a standard post-takeover move.

RAT 與一次性的惡意程式不同，重點在持續性：植入後與攻擊者的 C2（command and control，指揮控制）伺服器保持通訊，等待指令。對攻擊者而言這是「灘頭堡」——後續的橫向移動、資料竊取、部署勒索軟體都從這裡開始。

典型能力：瀏覽與上傳下載檔案、執行任意指令、鍵盤側錄、螢幕與攝影機擷取、竊取瀏覽器儲存的憑證、以及作為跳板存取內網其他主機。

與合法遠端管理工具的界線很模糊。攻擊者近年大量改用 AnyDesk、ScreenConnect、TeamViewer 這類正版工具達到同樣目的——因為它們有合法簽章、通常已在白名單上、流量也不可疑。2026-W32 就有一起偽裝成 Adobe 與 Zoom 更新來安裝 ScreenConnect 的活動。所以偵測不能只靠「這是不是惡意軟體」，要問「這台機器上為什麼會有遠端存取工具，是誰裝的」。

偵測方向：定期連線到固定外部位址的規律流量（beaconing）、非管理人員機器上出現遠端管理軟體、以及開機自動啟動項目的異動。

Unlike one-shot malware, a RAT is about persistence: once installed it maintains contact with the attacker's C2 (command and control) server, waiting for instructions. For the attacker it is a beachhead — lateral movement, data theft, and ransomware deployment all start here.

Typical capabilities: browsing and transferring files, running arbitrary commands, keylogging, screen and webcam capture, stealing browser-stored credentials, and pivoting to other hosts on the internal network.

The line against legitimate remote-management tools is blurry. Attackers increasingly use genuine AnyDesk, ScreenConnect, or TeamViewer for the same purpose — validly signed, often already allowlisted, with unremarkable traffic. 2026-W32 covered a campaign installing ScreenConnect behind fake Adobe and Zoom update prompts. So detection cannot rest on "is this malware"; the question is "why is there a remote access tool on this machine, and who installed it".

Detection angles: regular beaconing to a fixed external address, remote-management software appearing on non-administrator machines, and changes to autostart entries.

常見產品有 N-able N-central、ConnectWise Automate、Datto RMM、NinjaOne 等，主要使用者是 MSP（受管服務供應商）。一台 RMM 主機通常管理數十到數千個客戶端點，具備遠端安裝軟體、執行腳本、開遠端桌面的能力。

這正是問題所在：RMM 的正常功能，就是攻擊者想要的能力。攻擊者接管 RMM 之後不需要另外植入惡意程式，直接用平台內建的軟體派送功能就能對所有受管端點執行任意程式——而且這些行為在端點側看起來完全合法，因為它們確實來自受信任的管理代理程式。

所以 RMM 漏洞的影響半徑不是一台主機，而是整個客戶名單。近年勒索軟體集團特別偏好這條路徑，一次入侵就能同時加密數十家企業。

防守要點：管理介面絕不對外開放、強制 MFA、嚴格控管管理員帳號、把受管端點側的稽核紀錄集中到 RMM 之外的地方（被接管的平台上的紀錄不可信）。若你是委外方，要主動向服務商確認其 RMM 版本與修補狀況。

Common products include N-able N-central, ConnectWise Automate, Datto RMM, and NinjaOne, used mainly by MSPs (managed service providers). One RMM server typically manages tens to thousands of customer endpoints, with the ability to install software, run scripts, and open remote sessions.

That is precisely the problem: an RMM's normal functionality is exactly the capability an attacker wants. Having taken over the RMM, an attacker needs no malware — the platform's own software deployment feature will run anything on every managed endpoint. And on the endpoint side it all looks legitimate, because it genuinely comes from a trusted management agent.

So the blast radius of an RMM vulnerability is not one host but the entire customer list. Ransomware crews have favoured this path in recent years: one intrusion, dozens of companies encrypted at once.

Defensive priorities: never expose the console to the internet, enforce MFA, tightly control administrator accounts, and ship endpoint-side audit logs somewhere outside the RMM (logs on a platform the attacker controlled are not trustworthy). If you outsource IT, ask your provider for their RMM version and patch status.

與加密的差別在目的：加密是讓人看不懂內容，隱寫是讓人不知道有內容。兩者常合併使用。

常見做法是修改圖片像素的最低位元（LSB），視覺上完全看不出差異；或把資料附加在檔案格式的結構之外——例如 PNG 的結束標記之後，多數看圖程式會直接忽略。

攻擊者用它來規避以內容為判斷依據的防護：

- 網路層：下載一張圖片不會觸發任何規則，但下載一個 .exe 或 PowerShell 腳本會
- 端點層：落到磁碟上的是圖片檔，不是可疑的執行檔，減少被掃描判定的機會
- 多階段載入：第一階段的程式碼很小、很無害，真正的載荷藏在圖片裡稍後取出

偵測不容易，因為要判斷「這張圖裡有沒有東西」在計算上很昂貴，而且正常網站本來就充滿圖片。比較務實的方向是看行為而非看檔案：程序讀取圖片檔後隨即產生新的執行緒或子程序、從瀏覽器快取目錄讀取內容並執行——這些行為模式比檢查圖片本身有效得多。

The difference from encryption is intent: encryption makes content unreadable; steganography makes its presence unnoticed. The two are often combined.

Common methods modify the least significant bits of image pixels (LSB), leaving no visible difference, or append data outside the file format's structure — after a PNG's end marker, say, where most viewers simply stop reading.

Attackers use it to evade content-based controls:

- Network layer: downloading an image triggers no rule; downloading an .exe or PowerShell script does
- Endpoint layer: what lands on disk is an image, not a suspicious executable, reducing the chance of a scanning verdict
- Multi-stage loading: a small, innocuous first stage, with the real payload hidden in an image and extracted later

Detection is hard, because deciding whether an image contains anything is computationally expensive and normal sites are full of images anyway. The pragmatic approach is watching behaviour rather than files: a process reading an image and immediately spawning a thread or child process, or content read from the browser cache directory and executed. Those patterns are far more effective than inspecting the image itself.

你的防火牆擋得住外部連線，卻擋不住自己主動安裝的更新。供應鏈攻擊利用的就是這個不對稱。常見的入口：

- 開源套件生態系——npm、PyPI、Maven 等。手法包括竊取維護者的發布 token 後推出植入惡意程式的新版本、註冊與熱門套件名稱相近的套件（typosquatting）、以及在企業內部私有套件名稱上搶註公開同名套件（dependency confusion）
- 商用軟體更新機制——入侵廠商的建置或簽章流程，讓惡意版本帶著合法簽章下發
- 管理工具——如 RMM 平台，一次接管觸及所有受管環境

特別難防的原因有兩個。第一，惡意程式帶著合法的信任憑據進來：正確的簽章、官方的來源、你自己下的安裝指令。第二，傳遞性——你的 package.json 沒有列出的套件，可能經由三層相依進到你的環境。

可行的緩解方向：鎖定版本並審查 lockfile 變動、CI 使用 npm ci --ignore-scripts 之類的方式阻斷安裝期腳本、導入相依掃描與 SBOM、對建置環境採最小權限、以及假設會中招而準備好憑證輪換流程。

Your firewall blocks inbound connections but not the update you install yourself. Supply chain attacks exploit that asymmetry. Common entry points:

- Open source ecosystems — npm, PyPI, Maven and friends. Techniques include stealing a maintainer's publish token and shipping a trojanised release, registering names close to popular packages (typosquatting), and claiming public names that match a company's private packages (dependency confusion)
- Commercial update channels — compromise a vendor's build or signing pipeline so malicious versions ship with valid signatures
- Management tooling — an RMM platform, where one takeover reaches every managed environment

Two things make it hard to defend. First, the malicious code arrives with legitimate credentials of trust: a valid signature, an official source, an install command you typed. Second, transitivity — a package absent from your package.json can reach you three dependency levels down.

Practical mitigations: pin versions and review lockfile changes, block install-time scripts in CI (npm ci --ignore-scripts), adopt dependency scanning and SBOMs, apply least privilege to build environments, and assume compromise by having a credential rotation process ready.

EDR 只看端點。但一次真實入侵通常橫跨多個層面：釣魚信進到郵件系統、使用者在端點執行了東西、攻擊者拿著竊來的 token 從另一個 IP 登入雲端服務、再橫向移動到檔案伺服器。

每個系統各自看到的都只是碎片：郵件閘道看到一封可疑信但使用者沒回報、EDR 看到一次 PowerShell 執行但已被歸類為低風險、雲端看到一次成功登入但憑證正確。單獨看都不足以告警，串起來才是完整的攻擊鏈。

XDR 的主張就是把這些訊號放進同一個資料模型做關聯，讓偵測規則能跨層撰寫。

實務上要注意兩件事。第一，XDR 是行銷詞彙多於技術標準，各家定義差異很大，採購時要具體問「你關聯哪些資料來源」。第二，XDR 通常綁定單一供應商的生態系，跨廠牌整合往往沒有宣傳中順暢——這也是 SIEM 沒有被取代的原因。

EDR only sees the endpoint. A real intrusion usually spans several layers: a phishing email arrives, the user runs something on their endpoint, the attacker signs into a cloud service from a different IP with a stolen token, then moves laterally to a file server.

Each system sees only a fragment: the mail gateway saw a suspicious message nobody reported, EDR saw one PowerShell execution already scored as low risk, the cloud saw a successful sign-in with valid credentials. None warrants an alert alone; strung together they are the attack.

XDR's proposition is to put those signals into one data model and correlate them, so detection rules can span layers.

Two practical caveats. First, XDR is more marketing term than technical standard — definitions vary widely, so ask vendors specifically which data sources they correlate. Second, XDR usually assumes a single vendor's ecosystem; cross-vendor integration is rarely as smooth as advertised, which is why SIEM has not gone away.