시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 50/50편 (전체 150/450) 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 149. Linux 정보 수집 — 실전 시나리오
• 101. OS 정보 수집 흔적 식별
• 150. Linux 시스템 침해사고 종합 분석(linsec)

1. 개념

C영역 50편은 "침입 후 정찰(reconnaissance)" 을 탐지·분석하는 체계입니다. 공격자가 시스템·네트워크·계정·프로세스·파일·로그를 조회하는 흔적을, 정상 관리와 구분해 SOC에서 탐지하는 방법을 다뤘습니다.

[Linux 정보 수집 정찰 탐지 체계]
 정찰 유형 식별(C01~45)
   ↓
 정상 기준선 대비(C10·20·30·40·45)
   ↓
 세션 상관분석(C46)
   ↓
 Wazuh/ELK 탐지(C47·48)
   ↓
 정탐/오탐 판단(C48)
   ↓
 Incident Response(C49)

2. 왜 중요한가

• 정찰은 공격의 초기 단계라, 탐지하면 권한 상승(D)·탈취(E)·지속성(F) 이전에 대응할 수 있습니다.
• 정찰 명령은 정상 관리와 같아, 세션 상관·기준선이 탐지의 핵심입니다.
• C영역은 A(설정)·B(계정) 영역과 함께, 공격 흐름의 "정찰" 축을 담당합니다.

3. 핵심 명령어 / 설정

정보 수집 종합 정리표

4. 실습 (실습 예시)

# 정찰 탐지 체계 점검 (분석 방법)
# 1) recon 감사 규칙 적재 여부
sudo auditctl -l | grep -c recon_
# 2) Wazuh recon 룰 활성 여부
sudo grep -c '102[0-9]\{3\}' /var/ossec/etc/rules/*.xml 2>/dev/null
# 3) 최근 정찰 상관 Alert
# Kibana: rule.id:102450 or rule.id:102470 (최근 7일)

5. 정상 상태

[정찰 탐지 체계 — 실습 예시 점검]
auditd recon 규칙   : 적재됨
Wazuh 102000 룰     : 활성, wazuh-logtest 검증 완료
세션 상관(102450)   : 동작 확인
원격 로그 전송      : 구성(A영역 29편) — 로컬 변조 대비
→ 정찰 탐지 운영 가능

6. 이상 상태

[탐지 공백 — 실습 예시]
auditd recon 규칙   : 미적재 → 정찰 조회가 기록되지 않음
-p r 규칙 폭증      : 튜닝 안 됨 → Alert 피로로 사실상 미탐
원격 전송 없음      : 로컬 로그 삭제 시 정찰 흔적 소실(C41~43)
→ 보완 전까지 정찰 탐지 불가

특히 auditd recon 규칙 미적재·원격 전송 없음은 정찰을 탐지도 보존도 못 하게 하므로 우선 보완 대상입니다.

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

C영역을 A·B영역과 합친 공격 흐름 전체입니다(가상의 예시).

A영역(설정)   하드닝 상태·변경     ┐
B영역(계정)   로그인·인증·탈취      ├─ 침입·기반
C영역(정찰)   정보 수집(이 영역)    ┘
   ↓
D영역(권한)   권한 변경 이상 징후   ← 다음
E~I영역       탈취·프로세스·로그변조·확산·무결성

정찰(C)은 침입(B) 후, 권한 상승(D) 전의 연결 고리

8. SOC 관제 포인트

• 정찰 탐지는 세션 상관 + 기준선 + 원격 로그 보존을 축으로 운영합니다.
• auditd recon 규칙·Wazuh 102000 룰·세션 상관이 모두 있어야 정찰을 탐지·보존합니다.
• 정찰 탐지 시점이 D·E·F영역 이전의 조기 대응 기회입니다.

9. 탐지 규칙

C영역 탐지 체계를 한 장으로 정리하면 다음과 같습니다.

       [수집]                    [탐지]                      [대응]
 auditd recon_*(C01~45)    세션 상관·Wazuh·ELK(C46~48)    판단(C48)→IR(C49)
        ↓                          ↓                          ↑
   원격 전송(A영역 29) ── 로컬 변조 대비 ──→ 대시보드 ────────┘
        ↑                                                      │
        └────── 재발 방지: 기준선·룰·예외 갱신 ←───────────────┘

다음 D영역 「권한 변경 이상 징후」(151~200) 에서는, 정찰(C27·C28)로 파악한 권한 상승 경로를 공격자가 실제로 실행하는 단계 — chmod/chown·SUID·setuid·sudoers 변경 등 권한 변경의 이상 징후를 탐지합니다. C영역이 "상승 경로를 찾는 정찰"이라면, D영역은 "그 경로로 권한을 바꾸는 행위"입니다.

10. 대응 방법

1. 초기 확인 — 정찰 탐지 체계(recon 규칙·Wazuh 룰·세션 상관·원격 전송)의 적재·동작을 점검합니다.
2. 범위 확인 — 정찰 Alert의 다음 단계(D·E·F) 전개와 다른 서버 동일 IOC를 확인합니다.
3. 증거 확보 — 정찰 범위·IOC·타임라인을 사고 보고로 정리합니다.
4. 차단/조치 — 정탐은 침해 대응(세션·계정·IP), 공백은 체계 보완을 진행합니다.
5. 재발 방지 — C영역 탐지 체계를 A·B영역과 통합 운영합니다.

11. 핵심 정리

12. 다음 편 예고

C영역 「Linux 정보 노출 및 수집」 50편을 마칩니다. 다음은 D영역 151. 권한 변경 이상 징후 — chmod/chown 기반 권한 변경 개요 로, 정찰로 찾은 상승 경로를 실제 실행하는 권한 변경 탐지로 이어집니다.

이전 편: 149. Linux 정보 수집 — 실전 시나리오 — 로그인부터 정찰·SIEM 탐지까지
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 49/50편 (전체 149/450) 학습 단계: 실전 시나리오·종합 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 146. Linux 정보 수집 — 이벤트 상관분석
• 049. 하드닝 해제 후 침해 시도 타임라인(A영역)
• 049. brute-force부터 계정 탈취·권한 상승까지(B영역)

1. 개념

이 편은 가상의 실습 시나리오입니다. B영역에서 탈취된 세션(devops, 192.168.56.77, ses=12)이 로그인 직후 수행하는 정찰 전 과정을, 공격 명령이 아니라 관제 화면과 로그에 남는 흔적 중심으로 재구성합니다.

정찰 시나리오 (방어자 관점)
 로그인(B영역 74편 돌파)
   ↓
 시스템 정보 확인 (C01~10)
   ↓
 네트워크 정보 확인 (C11~20)
   ↓
 계정/권한 정보 확인 (C21~30)
   ↓
 프로세스/서비스 확인 (C31~40)
   ↓
 중요 파일 존재 확인 (C38·39)
   ↓
 관련 로그 발생 → SIEM 탐지 → SOC 분석

A영역 49편(설정 변경)·B영역 49편(계정 탈취) 시나리오에 이어, 이 편은 정찰 관점으로 같은 사건을 봅니다.

2. 왜 중요한가

• 정찰 단계는 공격의 초기라, 여기서 SIEM이 탐지하면 권한 상승·탈취·지속성(D·E·F영역) 이전에 대응할 수 있습니다.
• 관제원은 공격 명령을 재현할 필요 없이, 어떤 흔적이 어떤 순서로 남는가를 알면 정찰을 탐지·분석할 수 있습니다.
• 이 시나리오는 C영역 전체(C01~48)의 종합 적용입니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 정찰 시나리오 재구성 (분석 방법) — 세션 타임라인
SES=12
sudo ausearch --session $SES -i 2>/dev/null | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}.*key="recon_[^"]+"' | sed -E 's/.*(recon_[a-z]+)".*/\1/' | sort | uniq -c
# SIEM: 세션 12 정찰 타임라인
# Kibana: data.audit.session:"12" and rule.groups:"recon" → 시간순

5. 정상 상태

정상 로그인 후에는 이런 정찰 흐름이 나타나지 않습니다.

09:12 로그인(admin1, 관리망, publickey)
09:13 systemctl status httpd  (단일 작업)
 → recon 상관 Alert 없음 (정상)

6. 이상 상태

정찰 시나리오 타임라인 (가상, 2026-10-02)

시각      흔적                                      영역/탐지
02:10:44  Accepted password devops 192.168.56.77    B영역 74(돌파)
02:11:40  uname·os-release·cpuinfo (recon_sysinfo)  C01~10 / 102000
02:13:00  ip addr/route/neigh·ss (recon_net)        C11~20 / 102190
02:13:05  IDS: 내부 대역 스캔 전환                   C20(네트워크 측)
02:14:00  passwd·group·sudo -l (recon_account/priv) C21~30 / 102290
02:15:10  ps·pgrep wazuh·systemctl (recon_proc/svc) C31~40 / 102300(보안솔루션)
02:16:25  ls id_rsa·cat .env (recon_file)           C38·39 / 102370
02:17:00  grep 자기IP secure (recon_log)            C41·42 / 102400
02:17:30  [SIEM] 세션 12 전방위 정찰 Alert           C46~48 / 102450·102470

• 로그인 직후 6분간 시스템→네트워크→계정→프로세스→파일→로그 전 영역 정찰
• 각 단계가 recon 키로 탐지되고, 세션 상관(102450)으로 하나의 정찰로 묶임
• 다음 단계(권한 상승 D·중요 정보 E·지속성 F)로 이어지기 전 탐지 가능

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

SOC 분석 관점의 정리입니다(가상의 예시).

[관제 화면]
 세션 12 (devops, 192.168.56.77) 전방위 정보 수집 Alert (level 13)
 - 영역: 시스템·네트워크·계정·프로세스·파일·로그 (6영역)
 - 시간: 02:11~02:17 (6분 집중)
 - 전: B영역 돌파 / 후: E영역 접근 징후

[분석 결론]
 정탐: 탈취 계정의 침해 정찰 (단일 영역이면 보류, 다영역이라 정탐)
 다음 예상: 권한 상승(D)·자격증명 악용(E)·지속성(F)

8. SOC 관제 포인트

• 정찰 시나리오는 로그인→각 영역 정찰→세션 상관 Alert의 순서로 관제 화면에 나타납니다.
• 공격 명령 없이도 흔적 순서·recon 키·세션 상관으로 정찰을 탐지·분석할 수 있습니다.
• 정찰 탐지 시점이 D·E·F영역 이전의 조기 대응 기회입니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<!-- 돌파 직후 전방위 정찰: B영역 돌파 + C영역 상관 결합 -->
<rule id="102490" level="14">
  <if_sid>102470</if_sid>
  <if_matched_sid>101220</if_matched_sid>  <!-- B영역 돌파 -->
  <same_field field="audit.session" />
  <description>인증 돌파 직후 전방위 정찰(침해 정찰 Incident)</description>
</rule>

B영역 돌파(101220)와 C영역 정찰 상관(102470)을 결합하면 "침입→정찰" 흐름을 하나로 탐지합니다. SIEM 상관(148편)으로도 구현합니다.

10. 대응 방법

1. 초기 확인 — 정찰 세션의 로그인→각 영역 정찰 순서와 세션 상관을 확인합니다.
2. 범위 확인 — 정찰 뒤 D·E·F영역(상승·탈취·지속성) 전개를 추적합니다.
3. 증거 확보 — 세션 정찰 타임라인·IOC(IP·계정·대상 파일)를 보존합니다.
4. 차단/조치 — 탈취·정찰 세션이면 B영역 대응과 다음 단계 선제 차단을 진행합니다.
5. 재발 방지 — 돌파+정찰 결합 상관을 운영해 조기 대응합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 150. Linux 정보 수집 — Linux 정보 노출 및 수집 종합 정리 에서는 C영역 마지막으로 Linux 정보 노출 및 수집 종합 정리와 D영역 연결을 다룹니다.

이전 편: 148. Linux 정보 수집 — ELK/SIEM 기반 정보 수집 탐지와 정탐·오탐 판단
📚 시리즈 전체 보기: 시스템 보안 · 취약점

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

선행 학습

• 147. Linux 정보 수집 — Wazuh 기반 탐지
• 046. 설정 변경 이벤트의 SIEM·ELK 연계(A영역)
• 048. 인증 Alert 정탐·오탐 판단(B영역)

1. 개념

Wazuh 룰(C47)이 Alert를 만들면, ELK/SIEM에서 세션별 집계·대시보드로 전체를 보고, 각 Alert를 정탐·정상행위·오탐으로 판단합니다. 정보 수집은 정상 명령 기반이라 판단이 특히 중요합니다.

SIEM 탐지·판단 흐름
 Wazuh Alert(recon) → Elasticsearch → Kibana 대시보드
   ↓
 세션별 recon 영역 수·시간 밀도 집계
   ↓
 정탐/오탐 판단: 기준선·주체·맥락·다음 단계
   ↓
 대응(정탐) / 튜닝(오탐)

판단 핵심(문제 지문): 이벤트·user·IP·time·process·trace·관련로그·전후이벤트·기준선·탐지조건·오탐가능성·추가확인·대응

A영역 46편(SIEM 연계)·B영역 48편(정탐오탐)의 틀을 정보 수집에 적용합니다.

2. 왜 중요한가

• 정보 수집 Alert는 정상 관리 명령과 겹쳐 오탐이 많습니다. 기준선·맥락 없이 올리면 피로도가, 닫으면 정찰을 놓칩니다.
• 세션별 집계(다영역 상관)가 단건보다 정탐률이 높습니다(C46).
• 판단 결과를 대응·튜닝으로 되돌려야 탐지 품질이 유지됩니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# Kibana(KQL) 정보 수집 탐지 질의 (실습 예시)
# 1) 세션별 recon 영역 수 (다영역 = 정찰)
rule.groups: "recon" and agent.name: "rocky9-web01"
  → Terms(data.audit.session) × Unique count(rule.id)

# 2) 특정 세션 정찰 타임라인
data.audit.session: "12"  → 시간순, 컬럼: timestamp, rule.description, data.audit.comm

# 3) 비관리망·새벽 정찰 (B영역 출발지와 결합)
rule.groups: "recon" and not data.srcip: "192.168.56.0/28"

5. 정상 상태

정상행위(Benign)로 판정되는 사례입니다.

Alert   : 102000 시스템 정보 조회 (admin1, ses=8, 09:00)
집계    : 단일 영역(recon_sysinfo) 2건
기준선  : admin1은 아침 점검에 uname/df 사용
전후    : 이후 정상 서비스 관리
판정    : 정상행위 / 튜닝 — admin1 아침 점검 시간 예외(좁게)

6. 이상 상태

정탐으로 판정되는 사례입니다.

Alert   : 102450 전방위 정보 수집 (devops, ses=12, 02:11~02:17)
집계    : 7개 영역, 수십 건, 6분 집중
기준선  : devops {관리망·업무시간·소수 조회} — 전면 이탈
IP/time : 192.168.56.77(비관리망), 새벽
전후    : B영역 돌파(74편) 직후, 이후 E영역 접근 징후
판정    : 정탐 → 침해 정찰 Incident (C49 시나리오)

정상 사례와 비교하면 영역 수·시간·출발지·전후 이벤트가 모두 반대입니다.

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

흔한 오탐·정상행위 패턴과 처리입니다(분석 방법).

패턴                          원인              처리
단일 영역 소수 조회           관리자 점검       기준선·시간 예외(좁게)
모니터링 스크립트의 조회      정기 수집         스크립트 계정·시각 예외
장애 대응 중 다수 조회        인시던트 대응     변경관리·티켓 확인
백업 스크립트의 파일 탐색     정상 백업         백업 계정 예외(C47 102460)

예외는 계정+시각+대상을 좁게 지정합니다(B영역 48편). 넓은 예외는 공격 통로가 됩니다.

8. SOC 관제 포인트

• 정보 수집 Alert는 세션 다영역 집계 + 기준선·맥락으로 정탐/오탐을 판단합니다.
• 단일 영역·관리망·업무 시간은 오탐 가능, 다영역·비관리망·새벽·전후 공격은 정탐입니다.
• 판단에 근거(기준선·전후 이벤트)를 남기고, 오탐은 좁은 예외로 튜닝합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<!-- 비관리망·업무외 정찰은 상향 -->
<rule id="102470" level="13">
  <if_sid>102450</if_sid>
  <srcip>!192.168.56.0/28</srcip>
  <time>18:00-08:00</time>
  <description>업무 외 비관리망 전방위 정보 수집(정찰 Incident)</description>
</rule>

SIEM에서는 세션별 distinct recon_id count와 출발지·시간을 결합한 알림으로 운영합니다(A영역 46편 방식).

10. 대응 방법

1. 초기 확인 — Alert의 집계(영역 수·밀도)·기준선·출발지·시간·전후 이벤트를 판단 요소대로 확인합니다.
2. 범위 확인 — 정탐이면 세션으로 다음 단계(E·F·G) 전개를 확인합니다.
3. 증거 확보 — 판단 근거(집계·기준선·타임라인)를 보존합니다.
4. 차단/조치 — 정탐은 침해 대응(C49), 오탐은 좁은 예외 튜닝을 진행합니다.
5. 재발 방지 — 정보 수집 대시보드·판단 기준을 운영합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 149. Linux 정보 수집 — 실전 시나리오 — 로그인부터 정찰·SIEM 탐지까지 에서는 실전 시나리오로 로그인부터 정찰·SIEM 탐지까지를 다룹니다.

이전 편: 147. Linux 정보 수집 — Wazuh 기반 Linux 정보 수집 탐지
📚 시리즈 전체 보기: 시스템 보안 · 취약점

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

선행 학습

• 146. Linux 정보 수집 — 이벤트 상관분석
• 47. Wazuh(llp)
• 047. 서버 설정 탐지 규칙 모음(A영역)

1. 개념

C영역 상관분석(C46)을 Wazuh로 자동화합니다. 핵심은 auditd의 recon 키를 Wazuh가 받아, 세션 기준으로 상관하는 것입니다. C영역 룰은 102000번대를 씁니다.

탐지 파이프라인
 auditd 규칙(recon_*)        → audit.log
    ↓ Wazuh audit 디코더
 Wazuh manager (룰 매칭)      → recon 단건 룰 + 세션 상관 룰
    ↓
 Alert (102000대) → 대시보드(148편)

룰 계층
 단건  : recon_* 키별 조회 (낮은 레벨)
 세션 상관: 다영역 결합 (높은 레벨, 102450)
 유스케이스: 정찰→다음단계 (E·F·G 연계)

A영역 47편(룰셋 관리)의 방식을 C영역에 적용합니다.

2. 왜 중요한가

• 수동 상관분석(C46)은 사고 후 분석엔 좋지만, 상시 탐지는 자동화가 필요합니다.
• auditd -p r(읽기) 규칙은 이벤트가 많아, 사람 세션(auid)·키·빈도로 좁히지 않으면 로그가 폭증합니다.
• 룰은 반드시 wazuh-logtest로 검증하고 테스트 환경에서 오탐을 튜닝한 뒤 배포합니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 1) auditd recon 규칙이 Wazuh로 수집되는지 확인 (실습 예시)
sudo tail -f /var/ossec/logs/alerts/alerts.log | grep -E 'recon_|102[0-9]{3}'

# 2) 샘플 정찰 로그로 룰 매칭 검증
sudo /var/ossec/bin/wazuh-logtest
# 입력: type=SYSCALL ... auid=1002 ses=12 comm="uname" key="recon_sysinfo"
# 출력: id '102000'(또는 상관 102450) 확인

# 3) 오탐 튜닝: 관리자 계정·백업 스크립트 세션 예외 (좁게)
# local_rules.xml 에 특정 auid/프로그램 예외 룰 추가

5. 정상 상태

**Phase 3: Completed filtering (rules).
    id: '102450'
    level: '12'
    description: '단일 세션의 전방위 정보 수집(다영역 정찰 상관)'
    groups: '[..., syssec_c, recon]'

샘플 정찰 로그가 상관 룰(102450)에 매칭되고, 관리자 정상 세션은 단건 낮은 레벨에 그치는 상태가 정상입니다.

6. 이상 상태

$ sudo tail /var/ossec/logs/ossec.log
wazuh-analysisd: ERROR: Invalid regex at rule '102440'
 또는
(recon_log 단건 Alert 폭증 — tail/cat 정상 작업까지 탐지)

• 정규식 오류로 룰 로딩 실패 → 해당 파일 미적용(A영역 47편과 동일 위험)
• -p r 읽기 규칙이 너무 넓어 정상 로그 열람까지 Alert 폭증 → 사람 세션·빈도로 좁혀야 함
• 배포 전 wazuh-logtest·테스트 환경 검증 필수

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

Wazuh 탐지 결과의 구조입니다(가상의 예시).

rule.id: 102450  level: 12
rule.description: 단일 세션의 전방위 정보 수집
data.audit.auid: 1002   data.audit.session: 12
agent.name: rocky9-web01   timestamp: 2026-10-02T02:17:00
rule.mitre.id: ["T1082","T1016","T1087"]

8. SOC 관제 포인트

• C영역 룰은 102000 대역 + recon 그룹으로 통일하고 세션 상관을 핵심으로 둡니다.
• -p r 읽기 규칙은 사람 세션·빈도·예외로 좁혀 폭증을 막습니다.
• 모든 룰은 wazuh-logtest·테스트 환경 검증 후 배포합니다(실습 예시 명시).

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <!-- 정상 백업 스크립트 세션 예외(좁게) -->
  <rule id="102460" level="2">
    <if_sid>102000,102440</if_sid>
    <field name="audit.auid">^991$</field>  <!-- backup 계정 UID 예시 -->
    <description>백업 계정의 정보 조회(정상) - 집계용</description>
  </rule>
</group>

예외는 계정·프로그램을 좁게 지정합니다(A영역 48편 원칙). 넓은 예외는 공격자가 그 계정을 악용하는 통로가 됩니다.

10. 대응 방법

1. 초기 확인 — recon 룰의 매칭·오탐·폭증을 wazuh-logtest·대시보드로 점검합니다.
2. 범위 확인 — 상관 룰(102450)이 세션을 올바로 묶는지 검증합니다.
3. 증거 확보 — 룰 파일(git)·검증 결과를 보존합니다.
4. 차단/조치 — 오류 룰 수정·예외 튜닝 후 재배포합니다.
5. 재발 방지 — 102000 대역 룰셋과 세션 상관을 운영 기준으로 둡니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 148. Linux 정보 수집 — ELK/SIEM 기반 정보 수집 탐지와 정탐·오탐 판단 에서는 ELK/SIEM 기반 탐지와 정탐·오탐 판단을 다룹니다.

이전 편: 146. Linux 정보 수집 — Linux 정보 수집 행위의 이벤트 상관분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점

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

선행 학습

• 110. 시스템 정보 수집 종합 분석
• 120. 네트워크 정보 수집 종합 분석
• 130. 사용자·권한 정보 수집 종합 분석

1. 개념

정보 수집 탐지의 핵심은 개별 이벤트가 아니라 상관분석입니다. 조회 하나하나는 정상이지만, 같은 사용자·세션·출발지에서 여러 종류가 짧은 시간에 모이면 정찰입니다. 상관분석은 이 "모임"을 찾는 작업입니다.

상관 기준(correlation keys)
 user(auid)      → 누가
 source IP       → 어디서(로그인 출발지)
 timestamp       → 언제(시간 밀도)
 process/command → 무엇을(조회 종류)
 session(ses)    → 하나의 세션으로 묶기

상관 흐름
 개별 이벤트 → 세션(ses)으로 그룹 → 조회 종류·밀도 집계
   → 정상 기준선과 비교 → 정찰 판정

C10·C20·C30·C40·C45의 영역별 세트를, 이 편에서 전 영역 통합 상관으로 묶습니다.

2. 왜 중요한가

• 단일 이벤트 룰은 오탐이 많고(정상 명령), 미탐도 많습니다(느린 정찰). 상관분석이 정확도를 좌우합니다.
• 상관 기준(user·IP·time·process·session)을 표준화하면, 흩어진 조회를 재현성 있게 묶을 수 있습니다.
• 정상 기준선(관리자의 평소 조회 패턴)과 비교해야 "많다/빠르다/이상하다"를 판정할 수 있습니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 세션 기준 전 영역 정찰 상관 (분석 방법)
SES=12
echo "== 세션 $SES 정찰 상관 =="
# 1) 세션의 출발지·사용자
sudo ausearch -m USER_LOGIN --session $SES -i 2>/dev/null | grep -oE 'acct=[^ ]+|addr=[^ ]+' | sort -u
# 2) 조회 종류(key)별 건수
sudo ausearch --session $SES -k recon_sysinfo,recon_net,recon_account,recon_priv,recon_proc,recon_file,recon_log -i 2>/dev/null | grep -oE 'key="[^"]+"' | sort | uniq -c | sort -rn
# 3) 시간 밀도(첫~마지막 조회)
sudo ausearch --session $SES -i 2>/dev/null | grep -oE '[0-9]{2}:[0-9]{2}:[0-9]{2}' | sort | sed -n '1p;$p'

5. 정상 상태

== 세션 8 정찰 상관 ==
acct=admin1 addr=192.168.56.5
recon_sysinfo 2
(단일 영역, 소수, 업무 시간)

관리자 세션은 단일 영역·소수 조회·관리망·업무 시간으로, 기준선 안에 있습니다(정상).

6. 이상 상태

== 세션 12 정찰 상관 ==
acct=devops addr=192.168.56.77
  recon_sysinfo 7   recon_net 18   recon_account 8
  recon_priv 5      recon_proc 5   recon_file 9    recon_log 24
시간 밀도: 02:11:40 ~ 02:17:33 (약 6분)

• 한 세션에서 7개 영역 전부, 수십 건, 6분 집중 → 전방위 정찰 확정
• 비관리망·새벽·탈취 계정 → 모든 상관 기준이 기준선 이탈
• 시스템→네트워크→계정→프로세스→로그 순서 → 교과서적 정찰 흐름(C49 시나리오)

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

상관분석 결과를 한 화면으로 정리한 예시입니다(가상의 예시).

세션 12 (devops, 192.168.56.77, 02:11~02:17)
 영역      건수   대표 조회
 시스템    7     uname, os-release, cpuinfo
 네트워크  18    ip addr/route/neigh, ss
 계정      8     passwd, group, sudo -l
 프로세스  5     ps, pgrep wazuh
 파일      9     find id_rsa, cat .env
 로그      24    grep 자기IP secure
 → 전 영역 상관 = 전방위 정찰 (단일 영역이면 오탐 가능, 다영역이면 정탐)

8. SOC 관제 포인트

• 정보 수집 탐지는 세션(ses) 기준 다영역 상관으로 판정합니다(단일 영역·단건은 오탐 가능).
• 상관 기준(user·IP·time·process·session)을 표준화해 재현성 있게 묶습니다.
• 정상 기준선(C10·20·30 평소 패턴)과 비교해 이탈을 판정합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <!-- 한 세션에서 서로 다른 정찰 영역 키가 결합 -->
  <rule id="102450" level="12" frequency="10" timeframe="300">
    <if_group>audit</if_group>
    <field name="audit.key" type="pcre2">recon_(sysinfo|net|account|priv|proc|file|log)</field>
    <same_field field="audit.session" />
    <description>단일 세션의 전방위 정보 수집(다영역 정찰 상관)</description>
    <mitre><id>T1082</id></mitre>
  </rule>
</group>

same_field·다영역 조건은 버전 제약이 있으므로, 핵심 상관은 SIEM(148편)에서 세션별 distinct recon_key count로 구현합니다.

10. 대응 방법

1. 초기 확인 — 세션 기준으로 user·IP·time·조회 영역을 상관해 정찰을 판정합니다.
2. 범위 확인 — 정찰 세션의 다음 단계(E·F·G영역) 전개를 추적합니다.
3. 증거 확보 — 상관 결과(세션·영역·밀도)와 근거 로그를 보존합니다.
4. 차단/조치 — 탈취·정찰 세션이면 B영역 대응과 다음 단계 차단을 진행합니다.
5. 재발 방지 — 세션 기준 다영역 상관을 탐지 표준으로 운영합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 147. Linux 정보 수집 — Wazuh 기반 Linux 정보 수집 탐지 에서는 상관분석을 자동화하는 Wazuh 기반 Linux 정보 수집 탐지를 다룹니다.

이전 편: 145. Linux 정보 수집 — 설정 파일 접근 종합 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 45/50편 (전체 145/450) 학습 단계: 로그·설정·환경 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 141. Linux 정보 수집 — 로그 파일 접근 흔적
• 144. Linux 정보 수집 — 애플리케이션 로그 접근
• 46. 로그를 SIEM으로(llp)

1. 개념

로그·설정·환경 접근(C41~44, C09·C39)은 자격증명 수집과 흔적 확인(변조 선행) 두 목적으로 수렴합니다. 이 세트는 정찰의 마지막 단계이자, E영역(중요 정보 접근)·G영역(로그 변조)의 직접 선행입니다.

로그·설정·환경 접근 세트
 환경변수(C09) + 설정 파일(C39) → 자격증명 수집
 로그 접근(C41~44)             → 흔적 확인(변조 선행) + 추가 정보

정상 관리자 vs 침해 의심 계정
 관리자: 작업 맥락, 특정 로그, 쓰기(변경) 포함, 업무 시간
 침해:   자기 흔적 검색, 자격증명 파일 집중, 읽기 전용, 연속·새벽

2. 왜 중요한가

• 이 영역은 정찰의 종착점입니다: 자격증명을 모아 E영역(DB·중요 정보) 접근으로, 흔적을 파악해 G영역(로그 변조)으로 이어집니다.
• 관리자의 정상 로그/설정 접근과 침해 계정의 비정상 접근은 주체·패턴·목적으로 구분해야 오탐을 줄입니다.
• llp 시리즈(로그 경로·SIEM)와 연결해, 로그 접근 정찰이 SIEM에서 어떻게 보이는지 정리합니다.

3. 핵심 명령어 / 설정

정상 관리자 vs 침해 의심 계정 접근 비교:

4. 실습 (실습 예시)

# 로그·설정·환경 접근 세트의 세션별 집계 (분석 방법)
for ses in $(sudo ausearch -k recon_log,recon_file,recon_env,recon_environ -i --start today 2>/dev/null | grep -oE 'ses=[0-9]+' | sort -u | cut -d= -f2); do
  n=$(sudo ausearch --session $ses -k recon_log,recon_file,recon_env,recon_environ -i 2>/dev/null | grep -cE 'type=SYSCALL')
  echo "ses=$ses 로그설정접근=$n"
done | sort -t= -k2 -rn | head

5. 정상 상태

ses=8  로그설정접근=3  (admin1, 특정 로그 작업)

관리자 세션은 특정 로그·설정을 작업 맥락에서 접근하고, 자격증명 파일·자기 흔적 검색이 없는 상태가 정상입니다.

6. 이상 상태

ses=12 로그설정접근=24  (devops, 02:16~02:17)
 .env·my.cnf(자격증명) + secure·messages(자기 흔적) + access_log(토큰)

• 한 세션에서 자격증명 파일 + 로그 흔적 검색 다수 결합 → 수집+변조 준비 종합
• .env·토큰(자격증명) → E영역 접근 / secure·messages 자기 흔적 → G영역 변조
• 시스템·네트워크·계정·프로세스 정찰(C01~40)의 종착점

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

로그·설정 정찰 수렴 타임라인입니다(가상의 예시).

02:16:35 cat .env / my.cnf          (자격증명 수집, C39)
02:17:00 ls /var/log / grep 자기IP  (흔적 확인, C41)
02:17:10 grep admin1 secure         (패턴 학습, C42)
02:17:30 grep token access_log      (토큰 수집, C44)
 → 자격증명 수집(E영역) + 흔적 확인(G영역) 수렴

8. SOC 관제 포인트

• 로그·설정·환경 접근은 자격증명 수집·흔적 확인 두 목적으로 수렴합니다.
• 정상 관리자와 침해 계정을 주체·패턴·목적 비교표로 구분합니다.
• 이 세트 탐지 뒤 E영역(중요 정보 접근)·G영역(로그 변조)으로의 전개를 추적합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102440" level="9" frequency="5" timeframe="180">
    <if_group>audit</if_group>
    <field name="audit.key" type="pcre2">recon_(log|file|env|environ)</field>
    <same_field field="audit.session" />
    <description>단일 세션의 다종 로그·설정·환경 접근(자격증명 수집·흔적 확인 정찰)</description>
    <mitre><id>T1552</id></mitre>
  </rule>
</group>

same_field 미지원 시 SIEM 집계(146·148편)로 구현합니다. E·G영역 룰과 연계합니다.

10. 대응 방법

1. 초기 확인 — 로그·설정·환경 접근 세션의 목적(자격증명/흔적)·주체·패턴을 비교표로 확인합니다.
2. 범위 확인 — 자격증명 수집 뒤 E영역 접근, 흔적 확인 뒤 G영역 변조가 이어졌는지 확인합니다.
3. 증거 확보 — 세션 접근 흐름(원격 사본)을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 자격증명 교체·로그 무결성 점검을 진행합니다.
5. 재발 방지 — 로그·설정 접근을 E·G영역 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 146. Linux 정보 수집 — Linux 정보 수집 행위의 이벤트 상관분석 에서는 6단계 SOC 탐지로 넘어가 Linux 정보 수집 행위의 이벤트 상관분석을 다룹니다.

이전 편: 144. Linux 정보 수집 — 애플리케이션 로그 접근
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 44/50편 (전체 144/450) 학습 단계: 로그·설정·환경 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 143. Linux 정보 수집 — 시스템 로그 접근 분석
• 39. 설정 파일 탐색 흔적

1. 개념

애플리케이션 로그(웹 access/error, DB, 앱 로그)는 시스템 로그보다 민감한 운영 데이터를 담기도 합니다: URL에 담긴 토큰·세션ID, 사용자 활동, 쿼리, 오류 스택(경로·버전). 공격자는 여기서 추가 자격증명·공격 표면을 수집합니다.

앱 로그 접근
 cat /var/log/httpd/access_log  → 요청 URL(토큰·파라미터)
 cat /var/log/httpd/error_log   → 오류(경로·스택·버전)
 cat /var/log/mysql/*.log       → DB 로그(쿼리·연결)
 앱 자체 로그(/var/www/.../logs) → 앱 활동·세션

위험: access_log의 URL 토큰·세션ID, error_log의 경로·버전 노출

C39(설정 파일)가 "설정의 자격증명"이라면, 여기서는 "로그에 흘러든 민감 데이터"입니다. 웹 보안 영역(기존 웹 300편)과도 연결됩니다.

2. 왜 중요한가

• access_log의 URL에 토큰·세션ID·API 키가 GET 파라미터로 남으면(앱 취약점), 공격자가 그대로 탈취합니다.
• error_log의 스택 트레이스는 내부 경로·프레임워크 버전·DB 구조를 드러내 추가 공격 표면이 됩니다.
• 앱 로그 접근은 서비스 계정(apache)·침입 계정이 하며, 자기 웹 공격 흔적 확인에도 쓰입니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 앱 로그 접근 감사 (실습 예시)
-w /var/log/httpd -p r -k recon_log
-w /var/log/nginx -p r -k recon_log
-w /var/log/mysql -p r -k recon_log

# 앱 로그 접근 패턴 (분석 방법)
sudo ausearch -k recon_log -i --start recent | grep -E 'access_log|error_log|mysql|httpd|nginx' | tail

5. 정상 상태

$ sudo ausearch -k recon_log -i --start today | grep access_log | tail -1
10:50:02 auid=admin1 ses=8 comm="tail" name="/var/log/httpd/access_log"  (트래픽 점검)

관리자가 웹 트래픽·오류를 점검하는 것은 정상입니다. 공격자는 토큰·세션 검색, 서비스 계정의 로그 열람이 특징입니다.

6. 이상 상태

02:17:30 auid=devops ses=12 comm="grep" (token /var/log/httpd/access_log)
02:17:33 auid=devops ses=12 comm="cat" name="/var/log/httpd/error_log"

• access_log에서 token 검색 → URL에 노출된 토큰·세션ID 탈취 시도
• error_log 열람 → 내부 경로·버전·DB 구조 수집(추가 공격 표면)
• 설정(C39)·앱 로그(C44)에서 자격증명·토큰 수집 → E영역 접근 준비

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

앱 로그 정찰 흐름입니다(가상의 예시 로그 — 토큰 값은 가림).

type=EXECVE ... a0="grep" a1="token" a2="/var/log/httpd/access_log"
type=SYSCALL ... auid=devops ses=12 comm="grep" key="recon_log"
[access_log 예시 - 민감값 마스킹]
192.168.56.50 - - [02/Oct/2026:01:00:00] "GET /api?token=<masked> HTTP/1.1" 200

로그에서 토큰·세션을 다룰 때는 값을 마스킹해 분석하고, 보고서에 원문을 남기지 않습니다.

8. SOC 관제 포인트

• 앱 로그 접근 중 토큰·세션·자격증명 검색을 정찰로 봅니다(값은 마스킹 분석).
• URL에 토큰이 평문으로 남는 앱 설계 문제는 웹 보안 영역과 함께 시정합니다.
• 앱 로그에서 얻은 토큰·세션 악용(E영역·세션 재사용)을 연계 감시합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,credential,">
  <rule id="102430" level="8">
    <if_group>audit</if_group>
    <field name="audit.key">recon_log</field>
    <regex type="pcre2">(access_log|error_log|/var/log/(httpd|nginx|mysql))</regex>
    <description>애플리케이션 로그 접근(토큰·세션 수집 정찰)</description>
    <mitre><id>T1552.001</id></mitre>
  </rule>
</group>

앱 로그에서 토큰 검색은 자격증명 수집으로 분류하고, E영역·웹 보안 영역과 연계합니다.

10. 대응 방법

1. 초기 확인 — 앱 로그 접근의 대상(토큰·세션 검색)·주체를 확인합니다(값 마스킹).
2. 범위 확인 — 노출 토큰·세션의 악용(E영역·세션 재사용)이 이어졌는지 확인합니다.
3. 증거 확보 — 앱 로그 접근 흔적을 보존합니다(민감값 마스킹).
4. 차단/조치 — 탈취 세션이면 B영역 대응과 노출 토큰·세션 무효화를 진행합니다.
5. 재발 방지 — 앱 로그 토큰 검색을 자격증명 수집 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 145. Linux 정보 수집 — 설정 파일 접근 종합 분석 에서는 5단계를 마무리하는 설정 파일 접근 종합 분석을 다룹니다.

이전 편: 143. Linux 정보 수집 — 시스템 로그 접근 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 43/50편 (전체 143/450) 학습 단계: 로그·설정·환경 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 142. Linux 정보 수집 — 인증 로그 접근 분석
• 12. messages 로그(llp)
• 31. journald(llp)

1. 개념

시스템 로그(/var/log/messages·syslog·journald)는 서비스 시작·오류·커널·cron 실행 등 시스템 전반의 기록입니다. 공격자는 여기서 시스템 활동을 학습하거나, 자신의 행위(서비스 등록·cron 실행)가 남긴 흔적을 확인합니다.

시스템 로그 접근
 cat/tail /var/log/messages  → 시스템 기록(Rocky)
 cat/tail /var/log/syslog    → 시스템 기록(Ubuntu)
 journalctl                  → systemd 저널(llp 31편)
 journalctl -u <서비스>      → 특정 서비스 로그
 grep <자기행위> messages    → 자기 흔적 확인

용도: 시스템 구조·오류 학습 / 자기 서비스·cron 등록 흔적 확인(G영역 선행)

llp 12·31편이 시스템 로그·journald 분석(방어)이라면, 여기서는 공격자가 시스템 로그에 접근하는 정찰입니다.

2. 왜 중요한가

• 시스템 로그로 공격자는 자기 지속성(서비스·cron 등록) 흔적이 어디 남았나 확인해, 삭제(G영역)나 회피를 준비합니다.
• journald는 바이너리 저장이라 선별 삭제가 어렵지만, 설정 변경(A영역 28편 volatile)으로 무력화할 수 있어 공격자가 구조를 조회합니다.
• 오류 로그에서 서비스 취약점·경로 정보를 얻을 수도 있습니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 시스템 로그 접근 감사 (실습 예시)
-w /var/log/messages -p r -k recon_log
-w /var/log/syslog -p r -k recon_log
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/journalctl -F auid>=1000 -F auid!=unset -k recon_log

# 시스템 로그 접근 패턴 (분석 방법)
sudo ausearch -k recon_log -i --start recent | grep -E 'messages|syslog|journalctl' | tail

5. 정상 상태

$ sudo ausearch -k recon_log -i --start today | grep messages | tail -1
10:40:02 auid=admin1 ses=8 comm="tail" name="/var/log/messages"  (장애 점검)

관리자가 장애·서비스 로그를 점검하는 것은 정상입니다(llp 12편 분석). 공격자는 자기 행위 흔적 검색·전수 조회가 특징입니다.

6. 이상 상태

02:17:20 auid=devops ses=12 comm="journalctl" (-u 특정 서비스)
02:17:23 auid=devops ses=12 comm="grep" (sysbak /var/log/messages)

• journald로 자기 서비스 등록 로그 확인 + messages에서 자기 생성 계정(sysbak) 흔적 검색 → 흔적 확인
• 지속성(서비스·계정) 흔적이 어느 로그에 남았나 파악 → G영역 변조·회피 준비
• 인증 로그(C42)에 이어 시스템 로그까지 흔적 확인 → 로그 전반 삭제 범위 파악

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

시스템 로그 흔적 확인 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="journalctl" a1="-u" a2="dbus-update"
type=SYSCALL ... auid=devops ses=12 comm="journalctl" key="recon_log"
type=EXECVE ... a0="grep" a1="sysbak" a2="/var/log/messages"

흔적 확인 뒤 journald 설정 변경(A영역 28편)·로그 삭제(G영역)가 이어지는지 연계합니다.

8. SOC 관제 포인트

• 시스템 로그 접근 중 자기 행위(계정·서비스) 흔적 검색을 변조 선행으로 봅니다.
• journald 구조 조회 뒤 설정 변경(A영역 28편 volatile)이 이어지는지 확인합니다.
• 인증(C42)+시스템(C43) 로그 흔적 확인을 묶어 로그 변조 준비로 봅니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102420" level="7">
    <if_group>audit</if_group>
    <field name="audit.key">recon_log</field>
    <regex type="pcre2">(messages|syslog)|a0="journalctl"</regex>
    <description>시스템 로그 접근(흔적 확인 정찰)</description>
    <mitre><id>T1070</id></mitre>
  </rule>
</group>

시스템 로그 접근은 G영역(로그 변조)·A영역 28편(journald)과 연계합니다. 원격 전송 로그로 탐지 신뢰도를 확보합니다.

10. 대응 방법

1. 초기 확인 — 시스템 로그 접근의 패턴(자기 흔적·전수)·주체를 확인합니다.
2. 범위 확인 — 접근 뒤 journald 설정 변경·로그 삭제(A영역 28편·G영역)가 이어졌는지 확인합니다.
3. 증거 확보 — 시스템 로그 접근 흔적(원격 사본)을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 로그 무결성 점검을 진행합니다.
5. 재발 방지 — 시스템 로그 접근을 변조 선행 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 144. Linux 정보 수집 — 애플리케이션 로그 접근 에서는 애플리케이션 로그 접근인 애플리케이션 로그 접근을 다룹니다.

이전 편: 142. Linux 정보 수집 — 인증 로그 접근 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 42/50편 (전체 142/450) 학습 단계: 로그·설정·환경 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 141. Linux 정보 수집 — 로그 파일 접근 흔적
• 13. secure 로그(llp)
• 22. auth.log(llp)

1. 개념

인증 로그(/var/log/secure·auth.log)는 로그인 성공·실패·sudo·su 기록이 모인 곳입니다. 공격자에게 두 가치가 있습니다: ①다른 계정의 로그인 패턴 학습(C25 역이용 심화), ②자신의 인증 흔적 확인(삭제 대상, C41 심화).

인증 로그 접근
 cat/tail /var/log/secure   → 인증 기록(Rocky)
 cat/tail /var/log/auth.log → 인증 기록(Ubuntu)
 grep <계정> secure         → 특정 계정 로그인 패턴
 grep <자기세션> secure     → 자기 인증 흔적

용도: 정상 사용자 패턴 학습(위장) / 자기 로그인·sudo 흔적 확인(삭제)

llp 13·22편이 인증 로그 분석(방어)이라면, 여기서는 공격자가 인증 로그에 접근하는 정찰입니다.

2. 왜 중요한가

• 인증 로그로 공격자는 정상 로그인 패턴(시간·출발지)을 학습해 위장(B영역 27편 회피)하거나, 자기 흔적(돌파·sudo)을 확인해 삭제(G영역) 대상을 정합니다.
• 인증 로그는 사고 분석의 핵심 증거라, 공격자가 지우려는 1순위입니다. 접근·삭제 모두 주시합니다.
• 서비스 계정·비관리 계정의 인증 로그 열람은 거의 항상 비정상입니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 인증 로그 접근 감사 (실습 예시)
-w /var/log/secure -p r -k recon_log
-w /var/log/auth.log -p r -k recon_log
-w /var/log/btmp -p r -k recon_log

# 인증 로그 접근 패턴 (분석 방법)
sudo ausearch -k recon_log -i --start recent | grep -E 'secure|auth.log|btmp' | tail

5. 정상 상태

$ sudo ausearch -k recon_log -i --start today | grep secure | tail -1
10:30:02 auid=admin1 ses=8 comm="tail" name="/var/log/secure"  (인증 점검)

관리자·보안 담당자가 인증 로그를 분석하는 것은 정상입니다(llp 13편 분석). 공격자는 자기 흔적 검색·비관리 계정 열람이 특징입니다.

6. 이상 상태

02:17:10 auid=devops ses=12 comm="grep" (admin1 /var/log/secure)
02:17:13 auid=devops ses=12 comm="grep" (192.168.56.77 /var/log/secure)

• admin1 로그인 패턴 검색(위장 준비, C25 심화) + 자기 출발지(.77) 검색(흔적 확인, C41 심화)
• 정상 사용자 패턴 학습 + 자기 흔적 파악 → 위장·삭제 준비 동시
• 인증 로그는 돌파(B영역 74편)·sudo 흔적을 담아, 공격자의 핵심 삭제 대상

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

인증 로그 접근 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="grep" a1="admin1" a2="/var/log/secure"
type=SYSCALL ... auid=devops ses=12 comm="grep" key="recon_log"
type=EXECVE ... a0="grep" a1="192.168.56.77" a2="/var/log/secure"

인증 로그 접근 뒤 위장 접속(B영역 27편)·로그 삭제(G영역)가 이어지는지 연계합니다.

8. SOC 관제 포인트

• 인증 로그 접근 중 자기 흔적 검색·정상 패턴 학습을 정찰로 봅니다.
• 서비스·비관리 계정의 인증 로그 열람은 즉시 확인합니다.
• 인증 로그는 원격 전송(A영역 29편)으로 보존해 로컬 삭제(G영역)에 대비합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102410" level="8">
    <if_group>audit</if_group>
    <field name="audit.key">recon_log</field>
    <regex type="pcre2">(secure|auth\.log|btmp)</regex>
    <description>인증 로그 접근(흔적 확인·패턴 학습 정찰)</description>
    <mitre><id>T1070</id></mitre>
  </rule>
</group>

인증 로그 접근은 G영역(로그 변조)·B영역 27편(이상 로그인)과 연계합니다. 원격 사본으로 탐지 신뢰도를 확보합니다.

10. 대응 방법

1. 초기 확인 — 인증 로그 접근의 패턴(자기 흔적·정상 패턴)·주체를 확인합니다.
2. 범위 확인 — 접근 뒤 위장 접속(B영역)·로그 삭제(G영역)가 이어졌는지 원격 사본으로 확인합니다.
3. 증거 확보 — 인증 로그 접근 흔적(원격 사본)을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 인증 로그 무결성 점검을 진행합니다.
5. 재발 방지 — 인증 로그 접근을 변조·이상로그인 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 143. Linux 정보 수집 — 시스템 로그 접근 분석 에서는 시스템 로그 접근인 시스템 로그 접근 분석을 다룹니다.

이전 편: 141. Linux 정보 수집 — 로그 파일 접근 흔적
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 41/50편 (전체 141/450) 학습 단계: 로그·설정·환경 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 140. Linux 정보 수집 — 프로세스·서비스·파일 정보 수집 종합 분석
• 41. Linux 보안 로그 구조(linsec)
• 03. /var/log(llp)

1. 개념

로그 파일 접근은 양면성을 가진 정찰입니다. 공격자는 로그에서 ①정보를 수집(다른 사용자 활동·내부 구조)하거나, ②자신의 흔적을 확인해 어떤 로그를 지울지 파악합니다(G영역 로그 변조의 선행).

로그 접근 (/var/log)
 ls /var/log/            → 어떤 로그가 있는가(G영역 삭제 대상 파악)
 cat/tail /var/log/*     → 로그 내용(정보 수집·흔적 확인)
 grep <자기IP> /var/log/* → 자기 흔적 검색(제거 대상 특정)

두 목적
 ① 정보 수집: 다른 사용자·시스템 활동 학습
 ② 흔적 확인: 자신의 로그인·행위가 어디 남았나 → G영역 삭제 준비

llp 시리즈(로그 경로 정리)가 "로그 구조·분석"(방어)이라면, 여기서는 공격자가 로그에 접근하는 정찰입니다.

2. 왜 중요한가

• 공격자가 grep <자기IP> /var/log로 자기 흔적을 찾으면, 이후 그 로그를 선별 삭제(G영역)하려 합니다. 흔적 확인은 로그 변조의 직접 선행입니다.
• 로그 디렉터리 전수 조회(ls /var/log)는 "어떤 로그가 수집되는가"를 파악해 삭제·회피 범위를 정합니다.
• 로그 접근 자체는 관리자도 하므로, 자기 IP/계정 검색·전수 조회·삭제 선행 패턴으로 구분합니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 로그 접근 감사 (실습 예시)
-w /var/log -p r -k recon_log

# 자기 흔적 검색 패턴인지 (분석 방법)
sudo ausearch -k recon_log -i --start recent | grep '/var/log' | tail
sudo ausearch --session 12 -i 2>/dev/null | grep -E 'comm="grep".*log|comm="ls".*log|/var/log' | tail

/var/log 읽기는 관리자가 자주 하므로, 사람 세션의 전수 조회·grep 자기IP·삭제 선행으로 좁혀 봅니다(147편).

5. 정상 상태

$ sudo ausearch -k recon_log -i --start today | grep '/var/log' | tail -1
10:00:02 auid=admin1 ses=8 comm="tail" name="/var/log/messages"  (로그 점검)

관리자가 특정 로그를 점검·분석하는 것은 정상입니다(llp 시리즈 분석 작업). 차이는 자기 흔적 검색·전수 조회입니다.

6. 이상 상태

02:17:00 auid=devops ses=12 comm="ls" name="/var/log/"
02:17:03 auid=devops ses=12 comm="grep" (192.168.56.77 /var/log/secure)
02:17:05 auid=devops ses=12 comm="grep" (devops /var/log/*)

• 로그 디렉터리 전수 조회 + 자기 IP·계정으로 로그 검색 → 흔적 확인(삭제 대상 특정)
• 자기 흔적이 어느 로그에 남았나 파악 → G영역 로그 변조 준비
• 정찰 마무리 단계에서 "내 흔적 지우기" 준비로 이어짐

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

로그 흔적 확인 → 변조 준비 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="grep" a1="192.168.56.77" a2="/var/log/secure"
type=SYSCALL ... auid=devops ses=12 comm="grep" key="recon_log"
[이후 가능] /var/log/secure 선별 삭제·변조 (G영역)

로그 흔적 확인 직후 로그 삭제·크기 변화(G영역)가 나타나는지 연계합니다.

8. SOC 관제 포인트

• 로그 접근 중 자기 IP/계정 검색·전수 조회를 흔적 확인(변조 선행)으로 봅니다.
• 흔적 확인 직후 로그 삭제·변조(G영역)가 이어지는지 연계 감시합니다.
• 로그 접근은 원격 전송 로그(A영역 29편)로 교차 확인해, 로컬 변조에 대비합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102400" level="8">
    <if_group>audit</if_group>
    <field name="audit.key">recon_log</field>
    <regex type="pcre2">a0="grep".*(/var/log|secure|auth\.log)</regex>
    <description>로그 파일에서 특정 IP/계정 검색(흔적 확인·변조 선행)</description>
    <mitre><id>T1070</id></mitre>
  </rule>
</group>

T1070(Indicator Removal) 계열. 로그 흔적 확인은 G영역(로그 변조) 룰과 연계합니다. 로컬 로그는 지워질 수 있으므로 원격 사본(A영역 29편)으로 탐지합니다.

10. 대응 방법

1. 초기 확인 — 로그 접근의 패턴(자기IP·전수 조회)·주체와 대상 로그를 확인합니다.
2. 범위 확인 — 흔적 확인 직후 로그 삭제·변조(G영역)가 이어졌는지 원격 사본으로 확인합니다.
3. 증거 확보 — 로그 접근 흔적(원격 사본 포함)을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 로그 무결성 점검을 진행합니다.
5. 재발 방지 — 로그 흔적 확인을 변조 선행 상관(G영역)에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 142. Linux 정보 수집 — 인증 로그 접근 분석 에서는 인증 흔적 확인인 인증 로그 접근 분석을 다룹니다.

이전 편: 140. Linux 정보 수집 — 프로세스·서비스·파일 정보 수집 종합 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 40/50편 (전체 140/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 131. Linux 정보 수집 — 프로세스 목록 조회 흔적
• 139. Linux 정보 수집 — 설정 파일 탐색 흔적

1. 개념

프로세스·서비스·파일 정찰(C31~39)은 "무엇이 돌고, 무엇이 등록됐고, 어떤 파일이 있는가"를 파악해 지속성 등록·탈취 대상·탐지 회피를 준비하는 단계입니다. 이 영역의 핵심은 정상 운영 명령과 의심 연속 조회의 구분입니다.

프로세스·서비스·파일 정찰 세트 (한 세션)
 프로세스(C31·32) → 도구(C33) → 서비스(C34·35) → cron(C36)
   → 파일 탐색(C37) → 중요 파일(C38) → 설정(C39)

수렴점
 - 지속성 준비: systemd(C35)·cron(C36) 등록 위치
 - 탈취 준비: 중요 파일(C38)·설정 자격증명(C39)
 - 회피 준비: 보안 솔루션(C31·34)

2. 왜 중요한가

• 이 영역의 명령(ps·systemctl·find·cat)은 관리자가 매일 쓰는 것이라, 단건 탐지는 오탐투성이입니다. 연속·대상·맥락으로 구분해야 합니다.
• 세트로 보면 지속성·탈취·회피 준비가 한 세션에 수렴하는 것이 드러납니다.
• 정상 운영과 정찰의 경계를 표로 정리해 두면 판단이 일관됩니다(문제 지문의 비교표).

3. 핵심 명령어 / 설정

정상 운영 vs 의심 연속 조회 비교(문제 지문 기반 확장):

4. 실습 (실습 예시)

# 프로세스·서비스·파일 정찰 세트의 세션별 조회 종류 집계 (분석 방법)
for ses in $(sudo ausearch -k recon_proc,recon_svc,recon_file,recon_tool,recon_persist -i --start today 2>/dev/null | grep -oE 'ses=[0-9]+' | sort -u | cut -d= -f2); do
  n=$(sudo ausearch --session $ses -k recon_proc,recon_svc,recon_file,recon_tool,recon_persist -i 2>/dev/null | grep -oE 'key="[^"]+"' | sort -u | wc -l)
  echo "ses=$ses 정찰키종류=$n"
done | sort -t= -k2 -rn | head

5. 정상 상태

ses=8  정찰키종류=1  (admin1, 특정 작업)

관리자 세션은 특정 작업 맥락의 단일 종류 조회에 그치고, 보안 솔루션 조준·전체 탐색이 없는 상태가 정상입니다.

6. 이상 상태

ses=12 정찰키종류=5  (devops, 02:15~02:16)
 recon_proc(보안솔루션) + recon_svc(systemd) + recon_persist(cron) + recon_file(민감파일) + recon_tool(LOLBins)

• 한 세션에서 프로세스·서비스·cron·파일·도구 5종 정찰 결합 → 지속성+탈취+회피 준비 종합
• 보안 솔루션 조준(C31) + systemd/cron 조회(C35·36) + 민감 파일(C38) → 다음 단계(F영역 지속성·E영역 탈취) 임박
• 시스템(C10)·네트워크(C20)·계정(C30) 정찰에 이어 4단계 정찰 완료

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

프로세스·파일 정찰 세트 타임라인입니다(가상의 예시).

02:15:10 ps aux / pgrep wazuh   (프로세스·보안솔루션, C31)
02:15:40 systemctl list/status  (서비스, C34·35)
02:16:00 crontab -l / cron.d    (cron, C36)
02:16:10 find / -name id_rsa    (민감 파일, C37·38)
02:16:35 cat .env / my.cnf      (설정 자격증명, C39)
 → 1분 반 내 5종, 한 세션 = 지속성+탈취+회피 준비 정찰

8. SOC 관제 포인트

• 프로세스·서비스·파일 정찰은 세션 내 조회 키 종류·대상으로 판정합니다(개별 명령 아님).
• 보안 솔루션 조준·systemd/cron 조회·자격증명 파일 열람이 결합되면 다음 단계(E·F영역) 임박입니다.
• 정상/의심 비교표를 판단 기준으로 운영합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102390" level="10" frequency="5" timeframe="180">
    <if_group>audit</if_group>
    <field name="audit.key" type="pcre2">recon_(proc|svc|file|tool|persist)</field>
    <same_field field="audit.session" />
    <description>단일 세션의 다종 프로세스·서비스·파일 정보 수집(정찰 세트)</description>
    <mitre><id>T1057</id></mitre>
  </rule>
</group>

same_field 미지원 시 SIEM 집계로 구현합니다(146·148편). E·F영역 룰과 연계합니다.

10. 대응 방법

1. 초기 확인 — 프로세스·파일 정찰 세션의 조회 키 종류·대상·주체를 확인합니다.
2. 범위 확인 — 지속성(F영역)·탈취(E영역)·회피(A영역 39편)로 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름과 비교표 기반 판정을 보존합니다.
4. 차단/조치 — 탈취·지속성 세션이면 E·F영역 대응과 연계합니다.
5. 재발 방지 — 프로세스·파일 정찰 세트 탐지를 운영 기준으로 둡니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 141. Linux 정보 수집 — 로그 파일 접근 흔적 에서는 5단계로 넘어가 로그 파일 접근 흔적을 다룹니다.

이전 편: 139. Linux 정보 수집 — 설정 파일 탐색 흔적
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 39/50편 (전체 139/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 138. Linux 정보 수집 — 중요 파일 존재 여부 확인
• 21. /etc 디렉터리 변경 관리(A영역)

1. 개념

설정 파일은 자격증명·연결 정보·경로가 모여 있는 고가치 대상입니다. 웹 서버 설정, DB 설정, 앱 config(.env·yml)에는 DB 비밀번호·API 키·백엔드 주소가 담겨 있어, 공격자가 집중 조회합니다.

설정 파일 탐색·열람
 cat /etc/httpd/conf/*    → 웹 서버 설정(경로·가상호스트)
 cat /etc/my.cnf          → DB 설정
 cat /var/www/html/.env   → 앱 자격증명(DB_PASSWORD 등)
 cat application.yml      → 앱 설정

위험: 설정 내 평문 자격증명 → 추가 인증 없이 DB·API 접근(E영역)

문제 지문의 비교: 설정 조회가 인증·네트워크 정보와 연속되면(계정→네트워크→설정) 정찰의 종합 단계입니다. A영역 21편(/etc 변경 관리)이 변경 탐지라면, 여기서는 설정 열람 정찰입니다.

2. 왜 중요한가

• 설정 파일의 평문 자격증명은 추가 인증 없이 DB·API·백엔드 접근을 가능하게 합니다(C09 환경변수와 함께 자격증명 수집의 핵심).
• 웹 설정의 가상호스트·경로는 추가 공격 표면(숨은 앱·관리 페이지)을 드러냅니다.
• 설정 조회가 계정(C21)·네트워크(C11) 정찰과 연속되면, 정찰이 자격증명 수집으로 수렴하는 신호입니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 설정 파일 열람 감사 (실습 예시)
-w /var/www -p r -k recon_file
-w /etc/my.cnf -p r -k recon_file
-w /etc/httpd -p r -k recon_file

# 설정 조회가 계정·네트워크 정보와 연속됐는지 (분석 방법)
sudo ausearch -k recon_file -i --start recent | grep -E 'conf|\.env|\.yml|my.cnf' | tail
sudo ausearch --session 12 -i 2>/dev/null | grep -E 'passwd|resolv|httpd|\.env|my.cnf' | tail

5. 정상 상태

$ sudo ausearch -k recon_file -i --start today | grep httpd | tail -1
11:20:02 auid=admin1 ses=8 comm="vi" name="/etc/httpd/conf.d/ssl.conf"  (설정 작업)

관리자가 설정을 작업·점검하는 것은 정상입니다(변경관리와 일치). 공격자는 읽기만·연속·자격증명 파일 집중이 특징입니다.

6. 이상 상태

02:16:35 auid=devops ses=12 comm="cat" name="/var/www/html/.env"
02:16:37 auid=devops ses=12 comm="cat" name="/etc/my.cnf"
02:16:40 auid=devops ses=12 comm="cat" name="/etc/httpd/conf/httpd.conf"

• .env(자격증명) + my.cnf(DB) + httpd.conf(웹) 연속 열람 → 자격증명·구성 수집
• .env의 DB_PASSWORD 확보 → 내부 DB 접근(C18 연결 정찰과 결합, E영역)
• 계정(C21)·네트워크(C11)·설정(C39) 연속 → 정찰이 자격증명 수집으로 수렴

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

설정 파일 정찰 흐름입니다(가상의 예시 로그).

type=PATH ... name="/var/www/html/.env" nametype=NORMAL
type=SYSCALL ... auid=devops ses=12 comm="cat" key="recon_file"
type=PATH ... name="/etc/my.cnf"

설정에서 얻은 자격증명으로 DB·API 접근(E영역)이 이어지는지 연계합니다.

8. SOC 관제 포인트

• 설정 파일 읽기 전용·연속·자격증명 파일 집중을 정찰로 봅니다(작업=쓰기와 구분).
• .env·my.cnf 등 자격증명 포함 설정 열람은 C09(환경변수)와 함께 자격증명 수집으로 봅니다.
• 설정 조회가 계정·네트워크 정찰과 연속되면 정찰 수렴 단계로 판정합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,credential,">
  <rule id="102380" level="9">
    <if_group>audit</if_group>
    <field name="audit.key">recon_file</field>
    <regex type="pcre2">\.env|my\.cnf|application\.(yml|properties)|credentials</regex>
    <description>자격증명 포함 설정 파일 열람(자격증명 수집 정찰)</description>
    <mitre><id>T1552.001</id></mitre>
  </rule>
</group>

T1552.001(Credentials In Files)에 매핑됩니다. 설정 열람 + DB 접근(E영역)을 상관하면 자격증명 수집→악용을 포착합니다.

10. 대응 방법

1. 초기 확인 — 설정 조회의 대상(자격증명 파일 포함)·연속성·주체를 확인합니다.
2. 범위 확인 — 설정에서 얻은 자격증명으로 DB·API 접근(E영역)이 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름과 열람 설정 목록을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 노출 자격증명 교체를 진행합니다.
5. 재발 방지 — 설정 파일 열람을 자격증명 수집 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 140. Linux 정보 수집 — 프로세스·서비스·파일 정보 수집 종합 분석 에서는 4단계를 마무리하는 프로세스·서비스·파일 정보 수집 종합 분석을 다룹니다.

이전 편: 138. Linux 정보 수집 — 중요 파일 존재 여부 확인
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 38/50편 (전체 138/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 137. Linux 정보 수집 — 파일·디렉터리 구조 탐색 흔적
• 25. 중요 파일 권한 점검(linsec)

1. 개념

광범위 탐색(C37) 다음은 특정 중요 파일의 존재·속성 확인입니다. 공격자는 SSH 키·백업·DB 덤프·인증서 같은 고가치 파일이 실제로 있고, 읽을 수 있는지 확인해 탈취 대상을 특정합니다.

중요 파일 존재·속성 확인
 ls -l /path/to/key      → 존재·권한·소유자
 stat 파일               → 상세 속성(시각·inode)
 test -f 파일 && echo    → 존재 여부(스크립트)
 head -c 0 파일          → 읽기 가능 여부 확인

대상: ~/.ssh/id_rsa, *.pem, DB 덤프, backup.tar, .env, credentials

C37이 "광범위 탐색(무엇이 있나)"이라면, 이 편은 "특정 고가치 파일 확인(이게 있나, 읽을 수 있나)"입니다. E영역(중요 정보 접근)의 직접 선행입니다.

2. 왜 중요한가

• 중요 파일 존재·권한 확인은 탈취 대상 특정입니다. 읽기 가능하면 바로 접근(E영역)으로 이어집니다.
• 존재만 확인하고 접근은 나중에 하는 경우, 이 확인 단계가 조기 탐지 기회입니다.
• 특정 고가치 파일(키·.env·덤프)을 콕 집어 확인하는 것은 명확한 목표를 드러냅니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 중요 파일 접근 감사 (실습 예시) — 고가치 파일 읽기/속성 확인
-w /root/.ssh -p r -k recon_file
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/stat -F auid>=1000 -F auid!=unset -k recon_file

# 고가치 파일 대상 확인인지 (분석 방법)
sudo ausearch -k recon_file -i --start recent | grep -E 'id_rsa|\.pem|\.env|backup|dump|stat' | tail

5. 정상 상태

$ sudo ausearch -k recon_file -i --start today | grep stat | tail -1
11:10:02 auid=admin1 ses=8 comm="stat" (대상 /etc/httpd/conf/httpd.conf)  (설정 점검)

관리자가 특정 설정 파일 속성을 확인하는 단발 조회는 정상입니다. 고가치 파일(키·덤프)을 콕 집어 확인하는 것이 이상 신호입니다.

6. 이상 상태

02:16:25 auid=devops ses=12 comm="ls" (대상 /home/admin1/.ssh/id_rsa)
02:16:27 auid=devops ses=12 comm="stat" (대상 /var/backup/db_dump.sql)
02:16:29 auid=devops ses=12 comm="ls" (대상 /var/www/html/.env)

• SSH 키 + DB 덤프 + .env(자격증명) 존재·권한 확인 → 탈취 대상 특정
• 읽기 가능 여부 확인 → 바로 접근(E영역) 또는 권한 상승 후 접근 판단
• 광범위 탐색(C37)으로 찾은 파일을 콕 집어 확인 → 표적 확정

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

중요 파일 확인 → 탈취 준비 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="ls" a1="-l" a2="/home/admin1/.ssh/id_rsa"
type=SYSCALL ... auid=devops ses=12 comm="ls" key="recon_file"
type=EXECVE ... a0="stat" a1="/var/backup/db_dump.sql"

확인된 파일에 대한 실제 접근(E영역 중요 정보 접근)이 이어지는지 연계합니다.

8. SOC 관제 포인트

• 고가치 파일(키·덤프·.env)의 존재·권한 확인을 탈취 대상 특정으로 봅니다.
• 확인 뒤 실제 접근(E영역)·복사·유출이 이어지는지 연계 감시합니다.
• 광범위 탐색(C37)+표적 확인(C38)이 결합되면 데이터 탈취 임박으로 봅니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102370" level="9">
    <if_group>audit</if_group>
    <field name="audit.key">recon_file</field>
    <regex type="pcre2">(id_rsa|\.pem|\.key|\.env|db_dump|backup\.|credentials)</regex>
    <description>고가치 파일 존재·속성 확인(탈취 대상 특정)</description>
    <mitre><id>T1083</id></mitre>
  </rule>
</group>

표적 확인은 E영역(중요 정보 접근) 룰과 연계해 확인→접근을 포착합니다.

10. 대응 방법

1. 초기 확인 — 확인된 중요 파일(키·덤프·.env)·권한·주체를 확인합니다.
2. 범위 확인 — 확인 뒤 실제 접근·복사·유출(E영역)이 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름과 대상 파일 목록을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 해당 파일 접근 통제·자격증명 교체를 진행합니다.
5. 재발 방지 — 표적 파일 확인을 데이터 탈취 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 139. Linux 정보 수집 — 설정 파일 탐색 흔적 에서는 설정 탐색 정찰인 설정 파일 탐색 흔적을 다룹니다.

이전 편: 137. Linux 정보 수집 — 파일·디렉터리 구조 탐색 흔적
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 37/50편 (전체 137/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 136. Linux 정보 수집 — cron 관련 정보 수집
• 25. 중요 파일 권한 점검(linsec)

1. 개념

파일·디렉터리 탐색은 공격자가 "어디에 무엇이 있는가" 를 파악하는 광범위 정찰입니다. 민감 데이터·설정·쓰기 가능 위치를 찾습니다. 정상 작업은 특정 디렉터리를 보지만, 정찰은 광범위·재귀·전체 파일시스템을 훑습니다.

파일 탐색
 ls -laR /경로       → 재귀적 목록
 find / -name '*.conf'  → 전체 설정 파일 탐색
 find / -writable       → 쓰기 가능 위치
 find /home -name 'id_rsa' → SSH 키 탐색
 tree /경로          → 구조 시각화

정상: 특정 디렉터리 작업 / 정찰: 전체·재귀·패턴 기반 광범위 탐색

linsec 25편(중요 파일 권한 점검)이 방어라면, 여기서는 공격자가 파일을 광범위하게 탐색하는 정찰입니다.

2. 왜 중요한가

• 광범위 파일 탐색은 민감 데이터(개인정보·키·백업)·설정·쓰기 가능 위치(지속성 장소)를 한 번에 찾습니다.
• 전체 파일시스템 find는 부하가 크고 정상 운영에서 드물어, 그 자체로 탐지 가치가 높습니다(C27 SUID 탐색과 유사).
• 패턴 기반 탐색(*.conf, id_rsa, *.bak)은 명확한 목표(설정·키·백업)를 드러냅니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 파일 탐색 감사 (C27의 recon_priv와 별도 recon_file)
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/find -F auid>=1000 -F auid!=unset -k recon_file

# 광범위/패턴 탐색인지 (분석 방법) — find 인자 확인
sudo ausearch -k recon_file -i --start recent | grep 'find' | tail
sudo ausearch --session 12 -i 2>/dev/null | grep -A1 'comm="find"' | grep -E 'a[0-9]=' | tail

전체 find는 많으므로, 대상이 /·/home이거나 -name/-writable 패턴인 경우로 좁힙니다(147편).

5. 정상 상태

$ sudo ausearch -k recon_file -i --start today | grep find | tail -1
11:00:02 auid=admin1 ses=8 comm="find" a1="/var/log" a2="-name" a3="*.log"  (로그 작업)

관리자가 특정 디렉터리에서 특정 파일을 찾는 것은 정상입니다. 전체 파일시스템·민감 패턴 탐색이 이상 신호입니다.

6. 이상 상태

02:16:10 auid=devops ses=12 comm="find" a1="/" a2="-name" a3="*.conf"
02:16:15 auid=devops ses=12 comm="find" a1="/home" a2="-name" a3="id_rsa"
02:16:20 auid=devops ses=12 comm="find" a1="/" a2="-writable" a3="-type" a4="d"

• 전체 설정 파일 + SSH 키 + 쓰기 가능 디렉터리 탐색 → 민감 파일·지속성 위치 전수 조사
• id_rsa 탐색 → SSH 키 탈취 목표(E영역 중요 정보 접근)
• 쓰기 가능 위치 탐색 → 지속성·도구 배치 장소(F영역)

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

광범위 파일 탐색 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="find" a1="/" a2="-name" a3="*.conf"
type=SYSCALL ... auid=devops ses=12 comm="find" key="recon_file"
type=EXECVE ... a0="find" a1="/home" a2="-name" a3="id_rsa"

발견된 민감 파일 접근(E영역)·쓰기 위치 사용(F영역)이 이어지는지 연계합니다.

8. SOC 관제 포인트

• 광범위·패턴 기반 파일 탐색을 민감 파일·지속성 위치 정찰로 봅니다.
• id_rsa·*.bak·*.conf 등 민감 패턴 탐색은 명확한 목표를 드러내 우선순위를 높입니다.
• 탐색 뒤 민감 파일 접근(E영역)·쓰기 위치 사용(F영역)을 연계 감시합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102360" level="9">
    <if_group>audit</if_group>
    <field name="audit.key">recon_file</field>
    <regex type="pcre2">a0="find".*(-name.*(id_rsa|\.key|\.pem|\.bak|shadow)|-writable)</regex>
    <description>민감 파일·쓰기 위치 광범위 탐색</description>
    <mitre><id>T1083</id></mitre>
  </rule>
</group>

T1083(File and Directory Discovery)에 매핑됩니다. 파일 탐색은 파일 정찰 세트(140편)·E영역과 연계합니다.

10. 대응 방법

1. 초기 확인 — 파일 탐색의 범위(전체/특정)·패턴·주체를 확인합니다.
2. 범위 확인 — 발견된 민감 파일 접근(E영역)·쓰기 위치 사용(F영역)이 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름과 탐색 패턴을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 민감 파일 권한 점검(linsec 25편)을 진행합니다.
5. 재발 방지 — 파일 탐색을 파일 정찰·E영역 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 138. Linux 정보 수집 — 중요 파일 존재 여부 확인 에서는 표적 확인 정찰인 중요 파일 존재 여부 확인을 다룹니다.

이전 편: 136. Linux 정보 수집 — cron 관련 정보 수집
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 36/50편 (전체 136/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 135. Linux 정보 수집 — systemd 서비스 정보 수집
• 026. cron·at 접근 제어 점검(A영역)
• 31. Cron 기반 지속성 탐지(linsec)

1. 개념

cron은 systemd와 함께 대표적 지속성 수단입니다. 공격자는 예약 작업 구조(어디에 등록되고, 어떤 작업이 이미 있는가)를 조회해 악성 예약 작업 등록 위치를 물색합니다.

cron 구조 조회
 crontab -l             → 현재 사용자 crontab
 ls /etc/cron.d/        → 시스템 cron 작업(A영역 26편)
 cat /etc/crontab       → 시스템 crontab
 ls /var/spool/cron/    → 사용자별 crontab
 ls /etc/cron.{hourly,daily,...} → 주기 작업 디렉터리

목적: 악성 cron을 어디에 등록할지, 기존 작업에 섞을 수 있는지 파악

A영역 26편(cron 접근 제어)·linsec 31편(cron 지속성 탐지)이 방어라면, 여기서는 공격자가 등록 위치를 조회하는 정찰입니다.

2. 왜 중요한가

• cron 기반 지속성(F영역·linsec 31편)은 재부팅·세션 종료 후에도 실행돼, 공격자가 선호합니다.
• 기존 cron 작업을 조회해 그 작업에 섞거나 비슷하게 위장하면 눈에 덜 띕니다.
• cron 디렉터리 조회 직후 예약 작업 생성(A영역 26편·F영역)이 이어지면 지속성 확보입니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# cron 구조 조회 감사 (실습 예시)
-w /etc/cron.d -p r -k recon_persist
-w /etc/crontab -p r -k recon_persist
-w /var/spool/cron -p r -k recon_persist
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/crontab -F a1="-l" -k recon_persist

# 세션에서 cron 구조 조회 (분석 방법)
sudo ausearch -k recon_persist -i --start recent | grep -E 'cron|crontab' | tail

5. 정상 상태

$ sudo ausearch -k recon_persist -i --start today | grep cron | tail -1
10:20:02 auid=admin1 ses=8 comm="crontab" a1="-l"  (예약 작업 점검)

관리자가 자기 예약 작업을 점검하는 crontab -l은 정상입니다(A영역 26편 점검 포함).

6. 이상 상태

02:16:00 auid=devops ses=12 comm="crontab" a1="-l"
02:16:02 auid=devops ses=12 comm="ls" (대상 /etc/cron.d/)
02:16:04 auid=devops ses=12 comm="cat" name="/etc/crontab"

• 사용자 crontab + 시스템 cron.d + crontab 연속 조회 → 예약 작업 등록 위치 전수 파악
• 기존 작업 확인 후 그에 섞을 악성 예약 작업 등록(A영역 26편·F영역) 가능성
• systemd 정찰(C35)에 이어 cron 정찰 → 지속성 수단 전수 조사

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

cron 구조 정찰 → 지속성 준비 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="crontab" a1="-l"
type=SYSCALL ... auid=devops ses=12 comm="crontab" key="recon_persist"
type=PATH ... name="/etc/cron.d/" nametype=NORMAL
[이후 가능] /etc/cron.d/<악성> 또는 crontab 등록 (A영역 26편 100320, F영역)

cron 조회 직후 예약 작업 등록(A영역 26편 100320)이 나타나면 지속성 확보로 연계 탐지합니다.

8. SOC 관제 포인트

• cron 구조 조회는 지속성 등록 위치 물색 관점으로 봅니다(systemd C35와 묶음).
• cron 조회 직후 예약 작업 등록(A영역 26편·F영역)이 이어지는지 연계합니다.
• 지속성 정찰(systemd+cron)이 결합되면 지속성 확보 임박으로 봅니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102350" level="7">
    <if_group>audit</if_group>
    <field name="audit.key">recon_persist</field>
    <regex type="pcre2">cron|crontab</regex>
    <description>cron 예약 작업 구조 조회(지속성 등록 정찰)</description>
    <mitre><id>T1053.003</id></mitre>
  </rule>
</group>

T1053.003(Cron)에 매핑됩니다. cron 조회 + 등록(A영역 26편 100320)을 상관하면 지속성 준비→확보를 포착합니다.

10. 대응 방법

1. 초기 확인 — cron 구조 조회의 범위·주체와 이후 예약 작업 등록 여부를 확인합니다.
2. 범위 확인 — cron 조회 직후 등록(A영역 26편·F영역)이 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름과 cron 디렉터리 상태를 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 cron FIM 점검을 진행합니다.
5. 재발 방지 — cron 정찰을 지속성 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 137. Linux 정보 수집 — 파일·디렉터리 구조 탐색 흔적 에서는 파일 탐색 정찰인 파일·디렉터리 구조 탐색 흔적을 다룹니다.

이전 편: 135. Linux 정보 수집 — systemd 서비스 정보 수집
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 35/50편 (전체 135/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 134. Linux 정보 수집 — 서비스 목록 조회
• 27. systemd 보안 옵션(A영역)
• 30. 악성 systemd 서비스 탐지(linsec)

1. 개념

서비스 목록(C34)보다 깊게, systemd 유닛 파일의 구조·경로를 조회하는 정찰입니다. 공격자는 유닛 파일이 어디에 있고(/etc/systemd/system), 어떻게 작성되는지 파악해 악성 유닛 등록(지속성, F영역) 위치를 물색합니다.

systemd 구조 조회
 systemctl cat 서비스        → 유닛 파일 내용(작성 예시 학습)
 ls /etc/systemd/system/     → 유닛 파일 위치
 systemctl list-unit-files   → 유닛 파일 목록
 ~/.config/systemd/user/     → 사용자 유닛(B영역 40편)

목적: 악성 유닛을 어디에·어떻게 등록할지 파악 (지속성 준비)

A영역 27편(systemd 보안 옵션)·linsec 30편(악성 systemd 탐지)이 방어라면, 여기서는 공격자가 등록 위치·방법을 조회하는 정찰입니다.

2. 왜 중요한가

• systemd 유닛 등록은 대표적 지속성 수단(F영역)입니다. 공격자는 기존 유닛을 참고해 정상처럼 보이는 악성 유닛을 만듭니다.
• 사용자 유닛(~/.config/systemd/user)·linger(B영역 40편) 경로 조회는 일반 권한 지속성 준비입니다.
• systemd 구조 정찰 뒤 유닛 파일 생성(F영역)이 이어지면 지속성 확보로 판정합니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# systemd 구조 조회 감사 (실습 예시)
-w /etc/systemd/system -p r -k recon_svc
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/systemctl -F a1="cat" -k recon_svc

# 세션에서 유닛 구조 조회 (분석 방법)
sudo ausearch -k recon_svc -i --start recent | grep -E 'systemd/system|a1="cat"' | tail

5. 정상 상태

$ sudo ausearch -k recon_svc -i --start today | grep 'systemd/system' | tail -1
10:10:02 auid=admin1 ses=8 comm="systemctl" a1="cat"  (유닛 점검)

관리자가 서비스 유닛을 점검·수정하며 systemctl cat을 보는 것은 정상입니다(A영역 27편 점검 포함).

6. 이상 상태

02:15:50 auid=devops ses=12 comm="systemctl" a1="cat" a2="httpd"
02:15:52 auid=devops ses=12 comm="ls" (대상 /etc/systemd/system/)

• 정상 유닛(systemctl cat httpd) 내용 확인 + 유닛 디렉터리 조회 → 악성 유닛 작성 준비
• 기존 유닛을 참고해 정상처럼 위장한 유닛 생성(A영역 13·27편·F영역) 가능성
• 서비스 목록(C34)에 이어 등록 위치·방법 정찰 → 지속성 준비

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

systemd 구조 정찰 → 지속성 준비 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="systemctl" a1="cat" a2="httpd"
type=SYSCALL ... auid=devops ses=12 comm="systemctl" key="recon_svc"
type=PATH ... name="/etc/systemd/system/" nametype=NORMAL
[이후 가능] /etc/systemd/system/<악성>.service 생성 (A영역 13편 100200, F영역)

유닛 조회 직후 유닛 파일 생성(A영역 13편 100200)이 나타나면 지속성 확보로 연계 탐지합니다.

8. SOC 관제 포인트

• systemd 구조 조회는 악성 유닛 등록 위치·방법 물색 관점으로 봅니다.
• 유닛 조회 직후 유닛 파일 생성(A영역 13편·F영역)이 이어지는지 연계합니다.
• 사용자 유닛·linger(B영역 40편) 경로 조회는 일반 권한 지속성 준비로 봅니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102340" level="7">
    <if_group>audit</if_group>
    <field name="audit.key">recon_svc</field>
    <regex type="pcre2">a1="cat"|/etc/systemd/system</regex>
    <description>systemd 유닛 구조 조회(지속성 등록 정찰)</description>
    <mitre><id>T1543.002</id></mitre>
  </rule>
</group>

T1543.002(Systemd Service)에 매핑됩니다. 유닛 조회 + 생성(A영역 13편 100200)을 상관하면 지속성 준비→확보를 포착합니다.

10. 대응 방법

1. 초기 확인 — systemd 구조 조회의 대상·주체와 이후 유닛 생성 여부를 확인합니다.
2. 범위 확인 — 유닛 조회 직후 악성 유닛 등록(A영역 13편·F영역)이 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름과 유닛 디렉터리 상태를 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 유닛 디렉터리 FIM 점검을 진행합니다.
5. 재발 방지 — systemd 정찰을 지속성 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 136. Linux 정보 수집 — cron 관련 정보 수집 에서는 예약 작업 지속성 정찰인 cron 관련 정보 수집을 다룹니다.

이전 편: 134. Linux 정보 수집 — 서비스 목록 조회
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 34/50편 (전체 134/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 133. Linux 정보 수집 — 실행 파일 경로 확인
• 013. 불필요한 서비스 식별과 비활성화(A영역)

1. 개념

서비스 목록 조회는 공격자가 "어떤 서비스가 돌고, 어디에 기생·등록할 수 있는가" 를 파악하는 정찰입니다. 프로세스(C31)가 "지금 돌고 있는 것"이라면, 서비스 목록은 등록된 구성·자동 시작까지 보여줍니다.

서비스 조회
 systemctl list-units --type=service   → 실행 중 서비스
 systemctl list-unit-files             → 자동 시작 포함 전체(A영역 13편)
 systemctl status 서비스               → 특정 서비스 상세
 service --status-all                  → (구형) 서비스 상태

목적: 공격 표면(DB·웹), 보안 서비스(wazuh·auditd), 지속성 등록 대상(systemd, C35) 파악

A영역 13편이 "불필요한 서비스 식별"(방어)이라면, 여기서는 공격자가 서비스 구성을 조회하는 정찰입니다.

2. 왜 중요한가

• 서비스 목록으로 공격자는 공격 표면(DB·웹)과 보안 서비스를 함께 파악합니다(C31 프로세스 정찰 보완).
• systemd 서비스 구조를 알면, 악성 서비스 등록(C35·F영역 지속성)의 위장 대상을 고릅니다.
• 보안 서비스(wazuh·auditd) 상태 조회는 C31과 함께 탐지 회피 준비 신호입니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 서비스 조회 감사 (실습 예시)
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/systemctl -F auid>=1000 -F auid!=unset -k recon_svc

# 세션에서 서비스 조회 흐름 (분석 방법) — 보안 서비스 조회 포함 여부
sudo ausearch -k recon_svc -i --start recent | grep -E 'systemctl|list-unit' | tail
sudo ausearch --session 12 -i 2>/dev/null | grep -iE 'systemctl.*(status|list)|wazuh|auditd' | tail

5. 정상 상태

$ sudo ausearch -k recon_svc -i --start today | grep systemctl | tail -1
10:00:02 auid=admin1 ses=8 comm="systemctl" (status httpd)  (서비스 점검)

관리자가 서비스 상태를 점검·관리하는 systemctl status/list는 매우 흔하고 정상입니다. 차이는 전수 조회·보안 서비스 조준입니다.

6. 이상 상태

02:15:40 auid=devops ses=12 comm="systemctl" (list-unit-files)
02:15:43 auid=devops ses=12 comm="systemctl" (status wazuh-agent)
02:15:45 auid=devops ses=12 comm="systemctl" (status auditd)

• 전체 서비스(list-unit-files) + 보안 서비스(wazuh·auditd) 상태 조회 → 공격 표면·보안 서비스 파악
• 보안 서비스 조회(C31 프로세스 정찰과 중복 확인) → 탐지 회피 준비
• 이후 systemd 서비스 정보(C35)·악성 서비스 등록(F영역)으로 이어질 수 있음

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

서비스 정찰 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="systemctl" a1="list-unit-files"
type=SYSCALL ... auid=devops ses=12 comm="systemctl" key="recon_svc"
type=EXECVE ... a0="systemctl" a1="status" a2="wazuh-agent"

보안 서비스 조회 직후 중지(A영역 39편)·악성 서비스 등록(F영역)이 이어지는지 연계합니다.

8. SOC 관제 포인트

• 서비스 목록 조회 중 보안 서비스 조준은 C31과 함께 회피 준비로 봅니다.
• 전체 서비스 전수 조회는 공격 표면·지속성 등록 대상 파악 정찰입니다.
• 서비스 정찰 뒤 systemd 정보(C35)·악성 등록(F영역)을 연계 감시합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102330" level="7">
    <if_group>audit</if_group>
    <field name="audit.key">recon_svc</field>
    <regex type="pcre2">list-unit|status.*(wazuh|auditd|falco)</regex>
    <description>서비스 구성·보안 서비스 조회</description>
    <mitre><id>T1518.001</id></mitre>
  </rule>
</group>

보안 서비스 조회는 C31(프로세스)과 함께 회피 탐지 상관에, 전체 조회는 프로세스 정찰 세트(140편)에 포함합니다.

10. 대응 방법

1. 초기 확인 — 서비스 조회의 범위(전수/특정)·보안 서비스 포함 여부·주체를 확인합니다.
2. 범위 확인 — 보안 서비스 조회 뒤 중지(A영역 39편)·악성 등록(F영역)이 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 서비스·보안 솔루션 점검을 진행합니다.
5. 재발 방지 — 서비스 정찰을 회피·프로세스 정찰 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 135. Linux 정보 수집 — systemd 서비스 정보 수집 에서는 systemd 구조 정찰인 systemd 서비스 정보 수집을 다룹니다.

이전 편: 133. Linux 정보 수집 — 실행 파일 경로 확인
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 33/50편 (전체 133/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 132. Linux 정보 수집 — 프로세스 트리 확인 분석
• 24. 보안 패치·업데이트 상태(A영역)

1. 개념

공격자는 침입한 서버에 어떤 도구가 이미 있는가(추가 설치 없이 쓸 수 있는 것)를 확인합니다. 컴파일러(gcc)·인터프리터(python·perl)·네트워크 도구(curl·wget·nc)의 존재는 공격 가능성을 좌우합니다. 이를 LOLBins(Living off the Land) 탐색이라 합니다.

도구 존재 확인
 which gcc python3 curl   → 경로 확인(있으면 사용 가능)
 whereis nc socat         → 바이너리 위치
 type -a python           → 셸이 찾는 경로
 /proc/[PID]/exe          → 실행 중 바이너리 경로

목적: 추가 설치(A영역 24편 탐지) 없이 기존 도구로 공격
      → 설치 흔적을 남기지 않는 LOLBins 전략

A영역 24편이 "도구 설치 탐지"였다면, 여기서는 설치 없이 기존 도구를 탐색하는 정찰입니다. 설치보다 조용합니다.

2. 왜 중요한가

• 기존 도구(LOLBins)를 쓰면 설치 로그(A영역 24편)를 남기지 않아 탐지가 어렵습니다. 그래서 도구 탐색 단계가 탐지 기회입니다.
• gcc 존재 확인은 커널 익스플로잇 컴파일 가능성(C02 커널 정찰과 연계)을, curl/nc 존재는 외부 통신·데이터 유출 가능성을 시사합니다.
• 짧은 시간에 여러 도구를 which로 확인하는 패턴은 LOLBins 탐색의 전형입니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 도구 탐색 감사 (실습 예시)
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/which -F auid>=1000 -F auid!=unset -k recon_tool
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/whereis -F auid>=1000 -F auid!=unset -k recon_tool

# 짧은 시간 다수 도구 탐색인지 (분석 방법)
sudo ausearch -k recon_tool -i --start recent | grep -E 'which|whereis' | tail
sudo ausearch --session 12 -i 2>/dev/null | grep -E 'which|whereis' | tail -10

5. 정상 상태

$ sudo ausearch -k recon_tool -i --start today | grep which | tail -1
11:00:02 auid=admin1 ses=8 comm="which" a1="python3"  (스크립트 작업)

관리자가 작업 중 특정 도구 경로를 확인하는 단발 which는 정상입니다. 다수 도구 연속 확인이 이상 신호입니다.

6. 이상 상태

02:15:30 auid=devops ses=12 comm="which" a1="gcc"
02:15:31 auid=devops ses=12 comm="which" a1="python3"
02:15:32 auid=devops ses=12 comm="which" a1="curl"
02:15:33 auid=devops ses=12 comm="which" a1="nc"

• gcc·python·curl·nc를 4초 내 연속 탐색 → LOLBins 전수 조사
• 컴파일러·인터프리터·네트워크 도구 조합 → 공격 역량 파악
• 설치(A영역 24편) 없이 기존 도구 탐색 → 조용한 준비

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

도구 탐색 정찰 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="which" a1="gcc"
type=SYSCALL ... auid=devops ses=12 comm="which" key="recon_tool"
type=EXECVE ... a0="which" a1="nc"

탐색 뒤 그 도구를 이용한 행위(F영역 비정상 프로세스·외부 연결)가 이어지는지 연계합니다.

8. SOC 관제 포인트

• 짧은 시간 다수 도구 연속 탐색(which/whereis)을 LOLBins 정찰로 봅니다.
• gcc·인터프리터·네트워크 도구 조합 탐색은 공격 역량 파악 신호입니다.
• 탐색 뒤 해당 도구 사용(F영역)·외부 통신(C16)을 연계 감시합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102320" level="8" frequency="4" timeframe="60">
    <if_group>audit</if_group>
    <field name="audit.key">recon_tool</field>
    <same_field field="audit.session" />
    <description>단시간 다수 도구 경로 탐색(LOLBins 정찰)</description>
    <mitre><id>T1518</id></mitre>
  </rule>
</group>

T1518(Software Discovery)에 매핑됩니다. 도구 탐색은 프로세스 정찰 세트(140편)에 포함합니다.

10. 대응 방법

1. 초기 확인 — 도구 탐색의 종류·밀도·주체와 탐색된 도구(gcc·nc 등)를 확인합니다.
2. 범위 확인 — 탐색 뒤 해당 도구 사용·외부 통신(F·C16)이 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 불필요 도구 제거를 검토합니다.
5. 재발 방지 — 도구 탐색을 프로세스 정찰 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 134. Linux 정보 수집 — 서비스 목록 조회 에서는 서비스 구성 정찰인 서비스 목록 조회를 다룹니다.

이전 편: 132. Linux 정보 수집 — 프로세스 트리 확인 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 32/50편 (전체 132/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 131. Linux 정보 수집 — 프로세스 목록 조회 흔적
• 28. 프로세스 트리 기반 침해 분석(linsec)

1. 개념

프로세스 트리는 "어떤 프로세스가 무엇을 낳았는가(부모-자식)" 를 보여줍니다. 공격자는 자기 프로세스의 계보를 확인해 은닉 가능성을 재거나, 데몬을 부모로 둔 프로세스(서비스 침해 흔적)를 파악합니다.

프로세스 트리 조회
 pstree -p           → 트리(PID 포함)
 ps -ejH / ps axjf   → 계층 구조
 /proc/[PID]/stat    → PPID(부모)

관점
 - 자기 셸의 부모가 무엇인가(sshd? httpd? → 은닉 여부)
 - 데몬 → 셸 계보(B영역 35편 서비스 침해)
 - 고아 프로세스(PPID=1)로 재부모화해 은닉

linsec 28편이 "프로세스 트리 기반 침해 분석"(방어)이라면, 여기서는 공격자가 트리를 조회하는 정찰입니다.

2. 왜 중요한가

• 공격자는 자기 프로세스가 어떻게 보이는지(부모가 sshd인지, 데몬인지)를 확인해 은닉 전략을 세웁니다.
• PPID=1(init)로 재부모화된 프로세스는 백그라운드 지속성(F영역)의 단서이며, 공격자가 이를 미리 확인합니다.
• 데몬→셸 계보 조회는 서비스 침해(B영역 35편)의 자기 점검일 수 있습니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 프로세스 트리 조회 감사 (실습 예시)
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/pstree -F auid>=1000 -F auid!=unset -k recon_proc

# 세션에서 트리 조회 (분석 방법)
sudo ausearch -k recon_proc -i --start recent | grep -E 'pstree|ps.*axjf|ps.*ejH' | tail

5. 정상 상태

$ sudo ausearch -k recon_proc -i --start today | grep pstree | tail -1
10:00:02 auid=admin1 ses=8 comm="pstree"  (프로세스 관계 점검)

관리자가 프로세스 관계·부하 원인을 점검하는 단발 조회는 정상입니다.

6. 이상 상태

02:15:20 auid=devops ses=12 comm="pstree" a1="-p"
02:15:22 auid=devops ses=12 comm="cat" name="/proc/12901/stat" (자기 셸 PPID 확인)

• 트리 조회 + 자기 셸의 PPID 확인 → 프로세스 계보·은닉 가능성 점검
• 자기 셸의 부모가 sshd인지 확인 → 세션 노출 여부 파악
• 프로세스 목록(C31)에 이어 관계 정찰 → 은닉 전략 수립

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

프로세스 트리 정찰 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="pstree" a1="-p"
type=SYSCALL ... auid=devops ses=12 comm="pstree" key="recon_proc"
type=PATH ... name="/proc/12901/stat" nametype=NORMAL

이후 재부모화·백그라운드 은닉(F영역)이 나타나는지 연계합니다.

8. SOC 관제 포인트

• 프로세스 트리 조회는 자기 계보 확인·은닉 점검 관점으로 봅니다.
• 트리 조회 뒤 재부모화·백그라운드 지속성(F영역)이 이어지는지 연계합니다.
• 프로세스 목록(C31)+트리(C32) 조회를 묶어 프로세스 정찰로 봅니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102310" level="6">
    <if_group>audit</if_group>
    <field name="audit.key">recon_proc</field>
    <regex type="pcre2">a0="pstree"|a0="ps".*axjf</regex>
    <description>프로세스 트리·계보 조회</description>
    <mitre><id>T1057</id></mitre>
  </rule>
</group>

T1057(Process Discovery)에 매핑됩니다. 프로세스 정찰 세트(140편)에 포함합니다.

10. 대응 방법

1. 초기 확인 — 트리 조회의 대상(자기/전체)·연속성·주체를 확인합니다.
2. 범위 확인 — 트리 조회 뒤 재부모화·은닉(F영역)이 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 프로세스 점검을 진행합니다.
5. 재발 방지 — 프로세스 트리 조회를 프로세스 정찰 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 133. Linux 정보 수집 — 실행 파일 경로 확인 에서는 실행 파일 정찰인 실행 파일 경로 확인을 다룹니다.

이전 편: 131. Linux 정보 수집 — 프로세스 목록 조회 흔적
📚 시리즈 전체 보기: 시스템 보안 · 취약점

시스템 보안 · 취약점 › C. Linux 정보 노출 및 수집 · 31/50편 (전체 131/450) 학습 단계: 프로세스·서비스·파일 정보 수집 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 130. Linux 정보 수집 — 사용자·권한 정보 수집 종합 분석
• 26. Linux 프로세스 보안(linsec)
• 27. 의심 프로세스 탐지(linsec)

1. 개념

프로세스 목록 조회는 공격자가 "이 서버에서 무엇이 돌고 있는가" 를 파악하는 정찰입니다. 특히 보안 솔루션(Wazuh agent·백신·EDR) 의 실행 여부를 확인해 탐지 회피를 준비하거나, 다른 사용자 활동을 관찰합니다.

프로세스 조회
 ps aux / ps -ef        → 전체 프로세스(사용자·명령)
 /proc/[PID]/           → 프로세스 상세(cmdline·exe)
 top / htop             → 실시간 프로세스

목적
 - 보안 솔루션 실행 여부(wazuh·auditd·falco) → 회피 준비
 - 서비스·DB 프로세스 → 공격 표면
 - 다른 사용자 프로세스 → 활동 관찰

linsec 26·27편이 "프로세스 보안·의심 프로세스 탐지"(방어)라면, 여기서는 공격자가 프로세스 목록을 조회하는 정찰입니다.

2. 왜 중요한가

• 공격자가 ps로 Wazuh agent·auditd를 확인하면, 이후 그것을 중지(A영역 39편 하드닝 해제)하려 할 수 있습니다.
• 전체 프로세스 조회는 서비스·DB 등 공격 표면과 다른 사용자 활동을 한 번에 드러냅니다.
• 보안 솔루션 프로세스 조회 직후 그 솔루션 중지가 이어지면, 탐지 회피의 강한 신호입니다.

3. 핵심 명령어 / 설정

4. 실습 (실습 예시)

# 프로세스 조회 감사 (실습 예시)
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ps -F auid>=1000 -F auid!=unset -k recon_proc
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/pgrep -F auid>=1000 -F auid!=unset -k recon_proc

# 보안 솔루션 프로세스를 조회했는지 (분석 방법)
sudo ausearch -k recon_proc -i --start recent | grep -E 'comm="ps"|comm="pgrep"' | tail
sudo ausearch --session 12 -i 2>/dev/null | grep -iE 'wazuh|auditd|pgrep|ps ' | tail

5. 정상 상태

$ sudo ausearch -k recon_proc -i --start today | grep 'comm="ps"' | tail -1
09:30:02 auid=admin1 ses=8 comm="ps"  (서비스 상태 점검)

관리자가 서비스 상태·부하를 점검하며 ps를 보는 것은 매우 흔하고 정상입니다. 차이는 보안 솔루션 조준·연속 정찰입니다.

6. 이상 상태

02:15:10 auid=devops ses=12 comm="ps" a1="aux"
02:15:12 auid=devops ses=12 comm="pgrep" a1="wazuh"
02:15:14 auid=devops ses=12 comm="pgrep" a1="auditd"

• 전체 프로세스(ps aux) + 보안 솔루션 특정 조회(pgrep wazuh, pgrep auditd) → 탐지 회피 준비
• Wazuh·auditd 실행 확인 후 중지(A영역 39편)로 이어질 위험
• 계정·권한 정찰(C21~30)에 이어 프로세스 정찰 → 환경 장악 파악

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

프로세스 정찰 → 회피 준비 흐름입니다(가상의 예시 로그).

type=EXECVE ... a0="ps" a1="aux"
type=SYSCALL ... auid=devops ses=12 comm="ps" key="recon_proc"
type=EXECVE ... a0="pgrep" a1="wazuh-agentd"
[이후 가능] systemctl stop wazuh-agent (A영역 39편 하드닝 해제)

보안 솔루션 조회 직후 중지가 나타나면 A영역 39편(하드닝 해제)과 연계해 탐지합니다.

8. SOC 관제 포인트

• 프로세스 조회 중 보안 솔루션(wazuh·auditd·falco) 특정 조회를 최우선 확인합니다.
• 보안 솔루션 조회 직후 중지(A영역 39편)로 이어지는지 연계 감시합니다.
• 전체 프로세스 조회는 흔하므로, 보안 솔루션 조준·연속 정찰로 좁혀 판정합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_c,recon,">
  <rule id="102300" level="9">
    <if_group>audit</if_group>
    <field name="audit.key">recon_proc</field>
    <regex type="pcre2">a1="?(wazuh|auditd|falco|clamav|osquery)</regex>
    <description>보안 솔루션 프로세스 조회(탐지 회피 준비)</description>
    <mitre><id>T1518.001</id></mitre>
  </rule>
</group>

T1518.001(Security Software Discovery)에 매핑됩니다. 보안 솔루션 조회(102300) + 중지(A영역 39편)를 상관하면 회피를 포착합니다.

10. 대응 방법

1. 초기 확인 — 프로세스 조회의 대상(보안 솔루션 포함)·연속성·주체를 확인합니다.
2. 범위 확인 — 보안 솔루션 조회 직후 중지(A영역 39편)가 이어졌는지 확인합니다.
3. 증거 확보 — 세션 조회 흐름을 보존합니다.
4. 차단/조치 — 탈취 세션이면 B영역 대응과 보안 솔루션 상태 점검을 진행합니다.
5. 재발 방지 — 보안 솔루션 조회를 회피 탐지 상관에 포함합니다.

11. 핵심 정리

12. 다음 편 예고

다음 편 132. Linux 정보 수집 — 프로세스 트리 확인 분석 에서는 프로세스 관계 정찰인 프로세스 트리 확인 분석을 다룹니다.

이전 편: 130. Linux 정보 수집 — 사용자·권한 정보 수집 종합 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점