Reverse shells con PowerShell: útiles en lab, ruidosas en Windows real
PowerShell implica execution policy, AMSI, logs, quoting y telemetría de procesos muy visible en pruebas reverse shell.
PowerShell es cómodo para pruebas Windows en laboratorio. Está disponible en muchos sistemas, es expresivo y permite trabajar con red, procesos y encoding sin demasiada fricción. Esa misma comodidad explica por qué los defensores lo miran tanto.
Si tu prueba reverse shell depende de PowerShell, asume que hará ruido.
Execution policy no es la frontera real
Execution policy bloquea algunos caminos de ejecución de scripts, pero no es un modelo fuerte de seguridad. En laboratorios se habla demasiado de flags de bypass, como si fueran lo importante. Lo importante es si los controles detectan comportamiento sospechoso: comandos codificados, ventanas ocultas, sockets salientes, procesos hijos y parents extraños.
Los entornos reales pueden añadir Constrained Language Mode, AppLocker, WDAC, AMSI, Script Block Logging, transcripción y hooks de EDR. Un generador no debería presentar PowerShell como ruta garantizada.
El quoting en Windows castiga
PowerShell tiene sus propias reglas. cmd.exe añade otra capa si lo usas como wrapper. Las herramientas remotas vuelven a escapar caracteres. Una orden puede funcionar por un camino y romperse por otro.
Valida primero:
$PSVersionTable.PSVersion
whoami
Test-NetConnection 10.10.14.3 -Port 4444
Test-NetConnection ahorra tiempo. Si no llega al listener, cambiar de payload no arregla nada.
Los logs son parte del ejercicio
En trabajo autorizado, la telemetría PowerShell no es un estorbo. Es evidencia. Script Block Logging, Module Logging, Event ID 4688, Sysmon, DNS y eventos de red muestran partes distintas de la acción.
La pregunta red team es si el camino funciona. La pregunta blue team es si se vio lo suficiente para entenderlo. Un buen laboratorio contesta ambas.
Legible antes que ofuscado
La ofuscación tiene sentido en ingeniería de detección madura, pero no como ejemplo por defecto. Para validar un flujo o un control, empieza con comandos legibles. Haz obvio el comportamiento. Añade variaciones solo si el objetivo de detección lo requiere.
Los comandos legibles producen mejores informes y reducen errores del propio tester.