408. 지속성·재침투 — 지속성·재침투 판정 기준

changseop lee·4일 전

시스템 보안 · 취약점

목록 보기
408/450

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

선행 학습

1. 개념

지금까지의 기준선·분류·구분 기준을 하나로 묶어 지속성·재침투 판정 기준을 정리합니다. 판정은 "의심스러운가"가 아니라 근거가 몇 개 축에서 겹치는가로 결정합니다.

지속성·재침투 판정 6축
 ① 기준선  : 기준선 밖 신규 항목인가
 ② 작성자  : 구성관리 외 대화형 사용자인가
 ③ 내용    : 외부 다운로드·인코딩·셸 연결이 있는가
 ④ 위장    : 정상 이름·숨김 경로를 흉내 내는가
 ⑤ 시점    : 침투·권한 상승 직후·업무 외인가
 ⑥ 연계    : 다른 지속성·재침투 이벤트와 겹치는가

핵심: 3축 이상 겹치면 정탐 가능성 높음 → 즉시 조사

축이 많이 겹칠수록 확신이 높아지고, 특히 ⑥ 연계가 있으면 단일 이벤트가 아닌 공격 체인으로 봅니다.

2. 왜 중요한가

  • 판정 기준이 없으면 같은 Alert도 관제원마다 결론이 달라집니다.
  • 축 개수 기반 판정은 에스컬레이션 근거를 객관적으로 설명할 수 있게 합니다.
  • 판정 기록이 쌓이면 오탐 튜닝과 룰 개선의 근거가 됩니다.

3. 핵심 명령어 / 설정

판정조건조치
정탐3축 이상 또는 ③+⑥즉시 에스컬레이션
의심1~2축추가 확인 후 재판정
정상 행위기준선·티켓으로 설명기준선 갱신
오탐룰 조건 오류룰 튜닝

4. 실습 (실습 예시)

# 판정 기록 템플릿 (분석 방법)
cat <<'T'
[Alert] rule=108xxx host= time=
[항목] 위치= 내용 요약=
① 기준선 밖?      Y/N  근거:
② 대화형 작성자?  Y/N  근거: ausearch auid=
③ 외부/인코딩/셸? Y/N  근거:
④ 위장?           Y/N  근거:
⑤ 시점 이상?      Y/N  근거:
⑥ 연계 이벤트?    Y/N  근거: 관련 Alert ID
[판정] 정탐/의심/정상행위/오탐   [조치]
T

5. 정상 상태

Alert 108190 /etc/cron.d/logrotate-extra
① Y ② N(auid=deploy) ③ N ④ N ⑤ N ⑥ N, 티켓 CHG-1088
판정: 정상 행위 → 기준선 갱신

기준선 밖 항목이라도 구성관리 계정이 승인된 변경으로 만들었고 다른 축이 모두 N이면 정상 행위로 닫고 기준선을 갱신합니다.

6. 이상 상태

Alert 108120 /root/.ssh/authorized_keys 키 추가
① Y ② Y(auid=webadmin, sudo -i) ③ N ④ Y(주석 없음) ⑤ Y(권한 상승 4분 후) ⑥ Y(신규 cron 동시 생성)
판정: 정탐 → 에스컬레이션
  • 6축 중 5축 해당 → 정탐 판정
  • 권한 상승 직후 키 추가 + cron 동시 생성 → 다중 지속성 체인
  • 즉시 에스컬레이션하고 다른 위치 전수 점검 시작

7. 로그 분석 (분석 방법)

판정 흐름입니다(가상의 예시).

[Alert 수신]
   ↓
[6축 체크] 각 축 Y/N + 근거 로그
   ↓
 Y ≥ 3 또는 (③ and ⑥) → 정탐 → 에스컬레이션·봉쇄
 Y 1~2                 → 의심 → 추가 수집 후 재판정
 Y 0 + 티켓            → 정상 행위 → 기준선 갱신
 룰 조건 오류          → 오탐 → 룰 튜닝
축주 근거
①②기준선 diff·ausearch
③④파일 내용·이름
⑤⑥타임라인·연관 Alert

근거 없이 Y를 체크하지 않도록 각 축마다 확인한 로그·명령을 함께 적는 것이 판정의 신뢰도를 만듭니다.

8. SOC 관제 포인트

  • 판정 템플릿을 티켓 양식으로 고정해 관제원 간 판정을 일관되게 합니다.
  • 정상 행위로 닫은 항목은 반드시 기준선 갱신까지 마쳐야 같은 Alert가 반복되지 않습니다.
  • "의심"은 보류가 아니라 추가 수집 기한을 정한 상태로 관리합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_i,persistence,">
  <rule id="108070" level="12">
    <if_sid>108000</if_sid>
    <if_matched_group>persistence</if_matched_group>
    <same_field>audit.auid</same_field>
    <timeframe>1800</timeframe>
    <description>동일 사용자 30분 내 복수 지속성 이벤트(판정 축 ⑥ 연계)</description>
    <mitre><id>TA0003</id></mitre>
  </rule>
</group>

판정 축 ⑥(연계)을 자동화한 예시입니다. 같은 auid가 30분 안에 여러 지속성 이벤트를 만들면 단일 이벤트보다 높은 레벨로 올립니다.

10. 대응 방법

  1. 초기 확인 — 6축을 하나씩 확인하고 축마다 근거 로그를 기록합니다.
  2. 범위 확인 — 연계 축이 Y이면 관련 Alert를 묶어 범위를 확정합니다.
  3. 증거 확보 — 판정 기록과 근거 로그를 티켓에 첨부해 보존합니다.
  4. 차단/조치 — 정탐은 봉쇄·근절 절차로, 정상 행위는 기준선 갱신으로 처리합니다.
  5. 재발 방지 — 판정 결과를 룰 튜닝·화이트리스트 개선에 반영합니다.

11. 핵심 정리

판정기준
정탐3축 이상 또는 내용+연계
의심1~2축, 기한 내 재판정
정상 행위티켓·기준선으로 설명
오탐룰 조건 오류
면접 포인트"판정은 인상이 아니라 축의 개수 — 6축 중 3축 이상이면 정탐"

12. 다음 편 예고

다음 편 409. 지속성·재침투 — 백도어 계정 생성 탐지 에서는 useradd·passwd 직접 편집으로 만든 백도어 계정을 계정 생성 로그·FIM·auditd로 탐지하고 정상 계정 발급과 구분하는 방법을 다룹니다.


이전 편: 407. 지속성·재침투 — 정상 자동화와 악성 지속성의 구분
📚 시리즈 전체 보기: 시스템 보안 · 취약점

profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글