Snowflake 고객 165곳: 4년 묵은 비밀번호와 꺼진 MFA

아프로·2026년 11월 1일

해외 보안사고 사례

목록 보기

3/13

Snowflake 고객 165곳 표지

79.7%. 공격에 쓰인 계정 가운데 과거에 이미 유출된 적이 있던 계정의 비율입니다(맨디언트(Mandiant) 조사). 2024년 봄, 클라우드 데이터 웨어하우스 스노우플레이크(Snowflake)의 고객 계정이 차례로 털렸습니다. 약 165개 조직이 침해 가능성 통보를 받았고, AT&T 고객 약 1.1억 명의 통화·문자 기록도 이 경로로 빠져나갔습니다. 그런데 스노우플레이크 플랫폼에서는 취약점도, 설정 오류도, 내부 침해 증거도 나오지 않았습니다. 공격자는 고객 계정에 로그인했을 뿐입니다.

사고 원인: 교체하지 않은 비밀번호와 MFA 미적용. 정보탈취 악성코드로 새어 나간 비밀번호가 몇 년째 그대로였고, 그 비밀번호 하나로 열리는 계정에는 MFA도 접속 IP 제한도 없었습니다. 비밀번호·API 키처럼 코드와 로그 밖에 숨겨야 하는 값을 이 시리즈는 시크릿이라고 부릅니다.

한눈에 보기

항목	내용
기간	2024년 4월 전후 고객 계정 로그인 시작, 6월 10일 맨디언트 보고서 공개
규모	약 165개 조직에 침해 가능성 통보(맨디언트·스노우플레이크), 100개 이상 고객 테넌트 접근 확인
대표 피해	AT&T 무선 고객 통화·문자 기록 약 1.1억 명(내용·이름 제외, 일부 기지국 ID 포함)
원인	MFA 없음, 2020년부터 유출된 계정정보 미교체, 네트워크 허용 목록 없음(맨디언트)
비용	AT&T 집단소송 합의 총 1.77억 달러 중 이 사건 몫 2,800만 달러
현재 상태	2026년 8~10월 스노우플레이크가 사람 사용자 MFA 의무화, 서비스 계정 비밀번호 로그인 차단

테넌트(tenant)는 클라우드 서비스 안에서 고객 회사 하나에 주어지는 독립된 공간입니다. 이 사건에서 공격자가 들어간 곳은 고객사별 테넌트였습니다.

무슨 일이 있었나

2020-11 맨디언트가 확인한 가장 오래된 정보탈취 악성코드 감염 시점입니다. 이때 새어 나간 계정정보 일부가 2024년에도 유효했습니다.
2024-04 맨디언트가 첫 위협 정보를 입수했습니다. 이 무렵부터 고객 계정 로그인이 시작됐습니다. AT&T는 4월 14일부터 25일 사이에 데이터가 유출됐다고 공시했습니다(AT&T 8-K).
2024-05 맨디언트가 이 공격을 별도 그룹으로 추적하기 시작했습니다. 추적명은 UNC5537로, 금전을 노리는 협박 그룹입니다. 5월 31일 티켓마스터(Ticketmaster)의 모회사 라이브네이션(Live Nation)이 8-K를 냈습니다.
2024-06-10 맨디언트가 조사 보고서를 공개했습니다.
2024-07-12 AT&T가 8-K를 냈습니다. 미국 법무부 요청으로 공시가 늦춰졌습니다.
2026-08~10 스노우플레이크가 모든 사람 사용자에게 MFA를 의무화하고, 서비스 계정의 비밀번호 로그인을 막았습니다(3단계, 계정별 순차 적용).

8-K는 미국 상장사가 투자자에게 중요한 사건을 알리는 수시 공시 서류입니다. 티켓마스터 5.6억 명이라는 숫자는 해커 쪽 주장이라 확인되지 않았습니다 [추정].

고객사 직원 PC 감염에서 수년째 유효한 계정정보, MFA 없는 고객 계정 로그인, 대량 조회와 협박으로 이어지는 경로와 막을 수 있었던 네 지점

흐름은 단순합니다. 고객사 직원의 PC가 인포스틸러(infostealer, 브라우저에 저장된 아이디·비밀번호를 몰래 빼 가는 정보탈취 악성코드)에 감염됩니다. 빠져나간 계정정보는 몇 년이 지나도 바뀌지 않았습니다. 공격자는 그 아이디와 비밀번호로 고객사의 스노우플레이크 계정에 로그인했고, 계정에 MFA가 없어 그대로 들어갔습니다. 접속할 수 있는 IP도 정해 두지 않았으니 공격자 서버에서도 로그인이 됐습니다. 그다음은 데이터 조회와 유출, 그리고 협박이었습니다.

왜 뚫렸나

맨디언트 보고서(2024-06-10)에 따르면, 피해 계정에는 세 가지 공통점이 있었습니다.

MFA가 없었습니다. 아이디와 비밀번호만 맞으면 로그인됐습니다. MFA(다중 인증)는 비밀번호 말고도 휴대폰 승인이나 보안키 같은 두 번째 증거를 요구하는 방식입니다.
유출된 계정정보를 교체하지 않았습니다. 공격에 쓰인 계정의 79.7% 이상이 과거에 유출된 적이 있었습니다. 가장 오래된 감염은 2020년 11월이었습니다. 3년 넘게 같은 비밀번호가 살아 있었다는 뜻입니다.
네트워크 허용 목록이 없었습니다. 신뢰된 위치에서만 접속하도록 IP를 묶어 두지 않았습니다.

감염된 PC는 모두 고객사 쪽에 있었습니다. 일부는 개인용 PC를 업무에 함께 쓴 경우였습니다(맨디언트). 스노우플레이크는 플랫폼 취약점·설정 오류·내부 침해 증거가 없다는 입장을 유지하고 있습니다.

세 원인은 하나씩만 막혀 있어도 공격이 멈추는 구조였습니다. 비밀번호를 바꿨다면 유출 정보가 무효가 됐고, MFA가 있었다면 비밀번호만으로는 부족했으며, IP 허용 목록이 있었다면 공격자 서버에서는 로그인할 수 없었습니다. 피해 계정에는 세 겹이 모두 비어 있었습니다.

개발자 시점: 내 서비스였다면

데이터 웨어하우스나 클라우드 DB에 접속하는 계정은 대개 두 종류입니다. 사람이 대시보드에 로그인하는 사람 계정, 그리고 배치 작업이나 ETL(데이터를 추출·변환해 옮기는 작업)이 쓰는 서비스 계정입니다. 사고 회사의 코드가 아니라 같은 실수를 보여 주는 일반 예시입니다. 값은 모두 가짜입니다.

# 위험한 모양 · 일반 예시
conn = warehouse.connect(
    account="example-acct",
    user="etl_service",
    password=os.environ["WH_PASSWORD"],
)
# 몇 년째 같은 비밀번호
# 사람 계정도 비밀번호만으로 로그인, MFA 없음
# 어느 IP에서나 접속 가능

비밀번호를 환경 변수로 뺐으니 코드에는 시크릿이 없습니다. 그래도 문제는 그대로입니다. 비밀번호 하나만 알면 누구든, 어디서든 이 계정으로 접속할 수 있습니다. 사람 계정도 같은 방식이라면, 직원 PC 한 대가 감염되는 순간 그 직원이 볼 수 있는 데이터가 모두 공격자 손에 들어갑니다.

# 고친 모양 · 일반 예시
conn = warehouse.connect(
    account="example-acct",
    user="etl_service",
    private_key=secrets.get("wh/etl/FAKE-key"),
)

# 계정 정책 · 일반 예시
users:
  etl_service:            # 서비스 계정
    auth: key_pair        # 비밀번호 로그인 끔
    key_rotation_days: 90
    allowed_ips: [192.0.2.10/32]
  alice:                  # 사람 계정
    auth: sso
    mfa: required
alerts:
  - new_client_or_ip
  - result_rows_over: 1000000

고친 모양은 네 군데가 다릅니다.

서비스 계정은 키 쌍으로. 키 쌍 인증은 공개키를 서버에 등록하고, 개인키는 비밀 저장소에 둔 채 서명으로 로그인하는 방식입니다. 개인키는 사람이 외우거나 브라우저에 저장하지 않으므로 인포스틸러가 노리는 자리에 남지 않습니다. 워크로드 아이덴티티(OIDC처럼 실행 환경이 발급받는 단기 자격증명)를 쓸 수 있다면 더 좋습니다.
사람 계정은 SSO와 MFA. 회사 SSO(한 번 로그인으로 여러 서비스에 들어가는 통합 인증)를 거치게 하고 MFA를 강제합니다. 개별 비밀번호 로그인은 끕니다.
접속 IP 허용 목록. 서비스 계정은 배치 서버 IP에서만 접속하게 묶습니다. 계정정보가 새도 다른 곳에서는 쓸 수 없습니다.
교체 주기와 이상 조회 알림. 키를 정해진 주기로 바꾸고, 처음 보는 클라이언트·처음 보는 IP·평소보다 큰 결과 집합에 알림을 겁니다.

같은 사건의 뒷이야기도 있습니다. 다음 편 Salesloft Drift(04편)에서는 고객사 지원 케이스에 평문으로 붙어 있던 Snowflake 토큰을 공격자가 다음 공격에 쓰려 했습니다(GTIG). 한번 샌 계정정보는 다른 사건에서 다시 노려집니다.

국내에서도 같은 일이

국내에서는 GS리테일·티머니·알바몬 크리덴셜 스터핑이 같은 모양이었습니다. GS샵 회원 계정에는 2024년 6월부터 약 8개월 동안 다른 곳에서 새어 나간 아이디·비밀번호로 대량 로그인이 이어졌고, 158만여 명의 정보가 빠져나갔습니다. 서버 침해는 없었지만 개인정보위는 로그인 이상을 탐지하지 못한 책임을 물어 GS리테일에 과징금 128억 3,600만 원을 부과했습니다. 두 사건 모두 "비밀번호가 맞으면 통과"가 원인이었습니다. 다른 점은 대상입니다. GS리테일은 소비자 회원 계정이었고, 스노우플레이크 사건은 회사 데이터 전체에 닿는 업무 계정이었습니다.

막을 수 있었던 네 지점

위 흐름도의 그린 표시와 같은 번호입니다.

감염 뒤 비밀번호 교체. 퇴사나 감염 이후 비밀번호를 바꿨다면, 4년 전 감염에서 나온 계정정보로는 들어올 수 없었습니다.
MFA. 데이터 웨어하우스 계정에 MFA를 걸었다면, 유출된 비밀번호는 쓸모가 없었습니다.
IP 허용 목록. 사무실·VPN IP만 허용했다면, 공격자 서버에서의 로그인은 막혔습니다.
새 도구·새 IP의 대량 조회 경보. 처음 보는 곳에서 큰 조회가 일어날 때 경보가 울렸다면, 유출 도중에 끊을 수 있었습니다.

1번은 시크릿의 수명을 줄이고, 2·3번은 새어 나간 시크릿을 쓰지 못하게 하며, 4번은 그래도 들어온 공격을 빨리 찾게 합니다.

같은 사고를 막는 점검 5줄

데이터 웨어하우스·클라우드 콘솔·CI/CD 같은 SaaS에 SSO와 MFA를 강제하고, 개별 비밀번호 로그인은 끈다.
서비스 계정은 사람 계정과 분리하고, 비밀번호 대신 키 쌍이나 워크로드 아이덴티티로 인증하며 접속 IP를 묶는다.
인포스틸러 로그 등 유출 정보에 회사 도메인 계정이 나오면 즉시 비밀번호를 바꾸고 세션을 끊는다.
업무 계정을 개인 PC에서 쓰지 않는다. 감염된 개인 PC 하나가 회사 데이터의 열쇠가 된다.
처음 보는 클라이언트, 처음 보는 IP, 평소보다 큰 결과 집합에 알림을 건다.

제재와 비용

AT&T 합의: 집단소송 합의 총 1.77억 달러(약 2,478억 원, 1달러 1,400원 기준) 가운데 이 사건 몫은 2,800만 달러입니다. 2026년 10월 최종 승인이 났다는 보도가 있습니다 [추정].
형사 절차: 미국 법무부에 따르면 주범으로 지목된 사람은 2026년 8월 5일 유죄를 인정했습니다. 법무부는 이 사람이 몸값 250만 달러 이상을 받았고 피해액이 950만 달러라고 밝혔습니다. 선고 결과는 2026년 10월 말 기준 확인되지 않았습니다. AT&T 데이터 판매에 가담한 공범은 2026년 9월 70개월형을 받았습니다.
플랫폼의 대응: 스노우플레이크는 미국 사이버보안·인프라보안청(CISA)의 Secure by Design 서약과 함께 단일 비밀번호 로그인을 단계적으로 폐지했습니다. 2026년 8~10월 모든 사람 사용자에게 MFA를 의무화하고 서비스 계정의 비밀번호 로그인을 차단했습니다.
서비스 영향: 서비스 중단은 없었습니다. 피해는 고객사별 개인정보 유출과 협박으로 나타났습니다.

MFA를 켜는 비용과 비교하면 합의금은 단위가 다릅니다. 위 내용은 공개 보고서·발표를 정리한 것이며 법률 자문이 아닙니다.

정리

스노우플레이크 고객 약 165곳이 침해 가능성 통보를 받았지만, 플랫폼 침해 증거는 나오지 않았습니다(맨디언트·스노우플레이크).
공격에 쓰인 계정의 79.7% 이상이 이미 유출된 적이 있었고, 가장 오래된 감염은 2020년 11월이었습니다. 계정에는 MFA도 IP 허용 목록도 없었습니다.
계정 보안은 클라우드 회사가 아니라 계정을 쓰는 쪽의 몫입니다. 비밀번호 하나로 열리는 계정은 이미 열려 있다고 봐야 합니다.

더 깊게

인프런 「백엔드 개발자를 위한 서버 보안 실무」 수업

3-5 무차별 대입과 크리덴셜 스터핑 막기
3-6 MFA와 세션 탈취 대응: 피싱에 강한 인증과 토큰 바인딩
5-3 시크릿 관리: .env 유출, 저장소 스캔, 키 회전
6-7 클라우드 계정이 진짜 자산이다: IAM 최소 권한과 감사 로그

관련 velog 시리즈: 해킹 시도를 몇 초 안에 잡는 서버(실시간 탐지·차단)

방어선 1-②: 신원별 슬라이딩 윈도우로 열거·퍼징 잡기: 계정·IP 기준으로 비정상 조회를 세는 규칙
방어선 2-②: IP 평판·위협 인텔리전스의 쓸모와 한계: 처음 보는 IP를 판단하는 법

같은 패턴의 편: MFA 빈틈은 Change Healthcare(02편)에서도 시작점이었습니다.

보안을 더 알고 싶다면

오늘 본 사고의 원인은 대부분 서버와 코드의 기본기에서 막을 수 있는 것들이었습니다. 직접 손으로 막아 보고 싶다면 이런 강의도 있습니다.

백엔드 개발자를 위한 서버 보안 실무: 해킹 방어부터 정보유출 방지까지

서버를 공격하는 흐름을 로그로 보고, 내 서버와 Spring·Express 코드에서 직접 막아 봅니다.
SSH 하드닝, 인젝션, 인증·인가, 시크릿과 개인정보 보호, 침해사고 첫 한 시간까지 8개 섹션 54개 수업입니다.
이 글과 이어지는 수업: 3-5 무차별 대입과 크리덴셜 스터핑 막기 · 3-6 MFA와 세션 탈취 대응: 피싱에 강한 인증과 토큰 바인딩 · 5-3 시크릿 관리: .env 유출, 저장소 스캔, 키 회전