Scenario 02는 여기서 종료되지 않는다. 하편에서는 Wazuh 상관분석 · WAF 탐지/차단 · IAM 최소권한 · Network Hardening · Falco Rule 정교화 · 중앙 로그 연계 · Scenario 02 전용 CI Gate를 검증한다. 목표는 이미 완료한 코드 Hardening을 반복하는 것이 아니라, 개별 탐지 → 상관분석 → 예방 통제 → 운영 가능한 SecOps 흐름으로 확장하는 것이다.
1. 실습 목적
이번 실습의 핵심은 웹 취약점 하나를 단독으로 확인하는 것이 아니라, 애플리케이션 취약점이 클라우드 Workload 권한 악용으로 이어지는 과정 → Host/Cloud 로그에 남는 흔적 → 코드 Hardening 후 동일 공격이 실패하는지까지 하나의 흐름으로 직접 확인하는 것이었다.
JWT 검증 오류 ↓ Broken Access Control ↓ /admin/diagnostic 접근 ↓ OS Command Injection ↓ EC2 Web Process 권한으로 명령 실행 ↓ EC2 Workload IAM Role 사용 ↓ Secrets Manager GetSecretValue ↓ CloudTrail + Falco 증거 확보 ↓ Code Hardening (JWT 검증 + Server-side Authorization + shell=False/Allowlist) ↓ 동일 공격 Re-attack ↓ 위조 JWT / Command Injection 실패 확인 (401 / 400) ↓ [하편] Wazuh Correlation + WAF + IAM/Network 고도화
2. 취약 환경 구성
2.1 Terraform 기반 EC2 + IAM Workload 구성
Terraform으로 Amazon Linux 기반 EC2 인스턴스를 생성하고, 해당 인스턴스에
scenario02-web-profile을 연결했다. 부팅 시 python3-pip, git, awscli와 Flask·boto3·PyJWT 등을 설치하고, 취약한 app.py가 Web Server에서 실행되도록 구성했다.이 구조에서 중요한 점은 공격자가 별도의 Access Key를 탈취하는 것이 아니라, 이미 EC2에 정상적으로 연결된 IAM Instance Profile의 권한을 Web Process가 그대로 사용할 수 있다는 것이다.
2.2 취약한 관리자 Diagnostic API
/admin/diagnostic에는 다음 세 가지 취약 조건을 의도적으로 구성했다.jwt.decode(..., options={"verify_signature": False})로 JWT 서명 검증 생략
- Token의
role=adminClaim만 신뢰하는 Broken Access Control
ping -c 1 {host}문자열을subprocess.run(..., shell=True)로 실행하는 OS Command Injection
즉, 공격자가 관리자 Claim을 가진 JWT를 위조하면 관리자 API에 접근할 수 있고, 이후
host Query Parameter에 Shell 구문을 삽입해 Web Process 권한으로 임의 명령을 실행할 수 있다.
2.3 실습용 Security Group
실습 환경에서는 Flask App 접근을 위해 TCP 5000번 포트, 원격 관리 및 검증을 위해 TCP 22번 포트를
0.0.0.0/0에 개방했다. Egress 역시 전체 허용 상태로 구성했다.이는 실습 편의를 위한 의도적 노출 설정이며, 실제 운영 환경에서는 Source IP 제한, Bastion/SSM 사용, ALB 또는 Reverse Proxy 뒤 배치 등으로 축소해야 한다.
3. 공격 수행 및 AWS Secret 접근
3.1 Forged Admin JWT
취약 환경에서는 JWT Signature를 검증하지 않기 때문에, 공격자가
role=admin Claim을 포함한 Token을 만들어도 Server가 이를 관리자 Identity로 처리한다.공격자 JWT role = admin ↓ 서명 검증 생략 ↓ 관리자 권한으로 잘못 신뢰
3.2 Command Injection
위조 JWT를
Authorization: Bearer Header에 넣은 뒤 /admin/diagnostic의 host Parameter에 Shell Separator를 삽입해 명령 실행 여부를 확인했다.첫 번째 요청에서는
whoami를 실행해 OS Command Injection 성공 여부를 확인했고, 두 번째 요청에서는 AWS CLI를 이용해 Secrets Manager의 /lab/scenario02-secret을 조회했다.실행 결과 응답에
SecretString이 포함되어 반환되면서, 웹 애플리케이션 침해 → EC2 Workload IAM Role 권한 사용 → Secrets Manager 접근 흐름이 실제로 연결됨을 확인했다
핵심: 이번 공격에서는 IMDS에 직접 접근해 Credential을 탈취하지 않았다. 침해된 Web Process가 자신에게 정상적으로 부여된 EC2 IAM Role 권한을 그대로 악용했다.
4. CloudTrail에서 AWS API 호출 증거 확인
공격 이후 CloudTrail Event History에서
GetSecretValue 이벤트를 확인했다.상세 이벤트에는 다음 정보가 남았다.
eventSource:secretsmanager.amazonaws.com
eventName:GetSecretValue
awsRegion:ap-northeast-2
requestParameters.secretId:/lab/scenario02-secret
sourceIPAddress: 공격 명령을 실제 수행한 EC2 측 Public IP
- Credential Scope: EC2 Instance에 발급된 Workload Credential
이 기록을 통해 Secret 접근이 단순한 Application 내부 출력이 아니라, 실제로 AWS Secrets Manager API까지 호출된 사건임을 검증할 수 있었다.
5. Falco Runtime Detection
CloudTrail이 AWS Control Plane API 호출을 보여준다면, Falco는 그 전에 EC2 내부에서 발생한 Process 실행 행위를 보여준다.
5.1 Custom Falco Rule
실습에서는
python3 Web Process가 sh 또는 bash를 Spawn하는 행위를 Command Injection 징후로 탐지하도록 Custom Rule을 추가했다.Rule의 목적은 Web Application Process가 정상 요청 처리 과정에서는 실행하지 않아야 할 Shell을 생성했는지 확인하는 것이다.
5.2 Falco Alert 발생
공격 재실행 후 Falco에서 실제 Alert가 발생했다.
Alert에는 다음 정보가 포함되었다.
Python3 spawned a shell
- User:
root
- 실행 Command:
sh -c ping -c 1 127.0.0.1;whoami
- Parent Process:
python3
- Container:
host
이를 통해 HTTP 요청 자체만으로는 보이지 않던 Web Process → Shell Spawn 행위를 Runtime 수준에서 확인했다
6. 확보된 공격 Chain 증거
단계 | 행위 | 확보한 증거 |
1 | 취약 환경 배포 | Terraform EC2 + Instance Profile 구성 |
2 | 인증/인가 우회 | JWT Signature 검증 생략 + Admin Claim 신뢰 코드 |
3 | 명령 실행 | shell=True Diagnostic API와 실제 whoami 응답 |
4 | Cloud 권한 악용 | EC2 Workload Role을 이용한 Secrets Manager 호출 |
5 | AWS API 흔적 | CloudTrail GetSecretValue 이벤트 |
6 | Runtime 행위 탐지 | Falco python3 → sh Process Spawn Alert |
Forged JWT ↓ /admin/diagnostic ↓ Command Injection ↓ python3 → sh │ └─ Falco Alert ↓ AWS CLI / SDK ↓ SecretsManager:GetSecretValue │ └─ CloudTrail Event
7. 이번 실습에서 확인한 핵심
- 웹 취약점은 애플리케이션 계층에서 끝나지 않는다. Web Process가 Cloud IAM Role을 가지고 있으면 Command Injection은 곧 Cloud API 권한 악용으로 이어질 수 있다.
- IAM 최소권한이 중요한 이유를 직접 확인했다. 애플리케이션이 침해되더라도 Role에
GetSecretValue권한이 없었다면 최종 Secret 접근은 실패했을 것이다.
- CloudTrail과 Falco는 서로 다른 층을 본다. Falco는 Host Runtime의 Process Spawn을, CloudTrail은 AWS API 호출을 기록한다.
- 한 로그만으로는 공격 전체를 설명하기 어렵다.
python3 → sh와GetSecretValue를 시간 순서로 연결해야 Web-to-Cloud 공격 Context가 완성된다.
- JWT 검증과 Server-side Authorization은 별개의 방어 계층이다. Signature 검증뿐 아니라 관리자 Resource에 대한 별도 권한 검증도 필요하다.
- 방어는 수정 사실이 아니라 재공격 결과로 검증해야 한다. 동일한 위조 JWT와 Command Injection Payload를 다시 실행해 401/400 응답을 확인함으로써 코드 Hardening의 효과를 검증했다.
7. Hardening 적용 및 동일 공격 재검증
재검증 완료: 취약 코드를 보완한 뒤 동일한 공격 흐름을 다시 실행해, 이전에 성공했던 JWT 우회와 Command Injection이 더 이상 동일하게 동작하지 않는 것을 확인했다. 위조 JWT는 401, Command Injection Payload는 입력 검증 단계에서 400으로 차단되었다. 즉 이번 상편은 공격 성공 → Falco/CloudTrail 탐지 → Code Hardening → 동일 공격 실패 확인까지 포함한다.
영역 | Before | 상편 기준 상태 / 후속 |
JWT | Signature 검증 생략 | 허용 Algorithm 고정 + Signature 검증 |
Access Control | Token Claim 중심 | Server-side 관리자 권한 재검증 |
Command 실행 | shell=True • 문자열 조립 | shell=False • Argument Allowlist |
IAM | Web Role에 Secret 조회 권한 | 상편에서는 기존 Lab Secret 접근 권한 유지 · 하편에서 제거/축소 후 AccessDenied 검증 |
Network | 22/5000 전체 개방 | 상편에서는 실습용 공개 상태 유지 · 하편에서 Source 제한 또는 SSM/ALB 구조로 축소 |
Runtime | Custom Falco Rule 추가 | 1차 Custom Rule 적용 완료 · 하편에서 정상 Baseline과 AWS CLI Context를 반영해 정교화 |
SIEM | CloudTrail/Falco 개별 확인 | CloudTrail/Falco 개별 증거 확보 완료 · 하편에서 Wazuh 시간 기반 Correlation Rule 구성 |
8. 이번 실습에서 확인한 핵심
- 웹 취약점은 애플리케이션 계층에서 끝나지 않는다. Web Process가 Cloud IAM Role을 가지고 있으면 Command Injection은 곧 Cloud API 권한 악용으로 이어질 수 있다.
- IAM 최소권한이 중요한 이유를 직접 확인했다. 애플리케이션이 침해되더라도 Role에
GetSecretValue권한이 없었다면 최종 Secret 접근은 실패했을 것이다.
- CloudTrail과 Falco는 서로 다른 층을 본다. Falco는 Host Runtime의 Process Spawn을, CloudTrail은 AWS API 호출을 기록한다.
- 한 로그만으로는 공격 전체를 설명하기 어렵다.
python3 → sh와GetSecretValue를 시간 순서로 연결해야 Web-to-Cloud 공격 Context가 완성된다.
- JWT 검증과 Server-side Authorization은 별개의 방어 계층이다. Signature 검증뿐 아니라 관리자 Resource에 대한 별도 권한 검증도 필요하다.
- 방어는 수정 사실이 아니라 재공격 결과로 검증해야 한다. 동일한 위조 JWT와 Command Injection Payload를 다시 실행해 401/400 응답을 확인함으로써 코드 Hardening의 효과를 검증했다.
9. 현재 완료 범위와 다음 단계
완료
Terraform으로 취약 EC2 환경 구성
JWT/Broken Access Control/Command Injection 취약 코드 구성
Forged JWT 기반 관리자 API 접근
Command Injection으로 OS Command 실행
EC2 Workload Role을 이용한 Secrets Manager 접근
CloudTrail
GetSecretValue 증거 확보Falco Custom Rule 작성 및 Runtime Alert 확인
JWT Signature 검증 + Server-side Authorization 코드 Hardening
shell=False + 입력 Allowlist 적용동일 Forged JWT / Command Injection Payload 재실행 후 401/400 실패 확인
9. 상편 회고
이번 실습을 통해 Command Injection을 단순히
whoami가 실행되는 웹 취약점으로 보는 것과, 침해된 Process가 어떤 Cloud Identity와 권한을 가지고 있는지까지 보는 것의 차이를 확인했다.애플리케이션 취약점의 실제 영향도는 그 Process에 연결된 IAM 권한에 의해 확대될 수 있다.
또한 공격 성공 여부만 확인하는 데서 끝나지 않고 Falco와 CloudTrail을 통해 각각 Runtime과 Cloud Control Plane의 증거를 확보했으며, JWT·Authorization·Command 실행부를 보완한 뒤 동일 공격을 다시 수행해 실패까지 확인했다. 이로써 상편에서 공격 재현 → 증거 확보 → 코드 Hardening → 재검증의 한 사이클을 완성했고, 다음 단계에서는 이 Timeline을 Wazuh 상관분석과 WAF·IAM·Network 통제로 확장한다.
10. 남은 과제 및 Scenario 02 (하) 계획
본 문서는 Scenario 02의 전반부(상)이다. 이번 단계에서는 웹 취약점 → AWS Workload Role 악용 → CloudTrail/Falco 증거 확보 → 코드 Hardening → 동일 공격 실패 검증까지 완료했다. 아래에는 상편에서 끝내지 않고 하편에서 이어갈 탐지 상관분석·예방 통제·운영 고도화 과제만 남긴다.
미해결점 | 현재 상태 | 후속 검증 |
Wazuh 상관분석 | Falco와 CloudTrail 로그를 개별적으로 확인 | 5분 이내 Runtime + AWS API 이벤트를 하나의 Attack Chain Alert로 연결 |
WAF 탐지/차단 | Command Injection 요청 자체에 대한 Edge 탐지 미적용 | Query String 기반 Managed/Custom Rule 적용 후 탐지·차단 결과 확인 |
IAM 최소권한 | Web Role에 GetSecretValue 권한 존재 | Secret 접근 권한 제거/축소 후 AccessDenied 발생 확인 |
Network Hardening | 22/5000 포트 전체 공개 | Source 제한 또는 SSM/ALB 구조로 외부 노출 축소 |
Falco Rule 정교화 | python3 → sh/bash 기반 1차 Rule과 Alert 확인 완료 | 정상 행위 Baseline과 비교해 오탐을 줄이고 AWS CLI 실행 Context 추가 |
중앙 로그 연계 | CloudTrail/Falco를 각 도구에서 개별 확인 | Wazuh로 수집 경로를 통합하고 공통 Timeline으로 조회 |
Scenario 02 CI Gate | GitHub Actions SecOps CI 실습 경험은 있으나 Scenario 02 코드와의 연결은 별도 | JWT 검증 비활성화· shell=True 등 취약 Pattern을 PR 단계에서 탐지/차단 |
[상] Attack 취약점 재현 → AWS Workload Role 악용 ↓ [상] Observe CloudTrail + Falco 증거 확보 ↓ [상] Code Harden JWT/Authorization/Command 실행부 보완 ↓ [상] Re-attack 동일 Payload 실패 확인 (401 / 400) ✅ ↓ [하] Correlate + Prevent + Operationalize Wazuh + WAF + IAM/Network + 중앙 로그 + CI Gate
후속 보고서 예정:
Scenario 02 (하) — Wazuh 상관분석 · WAF · IAM/Network · Detection Engineering 고도화
