445. 지속성·재침투 — ELK/SIEM 기반 지속성 탐지와 정탐·오탐 판단

About this offer

시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 45/50편 (전체 445/450) 학습 단계: SOC 탐지 연계 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 444. 지속성·재침투 — Wazuh 기반 지속성·재침투 탐지 395. 방어 회피·흔적 삭제 — ELK/SIEM 기반 방어 회피 탐지와 정탐·오탐 판단(H영역) 1. 개념 지속성 탐지에서 가장 흔한 오탐 원인은 정상 자동화 입니다. 패키지 업데이트는 유닛과 cron을 바꾸고, Ansible은 sudoers와 SSH 키를 배포합니다. SIEM에서는 이런 정상 변경을 근거와 함께 걸러내는 질의와 예외 가 필요합니다. 지속성 대시보드 구성(예) ┌ 패널1: 호스트별 지속성 Alert 수 (class별 색) ├ 패널2: 시간대 분포 (업무 외 강조) ├ 패널3: actor 상위 (구성관리 계정 vs 대화형 사용자) ├ 패널4: 미소유 신규 항목 (persist-diff ADD) └ 패널5: 재침투 통로 (reentry_* 목적지·포트) 대표 오탐 3종 패키지 업데이트 : exe=dnf/apt, 같은 시각 대량 변경 구성관리 배포 : actor=deploy, 여러 호스트 동시 동일 변경 백업·모니터링 : 승인된 cron·유닛, 기준선 반영 누락 핵심: 예외는 "누가·무엇으로"로 좁게 — 경로 전체 예외는 금지 예외를 경로 단위로 걸면(예: /etc/cron.d 전체 제외) 공격자도 그 경로를 그대로 쓸 수 있습니다. 예외는 actor + method + 대상 을 모두 지정해 좁게 만듭니다. 2. 왜 중요한가 오탐이 많으면 관제원이 지속성 Alert를 무시하게 됩니다. 좁은 예외는 정상 자동화를 걸러내면서 공격 경로는 남겨 둡니다. 판정 근거를 질의로 남기면 같은 유형의 판정이 빨라집니다. 3. 핵심 명령어 / 설정 질의 목적 KQL 예 대화형 수정 rule.groups:persistence and not data.audit.exe:(*dnf* or *rpm* or *ansible*) 업무 외 rule.groups:persistence and not hour_of_day:[9 TO 18] 동시 다호스트 rule.id:108200 집계 → 같은 분 다수 호스트 = 배포 서비스 계정 data.audit.uid:(apache or www-data) and rule.groups:persistence 4. 실습 (실습 예시) # 오탐 판정 질의 순서 (분석 방법) # 1) 같은 시각 같은 변경이 여러 호스트에서? → 배포 가능성 # Kibana: rule.id:108200 → Visualize: date_histogram(1m) × terms(agent.name) # 2) 변경 주체가 구성관리 계정? → data.audit.auid:deploy # 3) 변경 도구가 패키지 관리자? → data.audit.exe:(*dnf* or *apt*) # 4) 승인 티켓과 시각 일치? → 변경관리 시스템 조회 # 5) 위 4개 모두 Y → 정상 행위, 기준선 반영 + 좁은 예외 검토 5. 정상 상태 10-02 10:12 rule 108200 × 38 호스트 (exe=/usr/bin/dnf, CHG-1090) 판정: 정상 행위(패키지 업데이트) → 기준선 일괄 갱신 여러 호스트에서 같은 시각 패키지 관리자가 만든 변경은 승인 티켓과 맞으면 정상 행위로 판정하고 기준선을 갱신합니다. 6. 이상 상태 10-08 03:02 rule 108200 × 1 호스트(web01), exe=/usr/bin/systemctl, auid=webadmin 같은 세션: 108080·108140·108180·108260 판정: 정탐 (단일 호스트·대화형·업무 외·다분류) 한 호스트에서만 발생 + 대화형 사용자 → 배포 아님 같은 세션 다분류 지속성 → 설치 단계(정탐) 예외 후보가 될 근거 없음 → 에스컬레이션 7. 로그 분석 (분석 방법) 정탐·오탐 판단 흐름입니다(가상의 예시). [Alert] persistence 그룹 ↓ 1 다호스트 동시? ─예→ 배포 의심 → 2 2 actor·exe = 구성관리·패키지? ─예→ 3 3 티켓 일치? ─예→ 정상 행위 (기준선 갱신) ↓ 어느 단계든 아니오 4 I08 6축 판정 → 정탐/의심 ↓ 5 반복 정상 행위 → 좁은 예외(actor+exe+경로) 예외 범위 평가 경로 전체 위험(공격 경로도 제외) actor+exe+경로 적정 시간 창 한정 배포 창에 한해 허용 예외 룰에도 만료일과 담당자를 기록해 두고, 분기마다 예외가 여전히 필요한지 검토해야 예외가 공격 경로로 굳지 않습니다. 8. SOC 관제 포인트 오탐 상위 룰을 주간으로 집계해 튜닝 대상을 고릅니다. 예외는 좁게, 만료일과 함께 관리합니다. 정상 행위 판정 후 기준선 갱신까지 마쳐야 같은 Alert가 반복되지 않습니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_i,persistence,"> <rule id="108440" level="0"> <if_group>persistence</if_group> <field name="audit.auid">^deploy$</field> <field name="audit.exe" type="pcre2">/ansible-playbook$|/python3 .*ansible</field> <description>구성관리(Ansible) 배포 계정의 지속성 위치 변경(예외 - 만료 2027-03-31)</description> </rule> </group> 레벨 0 예외 룰 예시입니다. 계정과 실행 도구를 함께 지정해 좁게 제외하고, 설명에 만료일을 적어 정기 검토 대상으로 둡니다. 10. 대응 방법 초기 확인 — 다호스트·주체·도구·티켓 순으로 오탐 여부를 확인합니다. 범위 확인 — 정탐이면 같은 세션·호스트의 다른 Alert를 묶습니다. 증거 확보 — 판정 질의와 결과를 티켓에 보존합니다. 차단/조치 — 정상 행위는 기준선 갱신, 반복 오탐은 좁은 예외로 처리합니다. 재발 방지 — 예외 목록을 만료일 기준으로 정기 검토합니다. 11. 핵심 정리 오탐 근거 패키지 업데이트 exe·다호스트·티켓 구성관리 actor·exe·티켓 기준선 누락 승인 작업 원칙 좁은 예외 + 만료일 면접 포인트 "오탐은 정상 자동화에서 온다 — 예외는 경로가 아니라 누가·무엇으로 좁게" 12. 다음 편 예고 다음 편 446. 지속성·재침투 — 지속성 근절과 재침투 차단 검증 에서는 지속성 인벤토리·타임라인을 바탕으로 재생성 장치부터 제거하는 근절 순서, 자격증명·통로 차단, 재부팅 재점검과 감시 기간 검증 방법을 다룹니다. 이전 편: 444. 지속성·재침투 — Wazuh 기반 지속성·재침투 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점