Fake AI Events: Device Code Phishing and AiTM Target Microsoft and Google Accounts

1. Basic Information

• Article Title: Analyzing a fake event campaign combining AiTM and device code phishing payloads
• Publisher: Push Security
• Publication Date: 2026-11-05
• Original Source: Push Security
• Related Sources: BleepingComputer: fake AI event phishing, Microsoft Entra authentication-flow controls, Microsoft Entra authentication strengths
• Related Malware: None identified
• Related Threat Actor: Operator identity undisclosed. ZoomMock and MSDRoot are Push Security's names for the lure kits.
• Related CVE: None
• Related Products and Services: Microsoft Entra ID, Google Workspace, Kali365, VoidProxy
• Severity: High

2. Executive Summary

Push Security analyzed fake event-registration pages impersonating brands including OpenAI, SpaceX, and Anthropic.

The Microsoft route starts with Kali365 device code phishing and then redirects the visitor to a VoidProxy Microsoft sign-in page. The Google route opens a VoidProxy reverse proxy directly. Depending on the route and which steps succeed, the campaign targets OAuth tokens, passwords, MFA responses, and session cookies.

This does not mean every visitor lost every type of credential. Push reported detecting and blocking visits on customer browsers; the number of downstream compromises was not disclosed.

3. Attack Flow

Shared Lure and Separate Authentication Routes

1. Invitation and Redirection: The visitor follows an event invitation through short links or redirects, including Google short links, Zapier's zpr.io, and, in an analyzed chain, an X redirect.
2. Bot Challenge and Event Page: A Cloudflare challenge limits scanner access to the fake registration page. The page asks the visitor to continue with a work account.
3. Microsoft Route:
   • The lure obtains a device code through Kali365.
   • The visitor enters the code and signs in on Microsoft's genuine device-login page.
   • Approval causes Microsoft tokens to be issued to the operator's Kali365 session.
   • The lure then redirects the visitor to a VoidProxy Microsoft sign-in page, attempting a second capture of the password and session cookie.
4. Google Route:
   • Selecting Google opens a VoidProxy reverse-proxy popup.
   • The proxy relays Google's sign-in interaction and attempts to capture the password, MFA response, and resulting session cookie.

The Microsoft follow-up and Google route depend on the visitor completing the relevant proxied sign-in.

FIDO2 is not cryptographically broken by the device-code route. The victim is authenticating on the genuine identity-provider site but approving a flow initiated by the attacker.

4. Threat Actor Location and Execution Site

• Attacker Position: An external operator controls invitations, lure pages, redirects, and collection infrastructure.
• Lure-Kit Attribution: Push assesses the link between ZoomMock and MSDRoot as medium-high confidence and considers the same operators likely responsible.
• PhaaS Relationship: Push assesses the operator as most likely a customer of both Kali365 and VoidProxy. It did not establish a link between the developers of those two services.

Lure-kit names, campaign operators, and PhaaS developers are distinct entities.

5. Victim and Administrator Visibility

• Visitor: A convincing event page leads to either Microsoft's genuine device-login page or a familiar-looking Microsoft or Google sign-in presented through a proxy.
• Administrator: Available records may show short-link navigation, newly observed lure domains, device-code authentication, and later session use from unusual addresses or user agents.
• Visibility Limit: Browser, identity, and SaaS records may each show only part of the chain. Unusual geography alone does not prove session theft.

6. Success and Failure Conditions

Success Conditions

• The visitor reaches the lure and chooses a work-account sign-in.
• In the Microsoft device-code route, the visitor approves the attacker-initiated flow on Microsoft's genuine page and policy permits token issuance.
• In an AiTM route, the visitor completes a sign-in that the proxy can relay.
• Subsequent misuse depends on the captured artifact's validity, permissions, and applicable access controls.

Controls and Their Limits

Conditions That Interrupt the Attack

• The visitor verifies the event independently and stops.
• An enforced policy blocks the relevant device-code flow.
• An enforced phishing-resistant authentication requirement prevents completion of the false-origin AiTM sign-in.
• A browser or network control blocks the lure or proxy before the relevant capture succeeds.

These controls address different stages and should be combined.

7. What Happens Upon Success

• Successful device-code approval can issue Microsoft tokens to the attacker's session.
• Successful Microsoft follow-up or Google AiTM sign-in can expose passwords and session cookies.
• Captured tokens or cookies may permit unauthorized SaaS access, subject to their validity, permissions, reauthentication requirements, and policy.

The report does not establish that every visitor suffered account takeover, that all later MFA challenges disappear, or that specific mail and file theft occurred in every case.

8. Observable Logs

The following combine reported infrastructure with possible local investigation sources. Follow-on actions listed here are investigation targets, not confirmed victim outcomes.

• Email: Event invitations, including messages associated with GoTo Webinar or Zoom-themed lures, and links using shorteners.
• Proxy / SWG / DNS: Requests involving eventrsvp[.]app, rsvpconnect-events[.]com, zpr.io, c.gle, and related phishing infrastructure.
• Endpoint / Browser: Lure-page visits, popups, and navigation to genuine device-login pages or deceptive proxy domains, where browser telemetry is available.
• Identity / IdP: Device-code authentication, token issuance, session identifiers, authentication methods, source addresses, and user agents. Exact fields depend on the log source.
• SaaS / Cloud: Subsequent Microsoft 365 or Google Workspace access, mail operations, sharing changes, and downloads.
• Network: Connections following the Cloudflare challenge and traffic to collection or proxy infrastructure.

A short token-issuance interval, a Cloudflare challenge, or a new domain is not sufficient evidence of compromise on its own.

9. Determining Attack Success

• Attempt Observed; Success Unconfirmed — Public Evidence: Push observed and blocked visits to lure pages on customer browsers. The report does not establish how far every visitor progressed.
• Device-Code Approval — Local Assessment: Correlate the approval with the operator-initiated flow and resulting token issuance. A legitimate device-code event alone is not malicious.
• Information or Session Compromise — Local Assessment: Establish that tokens or cookies were obtained through the phishing route, and correlate their use with identity and SaaS activity.
• Follow-On Activity — Local Assessment: Verify unauthorized mail, file, consent, or other operations separately.

An unfamiliar IP address alone does not confirm theft or account takeover.

10. Investigation Playbook

• Trigger: An event-registration report, suspicious device-code authentication, or a new AiTM-domain alert.
• Initial Checks: Preserve the invitation and redirect chain. Identify the selected sign-in route and whether the user entered a code, credentials, or an MFA response.
• Browser Investigation: Review available navigation, popup, download, and extension records.
• Identity Investigation: Correlate authentication flow, client or application, token audience, session identifiers, source addresses, MFA method, and issuance times.
• Follow-On Investigation: Check for suspicious consent, mail-forwarding rules, downloads, sharing changes, or access to other SSO applications.
• Containment: Use the provider's supported procedures to revoke affected sessions and tokens, reset exposed passwords, and restrict unnecessary device-code flows. Verify the outcome rather than assuming one action invalidates every application session.
• Classification: Separate lure visits, approval, credential or cookie capture, session use, and subsequent data access.

11. Defense and Detection Ideas

These are defensive proposals rather than universal indicators of malicious activity.

• Single-Event Detection: Investigate unexpected device-code use by users who have no documented need for it.
• Correlation: Link invitations and short-link clicks to device-login activity and later unusual SaaS sessions.
• Hunting: Combine redirect patterns, newly observed domains, authentication flows, and session behavior. Domains rotate, so static indicators alone have limited value.
• Logging Limits: Without browser telemetry, linking a legitimate IdP event back to the lure may be difficult.
• Priority Controls: Restrict unnecessary device-code flows, enforce phishing-resistant authentication for relevant resources, and deploy supported session protections and browser detection.

Legitimate device-code authentication exists. Alerting and blocking policies should reflect documented use cases and controlled exceptions.

12. Facts / Inference / Hypothesis

Facts

• Push detected and blocked visits to fake AI-event registration pages on customer browsers in late October 2026.
• The Microsoft route used Kali365 device-code phishing followed by a VoidProxy Microsoft sign-in page.
• The Google route used VoidProxy to relay the sign-in interaction.
• ZoomMock and MSDRoot are lure-kit names. Push assessed their operational link as medium-high confidence.
• Push did not establish a developer relationship between Kali365 and VoidProxy and considered the campaign operator most likely a customer of both.

Inference

• Combining trusted redirect services, new domains, and bot challenges can make email filtering and static URL reputation insufficient on their own.
• Defenders need to correlate browser and identity activity because the two authentication routes cross different trust boundaries.

Hypothesis

No additional hypotheses. Unconfirmed matters are listed under "Open Questions and Further Investigation".

13. MITRE ATT&CK Mapping

14. Open Questions and Further Investigation

• The initial invitation channel is not fully known for every observed visit.
• The number of organizations suffering downstream misuse or data theft was not disclosed.
• Whether a particular organization's tokens or cookies were captured requires local evidence.

15. Impact on SOCs and Organizations

Event invitations associated with well-known technology brands can make an account-sign-in request seem plausible. The important distinction is between approval on a genuine IdP through device code flow and authentication relayed through a deceptive proxy origin.

Organizations should not treat deploying passkeys as sufficient protection for both routes. Restrict unnecessary device-code flows within the correct policy scope, enforce phishing-resistant authentication without weaker fallback, and correlate browser, identity, and SaaS activity.

16. Summary by Role

• SOC: Correlate short links, lure pages, device-login or proxy navigation, and subsequent session use.
• Administrators: Restrict unnecessary device-code flows, enforce appropriate phishing-resistant authentication, and verify session-protection coverage.
• Users: Verify events through the organizer's official website before entering credentials or approving a device code supplied by an external page.