0x2 挖矿、僵尸网络与黑链从自己安全运营的反馈数据来看第一类的挖矿、僵尸网络的流程化攻击流量基本上可以占到到恶意攻击70%以上，其中以热门的几个挖矿团伙最为活跃如8220挖矿团伙、Bluehero挖矿团伙、H2Miner、Myking等团伙的攻击流量。
由于目前挖矿几乎按照了蠕虫模式的流程化攻击，导致中毒的主机也成为了发起攻击的来源，部分企业的资产尤其一些边缘资产中毒之后没有感知导致继续传播。这些挖矿的攻击方式也相对比较简单主要以一些热门的Nday的RCE漏洞、各类应用暴力破解、webshell上传、未授权访问等攻击场景为主，典型的如Docker、Jenkins、Redis、K8sAPI、Spark、Hadoop Yarn REST API未授权访问；Shiro/Fastjson的反序列化、S2全系列的RCE、weblogic的全系列RCE；暴力破解主要为一些SSH、RDP、web应用、数据库应用的的弱口令为主。部分尽职尽责的团伙往往也比较内卷，也会快速的融入一些新的EXP以提高成功率，前不久刚刚披露的log4j很快就被安排上了。
除了抢占先机之外，由于大部分都是存量市场，除了新的武器库之外，此类场景的攻击者往往还普遍从四个思路上出发：
- 干掉同行、排除异己独占资源；
- 增长持久化方法、防止被基础的操作给清理掉；
- 增加双平台的支持、不满足于window的场景也要兼容linux场景；
- 扩大攻击目标，主战场放在了安全建设相对脆弱的内网环境。
目前此类攻击场景技术维度上相对比较单一，常规的手法都是通过各类手法获取到一个shell之后执行一些下载命令从互联网的一个地址上拉取对应的挖矿套件(包含挖矿的配置文件、挖矿程序主体、内向传播的payload、资产发现模块、互联网探测模块等)、有脚本类类的Powershell、bat以及linux下的shell脚本，也有PE类的文件与ELF的程序主体。
部分攻击者为了躲避查杀还会利用一些系统白进程进行恶意代码的执行，典型的如一些mshta.exe、certifi.exe的程序往往payload甚至可以做到不落盘；根据最近几年的技术观察不得不承认做黑灰产也是一项很内卷的行业，稍微不注意技术上就容易掉队。
从排除异己的角度出发，毕竟挖矿的主要依靠的还是计算资源，卧榻之上岂容他人鼾睡，很多Linux的样本普遍就是在脚本里面内置很多其他同行的挖矿文件的路径和脚本，运行之前就先清理战场历史痕迹，甚至利用Iptables将现存在的风险基于访问控制进行封堵，防止后面别的团伙再次入侵，少数团伙甚至还会利用preload做一些进程的隐藏(这个的确有点卷)。
从持久化的方法出发，各种操作就更多一些如一些计划任务、系统服务、WMI、开机启动的常规操作，之前还偶然间接触过部分团伙利用MSSQL CLR写后门的处理起来还真的是挺棘手的，重要数据在手里每一条sql的查询命令都是小心翼翼的敲，就担心后续的攻击者如果都开始尝试用rootkit、文件替换、甚至驱动文件来进行做后门隐藏就真心有点麻烦了。
DDOS的僵尸网络遇见的概率也小了很多，不知道的是流量清洗技术的成熟、还是CDN、云抗D的已经应用更加广泛，抑或是自身的安全数据匮乏一些，此类型的僵尸网络除了少数的XorDDos、XnoteDDos、billgates的样本之外也没有太热门的样本，此类攻击手法普遍还是比较简单且纯粹，以SSH的暴力破解为主要的入侵手法。
之前一时好奇曾在互联网上搞了一个VP_S测试一下cowrie的蜜罐，结果意外的抓到了不少此类的样本。对于很多对业务连续性、可用性要高的业务除了常规的DDOS之外，还有很大部分是请求正常的高并发流量与BOT流量的管理对抗场景。从web业务场景来也同时存在大量的web入侵进行批量挂马、轮链、黑链、菠菜类的攻击流量，此类攻击场景普遍攻击手法也比较单一主要依靠webshell的上传漏洞为主，网页木马的质量与功能都异常丰富，环环相扣。
从应对措施的角度来思考，此类场景下的攻击手法虽然较多但总体上的技术门槛并不是很高，从安全风险的维度的来主要主要是二个关键问题：漏洞与弱口令。都是安全建设当中二个绕不开的问题，漏洞的存在一方面来源与自身的开发过程当中的的疏忽，另一方面来源于外部的风险输入。
自身的安全开发可以通过安全开发的基线、代码的审查、流程规范与借助于相应的安全检测工具(IAST、DAST)进行规避，对于很多明显的上传漏洞、存在安全风险的配置项目，已经存在高危风险的框架与组件都能积极的影响。同时借助于人工的渗透测试，从源头上能尽可能的减少存在的明显风险；对于很多新披露的漏洞能做到的一个及时的修复或者缓解。
伴随着当前安全检测技术的成熟，从一定程度上来讲以现有的防火墙、入侵检测与防御、web防火墙、以及各种概念包装后各不相同的态势感知，对此类攻击的行为的检出率基本上都没有什么挑战(及时更新规则库)。经过了3年的攻防演练之后，普遍能够对一些热门的攻击事件进行有效的应对，如当前热门的自动化联动响应(SOAR)通过多个安全产品的共同举证与处置，在此类场景下反而存在一些天然的优势(攻击剧本的paybook相对比较固定)也可较大程度上的减少安全运营的工作量。
所以这种广撒网的收割方式看似进攻猛烈异常，实际有效性的成功案例相对较少，少部分缺少安全防御与边缘资产、历史遗留的那部分资产反而是成为一个主要的受害群体中毒后对原本安全的内网造成了较大的威胁，所以最近一个关于ASM(攻击资产暴露面)的新品类出现，主要从互联网侧以红队的思路去发现更多未在防护清单内的”带病上线”资产。
0x3 勒索、定向攻击与窃密大多数时候都喜欢把挖矿勒索放在一起讨论，都是一些常见的黑产的一种能力变现的方式，从遇见的频率和所用的技术层面来区分的话，二者之间的入侵思路与模式都有着较大的区别。区别于广撒网的收割模式，目前大量的勒索团伙采取的方式更加趋近于APT的模式，针对性的广泛信息收集、步步为营的入侵模式、摸清家底后的快速摊牌。
从热门的wannacry广泛的使用MS17-010与RDP、SMB暴力破解进行传播扩散、后续部分GlobeImposter开始利用mimikatz抓取密码后的批量勒索、到现在热门的勒索phobos家族的爆发，可以明显的感知到勒索的过程当中人工参与的成分逐渐增大。之前参与过多起勒索的事件的溯源与复盘，印象深刻的一次发现攻击者入侵时间长达5个月之久，并在内网当中广泛的收集各类信息寻找核心的业务资产与服务器，内网横向阶段逐渐抛弃了低级的RDP爆破方式取而代之的是慢速的内网探测与基于主机信息收集后的定向RDP登录，甚至还有清理痕迹删除日志的习惯。
针对部分安装有终端杀毒的终端便是更加简单粗暴的用一些驱动层面的工具进行卸载，以至于在多数被勒索的主机的回收箱与操作记录当中，都有一些应急工具的痕迹。祸患常积于忽微，对比批量的RCE与漏洞探测，伴随大部分的恶意行为脱离了原本的攻击特征之后以至于市面上大部分的安全产品与方案显得心有余而力不足。从一定程度来讲当前的勒索产业链(勒索即服务)后端的入侵路径和定向攻击的的手法别无二致，技术上也更加难以识别期望依靠单个产品或者方案，想一劳永逸的避免这类事件的发现就显得有些的盲目自信了。
之所以把勒索、定向攻击与窃密场景归类在一起，是从入侵的手法来看具有高度的一致性，只是在最后目的各有其表；由于最近连续3年的攻防演练的活动，直接把对抗这件很专业的事件摆上了明面上来对比，很多参演方最后都发现很多安全产品的能力在真实的对抗场景当中的易用性、安全能力、场景适配上都存在较大的差距。简单总结一下，目前相对成功率较高的主要打点途径为：
- 存在高危漏洞、未在安全防护出的边缘资产，借此跳板接入内网网络；
- 针对办公网的员工发起的钓鱼、钓鲸邮件攻击；
- 针对热门/行业性的应用软件、网络设备、安全设备的0-day利用；
- 结合信息收集与配置不当、泄露账号的业务层面攻击。
另外一个比较大的特点在于安全厂商针对每一年的攻防演练进行复盘的的时候，也会结合一些典型案例进行专项的提升，也就变相的推动攻击手法的推陈出新，之前使用过的手法不加以改良的话在后续的活动当中的成功率会下降很多，甚至直接暴露自己。
于是可以看到当前很多攻击的隐蔽性得到了明显的提升，比如当前热门的DOH域前置技术、webshell的变形对抗、基于TCP/UDP的隧道通信、白进程远程/本地加载恶意dll、基于Java增强字节码的内存马后门、无文件攻击、CS马的bypassEDR、各类自定义加密的webshell通信流量、TV向日葵做远程软件等过手法已经屡见不鲜，即使在真实的打点过程当中，也可构造一些恶意的漏洞探测流量以瞒天过海，分散运营人员的精力。
还需要时刻提防来自于针对应用的各类0day、从安全建设方的角度来看，在此类场景下始终还是处于一个被动防守的过程，甚至不知道攻击者来自何处、使用什么攻击方式、攻击那些资产，虽然短时间也主推过欺骗防御技术却无法解决好二个主要的问题(业务仿真、漏洞反制)。
在大多数的群体当中安全人员往往投入的精力是资源相对有限，对网络资产的梳理都不甚清晰，在业务快速增长的背景下风险出现的更加频繁，仅仅依靠目前主流的安全设备进行监测在应对高隐蔽的攻击场景还存在较大的差距，现在很多场景开始主推威胁狩猎(Threat hunting)本着主动发现威胁的思路从蛛丝马迹处定位这些高级威胁。
0x4 业务安全安全建设的比较麻烦的一个问题在于如何去体现工作带来的价值，不出事的时候感觉没有什么存在感，有点安全问题的时候就显得日常的工作不完善，年底总结的时候比较常规的方式是总结一年的时间里面抵御了多少次XXX攻击，发现XXX个病毒、应急了XXX个事件；但是从业务安全的角度去思考的方式，就逐渐清晰了很多如果能说帮助业务减少了XXXX的经济损失，保护了XXX用户的信息安全、是不是就量化的比较明显了，从一定程度上说业务安全的建设比基础的安全建设更容易体现价值。
从web安全的的视角看，基础的web漏洞如sql Inject、XSS、文件包含类的出现的频率也逐步减少，伴随着开发人员的安全意识提升、各类框架提供的安全组件、安全厂商的设备覆盖，SDL的流程限制、以及少部分的开源RASP与基于Nginx类中间件的安全模块加持，此类漏洞的危害度被逐步减少。以至于在比较多的渗透测试场景更加偏好于对业务安全的漏洞挖掘、典型如账号撞库、越权访问、请求包重放、条件竞争、任意账号密码重置、短信验证码爆破等场景。
但是此类攻击往往造成的损失是在应用层面，典型的就是在前几年很多起步阶段的电商平台，很多都存在身份校验不严格导致的任意订单取消、支付漏洞、遍历订单的安全风险，此类场景下的安全建设往往需要贴合具体的业务场景进行剖析。
从技术的角度看，业务安全的视角最关键还是需要解决流程自动化攻击的问题，需要确认当前提交请求的发起对象是个人还是机器，个人用户在终端上的操作频率与输入都相对有限，解决好很多扫描工具、数据包发起工具、爬虫也能减少较多没有实际价值的告警噪声；同时在应对各类猫池、分布式的请求、养号等细分领域的背景下也依赖业务处不同地方的埋点与行为分析，定位隐藏在正常的业务逻辑下的恶意请求。
0x5 应对入侵-威胁检测当前主要的入侵检测类设备主要的形态有三大类，基于网络流量类、终端检测类、日志分析类；典型的网络流量类主要覆盖由Snort、Suricata衍生系列的各类IPS/IDS/FW/NTA类、终端检测类主要覆盖一些世面上常见的杀毒软件(启发式文件查杀、Yara特征)、行为检测类(IOA)，依靠对操作系统层面的网络行为(发起、接收)、进程/服务行为(拉起、创建)、文件行为(打开、写入、更新、删除)进行采集分析。
日志分析类常见的如splunk、日志易或者基于ES的二次开发的SIEM分析平台，主要数据源可以分析不同的安全设备的告警日志、部分web应用的日志、操作系统的日志等。除开热门的三大类之外还有一些专项的能力比如威胁情报、沙箱、蜜罐类的产品有等不同的产品形态。
稍微总结一些可以发现，此类安全产品主要的工作原理基本上都比较类似，基本上都是采集数据、处理数据、分析数据(场景分析、特征工程)、产生安全告警。区别在于不同的产品采集的数据对象并不相同，并且有不同的优势场景，比如在识别SSH暴力破解的场景，流量层的产品往往无法识别此类加密流量的数据内容因此只能从行为侧判断，但是在终端侧通过登录日志的分析可以轻易的获取到攻击者的源IP、登录的账号、时间等信息。
在数据泄露的场景依靠流量层的数据对保护对象的外发流量，从上行包、下行包的大小、频率进行统计或者异常检测时，相对于终端层面的开销与易用性层面就存在明显的优势。但是换一个思路的话可以发现，无论是终端数据的分析抑或是流量层的数据分析，最后需要识别的攻击场景基本上都是保持高度一层，花开两朵各表一枝，本身攻击行为就无法离开终端、网络与日志而独立存在至少之前缺少对应的探针(Sensor)进行采集，做安全运营、分析、溯源的人员都应该都知道，采集到的数据越全面描述一个攻击行为就越细致越准确，从安全效果的术语描述即高检出、低误报。
采集数据虽然各不相同，处理数据的思路却基本一致分字段进行拆解形成多个维度的key-value的键值对进行存储，数据量较少的时候以ES为主，单节点的ES经过性能优化EPS差不多在2W左右，少数数据量的场景可应用集群场景，针对海量数据普遍无论是分布式的存储还是当前热门的数据湖的概念，都是针对于格式化数据的存储方案(部分商业产品以流式引擎为主不存储原始数据)。
而呈现在用户面前的安全效果的价值，就更加依赖于对安全检测的人员具体能从这一批原始的数据当中能够提取到那些有用的信息；分析数据是比较能够体现一个人/团队安全能力与工程化能力的阶段，首要阶段是需要先确定具体应该识别怎么样的安全问题，以及过程中需要用什么那些数据、使用什么样的检测方法、预期达到什么样的效果。
关于具体的安全场景选择本身就是一个关键点，需要了解当前白帽子常用的攻击手法有那些，有一些的衍生的出来的变种，是在什么样的场景下会选择怎么样的攻击方式。比如从今年的攻防演练当中发现攻击者普遍大量的使用钓鱼邮件作为主要的攻击手法，就需要剖析一下这个场景我们需要采集到什么样的数据。
流量层的SMTP、Pop3、HTTP-webmail等内容、如果是加密的https的webmail或者私有协议，很大可能性就无法通过标准化的流量sensor获取到相关信息，终端的sensor能够识别到新增文件的执行并能对样本做进一步的查杀、却无法获取到邮件正文的内容，是否可以从流量侧去识别中毒后主机的C2过程？应对的免杀的样本是否有新的方法作为补充？等等一系列问题，都有依赖于安全研究的人员去思考，拿出一套切实可行的方案出来。
0x6 安全检测的思路安全检测主要思路粗略分基本就二种：基于模式匹配的误用检测、基于算法基线的异常检测。当前使用范围较广的依然是误用检测的逻辑，安全研究人员通过对已知黑样本/攻击手法当中提取对应的特征字段、可能是某一个特定传输协议的某一个特定的字符串内容、字符串集合，典型的如开源的yara规则识别恶意样本的场景。
由于攻击者的手法普遍变化较快导致一些规则过于严格的策略，无法识别到变种的攻击行为，从而在牺牲误报率的同时，提升检出率。单个特征的检测模式虽然准确、快速有效但依然面临着较大的安全挑战，尤其是特征维度增加的时候(多条件判断)，针对于每个不同维度的特征的权重就尤为重要了，手工去调整存在较大的误差性，那是否可以交给代码去完成了？答案是肯定的，目前很多的AI+安全思路本质上是解决了此类问题，以代码化的方式表示设定的好特征，通过大量的已分类的优质样本训练，最后将抽象的判断转化了多维向量的相乘(安全的尽头竟然是数学？)。
但由此以来也增加了很多的不确定性，导致很多安全问题最后无法被得到了一个准确的描述；而且此类方案有一个非常致命的问题，现有的安全能力是通过对已知的攻击手法的整理而得出的，也就意味着如果是一个全新的攻击方式，或者不在特征规则范围的行为将会被漏掉，而目前大量的已知的攻击同样也在衍生出更多的新的特点，导致安全研究人员需要不断的增加的知识，提取新的规则、识别新的风险，从这个背景看的话在对抗的过程中依然处于弱势地位，单纯的被动响应。
我们更加希望能够一个主动出击的方式，去应对各类威胁，通过对被保护的资产从细的颗粒度进行一定的时间的学习定位”出厂配置”的标准行为，只要后续的行为符合满足基线的访问即为正常、反之则为异常。基于这种思路即使对于各类变化多端的攻击行为，依然能够作为不变以应对万变，思路的确是相对新颖，但过程中对于百行为基线的建立、以具体场景和行为去建立基线却是当前最为主要的挑战，同时针对业务复杂/变更频繁的保护对象适用性也相对较差。长期来看二类不同的检测思路最终依然会走向一个统一的方向，以适应当前日益加剧的攻防不对等的思路。
很多做红队的大佬普遍思维比较活跃、奇思妙想且出人意料用安全行话说就是：表哥姿势真多，但如何将个人能力转化成一个产品的能力，将攻击的能力转化成防守的能力却依然有很多的挑战需要去面对。
最后一个话题是关于安全效果的评估的，感觉前几年的确是缺少一个合理的方式或者工具去评估现有安全产品的能力的，普遍都是各个产品或者厂家提供一批”公平公正”的优势POC的样本集，最后无论怎么测试反正都是自己最强，其他的都不行。直到最近的攻防演练反而成为一个最佳的实践方法，颇有一个不服跑个分的错觉，应该没有什么比实战的环境下的能力评估更有效、也更有说服力了。
安全效果依赖于运营，安全运营的发现的问题(误报、漏报)能够反作用于安全效果的改进，大家都试图在检出率与误报率之间寻求一个相对合理的平衡点，也颇有一种生成对抗网络的逻辑只是安全运营的工作更加依赖于白帽子的努力。
0x7 总结无论是在甲方(单场景)还是在安全厂商的乙方(多场景)目标都是保护业务免受安全风险，保护的业务可能有较大差异，但在面临的攻击手法与检测技术领域却是高度相似，从安全源头出发减少开发阶段出现的风险、上线后加以对应的安全防护与检测、出现安全问题的响应与溯源复盘，安全是一件很专业的事情，本质从来都是攻防技术的对抗。
由于今年写了比较多的内部文档颇有一些身心俱疲的无力感，刚好元旦三天有些许空闲时间总结自己一些对于反入侵技术的一些个人理解与趋势，文档之中颇有疏漏烦请各位斧正，如果有不同见解或思路，欢迎提出讨论。
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
显身卡
