Black Swan Zero Engine Dashboard
Deterministic behavioral state-machine threat detection — Sealed, closed-world, O(1) complexity
Real-World Calibration Results
Engine tested against 278 EVTX attack files from the public EVTX-ATTACK-SAMPLES dataset
| Event Source | Event IDs | Count | Description |
|---|---|---|---|
| Sysmon Process Create | 1 | ~2,400 | Process spawn events with Image path and ProcessGuid |
| Sysmon Network Connect | 3 | ~400 | Network connection events with source/dest IP and port |
| Sysmon Process Terminate | 5 | 14,638 | Process termination events (filtered — most are SYSTEM) |
| Sysmon Driver Load | 6 | 14,973 | Driver load events with ImageLoaded path (filtered) |
| Sysmon Registry Events | 12,13,14 | ~800 | Registry key/value create, modify, delete |
| Windows Security | 4624,4625,4648,4672,4688,7045 | ~1,000 | Logon, privilege, process, service events |
| # | Actor | Violation | Severity | Timestamp |
|---|---|---|---|---|
| 1 | admin01@EXAMPLE | user:initial→user:privileged | Critical | 2019-02-13 18:04 UTC |
PatternShadow Privilege — first observed event is a privileged action with no prior authentication
MITRE ATT&CKT1078 Valid Accounts / T1134 Access Token Manipulation
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
| 2 | samir@3B | user:initial→user:privileged | Critical | 2022-02-16 10:37 UTC |
PatternShadow Privilege — user samir@3B first appears in a privileged state with no authentication event
MITRE ATT&CKT1078 Valid Accounts
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
| 3 | {747f3d96-141c-5e41...}@MSEDGEWIN10 | process:terminated→process:accessing_resource | Critical | 2020-02-10 08:28 UTC |
PatternZombie Process — process recorded as terminated then performed a file/registry access. Possible pending I/O or process injection.
MITRE ATT&CKT1055 Process Injection / T1134 Access Token Manipulation
NoteCould be a timing artefact in EVTX log ordering, or a genuine detection of post-termination activity
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
| 4 | Administrator@EXAMPLE | user:initial→user:privileged | Critical | 2019-03-19 00:02 UTC |
PatternShadow Privilege — Administrator account first appears in privileged state at midnight (00:02 UTC)
MITRE ATT&CKT1078.002 Domain Accounts
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
| 5 | user01@EXAMPLE | user:authenticated→user:privileged | Critical | 2019-03-18 11:06 UTC |
PatternDirect Privilege Escalation — user01 authenticated then immediately escalated to privileged without an active session
MITRE ATT&CKT1078 Valid Accounts / T1548 Abuse Elevation Control Mechanism
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
| 6 | user01@EXAMPLE | user:privileged→user:authenticated | Critical | 2019-03-18 11:27 UTC |
PatternPrivilege Cycling — user01 drops from privileged to authenticated (21 minutes after Alert 5). Privilege cycling is a known lateral movement indicator.
MITRE ATT&CKT1078 Valid Accounts
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
| 7 | IEUser@MSEDGEWIN10 | user:authenticated→user:privileged | Critical | 2019-09-22 11:22 UTC |
PatternDirect Privilege Escalation — IEUser authenticated then immediately escalated to privileged
MITRE ATT&CKT1548 Abuse Elevation Control Mechanism
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
| 8 | IEUser@MSEDGEWIN10 | user:privileged→user:authenticated | Critical | 2019-08-05 09:39 UTC |
PatternPrivilege Cycling — IEUser drops from privileged to authenticated. Part of the same privilege cycling pattern as Alert 7.
MITRE ATT&CKT1078 Valid Accounts
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
| 9 | Administrator@WINLAB.LOCAL | user:initial→user:privileged | Critical | 2022-05-01 04:41 UTC |
PatternShadow Privilege — Administrator@WINLAB.LOCAL first appears in privileged state at 04:41 UTC (off-hours)
MITRE ATT&CKT1078.002 Domain Accounts
Lineagezero.v1.0.states.v1.transitions.v6.corridors.v1
| ||||
The engine was run against the full EVTX-ATTACK-SAMPLES dataset using the winevent adapter. Events were parsed from 278 EVTX files covering Windows Security logs (EventIDs 4624, 4625, 4648, 4672, 4688, 7045) and Sysmon logs (EventIDs 1, 3, 5, 6, 7, 8, 10, 11, 12, 13, 14, 15, 17, 18, 19, 20, 21, 22, 23, 25). Each event was mapped to a structured behavioral event and fed to the state machine in chronological order.
31,228 events (91.2%) were filtered before reaching the state machine. Filtering criteria:
- SYSTEM account events — noise, not actors
- NT AUTHORITY accounts (LOCAL SERVICE, NETWORK SERVICE) — service accounts
- Machine accounts (ending in $) — computer accounts
- ANONYMOUS LOGON — unauthenticated noise
- Events with no identifiable actor (no Image, no User, no ProcessGuid)
- Sysmon EventID 6 (Driver Load) — uses ImageLoaded field, now correctly mapped
Three rounds of false positive reduction were performed:
- Round 1 (32,108 → 774 alerts): Fixed phantom actor — EventID 6 (Driver Load) used ImageLoaded not Image. Added ProcessGuid-based actor_id for Sysmon process events to prevent all instances of the same executable being merged into one actor.
- Round 2 (774 → 14 alerts): Added missing self-transition rules (network:connecting, process:created, process:terminated, process:escalating) and mapped action/connect event types to existing states (running, communicating).
- Round 3 (14 → 9 alerts): Added missing transition rules (communicating→terminated, running→created, cross-domain process↔network), fixed LOCAL SERVICE@NT AUTHORITY filter, added legitimate path transitions (created→accessing_resource, initial→communicating, etc.).
State Machine
Behavioral domains, states, and event type mappings
| Event Type | Target State |
|---|---|
| login | authenticated |
| logout | idle |
| action | active |
| escalate | privileged |
| privilege_request | privileged |
| anomaly | anomalous |
| block | blocked |
| Event Type | Target State |
|---|---|
| spawn / create | created |
| start | running |
| access | accessing_resource |
| ipc / communicate | communicating |
| escalate | escalating |
| exit / terminate | terminated |
| action | running (Sysmon registry/file) |
| connect | communicating (Sysmon pipe) |
| Event Type | Target State |
|---|---|
| ready | idle |
| connect | connecting |
| transmit / response | transmitting |
| receive | receiving |
| close | idle |
| scan | scanning |
| exfiltrate | exfiltrating |
| Event Type | Target State |
|---|---|
| startup / normal | normal |
| degrade | degraded |
| stress | under_stress |
| compromise | compromised |
| recover | recovering |
The engine uses the following priority order to determine actor_id for each event:
- Sysmon process events (EventID 1,5,7,8,10+):
ProcessGuid@Machine— each process instance is a distinct actor - Sysmon EventID 6 (Driver Load):
ImageLoaded@Machine— driver path as actor - Sysmon network events (EventID 3):
SourceIp@Machine— source IP as actor - Windows Security process events (4688):
NewProcessName@Machine - Windows Security service events (7045):
ServiceName@Machine - Windows Security user events (4624, 4625, 4648, 4672):
SubjectUserName@LogonDomain
Events with no identifiable actor are skipped. SYSTEM, NT AUTHORITY, LOCAL SERVICE, NETWORK SERVICE, ANONYMOUS LOGON, and machine accounts ($) are filtered.
Attack Corridors
13 predefined attack sequence corridors — multi-step attack patterns that are allowed within the corridor but suspicious in isolation
Transition Rules
All allowed state transitions — any transition not in this list is an impossible transition and generates an alert
Submit Event
Submit a structured behavioral event to the engine and see the evaluation result
Live Alerts
Real-time alert feed from all 6 detection layers. WebSocket push — zero polling latency.
API Reference
tRPC endpoints for the Black Swan Zero engine
| Endpoint | Type | Description |
|---|---|---|
| /health | GET | Engine health check and version |
| /api/docs | GET | API documentation |
| /api/trpc/zero.evaluate | tRPC | Evaluate a single behavioral event |
| /api/trpc/zero.getStats | tRPC | Engine statistics and rule counts |
| /api/trpc/zero.getCorridors | tRPC | List all attack corridors |
| /api/trpc/zero.getTransitions | tRPC | List all transition rules |
# Process a JSONL file of structured behavioral events node dist/cybercore_zero_standalone.cjs \ --input=events.jsonl \ --format=zero \ --output=alerts.jsonl \ --state=state.db # Process Windows Event Log (EVTX) events node dist/cybercore_zero_standalone.cjs \ --input=windows_events.jsonl \ --format=winevent \ --output=alerts.jsonl \ --state=state.db # Formats: zero (native), winevent (Windows Security + Sysmon) # State DB persists actor state across runs (SQLite via sql.js)
// Structured Behavioral Event (native format)
{
"actor_id": "alice@corp.example", // Unique actor identifier
"actor_type": "user", // user | process | system | network
"event_type": "login", // Domain-specific event type
"timestamp": 1700000000000, // Unix milliseconds (UTC)
"domain_hint": "user_behavior", // Optional: override domain classification
"context": {
"environment_class": "production", // Optional: production | staging | dev
"source_ip": "10.0.0.1",
"target_resource": "/api/admin"
}
}
Sovereign Evaluation Suite
Offline evaluation — 10 MITRE ATT&CK scenarios, 5 red team full-chain attack tests. No network. No real data. All results are deterministic and reproducible.
Full synthetic simulation: 352,582 events across 2015–2025, 1,100 actors, 8 named threat actor campaigns, 4 insider cases. Deterministic (seed 42) — same inputs produce the same alerts and the same SHA-256 hash every time. No network. No real data. Results are reproducible by anyone.
Rule Manager
Add custom transition rules to the engine. Rules are stored in the database and loaded on next engine restart.
| Rule ID | Domain | From State | To State | Status |
|---|---|---|---|---|
| Loading... | ||||
Use this to permit a transition that the built-in rule table does not cover. Example: in your environment, cmd.exe legitimately connects to the network — add process_behavior:running → process_behavior:communicating for that actor class.
The engine's 74 built-in transition rules cover the most common legitimate behavioural sequences. In your specific environment, some additional sequences may be legitimate. Adding a custom rule tells the engine to permit that transition for all actors in the specified domain.
Custom rules are stored in the database and loaded on engine restart. They are auditable — every rule has a creation timestamp and can be toggled or deleted. They do not modify the built-in rule table.
⚠ Adding a rule reduces sensitivity. Only add rules for transitions you have confirmed are legitimate in your environment.
First-Event Enrolment
Persistent baseline seeding — new actors are silently enrolled on their first event. All subsequent events are evaluated normally.
By default, perpetual enrolment is active — new actors are always silently enrolled. You can override this with a fixed time window (e.g. for a controlled evaluation environment), or disable enrolment entirely. Set to 0 to disable immediately. Disabling on a live network will produce false positives for every new actor.
When the engine encounters an actor it has never seen before, it silently records their starting state without generating an alert. This is called first-event enrolment. All subsequent events from that actor are evaluated normally against the transition rules.
In perpetual mode (the default), enrolment applies permanently — not just during a startup window. This is required for production deployments because new actors (new employees, new service accounts, new servers, new containers) appear continuously and indefinitely.
Enrolment does not suppress alerts for known actors. If an actor the engine has already seen performs an impossible transition, it alerts immediately.
Enrolment does not suppress alerts for attack-path first events. If a brand-new actor's very first event is an impossible transition (e.g. a process that appears already dumping credentials), the engine alerts — that transition has no permitted rule regardless of actor history.
⚠ Disabling enrolment on a live network will produce false positives for every new actor until all legitimate actors have been seen at least once.
Report History
Every evaluation suite run is automatically saved. Click any row to view the full report and download it.
| # | Report ID | Engine Version | Scenarios | Red Team | Date | Hash | Actions |
|---|---|---|---|---|---|---|---|
| Loading... | |||||||
Access Manager
Create and manage client access tokens. Only visible to the master account.
| Label | Prefix | Created | Expires | Countdown | Last Used | Status | Actions |
|---|---|---|---|---|---|---|---|
| Loading... | |||||||
| Time | Event | IP Address | Detail |
|---|---|---|---|
| Loading... | |||
Alert Ledger Browser
Query the immutable ledger of all state transitions for any actor. Every evaluation is recorded.
| Time | Actor | From State | To State | Transition | Corridor | Result | Alert |
|---|
Enter an Alert ID to generate a plain-English incident report using AI. Reports are cached and persist across sessions.
System Health
Live engine diagnostics — uptime, throughput, diode, rate limiter, and memory.
Webhook Delivery
Configure outbound alert delivery to a SIEM, SOAR, or custom endpoint. Alerts are posted as JSON, CEF, or LEEF.
State Timeline Viewer
Visualise the complete state history of any actor as a chronological timeline.
Evidence Pack Download
Export a complete forensic evidence bundle for any actor — ledger records, alerts, and engine metadata — as a signed JSON file.
Mapping Tool
Map your environment into the engine. Five steps: input your data, discover structure, review shadow privileges, assign corridors, generate compliance report.
Paste your environment data as JSON. Each field accepts either a flat array or a structured object. A sample format is shown in each field.