Hardening Microsoft Entra ID Against Session Hijacking for Beyond Identity Tenants

📝 Note

This guide accompanies the gobeyondidentity/bi-entra-policies repository. The repo ships 11 ready-to-deploy Conditional Access policies and cross-platform deployment scripts.

Overview

Session hijacking is one of the most common post-authentication attacks against cloud identity. An attacker who obtains a valid session token — whether by phishing, an adversary-in-the-middle (AiTM) proxy, or cookie-stealing malware — can bypass MFA and act as the user until the token expires.

This framework deploys 11 Conditional Access policies in Microsoft Entra ID covering the full session hijacking kill chain: credential theft, token acquisition, token replay, and persistent unauthorized access. Every policy ships in report-only mode so impact can be measured before enforcement.

Why It Matters

Session hijacking has moved past simple password theft:

• AiTM phishing kits like EvilProxy and Evilginx proxy the real Microsoft login page in real time, capturing both credentials and the session cookie after MFA completes. MFA on its own doesn't stop this.
• Token-theft malware (Raccoon, RedLine, and similar infostealers) pulls browser cookies and refresh tokens straight off disk with no user interaction.
• Legacy protocols (IMAP, POP3, SMTP basic auth, Exchange ActiveSync) predate MFA and bypass federation entirely.
• Stale sessions on shared or unattended devices hand any local attacker a fully authenticated session with no challenge.

No single control closes all of these, which is why this framework layers eleven of them.

Benefits

• Coverage of the full kill chain. Credential theft, token acquisition, token replay, and persistent access are each addressed by at least one policy.
• Tuned for passwordless tenants. Risk handling, session control, and admin protection assume a Beyond Identity federation rather than the generic Microsoft baseline.
• Safe rollout by default. Every policy ships in report-only mode and the deployment scripts refuse to run without an explicit break-glass exclusion.
• Cross-platform deployment. Bash, PowerShell, or manual JSON upload, with dry-run, filter, ignore, and rollback flags.
• License-aware. Each policy is tagged with the Entra ID and Intune SKUs it requires so the framework adapts to whatever the tenant already has.

Threat Model

The framework assumes tenants federated to Beyond Identity for passwordless authentication. The federation protocol (WS-Fed, OIDC, or otherwise) is upstream of every Conditional Access decision, so the policies don't care which path delivered the assertion. What matters is that no password sits in the end-user auth flow. That changes a few specific choices:

• Medium user and sign-in risk are not enforced. Most medium-tier signals (low-confidence leaked-credential matches, accumulating sign-in anomalies) are noise when the user has no password in the auth path. They remain visible in Identity Protection's Risky Users and Risky Sign-ins reports for monitoring and correlation with Beyond Identity's own signals.
• High user risk is a block, not a password reset. A forced password change can't rotate a credential that doesn't exist in the federated flow. Block sends remediation back to the IdP, where the actual credentials live.
• High sign-in risk is also a block. Same reasoning at the per-event level.

📝 Note

Tenants that aren't fully federated to a passwordless IdP should reintroduce step-up MFA on medium risk and an SSPR-backed password change on high user risk. The Microsoft baseline pattern handles those cases correctly. It just doesn't fit a passwordless threat model.

Attack lifecycle coverage

 Credential Theft ───> Token Acquisition ───> Token Replay ───> Persistent Access
       │                      │                     │                    │
       ├ 01 MFA               ├ 03 Device Compl.    ├ 04 Token Binding   ├ 05 Session Frequency
       ├ 02 Block Legacy      ├ 04 Token Binding    ├ 03 Device Compl.   ├ 06 No Persist Browser
       ├ 07 Risk Block        ├ 09 Phish-Resist MFA │                    ├ 08 User Risk Block
       ├ 08 User Risk Block   ├ 11 BYOD App Prot.   │                    │
       └ 10 Azure Mgmt MFA    │                     │                    │

The 11 Policies

Defense-in-Depth Layers

The 11 policies form five complementary layers. Drop any one and a specific gap opens.

Prerequisites and Licensing

• Entra ID P1: Policies 01, 02, 03, 05, 06, 09, 10, 11
• Entra ID P2: Policies 04, 07, 08 (token protection plus Identity Protection risk)
• Microsoft Intune: Policies 03 and 11 (device compliance and app protection)

Policy 09 references the built-in Phishing-resistant MFA authentication strength (ID 00000000-0000-0000-0000-000000000004), which ships with P1; only custom strengths require P2.

Deployment

⚠️ Warning

Every Entra tenant is different. Existing Conditional Access rules, named locations, custom authentication strengths, and federation configurations vary org to org. Always start in report-only (monitor) mode and review sign-in logs before enforcing anything. Follow the rollout phases below in order; don't skip the monitor phase, even on small tenants.

Three deployment paths

Entra portal manual upload. Go to Protection > Conditional Access > Policies > Upload. In each JSON file, replace {{EXCLUDE_GROUP}} inside the excludeGroups array with the Object ID of your break-glass group. For multiple exclude groups, add additional Object IDs to the same excludeGroups array. Upload one policy at a time. Rollback on this path is manual: filter the policy list on the [BYID] tag in the portal and delete each match.

• macOS or Linux. Run deploy.sh with the Azure CLI installed (brew install azure-cli).
• Windows. Run deploy.ps1 with the Microsoft.Graph.Authentication PowerShell module (Install-Module Microsoft.Graph.Authentication -Scope CurrentUser).

Common deploy commands

# Deploy all policies, excluding two break-glass groups
./deploy.sh --exclude-groups "group-id-1,group-id-2"

# Dry-run to preview, no changes
./deploy.sh --exclude-groups "group-id-1" --dry-run

# Deploy a subset only
./deploy.sh --exclude-groups "group-id-1" --filter "01-*,02-*"

# Skip policies that don't apply (e.g. tenants without Intune)
./deploy.sh --exclude-groups "group-id-1" --ignore "03-*,11-*"

# Rollback: removes all policies tagged [BYID]
./deploy.sh --rollback

# Deploy all policies, excluding two break-glass groups
.\deploy.ps1 -ExcludeGroups "group-id-1","group-id-2"

# Dry-run to preview, no changes
.\deploy.ps1 -ExcludeGroups "group-id-1" -DryRun

# Deploy a subset only
.\deploy.ps1 -ExcludeGroups "group-id-1" -Filter "01-*","02-*"

# Skip policies that don't apply (e.g. tenants without Intune)
.\deploy.ps1 -ExcludeGroups "group-id-1" -Ignore "03-*","11-*"

# Rollback: removes all policies tagged [BYID]
.\deploy.ps1 -Rollback

🚫 Caution

Deploying any Conditional Access policy without a break-glass exclusion risks locking all users (including administrators) out of the tenant. Microsoft recommends at least two emergency-access accounts excluded from every CA policy. The deployment scripts refuse to run without one.

Recommended Rollout Phases

Per-Tenant Considerations

The framework is opinionated, but no single configuration fits every Entra tenant. Things to evaluate before enforcing:

• Existing Conditional Access estate. Overlapping legacy policies can cause unexpected double-evaluation. Audit current policies before adding these.
• License coverage. Skip P2-only policies (04, 07, 08) on P1-only tenants and Intune policies (03, 11) where Intune is not deployed. Use --ignore to omit them cleanly.
• Legacy applications. Older multifunction printers, scan-to-email setups, and line-of-business apps often still use IMAP/SMTP basic auth. Identify them during the monitor phase before enforcing policy 02.
• BYOD posture. Policy 11 only fits if you have an Intune App Protection rollout. Without one, exclude it.
• Privileged role membership. Policy 09 will block any admin without a registered phishing-resistant credential. Validate registration before enforcement.
• Break-glass coverage. Confirm at least two emergency-access accounts are in the exclude group before the first deployment, not after.

Summary Checklist

• ☐ Two or more break-glass accounts in the exclude group
• ☐ All policies deployed in report-only mode first
• ☐ Sign-in logs reviewed for "Report-only: Failure" before enforcing
• ☐ P2-only and Intune-only policies skipped on tenants without those licenses
• ☐ Privileged users have a registered FIDO2 / Windows Hello / CBA credential before enabling policy 09
• ☐ Legacy auth-dependent apps inventoried before enabling policy 02
• ☐ Existing Conditional Access policies reviewed for conflicts

Where to Find Things

• Repository: gobeyondidentity/bi-entra-policies (private)
• Policies: policies/ as JSON files numbered 01- through 11-
• Design rationale and full threat model: DESIGN.md
• Deployment scripts: deploy.sh (macOS/Linux), deploy.ps1 (Windows)

Rollback: --rollback (bash) or -Rollback (PowerShell) removes every policy whose displayName contains the [BYID] tag. For manual deployments, filter on [BYID] in the portal and delete the matches.

Feedback

Found an inconsistency between this guide and what an Entra tenant actually does, an edge case the framework misses, or a deployment that fails for a reason not listed here? File a GitHub issue on gobeyondidentity/bi-entra-policies. Real-tenant feedback is what drives the policies forward; small reports are welcome.

Conclusion

Session hijacking can't be solved with a single policy. The framework above pairs token binding, device compliance, identity-protection risk evaluation, session controls, and privileged-role hardening so each layer covers what the others miss, tuned for tenants where Beyond Identity is the source of truth for credentials. Start in monitor mode, work through the phases, and adapt the license-gated and Intune-gated policies to what your tenant supports.