AI를 활용하여 바이러스/악성코드는 어떻게 만들어지는가? 중국 공격자가 AI로 악성코드 제작한 증거

Checkpoint Research의 악성코드 분석팀이 보고한 내용입니다.

중국 공격자가 악성코드 개발 환경을 삭제하는 것을 잊었기 때문에, 공격자들이 악성코드 제작에 어떤 접근 방식을 사용하고 있는지 AI를 활용하고 있다는 매우 귀중한 정보가 얻어졌습니다.

실제로 이번에 만들어진 악성코드를 사용해 피해가 발생한 사례는 확인되지 않았지만, 이미 공격자들이 AI를 활용하여 공격을 구성하고 있다는 사실에는 변함이 없습니다. 공격자가 AI를 활용하여 새로운 공격 수법을 만들어내는 시대에 진입했습니다.

Voidlink란?

이번 중국 공격자가 지우는 것을 잊은 개발 환경에서 생성되었던, AI(LLM)에 의해 단기간에 생성된, 클라우드/Kubernetes 환경을 주 전장으로 하는 차세대 공격 프레임워크입니다.

기존의 'OS나 파일을 침해하는 악성코드'와는 달리, 클라우드의 아이덴티티(IAM / API Keys / Secrets)를 탈취하고 API를 통해 가로로 전개한다는, 현재의 클라우드 이용 실태에 완벽하게 최적화된 설계를 가지고 있습니다.

아티팩트의 타임스탬프를 근거로, AI를 사용하여 약 1주일 만에 88,000줄이 넘는 코드가 생성된 것으로 추정하고 있습니다.

여기서 중요한 점은, AI가 코드의 일부만 작성하는 것이 아니라, 복잡한 소프트웨어의 계획·구현·개선을 지원하며 활용되고 있다는 것입니다.

check Point Research (이하 CPR)는 VoidLink의 초기 샘플을 발견했습니다. Linux를 중심으로 클라우드/컨테이너/Kubernetes 환경에서의 활동을 상정한 프레임워크로 보고하고 있습니다.

본 기사에서는 개발에 AI가 관여한 근거, 기술적 특징, 운영자가 확인해야 할 방어 포인트를 정리합니다.

먼저 다음 두 가지는 구분하여 생각할 필요가 있습니다.

VoidLink에서 주목해야 할 것은 주로 개발 시 AI 활용입니다. AI에 대한 지시나 개발 계획서, 사양서, 테스트 보고서 등, 개발 프로세스에 AI가 관여했음을 보여주는 정보들이 있습니다.

조사의 단서가 된 것은 개발자 측이 외부에서 접근 가능한 상태로 남겨둔 소스코드, 버전 히스토리, 로그, AI 프롬프트 관련 파일입니다.

게다가, AI 개발 환경 'TRAE'와 관련된 헬퍼 파일이 남아 있어 원래의 지시 일부를 확인할 수 있었습니다.

개발 방식은 **사양 주도 개발(Spec Driven Development: SDD)**입니다. 아키텍처나 사양, 작업 계획을 정리하고, 이를 구현의 토대로 활용하는 흐름이 제시되었습니다.

공격자가 저지른 OPSEC 실수, 즉 공격자의 오산입니다.

통상적으로 고도화된 공격자는 자신의 흔적을 철저하게 지웁니다. 사용한 툴, 작성한 코드, 남긴 로그 등 모든 것을 삭제하고 철수하는 것이 기본 원칙입니다.

하지만 이번 공격자는 개발 중인 서버에 대량의 흔적(아티팩트)을 남겨둔 채 외부에서 접근 가능한 상태로 두었습니다.

image.png

OPSEC 실수로 발견된 폴더 안에 TRAE라는 툴의 흔적이 있었습니다.

TRAE란 무엇인가? 간단히 설명합니다.

TRAE는 AI 에이전트를 결합한 차세대 프로그래밍 개발 환경입니다. 일반적인 개발 환경과 다른 점은, 개발자가 AI에게 '이런 것을 만들고 싶다'라고 지시하기만 하면, AI가 자율적으로 코드를 작성하고 테스트하며 개선까지 해준다는 것입니다. 즉, AI가 소프트웨어 엔지니어 팀의 역할을 맡는 툴입니다.

그 TRAE의 헬퍼 파일이 소스코드와 함께 남아 있었습니다.

파일 내용은 중국어로 고도로 구조화되어 있었으며, AI에 대한 지시가 상세하게 기재되어 있었습니다.

특히 흥미로운 부분은 이 부분입니다. AI에게 **'아키텍처 검토 및 분석만 수행하고, 스텔스나 침입과 관련된 기술적 구현은 하지 말 것'**이라고 명시적으로 지시했습니다.

즉, 공격자는 처음부터 AI의 안전 기능을 의식하여, 직접 '악성코드를 만들어라'라고 명령하는 것이 아니라, 설계서 분석이라는 형태로 교묘하게 AI를 유도했던 것입니다. 이것이 VoidLink 개발에 AI가 깊이 관여했음을 보여주는 첫 번째 결정적인 증거였습니다.

**사양 주도 개발(Spec Driven Development)**입니다.

image.png

우선 'c2 architecture.txt'라는 설계서를 작성한 후, 이를 AI에게 전달하며 '아키텍처를 분석하고 구현하라'고 지시했습니다.

저희는 '악성코드를 만들어라'라고 한 번도 명령하지 않았습니다.

설계서 분석이라는 형태를 취함으로써, AI의 안전 기능을 우회하면서 실질적으로는 기능이 완벽한(full-function) 악성코드를 개발시키는 데 성공했습니다.

이는 AI를 악용하는 수법 중 이전에 본 적 없는 극도로 정교한 접근 방식입니다.

image.png

앞서 TRAE를 사용해 개발이 진행되었다고 말씀드렸습니다. 그 증거가 서버에 대량으로 남아있던 Markdown 파일들입니다.

Markdown 파일이란, 엔지니어가 설계서나 메모를 작성할 때 사용하는 문서 형식입니다.

이 파일들을 보면, AI가 마치 전문 개발팀의 매니저처럼 행동했음이 알 수 있습니다.

개발은 세 개의 팀으로 분할되어 있었습니다. 코드 작성 표준, 테스트 결과 보고서, 그리고 20주 분량의 스프린트 계획까지, 모든 것을 AI가 생성했습니다.

스프린트란 개발 작업을 짧은 기간으로 나누어 진행하는 기법으로, 대규모 소프트웨어 개발에서 자주 사용됩니다.

즉, AI는 단순히 코드를 작성했을 뿐만 아니라, 프로젝트 전체의 계획 수립, 관리, 품질 기준까지 담당했던 것입니다.

한 사람이 AI를 사용하여 마치 수십 명 규모의 개발팀을 움직이게 하듯이 VoidLink를 구축해낸 것입니다.

image.png

여기서는 VoidLink 개발 과정에서 AI가 어떻게 활용되었는지 보여드리겠습니다.

이 문서는 AI가 생성한 아키텍처 설계서입니다. 제목은 'VoidLink-2025 삼단 기능 대조 분석'으로, 즉 세 가지 컴포넌트의 기능 관계를 분석한 것입니다.

세 가지 컴포넌트란 무엇일까요? 아래 그림을 봐주십시오.

C2 Server(Go 언어)가 사령탑입니다. 공격자가 조작하는 서버입니다.

Implant Core(Zig 언어)가 실행 부대입니다. 표적 컴퓨터에 심겨지는 에이전트입니다.

Loader0(Zig 언어)가 침투 담당입니다. 인플란트를 표적으로 보내는 역할을 맡습니다.

그리고 아래 문서를 봐주십시오. 'The GhostWire Bible'이라는 제목의 이 문서에는 기밀 등급으로 'Top Secret / Red Team Internal'이라고 명시되어 있습니다.

Red Team이란 본래 기업의 보안을 검증하기 위해 가상의 공격을 수행하는 전문 팀을 말합니다. 하지만 여기서는 명백히 공격 도구 개발에 사용되었습니다.

AI에게 '이것은 Red Team용 도구다'라고 설명함으로써, 안전 기능을 교묘하게 우회했다고 생각됩니다.

image.png

제목은 'VoidLink-2025 벤치마크 성숙 C2 심도 개선 계획'입니다. 즉, VoidLink를 기존의 유명한 C2 프레임워크와 비교하여 자체적인 약점을 파악하고 개선하기 위한 문서의 흔적이 있었습니다.

벤치마크 대상은 Cobalt Strike, Sliver, Mythic이라는 세 가지 유명한 C2 프레임워크입니다.

비교표를 살펴보겠습니다.

아키텍처 설계에서는, Sliver나 Mythic가 플러그인을 자유롭게 추가할 수 있는 유연한 설계를 가진 반면, VoidLink는 플러그인 간 결합도가 높다는 약점이 지적되었습니다.

파일리스 실행(fileless execution)의 경우, 기존 도구들이 여러 개의 실행 방식을 가진 것에 비해, VoidLink는 하나의 방식만 가지고 있다는 과제가 명시되어 있습니다. 파일리스 실행이란 파일을 디스크에 기록하지 않고 메모리 상에서만 동작하는 기술로, 탐지가 매우 어렵습니다.

트래픽 위장(traffic camouflage)에서는, VoidLink의 통신 패턴이 감지되기 쉽다는 약점이 지적되었습니다.

중요한 것은, 이러한 약점들이 후속 버전에서 실제로 개선되고 있다는 것이 확인되었다는 점입니다.

즉, AI를 사용하여 경쟁사 분석을 수행하고 PDCA 사이클(Plan-Do-Check-Act)을 돌리듯이 스스로 진화시키고 있었던 것입니다. 이는 단순한 코드 생성을 넘어선 매우 고도한 AI 활용이라고 할 수 있습니다.

image.png

그리고 가장 놀라운 사실이 이것입니다.

타임스탬프 분석에 따르면, VoidLink는 아이디어를 떠올린 순간부터 버전 1.0이 완성될 때까지 불과 1주일 만이었다고 추정됩니다.

그 사이에 생성된 코드의 양을 봐주십시오.

Implant Core(Zig 언어)가 53,873줄, C2 서버(Go 언어)가 29,721줄, 플러그인(C 언어)이 약 5,000줄로, 총합은 약 88,594줄에 달합니다.

88,594줄이라는 양이 어느 정도인지 조금 설명드리겠습니다. 일반적인 소프트웨어 엔지니어가 하루에 작성할 수 있는 코드는 품질을 유지하면서도 기껏해야 수십 줄에서 수백 줄입니다. 즉, 통상적인 개발에서는 이 코드량을 작성하는 것만으로도 몇 달에서 1년 이상이 걸리는 계산이 됩니다.

그런데 이것이 단지 1주일 만에 이루어졌습니다.

저희는 여기서 처음에 세웠던 가설을 완전히 재검토하게 되었습니다. '이렇게 많은 개발은 여러 사람의 팀에 의한 것'이라고 생각했지만, 증거들을 종합해 보면 단독 개인에 의한 개발일 가능성이 매우 높습니다.

AI를 사용하면 소프트웨어 개발 지식을 가진 한 사람이 1주일 만에 풀 기능의 C2 프레임워크를 만들 수 있는 시대가 온 것입니다.

이것이 오늘 여러분께 가장 전달하고 싶은 메시지 중 하나입니다.

image.png

VoidLink는 클라우드 관련 정보나 메타데이터, 컨테이너 환경의 정보를 활용하여 자신의 실행 환경을 식별할 수 있습니다.

또한, cgroup이나 namespace 같은 정보를 사용한 컨테이너 환경 탐지나 Kubernetes의 ServiceAccount와 관련된 정보 확인도 합니다.

방어 측면에서 중요한 것은 호스트 자체의 상태뿐만 아니라, 해당 워크로드에 어떤 권한을 부여했는지까지 확인할 수 있다는 점입니다.

같은 컨테이너 침해라도 읽기 전용(read-only) 권한만 가진 경우와 광범위한 리소스를 변경할 수 있는 경우에서는 예상해야 할 영향이 다릅니다.

image.png

image.png

VoidLink는 보안 도구나 모니터링 환경을 확인하고, 통신 간격이나 활동 속도 등을 조절하는 'Adaptive Stealth'를 구현합니다.

다만, 환경에 따라 처리를 전환할 수 있는 기능의 존재 자체만으로는 실행 시 AI가 판단했다는 증거가 되지 않습니다. 조건 분기나 스코어링(scoring)을 통한 구현으로도 적응적인 행동은 실현될 수 있습니다.

운영 측면에서는 단시간의 대량 통신뿐만 아니라, 저빈도로 지속되는 의심스러운 활동도 조사 대상에 포함한다는 생각이 중요합니다.

image.png

VoidLink는 Plugin API를 통해 기능을 확장하는 모듈 구성을 채택하고 있습니다. 파일 조작이나 네트워크 관련 기능 등을 코어 API로 제공하는 설계가 되어 있습니다.

플러그인 수는 관리 화면 설명에서 '37종'으로 표기되어 있습니다. 다수의 기능을 추가하고 관리할 수 있는 구조에 주목해야 합니다.

관리 화면에는 인플란트(implant)의 관리뿐만 아니라, 인증 정보, 플러그인, 태스크, 통신 등을 다루는 기능들이 모여 있습니다.

memfd_create나 execveat을 이용한 메모 상에서의 로드 및 실행을 실현하고 있습니다.

디스크상의 파일 생성에 초점을 맞춘 탐지에서는 보이지 않을 수 있지만, 조사/모니터링 대상으로는 다음과 같은 것들이 있습니다.

• 프로세스 생성과 부모-자식 관계
• 시스템 콜(system call)이나 실행 이벤트
• 외부로의 네트워크 연결
• 클라우드 API 호출
• 인증 정보 이용 상황

이러한 가시성은 모니터링 제품의 대응 범위나 설정, 로그 획득 조건에 따라 달라집니다.

특정 시스템 콜을 사용했다는 이유만으로 악성이라고 판단하지 않고, 실행원이나 통신처 등의 맥락과 결합할 필요가 있습니다.

image.png

VoidLink는 실행 환경에 따라 사용자 공간(user space)이나 커널과 관련된 여러 은폐 기법을 선택하는 설계가 구현되어 있습니다.

다만, eBPF 자체는 정상적인 모니터링이나 성능 분석에도 사용되는 기술입니다. eBPF의 이용을 일률적으로 악성으로 간주하기보다는, 누가, 어떤 권한으로, 어떤 프로그램을 로드했는지 확인하는 것이 중요합니다.

또한, '프로세스를 숨기는 것'과 '재부팅 후에도 활동을 지속할 수 있는 것(지속성)'은 별개의 성질입니다. 은폐 기능의 존재만으로 영구화까지 성립한다고 판단해서는 안 됩니다.

image.png

image.png

IAM과 관련된 인증 정보, API 키, CI/CD의 Secrets, Git의 인증 정보, Kubernetes의 ServiceAccount 등을 중요한 대상으로 언급하고 있습니다.

여기서 등장하는 **NHI(Non-Human Identity)**는 애플리케이션이나 워크로드 등 인간 이외의 주체가 이용하는 아이덴티티를 의미합니다.

실무에서는 주체 그 자체와, 그 주체로 인증하기 위한 키나 토큰을 분리하여 관리하면 정리하기 쉽습니다.

image.png

인증 정보가 유출되었다고 해서 반드시 클라우드 전체를 조작할 수 있는 것은 아닙니다. 영향은 해당 인증 정보의 권한, 이용 조건, 유효 기간, 접근처 정책 등에 좌우됩니다.

마찬가지로, Kubernetes의 ServiceAccount 토큰을 획득했다고 해서 반드시 클러스터 관리자가 될 수 있는 것은 아닙니다.

따라서 침해 사고 발생 시에는 단말기나 컨테이너 격리 외에 다음 확인이 필요합니다.

• 해당 워크로드에서 참조 가능했던 인증 정보
• 인증 정보에 부여되어 있던 권한
• 의심스러운 이용 기록
• 만료 또는 로테이션(rotation)이 필요한 범위

컨테이너를 재작성하는 것만으로는 대응을 끝낼 수 없으며, 외부로 유출되었을 가능성이 있는 인증 정보까지 확인한다는 사고방식이 중요합니다.

바이너리 분석에서는 기술적인 메커니즘이, 대시보드에서는 공격자의 의도와 운영의 실태가 각각 파악됩니다. 이 두 가지 시점을 결합함으로써 VoidLink의 전모를 입체적으로 파악할 수 있었습니다.

그럼 실제로 대시보드를 살펴보겠습니다.

image.png

image.png

(대시보드 기능 목록)

VoidLink 패널이 가진 모든 기능을 3가지 카테고리로 정리했습니다.

먼저 왼쪽 열, Dashboard(대시보드)입니다. 이곳은 일종의 사령탑 역할을 합니다. Implants(감염 에이전트 관리), Terminal(원격 조작), Builder(임플란트 생성)라는 3가지 기능이 포함되어 있습니다. 공격자는 여기서 전체를 한눈에 파악하며, 감염된 호스트를 일원적으로 관리합니다.

다음으로 중앙 열, Attack(공격 모듈)입니다. 이곳은 실제 공격 행동을 실행하는 기능군입니다. Reconnaissance(정찰), Credentials(인증 정보 탈취), Persistence(지속성 확보), Lateral Movement(측면 이동), Process Injection(프로세스 인젝션), Hidden Modules(모듈 은폐), Wipe Evidence(증거 삭제)가 포함되어 있습니다. 침해 사고 이후에 해야 할 일들이 한데 모여 있습니다.

그리고 오른쪽 열, Infrastructure(인프라 관리)입니다. 이곳은 VoidLink 자체를 유지하고 은폐하기 위한 기능군입니다. Tunneling(통신 터널 구축), File Management(파일 관리), Plugin Management(플러그인 관리), Task Management(작업 관리), Setup(초기 설정)이 포함되어 있습니다.

이 3분할은 매우 중요한 의미를 가집니다. '침입하는 것 - 활동하는 것 - 유지하는 것'이라는 공격의 전체적인 라이프 사이클이 하나의 패널에서 완결되도록 설계된 것입니다.

이러한 설계 사상이 VoidLink를 단순한 악성코드가 아닌, 풀 스펙의 C2 프레임워크(Command and Control Framework)라고 부르는 가장 큰 이유입니다.

image.png

(임플란트)

감염 에이전트 관리 화면입니다. 36개 중 5개가 온라인, 29개가 오프라인 상태였습니다. 연구팀이 발견했을 당시에는 이것들이 실제 피해자의 머신인지 테스트 환경인지는 판단할 수 없었습니다. 호스트명 'VM-0-17-tencentos'를 통해 Tencent Cloud 사용이 시사됩니다.

image.png

(인증 정보)

인증 정보 수집 모듈 화면입니다. SSH 키/SSH 설정, Bash 히스토리, 환경 변수(API 키/토큰), 브라우저 비밀번호/쿠키, AWS 인증 정보, GCP 인증서 등을 선택적으로 수집할 수 있습니다. 소프트웨어 엔지니어나 클라우드 관리자를 표적으로 삼았을 가능성이 높아 공급망 공격으로의 전용도 우려됩니다.

image.png

(은폐)

루트킷 기능 관리 화면입니다. LKM(Loadable Kernel Module), eBPF, 프로세스/포트/파일 은폐를 운영자가 GUI에서 직접 제어할 수 있습니다. netstat/ss 출력으로부터의 포트 은폐, ps/top 출력으로부터의 프로세스 은폐, ls/find 출력으로부터의 파일 은폐, 그리고 /proc/PID/exe 심볼릭 링크의 은폐에 대응합니다.

image.png

(커스터마이징 가능한 임플란트 빌드)