Ransomware Detection

Scope

Ransomware response depends on speed, context, and confidence in the operating picture. This public guide keeps the workflow model and removes private detection and execution detail.

Overview

Ransomware Detection provides continuous monitoring of managed endpoints for ransomware-indicative activity. The system uses six signal sources to compute a composite risk score per endpoint, and can automatically contain threats when configured to do so.

Navigate to the Ransomware Detection page from the main navigation menu.

Activating a Policy

Activating a policy starts monitoring on all endpoints in the policy’s scope.

1. Select the policy from the list.
2. Click Activate.

What happens on activation:

• If entropy monitoring is enabled: an entropy_monitor daemon job is dispatched to each covered endpoint. The agent begins scanning the configured directories at the specified interval.
• If canary monitoring is enabled: a canary_deploy job is dispatched to each covered endpoint. The agent creates realistic-looking decoy files (spreadsheets, documents, backups) in the configured locations.

The activation response shows how many jobs were dispatched and their types.

Deactivating a Policy

Click Deactivate to stop monitoring:

• Canary removal jobs are dispatched to clean up deployed canary files.
• Daemon stop jobs are dispatched to halt running entropy monitors.

Monitoring the Dashboard and Risk Scores

Dashboard

The dashboard provides an at-a-glance view of your ransomware detection posture:

• Risk Distribution – count of endpoints at each risk level (none, low, medium, high, critical)
• Containment Status – count of endpoints currently monitoring, isolating, or isolated
• Active Policies – number of active vs total policies
• Top Risk Endpoints – the 10 endpoints with the highest risk scores

• Recent Activity – signal count and containment actions in the last 24 hours. This count is limited to endpoints you can currently see; org-scoped operators do not get sibling-org signal volume from the same account folded into the card

• Current score widgets and readiness views follow each endpoint’s current organization ownership. If an endpoint is moved between organizations, its live ransomware score moves with it instead of lingering in the old scope

Risk Scores

Each monitored endpoint has a composite risk score (0.0-1.0) built from six signals:

Signal	Weight	What It Measures
File Entropy	30%	High-entropy file writes (encryption indicator)
Canary Triggered	25%	Canary file tampering (very high confidence)
Drift Indicators	15%	System fingerprint changes correlated with ransomware (disabled AV, new admin accounts, firewall changes)
Exfiltration Risk	10%	Network exfiltration alerts and risk scores
Process Anomaly	10%	Deviations from process baselines
Health Degradation	10%	Endpoint health score drops

Risk levels:

• None (< 0.20) – no indicators detected
• Low (0.20 - 0.39) – minor indicators, worth monitoring
• Medium (0.40 - 0.59) – multiple indicators, investigate promptly
• High (0.60 - 0.79) – strong indicators, active investigation needed
• Critical (>= 0.80) – very high confidence, containment recommended

Scores decay exponentially with a 30-minute half-life when signals stop arriving.

Forensic Timeline

The backend/API supports endpoint timeline reconstruction and incident timeline refresh, and the current frontend page now surfaces endpoint timeline entries inline from the risk-score expansion flow plus incident-level timeline refresh. A dedicated standalone endpoint timeline browser is not yet wired in this repo UI.

Threshold Overrides

Customize risk level thresholds at different scopes (most specific wins):

1. Individual endpoint
2. Endpoint group
3. Organization
4. Account-wide

You can also override signal weights to emphasize certain signals for specific environments (e.g., increase canary weight for file servers).

To manage overrides from the shipped UI:

1. Go to the Containment tab.
2. Review the existing override list and scope labels.
3. Click Add Override to create a new scope-specific threshold set.
4. Set the four score thresholds in ascending order and optionally override individual signal weights.
5. Click Create Override or Save Changes.

Operator guardrails:

• Account-wide overrides are restricted to account admins or owners.
• Organization-scoped operators can only create, edit, or delete overrides for organizations, endpoint groups, and endpoints they already have access to.
• The backend rejects mixed-scope ownership that does not agree on the same account and organization, so an endpoint, endpoint group, and organization cannot be stitched together across tenant boundaries.
• Only one override exists for any exact scope, so if you need a different threshold set you edit the existing row rather than stacking duplicates.

The same tab also supports:

• Editing an existing override in place
• Deleting an override after an explicit in-app confirmation
• Refreshing the list without leaving the current tab

Dedicated effective-threshold inspection for a single endpoint is still API-backed rather than shown as a separate operator route.

Canary Inventory and Events

The shipped UI now includes a dedicated Canaries tab, and the direct route the relevant workflow opens the same page with that tab selected.

Use this workflow to:

• Filter deployed canary files by organization, endpoint, and status
• Review last verification time and deployment time
• Trigger Verify Endpoint for an endpoint that should re-check canary integrity
• Review canary trigger events independently from the risk-score expansion flow
• Expand an event row to inspect process, PID, user, and event details

The Canaries tab has explicit loading, empty, and retryable error states, so a failed fetch does not silently collapse the workflow.

Tenant boundary note: canary inventory and trigger events are now enforced at current account/organization, event rows must match their parent canary, and simulation-owned canaries/events are tied to the specific simulation that created them.

Entropy Events

The shipped UI now includes a dedicated Entropy Events tab, and the direct route the relevant workflow opens the same page with that tab selected.

Use this workflow to:

• Filter entropy events by endpoint, severity, and time window
• Review affected-path, extension-change, and triggering-process summaries
• Expand an event row to inspect the detailed affected paths, process list, and extension changes

If you enter an invalid time range (start after end), the page rejects it inline instead of sending a bad request.

account and derive their organization from the reporting endpoint. Simulation-owned entropy events are tied to the specific simulation that created them.

Responding to Incidents

Ransomware Incidents

An incident is automatically created when an endpoint crosses into high or critical risk. If an older high/critical score row exists without an incident, the next correlation cycle backfills it. Incidents track:

• Kill chain phase: reconnaissance, lateral_movement, pre_encryption, active_encryption, post_encryption
• Affected endpoints: which endpoints are involved
• Blast radius: assessment of at-risk endpoints (same org, same group, credential overlap, network flows)
• Timeline: chronological events from detection through containment
• Containment actions: queued evidence-gather, snapshot, isolate, and release actions plus their status

Releasing Isolation

After investigation is complete:

1. Click Release on the isolated endpoint.
2. A release job is dispatched to remove the firewall rules.

The incident action history records the queued network_release action.

Active Isolations

View all currently isolated endpoints in the Active Isolations list, showing hostname, risk level, composite score, and when containment started.

Circuit Breaker

The circuit breaker prevents runaway auto-containment. If more than max_auto_actions_per_hour auto-isolation actions occur within an hour, the breaker trips:

• All auto-containment pauses
• Operators are notified
• Manual isolation still works

To resume auto-containment after investigation:

1. Review the situation.
2. Click Reset Circuit Breaker.

Refreshing Incident Data

The incident detail panel provides two refresh actions for active investigations:

1. Refresh Timeline – Rebuilds the forensic timeline by querying live risk score changes, entropy events, canary triggers, and containment actions across ALL affected endpoints. Updates the kill chain phase assessment.
2. Refresh Blast Radius – Reassesses the blast radius by checking organizational, endpoint-group, credential, and network flow overlap for ALL affected endpoints. Shows total endpoints at risk.

These buttons appear in the expanded incident detail row.

Recovery from Backup

When an incident is contained and you need to restore:

1. Open the incident detail.
2. Click Clean Restore Points to see available backups. - Only backups completed BEFORE the first indicator timestamp are shown. - Verified (integrity-passed) backups are preferred.
3. Select a restore point and choose the restore type: - Files – restore specific files/directories - Image – full image restore
4. Click Recover to dispatch the restore job.

The incident status automatically transitions to “recovering” with the recovery timestamp set.

Updating Incident Status

Update incident fields as the investigation progresses:

• Status: active -> contained -> recovering -> resolved (or false_positive)
• Entry Point Hypothesis: document how the attack started
• Kill Chain Phase: track progression through the kill chain

Status transitions auto-set timestamps (containment_completed_at, recovery_started_at, recovery_completed_at).

Running Simulations

Simulations validate your detection pipeline without triggering real containment.

Create a Simulation

1. Go to the Simulations tab.
2. Click Create Simulation.
3. Configure: - Name – descriptive name - Scenario Type:
   • encryption_only – simulates pure encryption activity
   • double_extortion – simulates data exfiltration followed by encryption
   • wiper – simulates destructive (non-ransom) attack
   • targeted – simulates targeted attack on specific files/endpoints
   • Target Endpoints – select endpoints to inject simulated signals into
   • Expected Actions – what you expect the system to do (for result comparison)
4. Click Start.

Scope rules:

• You can only target endpoints in organizations you can access.
• If you set an explicit organization, every selected endpoint must belong to that same organization.
• If you leave organization blank and all selected endpoints belong to one organization, the system records the simulation under that organization automatically.
• If you leave organization blank and target multiple organizations, only users who can access every targeted organization can later open or cancel that simulation.

What Happens During a Simulation

1. Simulated entropy events and canary events are injected into the target endpoints (all tagged is_simulation=True and linked to the creating simulation).
2. The scoring engine processes the simulated data.
3. The engine evaluates what containment actions it would take (but does NOT dispatch them).
4. Results are recorded: actual_actions vs expected_actions.

Reviewing Results

Open a completed simulation to see:

• What actions the engine would have taken
• Whether they matched your expectations
• A results summary

Simulation status values:

• completed — simulation ran successfully and results are available
• failed — simulation encountered an internal error and did not produce reliable results. Check server logs for details. Do NOT treat a failed simulation as a passing drill.
• cancelled — simulation was manually stopped before completion
• pending / running — simulation is queued or in progress

Cancelling a Simulation

Cancel a pending or running simulation to stop it and clean up that simulation’s tagged data. Cleanup is scoped to the simulation id, so cancelling or cleaning one drill no longer removes another simulation’s artifacts on the same endpoint. If the simulation spans multiple organizations, only a user whose scope covers every targeted organization can cancel it.

Understanding Readiness Metrics

The Readiness Report assesses your detection posture:

Detection Coverage

• Total endpoints in your account
• Endpoints with active policy coverage (have a risk score record)
• Endpoints with entropy monitoring running
• Endpoints with canary files deployed
• Overall coverage percentage

Policy Summary

• Total policies
• Active policies
• Policies with auto-isolate enabled

Historical Incidents

• Total incidents
• Resolved incidents
• False positive rate
• Average detection time (first indicator to detection)
• Average containment time (first indicator to containment complete)

Recommendations

The system generates actionable recommendations based on your current state:

• Low coverage: expand policy scope
• No active policies: create and activate one
• No auto-isolate: consider enabling for critical endpoints
• No canaries: deploy canary files for high-confidence detection
• High false positive rate: review thresholds and whitelists
• Good coverage: consider running a simulation to validate response procedures

Permissions

Action	Required Permission
View dashboard, risk scores, policies, events, reports	ransomware.view
Create/edit/delete policies, manage thresholds, verify canaries, run simulations	ransomware.manage
Isolate/release endpoints, update incidents, reset circuit breaker, initiate recovery	ransomware.respond