How to Protect Microsoft Hybrid Environment Against Identity Attacks

On Day 25 of Cybersecurity Awareness Month, learn how to safeguard your Microsoft hybrid environment from identity attacks. Don’t miss what’s next in our ongoing Cybersecurity blog series.

Modern identity attacks against Microsoft environments have evolved beyond simple password theft. Attackers now focus on exploiting the trust relationships between on-premises and cloud systems. In hybrid environments, even a minor misconfiguration in synchronization can become the gateway to compromise.

These identity-based attacks exploit the ways users and systems authenticate across different platforms. A single compromised account or overlooked configuration can allow attackers to move laterally, escalate privileges, and reach critical cloud resources.

Traditional defenses such as strong passwords and MFA still play a vital role, but they are no longer enough on their own. Protecting a hybrid environment requires a clear understanding of how modern threat actors target hybrid infrastructure. In this blog, we will explore Microsoft hybrid identity attacks and discuss strategies to prevent them.

The battle for your network is fought at the identity layer, specifically where your on-premises Active Directory (AD) meets Microsoft Entra ID (formerly Azure AD). Attackers focus on exploiting the shared secrets, tokens, and trust boundaries that govern your hybrid identity landscape. Each of these moving parts expands the attack surface, giving adversaries multiple points to exploit vulnerabilities.

Attackers look for weak spots such as exposed AD FS endpoints or misconfigured sync accounts. Once found, they can impersonate users, steal tokens, or issue unauthorized authentication requests to the cloud.

Persistence remains a key reason attackers target Microsoft hybrid identity since compromising an on-premises domain can grant long-term access. Even if cloud credentials are reset, attackers can use that foothold to continuously reestablish access to Microsoft 365. In short, the flexibility that hybrid identity offers to organizations also provides flexibility to attackers.

Here is the list of identity attacks performed on Microsoft hybrid environment and their prevention strategies to strengthen your security posture.

• Entra Connect Compromise
• SyncJacking Attack
• Seamless SSO Hijacking
• Kerberos Ticket Forgery
• SAML Token Forgery
• Primary Refresh Token (PRT) Attack
• OAuth Token Replay Attacks
• Malicious App or Service Principal Registration
• Remote Code Execution Attack

This is the digital equivalent of stealing the master key to your entire kingdom, both on-premises and in the cloud. Here, attackers prioritize gaining local administrative access to the Entra Connect server. Once there, they compromise the highly privileged Sync Account by dumping its hash or clear-text password from the server’s memory (LSASS) or the local SQL database. The Sync Account is the most powerful bridge of identity, holding permissions to modify identities on both sides. This control allows the attacker to reset any synced user’s password, perform a massive account takeover, or steal all hashes from the on-premises AD via DCSync.

Strategies to Prevent Entra Connect Compromise

• Treat the Connect server as a Tier 0 asset and keep the server fully patched and up to date.
• Use Windows Defender Credential Guard to isolate the LSASS process and protect the credentials in memory.
• Configure the synchronization service to use a Group Managed Service Account (gMSA), which manages and rotates its own complex password, preventing hash/password exposure.
• Use Microsoft Defender for Identity (MDI) to monitor suspicious activities like credential dumping and anomalous DCSync attempts.

This attack is about swapping the ID on a low-privilege user to claim ownership of a high-privilege cloud administrator. Microsoft Entra Connect links on-premises Active Directory accounts with cloud identities. The attacker exploits synchronization and matching logic in Entra Connect by manipulating an attribute. Entra Connect uses soft matching, based on attributes like SMTP address or UPN, and hard matching, based on the ImmutableID (on-prem AD user’s objectGUID).

In soft matching attacks, an attacker modifies a low-privilege on-premises account to match a high-privilege cloud account. During the next sync, Entra Connect links the accounts, granting the attacker control without triggering alerts. Hard matching attacks work similarly but are more direct: if the attacker sets the ImmutableID of a low-privilege account to match a cloud admin, the sync immediately transfers ownership.

Defend Against SyncJacking Attacks

• Disable hard matching and soft matching in Entra ID to prevent privileged accounts from being linked based on easily mutable attributes.
• Use Entra Connect Health to monitor and alert synchronization errors or unusual changes in matching behavior.
• Audit and restrict who can change the critical attributes used for synchronization (like ProxyAddresses or the immutable ID) in on-premises AD.

Seamless SSO enhances the user experience by using a dedicated on-premises AD account called AZUREADSSOACC to share a decryption key with Entra ID. During setup, a computer account named AZUREADSSOACC is created in each on-premises AD forest synchronized with Microsoft Entra ID. Attackers abuse this account to pivot from On-Premises Active Directory to Entra ID.

If an attacker manages to steal the NTLM hash of this high-value account from the domain database, they gain access to the shared trust key between AD and Entra ID. With this hash, the attacker can forge a Silver Ticket (a customized Kerberos ticket) and send it to the Seamless SSO endpoint/service that Entra trusts. This flow tricks Entra into issuing a valid Primary Refresh Token (PRT) or accepting the user’s SSO assertion for any synchronized account.

Steps to Prevent Seamless SSO Hijacking

• Isolate the AZUREADSSOACC account in a protected organizational unit (OU), disable interactive logons, and limit its permissions to the absolute minimum.
• This account should be treated as a high-privileged account and like the KRBTGT account, the password should be rotated every 30 days.
• If your organization doesn’t need it, disable Seamless SSO to remove the shared secret hash.
• Enforcing phishing-resistant MFA methods such as WHfB, FIDO2 security keys to limit the utility of the resulting PRT, as it may be blocked by CA policies.

Microsoft Hybrid environments are increasingly targeted by identity-based attacks such as domain credential theft and Kerberos ticket forgery. These attacks enable adversaries to gain persistent access to your on-premises Active Directory (AD) and pivot to cloud resources. Attackers often use high-impact, on-premises techniques like extracting NT LAN Manager (NTLM) hashes from memory or the NTDS.DIT database.

The most notorious method used to do this is DCSync, where a compromised privileged account is used to mimic a domain controller and requests user password hashes from another DC. With these stolen hashes, attackers can create Golden Tickets (forging a Kerberos Ticket-Granting-Ticket) or Silver Tickets (forging a service ticket). These forged tickets grant the attackers full impersonation rights to any account. This allows them to maintain long-term access to the on-premises domain and pivot into cloud services.

Mitigation Measures for Kerberos Ticket Forgery

• Reset the KRBTGT account password regularly to invalidate existing Kerberos tickets that were encrypted with the old password hash. So, any stolen (forged) tickets become unusable.
• Deploy Windows Local Administrator Password Solution (LAPS) to secure local administrator passwords on all endpoints, mitigating lateral movement.
• Implement Privileged Access Management with Active Directory PAM or Entra ID PIM for admin roles to eliminate standing access.

If you are using Active Directory Federation Services (AD FS), the service relies on a private token-signing key to cryptographically sign SAML assertions. An attacker targets the AD FS server to export or steal the private key of the Token Signing Certificate. Any SAML assertion signed with that key will be accepted by relying parties that trust the AD FS federation, potentially including Microsoft Entra ID and connected cloud services. The attacker can then forge a token claiming they are a Global Administrator and sign in as that user, completely bypassing all standard authentication and MFA controls.

For example, the attacker exports the AD FS token‑signing key, crafts a SAML assertion that names user alice@contoso.com as a Global Administrator. They then sign the assertion with the stolen key and post it to the application’s SAML ACS endpoint. The application validates the signature and opens a session as alice@contoso.com without a password or MFA prompt.

How to Protect Against SAML Token Forgery

• Monitor AD FS server logs for suspicious certificate export attempts and excessive token issuance rates.
• Migrate from AD FS to Password Hash Synchronization (PHS) with Seamless SSO where feasible, eliminating this highly critical single point of failure.
• For containing the impact of a previously forged SAML token, rotate the token-signing AD FS certificate twice in rapid succession, which will invalidate any tokens generated using the previous certificate.
• Restrict permissions and access to the AD FS server environment to only originate from Privileged Access Workstations (PAWs).
• Securely store private keys in Hardware Security Modules (HSMs) on Windows Server to prevent their easy export.

This is the cloud version of session hijacking; it means stealing the user’s permanent login ticket. The Primary Refresh Token (PRT) is the core session token for Single Sign-On (SSO) across Microsoft cloud services. An attacker who gains local administrative access to an Entra-joined device can steal the user’s PRT and its cryptographic session key. They typically retrieve this data from the LSASS memory or the CloudAP cache.

The critical issue is persistence and MFA bypass. The attacker can use the stolen PRT to repeatedly request new access tokens. They don’t have to go through the authentication process again. Replaying the PRT inherits the user’s prior successful authentication, including any completed MFA state, effectively bypassing the need for a new MFA challenge.

Although it’s a cloud session attack, the initial device compromise serves as a pivot point back to the on-premises AD. From that compromised device, the attacker can harvest cached AD credentials or move laterally to domain controllers. They can also execute DCSync or abuse administrative privileges to manipulate hybrid synchronization settings, quickly leading to a full enterprise compromise.

Defenses Against Primary Refresh Token Attacks

• Implement Continuous Access Evaluation (CAE) to instantly revoke access tokens issued from stolen PRTs.
• Enforce device based Conditional Access policies that strictly requires a compliant or Hybrid Joined device, blocking the replayed PRT when used from an unauthorized location.
• Use Microsoft Defender for Endpoint (MDE) to detect LSASS credential dumping and memory-scraping behaviors targeting the CloudAP cache.
• Implement Windows Hello for Business to bind the PRT session key to the device TPM, preventing token reuse on unauthorized devices.

Developers and admins leave valuable keys lying around on their computers in the form of local cache files. After compromising a hybrid joined endpoint, an attacker skips password cracking and goes straight for the OAuth tokens stored by applications like the Azure CLI, Azure PowerShell, web browsers, or the Web Account Manager (TokenBroker).

These tokens are captured in various ways, such as man-in-the-middle attacks, insecure local storage, or unencrypted transmission. They are typically stored in specific user profile folders or local databases.

Since the authorization server has already authenticated these tokens, reusing them often grants the attacker immediate access without re-verification. These stolen tokens are direct keys to cloud services. They grant the attacker immediate, non-interactive API access to services like Key Vaults, Storage Accounts, or Exchange Online, bypassing the need for a password or MFA.

Ways to Prevent OAuth Token Replay Attacks

• Use Conditional Access (CA) Session Controls to enforce shorter refresh token lifetimes for high-risk applications, ensuring stolen tokens expire faster.
• Use Defender for Endpoint and Defender for Cloud Apps to detect suspicious OAuth token reuse or API activity from unmanaged devices.
• Configure Continuous Access Evaluation (CAE) to revoke tokens instantly when risk is detected.

This method involves either phishing users to grant consent for a new, malicious application of registration, or hijacking an existing service principal (the non-user identity for an application) and escalating its permissions. Service principals are often overlooked in identity review processes. They can hold broad permissions like Directory.ReadWrite.All and can be used for long-term data exfiltration or persistence without being tied to a human user account.

An attacker who has stolen credentials for an on-premises administrator with hybrid privileges can use that access to establish a persistent, backdoor presence in the cloud via a malicious application. Furthermore, a service principal with elevated permissions (like the ability to write back to Active Directory) can be used to maliciously alter on-premises user attributes, completing the attack chain back to the local domain.

Secure Against App or Service Principal Abuse

• Enforce the admin consent workflow in Entra ID, requiring administrator review and approval before any application can be granted high-risk permissions.
• Use Microsoft Defender for Cloud Apps to monitor and alert on unusual application registration activity and bulk consent grants.
• Review Enterprise applications and their permissions to detect apps with unnecessary API permissions that are consented to tenant wide.

After compromising an administrative account, the attacker abuses Microsoft management platforms like Intune Remote Actions, Microsoft Defender for Endpoint (MDE) Live Response, or Azure VM Run Command. These channels let the attacker execute scripts, install agents, or run code across thousands of managed devices and VMs simultaneously. This allows for massive, legitimate-looking lateral movement and post-exploitation actions that are often difficult to detect by endpoint security tools.

Hardening Systems to Stop Remote Code Execution

• Enforce Privileged Identity Management (PIM) for all administrators (Intune Admin, Security Admin) who can push scripts. This eliminates standing access and require approval for every high-risk action.
• Require access to management portals (Azure/Intune) only from secured Privileged Access Workstations (PAWs) using Conditional Access.
• Use MDE’s advanced hunting capabilities to monitor and alert on high-risk command execution (e.g., encoded PowerShell commands) originating from management consoles.

Overall, understanding and mitigating Microsoft hybrid identity attacks is a crucial step in securing both your on-premises and cloud environments. The attacks and mitigation strategies outlined above provide practical guidance on how you can protect Active Directory and Entra ID from sophisticated attackers. We’re nearing the end of Cybersecurity Awareness Month, but the need for vigilance never stops. Stay tuned for more insights and next steps in securing your cloud journey, and feel free to share your comments or questions below.