The Fake Webroot Renewal Hiding in a Calendar Invite

The most convincing thing about this phishing attack is that it never looked like an email. It arrived in the target's mailbox as a Google Calendar invitation, sent through Google's own calendar-notification service, with a subject line that read like an automated request confirmation. The recipient, an employee at a mid-size company, was not being asked to open an attachment or click a suspicious link. They were being invited to an event.

The event was a $525.88 bill.

Written into the calendar entry was a fabricated Webroot antivirus renewal notice, complete with an activation key, a client ID, and a support phone number to call and "confirm" the charge. No malware. No credential form. Just a piece of manufactured urgency riding inside a container that most security tooling, and most people, treat as harmless.

A Renewal Nobody Signed Up For

Webroot is a real, recognizable security vendor, which is exactly why its name was borrowed here. The attacker wrapped the whole lure in that brand: an antivirus subscription supposedly expiring, a specific dollar figure to make it feel like a real invoice, and reference numbers to lend it the texture of a genuine billing record. The only action the message offered was human. Call this number. Confirm the payment. Sort out the charge before it processes.

That is the tell, once you know to look for it. There is no button to a lender, no fake Microsoft login, no document to sign. The payload is a phone call. Pushing the victim off email and onto a voice channel is a deliberate move, because a live conversation lets the attacker improvise, apply pressure, and walk a worried caller toward a card number or a remote-access session. It is the same playbook as vishing, just seeded from a calendar entry instead of a cold call.

Why Every Link Scanned Clean

Here is the part that should worry any security team leaning on link reputation. Every clickable link in this message pointed to calendar.google[.]com. They were the standard RSVP and event-response URLs that Google generates for any invite, of the form calendar.google.com/calendar/event?action=RESPOND&...&tok=.... Scanned in isolation, they are perfectly clean, because they are perfectly legitimate.

The attached invite.ics file, the calendar container that carried the fraudulent event, also scanned clean. It is a benign file format doing exactly what it is designed to do. There was no malicious URL to detonate, no attachment signature to match, no infrastructure to blocklist. The fraud lived entirely in the free-text fields of the event, which no URL scanner or attachment sandbox is built to read for intent. This is the whole point of abusing a trusted collaboration tool: the platform does the delivery, and the malicious content hides in a place automated inspection does not look.

The Authentication That Was Not There

The sender side tells the rest of the story. The From address spoofed a real, GoDaddy-registered domain that has existed since 2013, an aged and otherwise unremarkable organization whose identity was borrowed without its knowledge. Spoofing an established domain is cheap when that domain never locked its own front door.

The authentication results were about as weak as they get. SPF was none, meaning the real domain never published a record designating who is allowed to send on its behalf. DKIM failed on a body-hash mismatch. DMARC was none, so there was no policy instructing receivers to reject the forgery. On a normal path, that trio would have sunk the message. What kept it afloat was the relay. Because the invite transited Google's legitimate calendar-notification infrastructure, the Microsoft 365 edge logged a compound-authentication pass, and the message inherited enough trust from the delivery mechanism to land. It was ultimately quarantined, but only after manual review, not because the auth stack caught it on arrival.

Mapping to MITRE ATT&CK

The tradecraft lines up with a handful of techniques in the MITRE ATT&CK framework:

• T1566.002 Spearphishing Link and T1204.001 User Execution: Malicious Link cover the delivery and the intended interaction, even though the "link" here doubles as an RSVP and the real call to action is a phone number.
• T1585.001 Establish Accounts covers the abuse of a legitimate calendar and notification service as the sending vehicle, turning trusted infrastructure into the attacker's distribution channel.

Indicators of Compromise

Detection and What to Watch For

Static defenses were never going to win this one. The infrastructure is Google's, the attachment is benign, and the links are real. Detection has to move to behavior and context. The signals that matter are an unsolicited calendar invite from a first-time sender, a payment demand and reference numbers sitting in an event body, a sender domain with no functioning authentication, and a phone number as the only real call to action.

This is where behavioral analysis earns its keep. Themis, the Adaptive AI analyst on the IRONSCALES platform, reads the relationship between the claimed brand, the actual sender, and the intent expressed in the content, the way a trained analyst would, rather than waiting for a URL or hash to turn malicious. The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and names pretexting, largely business email compromise, as the top social-engineering incident type. The Microsoft Digital Defense Report 2024 documents the same shift toward abusing trusted services instead of breaking them, and the FBI's 2023 Internet Crime Report lists tech-support and impersonation fraud among the most damaging categories, which is exactly the lever a fake antivirus renewal pulls.

See Your Risk: Calculate how many threats your SEG is missing

Serving 35,000+ security professionals across 17,000+ organizations, we see this class of trusted-infrastructure abuse constantly, and calendar-borne lures are a growing slice of it. Extending inspection to collaboration tool traffic, not just the inbox, is how you close the gap this campaign walked through.

The Takeaway

Attackers follow trust, and right now trust points at the tools we barely question. A calendar invite feels like a scheduling nicety, not an attack surface, so a fabricated bill inside one slides past both the scanner and the reflex to be skeptical. The defense is a simple rule that scales to a whole team: no legitimate security vendor collects a renewal through a calendar event, and no real charge is ever resolved by calling a number pasted into an invite. Verify billing on the vendor's own site or through a known contact, treat unsolicited invites as suspect, and pair that habit with detection that reads intent rather than infrastructure. CISA's guidance on recognizing and stopping phishing early is a solid reference for building that reflex: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one