The Calendar Invite Google Signed for the Attacker

One mailbox at a regional orthopedic medical practice group received a Google Calendar invitation. The event title read like a shipping notice, "Invitation: A new version of your Order No. V6EPF7BF has been uploaded," and the event was slotted for an evening in an Atlantic time zone. The description underneath it had nothing to do with orders. It was a fabricated antivirus renewal receipt: a Webroot branded "Premium Protection Membership," a receipt number, an activation key, a membership ID, a placeholder copyright footer, a United States street address, and a charge of USD 466.00 that would process "within the next 24 hours."

There was no link to click. There was no attachment other than the calendar file that carried the event. The only instruction was to call one of two phone numbers.

The interesting part is the header. The message was signed by google.com, and the signature was valid, because Google really did send it. The domain that owned the event failed SPF outright.

The Attacker Filled In a Form Instead of Writing Mail

Nothing in this attack was composed as an email. The operator created a calendar event, typed the lure into the title and description fields, set an organizer address on a domain they controlled, and added the target as an attendee. Everything after that was Google's job. The calendar notification service authored the message, applied its own HTML template, generated a per-recipient RSVP link, and delivered the invitation from calendar-notification@google[.]com.

That removes most of the work and most of the evidence. There is no sending infrastructure to stand up, no HTML to craft, no reputation to warm, and no lookalike domain to register for delivery. The lure text rode into the mailbox in two places at once, inside the description field of the attached calendar file and inside the visible body that Google rendered from it, so the content was plainly readable to anything inspecting the message. Readability was never the constraint. Provenance was the asset.

One Message Carried Two Identities

The authentication summary is where this case earns its own entry. DKIM passed with a google.com signing identity, which is exactly correct, since Google's notifier assembled and sent the mail. A second DKIM signature also passed, this one a Google Workspace signing identity belonging to the organizer domain, which tells you the operator had stood up a Workspace tenant on that domain rather than simply forging a From line.

Then the split. The envelope sender was the organizer domain, gedalias[.]net, while the transmitting address was inside a Google range that this domain had never authorized in its own SPF record, so SPF returned a hard fail. The organizer domain published no DMARC policy at all, so the failure carried no enforcement and no report. Composite authentication still resolved in the message's favor and the gateway landed on a mid-range spam score: the identity with reputation had signed cleanly, and the one that wrote the content had no policy to be judged against.

Alignment as defined in RFC 7489 answers one narrow question: did a domain authorize this message. Google authorized it. The organizer domain did not authorize itself and asked nobody to care. A control that stops at the strongest passing signature will read this as trusted Google mail every time, which is the whole reason the technique is worth an operator's time. MITRE ATT&CK tracks the pattern as adversary use of legitimate web services rather than as spoofing, and it deserves that separate slot.

The organizer domain is worth one more note: it was not registered the morning of the attack. Registration predates the campaign by years, through a mainstream registrar, behind a privacy shield, so every heuristic keyed to newly observed domains stays quiet. Aged and dormant is now an ordinary acquisition.

The Payload Was Ten Digits, Listed Twice

Strip the calendar mechanics away and what is left is a renewal scam with a phone number. One number was presented as a customer contact line and repeated for emphasis, a second as a service line, and neither was accompanied by a single URL. That makes this telephone-oriented attack delivery, mapped by MITRE ATT&CK as spearphishing voice and known to defenders as callback phishing or a vishing attack.

For an inspection pipeline this is close to a blank page. No URL to detonate, no macro to unpack, and a calendar file that hashes clean because calendar files are not malicious. The pressure comes from copy, not code: a specific amount, a receipt that appears to already exist, and a 24 hour deadline. The fraud happens on the call, where an operator handles objections live and steers toward remote access, a card capture framed as cancelling the charge, or a bogus refund walked through the victim's own banking portal. The 2024 Verizon Data Breach Investigations Report puts a human element in 68 percent of breaches, and a lure with no payload reduces the surface to that element alone.

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

One overlooked detail: the RSVP link Google generates is unique per attendee. If the recipient responds to the invitation at all, the operator learns the mailbox is live and monitored, on real Google infrastructure, without ever hosting a tracker.

What Flagged It Was the Mismatch

With no artifact to analyze, the evaluable material was identity and behavior. Themis, the IRONSCALES Adaptive AI analyst, weighed a first-time organizer against a two-word personal alias claiming a consumer security brand, a hard billing deadline nobody had authorized, two phone numbers as the sole call to action, and a signing identity that did not match the party who wrote the content. It labelled the message a vishing attack at 64 percent confidence and tagged both the sender and the message as suspicious. An analyst confirmed the verdict and the affected mailbox was quarantined.

A mid-range confidence figure is what a payload-free case honestly looks like. With no domain age to punish, no URL verdict to inherit, and no attachment to detonate, the score reflects a relationship judgment rather than a lab result, and the analyst closing the loop is part of the control rather than a sign it failed.

What To Take From This Case

Treat calendar invitations as mail, because they are mail, and treat the organizer as a trust decision separate from the notifier that delivered them. Two rules pay for themselves. Evaluate every authentication result in a message rather than the best one, and alert when an envelope domain hard-fails SPF with no DMARC policy even where the wrapper is a provider you trust. Then put invitation events and their organizers in the same inspection path as inbound mail, which is the practical argument for augmenting Google Workspace rather than assuming provider notifications are self-policing.

Then give people one instruction for unsolicited billing notices, whether they arrive as mail or as an event on the calendar: never dial the number in the message. Look the vendor up independently, then report the message. A callback lure only pays if somebody calls.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

The strongest signature in a message tells you who put it on the wire. It does not tell you who wrote what is inside. Check back tomorrow.