Storm-3068 침해 경로로 보는 소스코드 이후의 클라우드 권한 확산 점검

개요

Microsoft의 해당 블로그 조사에서 확인된 Storm-3068 침해는 셀프 서비스 암호 재설정으로 사용자 계정에 접근한 뒤, 자신의 인증 방법을 등록해 identity를 장악하고 Azure DevOps·개발 파이프라인·Kubernetes 환경으로 접근을 확장한 경로로 정리된다.

이 사례에서 주목할 점은 공격의 초점이 소스코드 자체에 머물지 않았다는 것이다. 계정에서 파이프라인, 그리고 클라우드 자격 증명이라는 방향으로 권한이 이어지는 흐름이 확인되기 때문에, 초기 계정 접근 이후 이어지는 개발 환경 접근까지 함께 살펴볼 필요가 있다.

공격 흐름

확인된 흐름은 크게 세 단계로 볼 수 있다.

• 먼저 Storm-3068은 셀프 서비스 암호 재설정 과정을 통해 사용자 계정에 접근했다.
• 이후 공격자는 해당 identity에 자신의 인증 방법을 등록해 접근을 유지할 수 있는 지점을 확보했다.
• 조사 결과, 공격자는 Kubernetes 자격 증명을 수확하도록 설계된 악성 파이프라인을 만든 것으로 확인됐다.

즉, 이번 침해의 흐름은 계정 탈취에서 끝나는 것이 아니라 인증 등록, 파이프라인 접근, 클라우드 자격 증명이라는 순서로 이어지는 형태였다. 공개된 흐름만으로는 초기 진입 이후의 세부 이동 경로는 알 수 없으나, 계정에서 파이프라인과 Kubernetes 접근으로 이어졌다는 방향성 자체는 확인된다.

영향 범위

이번 사례가 시사하는 영향 범위는 다음 영역으로 볼 수 있다.

• 셀프 서비스 암호 재설정이 활성화된 사용자 계정
• 인증 방법 등록이 충분히 통제되지 않는 identity 환경
• Azure DevOps와 개발 파이프라인
• 파이프라인에서 접근할 수 있는 Kubernetes 환경

여기서 중요한 것은, 피해가 단일 계정에만 국한된다고 단정할 수 없다는 점이다. 제공된 자료에서는 침해 기간, 피해 조직 유형, 실제 수확된 자격 증명에 대한 추가 활용 여부 등이 구체적으로 공개되지 않아, 이 부분의 최종 범위는 확인된 사실 범위 안에서만 해석해야 한다.

기술적 분석

이번 침해는 계정 접근, 인증 방법 등록, 파이프라인 악용이라는 세 요소가 연결된 형태로 볼 수 있다.

Microsoft 공개 자료에 따르면, 이번 침해의 출발점은 Storm-3068이 셀프 서비스 암호 재설정 프로세스를 통해 계정 접근을 확보한 지점이다. 이 기능이 정상적인 사용자 복구 흐름과 공격적 계정 진입 흐름을 동일하게 통과할 수 있다는 구조적 취약점이 있었음을 단정할 수 있는 세부 근거는 현재 자료에 포함되어 있지 않다. 다만 어떤 사전 정보나 우회 수단을 거쳐 재설정이 성공했는지는 공개 자료에 포함되어 있지 않다.

그 뒤를 잇는 핵심은 identity 장악이다. 공격자가 자신의 인증 방법을 등록한 뒤에는, 초기 침해를 유지하는 데 필요한 추가 동작의 의존도가 줄어든다. 즉, 한 번의 성공적인 재설정으로 끝나는 사건이 아니라, 이후에도 반복적으로 계정에 들어올 수 있는 상태를 만들었다는 의미가 된다.

이후 공격자가 Azure DevOps와 개발 파이프라인 영역으로 이동했다는 사실은, 계정 권한이 개발·빌드 인프라의 실행 권한과 연결되어 있을 때 침해가 빠르게 확장될 수 있음을 보여준다. 특히 Kubernetes 자격 증명 수확을 목적으로 한 파이프라인이 확인된 점은, 개발 파이프라인이 단순한 코드 빌드 도구가 아니라 클라우드 자격 증명 접근 통로로 기능할 수 있다는 점에서 의미가 크다.

다만 파이프라인이 Kubernetes 자격 증명을 수확한 구체적 기법, 그리고 실제로 접근된 자격 증명의 유형까지 공개 자료에서 확인되지는 않는다. 따라서 이 부분은 공격 방향성을 보여주는 단계로 이해해야 한다.

대응·복구

공개된 침해 사실에서 확인되는 지점은 계정 접근, 인증 방법 등록, 그리고 Kubernetes 자격 증명 수확을 위한 악성 파이프라인 생성이다. 현재 자료에 기반할 수 있는 점검 방향은, 이 세 가지 지점이 해당 환경에서 실제로 관찰되는지 확인하는 데 있다.

공개 자료만으로는 침해의 정확한 종료 시점이나 추가 확산 여부를 확인하기 어렵기 때문에, 해당 환경에서 관찰되는 이력 범위 내에서 판단해야 한다.

재발 방지

이번 사례가 주는 교훈은, 계정 보호를 넘어 개발 파이프라인과 클라우드 자격 증명 사이의 권한 구조까지 함께 봐야 한다는 점이다.

특히 이번 침해에서 확인된 경로가 파이프라인 권한에서 Kubernetes 자격 증명 수확으로 이어졌다는 점을 고려하면, 파이프라인-클러스터 간 자격 증명 분리 구조가 우선적으로 살펴볼 영역이다. 이는 공격이 이미 공개된 실제 침해 경로로 확인되었기 때문이다.

다만 초기 진입 차단책을 완전히 구체화하기 위해서는, 셀프 서비스 암호 재설정이 어떤 방식으로 우회되었는지에 대한 추가 확인이 필요하다. 현재 자료만으로는 이 부분을 단정할 수 없으므로, 해당 영역은 한계 사항으로 남겨 두는 것이 적절하다.

참고자료

• Beyond source code: A path to the keys to the kingdom
• How Microsoft names threat actors - Microsoft Defender XDR

함께 읽으면 좋은 글

• CVE-2026-100740: D-Link DIR-895L L2TP 제어 채널 범위 밖 쓰기와 공개 익스플로잇 점검
• Contrast 기밀 컨테이너 취약점 점검과 대응: LUKS2 영구 볼륨·로그 비밀 유출·복구 신뢰 경계
• CVE-2026-100721: vm2 NodeVM 외부 모듈 리졸버의 접두사 인가 우회와 샌드박스 경계 점검

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.