기술·트렌드

메일 게이트웨이가 거래처 사칭 BEC 메일을 놓치는 이유 — 페스트페이스가 설명하는 관계 기반 피싱 분석

스팸·악성코드·악성 URL은 메일 게이트웨이가 잘 막지만, 거래처 사칭 BEC 메일에는 걸러낼 요소가 없습니다. 게이트웨이가 놓치는 이유와, 과거 메일 이력과 비교하는 관계 기반 분석이 왜 함께 필요한지 정리했습니다.

메일 게이트웨이가 거래처 사칭 BEC 메일을 놓치는 이유 — 페스트페이스가 설명하는 관계 기반 피싱 분석

메일 보안 게이트웨이는 스팸, 악성 첨부파일, 악성 URL처럼 메일 한 통 안에서 판단할 수 있는 위협을 수신 시점에 잘 막습니다. 그러나 거래처 사칭·BEC 메일은 악성코드도 수상한 링크도 없이 정상 업무 메일의 형태로 오기 때문에, 메일 한 통만 보는 게이트웨이에는 차단할 근거가 부족합니다. 저희는 "이 메일이 위험한가"를 보는 게이트웨이와 "이 관계가 평소와 같은가"를 보는 관계 기반 분석이 함께 있어야 최근의 정교한 기업 피싱을 막을 수 있다고 봅니다.

핵심 요약

  • BEC(Business Email Compromise)란 거래처나 임직원을 사칭한 메일로 송금이나 계좌 변경을 유도하는 기업 대상 이메일 사기입니다.
  • 메일 게이트웨이는 발신자 평판, 첨부파일, URL, SPF·DKIM·DMARC 인증처럼 지금 들어온 메일 한 통의 속성을 검사합니다.
  • 거래처 사칭 메일은 company.com 대신 company-co.com처럼 유사 도메인을 쓰고, 첨부와 링크 없이 계좌 변경만 요청하므로 이 검사에 걸릴 것이 없습니다.
  • 위험 신호는 "3년 동안 거래하던 담당자가 왜 처음 보는 도메인에서 계좌 변경을 요청하는가"처럼 과거 메일 이력과 비교해야 드러납니다.
  • 게이트웨이와 관계 기반 분석은 대체 관계가 아니라 보완 관계입니다.

메일 보안 게이트웨이는 무엇을 검사하나

메일 보안 게이트웨이란 외부에서 들어오는 메일을 수신 시점에 검사해 스팸, 악성 첨부파일, 악성 URL, 알려진 악성 발신자를 차단하는 장비입니다. 발신자 평판은 어떤지, 첨부파일이 악성인지, URL이 위험한지, SPF·DKIM·DMARC 인증에 문제가 없는지를 확인합니다. SPF·DKIM·DMARC란 메일이 발신 도메인의 정당한 서버에서 보내졌는지 수신 측이 확인할 수 있게 하는 이메일 발신자 인증 규격입니다.

기업이 피싱메일을 막기 위해 가장 먼저 두는 장비가 이 게이트웨이이고, 꼭 필요한 장비입니다. 실제로 많은 공격을 앞단에서 걸러냅니다.

왜 게이트웨이는 거래처 사칭 메일을 놓치나

거래처 사칭 메일에는 게이트웨이가 차단 근거로 삼을 요소가 없기 때문입니다. 해외 거래처 담당자 이름으로 "거래 계좌가 변경되었습니다. 다음 결제부터 새로운 계좌를 이용해 주세요"라는 메일이 왔다고 가정해 보겠습니다. 첨부파일이 없고, 악성 URL도 없고, 본문에 특별히 이상한 문장도 없습니다. 발신 도메인은 company.com 대신 company-co.com을 쓰는 식으로 실제 거래처와 아주 비슷하게 만들어져 있습니다.

게이트웨이 입장에서 이 메일 한 통만 놓고 보면 정상 메일과 구분할 수 없습니다. 게다가 요즘 기업형 피싱은 실제 담당자의 이름을 쓰고, 회사의 업무 내용을 파악하고, 피해자가 질문하면 다시 답장을 보냅니다. 메일이 몇 번 오가면 사용자는 기존 거래처와 계속 대화하고 있다고 믿게 되고, 이 단계부터는 기술적인 공격이라기보다 기업 간 신뢰 관계를 이용한 공격에 가깝습니다.

거래처 사칭을 가려내는 질문은 무엇인가

거래처 사칭 공격에서 정말 중요한 질문은 메일 자체가 아니라 거래 관계의 변화에 관한 것입니다.

  • 이 사람이 원래 우리 회사와 거래하던 사람인가?
  • 같은 이름의 담당자가 원래 다른 이메일 주소를 쓰지 않았나?
  • 3년 동안 연락하던 거래처가 왜 갑자기 다른 도메인을 쓰기 시작했나?
  • 하필 처음 등장한 도메인에서 계좌 변경을 요청하는 이유는 무엇인가?

이 질문들은 메일 한 통을 분석해서는 답할 수 없고, 회사에 쌓인 과거 메일과 거래 관계를 함께 봐야 답할 수 있습니다. 실제로 이런 방식으로 거래대금을 가로챈 과정은 거래처 사칭 피싱메일 실제 사례 글에서 따로 정리했습니다.

게이트웨이와 관계 기반 분석은 어떻게 역할을 나누나

두 방식은 대체 관계가 아니라 보완 관계이며, 보는 질문이 다릅니다.

  • 메일 게이트웨이 — 지금 들어오는 메일 자체가 악성인지
  • 관계 기반 분석 — 과거와 비교했을 때 지금의 변화가 정상인지

악성코드, 스팸, 악성 URL처럼 수신 시점에 판단할 수 있는 위협은 반드시 앞단에서 막아야 합니다. 다만 피싱메일이 정상 업무 메일과 비슷해질수록 중요한 것은 메일 자체보다 평소와 무엇이 달라졌는지입니다. 처음 보는 도메인인지, 기존 거래처와 비슷한 도메인인지, 담당자 이름은 같은데 주소만 바뀌었는지, 갑자기 계좌 변경이나 송금 요청이 등장했는지. 이런 정보는 회사에 오랫동안 쌓여 있는 메일 데이터로 확인할 수 있습니다. 회사 데이터를 AI가 읽게 할 때 지켜야 할 원칙은 회사 데이터와 RAG 글에서 다뤘습니다.

저희 MailInsight는 저장된 기업 메일 데이터를 AI로 분석해 기존 거래 관계와 평소 패턴을 파악하고, 그 관계에서 벗어나는 변화를 찾아내는 방식으로 피싱 위험을 분석합니다. 게이트웨이가 "이 메일 자체에 문제가 있는가"를 본다면, MailInsight는 한 단계 더 나아가 "이 메일이 우리 회사가 지금까지 해 온 업무 관계와 비교해도 정상인가"를 봅니다. 자세한 내용은 MailInsight 소개에서 확인하실 수 있습니다.

자주 묻는 질문

Q. 메일 보안 게이트웨이가 있으면 BEC 메일도 막을 수 있나요?

게이트웨이는 악성 첨부파일, 악성 URL, 스팸, 알려진 악성 발신자처럼 메일 한 통에서 판단할 수 있는 위협을 막습니다. 거래처 사칭 BEC 메일은 이런 요소 없이 유사 도메인과 실제 담당자 이름만으로 계좌 변경을 요청하기 때문에 메일 한 통만으로는 차단 근거가 부족합니다. 게이트웨이는 그대로 두고, 과거 거래 관계와 비교하는 분석을 더해야 합니다.

Q. SPF·DKIM·DMARC를 설정하면 거래처 사칭 메일이 차단되나요?

SPF·DKIM·DMARC는 발신 도메인을 도용한 메일을 수신 측이 거를 수 있게 하는 인증 규격이므로 반드시 설정해야 합니다. 그러나 공격자가 직접 등록한 company-co.com 같은 유사 도메인에서 메일을 보내면, 그 도메인 기준으로는 인증이 정상으로 통과합니다. 인증 설정은 필요하지만 유사 도메인 사칭까지 막아 주지는 않습니다.

Q. 관계 기반 분석을 하려면 무엇이 필요한가요?

회사에 축적된 과거 메일 데이터가 필요합니다. 누구와 어떤 주소로 교신해 왔는지의 이력이 있어야 처음 보는 도메인인지, 같은 이름의 담당자가 다른 주소를 쓰기 시작했는지, 평소 없던 계좌 변경 요청이 등장했는지를 가려낼 수 있습니다. 개인 사서함 하나가 아니라 회사 전체의 교신 이력이 기준이 됩니다.