20242311 2026-2027-1《网络与系统攻防技术》实验二实验报告
学号： 20242311 姓名： 王润章 班级： 2423
实验名称： 后门原理及其应用
一、基础知识
（一）后门与反弹 Shell
后门是指绕过或弱化正常访问流程，使程序或操作者能够通过非预期通道再次进入系统的一类机制，反弹 Shell 是运行程序的机器主动连接另一台机器，再通过已经建立的网络连接传输命令和执行结果。
那为什么需要反弹 Shell这种机制呢？
因为有些主机位于 NAT 网络内部，或者受到防火墙的入站访问限制。外部设备可能无法直接向它发起连接，但它仍然可能主动向外建立网络连接。不过，反弹连接并不保证能够绕过防火墙，出站访问同样可能受到限制或监控。
实验中需要把三个角色区分清楚：运行程序的主机、接收连接的监听端，以及负责传输文件的发送端和接收端。例如 LHOST 对应反向连接的监听目标，并不必然是 Windows 宿主机的物理网卡 IP。
（二）Netcat 与 Socat
Netcat 可用于 TCP/UDP 连接、端口监听及数据传输，适合观察网络通道中的标准输入与标准输出，Netcat 只负责文件的传输，它本身不会判断文件是不是正常的 Windows 可执行文件。Socat 的全称来自 Socket CAT，它与 Netcat 的用途相似，但更强调不同数据端点之间的双向转发。和 Netcat 相比，Socat 的优势是支持更多地址类型和数据转发配置，例如双向通信、多个连接处理及伪终端等。
（三）cron 与 Windows 任务计划程序
cron 是 Linux 中负责执行定时任务的服务机制，通常由后台守护进程按照预设时间运行命令。例如，我们希望每天自动备份文件，或者每隔一段时间检查系统状态，就可以使用 cron。
Windows 中有类似的机制，叫作 Task Scheduler（任务计划程序）。它可以通过图形界面管理，也可以通过 schtasks 命令行工具管理。
（四）Metasploit、Meterpreter 与 ELF
Metasploit Framework 是一个用于安全研究、漏洞验证和渗透测试的框架。它把不同类型的安全测试功能组织成模块，使研究人员能够在授权环境中复现漏洞和分析系统行为。其中有几个重要概念：
| 概念 | 含义 |
|---|---|
| Exploit | 利用某种漏洞或缺陷的模块 |
| Payload | 被触发后执行的功能代码 |
| Handler | 负责处理指定类型连接或会话的模块 |
| Auxiliary | 辅助测试模块 |
| Session | 已建立的交互会话 |
Meterpreter 是 Metasploit 提供的一种功能较丰富的交互式载荷。普通 Shell 一般提供命令解释和程序执行能力，而 Meterpreter 还提供了面向目标系统的专用操作接口。
ELF 的全称是：Executable and Linkable Format，中文为：可执行与可链接格式。Linux 系统中常见的可执行文件、目标文件及共享库，都可以使用 ELF 格式。
二、实验内容
（一）实验任务
- 使用 Netcat 获取主机操作 Shell，并配置 cron 定时任务。
- 使用 Socat 获取主机操作 Shell，并通过 Windows 任务计划启动任务。
- 使用 MSF 生成实验用可执行文件，利用 Netcat 传输到 Windows 主机，并验证 Meterpreter 会话。
- 测试 Meterpreter 的屏幕、摄像头、键盘记录及提权相关功能。
- 使用 MSF 生成 Shellcode，结合实践一的
pwn1完成 ELF 注入与反弹连接验证。
（二）实验要求问题回答
问题1：列举一个后门进入系统的可能方式。
攻击者可能将程序伪装成常见安装包，通过不可信下载页面或邮件附件诱导用户执行。一旦用户以较高权限运行未知程序，就可能在不知情的情况下建立非预期的远程通信通道。防范时应核验文件来源、数字签名与安全扫描结果。
问题2：Windows 与 Linux 系统中有哪些可能启动后门的方式？
Linux 的 cron、systemd 服务、登录脚本都能自动启动程序；Windows 则有任务计划程序、启动文件夹、系统服务和注册表启动项等机制。
问题3：Meterpreter 的哪些功能给你留下了较深印象？
本次实际验证的系统信息查询、远程目录访问、屏幕获取和摄像头抓拍较为直观。这说明远程会话不仅可能影响命令行，还可能涉及终端上的个人信息与设备资源。
问题4：如何发现系统中可能存在的异常远程控制程序？
可以综合检查网络监听端口和异常外连、当前进程、任务计划和自启动服务、可疑可执行文件的数字签名及哈希值，并结合安全日志判断。遇到不熟悉的任务应先确认创建者和用途，保留证据后再进行隔离与清理。
三、实验过程
（一）实验准备：确认环境和网络地址
本实验使用 Windows 11 宿主机和 VMware 中的 Kali Linux。Windows 侧的计算机名为 LAPTOP-R4L7E2HQ，使用的登录账户为 lenovo；Kali 的用户名为 kali，终端主机名为 wangrunzhang，实验目录为 /home/kali/netsec_exp1。
开始时首先记录 Windows 的网络配置，其中物理网络环境中出现 10.30.9.91，即主机的ip地址。
随后在 Kali 执行网络接口检查，截图中的 eth0 地址为 192.168.17.129，即虚拟机的ip地址。
（二）任务一：Netcat 获取 Shell，cron 启动定时任务
（1）测试连接并查看远程 Shell
在 Windows 端打开 Netcat 监听并检查端口状态。截图中 2311 端口处于 LISTENING，说明程序已在等待网络连接。之后在 Kali 端测试连接，初次出现连接拒绝，检查监听状态后再次测试，Windows 端可以看到 Linux 命令的输出。
连接测试中，Kali 曾出现 Connection refused，随后 Windows 监听窗口成功显示 ls、pwd 的执行结果，其中 pwd 返回 /root。这既记录了初次失败，也记录了后续建立交互的结果。
（2）配置并核验 cron
Netcat 测试后，继续验证 Linux 的定时任务机制。通过 crontab 查看和配置计划任务，并在实验目录中准备输出学号的文本文件。配置阶段曾接触到系统 cron 任务文件，之后改为通过 crontab 命令管理任务，以减少直接操作任务文件产生的格式和权限风险。
实验中使用的写入学号任务，目标是定期更新 /home/kali/wangrunzhang/tempfile/20242311.txt。截图保留了任务配置内容，便于区分时间字段与实际执行命令。
最终在目标目录中查看到 20242311.txt，文件内容为 20242311，说明定时写入的结果得到观察。需要指出的是，文件内容截图可证明指定文本已产生，但并不能单独证明每次触发的精确执行时刻。
（三）任务二：Socat 获取 Shell，Windows 任务计划启动
（1）测试 Socat 连接
在 Socat 测试阶段，Windows 端出现与 Cygwin 移植环境有关的 Couldn't compute FAST_CWD pointer 提示。该提示说明兼容层存在警告，不能据此直接断定连接已经失败，需要查看双方实际会话。
随后 Kali 终端中出现 Windows 命令提示符 G:\socat\socat>，表明对应 TCP 通道已关联到 Windows 命令行，可以观察远程 Shell 的交互情况。
（2）建立 Windows 任务计划
继续使用 Windows 的 schtasks 创建任务。初次命令中，/tn 与任务名之间缺少空格，且引号格式不规范，导致 Windows 将参数解析错误。排查后修正任务名称参数的格式，再重新创建。
修改后再次执行任务创建命令。这里重点是命令参数分隔、使用英文引号以及正确识别 Windows 路径，不能将复制粘贴后的“命令没有报错”直接等同于任务已创建，还需查看计划任务列表。
任务计划程序中已出现名为 20242311wrz 的任务，状态显示“准备就绪”，触发条件包含按分钟重复的设置。这张截图能够证明任务创建与配置成功；至于程序每次触发的具体执行效果，仍以相应任务历史和结果为准。
（四）任务三：MSF 生成可执行文件、Netcat 传输并验证会话
（1）生成文件并确认监听地址
任务三使用 Kali 的 Metasploit 生成 Windows 平台的实验文件 backdoor20242311.exe。最初生成时曾将 Windows 物理网卡地址 10.30.9.91 填入反向连接监听配置，后来检查 Kali 网络接口，确认应区分“宿主机地址”和“真正运行监听端的 Kali 地址”，将相关配置与 Kali 的 192.168.17.129 保持一致。
（2）传输过程中的文件异常
实验中选择 Windows 上的 G:\netcat-win32-1.11\netcat-1.11 目录保存文件。首次使用 PowerShell 配合 Netcat 和输出重定向接收时，出现文件内容异常。截图所示目录中同名文件一度为 0 字节，因此不能把“文件名已经出现”当成传输成功。
检查后发现接收数据的方式需要调整。此时 Kali 仍可看到发送操作记录，但接收端的文件大小、可执行格式和哈希值均需单独核验，避免直接运行不完整文件。
按照本次实验的环境条件，后来改用 Windows CMD 接收二进制文件，重新传输并核对数据。截图中 Kali 发送端计算出的 MD5 为：
1d42ad10ef26e0d4f5543428552a14a5
Windows 端重新计算后得到相同 MD5，表明此次收到的文件与发送文件在内容上保持一致。本次实践的结论是 CMD 方式解决了当前的文件接收问题，而不是所有 PowerShell 版本都无法处理二进制流。
（3）验证 Meterpreter 会话
完成文件完整性校验后，在隔离实验环境中进行会话验证。日志显示 Windows 主机信息可以被读取，目标系统为 Windows 11 24H2，架构为 x64，Meterpreter 会话架构为 x86/windows。使用 getuid、pwd 和目录列举操作，分别记录到 Windows 登录用户与 Netcat 的工作目录。
这一步的主要证据是实际会话中返回了目标 Windows 的系统信息，而不仅仅是监听端显示“正在监听”。通过生成、传输、哈希比对及会话验证，任务三得到完成。
（五）任务四：Meterpreter 功能测试与提权尝试
（1）屏幕和摄像头功能
在已有会话中，屏幕截图命令返回保存路径 /home/kali/EtXHYtiq.jpeg；摄像头抓拍返回 Got frame，生成 /home/kali/PaOcYEiY.jpeg。这些终端记录表明对应图像数据已保存在 Kali 中。
通过 Kali 的文件管理器可以看到生成的 JPEG 文件，并能够在图像查看器中打开摄像头抓拍结果，构成“命令反馈—文件生成—图像打开”的连续证据。
下方为图像查看器打开抓拍结果的实际截图。
（2）键盘记录测试
本次执行键盘记录相关测试时，启动与停止阶段有正常提示，但导出操作返回错误：
stdapi_ui_get_keys_utf8: Operation failed: Incorrect function.
因此只能确认命令已进入相应流程，不能认定已经成功获取键盘输入记录。报错可能与系统版本、会话运行环境、API 兼容性有关，但现有记录不足以证实某一个确定原因。
（3）提权结果核验
在权限提升测试中，getsystem 返回了使用 EFSRPC 相关技术的执行提示；随后使用 getuid 复核，当前用户名仍是 LAPTOP-R4L7E2HQ\lenovo，并未显示 NT AUTHORITY\SYSTEM。因此本报告将其记为已尝试提权，但未证实当前会话权限提升至 SYSTEM，避免把工具提示和最终权限结果混为一谈。
（六）任务五：MSF Shellcode 注入 pwn1，验证 Linux 反弹连接
（1）初次生成文件出现异常
开始时曾使用 GDB 测试输入与栈布局，但多次触发异常，后来发现更根本的问题发生在 Metasploit 的 ELF 输出阶段。
初次输出显示 Payload size: 123 bytes、Final size of elf file: 123 bytes，通过 file 查看得到 data，而非正常 ELF。显然这不是有效的注入后可执行文件。此时无论继续调节 GDB 返回地址还是赋予执行权限，都不能从根本上解决文件格式异常。
（2）参考周梓濠同学的方法定位并修复环境
后续参照周梓濠同学提供的排查方法，查看 Metasploit 版本所对应的 Ruby 源码。to_linux_x86_custom_elf 在处理原 ELF 并替换代码片段后，末尾为字节串赋值表达式；而 Ruby 默认返回函数最后表达式的值，因而可能返回裸 code，使生成结果只有 123 字节。
正式修改之前先备份原 Ruby 文件，并验证备份与原件相同。之后根据周梓濠同学的方法修正返回逻辑，再进行源文件语法与生成结果检查。下图中的编辑界面展示了函数尾部修复后的状态。
（3）重新生成并核验 ELF
修复后重新以 pwn1_20242311 为载体生成实验文件 20242311_pwn1012。命令输出中的最终 ELF 大小恢复为约 7418 字节，与原始 pwn1_20242311 的文件大小相符。生成后还对文件类型、段权限作了进一步检查，而不是只看文件大小。
实际验证中，file 将生成结果识别为 ELF 32-bit LSB executable，Intel 80386；readelf 显示首个可执行 LOAD 段由原来的 R E 变为 RWE。由此确认，生成文件不再只是 123 字节的裸载荷，而是能够由 ELF 工具正常识别的文件。
（4）Linux 会话及结果确认
完成文件层面的核验后，在实验环境中进行运行测试。截图所示监听窗口返回 Linux Meterpreter 会话建立记录，说明连接结果与本项 Linux ELF 程序对应，而不是任务三此前建立的 Windows 会话。
进一步查看会话目录，返回路径为 /home/kali，列出 Kali 用户目录下的多个文件及文件夹。这与 Windows 会话的 G:\netcat-win32-1.11\netcat-1.11 不同，为区分任务三与任务五的实际结果提供了证据。
综上，任务五经历了“生成异常—检查源码—参考同学方法修复—核验 ELF—观察 Linux 会话”的完整过程。
四、问题及解决方案
（一）任务三：PowerShell 接收二进制文件出现错误
问题现象： Windows 端使用 PowerShell 配合 Netcat 接收实验文件时，曾出现空文件、文件大小异常、无法作为有效 Windows 程序打开，以及发送端与接收端 MD5 不一致等情况。
排查过程： 我先检查保存目录和文件大小，再对比两端的 MD5。发现即使文件名存在，实际字节内容仍可能不一致，因此问题主要指向传输与重定向阶段，而不是 Metasploit 监听。
解决方法： 在本次使用的 Windows Netcat 环境中，改用 CMD 接收二进制数据并重新传输，最后再次计算哈希值。两端 MD5 均为 1d42ad10ef26e0d4f5543428552a14a5，问题解决。
经验总结： 传输二进制文件不能只验证是否产生文件，还必须验证长度和哈希值；在某些 PowerShell 版本中，原生命令的输出经过 PowerShell 的文本处理或编码转换后，可能无法保持原始二进制字节完全不变。而 CMD 的重定向处理方式不同，通常更适合把原生程序的二进制标准输出直接保存为文件。
（二）任务五：修复 Metasploit 输出只有 123 字节的 ELF 问题
问题现象： 初次使用 MSF 向实践一的 pwn1 注入 Shellcode 后，得到的输出文件只有 123 字节，file 显示 data，无法正常按 ELF 程序验证。
排查过程： 我一度把注意力放在 GDB、栈地址和输入内容上，但这些调整不能解决生成文件本身不是 ELF 的问题。后来根据周梓濠同学指出的方向检查 lib/msf/util/exe/linux/x86.rb，发现相关方法末尾只返回了替换片段的值，没有返回经过修改的完整 ELF 字节串。
解决方法： 先备份并校验工具源文件，参考同学提供的方法修复 Ruby 函数返回值，再重新生成并校验输出文件。后续结果显示 ELF 大小约 7418 字节，类型为 32 位 i386 ELF，首个可执行 LOAD 段权限变化符合预期，最终获得 Linux Meterpreter 会话。
经验总结： 对生成工具进行故障排查时，应先验证生成物的格式和结构，再讨论调试地址、网络连通和执行环境。此次问题的根源是工具处理 ELF 时的返回值实现，而不是最初猜测的栈地址。
五、学习感悟与总结
这次实验给我印象最深的，并不是哪条命令执行成功，而是如何判断实验是否真的成功。例如任务三中，文件已经出现在 Windows 目录里，却因为接收过程中出现问题而不能运行；只有经过 MD5 对比，才确认改用 CMD 接收后的文件与 Kali 发送端一致。这个过程让我意识到，文件传输应包含完整性验证，而不是仅以文件是否存在作为结论。
任务五的问题更加典型。起初，我一直按实验一的 BOF 思路检查 pwn1、pwn3 的输入和栈地址，但最终发现生成文件只有 123 字节、根本不是 ELF。后来在周梓濠同学的帮助下，把排查方向转向 Metasploit 源码，理解了 Ruby 最后一条表达式的返回值行为。修复后通过文件长度、格式、程序段权限和 Linux 会话结果逐项确认，才形成了比较完整的验证链。
另外，任务四也让我认识到，工具的输出提示和最终结果必须区分。屏幕截图与摄像头拍摄能够找到实际生成文件；键盘记录导出失败，就不能写成已经获取按键；提权工具返回了相关技术提示，但用户身份没有变化，也不能直接认定获得 SYSTEM 权限。今后的实验记录中，我会优先保存原始输出和关键截图，尽量把故障现象、排查思路、修正方法和验证依据一一对应。
六、参考资料
[1] netcat下载链接(需要关闭防火墙)
[2] socat下载链接
[3] 20242312 2026-2027-1 《网络与系统攻防技术》实验2实验报告
