这是[信安成长计划]的第 14 篇文章
0x00 目录
0x01 DotNet功能分析
0x02 DotNet功能执行
0x03 写在最后
在上两篇文章中,讲述了 CS 中的一种功能执行方式 RDI,这一次来分析一下另外一个非常重要的功能执行方式——DotNet
0x01 DotNet功能分析
CobaltStrike 提供了一种可以执行任意 DotNet 程序的方案,使用了名叫 invokeassembly 的 DLL,来加载和执行所传递的 DotNet 功能,提供这个方法的 Job 是 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://b4rtik.github.io/posts/execute-assembly-via-meterpreter-session/
https://github.com/b4rtik/metasploit-execute-assembly
0x03 写在最后
与 RDI 不同的是,我们并不需要在 DotNet 当中处理管道相关的内容,这些东西都由 beacon 和 invokeassembly 处理了,因为 DotNet 是由我们来传进去的,而 RDI 的功能它是不支持像 DotNet 这样直接调用的,而我们通过二开的方式来进行了使用,就需要直接按照所规定好的方式来进行处理才可以。