浅谈安全运营的二三事 – 作者:si1ence

HW期间，为防范钓鱼，即日起FreeBuf将取消投稿文章的一切外部链接。给您带来的不便，敬请谅解~

0x0 背景

日光之下，并无新事。又是一年新旧交替，去年年底的时候FreeBuf的小编在关于安全工作总结这块还做了一个专题讨论，关于安全工作的总结复盘与规划估计也是许许多多安全从业者比较为难回答的问题了，最近大家也比较热门的讨论过关于安全运营的工作开展思路，结合自己的一些实际体验和各位大佬分享一下希望能够抛砖引玉。

目前无论是对甲方客户还是对乙方的技术提供商，普遍都遇见了一个比较大的问题，就是安全的价值到底要如何体现、如何量化、如何能能够看到效果，并以此体现自己的技术能力并让用户买单？

技术变现的难度一直都很高，而且还是信息安全这个行业更加偏技术门槛较高的行业；信息安全本身是一个基于计算机场景下的多学科交叉，从当前主流的行业需求来看主要方向还是在二进制安全、攻防对抗、安全治理三个大一点的需求多一些，论市场需求的话其实也很简单收集到信息，空闲时间多上一些互联网的招聘网站、大厂的招聘系统看看就好需要什么样的人才归纳总结一下就能达到一个七七八八的结论，感到职业生涯迷茫不知道何去何从的时候不妨以工作岗位的需求来成长自己。

细分的场景下就包括一些Web攻防、内网攻防、攻防对抗、安全服务交付、等级保护、数据安全治理、逆向分析、漏洞挖掘、可信计算、加密解密、企业安全体系建设、安全合规等等，细分下来可能还有更多此处不再赘述。关键问题在于这些知识点并不是一个递进成长关系，虽然都是做安全的可能就是完全不同的领域，很多对行业不了解的领导或者客户就默认为一个所谓的安全专家应该是什么都会的，对安全行业技术的认知差导致了很多工作开展时往往很难达到需求方的一个预期，或许这就是很多时候出现一些矛盾的源头。

0x1 运营方向

对安全运营而言目标相对比较明确看清当前安全能力的成熟度，进一步洞察技术差距从安全能力的点、攻击链、攻击面三个维度进行评估，从而制定后续的改进计划与商业市场下的差异性优势方案。安全能力的持续构建也还是离不开规划、实践、运营这三个维度，三个维度恰好行为了一个周期的闭环。规划的新方向通过实践进行交付、运营检验其中效果并发现不足与新的方向从而进一步影响到规划，运营不单单是对效果的检验更多的还有对新方向的探索与挖掘，是个项目当中最核心的一个角色。

与当前主流的互联网运营相对安全能力的运营往往具有更大的挑战，主要原因之一是对信息的收集来源较为困难，运营需要从数据当中发现问题、洞察到趋势与效果，所以数据的来源就至关重要毕竟巧妇难为无米之炊。

互联网场下的运营用户的行为收集就相对容易一些，毕竟这些APP是可以联网的且常常需要与服务器建立链接通信，运营人员可以在各种按钮埋点或者基于服务器的处理数据进行统计分析，从而得出一个相对中肯的结论比如我在一个页面上投放一个广告链接在后台就可以得出所有用户的点击时间、次数、停留时间、响应时间、之后的行为等等。

但是安全运营相对就复杂的很多

1.首先数据收集的难度就很大因为很多用户普遍不会让安全设备链接互联网、

2.第二就是安全的数据比较敏感用户对数据安全的要求普遍也较高，第三安全数据的分析存在较高的门槛且收集到的数据资料层次不齐。

3.安全数据的分析私下觉得这是一个对综合能力要求相对较高的一个岗位，也是整个运营工作当中最关键的一环。

安全攻击的行为和互联网业务的点击存在的一定的差异，安全攻击的数据的维度往往更多，一般的安全告警包括发生的事件、唯一标识、攻击类型、源、目标、攻击特征、告警描述等举证信息等内容，分析的第一步是需要确认当前事件的准备性，到底是不是误报、还是正常告警。这个其实反而是一件比较有难度的事情，当前主流的安全能力主要有三种方式基于特征的识别、基于行为的检测能力、基于关联分析的识别能力，由于分析人员和安全研究人员的割裂导致运营人员只能依靠现有的数据进行研判，一些常见的攻击举证字段相对容易一些比如识别一个文件是webshell上传，那么可以打开这个文件看一下是否包含一些特殊的函数名如eval、assert、create_function一类的，实在不行还可以借助D盾、河马一类的第三方工具辅助研判。

如果是一些基于HTTP协议的RCE还可以在数据包当中找寻对应的payload字符、一些暴力破解的告警需要收集到对应的行为特征比如是不是1秒发起了很多次不成功的登录请求、比如识别出有Nmap的攻击流量也可以从数据包当中去验证是否存在一个特殊的UA字段或者行为特征。对安全事件的研判，一定的是基于对当前攻防场景的理解、与猜测大概的检测手法到底是什么的背景下进行的，如果接触到一些不熟悉的领域就很容易走到一些盲区，对于很多经验不是很足的分析人员很多时候无法揣摩到对应的检测思路导致对安全告警的研判缺乏准确性，很有可能是识别到了一个0day最后被错判为误报。

另外一个问题在于很多研究攻防的安全人员对业务场景的认知不足，导致规则、方案的质量并不是很高，最开始的调研没有做好造成大量的误报、漏报等情况的出现，比较很多实验室的数据与效果总体来还是缺乏一个广泛的应用性。还有目前很多国内外引入了AI+安全的概念在对应的举证、研判上的难度无疑更上一层楼，很多描述类似雾里看花似的的很难进行识别，该场景下只能依靠运营人员对当前场景的猜测，并结合其他行为的上下文扩展开来了分析关联。 

针对于某一个安全事件，我们可以从点、线、面、场景来进行思考和剖析，比如最近二年玩的风声水起的勒索病毒的的确确给很多不懂安全的用户企业造成了比较大的损失，无论是精神上的还是经济上都给大家上了一课开始着力搞适合自己的安全防御体系。

从点来看有必要知道自己到底具备哪些场景下的安全识别能力(安全能力全景图)，这些能力的检出率、误报率、假阳性占比(业务误报率)、漏报率目前的数值是多少。安全能力的全景图普遍使用ATT&CK的覆盖度来描述当前能力，个人觉得此类只能从覆盖面来表述一定的问题因为在实际的攻击场景当中场景复杂的多，应该是一个多维的向量去描述当前安全能力的成熟度。覆盖与否、覆盖场景有多少、误报、检出、业务误报等维度。

除开对检出、误报、漏报率的场景数据统计之下，安全运营的工作还需要额外的针对一些流行且热门的攻击进行进行深入分析，比如针对某一个挖矿团伙可以定义他们的活动指纹用于监控该黑产团伙在当前互联网上的活跃情况，技术样本更新趋势，或者提取一些关键的威胁情报信息一类的操作。

同时针对于一些特定的能力进行运营能够较多的发现一些新类型的攻击手法，弥补一下运营人员自身在安全能力的缺失项。知己知彼，百战不殆。毕竟人的精力还是有限的往往也只能在某一个领域或者具体的方向上做的很深入，能覆盖很多个安全技能方向的大佬要么十分努力热爱这个行业，要么就是天赋异禀。

知行合一、格物致知。从理解勒索病毒的场景，首先需要弄清楚几个问题，攻击者的攻击对象是谁？那些能缴赎金且愿意为被加密的数据进行解密、安全建设不足且容易被入侵的群体。

常用的攻击技术手法是那些？从之前的自动化病毒传播到当前定向投毒实施勒索。为何避免被相关部门给盯上呢？基于国外的匿名邮箱联系、通过虚拟货币进行交易。如何保证受害者会交赎金？加密重要服务器的业务数据、保证操作系统可以运行。如何保障用户不会被自己破解算法？使用当前主流的非对称加密、对称加密的结合。如何保证受害者可以顺利的交钱？告诉受害者获取购买虚拟货币的方法，留下联系方式(非微信)。如何提高生产效率？建立完整的产业链条与分工，要有信誉度、防止信任危机。很多安全从业者喜欢用杀伤链(kill-chain)、攻击链、攻击阶段一类的方法用户描述攻击者的步骤，以及目前ATTCK整理好的攻击全景图，还有一些类似于作战图的概念出现，虽然攻击方式比较多常用的攻击手法到底有那些呢？基于RDP、SSH、SMB协议的弱口令爆破与登录，读取密码扩散其他主机；基于鱼叉邮件的方式进行样本投递；

0x2运营小插曲之shiro反序列化

安全的本质的确是在于攻防技术的演进，由于很多运营人员多数时候在反入侵这个方向上投入，在攻击姿势上很有可能与攻击者视角的技术存在差异性，导致安全能力的下降。所以还是需要在实际的工作中记得随时补充自己的安全能力，简单举几个比较有意思的例子吧也是自己的一些小收获。

Apache Shiro Java反序列化是去年比较热门的漏洞之一；Shiro提供了记住我（RememberMe）的功能对rememberMe的cookie做了加密处理，但是AES加密的密钥Key被硬编码在代码里，意味着每个人通过源代码都能拿到AES加密的密钥。因此攻击者构造一个恶意的对象并且对其序列化，AES加密，base64编码后，作为cookie的rememberMe字段发送。Shiro将rememberMe进行解密并且反序列化最终造成反序列化漏洞，具体原理不再多余赘述。

于是在一次应急响应过程中突出推测是秘钥泄露，但是用户一再确认自己用的不是默认秘钥，而且对应的流量层面安全设备并没有告警；补充一下，流量层面的安全设备对此类攻击的主要检测手法同样是收录了目前互联网上常用、默认的秘钥，由于是对称加密算法也公开然后依葫芦画瓢然后对相应的字段进行解密就可能看到明文；

开始排查溯源首先排查了一下access.log的日志（用户做了备份），由于一天的日志访问量比较大(GB数量级)所以还是找了很久，为了加快效果就简单写了一个python脚本筛选出了POST类型，并且返回码为200的访问记录，结果一无所获。由于缺乏一些必要的信息，一时间有点陷入僵局于是主动协调了真实的业务环境SSH登录上去，在web目录下的image文件夹却发现了隧道通信样本和webshell(由于是用户的生成环境主要是手工多一些没有借助其他工具)； 

借此为线索突破口于是又开始搜索access.log的日志，最后找到真实的webshell的链接记录。果然还是不能偷懒，攻击者应该是自定义的请求头、返回头和响应码302。由于真实访问的流量比较大，导致这些关键的信息被淹没在了没有用的信息当中。如果不是请求频率比较高，还真的不要容易注意到这条记录。 

后续通过流量层面的设备当中，按照对应的时间、访问请求等信息在网络层面的设备当中顺腾摸瓜逐步发现了真实写入webshell的数据包，后续结合对网络环境内的其他数据进行分析逐步还原到真实的攻击路径； 

这样的案例在真实环境当中还是经常出现，能够快速突破的原因还是依赖于攻击者留在web目录下的脚本文件，本质上还是有一些运气成分在里面的。由于流量层对此攻击的行为无法识别(加密流量)并通过RCE写入webshell能够较好的bypass流量层的安全设备，一条完整的供给链当中缺少一些蛛丝马迹，对于access日志的话也是数量太大分析起来花费的时间成本太高。于是复盘一下觉得整个攻击项目当中有2个点依然可以优化一下：

第一这里写入的冰蝎马太明显（没有免杀D盾可以直接杀）且路径也很明显(image目录下突然多个jsp)，命名也非常随意(1.jsp).后续研究了一下用户识别的网络层设备并不具备行为异常的检测能力，对此类敏感行为的访问没有识别，且未安装终端安全软件。

第二 链接该shell的时候请求的频率太快，打开日志的时候发现有大量针对此shell的访问都返回302，过程中应该利用VP.S开启一些漏洞扫描器之类的软件混淆视听，从而提高溯源的技术成本与时间成本。

0x3 运营小插曲之图片马执行

由于最近几年安全意识普遍提高了不少，很多开发者在上传接口普遍会做一些过滤白名单或者黑名单模式，很多成熟的框架往往会重点限制web脚本的文件上传，或者针对上传的文件进行重命名等方式进行修改，不返回文件路径等操作。就算攻击者伪造了一个图片马传递上去服务器之后，也需要借助解析漏洞、文件包含等方式进行利用，这个也有颇有运气成分在里面了。前段时间却遇见这个一个事件，发现有很多异常的流量访问主要是一些访问的资源都是ico文件 

由于孤陋寡闻一开始的时候甚至开始怀疑攻击者是不是更改了http.conf配置了不同类型的文件解析成脚本格式的规则，但是回头一想应该没有这个高的权限，通过看一下这个URL的请求格式99.99%的概率是reGeorg的HTTP隧道通信流量。但是这个favicon.ico跟了这么多参数是怎么回事，解析规则？不对还可以用htaccess文件，虽然普遍用法应该是用来做网站资源目录的访问控制、报错界面重定向，但是也可以配置Sethander来控制解析规则。还是有点吃惊样本以为知识一些CTF小技巧，没有想到出现在了实际的对抗场景当中。  

仔细想想后突然又觉得细思极恐，毕竟HTTP协议应用是如此的广泛在整个流量层面识别攻击行为普遍还是使用规则引擎多一些，要么要如何从访问行为上来识别一个图片就是一个图片，一个脚本就是一个脚本，一个rar压缩包是不是一个PE文件？那些没有文件后缀或者自定义格式文件访问到底是不是恶意的请求？只要伪装的足够好看起来和正常流量没有什么差异性就可以做到用户的无感知。但是依然避不开二个问题，即使流量层面的数据没有办法检测到始终绕不开终端层面的检测，毕竟文件在这里，就算做过免杀工具无法识别，就一个文件项目的文件对比，就很轻易的发现最近新增、修改时间、创建时间都不一样的文件，还是比较容易被发现只是时间成本会高一些罢了。于是，借助于前几年在windows端的比较热门的无文件攻击的思路，只有没有文件落地直接写入内存就可以完美避开这个问题。

0x4 运营小插曲之内存马

近几年在操作系统层的无文件攻击手法越来越多，最终目的都是想躲过安全设备的查杀。针对文件威胁普遍还是使用特征码扫码、启发式扫描、文件hash之类的手法进行全盘扫描，最常见的就是yara引擎，所谓的快速扫描就是针对一些恶意文件常见的目录进行扫描比如appdata、windows、font、temp目录之类。

但是扫描的文件普遍是有实体的，无论是隐藏文件也好，伪造的格式的PE文件也还是绕不开。无文件就比较好的解决了这个问题利用Powershell、Mshta、Certificate等系统进程，从互联网直接执行恶意代码也没有文件落地，利用定时任务、WMI实现权限维持。

最开始有关注到是因为rebeyond作者2018年的一个叫Memshell的开源项目https://github.com/rebeyond/memShell公布了一个基于Java服务器的内存马项目。2020年在某次重要的攻防演练时候又放出来Godzilla Shell大杀器支持了内存shell模块实现了在tomcat中注册、卸载内存马；直接注册一个哥斯拉的马或者冰蝎、菜刀的马，甚至是regeorg；

由于之前没有怎么接触过这类技术于是花了点时间找各种资料学习了一波目前主流的内存主要有3种实现方式：

1.servlet-api类：filter型、servlet型

2.spring类  拦截器、controller型

3.Java Instrumentation类   agent型

Filter型内存马首先是一个Filter类同时它在目录上没有对应的class文件。若dump出的class还有恶意代码那是内存马无疑，主要使用的方法java.lang.Runtime.getRuntime、defineClass、invoke，由于内存马没有实体要识别只能从内存当中出发，单纯依靠文件查杀肯定是不现实的。所以重点思路还是在内存扫描这一块，这是问题就比较麻烦主要是如何清理的、因为很多拉起的进程多数也是一些业务进程或者系统进程也不敢贸然删除或kill掉。

0x6 技术栈差异

除开另外一些基于线上的数据进行运营之外，重点还是有很多最终使用用户对产品的使用体验，由于很多用户群体的技术差异性、使用的业务环境、网络环境的差别导致对这些安全能力的效果一般存在较大的分歧，有时候不太懂原理的人员进行运营的时候反而容易造成一些误差，一些安全基础较好且使用频率较多的用户群体才是最具有运营价值的，所以除开基础的技术能力之外，还需要具备一些软实力在需求分析、与用户的非暴力沟通等方面。

很多攻防演练场景下表演主力的往往都是一些很姿势很多的攻击手秀各种操作，大家对值守防御的安全人员还是缺少一些表演的舞台和机会。个人觉得很多资深的防守人员在安全技术栈这一块并不比很多攻击手的少，只是术业有专攻虽然感觉都是搞安全的、搞对抗的，但是研究的方向具有较大的差异性。攻击大佬们平时关注在广泛的信息收集、打点、暴露面发现、免杀对抗、漏洞利用、0-day、社会工程、持久化、攻击链整理维度，只要姿势足够猥琐会玩，平时挖掘积累、收集一些常见框架组件的0-day，关键时候放放大招能够在一些活动当中相对容易的证明自己的技术实力于顺带的价值，Talk is cheap、Show me the Shell。

但是针对于很多做反入侵的人来看除了必要的渗透知识基础之外，还有一些特征工程、数据结构、方案实践、数据基础、应急响应、协议分析等领域知识，防御是针对的对象是攻击面的各个细节考虑的相关因素稍微要多一些相对而言就更加难的去体现自己的价值，天网恢恢到处都是缝隙，正如之前说的由于安全行业的门槛相对比较高导致很多人习惯性以结果为导向，看不懂过程可以看结果，但是怎么说呢，偏偏很多时候都是幸存者偏差的因素多一些。

作为安全运营人员平时往往需要对很多的数据进行整理，经常自我调侃为PPT工程师后来仔细一下也不只是有PPT还得有全家桶，所以得换个名字叫Office工程师。相对于很多枯燥得文字、数据表格、代码之类得文档的确需要很多图文并茂得东西来总结描述当前得工作成功。之前一直尝试过Kibana来作为前端展示工具、后面在一个小伙伴的推荐下发现还有功能更强大的grafana支持的插件非常多且支持的数据源更加丰富，实时化数据dashboard，手动拖格式，在日常的运营活动的说不定可以节省很大的精力整理图表，感兴趣的小伙伴可以自己尝试一下。

0x7 写在最后的话

April is coming还好也不是冬天；随着趋于频繁的各级攻防演练、网络安全日活动的开展，可以明显感受到用户安全意识得到了很大的提升，从基础的做安全就是买防火墙到现在主动部署一些类似于蜜罐类的优步类设备；从各种攻防活动当中可以明显发现，攻击者的手法也是越来越专业，使用了较多的加密流量、免杀、伪装、0-day、自定义协议等隐蔽的攻击手法来瞒天过海，攻击面也更加多样也逐渐从Web互联网服务的主战场迁移到IT类设备、邮件服务、泄露的账号、安全意识薄弱的用户等多个维度。此背景下无疑是对当前很多乙方提出了更高的技术要求还是依靠于传统的Snort、Suricata、Yara等签名类检测引擎叠加规则进行识别的背景下可能会面临更大的技术挑战。

未有知而不行者，知而不行，只是未知。加油吧，打工人。

来源：freebuf.com 2021-03-19 09:52:50 by: si1ence