Hyundai Card HTML Attachment Harvests Credentials Without a Single Malicious URL

No malicious URL. No redirect chain. No credential-harvesting landing page hosted on a compromised server. This phishing attack against a multinational chemical manufacturer's Korean subsidiary harvested card credentials using nothing but an HTML file attachment and obfuscated JavaScript running entirely inside the victim's browser.

The email impersonated Hyundai Card, one of South Korea's largest credit card issuers, and delivered a pixel-perfect April 2026 corporate billing statement. The attached HTML file contained a hidden password field, eval/atob decoding routines, and enough obfuscation to defeat static analysis. Traditional link scanners had nothing to flag because the entire attack lived inside the attachment.

Themis, the IRONSCALES Adaptive AI, classified this as phishing with 89% confidence and flagged the VIP recipient designation. All four affected mailboxes were system-reverted before any credentials could be exfiltrated.

A Pixel-Perfect Corporate Billing Statement

The email arrived from admin@hyundaicard[.]com with a Korean-language subject line translating to "[Hyundai Card MY COMPANY] April 2026 Corporate Card Email Billing Statement." It was addressed by name to an employee at the organization's Korean subsidiary, personalized with their actual recipient identity.

The message body was professionally formatted. Hyundai Card branding, a Seoul corporate address, customer service numbers (1577-6000), and a footer with business registration details all matched legitimate Hyundai Card communications. Visual assets loaded from hyundaicard[.]com domains. A call-to-action instructed the recipient to open the attached statement and enter the last seven digits of their card number or business registration number.

Everything about the email body looked authentic. The weaponized payload was the attachment.

Inside the 223 KB HTML Weapon

The attachment, named hyundaicard_20260422.html, weighed in at 223,327 bytes. Endpoint scanning rated it "clean" because it contained no known malware signatures. That verdict was wrong.

Buried inside the HTML was a form named decForm with two input fields: a hidden password field (p2) and a visible text field (p2_temp). The form's action attribute was empty. When the victim typed their card digits, JavaScript captured the input client-side rather than submitting it to a visible URL.

The script logic used multiple layers of obfuscation:

• eval() and atob() decoded base64-encoded payloads at runtime, hiding the actual credential-capture logic from static scanners
• unescape() and fromCharCode() provided additional encoding layers, converting hex and character code sequences into executable JavaScript
• Numerous data:image/base64 blobs padded the file to 223 KB, making manual analysis tedious and masking the malicious logic within legitimate-looking image data
• A doAction() function triggered on form submission, executing the decoded payload to process captured credentials

The HTML also referenced external domains including download.yettiesoft[.]com and www.yettiesoft[.]com, which were reachable and returning HTTP 200 responses during analysis. These third-party download hosts expanded the attack surface for potential exfiltration or secondary payload delivery.

Authentication Gaps That Opened the Door

The email's relay path told a story of broken authentication. The message originated from cabillmail.hcs[.]com (61[.]40[.]236[.]82), a server in Hyundai Card's legitimate SPF record. At this first hop, SPF passed.

But the message then transited through esa.hc1333-60.eu.iphmx[.]com (23[.]90[.]110[.]124), a Cisco IronPort appliance. When Microsoft's protection gateway evaluated SPF against this relay IP, the check failed. The IP was not in hyundaicard[.]com's SPF record.

The authentication results at the final receiver:

• SPF: fail (sender IP 23[.]90[.]110[.]124 not designated)
• DKIM: none (message not signed)
• DMARC: fail, action=none (policy set to monitor only)

With DMARC at p=none, the receiving server logged the failure but delivered the message anyway. No enforcement. No quarantine. No rejection. The email landed in the inbox.

This maps to MITRE ATT&CK T1566.001 (Phishing: Spearphishing Attachment) and T1204.002 (User Execution: Malicious File), with the obfuscated JavaScript execution falling under T1059.007 (Command and Scripting Interpreter: JavaScript).

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

Why Link Scanners Are Blind to This

This attack exposes a fundamental gap in Secure Email Gateway (SEG) architecture. SEGs are built to scan URLs. They follow links, detonate pages in sandboxes, and check domains against reputation databases. The Verizon 2024 DBIR confirms that credential theft remains the top action variety in breaches, yet the detection model assumes credentials are stolen at a destination URL.

When the credential harvester runs entirely inside an HTML attachment, there is no URL to scan. The form action is empty. The JavaScript executes locally. The file signature is clean. Every layer of URL-based defense returns a green light.

According to the FBI IC3 2024 Annual Report, phishing and its variants generated more complaints than any other cybercrime category. As attackers shift to client-side techniques that avoid detectable infrastructure, that number will only grow.

IRONSCALES detected this threat through behavioral analysis of the attachment's content patterns. The combination of a hidden password field with an empty form action, eval/atob obfuscation chains, and credential harvesting form structures triggered classification. Community-based reputation signals from the 35,000+ security professionals in the IRONSCALES network further corroborated the phishing verdict. The first-time sender flag added another signal. No single indicator was definitive. The convergence of all of them was.

Defending Against Attachment-Based Credential Harvesting

Enforce DMARC at p=reject or p=quarantine. Hyundai Card's p=none policy meant three separate authentication failures (SPF fail, no DKIM, DMARC fail) did not prevent delivery. Organizations sending corporate billing statements should enforce DMARC. Organizations receiving them should weight authentication failures heavily in their scoring models.

Deploy attachment behavioral analysis. Static file-type checks and signature scanning rated this 223 KB HTML file as "clean." Only behavioral inspection of the JavaScript patterns (eval, atob, hidden password fields, empty form actions) identified the threat. If your email security stack only scans for known malware, it will miss this class of attack entirely.

Train users on HTML attachment risks. Legitimate billing portals direct users to authenticated web portals. They do not send 223 KB HTML files with embedded JavaScript and hidden password fields. Any corporate communication asking a user to open an HTML attachment and enter credentials locally should be treated as suspicious by default.

Audit third-party relay configurations. The SPF failure in this attack resulted from a legitimate relay (Cisco IronPort) not being included in the sender's SPF record. Organizations should audit their own outbound relay chains to prevent similar alignment gaps that attackers can exploit or replicate.