在本系列文章的第一篇，我們介紹了如何監(jiān)控和分析全網(wǎng)環(huán)境的網(wǎng)絡日志，并借助網(wǎng)絡觀察程序搜集到的各個網(wǎng)絡安全組上的日志，再利用日志分析工具（Log Analytics）從諸如可疑 IP 的訪問、每日流量的觀察、內(nèi)部網(wǎng)段互訪等維度來幫助企業(yè)的安全團隊定位存在風險的虛擬機。錯過這篇文章的同學，可以這里回看。

　

　　本篇將在此基礎上深入一步，在利用第一篇所介紹方法找出的高危虛擬機為目標的基礎上，我們將通過終端服務器日志的具體行為，利用 Azure Defender（原名 Azure Security Center）或Microsoft Defender for Endpoint（原名 Microsoft Defender ATP），根據(jù) MITRE ATT&CK 所定義的，以及微軟安全團隊總結的一些與當年威脅相關的動作，對應到具體的 SysLog 或 Windows Events 中的日志，從而監(jiān)控異常情況，并最終確定機器是否存在安全隱患。

　　

　　首先我們從第一個開箱即用的維度出發(fā)，通過 Denied Flow 可以看到，在業(yè)務低谷時段，也會觸發(fā)很高的 Denied Flows。隨后點擊右上角，可以查看當前所用的查詢語句，并在此基礎上做進一步的篩選和深入調(diào)查。

　　

　　AzureNetworkAnalytics_CL

　　| where SubType_s == "FlowLog"

　　| summarize TotalFlows = count（） by bin（TimeGenerated, 1h）, FlowStatus_s

　　| extend FlowStatus=iff（FlowStatus_s == 'D', 'Denied Flows', 'Allowed Flows'）

　　| project TimeGenerated, FlowStatus, TotalFlows

　　可以看到上述維度就是將表“AzureNetworkAnalytics_CL”按每一個小時為單位，加總了 FlowStatus，然后按照時間、流量狀態(tài)和總數(shù)繪制了上述圖表。

　　按照上述圖表我們想查看拒絕流量頂峰的那一個小時的流量具體情況，既在 UTC 2021-01-31T01:00:00Z 這個小時中，這些 Deny Flow 和 Allow Flow 具體落在了哪些服務器上。

　　AzureNetworkAnalytics_CL

　　| where SubType_s == "FlowLog"

　　| where FlowStatus_s == "D"

　　| where TimeGenerated between （todatetime（'2021-01-31T00:59:00Z'）  todatetime（'2021-01-31T02:00:00Z'））

　　| summarize TotalFlows = count（） by bin（TimeGenerated,1h）, VM_s, FlowStatus_s

　　//| extend FlowStatus=iff（FlowStatus_s == 'D', 'Denied Flows', 'Allowed Flows'）

　　| project TimeGenerated, TotalFlows, VM_s, FlowStatus_s

　　因此我們在上層篩選維度上增加了一個流量為拒絕流量以及高峰期的那一個小時的兩條命令，而在加總的維度中，進一步擴充了一個服務器的維度，最后我們用時2秒就得到了在高峰期那個小時內(nèi)，按照拒絕流量總和排序的每臺服務器的排名表。

　　

　　由此可以定義上述四臺為高風險服務器，當然從網(wǎng)絡端還可以進一步看下這些流量具體落到了哪幾個端口，這些流量從何而來，是否存在來自于可疑 IP 的流量訪問。

　　只需要在上述的搜索語句中，篩選到對應的虛擬機（用 VM_s,DestIP_s），然后添加 DestPort_d 字段的呈現(xiàn)，就可以按照時間逐次查看或加總查看端口在給定時間內(nèi)被攻擊的密度。

　　在模擬環(huán)境中，即可根據(jù)模型默認給出的一個攻擊量變化，即在11月3號的到4號幾乎翻倍的攻擊數(shù)量，進行進一步分析：

　　

　　利用上述查詢語句，找到攻擊者的攻擊目標和方式的變化，攻擊者從原先的平均攻擊的方式，在四號把攻擊資源集中起來，針對兩臺機器 middleware2 datahub 兩臺機器，進行1秒100次的攻擊。

　　

　　之后對這兩臺機器做深入調(diào)查，看攻擊的落點在哪些端口上，是什么密度，Allow Flow 在發(fā)生問題的時間段有沒有上升，Allow Flow 去了哪些端口等：

　　

　　

　　從上述攻擊中可以看到，可疑 IP 也有攻擊的參與，而這些 IP 的參與可能蘊含著更強大的攻擊手段或者更高級的攻擊方式，所以第二個維度上，我們就需要從可疑 IP 出發(fā)，來看他的攻擊落點在哪些地方：

　　

　　還是點擊面板上的查詢語句的按鈕，進入到查詢頁，具體來看受到可疑 IP 攻擊的機器的落點在哪里：

　　從被攻擊最多的資源里，選擇某臺機器的 IP，進行深入調(diào)查，這里添加一個篩選字段 AllowedInFlow，來看 IP 是否有攻入的痕跡，可以看到有6臺機器都與可疑 IP 有1000+以上的流量條目。這里在查詢語句的顯示上，利用 extend 定義了一個新參數(shù) CountryOrRegion，并和 SrcIP_s 合并成了一個新的參數(shù) IPAdress：

　　AzureNetworkAnalytics_CL

　　| where SubType_s == 'FlowLog' and  FASchemaVersion_s == '2' FlowType_s == 'MaliciousFlow'

　　| extend CountryOrRegion = iif（FlowType_s == 'AzurePublic', AzureRegion_s, Country_s）

　　| where FlowDirection_s == "I"

　　| summarize FlowCount = sum（FlowCount_d）, AllowedInFlows = sum（AllowedInFlows_d）, DeniedInFlows = sum（DeniedInFlows_d） by IPAdress = strcat（SrcIP_s, ' （', CountryOrRegion, '）'）, DestIP_s, VM_s

　　| sort by AllowedInFlows desc

　　

　　這里選擇10.195.12.17，查看具體攻擊的落點到了哪個端口上，這里選取攻擊相對集中的時間段，按照 DestPort_d 做匯總，考慮到攻擊的僵尸網(wǎng)絡不一定全被定義成可疑 IP，所以去掉了 FlowType_s 的篩選：

　　可以看到10.195.12.17這臺機器的5432端口收到了短時間內(nèi)的集中攻擊，推測是 PostgreSQL 的注入攻擊方式在嘗試弱口令的爆破方式。之后的進一步分析就需要開啟安全中心，來搜集虛擬機上的 Syslog 或者 Windows Events 是否有相應的入侵痕跡來診斷機器是否被攻破。

　　從可疑 IP 的動向其實就很容易想到一個極具危險性的表現(xiàn)，就是如果環(huán)境中的機器存在出站到可疑 IP 的 Flow，那就很能說明機器存在問題，這時候根據(jù)常規(guī)的攻擊鏈，我們就還勢必要考慮這些機器在內(nèi)部的橫向移動的痕跡。

　

　　//list all the activities of malicioius IPs

　　AzureNetworkAnalytics_CL

　　| where SubType_s == 'FlowLog' and FASchemaVersion_s == '2' and FlowType_s == 'MaliciousFlow' and FlowDirection_s == 'O'

　　| project TimeGenerated, SrcIP_s, VM_s, SourcePortRange_s, DestIP_s, DestPort_d, FlowDirection_s, AllowedOutFlows_d, DeniedOutFlows_d

　　

　　這里就抓到的內(nèi)部的10.195.5.4這臺機器到很多可疑 IP 的出站流量痕跡，很明顯，這臺虛擬機我們需要開啟安全中心進行保護，鑒于這臺機器是 Windows 機器，也建議從安全角度安裝一個叫做 Microsoft Antimalware 的擴展：

　

　　可以看到，這臺虛擬機要去不同的可疑 IP 下載 vercheck.ps1 這個腳本，由于一直失�。ˋntimalware攔截），所以會同時發(fā)起去不同 IP 的下載動作（會在后續(xù)的單機調(diào)查中具體展開），于此同時，我們也可以從網(wǎng)絡端，從時間維度或者 IP 維度來查看一些內(nèi)部橫向調(diào)查和移動的痕跡：

　　// see all related activity to a certain malicious IP

　　AzureNetworkAnalytics_CL

　　//| where FlowType_s in （'ExternalPublic', 'AzurePublic'）

　　| where * has "124.127.40.202"

　　| extend Flowtype = FlowType_s, Direction = iff（FlowDirection_s == 'I', 'In', 'Out'）, Result = iff（FlowDirection_s == 'I', iff（AllowedInFlows_d > 0, 'Allowed', 'Denied'）,iff（AllowedOutFlows_d > 0, 'Allowed', 'Denied'））, ['Source IP'] = SrcIP_s, ['Source Public IP'] = split（SrcPublicIPs_s, '|'）[0], ['Destination IP'] = DestIP_s, ['Destination Port'] = DestPort_d

　　| project TimeGenerated, Flowtype, Direction, Result, ['Source IP'], ['Source Public IP'], ['Destination IP'], ['Destination Port']

　　| sort by TimeGenerated asc

　　從 IP 維度可以查看當前可疑 IP 在環(huán)境內(nèi)的移動情況。但考慮到可能是一個網(wǎng)絡的整體行動，也可以從時間維度出發(fā)，查看攻擊前后環(huán)境里的波動有哪些。例如上述事件的發(fā)生時間是2020/11/9下午3點的這個時間段內(nèi)，那我們就可以查看2點、3點、4點的時間內(nèi)，從我們已經(jīng)定位的暴露的 IP 出去的，所有的 Flow 有哪些，從而對比出正常業(yè)務運作的動態(tài)和被攻擊后的變化。

　　統(tǒng)計發(fā)現(xiàn)，1點時共19條出站，2點時共21條出站，其中內(nèi)網(wǎng)之間的流量 IntraVNet 各為7、8條。

　　但到了3點，總共的條目就上升到了500多條，主要的增長是到 ExternalPublic 的流量。而在 IntraVNet 方面的端口除了上述規(guī)律的到達某些 IP 的某些端口外，增加了到某 IP 的3306端口（2次），某 IP 的22端口（2次），共13條。之后4點，5點又恢復了20條左右的流量。這些信息都需要進一步跟業(yè)務部門溝通核對，來判定這些流量是正常業(yè)務流量，還是攻擊者留下的痕跡。

　　以上就是我們從網(wǎng)絡端對流量深入調(diào)查一些維度，通過從異常流量的起伏，可疑 IP 的流量勘察，以及橫向移動的情況，我們可以動態(tài)的定位出疑似的暴露機器，從而加入到安全中心的觀察中，來判定在當前的幾個月中是否有被潛伏或者被攻擊的痕跡。更好的對我們的環(huán)境有整體的安全可見性和掌控度。