内网渗透最难的到底是什么?从权限获取到横向移动逐步解析

发布时间:2026/9/29 22:01:19
内网渗透最难的到底是什么?从权限获取到横向移动逐步解析 引言外网突破只是开始内网才是真正的修罗场在网络安全攻防演练与红队实战中一个普遍存在的认知偏差是拿下边界 WebShell 就等于成功了一大半。然而真正经历过完整内网渗透的人都会告诉你——外网突破往往只是拿到了“入场券”而内网渗透才是真正考验技术深度、耐心与工程化能力的修罗场。很多初学者在靶场环境中能熟练使用 Mimikatz、Cobalt Strike、Impacket 等工具但一旦进入真实企业内网就会陷入迷茫为什么提权总是失败为什么横向移动到第三台机器就断了为什么明明抓到了哈希却登录不了内网渗透最难的从来不是某个单一工具的熟练度而是“在信息不完整、权限不稳定、防御动态变化的复杂环境中持续做出正确决策并保持隐蔽的能力”。它本质上是一个不确定性极高的决策优化问题而非简单的工具堆叠。本文将按照“权限获取 → 权限维持 → 信息收集 → 横向移动”的完整链路逐层剖析内网渗透中的核心难点并给出可落地的实战思路与代码示例。一、权限获取从“能执行”到“能控制”的鸿沟1.1 初始权限的脆弱性假设我们通过一个反序列化漏洞拿到了 WebShell此时权限通常是www-data或iis apppool。这个权限的特点是命令执行受限可能被 AppLocker、WDAC、软件限制策略拦截进程树异常w3wp.exe突然派生cmd.exe会立刻触发 EDR 告警无交互式会话无法直接使用需要 GUI 或凭据缓存的操作。因此权限获取的第一难点不是“提权”而是“将非交互式、受限的初始权限转化为稳定的、可交互的立足点”。很多团队在这一步就开始踩坑——他们成功反弹了 shell却发现连基本的whoami /groups都查不全或者反弹的 shell 在 30 秒后被 EDR 自动 kill。这是因为没有理解一个事实现代企业终端几乎全部默认开启了 PowerShell Logging模块日志、脚本块日志、命令行审计4688、以及 AMSI 集成。任何带有高风险特征的脚本执行都会留下痕迹被 SOC 实时关联分析。1.2 提权路径的选择逻辑在 Windows 环境中提权路径大致分为三类系统配置缺陷如未打补丁的本地提权漏洞CVE-2021-1732、CVE-2022-21882 等服务配置错误如可写服务二进制路径、未引用的服务路径、弱权限注册表项凭据泄露如配置文件中的明文密码、组策略首选项GPP密码、浏览器保存的凭据。很多教程会直接推荐使用Watson或winPEAS扫描漏洞但实战中最容易被忽视的是服务权限配置错误因为它不依赖系统补丁状态且往往能直接获得SYSTEM权限。这是因为大部分漏洞利用工具都依赖特定版本的 Windows 组件但在打了最新补丁的 Windows Server 2022 中仍然有大量老旧服务、自研服务、第三方监控代理如杀毒、备份、运维审计的可执行路径是 Everyone 可写的。以下是一个 PowerShell 脚本示例用于枚举当前主机上可写且以高权限运行的服务# Enum-UnquotedService.ps1# 枚举未引用服务路径且路径中包含空格的服务$servicesGet-WmiObject-ClassWin32_Service|Where-Object{$_.PathName-notmatch^-and$_.PathName-match\s-and$_.StartMode-neDisabled}foreach($svcin$services){$path$svc.PathName$dirSplit-Path$path-Parent$aclGet-Acl$dir$writable$acl.Access|Where-Object{$_.IdentityReference-matchEveryone|Users|Authenticated Users-and$_.FileSystemRights-matchWrite|Modify|FullControl}if($writable){Write-Host[!] 可写服务路径:$($svc.Name)-$path-ForegroundColor Red$writable|Format-TableIdentityReference,FileSystemRights}}解释该脚本通过 WMI 获取所有服务筛选出未加引号且路径含空格的服务再检查其父目录是否对普通用户可写。如果满足条件攻击者可以将恶意可执行文件放入路径中的空格处等待服务重启后以高权限执行。脚本的设计要点在于“PathName -notmatch ‘^’ 即路径不是用英文双引号包裹的否则即使路径包含空格也不存在被空格截断劫持的可能因为 Windows 会把双引号内的整段当成单一可执行文件路径。而在路径中寻找“Everyone、Users、Authenticated Users”这三种身份是基于真实的纵深防御场景用户的提权上下文往往是 Web 应用运行时账号它属于 Users 组。实战中容易踩的两个坑一是 Get-WmiObject 在 Windows Server 2022 高版本上默认会触发 WMI 日志记录建议改用Get-CimInstance -ClassName Win32_Service并加-OperationTimeoutSec 5减少停留时间二是脚本输出的服务路径如果是 UNC 路径如\\FILESERVER\svcbin\app.exe需要额外检查共享权限避免提权后落地的 payload 被文件服务器 AV 立即隔离。1.3 真正的难点提权后的“权限固化”拿到SYSTEM只是瞬间的胜利。真正的挑战在于如何在不触发 EDR 的情况下维持权限如何将SYSTEM权限转化为域内可用的凭据很多人在提权后直接运行 Mimikatzsekurlsa::logonpasswords结果被 Defender 或 CrowdStrike 当场捕获。这是因为现代 EDR 不再依赖特征码而是基于行为链sekurlsa::logonpasswords本质上是读取 lsass 进程内存并调用 samss 服务的 LSA 接口整个过程会触发 lsass 的IRP_MJ_READ操作被 EDR 的 minifilter 驱动捕获后立即中断进程。更隐蔽的做法是使用procdump转储lsass.exe内存离线解析使用comsvcs.dll的MiniDump功能Living-off-the-Land通过DCSync直接向域控请求凭据但前提是已获得域管或复制权限。# 使用 comsvcs.dll 转储 lsass 内存LOLBin 方式$lsassPid(Get-Processlsass).Id rundll32.exe C:\Windows\System32\comsvcs.dll,MiniDump$lsassPidC:\Windows\Temp\debug.dmp full注意该操作会生成一个完整的 lsass 内存转储文件体积可能超过 100MB且rundll32调用comsvcs.dll的行为已被多数 EDR 标记。实战中建议配合进程注入或直接使用Nanodump等更隐蔽的工具。Nanodump的核心原理是通过自己创建目标进程的线程而不是调用 MiniDump API再调用 NtReadVirtualMemory 读取敏感区域整个过程绕过了 lsass 的 MiniDump hook从而规避 EDR 的回调检测。FAQ拿到 SYSTEM 之后应该立刻做什么Q1SYSTEM 提权后是先抓凭据还是先做持久化A在一些项目里EDR 的高敏感操作创建计划任务、修改服务、写入 Startup是会被打告警的所以在获得了 SYSTEM 权限后建议先在C:\Windows\Temp下创建一个目录将后续所有工具以及 output 全部放到该目录中在出网之前依靠 OPEN 套接字和 Tor 代理就能大大缩短横向路径。Q2什么时候适合用 DCSync什么时候适合用 pass-the-ticketADCSync 会在域控的 4662、5136 事件中留下请求复制权的痕迹红队在合规项目中满足需求时、在有隐身需求的项目里应该优先考虑使用 pass-the-ticket 或者 AS-REP Roasting 拿到账号而不是 DCSync。Q3lsass dump 出来以后解析出来的 NTLM 哈希加密后到底存在哪里Alsass 进程中以明文保存的其实是 WDIGEST 明文、NTLMv1 响应、Kerberos 票据等。完整解密需要NTLMv1/NTLMv2的会话密钥及未 EXP 清除的 WDIGEST 明文这些只有在服务器如 RDP 服务器、文件服务器上才会保留。二、横向移动信息收集与协议选择的博弈2.1 横向移动的本质横向移动不是“从一个 IP 跳到另一个 IP”而是利用已掌握的凭据或会话在目标主机上获得执行权限的过程。其核心依赖三个要素凭据明文密码、NTLM 哈希、Kerberos 票据、证书协议SMB、WMI、WinRM、RDP、DCOM、SSH权限目标主机上的本地管理员或域管权限。难点在于不同协议在不同环境下的可用性差异极大且防御检测点各不相同。在广域网场景里SMB、RDP 默认会被边界 ACL 阻断但在内网中几乎所有横向协议都开放。在动辄成百上千台主机的域环境中防御方可能会对每种协议配置不同的微隔离策略比如服务器区限制 135/445办公区限制 5985/5986但常常忽略了 135 上的 DCOM 调用。2.2 协议选择矩阵协议端口依赖条件隐蔽性常见检测点SMB445管理员权限 文件共享中服务创建、命名管道WMI135管理员权限 DCOM中高WMI 事件订阅、进程创建WinRM5985管理员权限 远程管理中事件日志 4688DCOM135管理员权限高DLL 劫持、ShellExecuteRDP3389凭据 登录权限低登录日志 4624实战建议优先使用 WinRM如果目标开启因为其流量加密且日志相对分散其次考虑 DCOM因为它在很多环境中未被重点监控SMB 虽然通用但psexec式的服务创建极易被捕获。特别是在 Windows Defender Credential Guard 开启的环境里PtH 会被禁用反而是 Kerberos 票据Pass-the-Ticket和基于证书的认证拥有更稳定的成功率。另外横向移动协议的选择还要考虑“落地稳定性”比如 WMI 在跨林跨域信任场景里要求 RPC 服务可达DCOM 在调用MMC20.Application的时候会启动 mmc.exe 进程而很多企业终端的 EDR 对 mmc.exe 启动子进程是会告警的。2.3 凭据传递的陷阱Pass-the-HashPtH是横向移动的经典手段但以下情况会导致失败目标主机开启了 LSA 保护RunAsPPL1时无法读取 lsass 内存凭据为域用户但非本地管理员PtH 成功的前提是目标主机上该用户属于管理员组目标开启了 Credential GuardNTLM 哈希被虚拟化保护无法直接使用账户被禁用或锁定经历过多次错误登录后账户会被自动锁定这时 PtH 也会返回 STATUS_ACCOUNT_LOCKEDRestricted Admin Mode 未启用RDP 的 Restricted Admin 模式需要目标机器的注册表项fDenyTSConnections0且组策略启用否则 RDP PtH 无法使用。以下是一个使用 Impacket 进行 PtH 的示例# pth_smb.pyfromimpacket.smbconnectionimportSMBConnectionfromimpacket.examples.secretsdumpimportRemoteOperationsdefpass_the_hash(target_ip,username,ntlm_hash,domain):try:# 使用哈希连接 SMBconnSMBConnection(target_ip,target_ip,sess_port445)conn.login(username,,domain,lmhash,nthashntlm_hash)print(f[] 成功通过 PtH 连接到{target_ip})# 列出共享sharesconn.listShares()forshareinshares:print(f 共享:{share[shi1_netname][:-1]})# 尝试远程执行roRemoteOperations(conn,False,None)ro.enable_reg_remote()print([] 远程注册表操作已启用)returnconnexceptExceptionase:print(f[-] PtH 失败:{e})returnNoneif__name____main__:# 示例使用管理员哈希连接pass_the_hash(192.168.1.10,Administrator,aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0)解释该脚本使用 Impacket 的SMBConnection直接以 NTLM 哈希登录目标 SMB 服务。成功后可进一步利用RemoteOperations启用远程注册表为后续 Dump 凭据或创建服务做准备。注意nthash为空时表示使用空密码实际环境中需填入有效哈希。关键说明在 Windows Server 2012 R2 之后的版本默认会使用 NTLMv2 响应来验证 SMB 登录但 PtH 走的依然是 NTLM over NTLMv2 协议栈所以理论上仍然可以工作。但如果账户启用了“拒绝 NTLMv2”的策略那么 SMB PtH 会直接返回STATUS_NTLM_BLOCKED。优化建议当使用 Impacket 发现响应过慢时可以加-k关闭 Kerberos 协商强制走 NTLM批量扫描时建议加上timeout2避免长时间阻塞。2.4 真正的难点横向移动的“断链”问题在实际内网中横向移动经常在第三跳或第四跳断掉原因包括凭据不通用不同主机使用不同的本地管理员密码LAPS 已普及网络隔离VLAN 或微隔离策略限制了 445/135 端口日志审计大量 4624 登录事件触发 SOC 告警EDR 联动一台主机被标记后同网段其他主机加强监控找不到入口点目标网段没有预先的入口主机反而是打印服务器、监控探针这类“死端主机”被 EDR 重点监控杀进程杀会话在高稳定性场景下每一次新连接启动黑窗口新的进程都会被 EDR 立即终结。解决思路建立“凭据-主机-权限”的三维矩阵优先选择高价值目标避免在低价值主机上浪费凭据。同时使用CrackMapExec或NetExec进行批量验证快速定位可用凭据。# 使用 NetExec 批量验证本地管理员哈希netexec smb192.168.1.0/24-uadministrator-Haad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0--local-auth# 输出示例# SMB 192.168.1.10 445 DC01 [] administrator:... (Pwn3d!)# SMB 192.168.1.11 445 WEB01 [-] administrator:... STATUS_LOGON_FAILURE实战踩坑在批量验证时NetExec默认会为每个 IP 启动一个并行线程但这在生成日志的方面是有爆炸性效果的——一秒钟之内可能出现几十条 4624、4625 事件。常见优化手段包括使用--jitter添加随机延迟50-300 毫秒使用--threads 2降低并发使用--log把结果输出到文件然后离线分析。在有 NAC网络访问控制的环境里过多的认证失败会导致主机被准入策略临时拉黑所以建议先用低权限账号探测开放端口再用高权限账号针对存活主机逐一尝试。“断链”恢复技术如果在第三跳凭据用光不要急于用域管凭据。可以尝试以下方法Kerberoasting对SPN关联的服务账户发起 AS-REP 请求离线爆破 Kerberoast TGS 票据AS-REP Roasting对不需要预认证的账户DONT_REQUIRE_PREAUTH1发起 AS-REQ证书滥用从 CA 服务器获取低权限用户证书再通过 Schannel 进行证书认证横向DCSync 复制权限滥用在已经拿到域内主机权限的前提下搜索具有DS-Replication-Get-Changes权限的账户NTLM 中继在 SMB Signing 未强制要求的环境里利用ntlmrelayx把收到的 NTLM 挑战中继到其他服务LDAP、AD CS。三、踩坑与优化建议3.1 常见踩坑点盲目使用 Mimikatz在未关闭 Defender 的机器上直接运行导致工具被删、权限丢失忽视时间戳与日志横向移动后未清理 4688、4624 日志被蓝队溯源凭据复用过度同一个哈希在 20 台机器上尝试触发账户锁定策略忽略 Kerberos 票据生命周期TGT 默认 10 小时过期后需重新获取未审查 AD CS 证书状态很多企业里证书的私钥是可以通过 NTLM 中继被窃取的提权后没验证进程上下文有时候你以为拿到了 SYSTEM实际上只拿到了某个受限服务上下文如 IIS APPPOOL\DefaultAppPool。3.2 优化建议优先使用 Living-off-the-Land如wmic、powershell、rundll32、mshta减少工具落地使用 C2 的 SOCKS 代理将横向移动流量通过 C2 隧道转发避免直接出网凭据分级管理将域管凭据与本地管理员凭据分开使用降低暴露风险日志清理要谨慎直接删除事件日志会触发告警建议使用wevtutil cl前先评估多协议负载均衡在一类协议被封锁的环境中可以使用 SSH 隧道穿过 22 端口再借助chisel、frp、nps等内网穿透工具构建代理链C2 通道选择要在 packet loss 高的网络中谨慎选择使用 DNS over HTTPS避免被协议层行为特征检测。永久持久化的时机大多数持久化机制计划任务、注册表 Run、服务会产生难以清除的告警事件建议在拿到重要主机后立即评估是否进入项目结束阶段避免被逆源。四、总结与展望内网渗透最难的不是某个漏洞的利用也不是某个工具的使用而是在高度不确定的环境中持续做出“收益-风险”最优决策的能力。权限获取考验的是对系统配置的理解深度横向移动考验的是对凭据与协议的综合运用而贯穿始终的是对防御体系EDR、SIEM、微隔离的敬畏与规避。未来随着 LAPS、Credential Guard、Windows Defender ATP 的普及传统 PtH 和 Mimikatz 的生存空间将进一步压缩。红队需要转向更高级的技术如 Kerberos 委派滥用、AD CS 证书攻击、云环境下的混合身份横向移动例如 AWS IAM Role 令牌被盗用、Azure AD Connect 同步账号滥用。内网渗透的终点不是拿到域管而是理解整个身份认证体系的信任链并找到其中最薄弱的一环。核心结论内网渗透的难度 信息不对称程度 × 防御覆盖密度 × 凭据生命周期。更多硬核网安与AI工具包请扫码获取完整源码谁能在这三个维度上取得优势谁就能在内网中走得更远。