Knight Office: How AiTM Phishing Steals Microsoft 365 Sessions After MFA

Knight Office is a useful reminder that MFA validates a sign-in; it does not automatically protect every session created after that sign-in. In the incident documented by Huntress, an adversary-in-the-middle (AiTM) phishing chain captured Microsoft 365 session material and was followed by unauthorized Microsoft Entra ID device enrollment. The right operational framing is therefore identity compromise, not isolated password theft. 640

How the Knight Office attack chain works

The observed chain began with a DocuSign-style phishing email. Its link passed through a Monday.com tracking service and then a compromised Joomla site, concealing the final phishing destination from reputation checks and basic email-link inspection. 6

At the landing stage, a convincing Microsoft collaboration or sign-in workflow can prompt the victim to continue authentication, including a device-code-style interaction. The goal is to make the user approve an authentication flow they believe is legitimate.

The AiTM component acts as a reverse proxy between the victim and the real Microsoft sign-in service:

1. The victim enters credentials and completes the normal MFA challenge.
2. The proxy relays those interactions to Microsoft in real time.
3. Once authentication succeeds, the attacker captures the authenticated session cookie or other token material returned to the browser.
4. The attacker replays that authenticated state from their own infrastructure to access the account.

This does not mean the attacker broke MFA cryptography. It means the attacker stole the authorization state produced after MFA. Microsoft defines token theft as the compromise and replay of tokens issued to a user who may already have satisfied multifactor authentication. 40

Why a password reset may not end the intrusion

A stolen browser session or refresh-token-derived access can let an intruder continue operating without another password prompt or MFA challenge until the relevant tokens are revoked. Microsoft’s token-theft guidance explicitly calls for blocking affected users or devices and revoking current tokens. 40

Knight Office raises the stakes because the reported post-compromise activity included enrolling an unauthorized host in Microsoft Entra ID and setting up attacker-controlled Windows Hello for Business credentials. 6 That can create a separate authentication path: even after the original web session is revoked or a password is reset, defenders must verify that no unauthorized device or new authentication method remains.

The same persistence concept has been documented in device-code phishing research. Microsoft reported that a refresh token obtained through an abused device-code flow can be used to obtain access for device registration and register an actor-controlled device in Entra ID. 28

Device-code phishing is related—but not identical—to AiTM

AiTM phishing proxies a live sign-in and steals the resulting session. Device-code phishing instead abuses a legitimate OAuth device authorization flow: an attacker starts a device-code request, persuades a victim to enter the code and authenticate, and receives tokens for the attacker-controlled client if the victim approves it. 22

Both techniques shift the attacker’s objective from password collection to acquisition of usable authorization artifacts. Detection programs should cover both paths. Elastic’s device-code detection guidance highlights successful, interactive Entra sign-ins using the device-code protocol with the Microsoft Authentication Broker client and requests for first-party resources such as Exchange Online, Microsoft Graph, or SharePoint. 17

Observed activity and the PhaaS context

The Huntress investigation established a real Knight Office intrusion sequence: a document-themed lure, multi-hop redirects, session-token capture, and unauthorized Entra device enrollment. Huntress also linked repeated token replay in its telemetry to a single IP address, but that observation should not be treated as a global victim count. 6

Knight Office also fits a broader market for phishing-as-a-service kits aimed at Microsoft 365 identity sessions:

• Mirage2FA uses AiTM infrastructure to capture credentials and authenticated sessions. ANY.RUN reported 9,332 potential compromise events between 2024 and 2026, including 4,561 cookie-theft events. Those are telemetry-based potential events, not a count of confirmed victims. 4
• Kali365, first seen in April 2026 and distributed primarily through Telegram, was the subject of an FBI warning for its ability to obtain Microsoft 365 OAuth access and refresh tokens. 1

The shared defensive lesson is straightforward: protect, detect, and respond to session and token abuse as carefully as password compromise.

Detection priorities for Entra ID and Microsoft 365

Focus on correlations rather than a single alert.

1. Find suspicious session replay

Investigate sign-ins where the same account or session appears from materially different IP addresses, networks, geographies, browsers, or device properties in a short period—especially just after successful MFA. Microsoft notes detections for anomalous token use and unfamiliar sign-in properties associated with session cookies. 38

2. Hunt for suspicious device-code activity

Review successful device-code authentications and determine whether the client, source IP, requested resource, and user behavior make sense. In Entra sign-in logs, device-code activity can be identified through fields such as authenticationProtocol: deviceCode and originalTransferMethod: deviceCodeFlow. 26

3. Watch for persistence changes

Prioritize Entra audit events involving:

• New device registrations, joins, ownership changes, or unusual device identifiers.
• Newly added Windows Hello for Business, FIDO2/passkey, MFA, or recovery authentication methods.
• Application-consent grants, enterprise application changes, service principals, or privileged role assignments.
• Conditional Access, named-location, federation, mailbox-forwarding, and inbox-rule changes.

An unauthorized device registration shortly after suspicious authentication should be treated as a high-priority identity-persistence signal. 2628

4. Correlate email and identity evidence

A DocuSign-themed message alone may be spam; a new Entra device alone may be benign. The combination of a suspicious message, redirect-chain evidence, a successful MFA event, anomalous session reuse, and a device or authentication-method change is far more actionable.

Incident response: contain the identity, not just the password

For a suspected AiTM or device-code token-theft event, use an identity-containment workflow.

1. Block or disable the affected identity as needed. Disable affected user and device accounts while the scope is established. 40
2. Revoke current sessions and refresh tokens. Use the Entra sign-in-session revocation process, then force reauthentication. Microsoft specifically recommends revoking refresh tokens with revokeSignInSessions in device-code phishing response. 27
3. Reset credentials, but do not stop there. A password reset is supplementary containment, not proof that attacker access is gone. 4042
4. Remove persistence. Identify and remove unauthorized Entra devices; review device ownership; remove recently added Windows Hello for Business, FIDO2, MFA, recovery, and application credentials; and examine consent grants. 628
5. Hunt across the tenant. Search for matching lure URLs, redirect infrastructure, suspicious source IPs, device-code events, post-MFA sign-in anomalies, and new device registrations across all users.
6. Assess business impact. Review Exchange, SharePoint, OneDrive, Teams, Microsoft Graph, OAuth, and administrative audit activity for data access, mailbox rules, forwarding, external sharing, consent abuse, privilege changes, and SSO-connected application access.
7. Preserve evidence before cleanup. Retain phishing messages and headers, mail traces, redirect chains, Entra sign-in and audit logs, device records, OAuth-consent records, and browser or endpoint telemetry.

Reduce exposure before the next lure

Phishing-resistant authentication is an important control for high-risk users, but it should be part of a layered program. Microsoft recommends phishing-resistant methods such as FIDO2 security keys, Windows Hello for Business, and certificate-based authentication, alongside controls that reduce the usable lifetime of sessions on unmanaged devices. 39

Organizations should also evaluate whether device-code flow is necessary for their environment, restrict unauthorized device registration, apply Conditional Access based on compliant devices and risk, and ensure their operations team can quickly revoke sessions and investigate identity-object changes.

The central lesson from Knight Office is not that MFA has failed. It is that a successful MFA event can be the beginning of the compromise when an attacker steals the session that follows. A response is complete only when the tenant’s sessions, devices, authentication methods, and delegated access have all been checked and contained.