The Direct Deposit Form That Arrived From a Hotmail Account

The entire email was four words: "Hi. Please see attached." No context, no explanation, no company name. Attached was a PDF titled DirectDepositForm.pdf containing a pre-filled direct deposit authorization with routing and account numbers, a MICR line, and fillable form fields waiting for the recipient to complete. This was a social engineering attack that carried no malicious code and needed no link to click.

A Clean PDF That Scanners Could Not Flag

The PDF was generated by LibreOffice and created at 18:02 UTC on the same day it was sent, minutes before the email was dispatched. The file contained:

• Pre-filled banking details: a routing number, an account number, and a MICR line referencing a staffing company
• AcroForm fillable fields (/FT/Tx, /T(Text Box 1)) for the recipient to enter employee information
• An /OpenAction entry (standard for AcroForm PDFs, not malicious by itself)

No JavaScript objects. No embedded executables. No macros. No encrypted content. No external URLs. Antivirus and sandbox engines returned clean verdicts because there was nothing executable to detonate. The attack lived entirely in the content of the form, not in its code.

Authentication That Proved Nothing

The message came from an external Hotmail account and passed SPF, DKIM, and DMARC for hotmail.com. The sending path traversed Microsoft Outlook infrastructure with short end-to-end latency and valid ARC seals. Authentication confirmed the message was legitimately submitted through Hotmail. It said nothing about whether the sender was authorized to submit payroll changes.

The sender was flagged as high-risk in the incident metadata: external, first-time correspondent, consumer email provider. But the authentication signals were green across the board, creating a false confidence signal for any gateway that weights authentication heavily in its scoring.

The Process Vulnerability

If a payroll clerk received this form, opened it, and processed the direct deposit change, salary payments would route to the attacker's account. The business email compromise did not need credentials, did not need the recipient to visit a website, and did not need any technical exploit. It needed one person to treat an emailed form as a legitimate business request.

IRONSCALES flagged the message on first-time sender, external consumer email origin, attachment-only body with no business context, and the minimal message pattern that is characteristic of social engineering probes.

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

Indicators of Compromise

MITRE ATT&CK Mapping