444. 지속성·재침투 — Wazuh 기반 지속성·재침투 탐지

Soc Wazuh 리눅스 보안관제 시스템 보안 · 취약점 시스템보안 지속성·재침투 지속성탐지

시스템 보안 · 취약점

목록 보기

444/450

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

선행 학습

1. 개념

지금까지 편마다 만든 감사 키와 룰을 Wazuh 하나의 탐지 스택으로 묶습니다. 핵심은 "행위(auditd) + 결과(FIM·정기 점검) + 상태(SCA)"를 각각 다른 모듈로 받아 같은 룰 그룹에서 다루는 것입니다.

Wazuh 지속성 탐지 스택
 [에이전트]
  auditd 규칙 (persist_* / account_persist / reentry_* / module_load / bin_change)
  FIM(syscheck, whodata) : /etc/cron* /etc/systemd /etc/ssh /etc/pam.d /etc/sudoers.d ...
  명령 모니터링(wodle command) : persist-inventory · persist-diff (매일)
  SCA 정책 : UID 0 단일 · ld.so.preload 없음 · rc.local 비실행 ...
   ↓
 [매니저] 디코더 → local_rules (108000~108499, group=persistence)
   ↓
 [대시보드] MITRE TA0003 · 호스트별 지속성 Alert

핵심: 행위·결과·상태 세 모듈이 서로의 공백을 메운다

FIM의 whodata 모드는 auditd를 이용해 "누가 바꿨는지"를 FIM 이벤트에 붙여 주므로, 지속성 위치 감시에 특히 유용합니다.

2. 왜 중요한가

모듈별로 흩어진 탐지를 한 룰 그룹으로 관리할 수 있습니다.
whodata로 파일 변경 결과와 변경 주체를 한 Alert에서 볼 수 있습니다.
SCA로 "지금 상태가 안전한가"를 지속적으로 평가할 수 있습니다.

3. 핵심 명령어 / 설정

모듈	역할	설정 위치
auditd 연동	행위(누가·무엇으로)	/etc/audit/rules.d/persist.rules
FIM whodata	결과 + 주체	ossec.conf `<syscheck>`
command	인벤토리·diff	ossec.conf `<wodle name="command">`
SCA	상태 평가	커스텀 정책 YAML
룰	판정·레벨·MITRE	local_rules.xml

4. 실습 (실습 예시)

# ossec.conf 핵심부 (실습 예시)
cat <<'X'
<syscheck>
  <directories whodata="yes" report_changes="yes">/etc/cron.d,/etc/crontab,/var/spool/cron</directories>
  <directories whodata="yes" report_changes="yes">/etc/systemd/system,/etc/ssh,/etc/pam.d,/etc/sudoers.d</directories>
  <directories whodata="yes">/etc/profile.d,/etc/udev/rules.d,/etc/modules-load.d</directories>
  <directories whodata="yes" report_changes="yes">/etc/ld.so.preload,/etc/rc.d/rc.local</directories>
</syscheck>
<wodle name="command">
  <tag>persist-diff</tag>
  <command>/usr/local/sbin/persist-diff</command>
  <interval>1d</interval><run_on_start>yes</run_on_start>
</wodle>
X
# 룰 검증
sudo /var/ossec/bin/wazuh-logtest

5. 정상 상태

wazuh-logtest: persist_cron 감사 이벤트 → rule 108180 (level 12) 매칭
FIM whodata: /etc/cron.d/backup modified by ansible (auid=deploy)
SCA "persistence-baseline": 12/12 passed

감사·FIM·SCA·명령 모니터링 이벤트가 모두 매니저에 도착하고, 각 이벤트가 의도한 108000번대 룰에 매칭되는 상태가 정상입니다.

6. 이상 상태

wazuh-logtest: persist_udev 이벤트 → 매칭 룰 없음 (level 0)
SCA: "ld.so.preload 없음" passed → failed
FIM: /etc/ld.so.preload added (whodata: user=root, process=/usr/bin/cp, audit_name=webadmin)

감사 키가 룰 조건에 없어 매칭 실패 → 탐지 공백(키 이름 불일치)
SCA 상태 변화 passed→failed → 지속성 설치 상태 감지
whodata로 원래 사용자(webadmin)까지 확인 → 주체 특정

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

Wazuh 구성 검증 흐름입니다(가상의 예시).

[테스트 이벤트] 지속성 위치마다 무해한 변경 1회
   ↓
[수집 확인] 매니저 archives에 도착?
   ↓
[룰 확인] wazuh-logtest → 기대 룰 ID·레벨
   ↓
[공백 기록] 미매칭 키·경로 → 룰·감사 보강 → 재검증

결과	조치
미도착	에이전트·감사 규칙 점검
도착·미매칭	룰 조건 보강
매칭·레벨 부적절	레벨 조정

감사 키 이름을 바꾸거나 새로 만들 때 룰 조건을 함께 바꾸지 않으면 조용히 탐지가 멈춥니다. 키 목록과 룰 조건을 같은 저장소에서 버전 관리하는 이유입니다.

8. SOC 관제 포인트

룰·디코더·감사 규칙·SCA 정책을 Git으로 함께 관리합니다.
분기마다 지속성 위치별 테스트 이벤트로 탐지 회귀 시험을 합니다.
SCA failed 전환은 실시간 Alert와 별도로 일일 보고에 포함합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_i,persistence,">
  <rule id="108430" level="12">
    <if_group>syscheck</if_group>
    <field name="file" type="pcre2">^/etc/(cron|systemd/system|ssh|pam\.d|sudoers|profile\.d|udev/rules\.d|modules-load\.d|ld\.so\.preload|rc\.d/rc\.local)</field>
    <description>지속성 위치 FIM 변경(whodata 주체 포함)</description>
    <mitre><id>TA0003</id></mitre>
  </rule>
</group>

FIM 이벤트는 auditd 디코더가 아닌 syscheck 그룹으로 들어오므로 if_group syscheck를 상위 조건으로 쓰며, 그래서 상위 auditd 룰(108000)에 묶지 않은 독립 룰로 작성했습니다.

10. 대응 방법

초기 확인 — 미매칭·미도착 이벤트와 SCA failed 항목을 확인합니다.
범위 확인 — 같은 호스트의 다른 지속성 Alert와 whodata 주체를 확인합니다.
증거 확보 — Alert 원문·FIM diff·SCA 결과를 보존합니다.
차단/조치 — 판정 절차에 따라 대응하고 룰·감사 공백을 보강합니다.
재발 방지 — 회귀 시험과 버전 관리로 탐지 스택을 유지합니다.

11. 핵심 정리

모듈	보는 것
auditd	행위
FIM whodata	결과 + 주체
command	정기 diff
SCA	현재 상태
면접 포인트	"Wazuh는 행위·결과·상태를 각각 받는다 — 키와 룰은 함께 버전 관리"