사기의 바다를 건너는 등대: 한국편

사례·심리·대응·회복, 우리에게 필요한 한 권. 9장.

Oct 16. 2025 brunch_membership's

Part II. 공격 벡터별 플레이북(한국 현장 대본 포함)

ChatGPT Image 2025년 10월 16일 오전 10_16_31.png

9장. 이메일/BEC: 거래처 계좌 바뀜·공문 PDF 위장·결재 프로세스 침투

9.0 서문 — 이메일은 창이자 문이기도 하다

하루에도 수십 통의 이메일이 오간다.
거래처의 견적서, 결재 요청, 세금계산서, 그리고 안부 인사까지.
이메일은 우리가 세상과 연결되는 창이자,
누군가가 우리 안으로 들어올 수 있는 문이 되었다.

그 문은 조용히 열린다.
한 번의 클릭, ‘PDF 확인’이라는 단어 하나로.
그 안엔 회사 로고도, 담당자 이름도, 심지어 ‘지난 대화 내역’까지 완벽히 복제되어 있다.
그러나 그건 ‘그 사람’이 아니라,
그 사람의 흉내를 낸 알고리즘이다.

이제 사기는 허술하지 않다.
‘BEC(Business Email Compromise)’ —
업무 이메일 침투형 사기,
거래처 담당자를 가장해 계좌번호를 바꾸거나,
공문처럼 위장된 PDF로 악성 링크를 심는다.

그들의 목표는 단순하다.
신뢰의 사슬에 침투하는 것.
그리고 그 사슬은 언제나,
‘익숙함’이라는 이름으로 시작된다.

우리는 이제 묻는다.
“이메일을 믿는다는 건, 무엇을 믿는 걸까?”

그 답은 ‘불신’이 아니라,
정확한 확인의 기술이다.
보낸 사람의 주소를 다시 보고,
링크를 누르기 전 ‘직접 로그인’을 선택하는 단 10초의 행동.

그 짧은 10초가,
한 조직의 자산을,
그리고 한 사람의 명예를 지켜낸다.

이메일은 아직 안전하다.
다만, 우리가 그것을 다루는 손끝이 깨어 있을 때만.

9.1 BEC의 해부 — CEO 사칭과 결재 라인의 무너짐

이메일 한 통이 날아든다.
제목은 간단하다.

“긴급 송금 요청 — 오늘 안으로 처리 바랍니다.”

보낸 사람은,
당신이 매일 결재 보고를 올리던 대표이사 이름이다.
메일 서명에는 회사 로고가 있고,
어제 주고받은 메일 스레드까지 이어져 있다.

그런데, 이번엔 다르다.
문장 끝의 말투가 조금 짧다.
평소엔 “고생 많아요”로 끝나던 인사가
오늘은 “즉시 처리 바람.”

이것이 바로 **BEC(Business Email Compromise)**의 문법이다.
그들은 기술로 서버를 뚫지 않는다.
사람의 신뢰 체계,
그 조용한 회로를 조작한다.

보낸 사람의 주소는 진짜처럼 보인다.
메일 서버의 도메인도 정교하게 위장되어 있다.
(ceo@company.co.kr → ceo@cornpany.co.kr, 알파벳 ‘r’ 대신 ‘n’과 ‘m’의 합성체)

그들은 맥락을 해킹한다.
승인 절차를 건너뛰게 만들고,
‘급하다’는 한마디로 조직의 리듬을 무너뜨린다.

탐지의 신호는 항상 작게 시작된다.

말투가 평소보다 짧거나, 지나치게 명령조일 때.

익숙한 사람이 갑자기 ‘외화 송금’을 요구할 때.

새로운 계좌, 새로운 프로젝트, 새로운 긴급함.

그 작은 이상이,
메일 속 진짜 얼굴을 드러내는 균열이다.

대응의 원칙 — 단 2가지

2인 승인 원칙: 모든 대금·송금은 반드시 두 사람의 서명 또는 확인을 거쳐야 한다.

딜레이의 용기: 급하다고 느껴질수록 멈춰라. 전화 한 통이 전체 회계를 구한다.

훈련의 기술
매달 한 번, ‘가짜 CEO 메일’을 직원들에게 보낸다.
누가 열었는지, 누가 응답했는지, 누가 신고했는지를 분석한다.
그 데이터는 단순한 보안 지표가 아니라,
조직의 신뢰 체계의 건강검진표다.

“BEC는 기술이 아니라 ‘관계의 틈’을 노린다.
그 틈을 메우는 것은 방화벽이 아니라,
‘한 번 더 확인하는 사람의 마음’이다.”

원하신다면, 이어서 **9.2 ‘공문 PDF 위장 — 클릭 한 번으로 문이 열린다’**를 같은 서사톤으로 이어드릴까요?

9.2 거래처 계좌 변경 사기 — 신뢰의 전이 차단하기

메일 제목은 늘 그렇다.

“거래계좌 변경 안내드립니다.”

익숙한 회사명,
늘 거래하던 담당자의 이름,
심지어 어제 결제한 품목명까지 그대로다.
문체도, 서명도, 심지어 감사 인사도 같다.

그런데 단 한 줄이 다르다.

“입금 계좌가 변경되었습니다. 아래 계좌로 부탁드립니다.”

그 한 줄이,
수년간 쌓은 신뢰의 사슬을 절단하는 칼날이 된다.

그들은 기술보다 사람을 더 잘 이해한다.
거래의 언어, 신뢰의 형식,
그리고 업무의 습관까지 복제한다.

사람은 ‘관계’에서 안심하고,
그 안심이 사기의 통로가 된다.
신뢰는 본래 따뜻한 온기지만,
그 온기를 모방하는 순간, 돈은 증발한다.

“신뢰는 서명보다 강하다.”
하지만 그것이 기술로 복제될 때,
그 신뢰는 종이처럼 얇아진다.

탐지·대응 포인트

전화로 재확인:
메일에 적힌 번호가 아닌,
기존에 저장된 연락처로 직접 전화하라.
단 한 통의 통화가 수천만 원을 지킨다.

서면 계약 보완:
거래계좌 변경 시, 반드시 양사 직인 서류를 요구하라.
PDF 문서의 서명은 위조될 수 있지만, 종이의 잉크는 거짓말하지 않는다.

자동 차단 룰:
은행 계좌명과 거래처명 불일치 시 자동 경보가 울리도록 설정하라.
시스템은 ‘신뢰의 감시자’가 되어야 한다.

템플릿 — 계좌 변경 확인 이메일 예시

제목: [확인 요청] 귀사 계좌 변경 관련 사항 검토 내용: 안녕하세요, ○○회사 ○○○입니다. 귀사로부터 전달받은 계좌 변경 통지 확인을 위해 연락드립니다. 변경 계좌의 소유주명 및 은행 정보를 다시 한 번 확인 부탁드립니다. 확인 후 서명된 서류를 회신해주시면 감사하겠습니다.

전화 확인 체크리스트

저장된 기존 번호로 통화했는가?

상대방의 말투·응답 패턴이 평소와 일치하는가?

변경 사유와 승인 절차가 명확히 설명되는가?

통화 직후, 내부 결재 라인에 공유했는가?

“BEC의 칼날은 기술이 아니라,
우리가 쌓은 ‘신뢰’를 거꾸로 이용하는 손끝이다.
그러나 그 손끝을 막는 힘 또한,
다시 ‘신뢰’에서 나온다 — 단, 이번엔 확인된 신뢰로.”

9.3 공문·PDF 위장 — 메타데이터와 숨은 흔적 읽기

메일의 제목은 언제나 공손하다.

“세금계산서 발행 관련 공문 전달드립니다.”
[첨부파일: 국세청_통지문.pdf]

로고는 정교하고, 문장은 관공서의 문체를 닮았다.
왼쪽 상단엔 푸른색 워터마크, 오른쪽엔 직인까지.
심지어 문서의 ‘서류 냄새’마저 느껴진다.

하지만, 그 문서는 종이가 아니라 함정이다.
그 안엔 보이지 않는 코드가 숨었다 —
“열기”라는 단 한 번의 클릭을 기다리며.

이것이 바로 문서형 피싱의 진화,
공문 위장형 공격의 연극이다.

문서는 증거처럼 보이지만,
그 실체는 연극의 **소품(prop)**과 같다.
배경, 조명, 서명, 날짜까지 완벽히 연출된 무대.
그러나 진짜 이야기는 그 무대 뒤,
메타데이터 속에 있다.

“진실은 텍스트가 아니라, 속성(property)에 있다.”

PDF 생성일이 메일 수신일보다 뒤라면, 그것은 거짓이다.

편집자 이름이 회사 담당자와 다르다면, 그것은 위조다.

디지털 서명이 누락되어 있다면, 그것은 서류의 껍데기일 뿐이다.

탐지·대응 포인트

샌드박스 검사:
첨부파일을 직접 열지 말고, 내부 보안 샌드박스나 전용 검사툴로 먼저 스캔하라.

매크로 비활성 기본정책:
모든 워드·엑셀 파일은 기본적으로 매크로 비활성화 상태에서만 열기.
“매크로를 허용하시겠습니까?”라는 문장은 공격의 시작이다.

메타데이터 검토:
문서 → 속성 보기에서 생성자, 편집자, 수정 날짜를 반드시 확인하라.
눈에 보이지 않는 정보가, 보이는 신뢰보다 더 정확하다.

훈련 프로그램 — 첨부파일 안전 점검 워크숍
제목: 「파일 열기 전 7점 체크」
목표: 파일을 열기 전, 보이지 않는 흔적을 읽는 습관 훈련

실습 항목

파일명과 확장자 확인

생성일·편집자 확인

문서 내 숨은 링크 존재 여부

매크로 경고창 반응 훈련

샌드박스 테스트 절차

디지털 서명 유무 검증

의심 문서 보고 프로세스

“문서를 여는 손보다, 문서를 의심하는 눈이 앞서야 한다.”

결론의 한 문장

“진짜 공문은 권위를 내세우지 않는다.
진짜 문서는 조용히 증명한다.
그 차이를 구분하는 것은 기술이 아니라,
‘한 번 더 속성을 클릭해보는 습관’이다.”

9.4 스푸핑·스미싱의 기술적 배경 — SMTP·SPF·DKIM·DMARC 요약

이메일이 세상을 연결하기 시작한 건,
‘신뢰’가 기본값이던 시절이었다.
SMTP — Simple Mail Transfer Protocol,
그 이름처럼 ‘단순하게 믿는 시대의 약속’이었다.

하지만 세상은 변했고,
이 단순한 약속은 지금 가짜 신뢰의 출발점이 되었다.
누구나 보낸 사람을 바꿀 수 있고,
누구나 ‘대표이사’로 가장할 수 있는 세계.
그 허점을 막기 위해 태어난 세 가지 방패가 있다.

SPF ― 보낸 곳의 주소를 확인하는 첫 번째 문지기

Sender Policy Framework
→ 이 도메인에서 메일을 보낼 ‘허용된 서버 목록’을 명시한다.

“이 IP에서 보낸 메일만 우리 회사 메일이다.”

하지만 SPF는 메일이 다른 서버를 거칠 때 깨진다.
(포워딩, 외부 위임 서버 등)

점검 포인트:

DNS 레코드의 v=spf1 구문 확인

-all(강제 차단) 설정 여부 체크

DKIM ― 서명(Signature)으로 진짜 발신을 증명하는 두 번째 방패

DomainKeys Identified Mail
→ 메일 헤더에 ‘디지털 서명’을 넣어, 보낸 도메인이 위조되지 않았음을 검증한다.

“이 메시지는 우리가 서명한 진짜 메일입니다.”

하지만 공격자는 서명되지 않은 서브도메인을 이용해 우회할 수 있다.

점검 포인트:

DKIM 공개키가 DNS에 정확히 등록되어 있는가

메일 헤더에 DKIM-Signature: 항목이 존재하는가

DMARC ― 도메인의 최종 판정자

Domain-based Message Authentication, Reporting & Conformance
→ SPF와 DKIM의 결과를 종합하여, 정책을 직접 선언한다.

“SPF와 DKIM 둘 다 통과하지 못하면 거부한다.”

하지만 정책이 p=none이라면, 아무 일도 일어나지 않는다.

점검 포인트:

정책 레벨: p=quarantine 또는 p=reject

리포트 주소(rua) 설정: 공격 시도를 모니터링하는 핵심

탐지·대응 포인트 요약

도메인 정합성 모니터링:
SPF·DKIM·DMARC 검증 결과를 주기적으로 점검.

DMARC 리포트(rua) 분석:
발신 위조 시도 IP, 국가, 빈도를 시각화하여 주간 리포트 생성.

외부 메일 서비스 점검:
외주·협력사 메일 서버의 SPF 적용 여부 확인.

운영 실무 가이드 — IT팀을 위한 DMARC 체크리스트

“메일의 신뢰는 문장의 예의가 아니라,
DNS의 진실에서 태어난다.
방패는 이미 존재한다.
다만, 그 방패를 ‘켜두는 사람’이 필요할 뿐이다.”

9.5 악성 링크·첨부의 전형 — 매크로·체인다운로드·C2 연결

짧은 장면 (우화형 도입)

한 통의 메일. 첨부된 ‘견적서.pdf’는 눈에 익은 이름으로 왔다.
“내용 확인 후 회신 바랍니다.”
누군가는 호기심으로, 누군가는 바쁜 손으로, 그 파일을 연다.
그 순간, 화면 뒤에서 보이지 않는 손이 움직인다 —
작은 스크립트가 내려와 더 큰 코드에게 문을 열어준다.
체인은 이어지고, 원격의 지휘자(커맨드앤컨트롤, C2)는 침묵 속에서 명령을 내린다.
몇 시간 뒤, 사내 서버 몇 대가 잠식되고, 중요한 자료들이 외부로 빠져나간다.
사건은 ‘클릭 한 번’에서 시작된다.

핵심 문제

문서나 링크를 통해 시작된 멀웨어 감염이 내부 네트워크의 심층부로 확산된다.
전형적 루트는 다음과 같다:

문서 내 매크로(또는 악성 스크립트) 실행 → 드롭퍼(체인다운로드)를 통해 페이로드 획득 → C2와 연결 → 데이터 유출·랜섬·측면이동(Lateral Movement).

해설 — 왜 한 번의 클릭이 위험한가

한 번의 클릭은 기술적으론 작은 이벤트일 뿐이지만, 조직의 보안 관점에선 도미노의 첫 타격이다.
매크로는 원래 자동화 도구이지만, 악성으로 바뀌면 내부 명령을 수행하는 ‘원격 스위치’가 된다.
체인다운로드 방식은 탐지를 회피하기 위해 여러 단계로 나뉘어 내려오며, C2는 감염된 기기를 외부에서 조종해 증거를 지우고 추가 공격을 유도한다.
이 공격의 무서운 점은 ‘시간차’와 ‘은밀성’이다 — 즉시 눈에 띄지 않고, 탐지되기 전 이미 여러 자산을 손상시킬 수 있다.