Mais cedo ou mais tarde, durante o teste, surge a tarefa de comprometer toda a floresta - desde que haja direitos em um dos domínios. Nesses momentos, muitas questões surgem sobre relações de confiança, suas propriedades e os próprios ataques. Vamos tentar descobrir tudo.
A confiança entre domínios é usada para autenticar usuários de um domínio no controlador de outro domínio. Em outras palavras, para que os usuários do domínio A possam ter acesso aos recursos do domínio B. A estrutura do domínio pode ser de dois tipos:
- Árvores de domínio
- florestas de domínio.
Ao criar uma árvore de domínios entre domínios, por padrão, relações de confiança transitivas são estabelecidas. Todos os computadores têm comum:
- catálogo global
- namespace
- esquema.
Árvores de domínio podem ser combinadas em florestas. Ao criar uma floresta de domínio, relações de confiança transitivas são estabelecidas e todos os computadores na floresta compartilham o seguinte:
A tabela abaixo mostra os tipos de confiança entre domínios e suas propriedades.
Mais claramente, os tipos de relações de confiança entre domínios são ilustrados na figura abaixo.
Transitividade
A transitividade é necessária para definir a confiança fora dos dois domínios entre os quais foi formada e é usada para expandir as relações de confiança com outros domínios. Se adicionarmos um domínio filho ao domínio, será estabelecida uma relação de confiança bidirecional entre os domínios pai e filho. Essas relações são transitivas, ou seja, se o domínio A confiar no domínio D e o domínio D confiar no domínio E, o domínio A também confiará no domínio E.
Confiança não-transitiva pode ser usada para negar confiança em outros domínios.
Direção
Um caminho de relacionamento de confiança é uma série de relacionamentos de confiança entre domínios para os quais as solicitações de autenticação devem ser recebidas. Em outras palavras, antes de autenticar um usuário, a confiança entre domínios é determinada. Para que os usuários do domínio A acessem os recursos do domínio D, o domínio D deve confiar no domínio A.
A direção da confiança é de dois tipos:
Confiança unidirecional é um caminho de autenticação unidirecional criado entre dois domínios. Na confiança unidirecional entre o domínio A e o domínio B, os usuários no domínio B têm acesso aos recursos no domínio A. No entanto, os usuários no domínio A não têm acesso aos recursos no domínio B. Esse tipo de confiança não é transitivo.
A confiança bilateral é uma combinação de dois relacionamentos de confiança unidirecionais. Na confiança bidirecional entre os domínios A e B, seus usuários têm acesso aos recursos dos dois domínios. Esse tipo de confiança é transitivo.
A direção da confiança é sempre oposta à direção do acesso. Diagrama representativo da Microsoft abaixo:
Links para tipos de confiança mais detalhados:
Kerberos entre domínios confiáveis
Considere um exemplo. O cliente está tentando acessar o servidor.
Dos pontos 1 a 3, ações padrão ocorrem ao usar o protocolo Kerberos.- A senha é convertida em um hash NTLM, o carimbo de data / hora é criptografado com um hash e enviado ao KDC como um autenticador na solicitação de ticket TGT (AS-REQ). O controlador de domínio (KDC) verifica as informações do usuário e cria um ticket TGT.
- O ticket TGT é criptografado, assinado e enviado ao usuário (AS-REP). Somente o serviço Kerberos (KRBTGT) pode abrir e ler dados de um ticket TGT.
- Um usuário envia um ticket TGT para um controlador de domínio ao solicitar um ticket TGS (TGS-REQ). O controlador de domínio abre um ticket TGT e verifica a soma de verificação PAC.
As alterações começam no ponto 4: um ticket TGT entre regiões aparece, o chamado ticket de referência, que é criptografado / assinado com uma chave entre regiões criada a partir de uma senha confiável. Uma senha confiável é definida quando a confiança é estabelecida e é conhecida pelos dois controladores de domínio. Usando o ticket TGT entre regiões, um usuário do domínio 1 pode solicitar um ticket TGS para acessar os recursos do domínio 2.
NTLM entre domínios confiáveis
- O cliente envia uma solicitação de autenticação diretamente ao próprio recurso, localizado em outro domínio, ao qual deseja acessar.
- O servidor recebe uma solicitação do cliente e envia uma resposta CHALLENGE_MESSAGE, que contém uma sequência aleatória de 8 bytes. É chamado de Desafio do Servidor.
- O cliente, tendo recebido a sequência de Desafio do Servidor do servidor, criptografa essa sequência com sua senha e envia ao servidor uma resposta que contém 24 bytes.
- O servidor envia uma solicitação e resposta ao controlador do seu domínio B.
- No caso de autenticação entre relações de confiança, a seguinte lógica é realizada:
- Relações de Confiança de Direção Verificadas.
- As credenciais do cliente são enviadas ao domínio A para autenticação.
- Se não houver relação de confiança, a transitividade é verificada com o domínio A.
- Verificação de transitividade entre domínios
- Se houver transitividade entre domínios, uma solicitação de autenticação será enviada para o próximo domínio no caminho confiável. Esse controlador de domínio repete o processo, verificando as credenciais do usuário em seu banco de dados de contas de segurança.
- Se não houver transitividade, uma mensagem de acesso negado será retornada ao cliente.
6-8. A resposta com a decisão de autenticar o cliente.
Ataques entre relações de confiança entre domínios
Portanto, para realizar um ataque, precisamos de informações sobre relacionamentos confiáveis em nosso domínio.
Relações de confiança da lista
Existem três métodos principais para listar relações de confiança em um domínio:
- através da API do Win32;
- via métodos .NET;
- através do LDAP.
API do Win32
A enumeração é realizada chamando a função DsEnumerateDomainTrusts , que retorna a estrutura DS_DOMAIN_TRUSTSA . Usando esse método, o SID e o GUID do domínio de destino, sinalizadores e atributos que caracterizam a confiança atual no domínio são retornados.
O BloodHound coleta informações usando o método API Win32.
.Net
O método GetCurrentDomain do espaço de nome [System.DirectoryServices.ActiveDirectory.Domain] é usado, que retorna uma instância da classe System.DirectoryServices.ActiveDirectory.Domain . Essa classe implementa o método GetAllTrustRelationships , que retorna todas as relações de confiança para o domínio atual.
([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()
O uso desse método é implementado no módulo Get-DomainTrust no PowerView .
Uma das vantagens desse método é sua simplicidade. As informações são fáceis de ler e entender, mas seu volume é muito menor do que quando se faz a enumeração por outros métodos.
LDAP
As informações de confiança do domínio são armazenadas no Active Directory como um objectClass da classe trustDomain .
Exemplo de uso:
dsquery * -filter "(objectClass=trustedDomain)" -attr *
O PowerView usa esse método por padrão.
Com informações sobre domínios e tipos de confiança, você pode ir diretamente para o próprio ataque. Considere duas opções:
- Conseguimos comprometer o domínio e temos direitos de administrador de domínio.
- Não temos direitos de administrador de domínio.
Com direitos de administrador em um dos domínios
Dependendo do domínio que foi comprometido, vários vetores de ataque podem ser distinguidos:
Vale ressaltar que, para a implementação bem-sucedida de todos os vetores, é necessária uma confiança bilateral entre domínios.
1. Histórico de operação SID
O histórico do SID foi introduzido para facilitar a migração de usuários de um domínio para outro. O atributo contém os objetos SID anteriores. Cada vez que um objeto se move de um domínio para outro, um novo SID é criado, que se torna um objectSID. O SID anterior é adicionado à propriedade sIDHistory.
Cada floresta possui um grupo de usuários Admins da empresa que existe apenas no domínio raiz e possui direitos de administrador local nos controladores de domínio de todos os domínios filho da floresta. Este ataque foi demonstrado pela primeira vez por Sean Metcalf no BlackHat USA 2015 . A essência do ataque é que estamos emitindo um tíquete Golden com a adição de um SID adicional do grupo Administradores da Empresa. Isso é feito adicionando ExtraSids na estrutura KERB_SID_AND_ATTRIBUTES , que é enviada na estrutura KERB_VALIDATION_INFO .
Demonstração de Ataque:
Impacket tem um script que automatiza tudo isso.
2. Golden Ticket + Grupo de Administradores Corporativos
Tendo direitos de administrador no domínio Raiz, podemos criar um Golden Ticket com a adição de um usuário ao grupo Administradores Corporativos (519).
Kerberos::golden /domain:<domain> /sid:<domain_SID> /krbtgt:<ntlm_hash_krbtgt_user> /user:<user> /groups:500,501,513,512,520,518,519 /ptt
Como descrito acima, o Enterprise Admin possui direitos de administrador local para domínios do DC Child. Assim, seremos capazes de comprometer todos os domínios filho na floresta.
3. Operação de tickets de confiança
Para acessar um recurso usando o protocolo Kerberos, você precisa de um ticket TGS, criptografado com o hash NTLM da senha da conta de serviço. Um controlador de domínio armazena apenas hashes de senhas de usuário para seu domínio. Portanto, quando um usuário do domínio A precisa acessar um recurso no domínio B, uma chave entre regiões é usada. Essa chave é criada com base em uma senha confiável, definida ao criar relações de confiança entre domínios na mesma floresta. No banco de dados de senhas (NTDS.dit) no controlador de domínio, você pode encontrar usuários com o sinal $ no final. Sua senha também é usada para criar chaves entre domínios. Para criar um ticket TGT entre regiões, precisamos de um hash de senha desta conta.
Kerberos::golden /user:<user> /domain:<domain> /sid:<sid_domain> /sids:<extra_sid_entrprice_admin_group_from _another_domain> /aes256:<aes256_trust_user_password> /service:krbtgt /target:<target_domain> /ptt
Demonstração de Ataque:
O ataque é especialmente relevante quando o serviço de IS notou uma ameaça e alterou a senha krbtgt 2 vezes. Nesse caso, poderemos criar tickets dourados usando uma senha confiável entre domínios.
4. Erro na impressora
O Protocolo Remoto do Sistema de Impressão do Windows (MS-RPRN) tem o método RpcRemoteFindFirstPrinterChangeNotification (Ex) ativado por padrão, o que permite forçar a autenticação em qualquer computador executando o serviço Spooler no host especificado usando o protocolo Kerberos ou NTLM. No caso de c NTLM, podemos executar o NTLM-relay ou começar a decifrar a senha do computador (nunca desmarque). No caso do Kerberos, é necessária uma máquina comprometida com delegação ilimitada. Então podemos pegar um tíquete do TGT e desenvolver um ataque.
Demonstração de Ataque:
A figura abaixo mostra as etapas mostradas no vídeo.
Não temos direitos de administrador de domínio
Um pouco de teoria. Carlos Garsia, em seu relatório, apresentou uma excelente tabela que ilustra as propriedades de diferentes tipos de grupos.
Entre os recursos, vale considerar que os grupos Local do Domínio do AD e Global do AD são replicados sem membros do grupo no catálogo global, e os grupos do AD Universal são replicados com os usuários.
Devido à maneira como os grupos são enumerados pelo Catálogo Global, os resultados de um link reverso [ou seja, pesquisa memb podem variar, dependendo de você pesquisar no Catálogo Global (porta 3268) ou no domínio (porta 389), o tipo de grupos aos quais o usuário pertence (grupos globais x grupos locais de domínio).
Caso não tenhamos direitos de administrador de domínio, enumeramos os objetos. Estamos interessados em:
- Usuários de outro domínio que possuem direitos de administrador local em máquinas em nosso domínio.
- Usuários de outros domínios que são membros de grupos de domínio do usuário. Grupos contendo usuários de outro domínio.
- Principais ACL estrangeiros.
1. Usuários de outro domínio com direitos de administrador local em máquinas em nosso domínio
Procure usuários de outro domínio que sejam administradores locais em hosts em nosso domínio no BloodHound:
MATCH (c:Computer) OPTIONAL MATCH p1 = (u1)-[:AdminTo]->(c) WHERE NOT u1.domain = c.domain WITH p1,c OPTIONAL MATCH p2 = (u2)-[:MemberOf*1..]->(:Group)-[:AdminTo]->(c) WHERE NOT u2.domain = c.domain RETURN p1,p2
Comando no PowerView :
Get-NetLocalGroupMember <server>
2. Usuários de outros domínios, consistindo em grupos de domínio do usuário. Grupos contendo usuários de outro domínio
Como mencionado acima, usuários que são membros apenas de grupos universais são replicados para o catálogo global. Para demonstrar esse recurso, consultaremos grupos no catálogo global que contêm pelo menos um usuário e uma solicitação LDAP direta ao controlador de domínio.
Get-DomainGroup -Properties name, grouptype, member, DistinguishedName -LDAPFilter '(member=*)' -SearchBase "GC://jet.lab"
Ao executar uma consulta ao catálogo global, vemos apenas um grupo Universal Group com o tipo AD Universal do domínio one.jet.lab.
Se executarmos uma consulta LDAP direta para one.jet.lab, veremos outros grupos com o tipo AD Domain local e AD Global.
É importante considerar ao enumerar usuários e grupos.
Comandos no PowerView :
Get-DomainForeignUser -Domain <Domain> Get-DomainForeignGroupMember -Domain <Domain>
3. Principais ACL estrangeiros
O descritor de segurança ntSecurityDescriptor (https://docs.microsoft.com/en-us/windows/win32/adschema/a-ntsecuritydescriptor) está acessível a todos os usuários de domínios confiáveis e é replicado no catálogo global. Assim, podemos consultar todas as DACLs para todos os objetos em domínios confiáveis e filtrar usuários de outros domínios.
Get-DomainObjectAcl -Domain jet.lab -ResolveGuids | ?{$_.SecurityIdentifier -like 'SID_Domain*'}
Assim, conseguimos identificar o usuário Mike no domínio forestc.lab, que tinha direitos ao Grupo Global no domínio jet.lab.
A filtragem PS SID e a autenticação seletiva são usadas para proteção entre florestas. Um ataque entre florestas com a filtragem de SID ativou o dirkjan em seu blog . Também em 9 de julho, a Microsoft lançou uma atualização que desabilita a delegação de TGT entre florestas por padrão. Agora, tudo, a história com delegação ilimitada e comprometimento de uma floresta da outra usando o protocolo Kerberos não funciona mais.