The Google Calendar Header Was Real. The Invite Was Not.

A calendar invitation arrived in a dozen mailboxes at once. The recipients were attorneys at unrelated law firms with no connection to each other beyond a shared professional membership, plus one contact at an insurance brokerage. The invite announced a board meeting for a regional bar association, a one hour midday slot, with an agenda document and a set of prior meeting minutes linked in the body and a routine invite.ics attachment. One of the recipients reported it and tagged it as an impersonation attempt.

Every control that inspects content passed the message. Roughly thirty URLs were scanned and all of them came back clean. The attachment came back clean. DKIM validated. Composite authentication passed. There was no landing page, no credential form, and nothing to detonate, because none of that was present. What was wrong with this message lived entirely in its identity structure.

The Platform Header Was Genuine

Mail carries two separate notions of who sent it. There is the author, which is the visible From, and there is the submitting agent, which is what a Sender header records when the two differ. Google Calendar populates that second header with its own notification address on every invite it dispatches. It is boilerplate plumbing, applied uniformly.

This message carried that header, and it was not forged. The invite really had been created in Google Calendar and pushed out by Google Calendar, so the platform stamped its own notification address on the way through, exactly as designed.

That is the part worth sitting with. A header that reads like a strong provenance signal was in fact one of the weakest claims in the message. It says which system relayed the bytes. It says nothing about who booked the meeting, because it is inherited automatically by anybody with an account on the platform. Read as identity evidence, it is inherited trust, and a technique catalogued in MITRE ATT&CK as establishing cloud accounts is all it takes to acquire.

From and Reply-To Sat on a Domain With No SPF Record

Underneath the platform header, the visible From used a personal-sounding first-and-last-name alias at a domain that had nothing to do with any bar association. The Reply-To carried a different personal-name alias, on a different mailbox, at that same domain. So the message presented three identities at once: a calendar platform in the submission header, one individual as the author, and a second individual as the person any reply would reach.

The authentication results on that domain are the interesting half. SPF returned none. Not a soft fail, not a hard fail. The domain publishes no SPF record at all, so there was no policy for a receiving system to evaluate. DMARC was likewise absent, so there was no alignment requirement and no disposition to apply. DKIM passed on two selectors, one belonging to the platform and one belonging to the attacker domain's own cloud tenant, which confirmed only that whoever controlled the domain had authorized the send. Composite authentication passed on implicit signals.

Absence is the quiet option. A domain that publishes a policy and then violates it produces a fail that filters can score. A domain that publishes nothing produces a shrug. That asymmetry is why the DMARC specification treats a missing record as no policy rather than as a negative result, and why DMARC management and monitoring matters as much for reading inbound records as for protecting your own.

Nothing In The Message Was Malicious

The link inventory deserves specifics, because it is the reason payload analysis had no purchase here. The agenda and prior-minutes links pointed into a genuine association document tenant. There was a video conference join link. The rest were the response and view-in-calendar links the platform appends to every invite. All clean, every one.

This is what a pretext-first message looks like. There is no infrastructure to reputation-check, no redirect chain to unwind, no attachment to sandbox. The 2024 Verizon Data Breach Investigations Report puts pretexting at the top of the social engineering categories it tracks, ahead of payload delivery, and content inspection is structurally blind to a message whose only false statement is who it came from. Both CISA phishing guidance and the NIST definition frame the problem as deception rather than delivery, which is the right frame for this one.

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

A Dozen Attorneys And One Insurance Contact

The recipient list was the loudest thing in the message and the only part no header could launder. Twelve external mailboxes, openly addressed on a single invite, spread across unrelated legal practices with one insurance contact among them, and not one of them internal to the sending domain.

Compare that to the genuine article. A real board invitation is sent from the association's own tenant to the board roster, and the roster is small, consistent, and known to itself. What was addressed here reads like a scrape of a public professional directory, which is what a bar association membership listing is. Attorneys are a rational target for exactly that reason: the directory is public, and unsolicited meeting requests from unfamiliar counsel are an ordinary part of the job rather than an anomaly.

The Case Closed On A Human Report

Themis, the IRONSCALES Adaptive AI analyst, scored the message at 72 percent on a generic phishing pattern match with no specific label assigned, which is a soft signal and honest about being one. There was no malicious verdict available to escalate on, because there was nothing malicious to find.

What actually resolved it was a recipient reading an invitation to an unexpected meeting, from an unrecognized name, at a domain unconnected to the organization supposedly convening it, and reporting it as impersonation. An analyst confirmed the verdict and the mailbox was quarantined. When authentication is clean and content is clean, the human element is not a fallback layer. It is the detection surface.

What To Take From This Case

Treat a platform's own system headers as transport evidence, never as identity evidence. If a message claims an organization, check the domain on the visible From and the Reply-To against that organization, and treat a mismatch as decisive no matter how legitimate the plumbing around it looks.

Read an SPF result of none as an unanswered question rather than a benign one. Then look at the recipient list, because a mass-addressed invitation to a group that has no reason to be on the same invite is a strong signal that costs nothing to check and cannot be faked away by header polish.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

Clean links and a passing header check can still add up to a message that is lying about the only thing that matters. Back tomorrow with the next teardown.