AI로 해킹도구 직접 개발하는 랜섬웨어 조직 '더 젠틀맨', 국내 보안업체에 딱 걸렸다

[핵심요약] 러시아어권 랜섬웨어 조직 더 젠틀맨이 AI 코딩 어시스턴트로 C2 해킹도구 TukTuk을 직접 개발하던 정황이 국내 보안업체 오아시스시큐리티에 포착됐어요. EDR 무력화 커리큘럼까지 갖춘 개발 서버가 통째로 드러났어요.

2026년 9월 1일, 국내 사이버 위협 인텔리전스 기업 오아시스시큐리티(대표 김근용)가 러시아어권 랜섬웨어 조직 ‘더 젠틀맨(The Gentlemen)’과 연계된 공격 서버를 분석한 결과를 공개했어요. 이 서버에서는 이들이 자체 개발 중이던 C2(명령제어) 프레임워크 ‘TukTuk(툭툭) v2’의 전체 개발 프로젝트가 그대로 발견됐어요. 더 젠틀맨은 2026년 킬린(Qilin)에 이어 두 번째로 활발한 랜섬웨어 조직으로 꼽힐 만큼 빠르게 몸집을 키운 그룹이에요. 그런데 이번에 발견된 자료는 단순한 공격 도구 목록이 아니라, AI 코딩 어시스턴트를 활용해 해킹도구를 직접 만들고 EDR(엔드포인트 탐지·대응) 제품을 무력화하는 방법까지 체계적으로 연구한 ‘개발 현장’ 그 자체였어요.

무슨 일이 있었나 — 개발 서버가 통째로 노출됐어요

오아시스시큐리티가 확보한 서버 안에는 TukTuk C2의 윈도·리눅스 에이전트, 백엔드, 관리 패널까지 4가지 구성요소가 모두 담겨 있었어요. 이 C2는 원격 명령 실행과 파일 전송은 물론, 위조된 보안 경고창을 띄워 피해자의 계정정보를 그대로 입력하게 만드는 탈취 기능까지 갖추고 있었어요. 더 눈에 띈 건 서버에 남아있던 스크린샷이었어요. 작업 디렉터리가 ‘tuktuk’으로 설정된 AI 코딩 어시스턴트 세션이 러시아어 지시문과 함께 실행 중인 모습이 그대로 찍혀 있었거든요. 즉 사람이 한 줄 한 줄 짠 코드가 아니라, 공격자가 AI에게 지시를 내려가며 해킹도구를 만들어가던 작업 화면이 고스란히 남은 거예요.

서버에는 ‘Lesson 1~4’로 구성된 EDR 무력화 학습 자료도 있었어요. 기존 공격 도구를 분석하는 기초 단계부터 시작해 커널 수준 연구까지 단계별로 정리돼 있었고, ‘GentleKiller’ 변종과 연관된 취약 드라이버 ‘eb.sys’도 포함돼 있었어요. 심지어 주요 EDR 제품별로 강제 종료가 얼마나 걸리는지, 종료된 뒤 복구까지 걸리는 시간이 얼마인지까지 제품별로 직접 측정한 기록이 남아 있었어요. 이 서버를 통해 이미 탈취된 데이터도 확인됐어요. 한 글로벌 기술기업에서는 Jira 티켓 224건과 첨부파일 8건이, 미국 국방·항공우주 분야 고객사에서는 장비 구성·시스템 식별자·기밀 PoC 자료가, 한 헬스케어 기업에서는 관리자급 클라우드 접근키와 데이터베이스 정보가 그대로 빠져나가 있었어요.

왜 위험한가 — AI가 해킹도구 개발 시간을 통째로 줄이고 있어요

이번 사례가 특히 위험한 이유는 공격자가 AI를 ‘참고용’이 아니라 실제 도구 개발의 실무 파트너로 썼다는 점이에요. 예전에는 C2 프레임워크 하나를 처음부터 만들려면 숙련된 개발자가 수개월씩 매달려야 했어요. 하지만 AI 코딩 어시스턴트에게 지시를 내려가며 코드를 짜면, 윈도·리눅스 에이전트부터 관리 패널까지 갖춘 완성형 C2를 훨씬 짧은 기간에 만들어낼 수 있어요. 실제로 최근 보안업계에서는 오로라(Aurora) 랜섬웨어 조직이 AI 코딩 에이전트를 침투 계획에 활용해 9개국 20여 곳을 노렸다는 정황도 함께 보고됐어요. 더 젠틀맨 사례처럼 EDR 무력화 방법까지 AI의 도움을 받아 체계적으로 연구하는 흐름이 랜섬웨어 업계 전반으로 번지고 있다는 뜻이에요.

또 하나 눈여겨봐야 할 건, 공격자들이 이제 침투 이후에도 ‘끝까지’ 준비한다는 점이에요. 단순히 뚫고 들어가는 것을 넘어 EDR을 얼마나 빨리 무력화할 수 있는지, 무력화 후 보안팀이 얼마 만에 이를 복구하는지까지 제품별로 실측해뒀다는 건, 실제 침투 상황에서 방어팀이 대응할 시간을 얼마나 벌 수 있는지가 그만큼 줄어든다는 뜻이에요. 골든타임 자체가 공격자의 계산에 들어가 있는 셈이에요.

우리 회사도 대비하려면?

이번 사고의 피해자는 글로벌 대기업이나 미국 국방·항공우주 협력사였지만, 이런 흐름은 규모와 무관하게 모든 조직에 적용돼요. 국내 제조업이나 중견기업도 예외가 아니에요. 오히려 전산 인력이 소수인 조직일수록 EDR 알림 하나가 꺼졌을 때 그게 정상적인 업데이트인지 공격자의 무력화 시도인지 빠르게 구분하기 어렵다는 점에서 더 취약할 수 있어요.

가장 먼저 할 일은 EDR·백신 같은 보안 솔루션의 상태 변경 알림을 별도 채널로 반드시 받아보는 거예요. 보안 솔루션이 꺼지거나 프로세스가 강제 종료됐을 때 담당자에게 즉시 통보되는 구조가 없으면, 공격자가 며칠씩 무력화 상태를 유지해도 알아채기 어려워요. 두 번째는 관리자급 클라우드 접근키나 데이터베이스 접속 정보를 코드나 설정 파일에 평문으로 남겨두지 않는 거예요. 이번 헬스케어 기업 사례처럼 이런 정보 하나가 유출되면 피해 범위가 순식간에 커져요. 마지막으로, 위조된 보안 경고창으로 계정정보를 탈취하는 수법이 쓰인 만큼, 직원들에게 ‘보안 경고창이 떴다고 곧바로 비밀번호를 입력하지 말고 IT팀에 먼저 확인하라’는 원칙을 다시 한번 교육해둘 필요가 있어요.

• EDR·백신이 특정 시간대에 알 수 없는 이유로 꺼지거나 재시작된 적이 있나요
• 회사 계정정보를 입력하라는 낯선 보안 경고창이 뜬 적이 있나요
• 협업툴(Jira·클라우드 콘솔) 접근 로그에 낯선 IP나 시간대가 보이나요
• 관리자급 클라우드 접근키를 코드·설정 파일에 평문으로 남겨두진 않았나요
• 커널 드라이버 설치 알림을 사용자가 임의로 승인할 수 있는 구조인가요

Q. 우리 회사는 규모가 작은데, 이런 조직화된 랜섬웨어 그룹의 표적이 될 수 있나요?

네, 될 수 있어요. 더 젠틀맨 같은 조직은 큰 기업만 노리는 게 아니라 협력사·하청업체를 거쳐 침투 경로를 넓히는 경우가 많아요. 실제로 이번에 유출된 데이터에도 대기업의 협력사 정보가 포함돼 있었어요. 규모가 작다고 안심할 이유는 없어요.

Q. AI 코딩 어시스턴트를 쓰는 게 공격에만 쓰이는 건가요?

아니에요. AI 코딩 도구 자체는 방어에도 똑같이 활용할 수 있어요. 다만 이번 사례처럼 공격자가 먼저 이를 실전에 적극 활용하고 있다는 점에서, 방어하는 쪽도 EDR 우회 시도를 더 빠르게 탐지하는 체계를 서둘러 갖출 필요가 있다는 걸 보여줘요.

이번 사고는 공격자의 ‘작업 중인 컴퓨터’를 그대로 들여다본 흔치 않은 사례예요. AI가 해킹도구 개발 속도를 얼마나 앞당기고 있는지, EDR 무력화가 얼마나 정교하게 연구되고 있는지를 숫자로 확인시켜준 셈이에요. 결국 공격자의 준비 속도를 따라잡으려면, 방어하는 쪽도 보안 솔루션의 이상 신호를 놓치지 않는 모니터링 체계와 함께 ‘뚫려도 마지막 보루는 지킨다’는 이중 방어선이 필요해요.

이런 사고를 막으려면 EDR이 무력화되고 관리자 권한이 뚫려도 백업까지는 손대지 못하는 구조가 필요해요. 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스가 그 역할을 해줘요. EDR까지 무력화된 상황에서도 백업만은 어떻게 지켜내는지 궁금하다면 여기서 확인해보세요.