Una fuga de memoria en el proceso LSASS.exe –desencadenada tras aplicar ciertos parches de marzo 2024– provoca que los controladores de dominio de Windows Server consuman RAM de forma exponencial hasta reiniciarse de manera inesperada. Este artículo explica qué parches corrigen el problema, cómo desplegarlos con seguridad y qué medidas provisionales tomar.

Problema planteado

Después de instalar los paquetes de seguridad publicados el 12 de marzo de 2024 (Patch Tuesday), numerosos administradores detectaron un incremento continuo de la memoria privada de LSASS.exe en controladores de dominio (DC). El desbordamiento no libera recursos, por lo que el servicio de seguridad local agota la memoria disponible y el sistema fuerza un reinicio para preservar la integridad del dominio. El efecto acumulado puede derivar en caídas repetidas, pérdida de autenticaciones Kerberos y ventanas de tiempo sin DC disponible.

Resumen rápido

• Los paquetes acumulativos del 9 de abril de 2024 no contienen la corrección de la fuga.
• Microsoft liberó la solución como Out‑of‑Band (OOB) el 25 de marzo de 2024 en los siguientes boletines:
  • Windows Server 2022 → KB5037422
  • Windows Server 2019 → KB5037425
  • Windows Server 2016 → KB5037423
  • Windows Server 2012 R2 → KB5037426
• Si ya aplicaste los parches de abril, el instalador marca el OOB como “reemplazado”; deberás esperar a la versión de mayo (o posterior) que reincorpore la corrección.

¿Qué es LSASS y por qué es crítico?

LSASS (Local Security Authority Subsystem Service) es el servicio responsable de la autenticación, la aplicación de políticas de seguridad y la emisión/validación de tokens en Windows. En un DC, gestiona simultáneamente:

• Autenticaciones Kerberos y NTLM.
• Replicación de secretos entre DC.
• Procesamiento de certificados y operaciones PKI.
• Consultas LDAP seguras de clientes y aplicaciones.

Una fuga de memoria en LSASS se multiplica por el número de autenticaciones: cuanto mayor la carga, más rápido se consume la RAM del sistema.

Cómo identificar la fuga de memoria

Antes de desplegar cualquier parche, verifica si tu entorno está afectado:

1. En Administrador de tareas → Detalles, ordena por “Memoria (privada MB)” y localiza lsass.exe. Valores que crecen > 50 MB/hora indican fuga.
2. Agrega un contador en PerfMon: Process → lsass → Private Bytes. Establece un umbral de alerta al 70 % de la RAM física.
3. Ejecuta de forma puntual:
   
   Get-Process -Name lsass | Select-Object @{n='MemMB';e={($_.PrivateMemorySize/1MB)}} | Format-Table -Auto
4. Revisa el Visor de eventos (System): identificadores 1074 y 6008 indican reinicios inesperados originados por crash del proceso LSASS.

Escenarios y soluciones

Situación	Acción recomendada
Aún no instalaste los parches de abril	Aplica primero el OOB del 25/03/2024 (KB correspondiente) y después el paquete acumulativo de abril. Así aseguras que la corrección permanezca vigente.
Ya instalaste los parches de abril	El OOB no se instalará al detectarse como “reemplazado”. Microsoft publicará un paquete integrado a partir de la segunda semana de mayo. Mientras tanto: • Supervisa la memoria de LSASS. • Prepara reinicios controlados si supera el 80 % de la RAM disponible.
Parche mensual de mayo o posterior	La corrección OOB se integrará al canal regular. Instala los parches de mayo en cuanto salgan y revisa la nota de la KB para confirmar la inclusión de la solución de LSASS.

Procedimiento de instalación seguro para el OOB

1. Descarga local. Copia el MSU apropiado al DC para evitar interrupciones si se pierde la red.
2. Desconexión del clúster. Si empleas controladores virtualizados en HA, evacúa cargas y pausa la VM.
3. Instalación simultánea. En dominios grandes, aplica el OOB a un subconjunto representativo (por ejemplo, 1 DC por sitio) y observa 24 h antes del despliegue masivo.
4. Comando silencioso.
   wusa.exe .\windows10.0-kb5037422-x64.msu /quiet /norestart
5. Reinicio controlado. Programa el reinicio fuera de horas punta. Evita usar hot‑patching; se ha documentado que no libera correctamente la memoria ya perdida.
6. Verificación. Tras el reinicio ejecuta:
   Get-HotFix -Id KB5037422 (sustituye por tu KB) y verifica la fecha.

Qué hacer si no puedes esperar al parche de mayo

Algunas organizaciones con picos de autenticación (universidades, retail) no pueden arriesgar reinicios inesperados. Si los DC ejecutan los parches de abril y la fuga continúa:

• Aísla temporalmente el tráfico LDAP de aplicaciones no críticas para reducir el número de llamadas a LSASS.
• Implementa reinicios programados cada 48 h mediante Restart-Computer –Schedule para liberar memoria.
• Escala a Microsoft Premier con un trazado debug del proceso si el crecimiento es > 1 GB/hora.

Expectativas para el ciclo de mayo 2024

Microsoft confirmó en la guía oficial del estado de Windows Server que la corrección OOB se integrará en la rama normal. Esto implica que:

• El parche de seguridad de mayo reemplazará automáticamente el KB OOB.
• No será necesario desinstalar el OOB antes de instalar el acumulativo.
• Las herramientas de gestión (WSUS, SCCM, Intune) reconocerán el nuevo paquete con misma clasificación (Security Update), por lo que conviene ajustar aprobaciones automáticas.

Buenas prácticas preventivas

1. Pruebas en staging. Replica tu topología de dominio en un entorno cerrado. Inyecta carga de autenticación simulada para validar estabilidad.
2. Supervisión proactiva. Configura alertas en Azure Monitor o SCOM para Process\Private Bytes > 70 % RAM.
3. Plan de contingencia. Documenta un procedimiento de reinicio escalonado por sitio de AD, con control de Global Catalog para no dejar zonas sin autenticación.
4. Comunicación interna. Difunde un boletín a Service Desk explicando que la ausencia del OOB podría derivar en reinicios; así reducirás tickets de “login fallido”.

Preguntas frecuentes

¿Afecta la fuga a servidores miembro que no son DC?
En la mayoría de escenarios no; el consumo de LSASS en servidores miembro es menor. Sin embargo, se ha observado crecimiento anómalo en servidores RDS con picos de sesión concurrente. Monitorízalos igualmente.

¿El parche OOB exige un reinicio?
Sí. Aunque WUSA permite la instalación sin reiniciar, la corrección solo toma efecto tras reiniciar LSASS, y en un DC ese proceso no puede reiniciarse de forma aislada.

¿Puedo desinstalar los parches de marzo para mitigar la fuga?
Técnicamente sí, pero quedarías expuesto a vulnerabilidades críticas (CVEs de Kerberos y LDAP). Es preferible instalar el OOB.

¿Hot‑patching soluciona el problema?
Las sesiones de hot‑patch reducen el tiempo de mantenimiento, pero no revierten el consumo de memoria ya comprometido. Además, algunos clientes reportaron errores 0xC1900101 al aplicar el parche en caliente.

Checklist de acción rápida

• Identifica DC con fuga: contador Private Bytes > 70 % RAM.
• Descarga y aplica KB5037422/25/23/26 según versión.
• Reinicia controladamente.
• Confirma la instalación con Get-HotFix.
• Monitorea LSASS cada 30 min durante 72 h.
• Programa la instalación del parche de mayo en cuanto quede disponible.

Conclusión

La fuga de memoria de LSASS introducida por los parches de marzo 2024 puede poner en jaque la estabilidad de cualquier dominio. La solución OOB de marzo 25 es, a día de hoy, la única forma de detener el crecimiento descontrolado de RAM en controladores de dominio que aún no han aplicado los parches de abril. Hasta que Microsoft integre definitivamente la corrección en el ciclo de mayo 2024, la supervisión proactiva y los reinicios controlados siguen siendo imprescindibles.