Huy Kha | Arquitecto Senior de Identidad y Seguridad

Active Directory (AD) sigue estando en el centro de la mayoría de los entornos empresariales, y los atacantes lo saben. A medida que las amenazas se centran cada vez más en la identidad, AD sigue siendo un punto clave de entrada y escalada de privilegios. El problema es que muchos de los mismos errores de configuración y descuidos aparecen en diferentes organizaciones, sin importar el tamaño o la industria.

Tras revisar los resultados de múltiples evaluaciones de seguridad de Active Directory (ADSA) en 2025, el equipo de Identity Forensics and Incident Response (IFIR) de Semperis ha observado un patrón claro. Ciertos riesgos siguen apareciendo. Algunos son bien conocidos pero no se abordan, mientras que otros son fáciles de pasar por alto sin las herramientas o la visibilidad adecuadas.

En este post, repasaré los 10 riesgos AD más comunes que se encuentran en entornos reales y explicaré qué son, por qué son importantes y cómo se aprovechan de ellos los atacantes.

Riesgo 1: Vías de ataque de nivel 0 abiertas por permisos mal configurados

Durante los compromisos ADSA, uno de los errores de configuración más peligrosos que el equipo IFIR ha observado es cuando las cuentas o grupos terminan con derechos DCSync a través de permisos indirectos. Esto no significa que alguien haya asignado directamente los permisos. En su lugar, por ejemplo, una cuenta sin privilegios podría formar parte de un grupo que tiene derechos de control total sobre una cuenta con privilegios que ya tiene capacidades DCSync.

Como resultado, un atacante no necesita apuntar directamente a la cuenta privilegiada. Puede ir a por el eslabón más débil de la cadena y seguir teniendo acceso al mismo nivel de control. La configuración errónea suele producirse porque los permisos se delegan de forma demasiado amplia, lo que conduce a una violación indirecta del Nivel 0(Figura 1).

Figura 1. Esta exploración muestra un indicador de exposición (IOE) resultante de una mala configuración de los permisos delegados.

Otro ejemplo de una ruta de ataque que conduce a una violación de nivel 0 es el compromiso de una cuenta con permisos de escritura en objetos de controlador de dominio (DC)(Figura 2). Se puede abusar de este acceso para realizar un ataque de Delegación Restringida Basada en Recursos (RBCD), permitiendo al atacante hacerse pasar por cuentas con privilegios elevados.

Figura 2. Este indicador muestra los usuarios o grupos no predeterminados que han recibido acceso de escritura a un objeto de CC.

Riesgo 2: Uso excesivo de grupos AD integrados con privilegios elevados

Los entornos Windows más antiguos suelen incluir grupos integrados destinados a la administración delegada de funciones como Operadores de cuentas, Operadores de servidor, Operadores de copia de seguridad y Operadores de impresión. Estos grupos suelen pasarse por alto, pero todavía pueden tener privilegios elevados en Active Directory(Figura 3). Si estos grupos están poblados, sus miembros pueden realizar acciones que lleven a la escalada de privilegios y al acceso directo a activos de Nivel 0.

Figura 3. Análisis de grupos Este análisis examina AD en busca de grupos integrados heredados con privilegios elevados que supongan un riesgo para la seguridad.

El uso continuado de grupos integrados heredados aumenta el riesgo de compromiso, especialmente si las cuentas que contienen no se supervisan o controlan estrechamente. Por lo general, las mejores prácticas recomiendan evitar confiar en la mayoría de los grupos incorporados en AD (por ejemplo, DnsAdmins, Administradores DHCP, Propietarios Creadores de Políticas de Grupo, Usuarios de Escritorio Remoto), ya que a menudo tienen amplios permisos(Figura 4).

Figura 4. Este indicador identifica a los miembros de grupos comunes incorporados que pueden tener permisos amplios.

Riesgo 3: Configuración insegura de LAN Manager

NT LAN Manager versión 1 (NTLMv1) es un protocolo de autenticación heredado que sigue siendo sorprendentemente común en algunos entornos, pero no debería serlo. Utiliza una criptografía débil que facilita a los atacantes capturar y descifrar el tráfico de autenticación(Figura 5). Si un atacante consigue que una máquina se autentique utilizando NTLMv1 (normalmente con una herramienta de ataque como Responder), puede obtener el hash de la contraseña y descifrarlo sin conexión para obtener la contraseña de texto.

Figura 5. Esta advertencia de Microsoft advierte de la vulnerabilidad de los protocolos de autenticación obsoletos.

En la actualidad, todos los sistemas operativos de Microsoft admiten la nueva versión 2 de NT LAN Manager. Antes de imponer NTLMv2 en todo el dominio, empiece por activar la auditoría de NTLM para identificar los sistemas o aplicaciones que todavía utilizan NTLMv1. Una vez que haya revisado los registros y solucionado cualquier dependencia heredada, puede empezar a configurar un objeto de directiva de grupo (GPO) en todo el dominio para establecer el nivel de autenticación de LAN Manager en Send NTLMv2 response only. Refuse LM & NTLM (Figura 6). Esta configuración refuerza la autenticación moderna y bloquea los protocolos más débiles.

Figura 6. Asegúrese de establecer políticas de seguridad para aplicar protocolos de autenticación modernos.

Riesgo 4: Configuración insegura del ADCS

Nuestro equipo IFIR observa que los Servicios de certificados de Active Directory (ADCS) mal configurados siguen siendo un riesgo que se pasa por alto pero que tiene un gran impacto en muchos entornos. Cuando las plantillas de certificados, los permisos de inscripción o las funciones de inscripción web no están debidamente protegidas, los atacantes pueden abusar de ADCS para hacerse pasar por usuarios, escalar privilegios y obtener el control no autorizado de sistemas sensibles.

Un problema común son las plantillas de certificados excesivamente permisivas que permiten a cualquier usuario autenticado inscribirse para obtener certificados con la etiqueta Client Authentication EKU. Cuando se combina con el ENROLLEE_SUPPLIES_SUBJECT esta configuración permite a los usuarios especificar ellos mismos el asunto del certificado (Gráfico 7), que puede permitir a usuarios con pocos privilegios solicitar certificados en nombre de otras cuentas, incluidos los administradores de dominio. Estos certificados se pueden utilizar para hacerse pasar por esas cuentas y obtener acceso elevado. Este tipo de error de configuración se clasifica como ESC1.

Figura 7: Las plantillas de certificados ADCS mal configuradas pueden permitir a los atacantes solicitar certificados para cuentas con privilegios elevados y obtener acceso elevado.

Un riesgo relacionado ocurre cuando usuarios con pocos privilegios tienen la capacidad de modificar plantillas de certificados. Los atacantes pueden abusar de esta vulnerabilidad para introducir configuraciones inseguras, como habilitar ENROLLEE_SUPPLIES_SUBJECTque puede convertir una plantilla previamente segura en una vulnerable a ataques como ESC1 (Figura 8). Este tipo de configuración errónea corresponde a la ESC4.

Figura 8. Este indicador de seguridad advierte de que una configuración incorrecta de la plantilla de certificado puede plantear riesgos.

Riesgo 5: Delegación ilimitada

La delegación sin restricciones(Figura 9) es peligrosa porque cuando un usuario solicita un ticket de servicio en un servidor con esta configuración, su ticket de otorgamiento de ticket (TGT) se incluye y permanece en memoria. Si un atacante toma el control de ese servidor, puede hacerse con el TGT y utilizarlo para suplantar al usuario. El riesgo aumenta si el servicio Windows Print Spooler se está ejecutando en los DCs. Un atacante puede utilizar el bug de la impresora para hacer que un DC se autentique en el servidor comprometido, lo que filtra el propio TGT del DC y da al atacante el control total.

Para reducir el riesgo, asegúrese de que sus cuentas de nivel 0 o equivalentes tienen el Account is sensitive and cannot be delegated y añádalos al grupo de usuarios protegidos.

Figura 9. Establecer una delegación sin restricciones en un servidor expone el TGT de Kerberos a riesgos y abusos.

Riesgo 6: Los usuarios sin privilegios pueden añadir cuentas de ordenador al dominio

En la mayoría de los entornos AD, cualquier usuario autenticado puede añadir hasta 10 equipos al dominio. Es una configuración por defecto que a menudo se olvida. Pero los atacantes no lo olvidan. Si consiguen acceder a cualquier cuenta con pocos privilegios, pueden crear un objeto ordenador(Figura 10) y utilizarlo en ataques que aprovechan RBCD.

La cosa empeora cuando determinadas plantillas de certificados permiten que los equipos de dominio se inscriban e incluyan el Client Authentication EKU con el ENROLLEE_SUPPLIES_SUBJECT flag. Esa combinación abre la puerta a un ataque ESC1 clásico, en el que el atacante puede solicitar un certificado que le permita hacerse pasar por otro usuario. Si no tienes una razón para permitir a los usuarios añadir máquinas al dominio, es mejor establecer la opción ms-DS-MachineAccountQuota a 0 y bloquear eso.

Figura 10. Este indicador de seguridad te está alertando de que necesitas asegurarte de que los usuarios no pueden añadir máquinas a tu dominio.

Riesgo 7: Cuentas privilegiadas con SPN configurado

La asignación de Service Principal Names (SPNs) a cuentas de usuario privilegiadas como Administradores de Dominio u otras cuentas de Nivel 0 introduce un serio riesgo de seguridad. Cuando una cuenta privilegiada tiene un SPN (Figura 11), cualquier usuario autenticado en el dominio puede enviar una solicitud Kerberos Ticket-Granting Service (TGS) para obtenerlo. El ticket que obtienen está cifrado con el hash de la contraseña de la cuenta, lo que significa que un atacante puede extraerlo y realizar un Kerberoasting ataque. Un error de configuración común es asignar un MSSQL SPN a la cuenta de administrador integrada (RID 500), lo que proporciona a los atacantes una ruta directa de Kerberoasting a una de las cuentas más poderosas del dominio.

La cuestión clave es que el cracking se produce totalmente offline. Una vez que el atacante tiene el ticket, puede realizar un ataque de fuerza bruta o de diccionario utilizando herramientas como hashcat sin generar más tráfico o alertas en el DC. Las cuentas con privilegios nunca deben tener SPNs asignados. Si un servicio necesita un SPN, debe ejecutarse bajo una cuenta de servicio separada, con pocos privilegios y una contraseña segura y gestionada.

Figura 11: Este escaneo identifica cuentas privilegiadas con SPNs definidos.

Riesgo 8: Las cuentas de servicio obsoletas siguen activadas

Las cuentas de servicio tienden a acumularse con el tiempo. A menudo se crean para sistemas que han sido sustituidos, scripts puntuales o proyectos antiguos que ya nadie mantiene. El problema es que muchas de estas cuentas siguen activadas mucho después de que ya no se necesiten. Algunas de ellas siguen teniendo permisos elevados o están excluidas de las políticas de contraseñas habituales, lo que las convierte en un objetivo perfecto para los atacantes. Si una de estas cuentas olvidadas se ve comprometida, puede ser difícil de detectar. Como nadie la utiliza activamente, la actividad sospechosa puede pasar desapercibida.

Merece la pena revisar periódicamente las cuentas de servicio, como muestra la Figura 12 . Si una cuenta no se ha utilizado en mucho tiempo y nadie puede justificar su finalidad, desactívala y vigila si se producen consecuencias.

Figura 12. Revisar periódicamente las cuentas de servicio y su actividad ayuda a garantizar que las cuentas no utilizadas se purguen antes de que puedan verse comprometidas.

Riesgo 9: Falta de aplicación del nivel 0

Implantar un modelo completo de organización por niveles en la empresa es difícil y a menudo poco realista. Pero disponer de un modelo mínimo para los sistemas de nivel 0 no es negociable.

El nivel 0 son los sistemas que controlan la identidad, y si se ven comprometidos, el resto del entorno cae con ellos. En la mayoría de las ADSA, hemos visto que muchas organizaciones no cuentan con ningún modelo de niveles.

Si aún no ha establecido un modelo de nivel 0, ahora es el momento de empezar. Para ayudarle, la Figura 13 muestra una lista de sistemas que suelen tratarse como Tier 0 en entornos bien protegidos y un modelo para determinar su estado Tier 0.

Figura 13. Comprender, identificar y proteger los activos de nivel 0, como los de esta lista, es esencial para la ciberseguridad de la empresa.

Riesgo 10: Copias de seguridad de Active Directory poco fiables y sin posibilidad de restauración

AD es el núcleo de la autenticación y el acceso en todo el entorno. Y, sin embargo, una de las lagunas más críticas que seguimos observando en muchas organizaciones es la falta de una estrategia de copia de seguridad adecuada para Active Directory.

Algunas organizaciones asumen que tener controladores de dominio repartidos por las sedes es suficiente, o confían en instantáneas de máquinas virtuales de uso general sin validar si esas copias de seguridad pueden restaurar AD de forma coherente y compatible.

La realidad es que si Active Directory se cae y no hay una copia de seguridad limpia y restaurable, la recuperación se vuelve extremadamente difícil, especialmente después de un ciberataque.

Una copia de seguridad de AD fiable no es sólo una copia o instantánea a nivel de archivo. Cree una copia de seguridad fiable y validada. Aíslela del dominio de producción. Protéjala de manipulaciones. Y pruébela con regularidad. Porque sin ella, está dejando su infraestructura más crítica expuesta a daños irreversibles.

Instantánea de Semperis

En una época en la que los ciberataques no son una cuestión de "si" , sino de "cuándo", las organizaciones deben tomar medidas para garantizar su resistencia antes, durante y después de un ciberincidente.

Empiece por eliminar vulnerabilidades comunes como éstas. A continuación, asóciese con expertos en identidad y seleccione herramientas que den prioridad a la identidad:

  • Refuerce sus defensas
  • Establecer de forma proactiva estrategias eficaces de respuesta a incidentes
  • Recuperarse rápidamente cuando se produce un incidente
  • Reduzca su riesgo a largo plazo

¿Necesita profundizar en su infraestructura de identidad? Aproveche las décadas de conocimiento de primera mano de nuestro equipo IFIR.

Más información sobre la eliminación de vulnerabilidades de Active Directory