search
Page cover

🏛️Recopilación de Información Interna

Hemos cubierto mucho terreno hasta ahora:

  • Realizamos recopilación de información externa

  • Se realizó un escaneo de puertos y servicios externos

  • Se enumeraron varios servicios en busca de configuraciones incorrectas y vulnerabilidades conocidas.

  • Se enumeraron y atacaron 12 aplicaciones web diferentes; algunas no permitieron el acceso, otras permitieron la lectura de archivos o el acceso a datos confidenciales, y unas pocas provocaron la ejecución remota de código en el servidor web subyacente.

  • Conseguimos un punto de apoyo en la red interna con mucho esfuerzo.

  • Realizamos looting y movimientos laterales para obtener acceso como un usuario más privilegiado.

  • Aumentamos privilegios para ser root en el servidor web.

  • Se estableció persistencia mediante el uso de un par de usuario/contraseña y la clave privada id_rsa de la cuenta root para un acceso SSH rápido al entorno.

hashtag
Configuración de Pivoting - SSH

Con una copia del archivo id_rsa (clave privada), podemos usar el Port Forwarding SSH junto con ProxyChainsarrow-up-right para obtener una visión general de la red interna. Para revisar esta técnica, consulte la sección "Reenvío dinámico de puertos con SSH y túnel SOCKS".

Podemos usar el siguiente comando para configurar nuestro pivoting SSH mediante Port Forwarding dinámico:

ssh -D 8081 -i dmz01_key root@10.129.x.x

Esto significa que podemos redirigir el tráfico desde nuestro host de ataque a través del puerto 8081 en el objetivo para llegar a los hosts dentro de la subred 172.16.8.0/23 directamente desde nuestro host de ataque.

En nuestra primera terminal, configuremos primero el comando de Port Forwarding dinámico con SSH:

afsh4ck@kali$ ssh -D 8081 -i dmz01_key root@10.129.203.111

Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-113-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Wed 22 Jun 2022 12:08:31 AM UTC

  System load:                      0.21
  Usage of /:                       99.9% of 13.72GB
  Memory usage:                     65%
  Swap usage:                       0%
  Processes:                        458
  Users logged in:                  2
  IPv4 address for br-65c448355ed2: 172.18.0.1
  IPv4 address for docker0:         172.17.0.1
  IPv4 address for ens160:          10.129.203.111
  IPv6 address for ens160:          dead:beef::250:56ff:feb9:d30d
  IPv4 address for ens192:          172.16.8.120

  => / is using 99.9% of 13.72GB

 * Super-optimized for small spaces - read how we shrank the memory
   footprint of MicroK8s to make it the smallest full K8s around.

   https://ubuntu.com/blog/microk8s-memory-optimisation

97 updates can be applied immediately.
30 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable


You have mail.
Last login: Tue Jun 21 19:53:01 2022 from 10.10.14.15
root@dmz01:~#

Podemos confirmar que el Port Forwarding dinámico está configurado usando Netstat o ejecutando un escaneo Nmap contra nuestra dirección de localhost.

A continuación, debemos modificar el archivo /etc/proxychains.conf para utilizar el puerto que especificamos con nuestro comando de reenvío de puerto dinámico (8081 aquí).

A continuación, podemos usar Nmap con Proxychains para escanear el host dmz01 en su segunda NIC, con la dirección IP 172.16.8.120 para asegurarnos de que todo esté configurado correctamente.

hashtag
Configuración de Pivoting - Metasploit

Como alternativa, podemos configurar nuestro pivoting con Metasploit, como se explica en la sección "Meterpreter Tunnelling & Port Forwarding". Para ello, podemos hacer lo siguiente:

Primero, genera un reverse shell en formato Elf (ejecutable en linux) usando msfvenom:

A continuación, transfiere el binario al destino. Como tenemos SSH, podemos subirlo al destino mediante SCP.

Ahora, configuraremos en Metasploit un listener multi/handler.

Ejecutamos el archivo shell.elf en el sistema de destino:

Si todo va según lo previsto, capturaremos el shell de Meterpreter mediante el multi/handler y luego podremos configurar las rutas.

A continuación, podemos configurar el enrutamiento utilizando el módulo post/multi/manage/autoroute.

Para refrescar la memoria, consulte la sección MSFvenom y la sección Metasploit.

hashtag
Host Discovery - Metasploit

Una vez configuradas ambas opciones, podemos empezar a buscar hosts activos. Usando nuestra sesión de Meterpreter, podemos usar el módulo multi/gather/ping_sweep para realizar un barrido de ping de la subred 172.16.8.0/23.

hashtag
Host Discovery - Ping Sweep con bucle for

Como alternativa, podríamos hacer un Ping Sweep o utilizar un binario Nmap estáticoarrow-up-right desde el host dmz01.

Obtenemos resultados rápidos con este barrido de ping one-liner de Bash:

También podríamos usar Nmap a través de Proxychains para enumerar los hosts en la subred 172.16.8.0/23, pero sería muy lento y tardaría mucho tiempo en finalizar.

Nuestro host discovery produce tres hosts adicionales, ya que la dmz01 tiene la ip 172.16.8.120:

  • 172.16.8.3

  • 172.16.8.20

  • 172.16.8.50

Ahora podemos profundizar en cada uno de estos hosts y ver qué descubrimos. Los guardamos en un archivo live_hosts para pasárselo a otras herramientas como nmap.

hashtag
Enumeración de hosts

Continuemos nuestra enumeración usando un binario estático de Nmaparrow-up-right en el host dmz01. Intenta cargar el binario usando una de las técnicas enseñadas en el módulo File Transfers. Vemos una más abajo en el caso práctico.

De la salida de Nmap, podemos obtener lo siguiente:

  • 172.16.8.3 es un controlador de dominio porque vemos puertos abiertos como Kerberos y LDAP. Probablemente podamos dejar esto de lado por ahora, ya que es improbable que sea directamente explotable (aunque podemos retomarlo más adelante).

  • 172.16.8.20 es un host de Windows y los puertos 80/HTTP y 2049/NFS son particularmente interesantes

  • 172.16.8.50 también es un host de Windows, y el puerto 8080 se destaca por no ser estándar y ser interesante.

Podríamos ejecutar un escaneo completo del puerto TCP en segundo plano mientras investigamos algunos de estos hosts.

hashtag
Guía rápida de Active Directory

hashtag
SMB Null Session

Podemos comprobar rápidamente si el controlador de dominio tiene sesiones SMB nulas. Si podemos obtener la política de contraseñas y una lista de usuarios, podríamos intentar un ataque de Password Spraying medido. Si conocemos la política de contraseñas, podemos programar nuestros ataques adecuadamente para evitar el bloqueo de cuentas. Si no encontramos nada más, podríamos volver atrás y usar Kerbrute con una lista de nombres de usuario válidos, tras enumerar (durante una prueba de penetración real), los nombres de usuario potenciales de la página de LinkedIn de la empresa. Con esta lista, podríamos intentar uno o dos ataques de Password Spraying con la esperanza de obtener un resultado. Si esto sigue sin funcionar, dependiendo del cliente y el tipo de evaluación, podríamos solicitarles la política de contraseñas para evitar el bloqueo de cuentas.

También podríamos intentar un ataque ASREPRoasting si tenemos nombres de usuario válidos, como se explica en el módulo "Malas configuraciones en AD" en la sección ASREP Roasting.

Desafortunadamente para nosotros esto es un callejón sin salida.

hashtag
172.16.8.50 - Tomcat

Nuestro escaneo anterior de Nmap mostró el puerto 8080 abierto en este host. Al navegar, http://172.16.8.50:8080 se muestra la última versión de Tomcat 10 instalada. Aunque no existen exploits públicos para ello, podemos intentar forzar el inicio de sesión del administrador de Tomcat, como se muestra en la sección "Ataques a Tomcat".

Podemos iniciar otra instancia de Metasploit usando Proxychains escribiendo proxychains msfconsole para poder pivotar a través del host dmz01 comprometido, si no tenemos configurado el enrutamiento mediante una sesión de Meterpreter. Luego, podemos usar el módulo auxiliary/scanner/http/tomcat_mgr_login para intentar forzar el inicio de sesión.

No logramos iniciar sesión correctamente, por lo que esto parece ser un callejón sin salida y no vale la pena explorarlo más. Si encontráramos una página de inicio de sesión de Tomcat Manager expuesta a internet, probablemente querríamos registrarla como un hallazgo, ya que un atacante podría usarla para obtener acceso por fuerza bruta. Durante una operación interna, solo querríamos reportarla si logramos acceder con credenciales débiles y subir un webshell JSP. De lo contrario, es normal verla en una red interna si está bien protegida.

hashtag
Enumeración de 172.16.8.20 - DotNetNuke (DNN)

En el análisis de Nmap, vimos puertos 80 y 2049 abiertos. Analicemos cada uno de ellos. Podemos comprobar qué hay en el puerto 80 con cURL desde nuestro host de ataque con el comando proxychains curl http://172.16.8.20. Según la respuesta HTTP, parece que DotNetNuke (DNN)arrow-up-right se está ejecutando en el objetivo.

Este es un CMS escrito en .NET, básicamente el WordPress de .NET. Ha sufrido algunas fallas críticas a lo largo de los años y también cuenta con algunas funciones integradas que podríamos aprovechar. Podemos confirmarlo navegando directamente al objetivo desde nuestro host de ataque, pasando el tráfico a través del proxy SOCKS.

Podemos configurar esto en Firefox de la siguiente manera en Network Settings:

Navegando por la página se confirman nuestras sospechas.

texto

Al navegar a http://172.16.8.20/Login?returnurl=%2fadmin se muestra la página de inicio de sesión del administrador. También hay una página para registrar un usuario. Intentamos registrar una cuenta, pero recibimos el siguiente mensaje:

En mi experiencia, es muy poco probable que cualquier tipo de administrador de sitio apruebe un registro extraño, aunque vale la pena intentar cubrir todas nuestras bases.

Dejando de lado el DNN, por ahora, volvamos a los resultados del escaneo de puertos. El puerto 2049, NFS, siempre es interesante. Si el servidor NFS está mal configurado (lo cual suele ocurrir internamente), podemos explorar los recursos compartidos NFS y potencialmente descubrir información confidencial. Dado que se trata de un servidor de desarrollo (debido a la instalación del DNN en curso y al nombre de host DEV01), vale la pena investigarlo. Podemos usar "showmount"arrow-up-right para listar las exportaciones, que podríamos montar y explorar de forma similar a cualquier otro recurso compartido de archivos. Encontramos una exportación, DEV01, accesible para todos (acceso anónimo). Veamos qué contiene.

No podemos montar el recurso compartido NFS mediante Proxychains, pero por suerte tenemos acceso root al host dmz01 para intentarlo. Vemos algunos archivos relacionados con DNN y un subdirectorio DNN.

El subdirectorio DNN es muy interesante, ya que contiene un archivo web.config. Gracias a nuestras conversaciones sobre el pillaging, sabemos que los archivos de configuración suelen contener credenciales, lo que los convierte en un objetivo clave durante cualquier evaluación.

Al verificar el contenido del archivo web.config, encontramos lo que parece ser la contraseña de administrador para la instancia DNN.

Antes de continuar, dado que tenemos acceso root dmz01 por SSH, podemos ejecutar tcpdump tal y como está en el sistema. Nunca está de más escuchar en la red siempre que sea posible durante una prueba de penetración para ver si podemos obtener credenciales en texto plano o, en general, descubrir información adicional que pueda sernos útil. Normalmente lo hacemos durante una prueba de penetración interna, cuando tenemos nuestro propio portátil físico o una máquina virtual que controlamos dentro de la red del cliente. Algunos pentesters ejecutan una captura de paquetes constantemente (en raras ocasiones, los clientes incluso la solicitan), mientras que otros la ejecutan periódicamente durante el primer día aproximadamente para ver si pueden capturar algo.

Ahora podríamos transferir esto a nuestro host y abrirlo con Wireshark para ver si pudimos capturar algo. Esto se explica brevemente en la sección "Interacción con usuarios" del módulo Escalada de privilegios en Windows.

Tras transferir el archivo a nuestro host, lo abrimos en Wireshark, pero observamos que no se capturó nada. Si estuviéramos en una VLAN de usuario u otra zona concurrida de la red, podríamos tener que analizar una cantidad considerable de datos, así que siempre vale la pena intentarlo.

hashtag
Hacia delante

En este punto, hemos investigado los demás hosts activos a los que podemos acceder e intentado rastrear el tráfico de red. Podríamos ejecutar un escaneo completo de puertos de estos hosts también, pero tenemos mucho que hacer por ahora. Veamos qué podemos hacer con las credenciales DNN que obtuvimos del archivo web.config extraído del recurso compartido NFS abierto.

hashtag
Caso práctico

Monta un recurso compartido NFS y busque el archivo flag.txt. Envíe el contenido como respuesta.

hashtag
Port Forwarding con ID RSA

Tenemos que editar el archivo de proxychains para añadir un puerto en localhost:

hashtag
Confirmar Port Forwarding dinámico

hashtag
Localizar la red interna

Con un ifconfig conseguimos la ip interna 172.16.8.120.

hashtag
Ping Sweep de la red interna

Estos hosts los guardamos en un archivo targets:

hashtag
Enumeración de hosts con Nmap

Vamos a enviar a la máquina un binario de Nmap para ejecutarlo desde la red interna:

LogoGitHub - andrew-d/static-binaries: Various *nix tools built as statically-linked binariesGitHubchevron-right

Tenemos datos de los 3 hosts:

hashtag
🖥️ Host: 172.16.8.3

Perfil: Servidor con servicios de autenticación y directorio, probablemente un controlador de dominio (AD).

  • Servicios clave detectados:

    • Kerberos (88/tcp) y kpasswd (464/tcp) → Sistema de autenticación, común en entornos Windows AD.

    • LDAP (389/tcp) y LDAPS (636/tcp) → Protocolo de directorios (posible Active Directory).

    • NetBIOS (139/tcp) y SMB (445/tcp) → Compartición de archivos en red.

    • DNS (53/tcp) → Indica que podría resolver nombres internamente.

    • epmap (135/tcp) y puerto 593/tcp abierto (RPC) → Soporte para DCOM/RPC.

Análisis rápido: Posiblemente es un controlador de dominio Windows Server, usado para autenticación y gestión centralizada de red.

hashtag
🖥️ Host: 172.16.8.20

Perfil: Servidor mixto, probablemente un servidor de archivos con acceso remoto y servicios NFS.

  • Servicios clave detectados:

    • HTTP (80/tcp) → Página web o servicio web en ejecución.

    • NFS (2049/tcp) y sunrpc (111/tcp) → Exportación de archivos tipo Unix/Linux.

    • SMB (445/tcp), NetBIOS (139/tcp) y epmap (135/tcp) → Soporte Windows.

    • RDP (3389/tcp) → Acceso remoto a escritorio (Windows Terminal Services).

Análisis rápido: Servidor híbrido (Linux/Unix + Windows) con NFS y RDP habilitados. Puede estar exponiendo archivos compartidos o ser una máquina de uso general para administración remota.

hashtag
🖥️ Host: 172.16.8.50

Perfil: Máquina orientada a acceso remoto y posible interfaz web de administración.

  • Servicios clave detectados:

    • RDP (3389/tcp) → Acceso de escritorio remoto.

    • HTTP-alt (8080/tcp) → Servicio web no estándar (aplicación en desarrollo, dashboard o consola admin).

    • SMB/NetBIOS (135, 139, 445) → Acceso compartido de archivos y servicios DCOM.

Análisis rápido: Podría ser una estación de trabajo remota o servidor web de pruebas con acceso vía navegador y RDP.

hashtag
Montar el recurso compartido NFS

El puerto 2049, NFS, siempre es interesante. Podemos usar "showmount"arrow-up-right para listar las exportaciones, que podríamos montar y explorar de forma similar a cualquier otro recurso compartido de archivos. Encontramos una exportación, DEV01, accesible para todos (acceso anónimo). Veamos qué contiene.

No podemos montar el recurso compartido NFS mediante Proxychains, pero tenemos acceso root al host dmz01 para intentarlo. Vemos algunos archivos relacionados con DNN y un subdirectorio DNN.

El subdirectorio DNN es muy interesante, ya que contiene un archivo web.config. Al verificar el contenido del archivo, encontramos lo que parece ser la contraseña de administrador para la instancia DNN.

Usaremos estas credenciales para la siguiente sección de explotación.

hashtag
Lectura de la flag

AnteriorPersistencia Post-ExplotaciónSiguienteExplotación y escalada de privilegios

Última actualización