에스코어 인사이트
원문 번역에 앞서 국내 개발/보안 조직에서 확인해볼 관점만 간단히 정리했습니다.
•
npm 패키지 유입 경로 관리: 개발자 PC·CI/CD 러너·내부 캐시·미러에서 반입되는 패키지와 버전을 식별하고 설치 경로와 사용처를 추적
•
설치 전 패키지 검증: 신규·변형 패키지의 출처, 게시 이력, 버전 패턴, 무결성과 비정상 설치 행위를 확인한 뒤 개발 환경 반입 여부를 결정
•
감염 호스트 대응: 의심 시스템을 격리하고 지속성·2단계 페이로드를 제거한 뒤 노출 가능 자격증명을 폐기·교체하고 클린 환경에서 재검증
핵심 요약
•
Sonatype Research Labs는 npm에서 확산 중인 ‘Flooding Dropper’ 악성 패키지 캠페인을 추적하고 있으며, 게시 시점 기준 846개 소프트웨어 구성요소가 영향을 받았습니다.
•
공격자는 npm 계정과 패키지 생성 과정의 일부를 자동화한 것으로 보이며, bigops, bnpl 같은 문자열을 다른 단어와 조합하고 35.x.y 계열과 같은 반복적인 버전 패턴을 사용합니다.
•
악성 패키지가 설치되면 2단계 페이로드를 내려받아 실행하며, 공격 성공 가능성을 높이기 위해 여러 전달 방식을 사용합니다.
•
Sonatype은 이 캠페인을 sonatype-2026-005660으로 추적하고 있습니다. 영향을 받은 조직은 해당 호스트를 침해된 것으로 간주하고 패키지를 제거한 뒤, 2단계 페이로드 실행 여부와 지속성을 조사해야 합니다. 환경 정리를 완료한 후에 노출된 자격증명을 교체해야 합니다.
캠페인 개요
2026년 8월 5일 OpenSourceMalware 연구진은 Windows·Linux·macOS에 운영체제별 바이너리를 전달하는 악성 npm 패키지 bigops-backend를 보고했습니다. Sonatype Research Labs는 이를 더 큰 규모의 진행 중인 캠페인의 일부로 확인했으며, 게시 시점 기준 846개 구성요소가 연관된 것으로 파악했습니다.
공격자는 하나의 게시자 계정에 집중하지 않고 다수의 npm 계정을 생성해 각 계정에서 소수의 패키지를 배포합니다. 패키지명에는 bigops, bnpl 같은 문자열이 반복적으로 나타나며, 소스 코드는 변수명이나 URL 처리 방식 등을 조금씩 바꾸지만 실제 악성 행위는 유사합니다.
Flooding Dropper의 동작 방식
악성 패키지는 설치되거나 import될 때 실행될 수 있습니다. 첫 단계 JavaScript 로더는 다음 순서로 동작합니다.
1.
환경 변수와 로컬 상태 마커를 확인해 실행 여부를 판단합니다.
2.
운영체제와 프로세서 아키텍처를 식별하고 Windows·Linux·macOS에 맞는 바이너리를 선택합니다.
3.
여러 하드코딩된 원격 호스트를 대상으로 HTTPS를 통해 바이너리 다운로드를 시도합니다.
4.
직접 HTTPS 다운로드가 실패하면 DNS TXT 레코드를 사용하는 대체 전달 방식으로 전환합니다.
5.
DNS TXT 응답을 통해 전달된 데이터를 다시 조립하고 디코딩합니다.
6.
복원한 바이너리를 임시 디렉터리에 기록하고, Unix 계열 시스템에서는 실행 권한을 부여합니다.
7.
바이너리를 분리된 백그라운드 프로세스로 실행합니다.
이렇게 분리된 프로세스로 실행하면 npm 설치 과정이나 부모 Node.js 프로세스가 종료되더라도 내려받은 바이너리가 계속 실행될 수 있습니다. 또한 DNS TXT 방식은 특정 다운로드 호스트를 차단하더라도 다른 전달 경로를 통해 페이로드가 도착할 수 있게 합니다.
2단계 페이로드의 회피와 지속성
초기 분석에 따르면 다운로드된 Windows 바이너리 자체가 추가 페이로드를 불러오는 로더입니다. 다운로드된 이후 Sonatype은 다음과 같은 정교한 다운로더 동작을 관찰했습니다.
•
모니터링과 스캐닝을 방해하기 위해 Event Tracing for Windows(ETW)와 Antimalware Scan Interface(AMSI) 기능을 패치합니다.
•
디버거, 가상머신, 샌드박스 및 보안 제품이 있는지 확인하고, 재실행에 사용할 수 있도록 자신을 사용자 AppData 디렉터리 아래의 특정 경로에 복사합니다.
•
Registry Run 키와 예약 작업을 이용해 악성코드가 이후에도 다시 실행되도록 설정합니다.
•
원격 /pkg/update_win.exe 경로에서 암호화된 페이로드를 내려받아 복호화한 뒤, 해당 페이로드를 메모리에 직접 적재해 실행합니다.
이 방식은 페이로드를 일반 실행 파일처럼 디스크에 저장해 실행하지 않고, 메모리에 직접 적재해 실행할 수 있게 합니다. 이 때문에 2단계 페이로드는 디스크 중심의 보안 통제에서 탐지하기 더 어려워질 수 있습니다.
자동화가 대응을 어렵게 만드는 이유
대규모 악성 패키지 게시 자체는 새로운 일이 아닙니다. 다수의 일회성 계정에 패키지를 분산해 배포하면 대응과 차단이 더 어려워집니다.
Flooding Dropper 공격자는 무작위로 생성된 것처럼 보이는 계정명을 사용하며, 각 계정에서는 소수의 패키지만 게시합니다. 따라서 활동량이 많은 특정 게시자 하나를 제거하더라도 전체 공격 캠페인이 끝났다고 볼 수는 없습니다.
이 방식은 npm의 관리·검토 과정에도 부담을 줍니다. 공격자가 계속 새 계정과 패키지를 만들어내는 동안, 각 계정과 패키지를 개별적으로 식별하고 검토한 뒤 제거해야 할 수 있습니다.
캠페인의 패키지 명명 방식도 이미 진화하고 있습니다. 많은 패키지에 bigops 또는 bnpl이 포함돼 있지만, Sonatype Research Labs는 이와 다른 이름을 사용하는 추가 패키지도 관찰했습니다. 또한 많은 패키지가 35.x.y로 시작하는 버전 번호를 공유하고 있어, 서로 연관된 패키지를 식별하는 또 하나의 상관관계 단서가 됩니다. 이러한 특징은 현재 관련 패키지를 식별하는 데 도움이 되지만, 지속적으로 사용할 수 있는 탐지 기준은 아닙니다. 캠페인이 변화하면 이름과 버전 패턴 모두 바뀔 수 있기 때문입니다.
이처럼 자동화된 방식 덕분에 공격자는 적은 비용으로 수많은 계정과 패키지 변종을 계속 만들어낼 수 있습니다. 그 결과 단순한 계정 차단이나 이름 기반 deny list만으로는 캠페인의 확산과 재등장을 따라가기 어려워집니다.
영향을 받은 경우의 대응
먼저 sonatype-2026-005660으로 추적되는 패키지가 조직 환경 어디에서든 다운로드되거나 설치됐는지 확인해야 합니다. 확인 대상에는 개발자 워크스테이션, CI/CD 러너와 빌드 에이전트, 내부 저장소와 패키지 캐시, 테스트 시스템, 프로덕션과 인접한 인프라가 포함됩니다.
악성 의존성을 제거하는 것은 필요하지만 그것만으로는 충분하지 않습니다. 해당 패키지가 설치된 호스트는 침해된 것으로 간주하고, 2단계 페이로드 실행과 지속성 확보 여부를 포함한 후속 활동을 조사해야 합니다. 특히 자격증명 교체는 감염 환경을 정리하기 전에 먼저 수행하기보다, 지속성과 악성 페이로드를 제거하고 환경을 정리한 뒤 진행해야 합니다.
1.
영향을 받은 시스템을 격리하고, 알려진 지속성 메커니즘과 침해 지표(IOC)가 남아 있는지 확인합니다.
2.
프로세스 실행 기록, DNS 질의, 프록시 로그, 엔드포인트 텔레메트리를 검토해 2단계 페이로드를 내려받으려 한 흔적이나 실제 다운로드가 있었는지 확인합니다.
3.
Node.js, npm 또는 임시 디렉터리에서 시작된 분리(detached) 프로세스가 있는지 조사합니다. npm 설치나 부모 Node.js 프로세스가 끝난 뒤에도 계속 실행된 프로세스가 있는지도 확인합니다.
4.
이후 실행된 추가 실행 파일이나 메모리 내 페이로드를 식별합니다.
5.
지속성을 제거하고 필요하면 영향을 받은 시스템을 재빌드합니다.
6.
환경 정리와 지속성 제거를 마친 뒤 npm, GitHub, 클라우드, CI/CD 및 기타 개발 관련 자격증명 가운데 노출됐을 가능성이 있는 값을 폐기·교체합니다.
7.
lockfile, 의존성 캐시, 컨테이너 레이어, 내부 패키지 저장소와 미러를 확인해 악성 패키지나 해당 버전의 사본이 남아 있거나 다시 제공될 수 있는지 점검합니다.
8.
패키지를 교체하거나 다시 설치하기 전에 패키지명과 의존성 철자를 다시 확인해, 유사한 이름의 다른 패키지나 잘못된 의존성을 다시 선택하지 않도록 합니다.
패키지명은 단서일 뿐, 그것만으로는 충분하지 않다
초기에 나타난 bigops와 bnpl 명명 규칙은 이 캠페인의 연관성을 파악하는 데 도움이 됐습니다. 하지만 방어자가 이것만을 탐지 기준으로 삼아서는 안 됩니다.
공격자는 악성코드의 목적 자체를 바꾸지 않고도 패키지 이름은 쉽게 변경할 수 있습니다. 정확한 시그니처 일치를 피하기 위해 소스 코드를 조금씩 수정하는 경우도 마찬가지입니다. 알려진 패키지명을 차단 목록으로 관리하는 것은 이미 확인된 위협을 막는 데는 유효하지만, 이후 등장할 변종까지 탐지하려면 행위와 코드 유사성을 함께 분석해야 합니다.
Sonatype Research Labs는 새로운 패키지와 인프라, 페이로드 세부 정보가 확인되는 대로 sonatype-2026-005660 식별자로 이 캠페인을 계속 추적할 예정입니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide