OsmanDhaqane/sneaky-patch-tryhackme

# Sneaky Patch - TryHackMe Write-Up ## 场景 一个高价值的 Linux 系统疑似被内核级后门入侵。传统的用户态检测方法不足以应对，因此调查重点集中在实时系统取证、内核模块检查和后门分析上。 ## 目标 此房间的目标是调查实时 Linux 系统，识别内核级入侵的迹象，确定后门的运作方式，并恢复隐藏的 flag。 ## 练习技能 - Linux 实时取证 - 进程和网络检查 - 内核模块调查 - `/proc` 接口分析 - 基本恶意软件/后门分析 - Hex 解码和 flag 恢复 ## 方法论 调查遵循在运行中的 Linux 系统上进行实时取证的方法。我首先收集了基本的主机和操作系统信息以了解环境，然后查看了正在运行的进程和活动的网络连接，以寻找任何异常情况。 在初始取证之后，我将重点转移到内核层面的可见性，通过查看已加载的内核模块并检查可疑条目。这导致发现了一个名为 `spatch` 的异常外部（out-of-tree）模块。 随后，我调查了该模块的行为，确定了其关联的 `/proc` 接口，确认它允许以 root 身份执行命令，然后检查了模块二进制文件以恢复嵌入的 flag。 ## 调查步骤 1. 收集基本系统信息 2. 查看正在运行的进程和网络连接 3. 检查已加载的内核模块 4. 识别可疑的 `spatch` 模块 5. 调查 `/proc/cipher_bd` 6. 确认通过后门执行命令 7. 使用 `strings` 检查模块二进制文件 8. 解码恢复的十六进制字符串以获取 flag ## 枚举与分析 ### 1. 基本系统信息 我首先确定了当前用户、主机、操作系统和内核版本。 ``` whoami hostname uname -a cat /etc/os-release ``` 这确认了目标是一个运行内核版本 `6.8.0-1016-aws` 的 Ubuntu 24.04.1 LTS 系统。  ### 2. 进程与网络取证 接下来，我查看了活动进程和网络连接，以寻找可疑活动。 ``` ps aux --sort=-%cpu | head ps aux --sort=-%mem | head ss -antup ps -ef ``` 大多数可见的用户态进程对于 TryHackMe 环境来说看起来很正常，包括桌面和 VNC 相关服务。然而，进程审查显示了名为 `psimon` 的异常内核样式条目，这很引人注目，表明需要进行更深入的内核级调查。   ### 3. 已加载内核模块 然后我检查了已加载的模块以识别任何异常。 ``` lsmod | head -20 lsmod | grep -Ei 'sneak|patch|psi|monitor|hide|root|backdoor' ``` 这揭示了一个名为 `spatch` 的可疑模块，它看起来不像该系统的正常模块名称。  ### 4. 内核日志审查 为了验证该模块是否为恶意模块，我查看了内核日志消息。 ``` sudo dmesg | tail -50 ``` 内核日志清楚地显示 `spatch` 是一个外部（out-of-tree）模块，并包含与后门相关的日志消息。最重要的发现是该模块暴露了一个 `/proc` 接口，并通过它以 root 身份执行命令。  ### 5. 调查后门接口 在识别出可疑模块后，我检查了内核日志中引用的 `/proc` 条目。 ``` ls -l /proc/cipher_bd cat /proc/cipher_bd echo test | sudo tee /proc/cipher_bd sudo dmesg | tail -20 ``` 文件权限特别可疑，因为 `/proc/cipher_bd` 是全局可写的。读取它返回输入/输出错误，但向其写入数据会触发新的内核日志消息，显示该模块尝试将提供的输入作为命令执行。 这证实了 `/proc/cipher_bd` 充当了后门的命令接口。  ### 6. 模块元数据与位置 为了了解更多关于恶意模块的信息，我检查了它的元数据和文件路径。 ``` sudo /sbin/modinfo spatch find /lib/modules/$(uname -r) -type f | grep -i spatch sudo cat /sys/module/spatch/sections/.text ls -l /sys/module/spatch ``` 这确认了模块文件位于： ``` /lib/modules/6.8.0-1016-aws/kernel/drivers/misc/spatch.ko ``` 元数据还包含非常可疑的值： - Description: `Cipher is always root` - Author: `Cipher` 这些细节有力地支持了 `spatch` 是恶意内核模块而非合法系统组件的结论。  ### 7. 提取并解码 Flag 为了直接检查模块内容，我对模块二进制文件使用了 `strings`，并发现了一个嵌入的十六进制值，该值似乎包含 flag。 ``` strings /lib/modules/$(uname -r)/kernel/drivers/misc/spatch.ko | less ``` 恢复出的重要值是： ``` 54484d7b73757033725f736e33346b795f643030727d0a ``` 然后我使用 `xxd` 从十六进制解码它： ``` echo 54484d7b73757033725f736e33346b795f643030727d0a | xxd -r -p ``` 这揭示了最终的 flag： ``` THM{sup3r_sn34ky_d00r} ```   ## 关键发现 - 系统被名为 `spatch` 的恶意外部（out-of-tree）内核模块入侵 - 该模块从 `/lib/modules/6.8.0-1016-aws/kernel/drivers/misc/spatch.ko` 加载 - 内核日志显示了明确的后门行为和 root 命令执行 - 后门在 `/proc/cipher_bd` 处暴露了一个可写接口 - 向 `/proc/cipher_bd` 写入会导致命令被内核模块执行 - 模块元数据包含可疑标识符，如 `Cipher is always root` 和作者 `Cipher` - 嵌入的 flag 是通过使用 `strings` 和十六进制解码从模块二进制文件中恢复的 ## 经验教训 这个房间是一个很好的例子，说明了为什么内核级入侵很难仅通过正常的用户态检查来检测。起初，从进程和资源使用的角度来看，系统看起来基本正常，但查看已加载的内核模块和内核日志很快揭示了真正的问题。 我还获得了更多调查可疑 `/proc` 条目、通过 `dmesg` 验证恶意模块行为以及直接检查内核模块二进制文件的实践。另一个有用的收获是看到了在分析过程中使用 `xxd` 进行简单的十六进制解码如何揭示隐藏信息。 ## 结论 在这次调查中，我识别出了一个名为 `spatch` 的恶意内核模块，它通过 `/proc/cipher_bd` 创建了一个后门，并允许以 root 身份执行命令。通过查看内核日志、模块元数据以及模块二进制文件中的字符串，我确认了入侵并恢复了最终的 flag： ``` THM{sup3r_sn34ky_d00r} ``` 这个房间是 Linux 实时取证和内核级后门调查的强力实操练习。

标签：0day挖掘, Cutter, DAST, Digital Forensics, HTTP工具, HTTP请求, Incident Response, Linux取证, Live Response, /proc文件系统, Triage, TryHackMe, Writeup, 内核安全, 内核模块分析, 后门调查, 实时取证, 库, 应急响应, 恶意软件分析, 数据展示, 无线安全, 流量嗅探, 特权提升, 红队, 网络安全, 网络安全审计, 自动化部署, 隐私保护