This is a modern lure, not a classic fake login page. It also exploits a legitimate Microsoft sign-in feature, so the usual "check the URL" advice only goes so far.
What Push Security found
Push says it detected and blocked visits to fake event registration pages on customer browsers in late October 2026. The pages advertised three things:
- An OpenAI Academy-style livestream.
- A private SpaceX briefing.
- An Anthropic appearance at AWS re:Invent.
Each page asked visitors to sign in with a work account to claim a reward. The rewards were three months of ChatGPT Pro, three months of Grok Heavy, or a "SpaceX share."
Specific lures:
- OpenAI page: a livestream titled "ChatGPT for Social & Digital Marketing Teams," dated November 4, offering ChatGPT Pro.
- SpaceX page: an invite-only "Starship Product Briefing" on SpaceX AI for marketing and Grok, dated November 12. The visitor picks Grok Heavy or the "SpaceX share."
- Anthropic page: Push says it was no longer live when investigated.
The dates and rewards are claims made by the lures. They don't show that the events or rewards were real.
Two kits, two rented services
Push separates the operator's tooling from the services it rents:
- ZoomMock is the operator's kit for fake Zoom-style event pages. Push says it was used from May to October 2026.
- MSDRoot is the newer kit for the event pages, appearing from October 22.
- Kali365 and VoidProxy are the rented phishing services those pages call.
Push rates the link between the two kits as "medium-high" confidence. The kits share no code. Most of the evidence is that both were served from the same primary domain. Push has seen nothing linking the Kali365 and VoidProxy developers to each other. It thinks the operator is most likely a customer of both.
How the attack chain works
- Invitation. Links pass through trusted services: Google short links (c.gle or share.google) or Zapier's zpr.io. In one followed link, an X logout redirect came first. Push says earlier invitations came through GoTo Webinar's mail sender or real Zoom event pages. BleepingComputer notes that how the current links are first distributed is still unclear.
- Bot check. A Cloudflare managed challenge reading "Confirm you're not a robot" sits in front of the lure. Push says most public scans of these domains stop there.
- Event page. The page demands a work account and offers "Continue with Microsoft" or "Continue with Google." Push says the pages run identical code with different branding and translate themselves into the visitor's language.
- Credential and session capture. This step depends on which button is clicked.
The Microsoft path: device code, then a second grab
Clicking Microsoft makes the page request a device code from Kali365 and show it in a "Confirm access" dialog. The victim is told to copy it and open Microsoft's real device login page. They paste the code, sign in and approve. Microsoft then issues tokens to the attacker's Kali365 session.
The victim never types a password into a fake page at that point. The sign-in happens on a genuine Microsoft domain.
The lure then shows a "Signed in as …, opening Microsoft 365" message. It redirects the victim to a VoidProxy Microsoft sign-in page that captures the password and session cookie. That gives the operator a second capture.
The Google path: a reverse proxy
Clicking Google opens a pop-up titled "Portal." It is a VoidProxy reverse proxy that relays Google's real sign-in flow. Push says it captures the password, the MFA response and the session cookie. The victim sees the real flow, so the MFA prompt works as normal. The attacker keeps the authenticated session.
Why this slips past defenses
Push's argument is that every layer is built to dodge common controls:
- A Cloudflare challenge hides the page from scanners.
- The VoidProxy Microsoft proxies show scanners real business news sites.
- Delivery goes through trusted short-link and redirect services.
- Domains rotate quickly. Push says the eventrsvp[.]app domain was only three days old when it investigated on November 2, and the operator moved through several brands between October 20 and 30.
Push sells browser-based detection, so it has a commercial interest in the "legacy defenses fail" framing. Still, the technical flow it describes matches how device-code and AiTM phishing are known to work. The brand-rotation details also look like normal operator sloppiness. For example, the OpenAI page references Claude-named infrastructure, and an earlier page carried a "Same as Claude" code comment.
Earlier reporting
The campaign follows related activity. ANY.RUN reported on July 15 that real Zoom event pages carried "partner summit" lures for Meta, OpenAI and Anthropic. The flows branched into device-code and AiTM phishing. Cofense reported on October 29 on Anthropic-themed invitations that came through GoTo Webinar's mail sender. Those led through zpr.io and a Cloudflare check to a Zoom-style page.
What admins should do
Microsoft's documentation says device code flow is meant for devices without local input, such as shared devices or digital signage. It also calls the flow high-risk and says it can be part of a phishing attack. Microsoft recommends blocking it wherever possible. Microsoft says device code flow is rarely used by customers but frequently used by attackers.
Block device code flow in Conditional Access
Microsoft's documented procedure:
- Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
- Go to Entra ID > Conditional Access > Policies and select New policy.
- Under Include, choose the users in scope. Microsoft recommends all users.
- Under the Authentication flows condition, select Device code flow.
- Under Access controls > Grant, select Block access.
- Set the policy to Report-only first, then create it. Enable it once you have reviewed the impact.
Microsoft suggests auditing existing device code use first, and allowing it only in well-documented, secured cases such as legacy tooling that can't be updated.
Check before you enforce
- Inventory usage. Filter Entra sign-in logs with the Authentication protocol filter set to Device code flow. Report-only mode helps here too.
- Device Registration Service. Microsoft says policies targeting all resources are enforced against the Device Registration Service. If you use device code flow for device registration, exclude that resource, under Target Resources > Exclude.
- Teams devices. Microsoft's guidance for Teams devices that need device code flow is to scope the exception to specific resource accounts and exclude the Device Registration Service.
- Unexpected blocks. Protocol tracking means a session that began with device code flow can stay subject to the policy after refreshes. Check the "Original transfer method" property in the sign-in log's Conditional Access details. Error AADSTS530036 indicates refresh-token checks by authentication flow policies.
- Managed policy. Microsoft lists a managed "Block device code flow" Conditional Access policy. Check whether it exists and is enabled in your tenant.
- Default for new tenants. Microsoft says tenants created from July 1, 2026 block device code flow through Security Defaults. That date-specific default doesn't tell you what an older tenant is doing.
Beyond device code
- Use phishing-resistant MFA, such as FIDO2 security keys. Both Push and BleepingComputer recommend it against session hijacking. Because the credential is bound to the genuine site, a reverse proxy has a much harder time relaying it.
- Hunt back through logs for the campaign's indicators. Push stresses that they rotate every few weeks, so they are most useful for finding earlier visits. Examples include eventrsvp[.]app, rsvpconnect-events[.]com, claudewebinnar[.]com and the collection IP 217.60.102[.]48.
- Treat Kali365 and VoidProxy hosts as "used by this campaign," not "owned by this operator." Push warns they may serve other customers.
- If a user entered a device code or signed in on one of these pages, assume tokens and session cookies are stolen. Revoking sessions and reviewing sign-in logs is a reasonable response. This is general incident-response practice, not a procedure from the sources.
What users should be told
- Never enter a Microsoft device code that a website, event page or invitation gave you.
- Be suspicious of any event that requires a corporate sign-in to claim a free subscription, upgrade or other reward.
- Short links and a visible Cloudflare check don't prove a page is legitimate.
The bigger picture
The AI-brand lure is the story's hook, but the lasting lesson is about identity. The Microsoft path ends at a real Microsoft sign-in page. The Google path relays Google's real flow. Defenders can't rely on spotting a bad domain at the moment of login. The controls that work are ones that remove the attack path. Those are blocking device code flow where it isn't needed and using phishing-resistant credentials.
Push notes that employees want access to the latest AI tools, which makes AI-branded events good bait. Expect the brands to keep rotating. The mechanics will stay the same.