Exchange Online의 Ghost-Sender 결함: DMARC에 더해 점검해야 할 것

Ghost-Sender는 Microsoft Exchange Online이 수신 메일을 받아들이는 방식에서 새롭게 문서화된 결함입니다. 이 결함을 악용하면 공격자는, 위조 메일을 잡아내야 할 인증 검사를 모두 통과하지 못했음에도, 동료나 신뢰할 수 있는 브랜드에서 온 것처럼 보이는 위조 이메일을 받은 편지함에 전달할 수 있습니다. 보안 연구진 InfoGuard는 2026년 6월 9일 이 기법을 공개했으며, Microsoft는 이를 수정할 계획인 버그가 아니라 알려진 아키텍처상의 한계로 분류했습니다.

이 결함은 수신 메일이 Microsoft 365에 도달하기 전에 서드파티 스팸 필터를 거치도록 라우팅하는 조직에 영향을 미칩니다. 이러한 구성은 흔하며, 특히 IT를 대행사나 서비스 제공업체가 관리하는 기업에서 자주 볼 수 있습니다. DMARC 시행(enforcement)은 스푸핑에 대한 일반적인 방어책이지만, 이 공격은 막지 못합니다. 위조 메일이 DMARC 판정이 적용되지 않는 경로로 들어오기 때문입니다. 아래 섹션에서는 이 기법이 어떻게 작동하는지, 인증만으로는 왜 막을 수 없는지, 그리고 이 틈을 막는 Microsoft 365 설정이 무엇인지 설명합니다.

이 가이드의 내용

• Ghost-Sender 결함이란 무엇인가?
• 공격자는 어떻게 Exchange Online의 필터링을 우회하는가
• 왜 SPF, DKIM, DMARC는 이를 잡아내지 못하는가?
• Microsoft의 대응: '알려진 아키텍처상의 한계'
• 당신은 노출되어 있는가? Exchange Online 설정을 확인하는 방법
• 지금 해야 할 일: 실질적인 완화 조치
• 실질적인 요점

Ghost-Sender 결함이란 무엇인가?

Ghost-Sender는 위조 이메일을 Microsoft 365 받은 편지함으로 전달하는 기법입니다. 메일은 신뢰할 수 있는 동료나 잘 알려진 브랜드에서 온 것처럼 가장합니다. 인증 검사는 그 주장을 거짓으로 판정하지만, Exchange Online은 그럼에도 메일을 전달합니다.

InfoGuard 연구진은 2026년 6월 9일 이 기법을 공개했습니다. 이들의 테스트에서 noreply@microsoft.com에서 온 것처럼 가장한 메일이 모든 검사에서 실패 결과를 받고도 받은 편지함에 도달했습니다. SPF는 실패했고, DKIM은 서명되지 않았으며, DMARC도 실패했습니다. 보통 이런 결과는 메일이 거부되거나 스팸 폴더에 들어감을 의미합니다. 그러나 이 메일은 전달되었습니다.

이 기법에는 탈취한 비밀번호도, 대상 도메인의 DNS 변경도 필요하지 않습니다. Exchange Online이 수신 메일을 라우팅하는 방식을 악용하기 때문에, SPF, DKIM, DMARC 레코드가 모두 올바르게 구성된 도메인에 대해서도 작동합니다.

공격자는 어떻게 Exchange Online의 필터링을 우회하는가

많은 조직은 도메인의 메일 레코드를 Microsoft로 곧장 향하게 하지 않습니다. 그 앞에 서드파티 보안 게이트웨이, 즉 Proofpoint, Mimecast, Barracuda 같은 공급업체의 스팸·멀웨어 필터를 둡니다. 이들의 MX 레코드(메일을 어디로 전달할지 세상에 알리는 DNS 항목)는 그 필터를 가리키며, Microsoft를 가리키지 않습니다. 메일은 한 방향으로 흘러야 합니다. 인터넷에서 필터로, 필터에서 Microsoft로, Microsoft에서 받은 편지함으로 흐르는 것입니다.

문제는 Microsoft 자체의 전달 주소가 그동안 계속 접근 가능한 상태로 남아 있다는 점입니다. 모든 Microsoft 365 조직(Microsoft 용어로 '테넌트')은 yourdomain.mail.protection.outlook.com 형식의 직접 전달 주소를 가지며, 인터넷상의 누구로부터든 메일을 받아들입니다. 이 주소로 보내는 공격자는 Exchange Online에 직접 도달하여 외부 필터를 완전히 건너뜁니다. 필터는 그 메일을 한 번도 보지 못하므로, 스푸핑 방지나 피싱 방지 규칙 중 어느 것도 작동하지 않습니다.

메일이 Microsoft 자체 인프라를 통해 도착하기 때문에, Exchange Online은 이를 열린 인터넷에서 오는 메일보다 더 신뢰하여 처리합니다. 이 잘못 놓인 신뢰가 결함의 핵심입니다.

왜 SPF, DKIM, DMARC는 이를 잡아내지 못하는가?

SPF, DKIM, DMARC는 메일이 정말로 From 주소의 도메인에서 왔는지 판단하기 위해 수신 메일 서버가 실행하는 검사입니다. 이들은 도메인 스푸핑에 대한 핵심 방어이며, 그 대부분을 막아냅니다.

Ghost-Sender는 이 검사들을 무력화하지 않습니다. 검사 결과가 적용되는 전달 지점을 우회합니다. 위조 메일은 InfoGuard의 테스트가 보여준 대로 실제로 세 가지 모두에서 실패합니다. 그러나 메일은 이미 Microsoft의 직접 전달 주소에서 수락되었고, Exchange Online은 내부로 취급하는 메일에 동일한 DMARC 시행을 적용하지 않습니다. 인증 판정은 'fail'이지만, 메일은 그래도 전달됩니다.

그렇다고 DMARC가 선택 사항이라는 뜻은 아닙니다. DMARC는 여전히 일상적인 스푸핑을 막는 통제 수단입니다. 위조된 공급업체 청구서, 경영진을 사칭한 송금 요청, Exchange 엔드포인트에 전혀 닿지 않는 유사 도메인 피싱 등이 그 대상입니다. Ghost-Sender는 좁은 범위의 아키텍처상 예외이며, 그 아래에서 DMARC가 필요한 이유를 조금도 바꾸지 않습니다.

이런 방식으로 위조된 메일은 애초에 깨끗한 인증을 유지하기 어려운 인프라에 도달합니다. DMARCeye의 2026년 1분기 산업 보고서에 따르면, Microsoft 인프라에 귀속된 메일의 컴플라이언스는 90.0%였고, SPF는 메일의 26.6%에서, DKIM은 19.6%에서 실패했습니다. Microsoft를 통해 발송되는 정상 메일의 상당 부분이 이미 깨끗하게 인증되지 않습니다. 1분기 보고서가 지적하듯, 대형 제공업체에서의 낮은 컴플라이언스는 거의 항상 플랫폼 자체의 결함이 아니라 발신자 측의 구성 문제입니다. 흔한 원인은 올바른 DKIM 키를 DNS에 추가하지 않은 고객이거나, 발송 규모가 SPF 레코드의 범위를 넘어선 고객입니다.

요점은 Microsoft의 메일이 취약하다는 것이 아닙니다. 요점은 Microsoft 365 메일 흐름을 올바르게 구성하기가 복잡하다는 것이며, Ghost-Sender는 수신 라우팅이 구성된 방식의 한 가지 특정한 틈을 파고듭니다.

전체 보고서는 아래에서 다운로드할 수 있습니다.

Microsoft의 대응: '알려진 아키텍처상의 한계'

InfoGuard는 2026년 4월 21일 이 문제를 Microsoft에 보고했습니다. Microsoft는 다음 날 내부 완화 조치를 배포했다가 4월 27일에 이를 철회했습니다. 2026년 5월 29일, Microsoft는 Ghost-Sender를 제품 취약점이 아니라 알려진 아키텍처상의 한계로 분류했으며, 그 시점에 플랫폼 차원의 수정은 없었습니다.

실제로 이는 틈을 막을 책임이 자동으로 도착하는 패치가 아니라 각 조직에 있음을 의미합니다. Microsoft는 관련 기본값을 강화하고 있으며, 신규 테넌트에서는 공격이 의존하는 기능인 Direct Send가, Microsoft가 2026년 초에 배포를 시작한 변경에 따라 기본적으로 거부됩니다. 기존 테넌트는 관리자가 변경할 때까지 현재 구성을 유지합니다.

외부 필터와 함께 Microsoft 365를 운영한다면, 수정이 도착하기를 기다릴 수 없습니다. 직접 구성을 확인하고 조정해야 합니다.

당신은 노출되어 있는가? Exchange Online 설정을 확인하는 방법

다음 두 가지가 모두 참이면 노출되어 있을 수 있습니다. 조직이 Microsoft 365(또는 하이브리드 모드의 Exchange)를 사용하고, 도메인의 MX 레코드가 Microsoft로 직접이 아니라 서드파티 필터를 가리키는 경우입니다. 전용 보안 게이트웨이를 Microsoft 앞에 두는 것은 흔한 설계이므로, 이는 관리 대상 테넌트의 상당 부분에 해당합니다.

InfoGuard의 스캔에 따르면, 버그 바운티 프로그램을 통해 테스트한 Exchange Online 도메인의 20% 이상이 취약한 것으로 보였고, 외부 MX 레코드를 사용하는 환경 중 절반 미만만이 어떤 완화 조치라도 갖추고 있었습니다.

테넌트를 확인하려면 세 가지 질문을 차례로 검토하세요.

• MX 레코드는 어디를 가리키는가? *.mail.protection.outlook.com 외의 다른 곳을 가리킨다면, 메일은 서드파티를 거쳐 라우팅되며 Microsoft로의 직접 엔드포인트는 여전히 노출되어 있습니다.
• 수신 커넥터가 제한되어 있는가? Exchange 관리 센터에서 수신 커넥터를 검토하세요. 발신자를 IP 범위나 TLS 인증서로 제한하는 커넥터가 이 틈을 막는 통제 수단입니다. 그러한 제한이 없다면 테넌트는 열려 있을 가능성이 높습니다.
• Direct Send가 활성화되어 있는가? Direct Send는 인증 없이 메일이 사서함에 도달하도록 합니다. 이것이 켜져 있고 이를 보완하는 전송 규칙이 없다면, 위조 메일이 통과할 수 있습니다.

지금 해야 할 일: 실질적인 완화 조치

두 가지 구성이 Ghost-Sender를 확실히 차단하며, Microsoft 자체의 Direct Send 제어 기능이 세 번째 계층을 더합니다.

1. 수신 커넥터를 제한하세요. 파트너 조직 수신 커넥터를 임의의 도메인에서 오는 메일에 적용되고 IP 범위 또는 TLS 인증서 검증을 통과한 메시지만 수락하도록 만들거나 조정하세요. 이렇게 하면 Exchange Online에 수신 메일을 필터의 주소에서 오는 것만 신뢰하고, 직접 전달 주소를 찾아낸 누구도 신뢰하지 말라고 지시하게 됩니다.
2. 내부처럼 보이는 신뢰할 수 없는 메일을 격리하세요. 최우선(우선순위 0) 전송 규칙을 추가하여, 승인된 원본에서 온 X-MS-Exchange-Organization-AuthAs: Internal 헤더를 지니지 않았거나 승인된 IP 범위에서 오지 않은 모든 수신 메시지를 격리하세요. 쉽게 말해, 이는 내부인 척하지만 신뢰할 수 있는 경로로 도착하지 않은 메일을 잡아냅니다.
3. Direct Send를 끄세요. Direct Send는 장치와 앱이 인증 없이 테넌트를 통해 메일을 보낼 수 있게 하는 Microsoft 365 기능입니다. 이를 비활성화하면(RejectDirectSend 설정) Ghost-Sender가 악용하는 특정 경로가 제거됩니다. 먼저 정상적인 프린터, 스캐너, 업무용 앱이 인증된 커넥터를 사용하는지 확인하세요.

이것은 DMARC 문제가 아니라 Microsoft 365 구성 문제이며, 해결책도 Microsoft 365에 있습니다. DMARC 모니터링이 더하는 것은 가시성입니다. 위조 메일이 SPF, DKIM, DMARC에 실패해도 Microsoft는 그 실패를 기록하여 여러분의 DMARC 집계 보고서에 포함합니다. 이 보고서를 대신 읽어주는 도구는 여러분이 알아보지 못하는 원본에서 여러분의 도메인을 사칭해 발송된, 인증에 실패한 위조 메일을 보여줍니다. 이것이 바로 Ghost-Sender 같은 기법이 여러분을 겨냥해 사용되고 있다는 신호입니다. DMARCeye의 무료 요금제는 도메인 하나를 지원하며, 이 보고서의 원시 데이터를 누가 여러분을 사칭해 발송하고 무엇이 실패하는지 쉬운 말로 보여주는 화면으로 바꿔 줍니다.

지금 바로 여러분의 도메인이 무엇을 게시하고 있는지 확인하려면, 현재 DMARC 레코드부터 시작하세요.

실질적인 요점

이메일 보안은 계층으로 작동하며, 단일 계층이 모든 것을 다루지는 못합니다. DMARC는 필수적인 핵심입니다. From 주소의 도메인을 인증하고, 이메일 사기의 대부분을 차지하는 넓은 범주의 스푸핑을 막습니다. 이 결함은 그 핵심을 약화시키지 않습니다. 이 결함이 드러내는 것은 다른 계층, 즉 Microsoft 365가 자체 내부 메일 흐름에 두는 신뢰입니다. DMARC는 이 계층을 관리하도록 설계된 적이 없으며, 이를 보호할 수 있는 것은 오직 여러분의 Microsoft 365 구성뿐입니다.

대행사와 IT 제공업체에게 클라이언트에게 전할 메시지는 두 가지를 동시에 담습니다. DMARC 시행은 스푸핑의 대부분을 막으므로 유지하고, DMARC가 닿지 못하는 Exchange Online의 틈은 막으라는 것입니다.

이 두 부분으로 이루어진 답이 우리가 가장 중요하다고 여기는 일입니다. DMARCeye는 누가 자신의 도메인을 사칭해 발송하는지 명확히 볼 수 있게 하고, 스푸핑과 그것이 초래하는 실제 위험, 그리고 효과가 있는 해결책을, 이번처럼 DMARC 자체의 범위를 넘어서는 것까지 포함하여 설명하기 위해 존재합니다.