7.15 Windows 版本识别
「7C Windows 系统基础」系列 Part 1，免费开放。 从这一篇开始，我们正式进入 Windows 后渗透的地基课。很多人拿到一个 Windows shell 就急着
mimikatz一顿乱甩，结果发现权限不对、补丁太新、漏洞根本打不上。问题往往不在工具，而在你从一开始就没搞清楚这台机器到底是什么版本、打了多少补丁。这一篇把"怎么认出这台 Windows"讲透——它是后面所有提权、横向、协议课的入口。
一、为什么第一件事永远是"认版本"
打个比方。你手里有一把钥匙，听说这把钥匙能开一种锁。可你到了门口一看，门上挂着三把长得几乎一模一样的锁，你不先搞清楚哪把是你那把钥匙对应的锁，就敢一把一把捅吗？捅错了，要么捅不动，要么直接把锁弄坏。
Windows 提权就是这个道理。每个公开的提权漏洞——不管是 CVE-2021-1675 还是 CVE-2023-23397——都不是"对所有 Windows 都管用"的万能钥匙。它有严格的适用范围：
- 只对某个大版本管用（比如只支持 Win10 1809 到 21H2）；
- 只在"没打某个 KB 补丁"的机器上管用；
- 只对某种架构管用（x64 能打、x86 不能打，或者反过来）。
你要是连这台机器到底是 Win10 还是 Win11、是 Server 2016 还是 Server 2022、补丁打到了哪个月都不知道，就只能靠碰运气。运气在渗透里是最贵的成本，所以专业选手拿到 shell 后的第一句话，永远是去"认版本"，而不是"上武器"。
这张图你后面会反复用到。今天的任务，就是把第一步"认版本"这条路上的四条工具全摸熟。
二、四条认版本的路：从快到准
Windows 上认版本的命令有好几个，它们各有快慢、各有精度。我们从最快的 ver 开始，一路讲到最准的 WMI。
2.1 ver：一眼看内核号
这是最快的一条路，敲下去立刻出结果：
C:\> ver
Microsoft Windows [Version 10.0.19045.6093]它只告诉你一件事：内核主版本号 + Build 号 + 补丁修订号（UBR）。上面这个 10.0.19045.6093 的意思是：内核版本 10.0、Build 19045、第 6093 次补丁修订。
问题来了——很多人看到 10.0 就以为是 Windows 10。这是新手最大的坑。 Windows 11 的内核号也是 10.0。微软从 Windows 10 开始就把内核版本号焊死在 10.0 不动了，Win11 只是改了 Build 号。所以单看 10.0 完全分不清十和十一，必须看后面的 Build 数字。
2.2 winver：弹窗看个大概
如果你是在图形界面里，最直观的就是按 Win+R 输入 winver，会弹一个关于对话框：
关于 Windows
---------------------------
版本 22H2（操作系统内部版本 19045.5608）这个弹窗会告诉你版本号（22H2）和内部版本号。但它有两个致命缺点：一是它弹窗，非交互 shell 里根本弹不出来；二是它不告诉你补丁详情。所以它适合在自己本机上看，不适合在远程 shell 里用。
2.3 systeminfo：全量快照
真正干活用的是 systeminfo。它会把这台机器的操作系统、补丁、域信息、硬件全列出来，输出很长，但信息最全：
C:\> systeminfo | findstr /B /C:"OS 名称" /C:"OS 版本" /C:"系统类型" /C:"OS 制造商"
OS 名称: Microsoft Windows Server 2019 Datacenter
OS 版本: 10.0.17763 N/A 内部版本 17763
OS 制造商: Microsoft Corporation
系统类型: x64-based 电脑注意这里的"内部版本 17763"——它对应的正是 Windows Server 2019。再往下拉，还有一整块"修补程序"列表，把这台机器装了哪些 KB 补丁全列出来：
Hotfix(s): 15 Hotfix(s) installed.
KB5031539
KB5032000
KB5033371
...这一块"修补程序"列表才是提权的核心情报。 你拿到这个清单，拿去和 Exploit-DB / VulnCheck 上某个 CVE 影响的 KB 对照，就能知道这个 CVE 还能不能打。所以实战里 systeminfo 经常被完整拉下来存档，不是因为它慢，而是因为它信息最全。
2.4 注册表：精确到 Build 和 UBR
如果你只想要精确的 Build 号，不想等 systeminfo 那一长串输出，直接读注册表是最快的：
C:\> reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
CurrentBuild REG_SZ 19045
C:\> reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v UBR
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
UBR REG_DWORD 0x1648CurrentBuild 是内部版本号（19045），UBR（0x1648 是十六进制，换算成十进制就是 5704）是补丁修订号。两个拼起来就是 19045.5704，和 ver 看到的完全对得上。
这里有个坑要单独说：同一个注册表项里还有个叫 CurrentVersion 的值，很多老教程让你去看它。别被它骗了。 从 Windows 10 开始，CurrentVersion 早就不再随版本更新，它要么是 6.3 要么是 10.0，完全反映不出真实版本。看版本认 Build，不认 CurrentVersion。
2.5 WMI：脚本化的精准查询
最后一条路是 WMI（Windows 管理规范），它适合在 PowerShell 里脚本化调用：
PS C:\> Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, OSArchitecture
Caption Version BuildNumber OSArchitecture
------- ------- ----------- --------------
Microsoft Windows 10 Pro 10.0.19045 19045 64-bit老一点的机器上你可能还会看到 wmic 命令（虽然微软已经标记弃用，但 Server 2016/2019 上还在）：
C:\> wmic os get Caption, Version, BuildNumber
Caption BuildNumber Version
Microsoft Windows Server 2019 17763 10.0.17763WMI 的好处是输出干净、可被其他命令直接管道处理——你不需要 findstr 去过滤，Get-CimInstance 直接就能把字段挑出来。后面 7.22 讲 WinRM/WMI 远程管理时，你会反复用到它。
2.6 多语言系统：同一条命令输出不一样
这里有个新手极其容易踩的坑，必须单独拎出来讲。你在中文 Windows 上敲 systeminfo，输出的表头是"OS 名称"；但如果你拿到的是一台英文 Windows，表头就变成了"OS Name"。这意味着你照着中文教程写的 findstr /C:"OS 名称"，到了英文系统上会一个字都匹配不到，输出空白。
这个坑在实际渗透中非常常见——国内企业的服务器大量是英文版 Windows Server，而你手里的速查表很可能是从中文教程抄来的。正确的应对方式有两个：一是先跑 systeminfo 不加任何过滤，肉眼看一眼表头长什么样，再决定 findstr 该用中文还是英文关键字；二是优先用 WMI 而不是 systeminfo，因为 Get-CimInstance Win32_OperatingSystem 返回的是结构化属性名，Caption、Version、BuildNumber 这些字段名在任何语言的 Windows 上都是英文，不受系统语言影响。
| 识别方法 | 输出是否随系统语言变化 | 跨语言可靠性 |
|---|---|---|
systeminfo + findstr | 表头中英文都可能 | 低，容易匹配失败 |
ver | 输出纯英文 | 高 |
注册表 reg query | 值名是英文，数据是数字 | 高 |
WMI Get-CimInstance | 属性名是英文，值随语言 | 中高（字段名稳定） |
这张表记住一个结论：能走 WMI 就别死磕 systeminfo 的 findstr 过滤。 结构化数据天生比文本解析靠谱。
三、Build 号对照：十和十一、Server 和桌面
把上面四条路的输出都汇集到一张表上，你就有了一张"Build 号速查表"。这张表建议收藏，实战里天天用：
| 内部 Build 号 | 桌面版 | Server 版 | 发布年代 |
|---|---|---|---|
| 10240 | Windows 10 1507 | — | 2015 |
| 14393 | Windows 10 1607 | Windows Server 2016 | 2016 |
| 17763 | Windows 10 1809 | Windows Server 2019 | 2018 |
| 19041 / 19042 / 19044 / 19045 | Windows 10 2004~22H2 | — | 2020~2022 |
| 20348 | — | Windows Server 2022 | 2021 |
| 22000 | Windows 11 21H2 | — | 2021 |
| 22621 | Windows 11 22H2 | — | 2022 |
| 22631 | Windows 11 23H2 | — | 2023 |
| 26100 | Windows 11 24H2 | Windows Server 2025 | 2024 |
看这张表，记住三句话：
- Build 号 < 22000，是 Windows 10；Build 号 >= 22000，是 Windows 11。 这是区分十和十一唯一可靠的硬指标。
- Server 版本和桌面版共用同一套 Build 编号体系。 17763 既是 Win10 1809 也是 Server 2019，20348 是纯 Server 2022。所以光看 Build 号你还得配合
Caption（系统名称）才能确定它是桌面还是服务器。 - 数字越大越新、补丁越全。 老 Build 号意味着系统老、补丁老、能打的老 CVE 越多；新 Build 号意味着微软已经修掉了一大批老漏洞，你得找更新的打法。
这张判断流程图，就是你看到 Build 号后脑子里该跑的流程。
三点五、特殊版本：LTSB/LTSC、ESU 和 ARM64
在生产环境里，你还会遇到几种"不在主流对照表"上的特殊版本，认错了会直接选错 CVE。
第一类是 LTSB/LTSC 长期服务版。Windows 10 有个企业专属的 LTSB（Long-Term Servicing Branch），后来改名叫 LTSC。它的特点是：只收安全补丁、不收功能更新、Build 号长期不变。比如 LTSC 2019 的 Build 号就是 17763，和普通 Win10 1809 一样，但它永远不会升级到 19041——这意味着它永远停留在 17763 这一代补丁体系上。如果你看到一台机器 Build 是 17763 但补丁日期特别新（比如 2025 年还在打 17763 的补丁），大概率就是 LTSC 2019。这类机器上，2019 年以后的桌面版 CVE 很多不影响它，但 17763 专属的提权漏洞你都得查。
第二类是 ESU 扩展安全更新。Windows 7、Server 2008 R2 这些早就过了主流支持期的系统，企业可以花钱买 ESU 继续收安全补丁。你会在 systeminfo 里看到一台"Windows 7"还在打 2025 年的 KB——别惊讶，它是买了 ESU 的。这类机器的补丁列表里，每个月的安全补丁 KB 号仍然是有效的对照依据。
第三类是 ARM64 架构。现在越来越多的云服务器和瘦终端跑在 ARM64 上（比如 AWS Graviton、高通骁龙 X Elite 笔记本）。systeminfo 里"系统类型"会显示"ARM64-based 电脑"。如果你拿一个 x64 编译的提权 PoC 往 ARM64 上扔，Windows 会直接拒绝加载——架构不兼容。所以看到 ARM64，你得专门找 ARM64 编译的 exploit，或者干脆放弃这条路换别的打法。
| 特殊版本 | 识别特征 | 对提权的影响 |
|---|---|---|
| LTSB/LTSC | Build 号长期不变、补丁持续更新 | 老 Build 专属 CVE 存活率高，但新桌面版 CVE 不适用 |
| ESU 扩展更新 | 已停服系统仍在收新 KB | 补丁对照仍然有效，但可用 CVE 池更小 |
| ARM64 | 系统类型显示 ARM64-based | x64 PoC 无法直接运行，需 ARM64 编译版 |
| 评估版/Evaluation | Caption 里带 Evaluation 字样 | 功能完整，但到期会自动关机，别当生产目标 |
这四种情况在真实内网里都不罕见。尤其是 LTSC——金融、政务、制造业的工控机大量跑 LTSB/LTSC，因为它们不自动更新功能、不弹升级提示，运维省心。你碰到一台"怎么 Build 号这么老还在打新补丁"的机器，先怀疑 LTSC。
四、真实回显：一次完整的版本识别走查
光讲命令还不够，我们把它们串起来，走一次真实的内网识别流程。假设你通过 Web 漏洞拿到了一台内网 Windows 服务器的 shell，IP 是文档化示例地址 10.10.10.20。
第一步，先看自己是谁、主机叫什么：
C:\> whoami
nt authority\system
C:\> hostname
WEB01咦，一上来就是 nt authority\system，说明这个 webshell 是以系统权限跑的——那倒是省了提权，但我们还是要确认版本，因为后面横向也要用。
第二步，ver 先快速看一眼：
C:\> ver
Microsoft Windows [Version 10.0.17763.107]10.0.17763，根据对照表，这要么是 Win10 1809，要么是 Server 2019。到底是哪个？跑 systeminfo 确认：
C:\> systeminfo | findstr /B /C:"OS 名称" /C:"OS 版本" /C:"系统类型" /C:"原始安装日期"
OS 名称: Microsoft Windows Server 2019 Datacenter
OS 版本: 10.0.17763 N/A 内部版本 17763
系统类型: x64-based 电脑
原始安装日期: 2026/3/12, 上午 9:47:21确认了：Windows Server 2019 Datacenter，x64 架构。 注意"原始安装日期"是 2026 年 3 月——这是台新装机。
第三步，看补丁列表，判断还能打哪些 CVE：
C:\> systeminfo | findstr /C:"KB"
修补程序安装: 45 个修补程序程序已安装。
[01]:[KB5031539]
[02]:[KB5032000]
[03]:[KB5033371]
[04]:[KB5034122]
...这里你会发现一个实战要点：补丁列表很长，但真正决定"哪个 CVE 还能打"的是"最新一个月度补丁是哪个 KB"。比如这台机器最新补丁是 2024 年初的 KB，那 2024 年下半年爆出来的提权 CVE 理论上还没打——但 2023 年下半年之前的老 CVE 基本都被这些补丁覆盖了。
第四步，PowerShell 里用 WMI 再精确复核一遍，顺便看架构：
PS C:\> Get-CimInstance Win32_OperatingSystem | Format-List Caption, Version, BuildNumber, OSArchitecture, InstallDate
Caption : Microsoft Windows Server 2019 Datacenter
Version : 10.0.17763
BuildNumber : 17763
OSArchitecture : 64-bit
InstallDate : 20260312094721.000000+480四路信息全部对上了：Server 2019、Build 17763、x64、2026 年 3 月装机。这时候你心里才有底——接下来该翻的是"Server 2019、补丁截至 2024 年初"这一档的提权 CVE，而不是拿 Win11 的 exploit 去瞎试。
这里再补一个实战细节：看补丁列表别一个一个去对 CVE，那样太慢。正确的做法是先找到最新那一个月度累积补丁的 KB 号，然后去 Exploit-DB 或 VulnCheck 上搜"这个 KB 之后新出的提权 CVE"——只要它的"修复补丁"比这个 KB 更新，就说明目标大概率还没打。这一招能把几十条补丁过滤成两三个候选 CVE，比对着全表翻高效得多。另外要注意"原始安装日期"和"当前补丁日期"的差距：装机很新但补丁很旧的机器，往往是测试环境或长期没人管的跳板，这种机器上老 CVE 的存活率反而更高。
五、提权视角：版本识别为什么是第一道门
最后我们把"为什么要认版本"这件事，从攻击者视角再拔高一层。
很多新手以为提权是"会用工具就行"，其实不是。提权的本质是一次版本-补丁-CVE 的三角对位：
看懂这张图你就明白了：认版本不是走形式，它直接决定了你能进哪扇门。 版本对不上，再牛的 PoC 也白搭；版本对上了，你才能在几十个候选 CVE 里精准锁定那一两个还能用的。
还有一个常被忽略的细节：架构也要认。 上面 systeminfo 输出里"系统类型: x64-based 电脑"告诉你这是 64 位。如果你拿一个 x86 编译的提权 payload 往 x64 机器上扔，轻则不执行，重则直接崩进程。所以 OSArchitecture 这一行和 Build 号一样重要。
5.1 蓝队视角：版本枚举怎么被发现
从蓝队角度看，版本识别这一串命令其实是非常容易被 EDR 关联检测的行为。原因很简单：正常用户不会刚登上来就连着敲 ver、systeminfo、reg query、Get-CimInstance——这一串组合拳本身就是"攻击者在踩点"的特征。
现代 EDR 会做行为关联：如果一个新进程（尤其是 webshell 起的 cmd.exe 或 powershell.exe）在短时间内依次调用了 systeminfo、reg query CurrentVersion、wmic os get，它的告警优先级会自动拉高。蓝队的检测规则通常不是"检测某条命令"，而是"检测一个陌生进程在五分钟内收集了操作系统版本、补丁列表、域名信息、用户列表"这种行为链。
| 命令 | 正常用户会不会敲 | EDR 关注度 |
|---|---|---|
ver | 偶尔会（查兼容性） | 低 |
systeminfo | 很少（太慢，一般在排障时用） | 中 |
reg query ...CurrentVersion | 几乎不会 | 高 |
wmic os get / Get-CimInstance Win32_OperatingSystem | 几乎不会 | 高 |
| 上面四条在两分钟内连续出现 | 绝对不会 | 极高（直接告警） |
所以红队在做版本识别时，一个实战技巧是：别一口气把四条全敲了。先敲 ver 拿到 Build 号，够用就先收手。真需要补丁列表时，隔几分钟再跑 systeminfo，把时间差拉开，EDR 的行为关联规则就不容易命中。当然在靶场里你不用管这些，怎么快怎么来；但在真实红队项目里，这种"节奏控制"本身就是技术的一部分。
合规提醒：本篇所有命令与回显仅用于授权安全测试、靶场演练和学习研究。实际对任何生产系统执行提权操作，必须事先取得书面授权。示例中的 IP 均为文档化内网地址，请勿对真实公网目标套用。
六、本篇小结
- 拿到 Windows shell 后，第一件事是认版本，不是急着上 exploit——不同版本能打的 CVE 完全不同。
- 认版本四条路：
ver看内核号、winver弹窗看大概、systeminfo看全量含补丁、注册表CurrentBuild拿精确 Build、WMIGet-CimInstance脚本化。 - Win10 和 Win11 内核号都是 10.0，区分看 Build 号：>= 22000 是 Win11，< 22000 是 Win10。 别再被
CurrentVersion这个过时值骗了。 - Build 号对照表要存一份：17763=Server2019、20348=Server2022、22000=Win11 21H2。
- 提权 = 版本 + 补丁 + 架构三角对位，认版本是这三件事的第一块拼图。
下一篇 7.16 我们换个角度，不看操作系统本身，而是看它脚下的文件系统——盘符、路径、UNC 共享、哪些目录普通用户能写。看懂这些，你才知道该把文件扔到哪、该往哪里找配置和凭据。