핵심 요약
- 마이크로소프트 보안 연구팀은 짐브라(CVE-2026-73570) 취약점을 이용한 공격자가 다수 조직의 메일 서버에 JSP 웹셸을 여러 경로에 심고, 서비스 계정 비밀값·LDAP 사전 인증 키·인증 토큰 키·2FA 비밀값 등 인증 비밀값을 일괄 탈취했다고 분석했다.
- 이 결함은 SNMP 알림을 켜고 zimbra-snmp 선택 패키지가 설치된 서버에서 인증 없이 운영체제 명령을 실행할 수 있는 RCE로 이어지며, CVSS 등급이 ‘심각(High)’으로 분류된다.
- 공격 단계는 ①7월 28일~8월 7일 두 종의 스캐너로 명령 실행 여부 사전 확인 ②짐브라 서비스 계정으로 명령 실행 및 JSP 웹셸 다중 배치 ③sudo 설정 변경으로 무제한 관리자 권한 확보 ④zimlog.service 등록으로 재부팅 후에도 지속성 유지 ⑤기존 SSH 키로 클러스터 내부 횡적 이동 ⑥Zimclient2 설치로 SOCKS5 프록시·대화형 셸 확보 ⑦메일함 테이블 내보내기 및 애저 블롭 스토리지 유출 시도로 나타났다.
한 차례의 인증 우회가 단일 메일함이 아니라 서버 전체의 비밀값 저장소와 클러스터로 확산된 사례를 통해, 인증 비밀값 평문 보관과 SNMP 의존 설계가 어떻게 침투 면적을 키우는지를 짚고, 패치·비밀값 회전·잔여 웹셸 점검의 3축 대응 절차를 제시한다.
목차
7월 28일부터 8월 7일까지, 마이크로소프트 보안 연구팀은 여러 조직의 짐브라 Collaboration 메일 서버에서 같은 패턴의 침해 흔적을 연속으로 잡아냈다. 표적은 개별 사서함이 아니라 서버 자체였다. CVE-2026-73570라는 짐브라 취약점을 통과한 공격자는 서비스 계정 비밀값, LDAP 사전 인증 키, 2FA 비밀값을 한 번에 모아갔고, 클러스터 안의 다른 노드까지 횡적으로 이동했다.
짐브라 취약점 CVE-2026-73570의 작동 구조
이 짐브라 취약점은 짐브라 서버에서 SNMP 알림을 켜고 zimbra-snmp 선택 패키지를 설치한 경우, 인증 없이 운영체제 명령을 실행할 수 있는 RCE로 이어진다. CVSS 등급은 ‘심각(High)’. SNMP 설정이 켜지기 전에는 막혀 있던 길이, 그 옵션이 활성화되는 순간 운영체제 셸까지 직통하게 된다. 실무자 입장에서 눈에 띄는 건, 이 결함이 ‘잘못된 코드 한 줄’이 아니라 ‘운영 옵션과 패키지가 만든 조합’이라는 사실이다. 즉 기본 설치 습관만으로도 위험 경로가 열린다.
7단계 공격 타임라인
마이크로소프트가 정리한 흐름은 크게 7단계다.
- 7월 28일~8월 7일: 두 종의 스캐너로 명령 실행 가능 여부 사전 확인
- 짐브라 서비스 계정 권한으로 명령 실행, JSP 웹셸을 여러 경로에 동시 배치
- sudo 설정 변경으로 무제한 관리자 권한 확보
- zimlog.service 등록으로 재부팅 후에도 지속성 유지
- 기존에 남아 있던 SSH 키로 클러스터 내부 횡적 이동
- Zimclient2 설치로 SOCKS5 프록시·대화형 셸 확보
- 메일함 테이블 내보내기 및 애저 블롭 스토리지 유출 시도
짐브라 취약점을 통한 이번 공격은 단순 침투가 아니라, 한 번 들어온 뒤 시스템 안에서 권한과 키를 차례로 모으는 ‘라이브 오프 더 랜드’ 패턴이라는 점이 핵심이다.
핵심 침해 흔적 4가지
눈여겨볼 흔적은 권한 상승과 지속성 확보 방식이다. sudo 설정 변경은 짐브라의 운영 계정 권한 모델 자체를 무너뜨린 흔적이고, zimlog.service 등록은 서비스 단위 자동 재실행 경로를 새로 만든 흔적이다. 기존 SSH 키를 재사용해 클러스터 안 다른 노드로 들어간 점은, 한 대의 패치만으로 전체 침해를 끝낼 수 없다는 사실을 분명히 보여준다.
마이크로소프트는 짐브라가 한곳에 모아 둔 서비스 비밀값과 인증 비밀값을 탈취한 뒤 LDAP 조회로 연관 키를 추출했다고 분석했다. 메일함 개별 비밀번호 자체는 직접 노려지지 않았다. 일부 사례에서는 공개 디렉터리 쓰기 권한을 임시로 풀어 웹셸을 심은 뒤 원상복구해, 기본적인 권한 점검을 우회한 정황도 포착됐다.
도구와 유출 시도: Zimclient2와 AzCopy
Zimclient2는 SOCKS5 프록시와 대화형 셸을 함께 제공해 공격자가 내부 망에서 본격적으로 움직일 수 있는 발판이 됐다. MySQL과 LDAP을 직접 조회해 키를 모았고, AzCopy를 통해 애저 블롭 저장소로 메일함 백업을 전송하려는 시도도 있었다. 다만 마이크로소프트는 애저 블롭 전송이 실제로 완료됐는지에 대한 증거는 확인되지 않았다고 밝혔다. 필자는 유출 시도가 멈춘 건지, 단지 증거가 안 남은 건지 판단하기는 이르다고 본다.
다른 메일 솔루션 취약점과의 비교
이번 짐브라 취약점은 특수한 단일 사건이 아니다. BleepingComputer에 따르면 포티넷 FortiMail에서도 CVE-2026-104286(CVSS 9.8, 패스 트래버설+NULL 바이트 결합) 제로데이 공격이 실환경에서 확인됐다. 메일·협업 영역에서 결함이 연속 노출되는 양상이다.
| 항목 | 짐브라 CVE-2026-73570 | FortiMail CVE-2026-104286 |
|---|---|---|
| 공격 표면 | SNMP/zimbra-snmp 옵션 | 웹 메일 관리 경로 |
| CVSS | High | 9.8 (Critical) |
| 악용 형태 | 인증 우회 RCE | 패스 트래버설 + NULL 바이트 |
| 실환경 악용 공개 | 8월, 폴란드 CERT | 제로데이 형태로 보고 |
| 주요 위험 | 서버 비밀값 저장소 통째 탈취 | 관리자 권한 탈취 및 명령 실행 |
실무 적용 포인트
- 이번 짐브라 취약점에서도 확인되듯, SNMP 의존 옵션은 ‘켜져 있는가’만으로 침투 경로가 된다. 기본값 비활성화를 운영 정책으로 못 박아야 한다.
- 권한 상승 흔적은 sudo 설정 변경에서 나타난다. /etc/sudoers와 관련 파일 무결성 모니터링이 필요하다.
- 지속성 확보 단서인 zimlog.service는 ‘직접 만든 서비스 등록’ 흔적이다. 비표준 systemd unit을 주기적으로 감사한다.
- 메일본문 비밀번호가 직접 노려지지 않았어도, LDAP 키와 2FA 비밀값이 유출되면 2차 침해 가능성이 계속된다.
지금 바로 해볼 것
- 짐브라 취약점 패치가 포함된 짐브라 10.1.20 이상으로 즉시 업데이트하고, 그 이하 버전은 네트워크에서 분리한다.
- zimbra-snmp 패키지를 제거하고 SNMP 알림 옵션을 비활성화한 뒤 재부팅한다.
- SNMP, SMTP 접근을 신뢰 호스트와 내부 관리 대역으로만 제한하고 방화벽 규칙을 재검토한다.
- 짐브라가 보관 중인 LDAP 사전 인증 키, 인증 토큰 키, 2FA 비밀값을 전량 회전하고 사용자 비밀번호도 함께 재발급한다.
- /opt/zimbra, 웹루트, 임시 디렉터리에서 JSP 웹셸과 비표준 systemd unit을 전수 점검한다.
보안 공지 시점과 책임 기관
짐브라 측은 7월 10.1.20 버전으로 패치를 배포했고, 폴란드 CERT가 8월 실환경 악용을 최초 공개했다. 미국 CISA는 연방기관에 8월 24일까지 조치할 것을 지시했다. 이번 짐브라 취약점의 공격 노출 시점과 패치 배포 시점 사이의 시차를 보면, 내부 자산 인벤토리에서 짐브라 버전을 즉시 조회할 수 있는지가 대응 속도를 가른다.
자주 묻는 질문
짐브라 취약점 CVE-2026-73570는 어떤 종류의 결함인가요?
SNMP 알림을 켜고 zimbra-snmp 패키지가 설치된 환경에서 인증 없이 운영체제 명령을 실행할 수 있는 RCE 결함입니다. CVSS 등급은 ‘심각(High)’으로 분류됩니다.
메일함 사용자 비밀번호도 직접 유출되나요?
이번 캠페인에서는 메일함 개별 비밀번호 자체가 직접 노려지지는 않았습니다. 대신 서비스 계정 비밀값, LDAP 사전 인증 키, 인증 토큰 키, 2FA 비밀값이 일괄 탈취됐고, LDAP 조회를 통해 연관 키가 추가로 추출됐습니다.
패치만 적용하면 안전한가요?
아닙니다. 공격자는 zimlog.service 등록과 SSH 키 재사용으로 클러스터 전반에 흔적을 남길 수 있습니다. 패치 후에는 인증 비밀값 회전, 잔존 웹셸 점검, 클러스터 전체 감사가 함께 진행돼야 합니다.
FortiMail CVE-2026-104286과는 무엇이 다른가요?
FortiMail 사례는 패스 트래버설과 NULL 바이트를 결합한 웹 경로 결함(CVSS 9.8)이고, 이번 짐브라 취약점은 SNMP 옵션에 의존한 인증 우회 RCE입니다. 표면과 트리거는 다르지만 메일·협업 영역에서 결함이 연속으로 노출되는 공통된 양상이 있습니다.
참고 원문
이 기사는 다음 원문을 확인해 작성했습니다: 보안뉴스 — 메일함 대신 서버 노렸다… 짐브라 취약점 악용 공격, 인증 비밀값까지 털어
전문가 코멘트(AI)
정보보안전문가
선택적 패키지와 운영 옵션 조합으로 열리는 RCE는 메일 서버 비밀값 관리 체계 전반의 구조적 취약성을 드러낸 사건
CVE-2026-73570의 기술적으로 주목할 부분은 코드 결함 자체보다 SNMP 옵션 활성화와 zimbra-snmp 패키지 설치라는 운영자의 선택이 공격 표면을 만든다는 점이다. 이는 ‘기본 설치가 곧 안전하다’는 가정이 성립하지 않는 협업 소프트웨어의 통변 문제이며, 선택 패키지의 커맨드 처리 경입에 대한 위협 모델링이 부족했다는 반증이다. 공격이 서비스 계정 비밀값, LDAP 키, 2FA 시드를 일괄 수집한 점은 짐브라가 평문에 가까운 형태로 비밀값 저장소를 집중 보관하는 설계가 침해 시 피해 규모를 극대화함을 보여준다. sudo 구성 변경과 SSH 키 재사용 기반 횡적 이동까지 성공한 것은 메일 서버 계정에 과도한 로컬 권한이 위임된 운영 관행의 취약성이며, 패치 적용 후에도 전량 비밀값 회전과 클러스터 전수 감사가 없으면 재침해가 사실상 확정되는 구조다. 우려되는 점은 CVSS를 High로 분류했으나 인증 없는 RCE이면서 조직 전체 인증 자산 탈취로 이어지는 실제 피해 규모를 고려하면 위험 등급 산정이 피해 잠재력을 과소 반영할 수 있다는 것이다.
클라우드·이메일 인프라 운영 전문가
패치·비밀값 회전·잔존 웹셸 점검 3축 대응은 타당하나, 클러스터 구조와 스니핑 가능한 Credential 저장 이슈는 여전히 원천 봉쇄가 아닌 사후 대응에 머문다
이 캠페인이 보여주는 인프라 리스크의 핵심은 단일 노드 침해가 클러스터 전체로 확산된다는 점이다. 메일·협업 서버는 내부 네트워크 위치상 SSH 키나 sudo 설정이 클러스터 공용으로 관리되기 쉬운데, 이번 사례는 그 공용 신뢰 모델이 공격자에게 횡적 이동 채널로 작동함을 실증했다. zimbra-snmp 비활성화, LDAP 2FA 시드와 토큰 키 전량 회전, 비표준 systemd unit 감사라는 대응 절차는 실무적으로 실행 가능하나, 애저 스토리지 유출 시도에도 불구하고 Egress 방화벽이 AzCopy 형태의 정상 도구 전송을 차단하지 못했다는 점은 아웃바운드 제어의 사각지대를 드러낸다. 또한 메일함 테이블이 MySQL 형태로 로컬에 내보내기 가능했다는 것은 저장 구조 자체가 대량 유출에 취약한 배치 설계임을 의미하므로, 저장 계층 암호화와 테이블 접근 제어 도입이 요구된다. 조직 입장에서 짐브라 버전 인벤토리를 즉시 조회할 수 있는지가 대응 속도를 가른다는 점은 자산 관리가 여전히 가장 현실적인 방어 병목임을 재확인한다.
비판적 분석가
비밀값 통째 탈취, 애저 유출 시도, 스캐너 사전 검증이라는 구성은 단순 범죄 수익보다 조직화된 인텔리전스 수집 또는 공급망 선점 목적일 가능성을 시사한다
하지만 이면을 들여다보면 이 캠페인은 경제적 범죄 패턴과 어긋나는 지점이 여럿이다. 메일함 개별 비밀번호는 노리지 않았고 서비스 비밀값과 LDAP 키만 SUV처럼 수집했다는 것은, 범죄자보다는 내부 인증 체계 자체를 이해하는 주체의 손길로 읽힌다. 유출 수단으로 Azure Blob Storage를 골랐다는 점도 흥미로운데, 정상적인 클라우드 트래픽으로 위장해 Egress 필터를 통과하기 쉬운 경로를 선택했다는 점에서 전술적 세련됨이 배경 조직의 존재를 암시한다. 우리가 진작 주목해야 할 점은 7월 28일부터 8월 7일까지 10일간 반복 스캐닝과 단계적 배치라는 인내심이다. 이는 감염 증거를 최소화하며 지속 접근을 유지하려는 APT 스타일 운영 패턴이며, 마이크로소프트가 블롭 전송 완료 증거를 확인하지 못했다는 문구는 사실상 ‘이미 나갔는지 모른다’는 뜻으로 봐야 한다. 마지막으로 스스로에게 물어야 한다 — 폴란드 CERT 최초 공개와 CISA 연방기관 마감 지시 사이의 시간 차, 그리고 왜 공격 시작일 7월 28일은 패치 배포 시점보다 앞서는지, 이 타이밍 구도는 누구에게 이득인가.
물밑 시나리오
- 공격 초기 발견 시점(7월 28일)이 공식 패치 공개 이전이라는 정황은 이 결함 정보가 제로데이 시점부터 특정 주체에 의해 유통됐을 가능성을 시사하며, 이메일 협업 서버 비밀값은 범죄 수익보다 국가 단위 인텔리전스 목적에 더 부합한다.
- AzCopy + Azure Blob 조합은 클라우드 제공자의 정상 스트리지로 위장한 중간자 인프라일 가능성이 있으며, 블롭 전송 완료 증거 미확인 문구는 실제 유출이 성공했으나 증거가 이미 소거됐을 공산을 배제하기 어렵다.
- 여러 조직이 10일간 연속 동일 패턴으로 침해된 것은 다수 표적의 공통 인프라 취약점을 안다는 전제를 요하므로, 공급망 또는 패치 배포 채널 어딘가 정보가 새어나갔을 가능성도 배제할 수 없다.
답글 남기기