The Invoice Was in Hebrew, the HTML Attachment Called Localhost, and Every Authentication Check Passed

The email was written entirely in Hebrew. The subject referenced an order confirmation (SO25KA000195). The body instructed the recipient to complete a bank transfer to branch 31-048, account 409-123450, and noted that an invoice would be issued after payment. The sender address belonged to industry[.]org[.]il, the domain of a recognized Israeli manufacturers association. SPF, DKIM, and DMARC all passed.

Attached was a 37,734-byte HTML file that looked like a routine document. It was not.

Three Evasion Layers in One Attachment

The HTML attachment combined three techniques that individually complicate automated analysis and together defeat most sandbox environments.

First, the file contained a reference to http://127.0.0.1, the localhost loopback address. When a sandbox renders this attachment, it attempts to load resources from the analysis machine itself. No web server is running on the sandbox at that address, so the page fails to render correctly. The sandbox sees a broken document and reports it as benign. On a victim's workstation, the behavior changes: the localhost reference can trigger local redirect handlers, cached content, or JavaScript-driven fallback logic that activates the real payload.

Second, images in the attachment were embedded as base64-encoded data URIs rather than loaded from external URLs. This eliminates outbound network requests during static analysis. Scanners that monitor for external resource calls see nothing suspicious. The images render correctly in a browser without generating any network traffic that a proxy or firewall could intercept.

Third, the attachment contained a form element with an empty action attribute. By default, an empty action submits form data to the current page URL. In a file opened locally, this means credentials entered into the form are processed client-side through JavaScript rather than sent to a visible external endpoint. The data exfiltration mechanism only becomes apparent when the JavaScript executes in the victim's browser context.

Legitimate Infrastructure, Questionable Intent

The sending domain industry[.]org[.]il is associated with a real Israeli trade organization. Authentication passed cleanly because the domain's DNS records are properly configured. The sender address was not publicly verifiable through the organization's website or directory, raising the possibility that the account was compromised or that the sending infrastructure was abused.

The email body also referenced external resources from wbf[.]fbc[.]co[.]il, a domain within the Israeli .co.il namespace. The invoice fraud pretext, requesting bank payment before issuing a receipt, is a common social engineering pattern in B2B attacks targeting finance teams. The Hebrew language narrowed the target pool to Israeli organizations or companies with Israeli operations.

The behavioral signals were the discriminating factor: a first-time sender, an HTML smuggling attachment with localhost references, and bank transfer instructions embedded directly in the email body. Authentication confirmed the domain was authorized. Behavioral analysis identified that the message was not safe.

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

Indicators of Compromise

MITRE ATT&CK Mapping