A Real Gmail, a Real Drive Link, a Fake Tax Form

A message landed in the inbox of a division president at a mid-size restoration and construction firm. It passed SPF. It passed DKIM. It passed DMARC. It even passed ARC. On every transport-level control a security team normally leans on, the email was clean.

It was also a scam, and a fairly ambitious one. The sender wanted the recipient's tax identity.

The whole case is a lesson in what authentication does and does not prove. It confirms that a message truly came from the domain it claims to come from. It says nothing about whether the human behind that domain is honest. Here the domain was gmail[.]com, the account was a throwaway, and the ask was a W-9.

Authentication Was Never the Problem

The email came from ugecexifiv58@gmail[.]com, a random-local-part account with no history, flagged in the incident data as a first-time, high-risk sender. Because it originated inside Gmail's own infrastructure, the message aligned cleanly: SPF pass, DKIM pass on d=gmail[.]com, DMARC pass, ARC pass.

That is the trap. A phishing message riding free webmail inherits the sending platform's spotless reputation. There is no spoofed domain to catch, no failed alignment to alert on, no lookalike to score. The attacker did not defeat authentication. He simply chose an approach where authentication had nothing to say.

Microsoft's own filters sensed the disconnect anyway. Despite the full pass, the message was scored SCL=5 and Forefront-categorized as spam, a behavioral override triggered by the account's newness and the shape of the request rather than by any transport failure. That override is the tell: the signal lived in behavior, not in headers.

The Ask: A Drive Link and a Tax Form

The body opened with a generic "Dear Customer" greeting, never using the recipient's name, and asked him to open and complete a Google Drive-hosted form for "tax credit processing." The link resolved to a genuine Drive object:

hxxps://drive.google[.]com/file/d/1ikjhtwJHc7k8BVArOZAHdP3wzsG5-QqJ/view

Google Drive is a trusted domain with a near-perfect reputation, so a link pointing at it sails past URL-reputation and gateway checks that would flag a freshly registered attacker domain. The form itself was the payload. Tax-credit "verification" workflows are a textbook vehicle for collecting W-9 data: Social Security numbers, employer identification numbers, and bank routing and account details, all volunteered by the target into a form on infrastructure the attacker controls. No malware, no exploit, just a person typing their most sensitive identifiers into a field.

This is credential harvesting aimed one rung higher than a password. A stolen login can be rotated. A Social Security number and a routing number cannot.

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

Borrowing Credibility From a Real Name

The most deliberate touch was in the signature. It stacked several official-sounding vendor names, "Tax Advantage Verification LLC," "W-9 Verification Services LLC," and "Form Verification Services," none of which correspond to a verifiable business. Sitting among those fabrications was one genuine, unrelated tax-credit organization, named to lend real-world legitimacy to the fictions around it.

That is a well-worn confidence technique. Place one true, checkable entity next to several invented ones, and a recipient who Googles a single name finds a real result and stops looking. The real organization does the vouching for the fake ones by proximity alone. It costs the attacker nothing and buys a meaningful bump in perceived legitimacy.

Mapping to MITRE ATT&CK

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

• T1566.002 Spearphishing Link covers the delivery mechanism: a socially engineered email whose entire payload is a link to a hosted form.
• T1598.003 Phishing for Information: Spearphishing Link covers the objective. The goal was not code execution or account takeover but the direct collection of sensitive tax and financial data through a form the victim fills in willingly.

Indicators of Compromise

Detection and What to Watch For

Signature and reputation engines were never going to win this one. The sending platform is legitimate, the link target is legitimate, and there is no attachment or malware to fingerprint. Detection has to move to behavior and intent. The signals that matter are a first-time free-webmail sender addressing a senior leader with a generic salutation, a request for tax or financial identifiers, a link into a consumer file-sharing service standing in for a business process, and a signature whose named entities do not resolve to real businesses.

This is where the IRONSCALES platform adds a layer static gateways miss. Themis, our Adaptive AI analyst, weighs the relationship between the sender's history, the nature of the request, and the plausibility of the claimed entities the way a trained analyst would, flagging the intent even when every server-level check comes back green. The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and clocks the median time to submit data after a phishing click at 28 seconds, which is roughly how long a form like this needs. The Microsoft Digital Defense Report 2024 documents the same shift toward abusing trusted services rather than breaking them, and the FBI's 2023 Internet Crime Report ranks business-identity and data-theft schemes among the costliest categories it tracks. IRONSCALES sees this pattern across 35,000+ security professionals in 17,000+ organizations, and authenticated-but-hostile webmail is a recurring shape.

The Takeaway

Authentication answers "did this come from where it says," not "should I trust it." A free-webmail account will pass every check and still be run by a stranger who wants your Social Security number. When the request is for tax or financial data, the sender's history, the destination of the link, and the reality of the names in the signature matter far more than a row of green auth results. Treat a Google Drive form asking for a W-9 the way you would treat a stranger at the door asking for your bank details, and pair that instinct with behavioral detection that reads intent rather than headers. CISA's guidance on recognizing and stopping phishing early is a good reference for building that reflex across a team: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one

The NIST definition of phishing is a useful baseline for training as well: https://csrc.nist.gov/glossary/term/phishing