记一次粗浅的钓鱼样本分析过程

原创稿件征集
邮箱：edu@antvsion.com
QQ：3200599554
黑客与极客相关，互联网安全领域里的热点话题漏洞、技术相关的调查或分析，稿件通过并发布还能收获200-800元不等的稿酬。

0x00 前言

一切的一切要从（盘古开天辟地）几个月前的某大型网安活动期间说起。话说当时一位素未谋面的基友给在下发了一个疑似钓鱼的样本，说是让我试试看下能不能溯源出攻击方。于是虽然作为一名萌新，此前也从未接触过类似的工作，但想到既然是基友的请求，那也唯有欣然接受了。不过值得庆幸的是，最后虽然折腾了大半天，而且好像也没帮上什么忙，但与样本分析的初接触过程中，还是学到了不少东西的。唯独可惜的是，由于当时的自己沉迷摸鱼，没有及时把过程记录下来。如今偶然再想起，决定补写一文章——但也只能力求复刻当时的真实情况了。所以如果发现文中一些时间戳对不上的，请自动忽略，个人认为不影响文章的真实性。。。

0x01 投石问路

因为样本是基友直接发给我的，所以样本的发现过程这里按下不表，直奔主题吧。

拿到样本，一个朴实无华的 exe 可执行文件，再看这 exe 的图标更是已经烂大街的了：

于是本着没吃过猪肉也见过猪跑的道理，想起平时摸鱼时也看过不少大佬们做过的免杀和样本分析的文章，先草率地做出了一个最简单的猜想：很可能又是一个使用 rar 自解压制作的钓鱼样本。

于是就草率地先尝试使用 bandzip 打开，发现格式不对：

显然，这样草率的猜想果然是不靠谱的，遂转换思路。

于是又想到，正所谓他山之石可以攻玉，况且自己之前在这方面也几乎零基础，那不妨先扔在线的分析网站跑一波吧，就算只搞到个大概的报告也可以供参考。于是将样本拖进 VT，立等片刻后，得到结果：

只是瞧瞧这多引擎的检测结果，居然还有点小意外？！于是这个情况顿时让我对这个样本又多了几分好奇：看来有机会还是要搞清楚这个样本是怎么制作的呀。再说作为一条有理想的咸鱼，一直这样依赖工具也不是办法，有机会还是要锻炼下自己的动手能力。于是决定为基友献出自己的”第一次“，尝试手动分析下这个样本，顺便看看它这个查杀率是怎么做到的。

0x02 循序渐进

说是手动分析，但一来自己经验不足，二来身边也没有随时可抱大腿的大佬来解疑答惑，那眼前 VT 的分析结果还是要参考下的，起码起到风向标的作用。

VT 分析结果的前面几项都没有什么特别有价值的信息。直至切换到分析结果中的 BEHAVIOR 选项卡，发现样本执行过程释放和加载了一个名为python27.dll 的动态链接库文件：

看到这，作为一名常年网上冲浪、已经将喊666刻进DNA里的资深菜鸡，我的 privilege 又尽数体现了：根据经验，这大概又是一个 PyInstaller 打包的 exe文件。

于是现学现卖，从搜索引擎得知：

PyInstaller 打包的文件可以使用一个名为 pyinstxtractor.py 的脚本来进行解包反编译得到 pyc 文件
pyc 是 python 源代码执行编译后得到的文件。可使用 uncompyle6 等工具进行反编译，得到最终的 python源码
因此需准备工具有：pyinstxtractor.py）（可github获取）、uncompyle6 （可直接使用 pip install安装）

有了以上前置知识后，那么依葫芦画瓢——下载脚本并执行： python pyinstxtractor flashplayerpp_install_cn.exe：

幸运的是，过程十分顺利，在当前目录下生成了解压文件夹：

然后，根据资料，在解压目录中找到可疑的 pyc文件，名为 main：

按照剧本，这里的 main 应该就是 main.py 编译之后得到的 pyc 文件。但实际操作中，无论是使用在线反编译工具如 http://tools.bugscaner.com/decompyle/，还是本地的 uncompyle6 和 EasyPythonDecompiler，发现都无法反编译成功。尤其是 uncompyle6，执行 uncompyle6 -o main.py main.pyc 后给出了详细报错：

根据报错信息不难发现，报错与一个 magic number的概念有关。因此要想继续分析流程，就必须先解决 magic number的问题。

于是继续求助搜索引擎。得到解释如下：

magic number 是 pyc 文件结构的一部分，其位于文件开头的前 4 个字节，代表了 python 的版本信息。
出现 unknown magic number 错误，很可能是制作样本的钓鱼佬对 pyc 文件做了手脚。这种情况在 CTF 中也比较常见
在知道 python 版本的情况下，可通过补全magic number 信息来尝试修复无法还原的 pyc 文件

0x03 原来是虚晃一枪

老实说，看完上面收集回来的信息，我当时的表情就是这样的：

显然，事情到这一步已经超出了一个我这个菜鸡的预期了。

所以说，要半途而废嘛，也不是没想过。。。可气氛都渲染到这里了，不继续下去好像也不太说得过去的样子。。。

于是，本着准备手动修复 magic number 信息的想法， winhex 打开 main.pyc，却惊喜地发现：

main 文件里面的竟然是源码明文？！！

这。。这。。。这是咋回事呢？跟说好的剧本不一样啊。。这样难道不会影响打包的 exe 文件的运行的吗？难道这就是这个样本被查杀率不高的原因？

于是本着知其所以然的心态，本人又围绕这这个问题，尝试找了不少资料。但可惜水平有限，最终也是没找到相应的解释，对此还希望有知道的师傅能指教一二。。。

不过言归正传，既然拿到了 python 的源码，那一切就好办了。。

直接将 main.pyc 改名为 main.py，用 sublime 打开，得到：

简单看了下源码，发现执行的过程如下：

1、is_admin 函数先判断是否为管理员权限，如果不是，则调用 API 请求以管理员身份运行该样本
2、如果当前已经是管理员权限，则执行 NDdFrvsmTh 函数
3、NDdFrvsmTh 函数开辟两个线程，一个线程执行TFZWSTEcc函数下载真正的 flash 安装包到本地执行安装，另一个线程执行TENRWCTE 函数加载 shellcode 使主机上线
4、TFZWSTEcc 函数先从远程地址 https://www.xxx.us/xxxxxyyyyyyvszzzzz 加载 CS 的shellcode，然后几句 cPickle.loads 分别为 shellcode 的执行分配内存空间、设置执行权限、创建线程并最终执行：

（PS：可能是我愚钝，总之一番概览下来，好像除了从远程加载 shellcode 而不是硬编码到代码中去之外，也没啥特别的。。。？所以至此 VT 的这个 6/64 的查杀率似乎也成了我的一个未解之谜。。