Reverse shells PowerShell : pratiques en lab, bruyants en environnement Windows réel
Tester des reverse shells PowerShell implique execution policy, AMSI, logs, quoting et télémétrie processus très visible.
PowerShell est pratique pour tester Windows en lab. Il est souvent présent, expressif, et assez confortable pour manipuler réseau, processus et encodage. Cette praticité explique aussi pourquoi les équipes défense le surveillent de près.
Si votre test reverse shell dépend de PowerShell, partez du principe qu'il sera visible.
L'execution policy n'est pas la vraie frontière
L'execution policy bloque certains chemins de lancement de scripts, mais ce n'est pas un modèle de confinement fort. En lab, on voit trop souvent les flags de bypass traités comme le coeur du sujet. Ce n'est pas le sujet. La vraie question est : les contrôles détectent-ils le comportement PowerShell suspect ?
Commandes encodées, fenêtres cachées, sockets sortants, création de processus enfants, parent process inhabituel, tout cela compte plus que le simple statut de l'execution policy.
Les environnements réels ajoutent Constrained Language Mode, AppLocker, WDAC, AMSI, Script Block Logging, transcription PowerShell et hooks EDR. Un générateur doit rappeler ces contraintes au lieu de présenter PowerShell comme un chemin garanti.
Le quoting Windows est une punition
PowerShell a ses règles. cmd.exe en ajoute d'autres si vous passez par lui. Les outils d'exécution distante ajoutent encore leur couche d'échappement. Une commande peut survivre dans un contexte et casser dans le suivant.
Commencez par valider les bases :
$PSVersionTable.PSVersion
whoami
Test-NetConnection 10.10.14.3 -Port 4444
Test-NetConnection est sous-estimé. S'il ne rejoint pas le listener, changer de payload est du théâtre.
Les logs font partie du test
Dans un cadre autorisé, la télémétrie PowerShell n'est pas un obstacle. C'est une preuve. Script Block Logging, Module Logging, Event ID 4688, Sysmon, DNS et événements réseau montrent chacun un morceau du comportement.
La question red team est : le chemin fonctionne-t-il ? La question blue team est : avons-nous vu assez pour comprendre ? Un bon exercice répond aux deux.
Préférer la lisibilité avant l'obfuscation
L'obfuscation a sa place dans l'ingénierie de détection avancée. Elle ne devrait pas être le réflexe par défaut d'un exemple de blog. Pour valider un workflow ou un contrôle client, commencez par des commandes lisibles. Rendez le comportement évident. Ajoutez ensuite des variations contrôlées si l'objectif de détection le demande.
Les commandes lisibles produisent de meilleurs rapports et moins de malentendus.