The situation

The lure came from a sender the recipient already trusted. The tone was familiar, the wording was routine, and the link asked for a quick review of something that seemed urgent. Nothing about it looked wrong at a glance, and that is the point. Phishing has moved well past the misspelled-sender era, so “look for typos” is no longer a defense you can rely on.

How the attack worked

The link didn’t go to the real site. It went to a reverse proxy styled to look like a Microsoft sign-in screen. Anything typed there was forwarded to the real service in real time, so the attacker completed the sign-in while the victim was still on the page. This is an adversary-in-the-middle (AiTM) attack, which maps to T1557 for the interception and T1566.002 for the delivery via link.

The part that matters most for response is what happened after sign-in. The attacker registered a new device under the account. A registered device stays bound to the identity after the phishing page is closed and the original session ends, so it works as persistence. This maps to T1098.005 (Account Manipulation: Device Registration).

From there, the account itself became a delivery channel. The same kind of lure can go out from a compromised mailbox to people who trust that sender. That is internal spearphishing (T1534), and it is why one click can reach more people than the one who clicked.

StageWhat the user seesWhat the attacker gets
LureFamiliar sender, routine request, urgent toneA click
Proxy pageA Microsoft-looking sign-in screenUsername and password as typed
RelayThe normal MFA promptA valid session after MFA completes
Device registrationNothingA device bound to the account
Outbound mailAn email from a known contactThe next lure, delivered from a trusted account
Fake Microsoft login: device registration and containmentThe attack: a lure from a trusted sender leads to a proxy page styled like Microsoft sign-in. The proxy relays the password and MFA to Microsoft in real time, the attacker finishes the sign-in live and gets a valid session, and then registers a rogue device to the user that outlives the session. The same account sends the next lure to people who trust the sender. Containment, in order: revoke sessions, remove the device, then reset the password and re-enroll MFA. A password reset on its own leaves both the session and the device in place.The attackTrusted lurefamiliar sender,urgent reviewProxy pagestyled like aMicrosoft sign-inRelaypassword and MFAsent on in real timeValid sessionattacker finishesthe sign-in liveRogue deviceregistered to user,outlives the sessionFrom the same account, the next lure goes out to people who trust the sender.Containment, in orderRevoke sessionsRevoke-MgUserSignInSessionends the stolen sessionRemove the deviceRemove-MgDeviceends the persistenceReset and re-enrollnew password,fresh MFA methodsA password reset on its own leaves both the session and the device in place.
Sign-in is relayed, then a device is registered. Containment has to undo both, and a password reset alone does neither.

First hour: triage

Start with three questions: when did the account sign in from somewhere unexpected, what devices are registered to it, and what has the mailbox sent or changed. The queries below use the Microsoft Graph and Exchange Online PowerShell modules.

Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'

# Sign-ins for the account over the last seven days: time, app, IP, location, result
Get-MgAuditLogSignIn -All -Filter "userPrincipalName eq 'user@example.com' and createdDateTime ge $((Get-Date).AddDays(-7).ToString('yyyy-MM-ddTHH:mm:ssZ'))" |
    Select-Object CreatedDateTime, AppDisplayName, IpAddress, Location, Status

# Devices registered to the account. Anything you can't tie to a real machine is a suspect.
# The cmdlet returns bare directory objects, so resolve each one to get the device details.
Get-MgUserRegisteredDevice -UserId user@example.com -All |
    ForEach-Object { Get-MgDevice -DeviceId $_.Id } |
    Select-Object Id, DisplayName, OperatingSystem, RegistrationDateTime   # Id = the object ID used below

# Inbox rules: forwarding, redirects, and rules that delete or move mail. Attackers hide rules here.
# -IncludeHidden catches rules that don't show in Outlook
Get-InboxRule -Mailbox user@example.com -IncludeHidden |
    Select-Object Name, Enabled, ForwardTo, RedirectTo, DeleteMessage, MoveToFolder

Also review the sent items for the lure and any replies, and check for app consents the user granted recently. Those are the attacker’s second and third stages.

Containment

Order matters here: cut access first, then repair the account.

  1. Revoke sessions. This invalidates the refresh tokens and sign-in sessions the attacker may be holding.
Connect-MgGraph -Scopes 'User.ReadWrite.All','Device.ReadWrite.All'
Revoke-MgUserSignInSession -UserId user@example.com
  1. Disable the unknown device, then remove it, after confirming its ID from the earlier query. Disabling cuts it off straight away and keeps the record for the investigation.
# Replace <device-id> with the object ID you confirmed as unrecognized
Update-MgDevice -DeviceId <device-id> -AccountEnabled:$false

# Once the investigation has what it needs
Remove-MgDevice -DeviceId <device-id>

  1. Remove malicious inbox rules and revoke suspicious app consents.

  2. Reset the password and re-register MFA methods, so the user is enrolling fresh methods rather than trusting the ones that may have been changed.

A password reset by itself does not end the session or remove the device. That gap is why this attack keeps coming back on accounts that were “fixed.”

Root cause

In this pattern, two controls usually fail together:

  • MFA that can be relayed. Push approvals and one-time codes pass through the proxy along with the password. Only phishing-resistant methods, such as FIDO2 security keys and passkeys, bind the authentication to the real site.
  • Open device registration. If any user can register devices without review, a single successful sign-in becomes permanent access.

Check your own tenant against both before assuming either control is in place. Don’t assume a default is the setting you want.

Remediation

The durable fixes live in policy, not in one-off cleanup.

ControlRecommended settingWhy
Authentication strengthConditional Access requires phishing-resistant MFA (FIDO2, passkeys or certificate-based) for admin roles first, then all usersCodes and push approvals can be relayed by AiTM proxies. FIDO2 is bound to the real origin.
Token protectionEnable for the sign-in scenarios your tenant supportsBinds tokens to the device, so a stolen token is much less useful elsewhere
Device registrationLimit who can join or register devices, and cap devices per userRemoves the easy persistence path
Mailbox and consent monitoringAlert on new inbox rules, forwarding and new app consentsCatches the attacker’s second stage early

Configure authentication strengths in the Microsoft Entra admin center under Protection › Authentication methods › Authentication strengths. Device registration settings are under Devices › Device settings.

Roll out Conditional Access in report-only mode first. Review the sign-in logs for break-glass accounts, service accounts and legitimate users who would be blocked, then enforce. Skipping this step is how a security change becomes an outage.

Verification

  • Use the Conditional Access What If tool with a pilot account to confirm the policy evaluates the way you intended.
  • In a lab tenant, attempt a sign-in with a password plus an app-based code. The expected result is a block wherever a phishing-resistant strength is required. Anything else means the gap is still open.
  • Re-run the device and inbox queries after the changes to confirm nothing reappeared.

Don’t stand up a live phishing proxy against production users to test this. A lab tenant gives the same answer without the risk to real people.

Caveats

Map the remediation to the framework your clients are audited against:

  • CMMC Level 2 / NIST SP 800-171 Rev. 2: IA.L2-3.5.3 (multifactor authentication) and IA.L2-3.5.4 (replay-resistant authentication)
  • PCI DSS v4.0: Requirement 8.4.2 (MFA for all access into the cardholder data environment)
  • HIPAA Security Rule: 45 CFR 164.312(d) (person or entity authentication)
  • SOC 2: CC6.1 (logical access)

If phishing-resistant MFA can’t roll out this quarter, document the compensating controls and the risk acceptance, with a named owner and an end date. An open-ended exception is a finding waiting to happen.

What to tell users

The best user-side control is a fast report. Keep the message short:

  • Report immediately, even if you’re not sure. A fast report is what limits the damage, and nobody should be punished for reporting a mistake.
  • Don’t just delete the email. Tell the security team first so they can check the account.
  • Watch for signs of compromise: sign-in or verification prompts you didn’t trigger, sent messages you don’t recognize, and security methods or devices you don’t recognize.
  • Hover over links before clicking. If the domain isn’t the vendor’s real domain, don’t click.
  • Don’t sign in from a link in an email. Go to the site directly, or contact the sender on a phone number you already have.
  • When in doubt, don’t click. Checking a hundred harmless emails costs far less than missing one that isn’t.

Key takeaways

  1. A convincing sign-in page is enough. AiTM doesn’t break the login; it relays it, so the defense has to be phishing-resistant authentication.
  2. The attacker’s real target is the session. Containment has to revoke sessions and remove devices, not just reset a password.
  3. Device registration is persistence. Restrict who can register devices, and review what is registered on a schedule.
  4. Check inbox rules and sent mail for the account. A compromised mailbox becomes the next lure.
  5. Fast reporting limits the damage. Train users to report first and ask questions later.

References