谁是鱼谁是饵？红队视角下蜜罐识别方式汇总

引言

蜜罐技术本质上是对网络攻击方进行欺骗的一项技术，通过在服务上布置一些仿真的系统、网络服务、或是模拟一些物联网设备来诱惑攻击方对其实施攻击从而捕获攻击行为、分析攻击手段与方式、或是收集一些攻击者的个人信息来进行分析画像达到精准溯源的目的。在某大型攻防演练即将到来之际，我们总结了一些蜜罐识别的方式和经验，希望能对红队的小伙伴有所帮助。

基于蜜罐指纹的识别

指纹识别通常是鉴定业务系统类别最直接的方式，对蜜罐而言也一定会留下属于它独特的指纹信息。开源程序的开发者大多数为了保障版权问题，或宣传目的，都会留下版权身份信息，或使用某一些其他开源程序始终会留下特征信息，如下列大部分开源蜜罐都具有统一的返回信息，所以识别直接部署的开源蜜罐也比较简单。

下表是我们经过手动验证的开源蜜罐的指纹信息：

除了开源蜜罐外，一些商业蜜罐也会留下指纹信息，如某知名蜜罐可以通过以下方式进行识别：

该蜜罐系统会在首页加载一个/js/moment.js，该js是jsonp的利用代码，经过混淆加密后，包含 ：

• var a22l=['B09UBwK='
• var a1l=['zNvUy3rPB24TDa=='

注意直接访问该js的时候添加header头里面的Referer，不加Referer和加了的返回不一样，通过识别变量就能识别蜜罐。

除了蜜罐的客户端外，蜜罐的管理端也可以通过指纹进行识别，如对另一个知名商业蜜罐可以通过以下方式进行管理端的识别：

识别该蜜罐系统要分三步，第一步访问系统首页的时候会跳到/login页面，在访问/login页面的时候会加载umi.js和umi.css。

第二步是访问/login页面的时候会有一段js代码"';}continue;case'"，在此js代码往前推12位会得到一个随机code。

第三步是访问/{code}/func-sns.php 返回状态是200 并包含"jsonp"字样的，该php文件最终生成的js文件并里面包含一些jsonp漏洞。

关于此类蜜罐的指纹信息小伙伴们可以去自行整理和研究，这里就不再透露过多细节了。

基于溯源方式的识别

上文提到了jsonp漏洞，事实上很多商业蜜罐都会使用各大厂商（如淘宝、百度、京东等）的前端漏洞来获取攻击者的身份信息。该技术主要依靠主流厂商的jsonp或xss漏洞，将这些漏洞积聚成前端的js水坑代码，当用户浏览器解析到这些js请求时，跨域获取该用户在这些主流应用中的指纹信息，从而达到身份溯源的目的。下图为自研的某系统利用该技术捕捉到各大主流应用的指纹信息截图：

然而基于前端的指纹获取技术都是通过把用户侧加载到的数据传递到服务端而得到的指纹信息。实际执行jsonp或xss的请求是在用户侧进行的，这个原生请求是无法做加密或混淆的。即使部分系统禁用了F12调试面板或者定时清除调试窗口的网络连接，我们依然能够通过抓包的方式获取外域的请求链接。当我们发现在访问某个应用系统时有大量对各大主流厂商的ajax请求时大概率就是遇到蜜罐了，攻击者还能通过抓包白嫖一波厂商的前端漏洞。

事实上chrome80以后会默认在跨域请求的情况下不允许跨域携带cookie给后端，导致蜜罐页面的跨域请求获取攻击者指纹数据的资源时将不再携带 session cookie，相当于以未登录状态访问数据获取的jsonp或xss链接，自然也就获取不到指纹数据，使得以jsonp或xss（以iframe标签嵌套）的方式获取指纹在攻击者使用chrome浏览器时失效。与此同时，以firefox为首的其他主流浏览器厂商也告知在不久将来将使用该安全策略。这类前端指纹获取技术终究会成为历史，但我们依然可以通过这类特征进行蜜罐识别。

基于配置失真的识别

蜜罐系统为了捕获攻击行为，会让自己变得“特别容易被识别”，从而导致配置失真。一些做渗透攻击或者漏洞挖掘的同学应该有这样的经历，在进行对目标的批量漏洞扫描时总是会遇到有那么一两个站永远在指纹识别的条件内。它们一般都比较相似，在返回的信息中会出现大量的***或返回的header特别长的，这些都是不符合常理的web服务。这类蜜罐主要是为了搜集攻击者的攻击行为，同时能够捕获攻击者使用的攻击载荷，甚至是0day漏洞。通常该类蜜罐会在server、header、title等字段里会返回大量的特征信息，如从server里发现一个系统既是iis也是apache的，这在逻辑上就是不合理的，是典型的蜜罐特征。

除此之外，蜜罐系统开放的端口也可能导致配置失真。如一台服务器同时开放了22和3389端口，或是8080端口显示windows，而8081显示ubuntu。以上都是不符合常理的端口配置，基本可以识别成蜜罐，但不排除一些防火墙设备的代理映射服务，所以需要人工进行二次识别。

基于蜜网特性的识别

在获取到某个系统的权限后，我们需要判断该系统是否是一个蜜罐或处在某个蜜网内。由于蜜网通常需要模拟各种系统或设备，所以一般不会使用真实物理机器，通常都是虚拟机。那么虚拟机便是蜜网存在的一个必要不充分条件，我们可以通过检测虚拟机特征来初步判断是否处在一个蜜网内。虚拟机的特性有很多，如：

1、VM虚拟机常用mac地址前缀：00-05-69，00-0C-29，00-50-56等

2、判断 OpenVZ/Xen PV/UML，此方式是一种常见且比较准确的识别虚拟机的方式，网上有大量demo程序可供参考。

当然虚拟化只是蜜网的一个弱特征，这里只是提醒攻击者留个心眼，如果发现当前控制的设备是一个虚拟机，那么就需留个心眼了，除了一些真实的业务确实部署在虚拟化平台外，也有可能掉入了一个蜜网中。

除此之外，大多数蜜网的管理员害怕承担责任，为了防止攻击者利用蜜网作为跳板攻击第三方系统，通常会设置出站连接的上限，如每天只允许15个出站TCP链接，我们可以通过发大量的syn包到其他主机来进行检测和识别。

基于伪造场景的识别

在一些高交互的蜜罐中，为了引诱攻击者对系统进行攻击，蜜罐通常设置的非常真实，不仅贴合业务并且在还在攻击者的一些常用攻击套路上“设坑诱捕”。这里举两个遇到过的蜜罐场景，当某个系统被你轻而易举就拿下时，先问问自己到底是系统被拿下了还是自己被拿下了。

第一个案例是手机号诱捕识别，手机号诱捕主要基于让用户自发输入手机号来获得其真实电话号码，常用的场景来在于短信验证码。使用手机号诱捕的核心思路还是在于如何引诱攻击者使用自身手机号来收取验证码完成系统敏感操作。蜜罐会构造一些特殊的场景来实现反制的隐蔽性，例如故意泄漏陷阱站点的源码文件，然后在源码文件中预设上传漏洞，在上传漏洞的利用条件里加上必须返回短信验证码才能实现成功上传，攻击者按照一套流程走下来后往往会放下戒心，认为这并不是一个蜜罐，为了获取webshell而使用自身的手机号，从而获取到该类信息。

针对此类蜜罐，红队人员应该随时保持警惕，可以使用一些网上接码平台进行手机的验证。即便是没有找到可用的解码平台，也可以使用不常用的手机号或者新手机号或者阿里小号等业务，一般获取到你的手机号后，都是会进行一轮社工库查询，所以使用新手机号可有效避免被画像。

第二个案例是基于邮件做的蜜罐，邮件服务器作为攻击者重点关注的系统包含了大量的敏感信息。从以往攻防演练的经验来看，很多攻击者都是通过邮件内容为切入点，查阅敏感信息并以此对相关系统发起攻击。该思路反过来同样也可以用于蜜罐上，比较经典的案例是预设一个邮件系统，故意设置管理员的弱口令，在邮件里放上与“运维人员”来往的通信记录，附件里可以放上vpn客户端、网站登陆签名程序等各类假的软件，实质上是一个获取攻击者主机上敏感信息的木马，待攻击者下载使用后便可获取其信息。为了区分访客是攻击还是正常用户，可以在登陆口设置“忘记密码”等陷阱按钮，如下图所示：

使用上图构造的场景既提示了攻击者管理员的账号是什么，同时也可以不使用弱口令而是采取忘记密码的方式重置管理员的密码（账号提示问题的答案都可以穷举），这样极大降低攻击者防范的戒心，提升了溯源成功率。

此类蜜罐目的很明确的是为了溯源攻击者，对于从任何渠道获取的可执行程序，最好还是先进行沙箱检测，检测完后用虚拟机运行以防被溯源。

了解更多