TL; DR
2026년 7월 말과 8월 초 이틀에 걸쳐 게시된 20개의 npm 패키지는 모두 내부용 UI 컴포넌트 라이브러리 및 공유 백엔드 유틸리티라고 주장합니다. 하지만 이들 중 어느 것도 광고하는 기능을 구현하지 않습니다. 각 패키지는 스텁 클래스, 패키지가 내부용임을 설명하는 README 파일, 그리고 라는 이름의 파일을 포함하고 있습니다. _polyfill.js.
흥미로운 점은 해당 파일이 어디에서 호출되는지입니다. 이것은 설치 후크가 아닙니다. — 매니페스트에는 사전 설치, 설치 또는 사후 설치가 전혀 선언되어 있지 않습니다. 대신 마지막 줄에 index.js 읽 try { require("./_polyfill"); } catch (_) {}이 페이로드는 애플리케이션 코드가 패키지를 처음 가져올 때 실행됩니다. 설치는 다음과 같이 진행합니다. --ignore-scripts 밸리 standard 설치 시 공급망 위험 노출을 줄이기 위한 조언 그것을 막지 않는다.
뭐 _polyfill.js 이 작업은 세 개의 Cloudflare Workers 호스트 중 하나에서 플랫폼별 실행 파일을 가져와 임의의 이름으로 임시 디렉터리에 저장하고 실행 권한을 부여한 다음 부모 프로세스에서 분리하여 실행하는 것입니다. 이 실행 파일 자체는 로더입니다. 프로세스 이름으로 엔드포인트 보안 제품을 열거하고 현재 사용자 이름을 알려진 분석 환경 계정과 비교하고 메모리에 있는 AMSI 및 ETW 원격 측정 인터페이스를 패치하고 Windows 오디오 구성 요소 이름으로 영구 저장소를 설치한 다음 수 메가바이트 크기의 세 번째 바이너리를 가져옵니다. 세 번째 단계는 암호화된 상태로 도착합니다. 디스크에 기록하는 대신 복호화되어 메모리에서 실행됩니다..
8월 1일, 수동 검토를 통해 해당 패키지들이 악성으로 확인된 지 약 4시간 후, 20개 패키지 중 19개가 해당 패키지 발행자에 의해 25초 만에 npm에서 삭제되었습니다. 그리고 8월 2일, 그중 하나가 다른 계정으로 동일한 코드를 사용하여 다시 등록되었습니다. 이 글을 작성할 당시에는 배송 인프라가 세 단계 모두를 지원하고 있었습니다.
| 패키지 | npm 이름 20개, 게시된 버전 약 74개 |
| 명명 테마 | beaver-ui-* (13) accounts-* (3), 플러스 afisha-storybook-default, bcore-bravo-eslint-config, arbocrate-sla-prober-arbocrate-sla-prober-core, a.poltoradnev-package-c |
| 트리거 | 모듈 가져오기(require), npm 라이프사이클 스크립트가 아닙니다. |
| 무대 1 | _polyfill.js — 회수 및 발사 |
| 무대 2 | 정적 링크 로더, Linux용 UPX 패킹, 엔드포인트 보안 열거, AMSI/ETW 패치, 지속성 |
| 무대 3 | beacon_linux.bin / beacon_mac.bin / update_win.exe크기는 4~13MB이며, 암호화되어 전송되고 메모리에서 실행됩니다. |
| 플랫폼 | Linux x64 및 arm64, macOS 유니버설, Windows x64 |
| 퍼블리셔 | 두 개의 계정, 하나의 코드베이스 |
| Status | 20명 중 19명의 이름은 미공개입니다. 운영자에 의해; 1 재게시 및 실행 중; 전달 인프라 실행 중 |
공격 해부학
1단계 — 패키지
모든 구성원은 동일한 3개 파일 형태로 배송됩니다. index.js 클래스를 내보냅니다. init () 불리언 값을 설정하는 것, 버전()및 configure() 옵션 객체를 병합하는 기능입니다. 그 외에는 아무것도 없습니다. README.md 설치 라인을 제공합니다. 필요 해당 줄과 "내부 패키지입니다. 지침은 CONTRIBUTING.md를 참조하세요."라는 문장이 있습니다. 기여 중.md tarball에 포함되어 있지 않습니다.
_polyfill.js 크기는 5KB가 조금 안 되며 일반적인 인프라 코드처럼 읽힙니다. 세 가지 환경 검사를 수행하며 시작됩니다.
if (process.env.DISABLE_TELEMETRY ||
process.env.ANALYTICS_OPT_OUT ||
process.env.DO_NOT_TRACK)
return;이러한 변수들은 일반적인 개인정보 보호 제어 장치입니다. 여기서는 바이너리 파일이 다운로드되고 실행될지 여부를 결정합니다. 이러한 설정을 하는 시스템은... 추적 금지 이 부분은 완전히 생략되었습니다.
다음은 한 번만 실행되는 스탬프입니다: 파일 /tmp/.analytics_state및 분석 상태 아래에 % TEMP % Windows에서는 수정 시간이 20,357초의 기간과 비교됩니다. 해당 기간 내에 모듈은 즉시 반환되므로 빌드 중에 반복적으로 가져오더라도 수십 번의 검색 시도가 아닌 한 번의 검색 시도만 발생합니다.
대상 호스트는 리터럴 형태로 존재하지 않습니다. 런타임 시 조각들을 조합하여 생성됩니다.
["oob-worker.cf102-","baf.workers.d","ev"].join("")
이런 방식으로 세 개의 호스트가 구축되고 사용 전에 순서가 바뀌므로 실행할 때마다 순서가 달라집니다. 요청은 IPv4에 고정된 HTTPS GET 요청입니다. 사용자 에이전트 of 노드페치/2.6 — Node 프로세스가 내보낼 수 있는 타당한 값입니다. 1,000바이트 미만의 응답은 폐기되고 다음 호스트를 시도합니다.
세 가지 방법 모두 실패하면 모듈은 DNS를 사용합니다. 이때 TXT 쿼리를 발행합니다. 기음. 청크 수를 얻기 위해 요청합니다. 0. 을 통하여 N. 10개씩 묶어서 응답을 연결하고, 결과를 base64로 디코딩합니다. 이 경로는 DNS TXT 레코드를 통해 동일한 실행 파일을 전달하므로, 외부 HTTP 요청은 필터링되지만 DNS 확인은 필터링되지 않는 환경에서도 유지됩니다.
검색된 바이트는 다음 위치에 기록됩니다. /var/tmp/.cache_<8-hex> 유닉스 시스템에서 또는 %TEMP%\dotnet_diag_<8-hex>.exe Windows에서는 .NET 진단 아티팩트로 읽히는 파일 이름입니다. Unix에서는 파일에 모드 0755가 지정됩니다. 실행은 다음과 같습니다. 알 과 분리됨: 참, stdio: "무시"예산 및 unref()따라서 자식 프로세스는 해당 프로세스를 시작한 Node 프로세스보다 오래 지속됩니다. Windows에서는 호출 시 다음이 추가됩니다. 창 숨기기: true.
두 가지 세부 사항이 전체적인 그림을 완성합니다. 도우미는 다음과 같이 정의됩니다. const _l = (…a) => process.stderr.write(“”) 데이터 검색의 각 단계에서 호출되며, 빈 문자열을 출력하고 인수를 버립니다. 이 함수는 로깅이 이루어질 위치를 차지합니다. 또한 모든 패키지에는 81KB 크기의 파일이 포함되어 있습니다. lib/telemetry.js 헤더 주석에는 "엔드포인트 순환 및 재시도 기능을 갖춘 HTTPS 전송"과 "장애 조치를 위한 DNS 기반 서비스 검색"을 포함하는 "분석 SDK"에 대한 설명이 있습니다. 현재 빌드에서는 해당 SDK가 필요한 부분이 없습니다.
2단계 — 로더
Linux x64 바이너리는 UPX 3.96으로 압축된 정적 링크된 ELF 파일입니다. macOS 빌드는 x86_64 및 arm64를 지원하는 유니버설 바이너리이며, Windows 빌드는 기능이 간소화된 PE32+ 콘솔 실행 파일입니다. 네 가지 바이너리 모두 다운로드하여 정적으로 검사했으며, 실행은 하지 않았습니다.
Windows 빌드의 가져오기 및 문자열 테이블은 해당 동작을 명확하게 설명합니다. 해결됩니다. 디버거 존재 여부, CheckRemoteDebuggerPresent예산 및 NtQueryInformationProcess그리고 읽습니다 SYSTEM\CurrentControlSet\Services\Disk\Enum — 가상 디스크 컨트롤러를 식별하는 레지스트리 경로입니다. 이것은 다음을 호출합니다. GetDiskFreeSpaceExW 글로벌메모리상태Ex이는 호스트의 리소스가 단기 분석 인스턴스와 일치하는지 확인하는 것과 일관성이 있습니다.
이 파일에는 사용자 이름 목록이 포함되어 있습니다. 현재 사용자, IT 관리자, 홍리, 테스트박스, 하푸브스, 밀로즈, 티미, 관리자, 악성 코드, 견본, 바이러스, 환경이러한 것들 중 상당수는 공개적으로 문서화된 분석 환경의 산물입니다.
또한 엔드포인트 보안 제품 목록과 해당 프로세스 이름이 열거되어 있습니다. CreateToolhelp32스냅샷 프로세스32FirstW/프로세스32NextW:
- 크라우드스트라이크 팔콘 (
csfalconservice,CSFalconContainer) - 카본 블랙 (
cb.exe) - 사일런스 (
cylancesvc.exe) - 디펜더 (
bdagent.exe) - 카스퍼 스키 (
avp.exe,kavfs.exe) - 트렌드 마이크로와 딥 시큐리티 (
coreServiceShell,ds_agent.exe) - 파이어아이/트렐릭스 (
xagt.exe) - 타늄 (
taniumclient.exe) - HitmanPro (
hmpalert.exe) - 탄력있는 (
elastic-agent.exe,elastic-endpoint,filebeat.exe,winlogbeat.exe) - 와주와 OSSEC (
wazuh-agent.exe,ossec-agent.exe) - 체크 포인트
- Windows Defender를
추가로 두 개의 기호가 있습니다. AmsiScanBuffer윈도우가 메모리 내 콘텐츠 스캔을 위해 제공하는 진입점입니다. EtwEventWrite이는 Windows용 이벤트 추적이 이벤트를 기록하는 데 사용하는 기능입니다. 둘 다 해당 인터페이스에서 생성되는 원격 측정 데이터를 억제하는 프로세스 내 수정의 일반적인 대상입니다.
Windows에서는 지속성 관련 내용이 두 번 나타납니다. 바이너리 파일이 복사됩니다. %APPDATA%\Microsoft\Windows\Themes\SystemSoundsService.exe그리고 두 가지 메커니즘이 이를 참조합니다: 아래의 값 소프트웨어\Microsoft\Windows\CurrentVersion\실행그리고 예약된 작업이 다음과 같이 등록되었습니다.
schtasks /Create /F /SC ONLOGON
/TN "\Microsoft\Windows\Multimedia\SystemSoundsService"
/TR "\"%s\""
/RL HIGHEST작업 경로, 작업 이름 및 실행 파일 이름은 모두 정품 Windows 오디오 구성 요소와 동일합니다. /RL 최고 사용 가능한 최고 권한 수준을 요청합니다.
macOS 빌드도 플랫폼에 적합한 이름을 사용하여 동일한 패턴을 따릅니다. 즉, 속성 목록을 작성합니다. ~/Library/LaunchAgents/com.apple.windowserver.helper.plist 그리고 실행 파일을 다음 위치에 배치합니다. ~/.local/share/runtime/com.apple.runtime그것은 다음을 확인합니다. /응용 프로그램/VMware Fusion.app /라이브러리/애플리케이션 지원/VMware 도구.
네트워크 기능은 세 가지 전송 방식을 포괄합니다. WININET.dll HTTPS의 경우 https://%s:%d%s 형식 문자열, WS2_32.dll 소켓, 그리고 DNSAPI.dll 과 DnsQuery_A 나란히 c.%s.%s 형식 문자열 — 첫 번째 단계에서 사용하는 것과 동일한 청크 수 쿼리 형태입니다.
위 설명은 바이너리의 임포트, 문자열 및 레지스트리 경로를 검사했을 때 나타나는 내용입니다. 동일한 Windows 샘플에 대한 공개된 멀티 엔진 분석 결과는 임포트 테이블의 정적 읽기만으로는 파악할 수 없는 세부 정보를 제공하며, 여기서는 직접 관찰한 내용이 아닌 분석 결과를 인용합니다. 해당 분석에 따르면 AMSI 및 ETW 참조는 단순히 해결된 것이 아니라 패치된 것으로 나타났습니다. AmsiScanBuffer in amsi.dll EtwEventWrite in ntdll.dll 이는 해당 프로세스에 대한 메모리 내 콘텐츠 스캔 및 이벤트 추적을 억제합니다. 또한 안티 분석 검사를 타이밍 기반으로 보고합니다. CheckRemoteDebuggerPresent그리고 식별합니다 GetThreadContext 디버그 레지스터를 읽어 하드웨어 브레이크포인트를 확인하는 호출입니다. 또한 단일 인스턴스 뮤텍스도 보고합니다. Global\{7A3B9E1F-C2D4-4F8A-B5E6-D7A1F0C3E2B9}그리고 이름들 시스템사운드서비스 실행 키 값으로 사용됩니다. 해당 뮤텍스 값은 여기서 복구된 문자열에 포함되지 않았습니다. 추출 필터에서 중괄호로 묶인 대문자 16진수 토큰을 제외했기 때문입니다. 따라서 해당 값은 직접 관찰이 아닌 공개 분석 결과를 바탕으로 지표 테이블에 기록되었습니다.
무대 3
로더는 동일한 호스트의 추가 경로 집합을 참조합니다. 분석 중에 모든 경로에 접근할 수 있었습니다. 비콘_리눅스.bin 5.3MB 용량으로, 비콘_맥.빈 13.3MB 용량으로, update_win.exe 10.3MB이며, 암빈 크기는 4.3MB입니다. 이 파일들은 검색되지 않았으며, 그 동작 방식은 알려지지 않았습니다.
Windows 경로의 경우, 로더에 대한 공개 분석을 통해 세 번째 단계가 어떻게 처리되는지 알 수 있습니다. WinINet을 통해 가져와 암호화된 상태로 도착하고, 메모리에서 복호화되어 리플렉션 방식으로 실행됩니다. 즉, 메모리가 할당되고, 가져오기가 해결되고, 재배치가 처리되고, 제어가 새 스레드로 전달됩니다. 스레드 생성따라서 세 번째 단계는 파일 시스템에 기록되지 않으므로 파일 기반 탐지 및 사후 디스크 포렌식 분석으로는 복구할 수 있는 데이터가 없습니다. 또한, 배포 호스트에서 해당 바이트를 검색하더라도 분석 가능한 실행 파일이 아닌 암호문만 얻게 됩니다.
연혁
모든 타임스탬프는 UTC 기준이며, 패키지 생성 및 게시 취소 기록을 관찰자와 관계없이 독립적으로 저장하는 npm 레지스트리 메타데이터에서 가져온 것입니다.
이 항목들 중 두 가지는 좀 더 자세히 살펴볼 가치가 있습니다.
13시 04분에 발생한 집중적인 업데이트로 4초 만에 레지스트리에 9개의 패키지가 등록되었으며, 각 패키지는 12비트 버전의 단일 버전만 포함하고 있었습니다. 0.0.1 그 아래에. 이 정도 규모의 버전 번호와 하루밖에 안 된 이름은 릴리스 이력을 나타내는 것이 아닙니다.
게시 취소 순서도 마찬가지로 기계적입니다. 19개의 이름, 25초, 일정한 간격. npm은 이를 레지스트리에서 시작된 삭제가 남기는 자리 표시자가 아닌 게시 계정으로 작업을 기록하는 일반적인 게시 취소 이벤트로 기록합니다.
타협의 지표
호스트 및 경로 정보는 더 이상 사용되지 않습니다. 운영 시스템에서 해당 정보를 확인하거나 검색하지 마십시오.
패키지 이름
귀인 및 관찰된 행동
두 개의 npm 계정이 관련되어 있습니다. 미공개된 이름 19개가 한 계정에서 게시되었습니다. a.폴토라드네프-패키지-c 해당 계정은 8월 2일에 다른 계정 이름과 다른 이메일 도메인으로 재등록되었습니다. 두 등록 모두 동일한 코드 계보를 가지고 있으며, 두 번째 등록에는 동일한 전달 호스트, 동일한 DNS 대체 도메인, 동일한 드롭 경로 구성 및 동일한 실행 스탬프가 포함되어 있습니다.
재출간된 두 작품은 조립 과정도 보여줍니다. 버전 0.0.2 33.9.5 버전 문자열을 제외하고는 바이트 단위로 동일합니다. package.json및 index.js 배송됨 0.0.2 선언 const VERSION = “33.9.5”두 유물 모두 하나의 나무에서 잘라낸 후 번호를 매겼습니다. 없습니다. 0.0.2 개발 연혁 0.0.2 대표성을 드러내기 위해 공개합니다.
전체 패키지 세트의 버전 번호 매기기는 동일한 논리를 따릅니다. 이 캠페인의 패키지 이름은 공개 레지스트리가 아닌 조직 내부에 존재하는 것들을 나타냅니다. 예를 들어 UI 구성 요소 세트, ESLint 구성, SLA 프로버, 사람 이름을 딴 패키지 등이 있습니다. 빌드가 이름으로 종속성을 확인하고 공개 레지스트리와 비공개 레지스트리를 모두 참조할 경우, 더 높은 버전 번호가 우선 적용됩니다. 예를 들어 특정 날짜에 생성된 패키지 이름은 조직 내부에서 사용되는 이름입니다. 0.0.1 월요일에 그리고 운반 12.9.6 화요일은 그러한 비교를 위한 위치에 있습니다.
두 차례의 코드 공개 방식에도 차이가 있는데, 이는 반복적인 과정을 시사합니다. 초기 코드는 페이로드 파일의 이름을 지정했습니다. 설정.js 그리고 다섯 개의 배송 호스트를 나열했습니다. 현재 파일의 이름은 다음과 같습니다. _polyfill.js 그리고 세 가지를 나열합니다. 이전 버전은 실행 후 5초 후에 드롭된 파일을 삭제하여 프로세스가 삭제된 inode에서 계속 실행되도록 했지만, 현재 버전은 그렇지 않습니다. 참조되지 않은 lib/telemetry.js 두 부분 모두 타르볼 안에 그대로 남아 있으며, 여전히 배송 중이고 더 이상 연결되어 있지 않습니다.
킬 스위치에 관해 한 가지 주목할 만한 점이 있습니다.cis왜냐하면 그것은 일반적인 해석에 반하기 때문입니다. DISABLE_TELEMETRY, 분석_옵트아웃예산 및 추적 금지 이러한 설정은 존중되며, 다른 작업이 수행되기 전에 확인됩니다. 분석 환경에서 이러한 설정 중 하나라도 지정한 연구원은 아무런 작업도 수행하지 않는 패키지를 보게 됩니다.
영향력과 수비수들이 할 수 있는 일
수입 시점 트리거의 실질적인 영향은 제한적이며, 그 자체로 언급할 가치가 있습니다. npm install –ignore-scripts 라이프사이클 스크립트 실행을 방지하는 것은 좋은 권장 사항입니다. 하지만 이 코드는 라이프사이클 스크립트를 사용하지 않으므로 여기서는 아무런 효과가 없습니다. 페이로드는 애플리케이션 코드, 테스트 실행, 번들러 또는 린터가 모듈을 처음 가져올 때 실행됩니다. 설치 후 즉시 빌드하는 CI 환경에서는 두 시점이 몇 초 간격으로 발생합니다.
사냥에 있어서 내구성이 뛰어난 신호는 문자 그대로의 의미보다는 구조적인 의미에 있습니다. 호스트, 파일 이름, 드롭 경로는 변할 수 있지만, 이러한 구조적 형태는 변경하기가 더 어렵습니다.
- 최종 명령문이 다음과 같은 모듈 진입점 try { require(“./x”); } catch (_) {} 내보낸 API의 일부가 아닌 파일에 관한 것입니다. 제대로 된 폴리필을 포함하는 패키지는 해당 폴리필을 맨 위에서 가져와서 그 결과를 사용합니다. 파일 맨 아래에서 폴리필을 가져와서 발생하는 모든 오류를 무시하는 것은 오류 처리가 아닙니다.
- 호스트 문자열은 다음과 같이 구성됩니다. .가입하다("") 조각들의 배열에서. 정상적인 코드라면 호스트 이름을 배열 요소에 나눠서 저장할 이유가 없습니다.
- 선언된 종속성이 비어 있지만 다음을 호출하는 패키지 HTTPS, DNS예산 및 자식 프로세스 수입 시점에. UI 구성 요소를 광고하는 패키지에서 검색 및 실행이 이루어졌다는 것이 이번 발견의 전부입니다.
- 패키지 출시 시기와 버전 번호가 일치하지 않습니다. 며칠 전 두 자릿수 주요 버전과 함께 처음 공개된 이름은 그 사이에 아무런 릴리스도 없이 개발 과정과는 무관한 다른 무언가를 설명하고 있습니다.
- 에게 편지를 쓴다 / var / tmp or % TEMP % 다음 chmod를 0755까지, 그리고 분리된 스폰 지점. 그 순서는 짧고, 질서정연하며, 함께 나타날 때 양성인 경우는 드뭅니다.
Windows 호스트에는 저렴하면서도 신뢰도가 높은 두 가지 검사 방법이 있습니다. 지속성 흔적은 고정된 문자열이며, 깨끗한 시스템에는 존재하지 않습니다. 첫 번째는 예약된 작업입니다. \Microsoft\Windows\Multimedia\SystemSoundsServiceRun-key 값의 이름은 다음과 같습니다. 시스템사운드서비스그리고 그 이름으로 된 실행 파일이 있습니다. %APPDATA%\Microsoft\Windows\Themes\진짜 Windows 오디오 서비스는 이러한 위치 중 어디에도 존재하지 않습니다. 둘째, 로더는 고정된 단일 인스턴스 뮤텍스를 사용합니다. Global\{7A3B9E1F-C2D4-4F8A-B5E6-D7A1F0C3E2B9}호스트에 뮤텍스가 존재한다는 사실 자체가 지표이며, 로더는 기존 뮤텍스를 "이미 실행 중"으로 처리하기 때문에, 뮤텍스를 미리 생성하는 것은 복구 작업이 예약될 때까지 단기적으로 효과적인 예방책이 될 수 있습니다.
세 번째 단계에서의 탐지는 더 어려운 문제이며, 이 점을 명확히 할 필요가 있습니다. 공개된 분석에 따르면 해당 파일은 디스크에 기록되는 대신 복호화되어 메모리에 매핑되므로 파일 스캔이나 디스크 포렌식으로는 탐지할 수 없습니다. 하지만 로더 자체의 흔적, 즉 지속성 항목, 뮤텍스, 그리고 전달 호스트나 DNS-TXT 도메인으로의 아웃바운드 요청은 관찰 가능합니다.
개인 레지스트리와 공용 레지스트리 모두에서 종속성을 해결하는 환경의 경우, 완화 방법은 여기에 설명된 내용과 동일하게 적용됩니다. 즉, 공용 이름으로는 해결할 수 없도록 내부 레지스트리에 한정하여 내부 레지스트리에서만 종속성을 해결합니다. 위에서 설명한 버전 증가 동작은 더 높은 공용 버전이 이름을 우선적으로 사용할 수 있는 경우에만 효과적입니다.
마지막으로, 이 비공개 공지는 단순히 결론으로 받아들이기보다는 주의 깊게 읽어볼 가치가 있습니다. 25초 만에 19개의 이름이 레지스트리에서 삭제되었고, 하루 뒤 하나의 이름이 새로운 계정으로 다시 등록되었지만, 배송 인프라는 아무런 변화도 없었습니다. 패키지 삭제가 운영 중단을 의미하는 것은 아닙니다. 호스트는 이 글을 작성하는 동안에도 모든 단계를 계속 처리했습니다. 7월 31일과 8월 1일 사이에 이러한 이름 중 하나를 확인한 모든 종속성 트리는 해당 이름이 여전히 존재하는지 여부와 관계없이 1단계 실행 기회를 가졌던 것으로 간주해야 합니다.
참고자료
- 윈도우 로더의 다중 엔진 분석 — 위에서 언급한 AMSI/ETW 패칭, 메모리 내 실행 및 뮤텍스 세부 정보의 출처입니다.
- npm 스크립트 문서 — 이 캠페인에서 사용하지 않는 라이프사이클 이벤트입니다.
- npm install 문서 — 표지 – 스크립트 무시 그리고 그 범위.
