멀웨어 없이 클라우드가 뚫렸습니다: Storm-2949가 악용한 Entra ID 비밀번호 재설정
🤖 AI Summary
Microsoft 위협 인텔리전스가 2026년 5월 18일 Storm-2949라는 위협 행위자의 침해 사례를 공개했습니다. 이 공격은 멀웨어도 취약점(CVE)도 사용하지 않았어요. 공격자는 Entra ID의 셀프서비스 비밀번호 재설정(SSPR) 절차를 표적 사용자 대신 시작하고, IT 지원 담당자를 사칭해 사용자가 정상으로 보이는 MFA 승인을 누르게 유도했습니다. 그렇게 계정을 장악한 뒤 Microsoft Graph API로 테넌트를 정찰하고, 특권 RBAC 역할을 발판으로 Azure Key Vault에서 4분 만에 수십 개 시크릿에 접근했죠. 탈취된 시크릿에는 데이터베이스 연결 문자열과 신원 자격증명이 포함돼 있어 공격 범위가 한 번에 넓어졌습니다. OneDrive에서는 수천 개 파일이 한 번에 빠져나갔고, Azure 스토리지 기반 탈취는 여러 날 이어졌어요. 이번 글에서는 사건의 사실관계와 운영팀이 점검할 방어 항목을 Microsoft 공식 자료 기준으로 정리합니다.
블로그 목차
비밀번호 재설정 한 번이 클라우드 전체 침해로 이어졌습니다
MFA를 켜두면 계정 하나가 뚫려도 큰 문제는 없다고 생각하기 쉽습니다. 인증 수단이 하나 더 있으니까요. 그런데 그 MFA 승인 버튼을 사용자가 직접 눌러준다면 이야기가 달라지죠.
Microsoft 위협 인텔리전스는 2026년 5월 18일 Storm-2949 침해 분석을 공개했습니다. Storm-2949는 표적 조직의 고가치 자산에서 민감 데이터를 최대한 빼내는 데 집중한 위협 행위자예요. Microsoft는 이 공격이 두 단계로 진행됐다고 안내합니다. 하나는 표적 신원 침해, 다른 하나는 클라우드 인프라 침해죠.
이 사건에서 눈여겨볼 점은 공격에 멀웨어가 등장하지 않았다는 사실입니다. 악용한 취약점(CVE)도 없었어요. 공격자는 처음부터 끝까지 클라우드의 정상 기능만 사용했습니다. 그래서 이번 침해는 특정 제품의 결함 이야기가 아니라, 신원과 권한을 어떻게 운영하느냐의 문제로 읽어야 하죠.
공격은 비밀번호 재설정을 정상 절차처럼 보이게 만들었습니다
공격의 출발점은 Entra ID의 셀프서비스 비밀번호 재설정, 줄여서 SSPR입니다. 원래는 사용자가 비밀번호를 잊었을 때 스스로 재설정하라고 만든 편의 기능이죠.
Microsoft는 Storm-2949가 이 절차를 표적 사용자 대신 시작했다고 높은 확신도로 평가했습니다. 알려진 SSPR 악용 방식과 일치하는 사회공학 흐름이죠. 공격자는 사내 IT 지원 담당자를 사칭해 사용자에게 연락하고, 계정에 긴급 확인이 필요하다며 일상적인 비밀번호 재설정 절차의 일부라고 안내하면서 MFA 승인을 누르도록 유도했습니다. 사용자 입장에서는 IT팀이 보낸 정상 요청처럼 보이는 프롬프트였죠.
사용자가 승인을 누르면 그때부터 통제권이 넘어가죠. 공격자는 비밀번호를 재설정하고, 전화번호·이메일·Microsoft Authenticator 등록 같은 기존 인증 수단을 제거했습니다. MFA라는 통제 장치 자체를 걷어낸 셈이에요. 이어 MFA를 다시 등록하라는 안내가 뜨면, 공격자는 자신의 기기에 Authenticator를 등록해 지속적인 접근 권한을 확보했습니다.
여기까지의 흐름을 한눈에 정리하면 다음과 같습니다.
한 번의 승인 클릭이 비밀번호 변경과 인증 수단 교체로 이어졌고, 결과적으로 계정의 주인이 바뀐 거죠.
표적은 IT 인력과 경영진이었습니다
공격자가 아무 계정이나 노린 것은 아닙니다. Microsoft는 침해된 사용자에 IT 인력과 고위 경영진이 포함돼 있었고, 이는 의도적인 표적 선정을 보여준다고 안내했습니다. 권한이 넓은 계정을 골랐다는 뜻이죠. Storm-2949는 같은 SSPR 악용 방식을 조직 내 여러 사용자에게 반복해서 적용했습니다.
이런 사회공학 기반 침입은 새로운 이야기는 아니에요. 사람을 노리는 공격이 어떻게 진화해 왔는지는 5월 7일(목) 발행 사회공학 해킹 패턴 글에서 따로 정리했습니다. Storm-2949 사례는 그 연장선에서, MFA 승인이라는 마지막 관문까지 사람을 통해 통과하는 형태로 볼 수 있습니다.
계정을 장악한 공격자는 곧바로 내부 정찰에 들어갔습니다. 커스텀 Python 스크립트로 Microsoft Graph API에 자동 요청을 보내 테넌트 안의 사용자와 애플리케이션을 열거했어요. 이름 패턴과 역할 속성으로 검색하면서 특권 계정과 추가 표적을 찾는 과정이었죠. 침해된 계정 하나가 조직 전체의 지도를 그리는 도구가 됐습니다.
탈취된 신원이 4분 만에 Key Vault 수십 개 시크릿을 열었습니다
여기서부터 두 번째 단계, 클라우드 인프라 침해가 시작됩니다.
침해된 신원 가운데 일부는 여러 Azure 구독에 걸쳐 특권 커스텀 RBAC 역할을 부여받은 상태였습니다. 공격자에게는 이 권한이 그대로 열쇠가 됐죠. Microsoft에 따르면 공격자는 4분이라는 짧은 시간 동안 Azure Key Vault의 액세스 구성을 조작하고 수십 개 시크릿에 접근했습니다.
문제는 그 시크릿의 내용이었어요. 탈취된 시크릿에는 데이터베이스 연결 문자열과 신원 자격증명 등이 포함돼 있었습니다. Key Vault 하나가 뚫리자 거기 보관된 자격증명을 타고 공격 범위가 한 번에 넓어진 거죠.
데이터 유출 규모도 작지 않았습니다. 한 사례에서 공격자는 OneDrive 웹 인터페이스로 수천 개 파일을 한 번의 작업으로 자신의 인프라에 다운로드했어요. Azure 스토리지를 겨냥한 데이터 탈취는 초기 침해 이후 여러 날에 걸쳐 계속됐습니다.
계정 하나에서 시작된 침해가 파일 저장소와 운영 데이터베이스, 스토리지 계정까지 번진 흐름입니다.
멀웨어가 없었다는 점이 핵심입니다
이번 침해를 다시 보면, 공격의 어느 단계에도 악성 코드가 없습니다. SSPR도, MFA도, Graph API도, OneDrive도, Key Vault도 전부 정상 기능이에요. 공격자는 이 기능들을 의도된 용도와 다르게 이어 붙였을 뿐이죠.
이 점이 방어 관점에서 까다롭습니다. 멀웨어가 없으면 엔드포인트 보안 도구가 잡아낼 악성 파일이 없죠. 공격자의 행동은 정상 자격증명으로 정상 API를 호출하는 활동처럼 보입니다. 침해 여부를 가르는 신호는 파일이 아니라 행위에 있어요. 평소와 다른 시간대의 비밀번호 재설정, 인증 수단의 갑작스러운 교체, 짧은 시간에 몰린 Key Vault 접근, 익숙하지 않은 IP에서의 관리 작업 같은 것들입니다.
그래서 이런 공격에 대한 방어는 백신이나 패치 한 번으로 끝나지 않습니다. 신원·권한·활동 로그를 함께 보는 운영 체계가 있어야 정상 기능을 악용한 흐름을 골라낼 수 있습니다.
운영팀이 지금 점검할 것
Microsoft는 이번 분석과 함께 권고 방어책을 안내했습니다. 운영팀이 바로 점검할 수 있는 항목으로 정리하면 다음과 같습니다. 먼저 신원 영역부터 봅니다.
최소 권한 원칙: 특권 계정의 활동을 정기적으로 감사하고, 필요 이상으로 넓은 권한이 남아 있지 않은지 확인합니다.
조건부 액세스: 위치·기기·위험 신호를 기준으로 조건부 액세스 정책을 적용합니다.
전 사용자 MFA: 모든 사용자에게 MFA를 요구하고, 인증 방법을 충분히 등록해 둡니다.
피싱 저항 MFA: 관리자와 특권 계정에는 피싱에 견디는 강도의 MFA를 요구합니다.
특권 사용자 MFA 사전 등록: 기존 특권 사용자가 이미 MFA 방법을 등록해 두도록 해, 공격자가 새 인증 수단을 등록하는 것을 막습니다.
클라우드 리소스 영역도 함께 짚습니다.
활동 로그 모니터링: Azure Monitor 활동 로그로 관리 이벤트를 조사하고 모니터링합니다. 로그를 운영 관측 채널로 흘려보내는 방법은 5월 13일(수) 발행 옵저버빌리티 입문 글에서 정리했어요.
네트워크 접근 제한: 방화벽 규칙과 접근 제어를 신뢰하는 IP 범위·가상 네트워크로만 한정합니다.
Key Vault 보호: Key Vault에 purge protection을 켜고, 공개 네트워크 접근을 제한합니다.
레거시 인증 정리: 레거시 인증 방식을 비활성화하고 관리 ID 사용을 강제합니다.
RBAC 정기 감사: Azure RBAC 역할 할당을 주기적으로 점검합니다.
열 가지를 한 번에 정리하기 어렵다면, 신원 쪽에서 특권 계정 MFA 사전 등록과 피싱 저항 MFA부터, 리소스 쪽에서 Key Vault 공개 접근 제한부터 시작해도 좋아요. Storm-2949가 파고든 곳이 바로 그 지점이었기 때문이죠.
이것만 기억하세요
Storm-2949 침해는 멀웨어도 취약점도 없이 진행됐습니다. 공격자는 Entra ID 셀프서비스 비밀번호 재설정(SSPR)을 표적 대신 시작하고, IT 지원 담당자를 사칭해 사용자가 MFA 승인을 누르게 만든 뒤 비밀번호와 인증 수단을 교체해 계정을 장악했습니다. 이어 Microsoft Graph API로 테넌트를 정찰하고, 특권 RBAC 역할을 발판 삼아 4분 만에 Azure Key Vault 시크릿 수십 개에 접근했어요. 시크릿에 담긴 데이터베이스 연결 문자열로 공격 범위가 넓어졌고, OneDrive 수천 개 파일과 Azure 스토리지 데이터가 여러 날에 걸쳐 빠져나갔습니다. 정상 기능만 쓴 공격이라 멀웨어 탐지로는 잡히지 않으므로, 신원·권한·활동 로그를 함께 보는 운영 체계와 특권 계정 MFA 사전 등록·Key Vault 접근 제한 같은 점검이 필요합니다.
자주 묻는 질문 (FAQ)
Q. Storm-2949는 어떤 공격자인가요?
Storm-2949는 Microsoft 위협 인텔리전스가 추적하는 위협 행위자입니다. Microsoft는 2026년 5월 18일 공개한 분석에서, Storm-2949가 표적 조직의 고가치 자산에서 민감 데이터를 최대한 탈취하는 데 집중한 캠페인을 벌였다고 안내했습니다. Storm으로 시작하는 명칭은 아직 정식 명명 단계에 이르지 않은 행위자에 부여하는 분류이고, 이번 공격은 표적 신원 침해와 클라우드 인프라 침해 두 단계로 진행됐습니다.
Q. SSPR(셀프서비스 비밀번호 재설정) 악용은 어떻게 이뤄졌나요?
공격자는 표적 사용자 대신 SSPR 절차를 시작한 뒤, 사내 IT 지원 담당자를 사칭해 사용자에게 연락했습니다. 계정에 긴급 확인이 필요하다며 일상적인 비밀번호 재설정 절차라고 안내해 MFA 승인을 누르도록 유도했어요. 사용자가 승인하면 공격자는 비밀번호를 재설정하고 전화번호·이메일·Microsoft Authenticator 같은 기존 인증 수단을 제거한 뒤, 자신의 기기에 Authenticator를 등록해 지속 접근 권한을 확보했습니다.
Q. 멀웨어가 없었는데 어떻게 클라우드 전체가 뚫렸나요?
이번 공격은 취약점(CVE)을 악용하지 않고 클라우드의 정상 기능만 사용했습니다. SSPR·MFA·Microsoft Graph API·OneDrive·Azure Key Vault가 모두 정상 기능이고, 공격자는 이것들을 의도와 다르게 이어 붙였습니다. 멀웨어가 없으면 엔드포인트 보안 도구가 탐지할 악성 파일이 없고, 공격자의 행위는 정상 자격증명으로 정상 API를 호출하는 활동처럼 보입니다. 그래서 파일이 아니라 신원·권한·활동 로그의 이상 신호를 봐야 침해를 가려낼 수 있습니다.
Q. Key Vault에서는 무엇이 탈취됐나요?
Microsoft에 따르면 공격자는 약 4분 동안 Azure Key Vault의 액세스 구성을 조작하고 수십 개 시크릿에 접근했습니다. 탈취된 시크릿에는 데이터베이스 연결 문자열과 신원 자격증명 등이 포함돼 있었고, 이 자격증명을 통해 공격 범위가 한 번에 넓어졌습니다. 별도로 공격자는 OneDrive 웹 인터페이스로 수천 개 파일을 한 번에 다운로드했고, Azure 스토리지를 겨냥한 데이터 탈취는 초기 침해 이후 여러 날에 걸쳐 계속됐습니다.
Q. 운영팀은 무엇을 점검해야 하나요?
Microsoft는 신원과 클라우드 리소스 양쪽에 대한 방어책을 권고했습니다. 신원 영역에서는 최소 권한 원칙과 특권 계정 활동 감사, 조건부 액세스, 전 사용자 MFA, 관리자·특권 계정의 피싱 저항 MFA, 그리고 기존 특권 사용자의 MFA 사전 등록이 핵심입니다. 클라우드 리소스 영역에서는 Azure Monitor 활동 로그 모니터링, 신뢰 IP·가상 네트워크 기반 접근 제한, Key Vault purge protection과 공개 네트워크 접근 제한, 레거시 인증 비활성화, Azure RBAC 역할 정기 감사가 권고됐습니다.
