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

Об этом предложении

시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 48/50편 (전체 448/450) 학습 단계: SOC 탐지 연계 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 447. 지속성·재침투 — 지속성·재침투 Alert 대응 절차 398. 방어 회피·흔적 삭제 — 방어 회피·흔적 삭제 탐지 규칙 모음(H영역) 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 면접 포인트 "룰셋은 문서가 아니라 운영 자산 — 키·룰·예외·테스트를 함께 관리한다" 12. 다음 편 예고 다음 편 449. 지속성·재침투 — 실전 시나리오 — 침투부터 지속성 설치·재침투까지 에서는 웹 침투 → 권한 상승 → 다중 지속성 설치 → 1차 근절 → 재침투 → 원인 분석 → 재근절까지의 가상 사고를 관제 화면·로그 흔적 중심으로 재구성합니다. 이전 편: 447. 지속성·재침투 — 지속성·재침투 Alert 대응 절차 📚 시리즈 전체 보기: 시스템 보안 · 취약점