记一次应急响应靶场学习
记一次基于勒索事件的应急响应靶场学习以及取证分析 靶场来源于:乌鸦安全
一、项目背景:
vulntarget-n是一个模拟全球化勒索病毒高发环境下的应急响应和取证分析案例,其模拟了一个正常运行的业务服务被勒索病毒攻击的情景:
01、客户在阿里云部署的业务环境
02、今天突然发现首页变成了一个勒索的界面,要求用户支付赎金以解密数据
03、客户发现其中部分重要文件被加密为.vulntarget结尾
随即客户要你进行应急响应并取证分析,因为是阿里云的ECS,客户将阿里云ECS实例镜像导出到本地,要求你在明天分析出结果。
具体要求如下:
01、分析攻击事件是如何发生的,请给出攻击画像
02、解密勒索
03、恢复原来的index.jsp页面,恢复正常的web服务
二、环境配置:
A、靶场下载:
链接: https://pan.baidu.com/s/1sv9qdioNF4PTUliix5HEfg
提取码: 2dwq
B、格式转换:
使用镜像格式转换将原本的RAW格式转换成虚拟机的VMDK格式
相关文档说明:
https://help.aliyun.com/zh/ecs/user-guide/convert-the-format-of-an-image
工具下载地址:
https://qemu.weilnetz.de/w64/
格式转换命令:
qemu-img convert -f raw -O vmdk .\vuln_m-j6cegcrhehdcba0r5h4v_system.raw vuln_m-j6cegcrhehdcba0r5h4v_system.vmdk
最后转换完成后会产生一个.vmdk的虚拟机文件
C、新建虚拟机:
选择:“稍后安装操作系统”,选择linux类型的Ubuntu系统,磁盘选择:现有磁盘,然后找到刚才转换的VMDK镜像。
D、云服务器配置:
账号:root
密码:Vulntarget@123
三、应急响应/取证:
A、vulntarget文件查找:
首先我们可以从项目背景中得到一个有用的信息就是客户的重要文件被加密成了.vulntarget结尾,可以直接在服务器上查询一下带有vulntarget的文件
命令:find / -name *vulntarget*
解释:直接搜索服务器上带有vulntarget的文件(模糊查询)
01、查找结果:
我们可以发现客户是使用的tomcat中间件进行部署的且安装目录在opt下
02、Tomcat版本:
可以直接在当前用户的home目录下执行ls命令发现zip的安装包
B、查看Tomcat日志:
01、catalina是tomcat自己的一些配置日志,暂时不用管;
02、主要看localhost_access_log日志信息;
03、可以发现有六百多条日志内容,日志相对来说不是特别多;
C、日志筛选:
首先筛选一下日志信息,因为一般攻击者都会上传webshell或者首先查询POST、PUT等请求,然后再筛选状态码200的代表成功。
01、POST排除:
可以发现攻击者有在尝试POST上传文件但是并没有成功,所以不是POST
02、PUT确定:
当我们筛选PUT请求的时候发现改jsp文件上传成功了且状态码为201,并且攻击者还访问过vulntarget.jsp文件且状态码为200。
201状态码:请求成功并且服务器创建了新的资源;
D、tomcat上传漏洞复现:
BurpSuite测试:
访问:
从日志分析可知,攻击者通过tomcat中间件的历史漏洞(CVE-2017-12615)上传了恶意JSP文件到服务器,从而获得服务器权限。
E、root权限:
通过命令查看Tomcat中间件的进程信息发现是root权限,所以基本上可以知道攻击者获得了服务器的root权限。
命令:ps -aux | grep tomcat
F、history历史命令:
01、反弹shell:
在获得root权限后一般攻击者会进行反弹shell的操作,可以通过history命令查看历史命令的使用情况(这里由于不方便显示IP用的flag代替)
02、rsa加密:
通过历史命令的查看发现了攻击者通过python对文件进行了rsa加密(包含私钥、公钥创建以及存储路径)
03、删除文件:
然后删除了当前目录下公钥、加密脚本等;
G、得到私/公钥:
但是通过history的查看发现在/opt/tomcat/webapps/ROOT/.vulntarget目录中存在公钥、加密脚本文件等。
1、解密flag.jsp.vulntarget文件:
通过在线平台进行rsa解密第一个flag.jsp.vulntarget文件
2、解密vulntarget.jsp.vulntarget文件:
通过在线平台进行rsa解密第二个vulntarget.jsp.vulntarget文件
3、小问题:
但是后续其它文件通过这种方法无法进行解密因为长度问题,没有数据,只有简单写个py脚本进行解密
完整代码:
import rsa
import base64
# 假设这是你的私钥文件路径和文件名
PRIVATE_KEY_FILE = "./privkey.pem"
# 假设这是你的加密文件路径和文件名
ENCRYPTED_FILE = "./1.txt"
# 解密后的数据将保存的文件名(这里我们简单地移除了".encrypted"后缀)
DECRYPTED_FILE = ENCRYPTED_FILE.replace(".encrypted", "")
# 加载私钥
with open(PRIVATE_KEY_FILE, mode='rb') as file:
private_key = rsa.PrivateKey.load_pkcs1(file.read())
# 读取加密数据(假设是Base64编码的)
with open(ENCRYPTED_FILE, mode='r') as file:
encrypted_data = file.read()
decoded_data = base64.b64decode(encrypted_data)
# RSA解密通常不直接用于大文件,但这里我们假设数据被分成小块进行加密
# 注意:实际中,你可能需要知道每个数据块的确切大小,这取决于你的加密协议
BLOCK_SIZE = 128 # 假设每个数据块是128字节,但这不是RSA的标准做法
# 初始化结果列表
decrypted_blocks = []
# 按块解密数据
for i in range(0, len(decoded_data), BLOCK_SIZE):
block = decoded_data[i:i + BLOCK_SIZE]
# 注意:这里可能需要处理块大小不是密钥长度整数倍的情况
try:
decrypted_block = rsa.decrypt(block, private_key)
decrypted_blocks.append(decrypted_block)
except rsa.pkcs1.DecryptionError:
# 如果解密失败(例如,块大小不正确),则可能需要适当的错误处理
print(f"Decryption failed for block at index {i}")
break # 或者你可以选择继续处理其他块
# 将解密后的块连接成完整的解密数据
decrypted_data = b''.join(decrypted_blocks)
# 将解密后的数据写入新文件
with open(DECRYPTED_FILE, mode='wb') as file:
file.write(decrypted_data)
print(f"{DECRYPTED_FILE} 文件解密成功")
4、解密index.jsp.vulntarget文件:
通过编写python脚本解密第三个index.jsp.vulntarget文件
5、解密404.jsp.vulntarget文件:
通过编写python脚本解密第四个404.jsp.vulntarget文件
H、业务恢复:
01、index.jsp代码替换:
将解密后的index.jsp替换服务器中的文件即可恢复正常业务,并将其它文件进行替换即可。
I、后门文件:
解密后的 404.jsp 也对应了 history 里面的命令记录,将后门文件伪装成404页面。
四、攻击者画像:
五、总结:
本次勒索事件整体并不是和难,但是这些勒索事件都是很接近实际的,企业应该重视这些安全事件,大部分都是由于没有及时更新版本或者配置从而导致攻击者有可乘之机,进而一步造成勒索事件的发生。