本文經授權轉載自“七夜安全博客”公眾號
作者：七夜安全
前言
良好的習慣是人生產生複利的有力助手
最近一段時間，看了很多認知方面的書，對我的改變還是很大的。
之前看待事物總是看其一角，做技術也是囿於一面，思維不是很開闊，經過不斷地看書，思考，認知慢慢有了 改變，獲益良多。
作為技術人員，我的建議是不要總是看技術書籍或者一心研究技術，多看看哲學，認知，效率，商業方面的書籍，可以讓你看到人生多種可能性，同時反哺技術上的視野和思考模式。
現在遇到技術項目，儘量不再立即著眼於解決它，而是選擇如何看待它，比如會問自己一些問題：
- 它是否真是一個全新項目 ？
- 它的存在是否合理 ？
- 它的邊界是什麼？
。。。。。。
前面只是一些自己的感悟，如果對大家有啟發，有幫助的話，那就最好不過了。言歸正傳，在上一篇文章中，講解了webshell如何繞過RASP的方法論，並根據方法論設計了 webshell。
雖然有一些繞過方法，但RASP依然是webshell檢測中最強的存在，如果再和HIDS聯動，那些繞過方法在數據捕獲層面都會失效，縱深防禦不是說說而已。
今天說的承接上文，依然是webshell的繞過，不過不叫繞過，叫免殺。對付的不再是RASP（實時檢測手段），而是其它離線的檢測手段，目的是以攻促防。
這次講的內容主要是方法論，我給的是思考方法，而不會直接給一個通殺的webshell，因為沒有意義。如果你還在追求這種浮躁的方式，只能說還是沒脫離“腳本小子”的範疇。
一.思考
檢測方案的邊界
在繞過任何一個檢測引擎之前，思考是很關鍵的，尤其是新手。新手特別喜歡的乾的是 找一大批樣本上傳，看看能不能命中一個，這其實對你是沒有任何提高的。首先要做的是思考，下面我畫了一張思維導圖，理了理思路。
思考過程分為了四個部分，層層遞進，應用在其他方案繞過上,也是可以的，接下來我會根據這四個部分進行解釋。
二.認知
知己知彼
任何一個檢測引擎的大部分檢測手段，都是已知的，就算有創新，那畢竟是很少的一部分，因此首要的入手點是熟悉已知的主流檢測方案，對已知的檢測方案至少有一個原理性的瞭解。在之前的《Webshell檢測能力進化筆記》 一文中，簡要概括了主流的檢測手段及缺陷：
1.基於正則文本特徵檢測
初期對付webshell基本上都是這種方案，根據已知webshell使用的函數和參數，使用正則表達式制定相應的黑規則。
但是正則文法表達能力不足，加上webshell語法靈活，很容易通過混淆繞過這種方式。
2.基於統計特徵的文本檢測
之後為了對付混淆，人們把視野放到了統計學上，通過統計文本熵，字符串長度，特殊符號個數，重合指數，壓縮比等信息制定告警閾值，在對付混淆上有一定的威力。之後隨著機器學習的興起，閾值設置就交給了算法。
但是這種方式著眼於全局，無法顧及局部細節，將混淆的惡意代碼插入到正常文件中，基本上就失效了。
3.基於AST的語法特徵檢測
為了彌補統計特徵的不足，進一步深化，進行語法檢測，關注於每個函數和參數，這種方式精確，誤報較少。但是對於PHP這種動態特性很多的語言，檢測就比較吃力，AST是無法瞭解語義的。
4.動/靜態符號執行
其實本質上是數據流分析， 如果用戶可控的外部變量進入特殊的函數，那麼我們就可以判定這個樣本的危險係數很高。舉例：
<code>/<code>
對數據流進行跟蹤分析的話，就會得出如下有向圖，這種檢測方法覆蓋率高，誤報少。
數據流分析分為靜態和動態兩種，靜態分析通過語法樹遍歷的方式，對數據流進行跟蹤，如果做的好的話，可以對混淆的變量和函數進行還原。動態分析不用做變量還原，但難度更高，不過基本原理是一致的。
5.機器學習/深度學習
這個不是很主流，也算一種輔助手段，特徵主要來源於opcode序列和文本分詞，遇到問題和2類似。
6.沙箱
沙箱在這方面檢測就比較雞肋了，輸入參數未知，沙箱是很難發現威脅的，只是作為一個補充。
這幾種檢測方案都屬於離線檢測方式，除了他們自身解決方案的缺陷外，還有一個本質的缺陷就是信息不完備，我們給webshell傳參，它是無法得知的。正是因為這個原因，以上檢測方案的效果，從原理上是弱於RASP的。（RASP的性能如果做的很高就好了，就不需要其他的了）
三.“敵人”
在瞭解主流的檢測方案後，並不急於設計免殺webshell繞過引擎，你需要了解你的對手，這個時候需要進入探測階段，是非常重要的一環。我一般從五個方面著手，包括覆蓋率，誤報率，容忍度，驗證已知手段，猜測未知手段。
1.覆蓋率，誤報率，容忍度
我一般會準備一些常見的webshell，但是種類必須不同，測試一下引擎的覆蓋率。
接著製造一些有敏感函數，但是無惡意功能的樣本，測試一下引擎的誤報率。例如：
<code>eval
("echo 2323;"
)/<code>
最後，找一些正常樣本，然後不斷添加敏感函數和參數，測試一下引擎的容忍度。
2.驗證已知手段
已知手段主要分為兩大類，靜態和動態，每種方式又包含很多小類，如何驗證具體手段屬於靜態或者動態中的哪一個？
選擇一個普通的webshell,不要一直換，然後對這個webshell的函數名，參數名進行逐步隱藏，一一驗證已知的手段。
<code>/<code>
3.猜測未知手段
既然是猜測，那就看造化了，還是建議不要一直換webshell，只會讓你混亂，而是逐步變形，有創新手法也不會離開靜態和動態的圈子。
四.“磨刀”
通過上面的手段，對引擎有了個基本的瞭解，下面要積累自己的力量，磨刀霍霍了。
1.公開免殺方法
這時候要去漲漲經驗了，看看其他人是如何繞過各種檢測引擎的，他們對付的是哪種檢測手段，需要大家自己總結。我給大家準備了一下資料，足夠大家學習一波了。
https://xz.aliyun.com/t/7151 https://xz.aliyun.com/t/3959 https://klionsec.github.io/2017/10/11/bypasswaf-for-webshell/ https://blkstone.github.io/2016/07/21/php-webshell/ https://www.cnblogs.com/littlehann/p/3522990.html
只是看文章還是不夠，去github上找一下大家貢獻的webshell，看看他們的免殺有什麼可取之處。
2.php手冊
php手冊是最權威的php資料，中文版網址：https://www.php.net/manual/zh/。
php的語法靈活，內置函數豐富，大家通過php手冊可以隨時查詢自己想要的功能。
3.練手
1、http://www.d99net.net/down/WebShellKill_V2.0.9.zip
2、百度WEBDIR+
https://scanner.baidu.com/
3、河馬
https://www.shellpub.com/
4、Web Shell Detector
https://github.com/emposha/PHP-Shell-Detector
5、CloudWalker（牧雲）
https://webshellchop.chaitin.cn/
https://github.com/chaitin/cloudwalker
6、深度學習模型檢測PHP Webshell
http://webshell.cdxy.me/
五.精準打擊
對引擎也熟悉了，對免殺的知識也有了積累，下面就可以根據缺陷和問題進行降維打擊了。一般情況下，很多人繞不過的時候，有時候會問能不能給點思路，引擎把XXX給封鎖了，遇到XXX就會告警。
其實你發現的問題就是解決問題的方向。
舉個例子：
<code>/<code>
樣本中出現system就會報警,那你要做的就是根據你發現的問題，將system隱藏掉。可以變量替換，可以字符串拼接，旋轉加解密。
<code>/<code>
這時候還報警的話，那就可能會有靜態變量還原，動態分析的可能。這個時候再變化，自己寫函數生成 system，同時需要外部變量的參與才行。
<code>/<code>
就這樣按照發現的問題，結合現有手段，一步一步變換。
最後
感謝青藤團隊的邀請，【雷火引擎】公測賽，歡迎大家來對抗。同時，騰訊安全平臺洋蔥團隊開發的WebShell檢測引擎下個月也會進行眾測，以攻促防，歡迎大家參與。具體詳情可關注TSRC和青藤雲安全官方微信公眾號。
