ZoomMock and MSDRoot Phishing Kits: Fake AI Event Pages That Chain Kali365 and VoidProxy
ZoomMock and MSDRoot phishing kits fake OpenAI, SpaceX and Anthropic event pages and chain Kali365 device code phishing with VoidProxy, Push Security reports.
AegisAI Threat IntelligenceAegisAI Threat Watch · AiTM and device code phishing
ZoomMock and MSDRoot Phishing Kits: Fake AI Event Pages That Chain Kali365 and VoidProxy
Fake OpenAI and SpaceX event pages chain two rented phishing kits, one for each sign-in button.
- What
- Fake OpenAI and SpaceX event pages offer a free AI reward, then chain Kali365 device code phishing and VoidProxy to take sign-ins.
- Who it hits
- Staff asked to sign in with a work Microsoft or Google account. Push Security blocked visits in late October 2026.
- Why filters miss it
- Real Microsoft pages and a live proxy do the sign-in, behind a bot check that hides the lure from scanners.
- Do today
- Block device code flow in Entra Conditional Access, and add session binding for administrative apps.
ZoomMock and MSDRoot phishing kits fake OpenAI, SpaceX and Anthropic event pages, then chain Kali365 device code phishing with VoidProxy adversary-in-the-middle phishing to steal Microsoft and Google sign-ins.
Threat Watch has covered device code kits before, including MadApe and Wazza, and the AegisAI blog explains how Kali365 defeated MFA. This post adds what those did not have: one lure page that hands each sign-in button to a different rented kit, and a Microsoft path that continues to a proxy page after the device code step. The source is Push Security's analysis of 5 November 2026.
The numbers describe the operator's infrastructure, not victims. Push reports no count of accounts taken over.
Key judgments
- One page, two kits. Push reports that the Microsoft button starts a Kali365 device code request, while the Google button opens a VoidProxy reverse proxy of Google's real sign-in flow.
- The Microsoft path does not end at the device code. After approval the page continues to a VoidProxy page that captures the password and session cookie, so a control aimed only at device code flow covers one branch of two.
- The operator rents rather than builds. Push found nothing linking the Kali365 and VoidProxy developers and thinks the operator is most likely a customer of both.
- The tie between ZoomMock and MSDRoot is rated medium-high by Push alone. The kits share no code; the link rests mainly on one shared primary domain.
- The AI branding is thin. Between 20 and 30 October the operator moved from Zoom to Anthropic to OpenAI, SpaceX and Claude, and a Google proxy hostname on the OpenAI page still names Claude.
- Indicators age fast. Push says the operator rotates domains every few weeks, so the host list below is context for hunting, not a blocklist.
See a lure like this caught: watch the explainer, or book a demo.
A completed device code sign-in is a compromised account, the first issue in the Q3 report. Get the report.
What are the ZoomMock and MSDRoot phishing kits?
ZoomMock and MSDRoot are Push Security's names for two lure kits that build fake event-registration pages. The sign-in step on those pages is handed to a separate rented kit, which is why the page counts as a chain and not a single tool.
ZoomMock: fake Zoom event pages, May to October 2026
Push tracks ZoomMock as the earlier kit. Its pages imitated Zoom event registration, and earlier invitations reached targets through GoTo Webinar's mail sender or genuine events.zoom.us pages. Push lists ZoomMock hosts from May to October 2026, including us968web-zoom[.]us.
MSDRoot: the AI-branded pages from 22 October
MSDRoot is the newer kit. Its first page in Push's data, anthropic.rsvpconnect-events[.]com, appeared on 22 October 2026, and the OpenAI and SpaceX variants followed on subdomains of eventrsvp[.]app. Push rates the Anthropic at AWS re:Invent variant as no longer live when it investigated.
Why Push thinks one operator runs both
Push says the two kits share no code. Its medium-high rating rests mainly on one primary domain: register.rsvpconnect-events[.]com served a ZoomMock page until 20 October, and anthropic.rsvpconnect-events[.]com served the first MSDRoot page on 22 October. The same custom Cloudflare challenge page was on that domain on 12 October and on 29 October, and the proxy hostnames share the words continue, event and offcevent. This is one vendor's inference, and it is the only attribution on record.
How does one fake AI event page chain Kali365 and VoidProxy?
Invitation, bot check, event page
Push splits the chain into four stages. The invitation arrives as a link through Google short links (c.gle and share.google), a Zapier short link (zpr.io) or an x.com logout redirect. A Cloudflare managed challenge, a "not a robot" confirmation, then screens the visitor, which Push says hides the lure pages from scanners. The event page itself copies a real events site: an OpenAI Academy livestream, "ChatGPT for Social & Digital Marketing Teams" on 4 November, with three months of ChatGPT Pro for registrants, or a SpaceX "Starship Product Briefing" on SpaceX AI for marketing and Grok on 12 November, with three months of Grok Heavy or a SpaceX share. Each page asks the visitor to sign in with a work account to claim the reward.
Continue with Microsoft: a device code, then a proxy page
The page requests a device code from Kali365 and shows it in a "Confirm access" dialog. An "Open Microsoft" button opens login.microsoftonline.com/common/oauth2/deviceauth in a pop-up. After the visitor approves it, Microsoft issues tokens to the operator's Kali365 session, the page shows "Signed in as", and the visitor is sent on to a VoidProxy Microsoft sign-in page that captures the password and session cookie. The device code step needs no password. The proxy step that follows does.
Continue with Google: a live proxy of the real sign-in
The Google button opens a VoidProxy reverse proxy of Google's own sign-in flow, served from continue-to-event.claudewebinnar[.]com. Push reports that it captures the password, the MFA response and the session cookie. The visitor sees Google's real pages, relayed in real time.
What does the two-kit chain change for defenders?
Kali365 predates this campaign. The FBI's PSA of 21 May 2026 describes it as an emerging phishing-as-a-service platform, first seen in April 2026 and sold mainly through Telegram, that obtains Microsoft 365 OAuth access and refresh tokens through device code flow without a password or further MFA challenges. VoidProxy is the second kit in the chain. In Push's description it relays Microsoft and Google sign-in through a proxy and captures the password, the MFA response where one is entered, and the session cookie.
The pairing is what Push adds. AegisAI's reading is that an operator who rents both gets two independent ways in behind one invite, so a defence built for one flow leaves the other open. Blocking device code flow addresses the Kali365 branch of this chain and the first half of the Microsoft path. It does nothing to a proxy that relays a real sign-in.
Which tells did the operator leave behind?
The rebranding was fast and incomplete. Push found the Google proxy hostname continue-to-event.claudewebinnar[.]com on the OpenAI-branded page, and an earlier page carried a code comment reading "Same as Claude". A visitor cannot see a code comment, so this is a tell for analysts, not for staff. Page paths follow one pattern, /event/<brand>/id<11 digits>/rsvp/, with /live/ and /join/ variants, and eventrsvp[.]app was three days old on 2 November. Anthropic, OpenAI and SpaceX are lure brands here. Push reports no compromise at any of them.
How can organisations protect Microsoft 365 from device code phishing?
Block the flow where there is no business need
The FBI recommends a Conditional Access policy that blocks device code flow for all users with limited exceptions, after auditing existing use, and blocking authentication transfer. That closes the Kali365 branch.
Then plan for the proxy branch
A block on device code flow does not stop VoidProxy, which relays a real sign-in and takes the session cookie. Controls aimed at that branch are phishing-resistant, device-bound authentication that a relay cannot replay, session binding so a cookie stops working away from the device that earned it, and re-authentication for sensitive administrative actions. This is AegisAI's reading; Push's post describes the capture, not the countermeasure.
One invite, two rented kits. A control that covers one sign-in button leaves the other open.
AegisAI Threat IntelligenceWhy standard controls miss it
Scanners see a challenge page. Push says the Cloudflare managed challenge hides the lure pages from scanners, and Push's own detection works when the pages render in a visitor's browser. Network reputation checks meet short links on Google and Zapier before they reach the operator's domains, which is AegisAI's reading of why the invite looks routine on the way in.
The sign-in screens are real. On the Microsoft path the device code is approved on a genuine Microsoft page, and on the Google path the visitor sees Google's own flow relayed by a proxy. The address a person would check is correct at the step that matters, and the capture happens in the relay.
How AegisAI stops this
Aegis does not classify infrastructure. It classifies intent. A lure with no attacker-owned infrastructure still has to ask the recipient to do something on the attacker's behalf, and that request is what gets classified, independent of how clean the destination URL is.
AegisAI's agents evaluate the message and the destination it points to together, and pull a malicious message out of mailboxes before users see or click it.
When a lure or a compromised session is caught, the response compounds: the message is withheld at classification, copies already delivered are retracted, rewritten links refuse a late visit, the account's outbound and internal mail gets rescanned, and lateral phishing attempts to colleagues are blocked at the same bar rather than treated as a fresh, unrelated message.
How AegisAI stops credential phishing, 48 seconds
Recommendations for defenders
- Block Entra device code flow through Conditional Access for all users and resources: audit current use first, allow only documented cases, exclude emergency access accounts, and run the policy in report-only mode before enforcing it.
- Require phishing-resistant, device-bound authentication where it is available, and apply session binding and re-authentication for sensitive administrative actions, so a relayed session cookie loses value off the original device.
- Review Entra and Google sign-in logs for device code authentication and for sign-ins from unfamiliar addresses, and correlate each hit with a recent event invitation or short link.
- Search DNS and proxy logs for the hosts in the indicators below, and treat them as historical context since the operator rotates domains every few weeks.
- Add the pattern to awareness training and the reporting channel: an event invite that offers a free AI reward for a work sign-in, or asks staff to copy a code onto a Microsoft page, is a report.
FAQ
How do I protect Microsoft 365 from device code phishing?
Block device code flow with an Entra Conditional Access policy unless a documented use needs it, and audit current use first, as the FBI advises. In this campaign that closes only one branch, so also use phishing-resistant authentication and session binding, because VoidProxy relays a real sign-in and steals the session cookie.
What are the ZoomMock and MSDRoot phishing kits?
Names Push Security gave to two kits that build fake event-registration pages: ZoomMock for fake Zoom events from May to October 2026, and MSDRoot for the OpenAI, SpaceX and Anthropic pages seen from 22 October. Push rates the link between them as medium-high and says they hand the sign-in step to Kali365 or VoidProxy.
Does blocking device code flow stop VoidProxy?
No. VoidProxy is an adversary-in-the-middle proxy that relays the real sign-in and captures the password, MFA response and session cookie, with no device code involved. Blocking device code flow addresses the Kali365 branch only, so phishing-resistant authentication and session binding are also needed.
How do I spot a fake AI event invite that asks for a work sign-in?
Be wary of any event page that offers a reward such as free months of an AI service for signing in with a work account, reached through a short link and a bot check. Check the domain, and treat a request to copy a code onto a Microsoft page as a reason to stop and report it.
For researchers
What the reporting does not tell us 4 gaps
Victims. Push says it detected and blocked visits. It gives no count of visitors, sign-ins or accounts taken over.
Attribution. The operator is unnamed. The ZoomMock to MSDRoot link is a medium-high judgment by one vendor, and the idea that the operator rents both Kali365 and VoidProxy is an inference.
Invitation volume. Push describes the link patterns and the earlier GoTo Webinar sender but gives no figure for how many invitations were sent or to whom.
Indicator life. Push dates each host to a range. It does not say which were reused or taken down, and it reports that the operator rotates domains every few weeks.
Indicators published by Push Security campaign and ZoomMock
These come from Push's indicator list. Domains are written with [.] so they cannot be clicked. Infrastructure churns, so treat them as historical context and hunting leads, not a live blocklist. Dates are the ranges Push shows.
| Type | Indicator |
|---|---|
| MSDRoot event pages | openai.eventrsvp[.]app (29 to 31 Oct)spacex.eventrsvp[.]app (30 Oct)anthropic.rsvpconnect-events[.]com (22 Oct to 2 Nov)rsvpconnect-events[.]com (7 Oct to 2 Nov) |
| URL pattern | hxxps://<brand>.eventrsvp[.]app/event/<brand>/id<11 digits>/rsvp/ |
| Google proxy (VoidProxy) | continue-to-event.claudewebinnar[.]com (22 Oct to 2 Nov) |
| Microsoft proxy (VoidProxy) | continue-to-office-.ggleventapi[.]icu (29 to 30 Oct)wbdssologin[.]app (22 to 26 Oct)logins-offcevents[.]icu (21 to 22 Oct)accounts.ggkiejl[.]icu (22 Oct) |
| Kali365 backend | 62zr4vcasl.shifts[.]icu (22 to 30 Oct), path /api/generate?lure=candidate-portal-JhI3 |
| Collection server | 217.60.102[.]48 and eventrsvp-217-60-102-48.sslip[.]io/collect.php (29 to 30 Oct) |
| ZoomMock hosts | us968web-zoom[.]us (17 Sep to 30 Oct)officegocrqb[.]com (29 Jun to 20 Oct)offcevent-login[.]com (16 Sep to 7 Oct)office.com-access-sharepoint[.]com and goo.gle-access-eventregister[.]icu (11 Sep to 1 Nov) |
MITRE ATT&CK mapping 5 techniques
This mapping is AegisAI's own reading of the reported behaviour. Push's report lists no technique IDs.
| ID | Name | Use in this campaign |
|---|---|---|
T1566.002 | Phishing: Spearphishing Link | The invitation is a link through short-link services. |
T1528 | Steal Application Access Token | The Kali365 branch obtains Microsoft tokens through a device authorization request. |
T1557 | Adversary-in-the-Middle | VoidProxy relays the Microsoft and Google sign-in in real time. |
T1539 | Steal Web Session Cookie | Both proxy pages capture the session cookie. |
T1583.001 | Acquire Infrastructure: Domains | The operator rotates domains every few weeks. |
References 4 sources
- Push Security (5 Nov 2026). AI-themed fake event campaign analysis. pushsecurity.com
- FBI Internet Crime Complaint Center (21 May 2026). Public service announcement I-052126-PSA on Kali365. ic3.gov
- IETF (Aug 2019). RFC 8628: OAuth 2.0 Device Authorization Grant. rfc-editor.org
- MITRE ATT&CK. Techniques T1566.002, T1528, T1557, T1539 and T1583.001. attack.mitre.org
Every email, investigated.
See how AegisAI reads the request inside an invite like this one and pulls it from inboxes before anyone clicks.
Attacks like this one, stopped before the inbox.
Book a demoRelated posts
More from the AegisAI blog.