443. 지속성·재침투 — 지속성·재침투 이벤트 상관분석

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

시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 43/50편 (전체 443/450) 학습 단계: SOC 탐지 연계 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 442. 지속성·재침투 — 지속성·재침투 로그의 정규화와 수집 393. 방어 회피·흔적 삭제 — 변조 전후 비교와 무결성 검증(H영역) 1. 개념 지속성 이벤트 하나는 정상 작업일 수도 있습니다. 하지만 같은 세션에서 계정 생성 → sudoers 변경 → cron 등록 → 외부 연결 이 이어지면 공격 체인입니다. 상관분석은 이렇게 약한 신호를 묶어 강한 결론 을 만드는 작업입니다. 상관 축 4가지 1 세션 : audit.ses 같음 → 같은 로그인에서 한 일 2 주체 : actor(auid) 같음 → 같은 사람이 한 일 3 실행 대상: 같은 바이너리 해시·경로 → 여러 트리거가 같은 악성코드 기동 4 호스트·IOC: 같은 C2·키 지문이 여러 호스트에 → 확산 ↓ 체인 예: 침투(웹) → 상승(sudo) → 지속성(cron·유닛) → 통로(C2) 핵심: 축이 겹칠수록 확신 상승 — 특히 3은 다중 트리거를 하나로 묶는다 I08 판정 기준의 6 연계 축을 SIEM 규칙과 질의로 구현하는 것이 이번 편의 목표입니다. 2. 왜 중요한가 단일 이벤트 경보는 오탐이 많지만 상관 결과는 확신도가 높습니다. 여러 트리거에 흩어진 지속성을 하나의 인시던트로 묶을 수 있습니다. IOC 상관은 다른 호스트로의 확산을 조기에 보여 줍니다. 3. 핵심 명령어 / 설정 상관 조건 결론 세션 ses 같음 + 지속성 2종 이상 설치 단계 주체 auid 같음 + 상승 후 30분 내 지속성 상승→지속성 체인 실행 대상 같은 exe 경로를 여러 트리거가 참조 다중 트리거 IOC 같은 키 지문·C2가 2개 호스트 이상 확산 4. 실습 (실습 예시) # Elasticsearch 집계 질의 예: 세션별 지속성 분류 수 (분석 방법) cat <<'Q' GET wazuh-alerts-*/_search { "size": 0, "query": { "range": { "@timestamp": { "gte": "now-24h" } } }, "aggs": { "by_ses": { "terms": { "field": "data.audit.session", "size": 20 }, "aggs": { "classes": { "cardinality": { "field": "persist.class" } }, "multi": { "bucket_selector": { "buckets_path": { "c": "classes" }, "script": "params.c >= 2" } } } } } } Q 5. 정상 상태 세션별 지속성 분류 수: 최대 1 (Ansible 배포 세션, schedule만) IOC 공유 호스트: 없음 한 세션에서 한 분류의 승인된 변경만 있고, 여러 호스트가 같은 IOC를 공유하지 않는 상태가 정상입니다. 6. 이상 상태 ses=412 actor=webadmin classes=5 (account·auth·schedule·service·boot) exe=/usr/lib/.x/agent ← cron·dbus-helper.service·udev·rc.local 4개 트리거가 참조 키 지문 SHA256:Qm3... ← web01·db01 두 호스트 로그인 한 세션에서 5개 분류 지속성 → 설치 단계 확정 같은 바이너리를 4개 트리거가 기동 → 하나의 악성코드, 다중 지속성 같은 키 지문이 db01에도 → 확산, 범위 확대 필요 7. 로그 분석 (분석 방법) 상관분석 절차입니다(가상의 예시). [정규화 이벤트] ↓ 1 세션 상관 → 설치 단계 묶음 2 주체 상관 → 상승 이후 지속성 체인 3 실행 대상 상관 → 트리거 ↔ 악성코드 매핑 4 IOC 상관 → 호스트 간 확산 ↓ [인시던트] 하나의 체인 + 영향 호스트 목록 상관 축 대표 산출 세션 설치 단계 주체 행위자 전체 행동 실행 대상 다중 트리거 지도 IOC 확산 범위 3 실행 대상 상관은 근절에도 직접 쓰입니다. 바이너리 하나를 기동하는 모든 트리거를 찾아야 그 바이너리가 다시 살아나지 않습니다. 8. SOC 관제 포인트 세션·주체 상관 룰은 실시간으로, 실행 대상·IOC 상관은 정기 질의로 운영합니다. 상관 결과로 생성된 인시던트에 원본 Alert를 모두 연결합니다. IOC 상관에서 새 호스트가 나오면 즉시 해당 호스트 인벤토리를 수집합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_i,persistence,"> <rule id="108420" level="14"> <if_matched_group>persistence</if_matched_group> <same_field>audit.exe</same_field> <different_field>audit.key</different_field> <timeframe>86400</timeframe> <description>같은 실행 파일을 서로 다른 지속성 위치가 참조(다중 트리거 악성코드)</description> <mitre><id>TA0003</id></mitre> </rule> </group> 실행 대상 상관(3)의 예시입니다. 실제로는 지속성 파일 내용 속 실행 경로를 추출해야 하므로, 정규화 단계에서 persist.exec_target 필드를 만들어 기준 필드로 쓰는 편이 정확합니다. 10. 대응 방법 초기 확인 — 상관 결과의 체인과 연결된 Alert를 확인합니다. 범위 확인 — 실행 대상·IOC 상관으로 다중 트리거와 확산 호스트를 확인합니다. 증거 확보 — 상관 근거(질의·결과)와 원본 Alert를 보존합니다. 차단/조치 — 체인 전체를 하나의 근절 단위로 처리하고 확산 호스트를 함께 대응합니다. 재발 방지 — 상관 룰·질의를 정기 검증하고 개선합니다. 11. 핵심 정리 축 기준 세션 audit.ses 주체 auid 실행 대상 exe·해시 IOC 키 지문·C2 면접 포인트 "약한 신호를 묶어 강한 결론으로 — 같은 바이너리를 부르는 트리거는 하나의 사건" 12. 다음 편 예고 다음 편 444. 지속성·재침투 — Wazuh 기반 지속성·재침투 탐지 에서는 auditd 감사 키·FIM(whodata)·SCA·명령 모니터링·커스텀 룰(108000번대)을 묶어 Wazuh로 지속성·재침투를 탐지하는 구성을 다룹니다. 이전 편: 442. 지속성·재침투 — 지속성·재침투 로그의 정규화와 수집 📚 시리즈 전체 보기: 시스템 보안 · 취약점