The new phishing campaign weaponizing Google + Outlook calendar invites — credential theft, OTP interception, and RMM in one click.

# The new phishing campaign weaponizing Google + Outlook calendar invites — credential theft, OTP interception, and remote-management software in one click

GBHackers and a handful of corporate IR teams broke a campaign this morning (May 6, 2026) that I want every IT operator to read before lunch: a large-scale phishing campaign is using fake event invitations — sent through legitimate Google Calendar and Outlook scheduling APIs — to land credential theft, intercept time-based one-time passwords, and ultimately drop a remote monitoring and management tool on the victim's box. The campaign is targeting U.S. organizations specifically. The end-state is full-employee-workstation takeover wearing the costume of "your CFO scheduled a quick sync."

This is not a generic phishing email. It bypasses the familiar gut-check ("don't click suspicious links") because the invite arrives via the calendar API, lands in your real calendar, fires a real notification on your phone, and the sender appears to be your real CEO/CFO/HR Director — because the attacker has impersonated their From: field on a calendar object the recipient's inbox already trusts. By the time the invite is on your screen, the phishing layer has already won the framing battle. The credential-theft layer comes next, the OTP interception after that, and the RMM payload last. All in a single workflow that takes the victim less than two minutes to walk through.

I'm writing this up the same way I write up every active campaign: detection commands first, mitigations you can ship today, training points for your users, and the IR response if it's already in your environment.

#Why calendar invites bypass everything you're used to

Phishing-aware users have been trained — slowly, painfully, over fifteen years — to look for a few things:

• "Does the sender domain match the company they claim to be from?"
• "Does the URL hover-preview look legitimate?"
• "Is the language urgent, threatening, or out-of-context?"

Calendar invites in 2026 break every one of those gut-checks:

• The sender domain is real. Not because the attacker compromised it (sometimes they have, but the campaign also works without compromise) but because the calendar invite is sent through Google's calendar-noreply@google.com or Outlook's noreply@microsoft.com infrastructure. The "From the actual CFO" line is rendered in the body of the calendar object, not in the SMTP envelope.
• The URL is masked by Google/Microsoft's own click-tracking redirector. A user hovering the "Join meeting" link sees a meet.google.com/... or teams.microsoft.com/... URL, even when the redirect lands on the attacker's lookalike portal.
• The language is not urgent. It's organic. "30-minute sync re: Q2 budget" looks like a normal calendar artifact. The recipient walks into it expecting a meeting, not a defense posture.

The campaign's three landing-page variants observed so far:

1. Microsoft 365 sign-in lookalike. Hosted on a freshly-registered domain with a wildcard TLS cert. The page captures username + password + the TOTP code from the Authenticator app. It then performs the actual sign-in to the real M365 in real time, capturing the session cookie via a tool like evilginx2 or its descendants.
2. Google Workspace sign-in lookalike. Same architecture, targeting accounts.google.com flow. Particularly nasty because Google Workspace TOTP setups push back on hardware-key flows but have a fallback to TOTP that this campaign exploits.
3. "Click here to join the call" → RMM installer. The fallback if the credential-phishing flow stumbles. The page tells the user "to join the meeting, please install the secure conferencing client." The download is a signed installer for one of Atera, ConnectWise ScreenConnect (renamed to look like a Microsoft product), TeamViewer Host, or Splashtop. Once the agent is installed, the attacker has full unattended remote control of the workstation.

The OTP interception layer means traditional MFA does not save you. The RMM layer means even an MFA-savvy victim who only made it as far as "click here to join" still gets popped if they hit the install button. The campaign monetizes both.

#What "RMM as a phishing payload" actually means

Remote monitoring and management tools are normally a sign of a competent IT shop. Atera, NinjaOne, ConnectWise, TeamViewer, Splashtop — these are the platforms small-shop IT uses to push patches, run scripts, troubleshoot user workstations from miles away. They're trusted, they're signed, and they have full administrative control over the machine they run on.

Threat actors love them because:

• They're signed. Microsoft Defender, every commercial EDR, and most application-allowlisting policies treat ConnectWise and TeamViewer as trusted by default.
• They're persistent. The agent installs as a Windows service that runs at boot. Persistence is built in.
• They're remote-accessible. Once installed, the attacker has unattended access from anywhere in the world.
• They're "legitimate enterprise software." Forensic analysts who see TeamViewer in a process list don't always blink. It looks like normal IT.
• They're easy to redistribute. The MSI installer is signed, and the operator just needs to wrap it in a small loader that pre-configures the agent to call home to the attacker's instance instead of a normal MSP.

Once the RMM agent is in, the rest of the kill chain is conventional: Mimikatz / LSASS dump for credential collection, RDP / PowerShell remoting for lateral movement, ransomware or data exfil for monetization. The interesting part is the entry vector — calendar invite → RMM agent — because most enterprise security stacks were not designed to detect that path.

#Detection commands and queries — run these in your environment today

If you operate a Microsoft 365 or Google Workspace tenant, these queries will surface the campaign if it's already in your environment.

#M365: hunt for unauthorized calendar invites from external senders

# Connect to Exchange Online
Connect-ExchangeOnline

# Find calendar invites from external senders in the last 14 days that contain
# common social-engineering keywords. Adjust the date range and keyword list
# for your environment.
Search-MailboxAuditLog -StartDate (Get-Date).AddDays(-14) -EndDate (Get-Date) `
    -ShowDetails -ResultSize Unlimited |
    Where-Object {
        $_.Operation -eq 'Create' -and
        $_.ItemSubject -match '(sync|review|quick chat|budget|strategy|pricing|payroll|merger|acquisition)'
    } | Format-Table UserIds, ItemSubject, OperationProperties

#M365: hunt for new RMM agents installed in the last 14 days

If you have Defender for Endpoint, Microsoft Defender XDR, or Sentinel:

DeviceProcessEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("msiexec.exe", "explorer.exe")
| where ProcessCommandLine has_any (
    "atera_agent",
    "ConnectWiseControl",
    "ScreenConnect",
    "TeamViewer_Host",
    "splashtop_streamer",
    "AnyDesk",
    "NinjaRMM"
)
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, FolderPath
| sort by Timestamp desc

#Google Workspace: hunt for OAuth grants to unfamiliar applications

Calendar-invite phishing sometimes pivots to OAuth abuse — the lookalike landing page asks the user to grant an OAuth-scoped app access to their account, bypassing password+TOTP entirely.

admin.google.com → Security → API Controls → Domain-wide Delegation → Trusted Apps

Look for any app added in the last 30 days that you don't recognize. Then check the granted scopes — anything with https://mail.google.com/ (full Gmail access) or https://www.googleapis.com/auth/admin.directory.user (admin directory) is a smoking gun.

#Endpoint: hunt for unauthorized scheduled tasks

The RMM payload often persists by adding a scheduled task as a fallback to the service.

# Run on each workstation; or push via your existing remote-execution tooling.
Get-ScheduledTask | Where-Object {
    $_.TaskPath -notmatch '^\\Microsoft\\' -and
    $_.State -ne 'Disabled' -and
    $_.Date -gt (Get-Date).AddDays(-14)
} | Select TaskName, TaskPath, Date, Author, State

#Network: hunt for outbound connections to common RMM C2 endpoints

Most RMM tools call home to a small set of known endpoints. If you see them in your egress logs and you don't have a corresponding internal IT relationship, that's the signal.

Common known-good endpoints to allowlist if you DO use them, and red-flag if you DON'T:

• ConnectWise / ScreenConnect: *.screenconnect.com, *.connectwise.com
• TeamViewer: *.teamviewer.com, dyngate.com
• AnyDesk: *.anydesk.com, *.net.anydesk.com
• Atera: *.atera.com, *.aterasso.com
• NinjaRMM: *.ninjarmm.com, app.ninjarmm.com
• Splashtop: *.splashtop.com, *.splashtoplive.com

A flow to one of those that doesn't correspond to a known IT engagement is the campaign in your environment.

#Mitigations you can ship today

#Block external calendar invites at the inbound mail layer (the cleanest fix)

In M365, Exchange Online has a transport rule capability that can drop or quarantine inbound calendar messages from external senders. Most enterprises are reluctant to do this because they have legitimate calendar invites from vendors, customers, and contractors — but you can scope it to the high-risk subset:

• Drop calendar invites from external senders to executives in the C-suite group.
• Drop invites where the meeting subject matches social-engineering keyword lists.
• Drop invites where the embedded link goes to a domain that doesn't match the sender's domain.

Sample Exchange Online transport rule (PowerShell):

New-TransportRule -Name "Quarantine Suspicious Calendar Invites" `
    -SentToMemberOf "Executive Team" `
    -FromScope "NotInOrganization" `
    -MessageTypeMatches "Calendar" `
    -Quarantine $true `
    -Mode Enforce

#Mandate hardware security keys for executives and finance

YubiKey or equivalent FIDO2 keys break the OTP-interception layer. The lookalike landing page can capture username + password + TOTP code, but it cannot capture the cryptographic challenge-response from a hardware key. If your executives and finance team aren't on hardware keys yet, this campaign is the one that finally moves you to do it. Cost: $50 per user, deployable in a week.

#Deploy app-allowlisting on workstations

Microsoft AppLocker or Windows Defender Application Control configured in audit mode for two weeks, then enforce mode, will block the RMM installer dead on the workstation. Yes, it's annoying. Yes, your IT team will spend a quarter implementing it. But "the user clicked install on a TeamViewer that wasn't yours" is the exact threat model app-allowlisting was built for.

#Sender-policy-framework / DMARC / DKIM enforcement, properly

If your domain is valtikstudios.com and an attacker sends a calendar invite that *claims* to be from ceo@valtikstudios.com but routes through Google Calendar's infrastructure, your inbound mail server should be able to detect the spoofing. The condition is that DMARC be set to p=reject (not p=quarantine, not p=none) and that the inbound server actually enforce it. Most organizations have DMARC at p=none (monitor mode). Move it to reject with proper SPF and DKIM coverage of all your legitimate senders, and the spoofing avenue closes.

#User training that focuses specifically on this campaign

The training point is not "don't click suspicious links." Users have heard that. The training point is: if you receive a calendar invite for a meeting you don't expect, from someone you'd normally trust, where the meeting requires you to log in via a "secure portal" or "install a conferencing client," stop and verify out-of-band. Pick up the phone. Slack the person. Do not click. The 30 seconds of friction beats the 30 days of incident response.

#What if you find evidence of compromise?

The same playbook as any post-credential-theft scenario:

1. Disable the user account immediately. Reset password and revoke all session tokens through the Microsoft Graph API or Google Admin SDK. Do not just reset the password — revoke the active sessions.
2. Hunt the lateral movement. Pull authentication logs (Azure AD sign-in logs, Google Login Audit, on-prem AD events 4624/4625/4768/4769) for anomalies in the 7-day window before discovery. Look for sign-ins from unusual geographies, new device IDs, new IP ranges.
3. Forensically image the workstation if RMM was installed. Don't just uninstall the RMM agent. The agent often comes with secondary persistence (scheduled tasks, services, registry run keys). Image, then re-image.
4. Review email forwarding rules. A common post-phish action is to set an Outlook rule that auto-forwards every email to an external address. Hunt for New-InboxRule events in the last 14 days.
5. Notify your finance team and your customer-facing teams. If the attacker used the compromised account to send wire-fraud or vendor-change emails, those go out before you find the compromise. Get ahead of the wire fraud by notifying high-risk recipients before the bank does.

#Why this campaign matters for small businesses specifically

Enterprise IT shops with full SOCs and managed-detection-and-response retainers will catch this campaign. They have the telemetry, the queries, and the playbooks. The victims of this campaign are going to be small businesses — 10 to 200 employees — who run M365 or Google Workspace as their entire stack and don't have a dedicated security team. The user training isn't there. The DMARC isn't enforcing. The hardware keys aren't deployed. The RMM allowlist doesn't exist.

If you're a small-business owner reading this and any of those gaps describe your environment, the math is brutal: a single successful phish in this campaign typically costs the victim $50K to $250K in wire fraud, business interruption, IR costs, and notification costs. The full-stack security upgrade to prevent it costs maybe $5K-$15K in tooling and a one-week consulting engagement to implement.

That is exactly what Valtik does. We help small businesses spot the gaps that this campaign exploits — not by selling you a SIEM you don't need, but by walking through your tenant config, your DMARC posture, your MFA setup, your AppLocker stance, and your user-training cadence in a focused, fixed-price engagement. If this post made your stomach drop, that's the right reaction. Book a free 15-minute scope call at valtikstudios.com/free-check.

---

Sources cited:

• GBHackers: "Phishing Attack Weaponizes Calendar Invites to Steal Login Credentials" (May 6, 2026)
• Microsoft Defender for Office 365 advisory on inbound calendar invite abuse (March 2026 update)
• Google Workspace Security Bulletin GWS-2026-04 (April 2026)
• CISA AA26-117A: "Calendar Invite Pretexting Targeting U.S. Organizations" (April 27, 2026)