苍南最新发布请配合,seo查询怎么查,网站更换,做网站ps的图片威胁情报是指在信息安全和安全防御领域#xff0c;收集、分析和解释与潜在威胁相关的信息#xff0c;以便预先发现并评估可能对组织资产造成损害的潜在威胁#xff0c;是一种多维度、综合性的方法#xff0c;其通过信息的收集、分析和研判#xff0c;帮助组织了解可能对其…威胁情报是指在信息安全和安全防御领域收集、分析和解释与潜在威胁相关的信息以便预先发现并评估可能对组织资产造成损害的潜在威胁是一种多维度、综合性的方法其通过信息的收集、分析和研判帮助组织了解可能对其安全构成威胁的因素。这种方法不仅仅着重于技术层面还包括了社会、心理、政治等多个维度以此更好地应对不断变化和复杂化的威胁环境。旨在为分析人员提供关键信息帮助他们采取预防措施和应急响应策略从而降低威胁应对实施的风险和影响。
前言
随着愈发严峻网络攻击对抗环境网络威胁情报逐渐在攻击行为分析中扮演着不可或缺的角色。网络威胁情报的重要性主要在于其能够帮助组织了解自身所面临不断变化的威胁提供数据驱动的防御策略减少潜在的风险和损失并为建立更强大的信息安全体系提供支持。
本文聚焦于针对C2基础设施视角下的威胁情报对抗策略文内笔者将对于威胁情报分析过程的攻防思路展开论述。从高级攻防过程中攻击者的视角来看威胁情报的分析思路浅析在情报研判及狩猎过程中存在的问题。在工作过程中笔者发现站在攻击视角看待威胁情报是十分必要的我们需要从攻击者的角度去思考威胁情报中可能存在的不严谨的地方。当发生攻击行为时研判人员的分析思路是基于自己对于攻击的理解还是客观情报相信通过本文读者将对此有所思考。由于威胁情报的对抗概念较为广义涵盖了很多不同的细分方向限于篇幅本文将仅讲解C2基础设施对抗的方向。
本文仅为作者个人观点如有不恰请指正。
攻击者视角下的威胁情报研判思路
在看到疑似攻击行为时首先应该想一下我们所看到的威胁情报是否完全真实分析安全事件时威胁情报应作为辅助判断依据但不应该是决定性的因素。分析人员判断安全事件的第一准则即“行为”而行为概念在网络空间测绘中也有体现但是两者之间存在互通又具有歧义。在威胁情报流量侧狩猎的过程中行为主要是该主体做了什么聚焦于通信过程而测绘中则为个体独有特征目的为最终能够形成指纹。但是该主体所表现得特征同样可以作为威胁情报的聚焦信息之一以此来关联其某一组织的资产设施。
行为不同的群体可能表现出基本的独有的特征当我们能掌握到这个特征那么我们就能尽可能识别出这个群体里的所有个体而这些行为特征在网络空间测绘里表现出的是这个设备各个端口协议里的banner特征。
这里可以把行为理解为特征而如何提取这些特征进行更加精准的匹配无疑也成为了最重要的环节之一。
为了形成某APT组织的设施资产我们应该提取这些设施所表现的**“行为”从而构建出能够指向性该组织资产的指纹所以继而我们要引入一些更加“精准”、“特异”、“不可更改”**的个体特征可以决定性的指向某个人或团伙的资产范围既要精准的区分目标资产又要具有特异性不可以被轻易修改的特点。
这里我认为在威胁情报针对某一组织或某特殊C2设施的资产标记时分析人员可以通过做出相关指纹进行初步资产过滤再进一步对关联到的资产进行验证最终同步到威胁情报中而威胁情报的狩猎宁可不全也不要出现不准确的情况给后续面对攻击事件的分析人员造成误导。
针对恶意样本的威胁狩猎针对样本侧进行定位分析流量侧通信情况同步至威胁情报端体现在情报侧对C2进行综合研判标注恶意行为这样的过程。而流量在这个过程中起到了至关重要的作用在当下的攻防对抗进程中武器化工程师对于样本的生成已经做到了很精巧的地步各种白黑层出不穷所以通信行为无疑是需要更加注意的地方用一句话来总结就是不要看它的外在而要看做它了什么事情。
C2设施通信特征 回连地址 通信内容 特殊信道 通信频率 持续时间 .....
我觉得通信内容的检测始终是一个难点经过加密的通信流量无法获知加密后的通信数据传统明文检测使用的规则匹配、载荷还原检测等流量检测技术无法对加密会话所传递信息内容进行检测。像C3 这类利用流行应用程序的合法功能来伪装受感染端点和 C2 服务器之间通信使得威胁追踪更加困难面市面上针对加密流量检测的产品面对高版本TLS协议基本是束手无策的。通信频率即心跳包稍加进行心跳静默偏移即可绕过这也是基本操作。因此在以后的攻击者对抗中可能会开始发现利用更隐蔽的C2信道情报团队应加快分析端点机器数据以便快速检测整个杀伤链中的威胁。
针对自签名类样本代码签名的指纹无疑是一个不错的思路。 我认为根据代码指纹为基础可以针对一些自签名的证书样本做关联之前有了解过微步的OneSec那么有没有可能以此去关联组织中传输的恶意样本之间的关系。他这个签名的指纹应该是以该证书签名的程序均是同一个而攻击者通常会给程序进行白黑签名对应多个样本的前提是他们都是这个证书签名的。**如果在终端设备上已经部署了Agent那么将关联终端可疑程序的签名指纹对比以云沙箱的检出情报为基础识别相同代码签名的恶意程序来作为一个检出依据我认为这样的思路如果应用在组织架构的环境下应该是可行的。**当然具体可行性还是要专业人员思考理论商所有以Agent端部署作为防护基础的设备应该都是可以借鉴的。
组织应始终关注自身风险暴露面以情报为驱动关注舆情代码泄露、联系方式、数据泄露、供应链风险可能某些数据泄露事件的后期影响会直接导致相关组织发生安全事件。随着组织业务的发展业务云上化、移动办公需求、合作伙伴、分支机构的拓展安全风险会逐步上升所以需要更加关注近期发生的安全情报。 站在攻击者的角度渗透并不会从最安全的位置发起而是观察与目标有关联的互联网资产、舆情以此作为移动至目标组织的特殊桥梁须知木桶原则是从防御体系最薄弱的地方突破的。
总结一下在威胁情报的狩猎过程中未命中、发现的情报始终是最重要的攻击已经成为事实的情况下再进行情报狩猎分析只能在某种程度上减少组织的损失。威胁情报分析团队应加强针对正在进行攻击、已经发生攻击的事件的关注在此基础上发掘将要发生攻击的事件及时将攻击事件根据情报推送至处于高风险的行业及时排查将安全事件风险降低做到事先预防、事后有效处置的举措。
对抗C2威胁情报的策略与实施
命令与控制服务器也称为 CC 或 C2攻击者使用它来维持与目标网络内受感染系统的通信。“命令”和“控制”这两个术语经常被广泛使用过去十年中恶意网络攻击呈上升趋势。最具破坏性的攻击之一通常通过 DNS 执行是通过CC完成的命令和控制被定义为威胁行为者用于通过网络与受感染设备进行通信的技术。
顾名思义命令和控制服务器向受感染的系统通常是家庭用户的连接互联网的计算机然后形成僵尸大军称为僵尸网络发出命令和控制。这些通信可以像维护定时信标或“心跳”一样简单以便运行攻击的操作员可以保留他们在目标网络中受到损害的系统的清单或将它们用于更恶意的操作例如远程控制或数据传输。渗漏。虽然命令和控制服务器用于控制目标组织内部的系统但通常是受感染的主机发起从网络内部到公共 Internet 上的命令和控制服务器的通信。【Command-and-control servers: The puppet masters that govern malware】By Adam RiceJames Ringold, Westinghouse Electric Company
希望读者通过阅读本小段能够从攻击者的角度思考安全防范策略了解新型的C2设施防护手段本段也将从对抗威胁情报的C2基础设施的方法实施论讲解。下图为通过微步Graph生成的示意图读者可以先阅读正文然后再看该图例加强理解相关技术思路以实现更好的阅读效果。 [^微步情报]: 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
IPPortProtocolServiceCountryCityTitleTime103.211.xx.90443httpsApache httpdChinaSuzhou百度图片-发现多彩世界2023-08-28223.113.xx.207443httpsJSP3ChinaXuzhou403 Forbidden2023-08-28223.112.xx.48443httpsJSP3ChinaXuzhou403 Forbidden2023-08-28223.113.xx.40443httpsJSP3ChinaXuzhou403 Forbidden2023-08-28223.113.xx.31443httpsJSP3China405 Not Allowed2023-08-28223.113.xx.206443httpsJSP3ChinaXuzhou403 Forbidden2023-08-28
Search Result Amount: 2291
通过网络空间测绘发现2291个独立IP进行验证确定均为百度所属TLS证书如果单从通信流量来看是比较难判断是否为恶意通信的而上面针对域前置C2前置流量设施的TLS证书进行了伪造成功对空间测绘与威胁情报实现了干扰造成了错误的信息关联使得攻击者的流量特征更加逼真实现了伪造正常通信流量的目的。 [^RedGuard]: 使用默认证书的RG资产
哪怕在C2流量前置设施之前不存在隐匿转发的处理也最好对RedGuard进行更改证书。默认状态下任何目前在网络空间测绘里常用的通用组件指纹识别形成的指纹库就是利用了通用组件默认配置特征这个行为来进行识别的在这些自定义过程中不同的群体又可能表现出不一样的独有特征。当然指纹的形成需要对目标组件具有一定理解从而提取出目标的默认特征形成关联指纹。这里利用RG证书表现的行为特征进行网络空间测绘关联到了大量部署在公网的RG节点。
作者能够提取出该指纹不足为奇但是依然建议RedGuard用户修改的默认证书信息做一个专业的Hacker:)
劫持站点响应
相信不少读者对劫持响应会比较感兴趣大概原理为当客户端对真实的C2服务器发起请求时由于不符合入站规则所以C2服务器会获取指定的正常站点并返回其响应信息所以从效果请求端来看好像是与该IP进行服务交互但是实际是以中间C2服务器为代理服务器与正常站点进行交互很难发现异常。而如果符合入站请求时则会将流量请求转发至真实的C2服务监听端口进行交互而真实监听端口已经被云防火墙过滤仅允许本机访问从外部是无法直接访问的。所以从外部端口开放情况来看仅开放了该HTTP/S端口而某种意义来说这也确实为C2的上线端口。 [^流量示意图]: 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.comP.S.相信不解释大家也知道该怎么配置:)
该方式算是一种奇淫巧计吧更多的是体现在思路上如果进一步利用就可以在C2前置流量控制设施部署蜜罐捕获的功能然后再进行交互流量导向效果也就是如传统蜜罐一样能够获取客户端的浏览器缓存数据。但是个人感觉在公开版本中应用于现阶段的攻防对抗可能意义不大攻击者捕获得到蓝队分析人员的社交信息再进行溯源是无意义的操作。当然退一步来想这或许会让C2样本的分析更加危险当黑灰产的攻击者能够获取得到分析人员的虚拟身份后如果能够做到虚实身份的转换那么还是比较危险的。所以我认为以后的研判分析应该更加谨慎提高警惕意识。
后记
又到了比较轻松的阶段这也是我写文章最喜欢的环节已经一年没有写过文章了也没有关注安全方向嗯。。可能会有些不跟形势。刚刚完成了第四年的HW经历有朋友说的一句话让我印象深刻“感觉HW对我们来说就是参加了一场跟我们关系不大的热闹”哈哈哈哈感觉十分贴切啊。回首自己的安全经历感觉依然是学的比较杂难道是博观而约取厚积而薄发给自己后期的规划可能也不会主要去做技术实话说我一直不是一个喜欢追求技术的人所以在我毕业之后可能会去做面向接触人和技术打交道的工作岗位而不是专注于安全研究。我给自己的定位是一个善于理解联想创新的人可能说白了就是一个善于总结创新的人吧所以我始终喜欢接触新兴事物因为这样总能让我有所启发发现一些不一样的东西。2023是全新的开始风起依然在路上。
最后祝大家心想事成美梦成真!
