Microsoft 365 login lookalikes: the five variants we see weekly

Every week, our classifier catches new variants of fake Microsoft login pages. Last quarter we processed a few thousand of these. Five patterns accounted for roughly 80 per cent of what our users encountered.

None of them are sophisticated. All of them work on a percentage of users who see them. Here they are, ranked by volume.

1. The typosquat Microsoft subdomain

Examples: login.microsofft.com, login-microsoft.com, login.m1crosoft.com. The attacker is betting that at a glance, your user reads what they expect to read.

These work because URL bars are not carefully inspected by most users, especially when they've just clicked a link in an email that looked legitimate. The failure rate for staff who've had no browser-level warning is depressingly high, around 34 per cent of users who land on one will enter credentials.

2. The homograph attack

Examples: domains using Cyrillic or Greek characters that render identically to Latin letters. A domain with a Cyrillic 'о' in place of a Latin 'o' is visually indistinguishable from the real thing in most fonts.

Browsers have some protections here (punycode display), but they're inconsistent across versions and settings. If your fleet is on mixed Chrome versions, you have mixed exposure.

3. The legitimate-cloud phishing page

Attackers host the fake login page on legitimate cloud services, SharePoint Online, Google Sites, Azure Storage, Cloudflare Pages. The URL reputation is 'clean' because the hostname is sharepoint.com, even though the content is a phishing kit.

Defences that rely solely on domain reputation miss this entirely. You need page-content analysis, not just domain checks.

4. The OAuth consent phish

This one doesn't ask for a password at all. Instead, it asks the user to grant OAuth permissions to a malicious app that will then sit in their mailbox reading email. Because the user never enters credentials, MFA never triggers. The 'permission granted' looks legitimate because the OAuth dialog is served by Microsoft itself.

This attack has grown significantly in the last 18 months. Training alone cannot prevent it, users are being asked to make an informed decision about a permission scope they don't understand.

5. The 'your password has expired' redirect

Variants of this one have been around forever, but they still work. The email says the user's password is about to expire. The link goes to a lookalike page styled identically to Microsoft's self-service password reset. The user enters their current password (to 'confirm identity') and a new one. Both go to the attacker.

This is the single highest click-through rate we see, not because the lure is clever, but because password-expiry warnings are something users are conditioned to act on quickly.

What to tell your staff (and what not to)

Don't tell them to 'be careful.' Being careful doesn't scale and doesn't help under pressure. Tell them this instead:

• Never enter your password on a page you arrived at by clicking a link. Navigate to the service directly.
• If a password-expiry message feels urgent, go to portal.office.com yourself and check from there.
• OAuth consent prompts for third-party apps from unsolicited emails are almost always malicious. Decline and report.

Then put a tool at the browser layer that flags the ones that make it through anyway. Your best-trained user still gets caught sometimes. That's what the safety net is for.