GOTROOT / 모의해킹

클라우드는 보통 ‘설정 한 줄’에서 무너집니다 — 권한 상승을 따라가 보면 | GOTROOT

클라우드 사고는 대개 익스플로잇이 아니라 설정 한 줄에서 시작됩니다. SSRF로 시작해 메타데이터·임시 자격증명·역할 체이닝으로 이어지는 권한 상승 경로를 따라가며, IAM·스토리지·노출 컴포넌트까지 점검하는 방식을 정리했습니다.

GOTROOT 리서치 팀 2026. 6. 5.

온프레미스 시절의 사고가 ‘방화벽을 어떻게 넘었나’의 이야기였다면, 클라우드의 사고는 대부분 ‘설정 한 줄’에서 시작됩니다. 화려한 익스플로잇보다, 와일드카드가 들어간 IAM 정책 하나, 공개로 열린 버킷 하나가 더 자주 입구가 됩니다. 이 글은 저희가 클라우드 환경을 볼 때 따라가는 권한 상승의 흐름을, 책임 공유 모델 안에서 정리해 본 것입니다.

먼저, 어디까지가 우리 몫인가

점검 범위를 정할 때 가장 먼저 맞춰야 하는 게 ‘책임 공유 모델’입니다. 클라우드 ‘자체’의 보안은 사업자가 맡고, 클라우드 ‘안’의 설정·데이터·권한은 고객이 책임집니다. 모의해킹의 초점은 후자 — 고객이 만든 설정과 권한 경계입니다. (사업자별 점검 허용 정책도 사전에 함께 확인합니다.)

권한 상승을 따라가 보면

말로 설명하기보다, 저희가 실제로 자주 마주치는 한 가지 경로를 그대로 따라가 보겠습니다. 시작은 평범한 SSRF 한 개였습니다.

애플리케이션의 SSRF 한 줄
   │  (서버가 내부 주소로 요청하도록 유도)
   ▼
인스턴스 메타데이터 서비스 호출  http://169.254.169.254/...
   │  (IMDSv1이면 토큰 없이 그대로 응답)
   ▼
인스턴스 역할의 '임시 자격증명' 획득 (AccessKey/Secret/Token)
   │
   ▼
그 권한으로 다른 역할을 assume-role → 역할 체이닝
   │
   ▼
관리 권한에 도달 → 계정 전반으로 횡적 이동

각 단계는 그 자체로는 평범합니다. 무서운 건 이들이 ‘이어진다’는 점이고, 그 연결의 첫 단추가 보통 설정 한 줄(IMDSv1 허용, 과대 권한 역할)이라는 점입니다.

IAM — 가장 깊은 곳

클라우드 권한 상승의 심장은 IAM입니다. 노출된 액세스 키, Action:* 같은 와일드카드 정책, 그리고 iam:PassRole·iam:CreatePolicyVersion 같은 ‘조합하면 위험해지는’ 권한이 있는지 살펴봅니다.

# 지금 이 자격증명이 가진 권한부터 차분히 확인합니다
aws sts get-caller-identity
aws iam list-attached-user-policies --user-name <user>

# 위험 신호 예: PassRole + 람다/EC2 생성 권한
# → 더 높은 권한의 역할을 ‘넘겨받아’ 실행하는 상승 경로가 열립니다

자주 보이는 설정 오류

영역	자주 마주치는 설정
스토리지	공개 버킷·과대 ACL, 서명 URL 남용으로 데이터 노출
네트워크	관리 포트(SSH/RDP/DB)가 0.0.0.0/0으로 열림
이미지·스냅샷	공개 AMI·스냅샷에 남은 키·민감 정보
탐지	CloudTrail 미설정·우회 가능 → 활동이 기록되지 않음

한 걸음 더 — 클라우드 위에 올라간 컴포넌트

클라우드 점검은 설정에서 끝나지 않습니다. 그 위에서 도는 워크로드 — 컨테이너 이미지, 서버리스 런타임, 오픈소스 컴포넌트 — 에 알려진(혹은 아직 알려지지 않은) 취약점이 있으면, 그게 다시 자격증명 탈취와 권한 상승의 입구가 됩니다. 실제 표적 공격(APT)이 즐겨 쓰는 경로라, 저희도 노출된 컴포넌트의 버전을 식별하고 1-day 관점으로 실제 악용 가능성을 확인합니다. (관련 글: 0-day는 어떻게 발굴되는가)

현장 노트: 클라우드 점검에서 가장 자주 드리는 권고는 의외로 단순합니다 — IMDSv2를 강제하고, 역할 권한을 최소화하고, CloudTrail을 켜두는 것. 화려하지 않지만, 위 체인의 첫 단추를 끊는 가장 확실한 방법인 것 같습니다.

자주 묻는 질문

설정 점검(CSPM) 도구가 있는데 또 필요한가요?

CSPM은 설정 ‘상태’를 잘 보여줍니다. 모의해킹은 그 설정이 실제로 ‘권한 상승 경로로 이어지는지’를 체이닝으로 확인한다는 점이 다릅니다. 둘은 보완 관계에 가깝습니다.

운영 계정에서 해도 괜찮을까요?

위험 행위는 사전 합의·통제 아래에서만 진행하고, 필요하면 별도 검증 계정을 권해드립니다. 사업자 정책도 함께 확인합니다.

마치며

클라우드는 설정 한 줄이 계정 전체를 좌우할 만큼 민감하지만, 반대로 그 한 줄을 바로잡으면 큰 위험을 한 번에 줄일 수 있습니다. 우리 환경의 권한 경계를 함께 따라가 보고 싶으시면 클라우드 모의해킹 상담으로 편하게 연락 주세요.