Response Engine

Status: Planned

The response engine is not yet implemented. This page describes the planned architecture for active threat response. Currently, ExfilGuardian operates as a passive detection system: it detects and alerts, but does not take automated blocking actions.

Planned Architecture

The response engine will extend the existing pipeline by subscribing to high-confidence alerts from the correlation module and issuing blocking actions through the kernel driver.

Planned Response Flow

When implemented, the response engine will follow this sequence:

Design Principles

Kernel-Level Blocking via WFP

Unlike the previous NFQUEUE-based design (which was Linux-only), the response engine will use the Windows Filtering Platform to add dynamic block rules directly in the kernel driver. This provides:

Kernel-speed enforcement: packets are dropped before reaching userspace
Platform-native: uses the same WFP infrastructure already used for capture
No additional dependencies: no need for a separate interception framework

The driver already registers WFP callouts for packet capture. Blocking will be implemented by adding WFP filter rules with FWP_ACTION_BLOCK for specific flow tuples (source IP, destination IP, port, protocol).

Graduated Playbooks

Responses will be proportional to the threat type and confidence level. Blocking an entire IP is too broad and causes collateral damage. Each playbook targets the minimal scope needed.

Threat Type	Confidence	Planned Action
DNS tunneling	> 0.85	Block DNS queries to the suspicious domain
TLS C2 beaconing	> 0.90	Block flow to the specific IP:port
ICMP covert channel	> 0.80	Block ICMP to the destination IP
Multi-module correlated	> 0.90	Block the full flow (IP + port + protocol)
Single-module, behavioral only	< 0.85	Alert only (score too uncertain for automated action)

Temporary Rules with TTL

All blocking rules will be temporary by design. A false positive that permanently blocks a legitimate server is worse than missing a threat.

Whitelist

Certain destinations will never be blocked, regardless of score:

response:
  mode: observe           # observe | block (planned)
  threshold: 0.9          # minimum correlation score to trigger a block
  block_ttl: 300          # seconds before automatic rule expiry
  auto_unblock: true      # remove rule if flow goes quiet
  whitelist:
    - 127.0.0.0/8         # loopback
    - 10.0.0.0/8          # RFC 1918
    - 172.16.0.0/12       # RFC 1918
    - 192.168.0.0/16      # RFC 1918

Implementation Requirements

Before the response engine can be built, the following prerequisites must be completed:

Driver IOCTL extension: add IOCTL_ADD_BLOCK_RULE and IOCTL_REMOVE_BLOCK_RULE to the driver's device I/O handler
WFP dynamic filter API: implement FwpmFilterAdd0 / FwpmFilterDeleteById0 calls in the driver for runtime rule management
Server-to-agent push channel: extend the gRPC service with a server-initiated stream or bidirectional stream for pushing block commands to the agent
Audit logging: every automated block action must be logged with full context (flow tuple, alert ID, score, playbook, TTL) for operator review
Kill switch: a mechanism to instantly clear all active block rules in case of widespread false positives

Audit Log Format (Planned)

Every blocking action will be recorded for post-incident review:

{
  "timestamp": 1737987000000,
  "action": "BLOCK",
  "flow": {
    "src_ip": "192.168.1.42",
    "dst_ip": "203.0.113.50",
    "dst_port": 443,
    "protocol": "TCP"
  },
  "alert_id": "alert-a1b2c3",
  "score": 0.94,
  "severity": "Critical",
  "playbook": "tls-c2-block",
  "ttl_seconds": 300,
  "modules": ["dpi/tls", "behavioral/beaconing"]
}

Response Engine

On this page