448. 지속성·재침투 — 지속성·재침투 탐지 규칙 모음

목록 보기

448/450

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

선행 학습

1. 개념

I영역에서 편마다 작성한 탐지 규칙을 하나의 룰셋으로 정리합니다. 룰 번호는 108000 + (편-1)×10 규칙으로 배정했으므로, 룰 ID만 보고 어느 편에서 다룬 내용인지 바로 찾을 수 있습니다.

I영역 룰셋 구조 (108000~108499)
 108000~108070  기초      : 상위 룰·기준선·분류·판정 연계
 108080~108170  계정·인증  : 백도어 계정·UID 0·휴면·키·sshd·PAM·sudoers·자격증명·CA·세트
 108180~108270  스케줄·부팅: cron·at·service·timer·drop-in·rc.local·셸·udev·preload·다중
 108280~108370  통로·거점  : 리버스·리스너·웹셸·비컨·터널·신뢰·모듈·바이너리·복귀·종합
 108380~108499  분석·SOC   : 인벤토리·diff·타임라인·정규화·상관·FIM·예외·근절·에스컬레이션

감사 키 체계
 persist_{cron,svc,boot,shell,preload,ssh,pam,baseline} · account_persist
 reentry_{net,listen,trust} · module_load · bin_change · exec_web · exec_persist

핵심: 키 → 룰 → MITRE 가 한 줄로 이어져야 유지보수가 된다

룰셋은 문서가 아니라 운영 자산이므로, 감사 규칙 파일·룰 파일·예외 목록·테스트 이벤트를 함께 버전 관리하는 구조로 정리합니다.

2. 왜 중요한가

흩어진 룰을 모아야 중복·충돌·공백을 확인할 수 있습니다.
ID 규칙이 있으면 Alert에서 해당 편의 분석 방법으로 바로 연결됩니다.
면접·포트폴리오에서 탐지 설계 역량을 한 장으로 보여 줄 수 있습니다.

3. 핵심 명령어 / 설정

룰 ID	탐지	레벨	MITRE
108080	passwd 직접 편집(백도어 계정)	12	T1136.001
108090	UID 변경(UID 0)	13	T1098
108110	authorized_keys 변경	12	T1098.004
108130	PAM 모듈·설정 변경	14	T1556.003
108140	visudo 외 sudoers 변경	13	T1548.003
108180·108181	cron 변경·위험 CMD	12·13	T1053.003
108200	systemd 서비스 유닛	12	T1543.002
108210	systemd timer	12	T1053.006
108260	ld.so.preload	15	T1574.006
108280	리버스 셸 재접속	13	T1059.004
108300	웹셸 재침투	14	T1505.003
108320	SSH 역방향·동적 터널	13	T1572
108340	커널 모듈 로드	15	T1547.006
108350	시스템 바이너리 교체	15	T1554

4. 실습 (실습 예시)

# 룰셋 배치·검증 순서 (실습 예시)
# 1) 감사 규칙 배치 및 로드
sudo cp persist.rules /etc/audit/rules.d/ && sudo augenrules --load && sudo auditctl -l | grep -cE 'persist_|reentry_|account_persist'
# 2) 룰 파일 문법 확인 후 매니저 재시작
sudo cp 108000-persistence.xml /var/ossec/etc/rules/ && sudo /var/ossec/bin/wazuh-analysisd -t && sudo systemctl restart wazuh-manager
# 3) 테스트 이벤트 재생 → 기대 룰 ID 확인
sudo /var/ossec/bin/wazuh-logtest < tests/persist_cron.log

5. 정상 상태

auditctl -l: persist·reentry·account 감사 규칙 24개 로드
wazuh-analysisd -t: 문법 오류 없음
테스트 이벤트 30종: 기대 룰 ID 30/30 매칭

감사 규칙이 모두 로드되고, 룰 문법 검사를 통과하며, 테스트 이벤트가 모두 기대한 룰에 매칭되는 상태가 정상입니다.

6. 이상 상태

테스트 이벤트 30종: 27/30 매칭
 - persist_udev → 미매칭 (감사 키는 persist_boot로 통일되어 있음)
 - 108311 비컨 빈도 룰 → 상위 108310 레벨 0으로 덮어씀
 - 108440 예외 룰 → actor 조건 오타로 모든 cron Alert 억제

키 이름 불일치 → 탐지 공백
상위·하위 룰 레벨 충돌 → 상관 룰 무력화
예외 룰 조건 오류 → 정상·악성 모두 억제(가장 위험)

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

룰셋 유지보수 흐름입니다(가상의 예시).

[변경 요청] 신규 기법·오탐 튜닝
   ↓
[수정] 감사 키 · 룰 · 예외 · 테스트 이벤트 함께 수정
   ↓
[검증] analysisd -t → logtest 전체 회귀 시험
   ↓
[배포] 스테이징 → 운영, 변경 이력 기록
   ↓
[모니터링] 룰별 발생 수 급감·급증 감시(조용히 멈춘 룰 탐지)

점검	실패 시 위험
키-룰 일치	탐지 공백
상·하위 레벨	상관 무력화
예외 조건	전면 억제

가장 위험한 실패는 예외 룰 오류입니다. Alert가 "없어서 조용한" 상태와 "억제되어 조용한" 상태를 구분하려면 룰별 발생 수 추이를 감시해야 합니다.

8. SOC 관제 포인트

룰 ID·감사 키·MITRE 매핑표를 대시보드 범례로 씁니다.
룰 변경 시 전체 회귀 시험을 필수 절차로 둡니다.
일주일 이상 0건인 룰은 정상 여부를 점검합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_i,persistence,">
  <rule id="108470" level="3">
    <if_sid>108000</if_sid>
    <field name="audit.key" type="pcre2">^(persist_|account_persist|reentry_|module_load|bin_change|exec_web|exec_persist)</field>
    <description>I영역 지속성·재침투 감사 이벤트(상위 집계 룰)</description>
    <mitre><id>TA0003</id></mitre>
  </rule>
</group>

I영역의 모든 감사 키를 받는 상위 집계 룰입니다. 하위 룰이 놓친 키도 레벨 3으로 남겨 두면 "어떤 룰에도 안 걸린 지속성 이벤트"를 찾는 공백 점검에 쓸 수 있습니다.

10. 대응 방법

초기 확인 — 룰별 발생 수와 미매칭 이벤트를 확인합니다.
범위 확인 — 키-룰 불일치·레벨 충돌·예외 오류를 확인합니다.
증거 확보 — 룰셋·감사 규칙·테스트 결과를 버전과 함께 보존합니다.
차단/조치 — 오류를 수정하고 전체 회귀 시험 후 배포합니다.
재발 방지 — 변경 이력과 0건 룰 점검을 정기적으로 운영합니다.

11. 핵심 정리

대역	내용
108000~070	기초·판정
108080~170	계정·인증
108180~270	스케줄·부팅
108280~370	통로·거점
108380~	분석·SOC
면접 포인트	"룰셋은 문서가 아니라 운영 자산 — 키·룰·예외·테스트를 함께 관리한다"