相信大家都知道，沙箱識別是老生常談的話題了，目前大部分的識別方案都是基于樣本側去完成的。

例如常規(guī)方式，包括硬件檢查（CPU核心數、輸入輸出設備、內存）、鼠標移動檢查、進程名、系統(tǒng)服務、開機時長等，都不能直觀準確地識別出目標進行流量交互的服務器是否是沙箱環(huán)境。

舉個例子，之前看到有師傅使用鼠標移動檢查的方式去識別目標是否是沙箱虛擬機環(huán)境。 那么問題來了，這種方式在釣魚的場景下，我們雖然知道目標是PC客戶端，有人使用這臺電腦，但是對于目標是服務器場景的情況下，這種方法就不適用了。

運維人員并不會時刻都在每臺服務器前面操作，所以我們需要一種更加優(yōu)雅的識別方式。

當然，沙箱是快照還原，時間一般都存在問題。并且由于進行sleep加速，意味著這時候在樣本側進行延遲執(zhí)行操作會被沙箱反調。

一旦樣本被反調了，那么其樣本就身處異常環(huán)境下，這時候延遲幾秒后獲取本地時間，就能夠識別出異常。

這當然也是一種很好的反調試手段。但是，上述這些操作都是在樣本側完成的，需要定制化腳本實現功能，出現問題后進行排查等等都會比較麻煩。

本文將深入淺出地講解基于流量側對沙箱請求流量進行識別的方法，這種方法也能更易部署且有效識別，從而針對性的反制沙箱分析流量。

1 TLS JA3指紋

正式講解流量側識別云沙箱技術之前，我們先簡述一下TLS JA3(S)指紋的基本概念。

JA3為客戶端與服務器之間的加密通信提供了識別度更高的指紋，通過TLS指紋來識別惡意客戶端和服務器之間的TLS協商，從而實現關聯惡意客戶端的效果。

該指紋使用MD5加密，易于在任何平臺上生成，目前廣泛應用于威脅情報。例如，在某些沙箱的樣本分析報告中，可以看到以此佐證不同樣本之間的關聯性的樣例。

如果可以掌握C2服務器與惡意客戶端的JA3(S)，即使加密流量且不知道C2服務器的IP地址或域名，我們仍然可以通過TLS指紋來識別惡意客戶端和服務器之間的TLS協商。

相信看到這里大家就能想到，這也正是對付域前置、反向代理、云函數等流量轉發(fā)隱匿手段的一種措施，通過沙箱執(zhí)行樣本識別與C2之間通信的TLS協商并生成JA3(S)指紋，以此應用于威脅情報從而實現輔助溯源的技術手段。

JA3通過對客戶端發(fā)送的ClientHello數據包中的以下字段收集字節(jié)的十進制值： SSL 版本、接受的密碼、擴展列表、橢圓曲線、橢圓曲線格式。

然后它將這些值按順序連接在一起，使用“，”分隔每個字段，使用“-”分隔每個字段中的每個值。

示例：

771,39578-4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-21,56026-29-23-24,0

MD5編碼：

9ef1ac1938995d826ebe3b9e13d9f83a

如上示例，最終得到并應用的JA3指紋即：

9ef1ac1938995d826ebe3b9e13d9f83a

之前文章提到的JARM與JA3(S)都是TLS指紋，那么他們的區(qū)別是什么呢？

一是JARM指紋是主動掃描并生成指紋的，類似FUZZ的效果；

二是JA3(S)是基于客戶端與服務端流量交互識別并生成的指紋。

2 基于流量的云沙箱識別

上面簡述了JA3(S)指紋的概念，這里應用到識別沙箱流量，也是類似的原理。我們需要一個基礎設施可以監(jiān)控識別上線主機和C2服務器之間的TLS協商，從而生成請求主機的JA3指紋。

這里我們以RedGuard舉例。

通過上圖不難看出，RedGuard充當著C2服務器與上線主機流量交互的代理主機，所有的流量都會經由它轉發(fā)到C2服務器上，那么在這個過程中，我們基于流量側生成并識別JA3指紋的想法就可以實現了，在不修改后端C2設施源碼的基礎上，賦予了生成識別JA3指紋的功能。

在云沙箱的立場上，通過監(jiān)控樣本與C2服務器之間流量交互，生成JA3(S)指紋，識別惡意客戶端，從而進行關聯。

而我們逆向思考，同樣作為C2前置的流量控制設施，我們也可以進行這樣的操作獲取客戶端請求的JA3指紋，通過對不同沙箱環(huán)境的調試，獲取這些JA3指紋形成指紋庫，從而形成基礎攔截策略。

在測試某廠商沙箱環(huán)境時發(fā)現，其請求交互的出口IP雖然數量不大，但是通過IP識別沙箱并不準確，并且這是很容易改變的特征，但是其在多種不同配置的相同系統(tǒng)環(huán)境下JA3指紋是唯一的。

設想在分階段木馬交互的過程中，加載器會首先拉取遠程地址的shellcode，那么在流量識別到請求符合JA3指紋庫的云沙箱特征時，就會進行攔截后續(xù)請求。那么無法獲取shellcode，不能完成整個加載過程，沙箱自然不能對其完整的分析。

如果環(huán)境是無階段的木馬，那么沙箱分析同樣無法最終上線 到C2服務器上，相信大家都有睡一覺起來，C2上掛了一大堆超時已久的沙箱記錄的經歷吧。

當然理想狀態(tài)下，我們可以對不同沙箱環(huán)境進行識別，這主要也是依賴于指紋庫的可靠性。

3 識別網絡空間測繪掃描

在測試的過程中，指紋庫添加GO語言請求庫的JA3指紋后，監(jiān)測RedGuard請求流量情況。可以看到，大部分的請求觸發(fā)了JA3指紋庫特征的基礎攔截。

這里我猜測其測繪產品在該掃描中，底層語言是以GO語言實現的大部分掃描任務。通過一條鏈路，不同底層語言組成的掃描邏輯最終完成了整個掃描任務，這也就解釋了部分測繪產品的掃描為什么觸發(fā)了GO語言請求庫的JA3指紋攔截特征。

當然，觸發(fā)攔截規(guī)則的請求都會被重定向到指定URL站點。

4 后記

JA3(S)指紋當然是可以更改的，但是會很大程度上提高成本，同樣，修改基礎特征無法對其造成影響。如果準備用劫持的方式去偽造JA3指紋，并不一定是可行的，OpenSSL會校驗extension。如果和自己發(fā)出的不一致，則會報錯：

OpenSSL: error:141B30D9:SSL routines:tls_collect_extensions:unsolicited extension

偽造JA3指紋可以看以下兩個項目：

"https://github.com/CUCyber/ja3transport"

"https://github.com/lwthiker/curl-impersonate"

通常自主定制化的惡意軟件會自己去實現TLS，這種情況下JA3指紋可以唯一的指向它。但是現在研發(fā)一般都會用第三方的庫，不管是諸如Python的官方模塊還是win下的組件，如果是這種情況，那么JA3就會重復，誤報率很高。

當然應用到我們的流量控制設施，其實不需要考慮這些固定組件的問題，因為并不會有正常的封裝組件的請求，多數也是上面提到某些語言編寫的掃描流量。反而以此對這些語言請求的JA3指紋封裝進指紋庫，也能起到防止掃描的效果。