Unit 42가 Windows 외 세계 최초로 구현한 브라우저 기반 RDP WebAuthn 리디렉션의 기술 구조를 분석합니다. MS-RDPEWA 프로토콜, 미문서화 DVC 플러그인 역추적, clientDataHash 문제 해결 과정까지 상세 해부.
발행 ·읽기 14분·조회 0
deep_diveWebAuthnFIDO2RDPUnit42인증보안NTLM
핵심 요약Key Findings
Unit 42가 Windows 외 세계 최초로 브라우저 기반 RDP 클라이언트에 [WebAuthn](/blog/passkey-[phishing](/blog/kimsuky-[lazarus](/blog/lazarus-group-north-korea-apt)-phishing-technique-t1566-j27ywlfd)-blocking-authentication-0rbyfqok) 리디렉션 구현(2026년)
MS-RDPEWA의 4개 레거시 커맨드와 미문서화 `CtapCborDecodeRpcRequest` 함수가 구형 서버(~24H2) 지원의 핵심
clientDataHash 문제: 브라우저 표준 API 우회를 위해 커스텀 Chromium Extension API 구현이 필수였고, SHA-256 단방향 특성상 해시 역산 불가 → 비공개 DVC 경로로만 해결
근거: Unit 42 (2026-07-02) · W3C WebAuthn Working Group · MS-RDPEWA Rev3.0 (2026-03-30)
이 분석 공유
공유
댓글 (0)
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
RDP는 오랫동안 초기 침투의 관문이었다. 2026년 Verizon DBIR에 따르면 보안 침해의 36%가 탈취된 자격증명과 연관된다. 공격자들이 탈취한 자격증명만으로 원격 데스크톱에 접속해 내부망을 장악하는 방식은 수십 년간 유효하다.
WebAuthn은 이 구도를 바꾼다. 브라우저 표준으로 하드웨어 키(YubiKey 같은 것)나 지문 인식 같은 강한 인증을 웹 서비스에 붙일 수 있다. 그런데 이 방식을 브라우저 기반 RDP 클라이언트에서 동작시키려면, Microsoft조차 문서화하지 않은 코드 경로를 역추적해야 했다.
Unit 42(Palo Alto Networks)는 2026년 7월 이 리버스엔지니어링 과정 전체를 공개했다. Windows 이외의 환경에서 RDP WebAuthn 리디렉션을 구현한 사례는 이것이 세계 최초다.
Why — RDP는 왜 지금도 초기 침투 경로 1위인가
원격 데스크톱 프로토콜(RDP)은 MITRE ATT&CK T1021.001로 분류된다. Sophos의 2025년 Active Adversary Report에 따르면 분석된 공격 사례의 84%에서 RDP 활동이 탐지됐다. 초기 접근 벡터 중 외부 원격 서비스(RDP 포함)는 71%를 차지한다.
기존 RDP 인증 방식의 구조적 약점은 NTLM에서 비롯된다. NTLM은 Windows가 30년 가까이 써 온 비밀번호 인증 방식이고, 사용자가 입력한 비밀번호는 해시 값으로 변환돼 서버와 주고받는다.
NTLM의 핵심 결함은 이것이다. 비밀번호 해시 자체가 신분증처럼 통한다. 정상 로그인에서는 사용자가 비밀번호를 입력하면 해시로 변환돼 서버로 가지만, 공격자 관점에서는 해시만 있어도 로그인이 된다. 그래서 LSASS라는 Windows 인증 프로세스의 메모리에서 해시를 뽑아내면(패스더해시 공격), 그 해시를 그대로 RDP 접속에 재사용할 수 있다.
약점
공격 기법
관련 CVE
자격증명 재사용
탈취 ID/PW로 즉시 접속
—
패스더해시(PtH)
NTLM 해시로 RDP 인증
피싱
가짜 로그인 페이지 → 자격증명 탈취
—
는 2025년 3월 공개된 Windows NTLM 해시 노출 취약점으로 CISA KEV에 등재됐다. Microsoft는 NTLM을 단계적 폐지 대상으로 지정했으며, 2026년 10월 구버전(NTLMv1)의 자동 차단을 예고했다.
WebAuthn(FIDO2)은 이 세 가지 공격을 암호학적으로 차단한다. 인증 키가 특정 사이트 주소(origin)에 묶여 있어, 다른 사이트나 다른 세션에서 재사용하는 것이 불가능하기 때문이다.
문제는 WebAuthn을 브라우저 기반 RDP 클라이언트에서 동작시키기가 매우 어렵다는 점이었다.
What — WebAuthn과 RDP 리디렉션의 기초
WebAuthn(Web Authentication) 은 W3C 표준으로, 브라우저가 하드웨어 인증기(YubiKey, Touch ID, Windows Hello 등)와 통신하는 방식을 정의한다. 핵심은 클라이언트 데이터 JSON(clientDataJSON)이라고 부르는 작은 데이터 뭉치다. 브라우저가 인증 요청 때마다 자동으로 만들어서 인증기에 전달한다.
이 안에 담기는 필드 세 개가 중요하다.
필드
값 예시
역할
type
"webauthn.get"
등록/인증 구분
challenge
랜덤값
재전송 공격 방지
origin
"https://example.com"
사이트 바인딩
브라우저는 인증 요청 시 현재 탭의 사이트 주소(origin)를 자동으로 JSON에 삽입한다. 인증기는 이 JSON을 통째로 SHA-256으로 요약한 값(클라이언트 데이터 해시, clientDataHash)에 서명한다.
피싱 저항성의 원리: 공격자가 evil-bank.com으로 사용자를 유도해도, 브라우저는 진짜 bank.com의 인증 키를 가짜 사이트에 제시하지 않는다. origin이 달라지면 인증기가 그 사이트에 등록된 키를 아예 찾지 못하기 때문이다.
RDP 리디렉션(MS-RDPEWA) 은 이 흐름을 원격 세션으로 확장하는 Microsoft 스펙이다(Revision 3.0, 2026-03-30). 이름에서 알 수 있듯이, 원격 서버가 WebAuthn 요청을 받으면 그것을 자기 손으로 처리하지 않고 사용자 로컬 PC로 넘긴다. 로컬 PC에 꽂힌 하드웨어 키가 서명한 결과만 다시 서버로 돌아온다.
How — Unit 42의 리버스엔지니어링 여정
1단계: MS-RDPEWA 프로토콜 파악
MS-RDPEWA 스펙은 동적 가상 채널(DVC — RDP 세션 안에 서버와 클라이언트가 별도 파이프를 열어 데이터를 주고받는 통로) 위에서 동작한다. 채널 이름은 Microsoft::Windows::RDP.Webauthn이며, 서버는 CBOR(JSON의 이진 버전, 크기가 작아 프로토콜에 자주 쓰인다)로 인코딩한 요청을 클라이언트로 전송한다.
프로토콜 커맨드는 서버 버전에 따라 다르다.
커맨드 (ID)
기능
지원 버전
WEB_AUTHN (5)
MakeCredential / GetAssertion
모든 버전
IUVPAA (6)
플랫폼 인증기 감지 쿼리
모든 버전
CANCEL (7)
작업 취소
모든 버전
API_VERSION (8)
버전 협상
모든 버전
GetCredentials (9)
자격증명 목록 조회
Win11 24H2+, Server 2025+
GetAuthenticatorList (12)
인증기 목록 조회
동일
스펙만 보면 구현이 가능해 보인다. 문제는 그다음이었다.
2단계: clientDataHash 문제
브라우저 표준 API는 개발자가 원본 JSON을 직접 만들도록 허용하지 않는다. 브라우저가 자동으로 자기가 보고 있는 사이트 주소를 넣어 만들어 버린다. 이때 사이트 주소가 실제 RDP 서버 도메인이 아니라 chrome-extension://… 형태로 들어간다. 서버가 이미 계산해 놓은 해시와 다른 값이 나올 수밖에 없다.
SHA-256은 단방향 함수다. 해시에서 원본을 되돌릴 수 없다. 원본 JSON을 알지 못하면 같은 해시를 만들 수 없다. Unit 42 기사에서는 이 지점을 다음과 같이 표현했다.
"SHA-256 is a one-way function. There's no going around this."
표준 브라우저 API로는 해결이 불가능했다.
3단계: mstscax.dll 역추적
해결책을 찾기 위해 Unit 42는 Microsoft의 공식 RDP 클라이언트 DLL(mstscax.dll)을 뜯어봤다. Frida(실행 중인 프로그램의 함수 호출을 가로채는 동적 분석 도구)를 이 DLL에 붙여 실제 RDP 세션이 주고받는 WebAuthn 데이터를 관찰했다. 결과는 결정적이었다.
"no clientDataJSON on the wire. The server sends a 32-byte clientDataHash."
서버는 원본 JSON을 아예 보내지 않는다. 32바이트짜리 해시만 던져 준다. Windows의 webauthn.dll은 이 해시를 처리하는 비공개 경로를 내부적으로 갖고 있었다. IDA Pro(바이너리 정적 분석 도구)와 MCP 브리지를 활용한 분석으로 이 경로의 두 핵심 함수를 식별했다. 기존에 수 일 걸리던 작업이 수 시간으로 단축됐다.
비공개 함수 CtapCborDecodeRpcRequest는 원본 JSON을 선택 사항으로 처리한다. 없으면 해시를 그대로 통과시킨다. 이 동작은 MS-RDPEWA 스펙 어디에도 기술되어 있지 않다. 이 경로를 브라우저 환경에서 직접 호출하려면, 브라우저의 표준 인증 API를 우회하는 별도 계층이 필요했다.
4단계: 커스텀 Chromium Extension API 구현
Unit 42는 표준 API 대신 해시 값을 직접 받을 수 있는 커스텀 함수 두 개(makeCredential, getAssertion)를 Chromium에 심었다. 이를 통해 브라우저가 원본 JSON을 자동으로 만드는 과정을 우회한다.
최종 아키텍처는 3계층이다.
FIDO 표준 구현체로 널리 쓰이는 libfido2를 쓰지 않고 Chromium 내부의 FIDO2 스택을 재활용한 이유가 따로 있다. 브라우저 확장은 WebAssembly로 실행되는데, 이 환경에서는 USB 장치와 직접 통신하는 저수준 접근이 막혀 있어 libfido2가 동작하지 않는다. 반면 Chromium 스택은 USB 하드웨어 키, 블루투스, NFC, 지문 인식기, 스마트폰 하이브리드 인증까지 한 스택으로 처리한다.
5단계: Windows 서버 버전별 이중 경로 대응
구형 서버와 신형 서버의 동작이 다르다. 배포된 대부분의 RDP 서버가 구형 버전이므로 두 경로 모두 지원해야 했다.
서버 버전
전송 내용
구현 경로
Windows 11 25H2+, API v9 이상
전체 clientDataJSON + remoteWebOrigin
표준 API 사용 가능
Windows 10 · Server 2019/2022 · Win11 ~24H2
32바이트 clientDataHash만
미문서화 DVC 플러그인 필수
Security — 보안 분석가 관점
피싱 저항성의 실질적 의미
2026년 Verizon DBIR는 침해의 36%가 탈취된 자격증명과 연관된다고 밝혔다. 2025년 DBIR에서는 거의 절반의 침해에 자격증명 탈취가 포함됐다. RDP는 이 자격증명이 최초 사용되는 진입점 중 하나다.
WebAuthn 기반 인증에서는 피싱 경로가 암호학적으로 차단된다. 공격자가 rdp.attacker.com으로 유도해 자격증명을 수집해도, origin이 바인딩된 WebAuthn 응답은 rdp.legit.com에서 검증을 통과하지 못한다. 인증 키 자체가 특정 사이트 주소에 묶여 있어 다른 도메인에서 물리적으로 제시할 수 없다.
NTLM 해시 탈취 경로(PtH)에 대해서는 구현 방식에 따라 다르다. 하드웨어 키(YubiKey)를 사용하면 개인 키가 디바이스 밖으로 나가지 않으므로 탈취 자체가 불가능하다. 지문·얼굴 인식 같은 플랫폼 인증기는 TPM(Windows 메인보드에 내장된 보안 칩)에서 키를 보호한다.
탐지 관점 — WebAuthn RDP를 도입해도 남는 흔적
WebAuthn이 자격증명 탈취 경로를 없애도 공격자의 흔적이 완전히 사라지지는 않는다. 오히려 몇몇 지표는 더 뚜렷해진다.
인증 실패 시그니처가 바뀐다: NTLM 실패 로그(이벤트 ID 4625) 대신 서버 측 WebAuthn 검증 실패가 남는다. 특히 origin 불일치로 실패한 경우는 정상 사용자에겐 드문 이벤트라 탐지 신뢰도가 높다.
DVC 채널 트래픽 자체가 지표: Microsoft::Windows::RDP.Webauthn 채널이 열린 세션에서만 하드웨어 키 인증이 이뤄져야 한다. 이 채널이 열리지 않은 세션의 인증 성공은 우회 시도의 신호다.
CtapCborDecodeRpcRequest 호출 패턴: Windows Server의 이 함수가 정상 세션에서는 인증 요청당 1회 호출된다. 짧은 시간에 반복 호출되면 자격증명 재활용 시도를 의심할 수 있다.
RP ID 등록 이력: RP ID(사이트를 식별하는 값)가 미리 등록된 화이트리스트를 벗어나면 리디렉션 대상이 의심스러운 것이다. 조직이 자체 관리하는 RDP 게이트웨이에서만 발생해야 정상이다.
WebAuthn 도입 후에도 원격 세션의 로그를 계속 봐야 하는 이유가 여기 있다. 인증이 강해질수록 공격자는 세션 하이재킹, 토큰 도용, 세션 쿠키 탈취 같은 후속 경로로 이동한다.
Microsoft 문서화 공백의 보안 함의
Unit 42 기사에서 지적한 부분이 보안 관점에서 중요하다.
"Microsoft's documentation gaps aren't edge cases...these must be fixed for the implementation to work at all."
MS-RDPEWA 스펙과 실제 구현 사이의 간극이 크다는 의미다. 스펙대로만 구현하면 구형 서버에서 작동하지 않는 코드 경로가 존재한다. 이런 불일치는 서드파티 구현체의 보안 취약점으로 이어질 수 있다. 예를 들어 해시 검증을 생략하거나 잘못 처리하면, RDP WebAuthn의 보안 속성이 조용히 깨질 수 있다.
표준화 현황과 생태계
W3C WebAuthn 워킹 그룹은 이 사용 사례를 remoteClientDataJSON 확장(editor's draft 섹션 10.1.6)으로 표준화 중이다. Unit 42의 구현 방식이 유효성을 인정받아 표준 초안에 반영됐다.
현재 RDP WebAuthn 리디렉션 구현 현황은 다음과 같다.
클라이언트
지원 여부
비고
Unit 42 브라우저 RDP
지원
세계 최초 (Windows 외)
FreeRDP 3.25.0
지원
2026년 4월 추가
Microsoft macOS/iOS/Android/Linux
미지원
—
Azure Virtual Desktop
제한적 지원
Intune/GP로 활성화 필요
한국 보안 환경과의 연결
RDP를 이용한 공격은 국내 보안 환경과도 직접 연결된다.
북한 연계 APT 그룹 Kimsuky의 하위 클러스터 Larva-24005는 2023년 10월부터 2025년 4월까지 활동했다. 이들은 BlueKeep() 취약점을 이용해 RDP로 침투한 뒤 RDPWrap으로 지속성을 유지했다. 타겟에는 한국 소프트웨어·에너지·금융 섹터 기업이 포함됐다(AhnLab ASEC 분석, 2025년 4월).
수치로 보면, KISA가 집계한 2024년 국내 사이버 침해사고 신고 건수는 1,887건으로 전년 대비 48% 증가했다. AhnLab이 집계한 2025년 한국 기업 대상 랜섬웨어 피해는 56건으로 최근 5년 최다다. 랜섬웨어 그룹들은 외부에 노출된 RDP 포트를 스캔하고 브루트포스로 침투하는 방식을 지속적으로 사용하고 있다.
WebAuthn 기반 인증이 RDP 레이어까지 확장된다면, NTLM 자격증명 탈취 기반의 초기 침투 경로를 구조적으로 좁힐 수 있다. FIDO Alliance의 2026년 보고서에 따르면 전 세계 기업의 68%가 이미 직원 로그인에 패스키를 도입 중이며 활성 패스키는 50억 개에 달한다. RDP WebAuthn 리디렉션은 이 흐름의 다음 단계다.
Summary — 3줄 정리
MS-RDPEWA는 구형 서버(Windows 10~11 24H2)에서 미문서화 함수(CtapCborDecodeRpcRequest) 경로로만 동작한다. 스펙만으로는 구현 불가하며, Frida 동적 분석과 IDA Pro 정적 분석을 병행한 바이너리 역추적이 필요했다.
WebAuthn은 사이트 주소 바인딩으로 RDP 자격증명 피싱을 암호학적으로 차단한다. 하드웨어 키 사용 시 NTLM PtH 탈취 경로도 제거된다.
W3C 표준화 진행 중이지만 Microsoft 공식 클라이언트는 아직 미지원이다. FreeRDP 3.25.0(2026-04)이 유일한 오픈소스 구현체이며, 표준이 확정되면 RDP 클라이언트 생태계 전반으로 확산될 전망이다.