各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 247期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

话题抢先看

1、CSDN挂马事件给我们带来的安全警醒，类似本次事件企业该如何进行应急排查？
本次事件范围大时间久，在被公开之前就已经进行了一段时间攻击。在得到安全情报之后该如何展开应急响应？由于已经过了一段时间木马可能在内网已经扩散，数据安全可能已经遭受威胁。如何排查业务安全和损失情况？

2、我们应该如何避免受到类似的攻击？
本次事件的初始阶段是一个CDN加速的JS文件被劫持。在日常开发中经常使用CDN引用文件，如果是第三方文件该如何进行防护？如果是自有资源如何管控资源安全引发的业务问题？

3、本次攻击的最终步骤是钓鱼，平时如何应对钓鱼攻击？
钓鱼防护是企业安全中老生常谈的问题，常见的处理方案无外乎加强人员意识培训或依赖于终端安全。在遇到类似本次事件的高仿真度以及病毒免杀的情况时以上手段效果有限，还有什么方式法或者策略可以提高安全能力？

背景：CSDN挂马事件给我们带来的安全警醒

Q：类似本次事件企业该如何进行应急排查？
本次事件范围大时间久，在被公开之前就已经进行了一段时间攻击。在得到安全情报之后该如何展开应急响应？由于已经过了一段时间木马可能在内网已经扩散，数据安全可能已经遭受威胁。如何排查业务安全和损失情况？

A1：

1、启动应急响应，阻断系统与外界的连接。

2、排查业务安全，服务器、代码、数据库。

3、计算损失，实际营运损失、业务连续性、声誉损失等。

A2：

1、WAF依据规则先拦截。

2、ELK、NTA关键词检索。

3、终端产品拦截。

4、追溯排除源、补丁。

A3：

1、阻断隔离，切备用环境。

2、网络侧NDR监控拦截、终端：EDR拦截。

3、横断分析（时间线进行研判溯源）。

4、分析数据库是否被倒库（ELK\其他日志服务器）。

A4：

1、首先封堵相关IOC。

2、其次确认受影响资产，包括但不局限于确认是否引用了相关的JS，更新安全检测规则、排查历史访问记录等。

3、对排查出来的恶意代码进行清除。

4、评估损失，重点关注数据方面。

A5：

应急先梳理；需要先盘清楚应急的范围，网络流量IOC、终端文件IOC、账号异常情况等。

网络快阻断；在网络层的设备可以优先阻断。

终端全查杀；在终端层面针对IOC进行查杀。

人员需谨慎；发布通告小心APT组织攻击行为。

监测保善后；通过监测发现疑似APT相关动作。

A6：

发现威胁，立即隔离，停止受影响服务，初步分析日志和篡改情况。

深入排查扩散路径，分析挂马入口、木马行为和可能影响的数据。

评估损失，确认数据是否泄露，业务影响范围。

修复漏洞并恢复业务，通知用户，确保系统安全。

复盘总结，完善防护措施，加强安全意识。

A7：

1、先隔离受感染的终端，防止进一步扩散。

2、检查系统日志、应用日志和网络安全设备日志，查看地方存在可疑行为；使用网络监控工具分析历史和实时流量，查找可疑的数据传输行为，特别是与外部未知IP地址的通信；文件完整性检查：对关键服务器和应用程序执行文件完整性验证，确认是否有文件被篡改或添加了恶意代码。

A8：

这起事件根源是因为上游CDN提供商被攻击导致，归根结底属于供应链攻击，得到情报后应该立刻进行问题定位。对于这类问题，网站防篡改就能及时发现并解决不会让事件扩大化，定位分析后，及时将木马Hash加入杀软和EDR的黑名单即可，同时结合安全设备相关日志，对已中招的用户和设备进行应急处置。

A9：

定期做好业务系统和网站的源代码审计，及时尽早发现安全问题。同时，做好网站的实时防篡改、防挂马、黑链暗链的检测，市面上有很多SaaS化的云监测产品，是可以从互联网的不同节点上去自动爬取，并对发现可疑的链接或者篡改下发预警。针对带有政治性的挂马事件，则需要第一时间立刻下线网站，对服务器做应急响应处置。

A10：

先召集安全专家、网络与系统管理员、法务人员组成应急小组。接着收集攻击类型、入侵时间、受影响范围等信息。然后在网络层面，隔离感染区域，设防火墙规则防扩散；系统层面，扫描服务器与终端，查进程与日志找异常。最后评估业务，测试功能是否正常，校验数据完整性与保密性，从业务中断损失、恢复成本算经济损失，依客户投诉与社交媒体评价评估声誉损失。

A11：

这种长时间的控制情况下，应该先对样本以及攻击源头进行分析。根据攻击横向手法进行全面加固整改，攻击源头全面封堵。当然这是救火队员的视角。还是要做好日常的事前检测监控防御三位一体运营机制。

A12：

1、应急角度来说：只能是全面排查引用范围，明确是供应链攻击还是篡改行为。篡改行为的话就大条了，走蓝队应急全家桶，应急响应流程。

2、针对供应链攻击，应该还是考虑安全左移，建立完善的供应链安全管理体系，DevSecOps全家桶，对源代码层面进行审核及管控；加强供应链风险管理，对供应链中的风险进行识别、评估和控制，降低供应链攻击的风险；建立应急响应机制，一旦发生供应链攻击，能够迅速采取措施，降低损失。

3、常远考虑外包威胁情报猎人，针对本企业网络安全事件进行跟踪。协同市场部门控制舆情影响。

A13：

真实场景：发现告警IP->没有安服费用->全盘查杀没有报毒->反正电脑不重要，重装->来一个重装一个->所有告警IP都重装了->没告警了->over

我觉得我们单位的现状的话，如果某电脑有告警，应该是很难定位到这种攻击的。

Q：我们应该如何避免受到类似的攻击？
本次事件的初始阶段是一个CDN加速的JS文件被劫持。在日常开发中经常使用CDN引用文件，如果是第三方文件该如何进行防护？如果是自有资源如何管控资源安全引发的业务问题？

A14：

最傻的方式就是监控源站，对比加速站。

A15：

都采用HTTPS+启用HSTS就行，只允许HTTPS协议就能防止篡改了。

A16：

预防：防篡改  

检测：JS+AI分析

响应：一键回滚

A17：

探针，全国所有省份部署探针，除非全国全部劫持了，否则会有不一样的访问结果。

A18：

日常开发用CDN引用文件的时候，如果是第三方文件，挑有好口碑、安全记录佳且有强防护措施的 CDN供应商，参考其他用户评价与行业安全评级。自有资源的话，要严格把控资源的访问权限，定期检查文件完整性与安全性，更新时做好备份与测试，防止因资源变动引发业务问题，比如文件被篡改或出错影响业务正常运行。

A19：

感觉发的都是落地有点困难小公司用不到，大公司组织架构复杂，推行太难了。

下载到本地做源代码审计，成本太大了，供应链攻击这种，按照合同来啊，责任共担模型又不是摆设。

A20：

CSDN这个事情，是CDN回源被劫持了，还是CDN自己中招挂的马？回源的话，那HTTPS回源应该有点用。

A21：

如果经常清理CDN缓存，那么这个被劫持的JS会不会也被清理？

A22：

没用，经常清缓存，还要CDN干啥？

A23：

例如几天清理一次之类的。第一次访问慢一点，后面就快了。这样子就能把植入JS的文件也顺便清理了。

A24：

如果清理缓存，你怎么知道JS就准确被清理了，用户真实缓存咋办。

A25：

还可以清理了之后继续中毒。

A26：

这是基本操作。你清理缓存，意味着破坏了原始需求，那就不需要CDN了，反正得实时刷新。

A27：

这是这个事件的一环，不点击应该就没事。

再加一个，保持浏览器是最新版本吧，这样的话，如果是攻击浏览器，不是0day就做不到了，PE可执行文件是做了免杀的。

A28：

网站应该部署安全监测产品，大多都能动态持续的监测网站是否被挂马。另外最最基本的，网站防篡改系统应该部署一下吧，这个就算写个脚本定时监控也不难，总的来说，网站被挂马显然是低级攻击，但是影响却广泛，类似前段时间的教育系统短信平台弱口令，暴露出基础防范能力不足，天天盯着APT、0day啥的，反而基本的安全防护没重视。

A29：

之前我碰过类似的，手机APP弹足彩广告。后来排查发现是免费白嫖的CDN被投毒，客户端请求时CDN返回篡改后的恶意JS文件，就弹广告了。

经验教训：能用商业CDN就用商业的别贪便宜；

不过CSDN应该不会贪这便宜，所以……没太多好的想法，只能等用户来投诉才能发现？

A30：

又去搜了一下挂马事件分析：

最终会引导受害者下载并执行.exe文件，所以回归到了反钓鱼

1、增强安全意识，根据安全公司分析，exe样本是免杀的，识破了假冒页面，就不会去下载。

2、由于exe样本具体有啥网络行为，不太清楚，所以依赖于本机行为检测的终端/主机安全软件，看能不能发力检测出静态特征库中的未知恶意代码。

Q：本次攻击的最终步骤是钓鱼，平时如何应对钓鱼攻击？
钓鱼防护是企业安全中老生常谈的问题，常见的处理方案无外乎加强人员意识培训或依赖于终端安全。在遇到类似本次事件的高仿真度以及病毒免杀的情况时以上手段效果有限，还有什么方式法或者策略可以提高安全能力？

A31：

直接拒绝接受所有外部邮箱邮件，然后内外网隔离不给上网。

A32：

终端安全：如果是XDR等设备，会引发恶意行为的告警。邮箱安全在邮件落地前可以通过沙箱进行查杀。

A33：

网络层：建立独立的网络层隔离环境；可分为外网区域、测试区域、办公区域、服务器区域；区域之间进行管控。

应用层：终端检测产品、沙箱等等。

服务层：自动化钓鱼、内外网邮箱等等。

A34：

1、部署邮件网关啥的，提升钓鱼邮件的检测能力。

2、最好的办法是查看邮件的终端不出网，如果必须出网，那么可以在网络出口部署检测设备，这个设备最好支持威胁情报检测。

剩下的听天由命了。

A35：

这个相当于是利用CSDN进行钓鱼，本质上受害者不是企业内部人员，反而应该从法务的角度来评估了。如何确定黑客，降低企业损失。

A36：

遇到高仿真且病毒免杀的情况，可以增加多因素身份验证，比如除了密码再加上短信验证码等。定期进行模拟钓鱼演练，让员工熟悉各种钓鱼手段。对邮件来源进行深度检测，过滤掉可疑的发件地址和域名。及时更新系统和软件补丁，封堵可能被利用的漏洞。

A37：

多来高仿真演练，可以买这方面产品服务，失陷的上红榜，我记得券商有弄过这套方案。提高安全能力不是一朝一夕，纵深防御类方案看预算吧，定期演练主要侧重在在遇到安全事件，要各部门联动起来知道自己也是应急响应一份子，知道怎么做，真的去做，后期优化。

A38：

供应链污染确实很难应对，这次还是定向钓鱼，应对供应链攻击，老版本因为潜伏期的问题反而比较安全。

A39：

供应链安全这块，最好是国内有主管机构推动，由一线大厂分开负责常用开源组件的安全审核，保证软件供应链的相对安全。

A40：

之前听电信的分享，是有，公安部三所牵头，和电信搞了个供应链安全能力分中心。

A41：

这个感觉是收费的，那么多开源组件靠几个机构做不现实，最好是大厂做供应链审核后发布安全的源给我们用，反正他们自己用也要安全审核，放出来做做公益嘛，顺便统一下标准。

A42：

你还想白嫖大厂？

A43：

放出来做公益就很难，软件源，镜像源看看之前的风波。

A44：

可以少收点钱嘛，用的公司多了，收益不就上去了。

A45：

把所有Windows都换掉，就不会中这次钓鱼了。（狗头）

A46：

好方法。内部换成ARM内核，解决6成木马。

A47：

你这是因噎废食啊，服务器换了业务还能跑得起来不？

A48：

有位对抗APT的专家推荐过这个方法；这么些年就没见过落地场景。

A49：

现在的马很智能的，基本全架构支持。

A50：

钓鱼就是安全意识的事，搞别的没用，我就想点，你能咋地？

A51：

如果把钓鱼攻击的最终目的缩小到获取凭证或者信息系统突破上，那么相关系统的口令管理，可以考虑上MFA，或者OTP这种验证，现在大家的安全意识还是有的，傻傻的主动输密码钓鱼已经很难了，但是点击个什么恶意软件，还是存在的，在这样的场景下，二次验证可以拦截到一些攻击。

我们现在钓鱼演练，基本上钓不到主动输入的口令了。

A52：

尝试过这种防护；当时因为Token被抓出来，所以绕过了。后来将密码和OTP废除，换成证书、绑定设备、通讯加密，才有好转。

当然这办法，成本也很高。

A53：

上干货！可以参考下我这个，建立公司内部安全平台，在线答题赚积分，换小礼品。

搞积分是个不错点，化悲伤为力量，内部人员安全意识积分礼物制 ，再拉个海报 ，逼格就上来了。

本周话题总结

本期话题围绕CSDN挂马事件探讨安全问题。应急排查方面，企业在事件发生后应立即启动应急响应，从网络、终端等多层面进行排查，如阻断连接、排查业务安全与损失、分析攻击源头、评估影响并修复等，还可组建应急小组协同工作。

在避免类似攻击上，对于第三方CDN文件，要选择优质供应商，自有资源则严格管控权限；同时可采用 HTTPS等技术手段防护，定期清理缓存、部署监测和防篡改系统。

应对钓鱼攻击时，除加强人员培训和依赖终端安全外，还可部署邮件网关等设备，增加多因素身份验证，定期演练，建立内部安全平台提升员工安全意识，更换口令管理方式等。

近期群内答疑解惑

Q：如果别人不断换IP对业务进行访问，暂时不确定是否DDos，并且都建立正常连接每个IP每次流量都很小，怎么处理？

A1：

不影响业务就让他连呗，影响业务就封了它，如果封错会有电话的。

A2：

如果你的资源充足，而且这个接口是公开的，不用管吧，只要对当前服务没压力。

A3：

我拿SQL手搓，分类极值检测算法，算法检测到IP的自动封2~5秒。

A4：

请教是怎么个逻辑计算出来需要封堵？

A5：

算法是给老东家写的，不能给你公式。思路就是按照极值将IP进行分类，分类的越细，取极小值，极小值在短时间内可以判断出来，然后阻断。最短时间也要>=2分钟。

A6：

为什么流量很小还要处理，具体是啥场景？

A7：

是每次都换IP，每个IP访问量小，但他同时多个IP在请求，流量就上来了。

A8：

我是后来上了CDN好了很多，但是今天看到流量劫持，我又emo了。

A9：

如果是浏览器访问的业务，WAF上下发JS挑战，还有就是看下他的TLS指纹之类的。

A10：

还可以有其他办法，比如说计算请求的相似度；这种拦截速度会慢一些。这种方式都有个前提，就是实时计算结果可以和工作流联动。

Q：请教个技术问题，有啥方法可以检查内部的SSO账户有没有弱口令的？

没有态势，之前想用Hydra，它好像只能验证ldap协议的连接密码，而不是用户密码。

A1：

通过流量是最快的，一抓一大把。

A2：

没有设备，是个大问题。

A3：

年前POC，POC完了，觉得还行再做预算，这不就有设备用了。

A4：

没得，它想搞全量。

A5：

还有一个办法，写个脚本把自己的弱口令字典用SSO的加密算法算一遍生成对应的密文，然后对比数据库里的密文，命中就是弱口令。

A6：

SSO账号还有弱口令啊？规划的时候不是有密码策略吗？

A7：

这个不是很容易绕过吗，username+12345满足位数，最近一大堆账户被爆。

A8：

态势是最安全的方法，你如果用POC去验证的话，那可能会导致大量账号被锁。。。

A9：

你的规范是大小写加数字加符号，很多人不都是公司名+@+年份吗？

A10：

用流控，这些都没用，做二次认证，弱口令就不存在了。

A11：

有验证码，基本你就撞不了库了，默认屏蔽公司名，做策略的时候要加上，也不能连号、连单词。

A12：

开发的时候没做安全评审啊，这种上线后改最麻烦。我们现在都不敢动这玩意，有些字段都是Hash，你也不清楚哪个是弱口令，常见的跑一下也没用，只能是要求，长时间没登录的下次要求改密后登录，然后在前端加个验证，在前端哪里做一个密码判断，低密码要求改，但是可以被绕过。

A13：

你是安全侧还是研发侧？安全侧，发现一个弱口令报一个就行了，根本问题甩给研发.

A14：

那只能用老方法了，拉库或者爆破，拉库又存在一个问题，安全人员有没有权力去拉生产的数据库。我觉得安全人员拉数据库密码校验是否有弱口令，这个行为本来就是不合规的。以前我权限比较大，几朵云的所有最高权限都有，但是我也不太敢去碰。

A15：

不可能给你的，我们连主机权限都没。

A16：

不同公司不一样，有些IT跟安全是一起的，有些是分开的，有些安全在运维下面，会好点。

Q：买来私有化部署的软件也要做等保吗?比如OA，收到整改通知了。

A1：

要，等保不管你是自己研发还是买来的。换域名或者缩小到内网使用。

A2：

是在内网用的，都在内网隔离的。

A3：

那就不管它了，你自己申诉，系统只在内网使用，无敏感数据。

A4：

内网使用。Level1的等保，内部自查就行。

A5：

行，给评审弄个一级，感觉最靠谱些，免得再搞。

A6：

等保有分级的，你按照那个分级说明，说明一下，一级也不要弄，人家会问，你为啥评一级，不是二级、三级。

A7：

等保是自主定级，按我的经验一般问题不大，你就说内网使用，不会影响其他群体，而且也没啥重要数据，自主定个一级就好了。

A8：

这个重要数据，依据什么标准？

A9：

有定级指南的，按照那个东西来就完事了。

送你一本网安人的“小绿书”

光看不过瘾？想要加入话题深入交流？

那就来FreeBuf知识大陆电台小程序

网安人的“小绿书”

找报告、搜文档
行业新闻 、经验分享、职场八卦、同行互动

AI变声和匿名功能

专为社恐人士打造

让大家以更轻松的姿态

随时随地，想聊就聊

我们已经邀请数位网安行业大牛开设电台房间

等你来「撩」

扫码进入小程序，参与话题讨论

甲方群最新动态

上期话题回顾：

密码本与弱口令的应对方案；不规范开发应用的安全风险处理

活动回顾：

迈向安全服务化，探索网安行业和社区发展新动能 | FCIS 2024网络安全创新大会举行

近期热点资讯

Palo Alto防火墙存在高危漏洞，触发无需交互和权限

SEO 中毒：网络犯罪分子如何将搜索引擎变成陷阱

日本航空遭黑客攻击，大量航班延误
Windows Defender成黑客武器，可禁用EDR

特朗普政府2.0：网安政策重大转向，CISA收缩，减少监管

FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！

【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】

注：目前1群、2群、3群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员

“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1300+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。