Event Invitation Phishing: Detection, Hunting and Prevention

An invitation is one of the easiest messages to trust. It offers something rather than demanding something, it names a real organization or a real event, and the next step, register or join, feels routine. Attackers have used invitations for years, but in 2026 event lures have become a standard delivery method for both criminal phishing kits and state actors.

The most recent example is a campaign Push Security published on November 5, 2026: fake OpenAI, SpaceX and Anthropic events that ask staff to sign in with their work account to claim a reward such as three months of ChatGPT Pro. It is a good illustration of where the technique has gone, but it is one campaign among many. This guide covers the technique as a whole: how event invitation phishing works, why it succeeds, what recent campaigns have done, and how to prevent, detect and hunt for it in Microsoft 365, Entra ID and Google Workspace.

How event invitation phishing works

Every event lure has the same five parts. Attackers change each part independently, which is why blocking one sender or one domain rarely stops a campaign.

1. The pretext

The event has to look worth attending and fit the target’s job.

• Product previews and webinars with a reward: early access to an AI tool, a free subscription, a certificate.
• Partner summits and industry events aimed at marketing, partnerships and events staff.
• Closed-door roundtables and conferences aimed at policy, research and government staff, often using the names of real think tanks and real conferences.
• Speaker, panel or podcast invitations that flatter the target as an expert.
• Ordinary meetings: a Teams or Zoom invite from a “client”, a “recruiter” or an “investor”.
• Personal invitations such as parties, weddings and e-cards, which reach work inboxes too.

2. How the invitation arrives

• Through the real event platform. Attackers create accounts on Eventbrite, Luma, GoTo Webinar or Zoom Events and send through the platform’s own mail system. The messages pass SPF, DKIM and DMARC because the platform really sent them.
• As a calendar invite. Outlook adds meeting invitations to the calendar during delivery, and Google Calendar adds invitations from everyone by default. The event can sit on the calendar even after the email is removed or sent to Junk.
• After a conversation. State actors build rapport first on email, WhatsApp, Signal or Telegram, then send the invitation once the target expects it.
• Through a booking link. The attacker sends a Calendly or similar link, and the calendar invite the target receives contains the attacker’s meeting URL.
• On paper. Cisco Talos reported an actor that sent real event posters with the QR codes swapped for malicious ones, anticipating that recipients would print and display them.

3. The registration or join step

This is where the attack happens. The invitation leads to a page that asks the visitor to do something that feels normal for an event.

• “Register with your work account” or “Continue with Microsoft / Google”.
• “Enter this code to confirm your seat”, which is Microsoft device code sign-in.
• “Grant access to join”, an OAuth consent prompt for a malicious app.
• “Your audio is not working, run this fix”, a ClickFix prompt that has the victim paste a command.
• “Update your meeting app”, a fake Zoom or Teams installer.

4. What the attacker gets

5. How it slips past defenses

• Trusted senders. The email comes from GoTo Webinar, Eventbrite, Luma or Microsoft itself, so sender reputation and authentication checks pass.
• Trusted redirects. Links go through Google, Zapier or X redirects before reaching the attacker’s site.
• Bot checks. A CAPTCHA or Cloudflare challenge stops scanners from seeing the page.
• Fresh domains. Lure domains are often days old, and typo-squatted meeting domains are registered in bulk.
• Targeting filters. Some sites send only chosen victims to the payload and show everyone else a harmless confirmation page.
• The calendar. A meeting entry keeps the link in front of the victim even after the email is quarantined.

Why it works

• It offers instead of demanding. Most phishing training teaches people to distrust urgency and threats. An invitation flatters and rewards, so it does not trip those instincts.
• Exclusivity. “Closed-door”, “invite-only”, “registration approved” and limited rewards make people act before they think. Microsoft’s list of Star Blizzard’s 2026 campaigns includes five invitations billed as closed-door or private discussions.
• Real brands and real platforms. The page looks like OpenAI Academy or Zoom Events because it copies them, and the email often really came from the event platform.
• Signing in to register is normal. Real event sites ask for a work email or single sign-on, so a sign-in prompt is expected.
• Calendar entries are routine. Check Point notes a calendar invite “is rarely questioned”.
• Social proof. Kaspersky saw fake meetings that played real recordings of earlier victims, so the target saw a meeting already under way.
• Ordinary MFA does not help. With device code and AiTM payloads the victim completes MFA themselves, so the defense people were told to rely on works for the attacker.

Recent campaigns

The November 2026 AI events campaign shows how the parts combine. The operator ran fake Zoom event pages from May to October, then switched to OpenAI, SpaceX and Anthropic pages on eventrsvp[.]app from October 22. “Continue with Microsoft” opened Microsoft’s real device login page with a code from the Kali365 service, then sent the victim to a VoidProxy page for a second capture. “Continue with Google” opened a VoidProxy reverse proxy of Google’s sign-in. The lure domain was three days old when Push examined it, and most public scanners never got past its Cloudflare challenge.

Who is targeted

• Marketing, partnerships, events and sales staff, for AI, partner and ad-platform lures.
• Executives, investors and crypto or Web3 staff, for fake meetings and ClickFix.
• Policy, government, research and academic staff, for conference, roundtable and speaker invitations from state actors.
• Everyone with a calendar, for mass fake meeting invites.

Preventing event invitation phishing

Identity controls in Microsoft 365 and Entra ID

1. Block device code flow. In Conditional Access, create a policy for all users and all resources with Conditions > Authentication flows > Device code flow set to Block. Microsoft recommends getting “as close as possible to a unilateral block”. Exclude break-glass accounts, run it in Report-only first, and use Hunt 1 below to find the few users and devices that need an exception. Block authentication transfer the same way. The policy also applies to the Device Registration Service, so check device enrollment that relies on device code before switching it on.
2. Require phishing-resistant MFA. Use the Phishing-resistant MFA authentication strength (FIDO2 keys and passkeys, Windows Hello for Business, certificate-based authentication) for administrators first, then the targeted groups above, then everyone. It stops AiTM proxies.
3. Require compliant or hybrid-joined devices for Microsoft 365 where possible, so a token replayed from the attacker’s machine fails.
4. Turn on token protection for supported apps (Exchange Online, SharePoint Online and Teams on Windows, macOS and iOS).
5. Use sign-in and user risk policies in Entra ID Protection, and keep Continuous Access Evaluation on so revocation takes effect quickly.
6. Restrict user consent to verified publishers and low-risk permissions, with admin approval for the rest.
7. Enable automatic attack disruption in Defender XDR, which needs the Defender for Cloud Apps Microsoft 365 connector, Defender for Endpoint and Defender for Identity.

Identity controls in Google Workspace

1. Enforce passkeys or security keys through 2-Step Verification, starting with administrators and targeted groups.
2. Use Context-Aware Access (Enterprise and Cloud Identity Premium) to limit access to managed devices or known networks.
3. Shorten web session length from the 14-day default for sensitive groups.
4. Restrict third-party app access to reviewed apps under API controls.

Calendar controls

• Google Workspace. In the Admin console, go to Apps > Google Workspace > Calendar > Advanced settings and set invitations to be added automatically only from known senders (or only after the user responds by email). Since August 14, 2026 the setting can be enforced for existing users, not only new ones. The default is still “Invitations from everyone”.
• Outlook and Exchange Online. Outlook adds meeting invitations to user calendars during delivery, and Set-CalendarProcessing only controls resource mailboxes, so there is no switch to stop it on user mailboxes. Rely on removal instead: in Defender for Office 365, a Hard Delete remediation now also removes the calendar entry created by a malicious invite. It does not remove entries a user added by hand from an .ics file.
• Block or inspect .ics attachments from external senders. .ics is not in the default common attachments filter in Defender for Office 365, but you can add it.

Email and web controls

• Block newly registered domains and typo-squats of Zoom, Teams and Google Meet at the DNS filter or web gateway.
• Follow redirects to the end. Make sure filtering resolves c.gle, share.google, zpr.io and open redirects before judging a link.
• Treat event platform mail like any external mail. A message from Eventbrite, Luma, GoTo Webinar or Zoom Events is only as trustworthy as the account that created the event.
• Flag invites whose platform and link disagree, such as a Google Meet invite that points to a Zoom-like domain.

Meeting apps and endpoints

• Install meeting clients only from the vendor or your software portal, and block unsigned or unapproved meeting-app installers.
• Restrict PowerShell, mshta and the Run dialog for standard users where you can, which blunts ClickFix.
• Alert on commands pasted into Run (Hunt 11 below).

Your own events

• Publish official registration links on your own website and tell customers how you will contact them.
• Don’t require single sign-on with a work account to register for your own webinars. It trains attendees to accept exactly the prompt attackers use.
• Watch for look-alike event pages using your brand.

What to teach staff

Keep it to rules people can remember:

• No event, webinar or reward ever needs you to type a code into a Microsoft sign-in page.
• Joining a meeting never needs you to paste a command or install an update from the meeting page.
• If a registration page asks you to sign in with your work account, check the event on the organizer’s own website first.
• “Invite-only” and “closed-door” are sales words. Verify the sender through a channel you already use.
• Report unexpected calendar invites instead of deleting them, so the security team can remove them for everyone.

Detecting it in Microsoft 365 and Entra ID

Where the evidence lives

Microsoft deprecated the Defender table AADSignInEventsBeta on October 19, 2026 in favor of EntraIdSignInEvents. Older published queries still use the old name.

Device code sign-ins

In SigninLogs and AADNonInteractiveUserSignInLogs, a device code sign-in has AuthenticationProtocol == "deviceCode". The token refreshes that follow keep the origin in OriginalTransferMethod, which Microsoft’s Graph schema documents with the value deviceCodeFlow. In the Entra admin center, filter sign-in logs on Authentication protocol: Device code.

Signals that a device code sign-in is phishing rather than a conference room or developer:

• The user has never used device code before.
• The sign-in comes from an IP address or network (autonomous system) the user never uses, often hosting or VPN ranges, while the user’s own browser activity is elsewhere.
• The app is Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e), which can lead to device registration, or a first-party client such as Microsoft Office.
• It is followed within hours by a new registered device, new MFA method, inbox rule or bulk mail access.
• Microsoft’s interrupt error 50199 appears next to a success in the same session, a pattern Microsoft’s own hunting query uses.

Stolen-session (AiTM) sign-ins

• Entra ID Protection raises Attacker in the Middle (attackerinTheMiddle, which sets user risk to high and needs Microsoft 365 E5), Anomalous token (anomalousToken), Token issuer anomaly (tokenIssuerAnomaly), Unfamiliar sign-in properties (unfamiliarFeatures) and Suspicious browser (suspiciousBrowser).
• Defender XDR alerts include “Stolen session cookie was used,” “Authentication request from AiTM-related phishing page” and “Possible AiTM phishing attempt.” With the Defender for Cloud Apps Microsoft 365 connector, Defender for Endpoint and Defender for Identity in place, automatic attack disruption disables the account and revokes the stolen session.
• The session pattern. A browser sign-in to OfficeHome followed by sign-ins to other apps with the same SessionId from a different country or network is what replaying a stolen cookie looks like.

What attackers do next

Arctic Wolf reported operators of the Kali365 device code phishing service creating inbox rules that move mail containing words such as “spam,” “phish,” “click” and “link,” so the victim does not see warnings from colleagues.

Email and click telemetry

UrlClickEvents records Safe Links clicks in email, Office apps and Teams, with the whole redirect chain in UrlChain. That is where c.gle, zpr.io and x.com/logout hops show up even when the final domain is new. Safe Links does not rewrite links in Teams, and Microsoft notes that wrapping links with another service before Defender for Office 365 can stop Safe Links from processing them.

Detecting it in Google Workspace

The Admin console audit and investigation tool records the evidence under Login, OAuth Token and Gmail events. The useful login event names are:

• suspicious_login, suspicious_programmatic_login and suspicious_login_less_secure_app, Google’s own risk detections
• user_signed_out_due_to_suspicious_session_cookie, Google ending a session it believes was hijacked
• gov_attack_warning, Google’s government-backed attacker warning
• account_disabled_hijacked, an account Google disabled as hijacked
• login_success with login_challenge_method and is_second_factor, to see which second factors are really in use
• email_forwarding_out_of_domain, new forwarding to an outside address

For a user who clicked, look at login events from new IP addresses or countries shortly after the click, OAuth authorize events granting new apps mail or Drive scopes, and Gmail filters and forwarding added afterwards. Google’s device bound session credentials (DBSC) mainly defend against cookie theft by malware on the device. Against an AiTM proxy, enforce passkeys or security keys for the users most likely to be targeted.

Threat hunting queries

The KQL below is example code for Microsoft Sentinel and Microsoft Defender XDR advanced hunting. Adapt table and field names to your environment and test each query before relying on it. Hunt back at least six months; the Zoom-themed pages in the November 2026 campaign go back to May.

Hunt 1: every device code sign-in in the tenant

Start here. Most organizations find a short list of legitimate users (meeting room devices, Azure CLI users) and the rest needs explaining.

// Example: Sentinel, device code sign-ins and the token refreshes that follow them
union isfuzzy=true
  (SigninLogs | where TimeGenerated > ago(180d)
     | project TimeGenerated, UserPrincipalName, AppDisplayName, AppId, IPAddress, AutonomousSystemNumber,
               ResultType, AuthenticationProtocol, OriginalTransferMethod, UserAgent, Kind="interactive"),
  (AADNonInteractiveUserSignInLogs | where TimeGenerated > ago(180d)
     | project TimeGenerated, UserPrincipalName, AppDisplayName, AppId, IPAddress, AutonomousSystemNumber,
               ResultType, AuthenticationProtocol, OriginalTransferMethod, UserAgent, Kind="noninteractive")
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| summarize SignIns=count(), Successes=countif(ResultType == "0"), Apps=make_set(AppDisplayName, 10),
            IPs=make_set(IPAddress, 20), Networks=make_set(AutonomousSystemNumber, 10),
            FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
    by UserPrincipalName
| order by FirstSeen desc

Hunt 2: first-time device code users, and device code from new networks

// Example: Sentinel, successful device code sign-ins by users or from networks not seen in the previous 60 days
let Recent = 14d; let Baseline = 60d;
let Hist = SigninLogs
  | where TimeGenerated between (ago(Recent + Baseline) .. ago(Recent))
  | where ResultType == "0"
  | summarize KnownNetworks=make_set(AutonomousSystemNumber), DeviceCodeCount=countif(AuthenticationProtocol == "deviceCode")
      by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(Recent)
| where AuthenticationProtocol == "deviceCode" and ResultType == "0"
| join kind=leftouter Hist on UserPrincipalName
| extend FirstDeviceCode = isnull(DeviceCodeCount) or DeviceCodeCount == 0,
         NewNetwork = isnull(KnownNetworks) or not(set_has_element(KnownNetworks, AutonomousSystemNumber))
| where FirstDeviceCode or NewNetwork
| project TimeGenerated, UserPrincipalName, AppDisplayName, AppId, IPAddress, AutonomousSystemNumber,
          Location=tostring(LocationDetails.countryOrRegion), FirstDeviceCode, NewNetwork, UserAgent
| order by TimeGenerated desc

Hunt 3: Microsoft’s query for device code phishing after a click

Microsoft publishes this query in its Azure Sentinel repository. It finds a click on a device login page followed within minutes by a risky sign-in, for users who also show the 50199 interrupt and a success in one session. It is reproduced as published.

// Microsoft, "Possible device code phishing attempts" (Azure-Sentinel repository), Defender XDR advanced hunting
let suspiciousUserClicks = materialize(UrlClickEvents
  | where ActionType in ("ClickAllowed", "UrlScanInProgress", "UrlErrorPage") or IsClickedThrough != "0"
  | where UrlChain has_any ("microsoft.com/devicelogin", "login.microsoftonline.com/common/oauth2/deviceauth")
  | extend AccountUpn = tolower(AccountUpn)
  | project ClickTime = Timestamp, ActionType, UrlChain, NetworkMessageId, Url, AccountUpn);
let interestedUsersUpn = suspiciousUserClicks
  | where isnotempty(AccountUpn)
  | distinct AccountUpn;
let suspiciousSignIns = materialize(EntraIdSignInEvents
  | where ErrorCode == 0
  | where AccountUpn in~ (interestedUsersUpn)
  | where RiskLevelDuringSignIn in (10, 50, 100)
  | extend AccountUpn = tolower(AccountUpn)
  | join kind=inner suspiciousUserClicks on AccountUpn
  | where (Timestamp - ClickTime) between (-2min .. 7min)
  | project Timestamp, ReportId, ClickTime, AccountUpn, RiskLevelDuringSignIn, SessionId, IPAddress, Url);
let interestedSessionUsers = suspiciousSignIns
  | where isnotempty(AccountUpn)
  | distinct AccountUpn;
let shortIntervalSignInAttemptUsers = materialize(EntraIdSignInEvents
  | where AccountUpn in~ (interestedSessionUsers)
  | where ErrorCode in (0, 50199)
  | summarize ErrorCodes = make_set(ErrorCode) by AccountUpn, CorrelationId, SessionId
  | where ErrorCodes has_all (0, 50199)
  | distinct AccountUpn);
suspiciousSignIns
| where AccountUpn in (shortIntervalSignInAttemptUsers)

Hunt 4: event invitations and their redirect chains in mail and clicks

Look for event-themed mail from event platforms and outside senders, and for clicks that pass through the redirectors event campaigns use. Add the event platforms your organization really uses to the exclusions.

// Example: Defender XDR, event-themed mail and clicks through common redirectors
let EventWords = dynamic(["webinar", "summit", "conference", "roundtable", "livestream", "briefing", "invitation", "invite", "RSVP", "registration", "register", "exclusive", "preview", "event"]);
let EventPlatforms = dynamic(["gotowebinar.com", "eventbrite.com", "lu.ma", "zoom.us", "calendly.com"]);
let Redirectors = dynamic(["c.gle/", "share.google/", "zpr.io/", "redirect_after_logout=", "tinyurl.com/", "workers.dev"]);
let Mail = EmailEvents
  | where Timestamp > ago(90d)
  | where EmailDirection == "Inbound"
  | where Subject has_any (EventWords) or SenderFromDomain in~ (EventPlatforms)
  | where UrlCount > 0
  | project Timestamp, NetworkMessageId, RecipientEmailAddress, SenderFromAddress, SenderDisplayName, Subject, DeliveryAction;
let Clicks = UrlClickEvents
  | where Timestamp > ago(90d)
  | where UrlChain has_any (Redirectors)
  | project ClickTime=Timestamp, NetworkMessageId, Url, UrlChain, ActionType, IsClickedThrough, Workload;
Mail
| join kind=inner Clicks on NetworkMessageId
| project Timestamp, ClickTime, RecipientEmailAddress, SenderFromAddress, SenderDisplayName, Subject, Url, UrlChain, ActionType
| order by ClickTime desc

For a wider view, drop the join and review event-themed mail on its own. Senders that use a platform’s real address but an unfamiliar display name, such as “Austin from nthropic” sent through GoTo Webinar, are worth a look.

Hunt 5: stolen session cookies replayed from another country

Adapted from Microsoft’s published AiTM hunting query to the current EntraIdSignInEvents table. It finds a browser session that started in OfficeHome and was then used for other apps from a different country.

// Example: Defender XDR, same SessionId used from a new country after an OfficeHome sign-in
let OfficeHome = "4765445b-32c6-49b0-83e6-1d93765276ca";
let OfficeHomeSessions = EntraIdSignInEvents
  | where Timestamp > ago(7d)
  | where ErrorCode == 0 and ApplicationId == OfficeHome and ClientAppUsed == "Browser" and LogonType has "interactiveUser"
  | summarize arg_min(Timestamp, Country, IPAddress) by SessionId;
EntraIdSignInEvents
| where Timestamp > ago(7d)
| where ApplicationId != OfficeHome and ClientAppUsed == "Browser"
| project OtherTimestamp=Timestamp, Application, ApplicationId, AccountObjectId, AccountUpn, OtherCountry=Country, OtherIP=IPAddress, SessionId
| join kind=inner OfficeHomeSessions on SessionId
| where OtherTimestamp > Timestamp and OtherCountry != Country
| project AccountUpn, SessionId, FirstSignIn=Timestamp, FirstCountry=Country, FirstIP=IPAddress,
          LaterUse=OtherTimestamp, OtherCountry, OtherIP, Application

Hunt 6: Entra ID Protection detections that point to AiTM or token theft

// Example: Sentinel, AiTM and token risk detections in the last 30 days
AADUserRiskEvents
| where TimeGenerated > ago(30d)
| where RiskEventType in ("attackerinTheMiddle", "anomalousToken", "tokenIssuerAnomaly", "unfamiliarFeatures", "suspiciousBrowser")
| summarize Detections=make_set(RiskEventType), IPs=make_set(IpAddress, 10), Levels=make_set(RiskLevel),
            FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by UserPrincipalName
| order by LastSeen desc

Hunt 7: a device registered within hours of a device code sign-in

The Storm-2372 technique: a device code token for Microsoft Authentication Broker is used to register an attacker device and obtain a Primary Refresh Token, which survives a password reset until the device is removed. Microsoft also publishes a Defender XDR version of this check (“risky sign-in to device registration”) in its Azure Sentinel repository.

// Example: Sentinel, device registration by a user within 6 hours of their device code sign-in
let DeviceCode = SigninLogs
  | where TimeGenerated > ago(90d)
  | where AuthenticationProtocol == "deviceCode" and ResultType == "0"
  | project SignInTime=TimeGenerated, UserId, UserPrincipalName, AppDisplayName, AppId, SignInIP=IPAddress;
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName in ("Register device", "Add device", "Add registered owner to device", "Add registered users to device")
| mv-expand Target = TargetResources
| where tostring(Target.type) =~ "User"
| extend UserId = tostring(Target.id)
| join kind=inner DeviceCode on UserId
| where TimeGenerated between (SignInTime .. SignInTime + 6h)
| project SignInTime, RegistrationTime=TimeGenerated, UserPrincipalName, AppDisplayName, AppId, SignInIP, OperationName, TargetResources

Hunt 8: what happened in the account after a suspicious sign-in

Run this for every user surfaced by Hunts 1 to 7. Add the user names to the list.

// Example: Sentinel, inbox rules, MFA changes, device registration and app consent for chosen users
let Users = dynamic(["user@example.com"]);
let Since = ago(30d);
union isfuzzy=true
  (OfficeActivity | where TimeGenerated > Since
     | where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules", "Set-Mailbox", "Add-MailboxPermission")
     | where UserId in~ (Users)
     | project TimeGenerated, User=UserId, Activity=Operation, IP=ClientIP, Detail=tostring(Parameters)),
  (AuditLogs | where TimeGenerated > Since
     | where OperationName in ("User registered security info", "Register device", "Add registered owner to device",
                               "Consent to application", "Add delegated permission grant")
     | extend User = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(TargetResources[0].userPrincipalName))
     | where User in~ (Users)
     | project TimeGenerated, User, Activity=OperationName, IP=tostring(InitiatedBy.user.ipAddress), Detail=tostring(TargetResources))
| order by TimeGenerated asc

To catch inbox rules that hide warnings across the whole tenant, a habit Arctic Wolf reported for Kali365 operators:

// Example: Sentinel, inbox rules that delete or move mail mentioning phishing or security
OfficeActivity
| where TimeGenerated > ago(180d)
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| where Parameters has_any ("phish", "spam", "security", "hacked", "compromised", "suspicious", "click", "link")
| where Parameters has_any ("DeleteMessage", "MoveToFolder", "MarkAsRead", "SoftDeleteMessage")
| project TimeGenerated, UserId, ClientIP, Operation, Parameters

Hunt 9: devices that reached recent campaigns’ infrastructure

// Example: Defender for Endpoint, connections to lure and proxy domains from the November 2026 AI events campaign
let Domains = dynamic(["eventrsvp.app", "rsvpconnect-events.com", "claudewebinnar.com", "ggleventapi.icu", "logins-offcevents.icu",
  "wbdssologin.app", "ggkiejl.icu", "shifts.icu", "officegocrqb.com", "offcevent-login.com", "com-access-sharepoint.com",
  "gle-access-eventregister.icu", "workportalsso.com", "careersggl.icu", "gfmzrsj.icu", "ggolshhk.icu", "us968web-zoom.us",
  "us956web-zoom.us", "ssomeetingportal.com", "ssoeventportal.com", "iceagelandforms.surf", "emptytownmoon.de"]);
DeviceNetworkEvents
| where Timestamp > ago(180d)
| where RemoteIP == "217.60.102.48" or RemoteUrl has_any (Domains)
| summarize Connections=count(), Urls=make_set(RemoteUrl, 10), FirstSeen=min(Timestamp), LastSeen=max(Timestamp)
    by DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName
| order by FirstSeen asc

Hunt 10: external calendar invitations with links

Calendar invites reach the calendar even when the email is filtered. Find meeting invitations from outside senders that carry links or .ics files.

// Example: Defender XDR, inbound .ics attachments and meeting invites with links from external senders
let Ics = EmailAttachmentInfo
  | where Timestamp > ago(30d)
  | where FileName endswith ".ics"
  | distinct NetworkMessageId;
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where NetworkMessageId in (Ics) or (Subject startswith "Invitation:" or Subject has_any ("meeting invitation", "invited you", "has invited you"))
| where UrlCount > 0 or NetworkMessageId in (Ics)
| join kind=leftouter (EmailUrlInfo | where Timestamp > ago(30d) | summarize Domains=make_set(UrlDomain, 10) by NetworkMessageId) on NetworkMessageId
| project Timestamp, RecipientEmailAddress, SenderFromAddress, SenderDisplayName, Subject, DeliveryAction, LatestDeliveryLocation, Domains
| order by Timestamp desc

Messages with DeliveryAction of Junked or Blocked are still worth reviewing here, because the calendar entry may exist anyway.

Hunt 11: commands pasted into the Run dialog after a fake meeting

ClickFix pages for fake meetings tell the victim to press Windows+R and paste a “fix”. Windows records what was typed in the RunMRU registry key.

// Example: Defender for Endpoint, Run dialog entries that launch script interpreters or downloads
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has_any ("powershell", "pwsh", "mshta", "curl", "wget", "bitsadmin", "certutil", "iex", "http://", "https://", "cmd /c", "rundll32")
| project Timestamp, DeviceName, InitiatingProcessAccountName, RegistryValueName, RegistryValueData
| order by Timestamp desc

Correlate any hit with browser history around the same time for meeting-themed pages, and with process events for the script that ran.

Sigma detection rules

The rules below are written to the Sigma v2 specification so they can be converted for your SIEM. They are examples: test them, and tune the false positives for your environment before enabling alerts.

Field names for the Entra ID rules follow the Microsoft Sentinel SigninLogs and AADUserRiskEvents schemas (AuthenticationProtocol, OriginalTransferMethod, AppId, ResultType, RiskEventType). SigmaHQ’s own Azure rules use mixed field naming, so check how your conversion pipeline maps these before deploying. Proxy and DNS rules use the standard Sigma taxonomy (cs-host, c-uri, cs-referrer, query).

Device code sign-in succeeded

title: Entra ID Device Code Sign-In Succeeded
id: 0272913f-2060-41b1-a53a-408df14eca10
status: experimental
description: |
    Detects a successful Entra ID sign-in using the OAuth device code flow. Device code phishing kits such as Kali365
    and campaigns such as fake event invitations and Storm-2372 meeting invites rely on this flow to obtain tokens
    after the victim completes MFA on Microsoft's real login page.
references:
    - https://pushsecurity.com/blog/ai-themed-fake-event-campaign-analysis
    - https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.initial-access
    - attack.t1566.002
    - attack.credential-access
    - attack.t1528
logsource:
    product: azure
    service: signinlogs
detection:
    selection_protocol:
        AuthenticationProtocol: 'deviceCode'
    selection_transfer:
        OriginalTransferMethod: 'deviceCodeFlow'
    selection_success:
        ResultType: '0'
    condition: (selection_protocol or selection_transfer) and selection_success
falsepositives:
    - Meeting room devices, kiosks and other input-constrained devices
    - Administrators using Azure CLI or PowerShell with device code login
level: medium

Device code sign-in to Microsoft Authentication Broker

title: Entra ID Device Code Sign-In to Microsoft Authentication Broker
id: 3d7a2d0d-350f-4138-bc7a-562717864730
status: experimental
description: |
    Detects a successful device code sign-in for the Microsoft Authentication Broker client. Microsoft reported
    Storm-2372 switching to this client so the stolen token could register an attacker device and obtain a
    Primary Refresh Token.
references:
    - https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.persistence
    - attack.t1098.005
    - attack.credential-access
    - attack.t1528
logsource:
    product: azure
    service: signinlogs
detection:
    selection:
        AuthenticationProtocol: 'deviceCode'
        AppId: '29d9ed98-a469-4536-ade2-f981bc1d605e'
        ResultType: '0'
    condition: selection
falsepositives:
    - Rare legitimate device registration from input-constrained devices
level: high

Entra ID Protection Attacker in the Middle detection

title: Entra ID Protection Attacker in the Middle Risk Detection
id: 5f1d5805-54a6-4ce5-843a-5b0365284cef
status: experimental
description: |
    Detects the Entra ID Protection "Attacker in the Middle" user risk detection, raised when an authentication
    session is linked to a malicious reverse proxy such as VoidProxy. Microsoft sets the user risk to high.
references:
    - https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.credential-access
    - attack.t1557
    - attack.t1539
logsource:
    product: azure
    service: riskdetection
detection:
    selection:
        riskEventType: 'attackerinTheMiddle'
    condition: selection
falsepositives:
    - Unlikely
level: high

SigmaHQ already covers anomalousToken, tokenIssuerAnomaly, unfamiliarFeatures and suspiciousBrowser with rules in rules/cloud/azure/identity_protection/. Enable those alongside this one.

Microsoft device login page opened from a non-Microsoft page

title: Microsoft Device Code Login Page Opened From External Referrer
id: bde1a3fb-1e50-40d1-9545-adef48319f1d
status: experimental
description: |
    Detects a browser request to Microsoft's device code login pages where the referring page is not a Microsoft
    site. Device code phishing pages, including the fake event pages that use Kali365, open the real device login
    page from the attacker's domain.
references:
    - https://pushsecurity.com/blog/ai-themed-fake-event-campaign-analysis
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.initial-access
    - attack.t1566.002
logsource:
    category: proxy
detection:
    selection_devicelogin:
        cs-host:
            - 'microsoft.com'
            - 'www.microsoft.com'
        c-uri|contains: '/devicelogin'
    selection_deviceauth:
        cs-host: 'login.microsoftonline.com'
        c-uri|contains: '/oauth2/deviceauth'
    filter_main_ms_referrer:
        cs-referrer|contains:
            - '.microsoft.com'
            - '.microsoftonline.com'
            - '.office.com'
            - '.microsoft365.com'
            - '.live.com'
    filter_main_empty_referrer:
        cs-referrer: ''
    condition: 1 of selection_* and not 1 of filter_main_*
falsepositives:
    - Internal documentation or IT portals linking to the device login page
    - Proxies that only see the host name of TLS traffic cannot evaluate this rule
level: medium

The next two rules are specific to the November 2026 AI events campaign. They are useful for retro-hunting, but expect the operator to change domains and paths.

Fake event registration page URL pattern

title: Fake Event Registration Page URL Pattern (MSDRoot Kit)
id: 543e15ce-accf-4cde-aa99-4a602aad3b21
status: experimental
description: |
    Detects requests matching the URL structure of the fake OpenAI, SpaceX and Anthropic event pages documented by
    Push Security, <brand>.eventrsvp.app/event/<brand>/id<11 digits>/rsvp/ with live and join variants.
references:
    - https://pushsecurity.com/blog/ai-themed-fake-event-campaign-analysis
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.initial-access
    - attack.t1566.002
    - detection.emerging-threats
logsource:
    category: proxy
detection:
    selection:
        c-uri|re: '/event/[a-z0-9-]+/id[0-9]{11}/(rsvp|live|join)/'
    condition: selection
falsepositives:
    - Unknown
level: high

DNS lookups for recent event phishing domains

title: DNS Query for Fake Event Phishing Campaign Domains
id: 345c0a64-ba77-447b-a93f-e3eff8bfe483
status: experimental
description: |
    Detects DNS queries for lure, proxy and backend domains published by Push Security for the fake event phishing
    campaign (ZoomMock and MSDRoot kits, Kali365 and VoidProxy infrastructure), May to November 2026. The operator
    rotates domains every few weeks, so use this rule for retro-hunting as much as alerting.
references:
    - https://pushsecurity.com/blog/ai-themed-fake-event-campaign-analysis
    - https://cofense.com/blog/would-your-employees-join-a-fake-anthropic-ai-preview
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.initial-access
    - attack.t1566.002
    - detection.emerging-threats
logsource:
    category: dns
detection:
    selection:
        query|endswith:
            - 'eventrsvp.app'
            - 'rsvpconnect-events.com'
            - 'claudewebinnar.com'
            - 'ggleventapi.icu'
            - 'logins-offcevents.icu'
            - 'wbdssologin.app'
            - 'ggkiejl.icu'
            - 'officegocrqb.com'
            - 'offcevent-login.com'
            - 'com-access-sharepoint.com'
            - 'gle-access-eventregister.icu'
            - 'workportalsso.com'
            - 'careersggl.icu'
            - 'gfmzrsj.icu'
            - 'ggolshhk.icu'
            - 'us968web-zoom.us'
            - 'us956web-zoom.us'
            - 'ssomeetingportal.com'
            - 'ssoeventportal.com'
            - '62zr4vcasl.shifts.icu'
            - 'ydgjgdbhoa.shifts.icu'
            - 'rnacj.iceagelandforms.surf'
            - 'clqzwd4jqw.emptytownmoon.de'
            - 'eventrsvp-217-60-102-48.sslip.io'
    condition: selection
falsepositives:
    - Security researchers and threat intelligence tooling
level: high

Inbox rule hiding security warnings

title: Microsoft 365 Inbox Rule Hiding Phishing or Security Messages
id: c0961f1c-4ef3-4621-a281-5f6ea289dd6d
status: experimental
description: |
    Detects creation or change of an inbox rule that deletes, moves or marks as read mail mentioning phishing,
    spam or account compromise. Kali365 operators create rules like this after device code phishing so the victim
    does not see warnings from colleagues.
references:
    - https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.stealth
    - attack.t1564.008
logsource:
    product: m365
    service: audit
    definition: 'Requirements: Parameters is a list of name and value pairs. Map it to the Value field to avoid broad matches'
detection:
    selection_operation:
        Operation:
            - 'New-InboxRule'
            - 'Set-InboxRule'
            - 'UpdateInboxRules'
    selection_action:
        Parameters|contains:
            - 'DeleteMessage'
            - 'SoftDeleteMessage'
            - 'MoveToFolder'
            - 'MarkAsRead'
    selection_keywords:
        Parameters|contains:
            - 'phish'
            - 'spam'
            - 'hacked'
            - 'compromised'
            - 'suspicious'
    condition: all of selection_*
falsepositives:
    - Users filtering vendor newsletters that mention spam
level: high

Google Workspace hijacked session

title: Google Workspace Session Ended for Suspicious Cookie or Account Hijacked
id: 402279db-d0d9-4c89-ae9e-3502256ca29f
status: experimental
description: |
    Detects Google Workspace login audit events where Google signed a user out because of a suspicious session
    cookie or disabled the account as hijacked. AiTM kits such as VoidProxy steal Google session cookies.
references:
    - https://developers.google.com/workspace/admin/reports/v1/appendix/activity/login
    - https://www.okta.com/blog/threat-intelligence/uncloaking-void-proxy/
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.credential-access
    - attack.t1539
    - attack.t1557
logsource:
    product: gcp
    service: google_workspace.login
detection:
    selection:
        protoPayload.serviceName: 'login.googleapis.com'
        protoPayload.metadata.event.eventName:
            - 'user_signed_out_due_to_suspicious_session_cookie'
            - 'account_disabled_hijacked'
    condition: selection
falsepositives:
    - Unlikely
level: high

SigmaHQ’s existing gcp_gworkspace_suspicious_login rule covers suspicious_login and related events with the same log source.

Short-link and logout-redirect chain to a new domain

title: Logout Redirect From X to Google Short Link
id: dbdf6764-f08c-488d-bb27-0ba3d70d2683
status: experimental
description: |
    Detects use of the x.com logout redirect parameter to send a browser on to a Google short link, a redirect
    chain seen in the fake event phishing campaign to get past URL reputation checks. Threat hunting rule.
references:
    - https://pushsecurity.com/blog/ai-themed-fake-event-campaign-analysis
author: ThreatDefence
date: 2026-11-06
tags:
    - attack.initial-access
    - attack.t1566.002
    - detection.threat-hunting
logsource:
    category: proxy
detection:
    selection_logout:
        cs-host:
            - 'x.com'
            - 'twitter.com'
        c-uri|contains|all:
            - '/logout'
            - 'redirect_after_logout='
    selection_target:
        c-uri|contains:
            - 'c.gle'
            - 'share.google'
            - 'zpr.io'
    condition: all of selection_*
falsepositives:
    - Unknown, the logout redirect is rarely used by legitimate links
level: medium

What blue teams can do this week

1. Run Hunt 1 and list every user who signed in with device code in the last six months.
2. Create the device code block policy in Report-only, review a week of results, then enforce it.
3. In Google Workspace, set calendar invitations from known senders only. In Microsoft 365, make sure your phishing removal process uses Hard Delete so calendar entries go too.
4. Run Hunts 4 and 10 for event lures and external calendar invites, and Hunts 2, 5 and 6 for signs that a session was stolen.
5. Run Hunt 11 for ClickFix commands pasted after a fake meeting.
6. For every hit, run Hunt 8 and follow the response steps below.
7. Deploy the Sigma rules or equivalent analytics for device code sign-ins, Attacker in the Middle and inbox rules that hide warnings.
8. Move administrators and the most targeted groups to phishing-resistant MFA.
9. Send staff the five rules above.

Responding to a compromised account

Microsoft 365 and Entra ID

1. Revoke all sessions and refresh tokens (Revoke sessions in the Entra admin center, or revokeSignInSessions in Graph), then reset the password.
2. Delete devices the attacker registered to the user. A Primary Refresh Token on an attacker device survives a password reset until the device is removed.
3. Remove MFA methods the user did not add.
4. Remove inbox rules, forwarding and mailbox delegations added since the sign-in.
5. Review and revoke app consents granted since the sign-in. A consented app keeps access after a password reset.
6. Work out what was accessed from MailItemsAccessed, SharePoint and OneDrive file events, and sign-ins to SSO apps.
7. Remove the invitation for everyone who received it, including the calendar entries, and look for internal phishing sent from the account.

Google Workspace

1. Sign the user out of all sessions and reset the password in the Admin console.
2. Revoke OAuth tokens for apps the user did not knowingly authorize.
3. Remove Gmail filters, forwarding addresses and delegates added since the sign-in.
4. Re-enroll 2-Step Verification with a passkey or security key.

If the victim ran a command or installer from a fake meeting, treat the device as compromised: isolate it, collect the evidence, rebuild it, and rotate every password, session and key that was used on it, including browser-saved credentials and crypto wallets.

Indicators from recent campaigns

Event phishing infrastructure changes every few weeks, so these indicators are for searching back through logs, not for blocking the next campaign. The behavior-based hunts above will catch that. Most come from the November 2026 AI events campaign. Kali365 and VoidProxy hosts may serve other customers of those services.

On November 6, 2026, VirusTotal showed eventrsvp[.]app flagged by 13 engines and rsvpconnect-events[.]com by 14, but claudewebinnar[.]com by only 1 and the collection server IP by none. A day later the counts were 17, 15 and 3, and 2 engines flagged the IP. Reputation alone would have let most of this through at first. On November 7 these domains, wbdssologin[.]app and 62zr4vcasl.shifts[.]icu still resolved behind Cloudflare, so alert on them as well as hunting back.

Frequently Asked Questions

What is event invitation phishing? Phishing that uses an invitation to a webinar, conference, meeting, product preview or party as the lure. The registration or join step then steals the account, grants an app access, or gets the victim to run malware.

Does MFA stop it? Not the usual kinds. With device code phishing the victim completes MFA on Microsoft’s real site for the attacker, and an AiTM proxy relays the MFA prompt and keeps the session cookie. Phishing-resistant MFA stops AiTM, and blocking device code flow stops device code phishing.

The email came from Eventbrite, Luma or GoTo Webinar. Isn’t that safe? No. Attackers create accounts on those platforms and send through them, so the email is genuine even though the event is not.

Why does the meeting stay on my calendar after the email was deleted? Outlook and Google Calendar add invitations to the calendar when they arrive. In Microsoft 365, a Hard Delete remediation removes the calendar entry too. In Google Workspace, set invitations to be added only from known senders.

The sign-in was on microsoft.com. How is that phishing? In device code phishing the attacker starts the sign-in and gives the victim the code. Entering it on Microsoft’s real page authorizes the attacker’s session.

Does resetting the password remove the attacker? Not on its own. Revoke sessions and refresh tokens, delete devices the attacker registered, remove MFA methods and app consents they added, and then reset the password.

Can we block device code flow without breaking anything? Usually, with a short exception list for meeting room devices and some administrator tools. Run the Conditional Access policy in Report-only for a week first.

How do we check our own past exposure? Run Hunt 1 for device code sign-ins, Hunts 4 and 10 for event lures and calendar invites, and Hunt 9 for the recent campaigns’ domains. Then run Hunt 8 for each user found.

How ThreatDefence is responding

ThreatDefence has added the recent campaigns’ indicators to our threat intelligence. Where we hold Microsoft 365, Entra ID, Google Workspace, email, endpoint and network telemetry, our SOC is:

• hunting device code sign-ins, stolen-session reuse and Attacker in the Middle detections
• alerting on device code sign-ins outside each customer’s known exceptions, device registration after device code sign-ins, and inbox rules that hide security mail
• watching for ClickFix commands and unapproved meeting-app installers on endpoints
• helping customers roll out the device code block and calendar controls

If you want help checking your tenant or responding to a compromised account, contact us. Read more about our identity threat detection and response and Microsoft Sentinel MDR.

Sources

• Push Security, Analyzing a fake event campaign combining AiTM and device code phishing payloads (November 5, 2026)
• Cofense, Would your employees join a fake Anthropic AI preview? (October 29, 2026)
• Check Point, Fake calendar invites target thousands of organizations in Microsoft credential phishing campaign (October 15, 2026)
• Cisco Talos, UAT-11985: AI-assisted event lures delivering real-time Google AitM phishing (October 8, 2026)
• Microsoft Threat Intelligence, Star Blizzard refines phishing and malware delivery with the RedFlick technique (September 29, 2026)
• Cofense, You’re invited to get phished: why invitation-themed emails remain effective (August 12, 2026)
• ANY.RUN, Major cyber attacks in July 2026 (August 4, 2026)
• Malwarebytes, Fake Google and Cloudflare verification pages spread multiple malware families (July 2, 2026)
• Arctic Wolf, BlueNoroff uses ClickFix, fileless PowerShell and AI-generated fake Zoom meetings to target Web3 sector (April 27, 2026)
• Arctic Wolf, Token Bingo: don’t let your code be the winner (April 24, 2026)
• Mandiant, UNC1069 targets cryptocurrency sector with new tooling and AI-enabled social engineering (February 10, 2026)
• Volexity, Dangerous invitations: Russian threat actor spoofs European security events in targeted phishing attacks (December 4, 2025)
• IRONSCALES, Fake AI conference, real authentication: how attackers weaponized Lu.ma to bypass every email check (November 25, 2025)
• Kaspersky, BlueNoroff’s latest campaigns: GhostCall and GhostHire (October 28, 2025)
• Okta Threat Intelligence, Uncloaking VoidProxy (September 11, 2025)
• Microsoft Threat Intelligence, Storm-2372 conducts device code phishing campaign (February 13, 2025)
• Volexity, Multiple Russian threat actors targeting Microsoft device code authentication (February 13, 2025)
• Check Point, Google Calendar notifications bypassing email security policies (December 17, 2024)

• Perception Point, You’re invited: rampant phishing abuses Eventbrite (October 28, 2024, archived copy)

• FBI IC3, public service announcement on OAuth consent phishing, I-090126-PSA (September 1, 2026)

• FBI IC3, public service announcement on Kali365, I-052126-PSA (May 21, 2026)
• CISA and partners, Star Blizzard continues worldwide spear-phishing campaigns, AA23-341A (December 7, 2023)

• UK NCSC, UK cyber experts warn of targeted phishing attacks from actors based in Russia and Iran (January 26, 2023)

• Microsoft Learn, Block authentication flows with Conditional Access policy

• Microsoft Learn, What are risk detections? (Entra ID Protection)
• Microsoft Learn, Alert grading for session cookie theft (Defender XDR)
• Microsoft Learn, SigninLogs table reference (Azure Monitor)
• Microsoft Learn, EntraIdSignInEvents table (Defender XDR advanced hunting)
• Microsoft Learn, Token protection in Conditional Access
• Microsoft Learn, Set-CalendarProcessing
• Microsoft Learn, Remediate malicious email delivered in Office 365
• Microsoft Defender for Office 365 blog, Strengthening calendar security through enhanced remediation (November 24, 2025)
• Microsoft Learn, Anti-malware protection in EOP
• Microsoft, Possible device code phishing attempts hunting query (Azure-Sentinel repository)
• Google Workspace Admin Help, Automatically add events to calendars
• Google Workspace Updates, New admin controls for adding invitations to Google Calendar (August 14, 2026)
• Google, Reports API login activity events
• SigmaHQ, Sigma rules repository
• VirusTotal, domain reports for eventrsvp.app, rsvpconnect-events.com and claudewebinnar.com (checked November 7, 2026)