Skip to content

New: Microsoft Sentinel TAXII integration is in technical preview.Read the integration guide

ELLIOELLIO Documentation

CVE watchlist

The ellio_watched_cve_exploitation rule connects two facts: which CVEs each attacking IP actively exploits (observed by ELLIO) and which CVEs you actually care about (your watchlist). A hit means: someone who exploits a vulnerability you have is touching your perimeter right now - simultaneously a HIGH alert and a patch-prioritization signal.

How the matching works

Section titled “How the matching works”

ELLIO ships the CVEs it observed each IP exploiting; the parser writes them onto the entity as labels in metadata.threat.category_details, prefixed with cve::

category_details: [
  "classification:malicious",
  "cve:CVE-2018-10561",
  "cve:CVE-2018-10562",
  ...
]

The rule binds each label and keeps the ones present in your reference list:

$ioc.graph.metadata.threat.category_details = $cve
$cve in %ellio_watched_cves

Because the list contains only cve:-prefixed strings, every other label self-filters - no regex needed. This is also why the entry format matters:

  • entries must carry the cve: prefix: cve:CVE-2024-3400, not CVE-2024-3400
  • matching is exact and case-sensitive: use the canonical uppercase CVE- form

Create the list

Section titled “Create the list”

The list is a tenant reference list named ellio_watched_cves, syntax type STRING. The rule will not even validate until it exists.

In the UI: open the reference lists page under detections, create ellio_watched_cves (type String), and add one entry per line:

cve:CVE-2024-3400
cve:CVE-2023-4966
cve:CVE-2018-13379

With the secops CLI:

Terminal window
secops reference-list create --name ellio_watched_cves --syntax-type STRING \
  --entries "cve:CVE-2024-3400,cve:CVE-2023-4966"


# maintain it from a file, one entry per line
secops reference-list update --name ellio_watched_cves --entries-file watched_cves.txt

What a hit looks like

Section titled “What a hit looks like”

When the rule fires, its outcome carries exactly what you need:

Outcome variable Meaning
$matched_cve which watched CVEs the attacker exploits (cve: labels that matched)
$risk_score the indicator’s current ELLIO risk score
$targets_hit how many of your hosts it touched in the window

What belongs on the watchlist

Section titled “What belongs on the watchlist”

Treat the list as “CVEs we are actually exposed to” - edge devices, VPN appliances, and web frameworks in your stack - ideally exported from your vulnerability management rather than hand-curated. Keep it small and current: a bloated list degrades toward the generic exploitation rule that already exists at MEDIUM. The sharp semantics come from the intersection - actively exploited and present in your estate and aimed at you.

Variants

Section titled “Variants”

The same pattern works for any label family the parser emits. A behavior-tag watchlist (tag_id: prefix - for example specific botnet or exploit-kit tags) or a kill-chain watchlist (kill_chain: prefix) is a copy of the rule with a different list - see the data model for the full label inventory.