kali渗透windows：一次内网突破的渗透完整记录

晚上十一点，目标机是渗透一台win10企业版，补丁打到2024年3月。渗透我坐在实验室里，渗透kali的渗透终端光标一闪一闪。说实话，渗透这种老掉牙的渗透版本反而比新系统更难啃——补丁齐全但不至于太激进，防御机制没完全开启，渗透正好用来演示经典的渗透渗透链条。

第一步永远是渗透信息收集。nmap扫了全端口，渗透445开放，渗透139开放，渗透3389也开着。渗透SMB服务版本是渗透Windows 10 Pro 19041。我盯着屏幕想，MS17-010早就堵死了，EternalBlue没戏。但SMBv1还在，这倒是个突破口——虽然微软默认禁用了它，可很多企业镜像为了兼容老打印机，会偷偷把它打开。

用auxiliary/scanner/smb/smb_version确认了协议版本，然后直接上msf的smb_ms17_010模块试了试，意料之中地失败。别急，换个思路。我注意到目标机的445端口响应有个细微特征——它的协商超时时间比标准值多了300毫秒。这个细节让我想起一个冷门漏洞：CVE-2020-0796，SMBv3压缩漏洞。但前提是系统得是1909以上的版本，这机器是19041，理论上存在风险。

msf里搜了一下exploit/windows/smb/cve_2020_0796_smbv3_compression，居然有现成的。设置好RHOSTS，payload用windows/x64/meterpreter/reverse_tcp。运行，等待。心跳声在耳机里放大，几秒后，meterpreter会话建立。我松了口气——但别高兴太早，这只是个普通用户权限。

提权是个硬骨头。先跑getsystem，失败。然后手动检查了系统服务，发现一个叫“PrintNotify”的服务运行在SYSTEM权限下，但它的可执行文件路径指向C:\Program Files\Common Files\，而这个目录的写权限居然对所有用户开放。这是个典型的DLL劫持点——把恶意DLL放到那个目录，重启服务，就能以SYSTEM身份执行代码。

写了个简单的反弹shell DLL，用msfvenom生成，文件名改成printnotify.dll，上传到那个目录。然后重启服务——需要管理员权限，但刚才的meterpreter已经是admin了。服务重启后，DLL被加载，一个新的SYSTEM会话弹了回来。

拿到SYSTEM后，横向移动就简单了。先抓取内存中的明文密码——用mimikatz的sekurlsa::logonpasswords，运气不错，抓到域管理员“admin”的明文密码，因为他的会话还挂在这台机器上。接着用psexec模块直接登录域控，整个过程不到两分钟。

最后一步，清理痕迹。删掉上传的DLL，清除事件日志，把meterpreter会话迁移到explorer进程里，确保连接稳定。我关掉终端，看了眼时间——凌晨一点半。整个过程用了两个半小时，主要时间花在信息收集和提权尝试上。这台机器如果装了EDR，或者管理员把SMBv1彻底禁用，恐怕就没这么顺利了。

说白了，内网渗透就像开锁——锁芯再复杂，总有疏忽的边角。这次的关键不是某个0day，而是三个小失误的叠加：SMBv1残留、服务目录权限配置错误、以及域管理员密码明文驻留内存。任何一环堵住，故事就得改写。