kenshinx/netlab-blogs huggingface dataset:
MsraMiner 被曝光后72小时内的更新

3月16日，我们文章 中，提到了 MsraMiner，一个潜伏已久的挖矿僵尸网络。

DNSMon 在过去的72小时内，提示我们该僵尸网络有更新，如下：

 * 样本压缩包文件改名为 ProximityUntilCache32.tlb ，原来叫 MsraReportDataCache32.tlb
 * 矿机程序被重命名为 WUDHostServices.exe ，原来是 TrustedHostServices.exe
 * 样本里的 C2 Domain 被替换为 tsk.tknuv.com / err.tknuv.com / slo.tknuv.com ，原来是 ccc.njaavfxcgk3.club / rer.njaavfxcgk3.club / acs.njaavfxcgk3.club

新的矿池域名和挖矿账号如下，其中，jiovt.com 和 etionz.com 这两个域名都是 2018-03-16 才注册的。

A:\ -o sim.jiovt.com:45560 -u letiot@protonmail.com  
A:\ -o lol.jiovt.com:45560 -u letiot@protonmail.com  
A:\ -o tzt.jiovt.com:45560 -u letiot@protonmail.com  
A:\ -o tot.jiovt.com:45560 -u letiot@protonmail.com  
A:\ -o ziz.jiovt.com:45560 -u letiot@protonmail.com  
A:\ -o mue.jiovt.com:45560 -u letiot@protonmail.com  
A:\ -o okt.jiovt.com:45560 -u letiot@protonmail.com  
A:\ -o pqi.jiovt.com:45560 -u letiot@protonmail.com  
A:\ -o kji.jiovt.com:45560 -u letiot@protonmail.com

swx.jiovt.com  
ff.etionz.com  
mm.etionz.com  
dddddd.etionz.com  
cccccc.etionz.com  
rat.etionz.com  
err.etionz.com  
nnn.etionz.com  


这些挖矿账号和备用的 C2 域名，是通过对内存数据解密得到的：

新的样本 md5 (VT first-seen: 2018-03-17)：

a4992890d226f25f1057d71e475a83d8 *ProximityUntilCache32_tlb.zip  
d4ee3ccb9fd8d1a7fd90d2d9d6500300 *ProximityUntilCache32_tlb/crypt  
011d6ce51b7806dca26c300e8d26f9bb *ProximityUntilCache32_tlb/hash  
1e0022c02030f2b4353b583beffbade9 *ProximityUntilCache32_tlb/hash64  
1afb7154e1a57adc72e87e0948573bd0 *ProximityUntilCache32_tlb/spoolsv  
baa824c84e4385056f777759ef37092c *ProximityUntilCache32_tlb/spoolsv64  
3ab6ddea6ebd2404250f5255ff7e23b1 *ProximityUntilCache32_tlb/srv  
c70673f416e3c3ee0b194ff0966e0a86 *ProximityUntilCache32_tlb/srv64  
5b8fe3875e5523bfa356503b5e81ff25 *ProximityUntilCache32_tlb/x64.dll  
8fd6f89f9ec5f303c17243e9bdd2970a *ProximityUntilCache32_tlb/x86.dll```
the hidden IoT Multi-hop Proxy Attack

背景介绍


2021年7月29号，360网络安全研究院Anglerfish蜜罐系统监测到一个攻击者使用QNAP Systems, Inc.公司的网络存储设备的6个远程命令执行漏洞, 组建多跳代理（Multi-hop Proxy）网络[1] [2] 。


我们发现部分漏洞仍存在QNAP QVR系列最新固件程序中，并向QNAP厂商报告了其中4个。


2021年9月27号，QNAP Systems, Inc.公司发布安全公告 QSA-21-35 [3] 和 QSA-21-38 [4] ，并指出已在QVR 5.1.5 build 20210902和更高版本中解决了这些问题。


经过深入的分析，我们发现这个攻击者并不简单。攻击者从2018年开始至今，持续通过隐秘、复杂的漏洞攻击手法，攻击了D-Link、Huawei、Zyxel、QNAP、SAMSUNG、ASUS、Tenda、TP-LINK等厂商的大量IoT设备（路由器、摄像头和NAS），植入Dropbear程序组建SSH多跳代理网络，并用于隐秘的网络攻击行动。



多跳代理攻击概述


多跳代理（Multi-hop Proxy）技术被广泛应用于Tor、VPN、APT攻击等场景，一般认为多跳代理流量是很难溯源的，正如Tor网络。
(Untitled)

IoC


后门帐户：


wasthere



Webshell:


http://{target}/photo/Samples/rS82*********.php
http://{target}/cgi-bin/sysdebug***.cgi



Multi-hop Proxy Attacker IP:


84.110.216.242      	Israel              	ASN8551             	Bezeq International



URL:


http://188.161.164.161:19527/dropbearmulti_latest_arm
http://185.19.221.236:10517/dropbearmulti_latest_arm_modified
http://197.246.50.79:14601/dropbearmulti_mips
http://188.227.234.203:12845/dropbearmulti_mips
http://188.161.221.203:14769/dropbearmulti_mips
http://41.205.113.221:19243/dropbearmulti_latest_arm
https://pastebin.com/raw/Hie2NLXP



MD5:


26deb391fb065fbd12a40ba8e3d2fcae
aa70287907cde0b4eb6e8834cb5a6651
02bd87e6f4a48e97b061641270f60ab1
7cffd02594bef2f491fcd29fa6d00e24
快讯：利用namesilo Parking和Google的自定义页面来传播恶意软件

摘要


近期，我们发现一个GoELF可疑样本，分析得知是一个downloder，主要传播挖矿。有意思的地方在于传播方式，利用了namesilo的Parking页面，以及Google的用户自定义页面来传播样本及配置，从而可以躲避跟踪。


该样本最开始被友商腾讯安全团队捕获，不过传播链条分析中，对namesilo parking域名的分析不太准确。往往大家以为，域名停靠期间(Domain Parking），页面显示内容是被域名停靠供应商强制限定的，域名实际拥有者并不能修改其页面内容。但在这个案例中，域名停靠供应商允许域名拥有者自定义停靠页面。攻击者利用了这一点，再加上Google提供的自定义页面来传播自己的木马。


这样做有两个显而易见的好处：一方面攻击者几乎不需要为恶意代码的传播付出任何带宽和服务器的费用；另一方面攻击者将自己的恶意行为隐藏在大型互联网基础服务供应商的巨大流量中，所谓大隐于市，以此隐藏自己的行踪使得更难被检测和追踪。


在我们的DNSMon/DTA监测数据中显示，这种趋势在最近几月有上升迹象，值得安全社区注意。



缘起


在10.13号，我们的BotnetMon根据样本网络流量，发现一个可疑的GoELF样本，会请求一个已知的可疑域名www[.]hellomeyou.cyou，这个域名在之前腾讯安全团队的一篇挖矿木马报告中被披露过。


该样本是一个Miner/Downloader，业界公开的沙箱、引擎或报告已有具体分析，我们不再赘述。但是我们注意到，www.hellomeyou.cyou 历史上的DNS解析一直是 CNAME 到一个parking域名 parking.namesilo.com


2020-11-09 2021-11-07 19904   www.hellomeyou.cyou CNAME   parking.namesilo.com



parking的域名一般都是注册但未启用，为何能成为恶意样本传播的一环，这让我们非常好奇。


登陆namesilo的用户服务界面得知，其ParkingPage 是用户可以自己定义内容的，进而给了黑客团伙的利用机会。




我们DNSMon系统中对该网站的多次历史快照显示，页面的title是一个恶意样本链接，页面的description是xmrig配置。





同时，description中还有对 github 和 google 的链接的利用，进一步分析可知，都是恶意软件传播中的一环。其中，google的自定义页面中包含了一个base64编码的xmrig挖矿软件。


很多文章都曾提到过parking和黑产的关系，但大都是指的一个普遍现象：一个域名被注册后，在没有修改DNS记录将其映射到自己的IP之前，基本都是parking状态，可能会被做一段时间的广告推广，可能会用来做引流，可能会涉及二次买卖，之后DNS记录变化，域名被映射到黑客自己控制的IP上，非parking状态，进而被黑产使用。


当前案例，是利用了“用户可控“的parking页面，在保持parking状态的时候，用于恶意软件推广。黑客不需要有自己的机器和IP，就只用域名注册商提供的parking的页面，以及google的自定义页面，来传播自己的木马。黑客团伙利用这些“公共设施”来组织自己的恶意软件传播链条，以部分的逃避跟踪和拦截。


最开始腾讯文中的分析，猜测“hellomeyou这个网站被攻击后，在网站中嵌入了这些内容。”，应该是不准确的，这是黑客团伙刻意的利用。



拓展


通过页面相似性关联分析，我们在历史数据中一共获取了8条类似配置的web记录：





对应捕获到2个样本





我们回溯了360Netlab BotnetMon 中，涉及到 parking.namesilo.com 的恶意样本的历史情况，可以看到从6月份开始有了一个明显的突增。这个突增可能意味着该种利用方式、或者parking域名其他的利用方式，被黑客组织用的越来越多。






总结


IOC：


485baeb56cde578cdfe8f88a04e29212
96dc8dcd5bf8f6e62c3ce5219e556ba3
f06d38aa4f472a7e557069cc681d997c
f24dc9c47d3698d94d60a08258bd2337
f6321c2f3bc22085e39d9f54e2275ece

hideme.cyou
hellomeyou.cyou
gannimachoubi.cyou
hvtde6ew5.top

https://sites.google.com/view/dogtoken/Home
https://sites.google.com/view/tabjoy/







上述的分析过程，融合了PDNS、Web数据、样本以及沙箱等多维度的数据。我们近期推出了DTA产品，从DNS流量数据入手，深入分析客户流量，利用高质量威胁情报以及关联分析、机器学习、行为分析等技术，帮助客户及时定位未知威胁、高级威胁，降低攻击影响面，提升情报生产及安全运营能力。
从蜜罐视角看Apache Log4j2漏洞攻击趋势

1 概述


Apache Log4j2是一个Java的日志库，可用于控制日志信息的级别和日志生成过程。最近，Apache Log4j2被曝出JNDI注入漏洞（CVE-2021-44228），攻击者仅需要向目标服务器发送特定JNDI链接就可以触发漏洞并在目标机器上执行任意代码，影响面和破坏力极大。受影响用户需及时升级到安全版本。


360网络安全研究院 Anglerfish蜜罐系统在搜集网络攻击威胁情报领域具有国际领先的技术优势。从2017年WannaCry勒索病毒爆发至今，我们通过对网络攻击常见套路的分析和总结，模拟了大量应用协议和漏洞特征。该系统已经具备及时发现并响应大网威胁的能力，在第一时间内发现了多起大规模网络攻击事件。


北京时间2021年12月10日凌晨0:20，距离漏洞公开不足一天，该系统就首次捕获到了Apache Log4j2漏洞相关攻击。截至12月17日，该系统共捕获2042个攻击源IP（其中中国250个，国外1792个）发起的利用Apache Log4j2漏洞的攻击72242次，攻击源IP涉及54个国家，发现132个攻击源IP利用该漏洞传播了属于30个恶意软件家族的617个已知恶意软件md5。



2 甲方的相关需求


对于受影响的甲方而言，在采用安全产品进行防御，以及对相关组件的紧急修复也存在着一些“坑”，比如下面这些：


对于传统安全产品和紧急修复措施存在的种种问题，威胁情报是一个非常好的补充。甲方可根据威胁情报，针对性地阻断漏洞攻击源IP和下载服务器链接，为资产打上“预防针”。


3 威胁情报的视角

上图是漏洞攻击数量随时间变化的曲线，可以看出漏洞曝光后，攻击会话的数量在接下来的几天内快速上升。在攻击会话数最多的12月18日，一天内有超过28000次的攻击会话。12月13日开始，还出现了该漏洞与其他漏洞（Apache Flink、Hadoop、Apache Struts2漏洞等）的组合攻击。


上图是主要的攻击源IP，可以看出发起漏洞攻击最多的源IP地址为78.31.71.248，占总体IP攻击数的约9%，其它主要的攻击源IP见右边图例。


在传播恶意软件方面，我们最早在12月11日8点整率先捕获到了Muhstik僵尸网络样本，随着时间推移，恶意软件传播的数量明显增加。





攻击源IP
传播恶意软件会话数
恶意软件md5
恶意软件家族




170.210.45.163
4,753
28
6


167.71.175.10
4,678
15
4


164.52.53.163
3,926
30
6


46.105.95.220
3,710
30
6


1.116.59.211
2,824
31
6


89.249.63.3
2,195
31
6


86.109.208.194
2,121
29
6


178.176.202.121
2,081
29
6


175.6.210.66
2,025
30
7


191.232.38.25
1,776
23
6


上表列出了利用Apache Log4j2漏洞传播恶意软件最多的10个IP，以及这些IP传播恶意软件md5的数量和恶意软件家族数量。








我们按照ssdeep值对捕获的1083个可执行文件和Java 字节码类型的样本进行聚类分析，共得到107类样本，主要为Java字节码文件，其中的30类617个恶意软件md5我们可以识别出属于特定的恶意软件家族，剩下的目前还未知。

从恶意软件的下载服务器来看，34.221.40.237是出现次数最多的下载服务器，有接近一半的恶意软件都来自这个下载服务器。这是一个位于美国的AWS云服务器IP，其它常见的下载服务器见上图右边的图例，下表列出了攻击者使用的10个下载服务器。





域名/IP
攻击源IP数量
恶意软件数量
恶意软件家族
传播会话次数




34.221.40.237
102
8
2
50,358


159.89.182.117
102
1
1
1,850


18.228.7.109
75
15
1
2,947


31.220.58.29
73
6
2
467


137.184.174.180
66
1
1
1,097


68.183.165.105
66
5
1
6,334


210.141.105.67
51
1
1
183


45.130.229.168
15
1
1
34


103.13.230.149
14
6
1
156


54.210.230.186
14
1
1
19


45.80.181.55
6
6
1
54





在可以溯源的攻击源IP中，大多数攻击来自于Alpha Strike Labs（一家德国网络安全企业）的漏洞扫描测绘。除了安全厂商和研究机构外，还有大量来自Tor出口节点的攻击。



4 把威胁情报用于攻击防护


威胁情报可以帮助相关单位了解公网上正在发生的漏洞攻击的趋势和攻击者的来源，帮助用户及时把还未发生的网络攻击事件扼杀在摇篮中，具有使用方法简单，数据内容丰富，准确性高，并且不会对业务产生影响等优势。


此次Apache Log4j2 RCE漏洞攻击对网络安全产品是一次大考，面对未知漏洞攻击，表现不尽人意。


360 Anglerfish蜜罐系统通过多样的协议、应用和漏洞模拟和部署在全球范围的公网节点，及时、快速发现和捕获网络攻击威胁相关信息，并支持自动化输出漏洞利用，扫描协议、组织溯源和恶意样本四个维度的威胁情报。
用DTA照亮DNS威胁分析之路 (1)

--- “历史重现”小功能


概述

2021年10月，《七年一剑，360 DNS威胁分析平台》宣告了360 DNS威胁分析平台(简称DTA)的诞生。在文章开头，Netlab阐述了设计DTA的核心理念：




让情报发挥应有价值

让威胁分析真正有效



理念是简洁的，也是抽象的。18个字背后，对应着Neltab 7年的安全研究经验；而7年的沉淀，又在2年时间的打磨里，变成了DTA众多的功能。为了让抽象的理念具象化，后续，我们将推出一系列DTA相关博文，希望通过这些文章案例，在介绍产品某个具体功能如何使用的同时，顺带说明理念是怎样指导功能设计的；也希望这些示例，能为DTA的进阶使用者提供入门参考。

需要提醒使用者的是，DTA是一款灵活的数据分析产品，它一端连接着用户网络的全量DNS数据，另一端连接着360海量云端数据，DTA将这两者汇合，并在平台上努力提供得心应手的各种预置操作工具和大量预处理模型。但全量和海量的二者碰撞，究竟能演绎出多少精彩的内容，绝对是和使用者有极大关系的。在平台上，已经准备好了组件和工具，也有我们一直在更新迭代搭建完成的模型，但模型如何使用，不同的模型如何组合和拼接，有各种可能性。管理员按照自己的技术能力水平，既可以傻瓜式使用系统内置的数据结果，也可以组合和使用不同的模块及产出的数据，对DNS的数据进行观察，对用户、告警进行深入高阶分析，请发挥想象，不要被博文介绍的入门内容限制住了思路。

本文是系列文章的第一篇，我们从一个非常简单，即使是新手上路的同学也很容易理解的“历史重现”功能，简单的串下DTA的一些功能元素。


场景

作为公司的安全运营人员，在获取到新的威胁情报时，除了将IoC加入到安全产品，应该还会有这样的疑虑，举例来说：

比如360的安全运营人员，在2021-11-10，当看到ESET在twitter上发布了一则关于Lazarus使用带后门IDA攻击安全分析人员的消息时，他心里应该会想：我们是安全公司，IDA使用普遍，公司内会不会有人碰巧违规使用了这些软件？如果有，是什么时间什么资产在使用？

DTA解决这个问题的理念是：“让情报发挥应有价值”。情报的价值，不应局限于“现在”和“将来”的IoC匹配告警；当新情报出现时，也应该能够在“过去”的历史数据里挖掘出应有价值。

那产品的功能是如何实现的呢？


数据

首先，这个和DTA分析对象有关，它分析的是全量DNS日志数据。

DNS简单且重要。据统计，DNS在企业网全流量里占比小，但超过80%的恶意软件却和DNS协议相关。因此，DTA只要把好DNS这个关口，也能帮助企业发现大部分威胁。具体到真实的公司环境，比如一个拥有6000名员工的公司，日常的DNS流量在10~15Mbps之间，换算成每秒请求数(query per second)，为5千~8千qps，一天的总量大概在7亿。和全流量比，这个量级可以让DTA 以年为单位 存储全量DNS日志(下文称DNS日志数据库)，而对存储和算力的要求，普通服务器就可以满足。

其次，DTA内部集成了一个mini PDNS，其功能类似于Netlab从2014年开始运维的中国最大公开PDNS数据库(passivedns.cn)，会以极低的成本存储自DTA接入以来的全量DNS数据，并提供快速查询。

有了这两个数据的支持，在平台上实现“历史重现”的功能就是水到渠成的事情了。


功能

根据IoC数量的不同，DTA平台提供了两种查询方式。还是以ESET提到的带后门IDA例子为例。


单个IoC

在推文里，提供了一个C2域名：devguardmap[.]org。

我们在“全局搜索栏”里选择搜索类别：域名，然后输入或ctrl+v粘贴想要查询的域名，如果该域名在历史上没有被公司内的任何资产访问过，会提示“没有数据”。此刻，您可以放宽心了。

如果有命中，也先别惊慌，进一步选择域名查看详情再做结论。打个岔，从“搜索结果”可以看出，搜索结果会把满足子串匹配的所有域名也都列举出来供选择。

图-3是360内部对该域名的访问情况，两个关键信息：1、在右上角指定的时间范围内，共有11个资产访问了该域名；2、该域名在公司网络内出现的首次时间是：2021-11-11 10:39:25。由于时间是在推文发布(2021-11-10)之后，可以猜测大概率是研究人员在复盘，不是真实的感染。王婆卖瓜一下，360对安全事件的反应还是挺迅速的:)。进一步的，可以点击左侧栏的资产列表，对安全运营人员来说，结合其它信息，能定位到是哪些员工在跟进这个事件。

对安全敏感的读者，也许已经注意到域名的下方，有多个tabs，这些tabs里面有DTA系统的多种模型，从数据维度提炼和展现相关对象的多种角度的数据结果，比如这里面有3个橙色的标签：“可疑境外域名”、“UnknownThreat.persistent_access”和“可疑心跳域名”，这些标签是DTA内置的未知威胁模型在分析关联多个维度数据后给出的“可疑域名”判定。橙色标签就像交通灯亮起了黄灯，警示分析人员需要做进一步的分析。至于如何做进一步的分析，找出真实的威胁，后面其它文章细聊。

读者请注意，我们这里举的是一个历史数据的简单匹配，但DTA对这个简单例子的处理方式，和传统意义上的安全事件告警响应系统或者日志查询有很多的不同，如果仔细体会例子的各种细节，应该能感觉到系统从底层数据到页面布局，都是为方便展开威胁分析而设计的。把页面比作操作台，那操作台上既有原材料(用户的DNS数据和360的云端数据)，也有DTA自动产出的大量的预处理结果和不同的各种相关组件内容(可疑域名标签，资产类别，用户行为偏好等)，类似于乐高片，分析人员按照自己的经验想法，依次组合这些组件，可能就形成了一类有效的威胁分析。依照自己的能力水平，既可以浅尝辄止，也可以持续深入，从完全未知一步步向真相迈进。


多个IoC

在推文里，还出现了另一个域名：www[.]devguardmap[.]org。对多个IoC，DTA通过“威胁分析”页面实现历史数据查询。

“威胁分析”页面提供两种查询方式：1、熟悉语法的，直接书写“查询表达式”；2、不熟悉语法的，在右侧“构建表达式”里分别点击选择查询类别，运算符，输入或选择查询内容，最后点击“应用”按钮开始查询。

查询完成后，通过点击图-4的“2个域名”，“解析到1个IP”，“涉及11个资产”，“共14个请求”等按钮，查询结果会以4种不同的视角，即域名，Rdata，资产，请求时序的角度展现历史DNS请求解析情况。通过更多的角度观察同一份数据，能有效帮助分析人员形成威胁判研。


结语

本文以“历史重现”小功能为起点，通过实例细节，展示了这个功能点是如何和核心理念的第1条对应起来的。您在使用DTA时，也可以多观察，还有哪些功能点是和理念第1条相关的。后面，我们也会继续举例说明。

但下一篇，我们先来谈一谈核心理念的第2条：“让威胁分析真正有效”，看一看DTA是如何将360云端安全数据赋能到用户数据之上的，敬请期待。

产品、商务咨询，请联系 xuyinghan@360.cn
用DNS发现未知威胁，恶意程序基础设施迭代更新

之发现


360Netlab的DNSMon利用海量的多维度数据以及大网的DNS数据，对异常的域名进行监控判定，如果定性为恶意域名会自动生成IOC并在一定范围内进行拦截。


在12.8，DNSMon在无规则的情况下拦截了一个异常的二级域名 xiaoniu321[.]com及其子域名www2.xiaoniu321[.]com 。




在12.10针对样本数据的分析中，发现样本 65982deb6ac30b9f1f4dab1aa26a0d0e 在大量扩散并且和之前拦截的域名有着密切的关系，同时注意到www2的子域名上存在如下的URL链接。


http://www2.xiaoniu321[.]com:9002/1vv/ii7.exe
http://www2.xiaoniu321[.]com:9002/1vv/Nidispla2.exe
http://www2.xiaoniu321[.]com:9002/111/Nidispla2.exe



 1. 首先从xiaoniu321.com以及其对应的样本65982deb6ac30b9f1f4dab1aa26a0d0e 在迅速的扩散
 2. 其次xiaoniu321.com 的域名注册很新
 3. 从样本出发，发现若干近似样本与域名www1.jincc.cc有关联，并且xiaoniu321.com和jincc.cc的子域名结构很像。并且有段时间共享一个IP103.142.8.74。并且他们的URL结构很像，都包含nidisplay字样。 在10.19的时候已经被我们block了。
 4. 从流量图上来看，也存在此起彼伏的特征。
 5. 从xiaoniu123的IP上也可以关联出 7yx77.com，猜测是恶意程序运行过程中的配置文件
 6. 通过查询文件名nidisplay.exe，发现是激活工具在传播hpaccess病毒。主要是做ddos功能。
 7. 通过图系统关联，发现跟独狼有关。
 8. 通过对比配置文件，发现和独狼有关，



IOC


7yx77.com





参考文档


 1. https://www.bilibili.com/video/av969086155/
 2. https://bbs.huorong.cn/archiver/?tid-76990.html
 3. https://mp.weixin.qq.com/s/-Pg-4MoD9LyQN5hmS-HOow
 4. https://graph.netlab.qihoo.net/#/explorer?snapshot=61c5970a21addfb5089292ea
 5. https://www.freebuf.com/articles/system/218191.html
用DTA照亮DNS威胁分析之路 (3)

--- 内置未知威胁分析模型介绍


概述

在系列文章2，介绍了如何利用DTA进行一轮完整的未知威胁分析，共有3个步骤：




1、提出分析思路，从DNS日志里找到可疑线索

2、确认可疑线索有威胁行为

3、借助DNS日志确认资产被感染



其中，这几个步骤里最为安全分析人员所熟悉的应该是步骤2，毕竟日常工作大家都少不了利用各家威胁情报平台、搜索引擎和云沙箱进行信息搜集+关联+确认可疑线索；而步骤1和3，因为涉及到DNS日志，对于不熟悉DNS的分析人员来说，是需要一定学习成本去积累相关分析经验和熟悉DTA的各类元数据的。

因此，针对未知威胁分析，DTA预置了可疑心跳域名、可疑NOD(新出现在网络中的可疑域名)、可疑境外域名等等模型，这些模型以后台运行的方式自动完成上述3个步骤，当模型计算出某个域名存在威胁行为时，会在首页以威胁告警的方式通知分析人员有“未知威胁”类型的告警需要进一步分析。

此时，未知威胁分析的难度和工作强度，降低到了和已知威胁分析差不太多的高度。分析人员只要按照已知威胁分析的模式开展工作，即可完成告警的处置，清除网络存在的未知威胁隐患。


模型

不难想象，未知威胁分析模型对刚刚接触DTA的分析人员来说，乍听起来会觉得专业生僻，令人心生抗拒。不过如果把模型映射到现实生活，读者把自己代入成朝阳群众那样去分析身边隐秘的线索，会发现模型的原理其实是简单易懂的。首先，按下表做一个映射。




实体
元素1
元素2
元素3
日志的含义




DTA
资产
时间
域名及其Rdata
某资产在某时间请求解析某域名


现实世界
人
时间
地点
某人在某时间出现在某地点





那么，DTA记录在数据库的DNS日志，就如同现实世界里的摄像头，忠实地记录着监控范围内发生的事件。通过分析监控，可以总结出一些可疑情景和模型相对应：

1、某段时间，某人总是在每天的某个时间点准时在某个地方出现。这个情景对应到DTA，属于“可疑心跳域名”：就是资产有周期性域名请求，每隔一个固定时间段会发出对该域名的解析请求。DTA部署实践发现，winnit、双枪等多个恶意家族的C2域名在DNS日志上有明显的心跳周期行为。

2、某天，在某个地方出现了一个大家都没见过的陌生人。这个情景对应到DTA，叫做“可疑NOD”：即有资产请求了新观测到的域名(New Observe Domain)，这个域名在以往的访问历史里，从来没有在该网络出现过。可疑NOD适用范围较广，在攻击行为发生的下载、通信阶段等都有机会捕获到线索。

3、如果有某人，经常前往境外的某个地点，这个地点，普罗大众几乎没有前往的记录。这个情景对应到DTA，则是“可疑境外域名”：资产访问了一个很少有人请求的境外域名，很少有人请求这个指标是通过统计大网的PDNS数据来度量的，比如自域名出现以来，全中国访问该域名的人数不超过20个。想挖掘高级威胁的分析人员，可以多关注此模型提供的线索。我们曾经测试回溯360发布的APT报告域名类IoC，发现部署在公司内部的DTA，在安全人员利用沙箱测试样本的时候，此模型都能捕获到线索(系列文章1的图-3算是一个不完全恰当的例子--IoC不是360报告)。不过也要保持清醒，找到线索在一个完整的高级威胁分析周期里，大概只能算万里长征的第一里，方向有了，但更多的艰苦在后头。

4、某同事每天上班，总是来回背着鼓鼓囊囊的背包，而其他同事多是两袖清风地上下班，这个情景对应到DTA，叫“可疑DNS隧道”：正常的域名请求，前缀相对固定且字符较少，如果某个域名的前缀变化多端，有可能是恶意程序在和C2通信，将偷窃的数据隐藏在正常的DNS请求和响应中。

原理是简单的，难点在大数据的环境下，符合规则的数据量会远超人力可处理范围。以NOD为例，在一个稍有规模（比如1000个员工）的公司网络里，工作日观察到的NOD域名数量可达百万级别，而在休息日，也有十万级别。在这里，借助360云端大数据和积累的经验规则，可以让模型把可疑线索的数据量在尽可能不漏报的情况下降到百或千的级别，然后以可控地方式进入到步骤2和3。

在步骤3，有一个非常值得一提的“自动分析”功能，当该功能分析出告警事件为“无威胁”时，会在告警状态栏打上“无恶意行为”的徽章并给出判断理由。

除了未知威胁相关的模型，DTA也集成有很多其它类别的模型用来辅助威胁分析。比如可以帮助分析人员判断资产性质的模型，这些模型能标定资产是客户端或服务器，以及操作系统是Windows或安卓等等；又比如在域名分析页面，为帮助分析人员串起一个事件的前后域名访问关系，集成有共同访问模型。如此等等，不一而足。


举例

前面的原理介绍，说明了模型的思路和使用场景。这一节，我们来个例子介绍一下在DTA是如何处置未知威胁类型告警的。

点击顶部菜单栏进入“威胁告警”页面。页面的第一栏是告警汇总栏，其中，威胁类型分为3类：1、已知威胁和AI识别威胁是由引擎实时匹配IoC产生的；2、网络异常是DNS流量相关的异常；3、本文所描述的未知威胁。

点选“威胁类型”里的未知威胁，页面的第二栏告警列表栏会把指定时间段内的未知威胁过滤出来，通过标题，即可以分辨告警是由可疑心跳还是NOD还是DNS隧道引起的。

打开状态为“待分析”的事件，进入告警详情页面。页面第一栏IoCs列出域名的基本信息和模型在第2步运行时关联到的判黑情报；第二栏列出当前受影响的资产及其请求恶意域名的概况；在处理完成后，可以在第三栏写下分析经验，供其他人参考。

如果想进一步看模型在第2步时的关联关系，点击右上角的“威胁情报图”。

根据告警详情页面提供的威胁情报，有逆向能力的分析人员，可以分析样本的行为进一步实锤确认；想轻松一点的可以先尝试通过搜索引擎和各家威胁情报平台搜索关键字，看看有没有相关的分析报告。这个例子里，通过搜索引擎搜索 “macapproduct[.]com macos”关键字，可以搜到相关的分析报告，比如《利用EXE文件攻击MacOS》。

至此，仅通过点击查看告警提供的内容和借助搜索引擎，分析人员就可以形成结论：这是一台操作系统为MacOS的资产，被利用exe文件的攻击方法感染了。至于后期的处置动作，因为DTA是被动监听型，必须和其它安全产品配合才能完成清除阻断。


结语

内置的自动化分析模型可以解决普适性的问题并降低安全运维难度和强度。但再丰富的规则也只能描述有限的场景，而网络安全对抗，新手法总是层出不穷，所谓魔高一尺道高一丈。

人的思想是最灵动的，发挥人的能动作用，在未知威胁模型的第1步输出结果上进行深层次的挖掘，有时会有意外收获。下篇举一例子说明如何基于未知威胁最原始的输出上进行威胁分析，敬请期待。

产品、商务咨询，请联系 xuyinghan@360.cn
用DTA照亮DNS威胁分析之路 (4)

--- 发挥人的能动作用


概述




举例

未知威胁无告警

只保留新出现的心跳域名

点击心跳域名列表左上角的威胁情报图

样本无识别

telegram中文版“关联出样本80385




中文版下载地址
域名注册时间
安装压缩包
安装文件名称
安装文件MD5
VT识别




telegram-cn[.]org
2021-06-30 14:30:21
tsetup.zip
Telegram中文版.msi
58f8d9e024de1ad31c6c88e70bba6f58
14/57


www[.]telegram-zh[.]org
2021-11-24 14:28:25
Telegram Desktop.zip
Telegram Desktop.exe
ed1b74827b64fc8913af19b1b745ad1a
23/64


borsolo.oss-ap-southeast-1.aliyuncs[.]com
-
telegram.rar
Telegram中文版.msi
54cc6069bc165be77301937286fc6b82
20/59


www[.]telelgracn[.]com
2021-06-27 07:00:00
setup.zip
Telegram中文版.msi
53fb412a783e10607871fd205492981a
2/58


www[.]telegldcn[.]com
2021-08-07 07:00:00
setup.zip
Telegram中文版.msi
8038518d5023819708d2282e348ca931
22/59





全局关联

样本相似性：域名结构相似，伪造知名公司

内嵌gh0st变种，C2：www.windowstimeupdate.com:9006




结语

发挥人能动性的环节：中文版telegram；域名相似性，

未知威胁科普系列完结，后续继续科普其它，比如资产可视化。资产的重要性。

产品、商务咨询，请联系 xuyinghan@360.cn
俄乌冲突对比（DDoS攻击）

考虑到我方视野不可避免的具有一定局限性，所以以下内容仅可供参考，并不能作为严谨定论。



激烈状态对比


从数据上看，针对 *.gov.ua 域名的攻击在 2月 23 日出现比较多的增长，这一天正是俄乌武力冲突的第一天。





而针对 *.gov.ru 域名的攻击，则在 2月 26日 出现比较多的增长（如下图所示），这一天希拉里在媒体号召网络势力通过攻击俄罗斯支持乌克兰。 《Hillary Clinton Advocates Cyber Attacks To Support Opposition Inside Russia: "We Did Some Of That In The Arab Spring"》






“号召力”评估


参与 2月23日攻击乌克兰的CC主要看到一个，为 thelocalhomecamera.accesscam.org 。





参与 2月26日攻击俄罗斯的CC则有9个，由于所涉及CC较多，这里仅附上整理后的列表供参考。





从数量上看，似乎乌克兰背后的“号召力”更强一些。但俄罗斯其实是发起方，有战前保密的需求，无法提前发动网络号召，导致民间力量无法加入进来。而乌方9个CC中大部分都是ripprbot这个家族，背后对应的应为一(个/伙)人，且由于参与分析的CC数量较少，故这部分结论仅能作为参考。



谋划已久/临时起意


对比“激烈状态对比”章节的两张图，我们还可以发现，针对乌克兰的攻击具有一定的持续性，近大半个月的时间内基本没间断过攻击。而针对俄罗斯的攻击则具有偶发性，仅在 26日-27日有较大波动，其他时间则寥寥无几。这似乎意味着背后参与者与受害者之间并不存在直接的冲突。相反，针对乌克兰攻击的持续性则表明，一直有人对相关受害者表示不满。



IOC


attack_ua:

thelocalhomecamera.accesscam.org:27159 2022-02-26 4b135956714efae14b149549fcb34379


attack_ru:
136.144.41.117:3685          2022-02-27    720273b03f19f571a48a9315af22fd0c  gafgyt
136.144.41.69:34241          2022-02-06    1b897bdc0103c727a246626bd24aa440  mirai
157.245.117.125:13           2022-02-24    90ed973ac6826ddaf7ca1abe992f8ef5  mirai
171.22.109.201:8080          2022-02-03    60323238aa2cc93669d609a7fb11f154  ripprbot
login-lloyds.com:20715       2022-02-12    5612c200f51e78944ea806318307f4c8  ripprbot
iwishiwasnormal.ru:20715     2022-02-12    5612c200f51e78944ea806318307f4c8  ripprbot
ilikefishing.xyz:20715       2022-02-12    5612c200f51e78944ea806318307f4c8  ripprbot
iranistrash.cc:27015         2022-02-12    1b333e808f8df0ff220f58e0b9fd5b5f  ripprbot
juicewrldd.cf:60221          2022-02-10    51f6c8cca2669c3a084c911ba23e686f  ripprbot
DDoS跟踪之HTTP代理攻击

背景


请各位读者自行脑补，?



TODO


 * 攻击趋势
 * 目标SLD，TLD分布
 * 源IP分布，地理位置，PTR，AS，TAG
 * 总结
 * 自建bog？
 * 代理/vpn服务？