Implementación de modelos administrativos de menor privilegio

• Se aplica a:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

El extracto siguiente procede de La guía de planificación de seguridad de cuentas de administrador, publicada por primera vez el 1 de abril de 1999:

"La mayoría de la documentación y los cursos de formación relacionados con la seguridad analizan la implementación de un principio de privilegios mínimos, pero las organizaciones rara vez lo adoptan. El principio es sencillo y el impacto de aplicarlo correctamente aumenta considerablemente la seguridad y reduce el riesgo. El principio indica que todos los usuarios deben iniciar sesión con una cuenta de usuario que tenga los permisos mínimos absolutos necesarios para completar la tarea actual y nada más. Al hacerlo, se proporciona protección contra código malintencionado, entre otros ataques. Este principio se aplica a los equipos y a los usuarios de esos equipos. "Un motivo por el que este principio funciona tan bien es que le obliga a llevar a cabo investigación interna. Por ejemplo, debe determinar los privilegios de acceso que realmente necesita un equipo o usuario y, después, implementarlos. Para muchas organizaciones, a priori esta tarea podría implicar mucho trabajo, pero es un paso fundamental para proteger correctamente el entorno de red. "Debe conceder a todos los usuarios del administrador de dominio sus privilegios de dominio bajo el concepto de privilegios mínimos. Por ejemplo, si un administrador inicia sesión mediante una cuenta con privilegios y ejecuta accidentalmente un programa de virus, este virus tendrá acceso administrativo al equipo local y a todo el dominio. Si, en vez de eso, el administrador hubiera iniciado sesión con una cuenta sin privilegios (no administrativa), la magnitud de los daños del virus solo abarcaría el equipo local porque se ejecuta como un usuario de equipo local. "En otro ejemplo, las cuentas a las que se conceden derechos de administrador de nivel de dominio no deben tener derechos elevados en otro bosque, aunque haya una relación de confianza entre los bosques. Esta táctica permite evitar daños generalizados en caso de que un atacante logre poner en peligro un bosque administrado. Las organizaciones deben auditar regularmente su red para protegerse contra la elevación no autorizada de privilegios".

El extracto siguiente procede del Kit de recursos de Seguridad de Microsoft Windows, publicado por primera vez en 2005:

"Piense siempre en la seguridad en términos de conceder la menor cantidad de privilegios necesarios para llevar a cabo la tarea. Si una aplicación que tiene demasiados privilegios está en peligro, es posible que el atacante pueda expandir el ataque más allá de lo que lo haría si la aplicación hubiera tenido la menor cantidad de privilegios posible. Por ejemplo, examine las consecuencias que se derivan de que un administrador de red abra involuntariamente un archivo adjunto de correo electrónico que contenga un virus. Si el administrador ha iniciado sesión con la cuenta de administrador de dominio, el virus tendrá privilegios de administrador en todos los equipos del dominio y, por tanto, acceso sin restricciones a casi todos los datos de la red. Si el administrador ha iniciado sesión con una cuenta de administrador local, el virus tendrá privilegios de administrador en el equipo local y, por tanto, podrá acceder a los datos del equipo e instalar software malintencionado, como el de registro de pulsaciones de teclas, en el equipo. Si el administrador ha iniciado sesión con una cuenta de usuario normal, el virus solo tendrá acceso a los datos del administrador y no podrá instalar software malintencionado. Mediante el uso de los privilegios mínimos necesarios para leer el correo electrónico, en este ejemplo, se reduce considerablemente el alcance potencial del riesgo".

El problema de los privilegios

Los principios descritos en los extractos anteriores no han cambiado, pero al evaluar las instalaciones de Active Directory, encontramos de manera sistemática un número excesivo de cuentas a las que se han concedido muchos más derechos y permisos de los necesarios para realizar un trabajo diario. El tamaño del entorno afecta a los números sin procesar de cuentas con privilegios excesivos, pero no a los directorios de proporción mediana que pueden tener docenas de cuentas en los grupos con privilegios más elevados, mientras que las instalaciones de gran tamaño pueden tener cientos o incluso miles. Con pocas excepciones, independientemente de la sofisticación de las habilidades y los recursos de los atacantes, estos suelen seguir el camino que les suponga menos resistencia. Aumentan la complejidad de sus herramientas y enfoque solo si los mecanismos más sencillos fallan o los defensores los repelen.

Desafortunadamente, el camino de menos resistencia en muchos entornos ha demostrado ser el uso excesivo de cuentas con privilegios amplios y profundos. Los privilegios amplios son derechos y permisos que permiten a una cuenta realizar actividades específicas en una sección transversal de gran tamaño del entorno; por ejemplo, se pueden conceder permisos al personal del departamento de soporte técnico que les permita restablecer las contraseñas en muchas cuentas de usuario.

Los privilegios profundos son privilegios eficaces que se aplican a un segmento estrecho de la población, como conceder a un ingeniero derechos de administrador en un servidor para que puedan realizar reparaciones. Ningún privilegio amplio ni profundo es peligroso por sí mismo, pero cuando se conceden muchos privilegios amplios y profundos de forma permanente, basta con que una de las cuentas esté en peligro para que se pueda usar rápidamente con el fin de volver a configurar el entorno con los objetivos del atacante o incluso para destruir grandes segmentos de la infraestructura.

Los ataques pass-the-hash, que son un tipo de ataque de robo de credenciales, son ubicuos porque las herramientas para realizarlas están disponibles de forma gratuita y son fáciles de usar, y porque muchos entornos son vulnerables a los ataques. Pero los ataques pass-the-hash no son el problema real. El quid del problema es doble:

1. Normalmente, es fácil que un atacante obtenga privilegios profundos en un solo equipo y, después, propague ese privilegio de forma amplia a otros equipos.
2. En el mundo informático, por lo general hay demasiadas cuentas permanentes con altos niveles de privilegios.

Incluso si se eliminaran los ataques pass-the-hash, los atacantes no cambiarían de estrategia, sino que usarían simplemente tácticas distintas. En lugar de plantar malware que contenga herramientas de robo de credenciales, podrían plantar malware que registre pulsaciones de teclas o aprovechar cualquier otro enfoque para capturar credenciales que sean eficaces en todo el entorno. Independientemente de las tácticas, los objetivos siguen siendo los mismos: cuentas con privilegios amplios y profundos.

La concesión de privilegios excesivos no solo se encuentra en Active Directory en entornos en peligro. Cuando una organización tiene la costumbre de conceder más privilegios de los necesarios, normalmente se encuentra en toda la infraestructura, tal como se describe en las secciones siguientes.

En Active Directory

En Active Directory, es habitual encontrar que los grupos de EA, DA y BA contienen un número excesivo de cuentas. Normalmente, el grupo de EA de una organización contiene los miembros más pequeños, los grupos de DA normalmente contienen un multiplicador del número de usuarios del grupo de EA y los grupos de administradores suelen contener más miembros que en los otros grupos combinados. Esto suele deberse a la creencia que afirma que los administradores tienen, de alguna manera, "menos privilegios" que los DA o EA. Aunque los derechos y permisos concedidos a cada uno de estos grupos varían, en la práctica deben considerarse grupos igualmente poderosos ya que un miembro de uno de los grupos puede hacerse miembro de los otros dos.

En servidores miembro

Cuando recuperamos la pertenencia de grupos de administradores locales en servidores miembro en muchos entornos, encontramos que la pertenencia oscila desde una serie de cuentas locales y de dominio hasta docenas de grupos anidados que, cuando se expanden, revelan cientos e incluso miles de cuentas con privilegios de administrador local en los servidores. En muchos casos, los grupos de dominio con pertenencias de gran tamaño se anidan en los grupos de administradores locales de los servidores miembro, sin tener en cuenta el hecho de que cualquier usuario que pueda modificar las pertenencias de esos grupos en el dominio puede obtener el control administrativo de todos los sistemas en los que el grupo se ha anidado en un grupo de administradores local.

En estaciones de trabajo

Aunque las estaciones de trabajo suelen tener muchos menos miembros en sus grupos de administradores locales que los servidores miembro, en muchos entornos, a los usuarios se les concede la pertenencia al grupo de administradores local en sus equipos. Cuando esto ocurre, incluso si UAC está habilitado, esos usuarios presentan un riesgo elevado para la integridad de sus estaciones de trabajo.

Importante

Debe plantearse detenidamente si los usuarios requieren derechos administrativos en sus estaciones de trabajo y, de ser así, un mejor enfoque puede ser crear una cuenta local independiente en el equipo que sea miembro del grupo de administradores. Cuando los usuarios requieren elevación, pueden presentar las credenciales de esa cuenta local para la elevación, pero dado que la cuenta es local, no se puede usar para poner en peligro otros equipos o acceder a los recursos del dominio. Pero al igual que con las cuentas locales, las credenciales de la cuenta con privilegios locales deben ser únicas; si crea una cuenta local con las mismas credenciales en varias estaciones de trabajo, expondrá los equipos a ataques pass-the-hash.

En aplicaciones

En ataques en los que el objetivo es la propiedad intelectual e industrial de una organización, las cuentas a las que se les han concedido privilegios eficaces en las aplicaciones se pueden utilizar como destino para permitir la filtración de datos. Aunque es posible que las cuentas que tienen acceso a datos confidenciales no tengan privilegios elevados en el dominio o en el sistema operativo, las cuentas que pueden manipular la configuración de una aplicación o el acceso a la información que proporciona la aplicación presentarán riesgos.

En repositorios de datos

Al igual que ocurre con otros objetivos, los atacantes que buscan acceso a la propiedad intelectual e industrial en forma de documentos y otros archivos pueden establecer como objetivo las cuentas que controlan el acceso a los almacenes de archivos, las cuentas que tienen acceso directo a los archivos, o incluso los grupos o roles que tienen acceso a los archivos. Por ejemplo, si se usa un servidor de archivos para almacenar documentos de un contrato y se concede acceso a los documentos mediante el uso de un grupo de Active Directory, un atacante que pueda modificar la pertenencia del grupo podría agregar cuentas en peligro al grupo y acceder a los documentos del contrato. En los casos en los que las aplicaciones como SharePoint proporcionen acceso a documentos, los atacantes podrían establecer como objetivo las aplicaciones, tal como se ha descrito anteriormente.

Reducción de privilegios

Cuanto más grande y complejo sea un entorno, más difícil será administrarlo y protegerlo. En organizaciones pequeñas, la revisión y reducción de privilegios puede ser un planteamiento relativamente sencillo, pero cada servidor, estación de trabajo, cuenta de usuario y aplicación en uso adicional en una organización agrega otro objeto que se debe proteger. Dado que puede ser difícil o incluso imposible proteger correctamente todos los aspectos de la infraestructura de TI de una organización, en primer lugar debe centrar los esfuerzos en las cuentas cuyos privilegios creen el mayor riesgo, que suelen ser las cuentas y grupos con privilegios integrados en Active Directory, y las cuentas locales con privilegios en estaciones de trabajo y servidores miembro.

Protección de cuentas de administrador locales en estaciones de trabajo y servidores miembro

Aunque este documento se centra en proteger Active Directory, tal como se ha explicado anteriormente, la mayoría de los ataques contra el directorio comienzan como ataques contra hosts individuales. No se pueden proporcionar instrucciones completas para proteger grupos locales en sistemas miembro, pero se pueden usar las recomendaciones siguientes para ayudarle a proteger las cuentas de administrador locales en estaciones de trabajo y servidores miembro.

Protección de cuentas de administrador locales

En todas las versiones de Windows que actualmente están en soporte estándar, la cuenta de administrador local está deshabilitada de manera predeterminada, lo que hace que la cuenta no se pueda usar para ataques pass-the-hash ni otros ataques de robo de credenciales. Pero en dominios que contienen sistemas operativos heredados o en los que se han habilitado las cuentas de administrador locales, estas cuentas se pueden usar, tal como se ha descrito anteriormente, para propagar el riesgo entre servidores miembro y estaciones de trabajo. Por este motivo, se recomiendan los controles siguientes para todas las cuentas de administrador locales en sistemas unidos a un dominio.

En el Anexo H: Protección de cuentas de administrador locales y grupos se proporcionan instrucciones detalladas para implementar estos controles. Pero antes de implementar esta configuración, asegúrese de que las cuentas de administrador locales no se usan actualmente en el entorno a fin de ejecutar servicios en equipos ni realizar otras actividades para las que estas cuentas no deben usarse. Pruebe esta configuración a fondo antes de implementarla en un entorno de producción.

Controles para cuentas de administrador locales

Las cuentas predefinidas de administrador nunca deben usarse como cuentas de servicio en servidores miembro ni para iniciar sesión en equipos locales (excepto en modo seguro, que se permite incluso si la cuenta está deshabilitada). El objetivo de implementar la configuración que se describe aquí es evitar que se pueda usar la cuenta de administrador local de cada equipo, a menos que se reviertan en primer lugar los controles de protección. Al implementar estos controles y supervisar las cuentas de administrador para los cambios, puede reducir significativamente la probabilidad de éxito de un ataque cuyo objetivo sean cuentas de administrador locales.

Configuración de GPO para restringir cuentas de administrador en sistemas unidos a un dominio

En uno o varios GPO que cree y vincule a unidades organizativas de servidor miembro y estación de trabajo en cada dominio, agregue la cuenta de administrador a los derechos de usuario siguientes en Configuración del equipo\Directivas\Configuración de Windows\Configuración de seguridad\Directivas locales\Asignaciones de derechos de usuario:

• Denegar el acceso desde la red a este equipo
• Denegación del inicio de sesión como trabajo por lotes
• Denegar el inicio de sesión como servicio
• Denegar inicio de sesión a través de Servicios de Escritorio remoto

Al agregar cuentas de administrador a estos derechos de usuario, especifique si va a agregar la cuenta de administrador local o la cuenta de administrador del dominio según la manera en la que se etiqueta la cuenta. Por ejemplo, para agregar la cuenta de administrador del dominio NWTRADERS a estos derechos de denegación, escribiría la cuenta como NWTRADERS\Administrator, o iría a la cuenta de administrador del dominio NWTRADERS. Para asegurarse de restringir la cuenta de administrador local, escriba Administrador en esta configuración de derechos de usuario en el Editor de objetos de directiva de grupo.

Nota

Aunque se cambie el nombre de las cuentas de administrador locales, las directivas se seguirán aplicando.

Esta configuración garantizará que la cuenta de administrador de un equipo no se pueda usar para conectarse a los demás equipos, incluso si está habilitada de manera accidental o malintencionada. Los inicios de sesión locales que usan la cuenta de administrador local no se pueden deshabilitar por completo, ni debe intentar hacerlo, ya que la cuenta de administrador local de un equipo está diseñada para usarse en escenarios de recuperación ante desastres.

Si un servidor miembro o una estación de trabajo se desconecta del dominio sin otras cuentas locales con privilegios administrativos concedidos, el equipo se puede arrancar en modo seguro, se puede habilitar la cuenta de administrador y la cuenta se puede usar para realizar reparaciones en el equipo. Cuando se completan las reparaciones, la cuenta de administrador se debe volver a deshabilitar.

Protección de cuentas locales con privilegios y grupos en Active Directory

Ley número seis: un equipo solo es tan seguro como la confianza que transmite el administrador. - Diez leyes inmutables de seguridad (versión 2.0)

La información que se proporciona aquí está pensada para proporcionar instrucciones generales a fin de proteger las cuentas y grupos predefinidos con privilegios más altos en Active Directory. También se proporcionan instrucciones detalladas paso a paso en el Anexo D: Protección de cuentas predefinidas de administrador en Active Directory, Anexo E: Protección de grupos de administradores de empresa en Active Directory, Anexo F: Protección de grupos de administradores de dominio en Active Directory y el Anexo G: Protección de grupos de administradores en Active Directory.

Antes de implementar cualquiera de estas opciones, también debe probar a fondo todas las configuraciones para determinar si son adecuadas para su entorno. No todas las organizaciones podrán implementar esta configuración.

Protección de cuentas predefinidas de administrador en Active Directory

En cada dominio de Active Directory, se crea una cuenta de administrador como parte de la creación del dominio. De manera predeterminada, esta cuenta es miembro de los grupos administradores de dominio y administradores en el dominio y, si este es el dominio raíz del bosque, la cuenta también es miembro del grupo de administradores de empresa. El uso de la cuenta de administrador local de un dominio solo debe reservarse para las actividades iniciales de compilación y, eventualmente, para escenarios de recuperación ante desastres. Para asegurarse de que se puede usar una cuenta predefinida de administrador a fin de realizar reparaciones en caso de que no se pueda usar ninguna otra cuenta, no debe cambiar la pertenencia predeterminada de la cuenta de administrador en ningún dominio del bosque. En su lugar, debe seguir las instrucciones para ayudar a proteger la cuenta de administrador en cada dominio del bosque. En el Anexo D: Protección de cuentas predefinidas de administrador en Active Directory se proporcionan instrucciones detalladas para implementar estos controles.

Controles para cuentas predefinidas de administrador

El objetivo de implementar la configuración que se describe aquí es evitar que la cuenta de administrador (no un grupo) de cada dominio se pueda usar a menos que se inviertan varios controles. Al implementar estos controles y supervisar las cuentas de administrador para los cambios, puede reducir significativamente la probabilidad de éxito de un ataque utilizando la cuenta de administrador de un dominio. En la cuenta de administrador de cada dominio del bosque, debe configurar las opciones siguientes.

Habilitación de la marca "La cuenta es importante y no se puede delegar" en la cuenta

De manera predeterminada, se pueden delegar todas las cuentas de Active Directory. La delegación permite que un equipo o servicio presente las credenciales de una cuenta que se haya autenticado en el equipo o servicio en otros equipos para obtener servicios en nombre de la cuenta. Cuando habilita el atributo La cuenta es importante y no se puede delegar en una cuenta basada en dominio, las credenciales de la cuenta no se pueden presentar a otros equipos o servicios de la red, lo que limita los ataques que aprovechan la delegación para usar las credenciales de la cuenta en otros sistemas.

Habilitación de la marca "La tarjeta inteligente es necesaria para un inicio de sesión interactivo" en la cuenta

Cuando habilita el atributo La tarjeta inteligente es necesaria para un inicio de sesión interactivo en una cuenta, Windows restablece la contraseña de la cuenta a un valor aleatorio de 120 caracteres. Al establecer esta marca en cuentas predefinidas de administrador, se asegura de que la contraseña de la cuenta no solo es larga y compleja, sino que tampoco la conoce ningún usuario. Técnicamente no es necesario crear tarjetas inteligentes para las cuentas antes de habilitar este atributo pero, de ser posible, se deben crear tarjetas inteligentes para cada cuenta de administrador antes de configurar las restricciones de cuenta y las tarjetas inteligentes deben almacenarse en ubicaciones seguras.

Aunque el establecimiento de la marca La tarjeta inteligente es necesaria para un inicio de sesión interactivo restablece la contraseña de la cuenta, esto no impide que un usuario con derechos restablezca la contraseña de la cuenta estableciendo la cuenta en un valor conocido y usando el nombre de la cuenta y la contraseña nueva para acceder a los recursos de la red. Por este motivo, debe implementar los controles adicionales siguientes en la cuenta.

Configuración de GPO para restringir cuentas de administrador de dominios en sistemas unidos a un dominio

Aunque deshabilitar la cuenta de administrador en un dominio hace que, en la práctica, la cuenta sea inutilizable, debe implementar restricciones adicionales en caso de que la cuenta esté habilitada de forma involuntaria o malintencionada. Aunque, en última instancia, la cuenta de administrador puede revertir estos controles, el objetivo es crear controles que ralenticen el progreso de un atacante y limiten el daño que pueda provocar a la cuenta.

En uno o varios GPO que cree y vincule a unidades organizativas de servidor miembro y estación de trabajo en cada dominio, agregue la cuenta de administrador de cada dominio a los derechos de usuario siguientes en Configuración del equipo\Directivas\Configuración de Windows\Configuración de seguridad\Directivas locales\Asignaciones de derechos de usuario:

• Denegar el acceso desde la red a este equipo
• Denegación del inicio de sesión como trabajo por lotes
• Denegar el inicio de sesión como servicio
• Denegar inicio de sesión a través de Servicios de Escritorio remoto

Nota

Al agregar cuentas de administrador locales a esta configuración, debe especificar si va a configurar cuentas de administrador locales o cuentas de administrador de dominios. Por ejemplo, para agregar la cuenta de administrador local del dominio NWTRADERS a estos derechos de denegación, debe escribir la cuenta como NWTRADERS\Administrator o ir a la cuenta de administrador local del dominio NWTRADERS. Si escribe Administrador en esta configuración de derechos de usuario en el Editor de objetos de directiva de grupo, restringirá la cuenta de administrador local en cada uno de los equipos a los que se aplique el GPO.

Se recomienda restringir las cuentas de administrador locales en servidores miembro y estaciones de trabajo de la misma manera que se hace con las cuentas de administrador basadas en dominio. Por lo tanto, lo normal será agregar la cuenta de administrador para cada dominio del bosque y la cuenta de administrador de los equipos locales a esta configuración de derechos de usuario.

Configuración de GPO para restringir cuentas de administrador en controladores de dominio

En cada dominio del bosque, se debe modificar la directiva de controladores de dominio predeterminados o una directiva vinculada a la unidad organizativa de controladores de dominio para agregar la cuenta de administrador de cada dominio a los siguientes derechos de usuario en Configuración del equipo\Directivas\Configuración de Windows\Configuración de seguridad\Directivas locales\Asignaciones de derechos de usuario:

• Denegar el acceso desde la red a este equipo
• Denegación del inicio de sesión como trabajo por lotes
• Denegar el inicio de sesión como servicio
• Denegar inicio de sesión a través de Servicios de Escritorio remoto

Nota

Esta configuración garantizará que la cuenta de administrador local no se pueda usar para conectarse a un controlador de dominio, aunque la cuenta, si está habilitada, puede iniciar sesión localmente en controladores de dominio. Como esta cuenta solo debe habilitarse y usarse en escenarios de recuperación ante desastres, se prevé que estará disponible el acceso físico a un controlador de dominio como mínimo, o que se puedan usar otras cuentas con permisos para acceder a los controladores de dominio de forma remota.

Configuración de la auditoría de cuentas predefinidas de administrador

Cuando haya protegido la cuenta de administrador de cada dominio y la haya deshabilitado, debe configurar la auditoría para supervisar los cambios en la cuenta. Si la cuenta está habilitada, se restablece su contraseña o se realizan otras modificaciones, se deben enviar alertas a los usuarios o equipos responsables de la administración de AD DS, y también a los equipos de respuesta a incidentes de su organización.

Protección de administradores, administradores de dominio y grupos de administradores de empresa

Protección de grupos de administradores de empresa

El grupo de administradores de empresa, que se hospeda en el dominio raíz del bosque, no debe contener usuarios en el día a día, con la posible excepción de la cuenta de administrador local del dominio, siempre que esté protegida, tal y como se ha descrito anteriormente y en el Anexo D: Protección de cuentas predefinidas de administrador en Active Directory.

Cuando se requiere acceso de EA, los usuarios cuyas cuentas requieren derechos y permisos de EA deben situarse temporalmente en el grupo de administradores de empresa. Aunque los usuarios usan las cuentas con privilegios elevados, sus actividades se deben auditar y, preferiblemente, llevar a cabo con un usuario que realice los cambios y otro que los observe. De este modo, se minimiza la probabilidad de que se produzca una configuración incorrecta o un uso incorrecto involuntario. Cuando se hayan completado las actividades, las cuentas se deben quitar del grupo de EA. Esto se puede lograr mediante procedimientos manuales y procesos documentados, software de administración de identidades o de acceso con privilegios de terceros (PIM/PAM), o una combinación de ambos. Las instrucciones para crear cuentas que se pueden usar a fin de controlar la pertenencia a grupos con privilegios en Active Directory se proporcionan en Cuentas atractivas para el robo de credenciales y en el Anexo I: Creación de cuentas de administración para cuentas protegidas y grupos en Active Directory se proporcionan instrucciones detalladas.

Los administradores de empresa son, de manera predeterminada, miembros del grupo de cuentas predefinidas de administrador en cada dominio del bosque. Quitar el grupo de administradores de empresa de los grupos de administradores de cada dominio es una modificación inapropiada porque, en caso de un escenario de recuperación ante desastres de bosque, es probable que se requieran derechos de EA. Si el grupo de administradores de empresa se ha quitado de los grupos de administradores de un bosque, se debe agregar al grupo de administradores de cada dominio y se deben implementar los controles adicionales siguientes:

• Tal como se ha descrito anteriormente, el grupo de administradores de empresa no debe contener usuarios en el día a día, con la posible excepción de la cuenta de administrador del dominio raíz del bosque, que se debe proteger según se describe en el Apéndice D: Protección de cuentas predefinidas de administrador en Active Directory.
• En los GPO vinculados a unidades organizativas que contienen servidores miembro y estaciones de trabajo de cada dominio, el grupo de EA debe agregarse a los derechos de usuario siguientes:
  • Denegar el acceso desde la red a este equipo
  • Denegación del inicio de sesión como trabajo por lotes
  • Denegar el inicio de sesión como servicio
  • Denegar el inicio de sesión localmente
  • Denegar inicio de sesión mediante Servicios de Escritorio remoto

Esto impedirá que los miembros del grupo de EA inicien sesión en servidores miembro y estaciones de trabajo. Si los servidores de salto se usan para administrar controladores de dominio y Active Directory, asegúrese de que este tipo de servidores se encuentran en una unidad organizativa a la que los GPO restrictivos no están vinculados.

• La auditoría debe configurarse para enviar alertas si se realizan modificaciones en las propiedades o la pertenencia del grupo de EA. Estas alertas deben enviarse, como mínimo, a los usuarios o equipos responsables de la administración y la respuesta a incidentes de Active Directory. También debe definir procesos y procedimientos para rellenar temporalmente el grupo de EA, incluidos los procedimientos de notificación cuando se realiza una población legítima del grupo.

Protección de grupos de administradores de dominio

Como sucede con el grupo de administradores de empresa, la pertenencia a grupos de administradores de dominio solo debe ser necesaria en escenarios de compilación o recuperación ante desastres. No debe haber cuentas de usuario diarias en el grupo de DA con la excepción de la cuenta de administrador local para el dominio, si se ha protegido tal como se describe en el Anexo D: Protección de cuentas predefinidas de administrador en Active Directory.

Cuando se requiere el acceso de DA, las cuentas que necesitan este nivel de acceso deben situarse temporalmente en el grupo de DA para el dominio en cuestión. Aunque los usuarios usan las cuentas con privilegios elevados, las actividades se deben auditar y, preferiblemente, llevar a cabo con un usuario que realice los cambios y otro que los observe para minimizar la probabilidad de una configuración incorrecta o un uso incorrecto involuntario. Cuando se hayan completado las actividades, las cuentas deben quitarse del grupo de administradores de dominio. Esto se puede lograr mediante procedimientos manuales y procesos documentados, software de administración de identidades o de acceso con privilegios de terceros (PIM/PAM), o una combinación de ambos. Las instrucciones para crear cuentas que se pueden usar a fin de controlar la pertenencia a grupos con privilegios en Active Directory se proporcionan en el Anexo I: Creación de cuentas de administración para cuentas protegidas y grupos en Active Directory.

Los administradores de dominio son, de manera predeterminada, miembros de los grupos de administradores locales en todos los servidores miembro y estaciones de trabajo de sus respectivos dominios. Este anidamiento predeterminado no se debe modificar porque afecta a la compatibilidad y a las opciones de recuperación ante desastres. Si los grupos de administradores de dominio se han quitado de los grupos de administradores locales de los servidores miembro, se deben agregar al grupo de administradores en cada servidor miembro y estación de trabajo del dominio mediante la configuración de grupo restringido en los GPO vinculados. También se deben implementar los controles generales siguientes, que se describen en profundidad en el Anexo F: Protección de grupos de administradores de dominio en Active Directory.

Para el grupo de administradores de dominio de cada dominio del bosque:

1. Quite todos los miembros del grupo de DA, con la posible excepción de la cuenta predefinida de administrador del dominio, si se ha protegido tal como se describe en el Anexo D: Protección de cuentas predefinidas de administrador en Active Directory.

2. En los GPO vinculados a unidades organizativas que contienen servidores miembro y estaciones de trabajo de cada dominio, el grupo de DA debe agregarse a los derechos de usuario siguientes:

   • Denegar el acceso desde la red a este equipo
   • Denegación del inicio de sesión como trabajo por lotes
   • Denegar el inicio de sesión como servicio
   • Denegar el inicio de sesión localmente
   • Denegar inicio de sesión a través de Servicios de Escritorio remoto

   Esto impedirá que los miembros del grupo de DA inicien sesión en servidores miembro y estaciones de trabajo. Si los servidores de salto se usan para administrar controladores de dominio y Active Directory, asegúrese de que este tipo de servidores se encuentran en una unidad organizativa a la que los GPO restrictivos no están vinculados.

3. La auditoría debe configurarse para enviar alertas si se realizan modificaciones en las propiedades o la pertenencia del grupo de DA. Estas alertas deben enviarse, como mínimo, a los usuarios o equipos responsables de la administración y la respuesta a incidentes de AD DS. También debe definir procesos y procedimientos para rellenar temporalmente el grupo de DA, incluidos los procedimientos de notificación cuando se realiza una población legítima del grupo.

Protección de grupos de administradores en Active Directory

Tal como sucede con los grupos de EA y DA, la pertenencia al grupo de administradores (BA) solo debe ser necesaria en escenarios de compilación o recuperación ante desastres. No debe haber cuentas de usuario diarias en el grupo de administradores con la excepción de la cuenta de administrador local para el dominio, si se ha protegido tal como se describe en el Anexo D: Protección de cuentas predefinidas de administrador en Active Directory.

Cuando se requiere el acceso de administradores, las cuentas que necesitan este nivel de acceso deben situarse temporalmente en el grupo de administradores para el dominio en cuestión. Aunque los usuarios usan las cuentas con privilegios elevados, las actividades se deben auditar y, preferiblemente, llevar a cabo con un usuario que realice los cambios y otro que los observe para minimizar la probabilidad de una configuración incorrecta o un uso incorrecto involuntario. Cuando se hayan completado las actividades, las cuentas deben quitarse inmediatamente del grupo de administradores. Esto se puede lograr mediante procedimientos manuales y procesos documentados, software de administración de identidades o de acceso con privilegios de terceros (PIM/PAM), o una combinación de ambos.

Los administradores son, de manera predeterminada, los propietarios de la mayoría de los objetos de AD DS en sus respectivos dominios. La pertenencia a este grupo puede ser necesaria en escenarios de compilación y recuperación ante desastres en los que se requiera la propiedad o la capacidad de tomar posesión de los objetos. Además, los miembros de DA y EA heredan una serie de sus derechos y permisos en virtud de su pertenencia predeterminada al grupo de administradores. Para grupos con privilegios en Active Directory no se debe modificar el anidamiento predeterminado de grupos y el grupo de administradores de cada dominio se debe proteger, tal como se describe en el Anexo G: Protección de grupos de administradores en Active Directory y en las instrucciones generales siguientes.

1. Quite todos los miembros del grupo de administradores, con la posible excepción de la cuenta de administrador local del dominio, si se ha protegido tal como se describe en el Anexo D: Protección de cuentas predefinidas de administrador en Active Directory.

2. Los miembros del grupo de administradores del dominio nunca deben tener que iniciar sesión en servidores miembro o estaciones de trabajo. En uno o varios GPO vinculados a la estación de trabajo y a las unidades organizativas del servidor miembro de cada dominio, el grupo de administradores debe agregarse a los derechos de usuario siguientes:

   • Denegar el acceso desde la red a este equipo
   • Denegar el inicio de sesión como trabajo por lotes,
   • Denegar el inicio de sesión como servicio
   • Esto impedirá que los miembros del grupo de administradores se usen para iniciar sesión o conectarse a servidores miembro o estaciones de trabajo (a menos que se produzcan infracciones por primera vez en varios controles), donde sus credenciales se podrían copiar en caché y, por lo tanto, poner en peligro. Una cuenta con privilegios nunca debe usarse para iniciar sesión en un sistema con menos privilegios; la aplicación de estos controles ofrece protección frente a una serie de ataques.

3. En la unidad organizativa de los controladores de dominio de cada dominio del bosque, al grupo de administradores se le deben conceder los derechos de usuario siguientes (si aún no tienen estos derechos), lo que permitirá a los miembros del grupo de administradores realizar las funciones necesarias para un escenario de recuperación ante desastres de todo el bosque:

   • Obtener acceso a este equipo desde la red
   • Permitir el inicio de sesión local
   • Permitir inicio de sesión a través de Servicios de Escritorio remoto

4. La auditoría debe configurarse para enviar alertas si se realizan modificaciones en las propiedades o la pertenencia del grupo de administradores. Estas alertas deben enviarse, como mínimo, a los miembros del equipo responsable de la administración de AD DS. También se deben enviar alertas a los miembros del equipo de seguridad y se deben definir procedimientos para modificar la pertenencia del grupo de administradores. En concreto, estos procesos deben incluir un procedimiento por el que el equipo de seguridad recibe una notificación cuando se va a modificar el grupo de administradores, para que el envío de alertas sea un evento previsto y no se genere una alarma. Además, el equipo de seguridad recibe una notificación cuando ha finalizado el uso del grupo de administradores y se deben implementar las cuentas usadas que se han quitado del grupo.

Nota

Al implementar restricciones en el grupo de administradores de GPO, Windows aplica la configuración a los miembros del grupo de administradores local de un equipo, además del grupo de administradores del dominio. Por lo tanto, debe tener precaución al implementar restricciones en el grupo de Administradores. Aunque se recomienda prohibir inicios de sesión de red, por lotes y del servicio para los miembros del grupo de administradores siempre que sea factible su implementación, no debe restringir los inicios de sesión locales ni los que se realizan mediante Servicios de Escritorio remoto. El bloqueo de estos tipos de inicio de sesión puede provocar que los miembros del grupo de administradores local bloqueen la administración legítima de un equipo. En la siguiente captura de pantalla se muestran las opciones de configuración que bloquean el uso incorrecto de las Cuentas predefinidas de administradores locales y de dominio, además del uso incorrecto de los Grupos predefinidos de administradores locales o de dominio. Tenga en cuenta que el derecho de usuario Denegar inicio de sesión a través de Servicios de Escritorio remoto no incluye al grupo de Administradores, ya que incluirlo en esta configuración también bloquearía estos inicios de sesión para las cuentas que son miembros del grupo de Administradores del equipo local. Si los servicios de los equipos están configurados para ejecutarse en el contexto de cualquiera de los grupos con privilegios descritos en esta sección, la implementación de esta configuración puede provocar errores en los servicios y las aplicaciones. Por lo tanto, al igual que con todas las recomendaciones de esta sección, debe probar a fondo la aplicabilidad de la configuración en su entorno.

Controles de acceso basados en roles (RBAC) para Active Directory

Por lo general, los controles de acceso basados en roles (RBAC) son un mecanismo para agrupar usuarios y proporcionar acceso a los recursos en función de las reglas de negocios. En el caso de Active Directory, la implementación de RBAC para AD DS es el proceso de creación de roles a los que se delegan derechos y permisos a fin de permitir que los miembros del rol realicen tareas administrativas diarias sin concederles muchos privilegios. RBAC para Active Directory se puede diseñar e implementar mediante herramientas e interfaces nativas, aprovechando el software que puede que ya disponga, comprando productos de terceros o con cualquier combinación de estos enfoques. En esta sección no se proporcionan instrucciones paso a paso a fin de implementar RBAC para Active Directory, sino que se describen los factores que debe tener en cuenta al elegir un enfoque para implementar RBAC en las instalaciones de AD DS.

Enfoques nativos de RBAC para Active Directory

En la implementación de RBAC más sencilla, puede implementar roles como grupos de AD DS y delegar derechos y permisos a los grupos que les permiten realizar las tareas administrativas diarias en el ámbito designado del rol.

En algunos casos, se pueden usar grupos de seguridad existentes en Active Directory para conceder derechos y permisos adecuados a un puesto de trabajo. Por ejemplo, si los empleados específicos de la organización de TI son los responsables de la administración y el mantenimiento de las zonas DNS y los registros, delegar esas responsabilidades puede ser tan sencillo como crear una cuenta para cada administrador de DNS y agregarla al grupo de administradores de DNS en Active Directory. El grupo de administradores de DNS, a diferencia de los grupos con más privilegios, tiene pocos derechos eficaces en Active Directory, aunque a los miembros de este grupo se les han delegado permisos que les permiten administrar DNS y siguen estando sujetos a riesgos y abusos que podrían dar lugar a la elevación de privilegios.

En otros casos, es posible que tenga que crear grupos de seguridad, así como delegar derechos y permisos en objetos de Active Directory, objetos del sistema de archivos y objetos del registro para permitir que los miembros de los grupos realicen tareas administrativas designadas. Por ejemplo, si los operadores del departamento de soporte técnico son los responsables de restablecer contraseñas olvidadas, ayudar a los usuarios con problemas de conectividad y solucionar problemas de configuración de la aplicación, es posible que tenga que combinar la configuración de delegación en objetos de usuario de Active Directory con privilegios que permitan a los usuarios de este departamento conectarse de forma remota a los equipos de los usuarios para ver o modificar la configuración de los usuarios. Para cada rol que defina, debe determinar lo siguiente:

1. Qué tareas realizan los miembros del rol diariamente y cuáles se realizan con menos frecuencia.
2. En qué sistemas y aplicaciones se deben conceder derechos y permisos a los miembros de un rol.
3. A qué usuarios se les debe conceder la pertenencia a un rol.
4. Cómo se realizará la administración de las pertenencias a roles.

En muchos entornos, la creación manual de controles de acceso basados en roles para la administración de un entorno de Active Directory puede ser difícil de implementar y mantener. Si tiene roles y responsabilidades claramente definidos para la administración de la infraestructura de TI, es posible que quiera aprovechar herramientas adicionales a fin de permitirle crear una implementación de RBAC nativa administrable. Por ejemplo, si Forefront Identity Manager (FIM) está en uso en su entorno, puede usarlo para automatizar la creación y el rellenado de roles administrativos, lo que puede facilitar la administración continua. Si usa Microsoft Endpoint Configuration Manager y System Center Operations Manager (SCOM), puede usar roles específicos de la aplicación para delegar funciones de administración y supervisión, así como aplicar una configuración y auditoría coherentes en todos los sistemas del dominio. Si ha implementado una infraestructura de clave pública (PKI), puede emitir y requerir tarjetas inteligentes para el personal de TI responsable de administrar el entorno. Con la administración de credenciales de FIM (FIM CM), puede incluso combinar la administración de roles y credenciales para el personal administrativo.

En otros casos, para una organización puede ser preferible plantearse la implementación de software de RBAC de terceros que proporcione una función "lista para usar". Hay varios proveedores que ofrecen soluciones comerciales listas para la venta (COTS) de RBAC para Active Directory, Windows y sistemas operativos distintos de Windows. Al elegir entre soluciones nativas y productos de terceros, debe tener en cuenta los factores siguientes:

1. Presupuesto: al invertir en el desarrollo de RBAC mediante software y herramientas que puede que ya sean de su propiedad, puede reducir los costos de software implicados en la implementación de una solución. Pero a menos que tenga personal con experiencia en la creación e implementación de soluciones de RBAC nativas, es posible que tenga que contratar a recursos de consultoría para desarrollar la solución. Debe sopesar cuidadosamente los costos anticipados de una solución personalizada con los costos para implementar una solución "lista para usar", especialmente si el presupuesto es limitado.
2. Composición del entorno de TI: si el entorno se compone principalmente de sistemas Windows, o si ya está utilizando Active Directory para la administración de cuentas y sistemas distintos de Windows, las soluciones nativas personalizadas pueden ofrecerle la solución óptima para sus necesidades. Si la infraestructura contiene muchos sistemas que no ejecutan Windows y no administra Active Directory, es posible que tenga que tener en cuenta las opciones de administración de sistemas distintos de Windows de forma independiente del entorno de Active Directory.
3. Modelo de privilegios en la solución: si un producto se basa en la colocación de sus cuentas de servicio en grupos con privilegios elevados en Active Directory y no ofrece opciones que no requieran la concesión de privilegios excesivos al software de RBAC, significa que no ha reducido realmente la superficie expuesta a ataques de Active Directory, sino que solo ha cambiado la composición de los grupos con más privilegios en el directorio. A menos que un proveedor de aplicaciones pueda proporcionar controles para las cuentas de servicio que minimicen la probabilidad de que las cuentas se vean comprometidas y que se usen de forma malintencionada, es posible que quiera tener en cuenta otras opciones.

Privileged Identity Management

Privileged Identity Management (PIM), a veces denominado administración de cuentas con privilegios (PAM) o administración de credenciales con privilegios (PCM) es el diseño, la construcción y la implementación de enfoques para administrar cuentas con privilegios en la infraestructura. Por lo general, PIM proporciona mecanismos por los que se conceden derechos temporales y los permisos necesarios para realizar funciones de corrección de compilación o interrupción, en lugar de que los privilegios se asocien a las cuentas de forma permanente. Tanto si la función de PIM se crea manualmente como si se implementa mediante la implementación de software de terceros, puede que estén disponibles una o varias de las características siguientes:

• "Almacenes" de credenciales, donde las contraseñas de las cuentas con privilegios se han "desprotegido" y se les ha asignado una contraseña inicial y, después, se han "protegido" cuando se han completado las actividades, momento en el cual las contraseñas se restablecen de nuevo en las cuentas.
• Restricciones controladas por tiempo en el uso de credenciales con privilegios.
• Credenciales de un solo uso.
• Concesión de privilegios generada por el flujo de trabajo con supervisión e informes de actividades realizadas y eliminación automática de privilegios cuando las actividades se completan o han expirado el tiempo asignado.
• Reemplazo de credenciales codificadas de forma rígida, como nombres de usuario y contraseñas en scripts con interfaces de programación de aplicaciones (API) que permiten recuperar las credenciales de los almacenes según sea necesario.
• Administración automática de credenciales de cuentas de servicio.

Creación de cuentas sin privilegios para administrar cuentas con privilegios

Uno de los desafíos en la administración de cuentas con privilegios es que, de manera predeterminada, las cuentas que pueden administrar cuentas y grupos protegidos y con privilegios son cuentas con privilegios y protegidas. Si implementa soluciones de RBAC y PIM adecuadas para la instalación de Active Directory, las soluciones pueden incluir enfoques que le permitan eliminar eficazmente el rellenado de la pertenencia de los grupos con más privilegios en el directorio, rellenando los grupos solo temporalmente y cuando sea necesario.

Pero si implementa RBAC nativo y PIM, debe considerar la posibilidad de crear cuentas que no tengan privilegios y cuya única función sea la de rellenar y eliminar el rellenado de grupos con privilegios en Active Directory cuando sea necesario. El Anexo I: Creación de cuentas de administración para cuentas protegidas y grupos en Active Directory proporciona instrucciones paso a paso que puede usar a fin de crear cuentas con esta finalidad.

Implementación de controles de autenticación sólidos

Ley número seis: ahí fuera hay alguien intentando adivinar sus contraseñas. - 10 leyes inmutables sobre la administración de seguridad

Los ataques pass-the-hash y otros ataques de robo de credenciales no se circunscriben solo a los sistemas operativos Windows ni son nuevos. El primer ataque pass-the-hash se creó en 1997. Pero históricamente estos ataques requerían herramientas personalizadas, su éxito era cuestión de suerte y requerían que los atacantes contaran con un nivel relativamente alto de aptitudes. La introducción de herramientas disponibles de forma gratuita y fáciles de usar que extraen de forma nativa las credenciales ha provocado un aumento exponencial del número de los ataques de robo de credenciales en los últimos años y del éxito de estos. Pero los ataques de robo de credenciales no son los únicos mecanismos cuyo objetivo son las credenciales y con los que estas se ponen en peligro.

Aunque debe implementar controles para ayudarle a protegerse frente a ataques de robo de credenciales, también debe identificar las cuentas de su entorno a las que es más probable que se dirijan los atacantes e implementar controles de autenticación sólidos para esas cuentas. Si las cuentas con más privilegios usan autenticación de factor único, como nombres de usuario y contraseñas (ambos tipos son "información que conoce", que es un factor de autenticación), esas cuentas tienen una protección débil. Todo lo que un atacante necesita es conocer el nombre de usuario y la contraseña asociada a la cuenta; con esto, los ataques pass-the-hash no son necesarios para que el atacante se pueda autenticar como el usuario en cualquier sistema que acepte credenciales de factor único.

Si bien la implementación de la autenticación multifactor no le protege frente a ataques pass-the-hash, sí que lo hace la implementación de la autenticación multifactor en combinación con sistemas protegidos. En Implementación de hosts administrativos seguros se proporciona más información sobre la implementación de sistemas protegidos y en las secciones siguientes se describen las opciones de autenticación.

Controles generales de autenticación

Si aún no ha implementado la autenticación multifactor como, por ejemplo, las tarjetas inteligentes, plantéese hacerlo. Las tarjetas inteligentes implementan la protección mediante hardware de claves privadas en un par de claves pública-privada, lo que evita que se obtenga acceso a la clave privada de un usuario o que se utilice, a menos que este presente el PIN, el código de acceso o un identificador biométrico correspondiente a la tarjeta inteligente. Incluso si un registrador de pulsaciones de teclas en un equipo en riesgo intercepta el PIN o el código de acceso de un usuario, la tarjeta también debe estar presente físicamente para que un atacante vuelva a utilizar el PIN o el código de acceso.

En los casos en que la resistencia del usuario dificulte la implementación de contraseñas largas y complejas, las tarjetas inteligentes proporcionan un mecanismo mediante el cual los usuarios pueden implementar PIN o códigos de acceso relativamente simples sin que las credenciales queden vulnerables ante ataques por fuerza bruta o de tablas arcoiris. Los PIN de las tarjetas inteligentes no se almacenan en Active Directory o en las bases de datos SAM locales, a pesar de que los hashes de credenciales pueden seguir almacenados en la memoria protegida de LSASS en los equipos donde se usaron las tarjetas inteligentes para realizar la autenticación.

Controles adicionales para cuentas VIP

Otra ventaja de implementar tarjetas inteligentes u otros mecanismos de autenticación basados en certificados es la capacidad de aprovechar la Seguridad del mecanismo de autenticación para proteger los datos confidenciales que son accesibles para los usuarios VIP. La Seguridad del mecanismo de autenticación está disponible en dominios en los que el nivel funcional está establecido en Windows Server 2012 o Windows Server 2008 R2. Cuando está habilitada, la Seguridad del mecanismo de autenticación agrega una pertenencia de grupo global designada por el administrador al token Kerberos de un usuario cuando las credenciales del usuario se autentican durante el inicio de sesión mediante un método de inicio de sesión basado en certificados.

Esto permite a los administradores de recursos controlar el acceso a los recursos, como archivos, carpetas e impresoras, en función de si el usuario inicia sesión con un método basado en certificados, además del tipo de certificado utilizado. Por ejemplo, cuando un usuario inicia sesión con una tarjeta inteligente, el acceso del usuario a los recursos de la red se puede especificar como distinto de lo que es el acceso cuando no usa una tarjeta inteligente (es decir, cuando el usuario inicia sesión escribiendo un nombre de usuario y una contraseña). A fin de obtener más información sobre la Seguridad del mecanismo de autenticación, vea la Guía paso a paso de la Seguridad del mecanismo de autenticación para AD DS en Windows Server 2008 R2.

Configuración de la autenticación de la cuenta con privilegios

En Active Directory para todas las cuentas administrativas, habilite el atributo Requerir tarjeta inteligente para un inicio de sesión interactivo y audite los cambios en (como mínimo) alguno de los atributos de la pestaña Cuenta de los objetos de usuario administrativo de la cuenta (por ejemplo, cn, name, sAMAccountName, userPrincipalName y userAccountControl).

Aunque establecer la opción Requerir tarjeta inteligente para un inicio de sesión interactivo en las cuentas restablece la contraseña de la cuenta a un valor aleatorio de 120 caracteres y requiere tarjetas inteligentes para inicios de sesión interactivos, los usuarios con permisos que les permitan cambiar las contraseñas de las cuentas pueden seguir sobrescribiendo el atributo y las cuentas se pueden usar para establecer inicios de sesión no interactivos solo con el nombre de usuario y la contraseña.

En otros casos, en función de la configuración de cuentas en Active Directory y la configuración de certificados en Servicios de certificados de Active Directory (AD CS) o una PKI de terceros, los atributos de nombre principal de usuario (UPN) para las cuentas administrativas o VIP pueden ser el objetivo de un tipo específico de ataque, tal como se describe aquí.

Secuestro de UPN para suplantación electrónica de certificado

Aunque en este documento no se ofrece una explicación en profundidad de los ataques contra infraestructuras de clave pública (PKIs), los ataques contra las PKI públicas y privadas han aumentado exponencialmente desde 2008. Las infracciones de PKI públicas se han hecho mucho eco mediático, pero los ataques contra las PKI internas de las organizaciones son quizá más numerosas. Un ataque de este tipo utiliza Active Directory y los certificados para permitir a un atacante suplantar las credenciales de otras cuentas de forma que pueda ser difícil de detectar.

Cuando se presenta un certificado para la autenticación en un sistema unido a un dominio, el contenido del atributo Firmante o Nombre alternativo del firmante (SAN) del certificado se usan para asignar el certificado a un objeto de usuario en Active Directory. Según el tipo de certificado y de cómo se construye, el atributo Firmante de un certificado normalmente contiene el nombre común (CN) de un usuario, tal como se muestra en la captura de pantalla siguiente.

De manera predeterminada, Active Directory construye el CN de un usuario concatenando el nombre + " " + apellidos de la cuenta. Pero los componentes de CN de los objetos de usuario de Active Directory no son necesarios ni se garantiza que sean únicos, y mover una cuenta de usuario a otra ubicación en el directorio cambia el nombre distintivo (DN) de la cuenta, que es la ruta de acceso completa al objeto del directorio, tal como se muestra en el panel inferior de la captura de pantalla anterior.

Como no está garantizado que los nombres del firmante del certificado sean estáticos o únicos, el contenido del nombre alternativo del firmante se usa a menudo para buscar el objeto de usuario en Active Directory. El atributo SAN para los certificados emitidos a los usuarios de entidades de certificación empresariales (CA integradas en Active Directory) normalmente contiene el UPN o la dirección de correo electrónico del usuario. Como está garantizado que los UPN son únicos en un bosque de AD DS, la localización de un objeto de usuario por UPN se realiza normalmente como parte de la autenticación, con certificados implicados en el proceso de autenticación o sin estos.

Los atacantes pueden aprovechar el uso de UPN en atributos SAN en certificados de autenticación para obtener certificados fraudulentos. Si un atacante ha puesto en peligro una cuenta que tiene la capacidad de leer y escribir UPN en objetos de usuario, el ataque se implementa de la siguiente manera:

El atributo UPN de un objeto de usuario (como un usuario VIP) se cambia temporalmente a otro valor. En este punto también se pueden cambiar el atributo de nombre de cuenta SAM y el CN, aunque esto no suele ser necesario por los motivos descritos anteriormente.

Cuando se ha cambiado el atributo UPN de la cuenta objetivo, se cambia una cuenta de usuario obsoleta habilitada o un atributo UPN de la cuenta de usuario recién creada al valor que se asignó originalmente a esta cuenta objetivo. Las cuentas de usuario obsoletas y habilitadas son cuentas que no han iniciado sesión durante un largo periodo de tiempo, pero que no se han deshabilitado. Son el objetivo de atacantes que pretenden "ocultarse a simple vista" por los motivos siguientes:

1. Dado que la cuenta está habilitada, pero no se ha usado recientemente, es poco probable que el uso de la cuenta desencadene alertas de la manera en que lo haría la habilitación de una cuenta de usuario deshabilitada.
2. El uso de una cuenta existente no requiere la creación de una cuenta de usuario que el personal administrativo pueda advertir.
3. Las cuentas de usuario obsoletas que todavía están habilitadas suelen ser miembros de varios grupos de seguridad y se les concede acceso a los recursos de la red, lo que simplifica el acceso y la "integración" a una población de usuarios existente.

La cuenta de usuario en la que se ha configurado ahora el UPN objetivo se usa para solicitar uno o varios certificados de Servicios de certificados de Active Directory.

Cuando se han obtenido certificados para la cuenta del atacante, los UPN de la cuenta "nueva" y la cuenta objetivo vuelven a sus valores originales.

El atacante ahora tiene uno o varios certificados que se pueden presentar para la autenticación en recursos y aplicaciones como si el usuario fuera el usuario VIP cuya cuenta se modificó temporalmente. Aunque en este documento no se detalla una explicación completa de todas las formas en que los atacantes pueden dirigirse a certificados y PKI, este mecanismo de ataque se proporciona a fin de ilustrar por qué debe supervisar las cuentas con privilegios y VIP en AD DS para los cambios, especialmente en cualquiera de los atributos de la pestaña Cuenta de la cuenta (por ejemplo, cn, name, sAMAccountName, userPrincipalName y userAccountControl). Además de supervisar las cuentas, debe restringir quién puede modificarlas a un conjunto de usuarios administrativos lo más pequeño posible. Del mismo modo, las cuentas de los usuarios administrativos se deben proteger y supervisar para detectar cambios no autorizados.