시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 49/50편 (전체 449/450)
학습 단계: 실전 시나리오·종합
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.
선행 학습
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. 지속성·재침투 — 지속성·재침투 탐지 규칙 모음
📚 시리즈 전체 보기: 시스템 보안 · 취약점
