Google Calendar Phishing: One Link, Two Scanner Verdicts

Whois puts the landing domain's creation at 17:25:32 UTC. The Google Calendar notification carrying it left Google at 17:54:58 UTC and reached the mailbox one second later.

Twenty-nine minutes and twenty-six seconds, registration to inbox.

That is the number people will remember, and it is not the part that should worry you. The security stack produced two different verdicts about the same destination inside the same message, and the favourable one is the one a user can actually hover.

One destination, two verdicts

Five links in the message were scanned. Two point to the same place.

The bare landing URL, hxxps://voiceml[.]space/?a861af8a, came back with a status of 'Mixed Result' and a verdict of partial, screenshot on file. The other came back 'Clean'. That second URL was hxxps://www[.]google[.]com/url?q=...&sa=D&source=calendar, and the value of q= was the first URL.

Google Calendar rewrites links in an event description into its own redirector before it mails the notification. So the anchor text read 'Listen to voicemail', the href a recipient could inspect was a google.com address served under Google's own certificate, and the destination behind it was a privacy-protected Namecheap registration that had existed for less than half an hour.

Reputation attaches to the string you scan. Scan the wrapper and you are scoring Google. Scan the destination and there is nothing to score yet, which is why the bare URL reached only partial rather than a hard malicious verdict. Twenty-nine minutes is not enough time for anybody to have built a reputation on you.

Nothing here was spoofed

The reflex with a Google-branded lure is to go hunting for header forgery. There is none.

The message arrived from mail-sor-f69.google[.]com at 209.85.220[.]69 into mx.google[.]com. The return path was a bounce address at calendar-server.bounces.google[.]com. DKIM passed with header.i=@google.com, SPF passed, and DMARC passed against a p=REJECT policy with sp=REJECT. The From header read Google Calendar , and the message was marked Auto-Submitted: auto-generated.

All of that is true because Google genuinely sent it. The attacker created a real calendar event, put the lure in the description field, and invited the target. Google's notification service did the rest, including rendering the body from its own template. DKIM authenticated the sender faithfully. The sender was simply the wrong thing to be asking about.

One detail worth flagging: the notification also carried the description text inside a hidden preview block and again in a meta itemprop tag. That is Google's template behaviour on every calendar notification, not attacker obfuscation, and writing it up as evasion would be a false finding.

The sender heuristic was blind by construction

The platform recorded this message with first-time-sender false and prior sender-to-recipient contact true.

Both flags are correct. Google mails this tenant constantly. Every heuristic keyed on the envelope sender, the historical relationship, or the authentication result was working normally and had nothing to say, because the party the attacker borrowed was already trusted.

The one sender-side artefact that pointed anywhere was the Reply-To, which did not match the From. It was set to an unrelated third-party mailbox, and the same address appeared as the event organiser, rendered by Google under its 'Organiser' heading and marked up as a schema.org Person. That address belongs to a small regional franchise business with no apparent connection to the target. Abused and compromised accounts are the ordinary explanation for that pattern, and nothing in the evidence makes that business anything other than another party caught up in it.

The pretext was thin, and it did not need to be thick

Event title: 'New Voice Recording Received'. Description: a voice message was recently recorded in your inbox, 'Listen to voicemail', 'Duration: 0:42 Sec', 'Voice service.' Booked for an evening slot later the same day.

Google's template printed 'Guests (Guest list is too large to display)', which is Google's own suppression threshold rather than a count. One event, enough invitees that Google declined to list them.

Calendar invites as a delivery vehicle are not new, and neither is a voicemail pretext. The two verdicts are. This is spearphishing via link, MITRE T1566.002, with a trusted productivity platform supplying delivery, authentication and the outbound URL. Figure 54 of the 2026 Verizon Data Breach Investigations Report puts plain phishing at 80% of the attacks email gateways block, against 10% malware-laden, 5% callback, and 3% BEC (business email compromise). The low-complexity end of that distribution is where reputation inheritance pays best.

What the domain served is not established. The threat notes record a Cloudflare human-verification interstitial in front of it that blocks automated inspection, so the screenshot on file may be that gate rather than whatever sits behind it. The domain publishes no TXT, DKIM or DMARC records. The verdict is 'Mixed Result' and partial, and that is as far as the evidence goes.

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

Indicators

A person caught this

The recipient reported the message himself, a VIP user at an online entertainment technology firm. The Themis record labelled the message 'VIP Recipient' with the insight that one or more links had been flagged as malicious, naming 'Listen to voicemail' specifically. The malicious verdict on file is a human one, recorded as 'Approved Manually', and the message was mitigated.

That sequence is the honest version of this story. The sender checks were satisfied, one URL scan disagreed with another, and the thing that resolved it was a person who thought a voicemail invitation on his calendar was strange.

The 2026 DBIR puts the human element in 62% of breaches and phishing in 16% of initial access. Those figures usually get read as an indictment of users. Cases like this one read the other way around. IRONSCALES platform data shows 67.5 phishing emails per 100 mailboxes every month, and the 36,000+ security professionals across 18,000+ organizations in the IRONSCALES community are why novel infrastructure gets named in hours. Reported mail is signal.

What to change

Treat platform redirectors as pass-through, never as reputation. If a URL resolves through google.com/url, a marketing click tracker, or any other rewrite service, resolve it and score the destination. A wrapper verdict is a verdict about the wrapper.

Put domain age into the scoring path. A destination registered inside the last hour should not inherit a trusted host's standing no matter what wraps it, which is what CISA's phishing guidance means by breaking the cycle before the click.

Re-key your first-time-sender logic for platform-mediated mail. On a calendar notification the interesting identity is the organiser and the Reply-To, not the envelope sender, and a Reply-To that diverges from a p=REJECT From is worth a flag on its own.

Audit calendar auto-add behaviour in Google Workspace. An attacker who can place an event on a calendar gets an authenticated notification for free.

Then make the reporting path trivially easy for executives, because here it was the control that worked. NIST defines phishing as deception aimed at the person, and the FBI IC3 2024 report counts the losses when it lands. A VIP who reports a strange invite in the first hour is worth more than a second engine that agrees with the first. Two already disagreed here, and only one was looking at the right string.