ProxyLogon y ProxyShell: Exchange como Campo de Batalla (2021)

El año que Exchange se convirtió en el objetivo número uno

2021 fue el año que demostró que Microsoft Exchange Server on-premise no solo era difícil de mantener, sino activamente peligroso. En un período de ocho meses, dos cadenas de vulnerabilidades independientes (ProxyLogon y ProxyShell) convirtieron servidores de correo corporativo en puertas de entrada para grupos APT, operadores de ransomware y cualquiera con acceso a un exploit público.

ProxyLogon, explotado por el grupo chino Hafnium desde enero de 2021 como zero-day, comprometió aproximadamente 250.000 servidores Exchange a nivel global antes de que Microsoft publicara el parche de emergencia. ProxyShell, presentado por Orange Tsai de DEVCORE en Black Hat USA en agosto de 2021, demostró que la superficie de ataque del proxy de Exchange era mucho más profunda de lo que nadie había anticipado.

Este artículo analiza ambas cadenas técnicamente: cómo funcionaba la confusión del CAS (Client Access Service), por qué el cookie X-BEResource era un vector de SSRF, cómo se encadenaban las vulnerabilidades para lograr RCE pre-auth, y por qué la arquitectura fundamental de Exchange lo convertía en un objetivo recurrente.

La arquitectura de Exchange: el proxy que lo complica todo

Para entender ProxyLogon y ProxyShell, hay que entender primero cómo Exchange Server procesa las peticiones HTTP.

La separación frontend-backend

Exchange Server implementa una arquitectura de dos capas servida por IIS (Internet Information Services):

Frontend (CAS, Client Access Service): recibe todas las peticiones HTTP/HTTPS de clientes (Outlook, OWA, ActiveSync, ECP). Su función principal es determinar a qué servicio backend corresponde cada petición y reenviarla (proxy).

Backend (Mailbox Server): contiene los servicios reales: el buzón de correo, el panel de administración (ECP), OWA, PowerShell remoto, y otros. El backend confía en que el frontend ha autenticado correctamente al usuario.

La comunicación frontend→backend se realiza mediante Kerberos. El frontend se autentica ante el backend usando la cuenta de máquina del servidor Exchange, y pasa la identidad del usuario original en headers HTTP. Esto es fundamental: el backend confía implícitamente en las peticiones que vienen del frontend.

Los handlers de proxy

El frontend tiene múltiples handlers de proxy, cada uno responsable de reenviar peticiones a un servicio backend específico:

• ProxyRequestHandler: handler base
• BEResourceRequestHandler: proxy para recursos estáticos de ECP
• EcpProxyRequestHandler: proxy para el panel de administración
• OwaProxyRequestHandler: proxy para Outlook Web Access
• RpcHttpRequestHandler: proxy para conexiones RPC/HTTP de Outlook

Cada handler determina el destino backend de manera diferente, y cada uno representaba un vector potencial de SSRF.

ProxyLogon: SSRF + escritura de archivos = RCE

ProxyLogon es la combinación de dos CVEs que, encadenados, permiten ejecución remota de código sin autenticación.

CVE-2021-26855: el SSRF en BEResourceRequestHandler

El handler BEResourceRequestHandler se activa cuando el frontend recibe peticiones a recursos estáticos dentro del directorio /ecp/. Su función es reenviar estas peticiones al backend ECP.

La vulnerabilidad residía en cómo este handler determinaba el destino backend. El handler leía el cookie X-BEResource, que contenía la URL del servidor backend al que reenviar la petición. El diseño original asumía que este cookie era generado internamente y nunca manipulado por un cliente externo.

El flujo del ataque era:

1. Atacante envía POST /ecp/x.js (archivo que no necesita existir)
2. El handler BEResourceRequestHandler procesa la petición
3. El cookie X-BEResource contiene: backend-server/autodiscover/autodiscover.xml
4. El frontend reenvía la petición al endpoint interno especificado
5. El backend responde con datos internos (autodiscover, buzones, etc.)
6. El frontend devuelve la respuesta al atacante

Lo crítico es que el handler no validaba correctamente la URL en X-BEResource. Aceptaba rutas arbitrarias, incluyendo endpoints internos que normalmente no son accesibles desde fuera. Y como el frontend se autenticaba ante el backend con Kerberos como la cuenta de máquina de Exchange, las peticiones llegaban al backend con privilegios elevados.

El atacante podía acceder a cualquier endpoint backend sin autenticación, incluyendo:

• Autodiscover: para enumerar buzones y obtener el SID del administrador
• MAPI/nspi: para acceder a la libreta de direcciones
• ECP: para acceder al panel de administración

CVE-2021-27065: escritura arbitraria de archivos via ECP

Con acceso al backend ECP (panel de administración de Exchange) obtenido mediante el SSRF, el atacante podía explotar una segunda vulnerabilidad en la funcionalidad de Virtual Directory del ECP.

Exchange permite configurar Virtual Directories, y la función de reset de un Virtual Directory escribe un archivo de configuración en una ubicación especificada. El atacante abusaba de este mecanismo para escribir un archivo .aspx en el directorio web de IIS, convirtiendo cualquier contenido controlado en una webshell.

El flujo completo de ProxyLogon era:

1. SSRF (CVE-2021-26855): acceder al backend autodiscover para obtener
   el SID del admin y un token de autenticación ECP

2. SSRF (CVE-2021-26855): usar el token para acceder al backend ECP
   como administrador

3. Escritura de archivo (CVE-2021-27065): abusar de la funcionalidad
   de Virtual Directory para escribir una webshell ASP.NET en el
   directorio web de IIS

4. La webshell proporciona RCE completo con privilegios de SYSTEM

Las webshells de Hafnium

Hafnium desplegaba típicamente webshells minimalistas de una línea en formato ASPX:

<%@ Page Language="Jscript" %>
<%eval(Request.Item["cmd"],"unsafe");%>

Estas webshells se escribían en rutas como C:\inetpub\wwwroot\aspnet_client\ o dentro de directorios de OWA, donde IIS las servía directamente. La simplicidad era deliberada: una webshell de una línea es difícil de distinguir de un archivo legítimo en un escaneo superficial.

ProxyShell: la segunda cadena de Orange Tsai

Orange Tsai, investigador de DEVCORE y uno de los hackers más prolíficos en vulnerabilidades de Exchange, presentó ProxyShell en Black Hat USA el 5 de agosto de 2021. La cadena era diferente a ProxyLogon pero igualmente devastadora.

CVE-2021-34473: bypass de ACL por confusión de path

La primera vulnerabilidad de la cadena era un bypass de los controles de acceso (ACL) del frontend. Exchange implementa listas de control de acceso que determinan qué endpoints requieren autenticación y cuáles son accesibles sin ella.

El bypass explotaba una confusión en cómo el frontend normalizaba las URLs. Al construir una URL con un formato específico, el atacante podía hacer que el frontend evaluara los permisos contra una ruta (que no requería autenticación) pero reenviara la petición a otra ruta diferente (que sí la requería).

Concretamente, el atacante accedía al servicio PowerShell de Exchange (que normalmente requiere autenticación) a través de una URL que el sistema de ACL interpretaba como un recurso público.

CVE-2021-34523: elevación de privilegios en PowerShell backend

Una vez que la petición llegaba al backend de PowerShell sin autenticación, el atacante necesitaba una identidad para ejecutar comandos. Esta segunda vulnerabilidad permitía especificar un parámetro que el backend de PowerShell interpretaba como la identidad del usuario, sin verificar que el frontend lo hubiera autenticado realmente.

El atacante podía impersonar al administrador de Exchange especificando su SID (Security Identifier) en el header de la petición. El backend de PowerShell confiaba en que el frontend había validado la identidad, pero la petición había llegado a través del bypass de ACL sin ninguna autenticación.

CVE-2021-31207: escritura de archivos via PowerShell

Con acceso al backend de PowerShell como administrador, el atacante utilizaba el cmdlet New-ManagementRoleAssignment para asignar el rol de exportación de buzones a su sesión. Luego usaba New-MailboxExportRequest para exportar un buzón a un archivo PST en una ruta controlada.

El truco estaba en que el atacante primero enviaba un correo a un buzón con una webshell embebida en el cuerpo del mensaje. Luego exportaba ese buzón como un archivo .aspx al directorio web de IIS. El formato PST contiene los datos del correo, y entre esos datos estaba la webshell funcional. IIS interpretaba el archivo como una página ASP.NET ejecutable.

Línea temporal de ProxyShell

La cronología de ProxyShell revela una brecha problemática en la comunicación de Microsoft:

• Abril 2021: Microsoft parchea CVE-2021-34473 y CVE-2021-34523 silenciosamente, sin publicar advisories
• Mayo 2021: se parchea CVE-2021-31207
• Julio 2021: Microsoft publica los advisories de las tres vulnerabilidades (meses después del parche)
• 5 de agosto 2021: Orange Tsai presenta la cadena completa en Black Hat
• 12 de agosto 2021: exploits funcionales circulan públicamente
• 13 de agosto 2021: explotación masiva detectada globalmente

El problema fue que muchas organizaciones no habían aplicado los parches de abril y mayo porque los advisories no se publicaron hasta julio. Cuando Orange Tsai presentó la cadena en Black Hat, decenas de miles de servidores seguían vulnerables.

El impacto: 250.000 servidores y más

Hafnium: explotación selectiva a masiva

Hafnium comenzó explotando ProxyLogon de forma selectiva desde al menos enero de 2021, apuntando a organizaciones específicas:

• Instituciones de investigación de enfermedades infecciosas (en plena pandemia COVID-19)
• Bufetes de abogados con clientes gubernamentales
• Contratistas de defensa
• Think tanks de política exterior
• Universidades
• ONGs

Microsoft publicó el parche de emergencia el 2 de marzo de 2021, fuera del ciclo normal de Patch Tuesday. Pero entre la publicación del parche y la aplicación por parte de las organizaciones, otros grupos se sumaron a la explotación:

• DearCry: ransomware desplegado via ProxyLogon apenas días después del parche
• Black Kingdom: otro ransomware que explotó la ventana de parcheo
• Múltiples grupos criminales y APTs aprovecharon los servidores ya comprometidos por Hafnium

La estimación de 250.000 servidores comprometidos (publicada por múltiples fuentes, incluyendo Brian Krebs) se refiere al total global de servidores Exchange afectados antes de que el parcheo generalizado redujera la exposición.

La cascada post-ProxyShell

ProxyShell, al presentarse públicamente en Black Hat con detalles técnicos completos, generó una segunda ola de explotación masiva en agosto de 2021. Los grupos de ransomware Conti, LockFile y Hive utilizaron ProxyShell como vector de acceso inicial durante el segundo semestre de 2021.

Análisis técnico: por qué Exchange es un objetivo recurrente

La serie "Proxy" de vulnerabilidades descubiertas por Orange Tsai no se limitó a ProxyLogon y ProxyShell. También documentó:

• ProxyOracle: vulnerabilidad que permitía descifrar contraseñas de buzones
• ProxyRelay: NTLM relay a través del proxy de Exchange

Todas compartían la misma raíz arquitectónica: la complejidad del proxy frontend-backend de Exchange.

Factores que amplifican el riesgo

Superficie de ataque expuesta: Exchange Server, por su naturaleza, debe ser accesible desde Internet para recibir correo y permitir acceso remoto (OWA, ActiveSync). Esto lo convierte en un servicio de perímetro expuesto por diseño.

Privilegios elevados: Exchange se ejecuta con privilegios de SYSTEM y tiene permisos amplios en Active Directory (incluyendo la capacidad de replicar objetos, lo que ha sido explotado en ataques como PrivExchange). Un compromiso de Exchange frecuentemente implica un compromiso del dominio AD.

Complejidad del código: Exchange es una de las aplicaciones más complejas de Microsoft. La lógica de proxy, la integración con AD, el procesamiento de MAPI, la serialización de datos, y la interacción entre múltiples servicios IIS crean una superficie de ataque masiva que es difícil de auditar completamente.

Cadencia de parcheo: a diferencia de servicios cloud donde el proveedor aplica parches centralmente, Exchange on-premise depende de que cada organización aplique las actualizaciones. Muchas organizaciones tienen ventanas de mantenimiento mensuales o trimestrales, creando brechas de semanas o meses entre la publicación del parche y su aplicación.

Detección y respuesta

Indicadores de compromiso ProxyLogon

Para equipos SOC que necesitan verificar si sus servidores Exchange fueron comprometidos:

Logs de IIS: buscar peticiones POST a /ecp/ con cookies X-BEResource que apunten a endpoints inusuales (autodiscover, MAPI, EWS) desde IPs externas.

Webshells: inspeccionar los directorios web de Exchange:

• C:\inetpub\wwwroot\aspnet_client\
• C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\
• Cualquier archivo .aspx con fecha de modificación posterior a enero 2021 que no pertenezca a una actualización oficial

Reglas de detección: las reglas Sigma y Yara publicadas por la comunidad cubren los patrones de webshells conocidos de Hafnium. Los hashes de las webshells más comunes están documentados en los advisories de Microsoft y CISA.

Indicadores de compromiso ProxyShell

Logs de IIS: peticiones a endpoints de PowerShell de Exchange (/powershell/) sin autenticación previa, o con headers de impersonación manipulados.

Exportaciones de buzón: archivos PST o ASPX inesperados en directorios web de IIS. La presencia de New-MailboxExportRequest en los logs de Exchange Management es una señal directa.

El argumento de la migración cloud

ProxyLogon y ProxyShell se convirtieron en el argumento más poderoso de Microsoft para la migración a Exchange Online (Microsoft 365). La lógica es directa: si Microsoft parchea centralmente, la ventana de exposición se reduce a cero para el cliente.

La realidad matizada

Sin embargo, la migración cloud no es una solución universal:

Concentración de riesgo: Exchange Online concentra millones de buzones en una infraestructura compartida. Un compromiso de Exchange Online afectaría a un número de organizaciones incomparablemente mayor que cualquier incidente on-premise.

Soberanía de datos: para organizaciones europeas sujetas a RGPD, NIS2 o regulaciones nacionales como el ENS (Esquema Nacional de Seguridad) en España, almacenar correos corporativos en infraestructura de Microsoft (con servidores potencialmente fuera de la UE) plantea cuestiones legales y de compliance que no se resuelven simplemente migrando.

Dependencia del proveedor: Exchange on-premise, con todos sus riesgos, es controlado por la organización. Exchange Online depende de la disponibilidad, las políticas de seguridad, y las decisiones unilaterales de Microsoft.

Incidentes cloud propios: Exchange Online ha tenido sus propios incidentes de seguridad, incluyendo la brecha de Storm-0558 en 2023 donde un grupo chino accedió a buzones de funcionarios del gobierno de EE.UU. mediante tokens de autenticación falsificados.

Línea temporal consolidada

Fecha	Evento
Enero 2021	Hafnium comienza explotación zero-day de ProxyLogon
2 marzo 2021	Microsoft publica parche de emergencia para ProxyLogon
3-5 marzo 2021	Exploits públicos, explotación masiva por múltiples grupos
Semana del 8 marzo	CISA emite directiva de emergencia ED 21-02
Abril 2021	Microsoft parchea silenciosamente dos CVEs de ProxyShell
Mayo 2021	Se parchea el tercer CVE de ProxyShell
Julio 2021	Microsoft publica advisories de ProxyShell
5 agosto 2021	Orange Tsai presenta ProxyShell en Black Hat USA
12-13 agosto 2021	Exploits públicos de ProxyShell, explotación masiva
Sep-dic 2021	Conti, LockFile, Hive usan ProxyShell como vector de acceso

Conclusión

ProxyLogon y ProxyShell no fueron vulnerabilidades aisladas. Fueron síntomas de un problema arquitectónico fundamental en Exchange Server: la complejidad del proxy frontend-backend, combinada con la confianza implícita entre capas, creaba una superficie de ataque que ningún parche individual podía resolver.

La lección para la industria va más allá de "parchea rápido". Es que los servicios de perímetro con acceso a datos sensibles y privilegios elevados en el directorio activo representan un riesgo sistémico. Ya sea Exchange, Citrix, Ivanti o cualquier otro appliance de red, la combinación de exposición a Internet, complejidad de código, y dificultad de parcheo convierte a estos servicios en el vector de acceso preferido por atacantes de todo el espectro, desde grupos APT estatales hasta operadores de ransomware oportunistas.