ESC9 대 ESC16: 같은 결함, 다른 영향 범위

ESC9와 ESC16은 Active Directory Certificate Services (AD CS)에 대해 분류된 번호가 매겨진 에스컬레이션 기술(ESC) 중 두 가지이며, 서로 다른 범위에서 동일한 취약점입니다. 두 기술 모두 발급된 인증서에서 보안 식별자(SID) 보안 확장을 제거하여 공격자가 약한 인증서 매핑을 통해 다른 계정을 가장할 수 있게 합니다. ESC9는 단일 인증서 템플릿에서 발생하며, ESC16은 인증 기관(CA)이 발급하는 모든 인증서에 적용됩니다.

몇 년 전에 ESC9를 수정했다면, 그것이 ESC16에 대해 아무것도 알려주지 않습니다.

ESC9란 무엇인가요?

ESC9는 템플릿 설정입니다. 템플릿의 msPKI-Enrollment-Flag 속성에 CT_FLAG_NO_SECURITY_EXTENSION이 설정되면 해당 템플릿에서 발급된 인증서에는 SID 확장(szOID_NTDS_CA_SECURITY_EXT)이 포함되지 않습니다. 이 확장은 도메인 컨트롤러(DC)가 인증서를 특정 계정에 연결할 수 있게 해줍니다. 없으면 DC는 사용자 주체 이름(UPN) 매핑으로 대체합니다.

공격에는 세 가지가 필요합니다: 피해자 계정의 UPN에 쓰기 권한이 있는 공격자(GenericWrite 권한이면 충분), 플래그가 설정된 client-authentication 템플릿에 대한 등록 권한, 그리고 강력한 인증서 매핑을 적용하지 않는 DC. 공격자는 피해자의 UPN을 권한 있는 계정과 일치하도록 변경하고, 등록한 후 UPN을 원래대로 돌려놓고 인증서를 사용해 권한 있는 사용자로 인증합니다.

Oliver Lyak은 2022년 8월 ESC9을 문서화했으며, 많은 스캐너가 이를 탐지할 수 있습니다. 그중에는 Netwrix PingCastle가 포함되어 있습니다. 아래 체크리스트는 자신의 템플릿을 확인하는 방법을 보여줍니다.

ESC16란 무엇인가요?

ESC16는 템플릿을 건드리지 않고 동일한 결과에 도달합니다. szOID_NTDS_CA_SECURITY_EXT SID 보안 확장인 OID 1.3.6.1.4.1.311.25.2가 CA의 DisableExtensionList 정책 모듈 레지스트리 값에 나열되어 있으면 CA는 발급하는 모든 항목에 SID 확장을 추가하지 않습니다. 해당 CA 뒤에 있는 모든 템플릿은 ESC9 플래그가 설정된 것처럼 동작하며, 수년간 검토되지 않은 템플릿도 포함됩니다.

환경이 이 설정을 갖게 되는 데에는 여러 가지 이유가 있을 수 있습니다. 서드파티 도구의 호환성 수정, 마이그레이션, 또는 확장 기능을 처리하지 못하는 레거시 애플리케이션 등입니다. 이는 단일 레지스트리 항목으로 쉽게 간과되며, 템플릿별로 구축한 보호를 조용히 무효화합니다.

이 설정은 템플릿 속성이 아닙니다. 이는 CA 구성이며, 많은 인증서 위생 검토에서 CA 자체 정책 모듈 설정을 열어보지 않습니다. 조직은 모든 템플릿에서 깨끗할 수 있고 이를 증명하는 보고서를 가질 수 있지만 여전히 CA를 통해 노출될 수 있습니다. 수년 전 ESC9를 스캔했고 이후 CA를 확인하지 않았다면 공격자가 ESC16을 통해 동일한 사칭 공격을 수행할 수 있습니다.

강력한 인증서 매핑이 보호해 주나요?

부분적으로 그렇습니다. 두 기술 모두 DC가 약한 매핑을 허용하는 것에 의존하며, 강력한 인증서 바인딩을 적용하는 DC는 둘 다 무력화합니다. 2025년 9월 Windows 업데이트 이후 패치된 DC는 완전한 적용을 실행하며 호환성 모드 설정은 더 이상 지원되지 않으므로 완전히 패치된 도메인은 순수 ESC9 및 ESC16을 차단합니다. 그러나 두 가지 취약점이 남아 있습니다: 해당 업데이트를 놓친 DC와 공격자가 인증서 요청에 자신의 SID를 제공할 수 있는 체인(예: ESC16과 ESC6 또는 ESC15의 조합). 모든 DC에서 적용 상태를 확인하고 CA도 확인하세요.

둘 다 어떻게 확인하고 수정합니까?

두 가지 검사가 필요합니다. ESC9는 템플릿에 있고 ESC16은 CA에 있기 때문입니다.

ESC9(인증서 템플릿) 확인

1. 다음의 스캔을 실행하세요: PingCastle.
2. 보고서를 열고 CT_FLAG_NO_SECURITY_EXTENSION을 검색하세요(위험은 A-CertTempNoSecurity입니다). "최소 하나의 인증서 템플릿에 CT_FLAG_NO_SECURITY_EXTENSION 플래그가 설정되어 있습니다."라는 텍스트를 찾으세요.
3. 해당 텍스트가 없으면 스캔된 템플릿 중 플래그가 있는 것이 없습니다. 텍스트가 있으면 영향을 받은 템플릿에서 플래그를 제거하세요.

ESC16(인증 기관)를 확인하세요

각 CA에서 다음을 실행하세요:

      certutil -getreg policy\DisableExtensionList
      

출력에 OID 1.3.6.1.4.1.311.25.2가 나타나면 해당 CA가 발급하는 모든 항목에서 SID 확장을 제거하는 것입니다. 문서화된 이유가 없다면 목록에서 제거하세요.

문제를 해결하려면 OID를 제거하고 변경 사항이 적용되도록 Certificate Services를 다시 시작하세요:

      certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2
net stop certsvc
net start certsvc
      

이후에 certutil -getreg policy\DisableExtensionList 명령을 다시 실행하여 OID가 사라졌는지 확인하세요. 확장 없이 이미 발급된 인증서는 그대로 유지되므로 설정이 악용되었다고 의심되면 검토하세요. 애플리케이션이 이 설정을 필요로 했다면 널리 배포하기 전에 테스트하세요.

그런 다음 적용을 확인하세요: DC가 강력한 인증서 매핑을 적용하고 있는지 확인하세요. 이는 두 가지 기법 모두를 약화시킵니다. 최신 업데이트가 적용된 DC에서는 기본 설정입니다. CA 노출의 나머지 부분에 대해서는 웹 등록 시 ESC8를 포함하여 위험한 AD CS 설정을 검토하세요. 이 설정들은 종종 이 두 가지와 함께 나타납니다.

다음 변경 사항을 어떻게 포착합니까?

앞으로 ESC9의 경우: 템플릿 플래그는 Active Directory에 있으며, 이는 해당 변경이 AD 객체 변경임을 의미합니다. Netwrix Threat Prevention는 AD 변경 사항을 실시간으로 모니터링하고 차단할 수 있으므로 누군가 템플릿에 CT_FLAG_NO_SECURITY_EXTENSION을 설정하는 것을 효과가 발생하기 전에 중지할 수 있으며, 다음 평가 시 발견되지 않습니다.

앞으로 ESC16의 경우: 설정은 AD가 아닌 CA 서버의 레지스트리에 있으므로 별도의 관리가 필요합니다. SIEM에 데이터를 제공하는 CA 호스트의 레지스트리 감사를 수행하고 위에서 언급한 주기적인 점검도 포함됩니다. Netwrix는 인증서 기반 로그인과 발급을 연계하고 SID 확장 누락 시나리오를 표시하므로, 레지스트리 변경이 놓쳐져도 설정 남용이 감지됩니다.