Platform Structure
Kronyx is organised into three top-level components accessible from the dashboard sidebar: EDR, Network, and Pentesting. Each component contains dedicated modules grouped by function.
- Detection & Response
- • Devices
- • Autoruns
- • Binaries
- • Collected Files
- Management
- • Escalations
- • Investigations
- • Reports
- Security & Access
- • Teams
- Discovery & Analysis
- • Network Discovery
- • Traffic Analysis
- • Network Topology
- Security
- • WiFi Security
- • Port Services
- • Threat Detection
- Monitoring
- • Bandwidth Usage
- Targets & Scanning
- • Targets (Domains & Servers)
- • Scan Types
- • Full Scan & Scheduling
- Results & Access
- • Findings & CVSS
- • PDF Reports
- • SARIF / Slack Export
- • Server Terminal
Admin Setup Guide
Everything you need to set up Kronyx for your organisation from scratch. Estimated time: 20–30 minutes.
Step 1 — Log In & Verify
Open the Kronyx dashboard and sign in with your credentials. If two-factor authentication is enabled, enter the 6-digit code from your authenticator app.
Step 2 — Invite Your Team
Go to Teams in the sidebar and click Invite Member. Select a role that matches each person's responsibilities. Kronyx ships with ten predefined security roles — assign the one that most closely matches the analyst's day-to-day work:
| Role | Typical Responsibilities |
|---|---|
| Administrator | Full platform access — manages users, settings, and all data |
| SOC Lead | Team oversight, escalation management, investigation review |
| Senior Analyst | Full investigation and incident response capabilities |
| Security Analyst | Alert triage, investigations, and daily monitoring |
| Tier 1 Analyst | First-line alert triage — escalates to senior analysts |
| Incident Responder | Active incident handling, containment, and evidence collection |
| Threat Hunter | Proactive research and hypothesis-driven hunt campaigns |
| Network Engineer | Network discovery, topology, and traffic analysis |
| Compliance Officer | Audit trail and compliance reports — read-only on investigations |
| Read-Only | View-only access across all platform modules |
If none of the predefined roles fits, go to the Roles tab on the Teams page and click Create Role to define a custom role with its own name and description.
Step 3 — Enroll Your First Device
Go to EDR → Detection & Response → Devices and click Add Device.
- Select the operating system (Windows, macOS, or Linux)
- Click Generate Installer — the file downloads automatically
- Copy the installer to the target machine and run it as Administrator
- The device appears in the Devices list within 1–2 minutes with a Connected status
Step 4 — Configure Escalation Rules
Go to EDR → Management → Escalations and click New Rule. Recommended starting rules:
| Rule | Trigger | Action |
|---|---|---|
| Critical Threat Alert | Severity = Critical | Notify All Admins |
| Malicious Binary | Binary verdict = Malicious | Create Investigation automatically |
| New Autorun | Any new autorun entry | Notify assigned Analyst |
| Unknown Network Device | Network Discovery finds new device | Notify Admin |
Step 5 — Run Your First Network Scan
Go to Network → Discovery & Analysis → Network Discovery and click Start Scan. Review results for any unrecognised devices — these should be investigated immediately.
Setup Checklist
- At least one device enrolled and showing as Connected
- At least one team member invited
- At least one escalation rule configured
- Network Discovery scan completed
- Network Topology map reviewed
Analyst Quickstart
Your daily workflow in Kronyx. Covers alert triage, device checks, investigation management, and network monitoring.
Daily Workflow
- Check Escalations → Active Queue — acknowledge anything that fired overnight
- Check Devices — confirm all endpoints are connected
- Review Binaries — triage new VirusTotal alerts
- Review Autoruns — check for new persistence entries
- Check Network → Threat Detection — network-level IoCs
- Work open Investigations — update evidence and notes
- Check Network Discovery — spot unauthorised devices
Responding to a Threat
| Step | Action |
|---|---|
| 1. Assess | Note the severity, affected device, and what was detected |
| 2. Gather context | Check Devices, Autoruns, and Binaries for the same endpoint |
| 3. Correlate | Check Traffic Analysis for unusual outbound connections from that device |
| 4. Open investigation | Create an Investigation, link all related evidence, assign an investigator |
| 5. Escalate if needed | Trigger escalation rules or notify your team directly |
| 6. Document & close | Add resolution notes, update status to Resolved |
Severity Reference
| Level | Meaning | Action |
|---|---|---|
| Critical | Active, confirmed threat | Respond immediately, escalate |
| High | Strong indicator of compromise | Investigate within the hour |
| Medium | Suspicious behaviour requiring review | Investigate within the day |
| Low | Informational, low risk | Review during routine checks |
EDR — Detection & Response
Devices
The central registry of all endpoints enrolled in Kronyx. Each device runs a lightweight agent that continuously reports health and security telemetry.
Navigate to EDR → Detection & Response → Devices. The device list shows every enrolled endpoint with its current status, OS, last heartbeat timestamp, and live resource metrics.
| Status | Meaning |
|---|---|
| Connected | Agent active and reporting normally |
| Warning | Connected but reporting elevated resource usage |
| Disconnected | No heartbeat received — investigate |
Adding a Device
- Click Add Device
- Select the target operating system
- Click Generate Installer
- Run the installer on the target machine — the agent registers automatically
Autoruns
Monitors persistence mechanisms on enrolled endpoints — the locations where malicious software installs itself to survive reboots.
Navigate to EDR → Detection & Response → Autoruns. Kronyx tracks autorun entries across Windows registry run keys, startup folders, scheduled tasks, Windows services, macOS login items, LaunchAgents/Daemons, and Linux systemd services and cron jobs.
| Status | Meaning |
|---|---|
| New | Entry appeared since the last scan — requires review |
| Existing | Known, previously reviewed entry |
| Suspicious | Characteristics common in malware (unusual path, obfuscated command) |
| Malicious | Confirmed malicious based on hash or behavioral analysis |
High-Risk Patterns
- Entries pointing to files in
%TEMP%,%APPDATA%, orC:\Users\Public - Entries using encoded or obfuscated PowerShell commands
- Entries with randomised or meaningless names
- Multiple new entries appearing on the same device simultaneously
Binaries
Analyses executables discovered on managed endpoints and checks them against VirusTotal to identify malicious or suspicious files.
Navigate to EDR → Detection & Response → Binaries. Each binary entry shows the file name, path, SHA256 hash, VirusTotal score, and the device it was found on.
| Verdict | Description | Recommended Action |
|---|---|---|
| Clean | No vendors flagged this file | No action required |
| Suspicious | 1–5 vendors flagged the file | Review context; investigate if in unusual location |
| Malicious | 6+ vendors flagged the file | Treat as confirmed threat; open investigation immediately |
| Unknown | File not in VirusTotal database | Manually review — unknown does not mean safe |
Collected Files
A centralised repository of files pulled from managed endpoints for analysis or evidence preservation.
Navigate to EDR → Detection & Response → Collected Files. Every collected file has MD5, SHA1, and SHA256 hashes recorded at the moment of collection — these serve as the integrity record.
Collecting a File
From the Device detail view, browse the endpoint file system and click Collect File. The file appears in Collected Files once collection is complete. You can then link it to any open investigation.
EDR — Management
Escalations
Escalations are the platform's safety net — automated rules that ensure no serious incident is silently ignored. When an incident matches a rule's conditions, it is pushed into a visible queue that requires an analyst to explicitly acknowledge it.
What is an Escalation?
An escalation is a formal record created by the system when an open incident meets the conditions of one of your rules. Think of it as the platform raising its hand and saying: "This incident has not been dealt with — someone needs to take ownership of it right now."
Without escalations, a Critical incident could sit open in the list for hours with no one noticing. Escalation rules enforce your team's SLAs by making inaction visible: every escalation in the queue represents an incident that needs immediate attention and has not yet been claimed.
The Escalation Lifecycle
| Stage | What it means | Who acts |
|---|---|---|
| Incident opens | A security event is detected and an incident record is created | System / Kronyx AI / Analyst |
| Rule evaluates | The system checks whether the incident matches any active escalation rule — immediately on creation or after a configured delay | Automated |
| Escalation created | The incident enters the Active Queue with a pulsing severity indicator. The assigned analyst (or all analysts) receives a notification | Automated |
| Acknowledge | An analyst clicks Acknowledge — this means they have seen it and taken ownership. The escalation leaves the queue | Analyst |
| Resolved | The underlying incident is investigated and closed. The escalation is marked resolved | Analyst |
The Active Queue
Navigate to EDR → Management → Escalations to see the Active Queue. Each card shows:
| Field | What it tells you |
|---|---|
| Escalation ID | Unique reference — use this when discussing the escalation with your team |
| Severity | Inherited from the incident — Critical, High, Medium, or Low |
| Incident # | The linked incident record. Click it to open the full incident detail |
| Reason | The human-readable explanation of why the rule fired — e.g. "Critical incident open for more than 1 hour" |
| Time ago | How long the escalation has been sitting unacknowledged in the queue |
Items are sorted by severity — Critical escalations always appear first. The queue refreshes automatically every 30 seconds. If you see the count climbing, it means incidents are being created faster than they are being acknowledged.
Escalation Rules
Navigate to the Rules tab on the Escalations page. Rules are the conditions that decide when an escalation is created. Each rule has two parts:
| Part | What it controls |
|---|---|
| Trigger Severity | Which incident severity levels this rule applies to. You can select multiple. A rule set to "Critical + High" will fire for both. |
| Trigger After (hours) | How long the incident must be open before the rule fires. Set to 0 to escalate the moment an incident of that severity is created. Set to 1 to give analysts one hour to pick it up before escalating. |
Rules can be toggled on or off without deleting them. Disabled rules are shown in a separate section — this lets you keep rules that are only relevant during specific periods (e.g. out-of-hours coverage rules).
Writing Effective Rules
A good escalation rule answers one question: "What situation would make my team uncomfortable if it were missed for this long?" Use the following starting templates and adjust the timing to match your team's capacity:
| Rule name | Severity | Trigger after | Purpose |
|---|---|---|---|
| Immediate Critical Response | Critical | 0 hours | Any Critical incident triggers an escalation the moment it is created — no grace period |
| High Priority SLA | High | 1 hour | High severity incidents that have not been claimed within one hour are escalated |
| Medium Backlog Check | Medium | 4 hours | Prevents Medium incidents from sitting unworked during busy periods |
| End-of-Day Sweep | Critical, High, Medium | 8 hours | Catch anything that slipped through a full work day without being addressed |
| After-Hours Critical | Critical | 0.5 hours | For out-of-hours coverage — escalate Critical incidents after 30 minutes if on-call has not responded |
BluAI and Automated Escalations
BluAI — the platform's AI security analyst — can create escalations directly when it detects a high or critical threat on an enrolled device. These appear in the Active Queue like any other escalation, labelled with the source AI Detection. BluAI also posts a message to the #alerts channel in Team Messages so the entire SOC is notified immediately, not just the device owner.
You can identify AI-generated escalations by the incident title prefix "AI Detection:" and by the Source field in the incident record showing ai_analysis.
Analyst Responsibilities
When you acknowledge an escalation you are making a commitment: you have seen this incident and you are taking responsibility for it. The platform records who acknowledged it and at what time — this feeds the Avg Response Time metric, which leadership uses to assess SOC performance.
| Do | Do not |
|---|---|
| Acknowledge escalations you are actively working | Acknowledge and then walk away — acknowledgement means ownership |
| Open the linked incident immediately after acknowledging | Acknowledge on behalf of another analyst without telling them |
| Add a note to the incident explaining your initial assessment | Let escalations sit in the queue because the incident looks low-risk — if you disagree with the rule, disable it |
| Escalate to your SOC Lead if the incident is beyond your scope | Create duplicate escalations by triggering the same rule multiple times |
Investigations
A structured workspace to document and track the full lifecycle of a security event from detection through containment and resolution.
Navigate to EDR → Management → Investigations and click New Investigation. Fill in a title, severity, description, and assign an investigator.
Investigation Statuses
| Status | Meaning |
|---|---|
| Open | Newly created, not yet actively worked |
| In Progress | Actively being investigated |
| Resolved | Threat contained and documented |
Reports
Generate summaries of security activity for management review, compliance audits, or team retrospectives.
Navigate to EDR → Management → Reports and click New Report. Select a report type, set the date range, and optionally filter by device, severity, or investigator.
| Report Type | Contents |
|---|---|
| Security Posture Summary | Device health, alert counts, open investigations |
| Threat Activity Report | All detections within a time period |
| Investigation Summary | All investigations and resolution status |
| Device Health Report | Per-device metrics and connectivity status |
EDR — Security & Access
Teams
Manage user accounts, roles, and access within your Kronyx organisation.
Navigate to EDR → Security & Access → Teams. From here you can invite members, change roles, and deactivate accounts.
| Permission | Admin | Analyst | Viewer |
|---|---|---|---|
| View all modules | ✓ | ✓ | ✓ |
| Create/edit investigations | ✓ | ✓ | — |
| Create/edit escalation rules | ✓ | — | — |
| Generate reports | ✓ | ✓ | — |
| Download agent installers | ✓ | ✓ | — |
| Invite / remove team members | ✓ | — | — |
| Change user roles | ✓ | — | — |
Network — Discovery & Analysis
Network Discovery
Scans your local network to discover all connected devices and build a live asset inventory.
Navigate to Network → Discovery & Analysis → Network Discovery and click Start Scan. Results populate in real time as devices respond. New devices are highlighted — review them to confirm they belong on your network.
Traffic Analysis
Monitors network traffic flowing through your environment and identifies anomalous patterns at the flow level.
Navigate to Network → Discovery & Analysis → Traffic Analysis. The dashboard shows live connection data, top talkers, protocol breakdown, and a historical bandwidth timeline.
Anomalous Traffic Patterns
- Large outbound data transfers to unknown external IPs — possible exfiltration
- DNS queries with very large payloads — possible DNS tunnelling
- High-frequency short connections — possible C2 beaconing
- RDP or SMB connections to unexpected internal devices — possible lateral movement
Network Topology
A visual map of how devices on your network are connected and related to each other.
Navigate to Network → Discovery & Analysis → Network Topology. Nodes represent devices; edges represent observed connections. Node colour indicates risk status — grey (normal), amber (warning), red (active threat).
Kronyx tracks your topology over time. When the map changes — a new device appears or a new connection is established — the change is logged and can trigger an escalation rule.
Network — Security
WiFi Security
Scans for wireless networks in range and assesses their security posture.
Navigate to Network → Security → WiFi Security. Each detected network is assessed and assigned a risk level.
| Risk | Criteria |
|---|---|
| Safe | WPA2 or WPA3 encryption, SSID matches known corporate networks |
| Warning | WPA (original), hidden SSID, or unknown network near corporate premises |
| Danger | Open (no encryption), WEP encryption, or BSSID spoofing a known corporate network |
Port Services
Scans hosts on your network for open ports and identifies what services are running.
Navigate to Network → Security → Port Services. Enter a target IP, hostname, or range, select scan type, and click Start Scan.
| Scan Type | Scope |
|---|---|
| Quick | Top 100 most common ports |
| Standard | Top 1,000 ports |
| Full | All 65,535 ports (slower) |
High-Risk Ports
| Port | Service | Why it is risky |
|---|---|---|
| 22 | SSH | Remote access — should not be exposed to the internet |
| 23 | Telnet | Unencrypted remote access — should never be open |
| 3389 | RDP | Remote desktop — commonly exploited |
| 445 | SMB | Common ransomware propagation vector |
| 1433 | MSSQL | Database — should never be internet-facing |
| 5900 | VNC | Remote access — unencrypted by default |
Threat Detection
Analyses network traffic behaviour in real time to identify indicators of compromise and active threats.
Navigate to Network → Security → Threat Detection. The live feed shows alerts classified by type and severity.
| Category | Description |
|---|---|
| C2 Communication | Traffic patterns consistent with command-and-control beaconing |
| Data Exfiltration | Large or unusual outbound data transfers |
| Lateral Movement | Internal connections consistent with an attacker moving through the network |
| Port Scanning | A device scanning many ports on other hosts |
| DNS Anomaly | Unusual DNS query patterns (high volume, large payloads, unknown resolvers) |
| Brute Force | Repeated authentication attempts against a service |
| Known Malicious IP | Connection to or from an IP on a threat intelligence blocklist |
Network — Monitoring
Bandwidth Usage
Tracks network bandwidth consumption per device and across the network, supporting both operational visibility and anomaly detection.
Navigate to Network → Monitoring → Bandwidth Usage. The dashboard shows total network throughput, top consumers, a historical chart, and a per-device breakdown.
| Status | Meaning |
|---|---|
| Normal | Bandwidth within expected range for this device |
| High | Sustained usage above the device historical baseline |
| Spike | A sudden, brief surge in bandwidth usage |
Pentesting — Targets & Scanning
Overview
Pentesting is Kronyx's core capability — the module that turns everything else the platform collects into an active, adversarial test. Instead of only watching for threats, Kronyx actively tests your own domains and servers using the same categories of checks a real attacker or professional penetration tester would run, and turns every result into a tracked Finding with a severity, a real CVE/CVSS score where one genuinely applies, and remediation guidance.
Navigate to Pentesting in the sidebar. There are two tabs: Targets (register and manage what you scan) and Findings (everything discovered across every target, filterable and exportable).
Targets (Domains & Servers)
A target is anything Kronyx will run scans against — a domain/web application, or a server reachable over SSH. Add one from Pentesting → Targets → Add Target.
Adding a Domain
Click Add Target → Domain... and enter the domain. Kronyx generates a unique DNS TXT record you must add before any active scan can run — this proves you control the domain.
| Field | Value |
|---|---|
| Record Type | TXT |
| Value | kronyx-verify=<your unique token> |
DNS changes can take a few minutes to propagate. Once the record is live, click Verify — Kronyx checks the record over live DNS. You can retry verification any time; the record and instructions stay available on the target.
Adding a Server
Click Add Target → Server (SSH)... and provide connection details.
| Field | Notes |
|---|---|
| Label | A friendly name, e.g. "prod-web-1" |
| Host / IP | The server's address |
| Port | Defaults to 22 |
| Username | The SSH login user |
| Auth method | Private key (with optional passphrase) or password — both supported |
Kronyx attempts a real SSH connection immediately with the credentials you provide. A successful connection marks the server Verified — there is no separate ownership-proof step like DNS, since a working SSH login already proves access. Credentials are encrypted at rest before being stored.
Verification Status
| Status | Meaning |
|---|---|
| unverified | Not yet confirmed — active scans and scheduling are locked |
| verified | Confirmed — DNS TXT record found (domains) or SSH login succeeded (servers). All active scans unlocked |
| failed | Last verification attempt did not succeed — check the DNS record or SSH credentials and retry |
Scan Types
Every verified target can run four active scan types, each mapping to a real, industry-standard tool — not a simulation.
| Scan | Tool | What it finds |
|---|---|---|
| Nuclei (active scan) | ProjectDiscovery Nuclei | Known CVEs and misconfigurations, matched against a large community template library |
| Port scan (active) | Kronyx port scanner (nmap-based) | Open ports and the service on each — flags high-risk ports like SSH, RDP, SMB, Telnet |
| TLS/SSL audit (active) | testssl.sh | Weak ciphers, protocol downgrade issues, certificate problems, and specific named vulnerabilities (e.g. SWEET32, LUCKY13, BEAST, BREACH) |
| API fuzz (active) | Schemathesis | Auto-discovers an OpenAPI/Swagger spec on the target and property-tests every documented endpoint for server errors, auth bypass, and schema violations |
Domains additionally offer four passive recon scans that don't require verification: Cert (subdomain discovery via certificate transparency logs), Net (CIDR range scan), Related domains, and GitHub (code-leak search).
Launch scans from a target's Run Scans button, which opens a dialog with one button per scan type plus a job history table (status, result count, timestamp).
Full Scan & Scheduling
Instead of clicking each scan type separately, Run Full Scan launches all four active scans for a target in one click.
Open Run Scans on a verified target and click Run Full Scan (all active scans) — Nuclei, port scan, TLS/SSL audit, and API fuzz are all queued at once. Track progress in the job history table below it; it auto-refreshes every 10 seconds while any job is pending or running.
Scheduled / Automatic Scanning
Toggle Automatically re-scan on the same dialog and set an interval in hours (1–720) to have Kronyx re-run scans on its own, without you clicking anything.
The dialog shows Last scheduled scan with a timestamp once at least one automatic run has completed.
Pentesting — Results & Access
Findings & CVSS
Every scan result becomes a Finding — a single unified record type shared across domains, servers, and endpoint devices, so you review everything discovered anywhere in one place.
Navigate to Pentesting → Findings. Filter by source type (which scan/target category it came from) or status, and click any row to see full detail, including the raw evidence returned by the scanning tool.
| Status | Meaning |
|---|---|
| Open | Newly discovered, not yet reviewed |
| Acknowledged | Seen by an analyst, not yet being worked |
| Remediating | A fix is in progress |
| Resolved | Fixed and confirmed |
| False Positive | Reviewed and determined not to be a real issue |
| Won't Fix | Accepted risk — reviewed and intentionally left as-is |
CVE / CVSS Scoring
Where a finding corresponds to a real, known vulnerability, Kronyx resolves a genuine CVSS score — never a fabricated one — using three sources in order: a score already captured by an endpoint vulnerability scan (matched live against the NVD CVE database), CVSS metadata already included in a Nuclei template's own output, or — for TLS/SSL findings that reference a bare CVE ID (e.g. SWEET32, LUCKY13) — a live lookup against the NVD CVE API.
N/A — those categories are never tracked in the CVE system, so there's nothing to look up. A bare — instead means the finding is a CVE-eligible type (TLS/SSL or vulnerability scan) where a score genuinely couldn't be resolved.PDF Reports
Click PDF Report on the Findings tab to generate a complete, presentation-ready penetration test report — cover page, executive summary, charts, a full findings table, and remediation guidance — built entirely from your real scan results.
| Section | Contents |
|---|---|
| Cover page | Kronyx branding, report scope (source/status filter applied), finding count, generation timestamp |
| Executive summary | Narrative summary plus a severity bar chart and a findings-by-category pie chart, generated from the actual counts — not a filled-in template |
| Findings table | Every finding grouped by severity (critical → info), with asset, CVE/CVSS where available, and status |
| Recommendations | Real, standard remediation guidance mapped to each specific check that fired, with an honest generic fallback for anything unmapped |
The report respects whatever Source type and Status filters are currently set on the Findings tab — narrow to a single target or scan category before generating if you want a scoped report rather than everything.
Exporting (SARIF / Slack)
Findings can also be pushed into your existing security tooling instead of read inside Kronyx.
SARIF Export
Click Export SARIF on the Findings tab to download a SARIF 2.1.0 log of the currently filtered findings. SARIF is a standard format most security dashboards understand directly — including DefectDojo, which imports SARIF natively, so no separate DefectDojo integration is needed.
Slack Notifications
Click the Slack button to send the currently filtered findings to a Slack channel via an incoming webhook. Set the webhook URL once — it's an organisation-wide setting, shared by your whole team. Once saved, Kronyx never displays the webhook URL again, the same handling as any other secret.
Server Terminal
Every verified server gets a live, real SSH terminal directly inside Kronyx — no separate SSH client needed for quick manual checks.
Open a verified server's terminal from its row in Targets. It opens as a right-side dock, consistent with the device and network recon terminals elsewhere in the platform — not a popup, so you can keep working in the rest of the dashboard while it's open.
BluAI — Artificial Intelligence
What is Kronyx AI?
Kronyx AI is the platform's built-in AI security analyst — powered by Claude (Anthropic). It monitors every enrolled device continuously, learns what normal looks like, and alerts your team the moment something deviates from that baseline.
Most security platforms surface raw data and leave interpretation entirely to the analyst. Kronyx AI changes that. Instead of reading through hundreds of process names and network connections, you receive a structured threat assessment — in plain language — for every device, updated every time new telemetry arrives.
Kronyx AI operates across four integrated layers, each building on the last:
| Layer | What it does | Analyst benefit |
|---|---|---|
| Behavioral Detection | Learns each device's normal CPU, memory, process, and network patterns. Flags statistical anomalies. | Alerts only fire when something genuinely unusual happens — not on every spike |
| Threat Classification | Sends suspicious activity to Claude for contextual analysis. Returns a structured verdict with confidence score. | You get a plain-English summary and recommended actions, not raw telemetry |
| Autonomous Response | For high/critical threats, automatically creates an incident, posts to #alerts, and notifies your team. | Threats are tracked and visible the moment they are detected, even outside office hours |
| AI Security Analyst | A conversational interface where analysts can ask questions about any device or investigate threats using natural language. | Junior analysts can investigate at a senior level — ask 'what's suspicious today?' and get a structured answer |
ANTHROPIC_API_KEY). Without it the platform runs in demo mode — anomaly detection still works but the Claude classification step is skipped. All other features function normally.Behavioral Detection Engine
Kronyx AI builds a unique baseline for every enrolled device by observing 24 hours of normal activity. Once enough data is collected it can identify when a device is behaving abnormally — even if no known malware signature is involved.
How baselines are built
Every time an agent sends a metrics heartbeat, Kronyx AI records the data and updates the device's rolling baseline. The baseline tracks:
| Metric | What is measured | Anomaly threshold |
|---|---|---|
| CPU usage | Average and standard deviation of processor load | More than 2 standard deviations above the baseline mean |
| Memory usage | Average and standard deviation of RAM consumption | More than 2 standard deviations above the baseline mean |
| Running processes | Set of process names seen in the last 24 hours | Any process not previously observed on this device |
| Network connections | Set of established remote IP addresses | Any outbound connection to an IP not seen before |
Baselines require a minimum of 10 data samples before anomaly detection activates. For a device reporting every 5 minutes, this takes roughly 50 minutes after first enrolment. Until then, Kronyx AI collects data silently.
Why statistical baselines matter
Signature-based detection can only catch known threats. A device running legitimate-looking processes that are subtly different from its normal pattern — a common indicator of living-off-the-land attacks — would pass signature checks entirely. Statistical baselines catch this class of threat because they ask not "is this malicious?" but "is this normal for this specific machine?"
Threat Classification
When the behavioral detection engine flags anomalies on a device, Kronyx AI assembles a structured snapshot of the device's current state and sends it to Claude for contextual analysis. The result is a threat verdict in a consistent, actionable format.
What Kronyx AI sends to Claude
| Data included | Detail |
|---|---|
| Device identity | Hostname, operating system, last-seen timestamp |
| Resource snapshot | Current CPU %, memory %, bytes received |
| Top 10 processes | Process names sorted by CPU usage — the most active processes |
| Top 10 connections | Established outbound connections with remote IP and process name |
| Security status | Windows Defender state, firewall state, threat count |
| Detected anomalies | The specific deviations the baseline engine flagged, including the σ score |
The threat verdict
| Field | Values | Meaning |
|---|---|---|
| Threat level | low · medium · high · critical | Overall severity of the detected activity |
| Confidence | 0.0 – 1.0 | How certain the AI is of its assessment. Below 0.6 warrants manual review. |
| Summary | Plain English, 1–2 sentences | What is happening and why it is concerning |
| Recommended actions | List of specific steps | Immediate actions the analyst or the system should take |
Result caching
Analysis results are cached per device for 5 minutes. Requesting a device summary twice within that window returns the same result without a new API call. The cache is invalidated when new metrics arrive.
Autonomous Response
For high and critical threat verdicts, Kronyx AI acts without waiting for analyst input — creating incident records, notifying the team, and dispatching response commands to the affected device's agent.
What happens automatically
When Kronyx AI classifies a device as High or Critical, the following chain fires in sequence:
- Incident created — a new incident record is written with source type ai_analysis, the threat summary as the description, and the device linked as the affected endpoint
- Escalation rules checked — the escalation engine runs immediately. Any rule with Trigger After = 0 hours fires right away, pushing the incident into the Active Queue
- Notification sent — an AI Threat notification is delivered to the device owner with a direct link to the incident
- #alerts channel updated — Kronyx AI posts a bot message to the #alerts messaging channel so the entire SOC is notified simultaneously
- Response commands queued — if Claude recommended a kill_process or quarantine_file action, the command is dispatched to the device agent and executed within 3 seconds
Identifying AI-created incidents
| Field in incident record | Value |
|---|---|
| Title | Begins with "AI Detection:" |
| Source | ai_analysis |
| Description | JSON block containing the full threat summary, anomalies list, confidence score, and recommended actions |
AI Security Analyst (Kronyx AI Chat)
Navigate to Kronyx AI in the sidebar to open the conversational analyst interface. Ask questions in plain English and receive structured, contextual answers grounded in your platform's live data.
Selecting a device context
Use the device selector in the top-right of the Kronyx AI page to focus the conversation on a specific endpoint. When a device is selected, Kronyx AI injects that device's latest metrics, processes, and connection data into the conversation — every answer is grounded in the device's actual state, not generic advice. Leave the selector on All devices for platform-wide questions.
Quick action buttons
| Button | What it asks |
|---|---|
| What's suspicious today? | Summarises anomalies and open incidents across all devices from the last 24 hours |
| Analyze all devices | Runs a sweep of each enrolled device and returns a ranked threat summary |
| Show open incidents | Lists currently open incidents with severity, device, and time open |
| Any unusual network activity? | Reviews recent outbound connections and flags any that deviate from baseline |
Response action chips
When Kronyx AI recommends a specific action (e.g. "Kill process X", "Quarantine file Y"), a clickable chip appears below the response. Clicking it dispatches the command directly to the selected device's agent — no navigation required.
Collaboration & Communication
Team Messaging
Kronyx includes a built-in team messaging system so your SOC can communicate, coordinate investigations, and share security context without switching to an external tool. All communication stays inside the platform alongside the incidents, devices, and reports it relates to.
Access messaging via the chat icon in the top header bar.
System channels
Four channels are created automatically when your team first accesses messaging. These cannot be deleted.
| Channel | Purpose |
|---|---|
| #general | Day-to-day team communication — shift handovers, announcements, general discussion |
| #incidents | Incident coordination — loop in colleagues, share initial findings, agree on response actions |
| #threat-intel | Threat intelligence sharing — IOCs, threat actor TTPs, new CVEs, external intelligence feeds |
| #alerts | Managed by the BluAI bot. Do not post here manually — it is the authoritative record of every AI-detected threat |
Direct messages
Click the person+ icon at the top of the channel sidebar and search by name or email. Selecting a team member creates a private channel visible only to the two of you.
Sharing security context
- Click the paperclip icon in the compose bar
- Select the type — Incident, Report, or Investigation
- Search and select the item
- It appears as a rich card in the message — recipients click it to open the full record inside Kronyx
The #alerts channel and BluAI
| Alert message field | Content |
|---|---|
| Title | Threat level and affected device — e.g. "[High] AI Detection: DESKTOP-01" |
| Summary | Plain-English description of what was detected and why it is concerning |
| Incident card | A clickable attachment linking directly to the auto-created incident record |
| Severity badge | Colour-coded — red for Critical, orange for High |
Notifications
Kronyx delivers targeted, contextual notifications to keep individual analysts informed of events that specifically require their attention — without flooding the entire team with every alert.
The bell icon in the top header bar shows your unread count. Clicking it opens the Notifications page.
| Type | When it fires | Who receives it |
|---|---|---|
| AI Threat | BluAI detects a High or Critical threat on a device | The owner of the affected device |
| Escalation | An escalation rule fires and creates a new escalation | All platform users |
| Incident Assigned | An incident is assigned to you | The assigned analyst |
| Mention | A team member @mentions you in a message | The mentioned user |
| System | Platform-level events | All admins |
Notifications page
Notifications are grouped by date (Today / Yesterday / earlier) and filterable by type. Clicking a notification marks it read and navigates directly to the relevant record. Hover and click ✕ to dismiss without navigating.
Live Collaboration
Kronyx shows you in real time which colleagues are active on the platform and what page they are viewing — enabling situational awareness that normally requires a voice call.
The online indicator in the top header bar shows the number of analysts currently active. Clicking it lists each analyst by name and role. When multiple analysts are on the same page, their live cursors appear as labelled pointers overlaid on your screen.
| Cursor state | Meaning |
|---|---|
| Moving cursor with label | The analyst is actively navigating the page |
| Pulsing cursor — "Investigating" | The analyst is actively investigating — set automatically on certain actions |
| Click ripple effect | The analyst clicked something — useful for following along during a walkthrough |
FAQ & Troubleshooting
Common questions and solutions.
Device Issues
A device shows as Disconnected
Confirm the device is powered on and connected to the network, then check that the Kronyx agent service is running:
- Windows: Open
services.mscand look for "Kronyx Agent" — it should be Running - macOS: Run
launchctl list | grep kronyxin Terminal - Linux: Run
systemctl status kronyx-agent
If the service is stopped, start it. If it is running but the device still shows Disconnected, check that the agent can reach the Kronyx server on port 8000. Review the agent log at /var/log/kronyx/agent.log (macOS/Linux) or C:\ProgramData\Kronyx\logs\agent.log (Windows).
A device enrolled but does not appear in the Devices list
After installation the agent can take 1–2 minutes to register. If it still does not appear after 5 minutes: confirm the installer was generated with the correct server address, verify the agent can reach the server with curl http://<server-ip>:8000/health from the device, then restart the agent service.
EDR Questions
A binary shows as Unknown in VirusTotal — is it safe?
No. Unknown means the file has not been submitted to VirusTotal before and has no prior verdict. This can happen with custom internal tools, newly compiled malware, or niche legitimate software. Treat Unknown binaries in sensitive locations (Temp, AppData, user profile) with caution.
Our internal tools keep getting flagged as Suspicious
Open the binary detail view and click Mark as Reviewed to acknowledge it as legitimate. Add a note explaining why. This prevents the binary from re-alerting unless a new version with a different hash is detected.
Network Questions
Network Discovery is not finding all devices
Network Discovery is designed to surface every device on your network — including unregistered and potentially rogue devices that have no agent installed. If a device does not appear, check the following:
- Host firewall blocking ICMP — some devices are configured to silently drop ping requests. Kronyx also uses ARP and port-based probing to detect these devices even when ICMP is blocked.
- Device is powered off or disconnected — discovery only captures devices that are active on the network at scan time. Schedule recurring scans to build a more complete picture over time.
- Scan range not configured — ensure your scan target covers the full IP range of your network, not just the default subnet. You can set a custom CIDR range in the Network Discovery settings.
- Devices on separate VLANs — deploy a Kronyx agent on a host within each VLAN segment so discovery scans run from inside that segment. This is intentional security architecture, not a platform limitation.
Any device that responds on the network — registered or not — will appear in the discovery results. Unregistered devices are flagged so analysts can investigate whether they are authorised.
Traffic Analysis shows no data
Traffic Analysis requires the Kronyx backend to have visibility into network traffic. You may need to configure a SPAN/mirror port on your switch, or deploy the Kronyx network sensor on a device with access to network traffic. Consult your network administrator.
Too many false positives in Threat Detection
Go to Threat Detection → Settings and adjust sensitivity thresholds or whitelist specific source/destination IPs. Common sources of false positives include backup software generating high outbound traffic and internal vulnerability scanners — whitelist their IPs to suppress noise.
Pentesting Questions
A finding shows N/A instead of a CVE/CVSS score
This is expected for open-port and API-fuzz findings — neither is tracked in the CVE system (an open port or an API schema violation isn't a "vulnerability" with a CVE identifier the way a known software flaw is). A bare "—" instead of N/A means the finding is a CVE-eligible type (TLS/SSL or vulnerability scan) but a score couldn't be resolved — usually because that specific check doesn't reference a CVE at all (most testssl checks don't).
Will an API fuzz scan affect my live site or data?
Yes, potentially — unlike the other three active scans, API fuzz sends real state-changing requests (POST/PUT/DELETE with fuzzed bodies) to whatever your API spec documents. It's rate-limited and capped per run, and deliberately excluded from scheduled/automatic scanning for this reason. Only run it against targets and environments where that's acceptable.
I added a target but can't run active scans
Active scans (Nuclei, port scan, TLS/SSL audit, API fuzz) require the target to be Verified first. For domains, add the DNS TXT record shown in the Add Target dialog and click Verify. For servers, verification happens automatically the moment a real SSH connection succeeds with the credentials you provided — if it shows Failed, double-check the host, port, username, and credentials.
API Reference
Use the Kronyx REST API to integrate with your existing security tools, automate workflows, or build custom dashboards. All endpoints require a Bearer token.
Authentication
Generate an API key from Dashboard → API Settings. Every request must include the key in the Authorization header:
# Example — list all devices
curl -X GET \
http://localhost:8000/api/v1/devices \
-H "Authorization: Bearer kronyx_your_key_here" \
-H "Content-Type: application/json"
Endpoint Reference
All endpoints are prefixed with your server address (e.g. http://localhost:8000).
Authentication
| Method | Path | Description |
|---|---|---|
| POST | /api/auth/login | Obtain an access token |
| POST | /api/auth/register | Create a new user account |
| POST | /api/auth/refresh | Refresh an expired access token |
| GET | /api/auth/api-keys | List your API keys |
| POST | /api/auth/api-keys | Generate a new API key |
| DELETE | /api/auth/api-keys/{id} | Revoke an API key |
Devices
| Method | Path | Description |
|---|---|---|
| GET | /api/v1/devices | List all enrolled devices |
| GET | /api/v1/devices/{id} | Get device details |
| POST | /api/v1/devices/enroll | Enroll a new device |
| DELETE | /api/v1/devices/{id} | Remove a device |
| GET | /api/v1/devices/{id}/metrics | Get live device metrics |
Incidents & Escalations
| Method | Path | Description |
|---|---|---|
| GET | /api/incidents | List all incidents |
| POST | /api/incidents | Create a new incident |
| GET | /api/incidents/{id} | Get incident details |
| PUT | /api/incidents/{id} | Update incident status |
| GET | /api/escalations | List escalation rules |
| POST | /api/escalations | Create an escalation rule |
Threat Intelligence
| Method | Path | Description |
|---|---|---|
| GET | /api/edr/binaries | List scanned binaries |
| POST | /api/edr/binaries/scan | Submit a file hash for scanning |
| GET | /api/threat-map/events | Get live threat map events |
Network
| Method | Path | Description |
|---|---|---|
| GET | /api/network/discovery | List discovered network devices |
| POST | /api/network/scan | Trigger a new network scan |
| GET | /api/network/traffic | Get traffic analysis data |
Interactive Explorer
Try any endpoint directly below using your API key. The explorer is powered by the live FastAPI server running alongside this application.
Bearer field, then use any endpoint interactively.Can't find what you're looking for?
Open Dashboard