在本系列文章的第一篇，我们介绍了如何监控和分析全网环境的网络日志，并借助网络观察程序搜集到的各个网络安全组上的日志，再利用日志分析工具（Log Analytics）从诸如可疑 IP 的访问、每日流量的观察、内部网段互访等维度来帮助企业的安全团队定位存在风险的虚拟机。错过这篇文章的同学，可以这里回看。
本篇将在此基础上深入一步，在利用第一篇所介绍方法找出的高危虚拟机为目标的基础上，我们将通过终端服务器日志的具体行为，利用 Azure Defender（原名 Azure Security Center）或Microsoft Defender for Endpoint（原名 Microsoft Defender ATP），根据 MITRE ATT&CK 所定义的，以及微软安全团队总结的一些与当年威胁相关的动作，对应到具体的 SysLog 或 Windows Events 中的日志，从而监控异常情况，并最终确定机器是否存在安全隐患。
云端万事通—掌控全局动态
首先我们从第一个开箱即用的维度出发，通过 Denied Flow 可以看到，在业务低谷时段，也会触发很高的 Denied Flows。随后点击右上角，可以查看当前所用的查询语句，并在此基础上做进一步的筛选和深入调查。
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，然后按照时间、流量状态和总数绘制了上述图表。
按照上述图表我们想查看拒绝流量顶峰的那一个小时的流量具体情况，既在 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秒就得到了在高峰期那个小时内，按照拒绝流量总和排序的每台服务器的排名表。
由此可以定义上述四台为高风险服务器，当然从网络端还可以进一步看下这些流量具体落到了哪几个端口，这些流量从何而来，是否存在来自于可疑 IP 的流量访问。
只需要在上述的搜索语句中，筛选到对应的虚拟机（用 VM_s,DestIP_s），然后添加 DestPort_d 字段的呈现，就可以按照时间逐次查看或加总查看端口在给定时间内被攻击的密度。
在模拟环境中，即可根据模型默认给出的一个攻击量变化，即在11月3号的到4号几乎翻倍的攻击数量，进行进一步分析：
利用上述查询语句，找到攻击者的攻击目标和方式的变化，攻击者从原先的平均攻击的方式，在四号把攻击资源集中起来，针对两台机器 middleware2 datahub 两台机器，进行1秒100次的攻击。
之后对这两台机器做深入调查，看攻击的落点在哪些端口上，是什么密度，Allow Flow 在发生问题的时间段有没有上升，Allow Flow 去了哪些端口等：
江湖神算子—全面剖析局势
从上述攻击中可以看到，可疑 IP 也有攻击的参与，而这些 IP 的参与可能蕴含着更强大的攻击手段或者更高级的攻击方式，所以第二个维度上，我们就需要从可疑 IP 出发，来看他的攻击落点在哪些地方：
还是点击面板上的查询语句的按钮，进入到查询页，具体来看受到可疑 IP 攻击的机器的落点在哪里：
从被攻击最多的资源里，选择某台机器的 IP，进行深入调查，这里添加一个筛选字段 AllowedInFlow，来看 IP 是否有攻入的痕迹，可以看到有6台机器都与可疑 IP 有1000+以上的流量条目。这里在查询语句的显示上，利用 extend 定义了一个新参数 CountryOrRegion，并和 SrcIP_s 合并成了一个新的参数 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 做汇总，考虑到攻击的僵尸网络不一定全被定义成可疑 IP，所以去掉了 FlowType_s 的筛选：
可以看到10.195.12.17这台机器的5432端口收到了短时间内的集中攻击，推测是 PostgreSQL 的注入攻击方式在尝试弱口令的爆破方式。之后的进一步分析就需要开启安全中心，来搜集虚拟机上的 Syslog 或者 Windows Events 是否有相应的入侵痕迹来诊断机器是否被攻破。
悬丝诊脉—定位感染面
从可疑 IP 的动向其实就很容易想到一个极具危险性的表现，就是如果环境中的机器存在出站到可疑 IP 的 Flow，那就很能说明机器存在问题，这时候根据常规的攻击链，我们就还势必要考虑这些机器在内部的横向移动的痕迹。
首先我们先来发现环境内的机器出站到可疑 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
这里就抓到的内部的10.195.5.4这台机器到很多可疑 IP 的出站流量痕迹，很明显，这台虚拟机我们需要开启安全中心进行保护，鉴于这台机器是 Windows 机器，也建议从安全角度安装一个叫做 Microsoft Antimalware 的扩展：
可以看到，这台虚拟机要去不同的可疑 IP 下载 vercheck.ps1 这个脚本，由于一直失败（Antimalware拦截），所以会同时发起去不同 IP 的下载动作（会在后续的单机调查中具体展开），于此同时，我们也可以从网络端，从时间维度或者 IP 维度来查看一些内部横向调查和移动的痕迹：
// 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 在环境内的移动情况。但考虑到可能是一个网络的整体行动，也可以从时间维度出发，查看攻击前后环境里的波动有哪些。例如上述事件的发生时间是2020/11/9下午3点的这个时间段内，那我们就可以查看2点、3点、4点的时间内，从我们已经定位的暴露的 IP 出去的，所有的 Flow 有哪些，从而对比出正常业务运作的动态和被攻击后的变化。
统计发现，1点时共19条出站，2点时共21条出站，其中内网之间的流量 IntraVNet 各为7、8条。
但到了3点，总共的条目就上升到了500多条，主要的增长是到 ExternalPublic 的流量。而在 IntraVNet 方面的端口除了上述规律的到达某些 IP 的某些端口外，增加了到某 IP 的3306端口（2次），某 IP 的22端口（2次），共13条。之后4点，5点又恢复了20条左右的流量。这些信息都需要进一步跟业务部门沟通核对，来判定这些流量是正常业务流量，还是攻击者留下的痕迹。
总结
以上就是我们从网络端对流量深入调查一些维度，通过从异常流量的起伏，可疑 IP 的流量勘察，以及横向移动的情况，我们可以动态的定位出疑似的暴露机器，从而加入到安全中心的观察中，来判定在当前的几个月中是否有被潜伏或者被攻击的痕迹。更好的对我们的环境有整体的安全可见性和掌控度。
