Email Phishing Engineering · 5: Linkless Delivery & QR Codes

This is Part 5 of the “Email Phishing Engineering” series. It is short on purpose: there is not much left to say, so this post simply opens the QR delivery pipeline as a work-in-progress.

0x01 Design origin: danger does not have to live in the URL#

1.1 The implicit axiom of SEG pipelines#

Mainstream secure email gateways—whether open-source stacks in the SpamAssassin/Rspamd tradition or commercial SEGs such as Defender and Proofpoint—tend to share the same pipeline for “link-class” threats:

MIME unpack → extract URLs from text/HTML → reputation / sandbox / rewrite

Part 3’s Bayes and NLP sit on the content scoring side of this pipeline; Parts 4/5 discuss how a phishing site stays alive after the click. The whole chain rests on a premise that rarely makes it into requirements docs:

The threat carrier will ultimately appear as a string-form URL in a parseable mail layer.

“Linkless delivery” is not rhetoric; it is a negation of that axiom. The negation shows up in at least two engineering shapes:

Payload shape and persistence differ. Before we go further, a brief look at Exchange calendar phishing.

0x02 The calendar channel: CalPhishing#

2.1 What iCalendar / iMIP looks like in email#

RFC 5545 defines calendar objects; when delivered by mail, iMIP (RFC 6047) is common. On the MIME side a typical form is:

Content-Type: text/calendar; method=REQUEST; charset="UTF-8"

Or the .ics is attached. The core is VEVENT. METHOD:REQUEST means “please treat this as a meeting request.”

By abusing iCalendar (.ics), an attacker can—under some client/tenant policies—push insufficiently validated meetings into the user’s calendar (Outlook often surfaces them as something like “Tentative”). Whether the user deleted the original message is one question; whether the invite already landed in the calendar service is another.

2.2 Why this is harder to defend than an exe in an attachment#

The traditional attachment threat model is: attachment = potentially executable / macro / script → sandbox. In most cases .ics is classified as structured data, routed through a calendar parser, and never hits the main attachment-threat path.

Persistence makes it worse:

• Deleting the original mail is not the same as deleting the calendar item;

• Delete it on the desktop and the phone sync may still hold it.

2.3 Implementation-layer risk: CVE-2025-27915#

The calendar channel is not only social engineering. The publicly disclosed CVE-2025-27915 (Zimbra Classic Web Client) is a stored XSS from insufficient sanitization of calendar-related content. It has been used in targeted campaigns and is listed in CISA KEV. Public reporting ties it to malicious .ics delivery paths.

Engineering implication:

• When the implementation is buggy, .ics can be an RCE / session-surface risk, not merely a pop-up social-engineering trick;

0x03 QR codes: the control plane is physically split#

3.1 Migration model#

The user reads mail on the office PC, pulls out a phone, and scans—within seconds:

Desktop (often: EDR / AV / enterprise proxy)
        │  camera scan
        ▼
Phone (often: no EDR / mobile network / personal device)
        │
        ▼
Landing page / phishing site

Where QR sits in detection:

• There is a URL, so this is not truly linkless;

• The URL is not in the text layer, so SEG main paths that extract <a href> are blind to it;

• The open happens on another control plane, so desktop-side EDR / AV / proxy policy may never see the hop that actually loads the landing page.

3.2 TaiGong’s implementation approach#

Engineering splits into two halves, matching two exercise postures:

1. Embed at send time: if the template field qrsize (JSON qrsize) is non-empty, generate a QR; models/qr_code.go uses skip2/go-qrcode to produce a PNG → base64; when EmailRequest has a value in QRBase64, it appends an image/png attachment (vanillaFile).

2. On-the-fly image from the phishing site: /qrcode (QRHandler), gated by EnableQRCode; when off, unknown traffic is handled like other unknown traffic with a camouflaged 404/redirect (same philosophy as Part 4).

0x04 Closing#

Parts 3/4 assume “the click is on a link in the mail.” This part is about linkless delivery: moving the detection surface from the client onto the mobile end. There should still be a later piece on an LLM polymorphic template-generation engine; beyond that I probably will not write more (absent major updates, existing capabilities are largely enough).

Series navigation

• Part 1: GoPhish’s Ceiling
• Part 2: Untraceable Infrastructure
• Part 3: Bayesian & NLP Content Adversarial
• Part 4: Parameter Polymorphism & Response Camouflage
• Part 5: Linkless Delivery & QR Codes ← this post
• Part 6: BEC 3.0 & Cross-Channel Orchestration