DutchOven gates new outbound connection authorization. An existing connection that WFP has already authorized is not retroactively terminated; use a fresh canary connection or independently force the target to reconnect when validating an uninterrupted long-lived flow.

Quick start

Open an elevated PowerShell window.

Validate the resolved target and timing without changing WFP:

Run the default brownout profile:

That is the complete minimum invocation. --app is the only required flag. The default profile blocks the target for 1.5 seconds in every 5-second period and exits after one minute.

Use Ctrl+C to stop early. DutchOven removes active filters before closing its WFP session; the dynamic session is the cleanup backstop if the process is interrupted.

Operation profiles

Profiles bake in useful schedules so operators do not need to specify every timing value.

Select a profile with one optional flag:

CLI reference

Print the build version with dutchoven version.

Advanced timing flags override the selected profile regardless of argument order:

JSON Lines are intended for test harnesses and evidence collection:

Timing limits are enforced by the parser:

• Period: 100–60000 ms
• Block: 1 ms through the complete period
• Duration: at least one period, at most 900000 ms (15 minutes)
• Warmup: at most 60000 ms
• Targets: at most 16 explicit local executable paths

How it works

1. DutchOven resolves each supplied executable into a WFP application identity.
2. It opens a non-persistent, dynamic WFP engine session and creates a generated sublayer.
3. At the beginning of a block interval, IPv4 and IPv6 filters are added in one transaction.
4. At the beginning of a pass interval, those filters are removed in one transaction.
5. At completion or normal interruption, DutchOven removes any active filters and closes the engine.

Windows targets are resolved as Unicode and canonicalized to their long path before DutchOven asks WFP for an application identity. This prevents an 8.3 path alias such as ADMINI~1 from silently creating a filter that cannot match the process's long-form image identity.

The console prints state transitions with wall-clock and schedule-relative timestamps:

Build

The default Linux build exercises parsing and dry-run behavior. The live WFP gate requires the native Windows cross-build.

make check runs the portable tests, cross-builds the Windows artifacts, and verifies the BOF import contract. make release produces stripped release artifacts and SHA256SUMS under artifacts/v<version>/.

Primary outputs:

The Windows executable links only against Windows system libraries: fwpuclnt, rpcrt4, and advapi32.

Beacon Object File

The BOF packages DutchOven as a short, synchronous pulse that runs inline in an x64 Beacon. Build the COFF object, refresh the versioned artifact, and verify its import contract with:

Load bof/dutchoven.cna in Cobalt Strike's Script Manager, then invoke it from a Beacon console:

The default profile is brownout. Profiles map to a single bounded block interval:

Each invocation opens a dynamic WFP session, atomically installs IPv4 and IPv6 connect filters, waits for the selected pulse, explicitly removes both filters, and closes the session before returning. Closing the dynamic session remains the cleanup backstop if explicit removal fails.

The BOF uses Dynamic Function Resolution for Kernel32, Rpcrt4, and Fwpuclnt; it has no C runtime imports. It accepts one existing absolute executable path, requires an elevated Beacon, and refuses to gate the process hosting the BOF. Because it executes inline, it intentionally does not reproduce the standalone binary's one-minute multi-cycle scheduler.

Validation workflow

A useful red-team result needs independent evidence. Do not treat a successful filter-add call as proof that the target experienced the intended brownout.

1. Select a benign canary application whose network behavior is observable.
2. Record an ungated baseline.
3. Run DutchOven with an unrelated control application in parallel.
4. Measure both new connection attempts and an already-established connection.
5. Capture client timestamps, server timestamps, and packets independently.
6. Confirm the control remained unaffected and every pass interval recovered.
7. Confirm no DutchOven filters remain after normal exit and forced termination.

The repository includes a Windows integration harness that automates those assertions with two copies of a harmless TCP canary. It requires an elevated PowerShell session and a reachable non-local TCP listener; loopback traffic is not a valid substitute for routed WFP validation.

The harness proves baseline connectivity, targeted blocking, an unaffected control, normal recovery, forced-termination recovery through the dynamic session, and zero WFP residue.

Verified behavior

DutchOven 0.4.1 was validated on Windows Server 2022 with Elastic Defend 9.4.2:

• six live filters covered IPv4 and IPv6 for three explicit Elastic executable paths;
• after forcing fresh connections, targeted backend connections fell to zero while an unrelated PowerShell control still reached both backend ports;
• the Elastic services remained running throughout the bounded blackout;
• DutchOven exited successfully and independent WFP state dumps found no residual filter, session, or sublayer; and
• all agent connections and Fleet health recovered.

Elastic recorded DutchOven's process start, process end, SYSTEM identity, and complete command line, then delivered buffered telemetry after recovery. It did not produce an Elastic Defend alert in that configuration. Treat this as one measured result, not a universal detection or evasion claim.

Operational boundaries

DutchOven intentionally does not:

• enumerate installed security products;
• infer executable paths or process ownership;
• stop, suspend, or modify services;
• install a service, driver, persistence mechanism, or boot-time filter;
• change Windows Firewall profiles, Group Policy, or policy-QoS registry state;
• impersonate a commercial agent protocol; or
• claim vendor-side telemetry results without independent backend evidence.

Administrator rights are required because adding WFP objects requires write access to the Base Filtering Engine. Application identity must match the executable that actually owns the network flow. Multiprocess agents, proxies, kernel networking, and long-lived connections can change the observed result and must be measured rather than assumed.

Repository map