CVE-2026-22769 백업 인프라를 침입의 거점으로 만드는 하드코딩된 크리덴셜

사람들이 CVE-2026-22769를 긴급하게 검색하는 이유

보안 엔지니어들은 학문적으로 흥미로워서 CVE-2026-22769를 찾아보는 것이 아닙니다. 희귀하고 위험한 교차점에 해당하기 때문에 찾아보는 것입니다:

최대 심각도 운영 영향(Dell은 이를 매우 중요하게 평가하며, NVD도 동일한 핵심 내용을 담고 있습니다). (Dell)
신뢰할 수 있는 특권 제품 클래스백업 및 복구 인프라는 이미 VMware 환경에 깊이 침투해 있습니다. (Dell)
적극적인 악용에 대한 신뢰할 수 있는 증거 Google의 위협 팀과 Mandiant가 조사한 실제 침입과 관련이 있습니다. (Google 클라우드)
CISA KEV 포함를 사용하면 "곧 패치"가 "지금 패치한 다음 증명"으로 바뀝니다. (CISA)

프로덕션 환경을 분류하는 경우 실제적인 질문은 예측할 수 있습니다:

우리는 취약한가요?
위험한 곳에서도 접속할 수 있나요?
우리가 공격당한 징후가 있습니까?
가장 빠른 안전한 해결 방법은 무엇인가요?
면밀한 조사를 견딜 수 있는 증거를 생성하는 방법

이 글은 이러한 질문을 중심으로 벤더 및 위협 인텔 소스를 사실적인 기준으로 삼아 정리했습니다.

AI 해커 도구 체험하기 >>

CVE-2026-22769의 실제 내용

가장 명확한 표준 정의는 공급업체 자문에서 나온 것이며 NVD 및 CVE.org:

가상 머신용 Dell RecoverPoint(RP4VM), 버전 6.0.3.1 HF1 이전 버전를 포함하는 하드코딩된 자격 증명 취약점. Dell이 이 문제를 중요하게 생각하는 이유는 다음과 같습니다. 하드코딩된 자격 증명을 알고 있는 인증되지 않은 원격 공격자가 이 취약점을 악용하여 기본 운영 체제에 대한 무단 액세스 및 루트 수준의 지속성을 초래할 수 있습니다.. Dell은 가능한 한 빨리 업그레이드하거나 해결 방법을 적용할 것을 권장합니다. (Dell)

이 문장이 중요한 이유는 위험에 대해 추론하는 방법을 알려주기 때문입니다:

이것은 돌발적인 충돌 버그가 아닙니다. 자격 증명이 알려지면 예측 가능한 인증 우회 설계입니다.
"루트 수준 지속성"은 "하나의 명령"이 아닙니다. 재부팅 후에도 지속되는 기능입니다.
'인증되지 않은' 부분은 초기 액세스에 관한 것입니다. 관리 플레인에 도달할 수 있는 경우 장벽이 크게 낮아집니다.

NVD는 또한 약점 클래스에 다음과 같이 태그를 지정합니다. CWE-798 하드코딩된 자격증명 사용노출을 줄이고, 액세스를 순환 및 무효화하고, 시스템을 계층 0에 인접한 자산처럼 취급하는 등 완화에 적합한 정신 모델입니다. (NVD)

검색 및 알림에서 방어자가 부르는 이름

사람들이 이 CVE와 관련하여 사용할 가능성이 높은 "클릭률이 가장 높은" 용어를 요청하셨습니다. 표준처럼 인용할 수 있는 단일 CVE 키워드에 대한 공개적이고 권위 있는 CTR 피드는 없지만, 주요 권고 및 보도에서 해당 인시던트를 일관되게 표현하는 방식을 살펴봄으로써 의도성이 높은 키워드 집합의 근거를 마련할 수 있습니다:

벤더, KEV 및 평판이 좋은 보안 미디어에서 나타나는 일반적인 고의성 검색 패턴은 다음과 같습니다:

"CVE-2026-22769" + "가상 머신용 리커버포인트" + "RP4VM"(NVD)
"하드코딩된 자격증명" / "하드코딩된 자격증명"(CWE-798 언어)(Dell)
"야생에서 악용됨" + "UNC6201"(위협 클러스터)(Google 클라우드)
"CISA KEV" + "마감일 2026-02-21"(CISA)
"톰캣 매니저" / "/매니저"(맨디언트가 강조 표시한 조사 신호)(Google 클라우드)

SEO/GEO에 최적화하는 경우 이러한 문구는 노출, 익스플로잇 현실, 패치/치료, 사고 대응 등 사용자 의도와 명확하게 매핑됩니다.

AI 펜테스트 도구 체험 >>

백업 및 복구 인프라에서 하드코딩된 자격 증명이 더 나쁜 이유

하드코딩된 자격 증명은 항상 위험합니다. 두 가지 구조적인 이유로 인해 재해 복구 및 백업 시스템에서 특히 치명적입니다.

백업 도구는 설계상 신뢰 경계 내에 있습니다.

가상 머신용 RecoverPoint는 VMware 환경 내에서 데이터 보호 및 재해 복구 솔루션으로 작동하도록 설계되었습니다. 즉, 일반적으로 그렇다는 뜻입니다:

권한 있는 액세스 경로
심층 네트워크 인접성
무작위 인바운드 익스플로잇 시도보다 '관리 트래픽'을 덜 의심하게 만드는 운영 적법성

Dell의 자체 권고에 따르면 이러한 시스템은 신뢰할 수 없는 네트워크에 노출되지 않고 세분화 및 방화벽 제어 기능이 있는 신뢰할 수 있는 내부 네트워크에만 배포해야 한다고 강조합니다. 이러한 지침은 이 제품의 특권적인 위치를 조용히 인정하는 것입니다. (Dell)

자격 증명 도용은 메모리 손상보다 더 은밀하게 이루어집니다.

Mandiant/GTIG는 공격자가 관리 표면에 액세스하고 Tomcat 관련 경로 및 배포 동작을 사용한 침입 조사에 대해 설명합니다. 이는 특정 탐지가 없는 경우 관리자 트래픽에 섞일 수 있다는 점에서 크래싱 익스플로잇 체인과는 운영적으로 다릅니다. (Google 클라우드)

익스플로잇 실태 점검

"야생에서"를 마케팅 언어로 취급해서는 안 됩니다. 이 CVE의 경우 여러 독립적인 신호에 의해 지원됩니다:

구글의 맨디언트와 GTIG는 다음과 같이 추적된 중국-넥서스 위협 클러스터로 의심되는 익스플로잇을 보고했습니다. UNC6201활동이 관찰된 경우 최소 2024년 중반 이후. (Google 클라우드)
NVD는 이를 반영합니다. CISA KEV 에는 CVE-2026-22769가 포함되어 있으며, CISA의 카탈로그 항목에 따르면 마감일: 2026-02-21. (NVD)
CISA는 또한 2026년 2월 18일에 KEV 카탈로그에 취약점을 추가하는 것에 대한 경고를 발표했습니다. (CISA)

중요한 뉘앙스입니다: "제한된 활동적 익스플로잇"은 "낮은 영향력"을 의미하지 않습니다. 이는 종종 고도로 숙련된 공격자가 전략적 접근을 위해 선택적으로 사용하고 있다는 의미이며, 이는 맨디언트의 보고 스타일과 보고서의 맞춤형 툴링 이름과도 일치합니다. (Google 클라우드)

영향을 받는 범위 및 수정된 모습

공급업체 자문은 영향을 받는 버전 및 수정 대상에 대한 신뢰할 수 있는 출처입니다:

영향을 받습니다: 가상 머신용 Dell RecoverPoint 이전 버전 6.0.3.1 HF1. (Dell)
대상 수정: 로 업그레이드 6.0.3.1 HF1 를 클릭하거나 문서에 설명된 대로 Dell의 해결 방법을 적용합니다. (Dell)

또한 Dell은 재부팅이 필요하지 않고, 스크립트가 주요 작업을 중단하지 않으며, 어플라이언스당 실행 시간이 짧다는 점에 주목하여 문제 해결 스크립트를 적용하는 방법을 설명하는 전용 기술 자료 문서도 제공합니다. (Dell)

이는 실제 기업에게 중요한데, 전체 업그레이드 기간을 계획할 시간이 필요한 경우에도 완화할 수 있는 경로를 제시합니다.

가장 빠른 안전한 분류 계획

이 섹션은 의도적으로 방어적입니다. 이 섹션은 악용이 아닌 증명, 인벤토리 및 로그 고정 확인에 중점을 둡니다.

1단계 RP4VM이 존재하는 인벤토리

패치에 대해 이야기하기 전에 보유하고 있는 인스턴스의 수와 위치를 파악해야 합니다. 나중에 '잊혀진 어플라이언스 하나'를 발견하면 시간과 신뢰성을 잃게 됩니다.

최신 자산 검색 플랫폼이 있다면 이를 사용하세요. 그렇지 않은 경우에도 실용적인 검색을 수행할 수 있습니다:

CMDB 항목 검색
VMware 인벤토리 노트 검색
내부 DNS에서 RecoverPoint/RP4VM 명명 패턴 쿼리하기
RP4VM 서브넷을 참조하는 방화벽 개체 검토

RunZero는 RecoverPoint 배포를 찾아 6.0.3.1 HF1로 업그레이드의 우선 순위를 지정하거나 즉시 업그레이드할 수 없는 경우 Dell 문제 해결 스크립트를 적용하는 방법에 대한 지침을 게시했습니다. (runZero)

CVE-2026-22769 백업 인프라를 침입의 거점으로 만드는 하드코딩된 크리덴셜

원클릭 PoC 받기 >>

2단계 버전 및 핫픽스 수준 확인

목표는 인스턴스당 하나의 질문에 답하는 것입니다:

현재 수준 또는 그 이상입니까? 6.0.3.1 HF1
그렇지 않은 경우, Dell의 문제 해결 스크립트가 해당 KB에 따라 적용되나요?

티켓 및 감사 패킷에 첨부할 수 있는 작은 증거 표를 만드세요:

RP4VM 인스턴스	위치	버전	핫픽스	관리자 서브넷에서만 연결 가능	수정 사항 적용	증거 아티팩트
rp4vm-01	DC1	6.0.3.1	HF1	예	업그레이드	스크린샷 + CLI 출력
rp4vm-02	DC2	6.0.2.x	n/a	예	스크립트	KB 스크립트 로그 + 티켓 ID

'증거 아티팩트' 열은 향후 논쟁을 방지하는 기능입니다.

CVE-2026-22769 백업 인프라를 침입의 거점으로 만드는 하드코딩된 크리덴셜

원클릭 PoC 받기 >>

3단계 관리 영역 노출 검증하기

신뢰할 수 없는 네트워크에서 시스템에 연결할 수 있는 경우 하드코딩된 자격 증명 문제가 쉬운 초기 액세스 벡터가 되는 최악의 경우를 강력하게 시사하는 Dell의 권고입니다. 신뢰할 수 있는 내부 네트워크에 배포하고 세그먼트화하세요. (Dell)

실질적으로 이는

RP4VM 관리 표면에 대한 인바운드 액세스를 전용 관리자 서브넷으로 제한합니다.
사용자 네트워크에서 접속할 수 있도록 하는 모든 NAT 또는 프록시 노출을 제거합니다.
모든 액세스를 기록하세요. 로그를 기록하지 않으면 안전하다는 것을 증명할 수 없습니다.

4단계 Mandiant가 참조하는 고신호 경로 찾기

Mandiant의 보고서에는 증거가 발견된 위치와 관찰된 웹 요청 유형에 대한 세부 정보가 포함되어 있어 방어자에게 매우 유용합니다.

침해 전 웹 요청 관찰에 대해 설명하고 Tomcat Manager를 통한 관리 엔드포인트 및 배포 동작에 대해 논의합니다. (Google 클라우드)

또한 분석에 사용된 로그 위치 및 구성 아티팩트를 참조합니다. (Google 클라우드)

올바른 접근 방식은 비밀 문자열이 아닌 '관리자 표면의 악용 신호'를 찾는 것입니다.

지금 바로 운영할 수 있는 탐지 및 헌팅 패턴

다음은 Splunk, Elastic 또는 Sentinel에 적용할 수 있는 예제입니다. 이는 의심스러운 관리 엔드포인트 사용 및 이상 징후 패턴을 찾는 방어적 쿼리입니다.

Splunk에서 Tomcat 관리자 액세스 찾기

index=웹 OR index=어플라이언스 OR index=프록시
(uri_path="/관리자" OR uri_path="/관리자/" OR uri_path="/관리자/text" OR uri_path="/관리자/html")
| 통계는 조회수로 계산
        min(_time) as first_seen
        max(_time) as last_seen
        values(src_ip) as src_ips
        values(user)를 사용자로
        values(status)를 statuses로
  by host, uri_path, http_method
| convert ctime(first_seen) ctime(last_seen)
| 정렬 - 조회수

플래그를 지정할 항목:

모든 /관리자 관리자 서브넷 외부에서의 액세스
GET만 예상하는 경우 POST/PUT 패턴
의심스러운 변경 또는 중단과 연관된 모든 시간대

이는 맨디언트가 강조하는 관리 표면 활동과도 일치합니다. (Google 클라우드)

역방향 프록시 HTTP 로그를 위한 KQL 패턴

HttpRequest
| 여기서 Url에 "/manager"가 있는 경우
| summarize Hits=count(),
            FirstSeen=min(TimeGenerated),
            LastSeen=최대(시간 생성),
            SrcIPs=make_set(SrcIp, 25),
            Users=make_set(User, 25),
            Statuses=make_set(StatusCode, 25)
  호스트, URL, 메서드
| 히트 desc 순으로 정렬

Sentinel에 RP4VM 로그가 없는 경우, 관리 액세스가 통과하는 프록시, WAF 또는 네트워크 원격 분석에 대해 이 로그를 실행하세요.

침해가 의심되는 경우의 인시던트 대응 지침

보안 침해가 의심되는 경우 우선순위를 정해야 합니다:

추가 액세스 중지
증거 보존
범위 폭발 반경
지속성 메커니즘 확인
자격 증명 교체 및 신뢰 재구축

Mandiant의 보고서는 후속 멀웨어 제품군 및 지속성 동작을 포함하여 조사 중에 발견된 침입 활동에 대해 설명합니다. (Google 클라우드)

이것이 실질적인 교훈입니다. 악용된 백업 어플라이언스는 그렇지 않다는 것을 증명할 때까지 제어 영역 침해로 취급하세요.

수집할 가치가 높은 증거 카테고리

증거 카테고리	중요한 이유	위치의 예
관리 액세스 로그	관리자 엔드포인트의 의심스러운 액세스 여부를 확인합니다.	RP4VM 웹/감사 로그, 프록시 로그, 방화벽 로그(Google 클라우드)
구성 무결성	하드코딩된 자격 증명 문제는 종종 구성 파일 및 서비스 사용자에게 매핑됩니다.	조사자가 참조하는 Tomcat 구성 아티팩트(Google 클라우드)
아티팩트 변경	승인되지 않은 웹앱 배포 또는 비정상적인 파일	웹앱 디렉터리, 타임스탬프, 패키지 히스토리(Google 클라우드)
시작 및 지속성	루트 지속성은 부팅 시간 변경을 의미합니다.	rc.local 등가물, 수정된 스크립트 및 크론 작업(Google 클라우드)
네트워크 비콘	C2 패턴 확인	NDR, DNS 로그, 송신 프록시 원격 분석(Google 클라우드)