Al momento, l'uso offensivo di Powershell è uno degli argomenti più scottanti in infosec. Gli script di PowerShell sono spesso proposti come appropriati per la fase di "post-sfruttamento" di una penetrazione. Questa domanda segue in qualche modo questa linea, tranne che implica un passo avanti verso l'uso di Powershell un po 'prima del solito: quando il punto di appoggio solo che hai ottenuto finora è stato ottenere un'applicazione per eseguire shellcode di la tua scelta (Chiamalo "molto presto post-sfruttamento" se vuoi.) Quindi:
Diciamo che ci si trova in una situazione in cui si è acquisita la capacità di eseguire shellcode assembly (senza limiti di dimensioni o restrizioni di caratteri) all'interno di un determinato processo su una macchina Windows. Desiderate sfruttare questa capacità per non eseguire direttamente molti codici di basso livello, ma per fare qualcosa di diverso: per creare un ambiente di esecuzione all'interno di quel processo in cui puoi eseguire il codice PowerShell.
Il ragionamento alla base di questa scelta è piuttosto semplice: la creazione di un ambiente di esecuzione Powershell consente di sfruttare tutti gli strumenti, le tattiche e le procedure sempre più potenti che utilizzano Powershell che la comunità di sicurezza ha prodotto / sta producendo. E l'impostazione di quell'ambiente entro un processo già in esecuzione consente di evitare l'avvio di un nuovo processo per l'esecuzione del codice PowerShell (e soprattutto di evitare l'avvio di powershell.exe, cmd.exe o wscript.exe) come la maggior parte dei tester di penna di bassa abilità e cattivi lo fanno spesso, cosa che può essere molto, molto sospettosa per un difensore che sta monitorando registri di eventi o sta usando un software HIDS / HIPS ben configurato. L'obiettivo generale è quello di replicare alcune delle funzionalità e la furtività di alcuni utenti malintenzionati di fascia più alta senza dover utilizzare molta programmazione personalizzata nei linguaggi di programmazione di basso livello, sfruttando invece l'universo di script / strumenti Powershell già esistenti.
So che il concetto generale di ciò che mi interessa fare qui funziona, perché sono stato in grado di dimostrarlo, usando (per esempio) Metasploit - in particolare con un dllinject payload che inizia dallo shellcode generato da msfvenom-- insieme a una dll riflettente (da Empire , ad es.) per far sì che un agente di PowerShell sia correttamente attivo e in esecuzione senza creare un nuovo processo in una serie di situazioni di test. Ma, ad essere sinceri, sono un po 'scettico sull'idea di usare qualsiasi cosa che si basa su payload o comunicazioni Metasploit per qualcosa che alla fine (si spera) possa essere usato durante un effettivo impegno contro un difensore con HIDS, HIPS, NIDS, ecc. .
Esistono strumenti / metodi alternativi che potrebbero essere più silenziosi durante lo stesso risultato: ottenere il codice Powershell in esecuzione su una destinazione in cui è già in esecuzione codice e senza creare un nuovo processo che potrebbe essere facilmente rilevato? Sono aperto a considerare praticamente tutto ciò che non richiede la scrittura di un sacco di codice personalizzato in assembly. (Anche se, ovviamente, è più semplice implementarlo sempre.)