邮件钓鱼攻防工程·5：无链接投递与 QR 码

本文是「邮件钓鱼攻防工程」系列的第 5 篇。篇幅不长：其实没啥好说的了，所以单纯拎二维码投递链路实现开个坑。

0x01 设计原点：危险不一定住在 URL 里#

主流邮件安全网关（无论是 SpamAssassin/Rspamd 思路的开源栈，还是 Defender / Proofpoint 一类商业 SEG）在「链接类威胁」上，常见是同一条流水线：

MIME 拆包 → 文本/HTML 抽 URL → 信誉 / 沙箱 / 重写

bash

Part 3 的贝叶斯与 NLP，加在这条流水线的内容评分侧；Part 4/5 讨论点击之后钓鱼站怎么活。整条链有一个很少写进需求文档的前提：

威胁载体最终会以「字符串形式的 URL」出现在可解析的邮件层里。

「无链接投递」不是修辞，而是对这条公理的否定。否定至少有2种工程形态

形态	信任从哪迁到哪	网关「抽 URL」是否还在主路径上
日历 / `.ics`	邮件客户端 → 日历库 → 系统通知	常常不在：入口是 `text/calendar` 或附件
二维码	桌面渲染环境 → 手机相机与蜂窝出口	在图里：有 URL，但不在文本抽取层

payload 形态和持久性都不同。再次之前，可以先聊一下Exchange日历钓鱼。

RFC 5545 定义日历对象；经邮件投递时常用 iMIP（RFC 6047）。MIME 上典型是：

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

bash

或把 .ics 当附件。核心是 VEVENT。METHOD:REQUEST 表示请把这件事当作会议请求处理。

攻击者利用 iCalendar（.ics）文件，能在部分客户端/租户策略下，把未充分验证的会议推进用户日历（例如 Outlook 侧常见「暂定」一类呈现）。用户有没有删原邮件是一回事；邀请是否已经进入日程服务是另一回事

传统附件威胁模型是：附件 = 潜在可执行 / 宏 / 脚本 → 沙箱检测。.ics 大部分情况被归类为结构化数据，走日历解析器，不走附件威胁主路径。

更麻烦的是持久性：

日历通道不只有社工。2025 年公开的 CVE-2025-27915（Zimbra Classic Web Client）是对日历相关内容消毒不足导致的存储型 XSS，已被用于定向活动，并进入 CISA KEV。公开报道将其与恶意 .ics 投递路径联系在一起。

工程含义：

用户在办公 PC 看信，掏出手机扫码——几秒内发生：

桌面（常：EDR / AV / 企业代理）
        │  相机扫码
        ▼
手机（常：无 EDR / 移动网络 / 个人机）
        │
        ▼
落地页 / 钓鱼站

bash

二维码在检测上的位置是：

工程上分两截，对应两种演练姿势：

发信嵌入：模板字段 qrsize（JSON qrsize）非空则生成二维码；models/qr_code.go 用 skip2/go-qrcode 出 PNG → base64；EmailRequest 在 QRBase64 有值时追加 image/png 附件（vanillaFile）。
钓鱼站即时出图：/qrcode（QRHandler），受 EnableQRCode 控制；关闭时与未知流量一样走伪装 404/跳转（与 Part 4 未知流量哲学一致）。

Part 3/4 默认「点的是邮件里的链」。本篇是无链接投递，把检测面从客户端放到移动端上。后面应该还会有一篇LLM多态化生成文案模板的引擎介绍，别的应该不会再写了（没有大更新的前提下，现有的能力基本也够用了。）

系列导航