Page cover

📘DnsAdmins

Los miembros del grupo DnsAdmins tienen acceso a la información DNS en la red. El servicio DNS de Windows admite complementos personalizados y puede llamar a funciones desde ellos para resolver consultas de nombres que no están dentro del alcance de ninguna zona DNS alojada localmente. El servicio DNS se ejecuta como , por lo que la membresía en este grupo podría aprovecharse potencialmente para escalar privilegios en un controlador de dominio o en una situación en la que un servidor independiente actúe como servidor DNS para el dominio. Es posible utilizar la utilidad dnscmd NT AUTHORITY\SYSTEM incorporada para especificar la ruta de la DLL del complemento. Como se detalla en esta excelente publicación , se puede realizar el siguiente ataque cuando DNS se ejecuta en un controlador de dominio (lo cual es muy común):

  • La gestión de DNS se realiza a través de RPC

  • ServerLevelPluginDll nos permite cargar una DLL personalizada sin necesidad de verificar la ruta de la DLL. Esto se puede hacer con la herramienta dnscmd desde la línea de comandos.

  • Cuando un miembro del grupo DnsAdmins ejecuta el siguiente comando dnscmd, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\ServerLevelPluginDll se completa la clave de registro

  • Cuando se reinicia el servicio DNS, se cargará la DLL en esta ruta (es decir, un recurso compartido de red al que puede acceder la cuenta de la máquina del controlador de dominio)

  • Un atacante puede cargar una DLL personalizada para obtener un shell inverso o incluso cargar una herramienta como Mimikatz como una DLL para volcar credenciales.

Veamos el ataque paso a paso.


Aprovechar el acceso DnsAdmins

Generando una DLL maliciosas

Podemos generar una DLL maliciosa para agregar un usuario al grupo domain admins usando msfvenom.

afsh4ck@kali$ msfvenom -p windows/x64/exec cmd='net group "domain admins" netadm /add /domain' -f dll -o adduser.dll

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 313 bytes
Final size of dll file: 5120 bytes
Saved as: adduser.dll

Iniciar un servidor HTTP local

A continuación, inicie un servidor HTTP Python.

Descargar archivo al destino

Veamos primero qué sucede si usamos la utilidad dnscmd para cargar una DLL personalizada con un usuario sin privilegios.

Cargar DLL como usuario sin privilegios

Como era de esperar, intentar ejecutar este comando como usuario normal no da resultado. Solo los miembros del grupo DnsAdmins pueden hacerlo.

Cargar DLL como miembro de DnsAdmins

Cargar DLL personalizada

Después de confirmar la membresía del grupo DnsAdmins, podemos volver a ejecutar el comando para cargar una DLL personalizada.

La utilidad dnscmd sólo puede ser utilizada por miembros del grupo DnsAdmins, ya que no tienen permiso directo sobre la clave de registro.

Una vez que se haya configurado la configuración del registro que contiene la ruta de nuestro complemento malicioso y se haya creado nuestra carga útil, la DLL se cargará la próxima vez que se inicie el servicio DNS. La pertenencia al grupo DnsAdmins no otorga la capacidad de reiniciar el servicio DNS, pero es posible que los administradores de sistemas permitan que los administradores de DNS hagan esto.

Después de reiniciar el servicio DNS (si nuestro usuario tiene este nivel de acceso), deberíamos poder ejecutar nuestra DLL personalizada y agregar un usuario (en nuestro caso) u obtener un shell inverso. Si no tenemos acceso para reiniciar el servidor DNS, tendremos que esperar hasta que el servidor o servicio se reinicie. Verifiquemos los permisos de nuestro usuario actual en el servicio DNS.

Encontrar el SID del usuario

Primero, necesitamos el SID de nuestro usuario.

Comprobación de permisos en el servicio DNS

Una vez que tenemos el SID del usuario, podemos usar el comando sc para verificar los permisos en el servicio. Según este artículo , podemos ver que nuestro usuario tiene permisos RPWP que se traducen en SERVICE_START y SERVICE_STOP, respectivamente.

Detener el servicio DNS

Después de confirmar estos permisos, podemos emitir los siguientes comandos para detener e iniciar el servicio.

El servicio DNS intentará iniciar y ejecutar nuestra DLL personalizada, pero si verificamos el estado, mostrará que no pudo iniciarse correctamente (más sobre esto más adelante).

Iniciando el servicio DNS

Confirmación de membresía del grupo

Si todo va según lo previsto, nuestra cuenta se agregará al grupo de administradores de dominio o recibirá un shell inverso si nuestra DLL personalizada se creó para brindarnos una conexión nuevamente.


Limpiando

Realizar cambios de configuración y detener o reiniciar el servicio DNS en un controlador de dominio son acciones muy destructivas y deben realizarse con mucho cuidado. Como evaluadores de penetración, debemos ejecutar este tipo de acción por parte de nuestro cliente antes de proceder con ella, ya que podría hacer que se caiga el DNS de todo un entorno de Active Directory y causar muchos problemas. Si nuestro cliente da su permiso para seguir adelante con este ataque, debemos poder cubrir nuestras huellas y limpiar el desastre o ofrecerle a nuestro cliente pasos sobre cómo revertir los cambios.

Estos pasos deben realizarse desde una consola elevada con una cuenta de administrador local o de dominio.

Confirmación de la clave de registro agregada

El primer paso es confirmar que la clave de registro ServerLevelPluginDll existe. Hasta que no eliminemos nuestra DLL personalizada, no podremos volver a iniciar el servicio DNS correctamente.

Eliminar clave de registro

Podemos usar el comando reg delete para eliminar la clave que apunta a nuestra DLL personalizada.

Iniciar nuevamente el servicio DNS

Una vez hecho esto ya podemos iniciar nuevamente el servicio DNS.

Comprobación del estado del servicio DNS

Si todo salió según lo previsto, al consultar el servicio DNS se verá que está en funcionamiento. También podemos confirmar que el DNS está funcionando correctamente dentro del entorno realizando una consulta nslookup al host local u otro host del dominio.

Una vez más, se trata de un ataque potencialmente destructivo que solo debemos llevar a cabo con el permiso explícito de nuestro cliente y en coordinación con él. Si comprenden los riesgos y quieren ver una prueba de concepto completa, los pasos que se describen en esta sección ayudarán a demostrar el ataque y a solucionarlo posteriormente.


Uso de Mimilib.dll

Como se detalla en esta publicación , también podríamos utilizar mimilib.dll del creador de la herramienta Mimikatz para obtener la ejecución de comandos modificando el archivo kdns.c para ejecutar una línea única de reverse shell u otro comando de nuestra elección.


Creación de un registro WPAD

Otra forma de abusar de los privilegios del grupo DnsAdmins es mediante la creación de un registro WPAD. La pertenencia a este grupo nos otorga los derechos para desactivar la seguridad del bloqueo de consultas globales , que bloquea este ataque de forma predeterminada. Server 2008 introdujo por primera vez la capacidad de agregar a una lista global de bloqueo de consultas en un servidor DNS. De forma predeterminada, el Protocolo de descubrimiento automático de proxy web (WPAD) y el Protocolo de direccionamiento automático de túneles dentro del sitio (ISATAP) están en la lista global de bloqueo de consultas. Estos protocolos son bastante vulnerables al secuestro, y cualquier usuario de dominio puede crear un objeto de computadora o un registro DNS que contenga esos nombres.

Después de deshabilitar la lista de bloqueo de consultas globales y crear un registro WPAD, cada máquina que ejecute WPAD con la configuración predeterminada tendrá su tráfico redirigido a través de nuestra máquina de ataque. Podríamos usar una herramienta como Responder o Inveigh para realizar suplantación de tráfico e intentar capturar hashes de contraseñas y descifrarlos sin conexión o realizar un ataque SMBRelay.

Deshabilitar la lista de bloqueo de consultas globales

Para configurar este ataque, primero deshabilitamos la lista de bloqueo de consultas globales:

Agregar un registro WPAD

A continuación, agregamos un registro WPAD que apunta a nuestra máquina de ataque.


Caso práctico

Aproveche la pertenencia al grupo DnsAdmins para aumentar los privilegios. Envíe el contenido de la flag ubicada en c:\Users\Administrator\Desktop\DnsAdmins\flag.txt

Comprobar membresía de grupo

Con los siguientes comandos confirmamos que el usuario netadm está dentro del grupo DnsAdmins:

Crear DLL maliciosa con Msfvenom

Envío a la máquina objetivo

Cargar DLL maliciosa

Reiniciar el servicio DNS

Confirmación de membresía del grupo

Una vez que estamos en el grupo de Domain Admins necesitamos desloguearnos y volver a acceder para que los cambios surjan efecto. Podemos hacerlo con el siguiente comando:

Acceso a la flag

Última actualización

¿Te fue útil?