TryHackMe: Wireshark 101 (Tercera Parte)

 

Lo prometido es deuda, y como dije en mi última entrada en el blog, he hecho todo lo posible por poder traeros esta entrega final acerca de la sala de Wireshark de TryHackMe antes de que acabe el año.

Aprovecho la oportunidad de que me estés leyendo para felicitarte el Año Nuevo y desearte lo mejor para este próximo 2022 que empieza mañana mismo.

Espero que esta serie de entradas sobre Wireshark te sean de utilidad y te hayan servido, al menos, para acercarte un poco más a esta herramienta tan útil y a veces temida por analistas, ya que parece muy complicada de utilizar, pero cuando se adquiere experiencia con ella, es más sencillo de lo que parece a primera vista.

TRÁFICO TCP CON WIRESHARK

Visión General de TCP

TCP o Transmission Control Protocol (Protocolo de Control de Transmisiones) maneja la entrega de paquetes incluyendo la secuencia y los errores. Ya deberías tener un conocimiento de cómo funciona TCP, si necesitas refrescarlo puedes leer la Documentación IETF TCP.

Abajo puedes ver un ejemplo de un escaneo de Nmap, escaneando los puertos 80 y 443. Podemos decir que el puerto está cerrado debido a que los paquetes RST y ACK están en rojo.


Cuando analizamos paquetes TCP, Wireshark puede ser de mucha ayuda y ordenar los paquetes según su nivel de peligrosidad por colores. Si no puedes recordar el código de colores, lo puedes encontrar en el apartado de Visión General de Wireshark. Ahí podrás refrescar cómo usa Wireshark los colores para marcar los paquetes.

TCP puede dar una visión útil de una red durante un análisis, sin embargo, también puede ser difícil de analizar debido al número de paquetes que envía. Aquí es donde puedes necesitar usar otras herramientas como RSA NetWitness y NetworkMinner para filtrar y analizar las capturas más a fondo.

Visión General del Tráfico TCP

Algo común que verás cuando analices paquetes TCP es lo que conocemos como el TCP handshake, el cual ya debe serte familiar. Éste incluye una serie de paquetes: syn, synack, ack; y permite a los dispositivos establecer una conexión.


Normalmente cuando este handshake está fuera de lugar o cuando inclue otros paquetes como el paquete RST, algo sospechoso o erróneo ocurre en la red. El escaneo de Nmap en la sección anterior es un perfecto ejemplo de esto.

Análisis de Paquetes TCP

Para analizar paquetes TCP no entraremos en detalles de cada característica individual del paquete; sin embargo, veremos algunos de los comportamientos y estructuras que tienen estos paquetes.

A continuación puedes ver los detalles de un paquete SYN. Lo principal que queremos comprobar cuando estamos mirando un paquete TCP es el número de secuencia y el número de acuse de recibo.


En este caso, vemos que el puerto no estaba abierto porque el número de acuse de recibo es 0.

Dentro de Wireshark, también podemos ver el número de secuencia original navegando a Edición > Preferencias > Protocolos > TCP > Relativo a números de secuencia(desmarcar la caja).

Por lo general, los paquetes TCP deben considerarse como un todo para contar una historia en lugar de uno por uno en los detalles.

 

TRÁFICO DNS CON WIRESHARK

Visión General de DNS

El protocolo DNS o Domain Name Service (Servicio de Nombres de Dominio) se usa para resolver nombres con sus respectiva direcciones IP. Como otros protocolos, deberías estar familiarizado ya con DNS; sin embargo, si no lo estás puedes refrescarlo desde esta documentación.

Hay un par de cosas que se detallan a continuación y que deberías tener en cuenta a la hora de analizar los paquetes DNS.

  • Consulta-Respuesta

  • Solo servidores DNS

  • UDP

Si cualquiera de éstas está fuera de lugar, los paquetes deberán ser revisados más detenidamente y considerados sospechosos.

A continuación puedes ver una captura de un paquete con varias consultas DNS y sus respuestas.


Echando un vistazo a los paquetes, podemos observar lo que están consultando, esto puede ser muy útil cuando tienes varios paquetes y necesitas identificar tráfico sospechoso o no habitual rápidamente.

Visión General del Tráfico DNS

Consulta DNS:

Si miramos la siguiente imagen, vemos que realmente tenemos dos datos que podemos usar para analizar el paquete. El primer dato es dónde se origina la consulta, en este caso, se trata del puerto UDP 53, lo que significa que el paquete pasará la comprobación, si se tratase de TCP 53 sería considerado como tráfico sospechoso y debería analizarse más a fondo. También podemos echar un vistazo a lo que está consultando, esto puede ser útil junto a otra información para construir un historial de lo que ha pasado.

Cuando analizas paquetes DNS, necesitas comprender tu entorno y si ese tráfico puede ser considerado normal o no en dicho entorno.

Respuesta DNS:

En la siguiente captura vemos un paquete de respuesta, es parecido al de la consulta, pero incluye una respuesta que puede usarse para verificar la consulta.

Análisis Práctico de Paquete DNS

Ahora que comprendes lo básico sobre cómo se ve el tráfico DNS y como interactuar con él, descarga el PCAP adjunto o el archivo dns+icmp.pcap.gz del sitio web de Wireshark. Esta captura solo tiene dos protocolos por lo que es cosa tuya decidir si filtras el protocolo ICMP o no.

 

TRÁFICO HTTP CON WIRESHARK

El protocolo HTTP o Hypertext Transfer Protocol normalmente se usa como puerta al mundo de la world wide web y utilizado por algunos sitios web. Sin embargo, su versión cifrada (HTTPS) es más común, y la veremos en el siguiente apartado. HTTP se usa para enviar solicitudes GET y POST a un servidor web con la intención de recibir algo, como por ejemplo páginas web. Saber cómo analizar HTTP puede ser de ayuda para identificar rápidamente algunos puntos como SQLi, Web Shells y otros vectores de ataque relacionados con la web.

Visión General del Tráfico HTTP

Ya deberías tener cierta comprensión de cómo trabaja HTTP antes de completar esta sala; sin embardo, si necesitas refrescar un poco puedes leer el paper oficial del IETF.

HTTP es uno de los protocolos más sencillos en el análisis de paquetes, va directo al grano y no incluye handshakes ni requisitos previos a la comunicación.


En la imagen anterior podemos ver un ejemplo de paquete HTTP. Podemos recolectar en él información como el flujo de datos que no está encriptado en HTTP, al contrario que en HTTPS. Parte importante de esta información que podemos recolectar es el Request URI, los Datos de Archivos, el Servidor.

Ahora que comprendes la estructura básica de un paquete HTTP, podemos pasar a echar un vistazo a un ejemplo de captura de paquete y ponernos manos a la obra.

Análisis Práctico de Paquete HTTP

Para obtener una mayor comprensión del flujo de paquetes HTTP y comenzar a analizarlos, podemos empezar por el archivo http.cap adjunto, o podemos descargarlo del sitio web de Wireshark.


Después de abrir el PCAP podemos ver que se trata de una simple captura de paquete HTTP con varias solicitudes.

Si navegamos más a fondo en esta captura podemos ver los detalles de una de las peticiones HTTP, por ejemplo la del paquete 4.

Aquí podemos identificar alguna información importante como el huésped, el user-agent, la URI solicitada y la respuesta.

Podemos utilizar algunas de las características integradas en Wireshark para ayudar a digerir esta cantidad de datos y organizarlos para un análisis más exhaustivo. Comenzaremos por ver una característica muy útil en Wireshark para organizar los protocolos presentes en la Jerarquía de Protocolos. La encontrarás en Estadísticas > Jerarquía de Protocolos.

Esta información se puede utilizar en aplicaciones prácticas como la caza de amenazas para identificar discrepancias en las capturas de paquetes.

La siguiente característica que veremos es la Exportación de Objeto HTTP. Ésta nos permitirá organizar todas las URIs solicitadas en la captura. Para utilizarla, ve a Archivo > Exportar Objetos > HTTP.

De forma similar a la Jerarquía de Protocolos, puede ser muy útil para identificar rápidamente posibles discrepancias en las capturas.

La última característica que veremos es los Endpoints. Esta característica nos permite organizar todos los endpoints e IP’s encontradas en una captura específica. Como las anteriores, se útil para identificar dónde se origina una discrepancia. La encontrarás en Estadísticas > Endpoints.


HTTP no es un protocolo común de ver, ya que se usa más HTTPS; sin embargo, HTTP se sigue usando a menudo y puede ser muy sencillo de analizar si se da la oportunidad.

 

TRÁFICO HTTPS CON WIRESHARK

El protocolo HTTPS o Hypertext Transfer Protocol Secure puede ser uno de los protocolos más molestos a la hora de comprenderlo desde las perspectiva del análisis de paquetes, y también puede ser confuso entender los pasos que hay que dar para analizar los paquetes HTTPS.

Visión General del Tráfico HTTPS

Antes de enviar información cifrada, el cliente y el servidor necesitan estar de acuerdo en varios pasos para poder crear un túnel seguro.

  1. Cliente y servidor se ponen de acuerdo en la versión del protocolo

  2. Cliente y servidor seleccionan un algoritmo criptográfico

  3. El cliente y el servidor pueden autenticarse el uno al otro; este paso es opcional

  4. Crea un túnel seguro con una clave pública

Podemos comenzar a analizar el tráfico HTTPS echando un vistazo a los paquetes en busca del handshake entre cliente y servidor. A continuación tienes un paquete de saludo del cliente que muestra la Capa de Registro SSLv2, el Tipo de Handshake y la Versión de SSL.

En la siguiente imagen vemos el paquete de saludo del servidor que envía una información parecida al paquete anterior, aunque esta vez incluye detalles de la sesión e información del certificado SSL.

A continuación vemos el paquete de Intercambio de Clave del Cliente, esta parte del handshake determinará la clave pública a usar para cifrar aún más los mensajes entre Cliente y Servidor.

En el siguiente paquete, el servidor confirmará la clave pública y creará el túnel seguro,, todo el tráfico después de este punto será cifrado basándose en las especificaciones acordadas anteriormente.

El tráfico entre Cliente y Servidor está ahora cifrado y necesitarás la clave secreta para descifrar el flujo de datos que se envía entre ambos huéspedes.

Análisis Práctico de Paquete HTTPS

Para practicar y ponernos manos a la obra con los paquetes HTTPS, podemos analizar el archivo PCAP snakeoil2_070531 y el conjunto de claves proporcionado por Wireshark. Descarga los archivos necesarios adjuntos o directamente del sitio web de Wireshark.

Primero necesitamos cargar el PCAP en Wireshark. Ve a Archivo > Abrir y selecciona el PCAP de snakeoil2.


Si miramos la captura anterior podemos ver que todas las solicitudes están cifradas. Mirando más detenidamente los paquetes podemos ver el handshake HTTPS, así como las solicitudes cifradas en sí mismas. Echemos un vistazo más de cerca a una de las solicitudes cifradas: el paquete 11.

 

Podemos confirmar de los detalles del paquete que los Datos de Aplicación están cifrados. Puedes utilizar una clave RSA en Wireshark para ver los datos descifrados. Para cargar una clave RSA, ve a Editar > Preferencias > Protocolos > TLS > [+]. Si estás usando una versión anterior de Wireshark, aparecerá SSL en lugar de TLS. Deberás introducir los siguientes datos en las distintas secciones:

  • Dirección IP: 127.0.0.1

  • Puerto: start_tls

  • Protocolo: http

  • Archivo de claves: Localización de la clave RSA


Ahora que hemos importado la clave RSA a Wireshark, si volvemos atrás a la captura del paquete podemos ver que el flujo de datos está ahora descifrado.

Podemos ver las solicitudes HTTP en el flujo de datos descifrado. Mirando más a fondo uno de los detalles del paquete vemos el flujo de datos descifrados más de cerca.

Echando un vistazo a los detalles del paquete podemos ver información muy importante, como la solicitud URI y el User-Agent los cuales pueden ser muy útiles en aplicaciones prácticas de Wireshark como la caza de amenazas y la administración de redes.

Ahora podemos utilizar otras características para organizar el flujo de datos, como la opción de exportar objetos HTTP, a la que podemos acceder desde Archivo > Exportar Objetos > HTTP.

ANALIZANDO EXPLOITS PCAP CON WIRESHARK

Visión General del PCAP Zerologon

Hemos recolectado archivos PCAP de un exploit reciente de Windows Active Directory llamado Zerologon o CVE-2020-1472. El escenario dentro del archivo PCAP contiene un Controlador de Dominio Windows con una IP privada 192.168.100.6 y un atacante con una IP privada 192.168.100.128. Veamos los pasos del análisis de este PCAP y hagamos una hipótesis de los eventos que han tenido lugar.

Identificando al Atacante

Inmediatamente después de abrir el archivo PCAP podemos ver algunas cosas fuera de lo normal. Lo primero que vemos es tráfico normal de OpenVPN, ARP, etc. Entonces comenzamos a identificar lo que podríamos decir que son protocolos desconocidos, en este caso DCERPC y EPM.

Viendo los paquetes vemos que 192.168.100.128 está enviando todas las solicitudes, por lo que podemos asumir que el dispositivo es el atacante. Podemos continuar mirando los paquetes provenientes de esta IP para acotar nuestra búsqueda.

Análisis de la Conexión POC de Zerologon

Creamos un filtro para el src de la IP que pensamos es sospechosa. Cuando analizamos PCAPs necesitamos estar atentos a los exploits que los Indicadores de Compromiso o IOCs pueden traer consigo. Esto se conoce como Inteligencia ante Amenazas, algo que queda fuera del alcance de esta sala; recomiendo que después de completar esta sala, si estás interesado en ello, busques más información al respecto de ese tema. En este caso, si tuviéramos un conocimiento previo del exploit Zerologon, sabríamos que el exploit utiliza varias conexiones RPC, y solicitudes DCERPC para cambiar la contraseña de la cuenta de la máquina, lo que podemos verificar en el PCAP.

Análisis de Secretsdump SMB

Analizando el PCAP más a fondo podemos ver tráfico SMB2/3 y tráfico DRSUAPI, de nuevo con conocimiento previo acerca de que el ataque que conocemos usa secretsdump para volcar los hashes. Secretsdump utiliza SMB2/3 y DRSUAPI para ello, por lo que podemos asumir que este tráfico es secretsdump.

Cada exploit y ataque vendrá con artefactos únicos, en este caso, está claro lo que ha pasado y el orden como han ocurrido los eventos. Una vez identificado el atacante, necesitamos tomar otro camino para identificar y aislar, así como reportar el incidente si estuviéramos en un equipo de Caza de Amenazas o de DFIR.

 

De nuevo, feliz 2022 a ti que estás leyendo esta entrada y a toda la gente que no la lea también, ¿por qué no? Ah, y no te atragantes con las uvas. Nos leemos el año que viene.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.