Fake OpenAI and SpaceX Event Invites (November 2026): How Device Code Phishing Works and How to Block It

A phishing campaign documented on 5 November 2026 uses fake event registration pages for OpenAI Academy, a SpaceX product briefing and an Anthropic session at AWS re:Invent to take over Microsoft and Google work accounts. Visitors are promised a reward (three months of ChatGPT Pro, Grok Heavy, or a "SpaceX share") if they sign in with a work account. On the Microsoft side, the trick is device code phishing: you type a short code into Microsoft's real sign-in page, approve your real MFA prompt, and the attacker's session gets your tokens. If your company runs on Microsoft 365, block the device code flow in Conditional Access this week. If you are on Google Workspace, move your team to passkeys or security keys. Both changes take an afternoon.

I'm Kunal Vohra, a fractional CTO and a security researcher and cybersecurity advisor. Most of what I've written this month has been about patching servers. This one is about the accounts above the servers: the email, documents and single sign-on every startup depends on. Device code phishing is not new, but this autumn it has gone from a nation-state technique to something sold as a service, aimed squarely at the people who run startups.

Who should care

• Any company on Microsoft 365 or Entra ID. Device code phishing works against the default configuration. If nobody has turned the device code flow off, it is on.
• Teams on Google Workspace. The same campaign uses a proxy that sits between you and Google's real sign-in page and steals your password, MFA response and session cookie.
• Founders, marketing and sales teams. The OpenAI lure was billed as a session on ChatGPT for social and digital marketing teams. These are people who sign up for webinars weekly and are rarely the target of security training.
• Anyone using single sign-on. A work account is the key to everything connected to it; BleepingComputer lists apps such as Salesforce, Dropbox, Slack, Zendesk and Atlassian.

What actually happened

On 5 November 2026, Push Security published an analysis of a campaign using fake AI-themed event pages, and BleepingComputer covered it the same day. The details that matter:

• The lures. An OpenAI Academy livestream dated 4 November ("ChatGPT for Social & Digital Marketing Teams"), a SpaceX "Starship Product Briefing" about SpaceX AI for marketing and Grok dated 12 November, and an Anthropic page themed on AWS re:Invent, which was already offline when researchers looked at it. Each page asks you to sign in with a work account to register and claim a reward.
• Two paths, two rented kits. "Continue with Microsoft" requests a device code from Kali365, a phishing-as-a-service platform, and shows it in a "Confirm access" dialog. The victim is then sent to Microsoft's real device login page to enter it, after which a second page from VoidProxy, another rented platform, tries to capture the password and session cookie too. "Continue with Google" opens a VoidProxy reverse proxy of Google's sign-in page that captures the password, the MFA response and the session cookie.
• Delivery that looks clean. Links went through Google's own short-link domains and Zapier's link shortener, and earlier versions used GoTo Webinar senders or real Zoom event pages. A Cloudflare "confirm you're not a robot" check in front of the pages also keeps security scanners out.
• The operator. No threat actor is named. Push links this campaign to an earlier kit it calls ZoomMock (May to October 2026) and a newer one it calls MSDRoot (from 22 October), with medium-high confidence, and says the operator is most likely a customer of both rented platforms rather than their developer. BleepingComputer's framing is a little stronger; I'm going with Push's wording because it is the original research. Domains rotate every few weeks, so blocklists age fast.

No source gives victim or organisation counts for this campaign. Push says it detected and blocked visits in late October.

It is not one campaign, it is a season

The event lures are the most clickable version of a wider trend:

• SkyW4lker. A Microsoft 365 device code kit first seen on 23 June 2026, documented by ANY.RUN on 27 October and covered by Cyber Security News on 4 November. It uses invoices, contracts, payment notices and password-protected documents as lures, with redirects through Google Sites, Miro, Zoom and Smartsheet. ANY.RUN counted 618 sandbox analyses between June and 21 October, rising from 20 in June to 200 in September, with roughly 46 percent of submissions from the US and India second.
• MadApe. A Microsoft device code kit using business-themed PDF lures and fake document-sharing pages, first observed by Group-IB on 7 January 2026, in The Hacker News weekly recap of 2 November.
• GeorgeGinx and Mir0Auth. Two more device code operations in ANY.RUN research published on The Hacker News on 5 November: one abusing Adobe shared links, the other fake DocuSign pages.
• Storm-2372. Microsoft's February 2025 device code case (fake Teams invites), which a July 2026 update ties to Midnight Blizzard.

When a state-linked cluster and anyone with a subscription use the same trick, it is no longer exotic. It is the default phishing technique of 2026.

How device code phishing works

The device code flow exists for devices that cannot show a full sign-in page, like a smart TV or a command-line tool. The device gets a short code from Microsoft, you type it into a Microsoft page on your phone or laptop and sign in with MFA, and Microsoft hands tokens to the device that asked.

In the attack, the "device" is the attacker's server:

1. You click "Continue with Microsoft" on the fake event page.
2. The attacker's backend asks Microsoft for a device code, using a legitimate Microsoft client.
3. The page shows you that code and sends you to Microsoft's real device login page.
4. You type the code, sign in with your password, and approve your MFA prompt. Every page you see is genuinely Microsoft's.
5. Microsoft issues access and refresh tokens to the attacker's session. The attacker now has your mailbox, files and any app your account can reach, without ever seeing your password.

In device code phishing, the URL is real, the MFA prompt is real, and the only fake thing is who asked for the code. That is why "check the address bar" and "MFA protects you" both fail here, and why the fix has to be a configuration change, not just training.

Microsoft's own documentation calls device code flow "a high-risk authentication method" and says it recommends blocking it wherever possible.

What to change in your stack this week

1. Microsoft 365: block device code flow with Conditional Access

This is the single highest-value change. You need the Conditional Access Administrator role, and Conditional Access requires Entra ID P1 licences (included in Microsoft 365 Business Premium and E3/E5). In the Microsoft Entra admin center:

1. Go to Entra ID > Conditional Access > Policies > New policy.
2. Under Users or workload identities, include All users and exclude your break-glass (emergency access) accounts.
3. Under Target resources, include All resources.
4. Under Conditions > Authentication flows, set Configure to Yes and select Device code flow.
5. Under Grant, choose Block access.
6. Set Enable policy to Report-only, create it, and check the results before switching it to On.

Before you switch it on, find out who really uses device code flow: in Sign-in logs, filter by Authentication protocol and choose Device code. It is usually a few engineers with command-line tools or a meeting room device. Microsoft's guidance is to get "as close as possible to a unilateral block", so exclude a named group rather than leaving it open for everyone. If someone hits the block, the error code they'll report is AADSTS530036.

The same condition has an Authentication transfer option, which covers moving a signed-in session from desktop Outlook to a phone by scanning a QR code. Decide whether you need it; if not, block that too.

One detail that trips people up: since September 2024 an all-resources authentication flows policy also applies to the Device Registration Service, and Microsoft documents how to exclude it if a legitimate setup breaks.

2. Move to phishing-resistant sign-in

Passkeys and FIDO2 security keys are bound to the real website, so a proxy page cannot replay them. That is what defeats the Google half of this campaign and AiTM phishing generally.

• Microsoft: enable passkeys (FIDO2 keys or passkeys in Microsoft Authenticator) and require them for admins first, then everyone. Microsoft's Storm-2372 guidance lists phishing-resistant MFA and blocking legacy authentication next to blocking device code flow.
• Google Workspace: in the Admin console, go to Security > Authentication > 2-step verification (super admin required). Google's documentation says its security key method now supports both security keys and passkeys. Enforce it for admins and finance first, then the whole company.

A passkey does not stop someone typing a device code into a real Microsoft page, which is why step 1 comes first. You need both.

3. Bind tokens to devices where you can

Microsoft's token protection session control only accepts tokens bound to a registered device, which makes stolen tokens much harder to replay. It covers Exchange Online, SharePoint Online and Teams in the native apps on Windows, macOS and iOS/iPadOS. Pilot it in report-only mode first, starting with founders and finance.

4. Look for it in your logs

• Filter Entra sign-in logs by Authentication protocol: Device code for the last 90 days. A device code sign-in from someone who never uses a command line deserves a phone call.
• In a sign-in's activity details, the Original transfer method field shows Device code flow when a session started that way.
• If you have Microsoft Defender, Microsoft suggests hunting for clicks to microsoft.com/devicelogin and login.microsoftonline.com/common/oauth2/deviceauth.

5. Teach one rule, not a course

The one sentence I'd give every employee: never type a code into a Microsoft or Google page because a website told you to. You only enter a device code when you started the sign-in yourself, on a screen or terminal in front of you. And for this season: an event that needs your work account to "claim" a free subscription is phishing until proven otherwise.

If someone already entered a code

Treat it as an account takeover, not a "suspicious email" ticket. Changing the password alone does not kill the attacker's tokens.

In the Entra admin center, open the user, clear Account enabled, and on the user's overview page select Revoke sessions. With Microsoft Graph PowerShell, the same steps look like this:

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -UserId "person@yourcompany.com"
Update-MgUser -UserId $User.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $User.Id
Get-MgUserRegisteredDevice -UserId $User.Id -All | ForEach-Object {
  Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false
}

Revoking sessions stops new tokens, but access tokens already issued last until they expire (an hour by default), and apps with their own sessions are not revoked by Entra directly. Then, before re-enabling the account:

• Reset the password and re-register MFA methods; remove any MFA method or device you don't recognise.
• Check mailbox rules and forwarding (attackers love a rule that hides replies).
• Review OAuth app consents the user granted.
• Check SharePoint and OneDrive access and recent sharing links.
• Check outbound mail for internal phishing sent from the account.
• Sign the person out of connected SSO apps and rotate any secrets that sat in their mailbox or drive.

For Google Workspace, do the equivalent from the Admin console: reset the password, sign the user out of all sessions, review their 2-step verification methods and third-party app access, and check Gmail filters and forwarding.

If you hold personal data of people in India, check your breach reporting duties; I covered them in my DPDP Act explainer.

What I'd do as a CTO

I'd spend Monday morning on step 1. Put the Conditional Access policy in report-only, pull 90 days of device code sign-ins, name the two or three people who genuinely need it, and switch the block on by Wednesday. For most startups that list of people is empty.

I'd start the passkey rollout the same week with the accounts that would hurt most: founders, finance, and anyone with admin rights in Microsoft, Google, AWS or the domain registrar. Those are the accounts an attacker picks first.

And I'd stop treating identity as an IT chore. The Microsoft or Google tenant is the root account for the whole company, so it gets what production gets: an owner, a written baseline and a quarterly review (it is on my startup security checklist for that reason). AI has made convincing lures cheap, as I wrote in Can AI Hack Systems?, so remove whole classes of attack in configuration rather than hoping people spot better fakes.

If nobody on your team owns this, it doesn't need a full-time hire. A technical advisor retainer can review your tenant settings with whoever runs IT, and a fractional CTO can own identity, security and the rest of the platform end to end.

Frequently asked questions

What is device code phishing? It is a phishing technique that abuses the OAuth device authorization flow, which is built for TVs and command-line tools. The attacker requests a sign-in code, persuades you to type it into the real Microsoft page and sign in, and Microsoft then issues your account's tokens to the attacker's session.

Does MFA stop device code phishing? Ordinary MFA does not, because you complete it yourself on the genuine Microsoft page. Blocking the device code flow with Conditional Access does, and passkeys stop the proxy-style phishing that often comes with it.

How do I block device code flow in Microsoft 365? Create a Conditional Access policy in the Entra admin center: all users (excluding break-glass accounts), all resources, Conditions > Authentication flows > Device code flow, grant Block access. Run it in report-only first and check sign-in logs filtered by the Device code authentication protocol. Conditional Access needs Entra ID P1.

Is the OpenAI Academy event email a scam? The pages in this campaign are fakes; OpenAI, SpaceX and Anthropic are being impersonated, not involved. Treat any event page that wants your work sign-in to hand out a free AI subscription as phishing, and check the company's own website directly.

Does this affect Google Workspace? Yes, through a different method. The campaign's Google path is a reverse proxy that captures your password, MFA response and session cookie on a fake copy of Google's sign-in page. Passkeys and security keys defeat that, because they only work on the real Google domain.

What should I do if I entered a code from a website? Tell whoever runs IT immediately. They should disable the account, revoke all sessions, reset the password, remove unknown MFA methods and devices, and check mailbox rules, app consents and file sharing before turning the account back on.

If you'd like a second pair of eyes on your Microsoft or Google tenant before this lands in your inbox, book a 30-minute call. Bring an admin who can share the screen, and we'll go through the settings that matter first.

Sources

• Analyzing a fake event campaign combining AiTM and device code phishing payloads (Push Security)
• Fake OpenAI, SpaceX events used to steal Microsoft, Google accounts (BleepingComputer)
• SkyW4lker phishing campaign expands, threatening US enterprises with Microsoft 365 account takeovers (Cyber Security News)
• Weekly Recap: Critical CVEs, Linux DDoS Botnet, Device-Code Phishing, Android Spyware and More (The Hacker News)
• 5 Active Cyber Threats That Put US Enterprises at Risk in October 2026 (The Hacker News, partner content from ANY.RUN)
• Storm-2372 conducts device code phishing campaign (Microsoft Security Blog)
• Block authentication flows with Conditional Access policy (Microsoft Learn)
• Authentication flows as a condition in Conditional Access policy (Microsoft Learn)
• Token protection in Microsoft Entra Conditional Access (Microsoft Learn)
• Revoke user access in Microsoft Entra ID (Microsoft Learn)
• Deploy 2-step verification (Google Workspace Admin Help)

Written By

Kunal Vohra

Technical Co-Founder & Fractional CTO

I've co-founded 6+ startups across India, the UAE, and the US, spanning AI, Web3, fintech, and cybersecurity. I write about the technical and strategic decisions that determine whether a startup thrives or stalls.

Work With MeMedium →LinkedIn →