공개 패키지 레지스트리를 겨냥한 공급망 공격이 빌드 자동화 단계까지 깊이 침투하고 있다. The Hacker News는 jscrambler 8.14.0이 npm 배포 과정에서 변조되어, 설치가 진행되는 그 순간에 러스트(Rust) 인포스틸러를 드롭했다고 2026년 7월 11일 보도했다. 이 사례는 별도의 import나 CLI 호출 없이 npm 패키지 설치만으로 감염이 성립한다는 점에서 운영팀과 보안팀의 즉각적인 대응 점검을 요구한다.
핵심 요약
- jscrambler 8.14.0 패키지의 preinstall 훅에서 러스트 기반 인포스틸러가 자동 실행되어, 설치 시점 자체가 감염 지점이 된다.
- 윈도우, macOS, 리눅스 세 운영체제용 네이티브 바이너리가 동시 제공되어 크로스플랫폼 영향 범위가 확인된다.
- 동일 시기에 Injective Labs SDK(@injectivelabs/sdk-ts@1.20.21)에서도 npm 벡터 침해가 보고되며, 생태계 전반의 공급망 감사가 필요하다.
패키지명 한 줄과 설치 훅 한 번으로 빌드 파이프라인 전체가 잠재적 표적이 되며,, lockfile 고정과 훅 감사 같은 사전 통제가 필수 점검 항목으로 부상했다.
1. 사건 개요: jscrambler 8.14.0이 어떻게 변조되었나
The Hacker News에 따르면, 코드 난독화 도구로 널리 쓰이는 jscrambler의 8.14.0 버전이 npm에 게시된 직후 변조 판정으로 분류되었다. 변조는 패키지 메타데이터가 아니라 패키지 내부의 설치 스크립트 구간에서 이루어진 것으로 분석되며, 일반적인 install 흐름에서 자동으로 호출되는 preinstall 훅이 핵심 벡터로 작용했다. 단순히 라이브러리를 불러오는 단계가 아니라 의존성이 잠기는 시점부터 위협이 활성화된다는 점이 기존 침해 사례와 구별되는 특징이다.
2. 악성 페이로드의 동작 방식: preinstall 훅과 러스트 인포스틸러
문서에 따르면 변조된 패키지는 preinstall 훅에서 운영체제를 판별한 뒤, 해당 환경에 맞는 러스트로 작성된 네이티브 바이너리를 내려받아 실행한다. 인포스틸러로 분류된 이 페이로드는 호스트의 자격 증명, 토큰, 브라우저 저장 데이터, 암호화폐 지갑 정보 등을 수집해 외부 인프라로 송신하는 것으로 추정된다. 사전 import나 CLI 호출 없이도 감염이 성립한다는 점은, 개발자가 의존성을 새로 추가하거나 기존 의존성을 재설치하는 평범한 작업만으로 악성코드가 실행될 수 있음을 의미한다.
| 구분 | 내용 |
|---|---|
| 패키지명 | jscrambler |
| 영향 버전 | 8.14.0 |
| 배포 채널 | npm 공개 레지스트리 |
| 악성 동작 위치 | preinstall 훅 (npm install 실행 시 자동 호출) |
| 드롭되는 악성코드 | 러스트(Rust) 인포스틸러 |
| 대상 운영체제 | Windows, macOS, Linux 각 1종 네이티브 바이너리 |
| 감염 트리거 | import 또는 CLI 호출이 아닌 패키지 설치 자체 |
| 동일 시점 관련 사건 | Injective Labs SDK(@injectivelabs/sdk-ts@1.20.21) 악성 npm 배포 |
3. 크로스플랫폼 영향 범위와 Injective Labs 사례가 시사하는 점
윈도우, macOS, 리눅스 세 환경 각각에 대응하는 네이티브 바이너리가 준비된 것은 단일 플랫폼에 머무르지 않는 침해를 전제한 설계로 해석된다. 데스크톱 개발자, 서버 운영자, macOS 기반 빌드 머신을 사용하는 조직이 모두 잠재 표적이 되며, 특정 운영체제에 편중된 방어 전략만으로는 충분하지 않다. 더욱이 같은 시기에 Injective Labs의 GitHub 저장소가 침해되어 악성 npm 패키지가 배포된 사실이 함께 보고됨에 따라, npm이라는 단일 벡터를 통한 연속 사고 가능성이 제기된다. 두 사건의 공격자가 동일한지는 확인되지 않았으나, 공개 저장소와 패키지 레지스트리를 잇는 공격 표면이 광범위하게 확장되고 있음은 분명하다.
4. 개발 조직이 즉시 점검해야 할 항목
4.1 패키지 무결성 검증과 lockfile 고정
가장 먼저 적용 가능한 조치는 package-lock.json 또는 yarn.lock, pnpm-lock.yaml 같은 lockfile을 통한 버전 고정과 무결성 해시 검증이다. npm은 package-lock에 각 패키지의 integrity 필드를 기록하며, 이를 통해 변조된 패키지가 끼어들었을 때 설치 단계에서 차단할 수 있다. 또한 SBOM(소프트웨어 자재명세)을 주기적으로 생성해 의존성 그래프를 점검하고, 신뢰 등급이 낮은 패키지에 대해서는 별도 레지스트리 미러나 프라이빗 프록시를 도입하는 방안이 권고된다.
4.2 preinstall, postinstall 훅 감사 절차
preinstall과 postinstall 같은 라이프사이클 훅은 본질적으로 임의 코드를 실행하는 통로이므로, CI/CD 파이프라인에서 npm install –ignore-scripts 옵션을 기본값으로 적용하고, 필요한 훅만 허용 목록 방식으로 허용하는 정책이 필요하다. 또한 의존성 트리에서 새로 추가되거나 갱신된 패키지의 훅 스크립트 내용을 정기적으로 검토하고, 의심스러운 base64 인코딩, 외부 다운로드 요청, OS 디텍션 패턴 등을 정적 분석으로 탐지하는 절차가 효과적인 것으로 분석된다.
4.3 사후 침해 흔적 분석 절차
이미 jscrambler 8.14.0을 설치한 이력이 있다면, 빌드 머신과 개발자 PC에서 다음 항목을 우선 조사해야 한다. 첫째, /tmp, %TEMP%, ~/Library/Caches 하위에 생성된 의심스러운 러스트 바이너리 흔적을 찾는다. 둘째, npmrc, .gitconfig, ~.ssh, ~.aws 같은 자격 증명 파일의 최근 수정 시각과 접근 로그를 확인한다. 셋째, EDR 로그와 네트워크 로그에서 평소와 다른 외부 도메인 접속 시점을 식별한다. 공격자 인프라의 정확한 위치는 공개되지 않은 것으로 보이며, IOC(침해 지표) 확정까지는 패킷 캡처와 DNS 로그 기반의 행동 분석이 유효하다.
5. 향후 전망: 빌드 자동화 단계로 깊어지는 공급망 공격
jscrambler 사건은 단순히 특정 패키지에 국한된 일회성 침해가 아니다. 빌드 자동화는 개발 생산성과 직결되는 영역이라 일시 차단이 사실상 어렵고, 한 번의 감염으로 산출된 결과물이 여러 하위 프로젝트에 전파될 수 있다. 업계에서는 향후 인포스틸러를 넘어 백도어, 랜섬웨어 로더, 클라우드 자격 증명 탈취형 모듈까지 같은 벡터로 유입될 가능성에 주목하고 있다. 따라서 패키지 레지스트리 측의 신뢰 강화와 함께, 사용자 조직의 빌드 파이프라인 자체에 대한 통제 강화가 동시에 추진되어야 할 것으로 분석된다.
실무 핵심 체크리스트
- lockfile을 저장소에 커밋하고 integrity 해시를 강제 검증한다.
- CI/CD의 npm install 단계에서 –ignore-scripts를 기본으로 적용한다.
- 신규 또는 갱신 패키지의 preinstall, postinstall 훅 내용을 정기 감사한다.
- SBOM을 구축하고 변동 의존성에 대해 알림을 받는다.
- 개발 및 빌드 호스트에서 러스트 바이너리 드롭 흔적을 사후 점검한다.
참고 출처: