QR Code Phishing Targeting Swiss Microsoft 365 Tenants: An Adversary-in-the-Middle Campaign

Quishing — QR code phishing — is not a new concept, but the current wave hitting Swiss Microsoft 365 tenants represents a meaningful escalation in both technique and targeting precision. Unlike conventional phishing links embedded in email body text, QR codes are opaque to most email security gateways: they are images, not URLs, and the encoded destination is invisible to standard link-scanning engines. The victim's mobile device performs the URL extraction, typically in an environment with fewer enterprise security controls than the corporate laptop. This combination — gateway blindness plus a less-controlled scanning device — is exactly why attackers have doubled down on QR code delivery throughout 2025 and into 2026.

What makes the current campaign targeting Swiss organisations particularly significant is the infrastructure sitting behind the QR code. Victims are not redirected to a static credential-harvesting page. They are routed through an adversary-in-the-middle proxy — a live relay that sits between the victim and the legitimate Microsoft 365 login service, capturing not just credentials but authenticated session tokens. The practical consequence is that multi-factor authentication, as most organisations have deployed it, offers no protection against this technique.

How the Attack Works

Stage 1 — QR Code Delivery via Email and Physical Mail

The campaign uses two delivery channels that are rarely seen in combination. The primary vector is email: messages arrive appearing to originate from internal IT departments, HR functions, or trusted vendors, instructing recipients to scan a QR code to complete an urgent action — a password reset, a Conditional Access policy acknowledgement, or a multi-factor authentication re-enrolment. The QR code is embedded as an image in the email body or attached as a PDF, both of which bypass URL-scanning controls that operate at the link-text level.

The secondary vector is physical mail. Printed letters bearing credible corporate branding and Swiss postal markings have been reported by several organisations across the financial services and healthcare sectors. Physical mail carries an implicit legitimacy that email no longer does, and many employees have been conditioned to treat physical correspondence as more trustworthy than digital messages. A QR code on a printed letter arrives entirely outside any email security perimeter.

Stage 2 — Victim Scans the QR Code

When the recipient scans the QR code — almost certainly on a personal or lightly-managed mobile device — the device's camera app resolves the encoded URL and opens it in a mobile browser. At this point the victim has left the corporate network perimeter and any associated proxy or DNS filtering. Mobile devices in personal use, and many corporate-enrolled devices with standard MDM profiles rather than full MAM policies, will open the resolved URL without any security interception.

Stage 3 — The AiTM Proxy Page Mimicking Microsoft 365 Login

The resolved URL leads to a page that is visually indistinguishable from the genuine Microsoft 365 authentication portal. The domain uses homograph characters, typosquatting, or compromised legitimate subdomains to appear credible in the browser address bar. Crucially, this page is not a static clone: it is an adversary-in-the-middle proxy, a server that in real time forwards the victim's browser session to the genuine Microsoft login service and relays responses back to the victim. The victim sees the real Microsoft login flow, including any branded sign-in page customisation configured by their organisation's tenant.

Stage 4 — Credentials and Session Cookie Stolen

As the victim enters their username and password, those credentials pass through the attacker's proxy before reaching Microsoft. The proxy logs them. When Microsoft's authentication service completes the login — including prompting for and accepting the MFA factor — the resulting authenticated session cookie is also captured by the proxy. This cookie represents a fully authenticated session: it proves to Microsoft's services that authentication, including the MFA step, has already been completed.

Stage 5 — MFA Bypassed via Token Replay

The attacker extracts the captured session cookie and injects it into their own browser session. Microsoft's services receive a request presenting a valid, recently-issued authenticated session token. From the platform's perspective, the authentication event — including MFA — has already occurred. The attacker now has full access to the victim's Microsoft 365 account: email, SharePoint, Teams, OneDrive, and any connected applications. No additional authentication is required.

Why MFA Does Not Stop This Attack

This is the point that is most frequently misunderstood, and it is worth being precise. MFA does work in this attack — it completes successfully, as designed. The victim receives the push notification or enters the TOTP code, and Microsoft's authentication service accepts it. The problem is not that MFA fails; the problem is that MFA was designed to protect the credential exchange, and the attacker has bypassed the credential exchange entirely by stealing what comes after it: the session token.

Standard MFA — SMS OTP, authenticator app push notifications, TOTP codes — authenticates the login event. It does not authenticate the resulting session. Once a session token is issued, it is valid for however long Microsoft's token lifetime policies permit, typically hours or in misconfigured tenants much longer. The AiTM proxy captures this token at the moment of issuance and replays it from the attacker's infrastructure. The token replay is indistinguishable from a legitimate continuation of the authenticated session.

This is not a vulnerability in Microsoft's platform. It is an inherent limitation of cookie-based session management when authentication and session binding are decoupled. The only MFA mechanisms that defeat this attack are those that cryptographically bind the authentication assertion to the specific client device and origin — which brings us to phishing-resistant MFA.

Infrastructure and Attribution

Infrastructure analysis of the proxy domains used in this campaign reveals a cluster of characteristics consistent with a known Eastern European threat group that has been tracked by multiple threat intelligence vendors since late 2024. The overlaps are not conclusive for attribution but are significant enough to treat seriously.

The proxy infrastructure relies on fast-flux DNS: the IP addresses associated with the malicious domains rotate on intervals of minutes to hours, making IP-based blocking largely ineffective. The hosting providers are a mix of bulletproof hosting services in jurisdictions with limited law enforcement cooperation and compromised legitimate hosting accounts — a combination that provides operational resilience and complicates takedown efforts.

Domain registration patterns show a preference for registrars that accept cryptocurrency payment and offer privacy-protected WHOIS records. Registration timestamps cluster around weekday working hours in the UTC+2 and UTC+3 time zones, consistent with an operator base in Eastern Europe. Several domains were registered using email addresses that share infrastructure with domains previously attributed to the group in question in public threat intelligence reporting.

The targeting profile — Swiss financial services, healthcare, and professional services organisations — is also consistent with the group's known focus on high-value credential acquisition for subsequent business email compromise and financial fraud operations, rather than espionage or ransomware deployment.

Indicators to Watch

Security teams investigating potential exposure or monitoring for this campaign should look for the following patterns.

URL patterns: Proxy domains frequently incorporate strings such as login, microsoftonline, mfa, verify, or secure combined with random alphanumeric substrings. Domains using Unicode homograph characters that visually resemble Latin letters (for example, Cyrillic characters substituted for visually similar Latin equivalents) are a strong indicator. TLDs outside Microsoft's legitimate domain set (.com, .net) appearing in authentication URLs should trigger immediate investigation.

QR code characteristics: QR codes in email or physical mail that encode URLs not belonging to your organisation's verified domains, particularly those resolving to IP addresses rather than resolvable hostnames, or to hostnames registered within the past 30 days, warrant immediate scrutiny. QR codes embedded in PDF attachments rather than inline in email body HTML are a delivery pattern consistent with evasion of image-scanning controls.

Email sender anomalies: Emails carrying QR code lures often originate from domains that pass SPF and DKIM validation — frequently because they use compromised legitimate sending accounts or newly registered lookalike domains with valid DNS records. Look beyond authentication results: examine the display name versus the actual sending address, the age of the sending domain, and whether the sending infrastructure has appeared in threat intelligence feeds.

Defensive Measures

• Deploy phishing-resistant MFA (FIDO2/passkeys) for all privileged accounts and, as a target state, all users. FIDO2 authentication cryptographically binds the authentication assertion to the origin and the specific client device. An AiTM proxy cannot relay a FIDO2 challenge-response because the origin presented to the authenticator does not match the legitimate Microsoft domain. This is the only MFA mechanism that defeats AiTM at the authentication layer. Microsoft Entra ID supports FIDO2 security keys and Windows Hello for Business as phishing-resistant authentication methods.
• Implement Conditional Access policies requiring compliant and managed devices. Configure Conditional Access in Microsoft Entra ID to require device compliance as a condition for accessing Microsoft 365 resources. An attacker replaying a stolen session token from an unmanaged device will fail this check if the policy is correctly configured to evaluate device state at each access request, not only at initial authentication. Combine this with Continuous Access Evaluation where available to reduce token lifetime and force re-evaluation of access conditions.
• Restrict external QR code scanning on managed devices. For managed mobile devices enrolled in Intune or a comparable MDM solution, consider deploying configuration profiles that restrict or log QR code scanning to approved applications. At minimum, ensure that managed devices route all browser traffic through a corporate proxy or DNS filtering service so that QR-code-resolved URLs are subject to the same controls as email links. User-owned devices used for MFA (BYOD) represent a gap that should be addressed in your mobile security policy.
• Deliver targeted user awareness training specific to QR code lures. General phishing awareness training does not prepare employees for QR code attacks. Develop and deliver specific training scenarios covering: why QR codes in email and physical mail are high-risk; how to verify a QR-code-resolved URL before proceeding; the principle that IT departments do not request credential re-entry via QR codes; and the reporting path for suspected quishing attempts. Physical mail lures require explicit coverage — many employees have never been trained to treat physical correspondence with the same scepticism as email.
• Enable Microsoft Defender for Office 365 Safe Links with URL detonation and extend coverage to QR code content. Microsoft Defender for Office 365 Plan 2 includes QR code URL extraction capability in Safe Links, which attempts to resolve and evaluate the URL encoded in QR code images attached to or embedded in emails. Ensure this feature is enabled and that Safe Links policies cover both email and Teams messages. Complement this with Microsoft Defender for Cloud Apps session policies to detect and respond to anomalous session activity — such as a session originating from an unexpected geographic location or device immediately after authentication — which may indicate token replay in progress.