3.2 文档宏与浏览器脚本载体

3.2 文档宏与浏览器脚本载体

本节摘要：如果给过去二十年恶意代码的投递渠道排座次，文档类附件会以压倒性优势夺冠。原因不复杂：企业对办公文档的信任根深蒂固，而现代文档本质上是"压缩包加嵌入式程序"的复合体，既能夹带逻辑又天然越过可执行文件审查。本节拆解宏、嵌入对象、浏览器脚本三类载体的运作机制，并给出组织层面的治理清单。

一、问题与直觉：为什么是文档

先想清楚一个不对称性。对绝大多数用户来说，双击一个来路不明的 exe 是需要犹豫的动作，而打开一份 Word 简历、一张 Excel 对账单、一份 PDF 报价书几乎不需要任何心理建设——它们看起来是"内容"而不是"程序"。攻击者要的正是这层认知偏差。

技术侧的便利同样关键。现代办公文档格式普遍采用容器化设计：一个 docx 或 xlsx 解开就是一组结构化部件的打包目录，正文之外完全可以容纳宏代码、嵌入对象、外部模板引用等"活物"。安全网关若只做文件类型与静态特征检查，很难断言一份文档里是否藏着动态逻辑。

二、宏机制的前世今生

宏的本意相当正当：把重复操作录制成小程序，让财务自动化报表、行政批量改格式。早期版本对宏几乎零设防，导致九十年代末邮件蠕虫借宏兴风作浪（第 5 章复盘的梅丽莎正是第一个现象级案例）。此后厂商把安全模型层层加固为今天的样子：

这张表的最后一列暴露了防御的真实形态：技术闸门基本可靠，短板始终在人与配置上。"请到受信任位置运行此文档""你的杀毒软件较旧，请点击启用宏查看内容"这类话术直接瞄准流程缝隙。

三、一段载体的解剖实录

下面用一个分析视角还原典型钓鱼宏的处理链条，全部动作属于观察性的静态检查：

样本背景：一封伪装成货运通知的邮件，附件名为 运单明细.docm
──────────────────────────────────────────────────────
[1] 类型甄别
    扩展名 m 结尾提示含宏；先在隔离虚拟机中副本操作。
[2] 结构拆解（不解码，仅看骨架）
    - 重命名为 zip 后缀解包，可见部件树中存在 vba 工程目录，
      与普通仅含正文的 docx 形成鲜明对比；
    - 检查工程描述字段，空描述但体积偏大者可疑度上升。
[3] 宏文本导出审阅
    - 导出 VBA 文本做人工阅读，重点看三类语句：
      进程创建调用、字符串解码函数、写入自启位置的调用；
    - 混淆代码常见形态为超长变量名加字符拼接，此时不改原文，
      转向记录行为而非逐行翻译。
[4] 动态确认
    - 虚拟机内允许执行，同步记录进程链：
      文档进程 → 脚本宿主 → 远端命令解释器，
      这条祖孙链一旦出现即可定性投递型木马。
[5] 情报沉淀
    - 提取回连指示器入库，供网关反向封堵同类样本。
​

注意第四步的父子进程链记录——这就是第 2 章反复强调的行为语义观测在真实场景中的样子。宏可以千变万化地混淆自己，但"办公软件生出系统命令解释器"这件事本身骗不了人。

四、浏览器脚本：第二战场

网页脚本是宏的近亲，区别在于它的宿主是浏览器沙箱。设计者的本意是把页面代码关进笼子：不得随意读写本地文件、不得跨站读取数据。但两个因素让它长期构成威胁面。

其一是漏洞窗口。渲染引擎代码量巨大，解析畸形图片或字体时的内存缺陷时有披露，利用此类缺陷的页面可以在用户仅仅浏览时就突破沙箱——这也是"不要访问奇怪网站"这种朴素建议背后的技术根据。

其二是合法性掩护。挖矿劫持门户把计算代码嵌进正常页面，访客浏览新闻的几分钟里 CPU 被拿去替别人干活；假更新弹窗则用页面脚本伪造出逼真的系统对话框。两者都无需攻破什么，纯粹借助"网页本来就是程序"这一事实。

五、组织治理清单

把本节内容折算成一份能落地的最低配置要求：

办公终端基线建议（文档与网页载体部分）
──────────────────────────────────────────
· 外部来源文档默认禁用宏，白名单例外走审批留痕
· 关闭"受信任位置"中一切指向用户可写目录的条目
· 邮件网关剥离或隔离可执行类扩展与宏文档组合件
· 浏览器统一策略：禁用过期插件、限制站点弹窗权限
· PDF 阅读器关闭脚本执行与未知协议跳转
· 关键岗位演示环境独立于日常办公域（示例外发场景隔离）
​

这些项没有一条涉及高深产品，照着核对一遍内网终端合规率，通常就能发现两位数的偏差——正是这些偏差构成了第 5 章那些疫情复盘里最常见的起点条件。

问题：既然外部宏默认禁用，为什么实务中总是禁不干净

因为总有一批"业务刚需"站在对立面：某些老版财务控件、供应商交付的报表模板、行业主管部门下发的申报文件，全靠宏活着。硬刚的结果通常是安全部门被业务部门绕过，策略一纸空文。可行的折中是把例外管起来而不是假装例外不存在：盘点全组织真正依赖宏的业务清单，逐项指定专用终端或独立账号；供应商侧推动改用网页端或服务接口替代桌面宏——谈判筹码就是那句朴素的话术反制——"贵司的模板要求客户关闭安全配置，这个风险谁背"。多数僵持多年的例外，最后都死在了升级后的新版模板上。治理对象从来不是技术，是存量流程。

六、两类载体的共同软肋：信任的传递路径

收束前值得退一步看宏观。文档与网页这两条战线，技术上相去甚远，攻防逻辑却共享同一根轴：它们都是把"信任"从执行层预支到内容层的通道。用户对内容的信任被兑换为程序的运行权——文档如此，网页如此，未来任何"看起来是内容、实际上是程序"的新形态（协作平台的内嵌组件、办公套件的自动化插件）都会重演同一个剧本。识别这一规律后，治理清单就能举一反三：凡是允许内容携带可执行逻辑的产品引入，都应过一遍同样的三问——谁能投递它、运行时能碰到什么、出事后能否追溯。载体常换，三问不变。

本节要点回顾

• 文档统治投递榜靠的是认知落差：内容打开无戒心，程序执行有防备。
• 宏安全模型的四层闸门里，唯一真正的软肋是人为话术诱导与受信任位置滥用。
• 分析含宏样本的标准流程：类型甄别、结构拆解、文本审阅、动态确认、情报入库五步闭环。
• 行为链定性优先于代码翻译——办公进程派生命令解释器即宣告性质。
• 浏览器威胁的两张面孔：漏洞型突破沙箱与合法型滥用算力，对策分别是及时更新与站点信誉治理。
• 基线配置的合规巡检比采购新设备更能立竿见影地收窄这一战场。

平台篇还剩两块新大陆：装在口袋里的移动生态，以及边界日益消融的云端与物联网。下一节先看移动双雄的安全账本。