The PDF Creator Field Knew What the Subject Line Didn't: wkhtmltopdf and the Geek Squad Shipping Mismatch

Most phishing PDFs try to hide their malicious content. This one hid its identity, and the metadata gave it away before anyone opened the file.

A recipient at a regional services organization received an email from briliansupriyadiwill[@]gmail[.]com with the subject "Package Scanned A507JYE85A8N3_SFFC4~Z7EACLM4FBM1.2CRG." The body contained only that same opaque alphanumeric string: no carrier name, no tracking URL, no CTA, no context. One PDF attachment accompanied it. Gateway verdict on the PDF: clean. No JavaScript, no AcroForm fields, no embedded files, no extractable URLs.

The story was in the metadata the scanner didn't surface.

What the PDF Creator Field Reveals That Body Scanning Misses

PDF documents store a metadata dictionary in their header that records, among other fields, the Creator (the application that generated the content) and the Title (the document's internal name). Static analysis of the attachment showed:

• Creator: wkhtmltopdf 0.12.6
• Title: Geek Squad Subscription Renewal
• Subject line: Package Scanned (shipping lure)

Those three data points form the core of this attack's forensic tell. The subject frames the message as a shipping notification. The PDF title reveals the actual lure: a Geek Squad subscription renewal claim. And the Creator field identifies exactly how the document was produced.

wkhtmltopdf is a command-line HTML-to-PDF renderer used extensively in callback phishing kits. Its appeal to phishing operators is straightforward: convert a fully functional HTML lure page (complete with branding, urgency language, and a phone number) into a static PDF. The conversion removes all active content. The resulting file contains no clickable links, no JavaScript, no forms. Every gateway check that looks for exploitable mechanisms in PDF attachments returns clean. The social-engineering payload (the callback number and the scripted urgency) survives in the visual layer of the rendered document, invisible to parsers that don't perform optical character recognition or visual analysis.

MITRE ATT&CK T1566.001 covers spearphishing via attachment. T1204.002 (user execution: malicious file) applies when the victim opens the PDF and reads the callback instructions. T1656 (impersonation) covers the Geek Squad identity claim embedded in the document.

The Shipping Subject as Misdirection

The subject line and body token serve a specific purpose: they get the email past content filters without triggering brand-impersonation detection for Geek Squad. A Geek Squad-themed subject would match known phishing patterns in many gateway configurations. A shipping token does not.

The mismatch is not accidental. Phishing kit operators running volume campaigns frequently reuse template components, a shipping email wrapper here and a Geek Squad renewal PDF there, without synchronizing them. The result is an internal contradiction that tells the analyst what the gateway score cannot: these pieces come from different templates assembled for evasion, not for coherence.

The social engineering mechanism depends on urgency and authority. Geek Squad renewal phishing typically claims an auto-renewing subscription charge and instructs the recipient to call immediately to cancel. The callback phone number connects to an attacker posing as support, who then guides the victim toward credential disclosure, remote-access tool installation, or a fraudulent refund transaction.

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

Gmail API Dispatch and the Authentication Laundering Problem

The Received header showed the message dispatched via gmailapi.google.com with HTTPREST, not a standard SMTP client. This indicates the attacker sent through the Gmail API, an automated-send pathway that fully authenticates through Google's infrastructure.

SPF passed (Google's outbound IP designated as permitted for gmail.com). DKIM passed (signed by gmail.com). DMARC passed (policy p=NONE, result pass). ARC sealed at i=2 by google.com. Every authentication check returned a positive result because every authentication check was evaluating Google's infrastructure, not the attacker's identity.

First-time sender status and the implausible local-part of the sending address (briliansupriyadiwill[@]gmail[.]com reads as a string-generated account name, not a human's) are behavioral signals that authentication headers cannot encode. These are exactly the signals that impersonation detection must evaluate when the cryptographic layer provides no evidence of spoofing.

What Detection Requires When the File Is Technically Clean

The case illustrates a gap that gateway-layer PDF scanning cannot close. Static analysis correctly returned a clean verdict: no executable content, no network callouts, no exploit primitives. That verdict is accurate and useless simultaneously.

Closing the gap requires two capabilities working together. First, metadata extraction that surfaces Creator, Producer, and Title fields alongside the attachment verdict, in the primary analyst view rather than a supplemental log. wkhtmltopdf in the Creator field, combined with a document Title that names a brand the sender has no relationship to, is a high-confidence indicator of kit assembly.

Second, cross-field coherence checking: does the email subject match the attachment's declared content? A shipping-themed email body attached to a "Geek Squad Subscription Renewal" PDF is incoherent. Humans notice incoherence. Automated scanners that evaluate each field in isolation do not.

IRONSCALES detected the behavioral anomaly (first-time external Gmail sender, opaque body, PDF attachment with mismatched internal metadata) and flagged the incident for quarantine. The Themis AI engine identified the credential-theft pattern at the campaign level, matching the assembly characteristics to known social engineering kits despite the absence of any technically malicious PDF component.

Indicators of Compromise