From a CVE to a detection: from the advisory to a rule that catches the attack

A critical CVE drops, you prioritize it (EPSS, KEV, your exposure) and patch what you can. But patching takes time, and meanwhile you need to know if you're being attacked through it. The problem: a CVE advisory describes what breaks, almost never how to detect it. Here's the method to close that gap.

The advisory has more clues than it seems

Before writing anything, extract four things from the CVE text:

• Service and port: is it a web panel (443), SSH (22), SMB (445), an appliance on an odd port? That tells you where to look.
• Vector: command injection, path traversal, deserialization, file upload? That tells you what shape the request or process has.
• Outcome: RCE, escalation, exfiltration? That tells you what happens next (child processes, outbound connections).
• Product/version: to scope the affected hosts in your inventory.

A command injection in an appliance's HTTP API with RCE translates, almost by itself, into: suspicious request to the service port → the service process spawns sh/cmd → unexpected outbound connection.

From clues to concrete signals

Now map each clue to telemetry you already have:

• The port → your ports reference reminds you of the service and its risk.
• The "what happens next" → on Windows, process creation (event 4688 / Sysmon 1), network connections (Sysmon 3) and registry/disk writes. On Linux, execution and outbound connections from the service process.
• The attack phase → place it on MITRE ATT&CK (execution, persistence, lateral movement) to measure your coverage.

An anomalous parent (a web server suddenly parenting cmd.exe) is usually a better signal than the exact exploit signature: payloads mutate, behavior less so.

The Sigma skeleton, then to your SIEM

Sigma lets you write the rule once and convert it to KQL, SPL, Elastic or Wazuh. A typical skeleton for the case above:

title: Possible exploitation of CVE-XXXX-YYYY (appliance RCE)
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: '\httpd.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  condition: selection
level: high
falsepositives:
  - Legitimate admin scripts of the service itself

Fill in the real ParentImage, tune the selection and document false positives. Before pushing it, measure it.

Don't forget the network signal

Many exploits show up better going out than coming in: the compromised appliance calling a new IP (Sysmon 3, or your firewall/proxy logs). Pair the host signal with the network one and you'll have a detection far more robust than any payload signature.

Checklist

• ✅ Extract from the advisory: service/port, vector, outcome and version.
• ✅ Translate the "what happens next" into events you already log (4688, Sysmon 1/3).
• ✅ Detect behavior (anomalous parent-child, network egress), not just the exploit signature.
• ✅ Write it in Sigma, refine it and measure it before pushing to the SIEM.
• ✅ Pair host signal + network signal.

Patching closes the door; detecting tells you who tried to get in while you were closing it. You need both.

Sergio Belmonte Morales
Cybersecurity Analyst · SOC · Sentinel/KQL specialist