Fake invitations to OpenAI and SpaceX events led employees to registration pages designed to take over work accounts, security researchers reported Thursday. The pages offered perks such as free access to paid AI subscriptions, then asked visitors to sign in with Microsoft or Google. In one version, the Microsoft sign-in page was genuine. The code visitors were asked to enter came from the attacker.
Push Security’s November 5 report documents pages it began seeing in late October. Researchers also found an earlier lure that impersonated Anthropic. They did not publish a victim count, and their findings describe abuse of familiar brands and sign-in systems. They do not establish a breach of the companies whose names appeared on the invitations.
Why a real Microsoft page can still be part of a scam
Microsoft’s device code flow lets people use a second device to sign in when the first one is awkward to type on, such as a conference room system. A code ties the sign-in you complete in your browser to the device or app that originally requested it. Under ordinary circumstances, you start that process yourself.
In the campaign Push described, the fake event page supplied a code that the attacker had requested. When an employee entered it at Microsoft’s real sign-in page and approved the request, Microsoft issued access tokens to the attacker’s session. The attacker could gain access under the employee’s identity without first learning their password. Push also saw the event page then send users to a second, imitation Microsoft sign-in that could capture a password and session cookie.
The FBI warned in May that the same device code phishing kit, Kali365, had been used to hijack Microsoft 365 access. A genuine Microsoft address tells you who is handling the sign-in. The source of the code tells you who started it.
The Google route used a different trick
When someone chose Google on the fake registration page, Push found that a pop-up passed the interaction through a server controlled by the attackers. It relayed the real Google sign-in while collecting the password, the response to the extra verification step and the session cookie. A session cookie is one of the pieces of data a browser uses to stay signed in. An attacker who obtains it may be able to reuse the signed-in session.
A polished event page, a familiar logo and a link routed through a recognizable service do little to establish that the invitation came from the organizer. If the event sounds plausible, look for it on the organizer’s official site or use a contact you already know. A request to enter a device code you did not generate is a reason to stop, even if the page accepting it is real.
What to report if you entered a code or password
Contact your workplace help desk or security team using your normal internal channel. Tell them which account you used, roughly when it happened and whether you entered a device code, typed a password or approved a prompt. Preserve the invitation for your security team and avoid sending it to colleagues as a warning they might click.
A password reset addresses a stolen password. The security team may also need to revoke active sessions or tokens and check what the account did after the sign-in. Microsoft’s administrator guidance explains how organizations can restrict device code sign-ins to the devices or locations that need them. Google’s guidance for Workspace administrators recommends security keys over verification codes for stronger phishing protection. That advice addresses stolen sign-in credentials. The separate device code risk is why Microsoft also recommends that administrators restrict where that flow can be used.
