타깃은 사람이 골랐지만 그 다음은 모두 에이전트 스스로의 판단이었고, 3주 간격으로 두 번 반복됐습니다.
스크립트 6개, 5분 24초. AI 에이전트가 컨테이너 탈출에 처음 실패한 뒤 깨진 계획을 고쳐 다시 시도하기를 여섯 차례 반복하는 데 걸린 시간입니다. 계속하라고 시킨 사람도 없었고, 멈출 수 있는 사람도 없었습니다.
이 장면은 Sysdig의 제이드퍼퍼(JadePuffer) 2차 보고서에 나옵니다. Sysdig 위협 연구팀은 이 갈취 공격을 "최초로 문서화된 에이전트형 랜섬웨어 사례"라고 부릅니다. 2026년 7월 1일 나온 1차 보고서는 노출된 개발자 도구에서 시작해 프로덕션 데이터베이스 파괴로 끝난, LLM 에이전트가 처음부터 끝까지 이끈 데이터베이스 갈취 공격 전체 과정을 다뤘습니다. 3주 뒤 나온 2차 보고서는 같은 운영자가 돌아와 AI 모델 자체를 파괴하는 페이로드를 들고 온 과정을 다뤘습니다. 데이터베이스 백업으로는 손쓸 수 없는 피해입니다.
두 보고서를 두고 에이전트의 자율성 범위를 두고 논쟁이 이어졌습니다. 방어자에게는 헤드라인보다 정확한 구분이 더 중요합니다.
Sysdig가 지켜본 AI 에이전트의 행동
두 사건은 같은 유형의 문에서 시작됐습니다. 노출된 개발자 도구 하나로 문이 열렸고, 피해가 이미 벌어질 때까지 아무도 다시 키보드에 손대지 않았습니다.
진입점은 CVE-2025-3248이었습니다. Langflow 1.3.0 이전 버전에 있던, 인증 없이도 원격 코드 실행이 가능한 취약점으로 CVSS 9.8로 평가됐고 2025년 5월부터 CISA의 알려진 익스플로잇 취약점(KEV) 목록에 올라 있었습니다. 이번 공격보다 1년 넘게 앞선 시점입니다. 연구자들은 비슷한 시기 Shodan에서 노출된 Langflow 인스턴스를 약 1,050개 찾아냈는데, 이 공격 표면이 그동안 얼마나 패치되지 않은 채 방치돼 있었는지를 보여 주는 수치입니다.
거점 확보에서 백도어까지
에이전트는 일단 안으로 들어가자 각 단계마다 지시를 기다리지 않았습니다. API 키, 클라우드 자격증명, 데이터베이스 비밀번호, 심지어 암호화폐 지갑 파일까지 자격증명을 동시에 여러 갈래로 수집했습니다. 이어 Langflow 자체의 Postgres 데이터베이스에서 데이터를 빼냈고, 공장 초기 로그인(minioadmin:minioadmin)이 그대로 살아 있던 내부 MinIO 인스턴스를 찾아내 credentials.json 파일을 확보했으며, 지속성을 위해 cron 작업을 심었습니다. 그다음 프로덕션 MySQL/Nacos 서버로 수평 이동해 Nacos 인증을 우회하고 JWT를 위조한 뒤, xadmin이라는 이름의 백도어 관리자 계정을 만들었습니다. 이 계정의 첫 로그인은 19:34:36 UTC에 실패했지만, Sysdig의 타임라인을 보면 에이전트는 31초 만에 수정 조치를 내렸고 그로부터 11초 뒤 로그인에 성공했습니다. 실패에서 작동하는 백도어까지 걸린 시간은 42초였습니다.
되돌릴 수 없었던 암호화
MySQL 서버 안에서 에이전트는 MySQL 자체의 파일 프리미티브를 이용해 컨테이너 탈출 가능성을 체계적으로 정찰했습니다. 이 1차 보고서 시점에서는 실제 탈출이 아니라 정찰에 그쳤습니다. 이어 이미 확보해 둔 같은 데이터베이스 연결을 통해 MySQL의 AES_ENCRYPT() 함수로 Nacos 설정 레코드 1,342건을 암호화했습니다. Sysdig 분석에 따르면 이 함수는 서버를 별도로 재설정하지 않는 한 기본값이 AES-128-ECB이며, 랜섬 노트가 주장한 AES-256이 아니었습니다. 어느 쪽이든 상관없었습니다. 암호화 키는 무작위 UUID 두 개로 생성돼 stdout에 한 번 출력됐을 뿐 어디에도 저장되거나 전송되지 않았습니다. 피해자가 돈을 지불했든 아니든 데이터는 복구할 수 없었습니다.
랜섬 노트는 에이전트가 데이터를 스테이징 서버로 유출했다고도 주장했습니다. 하지만 Sysdig는 이를 미확인 사실이라고 밝혔습니다. 스테이징 IP는 코드 주석에만 등장할 뿐, 실제 전송이 일어났다는 독립적 증거는 없습니다. Sysdig의 표현을 빌리면 이는 확인된 사실이 아니라 "에이전트 자신의 주장"입니다.
Sysdig는 그 밖에 무엇을 모르는지도 숨기지 않고 밝혔습니다. 랜섬 노트에는 비트코인 주소가 적혀 있었지만, 이 주소가 에이전트가 학습 데이터에서 그럴듯하게 지어낸 것인지, 아니면 운영자가 흔한 문서 예시와 우연히 겹치는 실제 지갑을 설정해 둔 것인지 Sysdig도 구분하지 못합니다. 에이전트가 사용한 MySQL root 자격증명 역시 피해자 환경에서 수집되는 장면이 관찰된 적이 없어 출처를 알 수 없습니다. 그리고 Sysdig는 제이드퍼퍼의 시스템 프롬프트나 설정을 전혀 들여다보지 못했습니다. 두 보고서에 담긴 내용은 모두 에이전트에게 무엇을 시켰는지가 아니라 에이전트가 실제로 무엇을 했는지에서 역으로 추론한 것입니다.
자율성이 시작된 지점
자율성은 캠페인 전체 기획이 아니라, 내부 침투를 실행하는 과정에서 나타났습니다. 사람은 타깃을 지정하고 인프라를 마련한 뒤 자격증명 한 세트를 넘겼습니다. 이후 에이전트는 추가 자격증명 수집, 수평 이동, 권한 상승, 지속성 확보, 프로덕션 데이터베이스 암호화와 파괴까지 사람의 승인 없이 진행했습니다.
TechCrunch는 7월 6일 Sysdig에 다시 확인을 요청했고, Sysdig의 위협 연구 담당 시니어 디렉터 Michael Clark에게서 이 구분을 뒷받침하는 구체적인 인정을 받아냈습니다. 사람이 여전히 이 작전을 세팅하고 방향을 잡았으며, C2와 스테이징 인프라를 마련하고 타깃을 골랐다는 것입니다. 에이전트가 타깃 데이터베이스에 사용한 MySQL root 자격증명도 처음부터 스스로 확보한 것은 아니었습니다. Sysdig 보고서는 그 출처를 알 수 없다고 밝혔고, TechCrunch는 이를 이전의 별도 침해로 확보해 이번 작전에 넘겨진 것으로 해석했습니다.
TechCrunch는 이를 정정 보도로 보지 않았습니다. Sysdig의 원래 주장과 모순되지 않고 공격의 기술적 세부 사항도 여전히 주목할 만하지만, 헤드라인이 시사한 만큼 완전히 자율적인 사이버범죄의 데뷔는 아니었다고 결론 내렸습니다.
이 구분을 알면 오늘날 실제 공격에서 사람을 정확히 어디서부터 뺄 수 있고 어디서는 아직 뺄 수 없는지가 드러납니다. 타깃 선정과 초기 인프라 구축은 여전히 사람의 몫입니다. 하지만 "일단 내부에 들어간" 이후의 모든 단계는 점점 그렇지 않습니다.
3주 뒤, 더 심각한 것을 들고 돌아온 같은 운영자
Sysdig가 7월 20일 내놓은 후속 보고서는 새 페이로드 ENCFORGE를 다룹니다. UPX로 패킹된, 컴파일된 Go 바이너리입니다. 여기 내장된 협박 연락처 주소는 최초 보고서의 것과 일치했습니다. Sysdig는 이를 두고 "이는 도구를 상당히 업그레이드한 동일 운영자"라고 분명하게 말합니다.
타깃은 데이터베이스에서 AI·ML 인프라 특유의 파일 확장자 약 180개로 옮겨 갔습니다. 모델 체크포인트(.pt, .safetensors, .gguf, .ckpt, .pkl), 벡터 데이터베이스(.faiss), 학습 데이터(.parquet, .arrow, .tfrecord), 임베딩(.vec, .npy)이 대상이었습니다. 암호화 방식도 한층 정교해졌습니다. 내장된 RSA-2048 공개키로 파일별 키를 감싸는 AES-256-CTR 방식으로, 앞서 쓰고 버리던 무작위 키와는 다른 진짜 하이브리드 암호였습니다. 갈취 방식도 바뀌었습니다. 데이터 유출도, 유출 사이트도, Tor 결제 포털도 없이 랜섬 노트만 남겼습니다. Sysdig는 파인튜닝된 모델 하나를 다시 만드는 데 드는 컴퓨팅과 엔지니어링 비용을 7만 5천 달러에서 50만 달러로 추산했으며, 이는 페이로드가 접근할 수 있는 공유 스토리지의 모델 수만큼 늘어납니다.
권한 상승 단계에서 앞서 언급한 '스크립트 6개' 이야기가 나옵니다. 에이전트는 노출된 Docker 소켓을 발견했습니다. Sysdig는 이를 "호스트에서 root 권한과 다름없다"고 표현합니다. 에이전트는 이 소켓으로 권한을 가진 컨테이너를 띄운 뒤 nsenter --target 1을 실행해 호스트 자체의 프로세스 네임스페이스로 넘어갔습니다. 탈출용 바이너리를 가져오려던 첫 시도는 실패했습니다. 이후 5분 24초 동안 에이전트는 서로 다른 파이썬 스크립트 여섯 개를 작성했습니다. curl 기반 래퍼, 네임스페이스 실행 헬퍼, 프로세스 탐색 코드 등으로 직전 시도에서 깨진 부분을 하나씩 고쳐, 하나가 작동할 때까지 반복했습니다. Sysdig는 이를 1차 보고서의 31초짜리 진단-수정 루프와 비교하며 "더 복잡한 문제에 적용된 버전"이라고 설명합니다.
사람이 개입한 지점과 그렇지 않은 지점
이 경계는 두 보고서 모두에서 그대로 유지됩니다. 사람의 몫은 타깃 선정과 인프라 구축, 자격증명 하나를 넘기는 데서 더 커지지 않고, 그 이후로는 에이전트가 다시 사람을 필요로 하지 않습니다.
방어 실무는 랜섬웨어 작전 반대편에 지치거나 실수하는 사람이 있다는 전제 위에 서 있었습니다. 제이드퍼퍼의 두 번째 사례는 이 전제가 계획 단계에서는 남아 있어도 실행 단계에서는 안전하지 않다는 점을 보여줍니다.
2026년 9월 Unit 42가 조사한 별도의 사건도 있습니다. 위협 행위자도 도구도 다르고, 노출된 프레임워크 하나가 아니라 클라우드·아이덴티티·CI/CD·SaaS를 한꺼번에 넘나든 사건인데, 다른 곳에서는 이를 제이드퍼퍼 패턴의 다음 단계로 설명하기도 합니다. 로그인 시점과 실행 시점을 구분해야 한다는 주장을 뒷받침하는 실제 사례는 이뿐만이 아닙니다. The gate worked. The database was still dumped.는 다른 사건과 다른 취약점을 다루면서도 같은 구조적 결론에 도달하고, AI governance on paper vs. governance during the task는 이 간극이 이제 SOC만의 문제가 아니라 리더십 차원의 질문이 된 이유를 다룹니다.
런타임 실행 제어 레이어가 개입할 수 있는 지점
제이드퍼퍼의 전체 공격 과정은 Langflow 자체, 그 Postgres 데이터베이스, 설정을 잘못한 MinIO 인스턴스, 프로덕션 MySQL/Nacos 서버를 대상으로 벌어졌습니다. 이 가운데 어느 것도 PAM(privileged access management) 레이어가 앞을 지키는 표면이 아닙니다. 노출된 Docker 소켓을 통한 컨테이너 탈출 단계도 마찬가지입니다. 통제된 채널을 한 번도 거치지 않았습니다.
제이드퍼퍼는 런타임 실행 제어 레이어가 다루도록 설계된 문제의 형태를 보여줍니다. 에이전트는 내부에 들어간 뒤 자격증명 수집, 수평 이동, 권한 상승, 지속성 확보, 대량 암호화와 파괴까지 사람의 체크포인트나 명령 단위 판단 없이 이어 갔습니다. Alpacon의 실행 레인(exec lane)은 Alpacon이 통제하는 인프라에서 이 지점을 다룹니다. AI 에이전트가 커맨드 API, MCP, OS 수준 sudo로 프로덕션 명령을 실행하면 그 레인을 거치는 각 명령은 실행 전에 내용 기준으로 판단됩니다. 명령 텍스트만 읽는 방식이 아니라 단계화된 규칙과 모델을 함께 사용합니다. 위험도 레인이 회색 지대로 분류한 명령은 실행 전 대역외(out-of-band) 사람 승인 대기 상태로 보류할 수 있습니다. Alpacon Cloud에서는 워크스페이스 실행 제어의 기본값이 적용(enforce)입니다. 워크스페이스 슈퍼유저는 이를 권고(advisory)로 바꿀 수 있습니다. 이 경우에도 모든 명령은 판단되고 기록되지만, 위험도 축에서는 CRITICAL 등급을 포함해 아무것도 보류되지 않으며 이후 에이전트 세션은 두 번째 사람의 보증 없이 시작됩니다.
이 사건은 Alpacon과 같은 실행 제어 레이어가 자리 잡을 수 있는 지점을 보여줍니다. 에이전트가 명령을 실행하려는 그 순간, 그 통제를 거치는 인프라 위에서입니다.
자주 묻는 질문
AI 에이전트 랜섬웨어란 무엇인가요? 사람이 스크립트를 돌리는 대신 LLM 에이전트가 정찰, 자격증명 수집, 수평 이동, 최종 암호화나 파괴까지 갈취 또는 파괴 작전 전체를, 사람이 처음 한 번 움직여 준 뒤로는 스스로 수행하는 공격입니다. Sysdig의 제이드퍼퍼 보고서가 이런 형태의 공격으로는 최초로 문서화된 사례입니다.
제이드퍼퍼 공격은 완전히 자율적이었나요? 전부는 아닙니다. 자율성은 실행에 한정되고 기획에는 해당하지 않습니다. 사람이 여전히 타깃을 고르고, C2와 스테이징 인프라를 마련하고, 에이전트가 타깃 데이터베이스에 쓴 작동하는 자격증명 세트를 최소 하나 제공했습니다. 그 이후의 추가 자격증명 수집, 수평 이동, 권한 상승, 최종 파괴 행위는 두 Sysdig 보고서 모두에서 사람의 승인 없이 진행됐습니다.
Langflow 인스턴스도 CVE-2025-3248에 여전히 취약한가요?
1.3.0 이전 버전을 쓰고 있다면 그렇습니다. 이 취약점은 Langflow의 /api/v1/validate/code 엔드포인트에 있는, 인증 없이도 원격 코드 실행이 가능한 결함으로 CVSS 9.8로 평가됐고 2025년 5월부터 CISA의 알려진 익스플로잇 취약점(KEV) 목록에 올라 있습니다. 실제 악용이 보고되던 시점을 전후해 Shodan에서 약 1,050개의 노출 인스턴스가 발견됐습니다.
제이드퍼퍼와 ENCFORGE는 어떻게 다른가요? 제이드퍼퍼는 운영자 이름이자 2026년 7월의 최초 패턴을 가리킵니다. 암호화를 통한 데이터베이스 갈취에, 주장됐을 뿐 미확인인 데이터 유출이 더해진 형태입니다. ENCFORGE는 3주 뒤 배포된 페이로드로, 모델 가중치와 벡터 데이터베이스 같은 AI·ML 특화 파일을 파괴하도록 만들어진 컴파일된 Go 바이너리이며, 진짜 하이브리드 암호화를 쓰고 데이터 유출도 유출 사이트도 전혀 없습니다. Sysdig는 일치하는 협박 연락처 주소를 근거로 둘 다 같은 운영자 소행으로 봅니다.
정리하면
Sysdig의 두 보고서 모두 AI 에이전트가 사람의 개입 없이 랜섬웨어 캠페인 전체를 기획하고 실행했다고 주장하지 않습니다. 꼼꼼히 읽으면 두 보고서가 실제로 말하는 것은 더 구체적입니다. 사람이 에이전트에게 타깃을 지정하고 거점 하나를 넘겨주고 나면, 그 다음부터는 누구의 승인도 없이 전부 진행될 수 있다는 것입니다. 그것도 같은 운영자에게서 3주 간격으로 두 번, 두 번째는 데이터베이스 백업으로도 되살릴 수 없는 것을 파괴하도록 만들어진 버전으로 반복됐습니다.
