시스템 보안 · 취약점 › I. 지속성 · 재침투 징후 · 20/50편 (전체 420/450)
학습 단계: 스케줄·서비스·부팅 지속성 탐지
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.
선행 학습
1. 개념
at은 한 번만 실행되는 예약이라 지속성과 거리가 멀어 보이지만, 며칠 뒤 지속성을 다시 설치하는 시한 장치로 쓰일 수 있습니다(T1053.002). 사고 대응이 끝난 뒤에 실행되도록 시간을 맞추는 것이 특징입니다.
at 지연 실행 시나리오
D+0 침투 → echo "/tmp/.r/install.sh" | at now + 10 days
D+1 관제 탐지 → 키·cron 제거 → 사고 종료
D+10 at 작업 실행 → 지속성 재설치 → 재침투
위치: /var/spool/at/ (RHEL) · /var/spool/cron/atjobs/ (Ubuntu)
핵심: 근절 체크리스트에 at 큐가 없으면 "시한 장치"를 놓친다at 작업은 실행 시점의 환경 변수와 작업 디렉터리까지 파일에 저장하므로, spool 파일을 열면 예약한 사람의 세션 정보를 상당 부분 알 수 있습니다.
2. 왜 중요한가
- cron 점검만 하는 근절 절차는 at 큐를 놓칩니다.
- 지연 실행은 사고 종료 후 재침투를 만들어 "근절 실패"로 이어집니다.
- at 사용은 일반 서버에서 드물어 존재 자체가 신호입니다.
3. 핵심 명령어 / 설정
| 확인 | 명령 | 포인트 |
|---|---|---|
| 대기 작업 | atq | 실행 예정 시각 |
| 작업 내용 | at -c <job> | 마지막 줄 명령 |
| spool | ls -la /var/spool/at/ | 생성 시각·소유자 |
| 서비스 | systemctl is-enabled atd | 필요 여부 |
4. 실습 (실습 예시)
# at 큐 점검 (분석 방법)
systemctl is-active atd
sudo atq
for j in $(sudo atq | awk '{print $1}'); do echo "== job $j"; sudo at -c "$j" | tail -5; done
sudo ls -la --time-style=full-iso /var/spool/at/ /var/spool/cron/atjobs/ 2>/dev/null
sudo ausearch -k persist_cron -f /var/spool/at -i 2>/dev/null | grep -E 'auid=|exe=' | tail5. 정상 상태
$ atq
(대기 작업 없음)
atd: inactive (사용 안 함)at을 쓰지 않는 서버는 atd가 비활성이고 큐가 비어 있는 것이 정상입니다. 사용한다면 작업마다 승인 기록이 있어야 합니다.
6. 이상 상태
$ atq
7 Mon Oct 19 03:00:00 2026 a webadmin
$ at -c 7 | tail -2
cd /var/tmp/.r || { echo 'Execution directory inaccessible' >&2; exit 1; }
/bin/bash /var/tmp/.r/install.sh- 10일 뒤 새벽으로 예약된 작업 → 사고 종료 이후를 노린 시한 장치
- 숨김 디렉터리의 설치 스크립트 실행 → 지속성 재설치
- 침해 의심 계정이 예약 → 정탐
7. 로그 분석 (분석 방법)
at 지연 실행 분석 흐름입니다(가상의 예시).
[큐 확인] atq → 예약 시각·계정
↓
[내용] at -c → 실행 디렉터리·명령
↓
[작성 시점] spool 파일 생성 시각 ↔ 침투 타임라인
↓
[파급] 실행 대상 스크립트가 설치하는 지속성| 항목 | 단서 |
|---|---|
| 예약 시각 | 근절 이후 시점 |
| 작업 디렉터리 | 숨김 경로 |
| 환경 변수 | 예약자 세션 정보 |
at -c 출력의 환경 변수(SSH_CLIENT 등)에 예약자의 접속 출발지가 남는 경우가 있어 출발지 확인에 활용할 수 있습니다.
8. SOC 관제 포인트
- 근절 체크리스트에 atq 확인을 반드시 포함합니다.
- at을 쓰지 않는 서버는 atd를 비활성화하고 at.deny로 사용을 제한합니다.
- at 작업 생성 이벤트는 사용 빈도가 낮아 전부 경보로 다룹니다.
9. 탐지 규칙
<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_i,persistence,">
<rule id="108190" level="11">
<if_sid>108000</if_sid>
<field name="audit.key">persist_cron</field>
<field name="audit.file.name" type="pcre2">^/var/spool/(at|cron/atjobs)/</field>
<description>at 예약 작업 생성(지연 실행 지속성 의심)</description>
<mitre><id>T1053.002</id></mitre>
</rule>
</group>at spool 디렉터리를 cron과 같은 감사 키로 감시하고 경로로 구분합니다. at 사용이 없는 환경에서는 레벨을 더 높여도 됩니다.
10. 대응 방법
- 초기 확인 — 대기 작업의 예약 시각·계정·명령을 확인합니다.
- 범위 확인 — 실행 대상 스크립트와 그것이 설치하는 지속성을 확인합니다.
- 증거 확보 — at 작업 내용(at -c 출력)과 spool 파일을 보존합니다.
- 차단/조치 —
atrm으로 작업을 제거하고 스크립트를 격리합니다. - 재발 방지 — atd 비활성화·at.deny 적용, 근절 체크리스트에 at 큐를 추가합니다.
11. 핵심 정리
| 항목 | 확인 |
|---|---|
| 큐 | atq |
| 내용 | at -c |
| 위험 | 근절 이후 실행 |
| 예방 | atd 비활성·at.deny |
| 면접 포인트 | "at은 근절 이후를 노린 시한 장치 — 체크리스트에 atq를 넣는다" |
12. 다음 편 예고
다음 편 421. 지속성·재침투 — systemd 서비스 지속성 탐지 에서는 /etc/systemd/system에 등록한 악성 서비스 유닛을 enable 기록·유닛 내용·실행 경로로 탐지하고 정상 서비스와 구분하는 방법을 다룹니다.
이전 편: 419. 지속성·재침투 — cron 기반 지속성 탐지
📚 시리즈 전체 보기: 시스템 보안 · 취약점
