专栏名称: 渗透师老A
不一样的角度学习五花八门的渗透技巧,了解安全圈背后的故事
目录
相关文章推荐
网信正定  ·  古城限定美景,全国独一无二的存在 ·  8 小时前  
网信正定  ·  古城限定美景,全国独一无二的存在 ·  8 小时前  
植物星球  ·  爱护环境,禁止种菜 ·  2 天前  
植物星球  ·  酸汤鱼的配料正在满山开花 ·  3 天前  
51好读  ›  专栏  ›  渗透师老A

HVV 溯源实例-从OA到某信源RCE全0day渗透

渗透师老A  · 公众号  ·  · 2022-12-14 10:03

正文

来源于奇安信社区(Alivin )

原文链接: https://forum.butian.net/share/1765

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

0x02 溯源过程

事件起源于4月9日午后的一则来自EDR的webshell告警,如下:

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

2.1 向内溯源,确定影响面

2.1.1 某信源VRV溯源

2.1.1.1 从日志分析

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


从日志寻找入口的思路:

(1)定位webshell访问接口,确认攻击跳板的IP

(2)对webshell访问前后日志进行分析,确定漏洞URL

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

(4)对POST请求的日志重点分析。

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

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

该部分扫描无影响,然后继续分析,发现攻击队成功登陆了audit账号:

结合测试,发现audit账户为弱口令123456,同时在audit审计账户的后台中发现system也被登录过,同样为弱口令。(PS:此时猜测admin用户也是弱口令,经过测试并不是。)

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

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

到这得到的信息,总觉得是因为admin账户密码被重置导致的整台服务器实现(如果是admin弱口令的话,就不会存在admin修改自己密码的操作了。)
继续分析日志,发现在logo.aspx文件被访问前,还曾访问过logo.txt。


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

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

那么问题来了,admin账号权限咋来的?带着疑问,先分析GetNavUserByNavGuid.aspx被访问的日志:

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

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

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

2.1.1.2 从流量分析

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

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

此时终于有了明文流量了,直接搜索接口,验证上面从日志中溯源的结论,如下:

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

2.1.1.3 杂记

某信源这个漏洞是0day,后来因为客户要求,将细节给了某信源,某信源还特地发了公告:

具体漏洞分析过程见3.1

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

shell在上传后,我们马上进行了处置,从某信源服务器进行拓展是来不及的,所以我们重点从某信源后台失陷后,攻击者都干了些什么来确定影响面。
众所周知,某信源是终端管控系统,其最常用的攻击方法就是通过后台对管控的终端进行下发文件/执行命令等方式操作进行利用。于是在日志中找到相应的接口进行分析:

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

也不敢大意,在流量侧重点监控了几个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扫描结果,如下:


整理后,结合流量进行分析,发现攻击队共计探测到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做了什么。







请到「今天看啥」查看全文