루트킷 탐지를 위한 방안

By PLURA 2026-05-04

루트킷 탐지, 파일만 보면 충분할까요?

KISA는 리눅스 커널 루트킷 점검을 위한 가이드와 스크립트를 공개했습니다.

이는 매우 의미 있는 조치입니다. 루트킷은 일반적인 사용자 명령어만으로는 확인이 어렵고, 침해 이후에도 자신을 숨기도록 설계되는 경우가 많기 때문입니다.

다만 실제 운영 환경에서는 한 가지를 분명히 이해해야 합니다.

KISA 점검 스크립트는 주로 파일 시스템과 서비스 등록 흔적을 확인합니다.
그러나 커널 메모리에 이미 로드된 모듈이나 런타임 커널 변조까지 모두 탐지하는 도구는 아닙니다.

rootkit detection strategy

🔍 KISA 루트킷 점검 스크립트의 핵심 구조

KISA가 공개한 리눅스 커널 루트킷 점검 가이드는 감염 시 일반적인 사용자 레벨 명령어로 확인이 어려운 특징을 참고하여 제작된 점검 스크립트를 포함합니다.

공개 안내에 따르면 주요 점검 절차는 다음과 같습니다.

No	점검 절차	의미
1	부팅/서비스 디렉터리 내 파일시스템 inode 스캔	서비스 등록 파일, 자동 실행 파일, 숨김 파일 흔적 확인
2	파일시스템 기반 스캔 결과와 사용자 레벨 파일 목록 비교	사용자 명령어에서 보이는 결과와 실제 파일시스템 결과 비교
3	이전 점검 결과와 현재 결과 비교	새로 생긴 의심 파일 또는 숨겨진 서비스 변화 확인
4	서비스에 등록된 루트킷 악성코드 탐지	부팅 또는 서비스 등록 기반 지속성 확인

즉, 핵심은 파일 기반 탐지입니다.

파일시스템에 존재하는 숨김 파일, inode 차이, 서비스 등록 흔적, 자동 실행 등록 여부를 비교하여 루트킷 감염 가능성을 확인하는 방식입니다.

이 방식은 필요합니다. 특히 루트킷이 디스크에 파일을 남기거나, 부팅 시 자동 실행되도록 서비스를 등록하는 경우에는 효과적으로 이상 징후를 찾을 수 있습니다.

⚠️ 그런데 왜 `modprobe`는 탐지되지 않을까요?

리눅스에서 다음과 같은 명령어를 실행할 수 있습니다.

sudo bash -c 'modprobe dummy'

이 명령은 dummy라는 커널 모듈을 로드합니다.

하지만 Rootkit Detection Scanner에서는 다음과 같이 출력될 수 있습니다.

[OK] No Hidden Entry
[OK] Rootkit Not Found

이것은 단순히 “도구가 잘못됐다”는 뜻이 아닙니다.

더 정확히 말하면, 탐지 대상이 다르기 때문입니다.

modprobe는 파일을 새로 만들거나 서비스를 등록하는 행위가 아닙니다. 이미 시스템에 존재하는 커널 모듈을 찾아 커널 메모리에 로드하는 정상 리눅스 명령입니다.

따라서 파일시스템 중심 점검에서는 이 행위가 이상으로 보이지 않을 수 있습니다.

🧩 탐지 대상의 차이

modprobe의 주요 동작은 다음과 같습니다.

/lib/modules/<kernel-version>/ 경로에서 모듈 탐색
필요한 의존성 확인
커널 메모리에 모듈 적재
/proc/modules, /sys/module/, lsmod 결과에 로드 상태 반영

중요한 점은 이것입니다.

modprobe 실행은 새로운 지속성 파일을 만드는 행위가 아니라, 커널 런타임 상태를 변경하는 행위입니다.

따라서 파일 기반 점검과 커널 메모리 기반 점검은 보는 대상이 다릅니다.

No	구분	주로 보는 대상	대표 확인 항목
1	파일 기반 Rootkit Scanner	디스크	inode, 숨김 파일, 서비스 등록, 자동 실행 파일
2	`modprobe` 기반 모듈 로드	커널 메모리	로드된 모듈 목록, `/proc/modules`, `/sys/module/`
3	커널 루트킷 탐지	런타임 커널 상태	커널 모듈, 시스템 콜 변조, 커널 이벤트, 메모리 포렌식

파일 기반 점검 도구는 디스크에 남은 흔적을 찾는 데 강합니다.

반면 커널 모듈 로드와 같은 행위는 런타임 상태를 확인해야 보입니다.

🧠 실제 변화는 어디에서 발생하나요?

modprobe dummy를 실행하면 시스템에는 다음과 같은 변화가 발생합니다.

lsmod | grep dummy
cat /proc/modules | grep dummy
ls /sys/module/dummy

예를 들어 다음과 같은 결과가 확인될 수 있습니다.

dummy 12288 0 - Live 0x0000000000000000

또는 포렌식 결과에서는 다음과 같은 형태로 나타날 수 있습니다.

dummy | 12288 | 0 | (None) | kernel | linux-modules-6.8.0-101-generic | kernel/drivers/net/dummy.ko.zst

이 정보가 의미하는 것은 단순합니다.

dummy 모듈이 실제 커널에 로드됨
커널 모듈 목록이 변경됨
/proc/modules와 /sys/module/에 런타임 상태가 반영됨
그러나 새로운 서비스 파일이나 자동 실행 파일이 생성된 것은 아님

따라서 파일 중심 루트킷 스캐너에서는 이상 없음으로 보일 수 있습니다.

🚨 보안 관점에서 중요한 이유

dummy 모듈 자체는 정상적인 커널 모듈입니다.

문제는 공격자가 같은 구조를 악용할 수 있다는 점입니다.

공격자는 다음과 같은 방식으로 커널 영역을 노릴 수 있습니다.

악성 LKM(Loadable Kernel Module) 로드
커널 함수 후킹
프로세스, 포트, 파일, 네트워크 연결 은닉
보안 도구의 관찰 결과 조작
파일 흔적을 최소화한 메모리 중심 공격 수행

이 경우 파일 기반 탐지만으로는 충분하지 않습니다.

루트킷이 이미 커널 영역에서 동작하고 있다면, 사용자 레벨 명령어의 결과 자체가 조작될 수도 있습니다. 따라서 단순히 ps, netstat, ls, find 결과만 믿는 방식은 위험할 수 있습니다.

🔒 파일 기반 탐지의 한계

파일 기반 루트킷 점검은 필요합니다.

다만 다음 영역까지 모두 확인한다고 보기는 어렵습니다.

No	한계 영역	설명
1	커널 메모리	런타임에 로드된 모듈, 커널 구조체 변조는 별도 확인 필요
2	시스템 콜 후킹	사용자 명령어 결과가 조작될 수 있음
3	eBPF 기반 은닉	파일이 아니라 커널 내부 프로그램 형태로 동작할 수 있음
4	일시적 모듈 로드	공격 후 언로드하면 파일 기반 점검 시점에는 흔적이 제한적일 수 있음
5	메모리 전용 공격	디스크 파일 없이 동작하는 경우 파일 스캔만으로 확인 어려움

결국 중요한 것은 도구 하나의 문제가 아닙니다.

파일을 보는 도구와 커널 상태를 보는 도구는 역할이 다릅니다.

🛡️ 루트킷 탐지를 위한 보완 방안

루트킷 탐지는 다음과 같이 계층적으로 접근하는 것이 좋습니다.

No	점검 항목	확인 방법
1	파일 기반 흔적	KISA Rootkit Detection Scanner, inode 비교, 서비스 등록 확인
2	로드된 커널 모듈	`lsmod`, `/proc/modules`, `/sys/module/` 확인
3	커널 로그	`dmesg`, `journalctl -k` 기반 모듈 로드 이력 확인
4	계정 및 권한 변화	sudoers, 계정 생성, 권한 상승 흔적 확인
5	프로세스 실행 행위	`modprobe`, `insmod`, `rmmod` 실행 이벤트 수집
6	네트워크 이상 행위	비정상 포트, 은닉 연결, 외부 C2 통신 확인
7	포렌식 비교	이전 상태와 현재 상태의 커널 모듈 수, 모듈명, 경로 차이 비교
8	EDR/XDR 상관분석	명령 실행, 커널 이벤트, 네트워크 행위, 계정 행위를 함께 분석

특히 운영 환경에서는 단순히 현재 로드된 모듈만 보는 것이 아니라, 누가, 언제, 어떤 명령으로 모듈을 로드했는지까지 확인해야 합니다.

🔎 실무에서 볼 만한 명령어

다음 명령은 커널 모듈 상태 확인에 도움이 됩니다.

# 현재 로드된 모듈 확인
lsmod

# 특정 모듈 확인
lsmod | grep dummy

# 커널 모듈 런타임 정보 확인
cat /proc/modules

# sysfs 기반 모듈 정보 확인
ls -al /sys/module/

# 커널 로그 확인
dmesg | grep -i module
journalctl -k | grep -i module

# 모듈 파일 위치 확인
modinfo dummy

다만 루트킷 감염이 의심되는 시스템에서는 사용자 레벨 명령어 결과가 조작될 수 있습니다.

따라서 중요한 서버라면 다음과 같은 방식도 함께 고려해야 합니다.

신뢰 가능한 외부 부팅 매체 기반 점검
메모리 덤프 기반 포렌식
커널 모듈 기준선(baseline) 비교
운영 중 커널 모듈 로드 이벤트 실시간 수집
EDR/XDR 기반 행위 분석

✅ 정리하면

KISA가 공개한 루트킷 점검 스크립트는 의미 있는 파일 기반 점검 도구입니다.

하지만 modprobe 기반 커널 모듈 로드는 기본적으로 커널 메모리 상태 변화입니다.

따라서 파일시스템, inode, 서비스 등록 여부를 중심으로 확인하는 방식에서는 탐지되지 않을 수 있습니다.

이것은 KISA 도구가 무의미하다는 뜻이 아닙니다.

오히려 다음 사실을 알려줍니다.

루트킷 탐지는 파일 점검만으로 끝나서는 안 되며, 커널 런타임 상태와 행위 기반 탐지를 함께 봐야 합니다.

파일 기반 점검은 출발점입니다.

그러나 커널 루트킷 대응은 다음 단계까지 이어져야 합니다.

파일 흔적 확인
커널 모듈 상태 확인
명령 실행 이력 확인
네트워크 이상 행위 확인
포렌식 기준선 비교
EDR/XDR 기반 상관분석

결국 루트킷 탐지의 핵심은 단순히 “파일이 있는가”가 아닙니다.

커널에서 실제로 무엇이 실행되고 있는가를 함께 확인하는 것입니다.

📖 관련 자료

KISA 보호나라: 리눅스 커널 루트킷 점검 가이드 배포