Security in Active Directory

A medida que hemos avanzado en este módulo, hemos analizado las numerosas características y funcionalidades integradas en Active Directory. Todas ellas están construidas en torno a la premisa de la gestión centralizada y la capacidad de compartir información rápidamente, a voluntad, con una gran base de usuarios. Active Directory puede considerarse inseguro por diseño debido a esto. Una instalación predeterminada de Active Directory carecerá de muchas medidas de hardening, configuraciones y herramientas que pueden utilizarse para asegurar una implementación de AD. Cuando pensamos en ciberseguridad, una de las primeras cosas que surgen es el equilibrio entre Confidencialidad, Integridad y Disponibilidad, también conocido como el CIA Triad. Encontrar este equilibrio es difícil, y AD se inclina fuertemente hacia la Availability y la Confidentiality en su núcleo.

CIA Triad

Podemos ayudar a equilibrar la balanza utilizando las características integradas de Microsoft que pueden habilitarse o ajustarse para endurecer AD contra ataques comunes. La lista a continuación no es exhaustiva. Muchos otros principios generales de hardening de seguridad deben estar en su lugar dentro de una organización para asegurar un enfoque adecuado de defense-in-depth (tener un inventario de activos preciso, parches de vulnerabilidades, gestión de configuración, protección de endpoints, entrenamiento en concienciación de seguridad, segmentación de red, etc.). Esta sección puede considerarse como las mejores prácticas mínimas generales de seguridad en AD que cualquier organización debería adoptar. Profundizaremos en la Defensa de Active Directory en un módulo posterior. Vamos a sumergirnos y comenzar con algunas medidas generales de hardening para AD.

General Active Directory Hardening Measures

La Microsoft Local Administrator Password Solution (LAPS) se utiliza para aleatorizar y rotar las contraseñas del administrador local en hosts Windows y prevenir el movimiento lateral.

LAPS

Las cuentas pueden configurarse para que su contraseña se rote en un intervalo fijo (por ejemplo, cada 12 horas, 24 horas, etc.). Esta herramienta gratuita puede ser útil para reducir el impacto de un host comprometido en un entorno AD. Las organizaciones no deberían depender únicamente de herramientas como esta. Sin embargo, cuando se combina con otras medidas de hardening y mejores prácticas de seguridad, puede ser una herramienta muy efectiva para la gestión de contraseñas de cuentas de administrador local.

Audit Policy Settings (Logging and Monitoring)

Toda organización necesita tener configurado el logging y monitoring para detectar y reaccionar ante cambios o actividades inesperadas que puedan indicar un ataque. El logging y monitoring efectivo puede utilizarse para detectar un atacante o empleado no autorizado que esté añadiendo un usuario o computadora, modificando un objeto en AD, cambiando la contraseña de una cuenta, accediendo a un sistema de manera no autorizada o no estándar, realizando un ataque como password spraying, o ataques más avanzados como los modernos ataques de Kerberos.

Group Policy Security Settings

Como se mencionó anteriormente en el módulo, los Group Policy Objects (GPOs) son colecciones virtuales de configuraciones de políticas que pueden aplicarse a usuarios específicos, grupos y computadoras a nivel de OU. Estos pueden utilizarse para aplicar una amplia variedad de security policies para ayudar a endurecer Active Directory. La siguiente es una lista no exhaustiva de los tipos de políticas de seguridad que pueden aplicarse:

Account Policies - Administran cómo las cuentas de usuario interactúan con el dominio. Estas incluyen la política de contraseñas, política de bloqueo de cuentas, y configuraciones relacionadas con Kerberos como la duración de los tickets de Kerberos.
Local Policies - Estas se aplican a una computadora específica e incluyen la política de auditoría de eventos de seguridad, asignaciones de derechos de usuario (privilegios de usuario en un host) y configuraciones de seguridad específicas como la capacidad de instalar drivers, si las cuentas de administrador e invitado están habilitadas, renombrar las cuentas de administrador e invitado, evitar que los usuarios instalen impresoras o utilicen medios extraíbles, y una variedad de controles de acceso y seguridad de red.
Software Restriction Policies - Configuraciones para controlar qué software puede ejecutarse en un host.
Application Control Policies - Configuraciones para controlar qué aplicaciones pueden ser ejecutadas por ciertos usuarios/grupos. Esto puede incluir bloquear a ciertos usuarios para que no ejecuten todos los ejecutables, archivos de Windows Installer, scripts, etc. Los administradores utilizan AppLocker para restringir el acceso a ciertos tipos de aplicaciones y archivos. No es raro ver a organizaciones bloquear el acceso a CMD y PowerShell (entre otros ejecutables) para usuarios que no los requieren para su trabajo diario. Estas políticas no son perfectas y a menudo pueden ser evitadas, pero son necesarias para una estrategia de defense-in-depth.
Advanced Audit Policy Configuration - Una variedad de configuraciones que pueden ajustarse para auditar actividades como el acceso o modificación de archivos, inicio/cierre de sesión de cuentas, cambios de políticas, uso de privilegios, y más.

Advanced Audit Policy

Update Management (SCCM/WSUS)

La gestión adecuada de parches es fundamental para cualquier organización, especialmente aquellas que ejecutan sistemas Windows/Active Directory. El Windows Server Update Service (WSUS) puede instalarse como un rol en un servidor Windows y puede utilizarse para minimizar la tarea manual de aplicar parches en los sistemas Windows. System Center Configuration Manager (SCCM) es una solución paga que depende del rol WSUS instalado en el servidor Windows y ofrece más características que WSUS por sí solo. Una solución de gestión de parches puede ayudar a asegurar la implementación oportuna de parches y maximizar la cobertura, asegurando que ningún host omita parches de seguridad críticos. Si una organización depende de un método manual para aplicar parches, podría llevar mucho tiempo dependiendo del tamaño del entorno y también podría resultar en que se pasen por alto sistemas, dejándolos vulnerables.

Group Managed Service Accounts (gMSA)

Una gMSA es una cuenta gestionada por el dominio que ofrece un mayor nivel de seguridad que otros tipos de cuentas de servicio para su uso con aplicaciones, servicios, procesos y tareas no interactivas que se ejecutan automáticamente pero que requieren credenciales para funcionar. Proporcionan gestión automática de contraseñas con una contraseña de 120 caracteres generada por el controlador de dominio. La contraseña se cambia a intervalos regulares y no necesita ser conocida por ningún usuario. Permite que las credenciales se utilicen en múltiples hosts.

Security Groups

Los grupos de seguridad ofrecen una forma fácil de asignar acceso a recursos de red. Pueden utilizarse para asignar derechos específicos al grupo (en lugar de directamente al usuario) para determinar qué pueden hacer los miembros del grupo dentro del entorno AD. Active Directory crea automáticamente algunos default security groups durante la instalación. Algunos ejemplos son Account Operators, Administrators, Backup Operators, Domain Admins, y Domain Users. Estos grupos también pueden utilizarse para asignar permisos para acceder a recursos (por ejemplo, un archivo compartido, carpeta, impresora o documento). Los grupos de seguridad ayudan a asegurar que se puedan asignar permisos granulares a los usuarios en masa en lugar de gestionar individualmente a cada usuario.

Built-in AD Security Groups

Account Separation

Los administradores deben tener dos cuentas separadas. Una para su trabajo diario y una segunda para cualquier tarea administrativa que deban realizar. Por ejemplo, un usuario podría iniciar sesión en su máquina usando su cuenta sjones para enviar/recibir correos electrónicos, crear documentos, etc. Deberían tener una cuenta separada, como sjones_adm, para acceder a un secure administrative host utilizado para realizar tareas administrativas. Esto puede ayudar a asegurar que si el host de un usuario es comprometido (a través de un ataque de phishing, por ejemplo), el atacante estaría limitado a ese host y no obtendría credenciales de un usuario altamente privilegiado con acceso considerable dentro del dominio. También es esencial que el individuo utilice diferentes contraseñas para

cada cuenta para mitigar el riesgo de ataques de reutilización de contraseñas si su cuenta no administrativa es comprometida.

Password Complexity Policies + Passphrases + 2FA

Idealmente, una organización debería estar utilizando passphrases o contraseñas largas generadas aleatoriamente utilizando un gestor de contraseñas empresarial. Las contraseñas estándar de 7-8 caracteres pueden ser crackeadas offline utilizando una herramienta como Hashcat muy rápidamente con un rig de cracking de contraseñas GPU. Las contraseñas más cortas y menos complejas también pueden ser adivinadas a través de un ataque de password spraying, dando al atacante un punto de apoyo en el dominio. Las reglas de complejidad de contraseñas por sí solas en AD no son suficientes para asegurar contraseñas fuertes. Por ejemplo, la contraseña Welcome1 cumpliría con las reglas de complejidad estándar (3 de 4 de mayúsculas, minúsculas, número y carácter especial), pero sería una de las primeras contraseñas que intentaría en un ataque de password spraying. Una organización también debería considerar implementar un filtro de contraseñas para deshabilitar contraseñas que contengan los meses o estaciones del año, el nombre de la empresa, y palabras comunes como password y welcome. La longitud mínima de la contraseña para usuarios estándar debería ser de al menos 12 caracteres e idealmente más larga para cuentas de administrador/cuentas de servicio. Otra medida de seguridad importante es la implementación de autenticación multifactor (MFA) para acceso remoto a cualquier host. Esto puede ayudar a limitar los intentos de movimiento lateral que pueden depender del acceso GUI a un host.

Limiting Domain Admin Account Usage

Las cuentas de Domain Admin con todos los privilegios deberían utilizarse solo para iniciar sesión en Domain Controllers, no en estaciones de trabajo personales, jump hosts, servidores web, etc. Esto puede reducir significativamente el impacto de un ataque y reducir las rutas de ataque potenciales si un host es comprometido. Esto garantizaría que las contraseñas de las cuentas de Domain Admin no queden en memoria en hosts en todo el entorno.

Periodically Auditing and Removing Stale Users and Objects

Es importante que una organización audite periódicamente Active Directory y elimine o desactive cualquier cuenta no utilizada. Por ejemplo, puede haber una cuenta de servicio privilegiada que fue creada hace ocho años con una contraseña muy débil que nunca fue cambiada, y la cuenta ya no está en uso. Incluso si la política de contraseñas se hubiera cambiado desde entonces para ser más resistente a ataques como password spraying, una cuenta como esta podría ser un punto de entrada rápido y fácil o un método para el movimiento lateral o escalación de privilegios dentro del dominio.

Auditing Permissions and Access

Las organizaciones también deberían realizar auditorías periódicas de control de acceso para asegurarse de que los usuarios solo tengan el nivel de acceso requerido para su trabajo diario. Es importante auditar los derechos de administrador local, la cantidad de Domain Admins (¿realmente necesitamos 30 de ellos?), y Enterprise Admins para limitar la superficie de ataque, acceso a archivos compartidos, derechos de usuario (por ejemplo, membresía en ciertos grupos de seguridad privilegiados), y más.

Audit Policies & Logging

La visibilidad en el dominio es imprescindible. Una organización puede lograr esto a través de un logging robusto y luego utilizando reglas para detectar actividad anómala (como muchos intentos fallidos de inicio de sesión que podrían ser indicativos de un ataque de password spraying) o indicadores de que se está intentando un ataque de Kerberoasting. Estos también pueden utilizarse para detectar la enumeración de Active Directory. Vale la pena familiarizarse con las Audit Policy Recommendations de Microsoft para ayudar a detectar compromisos.

Using Restricted Groups

Restricted Groups permiten a los administradores configurar la membresía de grupos a través de Group Policy. Pueden utilizarse por varias razones, como controlar la membresía en el grupo de administradores locales en todos los hosts del dominio restringiéndolo solo a la cuenta de Administrador local y Domain Admins, y controlar la membresía en los grupos altamente privilegiados de Enterprise Admins y Schema Admins y otros grupos administrativos clave.

Limiting Server Roles

Es importante no instalar roles adicionales en hosts sensibles, como instalar el rol de Internet Information Server (IIS) en un Domain Controller. Esto aumentaría la superficie de ataque del Domain Controller, y este tipo de rol debería instalarse en un servidor web independiente. Algunos otros ejemplos serían no alojar aplicaciones web en un servidor de correo Exchange y separar servidores web y de bases de datos en diferentes hosts. Este tipo de separación de roles puede ayudar a reducir el impacto de un ataque exitoso.

Limiting Local Admin and RDP Rights

Las organizaciones deben controlar estrictamente qué usuarios tienen derechos de administrador local en qué computadoras. Como se mencionó anteriormente, esto puede lograrse utilizando Restricted Groups. He visto demasiadas organizaciones con todo el grupo de Domain Users con derechos de administrador local en uno o más hosts. Esto permitiría a un atacante que comprometa ANY cuenta (incluso una con muy pocos privilegios) acceder a ese host como administrador local y potencialmente obtener datos sensibles o robar credenciales de cuentas de dominio con altos privilegios desde la memoria si otro usuario está conectado. Lo mismo ocurre con los derechos de Remote Desktop (RDP). Si muchos usuarios pueden conectarse a través de RDP a una o varias máquinas, esto aumenta el riesgo de exposición de datos sensibles o ataques de escalación de privilegios, lo que lleva a una mayor compromisión.

Este link proporciona más información sobre las mejores prácticas de Microsoft para asegurar Active Directory.