最近的一項全球調查指出，CISO及其企業(yè)可能過于依賴端點檢測與響應（EDR）和擴展檢測與響應（XDR）系統，因為攻擊者越來越多地規(guī)避了這些系統。
這部分是因為規(guī)避EDR/XDR系統一直以來并將繼續(xù)是現代對手的基本要求。“規(guī)避”通常用來描述防御反應未被觀察到的情況。雖然技術上準確，但這種缺乏具體性的描述阻礙了網絡安全專業(yè)人士準確定位補救措施，例如，修復檢測邏輯錯誤與XDR平臺中缺少遙測數據的情況大不相同。
為了更好地理解攻擊者如何規(guī)避EDR/XDR系統，以及更重要的，在發(fā)生規(guī)避后應該采取什么措施，我們需要了解規(guī)避發(fā)生的三個領域：觀察、檢測和響應與預防。
攻擊者在觀察階段如何規(guī)避XDR
XDR系統的核心是從各種來源（如端點的操作系統或云提供商）獲取事件，這些事件通常稱為遙測數據，構成了檢測的基礎。XDR只能檢測到系統能夠提供和收集的數據，第一種規(guī)避類型發(fā)生在XDR未收到其需要的事件來檢測惡意行為時。
這種規(guī)避有幾個常見原因，首先，也是我認為最“純粹”的技術規(guī)避，是對手的行動未生成相關的遙測數據，相關是指系統上每個動作都會生成一定量的遙測數據，但這些事件可能對創(chuàng)建有效檢測沒有用，可以將其視為系統中缺失的事件源，而不是XDR的缺陷。
接下來是系統生成了遙測數據但未被XDR接收的情況，XDR可以訂閱數千個事件源，供應商的工作是決定哪些事件源是滿足檢測需求所必需的，例如，如果XDR供應商特別關注檢測與Active Directory相關的行為，他們會優(yōu)先收集來自AD的事件，而不是網絡流量。不收集某些類型的事件，無論是有意為之還是無意為之，都會在XDR對某些技術的覆蓋范圍內產生可利用的漏洞。
最后，對手可能會主動干擾XDR代理，使事件無法發(fā)送到負責收集和關聯的集中服務器，這種干擾有多種形式，包括停止或卸載代理、阻止與服務器的通信（例如，通過修改基于主機的防火墻）或篡改傳感器（例如，禁用AMSI）。
總體而言，這些問題反映了XDR開發(fā)者的失敗。如果由于代理程序未收集相關遙測數據而導致攻擊被遺漏，供應商是唯一能夠解決此問題的實體，因為這涉及添加新的遙測源或擴展/豐富現有的遙測源。在代理程序受到干擾的情況下，供應商應實施防篡改措施，以防止他們能防止的干擾，并檢測無法合理防止的干擾。對于每個安全團隊來說，這些問題是最難解決的，因為他們實際上除了求助于XDR供應商外別無他法。
攻擊者如何在檢測過程中規(guī)避XDR
當大多數人談論規(guī)避XDR時，他們幾乎總是指繞過XDR中的檢測邏輯。檢測本身只是評估一個事件或一組事件以確定是否存在某些可能表明惡意行為的條件的方式，這些檢測查詢或規(guī)則可以是精確的，意味著它們針對通常對某個惡意軟件或攻擊工具（例如Mimikatz的命令行參數）獨有的特定屬性，或者是魯棒的，意味著它們針對的是多個惡意軟件樣本或工具共享的行為。
兩種類型的檢測都有其缺陷。精確檢測易于被規(guī)避，因為它們通常過于具體，這意味著對目標樣本的任何修改都會導致誤報，例如，攻擊者修改Mimikatz的參數字符串，將“sekurlsa::logonpasswords”變成“nothings::happening_here”，從而打破針對攻擊者控制字符串的脆弱檢測邏輯。
盡管魯棒檢測表面上看起來不那么容易被規(guī)避，但它們因誤報而臭名昭著，這會導致規(guī)則中的排除項被攻擊者利用。一個實際中的例子是，將Chrome更新進程“GoogleUpdate.exe”排除在憑證轉儲檢測之外，因為其正常操作涉及打開本地安全機構子系統服務（LSASS）進程的特權句柄。此排除項允許攻擊者冒充更新助手或注入其中以提取憑證而不被檢測到，盡管XDR收集的事件中存在所有行為模式。
這些規(guī)避手段利用了EDR檢測中的邏輯問題，無論這些檢測是由供應商提供還是由內部檢測工程師編寫的。對技術或過程的理解不完善、檢測瓶頸、為了使檢測在生產環(huán)境中可行而做出的妥協以及XDR中次優(yōu)的遙測數據導致的弱檢測邏輯在端點保護領域是司空見慣的。
解決這些問題的方法是彌合這些邏輯差距，但不幸的是，在實際環(huán)境中，這并不總是可能的。有時我們必須接受某種程度的脆弱性，以快速生成針對新興威脅的檢測，但這些精確檢測應輔以魯棒檢測，以捕捉不可避免的漏報。
魯棒檢測幾乎總是需要一定程度的排除項，以避免安全團隊被警報淹沒，但這些排除項應盡可能少，并不斷評估以確定它們是否需要繼續(xù)存在于生產環(huán)境中。實際上，檢測工程從檢測進入生產環(huán)境的那一刻起，就進入了一個永無止境的調整和優(yōu)化階段，其唯一目標是使檢測盡可能具有彈性，同時保持在團隊可以容忍的誤報和漏報范圍內。
攻擊者在響應和預防過程中如何規(guī)避XDR
最后一種規(guī)避類型集中在當發(fā)生真正的正面警報時應進行的調查過程中的漏洞。響應警報的過程因企業(yè)而異，但通常包括分診、調查和響應階段，這個過程的復雜性帶來了許多不同的故障點。
在一個普通的SOC（安全運營中心）工作流程中，規(guī)避行為可能發(fā)生的第一個機會是在分診階段。在此階段，一名一級分析師收到警報并錯誤地將其標記為誤報，這導致盡管XDR發(fā)揮了作用，但該行為仍未被注意到，這種失敗可能源于警報疲勞，導致分析師為了減少警報隊列而錯誤地壓制警報，或者是因為缺乏對檢測目的和信息含義的理解。解決這一失敗點通常涉及通過減少誤報（如前文所述，減少誤報本身也存在問題）來進行隊列和疲勞管理，以及通過更好的文檔和教育來提升分析師對檢測的理解。
接下來是調查階段，該階段發(fā)生在確認真正的正面警報之后，涉及次級信息收集，以更具體地確定警報是否值得升級為全面事件，這個過程通常是手動的，需要熟練的分析師對相關系統進行質詢并提取支持信息，例如文件系統上遺留的痕跡信息。
在這里，有很多與調查人員的技能和對手有關的失敗點。如果分析師需要檢查磁盤上的文件，但對手已預先將其刪除怎么辦？如果需要內存取證，但對手已重啟系統怎么辦？如果對手采用了調查人員不熟悉的技術，導致他們遺漏了攻擊者留下的痕跡怎么辦？解決這些失敗點需要強有力的支持文檔，例如在懷疑有真正正面警報時應收集什么信息以及這些信息的含義。
最后是響應階段，這發(fā)生在警報被確認為真正正面并宣布為事件之后，涉及驅逐威脅行為者。在確定事件范圍（涉及多少系統、用戶等）之后，安全團隊有多種清除攻擊者的選項，從簡單地重啟主機以清除駐留在內存中的惡意軟件，到像銷毀整個環(huán)境這樣極端的措施。在這個階段，成功是二元的——要么完全驅逐對手，要么沒有。
我在紅隊工作時遇到的這個階段最大的錯誤是防御團隊錯誤地確定了事件范圍，導致驅逐不完全，使我們在環(huán)境中持續(xù)存在了近18個月（我們最終被踢出是因為我們駐留的服務器被他們的IT團隊在技術生命周期升級過程中退役）。改進響應過程以減少對手規(guī)避驅逐的機會歸結于擁有經過演練的可靠流程、識別妥協范圍的能力以及驗證對手完全根除的能力。
文檔
詳細描述XDR規(guī)避行為使我們能夠更好地識別檢測管道中的哪個組件失效，更重要的是，我們可以采取什么措施來修復它。大多數規(guī)避行為可以分為觀察（XDR是否發(fā)現了惡意行為）、檢測（XDR是否將行為正確識別為惡意）或響應（該行為是否導致安全團隊采取了適當的響應）。在下次遇到規(guī)避行為時，推動使用更具描述性的語言，并看看可以對你的補救過程進行哪些改進。
企業(yè)網D1net(hfnxjk.com)：
國內主流的to B IT門戶，旗下運營國內最大的甲方CIO專家?guī)旌椭橇敵黾吧缃黄脚_-信眾智(www.cioall.com)。旗下運營19個IT行業(yè)公眾號(微信搜索D1net即可關注)。
版權聲明：本文為企業(yè)網D1Net編譯，轉載需在文章開頭注明出處為：企業(yè)網D1Net，如果不注明出處，企業(yè)網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號