Web安全研究（八）

Good Bot, Bad Bot: Characterizing Automated Browsing Activity

S&P 2021

石溪大学

攻击者依赖于恶意的bot发现易受攻击的网站，并入侵服务器泄漏用户数据。因此了解恶意的bot相当重要。

作者设计了Aristaeus，用于部署大量蜜罐网站的系统，专门吸引和记录僵尸流量而存在的网站。

每月都收到超过37k的请求数据，且超过一般都是请求试图暴力破解凭证，进行指纹识别，以及利用大量不同的漏洞。比较tls与ua头发现86.2%的bot都声称自己是chrome和firefox，但其实基于简单的http和命令行工具。

文章结构

intro
background
system design
1. honeysite design
2. honrysite implementation
3. deployment and log collection/aggregation
bot traffic analysis
javascript fingerprints of bots
bot behavior
1. bot intentions
2. duration and frequency of bot visits
3. unexpected changes in bot identify
tls fingerpriting
case study
discussion
related work
conclusion

intro

为了应对网页的快速扩张，无论是合法运营者还是恶意行为者，都依赖网络机器人（也称为爬虫和蜘蛛）来快速自主地发现在线内容。合法服务，如搜索引擎，使用爬虫爬取网站以驱动它们的产品。恶意行为者也利用爬虫进行撞库攻击，找出不慎公开的敏感文件，以及探测网页应用的已知漏洞[1][2]。根据近期的行业报告[3]，机器人产生的流量占所有网站相关流量的37.2%，其中恶意机器人占总体机器人流量的64.7%。鉴于恶意机器人所进行的滥用行为，识别并阻止它们对于网站及其用户的安全至关重要。大多数现有的机器人检测技术依赖于通过监督和无监督的机器学习方法，根据客户端如何与网站交互（例如，请求资源的速度和类型）[4][5]，以及通过浏览器指纹识别技术[7][8]，来区分机器人和普通用户。

在上述所有方法中，研究者需要获取已知机器人和已知用户的数据集来训练系统，以区分它们。这个需求造成了一种循环依赖，即需要一个由精准机器人检测得出的数据集来用于准确的机器人检测。而恶意机器人的对抗性本质，在本文中，我们提出了一种技术，通过引入"蜜罐网站"的概念，避开区分用户和机器人的难题。我们的蜜罐网站像传统的高互动性蜜罐一样，是完全功能的网站，托管着置于公共IP空间的完整网络应用（类似Canali和Balzarotti用来研究web应用攻击的利用和后利用阶段的蜜罐网站[12]）。通过注册从未存在过的域名（从而避免由于遗留信任产生的流量[13]），并且从不向人类用户宣传这些域名，我们确保在这些蜜罐网站上接收到的任何流量都属于良性和恶意的机器人，以及可能是它们的操作者。为了扩大这个想法，我们设计并构建了一个名为Aristaeus[1]的系统，它提供灵活的远程部署和管理蜜罐网站，同时通过多种客户端指纹识别方式增强部署的网络应用。

通过Aristaeus，我们在全球部署了100个蜜罐网站，选择了五个开源网络应用（WordPress，Joomla，Drupal，PHPMyAdmin和Webmin），它们都非常流行且有数百个历史漏洞，因此对恶意机器人具有吸引力。在七个月的时间（2020年1月24日至8月24日）里，Aristaeus记录了来自287,017个独特IP地址的2640万次机器人请求，总共生成了超过200GB的来自没有自然用户流量的网站的原始日志。通过分析接收到的流量，我们发现平均每个Aristaeus管理的蜜罐网站每月接收的37,753个请求中，有21,523个（57%）明显是恶意的。此外，我们观察到47,667个机器人向我们部署的网络应用的登录端点发送未经请求的POST请求，且发现了12,183个独特的进行网络应用指纹探测的机器人IP地址。在我们的实验期间，我们见证了五个新高严重性漏洞的企图利用，可见机器人在漏洞公开的同一天就进行了武器化利用。此外，通过分析收集到的指纹并尝试与已知浏览器和自动化工具匹配，我们发现至少86.2%的机器人在伪造身份，即：它们声称的身份与TLS和HTTP头指纹不符。特别是，我们在声称是Chrome或Firefox的30,233个客户端中，我们发现86.2%在说谎，大部分与常见的Go和Python HTTP库以及可脚本化的命令行工具（如wget和curl）的指纹匹配。我们的主要贡献包括：

• 我们设计并实现了Aristaeus，一个部署和管理蜜罐网站的系统。通过使用Aristaeus，我们在全球范围内部署了100个蜜罐网站，获得了有关良性与恶意机器人种群和行为的独特见解。

• 我们从漏洞数据库和网络应用指纹识别工具中提取URL，并与Aristaeus记录的请求相对应，发现超过25,502个机器人参与了指纹识别或严重服务器端漏洞的利用。

• 我们整理了常见浏览器和自动化工具的TLS签名，并用它们揭露访问我们基础设施的机器人的真正身份。我们发现绝大多数机器人使用常见的HTTP库但声称是流行浏览器。我们的结果证明了TLS指纹识别在识别和区分用户与恶意机器人方面的有效性。

鉴于在实际网站上区分用户和机器人困难重重，我们将分享我们精心整理的纯机器人数据集以帮助其他研究员改进现有和未来机器人检测工具的质量。

background

未经请求的请求已成为网络托管体验中的常态。这些请求通常源自拥有各种良性和恶意目的的机器人。良性方面，搜索引擎的机器人抓取网站以为其服务编入索引，而大规模的研究项目则使用机器人收集一般统计信息。与此同时，恶意行为者使用机器人大规模地识别和利用漏洞。此外，高知名度的网站会成为有针对性的机器人攻击的目标，目标是抓取内容和瞄准用户账户。

机器人和自动化浏览：

一个自动化浏览环境可以是简单的wget或curl请求，也可以是通过Selenium等库程序控制的完整浏览器。底层的机器人平台及其配置定义了机器人在加载和执行特定资源（如JavaScript代码、图像和层叠样式表CSS）方面的能力。如本文所示，这些平台的能力和行为可以用于识别它们。

浏览器指纹识别：

恶意机器人可以伪装它们的身份。先前的工作已经提出基于浏览器指纹识别和行为分析的检测方案，以提取静态签名和可用于机器学习模型的特征。浏览器指纹识别是检测机器人的重要组成部分。以前的研究专注于使浏览环境独特的许多方面[15][16][17]。相同的技巧也被广告网络用于无状态用户追踪，重点关注对不同用户可能产生不同结果的特征，如支持的JavaScript API、插件列表、浏览器扩展、可用的字体和canvas渲染[15][18][19]。

TLS指纹识别：

同样，浏览器和操作系统也可以通过网络层利用TLS（传输层安全）差异进行指纹识别[20]。Durumeric等人通过比较连接声明的用户代理和使用的TLS握手差异，来识别HTTPS截取[21]。在这篇论文中，我们展示如何使用TLS签名（包括TLS版本、可用密码套件列表、签名算法、椭圆曲线和压缩方法）来识别恶意机器人的真正本质，不管它们自称的身份是什么。

行为分析：

除了浏览器和TLS指纹识别，机器人在目标网站上的行为也可以显示自动化浏览的迹象。为此，先前的机器人检测方案使用了诸如请求速率、针对关键端点（如登录端点）的请求，甚至鼠标移动和键盘输入等特征[4][5][22]。

浏览会话：

为了研究机器人的行为，我们需要一种机制来将同一个机器人的后续请求聚合在一起。虽然源IP地址可以用于此，但在大规模研究中，随着时间的推移IP地址的变动可能导致误报，即地址易手并被不同的实体使用。为了解决这个问题，我们使用了服务器端Web应用和Google Analytics定义的"浏览会话"概念[23]。对于每个IP地址，我们接收到请求时开始会话，并在30分钟的无活动后结束。这允许将活动浏览行为自然地划分为组。在同一会话中聚合同一机器人的请求，让我们可以分析其活动，如机器人声称身份的改变，以及作为凭证暴力破解攻击部分的多次请求。

system

为了在全球范围内收集机器人信息，我们设计了Aristaeus，一个提供灵活蜜罐网站部署和指纹收集的系统。Aristaeus由三个部分组成：蜜罐网站、日志聚合和分析模块。我们的系统可以根据用户提供的模板（一组现有或定制的Web应用和脚本，使用公共云上的虚拟机）启动任意数量的蜜罐网站。Aristaeus用多个指纹识别模块增强了这些模板，这些模块为每个访问的客户端收集各种信息。从蜜罐网站收集的信息由中央服务器定期拉取，该服务器负责关联和聚合所有活动蜜罐网站收集的数据。图1展示了我们系统的整体架构。

蜜罐网站是真实部署的网络应用，增强了不同的指纹识别技术并增加了日志记录。与传统的蜜罐一样，我们的蜜罐网站从未向真实用户宣传，也没有被其他网站链接，或提交给搜索引擎进行索引。如果蜜罐网站包含公共访问的用户生成内容（如显示博客文章的典型内容管理系统），Aristaeus将创建随机生成的文本并填充蜜罐网站的主页。

最后，为了确保蜜罐网站接收到的流量并非因为其域名之前存在（因此可能与之相关的遗留信任和遗留流量问题[13]），我们为Aristaeus注册的所有域名以前从未注册过。为了确保这一点，我们使用了商业的被动DNS提供商，在注册域名之前检查历史解析记录的缺失。因此，我们在蜜罐网站上观察到的任何流量都可以安全地归类为属于机器人，或者属于决定调查其机器人发现内容的机器人操作者。

为了能够在后期将来自不同IP地址的请求关联为属于变更IP地址的同一机器人，或者属于相同自动化浏览软件的不同部署，Aristaeus在蜜罐网站上增强了三种类型的指纹识别：浏览器指纹识别、行为指纹识别和TLS指纹识别。图2显示了这些不同类型的指纹识别如何与蜜罐网站对接。以下段落中，我们将提供每个指纹识别模块的详细信息和原理：

浏览器指纹识别
为了识别出请求我们蜜罐网站内容的每一个浏览器（或自动化代理），我们使用了以下方法：

JavaScript API 支持。

不同的机器人具有不同的功能。为了识别它们JavaScript引擎支持的基础特性，我们动态地使用document.write()和var imgAPIs引入一张图片，并检查连接的代理是否请求该资源。我们还通过在页面中包含的jQuery库发送POST请求来测试AJAX支持。最后，我们通过内联JavaScript和外部JavaScript文件的组合来量化是否支持内联和外部加载的JavaScript文件。

通过JavaScript进行浏览器指纹识别。

我们利用Fingerprintjs2 (FPJS2)库[24]来分析机器人的可指纹表面积。FPJS2从网络浏览器收集35个特征，包括屏幕分辨率、时区、canvas创建、webGL以及其他可以通过JavaScript查询的特性。为此，FPJS2依赖于一个JavaScript API列表。尽管在典型的浏览环境中这些API是现成的，但我们无法保证所有连接的客户端都完全支持JavaScript。例如，微信内置浏览器无法执行FPJS2的OfflineAudioContext，导致整个指纹识别脚本崩溃。为了解决这个问题，我们将FPJS2模块化，使得库能在尽可能多的失败情况下存活，并仍然为可用的API收集值。当然，如果机器人根本不支持JavaScript，我们将无法通过这种方法从它那里收集任何指纹。

支持安全策略。

现代浏览器支持一系列的安全机制，通常通过HTTP响应头来控制，以保护用户和web应用程序免受攻击。Aristaeus利用这些机制作为新颖的指纹识别技术，期望不同的机器人在支持安全机制的程度上会有所不同。具体来说，我们通过请求被这些策略明确禁止的资源来测试简单的内容安全策略和X-Frame-Options的执行[25][26]。据我们所知，这是首次这些机制被用于除保护web应用之外的目的。

行为指纹识别
遵守robots.txt。
良性机器人应遵循robots.txt中的指示（即，不访问明确标记为Disallow的路径）。相反，已知恶意机器人不仅会忽略这些Disallow指令，还会利用robots.txt来找出他们原本可能会错过的目标端点[27]。为了测试这一点，Aristaeus会在每个蜜罐网站的robots.txt文件中自动添加指向"password.txt"的Disallow条目，该文件的确切路径编码请求该文件的代理的IP地址。这使Aristaeus不仅能发现对robots.txt的滥用，还能识别出看似无关的两个请求背后同一个操作者的常见行为。即，如果具有IP地址5.6.7.8的机器人请求了一个为IP地址1.2.3.4的其他机器人生成的robots.txt条目，我们事后可以推断出这两个请求都是同一位操作者的。

定制错误页面。

为了确保Aristaeus有机会对那些针对特定网络应用（因此会请求生成HTTP 404错误消息的资源）的机器人进行指纹识别，我们使用包含本节中描述的所有指纹识别技术的自定义404错误页面。

缓存和资源共享。

常规浏览器使用缓存来减少页面加载时间，并更有效地加载跨网页重复使用的资源。缓存的使用可能使我们的日志分析复杂化，因为我们要依赖HTTP请求来识别哪些特性是机器人支持的。为了消除这些影响，我们使用"no-cache"头来请求代理不缓存资源，并在页面上每个资源的URL末尾附加一个动态的，破坏缓存的令牌。

缓存破坏者通过使用AES加密客户端IP地址和随机非密文，然后对输出进行Base64编码来生成。这使得相同的资源的每个URL都是唯一的。例如，如果一个机器人请求资源a.jpg，它会发送格式为/a.jpg?r=[encrypted IP+nonce]的请求。

在我们的分析中，解密缓存破坏者并获取请求这些资源的原始IP地址。利用这些信息，我们可以明确识别出跨多个IP地址的资源共享。这发生在从一个IP地址请求资源，但缓存破坏者指向了不同IP地址时。

TLS指纹识别
我们使用fingerprintTLS [20]（FPTLS）库来收集通过HTTPS协议连接到蜜罐网站的每个客户端的底层TLS库的TLS握手指纹。从每个连接中，FPTLS收集TLS版本、密码套件、椭圆曲线和压缩长度等字段。收集TLS指纹的原因是，不同的TLS库具有不同的特性，可以让我们后期将请求回溯到相同的软件或同一台机器。这种类型的指纹识别是被动进行的（即，连接的代理已经在其TLS握手期间发送了FPTLS记录的所有详细信息），几乎可以由请求我们蜜罐网站内容的所有客户端收集。这一点尤为重要，因为对于JavaScript等其他类型的指纹识别，如果机器人不支持JavaScript，Aristaeus就无法从这种不支持的机制中收集指纹。

虽然Aristaeus对Web应用是不挑剔的，但对于这篇论文，我们部署了五种流行类型的Web应用，包括三个内容管理系统（CMS）和两个网站管理工具。在CMS方面，我们部署了WordPress、Joomla和Drupal的实例，它们是网络上最流行的三大CMS [28]。仅WordPress估计就支撑了网络上超过30%的网站 [29]。在网站管理工具方面，我们选择了Webmin和PHPMyAdmin。这两个工具都允许管理员与数据库互动并在部署的服务器上执行命令。

除了其受欢迎（这使它们成为吸引人的目标）之外，这些工具已经存在很多年，并且遭受了大量严重的安全漏洞，从Webmin的49个漏洞到Drupal的333个漏洞。请注意，对于CMS，核心代码中的漏洞不包括第三方插件所面临的数千个漏洞。此外，这五个网络应用都允许用户和管理员登录，使它们成为通用的凭证填充机器人攻击的目标。

部署和日志收集/聚合

对于本文描述的实验集，我们总共注册了100个域名。如III-A章节所述，我们确保注册的域名从未存在过（即，一旦注册并到期），以避免遗留流量的污染。对于每个域名，Aristaeus会启动一个蜜罐网站，并在服务器上部署我们的一个Web应用模板。我们使用Let's Encrypt为每个域名获取有效的TLS证书，并使用AWS的虚拟机在北美、欧洲和亚洲三个不同大陆托管我们的蜜罐网站。总的来说，我们在北美有42个蜜罐网站，在欧洲有39个，在亚洲有19个。

一个中央服务器负责定期收集和聚合所有100个蜜罐网站的日志。如III-A章节所述，这些日志包括Web服务器访问日志、TLS指纹、浏览器指纹、行为指纹，以及记录安全机制违规的日志。我们通过时间戳和IP地址关联不同日志中的条目，并将结果合并的条目存储在Elasticsearch集群中，以便后续分析。

bot traffic analysis

在这部分和接下来的部分中，我们将报告从在3个不同大陆（北美、欧洲和亚太地区）部署的100个蜜罐网站为期7个月（2020年1月24日至8月24日）的数据收集中得出的发现。总体而言，我们的蜜罐网站捕获了来自287,017个独特IP地址的264,276,667个请求，总计207GB的数据。我们的数据集的详细细分可以在论文的附录（表VI）中找到。

在捕获的2640万个请求中，平均每台蜜罐网站每天收到1235个请求，来自14个IP地址。由于这些域名之前从未注册过，也没有被其他网站链接，我们认为进入的流量仅来自机器人，可能是机器人运营商。

每日机器人流量。

图3（上部）显示了每天访问我们蜜罐网站的唯一IP地址数量。我们观察到这个数量起初有所下降，但在数据收集的后期阶段平均稳定在大约1,000个IP地址。我们的数据表明，即使在实验开始7个月后，我们的蜜罐网站仍能观察到来自新IP地址的流量。

图3（下部）显示了随时间推移接收的请求数量。从4月18日开始，我们观察到入站请求量的增加，但与之相应的唯一IP地址数量没有相应增加。仔细检查后，我们将流量增加归因于针对我们WordPress蜜罐网站进行暴力攻击的机器人活动（在第六部分A2节中详细讨论）。

地理分布的机器人。

虽然我们没有观察到在不同地区托管的蜜罐网站之间有显著变化，但确实注意到机器人的请求并非均匀分布于各国。总体而言，我们从美国接收到的机器人请求最多，其次是中国和巴西。图4显示了联系我们的蜜罐网站的IP地址数量最多的前10个国家。

IP黑名单的有限覆盖。

我们从9个流行IP黑名单中收集关于恶意IP地址的信息，这些黑名单主要关注恶意客户端和网络威胁，包括AlienVault、BadIPs、Blocklist.de和BotScout。在对我们管理的Aristaeus基础设施表现出恶意行为的76,396个IP中，只有13%出现在这些黑名单中。

为了更好地了解这些恶意机器人的本质，以及它们如何与Aristaeus记录的其他机器人相关联，我们使用IP2Location lite IP-ASN数据库 [30] 来获取我们数据集中所有IP地址的地理位置类型。图5显示了这种分布。与我们预期大多数机器人位于数据中心相反，实际上大多数IP地址（64.37%）位于住宅IP空间。

这个发现表明，大多数机器人的请求来自被感染的住宅设备，或使用住宅设备作为代理以逃避基于IP的黑名单 [31]。这也在我们获取的第三方IP黑名单中IP地址的分布中得到了确认。如图5所示，这些黑名单标记为恶意的主机主体也位于住宅网络中。

最后，为了了解黑名单需要多久更新一次，我们对我们数据集中机器人的生命周期进行了特征描述。我们定义"生命周期"为机器人首次访问蜜罐网站到通过相同IP地址的最后一次访问之间的时间。我们观察到69.8%的机器人IP地址的生命周期少于一天。这些机器人活跃一小段时间后离开，不再回来。相比之下，0.8%的机器人生命周期超过200天，接近我们研究的持续时间。这表明机器人经常切换到新的IP地址，这使得基于静态IP的黑名单对于应对IP变动行为的效果较差。

我们对Aristaeus发现的恶意机器人和流行黑名单的比较，显示了现有黑名单的覆盖率不足，同时也展现了Aristaeus的强大，它可以识别出数万个当前逃避其他工具的恶意IP地址。我们在第六部分A节中提供了更多关于将机器人标记为恶意的细节。

蜜罐网站的发现。

机器人可以使用DNS区域文件、证书透明性日志和被动网络监控来发现域名。我们观察到，蜜罐网站上线后仅仅几分钟，Aristaeus就开始观察到与明显尝试利用相关的资源请求（如login.php、/phpinfo.php、/dbpma.php和/shell.php）。在第六部分A节中，我们将提供我们观察到Aristaeus日志中出现的利用尝试类型的更多细节。

为了识别机器人如何找到我们的蜜罐网站，我们检查了机器人HTTP请求中的"主机"头，查看它们是通过域名还是蜜罐网站的IP地址访问我们。在总共有287,017个属于机器人的IP地址中，我们发现126,361个（44%）是通过我们蜜罐的IP地址访问，74,728个（26%）通过域名访问。其余85,928个（30%）IP地址没有使用"主机"头。此外，在HTTPS流量中，由于Aristaeus不使用基于IP的HTTPS证书，我们观察到所有36,266个机器人IP地址都是通过我们的域名访问。

考虑到大量请求抵达我们的蜜罐网站，人们可能会怀疑我们是否因为那些曾经配置为解析到我们AWS分配的IP地址，但当管理员废弃旧的虚拟机时忘记更改的域而接收到了流量。这种"悬空域名"是安全漏洞的来源，最近已被Liu等人[32]进行调查，并Borgolte等人[33]。使用被动DNS，我们发现在我们的实验期间，有两个配置错误的第三方域名指向了我们的基础设施。然而，由于这些配置错误的域名而连接到我们蜜罐网站的客户端只占观察到的IP地址总数的0.14%。

同样，为了量化我们从真实用户（而不是机器人）那里接收请求的可能性，这些用户的浏览器在Aristaeus控制的IP地址以前属于其他方时，通过IP地址（而不是通过域名）链接到内容，我们进行了以下实验。我们抓取了Alexa排名前10K的每个网站的30个页面，搜索通过IP地址链接的内容（如图片、JavaScript文件、链接和CSS）。在发现的3,127,334个链接中，只有31个（0.0009%）使用了硬编码的IP地址。

结合这些发现，我们可以清楚地看到，Aristaeus记录的绝大多数访问与真实用户无关，而与我们研究的主题（良性或恶意的机器人）有关。

最受关注的URI。

并非所有蜜罐网站端点接收相同数量的请求。在这里，我们列出了从机器人那里收到最多请求的端点，以及它们所属的Web应用。

在最被请求的端点中，我们注意到了跨多个Web应用常见的端点，如robots.txt，以及仅属于我们一个Web应用的资源，如wp-login.php，它是WordPress的登录页面。图6显示了每个URI针对不同Web应用的请求份额；颜色较深的单元格表示向那种类型的Web应用提交的请求比例更高。为了提供基准比较，图6也显示了文档根目录（/）的访问分布。

总的来说，我们的蜜罐网站的登录端点最受机器人的关注。这些请求是为了暴力破解登录凭证，目标是wp-login.php或/user/login等端点。还有一些对robots.txt文件的通用请求。有趣的是，robots.txt文件主要在WordPress和Joomla蜜罐网站上被查询，而在Drupal、PHPMyAdmin和Webmin蜜罐网站上的查询量显著较低。

某些资源只在我们的一个Web平台上被请求。例如，xmlrpc.php和wp-login.php只在WordPress蜜罐网站上被请求。同样，请求/changelog.txt URI只发生在Drupal蜜罐网站上，用于Web应用指纹识别（即确定确切的版本和它是否对已知漏洞易感）。接下来是session login.cgi文件，它承载Webmin的登录页面，我们只在Webmin实例中观察到对这个资源的请求。最后，文档根目录和/latest/dynamic/instance-identity/document请求在所有蜜罐网站中均等出现。latest/dynamic/instance-identity/document端点在一些AWS托管的服务器上存在，可能被用于Server-Side Request Forgery（SSRF）攻击（我们在第六部分A2节中讨论此攻击）。

总而言之，特定应用的攻击模式表明，机器人会指纹识别这些应用并识别其是否存在机器人会指纹识别特定的易受攻击的Web应用，而不是盲目地发动攻击载荷。我们在第六部分A2节中详细讨论了机器人的指纹识别尝试。最后，附录中的表VII列出了从每个Web应用类型的角度最受攻击的URL。

js fingerprint

在这部分，我们报告有关通过浏览器指纹识别检测机器人的发现。

JavaScript支持。

我们设计了几项测试来评估机器人的JavaScript支持能力。从这些测试中，我们发现只有11,205个（累计1,760,124个会话中的0.63%）机器人会话支持添加动态DOM元素和进行AJAX请求等JavaScript功能。

JavaScript基础的浏览器指纹识别。

当涉及到检测访问我们蜜罐网站的机器人时，JavaScript基础的浏览器指纹识别的效果严重受限于大多数机器人对JavaScript的支持不足。在总计1,760,124个会话中，只有0.59%返回了基于JavaScript的浏览器指纹。

总体而言，鉴于访问我们网站的大多数机器人不支持JavaScript，这种类型的浏览器指纹识别对于机器人识别的实用度较低。同样，这也表明，如果网站要求用户必须支持JavaScript才能访问，通过Aristaeus识别出的大部分机器人将被排除在外。

bot behavior

在这部分，我们研究了机器人在访问我们蜜罐网站时的不同行为方面。

尊重robots.txt。

根据我们动态生成的robots.txt，我们没有观察到针对标记为Disallow路径的违规行为。这是一个意外的发现，可能是由于使用虚假的Disallow条目识别侦察尝试的流行[34]-[36]。然而，这并不意味着所有机器人会遵循robots.txt，因为只有2.2%的总体会话包含对这个文件的请求。

强制执行内容安全策略（CSP）。

在我们的蜜罐网站上，不到1%的总IP地址报告了CSP违规。同样，有不到1%的机器人违反了违反CSP规则，加载我们明确禁止的资源。大部分CSP违规来自良性的搜索引擎机器人，它们能够加载嵌入的资源（如第三方图片和JavaScript文件），但不支持CSP。大多数机器人不加载CSP禁止的资源，并不是因为它们遵守CSP，而是因为它们通常不加载这类资源。

共享/分布式抓取。

由于Aristaeus在每个URL缓存破坏者中编码客户端的IP地址，预期客户会发送匹配其URL的请求。然而，在1,253,590个带有有效缓存破坏器的请求中，我们发现536,258个（42.8%）"重用"了给予不同IP地址客户的缓存破坏器。

考虑到大量不匹配的请求，我们可以得出结论，大多数是因为分布式爬虫，它们在一个IP地址集合中识别出感兴趣的URL，然后在不同的"工作者"池中分发抓取任务。这种行为在Googlebots（所有缓存破坏器重用的19.6%）和英国Majestic运营的"MJ12Bot"（32.1%的缓存破坏器重用）中广泛观察到。有趣的是，恶意机器人不参与这种行为，即任何我们收到的缓存破坏器都与其IP地址匹配。

A. 机器人意图

根据在我们蜜罐网站上的活动，我们将机器人会话分为三个类别："良性的"、"恶意的"和"其他/灰色类"。良性的机器人定义为访问我们的蜜罐网站并像正常浏览器一样请求有效资源，没有明显的攻击意图。例如，良性的机器人不会发送未经请求的POST请求，也不会尝试利用漏洞。相反，恶意的机器人是指向认证端点发送未经请求的POST请求，或发送试图利用漏洞的无效请求的机器人。除了这两类之外，有些机器人由于与我们的蜜罐网站的交互有限，无法明确标注为良性的还是恶意的。我们将这些机器人标记为"其他/灰色类"。

benign bot

基于它们的活动，我们将搜索引擎机器人和学术/行业扫描器归类为良性的机器人。我们总共记录了347,386个良性请求，占Aristaeus收到的总请求的1.3%。

搜索引擎机器人。

搜索引擎机器人占据了良性机器人类别中大部分的请求，占到总数的84.4%。通常通过它们的User-Agent来识别搜索引擎机器人，它们会在那里明确说明自己。然而，机器人有可能伪装其User-Agent，以搜索引擎机器人的身份隐藏恶意行为。搜索引擎通常提供反向DNS查找等机制，让网站管理员验证每个声称属于特定搜索引擎的机器人的来源[37]-[40]。

我们共收到317,820个来自搜索引擎机器人的请求，其中Google机器人贡献了80.2%的请求。例如，我们观察到了与Google相关的四种不同的User-Agent（"Googlebot/2.1"，"Googlebot-Image/1.0"，"AppEngine-Google"和"Google Page Speed Insights"），这些与Google的文档相匹配[41]。

在声称来源于搜索引擎机器人的317,820个请求中，我们确认有293,337个（92.3%）确实是真实的搜索引擎机器人请求。表I列出了我们蜜罐网站接收到的已识别搜索引擎机器人请求的比例。

学术和行业扫描器。

除了匿名扫描器外，我们还识别出了30,402个（0.12%）来自收集网站统计信息（如BuiltWith [28] 和NetCraft [42]）、保存网站历史副本（如Internet Archive [43]）以及从网站收集SEO相关数据（如Dataprovider.com）的公司扫描器的请求。此外，我们观察到了德国一所大学的安全组的爬虫在我们的蜜罐网站上活跃。我们通过反向DNS查找验证了所有这些机器人，将它们的源IP地址归因于对应的公司和机构。

malicious bot

我们根据端点和访问方法来定义恶意请求。如同在第三节A部分所述，我们确保为Aristaeus注册的域名以前从未存在。因此，由于良性的机器人没有我们网站历史版本的记忆，没有理由让一个良性的机器人请求一个不存在的资源。因此，我们可以将所有无效请求标记为侦察请求（即指纹识别和利用尝试），最终将它们归类为恶意。同样，我们也将对登录页面等其他端点进行未经请求的POST请求的机器人标记为恶意。总的来说，我们标记了15,064,878个请求（总请求的57%）为恶意。

凭证暴力破解尝试。

来自47,667个IP地址的13,445,474（50.8%）个请求目标是我们网站的登录页面。通过分析我们接收的所有未经请求的POST请求并检查相应的URI，我们发现不同的Web应用吸引了不同类型的攻击。例如，有123,700,63个POST请求指向WordPress，其中90.3%是对wp-login.php和xmlrpc.php的暴力破解尝试。然而，对于Joomla，有343,263个未经请求的POST请求，只有51.6%瞄准Joomla的登录页面。剩余的请求与Joomla不特定，并针对各种易受攻击的软件（例如，对/cgi-bin/mainfunction.cgi的请求会攻击易受到远程代码执行攻击的DrayTek设备[44]）。

有趣的是，系统管理工具吸引了不同模式的攻击。虽然76.2%的POST请求朝着针对phpMyAdmin的目标登录端点，几乎所有的POST请求（99.95%）针对Webmin的特定登录接口。这表明大多数针对Webmin的机器人专注于暴力破解凭证，而不是针对其他公共可访问页面。

通过分析对我们的蜜罐网站尝试的用户名和密码组合，我们发现攻击者总是尝试用"admin"的用户名，使用常见密码 [45] 或者我们蜜罐网站域名的变体（比如在为example.com提供服务的蜜罐上尝试"www.example.com"密码）。根据尝试次数，我们发现99.6%的机器人（通过IP地址识别）在更改目标前对每个域名尝试不超过10次。只有0.3%的机器人对每个域名发起了100次以上的暴力破解尝试。最活跃的机器人向我们的WordPress蜜罐网站发出了64,211个与登录相关的请求。

侦察尝试。

为了识别侦察相关的请求，我们采用两步映射方法。首先，我们根据与应用指纹识别、利用尝试、搜索公开访问的后门和扫描未保护的备份文件相关的流行库和数据库生成签名。稍后，我们将在本节中提供每个特定库和数据集的细节。其次，我们手动识别收到超过1,000个请求的端点的请求意图，尽可能将每个请求映射到上述攻击类别。这个过滤步骤是必要的，因为我们不可能生成包含所有机器人请求签名的全面数据库。这个优先标签方法的力量在于，通过这个过程，我们发现了利用最近的CVE-2020-0618漏洞攻击MSSQL报表服务器的攻击，这在我们最初的签名数据库中并未包含。

总的来说，我们总共收集了16,044个签名，其中179个签名匹配了我们数据集中的请求。这些签名覆盖了25,502个IP地址（总IP地址的9%），产生了659,672个请求。

应用指纹识别：

在这项研究中，指纹识别尝试指的是旨在揭示特定Web应用程序版本及其插件存在的请求。为了量化这些请求，我们使用了BlindElephant [46]和WhatWeb [47]这两个开源指纹识别工具的签名。这些工具拥有大量流行Web应用及其插件的指纹数据库。通过请求特定的文件并将其内容与数据库中的签名进行匹配，这些工具可以识别目标Web应用的类型和特定版本。我们从指纹数据库中提取文件路径，并将这些签名与我们的Web服务器日志关联，以识别来自恶意机器人的指纹识别尝试。为了确保不会将常规抓取误标为指纹识别，我们不考虑对如index.php和robots.txt这样的通用文件的请求，即使在Web应用指纹识别的上下文中这些文件是有价值的。总的来说，我们的数据库包括13,887个基于URL的签名，用于识别指纹识别尝试。表II列出了我们指纹识别签名数据库中接到最多请求的前5个路径。总共有223,913个请求被归类为指纹识别尝试，来自12,183个独特的机器人IP地址。

在我们的签名数据库中，/CHANGELOG.txt收到了最多的请求，因为这个文件可以用来识别Drupal、Joomla、Moodle（在线学习平台）和SPIP（协作出版系统）等的版本。其次，我们注意到针对ThinkPHP部署的远程代码执行（RCE）漏洞的请求，这些漏洞被多个botnet所针对[48]。Apache Solr的指纹识别与2019年11月报告的易受RCE攻击的版本有关[49]。最后，在指纹识别请求的前五类中，我们还看到大量针对特定脆弱的WordPress插件以及Tomcat Manager默认部署的请求。其余与指纹识别相关的请求遵循相同的模式，针对的是配置不当或已知存在漏洞的特定应用程序端点。

利用尝试：

我们定义利用尝试为目标是直接触发已知漏洞的URI的请求。我们使用exploit-db.com上的利用来生成利用尝试的签名。不幸的是，基于公共漏洞描述自动生成签名是具有挑战性的，因为漏洞报告的格式多样。因此，我们采用一种人类辅助自动化工具，提取签名候选URL供人类分析师验证。同时，我们假设机器人最可能关注易于实施的服务器端漏洞（如SQL注入和RCEs），而不是包括客户端攻击，如XSS和CSRF。生成的签名数据库包括针对我们数据集中5种Web应用的593个签名，对应2014年至2020年的漏洞。我们的数据库包括针对WordPress的174个漏洞，针对Joomla的297个漏洞，针对Drupal的40个漏洞，针对phpMyAdmin的52个漏洞，针对Webmin的19个漏洞，以及通过查看蜜罐网站上最常请求的路径提取出的14个漏洞。

总的来说，我们匹配了238,837个源自10,358个机器人IP地址的利用尝试请求。表III列出了这些尝试中使用的前5个端点。当有可能时，我们在表中报告CVE编号，如果没有CVE编号，我们报告这些漏洞的EDB-ID（Exploit-db ID）。

PHPUnit中的RCE漏洞收到了最多的利用尝试，其次是phpMyAdmin的一个设置PHP代码注入漏洞，以及暴露的XDebug服务器（PHP远程调试工具）上的RCE。接下来是一个ThinkCMF（基于thinkPHP的内容管理系统应用）中的RCE漏洞也受到恶意机器人的攻击。表III中的最后一项涉及一个Draytech的漏洞，其重要性在于它的漏洞在我们的研究期间被发布，让我们得以观察其被武器化的速度（我们在第八节中会有更多讨论）。有趣的是，发出指纹识别或利用尝试请求的IP地址中有3,221（14%）出现在这两个类别中，这表明一些机器人覆盖了广泛的漏洞，而不是专注于单一的利用。

除了利用尝试，我们还搜索了在一个或多个请求参数中包含标志性的Shell命令（如"rm -rf /tmp"和"wget"）的请求。通过这种方式，我们发现了额外的24,379个与Shell相关的请求。尽管大多数注入的Shell命令试图从公共可访问的IP地址/域下载恶意负载，但我们发现2,890个请求包含私有IP地址的URL，例如"192.168.1.1:8088"，这当然在我们的Web服务器上无法触及。这些请求可能属于一个出错的机器人，在成功渗透主机后提取了错误的网络接口IP地址，或者可能表明是旨在攻击本地网络路由器但最终出现在公共网络上的僵尸网络。

• 搜索开放访问的后门：我们生成了一份包含485个知名PHP、ASP、Perl、Java和bash后门的清单。我们使用与Starov等人[50]相同的列表来提取已知Web后门的签名，并通过两个托管Web壳的存储库[51]、[52]来扩展他们的列表。我们的签名与6,721个机器人IP地址发起的144,082次请求的42个Web后门（如shell.php、cmd.php和up.php）匹配。

• 搜索未保护的敏感文件：另一组机器人通过猜测可能敏感文件的名称（如backup.sql）或利用管理员行为（如保留带.old后缀的已知工作副本的敏感文件）和来自特定编辑器的泄露（如访问Vim留下的临时交换文件）来查询未保护的敏感文件。

与Webshell签名类似，我们使用了在安全扫描器中常用的词表，如SecLists [51]，来构建包含1,016个签名的数据库。这些签名匹配了5,846个唯一机器人IP地址发起的52,840个请求。.env扩展名的文件包含Docker及其他流行开发平台中可能敏感的环境变量，被1,877个独特机器人IP地址请求了29,713次。机器人还请求了一系列可能敏感的文件扩展名，包括.old、.sql、.backup、.zip和.bak，以及PHP ̃和.swp这样的文本编辑器缓存文件。

基于本节介绍的全部签名，我们观察到有929个独特的机器人IP地址参与了所有上述类型的攻击。这表明存在一些机器人，它们装备了大量的攻击手段，并愿意在攻击主机时耗尽这些手段，然后转移到下一个受害者。

B. 机器人访问的持续时间和频率

我们把Aristaeus记录的请求分成了1,760,124个会话。总体而言，44.9%的会话仅包含一个请求。46%的会话包含2到20个请求，而存在2,310个包含超过1,000个请求的会话。大多数机器人在我们的蜜罐网站上停留的时间仅为1到3秒。58.1%访问我们蜜罐网站的机器人在3秒内离开，其中89.5%的机器人在1秒内离开。相反，有10.7%的机器人在我们的蜜罐上花费了超过30分钟的时间。

访问我们蜜罐网站的大量机器人执行的请求太少且太通用，以至于难以将它们分类为良性的或恶意的。具体来说，有11,015,403个请求（占总请求的41.68%）属于这一类别。我们下面提供了这些机器人的更多细节：

一次性扫描器。

50.04%的访问我们蜜罐的IP地址只发送了一个请求，并未显示出明显的恶意行为。这显然是机器人行为，因为现代浏览器在加载主站和第三方资源时会发起数十个后续请求。同样，这些机器人不太可能是索引网站，因为这也需要在主页链接的页面上发出后续请求。我们推测这些一次性扫描机器人要么是在为后期处理（由更持久的机器人）填充数据库，要么是在搜索我们配置中不存在的特定内容。

互联网范围扫描器。

我们归因于四个不同的互联网范围扫描器的114,489个请求，包括Masscan [53]（21.4%）和Zgrab [54]（73.1%）。此外，我们的蜜罐还记录了"Stretchoid"（34.3%）和"NetSystemsResearch"（3.69%）的机器人，它们声称识别组织的在线资产和公共系统的可用性。由于这些工具既可以用于良性目的也可以用于恶意目的，这些请求的确切意图仍然不清楚。

C. 机器人身份的意外变化

在这一节中，我们关注在请求之间改变其身份的机器人。我们查找某些HTTP头部的更改，如用户代理，以及使用自动化工具改变的迹象，如HTTP头部的重新排序。

同一IP地址的多个用户代理。

至少有14.28%访问我们蜜罐网站的IP地址发送了包含两种或更多用户代理（UA）字符串的请求。一个机器人可能由于良性的原因展示两个或多个UA字符串，例如，NAT和代理后的机器人，或更新了浏览器/爬虫工具版本的机器人。同时，我们也观察到了明显的伪装行为，比如，机器人每次请求都更改其UA。我们总结了UA变化的类型如下：

更改操作系统：

如以下示例所示，仅在两个请求之间改变了用户代理的操作系统部分。

• "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"

• "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0"

我们识别出了5,479个IP地址在请求中声称使用了超过一种操作系统。一个可能的解释是，这些机器人在寻找服务器端的伪装，即我们的蜜罐网站对Windows和Linux用户提供不同的内容。
更改浏览器版本：

我们使用Levenshtein距离来测量某个IP地址的用户代理字符串的相似度，记录它们的最小和最大相似度。观察到当变化仅限于机器人UA中的浏览器版本时，这些请求的相似度超过90%。共有11,500个IP地址表现出这种版本变化。然而，考虑到我们在第七节A.3中关于机器人模仿常见浏览器的发现，这些版本变化可能是伪装策略的一部分，而不是对浏览器更新的诚实公告。
经常切换用户代理：

我们观察到了4,440（1.54%）个IP地址发送了包含5个以上UA的请求，其中有542个IP地址在其请求中展示了20个以上的UA。在极端情况下，我们发现44个IP地址发送了超过50个独特的UA头。然而，通过查看其他HTTP头部及其TLS指纹，我们可以将它们的请求仅归因于一两个工具。这揭示了频繁轮换UA的策略，预计将服务器端的阻止策略。

HTTP头部的排序：

在分析爬虫工具时，我们观察到特定头部的排序可以关联到特定工具的使用。例如，我们发现wget和curl在不同版本之间都有一致的排序且彼此不同。利用这一观察，我们识别出了23,727个机器人，它们展示了超过一种头部排序，揭示了使用了不止一种工具，而不管其用户代理声明如何。此外，我们发现了28,627个IP地址，它们只有一个HTTP头部排序，但是有多个用户代理，这意味着它们在改变其声称的身份，但并未改变基础工具。

tls fingerprint

Aristaeus向HTTP和HTTPS请求提供内容，以容纳尽可能多的机器人。总的来说，机器人发出了10,156,305个HTTPS请求（占总请求的38.4%）。在所有HTTPS请求中，我们提取了558种独特的TLS指纹。这表明大多数机器人使用相同的底层TLS库，这与他们使用的工具和操作系统相关。因此，我们可以使用这些TLS指纹来识别机器人并确认它们声称的身份。

A. Web机器人的TLS指纹

NAT/代理后的机器人:
预期一些机器人在连接网站之前会使用代理，以逃避速率限制和黑名单，同时也可能将负载分散到多个服务器。因此，来自同一IP地址的请求可能由不同的机器人发出。为了理解是多个机器人隐藏在同一IP地址后面还是单一机器人只是用多个UA发送请求，我们可以比较相关请求的TLS指纹。为进行此分析，我们利用以下观察结果：

• 基本的网络爬虫工具。

像curl和wget这样的工具，在给定的OS和TLS库组合下会产生唯一的指纹。我们利用这些信息来识别UA伪装下的这些工具的使用。

• TLS堆栈中的GREASE支持。

Chrome、Chromium以及基于Chromium的浏览器（如Brave和Opera）支持GREASE，这是一个与TLS握手相关的IETF新标准[55]。GREASE在TLS握手期间发送的值在多个请求中产生多个TLS指纹，差异在于TLS加密套件、扩展和E曲线。因此，上述浏览器的TLS指纹在所有与GREASE相关的握手值的前1-2个字节会有所不同。GREASE在Chrome 55版本中添加[56]，我们通过在多个流行平台（Ubuntu 16.04、Ubuntu 18.04、CentOS 7、Windows 10、Mac OS和Android 8）上测试Chrome进行了验证。相反，Firefox、Edge和Safari在我们分析时未实现GREASE。因此，GREASE值未出现在握手中，这些浏览器的TLS指纹在请求中保持不变。对于这些浏览器，我们在不同操作系统上收集了它们的指纹，并使用这些指纹来揭示机器人请求的真实身份。

在具有TLS指纹的43,985个IP地址中，有1,396个（3.17%）IP地址有两组或更多TLS指纹。对于这个3.17%，我们观察到请求来自不同的工具和/或操作系统，隐藏在同一IP地址后面。如果存在TLS拦截代理，我们将观察到单个TLS指纹（即拦截代理的指纹）。然而，识别TLS代理后的多个客户端仍然是TLS指纹识别的挑战。

工具的TLS指纹：

考虑到10,156,305个请求中只有558种独特的TLS指纹，这意味着大部分请求可以归因于一小部分工具和TLS库。

为了将机器人的TLS指纹匹配到已知的工具，我们手动提取了Go-http-client，wget，curl，Chrome，Firefox，Opera，Edge和IE浏览器的TLS指纹，并将它们包含在我们的签名数据库中。此外，对于我们无法在我们的设置中复现的其他TLS指纹，我们假设一个爬虫不会假装是另一个爬虫。例如，使用Python构建的爬虫可能会假装是Chrome或Firefox（以绕过反机器人机制），但它没有理由假装是curl，因为这两个工具都被广泛用于构建爬虫，因此从反机器人工具和服务的角度会得到相同的待遇[8]。

因此，在排除浏览器的TLS指纹后，我们使用了与未知TLS指纹匹配的大多数记录的UA头部描述来标记它们。

表IV列出了最常见的113个独特指纹覆盖的工具。由于这些工具之一基于Google Chrome，表IV的下半部分列出了我们能够追溯到Chrome的其他指纹。这14个工具产生的请求总数为9,879,326，覆盖了所有TLS请求的97.2%。使用Go语言（以及Go提供的TLS库）的机器人是最受欢迎的，远远超过Python、perl和wget等传统选择。我们观察到了四种不同的Chromium相关指纹，具有针对Google（Googlebot、Google-Image和Google Page Speed Insights）、无头Chrome以及对应越南版Chrome的coc coc浏览器的指纹。

这些结果展示了TLS指纹识别在验证良性和恶意机器人的身份方面的威力。在声称是msnbot/bingbot并具有有效TLS指纹的38,312个请求中，我们能够通过反向DNS确认它们全部是真实的msnbot或bingbots。同样，对于声称是Googlebot的28,011个请求，我们通过TLS指纹匹配识别了27,833（99.4%）个为真实的Googlebots。其余的机器人也无法产生预期的反向DNS结果，这表明是恶意行为者冒充Googlebot身份以避免被封锁。

使用TLS指纹揭示机器人的真实身份
鉴于我们能够将声称的用户代理（UAs）与展示的TLS指纹匹配，我们检查了所有支持HTTPS的机器人，寻找UAs声明和观察到的TLS指纹之间的不一致。总体来说，我们发现30,233个声称是Firefox或Chrome的客户端中有27,860个（86.2%）在事实上谎报了身份。

假Chrome：

在声称是Chrome的12,148个IP地址中，有10,041个在它们的加密套件中没有预期的GREASE值。因此，我们可以得出结论，超过82.6%的客户在谎称是Chrome。从它们的TLS指纹中，我们可以推断它们主要是运行在Linux操作系统上的cURL和wget。

假Firefox：

类似地，有18,085个IP地址通过其UAs声称是Firefox。然而，12,418（68.7%）个Firefox客户端实际上与Go-http-client的指纹匹配，3,821（21.1%）与libwww-perl的指纹匹配。一小部分请求（5.7%）与Python或cURL匹配。剩余的539个IP地址未匹配数据库中的任何TLS指纹，包括Firefox的指纹。总的来说，我们的结果表明声称是Firefox的18,085个IP地址中有至少17,819个（98.5%）在谎报身份。

真Chrome：

2,419个IP地址中的351个展示了在TLS握手中的GREASE支持，它们声称归属于移动Safari。鉴于Safari目前不支持GREASE（无论是Mac还是iPhone），这是不可能的。这表明有些行为者（无论是善意的还是恶意的）希望获取网站提供给移动Safari浏览器的内容，但缺乏实际操作Apple设备的能力。

其他 TLS 指纹：

最后，有11,693个机器人的TLS指纹是其他类型的，但它们主要属于Go-http-client, Python-urllib, cURL和wget，如表IV所示。它们表现出各种各样的UAs，包括MSIE，Android Browser，.NET CLR和MS Word。这表明存在一个更广泛的假装客户端身份的景观，而不仅仅是我们在这一节中调查的Chrome/Firefox模拟。

利用尝试中的TLS指纹
我们将匹配TLS指纹的方法应用到了之前第VI-A2节中提到的恶意请求背后机器人声明的身份。表V显示了结果。首先，我们观察到几乎没有真实的浏览器访问这些资源，这证实了我们的利用标记（假定攻击者不需要完整的浏览器来向易受攻击的网站发送恶意payload是合理的）。其次，不同类型的恶意请求存在显著的差异。例如，93.4%的利用请求使用了Golang，但只有171个请求使用Golang来查找错位的备份文件。同样，libwww/wget在后门请求中很常见，但这些工具在备份文件探测请求中没有出现。这些结果表明不同代的工具和攻击者，使用不同的底层技术来利用不同的网站漏洞。

case study

专注于JS资源的机器人：

尽管许多机器人不请求图像和其他资源（可能是为了加快爬取速度），但我们观察到了只请求JavaScript资源的机器人。我们数据集中有一个特别的IP（101.4.60.1**）引起了我们的注意，它只下载JavaScript文件，但根据Aristaeus的测试，从未执行它们。由于这个机器人的IP地址属于一家中国反病毒公司，我们怀疑该机器人旨在为反恶意软件研究收集JavaScript文件。

流量突增：

我们在数据集中观察到两次大的流量高峰期。第一次流量激增发生在5月28日至6月17日，有一组机器人持续向我们发送登录尝试和XML-RPC请求。这些机器人首先请求/wp-includes/wlwmanifest.xml来检查蜜罐是否是WordPress实例。然后，它们从作者列表页面提取用户列表，接着开始通过向xmlrpc.php发送POST请求（针对WordPress的用于API身份验证的点）暴力破解管理员账户。这一组机器人总计发出了4,851,989个请求，占总请求的18.4%。类似地，第二次流量峰值对应于数据集中总请求量的21.9%。

伪装失败的尝试：

修改HTTP用户代理头部可能是机器人（无论是试图利用网站的恶意机器人还是由研究人员和安全公司运营的良性的）使用的最常见伪装方法。然而，在我们的研究中，我们观察到了试图修改这个头部但失败的尝试。例如，我们发现"User-Agent"头部的错误拼写，包括"useragent"和"userAgent"。类似地，"Host"头部也包括不同的拼写和大小写形式，如"HOST"，"host"或"hoSt"。这些拼写错误的出现意味着这些头部字段是伪造的。然而，对于某些HTTP库，拼写错误会导致原始头和新头都发送出去。因此，Aristaeus记录的一些请求同时包含了"User-Agent"和"userAgent"头部。对于这些机器人，原始的"User-Agent"头部指示了例如"python-requests/2.23.0"，而"userAgent"头部报告的是"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"。

公开漏洞武器化的时间：

在七个月的研究期间，我们观察到了尝试利用在数据收集开始后公之于众的五种远程命令执行（RCE）漏洞的请求。因此，我们能够看到对这些漏洞的初步探测。这五个RCE漏洞影响了以下软件/固件：

DrayTech调制解调器（CVE-2020-8585）、Netgear GPON路由器（EDB-48225）、MSSQL报表服务器（CVE-2020-0618）、Liferay门户（CVE-2020-7961）和F5流量管理UI（CVE-2020-5902）。

对于DrayTech设备的第一个漏洞，exploit在2020年3月29日发布，仅仅两天后我们在Aristaeus的蜜罐站点上就观察到了利用尝试。Netgear设备的exploit在2020年3月18日公开，Aristaeus在同一天就记录了首次利用尝试。接着，MSSQL报表服务器漏洞的证明概念exploit由报告该漏洞的研究人员在2020年2月14日公开，我们在4天后收到了针对该漏洞的利用尝试。Liferay漏洞在2020年3月20日公开，4天后利用请求出现在Aristaeus的日志中。最后，F5漏洞于2020年6月30日公开，并且我们在同一天看到了针对F5 TMUI shell的请求。

基于这五次情况，我们可以明显观察到从exploit公开到恶意行为者探测该漏洞的时间窗口很短，而且在某些情况下（如Netgear和F5设备）几乎是不存在的。

discussion

这一部分，我们首先强调从Aristaeus收集的数据分析中得出的关键发现，然后探讨我们的基础设施规模与发现的机器人数量之间的关系。最后，我们会讨论Aristaeus的局限性以及未来的研究方向。

A. 关键发现

人人都有可能成为目标：

仅仅在线并公开可访问，每个Aristaeus蜜罐站点平均每月吸引了37,753个请求，其中21,523（57%）显然是恶意的。每个在线站点都面临着指纹识别和各种攻击，利用了操作者的错误（如常见密码）以及最新发布的exploit。

大多数通用机器人请求由基本HTTP库生成：

在我们的数据分析中，我们发现访问我们网站的机器人中有99.3%不支持JavaScript。这使得依赖高级浏览器API和JavaScript的现代浏览器指纹识别变得无效。为了应对这种情况，我们展示了如何使用TLS指纹识别来准确地标记和识别由常见HTTP库创建的浏览环境。

大多数机器人位于住宅IP地址范围：

在我们的实验中，我们观察到多数（64.37%）的机器人IP地址是住宅IP，而只有30.36%的IP地址位于数据中心。这表明机器人使用被感染或其他方式代理的住宅设备来扫描互联网。我们预期来自住宅IP空间的请求在速率限制和黑名单方面较不敏感，因为担心封禁住宅用户。

通用型机器人针对低风险目标：

Aristaeus的日志显示89.5%的会话包含少于20个请求，而包含1000多个请求的会话少于0.13%。暴力破解尝试也呈现出类似模式：99.6%的IP地址对每个域发起的尝试少于10次，只有0.3%的IP地址对每个域发起的尝试超过100次。这表明大多数机器人在攻击时非常有针对性和精确，寻找容易利用的受害者。

IP黑名单不完整：

我们的蜜罐站点日志中，恶意机器人的大量IP（87%）未出现在流行的IP黑名单上。这进一步突出了静态IP黑名单的有限益处，因此需要对机器人采取反应式的防御措施。同时，黑名单覆盖率低凸显了Aristaeus的实用价值，它能够发现成千上万目前未纳入流行黑名单的恶意客户端。

公开的exploits很快会被滥用：

我们发现机器人在exploit公开的同一天就开始搜索易受攻击的目标。我们的发现强调了立即更新面向互联网的软件的重要性，因为任何延迟，无论多小，都可能被自动机器人利用来渗透系统和服务。

伪装的搜索引擎机器人不如预期常见：

与我们的预期相反，声称是搜索引擎机器人的总请求中，只有不到0.3%在说谎。这可能表明搜索引擎机器人没有受到网站的特殊待遇，或者验证搜索引擎机器人源IP地址的机制已经成功地阻止了机器人作者冒充搜索引擎。

大多数通用互联网机器人使用相同的底层HTTP库：

尽管Aristaeus记录了超过1020万来自机器人的HTTPS请求，但这些机器人只生成了558种独特的TLS指纹。我们追踪这些指纹回到了14种流行的工具和HTTP库，它们负责了总请求量的97.2%以上。

B. 基础设施规模

为了理解Aristaeus管理的蜜罐站点的数量如何影响收集的情报（例如，Aristaeus能否在拥有50而不是100个蜜罐站点的情况下记录同样数量的攻击者），我们进行了以下模拟。我们随机选择蜜罐站点的顺序，并计算每个蜜罐站点贡献的独特IP地址和TLS指纹的数量。图7展示了重复此模拟100次的结果。

我们使用模拟（而不是简单地按照提供情报的蜜罐站点排序）是因为新的实际部署在部署后无法获得统计信息。

我们观察到两个明显不同的分布。虽然仅用10%的蜜罐站点就能获得约50%的TLS指纹，但独特IP地址的数量随着蜜罐站点数量的增加而线性增长。我们的发现表明，如果目标是收集机器人的TLS指纹，较小的基础设施就足够了。然而，如果目标是收集机器人IP地址，可以部署更多的蜜罐站点仍然能获得新的观察结果。

C. 限制和未来工作

在这项研究中，我们基于五种流行web应用程序部署了蜜罐站点。由于我们发现许多机器人在发送exploit之前会先对目标进行指纹识别（第VI-A节），因此我们的蜜罐站点不会总是捕捉到针对不支持的web应用程序的exploit尝试。

Aristaeus和蜜罐站点的设计实质上吸引了针对互联网上所有网站的一般性机器人流量。然而，高知名度网站和特定公司经常遭受针对其基础设施的定制型机器人攻击。这些机器人和它们的攻击可能不会被Aristaeus捕捉到，除非攻击者首先在公共网络上尝试过。

作为后续工作，我们计划设计可以动态响应机器人的蜜罐站点，使它们相信它们正在与它们寻找的web应用程序进行交互。现有的恶意软件分析系统已经利用了这种技术，例如，检测恶意的浏览器扩展[58]和试图利用浏览器插件的恶意网站[59]。这样，我们期望我们的蜜罐站点能够捕捉到更多的攻击（尤其是那些目前仅发送初始探测请求就不发送更多流量的单次扫描器）和exploit有效载荷。

爬虫的特征和检测：

为了度量爬虫行为和不同爬虫策略的差异，许多研究者分析了大型网页服务器日志库，并报告他们的研究成果。这些研究包括对microsoft.com上24小时爬虫流量的分析[60]，标准性能评估公司（SPEC）网站12周的流量分析[61]，劳伦斯伯克利国家实验室12.5年网络流量日志[62]，以及学术网络和出版图书馆上的爬虫流量[63][64]。

相对于通用爬虫活动的研究，Web爬虫的安全方面受到的关注要少得多。大多数现有的尝试通过导航模式的差异（如，GET/POST/HEAD等HTTP方法在请求中的百分比，请求的链接类型，以及单个请求之间的时序）来区分爬虫与真实用户[4-6]。然后，这些特征被用于一个或多个基于监督的机器学习算法，使用各篇论文作者能够获取的真实情况（通常是通过手动标记他们访问的至少一个或多个web服务器的流量）进行训练。谢等人提出了一种离线方法，通过寻找针对不存在资源的请求簇来识别恶意爬虫[65]。帕克等人[22]研究了通过寻找鼠标移动、加载层叠样式表（CSS）和跟踪不可见链接来检测恶意web爬虫的可能性。简等人[66]提出了一个基于机器学习的机器人检测方案，该方案经过网络望远镜和蜜罐：

网络望远镜和蜜罐是两种旨在大规模研究互联网扫描活动的系统。Moore等人首次引入[67]的网络望远镜，通过定制路由器将无效IP地址块的流量重定向至收集服务器，以观测和衡量远程网络安全事件。这类工作在捕获DDoS攻击、互联网扫描器或蠕虫感染等网络安全事件方面是有效的。Richter等人[68]的最新研究将这些原则应用到了172个Class A前缀上的89,000个CDN服务器，发现32%的记录扫描流量是本地化扫描的结果。虽然规模庞大，但网络望远镜要么不提供任何响应或互动动作，要么在网络层支持基本响应（例如，如果从特定端口收到SYN，返回SYN-ACK[69]）。这使它们无法分析爬虫与服务器和web应用程序的交互。

蜜罐为监控和记录探查它们的实体活动提供了诱饵计算资源。高交互性蜜罐能以高保真度响应探查，但设置和维护起来较难。相比之下，如Honeyd[70]和SGNET[71]这样的低交互性蜜罐拦截发送给不存在主机的流量，并使用具有各种"个性"的模拟系统来生成响应。这使低交互性蜜罐具备一定的可扩展性，但也限制了其对探查的响应能力[72]。

我们的系统Aristaeus集这些方法的优点于一身。Aristaeus可扩展且可在全球分布式服务器上自动部署。然而，与网络望远镜和低交互性蜜罐不同，我们的系统不仅限于网络层的响应，而是利用了增强后的实际web应用程序执行传统和新型的客户端指纹技术。在这方面，我们的工作与Canali和Balzarotti的蜜网系统最为接近，该系统使用500个具有已知漏洞（如SQL注入和远程命令执行漏洞）的蜜罐网站，研究了攻击者攻击和攻击后的行为[12]。虽然我们的系统与Canali和Balzarotti的工作有相似之处（如使用实际的web应用程序而不是模拟的web应用程序或低交互性web服务器蜜罐），但我们的重点在于对我们接收到的请求进行特征化，将它们聚类到爬虫活动中，并揭示爬虫的真实身份。相比之下，由于Canali和Balzarotti[12]的设置，他们能够详细描绘攻击者如何尝试利用已知漏洞，上传到被攻击服务器的文件类型，以及攻击者如何滥用被攻击服务器进行网络钓鱼和垃圾邮件发送（这些都超出了Aristaeus的目标和能力范围）。

conclusion

在这篇文章中，我们介绍了Aristaeus系统的设计和实现，这是一个用于部署和管理大量之前未使用的域名上的web应用程序的系统，其唯一目的是吸引web机器人。利用Aristaeus，我们进行了长达七个月的大型研究，记录了在全球分布的100个蜜罐站点上的爬虫活动。这些蜜罐捕获了超过200 GB的爬虫活动，这些网站没有自然流量。

通过对这些数据的分析，我们不仅发现了由搜索引擎操作的预期机器人，而且还发现了一个活跃且多样的恶意机器人生态系统，它们不断地探测我们的基础设施，寻找操作员错误（如薄弱的凭据和敏感文件）以及在线软件的易受攻击版本。

我们发现，平均每个由Aristaeus管理的蜜罐站点每月收到超过37K个来自机器人的请求，其中50%是恶意的。在Aristaeus记录的76,000个明显恶意机器人的IP地址中，有87%目前未在流行的基于IP的黑名单中。我们观察到恶意机器人进行暴力破解攻击，web应用程序指纹识别，而且即使在exploit公开的同一天，也能很快地添加新的恶意功能。最后，通过新颖的基于头部、TLS和JavaScript的指纹技术，我们揭示了机器人的真正身份，发现大多数声称是流行浏览器的机器人实际上在撒谎，它们实际上是使用Python和Go构建的简单HTTP库实现的。

除了深入了解恶意机器人的滥用行为，Aristaeus使我们能够建立一个几乎无自然用户流量的数据库。在发表这篇文章之后，我们将向研究人员提供该数据集。这个仅限机器人的数据集可以帮助更好地理解机器人的动态并设计更精确的机器人检测算法。