Todos estamos de acuerdo que asegurar un entorno de Active Directory no es una tarea fácil, siempre hay nuevos requisitos, características, pequeños (o grandes) descuidos en su configuración y nuevas vulnerabilidades que van apareciendo casi de forma frenética. Recientemente en el blog de Infosecmatter recogían un top16 de las debilidades y vulnerabilidades más comunes que encontraremos en este tipo de entornos, sin duda una recopilación muy útil y que un pentester a de tener muy en cuenta:
1. Usuarios que tienen permisos para agregar equipos al dominio
2. Atributo AdminCount configurado en usuarios comunes
3. Demasiados usuarios en grupos privilegiados
4. Cuentas de servicio miembros de administradores de dominio
5. Privilegios excesivos que permiten shadow admins en el dominio
6. Cuentas de servicio vulnerables a Kerberoasting
7. Usuarios con contraseñas que no caducan
8. Usuarios con contraseña no requerida
9. Almacenar contraseñas usando cifrado reversible
10. Almacenar contraseñas usando hashes LM
11. Cuentas de servicio vulnerables a AS-REP roasting
12. Política de contraseñas débil
13. Cuentas de dominio inactivas
14. Usuarios privilegiados con restablecimiento de contraseña vencido
15. Usuarios con una contraseña débil
16. Credenciales en SYSVOL y Preferencias de directiva de grupo (GPP)
1. Usuarios que tienen permisos para agregar equipos al dominio
En el Directorio Activo por defecto cualquier usuario de dominio puede agregar worstations. Esto se define mediante el atributo ms-DS-MachineAccountQuota que se establece de manera predeterminada a 10. Es decir, cualquier usuario de dominio con pocos privilegios puede unir hasta 10 computadoras al dominio. Por ejemplo esto brinda la posibilidad a un atacante de agregar su propio equipo no administrado a un dominio corporativo con las siguientes ventajas:
- sin necesidad de tener una solución antivirus o EDR en su máquina
- no se aplicarán configuraciones o políticas de GPO a su sistema
- podrá tener derechos administrativos en su sistema
Para añadir a un equipo al dominio se puede hacer mediante las Propiedades del Sistema (sysdm.cpl) o con powershell:
add-computer –domainname <FQDN-DOMAIN> -Credential <DOMAIN>\<USER> -restart –force
# Ejemplo
add-computer –domainname org.local -Credential ORG\john -restart –force
Si tenemos acceso a los controladores de dominio también podemos enumerar aquellas máquinas que fueron agregadas por usuarios que no son administradores:
Import-Module ActiveDirectory
Get-ADComputer -LDAPFilter "(ms-DS-CreatorSID=*)" -Properties ms-DS-CreatorSID
Volver al principio
2. Atributo AdminCount configurado en usuarios comunes
En DA hay un objeto llamado
AdminSDHolder cuyo propósito es proteger objetos. Específicamente, objetos que son miembros de grupos administrativos.
Los objetos AD tienen un atributo llamado
AdminCount. El valor predeterminado es para la mayoría de los objetos. Al cambiar el valor a "1", se marca la cuenta como protegida por
AdminSDHolder.
Al agregar un usuario a un grupo con permisos de administración se cambia el valor a "1", pero si embargo cuando se saca del grupo ese valor no vuelve a "0". Como resultado, el objeto de usuario sigue teniendo ACL "sensibles" como por ejemplo deshabilitar la herencia de permisos. Esto puede ser un riesgo en algunos escenarios.
Para encontrar usuarios con el atributo
AdminCount configurado a 1 podemos usar la herramienta
LDAPDomainDump. Esta herramienta recopila información sobre todos los usuarios, grupos y equipos del dominio. Todo lo que necesitamos son credenciales de cualquier usuario de dominio con pocos privilegios y poder llegar al puerto LDAP de cualquier controlador de dominio.
1) Primero recopilamos la información del controlador de dominio:
python ldapdomaindump.py -u <DOMAIN>\<USER> -p <PASS> -d <DELIMITER> <DC-IP>
# Ejemplo:
python ldapdomaindump.py -u example.com\john -p pass123 -d ';' 10.100.20.1
Hay que tener en cuenta que en lugar de una contraseña también podríamos proporcionar el hash NTLM (pass-the-hash).
2) Una vez que se realiza el volcado, podemos obtener la lista de usuarios con el atributo
AdminCount configurado a 1 analizando el archivo "domain_users.json":
jq -r '.[].attributes | select(.adminCount == [1]) | .sAMAccountName[]' domain_users.json
Como alternativa podemos obtener la lista también con powershell:
Import-Module ActiveDirectory
Get-AdObject -ldapfilter "(admincount=1)" -properties admincount
Una vez que tengamos la lista de usuarios afectados, debemos verificar si realmente pertenecen a algún grupo privilegiado o administrativo.
Volver al principio
3. Demasiados usuarios en grupos privilegiados
Tener una gran cantidad de usuarios en grupos privilegiados como Administradores de dominio, Administradores de esquema y Administradores empresariales, aumenta innecesariamente el riesgo de comprometer el dominio, porque si algunos de esos usuarios se ven comprometidos, significa un compromiso total del dominio.
Para enumerar estos grupos desde un dominio unido a una máquina Windows:
net group "Schema Admins" /domain
net group "Domain Admins" /domain
net group "Enterprise Admins" /domain
En una máquina Windows no unida, primero tendríamos que autenticarnos en el dominio:
runas /netonly /user:<DOMAIN>\<USER> cmd.exe
Y desde Linux usando el comando "net":
net rpc group members 'Schema Admins' -I <DC-IP> -U "<USER>"%"<PASS>"
net rpc group members 'Domain Admins' -I <DC-IP> -U "<USER>"%"<PASS>"
net rpc group members 'Enterprise Admins' -I <DC-IP> -U "<USER>"%"<PASS>"
# Ejemplo:
net rpc group members 'Domain Admins' -I 10.10.30.52 -U "john"%"pass123"
Volver al principio
4. Cuentas de servicio miembros de administradores de dominio
Hay veces que a las cuentas de servicio se les asignan privilegios y/o membresías excesivas. Dicha práctica introduce un riesgo crítico en la infraestructura, porque las cuentas de servicio generalmente tienen contraseñas configuradas para que nunca caducan. Esto significa que si una cuenta de servicio así se comprometiera, permitiría al atacante tener control total sobre el dominio AD. Y por mucho tiempo probablemente.
Para verificar si hay cuentas de servicio podemos revisar los usuarios de los grupos como se especificó anteriormente:
net group "Schema Admins" /domain
net group "Domain Admins" /domain
net group "Enterprise Admins" /domain
Volver al principio
5. Privilegios excesivos que permiten shadow admins en el dominio
Esta vulnerabilidad es más compleja. Se trata del mal uso de los
permisos y
permisos extendidos de Active Directory, también conocidos como entradas de control de acceso (ACE).
El problema es cuando algunos de estos permisos se otorgan a un usuario con privilegios bajos (o un grupo) para permitir cambiar algo importante en un usuario con privilegios más altos (o un grupo).
Algunos de los permisos típicamente mal utilizados incluyen:
- ForceChangePassword - Posibilidad de restablecer la contraseña de otro usuario
- GenericAll: control total sobre un objeto (lectura/escritura)
- GenericWrite - Actualización de cualquier atributo de un objeto
- WriteOwner - Asume la propiedad de un objeto
- WriteDacl - Modificar la DACL de un objeto
- Self - Modifica arbitrariamente self
Esto puede tener un impacto crítico y a menudo conduce a privilegios de administrador de dominio. Los usuarios con tales privilegios excesivos se denominan administradores de dominio en la sombra,
shadow admins o administradores ocultos.
Para buscar "shadows admin" todo lo que necesitamos es un usuario de dominio con pocos privilegios y la herramienta adecuada.
Una de las herramientas que más ayuda en este proceso es
Bloodhound de la que ya hemos hablado anteroirmente en el blog.
Volver al principio
6. Cuentas de servicio vulnerables a Kerberoasting
Kerberoasting es un vector de ataque muy popular dirigido contra cuentas de servicio en Active Directory. El problema es cuando hay cuentas de servicio con contraseñas débiles y cuando hay un cifrado débil Kerberos RC4 utilizado para cifrar sus contraseñas.
Este ataque se puede automatizar ya con múltiples herramientas (por ejemplo,
Impacket o
Rubeus) y todo lo que necesitamos para probar es tener credenciales de usuario de dominio con privilegios bajos.
Aquí hay un ejemplo usando Impacket:
GetUserSPNs.py -request <DOMAIN>/<USER>:<PASS>
Tened en cuenta que en lugar de una contraseña, también podríamos usar un hash NTLM (pass-the-hash). Si obtuvimos alguno, significa que hay cuentas de servicio vulnerables a Kerberoasting.
Después de obtener los hashes, podemos intentar descifrarlos para demostrar completamente el impacto. Aquí hay un ejemplo del uso de Hashcat para realizar un ataque de diccionario:
hashcat -m 13100 -a 0 hashes.txt wordlist.txt
Para proteger las cuentas de servicio contra Kerberoasting se recomienda:
- Utilizar algoritmos de cifrado más nuevos, como AES128, AES256 o superior.
- Aplicar el uso de contraseñas seguras y complejas (idealmente más de 25 caracteres de longitud)
- Asegurarse de que la contraseña caduque periódicamente
- Mantener los privilegios lo más bajos posible
Volver al principio
7. Usuarios con contraseñas que no caducan
Algunas organizaciones tienen cuentas de dominio configuradas con el flag
DONT_EXPIRE_PASSWORD. Esta es la configuración típica de las cuentas de servicio, pero a veces también se puede ver en cuentas de dominio más privilegiadas. Aunque es útil en algunas situaciones, también puede ser bastante perjudicial y las cuentas de dominio con este flag son objetivos ideales para ataques de escalada de privilegios y son excelentes
backdoors para mantener el acceso como se ha visto en muchas APT.
Para encontrar usuarios con contraseñas que no caduquen, podemos usar nuevamente la herramienta
LDAPDomainDump mencionada anteriormente. Una vez que se realiza el volcado, podemos obtener la lista de usuarios con contraseñas que no caducan utilizando el siguiente comando:
grep DONT_EXPIRE_PASSWD domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3}'
Y con powershell:
Import-Module ActiveDirectory
Get-ADUser -filter * -properties Name, PasswordNeverExpires | where { $_.passwordNeverExpires -eq "true" } | where {$_.enabled -eq "true" }
Volver al principio
8. Usuarios con contraseña no requerida
Otro flag interesante en Active Directory es
PASSWD_NOTREQD. Si una cuenta de usuario tiene esa flag establecida, no significa que la cuenta no tenga que tener una contraseña si no que cualquier tipo de contraseña será válida: una corta, una que no cumpla (contra la política de contraseña de dominio) o una vacía. Simplemente cualquiera. Esto es, por supuesto, un gran riesgo de seguridad y ninguna cuenta de usuario debería tener esta flag.
La búsqueda de usuarios con el conjunto de indicadores
PASSWD_NOTREQD es muy similar a la búsqueda de usuarios con contraseñas que no caducan. Nuevamente podemos aprovechar la herramienta LDAPDomainDump y, una vez que se realiza el volcado, obtener la lista de usuarios con el indicador
PASSWD_NOTREQD utilizando el siguiente comando:
grep PASSWD_NOTREQD domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $ 3}'
Y volvemos a powershell como alternativa:
Importar módulo ActiveDirectory
Get-ADUser -Filter {UserAccountControl -band 0x0020}
Volver al principio
9. Almacenar contraseñas usando cifrado reversible
Algunas aplicaciones requieren la contraseña del usuario en texto claro para realizar una autenticación y es por eso que hay soporte para almacenar contraseñas utilizando cifrado reversible en Active Directory. Almacenar contraseñas de esta manera es esencialmente idéntico a almacenarlas en texto claro. Es una idea horrible, pero es una realidad.
El único factor atenuante aquí es que un atacante debería poder extraer datos de contraseña de los controladores de dominio para leer la contraseña en texto claro. Esto significa tener:
- Permisos para realizar la operación DCSYNC (por ejemplo, a través de Mimikatz)
- Acceso al archivo NTDS.DIT en un controlador de dominio (implica ya tener un compromiso completo del AD)
Ambos métodos ya implican un compromiso de dominio AD completo. Sin eso, no hay forma de encontrar qué usuarios tienen contraseñas almacenadas utilizando un cifrado reversible. E incluso si supiéramos cuáles, no podríamos extraer las contraseñas, a menos que tengamos tales privilegios con los que prácticamente ya tendríamos
owneado el dominio entero.
Entonces, para probar esta vulnerabilidad, tenemos que volcar el archivo NDTS.DIT del controlador de dominio y extraer los hashes de él. Solo así podremos ver qué usuarios tienen contraseñas almacenadas mediante cifrado reversible: sus contraseñas simplemente se imprimirán en texto claro.
Tened en cuenta que también podríamos obtener la contraseña en texto claro con Mimikatz ejecutándose en el contexto de un usuario con privilegios elevados (que puede realizar DCSYNC), pero tendríamos que conocer el nombre de usuario de un usuario afectado.
Aquí está el comando Mimikatz que lo haría:
mimikatz # lsadump::dcsync /domain:<DOMAIN> /user:<AFFECTED-USER>
# Ejemplo:
mimikatz # lsadump::dcsync /domain:example.com /user:poorjohn
En cualquier caso, las contraseñas nunca deben almacenarse en texto claro. Esta vulnerabilidad ofrece a los atacantes que comprometieron el dominio AD (por ejemplo, APT) y a personas con privilegios internos (por ejemplo, administradores de dominio) acceso instantáneo a las contraseñas en claro de los usuarios afectados.
Volver al principio
10. Almacenar contraseñas usando hashes LM
Otra vulnerabilidad típica es el almacenamiento de contraseñas como LM hash, en lugar de NTLM. LM hash es un antiguo método obsoleto para almacenar contraseñas que tiene las siguientes debilidades:
- La longitud de la contraseña está limitada a 14 caracteres.
- Las contraseñas que tienen más de 7 caracteres se dividen en dos y cada mitad se divide en hashes por separado
- Todos los caracteres en minúsculas se convierten en mayúsculas antes hashearse
Debido a estas debilidades, los hashes LM son extremadamente fáciles de descifrar. Cualquier persona que tenga acceso a ellos, por ejemplo usuarios con privilegios (administradores de dominio), pueden descifrarlas fácilmente y obtener contraseñas de texto sin formato.
Al igual que antes, esto podremos aprovecharlo una vez que el AD está comprometido y se han podido extraer los archivos NTDS.DIT.
Cuando la parte LM se establece en algo diferente a 'aad3b435b51404eeaad3b435b51404ee' (cadena vacía), significa que estamos buscando un hash LM.
Así que para encontrar hashes LM podemos simplemente grepear:
grep -iv ':aad3b435b51404eeaad3b435b51404ee:' dumped_hashes.txt
Volver al principio
11. Cuentas de servicio vulnerables a AS-REP roasting
Esta vulnerabilidad es muy similar a Kerberoasting, pero en este caso el ataque abusa de las cuentas de usuario que no requieren autenticación Kerberos previa. Afecta a los usuarios del dominio con el flag
DONT_REQ_PREAUTH.
Para probarlo es similar a Kerberoasting, se puede realizar con varias herramientas (por ejemplo, Impacket o Rubeus como decíamos anteriormente). Pero hay algunas diferencias sutiles: para AS-REP roasting, ¡no tenemos que conocer ninguna credencial de usuario de dominio! Lo único que necesitamos saber es qué usuarios se ven afectados.
Si no conocemos ninguno, entonces podemos probar una lista de palabras con nombres de usuario como en este ejemplo con Impacket:
GetNPUsers.py <DOMAIN>/ -usersfile <USERLIST.TXT> -format [hashcat|john] -no-pass
# Ejemplo:
GetNPUsers.py example.com/ -usersfile userlist.txt -format hashcat -no-pass
Por otro lado, si tenemos credenciales de usuario de dominio con privilegios bajos, podemos obtener la lista de usuarios afectados de inmediato, junto con sus hashes Kerberos AS-REP:
GetNPUsers.py <DOMAIN>/<USER>:<PASS> -request -format [hashcat|john]
# Example:
GetNPUsers.py example.com/john:pass123 -request -format hashcat
Si obtenemos algunos hashe podemos intentar romperlos. Aquí hay un ejemplo con Hashcat usando un ataque de diccionario para intentar romper los hashes Kerberos AS-REP:
hashcat -m 18200 -a 0 hashes.txt wordlist.txt
# Más rápido con cores optimizados, pero longitud de contraseña limitada a 31 caracteres:
hashcat -m 18200 -a 0 -O - self-test-disable hashes.txt wordlist.txt
Como alternativa, el siguiente comando de PowerShell podría usarse en un controlador de dominio para obtener la lista de usuarios que no requieren autenticación previa Kerberos:
Import-Module ActiveDirectory
Get-ADuser -filter * -properties DoesNotRequirePreAuth | where {$._DoesNotRequirePreAuth -eq "True" -and $_.Enabled -eq "True"} | select Name
Volver al principio
12. Política de contraseñas débil
La política de contraseñas es un tema que sigue evolucionando con el tiempo. Hay muchos puntos de vista diferentes y opiniones sobre cómo debería ser una política de contraseña ideal.
Algunas organizaciones aplican contraseñas largas y complejas, cambiándolas con frecuencia. Algunos son más benévolos y algunos incluso casi pueden ignorar aplicar cualquier política o y solo se centran en fortalecer sus controles compensatorios en sus entornos internos de modo que el compromiso de la cuenta solo tenga un impacto muy pequeño.
Cada enfoque tiene sus ventajas y desventajas pero, por ejemplo, el
CIS Benchmark recomienda la siguiente política de contraseñas en Active Directory:
- Longitud mínima de contraseña: 14
- Hacer cumplir el historial de contraseñas: 24
- Contraseña máxima: 60 días o menos.
- Edad mínima de contraseña: 1 o más
- La contraseña debe cumplir con la complejidad: habilitado
- Almacenar contraseñas con cifrado reversible: deshabilitado
- Umbral de bloqueo de cuenta: hasta 10, pero no 0
- Duración del bloqueo de cuenta (minutos): 15 minutos o más
- Ventana de observación de bloqueo de cuenta (minutos): 30 minutos
Para ver la política de contraseñas, no necesitamos privilegios especiales; cualquier cuenta de dominio con pocos privilegios puede hacerlo.
Para mostrar la política de contraseñas de AD desde un dominio unido a una máquina Windows:
net accounts /domain
Desde Linux con el comando polenum:
polenum --username <USER> --password <PASS> --domain <DC-IP>
# Ejemplo:
polenum --username john --password pass123 --domain 10.10.51.11
Como alternativa podemos usar enum4linux:
enum4linux -P -u <USER> -p <PASS> -w <DOMAIN> <DC-IP>
# Ejemplo:
enum4linux -P -u john -p pass123 -w dom.local 172.21.1.60
Volver al principio
13. Cuentas de dominio inactivas
Normalmente encontramos cuentas de usuario activas sin ser utilizadas durante mucho tiempo, de acuerdo con la "Última fecha de inicio de sesión". Estas cuentas generalmente pertenecen a:
- Empleados que abandonaron la empresa.
- Cuentas temporales
- Cuentas de prueba
Tener cuentas de dominio no utilizadas en el dominio aumenta la superficie de ataque de la organización, ya que brinda la oportunidad de comprometer estas cuentas, por ejemplo a través de ataques de inicio de sesión.
Debe existir un mecanismo (una política) para deshabilitar o eliminar estas cuentas en función de verificaciones periódicas, ej. después de 30 días de inactividad.
Para encontrar cuentas de dominio inactivas, podemos aprovechar nuevamente la herramienta LDAPDomainDump mencionada anteriormente.
Todo lo que necesitamos son unas credenciales de usuario de dominio con pocos privilegios y la capacidad de alcanzar el puerto LDAP de cualquier controlador de dominio.
1) Primero hay que recopilar la información del controlador de dominio:
python ldapdomaindump.py -u <DOMAIN>\<USER> -p <PASS> -d <DELIMITER> <DC-IP>
# Example:
python ldapdomaindump.py -u example.com\john -p pass123 -d ';' 10.100.20.1
2) Una vez que se realiza el volcado, se puede ordenar a los usuarios según la última fecha de inicio de sesión con el siguiente comando:
sort -t ';' -k 8 domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3, $8}'
Volver al principio
14. Usuarios privilegiados con restablecimiento de contraseña vencido
Las cuentas privilegiadas son probablemente objetivos para atacantes (por ejemplo, APT) y, si sus contraseñas no se cambian periódicamente, esto les da a los atacantes el tiempo suficiente para intentar romperlas. Todas las cuentas privilegiadas y cuentas de servicio deberían tener sus contraseñas cambiadas regularmente.
Para identificarlos lo que tenemos que hacer es obtener una lista de usuarios con el flag
AdminCount y ver cuándo fue la última vez que cambiaron su contraseña.
Con la herramienta LDAPDomainDump mencionada anteriormente, es pan comido. Todo lo que necesitamos son credenciales de cualquier usuario de dominio con pocos privilegios y la capacidad de alcanzar el puerto LDAP de cualquier controlador de dominio.
1) Primero recopilar la información del controlador de dominio:
python ldapdomaindump.py -u <DOMAIN>\<USER> -p <PASS> -d <DELIMITER> <DC-IP>
# Example:
python ldapdomaindump.py -u example.com\john -p pass123 -d ';' 10.100.20.1
2) Una vez que se realiza el volcado, obtener la lista de usuarios con el atributo AdminCount en 1 analizando el archivo "domain_users.json":
jq -r '.[].attributes | select(.adminCount == [1]) | .sAMAccountName[]' domain_users.json > privileged_users.txt
3) Ahora recorrer la lista de usuarios privilegiados, mostrar su última fecha de restablecimiento de contraseña (pwdLastSet) y ordenarla:
while read user; do grep ";${user};" domain_users.grep; done < privileged_users.txt | \
grep -v ACCOUNT_DISABLED | sort -t ';' -k 10 | awk -F ';' '{print $3, $10}'
Como veis, parece que esos 5 usuarios privilegiados no han tenido un cambio de contraseña durante mucho tiempo.
Volver al principio
15. Usuarios con una contraseña débil
A pesar de tener una política de contraseña corporativa sólida y un entorno maduro, aún puede haber cuentas de dominio con contraseñas débiles. De hecho, este es un problema muy común, especialmente en entornos grandes de Directorio Activo.
Para probar las credenciales débiles de los usuarios del dominio, primero tenemos que tener una lista de usuarios. Y para obtener la lista, debemos tener un acceso de usuario con privilegios bajos al dominio.
Esto es lo que podríamos hacer en una máquina con Windows unida a un dominio:
1) Primero necesitamos obtener una lista de usuarios del AD y para eso podemos usar el siguiente combo de PowerShell:
$a = [adsisearcher]”(&(objectCategory=person)(objectClass=user))”
$a.PropertiesToLoad.add(“samaccountname”) | out-null
$a.PageSize = 1
$a.FindAll() | % { echo $_.properties.samaccountname } > users.txt
2) Ahora podríamos alimentar esta lista con cualquiera de las siguientes herramientas para realizar el ataque:
De forma alternativa, también podríamos usar nuestro la tool login AD bruteforcer (
github):
Import-Module ./adlogin.ps1
adlogin users.txt domain.com password123
En Linux podríamos hacer lo mismo de la siguiente manera:
1) Obtener una lista de usuarios de dominio de AD utilizando el comando "net":
net rpc group members 'Domain Users' -I <DC-IP> -U "<USER>"%"<PASS>"
Ejemplo:
net rpc group members 'Domain Users' -I 192.168.10.50 -U "john"%"pass123" > users.txt
2) Ahora podríamos incluirlo en cualquiera de las herramientas mencionadas anteriormente, por ej. Metasploit para hacer el ataque:
use auxiliary/scanner/smb/smb_login
set RHOSTS <DC-IP>
set SMBDomain <DOMAIN>
set SMBPass file:pwdlist.txt
set USER_FILE users.txt
set THREADS 5
run
ADVERTENCIA: Antes de ejecutar cualquier ataque de fuerza bruta, debemos estar siempre al tanto de la política de contraseñas corporativa para evitar bloqueos de usuarios.
Volver al principio
16. Credenciales en SYSVOL y Group Policy Preferences (GPP)
Muchas veces se almacenan credenciales en carpetas compartidas de red SYSVOL, que son carpetas en controladores de dominio accesibles y legibles para todos los usuarios de dominio autenticados. Las carpetas SYSVOL se usan generalmente para almacenar Políticas de grupo corporativas, archivos de configuración y otros datos que se envían a los usuarios al iniciar sesión, etc.
El almacenamiento de credenciales en las carpetas SYSVOL es algo que los administradores a veces hacen o deciden hacer en algún momento, para resolver algún problema de configuración. Por ejemplo, iniciar una aplicación en máquinas cliente al iniciar sesión que requiere privilegios administrativos.
No es necesario decir que esto es algo que nunca se debe hacer, porque cualquier usuario de dominio puede acceder a los recursos compartidos de SYSVOL y encontrar las credenciales.
Ejemplos típicos son:
- Preferencias de directiva de grupo (GPP) con el atributo cPassword (
MS14-025)
- Credenciales hardcodeadas en varios scripts y archivos de configuración
Para probar esto, necesitamos tener credenciales de usuario de dominio con privilegios bajos.
Esto es lo que podríamos hacer desde un dominio unido a una máquina Windows:
findstr /s /n /i /p password \\<DOMAIN>\sysvol\<DOMAIN>\*
# Ejemplo:
findstr /s /n /i /p password \\example.com\sysvol\example.com\*
Este comando examinará todos los archivos del volumen SYSVOL y buscará el patrón "password".
Un comando equivalente en Linux (por ejemplo, Kali Linux) sería:
mount.cifs -o domain=<DOMAIN>,username=<USER>,password=<PASS> //<DC-IP>/SYSVOL /mnt
# Ejemplo:
mount.cifs -o domain=example.com,username=john,password="pass@123" //10.10.139.115/SYSVOL /mnt
# Búsqueda:
grep -ir 'password' /mnt
Lo más probable es que encontraremos algo interesante. Por ejemplo, podríamos encontrar un atributo cPassword en los archivos GPP XML, que podríamos descifrar instantáneamente usando la utilidad "gpp-decrypt":
Ahora podríamos intentar usar esta contraseña para autenticarnos en las máquinas Windows que se encuentran en la red. O podríamos probarla en otro lado. Lo más probable es que la contraseña se reutilice en algún lugar...
Volver al principio
Fuente:
https://www.infosecmatter.com/top-16-active-directory-vulnerabilities/
En cualquier caso hay que tener en cuenta que CVE-2020-1350 no requiere una
conexión directa al puerto 53. Si se suplanta/realiza un phishing sobre
alguien, basta un clic y el servidor DNS interno recibirá la petición
maliciosa.
Los mensajes más largos que no caben en un dominio (253 bytes) se dividen automáticamente en múltiples consultas, que el servidor vuelve a ensamblar y decodificar.
Instalación y uso
