设为首页收藏本站
开启辅助访问 切换到窄版

安全矩阵

 找回密码
 立即注册
搜索
安全矩阵»安全矩阵 › 安全矩阵实验室 › 技术转载 › 关于ADCS的一些利用方式
返回列表 发新帖
查看: 4312|回复: 0

关于ADCS的一些利用方式

[复制链接]
Delina

855

主题

862

帖子

2940

积分

金牌会员

Rank: 6Rank: 6

积分
2940
发表于 2021-9-16 21:21:07 | 显示全部楼层 |阅读模式
原文链接：关于ADCS的一些利用方式
​
NO.1 前言
通过ADCS相关利用方式的学习分析，体现相关应用服务的重要性，以便于及时对相关问题点进行整改
公开资料Certified Pre-Owned: Abusing Active Directory Certificate Services出自于black hat2021
https://www.blackhat.com/us-21/briefings/schedule/# certified-pre-owned-abusing-active-directory-certificate-services-23168
https://www.specterops.io/assets ... ified_Pre-Owned.pdf
强烈建议看下文前先看下英文素材，可以避免很多坑点
网络上关于ADCS利用各类的学习文档资源其实也有好些了，不过更多看都是针对RELAY部分，其他几个利用方式都没怎么提及特别多，可能确实实用程度没有那么高，断断续续几个白天晚上终于给整的差不太多了
NO.2 环境介绍&部分理论知识
更多的理论知识官方文档、搜索引擎查的更全更详细
PKI（Public Key Infrastructure公钥基础设施）
软件、加密技术、流程和服务的组合，使得组织能够保护其数据、通信、业务交易，PKI依赖于经过身份验证的用户和受信任资源之间的数字证书交换，可以用证书来保护数据并管理来自组织内外的用户和计算机身份凭证
ADCS
一个服务器角色，提供PKI功能，支持windows域上身份和其他安全功能如文件加密、邮件加密等，可以为组织内部使用创建、验证、撤销公钥证书
通俗来说ADCS角色是实施PKI解决方案，ADCS允许构建公钥基础设置并为组织提供公钥加密、数字证书、数字签名的功能
ADCS提供所有与PKI相关的组件作为角色服务，每个角色负责证书基础架构的特定部分，同时协同完成完整解决方案
认证机构
CA的主要目的是办法证书、撤销证书及发布授权信息方式和撤销信息，部署的第一个CA将成为PKI的根，随后可以部署位于PKI层次结构中的从属CA，根CA位于顶部，从属CA隐式信任根CA，并信任他颁布的cert
证书颁发机构web注册
使得用户使用未加入域或运行windows以外的设备下进行证书颁发续订的操作
Onlie responder
配置管理在线证书状态协议OCSP验证和吊销检查，在线响应程序解码特定证书的吊销状态请求，评估这些证书的状态，并返回具有请求的证书状态信息的签名响应
网络设备注册服务（NDES）
通过该组件，路由器交换器或其他设备可以从adcs获取证书
证书注册web服务（CES）
用于运行windows的计算机和ca之间的代理客户端，ces使用户、计算机或者应用程序能够通过使用户web服务连接到ca
证书注册策略web服务
使得用户能够获取证书注册策略信息，结合CES，可以在用户设备未加入域或无法连接域控的情况下基于策略的证书注册
补充
​

NO.3 环境搭建
基本功能
功能安装处如下选择：
证书颁发机构
证书颁发机构web注册
证书注册web服务
​

​
配置服务
​

​

如下选择进行服务的细节配置
​

​

​

​

​

​

​

​
​

​

​

配置证书注册web服务
上一步完成会告诉你是否要配置其他角色服务
​
依次如下配置即可
​
​
​

​

​

​
​
搭建完效果如下
​
辅助域控搭建
这里是把adcs搭成了辅助域控
​

​

配置如下
​

主从复制
​
至此，环境基本是搭建的差不多了，一步步直接操作没啥太大难度，按照提示完成相关的操作即可
​
NO.4 证书颁发机构信息获取
certutil
域内成员可成功定位到ca
​

​

powershell

  1. 获得ca名称
  2. (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration").Active
  3. 更多细节信息
  4. $CAName = (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration").Active;
  5. Get-Itemproperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$CAName”
复制代码



测试联通性
确认NTLM协议（后面中继要用）
curl http://192.168.3.73/certsrv -I
​
补充
基本结构情况
​
Certificate Templates：存储所有证书模板的配置。证书模板基本上是证书请求，但是，并非此容器中的所有证书模板都必须可用于注册
Enrollment Services：存储可用于证书注册的CA。Windows 主机使用此容器自动查找可以向其颁发证书的 CA。此容器中的相应 CA 对象具有称为“证书模板”的成员属性。此属性包含可用于在此 CA 上注册的所有证书模板的列表。这通常只是所有现有模板的一个子集
NtAuthCertificates：存储允许颁发智能卡登录证书的 CA。如果尝试使用不在此列表中的 CA 颁发的智能卡证书登录，身份验证将失败。每个企业CA都会自动添加到此处
​​
NO.5 ESC1-配置错误的证书模板
断断续续，过程中其实坑点比较多，环境就给搞了好久....ESC1在部署的另外一套环境测试，也是同样的上方部署方式即可
获取方式
我们可以在证书服务请求中指定主体名称，则请求者可以请求任何人（域管）的证书
配置问题
进入证书模板配置
​
如下进行配置（存在客户端身份验证就行）
​
允许注册
​

如下配置在请求中提供
​
如此将允许低权限用户使用任意SAN请求证书，从而允许低权限用户通过kerberos或schannel作为域中任何主体进行身份验证，白话文就是实现伪造身份
若允许这些设置的已发布证书模板，攻击者可以作为环境中的任何人请求证书，使用该证书为用户获取TGT
漏洞检测

  1. 使用公开的工具即可
  2. 域机器运行后如下，显示存在ESC1漏洞

  4. CA                      : yangdc.yangsir.git\yangsir-YANGDC-CA
  5. Name                    : 用户 的副本
  6. SchemaVersion           : 2
  7. OID                     : 1.3.6.1.4.1.311.21.8.10154165.557338.9848748.4027908.13133259.250.6500742.4833607
  8. VulnerableTemplateACL   : False
  9. LowPrivCanEnroll        : True
  10. EnrolleeSuppliesSubject : True
  11. EnhancedKeyUsage        : 客户端身份验证 (1.3.6.1.5.5.7.3.2)|安全电子邮件 (1.3.6.1.5.5.7.3.4)|加密文件系统 (1.3.6.1.4.1.311.10.3.4)
  12. HasAuthenticationEku    : True
  13. HasDangerousEku         : False
  14. EnrollmentAgentTemplate : False
  15. CAManagerApproval       : False
  16. IssuanceRequirements    : [Issuance Requirements]
  17.                             Authorized signature count: 0
  18.                             Reenrollment requires: same criteria as for enrollment.
  19. ValidityPeriod          : 1 years
  20. RenewalPeriod           : 6 weeks
  21. Owner                   : YANGSIR\Administrator
  22. DACL                    : NT AUTHORITY\Authenticated Users (Allow) - Read, Enroll
  23.                           YANGSIR\Administrator (Allow) - Read, Write
  24.                           YANGSIR\Domain Admins (Allow) - Read, Write, Enroll
  25.                           YANGSIR\Domain Users (Allow) - Enroll
  26.                           YANGSIR\Enterprise Admins (Allow) - Read, Write, Enroll
  27. Misconfigurations       : ESC1
复制代码


​

通过普通域用户申请证书，注意UPN需要为域管
​

​
确认申请成功如下，为administrator权限
​
确认使用者信息如下
​

导出证书
​

此处通过凭证进行PTT出现失败，这里也卡了好久，因为这个环境换的环境，先前还给工具作者提了issue，后推测可能是时间同步的问题
​
对机器重启后，再次PTT即可成功，使用先前导出的凭证
​
确认凭证信息如下
​

确认可成功获取权限
​

NO.6 ESC2-配置错误的证书模板
我们可以使用带有任何目的的EKU功能证书，进行客户端、服务端的身份验证，也可以使用无EKUs的证书来进行任何目的，或签署新的证书
因此使用从属CA证书，攻击者能够指定新证书中的任意EKUs或字段
配置问题
1、允许低权限用户注册，和ESC1相同
2、管理员审批禁用，和ESC1相同
3、不需要授权的前面，和ESC1相同
4、过于宽松的证书模板授权低权限用户注册
5、证书模板定义了任何的EKUS或无EKU
基本大体都是和ESC1一样的，部分区别如下
​

检测情况
公开工具能够检测确认漏洞存在如下
​

同ESC1相同方式申请证书即可
​
确认获得证书如下，具体如何利用请看ESC1
​
​
NO.7 ESC3-注册代理模板
证书请求代理EKU允许委托人代表其他用户申请证书，对于任何注册此模板的用户，生成的证书可用于代表任何用户共同签署部署请求
配置问题
1、允许低权限用户注册，和ESC1相同
2、管理员审批禁用，和ESC1相同
3、不需要授权的前面，和ESC1相同
4、过于宽松的证书模板授权低权限用户注册
5、证书模板定义了证书请求代理EKU，证书请求代理允许代表其他主题请求其他证书目标
6、没有在CA上实现登记代理限制
基本同ESC1相似，不同点在于证书申请代理处
检测情况
可检测ESC3存在如下
​

  1. 代理注册流程的官方文档：https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/97f47d4c-2901-41fa-9616-96b94e1b5435

  3. 最直接申请administrator证书
复制代码
​
NO.8 ESC4-证书模板访问控制
证书模板是 Active Directory 中的安全对象，这意味着它们具有安全描述符，用于指定哪些 Active Directory 主体对模板具有特定权限。如果允许意外或非特权的委托人编辑安全设置，则模板将被视为访问控制级别上的配置问题，攻击者具备写入、完全控制权限，能够将错误的配置推到模板，比如直接把模板设置为ECS1-3
检测情况
公开工具能够检测并确认漏洞存在如下
​

概念验证，详情可通过该工具实现
https://github.com/cfalta/PoshADCS
仔细拜读后，感觉基于github的这个demo利用来说感觉价值不高....利用难度有些大....
​

NO.9 ECS5-PKI访问控制
证书模板和证书颁发机构本身之外的许多对象可能会对整个ADCS系统产生安全影响，如果控制如下一个将影响整个PKI
包括但不限于：
CA服务器的AD计算机对象（即通过 RBCD 攻陷）
CA服务器的RPC/DCOM服务器
PKI相关的AD对象。容器中的任何后代AD对象或容器CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=  （例如，证书模板容器、证书颁发机构容器、NTAuthCertificates 对象等）
检测情况
这个配置范围非常大，琢磨了好久发现检测工具并不能检测到，后来查看了下文档，检测工具没有检测ECS5的能力，基本CA服务器的RPC/DCOM服务器安全性需要手工分析
获取相关控制编辑权限
​

domian users能够对相关模板重新编辑，从而影响发布的证书服务应用
​

​​
NO.10 ESC6-EDITF_
ATTRIBUTESUBJECTALTNAME2
如果在证书颁发机构的配置中启用了EDITF_ATTRIBUTESUBJECTALTNAME2标志，则任何证书请求都可以指定任意主题备用名称 (SAN)。这意味着为域身份验证配置的任何模板也允许非特权用户注册（例如，默认用户模板）可能会被滥用以获取允许我们作为域管理员（或任何其他活动用户/机器）进行身份验证的证书
检测情况
公开工具能够检测并确认漏洞存在如下
​

​

  1. 修复的话对应关闭EDITF_ATTRIBUTESUBJECTALTNAME2即可
  2. certutil –setreg policy\EditFlags –EDITF_ATTRIBUTESUBJECTALTNAME2

  4. 进步利用直接看这个就行了
  5. https://www.keyfactor.com/blog/hidden-dangers-certificate-subject-alternative-names-sans/
  6. 其他参考
  7. https://cqureacademy.com/blog/enhanced-key-usage
  8. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786426(v=ws.11)# controlling-user-added-subject-alternative-names
复制代码

NO.11 ESC7-证书颁发机构访问控制除了证书模板外，证书颁发机构本身剧本一组保护各类CA操作的权限，如下两种权限最为危险
ManageCA：ca admin，允许管理CA操作，包括(远程)配置ESC6-EDITF_ATTRIBUTESUBJECTALTNAME2，将直接导致ESC6
ManageCertificates：cert admin，允许主体批准悬而未决的证书请求，从而否定manager颁发的保护要求
配置问题
证书颁发机构配置相关权限
​

检测情况
​
NO.12 ESC8
获取方式
这部分应该互联网资源最多了
在ADCS下通过管理员可选择安装的附加服务器角色支持多种基于HTTP的注册方法，如证书注册服务通过安装证书注册web服务，通过安装证书注册策略web服务角色&证书注册策略web协同工作，然而此类http证书的注册接口都非常容易遭受NTLM中继
使用NTLM中继，可以实现冒用目标用户，从而访问这些web页面，并根据用户和机器证书模板请求客户端身份验证码证书
默认情况下，证书注册服务、证书注册策略web服务、网络设备注册服务通过授权http头支持协商身份验证，支持kerberos及NTLM。所以攻击者可以在中继攻击时获得NTLM身份验证虚拟性
默认情况下，不会启用https，但是https本身不能抵抗NTLM中继！！！只有当https&通道绑定相结合的时候，才能保护HTTPS服务免遭NTLM中继，ADCS没有为IIS上的身份验证启用扩展保护，并不能启用通道绑定！！！
​
漏洞利用
ntlmrelayx.py进行监听（后面会拿到凭证证书）
​


PetitPotam强制用户进行身份验证
​

获得凭证证书信息如下
​
传递获取到的证书即可，效果如下
​
凭证已经获取，可以直接拉能够直接获得域内用户hash
​
使用凭证可证明权限如下：
​

​

回复

使用道具 举报

返回列表 发新帖
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|安全矩阵

GMT+8, 2025-4-22 19:19 , Processed in 0.024573 second(s), 18 queries .

Powered by Discuz! X4.0

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表