Response actions

FreeDR can contain threats on the local host: stop processes, quarantine or delete files, disable persistence, block traffic and isolate the host. Every action belongs to a case, runs through one response executor inside the FreeDR service (freedr-response-win, running as LocalSystem), and is recorded in the case audit.

Native qualification is partial

The action set below is implemented in code. Per ADR-0059, native qualification on every supported Windows 10/11 build is still pending, and network blocking and isolation report filter readback (the exact filters are installed), not proven traffic blocking or reboot continuity. The UI shows Traffic efficacy: not qualified / Reboot continuity: not qualified unless a recorded test profile says otherwise.

Available actions

Action (kind)	Console label	What it does	Reversible by
terminate_processes	Terminate exact current process	Terminates exact processes, bound by PID and native creation time and image path.	Not reversible
quarantine_file	Quarantine exact file	Copies the file (all data streams, security descriptor, supported metadata) into an encrypted vault, verifies the copy, then removes the original name.	restore_quarantine
restore_quarantine	Restore quarantined file	Authenticates the vault item and restores it to the original location or a chosen destination folder, without overwriting an existing file.	n/a
delete_file	Permanent deletion — no recovery guarantee	Deletes the exact file name. Shown as irreversible.	Not reversible
remediate_persistence	Remove exact Run value / Disable exact task / Disable service start / Remove exact WMI binding	Run/RunOnce: removes one exact value (hive or user SID, 64/32-bit view). Scheduled task: disables the exact task. Service: sets start type to disabled (a running service is not stopped; use a process step). WMI: removes only the exact root\subscription filter-to-consumer binding. The prior configuration is captured first.	restore_persistence
restore_persistence	Restore captured persistence	Restores the captured configuration, only if the current state still matches what FreeDR left.	n/a
block_traffic	Block observed endpoint / Block traffic for application path	Windows Filtering Platform (WFP) filters for a remote IP/CIDR (optionally protocol, ports, direction) or an application path.	remove_traffic_block
remove_traffic_block	Remove owned traffic block	Removes exactly the filters FreeDR installed for that block.	n/a
isolate_host	Isolate this computer — disrupts network access	WFP filters blocking all non-loopback IPv4/IPv6 traffic, inbound and outbound. The local console stays reachable.	release_isolation
release_isolation	Release host isolation	Removes exactly the owned isolation filters.	n/a

There are no other actions: no shell commands, scripts, registry edits beyond the above, user/account changes, or reboot-time deletions. A plan holds at most 32 steps; a process step at most 32 processes.

Not supported (fail before anything is changed): EFS, reparse, sparse, offline/recall files; files on non-fixed, UNC or device paths. File inspection and quarantine are limited to 1 GiB per file (10 GiB total vault). Domain-name blocking is not offered.

Case scoping

• A response job is created under /api/v1/cases/{case_id}/response and is bound to that case (case_id, its updated_at_us and assessment_revision).
• Every step must cite a retained alert or event linked to that case, except isolate_host and the recovery actions (restore, remove block, release), which are bound to their source step instead.
• The service reloads the cited evidence and binds each target to it. If the evidence or target no longer matches, the request fails with 409 response_prerequisites_changed.
• While a case has a queued, running or needs-attention job, it cannot be merged or split.

Workflow in the console

On a case, open the Response tab:

1. Choose a retained case citation (an alert or event linked to the case) and click Inspect current targets (POST .../response/inspect). The service inspects the live system read-only and returns candidate actions for supported targets in that evidence:

   • process start with an unambiguous lifetime: terminate the current process;
   • file: quarantine, or permanent deletion;
   • Run value, scheduled task, service, WMI binding: the matching persistence action;
   • network connection: block the remote endpoint, or block the application path;
   • always (when there is evidence): isolate this computer.

   Candidates carry the limitation Current inspection does not prove a historical object identity. Execution rechecks the target. 2. Add candidates to the draft, reorder or remove steps, and enter a purpose. The exact native target of each step can be expanded and reviewed. 3. Submit (POST /api/v1/cases/{case_id}/response). The job is queued and runs immediately in order. The message reads Actions queued. Refresh to see execution results. 4. Review the job: state, per-step postcondition, OS outcome, receipts and limitations.

Approval and confirmation

• There is no approval step. ADR-0060 removed the earlier UAC/approval-helper workflow and response permission policy. A signed-in console session plus the CSRF operation token is the full authority to submit a plan (ADR-0062, ADR-0060).
• The case Response tab submits without a confirmation dialog; reviewing the draft is the confirmation. Only the Overview Isolate host / Release isolation buttons show a browser confirmation.
• There is no per-action password, second factor or role check.
• freedrctl has no response commands. The custom-URI/freedrctl approval handler described in ADR-0058/0059 does not exist in the current code.

Cancel

POST /api/v1/cases/{case_id}/response/{job_id}/cancel with the job's expected_revision requests cancellation. It stops future effects only; Cancellation requested. Completed Windows changes are not reversed.

Recovery (undo)

For a finished quarantine, persistence, block or isolation step, the job view offers recovery (POST /api/v1/cases/{case_id}/response/recovery, body: source step and optional destination folder for file restore). It creates a new single-step job. Restoration refuses intervening changes; release removes only the exact filters FreeDR installed.

Host isolation from Overview

Overview has Isolate host and Release isolation buttons and a banner (ADR-0059 addendum).

• POST /api/v1/host/isolation with {schema_version: 1, csrf_token, change: "isolate" | "release"}; GET /api/v1/host/isolation returns the state.
• Isolate creates an ordinary response job in the newest open case titled Manual host isolation (created on first use, severity Low, no alerts). Release creates release steps in every case that owns isolation filters.
• The plan purpose records the requesting session as console session <12 hex> (a SHA-256 prefix of the session token, not the token).
• Results: 200 already_isolated, 200 not_isolated, 409 in_progress, or 202 queued (with any failed_cases).
• State is derived only from executor outcomes: isolated once the isolation filters are verified installed; needs attention if an outcome is ambiguous (the banner says the host may be isolated; Release stays enabled). The tray icon reflects the same state.
• No UAC prompt is shown. Anyone with a valid console session can isolate or release.

Protected targets and safety checks

The executor refuses, before any change:

Target	Refused when
Process	It is the FreeDR service process itself; it is a critical process; it is a protected (PPL) process; its creation time or image path changed since inspection; it already exited.
Service	It is the FreeDR service; it is launch-protected; it is a driver service.
File	Not on a local fixed drive; path changed identity, version, USN, streams or security since inspection; reparse points in the path; unsupported backup streams or metadata.
Persistence	The task, service, Run value or WMI objects changed since they were captured.
Network filters	Release/remove only touches filters whose GUIDs FreeDR owns; unrelated firewall rules are never reset. Loopback is never blocked.

Other execution properties:

• Steps run strictly in order; a step never runs if an earlier step is not verified.
• Before each effect the service commits the exact intended effect to the control database, then executes it, then commits the observed outcome. A failed or ambiguous commit stops further effects; nothing is blindly retried.
• After a crash or restart, jobs whose outcome cannot be confirmed become needs attention; destructive calls are not replayed.
• Quarantine vault: one AES-256-GCM encrypted object per file (Windows CNG), with a random key protected by SYSTEM DPAPI, stored under the protected machine directory with SYSTEM/Administrators-only ACLs. No plaintext copy is kept. Removal is reported honestly: remaining hard links, open handles or delete-pending state are listed as limitations, not hidden.
• Persistence backups (captured configuration) are kept DPAPI-sealed in the job record and are not shown in API responses or exports.

Job states: queued, running, succeeded, partial, failed, cancelled, needs_attention.

Audit trail

Every response event is written to the case audit (GET /api/v1/cases/{case_id}/audit, also shown in case activity) with the job ID, step number and timestamp. Recorded events include proposed, claimed, effect_intent, effect_outcome, cancel_requested, execution_stopped, case_changed, restart_ambiguous, investigation_interrupted, recovery_observed and recovered_by_job. The job record itself (GET .../response/{job_id}) keeps the immutable plan, per-step preflight facts, limitations and receipts.

Identity in the audit is limited to the console session reference for host isolation and the AI investigator (run <id>) purpose for AI-submitted jobs. There are no user accounts.

AI investigator and response

AI can run some containment actions

With the AI investigator enabled and the setting Let AI contain threats it finds (ai.response_enabled, off by default, in setup and in Settings) turned on, for a suspicious or malicious verdict the investigator submits its own job through the same response service.

• Actions the AI may run: terminate_processes, quarantine_file, remediate_persistence, block_traffic, citing retained alerts or events of the case.
• Never run by the AI: host isolation, permanent deletion, any restore or release, and targets cited only from enrichment. These stay in the report's draft for you.
• AI jobs have a purpose starting AI investigator (run ...) and are bound to the exact case revision: if you edit the case while the job waits or between steps, the job is cancelled (case_changed).
• The response service applies the same evidence binding, protections and audit to AI jobs; the AI cannot bypass them.
• With the switch off, the AI only produces a draft plan, which you can import into the Response tab (AI draft imported for your review. No actions have been submitted.) and submit yourself.

See Security for the authentication boundary and data sent to AI providers.