360 Netlab Blog - Network Security Research Lab at 360 (Page 2)

用DTA照亮DNS威胁分析之路 (3)

--- 内置未知威胁分析模型介绍概述在系列文章2，介绍了如何利用DTA进行一轮完整的未知威胁分析，共有3个步骤： 1、提出分析思路，从DNS日志里找到可疑线索 2、确认可疑线索有威胁行为 3、借助DNS日志确认资产被感染其中，这几个步骤里最为安全分析人员所熟悉的应该是步骤2，毕竟日常工作大家都少不了利用各家威胁情报平台、搜索引擎和云沙箱进行信息搜集+关联+确认可疑线索；而步骤1和3，因为涉及到DNS日志，对于不熟悉DNS的分析人员来说，是需要一定学习成本去积累相关分析经验和熟悉DTA的各类元数据的。因此，针对未知威胁分析，DTA预置了可疑心跳域名、可疑NOD(新出现在网络中的可疑域名)、可疑境外域名等等模型，这些模型以后台运行的方式自动完成上述3个步骤，当模型计算出某个域名存在威胁行为时，会在首页以威胁告警的方式通知分析人员有“未知威胁”类型的告警需要进一步分析。此时，未知威胁分析的难度和工作强度，降低到了和已知威胁分析差不太多的高度。分析人员只要按照已知威胁分析的模式开展工作，即可完成告警的处置，清除网络存在的未知威胁隐患。模型不难想象

公有云威胁情报

公有云网络安全威胁情报（202201）

1. 概述 2022年的第一个月份，虽然没有爆发新的热门漏洞，且随着越来越多设备的Apache Log4j2漏洞被修复，12月开始的Apache Log4j2漏洞爆发也进入尾声，相关攻击源数量明显减少。但是，Docker Remote API未授权访问漏洞、美国飞塔（Fortinet）FortiOS未授权任意文件读取漏洞等旧漏洞的云服务器攻击源IP数量突然较12月大幅度增加。在第2部分，我们分析了这两个漏洞的攻击趋势和攻击方法。政府和企事业单位的云上资产方面，1月份共发现26个云上资产对外扫描攻击，其中某航天研究单位、某县级人民医院（都架设在阿里云上）等单位使用的云服务器IP在公网上发起攻击，值得关注。本文主要通过360网络安全研究院 Anglerfish蜜罐视角，分析云上热门漏洞攻击细节，以及云上重要资产在公网上发起攻击的情况。 2. 云上热门漏洞攻击威胁本月没有爆发的新漏洞攻击，但值得注意的是，本月有一些旧漏洞的攻击源IP数量较12月出现了大幅增加。增长最多的是Docker Remote API未授权访问漏洞和美国飞塔（Fortinet）FortiOS未授权任意文件

公有云威胁情报

公有云网络安全威胁情报（202112）

1. 概述云服务具备部署方便、资源灵活弹性、按需付费等优势，各类企业、政府、事业单位、高校和研究机构近年来都参与到了“上云”的潮流中。然而，随着越来越多各行各业的敏感数据“上云”，云安全问题的重要性和紧迫性也越发突出。近年来，全球云服务器被DDoS攻击、入侵、网站页面恶意修改、敏感数据泄露、加密勒索、恶意挖矿等安全事件频发，特别是提供公网服务的云主机，时时刻刻面临着漏洞攻击、暴力破解、Bot流量等云上网络威胁，这要求无论是云服务商还是云上用户都需要时刻做好威胁检测和处置的准备。云安全的关键是“知己知彼”。“知己”就是做好云上资产、组件、数据和漏洞的管理，包括对云上数据按照敏感程度分类管控、对云上资产和组件做好清点和监控，及时全面修复漏洞，保证云产品安全配置正确等。而“知彼”就是及时发现和阻断各类外部网络威胁。传统的以硬件为载体的各类安全产品难以部署于云端资产，无法适应公有云轻量、虚拟化、灵活取用的特点。而威胁情报结合云原生防火墙，不需要复杂的部署和配置，就可实现云上资产对公网威胁的全面防护和管控。根据360 Anglerfish蜜罐系统捕获的威胁情报数据，本文从近期云

用DTA照亮DNS威胁分析之路 (2)

--- 对服务器网段进行未知威胁分析概述要进行网络威胁狩猎，或者低调点叫网络威胁分析，通常需要具备3个能力： 1、找到线索的能力。这里的能力是特指在无先验知识(IoC等)条件下，既尽可能无漏报又不会有太多误报地从海量数据里挖掘出线索； 2、确认线索是威胁的能力。线索是包含噪音的，需要去除噪音只留下有威胁的线索； 3、分辨资产被真实感染的能力。只有确认真实感染，才能保证后续的威胁处置动作有成果。按：由于DTA也实现有“已知”威胁分析功能，但其用法和本文描述的操作细节相差甚远，为避免混淆，特此说明一下本文所有威胁分析的用词，都是指“未知”威胁分析。在上一篇文章，我们提到DNS日志的优点是简单且重要。但正是福兮祸所倚，简单这个优点，从威胁分析的角度来讲它又成了最大的缺点，因为这意味着日志包含的有效信息少。具体来讲，一次DNS请求和回应所解析出来的内容，除去极个别喜欢炫技的特意使用有区分度的词语，比如hackerinvasion[.]f3322.net， hackattacks[.]org等，大多数日志很难从字面意义上获取有效威胁信息。与此相反，倒是有不少看

用DTA照亮DNS威胁分析之路 (1)

--- “历史重现”小功能概述 2021年10月，《七年一剑，360 DNS威胁分析平台》宣告了360 DNS威胁分析平台(简称DTA)的诞生。在文章开头，Netlab阐述了设计DTA的核心理念：让情报发挥应有价值让威胁分析真正有效理念是简洁的，也是抽象的。18个字背后，对应着Neltab 7年的安全研究经验；而7年的沉淀，又在2年时间的打磨里，变成了DTA众多的功能。为了让抽象的理念具象化，后续，我们将推出一系列DTA相关博文，希望通过这些文章案例，在介绍产品某个具体功能如何使用的同时，顺带说明理念是怎样指导功能设计的；也希望这些示例，能为DTA的进阶使用者提供入门参考。需要提醒使用者的是，DTA是一款灵活的数据分析产品，它一端连接着用户网络的全量DNS数据，另一端连接着360海量云端数据，DTA将这两者汇合，并在平台上努力提供得心应手的各种预置操作工具和大量预处理模型。但全量和海量的二者碰撞，究竟能演绎出多少精彩的内容，绝对是和使用者有极大关系的。在平台上，已经准备好了组件和工具，也有我们一直在更新迭代搭建完成的模型，但模型如何使用，不同的模型如何

Day 10: where we are with log4j from honeypot’s perspective

Our team spent great deal of effort on simulating different protocols, applications and vulnerabilities with our honeypot (Anglerfish and Apacket) system. When big event happens, we are always curious what we see from the honeypot side. Since log4j came to light 10 days ago, we have published two related blogs,

从蜜罐视角看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个恶意软件家

Ten families of malicious samples are spreading using the Log4j2 vulnerability Now

Background On December 11, 2021, at 8:00 pm, we published a blog disclosing Mirai and Muhstik botnet samples propagating through Log4j2 RCE vulnerability[1]。 Over the past 2 days, we have captured samples from other families, and now the list of families has exceeded 10. It looks like the

已有10个家族的恶意样本利用Log4j2漏洞传播

背景介绍 2021年12月11号8点整，我们率先捕获到Muhstik僵尸网络样本通过Log4j2 RCE漏洞传播，并首发披露Mirai和Muhstik僵尸网络在野利用详情[1]。 2天来，我们陆续又捕获到其它家族的样本，目前，这个家族列表已经超过10个，这里从漏洞、payload、攻击IP 和样本分析等几个维度介绍我们的捕获情况。 Apache Log4j2 漏洞攻击分布 360网络安全研究院大网蜜罐系统监测到Apache Log4j2 RCE漏洞（CVE-2021-44228）扫描及攻击，源IP地址地理位置分布如下：国家/地区攻击源IP数量 Germany 271 The Netherlands 143 China 134 United States 123 United Kingdom 29 Canada 27 Singapore 23 India 22 Japan 15 Russia 12 通过对扫描端口分析发现，

Threat Alert: Log4j Vulnerability Has Been adopted by two Linux Botnets

The Log4j vulnerability that came to light at the end of the year can undoubtedly be considered a major event in the security community. Honeypot and botnet are our bread and butter, and we have been concerned about which botnets would be exploiting this since the vulnerability was made public.

威胁快讯：Log4j漏洞已经被用来组建botnet，针对Linux设备

年末曝光的Log4j漏洞无疑可以算是今年的安全界大事了。作为专注于蜜罐和botnet检测跟踪的团队，我们自该漏洞被公开后就一直关注它会被哪些botnet利用。今早我们等来了首批答案，我们的Anglerfish和Apacket蜜罐先后捕获到2波利用Log4j漏洞组建botnet的攻击，快速的样本分析表明它们分别用于组建 Muhstik 和Mirai botnet，针对的都是Linux设备。样本分析 MIRAI 这一波传播的为miria新变种，相比最初代码，它做了如下变动： 1. 移除了 table_init/table_lock_val/table_unlock_val 等mirai特有的配置管理函数。 2. attack_init 函数也被抛弃，ddos攻击函数会被指令处理函数直接调用。同时，其C2域名选用了一个 uy 顶级域的域名，这在国内也是很少见的。 Muhstik Muhstik 这个网络最早被披露于 2018 年，系一个借鉴了Mirai代码的Tsunami变种。在本次捕获的样本中，我们注意到新Muhstik变种增加了一个后门模块ldm，

公有云威胁情报

公有云网络安全威胁情报（202111）：云上多个资源对外发起攻击

1 概述 2021年11月，360网络安全研究院 Anglerfish蜜罐（以下简称“蜜罐系统”）共监测到全球53745个云服务器发起的网络会话9016万次，与10月份的数据相比略有下降，IP数量下降7.7%，会话数量下降2.1%。本月我们发现了涉及政府、事业单位、新闻媒体等多个行业的单位的8个云服务器IP地址在互联网上发起扫描和攻击。 2 云服务器攻击总体情况 11月22日~24日的突增主要是由以下两个IP地址造成的：一个是腾讯云119.45.229.133，在11月22~24日每天向蜜罐系统发送了数十万个敏感文件嗅探数据包以及上千个微软OMI漏洞探测数据包。另一个是位于荷兰的DigitalOcean云服务器188.166.54.243，该服务器在11月24日一天内向蜜罐系统发送了18万个Telnet暴力破解数据包。按云服务商维度来看，与上月相比，来自腾讯云和DigitalOcean的攻击会话数量明显增多。特别是腾讯云的攻击会话数量从上月的10万左右增加到了本月超过100万。 10月份腾讯云攻击会话前三的IP地址和会话数分别为：43.128.26.129（21,128）

An assessment of Non-Authorized Domain Name Resolution provided by DNS Resolution Service Provider

Summary In a previous article, we disclosed that the Specter botnet uses api. github[.]com and other white domains to provide C2 services as a way to evade detection by security products based on signature and threat intelligence matching. The botnet can do this because the Domain Name Resolution provider

解析服务提供商对非授权域名解析情况的评估

概要在之前的文章中，我们披露了Specter僵尸网络序利用api[.]github.com等白域名提供C2服务，以此来逃避基于签名和威胁情报匹配的安全产品的检测。其具体原理经过分析之后，发现其利用了某些域名注册/托管商(cloudns)的权威DNS服务器在解析非其客户域名方面的漏洞。我们对此现象，即域名注册/托管商，公有云提供商等能够提供域名注册和解析服务的供应商（以下统称为解析服务提供商）对非自己服务域名的DNS请求是否能够返回正确应答的情况，进行了系统的测量和评估。这篇文章对此现象进行了分析。数据选择及评估方法被测域名被测试域名：Alexa top500。选择他们作为被测域是因为： 1. 这些域名都会使用自己专有的DNS服务器，他们并不会使用外部的解析服务提供商提供的解析服务。所以如果这些域名可以被外部的解析服务提供商的NS服务器解析，那么大概率是非授权的。 2. 这些域名本身也因为其庞大而知名的业务，会被加入到各种白名单中。一些出于探测目的的人也更容易随手添加一些知名网站，而干坏事的人微了躲避检测黑名单检测，也愿意使用这些白域名。

EwDoor僵尸网络，正在攻击美国AT&T用户

背景介绍 2021年10月27日，我们的BotMon系统发现有攻击者正通过CVE-2017-6079漏洞攻击Edgewater Networks设备，其payload里有比较罕见的mount文件系统指令，这引起了我们的兴趣，经过分析，我们确认这是一个全新的僵尸网络家族，基于其针对Edgewater产商、并且有Backdoor的功能，我们将它命名为EwDoor。最初捕获的EwDoor使用了常见的硬编码C2方法，同时采用了冗余机制，单个样本的C2多达14个。Bot运行后会依次向列表中的C2发起网络请求直到成功建立C2会话。这些C2中多数为域名形式，有趣的是它们多数还未来得及注册，因此我们抢注了第二个域名iunno.se以获取Bot的请求。但一开始连接到我们域名的Bot非常少，因为大多数Bot都成功和第一个C2(185.10.68.20)建立连接，这让我们有些许"沮丧"。转机发生在2021年11月8日，当天7点到10点EwDoor的第一个C2185.10.68.20发生了网络故障，瞬间大量Bot连接到我们注册的C2域名，这使得我们成功的测绘了EwDoor僵尸网络的规模&感染范

EwDoor Botnet Is Attacking AT&T Customers

Background On October 27, 2021, our Botmon system ided an attacker attacking Edgewater Networks' devices via CVE-2017-6079 with a relatively unique mount file system command in its payload, which had our attention, and after analysis, we confirmed that this was a brand new botnet, and based on it'

公有云威胁情报

公有云网络安全威胁情报（202110）：趋势及典型案例分析

1 概述云计算服务价格低廉，部署快捷方便，但存在安全风险。黑客可以用虚假信息购买，或入侵他人机器获得云资源，用这些资源窃取、勒索原有用户的数据，或用于发起DDoS攻击、发送垃圾和钓鱼邮件、虚拟货币挖矿、刷单、违法代理和传播僵尸网络木马等其他恶意行为。 360网络安全研究院 Anglerfish蜜罐（以下简称“蜜罐系统”）通过模拟仿真技术伪装成针对互联网、物联网以及工业互联网的指纹特征、应用协议、应用程序和漏洞，捕获并分析网络扫描和网络攻击行为。在2021年10月，我们共监测到来自全球58253个云服务器IP共计9213万次的网络扫描和攻击，其中发现云上网站“某市供排水总公司”持续地对外发起网络攻击行为。 2 云服务器攻击总体情况由于IPv4地址和网络端口数量是有限的，黑客通过购买或入侵获取云服务器资源后，会扫描互联网IP地址，确定攻击目标。公网上的蜜罐系统模拟成相关设备和应用程序后，就有可能被黑客攻击。因此，蜜罐系统可以用于监测互联网上包括利用云服务器发起攻击在内的各类网络攻击行为。我们的数据来源除了蜜罐系统搜集到的网络五元组、网络数据包和恶意软件样本信息外，还包括一

The Pitfall of Threat Intelligence Whitelisting: Specter Botnet is 'taking over' Top Legit DNS Domains By Using ClouDNS Service

Abstract In order to reduce the possible impact of false positives, it is pretty common practice for security industry to whitelist the top Alexa domains such as www.google.com, www.apple.com, www.qq.com, www.alipay.com. And we have seen various machine learning detection models that bypass

白名单之殇：Specter僵尸网络滥用ClouDNS服务，github.com无辜躺枪

摘要威胁情报的应用，始终存在着“漏报”和“误报”的平衡，为了减少可能的误报带来的业务影响，你的威胁情报白名单中是否静静的躺着 www.apple.com、www.qq.com、www.alipay.com 这样的流行互联网业务域名呢？你的机器学习检测模型，依照历史流量，是否会自动对 .qq.com、.alipay.com 这样的流量行为增加白权重呢？但安全是对抗，白帽子想“判黑”，黑客想“洗白”。我们看到的白，不一定是真的白，可能只是黑客想让我们以为的白。我们BotnetMon最近的跟踪发现，Specter僵尸网络家族的样本，会使用api.github.com这种域名作为CC域名来通信，通过“可定制化”的DNS服务，将“白域名”引导到黑IP上来实现自己恶意指令通信。这种“过白”手法，在流量检测的场景下，

Malware uses namesilo Parking pages and Google's custom pages to spread

Abstract Recently, we found a suspicious GoELFsample, which is a downloder mainly to spread mining malwares. The interesting part is that we noticed it using namesilo's Parking page and Google's user-defined page to spread the sample and configuration. Apparently this is yet another attempt to hide

Import 2022-11-30 11:16

快讯：利用namesilo Parking和Google的自定义页面来传播恶意软件

摘要近期，我们发现一个GoELF可疑样本，分析得知是一个downloder，主要传播挖矿。有意思的地方在于传播方式，利用了namesilo的Parking页面，以及Google的用户自定义页面来传播样本及配置，从而可以躲避跟踪。该样本最开始被友商腾讯安全团队捕获，不过传播链条分析中，对namesilo parking域名的分析不太准确。往往大家以为，域名停靠期间(Domain Parking），页面显示内容是被域名停靠供应商强制限定的，域名实际拥有者并不能修改其页面内容。但在这个案例中，域名停靠供应商允许域名拥有者自定义停靠页面。攻击者利用了这一点，再加上Google提供的自定义页面来传播自己的木马。这样做有两个显而易见的好处：一方面攻击者几乎不需要为恶意代码的传播付出任何带宽和服务器的费用；另一方面攻击者将自己的恶意行为隐藏在大型互联网基础服务供应商的巨大流量中，所谓大隐于市，以此隐藏自己的行踪使得更难被检测和追踪。在我们的DNSMon/DTA监测数据中显示，这种趋势在最近几月有上升迹象，值得安全社区注意。缘起在10.13号，我们的BotnetM

Abcbot, an evolving botnet

Background Business on the cloud and security on the cloud is one of the industry trends in recent years. 360Netlab is also continuing to focus on security incidents and trends on the cloud from its own expertise in the technology field. The following is a recent security incident we observed,

僵尸网络Abcbot的进化之路

背景业务上云、安全上云是近年来业界的发展趋势之一。360Netlab 从自身擅长的技术领域出发，也在持续关注云上安全事件和趋势。下面就是我们近期观察到的一起，被感染设备IP来自多个云供应商平台的安全事件。 2021年7月14日，360BotMon系统发现一个未知的ELF文件(a14d0188e2646d236173b230c59037c7)产生了大量扫描流量，经过分析，我们确定这是一个Go语言实现的Scanner，基于其源码路径中"abc-hello"字串，我们内部将它命名为Abcbot。 Abcbot在当时的时间节点上功能比较简单，可以看成是一个攻击Linux系统的扫描器，通过弱口令&Nday漏洞实现蠕虫式传播。一个有意思的事情是，Abcbot的源码路径中有“dga.go”字串，但是在样本中并没有发现相关的DGA实现，我们推测其作者会在后续的版本中补上这个功能，这让我们对这个家族多了几分留意。随着时间的推移，Abcbot也在持续更新，如我们所料，它在后继的样本中加入了DGA特性。如今Abcbot除了拥有蠕虫式传僠的能力，还有自更新，Webserver，DDoS等功

Pink, a botnet that competed with the vendor to control the massive infected devices

Most of the following article was completed around early 2020, at that time the vendor was trying different ways to recover the massive amount of infected devices, we shared our findings with the vendor, as well as to CNCERT, and decided to not publish the blog while the vendor'

一个藏在我们身边的巨型僵尸网络 Pink

本文完成于2020年春节前后，为维护广大最终消费者的利益，一直处于保密期无法发表。近日 CNCERT 公开披露了相关事件，令本文有了公开契机。在保密期的这段时间里，Pink 也出现一些新的小变动，笔者筛选了其中一部分放到“新动向”章节，供其他同仁共同追踪研究。概述 2019年11月21日，安全社区的信任伙伴给我们提供了一个全新的僵尸网络样本，相关样本中包含大量以 pink 为首的函数名，所以我们称之为 PinkBot。 Pinkbot 是我们六年以来观测到最大的僵尸网络，其攻击目标主要是 mips 光猫设备，在360Netlab的独立测量中，总感染量超过160万，其中 96% 位于中国。 PinkBot 具有很强的技术能力： 1. PinkBot 架构设计具备很好的健壮性，它能够通过多种方式（通过第三方服务分发配置信息/通过 P2P 方式分发配置信息/通过 CNC 分发配置信息）自发寻址控制端，并对控制端通信有完备的校验，确保僵尸节点不会因某一个环节的阻杀而丢失或被接管；甚至对光猫固件做了多处改动后，还能确保光猫能够正常使用；