Secret Server
Webhook Events
→ SIEM Pipeline

Secret Server's Event Pipeline captures every significant PAM activity — authentication attempts, secret retrievals, rotation outcomes, dependency health checks — and dispatches them to registered webhook endpoints within seconds of occurrence. Your SIEM platform ingests these structured payloads and correlates them against other security telemetry for detection and compliance reporting.

The webhook engine operates independently of the sync connector infrastructure — it is a push-only, event-driven channel that does not query the SIEM and holds no SIEM credentials. Authentication is asymmetric: Secret Server signs outbound payloads with a configurable HMAC-SHA256 signature or Bearer token; the SIEM endpoint validates on receipt.

  ┌──────────────────────────────────────────────────────────────┐
  │                    SECRET SERVER PAM                         │
  ├──────────────┬─────────────────┬────────────┬───────────────┤
  │ Auth Events  │  Secret Access  │  Rotation  │  Heartbeat    │
  ├──────────────┴─────────────────┴────────────┴───────────────┤
  │           Internal Event Bus (Engine Broker)                 │
  ├─────────────────────────────────────────────────────────────-┤
  │       Webhook Engine  ·  Filter Rules  ·  Payload Builder    │
  ├──────────────────────────────────────────────────────────────┤
  │  HMAC-SHA256 Sign  ·  TLS 1.3  ·  Retry w/ Exponential BO   │
  └──────────┬──────────────────────┬──────────────┬────────────┘
             ↓                    ↓              ↓
   [Splunk HEC]         [Sentinel DCR]     [QRadar Syslog]
             ↓                    ↓              ↓
    SIEM Correlation · Detection Rules · Compliance Dashboards

Secret Server categorizes forwardable events into four primary groups. Each event type carries a severity classification that maps to your SIEM's alert priority model. Click any card to preview the JSON payload for that event category.

Additional Forwardable Event Types

Webhooks are configured under Admin → Event Subscriptions → Add Subscription. Each subscription defines a target endpoint URL, the event types to forward, optional filter rules, and the authentication method for the receiving SIEM endpoint.

All webhook payloads are delivered as HTTP POST requests with Content-Type: application/json. Every payload shares a common envelope structure containing metadata fields, with an event-specific body nested within. The payload builder supports Liquid template syntax for customisation — you can reshape the JSON to match your SIEM's expected ingestion format.

Standard Payload Envelope

Liquid Template Payload Customisation

Use Liquid syntax in the Custom Payload Template field of each event subscription to reshape the JSON to your SIEM's required format. This is especially important for Splunk (which requires a specific HEC envelope) and QRadar (which expects a flat key-value structure).

{
  "time":       "{{ event.timestamp | date: '%s' }}",
  "host":       "{{ event.ssInstance }}",
  "source":     "secret_server",
  "sourcetype": "ss:pam:event",
  "index":      "pam_security",
  "event": {
    "event_id":   "{{ event.eventId }}",
    "event_type": "{{ event.eventType }}",
    "severity":   "{{ event.severity }}",
    "actor":      "{{ event.actor.domain }}\\{{ event.actor.username }}",
    "src_ip":     "{{ event.actor.ipAddress }}",
    "secret_name":"{{ event.secret.name | default: '' }}",
    "folder_path":"{{ event.secret.folderPath | default: '' }}",
    "outcome":    "{% if event.outcome.result %}{{ event.outcome.result }}{% endif %}"
  }
}

Secret Server supports three mechanisms for authenticating outbound webhook deliveries to your SIEM endpoint. Select the method appropriate to your SIEM's ingestion API capabilities and your organisation's security policy.

HMAC-SHA256 Signature Validation (Recommended)

import hmac, hashlib, os
from flask import Flask, request, abort

app = Flask(__name__)
# Store the shared secret in an env variable — never hardcode
WEBHOOK_SECRET = os.environ["SS_WEBHOOK_SECRET"].encode()

@app.route("/ss-events", methods=["POST"])
def receive_event():
    sig_header = request.headers.get("X-SS-Signature", "")
    body       = request.get_data()           # raw bytes

    # Compute expected HMAC-SHA256 over raw body
    expected = "sha256=" + hmac.new(
        WEBHOOK_SECRET, body, hashlib.sha256
    ).hexdigest()

    # Constant-time comparison prevents timing attacks
    if not hmac.compare_digest(expected, sig_header):
        abort(401)  # reject invalid signature

    event = request.get_json()
    process_event(event)     # forward to SIEM index
    return "", 200

def process_event(event):
    # Route to appropriate SIEM index by severity
    severity = event.get("severity", "INFO")
    index    = "pam_critical" if severity == "CRITICAL" else "pam_security"
    # ... forward to SIEM ingestion API

Complete, production-ready configuration examples for the three most common enterprise SIEM platforms. Select your platform below for endpoint configuration, source type setup, and example detection rules.

{
  "time":       "{{ event.timestamp | date: '%s' }}",
  "host":       "{{ event.ssInstance }}",
  "source":     "secret_server:webhook",
  "sourcetype": "ss:pam:event",
  "index":      "pam_security",
  "event": {
    "event_id":      "{{ event.eventId }}",
    "event_type":    "{{ event.eventType }}",
    "severity":      "{{ event.severity }}",
    "ss_instance":   "{{ event.ssInstance }}",
    "actor_user":    "{{ event.actor.username }}",
    "actor_domain":  "{{ event.actor.domain }}",
    "actor_ip":      "{{ event.actor.ipAddress }}",
    "secret_id":     "{{ event.secret.id | default: '' }}",
    "secret_name":   "{{ event.secret.name | default: '' }}",
    "folder_path":   "{{ event.secret.folderPath | default: '' }}",
    "template":      "{{ event.secret.template | default: '' }}",
    "outcome":       "{{ event.outcome.result | default: '' }}",
    "raw_severity":  "{{ event.severity }}"
  }
}

| Detection: Privileged Account Brute Force (SS → Splunk)
index=pam_security sourcetype="ss:pam:event"
    event_type="USER_LOGIN_FAILURE"
| stats
    count          AS failure_count,
    dc(actor_ip)   AS unique_ips,
    values(actor_ip) AS source_ips
    BY actor_user actor_domain _time span=5m
| where failure_count >= 5
| eval risk_score = failure_count * unique_ips
| sort -risk_score
| table _time actor_domain actor_user failure_count unique_ips source_ips risk_score
| alert if risk_score > 15
  action.email.subject = "ALERT: Privileged Account Brute Force — {{ actor_user }}"

# Create the custom table schema in Log Analytics
$tableSchema = @{
    properties = @{
        schema = @{
            name = "SecretServerEvents_CL"
            columns = @(
                @{ name = "EventId";     type = "string" },
                @{ name = "EventType";   type = "string" },
                @{ name = "Severity";    type = "string" },
                @{ name = "TimeGenerated"; type = "datetime" },
                @{ name = "ActorUser";   type = "string" },
                @{ name = "ActorDomain"; type = "string" },
                @{ name = "ActorIp";     type = "string" },
                @{ name = "SecretName";  type = "string" },
                @{ name = "FolderPath";  type = "string" },
                @{ name = "Outcome";     type = "string" },
                @{ name = "SSInstance";  type = "string" }
            )
        }
    }
}

# Obtain AAD token for DCR ingestion
$token = (Get-AzAccessToken -ResourceUrl "https://monitor.azure.com/").Token

# Post a test event to the DCR endpoint
$body = @([ordered]@{
    EventId    = [guid]::NewGuid().ToString()
    EventType  = "WEBHOOK_TEST"
    Severity   = "INFORMATIONAL"
    TimeGenerated = (Get-Date -Format "o")
    ActorUser  = "test-actor"
}) | ConvertTo-Json -AsArray

Invoke-RestMethod -Uri "$DCR_ENDPOINT" `
    -Method POST -Body $body `
    -ContentType "application/json" `
    -Headers @{ Authorization = "Bearer $token" }

// Analytic Rule: Consecutive Heartbeat Failures → Possible Out-of-Band Password Change
SecretServerEvents_CL
| where EventType == "HEARTBEAT_FAILURE"
| where TimeGenerated > ago(1h)
| summarize
    FailureCount  = count(),
    AffectedSecrets = make_set(SecretName),
    FolderPaths   = make_set(FolderPath),
    FirstFail     = min(TimeGenerated),
    LastFail      = max(TimeGenerated)
  by SSInstance, bin(TimeGenerated, 15m)
| where FailureCount >= 3
| extend AlertSeverity = iff(FailureCount >= 10, "High", "Medium")
| extend
    AlertName = strcat("SS Heartbeat Failures: ", tostring(FailureCount), " in 15m"),
    Entities  = AffectedSecrets
| project TimeGenerated, AlertSeverity, AlertName, FailureCount, AffectedSecrets, FolderPaths

{
  "deviceVendor":    "Delinea",
  "deviceProduct":   "SecretServer",
  "deviceVersion":   "{{ event.version }}",
  "eventId":         "{{ event.eventId }}",
  "eventClassId":    "{{ event.eventType }}",
  "severity":        "{{ event.severity }}",
  "startTime":       "{{ event.timestamp }}",
  "sourceUserName":  "{{ event.actor.domain }}\\{{ event.actor.username }}",
  "sourceAddress":   "{{ event.actor.ipAddress }}",
  "destinationHost": "{{ event.ssInstance }}",
  "cs1Label":        "SecretName",
  "cs1":             "{{ event.secret.name | default: '' }}",
  "cs2Label":        "FolderPath",
  "cs2":             "{{ event.secret.folderPath | default: '' }}",
  "cs3Label":        "Template",
  "cs3":             "{{ event.secret.template | default: '' }}",
  "outcome":         "{{ event.outcome.result | default: '' }}",
  "reason":          "{{ event.outcome.reason | default: '' }}"
}

-- QRadar Ariel: Detect Bulk Secret Export — High Priority Offence Rule
SELECT
    "startTime"      AS event_time,
    "sourceUserName" AS actor,
    "sourceAddress"  AS src_ip,
    "cs1"            AS secret_name,
    "cs2"            AS folder_path,
    "severity"
FROM events
WHERE "eventClassId" = 'EXPORT_SECRET'
  AND "deviceProduct" = 'SecretServer'
  AND DATEFORMAT("startTime", 'yyyy-MM-dd HH:mm:ss') >
      DATEADD('MINUTE', -30, NOW())
ORDER BY event_time DESC
-- Trigger offence if count >= 1 (any export is alertable)
-- Map to: Category 5012 (Data Exfiltration) · Severity HIGH

Five questions covering webhook configuration, event handling, and SIEM integration concepts.

Complete all items before enabling the webhook pipeline in production.

Secret Server Configuration

• Event Pipeline service enabled and running on all Distributed Engine nodes
• Event subscription created with HTTPS endpoint (valid TLS cert — no self-signed)
• Event types selected covering minimum SOC set: auth failures, secret views, rotations, heartbeat failures
• HMAC-SHA256 signing enabled; shared secret stored in vault (not hardcoded)
• Retry policy configured: 5 retries, exponential backoff, dead letter queue enabled
• Test event delivered successfully and confirmed indexed in SIEM
• Delivery timeout set to 10 seconds; SIEM endpoint confirmed to respond within 2 seconds

SIEM Endpoint Security

• HMAC signature validated on every inbound event (constant-time comparison)
• Endpoint returns HTTP 200 immediately; event processing is asynchronous
• eventId deduplication logic implemented and tested with replay scenarios
• Ingestion endpoint access-controlled to Secret Server engine IP ranges only (WAF/firewall)
• TLS 1.2+ enforced on SIEM ingestion endpoint; weak ciphers disabled

Detection Rules & Alerting

• Brute-force detection rule active: ≥5 login failures within 5 minutes triggers HIGH alert
• Heartbeat failure rule active: ≥3 consecutive failures on same secret triggers MEDIUM alert
• Secret bulk export rule active: any EXPORT_SECRET event triggers immediate HIGH alert
• Compound detection rule: ROTATION_FAILURE + HEARTBEAT_FAILURE within 1 hour triggers HIGH escalation
• SIEM alert routing tested end-to-end to on-call SOC queue
• Dead letter queue monitored with alert if queue depth exceeds 10 undelivered events
• Runbook written for each alert type covering triage steps and escalation path