Az - Cloud Kerberos Trust
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.
Informações Básicas
Confiança
Quando uma confiança é estabelecida com o Azure AD, um Controlador de Domínio Somente Leitura (RODC) é criado no AD. A conta de computador RODC, chamada AzureADKerberos$. Além disso, uma conta secundária krbtgt chamada krbtgt_AzureAD. Esta conta contém as chaves Kerberos usadas para os tickets que o Azure AD cria.
Portanto, se esta conta for comprometida, pode ser possível se passar por qualquer usuário... embora isso não seja verdade porque esta conta é impedida de criar tickets para qualquer grupo privilegiado comum do AD, como Administradores de Domínio, Administradores Empresariais, Administradores...
No entanto, em um cenário real, haverá usuários privilegiados que não estão nesses grupos. Portanto, a nova conta krbtgt, se comprometida, poderia ser usada para se passar por eles.
Kerberos TGT
Além disso, quando um usuário se autentica no Windows usando uma identidade híbrida, **o Azure AD emitirá um ticket Kerberos parcial junto com o PRT. O TGT é parcial porque o AzureAD tem informações limitadas do usuário no AD local (como o identificador de segurança (SID) e o nome).
O Windows pode então trocar este TGT parcial por um TGT completo solicitando um ticket de serviço para o serviço krbtgt.
NTLM
Como pode haver serviços que não suportam autenticação kerberos, mas NTLM, é possível solicitar um TGT parcial assinado usando uma chave secundária krbtgt incluindo o campo KERB-KEY-LIST-REQ na parte PADATA da solicitação e, em seguida, obter um TGT completo assinado com a chave primária krbtgt incluindo o hash NT na resposta.
Abusando da Confiança do Cloud Kerberos para obter Admin de Domínio
Quando o AzureAD gera um TGT parcial, ele usará os detalhes que possui sobre o usuário. Portanto, se um Administrador Global puder modificar dados como o identificador de segurança e nome do usuário no AzureAD, ao solicitar um TGT para esse usuário, o identificador de segurança seria um diferente.
Não é possível fazer isso através do Microsoft Graph ou do Azure AD Graph, mas é possível usar a API que o Active Directory Connect usa para criar e atualizar usuários sincronizados, que pode ser usada pelos Administradores Globais para modificar o nome SAM e o SID de qualquer usuário híbrido, e então, se nos autenticarmos, obtemos um TGT parcial contendo o SID modificado.
Observe que podemos fazer isso com AADInternals e atualizar usuários sincronizados via o cmdlet Set-AADIntAzureADObject.
Pré-requisitos do ataque
O sucesso do ataque e a obtenção de privilégios de Admin de Domínio dependem do cumprimento de certos pré-requisitos:
A capacidade de alterar contas através da API de Sincronização é crucial. Isso pode ser alcançado tendo o papel de Administrador Global ou possuindo uma conta de sincronização do AD Connect. Alternativamente, o papel de Administrador de Identidade Híbrida seria suficiente, pois concede a capacidade de gerenciar o AD Connect e estabelecer novas contas de sincronização.
A presença de uma conta híbrida é essencial. Esta conta deve ser passível de modificação com os detalhes da conta da vítima e também deve ser acessível para autenticação.
A identificação de uma conta de vítima alvo dentro do Active Directory é uma necessidade. Embora o ataque possa ser executado em qualquer conta já sincronizada, o locatário do Azure AD não deve ter replicado identificadores de segurança locais, necessitando da modificação de uma conta não sincronizada para obter o ticket.
Além disso, esta conta deve possuir privilégios equivalentes a admin de domínio, mas não deve ser membro de grupos típicos de administradores do AD para evitar a geração de TGTs inválidos pelo RODC do AzureAD.
O alvo mais adequado é a conta do Active Directory utilizada pelo serviço de Sincronização do AD Connect. Esta conta não é sincronizada com o Azure AD, deixando seu SID como um alvo viável, e possui inherentemente privilégios equivalentes a Admin de Domínio devido ao seu papel na sincronização de hashes de senha (assumindo que a Sincronização de Hash de Senha esteja ativa). Para domínios com instalação expressa, esta conta é prefixada com MSOL_. Para outras instâncias, a conta pode ser identificada enumerando todas as contas dotadas de privilégios de Replicação de Diretório no objeto de domínio.
O ataque completo
Confira no post original: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated
