Huy Kha | Arquiteto Sénior de Identidade e Segurança

O Active Diretory (AD) ainda está no centro da maioria dos ambientes empresariais, e os atacantes sabem disso. À medida que as ameaças visam cada vez mais a identidade, o AD continua a ser um ponto-chave de entrada e de aumento de privilégios. O problema é que muitas das mesmas configurações incorrectas e negligências aparecem em diferentes organizações, independentemente da dimensão ou do sector.

Depois de analisar os resultados de várias Avaliações de Segurança do Active Diretory (ADSAs) em 2025, a equipa da Semperis Identity Forensics and Incident Response (IFIR) observou um padrão claro. Certos riscos não param de surgir. Alguns são bem conhecidos, mas não são abordados, enquanto outros são fáceis de ignorar sem as ferramentas ou a visibilidade certas.

Nesta publicação, irei analisar os 10 riscos AD mais comuns encontrados em ambientes reais e explicar o que são, porque são importantes e como os atacantes tiram partido deles.

Risco 1: Caminhos de ataque de nível 0 abertos por permissões mal configuradas

Durante as intervenções da ADSA, uma das configurações erradas mais perigosas que a equipa da IFIR observou é quando contas ou grupos acabam por ter direitos de DCSync através de permissões indiretas. Isto não significa que alguém tenha atribuído diretamente essas permissões. Em vez disso, por exemplo, uma conta sem privilégios pode fazer parte de um grupo que tenha direitos de controlo total sobre uma conta privilegiada que já possua capacidades de DCSync.

Consequentemente, um atacante não precisa de visar diretamente a conta com privilégios. Pode atacar o elo mais fraco da cadeia e, mesmo assim, obter acesso ao mesmo nível de controlo. A configuração incorreta ocorre normalmente porque as permissões são delegadas de forma demasiado ampla, o que conduz a uma violação indireta de Nível 0 (Figura 1).

Figura 1. Esta análise mostra um indicador de exposição (IOE) resultante de uma configuração incorrecta das permissões delegadas.

Outro exemplo de um caminho de ataque que conduz a uma violação de Nível 0 é o comprometimento de uma conta com permissões de escrita em objectos do controlador de domínio (DC)(Figura 2). Este acesso pode ser utilizado abusivamente para efetuar um ataque RBCD (Resource-Based Constrained Delegation), permitindo ao atacante fazer-se passar por contas com privilégios elevados.

Figura 2. Este indicador expõe os utilizadores ou grupos não predefinidos aos quais foi dado acesso de escrita a um objeto DC.

Risco 2: Utilização excessiva de grupos do AD incorporados com privilégios elevados

Os ambientes Windows mais antigos incluem frequentemente grupos incorporados destinados à administração delegada em funções como Operadores de Contas, Operadores de Servidores, Operadores de Cópia de Segurança e Operadores de Impressão. Estes grupos são frequentemente ignorados, mas podem ainda deter privilégios elevados no Active Diretory(Figura 3). Se estes grupos forem preenchidos, os seus membros podem executar acções que conduzem ao aumento de privilégios e ao acesso direto a activos de Nível 0.

Figura 3. Esta análise examina o AD em busca de grupos incorporados antigos com privilégios elevados que representem um risco de segurança.

A utilização continuada de grupos incorporados antigos aumenta o risco de comprometimento, especialmente se as contas neles contidas não forem monitorizadas ou controladas de perto. As melhores práticas recomendam geralmente que se evite confiar na maioria dos grupos incorporados no AD (por exemplo, DnsAdmins, Administradores DHCP, Proprietários de Criadores de Políticas de Grupo, Utilizadores de Ambiente de Trabalho Remoto), uma vez que têm frequentemente permissões amplas(Figura 4).

Figura 4. Este indicador identifica membros de grupos comuns incorporados que podem ter permissões alargadas.

Risco 3: Configuração insegura do LAN Manager

O NT LAN Manager versão 1 (NTLMv1) é um protocolo de autenticação legado que ainda é surpreendentemente comum em alguns ambientes - mas não deveria ser. Ele usa criptografia fraca que torna fácil para os invasores capturar e quebrar o tráfego de autenticação(Figura 5). Se um atacante conseguir que uma máquina se autentique usando NTLMv1 (geralmente com uma ferramenta de ataque como o Responder), ele pode pegar o hash da senha e quebrá-lo offline para obter a senha de texto.

Figura 5. Este aviso da Microsoft chama a atenção para a vulnerabilidade de protocolos de autenticação desactualizados.

Atualmente, todos os sistemas operativos da Microsoft suportam a versão 2 do Gestor de LAN NT mais recente. Antes de impor o NTLMv2 em todo o domínio, comece por ativar a auditoria NTLM para identificar os sistemas ou aplicações que ainda utilizam o NTLMv1. Depois de analisar os registos e resolver quaisquer dependências herdadas, pode começar a configurar um Objeto de Política de Grupo (GPO) em todo o domínio para definir o nível de autenticação do LAN Manager para Send NTLMv2 response only. Refuse LM & NTLM (Figura 6). Esta definição impõe a autenticação moderna e bloqueia protocolos mais fracos.

Figura 6. Certifique-se de que define políticas de segurança para aplicar protocolos de autenticação modernos.

Risco 4: Configuração insegura do ADCS

A nossa equipa IFIR observa que os Serviços de Certificados do Active Diretory (ADCS) mal configurados continuam a ser um risco negligenciado mas de grande impacto em muitos ambientes. Quando os modelos de certificados, as permissões de registo ou as funcionalidades de registo na Web não estão devidamente protegidos, os atacantes podem abusar do ADCS para se fazerem passar por utilizadores, aumentar os privilégios e obter controlo não autorizado de sistemas sensíveis.

Um problema comum são os modelos de certificado demasiado permissivos que permitem que qualquer utilizador autenticado se inscreva para obter certificados com o Client Authentication EKU. Quando combinado com o ENROLLEE_SUPPLIES_SUBJECT esta configuração permite aos utilizadores especificarem eles próprios o assunto do certificado (Figura 7), que pode permitir que utilizadores pouco privilegiados solicitem certificados em nome de outras contas, incluindo Administradores de Domínio. Estes certificados podem então ser utilizados para se fazerem passar por essas contas e obterem acesso elevado. Este tipo de configuração incorrecta é classificado como ESC1.

Figura 7: Modelos de certificado ADCS mal configurados podem permitir que os atacantes solicitem certificados para contas com privilégios elevados e obtenham acesso elevado.

Um risco relacionado ocorre quando utilizadores pouco privilegiados têm a capacidade de modificar modelos de certificados. Os atacantes podem abusar desta vulnerabilidade para introduzir definições inseguras, tais como ativar ENROLLEE_SUPPLIES_SUBJECTque pode transformar um modelo anteriormente seguro num modelo vulnerável a ataques como o ESC1 (Figura 8). Este tipo de configuração incorrecta é abrangido pelo ESC4.

Figura 8. Este indicador de segurança avisa que as configurações incorrectas do modelo de certificado podem representar riscos.

Risco 5: Delegação sem restrições

A delegação sem restrições (Figura 9) é perigosa porque, quando um utilizador solicita um bilhete de serviço num servidor com esta configuração, o seu bilhete de concessão de bilhetes (TGT) é incluído e permanece na memória. Se um atacante assumir o controlo desse servidor, pode obter o TGT e utilizá-lo para se fazer passar pelo utilizador. O risco aumenta se o serviço «Windows Print Spooler» estiver a ser executado nos controladores de domínio (DCs). Um atacante pode utilizar a falha da impressora para fazer com que um DC se autentique no servidor comprometido, o que provoca a fuga do próprio TGT do DC e confere ao atacante controlo total.

Para reduzir o risco, certifique-se de que as suas contas de nível 0 ou equivalente têm o Account is sensitive and cannot be delegated marcada e adicione-os ao grupo Utilizadores protegidos.

Figura 9. A definição de uma delegação sem restrições num servidor expõe o Kerberos TGT a compromissos e abusos.

Risco 6: Utilizadores sem privilégios podem adicionar contas de computador ao domínio

Na maioria dos ambientes AD, qualquer utilizador autenticado pode adicionar até 10 computadores ao domínio. Trata-se de uma definição predefinida que é frequentemente esquecida. Mas os atacantes não se esquecem. Se obtiverem acesso a qualquer conta com privilégios reduzidos, podem criar um objeto computador(Figura 10) e utilizá-lo em ataques que aproveitam o RBCD.

A situação piora quando determinados modelos de certificado permitem que os computadores do domínio se registem e incluam o Client Authentication EKU com o ENROLLEE_SUPPLIES_SUBJECT flag. Esta combinação abre a porta a um ataque ESC1 clássico, no qual o atacante pode solicitar um certificado que lhe permite fazer-se passar por outro utilizador. Se não tiver uma razão para permitir que os utilizadores adicionem máquinas ao domínio, é melhor definir a opção ms-DS-MachineAccountQuota para 0 e bloquear isso.

Figura 10. Este indicador de segurança está a alertá-lo para a necessidade de garantir que os utilizadores não podem adicionar máquinas ao seu domínio.

Risco 7: Contas privilegiadas com SPN configurado

A atribuição de Nomes Principais de Serviço (SPNs) a contas de utilizador privilegiadas, como Admins. do Domínio ou outras contas de Nível 0, introduz um sério risco de segurança. Quando uma conta privilegiada tem um SPN (Figura 11), qualquer utilizador autenticado no domínio pode enviar um pedido de Kerberos Ticket-Granting Service (TGS) para a mesma. O bilhete que recebem é encriptado com o hash da palavra-passe da conta, o que significa que um atacante pode extraí-lo e efetuar um Querberoasting ataque. Um erro de configuração comum é a atribuição de um MSSQL SPN para a conta de Administrador incorporada (RID 500), o que dá aos atacantes um caminho Kerberoasting direto para uma das contas mais poderosas do domínio.

A questão principal é que o cracking acontece totalmente offline. Quando o atacante tem o bilhete, pode efetuar um ataque de força bruta ou de dicionário utilizando ferramentas como o hashcat sem gerar mais tráfego ou alertas no DC. As contas privilegiadas nunca devem ter SPNs atribuídos. Se um serviço necessitar de um SPN, deve ser executado numa conta de serviço separada e pouco privilegiada com uma palavra-passe forte e gerida.

Figura 11: Esta análise identifica contas privilegiadas com SPNs definidos.

Risco 8: Contas de serviço obsoletas ainda activadas

As contas de serviço tendem a acumular-se com o passar do tempo. São frequentemente criadas para sistemas que foram substituídos, scripts pontuais ou projetos antigos que já ninguém mantém. O problema é que muitas destas contas permanecem ativas muito tempo depois de já não serem necessárias. Algumas delas ainda têm permissões elevadas ou estão excluídas das políticas de palavra-passe habituais, o que as torna um alvo perfeito para os atacantes. Se uma destas contas esquecidas for comprometida, pode ser difícil detetá-lo. Uma vez que ninguém a está a utilizar ativamente, atividades suspeitas podem passar despercebidas.

Vale a pena rever as contas de serviço regularmente, como mostra a Figura 12 . Se uma conta não é utilizada há muito tempo e ninguém consegue justificar a sua finalidade, desactive-a e monitorize eventuais consequências.

Figura 12. A revisão regular das contas de serviço e da sua atividade ajuda a garantir que as contas não utilizadas são eliminadas antes de poderem ser comprometidas.

Risco 9: Falta de controlo de nível 0

A implementação de um modelo de classificação por níveis para toda a empresa é um desafio e muitas vezes irrealista. Mas ter um modelo mínimo para os sistemas de Nível 0 não é negociável.

O Nível 0 é constituído pelos sistemas que controlam a identidade e, se forem comprometidos, o resto do ambiente fica igualmente comprometido. Na maioria das ADSAs, constatámos que muitas organizações não dispõem de qualquer modelo de classificação por níveis.

Se ainda não estabeleceu um modelo de Nível 0, agora é a altura de começar. Para o ajudar, a Figura 13 apresenta uma lista de sistemas que são normalmente tratados como de Nível 0 em ambientes bem protegidos e um modelo para determinar o seu estatuto de Nível 0.

Figura 13. Compreender, identificar e proteger os activos de nível 0, como os que constam desta lista, é essencial para a cibersegurança da empresa.

Risco 10: Backups do Active Diretory não confiáveis e não restauráveis

O AD é o núcleo da autenticação e do acesso em todo o ambiente. E, no entanto, uma das lacunas mais críticas que ainda vemos em muitas organizações é a falta de uma estratégia de backup adequada para o Active Diretory.

Algumas organizações assumem que ter controladores de domínio espalhados pelos sites é suficiente, ou confiam em instantâneos de VM de uso geral sem validar se esses backups podem restaurar o AD de uma forma consistente e suportada.

A realidade é que se o Active Diretory cair e não houver um backup limpo e restaurável, a recuperação torna-se extremamente difícil, especialmente após um ataque cibernético.

Uma cópia de segurança fiável do AD não é apenas uma cópia ou um instantâneo ao nível do ficheiro. Crie um backup confiável e validado. Isole-o do domínio de produção. Proteja-o contra adulterações. E teste-o regularmente. Porque sem ela, está a deixar a sua infraestrutura mais crítica exposta a danos irreversíveis.

Instantâneo da Semperis

Numa altura em que os ciberataques não são uma questão de "se " mas de " quando", as organizações devem tomar medidas para garantir a resiliência antes, durante e depois de um incidente cibernético.

Comece por eliminar vulnerabilidades comuns como estas. Em seguida, estabeleça parcerias com especialistas em identidade e selecione ferramentas que privilegiem a identidade:

  • Reforçar as suas defesas
  • Estabelecer proactivamente estratégias eficazes de resposta a incidentes
  • Recuperar rapidamente quando ocorre um incidente
  • Reduzir o risco a longo prazo

Precisa de analisar mais profundamente a sua infraestrutura de identidade? Aproveite as décadas de conhecimento em primeira mão da nossa equipa IFIR.

Saiba mais sobre como eliminar as vulnerabilidades do Active Diretory