446. 지속성·재침투 — 지속성 근절과 재침투 차단 검증

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

시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 46/50편 (전체 446/450) 학습 단계: SOC 탐지 연계 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 445. 지속성·재침투 — ELK/SIEM 기반 지속성 탐지와 정탐·오탐 판단 396. 방어 회피·흔적 삭제 — 중앙 로그 수집으로 로컬 삭제 무력화(H영역) 1. 개념 근절(eradication)은 "보이는 것을 지우는 일"이 아니라 "다시 돌아올 수 없게 만드는 일" 입니다. 그래서 순서가 중요하고, 끝났다는 것을 검증 할 수 있어야 합니다. 근절 순서 (재생성 관계 기준) 0. 증거 확보 (인벤토리·이미지·로그) ← 지우기 전에 1. 통로 차단 : C2·터널 목적지 차단, 리스너 포트 차단 2. 재생성 장치 : cron·at·timer 중지·제거 3. 기동 장치 : 서비스·drop-in·rc.local·udev·preload 비활성화·제거 4. 실행 대상 : 공통 바이너리·스크립트 격리 5. 접근 수단 : 키·CA·PAM·sudoers·백도어 계정·비밀번호 정리 6. 최초 경로 : 취약점 패치·웹셸 제거 7. 재부팅 → 인벤토리 재수집 → 전후 diff 8. 감시 기간 : IOC·비컨·재접속 0건 확인 핵심: 통로 → 재생성 → 기동 → 실행 → 접근 → 최초 경로 → 검증 깊은 거점(커널 모듈·바이너리 교체, I35·I36)이 확인되면 이 순서 대신 재설치 가 원칙입니다. 그때도 접근 수단 정리와 최초 경로 패치는 똑같이 필요합니다. 2. 왜 중요한가 순서를 지키지 않으면 지운 지속성이 다른 장치에 의해 다시 생깁니다. 통로를 먼저 막지 않으면 근절 중에 공격자가 반응(삭제·확산)할 수 있습니다. 전후 인벤토리 diff와 감시 기간이 있어야 근절 완료를 증명할 수 있습니다. 3. 핵심 명령어 / 설정 단계 대표 조치 검증 통로 방화벽 차단 DROP 로그 재생성 crontab -r -u , atrm , systemctl disable --now *.timer atq·list-timers 기동 systemctl disable --now , preload 제거 systemd-delta 실행 대상 격리 디렉터리 이동·해시 기록 재생성 여부 접근 키·계정·sudoers 정리, 비밀번호 교체 인벤토리 검증 재부팅·재수집·감시 IOC 0건 4. 실습 (실습 예시) # 근절 검증 (분석 방법) # 1) 근절 직후·재부팅 후 인벤토리 재수집 sudo /usr/local/sbin/persist-inventory > /root/ir/inv_after.tsv diff <(cut -f1-4 /root/ir/inv_before.tsv | sort) <(cut -f1-4 /root/ir/inv_after.tsv | sort) # 2) 격리 대상이 다시 생겼는지 sudo find / -xdev -path '*/.x/*' 2>/dev/null; ls /etc/ld.so.preload 2>/dev/null # 3) 감시 기간 IOC 재출현 확인 (I37 IOC 목록) sudo journalctl -k --since "-1d" | grep -c 'DST=198.51.100.7' 5. 정상 상태 inv_before 대비 inv_after: 미소유 지속성 9건 → 0건 재부팅 후 재생성: 없음 감시 14일: IOC·비컨·재접속 0건 → 근절 완료 근절 후와 재부팅 후 인벤토리에서 판정된 항목이 모두 사라지고, 감시 기간 동안 IOC가 재출현하지 않으면 근절 완료로 판단합니다. 6. 이상 상태 재부팅 후: /usr/lib/.x/agent 재생성, /etc/ld.so.preload 재생성 원인: udev 규칙(75-net-tune.rules) 미제거 → 부팅 시 재설치 스크립트 실행 재부팅 후 재생성 → 기동 장치 하나가 남음 udev가 근절 목록에서 누락 → 인벤토리 범위 공백 재근절 후 감시 기간을 처음부터 다시 시작 7. 로그 분석 (분석 방법) 근절 검증 흐름입니다(가상의 예시). [근절 실행] 순서대로 · 단계별 기록 ↓ [재수집] 직후 인벤토리 → diff ↓ [재부팅] 부팅 트리거 잔존 확인 → 재수집 ↓ [감시 기간] IOC·비컨·재접속·재생성 0건 ├─ 0건 → 근절 완료 보고 └─ 발생 → 원인(누락 항목) → 재근절 → 감시 재시작 검증 시점 확인 근절 직후 목록 제거 재부팅 후 부팅·이벤트 트리거 잔존 감시 기간 재생성·재침투 재부팅 검증을 생략하면 부팅·이벤트 트리거(rc.local·udev·generator)가 남아 있어도 알 수 없습니다. 운영상 재부팅이 어렵다면 그 사실과 위험을 보고서에 명시합니다. 8. SOC 관제 포인트 근절 단계마다 수행자·시각·명령을 기록합니다. 감시 기간 동안 해당 호스트 Alert 레벨을 한 단계 올려 운영합니다. 근절 완료 기준(인벤토리 0건·감시 0건)을 사전에 합의해 둡니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_i,persistence,"> <rule id="108450" level="14"> <if_group>persistence</if_group> <list field="agent.name" lookup="match_key">etc/lists/ir-eradicated-hosts</list> <description>근절 감시 기간 호스트에서 지속성 이벤트 재발생(근절 실패 의심)</description> <mitre><id>TA0003</id></mitre> </rule> </group> 근절을 마친 호스트를 CDB 리스트로 관리하고, 감시 기간 동안 그 호스트에서 지속성 이벤트가 다시 나오면 높은 레벨로 경보합니다. 감시 기간이 끝나면 목록에서 제외합니다. 10. 대응 방법 초기 확인 — 인벤토리·타임라인으로 근절 대상과 순서를 확정합니다. 범위 확인 — 통로·재생성·기동·실행·접근·최초 경로 순으로 범위를 정리합니다. 증거 확보 — 근절 전 증거를 확보하고 단계별 기록을 남깁니다. 차단/조치 — 순서대로 근절하고 재부팅 후 재점검합니다. 재발 방지 — 감시 기간 동안 재발 0건을 확인한 뒤 근절 완료를 보고합니다. 11. 핵심 정리 원칙 내용 먼저 증거 확보 → 통로 차단 순서 재생성 → 기동 → 실행 → 접근 검증 재부팅 재수집·감시 기간 예외 깊은 거점은 재설치 면접 포인트 "근절은 지우는 게 아니라 못 돌아오게 하는 것 — 순서와 검증이 핵심" 12. 다음 편 예고 다음 편 447. 지속성·재침투 — 지속성·재침투 Alert 대응 절차 에서는 지속성·재침투 Alert 수신부터 분류·조사·판정·봉쇄·근절·보고까지 관제원이 따르는 표준 플레이북과 단계별 체크리스트를 다룹니다. 이전 편: 445. 지속성·재침투 — ELK/SIEM 기반 지속성 탐지와 정탐·오탐 판단 📚 시리즈 전체 보기: 시스템 보안 · 취약점