Otmiceni npm i Go paketi pretvaraju VS Code taskove pri otvaranju projekta u cross-platform infostealer rizik

Nova kampanja sa otetim npm i Go paketima zasluzuje paznju zato sto supply-chain problem pomera dalje od klasicne price o lifecycle skriptama. Ovde napadac skriva izvrsavanje u Visual Studio Code tasku koji moze da se pokrene kada se otvori trusted workspace, zatim preko blockchain dead-drop mehanizma dovlaci sledece payload-e i na kraju isporucuje Python malware namenjen kradji kredencijala i trajnom udaljenom pristupu.

Za enterprise IT pravi rizik nije samo jedan los paket. Rizik je da developerska radna stanica, cloud shell ili laptop spoljnog saradnika odjednom izlozi browser session-e, Git kredencijale, GitHub CLI stanje, OS credential store, wallet podatke i cloud metadata tragove cim obicno coding ponasanje predje trust boundary. Zato je ovo istovremeno problem integriteta paketa i hardening-a developerskog okruzenja.

Zasto je ova kampanja operativno bitna

Prema objavljenim analizama, lanac napada je koristio dva oteta npm paketa i vise Go paketa cija su novija izdanja nosila napadacku logiku zajedno sa legitimnim sadrzajem. Trigger je bila skrivena VS Code task definicija koja je izgledala kao normalno projektno ponasanje. Kasnije faze preuzimale su sifrovani JavaScript preko blockchain povezane infrastrukture, otvarale Socket.io backdoor i potom isporucivale Python infostealer.

• Execution path zaobilazi ocigledni npm lifecycle-script obrazac koji mnogi defenderi vec prate.
• Workspace-open trigger zloupotrebljava normalno tooling ponasanje umesto da trazi ocigledno sumnjiv start binarnog fajla.
• Malware cilja Windows, Linux i macOS, pa je blast radius siri kroz mesovite engineering flote.
• Payload je namenjen i kradji i interaktivnom pristupu, pa response mora da pokrije i secrets exposure i endpoint kompromitaciju.

Sta security i platform timovi prvo treba da zakljucaju

1) Preispitaj poverenje u VS Code workspace-ove i automatske taskove

Mnogi timovi vec upozoravaju developere na sumnjive install skripte, ali mnogo manje njih ima politiku za folder-open ponasanje i trusted workspace logiku. Ako uvezeni projekat moze da aktivira automatske taskove, onda je model provere repoa nepotpun. Workspace trust promptovi, ugnjezdene putanje i task autorun podesavanja moraju da udju u sigurnu developer baseline konfiguraciju.

2) Podrazumevaj da je sacuvano developersko stanje deo mete

Opisani Python stealer je bitan zato sto navodno traga daleko sire od source koda. Browser kredencijali, Git materijal, cloud-drive metadata, password store i lokalno IDE stanje jednako su vredni napadacu. Zato post-exposure response mora da ukljuci rotaciju kredencijala, invalidaciju session-a i host triage, a ne samo uklanjanje paketa.

3) Ogranicite egress i bootstrap ponasanje na developerskim hostovima

Koriscenje dead-drop mehanizma, naknadnog JavaScript payload-a i komandnog kanala pokazuje da neogranicen outbound pristup povecava otpornost napadaca. Developer sandbox-i i radne stanice bliske CI toku ne bi trebalo da imaju isti egress kao obican desktop. Cak i umerene kontrole oko arbitrarnih preuzimanja, script execution-a i rizicnih destinacija mogu znacajno da smanje uspesnost ove vrste lanca napada.

Hitna response checklista

Zakljucak

Ova prica podseca da moderna odbrana od supply-chain napada ne sme da stane na package signature proveri i ociglednim install hook-ovima. Ako trusted IDE ponasanje, sacuvano developersko stanje i sirok outbound pristup ostanu nekontrolisani, napadaci mogu da pretvore obicnu workflow pogodnost u kradju kredencijala i daljinsku kontrolu. Timovi koji developer workspace tretiraju kao privilegovanu execution zonu mnogo ce bolje podneti sledecu varijantu ove tehnike.