Skip to content
Kandaro
Start free trial

Integrations

SIEM connectors

Deliver incidents straight into Splunk, Elasticsearch or Microsoft Sentinel, in a standard format your SOC tooling already understands.

What gets sent

Each incident arrives as one OCSF Detection Finding (class 2004): severity, an explanation, a recommended action, the MITRE ATT&CK techniques involved and the most recent events (up to 20). Kandaro sends a finding when an incident opens, when its severity escalates and when a closed incident re-opens. The minimum severity is set per channel, and the use of a decoy credential is always sent.

json
{
  "class_uid": 2004,
  "class_name": "Detection Finding",
  "category_uid": 2,
  "activity_id": 1,
  "type_uid": 200401,
  "time": 1791425700000,
  "severity_id": 4,
  "severity": "High",
  "status_id": 1,
  "status": "New",
  "confidence_id": 2,
  "message": "Login attempts on decoy NAS from finance workstation",
  "count": 7,
  "metadata": {
    "version": "1.1.0",
    "product": { "name": "Kandaro Deception", "vendor_name": "Kandaro" },
    "event_code": "incident.created"
  },
  "finding_info": {
    "uid": "6f1c2e0a-…",
    "title": "Login attempts on decoy NAS from finance workstation",
    "desc": "A machine on the finance VLAN tried to log into…",
    "src_url": "https://app.kandaro.com/incidents/6f1c2e0a-…",
    "attacks": [
      {
        "version": "ATT&CK Enterprise",
        "tactics": [{ "uid": "TA0006", "name": "Credential Access" }],
        "technique": { "uid": "T1110", "name": "Brute Force" }
      }
    ]
  },
  "remediation": { "desc": "Isolate 10.20.4.77 and reset the backup-admin password." },
  "resources": [{ "uid": "…", "name": "nas-backup-01", "type": "Decoy sensor" }],
  "evidences": [
    {
      "src_endpoint": { "ip": "10.20.4.77", "port": 51234 },
      "dst_endpoint": { "port": 22, "svc_name": "ssh" },
      "data": {
        "event_uid": "…",
        "time": "2026-10-08T02:14:07.000Z",
        "type": "login_attempt",
        "action": "password",
        "summary": "Someone tried to log in to ssh as \"backup-admin\"…",
        "attacker_input": {
          "username": "backup-admin",
          "password": { "masked": "••••••••", "length": 8, "fingerprint": "…" }
        }
      }
    }
  ]
}

evidences[].data.attacker_input holds what the attacker typed. Treat it as untrusted data. If an AI agent reads your SIEM, make sure it does not follow instructions found in that field. Captured passwords and tokens are masked before they leave Kandaro.

ATT&CK techniques come from a fixed table (event type and payload tags), not from AI, so the same activity always maps to the same technique. Kandaro cannot see where a decoy sits in your network, so a web exploit payload is labelled T1190 even when the decoy is internal.

Before you start

  • The endpoint must be reachable from the internet over https. Kandaro refuses private and internal addresses, so a SIEM that only listens inside your network needs a public endpoint or a forwarder, or you can pull from the API instead.
  • Requests time out after 5 seconds, are retried with back-off, and never follow redirects.
  • Tokens and secrets are stored encrypted and are never shown again. To change one, use “Replace credential”.
  • After adding a channel, press Send test. A test finding has activity_id 99 and no incident.

Splunk

  1. In Splunk, create an HTTP Event Collector token. Note the token and, if you want one, a default index.
  2. In the Console, open Settings → Alerts → Add channel → Splunk and enter the collector address without a path (for example https://http-inputs-example.splunkcloud.com), the token and optionally an index.

Findings are posted to /services/collector/event with source kandaro and sourcetype kandaro:ocsf.

Elasticsearch

  1. Create an API key that may write to the data stream you want to use.
  2. Add an Elastic channel with your Elasticsearch endpoint, the encoded API key and a data stream name. The default is logs-kandaro.incidents-default.

Each finding is indexed as one document with an added @timestamp.

Microsoft Sentinel

Sentinel receives findings through the Azure Monitor Logs Ingestion API.

  1. Create a custom table in your Log Analytics workspace with the columns below.
  2. Create a data collection endpoint and a data collection rule that maps the stream to that table.
  3. Register an app in Microsoft Entra, create a client secret, and give the app the Monitoring Metrics Publisher role on the data collection rule.
  4. Add a Microsoft Sentinel channel with the data collection endpoint, the rule’s immutable ID (dcr-…), the stream name (Custom-…), the tenant ID, the client ID and the client secret.
table columns
TimeGenerated        datetime
IncidentId           string
Title                string
Activity             string     // Create, Update or Test
Severity             string
Status               string
SourceIp             string
SensorName           string
EventCount           int
DecoyCredentialUsed  boolean
Techniques           dynamic    // ["T1110", "T1078"]
IncidentUrl          string
Finding              dynamic    // the full OCSF finding

Columns your rule does not declare are dropped by Azure, which is why the full finding also travels in the Finding column. Only the Azure public cloud is supported.

Another SIEM

Use a signed webhook, which carries the same techniques and events, or pull from the API.