Security

MS, 오랜 골칫거리 RC4에 칼 빼들었다

문가용 기자

Published: 17:01, 16 Dec 2025 (Updated: 20:20, 14 Jan 2026)

💡

Editor's Pick
- 예전에는 좋았던 사이퍼 RC4, 이제는...
- AES로 넘어가야 하는데 못 넘어간 고객이 다수
- MS, 이제 RC4 실제 사용률 0이라며 폐지 예고

MS가 자사 OS인 윈도에서 RC4라는 오래된 사이퍼를 폐지하기 시작했다. 지난 2000년 액티브 디렉토리(Active Directory, AD)를 출시할 때, 액티브 디렉토리의 보호 장치로서 처음 도입된 것으로, 당시에는 획기적인 보호 기술이었으나 시간이 지나며 오히려 여러 해킹 사고의 원인이 되어버렸다. 정계에서까지 RC4에 대한 비판이 나왔을 정도였기 때문에 MS의 이번 움직임은 정해진 수순이었다고 할 수 있다.

AD? 사이퍼? RC4?

액티브 디렉토리(AD)는 여러 조직에서 사용하는 중앙 관리 시스템이다. 누가 어떤 컴퓨터에 접근할 수 있는지를, 회사는 이 AD를 통해 조정할 수 있다. 따라서 사용자 인증, 권한 관리, 각 PC와 서버를 관리하는 기능을 가지고 있고, 그런 관리에 필요한 각종 정보와 권한을 스스로 보유하고 있기도 하다. 그러므로 주요 공격 포인트가 되기도 한다.

사이퍼(cipher)는 데이터를 암호화 해 함부로 열람할 수 없게 만드는 알고리즘이다. 당연하지만, 암호화 한 데이터를 해제하는(복호화 하는) 알고리즘이기도 하다. 비밀번호를 보관할 때 평문으로 하지 않고 암호화 처리부터 하는데, 이 때 사용되는 기술 중 하나가 사이퍼다. 네트워크에 누군가 접속해 도청하는 것도 사이퍼로 방지할 수 있고, 로그인 과정에서의 신원 증명 시에도 사이퍼가 작동한다.

RC4는 아주 오래된 사이퍼 중 하나에 붙은 이름이다. 리베스트 사이퍼 4(Rivest Cipher 4)의 준말이다. 론 리베스트(Ron Rivest)라는 암호학자가 개발한 것에서 유래한다. 개발 시기는 1987년이며, 간단한 구현과 빠른 속도 덕분에 큰 인기를 끌었다. 1990년부터 2000년 사이에는 대세 사이퍼로 자리를 잡기도 했다.

하지만 RC4는 완벽하지 않았다. 암호화 결과에 통계적 패턴이 생기며, 따라서 충분한 데이터만 있으면 암호를 깨기 쉽다는 게 뒤늦게 밝혀진 것이다. 게다가 1994년에는 알고리즘 자체가 유출되기도 했다. 이후 여러 공격 기법이 등장했으며, 2010년대엔 사실상 안전하지 않은 사이퍼라고 판명이 났다. 하지만 MS는 액티브 디레고리에 RC4를 여전히 적용하고 있었다.

MS의 고집?

MS가 RC4에 대한 특별한 애정이 있어서 삭제하지 않은 건 아니다. 업계와 정계에서 난리를 치는데도 유지할 수밖에 없었던 건 RC4 없으면 안 되는 MS 고객들이 있었기 때문이다. “일부 기업과 병원, 정부 기관들에는 수십 년 전에 만들어져 사용되어 온 시스템과 소프트웨어들이 있습니다. 그 중 많은 것들의 개발사가 문을 닫기도 했죠. 소스코드도 없고, 따라서 업데이트도 불가능합니다. 그럼에도 반드시 돌아가야 하는, 치명적으로 중요한 요소로 자리를 잡고 있어요. 그런 경우 RC4가 갑자기 바뀌게 된다면 큰일나죠. 의료 기록을 볼 수 없게 된다거나 산업 안전 장치를 제어할 수 없게 되는 상황이 벌어지거든요.” 한 보안 전문가의 설명이다.

이 때문에 MS는 RC4를 유지하면서, 보다 최신화 된 암호화 알고리즘(사이퍼)들을 채용하기 시작했다(대표적으로는 AES). 고객들이 RC4를 서서히 탈피하도록 시간을 준 것이다. “AES가 우선순위를 가져가면서 암호화 알고리즘이 채택되는 순서가 바뀌긴 했지만, RC4는 여전히 살아 있었습니다. 그래서 해커들은 피해자 시스템에 침투해 들어가 RC4를 계속해서 악용할 수 있었습니다.”

RC4로 인한 사고들

RC4로 인한 해킹 사고 중 가장 유명한 건 케르베로스팅(Kerberoasting) 공격이다. “이는 윈도의 인증 프로토콜인 케르베로스(Kerberos)를 악용한 공격 기법입니다. 정상적 인증 절차를 통과한 공격자가 서비스 티켓을 먼저 획득하고, 이를 해독함으로써 서비스 크리덴셜(Credential)을 확보하는 것을 말합니다.” 보안 기업 셈페리스(Semperis)의 설명이다. “서비스 티켓을 해독하는 단계에서 RC4가 문제가 됩니다. 만약 서비스 티켓이 AES 등으로 암호화 되어 있다면 케르베로스팅 공격은 성립하지 않았거나 매우 힘들어졌을 겁니다.”

해독이 가능한 건 액티브 디렉토리에서 RC4를 구현할 때 솔트를 사용하지 않고, 같은 비밀번호를 항상 같은 해시 값으로 처리한다는 치명적인 약점 때문이다. 따라서 무차별 대입 공격과 같은 기초적인 기법에도 쉽게 뚫린다. “RC4가 처음 각광 받았던 건 ‘속도’ 때문이었습니다. 하지만 속도가 공짜로 얻어지는 건 아니죠. 그만큼 어딘가가 허술했다는 것이고, 시간이 지나면서 그 허술함을 모두가 알게 된 거라고 할 수 있습니다. 그래서 RC4는 시간이 흐르면서 점점 약해진 것입니다.”

MS의 결단

이러한 점들 때문에 지난 주 MS는 드디어 RC4를 단계적으로 폐지하겠다고 발표했다. 발표문에서 폐지의 이유로 든 것은 케르베로스팅 공격 기법이었다. “이제 AD에서는 AES-SHA1 암호화 알고리즘만 허용할 예정입니다.” AES-SHA1은 2008년부터 본격적으로 사용되기 시작했으며, RC4에 비해 현격히 높은 보안성을 가지고 있는 것으로 평가 받고 있다.

그렇다면 위에서 설명한, ‘RC4를 포기할 수 없는 고객사들’은 어떻게 되는 걸까? MS는 그 동안 다른 사이퍼로 교체할 시간을 충분히 주었는지, “이제는 RC4를 폐지했을 때 큰 영향을 받는 곳이 거의 없는 것으로 조사됐다”고 밝혔다. RC4 폐지로 인한 예상 피해가 0에 가깝다고 한다. “이것이 폐지를 결단한 가장 큰 요인입니다.”

물론 당장 다음 주나 1월 1일부터 모든 MS 환경에서 RC4가 칼같이 지워지는 건 아니다. “2026년 중반부터는 RC4를 디폴트상 비활성화 할 예정입니다. 따라서 정말 RC4가 필요한 경우 일부러 설정을 고친다면 RC4를 쓸 수는 있습니다. 다만 저희는 지금도 그렇지만 앞으로도 RC4는 매우 위험하다는 경고를 계속해서 낼 겁니다.”

💡

여기서 잠깐!
과거 RC4를 비활성화 한 것과 이번에 비활성화 하는 것에는 차이가 있다. 과거에는 ‘RC4보다는 AES를 먼저 써보세요’라는 뉘앙스였다. 그래서 AES가 디폴트이긴 해도 RC4와의 호환성은 유지됐다. 지금은 관리자가 특정 계정의 설정을 바꾸거나 정책 자체를 변경하는 대대적인 작업을 하면서 RC4를 명확히 허용해야만 사용 가능하다. ‘RC4는 위험하니 이번 한 번만 쓰고 또 쓰지 마세요’라는 뉘앙스에 가깝다고 할 수 있다.

이 경고 속에는 중요한 내용이 포함될 예정이다. 바로 RC4로 인한 사고는 MS가 책임 지지 않는다는 것이다. RC4의 위험성에 대해 알리고 있고, 새로운 대체 알고리즘을 제안하고 도입하기도 했으며, 심지어 비활성화시킨 상태로 윈도를 제공하니 법적 책임을 질 이유가 없게 된 것이다. “앞으로 RC4로 인한 보안 사고가 일어난다면, 더는 MS를 탓하지 못할 것으로 보입니다. 이게 이번 MS 발표의 핵심입니다.”

실제로 MS는 RC4의 완전 폐기 날짜를 공개하지는 않았다. 다만 고객들이 자신들의 네트워크나 시스템 내 어디에서 RC4를 사용하는지 정확히 찾도록 도움을 주겠다고 말했다. “어떤 시스템이 RC4에 의존하는지 사전에 정확히 식별할 수 있다면, AES로 넘어가는 데 도움이 될 겁니다.” 많은 사용자들은 자신이 RC4에 의존하고 있다는 걸 모르고 있고, 이 때문에 케르베로스팅 공격을 허용하게 된다고 셈페리스는 강조한다.

보안의 책임 소재

이번 MS의 발표를 한 줄로 요약하면 “RC4는 위험하다”이다. 한 줄을 더 보태면 “난 알려줬으니 앞으로 일어나는 사고에 대해서는 책임이 없다”까지 포함할 수 있다. 소프트웨어 개발사로서 RC4로 인한 사고에 대한 법적, 도의적 책임에서부터 벗어나려는 게 MS의 진정한 목적이라고 시장 전문가들은 분석한다.

무리수는 아닌 것으로 평가되기도 한다. MS는 RC4가 위험하다는 인식이 생겨났을 때부터 RC4를 폐지하려고 여러 가지 수단을 동원했었다. 사용자에게 경고하기도 하고, 다른 대체 사이퍼를 도입하기도 했다. 그러면서도 RC4 없으면 안 된다는 고객들을 위해 RC4에 겨우 인공호흡기를 붙여놓기도 했었다. 그럼에도 RC4 기반 사고가 발생하면 모든 손가락질은 MS로 돌아갔다.

“MS로서는 이러지도 저러지도 못하는 상황이었을 겁니다. 그러다가 RC4의 실제 사용량이 0에 가까워지니 드디어 칼을 빼든 것이죠. 이번에도 RC4를 완전히 제거하는 건 아니지만, ‘난 할 일을 다 했고, 앞으로도 더 할 거니까 사고 책임은 이런 상황에도 굳이 RC4를 쓰겠다는 사람이 져야 한다’는 메시지를 전달했습니다. 즉 빼든 칼로 겨눈 건, RC4 사용자라고 할 수 있습니다. ‘보안 사고, 네가 책임져라’는 의미죠. MS가 해온 일을 봤을 때 이쯤 되면 정말 RC4로 인한 책임은 사용자가 져야 할 때가 맞아 보입니다.” 익명을 요청한 한 보안 전문가의 의견이다.

RC4 의존성 확인, 어떻게?

RC4로 인한 사고의 책임을 누가 지느냐의 문제보다 더 중요한 건, RC4가 사용되고 있는지도 모른 채 사용하다가 사고를 겪는 기업, 병원, 기관을 구제하는 일이다. MS는 “도메인 컨트롤러의 보안 사건 로그(Security Event Log)에서 Event ID 4769의 필드값을 확인하라”고 권장한다. 해당 이벤트 안에는 Ticket Encryption Type이라는 항목이 있는데, 이때 값이 0x17이라면 RC4를 사용한다는 뜻이라고 한다. “참고로 0x12는 AES256이고 0x11은 AES128입니다.”

관리자 권한을 가진 사람이 사용할 수 있는 파워셸 예제는 다음과 같다.

💡

Get-WinEvent -FilterHashtable @{
LogName='Security'
Id=4769
} | Where-Object {
$_.Properties[8].Value -eq "0x17"
} | Select-Object TimeCreated,
@{Name="ServiceAccount";Expression={$_.Properties[5].Value}},
@{Name="Client";Expression={$_.Properties[0].Value}}

RC4는 계정 단위로도 강제될 수 있는데, 이 때 AD 사용자 속성 등을 일괄적으로 확인하려면 다음과 같은 파워셸 코드를 사용할 수도 있다고 한다.

💡

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
Select Name, msDS-SupportedEncryptionTypes

이 때 0이나 null이 나오면 RC4가 사용되고 있다는 의미다. 24나 28은 AES 계열이다. 따라서 0과 null 값이 나온다면 RC4에 대한 조치를 취해야 안전해진다. 🆃🆃🅔

by 문가용 기자(anotherphase@thetechedge.ai)