jscrambler npm 계정 탈취로 IronWorm 정보탈취 악성코드 유포

자바스크립트 코드 보호 도구인 jscrambler의 npm 배포 계정이 탈취되면서, 정상 패키지 업데이트처럼 보이는 공급망 공격이 발생했다. 공격자는 2026년 7월 11일 약 3시간 동안 악성 버전 5개를 npm 레지스트리에 올렸고, 설치 또는 실행 과정에서 Rust 기반 정보탈취 악성코드 IronWorm이 내려받아 실행되도록 만들었다.

이번 사건의 핵심은 단순한 악성 패키지 등록이 아니라 신뢰된 배포 계정이 악용됐다는 점이다. 개발자나 CI/CD 파이프라인 입장에서는 패키지 이름, 배포 경로, 사용 방식이 모두 정상처럼 보일 수 있다. 따라서 영향 버전을 한 번이라도 설치한 환경은 "패키지를 지웠다"가 아니라 "해당 환경에서 접근 가능했던 자격증명이 노출됐다"는 기준으로 대응해야 한다.

사건 개요

jscrambler는 자바스크립트 코드를 난독화하고 변조를 어렵게 만드는 상용 코드 보호 솔루션이다. 개발·빌드 과정에서 쓰이는 CLI가 npm 패키지로 배포되며, 공개 분석에 따르면 주간 다운로드 규모는 약 1만 5,800건 수준으로 알려졌다.

공격자는 탈취한 npm 배포 권한으로 8.14.0, 8.16.0, 8.17.0, 8.18.0, 8.20.0 버전을 연달아 게시했다. 초기 악성 버전은 preinstall 훅을 이용해 설치 시점에 로더를 실행했다. 이후 버전에서는 드롭퍼 코드가 패키지 본체와 CLI 쪽으로 옮겨져, 단순히 설치 스크립트를 막는 조치만으로는 충분하지 않은 형태가 됐다.

JFrog는 이 페이로드를 IronWorm으로 식별했다. IronWorm은 Shai-Hulud 계열로 분류되는 Rust 기반 정보탈취 악성코드이며, 개발자 환경과 빌드 환경의 자격증명을 집중적으로 노린다. 악성 버전은 비교적 빠르게 탐지되어 내려갔지만, npm 패키지는 자동화된 빌드와 캐시를 통해 짧은 시간에도 여러 환경에 설치될 수 있다.

악성 버전은 어떻게 실행됐나

초기 악성 버전에는 dist/setup.js와 dist/intro.js가 추가됐다. setup.js는 작은 로더 역할을 하고, intro.js는 이름과 달리 자바스크립트 소개 파일이 아니라 여러 운영체제용 네이티브 바이너리를 담은 컨테이너로 분석됐다.

로더는 실행 환경의 운영체제를 확인한 뒤 Linux, Windows, macOS 중 맞는 바이너리를 꺼내 시스템 임시 디렉터리에 숨김 파일 형태로 기록하고 백그라운드에서 실행한다. 초기 버전에서는 이 흐름이 preinstall 훅으로 시작됐기 때문에 패키지 설치만으로 감염이 가능했다.

문제는 이후 버전이다. 8.18.0과 8.20.0에서는 드롭퍼가 설치 훅뿐 아니라 패키지 본체 코드와 CLI 실행 경로에 심어진 것으로 공개 분석에서 설명됐다. 이 경우 npm install --ignore-scripts처럼 설치 스크립트를 차단하는 조치가 일부 위험을 줄일 수는 있어도 완전한 차단책으로 보기 어렵다. 패키지를 불러오거나 CLI를 실행하는 순간 악성 흐름이 시작될 수 있기 때문이다.

분석 자료에서는 컨테이너 매직바이트와 암호화된 문자열, gzip 압축된 다중 플랫폼 바이너리 구조도 확인됐다. 이는 공격자가 단순한 스크립트형 탈취 코드를 넣은 것이 아니라, 분석 지연과 운영체제별 실행을 고려해 준비한 공급망 공격임을 보여준다.

{
  "name": "jscrambler",
  "version": "8.14.0",
  "scripts": {
    "preinstall": "node dist/setup.js"
  }
}

위 형태처럼 초기 버전은 설치 스크립트가 직접 로더를 호출했다. 이후 버전에서는 드롭퍼가 패키지 실행 경로로 옮겨져 설치 단계 방어만으로는 충분하지 않다.

무엇을 훔치고 어떻게 확산했나

IronWorm의 주요 표적은 개발자와 자동화 환경의 자격증명이다. 공개 분석에 따르면 AWS, GCP, Azure 관련 키와 메타데이터 접근 정보, CI/CD 토큰, GitHub 및 npm 인증 정보, 브라우저 세션, 비밀번호 관리자, 암호화폐 지갑이 수집 대상에 포함된다. Claude Desktop, Cursor, Windsurf 같은 AI 개발도구 설정과 API 키, MCP 관련 자격증명도 노린 것으로 보고됐다.

특히 npm 토큰 탈취는 피해를 키우는 핵심 요소다. 악성코드는 감염된 환경의 환경 변수와 .npmrc 등에서 npm 토큰을 찾아 유효성을 확인한 뒤, 다운로드 수가 많은 패키지를 골라 악성 스크립트를 심어 재배포하는 자가전파 기능을 갖춘 것으로 분석됐다. 한 개발자의 빌드 환경에서 끝나는 문제가 아니라, 배포 권한이 있는 패키지를 통해 다른 사용자에게 이어질 수 있는 구조다.

수집 데이터 유출에는 Tor 기반 통신과 파일 공유 서비스 전송이 함께 관측됐다. 방어자 입장에서는 temp.sh 업로드, Tor 관련 다운로드, 비정상적인 외부 연결, 알려진 C2 IP 접근 여부를 프록시·방화벽·EDR 로그에서 확인해야 한다.

개발 조직이 먼저 확인할 것

가장 먼저 lockfile과 패키지 설치 이력을 확인해야 한다. package-lock.json, npm-shrinkwrap.json, CI 캐시, 아티팩트 저장소, 컨테이너 이미지 빌드 로그에 영향 버전이 남아 있는지 점검한다.

npm ls jscrambler
grep -R '"jscrambler"' package-lock.json npm-shrinkwrap.json pnpm-lock.yaml yarn.lock 2>/dev/null

node_modules/jscrambler/dist/에 setup.js 또는 intro.js가 있는지도 확인한다. 다만 파일이 없다고 해서 안전하다고 단정하면 안 된다. CI 캐시 정리, 이미지 재빌드, 패키지 재설치 과정에서 흔적이 사라졌을 수 있기 때문이다. 설치 이력과 로그를 함께 봐야 한다.

다음으로 감염 의심 호스트의 임시 디렉터리와 백그라운드 프로세스를 확인한다. Linux는 사용자 systemd 서비스와 cron, macOS는 ~/Library/LaunchAgents, Windows는 스케줄 작업과 시작 폴더를 점검한다. 개발자 노트북보다 CI 러너에서 더 넓은 권한과 배포 토큰이 노출될 수 있으므로, 빌드 서버를 우선순위에 둔다.

네트워크 로그에서는 공개 분석에서 언급된 C2 IP 37.27.122.124, 57.128.246.79, temp.sh 업로드, archive.torproject.org 다운로드 접근을 확인한다. 단, IOC는 빠르게 바뀔 수 있으므로 IOC 매칭만으로 종료하지 말고 자격증명 회전과 배포 권한 점검을 병행해야 한다.

대응 체크리스트

• 영향 버전 8.14.0, 8.16.0, 8.17.0, 8.18.0, 8.20.0 설치 이력을 확인한다.
• 영향 버전이 확인되면 패키지를 제거하고 8.22.0 이상으로 업데이트하거나 검증된 안전 버전으로 고정한다.
• 해당 환경에서 접근 가능했던 npm 토큰, GitHub 토큰, 클라우드 키, CI/CD 비밀값, AI 개발도구 API 키를 모두 폐기하고 재발급한다.
• npm 배포 권한이 있는 계정은 MFA 상태, 토큰 권한 범위, 토큰 만료 정책을 재점검한다.
• CI 러너와 빌드 캐시, 컨테이너 이미지, 내부 패키지 미러에 악성 버전이 남아 있지 않은지 확인한다.
• 지갑·브라우저·비밀번호 관리자·협업 도구 세션이 노출됐을 가능성을 검토하고 필요한 경우 세션을 강제 만료한다.
• preinstall 등 lifecycle script 실행 정책을 재검토하되, 이번 사례처럼 본체 코드에 드롭퍼가 들어갈 수 있다는 점을 반영해 패키지 무결성 검증을 추가한다.
• lockfile 변경, 새 패키지 버전 도입, npm publish 이벤트를 CI 보안 게이트와 알림 대상으로 올린다.

재발 방지를 위한 운영 포인트

이번 사건은 npm 패키지 하나의 문제가 아니라 개발 조직의 배포 신뢰 체계를 점검하게 만드는 사례다. 패키지명과 배포 계정이 정상이어도 계정이 탈취되면 정상 업데이트처럼 악성 코드가 들어올 수 있다.

따라서 패키지 공급망 방어는 취약점 스캔만으로 끝나지 않는다. 새 버전 도입 시 lockfile diff를 검토하고, npm lifecycle script 변경을 자동으로 탐지하며, 빌드 환경의 비밀값을 최소 권한·짧은 수명으로 관리해야 한다. 배포 토큰은 장기 토큰보다 자동화된 짧은 수명 토큰을 우선하고, publish 권한은 필요한 패키지와 워크플로우로 제한하는 편이 안전하다.

AI 개발도구 API 키가 탈취 대상에 포함됐다는 점도 중요하다. 최근 개발 환경은 코드 저장소, 클라우드, CI/CD, AI 도구, MCP 서버가 연결된 형태로 바뀌고 있다. 한 패키지 설치가 단순한 로컬 감염을 넘어 내부 데이터 접근, 코드 변경, 추가 패키지 배포로 이어질 수 있다. 개발 조직은 AI 도구 설정 파일과 에이전트 연결 권한도 기존 보안 점검 범위에 포함해야 한다.

결론

jscrambler npm 계정 탈취 사건은 신뢰된 개발 도구가 공급망 공격의 전달 경로로 바뀔 수 있음을 보여준다. 악성 버전은 짧은 시간 동안만 노출됐지만, npm과 CI/CD의 자동화 특성상 짧은 노출도 충분히 위험하다.

영향 버전 설치 이력이 있는 조직은 패키지 제거와 업데이트에서 멈추지 말아야 한다. npm 토큰, 클라우드 키, CI/CD 비밀값, GitHub 자격증명, AI 개발도구 API 키를 노출된 것으로 보고 회전해야 한다. 동시에 lockfile 무결성, lifecycle script 감시, 배포 토큰 최소 권한화, CI 러너 격리를 통해 다음 공급망 공격이 같은 경로로 확산되지 않도록 막아야 한다.

참고자료

• SK쉴더스 EQST NOW, jscrambler npm 계정 탈취로 IronWorm 정보탈취 악성코드 유포
• Socket, jscrambler npm Supply Chain Attack
• JFrog, IronWorm Returns as jscrambler, Rustier Than Ever
• The Hacker News, Compromised jscrambler 8.14.0 npm Release Drops Rust Infostealer

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.