Back to Home
Writeups

Custom C2 프레임워크로 레드라쿤 RTL 실습

CloakCat

Author

CloakCat

Time

4 min read

Read by

2

Custom C2 프레임워크 RTL 실습

들어가며

RTL(Red Team Lite) 강의를 수강하면서 단순히 강의에서 제공하는 툴을 쓰는 것보다 직접 C2 프레임워크를 만들어서 실습해보고 싶었다. 그래서 Rust로 작성한 CloakCat이라는 커스텀 C2 프레임워크를 직접 개발하고, 이걸로 RTL 랩 환경을 공략해보기로 했다.

해당 글에는 민감한 정보가 노출되어 레드라쿤의 실습랩에 악영향을 끼치는것을 방지하기 위해 도메인과 획득한 정보들은 생략하거나, 가려두었다.

공격자 인프라 구성

먼저 레드라쿤 RTL에서 가이드하는 사항대로 AWS ap-northeast-1 리전에 3-tier 공격자 인프라를 구성했다.

  • RTL-C2: CloakCat cat-server 실행, PostgreSQL DB 포함
  • RTL-Redirector: Nginx + Let's Encrypt SSL, Malleable C2 프로파일 기반 트래픽 필터링
  • RTL-Operator: 공격 툴 실행등

Redirector에는 amazon.toml 프로파일을 적용해서 Amazon S3/CloudFront 트래픽처럼 위장하도록 설정했다. 특정 UA와 인증 헤더가 없으면 구글로 302 리다이렉트하도록 구성했다.

nginxmap $http_user_agent $is_valid_ua {
    default 0;
    "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0" 1;
}

외부 정찰

타겟 도메인에 대해 bbot으로 서브도메인 열거를 진행했다. 그 결과 stg-ap2-api04-monitor를 발견했다.

해당 호스트 3000번 포트에서 Grafana가 실행 중인 것을 확인했다.

bashproxychains curl -s http://stg-ap2-api04-monitor.도메인:3000/api/health
{"commit":"78ee958143","database":"ok","version":"8.5.4"}

Grafana 8.5.4 버전으로 데이터소스 Proxy 기능을 악용한 SSRF 취약점이 존재하는 버전이다.

커스텀 SSRF 익스플로잇 제작

강의에서 제공하는 익스플로잇 툴 대신 직접 Python으로 제작했다. 핵심 로직은 Grafana 데이터소스 API를 통해 내부 URL로 요청을 보내는 방식이다.

로그인 → 데이터소스 생성 → SSRF URL로 업데이트 → Proxy 엔드포인트로 응답 수집

2단계 IMDS 체인으로 EC2 IAM 크레덴셜을 탈취했다. 1단계에서 IAM 역할명(IAMNAME)을 확인하고, 2단계에서 실제 크레덴셜을 탈취했다.

제작 과정에서 몇 가지 문제가 있었다.

첫째, 처음에는 IMDS 응답이 JSON인 줄 알았는데 역할명은 plain text로만 반환된다. json.loads()로 파싱하려다 계속 실패했고 .strip()으로 처리하니 해결됐다.

둘째, datasources/proxy/{id}/ 뒤에 path를 명시하지 않으면 캐시된 응답이 반환되는 문제가 있었다. 데이터소스 base URL을 http://ip로 설정하고 proxy 경로에 나머지 path를 직접 붙이는 방식으로 해결했다.

탈취한 IAM 크레덴셜로 SSM을 통해 Bastion 호스트에 접근했다.

Bastion 접근 및 내부 정보 수집

SSM으로 라쿤-dmz-bastion01에 접속했다. /home/유저@로컬/.파일.sh 파일에서 크레덴셜을 발견했다.

US\****:****
SMB 타겟: //10.2.30.250/awsshare

내부망 라우팅을 확인해보니 rt-onprem 인터페이스를 통해 10.2.30.0/16 대역에 직접 접근이 가능했다.

10.2.30.xxx  → UDC01 (도메인 컨트롤러)
10.2.30.xxx → AWSJH01 (점프호스트,목표)

내부망 피버팅

CloakCat Linux 에이전트 배포

Operator 서버에서 Linux용 에이전트를 빌드하고 Bastion에 배포해서 C2 콜백에 성공했다. catctl에서 socks-start 명령으로 SOCKS5 터널을 시작했다.

그런데 SOCKS5 터널 사용 시 에이전트가 불안정하게 동작하는 문제가 있었다. 원인을 분석해보니 터널마다 새로운 reqwest::Client를 생성하고 try_lock() 경합으로 데이터가 드롭되면서 HTTP 요청이 폭증하는 구조적 문제였다.

Chisel로 전환

안정성 문제로 인해 SOCKS5 피버팅을 Chisel 역방향 터널로 전환했다.

Bastion → Chisel Client → Operator Chisel Server(8888) → SOCKS5(1080)
Operator proxychains(socks5 127.0.0.1:1080) → 내부망

Operator에서 proxychains 설정 후 evil-winrm으로 AWSJH01(10.2.30.xxx) WinRM 접속에 성공했다.

이 과정에서도 몇 가지 문제가 있었다. 처음에 proxychains가 Tor 기본 포트(9050)로 연결을 시도해서 설정 파일에서 strict_chain을 dynamic_chain으로 변경하고 ProxyList를 수정했다. 또 C2 보안그룹에 Operator 사설 IP(10.0.xx.xxx)의 1080 포트 접근을 허용해야 했다.

Windows 거점 확보 시도 (현재 진행 중)

shellcode_loader 문제

Windows용 shellcode_loader.exe를 개발해서 C2 shellcode를 실행했다. shellcode 다운로드와 메모리 주입까지는 성공했지만 60초 타임아웃 후 프로세스가 종료되면서 에이전트도 같이 죽는 문제가 있었다.

이 과정에서 여러 문제를 겪었다.

  • shellcode 크기가 ~12MB인데 로더의 최대 payload 크기 제한이 10MB로 설정되어 있어서 수정이 필요했다.
  • C2 stage 엔드포인트(/v1/admin/stage)가 Nginx UA 필터에 막혀 shellcode 업로드가 안 됐다. /d/ 경로와 /v1/ 경로를 Nginx에서 필터 없이 C2로 직접 전달하도록 수정했다.
  • catctl의 stage 업로드 타임아웃이 30초로 짧아서 타임아웃 제한시간을 변경하는 작업을 진행했다.

GUP.exe DLL Sideloading 시도

프로세스 종료 시 에이전트도 같이 죽는 문제를 해결하기 위해 Notepad++ 업데이터인 GUP.exe를 이용한 DLL Sideloading 방식을 시도했다.

RTL 강의에서 제공하는 libcurl-master 소스를 분석했다. 원본 코드는 robots.txt 파일을 XOR 복호화해서 shellcode를 실행하는 방식이었다. 직접 페이로드를 수정해서 RTL과 다른 방식으로 C2에 호스팅중인 shellcode에 접근해 다운로드 및 실행 후 쉘코드 흔적을 남기지 않게끔 개발하였으나, mac환경에서 dll빌드의 문제가 있어 RTL의 방식대로 진행하기로 하였다. CloakCat shellcode를 bin파일로 빌드하고, 직접 python을 통해 XOR 암호화해서 robots.txt로 만들고 awsjh01에 RTL-initial-Access.zip과 함께 배포하였다.

GUP.exe      → 정상 Notepad++ 업데이터
libcurl.dll  → 악성 DLL (원본 소스 활용)
gup.dll      → 원본 libcurl.dll 이름 변경
robots.txt   → XOR 암호화된 CloakCat shellcode

XOR 복호화 검증 결과 암호화/복호화는 정상이었지만 에이전트 콜백이 없었다. GUP.exe가 종료되면서 shellcode 스레드도 같이 죽는 것으로 파악됐다.

EXE 직접 실행 시도

Windows용 cat-agent를 EXE 포맷으로 직접 빌드해서 실행했지만 0xC0000005 (Access Violation)으로 크래시가 발생했다.

현재 상황 및 의심 원인

Linux(Bastion)에서는 에이전트가 정상 동작하고 SOCKS5 연결까지 됐는데 Windows에서는 EXE 자체가 실행되지 않고 있다.

의심되는 원인은 다음과 같다.

  • Windows 빌드 문제: cross-compile 과정에서 unsafe 코드 관련 버그 발생 가능성.
  • cat-agent Windows 호환성: unsafe 코드 중 일부가 Windows 환경에서 크래시를 유발할 가능성
  • 타겟 환경 문제: AWSJH01 특정 보안 설정이나 정책으로 인한 실행 차단 가능성

다음 단계로 빌드 과정을 재검토하고 Windows 환경에서의 호환성 문제를 파악할 예정이다.

마치며

직접 만든 C2로 진행하다 보니 검증된 툴을 쓸 때보다 훨씬 많은 문제를 만났다. 특히 Malleable C2 트래픽 필터링 설정, stage 업로드 파이프라인, Windows 크로스컴파일 등 평소에 당연하게 생각했던 부분들이 실제로는 고려해야 할 것들이 많다는 걸 느꼈다.

거점 확보까지 아직 시간이 걸리겠지만 계속 진행할 예정이다.

Comments

Loading comments…

Leave a Comment