看不见的陷阱：黑客用HTML表格“画”出恶意二维码，绕过企业邮件防线-平芜编程栈

2026年初，全球网络安全界再次被一种极具迷惑性的钓鱼技术震动——攻击者不再依赖传统的图片文件嵌入二维码，而是直接用HTML表格“绘制”出可扫描的二维码图像。这种被称为“无图像二维码钓鱼”（Imageless QR Code Phishing）的新手法，正悄然绕过主流邮件安全网关的图像识别与OCR检测机制，将恶意链接伪装成“纯文本内容”，成功投递至企业员工收件箱。

据SC Media于2026年1月12日援引多家安全厂商报告，该技术已在针对金融、物流和跨国制造企业的钓鱼活动中被大规模使用。受害者收到的邮件看似普通通知，内含一个“用于快速登录的二维码”，实则由数千个精心排布的HTML <td> 单元格构成，黑白交替形成标准QR码图案。一旦用手机扫描，便会跳转至高仿的微软或钉钉登录页面，诱导输入账号密码。

“这不是简单的视觉欺骗，而是一次对邮件检测逻辑底层假设的精准打击。”公共互联网反网络钓鱼工作组技术专家芦笛在接受采访时指出，“传统安全引擎默认‘二维码=图片’，但这次，攻击者把二维码变成了‘代码’。”

一、从PNG到HTML：二维码的“隐身术”如何实现？

要理解这一攻击的精妙之处，需先回顾传统钓鱼邮件中二维码的使用方式。

过去，攻击者通常将生成的恶意二维码保存为JPG或PNG文件，嵌入邮件正文。例如：

这类做法虽有效，但极易被现代邮件安全系统拦截。原因有三：

图像内容分析：高级邮件网关（如Mimecast、Proofpoint）会调用OCR引擎解析图片中的文本或二维码；

URL信誉检查：若图片托管于已知恶意域名，整封邮件会被标记或阻断；

附件/外链策略：部分企业禁止外部图片自动加载，用户根本看不到二维码。

于是，攻击者转向“无外部资源”的纯HTML方案——利用表格单元格的背景色模拟像素点。

一个标准QR码（Version 25）尺寸为117×117模块（module），攻击者只需创建一个117行、每行117列的HTML表格，并根据QR码数据矩阵设置每个<td>的背景色：

<tr>

</tr>

</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滥用只是开始