一些攻防演练后的总结与思考 – 作者:si1ence

0x0 背景

时隔N个月之后当前再来复盘最近多次攻防演练活动的技术细节，希望能够温故而知新吧。每次的活动参与后，和大佬们坐在一个屋子里即使不说话也感觉学到了很多知识，经历了不知道多个彻夜难眠的值守，认真揣摩了网线那头的对手会从什么地方过来，什么时候带着什么样的payload向我发起问候，盯着满屏幕的安全事件告警过程中还掺杂着难闻的咖喱味IP，不禁想脱下蓝背心换上红马甲；凡事预则立不预则废；对最近几次活动当中的一些经验做个总结，希望能对后续的活动提供了思路争取后续把安全工作做的更好，个人愚见欢迎各位大佬指教斧正。

0x1安全事件分析

君子生非异也，善假于物也；作为一个资深的安全打工人在应对大量攻击的时候最省力的方式当然还是靠各种各样的安全设备；笔者私下喜欢把安全事件报警设备分为三大类：处置类、报警类、支撑类；处置类最常见的还是防火墙，一次性把策略开到严格模式看到一个安全事件报警的攻击IP就直接给封堵掉，消减对手的攻击基础设施资源；发现有跨网段的攻击IP直接隔离被控制的IP的主机；同时基于终端的杀毒软件类也是较好的处置，发现有webshell、后门文件、CS样本之类的文件可以直接隔离删除掉； 报警类的设备主要还是流量层面的监控设备多一些，比如概念很热门的态势感知、入侵检测（不同厂商的命名可能不一样意思大家都懂）、上网行为监控、NTA、邮件网关(旁路部署)、沙箱、蜜罐类，主要功能还是可以依靠对流量的分析、基于算法、规则、行为、文件信息、威胁情报等多个维度从流量当中发现恶意行为并进行报警，该类设备往往不具备处置能力需要人为的排查或者联动处置类的设备进行闭环，当然也有部分主机层面的IDS支持从主机行为上识别攻击行为进行报警；还有一类比如运维管理、流量审计、远程接入、统一访问之类的设备主要做一些溯源支持或业务场景的功能需求，在对抗场景中承担一些辅助的作用。 

在实际安全事件分析的阶段主要发现存在2个大问题阻止了我成为最强安全打工人。

0x2 二个问题

第一个问题安全事件太多且种类多样；由于很多甲方上帝网络比较大导致整个环境当中有很多的安全设备、同时考虑到异构的场景，可能还不止只有2家厂商的设备；我的对手可能只是轻描淡写的打开了一个常规的漏扫，当前监控页面可能就会出现100+个安全报警；比如一个热门的漏洞利用扫描往往包括常规的Shiro反序列、S2系列、THinkphp系列、Solar类、某OA系列类、已知CMS类、Weblogic类探测；一个S2可以从S2-016尝试到S2-061还有POST和Get方法、再测试几个简单的编码绕过；因为当前很多安全设备的检测能力主要还是基于规则检测的多一些，往往一种攻击方式会有多个检测规则方法和场景，部分安全厂商会命中一条报警一条，针对大量的安全事件告警防守人员很难做到点开数据包一个一个分析只能选择在边界对攻击IP进行封堵，宁教我负天下人、休叫天下人负我。最可怕的也就是如果本地挂了一个代理池，攻击源IP就会非常多非常多靠人工的方式工作量就太大了。

同时不同的安全厂商报警的安全事件、格式内容什么的都不一样，有些描述很详细XXX框架XXX漏洞XXX攻击(CVE-XXX-XXX)熟系的小伙伴一眼就知道发生了什么，有些描述就比较简单了就是一个XXX系统XXXXXX;由于吃了甲方金主的零食喝了红牛和奶茶工作还是做好的，此类场景下也只能点开这些安全事件的详细界面查看一些数据包举证，看一下攻击者的IP和时间、次数以及一些详细描述、结合攻击的上下文信息进行综合判断，遇上一个冷门的漏洞可能自己还需要上网搜一下，有一些的确是一些真实攻击的payload看一下有没有攻击成功的可能后直接封堵攻击IP就好；有一部分是业务场景下的误报需要告知到甲方金主（虽然他们也不一定会改），确定是正常业务的可以对该行为进行加白，某些金主的应用系统里面就喜欢在参数里面跟着各种sql查询的命令select insert union from and or group by之类的都有甚至很多结尾还有二个–符号，一条数据流可以产生7、8条报警事件都不想点开看；有一部分也不知道命中了什么规则看起来十分正常，心里面就有点犯嘀咕万一是个什么高端攻击自己能力有限看不出来怎么办?但是这个数据包怎么看都正常啊！嗯，还是先把这个IP给办了错杀无所谓了。 

第二个问题就是误报问题的出现，非攻击者的行为被识别成恶意行为就认为是误报，总体上来说误报也分二种场景：业务误报与检测误报；大多数参与攻防对抗的主力选手对用户上帝的网络情况基本上都是不求甚解，所以在很多业务场景下存在着很多惊喜的报警；比较常见的如一些文件共享、文件备份的服务器精彩遭受到大量的SMB暴力破解，或者一些网络管理的操作系统批量的对内网发起端口扫描、部分负载均衡的地址疯狂攻击内网某web服务器、数据平台遭受大量的ES未授权访问、邮件网关设备中了几百种僵尸网络等等的情况；这种情况下颇有一种考验革命友谊的意思，如果用户方对这些业务场景比较了解的话很多行为其实都是说的通，也能够理解这就是一个特殊的用户场景，如果用户方不了解这些业务场景就依赖于防守的小伙伴自己结合更多的行为去揣测或者引导用户确定对应的业务场景。踩的坑多了多多少少也就知道怎么回事了，主要结合一些其他的流量行为、最近一段时间内的全部行为做一个综合分析。比较多的坑包括负载均衡、反向代理、域控服务器、DNS转发、云平台、文件共享服务器、漏扫场景、运维应用场景、网关类接入场景、特殊应用场景等等，所以多了解点用户的使用场景对安全研究人员来说是值得的，毕竟攻防是个对抗的过程防御检测时候能派上用场，攻击渗透的时候一样有用；

如果说业务误报是和用户的二人转的话，规则误报的场景就可能是安全研究人员的独角戏。估计大多数的安全研究人员对一些攻击姿势的积累和知识储备远远多于对检测技术的积累，研究什么数据统计、关联算法、检测模型、机器学习、特征工程、流量分析之类的东西相对来说枯燥乏味的多，且实际动手的成本较高没有膜拜一下大佬的诡异姿势和绕过操作来的淋漓畅快一些，且不同安全厂商识别同一种的攻击方法也是林林总总更多的像一种猜测。 目前主要的检测方法普遍采用的方式可以简单的分为三大类、规则匹配(内容分析)、行为模型检测、关联分析识别;为了方便理解简单举几个例子解释一下，所谓的规则匹配主要是一种检测payload特征的一种方式，比如尝试一个脚本文件上传的检测方式主要思路就是从HTTP协议当中筛选出POST请求再分离出上传的文件，从文件名后缀和文件内容二个方面识别这个上传的文件到底是不是个脚本，典型的jsp、php、aspx、php3等文件后缀，再从文件内容当中检测是否包含一些<?jsp  eval assert等特殊的字符之类的方法，当然这里也有很多的反检测姿势在里面常见的代码混淆、编码绕过、加密、文件包含、后缀名伪造、解析漏洞等方式，所以除了黑名单策略之外往往还有一些白名单的技术在里面，非白即黑；往往内容特征检测都有一些字符的举证，比如在一个完整的HTTP数据包当中进行高亮标注清楚；行为检测的话往往是根据一段时间内的行为进行识别，常见的A主机扫描B主机在一定的时间内达到了一定的频率，次数就会识别成扫描或者尝试多少次账号暴力破解，需要设定多少个账号、多少个密码、失败次数等维度进行判断；此类报警的事件举证起来就相对模糊一些往往只是对行为进行语言性的描述。

0x3  告警优化场景

总得来说由于场景的多样性，对安全人员在研判的过程当中增加了不少的难度，同时也对研判人员对安全事件的理解与业务场期望可以景熟悉程度提出了更高的要求。所以最理想的状态应该是，无论是通过人员还是一定的算法在大量的安全事件报警面前进行聚合过滤后生成少数几个准确度高、危害度高的定向攻击行为出来；由于不同设备的产生的安全告警的数量是巨大的而且有很多真实攻击往往混杂在一些无用的扫描器的漏洞探测的情况发生，所以需要一种方法将这些安全事件进行聚类分析。常见的方法比如攻击源同源、攻击行为同源、时序关系相关、因果关系聚类、攻击场景聚类；

攻击同源还是比较理解100个安全事件的告警在同一个时间都来自于同一个外网攻击源IP、可以理解这些告警属于同一个组织或者团队。或者根据情报显示、多个攻击源IP属于同一个团伙。多个攻击IP地址在一定时间内接受到了大量来自某一个地区、某一个城市或者IP位于同一个供应商、在一个C段的场景都可以理解为攻击同源；

攻击行为同源主要从攻击手法层面出发，某个IP地址之前针对某个OA系统上传了一个php、在一定的时间内另外一个IP地址进行了IP的链接，可以认为当前二个IP地址对应的安全告警都属于同一个团队。或者当前某个外网资产在一定的时间段内先后遭受了S2-045、S2-046、S2-032的漏洞测试，可以认为当前几个IP存在较大的可能性属于同一个团队；

通过去重、聚类等方法在减少告警的数量后依然会存在较多的安全告警无法分析，在研判人员时间、精力都有限的条件下优先会选择分析哪些疑似攻击成功的攻击数据包。攻击者往往在攻击成功之前必然会有大量的探测、尝试攻击的攻击行为，一招致命的毕竟还是少数。如果从告警当中筛选出攻击成功的事件就显得格外重要；100次失败漏洞利用效果不如1次成功攻击来的可怕，目前重要的攻击成功判断方式主要依赖：请求payload与response内容的回显、多源数据的关联、前置关系的关联；

基于回显的攻击成功目前来看应该是最主流的一种方式，其实也比较简单每一次攻击从数据当中提取出payload部份再根据内置一些攻击者常常执行的命令whoami、ipconifg、net user、ifconfig、dir、ls等命令，在内置一些每一个对应命令返回内容的格式，前面命中了payload后面命中了返回的格式内容，即可以认为当前攻击的状态是成功的，此类方式的误报率还是可以控制的，单纯的依靠返回状态码、数据包大小等手法就不是很靠谱了。

多源数据关联的方式的思路主要还是来自于溯源分析，单纯的依靠流量层面的数据仅仅是对部分的攻击行为能够做识别。端点层面的探针提供的信息往往更加丰富一些，常见的SSH暴力破解、RDP暴力破解因为都是加密流量无法做到对密码和状态的判断，能够借助终端上的日志在流量层面的安全告警过程中读取OS的系统日志 4625、4624就容易的多；发现一个遭受webshell上传的行为，无法判断是否成功结合终端是否有文件生成；出现命令执行的场景，重点监控weblogic、IIS、Apahce此类进程的调用顺序在攻击成功的判断方面具备较好的效果与价值。

由于很多用户环境都不是特别干净，内网当中必定有一些中毒的机器特别是最近几年黑产的活动越来越频繁。在众多的安全告警当中也需要摈弃那部分中毒主机导致的告警，这部分主机的确是有问题只是当前处理的不是时候，也有一部分可能是不好处置或者处置不了一些历史遗留问题。所以有必要把这部分的事件给分离出来原则上需要对所有的安全报警类型进行分类，冰蝎webshell访问、FRP穿透、ICMP隧道通信、CS、MSF工具流量活动、特定内容的鱼叉邮件、DNSlog注入多数就是定向攻击的行为，XXX家族的威胁情报访问、各种payment、invoice发\票之类的病毒邮件就是典型的病毒类型的告警，内网横向的MS17-010、RDP暴力破解、网段扫描等场景二者都有可能，同样也是值得关注。

0x4未知威胁应对

相信对于绝大多数有多年安全从业经验的选手来说，对主流的攻击手法多多少都见过一些即使没有怎么使用过，用来实现什么目的都还是清楚的，在大多数的事件研判上问题应该都不大。最大的不确定性应该是担心某些行为根本没有安全事件产生，巧妇难为无米之炊，在活动当中使用到之前保存的一些0-day或者免杀的样本、加密流量、特定场景的绕过姿势导致检测的探针都没有报警就有点降维打击的感觉，所以整个活动当中大家都是兢兢业业的担心对手不来（感觉自己没有什么用），却也担心悄无声息来（感觉自己没有什么用），大家心里其实都没有底，目前针对未知威胁的检测比较成熟的方法主要有二大类：文件沙箱（针对样本的行为判断恶意）、行为异常识别（针对攻击者行为与正常业务行为的差异性）；对于很多高级白帽子来说对抗杀软绕过静态的特征扫描的思路也是林林总总，在文件沙箱虚拟执行的过程中难度就会更高一些，稍微有一些敏感的动作都比较容易标记成恶意行为于是就衍生了不少技术在动态执行、对抗虚拟机沙箱、反调试的一些技术的研究和知识储备。

由于一些重大的安全活动的原因，每年都有一些0-day、免杀样本、无特征工具、新的攻击手法被披露出来成为热门的话题之一，伴随着红蓝对抗的意识越来越强更加趋近于常态化工作，对当前的安全检测能力提出了更好的要求。目前主流的开源入侵检测引擎主要为Suricata、Snort、Zeek三个相对使用的多一些检测方法主要为基于特征的检测和基于异常的检测为主。针对于新的攻击手法与漏洞利用，基于异常的检测往往效果会更好一些，这里本质上是在区分攻击者与业务使用人员在信息不对称的场景下的特殊行为，对业务系统很熟悉的安全人员清晰的知道当前网络的拓扑、业务系统情况，以及访问关系图大概的路径、网段的划分以及安全设备的部署情况。试想一下在攻击者成功拿到某台服务器的权限之后期望更进一步的内网漫游，即使通过前期的信息收集拿到了很多账号和密码没有爆破、漏洞利用的攻击行为但是总得有一些网络访问或者登录行为，一台公网的Web服务器主动发起对其他网段的RDP访问，通过鱼叉邮件被控制的办公电脑对DMZ区的服务器发起连接、192.168的终端首次访问10.1网段的服务器这些行为结合对历史访问关系的判断都能够产生一定的告警并进行研判分析。 

除了内置一些典型的UserCase之外还可以依赖当前主流的一些分类算法统计区分异常。常规的一些算法对网络的流量访问关系基于低颗粒度，区分正常流量与异常流量的访问，k均值聚类算法（k-means clustering algorithm）是一种迭代求解的聚类分析算法，其步骤是随机选取K个对象作为初始的聚类中心，然后计算每个对象与各个种子聚类中心之间的距离，把每个对象分配给距离它最近的聚类中心。聚类中心以及分配给它们的对象就代表一个聚类，通过对一段时间内的访问关系进行学习分析建立一定的基线模型，在真实的攻防场景下出现的异常访问的点就值得重点关注和排查，特别是在内网横向的场景下具备较好的识别效果，加密流量、正常流量即使无法进行内容匹配或者特征识别还可以从网络层的行为进行判断识别是目前针对未知威胁的主要方向之一，相关的算法模型还有很多包括各种图、树、森林、概率转化、数据挖掘算法可参考应用此类方法最需要的还是大量可供学习的数据源或者针对不同场景下的特征向量提取。

类似的场景还比较多常见的比如异常流量的外发(超出日常水平)、基于webshell访问的稀有流量、运维场景下的首次访问、主机异常外联场景、敏感的鱼叉邮件、高可疑的加密流量通信、服务器之间的异常访问服务器、境外IP的异常登录等场景即使是目前常用的一些DNSlog、DOH技术都依靠一定时间窗口内的数据统计具备对应的检测方法和途径。很多高对抗的攻击行为的确很难基于传统的特征检测去识别，通过对主机行为、流量访问数据层面一定时间内所有的小的异常点的告警事件进行非线性累加与场景判断，相对大多数的攻击场景都发现。相对于特征检测而言往往异常识别的误报率经常会翻好几倍，数量与质量的保证都不一定会比较精确，多数只是一个异常点需要熟系业务的人对对应的情况进行识别排查，往往需要一定的知识积累和精力投入。于是有很多技术人员对此类告警觉得很不准觉得质量不高，但是攻防对抗的对抗的是双方选手的技术功底、精力、时间投入的方方面面，攻击者的定向攻击从最开始的信息收集、踩点打点、漏洞利用和信息收集甚至是0-day的挖掘同样花费了比较多时间精力为了bypass安全设备做的免杀与无特征通信的技术研究，防守人员不花点心思和精力分析就轻易发现岂不是在否认别人努力成果了。

0x5 一些方法论与资料

攻防对抗的场景是一个持续学习、持续改进的过程，冰冻三尺非一日之寒，需要安全人员对当前方向上的持续研究。安全效果与价值的可视化伴随着一些活动的展开变得更加容易和量化，用户对安全的需求的也更显的清晰可见，用实战化的结果来评估攻击者的技术水平、防守方的识别能力、网络当中的存在的脆弱性与可能存在的风险。PDCA是为了更好地理解和更有意识地在工作生活中使用PDCA思考模型，因为它真的太有用了，能力需要持续打磨非一夕一朝之劳。

Plan：从最开始的方案预研、针对不同的攻击手法与特征进行分析研究确定当前的方案与需要达到的目标；

Do:根据设计和布局进行具体运作，实现计划中的内容通过自己的思路尝试并检验效果

Check:通过运营对结果进行分析是否存在可以优化的空间，漏报误报检出的平衡点

Acion:通过对运营的结论进行改进与探索新的方法与方向

ATTCK模型通过对案例和攻击手法的梳理整理出了攻击这个阶段的一些知识点，比较适合部分安全研究人员探索，纸上得来终觉浅自己尝试测试一下一些攻击手法想必收获也会颇丰。目前该模型很多用户喜欢把这个模型作为一个安全全景图用于描述当前安全能力的现况，既然是全景图必然有很多攻击手法利用场景非常的特殊并不一定是热门事件或者常用技术，且有部分覆盖不到的地方，对于很多从业者和爱好者作为学习资料还是不错的也不必太过追捧。

Cyber Kill Chain“网络杀链”是由洛克希德.马丁研所发的威胁情报的驱动防御模型，用于指导识别攻击者为了达到入侵网络的目的所需完成的活动。攻击者往往也是按照一定的攻击顺序进行渗透入侵，对攻击者的攻击阶段有个良好的分类在后续溯源、风险判断都有比较大的帮助，由于KillChain主要是按照攻击者攻击手法进行参考属于纯粹的攻击者视角，比如这武器化/工具化这个阶段对受害者完全是无感知，对应很多安全知识理解不深刻的用户很难从中去明白当前发生了什么事件。另外一个问题是多数安全厂商按照不同的理解都有自己的安全告警阶段分类，导致很多企业用户在建设自己的SIEM、SOC、SOAR之类的平台的时候很难做到针对不同的厂家的安全事件的归一化，后续的报警的理解与关联分析就存在更大的障碍。

0x6 总结

都说安全建设是一个典型的木桶理论思想整体的安全能力只能取决于最薄弱的地方，大家普遍认可基于纵深网络的网络建设体系。对攻击者针对目标只需找到一个最薄弱的地方单点突破，而对应企业内部的安全建设却需要花费很大的成本在构建一个相对合理的防御体系，然而却很难做到面面俱到，突破点可能是一个弱密码、可能是github的路径、可能是开源组件的bug、可能是某个框架的漏洞、可能是某个OA的默认密码、可能是某些应用的访问控制不严等。偏偏安全所产生的价值并没有那么容易凸显且存在较高的认知门槛，不出安全事故感觉无价值出了事故发现也没有价值，but whatever

来源：freebuf.com 2020-12-08 19:25:54 by: si1ence