SIEM Bot Detection: Splunk, CrowdStrike & Datadog Setup

SIEM bot detection starts by sending labeled automation events, not raw access logs, into the tools your analysts already use. Without that label, credential stuffing, scraping, and automated probing look like ordinary authentication failures and HTTP requests.

That credential stuffing run hitting your login page at 3 AM? It looks like normal authentication failures. That scraper pulling your pricing pages? Just another HTTP 200. That vulnerability scanner probing your API paths? Lost in the noise of legitimate traffic.

WebDecoy forwards each detection it records to Splunk (HTTP Event Collector), CrowdStrike Falcon LogScale, Datadog Logs, or any HTTPS endpoint through a signed webhook. This guide covers what those events actually contain, how to set each one up, and searches written against the real field names.

The Bot Visibility Problem in Security Operations

Traditional SIEMs are built to correlate known threats: malware signatures, CVE exploits, suspicious login patterns. They excel at connecting dots when the dots are labeled.

Bot attacks create unlabeled dots.

A careful scraper does not trigger your IDS. It does not match a malware hash. It generates legitimate-looking HTTP requests that your WAF waves through.

Consider what your SIEM sees during a typical bot attack:

2025-11-27T03:14:22Z web-01 nginx: 192.168.1.100 - - "POST /api/login HTTP/1.1" 401 0.023s
2025-11-27T03:14:22Z web-01 nginx: 192.168.1.101 - - "POST /api/login HTTP/1.1" 401 0.019s
2025-11-27T03:14:23Z web-01 nginx: 192.168.1.102 - - "POST /api/login HTTP/1.1" 401 0.021s

Three failed logins from three IPs. Could be a botnet cycling through a credential list. Could be three users who forgot their passwords. The access log cannot tell the difference.

A WebDecoy detection adds the missing label: this IP touched a decoy, tripped a sensor, or scored as automation, with a score, a threat level, and a category. Once that event sits next to your auth logs, you can join on the IP address.

What Gets Forwarded

WebDecoy has four ways to get detections out:

A few things to know before you design around them:

• They forward, they do not act. These integrations deliver detection events. They do not block traffic, run SOAR playbooks, or create cases. What your SIEM does with the event is up to your own rules.
• There is no dedicated Elastic, Syslog, or CEF output. If you run Elastic Security or another SIEM, point a webhook at an HTTPS receiver you control (for example, a small service that verifies the signature and writes to Elasticsearch).
• Events are compact by design. For full detail on one detection (every scoring signal, the MITRE ATT&CK tactic mapping, fingerprints), fetch it from the API with the detection_id: GET /organizations/{org}/detections/{id}.
• Plan tier. Webhooks and the Splunk, CrowdStrike, and Datadog integrations come with every paid plan, starting with Starter. See plans and billing.

Event types and filters

Splunk, CrowdStrike, and Datadog integrations each have trigger toggles (On Detection, On High Risk, On Rule Enforced) and optional filters (a minimum score, and a list of specific decoys). Splunk and Datadog label each event with an event_type:

CrowdStrike’s high-risk trigger uses the threat level instead: it fires on HIGH or CRITICAL.

Splunk (HTTP Event Collector)

Step 1: Create an HEC token in Splunk

1. In Splunk Web, go to Settings → Data Inputs → HTTP Event Collector
2. Under Global Settings, make sure tokens are enabled
3. Click New Token, name it (for example “WebDecoy Integration”)
4. Choose the index you want WebDecoy events in, then submit and copy the token

Step 2: Add the integration in WebDecoy

Go to Integrations → Splunk and click Add Splunk Integration. The fields are:

Click Test to send a test event, then check that it arrived:

index=<your index> source=webdecoy event_type=test

Event format

Each detection is posted as one HEC event. Fields that have no value for a given detection are left out rather than sent as null.

Illustrative example:

{
  "time": 1732691662.123,
  "host": "webdecoy",
  "source": "webdecoy",
  "sourcetype": "webdecoy:detection",
  "index": "security",
  "event": {
    "detection_id": "8f0c2d4e-...",
    "event_type": "high_risk_detection",
    "rules_enforced": false,
    "timestamp": "2025-11-27T03:14:22Z",
    "organization_id": "…",
    "property_id": "…",
    "decoy_id": "…",
    "ip_address": "203.0.113.45",
    "user_agent": "python-requests/2.31.0",
    "source_type": "decoy_link",
    "unified_score": 87,
    "bot_score": 92,
    "threat_level": "HIGH",
    "threat_category": "scanner",
    "confidence": 0.9,
    "request_method": "GET",
    "is_proxy": true,
    "geo_country": "…",
    "geo_city": "…",
    "abuse_confidence_score": 97,
    "reverse_dns_hostname": "…"
  }
}

The full set of event fields:

There is no JA3/JA4 fingerprint, MITRE mapping, or request path in the Splunk event. Those live on the detection itself, available through the API.

Field extraction

Splunk extracts JSON fields automatically for the _json sourcetype. If you keep the default webdecoy:detection sourcetype, either set KV_MODE = json for it in props.conf or add | spath to your searches. The searches below assume the fields are extracted.

Searches

Detections by threat level

index=security source=webdecoy
| stats count by threat_level

High-risk detections, highest score first

index=security source=webdecoy threat_level IN ("high", "critical")
| table _time, ip_address, source_type, threat_category, unified_score, user_agent
| sort - unified_score

Top sources by volume and score

index=security source=webdecoy
| stats count, max(unified_score) as max_score, values(threat_category) as categories by ip_address
| sort - count
| head 20

Detections from anonymizing networks

index=security source=webdecoy (is_vpn=true OR is_proxy=true OR is_tor=true)
| stats count by ip_address, geo_country

Detection volume by sensor

index=security source=webdecoy
| timechart span=1h count by source_type

Correlating with authentication logs

This is where the SIEM earns its keep. Join WebDecoy’s labeled IPs against successful logins from the same addresses. Adjust the auth index and field names to your own data:

index=auth action=success
    [ search index=security source=webdecoy threat_level IN ("high", "critical") earliest=-2h
      | stats count by ip_address
      | rename ip_address as src_ip
      | fields src_ip ]
| table _time, src_ip, user, app

If a source that tripped a decoy also logged in successfully, that account deserves a look.

CrowdStrike Falcon LogScale

Step 1: Create an ingest token

1. Log into Falcon LogScale (for example https://cloud.us.humio.com, or your regional URL)
2. Open the repository you want the events in
3. Go to Settings → Ingest Tokens → Add Token, name it, and copy it

Step 2: Add the integration in WebDecoy

Go to Integrations → CrowdStrike and click Add CrowdStrike Integration:

Event format

LogScale receives an HEC-format event with these fields in event: detection_id, timestamp, detection_type (the sensor source, such as decoy_link), threat_level, source_ip, user_agent, referer, unified_score, confidence, threat_category, cryptographic_trust, signature_verified, signature_agent, property_id, organization_id, decoy_id, rule_enforced, request_method, and the detection’s raw fingerprint and metadata objects when present. The event also carries #severity, #product (webdecoy), and #detection_source fields.

Note that the IP field is source_ip here, not ip_address as in Splunk and Datadog.

Queries

Depending on your parser, fields may appear at the top level or under an event. prefix. Check one event first and adjust. With top-level fields:

High and critical detections

sourcetype="webdecoy:detection"
| threat_level=/^(high|critical)$/i
| sort(@timestamp, order=desc)

Top sources

sourcetype="webdecoy:detection"
| groupBy(source_ip, function=[count(), avg(unified_score)])
| sort(_count, order=desc)
| head(20)

Detections by sensor

sourcetype="webdecoy:detection"
| groupBy(detection_type, function=count())

From there, the LogScale repository is yours: correlate source_ip with your other Falcon data, build dashboards, or alert on it with your own LogScale alerts. WebDecoy does not trigger Falcon Fusion workflows or modify your IOC lists.

Datadog Logs

The Datadog integration is a log integration, not a metrics one. Each detection becomes one log entry in the Datadog HTTP logs intake.

Setup

1. In Datadog, go to Organization Settings → API Keys and create a key (no application key needed)
2. In WebDecoy, go to Integrations → Datadog → Add Datadog Integration
3. Enter the API Key, your Site (datadoghq.com, us3.datadoghq.com, us5.datadoghq.com, datadoghq.eu, or ap1.datadoghq.com), the Service Name and Source (both default to webdecoy), and any extra Tags
4. Click Test, then search service:webdecoy in Live Tail

Log format

Illustrative example:

{
  "message": "High risk detection: bot_score=92.0 ip=203.0.113.45",
  "ddsource": "webdecoy",
  "ddtags": "env:production,event_type:high_risk_detection,team:security",
  "hostname": "webdecoy",
  "service": "webdecoy",
  "status": "error",
  "@timestamp": "2025-11-27T03:14:22Z",
  "attributes": {
    "detection_id": "8f0c2d4e-...",
    "event_type": "high_risk_detection",
    "rules_enforced": false,
    "timestamp": "2025-11-27T03:14:22Z",
    "decoy_id": "…",
    "organization_id": "…",
    "property_id": "…",
    "ip_address": "203.0.113.45",
    "user_agent": "python-requests/2.31.0",
    "bot_score": 92
  }
}

status is error for high-risk detections, warning for rule enforcement, and info otherwise. The Datadog log does not carry unified_score, threat level, or GeoIP; fetch the detection by detection_id when you need them.

Monitors

logs("service:webdecoy @attributes.bot_score:>=80").index("*").rollup("count").last("5m") > 0

logs("service:webdecoy @attributes.event_type:detection").index("*").rollup("count").last("15m") > 100

Webhooks: Elastic and Everything Else

For a SIEM without a dedicated integration, use a webhook. Go to Integrations → Webhooks → Add Webhook, give it an HTTPS URL, and pick triggers. Every request is a POST with these headers: X-WebDecoy-Signature (HMAC-SHA256 of the raw body, as sha256=<hex>), X-WebDecoy-Event, X-WebDecoy-Delivery (a unique delivery ID), and User-Agent: WebDecoy-Webhook/1.0.

The payload, from the webhook docs:

{
  "event": "detection",
  "timestamp": "2026-07-15T10:30:00Z",
  "detection": {
    "id": "det_abc123",
    "decoy_id": "decoy_uuid",
    "organization_id": "org_xyz789",
    "ip_address": "192.168.1.100",
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "bot_score": 92,
    "timestamp": "2026-07-15T10:30:00Z",
    "rules_enforced": true,
    "source": "decoy_link"
  },
  "metadata": {}
}

Each event is delivered once, with no automatic retries, and your endpoint has 10 seconds to respond. For a SIEM pipeline that means: verify the signature, return 200 immediately, queue the event, and index it from a worker. If you want the richer fields, have the worker fetch the full detection from the API by detection.id before indexing.

That receiver is the whole Elastic story today: WebDecoy has no native Elasticsearch output, Kibana dashboards, or Elastic detection rules.

Getting Started

1. Pick the destination your SOC already works in: Splunk, LogScale, Datadog, or a webhook receiver.
2. Create the credential on the SIEM side (HEC token, ingest token, or API key).
3. Add the integration under Integrations in the WebDecoy dashboard, and start with the high-risk trigger or a minimum score to keep volume sane.
4. Click Test and confirm the test event lands.
5. Write your own searches and alerts against the fields above. WebDecoy does not ship a Splunk app or importable dashboards, so the queries in this post are a starting point.
6. Correlate WebDecoy IPs with your auth, WAF, and endpoint data. That join is where a detection turns into a finding.

The setup pages in the docs have the full field lists: Splunk, CrowdStrike, Datadog, and webhooks.

Review the supported WebDecoy integrations, then start free and send a test event to your SIEM.

Questions about an integration? Contact us.