Cómo verificar la protección de la Autoridad de seguridad local en Windows 11

El proceso LSASS (Local Security Authority Subsystem Service) es un componente esencial de Windows encargado de autenticar a los usuarios, aplicar las políticas de seguridad y generar los tokens de acceso que controlan el acceso a los recursos del sistema. Como LSASS procesa y almacena material de credenciales sensible (por ejemplo, hashes de contraseñas o tickets de Kerberos), es un objetivo muy atractivo para los atacantes. Si lo comprometen, pueden extraer credenciales de la memoria, escalar privilegios y moverse lateralmente entre sistemas.

La protección de la Autoridad de seguridad local (LSA) es un control de seguridad fundamental de Windows 11 pensado para reducir ese riesgo. Protege el proceso LSASS ejecutándolo como proceso protegido y limitando el acceso únicamente a componentes firmados y de confianza. Así se evitan accesos no autorizados a la memoria, la inyección de código y las técnicas más habituales de robo de credenciales. Sin embargo, confirmar que la protección LSA está activada exige revisar varios indicadores del sistema, no solo un interruptor en la interfaz.

Sigue leyendo para conocer un flujo de trabajo práctico con el que los administradores y los proveedores de servicios gestionados (MSP) pueden verificar la protección LSA en Windows 11.

Cómo comprobar si la protección de la Autoridad de seguridad local está activada

Conviene validar la protección LSA desde varios ángulos, sobre todo en entornos gestionados. Los pasos siguientes te guiarán por las comprobaciones en la interfaz, los valores del registro, la evidencia de los registros de eventos, el contexto de las políticas y las funciones de seguridad complementarias para asegurarte de que LSASS se ejecuta como proceso protegido.

📌 Requisitos previos:

• Derechos de administrador local en el endpoint
• Acceso a Seguridad de Windows, al Visor de eventos y a una consola con privilegios elevados (por ejemplo, PowerShell o el símbolo del sistema)
• Registro formal de cambios para cualquier corrección

Paso 1: Revisa Seguridad de Windows

Primero, comprueba el estado en Seguridad de Windows para confirmar cómo informa el sistema de la protección LSA en este momento. En este paso también verás si hay avisos o recomendaciones que requieran tu atención inmediata.

1. Ve a Configuración > Privacidad y seguridad > Seguridad de Windows > Seguridad del dispositivo > Detalles del aislamiento del núcleo.
2. Localiza el interruptor de protección de la Autoridad de seguridad local y confirma que está Activado.
3. Revisa las recomendaciones o advertencias que se muestren al usuario.
4. Haz una captura de pantalla si necesitas evidencia para una auditoría o para la gestión de tickets.

Paso 2: Confirma en el registro

A continuación, revisa el registro para saber si la protección LSA también está configurada a nivel de sistema. Así podrás distinguir entre un problema de visualización en la interfaz y la intención real de protección.

1. Abre el Editor del Registro con derechos de administrador.
2. Ve a HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Revisa RunAsPPL y confirma que tiene el valor 1 o 2, lo que activa la protección LSA (con o sin bloqueo UEFI) para que LSASS se ejecute como proceso protegido tras reiniciar.
4. Revisa RunAsPPLBoot y confirma que tiene el valor 1 o 2, lo que aplica la protección LSA en una fase más temprana del arranque; el valor 2 refuerza esa aplicación al bloquear la configuración frente a manipulaciones en los sistemas compatibles.
5. Combina estos valores con los registros de eventos del paso siguiente para confirmar el comportamiento en ejecución.

Paso 3: Valida con los registros de eventos

Los registros de eventos también ofrecen una confirmación fiable de si LSASS se inició realmente como proceso protegido y revelan los plug-ins que no se cargaron por no cumplir los requisitos de protección.

1. Abre el Visor de eventos.
2. Ve a Registros de aplicaciones y servicios > Microsoft > Windows > CodeIntegrity > Operational.
3. Busca eventos de integridad de código (por ejemplo, los ID de evento 3065 o 3089) que indiquen que LSASS se inició como proceso protegido y señalen los plug-ins de LSA bloqueados o que no se cargaron.
4. Sigue las indicaciones de auditoría de Microsoft para profundizar en el análisis.

Paso 4: Verifica con PowerShell y el contexto de las políticas

Además, PowerShell y la validación de políticas te ayudan a confirmar que la protección LSA está activada y aplicada por las herramientas de gestión, de modo que la configuración sobreviva a las actualizaciones del SO y los usuarios finales no puedan cambiarla.

1. Usa una sesión de PowerShell con privilegios elevados para confirmar los valores del registro relacionados con LSA y verificar el estado configurado con este comando:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL","RunAsPPLBoot" -ErrorAction SilentlyContinue

2. Comprueba que la directiva de grupo o el MDM aplican la protección LSA para que se mantenga tras las actualizaciones y prevalezca sobre la configuración local de la interfaz.

Paso 5: Contrasta el estado de LSASS y de Credential Guard

También deberías validar cómo interactúa la protección LSA con Credential Guard, ya que ambas funciones dependen del comportamiento protegido de LSASS y de la seguridad basada en virtualización. Aun así, son funciones de refuerzo independientes, por lo que confirmar que están alineadas evita configuraciones incorrectas que podrían debilitar el aislamiento o provocar advertencias inesperadas.

1. Confirma que Credential Guard está activado.
2. Confirma que LSASS se ejecuta como proceso protegido validando los valores del registro RunAsPPL y los eventos de inicio protegido identificados en los pasos anteriores.
3. Revisa los registros de integridad de código y de auditoría de LSA en busca de errores que indiquen componentes bloqueados o conflictos entre Credential Guard y la protección LSA
4. Anota cualquier discrepancia entre el estado esperado y el real para corregirla antes de continuar con la validación.

Paso 6: Guarda la evidencia para la auditoría

Para poder revisar los hallazgos más adelante y facilitar mucho el diagnóstico, recopila siempre evidencia clara y verificable.

1. Haz capturas de pantalla del estado de la protección LSA en Seguridad de Windows.
2. Exporta las claves del registro correspondientes desde HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Anota los ID de evento que confirman el inicio protegido de LSASS o que identifican problemas con plug-ins.
4. Registra el nombre del dispositivo, la compilación de Windows y el ámbito de la política aplicable, y guarda después la evidencia en tu RMM o en tu sistema de gestión de tickets.

Paso 7: Corrige las incoherencias de estado

Por último, actúa cuando las señales de la protección LSA no coincidan entre la interfaz, el registro y los registros de eventos. Resuelve esas incoherencias para asegurarte de que el dispositivo está realmente protegido y de que el estado notificado es exacto.

• Vuelve a aplicar la política correspondiente si la interfaz indica que la protección LSA está desactivada, pero el registro y los valores de la política señalan que está activada.
• Reinicia el dispositivo y repite el proceso si es necesario, hasta que Seguridad de Windows, los valores del registro y los eventos de integridad de código muestren de forma coherente que LSASS se inicia como proceso protegido.
• Investiga los estados de advertencia o los mensajes de paquetes LSA sin firmar que aparezcan en Seguridad de Windows.
• Recurre a tu artículo de corrección habitual para resolver los plug-ins o controladores que no cumplan los requisitos.
• Vuelve a validar la configuración después de la corrección para confirmar que el estado es coherente en todas las fuentes.

Resumen de buenas prácticas

Estas son algunas buenas prácticas que te ayudarán a validar la protección LSA de forma coherente y a aplicarla con fiabilidad. Reducen la ambigüedad y agilizan las investigaciones.

¿Qué es la protección LSA y por qué conviene verificarla?

La protección LSA es una función de seguridad de Windows que ejecuta LSASS como proceso protegido, de modo que el código no confiable no puede inyectarse en él y se bloquean los intentos de robar credenciales almacenadas en memoria. Refuerza uno de los componentes más sensibles del sistema operativo y es la base de los controles modernos de seguridad de credenciales, como Credential Guard.

La verificación es clave para:

• Asegurarte de que LSASS no solo está configurado, sino que se ejecuta realmente como proceso protegido.
• Detectar discrepancias entre la interfaz, el registro y la aplicación de las políticas.
• Garantizar que la protección se mantiene después de actualizaciones o cambios de política.
• Identificar plug-ins de LSA sin protección o incompatibles que debilitan la seguridad.
• Aportar evidencia para auditorías, comprobaciones de cumplimiento e investigaciones de seguridad.

Resolución de problemas

Al verificar la protección LSA pueden surgir algunos problemas habituales. Ten en cuenta estos pasos de diagnóstico para que el dispositivo informe con precisión de su postura de seguridad.

LSA aparece desactivada después de una actualización

Confirma que la política corporativa sigue aplicándose y que los valores de RunAsPPL continúan configurados. Algunas actualizaciones de Windows restablecen los ajustes de seguridad, por lo que puede hacer falta reiniciar. Si la configuración no se mantiene, vuelve a aplicar la política y verifica de nuevo.

El interruptor de la interfaz no aparece o está atenuado

Normalmente significa que la configuración la controla una política corporativa y no la configuración local. Revisa la precedencia de las políticas y confirma que el registro refleja el estado aplicado. Las configuraciones no compatibles o heredadas también pueden dejar el interruptor inaccesible.

Advertencias sobre plug-ins sin protección

Consulta las indicaciones de auditoría de Microsoft para identificar qué plug-ins o controladores no se cargaron como protegidos. Actualiza, elimina o sustituye los componentes que no cumplan los requisitos para restaurar el comportamiento correcto de LSA. Después, vuelve a revisar los registros de eventos para asegurarte de que no hay más plug-ins afectados.

Los analistas confunden LSA y LSASS

Aclara que LSA es el subsistema responsable de la política de autenticación, mientras que LSASS es el proceso que la implementa. Añadir una breve explicación interna ayudará a reducir esta confusión recurrente.

Validar la protección LSA para una seguridad duradera

Verificar la protección LSA debe hacerse con un método estructurado que confirme que LSASS se ejecuta realmente como proceso protegido. Siguiendo el flujo de trabajo descrito, desde la validación de los valores del registro hasta la corrección de incoherencias, los MSP y los administradores pueden mantener la estabilidad a largo plazo.

Temas relacionados:

• Cómo activar Credential Guard y la protección LSA en los dispositivos cliente
• Cómo activar o desactivar la protección de la Autoridad de seguridad local en Windows 11
• Cómo solucionar la advertencia «El paquete LSA no está firmado como se esperaba» en Windows 11
• Cómo restablecer todos los valores de la política de seguridad local en Windows