Storm‑2949: 하나의 계정 탈취가 클라우드 전체 침해로 확산된 과정

Microsoft가 공개한 Storm‑2949 공격 사례는 최근 클라우드 보안 위협이 어떻게 변하고 있는지를 잘 보여준다. 이 공격은 악성코드 설치나 취약점 익스플로잇이 아니라 **단 하나의 계정 탈취(identity compromise)**에서 시작됐다. 이후 공격자는 Microsoft 365와 Azure의 공식 관리 기능과 API를 활용해 조직의 클라우드 환경 전체로 접근 범위를 확장했다.

이 사건은 현대 공격자가 더 이상 악성코드에만 의존하지 않고, 정상적인 클라우드 관리 기능을 이용해 탐지되지 않은 채 이동하는 전략을 점점 더 많이 사용하고 있음을 보여준다.

단일 계정 탈취에서 시작된 클라우드 탐색

Microsoft 위협 인텔리전스에 따르면 공격은 사용자 계정 하나가 탈취되면서 시작됐다. 공격자는 계정에 접근한 직후 Microsoft Entra ID 테넌트 내부를 탐색해 추가 목표를 찾기 시작했다.

이 과정에서 사용된 핵심 도구가 Microsoft Graph API였다. Graph API는 Microsoft 365와 Azure에서 사용자, 그룹, 애플리케이션, 권한 정보를 조회하고 관리할 수 있는 공식 인터페이스다.

공격자는 Python으로 만든 맞춤형 스크립트를 사용해 Graph API 요청을 자동화했다. 이 스크립트는 다음과 같은 정보를 대량으로 열거했다.

• 사용자 계정 목록
• 애플리케이션 등록 정보
• 역할 및 권한 속성

특히 이름 패턴이나 역할 정보를 기준으로 관리자 권한이 있을 가능성이 높은 계정을 찾는 데 집중했다.

이 단계에서 공격자는 조직의 클라우드 신원 구조를 사실상 지도처럼 파악하게 됐다.

Self‑Service Password Reset(SSPR) 악용

공격에서 중요한 역할을 한 또 다른 요소는 Self‑Service Password Reset(SSPR) 기능이었다. 이는 사용자가 IT 지원 없이도 비밀번호를 재설정할 수 있도록 하는 Microsoft Entra ID 기능이다.

공격자는 계정 탈취 이후 계정 복구 절차를 악용해 지속적인 접근 권한을 확보했다.

SSPR은 정상적인 인증 흐름을 사용하기 때문에 로그 상에서도 일반 사용자 활동처럼 보일 수 있다. 특히 공격자가 이미 자격 증명이나 복구 정보를 확보한 경우라면 악용 여부를 식별하기 더욱 어렵다.

Microsoft Graph와 Azure RBAC를 통한 권한 상승

공격자는 서버 취약점을 이용한 전통적인 방식 대신 **클라우드 제어 평면(control plane)**을 이용해 권한을 확대했다.

핵심은 두 가지였다.

• Microsoft Graph API를 통한 디렉터리 객체 조회 및 조작
• Azure RBAC(Role-Based Access Control) 권한 구조

Graph API로 조직 내 계정과 역할 구조를 파악한 뒤, 공격자는 더 높은 권한을 가진 계정과 서비스를 찾아 접근 범위를 확대했다.

Azure RBAC는 클라우드 리소스 접근 권한을 관리하는 시스템이다. 공격자가 권한 상승에 성공하면 여러 Azure 서비스에 관리 수준 접근이 가능해진다.

Azure 핵심 리소스 접근

권한 상승 이후 공격자는 Azure 환경의 여러 중요 리소스에 접근했다. Microsoft 보고에 따르면 접근된 리소스에는 다음이 포함됐다.

• Azure App Services
• Azure Key Vault
• Azure SQL 데이터베이스
• 가상 머신(VM)

특히 Key Vault와 데이터베이스는 애플리케이션 비밀 키, 인증 토큰, 운영 데이터 등을 저장하는 경우가 많기 때문에 공격자에게 매우 가치 있는 목표다.

이 사례는 단순한 계정 탈취가 실제 운영 인프라 접근으로 이어질 수 있음을 보여준다.

정상 관리 도구를 이용한 탐지 회피

Storm‑2949 공격이 탐지되기 어려웠던 이유 중 하나는 모든 활동이 정상 관리 도구를 통해 수행되었다는 점이다.

Microsoft는 공격자가 다음과 같은 Azure 관리 기능을 사용했다고 밝혔다.

• VMAccess
• Run Command
• PowerShell

이 도구들은 시스템 관리자들이 일상적으로 사용하는 기능이기 때문에 로그에서 악성 활동을 구분하기 어렵다. 공격자는 이를 이용해 관리 작업처럼 보이는 방식으로 리소스를 조작하고 이동했다.

며칠에 걸친 데이터 유출

공격의 마지막 단계는 수일 동안 지속된 데이터 탈취였다.

공격자가 여러 서비스와 데이터 저장소에 접근한 뒤 민감한 정보를 외부로 전송한 것으로 보고됐다. 장기간 활동이 가능했다는 점은 공격자가 일정 기간 동안 탐지 없이 테넌트 내부에 머물렀다는 의미다.

왜 이런 공격은 탐지하기 어려운가

Storm‑2949 사례는 클라우드 보안에서 점점 흔해지는 공격 패턴을 보여준다.

주요 특징은 다음과 같다.

• 유효한 계정 자격 증명 사용
• 정상 API 호출 기반 탐색
• 권한 시스템(RBAC)을 통한 권한 상승
• 공식 관리 도구 사용

즉 공격자는 신뢰된 서비스 내부에서 정상 기능만 사용해 움직였기 때문에 전통적인 엔드포인트 보안 도구로는 이상 징후를 발견하기 어렵다.

Microsoft의 보안 권고 사항

Microsoft는 유사한 공격을 막기 위해 **신원 중심 보안(identity security)**을 강화해야 한다고 강조했다.

주요 권고 사항은 다음과 같다.

계정 보호 강화

단일 계정 탈취가 조직 전체 침해로 이어지지 않도록 강력한 인증 보호 체계를 구축해야 한다.

SSPR 설정 검토

특히 관리자 계정에 대해 Self‑Service Password Reset 설정을 면밀히 검토하고 복구 방법이 악용되지 않도록 해야 한다.

강력한 MFA 및 조건부 접근 적용

다중요소 인증(MFA)과 조건부 접근 정책을 적용하면 탈취된 비밀번호만으로는 로그인하기 어려워진다.

Microsoft Graph API 활동 모니터링

대량의 디렉터리 조회나 자동화된 API 호출 패턴은 내부 정찰 활동일 수 있으므로 모니터링이 필요하다.

Azure RBAC 권한 감사

권한 할당을 정기적으로 검토하고 최소 권한 원칙을 적용해야 한다.

관리 도구 사용 감시

VMAccess, Run Command, PowerShell 같은 관리 기능이 비정상적으로 사용될 경우 경고를 생성하도록 설정해야 한다.

고가치 Azure 리소스 보호

Key Vault, 데이터베이스, 운영 가상 머신 등 민감 리소스에 대한 접근을 엄격히 통제해야 한다.

핵심 교훈: 클라우드 보안의 중심은 ‘신원’

Storm‑2949 사건이 보여준 가장 큰 교훈은 클라우드 환경에서 가장 중요한 공격 표면이 ‘신원(identity)’이라는 점이다.

공격자가 하나의 계정을 장악하면 API, 권한 시스템, 관리 도구를 이용해 조직 전체 환경으로 이동할 수 있다.

따라서 현대 클라우드 보안은 단순히 악성코드나 엔드포인트 탐지에 집중하는 것을 넘어 계정 행동 분석, API 활동, 권한 구조, 클라우드 제어 평면 활동까지 가시성을 확보해야 한다.