The Payroll Change Request That Passed Every Authentication Check

The email was three sentences long. No links. No attachments. No embedded images. Just a polite request to update direct deposit information before the next payroll cycle.

"Hello ," it began (the comma dangling where a name should have been), "I'm writing to inform you that my pay information has changed, and I would request a change to my direct deposit information for next payroll checks as a precaution."

The display name said it was from a known internal contact. The sending address was mtut245@gmail[.]com. SPF passed. DKIM passed. DMARC passed. Every authentication check returned clean. And the entire payload was a social engineering script designed to steal someone's paycheck.

When Gmail Becomes the Attack Platform

A regional broadband provider received this email targeting its payroll or HR function. The attacker's approach was deceptively simple: register a free Gmail account, set the display name to match a real employee the organization already knows, and send a direct deposit change request.

The impersonated identity was a known internal contact whose legitimate address was on a completely different domain. But most email clients display the sender name prominently while burying the actual address behind a click. On mobile, the mismatch is essentially invisible.

This is MITRE ATT&CK T1656 (Impersonation) in its most stripped-down form. No infrastructure to build. No domains to register. No payload to craft. The attacker borrowed Google's authentication and a colleague's name, then asked for money.

According to the FBI's 2024 Internet Crime Report, BEC accounted for $2.77 billion in reported losses. Payroll diversion, where attackers redirect an employee's direct deposit to a fraudulent account, is one of the fastest-growing subcategories. The FTC has issued specific warnings about payroll redirect schemes, noting that once funds are rerouted, recovery is often impossible because the attacker drains the account within hours.

The Authentication Paradox: All Green, All Dangerous

Here's what makes this attack instructive for defenders. Every technical signal said "legitimate."

The message routed through Google's mail infrastructure at mail-ej1-x632.google[.]com (IPv6 2a00:1450:4864:20::632). SPF passed because the sending IP is authorized for gmail[.]com. DKIM passed with valid signatures under both gmail[.]com and 1e100[.]net. DMARC passed with full alignment. ARC validation passed through both Google and Microsoft. The composite authentication score (compauth) returned 100, the highest possible confidence.

From the perspective of any Secure Email Gateway relying on authentication signals, this email was cleaner than messages sent by most Fortune 500 companies.

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

That's the uncomfortable reality. SPF, DKIM, and DMARC answer one question: "Was this email sent from an authorized server for this domain?" They cannot answer: "Is the person behind this email who they claim to be?" As Microsoft's Digital Defense Report 2024 documented, attackers increasingly leverage legitimately authenticated infrastructure rather than spoofing domains. Free email services are the most accessible version of this technique.

The recipient's mail gateway actually did flag the message (SCL:5, CAT:PHISH), and the organization's external-origin banner displayed a caution warning. But the gateway classification alone, without automated quarantine, would have left the decision to the recipient. A payroll clerk seeing a familiar name and a routine request has every reason to respond.

Three Sentences, Zero Technical Indicators, One Behavioral Fingerprint

The body of this email was a masterclass in minimalism. Three sentences. Polite tone. A reasonable request. No urgency language, no threats, no deadlines. The attacker even closed with a simple "Thanks."

But the compositional tells were there for a system that knows what to look for.

The salutation was "Hello ," with a blank where the recipient's name should have been. No employee ID, no payroll reference number, no department, no phone number, no email signature. For an email supposedly from a colleague requesting a sensitive financial change, the absence of identifying details was conspicuous.

This maps to MITRE ATT&CK T1598 (Phishing for Information). The attacker wasn't trying to deliver a payload. The goal was to elicit a reply, at which point the attacker would provide fraudulent banking details for the "updated" direct deposit. According to Verizon's 2025 Data Breach Investigations Report, pretexting (which includes BEC social engineering) was involved in 24.3% of breaches, nearly all financially motivated.

Themis, the IRONSCALES Adaptive AI engine, flagged this email at 90% confidence and auto-quarantined it. The detection relied entirely on behavioral signals:

• Display name mismatch: The sender's display name matched a known internal identity, but the sending address came from an unrelated external Gmail account.
• First-time sender: The Gmail address had never previously communicated with anyone at the organization.
• Fraudulent request pattern: A financial change request (direct deposit update) from an external sender impersonating an internal employee fits a well-established BEC pattern.
• Community intelligence: Across the IRONSCALES network of 35,000+ security professionals, display name impersonation from free webmail providers targeting payroll functions had already been flagged and resolved at high confidence.

No single signal was definitive. The combination was.

What This Means for Payroll Security

This attack failed because behavioral AI evaluated the sender's identity against known communication patterns rather than scanning for technical threats that didn't exist. For security teams reviewing their own defenses, three points stand out.

Free webmail is an attack vector, not just a nuisance. Any email from a Gmail, Yahoo, or Outlook.com address that uses a display name matching an internal employee and makes a financial request should trigger immediate verification. Authentication will always pass for these services. That's by design.

Payroll change requests need out-of-band verification. The FBI recommends confirming all payroll and banking changes through a separate, pre-established channel (a phone call to a number on file, an in-person confirmation, or a verified HR portal). Email alone, regardless of how legitimate it appears, should never be sufficient for financial routing changes.

Zero-payload attacks expose the limits of content scanning. If your detection strategy depends on detonating attachments, crawling URLs, or analyzing embedded content, you have no defense against an email that deliberately contains none of those things. According to IBM's 2024 Cost of a Data Breach Report, the average cost of a social engineering breach reached $4.88 million. The attacks that cost the most are the ones with the least to scan.