AIR Responder Kernel Drivers on Windows
Overview
Section titled “Overview”The AIR Responder runs as a user-mode service and does not keep a kernel driver loaded between tasks. On Windows, a small number of task types load a kernel driver only while they need it and remove it when the task ends.
This page explains which tasks load a driver, what each driver does, and how to verify that a driver is present only for the duration of its task. It is intended for change management, SIEM, and EDR teams.
Why drivers are loaded per task
Section titled “Why drivers are loaded per task”AIR is an on-demand incident response and forensics platform, not an always-on monitoring agent. Loading kernel components only when a task needs them:
- Avoids the overhead, stability risk, and attack surface of a permanently loaded driver
- Limits any interaction with other kernel-level security products to the duration of the task
- Keeps changes on the investigated system to a minimum, which supports evidence integrity
Drivers by task type
Section titled “Drivers by task type”| Task | Driver file | Service name | Loaded by | Removed |
|---|---|---|---|---|
| Acquisition, when an evidence type needs low-level access (for example locked files, raw disk, or memory) | TACTICAL.sys | TACTICAL | TACTICAL-Legacy.exe | At the end of the task, during cleanup |
| Acquisition with Network Capture (PCAP or Network Flow) | irecnf.sys | irecnf | TACTICAL-Legacy.exe | When the capture ends |
| Asset Isolation | irecnf.sys | irecnf | TACTICAL-Legacy.exe | When the asset is un-isolated |
Driver files are written to %SystemRoot%\System32\drivers and registered as kernel driver services with the demand start (manual) start type. Windows does not load them automatically at boot. When a task ends, the Responder stops the driver, deletes the service, and deletes the driver file. Loading or removing a driver does not require a restart.
Asset Isolation is the only case where the driver stays loaded beyond a single task: it remains loaded while the asset is isolated. Because isolation persists across reboots, the Responder re-applies isolation when it starts after a restart, which loads the driver again. For details, see Asset Isolation.
Evidence collection driver
Section titled “Evidence collection driver”TACTICAL.sys gives the evidence collection engine read access to data that Windows does not expose to normal processes, such as files locked by the operating system, raw disk sectors, and memory and process information. It does not interact with network traffic.
Network driver
Section titled “Network driver”irecnf.sys is a Windows Filtering Platform (WFP) callout driver. It is used for Network Capture and Asset Isolation.
During a network capture, the driver registers with WFP at the IP packet layer. It lets each packet continue immediately and passes a copy to the capture process, which writes it to the PCAP or Network Flow file. Network traffic does not wait for the capture process. If the capture process slows down or the disk is busy, some copies may be missing from the capture file, but the host’s network traffic is not affected.
The filtering rules are tied to the capture process. If the process ends for any reason, Windows removes the rules immediately.
Because it is a WFP callout driver and not an NDIS filter driver, it is not bound to network adapters. Loading or removing it does not restart network adapters or require a reboot, and it does not appear in network adapter bindings.
What you may see in monitoring tools
Section titled “What you may see in monitoring tools”When a task loads a driver, you may see the following. Each event lines up with the start and end of the corresponding AIR task.
- Windows System event log: Service Control Manager Event ID 7045 (“A service was installed in the system”) with service type kernel mode driver
- EDR or system monitoring tools: Driver load events from
%SystemRoot%\System32\drivers - WFP state: Callouts and sub-layers owned by the network driver while a network capture or isolation is active
If your change-management process tracks kernel driver installations, register the drivers on this page as expected AIR task activity. If your security product blocks or alerts on driver loads, see Responder Exception Rules for EPP and EDR.
Verify that a driver is present only during the task
Section titled “Verify that a driver is present only during the task”Run the following commands as administrator while a network capture task is running and again after it has finished:
| Command | What it shows | During the task | After the task |
|---|---|---|---|
sc qc irecnf | Service type and start type | KERNEL_DRIVER, DEMAND_START | Error 1060 (the service does not exist) |
sc query irecnf | Driver state | RUNNING | Error 1060 |
driverquery /v | Loaded kernel drivers | irecnf is listed | irecnf is not listed |
netsh wfp show state | WFP callouts and sub-layers (written to wfpstate.xml) | Entries for irecnf | No irecnf entries |
Get-NetAdapterBinding -AllBindings | NDIS filters bound to network adapters | irecnf is not listed | irecnf is not listed |
For acquisition tasks that use TACTICAL.sys, use the same commands with the TACTICAL service name. While an asset is isolated, irecnf remains RUNNING until the asset is un-isolated.