資安術語表Glossary

三個字各有意義，但最被誤解的是 A（Advanced）。APT 不代表每次都用零時差漏洞——大量實際案例的入口是釣魚信、外洩憑證、未修補的邊界設備，跟一般攻擊沒兩樣。「進階」指的是整體作業能力：情報蒐集、客製工具、對目標環境的理解、以及行動的紀律。

真正的區別在 P（Persistent）。一般犯罪集團打不進去就換目標，因為他們要的是投報率；APT 針對的是特定組織的特定資產，打不進去就換方法、換入口、等下一個機會，時間尺度以月甚至年計。這也意味著你把它踢出去一次，它會再回來——事件處理必須連根拔除，否則只是暫時中斷。

命名慣例相當混亂：各家資安廠商對同一個組織有各自的代號（動物、數字、元素、天氣現象），彼此的對應關係也不完全一致。看報告時要注意你讀的是哪一家的命名體系。TA（Threat Actor） 則是較中性的泛稱，不預設對方是否具備國家級資源。

防禦上的意涵：對抗 APT 不能靠單一產品，而是偵測與回應的整體成熟度——日誌保存期夠不夠長、能不能回溯數月前的活動、事件處理能不能做到完整清除。

Each word carries meaning, but A (Advanced) is the most misunderstood. APT does not mean zero-days every time — a great many real cases start with phishing, leaked credentials, or an unpatched edge device, exactly like ordinary attacks. "Advanced" refers to overall operational capability: intelligence gathering, custom tooling, understanding of the target environment, and disciplined execution.

The real distinction is P (Persistent). Ordinary criminal crews move on when a target proves hard, because they optimise for return on effort. An APT is after specific assets in a specific organisation; blocked, it changes method, changes entry point, and waits for the next opening — on a timescale of months or years. Which also means evicting it once does not end it. Incident response has to be complete, or you have only paused the operation.

Naming is genuinely messy: each vendor has its own codenames for the same group (animals, numbers, elements, weather), and the mappings between them are not perfectly aligned. When reading a report, note whose naming scheme you are in. TA (threat actor) is the more neutral general term, making no assumption about state resourcing.

The defensive implication: countering an APT is not a product purchase but overall detection and response maturity — whether your log retention is long enough, whether you can reconstruct activity from months ago, whether your response can achieve full eradication.

多數組織買了一整排資安設備，卻沒有辦法回答一個基本問題：它們現在真的有效嗎？ 設定可能被改過、規則可能沒更新、授權可能過期、新版本可能改變了預設行為。稽核報告與設備儀表板都不會告訴你這件事。

BAS 的做法是持續、自動地把已知攻擊手法丟進自己的環境，觀察哪些被擋下、哪些通過、哪些有告警但沒人處理，藉此量化每個控制點的實際覆蓋率。與滲透測試的差別在於頻率與範圍：滲透測試是一年一兩次的深度人工評估，BAS 是可以每週跑的廣度自動化驗證，兩者互補而非取代。

測項通常分成兩型：

- IOC 型——拿近期的威脅情資去試打閘道與防毒，驗證情資有沒有即時載入
- IOB 型——重現攻擊技術本身（例如 Pass-the-Hash、SQL 注入），驗證行為型控制是否偵測得到

驗證對象涵蓋整條防線：SWG、SEG、防毒、EDR、WAF，以及橫向移動階段的內網控制。

要注意的限制：BAS 驗證的是「控制有沒有反應」，不是「你的組織能不能處理事件」。設備擋下了但沒人看告警，在 BAS 報表上仍是綠燈。它也不會發現未知漏洞——那是滲透測試與紅隊的工作。

Most organisations own a wall of security products but cannot answer a basic question: are they actually working right now? Configuration drifts, rules go stale, licences lapse, new versions change defaults. Neither audit reports nor product dashboards tell you.

BAS continuously and automatically fires known attack techniques into your own environment and observes what gets blocked, what gets through, and what alerts but goes unhandled — quantifying real coverage per control. The difference from penetration testing is frequency and breadth: pentests are deep manual assessments once or twice a year; BAS is broad automated validation you can run weekly. They complement rather than replace each other.

Test cases usually come in two types:

- IOC-based — replay recent threat intelligence against gateways and antivirus to verify indicators are loaded
- IOB-based — reproduce the technique itself (Pass-the-Hash, SQL injection) to verify behaviour-based controls detect it

Coverage spans the whole line: SWG, SEG, antivirus, EDR, WAF, and the internal controls that matter during lateral movement.

A limit worth stating: BAS validates whether a control reacts, not whether your organisation can handle an incident. A product that blocked something while nobody read the alert still shows green. Nor does it find unknown vulnerabilities — that is what penetration testing and red teaming are for.

植入惡意程式只是開始，攻擊者還需要一條能持續下指令、取回資料的通道，這就是 C2。它的設計目標與防守方的目標直接對立：攻擊者要讓這段流量看起來毫不起眼。

演進路徑很清楚。早期是固定 IP 或網域的直接回連，封鎖名單即可應對。之後出現 DGA（網域生成演算法），每天產生大量候選網域讓封鎖追不上。現在最棘手的是濫用合法服務：把指令放在雲端硬碟的檔案裡、放在協作平台的訊息中、藏在程式碼託管平台的 commit 裡，甚至用 DNS 查詢或 MQTT 這類物聯網協定夾帶。

這讓以目的地為判斷依據的防禦失效。 惡意流量連的確實是合法網域、確實有有效憑證、確實是公司本來就在用的服務。封鎖那個網域等於中斷正常業務。

可行的偵測方向是行為而非目的地：

- beacon 規律性——自動化的回連呈現固定或近固定的時間間隔，人類操作不會如此規律。抖動（jitter）可以模糊但很難完全消除
- 流量方向失衡——正常的協作服務使用是雙向且不規則的；C2 常是小量固定的上行加上偶爾的大量下行
- 主體異常——某個服務帳號或裝置突然開始存取它從未碰過的資源類型
- 時間分布——非人類作息的持續活動

記錄要留得夠久。C2 的規律性往往要拉長到數天的尺度才看得出來。

Planting malware is only the start; the operator still needs a channel to issue instructions and retrieve data. That is C2, and its design goal directly opposes the defender's: make this traffic look unremarkable.

The evolution is clear. Early C2 called back to a fixed IP or domain, which blocklists handled. Then came DGAs (domain generation algorithms), producing enough candidate domains daily to outpace blocking. The hardest case now is abusing legitimate services: instructions parked in a cloud drive file, in collaboration platform messages, inside commits on a code hosting platform, or smuggled through DNS queries and IoT protocols such as MQTT.

This defeats destination-based defence. The malicious traffic genuinely goes to a legitimate domain, with a valid certificate, to a service the company already uses. Blocking that domain breaks the business.

Detection has to look at behaviour rather than destination:

- Beacon regularity — automated callbacks arrive at fixed or near-fixed intervals; human use is never that regular. Jitter blurs this but rarely removes it
- Directional imbalance — legitimate collaboration is two-way and irregular; C2 is often small steady uploads with occasional large downloads
- Principal anomalies — a service account or device suddenly reaching resource types it has never touched
- Time distribution — sustained activity that does not follow human working patterns

Retain logs long enough. C2 regularity often only becomes visible across several days.

流程是這樣：使用者造訪被入侵或惡意的網站，畫面顯示「請完成驗證以繼續」之類的提示，指示他按下 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.

IOC 記錄的是成品（這個雜湊值是惡意的），IOB 記錄的是做法（把 LSASS 記憶體傾印出來以竊取憑證）。兩者的差別決定了它們的壽命：換個編譯參數就能產生新的雜湊值，但要換掉「傾印 LSASS」這個動作，攻擊者得改變整套流程。

IOB 通常對應到 MITRE ATT&CK 的技術編號，例如 Pass-the-Hash（T1550.002）、Kerberoasting（T1558.003）。偵測邏輯寫的是行為模式：哪個程序存取了哪個資源、程序親子關係是否合理、命令列參數的特徵。

代價是誤判率較高、成本較貴。合法的管理行為與攻擊行為在技術上常常一模一樣——系統管理員也會用 PsExec、也會查詢 SPN。所以 IOB 偵測需要環境基準線與人工調校，不像 IOC 那樣開箱即用。

在 BAS 的驗證矩陣裡，IOB 型測項打的是 EDR 與 WAF 這類看行為的控制，驗證的問題是「這個攻擊手法在你的環境裡會不會被擋下或告警」，而不是「這個檔案認不認得」。

An IOC records the artefact (this hash is malicious); an IOB records the method (dumping LSASS memory to steal credentials). That difference determines their shelf life: a new compiler flag produces a new hash, but abandoning "dump LSASS" means changing the whole workflow.

IOBs usually map to MITRE ATT&CK technique IDs — Pass-the-Hash (T1550.002), Kerberoasting (T1558.003). The detection logic describes behaviour: which process touched which resource, whether the parent-child relationship makes sense, what the command line looks like.

The cost is more false positives and more effort. Legitimate administration and attack often look technically identical — sysadmins also use PsExec, also query SPNs. So IOB detection needs an environmental baseline and human tuning; it is not turnkey the way IOC matching is.

In a BAS validation matrix, IOB test cases target behaviour-based controls like EDR and WAF. The question is "would this technique be blocked or alerted in your environment", not "do you recognise this file".

IOC 是威脅情報最基本的形式：一份可以直接餵進防火牆、閘道、防毒軟體的清單。常見型態包括 IP 位址、網域與 URL、檔案的 MD5／SHA-256 雜湊值、憑證指紋、以及惡意程式的檔名或註冊表鍵值。

優點是精準且成本低——比對命中就是命中，幾乎沒有誤判，而且比對本身很便宜，可以在網路邊界大規模執行。

限制也很明確：IOC 是過去式。攻擊者換一個 IP、重新編譯改變雜湊值，你的清單就失效了。這種「一次性」的特性讓純 IOC 防禦永遠落後一步，這也是 IOB（行為指標）補位的原因。

在 BAS（入侵與攻擊模擬）的驗證情境裡，IOC 型測項驗證的是「你的 SWG／SEG／防毒是否已載入最新情資」——通常直接拿近幾週的新情報去試打，看設備擋不擋得下來。

IOCs are the most basic form of threat intelligence: a list you can feed straight into a firewall, gateway, or antivirus product. Typical types include IP addresses, domains and URLs, MD5/SHA-256 file hashes, certificate fingerprints, and malware filenames or registry keys.

The strengths are precision and low cost — a match is a match, with almost no false positives, and matching itself is cheap enough to run at network scale.

The limits are equally clear: an IOC describes the past. Change an IP, recompile to alter the hash, and your list is stale. That disposability keeps pure IOC defence one step behind, which is exactly the gap IOBs fill.

In BAS validation, IOC-type test cases verify whether your SWG, SEG, or antivirus has current intelligence loaded — typically by replaying the last few weeks of new indicators and seeing whether the control blocks them.

這個手法的可怕之處在於它不需要任何特殊權限。Kerberos 的設計允許任何已通過驗證的網域使用者，向網域控制站索取任何已註冊 SPN（Service Principal Name）之服務的票證——這是正常功能，不是漏洞。

問題出在票證的加密金鑰衍生自該服務帳號的密碼。攻擊者拿到票證後帶離網域，在自己的機器上離線嘗試各種密碼，直到解得開為止。整個破解過程不會產生任何登入失敗紀錄，也不會觸發帳號鎖定——因為它根本不在你的網域裡進行。

服務帳號往往是最弱的一環：密碼設定多年未改、為了避免服務中斷而排除在密碼原則之外、由廠商安裝時設定且無人知道、有時還被賦予過高權限。一個弱密碼的服務帳號如果是網域管理員群組成員，破解成功就直接通關。

防禦重點：

- 服務帳號改用群組受管服務帳號（gMSA），密碼由系統自動產生與輪換，長度足以讓離線破解不可行。這是最根本的解法
- 無法使用 gMSA 時，服務帳號密碼至少 25 字元以上並定期輪換
- 稽核有 SPN 的帳號，尤其檢查有沒有服務帳號在高權限群組裡——這是最常見也最致命的組合
- 停用 RC4 加密，強制使用 AES（RC4 加密的票證破解速度快得多）

偵測上可留意：短時間內大量索取服務票證、以及使用 RC4 加密的票證請求（現代環境應以 AES 為主）。

What makes this dangerous is that it requires no special privilege. Kerberos by design lets any authenticated domain user request a ticket for any service with a registered SPN (service principal name). That is normal functionality, not a bug.

The problem is that the ticket's encryption key derives from the service account's password. The attacker takes the ticket away and tries passwords offline on their own machine until it opens. The cracking produces no failed logon events and triggers no account lockout — it does not happen in your domain at all.

Service accounts are often the weakest link: passwords unchanged for years, excluded from password policy to avoid outages, set by a vendor during installation and known to nobody, and sometimes over-privileged. A service account with a weak password that also sits in Domain Admins ends the game on a successful crack.

Defensive priorities:

- Move service accounts to group managed service accounts (gMSA), where the system generates and rotates a password long enough to make offline cracking infeasible. This is the root fix
- Where gMSA is not possible, use service account passwords of 25+ characters and rotate them
- Audit accounts with SPNs, especially checking for service accounts in privileged groups — the most common and most fatal combination
- Disable RC4 and enforce AES; RC4-encrypted tickets crack far faster

For detection: bursts of service ticket requests, and ticket requests specifying RC4 in an environment that should be AES.

每年公告的 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

很多組織的電腦是用同一份映像檔部署的，於是每一台的本機管理員密碼都一樣。這在管理上方便，在資安上卻是災難：攻擊者只要拿下任何一台機器並取得該密碼（或其雜湊值），就能用它登入其餘所有機器——不需要提權、不需要漏洞，因為那本來就是合法憑證。這是橫向移動最省力的一條路。

LAPS 的做法是讓每台電腦自行產生隨機密碼、定期輪換，並把當前密碼存放在 Active Directory（新版 Windows LAPS 也支援存放於 Entra ID）中，只有被授權的人員或群組讀得到。需要用時就去查該台機器的當前密碼，用完之後系統會再次輪換。

這是投報率極高的一項措施：部署成本低、對使用者無感，卻能直接封死一整類攻擊路徑。

實作時要注意：

- 讀取權限要嚴格控管並稽核——AD 中的密碼讀取權限若給得太寬，等於把所有機器的管理員密碼集中放在一個容易拿到的地方
- 確認輪換週期確實生效，別讓密碼長年不變
- 記得涵蓋伺服器，不要只做工作站
- 舊版 LAPS 與新版 Windows LAPS 的儲存方式與屬性不同，遷移時要確認舊屬性已清除

在 BAS 的驗證矩陣中，這一項通常標註為「視環境而定」——因為要驗證的是你的環境有沒有正確部署，而不是產品本身的功能。

Many estates deploy machines from one image, so every local administrator password is identical. Convenient to manage, disastrous for security: compromise any one machine, recover that password (or its hash), and it opens every other machine — no escalation, no exploit, because those are legitimate credentials. It is the cheapest lateral movement path there is.

LAPS has each machine generate its own random password, rotate it on a schedule, and store the current value in Active Directory (newer Windows LAPS also supports Entra ID), readable only by authorised people or groups. When you need it, you look up that machine's current password, and the system rotates it again afterwards.

The return on effort is exceptional: cheap to deploy, invisible to users, and it closes an entire class of attack path.

Implementation notes:

- Control and audit read permissions tightly — permissions granted too broadly in AD amount to collecting every machine's admin password in one easily reached place
- Verify rotation actually happens; do not let passwords sit unchanged for years
- Cover servers, not just workstations
- Legacy LAPS and modern Windows LAPS store data differently; when migrating, confirm the old attributes are cleared

In a BAS validation matrix this item is usually marked environment-dependent, because what is being validated is whether your estate deployed it correctly, not whether the product works.

初始入侵取得的通常是一台低價值的機器——某個員工的筆電。真正的目標（網域控制站、資料庫、檔案伺服器、備份系統）還在後面。橫向移動就是這中間的過程，也是防守方最有機會攔截的階段：初始入侵可能只有幾秒鐘，橫向移動往往持續數天到數週。

這個階段的核心是憑證。攻擊者不斷重複「在目前這台機器上找可用的憑證 → 用它連到下一台 → 在新機器上再找憑證」的循環，直到取得網域管理員權限。常見手法包括 Pass-the-Hash、Pass-the-Ticket、Kerberoasting、密碼噴灑、以及從瀏覽器與記憶體中竊取憑證。

防禦的關鍵是讓憑證不能重複使用：

- 本機管理員密碼隨機化（LAPS），避免一組密碼打通全公司
- 分層管理（tiering）——網域管理員帳號絕不登入一般工作站，否則其憑證會留在該機器的記憶體裡
- 網路分段，限制工作站之間的直接連線（多數企業的工作站根本不需要互連）
- 特權帳號啟用防釣魚 MFA

偵測的關鍵是東西向流量。多數組織的監控集中在對外連線，內網主機之間的橫向連線反而是盲區。工作站對工作站的 SMB／WMI／WinRM 連線、非管理時段的遠端執行、單一帳號短時間內登入多台主機，都是值得告警的訊號。

Initial access usually lands on a low-value machine — some employee's laptop. The real targets (domain controllers, databases, file servers, backup systems) are further in. Lateral movement is the journey between, and it is the defender's best interception window: initial compromise may take seconds, but lateral movement often runs for days or weeks.

The currency of this phase is credentials. The attacker repeats a loop — find usable credentials on this machine, use them to reach the next, harvest again — until they hold domain administrator rights. Common techniques include Pass-the-Hash, Pass-the-Ticket, Kerberoasting, password spraying, and stealing credentials from browsers and memory.

The defensive key is making credentials non-reusable:

- Randomise local administrator passwords (LAPS) so one password does not open the whole estate
- Tiering — domain admin accounts never sign in to ordinary workstations, or their credentials sit in that machine's memory
- Network segmentation limiting workstation-to-workstation connections (most estates have no legitimate need for them)
- Phishing-resistant MFA on privileged accounts

The detection key is east-west traffic. Most monitoring points outward, leaving internal host-to-host connections a blind spot. Workstation-to-workstation SMB/WMI/WinRM, remote execution outside maintenance windows, and one account authenticating to many hosts in a short window are all worth alerting on.

Windows 在 DNS 查不到某個主機名稱時，會退而使用 LLMNR 與 NBT-NS 向整個區網廣播「有誰是這個名字？」。這兩個協定沒有任何驗證機制——第一個回答的就被相信。

攻擊者只要在同一個網段安靜地監聽並搶答，就能把流量引到自己身上。而 Windows 在連接 SMB 等服務時會自動送出目前使用者的 NTLM 驗證憑據，攻擊者因此不必誘騙任何人，就能收到憑證材料，接著離線破解或直接轉手做中繼攻擊。

觸發條件比想像中常見：使用者打錯了共享資料夾名稱、某個舊腳本指向已下線的伺服器、或是 WPAD（自動代理探索）在沒有正確 DNS 記錄時發出的廣播。WPAD 冒充尤其危險，因為攻擊者可藉此成為受害者的網頁代理，看見並竄改其瀏覽流量。

防禦重點：

- 直接關掉 LLMNR 與 NBT-NS。這是少見的「關掉就解決、且幾乎無副作用」的措施——現代環境有正常運作的 DNS 就不需要它們。以群組原則統一停用
- 在 DNS 建立 WPAD 記錄（或封鎖該名稱），避免廣播外流
- 啟用 SMB 簽章，讓收到的憑據無法被中繼利用
- 網路分段，縮小廣播網域的範圍

偵測上可留意：同一主機頻繁回應各種不同名稱的解析請求，這在正常環境中不會發生。

When DNS cannot resolve a hostname, Windows falls back to LLMNR and NBT-NS, broadcasting to the whole local network: "who is this name?" Neither protocol has any authentication — whoever answers first is believed.

An attacker on the same segment need only listen quietly and answer first to pull traffic toward themselves. And because Windows automatically sends the current user's NTLM authentication material when connecting to services like SMB, the attacker collects credential material without tricking anyone, then cracks it offline or relays it onward.

The triggers are more common than you would think: a user mistyping a share name, an old script pointing at a decommissioned server, or WPAD (automatic proxy discovery) broadcasting when no DNS record exists. WPAD impersonation is especially serious, because it makes the attacker the victim's web proxy, able to see and modify their browsing.

Defensive priorities:

- Simply turn LLMNR and NBT-NS off. This is that rare control which solves the problem with almost no side effects — a modern environment with working DNS does not need them. Disable via group policy
- Create a WPAD record in DNS (or block the name) so the broadcast never escapes
- Enable SMB signing, so captured material cannot be relayed
- Segment the network to shrink broadcast domains

For detection: one host answering resolution requests for many different names, which does not happen in a healthy environment.

MCP 定義 AI agent 如何發現並呼叫外部能力：讀取檔案、查詢資料庫、呼叫 API、操作雲端資源。開發者架設 MCP server 把這些能力暴露給模型使用，agent 因此能實際做事而不只是回話。

從資安角度看，這帶來三個具體風險：

其一，機密以明文散落。 MCP server 的設定檔常直接放著 API 金鑰、資料庫連線字串與雲端憑證，位置在開發者的家目錄而非任何密鑰管理系統裡。資安團隊往往不知道這些檔案存在，也沒有納入盤點。

其二，權限給得太寬。 為了讓 agent 用起來順手，token 常被賦予遠超實際所需的範圍。一旦模型被操控，它能做的每件事都是攻擊者能做的事——這就是 OWASP LLM Top 10 說的「過度代理」。

其三，提示注入在此變成可執行的攻擊。 當 agent 讀進外部內容（網頁、issue、文件、程式碼註解）時，藏在裡面的指令可能觸發真實的工具呼叫。純聊天的模型被注入只是說錯話；能呼叫工具的 agent 被注入則是實際動作。

該做的事：盤點環境中實際在跑哪些 MCP server；設定檔的憑證改由密鑰管理系統提供；token 依最小權限重新核發；對會產生副作用的工具要求人工確認；記錄 agent 的工具呼叫並納入監控。

MCP defines how an AI agent discovers and calls external capabilities: reading files, querying databases, calling APIs, operating cloud resources. Developers stand up MCP servers to expose those capabilities to a model, so the agent can act rather than merely reply.

From a security standpoint this creates three concrete risks:

One: secrets scattered in plaintext. MCP server configuration files routinely hold API keys, database connection strings, and cloud credentials — sitting in a developer's home directory rather than any secrets manager. Security teams often do not know these files exist and have never inventoried them.

Two: over-broad permissions. To make the agent convenient, tokens are commonly issued with far more scope than needed. Once the model can be manipulated, everything it can do is something an attacker can do — what the OWASP LLM Top 10 calls excessive agency.

Three: prompt injection becomes executable. When an agent ingests external content — a web page, an issue, a document, a code comment — instructions hidden inside can trigger real tool calls. Injection against a chat-only model produces wrong words; injection against a tool-calling agent produces actions.

What to do: inventory which MCP servers actually run in your environment; move credentials out of config files and into a secrets manager; reissue tokens on least privilege; require human confirmation for side-effecting tools; log agent tool calls and bring them into monitoring.

Mimikatz 原本是為了展示 Windows 憑證儲存機制的弱點而寫的研究工具，如今是攻擊者與紅隊的標準配備。它的能力涵蓋從 LSASS 程序記憶體中取出已登入使用者的憑證材料、讀取本機 SAM 資料庫、匯出 Kerberos 票證、以及偽造 Golden／Silver Ticket。

理解它的重要性在於：它是一個樞紐。 前面提到的 Pass-the-Hash、Pass-the-Ticket 都需要先取得憑證材料，而這一步幾乎都由這類工具完成。因此阻斷憑證擷取，等於同時削弱下游一整串攻擊手法。

實務上要有心理準備：偵測「Mimikatz 這支程式」意義有限。原始碼公開，任何人都能改名、改特徵、重新編譯，或把功能整合進自製工具；同類工具（如各種 SAM/NTDS 匯出腳本）也不斷出現。要防的是行為，不是檔案。

防禦重點：

- 啟用 Credential Guard，把憑證材料隔離在虛擬化保護的環境中，讓一般的記憶體讀取拿不到東西。這是最根本的措施
- 限制本機管理員權限——沒有管理員權限就無法存取 LSASS
- 分層管理，減少高權限憑證出現在低信任機器上
- 啟用 LSA Protection（RunAsPPL）

偵測重點：監控對 LSASS 程序的異常控制碼存取（Sysmon Event ID 10 是常用來源），這比比對檔案雜湊值可靠得多——不論工具叫什麼名字，要讀 LSASS 就得留下這個痕跡。

Mimikatz began as research demonstrating weaknesses in how Windows stores credentials; it is now standard equipment for attackers and red teams alike. Its capabilities span extracting signed-in users' credential material from LSASS process memory, reading the local SAM database, exporting Kerberos tickets, and forging Golden and Silver Tickets.

Its importance is that it is a hinge. Pass-the-Hash and Pass-the-Ticket both require credential material first, and this class of tool is almost always how that step happens. So blocking credential extraction weakens an entire chain of downstream techniques at once.

Set expectations accordingly: detecting "the Mimikatz binary" is of limited value. The source is public, so anyone can rename it, alter its signatures, recompile, or fold the functionality into custom tooling — and comparable tools (assorted SAM and NTDS export scripts) keep appearing. Defend against the behaviour, not the file.

Defensive priorities:

- Enable Credential Guard to isolate credential material behind virtualisation-based security, so ordinary memory reads come back empty. This is the root measure
- Restrict local administrator rights — without them, LSASS is out of reach
- Tiering, to keep privileged credentials off low-trust machines
- Enable LSA Protection (RunAsPPL)

Detection priority: monitor anomalous handle access to the LSASS process (Sysmon Event ID 10 is a common source). That is far more durable than hash matching — whatever the tool is called, reading LSASS leaves this trace.

與 Pass-the-Hash 的差別在於連破解或竊取都省了。攻擊者站在中間，把受害者送來的驗證挑戰與回應原封不動轉發給真正的目標伺服器：受害者以為自己在跟檔案伺服器驗證，實際上攻擊者正拿著這組往返資料去登入網域控制站。

完整流程通常是：先用名稱解析毒化或其他方式讓受害者主動連上攻擊者機器 → 受害者的系統自動送出 NTLM 驗證 → 攻擊者即時轉發到選定的目標 → 取得該目標上受害者權限的存取。如果被中繼的是網域管理員的驗證，結果就是網域淪陷。

這是協定設計層次的問題：NTLM 的驗證流程本身沒有綁定「這次驗證是要給誰的」。

防禦重點：

- 啟用並強制 SMB 簽章——這是針對 SMB 中繼最直接有效的措施，簽章會讓轉發後的封包驗證失敗
- LDAP 啟用簽章與通道繫結（channel binding），封住中繼到目錄服務這條路
- 對外服務啟用 EPA（Extended Protection for Authentication），把驗證繫結到 TLS 通道
- 從源頭下手：關閉 LLMNR／NBT-NS，減少受害者被引導到攻擊者機器的機會
- 長期方向是逐步淘汰 NTLM，改用 Kerberos

偵測上，可留意同一組帳號的驗證在極短時間內出現在來源不一致的兩處，以及非預期主機對網域控制站發起的 LDAP 或 SMB 驗證。

The difference from Pass-the-Hash is that nothing needs cracking or even stealing. The attacker sits in the middle and forwards the challenge and response verbatim to a different target server: the victim believes they are authenticating to a file server, while the attacker uses that same exchange to sign in to a domain controller.

The usual chain: name-resolution poisoning (or something similar) makes the victim connect to the attacker, the victim's system automatically sends NTLM authentication, the attacker relays it in real time to a chosen target, and gains access there with the victim's privileges. Relay a domain administrator's authentication and the domain is gone.

This is a protocol design issue: NTLM's exchange does not bind an authentication to the service it was meant for.

Defensive priorities:

- Enable and require SMB signing — the most direct fix for SMB relay, since signing makes forwarded packets fail validation
- Enable LDAP signing and channel binding to close the path into directory services
- Enable EPA (Extended Protection for Authentication) on published services, binding authentication to the TLS channel
- Cut it off at the source: disable LLMNR/NBT-NS so victims are not lured to the attacker in the first place
- Long term, retire NTLM in favour of Kerberos

For detection: one account authenticating from inconsistent sources within moments, and unexpected hosts initiating LDAP or SMB authentication against domain controllers.

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.

多數人以為竊得雜湊值之後還要花時間破解才能用。在 NTLM 驗證裡不需要。 驗證流程比對的就是雜湊值本身，明文密碼只是用來算出雜湊值的中間產物。攻擊者取得雜湊值後即可直接用它完成驗證，密碼多長多複雜完全無關。

雜湊值的來源通常是已登入使用者留在記憶體（LSASS 程序）中的憑證材料，或是本機 SAM 資料庫、網域控制站的 NTDS.dit。取得這些需要本機管理員或更高權限——所以 Pass-the-Hash 是權限提升之後的擴散手法，不是初始入侵手法。

這個手法之所以長年有效，是因為它利用的不是漏洞而是協定的設計。真正的解法是減少可竊取的憑證與限制其可用範圍：

- 分層管理：高權限帳號絕不登入低信任層級的機器。網域管理員登入過的每一台工作站，都在記憶體裡留下可被竊取的材料
- 本機管理員密碼隨機化（LAPS）：讓同一組雜湊值無法橫掃全公司
- 限制本機管理員帳號的網路登入，讓竊得的本機憑證只在該台機器有效
- 啟用 Credential Guard，把憑證材料隔離在虛擬化保護的環境中
- 逐步汰換 NTLM，改用 Kerberos

偵測上可留意：使用本機帳號的網路登入（Logon Type 3）、單一帳號在短時間內對多台主機驗證、以及對 LSASS 程序的異常存取。

Most people assume a stolen hash still needs cracking before it is useful. Under NTLM it does not. Authentication compares the hash itself; the plaintext password is merely an intermediate value used to compute it. An attacker holding the hash can authenticate directly, and password length or complexity becomes irrelevant.

Hashes typically come from credential material left in memory (the LSASS process) by signed-in users, or from the local SAM database or a domain controller's NTDS.dit. Reaching those requires local administrator rights or higher — so Pass-the-Hash is a post-escalation spreading technique, not an initial access one.

It has stayed viable for years because it exploits protocol design rather than a bug. The real fix is reducing stealable credentials and limiting where they work:

- Tiering: privileged accounts never sign in to lower-trust machines. Every workstation a domain admin has logged into holds stealable material in memory
- Randomised local administrator passwords (LAPS), so one hash cannot sweep the estate
- Deny network logon for local administrator accounts, confining stolen local credentials to that machine
- Enable Credential Guard to isolate credential material behind virtualisation-based security
- Retire NTLM in favour of Kerberos over time

For detection: network logons using local accounts (logon type 3), one account authenticating to many hosts quickly, and anomalous access to the LSASS process.

Kerberos 的運作是「先取得票證，之後憑票證存取服務」。票證在有效期內就等同通行證，服務端不會再回頭問密碼。攻擊者從記憶體中竊得他人的票證後直接使用，即可冒充該使用者。

更嚴重的是偽造票證：

- Golden Ticket——取得網域的 krbtgt 帳號金鑰後，可自行簽發任意使用者、任意權限的票證，有效期可設得極長。這等同拿到網域的「印鈔機」，而且改一般使用者的密碼完全無效，必須輪換 krbtgt 金鑰兩次才能失效
- Silver Ticket——取得單一服務帳號的金鑰後偽造該服務的票證。範圍較小，但更隱蔽，因為驗證過程不會經過網域控制站，中央日誌上看不到

防禦重點：

- 嚴格保護網域控制站——krbtgt 金鑰外洩等於整個網域淪陷
- 定期輪換 krbtgt（需連續兩次，中間隔足夠時間讓現有票證自然過期）
- 分層管理，減少高權限票證出現在低信任機器上的機會
- 縮短票證有效期限

偵測上，Golden Ticket 常見的破綻是票證的有效期異常長、或票證中的帳號在網域中不存在；Silver Ticket 則要靠服務端主機的本機日誌與中央驗證紀錄比對——出現「有服務存取但無對應的網域驗證」就值得追查。

Kerberos works by obtaining a ticket first and using it for service access thereafter. Within its lifetime a ticket is the pass itself — the service never asks for a password again. An attacker who steals another user's ticket from memory can simply present it and be that user.

Forging tickets is worse:

- Golden Ticket — with the domain's krbtgt account key, an attacker can issue tickets for any user with any privileges and an arbitrarily long lifetime. It is the domain's money printer, and resetting user passwords does nothing; only rotating the krbtgt key twice invalidates them
- Silver Ticket — with a single service account's key, forge tickets for that service. Narrower in scope but stealthier, because validation never touches a domain controller and so leaves nothing in central logs

Defensive priorities:

- Guard domain controllers rigorously — a leaked krbtgt key means the whole domain is lost
- Rotate krbtgt periodically (twice, with enough time between for existing tickets to expire naturally)
- Tiering, to keep privileged tickets off low-trust machines
- Shorten ticket lifetimes

For detection, Golden Tickets often betray themselves through abnormally long lifetimes or accounts that do not exist in the domain. Silver Tickets require reconciling service host logs against central authentication records — service access with no corresponding domain authentication is worth investigating.

passkey 的核心是公開金鑰密碼學：註冊時裝置產生一對金鑰，私鑰留在裝置的安全區域從不外流，伺服器只保存公鑰。登入時伺服器送出挑戰，裝置用私鑰簽章回應。

它之所以能擋住 AiTM 釣魚，關鍵在來源綁定：簽章的內容包含發起請求的網域。攻擊者架的代理網域與真實網域不符，簽章驗不過，中間人拿到的東西沒有用。這是 passkey 相對於簡訊碼與 TOTP 的根本差異——後兩者可以被即時轉送，passkey 不行。

但「防釣魚」的保護範圍常被高估。 它保護的是登入的那一刻，不是身分生命週期的其他環節：

- 註冊流程：誘使受害者在攻擊者控制的情境下新增一把 passkey，等同給對方一把長期鑰匙
- 備援方式：帳號若仍保留簡訊或安全問題作為備援，攻擊者直接打最弱的那條路
- 既有工作階段：已通過驗證的 session cookie 被竊，不需要再經過任何登入
- 裝置端惡意程式：能操控本機的惡意程式可在使用者無感的情況下完成驗證

該做的事：導入 passkey 的同時移除弱備援方式；對「新增驗證方式」這個動作要求既有的強驗證並發出通知；監控 passkey 註冊事件，尤其是來源與既有裝置不符者。

Passkeys rest on public-key cryptography: at registration the device generates a key pair, the private key stays in the device's secure element and never leaves, and the server keeps only the public key. At sign-in the server issues a challenge and the device signs it.

What defeats AiTM phishing is origin binding: the signed data includes the domain that made the request. An attacker's proxy domain does not match the real one, the signature fails validation, and what the middleman captured is useless. That is the fundamental difference from SMS codes and TOTP, which can be relayed in real time.

But the scope of "phishing-resistant" is routinely overstated. It protects the moment of sign-in, not the rest of the identity lifecycle:

- Enrolment: trick the victim into adding a passkey under the attacker's control and you have handed over a durable key
- Fallback methods: if the account still keeps SMS or security questions as recovery, attackers simply take the weakest path
- Existing sessions: a stolen authenticated session cookie needs no sign-in at all
- Device malware: code that controls the endpoint can complete the ceremony without the user noticing

What to do: remove weak fallbacks as you roll passkeys out; require existing strong authentication plus a notification for the act of adding an authentication method; and monitor passkey registration events, especially from sources that do not match known devices.

傳統暴力破解是對一個帳號試上千組密碼，會迅速觸發帳號鎖定並產生明顯的失敗紀錄。密碼噴灑把方向轉了 90 度：拿一組密碼去試全公司幾千個帳號，每個帳號在鎖定閾值週期內只失敗一到兩次。

從單一帳號的角度看，這只是使用者偶爾打錯密碼，完全在正常範圍內。只有把所有帳號的失敗紀錄橫向彙整，才會看出「同一來源在短時間內對數百個帳號各失敗一次」這個明顯異常。這正是多數組織漏掉它的原因——監控是以帳號為單位設計的。

攻擊者用的密碼往往命中率意外地高：季節加年份的組合、公司名稱加數字、鍵盤序列、以及該產業的常見詞彙。在數千個帳號的組織裡，總會有人用。

防禦重點：

- 全面 MFA，尤其是對外可存取的服務（VPN、郵件、遠端桌面）。密碼猜中了但過不了第二因素，攻擊就止步
- 禁用常見密碼字典，這比要求複雜度更有效
- 監控要以來源為軸而非以帳號為軸：同一 IP／同一時間窗內對多個帳號的失敗驗證
- 留意「成功登入前有一連串跨帳號失敗」的模式，那通常代表已經猜中
- 停用或嚴格保護不再使用的舊帳號——它們常是最弱的一環

Classic brute force tries thousands of passwords against one account, which trips lockout quickly and leaves obvious failures. Password spraying rotates that by ninety degrees: take one password and try it against every account in the company, so each account sees only one or two failures per lockout window.

From any single account's perspective this is a user occasionally mistyping — entirely normal. The anomaly only appears when failures are correlated horizontally: one source failing once against hundreds of accounts in a short window. That is precisely why most organisations miss it — monitoring is designed per account.

The passwords attackers choose hit more often than you would expect: a season plus the year, company name plus digits, keyboard walks, and industry vocabulary. Across a few thousand accounts, someone is using one.

Defensive priorities:

- MFA everywhere, especially on externally reachable services (VPN, mail, remote desktop). A guessed password that cannot pass a second factor ends the attack
- Ban common-password dictionaries — more effective than complexity requirements
- Pivot monitoring from account to source: failed authentications from one IP or within one window across many accounts
- Watch for the pattern of a successful sign-in following a run of cross-account failures; that usually means they landed one
- Disable or tightly protect dormant legacy accounts, often the weakest link

程式把使用者提供的字串直接接到檔案路徑上時，攻擊者用 ../ 這類序列往上跳出預定目錄，就能觸及系統上的其他檔案。經典的讀取目標是設定檔與憑證檔案。

真正危險的是可以「寫入」的那一種。能讀檔已經是資訊外洩，但能把檔案寫到任意位置，通常直接等於遠端程式碼執行——寫進網頁根目錄就是一個 web shell，寫進排程或啟動目錄就是持久化。本站 2026-W34 的 VMware vCenter 漏洞正是這一型：路徑穿越被評為 CVSS 9.8，因為它導向任意程式碼執行。

過濾很容易做得不完整，常見的繞過方式包括 URL 編碼與雙重編碼、....// 這種過濾後反而還原成 ../ 的寫法、絕對路徑、以及 Windows 上的反斜線與 UNC 路徑。自己寫字串過濾幾乎一定會漏。

可行的做法：

- 不要用使用者輸入組路徑。改成索引或識別碼對照到伺服器端的白名單
- 必須用時，正規化（canonicalize）之後再驗證結果是否仍在允許的根目錄之下，而不是檢查輸入字串長什麼樣
- 以作業系統層級限制程序可及的檔案範圍（容器、chroot、最小權限帳號）
- 上傳的檔案存放於不可執行的位置

When a program concatenates a user-supplied string into a file path, an attacker uses sequences like ../ to climb out of the intended directory and reach other files. Classic read targets are configuration files and credential stores.

The genuinely dangerous variant is the writable one. Reading files is already a disclosure, but writing to an arbitrary location usually means remote code execution — into a web root it is a web shell; into a scheduled task or startup directory it is persistence. The VMware vCenter flaw in this site's 2026-W34 issue is exactly this shape: a path traversal rated CVSS 9.8 because it leads to arbitrary code execution.

Filtering is easy to get wrong. Common bypasses include URL encoding and double encoding, ....// (which filtering can collapse back into ../), absolute paths, and on Windows backslashes and UNC paths. Hand-rolled string filtering nearly always misses something.

What works:

- Do not build paths from user input. Map an index or identifier to a server-side allowlist instead
- Where you must, canonicalize first and then verify the result still sits under the permitted root — check the resolved path, not the shape of the input
- Constrain what the process can reach at the OS level (containers, chroot, least-privilege accounts)
- Store uploads somewhere non-executable

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.

郵件仍是最主要的初始入侵途徑，SEG 就是這條路上的第一道關卡。主要檢查項目：

- 寄件者真偽——SPF、DKIM、DMARC 驗證，以及顯示名稱與實際位址不符的偽冒
- 連結——比對惡意網址情資；較新的做法是改寫連結，在使用者點擊當下再檢查一次（因為攻擊者常在寄信後才把網頁改成惡意）
- 附件——靜態掃描加沙箱引爆，觀察實際行為
- 內容特徵——商業郵件詐騙（BEC）這類沒有惡意連結或附件的信，只能靠語意與情境判斷

現代釣魚的難處在於它未必帶惡意元件。BEC 信件裡什麼都沒有，只有一句「請把這筆款項改匯到新帳戶」；device code 釣魚的連結指向真正的官方登入頁。這兩種都不是掃描技術擋得住的，需要搭配身分層控制與人員流程。

驗證重點：BAS 對 SEG 的測項通常分成「帶可疑連結」與「帶惡意附件」兩型，用近幾週的新情資試打，看多少能穿透到信箱。

Email remains the dominant initial access vector, and the SEG is the first gate on that path. The main checks:

- Sender authenticity — SPF, DKIM, DMARC, plus display names that do not match the actual address
- Links — matched against malicious URL intelligence; newer products rewrite links and re-check at click time, because attackers often flip a page to malicious after delivery
- Attachments — static scanning plus sandbox detonation to observe real behaviour
- Content signals — business email compromise (BEC) carries no malicious link or attachment at all, leaving only semantic and contextual judgement

The hard part is that modern phishing may carry no malicious component. A BEC message contains nothing but a sentence asking you to redirect a payment; device code phishing links to the genuine official sign-in page. Neither is a scanning problem — they need identity-layer controls and human process.

What to validate: BAS test cases for SEG usually split into "mail with suspicious link" and "mail with malicious attachment", replaying recent intelligence to see how much reaches the mailbox.

只要應用程式會依使用者提供的網址去抓取資源——預覽連結、匯入遠端檔案、Webhook、產生縮圖、健康檢查——就可能有 SSRF。攻擊者把網址換成內部位址，伺服器就成了他的代理人。

在雲端環境中破壞力最大。多數雲端平台提供一個只有本機能存取的 metadata 服務，用來讓執行個體取得自己的臨時憑證。一旦 SSRF 能打到那個位址，攻擊者就取得該執行個體的雲端存取權杖——接著能做什麼，取決於那台機器的 IAM 權限有多寬。這正是「最小權限」在雲端特別重要的原因。

防禦不能靠黑名單。過濾內部 IP 字串會被各種寫法繞過：十進位或十六進位的 IP 表示法、DNS 解析到內部位址的網域、0.0.0.0、IPv6 對應位址、以及重新導向（先給一個外部網址，回應 302 指向內部）。可行的做法是：

- 改用白名單，只允許明確列出的目的地
- 在網路層隔離：讓應用程式伺服器根本沒有到內網與 metadata 服務的路由
- 強制使用需要權杖的 metadata 服務版本（雲端平台多已提供），讓單純的 GET 拿不到憑證
- 解析後再驗證一次，且驗證的必須是實際連線的位址，不是使用者給的字串
- 停用不必要的重新導向跟隨

Any application that fetches a URL supplied by a user — link previews, remote file import, webhooks, thumbnail generation, health checks — can have SSRF. Swap the URL for an internal address and the server becomes the attacker's proxy.

The impact is greatest in cloud environments. Most cloud platforms expose a metadata service, reachable only from the instance itself, that hands out temporary credentials. Once SSRF can reach that address, the attacker holds that instance's cloud access token — and what follows depends entirely on how broad its IAM permissions are. This is precisely why least privilege matters so much in cloud.

Blocklists do not work. Filtering internal IP strings is bypassed by decimal or hexadecimal IP notation, domains that resolve to internal addresses, 0.0.0.0, IPv6-mapped addresses, and redirects (supply an external URL that 302s inward). What does work:

- Use an allowlist of explicitly permitted destinations
- Isolate at the network layer so the application server has no route to internal ranges or the metadata service at all
- Require the token-based metadata service version (most platforms offer one), so a plain GET yields nothing
- Re-validate after resolution, and validate the address actually connected to, not the string the user supplied
- Disable redirect following where it is not needed

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

常見做法是修改圖片像素的最低位元（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.

所有對外的網頁流量都經過 SWG，它依網址分類、威脅情資、檔案掃描與內容政策決定放行或阻擋。典型的攔截點有兩處：使用者要連到惡意網域時（釣魚頁、C2 中繼站），以及惡意檔案要下載進來時。

因為現代流量幾乎全是 HTTPS，SWG 要看得到內容就得做 TLS 攔截解密——這帶來憑證管理、隱私、以及憑證釘選（certificate pinning）應用相容性的問題，實務上通常要維護一份不解密的例外清單。

驗證重點：SWG 的防護力取決於威脅情資有多新。上週才出現的釣魚網域，你的閘道今天認不認得？這正是 BAS 用 IOC 型測項驗證 SWG 的原因——拿最近幾週的新情資去試打，看擋不擋得下來。

近年這個角色多半被併進 SASE／SSE 這類雲端遞送的架構，讓遠端工作者不必回連公司網路也受同一套政策保護。

All outbound web traffic passes through the SWG, which decides to allow or block based on URL categorisation, threat intelligence, file scanning, and content policy. There are two typical interception points: when a user tries to reach a malicious domain (phishing pages, C2 relays) and when a malicious file is being downloaded.

Since nearly all traffic is HTTPS, seeing content requires TLS interception — which brings certificate management, privacy, and compatibility headaches with certificate-pinned applications, so in practice you maintain a do-not-decrypt exception list.

What to validate: an SWG is only as good as its intelligence freshness. Does your gateway recognise a phishing domain that appeared last week? That is exactly why BAS uses IOC-type test cases here — replay the last few weeks of indicators and see what gets through.

In recent years this role has largely folded into cloud-delivered SASE/SSE architectures, so remote workers get the same policy without backhauling to the office network.

傳統防火牆看的是 IP 與連接埠——它無法分辨一個正常的 HTTP 請求與一個帶著 SQL 注入載荷的 HTTP 請求，因為兩者都是往 443 埠的合法連線。WAF 補的就是這一層：解析請求的路徑、參數、標頭與內容，比對攻擊特徵或行為規則。

典型覆蓋的攻擊類型：SQL／指令／LDAP／XML／NoSQL 注入、跨站腳本（XSS）、伺服器端請求偽造（SSRF）、路徑穿越、本地與遠端檔案包含（LFI／RFI），以及 Log4Shell、Spring4Shell 這類特定漏洞的利用特徵。

WAF 最重要的定位是「爭取時間」，不是「取代修補」。當一個重大漏洞公開而你的系統還來不及更新時，WAF 規則可以先擋住已知的利用手法，讓你有時間安排修補。但它擋的是已知的攻擊形態，繞過技巧（編碼變形、分段請求、參數污染）層出不窮，把 WAF 當成唯一防線是危險的。

驗證重點：BAS 對 WAF 的測項數量通常最龐大——同一種攻擊會有數十上百種變形寫法（不同編碼、不同注入位置），驗證的是規則覆蓋的廣度，而不只是「有沒有開」。

A traditional firewall sees IPs and ports — it cannot distinguish a normal HTTP request from one carrying a SQL injection payload, because both are legitimate connections to port 443. The WAF fills that layer: it parses the request path, parameters, headers, and body, matching attack signatures or behavioural rules.

Typical coverage: SQL / command / LDAP / XML / NoSQL injection, cross-site scripting (XSS), server-side request forgery (SSRF), path traversal, local and remote file inclusion (LFI/RFI), and exploitation signatures for specific flaws like Log4Shell and Spring4Shell.

A WAF's real job is buying time, not replacing patching. When a serious vulnerability drops and you cannot update yet, WAF rules can block known exploitation while you schedule the fix. But it blocks known attack shapes, and bypass techniques — encoding tricks, request splitting, parameter pollution — keep coming. Treating a WAF as your only line of defence is dangerous.

What to validate: WAF test cases usually dominate a BAS matrix by volume, because one attack class has dozens or hundreds of variant encodings and injection points. What you are measuring is rule breadth, not merely whether the product is switched on.

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.