Skip to main content

External threat-intel enrichment

VirusTotal and AbuseIPDB reachable through an automation rule's enrich action — and the precise process boundary that determines whether it actually runs.

Written for whoever runs IT7 min readUpdated

VirusTotal and AbuseIPDB reputation lookups can now enrich a SIEM incident automatically, through an automation rule's enrich action. This article is about precisely where that reaches and where it does not — the reachability boundary here is exact and worth reading carefully rather than assuming the obvious answer.

Configuring the providers

Connect VirusTotal and/or AbuseIPDB with your own API key through the integrations catalog, per tenant — the full walkthrough, including how each provider scores an indicator and what each one covers, is in Connecting VirusTotal or AbuseIPDB for threat-intel lookups. That article covers the credential and the manual, on-demand test lookup you can run from the integration screen itself. This article covers the other path in: what happens when an automation rule's enrich action reaches for the same providers on its own.

Reachable only when the rule fires in the live API process

Concretely: if an automation rule's enrich action runs because you changed an incident's status, severity, assignee or tags in the console (an incident_updated trigger, running in the API process), it can reach VirusTotal or AbuseIPDB for the incident's indicators, using your tenant's own connected credentials. If the same rule's enrich action runs because a scheduled rule just opened the incident in the first place (an incident_created trigger from the worker), it gets watchlist enrichment only — the external lookup is silently unavailable in that path, not an error, just not reached.

There is no direct "look this indicator up" button anywhere in the SIEM console today. The only two ways to trigger a VirusTotal or AbuseIPDB lookup are the manual test lookup on the integration's own configuration screen (a connectivity check, not tied to any incident) and an automation rule's enrich action under the process boundary above.

What is explicitly not built

Two related capabilities are sometimes assumed to come with this and do not exist at all — stated plainly so you do not plan around either:

  • GeoIP enrichment of log events. Nothing stamps a country, city or ASN onto an ingested log event. If you need geography on an event today, it has to already be present in the source data — see the region/cell fields discussed in Searching your logs, which are currently written empty for every collected event.
  • TAXII/STIX threat-intel ingestion. There is no TAXII feed subscription and no STIX indicator ingestion pipeline for the SIEM module. If you are looking for bulk indicator-of-compromise feeds rather than on-demand reputation lookups, that is a different, XDR-side mechanism — see Threat-intelligence feeds, which covers a distinct set of eleven subscribable feeds and is honest about its own narrow match path (only file hashes are ever automatically matched there). Do not conflate the two: this article's VirusTotal/AbuseIPDB enrichment is an on-demand, per-indicator lookup through the automation engine; the XDR feeds article is a different, bulk-subscription mechanism entirely.

What to read next

  1. Connecting VirusTotal or AbuseIPDB for threat-intel lookups — getting the credential connected in the first place.
  2. Automation rules and proposals — the enrich action and the process-boundary distinction in full context.
  3. Lookups and watchlists — the enrichment path that does work from the worker process.

Was this article wrong?

If a procedure here does not match what you see, or a limit we described has changed, tell us and we will fix the page. Email us about this article, or see how to get help if you need an answer rather than a correction.

Everything in logs and detection