🏦 Bangladesh Bank SWIFT Heist — '정상 승인 거래'로 위장해 8,100만 달러를 빼낸 APT38의 은행 강탈 (2016)

1. 배경/역사 — 언제, 누가, 왜 유명한가

2016년 2월 4일 밤부터 5일 사이, 방글라데시 중앙은행(Bangladesh Bank)이 뉴욕 연방준비은행(FRB New York)에 두고 있던 계좌에서 SWIFT 국제결제망을 통해 35건의 송금 지시가 쏟아졌다. 발신자는 방글라데시 중앙은행의 정상 SWIFT 터미널과 정상 자격증명이었고, 전문(메시지) 형식도 정상이었다. 그러나 실제 발신자는 은행 내부에 침투해 있던 공격자였다. 나흘 뒤인 2월 8일(중국 설날 연휴 첫날) 은행이 이상을 인지했을 때, 이미 8,100만 달러는 필리핀으로 빠져나간 뒤였다.

왜 유명한가. 그전까지 대형 사고는 "웜이 퍼졌다"(Morris·Slammer·Conficker), "랜섬웨어가 암호화했다"(WannaCry·NotPetya), "시설이 파괴됐다"(Stuxnet) 같은 서사였다. 이 사건은 처음으로 "국가가 국제 결제망에 접속된 은행을 직접 털었다"는 사실을 드러냈다. 그 충격은 세 갈래로 남았다.

• 탐지 패러다임의 전환: 악성 행위가 정상 소프트웨어·정상 자격증명·정상 전문 형식 안에서 일어났다. 시그니처·블랙리스트 기반 탐지는 원리적으로 무력했고, 이후 금융권은 행위·대사(reconciliation) 기반 통제로 무게중심을 옮겼다.
• 제도의 탄생: 이 사건이 직접 계기가 되어 SWIFT는 CSP(Customer Security Programme)와 의무 통제 프레임워크 CSCF를 만들었고, 전 세계 은행의 결제 시스템 보안 기준이 바뀌었다. 필리핀은 카지노 자금세탁방지(AML) 사각지대를 재검토했다.
• 귀속과 책임: 2018년 미국 법무부는 북한 프로그래머 Park Jin Hyok을 방글라데시 은행 해킹·WannaCry·2014 소니 픽처스 공격 혐의로 기소했고, 2021년에는 방글라데시 중앙은행이 자금 회수를 위해 필리핀 RCBC를 상대로 소송을 제기했다. 2023년 다큐멘터리 Billion Dollar Heist의 소재가 됐다.

2. 감염·전파 경로 — '전파'가 없는 공격

이 사건에는 자기복제도, 스캔도, 워크 전파도 없다. 그래서 악성코드 분류상 '웜'이 아니라 표적형 침투(APT) + 결제 사기로 본다. 확산 방식이 아니라 침투 → 정찰 → 실행이라는 시간축으로 봐야 한다.

• 1단계 · 내부 침투와 설치(2016년 1월): 방글라데시 중앙은행 자체 포렌식 조사는 2016년 1월경 시스템에 악성코드가 설치되어 은행의 내부 운영 절차 정보를 수집했다고 밝혔다. 조사팀(World Informatix + Mandiant)은 공격자가 직원들의 업무를 감시해 송금 절차에 익숙해졌다고 판단했다. 초기 침투 경로로는 악성 문서가 첨부된 스피어피싱 메일이 여러 보도에서 지목됐지만, 공식 포렌식이 확정한 사실은 '악성코드 설치 + 장기 정찰' 쪽이다.
• 2단계 · 결제 인프라 이해: 은행의 SWIFT 접속은 내부망의 전용 소프트웨어(Alliance Access)가 담당한다. 이 서버는 전문 생성·파싱·기록·출력까지 전부 수행한다. 공격자는 이 환경을 관찰한 뒤 송금 실행에 필요한 자격증명과 조작 지점을 확보했다.
• 3단계 · '영업 종료'를 노린 실행(2월 4~5일): 방글라데시 은행이 주말로 문을 닫은 시점에 35건의 송금 지시를 몰아서 발행했다. 인력이 없는 시간대에 대량 송금 + 즉시 기록 삭제가 동시에 일어났기 때문에 내부에서는 "거래가 없었던 것"처럼 보였다.
• 4단계 · 같은 수법의 수평 확산(다른 은행들로): 개별 악성코드가 퍼진 게 아니라 공격 기법(TTP)이 재사용됐다. APT38은 에콰도르 Banco del Austro, 베트남 Tien Phong Bank, 대만 Far Eastern International Bank, 칠레 Banco de Chile 등 아시아·남미 은행의 SWIFT 단말을 잇달아 겨냥했고, MITRE ATT&CK 기준 최소 38개국의 은행·거래소·ATM이 표적이 됐다.

정리하면 이 공격의 '전파 경로'는 네트워크가 아니라 "결제망에 접속된 터미널을 보유한 기관"이라는 자격 조건이다. 그래서 방어의 단위도 백신이 아니라 금융 인프라의 통제(세그멘테이션·2FA·대사)가 된다.

3. 동작 원리 상세 분석 — 코드/구조 레벨

3-1. 이 공격의 전제: 결제 명령은 '소프트웨어가 만드는 데이터'다

• MT 전문과 로컬 원장: SWIFT 결제는 MT103(고객 송금) 같은 전문(message) 형태로 오간다. 전문에는 송신 참조번호, 통화·금액, 수취인, 수취은행 같은 필드가 담기고, 접속 소프트웨어는 이를 로컬 데이터베이스에 기록하고 확인 전문을 프린터로 출력하며 화면(PDF)·조회 화면으로 보여준다.
• 따라서 "돈이 움직였다"는 사실은 세 곳에 흔적을 남긴다: ① 저장된 기록(DB), ② 송출·출력되는 전문(프린터), ③ 사용자가 보는 화면(PDF/뷰어). 이 사건의 악성코드는 세 층을 모두 덮는 것을 목표로 설계됐다.

3-2. BAE Systems가 공개한 evtdiag.exe의 동작 (요약)

사건 직후 BAE Systems의 분석(Sergei Shevchenko)은 표적 환경을 위해 맞춤 제작된 악성코드를 공개했다. 핵심 동작은 다음과 같다.

• 전문 감시: 실행되면 SWIFT 접속 소프트웨어가 다루는 메시지를 살펴보며, 시스템 데이터베이스와 상호작용하는 데 필요한 정보를 추출했다.
• 기록 조작·삭제: 추출한 정보를 이용해 거래 금액을 갱신(변조)하고, 자신이 발생시킨 송금 기록을 삭제했다. 즉 승인된 위조 송금이 로컬 원장에서는 '존재하지 않는 거래'가 됐다.
• 출력 위조: 프린터로 전달되는 거래 확인 메시지를 가짜 내용으로 바꿔 출력되게 했다. 출력물은 지금도 많은 금융 현장에서 '증적'으로 쓰인다 — 그 증적 자체를 공격자가 만든 것이다.
• 지속적 정리: 이 감시·조작 루프는 2016년 2월 6일 오전 6시까지 반복 동작했다. 사고 '이후'까지 흔적을 관리했다는 뜻이다. 분석가는 "증거 삭제와 업무 프로세스 왜곡에 상당한 공을 들였으며, 침해 대응을 방해하려 했다"고 평가했다.

3-3. MITRE ATT&CK 매핑 — "저장·전송·표시" 3층 동시 오염

• T1565.001 Stored Data Manipulation: DYEPACK이 SWIFT 거래용 데이터베이스에서 레코드를 생성·삭제·변조했다.
• T1565.002 Transmitted Data Manipulation: DYEPACK이 프린터로 가는 도중의 SWIFT 메시지를 조작했다.
• T1565.003 Runtime Data Manipulation: 변종 DYEPACK.FOX가 PDF가 열리는 순간 데이터를 조작해, 사용자가 보는 화면에서 위조 거래의 흔적을 지웠다.

이 3종 조합이 이 공격의 '설계 의도'를 그대로 보여준다. 감사(audit)는 보통 세 계층을 교차 확인해서 신뢰를 얻는다 — DB 로그, 출력 기록, 화면/리포트. 공격자는 세 계층을 같은 도구로 동시에 무력화했고, 그래서 내부에서는 '이상 없음'으로 보였다.

3-4. 무엇이 실제로 막았나 — 시스템이 아니라 '사람의 눈'

• 차단의 결정적 순간: 스리랑카로 향한 송금에서 수취인 표기 오타("Foundation" → "Fandation")가 나왔다. 중계은행 도이체방크가 이를 수상히 여겨 방글라데시 중앙은행에 확인을 요청했고, 파나시아은행(Pan Asia Bank)도 "스리랑카에 어울리지 않는 거액"이라며 되돌렸다. 그 결과 남은 30건 $850M이 뉴욕 연준에서 차단됐다.
• 즉, 내부 통제는 뚫렸다: 자금을 막은 것은 악성코드 탐지도, 대사 시스템도 아니었다. 외부 기관 직원의 육안 확인이었다. 방어 관점에서 이 사실은 매우 불편한 교훈이다.
• 초기 오귀속: 사건 초기 일부 보도(The Straits Times)는 기존 금융 악성코드 Dridex를 지목했다. 이후 BAE Systems·Symantec·Kaspersky 분석을 통해 표적 맞춤형 신규 도구임이 드러났다. 초기 보고의 잠정 귀속이 이후 기술 분석으로 뒤집히는 전형적 사례다.

4. 피해 규모/영향 — 숫자와 실제 사례

구분	내용
송금 지시	35건 (약 3~40건으로 표기되는 자료도 있으며, 모두 2016-02-04~05에 집중)
시도 금액	$951M (뉴욕 연준 계좌 기준)
승인·성공	5건 $101M — 필리핀 $81M + 스리랑카 $20M
차단	30건 $850M (오타로 인한 확인 요청 → 연준 차단)
회수	스리랑카 $20M 전액 회수, 필리핀 $81M 중 약 $15M만 회수 (나머지 대부분 미회수)

• 자금 세탁 경로(필리핀): 유출된 자금은 RCBC(리잘 상업은행)의 4~5개 계좌로 입금됐다. 이 계좌들은 2015년 5월 15일 개설된 뒤 사건 당일(2016-02-04)까지 한 번도 거래가 없던 휴면 계좌였고, 명의는 가공 인물이었다. 이후 외환 브로커를 거쳐 페소로 환전(2월 5~13일)되고, 다시 RCBC의 통합 계좌로 모인 뒤 카지노를 통해 세탁되어 일부는 홍콩으로 넘어갔다.
• 조사가 늦어진 이유: 은행이 자금 유출을 인지한 2월 8일은 중국 설날이었고, 카지노·금융권이 연휴에 들어가 있었다. 시간차 세탁에서 '명절'은 공격자에게 유리한 요소로 작동했다.
• 제도적 파급: 필리핀은 카지노를 AML 신고 대상에서 제외한 2012년 규정을 재검토하게 됐고, SWIFT는 CSP/CSCF를 도입해 회원 기관에 연 1회 자기 평가·준수 선언을 요구하게 됐다. "결제망 보안은 개별 은행의 문제가 아니라 네트워크 전체의 문제"라는 원칙이 문서화된 것이다.
• 장기 영향: APT38은 이후에도 금융권을 집중 공략했다. FireEye/Mandiant는 이 그룹이 최소 11개국 은행에서 10억 달러 이상을 시도했고(2018년 보고), ATT&CK은 표적 국가를 38개국으로 집계한다. '한 번의 성공'이 '지속적 산업'으로 이어진 셈이다.

5. PoC — 교육용 모의 재현 (로컬 가상 환경 전용)

PoC A — '정상 데이터'를 조작해 흔적을 지우는 원리 재현

결제 데이터가 ① 내부 원장(journal), ② 대외 통보용 명세(statement), ③ 출력물(print queue)에 각각 남는다는 구조를 가상 SQLite로 모사하고, 금액 변조 → 기록 삭제 → 출력 위조가 어떻게 '정상 업무처럼' 보이게 되는지 재현한다.

# poc_a_mock_ledger.py — 교육용 모의 (실제 악성코드 아님 / 로컬 가상 원장 전용)
import os, sqlite3, shutil

LAB = "/tmp/lab_swift_mock"
if os.path.isdir(LAB):
    shutil.rmtree(LAB)                 # 실습 전용 디렉터리만 초기화
os.makedirs(LAB + "/print_queue")

DB = LAB + "/ledger.sqlite"
db = sqlite3.connect(DB); c = db.cursor()
c.execute("CREATE TABLE journal(seq INTEGER PRIMARY KEY, ref TEXT, amount INTEGER, ben TEXT)")
c.execute("CREATE TABLE statement(id INTEGER PRIMARY KEY, ref TEXT, amount INTEGER)")

def send(ref, amount, ben):
    """정상 송금 1건: 내부 원장과 대외 명세에 동시 기록 + 확인 출력물 생성"""
    seq = c.execute("SELECT COALESCE(MAX(seq),0)+1 FROM journal").fetchone()[0]
    c.execute("INSERT INTO journal VALUES(?,?,?,?)", (seq, ref, amount, ben))
    c.execute("INSERT INTO statement(ref, amount) VALUES(?,?)", (ref, amount))
    open("%s/print_queue/confirm_%s.txt" % (LAB, ref), "w").write(
        "SWIFT CONFIRMATION\nref=%s amount=USD %d beneficiary=%s\n" % (ref, amount, ben))
    db.commit()

# 영업 중 정상 거래 3건 (가상의 금액/수취인)
send("REF-0001", 1200000, "Atlas Foods Trading LLC")
send("REF-0002",  330000, "Riverline Logistics Ltd")
send("REM-0300",  810000, "Shalika Foundation")     # 오타: 'Fandation' 로 보내진 실제 사건의 그 송금

print("[정상] 원장  :", c.execute("SELECT seq, ref, amount FROM journal").fetchall())
print("[정상] 명세  :", c.execute("SELECT ref, amount FROM statement").fetchall())

# --- 여기서부터 '공격자 도구' 흉내 (evtdiag.exe / DYEPACK 의 동작 모사) ---
def attacker_tool(target_ref, new_amount=None, delete=True, fake_print=None):
    """실제 악성코드가 한 일을 '가상 로컬 원장'에서 그대로 흉내낸다."""
    if new_amount is not None:      # 1) 저장된 데이터 조작 (T1565.001)
        c.execute("UPDATE journal SET amount=? WHERE ref=?", (new_amount, target_ref))
    if delete:                      # 2) 자기 거래의 기록 삭제 (T1565.001)
        c.execute("DELETE FROM statement WHERE ref=?", (target_ref,))
    if fake_print:                  # 3) 프린터로 가는 확인 메시지 위조 (T1565.002)
        open("%s/print_queue/confirm_%s.txt" % (LAB, target_ref), "w").write(fake_print)
    db.commit()

attacker_tool("REM-0300",
              new_amount=99000,                                  # 금액을 '평범한' 값으로 바꿔 눈에 띄지 않게
              delete=True,                                       # 대외 명세에서는 거래 자체를 삭제
              fake_print="SWIFT CONFIRMATION\nref=REM-0300 status=REJECTED\n")  # "실패했다"는 가짜 확인증

print("[조작] 원장  :", c.execute("SELECT seq, ref, amount FROM journal").fetchall())
print("[조작] 명세  :", c.execute("SELECT ref, amount FROM statement").fetchall())
print("[조작] 출력물:", open(LAB + "/print_queue/confirm_REM-0300.txt").read().strip())
print("\n→ 원장에는 거래가 남아 있지만, 금액이 다르고 대외 명세에서는 사라졌으며")
print("  프린터에는 '거절됨(REJECTED)'이라는 가짜 확인증만 남았다.")
print("  내부 담당자가 출력물만 본다면 '실패한 거래'로 보인다. 이것이 이 공격의 핵심이다.")

PoC B — 그래서 어떻게 잡는가: '대사(Reconciliation)' 기반 탐지

이 공격의 본질은 데이터 무결성 훼손이다. 따라서 탐지도 시그니처가 아니라 서로 다른 계층의 기록을 교차 검증하고, 기록이 사라진 것(삭제) 자체를 이상 신호로 삼아야 한다. 아래는 실제로 잡히는 세 가지 단서다.

# poc_b_detect.py — 교육용 모의 탐지 (동일한 가상 원장 대상)
import sqlite3, hashlib

LAB = "/tmp/lab_swift_mock"
db = sqlite3.connect(LAB + "/ledger.sqlite"); c = db.cursor()

# [단서 1] 내부 원장 vs 대외 명세 불일치 (거래가 '사라진' 흔적)
j = set(r[0] for r in c.execute("SELECT ref FROM journal"))
s = set(r[0] for r in c.execute("SELECT ref FROM statement"))
print("[탐지1] 원장에만 있고 명세에 없는 참조번호:", sorted(j - s), "→ 삭제 의심")

# [단서 2] 참조번호 '번호 대역'의 구멍(시퀀스 갭)
#   REM-03xx 대역은 일련번호 체계다. 0300 이외가 비어 있으면 '없는 것'이 아니라 '지워진 것'일 수 있다.
seen = sorted(r[0] for r in c.execute("SELECT ref FROM journal WHERE ref LIKE 'REM-%'"))
print("[탐지2] 일련번호 연속성:", seen, "→ 갭 존재 여부를 상시 점검")

# [단서 3] 금액 이상: 같은 수취인에게 이전에 없던 '정리된' 금액 변동
rows = c.execute("SELECT ref, amount FROM journal").fetchall()
print("[탐지3] 금액 스냅샷:", rows, "→ '라운드 다운'된 변조 흔적은 이력 테이블과 대조")

# [권장] append-only + 해시 체인: 각 거래에 이전 거래 해시를 묶어 저장하면
#        누군가 DELETE/UPDATE 하는 순간 체인이 끊어져 '삭제 사실'이 드러난다.
chain = b""
for ref, amount in rows:
    chain = hashlib.sha256(chain + ("%s|%s" % (ref, amount)).encode()).digest()
print("[탐지4] 해시 체인 헤드:", chain.hex()[:16], "→ 외부(상대은행·감사기관)에 통보한 값과 대조")

print("\n→ 교훈: 이 사건에서 자금을 막은 것은 내부 시스템이 아니라")
print("  중계은행 직원의 육안(오타 확인)이었다. 대사 자동화는 '있으면 좋은 것'이 아니라")
print("  '이 공격을 잡는 유일한 계층'이다.")

6. 방어 방법/교훈 — 어떻게 막았고, 무엇을 배우나

• 결제 환경은 '별도의 섬'으로: SWIFT 접속 단말(Alliance Access)을 사무망·인터넷과 분리하고, 전용 장비·전용 계정·물리 접근 통제를 적용한다. 내부 PC 하나가 뚫려도 결제 단말까지 닿지 않게 하는 것이 1차 목표다.
• 자격증명 = 돈: 결제 단말 운영 계정에 하드웨어 기반 2FA/MFA를 적용하고, 공용·공유 계정을 금지하며, 이중 승인(2인 통제) 없이는 송금이 생성·승인되지 않게 설계한다. 자격증명 탈취 자체를 막는 것과, 탈취돼도 실행되지 않게 하는 것을 둘 다 해야 한다.
• 대사(reconciliation)를 자동화하라: 내부 원장 ↔ 대외 명세 ↔ 상대은행/중앙은행 잔액 대조를 일 단위·자동으로 수행한다(PoC B의 단서 1~3). "명세에 없는 거래"와 "시퀀스 갭"은 악성코드를 몰라도 잡히는 신호다.
• 출력물·화면을 맹신하지 말고 '무결성'을 관리하라: 이 사건에서 공격자는 프린터 출력(T1565.002)과 PDF 표시(T1565.003)까지 위조했다. 출력물은 증적이 아니라 '변조 가능한 표시 계층'이다. 로그·전문은 append-only/WORM 저장과 해시 체인으로 보존하고, 외부 기관과의 잔액 대조를 최종 신뢰 원천으로 삼는다.
• 이상 거래 규칙은 '시간'을 포함해야 한다: 주말·명절·심야의 대량 송금, 휴면 계좌로의 대금, 갑자기 조정된 금액은 강한 이상 신호다. 이 사건은 영업 종료 시점과 중국 설날을 정확히 노렸다.
• SWIFT CSP/CSCF 준수를 형식이 아니라 운영으로: CSP는 ① 환경 보호(망분리·강화), ② 운영 제한(자격증명·권한·취약점 관리), ③ 탐지·대응(이상 탐지·백업·사고 대응)의 세 축을 요구한다. 자기 평가 체크박스가 아니라 실제 통제로 돌려야 의미가 있다.
• 교훈 요약:
  • 정상 자격증명으로 하는 공격은 '취약점 패치'로 막을 수 없다: 남는 방어는 권한·대사·모니터링이다.
  • 돈이 있는 곳에는 데이터 무결성이 필요하다: 금융 시스템에서 기밀성보다 무결성(Integrity)이 결정적 자산이었다.
  • 계보: 무차별 확산형 웜(Morris·Slammer·Conficker) → 파괴형 랜섬(M.E.Doc 공급망의 NotPetya) → 정품 서명 악용(SUNBURST, 2020) → 결제 데이터 직접 조작(이번 2016년 사건). 확산은 사라지고 '정상 신뢰의 악용'이 남았다.

출처

• Wikipedia — Bangladesh Bank robbery (사건 타임라인·금액·자금 세탁 경로) — https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery
• VICE/Motherboard — Cunning Malware Covered Hackers' Tracks in $81M Bangladeshi Bank Heist (BAE Systems 분석 인용; evtdiag.exe·프린터 위조) — https://www.vice.com/en/article/cunning-malware-covered-hackers-tracks-in-81m-bangladeshi-bank-heist/
• Malpedia (Fraunhofer FKIE) — win.dyepack (DYEPACK / BanSwift, Lazarus Group, 참고문헌 목록) — https://malpedia.caad.fkie.fraunhofer.de/details/win.dyepack
• MITRE ATT&CK — APT38 (G0082) · T1565.001/.002/.003 Data Manipulation (DYEPACK) — https://attack.mitre.org/groups/G0082/
• U.S. Department of Justice — North Korean Regime-Backed Programmer Charged (Park Jin Hyok, 2018) — DOJ Press Release (2018)
• OCD Tech — The Bangladesh Bank SWIFT Heist: A $81M Cyber Theft Explained (방어 관점 정리) — https://ocd-tech.com/cybersecurity-incident-case-studies/the-bangladesh-bank-swift-heist-a-81m-cyber-theft-explained
• SWIFT — Customer Security Programme (CSP) 공식 페이지 — https://www.swift.com/myswift/customer-security-programme-csp

함께 읽기: 🦅 SolarWinds SUNBURST (2020) — '정품 서명'을 악용한 공급망 백도어 · ☠️ NotPetya (2017) — M.E.Doc 공급망에서 시작된 파괴형 와이퍼 · ⚛️ Stuxnet (2010) — 물리 세계를 겨냥한 최초의 사이버 무기