引言
蜜罐技術本質上是對網絡攻擊方進行欺騙的一項技術，通過在服務上布置一些仿真的系統、網絡服務、或是模拟一些物聯網裝置來誘惑攻擊方對其實施攻擊進而捕獲攻擊行為、分析攻擊手段與方式、或是收集一些攻擊者的個人資訊來進行分析畫像達到精準溯源的目的。在某大型攻防演練即将到來之際，我們總結了一些蜜罐識别的方式和經驗，希望能對紅隊的小夥伴有所幫助。
基于蜜罐指紋的識别
指紋識别通常是鑒定業務系統類别最直接的方式，對蜜罐而言也一定會留下屬于它獨特的指紋資訊。開源程式的開發者大多數為了保障版權問題，或宣傳目的，都會留下版權身份資訊，或使用某一些其他開源程式始終會留下特征資訊，如下列大部分開源蜜罐都具有統一的傳回資訊，是以識别直接部署的開源蜜罐也比較簡單。
下表是我們經過手動驗證的開源蜜罐的指紋資訊：
除了開源蜜罐外，一些商業蜜罐也會留下指紋資訊，如某知名蜜罐可以通過以下方式進行識别：
該蜜罐系統會在首頁加載一個/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用戶端、網站登陸簽名程式等各類假的軟體，實質上是一個擷取攻擊者主機上敏感資訊的木馬，待攻擊者下載下傳使用後便可擷取其資訊。為了區分訪客是攻擊還是正常使用者，可以在登陸口設定“忘記密碼”等陷阱按鈕，如下圖所示：