BOF di DSCourier

Questa è un'implementazione BOF del progetto DSCourier di Dylan Davis e Matthew Schramm. Utilizza l'interfaccia COM di WinGet per eseguire codice powershell arbitrario in un processo firmato e fidato da Microsoft. Il loro blog di ricerca completo può essere trovato qui.

A differenza della maggior parte dei progetti che rilascio, questo NON è uno strumento operativamente pronto ma piuttosto una POC. Ho scelto di non proseguire ulteriormente dopo aver scoperto una serie di problemi che impediscono che questo sia un BOF facilmente distribuibile. Il codice è stato quasi interamente generato da Claude. Diversi problemi rimangono irrisolti e sono discussi qui sotto

Utilizzo

Inserisci il tuo codice powershell arbitrario nel file dist/rev.yml. Per impostazione predefinita contiene una semplice reverse shell powershell dal repository originale. Se scegli di usarla, assicurati di sostituire l'IP nell'esempio esistente con il tuo IP desiderato.

Esempio utilizzando la reverse shell powershell:

Come Funziona / Limitazioni

In nessun ordine particolare, ecco alcuni problemi/limitazioni di questo strumento.

1. Affinché le chiamate COM abbiano successo, il file Microsoft.Management.Configuration.winmd deve essere presente nella stessa directory dell'eseguibile che effettua le chiamate COM. Questo pone un problema immediato quando si esegue un Beacon da un processo system32 svuotato, ad esempio, dove gli utenti normali non hanno permessi di scrittura. Per aggirare questo problema, il file viene invece rilasciato in %APPDATA%\temp e la funzione WinTypes!RoGetMetaDataFile che recupera il percorso del file winmd viene hookata con un hook inline in modo da poter fornire la posizione del percorso temporaneo. Ciò consente di leggere il file winmd / far riuscire le chiamate COM, ma comporta chiamate VirtualProtect e sovrascrittura della memoria DLL che creano IOC.
2. Seguendo il punto #1, il file winmd viene bloccato su disco dopo l'esecuzione del BOF fino all'uscita del processo Beacon. Ho giocato un po' con questo per cercare di risolvere, inclusa l'aggiunta della funzionalità di auto-eliminazione che è ben nota a questo punto, ma il file è rimasto bloccato su disco. Potrebbe essere possibile aggirare/risolvere questo problema, ma è qualcosa che qualcun altro dovrà perseguire.
3. Come menzionato nella ricerca originale, poiché questo utilizza la risorsa pwsh all'interno di WinGet, un processo conhost.exe viene generato sotto ConfigurationRemotingServer.exe. Claude ha suggerito che sarebbe possibile caricare un modulo binario personalizzato come risorsa invece di invocare pwsh, il che dovrebbe risolvere il problema di conhost, ma ciò richiede il rilascio di file aggiuntivi su disco e non sono riuscito a farlo funzionare. Potrebbe non essere possibile. Se lo fosse, aprirebbe la porta al rilascio di una DLL .NET generica su disco che potrebbe essere caricata da ConfigurationRemotingServer.exe ed eseguire shellcode/parametri/ecc. passati.
4. Questo BOF implementa le versioni Async delle interfacce COM richieste. L'utilizzo delle versioni Sync comporta il blocco del Beacon / l'impossibilità di comunicare fino al termine del processo ConfigurationRemotingServer.exe; con l'esempio della semplice reverse shell, ciò significherebbe che Beacon non effettuerebbe il check-in finché la shell non viene terminata. Passare alle interfacce Async previene questo problema, ma introduce alcuni problemi di temporizzazione. C'è un sleep hardcoded di 3 secondi che ha funzionato nella pratica per ritardare tra chiamate specifiche, ma ovviamente non è il modo corretto per implementarlo.
5. Le definizioni delle interfacce COM sono state ottenute scaricando il .msixbundle di winget-cli da Github, estraendo, estraendo il .msix e trovando il file .winmd. È stato quindi utilizzato winmdidl.exe per estrarre i file IDL. midlrt.exe è stato poi usato per convertire l'IDL in file header/.c, che sono stati poi analizzati da Claude per contenere solo le definizioni necessarie. È ancora un pasticcio di codice. Questo link Microsoft probabilmente aiuterà a comprendere meglio questo processo.

Compilazione

Questo strumento è stato scritto senza l'uso delle normali dichiarazioni API BOF (ad es. un file bofdefs.h). Come descritto in questo post del blog di Matt Ehrnschwender, è possibile utilizzare objcopy per patchare i simboli appropriati nel formato DLL$API nel BOF dopo la compilazione.

Ho scritto uno strumento chiamato BOFPatcher che automatizza questo processo. Ciò consente agli utenti di scrivere BOF come normale C senza preoccuparsi di dichiarazioni API macchinose:

Questo strumento è disponibile per coloro che acquistano il mio corso BOF Development and Tradecraft.

Mentre lo strumento BOFPatcher non è incluso in questo repository, il Makefile per questo strumento richiama objcopy, passando un file imports_dscourier64.txt contenente le sostituzioni di simboli appropriate che rendono quindi il BOF utilizzabile.

Crediti

1. Ottimo lavoro da Dylan e Matt. Spero di vedere altro da loro!
2. Claude per aver generato (clankato) la maggior parte di questo codice.