Microsoft云：三招出手搞定安全隐患

小提示：您能找到这篇{Microsoft云：三招出手搞定安全隐患}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Microsoft云：三招出手搞定安全隐患内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

云时代，IT系统的安全监视必不可少。为了适应云部署的特点和全新用户需求，我们围绕企业云端安全监控设计了一套可一键部署也可动态调整的安全监控模板方案，借此能给用户带来最直观的安全监控方案以及后续深入调查的平台。

在本系列文章的第一篇，我们介绍了如何监控和分析全网环境的网络日志，并借助网络观察程序搜集到的各个网络安全组上的日志，再利用日志分析工具（Log Analytics）从诸如可疑IP的访问、每日流量的观察、内部网段互访等维度来帮助企业的安全团队定位存在风险的虚拟机。错过这篇文章的同学，可以点击回看。

本篇将在此基础上深入一步，在利用第一篇所介绍方法找出的高危虚拟机为目标的基础上，我们将通过终端服务器日志的具体行为，利用Azure Defender（原名Azure Security Center）或Microsoft Defender for Endpoint（原名Microsoft Defender ATP），根据MITRE ATT&CK所定义的，以及微软安全团队总结的一些与当年威胁相关的动作，对应到具体的SysLog或Windows Events中的日志，从而监控异常情况，并最终确定机器是否存在安全隐患。

< max-width: 100%; font-size: 16px; max-inline-size: 100%; cursor: text;">< font-size: 16px; max-width: 100%; text-align: left;">云端万事通—掌控全局动态

首先我们从第一个开箱即用的维度出发，通过Denied Flow可以看到，在业务低谷时段，也会触发很高的Denied Flows。随后点击右上角，可以查看当前所用的查询语句，并在此基础上做进一步的筛选和深入调查。

可以看到上述维度就是将表“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去了哪些端口等：

< max-width: 100%; font-size: 16px; max-inline-size: 100%; cursor: text;">< font-size: 16px; max-width: 100%; text-align: left;">江湖神算子—全面剖析局势

从上述攻击中可以看到，可疑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是否有相应的入侵痕迹来诊断机器是否被攻破。

< max-width: 100%; font-size: 16px; max-inline-size: 100%; cursor: text;">< font-size: 16px; max-width: 100%; text-align: left;">悬丝诊脉—定位感染面

从可疑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条左右的流量。这些信息都需要进一步跟业务部门沟通核对，来判定这些流量是正常业务流量，还是攻击者留下的痕迹。

< max-width: 100%; font-size: 16px; max-inline-size: 100%; cursor: text;">< font-size: 16px; max-width: 100%; text-align: left;">总结

以上就是我们从网络端对流量深入调查一些维度，通过从异常流量的起伏，可疑IP的流量勘察，以及横向移动的情况，我们可以动态的定位出疑似的暴露机器，从而加入到安全中心的观察中，来判定在当前的几个月中是否有被潜伏或者被攻击的痕迹。更好的对我们的环境有整体的安全可见性和掌控度。