最后更新:2026年9月28日

Excel 文件安全解析:XLSX、XLSM 与宏风险
数十年来,Microsoft Excel 一直是业务运营的通用引擎。它平衡企业预算、可视化复杂数据集、跟踪库存,并在几乎所有行业中驱动分析流程。
然而,同样的计算灵活性使电子表格成为网络对手的长期青睐对象。自上世纪90年代末宏病毒早期以来,攻击者就已经将电子表格武器化。虽然 Microsoft 和系统管理员已经引入了多层防御——如文件格式隔离和默认宏阻止——但社会工程和细微的架构风险仍使针对 Excel 的攻击保持相关性。
要构建弹性的安全姿态,开发者、管理员和高级用户必须深入工作簿界面之下。了解底层 OpenXML 格式的工作原理、.xlsx 与 .xlsm 在架构层面的差异,以及宏执行机制的运作,对防御现代终端至关重要。
1. 现代 Excel 文件的结构:OpenXML 解析
在 Microsoft Office 2007 发布之前,Excel 主要使用专有的二进制格式保存文件,最典型的是 .xls 格式(受二进制互换文件格式,即 BIFF8 规范约束)。在 .xls 文件中,数据记录、格式定义、公式以及 Visual Basic for Applications (VBA) 宏流被打包进单一的结构化存储容器。这使得程序化检查变得困难,并让攻击者能够在不透明的二进制区块中隐藏恶意负载脚本。
自 Excel 2007 起,Microsoft 引入了 Office Open XML (OOXML) 标准(已标准化为 ECMA-376 和 ISO/IEC 29500)。在 OOXML 下,Excel 工作簿不再是单一的二进制块,而是包含 XML 文档、关系表和嵌入式媒体资源的层级结构的压缩归档文件。
ZIP 容器内部
如果您将任何标准的现代 Excel 工作簿的扩展名改为 .zip,就可以使用任何标准的解压缩工具提取其内容:
my_workbook.xlsx (extracted)
│
├── [Content_Types].xml <-- Registry of MIME types and structural parts
├── _rels/ <-- Package-level relationship mappings
│ └── .rels
├── docProps/ <-- Metadata (author, creation date, revision)
│ ├── app.xml
│ └── core.xml
└── xl/ <-- Core spreadsheet contents
├── workbook.xml <-- Workbook-level parameters and sheet list
├── styles.xml <-- Cell styles, fonts, and borders
├── sharedStrings.xml <-- Unique string index for performance optimization
├── _rels/
│ └── workbook.xml.rels <-- Sheet and component dependencies
└── worksheets/
├── sheet1.xml <-- Raw cell values, formulas, and grid geometry
└── sheet2.xml
这种结构性的转变立即带来了安全优势:
- DPI(深度数据包检查)和网关可视化: 安全设备、代理和终端代理可以即时解压归档并解析纯文本 XML 树,以识别可疑字符串、外部 URL 或嵌入对象。
- 确定性文件验证: 如果文件声称是 OpenXML 文档但违反了模式约束,Excel 将拒绝打开它,或在沙盒恢复模式下运行。
- 格式分离: Microsoft 将常规计算电子表格与能够执行嵌入过程脚本的文件分离。
2. XLSX 对比 XLSM:架构边界
.xlsx 与 .xlsm 的主要区别在于文件结构是否允许包含可执行的宏项目。
| 功能 / 维度 | .xlsx(Excel OpenXML 电子表格) | .xlsm(Excel 宏启用电子表格) |
|---|---|---|
| MIME 内容类型 | application/vnd.openxmlformats-officedocument.spreadsheetml.sheet | application/vnd.ms-excel.sheet.macroEnabled.12 |
| VBA 存储容器 | 严格禁止。 无法存储 vbaProject.bin | 允许。 包含 xl/vbaProject.bin |
| 本机执行风险 | 对宏执行的影响可忽略;仅限于公式注入/DDE | 高;在工作簿交互时可以运行自动化 VBA 代码 |
| OpenXML 严格模式 | 符合严格的、无宏的 XML 定义 | 包含对传统和现代自动化扩展的定义 |
| 用户视觉指示器 | 标准绿色电子表格图标 | 带感叹号标记的电子表格图标 |
执行机制:为何 XLSX 不能运行宏
在初级管理员和开发人员中常见的问题是:如果攻击者获取一个恶意的 .xlsm 文件,注入可执行代码,然后将文件扩展名改为 .xlsx,会发生什么?
简短的答案:该文件不会执行宏。
Excel 并不完全依赖文件扩展名来决定执行规则。打开一个名为 .xlsx 的文件时:
- Excel 检查 zip 包内容并引用
[Content_Types].xml。 - 在真实的
.xlsx文件中,所有定义的内容类型都代表标准数据元素(例如worksheet、sharedStrings或styles)。 - 如果攻击者手动将编译后的 VBA 流(
xl/vbaProject.bin)注入.xlsx包并更新关系,Excel 将遇到明确的模式冲突:- 它会看到一个
.xlsx扩展名绑定到指示宏功能的内容类型。 - Excel 抛出致命的完整性错误:“Excel 无法打开文件 ‘filename.xlsx’,因为文件格式或文件扩展名无效。请确认文件未损坏…”
- 它会看到一个
- 如果攻击者保持内部类型不变且不注册二进制文件,Excel 会将
vbaProject.bin视为 zip 存档中未引用的孤立附件,并在加载周期中完全丢弃它。
因此,**严格作为真实 .xlsx 容器运行的文件无法执行本机 VBA 代码。**然而,这并不意味着 .xlsx 文件没有任何攻击向量,后文将在本指南中进一步探讨。
3. 宏风险与攻击生命周期
宏被设计用于通过 Visual Basic for Applications(VBA)自动化重复的会计、财务建模和数据处理任务。由于 VBA 是为工作场所自动化而构建的,它通过组件对象模型(COM)、Windows 脚本宿主(WSH)以及直接的 Win32 API 调用,获得了对底层 Windows 操作系统的广泛访问权限。
当不受信任的宏执行时,它以 与登录用户完全相同的权限 运行。它并未被限制在虚拟化的类似 JavaScript 的浏览器沙箱中。
+--------------------------------------------------------------------------------+
| ATTACK LIFECYCLE |
+--------------------------------------------------------------------------------+
│
▼
[ Delivery & Evasion ] ──────► Spear-phishing email with .xlsm, .xlam, or .zip.
│
▼
[ Social Engineering ] ──────► Lures victim to bypass Protected View ("Enable Content").
│
▼
[ Auto-Execution ] ──────► Auto_Open() or Workbook_Open() triggers automatically.
│
▼
[ System Invocation ] ──────► VBA creates COM objects (WScript.Shell, WinHttp.WinHttpRequest).
│
▼
[ Payload Retrieval ] ──────► Spawns hidden PowerShell/cURL to fetch staging binary.
│
▼
[ Post-Exploitation ] ──────► In-memory execution, credential theft, lateral movement.
常见宏入口技术
自动执行钩子: 攻击者将入口点放置在内在事件处理程序中,例如
Sub Auto_Open()或Private Sub Workbook_Open()。只要用户授予执行权限,这些例程就会触发,无需在电子表格内进行任何点击。混淆与压制:
- 字符串混淆: 负载使用字符数组、XOR 编码、Base64 解码或环境变量拼接来隐藏 URL 和系统调用(例如
Chr(112) & Chr(111) & Chr(119)...)。 - VBA 压制: VBA 在
vbaProject.bin中以两种形式存在:解释型源代码和已编译的 p-code(针对编译它的特定 Office 版本的伪代码)。攻击者可以完全擦除明文源代码,只留下已编译的 p-code。许多基础的杀毒软件和静态分析器仅检查源代码流,导致 p-code 在匹配的 Office 版本执行前未被检测到。
- 字符串混淆: 负载使用字符数组、XOR 编码、Base64 解码或环境变量拼接来隐藏 URL 和系统调用(例如
利用系统自带工具 (LotL): 现代恶意宏很少直接将
.exe文件写入磁盘,因为这会立即触发端点检测与响应(EDR)代理。相反,它们会利用内置系统工具:- 实例化
WScript.Shell来执行命令行参数。 - 调用
PowerShell.exe并使用执行策略绕过 (-ExecutionPolicy Bypass -WindowStyle Hidden)。 - 通过
Declare PtrSafe Function CreateProcess或VirtualAlloc调用本机 Win32 API,将 shellcode 直接注入系统内存。
- 实例化
4. 其他电子表格威胁向量(超出标准 VBA)
仅仅防御 .xlsm 文件只能算是防御的一半。攻击者还会使用独立于传统 VBA 的机制。
动态数据交换(DDE)和 CSV 注入
Excel 包含一种名为动态数据交换(Dynamic Data Exchange,DDE)的旧协议,旨在实现运行中应用程序之间的数据共享(例如,将来自其他程序的实时股票行情数据流式传输到 Excel 单元格中)。
- 公式注入的工作原理:
当电子表格单元格以
=,@,+或-等字符开头时,Excel 会将其内容解释为公式。如果攻击者控制导出到电子表格的输入(例如,未经过清理的 Web 应用程序中的 “Comments” 字段导出为 CSV 或 XLSX),他们可以注入:=cmd|'/C powershell.exe -w hidden -enc <base64_payload>'!A0 - 打开后,Excel 会计算该公式,弹出提示询问是否启动外部应用程序,若用户批准,则运行系统 shell。
Excel 4.0(XLM)遗留宏
在 1993 年引入 VBA 之前,Excel 使用一种基于公式的宏系统,称为 Excel 4.0 (XLM) 宏。这些宏位于专用的宏工作表中,而不是单独的 VBA 项目。
由于 XLM 宏是以单元格公式的形式编写的(例如 =EXEC("calc.exe")),它们可以绕过许多标准的 VBA 静态检查引擎。攻击者在 2010 年代后期和 2020 年代初期偏好使用 XLM 宏,以规避自动检测,直至 Microsoft 在现代企业版中默认禁用它们。
恶意外部连接和 OLE 对象
普通的 .xlsx 工作簿仍可能通过外部资源带来风险:
- 嵌入的 OLE 包: 攻击者可以将伪装成嵌入式 PDF 图标的可执行文件直接插入工作表。
- 外部工作簿链接和网络查询: XLSX 文件可能包含外部引用,在打开文件时会自动发起对攻击者控制的指挥控制 (C2) 服务器的 HTTP GET 请求,主要用于侦察或 netNTLM 哈希收集攻击。
5. 企业加固与纵深防御策略
防御 Excel 相关威胁需要采用分层方法,涵盖网络检查、系统配置、访问控制和运营流程。
+─────────────────────────────────────────────────────────+
| ENTERPRISE DEFENSE LAYERS |
+─────────────────────────────────────────────────────────+
| PERIMETER: Drop inbound .xlsm, .xla, and .xltm at mail |
| gateway unless cryptographically signed or exempted. |
+---------------------------------------------------------+
| IDENTITY & POLICY: Enforce ASR rules and apply |
| Mark of the Web (MotW) macro execution blocks. |
+---------------------------------------------------------+
| RUNTIME: Hook AMSI into Office to evaluate dynamic |
| VBA buffers directly before execution. |
+---------------------------------------------------------+
| STORAGE: Restrict macro execution exclusively to |
| managed, centralized Trusted Locations. |
+─────────────────────────────────────────────────────────+
1. 强制执行网页标记 (MotW) 宏阻止
2022 年,Microsoft 更新了 Office 应用程序的默认行为:来自互联网的文件中的宏 默认被阻止。
当用户通过浏览器或外部客户端下载文件时,Windows 会使用名为 Zone.Identifier 的备用数据流 (ADS) 为文件打标签(Zone 3 表示互联网)。对于带有此标记的文件,Excel 会完全禁用宏并显示红色安全横幅:> “安全风险:Microsoft 已阻止宏运行,因为此文件的来源不受信任。”
管理操作: 确保通过组策略强制执行此行为,且终端用户无法覆盖:
- GPO 路径:
User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center - 设置: 启用 “Block macros from running in Office files from the Internet”。
2. 配置攻击面降低 (ASR) 规则
使用 Microsoft Defender for Endpoint 的组织应激活专为 Office 应用程序设计的核心攻击面降低规则:
Block Office applications from creating child processes(GUID:D4F940AB-401B-4EFC-AADC-AD5F3C50688A)- 阻止 Excel 启动 PowerShell、CMD 或脚本引擎。
阻止 Office 应用程序向其他进程注入代码(GUID:75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84)阻止 Office 宏调用 Win32 API(GUID:92E6390C-CF9E-43CE-BD8C-0E6F0FE66680)
3. 利用反恶意软件扫描接口 (AMSI)
Microsoft 365 的现代版本将 VBA 执行直接集成到 AMSI 中。即使攻击者使用复杂的字符串混淆或 VBA 覆盖,VBA 运行时引擎也会在执行前的毫秒级时刻将重建的未加密命令传递给已安装的防病毒/EDR 引擎。确保您的终端防护能够主动监控 AMSI 运行时事件。
4. 转向受信任位置和数字证书
对于依赖自动化电子表格进行日常运营的组织:
- 消除用户下载或桌面文件夹中的松散 XLSM 文件。
- 使用受信任位置: 将宏执行限制仅在由 IT 管理员管理的只读网络共享上进行。
- 代码签名: 强制所有内部开发的宏使用企业公钥基础设施 (PKI) 颁发的证书进行加密签名。配置 Excel 执行 仅 数字签名的宏,并静默阻止未签名的宏。
6. 开发者视角:构建安全自动化
如果您正在构建解析、生成或使用 Excel 文件的软件(例如,使用 pandas/openpyxl 的 Python 流程、Node.js 微服务或 C#/.NET 应用程序),请采用以下开发安全措施:
在上传边界拒绝意外的文件格式: 如果您的应用程序需要处理财务报告,请严格验证传入文件是否符合
.xlsx格式。检查内部魔术字节(标准 zip 头50 4B 03 04),并在将文件保存到云存储桶或数据库之前,确认归档索引中不存在vbaProject.bin条目。对数据进行清理以防止公式注入: 在将用户生成的输入导出为 CSV 或 XLSX 文件时,在任何以危险字符(
=,+,-,@,\t,\r)开头的单元格前加上撇号(')或空格:def sanitize_for_spreadsheet(value: str) -> str: if value and value[0] in ('=', '+', '-', '@', '\t', '\r'): return f"'{value}" return value从 VBA 迁移到 Office Scripts 或 Web 加载项: 对于现代企业自动化,彻底淘汰传统 VBA:
- Office Scripts: 使用 TypeScript 编写,Office Scripts 在沙盒化的云环境中运行,并可在网页和桌面版本中顺畅工作,而不会暴露本机操作系统调用。
- Office Web Add-ins: 使用标准的 HTML、CSS 和现代 JavaScript 构建,Web 加载项通过受管的 JavaScript API 进行通信,并且与本地操作系统隔离。
7. 电子表格安全性摘要检查清单
- 默认强制使用
.xlsx: 要求所有标准用户工作流保存为无宏的.xlsx。 - 阻止来自互联网的宏: 确认已通过 GPO 或 Intune 在整个组织中部署 MotW 策略强制执行。
- 启用 ASR 规则: 禁止 Office 产品生成命令解释器或子进程。
- 弃用 Excel 4.0 (XLM): 确保在所有工作站上永久禁用旧版 XLM 宏引擎。
- 清理应用导出: 保护 CSV 和 Excel 生成例程免受 CSV/公式 注入攻击。
- 转向 Office Scripts: 将传统的管理宏迁移到基于 TypeScript 的 Office Scripts 和受管 API。
通过将电子表格视为不仅是文档文件,而是具备执行能力的结构化软件容器,安全团队和开发人员能够有效地中和企业计算中最古老的攻击向量之一。
常见问题解答(FAQ)
Q1: 以 .xlsx 结尾的文件能运行恶意宏吗?
不,OpenXML 标准严格禁止在 .xlsx 文件中包含宏代码,Excel 会拒绝或剥离任何注入到真实 .xlsx 容器中的 VBA 项目。
Q2: 如果 Excel 文件要求我“启用编辑”或“启用内容”,我该怎么办?
仅在你认识发送者并且预期收到该文件时才授予权限;此提示是允许不受信任宏执行代码的主要检查点。
Q3: Microsoft Excel 如何判断文件是否来自互联网?
Windows 会在下载的文件上附加一个隐藏的 “Web 标记”(Zone.Identifier) 流,这会告诉 Excel 默认在受保护视图中打开它们并阻止宏。
Q4: CSV 文件比 XLSX 和 XLSM 文件更安全吗?
CSV 文件不能包含原生 VBA 宏,但如果其中包含恶意指令,Excel 在打开时执行这些指令,它们仍然容易受到公式注入攻击。
Q5: 现代 Office 脚本与传统 VBA 宏有何区别?
Office 脚本在 TypeScript 上运行于沙箱运行时环境中,阻止它们访问本地文件系统、命令行或操作系统 API。