404. 지속성·재침투 — 지속성 정상 기준선 만들기

목록 보기

404/450

시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 4/50편 (전체 404/450)
학습 단계: 지속성·재침투 기본 개념
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

지속성 탐지는 결국 "원래 없던 자동 실행·접근 장치가 생겼는가"를 묻는 일입니다. 이 질문에 답하려면 먼저 "원래 있던 것"의 목록, 즉 지속성 기준선(persistence baseline)이 있어야 합니다.

지속성 기준선 구성 요소
 계정   : 로그인 가능 계정·UID 0·sudo 권한자
 인증   : authorized_keys 지문·PAM 모듈 목록
 스케줄 : crontab·cron.d·at·systemd timer
 서비스 : enabled 유닛·사용자 유닛·drop-in
 부팅   : rc.local·udev 규칙·커널 모듈·ld.so.preload
 셸     : /etc/profile.d·각 계정 ~/.bashrc 해시
   ↓
 정상 목록(해시·날짜·담당자) 저장 → 정기 diff

핵심: 기준선 없는 지속성 점검은 "느낌"에 의존

기준선은 한 번 만들고 끝나는 문서가 아니라 승인된 변경이 반영되며 계속 갱신되는 목록입니다. 기준선에 없는 항목이 나타나는 순간이 지속성 탐지의 출발점입니다.

2. 왜 중요한가

신규 지속성은 "목록에 없던 항목"으로만 정의할 수 있어 기준선이 탐지의 전제가 됩니다.
정상 자동화(백업 cron, 모니터링 에이전트)를 미리 등록해 두면 오탐이 크게 줄어듭니다.
사고 후 근절 단계에서 "무엇을 지워야 하는가"를 결정하는 비교 기준이 됩니다.

3. 핵심 명령어 / 설정

항목	수집 명령	저장 형태
계정	`getent passwd`, `awk -F: '$3==0' /etc/passwd`	계정명·UID·셸
SSH 키	`ssh-keygen -lf <authorized_keys>`	계정별 지문
cron	`ls -la /etc/cron*`, `crontab -l -u <user>`	파일 해시
systemd	`systemctl list-unit-files --state=enabled`	유닛명·경로
부팅	`lsmod`, `cat /etc/ld.so.preload`	모듈·라이브러리 목록
셸	`sha256sum /etc/profile.d/* ~/.bashrc`	파일 해시

4. 실습 (실습 예시)

# 지속성 기준선 수집 (분석 방법, 읽기 전용)
B=/root/baseline/persist-$(date +%F); sudo mkdir -p "$B"
getent passwd | awk -F: '$7!~/(nologin|false)$/{print $1,$3,$7}' | sudo tee "$B/accounts.txt" >/dev/null
for h in /root /home/*; do f="$h/.ssh/authorized_keys"; [ -f "$f" ] && ssh-keygen -lf "$f" | sed "s|^|$h |"; done | sudo tee "$B/ssh_keys.txt" >/dev/null
sudo find /etc/cron* /var/spool/cron -type f -exec sha256sum {} + | sudo tee "$B/cron.sha256" >/dev/null
systemctl list-unit-files --state=enabled --no-legend | sudo tee "$B/units.txt" >/dev/null
lsmod | awk 'NR>1{print $1}' | sort | sudo tee "$B/modules.txt" >/dev/null
sudo sha256sum /etc/profile.d/* /etc/bashrc /etc/ld.so.preload 2>/dev/null | sudo tee "$B/shell.sha256" >/dev/null
# 다음 점검 때 diff로 비교
# diff <(sort 이전/units.txt) <(sort 현재/units.txt)

5. 정상 상태

$ diff baseline/units.txt current/units.txt
(차이 없음)
$ diff baseline/ssh_keys.txt current/ssh_keys.txt
(차이 없음)

기준선과 현재 상태가 일치하거나, 차이가 있어도 변경 요청(티켓)·패키지 업데이트로 설명되는 상태가 정상입니다.

6. 이상 상태

$ diff baseline/units.txt current/units.txt
> dbus-helper.service   enabled   enabled
$ diff baseline/ssh_keys.txt current/ssh_keys.txt
> /root 256 SHA256:Qm3x...k9 (no comment) (ED25519)
→ 승인 기록 없는 유닛·키가 기준선 밖에 출현

기준선에 없는 enabled 유닛·SSH 키 지문 → 신규 지속성 후보
정상 이름을 흉내 낸 유닛(dbus-helper)·주석 없는 키 → 위장 의심
변경 티켓·패키지 이력으로 설명되지 않으면 → 조사 대상으로 승격

7. 로그 분석 (분석 방법)

기준선 diff 기반 판정 흐름입니다(가상의 예시).

[정기 수집] 계정·키·스케줄·서비스·부팅·셸
   ↓
[diff] 기준선 대비 추가 / 삭제 / 변경
   ↓
[설명 가능?] 변경 티켓·패키지 로그·배포 기록
   ├─ 예 → 기준선 갱신(승인자·날짜 기록)
   └─ 아니오 → 지속성 후보 → 작성자·시점 추적(auditd)

diff 유형	해석
추가	신규 지속성 후보(가장 중요)
변경	기존 항목 변조(내용 교체)
삭제	정리 또는 흔적 제거

특히 "추가"는 승인 기록과 바로 대조하고, "변경"은 해시가 바뀐 파일의 내용 diff까지 확인해야 합니다.

8. SOC 관제 포인트

기준선은 해시·지문·담당자·날짜를 함께 저장해야 증거로 쓸 수 있습니다.
diff 결과의 "추가" 항목은 auditd 기록으로 작성자(auid)·시점을 반드시 역추적합니다.
승인된 변경만 기준선에 반영하고, 반영 이력 자체도 보관합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_i,persistence,">
  <rule id="108030" level="7">
    <if_sid>108000</if_sid>
    <field name="audit.key">persist_baseline</field>
    <description>지속성 기준선 점검 스크립트 차이 발견(신규 지속성 후보)</description>
    <mitre><id>TA0003</id></mitre>
  </rule>
</group>

기준선 diff 스크립트가 차이를 발견하면 logger로 persist_baseline 이벤트를 남기고 Wazuh가 수집하도록 설계합니다. 기준선 자체가 탐지 규칙의 "정상 목록" 역할을 합니다.

10. 대응 방법

초기 확인 — 기준선 diff에서 추가·변경된 지속성 항목을 목록화합니다.
범위 확인 — 같은 시점에 다른 위치(키·cron·유닛)에도 변화가 있는지 전수 비교합니다.
증거 확보 — diff 결과·해당 파일 사본·해시를 증거로 보존합니다.
차단/조치 — 승인되지 않은 항목은 격리(비활성화) 후 제거 여부를 결정합니다.
재발 방지 — 승인 절차와 기준선 갱신을 연결해 비인가 변경이 바로 드러나게 합니다.

11. 핵심 정리

구성	핵심
대상	계정·키·스케줄·서비스·부팅·셸
형태	목록 + 해시 + 담당자 + 날짜
판정	diff "추가"를 승인 기록과 대조
갱신	승인된 변경만 반영
면접 포인트	"지속성 탐지는 기준선 diff — 목록에 없던 자동 실행이 곧 후보"