第四十九课0day攻击 案例

前面我们说了0day漏洞接下来我们来说说通过0day漏洞来进行0day攻击

12021 年国 Hvv 真实溯源过程，在流量设备告警能力弱的情况下，重人工介入分析整个过程总结，回顾当时整个溯源过程和 0day 的捕获过程，尝试把当时的心境和技术上的思考点梳理出来，给大家参考，批评。

　　0x02 溯源过程

事件起源于 4 月 9 日午后的一则来自 EDR 的 webshell 告警，如下图1-1：

图1-1

马上展开对该服务器的排查，该服务器为某信源 VRV，纯内网环境。说明攻击者已经进入内网环境，分两条线分别对攻击入口和内网影响面进行排查。

　　2.1

　　向内溯源，确定影响面

2.1.1 某信源 VRV 溯源

1. 从日志分析

因为某信源 VRV 的管理后台使用 SSL 协议，在协调厂商提供证书的同时，对 access.log 日志进行分析，尝试找出其中的攻击入口。如图1-2

图1-2

　　从日志寻找入口的思路：

（1）定位 webshell 访问接口，确认攻击跳板的 IP

（2）对 webshell 访问前后日志进行分析，确定漏洞 URL

（3）将可疑 URL 在其他时段日志中进行搜索，找出在其他时段没出现过的 URL 重点分析

（4）对 POST 请求的日志重点分析。

通过对日志分析，发现 10.*.*.*2 在对 VRV 服务器尝试扫描，扫描日志符合 fscan 等类型内网扫描工具的流量，如下：1-3

图1-3

此时已经定位了攻击某信源 VRV 的主机为 10.*.*.*2，同时安排其他同事对该 IP 进行溯源分析。

该部分扫描无影响，然后继续分析，发现攻击队成功登陆了 audit 账号：图1-4

图1-4

结合测试，发现 audit 账户为弱口令 123456，同时在 audit 审计账户的后台中发现 system 也被登录过，同样为弱口令。（PS：此时猜测 admin 用户也是弱口令，经过测试并不是。）如图1-5

图1-5

时间和 IP 都和攻击者路径对得上。但 audit 和 system 账户权限有限，并不会直接控制终端。

此外，在审计用户的后台还发现，admin 账户的密码被修改过，操作者时 admin 本人，登录 IP 为攻击队控制的跳板机，修改后密码后，admin 账户成功登录。

　　图1-6

图1-6

到这得到的信息，总觉得是因为 admin 账户密码被重置导致的整台服务器实现（如果是 admin 弱口令的话，就不会存在 admin 修改自己密码的操作了。）

继续分析日志，发现在 logo.aspx 文件被访问前，还曾访问过 logo.txt。图1-7

图1-7

而且 logo.txt 的访问中存在一次 404 的访问，说明马没写成功。那么比对两次 logo.txt 访问前被访问的接口，大概率可以定位到漏洞存在点。如图1-8-9

图1-8

1-9

成功定位 / VRVEIS/SystemMan/GetN**UserByN**Guid.aspx 就是漏洞文件，而该文件能写入 shell，且从日志看，该路径应该需要 admin 权限才能访问。

那么问题来了，admin 账号权限咋来的？带着疑问，先分析 GetN**UserByN**Guid.aspx 被访问的日志：图2-1

图2-1

成功定位 / VRVEIS/SystemMan/GetN**UserByN**Guid.aspx 就是漏洞文件，而该文件能写入 shell，且从日志看，该路径应该需要 admin 权限才能访问。

那么问题来了，admin 账号权限咋来的？带着疑问，先分析 GetN**UserByN**Guid.aspx 被访问的日志：图2-2

图2-2

在 admin 用户登录前，已经出现了大量的接口调用和访问，里面奇迹般的记录了一个 POST 的 body，把思路引向了注入（后话：最后证明 pczq 参数与漏洞利用无关）。

恰好如果是注入的话，也解释的通 admin 账号的来源和写文件的操作。mssql 支持堆叠注入，update 操作可以改密码，xp_cmdshell 可以用于写 shell。

而在登录 admin 之前，登录 audit、system 账号的行为，原因大概是因为 admin 用户的密码复杂，cmd 不可解。所以先解开 audit 和 system 的密码登录的。

2. 从流量分析

从流量分析已经是几个小时以后的事情了，某信源厂家并不愿意提供证书对流量进行解密。但是在不经意间看到 VRV 根目录下有一个 cert 目录，在其中找到证书。如图2-3

图2-3

证书有加密，尝试以后发现证书密码是 123。

　　此时终于有了明文流量了，直接搜索接口，验证上面从日志中溯源的结论，如下：如图2-4

图2-4

与日志分析结论一致，且在流量中有发现修改 admin 的密码。（时间久远，找不到数据包截图了，payload 截图如下）如图2-5

图2-5

　　杂记

某信源这个漏洞是 0day，后来因为客户要求，将细节给了某信源，某信源还特地发了公告如图2-6

图2-6

具体漏洞分析过程见 3.1

2.1.2 某信源后台失陷的影响面

shell 在上传后，我们马上进行了处置，从某信源服务器进行拓展是来不及的，所以我们重点从某信源后台失陷后，攻击者都干了些什么来确定影响面。

众所周知，某信源是终端管控系统，其最常用的攻击方法就是通过后台对管控的终端进行下发文件 / 执行命令等方式操作进行利用。于是在日志中找到相应的接口进行分析：如图2-7

由于一些图片大小不符合 上传标准 所以我就进行了拼接 把它弄大一点 才能上传 会出现图 2－5这种情况

图2-7

根据 DeviceID 可以确定出被攻击的机器具体是哪台，最终梳理出一个表，最后使用时间都在被攻击之前，如下：图2-8

图2-8

也不敢大意，在流量侧重点监控了几个 IP 的流量，没有明显异常行为，对 PC 都进行了查杀、进程、启动项、注册表分析，确认未被攻击者控制。此时已经凌晨 3 点多。

第二天与客户沟通后发现，该 VRV 是用于 VPN 接入时进行管控的，而 VPN 在 4 月 8 日晚上已经关闭。

2.1.3 10.*.*.*2 失陷后的影响面

该失陷主机在 DMZ 区，且开放对互联网的访问，所以大概率这就是首台被攻破的机器了。

凌晨 3 点多，我同事还没有完整的梳理出该机器的影响面，于是我参与其中一起梳理。（PS：客户第二天一早要看到影响面，不敢怠慢）。

　　分析思路：

（1）以 10.*.*.*2 作为源 IP，分析其对内网的整个访问流程中的异常流量。

（2）分析 10.*.*.*2 上的木马文件、攻击者工具等文件，在分析影响面的同时也寻找被攻击的点。

　　（3）关联服务器分析

整个分析展开时，由于流量设备告警能力弱（可以说连 SQL 注入都不怎么告警），分析依靠蛮力介入的比较大。整体看下来就是扫描流量非常多，但分析是否成功实在工作量太大了。

在扫描文件的时候，发现服务器上仍存在攻击队未删除的 fscan 扫描结果，如下：图2-9

图2-9

整理后，结合流量进行分析，发现攻击队共计探测到 28 台内网机器（含 10.*.*.*2 本身），其中存在漏洞的情况如下：

10.*.*.*2 存在 MS17-010 漏洞（本机），DMZ 区域做了策略优化，禁止了该区域内的 445 访问，所以其只能访问自己的 445。

10.*.*.*7 存在 Druid 未授权访问漏洞，未发现流量中有利用行为。

10.*.*.*1 存在 MySQL 弱口令，未在流量中发现进一步漏洞利用。

10.*.*.*5 存在某信源 SQL 注入 0day

10.*.*.*3 被成功登录了数据库

其本身情况就是这样了，然后对其关联的服务器进行分析，因为该应用站库分离，用的是 mssql，使用的是 sa 用户，IP 为 10.*.*.*3，在流量中也证实该机器被成功登录了 mssql。那极有可能通过 xp_cmdshell 已经获取到了数据库服务器的权限。

通过上机排查 10.*.*.*3，发现 xp_cmdshell 已经被激活，但未从数据库日志里面找到 xp_cmdshell 被调用的记录，无法得知攻击队用 xp_cmdshell 做了什么。

在流量侧对 10.*.*.*3 进行分析，仅发现其与 10.*.*.*2（应用）有流量交互，不存在向内网扩散的行为。

　　向外溯源，查找入口点

之所以把对 DMZ 区域的攻击过程溯源放的比较靠后，是因为该机器出现问题后一直处于断网状态，所以不急着分析。

2.2.1 寻找线索，发现端倪

对于 10.*.*.*2 的被攻击的路径是一点线索也没有，所以上去先对进程、文件、定时任务、启动项、网络连接进行检查，状况如下：

　　（1）定时任务、进程、启动项里面没有驻留的后门

（2）网络连接只有外网访问该应用的，并没有由内向外的 C2 回连（因为不出网）

（3）文件方面只发现了 fscan，竟然没有发现 webshell。

　　此时可以说是一头雾水，又整理了一下手里的信息：

（1）服务器处于 DMZ 区，向外提供服务

（2）服务是 e-mobile，当时未暴出 0day（ps：溯源到的第二天细节公开了）

　　（3）无文件落地，可能是用了内存马（ps：不排除攻击过程中有文件落地）

于是，使用 cop 对内存马进行检测，如下

　　图3-1-3-2

图3－1

图3－2

果然发现了内存马，然后找到内存马对应的 java 文件，如下：图3-3

图3－3

根据对样本进行分析，发现该内存马的特征流量为返回包的 set-cookie 中包含 eagleeye-traceid 字段，对流量中包含该特征的流量进行检索，如下：图3-4

图3-4

发现两个 IP 有过 webshell 连接的请求，随后对两个 IP 的的流量进行分析，发现两个 IP 的交互都很有目标，直接就连接了 webshell，未发现其进行其他攻击操作。图3-5-6

图3－5

3－6

然后又开始了苦逼的分析。

2.2.2 深入分析，找到过程

通过对内存马访问前后流量的排查，未发现直接上传 webshell 的操作（服务没 shell 文件，不排除内存马植入后删除了木马，所以排查了 webshell 上传行为）。

想到可能是直接执行代码将内存马加载到内存中的，搜索关键字 loadClass如图3-7

图3-7

从而定位到攻击 IP 和加载内存马的过程。根据攻击 IP 筛选，还原整个漏洞利用过程。如图3-8－9

3－8

图3-9

漏洞为 SQL 注入，通过创建别名的方式执行 j**a 代码，将内存马的字节码文件写入到 tmp 目录下的 tmpD591.tmp 中，字节码文件较长，所以进行了多次追加写入，然后在最后调用 j**a.net.URLClassLoader 类将 tmpD591.tmp 字节码文件加载到内存中。

随后上机排查，在 tmp 目录下发现 tmpD591.tmp, 截图如下：图4－1

图4－1

通过对字节码文件进行分析，发现其中包含了一个名为 resin.class 的字节码文件。图4-2

图 4－2

通过分析代码，证实该文件是 Resion 的内存马。至此，整个溯源过程结束，跨时 2 天。

0x03 漏洞分析

　　3.1

E-moblie 注入分析

当我们在为发现两枚 0day 而窃喜的时候，第二天 E-moblie 这个漏洞就被公开了。下面是分析过程，看官们直接跳转，不赘述了。

　　https://forum.butian.net/*****/84

　　3.2

某信源 SQL 注入分析

　　找到漏洞文件，代码如下：图4-3

图4-3

通过反编译 VRV 的 dll 文件，找到该方法的实现：图4-4

图4-4

直接从 request 中拿到了 n**Guid 参数，然后带入了 GetListByN**Guid 方法，跟踪该方法：如图4-5

图4-5

直接将参数拼接到 SQL 语句中产生的注入。

0x04 总结

时隔 1 年多，整理手中的材料时想拿出来做分享，部分过程没有找到相对应的截图。各位看官将就一下。站在上帝视角，回顾整个过程，颇有收获：

（1）DMZ 区的被攻破应用的数据库就在核心区域，而且核心区域访问关系不清晰，没有做严格的分级分域，里面全部互通。如果攻击队通过 10.*.*.*3 进行资产扫描，我们早就退场了。这也给了我以后打红队的启发。

　　（2）在分析过程中，对于漏洞攻击过程的追求远大于对事件影响的排查，也庆幸在甲方的督促下，我注意到了其中的重要性。

（3）关于项目开发，某信源对 0day 的解释是某项目的定制需求，定制需求还放在标准产品中，显然是审计工作不够充分如图4-6

图4-6

）某信源系统多个不被人关注到的账号，都是 123456 这个弱密码。这类问题不止体现在某信源，其他产品也是，所以作为防守方应该注意这些问题。图4-7

图4-7