8월 대형 기업들을 연달아 뚫은 건, 사실 하나의 각본이었다
안녕하세요, 베이스스톤 구독자님! 👋
지난달까지는 매달 있었던 여러 보안 사고를 폭넓게 훑어봤는데요, 이번 달부터는 한 가지 주제를 조금 더 깊게 파보려고 합니다. 8월에는 의료용품 유통업체 맥케슨, 통신 서비스 업체 링센트럴, 그리고 맥도날드와 갭을 포함한 포춘 500대 기업 9곳이 연달아 SSO 계정 침해를 겪었어요. 언뜻 보면 서로 다른 업종의 서로 다른 사고처럼 보이지만, 공격 방식을 뜯어보면 놀랍도록 똑같습니다. 헬프데스크를 사칭한 전화 한 통으로 시작해서, 정교하게 복제된 로그인 페이지를 거쳐, 실시간으로 MFA까지 가로채는 6단계 각본이 거의 그대로 반복됐거든요. 오늘은 이 플레이북이 실제로 어떻게 작동하는지, 왜 지금 이렇게 자주 성공하고 있는지, 그리고 이걸 막아낸 회사는 무엇이 달랐는지 단계별로 살펴보겠습니다 🔐
📌 오늘의 글, 한눈에 요약해보기
- 맥케슨(8/25), 링센트럴(7월 말 발견), 포춘 500대 기업 9곳(8월)까지, 8월 SSO 침해 사고들은 서로 다른 사건이 아니라 같은 6단계 보이스피싱 각본의 반복이었음
- 이 각본은 "번호 매칭(number matching)" 방식의 MFA까지 실시간으로 가로채는 중간자 공격(AiTM) 구조로, 일반적인 푸시 알림형 MFA로는 막을 수 없음
- 반면 오리진(도메인)에 암호학적으로 묶이는 패스키나 보안키 같은 피싱 저항형 인증은 이 공격에 구조적으로 뚫리지 않음
- 배후로 지목되는 Scattered Spider, ShinyHunters, LAPSUS$는 2025년 8월 하나의 연합체로 합쳐졌고, 그 결과 같은 각본이 훨씬 많은 기업을 동시다발적으로 노리고 있음
🔍 이 플레이북은 실제로 이렇게 작동합니다
1단계, 다급함을 앞세운 전화
공격자는 IT팀이나 인사팀, 헬프데스크 직원을 사칭해 직원에게 전화를 겁니다. "복리후생 마감이 임박했다", "보험 청구 시스템을 이전 중이다", "보안 재인증이 필요하다"처럼 다급하게 느껴지는 이유를 대고, 전화를 끊지 않은 채로 문자나 음성으로 특정 링크에 접속하라고 안내해요.
2단계, 진짜처럼 보이는 가짜 주소
이때 안내하는 도메인은 mckesson.claims처럼 오타가 아니라, 회사 이름과 업계 맥락에 자연스럽게 어울리는 주소로 등록돼 있습니다. 언뜻 봐서는 의심하기 어려운 이유예요.
3단계, 정교하게 복제된 로그인 화면
링크를 열면 회사 로고, "연결하는 중" 배너, 실제와 똑같은 레이아웃까지 재현한 Okta 로그인 페이지가 뜹니다. 주소창에는 그럴듯한 SSO URL까지 그려 넣어, 눈으로 봐서는 진짜와 구별이 거의 불가능해요.
4단계, 실시간으로 전달되는 자격증명
직원이 아이디와 비밀번호를 입력하면, 그 값은 저장됐다가 나중에 쓰이는 게 아니라 그 순간 공격자에게 실시간으로 전달됩니다.
5단계, 번호 매칭 MFA까지 실시간으로 중계
여기가 이 공격의 핵심이에요. "번호 매칭"은 원래 공격자가 무작위로 푸시 알림만 눌러 넘어가는 이른바 "MFA 피로도 공격"을 막기 위해 설계된 방식입니다. 화면에 뜬 숫자를 인증 앱에서 확인해야만 승인할 수 있으니, 화면을 보지 못하는 공격자는 통과할 수 없다는 논리예요. 하지만 이 공격 도구는 단순히 정보를 훔쳐서 나중에 재사용하는 게 아니라, 피해자와 공격자 사이를 실시간으로 중계하는 중간자(AiTM) 구조로 만들어져 있습니다. 피해자가 입력한 정보로 공격자가 그 순간 진짜 Okta 로그인을 시도하고, 진짜 백엔드가 보낸 진짜 숫자를 그대로 피해자 화면에 띄워주는 거예요. 피해자는 자신의 인증 앱에 뜬 숫자와 가짜 페이지의 숫자가 일치하는 걸 보고 안심하며 승인하지만, 실제로는 공격자의 로그인을 대신 승인해주는 셈이 됩니다.
6단계, 승인 화면 뒤에서 조용히 완료되는 침투
피해자 화면에는 짧은 "승인 완료" 화면이 뜨고, 그사이 공격자는 실제 백엔드에서 인증을 마무리합니다. 이렇게 확보한 SSO 세션으로 맥케슨에서는 세일즈포스와 스노우플레이크에, 다른 사고에서는 각각의 내부 시스템에 접근했어요.
🧭 왜 지금 이 각본이 이렇게 자주 통하는가
패스키가 뚫리지 않은 이유가 오히려 이 공격의 한계를 보여줍니다
흥미로운 건, 이 공격 도구가 실제로는 패스키(FIDO2 보안키, 생체인증)를 일부러 선택 화면에서 "이 지역에서는 사용할 수 없음"으로 표시해 우회한다는 점이에요. 패스키를 굳이 비활성화하는 이유는 기술적으로 뚫기 어려워서가 아니라, 애초에 뚫을 수 없기 때문입니다. 패스키는 로그인 시도가 일어나는 도메인 자체에 암호학적으로 묶여 있어서, yourcompany.okta.com에 등록된 패스키는 yourcompany.claims라는 가짜 도메인에서는 서명 자체가 거부돼요. 화면을 아무리 정교하게 복제해도, 이 구조적인 검증은 우회할 수 없습니다. 다시 말해 이 공격의 정교함은 "번호 매칭 MFA까지는" 통한다는 뜻이지, "모든 인증 수단"을 뚫는다는 뜻이 아니에요.
같은 각본이 이렇게 많은 곳을 노리는 이유는 '연합'에 있습니다
2025년 8월, 정교한 사회공학 공격에 강한 Scattered Spider와 대규모 데이터 탈취 자동화에 강한 ShinyHunters, 그리고 심리적 압박과 언론 노출에 능한 LAPSUS$가 하나의 연합체로 합쳐졌습니다. 이후 이들은 여러 개의 텔레그램 채널을 통해 마치 랜섬웨어 프랜차이즈처럼 조직화된 "공격 대행" 구조로 움직이고 있어요. 각기 다른 회사에서 벌어진 것처럼 보이는 8월의 사고들이 실은 같은 도구, 같은 각본, 같은 배후에서 나온 이유입니다.
막아낸 회사와 뚫린 회사의 차이는 '무엇을 탐지했는가'에 있습니다
보안 기업 릴라이퀘스트는 같은 방식의 공격을 받았지만 실제 데이터 유출 전에 접근을 차단하는 데 성공했습니다. 회사 측이 구체적으로 어떤 신호를 근거로 탐지했는지는 공개하지 않았지만, "신원 정보 흐름에 대한 모니터링"과 "빠르게 escalation되는 대응 체계"를 성공 요인으로 꼽았어요. 이 공격은 악성코드나 취약점을 남기지 않기 때문에, 백신이나 패치로는 막을 수 없습니다. 오직 행동 기반 탐지와 사람의 판단만이 마지막 방어선이 돼요.
✅ 우리 조직의 헬프데스크, 지금 이것부터 점검하세요
- 헬프데스크가 비밀번호 재설정이나 MFA 해제를 승인하기 전에, 전화 통화 외에 별도 채널(등록된 매니저 승인, 사내 앱 알림 등)로 본인확인을 한 번 더 거치는가
- 관리자 계정이나 고위험 계정만이라도 패스키, 보안키(FIDO2/YubiKey) 기반 인증으로 전환하고, 번호 매칭이나 SMS 같은 대체 수단으로 되돌아갈 수 있는 예외 경로를 없앴는가
- 헬프데스크 직원이 "다급함"을 앞세운 요청에 대해 일단 통화를 끊고 등록된 번호로 다시 거는 절차를 표준으로 갖추고 있는가
- SSO 로그인 시도에 대한 행동 기반 이상탐지(비정상적인 위치, 새로운 기기, 짧은 시간 내 반복 시도 등)가 실시간으로 알람을 울리고, 그 알람이 빠르게 담당자에게 전달되는가
⚠️ 현장에서 자주 놓치는 지점
"번호 매칭을 쓰고 있으니 안전하다"는 착각
번호 매칭 MFA는 무작위 푸시 승인 공격은 막아주지만, 이번처럼 실시간 중계형 공격에는 무력합니다. MFA의 종류만 보고 안전하다고 판단하기보다는, 그 MFA가 로그인 페이지의 진위 자체를 검증해주는지(오리진 바인딩 여부)를 기준으로 삼아야 해요.
헬프데스크 교육은 '피싱 메일 구별법'에만 머물러 있는 경우가 많습니다
많은 조직의 보안 교육이 이메일 피싱에 집중된 나머지, 전화로 걸려오는 사회공학 공격에 대한 대응 훈련은 상대적으로 소홀합니다. 헬프데스크 직원이야말로 계정 복구 권한을 쥐고 있는 만큼, 가장 정교한 표적이 된다는 점을 감안해 별도의 훈련이 필요해요.
"이 공격에서 기술적 결함은 없습니다. 유일한 취약점은, 전화기 반대편의 목소리를 믿어야 했던 사람입니다." — Basestone Security Research Team
🚀 작게 시작하는 방법
가장 먼저 할 수 있는 건, 우리 조직의 관리자 계정이나 IT 담당자 계정처럼 뚫렸을 때 피해가 가장 큰 소수의 계정부터 패스키나 보안키로 전환해보는 거예요. 모든 직원에게 한 번에 적용하기 어렵다면, 가장 위험한 계정부터 시작하는 것만으로도 이 공격의 핵심 경로를 차단할 수 있습니다.
지난달 있었던 외교부 해킹과 KDDI 유출 사고도 함께 살펴보고 싶다면 외교부 해킹부터 KDDI 대규모 유출까지 7월 한 달의 보안 사고 총정리를 이어서 읽어보세요.
