前段时间在午休时间写了一篇聊聊武器化的文章《聊聊我眼中的“红队武器化”》，可能写的不太全面，今天我们不但从认知层面来看“武器化”，也结合一定的技术和例子，来体现“武器化”所需要做到的，技术层面，认知，知识，视角相关的东西。
PS:本文说的“武器化”限于红队攻防中终端对抗领域。
今天是因为聊我昨天发到星球内的一个资料里提到了Potato相关的东西
然后@鬼屋女鬼在内部群分享了一个插件，我去读了下这个4年前的CS插件代码，才想写一篇这样的文章。
土豆提权大家都不陌生，Potato类工具从利用流程上来看大体可以分为两个步骤，首先是“触发认证”，其次是“模拟令牌”；而触发认证从历史上看有NTLM Reflect（relay to self），relay to DCOM，relay to pipe等等方式来使机器账户强制认证到自身；接着模拟令牌即为使用机器账户的访问令牌，模拟出一个模拟令牌，用高权限的模拟令牌来创建进程，达到提权的目的，具体的技术细节非常多不是本文关注的重点。
现在有若干的Potato家族的Server to SYSTEM的EXP，大都为exe文件，因为这些利用的作者在这里提供给你关注的是展示提权技术本身的原理、代码、效果，而不会关注实际在红队攻防中如何使用。
假如要实现一个实际想用的Potato的提权插件，集成到C2，那么首先最起码要了解Potato的一个基本技术原理和运行流程等知识，这是基本，也是首要条件。
土豆提权们的共同点和流程大概都是：
OpenThreadToken -> DuplicateTokenEx ->CreateProcessWithTokenW
token -> CreateProcessWithToken / CreateProcessAsUser
最终可以抽象为：
token -> CreateProcess
土豆提权拦截点：
createprocess with high privilege token
也就是high privilege token 创建进程拦截
土豆提权Bypass：
现在用的最多的就是使用高权限token创建线程从而绕过创建进程拦截，这里也有公开资料就不过多叙述其技术细节。
代码在星球内也有存档,以及还有不同情况下，如IIS、MSSQL等情况下的操作办法，当然还有其他方式也在星球内有提及，请自行获取。
这些相关内容在知识星球内和交流群内早已经是老生常谈了，早已沉淀了不少内容（想加的直接文末扫码）。
那么，我们是如何使用的呢，后面出现了很多cs插件，里面集成了很多Potato提权技术，像这样：
这些插件都是依赖CS提供的内存执行技术，在CNA中封装为了几种函数，可供用户调用，比如execute_assembly就是bexecute_assembly：
反射DLL注入的接口就是bdllspawn：
这些接口是为了一些后利用任务做的，我们也可以在文档中查询到如何使用。
这样的方式就是利用CS的Fork&Run机制来执行这些功能模块，这个Fork&Run机制也是后面被大家所诟病的一个点，我们不谈执行的这个Potato本身的规避性，就以Fork&Run来看，默认的远程进程注入技术是十分明显容易被检测的。
当然在写本文的时候CS早已将这块的自定义HOOK也交给了大家，不得不说还是十分灵活的（以后谁在说出CS不行，做的不好，容易被杀，特征多诸如此类言论的大都统一归为2B行列。）
那么这种开发后渗透插件的方式也是在很长一段时间被大家所采用（在BOF还没有出现的时期）。
BOF这个在当前进程执行一些obj文件的技术出现后，CS相关的社区出现了比较好的BOF生态， 大家最知道的可能是一些替代命令用BOF去实现，甚至有超级多的功能实现，比如截图等等。
我们知道BOF最大的优点就是在本进程修复执行，不需要用到Fork&Run，但是我去查看了几个社区内的BOF化的Potato插件，发现其仅是把原始EXP翻译为了BOF。
这里是使用BOF去规避了Fork&Run的使用，但是还是存在上面说到的Potato的规避问题，当然这很可能并不是作者考虑的，毕竟只是一个开源的东西，但是我们实现一个武器化的Potato，一定就要考虑到，所以这个还不是很完美，需要我们自己去结合上面提到的规避方法优化。
那么今天看到的四年前的插件到底是哪里惊艳到我了呢，项目的地址是这个：https://github.com/rxwx/spoolsystem
可以发现他是有一个selfinject功能，可以实现无需创建任何新进程完成土豆提权的，在当年还没有BOF的出现，而且这是一个依赖于反射DLL注入的插件，我们看他的包含rdi代码的功能代码：
可以发现，他的反射DLL里面只做了这类pipepotato的trigger操作
没有之后的创建管道和模拟token等操作，这让我很奇怪，这是什么意思？进一步查看cna文件才发现，他在cna里面直接调用了两个beacon的任务，ID为60和61，并且还设定了管道名字。
我们进入beacon查看代码发现，60就是创建命名管道的任务，而61是将60任务中管道内获取到的高权token设置在当前线程的。
60：
61：
那么在这个CS的场景下使用土豆，就实现了一个非常非常巧妙的方式，注入自身避免了Fork&Run的同时也利用CS自带的功能直接调用，规避了土豆提权去创建进程的操作非常有意思，这也是今天为什么我觉得可以分享一下，这对于土豆的原理以及CS的理解没有到达一定程度是没办法实现的。
这样就够了吗？当然还不够，这个四年前的插件，我们从中学习到的仅是作者对于Potato提权技术与CS功能的理解，并巧妙结合的思路。
毕竟他是四年前的，目前的技术发展也出现了更多的先进技术，在RDI本身以及内存情理上我们是否要考虑？
所以还可以使他在所有的点上更完美一些，现在有了post-ex的UDRL，我们可以将他修改为前置式RDI以及一些RDI技术的规避点也可以做优化，这里就不细说了这些也都是该会的知识。
并且自注入到beacon自身会有内存的残留，所以我们是否可以研究如何清理掉残留的内存呢，这也是一个潜在的风险。如何清理呢，请期待下篇文章。
所以，我们发现做一个趋向完美的Potato的插件，要具备Potato提权技术的理解、CS运行机制执行功能的理解、RDI技术的理解等等，才能实现出来客观比较完美的，并不是现在市面上小孩过家家的所谓红队武器。
所以难的是同时要掌握这么多技术吗，这些固然重要，我觉得难的是同时具备这些技术，还要有高于常人的攻防实战经验，以及这些知识、历练、实践中磨练出的一个很高的视角看看待所做的事情，这是最重要的也是最难的，这也是本篇文章书接上篇文章所最想传递的内容。
