Back to Intelligence

Fake OpenAI, SpaceX, and Anthropic Event Lures Fuel AiTM Phishing Campaigns Targeting Microsoft and Google Accounts — Detection and Hardening Guide

SA
Security Arsenal Team
November 5, 2026
11 min read

A coordinated social engineering campaign is using fraudulent event invitations impersonating OpenAI, SpaceX, and Anthropic to compromise corporate Microsoft and Google accounts. According to reporting from BleepingComputer, the operators are leveraging two distinct social engineering-as-a-service (SEaaS) platforms to deliver polished, believable lures that direct victims to credential-harvesting infrastructure capable of capturing not just usernames and passwords, but live authentication sessions.

This is the part that should concern every defender: the theft of session tokens means multi-factor authentication is not a guaranteed backstop. Adversary-in-the-middle (AiTM) phishing infrastructure proxies the victim's authentication flow in real time, captures the resulting session cookie or token after MFA completes, and replays it from attacker infrastructure. The victim did everything 'right' — and the account is still compromised.

The lures specifically exploit the enormous public interest in AI companies and high-profile tech events. An invitation to an 'exclusive OpenAI briefing' or a 'SpaceX partner event' lands in a corporate inbox, carries plausible branding, and links to a login page that is a pixel-perfect clone of a Microsoft or Google authentication portal. Employees at technology-forward organizations are the primary targets, and given the SEaaS delivery model, we should expect this campaign style to scale quickly and mutate.

This post breaks down the attack chain, explains why conventional MFA is insufficient, and provides detection content — Sigma, KQL, and VQL — plus concrete hardening steps your organization can implement this week.

Technical Analysis

What is being attacked

  • Target platforms: Microsoft 365 / Entra ID accounts and Google Workspace accounts
  • Lure themes: Fake event invitations branded as OpenAI, SpaceX, and Anthropic
  • Delivery mechanism: Two separate social engineering-as-a-service platforms, indicating a mature criminal supply chain where phishing infrastructure, lure templates, and landing pages are rented or subscribed to rather than built by each operator
  • Objective: Credential theft and authentication session theft (session cookies/tokens)

Attack chain (defender's view)

  1. Lure delivery: A well-crafted email arrives with event branding from a recognizable AI or space company. Sender domains are typically lookalikes or freshly registered domains that pass cursory human inspection. Links may pass through redirectors or legitimate services to defeat URL scanning.
  2. Landing page: The victim clicks through to a page that requests 'sign in to register' or 'verify your identity to claim your invite.' The page mirrors the Microsoft or Google login experience.
  3. AiTM proxying: In the more dangerous variant, the phishing server acts as a reverse proxy to the real identity provider. The victim's credentials and MFA response are relayed live; the attacker harvests the authenticated session artifact (cookie or token) after successful authentication.
  4. Session replay: The attacker imports the stolen session into their own browser and gains full account access without needing credentials or MFA again — until the session expires or is revoked.
  5. Post-compromise: Typical follow-on activity includes mailbox rule creation, internal phishing propagation, OAuth consent abuse for persistence, data theft, and business email compromise (BEC) staging.

Why this defeats basic MFA

SMS, TOTP apps, and even push-based MFA validate the authentication event, not the session's eventual holder. Once the session token is minted, whoever presents it is trusted. This is precisely why Microsoft and Google have been pushing phishing-resistant authentication (FIDO2 security keys, passkeys, certificate-based authentication) and token binding / token protection in Conditional Access — controls that cryptographically tie the session to the legitimate device or origin, making replay from attacker infrastructure fail.

Exploitation status

This is an active, in-the-wild campaign delivering working phishing infrastructure, not a theoretical technique. The SEaaS model means the barrier to entry is low and variant volume is high. There is no CVE associated with this campaign — it exploits human trust and architectural weaknesses in session management, not a software bug. No patch exists; the fix is architectural and procedural.

Detection & Response

The detections below focus on the highest-signal, lowest-noise behaviors: anomalous OAuth consent grants (a common persistence step after session theft), suspicious sign-in patterns consistent with token replay (new device, new ASN/location, immediately following mail delivery), and browser artifacts indicating visits to impersonation domains.

YAML
---
title: Suspicious OAuth Consent Grant Following Phishing Campaign Activity
id: 4f2c8a1e-6b9d-4e7a-9c31-2a5d7f8b0e12
status: experimental
description: Detects user consent grants to newly registered or unverified OAuth applications in Entra ID, a common persistence and data-access step after AiTM phishing-driven session theft. Correlates with fake OpenAI/SpaceX/Anthropic lure campaigns targeting Microsoft accounts.
references:
  - https://www.bleepingcomputer.com/news/security/fake-openai-spacex-events-used-to-steal-microsoft-google-accounts/
  - https://attack.mitre.org/techniques/T1528/
  - https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/02/09
tags:
  - attack.credential_access
  - attack.t1550.001
  - attack.persistence
logsource:
  product: azure
  category: auditlogs
detection:
  selection_operation:
    OperationName:
      - 'Consent to application'
      - 'Add service principal'
      - 'Add delegated permission grant'
  filter_known_apps:
    TargetResources|contains:
      - 'Microsoft'
      - 'Office 365'
  condition: selection_operation and not filter_known_apps
falsepositives:
  - Legitimate third-party SaaS onboarding by users; tune with an allowlist of approved application names in your tenant
level: high
---
title: Browser Launch of Lookalike AI Company Phishing Domains
id: 8e1b3d47-5c2a-4f68-b1d9-7c4e6a0f2d35
status: experimental
description: Detects browser processes navigating to lookalike domains abusing OpenAI, Anthropic, or SpaceX branding on non-official top-level infrastructure, consistent with fake event invitation phishing lures delivering AiTM credential and session theft pages.
references:
  - https://www.bleepingcomputer.com/news/security/fake-openai-spacex-events-used-to-steal-microsoft-google-accounts/
  - https://attack.mitre.org/techniques/T1566/002/
author: Security Arsenal
date: 2026/02/09
tags:
  - attack.initial_access
  - attack.t1566.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_browser:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
  selection_lure:
    CommandLine|contains:
      - 'openai-event'
      - 'openai.events'
      - 'spacex-event'
      - 'spacex.events'
      - 'anthropic-event'
      - 'anthropic.events'
      - '-invite'
      - 'event-registration'
  filter_official:
    CommandLine|contains:
      - 'openai.com'
      - 'spacex.com'
      - 'anthropic.com'
  condition: selection_browser and selection_lure and not filter_official
falsepositives:
  - Rare; internal marketing pages using similar URL slugs. Validate against a list of sanctioned campaign domains.
level: high
KQL — Microsoft Sentinel / Defender
// Hunt: Sign-ins consistent with AiTM session-token replay following delivery
// of AI/space-themed event lure emails. Joins Defender for Office email events
// with Entra sign-ins showing a new device and new ASN within a short window.
// Tune the time window and lure keywords to your environment.
let LureWindow = 24h;
let LureKeywords = dynamic(["openai", "spacex", "anthropic", "event", "invite", "registration"]);
let LureRecipients =
    EmailEvents
    | where TimeGenerated > ago(LureWindow)
    | where Subject has_any (LureKeywords)
    | where SenderFromDomain !in ("openai.com", "spacex.com", "anthropic.com")
    | where DeliveryAction == "Delivered"
    | extend Recipient = tolower(RecipientEmailAddress)
    | project EmailTime = TimeGenerated, Recipient, SenderFromDomain, Subject, NetworkMessageId;
SigninLogs
| where TimeGenerated > ago(LureWindow)
| where ResultType == 0
| extend Recipient = tolower(UserPrincipalName)
| join kind=inner LureRecipients on Recipient
| where TimeGenerated between (EmailTime .. EmailTime + 6h)
| extend DeviceDetail = tostring(DeviceDetail)
| project SignInTime = TimeGenerated, Recipient, IPAddress, Location,
          AppDisplayName, UserAgent, DeviceDetail, AuthenticationRequirement,
          SenderFromDomain, Subject, RiskLevelDuringSignIn
| order by SignInTime desc
KQL — Microsoft Sentinel / Defender
// Hunt: Session replay indicators — successful sign-ins from ASNs/locations
// never before seen for the user, with token/cookie-based auth (no interactive
// MFA claim), typical of stolen session reuse after AiTM phishing.
let Lookback = 30d;
let Recent = 2d;
let KnownLocations =
    SigninLogs
    | where TimeGenerated between (ago(Lookback) .. ago(Recent))
    | where ResultType == 0
    | summarize by UserPrincipalName, AutonomousSystemNumber = tostring(NetworkLocationDetails), Location;
SigninLogs
| where TimeGenerated > ago(Recent)
| where ResultType == 0
| extend ASN = tostring(NetworkLocationDetails)
| where not(UserPrincipalName in~ (KnownLocations | project UserPrincipalName)
    and ASN in~ (KnownLocations | project AutonomousSystemNumber))
| where AuthenticationRequirement == "singleFactorAuthentication" or isnotempty(TokenProtectionStatus)
| project TimeGenerated, UserPrincipalName, IPAddress, ASN, Location,
          AppDisplayName, UserAgent, AuthenticationRequirement,
          TokenProtectionStatus, RiskLevelDuringSignIn
| order by TimeGenerated desc
VQL — Velociraptor
-- Hunt browser history artifacts for visits to AI/space-themed phishing
-- lure domains (fake OpenAI/SpaceX/Anthropic event pages) across endpoints.
-- Parses Chrome/Edge History SQLite databases for suspicious URL patterns
-- while excluding the legitimate vendor domains.
LET history_files = SELECT FullPath
FROM glob(globs=[
  'C:/Users/*/AppData/Local/Google/Chrome/User Data/*/History',
  'C:/Users/*/AppData/Local/Microsoft/Edge/User Data/*/History'
])

SELECT FullPath AS HistoryDB,
       url.URL AS VisitedURL,
       url.title AS PageTitle,
       timestamp(epoch=url.last_visit_time / 1000000 - 11644473600) AS VisitTimeUTC
FROM foreach(
  row=history_files,
  query={
    SELECT FullPath, url.url AS URL, url.title, url.last_visit_time
    FROM sqlite(file=FullPath,
                query='SELECT url, title, last_visit_time FROM urls')
    AS url
    WHERE (url.URL =~ '(?i)openai|spacex|anthropic'
       OR url.URL =~ '(?i)(event|invite|registration)')
      AND url.URL !~ '(?i)(^|//|\.)(openai\.com|spacex\.com|anthropic\.com)'
      AND url.URL =~ '(?i)(event|invite|registr|briefing|webinar|rsvp)'
  })
ORDER BY VisitTimeUTC DESC
PowerShell
# AiTM Phishing Response & Entra ID Hardening Script
# Run with an account holding Global Admin or Privileged Role Admin + Cloud App Admin.
# Requires: Microsoft.Graph PowerShell SDK (Install-Module Microsoft.Graph)

# 1. Connect with the scopes needed for session revocation and consent auditing
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All","RevokeSession.All","AuditLog.Read.All","Policy.ReadWrite.ConditionalAccess"

# 2. REVOKE active sessions for suspected compromised users (stolen tokens die here)
# Replace with your confirmed/affected user list from the KQL hunts above
$affectedUsers = @("user1@contoso.com","user2@contoso.com")
foreach ($u in $affectedUsers) {
    Revoke-MgUserSignInSession -UserId $u
    Write-Host "[+] Sessions revoked for $u" -ForegroundColor Green
}

# 3. AUDIT recent OAuth consent grants (persistence check after session theft)
$since = (Get-Date).AddDays(-14).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $since" -All |
  Where-Object { $_.ActivityDisplayName -in @("Consent to application","Add service principal","Add delegated permission grant") } |
  Select-Object ActivityDateTime, ActivityDisplayName,
    @{n='InitiatedBy';e={$_.InitiatedBy.User.UserPrincipalName}},
    @{n='TargetApp';e={($_.TargetResources | Select-Object -First 1).DisplayName}} |
  Format-Table -AutoSize

# 4. VERIFY Conditional Access token protection is enforced (blocks session replay)
Get-MgIdentityConditionalAccessPolicy |
  Where-Object { $_.State -eq "enabled" } |
  Select-Object DisplayName,
    @{n='TokenProtection';e={$_.SessionContext -match 'tokenProtection'}} |
  Format-Table -AutoSize

# 5. CHECK for users still on legacy / non-phishing-resistant MFA
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Where-Object { $_.IsMfaRegistered -eq $true -and $_.MethodsRegistered -notcontains "windowsHelloForBusiness" -and $_.MethodsRegistered -notcontains "fido2" -and $_.MethodsRegistered -notcontains "passkey" } |
  Select-Object UserPrincipalName, MethodsRegistered |
  Export-Csv -Path ".\NonPhishingResistantMFAUsers.csv" -NoTypeInformation
Write-Host "[!] Review .\NonPhishingResistantMFAUsers.csv for phishing-resistant MFA rollout targets" -ForegroundColor Yellow

# 6. REMOVE suspicious mailbox forwarding rules created post-compromise (per user)
# Connect-ExchangeOnline
# Get-InboxRule -Mailbox "user1@contoso.com" | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.DeleteMessage -eq $true } | Format-List

Remediation

Because this campaign exploits session architecture and human trust rather than a patchable vulnerability, remediation is layered. Prioritize in this order:

Immediate (24–48 hours)

  1. Revoke sessions for any suspected victims. Stolen session tokens remain valid until expiry or revocation. Use Revoke-MgUserSignInSession (Entra) or the Google Admin console's Sign out user / revoke OAuth tokens function. Revocation is the single highest-impact containment action for session theft — password resets alone do not kill an active stolen session in every scenario, so do both.
  2. Force password resets and re-register MFA for affected accounts. Treat any confirmed click-through on these lures as full credential compromise.
  3. Audit for persistence: OAuth consent grants, inbox forwarding/deletion rules, new MFA methods added to the victim account, and new device enrollments. These are the standard post-AiTM artifacts.
  4. Block and report the lure domains at your secure email gateway, DNS resolver, and web proxy. Report phishing URLs to Microsoft (via the report message add-in / submissions portal) and Google Safe Browsing.

Short term (this quarter)

  1. Deploy phishing-resistant MFA. Enforce FIDO2 security keys, passkeys, or Windows Hello for Business for all users — starting with executives, finance, IT admins, and anyone with access to sensitive data. In Google Workspace, enforce security keys via the Advanced Protection Program for high-risk users. This is the only control class that structurally defeats AiTM proxying, because the authenticator cryptographically binds to the legitimate origin.
  2. Enable Conditional Access token protection (Entra ID P2). Token protection binds sign-in session tokens to the device, so a replayed token from attacker infrastructure is rejected. Combine with compliant-device and sign-in risk policies.
  3. Restrict user consent for OAuth applications. Disable user consent entirely or switch to admin consent workflows (Entra: Enterprise applications → Consent and permissions; Google Workspace: API controls → App access control). This removes the most common persistence path after account takeover.
  4. Disable legacy authentication protocols (IMAP, POP, basic auth SMTP) that bypass modern Conditional Access enforcement.

Ongoing

  1. Targeted user education on this exact lure family. Generic phishing training is losing effectiveness against SEaaS-quality lures. Brief staff specifically: no legitimate OpenAI, SpaceX, or Anthropic event requires you to authenticate through a link in an email. Verify invitations through official channels, and treat any 'sign in to register' flow as hostile by default.
  2. Continuous monitoring with the KQL hunts above, plus alerting on RiskLevelDuringSignIn anomalies, impossible travel, and first-time ASN/device combinations. If you license Entra ID Protection, ensure risky sign-in policies are set to block, not just report.
  3. Tabletop the scenario. Your IR runbook for account takeover should explicitly include session revocation, consent audit, and mailbox rule audit — many organizations still only reset passwords and call it done. That playbook loses against AiTM.

Conclusion

The fake OpenAI, SpaceX, and Anthropic event campaign is a textbook example of where phishing has evolved: professionally packaged lures delivered through criminal service platforms, engineered specifically to harvest sessions and neutralize conventional MFA. There is no patch to deploy — defense here is architectural: phishing-resistant authentication, token binding, restricted consent, and fast session revocation when compromise is suspected.

If your organization has already deployed FIDO2/passkeys broadly, your exposure to this campaign class drops dramatically. If you have not, this is the business case to take to leadership this week.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.