[7강] 레드팀 인프라 및 C2(Command and Control) 구축

안녕하세요, Hackerstory 공부방의 IT/보안 튜터 정다은입니다! 👋

지난 시간에 우리는 실제 위협 주체의 동작을 모방하기 위한 시나리오와 IoC(침해 지표)를 설계하는 방법을 다뤘습니다. 시나리오가 완성되었다면, 이제 공격을 실제로 수행할 **'무대(Infrastructure)'**와 **'지휘 통제소(C2 Framework)'**를 구축할 차례입니다.

영화 속 스파이들이 작전을 수행할 때 본부와 비밀 통신망을 구축하고, 안전한 은신처를 마련하는 것과 같습니다. 레드팀 역시 방어팀(Blue Team)에게 쉽게 간파당하지 않으면서 안정적으로 작전을 수행할 수 있는 탄탄한 인프라가 필수적입니다.

이번 챕터에서는 레드팀 인프라의 설계 원칙부터 C2 프레임워크 구축, 그리고 실무 통신 인프라 구성까지 기초부터 차근차근 알아보겠습니다!

1. 개념 설명: 레드팀 인프라와 C2란 무엇인가?

(1) 레드팀 인프라(Red Team Infrastructure)의 핵심 요건

레드팀 인프라는 공격에 사용되는 서버, 도메인, IP, 도구, 중앙 데이터 저장소 등을 모두 포함하는 시스템 환경을 의미합니다. 단순히 공격용 Linux 서버 한 대를 띄우는 것이 아닙니다.

레드팀 인프라 설계 시 반드시 고려해야 할 3가지 핵심 요소가 있습니다.

1. 작전 보안 (OPSEC - Operational Security): 인프라가 방어팀에 의해 차단되더라도 실제 레드팀의 핵심 자산(C2 서버, 팀원 IP 등)이 노출되거나 작전 전체가 마비되지 않아야 합니다.
2. 유연성 및 복원력 (Resilience): 특정 IP나 도메인이 방어팀에 의해 차단(Block)되었을 때, 즉시 대체 통로로 전환할 수 있어야 합니다.
3. 중앙 집중식 로깅 및 관리 (Centralized Logging): 오퍼레이터(공격 수행원)들이 수행한 모든 명령과 결과를 중앙 데이터 저장소에 기록해야 합니다. 이는 추후 교전 수칙(ROE) 준수 여부를 확인하고 보고서를 작성할 때 결정적인 증거가 됩니다.

(2) Tiered Architecture (계층형 인프라 구조)

현대 레드팀은 방어자의 추적을 피하기 위해 인프라를 여러 계층으로 나누어 구성합니다.

(참고: 레드팀의 체계적인 작업 흐름과 인프라 통제)

• 1계층: 타깃 임플란트 (Target Implant / Agent)
  • 침투 대상 시스템에서 실행되는 악성 코드(에이전트)입니다.
• 2계층: 리다이렉터 (Redirector / Reverse Proxy)
  • 타깃과 실제 C2 서버 사이에 위치하는 '방패' 역할입니다. 타깃의 통신을 수신한 뒤, 정상적인 요청만 실제 C2 서버로 전달(Forwarding)합니다. 방어팀이 탐지하여 차단하더라도 리다이렉터 IP만 차단되므로 C2 서버는 안전합니다.
• 3계층: C2 서버 (Command & Control Server)
  • 임플란트 제어, 페이로드 생성, 데이터 수집 등을 담당하는 중앙 지휘 서버입니다. 외부망에 직접 노출되지 않도록 엄격히 보호됩니다.
• 4계층: 팀 서버 및 중앙 데이터 저장소 (Team Server & Data Repository)
  • 레드팀 오퍼레이터들이 접속하여 공동 작업하는 공간이며, 작전 중 발생하는 모든 데이터(수집한 자격 증명, 파일, 통신 로그)가 실시간으로 저장됩니다.

(3) C2(Command and Control) 프레임워크

C2 프레임워크는 타깃 시스템에 침투한 에이전트에 명령을 내리고, 결과를 전달받으며, 권한 상승·내부 이동 등의 추가 공격을 수행할 수 있게 해주는 '중앙 제어 플랫폼'입니다. (대표적으로 Cobalt Strike, Havoc, Mythic, Sliver 등이 있습니다.)

2. 실무 예시 및 구축 흐름

실제 레드팀 작전 환경을 구축하는 대표적인 흐름을 예시와 함께 살펴봅시다.

Step 1. 리다이렉터(Redirector) 설정

리다이렉터는 Nginx, Apache, 또는 Cloudflare와 같은 CDN 서비스를 활용하여 구축할 수 있습니다.

예를 들어, Nginx를 사용하여 방어팀의 스캐너나 일반 사용자의 접근은 정상 웹사이트로 리다이렉트시키고, 레드팀 에이전트의 특정 HTTP 헤더를 포함한 요청만 실제 C2 서버로 프록시해주는 설정 예시입니다.

# Nginx Reverse Proxy 설정 예시 (OPSEC 강화)
server {
    listen 443 ssl;
    server_name update-service-check.com; # 신뢰할 만한 도메인 위장

    ssl_certificate /etc/letsencrypt/live/update-service-check.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/update-service-check.com/privkey.pem;

    location / {
        # 에이전트 전용 Custom User-Agent 및 URI 검증
        if ($http_user_agent ~* "Mozilla/5.0 \(Windows NT 10.0; Win64; x64\) DedicatedAgent") {
            proxy_pass https://10.0.0.50:8443; # 내부 C2 서버 IP로 전달
            break;
        }

        # 조건에 맞지 않는 일반/방어팀 접근은 정상 사이트(예: 구글)로 보냄 (비콘 은닉)
        return 302 https://www.google.com;
    }
}

💡 튜터의 팁: 방어팀이 해당 도메인에 브라우저로 직접 접속하면 Google 페이지로 이동하므로, 단순 탐지 도구로는 C2 서버의 존재를 파악하기 매우 어렵습니다!

Step 2. Short-haul vs Long-haul C2 통신 분리

운용 효율성과 안전성을 모두 잡기 위해 C2 통신을 두 가지 채널로 분리하여 운영합니다.

                  ┌─── [Short-haul C2] (빠른 주기: 1~5초) ──> 빠른 대화형 작업 수행
[타깃 시스템] ────┤
                  └─── [Long-haul C2]  (긴 주기: 12~24시간) ──> 백업용 (주 통로 차단 대비)

1. Short-haul (단기/대화형 채널):
   • 목적: 권한 상승, 내부 네트워크 탐색 등 즉각적인 반응이 필요한 작업 수행.
   • 특징: 비콘(Beacon) 주기가 짧음(수 초 단위). 탐지될 위험이 상대적으로 높음.
2. Long-haul (장기/백업 채널):
   • 목적: Short-haul 채널이 방어팀에 의해 차단되었을 때 재침투하기 위한 '비상구'.
   • 특징: 비콘 주기가 매우 긺(수 시간 ~ 하루에 한 번 접속). 트래픽이 거의 없어 탐지가 매우 어려움.

Step 3. 중앙 데이터 저장소 및 오퍼레이터 도구 통합

모든 오퍼레이터는 개인 PC에서 직접 타깃으로 공격을 수행하지 않습니다. 반드시 보안된 VPN을 통해 레드팀의 **팀 서버(Team Server)**에 접속하여 작전을 수행합니다.

• Elasticsearch / Vector / Splunk 통합: C2 서버와 리다이렉터의 모든 로그를 중앙 로그 서버로 실시간 수집합니다.
• 타임스탬프 동기화(NTP): 모든 서버의 시각을 동기화하여, "누가, 언제, 어떤 명령을 실행했는지"를 정확히 기록합니다.

3. 핵심 정리

오늘 배운 레드팀 인프라 및 C2 구축의 핵심 내용을 요약해 볼까요?

📖 다음 챕터 예고

공격을 수행할 탄탄한 인프라와 C2 지휘 통제소가 마련되었습니다! 이제 타깃의 문을 두드릴 차례입니다.

다음 8강에서는 **"초기 침투 기법 (Initial Access Techniques)"**에 대해 배웁니다. 이메일 스피어피싱, 페이로드 제작 및 전달, 사용자 상호작용 유도 등 준비된 인프라를 활용해 타깃 내부 네트워크에 성공적으로 첫 발을 내딛는 실무 기법들을 다룰 예정이니 기대해 주세요!

오늘 내용 중 궁금한 점이 있다면 언제든 댓글로 질문 남겨주세요. 수고 많으셨습니다! 😊