RC4는 케르베로스가 수십 년 동안 인증 트래픽을 보호하기 위해 사용해 온 기존 암호화 알고리즘입니다. Active Directory (AD) 환경. 하지만 이제 상황이 바뀔 것입니다. 여러분의 환경이 준비되었든 아니든 말이죠.
보안 강화의 일환으로 다음과 같은 조치가 시행됩니다. CVE-2026-20833마이크로소프트는 케르베로스 인증에서 RC4 암호화를 단계적으로 폐지하고 있습니다. 2026년 4월 윈도우 업데이트는 케르베로스 키 배포 센터(KDC)가 RC4를 암묵적인 대체 암호화 방식으로 더 이상 허용하지 않는 첫 번째 단계입니다. RC4 의존성을 제대로 설정하지 않은 환경은 운영 환경에서 인증 실패라는 최악의 상황에 직면하게 될 것입니다.
보안 커뮤니티에서는 RC4 암호화 방식이 취약하다는 사실을 오래전부터 밝혀왔습니다. 어려운 점은 환경 어디에 아직도 RC4가 숨어 있는지 파악하는 것입니다. RC4는 암호학적으로 구식이며, 공격에 취약한 표면으로 잘 알려져 있고, 레거시 시스템과의 하위 호환성 때문에 계속 사용되고 있을 뿐입니다. RC4는 의도했던 것보다 훨씬 오랫동안 Active Directory 환경에서 사용되어 왔습니다.
이 블로그에서는 RC4 종속성을 감지하기 어려운 이유, 이를 간과할 경우 발생할 수 있는 위험, 그리고 해결 방법에 대해 살펴보겠습니다. Silverfort 보안팀이 규제 기관에서 조치를 취하기 전에 문제를 발견하고 해결할 수 있도록 가시성을 제공합니다.
케르베로스에서 RC4가 심각한 보안 취약점인 이유는 무엇일까요?
RC4 지원 중단이 왜 중요한지 이해하려면 다음이 도움이 됩니다. 케르베로스 인증 작동 방식을 간단히 요약해 보겠습니다.. 때 AD 환경에서 사용자 또는 서비스 계정이 인증되면 Kerberos KDC가 티켓을 발급합니다.본질적으로 특정 리소스에 대한 접근 권한을 부여하는 암호화 방식으로 보호된 패스입니다.해당 티켓을 보호하는 데 사용되는 암호화 알고리즘 결정하다 공격자가 얼마나 어려운지 갈라진 금 그것.
바로 이 부분에서 RC4는 심각한 취약점을 드러냅니다. 케르베로스 티켓이 RC4로 암호화되면, 다음과 같은 공격에 취약해집니다. 케르베로스팅이러한 유형의 공격에서, 유효한 도메인 계정을 가진 공격자는 정상적인 리소스에 대한 서비스 티켓을 요청하고, 이를 탈취하여 오프라인 상태로 만든 후 무차별 대입 공격을 시도할 수 있습니다. 이 과정에서 관리자 권한은 필요하지 않으며, 경고도 발생하지 않습니다. 암호화 수준이 낮을수록 해킹 속도는 빨라집니다.
RC4를 사용하면 특히 오래되었거나 취약한 암호를 사용하는 서비스 계정의 경우 고급 암호화 표준(AES) 암호화에 비해 해당 프로세스가 훨씬 빠릅니다. 결과적으로 기본 도메인 계정에서 전체 서비스 계정으로의 접근이 수월해지며, 그 이후에는 더욱 심각한 문제가 발생할 수 있습니다. 측면 운동 전체 환경에 걸쳐.
RC4 종속성을 찾기 어려운 이유는 무엇일까요?
RC4가 널리 알려진 위험 요소라면, 왜 여전히 많은 환경에서 RC4에 의존하고 있을까요? 그 이유는 부주의 때문이 아니라, 가시성 부족 때문입니다. RC4 노출은 종종 눈에 띄지 않게 발생합니다. 오랫동안 손대지 않은 곳에서 조용히 백그라운드에서 실행될 수 있습니다.
주된 이유는 AD의 특정 속성 때문입니다. msDS에서 지원하는 암호화 유형. 계정에 이 속성이 명시적으로 설정되지 않은 경우 KDC는 어떤 암호화를 사용해야 하는지 알 수 없으며, 과거에는 RC4, AES-128 또는 AES-256 모두 허용되었습니다. 대부분의 환경에는 이 속성이 정의되지 않은 계정이 수천 개에 달하며, 이러한 계정 하나하나가 Kerberoasting 공격 및 계정 침해의 잠재적 대상이 될 수 있습니다.
특히 위험에 취약한 계정 유형은 서비스 계정과 기기 계정 두 가지입니다.
서비스 계정 Active DirectoryRC4의 가장 큰 사각지대
서비스 계정 이러한 계정은 애플리케이션, 서비스 또는 자동화된 프로세스를 실행하기 위해 생성된 사용자 유형 계정입니다. 일반 사용자 계정과 달리 이러한 계정의 암호는 수동으로 관리되며, 많은 환경에서 수년 동안 재설정되지 않은 경우가 많습니다.
서비스 계정의 암호가 Windows Server 2008 이전 버전(Active Directory에서 AES 암호화 지원이 도입된 버전)에 설정된 경우, 해당 계정에는 AES 키가 생성되지 않습니다. 도메인을 업그레이드하는 것만으로는 이 문제가 해결되지 않습니다. 암호를 재설정해야만 RC4 대신 AES 키가 생성됩니다. 하지만 암호를 재설정하려면 어떤 계정이 이러한 상태인지 파악해야 하는데, 대부분의 환경에서는 이러한 정보를 파악하기 어렵습니다.
머신 계정 Active Directory다른 종류의 의존성
기계 계정 자동으로 생성됩니다. Active Directory 도메인에 가입하는 모든 엔드포인트에 대해 이러한 계정이 필요합니다. 서비스 계정과 달리 엔드포인트 계정의 암호는 자동으로 변경되므로 오래된 자격 증명은 문제가 되지 않습니다.
문제는 운영 체제 자체에 있습니다. Windows Server 2008 이전 버전을 실행하는 장치는 AES 암호화를 지원하지 않습니다. 이러한 계정의 경우 RC4는 기본 옵션이 아니라 시스템을 업그레이드하기 전까지 필수 요구 사항입니다.
결과적으로 대부분의 환경에서 RC4 취약점은 한 곳에 집중되지 않고 서비스 및 머신 계정 전체에 분산되어 있으며, 각 계정마다 종속성의 원인과 해결 경로가 다릅니다.
RC4 지원 중단 일정: 각 단계별 진행 상황 및 현재 중요한 이유
마이크로소프트는 RC4 지원 중단을 단계적으로 진행하여 기업들이 준비할 시간을 확보했지만, 그 시간은 얼마 남지 않았습니다.
2026 년 XNUMX 월 이번 업데이트에서는 감사 단계가 도입되었습니다. RC4 암호화는 여전히 허용되었지만, 조직이 해당 암호화가 어디에 사용되고 있는지 파악할 수 있도록 새로운 로깅 메커니즘이 추가되었습니다.
4 월 2026 업데이트는 시행이 시작되는 지점입니다. 키 배포 센터(KDC)는 이제 기본적으로 AES 전용 모드로 운영됩니다. msDS에서 지원하는 암호화 유형 정의되지 않았습니다. RC4는 더 이상 대체 옵션이 아니며, RC4에 의존하는 모든 서비스 또는 시스템 계정은 인증 실패를 경험하게 될 것입니다. 임시 해결책은 다음과 같습니다. RC4DefaultDisablementPhase 레지스트리 키를 사용하면 관리자가 복구 작업을 완료하는 동안 DC 동작을 수동으로 롤백할 수 있습니다. 하지만 이는 명백히 단기적인 해결책입니다.
2026년 7월이렇게 되면 롤백 옵션이 완전히 제거됩니다. RC4 암호화는 개별 계정에 명시적으로 구성된 경우에만 작동하지만, Microsoft는 이러한 안전하지 않은 접근 방식을 권장하지 않습니다. 완전한 복구 프로세스가 완료되지 않으면 남아 있는 RC4 종속성으로 인해 롤백할 수 없는 인증 실패가 발생합니다.
위험은 인증 실패에만 있는 것이 아닙니다. 서비스 계정 인증에 실패하면 애플리케이션이 다운되고 자동화된 프로세스가 중단됩니다. 이는 운영상의 문제로 이어져 심각한 결과를 초래할 수 있습니다. 전사적 혼란7월 이후에도 명시적으로 구성된 RC4 종속성은 Kerberos 인증의 영구적인 취약점이 됩니다.
주변 환경에서 RC4 노출을 찾는 방법 Silverfort
Silverfort 추가 구성이나 스크립팅 없이 두 가지 상호 보완적인 접근 방식, 즉 사전 예방적 자세 평가와 실시간 인증 모니터링을 통해 환경 내 RC4 종속성을 식별하는 데 도움이 됩니다.
이번 조사는 자연스러운 2단계 흐름을 따릅니다. 먼저 위험 지표를 통해 RC4 의존성을 가질 가능성이 가장 높은 계정과 장치를 사전에 식별하고, 그다음 인증 로그를 자세히 분석하여 실시간 인증 흐름에서 RC4를 구체적으로 사용하는 계정과 장치를 확인합니다.
1단계-위험 지표: I확인하다 암호화가 취약한 계정 노출
Silverfort'의 신원 보안 태세 관리(ISPM) 환경을 지속적으로 모니터링하고 인증 트래픽에서 취약한 암호화가 감지되면 위험 지표를 자동으로 표시합니다. RC4 노출과 직접적으로 관련된 지표는 두 가지입니다.
- 취약한 암호화(사용자)—사용자 계정이 RC4 또는 기타 취약한 Kerberos 암호화 유형을 사용하여 인증할 때 발생하는 오류입니다.
- 취약한 암호화(서버)—서비스 또는 기기 계정에서 동일한 문제가 발생할 경우 제기됨
이러한 지표는 인증 트래픽에서 취약한 암호화가 실제로 확인된 계정 목록을 즉시 제공하며, 이는 구성에 따라 위험에 처할 수 있는 계정뿐 아니라 현재 취약한 암호화가 활발히 사용되고 있는 계정까지 포함합니다.
취약한 암호화 지표 외에도 두 가지가 있습니다. 추가 ISPM 범주는 전체적인 그림을 완성하는 데 도움이 됩니다. 오래된 비밀번호를 사용하는 사용자 식별하다 서비스 계정은 Windows Server 2008 이전 버전의 암호를 사용하고 AES 키가 생성되지 않았기 때문에 RC4 키만 사용할 가능성이 가장 높습니다. 구형 운영 체제 표면 장치 하지 AES 암호화를 지원하므로, 강제 적용 전에 어떤 머신 계정에 수동 RC4 예외를 구성하거나 서비스 종료 계획을 수립해야 하는지 명확하게 파악할 수 있습니다.
2단계 - 인증 로그: RC4 사용 내역 확인 및 조사
플래그가 지정된 계정 목록을 확보했으면, Silverfort's 인증 로그 더 깊이 들어가 볼 수 있도록 (참고: 당신은 할 수 있습니다) 신원 가시성 및 인텔리전스 확보에 대한 자세한 내용은 여기에서 확인하세요.). 다음으로 필터링하세요 약하게 암호화된 답장 약하게 암호화된 티켓 RC4가 정확히 어디에 사용되고 있는지 인증별로 파악할 수 있는 위험 지표를 제공합니다. 각 인증에 대해 다음을 확인할 수 있습니다.
- 관련된 사용자 또는 서비스 계정
- 소스 호스트
- 대상 서비스 또는 SPN
- 티켓을 발급한 도메인 컨트롤러
이를 통해 어떤 계정이 RC4 암호화를 구체적으로 사용하고 있는지 확인하고, 문제 해결의 우선순위를 정하고, 영향을 받는 시스템을 담당하는 팀과 함께 정보에 입각한 의사 결정을 내리는 데 필요한 정확한 맥락을 파악할 수 있습니다.
마이크로소프트가 RC4 노출 기회를 찾아줄 때까지 기다리지 마세요.
Silverfort 이를 통해 Microsoft의 강제 적용 이전에 RC4 종속성을 찾아 인증 실패 및 생산성 손실을 방지할 수 있습니다. 또한, Silverfort지속적인 모니터링을 통해 문제를 해결해 나가는 과정에서 진행 상황을 추적할 수 있습니다. 2026년 7월 마감일이 다가오고 있는 지금, 현재 상황을 파악하기에 이보다 더 좋은 시기는 없습니다.
어디서부터 시작해야할지 모르겠습니까? 우리를 다운로드 RC4 개선 준비 체크리스트 위험 노출 정도를 평가하고 다음 단계를 우선순위화하는 데 도움이 되며, 더 자세한 내용을 알고 싶으시다면 Silverfort 도울 수있다, 통화 예약 전문가 중 한 명과 함께.
