클라우드 공격은 더 이상 가상머신 한 대를 암호화하는 방식에만 머물지 않습니다. Microsoft Security Research는 2026년 9월 25일 Storm-3168이 손상된 Azure 서비스 주체를 사용해 환경을 탐색하고, 여러 리소스를 삭제하며, 스토리지 키를 수집한 사례를 분석했습니다.
Microsoft는 이 활동이 AI가 조율하는 공격의 확장 가능성을 보여준다고 평가했지만, 실제 랜섬노트나 성공적인 데이터 반출은 확인하지 못했다고 명시했습니다.
3줄 핵심 요약
- Microsoft는 탈취한 Azure 서비스 주체(service principal)로 자원 탐색과 삭제, 자격 증명 수집을 자동화한 Storm-3168 활동을 공개했습니다.
- 한 테넌트에서 15시간 넘는 탐색 뒤 약 7분 동안 100건 이상의 스토리지 계정 삭제가 시도됐고, 백업·복구 보호 장치도 표적이 됐습니다.
- 공개된 비밀은 원문을 지워도 안전해지지 않으므로 즉시 폐기·교체하고, 워크로드 ID 최소 권한과 독립적인 복구 보호를 함께 운영해야 합니다.

서비스 주체 두 개가 역할을 나눴다
Microsoft가 관찰한 테넌트에서는 두 개의 손상된 서비스 주체가 사용됐습니다. 하나는 구독·가상머신·리소스 그룹을 장시간 열거했고, 다른 하나는 짧은 시간에 탐색과 파괴 작업, 자격 증명 수집을 수행했습니다.
첫 번째 주체는 약 15시간 30분 동안 300건이 넘는 읽기 작업을 성공시켰고, 두 번째 주체는 두 구독의 가상머신과 리소스 그룹을 약 5초 만에 조사했습니다.
탐색 직후 7분간 대량 삭제가 이어졌다
마지막 자원 목록 조회와 존재하지 않는 스토리지 계정의 키 조회 시도 직후, 두 번째 서비스 주체는 파괴 작업을 시작했습니다. 35분 동안 삭제·자격 증명 관련 작업 150건 이상이 시도됐고, 실제 파괴 시퀀스는 약 7분간 이어졌습니다.
Azure Storage 계정 100건 이상이 삭제 대상으로 지목됐으며, Key Vault·Function App·App Service plan과 여러 SQL 데이터베이스도 함께 노려졌습니다.
백업과 복구 장치도 공격면이 됐다
일부 삭제는 Azure 리소스 잠금과 스토리지 계정 삭제 보호로 막혔습니다. 반면 Site Recovery 잠금과 Azure Backup 보호 잠금에 대한 삭제 시도도 관찰됐습니다.
Microsoft는 이런 독립적인 보호 장치가 광범위한 관리자 권한을 가진 ID가 손상돼도 파괴 범위를 줄인다고 설명합니다. 백업 계정과 복구 제어 plane을 일반 운영 계정과 분리해야 하는 이유입니다.
공개된 비밀은 수정만으로 무효화되지 않는다
영향을 받은 서비스 주체의 클라이언트 ID·시크릿·테넌트 ID는 과거 공개 GitHub 이슈에 평문으로 노출된 적이 있었습니다. 이슈에서 시크릿을 지웠지만 편집 이력에는 남아 있었습니다.
Microsoft는 공개된 자격 증명을 원문 삭제 여부와 관계없이 이미 손상된 것으로 간주하고 즉시 폐기·교체하며 과거 사용 이력을 조사하라고 권고합니다.
공격이 자동화됐다는 단서
Storm-3168은 여러 토큰을 동시에 사용해 삭제와 스토리지 키 조회를 나눠 수행했습니다. 같은 인프라 지문과 자동화된 API 호출이 짧은 시간 간격으로 이어진 점은 사람이 한 명씩 콘솔을 조작한 것보다 스크립트 또는 에이전트 기반 실행에 가깝다는 단서입니다.
방어팀은 개별 삭제 경보뿐 아니라 서비스 주체의 탐색량, 토큰 발급, 역할 권한, 짧은 시간의 연속 작업을 묶어 분석해야 합니다.
Azure 운영자가 우선 적용할 방어책
첫째, 서비스 주체와 기타 워크로드 ID의 RBAC 권한을 실제 작업에 필요한 범위로 줄입니다. 둘째, 소스 코드·설정 파일·공개 저장소·이슈에 시크릿과 스토리지 키를 남기지 않고, 노출 시 즉시 교체합니다.
셋째, Defender for Resource Manager·Storage·Key Vault·App Service·Databases 같은 보호 계획과 비정상 키 조회·대량 삭제 탐지를 검토합니다. 넷째, 백업과 복구 잠금에 별도 권한과 감사 경로를 두고, 복구 자원 변경을 독립 채널로 알립니다.
사용자와 업계에 미치는 영향
Storm-3168 사례는 클라우드에서 ‘관리자 계정’보다 자동화에 사용되는 워크로드 ID가 더 조용한 공격 진입점이 될 수 있음을 보여줍니다. AI가 공격 순서를 조율할수록 방어팀도 로그를 수동으로 한 줄씩 확인하기보다 ID·토큰·리소스·복구 장치의 관계를 자동으로 연결해야 합니다.
확인할 점
이번 분석은 Microsoft가 조사한 Azure 테넌트와 관찰된 활동에 기반합니다. Microsoft는 랜섬노트나 성공적인 데이터 반출을 확인하지 못했으며, 실제 초기 침해 경로도 확정하지 않았습니다.
서비스 주체와 Azure RBAC, Defender 기능의 이름·세부 동작은 조직 구성과 라이선스에 따라 다르므로 실제 적용 전 테스트와 권한 검토가 필요합니다.
출처
함께 읽을 글
- AWS EventBridge, 여러 계정을 하나의 이벤트 버스로 묶는다
- 랜섬웨어 이름이 바뀌어도 흔적은 남는다: Storm-2570의 공통 수법
- 구글 워크스페이스, 관리자 권한을 ‘기간 한정’으로 부여한다
'수수께끼연구소' 카테고리의 다른 글
| AI 코딩 에이전트가 CAPTCHA 보안 설정까지 돕는다: Cloudflare Turnstile Spin (0) | 2026.09.27 |
|---|---|
| GitHub가 CSS를 더 보내며 사이트를 더 빠르게 만든 방법 (0) | 2026.09.26 |
| AWS EventBridge, 여러 계정을 하나의 이벤트 버스로 묶는다 (0) | 2026.09.25 |
| 랜섬웨어 이름이 바뀌어도 흔적은 남는다: Storm-2570의 공통 수법 (0) | 2026.09.25 |
| 구글 워크스페이스, 관리자 권한을 ‘기간 한정’으로 부여한다 (0) | 2026.09.24 |