MVC nLPD — Microsoft 365 Business Premium

Bundle Minimum Viable de Conformité (MVC) nLPD pour PME suisses de 5 à 25 utilisateurs. Quatre guides de déploiement et d'exploitation sur Microsoft 365 Business Premium + Purview Suite.

View the Project on GitHub doit4everyone/mvc-nlpd-m365

🌐 English version · Version française

← Back to the MVC nLPD bundle

AiTM / Cookie Hijacking M365

Detection · Mitigation · Structural protection

Standalone technical guide · Microsoft 365 Business Premium · v1.1 · August 2026, corrected on November 2, 2026
Field-validated on a hybrid infrastructure (Entra Connect + on-prem AD + WS2025)

Publication context

This document was written following two major publications in August 2026: the ANY.RUN research on Mirage2FA and the Microsoft advisory on CVE-2026-69836. The two topics are separate: nothing indicates that Mirage2FA exploits this flaw.

Mirage2FA (LinX Coders group, ANY.RUN research of August 18, 2026): a PhaaS platform using an AiTM technique based on a WebSocket proxy against Microsoft 365, active from 2024 to 2026. According to ANY.RUN estimates: 9,426 addresses targeted, 4,532 potentially compromised (48%), and 4,561 session cookie theft events, the most common outcome.

CVE-2026-69836 (Microsoft advisory of August 20): remote code execution vulnerability (deserialization), CVSS 10.0, in Entra ID. It was fixed on Microsoft's infrastructure side, with no action required on the customer side. Microsoft initially reported active exploitation, then corrected its advisory on August 21, 2026 and confirmed that the vulnerability had not been exploited in the wild.

Audience: IT consultants / MSPs and in-house IT managers supporting SMEs on M365 Business Premium.

This document is standalone but complements the MVC Purview nLPD Guide (in French).

Table of contents

Part A: Plan B, immediately actionable

Part B: Plan A, structural protection

PART A · Plan B: immediately actionable
CAE · IoC detection · SIEM · Immediate response

1. Context: MFA is no longer enough

1.1 What is an AiTM attack?

A modern AiTM (Adversary-in-the-Middle) attack no longer tries to break MFA. It lets MFA work normally and intercepts what comes after: the authenticated session cookie.

The Mirage2FA mechanism illustrates this approach perfectly:

  1. Phishing: The user receives an email with a link, an attachment (.htm, .xhtml, .svg) or a QR code leading to a transparent WebSocket proxy, visually identical to login.microsoft.com.
  2. Transparent proxy: The proxy relays every request to Microsoft in real time. The user completes their MFA normally.
  3. Interception: The proxy captures the authenticated session cookie. The attacker now holds a valid cookie.
  4. Replay: The attacker imports the cookie into their browser and accesses M365 without credentials or MFA. A password reset is not enough: the cookie stays valid until it is explicitly revoked.

Mirage2FA: ANY.RUN research figures (August 18, 2026, campaign from 2024 to 2026)

9,426 addresses targeted · 4,532 Microsoft 365 accounts potentially compromised (48%)
4,561 session cookie theft events (2,541 unique victims): the most common outcome, about 48.9% of the 9,332 potential compromise events recorded
ANY.RUN estimates: potential impact, not individually confirmed compromises
Vector: WebSocket proxy, undetectable by the user
Insufficient countermeasure: password reset alone

1.2 CVE-2026-69836: when the vulnerability is in the infrastructure itself

On August 20, 2026, Microsoft published the CVE-2026-69836 advisory, a deserialization of untrusted data vulnerability in Entra ID (remote code execution, CVSS score 10.0). The fix was deployed on Microsoft’s infrastructure side: no patching action is required on the customer side. Microsoft initially reported active exploitation, then corrected its advisory on August 21, 2026 and confirmed that the vulnerability had not been exploited in the wild. Nothing indicates that Mirage2FA exploits it: its mechanism relies on a phishing proxy.

Even though Microsoft reports no exploitation, the prudent question is not “is it fixed?” but “did anything happen in my tenant before the fix?”

Retrospective audit recommended as a precaution: period before August 20, 2026

· New Global Admin / Privileged Role Admin role assignments
· Credentials added to existing service principals
· Changes to Conditional Access policies
· Unusual OAuth consents
· New MFA methods registered on privileged accounts
· Cloud accounts created outside the synchronization process

Limit: Entra ID audit and sign-in logs are kept for 30 days (P1 and P2). Beyond that, without routing them to Log Analytics or a storage account via Azure Monitor, they are no longer accessible. The Microsoft 365 audit log (Purview Audit Standard, including Exchange events) has its own retention: 180 days by default.
→ Permanent recommendation: route Entra ID logs to Log Analytics.

Full retrospective audit procedure: see section 4.4.

1.3 Why classic MFA is structurally not enough

MFA protects the authentication but not the session that results from it. Once the session cookie is issued, it is valid proof of identity in the eyes of Microsoft 365, regardless of the authentication method used to obtain it.

Measure Effectiveness against AiTM Remark
MFA (TOTP / SMS) Insufficient The proxy relays the MFA in real time
MFA (Authenticator push) Insufficient The user approves, the proxy intercepts
Password reset Insufficient The cookie stays valid after the reset
CAE (Continuous Access Evaluation) Partial Near real-time revocation (up to 15 minutes according to Microsoft) for compatible clients
Identity Protection (detailed detections: Entra ID P2) Partial Flags a replay from an unusual context (IP, country, anomalous token)
WHfB (key in the TPM) or FIDO2 passkey Structural The AiTM proxy cannot obtain a valid session, see Part B

2. CAE: Continuous Access Evaluation

2.1 Principle, token lifetime and nuances

CAE changes two aspects of the token lifecycle: their lifetime and their revocability.

Token type Lifetime Revocability AiTM scenario
Standard token (client not CAE-capable) 1 hour by default Revocation blocks new tokens, the access token already issued stays valid until it expires Up to ~1h of access after revocation
CAE token (client AND resource both CAE-capable) Up to 28 hours Revocable by critical event (revocation, account disabled, password change, high user risk) Longer window if undetected, near real-time revocation if detected (up to 15 minutes of propagation according to Microsoft)

The CAE paradox, from the attacker's side

A CAE token can last up to 28 hours instead of one hour. For an attacker who steals a CAE token via AiTM, the potential exploitation window is therefore much longer than with a standard token, if nobody detects the incident.

The CAE model only holds if detection and revocation are fast. Without a SIEM or active monitoring, CAE can be an advantage for the attacker. This is why detection (SIEM + Identity Protection) is critical.

M365 applications supporting CAE on the server side: Exchange Online, SharePoint Online, OneDrive, Microsoft Teams, MS Graph. On the client side, CAE requires a compatible client. This was validated in the lab with Microsoft Edge on SharePoint Online. Firefox and the Outlook web app (outlook.office.com) did not show a CAE token in our tests.

CAE: enabled by default, revocation validated live (August 23, 2026)

According to Microsoft, critical event evaluation does not depend on a Conditional Access policy and is available in any tenant. On our lab tenant, CAE was active with no configuration: the option visible in Conditional Access (Customize continuous access evaluation) is used to disable or tighten it. Some older tenants that configured CAE in the legacy interface must migrate that setting to Conditional Access.

Measured in the lab on a Business Premium tenant (Microsoft states a latency of up to 15 minutes):
· Active session revocation in ~1 minute (myaccount.microsoft.com)
· ~3 to 4 minutes on SharePoint Online via Edge (CAE token confirmed, Is CAE Token = Yes)

Revocation works on all token types (CAE and standard) via "Revoke sessions" in Entra ID.

Identity Protection: P1 vs P2 difference (source: Microsoft Learn)

Business Premium without add-on (P1):
· Only a few detections (anonymous IP address, leaked credentials, Microsoft Entra threat intelligence)
· Other detections appear under the generic "Additional risk detected" label, without details
· No risk-based Conditional Access (automatic revocation on detection)
· Manual revocation only, after detection via the SIEM or manual monitoring

Business Premium + Defender Suite add-on (P2):
· Detailed detections: Anomalous token, Unfamiliar sign-in properties, Malicious IP address, Token issuer anomaly
· Impossible travel: also requires Defender for Cloud Apps (or Microsoft 365 E5)
· Risk-based Conditional Access: automatic revocation when a risk is detected

In both cases: manual revocation works immediately via "Revoke sessions".

2.2 Checking that CAE is not disabled on the tenant

Via PowerShell:

Connect-MgGraph -Scopes "Policy.Read.All" -UseDeviceAuthentication

$result = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies"
$result.value | Where-Object {
  $_.sessionControls.continuousAccessEvaluation -ne $null
} | Select-Object displayName, @{N='CAE';E={$_.sessionControls.continuousAccessEvaluation.mode}}

Expected result: no line returned = no Conditional Access policy disables or customizes CAE. ✅

This script queries the Graph beta API, which may change. If in doubt, the portal check below is authoritative.

Via the portal:

entra.microsoft.com → Conditional Access → Policies: check that no policy contains Session → Customize continuous access evaluation → Disable.

What you see in the interface

In Conditional Access → New policy → Session, the "Customize continuous access evaluation" option offers only two sub-options: Disable and Strictly enforce location policies (preview). There is no "Enable" option: CAE is enabled by default without any action.

2.3 Revocation test

  1. Sign in with a test account on myaccount.microsoft.com in a private browsing window.
  2. entra.microsoft.com → Users → [test account] → Overview → Revoke sessions → Yes.
  3. Measure the delay before the session is invalidated.

Result validated live (August 23, 2026): session invalidated in ~1 minute. Confirmation toast (translated from the French UI): “Sign-in sessions revoked for [account]”.

For a native CAE test: use SharePoint Online via Edge. CAE token confirmed (Is CAE Token = Yes in the Entra ID sign-in logs). Revocation takes effect at the client’s next network call (page refresh).

3. Indicators of compromise (IoCs)

3.1 Signals in Identity Protection (details: Entra ID P2)

entra.microsoft.com → Identity Protection → Risk detections

The detections below require Entra ID P2. Without P2 (Business Premium alone), they appear under the generic “Additional risk detected” label, without details.

Signal Description Relevance
Impossible travel Sign-in from two incompatible geographies within a short time (also requires Defender for Cloud Apps) Partial: only if the attacker replays from a geographically inconsistent IP
Unfamiliar sign-in properties New IP, new user-agent, new country Good: the attacker’s infrastructure differs from the usual profile
Anomalous token Token with unusual characteristics (abnormal lifetime, replay from an unfamiliar location) Direct: the most specific signal for a replayed cookie
Malicious IP address Sign-in from a known malicious IP Depends on the freshness of the Microsoft TI feed

3.2 Post-compromise behavioral signals

These signals appear within the first 30 minutes after a successful session theft. Monitor them in security.microsoft.com → Incidents & alerts.

3.3 On-prem signals (hybrid environments)

3.4 SIEM correlation: what you see depending on your UTMStack configuration

Reference: Chapter 11 of the UTMStack lab (in French)

Block 1: Rules that work without extra configuration

UTMStack rule Signal covered Scenario
M2: OAuth Application Consent Granted Suspicious OAuth consent after compromise AiTM + Entra ID compromise (CVE-2026-69836 scenario)
M3: Impossible Travel Sign-in from a geographically impossible country AiTM
M5: MFA Required Interrupt MFA interrupt visible even if the proxy relayed the token AiTM
M6: Member Added to Group Addition to an Entra ID group Entra ID compromise (CVE-2026-69836 scenario)
M7: User Account Created Outside Sync Cloud account created outside Entra Connect Entra ID compromise (CVE-2026-69836 scenario)
M8: Unified Audit Log Disabled Attempt to blind the SIEM after compromise AiTM + Entra ID compromise (CVE-2026-69836 scenario)
M12: External Mailbox Access External access to an Exchange mailbox via OAuth AiTM
M14: Sign-In Blocked by CA Sign-in blocked by Conditional Access AiTM

Block 2: Two additional rules for the CVE-2026-69836 scenario

Rule Entra ID action detected Validation
M-new-1: Privileged Role Assigned Add member to role. → Global Admin, Security Admin, etc. ✅ Validated live: August 22, 2026 (latency ~7 min)
M-new-2: Credentials Added to Service Principal Add service principal credentials. → persistence without MFA ✅ Validated live: August 22, 2026 (latency ~4 min)

M-new-1 and M-new-2: fields available in the UTMStack alert

M-new-1: action = "Add member to role." · log.ObjectId = UPN of the assigned account · log.ModifiedProperties: Role.DisplayName · origin.user = actor · latency ~7 min

M-new-2: action = "Add service principal credentials." · log.Target = service principal name · origin.user = actor · latency ~4 min

Note: M-new-2 only triggers via a direct Graph API call (addPassword) or PowerShell. The Entra ID graphical interface generates a different label. Test: POST https://graph.microsoft.com/v1.0/servicePrincipals/{id}/addPassword via Graph Explorer.

Block 3: Visibility limits

Structural blind spots: independent of any tool or license

· CVE-2026-69836, initial phase: a flaw of this kind sits inside Microsoft's infrastructure. No event is generated in the customer logs, even though Microsoft now reports no exploitation. Only the subsequent actions inside the tenant are visible, which is what M-new-1 and M-new-2 cover.
· Log retention: Entra ID audit and sign-in logs are kept for 30 days (P1 and P2). Beyond that, without routing them to Log Analytics or a storage account via Azure Monitor, they are no longer accessible. The Microsoft 365 audit log (Purview Audit Standard, including Exchange events) has its own retention: 180 days by default.
→ Permanent recommendation: route Entra ID logs to Log Analytics.

UTMStack blind spot: technical limitation of the ETL v11 pipeline

SharePoint exfiltration: FileDownloaded events (RecordType 6) are not collected. Rule M13 is documented as not implementable (see Chapter 11).

Partial coverage is available through Microsoft Purview Insider Risk Management (policy IRM-Fuites-Données-PME). It requires the Purview Suite add-on, outside the scope of Business Premium alone.

Recommended best practices before enabling IRM (with regard to art. 26 OLT 3, the Swiss Ordinance 3 to the Labour Act, and art. 6 nFADP, the revised Swiss Federal Act on Data Protection, known as nLPD in French):
· Prior notification of employees in the staff regulations or the IT charter
· Anonymization enabled by default in Purview
· Written procedure for lifting anonymity (see Annex G of the full Purview guide)

Reference: Full Purview 2026 guide (in French), section 8.2

4. Immediate response: SIEM alert received

Critical point: when a replay alert comes in, the theft has usually already happened

Post-authentication signals (replay, OAuth consent, mailbox rule) usually mean the attacker already holds the session cookie. The goal becomes limiting the exploitation time. An earlier signal (a click on a known phishing link, for example) can however allow action before the theft.

· Without CAE: revocation blocks new tokens, but the access token already issued remains usable until it expires (one hour by default).
· With CAE: revocation applies in near real time to compatible clients, with a latency of up to 15 minutes according to Microsoft (1 to 4 minutes measured in the lab).

CAE must be enabled BEFORE the incident for the response to be effective. See section 2.

4.1 Sequence of signals to watch in the SIEM

Phase Typical delay SIEM signals (UTMStack rules) Interpretation
Phase 1: initial access T+0 to T+5 min M3 (Impossible Travel), M5 (MFA Interrupt) The cookie has just been stolen and replayed. Act immediately.
Phase 2: exploitation T+5 to T+30 min M2 (OAuth Consent), M12 (External Mailbox Access) The attacker establishes persistence and starts exfiltrating.
Phase 3: long-term persistence T+30 min to several hours M-new-1 (Role Assigned), M-new-2 (Credentials SPN), M7 (Account Created) The attacker prepares durable access, independent of the cookie.

Golden rule

If you see Phase 2 or Phase 3 without having seen Phase 1 in the SIEM, the initial attack took place outside your detection window. Revocation is required immediately and the damage of Phase 2 may already be done. Run the full audit of section 4.3.

4.2 Immediate token revocation: do this within 2 minutes

  1. Revoke all sessions: entra.microsoft.com → Users → [compromised account] → Overview → Revoke sessions → Yes. PowerShell equivalent, useful in scripts: Revoke-MgUserSignInSession -UserId [UPN]. It is the same operation: no need to do both.
  2. Check CAE propagation: If CAE is enabled, test a SharePoint / Teams action on the affected account. The session should be invalidated within a few minutes (up to 15 minutes according to Microsoft).

Without CAE: what to do until the access token expires (one hour by default)?

Immediately tell the affected user to stop doing anything in their session. Monitor in real time the actions in Exchange (mail forwarding), SharePoint (downloads), Teams (messages sent) and Entra ID (configuration changes). Document every observed action with a timestamp to build the incident file.

4.3 Damage audit: do this within 30 minutes

Microsoft 365 audit log (Exchange events)

purview.microsoft.com → Audit → filter on [incident date/time] → [compromised account]

Entra ID audit logs

entra.microsoft.com → Audit logs → filter on [incident date/time] → [compromised account]

Entra ID sign-in logs

entra.microsoft.com → Sign-in logs → filter on [compromised account] → incident period

Look for: unusual source IP, generic or malformed user-agent, inconsistent geolocation.

4.4 Retrospective audit after CVE-2026-69836

If the audit reveals suspicious actions in the window before August 20, 2026, apply the revocation sequence on the affected accounts, then specifically check:

Building the evidence file for FDPIC notification (art. 24 nFADP)

If the audit reveals an actual compromise, eDiscovery Premium lets you search all potentially exposed data in Exchange, SharePoint and Teams and build the evidence file for the notification to the FDPIC (Federal Data Protection and Information Commissioner, PFPDT in French).

Requires the Purview Suite add-on, outside the scope of Business Premium alone.
Reference: Full Purview 2026 guide (in French), section 8.3

4.5 Full remediation sequence

Common mistake: resetting the password first

The session cookie stays valid after a password reset. The sequence below must be run in the order given.

  1. Revoke all sessions (portal or PowerShell, see 4.2)
  2. Audit mail forwarding rules (Exchange Admin Center)
  3. Audit mailbox delegations (Full Access / Send As)
  4. Audit recently consented OAuth applications
  5. Audit registered MFA methods: remove any unrecognized device
  6. Reset the password: only after steps 1 to 5
  7. Force a full MFA re-registration
  8. Document the incident: timestamp, source IP, user-agent, detected actions
PART B · Plan A: structural protection
WHfB with TPM · Cloud Kerberos Trust · Legacy applications · AzureADKerberos rotation

Scope note

This part covers advanced hardening measures, beyond the MVC Business Premium scope. Audience: IT consultants supporting SMEs with Hybrid Entra Join or full-cloud workstations. Field validation was performed on a hybrid environment: Entra Connect + on-prem AD + WS2025.

5. Why WHfB / FIDO2 defeats the AiTM attack

5.1 The cryptographic mechanism

Windows Hello for Business uses an asymmetric key pair generated at enrollment:

At Windows sign-in, the Windows cloud authentication provider (Cloud AP) requests a nonce from Entra ID, signs it with the private key and returns it. Entra ID verifies the signature with the public key, then issues a Primary Refresh Token (PRT) bound to the device. Authentication is performed by Windows, not by typing anything into a web page.

FIDO2 passkeys (physical security key or passkey) rely on a different mechanism, WebAuthn: the passkey is bound to the domain it was registered for, and the browser only offers it to that domain.

Why the AiTM attack fails with WHfB / FIDO2

With WHfB, there is no password or code to type into a web page: the proxy has nothing to relay. With a FIDO2 passkey, the proxy's domain is not the one the passkey was registered for: the browser does not offer it. In both cases, the proxy obtains no valid session. Microsoft lists these methods in the "Phishing-resistant MFA" authentication strength (see 7.4).

This protection is only complete if Conditional Access requires a phishing-resistant method: as long as a weaker method remains allowed, the proxy can offer it to the user. Nor does it protect against the theft of a cookie already issued by other means (malware on the device, for example).

5.2 Comparison of deployment scenarios

Workstation type Account type Solution AzureADKerberos required? Difficulty
Full cloud (Entra ID only) Cloud-only or hybrid FIDO2 / WHfB direct No Low
Hybrid Entra Join Hybrid (AD-synced) WHfB + Cloud Kerberos Trust Yes Medium
Hybrid Entra Join Cloud-only Not compatible N/A Impossible: no Windows session possible
Pure AD (no Entra Join) On-prem AD only Out of WHfB scope Not applicable N/A

Critical point: cloud-only account on a hybrid workstation

A cloud-only account cannot open a Windows session on a Hybrid Entra Join workstation. Windows tries to authenticate via Kerberos against the on-prem AD first. The account does not exist in the AD, so the sign-in fails.

Validated in the lab (August 24, 2026): test-m7 (cloud-only) refused on a hybrid workstation. Solution: use a hybrid account (synced via Entra Connect) on hybrid workstations.

6. Prerequisites and preliminary audit

6.1 Technical prerequisites

Prerequisite Detail Status to check
Entra ID P1 Included in M365 Business Premium ✅ Within the MVC scope
Windows 10 21H2+ / Windows 11 On the workstations targeted by WHfB 📋 Inventory to be done
TPM 2.0 TPM chip enabled in the BIOS/UEFI (firmware or discrete) 📋 Device Manager → Security devices
Hybrid Entra Join Entra Connect configured on the hybrid workstations 📋 Entra ID → Devices → confirm the status
Hybrid accounts Cloud-only accounts cannot open a Windows session on a hybrid workstation 📋 Check the source of the user accounts
Windows Server 2016+ DCs For Cloud Kerberos Trust in hybrid, with enough writable DCs in each site where users authenticate 📋 Check the DC version and distribution
Non-privileged accounts Direct or indirect members of privileged built-in AD groups (Domain Admins, for example) cannot use Cloud Kerberos Trust 📋 Test with a standard user account
Global Admin + Domain Admin rights To create the AzureADKerberos object 📋 Available for the duration of the operation
PowerShell 5.1 The AzureADHybridAuthenticationManagement module does not work in PowerShell 7 📋 Check via $PSVersionTable.PSVersion

Note: privileged accounts and shared workstations

Privileged accounts: the password replication policy of the AzureADKerberos object blocks high-privilege accounts, as for an RODC. Microsoft advises against relaxing this policy to unblock them, because of possible attack vectors from Entra ID to AD. A deployment test run with an administrator account will fail: use a standard account.

Shared workstations: Microsoft limits the number of WHfB enrollments to 10 per device. For devices used by more than 10 people, or for users who sign in to many devices (a support technician, for example), Microsoft recommends FIDO2 security keys.

Preliminary check: existing WHfB GPOs in a hybrid environment

Active Directory WHfB GPOs take precedence over Intune policies on hybrid workstations. Check that no WHfB GPO is already in place before deployment:

Get-GPO -All | Where-Object {
  (Get-GPOReport -Guid $_.Id -ReportType XML) -match "PassportForWork"
}

6.2 Legacy application audit: mandatory step

Before any WHfB deployment, identify the applications likely to regress. A deployment without an audit can block users on critical business tools.

Quick audit method:

  1. Inventory of apps that interactively ask for Windows credentials
  2. Identification of NTLM flows: Event ID 4624 LogonType 3 + AuthPackage NTLM in the DC logs
  3. List of network shares / NAS accessible via Windows auth
  4. Inventory of RDP sessions to servers without Remote Credential Guard
  5. Check of Windows Credential Manager on the pilot workstations

6.3 Legacy applications: risks and mitigation

Application type Risk after WHfB Mitigation
Apps interactively asking for the Windows password Blocked: the user no longer knows their password Migrate to modern auth or keep a documented fallback password
Applications forcing NTLM Authentication failure or credentials prompt Configure SPN and Kerberos on the target server
Misconfigured WIA (missing SPN) Falls back to NTLM, fails Create the missing SPNs, check the negotiation order
RDP to legacy servers Password prompt Enable Remote Credential Guard or Restricted Admin mode
M365 apps using legacy protocols (IMAP, POP3, SMTP AUTH) Blocked if legacy protocols are not already blocked Deploy a Conditional Access policy blocking legacy protocols
Windows Credential Manager Renewal impossible if the password is forgotten Document the reset procedure with IT assistance

7. Deployment: Cloud Kerberos Trust and AzureADKerberos

7.1 Creating the AzureADKerberos object

What this object does

AzureADKerberos is a virtual RODC-type krbtgt object created in the AD and published in Entra ID. It establishes a shared secret between the on-prem AD and Entra ID, allowing Entra ID to issue partial TGTs that on-prem DCs recognize and exchange for full TGTs. Result: the WHfB user accesses on-prem resources without a password and without PKI.

Step 1: TLS 1.2

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

Step 2: PowerShell module (PowerShell 5.1 required, does not work in PowerShell 7)

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber -Force
Import-Module AzureADHybridAuthenticationManagement

Note: if the message “Required VC++ 2013 x64 Runtimes do not exist” appears, the module installs the runtime automatically. Let it finish.

Step 3: Variables

$domain = $env:USERDNSDOMAIN
$domainCred = Get-Credential -Message "Domain Admin credentials"

Step 4: Creation

Set-AzureADKerberosServer -Domain $domain `
  -UserPrincipalName 'admin@[tenant].onmicrosoft.com' `
  -DomainCredential $domainCred

An Entra ID sign-in window opens in the browser: sign in with the Global Admin or Hybrid Identity Admin account. No output = silent success.

Step 5: Verification

Get-AzureADKerberosServer -Domain $domain `
  -UserPrincipalName 'admin@[tenant].onmicrosoft.com' `
  -DomainCredential $domainCred

Expected output after a successful creation (validated in the lab, August 24, 2026)

Id                 : [unique number]
UserAccount        : CN=krbtgt_AzureAD,CN=Users,DC=[domain],DC=[ext]
ComputerAccount    : CN=AzureADKerberos,OU=Domain Controllers,DC=[domain],DC=[ext]
DisplayName        : krbtgt_[number]
DomainDnsName      : [domain.ext]
KeyVersion         : [number]
CloudKeyVersion    : [same number as KeyVersion]  ← synchronization confirmed
CloudKeyUpdatedOn  : [same date as KeyUpdatedOn]  ← ideally 0 seconds apart
CloudTrustDisplay  : [empty on first deployment, normal]

Points to check: KeyVersion = CloudKeyVersion and a gap between KeyUpdatedOn / CloudKeyUpdatedOn of less than 1h.

7.2 Configuring WHfB in Intune

Tenant-wide policy or Account protection profile

The tenant-wide policy applies at device enrollment, to the whole organization. After enrollment, Microsoft indicates using the "Account protection" profile (Endpoint security) or the settings catalog to manage WHfB on targeted groups. If both define the same settings (the PIN, for example), the WHfB policy applies: align the values to avoid unexpected behavior.

The method described below (tenant-wide policy + Cloud Kerberos Trust profile) is the one validated in the lab.

Step A: configure the tenant-wide WHfB policy

intune.microsoft.com → Devices → Enrollment → Windows → Windows Hello for Business

This policy exists on all tenants but is in the “Not configured” state by default.

Setting Recommended value Remark
Configure Windows Hello for Business Enabled Enables WHfB on all enrolled devices
Use a Trusted Platform Module (TPM) Required Two possible values. Required (default): only devices with an accessible TPM can provision WHfB. Preferred: the device tries to use the TPM and, failing that, falls back to software encryption. The key is then no longer hardware-protected, which weakens the guarantees described in sections 5 and 9. Keep Preferred for a transition phase on a mixed fleet.
Minimum PIN length 6 Recommended minimum
Allow biometric authentication Yes Fingerprint, facial recognition
Use security keys for sign-in Enabled Enables FIDO2 in addition to WHfB

Step B: create the Cloud Kerberos Trust profile

intune.microsoft.com → Devices → Configuration → Create → New policy

  1. Platform: Windows 10 and later
  2. Profile type: Settings catalog (not Templates)
  3. Name: WHfB-Cloud-Kerberos-Trust
  4. Add settings: search “Cloud Trust” → Windows Hello for Business category
  5. Setting: Use cloud trust for on-premises authentication → Enabled
  6. Assignment: initial pilot group (2 to 3 non-critical hybrid devices)
  7. Review + create → Create

Expected behavior at the first WHfB enrollment on a hybrid workstation (validated in the lab, August 24, 2026)

1. Windows sign-in with password → Windows detects the WHfB policy
2. Authenticator or registered MFA method requested to validate identity
3. WHfB wizard opens → PIN creation (6 characters minimum)
4. Reboot possible depending on the workstation: normal during the initial policy application
5. Sign back in with the PIN → an Entra ID sign-in window opens once to create the PRT
6. Subsequent sign-ins: PIN only, no more Microsoft sign-in window

Note: the Intune tenant-wide policy works without a GPO on hybrid workstations. If a WHfB GPO exists in the AD, it takes precedence over Intune: check section 6.1.

7.3 Checking the WHfB state on the workstation

From an administrator command prompt:

dsregcmd /status

Key fields to check in the output (validated in the lab, August 24, 2026)

Device State :
  AzureAdJoined : YES  ← workstation joined to Entra ID
  DomainJoined  : YES  ← workstation joined to the on-prem AD (hybrid)
  TpmProtected  : YES  ← WHfB key in the TPM

User State :
  NgcSet    : YES      ← WHfB enrolled for this user
  NgcKeyId  : {GUID}   ← identifier of the WHfB key in the TPM

SSO State :
  AzureAdPrt : YES  ← Entra ID PRT active (M365 SSO)
  OnPremTgt  : YES  ← on-prem Kerberos ticket active
  CloudTgt   : YES  ← Cloud Kerberos Trust active ✅

Diagnostic :
  KeySignTest : PASSED  ← the WHfB key signs correctly

Troubleshooting: PreReqResult = WillNotProvision

If NgcSet : NO and PreReqResult : WillNotProvision appear, check two points:

1. Does the account have an MFA method in the new unified Entra ID system?
Check via: entra.microsoft.com → Users → [account] → Authentication methods
Legacy methods (Authenticator registered via outlookMobile) may not be enough.
Solution: register a native method via aka.ms/mysecurityinfo.

2. Is the account subject to an active MFA policy?
An account excluded from every MFA policy cannot enroll in WHfB.
WHfB requires strong identity validation during enrollment.

7.4 Conditional Access: require phishing-resistant MFA

Once WHfB and FIDO2 are deployed, create a Conditional Access policy that exclusively requires a phishing-resistant method, which removes the fallback to SMS or TOTP.

License scope: Entra ID P1, within the Business Premium scope

The "Require authentication strength" feature in Conditional Access only requires P1.

Built-in authentication strengths in the interface:

Mandatory prerequisite before activation

Every user subject to this policy must have at least one phishing-resistant method registered. Without it, the user will be blocked. First enable the policy in "Report-only" mode and check the logs before switching it to On. A minimum of 2 weeks of monitoring is recommended.

Policy 1: privileged accounts (top priority)

entra.microsoft.com → Conditional Access → Policies → New policy

  1. Name: CA-Phishing-Resistant-Admins
  2. Users: Directory roles → Global Administrator, Privileged Role Administrator, Security Administrator (at a minimum)
  3. Target resources: All resources (formerly “All cloud apps”)
  4. Access controls → Grant: Grant access → Require authentication strength → Phishing-resistant MFA → Select
  5. Enable: Report-only → Create

Microsoft warning when creating the policy

"Don't lock yourself out! This policy affects the Azure portal." (translated from the French UI) It can be ignored in Report-only mode: Report-only mode never blocks access.

Policy 2: all users (progressive rollout)

Deploy only after confirming that all users have enrolled WHfB or a passkey.

  1. Name: CA-Phishing-Resistant-AllUsers
  2. Users: All users, excluding the break-glass group
  3. Target resources: All resources (or critical applications only at first)
  4. Access controls → Grant: Grant access → Require authentication strength → Phishing-resistant MFA → Select
  5. Enable: Report-only → minimum 2 weeks of monitoring → switch to On

What the policy does in On mode: exact behavior

The policy does not force WHfB enrollment automatically. It requires that a phishing-resistant method be used to authenticate.

· User with WHfB enrolled: seamless sign-in via WHfB, policy satisfied.
· User with a FIDO2 passkey: sign-in via passkey, policy satisfied.
· User without a phishing-resistant method: access blocked, redirected to aka.ms/mysecurityinfo.

Older accounts without a registered phishing-resistant method will be blocked. Plan an enrollment campaign before switching to On.

Preliminary audit: identify non-compliant accounts

Get-MgUser -All | ForEach-Object {
  $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
  $resistant = $methods | Where-Object {
    $_.AdditionalProperties.'@odata.type' -match 'fido2|windowsHello|x509Certificate'
  }
  if (-not $resistant) {
    [PSCustomObject]@{ UPN = $_.UserPrincipalName; DisplayName = $_.DisplayName }
  }
}

Note: passkeys by default, then SMS and voice retirement

Starting September 1, 2026 (gradual rollout), Microsoft automatically enables passkeys for users configured for SMS or voice and prompts them to register one at MFA sign-in. Microsoft-provided SMS and voice will be retired on February 1, 2027 for all users except Global Administrators and external users, whose date is July 1, 2027. Internal guest users follow the February 1 date.

Organizations that need to keep SMS or voice can configure a telephony provider through Microsoft Security Store (available since October 30, 2026, at their own cost). Otherwise, plan the migration to WHfB or passkeys before these dates.

8. Rotating the AzureADKerberos key

8.1 Why and how often

Cadence Context Remark
Same schedule as the AD krbtgt rotation Microsoft recommendation Microsoft does not mandate a fixed interval
More frequent Sensitive environments Governance choice to document (data security, art. 8 nFADP)
Immediately Confirmed compromise of a Domain Admin account Emergency procedure

8.2 Standard rotation procedure

Step 1: Rotation

Set-AzureADKerberosServer -Domain $domain `
  -UserPrincipalName 'admin@[tenant].onmicrosoft.com' `
  -DomainCredential $domainCred -RotateServerKey

Step 2: Immediate verification: run Get-AzureADKerberosServer (see 7.1). KeyVersion must equal CloudKeyVersion, and the gap between KeyUpdatedOn and CloudKeyUpdatedOn must stay under 1h.

Step 3: Wait: do not start another rotation for at least 10h (the default lifetime of a Kerberos TGT), ideally 24h.

Step 4: Validation: test a WHfB sign-in on a hybrid workstation to confirm that the rotation did not break authentication.

Coordination with the AD krbtgt account rotation

The AzureADKerberos object and the AD krbtgt account are two distinct objects with independent keys: their rotations are separate operations.

AD krbtgt rotation: classic best practice, recommended every 60 to 90 days, or immediately after any incident involving unauthorized Domain Admin access. The krbtgt rotation is done in two passes spaced by the maximum Kerberos ticket lifetime (10h by default) to avoid blocking active sessions.

Recommended order: AD krbtgt first (double rotation D+0 / D+10h minimum), then AzureADKerberos after confirming stability. Leave at least 10 to 24h between the two. Aligning both cycles on a common schedule, as Microsoft recommends, simplifies management and reduces the risk of forgetting.

8.3 Automation via Azure Automation

Periodic runbook logic:

  1. Retrieve the credentials from Azure Key Vault (never in clear text in the script)
  2. Run Set-AzureADKerberosServer -RotateServerKey
  3. Run Get-AzureADKerberosServer → check that KeyVersion = CloudKeyVersion and that the gap between KeyUpdatedOn and CloudKeyUpdatedOn is under 1h
  4. If the gap is greater than 1h: send an email / Teams alert → manual intervention required
  5. Log the result in Log Analytics for the audit trail

Required rights: Hybrid Identity Administrator (Entra ID) + delegated Domain Admin rights (via a Credential stored in Key Vault).

9. Annex A: hardware FIDO2 for privileged accounts

9.1 When to prefer a physical key over TPM-based WHfB

Criterion WHfB / TPM Physical FIDO2 key
Portability Tied to the workstation Portable between workstations
Cost Zero (built into the workstation) 30 to 80 CHF / unit depending on model
Declared lifespan Tied to the workstation (5 to 10 years) YubiKey: 5 years minimum, typically 7 to 10 years. Feitian: 5 years declared. Practical limit: physical loss or policy change (certified USB connector >10,000 insertions).
Deployment Via Intune, scalable Physical distribution, manual
Loss / theft No risk (key in the TPM) Physical risk: revocation procedure needed
Recommended accounts All standard users Global Admin, break-glass, PIM accounts

9.2 Enabling FIDO2 in Entra ID

entra.microsoft.com → Authentication methods → Policies → Passkey (FIDO2)

Page: Passkey (FIDO2) settings

Important: FIDO2 is disabled by default

Unlike CAE, the "Passkey (FIDO2)" method is disabled by default on all tenants. Manual activation is required.

“Enable and target” tab:

  1. Enable toggle → Enabled
  2. Include tab → All users (or a specific group depending on the deployment strategy)
  3. Exclude tab → Add the break-glass group

“Configure” tab:

Note on Microsoft Authenticator in the AAGUIDs

The interface offers Windows Hello, Microsoft Authenticator and Enter AAGUID as shortcuts. Microsoft Authenticator = Synced passkey stored in the mobile app, synchronized via Microsoft. More convenient but slightly less robust than a Device-bound key for ultra-sensitive accounts. For Global Admin: prefer Device-bound only (YubiKey or TPM).

Enrollment: the user enrolls their key or passkey via aka.ms/mysecurityinfo.

10. Conclusion: intellectual honesty about the level of protection

This document does not make a Microsoft 365 tenant unbreachable. It raises the difficulty for the attacker.

Level Measure What it guarantees
Baseline MFA only, no CAE A stolen cookie is exploitable until revocation, then the access token stays valid for up to one hour
+ CAE CAE + Identity Protection Near real-time revocation (up to 15 minutes according to Microsoft), provided detection follows
+ SIEM Rules M2/M3/M5 to M8/M12/M14 + M-new-1 + M-new-2 Visibility on post-exploitation actions in the tenant
+ Purview Suite (add-on) IRM data-leak policy + eDiscovery Premium SharePoint coverage and building nFADP evidence
+ WHfB / FIDO2 Structural protection (TPM + Cloud Kerberos Trust) Proxy-based AiTM attack defeated (no valid session for the proxy)
Full posture WHfB + key rotation + legacy audit + SIEM + IRM Structural resistance + residual risk management

Other vectors stay active regardless of WHfB: compromised endpoint (malware, keylogger), direct social engineering, compromise of the on-prem DC. WHfB closes the AiTM vector but does not replace an overall security posture.

Recommended next step: make sure CAE is active immediately (a 20-minute check), then plan WHfB as a hardening project over 1 to 2 sessions.

11. Annex B: why a SIEM is essential, even a free one

11.1 The problem without a SIEM

The IoCs described in this document exist in the Entra ID, Exchange and Defender logs. Identity Protection sends alerts, but they land in a portal that nobody actively monitors. Without a SIEM, detection is manual, reactive and often too late.

A SIEM with correlation rules turns these signals into actionable alerts, in real time, sent to the channels the IT team actually watches (email, Teams, SMS). That is the difference between discovering a compromise 3 days after the fact and reacting within 7 minutes.

11.2 Open source / free options for an SME

SIEM Strengths Weaknesses M365 integration
Wazuh Very popular, large community, abundant documentation, native endpoint agents, built-in XDR Manual and complex M365 configuration, steep learning curve Via the Wazuh Office 365 module (Management Activity API), manual rule configuration
UTMStack CE Intuitive interface, native O365 integration, M-series rules validated in the lab on the AiTM and CVE-2026-69836 scenarios, documented lab available Smaller community, fewer online resources Native O365: M-series rules ready to import, validated in the lab
Graylog Excellent for high-volume log management, clear interface Less SIEM-oriented, limited correlation in the CE version Via custom inputs, requires rule development

11.3 Recommendation for an M365 SME

For an SME of 5 to 25 users on M365 Business Premium, UTMStack CE offers the best deployment / immediate coverage ratio for the scenarios documented in this guide.

UTMStack lab: M365 rules validated in the lab

The UTMStack lab documented on GitHub Pages covers all the M365 correlation rules used in this guide, with ready-to-import YAML files, documented trigger tests and the fields available in each alert.

· Chapter 11: M-series correlation rules (including M-new-1 and M-new-2), in French
· Complete UTMStack lab (in French)

12. References and resources

Document / Resource License scope Link
MVC Purview nLPD Guide, Swiss SMEs (in French) Business Premium (no add-on) doit4everyone.github.io
Full Purview 2026 guide: IRM (8.2), eDiscovery (8.3) (in French) Business Premium + Purview Suite (add-on required) Section 8: Advanced features
Shadow AI / Copilot Governance guide (in French) Business Premium + Purview Suite (add-on required) doit4everyone.github.io
UTMStack lab: Chapter 11 (rules M-new-1, M-new-2) (in French) UTMStack CE (open source) 11-correlations-yaml.html
UTMStack lab: home (in French) UTMStack CE (open source) utmstack-lab
Microsoft: Cloud Kerberos Trust Business Premium (included) learn.microsoft.com
Microsoft: CAE Business Premium (included) learn.microsoft.com
Microsoft: FIDO2 security keys Business Premium (included) learn.microsoft.com
Microsoft: CVE-2026-69836 advisory N/A msrc.microsoft.com
The Hacker News: correction of the CVE-2026-69836 exploitation status N/A thehackernews.com
ANY.RUN: Mirage2FA research N/A any.run
The Hacker News: Mirage2FA N/A thehackernews.com
Microsoft: SMS and voice retirement (FAQ) N/A learn.microsoft.com

📥 Downloads

← Back to the MVC nLPD bundle · 🏠 Back to the main portal

ℹ️ References, structuring and drafting assistance provided by AI, with final human validation. Field validation performed on a real hybrid infrastructure, August 2026. Corrected on November 2, 2026: Mirage2FA figures, CVE status, SMS and voice retirement, technical clarifications (CAE, Identity Protection, WHfB, Cloud Kerberos Trust, rotation, logs).