CrazyHunter 實戰錄

與APT組織的攻防重點

Author
Security Research Director
Jacky Hsieh

CrazyHunter,僅僅花了不到兩個月的時間,便從一個陌生的新名詞,搖身一變成為惡名昭彰並給予台灣IT從業人員帶來極大壓力的中國駭客團體。該駭客團體專門鎖定台灣企業、單位進行攻擊,平均每一至兩週,便在其官網上更新受害名單,甚至直接在其官網自介中,寫出可以100% 繞過多家國際知名大廠EDR的偵測與保護。看著他們在如此短時間內便攻破多個單位,相信多數企業負責人及IT相關人員心中都會有相同的疑問:為何他們能夠如此來去自若,難道EDR真的已無用武之地了嗎?

在網路世界中,通常在駭客執行勒索軟體,並於相關網站上「宣示」戰果以前,是不易判定攻擊者是否為某個駭客團體的。但人總有慣性,即便是善於匿蹤的駭客組織,也會有慣於使用的工具、手法、特徵等資訊,可供研究員進行判別。本文將透過近期本公司研究監控團隊阻斷的攻擊中,數個幾乎可以確定是CrazyHunter的實際範例來進行分析探討。

【實際案例】

接下來的數起案例分享,是攻擊者從未知來源的機器,竊取得高權限帳號密碼後,使用常見橫向擴散工具impacket進行橫向移動的例子。此工具功能強大又好用,為許多攻擊者、紅隊人員做內網滲透時所喜愛。

從上面幾張圖可以發現,最上排左圖為使用預設未經客製化修改的impacket wmiexec橫向移動時所產生的特徵;其餘為經CrazyHunter客製化修改後,使用impacket wmiexec橫向移動時所留下的特徵。由於此工具的預設特徵明顯,又遭大量使用,許多資安產品均有辦法針對預設特徵做偵測。但經過攻擊者客製化修改特徵後,便能非常有效的規避多數資安產品的偵測。本公司研究團隊於2022 Hitcon演講 闡述EDR偵測分析手法,當時國內專業紅隊特地蒞臨交流,後續也針對相關特徵做修改,以試圖繞過專業MDR團隊的偵測。除上述之專業紅隊外,APT駭客組織為求更隱蔽的進行攻擊,也會對其進行修改。而這邊可以看到,CrazyHunter不僅有針對Windows大小寫通吃的特性做混淆,亦將原本最末端的隨機數字亂碼進行修改,甚至在不同攻擊中有不同的亂碼。此舉可能是為了規避偵測,故在每次攻擊時都將相關特徵做更改,但亦不排除是團隊中不同成員在操作時所留下。除了impacket中的wmiexec,其餘常見的smbexec等橫向工具,也都有類似特殊特徵可供偵測,我們亦有觀測到攻擊者有針對其做修改來規避偵測。

除了修改常見工具中的預設特徵以規避偵測之外,使用Bring Your Own Vulnerable Driver (BYOVD)攻擊來嘗試清除端點上的資安設備,也幾乎可以說是CrazyHunter攻擊SOP中的一環了。我們發現了一些以開源專案 L1LKiller[1]寫成的惡意程式和多隻功能、特徵以及架構與之前已公開的相關IOC分析報告相似,但Hash卻均不相同的惡意程式。簡單逆向分析其中一隻惡意程式可以發現,

一樣都是使用Golang進行開發,載入有弱點的驅動程式用來停止資安軟體。除了將趨勢、微軟的防毒產品程序列入停止清單,其他諸如Avira(小紅傘)等防毒軟體也進入列表。此外,攻擊者還會將攻擊目標中發現的資安軟體額外加入列表後重新編譯客製化的惡意程式。在我們遇到的案例中,不僅有使用zam64.sys這隻因為用在馬偕醫院而被多數資安廠商列於黑名單的驅動程式,還有看到多個被嘗試用來停止資安軟體的驅動程式,在VirusTotal(VT)上都有超過半數防毒軟體認定為惡意程式。但其中viragt64.sys (SHA1: 05c0c49e8bcf11b883d41441ce87a2ee7a3aba1d) 這隻驅動程式在VT上的分數相對低,若是未及時阻擋,資安軟體便可能遭到停止。

在常駐手法上,除了基本的竊取高權限帳號密碼、新增後門帳號搭配安裝Anydesk或竊取其遠端連線密碼之外,CrazyHunter很大量使用Living Off Trusted Sites (LOTS)手法來將中繼站連線隱藏於合法網域內來繞過資安設備的檢查,詳細可參考本公司前篇文章,本文便不再贅述。

綜合以上案例,我們可以整理出以下幾個重點:

  • 選用許多相對低開發成本的現成工具、開源工具重新編譯後進行攻擊,但對相關工具均有相對充足的認識,能夠進行混淆免殺、修改特徵以大幅降低遭偵測機率。
  • 標配使用反EDR技術,嘗試刪除、關閉端點上的防護設備。
  • 以合法掩飾非法,最大程度地將惡意行為隱藏於合法程式、網域之中,延後遭發現時間。

【EDR已不再有用?】

要講到這個議題,就得從Detection and Response類型的解決方案說起。正是因為認知到了「沒有絕對安全的系統」的事實,不可能將所有攻擊威脅阻擋下來,所以在考量安全性和使用性之間,做出了退一小步的選擇 – 在攻擊發生後、嚴重損失發生前,盡早於攻擊初期階段偵測(Detection)並精準快速的處理(Response)來應對。用上圖的Cyber Defense Matrix[2]來看,EDR就是在端點上針對後面幾個階段做防禦加強而問世的產品。

隨著最近幾年EDR/MDR的盛行,相關針對EDR的攻擊手法也越來越多,從一開始的降低告警嚴重度(Critical告警變成Low告警)、繞過EDR告警或避免行為被紀錄下來,到最簡單粗暴的直接將EDR程式砍掉等,顯示駭客組織將大量研究應用於實際攻擊中,並獲得不錯的成效,而這也正是CrazyHunter及其他攻擊者在面對此類產品時下足功夫之處 – 盡可能地讓被發現的時候趨近於發生影響的階段。

可以發現,造成EDR “好像”無用的主要原因在於攻擊者運用大量最新紅隊研究、免殺技術,有效地規避偵測,僅在攻擊最後階段竊取資料、加密勒索時才露出真面目,極大程度壓縮資安人員的反應及處理的時間,才讓攻擊者在如此短時間內成功攻擊勒索多個單位。

【該如何防範?】

在攻擊者可以拿著EDR直接進行測試,並運用各種最新紅隊研究來強化攻擊的情況下,單純只依賴工具原生的偵測機制已不現實,能即時研究各種新式攻擊手法,並將之優化單位偵測能力的整體機制成為這時代資安的必須品。如何準確調整規則來偵測事件,不讓偵測範圍過大而造成資安人員無法每條確認並處理完畢,與之同時偵測範圍亦不能太小使得攻擊者可以輕易修改特徵繞過,同時還需研究是否有出現新的規避偵測及攻擊技巧而新增相對應的偵測機制,都是藍隊研究員與相關Detection and Response產品維運人員的重要課題,相關告警規則調整的好,不僅僅可以及早抓出已知漏洞N-Day的利用,甚至就連Zero-Day也能有效阻擋(參考連結),CrazyHunter的出現以及各種資安事件的發生,無不在提醒我們紅藍隊偵測與反偵測之間的軍備競賽已然展開。

除此之外,確保所使用的EDR程式有主動式阻擋可抵禦BYOVD、EDR Silencer等攻擊,或即使沒有主動阻擋也要確保不受相關攻擊影響,以免產品直接失去效用。由於在一般演練,甚至是紅隊測試中,紅隊人員普遍不會進行此類攻擊,又或是會直接被禁止做此等較具破壞性的操作,避免影響系統服務。但在現實中,駭客可絲毫不會手軟,且可以無顧忌的進行此類攻擊,因此在評估相關產品時,針對其安全性、可靠性進行驗證絕對是必要的步驟。

最後,良好的資安管理規範增加攻擊難度以拖延攻擊者速度,為Detection and Response產品維運人員爭取應變時間,在為時未晚前便發現處理,也是極為重要的。

  • 定期進行安全性更新,減少已知漏洞被利用的可能
  • 建立良好安全系統發展生命週期(SSDLC),減少漏洞的產生並及時修復
  • 檢查所有對外設備並全面部署相對應的資安產品
  • 嚴格的資安規範,高權限帳號管理及重要資產的分區、連線控管,亦可參考CIS Benchmarks[3]
  • 針對產品的告警確實處理,不因告警嚴重度低而輕易忽略甚至不分析處理

而在IoC情資部分,綜合比對我們發現的攻擊行為與網路上公開的CrazyHunter相關資訊,可以發現傳統的IoC,尤其是相關惡意程式的檔案Hash效用大幅降低,因為攻擊者每次攻擊時都會透過部分修改,並針對不同受害單位客製化惡意程式,使得每次攻擊初、中期使用的多數攻擊程式都是Hash未知的惡意程式。相對較有阻擋意義的IoC是稍微需要一些成本的惡意中繼站網域,以及成本又相對更高的BYOVD攻擊中所需使用的有弱點驅動程式的Hash。

【結語】

身處於攻擊者產業鏈越來越成熟的今日,評估Detection and Response類型的解決方案,僅考慮傳統的MTTD、MTTR等關鍵指標已略顯不足,在眾多阻斷攻擊者的經驗中,我們認為應該加入一個新的維度 – 攻擊階段(Stage of Attack),並引入新的關鍵指標Mean Stage to Detect and Respond(MSTDR) 來評估不同攻擊情境下的偵測及應變能力,正如近幾年越來越多人在討論的Mitre Att&ck框架所致力於傳達的概念一般。

在這樣防禦思維下,以往資安的縱深防禦架構已無法完美抵禦攻擊者,藍隊的資安人員需從購買資安設備進行防禦轉向攻擊階段的研究並跟上最新技術與手法。這也預示資安不能僅考慮各”面向”的防護,而是要找回Detection and Response解決方案出現時的宗旨,從攻擊者的行為進行分析,進而達到在攻擊初期就發現並進行處置,才能真正阻擋來勢洶洶的勒索團體,這也代表與攻擊者的軍備競賽已然正式開打。

[1] https://github.com/brosck/L1LKiller [2] https://cyberdefensematrix.com,由Sounil Yu 所提出 [3] https://www.cisecurity.org/cis-benchmarks ,由美國非營利組織網路安全中心所彙整