《网络与系统攻防技术》实验二报告

学期：2026—2027 学年第一学期

实验名称：实验二——后门原理与实践

学号：20242329　　实验署名：wangxiaoxuan

实验时间：2026 年 10 月 17—18 日

实验环境：Windows 11 物理主机、VMware Kali Linux 虚拟机

1. 基础知识

1.1 Shell、正向连接与反向连接

Shell 是系统提供的命令交互接口，例如 Linux 的 Bash 与 Windows 的 cmd.exe。在网络实验中，如果一个命令解释器的标准输入、标准输出和 TCP 连接建立关联，就可以在另一端发出命令并接收结果。正向连接通常由操作端连接目标主机上等待的服务端口；反向连接则由目标端主动连接操作端的监听端口。连接的发起方向不同，但都依赖实际可达的地址、端口和正常运行的程序。

需要区分三种状态：端口可以连通、远程命令可以执行、专用远控协议成功建立会话。三者不是同义词。

1.2 Netcat、Ncat 与 Socat

Netcat（nc）支持 TCP/UDP 连接、监听及文本收发。Windows 端使用的 Ncat 是 Nmap 项目提供的实现。Socat 将两个输入输出对象连接起来，既可以对接终端与 TCP Socket，也可以对接文件与网络连接。在本实验中，Windows Ncat 和 Kali Socat 曾协同完成通信与临时 Shell 测试。

1.3 定时任务与后门驻留的区别

Linux 的 cron 通过 crontab 定义周期任务；Windows“任务计划程序”使用触发条件和操作定义计划任务。这些机制可能被正常运维工作使用，也可能被滥用为不需要人工干预的程序启动入口。本实验配置的均为记录时间的测试任务，用于验证调度机制，未配置远程控制程序开机或定时自启动。

1.4 Metasploit、Payload 与 Meterpreter

Metasploit Framework 为安全测试提供载荷生成、会话管理和模块化功能。msfvenom 可以生成与目标平台相应的载荷文件。Meterpreter 是一种会话型 Payload，支持交互式信息查询、文件操作及部分设备功能。Windows PE 程序和 Linux ELF 程序分别适用于不同操作系统和体系结构，不能直接互换。

本实验的 Windows 端使用 x64 Meterpreter；第五项实验涉及的原始 pwn1 则为 32 位 i386 ELF。Payload 平台、架构、文件格式及监听配置必须分别核验。

1.5 击键、音视频与权限模型

远程录音、拍摄和按键记录属于不同的能力：设备识别正常，不代表远程采集功能已经成功；保存文件的提示，也不必然证明文件能够正常回放。权限方面，Windows 普通用户、经 UAC 提升的管理员进程以及 NT AUTHORITY\SYSTEM 是不同的安全上下文。getuid 反映当前会话身份，getsystem 的执行结果则必须结合后续身份查询判定，不能只看是否发送了命令。

1.6 Shellcode 与 ELF 文件结构

Shellcode 是一段能够被处理器执行的机器指令。将其嵌入一个已有 ELF，并不是把字节附加到文件尾部就必然能够执行：还要考虑入口地址、节区、程序头、可加载段、虚拟地址映射以及指令架构。尤其应注意 ELF 的“节（section）”和运行时“段（segment）”并不完全等同。独立 ELF 能运行，不能据此推出已有 pwn1 被成功注入。

2. 实验内容与环境

2.1 实验目标

本次实验对照课程要求完成以下五项验证：（1）Netcat 获取 Shell 与 Linux cron；（2）Socat 获取 Shell 与 Windows 任务计划；（3）生成、传输可执行载荷并获取目标主机远程会话；（4）验证 Meterpreter 的音频、摄像头、击键记录能力并尝试提权；（5）尝试将 MSF Shellcode 注入原有 pwn1，并观察是否形成反向 Shell。

2.2 实验平台

类别	实际配置	用途
目标主机	Windows 11 家庭版 x64，Build 26200，主机名 `wangxiaoxuan`，用户 `lenovo`	老师要求的 Windows 物理主机
操作主机	Kali Linux 2026.2，VMware 虚拟机，主机名 `wangxiaoxuan`	网络监听、实验记录与 ELF 分析
网络（前期）	VMnet8 NAT：Kali `192.168.37.130`、Windows `192.168.37.1`	Netcat、Socat 初始实验
网络（后期）	VMnet1 Host-only：Kali `192.168.19.128`、Windows `192.168.19.1`	后期载荷与会话验证
工具	Kali Netcat、Socat 1.8.1.1、Windows Ncat 7.99、Metasploit 6.4.135-dev	通信、载荷与会话实验
目标文件	`~/netsec_exp2/original/pwn1`	任务（5）原始 32 位 ELF 样本

两台主机在后期网络下完成双向 ICMP 测试，网络可达。Windows 同时拥有物理机的其他网络接口，因此不能把 Host-only 简单描述为整台 Windows 完全离线。

图 1　Windows 物理主机与 Kali 虚拟机的连通性验证

3. 实验过程与分析

3.1 任务一：Netcat 获取 Shell 与 cron 定时任务

3.1.1 双向文本通信

先在 Kali 端建立 TCP 监听，再使用 Windows 的 Ncat 发起连接。双方发送不同的测试字符串，均能在对端看到对应内容。这一步证明两个系统之间的数据收发正常，但还不能作为 Shell 验收结果。

图 2　Windows Ncat 发起 TCP 连接并发送测试内容

图 3　Netcat 建立 TCP 通信并接收测试消息

3.1.2 临时 Windows Shell 验证

随后将 Windows 命令解释器与临时 TCP 通道关联。首次尝试时连接很快结束，因此先区分命令一次性输出与持续交互；调整后，Kali 端成功获得 Windows whoami 和 hostname 等命令的输出。返回身份为 wangxiaoxuan\lenovo，主机名为 wangxiaoxuan。这证明操作端接收到的是 Windows 命令执行结果，而不是 Kali 本机的输出。

图 4　Kali 端通过 Netcat 验证 Windows 命令交互

3.1.3 cron 定时任务

通过用户 crontab 配置每分钟执行一次日期记录，把时间追加到 ~/netsec_exp2/cron_20242329.log。实际观察到跨多个分钟的连续记录；任务结束后移除 crontab，保留日志。这说明定时调度的触发、执行和结果写入均得到验证。

# 实验中 crontab 所执行的时间记录命令
/usr/bin/date >> /home/kali/netsec_exp2/cron_20242329.log 2>&1

图 5　cron 周期任务及时间日志验证

本项结论：Netcat 文本通信、临时远程 Shell 和 cron 调度均成功。定时记录任务不等于后门自启动。

3.2 任务二：Socat 获取 Shell 与 Windows 任务计划

3.2.1 Socat 监听与通信

Kali 使用 Socat 对 TCP 端口进行监听，Windows Ncat 作为连接端。测试字符串能够双向收发，验证了 Socat 把 TCP Socket 与标准输入输出连接的能力。

图 6　Socat 监听及双方文本收发结果

3.2.2 Windows Shell 验证

Kali Socat 与 Windows Ncat 组合建立临时命令交互。对端身份查询、主机名查询及实验标识都返回正确，说明在这一组合方案中，远端 Windows 命令输出能够返回 Kali。报告中必须将其表述为Socat＋Ncat 的混合实现。

图 7　Kali Socat 与 Windows Ncat 配合完成远程命令验证

3.2.3 Windows 计划任务

在 Windows 中创建一次性测试任务 Exp2_20242329_ScheduleTest，设定 2026 年 10 月 17 日 19:25 执行时间记录脚本。任务执行后，状态显示 LastTaskResult = 0，日志写入 2026-10-17 19:25:00。之后删除计划任务并确认已移除。

图 8　Windows 计划任务的触发与执行参数核验

图 9　Windows 一次性计划任务执行状态与日志

本项结论：Socat 的网络转发能力、混合方案的 Shell 交互和 Windows 计划任务执行得到验证；没有配置远程程序持久化启动。

3.3 任务三：Windows 可执行载荷的三轮尝试与最终会话建立

任务（3）并不是第一次生成程序后就直接成功。实际操作中，先经历了 Meterpreter 样本被拦截，随后改用 Nmap 项目中的 Ncat 验证通信与程序执行，最终才重新完成 Meterpreter 会话建立。三轮实验的工具、成功范围和证据各不相同，因此分别记录。

3.3.1 第一次尝试：Meterpreter 文件生成成功，但未建立会话

首先在 Kali 使用 Metasploit 生成 Windows x64 Meterpreter 可执行程序。生成输出显示 Payload 为 509 字节，最终 EXE 为 7680 字节；文件格式检查也识别出 Windows x64 PE 文件。由此可以确认生成环节完成，但生成成功并不等于目标主机已经运行程序。

图 10　首次生成 Windows x64 Meterpreter EXE 的终端结果

图 11　首轮 EXE 文件类型、大小和校验信息

样本向 Windows 传输后，Microsoft Defender 将它识别为 Trojan:Win32/Zusy.NCD!MTB 并删除。相应保护历史记录保留了威胁名称和受影响文件路径。该次尝试没有产生有效 Meterpreter Session；在清理监听作业后，sessions -l 显示没有活动会话。这是第一轮失败的直接依据。

图 12　Defender 检测并删除初次实验载荷的记录

图 13　首次尝试结束后的 Meterpreter 活动会话检查

此外，最初载荷采用 Kali 在 VMnet8 NAT 网络下的旧地址 192.168.37.130，后续网络改为 VMnet1 Host-only，Kali 地址为 192.168.19.128。更换监听地址不会自动改写已经生成的 EXE。由于该次文件在运行前被安全软件删除，不能单凭这次记录断定 IP 差异也是导致会话失败的直接原因，但配置不一致确实需要在排错时核对。

3.3.2 第二次尝试：改用 Ncat，验证可执行文件传输和 Windows 远程 Shell

为了把“网络传输是否正常”和“Meterpreter 程序能否运行”这两件事分开判断，第二阶段改用 Ncat。Ncat 是 Nmap 项目提供的网络通信工具，不应将本阶段简单写成“Nmap 扫描”；这一次并没有建立 Meterpreter 会话，验证重点是可执行文件在两台主机之间的传输完整性和临时 Shell 交互。

先把 Windows 安装目录中的原始 ncat.exe 传到 Kali，Kali 端成功得到一个 Windows PE 可执行文件。两端对原始文件及接收文件计算 SHA-256，哈希值一致，文件大小均为 371128 字节。随后又把 Kali 端的程序副本发送到 Windows 的专用实验目录，并再次核验其哈希与大小。这说明两个方向的字节传输均能保持文件内容一致。

图 14　Kali 使用 Socat 接收 Windows Ncat 程序并识别 PE 文件格式

图 15　Windows 原始 Ncat 程序的 SHA-256

图 16　Kali 接收 Ncat 后的 SHA-256 与文件大小

图 17　Kali 将 Ncat 程序副本传回 Windows 的传输日志

从 Windows 实验目录运行接收的 Ncat 副本，版本信息显示为 7.99；在 Kali 的监听窗口中，whoami、hostname 和自定义验证字符串均得到目标主机的正确响应，其中当前账户为 wangxiaoxuan\lenovo。随后输入 exit，会话正常结束。这一轮真正证明了“传输后的 EXE 可执行、可连接、可交互”，而不是仅凭目录中出现文件就认定完成。

图 18　Windows 从实验目录启动传输后的 Ncat 副本

图 19　Kali 接收到 Windows 远程 Shell 的身份、主机名及测试标识

在此基础上，我还通过 C# 编译过一个只显示主机信息的测试 EXE，完成 Windows 本地执行以及向 Kali 传输后的 SHA-256 检查。这部分并非后门验证，而是对“自编译可执行文件能否正常生成、传输并保持内容一致”的补充，避免将普通程序执行与远控功能混为一谈。

图 20　自编译测试 EXE 在 Windows 的真实执行结果

图 21　自编译程序的传输文件校验记录

这一阶段的结论是：Ncat 文件传输、程序启动和 Windows Shell 均验证成功，但它属于替代技术路线，不能直接用来宣称 Meterpreter Session 已建立。

3.3.3 第三次尝试：重新核对环境并成功建立 Meterpreter 会话

后续实验重新回到老师要求的 Metasploit 路线。现场核验了 VMnet1 地址，Kali 的监听端配置使用后期实验网络。相关截图记录了文件跨主机传输，Windows 实验目录出现 backdoor_20242329.exe，大小 7680 字节；还保存了端点防护软件的提示记录。网络、防护提示及文件状态属于本轮真实环境，不把仅有文件传输当作会话成功。

图 22　重新核查 Host-only 实验网段和 Windows 网络接口

图 23　Kali 端传输后门文件的过程记录

图 24　Windows 目录中接收后的 EXE 文件及大小

之后在 Kali 启动对应的 Metasploit Handler。截图显示使用 Windows x64 Meterpreter 类型，操作端地址与当时实验网段匹配，监听端口为 8888。这一步仍只是准备阶段，真正的验收依据来自下一张会话输出。

图 25　第三轮 Metasploit Handler 参数和监听状态

最终截图清楚显示 meterpreter > sysinfo，返回 Computer: WANGXIAOXUAN、OS: Windows 11 24H2+ (10.0 Build 26200)、Architecture: x64 和 Meterpreter: x64/windows。这是实际建立可交互 Meterpreter Session 的直接证据，能够与第一次尝试的“无活动会话”形成前后对照。

图 26　第三轮 Meterpreter 会话建立并执行 sysinfo 的结果

3.3.4 三轮结果对比与任务（3）结论

尝试阶段	核心目标	实际现象	验收结论
第一次：Meterpreter 初试	生成 Windows 载荷并建立会话	PE 文件生成成功；Defender 删除样本；无活动会话	未成功
第二次：Ncat 替代验证	排除文件传输和 Shell 通信故障	双向文件传输及哈希一致；可执行副本提供临时 Windows Shell	替代方案成功，非 Meterpreter
第三次：Meterpreter 再试	建立课程要求的 Meterpreter 会话	Windows 接收 EXE、Handler 监听、`sysinfo` 实际返回	Meterpreter 会话成功

任务（3）的最终结果是第三次尝试成功建立 Meterpreter 会话；前两次分别提供了失败原因和替代验证的证据。将这些环节完整保留，比直接展示最后一张成功截图更有利于说明问题定位过程，也便于与任务（4）的后续会话操作衔接。

3.4 任务四：Meterpreter 音视频、击键与提权尝试

3.4.1 会话身份与进程权限基线

先在已建立的 Meterpreter 会话中运行 getuid、getprivs。截图显示会话身份为 WANGXIAOXUAN\lenovo，并列出数项已启用的进程权限。它说明会话运行于该用户的安全上下文，不能据此推断已成为管理员或 SYSTEM。

图 27　Meterpreter 会话身份与权限基线

3.4.2 远程录音验证

Meterpreter 执行 record_mic -d 5 后显示录制开始、停止，并提示将音频保存至 Kali 路径 /home/kali/netsec_exp2/ojsmXpZH.wav。截图能够证明命令执行并得到保存路径提示；压缩包未包含 WAV 原文件或试听记录，因此本文不延伸认定音质、内容或回放效果。

图 28　Meterpreter 远程麦克风录制及 WAV 保存提示

3.4.3 摄像头图像验证

实验资料中保存了 Kali 图片查看器显示的 LMpYTkPg.jpeg，图片分辨率 1280×720，内容为目标主机摄像头拍摄的实际画面。它证明 Kali 端取得了可打开的摄像头图像。由于该张证据主要展示文件预览，不能从这一截图单独还原每一步的采集命令或权限弹窗。

图 29　Kali 端查看已取得的 Windows 摄像头照片（公开发表请保护面部隐私）

3.4.4 击键记录验证

Meterpreter 会话先运行 keyscan_start，再通过 keyscan_dump 读取记录，实际得到字符串 wrzsxcm；最后 keyscan_stop 显示停止。和之前只监听本地 WinForms 输入框的演示不同，这张截图来自 Meterpreter 的专用键盘记录功能。

图 30　Meterpreter 击键记录启动、输出与停止的实际结果

3.4.5 提权尝试及失败结果

Meterpreter 会话中执行 getsystem，返回 Send timed out；随后再次运行 getuid，身份依然为 WANGXIAOXUAN\lenovo。因此，本次确实进行了提权尝试，但没有证据表明提升到 SYSTEM。与前期 Windows 通过 UAC 正常打开管理员 PowerShell 的实验也不可混淆。

图 31　Meterpreter 提权超时及提升后身份未改变的验证

3.5 任务五：将 MSF Shellcode 注入 pwn1 的尝试与独立 Shell 验证

3.5.1 原始目标文件核验

Kali 原始文件位于 ~/netsec_exp2/original/pwn1，file 显示为 ELF 32-bit LSB executable, Intel i386, dynamically linked, not stripped，文件大小 7418 字节。这一步明确了实验对象和架构：目标是现有 32 位 ELF，而不是任意生成一个新程序。

图 32　原始 pwn1 的 ELF 类型、架构和文件大小

3.5.2 模板与格式尝试

尝试使用 msfvenom 配合 pwn1 模板进行处理，日志显示输出仅 68 字节。这个大小明显不同于原始 7418 字节 ELF，截图也没有给出所需的模板注入成功证据。因此不能仅凭工具打印 Saved as 就认定原程序已完成注入。

图 33　msfvenom 模板处理结果与异常的输出长度

图 34　独立原始二进制 Shellcode 生成和文件检查记录

3.5.3 文件入口与可加载段问题

在后续尝试中，检查过 pwn1_injected_20242329 的格式及入口地址，并试图通过修改文件头入口字段改变执行流。截图表明该文件仍被识别为 32 位 ELF，但缺少其能够执行预期 Shellcode 的证明。

图 35　实验副本的 ELF 格式与入口地址检查

另一次尝试使用 objcopy 增加 .shell 节。工具提示：allocated section '.shell' not in segment。虽然 ELF 入口字段后来显示为 0x8049000，但修改后的文件运行没有留下目标反向 Shell 成功的证据。这里的核心问题是新增节并不意味着对应内容已经被程序加载器映射到可执行段。

图 36　新增节区与可加载段不匹配的警告及运行尝试

3.5.4 独立 Linux ELF 反向 Shell 功能验证

为区分“Payload 不能工作”和“注入过程失败”，另行生成独立的 Linux x64 ELF 反向 Shell 样本。生成日志显示 Payload 130 字节、ELF 文件 250 字节。后续 Metasploit Handler 输出 Command shell session 1 opened，同一 Kali 环境下 id 返回 uid=1000(kali) 等信息。这能够证明独立 x64 Linux 载荷在所示本机网络回环场景下成功建立命令会话。

图 37　Linux x64 独立 ELF 载荷生成及执行记录

图 38　Metasploit 中独立 Linux Command Shell 会话及 id 输出

需要特别指出：此处独立载荷为 x64 ELF，原始 pwn1 为 i386 ELF，截图也没有显示运行被修改的 pwn1 后建立会话。因此任务（5）的严格结论是：Shellcode 独立反向 Shell 功能得到验证，但向原有 pwn1 注入并成功获取反向 Shell 的要求尚未达成。

3.6 五项任务验收汇总

课程任务	实际验收结果	对应证据
（1）Netcat Shell 与 cron	完成；测试任务已清理	图2—图5
（2）Socat Shell 与计划任务	完成；采用 Socat＋Ncat 混合方案	图6—图9
（3）生成、传输并建立 Meterpreter 会话	第一次受阻、第二次 Ncat 替代验证、第三次成功建立 Meterpreter	图10—图26
（4）音视频、击键及尝试提权	音频保存提示、摄像头图片、击键输出已记录；提权未成功	图27—图31
（5）将 Shellcode 注入 pwn1 获取反向 Shell	原 ELF 注入未成功；独立 Linux ELF 反向 Shell 成功	图32—图38

4. 问题及解决方案

4.1 Netcat 远程 Shell 建立后立即退出

在任务（1）的初次实验中，Windows 与 Kali 之间已经能够正常建立 TCP 连接，双方发送的测试字符串也可以正确接收，但当我尝试通过 Netcat 调用 Windows 命令解释器时，连接很快就终止了，没有获得预期的交互式 Shell。

最初我怀疑是虚拟机网络或端口配置的问题，但重新检查后发现，普通文本通信能够成功，说明至少在测试时，双方的 IP 地址、端口和基本 TCP 通信并不存在明显障碍。问题更可能发生在命令解释器启动以及标准输入、标准输出与网络连接关联的过程中。

为了缩小排查范围，我先尝试通过远程连接执行简单的固定命令，确认目标主机能够返回命令执行结果，再重新测试交互式命令解释器。后续调整了 cmd.exe 的启动参数，使用 /D /K 组合后，Kali 终端终于能够持续显示 Windows 命令提示符，并成功执行 whoami、hostname 等命令。

其中，/D 用于禁止执行命令处理器的自动运行配置，/K 用于执行指定命令后保持命令解释器运行。需要说明的是，本次同时修改了两个参数，因此不能仅凭最终成功就认定问题完全由某一个参数造成。

这次排查使我认识到，TCP 连接成功并不意味着交互式 Shell 一定能够正常工作。网络连接只是基础条件，命令解释器自身的运行状态以及输入输出流的处理方式，同样会影响最终结果。

4.2 虚拟机网络模式变化导致连接参数不一致

实验初期，我使用 VMware 的 NAT 网络，Kali 地址为 192.168.37.130。后来为了使 Windows 物理主机与 Kali 之间的实验通信更容易管理，又将虚拟机调整至 Host-only 网络，此时 Kali 地址变成了 192.168.19.128。

这一变化在普通 Netcat 通信中比较容易发现，因为连接时会直接指定目标地址。但在 Metasploit 实验中，情况有所不同：生成可执行载荷时使用的连接地址已经包含在对应程序配置中，后续即使修改监听器的 LHOST，也不会自动更新此前生成的文件。

我们第一次生成的 Meterpreter 程序使用的是旧网络地址，而后来启动的监听器使用了新的地址。因此，即使文件本身没有被安全软件拦截，这种配置不一致也可能导致反向连接无法正确建立。

排查时，我重新区分了 Windows 主机地址、Kali 当前地址、载荷中的连接参数和监听器参数，避免把它们混为一谈。同时通过实际网络通信结果确认，Windows 与 Kali 在新的网段中可以互相访问。

第三轮实验重新核对了实际使用的网络配置，最终成功建立 Meterpreter 会话。通过这一过程，我更加清楚地理解了反向连接的工作方式：目标端需要主动连接预先指定的监听地址，网络环境发生变化时，不能只检查监听器，还必须考虑已经生成的程序是否仍然使用旧配置。

4.3 安全软件拦截导致第一次 Meterpreter 实验失败

任务（3）第一次尝试时，Metasploit 已经成功生成 Windows x64 平台的 Meterpreter 可执行文件。Kali 端显示 Payload 大小为 509 字节，最终生成的 EXE 文件大小为 7680 字节，文件格式检查也表明它属于 Windows PE32+ 可执行程序。

然而，在将文件传输至 Windows 后，预期的远程会话并没有建立。起初仅根据文件未能正常使用的现象，还无法确定问题来自传输失败、文件损坏还是程序执行受阻。

随后检查 Windows 安全中心的防护历史，发现 Microsoft Defender 将该文件识别为 Trojan:Win32/Zusy.NCD!MTB，并执行了删除操作。这说明第一次实验的主要障碍并非 Metasploit 无法生成程序，而是生成的文件在目标主机上受到安全软件拦截，未能完成正常运行。后续实验材料中还出现了火绒安全软件的告警和删除记录，说明不同安全软件对这一类程序都可能产生检测与处置行为。

这里需要区分两个结论：生成日志可以证明可执行文件已经在 Kali 端产生，但不能证明它已经在 Windows 上成功运行；文件传输过程结束，也不代表目标系统一定保留了该文件。

第三轮实验最终成功建立了 Meterpreter 会话，证明该技术路线在当时的实验环境下能够运行。不过，仅凭最终的成功截图，不能完整还原实验期间所有安全软件配置的变化。因此，我将早期拦截记录作为真实的实验故障保留，而没有简单地把第一次失败归结为网络不通。

4.4 改用 Ncat 排查文件传输与远程 Shell 问题

第一次 Meterpreter 实验失败后，我没有立即认定整套通信方案存在问题，而是尝试使用 Nmap 套件中的 Ncat 进行替代验证。这样做的目的，是把可执行文件传输、程序运行和远程命令交互三个环节拆开检查。

首先，我使用 Windows 已经安装的 Ncat 程序进行传输测试。原始文件大小为 371128 字节，Windows 将其发送至 Kali 后，再通过反方向传回 Windows 实验目录。为了确认文件在传输过程中没有发生变化，我分别在两端计算 SHA-256。

三处文件的哈希值一致：

78f022cf3f4d41bb538c678e5e9f9f907abf00fc8a16ee528f765e316609ea15

这比单纯看到“文件已接收”更有说服力，因为文件名相同、大小相同都不能完全排除内容变化，而 SHA-256 一致能够为文件完整性提供更可靠的校验依据。

接下来，我没有直接使用原安装目录中的 Ncat，而是从 Windows 实验目录运行传输回来的副本。程序正确显示 Ncat: Version 7.99，说明传输后的可执行文件能够启动。

随后在 Kali 建立临时监听，Windows 通过该副本建立连接。Kali 端成功获取 Windows 命令提示符，执行 whoami 后返回 wangxiaoxuan\lenovo，执行 hostname 后返回 wangxiaoxuan，自定义实验标识 E2_TASK3_20242329_OK 也正确输出。实验结束后，我主动退出远程 Shell，并删除 Windows 实验目录中的副本，使用 Test-Path 验证文件已经不存在。

为了进一步验证自行生成可执行文件的能力，我还使用 C# 编译了一个输出主机名、用户名及测试标识的 Windows 程序，并通过 Ncat/Socat 进行传输和哈希校验，验证结果同样正常。

这一阶段虽然没有获得 Meterpreter 会话，却并非毫无价值。它独立证明了实验环境具备跨主机传输可执行文件、运行接收程序以及建立临时远程 Shell 的能力。

因此，后续排查 Meterpreter 时，就没有必要再将所有失败现象都归因于网络或文件传输。与此同时，我也认识到 Ncat Shell 与 Meterpreter Session 在功能和协议上存在区别，前者成功不能直接证明后者成功。

4.5 从普通 TCP 连接到真正的 Meterpreter 会话

在排查 Metasploit 监听器时，我曾通过 Windows 对 Kali 监听端口进行普通 TCP 连通性测试。测试显示目标端口可以连接，但 Metasploit 随后输出会话无效、连接关闭等信息。

这时我最初容易产生一个误解：既然监听器已经收到连接，是否就意味着 Meterpreter 会话建立成功？

后来分析发现，普通 TCP 测试只能证明目标端口能够建立网络连接，并不会自动完成 Meterpreter 所要求的协议交互。监听器显示存在连接请求，与真正得到可以执行 sysinfo、getuid 等指令的 Meterpreter 会话，是两个不同层次的结果。

第三轮重新进行实验后，Kali 端终于进入 Meterpreter 交互界面，执行 sysinfo 能够返回 Windows 11、x64 架构以及 WANGXIAOXUAN 等真实系统信息。这一次才具备了有效会话的直接证据，也为任务（4）的后续功能验证创造了条件。

这三轮实验让我形成了更明确的验收习惯：不能只根据工具显示“启动成功”“端口已监听”或“连接已建立”来判断整个实验成功，而应当继续验证目标功能是否真正可用。对于 Meterpreter，进入交互会话并成功返回目标系统信息，比单纯的端口连接日志更具有证明力。

4.6 Meterpreter 功能验证中的结果判定

任务（4）建立在第三轮成功获取 Meterpreter 会话的基础上。我分别对目标主机的音频、摄像头和击键记录功能进行了验证，并保存了对应的控制台输出及实验文件。

在音频和摄像头实验中，不能只看到程序报告“开始采集”，就直接认定采集成功。还需要观察执行完成后的文件保存提示，以及输出文件是否实际产生。此次实验保留了远程音频录制、摄像头拍照对应的执行记录，为相关结论提供了依据。

击键记录实验则需要特别注意开始、停止和读取记录之间的关系。执行启动命令只能证明工具接受了启动请求，是否实际捕获到测试输入，还需要结合读取结果判断。如果出现错误提示，也应将错误保留下来，而不是为了使报告看起来完整而删除失败信息。

通过这一部分实验，我认识到远程控制工具的各项功能虽然集中在同一个交互界面中，但它们涉及的系统接口和权限条件并不相同。会话能够建立，不意味着每项扩展功能都一定成功。因此，每个功能都需要单独进行结果验证。

4.7 Meterpreter 提权尝试超时，用户身份未改变

任务（4）的最后一项是尝试提升会话权限。

实验开始时，我先使用 getuid 查询当前会话身份，确认会话运行在 Windows 普通用户上下文中。随后执行 getsystem 尝试提升权限，但控制台出现 15 秒通信超时提示。

为判断这次提权是否真正生效，我没有仅凭“已经发送提权命令”就宣布成功，而是再次查询会话身份。结果仍然是 WANGXIAOXUAN\lenovo，没有出现预期的 NT AUTHORITY\SYSTEM。

因此，本次能够确认的结论是：Meterpreter 提权操作已经尝试，但没有得到成功提升权限的证据。

此前我还做过 Windows UAC 权限对比实验。普通 PowerShell 的完整性级别为 Medium，管理员权限判断为 False；通过用户主动授权启动管理员 PowerShell 后，完整性级别变为 High，管理员权限判断为 True。这一对比说明同一 Windows 账户在不同访问令牌下，可以具有不同的进程权限。

但 UAC 授权提升与 Meterpreter 获取 SYSTEM 权限并不是同一种机制，不能将前者的成功结果当作后者的证据。

这次失败也让我更加注意权限验证的严谨性：真正的提权成功需要提升后的身份和权限信息作为支持。至于 getsystem 超时的具体原因，仅凭本次输出还不能确定是否与 Windows 版本、所采用的提权技术或其他系统限制有关，因此没有作出缺乏依据的归因。

4.8 Shellcode 注入 pwn1 时遇到的 ELF 结构问题

任务（5）是本次实验中排查过程较复杂的一部分。

实验目标不是简单生成一个能够建立反向 Shell 的 Linux 程序，而是将 MSF 生成的 Shellcode 注入已有的 pwn1 可执行文件，使修改后的程序能够执行相应功能。

最初，我检查了原始 pwn1 的文件信息，确认其属于 32 位 Linux ELF 程序。随后尝试使用 Metasploit 对原文件进行模板处理，但工具产生了与预期不符的输出，无法直接确认生成文件仍然保持了原程序的完整结构。

为了继续分析，我又尝试生成原始机器码，并研究将其添加至 ELF 文件的不同方式。

第一次采用简单追加的方法时，虽然能够把新数据写入文件，但这并不意味着 Linux 加载器会把追加数据作为可执行代码映射到内存，更不意味着处理器的执行流程会自动跳转到该位置。

之后尝试新增 .shell 节，工具给出了类似 allocated section not in segment 的警告。这个现象使我意识到，此前对 ELF 文件结构的理解还不够充分。

ELF 中的 Section 主要用于组织代码、数据和符号信息，而程序真正加载运行时还依赖 Program Header 描述的 Segment。即使新增节具有可执行属性，如果它没有被正确纳入加载段，运行时仍可能无法按照预期访问和执行其中的机器码。

同时，原始 pwn1 是 32 位程序，而后续独立功能验证采用了 Linux x64 载荷。二者在机器指令、寄存器、系统调用约定等方面都存在差异，不能把独立 x64 程序成功运行直接理解为原始 32 位 ELF 注入成功。

在多次尝试未取得预期效果后，我保留了原始 pwn1，将修改操作限制在实验副本中，避免继续操作破坏原始文件。

4.9 通过独立 Shellcode 验证进一步缩小问题范围

虽然向原始 pwn1 注入 Shellcode 的尝试没有成功，但我没有立即将问题归结为 Shellcode 本身不可用，而是进行了独立的反向 Shell 功能验证。

在这一轮实验中，我生成了独立 Linux x64 ELF 载荷，使用 Metasploit 监听对应连接。执行程序后，监听端出现 Command shell session 1 opened，随后通过 id 命令获得 uid=1000(kali) 的输出。

这说明独立生成的 Linux 载荷具备建立反向 Shell 并执行命令的能力。至少在该验证场景下，监听器、连接过程及载荷的基本功能能够正常工作。

结合此前的失败现象，可以把任务（5）的问题范围进一步缩小：当前主要没有解决的是如何将新的机器码正确放置到已有 ELF 中，并使程序按照预期执行，而不是所有反向 Shell 载荷都无法运行。

但也必须明确，独立 ELF 运行成功不等于成功完成对原始 pwn1 的注入。本次实验只完成了 Shellcode 相关功能的独立验证，原程序注入这一具体目标尚未达到。

相比单纯追求最终输出，这部分实验让我更深刻地认识到：生成机器码、修改二进制文件、让操作系统正确加载代码，以及改变程序控制流，是四个相互关联但不能互相替代的技术环节。只有逐层验证，才能真正定位问题。

4.10 本次实验问题排查的总结

回顾整个实验，我发现前期最容易出现的问题，是把某一个环节的成功误认为完整任务已经完成。例如，TCP 连接成功不等于远程 Shell 可以持续交互；EXE 生成成功不等于目标主机能够运行；Meterpreter 监听器收到连接不等于建立了有效 Session；Shellcode 独立运行成功，也不等于已经成功注入原有程序。

任务（3）的三轮尝试是一个比较典型的例子。第一次发现安全软件拦截后，我通过 Ncat 替代方案独立验证了文件传输、完整性校验和远程命令交互，随后又结合网络地址变化重新检查连接条件，最终在第三轮获得真实的 Meterpreter 会话。相比直接得到一个成功结果，这个过程使我更加理解各个技术环节之间的依赖关系。

任务（4）和任务（5）则让我进一步意识到，实验报告不仅需要记录成功，也应该准确说明失败的范围。提权命令已经执行，但身份没有变化，就不能写成提权成功；独立反向 Shell 已经建立，但 pwn1 修改未达到目标，也不能将两种结果混为一谈。

我认为本次实验最重要的收获，是逐渐形成了依据实际输出判断结果的习惯：先确认现象，再分析可能原因，通过新的验证缩小范围，最后根据证据确定结论，而不是为了符合预期结果而反过来解释实验现象。

5. 学习感悟与思考

5.1 实验反思

做前两项实验时，我起初比较关注命令有没有报错、端口有没有打开。实际操作后才发现，这样的判断太粗糙：只有看到远端主机真实返回的身份、主机名或操作结果，才能知道验证进行到了哪一步。cron 与 Windows 计划任务的实验也帮助我把“程序能够定时运行”与“程序拥有远程控制功能”区分开来。

任务（3）实际上经历了三个阶段。首次生成 Meterpreter 程序之后就被安全软件删除，令我一度把“文件能生成”误当成接近成功。接着，我转而使用 Ncat 检查两个方向的文件传输、校验值和临时 Windows Shell，还另外编译普通 EXE 排除基础执行环境问题。这些测试虽然没有直接得到 Meterpreter，却帮我分清了哪些环节已经能正常运行。直到第三次重新开展 Meterpreter 实验并看到 meterpreter > sysinfo 的真实输出，我才有把握将任务（3）的最终状态判为成功。三次尝试的作用不同，都值得在报告中留下证据。

任务（4）给我的印象是，安全测试中的每个功能都应当分别验收：录音保存提示、摄像头图片、击键输出和权限身份不是同一类证据。特别是 getsystem 超时之后，getuid 依然是普通账户，说明不能因为发出命令便填写“提权成功”。

任务（5）的结果让我进一步认识到 ELF 文件结构的重要性。独立 Linux Shell 可以建立连接，但改动过的 pwn1 并没有达到同样效果，根源并非单纯的“命令不对”，而是体系结构、入口位置和加载段需要同时成立。这也是我认为本次实验最值得后续补强的技术点。

5.2 思考题

（1）后门可能通过什么方式进入系统？可能被夹带在看似正常的软件包、受攻击服务的后续下载内容、被植入的安装程序或存在权限缺陷的软件更新链路中；具有高权限的内部操作和不恰当的软件来源管理也可能成为入口。从防御角度应重视来源核验、完整性校验、最小权限和终端防护。

（2）Windows 与 Linux 的后门可能通过哪些机制启动？ Windows 的启动文件夹、注册表登录项、服务和任务计划程序都可以配置程序运行；Linux 则可能使用 systemd 服务、cron、用户登录脚本等机制。相同机制也广泛用于合法软件，因此排查时应结合程序路径、签名、行为与变更来源，不应仅凭“存在计划任务”认定为后门。

（3）Meterpreter 能提供哪些深入系统的功能？在具体版本、系统权限和设备条件允许时，它可提供系统信息与进程查询、文件操作、截图、摄像头/麦克风相关功能、按键记录以及权限检查或尝试提升等。功能是否成功必须逐项验证；例如本次录音与击键有输出，而提权未成功。

（4）如何发现系统是否被安装后门？可从异常进程、服务、计划任务、自启动项、网络监听与外联连接、账户及权限变化、终端防护日志、文件完整性变化等方面交叉核查。不能依赖单一可疑文件名，更不能把一条正常的 TCP 连接直接判断为后门。发现异常时，先保留时间、路径、哈希与事件日志，再按要求隔离和处置。

参考资料

课程《网络与系统攻防技术》实验二任务书与实验报告模板（2026 年 10 月）。
Nmap Project. Ncat Users' Guide. https://nmap.org/ncat/guide/index.html
Socat Project. socat — Multipurpose relay. https://www.dest-unreach.org/socat/doc/socat.html
Rapid7. Metasploit Framework Documentation. https://docs.metasploit.com/
Microsoft Learn. Task Scheduler、Windows Security 与访问令牌相关文档. https://learn.microsoft.com/windows/
Linux man-pages. crontab(5)、cron(8)、elf(5)、readelf 相关技术手册。
0x11_MAL_逆向与Bof基础.md：https://gitee.com/wildlinux/NetSec/blob/master/ExpGuides/0x11_MAL_逆向与Bof基础.md
0x12_MAL_Shellcode基础.md： https://gitee.com/wildlinux/NetSec/blob/master/ExpGuides/0x12_MAL_Shellcode基础.md
0x13_MAL_使用netcat进行反弹链接的shellcode.md: https://gitee.com/wildlinux/NetSec/blob/master/ExpGuides/0x13_MAL_使用netcat进行反弹链接的shellcode.md

posted on 2026-10-18 15:42 Jliessin 阅读(7) 评论(0) 收藏举报

刷新页面返回顶部

Jliessin

公告