Advanced Windows Task Scheduler Playbook-Part.3 Lateral Movement
原创 zcgonvh 2022-09-28 06:30 北京
Advanced Windows Task Scheduler Playbook - Part.3 from RPC to lateral movement
Advanced Windows Task Scheduler Playbook - Part.3 from RPC to lateral movement
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和对抗也有了联系。
考虑到我们正在研究计划任务，那么随之思考：计划任务能否做到这一点？根据我们前两篇文章的研究结果，不难回答这一问题：
MS-TSCH
基于RPC
，无法关闭且多数情况下允许访问。2.ExecAction
提供无限制的命令执行，写入文件与注册表后，ComHandlerAction
提供无限制的代码执行。3.协议内部通过UTF-16
编码，将完整的
XML定义以原样
传输至客户端。其中Description
元素可无限制
放置任何字符串
内容。
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"));
（体会到 抽象 透明
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
将结果转换为可读的字符串，最后进行保存。XML
的/Task/RegistrationInfo/Description
元素内容设置为要执行的命令，将名称设置为TestTask
，将命令行指定为上面的PowerShell命令，运行这个计划任务，Description
将变为命令结果。
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
无关，主要目的是为了处理转义可能带来的一系列问题。根据前缀
执行不区分大小写
的匹配，所以实际上-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
这两种。SMB
协议，实现了单协议的横移与回显结合的特点，所以在相当长的时间用作内网渗透的首选。哪怕是现在，基于Impacket
或是API
的自修改版PsExec依然能起到不俗的作用。WmiExec
？因为WMI服务同样默认开启，且基本上不存在关闭的可能，通过stdregprov
依然可以达到同协议回显的目的，从而变为基于DCOM
协议横移的首选。基于RPC的taskexec
这个技术选择。是的，这仅仅是一个技术补充，而非替代品。为什么？
应用范围/环境要求
，同时必定存在各种各样的强特征
。所有声称无感的(undetectable
)绕过(bypass
)/逃逸(evasion
)方式，只是没有捕获强特征罢了强特征
意味着被检测、被追溯的可能。但没有哪家产品敢于声称100%检测某一技术与其变种
。也没有哪家产品能够做到100%无需人为
判断/处置。而且检测和追溯需要人
。更何况验证自动化的结果进行处置同样需要人
。在我们从钓鱼的
变成钓鱼佬
之前，几乎不可能见到这个场景下可以替代人工的AI大规模商用。mshta
、sct
、ComHandler
等等未选择的实现方式同样也是备选项，都是在实现基于任务计划的横向移动
这一目的的过程中可用的Gadget。甚至于将这些备选项重新组合，还能得到另外一大堆很好用的chain
对抗-内网渗透-域-RPC
这个更大的行为链条中的一个更大的gadget。0x05 总结
这是本系列第三篇，我们从应用场景入手，随后进行可行性分析，接下来根据分析的内容进行原型实验，最后结合实战经验，打磨出一个全新的横向移动工具。
精通
、掌握
的技术点都应当能够变为我们的Gadget储备
，并结合我们长期积累的经验
，在过程中动态地
创造一条合理的Chain
，最终在实战中发扬光大。实战应用应当是知识的有机组合，不存在一劳永逸绝对成功的技巧，但知识的积累与理解能让我们更加轻松。
当然，如果你就是喜欢无脑12345，那权当我什么都没说
文章中的代码可以在https://github.com/zcgonvh/TaskSchedulerMisc/找到，这次是一个没什么坑的原型，可以直接用，但最好自行修改一些特征防止撞车。
还是那句话，希望这篇文章能在技术点之外为各位带来启发。