No Links. No Attachments. Just a Polite Request for Every Employee's W-2.

The email contained no links. No attachments. No embedded images. No QR codes. No malicious URLs of any kind. A content scanner examining this message would find nothing to flag, because there was nothing to find.

The entire payload was a single paragraph asking the HR department to send "complete copies of the W-2 wage and tax statements for all employees for the 2025 tax year" as PDF attachments.

If HR had complied, every employee's Social Security number, total compensation, and home address would have been delivered to an attacker-controlled inbox. One email. One response. An entire workforce compromised.

The Request That Looked Like Business

The email arrived at the HR department of a mid-size financial institution with the subject line "Request for 2025 Employee W-2 Forms for Review." The sender name displayed as "Ted Treat." The tone was professional, the formatting was clean, and the request followed the cadence of a routine internal audit or tax compliance review.

The body asked for W-2 forms "for all employees for the 2025 tax year," specified PDF format, and requested them as email attachments. There was no rush language, no threat of consequences, no artificial deadline. The ask was framed as a standard business process.

That restraint is what makes this class of attack effective. According to the FBI's 2024 Internet Crime Report, W-2 and tax document fraud continues to be a high-impact subcategory of BEC, with the FBI noting that payroll diversion and tax data theft schemes have increased year over year. A single successful W-2 request can expose hundreds or thousands of employees to identity theft and fraudulent tax filings.

This maps directly to MITRE ATT&CK T1598.003 (Phishing for Information: Spearphishing Service), where the attacker's objective is information collection rather than payload delivery.

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

Two Domains, One Inbox, Zero Overlap

The technical tells in this email were subtle but present for anyone examining the headers.

The From address showed jonas@rrinconline[.]com. The domain rrinconline.com was registered in 2009, uses Google DNS, and has privacy-shielded WHOIS records. It is old enough to carry decent domain reputation and would not trigger new-domain alerts.

The Reply-To address pointed somewhere entirely different: ceoceo@akpages[.]com. A different domain, a different mailbox, and a sender name ("ceoceo") that carries its own social engineering weight, implying executive authority through the address itself.

This is the core mechanism of the attack. The From address establishes surface credibility. The Reply-To address routes the victim's response to an attacker-controlled destination. Most email clients display the From name and address prominently. The Reply-To field is buried in headers that recipients rarely inspect. When the HR administrator hits "Reply" with a PDF full of W-2 forms attached, that response goes to ceoceo@akpages[.]com, not to the address shown in the From field.

Reply-To mismatches are one of the most reliable indicators of BEC intent. Microsoft's Digital Defense Report 2024 documented that identity-based attacks, including Reply-To manipulation and display name impersonation, continue to scale because they exploit how email clients present sender information rather than how email protocols authenticate it.

The sender identity "Ted Treat" does not appear in public records, LinkedIn, or company directories associated with either rrinconline.com or akpages.com. The identity appears to be fabricated, which maps to T1656 (Impersonation).

The Allow-Listed Relay That Opened the Door

The email routed through Amazon SES infrastructure (IP 54[.]240[.]48[.]92), which is Amazon's legitimate email sending service. DKIM passed for both rrinconline[.]com and amazonses[.]com. DMARC passed with a policy of p=none, meaning the sending domain publishes no enforcement directive even if authentication fails.

Then the message hit an AppRiver relay at 8[.]31[.]233[.]206. AppRiver (now Zix, now OpenText) is a legitimate email security gateway. SPF failed at this hop because the AppRiver IP is not authorized in rrinconline.com's SPF record. Under normal circumstances, that SPF failure would contribute to a negative trust score.

Instead, the message received SCL -1.

SCL -1 means the message was explicitly allow-listed, bypassing content filtering entirely. In Microsoft 365 environments, SCL -1 is typically assigned when mail flows through a connector or relay that the tenant administrator has configured as trusted. The AppRiver relay was in the organization's trusted path, so the message landed directly in the inbox with no spam or phishing evaluation applied.

This is a structural problem. Allow-listed relays exist because organizations need mail to flow through security appliances without being re-filtered at every hop. The tradeoff is that any message that enters through that relay inherits the trust designation, regardless of its actual content or intent. An attacker who knows (or guesses) that a target organization routes mail through a specific gateway can exploit that trust chain.

According to the Verizon 2024 DBIR, social engineering remains the leading initial access vector in breaches, and the report specifically notes that pretexting (which includes BEC schemes requesting sensitive data) was involved in nearly a quarter of all breaches analyzed.

What Stopped It

There was nothing for a static scanner to catch. No URL to check. No attachment to detonate. No embedded content to render. The message was plain text with a professional request.

Themis flagged the email at 90% confidence based on behavioral signals:

W-2 bulk request pattern. An email requesting tax documents for "all employees" carries a specific risk profile. This is not a vendor asking for a single W-9. It is a request for the complete payroll identity dataset of an organization. The scope of the ask is itself a signal.

Reply-To domain mismatch. The From domain and Reply-To domain shared no infrastructure, no registration history, and no organizational relationship. Responses to this email would have been routed to a completely separate entity from the apparent sender.

Fabricated sender identity. "Ted Treat" could not be verified against any public directory, organizational record, or social media presence associated with either the sending or reply-to domain.

Community intelligence. Across the IRONSCALES network of 35,000+ security professionals, similar W-2 bulk request patterns had been flagged and resolved as phishing. That community signal corroborated the behavioral analysis.

The message was flagged across one affected mailbox. The IRONSCALES community independently confirmed it as phishing.

IOC Reference

What Zero-Payload BEC Means for Payroll Security

This attack asked for exactly one thing: data. Every employee's W-2. There was no follow-up needed, no wire transfer to execute, no gift card to purchase. A single reply with a PDF attachment would have completed the attack in full.

For security teams, the specific lessons are:

Treat bulk tax document requests as high-severity events regardless of sender authentication. Any email requesting W-2, W-9, or payroll data for multiple employees should trigger out-of-band verification through a known-good phone number or in-person confirmation. The request scope is the signal.

Surface Reply-To mismatches to end users. If your email client or gateway can flag messages where the Reply-To domain differs from the From domain, enable that feature. Most recipients never check Reply-To headers manually. Making the mismatch visible is the single highest-impact change for this class of attack.

Audit your allow-listed relays. If a connector or relay in your mail flow assigns SCL -1 to inbound messages, every message through that path bypasses content filtering. Ensure that trust designation is narrowly scoped and regularly reviewed. An allow-listed relay is a trust assumption, and attackers exploit trust assumptions.

Run W-2 phishing simulations during tax season. Phishing simulation programs should include zero-payload payroll data requests, not just link-click exercises. If your simulation program only tests whether employees click malicious links, it is not testing for the attack pattern that actually targets payroll departments.

The email had no links to block, no attachments to quarantine, and no malicious content to detect. It was a paragraph of text that, if answered, would have handed an attacker the identity data of every person on the payroll. Static analysis returned nothing because there was nothing to analyze. Behavioral detection returned 90% confidence because the pattern, the scope, and the infrastructure told a clear story.