接群众举报,网站“www.kkzjc.com”可能涉嫌非法交易,警方调取了该网站的云服务器镜像(检材1.DD),请对检材1进行分析,获取证据,并根据线索解锁更多检材,深入挖掘出更多与案件有关的信息。
仿真
仿真后 uname
查看,或者直接看版本存储文件
uname -a
uname -r
cat /proc/version
fdisk -l
全局搜索关键字
find / -name "*www.kkzjc.com"
输出文件内容,一开头就写着监听的端口
cat /etc/nginx/conf.d/www.kkzjc.com
3个,和上一道题的域名都在一个目录下
没思路,看 history,发现服务器有 docker,开启 docker 服务
systemctl start docker
systemctl status docker
查看镜像和容器
docker images
docker ps
发现有一个正在运行的容器,可以看到这个容器是个 nginx 服务器,而且它的端口映射是把它自己的 80 端口映射到了虚拟机的 8091 端口上,和 第4题 图里 nginx 的代理配置是相同的,可以判断这个网站会经过 nginx 的代理进行转发
进入交互式终端
docker exec -it 08f64376a2e3 /bin/bash
查看历史记录
可以看到在 nginx 的配置文件目录下编辑了 hl.conf 这个文件,里面就有 nginx 服务器的代理转发信息
不过这个是 第8题 的答案,本题的答案见 第9题
last
命令,从下往上时间顺序
正确的地址能解压检材2,试一下就行了(192.168.99.222)
见 第6题 的分析,实际上在服务器中 nginx 配置文件目录下的三个网站转发的后台网站的 IP 地址都是同一个(192.168.1.176)
题干里提到嫌疑人曾用 WEB 方式 远程访问过网站,我们通过上面几道题的分析可以知道,如果访问该网站,那么会经过 nginx 反向代理到另一个 IP 的后台,那么想到可以通过 nginx 服务的日志来判断访问次数
nginx 官方的 docker 把日志输出到 /dev/stdout 和 /dev/stderr 中,可见 github
# forward request and error logs to docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log
在默认目录 /var/log/nginx
下也可以看到
这种情况下无法直接查看这两个文件中的日志记录,需要通过查看这个 docker 容器的日志,参考文章一、文章二
docker logs 08f64376a2e3
利用 grep
命令来统计次数
docker logs 08f64376a2e3 | grep -o "192.168.99.222" | grep -c "192.168.99.222"
-o 显示所有匹配位置
-c 统计匹配行数
一共 18 个
当我们在翻日志看有关 192.168.99.222
字段的时候,也可以看到其中 nginx 记录的日志信息
例如
192.168.99.222 - - [19/Sep/2020:17:47:14 +0000] "GET /res/img/dr/login/l4.gif HTTP/1.1" 200 417 "http://192.168.99.3:8091/dl" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0" "-"
而 nginx 预定义了名为 combined 日志格式,如果没有明确指定日志格式默认使用该格式:
log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
可以看到对应了 "$http_referer"
的字段恰好是 "http://192.168.99.3:8091/dl"
,也就是说这个请求是从 192.168.99.3:8091 这个 IP 转发过来的,而 8091 恰好又是 nginx 映射到宿主机,也就是这个服务器虚拟机上的端口,由此就可以判断出 第6题 的答案是(192.168.99.3)
第一部分的题目都围绕服务器镜像展开,负载均衡、反向代理这种考点在长安杯中也比较常见,20年的题涉及到了 nginx 反向代理,21年的题涉及到了负载均衡服务器,这部分问到了几个 IP 地址,我们需要搞清楚 钓鱼网站、后台 IP 地址、远程登陆地址 和 服务器原始地址 这几个地址之间的关系与联系:
仿真之后可以看到
取证大师
答案里给的是安装包的最后运行时间(2020-09-18 17:54)
用取证大师看到的应该是安装好的时间,所以可能有个时差?
取证大师,应用程序运行痕迹
一共六次运行痕迹
Part1 中已经分析过了,在 第9题 的日志分析中,有 "http://192.168.99.3:8091/dl"
,很显然就是 8091 端口
在检材 2 中看浏览器的记录也能找到 通过 Web 方式 访问的目标网址和端口
netstat -anp | grep 8091
-p 获取进程名、进程号以及用户 ID
搜一搜关键词
或者查看 hosts 文件
C:\Windows\System32\drivers\etc
电脑里没有微信,但是有苹果手机的备份
这是个文件夹,打开之后里面有个 .tar 备份文件,导出后对其进行分析,手机备份用火眼分析效果比较好
几个聊天软件翻一翻聊天记录就能看到
与上一题在相同的聊天记录
上题图里
见下题
22、23 题放在一起说,这两个题需要我们上网去找能够查狗狗币交易记录的网站,有个 Dogecoin 浏览器,通过聊天记录里的收款地址就能够查到这笔交易
交易时间 2020-09-20 12:12:46,交易数量 4000
关于这道题,实际上在手机备份取证的微信聊天记录中有提示
在检材 2 的 Chrome 浏览器历史记录中也有提示
有关 VMWare 构建虚拟机的文件信息可参考该文章
VMware 对虚拟机进行加密的功能,实际上就是对虚拟机的配置文件 vmx 进行加密,在未加密的时候 vmx 文件中存储的是有关该虚拟机的配置明文信息
但检材 2 中的虚拟机 Windows 10 x64 的配置文件 vmx 是经过加密的乱码
\检材2.E01\分区2_本地磁盘[D]:\Users\HL\Documents\Virtual Machines\Windows 10 x64\Windows 10 x64.vmx
把 vmx 文件单独导出来,用 GitHub 上的工具 pyvmx-cracker 爆破即可,字典就用工具自带的字典
检材 2 中并没有邮箱的使用记录,所以想到去上一题中涉及的虚拟机中寻找,方便操作可以把整个虚拟机文件夹导出来,在本机上再导入虚拟机
打开虚拟机发现有密码,移除 VMware 对虚拟机的加密后,将 vmdk 文件用仿真工具打开,就可以识别到密码
实际上这个密码和检材 2 的开机密码是相同的
打开虚拟机里有个 Foxmail 应用,在草稿箱里可以找到这个图片附件
同样在草稿箱里,可以看到许多邮件主题为【广告】的邮件,都是在 2020-09-20 12:53 这个时间保存的
对虚拟机镜像进行取证
同样在对虚拟机的取证分析结果中,192.168.99.3 是我们在 Part1 分析出的检材 1 的原始地址
见上题图
这部分围绕检材 2 展开,检材 2 中包含了嫌疑人手机备份和嫌疑人用来远程连接检材 1 服务器的虚拟机镜像,嫌疑人主要的通信行为和远程管理都在手机和虚拟机中完成,宿主机中并未存在太多信息。其中一个比较新颖的考点是对 VMware 加密虚拟机的破解,而且也涉及到一些对虚拟货币的基础了解,虚拟货币这一块也是前几年的热门话题,也经常出现在各种网络犯罪行为中。
截止目前,检材之间的关联主要如下:
- 手机备份中含有嫌疑人与外界交流的各种通信应用检材 2 中包含一台 Windows 7 虚拟机
- 嫌疑人通过虚拟机与广告供应商联系
- 嫌疑人通过虚拟机中 xshell 远程管理检材 1 的服务器
仿真检材 3,开机后可以看到服务器里面有个 IIS,展开后可以看到搭建的网站名
上图中物理路径就是根目录
见上题图
在浏览器历史记录中可以看到嫌疑人曾访问过一个叫【代理登录】标题的网站,对应的网址是
http://localhost/dl
我们在把检材 3 仿真起来后也可以直接访问到这个 url,确实是登录的入口
在网站根目录下的配置文件 Web.config 中可以看到对应寻找 /dl
请求的转发
对应上一题目录下的 dllogin.aspx 文件
或者在虚拟机里访问对应的登陆页面,然后 f12,也能看到源码
还是在 dllogin.aspx 中
在 bin 目录下可以找到该文件
这题和上一道题有关联,上一题中调用的动态链接库在 inherits
字段中,是被继承下来的代码隐藏类编译成了 dll 文件
参考:
在 bin 目录下导出这个 dll 文件,用 dnspy 可以对其进行分析
上题的 dll 中,可以看到 dl_login_dllogin
类调用的外部动态链接库中有一个 DBManager,看名字就是和数据库相关的库
这个 dll 也在 bin 目录下,导出后用 dnspy 分析
在 DBcon
类中最下面可以看到连接 sql 数据库的默认配置
其中有数据库地址(192.168.1.174,检材 4 解压密码)和端口(1433)
同样在 DBcon
中,最上面
可以看到这里的逻辑,如果 this.Conn
为空,则使用默认的连接信息(红色框),但实际上 this.Conn
已经被赋值了(黄色框),也就是说我们需要利用 AESDecrypt
方法来解密这串信息,查看该方法,可以看到这是个 Encryption
类下的静态方法,可以直接通过 PowerShell 调用,但是需要注意调用静态方法必须使用方括号加上双冒号 ::
的形式,而且要先在当前的 PowerShell 环境下引入这个动态链接库
见 39 题
这部分题目围绕检材 3 展开,该检材是一个 Windows Server 服务器,上面部署了一个 IIS 网站,主要考察点还是在网站架构(根目录下文件存放路径)、配置信息以及对动态链接库的分析,aspx 与 dll 之间的继承关系,各个 dll 之间的调用关系,找到对应的文件,搞清楚这些关系对解题很有帮助:
/dl
/dr/login
下/bin
下Encryption.AESEncrypt
方法,也在 /bin
下- 数据库名:v7sq3
- 用户名 / 密码:sa / c4f2737e88
- 数据库 IP 地址:**192.168.1.174(检材 4 的解压密码)**
- 数据库端口号:1433
可以看到从 42 题开始,后面的每一道题都涉及到了【重构该网站】,网站重构也是长安杯最喜欢的考点,每一年都会出,所以对于长安杯来说,网站重构的方法是必须要掌握的知识点。
用 39 题的答案解压检材 4 并仿真,可以看到是一台 CentOS 的机器,仿真后查看 history
,能发现里面涉及到很多数据库相关的操作,再结合检材 3,可以发现很明显是一个站库分离的架构,站是检材 3,库是检材 4
这里比较有趣的一点是,通过 history 可以看到出题人大概一开始是想直接在主机上搭建 mssql 服务器来着,但是因为某种原因失败了,就换成 docker 了 我们在实际操作的时候也能发现,通过
systemctl start mssql-server
命令确实无法正常启动 mssql 服务
主机上 mssql 服务无法正常启动,而且 history 中 docker cp
命令对 LDF 文件(日志数据库文件)的操作,数据库的名字与在检材 3 中分析到的完全相同,都是v7sq3
(可见 39 题)
据此我们可以明确判断,真正的数据库在 docker 中
systemctl start docker # 启动docker服务
systemctl status docker # 查看服务状态
docker ps -a # 查看所有容器
docker start 3f17 # 开启容器
通过检材 3 我们得知连接数据库的地址是 192.168.1.174,所以我们要先修改检材 4 的静态 IP
关闭 DHCP
修改网卡配置文件
ip a # 查看配置文件名称 ens-33
vi /etc/sysconfig/network-scripts/ifcfg-ens33 # 修改配置文件
修改(红框)/添加(黄框)以下内容
# 修改
BOOTPROTO="static" # dhcp改为static
ONBOOT="yes" # 开机启用本配置
# 添加
IPADDR=192.168.1.174 # 静态IP
GATEWAY=192.168.1.1 # 默认网关
NETMASK=255.255.255.0 # 子网掩码
重启网络配置,查看是否修改成功
systemctl restart network
ip a
配置好检材 4 后,再配置检材 3,开启 DHCP,查看网络配置,检测是否能 ping 通检材 4
连接数据库
Part3 中提到有关网站登录时调用的 dll,其中 dr_login_dllogin
类的 oCmd
方法中将用户登录信息与数据库比对使用了 wduser.DUserLogin
函数
跟进查看这个函数,在 WBus.dll 的 WDUser 类中(WBus.dll 也在 App_Web_dllogin.aspx.7d7c2f33.dll 开头引用)
DUserLogin
函数中调用了数据库中 PD_UserLogin
函数
PD_UserLogin
函数内容如下图
有几个关键点:
DW_Web
的值取了 DW_Type
和 DW_DU_Id
,DW_Web
是域名/IPDW_Type
的取值(0/1)进入下面两个条件分支,在 TD_User 表中取用户数据根据以上的取值和判断逻辑,我们再修改数据库中的数据,让 DW_DU_Id
与 DU_Id
保持一致就行,根据检材 2 我们能够知道 liwente1314520 是嫌疑人的用户(见 25 题),对应 1001,根据生成密码的逻辑修改 DU_Pwd
字段,例如修改密码为 123
MD5(AESEncrypt('123'+'OvO'))
修改后保存,重启容器
docker restart 3f17
在检材 3 中开启 ASP.NET State Service 服务
此时在自己电脑的浏览器上就可以通过 192.168.1.176/dl
来登录网站,用户名 liwente1314520,密码 123
至此,网站重构成功。
用户列表,一共 3 页,前两页 9 个,最后一页 8 个,一共 26 个
用与对登录页面相同的分析方法,先找到【用户列表】页面对应的 aspx 文件
然后找到它继承自哪个动态链接库
导出后用 dnspy 分析,找到里面和数据库交互的函数
寻找引用,在 WBus.dll 的 WUUser 类中,找到对应的表
统计行数
和上一题同样的分析方法(App_Web_tybfjl.aspx.df411ca0.dll -> WYouxi2.BFTestListGet2),找到对应的数据库表,这里对应的是一个视图(view)
Page_Load
方法中对于是否补发成功的判断如下
可以看到当 YY1T_CState
字段为 100 时,补发成功
sql 语句过滤查询一下,再加上时间范围
SELECT SUM(YY1T_Money) FROM [dbo].[VY_TestLog] WHERE [YY1T_CState] = N'100' AND [YY1T_CDate] BETWEEN N'2019-10-01 00:00:00' AND N'2020-12-31 00:00:00'
无法直接跳转,需要在地址栏开头添加服务器的 IP
192.168.1.176/res/aspx/uin.aspx?user=liyun10&pwd=F58249F4A628AE7B35753EA8416BA943&t=fqgl
这一部分围绕【网站重构】展开,作为每年的保留项目,考察点也不尽相同,21年主要考察对数据库服务器的【raid 重组】,而20年则主要考察对数据库的【改查】操作,当然前提是要弄清楚登录判断和密码校验的逻辑,找到对应的表和对应的数据,才能正确修改。重构网站后剩下的步骤就比较简单了,对 sql 语句有个简单的了解,或者导出到 excel 用表格来统计都可以。
最后再整体看一遍所有的检材,梳理它们之间的关系:
- 根据后台网站的内容和功能可以判断,这三个域名是嫌疑人给下线代理访问管理平台的地址,账号需要嫌疑人审核通过后才能登录
- 检材 3 的 IP 地址为 **192.168.1.176**,恰好符合 **检材 1** 中 **nginx** 代理转发规则,80 端口对应后台首页
- 检材 4 的 IP 地址为 **192.168.1.174**,所有关于 **数据库的连接信息** 都是通过对 **检材 3** 中 **网站登录代码** 分析得到的