Fake AI event lures combine device-code phishing and AiTM against Microsoft and Google accounts

Push Security has published an analysis, dated 5 November 2026, of an active phishing campaign that lures victims with fake AI-event registration pages impersonating brands such as OpenAI, SpaceX and Anthropic. According to Push Security, the campaign combines device-code phishing with adversary-in-the-middle (AiTM) reverse proxies to compromise Microsoft and Google accounts, targeting OAuth tokens, passwords, MFA responses and session cookies.

Not every visitor lost every type of credential: Push says it detected and blocked lure visits in customer browsers, and the report does not disclose how many downstream compromises occurred.

The lure

Victims arrive through event invitations distributed via short links and redirects, including Google's shortener, Zapier's zpr.io and, in one chain analyzed by Push, an X redirect. A Cloudflare bot challenge keeps automated scanners away from the registration page, which presents a plausible event sign-up and prompts visitors to continue with a work account. From there the flow splits into a Microsoft path and a Google path.

The Microsoft route: a code first, then a proxy

Visitors who choose Microsoft first encounter a device-code flow run through Kali365, a phishing-as-a-service kit. They are shown a code, taken to Microsoft's genuine device sign-in page, and asked to enter the code and authenticate. Because the page is real, nothing looks wrong — but approval issues Microsoft tokens into a session the attacker controls. The victim is then redirected once more, to a Microsoft sign-in page served through VoidProxy, an AiTM reverse-proxy service, in a second attempt to capture the password and session cookie.

The Google route: straight into the proxy

Selecting Google skips the device-code stage. A popup opens a VoidProxy-hosted proxy that relays Google's real sign-in interaction, aiming to capture the password, the MFA response and the resulting session cookie as the victim completes authentication through it.

Attribution and tooling

Push assigns the names ZoomMock and MSDRoot to the lure kits and assesses at medium-high confidence that the same operators run both. The operator is most likely a paying customer of Kali365 and VoidProxy; Push found no evidence linking the two services' developers to each other. Lure-kit authors, campaign operators and phishing-platform developers are distinct groups, per the report.

Why phishing-resistant keys are not enough

The device-code route does not break FIDO2 or WebAuthn cryptographically. The victim authenticates on the genuine Microsoft site; the problem is that they are approving a flow the attacker initiated. Enforced origin-bound, phishing-resistant authentication does stop the AiTM stages, because the proxy presents a false origin — but only if no weaker fallback is permitted, and it cannot prevent a password from being typed into a proxy page in the first place.

Defenses and their limits

Push maps controls to each stage of the chain. Disabling the device-code flow, possible in Microsoft Entra ID, blocks that route within the policy's scope — but report-only mode blocks nothing, and the setting does not address a separate AiTM sign-in. Enforced phishing-resistant MFA prevents completion of false-origin sign-ins. Session binding and Conditional Access can constrain token or cookie reuse, with effectiveness depending on the product, application, client and policy. Browser-level detection may catch the lure or the proxy, though Push's own detections do not prove equivalent capability in every browser-security product. The report's conclusion is that these controls cover different stages and must be combined.

For investigation, Push points to invitations themed around GoTo Webinar or Zoom, requests to domains such as eventrsvp[.]app and rsvpconnect-events[.]com, shortener traffic over zpr.io and c.gle, device-code authentications in identity logs, and later sessions from unusual addresses or user agents. Unusual geography alone, the report cautions, does not prove session theft.

Why it matters

The campaign is a working demonstration of how phishers now stack techniques to route around MFA: device-code abuse sidesteps origin binding entirely by getting the victim to authenticate on the real provider, while AiTM proxies harvest credentials, MFA responses and cookies from whatever they can relay. The AI-event theme is effective bait precisely because invitations to AI talks and launches are routine for the technical audiences being targeted. For defenders, the practical lesson is layered controls — phishing-resistant MFA without fallback, disabling device-code flows where they are not needed, session protections, and browser detection — because no single measure interrupts every route in the chain.