PERSONA
Detection Engineer
CATEGORY
Integration
ENDPOINTS
4 used
UPDATED
April 2026
USE CASE · DETECTION ENGINEER

One threat intelligence API for your SIEM, detections, and dashboards

In-house TI aggregation is glue code — N rate-limiters, N auth schemes, N response schemas, and a Slack channel full of 'the VT API changed again'. DFIR Platform exposes one endpoint, one Bearer token, one normalized response schema, and one rate-limit bucket across every source a detection engineer actually uses.
CONTEXT

In-house TI aggregation is a maintenance tax

Every security engineering team eventually tries to build the same thing: a service in front of VirusTotal, AbuseIPDB, GreyNoise, Shodan, and OTX that the SIEM / detection pipeline / analyst dashboards can call. The first version ships in a week. The long tail — handling rate limits per provider, retrying when one source is down without failing the whole call, keeping up with schema changes, rotating API keys across six vendors — turns into a permanent part of someone's week forever.
PAIN POINTS
  1. Each TI source ships a different auth model (header token, query param, basic auth, OAuth) and a different error shape.
  2. Rate limits diverge: VT is per-minute, AbuseIPDB is per-day, Shodan is per-query-credit — the glue code has to reconcile all three.
  3. Response schemas change under you — detection rules break silently when a provider renames a field.
  4. Key rotation across six vendors is a quarterly chore the on-call team inherits.
The reality
“Each TI source ships a different auth model (header token, query param, basic auth, OAuth) and a different error shape.”
CAPABILITIES

The endpoints that solve it

The /v1/enrichment/lookup endpoint is the building block most detection engineers actually want: submit IOCs, receive a normalized verdict aggregated across every applicable source. Pair it with /v1/ai/threat-profile for narrative context in analyst dashboards, or /v1/ai/detect to turn observed IOC patterns into Sigma / YARA / KQL rule drafts. Versioning is explicit; schema changes are announced in the changelog.

Normalized IOC enrichment

3 credits / IOC
POST /v1/enrichment/lookup

Accepts an indicators[] array of mixed IPs, domains, URLs, and hashes. Each indicator returns a single normalized verdict aggregated across up to 11 sources per IP (VirusTotal, AbuseIPDB, GreyNoise, Shodan, Censys, OTX, urlscan, Pulsedive, ThreatFox, Hybrid Analysis, IPVoid), 8 per domain/URL, 6 per hash.

Threat-actor profile

20 credits
POST /v1/ai/threat-profile

Generate a structured written brief on a named threat actor — TTPs, associated malware families, historic victimology. Feeds analyst dashboards or the 'context' panel on a detection alert.

Detection-rule generation

15 credits
POST /v1/ai/detect

Given an IOC set or an observed pattern, generate a draft detection rule in Sigma, YARA, or SIEM-native syntax. Useful as a starting point for rule engineering on novel campaigns; always reviewed before production.

Stable response schema

All response fields are versioned under /v1. Additive changes are announced in the changelog; breaking changes bump the major version. Your SIEM's ingest pipeline does not rebase every quarter.

WORKFLOW

The canonical detection-engineering integration

The standard shape is a thin adapter in front of your SIEM or detection pipeline that calls /v1/enrichment/lookup when a rule fires, attaches the normalized verdict to the alert, and (optionally) asks /v1/ai/detect to draft a tighter rule for the observed pattern. Below is the minimal Python — swap in your SIEM's SDK and the logic is identical.
$ dfir-lab run threat-intelligence-api
import os, requests

API = "https://api.dfir-lab.ch"
KEY = os.environ["DFIR_API_KEY"]
HDRS = {
    "Authorization": f"Bearer {KEY}",
    "Content-Type": "application/json",
}

def enrich(indicators: list[dict]) -> dict:
    """Called from the SIEM adapter when a rule fires."""
    r = requests.post(
        f"{API}/v1/enrichment/lookup",
        json={"indicators": indicators},
        headers=HDRS,
        timeout=30,
    )
    r.raise_for_status()
    return r.json()

# Example: a detection rule fires on outbound traffic to an unusual IP
result = enrich([
    {"type": "ip",     "value": "45.155.205.233"},
    {"type": "domain", "value": "update-services.top"},
])

# result["indicators"][i] includes:
#   verdict          -> clean | suspicious | malicious
#   confidence       -> 0.0 .. 1.0
#   sources          -> per-source raw detail
#   sources_consulted, first_seen, last_seen, tags

# Optional: generate a detection-rule draft for this pattern
rule_draft = requests.post(
    f"{API}/v1/ai/detect",
    json={"indicators": result["indicators"], "format": "sigma"},
    headers=HDRS,
).json()
One Bearer token, one schema, one retry path — instead of N per-vendor adapters.
  1. 01
    Step 01

    Adapter

    Drop a thin HTTP wrapper into your detection pipeline or SIEM ingestion layer. One function, one auth scheme, one retry path.

  2. 02
    Step 02

    Enrich on rule fire

    When a detection rule fires, submit the observed IOCs to /v1/enrichment/lookup. Attach the normalized verdict to the alert payload.

  3. 03
    Step 03

    Route

    Use the aggregated verdict and confidence score to drive routing — malicious + high-confidence escalates to on-call; clean + high-confidence suppresses the alert with an audit trail.

  4. 04
    Step 04

    Contextualize

    For analyst-facing dashboards, pull threat-actor context with /v1/ai/threat-profile and attach it to the alert detail view.

  5. 05
    Step 05

    Iterate

    For novel patterns, /v1/ai/detect drafts a Sigma / YARA / KQL rule scoped to the observed IOCs. Review, tune, promote to production.

PRICING

Pricing that tracks your workload

Sustained SIEM-side automation — even a lean detection team enriching 30–50 alerts a day — lands in Professional territory once you multiply across the business month. Starter covers bursty or dashboard-only usage; Enterprise is where you move if an entire detection pipeline hits tens of thousands of alerts.
Recommended tier
Professional
2,500 credits / month
Entry price
$99/mo
  1. 01

    Lean detection team — 40 alerts/day × 2 IOCs each

    40 × 2 × 3 × 22 business days = 5,280 credits/month
    Exceeds Professional (2,500) — move to Professional + 5,000-credit top-up, or Enterprise if traffic grows.
  2. 02

    Dashboard-only usage — 20 enrichments/day

    20 × 3 × 22 = 1,320 credits/month
    Fits Professional ($99, 2,500 credits) with headroom; Starter ($29, 500) is too tight for sustained daily use.
  3. 03

    Small team evaluation — 5 enrichments/day

    5 × 3 × 22 = 330 credits/month
    Fits Starter ($29, 500 credits) comfortably with ~170 credits spare for occasional AI rule drafts.
FAQ

Frequently asked

Q / 01
Is this a TI feed or a TI API?
It is an on-demand enrichment API — you submit indicators and receive normalized verdicts. It is not a push feed of curated indicators. If your architecture expects a STIX/TAXII stream, this is complementary rather than a replacement.
Q / 02
What happens when one upstream source is down?
The endpoint is designed to degrade gracefully. Each response includes a sources_consulted array — if GreyNoise or AbuseIPDB times out on a request, the aggregate verdict is computed from the sources that did respond, and the missing source is flagged in the response rather than failing the whole call.
Q / 03
How stable is the response schema?
All endpoints are versioned under /v1. Additive changes (new fields) are announced in the changelog; breaking changes bump the major version and run both versions in parallel during the migration window. You should not need to rewrite parsers on a regular cadence.
Q / 04
Can I use this from Splunk / Elastic / Sentinel?
Yes — the endpoint is a plain HTTP POST with a Bearer token, which every major SIEM can call from a search command, an ingest enrichment action, or a playbook. The Splunk-specific pattern is covered in a separate use case.
Q / 05
Is there a STIX / OpenCTI bridge?
The response JSON maps cleanly to STIX 2.1 Indicator objects — there is no first-party STIX renderer yet, but the field mapping is documented and teams commonly run the translation in their own pipeline. A native bridge is on the roadmap.
Q / 06
How does pricing compare to buying VT + AbuseIPDB + Shodan separately?
Commercial tiers of the big three TI sources run into four-to-five-figure annual spend before you count the engineering time to stitch them together. A Professional plan covers most detection-engineering workloads at $99/mo flat with no glue code, which is usually the real win — the money saved is secondary to the team-hours not spent on adapter maintenance.
Ready when you are

Stop triaging by hand.

Create a free account — 100 credits per month, no credit card. Or keep browsing to find the use case that matches your workflow.