탈취된 자격증명은 어떤 경고도 울리지 않습니다. 로그인에 실패하지도, 속도 제한에 걸리지도 않고, 새벽 2시에 원래 소유자가 쓰는 것과 겉모습이 다르지 않습니다. 정적이고 수명이 긴 자격증명은 탈취되는 순간에 신호를 남기지 않는다는 점이 문제입니다. 나쁜 목적으로 사용된 뒤에야 신호가 나타나지만, 그때는 이미 늦는 경우가 많습니다.
올해 초 침해된 아이덴티티 하나가 클라우드 전체로 번진 침해 사고도 같은 이유에서 발생했습니다. 이 사건의 경위를 따라가면, 탈취된 자격증명의 권한만으로는 답할 수 없는 질문이 남습니다.
로그인 하나, 계정 네 개
지난 5월 마이크로소프트는 자사가 Storm-2949로 추적하는 위협 행위자에 대한 상세한 조사 결과를 공개했습니다. 최초 침투에는 Entra ID의 셀프서비스 비밀번호 재설정 기능 악용과 소셜 엔지니어링이 동원됐습니다. 공격자는 사용자를 속여 가짜 MFA 승인 요청을 누르게 한 뒤 전화번호·이메일 주소·Microsoft Authenticator 등록 정보 같은 실제 인증 수단을 제거했고, 원래 소유자를 계정에서 몰아냈습니다. 마이크로소프트는 이 공격자가 "전통적인 멀웨어나 온프레미스 전술·기법·절차(TTP)에 의존하지 않았다"고 설명하며, IT 인력과 고위 경영진을 의도적으로 노렸다고 밝혔습니다. 침해된 아이덴티티 하나로 시작해 계정 4개까지 번졌고, 공격자가 클라우드 테넌트에 도달한 뒤로는 스토리지에서의 유출이 여러 날에 걸쳐 이어졌습니다.
일단 들어온 뒤로는 정교한 수법이 필요하지 않았습니다. 공격자는 원격 파일 공유에서 비밀번호 관련 문자열을 검색하고, 개인 키를 담고 있을 수 있는 .pfx 인증서 파일을 빼냈습니다. 그다음에는 침해된 아이덴티티가 이미 갖고 있던 상위 권한의 Azure RBAC 권한을 그대로 악용했습니다. 공격자는 관리 평면(management-plane) 호출로 스토리지 계정 키를 꺼냈습니다. Key Vault 접근 권한을 조작해 데이터베이스 연결 문자열과 아이덴티티 자격증명 등 수십 개의 시크릿에 접근한 뒤, SQL 서버 방화벽 규칙을 고쳐 쓰고 Key Vault 자격증명으로 SQL 서버에 연결했습니다. 이는 침해된 계정이 실제로 하던 업무 범위를 한참 벗어난 행동이었습니다.
이 사건에서는 최초 침투보다 그 뒤에 이어진 권한 사용이 더 큰 문제였습니다. 침해된 계정이 보유한 상시 권한은 작업 범위로 제한되지 않았습니다. 만료 기한이나 별도 작업 범위도 없었고, 계정에 부여된 Azure RBAC 역할이 곧 접근 가능 범위였습니다.
기계 속도로 이뤄지는 수평 이동
탈취된 자격증명을 이용한 수평 이동은 이제 며칠이 아니라 몇 분 만에 일어납니다. CrowdStrike의 2026년 Global Threat Report에 따르면 평균 eCrime breakout time(최초 침해에서 두 번째 시스템으로 수평 이동하기까지 걸리는 시간)은 29분으로, 2024년보다 속도가 65% 빨라졌습니다(CrowdStrike). 대부분의 접근 제어 체계는 수평 이동까지 며칠이 걸린다는 전제에서 설계됐습니다. 분기마다 자격증명을 교체하거나 스프린트마다 한 번 접근 권한을 검토해서는 30분도 안 되는 시간에 움직이는 위협에 대응할 수 없습니다.
Unit 42의 Sam Rubin은 공격자가 갈수록 침입보다 로그인을 택한다고 지적했습니다(Help Net Security). 한 번 로그인하면 탈취된 자격증명 하나가 클라우드 전체로 번질 수 있는 이유는, 회수되지 않은 상시 접근 권한이 남아 있기 때문입니다. Storm-2949도 같은 방식으로 진행됐습니다. 플랫폼 팀에서 반복해서 듣는 불만도 "어떻게 뚫렸나"가 아니라 "그 자격증명이 왜 석 달 뒤에도 여전히 작동했나"입니다.
Storm-2949에서는 사람의 아이덴티티가 침해됐습니다. 하지만 같은 상시 권한 문제는 대부분의 기업이 들여다보지 않는 아이덴티티에서 더 크게 나타납니다. 클라우드 네이티브·DevOps 환경에서는 머신 아이덴티티가 사람보다 최대 144대 1 비율로 많습니다(Entro Labs, NHI & Secrets Risk Report H1 2025, axis-intelligence 인용). AI 에이전트와 자동화 스크립트가 늘수록, 회수되지 않은 상시 접근 권한을 축적할 아이덴티티도 늘어납니다. 이런 아이덴티티를 잃어도 사람 계정처럼 MFA 알림이 오지 않습니다.
RBAC에 없는 선언된 목적
Alpacon에서는 Work Session을 열 때 아이덴티티와 목적을 선언합니다. 에이전트가 exec, command-API, MCP 레인에서 실행하는 명령은 실행 전에 이 목적에 비추어 판단합니다. 이때 규칙 검사, 베이스라인 검사, LLM 목적 판단을 순서대로 거칩니다. 계정 역할이 허용한 범위만 확인하지는 않습니다.
Storm-2949의 침해 계정과 RBAC에는 이 정보가 없었습니다. 공격자가 물려받은 상위 권한의 Azure RBAC 역할에는 그 역할을 당일 어떤 용도로 써야 하는지 적을 칸이 없습니다. 발견된 API 토큰이나 방치된 인증서도 같은 공백을 안고 있습니다. 이런 자격증명에는 권한은 있어도 목적이 없으며, 동작이 그 목적과 맞는지 확인하는 절차도 없습니다.
이 판단이 적용되는 곳은 exec, command-API, MCP 레인뿐입니다. 서비스 토큰과 대화형 셸에서 직접 작업하는 사람에게는 서로 다른 모델이 적용됩니다.
정리
Storm-2949에서 배울 점은 MFA 강화나 더 잦은 키 교체만으로 설명되지 않습니다. 두 조치는 필요하지만, 어떤 작업에도 맞춰 좁혀지지 않고 목적도 붙지 않은 상시 접근 권한이 실제 실패 지점이었습니다. 그 권한은 누가 부여했는지조차 기억나지 않을 만큼 오래 인프라에 남아 있었습니다. 만료 시점만으로는 충분하지 않습니다. 자격증명을 쥔 사람이 기한을 스스로 연장할 수 있다면, 그 기한은 실질적인 제한이 되지 않습니다. 확인해야 하는 대상은 자격증명의 유효성뿐 아니라 명령이 선언된 목적과 맞는지입니다.
AI 에이전트 인프라에서 자격증명의 유효성만 확인하고 명령의 의도는 판단하지 않는다면, 다음으로 점검해야 할 지점이 여기에 있습니다.
