TTESays

글로벌 메일 인프라 공격 연대기가 한국에 던지는 질문 Part1

Donghwi Shin, Jin Kwak

Published: 08:00, 23 Mar 2026 (Updated: 02:33, 11 Apr 2026)

Photo by Le Vu / Unsplash

💡

Editor Pick
- 공격자에게 매력적인 메일 서비스의 의미와 위치
- 글로벌 메일 서비스/인프라의 취약점 활용한 공격
- 메일 서비스에 대한 침해는 일반적인 서비스 침해와 상이

보안 분야에서 메일은 오래된 기술로 취급된다. 기업의 디지털 인프라가 클라우드와 협업 플랫폼 중심으로 재편되었지만 메일은 과거에도 현재에도 가장 보편적인 커뮤니케이션 도구이다. 그러나 공격자의 관점에서 메일은 여전히 조직 내부로 들어가기 위한 가장 효율적인 통로 가운데 하나이며, 실제 공격 사례를 살펴보면 이 사실은 꾸준히 반복되어 왔다.

메일은 단순히 메시지를 전달하는 시스템이 아니다. 계정 생성 알림, 비밀번호 재설정, 승인 요청, 외부 협력사와의 문서 교환, SaaS 서비스 인증까지 대부분의 업무 흐름이 메일을 중심으로 작동한다. 조직 내부에서 신뢰 관계가 형성되는 지점 역시 메일이다. 누군가에게 문서를 보내고, 승인을 요청하고, 외부 파트너와 협력하는 과정에서 메일은 일종의 기본 통신 계층처럼 작동한다. 이 때문에 메일 계정을 장악하는 것은 단순히 편지함을 읽는 것 이상의 의미를 가진다. 공격자는 조직의 커뮤니케이션 흐름과 인증 구조, 그리고 내부 신뢰 체계에 동시에 접근할 수 있게 된다.

이러한 특성 때문에 메일은 오래된 기술임에도 불구하고 Attack Surface에서 한 번도 내려온 적이 없다. 오히려 지난 10여 년 동안의 보안 사건을 살펴보면 메일 인프라는 지속적으로 새로운 방식의 공격을 받아 왔으며, 공격 기술 역시 점점 정교해지고 있다.

위와 같은 배경에 메일 서비스/인프라에 대한 상황을 Par1과 Part2로 나누어 살펴보고자 한다.

메일 서버는 단순한 메시지 전달 시스템이 아니다

메일 인프라 공격의 흐름을 이해하기 위해서는 먼저 메일 시스템이 어떤 구조를 갖고 있는지를 살펴볼 필요가 있다. 일반적으로 기업 메일 환경은 단일 시스템이 아니라 여러 계층으로 구성된다. 메일을 전달하는 MTA(Mail Transfer Agent), 사용자가 접근하는 웹메일 플랫폼, 그리고 Outlook이나 Thunderbird와 같은 메일 클라이언트 애플리케이션이 각각 다른 역할을 수행하면서 하나의 생태계를 이룬다. 중요한 점은 이 모든 계층이 외부 입력을 처리한다는 사실이다. 메일은 본질적으로 인터넷을 통해 전달되는 데이터이며, 이 데이터는 헤더, MIME 구조, 첨부파일, HTML 콘텐츠 등 다양한 형태로 구성된다. 이 복잡한 파싱 과정이 바로 메일 인프라를 공격 표면으로 만드는 핵심 지점이다.

대표적인 사례가 2019년에 발견된 Exim 취약점이다. Exim은 전 세계 인터넷 메일 서버의 상당 비율에서 사용되는 MTA이며, 당시 발견된 CVE-2019-10149 취약점은 SMTP(Simple Mail Transfer Protocol) 메시지 처리 과정에서 발생한 입력 검증 오류로 인해 원격 코드 실행(RCE, Remote-code Execution)이 가능했다. 공격자는 특정 SMTP명령을 조작해 메일 서버가 의도하지 않은 방식으로 명령을 실행하도록 유도할 수 있었고, 실제로 이 취약점은 단순 연구 단계에 머무르지 않았다. 미국과 영국 보안 당국은 이 취약점이 러시아 군 정보기관(GRU)과 연계된 공격 조직, 특히 Sandworm과 같은 그룹에 의해 활용되었을 가능성을 지적한 바 있다. 이들은 취약한 메일 서버를 스캔한 뒤 웹쉘을 설치하거나 추가 악성코드를 배포하는 방식으로 초기 침투를 수행했고, 이후 내부 네트워크로 이동하는 공격을 전개했다. 즉 MTA 취약점은 단순한 서비스 취약점이 아니라 외부에서 내부로 진입하는 1차 침투 벡터로 활용된 것이다.

이와 같은 공격 패턴은 MTA에만 국한되지 않는다. 웹메일 플랫폼 역시 유사한 방식으로 공격 대상이 되어 왔다. 예를 들어 Roundcube 웹메일에서는 반복적으로 XSS와 RCE 취약점이 발견되었으며, 러시아 연계 공격 조직으로 알려진 APT28은 이를 활용해 외교 및 정부 기관을 대상으로 한 Operation RoundPress 공격을 수행한 것으로 알려졌다. 이 공격에서 사용된 방식은 비교적 단순하지만 효과적이었다. 공격자는 악성 스크립트가 포함된 이메일을 전달하고, 사용자가 웹메일을 통해 해당 메일을 열람하는 순간 브라우저 세션을 탈취하거나 인증 토큰을 획득했다. 이후 공격자는 피해자의 계정으로 로그인해 메일 규칙을 변경하거나 추가 공격을 수행했다. 여기서 중요한 점은 서버를 직접 장악하지 않더라도 웹메일 계층만으로도 계정 장악과 내부 정보 접근이 가능하다는 점이다.

메일 클라이언트 애플리케이션 역시 예외가 아니다. 2023년에 공개된 Outlook 취약점 CVE-2023-23397은 메일을 열지 않아도 공격이 가능한 사례였다. 공격자가 특수한 MAPI(Messaging Application Programming Interface) 속성을 포함한 이메일을 전송하면 Outlook이 자동으로 공격자의 SMB 서버에 인증 요청하고 이를 통해 NTLM 해시가 유출되었다. 이 취약점은 특히 위험했던 것이 사용자 상호작용이 필요 없었다는 점이다. 메일을 수신하는 것만으로 공격이 성립하며, 공격자는 탈취한 인증 정보를 이용해 내부 네트워크 접근이나 추가 인증 우회를 시도할 수 있었다. 실제로 이 취약점은 국가 단위 공격 조직에 의해 적극적으로 활용된 것으로 보고되었다.

이 세 가지 사례의 공통점은 메일 인프라는 단일 시스템이 아니라는 점과 여러 계층으로 구성되어 있다는 점을 착안하여, 공격자는 특정 제품이 아닌 전체 구조를 표적으로 삼았다는 것이다. MTA는 외부에서 내부로 진입하는 통로가 되고, 웹메일은 사용자 세션과 계정을 탈취하는 지점으로 활용되었으며, 메일 클라이언트는 인증 정보를 유출하는 역할을 담당했다. 각각의 계층은 서로 다른 취약점을 가지지만, 공격자는 이를 연결해 하나의 공격 체인으로 만든 것이다.

결국 메일 서비스 관련 서비스들은 단순한 메시지 전달 시스템이 아니다. 그것은 외부 입력을 받아 내부 네트워크와 연결하는 복합적인 처리 시스템이며, 그 구조 자체가 공격자에게는 매우 매력적인 진입점이다. 그리고 이 진입점은 생각보다 자주, 그리고 다양한 방식으로 열리고 있다.

Exchange 사건이 보여준 메일 공격의 현실

메일 인프라 공격이 얼마나 큰 영향을 미칠 수 있는지를 보여준 사건은 2021년 Microsoft Exchange 취약점 사건이다. 이 사건에서 공격자들은 ProxyLogon으로 알려진 취약점 체인을 활용했다. ProxyLogon은 단일 취약점이 아니라 여러 취약점이 연결된 공격 시나리오였다. 공격자는 먼저 SSRF(Server-Side Request Forgery) 취약점을 이용해 Exchange 서버의 내부 API에 접근한다. 이후 인증 우회를 통해 관리자 권한을 획득하고, 파일 업로드 취약점을 이용해 웹쉘을 설치한다. 이렇게 설치된 웹쉘은 공격자가 서버를 원격으로 제어할 수 있는 백도어 역할을 한다.

이 공격이 위험했던 이유는 단순히 메일 서버가 침해되었기 때문이 아니다. 많은 조직에서 Exchange 서버는 내부 네트워크 깊숙한 곳에 위치하며, Active Directory와 긴밀하게 연결된 핵심 인프라로 운영된다. 공격자가 Exchange 서버에 웹쉘을 설치하면 그 서버는 곧바로 내부 네트워크 공격의 출발점이 된다. 실제 공격 사례를 보면 이 구조가 분명히 드러난다. 공격자들은 Exchange 서버에 웹쉘을 설치한 뒤 단순히 메일 데이터를 탈취하는 데서 멈추지 않았다. 먼저 서버에서 PowerShell 명령을 실행해 Active Directory 정보를 수집했고, 이후 관리자 계정이나 서비스 계정의 인증 정보를 확보하려고 시도했다. 일부 공격에서는 LSASS 프로세스 메모리를 덤프해 자격 증명을 추출하거나, Kerberos 티켓을 이용한 Pass-the-Ticket 공격이 수행되기도 했다.

또 다른 공격 흐름에서는 메일 서버를 통해 내부 네트워크 스캔이 이루어졌다. 공격자는 Exchange 서버에서 netstat, nltest, dsquery 같은 관리 도구를 사용해 도메인 구조와 내부 서버 목록을 파악했다. 이후 SMB나 WinRM 같은 관리 프로토콜을 통해 다른 서버로 이동하는 Lateral Movement가 이루어졌다. 이 과정에서 메일 서버는 단순한 서비스 서버가 아니라 내부 네트워크로 들어가는 중간 거점(Pivot Point)으로 활용되었다. 실제로 Exchange 침해 이후 랜섬웨어 공격으로 이어진 사건도 적지 않았다. 공격자는 Exchange 서버를 통해 내부 관리자 권한을 확보한 뒤 파일 서버나 백업 서버를 장악하고, 최종적으로 랜섬웨어를 배포하는 방식으로 공격을 확장했다.

또 하나 중요한 점은 메일 서버가 조직의 외부 통신 허브라는 사실이다. 대부분의 조직에서 메일 서버는 인터넷과 직접 연결되어 있으며 외부와 지속적으로 통신한다. 따라서 공격자가 메일 서버를 장악하면 내부 네트워크에 대한 접근뿐 아니라 데이터 유출 채널까지 확보하게 된다. 실제로 Exchange 사건 이후 많은 조직에서 메일 서버를 통한 장기간 데이터 유출이 뒤늦게 발견되기도 했다. 이 사건은 메일 서버가 단순한 메시지 전달 시스템이 아니라 조직 네트워크의 전략적 거점이라는 사실을 명확히 보여주었다. 메일 서버는 외부와 연결되어 있으면서도 내부 인증 시스템과 깊이 연결된 몇 안 되는 시스템이다. 바로 그 지점에서 공격자에게는 매우 매력적인 공격 표면이 된다.

메일 취약점의 기술적 패턴

글로벌 메일 서비스 공격 사례를 분석하면 몇 가지 기술적 패턴이 반복적으로 등장한다. 가장 대표적인 것은 원격 코드 실행 취약점이다.

원격 코드 실행 취약점 (RCE)

RCE는 공격자가 서버에서 임의 코드를 실행할 수 있는 취약점이다. 메일 서버가 외부 입력을 대량으로 처리하고 내부 네트워크와 연결되어 있기 때문에 공격자 입장에서 중요 입무를 부여할 수 있기 때문에 RCE 취약점의 발견은 심각한 문제를 야기할 수 있다. 그리고 단순히 하나의 서비스를 제공하는 서버가 아니며 메일 서버가 담고 있는 데이터와 그 의미가 가볍지 않기 때문에 RCE가 공격자게에 가져다 주는 이득이 막강하다.

메일 서비스에서 확인된 대표적인 RCE 취약점 사례로는 다음과 같은 취약점이 있다.

Exim RCE (CVE-2019-10149)
Zimbra RCE (CVE-2024-45519)
Roundcube RCE (CVE-2025-49113)

이러한 취약점은 주로 이메일 파싱 과정에서 발생한다. 예를 들어 MIME 구조를 처리하는 코드에서 버퍼 관리 오류가 발생하거나, 첨부파일 처리 과정에서 명령 실행이 발생하는 경우가 있다. 웹메일 환경에서는 서버 측 스크립트가 사용자 입력을 처리하는 과정에서 코드 실행 취약점이 발생하기도 한다.

인증 및 세션 관련 공격

메일 서비스에 대해 관심있게 지켜봐야 하는 공격 유형은 인증 체계를 노리는 것이다. 대표적인 사례가 Outlook 취약점 CVE-2023-23397으로 사용자가 메일을 열지 않아도 공격이 가능하다는 점에서 주목을 받았다. 공격자는 특수한 메시지 속성을 포함한 메일을 보내 Outlook이 공격자의 SMB 서버로 자동 인증을 수행하도록 만들 수 있었다. 이 과정에서 NTLM 인증 해시가 유출되으며 공격자는 이 정보를 내부 시스템의 인증 우회에 사용할 수 있었다. 해당 취약점은 Fighting Ursa라는 해킹 조직이 우크라이나 공격에 사용된 것으로 알려져 있다.

인증 및 세션 관련 공격이 많이 발생하는 메일 관련 서비스는 웹메일이다. 웹 메일 플랫폼 역시 중요한 Attack Surface이며 대형 웹 애플리케이션이다. 웹을 기반으로 하기 때문에 인증 및 세션 관련 취약점 이외에도 웹 서비스에서 발생 가능한 다양한 취약점이 다음과 같이 확인 된다.

Cross-Site Scripting (XSS)
Injection 취약점
인증 우회
파일 업로드 취약점

Roundcube 웹메일에서도 이러한 취약점들이 여러 차례 발견되었으며 특히 APT28 공격 조직은 Roundcube 취약점을 활용한 Operation RoundPress 공격을 수행한 것으로 알려졌다.

ESET Research uncovers Operation RoundPress: Russia-aligned Sednit targets entities linked to the Ukraine war to steal confidential data ( 출처 : ESET )

프로토콜 자체도 공격 대상이 된다

메일 보안에서 상대적으로 덜 주목받았지만 다시 부각되고 있는 영역이 있다. 바로 프로토콜 자체를 이용한 공격이다. 대표적인 사례가 SMTP Smuggling이다. 이 공격은 특정 소프트웨어의 버그를 이용하는 것이 아닌, 메일을 전달하는 과정에서 서로 다른 서버가 메시지를 해석하는 방식의 차이를 이용한다.

SMTP는 이메일을 전달하기 위한 표준 프로토콜이다. 메일은 하나의 서버에서 다른 서버로 전달되는 방식으로 여러 단계를 거쳐 목적지에 도달한다. 이 과정에서 메일은 일정한 규칙에 따라 구분된다. 예를 들어 SMTP에서는 메시지의 끝을 나타낼 때 CRLF.CRLF(줄바꿈 + 마침표 + 줄바꿈)와 같은 구문을 사용한다. 문제는 이 규칙을 모든 서버가 동일하게 해석하지 않는다는 점이다.

SMTP Smuggling은 바로 이 지점을 노린다. 공격자는 하나의 SMTP 세션 안에 두 개의 메시지를 교묘하게 섞어서 전송한다. 첫 번째 서버는 이를 하나의 정상적인 메시지로 처리하지만, 다음 단계의 서버는 이를 두 개의 메시지로 분리해 해석한다. 이때 두 번째 메시지는 보안 필터를 거치지 않은 상태로 전달될 수 있다. 공격 흐름을 단순화하면 다음과 같다.

공격자는 SMTP 메시지 내부에 추가적인 메시지 경계를 삽입한다.
최초 수신 서버(MTA)는 이를 하나의 메시지로 인식한다.
중간 또는 최종 서버는 동일한 데이터를 두 개의 메시지로 해석한다.
두 번째 메시지는 기존 보안 정책을 우회한 상태로 전달된다.

이 공격이 위험한 이유는 보안 장비의 동작 방식과도 관련이 있다. 대부분의 메일 보안 시스템은 최초로 수신되는 메시지를 기준으로 스팸 필터링, 악성코드 검사, 정책 검증을 수행한다. 그러나 메시지가 중간 단계에서 분리되면, 분리된 두 번째 메시지는 이러한 검사 과정을 거치지 않을 수 있다. 결과적으로 공격자는 정상적인 메일 전송 과정 안에 숨겨진 두 번째 메시지(Hidden Payload)를 삽입할 수 있게 된다. 이 메시지는 스팸 필터를 우회하거나, 악성 링크를 포함하거나, 내부 사용자를 대상으로 한 피싱 공격에 활용될 수 있다.

더 중요한 점은 이 공격이 특정 제품 하나의 취약점이 아니라는 것이다. SMTP Smuggling은 프로토콜 구현 차이에서 발생한다. 따라서 Postfix, Sendmail, Exim 등 서로 다른 메일 서버가 조합되어 있는 환경에서 특히 효과적으로 작동한다. 즉 공격자는 특정 기업의 시스템을 노리는 것이 아니라, 서로 다른 시스템이 연결된 구조 자체를 공격하는 것이다.

이와 같은 프로토콜의 문제점으로 비추어 보면 메일 보안은 특정 소프트웨어에 대한 보안 패치만으로 해결되는 문제가 아니라는 점을 알 수 있다. 특히 메일이 다양한 서버와 네트워크를 거쳐 전달되는 이상, 그 과정에서 발생하는 해석 차이는 필연적으로 Attack Surface가 된다. SMTP Smuggling은 이러한 프로토콜 취약점을 가장 잘 보여주는 사례라고 할 수 있다. 🆃🆃🅔