Az - Cloud Kerberos Trust
Esta postagem é um resumo de https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ que pode ser verificado para mais informações sobre o ataque. Essa 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 do RODC, chamada AzureADKerberos$. Além disso, uma conta krbtgt secundária chamada krbtgt_AzureAD. Esta conta contém as chaves Kerberos usadas para os tickets que o Azure AD cria.
Portanto, se essa conta for comprometida, poderia ser possível se passar por qualquer usuário... embora isso não seja verdade porque essa conta é impedida de criar tickets para qualquer grupo AD privilegiado comum como Administradores de Domínio, Administradores de Empresa, 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.
TGT Kerberos
Além disso, quando um usuário se autentica no Windows usando uma identidade híbrida do Azure AD, 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 krbtgt secundária incluindo o campo KERB-KEY-LIST-REQ na parte PADATA da solicitação e então obter um TGT completo assinado com a chave krbtgt primária incluindo o hash NT na resposta.
Abusando da Confiança Kerberos na Nuvem para obter Administrador de Domínio
Quando o AzureAD gera um TGT parcial, ele estará usando os detalhes que possui sobre o usuário. Portanto, se um Administrador Global pudesse 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 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 SID de qualquer usuário híbrido, e então se autenticarmos, obtemos um TGT parcial contendo o SID modificado.
Observe que podemos fazer isso com o 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 Administrador de Domínio dependem do cumprimento de certos pré-requisitos:
A capacidade de alterar contas via a 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 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 localmente, exigindo a modificação de uma conta não sincronizada para obter o ticket.
Além disso, esta conta deve possuir privilégios equivalentes aos de um administrador de domínio, mas não deve ser membro de grupos administrativos AD típicos 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 ela possui inerentemente privilégios equivalentes aos de um Administrador de Domínio devido ao seu papel na sincronização de hashes de senha (assumindo que a Sincronização de Hash de Senha está 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
Verifique no post original: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Última actualización