434. 지속성·재침투 — 신뢰 관계 악용 재침투 탐지

changseop lee·2026년 10월 9일

Soc sshAgent 리눅스 보안관제 시스템 보안 · 취약점 시스템보안 신뢰관계 지속성·재침투

시스템 보안 · 취약점

목록 보기

434/450

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

선행 학습

1. 개념

서버들은 서로를 신뢰하는 설정으로 묶여 있는 경우가 많습니다. 공격자는 한 서버에서 쫓겨나더라도, 신뢰 관계를 통해 이웃 서버에서 다시 들어오는 재진입 경로를 만들 수 있습니다.

신뢰 관계 재침투 경로
 ① 레거시 신뢰 : ~/.rhosts, /etc/hosts.equiv ("+ +" = 누구나)
 ② 호스트 기반 인증 : HostbasedAuthentication yes + shosts.equiv
 ③ SSH agent 하이재킹 : 관리자의 agent 소켓(/tmp/ssh-*/agent.*)으로 다른 서버 접속
 ④ 키 재사용 : 탈취한 개인키 + known_hosts 목록 → 이웃 서버 접근
   ↓
 한 서버의 근절이 끝나도 이웃 서버를 통해 복귀

핵심: 재침투 범위는 "그 서버"가 아니라 "그 서버를 신뢰하는 서버들"

known_hosts·bash_history·SSH config는 공격자에게 다음 목표 목록이 됩니다. 반대로 방어자에게는 재침투 가능 범위를 계산하는 자료가 됩니다.

2. 왜 중요한가

단일 서버 근절로는 신뢰 관계를 통한 재진입을 막을 수 없습니다.
agent 포워딩은 관리자 키를 직접 훔치지 않고도 다른 서버에 접속하게 합니다.
레거시 신뢰 파일은 오래된 서버에 잊힌 채 남아 있는 경우가 많습니다.

3. 핵심 명령어 / 설정

확인	명령	포인트
레거시 신뢰	`find / -name '.rhosts' -o -name 'hosts.equiv'`	존재 여부
호스트 기반	`sshd -T \| grep -i hostbased`	yes 여부
agent 소켓	`find /tmp -path 'ssh-' -type s`	소유자·접근
포워딩	`sshd -T \| grep -i allowagentforwarding`	허용 여부
신뢰 대상	`cat ~/.ssh/known_hosts ~/.ssh/config`	이웃 서버 목록

4. 실습 (실습 예시)

# 신뢰 관계 재침투 경로 점검 (분석 방법)
sudo find / -xdev \( -name '.rhosts' -o -name '.shosts' -o -name 'hosts.equiv' -o -name 'shosts.equiv' \) -ls 2>/dev/null
sudo sshd -T | grep -iE '^(hostbasedauthentication|allowagentforwarding|ignorerhosts) '
# 다른 사용자의 agent 소켓에 접근한 기록 (auditd)
sudo find /tmp -path '*ssh-*' -type s -ls 2>/dev/null
sudo ausearch -k reentry_trust -i 2>/dev/null | grep -E 'name=/tmp/ssh-|auid=|exe=' | tail
# 이 서버가 접속 가능한 이웃 서버 수
for h in /root /home/*; do [ -f "$h/.ssh/known_hosts" ] && echo "$h $(wc -l < $h/.ssh/known_hosts)"; done

5. 정상 상태

.rhosts·hosts.equiv: 없음
hostbasedauthentication no / allowagentforwarding no
agent 소켓: 소유자 본인 프로세스만 접근

레거시 신뢰 파일이 없고, 호스트 기반 인증과 agent 포워딩이 꺼져 있으며, agent 소켓에 타인 접근 기록이 없는 상태가 정상입니다.

6. 이상 상태

/root/.rhosts : "+ +"
agent 소켓 /tmp/ssh-XyZ/agent.4011 (owner=admin01)
  → auid=webadmin euid=0 exe=/usr/bin/ssh 접근 (SSH_AUTH_SOCK 하이재킹)
ssh: webadmin(root) → db01 접속, 키 지문 = admin01 키

"+ +" 신뢰 → 모든 호스트·사용자의 비밀번호 없는 접근 허용
root 권한으로 관리자 agent 소켓을 사용해 다른 서버 접속 → agent 하이재킹
관리자 키로 이웃 서버 접속 → 재침투 범위가 db01까지 확장

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

신뢰 관계 재침투 분석 흐름입니다(가상의 예시).

[신뢰 설정 점검] rhosts·hostbased·agent 포워딩
   ↓
[하이재킹 흔적] agent 소켓 접근 주체 ≠ 소유자
   ↓
[이웃 서버] known_hosts·ssh 명령 기록 → 접속 대상 목록
   ↓
[범위 확장] 대상 서버 로그에서 같은 키 지문·출발지 확인

경로	근거
rhosts	파일 존재
agent 하이재킹	소켓 접근 주체
키 재사용	이웃 서버의 키 지문 로그

agent 하이재킹은 피해 서버가 아니라 다음 서버의 로그에 관리자 키 지문으로 남습니다. 관리자가 접속하지 않은 시간의 관리자 키 로그인은 강한 신호입니다.

8. SOC 관제 포인트

레거시 신뢰 파일은 존재 자체를 고위험 점검 결과로 다룹니다.
agent 포워딩을 기본 비활성화하고 필요 시 ProxyJump로 대체합니다.
사고 범위 산정 시 known_hosts 기반으로 이웃 서버를 함께 조사합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,syssec_i,persistence,">
  <rule id="108330" level="13">
    <if_sid>108000</if_sid>
    <field name="audit.key">reentry_trust</field>
    <field name="audit.file.name" type="pcre2">\.(r|s)hosts$|hosts\.equiv$|^/tmp/ssh-[^/]+/agent\.</field>
    <description>신뢰 관계 파일 변경 또는 SSH agent 소켓 접근(신뢰 관계 재침투 의심)</description>
    <mitre><id>T1021.004</id></mitre>
  </rule>
</group>

신뢰 파일 생성과 agent 소켓 접근을 같은 키로 감사합니다. agent 소켓 접근은 소유자 본인의 정상 사용도 잡히므로, auid와 소켓 소유자가 다를 때만 경보하는 하위 룰로 좁혀 운영합니다.

10. 대응 방법

초기 확인 — 신뢰 설정·agent 접근 기록·이웃 서버 접속을 확인합니다.
범위 확인 — known_hosts 기반으로 재침투 가능 서버 범위를 산정합니다.
증거 확보 — 신뢰 파일·감사 기록·이웃 서버 로그를 보존합니다.
차단/조치 — 신뢰 파일 제거, 호스트 기반 인증·agent 포워딩 비활성화, 노출된 키를 교체합니다.
재발 방지 — 신뢰 관계 점검을 범위 산정 표준 절차에 넣습니다.

11. 핵심 정리

경로	차단
rhosts·equiv	파일 제거
hostbased	비활성화
agent	포워딩 금지·ProxyJump
키 재사용	키 교체
면접 포인트	"재침투 범위는 그 서버를 믿는 서버까지 — agent 소켓과 known_hosts를 본다"