Una nueva investigación ha descubierto primitivas de explotación en .NET Framework que podrían aprovecharse en aplicaciones de nivel empresarial para lograr la ejecución remota de código.
WatchTowr Labs, que ha denominado en código «vulnerabilidad de conversión no válida» SOAPwndijo que el problema afecta a Barracuda Service Center RMM, Ivanti Endpoint Manager (EPM) y Umbraco 8. Pero es probable que la cantidad de proveedores afectados sea mayor dado el uso generalizado de .NET.
Los hallazgos fueron presentados hoy por el investigador de seguridad de WatchTowr, Piotr Bazydlo, en la conferencia de seguridad Black Hat Europe, que se celebra en Londres.
Básicamente, SOAPwn permite a los atacantes abusar de las importaciones del lenguaje de descripción de servicios web (WSDL) y de los servidores proxy de clientes HTTP para ejecutar código arbitrario en productos creados sobre la base de .NET debido a errores en la forma en que manejan los mensajes del Protocolo simple de acceso a objetos (SOAP).
«Por lo general, se puede abusar de él a través de clientes SOAP, especialmente si se crean dinámicamente a partir del WSDL controlado por el atacante», dijo Bazydlo.
Como resultado, los servidores proxy de cliente HTTP de .NET Framework se pueden manipular para utilizar controladores de sistema de archivos y lograr escritura de archivos arbitraria pasando como URL algo como «file://
En un escenario de ataque hipotético, un actor de amenazas podría aprovechar este comportamiento para proporcionar una ruta de Convención de nomenclatura universal (UNC) (por ejemplo, «file://attacker.server/poc/poc») y hacer que la solicitud SOAP se escriba en un recurso compartido SMB bajo su control. Esto, a su vez, puede permitir a un atacante capturar el desafío NTLM y descifrarlo.
Eso no es todo. La investigación también encontró que se puede utilizar un vector de explotación más poderoso como arma en aplicaciones que generan servidores proxy de cliente HTTP a partir de archivos WSDL usando la clase ServiceDescriptionImporter aprovechando el hecho de que no valida la URL utilizada por el proxy de cliente HTTP generado.
En esta técnica, un atacante puede proporcionar una URL que apunte a un archivo WSDL que controla para aplicaciones vulnerables y obtener la ejecución remota de código colocando un shell web ASPX completamente funcional o cargas útiles adicionales como shells web CSHTML o scripts de PowerShell.
Tras la divulgación responsable en marzo de 2024 y julio de 2025, Microsoft optó por no solucionar la vulnerabilidad, afirmando que el problema se debe a un problema o comportamiento de la aplicación, y que «los usuarios no deben consumir entradas que no sean de confianza y que puedan generar y ejecutar código».
Los hallazgos ilustran cómo el comportamiento esperado en un marco popular puede convertirse en una posible ruta de explotación que conduzca a la retransmisión NTLM o a la escritura arbitraria de archivos. Desde entonces, el problema se solucionó en Barracuda Service Center RMM versión 2025.1.1 (CVE-2025-34392, puntuación CVSS: 9,8) y Ivanti EPM versión 2024 SU4 SR1 (CVE-2025-13659, puntuación CVSS: 8,8). La vulnerabilidad en Umbraco 8 persiste ya que alcanzó el final de su vida útil (EoL) el 24 de febrero de 2025.
«Es posible hacer que los servidores proxy SOAP escriban solicitudes SOAP en archivos en lugar de enviarlos a través de HTTP», dijo Bazydlo. «En muchos casos, esto conduce a la ejecución remota de código a través de cargas de webshell o cargas de scripts de PowerShell. El impacto exacto depende de la aplicación que utiliza las clases de proxy».