Vulnerability

Certighost (CVE-2026-54121): AD CS chase fallback을 이용한 도메인 가장

AD CS 인증서 등록 chase fallback 취약점으로 인해 저권한 사용자가 테스트된 AD CS 구성에서 도메인 컨트롤러를 가장해 완전한 도메인 전복이 가능한 보안 취약점(CVE-2026-54121)과 공격 경로, 공개 PoC 분석, 패치 및 탐지 방향을 기술한 전문 문서입니다.

Certighost (CVE-2026-54121): AD CS chase fallback을 이용한 도메인 가장

핵심 요약

Certighost(CVE-2026-54121)는 Microsoft Active Directory Certificate Services (AD CS) 의 취약점입니다. 이 결함을 통해 저권한 도메인 사용자가 테스트된 AD CS 구성에서 도메인 컨트롤러를 가장해 도메인을 완전히 전복할 수 있었습니다. 이번 글에서는 chase fallback이라는 AD CS 내부 메커니즘이 어떻게 신뢰 경계를 넘어서는지, 공개된 Proof of Concept (PoC) 가 무엇을 하는지, 그리고 패치와 탐지 방향을 기술합니다.

핵심 메시지 세 가지: |1. attacker가 임의 호스트를 chase target 으로 지정하면 CA 가 검증 없이 해당 호스트의 directory 응답을 신뢰해 주었습니다. 2. 2026년 7월 보안 업데이트에서 chase 진행 전 DC 검증 체크가 추가되어 공격 경로가 차단되었습니다. 3. 우선 적용할 수 있는 핫픽스 구성이 있지만, 이는 임시 조치이며 반드시 테스트 후 운영 환경에 도입해야 합니다.


취약점 정보

항목 내용
CVE 번호 CVE-2026-54121
공식 명칭 Certighost
취약점 유형 AD CS certificate enrollment chase fallback 신뢰 부재 (권한 상승 / 인증 우회)
영향 범위 테스트된 AD CS 구성에서 확인됨. 모든 AD CS 환경에 반드시 적용되는 것은 아님.
보고 및 패치 2026년 5월 MSR 보고 → 2026년 7월 14일 보안 업데이트 배포
연구자 @h0j3n, @aniqfakhrul (공개 발표: 2026년 7월 24일)

테스트 환경과 공격 전제조건

연구자가 취약점 확인을 위해 사용한 AD CS 구축 환경은 다음과 같습니다. 이 구성과 다르면 동작 가능성이 달라질 수 있으므로, 본 기술이 모든 조직의 AD CS에서 반드시 재현되는 것은 아닙니다.

항목
도메인 기능 수준 Windows Server 2016 이상
도메인명 ABC.LOCAL
Domain Controller WDC01.abc.local (192.168.8.128)
Enterprise CA abc-WCA01-CA on WCA01.abc.local (192.168.8.129)
ms-DS-MachineAccountQuota 기본값 10
인증서 템플릿 기본 Machine 템플릿 + 기본 ACL
공격자 호스트 IP 192.168.8.134
공격자 계정 일반 도메인 사용자 normaluser (저권한 Domain Users 권한)

공격 전제 조건 세 가지:

  1. 저권한 도메인 사용자로 AD CS 인증서 등록이 가능한 인증서 템플릿 접근 권한 보유 (ms-DS-MachineAccountQuota >= 0)
  2. 네트워크상 CA 및 DC에 접근 가능
  3. 루트 권한으로 rogue 서비스 구동 (포트 389/445 필요)

AD CS 인증서 등록과 chase fallback

AD CS 는 X.509 인증서를 issuance 하는 Microsoft 의 PKI 구현체입니다. LDAP/Kerberos 로 통합되어 있으며, 도메인 호스트의 식별을 위한 수단으로도 사용됩니다.

인증서 기반 클라이언트 인증 흐름은 간단합니다:

  1. 클라이언트가 Enterprise CA 에 템플릿에 기초해 certificate request 제출
  2. CA 가 요청을 검사하고 유효하면 서명된 인증서를 발급
  3. 클라이언트는 해당 인증서를 KDC 에 제시하여 Kerberos credential 획득

이 과정에서 중요한 역할을 하는 것이 chase fallback입니다. chase 는 다중 도메인 컨트롤러가 있는 환경에서 CA 가 directory-object resolution 을 위해 수행하는 두 번째 directory 조회 작업입니다. Chase 동작은 요청자가 지정할 수 있는 두 속성에 의해 영향을 받습니다:

  • cdc (Client DC): CA 가 연락해야 할 호스트를 지정합니다.
  • rmd (Remote Domain): CA 가 조회할 principal 대상 (주로 도메인 컨트롤러 DNS 이름) 을 지정합니다.

두 속성이 동시 요청되면, CA 는 cdc 로 지정한 호스트에 SMB 와 LDAP 연결을 연 후 rmd 에 담긴 principal 탐색을 수행합니다. 정상적으로 동작할 때 chase 를 거쳐 추가 identity 정보를 획득하는 것은 의미 있으나, 이 메커니즘 설계에는 명백한 신뢰 간격이 있었습니다.


cdc 와 rmd 가 만드는 신뢰 경계 문제

Vulnerable AD CS (패치 전) 의 핵심 문제는 CA 가 요청자가 공급한 chase target(cdc 로 지정한 호스트) 이 실제로 도메인 컨트롤러 인지를 검증하지 않고 해당 호스트의 응답을 directory data 로 사용했다는 것입니다.

공격자는 다음과 같은 방법으로 이를 악용했습니다:

  1. 저권한 계정으로 machine account 를 생성 (기본 ms-DS-MachineAccountQuota 값 덕분에 가능) |2. 생성된 계정으로 실제 DC 의 Netlogon 을 통해 authentication challenge 검증 (정당한 도메인 principal 인증)
  2. Rogue LDAP/SMB 서비스를 포트 389/445 에서 구동하고 chase endpoint 준비
  3. certificate request 시 자신에게 연결하도록 cdc 속성 지정 + 타겟 DC 이름을 rmd 로 전달 |5. CA 가 attacker 호스트에 LDAP chase 요청 → Rogue endpoint 가 실제 DC 의 objectSid, dNSHostName 등을 응답
  4. CA 는 해당 identity material 을 신뢰하고 인증서 issuance

취약점의 본질: Attacker-controlled chase endpoint 가 정당한 도메인 principal 인증을 통과할 수 있었던 이유는, 공격자가 ms-DS-MachineAccountQuota 를 이용해 생성한 machine account 가 AD 내에서 legitimate principal 로 인정받았기 때문입니다. CA 는 그 authentication 을 신뢰하고 directory response 자체를 검증하지 않았습니다.


Certighost 공격 흐름

연구자의 테스트 및 공개 PoC 분석에 따르면, 다음 순서로 attacker 가 수행합니다:

  1. Infrastructure 탐색 — 저권한 계정으로 LDAP 접속 → CA 의 cn/dnsHostName 발견, DC sAMAccountName/objectSid/domain GUID 조회
  2. Machine Account 생성 — LDAP/ SAMR 를 통해 새 computer account (예: GHOSTABCDEFGH$) 생성 및 SPN 등록
  3. Rogue 서비스 구동 — port 445(LSA/SMB) 및 port 389(LDAP) 리스너 시작. 이 과정에서 LSASrv 가 LsarOpenPolicy, LsarQueryInformationPolicy 등의 RPC method 핸들링, NTLM challenge 생성 등을 수행
  4. Certificate Request 제출 — 생성된 계정으로 CA 에 PKCS#7 enrollment 요청. cdc(공격자가 제어하는 IP) 및 rmd (대상 DC DNS 이름) 속성 포함 — certighost.py L739-741 에서 attrs 배열 구성, L720-CertServerRequest RPC call
  5. CA Chase → DCIdentity 반환 — CA 가 Rogue LDAP/SMB 로 chase 요청. 공격자가 제어하는 endpoint 가 DC 의 identity (objectSid, dNSHostName 등) 을 응답. CA 는 이를 그대로 cert 에 인코딩
  6. PKINIT 수행 — 발급된 certificate 기반 Kerberos pre-authentication (AS_REQ/AS_REP flow). .pfx 파일로 저장된 private key+certificate 사용

결과적으로 공격자는 대상 DC 의 identity 로 인증할 수 있는 CA 서명 인증서 및 Kerberos credential cache (.ccache) 를 획득하게 됩니다.


공개 PoC 구성과 동작

연구자가 발표한 PoC(certighost.py, 총 986 행) 는 단일 Python 스크립트로, 다음 외부 라이브러리에 의존합니다: impacket, cryptography, pyasn1, asn1crypto, pycryptodome, dnspython.

PoC 가 수행하는 동작 (README 문서화 기반과 코드 직접 검증 동시 확인됨):

E1: LDAP/Kerberos/SAMR 통신 (certighost.py L357-483, L222-269)

  • RogueLDAP 클래스가 LDAP SASL bind (GSS-SPNEGO → NTLM) 및 search 응답 구현
  • NLOracle 클래스 (L222) 가 real DC 의 Netlogon(LSA RPC/NetrLogonSamLogonWithFlags, L251) 검증 절차 구현하여 authentication challenge relay

E2: 머신 계정 생성 (certighost.py L782-829)

  • LDAP(LDAPS) 혹은 SAMR RPC 경로로 AD 에 computer account 등록
  • --computer-name 인자 전달 시 기존 계정 재사용 가능 (README 문서화)

E3: Rogue 서비스 구동 (certighost.py L291-344, L476-482)

  • LSASrv 클래스(L291) 가 DCERPC pipe(\PIPE\lsarpc) 핸들링, NTLM challenge 생성
  • SMBServer 로 포트 445 리스너 시작
  • RogueLDAP.serve() 가 포트 389 에서 LDAP 프로토콜 처리

E4: cdc/rmd 포함 certificate 요청 (certighost.py L730-779)

  • RSA 2048-bit 키 + X.509 CSR 생성 (L732-738)
  • ATTRS 에 CertificateTemplate, SAN:dns=, cdc:{ip}, rmd:{dc_name} 삽입 (L739-741)
  • CA RPC pipe (ncacn_np:{ca_ip}[\pipe\cert]) 를 통해 CertServerRequest 전송

E5: .pfx 및 .ccache 생성 (certighost.py L732-779, L966-967, L656-658)

  • CA 의 응답DER 인증서를 pkcs12.serialize_key_and_certificates 로 PKCS12 직렬화 (L778), 현재 디렉토리에 {target_name}.pfx 로 저장 (L966-967)
  • Kerberos TGT 캐시: 임팩트 라이브러리 DC 에 AS_REQ/AS_REP flow 수행 후 CCache.getData()Path(ccname).write_bytes() 방식으로 작성 (L656-658)

E6: PKINIT 및 credential 추출 (certighost.py L632-712)

  • DirtyDH(Diffie-Hellman key exchange) 구조체(L576) 로 PKINIT DH flow 구현
  • AS_REP 복호화 후 session key 획득, CCache 저장 (L646-658)
  • U2U TGS_REQ flow 를 통한 PAC 의 NT hash 추출 (L660-712)

PoC 목적 외 동작 정적 검토

인증된 감사 보고서(수정 포함, 최종 판정 PASS) 에 따르면 PoC 는 설계 목적의 AD CS chase exploit 재현 외 추가 동작이 없는 것으로 확인되었습니다. 주요 검사 항목은 다음과 같습니다:

U1-U6 모두 NO FINDING (목적 외 동작 없음):

U# 검사 항목 결과 근거
U1 외부 IP/도메인 전송, requests/httpx 등 네트워크 HTTP 라이브러리 사용 없음 모든 socket connect 는 dc_ip 입력 인자 또는 로컬(0.0.0.0/127.0.0.1) 기반. PoC L176-178(detect_ip), L893(dns_resolve) 확인.
U2 외부 URL/payload 다운로드 (HTTP/DNS TXT/wget) 없음 requests, urllib import 및 함수 호출 없음.
U3 subprocess/os.system/eval/exec 실행 없음 os 모듈에서 urandom 전용으로 사용. L6(L73) — compute_nthash 는 legitimate MD4 NTLM hash 계산을 위해 사용됨.
U4 registry/cron/service 지속성 mechanism 작성 없음 winreg, _winreg 등 Windows registry 관련 import 없음. 생성 파일 오직 pfx/ccache 두 개.
U5 파일 삭제 또는 시스템 파괴 없음 os.remove/unlink 패턴 없음. write_bytes 는 신규 파일 기록 전용.
U6 base64 인코딩 blob 통한 동적 코드 실행, 난독화 payload, hidden shellcode 없음 base64 import 없음. Cryptodome ARC4/MD4 는 NTLM/Kerberos 프로토콜 불가결한 legitimate 암호학 사용. ASN1/CMS 구조체는 PKINIT/X509 표준 인코딩용.

보완 검토 — _patch_smb() (L272-288): PoC 의 _patch_smb() 함수는 impacket.smbserver.SimpleSMBServer 클래스에 호환성 메서드(setComputerAccount, getServer) 를 추가하는 monkey-patch 입니다. 외부 통신 또는 악의적 동작과 무관하며, 일부 impacket 버전에서 API 변경으로 인한 호환성 보정을 위한 것입니다.


패치 전후 검증 흐름

Microsoft 는 2026년 7월 업데이트를 통해 CA 측 chase fallback 의 신뢰 경계를 강화했습니다. 연구자가 역어셈블로 확인한 July patched build 의 핵심 체크는 다음과 같습니다 (연구자 Gist L159-313 — 바이너리 분석 결과이며 Python PoC 에 구현되지 않음):

July 업데이트에서의 검증 조건 (총 6단계):

단계 동작 목적
Step 0 Feature_3185813818 gate 체크 (L201-203) 패치된 기능 활성화 여부. 비활성화 시 기존 동작으로 backward compat
Step 1 cdc 값 empty or leading-backslash-strip and reject empty input 악의적 공백 입력 차단
Step 2 hostname 길이 0x104(260자) 초과 검사 → 거부 버퍼 오버플로우 방지
Step 3 RtlIpv4StringToAddressW / RtlIpv6StringToAddressW 로 IPv4/IPv6 literal 차단 직접 IP 주소 chase 방어
Step 4 LDAP injection metacharacter ((, ), *, [, \, ]) 필터링 LDAP 필터 분출 방지
Step 5 DC 조회: (&(objectCategory=computer)(dNSHostName=<target>)(userAccountControl:1.2.840.113556.1.4.803:=8192)) — 정확히 1개 일치 결과 요구, 결과 없음 시 base DN 재조회 시도 핵심 체크: cdc 가 실제 DC computer object 인지 AD 에서 확인
Step 6 resolved SID 비교 추가 (L239-240) chase 후 반환된 objectSid 와 예상 identity 비교 — object substitution 방어

패치 전과 후의 변경 요약:

사항 패치 이전 패치 이후
Chase 대상 요청자가 지정한 임의 호스트로 무조건 연결 AD 로부터 DC computer object 여부 검증 후에만 chase 진행
Principal lookup 원격 응답을 authoritative 데이터로 사용 실제 DC 객체가 정확히 1개 일치해야 다음 단계로 진행
Certificate identity 공격자 제어 가능 validation 및 SID 비교를 통과한 경우에만 issuance
실패 시 처리 명시적 거부 없이 continue 가능 verification 실패 시 error path 분기

보안 대책

** 최우선 조치: Microsoft 패치 적용**

2026년 7월 기준 AD CS Enterprise CA 가 설치된 모든 서버에 최신 보안 업데이트를 즉각 적용하십시오. MSRC(CVE-2026-54121) 에서 확인 가능한 지침을 따르시면 됩니다.

패치 적용 전 임시 조치 (mitigation)

Chase fallback 을 완전히 비활성화하면 이 취약점을 통한 exploit 이 불가능해집니다:

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

이 구성은 EDITF_ENABLECHASECLIENTDC 플래그를 제거하여 chase fallback 을 차단합니다. 중요: 이 조치는 완화책이지 패치가 아닙니다.

  • 반드시 스타ging CA 에서 먼저 테스트 — legitimate enrollment 요청 중 chase fallback 에 의존하는 것이 있을 경우 해당 인증서 등록에 실패할 수 있습니다.
  • 그룹 정책이나 이미지 배포를 통해 EDITF_ENABLECHASECLIENTDC 가 다시 활성화되면 취약점이 재발 가능함
  • 운영 환경 도입 전 반드시 테스트 환경에서 무결성 검증이 필요합니다.

권장 사항: 패치 적용을 최우선으로 하고, mitigation 은 짧은 기간만 유예 조치로 사용하십시오.


탐지 및 사후 점검 방향

AD CS 인프라의 정상적인 chase 동작 패턴과 비정상적인 시도를 구분하기 위해 다음과 같은 지표를 모니터링하십시오:

CA 이벤트 로그 (Event ID): CA 의 인증서 발급 관련 이벤트 로그에서 다음 사항을 확인합니다:

  • 평소 보기 어려운 DC identity 로 issuance 된 certificate 발생
  • 비정상적으로 많은 chase fallback 으로 인한 발급
  • 동일 source IP 에서 다수의 certificate request

네트워크 감시 지표:

  • enterprise CA 로부터 나가는 의심스러운 LDAP/SMB chasing traffic (의외 호스트로 연결)
  • 일반 도메인 사용자가 LDAP/SMB 에 의해 rogue 서버와 통신 시도하는 패턴 (port 389/445 listener 모니터링)

도메인 컨트롤러 이상 동작:

  • DC computer object 가 아닌 호스트가 Chase endpoint 로 응답하는 경우 — 정상 DC 와 같은 objectSid/dNSHostName 을 보유해야 하므로, 생성된 machine account 의 존재 자체를 확인 가능
  • 비정상적인 새 computer account 등록 (GHOST접두어 패턴 등)

정기 검증:

  • 기존 AD CS template 중 Machine 템플릿이나 CDC/RMD 특성을 활용할 수 있는 custom 템플릿의 접근 제어 목록(ACL) 정기 검토
  • ms-DS-MachineAccountQuota 가 기본값 10 보다 큰 경우 — attacker 가 여러 machine account 를 생성할 수 있음. 필요 시 값 제한 고려
  • CA 서버에서 rogue listening 포트 (389/445) 발견 여부 주기적 점검

결론

Certighost(CVE-2026-54121) 는 AD CS 의 chase fallback 메커니즘이 설계상 가진 신뢰 간격을 통해 저권한 사용자가 DC 를 가장할 수 있도록 한 취약점입니다. 연구자가 확인한 바, 테스트된 AD CS 구성에서 attacker 는 machine account 생성 → Rogue LDAP/SMB 서비스 구동 → chase target 조작 → CA 서명 DC 인증서 획득 → Kerberos credential 캐시 기록의 flow 로 도메인 전복이 가능합니다.

2026년 7월 Microsoft 패치가 cdc 검증 체크를 추가하여 이 공격 경로를 차단합니다. 그러나 패치 적용 전까지 AD CS 인프라 운영자는 테스트 환경에서 먼저 구성 변경의 무결성을 확인한 후 완화책을 적용해야 합니다. 또한 사후에는 정상/비정상 chase 동작을 구분할 수 있는 모니터링 체계를 갖출 필요가 있습니다.


참고자료

본 기술 문서는 공개된 PoC 의 코드를 실행하거나 역이용하는 방법을 포함하지 않습니다. 방제와 탐지 위주로 작성되었습니다.


댓글 남기기
댓글목록 0

아직 작성된 댓글이 없습니다.

첫 번째 댓글의 주인공이 되어보세요!