Los atacantes están escaneando activamente servidores de Microsoft Exchange vulnerables y abusando de la última serie de vulnerabilidades de Microsoft Exchange que se parcharon a principios de este año.
En marzo pasado, vimos múltiples exploits de zero-day usados para atacar servidores Exchange on-premises, y parece que todavía no salimos del problema. Quienes no hayan parchado desde abril o mayo julio no están a salvo y aún podrían ser explotados.
Te recomendamos actualizar al último parche de seguridad, monitorear nuevos indicadores de compromiso y mantenerte al tanto de la información a medida que se publique. Seguiremos actualizando esta publicación con nuevos hallazgos.
- Actualización n.º 9 - 25/08/2021 @ 7:10 p. m. hora del Este - Se agregó información sobre webshells ocultos con fechas de modificación anteriores a agosto de 2021
- Actualización n.º 8 - 23/08/2021 @ 6:50 p. m. hora del Este - Se agregaron ubicaciones adicionales donde buscar webshells
- Actualización n.º 7 - 23/08/2021 @ 2:06 p. m. hora del Este - Se amplió la información identificada en la Actualización n.º 6 con rutas de archivo a monitorear y pasos de remediación
- Actualización n.º 6 - 23/08/2021 @ 10:53 a. m. hora del Este - Se agregó información sobre la capacidad de los actores de amenazas de ocultar un webshell en ubicaciones poco comunes o no estándar fuera de los directorios ASP que normalmente se monitorean
- Actualización n.º 5 - 23/08/2021 @ 12:12 a. m. hora del Este - Se listaron direcciones IP y cadenas de user agent que interactúan con webshells
- Actualización n.º 4 - 22/08/2021 @ 8:24 p. m. hora del Este - Se actualizó el conteo de servidores sin parchar a 1764
- Actualización n.º 3 - 21/08/2021 @ 6:48 a. m. hora del Este - Se incluyó un gráfico de servidores sin parchar y de ransomware LockBit
- Actualización n.º 2 - 21/08/2021 @ 2:03 a. m. hora del Este - Se incluyeron cinco payloads de webshell distintos
- Actualización n.º 1 - 21/08/2021 @ 1:19 a. m. hora del Este - Se incluyó una aclaración sobre ProxyShell vs. ProxyLogon
Actualización n.º 9 - 25/08/2021 - 7:10 p. m. hora del Este
Con una mirada adicional del investigador de seguridad Florian Roth (¡muchas gracias por seguir de cerca nuestra información!), Huntress descubrió que algunos de los webshells ocultos guardados en el archivo de configuración de Exchange mencionado anteriormente en las Actualizaciones n.º 7 y n.º 8 también se han reportado con fechas de modificación anteriores a agosto de 2021.
Hemos buscado en más de 4.000 servidores Exchange sobre los que Huntress tiene visibilidad, y encontramos más de ~200 de estos webshells ocultos. Estos se referencian en el archivo de configuración de Exchange mencionado anteriormente con una configuración de virtualDirectory y una physicalPath definida donde se almacenaría el webshell oculto.
Estos son los archivos de configuración que deberías revisar:
- C:\Windows\System32\inetsrv\Config\applicationHost.config
- C:\inetpub\temp\apppools\MSExchangeECPAppPool\MSExchangeECPAppPool.config
Curiosamente, la fecha de modificación de algunos de estos archivos de configuración y de los webshells correspondientes se remonta a marzo, abril, junio o julio, todos antes de la cronología de ProxyShell. No podemos afirmarlo con certeza, pero es razonable suponer que son remanentes de ProxyLogon, de marzo pasado. Además, ninguna de estas rutas “antiguas” de webshell usa los nombres de subcarpeta que habíamos visto antes: WHO, XYZ, ZING, ZOO., etc.
Ya sea que estés parcheado o no, y que te haya afectado o no ProxyLogon o ProxyShell, te recomendamos encarecidamente revisar estos archivos de configuración en busca de indicadores de webshells ocultos. Si descubres nuevas ubicaciones de webshells referenciadas, asegúrate de revisar si existe la misma estructura de directorios y el mismo archivo de webshell bajo C:\Users\All Users.
Si descubriste un webshell alojado en un subdirectorio con uno de los "nombres reservados" de Windows, eliminar los archivos del webshell puede ser bastante complicado. Miembros de la comunidad han sugerido intentar renombrar el archivo. Hemos tenido éxito con este método para una carpeta en particular, y con esta serie de comandos para eliminar un directorio completo.
Estos comandos deben ejecutarse desde un símbolo del sistema como administrador, reemplazando $DIRECTORYNAME por el directorio de destino correspondiente.
icacls $DIRECTORYNAME /grant administrator:F /T
takeown /F $DIRECTORYNAME /R
rd \\.\$DIRECTORYNAME /S /Q
Actualización #8 - 23/08/2021 - 6:50 p. m. hora del Este
Estamos observando que los equipos comprometidos que tienen los webshells ocultos en `ProgramData`, mencionados más abajo en la Actualización #8, a menudo pueden tener un webshell duplicado presente en C:\Users\All Users bajo la misma estructura de subdirectorios y carpetas. Estamos trabajando en localizarlos para los partners y en notificarte si se descubren.
Por favor, agrega esto a tu lista de ubicaciones donde buscar webshells. Puede haber archivos ASPX en subdirectorios de estas ubicaciones, si ves lo siguiente presente:
- C:\Users\All Users\COM
- C:\Users\All Users\COM1
- C:\Users\All Users\CON
- C:\Users\All Users\WHO
- C:\Users\All Users\XYZ
- C:\Users\All Users\ZOO
- C:\Users\All Users\ZING
Actualización #7 - 23/08/2021 - 2:06 p. m. hora del Este
Profundizando en las técnicas que descubrimos en la Actualización #6, donde el archivo de configuración de Exchange C:\Windows\System32\inetsrv\Config\applicationHost.config se modificó para ocultar la presencia de un webshell con una nueva ruta de directorio virtual.
Hasta ahora, hemos descubierto 88 casos de esto, en 62 endpoints. Algunos servidores tienen múltiples entradas y directorios virtuales. Esto saca a la luz algunos puntos a tener en cuenta:
- C:\ProgramData\ y sus subdirectorios también parecen ser una ubicación para algunos webshells.
- Los subdirectorios no se limitan estrictamente a COM o COM1, sino que también se observan WHO, ZING, ZOO, XYZ y otros.
Algunas entradas usan una ruta física (una ubicación en el sistema de archivos para ofrecer al usuario un webshell) con una ruta UNC \\ que apunta a otra máquina. Esto podría considerarse "movimiento lateral", pero dado que el actor de amenazas ya necesitaría tener acceso para colocar un webshell independiente ahí, simplemente agrega persistencia redundante a otro servidor comprometido.
Por favor, revisa tu archivo C:\Windows\System32\inetsrv\Config\applicationHost.config en busca de cambios que incluyan la creación de un nuevo directorio virtual, y examina cualquier ruta nueva encontrada para buscar y eliminar webshells.
Si ves líneas que crean un nuevo directorio virtual en el archivo applicationHost.config:
- Elimina los webshells que puedas encontrar en la ubicación physicalPath
- Edita el applicationHost.config para eliminar las líneas
- Reinicia el servicio IIS para asegurarte de que este cambio se aplique
Huntress enviará reportes de incidentes a los partners afectados por esta técnica a medida que la detectemos.
Actualización #6 - 23/08/2021 - 10:53 a. m. hora del Este
Mientras analizábamos un endpoint comprometido tanto con ProxyShell como con el ransomware LockFile, descubrimos una TTP única que no habíamos visto antes en la actividad de ProxyShell. El archivo de configuración del servicio de internet de Exchange fue modificado para incluir un nuevo "directorio virtual", que en la práctica redirige un endpoint de URL a otra ubicación del sistema de archivos.
Esto permite que un actor de amenazas oculte un webshell en otras ubicaciones poco comunes y no estándar, fuera de los directorios ASP que normalmente se monitorean. Si no sabes que debes buscar esto, pasará desapercibido y los hackers persistirán en el entorno objetivo. Además, el webshell oculto descubierto en este endpoint usa la misma técnica de transformación XML/XLS que hemos visto antes.
Actualización #5 - 23/08/2021 @ 12:12 a. m. hora del Este
Estamos empezando a desglosar los archivos de registro de Exchange de los servidores de partners comprometidos y hemos visto las siguientes direcciones IP y cadenas de user agent interactuar con webshells:
- 37.221.115[.]68 - python-requests/2.25.1
- 45.144.30[.]18 - python-requests/2.26.0
- 84.17.46[.]174 - python-requests/2.26.0
- 116.203.201[.]159 - python-requests/2.26.0
- 116.203.201[.]159 - Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)
- 203.184.132[.]186 - python-requests/2.25.1
- 203.184.132[.]186 - Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)
Por favor, bloquea estas direcciones IP en tu endpoint, en tus firewalls on-prem y de aplicaciones web, y monitorea tu red en busca de estos indicadores de compromiso.
Actualización #4 - 22/08/2021 @ 8:24 p. m. hora del Este
De los aproximadamente 1900 servidores Exchange vulnerables originales del viernes por la noche, todavía vemos 1764 sin parchar en este momento. Esto es bastante preocupante, ya que estamos empezando a ver comportamiento activo de post-explotación que incluye coinminers y ransomware.
Por suerte, el ritmo de nueva explotación empezó a bajar el sábado temprano por la mañana. Solo hemos observado 13 servidores Exchange recién explotados desde el 21/08/2021 a las 0017 hora del Este, lo que eleva el total a 164 servidores Exchange comprometidos en los últimos cuatro días.
Actualización #3 - 21/08/2021 @ 6:48 a. m. hora del Este
El ritmo de actividad de webshells se redujo un poco durante la noche, pero sigue en curso. Durante este tiempo, construimos algunos análisis simples para resaltar los niveles de parches en aproximadamente 1900 servidores Exchange monitoreados.
Aquí tienes el desglose de @HuntressLabs sobre los niveles de parches de Exchange en aproximadamente 1900 servidores, cortesía de @DaveKleinatland. Eso es mucho potencial estrago de #ProxyShell. pic.twitter.com/PaMcRuGkRl
— Kyle Hanslovan (@KyleHanslovan) 21 de agosto de 2021
La colaboración con los investigadores de seguridad del sector Kevin Beaumont y Rich Warren ha ayudado a corroborar que los incidentes de webshells y del ransomware LockFile que estamos viendo en empresas podrían estar relacionados:
- Sistema señuelo capturando actividad de ProxyShell y de LockFile
- Cargas útiles subidas junto con webshells
Seguiremos manteniendo informada a la comunidad a medida que avancen los acontecimientos.
Actualización #2 - 21/08/2021 @ 2:03 a. m. hora del Este
En el mes de agosto (sin limitarnos al aumento de las últimas 48 horas), hemos observado hasta ahora al menos cinco estilos distintos de webshells desplegados en servidores Microsoft Exchange vulnerables:
- Transformación XSL (el más común, con más de 130 ocurrencias)
- Cargador de ensamblado reflejado cifrado
- Separación de comentarios y ofuscación de la palabra clave "unsafe"
- Codificación Base64 de JScript y conversión de tipos de caracteres
- Cargador de archivos arbitrario
Actualización #1 - 21/08/2021 @ 1:19 a. m. hora del Este
Hemos visto varias preguntas sobre si Exchange 2010 es vulnerable. Como se mencionó antes, la cadena de explotación de ProxyShell encadena tres vulnerabilidades distintas para lograr la ejecución de código.
Según las entradas de CVE de nist.gov enlazadas arriba, Exchange 2010 no se ve afectado por estas. Sin embargo, Exchange 2010 llegó al final de su vida útil en octubre de 2020, lo que significa:
"Microsoft ya no [proporcionará] soluciones de seguridad para las vulnerabilidades que puedan hacer que el servidor sea vulnerable a brechas de seguridad"
Recomendamos encarecidamente no usar un servidor 2010 fuera de soporte en 2021.
¿Qué está pasando?
Los hackers están explotando vulnerabilidades en Microsoft Exchange, apodadas ProxyShell, para instalar una puerta trasera para acceso posterior y post-explotación. Este ataque ProxyShell usa tres vulnerabilidades encadenadas de Exchange para realizar ejecución remota de código sin autenticación.
- CVE-2021-34473 ofrece un mecanismo para la ejecución remota de código previa a la autenticación, lo que permite a los actores maliciosos ejecutar código de forma remota en un sistema afectado.
- CVE-2021-34523 permite a los actores maliciosos ejecutar código arbitrario después de la autenticación en servidores de Microsoft Exchange debido a una falla del servicio de PowerShell al no validar correctamente los tokens de acceso.
- CVE-2021-31207 permite a los actores maliciosos, después de la autenticación, ejecutar código arbitrario en el contexto del sistema y escribir archivos arbitrarios.
Huntress observa que los atacantes explotan activamente estas vulnerabilidades contra servidores Exchange vulnerables. Nuestro equipo ha enviado más de 100 informes de incidentes relacionados con este exploit en los últimos dos días, 17 y 18 de agosto.
¿Qué debes hacer?
Es fundamental que actualices tus servidores Exchange con los parches más recientes publicados. Como mínimo, asegúrate de tener instaladas las actualizaciones de julio de 2021. Puedes ver las revisiones rápidas instaladas ejecutando el comando systeminfo en un símbolo del sistema con privilegios administrativos. La salida en la sección "Hotfixes" debe incluir los identificadores de Knowledge Base (KB) adecuados para tu versión de Exchange, enumerados a continuación.
A continuación, una lista de niveles de parche y el hash correspondiente para el binario del servicio MSExchangeRPC que indica una aplicación completa de parches a partir de julio de 2021:
- Exchange 2019 CU10 + KB5004780 = v15.2.922.13
- 8a103fbf4b18871c1378ef2689f0bdf062336d7e02a5f149132cdbd6121d4781
- Exchange 2019 CU9 + KB5004780 = v15.2.858.15
- c5c88f5b013711060bcf4392caebbc3996936b49c4a9b2053169d521f82010aa
- Exchange 2016 CU21 + KB5004779 = v15.1.2308.14
- 9f7f12011436c0bbf3aced5a9f0be8fc7795a00d0395bfd91ff76164e61f918d
- Exchange 2016 CU20 + KB5004779 = v15.1.2242.12
- ab767de6193c3f6dff680ab13180d33d21d67597e15362c09caf64eb8dfa2498
- Exchange 2013 CU23 + KB5004778 = v15.0.1497.23
- 20659e56c780cc96b4bca5e4bf48c812898c88cf134a84ac34033e41deee46e9
Indicadores de compromiso
Hasta ahora, Huntress ha encontrado webshells escritos en subdirectorios dentro de la ruta de instalación de Exchange. Normalmente, estos archivos tienen un nombre aleatorio, aunque algunos son legibles para humanos.
A continuación, un breve fragmento de webshells que hemos descubierto:
C:\inetpub\wwwroot\aspnet_client\HWTJQDMFVMPOON.aspxC:\inetpub\wwwroot\aspnet_client\VJRFWFCHRULT.aspxC:\inetpub\wwwroot\aspnet_client\error.aspxD:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\HWTJQDMFVMPOON.aspxC:\inetpub\wwwroot\aspnet_client\nhmxea.aspx.aspxC:\inetpub\wwwroot\aspnet_client\supp0rt.aspxC:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\d62ffcd688.aspxC:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Current\themes\resources\zaivc.aspxC:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\415cc41ac1.aspxC:\inetpub\wwwroot\aspnet_client\253283293.aspxC:\inetpub\wwwroot\aspnet_client\ykmsr.aspxC:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\6514f55e1a.aspxC:\inetpub\wwwroot\aspnet_client\KDNLIE.aspxC:\inetpub\wwwroot\aspnet_client\VOLWMFQWPP.aspxC:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\VOLWMFQWPP.aspxC:\inetpub\wwwroot\aspnet_client\system_web\NUQvLIoq.aspxC:\inetpub\wwwroot\aspnet_client\shell.aspxC:\inetpub\wwwroot\aspnet_client\updateServer.aspx
Ten en cuenta que estos no son archivos ASPX puros. Si examinas los bytes mágicos y el encabezado del archivo, verás que en realidad se trata de una carpeta de correo de Microsoft Outlook.
Si inspeccionas más a fondo este archivo (con cadenas simples o viéndolo en un editor hexadecimal), encontrarás código válido que a menudo puede ejecutar código con una instrucción eval o permitir la carga adicional de archivos.
Lecturas adicionales y recursos
Esta cadena de ataque se presentó en Black Hat USA '21 en la presentación de Orange Tsai, "ProxyLogon es solo la punta del iceberg." Para una explicación detallada de la cadena de ataque, consulta:
- Las diapositivas de la presentación
- La demostración en video de la prueba de concepto
- La grabación de la presentación
Orange Tsai también proporcionó un informe escrito de la cadena de ataque para Zero Day Initiative tras el concurso Pwn2Own, que puedes encontrar aquí.