1억2천만 달러 넘게 송금한 미국 기업들 공급업체 사칭메일 사건

2013~2015년 범행, 2019년 징역 5년 선고

미 법무부는 2019년 12월 19일, 리투아니아인 Evaldas Rimasauskas에게 징역 60개월이 선고됐다고 발표했습니다. 미국 기업 두 곳을 속여 자신이 통제하는 계좌로 총 1억2천만 달러 이상을 보내게 한 업무 이메일 사기, 즉 BEC 사건입니다.

이 글의 금액은 뒤에 나온 선고 자료를 기준으로 합니다. 이는 사기로 보내게 한 총액이며, 피해 기업의 최종 순손실이나 돌려받은 금액을 뜻하지 않습니다. 미 법무부 유죄 인정 발표 · 2019-03-20 ↗ 미 법무부 선고 발표 · 2019-12-19 ↗

이런 사건을 읽을 때는 피해 규모와 함께 무엇을 믿고 지급했는가를 살펴볼 필요가 있습니다. 정상 거래에 대한 대금을 보내는 상황이라도, 지급처가 바뀌는 순간에는 새로운 확인이 필요하기 때문입니다.

같은 회사 이름으로 별도 법인을 만들었습니다

발표에 따르면 범인은 아시아 하드웨어 공급업체와 같은 이름으로 라트비아에 회사를 등록하고, 그 회사 명의로 라트비아와 키프로스에 계좌를 마련했습니다. 공급업체 직원을 사칭한 메일은 정상 거래대금을 그 계좌로 보내도록 유도했습니다.

위조 서류의 제출처가 은행이라는 점에 주목하세요. 이를 피해 기업이 해당 서류로 내부 결재를 했다는 뜻으로 바꾸어 읽으면 안 됩니다. 공개된 자료에는 피해 기업의 실명, 결재 과정, 메일 인증 결과가 없습니다. 미 법무부가 공개한 범행 방식 ↗

상호가 같아도 같은 계약 상대방은 아닐 수 있습니다

상호는 회사의 이름입니다. 법인은 계약을 맺고 권리와 의무를 갖는 주체입니다. 업무에서는 이름으로 거래처를 부르지만, 지급할 때는 계약서에 적힌 법인이 누구인지까지 맞춰 봐야 합니다. 서로 다른 나라에 같은 이름의 회사가 있을 수 있고, 한 기업집단 안에도 별도의 법인이 여러 개 있을 수 있습니다.

그래서 수취인 이름이 익숙하다는 사실과 그 계좌로 대금을 지급해도 된다는 판단은 구분해야 합니다. 회사 이름이 일치해도 등록 국가·법인등록번호·계약 관계가 다르면 새 지급처를 검토해야 합니다. 반대로 해외 계좌라는 이유만으로 사기라고 단정해서도 안 됩니다. 해외 판매법인이나 정식 수금 대행사를 쓰는 정상 거래도 있으므로, 그 관계를 설명하는 근거가 필요합니다.

회사 등록 자료는 해당 법인이 존재하는지 확인하는 데 도움이 됩니다. 하지만 그 법인이 우리 계약의 대금을 받을 권한까지 자동으로 증명하지는 않습니다. 계좌 사본이나 회사 도장이 찍힌 PDF도 마찬가지입니다. 서류에 적힌 내용을 기존 계약·거래처 기록과 대조하고, 그 서류 자체가 어디서 왔는지 확인해야 합니다.

가상 사례: 정상 청구서인데 지급은 보류해야 할 때

이제 재무팀의 업무로 옮겨 보겠습니다. 아래 회사명·등록번호·금액은 모두 설명을 위한 가상 예시입니다. 실제 사건의 피해 기업이나 결재 방식을 재현한 것이 아닙니다.

가온기술은 하늘부품에서 장비를 구매했습니다. 구매번호는 PO-217, 대금은 48,000달러입니다. 구매팀은 장비가 도착한 것을 확인했고, 재무팀에는 아직 지급하지 않은 청구서가 있습니다. 지급일 전날, 하늘부품의 담당자처럼 보이는 사람에게 메일이 옵니다.

메일에는 계좌 안내문과 법인 등록 자료가 붙어 있습니다. 수취인 이름은 계약서에서 보던 영문 회사명과 같습니다. 그러나 기존 거래처 기록과 항목별로 나란히 놓으면 다른 점이 드러납니다.

마지막 줄은 일치합니다. 따라서 구매한 장비의 대금이 맞는지 확인하는 단계는 통과할 수 있습니다. 하지만 중간의 세 줄은 달라졌습니다. 이 표에서 내릴 결론은 “청구 근거는 확인했지만, 새 지급처는 아직 확인하지 못했다”입니다. 거래 자체가 실제라는 이유로 계좌 B까지 승인할 수는 없습니다.

승인자가 두 명이어도 같은 자료만 보면 놓칠 수 있습니다

담당자가 “회사명과 금액이 맞음”이라고 적고 팀장이 같은 메일과 첨부파일을 다시 읽는다고 가정해 보세요. 두 번 확인했지만, 판단에 사용한 정보는 모두 한 메일에서 왔습니다. 그 메일이 거짓이라면 두 사람 모두 같은 거짓 정보를 확인한 셈입니다.

두 번째 승인자는 첫 번째 승인자의 결론을 되풀이하기보다 지급처 변경을 뒷받침하는 별도의 근거를 봐야 합니다. 누가 어떤 경로로 실제 거래처에 확인했는지, 새 법인이 계약과 어떤 관계인지, 최종 송금 계좌가 확인받은 계좌와 같은지가 그 근거입니다.

1. 담당자는 지급과 계좌 변경을 잠시 보류합니다

   이번 요청으로 기존 거래처 정보를 바로 덮어쓰지 않습니다. 기존 법인·계좌 정보와 새 요청을 함께 남기고, 어떤 항목이 달라졌는지 표시합니다. 정상 청구서라는 판단과 계좌 변경 승인은 분리합니다.

2. 구매팀은 기존 계약 상대방에게 확인합니다

   이번 메일의 서명에 적힌 번호가 아니라, 이전에 검증한 거래처 연락처로 확인합니다. “메일을 보냈나요?”에 그치지 않고 구매번호, 새 수취 법인의 등록 정보, 계좌 변경 내용을 짚어 확인합니다.

3. 다른 법인이 받는다면 그 근거를 검토합니다

   실제 거래처가 변경을 요청한 것이 맞더라도, 별도 법인의 수금을 허용한 계약 변경이나 위임 관계가 있는지 구매·법무 담당자가 확인합니다. 메일 한 통으로 기존 계약의 지급 상대방을 바꾸지 않도록 합니다.

4. 최종 승인자는 확인 기록과 실제 송금 대상을 대조합니다

   확인한 상대와 경로, 새 법인·계좌를 승인한 근거를 보고 판단합니다. 지급 파일이나 은행 화면에 입력한 수취인·계좌도 승인받은 값과 비교합니다. 승인된 문서와 실제 송금 입력이 달라지는 일을 막기 위해서입니다.

이 가상 사례에서는 기존 담당자가 “수취 법인도 계좌도 변경한 적 없다”고 답했다고 하겠습니다. 재무팀은 계좌 B 등록을 중단하고, 메일 원본과 첨부파일을 보안 담당자에게 전달합니다. 장비 대금은 정상 청구 여부와 중복 지급 여부를 확인한 뒤, 기존에 승인된 계좌로 원래 지급 절차를 진행합니다. 의심스러운 계좌 요청을 멈추는 일과 정상 거래대금을 처리하는 일을 구분한 결과입니다.

반대로 정식 변경으로 확인됐다면 새 법인과 계약의 관계를 검토한 뒤 계좌 정보를 갱신합니다. 변경 전후 값, 확인 근거와 승인자가 남아 있어야 다음 지급 때 처음부터 같은 의문을 풀지 않아도 됩니다. 변경 사유가 “급한 결제”라는 말뿐이고 확인할 수 없다면, 사기로 단정하는 대신 확인이 끝날 때까지 지급을 보류하는 편이 합리적입니다.

지급 요청이나 계좌 변경을 다른 경로로 확인하라는 원칙은 FBI도 안내합니다. 위 절차는 그 원칙을 법인·계좌 변경 업무에 적용해 본 예시입니다. FBI의 BEC 예방 안내 ↗

DMARC가 확인하는 것은 계좌의 정당성이 아닙니다

“DMARC 통과 여부만 확인하면 되지 않을까?”라는 질문이 생길 수 있습니다. DMARC는 보낸 사람 주소의 From 도메인을 인증 결과와 연결합니다. SPF 또는 DKIM이 통과하고, 그 인증 도메인이 From과 정렬돼야 DMARC를 통과합니다.

거래처의 정확한 도메인을 무단으로 적어 보내는 시도에는 도움이 됩니다. 그러나 공격자가 소유한 비슷한 도메인이나 탈취한 정상 계정으로 보낸 메일은 인증을 통과할 수 있습니다. dmarc=pass는 From 도메인 사용에 대한 인증 근거입니다. 회사의 실체, 계약 관계, 계좌 소유까지 확인한 결과는 아닙니다. 표준도 통과 결과만으로 메일의 안전성을 보증하지 않으며, 비슷한 도메인이나 표시 이름 사칭은 보호 범위 밖이라고 설명합니다. DMARC 통과 결과의 의미 ↗ DMARC의 사칭 대응 범위 ↗

우리 회사 도메인 보호와 수신 메일 검사는 역할이 다릅니다

우리 회사의 발신 환경에 SPF·DKIM·DMARC를 설정하면 수신자가 우리 주소의 메일을 검증하는 데 도움이 됩니다. 거래처에서 오는 메일은 우리 수신 서비스가 거래처 도메인의 인증 결과와 다른 보안 신호를 검사해야 합니다. 우리 도메인의 p=reject만으로 거래처를 사칭한 수신 메일까지 차단할 수는 없습니다.

보안 담당자는 인증 결과와 실제 발신 경로를 살피고, 재무·구매 담당자는 지급 상대방과 변경 근거를 확인합니다. 두 업무를 연결하되 한 업무에서 “정상”으로 판단했다고 다른 확인을 생략하지 않는 것이 좋습니다. 이 사건의 실제 헤더나 당시 DMARC 설정은 공개 자료에 없으므로, DMARC가 있었으면 반드시 막았을 사건이라고 결론 내릴 수는 없습니다.

다음 지급 전에 확인해 볼 세 가지

최근 지급한 거래처 하나를 골라 보세요. 담당자가 바뀌더라도 회사 이름 외에 무엇을 근거로 지급처를 확인할 수 있는지 살펴보면, 절차의 빈틈이 구체적으로 드러납니다.

1. 거래처 이름 뒤에 실제 법인 정보가 남아 있나요?

상호와 이메일만으로 거래처를 관리한다면 계약 상대방을 구별하기 어렵습니다. 계약서, 등록 국가와 식별 정보, 승인된 계좌를 서로 연결해 두세요. 계열사나 수금 대행사가 대금을 받는 거래라면 그 관계와 승인 근거도 함께 보관해야 합니다. 항목을 모으는 데서 끝내지 말고 어떤 자료로 확인했는지 남기는 것이 중요합니다.

2. 계좌 변경 승인은 무엇을 보고 이뤄지나요?

담당자와 승인자가 각각 확인한 근거를 한 건만 펼쳐 보세요. 둘 다 같은 메일과 첨부파일만 봤다면, 외부 확인이 필요한 지점을 정할 수 있습니다. 변경 후 정보만 저장하는 대신 이전 값과 확인 이력을 남기면 실수나 이상 변경을 발견했을 때 어디서 달라졌는지 추적하기도 쉽습니다.

3. 의심스러운 지급을 멈추고 원본을 확보할 수 있나요?

누가 지급을 보류할 수 있는지, 이미 송금했다면 누가 은행에 즉시 연락할지 정해 두세요. 송금 시각·금액·수취 계좌, 메일 원본, 첨부파일, 거래처 정보 변경과 승인 기록을 확보하면 후속 조사에 도움이 됩니다. 이미 보냈다면 조사 자료가 모두 모일 때까지 은행 연락을 미루지 않습니다. FBI도 금융기관에 즉시 연락할 것을 안내합니다. 실제 회수 여부는 별도로 확인해야 합니다. FBI의 송금 피해 대응 안내 ↗

이메일 인증부터 점검하려면 SPF·DKIM·DMARC 동작 원리를 읽고, 회사 주소의 발신 환경은 DMARC 도입 체크리스트로 정리해 보세요. 재무팀에서는 위 가상 사례처럼 기존 거래처 정보와 계좌 변경 요청을 한 번 나란히 놓아 보는 것부터 시작할 수 있습니다.