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

목록 보기

443/450

시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 43/50편 (전체 443/450)
학습 단계: SOC 탐지 연계
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

지속성 이벤트 하나는 정상 작업일 수도 있습니다. 하지만 같은 세션에서 계정 생성 → sudoers 변경 → cron 등록 → 외부 연결이 이어지면 공격 체인입니다. 상관분석은 이렇게 약한 신호를 묶어 강한 결론을 만드는 작업입니다.

상관 축 4가지
 ① 세션    : audit.ses 같음 → 같은 로그인에서 한 일
 ② 주체    : actor(auid) 같음 → 같은 사람이 한 일
 ③ 실행 대상: 같은 바이너리 해시·경로 → 여러 트리거가 같은 악성코드 기동
 ④ 호스트·IOC: 같은 C2·키 지문이 여러 호스트에 → 확산
   ↓
 체인 예: 침투(웹) → 상승(sudo) → 지속성(cron·유닛) → 통로(C2)

핵심: 축이 겹칠수록 확신 상승 — 특히 ③은 다중 트리거를 하나로 묶는다

I08 판정 기준의 ⑥ 연계 축을 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. 로그 분석 (분석 방법)

상관분석 절차입니다(가상의 예시).

[정규화 이벤트]
   ↓
① 세션 상관 → 설치 단계 묶음
② 주체 상관 → 상승 이후 지속성 체인
③ 실행 대상 상관 → 트리거 ↔ 악성코드 매핑
④ IOC 상관 → 호스트 간 확산
   ↓
[인시던트] 하나의 체인 + 영향 호스트 목록

상관 축	대표 산출
세션	설치 단계
주체	행위자 전체 행동
실행 대상	다중 트리거 지도
IOC	확산 범위

③ 실행 대상 상관은 근절에도 직접 쓰입니다. 바이너리 하나를 기동하는 모든 트리거를 찾아야 그 바이너리가 다시 살아나지 않습니다.

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>

실행 대상 상관(③)의 예시입니다. 실제로는 지속성 파일 내용 속 실행 경로를 추출해야 하므로, 정규화 단계에서 persist.exec_target 필드를 만들어 기준 필드로 쓰는 편이 정확합니다.

10. 대응 방법

초기 확인 — 상관 결과의 체인과 연결된 Alert를 확인합니다.
범위 확인 — 실행 대상·IOC 상관으로 다중 트리거와 확산 호스트를 확인합니다.
증거 확보 — 상관 근거(질의·결과)와 원본 Alert를 보존합니다.
차단/조치 — 체인 전체를 하나의 근절 단위로 처리하고 확산 호스트를 함께 대응합니다.
재발 방지 — 상관 룰·질의를 정기 검증하고 개선합니다.

11. 핵심 정리

축	기준
세션	audit.ses
주체	auid
실행 대상	exe·해시
IOC	키 지문·C2
면접 포인트	"약한 신호를 묶어 강한 결론으로 — 같은 바이너리를 부르는 트리거는 하나의 사건"