← 아티클 목록

관련 프로젝트CJ AI Security Wave 최종 프로젝트(AI를 활용한 침투테스트) →

Pentest

셸에서 C2까지, 침투테스트 기본 개념 노트

강의에서 다룬 Bind·Reverse Shell, 기본 탐색, 1-Day, VCS 노출, 해시 크랙, C2, OPSEC의 관계를 정리한다. 전 과정을 직접 이어서 실행한 한 세션 기록이 아니라, 허가된 실습을 준비하기 위한 개념 노트다.

목차 7

2026-08-09 업데이트 — ‘로그 흔적 정리’라는 표현을 바로잡았다. 감사·보안 로그는 평가자가 임의로 삭제할 대상이 아니며, OPSEC 절을 ROE·소유자 승인·증거 보존 원칙에 맞게 수정했다.

이 글은 강의에서 다룬 침투테스트 용어와 흐름을 한데 모은 개념 노트다. 아래 명령과 기법은 본인 소유이거나 시스템 소유자가 서면으로 허가한 실습 환경에서만, 합의한 Rules of Engagement(ROE) 범위 안에서 사용한다. Reverse Shell에서 C2까지 전 과정을 한 세션으로 재현한 실습 기록은 아니다.

셸을 어느 방향으로 여는가

원격 시스템에서 명령을 실행하려면 대화형 명령 채널, 곧 셸을 확보해야 한다. 방향에 따라 Bind Shell과 Reverse Shell로 나뉜다.

Bind Shell은 대상이 포트를 열고 대기하면 테스터가 그 포트로 접속한다.

테스터
-> 대상 시스템의 열린 포트

대상 쪽 인바운드 연결이 허용돼야 하므로 방화벽이나 NAT 환경에서는 막히는 경우가 많다.

Reverse Shell은 대상이 테스터가 준비한 리스너로 outbound 연결을 건다.

대상 시스템
-> 테스터 리스너

실습과 현업에서는 Reverse Shell을 더 자주 쓴다. 밖에서 안으로 들어오는 인바운드 연결보다, 안에서 밖으로 나가는 아웃바운드 연결을 느슨하게 통제하는 환경이 많기 때문이다. 그래서 방어 쪽에서는 서버의 outbound를 필요한 목적지와 포트로 제한하고, 비정상 장기 TCP 연결이나 의심스러운 프로세스의 네트워크 연결을 본다.

반복해서 쓰는 기본 명령어

셸을 잡으면 위치 확인, 파일 탐색, 내용 확인, 네트워크 연결, 파일 전송을 반복한다. 웹셸이나 제한된 셸에서는 cd가 세션으로 유지되지 않는 등 일부 명령이 기대대로 안 되기도 한다.

탐색과 내용 확인:

  • pwd, ls, file, env — 현재 위치·목록·파일 형식·환경변수
  • cat, less, head, tail, tail -f — 파일 내용 확인

파일과 텍스트 찾기:

bash
find /path -name "*.txt" -type f 2>/dev/null
find /path -writable -type f 2>/dev/null
grep -Rni "password" .

find는 이름(-name), 형태(-type), 깊이(-maxdepth), 권한(-readable, -writable, -executable) 기준으로 좁힌다. grep은 -R로 재귀, -i로 대소문자 무시, -n으로 줄 번호를 붙인다. 2>/dev/null은 에러 출력을 버려 결과를 읽기 쉽게 한다.

네트워크와 전송:

  • curl, wget — HTTP 응답·헤더 확인, 파일 요청·다운로드
  • nc — 포트 연결 테스트와 간단한 TCP 통신
  • ssh, scp, sftp — SSH 접속과 파일 복사

find는 파일 탐색에 쓰고, nc를 이용한 포트 연결 확인은 포트 스캔과 이어진다. 스캔 결과의 ’열림’이 무엇을 뜻하는지는 따로 판정해 본 적이 있다(스캐너가 「열림」이라고 안 하면 그 포트는 닫힌 걸까).

진입 경로가 되는 1-Day

셸을 얻기 전, 진입 경로 자체가 이미 공개된 취약점일 때가 있다. 1-Day Exploit은 취약점 정보와 보안 패치가 공개된 뒤, 아직 패치하지 않은 시스템을 대상으로 검증하거나 악용하는 코드·기법이다.

0-day와 다른 점은 패치가 이미 나와 있다는 것이다. 패치가 공개되면 공격자도 취약점 원인과 수정 내용을 분석할 수 있어서, 패치 적용이 늦은 시스템은 공개 직후부터 대상이 된다. 방어는 CVE·보안 공지를 주기적으로 확인하고, 중요 시스템에 패치 우선순위를 두고, 즉시 못 하면 임시 완화책을 적용하며, 외부 노출 서비스의 버전과 공격 시도를 모니터링하는 순서로 간다.

크리덴셜이 남는 VCS 노출

또 다른 진입·확장 경로는 버전 관리 시스템의 노출이다. VCS 정보 노출은 Git, Mercurial, SVN의 메타데이터나 히스토리가 웹에서 접근 가능한 상태로 남는 문제다. Mercurial의 .hg는 Git의 .git처럼 저장소 정보, 변경 이력, 설정, 브랜치를 담는다.

노출되면 소스 코드, 과거 커밋, 삭제된 파일 흔적, 설정 파일, DB 계정, API Key, 개발자 계정 정보가 새어 나갈 수 있다. 자격 증명은 다음 위치에서 자주 발견된다.

.env
config.php
settings.py
.hgrc
.hg/hgrc
.git/config
commit history

현재 파일이 깨끗해 보여도 과거 커밋에 남아 있을 수 있다. 히스토리는 이렇게 뒤진다.

bash
hg log config.php
hg diff -c <revision>

Git도 삭제한 커밋이나 파일이 히스토리에서 복구된다. 그래서 유출된 키는 삭제만 하지 말고 즉시 폐기 후 재발급해야 하고, 웹 루트에 .git·.hg·.svn을 배포하지 않으며, Secret Scanning으로 히스토리까지 검사한다.

주운 해시를 처리하기

노출된 파일이나 계정에서 해시를 얻으면 두 단계로 다룬다. 해시 식별은 문자열의 알고리즘 후보를 추정하는 과정이고, 해시 크랙은 사전 대입이나 규칙 기반 공격으로 평문 후보를 찾는 과정이다.

식별은 길이와 문자 집합을 먼저 본다. 128자리 hex는 SHA-512 계열 후보다.

bash
hashid hash.txt

크랙은 알고리즘에 맞는 모드를 골라 워드리스트를 대입한다. raw SHA-512는 hashcat에서 보통 mode 1700이다.

bash
hashcat -m 1700 -a 0 hash.txt /usr/share/wordlists/rockyou.txt
john --format=raw-sha512 --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

실습에서는 여기서 얻은 평문이 실제 계정 비밀번호로 재사용되는지 확인하는 흐름으로 이어진다. 방어는 비밀번호를 salt가 포함된 느린 KDF(bcrypt, scrypt, Argon2, PBKDF2)로 저장하고, 계정 간 재사용을 막고, SSH는 키 기반 인증을 쓰는 쪽이다.

제어를 유지하는 C2

셸을 하나 얻은 것과 여러 시스템을 계속 제어하는 것은 다르다. C2(Command and Control)는 감염된 시스템이나 에이전트를 원격으로 제어하는 명령·제어 인프라를 뜻한다. C2 프레임워크는 여러 대상의 에이전트와 통신하며 명령을 내리고 결과를 수집하는 도구다.

운영자
-> C2 서버
-> 에이전트
-> 실행 결과 반환

초기 학습 단계에서는 C2의 세부 기능보다 ’공격자가 원격 제어 채널을 유지하려 한다’는 큰 그림이면 충분하다. 방어 쪽에서 보는 신호는 Reverse Shell을 볼 때와 같다. 비정상 outbound 통신, 주기적 beaconing, 의심스러운 프로세스와 네트워크 연결이다.

이 글에서 말하는 OPSEC

이 글의 허가된 침투테스트 맥락에서 OPSEC(Operational Security)가 대상 시스템의 감사 로그를 임의로 삭제할 권한을 주지는 않는다. 승인된 레드팀 훈련에서는 탐지 회피가 목표에 포함될 수 있지만, 그 범위와 방법도 사전에 승인된 ROE를 따른다. 여기서 OPSEC는 정해진 대상, 시간, 계정과 도구로 평가하고 운영 영향을 통제하는 작업 규율을 뜻한다. 접속 IP, 테스트 계정, 업로드 파일, 명령 실행과 시스템 변경은 시작 전에 시스템 소유자와 합의하고 ROE에 적는다.

NIST SP 800-115는 ROE를 보안 테스트의 상세 지침과 제약으로 정의한다. 평가자는 ROE를 따라야 하며, 범위를 벗어날 필요가 생기면 원 서명자나 책임자의 명시적 허가를 받아야 한다. 대상, 허용·금지 기법, 기간, 중단 조건, 비상 연락망, 평가 데이터의 보관과 종료 절차도 사전에 정한다.

평가 중에는 날짜와 시간, 평가자, 출발지와 대상 시스템, 도구, 실행 명령, 결과를 기록한다. 대상 시스템의 감사·보안 로그는 지우거나 바꾸지 않는다. 이 로그는 테스터의 행위와 실제 침해를 구분하고 결과를 검증하는 근거다. 장애나 침해 정황이 보이면 작업을 멈추고 ROE의 연락 절차에 따라 시스템 소유자와 사고 대응 담당자에게 넘긴다. 증거가 될 수 있는 로그와 수집 자료는 접근을 통제해 보존한다. 디지털 증거 처리에는 NIST SP 800-86의 수집·검사·분석·보고 원칙을 참고할 수 있다.

종료 때 정리하는 것은 ROE가 정한 테스트 산출물이다. 업로드한 도구, 테스트용 계정과 임시 키, 테스트 때문에 바꾼 설정은 먼저 소유자 승인을 받고 제거하거나 원복한다. 운영 로그와 감사 기록은 일반 정리 대상이 아니다. 보존 기간이나 폐기가 필요하다면 조직의 로그·사고 대응 정책에 따라 소유자가 처리하며, 평가자가 임의로 삭제하지 않는다.

여기까지는 강의에서 다룬 개념의 연결 관계다. 직접 확인한 범위는 포트 스캔으로 서비스를 식별하는 앞단뿐이다. Reverse Shell을 잡아 C2로 유지하거나, 노출된 VCS에서 크리덴셜을 회수해 해시를 크랙하는 전체 과정은 아직 한 실습 환경에서 이어서 검증하지 않았다.

2026-09-25 정정: 파일 탐색 명령인 find를 서비스 확인 도구로 설명한 문장을 고쳤다.