JadePuffer/Storm-3168: 에이전트형 행위자가 7분 동안의 파괴적인 폭주로 Azure 테넌트의 스토리지를 삭제하다

Microsoft Security Research가 보고한 2026년 9월 25일자 내용에 따르면, 침해된 서비스 주체 두 개를 이용한 행위자가 2026년 6월 초 이름이 밝혀지지 않은 Azure 테넌트 내에서 활동했으며, 15시간 이상의 정찰로 시작해 약 7분 만에 100개 이상의 스토리지 계정을 삭제하려 시도해 대부분 성공했고, Azure Key Vault, Function App, App Service plan을 삭제했습니다. Microsoft는 이 침입을 다음으로 추적하는 행위자에게 귀속시켰습니다: Storm-3168, 보안 업체 Sysdig는 이를 JADEPUFFER라고 부르고 2026년 7월에 대규모 언어 모델이 처음부터 끝까지 수행한 최초의 랜섬웨어 작전으로 문서화했습니다. Microsoft는 몸값 요구서를 발견하지 못했고 데이터가 유출되었다고 확인하지 않았다고 밝혔습니다. 아카이브는 이 캠페인을 AI 개입이 확인되고 실제 피해가 발생한 고심각도 사건으로 기록하며, Orca AI 사건 아카이브의 전체 항목에는 출처, 심각도 등급, 신뢰도 평가가 담겨 있습니다.

피해자의 이름은 공개되지 않았다. 마이크로소프트의 보고서는 단일 Azure 테넌트, 그 테넌트에 속한 두 개의 침해된 서비스 주체, 그리고 이들 사이의 역할 분담을 설명한다. 한 주체는 약 15시간 30분 동안 정찰을 담당하며 가상 머신, 구독, 리소스 그룹 및 리소스를 열거하는 300건 이상의 성공적인 읽기 작업을 수행했고, 다른 주체는 탐색, 파괴적 작업 및 자격 증명 수집을 수행했다. 마이크로소프트는 영향을 받은 조직이 몇 곳인지 밝히지 않았으며, 서비스 주체가 처음 어떻게 침해되었는지는 확인할 수 없었다.

텔레메트리가 보여주는 것, 순서대로

마이크로소프트에 따르면 두 번째 보안 주체는 첫 번째 보안 주체가 시작된 지 약 90분 후에 시작되었으며, 약 5초 만에 두 구독에 걸쳐 가상 머신과 리소스 그룹을 열거했습니다. 두 자격 증명 모두 마이크로소프트가 Storm-3168과 연관 짓는 인프라를 사용했고, 동일한 네트워크 지문을 공유했으며 동일한 사용자 에이전트를 제시했습니다: python-requests/2.34.2. 마이크로소프트는 타이밍과 업무 분담이 “자동화 또는 스크립트 실행을 강력히 시사한다”고 밝혔습니다.

약 16시간 후, 두 번째 주체는 Azure App Service 구성 저장소에서 노출된 자격 증명을 확인했고 Azure OpenSearch를 찾으려 했지만 찾지 못했습니다. 그로부터 70초 후, 존재하지 않는 스토리지 계정에 대해 ListKey 작업을 시도했습니다. 그 실패한 호출로부터 1초도 지나지 않아 파괴가 시작되었습니다. 이후 35분 동안 Microsoft는 150건이 넘는 파괴적 작업 또는 자격 증명 수집 작업을 집계했으며, 핵심 파괴 단계는 약 7분간 지속되었습니다.

7분, 그리고 버텨낸 통제 장치들

Microsoft는 공격자가 대상으로 삼은 스토리지 계정 대부분이 성공적으로 삭제되었다고 밝혔다. 공격자는 또한 동일한 리소스 그룹에 있었고 해당 Function App을 지원하는 것으로 보였던 App Service 플랜과 Azure Key Vault, Function App을 삭제했다. 공격 대상은 스토리지에 국한되지 않았다. Microsoft는 Azure Site Recovery 잠금과 Azure Backup 보호 잠금을 삭제하려는 여러 시도를 기록했으며, 그 시도들은 실패했다고 보고했다.

마이크로소프트는 모든 삭제가 성공한 것은 아니며, 그 이유가 방어자에게 중요한 방식으로 서로 다르다고 밝혔다. 몇몇 스토리지 계정은 Azure 리소스 잠금과 스토리지 계정 수준의 삭제 보호가 해당 작업을 차단했기 때문에 살아남았다. Azure SQL 데이터베이스를 삭제하려는 병행 시도는 다른 이유로 실패했다. 모두 지원되지 않는 API 버전을 사용했던 것이다. 클라우드 보안 연합(Cloud Security Alliance)은 이를 차단된 조치가 아니라 운영상의 오류라고 설명했다. 마이크로소프트는 리소스 삭제, 복구 방해 시도, 자격 증명 수집의 조합을 "랜섬웨어 및 갈취 작업을 지원할 수 있는 전술과 일치한다"고 요약했다.

Microsoft의 설명은 Azure 자체의 취약점 악용이 아니라 일반적인 Azure 역할 할당을 다룹니다. 그룹에 부여된 Storage Account Contributor 역할이 스토리지 파괴를 허용했고, 직접 Contributor 역할이 세 애플리케이션 리소스의 삭제와 또 다른 키 검색을 허용했으며, 직접 SQL DB Contributor 역할이 실패한 SQL 시도를 허용했습니다. Microsoft는 두 번째 서비스 주체에 발급된 다섯 개의 고유 토큰을 관찰했습니다. 그중 네 개는 삭제를 지원했고 다섯 번째는 스토리지 인벤토리와 키 검색을 처리했습니다. 삭제 토큰 중 두 개는 동일한 70초 기간 동안 활성 상태였습니다. 보고서는 또한 스토리지 계정 중 terraform 및 backup 테마 이름을 가진 계정이 대상에 포함되었다고 언급하며, 이는 잠재적으로 복구를 방해하기 위한 것일 수 있습니다.

스토리지 키에 대한 반환

파괴가 끝난 후 약 30분 뒤, 동일한 주체가 다시 돌아왔습니다. 이 주체는 스토리지 계정을 조사하고 30건이 넘는 성공적인 ListKeys 요청을 수행했습니다. 그중에는 Site Recovery와 연결된 스토리지에 대한 요청도 있었습니다. 같은 리소스 그룹에 있던 비슷한 이름의 스토리지 계정은 삭제 단계에서 살아남았고 이후 성공적으로 키 조회가 이루어졌습니다. Microsoft는 몸값 요구 메모를 발견하지 못했고 성공적인 데이터 유출도 확인하지 못했지만, 수집된 키가 향후 유출을 지원할 수 있다고 밝혔습니다.

Corsica Technologies의 최고 정보 보안 책임자인 Ross Filipek은 이번 사건에 대해 CSO Online과 인터뷰하며, 그 일련의 흐름이 복구의 의미를 바꾼다고 말했다. 그는 삭제된 자산을 재구축하는 것만으로는 충분하지 않다고 말했다. 나중의 스토리지 키 요청이 데이터로 이어지는 또 다른 경로를 만들 수 있기 때문이다. 대응 담당자는 어떤 아이덴티티와 키가 접촉되었는지 확인하고, 복구된 서비스를 신뢰하기 전에 그 사용 내역을 검토해야 한다. "공격자가 애플리케이션 아이덴티티를 확보하면, 그들의 활동은 평범한 클라우드 관리처럼 보일 수 있습니다"라고 Filipek은 CSO Online에 말했다.

자격 증명이 어떻게 드러났는지

Microsoft는 초기 접근 벡터를 확인할 수 없었다. 대신 발견한 것은 하나의 노출이었다. 영향을 받은 조직의 직원이 게시한 공개 GitHub 이슈에 서비스 주체 중 하나의 클라이언트 ID, 클라이언트 암호 및 테넌트 ID가 평문으로 나타났던 것이다. 해당 이슈는 나중에 편집되었지만, Microsoft는 그 암호가 이슈의 공개 편집 기록을 통해 계속 접근 가능한 상태로 남아 있었다고 밝혔다. 보고서는 Microsoft가 이 암호가 실제로 사용된 것인지 확인할 수 없었다고 분명히 명시하고 있다.

그 발견 사항에 딸린 경고가 실무적으로 중요한 부분입니다. Microsoft는 공개적으로 노출된 자격 증명은 침해된 것으로 간주해야 하며, 즉시 폐기하거나 교체하고, 이전 사용 여부를 조사해야 한다고 말합니다. 노출된 비밀을 제거하거나 가려도 그것이 무효화되지는 않으며, 공개적으로 노출된 자격 증명은 폐기하거나 교체할 때까지 계속 사용할 수 있습니다.

Microsoft는 또한 2026년 초부터 Storm-3168과 연관된 인프라가 WordPress 관리 인터페이스, PHP-CGI, Langflow 엔드포인트 /api/v1/validate/code 및 웹셸 유사 경로에서 Azure App Services를 대상으로 더 광범위한 프로빙을 수행했다고 설명했습니다. 해당 대상들은 피해자의 구독과 겹치지 않았고, Microsoft는 App Service에서 Azure Resource Manager 자격 증명으로 이어지는 경로를 찾지 못했습니다. 보고서에는 세 가지 지표가 나열되어 있습니다: 45.131.66[.]106은(는) 프로빙 및 악성 ARM 요청에 사용되었고, 34.153.223[.]102 및 64.20.53[.]230은(는) App Service 프로빙에 사용되었습니다.

동일한 행위자, 다른 작전

Sysdig의 2026년 7월 1일 보고서는 "에이전틱"이라는 단어가 이 행위자에게 붙는 이유입니다. Sysdig는 JADEPUFFER를 최초로 문서화된 에이전틱 랜섬웨어 사례라고 설명했습니다. 즉, "대규모 언어 모델이 처음부터 끝까지 주도한 완전한 갈취 작전"이며, 그 기능은 인간이 운영하는 툴킷이 아니라 AI 에이전트에서 나왔다고 말했습니다. 해당 침해에서 행위자가 악용한 취약점은 바로 CVE-2025-3248인터넷에 노출된 Langflow 인스턴스에서 1,342개의 Nacos 구성 항목을 암호화하는 데 MySQL 내장 AES_ENCRYPT() 함수를 사용했고, 원본 테이블을 삭제한 뒤, 남겨둔 것은 README_RANSOM 테이블로, Bitcoin 주소와 Proton Mail 연락처가 포함되어 있었습니다. Sysdig는 600개 이상의 서로 다른 페이로드, 자기 설명 코드, 그리고 Nacos 로그인 실패 후 31초 이내에 실행된 교정 다단계 페이로드를 보고했습니다. Sysdig는 또한 시스템 프롬프트나 에이전트 구성에 대한 가시성이 부족하다고 밝혔습니다.

Azure 캠페인은 동일 행위자에 의한 별개의 작전으로, 7월 침해의 재실행이 아니다. 이는 암호화가 아니라 삭제와 키 수집에 관한 것이었으며, Microsoft는 몸값 요구 노트를 발견하지 못했다. 두 사건의 연관성은 부분적으로 인프라에 근거한다. Cloud Security Alliance는 9월 28일 연구 노트에서 Microsoft가 나열한 IP 주소 중 두 개인 45.131.66[.]106과 34.153.223[.]102가 Sysdig의 7월 보고서에 등장했다고 언급했다. 같은 노트는 IP 재사용만으로는 공유된 제3자 호스팅을 배제할 수 없다고 경고했다.

확립되었고, 평가되었으며, 여전히 열려 있음

Azure 침입의 메커니즘은 잘 문서화되어 있다. 자율성은 같은 수준으로 문서화되어 있지 않으며, 그 차이가 이 기록에서 가장 중요한 유보 사항이다.

Microsoft의 텔레메트리로 확인된 사실: 한 테넌트 내 침해된 서비스 주체 2개; 약 15시간 30분 동안 300건이 넘는 성공적인 읽기 작업; 100건이 넘는 스토리지 계정 삭제 시도(대부분 성공); Key Vault, Function App 및 App Service 플랜의 삭제; 지원되지 않는 API 버전으로 인해 모두 실패한 SQL 데이터베이스 삭제; 리소스 잠금과 삭제 보호로 지켜진 스토리지 계정; 파괴 후 30건이 넘는 성공적인 ListKeys 요청; 공개 GitHub 이슈 및 해당 편집 기록에 있는 평문 서비스 주체 자격 증명; 몸값 요구 메모는 관찰되지 않음; 확인된 유출 없음.

Microsoft의 평가: 해당 활동이 Storm-3168에 속한다는 점; 삭제, 복구 방해 및 키 수집의 조합이 랜섬웨어 및 갈취와 일치한다는 점; 실행이 자동화되었거나 스크립트로 이루어졌을 가능성이 높다는 점; 수집된 키가 향후 유출을 지원할 수 있다는 점입니다. Microsoft의 공개 보고서는 Azure 관련 단계를 추론하는 자율 에이전트를 설명하지 않습니다.

공개: 서비스 주체가 처음 어떻게 침해되었는지, 피해자의 신원과 영향을 받은 조직의 수, 테넌트를 벗어난 데이터가 있었는지, 그리고 스크립트가 아닌 AI 에이전트가 Azure 작업 자체를 지시했는지 여부.

Cloud Security Alliance는 9월 28일 메모에서 증거 격차를 정확히 짚었다. “에이전트형”이라는 특성 규정은 현재 “포착된 에이전트 추론 흔적”이 아니라 “정밀성, 속도, 그리고 아이덴티티 전반의 노동 분업”에 근거하고 있다고 밝혔다. Sysdig가 7월에 사용한 증거 — 자기 서술형 페이로드와 신속한 진단-수정 주기 — 는 Azure 캠페인의 공개 기록에는 없다. 보안 기업 Swimlane의 Nick Tausek은 CSO Online에 Azure 증거가 “AI가 각 단계를 지시했음을 입증하기보다는 조정된 자동화를 보여준다”고 말했다.

공개 내용에 대한 보도는 더 강한 프레이밍을 사용했다. BleepingComputer의 헤드라인은 Azure에 대한 “에이전틱 AI 공격”을 묘사했고, Dark Reading의 헤드라인은 Azure 테넌트를 침해한 “AI 행위자”를 묘사했다. Microsoft 자체 보고서는 시점과 역할 분담이 “자동화되었거나 스크립트로 실행되었음을 강하게 시사한다”고 밝히며, 개별 Azure 단계를 에이전트에 귀속시키지 않는다.

아카이브는 이 기록에 신뢰도 A를 부여하며 분쟁 중이라고 표시하지 않는다. 이 기록의 "확인됨" AI 관련 라벨은 Sysdig가 LLM 기반이라고 문서화한 행위자인 JADEPUFFER에 대한 귀속에 달려 있으며, Microsoft가 Azure 삭제 중에 에이전트의 추론을 포착했다는 주장은 아니다. 피해는 입증되었고, 자동화는 입증되었으며, 자율성은 추론된 것이다.

마이크로소프트가 바뀌어야 한다고 말하는 것

마이크로소프트의 권장 사항은 운영적이며, 이번 침해가 어떻게 발생했는지에서 직접 비롯된 것입니다. 이는 방어자에게 Resource Manager, Storage, Key Vault, App Service 및 Databases에 대한 관련 Microsoft Defender for Cloud 계획을 사용하도록 설정하고, 서비스 주체 자격 증명, 스토리지 키, 연결 문자열 및 기타 비밀을 소스 코드, 구성, 리포지토리 및 이슈에 두지 않으며, 수명이 긴 비밀 대신 Microsoft Entra Workload ID를 사용하고, 최소 권한을 적용하고 워크로드 ID에 대한 Azure RBAC 할당을 검토하며, 보호 제어를 변경하려는 시도를 포함하여 백업 및 복구 리소스를 제한하고 모니터링하도록 요청합니다.

Microsoft의 공개 보고서는 테넌트가 데이터를 복원했는지, 피해자에게 통지되었는지, 또는 수집된 키 중 일부가 이후에 사용되었는지는 밝히지 않는다. 그러한 결과들은 기록에 없다. 기록이 담고 있는 것은 측정 가능한 대조다. 리소스 잠금과 삭제 보호는 광범위한 권한을 가진 ID에 대해서도 일부 삭제를 차단한 반면, SQL 데이터베이스는 방어자의 결정이 아니라 API 버전 실수 덕분에 살아남았다. Microsoft의 설명은 테넌트가 다음에 무엇을 했는지는 말하지 않는다. 다만 행위자가 삭제에 7분을 쓰기 전에 읽는 데 15시간 넘게 썼다고는 말한다.