449. 지속성·재침투 — 실전 시나리오 — 침투부터 지속성 설치·재침투까지

About this offer

시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 49/50편 (전체 449/450) 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 448. 지속성·재침투 — 지속성·재침투 탐지 규칙 모음 399. 방어 회피·흔적 삭제 — 실전 시나리오 — 침투 은폐부터 흔적 삭제까지(H영역) 1. 개념 I영역의 내용을 하나의 가상 사고 로 엮어 봅니다. 공격 명령이 아니라 관제원이 보게 되는 Alert와 로그 흔적 중심으로, 1차 근절이 왜 실패했고 어떻게 바로잡았는지까지 따라갑니다. 시나리오 개요 (가상 환경: web01 Rocky 9, db01, Wazuh/ELK) D0 02:41 웹 업로드 취약점으로 웹셸 업로드 (침투) D0 02:49 webadmin 계정으로 sudo -i (상승, D영역) D0 02:51~03:12 지속성 설치 (계정·키·sudoers·cron·유닛·preload·udev·터널) D0 03:15 Alert 다발 → L2 에스컬레이션 D1 1차 근절 (udev·휴면 계정 누락) D6~D9 재접속 시도·휴면 계정 재로그인 → 재침투 확인 D10 원인 분석 → 재근절 → D24 감시 종료 핵심: 근절 실패의 원인은 "인벤토리 범위의 빈칸" 실제 사고에서도 1차 근절이 완벽한 경우는 드뭅니다. 중요한 것은 재침투를 빨리 알아차리고, 원인을 절차 개선으로 연결 하는 것입니다. 2. 왜 중요한가 개별 기법이 실제로는 한 번에, 서로를 되살리는 구조로 설치됨을 보여 줍니다. 근절 검증과 감시 기간이 왜 필요한지 구체적으로 확인할 수 있습니다. 면접에서 "지속성 대응 경험"을 구조적으로 설명하는 예시가 됩니다. 3. 핵심 명령어 / 설정 시각 관제 화면(Alert) 의미 02:43 108300 웹서버 → 셸 웹셸 사용 02:51 108080 passwd 직접 편집 백도어 계정 02:54 108110 authorized_keys 백도어 키 02:57 108140 sudoers.d 생성 권한 지속성 03:00 108180 apache crontab 재생성 장치 03:02 108200 dbus-helper.service 서비스 지속성 03:04 108260 ld.so.preload 전역 주입 03:12 108320 ssh -R 터널 재침투 통로 03:15 108170·108460 상관 지속성 세트·즉시 에스컬레이션 4. 실습 (실습 예시) # 시나리오 분석에 쓴 확인 명령 (분석 방법) sudo ausearch -ts 10/08/2026 02:40:00 -te 10/08/2026 03:20:00 -k persist_cron -k persist_svc -k persist_preload -k account_persist -i | grep -E 'auid=|exe=|name=' | head -40 sudo /usr/local/sbin/persist-inventory | grep -P '\t미소유\t' sudo ss -tnp | grep -E 'ssh|bash' # 재침투 후 원인 분석 sudo grep 'Accepted' /var/log/secure | grep -E 'oldsvc|203\.0\.113\.' sudo grep -rl 'RUN+=' /etc/udev/rules.d/ 5. 정상 상태 (사고 이전 web01 기준선) 미소유 지속성 0, LISTEN 22·443, 셸 외부 연결 없음 사고 이전 web01은 기준선과 일치하는 상태였고, 이것이 이후 모든 diff의 비교 기준이 되었습니다. 6. 이상 상태 [1차 근절 후 D6] DROP DST=198.51.100.7 DPT=443 5분 간격 재개 [D9] Accepted password for oldsvc from 203.0.113.80 [D9] /usr/lib/.x/agent 재생성 (ppid=systemd-udevd), /etc/ld.so.preload 재생성 1차 근절 후 비컨 재개 → 기동 장치 잔존 휴면 계정 oldsvc로 재로그인 → 재활성화 계정 미정리 udev가 agent·preload를 되살림 → 인벤토리에 udev 경로 누락 7. 로그 분석 (분석 방법) 사고 전체 흐름입니다(가상의 예시). [침투] 웹셸(02:41) ↓ [상승] sudo -i(02:49) ↓ [지속성 설치 23분] 계정: sysadm·oldsvc 재활성화 / 인증: 키 / 권한: sudoers.d 스케줄: apache cron / 서비스: dbus-helper / 실행: preload / 이벤트: udev 통로: ssh -R 터널 ↓ [1차 근절 D1] udev·oldsvc 누락 ↓ [재침투 D6~D9] 비컨 재개 · oldsvc 로그인 · agent 재생성 ↓ [원인 분석 D10] 인벤토리 범위에 udev·휴면 계정 상태 없음 ↓ [재근절 + 개선] 인벤토리 항목 추가 → 재부팅 검증 → 감시 14일 0건(D24) 교훈 개선 udev 누락 인벤토리에 udev·generator 추가 휴면 계정 누락 계정 "상태 변화"를 인벤토리에 포함 재부팅 검증 생략 근절 절차에 필수화 db01에서도 같은 키 지문 로그인이 있었으므로 db01 인벤토리를 수집했고, 키 1건과 cron 1건을 추가로 근절했습니다. 범위 산정에는 I34·I43의 상관 결과가 결정적이었습니다. 8. SOC 관제 포인트 여러 지속성 Alert가 짧은 시간에 몰리면 개별 처리보다 인시던트 병합을 먼저 합니다. 1차 근절 후 감시 기간에 비컨·재접속을 최우선 지표로 봅니다. 재침투 원인은 개인 실수가 아니라 절차의 빈칸으로 기록하고 개선합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_i,persistence,"> <rule id="108480" level="15"> <if_matched_sid>108360</if_matched_sid> <same_field>agent.id</same_field> <timeframe>1209600</timeframe> <description>근절 후 14일 내 IOC 재출현 반복(재근절·범위 재산정 필요)</description> <mitre><id>TA0003</id></mitre> </rule> </group> I37의 IOC 재출현 룰(108360)이 감시 기간 안에 같은 호스트에서 다시 발생하면 근절 실패로 보고 최고 레벨로 올리는 시나리오용 상관 예시입니다. 10. 대응 방법 초기 확인 — Alert 다발을 하나의 인시던트로 병합하고 6축 판정으로 정탐을 확정합니다. 범위 확인 — 상관·인벤토리로 web01·db01 범위를 확정합니다. 증거 확보 — 인벤토리·타임라인·로그를 원격 보존합니다. 차단/조치 — I46 순서로 근절하고, 재침투 후 누락 항목을 포함해 재근절·재부팅 검증합니다. 재발 방지 — 인벤토리 범위·근절 절차를 개정하고 감시 기간 0건을 확인한 뒤 종료합니다. 11. 핵심 정리 단계 핵심 장면 설치 23분, 8개 분류 탐지 상관 룰로 즉시 에스컬레이션 실패 udev·휴면 계정 누락 개선 인벤토리 범위·재부팅 검증 면접 포인트 "1차 근절은 자주 실패한다 — 빨리 알아차리고 빈칸을 절차로 메우는 것이 실력" 12. 다음 편 예고 다음 편 450. 지속성·재침투 — 지속성·재침투 징후 종합 정리 에서는 I영역 「지속성 · 재침투 징후」 50편을 개념·탐지 위치·판정·Wazuh/ELK·근절·검증으로 종합하고, 「시스템 보안 · 취약점」 450편 전체 흐름을 정리합니다. 이전 편: 448. 지속성·재침투 — 지속성·재침투 탐지 규칙 모음 📚 시리즈 전체 보기: 시스템 보안 · 취약점