Az - Cloud Kerberos Trust

Reading time: 8 minutes

Este post é um resumo de https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ que pode ser consultado para mais informações sobre o ataque. Esta técnica também é comentada em https://www.youtube.com/watch?v=AFay_58QubY.

Visão Geral da Relação de Confiança Kerberos

Cloud Kerberos Trust (Entra ID -> AD) -- Este recurso (parte do Windows Hello for Business) estabelece uma confiança unidirecional onde o AD local confia no Entra ID para emitir tickets Kerberos para o AD. Habilitá-lo cria um objeto de computador AzureADKerberos$ no AD (aparecendo como um Controlador de Domínio Somente Leitura) e uma conta vinculada krbtgt_AzureAD (um KRBTGT secundário). O Entra ID detém as chaves para essas contas e pode emitir TGTs Kerberos "parciais" para usuários do AD. Os controladores de domínio do AD honrarão esses tickets, mas com restrições semelhantes a RODC: por padrão, grupos de alta privilégio (Domain Admins, Enterprise Admins, etc.) são negados e usuários comuns são permitidos. Isso impede que o Entra ID autentique administradores de domínio via a confiança em condições normais. No entanto, como veremos, um atacante com privilégios suficientes no Entra ID pode abusar desse design de confiança.

Pivotando do Entra ID para o AD Local

Cenário: A organização alvo tem Cloud Kerberos Trust habilitado para autenticação sem senha. Um atacante obteve privilégios de Global Administrator no Entra ID (Azure AD), mas ainda não controla o AD local. O atacante também tem um ponto de apoio com acesso à rede a um Controlador de Domínio (via VPN ou uma VM do Azure em rede híbrida). Usando a confiança na nuvem, o atacante pode aproveitar o controle do Azure AD para obter um ponto de apoio de nível Domain Admin no AD.

Pré-requisitos:

• Cloud Kerberos Trust está configurado no ambiente híbrido (indicador: uma conta RODC AzureADKerberos$ existe no AD).

• O atacante possui direitos de Global Admin (ou Hybrid Identity Admin) no locatário do Entra ID (esses papéis podem usar a API de sincronização do AD Connect para modificar usuários do Azure AD).

• Pelo menos uma conta de usuário híbrida (existe tanto no AD quanto no AAD) que o atacante pode autenticar. Isso pode ser obtido conhecendo ou redefinindo suas credenciais ou atribuindo um método sem senha (por exemplo, um Temporary Access Pass) para gerar um Primary Refresh Token (PRT) para ela.

• Uma conta de alvo do AD local com altos privilégios que não está na política de "negação" padrão do RODC. Na prática, um ótimo alvo é a conta de sincronização do AD Connect (geralmente nomeada MSOL_*), que possui direitos DCSync (replicação) no AD, mas geralmente não é membro de grupos de administradores integrados. Esta conta normalmente não é sincronizada com o Entra ID, tornando seu SID disponível para impersonação sem conflito.

Passos do Ataque:

1. Obter Acesso à API de Sincronização do Azure AD: Usando a conta de Global Admin, adquira um token de acesso para a API de Provisionamento (sincronização) do Azure AD. Isso pode ser feito com ferramentas como ROADtools ou AADInternals. Por exemplo, com ROADtools (roadtx):

# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph

(Alternativamente, o Connect-AADInt do AADInternals pode ser usado para autenticar como Administrador Global.)

2. Modifique os Atributos On-Prem de um Usuário Híbrido: Aproveite a API de sincronização do Azure AD para definir o Identificador de Segurança (SID) e o SAMAccountName de um usuário híbrido escolhido para corresponder à conta AD de destino. Isso efetivamente informa ao Azure AD que o usuário da nuvem corresponde à conta on-prem que queremos impersonar. Usando o kit de ferramentas ROADtools Hybrid de código aberto:

# Example: modify a hybrid user to impersonate the MSOL account
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
--sourceanchor <ImmutableID_of_User>\
--sid <TargetAD_SID> --sam <TargetAD_SAMName>

O sourceAnchor (ID imutável) do usuário é necessário para identificar o objeto do Azure AD a ser modificado. A ferramenta define o SID on-prem e o nome da conta SAM do usuário híbrido para os valores do alvo (por exemplo, o SID e SAM da conta MSOL_xxxx). O Azure AD normalmente não permite alterar esses atributos via Graph (eles são somente leitura), mas a API do serviço de sincronização permite isso e os Administradores Globais podem invocar essa funcionalidade de sincronização.

3. Obter um TGT Parcial do Azure AD: Após a modificação, autentique-se como o usuário híbrido no Azure AD (por exemplo, obtendo um PRT em um dispositivo ou usando suas credenciais). Quando o usuário faz login (especialmente em um dispositivo Windows associado ao domínio ou ao Entra), o Azure AD emitirá um TGT Kerberos parcial (TGT_AD) para essa conta porque o Cloud Kerberos Trust está habilitado. Este TGT parcial é criptografado com a chave AzureADKerberos$ RODC e inclui o SID alvo que definimos. Podemos simular isso solicitando um PRT para o usuário via ROADtools:

roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>

Isso gera um arquivo .prt contendo o TGT parcial e a chave de sessão. Se a conta era apenas de nuvem, o Azure AD ainda inclui um TGT_AD na resposta do PRT.

4. Trocar TGT Parcial por TGT Completo (no AD): O TGT parcial pode agora ser apresentado ao Controlador de Domínio local para obter um TGT completo para a conta alvo. Fazemos isso realizando uma solicitação TGS para o serviço krbtgt (o serviço TGT principal do domínio) -- essencialmente atualizando o ticket para um TGT normal com um PAC completo. Ferramentas estão disponíveis para automatizar essa troca. Por exemplo, usando o script do ROADtools Hybrid:

# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash

Este script (ou equivalentes do Impacket) irá contatar o Controlador de Domínio e recuperar um TGT válido para a conta AD alvo, incluindo o hash NTLM da conta se a extensão Kerberos especial for utilizada. A extensão KERB-KEY-LIST-REQ é automaticamente incluída para pedir ao DC que retorne o hash NTLM da conta alvo na resposta criptografada. O resultado é um cache de credenciais (full_tgt.ccache) para a conta alvo ou o hash da senha NTLM recuperado.

5. Impersonar o Alvo e Elevar para Administrador de Domínio: Agora o atacante efetivamente controla a conta AD alvo. Por exemplo, se o alvo era a conta MSOL do AD Connect, ela tem direitos de replicação no diretório. O atacante pode realizar um ataque DCSync usando as credenciais dessa conta ou o TGT Kerberos para despejar hashes de senhas do AD (incluindo a conta KRBTGT do domínio). Por exemplo:

# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL

Isso despeja todos os hashes de senha de usuários do AD, dando ao atacante o hash do KRBTGT (permitindo que ele forje tickets Kerberos de domínio à vontade) e efetivamente privilégios de Domain Admin sobre o AD. Se a conta alvo fosse outro usuário privilegiado, o atacante poderia usar o TGT completo para acessar qualquer recurso de domínio como esse usuário.

6. Limpeza: Opcionalmente, o atacante pode restaurar o onPremisesSAMAccountName e o SID originais do usuário do Azure AD modificado via a mesma API ou simplesmente excluir qualquer usuário temporário criado. Em muitos casos, o próximo ciclo de sincronização do Azure AD Connect reverterá automaticamente alterações não autorizadas em atributos sincronizados. (No entanto, a essa altura, o dano já está feito -- o atacante possui privilégios de DA.)

Referências

• Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust