DDos样本C2抽取及跟踪的相关问题分析报告（草稿，欢迎指正）

背景

分析报告整理了在日常处理DDos样本中出现的问题，以及相应的检测方法、解决方案和工作量。为了简化分析过程，报告只分析bld，mirai两个家族。但是报告中的问题和方法对其它家族也适用。报告列出的问题是目前看到的常规情况，一些少数特例需要特别处理。


DDos样本的处理流程分为如下四大大环节：


捕获（蜜罐，爬取，VT，etc) -> 预处理（脱壳，yara扫描，样本分析）-> 抽取样本C2（分析员各自的系统）-> 跟踪DDos指令 (Btmon, Beast, etc)


这四个环节有逻辑上的先后顺序，每一环都是下一环的基石。但是每一环的输出又都是有独立价值的，都可以独立评价并利用，所以当前环节的输出暂时不能严格服务于下一环节时（在不影响下一环节产出的情况下），仅满足当前环节的评价标准也是有

意义的。


例如：

1. C2抽取环节，如果暂时不能抽取跟踪环节需要的完整参数而放处理样本非常可惜。只要保证IOC的准确性，仅抽取C2也是有意义的，前提是不影响跟踪程序。

2. 预处理阶段，针对暂时不能脱壳的样本写Yara规则，这对样本打标签也是有意义的。但是要在统计C2抽取环节数据时把这部分数据剔除，这会导致错误评估抽取环节的性能。


本报告先尝试总结 预处理，C2抽取和C2跟踪三个环节常见的问题、原因、检测、解决方法，然后使用上述操作流程对24小时内的生产数据做定量分析和处理，最后根据评测结果评价当前的处理流程的有效性。本报中提出的问题暂时没有给出统一的解决方案，其中有些问题的解决方法是显而易见的，无法解决的问题会给出特别说明。



问题整理


预处理

有问题：
    １．漏报            
        原因：
            １．私有壳，脱壳失败。 
            	现有解决方案：找ZhaTu更新脱壳器
            	永久解决方案：把ZhaTu集成到系统里
            ２．新变种，Yara规则未命中
            	解决方案：分析员写规则
        检测：
            １．mat统计，分析员通过处理未知样本可发现
    
    ２．误报：
        原因：
            １．Yara规则太粗。
        解决方案：找对应分析员修正规则，回扫样本修改tag。
        检测：
            １．mat统计，分析员通过分析C2抽取失败的样本可发现

无问题：正确命中



抽取C2

有问题：
    １．抽取失败
        原因：
            １．抽取系统Bug
            ２．新变种
        解析方案：分析员修改抽取系统的代码，解Bug
        检测：
            １．mat统计

    2．抽取错误
        原因：
            １．抽取系统Bug
            ２．新变种
        解析方案：分析员修改抽取系统的代码，解Bug
        检测：
            １．mat统计，多系统交叉验证法

无问题：正确抽取

现有的抽取系统从技术手段上分为两大类：针对样本的代码规则类系统（LY,LY），针对流量的流量规则类系统（sandbox，zelos）。



指令跟踪

有问题：
    １．端口未打开（连不上）
        原因：
            １．抽取错误，相关分析在抽取环节。（这个问题是抽取阶段产生，一般通过交叉验证可以发现，在所有系统都错误时只有跟踪阶段才能发现）
            ２．Ｃ２过期
            解决方案：无
            ３．Ｃ２不定时上线
            解决方案：持续跟踪
        检测：
            １．mat统计 

    ２．端口开放无指令
        原因：
            １．协议格式不对
            解决方案：分析员分析相关样本升级跟踪程序
            ２．上线协议中Bot相关信息不对
            解决方案：根据攻击阶段的目标设备伪造相应的设备信息
            ３．tracker　IP地址被限制
            解决方案：多布点？
            ４．tracker不在攻击分组之列（？？？地域，设备型号，随机）
            解决方案：无
        检测：mat统计，多系统交叉验证法可部分检测。

    ３．指令不全
        原因：
            １．协议解析出错
            解决方案：分析员分析相关样本升级跟踪程序
            ２．tracker不在攻击分组之列（？？？地域，设备型号，随机）
            解决方案：无
        检测：mat统计，多系统交叉验证法,暂无

无问题：正确跟踪



小结：

可以看到不管问题是什么，解决方法无外乎分析员处理未知样本，抽不出来的样本，跟不到C2指令的样本。但是分析员在处理上述相关样本时没有操作规范，处理过程和问题分类没有记录，所以全部处理完时依然不能有效的反应系统做了哪些改动，哪些问题是最多的。


有些问题的检测需要多系统交叉验证，在相同环节引入不同技术原理的系统是有必要的。



定量案例分析

通过记录２４小时内的样本并手工处理，统计出上述各个问题对应的指标，测量系统现阶段能力。


New samples with no C2 extracted:
elfmips64:                                                  24
unknow:                                                     18
mozi_v2:                                                    7
kkbot:                                                      4
elf_android_native:                                         4
tinydl:                                                     3
bld:                                                        3
bld;elfmips64:                                              2
mirai_packed:                                               1
elf_py:                                                     1
mirai:                                                      1
mirai;upxed_mozi:                                           1
upxed_mozi:                                                 1
elknot_bd:                                                  1


mat统计显示

unknown样本共18个，
bld:3个，mirai:1个 抽取失败
79e64abd5eed18b57f492c97f73a3990    bld ARM
e285a727997b215680b54f325fcfeb6f    bld ARM
e9ba8b4ac7a2278c8f3c017ea7c6bbd9    bld ARM
2df780f9ad2c2ee51d5a59ac099ebcd1    mirai x86-64


从实际数据出发，对应上面整理的问题，对样本做定量分析。


预处理

漏报：
    检测：
    需分析18个unknown
    处理：
    工作量太大，暂不处理（随机分了？）

误报：
    检测： 
    通过分析抽取失败样本发现 2df780f9ad2c2ee51d5a59ac099ebcd1不是mirai，

    处理：
    需要按未知样本处理流程分析。
    mirai yara 规则去误报，回扫样本。



抽取C2

抽取失败：
    检测：
    通过分析抽取失败样本发现下面三个样本确为bld，因抽取系统bug抽取失败。
    79e64abd5eed18b57f492c97f73a3990，
    e285a727997b215680b54f325fcfeb6f，
    e9ba8b4ac7a2278c8f3c017ea7c6bbd9

    处理：
    分析员修改代码，重新处理样本抽c2。

抽取错误:
    检测：
    mat统计没有结果冲突的c2
    处理：
    无



指令跟踪

端口未打开：
    检测：
    mat显示有18个c2未打开

    处理：
    分析相关的样本（x86）发现没有抽错的情况。
    所以可能是C2过期或者C2不定时、延时上线，trcker会持续监测，分析员无需进一步处理。

端口开放无指令：
    检测：
    mat显示有8个

    处理：
    对照之前的问题分析，分析员需要逐个分析是不是跟踪器通信协议有问题。工作量大，暂不处理。
    而bot信息不对、tracker IP受限、不在攻击分组之列的问题更是无完美解决方案。

指令不全：
    检测：
    mat，交叉验证

    处理：
    分析员需要逐个分析是不是跟踪器通信协议有问题。但不能覆盖全部情况（同上）。



小结

通过具体案例可以看到分摊任务后，各个阶段的工作量并不是很大，现有的分析力量是可以覆盖的。


但是有一些问题现有的技术手段不能很好的检测验证，这一块是大家发挥相像力的地方，可以做的更精细。


例如，我尝试用Docker来检测跟踪器的协议是否有问题。



使用Docker验证跟踪协议

过滤mat对c2状态的统计结果，端口开放但无指令"ok0 A1 C1"和 端口未开放"ok0 A0 C0"的c2。这两种c2可能包含协议不正确的情况。


2020-11-25T14:02:06 ok0 A1 C1   bld_185.239.242.8_23                                jinye@360.cn
2020-11-25T13:36:45 ok0 A0 C0   bld_192.3.163.44_666                                jinye@360.cn


尝试使用Docker来捕捉流量并解析出指令，最后和mat结论对照发现协议不正确的情况。



方案

环境：
    奇云CentOS, tcpdump, iptable, Docker

方法：
    用mat定时查过去1小时的ok0的x86样本。
    cc加入iptable白名单和tcpdump过滤器。
    每隔10分钟测试cc的端口开放情况，如果开放就把样本投入Docker中运行，用tcupdump捕捉流量。
    解析流量提取cc指令。
    超过一小时无cc指令的退出Docker跟踪阶段，退回端口测试阶段。


统计结果：
    系统持续运行24小时，共有31个ok0 c2，其中10个检测到端口开放，2个检测到攻击指令。和mat对照结果完全一致。



小结

bld，mirai两个家族的跟踪器已经非常完善，因协议错误导致跟踪失败的情况暂时未发现。



其它用法：

也可用来跟踪协议和交互复杂的样本，只做协议解析，不用构造完整的交互协议。



结论

现在的各个系统在多次优化之后综合覆盖绝大部分样本，失败的情况比较少。



目标

可量化 - 计算关键指标，mat已经做了。

可追踪 - 所有样本状态明确，在什么阶段，还有什么流程要走。

可解释 - 指标异常的时候能反应出是什么阶段的什么系统有问题。（是谁的锅？）。

可解决 - 以阶段内的问题为任务，有标准的操作方法，分配到个人。

无错 - 通过所有的检测流程。