從零開始制作一個Web蜜罐掃描器

同上得到的一份資產(chǎn)如下：

如上圖所示，大量的域名如果靠人工來篩選蜜罐，費時費力，開發(fā)一個工具來減少工作量是很自然的想法。

實現(xiàn)的思路

要實現(xiàn)蜜罐掃描器，首先得搞清楚以下幾個問題：

蜜罐是什么蜜罐有啥用蜜罐有什么特征怎么根據(jù)特征從一大批資產(chǎn)中找到蜜罐怎么快速準確的找到蜜罐怎么快速且準確且批量的找到蜜罐怎么快速且準確且批量的找到蜜罐然后還不會留下痕跡

很明顯，一個成功的掃描器，是能夠成功解決上述問題的。我的制作思路，也是跟著上面的步驟一步步走下來的，以下分點進行詳細闡述。

蜜罐是什么？英文名honeypot，蜜罐蜜罐，就是帶蜜的罐子，進去吃了蜜，就出不來了，本質(zhì)上就是一個陷阱。

上面是一個從網(wǎng)上扒下來的蜜罐，長得人模狗樣。進一步查看前端js代碼可以發(fā)現(xiàn)竟然直接使用js進行前端校驗：

可以看到這里如果code為0直接就可以進去了，顯然是在耍我。

蜜罐有啥用：蜜罐的用處就是利用jsonp捕獲黑客社交網(wǎng)絡(luò)信息。

上圖就請求了hd.huya.com這個網(wǎng)頁。注意看這段payload

/web/anchor_recruit/index.html?id=42566%26callback=eval(name)%23&anchorsrc=0

本質(zhì)上就是

通過一個回調(diào)函數(shù)，巧妙的繞過了同源策略的限制，達到了跨域請求的目的。通過跨域請求，獲得了攻擊者的社交網(wǎng)絡(luò)信息，在這個例子中是huya的id信息當然，這要頁面存在jsonp漏洞才能派上用場。

如果不理解同源策略，關(guān)于同源策略以及繞過的方法可以看這篇文章：

https://blog.csdn.net/duzm200542901104/article/details/85870019

蜜罐有什么特征

根據(jù)我們上面的描述，現(xiàn)在可以理解，蜜罐的功能是誘捕黑客。誘捕黑客是利用的jsonp劫持技術(shù)來做。jsonp劫持技術(shù)需要利用jsonp跨域請求很多其他的社交網(wǎng)站頁面從而獲得攻擊者的相關(guān)信息。因此蜜罐的特征就是會發(fā)送很多非正常的跨域請求，并且請求的都是一些常用的社交網(wǎng)站，如bilibili，baidu，huya，youku等。

鑒別方法就是抓包看是否存在很多跨域請求，這里直接用burp抓包即可。

如上所示，請求了很多其他的社交網(wǎng)站api，這是一個很顯著的特征，蜜罐本身使用了jsonp劫持的溯源技術(shù)，當進入這個網(wǎng)頁的那一刻，他就開始溯源攻擊者了。

如果對jsonp劫持攻擊不熟悉可以看這篇文章=https://www.cnblogs.com/happystudyhuan/p/11583384.html

怎么根據(jù)特征從一大批資產(chǎn)中找到蜜罐？

這是一個很實際的問題。如果用通過上面burp抓包一個個點開然后一個個看，其實也能做到，但是很慢。在做攻擊隊項目的時候，如果還是用這種原始的方式，肯定是不行的。因此開發(fā)一個自動化工具快速找到蜜罐的想法應(yīng)運而生，下面說一下我開發(fā)的思路：首先，通過上面的介紹我們可以了解到，無論什么蜜罐，無論哪個廠商的蜜罐，只要是web蜜罐，他就會去做jsonp劫持攻擊，做了jsonp劫持，就會有request，所以我這里用爬蟲去抓request就可以了。抓到了request之后，會有兩個數(shù)據(jù)，一個是request是什么，可能是baidu.com,github.com等等，還有一個就是request的量，通過上面的截圖我們可以看到其實request的量是很大的，至少有大幾十條。由于我們前期抓到了一些蜜罐，其實這里可以把蜜罐中去請求的request提取出來作為一個字典，然后以這個字典作為基準去判斷是否其他的網(wǎng)站是否存在同樣的request請求。上述判斷方式具有一定的通用性，因為無論是哪家廠商的蜜罐，來來回回請求的api就那么幾個。

思路理清楚了，那么就針對需求進行代碼實現(xiàn)：

爬蟲實現(xiàn)

爬蟲這個東西，說難不難，說簡單也不簡單，一個高性能的爬蟲其實也是很有技術(shù)含量的。

這里星光大佬直接推薦了crawlergo，附鏈接：

https://github.com/0Kee-Team/crawlergo

使用crawlergo進行爬取

crawlergo可以直接爬取一個ip的所有request，然后返回一個json文件，如下：

在all_domain_list這個字段里面，存在請求這個ip后爬取到的所有request的domain。這里通過crawlergo，就實現(xiàn)了抓取request的功能。

數(shù)據(jù)清洗和判斷實現(xiàn)

爬取完畢后的數(shù)據(jù)需要進行清洗，才能拿來使用，那么如何清洗呢？這里使用了python的re模塊來進行清洗，

思路如下：首先匹配到all_domain_list

然后將匹配到的數(shù)據(jù)轉(zhuǎn)換成一個大列表

接下逐個判斷字典里是否有這個值，如果有，就設(shè)置一個計數(shù)器count++，如果沒有，就不動，

完整代碼實現(xiàn)如下：

其實這樣寫有點麻煩，星光大佬提出了直接使用集合匹配交集的方法，有效減小了代碼量，這里也貼出來：

文件讀取和寫入實現(xiàn)

上面的工作已經(jīng)完成了邏輯判斷的部分，下面還需要進一步完善一些旁支末節(jié)的部分。因為爬蟲生成的文件是一個json文件，那么操作這個文件還需要一個函數(shù)，同時對文件操作完畢之后需要將result寫入一個文件以供最終審閱。因此還需要添加文件讀取和寫入的模塊。

讀取模塊實現(xiàn)如下：

寫入模塊實現(xiàn)如下：

那么完成了上述步驟，其實一個簡易的蜜罐掃描器雛形就搭建完成了，下面需要進行的是對掃描器進一步的優(yōu)化。

怎么快速找到蜜罐

通過初期對掃描器的測試，會發(fā)現(xiàn)這個掃描器掃的非常慢。完成一個ip的掃描，平均需要十多秒的時間，這個速度十分的離譜。因為一般在實戰(zhàn)中，幾個域名裂變成的子域名，如果是大的站，可能就會有成百上千個，子域名再裂變，那么數(shù)量就極為龐大了。為了解決大批量掃描的問題，就必須提高掃描的性能。由于爬蟲是調(diào)取別人的，且crawlergo是閉源的工具，這里就只能進行本地的優(yōu)化，這里的思路是利用python的多線程進行優(yōu)化。

python多線程的介紹可以看這篇文章：https://www.cnblogs.com/luyuze95/p/11289143.html

這里我們選擇的是threadpool，需要pip額外安裝，這里直接在python中pip install就好

可以看到我這里是已經(jīng)安裝完畢了。然后在代碼中定義線程的數(shù)量

這里是設(shè)置了10個線程，那么通過上述多線程的方式，掃描的速度就得到了大大的提高，雖然python的多線程一直飽受詬病，但有總比沒有強，并且針對這種強io讀寫的操作，使用線程的確要恰當一些。

那么完整代碼如下：

其中work是我們調(diào)取的處理函數(shù)。通過上述代碼，就實現(xiàn)了一個多線程掃描器，在10個線程的條件下，實測1-2s可以掃描一個ip，掃描效率得到了大幅度提升。

怎么快速準確的找到蜜罐？

快速的問題，通過多線程的方式得到了解決，下面還存在一個準確性的問題。準不準確，來自于字典準不準確。字典準不準確，在于對于字典的優(yōu)化是否到位。在初期爬取的時候，字典會有很多雜項，需要對字典去重&刪除臟數(shù)據(jù)&刪除空格。

如上圖所示，初期的字典包含了很多這樣的數(shù)據(jù)，篩選和去重成為了一個必不可少的工作。這里一分為二的來做這件事，首先將字典導入代碼中篩掉空格，然后再人工的篩選出臟數(shù)據(jù)。過程就不再贅述，因為其實也是相當簡單的一件事。

那么經(jīng)過字典的優(yōu)化，最終就得到了一份ok的字典，如下所示：

基本上都是有效的api，那么字典清洗這一步到這里就算完成了。有了一份好的字典，準確性的問題就迎刃而解。怎么快速且準確且批量的找到蜜罐

這里一個關(guān)鍵字就是批量市面上很多好用的工具都是可以批量掃描的，這個東西不難實現(xiàn)，思路如下：

首先，把待檢測的iplist寫到txt的文件里。讀取待檢測的txt文件讀取到了文件之后，把文件中的ip列成單獨的一條條的形式。把單獨的ip傳送給檢測模塊進行檢測。

于是根據(jù)上面的思路，直接寫一個解析模塊就行

通過上面的解析模塊，就可以完成iplist.txt文件的解析工作。解析完畢后，會return一個list。怎么快速且準確且批量的找到蜜罐然后還不會留下痕跡這里痕跡清除的思路可以類比其他的掃描器或者滲透過程中痕跡清除的思路。在實際滲透的過程中或者使用漏掃的過程中，我們常常會使用代理。使用代理一方面是為了防止被溯源到，另一方面常常主機ip會被ban，所以要不斷的更換代理來保證工作的正常完成。

那么這里本質(zhì)上就是需要搭建一個代理池。

代理池這個東西，如果展開來說，又是很大的篇幅，因此這里直接采用他人已經(jīng)造好的輪子。

免費

如果選用免費代理，可以用這個proxypool：https://github.com/jhao104/proxy_pool

這個代理可以自動篩選出可用代理然后給與更換，不過由于都是免費的代理，所以可用度不是很高。接口如圖

如果資金充裕，那么就可以考慮付費版本。

付費版本是付費的代理，付費代理的花樣就有很多了。

這里要介紹一種黑產(chǎn)常用的技術(shù)，叫做秒撥。

秒撥秒撥，本質(zhì)上是一種撥號上網(wǎng)技術(shù)，現(xiàn)在被廣泛的應(yīng)用于黑產(chǎn)，一次斷線重撥，就能能換一個ip，因此得名秒撥。

秒撥的詳細說明可以看下面這篇文章：https://blog.csdn.net/weixin_34268169/article/details/93024675

現(xiàn)在網(wǎng)上的秒撥池很多，這里不一一列舉了，列出我常用的兩個，云立方和極光代理，都可以配置代理池。

感興趣可以試用，出了問題不要找我

通過代理池，其實這里根本就不用寫是否被banip，因為他幾秒一個ip，ip池資源完全夠用，所以不用擔心。

這里直接在電腦開啟代理池，然后跑檢測腳本即可，簡單快捷。

由于過分簡單，這里不再演示。

完整代碼呈現(xiàn)

檢測腳本代碼鏈接：honeypotdetection.py

大字典：biglist.txt

crawlergo腳本：crawlergo

運行之后：

根據(jù)結(jié)果看這里是成功掃出來了兩個蜜罐。延申與突破

在上面的內(nèi)容中，基本實現(xiàn)了一個蜜罐檢測器的基本功能，要用也是能用的，但是星光大佬說了，做事要精益求精，于是我就被按著頭又再一次深化這個蜜罐檢測系統(tǒng)。

其實要優(yōu)化，主要還是優(yōu)化速度，如果要優(yōu)化速度，那么最簡單的思路其實就是直接抓取對應(yīng)蜜罐的靜態(tài)指紋。

抓取到靜態(tài)指紋之后，通過python腳本再來判斷，這樣速度就快的飛起。

如果在靜態(tài)判斷的基礎(chǔ)上再加上多線程，那么就更加快的飛起。

所以這里我們來抓一下蜜罐的靜態(tài)指紋。

通過前期掃描器掃描，找到了一些蜜罐，列表如下：

http://36.110.121.115/login.htmlhttp://203.57.123.127:8088/login.htmlhttp://oa3.chinabond.com.cn/http://vpn7.chinabond.com.cn/http://crm5.chinabond.com.cn/http://mail3.chinabond.com.cn

上述蜜罐都是爬取大量的資產(chǎn)后用蜜罐檢測器檢測出來的，下面我們來分析下這些蜜罐的靜態(tài)特征。

注意這里要開無痕模式，如果不想被溯源的話

打開其中一個蜜罐：查看源碼

這個./js/portrait.js非常引人注入，點進去看一下：

明顯是被混淆過了，結(jié)合語義來理解，這是portrait=畫像，那么可以大膽猜測這段json是黑客畫像用的。猜測了就要進行驗證，這里在控制臺抓到了一個請求的api–api.ip.sb，抓取后全局進行搜索：

發(fā)現(xiàn)在這個文件的305行存在這個這個接口，肯定了我們的猜想。那么我們再來看一看這個頁面的樣子：

堂堂中華人民共和國水利部的登錄頁面，為什么要鬼鬼祟祟的請求我得其他api呢，只能說明這其中有很大的蹊蹺！放著這個蜜罐先不管，我們再打開第二個蜜罐：

和上面一樣

于是這里可以確定一條基本的指紋，./js/portrait.js。

光一條肯定是不夠的，于是再打開一個蜜罐：

這里沒portrait了，換成了一個moment.min.js，非常的神奇，我猜這個文件里面也有鬼，全局搜索請求的api一波：

果然有鬼，于是又捕獲一條指紋js/moment.min.js。

這個時候其實可以嘗試fofa搜一波來篩選，然后再用我的掃描器來曬出真正的蜜罐。

于是打開fofa進行搜索：

關(guān)鍵字：

body="/js/portrait.js" && country="CN"

掃出來的結(jié)果

這個蜜罐是一條雙頭龍，兼具兩個靜態(tài)特征：

其實仔細觀察，會發(fā)現(xiàn)無論是./js/portrait.js還是./js/moment.min.js，都有共同的文件內(nèi)容，就是這個：parcelRequire=function(e,r,t,n)

因此檢測思路也很簡單了，先爬取一批域名，然后將/js/moment.min.js或者/js/portrait.js拼接到域名的后面，然后檢查返回的reponse中有沒有parcelRequire=function(e,r,t,n)這一串字符，如果有，那就判定是蜜罐，如果沒有，那就不是，簡單粗暴快速。下面是腳本實現(xiàn)：

七行代碼解決問題。但是，仔細想一想，真的有這么簡單嘛，做蜜罐的人真的有這么傻嘛？我拿著這個蜜罐去問了下同行，他們說這個是默安的蜜罐，于是我又拿這個去問了下默安的coo

其實到這篇文章寫完的時候，我和星光兩個人已經(jīng)掃了上萬個ip了，發(fā)現(xiàn)的蜜罐很少，我分析可能是他們買的少或者我們掃的域不是蜜罐的域或者大部分蜜罐都布置在內(nèi)網(wǎng)了，公網(wǎng)暴露的很少。

那么本文到了這里，其實就差不多結(jié)束了，因為沒有指紋，所以被迫結(jié)束。

這里也提出了一種更快的掃描方法，就是做靜態(tài)掃描，但是缺點也很明顯，如果廠商做蜜罐隨機化處理，那么就無法根據(jù)靜態(tài)指紋來匹配了。通用性的掃描方法能得到一個理想的結(jié)果，缺點就是掃的稍微慢了一點。如果用通用性的方法想要快一點，就需要增加服務(wù)器配置，開多個線程來掃，這當然也是一種解決辦法。靜態(tài)的指紋庫在以后的實戰(zhàn)過程中遇到了，我會填充到靜態(tài)指紋庫里，本質(zhì)上也是一個收集工作。如果有其他蜜罐的樣本，其他兄弟能幫一幫幫一把，可以把樣本發(fā)給我，小弟叩謝。

最后，感謝星光的支持，很多思路和方法也是他提出來我們一起實踐的。

鏈接：https://github.com/biggerduck/RedTeamNotes

（版權(quán)歸原作者所有，侵刪）