14 złośliwych pakietów npm podszywa się pod OpenSearch i Elastic

Badacze bezpieczeństwa z Microsoft zidentyfikowali złośliwą kampanię w ekosystemie pakietów npm.

28 maja 2026 roku pojedynczy użytkownik vpmdhaj (a39155771@gmail[.]com) opublikował 14 złośliwych pakietów w ciągu 4 godzin. Pakiety te podszywają się pod biblioteki OpenSearch i ElasticSearch, oraz narzędzia do konfiguracji środowiska.

TLDR:

• Microsoft wykrył kampanię w npm, w której jeden użytkownik opublikował 14 złośliwych pakietów.
• Paczki podszywają się pod OpenSearch/Elastic i narzędzia konfiguracyjne, wykorzystując typosquatting, fałszywe metadane i spreparowane wersje.
• Payload jest uruchamiany automatycznie przez hooki npm (preinstall/install/postinstall).
• Malware kradnie sekrety z środowisk CI/CD i chmurowych, w tym AWS, HashiCorp Vault, GitHub Actions oraz tokeny npm.
• W nowszym wariancie zamiast klasycznego C2 wykorzystuje lokalne uruchamianie payloadu przez pobrany Bun runtime, co utrudnia wykrycie przez analizę ruchu sieciowego.

Wszystkie paczki w ramach kampanii dostarczają ten sam payload drugiego etapu skompilowany przy użyciu Bun – całość ma na celu wykradanie poświadczeń do środowisk chmurowych i CI/CD. Pierwszy etap – zależnie od wersji – uruchamiany jest przez hook install/preinstall/postinstall.

Atakujący wykorzystał kilka metod na zwiększenie wiarygodności fałszywych pakietów. Po pierwsze, nazwy łudząco podobne do oryginałów – takie jak opensearch-setup, opensearch-setup-tool, opensearch-config-utility, elastic-opensearch-helper, search-engine-setup oraz env-config-manager – naśladują one znane programistom biblioteki. Po drugie, sfałszowane metadane – pakiety posiadały zdefiniowane pola homepage, repository oraz bugs wskazujące na prawdziwe strony i repozytoria. Po trzecie, spreparowane numery wersji – np.  1.0.7265, 1.0.9108 lub 2.1.9201 – zapewne mające na celu sugerowanie realnej historii wydań.

Paczki w tej kampanii deklarują w package.json hooki instalacyjne. Złośliwy kod wykonuje się w momencie, gdy ofiara uruchomi npm install – nie jest wymagana żadna dodatkowa interakcja, zatwierdzenie itp. Badacze zaobserwowali dwie zastosowane metody:

1. (wersje 1.0.7265 i poprzednie): hooki install, preinstall oraz postinstall wywołują preinstall.js / index.js

2. (wersje 1.0.7266 i następne): pojedynczy hook preinstall wywołuje setup.mjs 

W pierwszym wariancie zbierany jest zestaw informacji o urządzeniu ofiary – m.in. nazwa hosta, system operacyjny, wersja Node.js, nazwa użytkownika – całość w formie JSON zakodowanego w base64 i wysyłana żądaniem POST do serwera C2. Ten sam C2 dostarcza skompresowany (gzip) plik binarny drugiego etapu – jest on zapisywany jako payload.bin w katalogu instalacyjnym pakietu.

Plik index.js pakietu uruchamia payload.bin przy każdym kolejnym wywołaniu require() dla tego modułu – jest to sposób na utrzymanie działania malware.

W nowszych wersjach atakujący zastąpił dotychczasową komunikację HTTP z serwerem C2 na trudniej wykrywalny mechanizm. Plik setup.mjs najpierw sprawdza, czy Bun jest już obecny na urządzeniu. Jeśli go nie ma, pobierany jest oficjalny runtime Bun z oficjalnego repozytorium projektu na GitHub. Po rozpakowaniu runtime uruchamiany jest payload drugiego etapu (opensearch_init.js lub ai_init.js) pobrany z npm (razem z pozostałymi plikami paczki).

Utrudnia to wykrycie infekcji przez kontrolę ruchu sieciowego urządzenia – na tym etapie nie będzie tam widoczna domena C2.

Wspomniany payload drugiego etapu służy do kradzieży poświadczeń chmurowych i CI/CD. Badacze zidentyfikowali kilka platform, dla których gromadzono dane:

• AWS – malware wykonuje zapytania do EC2 Instance Metadata Service v2 oraz ECS task metadata, odczytuje poświadczenia AWS ze zmiennych środowiskowych, wywołuje operacje  GetCallerIdentity / AssumeRole oraz enumeruje Secrets Manager (ListSecrets / GetSecretValue) w ponad 16 regionach.
• HashiCorp Vault – odczytuje zmienne środowiskowe VAULT_TOKEN oraz VAULT_AUTH_TOKEN.
• npm – weryfikuje znalezione na urządzeniu tokeny przez endpoint /-/whoami oraz sprawdza uprawnienia do publikacji paczek przez /-/npm/v1/tokens.
• GitHub Actions: zbiera kontekst GITHUB_REPOSITORY oraz RUNNER_OS w celu identyfikacji środowiska build.

Użytkownikom, którzy zainstalowali złośliwe paczki (pełna lista pod tekstem) w dniu 28 maja 2026 lub później polecamy wyłączenie hooków npm, uruchamiając npm install z opcją –ignore-scripts albo ustawiając ją globalnie. Warto także zrotować poświadczenia AWS, HashiCorp Vault, npm oraz GitHub Actions, które mogły zostać wykradzione.

Oczywiście należy usunąć zainfekowane paczki, warto także wyczyścić cache menadżera pakietów. Nie jest to pierwszy i na pewno nie ostatni atak na łańcuch dostaw. Warto w miarę dostępnych opcji ograniczać generowane tokeny / klucze zarówno pod kątem ich uprawnień, jak również adresów/zakresów IP, które mogą z nich korzystać. Do publikowania paczek w npm można rozważyć mechanizm trusted publishing, a wrażliwe poświadczenia (np. klucze SSH) obsługiwać za pomocą np. klucza FIDO. 

IoC

Paczki:

• @vpmdhaj/elastic-helper (1.0.7269)
• @vpmdhaj/devops-tools (1.0.7267)
• @vpmdhaj/opensearch-setup (1.0.7267)
• @vpmdhaj/search-setup (1.0.7268)
• opensearch-security-scanner (1.0.10)
• opensearch-setup (1.0.9103)
• opensearch-setup-tool (1.0.9108)
• opensearch-config-utility (1.0.9106)
• search-engine-setup (1.0.9108)
• search-cluster-setup (1.0.9104)
• elastic-opensearch-helper (1.0.9108)
• vpmdhaj-opensearch-setup (1.0.9102)
• env-config-manager (2.1.9201)
• app-config-utility (1.0.9300)

Nazwa wydawcy: vpmdhaj

Adres e-mail: a39155771@gmail[.]com

Domena C2: aab[.]sportsontheweb[.]net

Nagłówek z zapytań do C2: X-Supply: 1

Źródło: microsoft.com

~Tymoteusz Jóźwiak