Active Directory: pentest de domínio, enumeração e mitigação

O que é Active Directory - Apresentação

Apresentando o curso e o instrutor

Olá, estudantes. É um prazer estar aqui com vocês. Vamos ao nosso curso Active Directory: pentest de domínio, enumeração e mitigação, dentro da trilha de pentesting na Alura. Meu nome é Felipe Monteiro.

Audiodescrição: Felipe é um homem branco, está sentado em frente ao computador, com uma parede clara ao fundo e iluminação em tons de azul e lilás.

Definindo a proposta e a estrutura do curso

A proposta deste curso é o pentest (teste de invasão) interno: enumerar o domínio, entender como identidades e permissões se conectam e estudar ataques; analisar movimentações laterais até chegarmos à escalada de privilégios, com evidência técnica para consolidação em formato de relatório.

Nosso curso está organizado em sete aulas. Nós começamos pela arquitetura do Active Directory (Diretório Ativo), para entender o domínio, os controladores, os objetos, os grupos e as permissões.

Explorando protocolos e tópicos de segurança

Em seguida, seguimos para protocolos e autenticação, como DNS, que é o Domain Name System (Sistema de Nomes de Domínio); o Lightweight Directory Access Protocol (Protocolo de Acesso a Diretório Leve), LDAP; o Server Message Block (Bloco de Mensagens de Servidor), SMB; NTLM; e Kerberos. Todos esses são conceitos muito importantes no contexto do Active Directory (Diretório Ativo).

Na sequência, entraremos na parte de enumeração. Já começamos a pensar como pessoa pentester (profissional de teste de invasão), abordando ataques a credenciais, movimentação lateral, Kerberos avançado e escalada de privilégios.

Encadeando reconhecimento, enumeração e escalada

Todas as aulas foram planejadas como uma cadeia lógica. O reconhecimento da primeira aula alimentará o mapeamento dos protocolos. Esse mapeamento nos ajudará na parte de enumeração, que é a base de qualquer pentest (teste de invasão). Primeiro, precisamos entender com o que estamos lidando antes de avançarmos.

Na fase de enumeração, nós identificamos contas, grupos, hosts (máquinas) e políticas que podem orientar ataques a credenciais. Credenciais validadas abrem caminho para a movimentação lateral, que, por sua vez, pode levar à escalada de privilégios dentro do domínio. Todo esse processo deve sempre terminar com evidências organizadas, porque um pentest (teste de intrusão) não termina com um único comando; ele exige uma conclusão técnica. Essa postura é o que diferencia um trabalho profissional.

Preparando o ambiente e a metodologia prática

Agora, na parte prática, nós utilizaremos o projeto disponível no GitHub, no link de referência: Game of Active Directory (Jogo do Active Directory), GOAD. Para continuar, recomendamos fortemente instalar o ambiente do GOAD. Para acompanhar os conceitos e grande parte das práticas, a recomendação mínima é o GOAD com a Workstation (Estação de Trabalho) WS01. Entretanto, se você, estudante, tiver mais recursos computacionais, o GOAD Lite (Leve) é uma ótima opção intermediária. Mas, se quiser acompanhar com paridade total o que será realizado, o GOAD completo é um ambiente adequado. Quando alguma prática depender de um recurso que não exista em qualquer dessas versões, nós deixaremos essa limitação explícita.

A metodologia do curso seguirá um ciclo simples: primeiro, nós entendemos um conceito; depois, validamos essa premissa; e, por fim, interpretamos as evidências obtidas. Essa ordem será muito importante, porque a ferramenta não substituirá o raciocínio.

Antecipando a próxima aula e encerrando

Na próxima aula, nós começaremos a base técnica da jornada: o que é o Active Directory (Diretório Ativo) e por que ele é tão valioso em um ambiente interno? Por que pensá-lo como um sistema de identidade, autenticação, autorização e administração centralizada?

Agradecemos sua presença e nos vemos na próxima aula!

O que é Active Directory - O que é Active Directory

Iniciando o curso e definindo objetivos

Olá a todas as pessoas. Vamos começar de fato nosso curso. Nesta primeira parte da aula, nosso objetivo é simples: entender o que é o Active Directory (Diretório Ativo) e por que ele costuma ser o alvo mais valioso em uma avaliação de segurança interna. Nossa meta é construir um modelo mental correto de como o AD funciona. O AD controla identidades, autenticação, políticas e computadores. Ele também concentra grande parte do caminho que uma pessoa atacante percorre dentro de uma rede corporativa interna.

Neste vídeo, não vamos aprofundar em conceitos mais complexos. Precisamos ser capazes de responder a três perguntas:

• Quem é a pessoa autenticada?
• Onde estão os objetos importantes?
• Por que comprometer o AD muda o impacto do ataque?

Definindo o serviço de diretório e contextualizando impacto

O Active Directory (Diretório Ativo) é um serviço de diretórios. Em termos práticos, isso significa que ele armazena informações sobre objetos de rede, como usuários, computadores, grupos, servidores, recursos compartilhados e configurações. No entanto, ele não é apenas uma lista telefônica corporativa, vista de forma simples. O AD também participa da autenticação, do controle de acesso e da administração centralizada do domínio. Por isso, em uma rede corporativa Windows, ele funciona como um plano de controle completo.

Para uma pessoa atacante, isso importa porque quase todo o impacto relevante passa por identidades. Se entendermos usuários, grupos, computadores e permissões, poderemos descobrir quem tem acesso ao quê. Se entendermos os processos de autenticação, saberemos quais credenciais poderemos usar depois, por exemplo. Se entendermos a administração centralizada, saberemos onde uma configuração mal feita afetará várias máquinas ao mesmo tempo.

Enfatizando encadeamentos e apresentando o laboratório

Aqui já percebemos que o AD não se reduz a encontrar uma vulnerabilidade específica, e sim ao encadeamento lógico de várias configurações mal feitas, que podem afetar todo o domínio. De fato, raramente encontraremos uma vulnerabilidade lógica do tipo exploit (exploração) que afete o Active Directory (Diretório Ativo). Na maioria das vezes, exploraremos configurações e más práticas de segurança implementadas dentro desse domínio.

O laboratório de referência do curso é o Gold (Ouro), como dito na aula de introdução. No Gold (Ouro) completo, a documentação oficial descreve três domínios e duas florestas — entenderemos esses conceitos mais adiante. No Gold Lite (Ouro Lite), o ambiente removeu o Essos e será um pouco menor. No Gold Mini (Ouro Mini), o enfoque é muito mais minimalista: um domínio, 7kingdoms.local, com o controlador de domínio KingsLanding. Por ora, o Gold Mini (Ouro Mini) é suficiente para acompanhar boa parte da aula, porque o conceito principal é entender o papel do AD, não explorar cruzamentos ou múltiplas florestas em caminhos mais avançados. Não nos preocuparemos com isso agora.

Mapeando serviços do ambiente e preparando a enumeração

Vale mapear os serviços que justificam o valor do AD:

• DNS (Sistema de Nomes de Domínio): ajuda clientes a localizar controladores de domínio dentro de um Active Directory (Diretório Ativo).
• Kerberos: participa da autenticação do domínio.
• LDAP (Protocolo Leve de Acesso a Diretórios): permite consultar objetos do diretório.
• SMB (Bloco de Mensagens do Servidor): aparece em acessos e compartilhamentos e também em componentes como o SYSVOL (Volume do Sistema).
• RPC (Chamada de Procedimento Remoto): aparece em várias operações administrativas e de domínio.

Por ora, não atacaremos esse serviço. Nosso objetivo é apenas mostrar por que o AD tem uma superfície tão grande para enumeração, o que nos permite fazer várias deduções. Exploraremos isso mais a fundo nas próximas aulas.

Caracterizando o vetor de ataque por identidade

Quando falamos de AD, o vetor de ataque muitas vezes não é uma vulnerabilidade específica. O vetor é o próprio modelo de identidade centralizada que o AD possui. Uma conta comum revelará grupos, relações, máquinas acessíveis e caminhos de privilégio.

A pessoa atacante não precisa começar como Domain Admin (Administrador de Domínio). Muitas vezes, começará com uma credencial fraca, uma sessão em uma estação de trabalho com poucos privilégios e uma configuração mal delegada. O valor do Active Directory (AD) está em transformar uma identidade pequena e com pouco valor em um mapa bem definido de oportunidades que poderemos usar posteriormente.

Modelando objetos e relações no diretório

No Active Directory, quase tudo está representado como um objeto no diretório: usuário, computador, grupo, unidades organizacionais (OUs), GPOs e contas de serviço. Cada um desses objetos tem atributos. O usuário pode ter nome, pertencer a um grupo, ter configurações de início de sessão e outros metadados. O computador também é um objeto com nome e sistema associado, relações de domínio e permissões. Um grupo é outro objeto.

Um ponto importante é que esses objetos não existem de forma isolada; sempre se conectam por relações. O usuário pertencerá a um grupo, e um grupo tem privilégios, que têm GPOs aplicadas a uma unidade organizacional. Um administrador local, por sua vez, controla uma máquina específica. Do ponto de vista da defesa, isso permite administrar a empresa em escala. Para uma pessoa atacante, isso se torna um mapa de caminhos: se controlarmos este objeto, quais relações poderemos usar para chegar a outro objeto mais valioso? Essa é a lógica de ataque dentro do AD. Queremos construir um encadeamento lógico.

Priorizando o controlador de domínio e reconhecendo desafios

Quando exploramos um AD, normalmente nos concentramos em comprometer o controlador de domínio. Isso ocorre porque o AD sustenta funções centrais do domínio: participa da autenticação, mantém a base do diretório para esse domínio, replica dados com outros controladores de domínio, quando existem, e permite que políticas e configurações sejam aplicadas no âmbito do domínio. Em muitos cenários de pentest (teste de invasão), o objetivo final é chegar a uma conta de Administrador do Domínio, para comprometer o domínio em sua totalidade. Não é porque o título “comprometer o controlador de domínio” soa bem; é porque esse nível de controle altera o alcance do ataque.

O AD é difícil de proteger porque mistura compatibilidade, administração descentralizada e dependências de negócio. Empresas e instituições acumulam grupos antigos, usuários antigos, servidores antigos e delegações que eram temporárias e acabam se tornando permanentes, o que é muito comum. Existem GPOs criadas para resolver urgências e esquecidas, e contas de serviço com privilégios que não deveriam ter. A superfície é grande porque o AD abrange e toca muitas áreas.

Orientando a análise com quatro perguntas

A partir daqui, precisamos pensar no AD com quatro perguntas:

• Quem somos dentro do domínio?
• Onde essa identidade pode se autenticar?
• O que essa identidade pode acessar?
• Como essas relações podem escalar?

Essa leitura será usada o tempo todo a partir de agora: quando analisarmos o DNS e os protocolos associados, quando fizermos a enumeração do domínio, quando atacarmos credenciais e quando interpretarmos um caminho com ferramentas mais avançadas.

Resumindo a aula e antecipando próximos passos

O resumo desta aula: o AD centraliza identidade, autenticação, autorização e administração na rede Windows. Por isso, comprometer o AD com uma identidade relevante dentro dele pode ter um impacto muito maior do que comprometer uma máquina isolada. O ponto mais importante: um ataque em AD quase nunca é um evento único; é um caminho.

Nas próximas partes da aula, vamos abrir esse caminho em componentes: domínio, florestas, controlador de domínio, DNS, KDCs, objetos, GPOs, grupos e permissões. São conceitos que ainda nos são pouco familiares, mas nós os exploraremos com calma e entenderemos a importância de cada um dentro do pentest (teste de invasão) de Active Directory.

Obrigade, e até a próxima aula.

O que é Active Directory - Estrutura lógica do Active Directory

Introduzindo o mapa do Active Directory

Olá a todas as pessoas.

Na primeira parte da aula, vimos que o Active Directory (Diretório Ativo — AD) concentra identidades, computadores, grupos e políticas. Agora vamos nos aprofundar nesse mapa, nesse conceito. Quando encontrarmos um nome como 7kingdoms.local, o que ele representa? Onde entram os outros domínios? Até onde uma identidade pode ser reconhecida?

Para responder a essas perguntas, primeiro precisamos entender o que é um domínio, depois o que é uma árvore, uma floresta, unidades organizacionais — Organizational Units (Unidades Organizacionais — OU), que veremos com frequência — e relações de confiança. Esta etapa lembra a analogia de afiar o machado antes de cortar a árvore: se tivermos 5 horas para cortar uma árvore, é melhor dedicar 4 horas para afiar o machado, deixando um fio muito bom, e usar a última hora para cortar a árvore, garantindo eficiência no trabalho. No nosso caso, afiar o machado significa aprender a ler o ambiente antes de iniciar a enumeração, em vez de partir diretamente para o ataque. Um nome de domínio, uma OU ou uma relação de confiança não são apenas termos administrativos; cada um mostra uma parte diferente do caminho que uma identidade pode percorrer.

Diferenciando mapas e contextualizando no GOAD

Vamos construir esse mapa aos poucos, começando pela diferença entre a estrutura lógica do AD e a estrutura física da rede. Ao observarmos esse esquema por camadas, é importante não misturar dois mapas diferentes. O primeiro é o mapa físico da rede, com sub-redes, roteadores, VLANs, centros de dados e outros componentes. O segundo é o mapa lógico do Active Directory, que organiza identidades, políticas e relações administrativas. Por isso, um domínio não é uma sub-rede, uma OU não é uma VLAN e uma floresta também não é um centro de dados. Não vamos confundir esses conceitos. Os dois mapas se relacionam, mas respondem a perguntas diferentes.

Vamos levar essa diferença para o nosso laboratório, o GOAD. Na estrutura principal, temos 7kingdoms.local. Abaixo, aparece north.7kingdoms.local. O próprio nome já indica que existe uma relação entre ambos, algo interessante para observar. Ao lado, temos essos.local, que não compartilha o mesmo nome e pertence a outra floresta. Antes de pensarmos em ferramentas para trabalhar no AD ou em endereços IP, vamos observar o diagrama. Nele, vemos dois domínios relacionados dentro de uma estrutura e um terceiro domínio separado em outra floresta, o que facilita a visualização.

Voltando ao nosso material, dependendo da versão do GOAD, parte desse mapa pode não aparecer. No GOAD Lite, ainda será possível comparar 7kingdoms.local com o domínio filho north.7kingdoms.local. A floresta do domínio essos.local fica de fora. No GOAD Mini, temos apenas 7kingdoms.local. Quem usar o Mini poderá acompanhar o domínio e a organização interna, mas não encontrará os outros domínios e as relações entre florestas. O conceito é o mesmo; o que muda é o tamanho do cenário disponível para observação.

Apresentando protocolos e o escopo do domínio

Até agora analisamos nomes e limites. Como uma máquina encontra e usa tudo isso dentro de um AD? O DNS ajuda a localizar os serviços e os Controladores de Domínio. O Kerberos participa da autenticação. O LDAP — Lightweight Directory Access Protocol (Protocolo Leve de Acesso a Diretórios) — permite consultar os objetos do diretório. O SMB aparece no acesso e no compartilhamento do SYSVOL (volume do sistema). O RPC — Remote Procedure Call (Chamada de Procedimento Remoto) — participa de várias operações administrativas dentro do Active Directory. Esses protocolos, ainda um pouco abstratos, são a base que sustenta o conceito do AD em si. Por isso, reaparecerão quando começarmos a observar o domínio mais a fundo.

Vamos abrir a primeira parte desse diagrama: o domínio 7kingdoms.local. Dentro dele, encontraremos contas de usuário, contas de computador, grupos e Objetos de Política de Grupo (GPOs). Os Controladores de Domínio mantêm e replicam os dados desse domínio. Isso torna o próprio domínio um limite importante para identidade, autenticação e administração.

Em um pentest (teste de intrusão), que é o que nos importa ao final, é dentro desse limite que começamos a formular perguntas: Quais contas existem? Quais computadores pertencem ao domínio? Quais grupos concentram privilégios? Quais políticas afetam esses objetos? Fica evidente a importância de entender o conceito do AD — como funciona e por que cada protocolo opera de determinada maneira — para sabermos quais perguntas fazer.

Explicando árvores e distinguindo domínios

Uma floresta pode ter vários domínios, mas também pode ter apenas um, o que não é incomum. Compare 7kingdoms.local com north.7kingdoms.local. O domínio north.7kingdoms.local mantém o nome do domínio pai dentro do próprio DNS. Essa continuidade forma uma árvore. Podemos pensar na árvore como uma família de domínios que compartilham uma hierarquia de nomes.

Ainda assim, 7kingdoms.local e north.7kingdoms.local continuam sendo domínios diferentes. Cada um possui seus objetos, seus Domain Controllers (Controladores de Domínio) e suas administrações. A árvore mostra a relação entre eles, mas não os converte em um único domínio. É importante manter esse conceito, porque mais adiante, quando estivermos trabalhando em técnicas de exploração mais avançadas, ele será essencial.

Definindo florestas e questionando relações de confiança

Se 7kingdoms.local e north.7kingdoms.local fazem parte da mesma árvore, onde entra essos.local? Ele pertence a outra floresta. A floresta é o limite lógico mais alto do Active Directory e pode reunir um ou mais domínios que compartilham esquema e configuração. Os domínios de uma mesma floresta possuem relações de confiança automáticas. Entre florestas diferentes, essas relações dependem da configuração.

Quando encontrarmos uma segunda floresta, a pergunta passa a ser: existe alguma relação que permita reconhecer identidades entre ambos os lados?

Organizando objetos e introduzindo relações de confiança

Continuando, dentro de um domínio ainda precisamos organizar pessoas usuárias, equipamentos e servidores. Entram aqui as Organizational Units (Unidades Organizacionais), ou OUs. Podemos criar uma OU para estações de trabalho, outra para servidores e outra para determinados usuários. Essa organização permite aplicar as Group Policy Objects (Objetos de Política de Grupo), ou GPOs, e delegar tarefas administrativas. Contudo, OU e grupos cumprem papéis diferentes. Não vamos confundir esses conceitos; esta é uma base que fará muita diferença mais adiante. O grupo reúne identidades para receber permissões. Já a OU organiza objetos e define um escopo de administração. Colocar uma conta em uma OU, por si só, não concede privilégios.

Agora, imaginemos que uma conta de north.7kingdoms.local tente acessar um recurso em outro domínio. Para que a identidade seja reconhecida, deve existir uma relação de confiança, ou trust (confiança). Essa relação abre um caminho de autenticação entre os domínios, mas o acesso ainda não está garantido. Depois de reconhecer a identidade, o recurso verifica grupos, controles de acesso — as Access Control Lists (Listas de Controle de Acesso), ou ACLs —, permissões locais e políticas. Uma conta pode se autenticar no outro lado e, ainda assim, não ter autorização para usar o recurso, porque se trata de outro domínio. Por isso, trust (confiança) não significa permissão automática.

Detalhando direção e transitividade das confianças

Para entender a direção do trust (confiança), pensemos em dois portais de acesso. Se a guarita do domínio A reconhece a credencial emitida pelo domínio B, uma identidade de B pode ser autenticada em A. Isso não quer dizer que a guarita de B também reconheça as credenciais de A. Quando o reconhecimento funciona em um único sentido, temos uma confiança unidirecional. Quando funciona em ambos, a confiança é bidirecional.

A transitividade responde a outra pergunta: se A confia em B e B confia em C, essa relação também pode alcançar C? Em um trust (confiança) transitivo, o caminho pode continuar assim. Em um trust (confiança) não transitivo, ele termina na relação direta. Dentro de uma mesma floresta, as relações entre domínio pai e domínio filho normalmente são bidirecionais e transitivas. Já entre florestas, precisamos verificar a configuração antes de concluir. E o limite da analogia permanece o mesmo: reconhecer uma credencial não significa abrir todas as portas automaticamente.

Visualizando o diagrama e mapeando movimentos de ataque

É interessante visualizar isso no diagrama do domínio. Não vamos nos aprofundar nesse ponto agora para não confundir os conceitos, mas retornaremos a ele mais adiante.

Vamos colocar uma identidade comprometida nesse mapa. Primeiro, descobrimos a qual domínio ela pertence. Depois, verificamos os grupos e as permissões dessa conta. Se houver outros domínios ou florestas, buscamos relações de trust (confiança) que permitam autenticação fora do domínio de origem. Só então verificamos se existe autorização em algum recurso do outro lado. Percebamos a sequência: identidade, caminho de autenticação e permissão. A existência de um trust (confiança) é uma possibilidade de comunicação, não uma vulnerabilidade por si só.

Consolidando entendimentos e revisitando o diagrama

Aqui vemos que north.7kingdoms.local tem uma confiança bidirecional com 7kingdoms.local. É importante começarmos a absorver esses entendimentos, porque mais adiante, quando estivermos realizando ataques mais avançados, eles serão muito mais manejáveis.

Voltando ao diagrama completo: o domínio reúne identidades, equipamentos, grupos e políticas. Quando o domínio segue uma hierarquia contínua de nomes, temos uma árvore. Uma ou mais árvores formam uma floresta, que é o limite lógico maior dentro do Active Directory (Diretório Ativo). Dentro do domínio, as OUs ajudam a organizar objetos, aplicar as GPOs e delegar a administração. E, quando as identidades precisam ser reconhecidas entre domínios ou florestas, entram as relações de trust (confiança). Podemos, inclusive, retornar à imagem do nosso domínio para acompanhar isso.

Enfatizando autenticação versus autorização e indicando próximos passos

Guardemos especialmente esta separação: trust (confiança) permite autenticação; a permissão ainda depende de autorização. Com esse mapa montado, já temos a base para interpretar o que aparece durante a enumeração. Quando encontrarmos um domínio, uma OU ou uma relação de trust (confiança), saberemos qual pergunta fazer e o que esse elemento representará em nossa análise como pessoas atacantes.

Na próxima parte, seguimos para o componente que sustenta essa estrutura: os Domain Controllers (Controladores de Domínio), um DNS (Sistema de Nomes de Domínio) integrado e o Key Distribution Center (Centro de Distribuição de Chaves), o KDC.

[♪]

Sobre o curso Active Directory: pentest de domínio, enumeração e mitigação

O curso Active Directory: pentest de domínio, enumeração e mitigação possui 352 minutos de vídeos, em um total de 73 atividades. Gostou? Conheça nossos outros cursos de Red Team & Pentest em Cibersegurança, ou leia nossos artigos de Cibersegurança.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Arquitetura do Active Directory para pentesters