A Fillable PDF With Real Bank Details and Nothing for Scanners to Flag

The email said "Hi. Please see attached." Nothing else. No context, no employee ID, no reference to a recent conversation. Just a three-word message from a Hotmail account, a display name matching a known employee, and a single PDF attachment titled DirectDepositForm.pdf.

Inside the PDF was a complete direct deposit authorization form: a nine-digit routing number, a twelve-digit account number, a MICR line, and authorization language requesting that payroll update the employee's deposit destination. The form was created in LibreOffice minutes before the email was sent. It contained no links, no macros, no embedded executables, and no JavaScript triggers. Every antivirus engine and sandbox that evaluated it returned a clean verdict. SPF, DKIM, and DMARC all passed for the sending domain.

This is what pure social engineering in business email compromise looks like when every technical control returns green. The entire attack depends on one thing: an HR employee processing the form without picking up the phone.

A Fillable Form Designed to Be Acted On

The PDF was not a scan. It was not an image of a bank form. It was a structured AcroForm document with fillable text fields (FT/Tx field types labeled "Text Box 1" and similar generic identifiers), pre-populated with the attacker's banking information. The /OpenAction directive in the PDF structure indicates the document was configured to execute an action when opened, though in this case the action was benign, likely an auto-focus on the first form field.

The distinction between form fields and inline text matters. Text-based DLP rules scan the visible text stream of a PDF: the paragraphs, headings, and labels that appear when you extract text from the document's content objects. AcroForm field values live in a separate layer, the interactive form structure. A DLP rule looking for patterns like nine-digit numbers (routing numbers) or twelve-digit sequences (account numbers) in the text stream finds nothing, because those values exist only in the form field objects. OCR-based analysis would catch them if applied, but most email security pipelines do not run OCR on every PDF attachment. The FBI IC3 2024 Internet Crime Report recorded $2.9 billion in BEC losses for the year, with payroll diversion representing one of the fastest-growing subcategories.

The PDF metadata reinforces the ad hoc nature of the document. The creator application was Writer (LibreOffice 7.0), not an enterprise payroll system or banking platform. The creation timestamp was minutes before the email was sent. No legitimate payroll process produces a direct deposit form in a consumer office suite and emails it from a personal Hotmail account within the same session.

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

Full Authentication Pass From a Consumer Mailbox

The email transited Microsoft's Hotmail/Outlook infrastructure over IPv6 and arrived with pristine authentication:

This is working as designed. Hotmail maintains proper SPF records, DKIM signing infrastructure, and a published DMARC policy. Any message sent through that infrastructure passes every protocol-level check. The authentication confirms that Microsoft's servers sent the email on behalf of a hotmail[.]com address. It says nothing about whether the person behind that address is actually the employee named in the display name.

The sender risk was flagged as HIGH by the IRONSCALES incident system despite the clean authentication. That flag was driven by behavioral context, not protocol results.

Zero Technical Indicators, Maximum Process Risk

What makes this attack distinct is the complete absence of anything to detect through conventional content analysis:

• No malicious links. The only URLs in the email were Microsoft Safe Links in the mobile signature (aka[.]ms/krs, aka[.]ms/AAb9ysg), both resolving to legitimate Outlook mobile download pages.
• No malware. The PDF contained no JavaScript, no embedded executables, no macro code, and no external link annotations. Every scanner returned clean.
• No credential harvesting page. The attacker was not trying to steal the recipient's password. They were trying to change where an employee's paycheck goes.
• No technical exploit. The attack targets a business process, not a vulnerability. It maps to MITRE ATT&CK T1656: Impersonation and T1566.001: Phishing: Spearphishing Attachment.

The entire payload is a filled-out form. The entire exploit is submitting that form to payroll. If the HR department processes the direct deposit change based solely on the emailed PDF, the attacker wins without ever compromising an account, deploying a payload, or clicking a single link.

How Behavioral Detection Caught a Zero-Payload Attack

Themis, the IRONSCALES Adaptive AI, flagged this email based on behavioral signals that no content scanner would evaluate:

1. First-time external sender. The Hotmail address had no prior communication history with the target organization. A direct deposit change request from an address that has never contacted payroll before is a high-risk anomaly.
2. Consumer mailbox targeting HR/payroll. Legitimate direct deposit changes at a staffing agency flow through internal HR systems, employee self-service portals, or established corporate email channels. A free webmail account sending banking forms to the payroll department breaks every established communication pattern.
3. Attachment without context. Three words and a PDF. No employee ID, no reference number, no manager CC, no prior thread. The absence of context is itself a signal. Legitimate payroll change requests carry process artifacts.

This is the detection gap that business email compromise protection must address. When the attachment is clean, the authentication is valid, and the links are benign, the only signal left is behavioral: who is this sender, have they contacted this recipient before, and does the request match how this organization normally communicates?

Staffing agencies handle direct deposit changes constantly. That volume is precisely what makes them vulnerable. The fraudulent request hides in the noise of routine payroll operations. Without account takeover protection and behavioral baselines that flag deviations from normal sender patterns, the defense relies entirely on the HR employee noticing that the email came from a Hotmail address instead of an internal system. That is not a reliable control.

Indicators of Compromise