这是[信安成长计划]的第 14 篇文章
0x00 目录
0x01 DotNet功能分析
0x02 DotNet功能执行
0x03 写在最后
在前两篇文章中，已经探讨了 CS 中的一种功能执行方式 RDI，本文将深入分析另一种非常重要的功能执行方式——DotNet。
0x01 DotNet功能分析
CobaltStrike 提供了执行任意 DotNet 程序的方案，利用了名为 invokeassembly 的 DLL 来加载和执行传递的 DotNet 功能。这种方法由 ExecuteAssemblyJob 提供支持，与 RDI 不同的是，它继承自 JobSimple 类。
与 RDI 类似，它也需要处理一些必要的方法。
在实际执行时，它会直接运行 ExecuteAssemblyJob 的 spawn 方法。
首先获取 invokeassembly.dll，并找到它的 ReflectiveLoader 函数，随后开始构建任务。
接着会进行一些设置操作。
在 fix 中，会处理一些 amsi 相关的内容。
接下来是一个重要的步骤，获取参数。
在这里会将 this.file 和 this.args 组合在一起。
这两个元素正是我们要执行的 DotNet 程序和参数，因此 CS 将我们要执行的内容作为参数进行传输，最后交给 invokeassembly 来执行。
之后就是任务的构建和发送。
0x02 DotNet功能执行
在执行 DotNet 功能时，忽略前面的处理操作，直接关注执行部分。
根据之前对 RDI 的分析，很容易就能区分出进程创建的位置，其中的操作基本一致。
直接进入函数执行，这里包含了各种执行方式和加载运行。
之后，执行权限就移交给了 invokeassembly。
继续追踪下去的意义不大，主要是调用接口来加载 DotNet 程序集，其中使用的技术是已经开源的 Hosting CLR，可以参考以下文章进行阅读：
https://www.php.cn/link/133232fc800034e36792956ebea38deb
https://www.php.cn/link/418bf1ce1437adeeb5d0352fcd92b1d2
0x03 写在最后
与 RDI 不同的是，我们不需要在 DotNet 中处理管道相关的内容，这些由 beacon 和 invokeassembly 处理。因为 DotNet 是由我们传进去的，而 RDI 的功能不支持像 DotNet 这样直接调用。我们通过二次开发的方式使用，就需要按照规定好的方式进行处理才行。
