好文 | C2 基础设施威胁情报对抗策略

写在前面

    “站在攻击视角看待威胁情报是十分必要的，我们需要从攻击者的角度去思考威胁情报中可能存在的不严谨的地方。”——风起

    之前跟风起师傅凑了一个跟我们关系不大的热闹，期间分析过一次云函数相关的C2攻击，他当时说结束以后要写一篇相关的文章。转发为敬，慢慢学习。（推荐PC上浏览器阅读）

目录

0x01 前言0x02 攻击者视角下的威胁情报研判思路0x03 对抗C2威胁情报的策略与实施0x04 后记

威胁情报是指在信息安全和安全防御领域，收集、分析和解释与潜在威胁相关的信息，以便预先发现并评估可能对组织资产造成损害的潜在威胁，是一种多维度、综合性的方法，其通过信息的收集、分析和研判，帮助组织了解可能对其安全构成威胁的因素。这种方法不仅仅着重于技术层面，还包括了社会、心理、政治等多个维度，以此更好地应对不断变化和复杂化的威胁环境。旨在为分析人员提供关键信息，帮助他们采取预防措施和应急响应策略，从而降低威胁应对实施的风险和影响。

前言

随着愈发严峻网络攻击对抗环境，网络威胁情报逐渐在攻击行为分析中扮演着不可或缺的角色。网络威胁情报的重要性主要在于其能够帮助组织了解自身所面临不断变化的威胁，提供数据驱动的防御策略，减少潜在的风险和损失，并为建立更强大的信息安全体系提供支持。

本文聚焦于针对C2基础设施视角下的威胁情报对抗策略，文内笔者将对于威胁情报分析过程的攻防思路展开论述。从高级攻防过程中，攻击者的视角来看威胁情报的分析思路，浅析在情报研判及狩猎过程中存在的问题。在工作过程中，笔者发现，站在攻击视角看待威胁情报是十分必要的，我们需要从攻击者的角度去思考威胁情报中可能存在的不严谨的地方。当发生攻击行为时，研判人员的分析思路是基于自己对于攻击的理解还是客观情报？相信通过本文读者将对此有所思考。由于威胁情报的对抗概念较为广义，涵盖了很多不同的细分方向，限于篇幅，本文将仅讲解C2基础设施对抗的方向。

本文仅为作者个人观点，如有不恰，请指正。

攻击者视角下的威胁情报研判思路

在看到疑似攻击行为时首先应该想一下，我们所看到的威胁情报是否完全真实？分析安全事件时，威胁情报应作为辅助判断依据，但不应该是决定性的因素。分析人员判断安全事件的第一准则即“行为”，而行为概念在网络空间测绘中也有体现，但是两者之间存在互通又具有歧义。在威胁情报流量侧狩猎的过程中，行为主要是该主体做了什么，聚焦于通信过程，而测绘中则为个体独有特征，目的为最终能够形成指纹。但是该主体所表现得特征同样可以作为威胁情报的聚焦信息之一，以此来关联其某一组织的资产设施。

行为：不同的群体，可能表现出基本的独有的特征，当我们能掌握到这个特征，那么我们就能尽可能识别出这个群体里的所有个体，而这些行为特征在网络空间测绘里表现出的是这个设备各个端口协议里的banner特征。

这里可以把行为理解为特征，而如何提取这些特征，进行更加精准的匹配无疑也成为了最重要的环节之一。

为了形成某APT组织的设施资产，我们应该提取这些设施所表现的“行为”，从而构建出能够指向性该组织资产的指纹，所以继而我们要引入一些更加“精准”、“特异”、“不可更改”的个体特征，可以决定性的指向某个人或团伙的资产范围，既要精准的区分目标资产又要具有特异性，不可以被轻易修改的特点。

这里我认为，在威胁情报针对某一组织或某特殊C2设施的资产标记时，分析人员可以通过做出相关指纹进行初步资产过滤，再进一步对关联到的资产进行验证，最终同步到威胁情报中，而威胁情报的狩猎，宁可不全，也不要出现不准确的情况，给后续面对攻击事件的分析人员造成误导。

针对恶意样本的威胁狩猎，针对样本侧进行定位，分析流量侧通信情况，同步至威胁情报端，体现在情报侧对C2进行综合研判，标注恶意行为这样的过程。而流量在这个过程中起到了至关重要的作用，在当下的攻防对抗进程中，武器化工程师对于样本的生成已经做到了很精巧的地步，各种白+黑层出不穷，所以通信行为无疑是需要更加注意的地方，用一句话来总结就是不要看它的外在，而要看做它了什么事情。

C2设施通信特征：

• 回连地址

• 通信内容

• 特殊信道

• 通信频率

• 持续时间

• .....

我觉得，通信内容的检测始终是一个难点，经过加密的通信流量，无法获知加密后的通信数据，传统明文检测使用的规则匹配、载荷还原检测等流量检测技术无法对加密会话所传递信息内容进行检测。像C3 这类利用流行应用程序的合法功能来伪装受感染端点和 C2 服务器之间通信使得威胁追踪更加困难，面市面上针对加密流量检测的产品面对高版本TLS协议基本是束手无策的。通信频率即心跳包，稍加进行心跳静默+偏移即可绕过，这也是基本操作。因此，在以后的攻击者对抗中可能会开始发现利用更隐蔽的C2信道，情报团队应加快分析端点机器数据以便快速检测整个杀伤链中的威胁。

针对自签名类样本，代码签名的指纹无疑是一个不错的思路。

我认为根据代码指纹为基础，可以针对一些自签名的证书样本做关联，之前有了解过微步的OneSec，那么有没有可能以此去关联组织中传输的恶意样本之间的关系。他这个签名的指纹，应该是以该证书签名的程序均是同一个，而攻击者通常会给程序进行白+黑签名，对应多个样本的前提是他们都是这个证书签名的。如果在终端设备上已经部署了Agent，那么将关联终端可疑程序的签名指纹对比，以云沙箱的检出情报为基础，识别相同代码签名的恶意程序，来作为一个检出依据，我认为这样的思路如果应用在组织架构的环境下应该是可行的。当然，具体可行性还是要专业人员思考，理论商所有以Agent端部署作为防护基础的设备应该都是可以借鉴的。

组织应始终关注自身风险暴露面，以情报为驱动，关注舆情（代码泄露、联系方式、数据泄露、供应链风险），可能某些数据泄露事件的后期影响会直接导致相关组织发生安全事件。随着组织业务的发展，业务云上化、移动办公需求、合作伙伴、分支机构的拓展，安全风险会逐步上升，所以需要更加关注近期发生的安全情报。站在攻击者的角度，渗透并不会从最安全的位置发起，而是观察与目标有关联的互联网资产、舆情以此作为移动至目标组织的特殊桥梁，须知木桶原则是从防御体系最薄弱的地方突破的。

总结一下，在威胁情报的狩猎过程中，未命中、发现的情报始终是最重要的，攻击已经成为事实的情况下，再进行情报狩猎分析只能在某种程度上减少组织的损失。威胁情报分析团队应加强针对正在进行攻击、已经发生攻击的事件的关注，在此基础上发掘将要发生攻击的事件，及时将攻击事件根据情报推送至处于高风险的行业，及时排查，将安全事件风险降低，做到事先预防、事后有效处置的举措。

对抗C2威胁情报的策略与实施

命令与控制服务器，也称为 C&C 或 C2，攻击者使用它来维持与目标网络内受感染系统的通信。“命令”和“控制”这两个术语经常被广泛使用，过去十年中，恶意网络攻击呈上升趋势。最具破坏性的攻击之一通常通过 DNS 执行，是通过C&C完成的，命令和控制被定义为威胁行为者用于通过网络与受感染设备进行通信的技术。

顾名思义，命令和控制服务器向受感染的系统（通常是家庭用户的连接互联网的计算机，然后形成僵尸大军，称为僵尸网络）发出命令和控制。这些通信可以像维护定时信标或“心跳”一样简单，以便运行攻击的操作员可以保留他们在目标网络中受到损害的系统的清单，或将它们用于更恶意的操作，例如远程控制或数据传输。渗漏。虽然命令和控制服务器用于控制目标组织内部的系统，但通常是受感染的主机发起从网络内部到公共 Internet 上的命令和控制服务器的通信。【Command-and-control servers: The puppet masters that govern malware】By Adam RiceJames Ringold, Westinghouse Electric Company

希望读者通过阅读本小段能够从攻击者的角度思考安全防范策略，了解新型的C2设施防护手段，本段也将从对抗威胁情报的C2基础设施的方法实施论讲解。下图为通过微步Graph生成的示意图，读者可以先阅读正文然后再看该图例，加强理解相关技术思路，以实现更好的阅读效果。

RedGuard是基于命令与控制（C2）前端流控技术的衍生工具，具有更轻量级的设计、高效的流量交互以及可靠的兼容Go编程语言开发。随着网络攻击的不断演变，红蓝团队随着演练变得越来越复杂，RedGuard旨在为红队提供更好的C2通道隐藏解决方案，为C2通道提供流量控制，阻断“恶意”分析流量，更好地完成整个攻击任务。

RedGuard是一款C2前端流量控制工具，可以躲避Blue Team、AVS、EDR、Cyberspace Search Engine的检测。

Github下载地址

https://github.com/wikiZ/RedGuard

伪造TLS证书

在部署域前置隐匿C2流量时，默认情况下加速的域名是不具备HTTPS证书信息的，这样显然是存在问题的，所以配置域名时需要注意对证书进行配置，这也是判断样本是否为域前置流量的默认依据。

相信看到这里，大家会有所疑问，配置的证书怎么获得？如果使用自己申请证书是不符合我们预期想达到的隐匿效果。这里可以使用克隆的证书进行配置，以腾讯云为例，测试中发现其不会对自定义上传的证书进行校验有效性，我们可以使用与加速域名实际站点相同的证书进行伪造。虽然伪造的证书在正常情况下替换CS的默认证书是无法通信的，但是在云服务厂商CDN全站加速和RedGuard上面部署是不会进行校验有效性并且可以正常通信C2交互流量。

以下为Github已有项目地址

https://github.com/virusdefender/copy-cert

尽管样本域前置流量侧的证书已经解决，但是站在大网测绘的角度来看，我们的C2服务器仍然暴露于外，依然可能被探测到真实C2服务器并实现关联，这时就可以通过RedGuard修改C2的前置默认证书实现隐匿。

以上即为C2服务器伪造的证书效果，可以看到在微步社区的情报中是可信且未过期的状态，而其获取数字证书的主要途径也是在云沙箱进行样本分析时进行提取并实时更新的，但是显然没有经过有效校验，状态值仅对失效时间进行验证，证书可信验证应该是只以是否能够正常通信作为判断依据。

需要注意的是，微步情报并不会对样本请求的SNI及HOST的地址进行标注证书情报，这其实也是出于防止出现误报的考量，我认为这是正确的，作为辅佐研判人员分析的重要依据，威胁情报宁可不全，也最好不要出现错误指向，对后续分析造成误判。如果说在全站加速配置证书是伪造通信流量的证书，那么配置RedGuard C2的前置响应证书就是为了针对部署于公网的真实C2服务器的行为特征进行伪造，以实现抗测绘的效果，这是十分必要的。

提取证书序列号：55e6acaed1f8a430f9a938c5，进行HEX编码得到TLS证书指纹为：26585094245224241434632730821

Search Result Amount: 2291

通过网络空间测绘发现2291个独立IP，进行验证确定均为百度所属TLS证书，如果单从通信流量来看是比较难判断是否为恶意通信的，而上面针对域前置+C2前置流量设施的TLS证书进行了伪造，成功对空间测绘与威胁情报实现了干扰，造成了错误的信息关联，使得攻击者的流量特征更加逼真，实现了伪造正常通信流量的目的。

哪怕在C2流量前置设施之前不存在隐匿转发的处理，也最好对RedGuard进行更改证书。默认状态下，任何目前在网络空间测绘里常用的通用组件指纹识别形成的指纹库就是利用了通用组件默认配置特征这个行为来进行识别的，在这些自定义过程中不同的群体又可能表现出不一样的独有特征。当然，指纹的形成需要对目标组件具有一定理解，从而提取出目标的默认特征，形成关联指纹。这里利用RG证书表现的行为特征进行网络空间测绘，关联到了大量部署在公网的RG节点。

作者能够提取出该指纹不足为奇，但是依然建议RedGuard用户修改的默认证书信息，做一个专业的Hacker:)

劫持站点响应

相信不少读者对劫持响应会比较感兴趣，大概原理为当客户端对真实的C2服务器发起请求时，由于不符合入站规则，所以C2服务器会获取指定的正常站点并返回其响应信息，所以从效果请求端来看好像是与该IP进行服务交互，但是实际是以中间C2服务器为代理服务器与正常站点进行交互，很难发现异常。而如果符合入站请求时，则会将流量请求转发至真实的C2服务监听端口进行交互，而真实监听端口已经被云防火墙过滤，仅允许本机访问，从外部是无法直接访问的。所以从外部端口开放情况来看仅开放了该HTTP/S端口，而某种意义来说这也确实为C2的上线端口。

在网络空间测绘数据中，该IP的HTTP/S开放端口响应码为200，不是302跳转，更加具有真实性。

HTTPS证书与上述伪造证书效果相同，均为真实证书的指纹。

相信不少红队在打项目的过程中，都会广泛的使用云函数/域前置一类的隐匿手段，但是在今天的攻防对抗的博弈中，上述两种隐匿手段均存在一个致命的问题，就是可以直接连通C2服务，而这些导致结果无疑就是当我们掌握到云函数地址或者域前置的交互IP/HOST即可直接访问C2监听服务并证明其为攻击设施。

由于流量可以直接到达C2，那么这里不妨思考一下，安全设备针对SNI与HOST不相符的流量是否可以进行CS扫描来识别是否为恶意流量，云函数或者沙箱环境也为同理，除去样本侧也可以多一些流量层面的分析过程。

而当进行劫持响应后，直接访问HTTP服务是可以正常网站交互的，但是Cscan是无法扫描出样本信息的，因为流量无法到达真实的C2监听器，只有当满足流量发起的特征时才可以正常C2交互，但是这就存在一个问题，C2扫描的脚本需要符合入站规则，这对蓝队分析人员的代码能力也就具有了一定考验，目前公开的扫描脚本为Nmap形式的。

这里提一点Tips，除却域前置，也可以尝试抢注一些高信誉的域名，而一些组织可能会疏漏注册某些域名，这时可以抢注然后使用隐藏WHOIS信息服务作为交互域名，可信度更高。

P.S.深信服大哥能不能回购啊，我留着没用 >_<

识别云沙箱指纹

JA3为客户端与服务器之间的加密通信提供了识别度更高的指纹，通过 TLS 指纹来识别恶意客户端和服务器之间的 TLS 协商，从而实现关联恶意客户端的效果。该指纹使用MD5加密易于在任何平台上生成，目前广泛应用于威胁情报，例如在某些沙箱的样本分析报告可以看到以此佐证不同样本之间的关联性。

如果可以掌握 C2 服务器与恶意客户端的JA3(S)，即使加密流量且不知道 C2 服务器的 IP 地址或域名，我们仍然可以通过 TLS 指纹来识别恶意客户端和服务器之间的 TLS 协商。相信看到这里大家就能想到，这也正是对付域前置、反向代理、云函数等流量转发隐匿手段的一种措施，通过沙箱执行样本识别与C2之间通信的 TLS 协商并生成JA3(S)指纹，以此应用于威胁情报从而实现辅助溯源的技术手段。

该技术在去年的时候就已经公布，在测试微步沙箱环境时发现，其请求交互的出口IP虽然数量不大，但是通过IP识别沙箱并不准确，并且这是很容易改变的特征，但是其在相同系统环境下JA3指纹是唯一的。后续得到反馈称沙箱已完成指纹随机化，但是近期通过测试发现仍没有完全实现，还是希望可以正视流量侧指纹的问题。

目前主要为以下JA3指纹：

• 55826aa9288246f7fcafab38353ba734

在云沙箱的立场上，通过监控样本与C2服务器之间流量交互生成JA3(S)指纹识别恶意客户端从而进行关联，而我们逆向思考，同样作为C2前置的流量控制设施，我们也可以进行这样的操作获取客户端请求的JA3指纹，通过对不同沙箱环境的调试获取这些JA3指纹形成指纹库从而形成基础拦截策略。

设想在分阶段木马交互的过程中，加载器会首先拉取远程地址的shellcode，那么在流量识别到请求符合JA3指纹库的云沙箱特征时，就会进行拦截后续请求。那么无法获取shellcode不能完成整个加载过程，沙箱自然不能对其完整的分析。如果环境是无阶段的木马，那么沙箱分析同样无法最终上线到C2服务器上，想必大家都有睡一觉起来C2上挂了一大堆超时已久的沙箱记录吧，当然理想状态下我们可以对不同沙箱环境进行识别，这主要也是依赖于指纹库的可靠性。

在测试的过程中，我发现在指纹库添加ZoomEye GO语言请求库的JA3指纹后监测RG请求流量情况，大部分的请求均触发了JA3指纹库特征的基础拦截，这里我猜测该测绘产品底层语言是以GO语言实现的部分扫描任务，通过一条链路，不同底层语言组成的扫描逻辑最终完成了整个扫描任务，这也就解释了部分测绘产品的扫描为什么触发了GO语言请求库的JA3指纹拦截特征。而其与云沙箱指纹的识别规则原理是相同，均利用了请求客户端环境及请求库的唯一性，区别于PC端，这些产品的请求环境基本上是不会随意更改的，这也导致了我们能够掌握到其流量侧指纹并拦截，那么是否可以思考安全设备是否可以把主动探测流量的JA3指纹作为拦截依据？当然，当业务流量较大时可能会有一定的误报，这里仅提出理论上可实施的产品需求。

P.S.读者也可以自行上传样本至沙箱中获取并验证其JA3指纹添加至指纹库，需要注意的是，如果沙箱仅更改JA3指纹不为上述指纹是没有意义的，真正需要解决的是每次沙箱动态分析时均不为同一指纹，而其变化需要满足尽可能的不重复，如果重复率较高依然会被作为指纹使用。

自定义样本指纹

这里提出一个实战场景，当攻击者希望不同监听器均对应独立样本，而在某一样本被捕获或希望其“失效”的情况下，能够指定样本流量是否允许放行到达C2，这时就可以使用自定义样本指纹。该功能基于对Malleable Profile自定义设置HTTP Header字段作为样本指纹“样本Salt值”，为相同C2监听器/Header Host提供唯一辨识。此外，结合其他相关请求字段生成的木马样本指纹，可用于检测自定义样本存活性。

根据攻击方任务要求，木马样本指纹识别功能可针对希望失效的样本进行“下线操作”，更好地规避恶意研判流量的样本通联性关联及分阶段样本PAYLOAD攻击载荷获取分析，给予攻击方更加个性化的隐匿措施。针对不同C2监听器，可以给不同的Malleable Profile配置别称、自定义相关header的字段名和值作为样本Salt值，以此作为区分不同样本之间的唯一辨识。下列代码是为了方便说明，而在实际攻防场景下我们可以给予更加贴合实际的HTTP请求包字段作为判断依据。

http-get "listen2" {
set uri "/image.gif";
    client {
        header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //用户自定义字段名及值
        metadata {
            print
        }
    }
}

HTTP流量

如图所示，我们根据上述样本Salt值及Host字段作为指纹生成依据，这里我们已知:

• Salt值：866e5289337ab033f89bc57c5274c7ca

• Host字段值：redguard.com

根据对上述值进行拼接并使用32位小写MD5哈希得到sample指纹为：

redguard.com866e5289337ab033f89bc57c5274c7ca    //拼接后待哈希字符串
d56da55231dfd8e9a4f3ad2e464f49e4                //Sample FingerPrint

目前已知上述样本指纹，现在我们在RedGuard配置文件中设置自定义的Header字段及样本指纹用于恶意流量拦截。值得注意的是，这里的Header字段及值可以自定义为更符合实际的，这里为了更好的展现效果所以Accept-Finger与长字段的Hash为例。我们可以拓展多个样本指纹，不同指纹之间FieldName和FieldFinger字段用逗号分隔，FieldName字段需要和Malleable Profile中配置的Header字段名称保持一致，这也是获取请求包所携带Salt值的重要依据。

因为RG的配置文件为热配置，所以这里我们不需要重新启停RG即可实现针对希望失效的样本进行拦截，当我们希望该样本重新生效时，只需在RG配置文件中删除相关样本指纹即可实现。

蜜罐恶意诱捕

蜜罐恶意诱捕的原理主要是依赖于RG流量导向的劫持响应or重定向功能，将研判C2设施的分析者导向蜜罐沙箱的地址，在劫持响应的状态下，RG会将不符合入站规则的请求流量导向蜜罐资产中，而碰到一些比较厉害的蜜罐（例如抓取运营商手机号那种），客户端就会依照目标站点的响应发起请求被jsonp劫持到相关信息。

试想，当分析人员对C2上线端口直接访问就会被导向至蜜罐资产，造成的结果无疑就是对分析人员造成了扰乱，而分析人员被恶意导向请求蜜罐资产，蜜罐监测端则捕获到蓝队分析人员的相关信息从而错误溯源。如果从开始分析目标就是错误的，又怎么会得到好的结果，无疑对防守队伍造成了严重的内耗。

这里给大家提供一组关联蜜罐资产的ZoomEye指纹：

(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")

而实现这一效果的方式非常简单，仅需更改RG配置文件相关键值即可。

# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action   = proxy
# URL to redirect to
Redirect      = https://market.baidu.com

P.S.相信不解释大家也知道该怎么配置:)

该方式算是一种奇淫巧计吧，更多的是体现在思路上，如果进一步利用就可以在C2前置流量控制设施部署蜜罐捕获的功能然后再进行交互流量导向，效果也就是如传统蜜罐一样能够获取客户端的浏览器缓存数据。但是个人感觉在公开版本中，应用于现阶段的攻防对抗可能意义不大，攻击者捕获得到蓝队分析人员的社交信息再进行溯源是无意义的操作。当然退一步来想，这或许会让C2样本的分析更加危险，当黑灰产的攻击者能够获取得到分析人员的虚拟身份后，如果能够做到虚实身份的转换，那么还是比较危险的。所以我认为，以后的研判分析应该更加谨慎，提高警惕意识。

后记

又到了比较轻松的阶段，这也是我写文章最喜欢的环节，已经一年没有写过文章了，也没有关注安全方向，嗯。。可能会有些不跟形势。刚刚完成了第四年的HW经历，有朋友说的一句话让我印象深刻，“感觉，HW对我们来说就是参加了一场跟我们关系不大的热闹”，哈哈哈哈，感觉十分贴切啊。回首自己的安全经历，感觉依然是学的比较杂，难道是博观而约取，厚积而薄发？给自己后期的规划可能也不会主要去做技术，实话说我一直不是一个喜欢追求技术的人，所以在我毕业之后可能会去做面向接触人和技术打交道的工作岗位，而不是专注于安全研究。我给自己的定位是一个善于理解+联想+创新的人，可能说白了就是一个善于总结创新的人吧，所以我始终喜欢接触新兴事物，因为这样总能让我有所启发，发现一些不一样的东西。2023是全新的开始，风起依然在路上。

最后，祝大家心想事成，美梦成真!

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/3022/