공성전에서 성을 지키는 방법 🏰⚔️

By PLURA 2025-09-28

옛날, 성벽🧱이 높고 해자🌊가 깊은 나라가 있었습니다.
적은 성벽을 넘을 수 없었고, 남은 길은 성문뿐이었습니다.

오늘 우리의 시스템도 같습니다.
방화벽으로 외곽은 닫혀 있고, 유일하게 열린 문은 웹 서비스(80/443) 입니다.

그래서 공격자는 성문을 정면으로 부수기보다,
성 안에 세작(백도어, 웹셸, 지속화 도구) 을 들여보내는 전략에
모든 창의와 자원을 쏟습니다.

AI 시대가 되면서 이 문제는 더 심각해졌습니다.
이제 공격자는 한두 개의 고정된 페이로드를 쓰지 않습니다.
수많은 변종, 난독화, 우회형 본문, 정상 도구 악용으로
같은 공격을 끝없이 다르게 포장할 수 있습니다.

이 글은 공성전 비유를 통해
왜 웹이 사실상 유일한 성문이 되었는지,
왜 형식 중심 점검만으로는 방어가 무너지는지,
그리고 실전에서는 무엇을 봐야 하는지를 정리합니다.

Protect the Castle

이 글의 주요 독자는
보안 실무자, WAF/EDR 운영자, CISO, 정책 담당자입니다.
비유는 쉽게, 대안은 실무적으로 정리했습니다.

1) 우화로 보는 현재: 성문·배수로·세작

먼저 비유를 명확히 해 보겠습니다.

성벽 = 네트워크 경계(방화벽, 분리망)
성문(정문) = 웹 서비스(HTTPS 443, 리다이렉트 80→443)
배수로/은닉로 = 본문 인코딩 우회, 취약 라이브러리, 관리 콘솔, 예외 설정
세작(백도어, 악성코드) = 웹셸, 악성 플러그인, 크리덴셜 탈취 후 설치된 지속화 도구

즉, 모든 성벽이 닫혀 있을수록
공격자는 결국 열린 유일한 문, 즉 웹으로 몰립니다.

그리고 그 목적은 단순하지 않습니다.

처음부터 크게 부수는 것이 아니라
조용히 들어오고
안에서 자리를 잡고
권한을 훔치고
바깥과 연결하며
나중에 다시 길을 열어두는 것

입니다.

모든 성벽이 안전할 때,
공격자는 결국 성문을 속이거나 성 안에 세작을 들이는 것 외에는 선택지가 줄어듭니다.

2) 왜 ‘웹’이 모든 공격의 관문이 되는가?

웹은 단순한 서비스 채널이 아닙니다.
현대 환경에서는 사실상 가장 넓고, 가장 복잡하고, 가장 자주 바뀌는 공격면입니다.

1. 유일한 개방 포트

대국민·대고객 서비스는 거의 모두 443을 사용합니다.
표면적으로는 단순해 보여도, 실질적으로는 대부분의 외부 트래픽이 이 문으로 들어옵니다.

2. 복잡성의 함정

웹 프레임워크, 오픈소스 컴포넌트, 플러그인, API, 업로드 기능, 인증 모듈이 얽히면서
기능은 곧 공격면이 됩니다.

3. 운영 상시 변경

배포, 긴급 패치, 설정 변경, 블루/그린 전환, 예외 처리 등이 반복되면서
보안 규칙은 항상 뒤따라가는 구조가 됩니다.

4. TLS 암호화

내용이 보이지 않으면
WAF나 중간 보안장비는 겉모양만 본 채 판단할 수밖에 없습니다.
결국 TLS 종단 위치와 본문 가시성이 실전 방어의 핵심이 됩니다.

즉, 공격자는 웹이라는 성문을 통과하기만 하면
안쪽에서 더 유리한 전투를 벌일 수 있습니다.

3) 세작 제조의 진화 — “수백 명 → 수억 개”

예전에는 한 개의 세작, 한 개의 백도어를 만들기 위해
사람 수십 명, 수백 명이 많은 시간을 써야 했습니다.

하지만 이제는 다릅니다.

AI는

난독화
인코딩 변형
우회형 본문 생성
폴리모픽 변종
정상처럼 보이는 명령 조합

을 자동으로 반복할 수 있습니다.

즉, 예전의 방어가
“하나의 악성 파일, 하나의 문자열, 하나의 패턴”을 찾는 게임이었다면,
지금의 방어는
끝없이 변형되는 행동 흐름을 상대하는 게임이 되었습니다.

그래서 시그니처와 정적 룰만으로는 누수가 생길 수밖에 없습니다.

예전엔 한 명의 세작을 찾으면 됐지만,
이제는 군중 속에 섞인 수많은 세작 변종을 구분해야 합니다.

이 지점에서
행위 기반 탐지, 본문 가시성, 상관 분석이 중요해집니다.

4) “듣지 않는 귀”의 위험 — 형식주의가 만드는 괴물 정책

많은 조직은 여전히
형식 중심 보안에 머물러 있습니다.

깃발 색을 점검하고
성문 장식을 번쩍이게 하고
점검표를 채우고
인증서를 갖추는 데 익숙합니다

하지만 그 과정에서 정작 중요한 것은 비어 있는 경우가 많습니다.

웹 요청/응답 본문 로그
서버 감사 로그
프로세스 트리
웹 이벤트와 호스트 이벤트의 연결성

이것이 없으면
실전 방어는 사실상 불가능합니다.

형식 중심 보안은
성문이 반짝이는지 보지만,
정작 배수로로 들어온 세작은 보지 못합니다.

AI 방어는 데이터 없이는 불가능합니다.
웹 본문 로그와 서버 감사 로그가 비어 있으면,
AI는 볼 것도, 배울 것도, 상관 분석할 것도 없습니다.

즉, “로그 없는 AI 방어”는
실전이 아니라 구호에 가깝습니다.

5) 실전 방어 원칙 — “성문 가시성 + 성내 첩보 + 즉응”

이제 중요한 것은
무엇을 실제로 준비해야 하느냐입니다.

5.1 필수 가시성(Observability)

웹 계층

요청/응답 본문 로그
POST/JSON/XML/파일 업로드 로그
헤더·쿠키·바디 파라미터 정규화
URL 디코딩, 이중 인코딩 해제, 압축/분할 구조 해석

여기서 핵심은 단순 저장이 아니라
정규화(normalization) 입니다.

예를 들어:

이중 URL 인코딩
유니코드 우회
Base64 인코딩
스크립트 난독화
파일 확장자 위장

같은 기법을 해석하지 못하면
본문을 수집해도 실전 탐지로 이어지기 어렵습니다.

호스트 계층

Windows Sysmon / Linux auditd
프로세스 트리
명령행 인자
파일 생성/수정 이벤트
네트워크 연결
권한 상승 이벤트

TLS 가시성

WAF/리버스 프록시 등
실제 종단 지점에서 TLS를 처리해
본문 검사 가능 구조를 설계해야 합니다.

5.2 다층 방어(Defense-in-Depth)

WAF

WAF는 이제 단순 패턴 매칭을 넘어야 합니다.

본문·정규화·파일 형식 검증
확장자 ↔ MIME ↔ 매직넘버 일치 확인
프레임워크/관리콘솔/취약 컴포넌트별 전용 룰셋
문맥 기반 탐지
정상 서비스 흐름과 다른 행위 조합 탐지

예를 들어:

로그인 API인데 업로드 구조가 섞여 있거나
JSON 본문 안에 명령 실행형 문자열이 들어가거나
정상 폼과 다른 압축·인코딩 패턴이 반복될 때

이런 것은 단순 서명보다 문맥으로 봐야 합니다.

EDR/XDR

호스트에서는 다음이 중요합니다.

웹 프로세스(w3wp, php-fpm, apache, nginx 연계 프로세스, java)의 비정상 자식 프로세스 실행
웹루트 내 신규 스크립트 생성
압축·암호화 도구 실행
크리덴셜 접근 시도
외부 연결과 결합된 이상 행위

실무에서 자주 보는 패턴은 이런 식입니다.

w3wp.exe → cmd.exe
w3wp.exe → powershell.exe
php-fpm → sh / curl
웹 프로세스 직후 7z, rar, openssl 호출
웹루트 파일 생성 직후 외부 HTTPS 연결 발생

이런 체인은
단일 이벤트보다 훨씬 강한 신호입니다.

SIEM/SOAR

웹 ↔ 호스트 이벤트를 연결해
한 개의 사건(storyline) 으로 만들어야 합니다.

예:

업로드 직후 웹루트 파일 생성
비정상 프로세스 트리 생성
신규 외부 연결 발생
이후 권한 상승 또는 계정 접근 시도

이 조합은
단일 경보가 아니라 고위험 스토리라인으로 다뤄야 합니다.

그리고 자동화는
다음으로 이어져야 합니다.

세션 차단
파일 격리
계정 잠금/비밀번호 초기화
티켓 생성
증거 보존

5.3 MITRE ATT&CK 관점

실전 방어는
공격을 기능이 아니라 전술·기술·절차(TTP) 로 봐야 합니다.

Initial Access: T1190(공개 애플리케이션 익스플로잇), T1133(외부 원격 서비스)
Execution: T1059(명령 인터프리터), 웹셸 기반 명령 실행
Persistence: T1505.003(웹셸), T1053(스케줄러)
Credential Access: T1003(LSASS/LSA 계열 자격증명 접근)
Exfiltration: T1041(네트워크 유출)
Command & Control: T1071(웹 프로토콜 기반 C2)

이렇게 보면
공격은 파일 이름이 아니라 행동의 연쇄로 보이기 시작합니다.

6) 탐지·차단 플레이북

1. 프런트라인(WAF)

TLS 종단 위치에서 본문 검사 활성화
정규화 후 탐지
업로드 시 확장자·MIME·매직넘버 일치 검증
우리 환경의 프레임워크/관리콘솔/플러그인에 맞춘 전용 룰셋
사용하지 않는 스택의 룰은 기본 비활성화해 성능 보호

2. 호스트(EDR/XDR)

웹 프로세스의 자식 프로세스 실행 상시 감시
웹루트 변경 및 신규 스크립트 생성 탐지
권한 상승 및 크리덴셜 접근 차단
서버 → 외부 직접 통신 최소화(프록시·허용목록 기반)

3. 상관·대응(SIEM/SOAR)

업로드 → 웹루트 파일 생성 → 비정상 프로세스 트리 → 신규 외부 연결
= 고위험 스토리라인 경보
자동화: 세션 차단 → 파일 격리 → 계정 잠금 → 티켓 생성 → 증거 보존

7) 현장 체크리스트 ✅

이 부분은 실제 점검용으로 써야 합니다.

요청/응답 본문 로그가 저장·조회·검색 가능한가?
(PII 마스킹·보존정책 포함)
TLS 가시성을 확보했는가?
(종단 위치, 재암호화, 성능 테스트 포함)
프레임워크/플러그인 인벤토리가 최신 상태인가?
취약 컴포넌트별 룰셋이 반영되는가?
본문 정규화 정책이 있는가?
(이중 디코드, 압축 해제, 인코딩 우회 처리 포함)
웹루트 변경 탐지가 적용되어 있는가?
웹 프로세스의 자식 프로세스 실행을 감시하고 있는가?
서버 아웃바운드 제어가 프록시/허용목록 기반으로 적용되어 있는가?
MITRE ATT&CK 기반 상관 규칙이 운영 중인가?
(웹 이벤트 ↔ 호스트 이벤트 ↔ 외부 연결)
릴리스·패치 거버넌스가 있는가?
블루/그린, 롤백, DR 전환 시 보안 룰이 함께 동기화되는가?
오탐·미탐 리뷰를 주기적으로 수행하는가?
Table-top / Purple Team 훈련으로 웹 침투 시나리오를 반복 검증하는가?

8) 자주 틀리는 정책들 🙅

다음과 같은 상태는 실무에서 매우 자주 보지만, 매우 위험합니다.

1. 형식 점검만 강화하고 본문·감사 로그는 비어 있는 상태

겉으로는 관리가 잘되는 것처럼 보이지만,
실제 공격은 설명하지 못합니다.

2. 우리 스택에 없는 취약점 룰까지 전부 활성화

성능 저하, 오탐 증가, 운영 피로만 커집니다.

3. 아웃바운드 무제한 허용

서버가 클라이언트처럼 자유롭게 외부와 통신하면
유출과 C2 통로를 스스로 열어 주는 셈입니다.

4. TLS를 끝까지 밀폐

장비가 내용을 보지 못하면
결국 “보안이 있는 척하는 장식”이 될 수 있습니다.

9) 결론 — “성문을 본문으로 본다”

AI 시대의 공성전에서
공격의 기술은 세작 대량생산으로 진화했습니다.

우리가 해야 할 일은 단순합니다.

🚪 문을 보듯 본문을 보라.
🗣️ 성내의 속삭임(감사 로그)을 기록하라.
🔗 웹 ↔ 호스트를 하나의 사건으로 이해하고 자동으로 대응하라.

데이터가 쌓이면
비로소 AI도 거짓과 진짜를 가려내는 훈련을 시작할 수 있습니다.
그때 세작은
군중 속에 숨어 있더라도 결국 드러납니다.

보안의 핵심은
형식을 더 늘리는 것이 아니라,
보이지 않던 세작을 실제로 보이게 만드는 것입니다.

📖 함께 읽기

PLURA-XDR는 웹 본문 로그와 호스트 감사로그를 수집·상관·자동 대응까지 연결해
보이지 않던 세작을 가시화 → 격리 → 증거화하는 구조를 지향합니다.