目录
1. 开篇与议程概述
2. 上周回顾与 Q&A (凭据验证深化理解)
3. WinRM, Evil-WinRM, PSRemoting 详解
4. PSRemoting 配置与使用
5. JEA (Just Enough Administration) 受限 Shell
6. JEA 受限 Shell 绕过思路 (通用策略)
7. 总结与展望
1. 开篇与议程概述
1.1 本次直播内容焦点 (理论铺垫)
本次直播(周六)主要聚焦于理论知识铺垫,为后续的实操演示打下基础。内容较多,
主要围绕 WinRM、PSRemoting、Evil-WinRM 等远程管理和利用技术展开。同时会回应上周直播后收集到的学员问题。
1.2 后续课程规划 (NXC, JEA Bypass, ADFS)
下周二: 深入讲解
nxc(NetExec) 工具的细节。下周: 完成 PS Remoting 的操作和 JEA 受限 Shell 的绕过实操。
下下周: 进入 ADFS (Active Directory Federation Services) 攻击的庞大板块。
整体趋势: 后续内容将非常密集,工具和概念交叉出现,需要扎实的基础。
2. 上周回顾与 Q&A (凭据验证深化理解)
2.1 NXC (NetExec) 结果分类解析
回顾上周使用 nxc smb 对 DC (192.168.20.10) 进行凭据碰撞的结果,强调需要理解其三种主要输出类型:
[+] ... (Guest): 表示认证尝试成功,但用户名字并不在域里,SMB 不返回STATUS_LOGON_FAILURE,而是把会话降为 Guest。原因: 目标系统配置允许 Guest 访问,但是用户名在域内不存在,但认证机制仍接受了尝试并映射到 Guest。

系统里有一个安全策略或者叫认证机制就是 authentication 的机制是不存在的,用户他会映射成Guest
服务器策略:Network access: Sharing and security model for local accounts = Guest only价值: 对攻击者通常无用,表明该用户名/密码组合不是有效的域凭据。
[-] ... STATUS_LOGON_FAILURE: 表示登录失败。原因: 用户名可能存在于域中,但密码错误;或者用户名根本不存在。

价值: 这些用户名(如
robert,ralph,emma)值得关注,它们是已知的域内账户,只是我们手中没有正确密码。
[+] <DOMAIN>\<USER>:<PASSWORD>: 表示认证成功,且不是 Guest 会话。原因: 提供了完全正确的域用户名和密码。
[+] 0x0security.local\mark:$Ul3S@t0x0S3c
价值: 这是真正有效的域凭据,是后续攻击的关键入口(如
mark:\$Ul3S@t0x0S3c)。
2.2 NetExec/CrackMapExec 工具哲学
NXC/CME 定位: 平台级工具,远超简单爆破,核心在于破解 (Crack)、枚举 (Map) 和执行 (Exec)。
什么是好工具 (高级渗透视角):
参数可控性/透明性: 允许用户精确控制每个参数和行为,而不是黑盒操作。
逻辑清晰: 命令和参数能清晰反映攻击流程和技术原理。
避免过度集成: 高度集成的“傻瓜化”工具对初学者友好,但限制了高级用户的灵活性和深度理解。NXC/CME 在这方面做得较好,提供了丰富且相对底层的选项。
命名解读 (
CrackMapExec):Crack: 验证/破解凭据(密码喷洒、哈希传递等)。Map: 枚举目标信息(共享、用户、组、会话、策略等)。Exec: 在目标上执行命令(通过 SMB, WinRM, WMI 等协议)。这是其强大但可能被忽视的功能。
工具学习建议: 研究 NXC/CME 这类“明星工具”的参数、功能和命名,有助于理解其设计哲学、背后的技术原理和攻击场景,从而超越死记硬背命令。
2.3 凭据验证的多工具策略与排错思路
多工具验证: 验证用户/凭据有效性有多种途径:
2.3.1
nxc smb: 直接验证用户名+密码组合。
2.3.2
nxc users/impacket-GetADUsers: 使用已有凭据枚举域用户列表。
┌──(root㉿kali)-[~/Desktop/APTLabs/credentials] └─# nxc smb 192.168.20.10 -u mark -p '$Ul3S@t0x0S3c' --users SMB 192.168.20.10 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:0x0security.local) (signing:True) (SMBv1:False) SMB 192.168.20.10 445 DC [+] 0x0security.local\mark:$Ul3S@t0x0S3c SMB 192.168.20.10 445 DC -Username- -Last PW Set- -BadPW- -Description- SMB 192.168.20.10 445 DC Administrator 2020-04-17 12:53:42 0 access to gigantichosting site SMB 192.168.20.10 445 DC Guest <never> 0 Built-in account for guest access to the computer/domain SMB 192.168.20.10 445 DC krbtgt 2020-01-02 10:57:34 0 Key Distribution Center Service Account SMB 192.168.20.10 445 DC adfs_svc 2020-01-02 11:23:13 0 SMB 192.168.20.10 445 DC ralph 2020-03-08 12:43:40 0 SMB 192.168.20.10 445 DC emma 2020-03-08 12:43:58 0 SMB 192.168.20.10 445 DC mark 2020-03-08 13:16:05 0 SMB 192.168.20.10 445 DC robert 2020-03-08 12:44:11 0 SMB 192.168.20.10 445 DC [*] Enumerated 8 local users: 0X0SECURITY2.3.3
nxc --rid-brute/impacket-lookupsid: 通过 RID 爆破枚举用户和组 SID。
┌──(root㉿kali)-[~/Desktop/APTLabs/credentials] └─# nxc smb 192.168.20.10 -u mark -p '$Ul3S@t0x0S3c' --rid-brute SMB 192.168.20.10 445 DC [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:0x0security.local) (signing:True) (SMBv1:False) SMB 192.168.20.10 445 DC [+] 0x0security.local\mark:$Ul3S@t0x0S3c SMB 192.168.20.10 445 DC 498: 0X0SECURITY\Enterprise Read-only Domain Controllers (SidTypeGroup) SMB 192.168.20.10 445 DC 500: 0X0SECURITY\Administrator (SidTypeUser) SMB 192.168.20.10 445 DC 501: 0X0SECURITY\Guest (SidTypeUser) SMB 192.168.20.10 445 DC 502: 0X0SECURITY\krbtgt (SidTypeUser) SMB 192.168.20.10 445 DC 512: 0X0SECURITY\Domain Admins (SidTypeGroup) SMB 192.168.20.10 445 DC 513: 0X0SECURITY\Domain Users (SidTypeGroup) SMB 192.168.20.10 445 DC 514: 0X0SECURITY\Domain Guests (SidTypeGroup) SMB 192.168.20.10 445 DC 515: 0X0SECURITY\Domain Computers (SidTypeGroup) SMB 192.168.20.10 445 DC 516: 0X0SECURITY\Domain Controllers (SidTypeGroup) SMB 192.168.20.10 445 DC 517: 0X0SECURITY\Cert Publishers (SidTypeAlias) SMB 192.168.20.10 445 DC 518: 0X0SECURITY\Schema Admins (SidTypeGroup) SMB 192.168.20.10 445 DC 519: 0X0SECURITY\Enterprise Admins (SidTypeGroup) SMB 192.168.20.10 445 DC 520: 0X0SECURITY\Group Policy Creator Owners (SidTypeGroup) SMB 192.168.20.10 445 DC 521: 0X0SECURITY\Read-only Domain Controllers (SidTypeGroup) SMB 192.168.20.10 445 DC 522: 0X0SECURITY\Cloneable Domain Controllers (SidTypeGroup) SMB 192.168.20.10 445 DC 525: 0X0SECURITY\Protected Users (SidTypeGroup) SMB 192.168.20.10 445 DC 526: 0X0SECURITY\Key Admins (SidTypeGroup) SMB 192.168.20.10 445 DC 527: 0X0SECURITY\Enterprise Key Admins (SidTypeGroup) SMB 192.168.20.10 445 DC 553: 0X0SECURITY\RAS and IAS Servers (SidTypeAlias) SMB 192.168.20.10 445 DC 571: 0X0SECURITY\Allowed RODC Password Replication Group (SidTypeAlias) SMB 192.168.20.10 445 DC 572: 0X0SECURITY\Denied RODC Password Replication Group (SidTypeAlias) SMB 192.168.20.10 445 DC 1000: 0X0SECURITY\DC$ (SidTypeUser) SMB 192.168.20.10 445 DC 1101: 0X0SECURITY\DnsAdmins (SidTypeAlias) SMB 192.168.20.10 445 DC 1102: 0X0SECURITY\DnsUpdateProxy (SidTypeGroup) SMB 192.168.20.10 445 DC 1103: 0X0SECURITY\ADFS$ (SidTypeUser) SMB 192.168.20.10 445 DC 1106: 0X0SECURITY\adfs_svc (SidTypeUser) SMB 192.168.20.10 445 DC 1601: 0X0SECURITY\splunk_gigantichosting (SidTypeGroup) SMB 192.168.20.10 445 DC 1603: 0X0SECURITY\demo_gigantichosting (SidTypeGroup) SMB 192.168.20.10 445 DC 1605: 0X0SECURITY\ralph (SidTypeUser) SMB 192.168.20.10 445 DC 1606: 0X0SECURITY\emma (SidTypeUser) SMB 192.168.20.10 445 DC 1607: 0X0SECURITY\mark (SidTypeUser) SMB 192.168.20.10 445 DC 1608: 0X0SECURITY\robert (SidTypeUser)2.3.4
impacket-lookupsid: 枚举用户和组 SID。
连接成功 ⇒ 凭据有效
工具用
mark / $Ul3S@t0x0S3c成功在lsarpc管道建立了 LSA 远程调用会话。这进一步确认
mark账户是真实存在且口令正确——绝不是被映射到 Guest。
拿到了域 SID
S-1-5-21-1203346422-2024322971-1674203895以后做 RID 枚举、Kerberos 离线碰撞、Silver Ticket 伪造时都要用到这串数字。
列出了内置高权限组
512Domain Admins518Schema Admins519Enterprise Admins520Group Policy Creator Owners以及若干受保护的系统组 (
Protected Users,KRBTGT,RODC相关)
说明你对 域策略对象 有读取权限——正常域用户默认就能读取这些对象的信息。
还没看到普通用户
impacket-lookupsid默认只把 0–999 的 RID 强扫一遍(系统/内置账户区)。普通员工账户通常从 RID = 1000 开始递增
>= 1000 域内手工或 DSRM 创建的对象 1605 ralph、1606 emma、1607 mark、1608 robert…
2.3.5 kerbrute userenum: 通过 Kerberos 预认证验证用户名是否存在。

┌──(root㉿kali)-[~/Desktop/APTLabs/kerbrute/dist]
└─# ./kerbrute_linux_amd64 userenum -d 0x0security.local --dc dc.0x0security.local ../../credentials/usernames
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: dev (9cfb81e) - 04/19/25 - Ronnie Flathers @ropnop
2025/04/19 01:33:11 > Using KDC(s):
2025/04/19 01:33:11 > dc.0x0security.local:88
2025/04/19 01:33:17 > [+] VALID USERNAME: mark@0x0security.local
2025/04/19 01:33:18 > [+] VALID USERNAME: robert@0x0security.local
2025/04/19 01:33:23 > [+] VALID USERNAME: Emma@0x0security.local
2025/04/19 01:33:23 > [+] VALID USERNAME: Ralph@0x0security.local
2025/04/19 01:33:23 > Done! Tested 14 usernames (4 valid) in 12.128 seconds交叉验证排错: 当使用某个工具或命令遇到问题无法解决时(可能是命令写错、环境问题、工具 bug),尝试使用功能相似的、基于不同原理或实现方式的工具去完成同一目标。这是一种有效的排错策略,可以帮助区分是自身操作失误还是工具/环境的问题,并能对抗“思维定势”或“马虎”导致的错误。
2.4 Kerbrute 回顾与总结
userenum: 基于 Kerberos 预认证,只验证域用户是否存在,不显示本地用户或 Guest 映射,
结果相对 NXC 的 Guest 更精确,但无法验证密码。passwordspray: 单密码对用户列表进行喷洒,效率低于 NXC,但可作为补充验证。
2.5 Kerberoasting 关键概念回顾 (服务账户 vs 用户账户)
再次强调: Kerberoasting 攻击的核心价值在于找到使用用户账户(密码通常由人设置,可能较弱)运行的服务(其 SPN 已注册)。
下面给出 4 类对象在真实环境中如何“挂 SPN” 的典型案例。每个案例都说明了 账户名、示例 SPN、常见应用场景 与 渗透/防御要点。
案例均为企业常见模式,方便你在演练或红队行动里快速对号入座。
快速实战 Tips
枚举时立刻用正则剔除
\$结尾的帐户:grep -vE '\$' spn_list.txt > crack_targets.txt查
userAccountControl:0x110=WORKSTATION_TRUST_ACCOUNT,0x2080=gMSA。看到就跳过。优先跑 描述含
svc / app / sql / backup / jenkins等关键字且无$的账号——这些往往是人为口令。爆破成功后 先
whoami /priv、net localgroup administrators看本地权限,再看域组;服务账号常本地有高权但域内低权。
这样,你就能把算力和时间集中在真正可能爆破成功且具备横向价值的 SPN 目标上,而不是误陷在机器/托管帐户的“无底洞”里。祝渗透顺利!
服务账户/机器账户: 密码通常由系统管理,极其复杂且定期轮换,即使拿到 TGS 哈希也几乎无法破解。
理解差异的重要性: 避免将精力浪费在破解无法破解的服务/机器账户哈希上。
impacket-GetUserSPNs的命名 (GetUser...) 正体现了这一点。
3. WinRM, Evil-WinRM, PSRemoting 详解
3.1 问题引出:evil-winrm 登录 192.168.20.15 报错分析
现象: 使用
adfs_svc:S3cur!ty凭据通过evil-winrm连接192.168.20.15时,虽然认证成功 (NXC 显示Pwn3d!),
但evil-winrm的 shell 报错,提示命令无法识别 (The expression after '&' in a pipeline was not supported.)。┌──(root㉿kali)-[~/Desktop/APTLabs/kerbrute/dist] └─# evil-winrm -u '0x0security.local\adfs_svc' -p 'S3cur!ty' -i 192.168.20.15 Evil-WinRM shell v3.7 Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion Info: Establishing connection to remote endpoint *Evil-WinRM* PS The term 'Invoke-Expression' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. + CategoryInfo : ObjectNotFound: (Invoke-Expression:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException>
推断: 这表明连接本身建立了,但获得的 Shell 是受限的,无法执行
evil-winrm尝试执行的初始化或标准命令。
3.2 核心概念辨析
理解这几个术语的关系至关重要:
WS-Management (WS-Man): 是一个标准协议,基于 SOAP over HTTP/HTTPS,用于远程管理。它是跨平台的理论基础。
WinRM (Windows Remote Management):是 Windows 系统上的一个服务,
它实现了 WS-Man 协议,负责监听端口(HTTP 5985, HTTPS 5986),处理认证,执行管理任务。
是 PSRemoting 和 Evil-WinRM 的通信基础。PSRemoting (PowerShell Remoting): 是一项技术/功能,构建在 WinRM/WS-Man 之上,允许通过 PowerShell 远程执行命令和脚本。
它是微软合法的远程管理解决方案,功能强大且安全。Evil-WinRM: 是一个第三方渗透测试工具,它利用 WinRM 服务和 WS-Man 协议,提供一个简化的、面向攻击者的交互式 Shell。
它封装了认证和常用操作(如文件上传下载),但本质上还是在调用底层的 WinRM 功能。关系总结: WS-Man (协议) <- WinRM (服务实现) <- PSRemoting (合法技术) / Evil-WinRM (攻击工具)。

3.3 Remoting Shell vs 标准 Shell 对比
对比 PSRemoting/WinRM 获得的 Shell 与常见的反弹 Shell/绑定 Shell:
核心价值: 理解 Remoting 是一种功能完整的、基于标准协议的、合法的(但可被滥用)远程管理方式,与简单的反弹 Shell 在底层机制和能力上有本质区别。
4. Windows远程服务和PSRemoting配置与使用技术的细节
WinRM服务连接受限了?那我们回归这项技术的底层,就是 PowerShell Remoting 技术,非正式的编写或口语表达也叫“PSRemoting”。
PowerShell Remoting 是一项允许从一个 PowerShell 会话连接到另一个远程计算机上的 PowerShell 会话的技术。它使得管理员可以执行命令和脚本,在远程计算机上就像在本地操作一样。
技术原理与命令结构
PowerShell Remoting 主要依赖于 Windows 远程管理(WinRM)服务,
基于标准 WS-Management 协议实现,广泛用于远程软件与硬件管理。
常用命令:
Enter-PSSession:开启一个交互式远程 PowerShell 会话。Invoke-Command:一次性执行命令或脚本,适合批量操作。
PowerShell Remoting 的优势
安全性:使用加密和身份验证机制保护会话内容。
灵活性:可远程访问系统和服务而无需物理接触。
扩展性:支持多个远程计算机并行命令执行。
自动化:与脚本系统集成,支持自动批量运维。
命令使用示例
1. Invoke-Command(远程执行一次性命令)
Invoke-Command -ComputerName RemoteServer -ScriptBlock { Get-Process }2. Enter-PSSession(交互式会话)
Enter-PSSession -ComputerName RemoteServer3. New-PSSession(创建持久远程会话)
$session = New-PSSession -ComputerName RemoteServer4. 使用 Invoke-Command 结合已建立的会话
Invoke-Command -Session $session -ScriptBlock { Get-Service }5. Remove-PSSession(关闭会话)
Remove-PSSession -Session $session6. Enable-PSRemoting(启用本机的 PowerShell Remoting)
Enable-PSRemoting -Force补充说明
在 Windows 主机和 Kali 中,可以通过安装
powershell和gss-ntlmssp实现兼容性:
sudo apt install powershell gss-ntlmssp4.1 跨平台命令 (pwsh vs powershell)
在 Linux/macOS 系统中,启动跨平台 PowerShell Core 的命令是
pwsh。在 Windows 系统中,传统的是
powershell.exe,但也可以安装并使用pwsh.exe。命令参数和语法在
pwsh环境下理论上应与 Windows PowerShell 保持一致。
4.2 主要命令 (Enter-PSSession, Invoke-Command 等)
Invoke-Command -ComputerName <Target> -ScriptBlock { <Command> }: 在远程机器上非交互式地执行命令块。每次执行建立连接、执行、断开。适合批量、一次性任务。nxc winrm -x <command>类似此模式。Enter-PSSession -ComputerName <Target> -Credential <Cred> ...: 建立到远程机器的交互式 PowerShell 会话。是我们尝试复现evil-winrm功能的首选命令。
New-PSSession/Remove-PSSession: 创建和管理持久化的远程会话对象,便于多次调用Invoke-Command。Enable-PSRemoting -Force: 在目标 Windows 上(需管理员权限)启用 WinRM 服务和防火墙规则。
4.3 认证机制 (-Authentication Negotiate)
Negotiate是推荐的认证方式,它会尝试使用 Kerberos 进行认证,如果失败,则自动降级尝试 NTLM。
┌──(root㉿kali)-[/root/Desktop/APTLabs/kerbrute/dist]
└─PS> Enter-PSSession -Computer 192.168.20.15 -Credential 0x0security\adfs_svc -Authentication Negotiate -Verbose
PowerShell credential request
Enter your credentials.
Password for user 0x0security\adfs_svc: ********
Enter-PSSession: This parameter set requires WSMan, and no supported WSMan client library was found. WSMan is either not installed or unavailable for this system.
4.4 时间同步
需要安装wsman,那就安装一下。首先要注意时间同步问题,可以再次通过如下命令确保时间同步。
net time set -S dc.0x0security.local
4.5 Linux/Kali 环境配置 (挑战与现状)
在 Kali Linux 上使用 pwsh 进行 PSRemoting 连接 Windows 面临挑战:
安装
pwsh:sudo apt update && sudo apt install powershell。安装 NTLM 支持库: (通常已默认安装)
sudo apt install gss-ntlmsspgss-ntlmssp: 提供 GSS-API 接口,让 Linux 应用(如pwsh)能使用 NTLM 认证与 Windows 通信,无需加入域。
安装 WS-Man 客户端支持: 这是关键且问题频发的环节。
方法一 (OMI - 系统级): 安装微软的 OMI (Open Management Infrastructure)。
理论上是标准方案,但在 Kali/Debian 上安装配置复杂,且项目似乎更新缓慢,当前不推荐/可能无效。方法二 (PSWSMan - PowerShell 模块级): 在
pwsh中安装模块。# 在 pwsh 中执行 Install-Module -Name PSWSMan -Force Install-WSMan -Force
根据提示重新进入pwsh后查看活动模块中就以及存在PSWSMan了。
这是目前推荐的方式,但存在已知的兼容性 Bug。
当前的 Bug: 即使正确安装了
pwsh和PSWSMan模块,在 Kali 上执行Enter-PSSession或Invoke-Command连接 Windows 时,
仍大概率遇到WSManClientLibraryNotFound或其他连接错误,导致无法建立会话。原因: 微软对跨平台 PowerShell Remoting 的维护和兼容性做得不够好。
应对:
认识到是 Bug: 避免误判为凭据或权限问题。
尝试
evil-winrm: 虽然它也基于 WinRM,但其实现可能不同,有时能成功连接。但如本例所示,也可能遇到 JEA 等限制。切换平台: 最可靠的备选方案是使用 Windows 虚拟机作为攻击机执行 PSRemoting 操作。
4.6 替代方案:Windows 渗透环境
必要性: 由于 Kali -> Windows PSRemoting 的不稳定性,准备一个 Windows 渗透环境(如 Commando VM 或自定义的 Windows VM)是进行深度域渗透,尤其是需要依赖 PowerShell 高级功能时的重要备选项。周二会简单介绍。
5. JEA (Just Enough Administration) 受限 Shell
5.1 引入 JEA (解释 evil-winrm 报错原因)
evil-winrm连接192.168.20.15后报错,无法执行基本命令,
强烈暗示目标 Shell 是一个 JEA (Just Enough Administration) 受限环境。
5.2 JEA 概念与原理 (最小权限)
定义: 微软的一种安全技术,通过 PowerShell Remoting 提供精细化委派管理。
核心思想: 最小权限原则。管理员可以预定义角色(Role Capabilities),精确指定某个用户或组通过特定 JEA 端点连接时,只能执行哪些 PowerShell Cmdlet、函数、外部程序,以及允许使用哪些参数。
5.3 JEA 特点 (虚拟账户, gMSA, 命令限制, 增强日志)
命令限制: 核心功能,限制可执行的命令和参数。
虚拟账户/gMSA: JEA 会话通常在临时的、低权限的虚拟账户下运行,或者使用组托管服务账户 (gMSA),而不是直接使用连接用户的凭据执行命令,增加了安全性。gMSA 的利用是后续的一个攻击点。
增强日志: JEA 会话通常会开启详细的脚本块日志 (Script Block Logging) 和模块日志 (Module Logging),以及会话记录 (Transcripts),使得管理员可以精确审计用户的所有操作。这增加了攻击者的暴露风险。
5.4 JEA 与 Linux Restricted Shell 类比与区别

相似点: 都限制了用户可执行的命令和能访问的环境。
区别: JEA 通常更复杂、配置更灵活(基于 PowerShell Role Capabilities 文件),与 AD 集成更紧密(虚拟账户、gMSA),且日志记录通常更强。
6. JEA 受限 Shell 绕过思路 (通用策略)
面对 JEA 环境,需要采用特定的绕过思路,与绕过 Linux rbash 等受限 Shell 有共通之处,但更侧重 PowerShell 的特性:
6.1 枚举并分析可用命令
首要步骤: 必须弄清在这个受限环境中到底能用什么命令。
尝试
Get-Command(可能被禁用)。尝试
Get-PSSessionCapability(如果 JEA 配置允许)。观察
evil-winrm或其他连接工具的初始化报错,可能会泄露一些尝试执行但失败的命令。
分析: 对允许的命令,仔细研究其功能和参数,寻找是否存在可以被滥用来读写文件、执行代码、加载模块、修改配置或与其他系统交互的“意外”用法。
6.2 诱导程序报错收集信息
故意提供错误参数、超长输入、特殊字符等,观察详细的错误信息。
错误信息可能泄露:内部路径、对象类型、权限上下文、依赖关系等,为进一步探测提供线索。
6.3 关注自定义命令与潜在 Bug
JEA 配置通常包含管理员自定义的函数或脚本 (
.ps1)。这些自定义代码是重点关注对象,因为它们更容易存在逻辑漏洞、参数注入、权限配置不当等问题,相比系统自带 Cmdlet 更易被绕过。
6.4 对抗性思维与接受失败可能
JEA 设计上就是为了限制,绕过并非必然成功。
保持尝试,但也要认识到可能需要转换思路(如横向移动到其他非 JEA 限制的主机)。
6.5 挖掘配置文件与环境变量
如果能通过允许的文件操作命令读取 JEA 的角色配置文件 (
.psrc) 或会话配置文件 (.pssc),可以分析其具体限制和潜在弱点。检查环境变量 (
$env:PATH,$env:PSModulePath等) 是否包含可写路径,或是否泄露敏感信息。
6.6 利用允许的外部命令
检查是否允许执行非 PowerShell 命令(如
cmd.exe,whoami.exe,net.exe,mshta.exe等)。如果允许,可能直接绕过 PowerShell 的限制。
7. 总结与展望
7.1 推荐资料 (Secrets of PowerShell Remoting)
推荐深入研究 "Secrets of PowerShell Remoting" 这本书(或类似资源),以透彻理解 Remoting 技术底层,但注意其内容可能较为艰涩。
7.2 后续内容预告 (NXC, Evil-WinRM 细节, JEA 绕过实操, 备选 Windows 环境)
下周二: 深入 NXC/NetExec 功能细节。
下周六: 实操 PS Remoting 连接尝试(可能切换到 Windows 环境),并进行 JEA 绕过。
之后: ADFS 攻击专题。
贯穿: Evil-WinRM 的高级用法将在后续实战中持续讲解。
补充: 介绍备选的 Windows 渗透测试环境。
-.-
评论区