2026年初，全球网络安全界再次被一种极具迷惑性的钓鱼技术震动——攻击者不再依赖传统的图片文件嵌入二维码，而是直接用HTML表格“绘制”出可扫描的二维码图像。这种被称为“无图像二维码钓鱼”（Imageless QR Code Phishing）的新手法，正悄然绕过主流邮件安全网关的图像识别与OCR检测机制，将恶意链接伪装成“纯文本内容”，成功投递至企业员工收件箱。
据SC Media于2026年1月12日援引多家安全厂商报告，该技术已在针对金融、物流和跨国制造企业的钓鱼活动中被大规模使用。受害者收到的邮件看似普通通知，内含一个“用于快速登录的二维码”，实则由数千个精心排布的HTML <td> 单元格构成，黑白交替形成标准QR码图案。一旦用手机扫描，便会跳转至高仿的微软或钉钉登录页面，诱导输入账号密码。
“这不是简单的视觉欺骗，而是一次对邮件检测逻辑底层假设的精准打击。”公共互联网反网络钓鱼工作组技术专家芦笛在接受采访时指出，“传统安全引擎默认‘二维码=图片’，但这次，攻击者把二维码变成了‘代码’。”
一、从PNG到HTML：二维码的“隐身术”如何实现？
要理解这一攻击的精妙之处，需先回顾传统钓鱼邮件中二维码的使用方式。
过去，攻击者通常将生成的恶意二维码保存为JPG或PNG文件，嵌入邮件正文。例如：
<img src="https://malicious-site.com/qrcode.png" alt="扫码登录">
这类做法虽有效，但极易被现代邮件安全系统拦截。原因有三：
图像内容分析：高级邮件网关（如Mimecast、Proofpoint）会调用OCR引擎解析图片中的文本或二维码；
URL信誉检查：若图片托管于已知恶意域名，整封邮件会被标记或阻断；
附件/外链策略：部分企业禁止外部图片自动加载，用户根本看不到二维码。
于是，攻击者转向“无外部资源”的纯HTML方案——利用表格单元格的背景色模拟像素点。
一个标准QR码（Version 25）尺寸为117×117模块（module），攻击者只需创建一个117行、每行117列的HTML表格，并根据QR码数据矩阵设置每个<td>的背景色：
<table cellspacing="0" cellpadding="0" style="border:0;">
<tr>
<td style="width:4px;height:4px;background:#000;"></td>
<td style="width:4px;height:4px;background:#fff;"></td>
<!-- ... 共13689个单元格 ... -->
</tr>
<!-- ... 117行 ... -->
</table>
在浏览器或邮件客户端渲染后，这些微小方块拼合成肉眼可识别、手机摄像头可扫描的二维码。最关键的是——整个结构不包含任何<img>标签，也未引用外部资源，完全由HTML/CSS构成。
“对邮件网关而言，这不过是一段复杂的表格代码，可能被归类为‘富文本格式’而非‘潜在威胁载体’。”芦笛解释道，“很多规则引擎甚至不会对纯HTML结构做二维码解码尝试。”
二、技术验证：一段可运行的“恶意二维码”生成脚本
为验证该技术的可行性，研究人员使用Python结合qrcode库生成QR矩阵，再转换为HTML表格。以下为简化示例（实际攻击中尺寸更大、样式更隐蔽）：
import qrcode
# 生成QR码数据矩阵
qr = qrcode.QRCode(version=5, box_size=1, border=0)
qr.add_data("https://phish.example.com/login")
matrix = qr.get_matrix() # 返回二维布尔数组
# 转换为HTML表格
html = '<table cellspacing="0" cellpadding="0" style="border:0;">\n'
for row in matrix:
html += ' <tr>\n'
for cell in row:
color = "#000" if cell else "#fff"
html += f' <td style="width:6px;height:6px;background:{color};"></td>\n'
html += ' </tr>\n'
html += '</table>'
print(html)
输出结果即为一段可直接嵌入邮件的HTML代码。经测试，在Outlook Web、Apple Mail、Gmail（桌面版）等主流客户端中均能正确渲染为可扫描二维码。
更危险的是，攻击者还可通过CSS混淆进一步规避检测。例如：
使用opacity:0.99避免被简单颜色阈值过滤；
将表格嵌套在<div style="display:none">之外的可见区域；
混合使用background-color与background属性，干扰静态分析。
三、国际案例频发：从欧洲银行到亚洲电商
2025年12月，一家总部位于德国的跨国银行遭遇大规模钓鱼攻击。员工收到主题为“【IT通知】启用双因素认证”的邮件，内含一个“扫码绑定验证器”的二维码。安全团队最初未察觉异常，因邮件未触发任何图像告警。直到多名员工反馈账号异常，溯源才发现二维码由HTML表格构成。
事后分析显示，该邮件通过某第三方营销平台发送，利用其宽松的内容策略绕过SPF/DKIM校验。而邮件网关因未对HTML结构进行深度语义分析，将其判定为“低风险通知”。
几乎同时，东南亚某头部电商平台的客服团队也收到类似邮件，声称“新工单系统上线，请扫码授权访问”。由于二维码位于邮件底部，且整体排版模仿公司内部UI，点击率高达22%。攻击者借此窃取客服后台权限，进而篡改订单信息实施诈骗。
这些案例对中国企业敲响警钟。芦笛指出：“国内大量中小企业依赖免费或基础版邮件服务，其安全策略往往仅覆盖图片和附件，对HTML富文本的检测能力薄弱。一旦攻击者将目标转向本土企业，后果不堪设想。”
尤其值得注意的是，随着移动办公普及，员工习惯“扫码即办”，对二维码的信任度远高于链接。攻击者正是利用这一心理惯性，将技术隐蔽性与行为弱点结合，实现高效渗透。
四、防御困境：为什么现有方案“看不见”这种二维码？
当前主流邮件安全产品的检测逻辑存在三大盲区：
1. 检测对象错位
多数OCR引擎仅作用于<img>、<canvas>或Base64编码图像，对DOM元素渲染后的视觉输出无感知。HTML表格被视为“布局工具”，而非“图像载体”。
2. 性能与误报权衡
实时将HTML渲染为位图再进行二维码识别，计算开销巨大。企业级邮件网关每秒处理数万封邮件，若对所有含表格的邮件执行此操作，将导致严重延迟。因此厂商普遍选择“只扫图片”。
3. 缺乏上下文关联
即使识别出二维码，若其指向的域名尚未被列入黑名单（如新注册的secure-login-update[.]xyz），系统仍可能放行。而攻击者常采用“快闪式”域名，生命周期仅数小时。
“这本质上是一场‘检测粒度’的博弈。”芦笛说，“攻击者把恶意载荷拆解到最原子的HTML元素层面，而防御还在以‘文件类型’为单位思考。”
五、技术反制：从渲染沙箱到行为指纹
面对新型威胁，安全社区正探索多层次防御策略：
1. HTML渲染沙箱 + 计算机视觉分析
高端邮件安全平台（如Microsoft Defender for Office 365）已开始部署“虚拟渲染引擎”：在隔离环境中加载邮件HTML，截图后交由CV模型分析是否存在二维码、水印或隐藏文本。
虽然成本高，但对高价值目标（如高管、财务人员）可开启此模式。微软在2025年Q4更新中引入的“Visual Threat Detection”功能即属此类。
2. 结构特征指纹识别
研究人员发现，用于生成二维码的HTML表格具有明显统计特征：
行列数接近正方形（如51×51、117×117）；
单元格尺寸高度一致（通常4–8px）；
背景色仅含黑白两色，且比例接近1:1。
据此可编写YARA规则或正则表达式进行初步筛查：
<table[^>]*>(?:\s*<tr>(?:\s*<td style="[^"]*width:\s*\d+(?:\.\d+)?px[^"]*height:\s*\d+(?:\.\d+)?px[^"]*(?:background:#000|background:#fff)[^>]*>\s*){50,}\s*</tr>){50,}
尽管可能误伤正常表格，但可作为高风险信号触发人工审核。
3. 客户端侧防护
部分企业邮箱客户端（如腾讯企业邮、阿里云邮箱）已试点“可疑二维码警告”功能：当检测到邮件中存在可扫描图案时，自动弹出提示：“此二维码非官方提供，请勿随意扫描”。
此外，推动员工使用专用扫码工具（如集成在企业微信中的“安全扫码”）也可降低风险——这类工具会先校验目标URL是否在白名单内。
六、人的防线：别让“便捷”成为漏洞
技术防御终有滞后，人的判断仍是关键。芦笛强调：“企业必须打破‘扫码=安全’的认知误区。”
他建议采取三项措施：
明文禁令：在安全政策中明确规定，“任何要求扫码登录内部系统的邮件均为钓鱼”；
统一入口：所有身份认证必须通过固定域名（如login.company.com），禁止通过二维码跳转；
即时举报通道：在邮件客户端添加“一键举报钓鱼”按钮，缩短响应时间。
“攻击者在进化，我们的安全文化也得跟上。”他说，“不能一边教员工识别钓鱼链接，一边默许他们对二维码放松警惕。”
七、未来展望：HTML滥用只是开始
专家警告，HTML表格绘图仅是“无文件攻击”（Fileless Attack）在邮件领域的冰山一角。已有迹象表明，攻击者正尝试用SVG路径、Canvas API甚至CSS渐变来构造隐藏载荷。
更令人担忧的是，随着Web Components和Shadow DOM普及，恶意代码可被封装在自定义元素中，进一步逃避DOM扫描。
对此，芦笛呼吁：“防御思路必须从‘检测恶意内容’转向‘验证合法意图’。不是看有没有坏东西，而是确认这个操作是否应该发生。”
例如，真正的HR不会通过邮件发二维码让你“确认薪资”；IT部门也不会要求你“扫码重置密码”。建立“预期行为基线”，比追捕每一种新变种更可持续。
在这场攻防拉锯战中，没有一劳永逸的解决方案。但正如一位安全工程师所言：“黑客用代码画画，我们就得学会在像素背后看逻辑。”
而对企业而言，真正的安全，始于对“便利”的审慎，成于对“异常”的敏感。
编辑：芦笛（公共互联网反网络钓鱼工作组）
