The Google Forms Editor Invite That Matched the Recipient's Name: Property Tax Survey as Social Engineering Pretext

A Google Forms editor invitation arrived at a multinational law firm with full authentication. SPF passed. DKIM passed. DMARC passed. Every link pointed to docs.google[.]com or accounts.google[.]com. Google's own infrastructure delivered the message. There was nothing for a secure email gateway to block.

The sender's display name matched the recipient's name. That was not a coincidence.

Google as the Authenticated Sender

The email originated from george23fx@gmail[.]com and was delivered through mail-qv1-xf48.google[.]com over IPv6 (2607:f8b0:4864:20::f48). SPF passed because Google's servers are authorized senders for gmail[.]com. DKIM passed under Google's signing keys. DMARC aligned. Composite authentication returned reason=100, the highest trust score. The Return-Path used a VERP-encoded address under doclist.bounces.google[.]com, consistent with legitimate Google Forms sharing notifications.

This is the same authentication profile that every real Google Forms invitation carries. A gateway evaluating sender reputation, domain age, and authentication results would see a trusted platform delivering a routine document sharing notification.

The /edit?invite= Permission Escalation

The form's subject was in Hebrew, referencing a survey about apartment ownership status for property tax rights. The content was regionally specific, crafted to appear relevant to the target's professional context in real estate law.

The links in the email were not standard view-only form URLs. They used /edit?invite= parameters, which grant editor privileges to the form without requiring the recipient to sign in to a Google account. Editor access means the recipient (or anyone with the link) can view all submitted responses, modify form questions, and alter the form structure. This turns a survey invitation into a potential data exfiltration vector. If other recipients have already submitted sensitive information, the editor link exposes it.

The Name Match as a Social Engineering Signal

The Gmail account display name matched the recipient's name at the law firm. The attacker registered george23fx@gmail[.]com, set the display name to match, and sent the form invitation to the corresponding corporate email address. When the notification arrived, the recipient saw their own name as the sender, delivered by Google, with a phishing pretext aligned with their professional domain.

This is deliberate targeting, not opportunistic spam. The name match increases the probability of engagement by creating a false sense of familiarity. It also complicates triage, because the recipient may assume they shared the form with themselves or that a colleague with a similar name initiated the request.

What Behavioral Detection Identified

Themis, the IRONSCALES Adaptive AI engine, flagged this message at 50% confidence. The community intelligence layer provided higher confidence based on resolutions of similar incidents across the platform. The combination of a first-time sender, name-matching anomaly between sender and recipient, editor-level permissions in the sharing link, and a regionally targeted pretext are behavioral signals that authentication alone cannot evaluate. These patterns reveal intent at the social engineering layer, not the infrastructure layer.

Authentication confirmed Google sent this email. It did not confirm who created the form or why they targeted this specific recipient.

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

Indicators of Compromise

MITRE ATT&CK Mapping