13.12 Exchange Online Hardening

Exchange Online Hardening

The investigation revealed specific configuration gaps. This subsection documents each hardening action with the before state, the change, and the security impact.

Conditional access: require compliant device

Before: MFA required for all users. No device compliance check. Any device that presents valid credentials and MFA is allowed access.

After: Conditional access policy requires a compliant device (Intune-enrolled, meeting compliance policies) for Exchange Online and SharePoint Online access.

Impact: The attacker’s stolen token was replayed from an unmanaged device. With this policy, the sign-in would have been blocked at 09:22 — zero compromise, zero email access. This single control eliminates the entire AiTM attack chain for applications it covers.

1
2
3
4
5
6
7
8
9

// Verify the policy is working — check for blocked non-compliant sign-ins
SigninLogs
| where TimeGenerated > ago(7d)
| where ConditionalAccessStatus == "failure"
| mv-expand CAPolicy = parse_json(ConditionalAccessPolicies)
| where tostring(CAPolicy.displayName) has "compliant device"
| where tostring(CAPolicy.result) == "failure"
| summarize BlockedSignins = count() by bin(TimeGenerated, 1d)
| sort by TimeGenerated asc

Conditional access: block legacy authentication

Before: Legacy authentication protocols (IMAP, POP3, SMTP) not explicitly blocked. Attackers with stolen credentials could access email via IMAP without triggering MFA.

After: Conditional access policy blocks all legacy authentication protocols for all users, with a narrow exception for 2 multifunction printers using SMTP relay.

Impact: Eliminates the MFA bypass path via legacy protocols. Even if an attacker obtains credentials in a future attack, they cannot access the mailbox via IMAP.

Transport rules

Three transport rules deployed during the incident:

Rule 1: Phishing kit URL pattern block. Rejects emails containing URLs matching /auth/[a-f0-9]{32}/login. Blocked Waves 4 and 5 pre-delivery.

Rule 2: External sender banner. Prepends a warning banner to all external emails. Users reported this helped them identify the Wave 5 lure as external when the subject line implied an internal project update.

Rule 3: Lookalike domain block. Blocks external email from domains containing “northgate” — the organisation name. Catches future impersonation attempts regardless of TLD or prefix.

FIDO2 deployment plan

Deploying FIDO2 security keys to all 500 users is a multi-month project. The phased approach:

Phase 1 protects the accounts with the most privilege. Phase 2 protects the accounts most targeted by AiTM (finance was Wave 1’s target). Phase 3 is a long-term project requiring user training and distribution logistics.