★ FEATURED ARTICLE 1. 漏洞全貌金刚狼 SharePoint 漏洞为什么会成为焦点最近安全圈里讨论最热的一个词就是“金刚狼”代号来自某个安全团队的漏洞命名习惯实际指的是一个影响 Microsoft SharePoint 的高危漏洞编号 CVE-2025-53770。最初看到“实战注入内存马”这个说法很多人第一反应是攻击方又在炫技但从我们搞防御和应急响应的视角看这恰恰是一个必须认真对待的信号攻击者已经把手伸进了 SharePoint 的进程内部用内存马的方式突破了传统文件查杀的边界。先说影响面。SharePoint 是什么它是很多企业和机构内部文档管理、门户网站、协作办公的核心系统几乎等同于组织内部的“数字中枢”。一旦这个系统被打穿意味着攻击者可以直接读取内部文件、获取用户凭证、横向移动甚至以服务账号身份在内网畅通无阻。而 CVE-2025-53770 这个漏洞的特点是它不需要复杂的身份认证条件在特定版本下可以远程触发配合内存马技术后恶意代码根本不落盘常规的安全设备很难察觉。从漏洞命名来看“金刚狼”是个很贴切的代号因为它的恢复能力和隐蔽性很像那个电影角色。攻击者把恶意代码注入到 SharePoint 的进程内存中即使系统重启、文件被查杀只要内存马还在进程恢复后它又会跟着活过来。我们团队在一次模拟演练中复现了类似场景发现从注入到完全控制整个过程可以快到分钟级而期间的日志痕迹如果不是盯着看几乎不会注意到异常。对一个安全从业者来说看到这种标题第一反应不是兴奋而是紧张。因为内存马不是新概念Java Web 应用里的内存马大家都熟但在 SharePoint 这种 Windows 生态、NET 体系下的商业产品里内存马的植入路径和检测难度都不一样。这篇文章我打算从攻击者的思路推演开始再反推到我们该如何检测、如何止血、如何加固。如果你是负责企业安全、运维 SharePoint 的同行或者正在做日志分析和应急响应这篇内容会给你一个相对完整的参考框架。2. 攻击链路推演与关键载荷分析2.1 利用前置条件与入口先明确一点CVE-2025-53770 并不是一个“裸奔”的漏洞它需要几个前置条件才能达到内存马注入的效果。根据漏洞公告和多个团队的分析影响的主要是 SharePoint Server 的某些特定版本尤其是开启了自定义表单验证或允许匿名访问的部分站点拓扑。攻击者首先要能向 SharePoint 发起特定的构造请求这个请求会在服务器端触发某个组件的反序列化逻辑从而绕过常规的权限校验。这里的“反序列化”是很多同类漏洞的核心。简单打个比方序列化是把对象变成字节流以便传输反序列化就是收到字节流后重新还原成对象。如果还原过程中没有做严格的类型校验攻击者就可以在流量里夹带“私货”——一个精心构造的恶意对象。SharePoint 的这个漏洞正是某个常见组件在处理请求时对传入的数据类型没有白名单限制导致攻击者可以把一段可执行的载荷“喂”给服务器。入口上实测下来有两种常见路径一种是通过 SharePoint 的某些 API 接口直接提交另一种是借助上传功能把构造好的文件传上去再触发解析。无论是哪种攻击者都需要先摸清当前系统版本和具体组件位置所以前期信息收集是少不了的。但从漏洞利用本身来说它并不需要管理员权限这也是它被评估为高危的核心原因。2.2 内存马的注入方式与生命周期攻击者拿到代码执行权限后第一件事不会去写文件因为写入文件会触发 EDR 和杀软的行为监控。他们的选择是把恶意代码加载到当前进程的内存空间最常见的方式是反射调用某个.NET 组件动态注册一个 Web 处理接口。这样恶意逻辑就寄生在 SharePoint 的进程里外部访问某个隐蔽的 URI 就能触发后门行为。内存马的“生命周期”管理是攻击者比较上心的地方。为了不让进程崩溃他们会把注入的代码挂接到某个长期运行的事件上比如请求管道过滤器或者定时任务回调。攻击者还会做“保活”设计一旦主进程重启只要 IIS 工作进程重新加载了相关的托管模块内存马就能被再次激活。这也是内存马比传统 WebShell 难清的原因你不光要杀掉线程还得找到注入源否则清了又长。从我们做应急响应的经验看注入成功后门通常会做三件事第一回连到攻击者的控制端确认通道畅通第二收集当前进程上下文里的身份凭证包括 SharePoint 用户令牌和服务账号密码第三把自己的权限降级伪装成正常模块避免出现明显的异常进程图标或命令行。整个流程走下来攻击者可以做到很低调的长期驻留。2.3 实战中攻击者最常利用的载荷在多个安全社区通报的样本分析中内存马载荷并不花哨反而非常“务实”。常见的有这么几类内存版 WebShell响应特定请求头的内容例如自定义 Header 加上密钥就返回命令执行结果。内存转发代理把 SharePoint 收发的流量转发到一个隐蔽隧道用于内网穿透和数据窃取。凭证窃取器直接挂钩认证模块在用户登录时把明文密码或 HASH 同步给攻击者。定时触发器每隔一段时间检查 Control 端指令动态更新恶意逻辑。为什么选这些载荷因为它们运行在合法进程里没有独立进程的痕迹交互也不是普通的 HTTP 那样直接所以流量检测设备很难区分。而且 .NET 环境下的内存马不用编译成独立的 EXE可以直接用 PowerShell 反射加载或通过 C# 代码动态编译门槛并不高网上也有很多公开的研究代码。但对防守方来说这就意味着必须把监控下沉到进程内部而不能只看文件和端口。3. 检测与排查如何发现内存马3.1 内存马查杀的难点很多朋友问我内存马是不是就查不出来其实不是检测内存马没有一劳永逸的工具但有行之有效的方法。难点在于你需要同时掌握“行为”和“关联”两层证据。比如一个 SharePoint 工作进程 wp3.exe 内存占用比平时多了 300MB光看这个你不会紧张但如果这个进程对应的站点根本没有文件变更却频繁和外部 IP 通信那就要警惕了。另一个难点是内存马实现方式的差异。有的内存马直接注册为托管模块有的则通过反射动态生成一个类挂进程序集。普通文件系统扫描根本看不到杀毒软件也不会报。我们曾经在一个客户现场碰到的情况是用微软官方的 Process Explorer 查到的线程和模块列表很正常但用 .NET 调试器一附加就能发现有十几个异常的程序集加载记录。所以查内存马不能用通用工具一把梭要有针对性地用框架级监控方案。还有一点需要特别注意SharePoint 本身会有大量正常的内存操作和动态代码加载比如工作流引擎、事件接收器它们都会在进程内动态编译。这会导致误报率很高。我们采用的方法是先建立基线在系统刚装好、没有异常行为的时候采样正常状态下的程序集列表、模块列表和网络连接把基线存在安全分析平台上。之后每次排查用当前状态对比基线差异部分才需要人工确认。3.2 排查清单结合我们的应急响应流程推荐你按下面的清单来排查检查 IIS 应用池对应的进程w3wp.exe 或 Microsoft SharePoint Foundation Workflow Service重点看加载的托管模块列表。内存马必然会增加新的类型或模块引用哪怕是动态生成的程序集也能在模块列表里看到异常项。用 .NET 性能计数器观察进程里 JIT 编译次数。如果某台 SharePoint 服务器没有大量代码变更但 JIT 编译次数异常升高说明有新的代码被动态执行。查看进程的线程栈找有没有反复执行同一个非官方命名空间的代码。内存马为了保活通常会在后台线程里循环这个特征比较明显。检查文件系统里最近被修改的动态链接库文件和配置文件特别是一些原本不常变的目录。内存马加载可能依赖某些 DLL 的影子文件或者通过修改 web.config 添加模块注册。分析访问日志里的异常 URI。内存马会有一个访问触发点往往是一长串看似随机的路径同时带有特定的查询字符串。清单最后是检查服务器对外连接。用 netstat 或防火墙日志看一眼进程有没有建立到外网的会话。注意只看新建会话因为有些内存马做的是短连接传输几KB就断开。3.3 日志与流量双向验证排查不能只看单方面证据。我个人的习惯是先看 SharePoint 的统一日志服务ULS和 IIS 日志把可疑时段的所有请求拉出来找那些请求体特别大或者返回特别快的记录。这里有个技巧内存马的 HTTP 响应通常很短内容可能是一串密文或是固定格式的 JSON和正常页面响应的 Content-Type、长度都有差异。流量层面要做双向验证。常规的外网访问记录可能看不出问题因为攻击者会用 HTTPS 加密流量。这时候要看连接维持时间。正常用户访问 SharePoint 页面是短连接一般是几十毫秒到几秒如果发现某个 IP 和服务器之间保持着长连接而且发送间隔很有规律比如每分钟一次心跳包那基本可以判定为控制通道了。当然在调试这个漏洞的时候我们也会用安全分析工具去模拟合法请求比对响应差异这样能够缩小异常排查范围。4. 修复与加固真正意义上的止血4.1 漏洞补丁与版本管理发现漏洞之后的第一反应当然是打补丁。微软在漏洞公告中提供了对应版本的累积更新包需要特别提醒的是SharePoint 的补丁不能随便“下一步下一步”地装。之前有同行遇到过打完补丁后自定义组件失效的情况因为 SharePoint 的补丁会重建某些数据库和配置文件。正确的做法是在测试环境完全模拟生产环境包括所有自定义字段、站点模板和事件接收器。补丁打得再快也有空窗期尤其很多企业的 SharePoint 系统是老的长期服务版本新补丁不一定直接兼容。这种情况下我们需要做一个临时的“虚拟补丁”也就是在网关或 WAF 上针对 CVE-2025-53770 的利用特征做拦截规则。虽然不能根治但可以挡住大部分自动化攻击扫描。版本管理同样重要。我们遇到过不少客户生产环境还跑着五年前的 RTM 版本从来没有更新过甚至连扩展补丁都没有。要知道 SharePoint 是面向整个组织的高价值系统如果连基本补丁策略都不做攻击面真是大到没法收敛。所以不管这次漏洞是否影响你都建议你建立一个季度更新检查机制把 SharePoint 相关的组件、依赖的 .NET Framework、系统补丁都纳入统一管理。4.2 从配置层面削减攻击面补丁之外配置加固能明显降低风险。先说权限模型CVE-2025-53770 的利用不需要管理员权限但对运行账号的依赖很大。很多企业默认让 SharePoint 应用程序池使用域账号运行这个账号通常有较高的权限。我们应该实施最小权限原则把每类应用池对应的域账号权限限制在适当的 OU 和文件系统目录中不要用同一个账号跑所有站点。然后是身份验证组件如果你没有用到自定义表单认证就把扩展认证类型关掉尤其是那些允许位置不明的 POST 请求的类型。还要限制匿名访问令牌生命周期避免攻击者在窃取到匿名令牌后可以长时间伪装合法请求。我们在复测中会发现一定比例的利用行为都是基于过度宽松的认证配置才成功的收紧这一层可以挡住一大批脚本小子。再补充一个容易忽略的点启用进程级别的托管代码签名验证。SharePoint 允许配置安全策略只加载经过签名的程序集。如果之前没有启用内存马这种动态加载就会被签名校验拦住。当然部分第三方组件可能没有签名需要在测试后加入白名单否则生产环境可能出现大面积报错。这一步操作起来有点费劲但防内存马很有效。4.3 面向内存马的应急响应流程如果确认服务器已经被注入了内存马不要急着重启进程也不要直接结束 w3wp.exe否则内存中的证据会消失。正确的应急响应流程应该是这样的第一步冷标记现场。把可疑进程的内存 dump 保存下来再把 ulS 日志、IIS 日志、系统事件日志都导出来并记录当前时间戳。不要修改任何文件属性。第二步隔离出网。在防火墙上封锁该服务器所有对外连接尤其是目标端口为高位数端口的直接出口。这样可以切断攻击者控制通道同时不会影响其他服务器。第三步分析内存 dump。用调试工具查看托管堆里的可疑对象找出动态程序集和调用栈。这个环节可以确认攻击者做了什么拿到攻击者的关键 IP 和载荷样本。第四步手工清除。根据分析结果先移除注入点在配置文件里的注册项再卸载相应模块最后清理进程内引用。注意不要漏掉其他应用池同一个漏洞可能会影响多个站点。第五步修复并恢复。打补丁、改配置、换密码确认干净后再启动服务并持续观察 72 小时看是否还有回连行为。整个流程里最容易做错的是第一步很多人一上来就杀进程导致证据全丢。我之前带队做应急时反复跟团队成员强调遇到内存马要忍住“立刻干掉”的冲动先把现场保存完整再谈清理。4.4 长期监测体系建设一次应急做完不代表就安全了。内存马之所以可怕是因为它可以在不落盘的情况下长期潜伏。所以长期监测体系一定要跟上。建议在 SharePoint 服务器上部署带有内存活动监控能力的 Agent定期采集进程加载的程序集列表、线程数量、内存区域的可执行标记。这些指标要做到分钟级采集起码也要十分钟以内太粗的粒度发现不了快速注入。日志层面ULS 的日志级别可以适当提高特别是对“请求处理管道”和“程序集加载”这两类事件。它们平时产生的数据量会比较大建议把日志收集到集中的 SIEM 平台做关联分析设定规则当某台服务器出现“特定时间窗口内动态加载超过 3 个程序集”或“一个进程的对 IP 数量暴增”时自动告警。很多企业卡在“日志有但没人看”所以告警不能只发到邮箱要联动到对应的安全运营值班群并配套一个级别评估表单。我们内部是每天把可疑事件按风险分三级红色直接电话找人橙色每半小时跟进一次黄色每天汇总。这样不至于出现日志躺在硬盘里、攻击者早就横移成功的“纸面安全”。5. 复盘与经验几个可以复用的做法写到这里我想把一些比较零散的实战经验总结一下。首先关于“金刚狼”CVE-2025-53770 这个漏洞我认为它的出现不是孤例未来会有更多针对 Office 协作类产品的内存级攻击出现。这类系统复杂度高、定制多、补丁周期长而且进程内动态代码调用是常态天然适合内存马隐藏。防守方必须转换思路别指望单靠一台 WAF 或者杀毒软件就能挡住要走到进程内去观察、去监测。其次是团队协作上的经验。我们在处理这类事件时会把开发和运维拉到一个群里因为排查内存马的时候开发能准确判断哪些模块是正常业务逻辑运维能快速定位 IIS 配置异常缺少任何一方都会拖慢响应速度。尤其是 SharePoint 这种平台业务逻辑复杂很多“可疑模块”其实是某些第三方开发的 Event Receiver如果安全团队不了解很容易误判或漏判。还有一个小技巧强烈建议你提前做一个“干净环境基线镜像”。找一台全新的 SharePoint 服务器把系统刚装好、补丁打完、业务配置完成后的进程模块列表、网络连接、ULS 日志格式都保存下来。平时做安全巡检时用这个基线去对比生产环境能省很多排查时间。我们就是靠这个基线快速发现了某台服务器上多了一个名为“Microsoft.SharePoint.UXControl”的可疑程序集——名字伪装得非常像官方组件但基线里根本没有它。内存马的“生存土壤”其实是混乱和疏忽。补丁缺失、权限过宽、监控空白这些都是我们给攻击者留下的机会。与其期待一个漏洞查杀工具一劳永逸不如从流程上慢慢磨出一套适合自己系统的防御方法论。这篇文章里的检测思路和应急流程都是我们在实际工作中反复验证过的希望能给正在做 SharePoint 安全防护的你一些启发。如果你也在排查类似问题记住两点第一别急着杀进程先固定证据第二把排查步骤记录下来因为每一次应急都是补齐防御体系的好机会。
阅读完成 · 觉得有帮助？
