对虚拟机的对虚的渗渗透报告

目标是一台运行VMware Workstation的Windows 10虚拟机，桥接模式，拟机IP 192.168.1.108。透报宿主机是对虚的渗台老旧的ThinkPad，风扇声比键盘敲击声还大。拟机我花了三小时，透报从扫描到拿到SYSTEM权限，对虚的渗过程不算惊艳，拟机但有几个点值得记下来。透报

开局nmap扫端口，对虚的渗只开了3389和445。拟机这个组合其实很无聊——典型的透报“没打补丁的远程桌面+空密码账户”配置。但我没急着猜密码，对虚的渗先试了试SMB的拟机匿名枚举。结果net view直接列出了一个叫“backup”的透报共享文件夹。这个命名太直白了，管理员八成把备份文件全塞在里面。

共享目录里躺着一个名为“password.txt”的文档。打开后，里面是明文记录：Administrator: P@ssw0rd2023。这密码强度不低，但写在共享文件夹里就跟没锁门一样。用这组凭据直接登录远程桌面，进去后第一件事是看用户列表——除了Admin，还有个叫“svc_oracle”的本地账户，属于Remote Desktop Users组。

这个服务账户是突破口。我检查了它的登录脚本，发现指向一个网络路径\\192.168.1.105\scripts\login.bat。而192.168.1.105是台早已关机的旧服务器。这意味着任何能控制这个IP的主机，都能劫持登录脚本。我在攻击机上用Responder监听，伪造SMB服务器，等管理员下次远程登录时，svc_oracle账户会主动把NTLMv2哈希送过来。

等了大概四十分钟，哈希到手。用hashcat跑字典，密码是Oracle#2023——跟文档里的密码风格一致，管理员显然喜欢用年份做后缀。拿到svc_oracle权限后，我注意到它居然被加入了本地Administrators组。这配置错误太典型了，服务账户往往被赋予过高权限，只因为“方便管理”。

提权到SYSTEM很顺利，因为VMware Tools的进程以SYSTEM运行，且其安装目录C:\Program Files\VMware\VMware Tools\对Users组开放写权限。我替换了其中的vmtoolsd.exe为恶意文件，重启虚拟机后，恶意文件以SYSTEM身份执行，反弹shell到手。

整个渗透链条其实没有用到0day，全是配置失误和懒惰习惯：明文密码文件、遗留的SMB共享、过期的网络路径、服务账户权限过大、可写目录中的关键进程。虚拟机的隔离性在这里毫无作用——它只隔离硬件，不隔离人的错误。

最后清理痕迹时，我删掉了共享文件夹里的password.txt？不，我没删。那会打草惊蛇。我只删除了自己上传的恶意文件，并清空了事件日志。管理员大概率永远不知道发生了什么，除非他某天闲得慌去翻共享目录的修改时间。

这次渗透没什么技术含量，但完美诠释了安全最薄弱的环节永远是操作者。虚拟机的快照功能倒是方便，每次搞砸了回滚一下，比物理机省心多了。