大家好,我又回来了,上一期我们对那一起攻击事件流量的分析只进行了一半,事情还远未结束,这期,我们继续来进行探究。


第五问 数据库

攻击者拿到的数据库配置信息是什么。 

前面攻击者已经拿下了一个网站,并上传了webshell,通常都会读取网站的配置文件来获取数据库的账号密码,然后连接数据库进行数据脱取等操作,那么,我们就来从流量中找找攻击者读取的数据库文件。

通常,在php语言的网站中,数据库的配置会写在config.php、database.php等名称的文件中,Java语言的网站中,当使用一些框架时,数据库的配置可能会写在datasource.xml、config.xml、config.properties等名称的文件中,一般情况下,在这些文件中写数据库的连接信息时,都会有hostname、dbname、username、password这类的关键字,在java中还会有jdbc的字段。大多数情况下,这些配置信息在配置文件中都是明文存储的,当存在任意文件读取、下载、获取webshell之后都可以通过读取这些文件直接获取数据库信息。

现在我们就来看看攻击者的流量,看看他读到的数据库信息是什么。首先我们能想到,攻击者读取到的数据库信息肯定是在返回包中显示,再通过我们之前分析出来的攻击者使用的名称为a.php的webshell来筛选一下。先筛选攻击者IP发出的请求,并且返回包是由a.php请求来的:ip.addr == 192.168.32.189 and http.response_for.uri contains "a.php"

seoss.oss-cn-shanghai.aliyuncs.com/wp-content/uploads/1970/01/beepress-image-139504-1598339370.png" style="margin:10px 0px;padding:0px;box-sizing:border-box;border-width:1px;border-style:solid;border-color:#EEEEEE;image-rendering:-webkit-optimize-contrast;max-width:90%;max-height:90%;cursor:zoom-in;" />

筛选出来90条数据包,再把返回包200的请求筛选出来,就只剩下36条数据包,这样找起来就更容易了。

我们直接搜索数据包中的字符串,搜一些跟数据库配置文件相关的关键字,由于是搜的返回包内容,所以我们直接搜host、dbname、password、dbpwd等。搜索了一番,怎么都没找到读取数据库配置文件的数据包,难道没有读数据库配置文件吗?难道筛选逻辑有问题?不禁心生疑问。此时想到之前遇到过的一个情况,流量包里只有返回包,没有记录到请求包时,就无法通过特定的请求路径筛选出对应的返回数据包。难不成读取数据库配置文件的请求包没有被记录下来吗?带着这个疑问,我又来翻查一遍数据包,这次不再筛选数据包的路径,直接将所有攻击者发起的请求的返回包,并且状态是200的数据包筛选出来,再去查找。

筛选出的数据包有1万多个,使用wireshark的搜索字符串的功能,搜索host发现有大量的噪声包,就直接搜索dbhost字段,正中目标,发现攻击者只读取了一次配置文件,只有这一个数据包。

跟踪了这个数据包之后发现,整个数据流只有返回包的内容,没有请求包,似乎就可以印证之前的猜想了,流量包中并没有记录到这个操作的请求包,只记录到了返回包。

第六问 邮箱

攻击者获得的邮箱账号密码是什么?

前面攻击者已经拿到了数据库的账号密码,我们猜测攻击者可能通过哪些方式去查询的数据库:第一种,通过webshell连接数据库,执行sql语句查询数据库,这种方式的流量为http流量;第二种,通过数据库连接工具或命令行连接数据库,执行SQL语句查询数据库,这种方式就取决于连接工具本身,mysql一般情况下都是tcp流量。

从上一步获取到的数据库配置信息中看到,数据库的地址是10.3.3.101,我们先来看看被攻击者攻击的网站的网卡信息。

可以看到被攻击的web服务器存在两张网卡,一个对外,一个与数据库通信。继续分析寻找攻击者查询数据库获取邮箱账号信息,查找http流量,没有发现任何基于http流量的查询数据库操作,在记录到的数据包流量中,有mysql流量,直接筛选出来mysql的流量来分析。

筛选之后发现只有web服务器与数据库的通信流量,猜测可能攻击者使用web服务器做流量代理连接数据库或者直接使用web服务器连接数据库。流量包中的mysql流量共有40多万条,整体逐条筛选肯定会很困难,此时,我们可以回到攻击者发起攻击的行为来分析。攻击者发起读取数据库行为,肯定发生在读取数据库配置文件之后,由此而来,我们可以看看数据包中记录到的读取数据库配置文件的时间,然后寻找mysql流量中对应的时间之后的流量。

可以看到读取配置文件的时间是8月8日16点18分05秒,再回到mysql流量里,按照时间排序流量包,然后来分析。查看了这个时间之后的mysql流量包,发现并没有预期的结果,难道没有通过连接数据库来读数据库里的信息吗?难道是通过注入拿到的信息?现在我们也无法直接确定,我们就来反推一下这个过程,先来找找攻击者登录的邮箱。

与之前一样,先来找找与邮箱登录相关的流量:

http.request.method == POST and http contains "index.php"

存在大量192.168.94.59发出的攻击流量,这个应该就是攻击者的IP了。再来看一下正常的邮箱登录是什么样的返回包,过滤出来与邮箱有关的http数据包后,发现有一个logout退出登录的数据包,在这个数据包中的cookie参数中发现有个login_name参数,那么这个肯定就是正常登录的用户了。

继续看看这个用户名的正常登录是什么样的,会返回来什么样的数据。

这里登录之后返回了一串json格式的字符串,然后又请求welcome模块跳到正常登录后访问的页面。所以登录成功后会返回{"success":true}这样的json字符串。根据这个特征,来找找攻击者登录的邮箱账号是什么。

(http contains "{"success":true}" or http.request.method=="POST") and ip.addr==192.168.94.59

在搜寻的过程中发现还存在大量的爆破的痕迹,不排除攻击者根本没有通过之前拿到的数据库获得密码的可能,而是通过爆破获得的账号。在找到攻击者登录邮箱使用的账号密码后,发现密码是一串加密的字符串,我们还需要解密出密码的明文,才有可能判断出攻击者是否是通过数据库获得的密码。再返回来找一下登录页面的数据包,看看返回的页面中有没有加密方法。

终于在这里找到了登录的密码加密方法,是AES加密,key是1234567812345678的MD5的hash值,iv偏移量是1234567812345678,后面还说了mode和padding的类型,到这里,我们就可以借助解密工具对密码解密了。

到这里我们再回过头从数据库里看看有没有查询admin@test.com密码的操作。

mysql contains "admin@test.com"

查看mysql里包含admin@test.com的流量,发现时间均在攻击者通过webshell读取数据库配置文件之前。并且数据库中记录的最后登录IP就是攻击者的ip。看来攻击者在读取数据库操作之前就已经拿到了账号密码。

第七问 VPN

攻击者登录vpn后的ip是多少?

前面攻击者已经拿到了admin权限的邮箱账号,应该所有用户的邮件都可以看到了,我们来找找攻击者有没有从其中拿到vpn的账号密码。

ip.addr == 192.168.94.59 and http contains vpn

过滤之后发现攻击者所有请求的数据包中包含vpn信息的用户名只有luzhihao一个,再到vpn的流量记录里看看。

这里使用luzhihao的账号进行登录,但并未登录成功。这里我们可以知道192.168.32.131是vpn服务器。

在后面的流量包中发现有使用xingh的账号连接vpn成功的流量包。来使用wireshark自带的流量统计功能看看每个ip之间的流量请求情况。

从统计出来的流量上看到vpn服务器返回给攻击者的ip大量数据包,其中有一部分是前期攻击者登录的流量包,其余的就是攻击者连接上vpn之后的操作。再看其他的统计数据,10.3.4.3向10.2.4.96发送了大量数据包,那么这两个ip中应该有一个是攻击者连接vpn之后分配的ip,再来看看哪个是攻击者的ip。

筛选10.3.4.3的流量后,按照协议类型排序,在ICMP类型的流量中,发现10.3.4.3主动向10.3.4.55和10.3.4.96发起了ping请求,通常情况下可以判定10.3.4.3是人为控制的机器。

继续查看,发现10.3.4.3向10.3.4.96主动发起共享请求,10.3.4.96返回回应,这就可以判断10.3.4.3是攻击者控制的机器,所以攻击者接入vpn后的ip是10.3.4.3。

至此,我们整个的分析就已完成。攻击者的整个攻击流程大致如下:

总结

流量分析,防守之道。站在攻击者的角度,思考攻击者的整体流程,他们的最终目的无外乎拿数据、得权限,正向走不通就反向推演,万变不离其宗。

对整个分析过程做一个回顾,大致可以把整个思路汇总成为下面这一个图:

拓展

我们继续来说说cobalt strike的几种不同类型的beacon模式的远控流量所存在的一些特征。

DNS隧道

配置好服务器,做好域名解析后,在cobalt strike上创建一个监听器,并使用cs生成一个木马文件(这里使用的是cobalt strike 3.13版本)。将木马放在windows下执行,同时我们使用wireshark来抓取流量包,查看整个执行远控的过程中的通信情况。

执行木马主机上线后,这里我执行了ipconfig、net user、dir命令,来看一下cobaltstrike远程控制主机执行这些命令后,teamserver与远控主机之间是如何进行通信的。

我们使用的是dns隧道实现的远程控制,在流量中会出现大量的dns数据包,从这些dns数据包的解析地址来看,发现异常的域名地址还是相对比较容易。全局搜索执行的命令,无论是搜字符串还是hex值,都没有任何信息。相对从数据包内容上来说,dns隧道还是比较隐蔽,很多攻击者在使用dns隧道来进行远控时,都会使用隐蔽性更强的域名,会使用一些与常用域名非常相似的域名,如a1iyun.com这样的,不容易被认出来,这时候就需要借助一些第三方的威胁情报库去辅助判断。


本文作者:酒仙桥六号部队

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/139504.html