在本系列文章的第一篇，我們介紹了如何監(jiān)控和分析全網(wǎng)環(huán)境的網(wǎng)絡(luò)日志，并借助網(wǎng)絡(luò)觀察程序搜集到的各個(gè)網(wǎng)絡(luò)安全組上的日志，再利用日志分析工具（Log Analytics）從諸如可疑 IP 的訪問、每日流量的觀察、內(nèi)部網(wǎng)段互訪等維度來幫助企業(yè)的安全團(tuán)隊(duì)定位存在風(fēng)險(xiǎn)的虛擬機(jī)。錯(cuò)過這篇文章的同學(xué)，可以這里回看。
本篇將在此基礎(chǔ)上深入一步，在利用第一篇所介紹方法找出的高危虛擬機(jī)為目標(biāo)的基礎(chǔ)上，我們將通過終端服務(wù)器日志的具體行為，利用 Azure Defender（原名 Azure Security Center）或Microsoft Defender for Endpoint（原名 Microsoft Defender ATP），根據(jù) MITRE ATT&CK 所定義的，以及微軟安全團(tuán)隊(duì)總結(jié)的一些與當(dāng)年威脅相關(guān)的動作，對應(yīng)到具體的 SysLog 或 Windows Events 中的日志，從而監(jiān)控異常情況，并最終確定機(jī)器是否存在安全隱患。
云端萬事通—掌控全局動態(tài)
首先我們從第一個(gè)開箱即用的維度出發(fā)，通過 Denied Flow 可以看到，在業(yè)務(wù)低谷時(shí)段，也會觸發(fā)很高的 Denied Flows。隨后點(diǎn)擊右上角，可以查看當(dāng)前所用的查詢語句，并在此基礎(chǔ)上做進(jìn)一步的篩選和深入調(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”按每一個(gè)小時(shí)為單位，加總了 FlowStatus，然后按照時(shí)間、流量狀態(tài)和總數(shù)繪制了上述圖表。
按照上述圖表我們想查看拒絕流量頂峰的那一個(gè)小時(shí)的流量具體情況，既在 UTC 2021-01-31T01:00:00Z 這個(gè)小時(shí)中，這些 Deny Flow 和 Allow Flow 具體落在了哪些服務(wù)器上。
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
因此我們在上層篩選維度上增加了一個(gè)流量為拒絕流量以及高峰期的那一個(gè)小時(shí)的兩條命令，而在加總的維度中，進(jìn)一步擴(kuò)充了一個(gè)服務(wù)器的維度，最后我們用時(shí)2秒就得到了在高峰期那個(gè)小時(shí)內(nèi)，按照拒絕流量總和排序的每臺服務(wù)器的排名表。
由此可以定義上述四臺為高風(fēng)險(xiǎn)服務(wù)器，當(dāng)然從網(wǎng)絡(luò)端還可以進(jìn)一步看下這些流量具體落到了哪幾個(gè)端口，這些流量從何而來，是否存在來自于可疑 IP 的流量訪問。
只需要在上述的搜索語句中，篩選到對應(yīng)的虛擬機(jī)（用 VM_s,DestIP_s），然后添加 DestPort_d 字段的呈現(xiàn)，就可以按照時(shí)間逐次查看或加總查看端口在給定時(shí)間內(nèi)被攻擊的密度。
在模擬環(huán)境中，即可根據(jù)模型默認(rèn)給出的一個(gè)攻擊量變化，即在11月3號的到4號幾乎翻倍的攻擊數(shù)量，進(jìn)行進(jìn)一步分析：
利用上述查詢語句，找到攻擊者的攻擊目標(biāo)和方式的變化，攻擊者從原先的平均攻擊的方式，在四號把攻擊資源集中起來，針對兩臺機(jī)器 middleware2 datahub 兩臺機(jī)器，進(jìn)行1秒100次的攻擊。
之后對這兩臺機(jī)器做深入調(diào)查，看攻擊的落點(diǎn)在哪些端口上，是什么密度，Allow Flow 在發(fā)生問題的時(shí)間段有沒有上升，Allow Flow 去了哪些端口等：
江湖神算子—全面剖析局勢
從上述攻擊中可以看到，可疑 IP 也有攻擊的參與，而這些 IP 的參與可能蘊(yùn)含著更強(qiáng)大的攻擊手段或者更高級的攻擊方式，所以第二個(gè)維度上，我們就需要從可疑 IP 出發(fā)，來看他的攻擊落點(diǎn)在哪些地方：
還是點(diǎn)擊面板上的查詢語句的按鈕，進(jìn)入到查詢頁，具體來看受到可疑 IP 攻擊的機(jī)器的落點(diǎn)在哪里：
從被攻擊最多的資源里，選擇某臺機(jī)器的 IP，進(jìn)行深入調(diào)查，這里添加一個(gè)篩選字段 AllowedInFlow，來看 IP 是否有攻入的痕跡，可以看到有6臺機(jī)器都與可疑 IP 有1000+以上的流量條目。這里在查詢語句的顯示上，利用 extend 定義了一個(gè)新參數(shù) CountryOrRegion，并和 SrcIP_s 合并成了一個(gè)新的參數(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，查看具體攻擊的落點(diǎn)到了哪個(gè)端口上，這里選取攻擊相對集中的時(shí)間段，按照 DestPort_d 做匯總，考慮到攻擊的僵尸網(wǎng)絡(luò)不一定全被定義成可疑 IP，所以去掉了 FlowType_s 的篩選：
可以看到10.195.12.17這臺機(jī)器的5432端口收到了短時(shí)間內(nèi)的集中攻擊，推測是 PostgreSQL 的注入攻擊方式在嘗試弱口令的爆破方式。之后的進(jìn)一步分析就需要開啟安全中心，來搜集虛擬機(jī)上的 Syslog 或者 Windows Events 是否有相應(yīng)的入侵痕跡來診斷機(jī)器是否被攻破。
懸絲診脈—定位感染面
從可疑 IP 的動向其實(shí)就很容易想到一個(gè)極具危險(xiǎn)性的表現(xiàn)，就是如果環(huán)境中的機(jī)器存在出站到可疑 IP 的 Flow，那就很能說明機(jī)器存在問題，這時(shí)候根據(jù)常規(guī)的攻擊鏈，我們就還勢必要考慮這些機(jī)器在內(nèi)部的橫向移動的痕跡。
首先我們先來發(fā)現(xiàn)環(huán)境內(nèi)的機(jī)器出站到可疑 IP 的痕跡：
//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這臺機(jī)器到很多可疑 IP 的出站流量痕跡，很明顯，這臺虛擬機(jī)我們需要開啟安全中心進(jìn)行保護(hù)，鑒于這臺機(jī)器是 Windows 機(jī)器，也建議從安全角度安裝一個(gè)叫做 Microsoft Antimalware 的擴(kuò)展：
可以看到，這臺虛擬機(jī)要去不同的可疑 IP 下載 vercheck.ps1 這個(gè)腳本，由于一直失敗（Antimalware攔截），所以會同時(shí)發(fā)起去不同 IP 的下載動作（會在后續(xù)的單機(jī)調(diào)查中具體展開），于此同時(shí)，我們也可以從網(wǎng)絡(luò)端，從時(shí)間維度或者 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 維度可以查看當(dāng)前可疑 IP 在環(huán)境內(nèi)的移動情況。但考慮到可能是一個(gè)網(wǎng)絡(luò)的整體行動，也可以從時(shí)間維度出發(fā)，查看攻擊前后環(huán)境里的波動有哪些。例如上述事件的發(fā)生時(shí)間是2020/11/9下午3點(diǎn)的這個(gè)時(shí)間段內(nèi)，那我們就可以查看2點(diǎn)、3點(diǎn)、4點(diǎn)的時(shí)間內(nèi)，從我們已經(jīng)定位的暴露的 IP 出去的，所有的 Flow 有哪些，從而對比出正常業(yè)務(wù)運(yùn)作的動態(tài)和被攻擊后的變化。
統(tǒng)計(jì)發(fā)現(xiàn)，1點(diǎn)時(shí)共19條出站，2點(diǎn)時(shí)共21條出站，其中內(nèi)網(wǎng)之間的流量 IntraVNet 各為7、8條。
但到了3點(diǎn)，總共的條目就上升到了500多條，主要的增長是到 ExternalPublic 的流量。而在 IntraVNet 方面的端口除了上述規(guī)律的到達(dá)某些 IP 的某些端口外，增加了到某 IP 的3306端口（2次），某 IP 的22端口（2次），共13條。之后4點(diǎn)，5點(diǎn)又恢復(fù)了20條左右的流量。這些信息都需要進(jìn)一步跟業(yè)務(wù)部門溝通核對，來判定這些流量是正常業(yè)務(wù)流量，還是攻擊者留下的痕跡。
總結(jié)
以上就是我們從網(wǎng)絡(luò)端對流量深入調(diào)查一些維度，通過從異常流量的起伏，可疑 IP 的流量勘察，以及橫向移動的情況，我們可以動態(tài)的定位出疑似的暴露機(jī)器，從而加入到安全中心的觀察中，來判定在當(dāng)前的幾個(gè)月中是否有被潛伏或者被攻擊的痕跡。更好的對我們的環(huán)境有整體的安全可見性和掌控度。
