《2019補天白帽大會》 ——Red Teaming 紅隊行動

時間：2019年5月29日（13：30-17:30）

地點：上海雅居樂萬豪酒店（5F）

[正式開始]

主持人：各位朋友們，下午好！

歡迎大家來到補天白帽大會紅隊分論壇，這個論壇討論的是“實戰化安全能力”中的攻擊能力，我相信選擇這個分論壇一定是大家今天做的最明智的決定。

今天也是一個值得紀念的日子，奇安信旗下的 A-TEAM首次在公開場合與大家見面，A-TEAM 是奇安信集團旗下的一支純技術研究團隊，主要致力於 Web 滲透，APT 攻防、對抗，以及前瞻性攻防工具預研。我們從底層原理、協議層面進行嚴肅、有深度的技術研究，深入還原攻與防的技術本質。

A-TEAM也是奇安信CERT背後的支撐團隊，憑藉著對攻擊者更深入的理解與相關領域的技術積累，在過去的一年裡我們曾多次搶先提供windows域、exchange、weblogic等重大安全問題的預警及可行的處置措施。

未來我們將秉承古典駭客精神進行有深度、服務實戰的安全研究工作，同時我們會不定期釋出一些專案向社會貢獻自己的一份力量，具體資訊可以關注我們的GitHub。

今天A-TEAM首次公開亮相，也帶來了五個非常硬核的議題，與大家一起分享探討。在議題分享前，讓我們一起隆重邀請我的好朋友，著名老駭客TB為本次論壇致開幕詞，有情TB!

[盤古創始人 TB：開場致辭。]

    

TB：感謝大家！首先，作為一個東道主，因為我們是盤古團代。我們希望大家如果有興趣的話，明天可以參加“Mosec”論壇。我這裡致辭也沒有準備什麼稿子，我這裡也不想多說什麼了。我本身也是做技術的，我希望大家能夠在“白帽子”的路上不忘初心、不要拋棄這一塊興趣，能夠在技術這一塊做深、做廣。什麼叫做深、做廣呢？就是說有一些漏洞，我們要挖掘這些漏洞詳細的底層原因，然後去探究這些東西。然後“做廣”，是因為我覺得駭客或者白帽子領域需要知識的廣度，光知道一“點”東西，很難達到攻擊或者是防禦的效果，希望大家要做到廣度和深度。

    

其它的也不說了，主要就是這些。預祝Red Teaming紅隊論壇成功。

    

主持人：提到APT很多都講到郵件。我今天給大家帶來一個新的視角，由我們的工程師來給大家講一個從郵件開始如何不利用傳統手段，一步一步達到目標的過程。

Pr0mise：紅隊行動，郵件戰爭

 

大家好，今天給大家分享的議題叫做郵件戰爭，介紹了我去年的一次重點圍繞郵件展開的滲透經歷。目的是給大家分享一種滲透思路，以及後滲透過程中的思維方式。我是本次議題的演講人劉偉，接下來我做一個簡單的自我介紹。

本人就職於奇安信A-Team，是一名滲透測試工程師。其實我一開始是做免殺的，後來覺得太難了就轉行做web，由於入行太晚，我學web安全的時候各種waf裝置大行其道，需要測試的站點大多部署在阿里雲上，並且安裝了安全狗/網站衛士等軟體，此時我的御劍和明小子失去了作用，這還怎麼測？ web安全也太難了，只能轉行做做滲透了。

出於工作性質的原因，我接觸了很多拓撲復雜且安全裝置繁多的環境，也漸漸熟知了各類安全裝置的對抗手段。我們都知道現在的安全裝置日益完善，網路環境日趨複雜。傳統的滲透“三板斧”可能就不再適用了。何謂三板斧？

首先說第一板斧，當我們透過郵件魚或者Web漏洞利用等任意什麼手段，拿到了對方內網一臺機器的許可權後，會進行簡單的資訊收集、做初期的環境偵查。比如：會提取憑據等一系列對攻擊者有利的資訊，之後對資訊進行歸類分析。假設沒有找到有價值資訊，我們會進行網段探測：這是第二板斧。

我們會用一些工具進行網路掃描，比如nmap。嘗試探測對方內網的網路拓撲，瞭解網段分佈，繼而識別企業元件的指紋，根據指紋搜尋漏洞資訊，或是審計程式碼挖洞。找到漏洞後接下來就是第三板斧"漏洞利用"。

如果getshell成功，就繼續進行資訊收集，重複三板斧的過程，直到提取到有價值資訊（管理員憑據）之後，進行憑據利用，打到目標機。

這個過程其實存在一系列的問題，比如我用nmap進行網端探測獲取對方目標網路拓撲的時候，由於nmap無法精準的識別哪些機器是“蜜罐”，哪些是真實資產，所以可能產生蜜罐裝置告警。而且nmap的掃描指紋有明顯的特徵，所以會被ids識別。

當面對一個極度重視安全，並且部署了全量安全裝置的企業時，我們需要一點不一樣的經歷。

首先，我透過郵件釣魚的方案打到對方內網裡一臺HR的機器，我進行簡單資訊收集後，發現對方域網裡有一個ACL缺陷，此處缺陷可以間接影響到整個域，我只要利用此處ACL缺陷就能完成本次滲透，控制所有賬戶的憑據。那麼，什麼是ACL呢？

ACL全稱叫作訪問控制列表，列表內的記錄叫做訪問控制條目，也就是ace. 域內的所有物件的許可權控制都是透過ACL實現的。

    

大家熟悉的ACL作用物件有成員賬戶、機器賬戶、組，組策略、文件伺服器等。接下來我舉一個小例子，讓大家瞭解ACL的作用。假設我們是Domain admins組，要新增一個名為test的使用者到domain Users組裡面，新增成功後，domain user組裡會有一個test的成員。這是因為domain user組內的acl裡有一條ace為“允許domain admins組對它進行完全控制”。

這裡我為什麼要強調組呢？

這牽扯到ACL的一個特性，叫做繼承。我以去年的exchange ssrf漏洞利用鏈舉例，加深大家的理解。漏洞的核心利用點在於域上的有一條ACE寫的是允許Exchange windows permission組進行任意的ACL修改。也就是說，當我們控制住Exchange windows permission組的任何一個使用者後，就可以發出如下的acl請求，讓test使用者對domain admins組有完全控制權。

而exchange trusted subsystem組屬於Exchange windows permission組，他們是父子關係，所以可以繼承父組的acl。當他發出相同的acl請求時，也會返回成功。

又由於exchange的機器賬戶屬於exchange trusted subsystem組，所以當他發出相同的acr請求時，也會返回成功。

攻擊者如果在內網裡發現了一個作用於Exchange機器賬戶的ssrf的漏洞，就可以控制域內所有的賬戶。 acl的配置儲存在哪裡呢？

這些資訊其實儲存在域資料庫上面，域資料庫提供了一些介面訪問所有的acl資訊，介面的上層協議是ldap，有一些工具可以透過ldap檢索所有的配置，利用缺陷推匯出這個域內有哪些攻擊路徑。

常見的工具有Bloodhound，invoke aclpwn等。接下來我以Bloodhound在實戰中進行效果測試，大家能夠看到這個圖上“G-IT可以對EXCHANGE WINDOWS PERMISSIONS新增成員，Exchange windows permission組能對域內進行任意的acl修改，當攻擊者能夠控制IT部門這11個賬戶中任意一個賬戶之後，他就能完成本次滲透了。接下來我對這一處ACL缺陷進行成因分析：通常來說IT部門需要將新員工的帳號進行精準的許可權控制，這一步透過將賬號新增到已經配置好acl的組裡來實現。也就是說It部門需要有新增成員的特權，這個過程中，出於安全考慮，拒絕了it部門向高特權使用者組新增成員，比如域管組。但是忽略了一些高特權的系統組，比如：ex windows permission組。

    

接下來有一個簡單的流程展示，IT組成員可以繼承自身組的ACL將自身賬戶新增到Ex Win Permission內，繼而繼承Exchange windows commission.組的acl，將自己提權為域管理員。接下來要面臨的一個問題是，如何控制IT組的成員。

傳統思路有進行密碼的爆破。考慮到對方企業密碼策略較為複雜，有14位以上的數字、字母等特殊字元組成。同時我們在爆破的過程中，可能不可避免的會在域控上留下一些審計失敗的LOG，這個時候就會觸發日誌審計預警。其它可以嘗試控制IT部門成員的PC機，之後可能透過一些傳統的工具提取憑據，這個時候就有了IT部門某位員工的帳號許可權，但是此條難度較大，所以也忽略：因為IT部門員工可能具備較強的安全意識。我們控制一些關聯登陸的網站提取關於IT組成員賬戶的憑據，但是此種方案可能有點本末倒置。那麼有沒有不需要密碼，就能利用IT組的成員賬戶向域內新增成員的方案呢？這裡不妨思考一下新增域成員的原理，假設我們在域內執行net User， 它會透過SMB連線一個域控的一個叫samr的命名管道，從而間接連線到域資料庫上。假設域資料庫對某位使用者進行身份認定成功、許可權鑑定之後就會返回成功的資訊，但是其實域資料庫提供了其它的介面，就像我剛剛提到的LDAP。但是LDAP協議其實是可以被攻擊的，LDAP支援NTLM認證，NTLM由於自身的缺陷可以導致中間人攻擊。

正常的NTLM認證流程，正常的想要域內新增成員的話，要把自身的傳送到到ldap上，身份認證等成功返回相關的資訊。中間人攻擊流程我誘導IT部門的員工跟我這臺中間人的機器進行NTLM認證，此時就可以拿到憑據跟ldap進行認證，認證成功之後我可以在這臺中間人的機器上繼承IT成員組織的ACL。也就是說，我不需要密碼，就能在域上新增一個成員。此時確定了要進行NTLM Relay攻擊，就要選擇一個可以觸發NTLM Relay的載體。通常是有幾種：瀏覽器、檔案伺服器，社交工具，郵件。瀏覽器需要大量的互動，所以pass。如果能夠觸發IT跟內部某臺文件伺服器的通訊，我們對這臺文件伺服器進行滲透、投毒。比如：投毒一個快捷方式，這條快捷方式指向中間人的伺服器，然後下一次到IT部門的員工訪問文件伺服器的時候，就會處罰NTLM的認證。但是我們的滲透是黑盒的，由於此時也沒有控制到一些進行流量監控的裝置，也不能進行DNS劫持，所以我不知道IT部門的員工日常訪問的位置，所以此方案忽略。再者“社交工具”，假設能夠找到社交工具能跟NTLM觸發的點，也可以進行NTLM Relay，但是這條挖掘成本過高。那麼，只剩下郵件這個渠道。

這裡要思考一下，郵件觸發NTLM Relay的點，一般有以下幾種。

1.郵件新增a標籤，誘導點選。

2.郵件新增各類可觸發認證的附件。但是這些方案都需要互動，IT部門的員工都有較強的安全意識，假設我給他們直接傳送這類需要互動的惡意郵件，可能會被他們意識到此次攻擊行動，導致滲透過程的終止。有沒有不需要互動的方案？我在持續監控被控端的過程中，發現他們所用的郵件客戶端outlook在載入外部資源時有不同的策略。首先是載入外部郵箱的時候，當一個外部郵箱給它傳送郵件，其實它並不會完全的載入郵件中所有的內容，它會只載入郵件正文中的文字內容。正文裡的圖片需要經過手工確認後才能載入，但是企業內部郵箱發來郵件的時候，會完全載入正文裡的所有的內容。

    

其實這是一個比較奇怪的問題，我查閱MSDN的文件發現，outlook預設來說，它會自動載入其他員工傳送的外部圖片。我們不妨這樣理解，outlook認為外部的發件人是不可信任的、是不安全的。認為內部的域員工發來的郵件是可以信任的，因為它是“熟人”。它認為“熟人”應該沒有問題，但是熟人真的沒有問題嗎？我們利用outlook自動載入內部域郵箱發來的郵件圖片這一個，可以制定核心的框架。比如：我可以控制內部的一個員工的郵箱，他符合outlook的熟人策略。以他的身份傳送一個惡意郵件給IT部門的任意員工，IT部門的任意員工在outlook上預覽此封郵件會自動載入unc標籤，這個時候就可以跟中間人進行NTLM認證，此時就可以把IT部門的員工憑據轉發到域控的Dc ldaps上。此時我就可以在域內進行任意的修改，比如：將攻擊者已經控制的賬戶提升為“域管”。這個核心的滲透框架有沒有問題呢？

    

我在實際測試的時候，我發現受害者在outlook內預覽一個惡意郵件的時候，惡意郵件IMG標籤如果指向的是一個 UNC 路徑，那麼會有長時間的彈窗，這其實是明顯的異常。我根據IE Relay的啟發，我發現outlook也沒有修復 http 重定向至 SMB 的問題，所以我就利用這種方案來bypass 了彈窗。此時我只控制的一臺HR電腦和內網的一臺Linux伺服器，假如直接以HR的郵箱傳送惡意郵件。那麼可能會面臨如下的場景：IT部門的員工在內部的IM工具上跟HR進行郵件主題的詳細對接，他們可能會發現一個比較明顯的異常。因為HR本人並沒有傳送此封惡意郵件，這就會導致我們滲透過程的終止。既然不能直接發，只能間接發了。也就是說，我要想方設法打通HR跟IT部門之間的聯絡。根據“六度人脈理論”，我們在地球上跟任意一個陌生人之間的關係鏈不會超過六層。也就是說，HR可能認識一個人叫X，X可能認識一個人叫Y，Y某或許會認識一個與IT有頻繁郵件交流的人，此時就能構造一個熟人鏈條讓HR跟IT部門之間有合理的交流。

    

我的郵件要如何構造才能在沒有密碼的情況下，控制這個熟人鏈條內這些節點的郵箱帳號呢？我透過簡單的資訊收集，發現郵件伺服器Exchange。Exchange提供了很多介面，比如：EWS，它還提供了有ECP、OWA等。還有一些其它的介面，我就不作過多介紹了。這裡重點介紹一下EWS介面，EWS是 Exchange 提供的一個 WebService 介面，可以透過這個介面來訪問使用者的郵箱。這個介面支援NLTM跟Kerberos。這個時候其實就能在不需要密碼的情況下，構造一份為郵件構建熟人鏈條的郵箱節點。初始受害者如果構造一個惡意郵件滿足outlook的熟人策略，此時熟人鏈中的節點在本地的outlook上御覽此封郵件就會自動載入IMG的標籤，Bypass outlook的一個彈窗。之後302跳轉到已經控制的中間人機器，這臺中間人機器就可以把熟人鏈中節點的憑據轉發到EWS介面上，完成NTLM的認證，此時就是不需要密碼接管熟人鏈中郵箱的全過程。

    

這封惡意郵件應該如何構造呢？或者是說如何讓惡意郵件的主題更合理一些？這裡我設計了一個簡單的工具來實現自動化的流程，當我控制的這個初始受害者也就是HR給別人傳送郵件的時候，我監控這個傳送的動作，匹配這個傳送動作中的收件人的郵箱。假設他是給一些熟人鏈中節點之外的郵箱傳送郵件，那麼就繼續迴圈，假設或者是說直到這個HR給熟人鏈中的節點X傳送郵件的時候，我汙染郵件正文。汙染郵件正文會有一個惡意的IMG標籤，此時就能成功接管熟人鏈中節點郵箱帳號許可權。那麼這個汙染郵件正文，是如何來實現的呢？當HR給熟人鏈中的節點傳送一封郵件之後，我會立即跟著傳送一封一模一樣的郵件，唯一的區別在於惡意郵件中多了一個IMG的標籤。在熟人鏈中的節點的outlook裡，預覽或者是說在outlook裡檢視它收到的郵件的時候，它會看到兩封郵件。第一封就是我們的惡意郵件，第二封是正常郵件。

    

我根據上述的方案，設計了一套橫向移動過程中基於流程，我把所有的受害者憑據放到一個資源池監控所有人的郵件傳送。匹配到熟人郵箱汙染正文，轉到EWS接管對方的郵箱，再把對方的郵箱憑據載入到受害者資源池裡面，直到受害者給IT部門的人傳送郵件，那麼我也是實現相同的汙染郵件正文，但是此時就不是轉到EWS介面上，而是轉到域控的LDAPS介面，我就能接管IT部門的憑據，整合IT組的ACL，在域上進行任意ACL修改，讓任意一個帳號有域管的特權。

    

武器說明。支援中文，支援郵件後門的增加與刪除（delegate）。支援郵件汙染（包含附件汙染+正文汙染）。支援關鍵字搜尋及delegate後的關鍵子搜尋，支援已公開的exchange ssrf漏洞利用。可對outlook設定homepage（郵件服務端未打ruler補丁的話，透過郵件汙染可以直接滲透個人終端。郵件關係梳理。簡單的說就是你傳送一封惡意郵件之後，就能接管對方的機器。我控制一個郵箱帳號之後，我會提取它的發件跟收件資訊，把這些資訊作為一個關係匯入到“圖資料庫”裡面。我把發件人跟收件人作為一個節點匯入到圖資料庫之後，直接輸入某一個使用者的郵箱就可以直接規劃出從你到目標郵箱之間最短的攻擊路徑。

    

完成了定製化的工具開發之後，就涉及到武器部署。武器部署的目的之一，隱藏自己。其次是加大取證難度。這個過程我是透過大量的轉發動作來實現的，所以需要你在對方內網裡控制一臺Linux機器以及你每年有一臺外網的vps搭建二次化開發的工具。接下來是一張轉發的流程圖，它可能較為複雜。（圖）這裡我不詳細講解這個轉發流程的實現了，大家能看到受害者訪問已經被汙染後的惡意郵件之後，自動載入IMG標籤、302跳轉到內網一臺已經被攻陷的伺服器，跟這臺已經被攻陷的伺服器進行NTLM認證之後，將流量封裝轉到外網的vps的445埠上。之後外網的vps透過埠的對映，把445埠轉到內網的Linux上，然後跟內網的EWS介面完成NTLM認證。設計完這一個部署流程之後，我重新審視了一下，發現貌似還可以更隱蔽一點。也就是說，大多數的郵件閘道器裝置都會對郵件正文進行掃描。提取正文裡的UL進行域名的信譽評級，信譽評級幾個因素，可能有講了這個域名是否已經有在IOC指標裡出現過。檢查這個域名是否是新註冊的？假如達到一定的權重之後，他就認為這個郵件裡嵌著一個URL是不正常，直接歸類到垃圾箱裡，受害者就無法接受到這個郵件。

    

這裡我發現郵件閘道器的引擎其實是部署在雲端的，部署在雲端意味著出口IP跟目標內網出口是對不上的？我在302跳轉之前加上一個目標出口IP，然後還加了一個UA的判斷，因為我發現所有的都是Office觸發，郵件閘道器肯定不會有Office的UA。所以掃描的時候，無法發現後端已經被攻陷的伺服器，所以它可能會將此封惡意郵件進行放行。接下來有一個簡單的流程圖來展示，這個大家可以簡單的理解為“郵件閘道器”。他獲取郵件內容，提取URL，之後關聯反病毒引擎對URL進行判斷。比如：信譽評級，掃描這個URL上隨之附帶的一些福建，比如：這個URL有關聯的一些文件，會用反病毒引擎對其進行掃描。由於我的域名有302的判斷，所以他認為這是一個正常的。

    

萬事俱備，讓我們看一下這個定製化武器的效果。（圖）這是一個簡單的展示，我提取了此名招聘HR的發件跟收件的資訊，把這些資訊作為一個關係節點載入到一個圖資料庫裡，也就是嘗試直接定義此名招聘直接上級是誰。我希望能夠得到一個最短的路徑，下面是一張圖形展示。比如：初始受害者為招聘HR，它直接列出了它跟招聘組長也就是直接上級之間最短的路徑。我發現他跟招聘組長之間交流的主題，我依據這些郵件主題判斷郵件交流的頻率，根據這個頻率可以進行相應的郵件汙染。

透過郵件汙染控制H的上級P，現在的供給路線：透過招聘HR達到組長H，透過組長進行進一步郵件關係梳理確定了上級為HRBP head P。現在我們要面臨的問題，就是如何打通HRBP Head跟謀為不願意透露姓名但是與IT有頻繁交流的高人之間的聯絡。這個時候我進行了一個簡單的HR部門的架構分析，一般來說人力資源部門會下設以下小組，有：招聘、運營、薪酬、福利、培訓等等。運營組複雜維護整個公司所有員工的資訊，我作為攻擊者只要成功控制了運營組的組長。當運營組的組長跟它的組員進行郵件交流的時候，透過我的定製化的工具進行成功的汙染就能控制他的組員。比如：他的組員叫小明和小紅。小紅需要跟IT部門對接某一個員工的帳號需要什麼樣的許可權。當小紅跟IT進行跨部門溝通的時候，也是一個郵件往來的交流。那麼，我汙染他們的交流郵件，就能控制IT的帳號。此時大家審視一下，我已經打通了更新路徑。有招聘HR A，跟它的組長H，跟組長H的上級HRBP。現在面臨的一個問題，就是如何打通招聘組與運營組之間的聯絡。其實這個可以設計一個“迂迴”的路徑，因為正常兩個組長是不會透過郵件進行溝通的。進一步明確的攻擊路線如下：HR到H，到HRBP Head，然後想辦法迂迴控制運營組組長的帳號，運營組組長控制運營組的組員，之後組員跟IT進行互動完成本次滲透。

    

因為週報制度的存在，P某（hrbp head）需要定期向上級（hrvp）進行彙報工作，我透過之前成功汙染週報郵件，成功控制了hrvp郵箱帳號。這是我工具的圖例演示（圖），此時我們就能完善一個攻擊路線。我梳理HRVP的郵件關係，得知運營組組長為k，組員Y負責與IT部門對接新員工許可權賦予。透過下面的一個郵件資訊裡的圖，印證了我的這個思路。大家能夠看到組員Y跟IT部門對接，某一個入職的員工需要在某臺文件伺服器上有什麼樣的許可權。既然思路驗證成功，就能完成整個熟稔連的攻擊列表。由招聘的HR到H到HRBP head然後迂迴攻擊打道運營組長，想辦法控制運營組的組長及組員，那麼就能完成本次的滲透了。這個時候我遇到了一個意外，因為本次Ex Win Permission加outlook實現的橫向流程不是主動出擊的方案，是一種被動性的橫向移動。所以我在等待的期間，我每控制一個熟人鏈中要等待，等待的期間遭遇了人力資源部門臨時的組織調整，原先的運營組組長換人了。這個時候我就需要針對這種突發狀況，進行簡單的攻擊路線修正。之後當HRVP跟原運營組組長K和新運營組組長Q進行郵件互動的時候，汙染他們兩個人的郵件成功控制了K跟Q，之後再透過Q跟組員進行郵件交流的時候，控制了組員Y。

    

那麼我們做一次整個攻擊鏈條的完整回顧。首先我透過郵件釣魚的方案控制了對方公司裡一名招聘HR的機器，透過它的機器進行初期的環境偵查，發現了域內一處ACL缺陷，透過這個ACL缺陷我畫出核心的滲透框架。透過這個反推中其它的關鍵節點也就是招聘組長H，透過招聘組長H控制HRBP Head，透過HRBP Head打通運營負責人K，然後控制運營新負責人L，然後運營組員Y，IT等達成。這個時候我作為攻擊者，我就可以不需要IT組的帳號密碼，而繼承IT組的ACL。我新增一個攻擊者已經控制的郵件帳號，這個時候A就具有Ex Win Permission，它就能夠對域上進行任意操作。此時我完成的所有的滲透任務。

    

我們來回顧一下本次滲透流程的優點跟缺點。優點是規避了所有的安全裝置，這裡我不介紹那種EDR的對抗，只是說IDS。因為中間人的機器進行NTLM Real攻擊的時候，IDS裝置不會發現異常。缺點，不能說缺點，因為確實沒有什麼缺點，可以說是緩解的措施。緩解的措施在於，我們可以應用類似於某些服務的簽名功能，這個簽名可以要求一個使用者跟相應的服務進行認證時，用使用者的密碼生成加密。當然，一般企業也沒有開這種。

    

我的演講結束，謝謝大家！

    

問：EWS之類也有日誌，；因為你存在劫持者和本人自己收郵件，所以這裡是不是也會有痕跡可以做感知的？

Pr0mise：當防守方已經知道了此次攻擊方式之後，可以依據這個攻擊方式進行相應的防護。比如：他可以檢查。我在滲透過程中有利用到“郵件後門”，這個會在ldap上留一個明顯的新建專案，防守方監測這個專案就可以感知到哪些郵件賬戶已經被攻破。

    

問：你用到A標籤。

Pr0mise：其實我沒有用到A標籤。我在outlook出發有A標籤，最終沒有選擇就是因為它們沒有解決互動的問題。

    

問：最後你用的是圖片。對吧？

Pr0mise：嗯。

    

問：理論上圖片這種接近302轉的連結也是可以作為一個感知的點吧？

Pr0mise：只是一個跳轉的動作，我覺得這不存在異常。

[2月30日：紅對行動，終端日誌對抗。]

2月30日：大家好，我分享的議題是“紅隊行動-終端日誌對抗”。在網路安全環境日益惡化的今天，絕大部分的中小企業、政府單位，還有一些特殊部門均採購了越來越多、越來越好的安全產品。這些安全產品中，有一些可以透過對日日誌的監控達到預警目的。甚至有一些產品做的非常好，不僅可以預警，還可以做到及時、自動的處置。這樣就造成了我們在滲透過程當中，很有可能第一步還沒有開始就已經結束了。本議題就是要和這種基於日誌查詢告警的安全產品進行對抗。我是議題的演講人鄧遜（音）。

由於我是第一次登臺分享技術，所以請允許我多花一點時間來介紹自己。我的網路ID是“2月30日”，早年的時候混跡在一個叫“冰點極限”的技術論壇裡面。這個論壇是一個非常老，也沒有開放註冊的一個封閉論壇，裡面只討論一些純粹的技術。後來創始人覺得做技術可能不掙錢，然後回老家賣蟹肉煲去了。接下來是我的工作經歷，為什麼我在安全行業做了這麼多年，才第一次出來分享技術？是因為我以前的工作性質，領導不允許我們把做的東西、還有研究的東西拿出來做這種演講。整個工作的歷程來說，我都是在處理一些一線的實際技術對抗方面的問題。主要涉及的方面有APT、Web安全、系統安全和資料庫等方面，現在供職於奇安信A-Team。

我們要研究一個東西，首先要明確自己的研究物件。

    

研究物件主要有三點：1.終端日誌的定義。我這裡把系統終端中發生的檔案訪問、執行命令、網路訪問，這些操作產生的日誌統稱為“終端日誌”。這個終端也不僅指是一個Linux作業系統，可以是一個IoT裝置、一個印表機，甚至一些什麼別的奇奇怪怪的東西。2.本次的研究物件。本議題主要把問題聚焦在命令執行產生的日誌上面。3.問題場景的設定。我把場景設定在一個Linux下面的一個低許可權的webshell上面。不管我們做測試還是給客戶做安全評估，這個過程當中很多時候做外網打點，都是從一個低許可權的webshell開始的。Linux低許可權webshell是非常常見的場景，也是我們一線工作人員經常遇到的，所以我認為把場景設定在這裡是非常有價值的。

    

講對抗的話，就必須要來認識我們的對手。（圖）這個地方簡單的列舉了一些開源的安全HIDS這種日誌告警工具和一些方法，因為時間有限我不可能把所有的產品都拿出來做一下，所以就選了開源、不用花錢的產品。第一個是Shelllog，是透過使用syslog介面或者直接修改Bash原始碼，然後再透過其它的程式對日誌記錄進行匹配告警的方法。它的方法比較古老，特點是簡單易用，缺點是隻能被修改的Shell本身執行的命令。然後Auditd是核心提供的一種稽核訊息，是透過記錄系統產生的系統呼叫，應用程式做的系統呼叫，把系統呼叫的引數進行記錄，特點是簡單易用，範圍非常的廣，幾乎所有的Linux的發行版本都支援它。這個地方標進行了標紅，我們後來會詳細的講到它。第三個是ossec，ossec在監控命令執行這個方面，主要就是依賴於對Auditd日誌查詢，然後根據內建的規則進行報警。比如給管理員發郵件，甚至是打電話之類的。它的特點是簡單易用多平臺。第四個輕量級的開源專案snoopy，特點是輕量化、非常的靈活，可以只對你想要的進行設定，缺點是不能對靜態編譯的檔案產生作用。最後一個是osquery也是基於Auditd，它基於的是Auditd一套內建訊息機制做的，特點也是多平臺、廣泛。

前面大概講了那些產品，如果把每一個產品都拿出來，甚至一些商業軟體都拿出來做分析研究的話，那麼這個產本太高了。Auditd是工作在最底層的，就是說核心訊息的。Osquery是基於同一套Auditd的訊息，Ossec是基於查詢Auditd日誌，所以他們之間的交集是依賴關係。也就是說Osquery和Ossec依賴於Auditd。Snoopy雖然沒有依賴Auditd、而是用過載庫函式，但是一樣最後回到核心系統呼叫部分來。既然Auditd是總的突破口，我們就以它為研究物件來詳細的瞭解。Auditd是Linux提供的一個日誌審計的服務，優勢在於管理員可以非常方便透過自己的軟體包來安裝和配置。左邊的Open /etc/passwd是我們經常做的，下面的EXECVE是執行uname。現在我們在一臺Centos上配置一套環境，第一步先裝好，第二步把Auditd給啟動起來。第三步，我們建立一條規則，這一條規則是針對64位的程式。UID等於48，這個是我的實驗環境apache使用者的UID，監控的系統呼叫是EXECVE。設好了以後，我們可以看到下面執行的ID命令被忠實的記錄下來，執行的命令是哪一個，有幾個引數，然後命令的路徑和命令執行時候的當前目錄，就是CWD。

對於日誌型別，我們要思考突破方向，主要有四個方面。

    

突破方向：

    1.刪改日誌記錄。對產生的日誌記錄進行刪除或修改。這個日誌已經產生了，我們把其中關於我們自己的東西進行刪除，類似於提權成功之後刪除apache的訪問日誌是一樣的。

    2.停用日誌服務。停止審計日誌服務的程式或使他拒絕服務。比如：裝了Auditd這種東西，我們把這種服務日誌停掉、或者我們有某些漏洞達到“拒絕服務”的效果，讓這個日誌服務不工作。

    3.規避日誌記錄。尋找逃避記錄的規則，類似於WAF繞過。

    4.汙化日誌記錄。使審計日誌記錄不到有價值的資訊。

    

就是說日誌雖然記錄了，但是被我打上“馬賽克”。打上馬賽克之後，即使是人工稽核的話，也只能知道有人做了一些操作，他已經走了，但是不知道他幹了什麼，也不知道他到底成功了沒有。然後在我們設定的環境裡面，對於第一點“刪改日誌”我們是沒有許可權的。絕大多數的Webshell都是執行在www-data、apache等使用者下，不具有root許可權。第二個是停用日誌服務，不具有root許可權，沒有已知的相關拒絕服務漏洞。規避日誌記錄，沒有預設的豁免規則。像Auditd這種純粹依賴於自身的系統呼叫的這種非常穩定、漏洞是非常難找的。然後第三個，規避日誌記錄，沒有預設的豁免規則。最後一點，汙化日誌記錄。因為安全產品是透過對這些日誌進行規則的匹配，甚至一些機器學習的東西來發現的。我們把日誌塗黑了之後，這種警告就會失效。

    

回憶一下剛剛我們Auditd產生的日誌，主要有我們要執行的命令路徑，就是我們執行什麼，然後我們給它引數是什麼，兩個部分來組成。我這裡進行日誌汙化，也分成兩個部分分別來解決。第一部分就是執行路徑，我採用的方法是記憶體執行。然後引數的一部分，是引數汙化。首先第一部分，記憶體執行。要用記憶體執行這個主要用到的系統叫memfd-create，這個系統呼叫的作為是建立一個匿名檔案。如果你對“匿名檔案”概念不太理解的話，可能絕大多數人對windows要熟悉一點，windows就相當於記憶體預設檔案、你可以這麼理解、但是不等同於。它有兩個引數：一個是匿名檔案的名字，這個名字不重要。比較重要的是第二個引數，就是建立檔案的時候給檔案一些屬性。整個系統呼叫返回的是一個檔案描述服務，就如同我們開啟一個檔案、Linux上面開啟一個檔案，我們有Open或者是訪問網路系統描述符一樣。比較重要的是Flag裡面，因為最後要可執行檔案。所以我們要在flag裡面加上MFD-CLOEXEC標誌。最重要的系統呼叫介紹完了，就可以得到一個基本的流程圖（圖）。第一步，我先使用memfd-create建立一個匿名檔案，再把這個匿名檔案的大小進行分配。分配好之後之後再把bin/id這個ELF檔案寫到匿名檔案、也就是寫到記憶體裡面。這裡值得注意的一點，這裡寫的檔案是本地磁碟的檔案，但是它其實不僅可以是本地磁碟，還可以來自於別的地方，最常見的場景就是我們在做滲透的時候，如果要下載一個東西，下載我們自己的ELF檔案到記憶體裡面，必然我們要使用一個高信譽的域名。比如：百度雲盤這樣的高信譽的域名，作為一個圖片傳上去之後，然後拉回來解碼寫進去。也就是說，這個地方是靈活的，它可以來自於任何地方。而不管你這個檔案；不是說我這個檔案必須要有可執行的許可權、這個不需要，來自於任何地方都可以，因為我們在memfd-create的時候給了相應的屬性。我們知道在Linux每一個檔案描述開啟以後，都會有自己的/proc/self/fd下面建立一個數字命名的檔案，這個檔案在這個地方是可以直接使用Execve系統呼叫。bin/id抽取一個東西，相當於對映到程式的proc/self/fd/N，然後再execve執行。

    

可以看到同樣是一個Auditd的日誌記錄下來的內容，在第一個引數的位置和路徑的位置，同時這裡也反映執行的命令bin/uname -a，這個地方引數並沒有解決，這是我們接下來的第二個部分，就是引數汙染。“引數汙染”在比較長的一段時間內，都讓我一籌莫展。但是後來Cs3.13給了我很大的其實。Cs3.13帶來一個新的特性，叫作“程式引數欺騙”。它的作用是什麼呢？可以讓Windows建立程式的日誌，只能記錄到一些虛假的引數。這裡所謂的“虛假”，就是一些無意義的字元。Cs3.13的特性是怎麼讓這個東西工作的呢？首先它用一個虛假引數建立了一個子程式，但是這個子程式使用掛起的標誌位，讓這個程式是掛起的狀態。我們如果調過Windows程式就知道，我們的偵錯程式開啟一個EXE之後，那個就是掛起的狀態，就是在開始的狀態停住了。掛起之後再透過ReadProcessMemory和WriteProcessMemory修正引數。接下來恢復子程式執行。我呼叫CreateProccess啟動一個程式，這個API已經返回了。API返回之後，Windows的建立程式日誌也完成工作了。它說：你執行的命令我記錄下來了，我的工作已經完成了，接下來的工作跟日誌服務就沒有任何關係了。所以透過這種“暗度陳倉”的方法，Cs3.13成功了。

    

我們要在Linux上面借鑑這個東西，實際上我一查還比較麻煩。因為Linux的execve系統不提供這種功能，同時也沒有庫函式提供這樣的功能。甚至我搜尋資料的時候沒有一個第三方的庫完成這個功能，但是如果我們把上面提到的“掛起程式、搜尋記憶體、寫入修正記憶體，把這看作自動化的程式除錯的話，那麼Linux有一個ptrace系統呼叫是非常完美的選項。

為什麼說它是一個完美的選項？有下面三點：

    1.穩定易用，由系統呼叫提供。

    2.支援廣泛，大多數發行版本支援。

    3.成熟用例，知名偵錯程式GDB。

    

關於系統呼叫更詳細的，可以看官方文件。我PPT裡面，只列了一些我需要的功能。主要有：TRACEME，獲取子程式控制權。我啟動的子程式狀態，要給我掛起來、我要控制它。第二個是GETREGS，獲取暫存器值。第三個是PEEKTEXT，它是把像指令地址讀取資料。第四個是POKETEXT，寫入資料。然後是CONT，繼續執行（resume）。再下一個是放棄控制權，DETACH。最後一個是單步執行。有了對API非常深的認識了之後，整個流程就出來了。

    

引數汙化：

    1.除錯子程式。

    2.虛假引數啟動程式。

    

啟動完了之後，我們的對手Auditd已經把虛假的引數進行了記錄。也就是說，跟Windows的日誌服務一樣，它說：我的工作已經完成了。他的工作完成了，我們的工作並沒有完成。接下來，控制子程式的執行。透過單步執行的方法，一直找到執行這個程式的入口點。找到入口點之後，然後我們修正引數，在記憶體裡面把這個引數重新修正回我們想要傳遞的引數。修正完了之後，我們再呼叫把自程式繼續跑起來。我對Linux裝載器，把一個程式裝載開始程式的狀態不是特別的熟悉，所以我才需要單步執行一直找到入口點。因為在入口點的位置有引數傳遞進來，所以那個位置是我最容易找到引數記憶體地址的地方，並不是說，如果你自己要做這個功能的話，我必須要這麼做。不是這個意思，我的這個圖是因為我的水平差一點，沒有辦法在裝載期開始的時候找到引數的記憶體地址。如果你能很快的透過在裝載的時候找到，就不需要這一步了。這一點專門提出來講，是為了規避後面會提到的一個問題。有了這個流程之後，我們繼續把兩個Demo給連線起來，形成了我們完整的一個Demo。可以看到下面（圖）apache使用者執行的一個命令之後，可以看到所預期的有uname-A地方的值，這個時候我們的Demo順利的完成它了使命，把執行的路徑和它的引數都打上了馬賽克。

    

Demo。我們紅隊在持續做任務的時候，不可能拿一個Demo就上去弄，因為我們不可能為每一個命令編一次程式碼。所以必須要提到這個“武器化”，“武器化”我選擇了一個最常見的動作，我們要反彈一個Shell。現在我們要把Bash原始碼拿出來，然後把記憶體執行和引數汙化兩個技巧以補丁的形式打到Bash原始碼裡面，重新變異生成一個Shell，然後再把這個Shell繫結到埠上面，這樣就形成一個執行的每一個命令都使用了這兩個技術。下面是武器化更詳盡的細節，左邊是Bash原始碼，下面是execute-cmd.c，這個檔案實現Shell-execve函式，右邊是libptrace這是我把之前兩個Demo結合起來做的靜態庫，這個靜態庫實現的execve2，我們把系統呼叫execve的地方換成我自己的execve2就完成了這個簡單的包裝了。

    演示程式碼跟libptrace庫程式碼都在我們奇安信的github上可以下載，有興趣可以下載一下。

    接下來就是展示我們的效果，我們要把首要的三個產品；因為Auditd的日誌已經看到效果了，我們要把三個產品的效果進行展示。首先第一個登場是osquery 臉書的開源工具，左上角是反彈Shell，在裡面執行簡單命令的一個過程。右下是osquery提供的一個關於select查詢。Path這個欄位已經全部變成了memfd，這個地方有點不一樣，但是不影響，因為全部變成統一的一個東西。然後下面的是snoopy，snoopy是工作在使用者層的，自然也逃不過我這個是基於欺騙核心系統呼叫的方法，我工作的比它更底層。右下角是透過NC在反彈Shell的時候還能看得見的，之後就不知道是執行的是什麼。接下來是ossec，ossec可以看得到裡面的一些引數、路徑，也變成了我們預期那樣。在這種情況下，ossec規則和規則匹配聯動的一些報警措施就會失效。

    

這三個產品，都已經完全被攻破了。

    

然後接下來要說的，是：這個世界上沒有完美的技術。接下來，講侷限性。侷限性主要有三個方面：1.隱蔽性，就是說：我在低許可權的情況下，除非我在後續的操作當中成功了。否則我在低許可權情況下，只能把日誌打上馬賽克，但是我不能讓它完全消失，這算是一個先天的缺陷。2.相容性。回顧之前引數汙化部分的運作原理，是透過掛起程式之後再進行記憶體修改，相當於預設的除錯指令。我們知道Linux有非常多的發行版本，絕大多數的EFL裝載器的標準是一樣的。但是也不排除有少數的發行版本標準並不一樣。或者是說有的程式在編譯的時候，加了一些不常見的flag。這個可以透過程式碼調優，來擴大相容面積。3.執行效率。因為我們在執行之前、子程式執行之前進行了一些包裝，比如：我的程式碼裡面就有單步執行的過程，到入口點的一個過程。這在感官上，就降低了執行的效率。我在執行的時候就發現，有了這個可能會慢兩秒鐘。這個東西的解決方案，就是去掉除錯一步，對裝載期子程式記憶體環境足夠非常熟悉，可以在掛起的時候就完成引數的修改，這個是沒有問題的。我也非常期待有同學給我分享一下，直接在裝載初起掛起的狀態就把引數修改過來的方法。

    

我的議題就到這裡，謝謝大家！

圖南：GraphQL安全指北

圖南：大家好！非常感謝大家能參加紅隊分論壇，到第三個議題了，還是人滿為患，非常感謝。我今天講的議題內容，主題是“GraphQL安全指北”。我先做一下自我介紹，我叫圖南，大家也可以叫我“南哥”，是奇安信A-Team的安全研究員，曾經我是一名程式設計師。可能在座都是做安全相關，比如：漏洞挖掘和滲透測試之類的工作。我覺得我之前做的工作，我是漏洞的生產者，所以我自稱為：給大家提供漏洞來挖的這麼一個人。我的郵箱是bibotai@qianxin.com，可以透過這個郵箱聯絡我。我分享的主題和前面兩個不太一樣，前面兩個是攻擊思路，攻擊思路也非常棒。我是從研究員的角度，從全方位的角度剖析“安全”的問題。在開始之前，我先說一些題外話。

    

這個議題是由我和獵戶攻防實驗室gyyyy共同完成的，當時我是在我老東家寫GraphQL程式、也就是說做開發工作、他也做一些GraphQL相關的開發工作，順帶做一些安全的研究工作。我們倆因為搞同一個東西，然後就一拍即合，說：有空看看安全問題。然後就覺得這個方向蠻好的，然後就寫了一篇文章叫《GraphQL安全指北》，這篇文章大家可以在網上搜到。我這個議題是根據那篇文章稍微做了一些修改，然後呈現給大家的。其次議題中的後端原始碼，是以Node.js為例。但是現在的主流語言如JAVA等各都可以支援GraphQL開發。

    

我開始正式介紹GraphQL。在介紹之前，我請大家看兩組HTTP的請求。第一組，我們可以發現大家應該非常常見，左邊是一個GET請求，右邊是一個POST請求。請求內容和請求體，大家在滲透測試和漏洞挖掘過程中經常會遇到。下一個請求我覺得可能在座的各位有的人已經在滲透測試的時候遇到過類似的請求了，只不過可能有的人不知道是什麼東西，有的人知道。這種請求就是GraphQL請求。我大致說一下它的特點，首先我們可以看到它是單路由的狀態。也就是說，兩個請求用了同一個路由，也就是GraphQL的路由。

    

有些人就說：GraphQL應該是以後Web API主力，也有人說GraphQL最終會代替RESTful成為一個新的Web API。我覺得GraphQL已經進入了我們的視野，所以我覺得詳細的瞭解一下它也是非常必要的。在正式對GraphQL下定義之前，我們先看一下現在已經使用GraphQL的大客戶們。首先以Facebook為領頭，它是GraphQL的開發者和推廣者。有Twitter等大廠，還有Airbnb等等。GraphQL API也會給大家提供一些便利性，比如：產業限制，可能會更少一些。

    

我現在開始真正的對GraphQL下一個定義。GraphQL是由Facebook創造並開源的一種用於API的查詢語言。正如圖上展示的那樣，可以透過它語言的形式描述你想要的資料，然後請求你想要的資料，然後得到可預測的結果。我再用官方的文案去描述一下GraphQL的特點：首先第一個特點，請求您所要的資料不多不少。我們大家可以看這個動圖。我在左面請求中只要加一個欄位，右面的響應中就會多出來一個欄位。我在左面響應刪除一個欄位，右面的響應也會少一個欄位。也就是說，前端想要什麼就來什麼，不用關心我拿到我不想要或者我拿不到我想要的，這就是說請求你所要的資料不多也不少。第二個是獲取多個資源，只用一個請求。傳統的API的是透過入口端組織資源的，比如：這個例子，在普通的API的時候要分成兩個請求。這裡可以透過一個資源擴充套件到另一個資源。比如：我請求Blog的時候拿到作者資料，新增一個作者資源，新增相關的欄位就可以拿到一個它的資料。第三個特點是描述所有可能的型別系統，從這張動圖我們可以看到，基本上每一個欄位都有其自己的型別。比如：常見的像type裡面的型別，這裡面author是我們自己定義的型別，關於這個型別系統我後面會繼續介紹，大家現在不太瞭解也沒事。後面我就開始說GraphQL核心的組成部分：型別Type。用於描述介面的抽象資料模型，有標量和物件兩種。物件由Field組成，同時Field也有自己的Type。第二個組成部分是Schema，用於描述介面獲取資料的邏輯，類比RESTful中的每個獨立型別URL。一個GraphQL Schema中的恩樣本的元件對比型別。Query是用於描述介面的查詢型別，有查詢、更改和訂閱三種。Resolver用於描述介面中的每個Query的解析邏輯，部分GraphQL引擎還提供Field細粒度的Resolver。

    

我覺得只看概念，可能還讓沒有接觸GraphQL的人會有一些模糊，所以我後面展示一個非常簡單的示例。這是一個非常簡單的GraphQL伺服器的組成部分，我們可以先看最上面我框住的最大的部分，那個就是一個type定義，裡面描述了要查詢資料的形狀，並且指定了GraphQL伺服器獲取資料的方式。Schema包含在Type中，Schema的最基本元件就是物件型別。下面大框裡面的小框就是Query是所有GraphQL查詢的根。下面的Resolver定義的是用怎樣的技術方式從剛才定義的Schema中取出相應的資料。下面就是ApolloServer，這個GraphQL伺服器就搭建完成了。

    

我再去對比一下常見的RESTful介面和引數型介面。前兩行是引數型介面，把想要傳遞的後端資料帶到URI引數介面，後面是RESTful介面。這兩種只是請求的樣式不一樣，得到的結果是一樣的。並且共性，就是我每次請求一個資源，需要傳送一個請求。GraphQL是單路由，其次我們可以看到請求體，我想要什麼資料，可以把這個資料組織出來，然後得到我想要的響應。這樣的話，就會非常靈活。大家可以記住，就是左邊那個GraphQL請求的樣子，如果以後見到這種樣子，就可以認定它為GraphQL請求了，也就可以用到我後面講的一些安全知識做一些漏洞挖掘和其它的一些研究工作了。

    

我又做了一個動畫去展示一下RESTful和GraphQL的區別。首先我們可以看到這個動畫反映兩點：第一點，首先我發兩個請求，這是非常明顯的，有“1”和“2”兩個請求。然後其次是我在請求Blog的時候拿到的是Blog全量資料。

而GraphQL做到了我想要什麼欄位拿什麼欄位。

    

前面我介紹完了GraphQL的相關基礎知識，我後面開始講GraphQL存在的一些安全問題。在開始講安全問題之前，先給大家展示一下，我們可以看到裡面的漏洞，可以注意到獎金還是非常高的。如果我們現在可以挖一些GraphQL漏洞的話，我覺得應該可以賺一筆可觀的數額、我覺得是這樣。首先我講一下第一個安全問題的第一點，就是身份認證與許可權控制不當的問題。其實GraphQL和其它的API技術是一樣的，需要進行身份認證和鑑權。GraphQL官方是推薦把身份認證和鑑權放在業務邏輯層的，我們可以看到這個圖，就是他把鑑權的邏輯放到了業務邏輯層。我們可以看一些例子，這還是我從Hackone裡面找的一些例子，評分是9.8，還是比較高危，這應該算是一個嚴重漏洞。可以看到獎金是5千美金，還是非常可觀的收入。我把這個詳細的用紅線劃出來，現場展示螢幕可能看不太清，所以我給大家翻譯一下。這個檔案就是在JavaScript檔案中暴露了一個GraphQL介面路徑，透過這個GraphQL介面路徑在未經身份認證的前提下查詢到了很多關鍵資料。第二個例子是星巴克的，一個獲取使用者地址簿的GraphQL查詢語句可洩漏部分使用者地址簿資訊。這是一個明顯的許可權控制不當的問題。

    

對於GraphQL引領者或者開創者來說，它是不是也能逃過一劫呢？我覺得不是的，我已經看到了很多Facebook相關的漏洞。比如這個例子，它是一個不合時宜的授權導致使用者可以越權切換別人的預約服務的開關。這個我也把它歸類為，許可權控制不當的問題。雖然這個漏洞是低危，但是也是達到了一千刀的可觀收入。

    

我們看了這麼多的例子，有很多身份認證和許可權控制不當的問題。我想說一下就是為什麼GraphQL會頻繁發生這些身份認證無效和許可權控制不當的問題？我總結為三點原因：

    1.GraphQL多了一箇中間層，對它定義的查詢語言進行語法解析執行等操作。

    2.Schem Resolver等種種定義讓開發者對它的存在間接增加了複雜難度。

    3.單路由形態，透過不同的field查詢得到不同的結果，開發者需要對每個field的resolve做許可權控制。

    

在我丟擲問題之後，提出一下解決方案。我在這張圖展示的就是一個“裸奔”的GraphQL介面，客戶端可以透過請求拿到GraphQL裡面的伺服器裡面的資料，這就是一個非常常規的狀態了。駭客或者是惡意攻擊者，也可以透過構造一個請求去拿到一個返回的資料，這就是沒有任何防護的GraphQL伺服器。在我提出GraphQL伺服器認證無效的解決方案之前，我們先回顧一下RESTful是怎麼認證的。GraphQL解決方案，我覺得也可以按照RESTful的思路去做。比如：我也先讓他請求一下RESTful伺服器，然後讓它訪問token，這時候客戶端帶著token請求伺服器，然後返回結果就OK了。這也是官方最推出的做法，但是前提是我們應用的服務架構，必須是有支援RESTful的。

方案二：在GraphQL內認證。這是我幫老東家做的一個方案，因為我們之前走的比較激進，因為GraphQL各種好處。我們當時沒有其它認證伺服器，也沒有一些RESTful的介面，這樣只能在GraphQL實現了一個登入的邏輯。看這張圖，就是客戶端先去GraphQL伺服器請求token、返回token，然後帶著token請求伺服器，然後返回就可以了。這裡面展示這一套方案的實現程式碼，我們先看右面的程式碼。右面是一個登入完返回物件的一個，我們可以看到使用者可以帶著使用者名稱和密碼去登陸，登陸完之後返回的結果裡面帶著token，這時候再請求GraphQL伺服器。左面是整個認證的流程，認證完成之後需要對ApolloServer就是GraphQL伺服器做一個對應的修改，也就是說在這裡面我透過token獲取我的使用者，然後把使用者塞到GraphQL伺服器配置中，在RESTful中進行細粒度的健全和授權認證解決方案。

    

因為GraphQL的這些特性，導致它如果出現認證失效或者許可權控制不當的問題之後，會帶來一些更多的後果。我把它總結為併發症。首先我說第一個併發症就是內省，在我們熟悉的普通的那些RESTful和引數性介面要先做一步，就是資訊收集。我要知道這個裡面大致有什麼操作，比如：有什麼路由，都能執行什麼操作，都大致能返回什麼結果。這個時候我可能需要得到一個API的全量資料，但是之前的RESTful和引數性介面，我只能猜介面長什麼樣子，所以我可能就用到一些代理、甚至爬蟲，還有爆破的一些方式去拿到我外圍API大致的全量資料。但是由於現在我們已經知道了，已經有很多的廠商在用一些虛擬DOM技術，比如：VUE等去做一些前端，導致我們可能用爬蟲，還有用代理都不太好使了，這時候我們可能要用一些更高階的技術如Headless去抓全量資料。但是對於GraphQL如果我們想要獲取它內部資訊的話，可以完全省略這一步，因為它有一個內省自檢機制。首先GraphQL自帶一個強大的型別自檢的機制功能，可以看到透過schema可查詢所有的可用物件，透過type查詢指令物件的欄位。

我後面展示一下schema的用法，這張圖展示的是我用schema查詢我所有定義查詢的schema的情況。

    

下面我展示的是我透過type的查詢，查詢到所有blog裡面type的情況。接下來這張圖展示的是我用GraphQL開源的內省工具、輸出的詳細文件，我們可以看到裡面詳細的Query文件，包括：Query裡面所有的定義，裡面要傳什麼引數，包括註釋都會寫的很清楚。這其實是一個對開發者非常友好的功能，因為開發者可以不用再去維護一個介面文件，他可以直接開發完GraphQL API之後透過內省文件呼叫伺服器就OK了。這個同時也給安全埋下了一個隱患。

    

說完了第一個併發症，我們可以看一下第二個併發症。這個併發症是我們自己定義的，叫“非預期欄位”。我給它定義如下：同一個介面給不同的許可權職能、屬性、決策使用，正常情況下每一個角色只查詢介面的一部分欄位。也就是說，它肯定不會兩個同時使用。舉個例子，就是我要查詢的是一個三個欄位，有兩個需求。第一個需求，查詢的是A和B。然後第二個需求，查詢的是B和C。但是如果這個介面被惡意利用的話，比如：一個惡意攻擊者可以去用“內省”把介面裡面的內容都“內省”出來，然後把ABC都查出來，這就是一個不對欄位許可權的概念。所以如果不對欄位許可權控制，即可被利用產生非預期欄位。

    

GraphQL容易查詢出非預期欄位的原因：

    1.GraphQL是根據前端請求的欄位進行資料回傳。

    2.後端Resolver的響應包含對應欄位即可。

    3.後端欄位擴充套件對前端無感知無影響。

    

我為什麼定義為“非預期欄位”是因為我覺得它不只是一個資訊洩漏的問題，它還有可能造成一些其它的問題。

    

我現在開始舉例子：假如有下面的一個需求。假如有一個開發者叫小明，小明接到了兩個需求。第一個需求，管理員可以檢視使用者的相關資訊，需要檢視的欄位有使用者名稱、郵箱、建立日期。第二個需求，是運營人員需要統計使用者資料、輸出報表，需要查詢資訊有使用者名稱、身份證號、登陸地點。我們可以發現這兩個需求應該是在開發過程中經常會遇到的，第一個需求它可能是一個系統級別的需求，它需要把這個功能做到系統中，然後給管理員檢視。第二個需求，運營人員要做一些活動之類的，他就直接跟成員說：小明你給我導一份資料，資料裡包含這些資訊就可以了。

    

小明已經開始寫程式碼了，我們看到他搞了一個叫UserInfo的Schema。這種設計其實是GraphQL推薦我們去這樣設計的，因為我們可以把一些需求去合併，然後去設計出來一個介面去解決多個問題。這樣的話，也方便開發去維護程式碼，也方便專案推進。但是我們會發現這個身份證號和登入地點並不是一個預期欄位，也就是說這兩個“點”其實我是不希望讓除了運營人員其他人看到的。我這張圖就展示了一下，就是這兩個需求，還有被惡意利用的情況。

    

首先說第一個需求，就是在管理員需求。管理員透過這個查詢，他查詢到了他想要的內容。然後是運營人員透過這個查詢，查詢到了他想要的身份證號和登陸地點的這兩個欄位。但是如果這個被惡意利用或者被駭客利用，可以構造這樣的一個請求，就是把裡面的欄位全部包含起來，造成了非預期欄位洩漏的情況。我覺得非預期欄位還有一個併發症，就是我覺得他倆是並行的，就是廢棄的欄位。廢棄的欄位也是非預期，但是我把它放在三類。GraphQL為了欄位的刪除提供了一個廢棄的解決方案，如果一個欄位不再使用，可以標識“欄位為廢棄”，但是如果不對廢棄欄位進行修改，依然可以查詢到廢棄欄位的內容。也就是說，我們可以發現這也是一個對開發非常利好的操作。比如說他有一個欄位，他不想要了，然後他就可以標識為廢棄就好了。然後我繼續舉剛才那個例子，架設小明已經意識到了剛才那個資訊洩漏的問題了，就是idCardNo和loginLocation是非預期欄位，他發現GraphQL文件中有廢棄欄位可用，就把這兩個欄位廢棄並標識為安全問題，標識完了之後，如果他不對Resolver做修改的話，仍然可以透過內省暴露廢棄欄位的。這裡面有一點，就是在我們進行一些安全研究和漏洞挖掘過程當中，我們會發現有很多的安全問題是利用了開發、測試，還有運維的一些盲點去產生的。如果你問我：為什麼會有這些盲點。我只能說，他們可能在平時的一些開發工作中根本就遇不到。

    

如果小明沒有仔細閱讀那篇GraphQL的文件，或者說他沒有仔細閱讀“內省”章節，他一定不知道透過給field裡面傳一個includeDeprecated欄位並設定true就可以拿到所有廢棄欄位。

    

由於開發者小明沒有對Resolver做任何修改，所以廢棄欄位仍然可以查詢。我們可以看到這兩個欄位已經標黃了，提示這兩個是廢棄欄位，但是實際上我查資料沒有任何的問題，因為我後端的資料Resolver是沒有更改的。

    

剛才講了一系列許可權和授權相關的漏洞，我現在開始說一下GraphQL注入，我這裡也引用一下qyyyy的金句：有語法就會有解析，有解析就會有結構和順序，有結構和順序注入。

    

再舉個例子，小明是前端開發工程師，構建了這樣一個前端的GraphQL查詢依據。（圖）如果駭客用欄位拼接，我們可以發現語句結構就發生變化。這個當中多了一個hack物件，hack物件又對user進行了查詢，傳入username引數，值是admin意圖很明顯，就是想把管理員的帳號、密碼和相關資訊查出來，這就是GraphQL注入。GraphQL注入如何解決？幸運的是，它的型別系統可以定義到每一個欄位的具體型別值。也就是說，可以作為天然的屏障幫助我們過濾一些惡意的注入。但是在前端、在官網上也是不建議大家用字串拼接寫，所以我們看到解決方案程式碼，第一行是一樣的，第二行都寫了一個引數，並且在下面把name傳到username引數去，然後把client和query直接傳到後端，也就是說最後拼接成GraphQL過程直接交給後端，避免了GraphQL注入。

    

第三個問題就是拒絕服務。在我做安全研究的過程當中，我會發現有很多的物件巢狀的存在，比如：A物件巢狀B物件，B物件巢狀A物件，這樣互相巢狀，我可以無窮無盡的展開。如果那個物件裡面是一個指令型別而不是引用型別，就很有可能造成諸如OOM之類的問題。OOM其實就是一種拒絕服務，GraphQL也是允許物件間的巢狀關係存在的。如果我們不對物件的巢狀深度進行限制，就會被攻擊者利用進行拒絕服務的攻擊。

    

最後一個例子，還是小明。小明已經完成了剛才我展示了很多遍的系統，完成之後就有一個需求完成了。需求一，查詢所有文章的時候，返回內容中包含作者相關的資訊。這個時候突然又來了一個需求，就是說：查詢作者的資訊，返回內容中包含此作者所寫的所有文章。其實大家可以看到，這個需求也是一個非常常見的需求。比如：我想一下先有的一些部落格，點一下作者的頭像就能列出來這個作者所寫過的所有文章。這個時候小明又很快的寫程式碼去了，然後我們可以看到右面的Query是我展現之前Blog查詢的。這樣就達成了剛才需求二，就是查詢author時候返回他所寫的所有文章。這也是可以看出GraphQL的優勢，可以透過改少量程式碼完成。在blog查詢的時候巢狀author，在author查詢的時候巢狀blog，這樣無窮無盡。

    

對於拒絕服務的解決方案，我這裡只提一點：限制查詢的深度。這個程式碼裡面展示的是我當時用graphql-depth-limit包，限制十層。在設計GraphQL介面的時候，應該避免出現巢狀問題，這是一個程式設計或者是一個框架方面的問題。其實在官網上還有一些其它的解決方案，比如：限制一下查詢的複雜度。總之就是解決方案，不僅限於查詢深度。

    

在結束之前，我想丟擲我的兩個觀點。第一個觀點，我覺得GraphQL只是一個介面。它和其它的Web API的介面是一樣的，都有可能透過一些對外界資料的接收，然後影響了它的結構、影響了後端，造成了一些安全問題，這個就是大家都有的共性。我覺得我們並不能要求GraphQL去幫我們做很多的安全問題，這個更多還是一個安全意識的問題。所以我覺得它還會存在諸如：XSS、SQL隱碼攻擊、"NoSQL隱碼攻擊、CSRF、遠端命令執行。右面的圖是展示GraphQL可能會存在的SQL隱碼攻擊和NoSQL隱碼攻擊的。紅色背景的字第一行是SQL隱碼攻擊的情況，第二行是NoSQL隱碼攻擊的欄位。關於NoSQL隱碼攻擊可能有一些人不太瞭解，可以看我另一篇文章《NoSQL知多少》。

    

我想丟擲的第二個觀點，是我本次演講只是給大家拋了一個磚。至於以後還能引出來什麼樣的玉？我希望大家能一起來參與一下GraphQL的研究。所以我覺得關於GraphQL研究的點可以有很多，比如：我們所知的GraphQL引擎，有各種語言實現的。不同語言有不同的語言特性，不同的語言特性會不會造成一些新的問題？這個還是我沒有研究到的一個方面。還有一個就是它引擎內部執行流程，我也沒有仔細去看。既然GraphQL作為一個語言，它一定有語法、也一定有解析。那麼，它的語法和解析的一些過程，會不會存在一些問題？比如：我們所知道的有很多的漏洞都是因為語法解析的問題，造成了一些非常嚴重的漏洞。比如：命令執行。這一塊，也是我沒有涉及研究的。還有就是對於一些資料外部傳的內部校驗和資料編碼的過程，這個也是我還沒有涉及到的。所以我覺得我今天的演講就到這裡，但是希望大家可以後面繼續加入到GraphQL研究當中。

    

謝謝大家！

n1nty：紅隊行動，橫向移動與IDS對抗

大家好，我今天帶來的議題叫作“橫向移動與IDS對抗”。首先做一個簡單的自我介紹，我來自於奇安信A-Team。橫向移動本身是一個比較寬泛的概念，我標題裡面說的橫向移動其實指的是某一種具體的行為：當駭客已經透過某些途徑進了內網以後，已經透過一些方法獲取到內網Windows伺服器帳號密碼以後，透過這些賬與密碼去遠端控制目標伺服器的這麼一個行為。後面的內容會跟大家分享我收集到的一些網路上IDS的規則，這一類IDS規則基本上都是用來檢測這一類的行為，跟大家分享這一類IDS規則的缺陷和繞過的方式，以及我自己總結出來的我認為是比較好的方法論。我今天說的IDS指的是網路層面的IDS，不包括主機層面的IDS。

前面說到了具體的行為就是當駭客已經有了帳號密碼以後，需要遠端利用這些去控制Windows伺服器。通用有幾類方案可以達到這個目的： PSEXEC 類、計劃任務類、WMI類、DCOM類和其它類（RDP、WINRM）等。 我今天的演講內容主要覆蓋前四類而不包括其他類。

PSEXEC 類、計劃任務類、WMI類、DCOM類，圍繞這四類橫向移動方案已經出現了很多不同的工具。但是，無論這些工具本身在使用上有多大的差別，只要他依靠的是那四類方案進行橫向移動，那麼它們就有一個共性：它們所依賴的下層協議是 MSRPC。

    

MSRPC是微軟的遠端過程呼叫協議，是基於DCE/RPC改良出來的，跟所有的RPC 類的協議都一樣，其目的是為了實現跨程式的過程呼叫。“過程”可以直白理解成函式。後面我會講到跟這個協議有關的比較大量的理論知識，所以大家跟緊我一點。

    

MSRPC協議的作用。同一個作業系統上兩個不同的程式A.EXE和B.EXE，如果 A.EXE 想呼叫 B.EXE 中的某一個函式，那麼可以透過 MSRPC 進行呼叫，並且可以拿到這個函式的返回值。這是在同一個作業系統上面執行的兩個不同的程式。其實利用 MSRPC 還可以實現跨機器的遠端呼叫，比如執行在機器 1 上的 A.EXE 可以利用 MSRPC 去遠端呼叫執行在機器 2 上的 B.EXE 中的函式，並且拿到呼叫結果。現在我們知道了MSRPC協議是個什麼東西，以及大概的功能是什麼。我們重新審視一下前面說到的四類橫向移動的方案。假如攻擊者、駭客用了這四類方案中的任何一種來對遠端機器進行橫向移動操作的話，本質都是利用了MSRPC協議對要打的機器所暴露出來的敏感函式進行呼叫而已（敏感函式指的一般是具體遠端程式建立、遠端命令執行功能的函式）。這個場景下我們可以將攻擊者，也就是發起MSRPC呼叫的這一端稱之為MSRPC客戶端，以及被它打的機器稱之為是MSRPC協議的服務端。MSRPC協議客戶端與服務端到底是怎麼通訊的呢？或者直接的說，當攻擊者、駭客使用這些方案來打另外一臺機器的時候，攻擊者和目標機器之間到底做了哪些互動？我們首先需要知道MSRPC協議的服務端怎麼實現的，我畫了一個流程圖。

    

第一步，服務端需要定義並且實現RPC介面。第二步，實現完以後需要把這個介面註冊到Windows作業系統裡面去。第三步，就可以接收RPC呼叫了。我們首先要知道RPC介面是什麼？前面我們說到客戶端透過微軟RPC的協議呼叫遠端服務端暴露出來的函式，這個說法不是太準確。因為服務端直接暴露的並不是一個函式，直接暴露的是一個介面、介面裡面有多個函式。客戶端呼叫的時候，其實是連線到服務端暴露出來的RPC介面上面，再去呼叫這個介面裡面的函式。對於介面來說有兩個比較重要的屬性：第一個，就是每一個介面都有一個唯一的標識。還有就是介面的版本。用這個圖形化的例子看一下，假如自己實現了RPC的服務端，RPC-Server.exe，定義並實現了右邊這個名為 IPentest 的介面。可以看到介面的名字下面那一串像是隨機字串一樣的東西就是這個介面的唯一標識 IID，以及這個介面裡面一共定義了三個函式： RunCmd，序號0；DownloadFile，序號 1； UploadFile，序號 2。 函式序號的作用就是客戶端在遠端調某一個函式的時候，實際上是透過函式的序號呼叫的，而不是透過函式的名字。第二步註冊RPC介面，註冊目的是為了讓Windows作業系統真正意義上把我們的介面暴露出去。

註冊的時候其實涉及到三個概念。

    1.協議序列。

    我們在註冊介面的時候告訴作業系統，我們希望作業系統到底把我們這個介面以什麼樣的方式對外暴露出去。最常見的一個是純TCP的協議序列，另一個就是基於SMB命名管道的協議序列。同一個介面，可以透過多個不同的協議序列暴露出去的。

    2.Endpoint（EP）。

    EP是跟協議序列強相關的東西，比如：如果這個介面使用的是純TCP的協議對外暴露，這個介面的EP對應的就是某一個TCP的埠號，如果這個介面使用命名管道的方式都要暴露，那麼你的這個介面使用命名管道協議序列進行對外暴露，那麼對應的 EP 就是一個命名管道的名字。當服務端向作業系統註冊RPC介面時，可以自己手動指定一個 EP，也可以選擇讓作業系統幫你隨機生成一個。

    3.Endpoint Map（EPM）。

   

 135埠裡面執行EPM服務。EPM裡面儲存的是Endpoint到某一個介面的對映關係。

    

看完理論知識，再用圖表的方式重新回顧一下。第一步剛才已經定義並實現好了一個叫IPentest的介面，我們希望這個介面被以純TCP的協議序列被暴露出來。EP不自己指定，而是由作業系統幫我們生成一個隨機的埠也充當 EP。最後一步，就是我們需要把EP儲存到EPM， 也就是135埠上執行的那個服務裡面去。第三步，我們RPC服務端就已經做好了。做好了服務端以後，我們需要有客戶端連線到服務端上面，然後來遠端呼叫服務端介面上面的函式。客戶端呼叫服務端有這麼四個步驟：第一步，查詢所要呼叫的目標介面在遠端的機器上是以什麼樣的協議序列被暴露了出來，以及暴露的時候所使用的EP是什麼。第二步，當查到第一步的結果後，使用指定的協議序列以及查到的EP連線遠端機器。連上以後，第三步繫結要呼叫的介面。第四步就可以真正的開始呼叫介面裡面的函式了。

    

還是以圖象的方式看一下，右邊是實現好的遠端RPC服務端。假如客戶端現在需要呼叫RPC-Server.exe，需要先查IPentest以什麼樣的協議序列匯出，以及匯出的時候是用的什麼Endpoint，查到以後以純TCP的方式連線到遠端機器上的33219埠、這是第二步。第三步，它需要繫結到要呼叫的IPentest介面。繫結的操作就是說我要告訴服務端，接下來到底要呼叫哪一個介面的什麼函式，這是繫結的操作。第四步，就可以開始進行函式的呼叫了。

    

簡單的回顧一下MSRPC協議棧，當客戶端透過MSRPC呼叫遠端服務端的時候，所走的協議、所用的埠基本上都在這個圖裡面了（圖）。如果是純TCP 協議序列，那麼下層就是直接的純TCP協議。這個時候客戶端往往連線到服務端所暴露出來的隨機高階口。第二個，如果客戶端使用命名管道這個協議序列來連線服務端介面的話，那麼MSRPC下層就是SMB協議。

    

透過這張圖我們可以看到，Windows作業系統預設匯出了非常多的介面，這些介面理論上都是可以被遠端呼叫的。前面我歸類的四類橫向移動方案，都只是對這些Windows預設對外暴露的RPC介面函式的惡意利用。前面我們說到了一個客戶端要呼叫服務端某一個函式需要經過這麼四個步驟，現在我們切換到IDS的視角看一下。在四個步驟中，每一個節點上，IDS都是可以做相應的檢查，只不過也許檢查越靠前，誤報率有可能會越高。我們來看一下第一個節點上面IDS有可能做什麼樣的檢查？部署在第一個節點上的IDS規則檢查的通常是135這個埠的流量，就是說這個節點上面的IDS規則的工作邏輯一般都是如果發現有人連線伺服器135埠，並且透過這個埠上的EPM服務查詢了某一個已知的敏感介面（裡面包含一些函式可以進行橫向移動，比如：遠端命令執行等這樣的）的資訊時候，IDS會認為你既然查這個，那你後面有可能就要呼叫這個敏感的介面，那麼它有可能會產生告警。工作在這一步的規則我們的對抗思路是什麼？第一點，如果你有一些沒有公開方案使用的是一些目前不為人知的小眾介面的話，儘量不要公開了，自己留著用，一旦公開就有可能被人們寫到這個規則裡面去。第二個，如果你明確的知道你呼叫的那個遠端介面，同時被暴露在了TCP協議序列和SMB協議序列，那麼為了繞過這個節點上的 IDS 規則的檢測，你應該使用基於命名管道的方式呼叫你的那個介面。因為你用命名管道的方式呼叫介面的時候，通常是不需要經過135埠的。135埠主要作用是當你不知道你要呼叫的那個介面被匯出在了哪一個 EP 上的時候，需要透過 135 埠來查詢。如果你的介面在命名管道上，這個命名管道的名字通常是事先預設好的並且是固定不變的，所以可以繞過135這一步，那麼自然基於這個節點上的IDS規則就抓不到你了。

    

現在我們來看一下第二個節點上的 IDS 規則通常是如何工作的。執行在第二個節點上的 IDS 規則，通常是檢查網路中出現的 SMB 流量中的敏感命名管道的名字，來檢測橫向移動。工作的邏輯就是，如果 IDS 發現在 SMB 流量中出現了一個敏感的命名管道的名字，那麼 IDS 認為有人在嘗試連線這個敏感的命名管道背後的那一個敏感的 RPC 介面，此時就會產生告警。對抗的思路，我們要知道一個程式如果用命名管道的方式來將一個介面匯出的話，那麼他是有可能將這個介面匯出在多個命名管道上面的，而不是一個。而且Windows裡面命名管道是可以有別名的，一個命名管道名字叫A，但是作業系統給它配了別名叫B、C什麼的，透過這些個別名我們也可以連線到這些命名管道上面。這種情況下你可以收集常用的IDS規則，可以發現其實很多人檢測某一個橫向移動方案時所寫在 IDS 規則裡面的命名管道名字都是固定一個，不會變的。第二個由於這一步的操作檢查的是透過SMB的方式呼叫遠端介面的方式，如果你知道遠端的介面同時被匯出在純TCP協議序列上，你就用純TCP協議序列去連線這個 RPC 介面，這個時候就沒有所謂命名管道的名字。下面來看一個真實的例子。

    

（圖）這三條規則都是用於檢測利用遠端計劃任務進行橫向移動的行為。他們的檢查原理是一樣的，如果 SMB 流量中出現 atsvc 這個命名管道的名字，就進行告警。所以繞過的思路有兩點。第一點，遠端計劃任務不只是被暴露在了 atsvc 這一個命名管道上，而暴露在了其他的比如 srvsvc 上，我們只需要換一個名字去連線，就可以繞過這三條規則。第二點，這三條規則檢查的都是命名管道的名字，那麼其實遠端計劃任務介面還被暴露在純TCP協議序列上，我們如果用純TCP方式呼叫遠端計劃任務介面，也可以繞過這三條規則。第三個檢查點，Bind介面。這往往是嘗試監查如果發現有人嘗試對已知敏感介面進行繫結操作就報警。第三點對抗的思路，還是如果你自己有一些未公開的方法的話，你就還是自己留著自己用，不要被人們寫進這個節點上的IDS規則。下一個對抗方式，有點像Web滲透裡面的WAF繞過。IDS 在檢查資料包的時候有可能只檢測前 N 個位元組，這個時候我們先傳送多個虛假的 Bind 請求，最終再去 Bind 我們實際要呼叫的那個敏感介面就可以繞過。第四個就是嘗試檢查你真正去呼叫的那個函式，這一步對抗其實總結不出來什麼太好的規律，只是看具體規則之後再去分析。

    

現在我們看一個具體的例子，拿：PSEXEC這一類工具嘗試一下，這一類工具產生的流量IDS看來如何。先看一下 PSEXEC 這一類工具的原理是什麼。Windows上面有一個叫Service.exe程式，這個程式定義、實現並匯出了一套SCMR介面，允許客戶端遠端在服務端建立啟動停止Windows的服務。所以 PSEXEC這一類方案其實很簡單，它透過遠端呼叫SCMR介面在遠端的伺服器上建立一個服務來實現橫向移動。有一點需要提的是這一套介面同時被監聽在純TCP和命名管道兩個序列上。介紹完了之後，我們看一下實際PSEXEC.EXE執行完之後產生的流量怎麼樣。

    

第一步，向目標機器查詢 SCMR 被監聽在了 TCP 協議序列的哪一個 EP 上。第二步，假如上一個查到的是49157埠，自然是以純TCP方式連線49157埠。第三步，發起Bind請求，繫結到要呼叫的SCMR介面。第四步，從流量可以直接的看出來，我們可以看到很多函式的呼叫，建立服務、啟/停服務之類的。前面說到了，客戶端呼叫服務端的四個節點。其實這一塊的PSEXEC.EXE例子就是四個步驟在流量方面的呈現方式。透過這個流量圖，其實我們可以出來一個問題。問題是什麼？我們發現PSEXEC.EXE在執行過程中到底呼叫了遠端機器的哪些函式是可以透過流量直接看到的，這其實是 MSRPC 的加密措施導致的。客戶端呼叫服務端的四個步驟裡面，前三個步驟MSRPC並沒有為前三個步驟提供任何的加密措施。只有最後一步，提供了半遮半掩的措施。假如第四步啟用了 MSRPC加密措施，對於IDS來說，它依然能看到你呼叫了什麼函式，但是無法再看到你給這個函式傳了什麼引數。這就是 MSRPC 的加密機制。

    

我們再來看看Psexec.py和PSEXEC.EXE產生的流量有什麼區別。Psexec.py第一步先建立SMB會議，使用ncacn-np協議序列連線SCMR介面，後續所有資料包經過SMB3加密，IDS無法識別。簡單插播一下SMB3加密功能，是從3.0版本引入的。3.0版本是從Windows2012引入的，而且SMB3.0服務端不強求客戶端必須使用加密通訊，並且多數Windows客戶端在連線SMB3.0服務端的時候也不主動使用SMB的加密，這個影響會在後面說到。我們來對比一下，前面說到了exe版本的Psexec和Psexec.py。PSEXEC.EXE協議序列Ncacn-ip-tcp，Endpoint是隨機高階口，危險係數是“高”，全程流量近乎明文。Psexec.py協議序列Ncacn-np，Endpoint是命名管道svcctl，危險係數：低，目標主機為2012及以上系統自動啟用SMB3加密。高，目標主機為2012以下時全程流量明文。

    

根據剛才對比，我們可以得出來初步的結論：假如你要打的目標機器是2012或者2012以上的機器，你應該優先使用基於命名管道的協議序列的RPC。SMB3的加密功能在Windows預設情況下，多數客戶端，哪怕連的是SMB3.0服務端，也不會主動使用加密功能。如果你的目標是2012以下版本的話，那麼我們就接著往後看。

    

（圖）這條IDS 規則是用於檢測利用WMI進行橫向移動的方案。它是工作在第一個節點上面的規則，原理就是當它發現有攻擊者或者說有人連線了某一臺機器135埠，並且同時流量裡面出現了WMI所依賴的介面唯一標識的話，它就會產生告警。WMI這種橫向移動的方式，最簡單最直接的利用方式就是透過Powershell 或者 wmic.exe，但是這兩種方式都會被剛才所展示到的IDS規則所抓到。 Python裡面有一個非常厲害的庫叫 impacket，裡面有一個叫wmiexec的工具這個可以繞過剛才說的那條規則，但是它帶來的另外一個問題就是我們可以看到在流量裡面雖然繞過了第一條規則，實際上用這個工具執行任何命令的時候，你執行命令是透過明文在網路傳輸的。你雖然繞過了剛才那條規則，但是有可能被工作在第四個節點上的規則給抓到。所以這個時候我們需要對這個工具做一下改造，紅框裡面的程式碼是我加上去的，這串程式碼就是我強行開啟加密功能，開啟之後執行的命令就是加密的。

    

（圖）這個圖片展現的是全是抓利用DCOM進行橫向移動的IDS規則。總結一下它們其實都是工作在第一個節點，以及第四個節點上面。利用DCOM進行橫向移動，這個方法的發明者在首次介紹這個方案的時候用到的程式碼，就是透過 Powershell建立遠端伺服器DCOM物件，然後拿到DCOM物件之後做橫向移動。這種方案會被剛才列出來的那一堆規則裡面的好幾個規則給抓到。同時它還有另外一個問題，就是跟剛才那個問題有點類似，就是你執行的命令是“明文”在網路裡面傳輸的。同樣的impacket 提供的 dcomexec.py 也是利用 DCOM 類的方案進行橫向移動，但是它同樣會被我剛才列出來的一堆規則抓到。而且被抓到的原因是因為流量是明文的，這是它被抓到的原因。這裡你要對這個檔案做一些更改，強制開啟加密，開啟加密以後，流量也加密了，就可以繞過剛才那些 IDS 規則。這個時候我們就可以得到一個相對完整的總結：當你要打的目標機器是2012或者2012以上的時候，應該優先選擇利用SMB命名管道作為協議序列來連線遠端介面的那些工具。Windows上面的客戶端預設不會使用SMB3加密功能來與服務端通訊 ，所以這裡我列出來的工具都是用 Python 寫的。當你要打的目標是2012以下目標的話，你應該優先使用的是那些在MSRPC過程中全程開啟了 PacketPrivacy 身份認證級別的工具，也就是全程啟用了 MSRPC 加密的工具。說是“全程開啟”實際上也只有最後一步是加密的。比如說我們改過的 wmiexec.py以及 dcomexec.py 等。

    

其實完全看你的目標環境裡面的IDS規則怎麼寫的。要是寫的很嚴格，也是有方法可以去檢查出來這些其它方案的。但是我收集了很多IDS的規則，我發現改完之後很多IDS規則就被bypass掉了。

    

（圖）這一頁是跟主題“橫向移動”四個字有關聯的。我們現來聊一下利用DCOM方式進行橫向移動的方案，這種方案應該是在2017年左右被國外的一個安全研究人員首先公開了這個方案。關於到底什麼是COM，什麼是DCOM這個話題比較大，希望各位可以回去自己瞭解一下。我這裡總結了一下人們公開的挖掘出來的可以進行橫向移動的DCOM的方案，這個列表其實在網上可以隨便找到。在我對COM及DCOM學習研究過程中，我發現這些方案都有一些侷限性。首先這些DCOM元件裡面大多數都是Office系列軟體所帶有的，你如果想用裡面有些元件進行橫向研究，要求目標伺服器裝了Office。另外一種，基本上它們通用的問題，就是這些元件都只能夠提供基礎的命令執行功能。我在對於這些進行研究的過程中，我一直在想：有沒有一種DCOM元件可以提供直接的遠端任意程式碼的執行功能？這些已知公開的元件，基本上只能用來執行命令。

    

我們看一下這個，如果你工作在內網滲透第一線，對於這個肯定不會陌生（圖）對不對。它主要的效果就是我們可以利用WMIC來執行任意的VBScript/JScript程式碼。我發現有一個COM 元件提供了跟WMIC相似的功能，也可以執行任意的程式碼。甚至我都懷疑，WMIC內部是透過呼叫這個元件來完成的工作，只不過我沒有印證、只是猜想。下面用一張圖來展示我們可以在本地呼叫這個元件執行任意程式碼，效果就是我透過這一個 COM 元件實現了命令執行的功能，並且拿到了命令的回顯結果，這是簡單的事例。

    

我們現在要講的是橫向方案，對於 XML DOM Document 這個 COM 元件來講，它最大的就是：它不是DCOM元件，不能被遠端呼叫。我們必須找到能夠遠端呼叫的東西才能達到我們的目的。這個怎麼解決？我們可以把一個COM改造成DCOM。當目標COM介面向作業系統註冊了ProxyStub，則實現了此COM介面的COM元件存在被遠端呼叫的可能性。我們具體怎麼去把它由一個COM改造成為DCOM呢？其實如果多看一些資料，這方面的過程並不複雜。我在沒有實踐之前覺得很複雜，但是實際上我研究出來以後，發現你只需要對登錄檔裡面的一些值做一些變動，一個原本不能被遠端呼叫的COM元件就變成了DCOM，變成可以被遠端呼叫了。將 COM 改造成為 DCOM 的過程需要我們操作登錄檔，操作登錄檔的操作是可以遠端實現的。什麼意思呢？就是我們可以遠端連線到一臺機器上，遠端把這臺機器上的上的 XML DOM Document元件由COM改成DCOM，然後就可以利用這個COM元件（現在應該叫DCOM元件了）來做我們任何想要做的事情。

   

至少可以做到這麼四類事情：支援直接命令回顯，上傳、下載二進位制檔案，遠端記憶體執行任意.NET PE，MIMIKATZ整合。

    

一般人們用的那些方案，只所以能夠看到命令的回顯結果，是因為把命令的回顯結果儲存到另外一個地方。要麼是檔案裡面，要麼是登錄檔裡面。命令執行完以後，透過讀檔案、讀登錄檔，把這個結果讀回來，這是一種間接的命令回顯方式。而我這裡提到的方案，支援的是直接的命令結果回顯，你可以直接拿到命令的回顯結果，不需要把這個結果儲存到一個其他地方再從這個地方去讀取。第四個（MIMIKATZ 整合）其實算第三個的子集，這個工具太常用了。

簡單的看一下實現的效果。（圖）功能不是很全，因為就是兩天時間寫出來的。首先看一下第一個效果，命令執行。效果從圖片上看起來好像沒有什麼區別，但是這個回顯是直接拿到的，並不是儲存到檔案或者其它地方再讀回來的，這是直接拿過來的。第二個，客戶端向服務端上傳一個檔案，傳上去以後在服務端也是可以開啟的。下面這個例子，就是二進位制檔案的下載。這裡演示的例子，就是下載CMD檔案回到本地，也是可以開啟的。最後是遠端記憶體執行 MIMIKATZ，之前應該有出過其他方案，但是那些方案我看到過都是事先將mimikatz程式碼儲存到遠端伺服器的一個地方比如登錄檔裡面再透過其他的方式放入記憶體執行。我的方案跟這些方案不一樣，MIMIKATZ 的程式碼不需要被儲存到遠端伺服器的任務地方，而是被當作一個引數傳到服務端記憶體裡面去的，然後進行記憶體執行，然後透過同樣的通道把結果拿回來。

最後打個廣告，我們團隊現在主要做的是紅藍對抗方面的實戰與研究，有的時候會迸出來一些小想法或者實踐中需要的工具，這個時候有可能會把它武器化。對於有些工具我們選擇上傳到github上面去：

https://github.com/QAX-A-Team

仙果：紅隊行動，攻防之防毒軟體對抗

    

仙果：謝謝大家，其實上臺我還是有一點緊張的。為什麼呢？本來準備的議題是準備了半小時，但是我看到的內容其實是50分鐘。也就是說，我要擴充套件20分鐘時間。這20分鐘的時間，擴充套件什麼呢？給大家加點私貨。我來之前領導跟我說：你可以講、可以分享，但是不能講到我們目前用到的一些技術。這個讓我非常的糾結，因為對於我來說，我非常希望把我這邊掌握的技術給大家公開，讓大家一塊兒來成長。但是公司既然有要求了，這個屬於沒辦法的事情。有些技術不能說得太細，大家理解。

    

一、自我介紹。

    這個已經說很多次了，略過。

    

二、何為“防毒軟體對抗”。

    簡單的來說“免殺”。

    

三、防毒軟體解析。

    一筆帶過。

    

四、防毒軟體對抗技術。

    

五、思路和方法分享。

    

講的時候PPT的內容，可能更多是以PE的。加點私貨，更多是跟軟體漏洞相關的，畢竟是老本行。

   

仙果，主要做的是安全攻防對抗研究，物聯網安全攻防對抗研究。何為“防毒軟體對抗”？來看一個圖片。大家熟悉嗎？這個圖片，顏色很熟悉，如果是之前可能不敢把這個圖片放出來，現在放出來也沒問題了，畢竟奇安信和360集團已經分家了，是吧？然後來看，免殺了。再來看另外一張，又免殺了。這種“免殺”技術更多的是分析一種叫免殺對抗的基於技術方法。在我們拿到的樣本之後，我們不止要研究防禦技術，還要研究攻防對抗技術。一個是提高防毒軟體的能力，還有就是提高攻擊技術實力。這裡提到“紅隊”的概念，主要提高紅隊技術對抗的能力。傳統的攻防對抗上，遇到防毒軟體的情況是最多的。真正的目標企業，不裝防毒軟體的情況幾乎沒有。我們自己的安全人員可能會選擇裸奔，我不知道在座的各位有多少是做二進位制安全的。之前據我瞭解很多是做滲透測試，所以呢更多是偏向于思路上面，就是免殺技術對抗思路方面。在實際的攻防對抗上面，這裡不單單是說國內360，也不只是防毒軟體對抗，還有IDS或者其它防禦產品對抗。我們知道國外的安全公司公開很多國內的攻防對抗組織。為什麼會公開，技術稍微做好一點，然後就可以做到不被公開。而一旦公開之後，所付出的很多成本，行政成本、政治成本以及經濟成本都是非常高。提升對抗技術就可以避免這些問題。我不知道大家在日常滲透的時候遇到防毒軟體產品的情形多不多，實戰攻防對抗經常能夠遇到，此時就必須提升技術對抗能力，而防毒軟體是一個比較好的入口點。牽扯到第四點，我沒有寫的很具體，就是實戰對抗技術儲備。儲備這樣的技術，因為說不定哪天我們就會用到。

    

我們來看防毒軟體的解析。如果梳理防毒軟體的廠商，你會發現主流的安全廠商。比如：卡巴斯基、諾頓、賽門鐵克、AVG等公司成立都非常早，那個時候我們還是小學生，防毒軟體的廠商已經有了。它們發展了這麼多年，他們的技術積累是非常豐富的，而且他們能夠存活這麼多年，他們的技術積累就可想而知。最開始的時候可能採用基本的方法對抗木馬病毒，比如：對付衝擊波、蠕蟲病毒的時候，採用特徵碼或者是一些基礎規則的掃描。發展到後面2000年-2005年的時候，可能更多是採用其他方式。2005年-2014年新的技術，主動防禦技術和虛擬化技術都發展起來了。到了2014年-2018年，提到更多的是“下一代防毒軟體”技術。比如：“雲”廠商。2019年也就是今年，我們現在的情況，是不是說：防毒軟體已經消亡了呢？像現在比如大家在裝Win10的時候，大家在用Win10時候更多是考慮效能，而不是考慮是否還再要去裝一個防毒軟體。現在防毒軟體它是否要消亡？這個問題其實是一個非常好的命題。

    

我們再來看（圖）這個列表很長，我傳了一個簡單的小的樣本上去。一大長串的防毒軟體，但是我們在實際的攻防對抗上面，其實會遇到這麼多的防毒軟體嗎？不會。可能遇到一個主流的，而且它是分地區、分方向的。可能東歐、俄羅斯或者是東北亞，更多的是卡巴斯基，南北美洲可能更多的是賽門鐵克或者什麼。東南亞可能更多的是一些小的不出名的防毒軟體。這種時候你可能就需要針對每一個目標地區的防毒軟體，做更詳細的規劃、跟詳細的分類，然後做它們分別的技術儲備。

    

這裡面能夠看到比較多的是主流的，其中卡巴斯基、AVG、AVAST這種都是非常主流。08年之後大家知道小紅傘的可能會比較多，但是真正有多少人會用小紅傘這樣一個防毒軟體？其實它做的是相當好，但它確實是可以被繞過。

    

這裡來梳理一下防毒軟體的查殺技術。

    1.特徵碼、廣譜特徵碼（複合特徵碼）。

    這個實際是多個MD5的比較。08年之前，這種應用是非常多的。而且當時360鬧過一個笑話，它是直接根據“檔名”來判斷查殺的。

    2.記憶體特徵碼。

    因為防毒軟體本身的許可權是相當於核心許可權，它的許可權是比較高的，可以監控核心，在記憶體中對特徵碼進行監控。

    3.啟發式防毒。

    啟發式防毒更多的是根據一個行為、一個操作呼叫或者是其它各種各樣的行為，然後判定“惡意行為”。這裡面講“啟發式防毒”過程，其實很原理化。

    4.虛擬機器技術。

    虛擬機器技術在前兩年是非常之火的，程式碼放到一個虛擬機器裡面去執行，然後來判斷到底是不是惡意的還是正常的。這裡面有一個很大的問題是什麼？虛擬機器不可能完全模擬全部的操作指令，或者是我可以在我的程式碼裡面去分析你到底是不是在虛擬機器裡面，這個會在下面講到。

    

諾頓出了一個什麼樣的查殺機制呢？把你要執行的檔案，不管是MD5還是其它的方式也好，發到雲端，然後判斷多少人來執行了這個檔案。如果人少，它會給一個比例。如果已經上傳，已經定義的話，就直接下發，說：這是一個惡意的軟體。像這種怎麼來做這種對抗？其實最終都是有辦法來進行對抗的。

    

這兩個工具大家有沒有很熟悉的（VirTest5.0和MyCCL複合特徵碼丁煒器Ver1.1 Build58）。我們看了有工具、有原理，還有我們知道防毒軟體是怎麼查殺的。這個時候我們怎麼來做“免殺”，或者怎麼做防毒軟體的對抗？

    

防毒軟體要查殺，肯定是要你有相應的行為是惡意的。有一個問題是什麼呢？惡意的行為和正常的行為，區別在哪裡？這個時候要思考這樣的一個問題。它的真正的區別是什麼？為什麼木馬行為被抓出來，正常的行為和惡意的行為其實是沒有區別的。在作業系統看來，它是沒有區別的。這時候怎麼來做？其實你只要抓住這一點，然後就有辦法來“過”防毒軟體。

    

（圖）這是一個免殺的最基本的操作。這個叫什麼呢？在原來很早之前它叫“加花指令”，因為透過之前的工具，我們能定位出來特徵碼。這個時候你去修改這些特徵碼。防毒軟體免殺：1.過靜態。2.過動態。3.過雲。原來你需要過靜態、過動態，然後就可以了，現在還要再加一個“雲”。可能這裡面所說的把“過虛擬化”這個給省略了，過動態其實包括了虛擬化。這裡面我們強調一個，是過靜態的技術。靜態技術其實好過，當你有原始碼的情況下非常好過，因為你可以定位到查殺的具體動作點。但是很多的時候面臨的一個工情形是沒有原始碼，或者是根本用不到原始碼，那麼就有很多彙編指令的應用。

    

之前學破解的時候有一個順口溜，叫“74“變“75“，“84“變“85”，很老的一個段子。基本免殺的原理是把你的指令給操作複雜化。把指令序列改得很亂，這個時候不管是靜態還是動態，它的順序就亂了，而防毒軟體在進行識別的時候，它是不能準確的識別，去過掉靜態檢測。另外一點就是這裡面強調一個“虛擬化的對抗”，虛擬化的對抗是一個比較主流的。我們提到之前的特徵碼，啟發式或其它的查殺技術，它可能都沒有虛擬化做的這麼徹底。那麼，我們就想辦法來繞過這一點。

    

（圖）這是一個檢查是否是在除錯狀態的一個程式碼，首先是fs:30，然後取fs:30指向地址裡面的一個值，獲取除錯標誌。判斷這個標誌之後，就可以判斷出來它到底是否是在這樣一個虛擬機器裡面執行的狀態。這個防毒軟體可以識別的，防毒軟體可以識別這一串機器碼。我們這個時候針對這個機器碼再做一個變形，功能是同樣的，複雜程度更高.這個時候其實它在防毒軟體檢測的時候，其實就無能為力了。我們再來看另外一點，這也是虛擬機器的一個對抗，它去檢測TickCount，TickCount如果小於1000的話，它肯定是在虛擬機器裡面，然後我們再來看，這個時候它來檢測CPU的核心數，檢測CPU的核心數我們知道虛擬機器裡面去模擬這樣的一個技術。那麼，它的核心數、它為了保證檢測效率，它模擬的一個核心，主流的可能兩個、三個、四個都有，再有一個就是我分配大量的記憶體，我分配大批次的記憶體。如果它分配不成功的話，肯定是有問題的。再然後我們看，這是一個什麼呢？這就是一個繞過的技巧，透過註冊“互斥”然後來繞過它。知道叫防毒軟體檢測是有順序往下執行的，這個時候我們如果採用多執行緒，比如：互斥這種多方面的技術，就可以繞過很大部分的防毒軟體。

    

上面說的這些可能更多的是跟PE相關的，防毒軟體對抗，還有一種是利用防毒軟體自身的漏洞，作業系統都有漏洞，那麼防毒軟體肯定也有漏洞。以前出過什麼樣的呢？出過這樣的一個漏洞，就是防毒軟體在解析、進行虛擬執行的時候出現的安全問題，比如：防毒軟體在解析JS程式碼的時候，因為它要模擬去執行時候就造成了一個緩衝區溢位，它是可以直接在防毒軟體環境裡面去做一個任意程式碼執行的漏洞，這個時候就可以做任何事情。

    

（圖）這是一個熊貓防毒軟體，某一個版本存在許可權提升漏洞。我們來看錄影！（影片短片-這個會在桌面上釋放一個檔案，可以看到熊貓防毒軟體有存在這樣的一個安全問題。除了熊貓防毒軟體之外，是不是其它的防毒軟體也存在這樣的問題？）是不是存在影響範圍更大的，比如：熊貓防毒軟體只是個人端的。如果是企業端的防毒軟體，比如：賽門鐵克。我知道賽門鐵克在前些年，包括：現在在很多企業裡面用的都是非常多的。企業版防毒軟體是有個集中管理端，統一進行防毒軟體更新，像域的結構一樣，域下面的客戶端裝了各個防毒軟體的元件。這個時候如果說防毒軟體的伺服器出現了安全的問題，它出現安全問題之後你可以給下面的客戶端去推送這樣一個更新，預設客戶端是信任的。這樣的問題就大條了。大條在什麼地方？完全信任。就像是最近這兩年比較流行的供應鏈、軟體供應鏈攻擊一樣，造成的後果就是你只要更新，防毒軟體的服務端推送更新之後下面所有的客戶端、執行的更新，然後來執行這樣的一個exe或者是其它的功能。這樣你在整個在做滲透，在做這樣的橫向移動的時候，其實就非常的方便，不需要有作業系統的0day漏洞，也不需要去做水坑。一條防毒軟體的指令過去，下面所有的客戶端全部被覆蓋。而且不止是賽門鐵克，也包括其它的防毒軟體。

    

（圖）下面是私貨時間。我之前講的除了防毒軟體的漏洞之外，更多講的是PE的對抗技術。我覺得大家如果有在有原始碼的情況下，可能就很容易能夠過了。因為你知道查的點，具體哪一條，你改動起來就比較容易了。但是如果是軟體漏洞呢？從Office漏洞來說，它有幾大行為。第一個，Office漏洞的三段式。從三段式說起：第一，有惡意文件。第二，有木馬病毒。第三，有正常的文件。這三段式組成的一個文件類的漏洞利用，這樣一個三段式在做防毒軟體對抗的時候，有幾個危險點。第一，漏洞的觸發點，動態的漏洞出發點。第二，執行的行為。第三，釋放之後你的木馬和遠控的行為。它的三段式，防毒軟體會在這三段裡面同時來做檢測，而且更變態的是什麼？防毒軟體的漏洞緩解技術，不僅是在作業系統裡面，也在這樣的一個防毒軟體裡面。這個在麥咖啡的企業版，體現的是最明顯的。我們說回Office漏洞的三段式裡面，如果我們能夠減少Office軟體漏洞利用的三段式，把三段式改成兩段式或者是一段式，這個時候防毒軟體是不是就沒有效果了，或者說很難檢測。從Office軟體漏洞利用的三段式到二段式、到一段式。一段式是什麼？我們先說二段式，二段式是利用漏洞和正常文件是同一個文件。具體怎麼做到？兩段式是一個漏洞率文件和正常文件是同一個，再加一個遠控和木馬的檔案，構成了一個兩段式的文件。這個時候防毒軟體升級，升級以後檢測你釋放的行為、你釋放的動作。這個時候其實在做的時候就發現一個什麼問題呢？你只要釋放，不管你是怎麼釋放的，總會被檢測。

    

還有一個問題，我們所有的說：有一個問題沒有解決。是什麼問題？漏洞執行點的問題。漏洞執行點，如果防毒軟體來做的話，我們HOOK軟體漏洞觸發點比如說：Office辦公軟體類，不管你是怎麼執行，你都要執行到那個點上去。這個時候如果來做這樣的一個防禦？其實這個方法還是有的。叫什麼方法呢？防毒軟體去監測的時候，是有一個檔案格式識別。檔案格式識別的一個功能。如果是辦公軟體類的，我讓你識別不出來辦公軟體類的就可以了，從根本上解決這個問題。比如說，我們一個DOC的文件被識別成了一個7Z或者是識別成了一個EXE。這個時候針對這種辦公軟體類的檢測就失效了，這就是一個整體利用的過程和思路，也是從最開始的一個軟體漏洞的對抗到現在一個技術的發展。

    

我們來梳理一下，我們執行了哪些技術。第一個，從軟體漏洞利用的三段式裡面改成一段式。從一段式裡面改變檔案格式的一個從根本的檔案格式，那麼就完美的避過了防毒軟體。還有一點，這裡面提到了是文件類的。我們再來說成Adobe Reader漏洞，Adobe Reader一兩年才公佈幾個比較好用的，以前是比較多的。針對Adobe Reader對抗，其實也是非常多的。不知道大家在開啟PDF的時候有沒有發現一個問題，有些文字是複製不出來的，或者是由於版權的要求，你只能去閱讀而不能去修改、刪除。這個時候你會發現，它裡面的文件是加密的。這個技術其實是可以用到這樣一個“免殺”技術裡面去的，因為防毒軟體要做這種檢測，那麼它肯定要做一個特徵碼。這個時候其實如果我們讓它檢測不到，或者是無法識別。首先是什麼呢？首先是PDF的檔案格式，它是基於“流”的，它解開這個“流”自然能看到裡面的“文”。如果讓它解不開這個“流”，是不是就可以規避很大一部分防毒軟體？這個時候就可以用到一個方法，然後把它加密，而且加密強度可以很高。還有一個是什麼呢？製作PDF的工具，Adobe Reader只是一個PDF的閱讀器。製作PDF的文件工具有很多，這個時候你不一定非要用Adobe Reader官方的PDF編輯器，可以用其它的。這個時候每一個不同的工具生成的PDF文件都是格式上面有區別的，防毒軟體不可能針對每一種文件、每一種PDF的版本文件都去做檢測。這個時候，我們的機會就來了。叫什麼呢？透過各種各樣的工具、各種各樣的製作工具組合起來，包括：PDF的表單工具，這樣的一些工具組合起來使用，就直接讓防毒軟體失效。

    

下面我們來看什麼呢？這是卡巴斯基，這是一個Offcie的漏洞，我們看它執行的效果。這個時候我們看到靜態肯定是沒有問題的，執行呢？也是沒有問題的，開啟是沒有任何反應的。這個時候其實當你下次開啟的時候，已經執行起來，計算器彈出來。可能給大家去演示彈計算器是一個比較常見的，只是彈一個計算器。我們再來看另外一個，這是諾頓的。靜態上面都是沒有問題的，這是檢測了其中一個（影片演示），這個沒有彈計算器，而彈了“掃雷”。我們再來看另外還是卡巴斯基，這個錄影做的時間是2018年的，實際上現在利用也是沒有問題的。這是一個PDF的漏洞，為什麼看的比較卡呢？是因為是在虛擬機器裡面，它的效能還是有限。（影片演示）這裡給大家說一點，就是在實際的攻防對抗當中，防毒軟體只是對抗當中的一部分。紅隊在具體研究的時候，防毒軟體最終不是目的，它只是其中落地的一步。文件類的防毒軟體對抗可以用各種各樣的技術，它比木馬的難度在於你的文件、你的漏洞要過一層，你的動態行為也要過一層，所以說：它的難度體現在這一點。

    

（影片演示——這是AVG的防毒軟體，這是一個遠控的演示。遠控的演示，可能大家見識的都已經是比較多了，這個就沒有什麼好說的了。我們看，它正在對EXE進行掃描，他在內部對EXE進行虛擬執行。等它虛擬完成之後，然後再判斷到底是正常的還是惡意的。這個時候它就找不到問題了，這裡面可以看到這個遠控就已經上線了。）

    

我的議題大致主要內容就到這裡。想給大家說幾點：第一，紅隊在做這種攻防對抗的時候，其實需要一點就是防毒軟體。真實的攻擊、真實的網路攻防對抗，防毒軟體只是其中一環。第二，軟體漏洞和防毒軟體的對抗，是一個迴圈、螺旋上升的過程。它的技術對抗門檻是越來越高的，也希望大家能夠投入到“軟體漏洞”和“防毒軟體對抗”的工作當中。第三，下來之後非常希望跟大家交流這方面的技術。

    

主持人：感謝大家花費一下午的時間在這裡。我覺得應該是不虛此行，希望大家有所收穫。我們後續計劃在大概今年Q3的時候，舉行一些相關的訓練營，把今天提到的技術講得更細，大家可以參與到其中學到更多的東西。同時我有三點希望：1.希望透過介紹紅隊的這些知識，可以點燃大家心裡的火炬。做攻擊或者是做滲透這個東西，其實跟現在市場上能看到的最普通的那種我把它定義叫“漏洞測試”是有很明顯區別的，大家心裡要有這個概念。2.希望以後再跟別人談起的時候，我們可以有一個共同交流的頻率。就是說所謂做“漏洞測試”的人不是做滲透的，我甚至不認為他們是做安全的，我覺得他們像低端的QA，是一個非常機械化的簡單的可以被程式替代的工作。3.今天準備的這幾個議題，希望給大家傳遞一些知識，讓大家有所收穫。

    

再次感謝大家，幾個月之後再見。謝謝！