Phishing PDFs in the Wild - Patterns Across Three Campaigns

TL;DR

This week I triaged three malicious PDF attachments. PDF-based attacks are claiming a growing share of malicious email, which pushed me to shift focus from general email security toward attachment-centric analysis.

The samples varied in technical sophistication, but the playbook was the same: manufacture urgency, force a click, and lean on disposable infrastructure.

Sample 1 - Facebook Recovery

This one was a Facebook “account locked” lure, built to make someone react fast. Nothing fancy in the flow: a couple redirects and then basic credential-harvest infrastructure. What stood out was how throwaway everything looked, from cheap hosting to minimal hardening.

When I checked it, the phishing domain still resolved to a CMC Telecom VPS in Vietnam and the server was still up. But /step1 and the usual lure paths all returned the same Webcake unpublished-site placeholder.

Current state:

• PDF still carries phishing URL
• Domain still resolves
• OpenResty server still responds
• Lure content appears removed/unpublished
• No live credential collection flow observed

Conclusion: this was clearly a malicious delivery artifact. The infrastructure was still reachable, but the live lure content looked removed.

Sample 2 - Chase Invoice

The Chase invoice sample was a fake billing PDF with urgency baked in, but not much polish. Instead of doing anything complex, it used a blurred overlay to push a click into external infrastructure. The chain ended at a raw IP on cheap VPS hosting with exposed Windows ports and weak setup overall. No real evasion here, just a direct attempt to get someone to fetch the next stage.

This one was simple: visual pressure and one hidden URL to a raw IP serving a .7z stage. The destination sat on low-cost VPS infrastructure with exposed Windows-facing ports and inconsistent delivery behavior (connection resets and broken HTTPS upgrade handling).

Conclusion: not a well-run operation, but still good enough for initial delivery.

Sample 3 - "This Invoice Is Not Compatible With Your Browser"

The “invoice not compatible with your browser” lure stood out because the infrastructure did not look brand new. The domain goes back to the early 2000s, which can make it look more trustworthy at a glance. But the flow was still the same: fake browser issue, push the click, then route into credential-collection infrastructure. Underneath, it had the same familiar signs: redirects, light hosting, and disposable backend logic.

This was the most interesting chain. One Netlify link was dead, while the other exposed source references including:

https://d33wubrfki0l68.cloudfront.net/js/18393a7b4e6c50bdf31d721382e24fa2d7fb581d/build.js

From that script, three endpoints stood out:

• https[:]//challenges[.]laim[.]com/roombooking/
• https[:]//challenges[.]laim[.]com/roombooking/getrooms
• https[:]//challenges[.]laim[.]com/roombooking/sendpass

The endpoint naming looked like a fake booking flow designed to collect credentials and submit them backend-side.

Domain context for laim.com:

• Creation date: 2000-02-11
• Updated: 2026-01-14

Apex behavior:

• laim.com redirected to parked-domain sales landing
• 302 redirect observed to namekeen.com/landing/laim.com

Conclusion: likely abuse of an aged domain pattern (or a previously compromised asset), with phishing collection logic sitting on subdomain paths behind a Netlify-fronted lure.

MITRE ATT&CK Mapping

Mapping it out for the record.

Cross-Sample Observations

None of these campaigns were technically impressive, and they did not need to be. Across all three, the same ideas kept showing up:

• Urgency and interruption (account locked, invoice, browser error)
• Social engineering over technical depth
• Cheap, disposable infrastructure
• A simple click path that gets users where the attacker wants them

These kits do not need to be sophisticated to work. They just need to stay up long enough and look believable enough to get interaction.