这是 酒仙桥六号部队 的第 24 篇文章。

全文共计3449个字，预计阅读时长11分钟。

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

第五问 数据库

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

前面攻击者已经拿下了一个网站，并上传了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"

筛选出来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的类型，到这里，我们就可以借助解密工具对密码解密了。

到这里我们再回过头从数据库里看看有没有查询[email protected]密码的操作。

mysql contains "[email protected]"

查看mysql里包含[email protected]的流量，发现时间均在攻击者通过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这样的，不容易被认出来，这时候就需要借助一些第三方的威胁情报库去辅助判断。