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.

Self-Hosting Kronyx

For teams that want to run the Kronyx backend on their own infrastructure instead of (or alongside) a Kronyx-hosted instance. This walks through provisioning a server, deploying the backend stack, and connecting a frontend to it using a standard Docker Compose setup.

What you're deploying

The backend stack is a Docker Compose project with the blu-api application, a Postgres database, a scan worker that runs pentesting jobs, and Caddy as a reverse proxy that automatically issues and renews HTTPS certificates. The dashboard (blu-frontend) is a separate Next.js application that doesn't need to live on the same server — it just needs to be pointed at your backend's URL once it's deployed. See Connecting the Frontend below.

Requirements

Choose a Hosting Provider

The steps below are identical regardless of where the server itself lives — any provider that gives you a Docker-capable Linux VM with a public IP works the same way. Quick-start notes for the major ones:

Clone, Configure & Deploy

1. Install Docker

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
# log out and back in for the group change to apply
docker compose version

2. Set up access to the private repository

Generate a dedicated SSH key on the server and give the public half to your Kronyx contact (or add it yourself under the repository's Settings → Deploy keys if you've been given access directly):

ssh-keygen -t ed25519 -f ~/.ssh/kronyx_deploy_key -N ""
cat ~/.ssh/kronyx_deploy_key.pub

Then tell git to use that key for GitHub:

cat >> ~/.ssh/config <<'EOF'
Host github.com
  IdentityFile ~/.ssh/kronyx_deploy_key
  IdentitiesOnly yes
EOF

3. Clone the repository

git clone git@github.com:<repo-provided-by-kronyx>.git
cd <repo-name>/infra

4. Configure your environment

cp .env.example .env

Then edit .env and fill in at least these values:

5. Point your domain at the server, and update the Caddyfile

Create an A record for the hostname you used in API_URL (e.g. api.yourcompany.com) pointing at the server's public IP. Then open infra/Caddyfile and set that same hostname there — it isn't templated from .env, so it needs to be edited directly:

api.yourcompany.com {
    reverse_proxy blu-api:8000
}

6. Build and start the stack

docker compose up -d --build
docker compose ps

Caddy automatically requests and renews a free HTTPS certificate the first time it sees traffic for the domain in the Caddyfile, as long as the DNS record above has propagated and ports 80/443 are reachable — no manual certificate setup needed. Confirm it worked:

curl -I https://api.yourcompany.com/health

Optional: the self-hosted mail gateway

The stack also includes an inbound/outbound mail-scanning gateway (Postfix + a milter pair) for the Email Security module, and it starts by default. If you don't plan to route real mail through this server, you can remove the milter, milter-outbound, and postfix services from infra/docker-compose.yml — leaving them running unused doesn't affect anything else. If you do use it, you'll additionally need MX records pointing at this server and ports 25/587 open.

Connecting the Frontend

The dashboard is a separate Next.js application and isn't part of the Docker Compose stack above — you can deploy it to Vercel, Netlify, or any other Next.js-capable host, or run it yourself. Whichever you choose, set one environment variable on that deployment:

NEXT_PUBLIC_API_URL=https://api.yourcompany.com

— the same URL you set as API_URL in the backend's .env.

Once the frontend is live and pointed at your backend, open it and use the normal Sign Up page to create your first account — every self-registered account is automatically a full administrator of its own organization. You can log in right away; email verification is separate, so outbound email (see the SMTP_USERNAME/SMTP_PASSWORD step above) is what's needed for that confirmation link, and any future password-reset emails, to actually arrive.

Updating & Redeploying

Kronyx ships ongoing improvements to the same private repository. To pick up changes, pull the latest code and rebuild the stack:

cd ~/Blu
git pull
docker compose -f infra/docker-compose.yml up -d --build

This rebuilds only the images whose source changed and recreates containers with the new code, without touching your .env or the Postgres data volume.

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:

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 open the Deploy tab (or click Deploy Agent).

1. Click Generate New Key. Name it after the team or department the devices belong to (for example, Finance) and leave the operating system on Any OS unless the key should only ever be used for one. Copy the key value — it is shown once
2. Under Install the Agent, choose the target operating system, then either pick a deployment method (PowerShell, shell script, Group Policy, Intune, and others) or download a ready-made installer (MSI, .exe, .deb, or .rpm)
3. Run the script or installer on the target machine — as Administrator on Windows, with sudo on Linux
4. The device appears on the Devices tab under the key's name, showing Enrolling and then Active within a minute or two

Step 4 — Configure Escalation Rules

Go to EDR → Management → Escalations and click New Rule. Recommended starting rules:

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 Active
• 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

1. Check Escalations → Active Queue — acknowledge anything that fired overnight
2. Check Devices — confirm all endpoints are connected
3. Review Binaries — triage new VirusTotal alerts
4. Review Autoruns — check for new persistence entries
5. Check Network → Threat Detection — network-level IoCs
6. Work open Investigations — update evidence and notes
7. Check Network Discovery — spot unauthorised devices

Responding to a Threat

Severity Reference

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.

Adding a Device

Devices are added from the Deploy tab (also reachable with the Deploy Agent button). Adding a device is two steps: generate an enrollment key, then install the agent using that key.

1. Generate a key.

1. Click Generate New Key
2. Name the key. The name is the device category — every device that enrolls with a key named "Finance" is listed under Finance in the device list
3. Choose the operating system: Any OS (recommended — one key works for Windows, Linux, and macOS devices and devices can be moved between such keys freely) or a single OS, which restricts the key to devices of that OS
4. Click Generate and copy the key value

The Your Keys table lists every key with its name, operating system, how many devices are currently filed under it (and its enrollment limit, if one is set), and whether it is Active or Revoked. Each key can be edited (name, operating system, maximum enrollments, expiry), revoked so it accepts no new devices, or deleted. Devices already enrolled keep running when a key is revoked or deleted; deleting a key moves its devices to Uncategorized.

2. Install the agent. Under Install the Agent, pick the target operating system and one of two ways to install:

Deployment methods (scripts and configuration)

For Group Policy, Intune, and SCCM, choose between a Script (a startup or platform script) and an MSI package (a Software Installation package, Win32 app, or Application) — the MSI option uses the Windows installer described below.

• PowerShell: open PowerShell as Administrator and paste the script, or run the downloaded file with powershell -ExecutionPolicy Bypass -File followed by its path. Double-clicking a .ps1 file opens it in an editor instead of running it — this is standard Windows behaviour
• Shell script (Linux, macOS): make the downloaded file executable and run it as root, for example chmod +x ./script.sh && sudo ./script.sh
• Requirements: script methods need Python 3.8 or later on the target machine. On Windows, install it for all users, because the agent's background task runs as the SYSTEM account
• What it sets up: the agent is registered to run in the background and to start again after a reboot — as a Scheduled Task on Windows, and a system service on Linux and macOS

Direct installers

Each package card shows its version, size, SHA-256 checksum for verification, a GPG signed badge where the package is signed, a Download button, and the exact install command with your key already filled in. Compiled installers need no Python on the target machine, which makes them the right choice for locked-down and offline environments.

3. Confirm the device appears. On the Devices tab the new device shows Enrolling and then Active within a minute or two, filed under your key's name. From then on the agent checks in every 5 minutes, and a device with no check-in for about 10 minutes shows Offline.

Organizing Devices

A device's Category is the key it enrolled with, shown as a column in the device list. Devices with no key show as Uncategorized.

• Filter the list by Category, by OS, or by tag; use Clear to reset the filters
• Rename a category by editing its key on the Deploy tab — the new name applies everywhere immediately
• Tag a device with free-form labels such as vip, server, or needs-review (up to 20 tags per device) to find and group devices however you like
• Move devices between keys if one was enrolled under the wrong one: tick one or more devices and click Move to key…, or use the move action on a single row, then choose the destination key

Isolating a Compromised Device

If a device may be compromised, isolate it so analysts can investigate before a threat spreads across the network. Only the connection to Kronyx (plus DNS and DHCP) stays open, so the device can still be worked on remotely.

1. Click the isolate (shield) button on the device's row, or Isolate on its detail page
2. Enter a reason — it is recorded in the audit log
3. Choose how long to keep it isolated (1 hour to 7 days) and confirm

The device shows Isolating… until the agent confirms, then Isolated. If the device is offline, isolation is applied the next time it checks in. Isolation ends on its own when the time runs out, or immediately when you click Release; starting isolation also opens an incident.

Removing a Device

Internal Network Scan

This is Kronyx's internal pentest capability — since the agent already runs inside your network, it's a real internal vantage point, not a separate on-prem appliance. Click Internal Scan on a connected device to sweep that device's local subnet for live hosts, then port-scan each one found for the same high-risk services (Telnet, SMB, exposed databases, and similar) Kronyx already checks for externally.

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.

High-Risk Patterns

• Entries pointing to files in %TEMP%, %APPDATA%, or C:\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.

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.

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

The Active Queue

Navigate to EDR → Management → Escalations to see the Active Queue. Each card shows:

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:

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:

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.

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

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.

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.

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.

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.

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.

High-Risk Ports

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.

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.

Overview

Two separate, independent ways to protect a domain's mail — pick whichever fits how your organization actually receives email, or use both for different domains.

Connect a Mailbox detects and responds to threats through that provider's own API — Kronyx is notified in near real time and can quarantine a message the same way. The Mail Gateway is deeper: your domain's actual mail flow is rerouted through Kronyx's own server first, so a malicious message can be stopped before it's ever delivered, not just flagged afterward — the trade-off is a real MX record change, which carries more weight to get right.

Connect a Mailbox

Go to Email Security → Connect Mailbox, choose Microsoft 365 or Google Workspace, and sign in with an account that has admin consent for the organization (not a single mailbox) — Kronyx needs tenant-level permission to monitor every mailbox, not just the one you authorize with. Nothing in DNS changes; protection starts as soon as the connection shows Active.

Mail Gateway (Any Domain)

Go to Email Security → Add Domain. Setup is two steps, and the dialog always shows exactly where you are in the process:

Step 1 — Prove you own the domain

Add a DNS TXT record at your domain's DNS provider using the exact name and value the dialog shows you (the value starts with kronyx-verify=), then click Verify Now. DNS changes can take a few minutes to propagate — if verification fails right away, wait a bit and try again; the record stays available in the dialog, so there's nothing to re-copy.

Step 2 — Point mail at the Kronyx gateway

Once verified, the dialog shows an MX record value (mail.kronyx.cloud). Replace your domain's existing MX record with this value at your DNS provider, then click Check MX.

Once Kronyx confirms the MX record points at the gateway, the domain shows active and every message to and from this domain is scanned before delivery.

Outbound Relay (DLP on Send)

Everything in Step 1/2 above protects mail arriving at your domain. Outbound Relay is a separate, additive feature for mail leaving your organization: Kronyx scans it for data-loss-prevention policy violations — things like a credit card number, a social security number, or a flagged confidential document — before it's delivered to its real destination.

Do you need this?

Only if your organization runs its own outbound mail server or relay — an on-premise Exchange server, a self-hosted Postfix relay, a security appliance — that you can reconfigure to route outbound mail through Kronyx's gateway as a smarthost. If your organization sends mail directly through Microsoft 365 or Google Workspace's own infrastructure with no separate server in between, there is nothing on your side to point at this setting — leave it disabled. (If you've also connected that mailbox via the Connect a Mailbox track above, outbound mail sent through that provider isn't affected by this setting either way — this field is specifically for a server you control.)

Finding your mail server's IP

The dialog asks for your outbound mail server's IP — the public address Kronyx's gateway will see that server's connections coming from, not an address you choose or make up. The reliable way to find it is to check from the mail server itself, not from your laptop — for example, run a command like curl https://api.ipify.org directly on that server, or ask whoever manages your network/firewall for its public outbound (NAT) IP address. If nobody in your organization can answer "what IP does our mail server send from," you most likely don't have a dedicated outbound server at all, and this feature doesn't apply to you.

Enter that IP and click Enable. Kronyx's gateway only accepts outbound relay connections claiming to send as your domain from that exact IP — every other source is still rejected, so enabling this does not turn your domain into an open relay for anyone else.

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 & Repositories)

A target is anything Kronyx will run scans against — a domain/web application, a server reachable over SSH, or a git repository. 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.

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.

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.

Adding a Repository

Click Add Target → Repository... and provide the clone URL and, for a private repository, an access token.

Kronyx attempts a real connection immediately (a lightweight git ls-remote, no full clone). A successful connection marks the repository Verified — the same reasoning as servers: working access already proves authorization, no separate ownership challenge is needed. The access token is encrypted at rest before being stored.

Verification Status

Scan Types

Every verified target can run four active scan types, each mapping to a real, industry-standard tool — not a simulation.

Domains additionally offer five passive recon scans that don't require verification: Cert (subdomain discovery via certificate transparency logs), Subdomains (broader passive subdomain discovery via subfinder — DNS aggregators and search engines, not just certificate 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).

Repository Scan Types

Connected repositories offer three scan types of their own, launched the same way — a target's Run Scans button.

Each scan clones the repository fresh and discards the checkout afterward — nothing from your source code is retained beyond the scan results themselves.

Adding a Cloud Account

Click Add Target → Cloud Account (AWS)... and provide an AWS access key pair. Create a dedicated IAM user for Kronyx first and attach AWS's own managed SecurityAudit policy — a broad read-only policy purpose-built for exactly this kind of posture scanning.

Kronyx attempts a real, read-only AWS STS GetCallerIdentity call immediately. A successful call marks the account Verified and records the AWS account ID — the same reasoning as servers and repositories: a working, authenticated connection already proves the credentials are valid, no separate challenge is needed. The secret access key is encrypted at rest before being stored and is never displayed again after entry.

Cloud Scan Types

Connected cloud accounts offer one scan type, launched the same way — a target's Run Scans button.

Findings carry compliance framework mappings straight from Prowler's own checks (CIS, PCI-DSS, SOC2, HIPAA, and more) in their evidence, giving every posture finding a ready-made audit trail.

Adding a Network

Click Add Target → Network (IP/CIDR)... and provide an IP or CIDR range you own — e.g. 203.0.113.0/24 or a single host as 203.0.113.5/32.

Unlike domains (DNS), servers (SSH), and repositories (git access), a bare IP range has no direct "prove you control this" mechanism, so Kronyx instead looks up the range's real, live RDAP registration (the modern, JSON-based successor to WHOIS) and checks whether the registrant or a contact email's domain matches your organization's name or one of your already-verified domains.

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.

Sandbox Terminal

For hands-on testers who'd rather type real commands than click buttons — the Sandbox Terminal is a real, isolated Linux shell with the platform's actual pentest tools pre-installed, opened directly from the dashboard.

Opening a Session

Go to Pentesting → Targets and click Open Sandbox Terminal. This requires at least one verified domain, server, or network — an empty allowlist would boot a shell with no reachable targets at all, so Kronyx refuses to open one rather than hand you a useless session.

What's Installed

Network Access

A default-deny firewall restricts all outbound traffic to your organisation's verified targets' resolved IP addresses, plus DNS — re-resolved every 60 seconds so a target's IP can change without breaking the session.

Running Commands

The scan-mode buttons above the terminal fire the exact same tracked scan jobs the dashboard's Run Scans dialogs use — their results become real Findings. Typing a command directly into the shell only prints to that terminal; it doesn't create a Finding or appear anywhere else in Kronyx. Use the buttons when you want a result tracked, and the shell when you want to explore, learn, or run something custom.

Replace target.com below with one of your own verified targets.

Scanning a Verified Network Range

A verified Network has no scan-mode buttons at all — nmap and masscan both take a CIDR range natively, so there's nothing to wrap in a tracked job. Replace 203.0.113.0/24 below with your own verified range (shown in the target bar above the terminal as "Also reachable: ...").

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.

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.

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.

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.

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:

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:

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

The threat verdict

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:

1. 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
2. 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
3. Notification sent — an AI Threat notification is delivered to the device owner with a direct link to the incident
4. #alerts channel updated — Kronyx AI posts a bot message to the #alerts messaging channel so the entire SOC is notified simultaneously
5. 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

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

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.

Bring Your Own API Key

Kronyx AI — device analysis, the chat assistant, pentest threat modeling and email analysis — runs on your organization's own AI provider key. There is no shared key: until an organization admin adds one, Kronyx AI is off, and once added, usage is billed by your provider to your own account.

Where to set it

Go to Settings (from the account menu in the header) and find the Kronyx AI card. It's visible to organization administrators on every plan.

Supported providers

Setting it up

1. Choose a provider from the dropdown
2. Paste your API key — an optional Model field lets you override the default model for that provider
3. Click Save Key

Once saved, Kronyx AI turns on and every request from your organization uses your key immediately — no restart or delay. Click Remove key at any time to turn Kronyx AI off again for your organization.

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.

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

1. Click the paperclip icon in the compose bar
2. Select the type — Incident, Report, or Investigation
3. Search and select the item
4. It appears as a rich card in the message — recipients click it to open the full record inside Kronyx

The #alerts channel and BluAI

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.

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.

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.msc and look for "Kronyx Agent" — it should be Running
• macOS: Run launchctl list | grep kronyx in 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:

Endpoint Reference

All endpoints are prefixed with your server address (e.g. http://localhost:8000).

Authentication

Devices

Incidents & Escalations

Threat Intelligence

Network

Interactive Explorer

Try any endpoint directly below using your API key. The explorer is powered by the live FastAPI server running alongside this application.