BeyondTrust Remote Support CVE-2026-102764: 원격지원 서버가 내세운 이름만 믿고 들여보낸 상대

이미지 출처: CISA KEV

헬프데스크 담당자가 전화를 받고, 사용자에게 세션 키를 불러주고, 몇 초 뒤 사용자 PC 화면이 상담원 모니터에 뜨는 장면을 떠올려보면 원격지원 솔루션이 얼마나 깊은 곳까지 들어가는 도구인지 실감이 남. 그 한가운데 서는 어플라이언스가 "이 요청을 보낸 쪽이 정말 그 사람이 맞는지"를 제대로 확인하지 않는다면 어떻게 될까? 이번에 NVD에 올라온 CVE-2026-102764가 바로 그런 이야기임. BeyondTrust Remote Support에서 스푸핑(Spoofing)을 통한 인증 우회가 가능하다는 내용이고, 개인적으로는 패치 공지만 보고 지나치기엔 이 제품이 쥐고 있는 권한이 너무 크다 보니 방어자 입장에서 한 번 길게 정리해두는 게 맞는 것 같았음.

핵심 요약

• BeyondTrust Remote Support에서 요청 출처나 신원 정보를 위조해 정상 인증 절차를 건너뛸 수 있는 취약점(CVE-2026-102764)이 공개됨.
• 원격지원 어플라이언스는 엔드포인트 전체에 대한 접근 통로라서, 인증이 뚫리면 내부 확산의 출발점이 될 수 있음.
• 벤더 패치 적용이 1순위이고, 관리 인터페이스 노출 축소와 세션·인증 로그 소급 점검을 함께 해야 함.

1. 이 취약점이 건드리는 자리

스푸핑에 의한 인증 우회는 분류상 흔히 CWE-290 계열로 묶이는 유형임. 공격자가 비밀번호를 맞히거나 토큰을 훔치는 게 아니라, 서버가 신뢰의 근거로 삼는 어떤 값을 그럴듯하게 꾸며서 내미는 방식임. 그 값이 무엇이냐는 제품마다 다른데, 일반적으로는 다음 같은 것들이 후보가 됨.

• 요청이 어디서 왔는지 알려주는 헤더나 출발지 정보
• 클라이언트가 스스로 신고하는 식별자(장치 ID, 사용자 이름, 역할 값 등)
• 내부 구성요소끼리만 주고받는다고 가정한 신호나 플래그

핵심은 "클라이언트가 말한 것"을 "서버가 검증한 것"처럼 취급했다는 데 있음. 개념적으로 보면, 원래는 인증을 마친 쪽만 보낼 수 있어야 하는 정보를 외부에서도 그대로 흉내 낼 수 있었다는 뜻이고, 서버는 그걸 의심 없이 받아준 셈임. 구체적인 필드나 요청 형태는 공개 자료 범위를 넘어서 다루지 않겠음. 방어하는 입장에서는 그 디테일보다 내 환경에서 그 문이 바깥을 향해 열려 있는가가 훨씬 중요하기 때문임.

2. 왜 원격지원 제품에서 특히 위험한가

BeyondTrust Remote Support는 이전에도 공격자들이 노린 이력이 있는 제품군임. 이유는 단순함. 이 장비 하나가 수많은 사내 PC와 서버에 화면 제어, 파일 전송, 명령 실행을 할 수 있는 통로이다 보니, 공격자 눈에는 엔드포인트 수백 대로 들어가는 마스터키처럼 보이는 것임.

• 인증이 우회되면 상담원 권한으로 세션을 열거나 설정을 바꾸는 시나리오가 가능해질 수 있음
• 정상 원격지원 트래픽과 섞이기 때문에 EDR이나 네트워크 장비에서 이상 행위로 튀지 않을 가능성이 큼
• 외부 고객 지원 때문에 인터넷에 노출된 채 운영되는 경우가 많아서 스캐닝 대상이 되기 쉬움

3. 탐지 — 지금 로그에서 볼 것

패치를 하기 전이든 후든, 이미 누가 다녀갔는지 보는 작업은 따로 해야 함. 개인적으로는 아래 순서로 보는 걸 추천함.

• 인증 로그와 세션 로그의 불일치: 로그인 성공 기록 없이 시작된 상담원 세션, 혹은 평소 쓰지 않는 계정으로 열린 세션이 있는지 확인
• 출발지 IP 패턴: 상담원들이 실제로 접속하는 사내·VPN 대역 밖에서 관리 기능에 접근한 흔적이 있는지 확인
• 설정 변경 이력: 신규 계정 생성, 권한 상승, API 계정·키 발급, 점프 클라이언트 배포 같은 변경이 공지 시점 전후로 있었는지 확인
• 비정상 시간대: 지원 업무가 없는 새벽·주말에 시작된 세션이나 파일 전송
• 엔드포인트 측 흔적: 원격지원 클라이언트 프로세스가 자식 프로세스로 셸이나 스크립트 엔진을 띄운 기록

로그를 SIEM으로 보내고 있지 않았다면 어플라이언스 내부 보존 기간이 짧을 수 있으니, 지금 바로 원본 로그부터 백업해두는 게 좋음.

4. 완화 — 패치와 그 주변

• 벤더 권고 패치 적용: BeyondTrust 클라우드 호스팅 고객은 자동으로 반영되는 경우가 있지만, 온프레미스 어플라이언스는 직접 업데이트해야 하는 경우가 많으니 반드시 버전을 확인할 것
• 관리 인터페이스 노출 축소: 고객용 포털과 상담원·관리자용 인터페이스를 분리하고, 관리 쪽은 VPN이나 허용 IP로만 접근하게 묶기
• 프록시·로드밸런서 설정 재검토: 앞단 장비가 클라이언트 헤더를 그대로 전달하고 있다면, 외부에서 들어온 신원·출처 관련 헤더는 덮어쓰거나 제거하도록 정리
• 자격 증명 교체: 침해 흔적이 조금이라도 의심되면 관리자 계정, API 키, 연동 계정 비밀번호를 일괄 교체
• MFA와 세션 승인 정책 강화: 우회 자체를 막지는 못하더라도, 이후 단계의 권한 행사를 한 번 더 걸러주는 효과가 있음

5. 이번 건에서 챙겨갈 교훈

스푸핑 기반 인증 우회는 코드 한 줄의 실수라기보다는 신뢰 경계를 어디에 그었느냐의 문제인 경우가 많음. "이 값은 내부에서만 오니까 괜찮다", "앞단 프록시가 걸러주겠지" 같은 가정이 겹겹이 쌓이다 보면 결국 아무도 검증하지 않는 값이 생기는 것 같음. 우리 쪽에서 직접 만드는 서비스도 마찬가지라서, 이번 기회에 클라이언트가 보낸 값을 그대로 신원 판단에 쓰는 곳이 없는지 같이 돌아보면 좋겠음.

원격지원 솔루션을 운영 중이라면 오늘 안에 버전 확인부터 해보아요! 탐지 쿼리를 짜다가 막히는 부분이나 환경별로 다르게 본 지점이 있다면 댓글로 공유해주세요. 차차 모아서 정리해보겠음.