Exfiltration Detection
Signal interpretation, investigation workflow, and the operating context teams need when suspicious data movement appears.
Scope
Exfiltration signals only help if they arrive with enough context to drive a real response. This guide keeps the public-safe workflow model and leaves private detection internals out.
Step-by-step guides for investigation workflow, threshold tuning, and whitelist management.
Verified against code as of 2026-04-07.
Related documents:
- Architecture: docs/architecture/exfiltration-detection.md
- Functional: docs/functional/exfiltration-detection.md
- Alert management: docs/manual/alerts-monitoring.md
Understanding the Detection Pipeline
The exfiltration detector runs every 30 minutes and:
1. Analyzes NetworkFlowSample data from agents
2. Collects host IDs from flow data and checks which are in active maintenance windows (skips those)
3. Applies heuristic checks (large outbound, unknown destination, tunneling, receive-only anomaly)
5. Creates alerts for medium+ risk levels and incidents for high+ risk levels
Maintenance window behavior: Hosts currently in an active maintenance window are completely skipped – no alerts, no risk scores. The hosts_skipped_mw counter in the detection stats shows how many hosts were suppressed.
Unknown destination behavior: Unknown destination alerts create domain-level NetworkExfiltrationAlert records for investigation but do NOT create unified alerts or incidents. They appear in the exfiltration alerts UI and contribute to composite scoring, but cannot independently trigger the alert/incident pipeline. This prevents low-confidence detections from creating noise in the unified alert system.
Unknown destination baseline: If a host has been communicating with a destination IP consistently (>= 10 flow samples in the prior 7 days), that destination is considered “established” and the unknown destination alert is downgraded to informational severity. This prevents false positives from known SaaS/API destinations.
Alert resolution cascade: When you resolve an exfiltration alert (confirmed or false positive), the system also automatically resolves any linked unified Alert and Incident records that were created during detection. You do not need to separately close those.
Configuration change propagation: All detection configuration changes (thresholds, suppressions, whitelist edits) take effect within the next detection cycle (30 minutes). The detector clears its internal caches at the start of each cycle. No service restart is required.
V1 limitations: The system detects and recommends only. There is no autonomous host isolation, egress blocking, or process killing.
Managing Suppressions
Create allowlists for known-safe traffic patterns:
- Process name patterns (regex, max 200 characters)
- Destination IP/domain regex patterns (max 200 characters)
- Optional expires_at for time-bound suppressions (required for org-scoped users)
Scope enforcement:
- Permanent suppressions (expires_at=None) require account-admin
- Deleting account-wide suppressions requires account-admin; deleting org-scoped suppressions requires access to that org
Investigating Exfiltration Alerts
From the Security Dashboard
The Security Dashboard (the relevant workflow > Network Security tab) shows exfiltration alerts with server-side pagination and filters:
- Actions: Investigate (open alerts), Resolve as Confirmed, Resolve as False Positive (open and investigating alerts), Whitelist process
The table supports pagination (50 per page) so busy tenants will not have alerts silently truncated. Sensitive disposition actions now use explicit in-app confirmation dialogs for single-alert and bulk resolution flows; the page no longer relies on browser-native confirm prompts.
Alert-to-Risk Score Drill-Down
The alert detail endpoint now links to the closest risk score within 5 minutes of the detection time. The response includes:
- composite_score – overall risk score (0.0-1.0)
- risk_level – informational/low/medium/high/critical
- score_breakdown – list of factor scores with explanations
Score breakdown interpretation:
- destination_novelty (0.25 weight): is this a new destination for the host/org?
- volume_anomaly (0.25 weight): is egress volume significantly above the 7-day average?
- process_rarity (0.15 weight): how uncommon is this process across the organization?
- off_hours (0.10 weight): is this happening outside business hours (08:00-18:00 UTC)?
- asset_criticality (0.10 weight): how critical is this host?
- connection_pattern (0.15 weight): tunneling indicators, sustained connections, unusual ports
Process Whitelist
Add known-safe processes to reduce false positives:
2. The sha256_hash field has been deprecated and is no longer accepted on creation
3. Existing whitelist entries with historical hash data retain that data in responses
Retention
Old records are automatically purged: - Exfiltration alerts: after 90 days (default, configurable per org) - Risk scores: after 30 days (default, configurable per org) - Runs daily via scheduler