최소 5개월간 악용된 Zimbra 제로데이는 공격자가 인증된 세션 안에 들어온 뒤 어떤 일이 벌어지는지 드러냅니다.
SSO와 MFA 같은 신원 확인 수단은 로그인한 주체를 검증합니다. 일부는 위험 신호가 바뀌면 세션을 즉시 종료할 수도 있습니다. 하지만 특정 동작이 세션을 연 목적에 맞는지 판단하지는 않습니다. 최소 5개월간 악용된 Zimbra 웹메일 제로데이는 이런 판단이 없을 때 어떤 일이 일어나는지 드러냅니다. 공격자가 이미 인증된 세션에 들어오면, 그 세션에 허용된 동작을 그대로 이어갈 수 있습니다. 로그인 강도만 높여서는 해결되지 않습니다. 로그인 뒤에도 동작을 계속 판단해야 합니다.
MFA를 지나간 제로데이
Zimbra는 Zimbra Collaboration Suite Classic Web Client의 저장형 크로스 사이트 스크립팅(XSS) 취약점인 CVE-2025-66376을 패치했습니다. 조작된 HTML 이메일은 클라이언트의 CSS @import 규칙 처리 방식을 악용했습니다. display:none div 안에 <svg onload> 태그를 숨긴 뒤, 가짜 @import 지시문으로 태그를 나눠 필터를 통과시켰습니다. 그 결과 피해자가 이미 로그인한 웹메일 세션 안에서 JavaScript가 실행됐습니다.
Zimbra는 2025년 11월 6일 패치를 배포했습니다. Proofpoint에 따르면 이 그룹은 패치 전인 2025년에 최소 5개월 동안 이 취약점을 제로데이로 악용했습니다. 활동은 패치 후 수개월이 지난 2026년 2월까지 관찰됐습니다.
배후 그룹의 귀속은 아직 확정되지 않았습니다. TA488, CL-STA-1114, LAUNDRY BEAR, Void Blizzard라는 이름이 함께 쓰이지만, 보도는 이 이름들이 일대일로 대응하지 않을 수 있다고 설명합니다. Seqrite는 2026년 1월의 별도 사례를 중간 신뢰도로 APT28과 연결했습니다. 네덜란드 정보기관은 두 행위자를 별개로 봅니다. CISA는 2026년 3월 18일 이 취약점을 Known Exploited Vulnerabilities 목록에 추가했습니다.
세션 탈취는 이미 신원 확인을 통과한 세션을 가로채는 공격입니다. 공격자는 그 세션에 허용된 작업 권한을 이어받으며, 이 과정에서 MFA 프롬프트는 뜨지 않습니다. ZimReaper라는 이름이 붙은 페이로드는 CSRF 토큰과 브라우저 자동완성 비밀번호를 훔쳤습니다. 흔한 세션 탈취 행위입니다. 여기에 더해 Zimbra 자체 API에서 2FA 복구 코드를 가져오고, ZimbraWeb이라는 앱 전용 비밀번호를 만들었습니다. 이 비밀번호만 있으면 2차 인증이 전혀 필요 없이 IMAP, POP3, SMTP에 접근할 수 있습니다.
공격자는 MFA를 우회할 필요가 없었습니다. MFA는 로그인 시점에 사람을 확인하는 역할을 이미 마쳤고, 그 결과 만들어진 세션이 탈취됐습니다. 복구 코드를 빼내고 2차 인증 없는 메일 자격증명을 만든 일은 초기 침투 단계가 아니라, 이미 세션 안에 있던 공격자가 계정에 부여된 신뢰를 이용해 수행한 후속 작업이었습니다.
다른 경로로 나타난 같은 문제
관련 Zimbra 취약점인 CVE-2025-27915는 Zimbra 9.0–10.1에서 ICS 캘린더 첨부파일을 통한 저장형 XSS로 스크립트를 실행하고 메일 리디렉션을 설정했습니다. 첨부파일 유형은 달랐지만, 필터의 빈틈을 통과한 스크립트가 살아 있는 세션에서 실행되는 구조는 같습니다. Zimbra는 2026년 7월 10.1.20 릴리스에서도 Classic Web Client의 XSS 취약점 네 건을 추가로 수정했습니다. 이 제품군에서는 같은 유형의 문제가 계속 발견되고 있습니다.
2026년에 확인된 다른 악성코드 계열에서도 구조는 비슷합니다. ChonkyChicken은 Golden Chickens(TAG-195 / Venom Spider) 서비스형 악성코드 운영이 쓰는 2단계 임플란트입니다. 원격 디버깅을 켠 브라우저를 보이지 않게 띄우고, Chrome의 App-Bound Encryption을 우회하는 보조 도구를 써서 이미 인증된 세션을 제어합니다. 이 방식으로 공격자는 이미 인증된 브라우저 세션을 대화형으로 제어할 수 있습니다.
비밀번호를 재설정해도 이 통제가 사라지지 않을 수 있습니다. 공격자가 애초에 그 사용자로 인증한 적이 없기 때문입니다. 공격자는 사용자가 이미 인증해 둔 세션을 이용했을 뿐입니다. 서버는 탈취된 세션 토큰도 유효한 신원 증명으로 보기 때문에 MFA 프롬프트가 뜨지 않습니다.
신원 확인 뒤에도 남는 세션 내 동작 판단
Zimbra와 ChonkyChicken은 웹메일과 브라우저에서 발생한 사건입니다. 인프라 셸에서 일어난 사건은 아닙니다. 하지만 이 사례가 드러낸 공백은 이메일 클라이언트나 브라우저에만 국한되지 않습니다. 신원 확인 수단 전반에 존재하는 한계입니다. SSO와 MFA는 로그인 주체를 확인합니다. 신원 플랫폼은 이제 토큰이 유효한 중간에도 세션을 다시 평가할 수 있습니다. 예를 들어 Microsoft Entra의 Continuous Access Evaluation은 위험 신호가 바뀌면 그렇게 세션을 종료합니다.
Cloud Security Alliance의 agentjacking 연구는 같은 문제를 AI 에이전트 관점에서 설명합니다. 에이전트는 개발자 신원으로 허가된 동작을 수행합니다. 그래서 기존 엔드포인트 및 네트워크 통제 대부분은 이 공격 유형을 다루도록 설계되지 않았습니다. 이런 동작은 모두 허가된 것으로 보이기 때문입니다. 세션이 인증되면 이후 동작도 기본적으로 그 인증을 물려받습니다.
신원 확인만으로 충분하지 않아 실행 제어를 별도 계층으로 둡니다. 정책 계층은 신원이 어디까지 접근할 수 있는지 정합니다. 세션이 열려 있는 동안 실제로 실행되는 동작은 별도 계층에서 계속 판단해야 합니다. PAM 셸도 정적 허용 목록과 차단 목록으로 명령을 걸러냅니다. 그러나 규칙 목록만으로는 그 명령이 세션을 연 목적에 맞는지 판단할 수 없습니다.
AI 에이전트 세션에서 같은 패턴이 나타나는 방식
웹메일에서 보인 패턴은 프로덕션 환경에서 일하는 AI 에이전트에도 적용됩니다. 에이전트의 자격증명이 검증되고 범위가 부여된 상태에서 공격자가 세션을 탈취하거나 인젝션으로 개입하면, 이미 허가된 자격증명의 권한을 이어받습니다. 이후 동작도 이미 통과한 자격증명 아래에서 승인된 것으로 처리됩니다. 이는 ZimReaper가 웹메일 세션의 신뢰를, ChonkyChicken이 브라우저 세션의 신뢰를 이어받은 방식과 같습니다. 위험 신호가 바뀌면 Continuous Access Evaluation이 세션을 끊을 수는 있습니다. 그러나 신원 확인만으로는 지금 하려는 동작이 세션을 연 목적에 속하는지 판단하지 못합니다.
에이전트의 경우 Alpacon 실행 제어 계층은 세션 시작뿐 아니라 세션 안에서도 판단을 이어 갑니다. 동적 권한은 세션별로 에이전트가 실행할 수 있는 범위를 정합니다. Alpacon 명령 API나 MCP를 통해 실행되는 명령은 세션이 선언한 목적을 기준으로 평가됩니다. 위험 점수가 불확실한 구간에 들어간 명령은 실행 전에 별도 채널의 사람 승인을 위해 보류될 수 있습니다.
마무리
SSO와 MFA는 필요하지만, 그것만으로 충분하지는 않습니다. 지난 1년의 세션 탈취 사례는 이 공백이 이론만의 문제가 아니었음을 보여 줍니다. 최소 5개월간 악용된 제로데이, 애플리케이션 자체 API에서 가져간 복구 코드, 사후에 만들어 MFA를 전혀 요구하지 않는 앱 전용 비밀번호, 브라우저의 원격 디버깅 인터페이스로 탈취된 이미 인증된 브라우저 세션이 있었습니다. 어느 경우에도 신원 확인을 깨뜨릴 필요는 없었습니다. 공격자에게 필요했던 것은 신원 확인을 통과한 세션 안으로 들어가는 일이었습니다.
보안 모델이 "사용자가 인증됐다"를 끝으로 본다면, 다음으로 점검할 곳은 그 이후 세션 안에서 수행되는 동작입니다.
