---
title: "북한 해커, npm 유명 패키지 베껴 개발자 PC부터 뚫었다"
published: 2026-07-06T01:05:02.794Z
canonical: https://jeff.news/article/4692
---
# 북한 해커, npm 유명 패키지 베껴 개발자 PC부터 뚫었다

북한 연계로 추정되는 공격자가 npm에서 유명 자바스크립트 패키지를 흉내 낸 악성 패키지 6종을 유포한 정황이 나왔다. 패키지 설명과 홈페이지까지 원본처럼 꾸미고, 샌드박스 회피와 다단계 다운로드로 정적 분석을 피한 게 핵심이다.

- 북한 연계로 추정되는 공격자가 npm 생태계를 노리고 악성 패키지 6종을 뿌린 정황이 나옴
  - 제이프로그 보안연구소가 발견한 사례고, 자바스크립트 개발자들이 자주 쓰는 공식 저장소 npm이 공격 무대였음
  - 공격 방식은 유명 패키지를 정교하게 베낀 뒤 내부에 악성 코드를 심는 전형적인 소프트웨어 공급망 공격임

- 포인트는 ‘대충 비슷한 이름’ 수준이 아니라, 개발자가 눈으로 봐도 헷갈리게 만든 데 있음
  - 공격자는 월 120만 건 이상 다운로드되는 검증된 유명 패키지를 복제 대상으로 삼음
  - 패키지 설명서와 홈페이지 주소까지 원본과 똑같이 꾸며서, 검색 결과만 보고 설치하면 구분이 거의 안 되게 만들었음
  - 개발자들이 패키지 전체 이름보다 핵심 단어만 검색하는 습관을 노린 것도 꽤 현실적인 공격 포인트임

> [!WARNING]
> 패키지 이름, 설명, 홈페이지가 멀쩡해 보여도 안전하다는 뜻은 아님. 이번 사례는 ‘눈으로 확인’하는 검증 방식이 얼마나 쉽게 깨지는지 보여줌.

- 악성코드는 샌드박스 회피까지 넣어서 보안 분석을 피해 감
  - 실행 중인 컴퓨터 환경을 스스로 분석한 뒤, 보안 제품의 격리 환경인 샌드박스라고 판단하면 악성 동작을 멈춤
  - 겉으로는 정상 프로그램처럼 행동하니, 자동 분석 시스템에서는 깨끗한 패키지처럼 보일 수 있음

- 더 귀찮은 부분은 실제 악성코드 본체를 패키지 안에 바로 넣지 않았다는 점임
  - 개발자가 패키지를 설치하고 실행하는 순간, 외부 명령 제어 서버에서 진짜 악성코드를 몰래 내려받는 구조였음
  - 그래서 패키지 파일만 정적으로 훑는 방식으로는 악성 여부를 잡기 어려움
  - 정상 코드 사이에 악성 기능을 숨기는 난독화까지 섞여 있어서 분석 비용도 올라감

- 공격 목표는 일반 사용자가 아니라 개발자 PC였음
  - 개발자 환경을 먼저 감염시키고, 거기서 기업 소스코드와 핵심 인프라로 들어가는 그림임
  - 화면 실시간 감시, 원격 제어권 탈취, 가상화폐 지갑 정보, 로그인 자격 증명 탈취가 주요 목적으로 분석됨
  - 개발자 로컬에 저장된 토큰이나 배포 키가 많을수록 피해가 커지는 구조임

- 제이프로그는 이번 수법이 북한 정찰총국 연계 조직으로 알려진 라자루스의 활동 양상과 맞아떨어진다고 봄
  - 다단계 공격 구조, 위장 방식, 정보 탈취와 원격 제어 패턴이 과거 라자루스 사례와 유사하다는 설명임
  - 라자루스는 김수키, 안다리엘과 함께 북한의 대표 해킹 조직으로 꼽히고, 금융기관과 가상자산 거래소 공격 이력이 있음

- 일부 악성 패키지는 이미 차단됐지만, 문제는 이미 설치한 개발자와 기업임
  - 저장소에서 내려갔다고 로컬 프로젝트와 사내 캐시, 잠금 파일까지 자동으로 깨끗해지는 건 아님
  - 패키지 락 파일, 사내 프록시 저장소, CI 캐시, 개발자 PC의 설치 이력을 같이 확인해야 함

---
## 기술 맥락

- 이번 공격에서 중요한 건 npm이라는 저장소 자체보다, 개발자가 의존성을 가져오는 경로가 신뢰 경계 안으로 들어와 있다는 점이에요. 패키지를 설치하는 순간 postinstall 스크립트나 런타임 코드가 개발자 PC에서 실행될 수 있거든요.

- 다단계 다운로드를 쓴 이유는 정적 분석을 피하기 위해서예요. 패키지 안에 악성코드 본체를 넣으면 저장소 스캐너에 걸릴 확률이 커지지만, 설치 후 명령 제어 서버에서 내려받으면 분석 시점과 실제 감염 시점을 분리할 수 있어요.

- 샌드박스 회피가 붙은 것도 같은 맥락이에요. 보안 제품이 격리 환경에서 패키지를 실행해 봐도, 악성코드가 “여긴 분석 환경이네”라고 판단하면 조용히 빠져나가니까 탐지 난도가 올라가요.

- 실무에서는 패키지 이름 확인만으로는 부족해요. lockfile 변경 리뷰, 새 의존성 자동 차단, 설치 스크립트 제한, 개발자 PC의 비밀값 분리 같은 통제가 같이 들어가야 하는 이유가 여기에 있어요.

## 핵심 포인트

- 월 120만 건 이상 다운로드되는 유명 패키지를 모방한 악성 npm 패키지 6종이 발견됨
- 설치 시점에 외부 명령 제어 서버에서 실제 악성코드를 내려받는 다단계 구조를 사용함
- 샌드박스 환경을 감지하면 악성 동작을 멈춰 보안 분석을 회피함
- 개발자 PC를 발판으로 기업 소스코드, 인프라, 지갑 정보, 로그인 자격 증명을 노린 공격으로 분석됨

## 인사이트

이건 단순히 ‘이상한 패키지 받지 말자’ 수준이 아님. 개발자 로컬 환경이 곧 회사 내부망으로 들어가는 입구가 됐다는 점에서, 패키지 설치 정책과 비밀값 관리가 같이 봐야 할 문제가 됨.