引言

蜜罐技術本質上是對網路攻擊方進行欺騙的一項技術，透過在服務上佈置一些模擬的系統、網路服務、或是模擬一些物聯網裝置來誘惑攻擊方對其實施攻擊從而捕獲攻擊行為、分析攻擊手段與方式、或是收集一些攻擊者的個人資訊來進行分析畫像達到精準溯源的目的。在某大型攻防演練即將到來之際，我們總結了一些蜜罐識別的方式和經驗，希望能對紅隊的小夥伴有所幫助。

基於蜜罐指紋的識別

指紋識別通常是鑑定業務系統類別最直接的方式，對蜜罐而言也一定會留下屬於它獨特的指紋資訊。開源程式的開發者大多數為了保障版權問題，或宣傳目的，都會留下版權身份資訊，或使用某一些其他開源程式始終會留下特徵資訊，如下列大部分開源蜜罐都具有統一的返回資訊，所以識別直接部署的開源蜜罐也比較簡單。

下表是我們經過手動驗證的開源蜜罐的指紋資訊：

除了開源蜜罐外，一些商業蜜罐也會留下指紋資訊，如某知名蜜罐可以透過以下方式進行識別：

該蜜罐系統會在首頁載入一個/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客戶端、網站登陸簽名程式等各類假的軟體，實質上是一個獲取攻擊者主機上敏感資訊的木馬，待攻擊者下載使用後便可獲取其資訊。為了區分訪客是攻擊還是正常使用者，可以在登陸口設定“忘記密碼”等陷阱按鈕，如下圖所示：

使用上圖構造的場景既提示了攻擊者管理員的賬號是什麼，同時也可以不使用弱口令而是採取忘記密碼的方式重置管理員的密碼（賬號提示問題的答案都可以窮舉），這樣極大降低攻擊者防範的戒心，提升了溯源成功率。

此類蜜罐目的很明確的是為了溯源攻擊者，對於從任何渠道獲取的可執行程式，最好還是先進行沙箱檢測，檢測完後用虛擬機器執行以防被溯源。

點選瞭解更多