거래처가 “대금을 아직 받지 못했다”고 연락해 왔습니다. 회사에서는 이미 송금을 마쳤습니다. 이때 확인해야 할 것은 송금 영수증만이 아닙니다. 며칠 전 도착한 계좌 변경 메일의 주소도 다시 펼쳐 봐야 합니다.
2024년 싱가포르에서는 거래처를 사칭한 메일을 믿고 4,230만 달러를 다른 계좌로 보낸 사건이 발생했습니다. 주소에는 작은 차이가 있었습니다. 싱가포르 경찰은 원래 주소의 소문자 i가 소문자 l로 바뀌었다고 밝혔습니다. 싱가포르 경찰 발표 · 2024-08-03 ↗
이처럼 이메일로 거래처나 임직원을 사칭해 송금 등을 유도하는 사기를 BEC(기업 이메일 사기)라고 부릅니다. 주소를 어디까지 확인해야 하는지, 이미 송금했다면 누가 어떤 정보를 모아야 하는지 이 사례를 통해 살펴보겠습니다. 사건 경위와 금액은 2024년 8월 발표 시점을 기준으로 합니다.
수신부터 발견까지, 무엇이 일어났을까요?
- 2024.07.15계좌 변경 메일 수신
공급업체를 사칭한 메일이 동티모르의 새 은행 계좌로 대금을 보내 달라고 요청했습니다.
- 2024.07.194,230만 달러 송금
싱가포르 기업이 사칭 메일의 계좌로 대금을 보냈습니다.
- 2024.07.23실제 거래처 연락으로 발견
거래처가 미입금을 알렸고, 기업은 사기를 확인해 경찰에 신고했습니다.
- 2024.07.243,900만 달러 동결 확인
싱가포르 경찰은 동티모르 계좌의 자금이 동결됐다는 소식을 받았습니다.
- 2024.07.25추가 회수 소식
동티모르 당국이 체포와 함께 200만 달러 이상을 추가 회수했다고 알렸습니다.
INTERPOL도 8월 6일 국제 공조를 통한 자금 확보를 발표했습니다. 발표 당시에는 피해 기업에 돈을 돌려주는 절차가 진행 중이었습니다. INTERPOL 사건 발표 · 2024-08-06 ↗
위 순서에서 실무적으로 눈여겨볼 대목은 진짜 거래처의 미입금 연락이 사고 발견으로 이어졌다는 점입니다. 지급 시스템에 “송금 완료”라고 표시되는 것과 계약 상대가 실제로 돈을 받는 것은 다른 일입니다. 계좌 변경 직후의 첫 지급은 기존 거래처 담당자에게 수령 여부까지 확인하는 절차를 둘 수 있습니다.
다만 공개 자료에는 회사 내부의 승인 화면이나 담당자 간 대화가 없습니다. 어느 단계에서 어떤 확인을 생략했는지까지 추정해 특정 직원의 부주의로 설명하지는 않겠습니다. 아래의 주소 비교와 대응 절차는 회사에서 점검해 볼 수 있도록 만든 가상 예시입니다.
송금·동결·회수·반환을 구분해서 읽어야 합니다
사건 기사에서 “4,000만 달러 이상 회수”라는 표현을 읽으면 피해가 모두 해결된 것으로 생각하기 쉽습니다. 하지만 돈이 이동한 단계마다 확인해야 할 내용이 다릅니다.
표를 좌우로 밀어 전체 내용을 확인하세요.
| 상태 | 발표 내용 | 이 숫자가 뜻하는 것 |
|---|---|---|
| 송금 | 4,230만 달러 | 기업이 잘못된 계좌로 보낸 금액 |
| 동결 | 3,900만 달러 | 당국이 계좌에서 이동하지 못하도록 붙잡은 자금 |
| 추가 회수 | 200만 달러 이상 | 후속 수사에서 추가로 확보한 자금 |
| 피해자 반환 | 절차 진행 중 | 실제로 돌려받은 최종 금액은 이 발표에서 확정하지 않음 |
이 표의 송금액에서 확보액을 빼 “최종 손실은 얼마”라고 계산하면 안 됩니다. 확보한 자금을 피해자에게 돌려주는 데에는 별도 절차가 남아 있고, 발표의 금액도 최종 정산 내역은 아닙니다. 동결·추가 회수 수치는 싱가포르 경찰 발표를, 반환 진행 상태는 두 기관의 발표를 함께 확인했습니다.
회사 내부의 사고 보고도 같은 방식으로 작성하면 혼선을 줄일 수 있습니다. 예를 들어 은행에서 “상대 은행에 회수 요청을 전달했다”고 했다면, 상태는 회수 요청 접수입니다. 아직 동결 확인이나 반환 완료로 바꾸지 않습니다. 연락한 시각, 담당 기관, 받은 답변을 남기고 새 확인이 있을 때 상태를 갱신합니다.
이 사건의 회수 결과는 빠른 신고와 공조의 중요성을 보여 줍니다. 그렇다고 송금 후 며칠까지는 안전하다거나, 일정 시간 안에 신고하면 돈을 돌려받는다는 기준으로 삼을 수는 없습니다. 자금의 이동 경로와 은행·수사기관의 조치에 따라 결과가 달라집니다.
이름을 읽은 다음, 전체 주소와 회신 방향을 확인하세요
재무 담당자가 라임무역에서 보낸 듯한 계좌 변경 메일을 받았다고 가정해 보겠습니다. 메일 목록에는 익숙한 “라임무역 재무팀”이라는 이름이 보이고, 제목도 이번 달 지급 업무와 관련돼 있습니다. 이 단계에서 “늘 거래하던 곳”이라고 판단하면 실제 주소는 눈에 들어오지 않을 수 있습니다.
1. 표시 이름 아래의 주소를 펼칩니다
표시 이름은 사람에게 읽기 좋게 붙인 이름입니다. From 주소는 메일이 보낸 사람으로 적어 놓은 전체 주소입니다. 메일 앱에서 보낸 사람의 상세 정보를 열어, 이름 뒤에 가려진 주소를 확인합니다. 모바일에서는 주소가 줄어 보일 수 있으므로 전체가 표시되는 화면에서 비교하는 편이 좋습니다.
billing@lime.examplebilling@llme.example위쪽은 lime.example, 아래쪽은 llme.example입니다. 익숙한 이름과 대충 비슷한 철자를 인식하는 것만으로는 놓칠 수 있는 차이입니다. 눈으로 기억을 더듬기보다, 사전에 검증해 둔 거래처 정보의 주소와 받은 주소를 나란히 놓고 비교하세요. 의심 메일에 인용된 과거 대화나 서명은 비교 기준으로 삼지 않습니다.
2. @ 앞부분과 뒷부분을 따로 봅니다
@ 앞은 사서함 이름이고 뒤는 도메인입니다. 위 예시에서는 앞부분인 billing이 같고 도메인이 다릅니다. 반대로 도메인은 같아도 billing과 bllling처럼 앞부분이 다를 수 있습니다. 어느 경우든 기존 담당자 주소와 다르다면 변경 이유를 확인할 대상입니다.
주소가 같다는 사실도 송금 승인은 아닙니다. 누군가 정상 계정을 탈취했거나 보낸 사람 주소를 위조했을 가능성은 별도로 살펴야 합니다. 주소 비교는 이상을 발견하는 첫 단계이고, 계좌를 바꾸는 결정에는 거래처의 독립적인 확인이 필요합니다.
3. 답장이 실제로 향하는 주소도 확인합니다
From: "라임무역 재무팀" <billing@llme.example>
Reply-To: settle@accounts.example
Subject: 이번 달 대금 입금 계좌 변경Reply-To는 답장을 받을 주소를 별도로 지정하는 항목입니다. 위 메일에 회신하면 보통 billing@llme.example이 아니라 settle@accounts.example으로 답장이 향합니다. 메일 상세 정보와 회신 창의 받는 사람 주소를 확인하면 그 차이를 볼 수 있습니다. 메일 표준의 From·Reply-To 설명 ↗
Reply-To가 다르다는 이유만으로 사기라고 단정할 수는 없습니다. 고객지원 시스템이나 부서의 공용 사서함을 쓰는 정상 메일에도 이 항목이 있습니다. 다만 계좌 변경을 요청하면서 회신 방향까지 달라졌다면, 해당 주소에 “정말 맞나요?”라고 답장해서 확인을 끝내면 안 됩니다. 요청을 보낸 사람이 다시 확인해 주는 구조이기 때문입니다.
이 가상 상황의 담당자는 지급을 보류하고 기존 거래처 정보에 등록된 전화번호로 확인합니다. 거래처가 변경을 요청한 적이 없다고 답하면 새 계좌를 등록하지 않고, 받은 메일을 보안 담당자에게 전달합니다. “주소의 i가 l로 달랐고, Reply-To도 처음 보는 주소였다”는 관찰 내용을 함께 적으면 조사를 시작하기 쉽습니다. FBI도 주소를 자세히 살피고 지급·계좌 변경 요청을 별도 경로로 확인하도록 안내합니다. FBI의 BEC 예방 안내 ↗
DMARC PASS와 거래처 확인은 어떤 차이가 있나요?
“그 메일이 DMARC를 통과했다면 믿어도 되지 않을까요?” DMARC는 From의 도메인이 인증에 성공한 도메인과 연결되는지 확인합니다. 메일에 적힌 계좌가 실제 거래처 소유인지, 그 직원에게 계좌 변경 권한이 있는지는 확인하지 않습니다.
표를 좌우로 밀어 전체 내용을 확인하세요.
| 메일이 온 상황 | 인증에서 볼 수 있는 것 | 업무에서 더 확인할 것 |
|---|---|---|
| 외부 서버가 lime.example을 무단으로 From에 사용 | 정렬된 SPF·DKIM 인증이 모두 없으면 DMARC 실패 | 수신 측 처리 정책과 도메인 도용 흔적 |
| 다른 도메인 llme.example로 발송 | 그 도메인으로 인증·정렬을 갖추면 DMARC 통과 가능 | 원래 거래처 도메인과 일치하는지 |
| 탈취된 실제 거래처 계정에서 정상 경로로 발송 | 정상 인증을 거쳐 DMARC 통과 가능 | 계정 침해 여부와 지급 요청의 정당성 |
두 번째 행에서 DMARC가 확인한 것은 llme.example입니다. 우리가 알고 있던 lime.example과 이름이 닮았는지 판별하는 기능은 아닙니다. 도메인 소유자가 게시한 DMARC 정책도 다른 회사나 공격자가 가진 별도 도메인까지 통제하지는 못합니다. DMARC 표준의 보호 범위 ↗
그래서 회사 도메인의 무단 사용을 줄이는 인증 설정과, 외부에서 들어오는 사칭 메일을 판단하는 수신 보안, 실제 지급을 승인하는 업무 절차가 함께 필요합니다. 보안팀이 인증 결과를 볼 때에는 PASS라는 단어와 함께 어느 From 도메인에 대한 결과인지를 재무팀에 설명해 주면 좋습니다.
이 사건의 메일 원본과 인증 결과는 공개되지 않았습니다. 이 표는 기술의 역할을 이해하기 위한 예시이며, 당시 DMARC가 없었다거나 특정 설정으로 반드시 막을 수 있었다는 사건 분석은 아닙니다. 인증 결과를 읽는 방법은 SPF·DKIM이 통과해도 DMARC가 실패하는 이유에서 더 자세히 다룹니다.
이미 송금했다면, 원인 분석을 기다리지 말고 연락합니다
앞의 예시에서는 송금 전에 멈췄습니다. 반대로 송금을 마친 뒤 주소 차이를 발견했다면 우선순위가 달라집니다. 메일이 어떻게 들어왔는지 조사하는 동안에도 돈은 이동할 수 있습니다. 재무 담당자는 송금 은행에 사기 의심 거래임을 즉시 알리고, 수취 은행과의 연락 및 가능한 회수 조치를 요청합니다. 수사기관 신고도 함께 진행합니다. FBI 역시 피해 의심 시 금융기관에 즉시 연락하도록 안내합니다. FBI 피해 대응 안내 ↗
은행 연락을 모든 자료가 모일 때까지 미루지 않도록 역할을 나누는 편이 좋습니다. 아래는 재무 담당자가 은행과 통화하는 동안 다른 담당자가 정보를 보완하는 방식의 예시입니다. 아직 출금 전인 예약·승인 대기 건이 있다면 별도로 확인해 추가 지급을 멈춥니다.
표를 좌우로 밀어 전체 내용을 확인하세요.
| 담당 | 먼저 할 일 | 다른 담당자에게 전달할 결과 |
|---|---|---|
| 재무·자금 | 은행에 연락하고 해당 송금과 추가 지급 확인 | 거래 참조번호, 은행 접수번호, 확인된 처리 상태 |
| 구매·거래처 담당 | 기존 연락처로 실제 요청·입금 여부 확인 | 확인 상대, 연락 시각, 정상 계좌 정보의 출처 |
| IT·보안 | 메일 원본과 관련 로그 보존, 동일 메일 조사 | 확인된 발신·회신 주소, 수신 범위, 계정 이상 징후 |
| 사고 대응 책임자 | 수사기관 신고와 자료 취합, 연락 창구 정리 | 신고 접수 정보, 담당자, 후속 요청과 진행 기록 |
신고할 때 필요한 정보를 한곳에 모읍니다
“사기 메일을 받았다”는 설명만으로는 어느 송금에 조치해야 하는지 알기 어렵습니다. 첫 연락에서는 확인된 거래부터 식별할 수 있게 전달하고, 모르는 항목은 확인 중으로 표시합니다. 기관마다 요구 자료는 다르므로 아래 항목은 내부 취합용으로 사용하세요.
사건 담당자 / 바로 연락 가능한 번호:
발견 시각 / 시간대:
송금 시각 / 시간대:
금액 / 통화:
송금 은행 / 거래 참조번호:
수취 은행 / 국가 / 수취인 / 계좌번호:
요청 메일 수신 시각 / From / Reply-To:
실제 거래처에 확인한 내용 / 확인 경로:
추가로 대기 중인 지급 건:
메일 원본 / 송금 증빙 보관 위치:
은행·수사기관 접수번호 / 다음 확인 사항:해외 거래라면 시각에 시간대를 함께 적습니다. 서로 다른 나라의 “오후 3시”는 같은 시점이 아닐 수 있습니다. 거래 참조번호와 수취 계좌는 전달 과정에서 다시 타이핑하기보다 은행의 송금 내역을 기준으로 대조하고, 계좌번호·메일 원본은 은행과 수사기관이 안내한 안전한 경로로 제출합니다.
화면 캡처와 메일 원본을 함께 보존합니다
화면 캡처는 담당자가 무엇을 봤는지 설명하는 데 도움이 됩니다. 그러나 메일이 거친 경로나 인증 결과를 조사하려면 전체 헤더를 포함한 원본도 필요합니다. 메일 서비스의 원본 다운로드 기능을 사용하거나 관리자에게 보존을 요청하고, 첨부파일을 다시 실행해 내용을 확인하려고 하지는 않습니다.
보안 담당자는 해당 발신·회신 주소와 관련 제목으로 다른 수신자가 있는지 살펴보고, 정상 계정의 이상 징후가 있다면 로그인 기록과 전달 규칙도 확인합니다. 사칭 메일을 받았다는 사실만으로 우리 계정이 탈취됐다고 결론 내리지는 않습니다. 조사된 사실과 아직 확인 중인 내용을 구분해 공유해야 불필요한 혼선을 줄일 수 있습니다.
사고가 없는 지금 준비할 수 있는 일도 있습니다. 은행의 사고 연락 경로, 거래처의 검증된 연락처, 메일 원본을 보존할 담당자를 함께 정해 두세요. 주소를 살펴 이상을 발견한 사람이 곧바로 지급을 보류하고 담당자에게 연결할 수 있어야, 한 글자의 차이가 실제 대응으로 이어집니다.
Genharden DMARC · 2026.09.21 기준. 사건 사실은 본문에 연결한 공식 발표를 기준으로 정리했습니다. 발생·발표 시점과 확인되지 않은 부분을 구분하고, 업무 절차는 대응 제안으로 설명했습니다.