Estimados amigos del blog ¡!!
Siguiendo la apasionante senda que iniciamos ya hace unas semanas, venimos con la tercera entrega de la seria Azure Sentinel, donde después de ver como instalar y configurar los primeros pasos, y como conectar nuevas fuentes de datos, venimos con nuevas funcionalidades que te animen a introducirte en el SIEM de Microsoft.
En el capítulo de hoy vamos recrear un pequeño laboratorio que emule un despliegue de clientes y servidores Exchange vulnerables al reciente fallo conocido como Proxylogon.
Proxylogon es una vulnerabilidad con el CVE-2021-26855 muy peligrosa porque permite ejecución de código, no necesita autenticación… es sobre un producto ampliamente implementado… y que está siendo explotada por los malos antes de que saliera el Update. Lo que se denomina un Zero Day peligroso en toda regla. En el momento de la publicación del parche no había exploit público pero con el paso de los días se han ido publicando numerosas pruebas de concepto, y los CERTS y organismos de monitorización estamos viendo en las redes de nuestros clientes como se está intentando explotar.
Realmente no es solo una vulnerabilidad, es un conjunto de 4 vulnerabilidades que empleadas de manera coordinada provocan la RCE sin autenticación.
Detrás de esta publicación hay numerosos grupos APT ( Advanced Persistent Threat) explotando la vulnerabilidad en importantes organizaciones por todo el mundo. Se evidencia la presencia de más de 200.000 equipos afectados en todo el mundo, cifra que irá bajando según se solucionen las actualizaciones, pero que como puedes comprender, está siendo “revoltoso” el asunto de los fallos del Exchange.
Para comprender un poco el fallo, sin que sea el propósito de este artículo, hay que comprender la compleja infraestructura de componentes que existen en un despliegue de Exchange, en el que podemos “consumir” nuestros correos de distintas formas, y contra distintos buzones o servidores de estos. Para realizar esa conexión entre el frontend y el backend, usamos el componente Proxy, y este fallo aprovecha la AUTHenticación en ese componentes para ganar la preciada ejecución de código remoto ( De aquí el nombre Proxylogon).
Para mi, de las numerosas investigaciones que se han hecho públicas, me quedo con esta de la gente de Praetorian.
El propósito más explotado es el de guardar una webshell en el servidor que permita al atacante ejecutar comandos remotos, aunque también es cierto que se están viendo servidores en los que se ejecuta un Ransomware como vector de compromiso para monetizar la acción.
Si tenemos un sistema con un servidor Exchange, debemos configurar como hicimos en la segunda entrega el transporte de eventos, y debemos configurar Sysmon para tener acceso a la monitorización de procesos padre e hijos para poder detectar el ataque. Para ello, sin que sea esto un artículo de cómo montar SYSMON, debemos añadir la rama del “visto de eventos” que queremos transportar.
La manera de detectar el ataque, o mejor dicho, el post-compromiso, es mediante una consulta que nos dará la ejecución de comandos del proceso CMD.exe, como subproceso de w3wp. Es decir, una webshell corriendo en nuestro sistema.
Lo primero es ejecutar el ataque en nuestro Exchange.
Y a continuación ejecutamos una sencilla consulta.
Conclusión
Como puedes ver, es “sencillo” buscar si sabemos qué debemos buscar, pero sobre todo, si tenemos nuestros despliegues correctamente configurados, en este caso, mediante Sysmon.
Espero que os haya gustado y animado el artículo de hoy y nos vemos en próximos episodios de la serie explicando más cositas.
Recuerda que puedes consultar con nuestros expertos sobre Azure Sentinel y como monitorizar/fortificar tus sistemas con Verne y los servicios de Ciberseguridad.
