홈페이지 위변조 해킹 탐지 방법 — 파일 무결성 모니터링과 실시간 행위 분석이 필요한 이유

By PLURA 2020-06-04

홈페이지 위변조(Defacement)는 오래된 공격처럼 보이지만,
지금도 여전히 매우 실전적인 위협입니다.

공격자는 웹사이트를 침해한 뒤

필요한 정보를 먼저 탈취하고,
이후 2차 피해를 위해 악성코드를 심거나,
웹쉘을 남겨 지속적인 접근 경로를 유지하려고 합니다.

즉, 홈페이지 위변조는 단순한 “화면 바꾸기”가 아닙니다.
그 뒤에는 종종 지속적 침해, 악성코드 유포, 추가 데이터 유출이 숨어 있습니다.

공개된 통계와 기사들에서도
국내에서 홈페이지 위변조 공격은 오랫동안 반복되어 온 문제로 언급되어 왔습니다. :contentReference[oaicite:1]{index=1}

이 글에서는
홈페이지 위변조가 왜 중요한지,
어떤 방식으로 발생하는지,
그리고 파일 무결성 모니터링(FIM) + 웹 로그 + 서버 감사 로그를 통해
어떻게 더 현실적으로 탐지할 수 있는지를 정리합니다.

homepage_hack

홈페이지 위변조 해킹 탐지 방법

1. 홈페이지 위변조는 왜 위험한가?

홈페이지 위변조라고 하면
많은 사람이 단순히 첫 화면 문구가 바뀌는 정도를 떠올립니다.

하지만 현실의 위변조는 훨씬 더 다양합니다.

대표적인 목적

악성코드 유포
피싱 페이지 삽입
웹쉘 유지
SEO 스팸 삽입
방문자 브라우저를 외부 악성 사이트로 리다이렉트
관리자만 모르게 특정 코드만 삽입

즉, 공격자는
단순한 과시보다도 추가 침해와 지속성 확보를 더 중요하게 생각합니다.

2. 위변조 공격은 어떤 방식으로 발생하나?

홈페이지 위변조는 대체로 다음과 같은 흐름으로 발생합니다.

1) 취약한 웹 애플리케이션 또는 서버 침투

취약한 CMS/게시판/플러그인 악용
파일 업로드 취약점
취약한 관리자 페이지
원격 코드 실행 취약점

2) 파일 또는 내용 변경

index.php, index.html, main.js 같은 핵심 파일 수정
공용 헤더/푸터 파일에 외부 스크립트 삽입
정적 자원(JS/CSS) 변조
특정 경로에 악성 HTML 삽입

3) 지속성 확보

웹쉘 업로드
관리자 계정 추가
예약 작업 등록
숨겨진 백도어 코드 삽입

즉, 위변조는 결과이고,
그 이전에는 거의 항상 침입이 존재합니다.

3. 위변조의 주요 유형을 구분해야 합니다

위변조를 잘 탐지하려면
무엇이 바뀌는지를 먼저 구분해야 합니다.

A. 파일 내용 변조

가장 전형적인 유형입니다.

예:

index.php에 iframe 삽입
외부 자바스크립트 로더 추가
악성 링크 배너 삽입

B. 파일 추가형 위변조

기존 파일을 바꾸지 않고
새로운 악성 파일을 넣는 방식입니다.

예:

shell.php
cache.php
tmp1.asp
정상 파일처럼 보이는 백도어

C. 메타데이터·배포 산출물 변조

콘텐츠 자체보다
배포 파일, JS 번들, 템플릿 조각이 바뀌는 경우입니다.

예:

app.min.js에 난독화 코드 삽입
공용 include 파일 변경
CDN 업로드 전 정적 파일 변조

D. 공급망형 위변조

직접 홈페이지 파일을 바꾸지 않고,
외부에서 불러오는 코드가 변조되는 경우입니다.

예:

서드파티 JS 스크립트 변조
외부 광고/분석 스크립트 악용
패키지/라이브러리 공급망 오염

즉, “첫 페이지가 바뀌었는가”만 보면
많은 위변조를 놓칠 수 있습니다.

4. 기존 보안 장비만으로는 왜 놓치기 쉬운가?

기존 보안 장비가 아무 의미 없다는 뜻은 아닙니다.
하지만 홈페이지 위변조는 다음 이유 때문에 자주 놓칩니다.

1) 방화벽/WAF는 ‘들어오는 공격’ 중심

침투를 막는 데는 중요하지만,
이미 침투가 발생한 뒤 파일이 바뀌는 순간까지 항상 설명해 주지는 못합니다.

2) SIEM은 로그가 있어야만 의미가 있음

단순 syslog 집계만으로는
실제 어떤 파일이 언제 어떻게 바뀌었는지 보기 어렵습니다.

3) 화면만 보면 늦음

운영자가 직접 홈페이지를 열어 보고
“이상하다”고 느끼는 시점은 이미 늦은 경우가 많습니다.

즉, 위변조 대응의 핵심은
침입 자체 탐지 + 파일 무결성 모니터링 + 변경 원인 추적입니다.

5. 그래서 필요한 것이 파일 무결성 모니터링(FIM)입니다

위변조 탐지의 가장 기본적인 방법은
파일 무결성 모니터링(FIM, File Integrity Monitoring) 입니다.

이 방식은
지정한 파일이나 경로의 상태를 지속적으로 감시하다가,

파일이 수정되거나
새 파일이 생기거나
삭제되거나
권한이 바뀌거나
예상하지 않은 해시 변경이 발생하면

경고를 발생시킵니다.

FIM의 핵심 가치

“바뀌면 안 되는 파일”을 정확히 감시할 수 있음
화면이 바뀌기 전에도 파일 변경을 감지 가능
운영자가 직접 비교하지 않아도 변경 사실을 확인 가능
복구 및 원인 분석의 출발점 제공

즉, 홈페이지 위변조 대응의 첫걸음은
무엇이 바뀌었는지 가장 먼저 아는 것입니다.

6. FIM만으로는 부족한 이유

하지만 FIM만으로는 부족합니다.

왜냐하면 FIM은
“바뀌었다”는 사실은 알려 주지만,
누가 왜 어떻게 바꿨는지는 충분히 설명하지 못하기 때문입니다.

그래서 함께 필요한 것이 다음입니다.

1) 웹 로그

어떤 요청이 들어왔는지
어떤 업로드가 있었는지
어떤 URL이 호출됐는지

2) 서버 감사 로그

어떤 프로세스가 실행됐는지
누가 파일을 수정했는지
어떤 계정이 접근했는지

3) 상관 분석

특정 요청 직후 파일이 바뀌었는지
웹 프로세스가 자식 프로세스를 만들었는지
외부 연결과 함께 파일 생성이 있었는지

즉, 실전에서는
FIM + 웹 로그 + 감사 로그를 함께 봐야
단순 변경 감지를 넘어 침해 시나리오로 볼 수 있습니다.

7. 실전 탐지 예시: index.php에 iframe 삽입

가장 전형적인 위변조 사례 중 하나는
홈페이지 메인 파일에 악성 iframe을 삽입하는 방식입니다. :contentReference[oaicite:2]{index=2}

예를 들어 공격자가 index.php에 다음과 같은 코드를 넣을 수 있습니다.

외부 악성 유포지 연결
방문자 브라우저 리다이렉트
보이지 않는 프레임으로 악성 페이지 로드

이 경우 방문자는 정상 사이트에 접속했다고 생각하지만,
실제로는 악성 유포지와 연결될 수 있습니다. :contentReference[oaicite:3]{index=3}

이런 유형에서 중요한 탐지 포인트는 다음과 같습니다.

탐지 포인트

index.php 해시 변경
웹루트 내 파일 수정 시간 변경
웹 프로세스 계정의 비정상 파일 쓰기
특정 요청 직후 파일 생성/수정
외부 도메인 참조 문자열 삽입

즉, 단순히 “페이지가 바뀌었다”가 아니라
파일 수정 자체와 수정 흐름을 잡아야 합니다.

8. 실제 운영에서는 어떻게 설정해야 하나?

기존 글에서 장점이었던 부분은
설정이 매우 직관적이었다는 점입니다. :contentReference[oaicite:4]{index=4}

예를 들어 PLURA에서는 다음 경로를 통해
홈페이지 위변조 감시 필터를 설정할 수 있습니다. :contentReference[oaicite:5]{index=5}

1. [PLURA 메뉴] → [필터] → [보안] → [홈페이지 위변조]

그리고 감시하려는 파일 또는 경로를 지정하면
해당 파일이 변조될 때 탐지가 가능합니다. :contentReference[oaicite:6]{index=6}

여기서 중요한 것은
도구 이름보다도 무엇을 감시 대상으로 삼을 것인가입니다.

우선 감시해야 할 경로

웹루트 메인 파일 (index.php, index.html, default.asp)
공용 include/header/footer 파일
업로드 디렉터리
실행 가능 스크립트 경로
JS/CSS 번들 산출물
관리자 페이지 관련 파일

즉, 모든 파일을 무작정 감시하기보다
공격자가 바꾸면 바로 영향이 큰 파일부터 우선 관리해야 합니다.

9. 운영 체크리스트

아래 항목은 지금 시점에 바로 점검할 수 있는 체크리스트입니다.

홈페이지 위변조 대응 체크리스트

메인 페이지와 공용 템플릿 파일에 대한 FIM이 활성화되어 있는가
웹루트 전체 또는 주요 경로의 해시 기준선(Baseline) 이 존재하는가
업로드 디렉터리에 실행 가능 파일 업로드가 차단되어 있는가
웹서버 프로세스 계정의 파일 쓰기 권한이 최소화되어 있는가
웹 로그와 감사 로그가 중앙에서 조회 가능한가
파일 변경 이벤트와 웹 요청 이벤트를 상관 분석할 수 있는가
위변조 탐지 후 복구할 정상 원본이 준비되어 있는가
웹쉘 탐지 규칙과 비정상 프로세스 실행 탐지가 있는가
정적 파일(CSS/JS/이미지) 위변조도 별도로 감시하는가
서드파티 스크립트·광고 코드·외부 JS 의존성을 관리하고 있는가

10. 최근 기준으로 이 글을 업데이트한다면 무엇이 더 필요할까?

2020년 당시에는
“파일이 바뀌었다”는 것만 알아도 큰 의미가 있었습니다.

하지만 지금은 더 나아가야 합니다.

추가로 필요한 것

웹쉘 탐지
프로세스 트리 분석
정상 배포와 비정상 변경 구분
정적 파일/CDN/공급망 변조 대응
응답 본문 기반 악성 삽입 탐지
배포 파이프라인 무결성 검증

즉, 위변조 탐지는
단순 파일 감시를 넘어
웹 침해 전체를 이해하는 문제가 되었습니다.

11. 현실적인 정리

홈페이지 위변조는
지금도 충분히 현실적인 공격입니다.

그리고 이 공격은
다음 순서로 대응해야 합니다.

파일 변경을 가장 먼저 알아차린다
누가 어떻게 바꿨는지 로그로 추적한다
웹쉘/백도어 등 추가 침해 흔적을 점검한다
정상 원본으로 복구한다
재발 방지 규칙을 만든다

이 과정에서
파일 무결성 모니터링(FIM) 기능이 강한 솔루션,
예를 들어 PLURA 같은 구조를 활용하면
실무 운영은 훨씬 쉬워질 수 있습니다.

다만 중요한 것은
제품 이름보다 먼저 원칙입니다.

위변조를 보려면,
파일을 보고, 로그를 보고, 그 둘을 연결해야 합니다.

결론

홈페이지 위변조 탐지는
단순한 화면 감시가 아닙니다.

그것은

파일 무결성 모니터링
웹 로그 분석
서버 감사 로그
웹쉘/지속성 점검
복구 준비

를 함께 요구하는 실전 운영 문제입니다.

기존 글은
“클릭 몇 번으로 탐지할 수 있다”는 실무 편의성을 보여 주는 데 의미가 있었습니다. :contentReference[oaicite:7]{index=7}
하지만 지금 시점에서 더 중요한 메시지는 이것입니다.

홈페이지 위변조는 단순한 훼손이 아니라,
웹 침해의 결과이자 추가 침해의 시작점일 수 있습니다.

그래서 위변조 탐지는
단순 알림 기능이 아니라
침해사고 대응의 시작점으로 봐야 합니다.