目 录CONTENT

文章目录

红队行动Live-20241123

Administrator
2025-04-19 / 0 评论 / 0 点赞 / 27 阅读 / 0 字

目录

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) 进行凭据碰撞的结果,强调需要理解其三种主要输出类型:

  1. [+] ... (Guest): 表示认证尝试成功,但用户名字并不在域里,SMB 不返回 STATUS_LOGON_FAILURE,而是把会话降为 Guest。

    • 原因: 目标系统配置允许 Guest 访问,但是用户名在域内不存在,但认证机制仍接受了尝试并映射到 Guest。

    • 系统里有一个安全策略或者叫认证机制就是 authentication 的机制是不存在的,用户他会映射成Guest
      服务器策略:Network access: Sharing and security model for local accounts = Guest only

    • 价值: 对攻击者通常无用,表明该用户名/密码组合不是有效的域凭据。

  2. [-] ... STATUS_LOGON_FAILURE: 表示登录失败。

    • 原因: 用户名可能存在于域中,但密码错误;或者用户名根本不存在。

    • 价值: 这些用户名(如 robert, ralph, emma值得关注,它们是已知的域内账户,只是我们手中没有正确密码。

  3. [+] <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: 直接验证用户名+密码组合。
    image-nscq.png

    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: 0X0SECURITY

    2.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 伪造时都要用到这串数字。

  • 列出了内置高权限组

    • 512 Domain Admins

    • 518 Schema Admins

    • 519 Enterprise Admins

    • 520 Group 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 预认证验证用户名是否存在。
image-kwxp.png

┌──(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常见应用场景渗透/防御要点

  • 案例均为企业常见模式,方便你在演练或红队行动里快速对号入座

类别

典型账户 /
对象

挂载的 SPN(示例)

业务场景

红队关注点

① 计算机帐户
(Machine Account,
结尾有 $)

SQL01$   

MSSQLSvc/SQL01.corp.local:1433HOST/SQL01

SQL Server 按默认设置运行于 Local System;安装程序会把数据库监听端口写入机器帐户 SPN

‑ 密码 120 字符随机 + 30 天自动更换,几乎无法爆破‑ 但 SPN 泄漏的主机名 + 端口 可用于资产发现

DC01$   

ldap/DC01.corp.localldap/DC01GC/DC01.corp.local

域控安装过程中自动写入 LDAP、GC、Kerberos 等 SPN

‑ 拿不到口令,但能快速锁定域控 FQDN‑ Kerberos relay 场景常用来识别“对什么服务进行中继”

② gMSA / MSA
(托管服务帐户,
结尾有 $)

sql_gmsa$

MSSQLSvc/sql-cluster.corp.local:1433

运维选用 gMSA 来跑 AlwaysOn 集群;密码由 DC 自动管理

‑ SPN 哈希 AES256 超长且 30 天轮换 → 放弃爆破‑ 但若发现服务未正确设置 “仅允许 Kerberos”,可尝试 NTLM relay

iisapp01$

HTTP/app.corp.local

Web Farm 使用 MSA 统一账号跑 IIS 应用池

‑ 遇到 Constrained DelegationResource‑Based Constrained Delegation 时,gMSA 常是目标主体

③ 用户帐户用作服务
(Human user = Service)

sqlsvc

MSSQLSvc/finance-db.corp.local:1433

DBA 图省事,直接把域用户 sqlsvc 塞进 Windows 服务 ‑> 口令长年不改

Kerberoast 高价值目标‑ 通常 8–12 位混大小写或带公司缩写,爆破成功率高‑ 如果口令弱且 sqlsvc 属于 sysadmin,可 OS‑CMD RCE → 横向

backup_op

cifs/fileserver01.corp.localsmb/fileserver01

第三方备份软件要求域用户访问所有共享;运维建了 backup_op

✅ Kerberoast + 密码重用‑ 备份账号往往有 全网文件读权限,爆破后即可大范围搜敏感数据

④ “机器模拟”用户
(脚本/批处理专用)

jenkins_build

HTTP/jenkins.corp.local

DevOps 平台 Jenkins 需要访问 GitLab、推 Docker;安全组不想给 Local System,于是建个域用户

✅ 典型弱口令:“Company!2021” 类‑ 口令多写在 credentials.xml、PowerShell 脚本里;拿下 Jenkins = 域内任意代码执行

svc_reports

MSSQLSvc/reporting.corp.localHTTP/reportportal

BI 报表服务器调用远程 SQL;运维不懂 gMSA,就新建 svc_reports

✅ Kerberoast 可行‑ 往往只隶属于 Domain Users,但在报表虚机上有 本地管理员;横向后可 dump 明文口令


快速实战 Tips

  1. 枚举时立刻用正则剔除 \$ 结尾的帐户:

    grep -vE '\$' spn_list.txt > crack_targets.txt
  2. userAccountControl0x110=WORKSTATION_TRUST_ACCOUNT,0x2080=gMSA。看到就跳过。

  3. 优先跑 描述含 svc / app / sql / backup / jenkins 等关键字且无 $ 的账号——这些往往是人为口令。

  4. 爆破成功后whoami /privnet 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 (协议) &lt;- WinRM (服务实现) &lt;- PSRemoting (合法技术) / Evil-WinRM (攻击工具)。

3.3 Remoting Shell vs 标准 Shell 对比

对比 PSRemoting/WinRM 获得的 Shell 与常见的反弹 Shell/绑定 Shell:

特性

PSRemoting/WinRM Shell

标准 Reverse/Bind Shell

协议

WS-Man (HTTP/HTTPS)

TCP/UDP (常见)

方向

客户端 -> 服务器 (通常)

服务器 -> 客户端 (反弹)

认证

强制 (Kerberos/NTLM/本地)

通常无/弱

加密

支持 HTTPS

通常无 (可自行实现)

功能

完整 PowerShell 功能集

有限 (依赖基础 shell)

会话

支持多会话、持久会话

通常单连接

用途

合法管理、横向移动

C2、后门、绕防火墙

权限

通常需较高权限启动/连接

取决于执行进程的权限

端口

5985 (HTTP), 5986 (HTTPS)

任意,常伪装成 80/443

检测/日志

较完善 (Event ID 4648, 7045 等)

依赖流量、异常端口检测

优势

功能全、稳定、合法

隐蔽性 (反向连接)、无需目标配置

劣势

需目标开启服务、权限要求高

功能受限、不稳定、易被检测

特性

PSRemoting

反弹 shell

通信协议

基于 WS-Man 协议和 WinRM(Windows Remote Management)服务,运行在 HTTP(5985)或 HTTPS(5986)端口

基于 TCP/UDP,通常攻击者监听特定端口,目标主机主动向攻击者发起连接

网络方向

管理主机主动连接目标主机,通过域名或 IP 地址实现远程访问

目标主机主动连接攻击者监听端口,通常绕过目标网络的防火墙出站限制

身份验证

需要凭据验证,支持 NTLM、Kerberos 或本地用户凭据验证;支持多因素认证和权限细分

无身份验证机制,连接建立后攻击者立即获得控制权,权限取决于目标主机中反弹 shell 进程的权限

安全性

支持 HTTPS 加密通信,可结合域策略(GPO)和权限控制;默认不开启 PSRemoting

通常为明文,数据可能被探测检测;如果配置不当,可能暴露在 IDS/IPS 或 SIEM 系统下。当然也可以加密

功能范围

提供完整的 PowerShell 功能,支持脚本执行、任务计划、注册表和文件系统管理,适用于远程运维和自动化

提供基本命令行交互,功能受限;取决于 shell 类型(如 cmd.exe、bash 等),需要手动执行额外工具

会话支持

支持长期维持与远程会话(Session);每个会话可单独运行脚本

一般不支持会话,连接断开后需要重新发起目标机连接

适用场景

适用于合法远程管理任务,如批量更新、横向渗透、权限维持执行

常用于渗透测试和非法入侵,适合绕过防火墙限制并初步获取访问权限

权限需求

默认需要目标主机上的管理员权限或显式授权的远程权限

根据反弹 shell 进程权限,攻击者权限可能受到限制(如普通用户或管理员)

配置要求

需要在目标主机上启用 PSRemoting(通过 Enable-PSRemoting),并配置防火墙规则允许 WinRM 流量

目标主机需有能力向外发起 TCP/UDP 连接,无需特殊配置

通信方向

双向通信,管理主机可以实时推送和接收命令执行结果

单向通信,目标主机向攻击者连接后,攻击者控制会话;通信建立后无额外数据安全保障

典型端口

TCP 5985(HTTP)、TCP 5986(HTTPS)

TCP 80、443(常见于绕过防火墙),也可根据攻击者需求自定义

可检测性

可通过事件日志和网络流量监控检测(如 Windows Event ID 4648、7045)

容易被安全设备(IDS/IPS)检测,未加密流量容易被审查追溯回连接发起点

延展性

用于大规模脚本管理和自动化任务,支持域内大批量主机管理

功能有限,多用于单点突破或后续权限维持,需结合其他工具(如 Metasploit、nc 等)

典型用途

合法用途:远程管理、运维、横向移动、权限验证

非法用途:绕过网络防护,获取初步访问,进一步部署后门

限制条件

需要显式启用 PSRemoting,且要求网络访问权限

目标主机主动连接可能受防火墙策略或网络出站限制

典型工具

原生 PowerShell、Invoke-Command、Enter-PSSession

Netcat、Metasploit、nc、Socat 等第三方工具

核心价值: 理解 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 RemoteServer

3. New-PSSession(创建持久远程会话)

$session = New-PSSession -ComputerName RemoteServer

4. 使用 Invoke-Command 结合已建立的会话

Invoke-Command -Session $session -ScriptBlock { Get-Service }

5. Remove-PSSession(关闭会话)

Remove-PSSession -Session $session

6. Enable-PSRemoting(启用本机的 PowerShell Remoting)

Enable-PSRemoting -Force

补充说明

  • 在 Windows 主机和 Kali 中,可以通过安装 powershellgss-ntlmssp 实现兼容性:

sudo apt install powershell gss-ntlmssp

4.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 面临挑战:

  1. 安装 pwsh: sudo apt update && sudo apt install powershell

  2. 安装 NTLM 支持库: (通常已默认安装)

    sudo apt install gss-ntlmssp
    • gss-ntlmssp: 提供 GSS-API 接口,让 Linux 应用(如 pwsh)能使用 NTLM 认证与 Windows 通信,无需加入域。

  3. 安装 WS-Man 客户端支持: 这是关键且问题频发的环节。

    • 方法一 (OMI - 系统级): 安装微软的 OMI (Open Management Infrastructure)。
      理论上是标准方案,但在 Kali/Debian 上安装配置复杂,且项目似乎更新缓慢,当前不推荐/可能无效

    • 方法二 (PSWSMan - PowerShell 模块级):pwsh 中安装模块。

      # 在 pwsh 中执行
      Install-Module -Name PSWSMan -Force
      Install-WSMan -Force



      根据提示重新进入pwsh后查看活动模块中就以及存在PSWSMan了。

      这是目前推荐的方式,但存在已知的兼容性 Bug

  4. 当前的 Bug: 即使正确安装了 pwshPSWSMan 模块,在 Kali 上执行 Enter-PSSessionInvoke-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 渗透测试环境。

-.-

0

评论区