前言

免杀几乎讲的差不多了，今天讲个CS的二次开发。我们原生态的CS特征肯定都是被提取完的了，包括它的流量特征，而我们要做的就是把它的流量特征给打乱，还可以修改生成的后门，使其生成即免杀。

实验环境

CS4.4，JDK11

端口修改

这个简单，CS默认连接端口50050，我们修改一下配置文件，随便改个端口，不至于让别人一眼看出来是CS。编译teamserver文件，可以看到我们默认端口为50050，改个其它端口。

vim teamserver

保存上线，可以看到连接端口改为12345了。

环境部署

这里反编译的话我们用idea自带的工具，如果你用jdgui来进行反编译的话那么会卡住，因为这个CS的jar包还是挺大的，idea如何破解安装我就不讲了网上都有。

我们在idea的这个目录下D:\idea\IntelliJ IDEA 2024.2.4\plugins\java-decompiler\lib，找到java-decompiler.jar这个工具。

为了方便一点，直接把这个工具复制到cobaltstrike.jar同一目录下。

接着执行命令对我们的cobaltstrike.jar进行反编译，并且保存在cs_src目录下面。

java -cp java-decompiler.jar org.jetbrains.java.decompiler.main.decompiler.ConsoleDecompiler -dsg=true cobaltstrike.jar cs_src

运行完之后会在cs_src目录下面生成cobaltstrike.jar，此时我们对这个jar包进行解压的话生成的是.java文件。如果你没有进行反编译就把cobaltstrike.jar解压，那么生成的是.class文件，.class文件是加密过的啥也看不到。

把这个cobaltstrike.jar解压出来，可以看到很多文件，如果其它版本的CS4.8的话编译出来还有个cobaltstrike-client.jar，感觉搞得有点乱，所以这里用4.4老版本。

打开idea，创建一个名为CS的项目。

创建后在项目下新建立两个文件夹decompiled_src 和lib。

就将上面反编译出来的cobaltstrike.jar解压到decompiled_src，将cobaltstrike.jar 拷贝到lib。

然后点击文件—>项目结构—>模块—>依赖——>点击加号——>选择库——>选择Java。

选择我们刚刚复制到lib的cobaltstrike.jar。

记得勾选上。

再然后文件——>项目结构——>工件——>点击+——>JAR——>选择来自具有依赖项的模块。

这个主类可以在我们解压的cobaltstrike.jar—>META-INF—>MENIFEST.MF中找到，把名字复制上去就行。

我们在decompiled.src中找到Aggressor这个文件，然后右键选择重构——>复制类。

目标软件包我们填F:\CS\src\aggressor，要和原本的一致才行。

此时我们到src目录下面去看，发现Aggressor文件已经被复制过来了，然后这里记得把cobaltstrike.jar->META-INF->MENIFEST.MF的内容全部拷贝覆盖src->META-INF->MENIFEST.MF不然编译完成后运行会报错。

OK现在我们的环境部署已经差不多了，直接在src目录下的Aggressor.java中添加一句弹窗代码，如果报错就点击提示的导入类即可。

JOptionPane.showMessageDialog(null, "wlw");

接着我们点击构建——>构建工件——>构建。

然后就会生成一个out目录，我们编译成的jar包就在这里。

我们运行一下这个jar包，看看有没有弹窗，可以看到是有弹窗的。

java -jar CS.jar

流量特征消除

我们先生成一个上线的exe后门，然后运行上线，可以在这个web日志看到访问了os5E这个地址。

你去访问这个地址的话就会下载一个东西。

地址：8.149.xxx.xxx/os5E

我们重新生成一个exe看看这个地址是固定的还是随机的，可以看到现在访问的是JXDw，说明这是随机的。

我们用checksum8对这个四位字符进行解密。

public class EchoTest {public static long checksum8(String text) {if (text.length() < 4) {return 0L;}text = text.replace("/", "");long sum = 0L;for (int x = 0; x < text.length(); x++) {sum += text.charAt(x);}return sum % 256L;}public static void main(String[] args) throws Exception {System.out.println(checksum8("flJA"));}}

可以看到对JXDw的解密结果是93。

对os5E进行解密的结果为92。

CS中64位的后门上线之后，访问的地址也就是那四位字符解密为93，而32位解密结果为92，这就是CS的一个流量特征。那我们现在要做的就是把这个流量特征给去除掉，直接在源码里面搜一下92L，看看是那一部分的代码进行解密的。

在WebServer.java可以看到这里 isStagerX64返回了93， isStager则返回了92。

往上划一下还可以看到这个checksum8解密算法，我说白了其实就是一个换算。

那么我们现在对这个Webserver.java进行修改，上面说过如果要修改的话，必须要先把代码复制到F:\CS\src\这个目录里面，记得要在src目录下新建一个cloudstrike文件夹，要和原本的保持一致。

首先我们修改这个解密值，也就是说那四个字符解密之后不再是92或者93，而是其它的值。我这里是干脆把它写死，wlww的算法解密值为209，那么209就替换32位的值92，wlwwnb算法解密值为161，那么161就替换64位的值93，既然写死我们就顺便把它后面的替换字符给去掉。

光改这里还不行，我们还要去改那个调用checksum8的地方，直接搜checksum8好吧。在common目录下面的CommonUtils.java文件可以看两个方法，额，在java中函数叫做方法，妈的就它搞特殊。一个是返回92的函数，一个是返回93的函数。

现在我们把CommonUtils.java复制到src目录下，然后再对它进行修改。我们看一下代码逻辑，如果var2.toString()等于92就返回var2.toString()字符串，我们直接把它写死，就是当var2.toString()等于92就返回wlww，然后Webserver.java调用ckecksum8对wlww解密。

修改如下。

同理64位的修改如下。

我们对CommonUtils.java进行构建，发现会报错，我们直接把报错的代码给删除掉就行了。

重新重构即可，在out目录下面可以看到重构的CS.jar。

接着我们点击构建——>重新编译，分别对CommonUtils.java和Webserver.java重新编译一下子，来到out目录下面可以看到重新编译出来的文件。

我们把重新编译好的CommonUtils.java和Webserver.java文件，复制到CobaltStrike.jar里面，直接覆盖掉原有文件即可。重新编译会生成两个文件，记得都要替换。

覆盖完之后我们可以用jd-gui来看一下是否覆盖成功。

生成一个32位的后面，直接运行上线可以看到我们访问的地址是wlww，对应上我们修改的了，不再是随机生成的四位字符。

64位同样也是访问我们上面修改的地址，成功达到一个流量特征消除。

模板修改

写死

我们先生成一个power shell的payload，大家有没有想过为什么每次生成的payload都是差不多的呢。

然后我们发现有个名为resources的文件夹，如果熟悉java开发的都知道这个文件夹是用来存放一些资源啊或者模板啥的，需要的时候就去调用它。来到resources目录下，查看一个名为template.hint.x86.ps1的模板，此时你会发现和生成的powershell payload几乎一模一样。

唯一不同的就是这个DATA参数，每次生成都会传个新的参数过来base64解密，其余的都一样。

我们直接搜一下%%DATA%%这个参数，在ResourceUtils.java文件中可以看到如下函数，不难看出这里调用了template.hint这个模板，var2就是位数。接着通过CommonUtils.strrep把base64编码的var1替换给%%DATA%%，最后再return CommonUtils.toBytes(var5)生成一个power shell的payload。

OK，现在我们大概了解了它payload的生成，前期我们见过powershell的免杀，那我们是不是可以把这个生成模板换成我们做了免杀的powershell，让它生成即免杀。

直接把我们修改好的32位的powershell脚本替换掉原来的模板，可能你会考虑到DATA参数咋办，这里我是干脆把模板写死了，什么意思呢，就是我无论生成多少次32位的都是完全一样的。我这里只替换了32位的，因为64位的我还没进行处理，当然你也可以统统换成32位的，因为实战中位数的影响不是很大。

我们重新生成一个32位的powershell payload看看，可以看到是我们做了免杀之后的paylaod。我的建议是不懂java开发的话，直接把它写死即可。

不写死

把模板直接写死虽然方便，但是有个鸡肋的地方是就你换个监听器或者连接IP端口来生成就上线不了了，前面我们说过%%DATA%%参数会根据你的监听器或者IP啥的来生成，但是我们写死的话就没有%%DATA%%这个参数了，此时你换个TCP监听器来生成，但是生成的依旧是HTTPS监听器的payload，所以就上不了线。

现在我们要保留%%DATA%%这个参数，使我们无论怎么改生成的payload都可以上线。我们修改template.x86.ps1这个模板文件，但不对%%DATA%%进行修改，让$xx2变量去接受上线的%%DATA%%，对其他的代码进行编码。

由于我们还要对$xx2进行一次base64解码，那我们直接到生成%%DATA%%的文件，对%%DATA%%进行一次base64编码，在common目录下的ResourceUtils.java修改，修改完记得重新编译一下。

把修改好的文件覆盖掉cobaltstrike.jar原有的文件，同时跟新一下服务端。可以看到我们生成出来的payload是和我们设置的模板一样的，而且变量$xx2每次都是不一样的%%DATA%%参数，这样子我们无论怎么换监听器或者IP都可以滴。

shellcode生成修改

我们可以替换一下shellcode生成的模板，也就是让它生成就已经进行base64编码或者其他加密啥，如果你想想加上加载器让它一生成就免杀且可以直接用，也是可以的，但是需要java开发的知识，反正我不会。可以看到无论我们怎么生成都会有unsigned char buf[]这个玩意，我们直接搜它。

可以在encoders目录下的Transforms.java文件找到shellcode的生成代码。

我们直接对var0进行base64编码。

重新编译替换掉原来的文件，可以看到我们重新生成的shellcode是经过base64加密的。

exe生成修改

我们试想一下能不能让exe生成即免杀呢，答案是肯定的，因为在CS中exe的生成也是有模板滴。在resources目录下可以找打模板，这也是为啥生成的exe默认名字是artifact32。

我们用C32asm打开artifact32.exe可以看到有很多A字符，这其实就相当于空白区域，等我们生成的时候就加入监听器、端口、IP这些信息。

OK，要想exe实现生成即免杀，对简单的方法就是修改模板。记得我们前面说过的特征码修改吗，我们只需把模板exe的特征码打乱即可，这样就实现了生成即免杀，至于如何修改我就不演示了，有点麻烦说实话。

总结

要想深度地对CS进行二次开发的话，首先你要了解CS的代码流程，以及对java开发有基础才行。网上的文章也挺多的，不过要么只是浅浅地讲一下，要么就是我看不懂。

最后，以上仅为个人的拙见，如何有不对的地方，欢迎各位师傅指正与补充，有兴趣的师傅可以一起交流学习。