【HTB Academy】Linux取证练习记录

🛠️ 准备工作：解析 Sysmon for Linux 日志

微软推出的 Sysmon for Linux 是一个极其强大的工具，它可以记录进程创建、网络连接、文件更改等高级事件。
原始的 syslog 中包含了 Sysmon 的 XML 格式数据，为了方便后续分析，我们需要先将其解析为易读的文本。
cat /var/log/syslog | sudo /opt/sysmon/sysmonLogView 2>/dev/null > /tmp/sysmon_parsed.txt
命令解析：

cat：读取原始日志文件。
sysmonLogView：Sysmon 官方提供的日志解析工具。
2>/dev/null：将标准错误（如解析不规范的 XML 报错）丢弃，避免干扰正常输出。
/tmp/sysmon_parsed.txt：将解析好的干净结果重定向到临时文件，后续所有的 grep 搜索都基于此文件，大大提高效率。

🔍 第一部分：基于日志的进程与网络溯源

1. 查找连接到 C2 服务器的恶意进程 (PID)

场景：我们已知攻击者的 C2（命令与控制）服务器 IP 为 3.212.197.166，需要找出系统中哪些进程连接过它。
grep -B 8 "DestinationIp: 3.212.197.166" /tmp/sysmon_parsed.txt | grep "ProcessId:" | grep -v "Parent" | awk '{print $2}' | sort -n | uniq
命令解析：

grep -B 8：-B (Before) 打印匹配行及其前面 8 行。因为在 Sysmon 的网络连接事件（EventID 3）中，ProcessId 字段通常在 DestinationIp 的上方。
grep -v “Parent”：-v (Invert match) 排除包含 “Parent” 的行（排除 ParentProcessId 的干扰）。
awk ‘{print $2}’：以空格为分隔符，提取第二列（即 PID 数字本身）。
sort -n | uniq：-n 按数字大小排序，uniq 去除重复项。

2. 数据库取证：分析被窃取的用户信息

场景：攻击者利用权限执行了 PostgreSQL 数据库查询，我们需要知道窃取了谁的信息。
直接查看 PostgreSQL 的查询日志：
grep -i "SELECT\|INSERT\|UPDATE\|COPY\|dump" /var/log/postgresql/postgresql-12-main.log
发现核心攻击记录：
select name from users;
select * from users where name LIKE ‘Wade Murphy%’;

结论：攻击者首先获取了 users 表的用户名列表，随后精准窃取了用户 Wade Murphy 的所有信息。

🧠 第二部分：Volatility 3 内存取证高级技巧

当日志被篡改或存在欺骗性时，内存转储 (Memory Dump) 才是最诚实的证人。这里使用 Volatility 3 (https://github.com/volatilityfoundation/volatility3) 框架。

1. 突破迷雾：寻找真实的父进程 (PPID)

场景：攻击者使用了一条命令来提权：/bin/sh -c echo “december” | sudo -S python3 -c “import sys,base64…”。我们在 Sysmon 日志中看到该 sh 命令的 ParentProcessId 为 3320，但这其实是个“幽灵 PID”。如何找到真实的父进程？
解决方案：使用 Volatility 3 直接分析内存中的进程树结构。
python3 vol.py -f memdump.mem linux.pslist | grep -E "sh|python|sudo"
命令解析：

-f memdump.mem：指定内存转储文件。
linux.pslist：列出内存中捕获的所有活动进程及其父子关系。
分析结果：
2840 2831 python3 (C2 代理进程)

3321 2840 sh (执行 echo 的 shell)
3323 3321 sudo (接收密码并提权)
惊人发现： PID 3321 (sh 命令) 的真实父进程是 2840 (python3)！这是因为恶意 python 脚本通过管道派生了子 shell 来完成自动化提权。Sysmon 日志偶尔会因为异步或 PID 快速回收出现归属偏差，而内存取证还原了最真实的进程链。

2. 内存文件提取：Dump 可疑 ELF

场景：我们怀疑内存中的 sshd 被注入了，需要提取它的 ELF 文件计算 MD5。
python3 vol.py -f memdump.mem linux.elfs --dump
md5sum pid.3939.sshd.0x7fb4eed88000.dmp
命令解析：

linux.elfs：枚举内存中加载的所有 ELF 文件（执行档和共享库）。
–dump：将这些文件提取到当前物理硬盘上。

3. 寻找注入的恶意代码 (RWX 内存区)

场景：正常的代码段权限是 R-X (读/执行)，如果一块内存是 RWX (读/写/执行)，大概率是注入了 Shellcode。
python3 vol.py -f memdump.mem linux.malfind --pid 3939
命令解析：

linux.malfind：专门寻找进程中隐藏的或注入的代码（寻找 VMA 权限为 RWX 且头部包含可疑指令的内存块）。
–pid 3939：针对可疑的被注入进程进行定点扫描。

第三部分：恶意软件静态分析 (YARA & Hexdump)

从内存中 dump 出恶意文件后，我们需要确认它到底是什么，以及提取它的网络配置。

1. 批量运行 YARA 规则

场景：使用本地的 YARA 签名库扫描 Dump 出来的恶意代码。

for rule in ~/tools/yara/*; do 
    result=$(yara "$rule" pid.3939.sshd.0x7fb4ee007000.dmp 2>/dev/null)
    if [ -n "$result" ]; then echo "$result"; fi
done

命令解析：

这是一个 Bash 的 for 循环，遍历 yara 规则目录中的所有文件。
yara ：应用签名进行扫描。
结果：触发了 mettle 规则。Mettle 是 Metasploit 针对 Linux 的 Meterpreter payload 实现。

2. 手工提取 Meterpreter UUID (Hexdump 技巧)

场景：找出这个 Meterpreter payload 中硬编码的 Session UUID。
由于 Mettle 习惯将配置参数存储在 ELF 文件的末尾（或者数据段末尾），我们可以先用 strings 寻找线索：
strings -t x pid.3939.sshd.0x7fb4ee007000.dmp | grep -i “tcp://“
发现 0xd9206 偏移处有 “tcp://0.0.0.0:8080 字样。接着使用 hexdump 查看该地址附近的十六进制数据：
hexdump -C -s 0xd91a0 -n 256 pid.3939.sshd.0x7fb4ee007000.dmp
命令解析：

hexdump -C：以标准十六进制 + ASCII 字符的形式输出。
-s 0xd91a0：跳过前面的数据，直接从 0xd91a0 (十六进制) 偏移量开始查看。
-n 256：只打印 256 个字节，防止输出刷屏。
完美斩获：
在输出的明文中，我们清晰地看到了 Mettle 的启动参数：
mettle.-U.”bWWoXsWDgPG1A7MB0C+Qkg==. -G.”ZpM+…
其中紧跟在 -U 参数后面的 bWWoXsWDgPG1A7MB0C+Qkg== 就是 Base64 编码的 Session UUID！

💡 总结与反思

不要盲信单一日志： Sysmon 日志给出的 PPID 可能是错的，Volatility 内存分析能提供进程树的上帝视角。
结合 grep, awk, sed 的文本三剑客：是处理巨大日志文件的效率保障。
恶意代码的蛛丝马迹都在内存里：熟练使用 linux.malfind (找 RWX) 和 hexdump/strings (提取硬编码配置) 是应对高级持久化威胁 (APT) 和无文件攻击的关键。