DutchOven

Brownout di rete Windows con ambito applicativo per una validazione red-team deterministica.

C nativo  •  Windows Filtering Platform  •  IPv4 + IPv6  •  Pulizia dinamica

Avvio rapido • Profili • CLI • Come funziona • Build • BOF • Validazione

[!CAUTION] Solo ambienti controllati. Esegui DutchOven esclusivamente su sistemi di tua proprietà o per i quali sei esplicitamente autorizzato a fare assessment. Modifica le policy di rete Windows attive e richiede un token di Administrator elevato. Leggi SECURITY.md prima dell'uso.

Cos'è DutchOven?

DutchOven è una primitiva red-team per Windows volutamente minima che pone percorsi eseguibili espliciti dietro un gate di rete deterministico. Durante ogni periodo, le applicazioni corrispondenti vengono bloccate per un intervallo limitato e lasciate passare per il resto del tempo.

Il risultato è un brownout ripetibile, non un arresto del servizio o una regola firewall permanente. Crea un modo controllato per misurare logiche di retry, buffering, transizioni di health-state, consegna ritardata e comportamento di recupero mentre il processo rimane attivo.

DutchOven controlla l'autorizzazione di nuove connessioni in uscita. Una connessione esistente già autorizzata da WFP non viene terminata retroattivamente; usa una connessione canary nuova o forza indipendentemente la riconnessione del target quando validi un flusso long-lived senza interruzioni.

Avvio rapido

Apri una finestra PowerShell elevata.

Valida il target risolto e la temporizzazione senza modificare WFP:

.\dutchoven.exe --app 'C:\Path\To\Target.exe' --dry-run

Esegui il profilo brownout predefinito:

.\dutchoven.exe --app 'C:\Path\To\Target.exe'

Questa è l'invocazione minima completa. --app è l'unico flag obbligatorio. Il profilo predefinito blocca il target per 1,5 secondi ogni 5 secondi ed esce dopo un minuto.

Usa Ctrl+C per fermarti prima. DutchOven rimuove i filtri attivi prima di chiudere la sessione WFP; la sessione dinamica è la rete di sicurezza per la pulizia se il processo viene interrotto.

Profili operativi

I profili incorporano programmi utili così gli operatori non devono specificare ogni valore di temporizzazione.

Seleziona un profilo con un flag opzionale:

.\dutchoven.exe --app 'C:\Path\To\Target.exe' --profile heavy

Riferimento CLI

dutchoven --app <absolute.exe> [--app <absolute.exe> ...] [options]

Stampa la versione della build con dutchoven version.

I flag di temporizzazione avanzati sostituiscono il profilo selezionato indipendentemente dall'ordine degli argomenti:

.\dutchoven.exe `
  --app 'C:\Path\To\Target.exe' `
  --period-ms 8000 `
  --block-ms 2000 `
  --duration-ms 120000 `
  --warmup-ms 5000

I JSON Lines sono pensati per gli harness di test e la raccolta di evidenze:

.\dutchoven.exe --app 'C:\Path\To\Target.exe' --profile heavy --json

I limiti di temporizzazione sono applicati dal parser:

• Periodo: 100–60000 ms
• Blocco: da 1 ms fino all'intero periodo
• Durata: almeno un periodo, al massimo 900000 ms (15 minuti)
• Warmup: al massimo 60000 ms
• Target: al massimo 16 percorsi eseguibili locali espliciti

Come funziona

explicit executable path
          │
          ▼
   WFP application ID
          │
          ├── ALE_AUTH_CONNECT_V4 ──┐
          └── ALE_AUTH_CONNECT_V6 ──┤── BLOCK / PASS schedule
                                    │
                                    └── dynamic WFP session cleanup

1. DutchOven risolve ogni eseguibile fornito in un'identità applicativa WFP.
2. Apre una sessione dinamica non persistente del motore WFP e crea un sottolivello generato.
3. All'inizio di un intervallo di blocco, i filtri IPv4 e IPv6 vengono aggiunti in una singola transazione.
4. All'inizio di un intervallo di passaggio, quei filtri vengono rimossi in una singola transazione.
5. Al completamento o all'interruzione normale, DutchOven rimuove eventuali filtri attivi e chiude il motore.

I target Windows vengono risolti come Unicode e canonicalizzati al loro percorso lungo prima che DutchOven chieda a WFP un'identità applicativa. Questo impedisce che un alias di percorso 8.3 come ADMINI~1 crei silenziosamente un filtro che non può corrispondere all'identità immagine in formato lungo del processo.

La console stampa le transizioni di stato con timestamp wall-clock e relativi al programma:

Targets: 1
  C:\Path\To\Target.exe
Schedule: block=1500ms pass=3500ms period=5000ms duration=60000ms warmup=0ms
Profile: brownout
Mode: brownout
BLOCK cycle=1 filters=2 wall_ms=1786973903811 elapsed_ms=0
PASS cycle=1 wall_ms=1786973908813 elapsed_ms=5000
...
CLEAN filters=0 session=closed cycles=12 wall_ms=1786973963812 elapsed_ms=60000

Build

La build Linux predefinita esercita il parsing e il comportamento dry-run. Il gate WFP live richiede la cross-build nativa per Windows.

make check
make release

make check esegue i test portabili, cross-compila gli artefatti Windows e verifica il contratto di import del BOF. make release produce artefatti release strippati e SHA256SUMS in artifacts/v<version>/.

Output principali:

L'eseguibile Windows si collega solo a librerie di sistema Windows: fwpuclnt, rpcrt4 e advapi32.

Beacon Object File

Il BOF confeziona DutchOven come un impulso sincrono breve che viene eseguito inline in un Beacon x64. Compila l'oggetto COFF, aggiorna l'artefatto versionato e verifica il suo contratto di import con:

make bof

Carica bof/dutchoven.cna nello Script Manager di Cobalt Strike, quindi invocalo da una console Beacon:

dutchoven "C:\Path\To\Target.exe"
dutchoven "C:\Path\To\Target.exe" heavy

Il profilo predefinito è brownout. I profili corrispondono a un singolo intervallo di blocco limitato:

Ogni invocazione apre una sessione WFP dinamica, installa atomicamente i filtri di connessione IPv4 e IPv6, attende l'impulso selezionato, rimuove esplicitamente entrambi i filtri e chiude la sessione prima di restituire il controllo. La chiusura della sessione dinamica rimane la rete di sicurezza per la pulizia se la rimozione esplicita fallisce.

Il BOF usa Dynamic Function Resolution per Kernel32, Rpcrt4 e Fwpuclnt; non ha import dalla C runtime. Accetta un percorso assoluto di un eseguibile esistente, richiede un Beacon elevato e rifiuta di mettere al gate il processo che ospita il BOF. Poiché viene eseguito inline, intenzionalmente non riproduce lo scheduler multi-ciclo di un minuto del binario standalone.

Workflow di validazione

Un risultato red-team utile richiede evidenze indipendenti. Non trattare una chiamata di aggiunta filtro riuscita come prova che il target abbia subito il brownout previsto.

1. Seleziona un'applicazione canary benigna il cui comportamento di rete sia osservabile.
2. Registra una baseline senza gate.
3. Esegui DutchOven in parallelo con un'applicazione di controllo non correlata.
4. Misura sia i nuovi tentativi di connessione sia una connessione già stabilita.
5. Cattura indipendentemente timestamp client, timestamp server e pacchetti.
6. Conferma che il controllo sia rimasto non influenzato e che ogni intervallo di passaggio si sia ripreso.
7. Conferma che non rimangano filtri DutchOven dopo l'uscita normale e la terminazione forzata.

Il repository include un harness di integrazione Windows che automatizza queste asserzioni con due copie di un canary TCP innocuo. Richiede una sessione PowerShell elevata e un listener TCP non locale raggiungibile; il traffico di loopback non è un sostituto valido per la validazione WFP instradata.

.\tests\windows_integration.ps1 `
  -DutchOvenPath '.\build-windows\dutchoven.exe' `
  -CanaryPath '.\build-windows\windows_canary.exe' `
  -ServerAddress '192.0.2.10' `
  -ServerPort 8443

L'harness dimostra la connettività baseline, il blocco mirato, un controllo non influenzato, il recupero normale, il recupero dopo terminazione forzata tramite la sessione dinamica e zero residui WFP.

Comportamento verificato

DutchOven 0.4.1 è stato validato su Windows Server 2022 con Elastic Defend 9.4.2:

• sei filtri live coprivano IPv4 e IPv6 per tre percorsi eseguibili Elastic espliciti;
• dopo aver forzato nuove connessioni, le connessioni backend mirate sono scese a zero mentre un controllo PowerShell non correlato raggiungeva ancora entrambe le porte backend;
• i servizi Elastic sono rimasti in esecuzione per tutto il blackout limitato;
• DutchOven è uscito correttamente e dump indipendenti dello stato WFP non hanno trovato filtri, sessioni o sottolivelli residui; e
• tutte le connessioni dell'agente e il Fleet health si sono ripresi.

Elastic ha registrato l'avvio del processo di DutchOven, la fine del processo, l'identità SYSTEM e la riga di comando completa, quindi ha consegnato la telemetria bufferizzata dopo il recupero. Non ha prodotto un alert di Elastic Defend in quella configurazione. Tratta questo come un singolo risultato misurato, non come un'affermazione universale di rilevamento o evasione.

Limiti operativi

DutchOven intenzionalmente non:

• enumera i prodotti di sicurezza installati;
• deduce percorsi eseguibili o proprietà dei processi;
• arresta, sospende o modifica servizi;
• installa un servizio, un driver, un meccanismo di persistenza o un filtro all'avvio;
• modifica i profili Windows Firewall, le Group Policy o lo stato del registro policy-QoS;
• impersona un protocollo di un agente commerciale; o
• rivendica risultati di telemetria lato vendor senza evidenze backend indipendenti.

Sono richiesti privilegi di amministratore perché l'aggiunta di oggetti WFP richiede accesso in scrittura al Base Filtering Engine. L'identità applicativa deve corrispondere all'eseguibile che possiede effettivamente il flusso di rete. Agenti multiprocesso, proxy, networking kernel e connessioni long-lived possono cambiare il risultato osservato e devono essere misurati, non assunti.

Mappa del repository