The Gentlemen 공격｜TukTuk C2 개발과 EDR 우회 연구

이번 공개가 새로운 이유

랜섬웨어 조직 The Gentlemen을 둘러싼 기존 공개 자료는 실제 침해 과정과 유출사이트 활동을 중심으로 축적돼 왔습니다. 9월 1일 새로 공개된 분석은 공격 결과가 아니라 공격자가 도구를 만들고 시험하며 탈취 자료를 정리한 작업 환경을 보여준다는 점에서 성격이 다릅니다. 오아시스시큐리티가 분석한 연계 서버에는 TukTuk C2 v2의 개발 프로젝트, EDR 무력화 연구 자료, 피해 조직에서 수집된 것으로 분석된 업무 자료가 함께 보관돼 있었습니다. 기존에 관찰된 TukTuk 사용을 넘어 개발 구조와 우회 기술의 개선 과정까지 이어서 판단할 단서가 생겼습니다.

이번 원고는 서버에서 직접 확인된 파일과 화면, 이전 실제 침해사례에서 관찰된 행위를 구분해 다룹니다. 특정 피해기업의 이름이나 공격자 측 피해 수치는 다루지 않습니다. 공개된 증거가 뒷받침하는 범위는 The Gentlemen 연계 인프라에서 C2 개발과 방어 회피 연구, 탈취자료 관리가 하나의 운영 흐름으로 이어졌다는 점입니다. 따라서 방어팀도 랜섬웨어 실행 파일 하나만 찾기보다 초기 실행, 외부 통신, EDR 중단, 비밀정보 접근, 최종 영향 사이의 연결을 확인해야 합니다.

노출된 TukTuk C2 v2 개발 구조

공개된 서버에는 TukTuk C2 v2 전체 프로젝트가 남아 있었습니다. 구성요소는 Windows 에이전트, Linux 에이전트, 백엔드, 운영자용 관리 패널의 네 부분으로 나뉘었습니다. 이는 한 운영체제에서만 작동하는 단일 악성코드가 아니라 여러 환경의 감염 호스트를 공통 백엔드와 패널에서 다루려는 구조입니다. 원격 명령 실행과 파일 송수신 기능이 포함됐고, Windows 보안 대화상자를 모방해 사용자가 계정과 비밀번호를 입력하도록 유도하는 기능도 분석됐습니다. C2가 단순 명령 전달을 넘어 자격증명 수집과 후속 접근을 지원하도록 확장됐다는 의미입니다.

개발 과정에는 상용 AI 코딩 도구가 사용된 정황도 남았습니다. 분석 서버의 화면에는 작업 디렉터리를 tuktuk으로 설정한 AI 코딩 어시스턴트 세션과 러시아어 지시문이 보였고, 이전 작업 기록에 등장한 관리 패널과 백엔드 에이전트가 확보된 소스 프로젝트에서도 대응했습니다. 이 대목은 AI가 공격을 자동으로 완성했다는 단정과는 구분해야 합니다. 공개 증거가 보여주는 것은 운영자가 AI 코딩 도구를 개발 보조 수단으로 사용하면서 실제 C2 구성요소를 반복적으로 만들고 다듬었다는 작업 방식입니다.

실제 침해사례와 이어지는 공격 흐름

노출된 개발 환경의 의미는 5월 The DFIR Report가 공개한 실제 침해사례와 대조할 때 더 선명해집니다. 당시 사용자는 Sysinternals RAMMap으로 위장한 악성 MSI를 실행했고, 설치 과정에서 EtherRAT 변종이 배치됐습니다. 악성코드는 휴대형 Node.js 런타임과 난독화된 JavaScript를 사용했으며, 레지스트리 Run 키로 지속성을 확보했습니다. 이후 Ethereum 블록체인에 저장된 설정을 조회해 C2 주소를 갱신했고, 공격자가 설정을 바꾸자 TryCloudflare 터널을 통해 통신이 활성화됐습니다.

그 다음 단계에서 TukTuk 프레임워크와 원격관리 도구 GoTo Resolve가 투입됐습니다. 공격자는 이 접근을 이용해 자료를 클라우드 서비스로 반출한 뒤 The Gentlemen 랜섬웨어를 배포했습니다. 즉 위장 설치파일, 탄력적으로 바뀌는 C2, 추가 원격제어, 자료 반출, 암호화가 한 사건 안에서 이어졌습니다. 이번에 공개된 v2 프로젝트는 그 침해에서 관찰된 TukTuk을 별도 도구가 아니라 계속 개발되는 운영 플랫폼으로 바라봐야 한다는 근거를 보탭니다.

블록체인 기반 설정과 임시 터널 서비스는 방어 관점에서 중요한 조합입니다. 고정 도메인 하나를 차단하는 방식만으로는 공격자가 설정 값을 바꾸며 통신 경로를 교체하는 행위를 따라가기 어렵습니다. 반대로 엔드포인트 실행 기록, 블록체인 게이트웨가 조회, 새 터널 도메인 접속, 원격관리 도구 실행을 시간순으로 묶으면 개별 이벤트보다 훨씬 높은 신뢰도로 침해 흐름을 재구성할 수 있습니다. 네트워크와 엔드포인트 로그를 같은 시간축에서 보는 이유가 여기에 있습니다.

EDR 무력화 연구의 체계화

같은 서버에서는 EDR 무력화 기술을 Lesson 1부터 Lesson 4까지 단계별로 정리한 자료가 발견됐습니다. 기존 도구를 분석하는 단계에서 직접 구현, 취약 드라이버 탐색, 커널 수준 연구로 이어지는 형태였고, 각 단계에 기술 문서와 실습 코드가 함께 배치됐습니다. 첫 단계에는 공개 보고서에서 GentleKiller 변종과 연결된 eb.sys 드라이버 관련 자료도 포함됐습니다. 이미 알려진 BYOVD 계열 기법을 단순 보관하는 수준이 아니라 재현과 개선을 위한 학습 체계로 만들었다는 점이 핵심입니다.

특히 주요 EDR 제품의 프로세스를 강제로 종료한 뒤 다시 살아나기까지 걸리는 시간을 제품별로 측정한 기록이 주목됩니다. 공격자는 보호 기능이 사라지는 짧은 공백을 계산해 자격증명 탈취, 추가 도구 실행, 랜섬웨어 배포 같은 후속 행동의 창으로 활용할 수 있습니다. 따라서 보안제품이 자동으로 재시작됐다는 사실만으로 정상 상태를 판단하면 공격자가 활용한 중단 구간을 놓칠 수 있습니다. 중앙 관리 서버의 상태 변화, 서비스 중지와 재시작 시각, 그 사가 생성된 프로세스와 파일을 함께 확인해야 합니다.

탈취자료의 분류와 후속 접근

공격 서버에는 글로벌 기술기업의 Jira 티켓 224건과 첨부파일 8건이 별도 폴더에 보관돼 있었습니다. 공격자가 작성한 것으로 분석된 문서에서는 이를 자격증명, 취약점, 인프라, 고객 커뮤니케이션 등 19개 범주로 나눈 흔적이 확인됐습니다. 기술지원 티켓은 단순 문의 기록이 아니라 내부 호스트명, 장비 구성, 인증 문제, 제한된 첨부파일처럼 후속 침투에 유용한 맥락을 한곳에 모를 수 있습니다. 고객사와 협력사가 공유한 정보까지 포함되면 한 조직의 침해가 공급망 관계의 탐색 자료로 확장될 수 있습니다.

또 다른 자료 묶음에는 관리자 수준의 클라우드 접근키와 데이터베이스, 디렉터리 서비스, 소스코드 저장소 관련 정보가 포함됐습니다. 사고 대응에서는 파일을 삭제하거나 계정 비밀번호를 바꾸는 조치만으로 끝내기보다 노출된 비밀정보가 어떤 서비스와 권한에 연결됐는지 확인해야 합니다. 접근키를 폐기하고 새 키로 교체한 뒤 사용 이력과 권한 범위를 검토하며, Jira나 저장소에 남은 토큰과 구성값도 함께 찾아야 합니다. 탈취 자료가 이미 범주화돼 있었다는 사실은 공격자가 후속 접근의 우선순위를 정할 준비를 했음을 보여줍니다.

방어팀의 우선 점검

첫째, 인터넷에서 내려받은 MSI와 스크립트의 실행 출처를 확인해야 합니다. 정상 관리도구나 Sysinternals 유틸리티를 사칭한 파일은 이름만으로 허용하지 말고 서명, 해시, 배포 경로를 함께 검증하는 편이 안전합니다. 사용자 다운로드 폴더나 임시 경로에서 실행된 설치파일이 Node.js 같은 런타임을 추가하고 난독화된 스크립트를 호출했다면 관련 프로세스 트리와 생성 파일을 보존해야 합니다.

둘째, 외부 통신은 도메인 단위 차단보다 행위의 연쇄를 중심으로 살펴봐야 합니다. 평소 사용하지 않던 블록체인 RPC 게이트웨가 조회, 새로 생성된 터널 도메인 접속, 비승인 원격관리 도구 실행이 한 호스트에서 이어졌는지 비교합니다. 프록시와 DNS, 방화벽, EDR의 시각을 맞추면 C2 주소가 바뀌어도 공통된 전환 패턴을 찾을 수 있습니다.

셋째, EDR 상태는 ‘현재 정상’뿐 아니라 중단 이력까지 확인해야 합니다. 보호 프로세스의 비정상 종료와 자동 복구 사이에 드라이버 적재, 자격증명 접근, 대량 파일 열람, 원격 실행이 있었는지 점검합니다. 에이전트 자체 로그가 손상될 가능성에 대비해 중앙 수집 로그와 시스템 이벤트, 네트워크 기록을 교차 검증하는 방식이 필요합니다.

넷째, Jira·클라우드·디렉터리·소스 저장소의 비밀정보를 하나의 노출 범위로 묶어 처리해야 합니다. 관리자 키와 토큰을 우선 폐기하고, 해당 자격증명으로 수행된 로그인과 API 호출을 검토합니다. 지원 티켓과 첨부파일에 기록된 장비 식별자나 내부 주소는 후속 표적화에 쓰일 수 있으므로 외부 노출 범위와 접근권한도 재점검해야 합니다.

다섯째, 복구 완료 판단에는 재연결과 재감염 검증이 포함돼야 합니다. C2 통신을 차단한 뒤 동일 호스트가 다른 터널이나 도메인으로 다시 연결되는지 관찰하고, 비밀정보 교체 후 오래된 키가 실제로 거부되는지 시험합니다. 백업 복구 전에는 원격관리 도구와 지속성 항목을 제거하고, 복구 이후에도 EDR 중단 공백과 대량 파일 접근이 반복되지 않는지 확인해야 합니다. 이번 분석의 가장 큰 교훈은 도구 하나가 아니라 개발·우회·수집·영향이 연결된 운영 체계를 끊어야 한다는 점입니다.