CSDN投毒是谁干的（一）
原创 热心网友 2025-01-23 07:00 泰国
是谁呢？
12月12号一哥报道了 CSDN 挂马攻击事件，引起了我强烈的兴趣。当时花了大概两周时间把素人能接触到的信息整理了七七八八，折腾出来一个 3 万多字快 500 张图的文档，信息量有点大导致身边朋友没几个人有耐心看完。
另外当时感觉自己基本已经把这个事分析完了，信息搜集的算是已经比较全面，后来也是实在分析累了就没再跟进了。
但是比较巧合的是前几天这个事竟然又出现了两次转折，导致我意外发现这个团队在 QAX 发文之后还一直处于活跃状态。基于 “有的受害者一直不知道自己已经中招了并且还在被持续内网横向” 的情况，我决定在过年之前把追踪分析的结果总结拆分成几部分发一下。
建议
如果你是媒体相关单位的网络安全岗位，非常建议你拉到文末的 IOC 部分回溯排查一下自家内网，这可能涉及到安稳过个好年🤣。
如果你是互联网大厂的安全运营相关岗位，也可以顺手一搜，后来的分析发现攻击者的目标清单里包含少部分互联网目标。
TL;DR
基于网络 ioc、二进制样本以及其他威胁情报，对 CSDN 投毒事件操作者的追踪尝试，最终得出的结论比较倾向于以下标签。
SEO
新闻源
菠菜盘
强渗透能力
高"研发"投入
买站投毒
目标人群站长
国人
泰国
历史攻击事件关联
提前声明
我只是一个菜鸡，不擅长威胁分析，更代表不了权威，本文仅作为分析过程的记录和阐述，一切都是个人的看法和结论。
文章基本完成于1月1号左右，这个团队持续在活动中应该会产生新的样本，所以文中的 ioc 关联现在看来不一定全。
文章里如果有逻辑不合理的地方欢迎指出，其他的问题就不回复了。
攻击者看到文章请不要恨我，个人觉得这次行动还是比较秀的。但是首先，操作太A里A气的话，盯上你们的肯定不止我一个。
其次攻防本来就是一个对抗的过程，对抗都是相互的、你来我往的，相信你们也能理解。我写文章无任何利益、竞争目的，单纯觉得有趣。
前置信息
奇安信披露攻击事件
2024年12月12日 14:08 奇安信发布文章《国内最大IT社区CSDN被挂马，CDN可能是罪魁祸首？》披露了一则针对 CSDN 基于篡改 js 的定向投毒攻击事件，攻击者通过第一阶段的 js 限定了一个IP清单，只有命中的 IP 地址才会触发第二阶段加载仿冒的钓鱼页面的 js。
奇安信文章中表示对 js 内置的 IP 列表进行了分析后，结论是攻击者似乎比较关注媒体行业。
文章中分析到，托管第一阶段恶意 js 的恶意域名 analyzev.oss-cn-beijing.aliyuncs.com-cn-beijing.aliyuncs[.]com 的访问量在 9 月初陡增，一直持续到 9 月底，后来 10 月底再次爆发。
投毒受害者简要确认
最开始文章刚刚发布的时候攻击者的部分基础设施还没来得及关闭，通过在 jquery-statistics.js 当中拿到的 IP 地址清单和访问最终 C2域名 server.centos[.]ws 的来源数据对比，发现攻击者这一波操作应该确实是拿到了部分想要的权限。
尝试对几个受害者的身份归属进行确认分析。
根据该IP开放的F5服务的签名信息 XXRB 以及地理位置信息来看，xxx.xx.xxx.xx 有可能是XX日报（我知道还能搜到，打码避嫌）。
剩下的几个中招的地址有的只能模糊的确认，但是的确能看出来攻击者的目标比较倾向于奇安信的结论 —— 新闻行业。
XXX.XX.XXX.XX XX日报
XXX.XXX.XXX.XX XX天气网
XXX.XXX.XX.XX XX日报
攻击者意图猜测
但是大家都想不明白为什么要搞媒体行业，媒体行业并不能直接获得收益。
同时我也比较好奇攻击者从哪里拿到这部分媒体行业的出口 IP。如果是我来做这件事的话我可能会发一封不会让接收者起疑心的邮件，邮件里面带一个探针，如果打开邮件的时候加载了这个请求的话应该就能拿到出口 IP 了。
但是这么做有一些小问题，就是接收者很有可能不是在公司打开邮件，导致探针获取到的IP可能并不准确。再者就是一个公司不见得只有一个出口 IP，从攻击 CSDN 访问者来猜测如果攻击者的目标是研发、运维这类的距离基础设施权限比较近的人，他们的联系方式在互联网可能并不那么好拿到，所以给互联网上能搜到联系方式的人发的邮件打到的IP地址不见得能覆盖真正的目标人群。
当然了这些都是 yy，真实的情况只有攻击者和受害者知道了。
攻击者身份溯源
事件木马样本
我把本文所有相关联的木马样本整理成了一个 90 多行的表格，表格截图附在文末了。下面这里贴的是本次事件比较基础的样本（其实是初代目的表格，后来太多了单起文件了）。
这里先来认识一下本次攻击事件中直接出现的几个木马样本，大致认个脸熟。这些样本几乎都是奇安信直接给出的MD5值，还有个别在 VT 顺着 relations 点两下就能找到，基本都属于 "第一层" 的样本。
可以看到事件中暴露的 C2 端口常用 8848、8084，攻击者偏爱香港的 IP。
本次事件所有搜集到的样本中，只出现了 "Chengdu Nuoxin Times Technology Co., Ltd." 这一个有效的签名，"Octopus Data Inc." 这个签名是无效的。
初代目样本们的上传时间。当然 2037 年的 creat time 肯定是写马的人自己改的。
第一层拓展到的两个奇怪样本
MyBinder.exe
MyBinder.exe 这个样本是通过 31f84f78241819e6e6b9f80005bc97ae - sslupdate.dll 这个奇安信给出的样本关联到的。
Mybinder.exe 释放了两个 .log文件（一开始VT显示的是Xworm V5.6.exe.log，后来才发现这里的文件会随着用户上传同hash样本而刷新文件名），并释放了 sslupdate.exe-7edc 和 sslupdate.dll-31f8。
这个样本在 2024-10-31 07:27:42 UTC（准确的话）被创建，在 2024-11-04 14:22:38 UTC 被上传到 VT，没过多久也被提交到 tria.ge（也可能是 VT 的 api 拉过去的），11月4号这个时间在整个本次攻击事件中算是比较早的时间点了。
结合样本的文件名（主要是这点）、文件提交时间、释放出来的 "Xworm V5.6.exe.log" （这点是我搞错了，没想到VT上样本的dropped文件名竟然还会不断变化，我以为是攻击者测试样本故意放的假旗），起初我猜测这个样本是否是攻击者在正式行动之前的测试样本，上传到VT用来测试免杀来着，结果正式行动时不小心再次使用了用过一次的二阶段的 sslupdate.dll 导致被关联到。
f09da0df6007
继续分析发现，Mybinder.exe 释放的 sslupdate.exe-7edc 也被一个没有名字的样本释放过。由于攻击者用过很多 "sslupdate.exe"，所以不点开详情看很容易认为是已知样本，然后很容易就这么漏掉。
这个样本在 2024-10-26 13:55:45 UTC 被创建，在 2024-11-04 10:19:23 UTC 被提交，创建时间比 Mybinder.exe 早 5 天，提交时间比Mybinder.exe 早 4 个小时。
非常奇怪的是样本的查杀爆毒码清一色全是 Hive，Hive是之前比较头部的勒索软件。
这让我非常疑惑，尝试找出来是哪部分让这么多杀软集体报Hive，但是最终没有找到原因（也许是行为关联？）。
但是分析的时候看到这个样本释放了一个 xlsx 文件并打开，这引起了我的兴趣。
一方面我好奇 xlsx 的文件内容，这个手法在大型活动中用来假冒文档钓目标员工比较常用。另一方面文档类文件常常会保存编辑者的信息，我寻思能不能在右键详细信息里面直接抓到攻击者的实名。
结果文档的作者就是一个简单的 HP，不知道是不是惠普电脑的缩写。而文档内容就是空白的xlsx文档。
另外还有个信息就是 f09da0df6007 的文件图标是 WPS 的文档图标，Mybinder.exe 的图标是 chrome 安装包的图标。
上传者
看到这里，Mybinder.exe 和 f09da0df6007 是不是也让你感到很奇怪，杀软爆出奇怪的特征码、差劲的免杀效果、随意的文件名、空白的文档、比较早期的上传时间，我当时几乎认定这就是攻击者用来测试的样本了。
如果这两个样本是攻击者本人上传，那么上传 IP 应该就是攻击者所在的地区（如果他没挂代理的话）。
但是看了一下 Mybinder.exe 、sslupdate.exe-7edc 、f09da0df6007 、sslupdate.dll-31f8 的上传地区，结果竟然全部都是国内上传的。
到这里我又开始疑惑，如果样本确实是攻击者本人上传的，那么写马的人在国内？
如果样本是受害者那边上传来的（没有名字的这种样本确实很像是杀软之类的途径传上来的），两个样本倒也确实都回连了 8848 端口的那个 C2，但是攻击者不修改木马的原始文件名，直接就拿来钓鱼是不是太草率了点。
再就是这两个被上传的样本的时间都是11月初，这表明攻击者可能早在11月初就开始动手了。
如果我们是布置定向水坑的攻击者的话，已经中招的那些人是不是就没有必要在第一阶段的 js 当中保留他的 IP 地址了？不然钓鱼页面会一直给他弹，他都已经上线了还在弹。
而网页上的 js、木马、钓鱼页面全部都是动态的、可操纵替换的，这就意味着我们在 12 月才拿到的 js、受害IP清单、C2、钓鱼页面可能都是不完整、不全面的。
网络资产拓线分析
指奇安信给出的 IOC 以及点点鼠标就能找到的 "第一层" IOC 的拓线分析。
第一次定性转折 - 银狐？
update.sslcsdn[.]com 是一个在攻击流程中非常靠前的 C2，因为按照奇安信文章里的说法，命中 IP清单的 IP 地址才会去 https://update.sslcsdn[.]com/func.js 拉取钓鱼页面。
在 VT 对各个 C2 地址逐一尝试拓线分析时，发现 update.sslcsdn[.]com 关联出一个没有见过的样本 update (35).exe。
这个样本签名于 2024-11-09 07:48:00 UTC，第一次被上传于 2024-11-20 02:06:37 UTC，也是比较早期曝光的样本，另外很重要的是样本也带有 "Chengdu Nuoxin Times Technology Co., Ltd." 这一个有效的签名。
纵观整次事件带有效签名的样本并不算多，说明这个样本可能是攻击者比较重视的一个文件。
可以看到样本是 go 语言写的，有 20.65 MB 大。
VT的 behavior 板块可以看到很多沙箱在跑起来样本后采集到的信息，其中就有行为、内存指标一类的信息。
挨个排除掉微软、证书服务一类的白信息，可以发现除去已知的 update.sslcsdn.com、107.148.61.185:8084 以外，出现了一个生面孔 www.7zei[.]com。
并且可以看到内存中匹配到的 URL 字符串还有 https://update.sslcsdn[.]com/run 、https://www.7zei[.]com/wasdsfas
前者已经关站了下不到了，后者还开着，文件下载下来发现是无意义的文件，看上去可能是在内存加载的shellcode一类的东西。
当时分析的时候奇安信的 ti 还没有标记 www.7zei[.]com 这个域名，所以我带着疑惑打开首页，发现是一个假冒的 Xshell 官网？？？
网页不知道套用了什么网站的模板，看得出来文案修改的素养比较有限，"多版本的比较"、"以上都不需要"。
而网站的下载功能还是可以正常使用的，点击下载按钮调用的是 https://www.7zei[.]com/download.php，实际返回的文件是 https://www.7zei[.]com/Xshell7.rar。
但是打开压缩包发现，压缩包里并不是 Xshell，而是一个2024年9月15日修改过的 MobaXterm 程序。
反正意思就是你就说这是不是 SSH软件吧，你凑活用就行了。
这个 MobaXterm 不仅证书已经损坏，还加了 enigma 的壳，不太正经的样子。
这草率的一切吸引着我继续探索，由于这个可疑的 MobaXterm exe 时间已经比较早了，所以我直接在 VT 搜索了他的 hash，发现确实已经被人上传过了。
样本关联出了新的 URL 和域名：
http://154.19.200[.]133:8087/count
https://scrt1.nyazz.com/MobServe.exe
https://ssh.0523qyfw.com/MobServe.dll
以及一个没有出现过的 C2 107.148.62.100:8084
其中 ssh.0523qyfw[.]com 已经无法打开，但是 https://scrt1.nyazz[.]com/ 还是可以打开的，是一个假冒的 SecureCRT 官网...
也是类似的网页模板。
访问 https://scrt1.nyazz[.]com/download.php 直接返回 https://scrt1.nyazz[.]com/SecureCRT.zip ， 是一个12月18日修改的 SecureCRT 压缩包。
exe 程序没看到有什么问题，但是相关目录下存在一个10月19日修改过的 libEGL.dll 比较可疑。
（这里样本分析不再赘述，后面的样本信息表格中汇总了关联逻辑关系。）
跟进到这里我开始感觉到奇怪，这些假冒官网的粗糙程度很像银狐，但是 CSDN 这次的投毒事件的细腻程度多少带点 A 里 A 气啊，这里的样本拓展是不是哪里有点错误？
如果这两个假冒官网真的是攻击者的基础设施，那么意味着攻击者没事也跟银狐一样弄点假冒网站搞点投毒？投毒的话似乎目标就无法固定，只能买推广然后广撒网了吧？
第二次定性转折 - 红队？
接下来我扫了下 web 目录，发现了一个 config.php。
（www.7zei[.]com 解析到 154.19.200.214，后来发现这应该是台多 IP 机器，154.19.200.212 = 154.19.200.213 =154.19.200.214，不管访问哪个都等于访问 https://www.7zei[.]com）
看到这里是不是会疑惑这是啥玩意。
我首先确认了这个 cl_reader.php 确实存在，直接访问会提示你缺少参数，但是 creds.csv 不存在，看上去似乎是接收钓取到的凭据的回传脚本？跟老外玩的那一套比较像。
我去 github 搜了一下这个脚本的名字，发现原来是一个后渗透的时候钓取目标机器账号密码的项目，还支持域环境。
可以看到项目有个配置文件 config.cl，我把 7zei 的 config.cl 下载下来跟原项目的对比了一下，发现这个配置文件还真是一个投入生产使用的正式配置。
攻击者在受害者电脑上执行 CredsLeaker.ps1，脚本来 config.cl 拉取回弹窗的配置，受害者输入的账号密码被回传到 cl_reader.php。
攻击者没有修改保存钓鱼成果的 txt 文件（这点也跟老外那一套很像），可以直接访问到，看密码似乎都是真实密码。
最一开始看到配置文件 config.php 这里狂喜，我寻思把 filename 改成 1.php，直接给他写个 shell 进去。
结果仔细看完项目，发现这里的配置是写死了去修改配置 config.cl 的，是受害者机器上执行弹窗的配置，所以修改这里顶多能给受害者弹提醒 "不要输入！"。
$Caption = 'Sign in' //弹框标题
$Message = 'Enter your credentials' //弹框说明
$Server = "https://www.7zei.com/cl_reader.php?" //回传地址
$Port = "80"
$delivery = "https"
$filename = "\cl_loot\creds.csv" //本地缓存文件
$usblabel = "USB_LABEL"
$mode = "dynamic"
$timer = $null
在 VT 上搜索 www.7zei[.]com 也能关联到这几个文件，其中 cl_params.ps1 的hash与 https://www.7zei[.]com/config.cl 是对应的，而 lolz.ps1 与 https://www.7zei[.]com/CredsLeaker.ps1 的hash是对应的。
根据 lolz.ps1 还能追踪到一个新的样本 git-update.exe。
起初我以为这玩意不是自动化的，是攻击者有需要的时候调用一下子，通过 git-update.exe 的分析可以大致看出来拉取脚本并调用回传的过程，这么看的话钓取用户密码这部分功能有点像是自动化完成的（或者是手动执行的自动插件？）。
至此，攻击者的身份从极具 APT 感觉的神秘黑客，到 low 了吧唧的银狐黑客，又增加了一点红队的色彩。
一般来说类似银狐这种一股脑想办法让你上线这种黑客是比较常见的，这种钓密码的方式多少带点后渗透的意思了，毕竟现在能直接抓出来密码的机器越来越少，攻击者也许是为了下一步利用密码继续深入渗透？
第三次定性转折 - 菠菜猎人ever？
根据奇安信文章中曝光的钓鱼页面特征 "上游签发证书校验失败" 字符串，进行网络测绘检索。
可以找到 sslupdate[.]net (47.239.5.111)。
这个域名比较特殊，并没有出现在奇安信的文章中，没记错的话在我最开始溯源的时候也还没有被奇安信 ti 标记。
域名最开始可以直接访问，https://sslupdate[.]net/index.html 就是钓鱼页面，点击更新证书文件就会去拉取 https://analyzev.oss-cn-beijing.aliyuncs.com-cn-beijing.aliyuncs[.]com/update.exe 。
后来 https://sslupdate[.]net 被攻击者关闭，没记错的话攻击者当时连 https://47.239.5.111 一起关了，后来过了几天又偷偷把 https://47.239.5.111 打开了，现在访问 https://47.239.5.111 仍然可以看到钓鱼页面。
页面顶部包含一个 saved from 标记，<!-- saved from url=(0032)file:///Users/ok/Desktop/tt.html --> ，说明这个页面是攻击者通过 EDGE 浏览器打开保存在桌面的html文件。很可惜，攻击者这次又没有暴露实名或者 ID。
<!-- saved from url xxx --> 这个特征本来是 IE 浏览器的特征，后来 EDGE 保留了这个特性，有时候这里可以追溯到一些信息。
另外这个页面当中还包含一个很有意思的域名信息：c.flash[.]ec ，域名算得上是靓号域名，不仔细很容易错过。
并且出现在这个位置也很奇怪，也不太像是替换的时候出现了失误，不知道攻击者是出于什么操作把这个域名放在这里。
对这个域名进行拓线分析，发现所有域名都绑在 Cloudflare上，所以 IP 没什么参考价值。
先是 fox 发现 x.flash[.]ec 是一个 XSS 平台的后台，使用了开源的 Onexss。
注意看这个 XSS 平台的 title 是 FromXS ，当时没有留意这个细节，以为是默认的标题，后面它还会再出现。
而真正让我又开始惊讶的是，fofa搜索 l.flash[.]ec 的结果是一大批菠菜网站。
由于flash的域名已经不解析了所以也无法拉取xss payload 回来了
后面的数字编号 6647 可能代表着一个项目。
搜索 "l.flash[.]ec" && body!="6647" 可以发现其他项目。
由于好几个后台的 URI 都是 /public.login.do ，所以很像是一个漏洞打了一批同框架的后台。
但是多翻几个又发现这些网站似乎也并不全是同一套源码。
搜索 web.flash[.]ec 有一个 flash.js，已经无法访问到了。
而 v.flash[.]ec 是一个basic认证页面。
如果 flash.ec 确实也是攻击者的资产的话，那么到这里黑客的身份似乎又加了一层 Buff —— 菠菜猎人。
起初看到 CredsLeaker 的时候我有想过，是不是国内的某些大厂红队打算拿 CSDN 供应链打一些目标来着，只不过玩的有点大被曝光了，而这些基础设施都是他们用来打 hw 用的。
但是一般正经的大厂也不会打那么多菠菜吧，反诈公司有可能会打菠菜，但是不太可能会去打 CSDN。
那么除了反诈公司还有谁会打这么多菠菜呢？洗盘子黑吃黑的？友商？
比较奇怪的是这些域名现在都无法访问了，xss 的 payload 都还在，是这些网站都已经没有价值了么？
第四次定性转折 - 菠菜猎人now
一开始跟进 flash[.]ec 发现菠菜之后就继续分析其他 ioc 去了，因为都没办法访问了，就没有再继续深入。
后来写完回了检查的时候有了新的发现，新发现源于互联网资产测绘平台的功能差异。
之前搜索 "上游签发证书校验失败" 字符串是用 fofa 搜索的，只能搜索到 sslupdate[.]net 的 index。后来我用奇安信的 Hunter 搜索的时候发现结果多出来一些。
分析发现原来是奇安信的 Hunter 爬取 web 的时候解析 js 比较彻底，XSS payload也会被解析完整，这就导致如果 payload 包含一个钓鱼页面，那么这个钓鱼页面的源码也会被采集到 response 结果当中，而 fofa 和 quake 就不会（非拉踩，各有长处）。
所以当你使用hunter搜索 "上游签发证书校验失败" 的时候，你就能发现除了 sslupdate[.]net 还有不少被挂了钓鱼 js 的菠菜后台，多数的 URI 似乎是还是我们刚刚见过的 /public.login.do 。
但这次域名变了，不再是 flash[.]ec ，而是一个新的域名 l.xn--y7aa[.]cc 。
因为包含不少历史数据和重复数据，所以实际有效的结果没有显示的那么多。
打开一个页面分析了一下，不难看出来 L 子域名是用来托管 XSS payload，C 子域名用来托管钓鱼模板，最终木马托管在阿里云 OSS 上。
payload为：https://l.xn--y7aa[.]cc/6647
拉取的假冒地址为：https://c.xn--y7aa[.]cc/ChromeUpdate.html
oss托管的木马地址为：https://applow.oss-cn-hongkong.aliyuncs[.]com/ChromeSetup.zip
简单看了几个站似乎都是一样的。这个钓鱼模板跟 CSDN 那个不能说是很相似，也只能说是一毛一样。
这个域名注册的其实很讲究，选择了一个模仿 "qq" 的同形异义符。
不过貌似现在对一般的浏览器效果不咋滴，直到我拿到VT搜才发现它是模仿的 qq。
这个域名也都挂了 cloudflare，结合这相似的子域名命名法，我们直接大胆猜测，这域名有没有可能就是 flash 的继承者。
对这个域名进行简单的信息搜集，就可以发现 x.xn--y7aa[.]cc 也是xss平台的后台地址，用的也是onexss，而平台名字也自定义为 "FromXS"。
实际上fofa直接搜索 title="FromXS" 也能把它搜出来，当时看到标题没多想，以为是这套服务默认的。
v.xn--y7aa[.]cc 也是个401认证。
而子域名 l.xn--y7aa[.]cc 就是拉取xss平台payload的域名。a、b、c、d.xn--y7aa[.]cc 这些子域名（泛解析）都是拉取用来展示给受害者的钓鱼模板用的。
除了chrome的钓鱼页面，还发现了一款模仿微软更新根证书的页面，a、b、c、d.xn--y7aa[.]cc 子域名都可以访问到。
页面模板：https://c.xn--y7aa[.]cc/microsoft/update.html
oss托管的木马地址为：https://applow.oss-cn-hongkong.aliyuncs[.]com/MicrosoftEdgeSetup.zip
可见的域名全部都是套了 cloudflare 的，当然 onexss 这个项目本身也是建议在 cloudflare 上运行。
但是在fofa搜索的时候发现了一个比较有趣的信息，在 154.201.80.171:8443 （IP实际是香港的）上配置的cobaltstrike曾经在 2024-11-01 被扫描到过，其中c2配置解析的C2 server是 "C2Server : o.xn--y7aa.cc,/ak.js"。
这属于比较典型的 "web 服务挂 CDN，但是证书配置不规范导致被测绘到" 真实IP没藏住的案例。
不过8443端口对应的web服务已经不开放。
甚至端口都不开了。
这一小节结束，攻击者的画像新增元素：菠菜猎人（现役）、喜欢用Onexss、可能玩过CobaltStrike、喜欢用阿里云OSS托管木马、拥有疑似未公开的 chrome、微软 钓鱼模板。
钓鱼模板的深入溯源
由于这款 chrome 证书更新和微软的钓鱼模板都没有在市面上出现过，github 搜索关键字也没有搜到，所以把时间线拉长搜索 body 和 title 的关键字，有部分新发现。
2023年9月，域名 freessl.freevar[.]com，钓鱼链接指向 http://38.6.184.125/error/sign.zip 。
这个结果被收录的非常少，不确定是因为开放时间比较短还是有其他原因。
38.6.184.125 这个IP目前除了 ssh 还开放了一个灯塔 web，有理由怀疑背后的运营者是网络安全相关人员。
并且 VT 上这个 IP 关联大量的疑似测试用途的样本，样本活跃时间从23年6月到24年6月，其中很可能就有钓鱼页面中的 sign.zip。
样本几乎都是向 IP 发起 http 请求，看uri疑似测试用途。
其中有个样本似乎还是 Supershell 的🐎，就很国产红队。
但是除此之外没有其他证据表明 38.6.184.125 跟 CSDN 事件的样本、网络资源有关联，除非有手段能反推回去或者直接定位到相关人，不然该 IP 只能作为一个疑似相关人的嫌疑IP。
除 38.6.184.125 之外hunter上还能找到三个有嫌疑的IP。
其中 180.76.161.95 是 chromium.hk.cn 的解析IP，chromium.hk.cn 的页面似乎保存自chrome的报错页面。
chromium.hk.cn 也挂过 cloudflare。
通过搜到的域名看，被挂 chromium.hk.cn 似乎不是bc相关的资源。
而103.43.16.195 和 144.48.240.1 的钓鱼页面中的下载地址都指向chromium.hk.cn。
但是仔细看下来这套模板跟本次事件中出现的模板源码又不太相同，本次出现的源码没有这些 cookie 判断逻辑。
到这里钓鱼模板这条线基本就没有什么新的线索了。
当然了，说到底上面这两个 XSS 平台也不见得就是 CSDN 这次的攻击者本人的，仅仅靠一个忘记删除的域名产生的关联比较弱，也许是某些大厂内部攻击平台的钓鱼页面在流传出来的时候不小心带上的呢，这些可能性都是存在的。
分析一下func.js
钓鱼页面的区别
前面说到 https://sslupdate[.]net 被关闭，在攻击者关闭这个 web 之前，可以访问到 https://sslupdate[.]net/func.js 。
后来攻击者关闭服务，过了几天偷偷打开服务的时候，sslupdate[.]net 是无法解析的，但是 https://47.239.5.111/func.js 还是可以访问到的。
但是现在攻击者不知道啥时候把 func.js 给删除掉了，只保留了 index.html。
func.js 这个 URI 只在 https://update.sslcsdn.com/func.js 这里出现过， https://update.sslcsdn.com/func.js 的用途是为经过 jquery-statistics.js 筛选过后的 IP 展示钓鱼页面。
但是在分析 https://sslupdate[.]net/func.js 这里下载到的 func.js 这个文件的时候，发现这个文件似乎既包含筛选 IP 列表的功能，又包含返回钓鱼 html 页面的功能。
并且重要的是 jquery-statistics.js 是被混淆过的，func.js 没有被混淆。
钓鱼 html 被编码在下面一坨里。看上去这个版本的方案是打算请求 https://update.sslcsdn[.]com/checkip?ip= 来二次判断来源 IP 是否在白名单里，如果在白名单的话才返回钓鱼网页。
把编码的 html 解码还原之后，和 https://update.sslcsdn[.]com/index.html 对比发现，编码的 html 不是被保存过的（没有saved标签），另外就是木马的下载地址似乎也被修改过了，从 sslcsdn 下载修改为去阿里云OSS下载。
看上去 func.js 里的这个编码版本要么是攻击者用来做测试的版本，要么是前期投毒行动时没有被捕捉到的版本。
IP列表的区别
一开始 fox 说 func.js 是未混淆版的，只顾着看混淆没有留意 js 里面的 IP 列表，后来回来梳理的时候才发现 func.js 跟 jquery-statistics.js 的 IP "白名单" 是不一样的。
用正则提取 jquery-statistics.js 当中的 IP 地址去重后可以得到 179 个IP地址，而 func.js 只包含 12 个 IP 地址（其中有一个C）。
这马上让我开始警觉起来，有没有可能这些 IP 地址是攻击者自己的 IP 地址，而这个 js 是他们前期自己测试使用的呢？
我对两边的 IP 做了一下对比，发现 func.js 当中黄色框这部分 IP 是 jquery-statistics.js 没有再出现过的，红色框 IP 是比较可疑的地址。
其中 8.218.160.70:7000 在11月底开放过 frp 服务。
使用受害者的 IP 在 VT 基本都可以搜索出来本次事件中的 js 样本（因为js里面包含这个IP），但是 8.218.160.70、38.181.72.101没有关联出任何 js 样本。
8.218.160.70 实际上在我们获取到的 jquery-statistics.js 当中，也有可能是我们这个版本的 js 没有被上传 VT。
但是 38.181.72.101 在整个事件分析当中确确实实只出现了这一次，Cogent 的 IP 却出现了多次。
另外 116.213.40.49 这个 IP 虽然关联出了好几个js样本，但是有一个C2 116.213.40.186 跟它同C段。
至于黄色框里的 IP 为什么没有在 jquery-statistics.js 再次出现，我不确定是因为这些人已经中招，没有必要再放进去，还是有其他的原因。
JS版本的区别
分析到 IP 地址的时候我才突然意识到，js 文件是随时可以变化的，所以攻击者被抓取到的 js 当中的攻击目标 IP 清单也不一定完整。
这就是为什么我在 VT 根据受害者的 IP 搜索关联 js 样本的时候关联出了好几个版本的 js，结合 jquery-statistics.js 当中比较可疑的境外 IP ，我对几个比较有代表性的 js 样本做了一下关联梳理。
可以看到 js 的大小有很多版本，并且每个版本当中同时包含的境外 IP 都不一样。
对上面红黄框出来的这几个IP进行分析时发现，220.191.249.188 能关联出三个版本的js样本，但是这三个样本似乎都不是 https://sslupdate[.]net/func.js，因为这个版本的js当中直接内嵌了假冒证书的html，不用再去远端加载，所以里面并不包含 https://update.sslcsdn[.]com/func.js ，包含的是 https://update.sslcsdn[.]com/checkip?ip=。
并且由于这个js内嵌了BASE64编码后的html，所以有172kb大，而我们拿到的 jquery-statistics.js 才8kb。
220.191.249.188 关联出的三个 js 当中都是带有 https://update.sslcsdn[.]com/func.js 的版本。
搜索这些 IP 可以发现有多个不同的 js 样本，猜测可能是在有部分IP上线之后，攻击者调整js当中的IP地址导致的版本更新？
但是 106.39.147.146 可以关联到 9 月份和 10 月份的 js，说明它可能是处于比较前期的受害者（或攻击者本人测试）。
所以说如果不是攻击者自己上传 VT 测试免杀的话，实际用于攻击的 js 很可能是多版本的，IP出口不在名单里有可能是已经中招了被删掉了，或者攻击者拿到了新的目标 IP 不断往 js 当中新增，动态调整攻击目标。
有的 js 样本可以关联出 https://analyze.sogoudoc[.]com/func.js
不过这部分分析很难得出什么起决定性作用的结论，只是根据 IP 的包含情况做的推测。
第一部分先发到这里，未完待续。
IOC
为了方便用得上的人正常放假过年，就先把所有的 ioc 发出来了，有的 ioc 文章的 “剧情推进” 可能还没有关联到。
C2 木马通信 ioc，有连接基本可以肯定已经被控，这部分比较适合 NTA 设备回溯。
107.148.61.185:8084
45.205.2.101:8848
103.112.98.83:8848
116.213.40.186:8848
107.148.62.90:8084
38.47.220.216:8848
154.19.200.133:8087
107.148.62.100:8084
154.19.200.133:8086
107.148.61.127:8084
47.242.214.157:8084
107.148.50.237:8084
8.217.208.228:8084
奇安信 《最大IT社区CSDN被挂马，CDN可能是罪魁祸首？》文章中的 ioc 重发，有些目前还活着。
update.sslcsdn.com
fix-ssl.com
47.243.177.243:443
analyze.sogoudoc.com
107.148.62.90:443
107.148.61.185:8084
8.217.107.66:443
csdnssl.com
sogoucache.com
sslcsdn.com
sogoudoc.com
flash-update.com
centos.ws
45.205.2.101:8848
103.112.98.83:8848
sslupdate.org
analyzev.oss-cn-beijing.aliyuncs.com
updateboot.com
ntpfix.com
追踪恶意样本过程涉及到的网络 ioc（仅样本关联），有些可能是无差别钓鱼的类型关联到的，也可能有重复，所以这部分噪音比较大。
45.205.2.101:8848 (server.centos.ws)
https://fix-ssl.com/aliyunoss
https://update.sslcsdn.com/runstream
47.243.177.243:443 (update.sslcsdn.com)
107.148.62.90:443 (fix-ssl.com)
https://analyzev.oss-cn-beijing.aliyuncs.com/aliyunossinternal
server.centos.ws
116.213.40.186:8848
8.141.181.246:443 (analyzev.oss-cn-beijing.aliyuncs.com)
107.148.62.90:8084 (fix-ssl.com)
https://update.sslcsdn.com/run
https://www.7zei.com/wasdsfas
154.19.200.214:443 (www.7zei.com)
http://154.19.200.133:8087/count [POST]
https://scrt1.nyazz.com/MobServe.exe
https://ssh.0523qyfw.com/MobServe.dll
216.83.52.145:443 (scrt1.nyazz.com)
216.83.52.155:443 (ssh.0523qyfw.com)
154.19.200.133:8087
107.148.62.100:8084
http://154.19.200.133:8086
https://m.7zei.com/CredsLeaker.ps1
https://m.7zei.com/update.ps1
https://www.fix-ssl.com/startup.ps1
https://www.7zei.com/cl_reader.php
https://www.7zei.com/config.cl
https://scrt.95271.pw/chrome.php
https://scrt1.nyazz.com/Mobnew64new.bin
scrt.nyazz.com
107.148.62.100
118.107.29.172 (scrt1.nyazz.com)
https://ssh.0523qyfw.com/winscp
216.83.52.155 (ssh.0523qyfw.com)
107.148.62.100:8084 (107.148.62.100)
https://scrt1.nyazz.com/dfMob2
https://scrt1.nyazz.com/pslist64mob.dll
scrt.95271.pw
118.107.29.172:443 (scrt1.nyazz.com)
http://107.148.62.100:8084/?a=w64&h=107.148.62.100&t=ws_&p=8084
http://107.148.62.100:8084/
https://www.61xdm.com/wmob
https://www.i5iii.com/insert
107.148.51.200:443 (www.61xdm.com)
GET http://107.148.62.100:8084/ 101
https://ssh.0523qyfw.com/mamami
107.148.61.127:8084
ssh.0523qyfw.com
https://scrt1.nyazz.com/SecureCrtServe.exe
https://scrt1.nyazz.com/dfSrc1
https://scrt1.nyazz.com/pslist64.dll
107.148.61.127
216.83.52.155
http://47.242.214.157:8084/
http://47.242.214.157:8084/?a=w64&h=47.242.214.157&t=ws_&p=8084
https://www.61xdm.com/47
http://47.242.214.157/aliyunoss1111
47.242.214.157:80
47.242.214.157:8084
107.148.62.90:8084
154.19.200.214:443
www.7zei.com
m.7zei.com
216.83.52.145:443
scrt1.nyazz.com
216.83.52.155:443
118.107.29.172:443
107.148.51.200:443
www.61xdm.com
154.19.200.133:8086
http://154.19.200.133:8087/count
https://jpbhb.com/s
https://jpbhb.com/update
https://microsoftstore.oss-cn-beijing.aliyuncs.com/50237?ts=1736924067
https://azurex-resource.oss-cn-beijing.aliyuncs.com/47
http://47.242.214.157/8.217niuniu