Push says fake OpenAI, SpaceX and Anthropic event pages phish work logins by device code and by proxy
Push Security says fake event pages for OpenAI and SpaceX, plus an Anthropic one no longer live, ask for a work login to claim a reward and hand it to two rented phishing services. How many people were caught is not stated. Read 7 November 2026.
By Parminder Kumar Sharma · LinkedIn · · 18 min read
Ten days of lure changes, and a domain three days old
Push Security says that between 20 and 30 October 2026 the operator behind a run of fake event pages moved from Zoom lures to Anthropic, OpenAI, SpaceX and Claude lures. That is a span of 10 days (derived: 20 to 30 October). One lure domain, eventrsvp[.]app, was "three days old on November 2" when Push investigated it, which puts its creation at about 30 October (derived). The pace is Push's argument: a detection list built from known bad domains cannot keep up with an operator that changes its lure within days and keeps adding domains. This briefing rests on Push's post of 5 November 2026, saved at about 18:14 UTC on 7 November and read in full by this site at about 18:23 UTC on Saturday 7 November 2026. It also uses Cofense's report of 29 October, read in full, Microsoft's own pages on the device code flow, and BleepingComputer's coverage of 5 November as a secondary pointer.
Two more derived figures. The two events the pages advertise are 8 days apart: the OpenAI Academy livestream is dated 4 November and the SpaceX briefing 12 November. The livestream date was 1 day before Push published, and the briefing date was still 7 days away on the day of publication, so the SpaceX page advertised an event still in the future when the post went up. Push saw that page on 30 October, 13 days before the date it names.
What those figures do not establish. Push gives the dates on which it saw pages, not the dates on which anyone was targeted. It does not say who runs the operation or where. It does not say how the invitation links reach people in this wave. It does not say how many employees entered credentials, which organisations they work for or whether any account was used afterwards: it says only that it "detected and blocked visits to fake event registration pages on customer browsers". Push sells a browser security product, and the post describes it, so its detection claims are its own. OpenAI, SpaceX and Anthropic are the brands being impersonated, not parties at fault, and none of the three sources this site read reports a statement from any of them.
What the pages offer, and why it has to be a work account
Push describes pages that advertise an OpenAI Academy livestream, a private SpaceX briefing on "SpaceX AI for Marketing" and Anthropic at AWS re:Invent. "Each page asks the visitor to sign in with a work account to claim a reward". The rewards differ by brand, and the Anthropic variant is the odd one out.
The lure pages Push describes in its post of 5 November 2026, read 7 November 2026. The Anthropic variant was "no longer live at the time we investigated".
| Brand used | Event the page advertises | Reward on offer |
|---|---|---|
| OpenAI | A livestream on 4 November, "ChatGPT for Social & Digital Marketing Teams", on a page that "copies the look of the OpenAI Academy events site" | 3 months of ChatGPT Pro |
| SpaceX | An invite only "Starship Product Briefing" on SpaceX AI for marketing and Grok, on 12 November | 3 months of Grok Heavy, or a "SpaceX share" |
| Anthropic | "Anthropic at AWS re:Invent"; a third variant, no longer live when Push looked | Not stated |
Why a work account? Push's own line is that "Employees want access to the latest AI tools, making them excellent bait for attacks", and that both kits "target marketing staff with AI-brand events". Push's screenshot of the SpaceX page shows the filter at work: it says a work or business email is required and that personal accounts are not eligible for the invitee reward. A personal mailbox is worth little to an operator who wants a company's mail, files and the apps behind its sign in (this site's reading). Push also says the pages "translate themselves into the visitor's language" and "run the same code".
The friendly names start here. "Register to attend", "invitee reward" and "Work account required" read like admission paperwork. They are the instructions of a sign in harvest, and the one rule they state, work accounts only, is the operator's targeting rule written as a courtesy to the visitor.
The path of one click
Push lays the chain out in four stages and says the operator controls the first three. The invitation link "goes through a Google short link (c.gle or share.google) or Zapier's zpr.io". "Earlier invitations came from GoTo Webinar's mail sender or from real events.zoom.us event pages". In the link Push followed, an x.com logout redirect came before the Google short link. Push's comment is general: "Short links and open redirects on trusted domains are common techniques for evading reputation-based URL checks". That describes how trusted names launder a link. It does not say that any of those services was compromised.
Step 2 is the bot check. "A Cloudflare managed challenge protects the lure domain", with a custom page that says "Confirm you're not a robot". Push adds: "Most public scans of the lure domains stop at this page". That is the second friendly label. A bot check is a sign that the operator wants to be seen only by people. Cofense, describing the earlier wave, makes the same point from the victim's side: because CAPTCHAs are common on legitimate sites, a recipient may think all is well.
How the link first reaches a victim is where the sources disagree in tone. Push's introduction says the campaign uses these lures "in email-delivered invitations". BleepingComputer, a secondary source, writes: "While it is unclear how the attackers initially distribute the phishing links". The post prints no email for this wave, and its detections came from blocked visits in customers' browsers, so what reached the browser before the short link is not shown. The only email the sources describe is Cofense's, from the earlier Zoom themed wave, and that is a different set of pages.
Two payloads, and what each hands the operator
The page has two buttons, and each one starts a different attack. Push describes them as separate rented services: "Kali365 and VoidProxy are separate phishing-as-a-service (PhaaS) platforms, both designed to bypass or defeat MFA checks". The pages themselves are the operator's work. Kali365 and VoidProxy are "the rented services they call".
The device code payload. Microsoft documents the device authorisation grant for devices with no keyboard: it "allows users to sign in to input-constrained devices such as a smart TV, IoT device, or a printer", and the code expires, by default, because "the user has 15 minutes to sign in". In the attack the operator plays the part of the television. The page asks Kali365 for a code and shows it; the victim types it into Microsoft's real login page and approves; and "Microsoft then issues tokens to the operator's Kali365 session". The domain in the pop-up is Microsoft's. There is no lookalike password page in this step to spot.
The proxy payload. For the Google button, the pop-up is a VoidProxy reverse proxy. Push says it "relays Google's real sign-in flow and captures the password, the MFA response, and the session cookie". The victim sees Google's actual page, relayed through an attacker domain. The Microsoft button adds the same proxy as a second stage: after the code, the page "hands the visitor to a VoidProxy Microsoft sign-in page, so the operator gets a second capture".
What each defeats, as Push states it. Only the sentence above: both services are "designed to bypass or defeat MFA checks". Push names no MFA method, whether a code from an app, a push prompt or a security key, and describes no test of any. BleepingComputer, a secondary source, goes further, writing that device code authentication bypasses MFA "entirely" and that phishing resistant MFA "such as FIDO2 security keys" helps against session hijacking. Those are its words, not Push's.
Two readings follow from Push's chain, and both are this site's inference. First, the two buttons need different controls. Microsoft's guidance for device code is a policy block, which does nothing for the Google branch, because that branch never uses a device code. Second, the Microsoft branch has a fallback: if the code step fails, the page still sends the victim to the VoidProxy Microsoft page. Closing one stage may not close the path.
Friendly labels doing the work of a control
A label on a page is not a control, and these pages are built from labels. "Confirm access" is the title of the box that holds the operator's device code. "One-time access code" is that same code, which Push's screenshot shows next to a button reading Open Microsoft and four numbered steps that end with the page unlocking automatically once the victim returns. "Portal" is the title of the window that proxies Google. "Continue with Microsoft" starts a token grant to someone else's session. And the real Microsoft domain in the pop-up, the thing a trained employee is told to check, is exactly where the victim is sent. The check passes, and the attack proceeds.
One more oddity the post records. The OpenAI page "sloppily contains URLs that mention Claude", and an earlier page had a code comment reading "Same as Claude". Push reads that as the operator building each new lure from a copy of the last one without fully rebranding it. It is a detail of the operator's workflow and does not involve Anthropic.
What Push states, and what it does not
Push Security's post of 5 November 2026, read 7 November 2026, with BleepingComputer and Cofense where marked. Quotations are Push's unless marked.
| Point | Stated | Not stated |
|---|---|---|
| Who runs it | "We think this operator is most likely a customer of both" services | Identity, location, motive, any link to a named group |
| The two services | "We haven't seen anything that links the Kali365 and VoidProxy developers" | Whether any link exists; Push says only that it has not seen one |
| Delivery | Invitation links via Google short links or zpr.io; earlier GoTo Webinar's mail sender or real Zoom event pages; "email-delivered invitations" | How a link first reaches a victim in this wave; BleepingComputer calls it unclear |
| Impact | Push "detected and blocked visits" on customer browsers | Number of visits, people who entered credentials, accounts taken or used, organisations |
| MFA | Both services "designed to bypass or defeat MFA checks" | Which methods fail, any test, any account that held up |
| Kit link | ZoomMock and MSDRoot rated "medium-high"; "The two kits share no code" | Anything beyond one shared domain |
| Anthropic page | A variant "no longer live at the time we investigated" | When it was live; Push's own table lists the page host as seen 22 October to 2 November |
| Detection | Its product "identifies the Kali365 device code page and the VoidProxy reverse proxy when they render" | Any detection rate, false positive rate, count of blocks or independent test |
| The brands | OpenAI, SpaceX and Anthropic are impersonated | Any statement from any of the three, in any source read |
Two details inside Push's own post are worth holding against each other. Push says the eventrsvp domain was three days old on 2 November, which derives to about 30 October, yet its indicator table lists the domain as seen from 29 October, a gap of 1 day. Dates in a table of sightings are not creation dates, so the most that can be said is that the age and the first sighting are about a day apart. And the Anthropic page host is listed as seen until 2 November while the text says that variant was no longer live when Push looked on that day. "Seen" is not "live", and the table does not say what kind of sighting it counts.
How firm is the link between the two kits
Push names two kits, ZoomMock for the Zoom themed pages of May to October and MSDRoot for the event pages from 22 October, and says they are one operator's work. Its confidence is stated: "We rate the link between ZoomMock and MSDRoot as medium-high". The basis is thin on purpose: "The two kits share no code" and "Most of the evidence comes from one domain that both kits used". On that domain, Push says a ZoomMock page was served "until October 20" and the first MSDRoot page, for Anthropic at AWS re:Invent, appeared on 22 October, 2 days later (derived). The same custom Cloudflare challenge page was on the domain on 12 and 29 October, 17 days apart (derived).
Add two softer ties from Push: the proxy domains for both kits use the names "continue…event" and "offcevent", and both kits target marketing staff. None is proof of common control, and Push does not say it is. The conclusion that matters for a defender is narrower than the attribution: whoever it is, the same pairing of a device code step and a relay proxy has been wrapped in different brand costumes, and Push says "The operator likely runs more lures than the ones we've seen".
Push also cites two earlier reports. It says ANY.RUN reported on 15 July that real events.zoom.us pages carried partner summit lures for Meta, OpenAI and Anthropic, with flows that "branched into device code phishing and AiTM phishing". Push links that report through a post on X, which needs a login, so this site did not read it and relays it only as Push describes it. Push does not say the July actor is the same operator. This site's earlier briefing on ANY.RUN's SkyW4lker kit covers a different device code kit and its sandbox counts; neither source says whether that kit is related to Kali365.
What Cofense saw a week earlier
Cofense's post of 29 October 2026 describes an earlier or parallel strand of the same theme. It says that "Since September 2026" emails have invited people to a private Anthropic AI meeting, appearing to come from GoTo Webinar's sender address, with a link shortened by zpr[.]io, followed by a Cloudflare CAPTCHA, a Zoom styled meeting page on us968web-zoom[.]us and then a second, custom slider CAPTCHA before the Google or Microsoft page. That domain appears in Push's ZoomMock list. Cofense says the sender name on the email had the first letter of Anthropic missing, which it calls a useful warning sign; this briefing does not repeat the name.
The two vendors describe the pages differently, and neither explains why. Cofense says the Google page "only captures usernames" and is "likely" misconfigured because it does not ask for a password, while the Microsoft page captures a username and password. Push lists several of the same hostnames, including goo.gle-access-eventregister[.]icu, as sign-in proxies. The observations come from different dates and different paths, and a page can behave differently for a scanner than for a visitor, but that is an inference. Cofense also sells a product, Cofense Vision, and lists it among its mitigations.
What to do, in order
Push's own advice is about its product: it says its detection "identifies the Kali365 device code page and the VoidProxy reverse proxy when they render" and that it can also "show a warning or block on any legitimate device code login page as a second layer of defense". That is a vendor claim about a vendor product. The steps below are ranked by how much they change the outcome for a reader with no particular product. Each says whose advice it is.
Take this with you
Ranked actions
- Never approve or type a device code that came from a web page, an invitation or a rewards offer. Enter a code on Microsoft's device login page only when you started that sign in yourself on a device that is showing the code. This is this site's suggestion, tied to Push's description of the Confirm access box.
- If you do not use the device code flow, block it with a Conditional Access policy, starting in report only mode and auditing existing use first. Microsoft's page says: "We recommend organizations get as close as possible to a unilateral block on device code flow." This does nothing for the Google button, which uses a proxy.
- Move the accounts that can be phished towards phishing resistant sign in, such as passkeys or FIDO2 security keys, which is this site's general suggestion for relay proxies. BleepingComputer says the same of FIDO2 keys. Push tests no method, so treat it as a design argument and not a measured result.
- If anyone entered credentials or approved a code on such a page, revoke their sessions and tokens as well as resetting the password. Push says the operator takes tokens or a session cookie, and none of the sources read says a password change alone cancels them. This is this site's suggestion; your identity provider's documentation says how.
- Hunt back through proxy, DNS and mail logs for the hosts in Push's list in the Technical details section. Push says the operator "rotates domains every few weeks" and that the service hosts "may serve other customers", so read a hit as used by this campaign and not owned by this operator, and read a miss as telling you little.
- Treat any invitation that offers a reward for signing in with a work account as a lure, whatever the brand. Push says both kits target marketing staff, so brief marketing and events teams first. Go to the organiser's own site by typing its address, not by following the invitation. This is this site's suggestion.
Technical details
Push prints page shapes, hostnames, one IP address and a collection path, and no file hashes, no email headers and no detection rules, so none are shown here. Everything in the first three blocks is Push's, copied as printed and defanged as Push defanged it. Two cautions come from Push itself: "The operator rotates domains every few weeks", so these have limited value on their own and are most useful for hunting back through logs for earlier visits; and "Kali365 and VoidProxy hosts may serve other customers of those services", so read them as "used by this campaign", not as "owned by this operator". Push gives each indicator a role and a date range in 2026; this site wrote the ranges with "to" in place of Push's dash and laid the table out as lines.
Page shapes, paths and strings. What an analyst can match in proxy logs, and what to expect on screen. The Microsoft address is the genuine device login page, which is why an address check alone does not help. The x.com address is a genuine redirect on a trusted domain that was abused in one chain Push followed.
Lure URL pattern, as Push prints it
hxxps://<brand>.eventrsvp[.]app/event/<brand>/id<11 digits>/rsvp/ (also /live/ and /join/)
Collection server path, as Push prints it
hxxps://eventrsvp-217-60-102-48.sslip[.]io/collect.php
Kali365 backend, as Push prints it
62zr4vcasl.shifts[.]icu (/api/generate?lure=candidate-portal-JhI3)
The real Microsoft device login page that the Open Microsoft button opens, as Push prints it
login.microsoftonline.com/common/oauth2/deviceauth
Redirect that came before the Google short link in the chain Push followed, as Push prints it
x.com/logout?redirect_after_logout=
Page text Push quotes
Confirm you're not a robot (custom Cloudflare challenge page)
Confirm access (dialog that shows the device code)
Open Microsoft (button that opens the real device login page in a pop-up)
Signed in as ..., opening Microsoft 365 (after the code is approved)
Portal (title of the Google proxy pop-up)
Continue with Microsoft / Continue with Google (the two buttons)
Indicators for this campaign. 14 rows in Push's table for the October to November activity (derived count). Search web proxy, DNS and mail logs for them; a hit shows a visit, not a sign in.
eventrsvp[.]app
role: Lure domain
seen (2026): Oct 29 to Nov 2
openai.eventrsvp[.]app
role: OpenAI Academy event page
seen (2026): Oct 29 to 31
spacex.eventrsvp[.]app
role: SpaceX event page
seen (2026): Oct 30
hxxps://<brand>.eventrsvp[.]app/event/<brand>/id<11 digits>/rsvp/ (also /live/ and /join/)
role: Lure URL pattern
seen (2026): Oct 29 to 30
rsvpconnect-events[.]com
role: Lure domain
seen (2026): Oct 7 to Nov 2
anthropic.rsvpconnect-events[.]com
role: Anthropic event page
seen (2026): Oct 22 to Nov 2
hxxps://eventrsvp-217-60-102-48.sslip[.]io/collect.php
role: Collection server
seen (2026): Oct 29 to 30
217.60.102[.]48
role: Collection server IP
seen (2026): Oct 29 to 30
62zr4vcasl.shifts[.]icu (/api/generate?lure=candidate-portal-JhI3)
role: Kali365 backend
seen (2026): Oct 22 to 30
claudewebinnar[.]com and all its subdomains, including continue-to-event.claudewebinnar[.]com
role: VoidProxy Google sign-in proxy
seen (2026): Oct 22 to Nov 2
logins-offcevents[.]icu, accounts.logins-offcevents[.]icu
role: Redirect after sign-in
seen (2026): Oct 21 to 22
accounts.ggkiejl[.]icu
role: Google sign-in proxy
seen (2026): Oct 22
continue-to-office-.ggleventapi[.]icu
role: Microsoft sign-in proxy
seen (2026): Oct 29 to 30
wbdssologin[.]app, login.wbdssologin[.]app
role: Microsoft sign-in proxy
seen (2026): Oct 22 to 26
Indicators for ZoomMock, May to October 2026. 10 rows (derived count). These are the older Zoom themed pages and the proxies and Kali365 backends the same operator used, as Push attributes them.
us956web-zoom[.]us
role: Fake Zoom event pages
seen (2026): May
us968web-zoom[.]us, event.us968web-zoom[.]us
role: Fake Zoom event pages
seen (2026): Sep 17 to Oct 30
register.rsvpconnect-events[.]com
role: Fake Zoom event page
seen (2026): Oct 7 to 20
zoomconnect.ssomeetingportal[.]com, connect.ssoeventportal[.]com
role: Fake Zoom event pages
seen (2026): Jul 6 to Aug 7
officegocrqb[.]com, nextconfirmationlogin.officegocrqb[.]com, continueevenregistration.officegocrqb[.]com, continuessoevent.officegocrqb[.]com
role: Microsoft sign-in proxy
seen (2026): Jun 29 to Oct 20
offcevent-login[.]com, signincomplete.offcevent-login[.]com
role: Microsoft sign-in proxy
seen (2026): Sep 16 to Oct 7
office.com-access-sharepoint[.]com, financeline.com-access-sharepoint[.]com, goo.gle-access-eventregister[.]icu
role: Microsoft and Google sign-in proxies
seen (2026): Sep 11 to Nov 1
workportalsso[.]com, zoomconnect.workportalsso[.]com, application.workportalsso[.]com, accounts.careersggl[.]icu
role: Fake Zoom event page and Google sign-in proxy
seen (2026): Jun 23 to Jul 9
accounts.gfmzrsj[.]icu, accounts-auth.ggolshhk[.]icu
role: Google sign-in proxies
seen (2026): Oct 6 to 20
ydgjgdbhoa.shifts[.]icu, rnacj.iceagelandforms[.]surf, clqzwd4jqw.emptytownmoon[.]de
role: Kali365 backends
seen (2026): Oct 7 to 20
The block Microsoft documents. This is the defender's setting, from Microsoft's page on blocking authentication flows. Start in report only mode, as the page says, before turning the policy on, and exclude emergency access accounts as the page advises.
We recommend organizations get as close as possible to a unilateral block on device code flow. Consider creating a policy to audit the existing use of device code flow and determine if it's still necessary.
Under Conditions > Authentication Flows, set Configure to Yes.
Select Device code flow.
Under Access controls > Grant, select Block access.
Confirm your settings and set Enable policy to Report-only.
After confirming your settings using policy impact or report-only mode, move the Enable policy toggle from Report-only to On.
A hunting expression derived from Push's pattern. This is this site's, not Push's, and it only finds pages of this campaign's shape. It was written from the printed URL pattern and the page endings visible in Push's screenshots.
Derived by this site from Push's printed pattern and screenshots. Push does not publish this expression.
Match in web proxy or DNS logs, case insensitive:
[a-z]+\.eventrsvp\.app/event/[a-z]+/id[0-9]+/(rsvp|live|join|register)/
Push prints the endings rsvp, live and join. Its screenshots of the SpaceX page show a page whose address ends in register, so that ending is
added here. A hit means a visit to a page of this shape, which Push ties to this campaign; it does not show that anyone signed in.
The question Push's post leaves open
This operator rebuilt its lure around five themes in ten days and changed the lure theme within days, which Push says outpaces detections built on known bad domains. What stayed fixed is the ask: a work login for a prize, and two ways to take it that do not need a convincing fake password page. So when an employee decides, rightly or wrongly, that a page is genuine and approves a code or signs in, what in your tenant is still standing between that decision and the operator's tokens?
Key facts
Sources
- PrimaryAnalyzing a fake event campaign combining AiTM and device code phishing payloads, post of 5 November 2026 (modified 16:36 UTC the same day): the lure pages, the Kali365 and VoidProxy payloads, the ZoomMock and MSDRoot kits, the indicators and Push's product claims. Read in fullPush Securityaccessed 2026-11-07
- PrimaryWould Your Employees Join a Fake Anthropic AI Preview, post of 29 October 2026: the earlier Zoom themed wave through GoTo Webinar and zpr.io, the two CAPTCHAs and the credential pages. Read in fullCofenseaccessed 2026-11-07
- PrimaryBlock authentication flows with Conditional Access policy: Microsoft's recommendation to block device code flow and the policy settings. Read in fullMicrosoftaccessed 2026-11-07
- PrimaryMicrosoft identity platform and the OAuth 2.0 device authorization grant flow: what the flow is for and the 15 minute default expiry. Read in fullMicrosoftaccessed 2026-11-07
- Reported byFake OpenAI, SpaceX events used to steal Microsoft, Google accounts, coverage of 5 November 2026: used only as a pointer, for its statement that distribution is unclear and for its own mitigation adviceBleepingComputeraccessed 2026-11-07
