In many of the hybrid environments I review, nobody pays much attention to the Entra Connect server. It usually gets minimal hardening, sits in the production network and is sometimes even reachable from the internet. Privileged users log on to it as a matter of routine. Microsoft’s analysis of Storm-0501 (https://www.microsoft.com/en-us/security/blog/2024/09/26/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/) shows what that can cost. Once the attackers were inside the on-premises infrastructure, they pulled the Directory Synchronization Account credentials straight off the Entra Connect Sync server and eventually used them to take over the cloud tenant.

The Entra Connect server belongs in Tier 0

Technically, the Entra Connect server sits on the most sensitive boundary of a hybrid setup, the directory bridge between Active Directory and Entra ID. Whoever compromises this machine can often get at more than password hashes and service accounts. They also get the sync account itself, and that account may hold broad Entra roles. With Storm-0501, this was the way in to taking down the whole tenant. I still come across organizations where the sync account has privileged roles assigned, or where Connect runs in poorly segmented networks. People underestimate this risk again and again.

Synced admins without strong MFA hand attackers the tenant

A classic mistake is using AD-synced accounts as cloud admins, frequently without enforced MFA. Storm-0501 exploited exactly that. After stealing the sync account, the attackers needed only one more synced admin account without strong MFA to seize the tenant. The most important thing you can do is make sure no synced accounts are used for privileged Entra roles. Use cloud-only admin accounts and require phishing-resistant MFA (such as FIDO2 or Passkeys) for every one of them. A compromise at this point practically invites attackers in.

Tip: For all privileged Entra roles (Global Admin, Privileged Role Admin, Exchange Admin etc.), set up cloud-only accounts and enforce FIDO2 or Passkey sign-in through a dedicated authentication methods policy.

Moving to the new authentication methods policy in Entra ID (I describe the migration here) gives you far more flexibility and security than sticking with the legacy MFA settings.

You should harden and monitor the Connect server like a domain controller

Treat the Entra Connect server the same way you treat a domain controller. That means strict segmentation (no internet access, only the ports it actually needs), no unnecessary logons and tightly controlled admin rights. The sync account credentials live on this server and can be extracted in plaintext once it’s compromised, so watching the synchronization account’s sign-ins is essential. In the Entra ID portal → Audit logs → Sign-ins, you can filter for the sync account specifically. Any sign-in from an unexpected location or at an odd time should be investigated right away.

Here’s a sample KQL query (Microsoft Defender for Cloud Apps, licence: Defender for Cloud Apps P1/P2, role: Security Reader):

IdentityInfo
| where AccountName contains "Sync_" or AccountName contains "MSOL_"
| join kind=inner (SigninLogs | where ResultType == 0) on $left.AccountObjectId == $right.UserId
| project TimeGenerated, AccountName, Location, IPAddress, AppDisplayName

It keeps unusual sync account activity in view, which matters most for attacks that begin on-premises and then move into the cloud.

Cloud Sync offers an alternative and regular updates add resilience

If running a classic Connect server seems too risky or too much effort, take a serious look at Entra Cloud Sync. Its lightweight agent is designed to get by with minimal permissions, and because it doesn’t store sensitive credentials, it doesn’t need the same Tier 0 treatment. For many smaller and even mid-sized environments, Cloud Sync is now the better choice. I compare the two in Entra Connect Sync or Cloud Sync.

Hardening and account separation are only part of it. You also have to keep Entra Connect fully up to date, without exceptions. Outdated versions are a major source of vulnerabilities, and that applies to authentication mechanisms as well as plain software flaws. Password hash sync has a benefit people often miss. If the on-premises infrastructure goes down, cloud sign-ins still work, which gives you extra resilience. Microsoft’s official prerequisites and guidance are a good read: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-prerequisites.

The simplified flowchart below shows the Storm-0501 attack path and the weak links that made it possible:

flowchart TD
    A["Attacker compromises AD"] --> B["Access to Entra Connect server"]
    B --> C["Extract sync account credentials"]
    C --> D["Sync account has Entra admin role"]
    D --> E["Cloud admin account without MFA"]
    E --> F["Tenant takeover"]

Figure: The Storm-0501 attack path from the Entra Connect server to tenant takeover.

I see no room for compromise with hybrid identity

Storm-0501 is not a one-off. I still find the same weaknesses in real tenants today. If you run hybrid identity, treat the Entra Connect server as Tier 0, just as you would a domain controller. Allow only cloud-only admin accounts in privileged roles, enforce strong MFA and keep the software current. Lower risk often comes from moving to Cloud Sync and cutting on-premises dependencies where you can. Attackers keep getting better, and our defenses have to keep pace. If you take these steps now, your hybrid identity setup will be in a much better position when the next Storm-0501 comes along.