Korea Północna i „Contagious Interview”: jak złośliwe projekty VS Code uruchamiają malware przez tasks.json - Security Bez Tabu

Korea Północna i „Contagious Interview”: jak złośliwe projekty VS Code uruchamiają malware przez tasks.json

Wprowadzenie do problemu / definicja luki

Kampania powiązana z aktorami DPRK (Korea Północna), znana jako Contagious Interview, ewoluuje w stronę ataków „zero-click-ish” z perspektywy programisty: ofiara nie musi świadomie uruchamiać malware, wystarczy że sklonuje repo i otworzy je w Visual Studio Code. Najnowszy wariant wykorzystuje mechanizm VS Code Tasks (.vscode/tasks.json) do automatycznego wykonania poleceń po otwarciu folderu projektu, prowadząc do instalacji backdoora z funkcjami zdalnego wykonania kodu.

Kluczowe w tym łańcuchu jest zachowanie użytkownika: VS Code pyta o zaufanie do repozytorium (Workspace Trust), a udzielenie zaufania może uruchomić przetwarzanie zadań i wykonanie osadzonych komend.

W skrócie

  • APT powiązany z DPRK podszywa się pod rekruterów/CTO i dostarcza „zadania rekrutacyjne” jako repozytoria Git.
  • Repo zawiera .vscode/tasks.json z runOptions.runOn: "folderOpen", co pozwala na uruchomienie zadania przy otwarciu projektu (po zgodzie na automatyczne taski).
  • W obserwacjach Jamf na macOS dochodziło do uruchomienia w tle polecenia pobierającego zdalny JavaScript (hostowany m.in. na Vercel) i „wpinającego” go bezpośrednio do Node.js (pipe), co realizuje backdoora i pętlę beaconingu.
  • Kampania wykorzystuje i rozwija rodziny malware powiązane z Contagious Interview: BeaverTail (warstwa Node/infostealer/downloader) i InvisibleFerret (backdoor, często Python).

Kontekst / historia / powiązania

Contagious Interview jest śledzona od co najmniej 2023 r. jako kampania nastawiona na programistów i osoby szukające pracy w branży tech. Unit 42 opisywał scenariusze, w których fałszywi rekruterzy nakłaniali ofiary do instalacji/uruchomienia „aplikacji” (np. podszywających się pod narzędzia do rozmów), co prowadziło do infekcji BeaverTail oraz finalnie InvisibleFerret.

W styczniu 2026 r. obserwujemy przesunięcie ciężaru z „uruchom plik” na „otwórz repo w IDE”: socjotechnika pozostaje podobna (LinkedIn, zadanie techniczne, code review), ale technika wykonania payloadu coraz mocniej wpasowuje się w domyślne workflow deweloperskie.

Analiza techniczna / szczegóły luki

1) Mechanizm: VS Code Tasks + runOn: folderOpen

VS Code pozwala definiować zadania w .vscode/tasks.json. Dokumentacja opisuje runOptions.runOn, gdzie folderOpen oznacza uruchomienie taska przy otwarciu folderu. Co ważne: przy pierwszym otwarciu folderu z takim taskiem użytkownik dostaje pytanie, czy zezwolić na automatyczne uruchamianie zadań w tym folderze.

W praktyce atakujący:

  • ukrywa złośliwy task wśród „normalnych” zadań (np. udających lint/build),
  • ustawia runOn: "folderOpen",
  • dobiera komendę tak, aby wyglądała niegroźnie (np. uruchomienie pliku udającego font), ale w rzeczywistości wykonywała kod (np. node ...).

2) Punkt krytyczny: Workspace Trust

Jamf wskazuje, że przy otwarciu projektu VS Code pyta o zaufanie do autora repozytorium, a po jego udzieleniu aplikacja może automatycznie przetwarzać tasks.json, co „otwiera drzwi” do wykonania arbitralnych poleceń osadzonych w taskach.

3) Łańcuch infekcji obserwowany przez Jamf (macOS)

W badanym wariancie na macOS uruchamiane było polecenie w tle (m.in. z nohup bash -c), które pobierało zdalny JavaScript i przekazywało go bezpośrednio do runtime Node.js. Payload (hostowany na infrastrukturze typu vercel.app) implementował logikę backdoora: rozpoznanie hosta, utrzymywanie pętli wykonywania, komunikacja z serwerem i możliwość zdalnego wykonania kodu.

4) „Dual-stack” i dodatkowe wektory (wg Security Alliance)

Security Alliance opisuje architekturę „dual-stack”:

  • warstwa Node.js: szybka kradzież danych (m.in. klucze, screeny, pliki, przeglądarki) i uruchomienie kanału zdalnego sterowania,
  • warstwa Python: komponenty długotrwałe, w tym kradzież portfeli i elementy monetizacji (np. mining).

W raporcie pojawiają się też warianty awaryjne: jeśli wektor VS Code nie zadziała, malware może „zahaczać” o logikę aplikacji (uruchomi się dopiero przy starcie projektu) lub próbować dociągnąć złośliwą zależność npm.

Praktyczne konsekwencje / ryzyko

Dlaczego to groźne dla organizacji, nie tylko dla kandydatów?

  • Programista często pracuje na urządzeniu z dostępem do repozytoriów firmowych, sekretów CI/CD, tokenów chmurowych, kluczy SSH i portfeli kryptowalutowych (szczególnie w fintech/crypto).
  • Atak może zadziałać nawet wtedy, gdy ofiara „tylko zerknie na kod” lub pozwoli narzędziu AI przeanalizować repo (bo w tle uruchamia się task/Trusted Workspace).
  • Skutki obejmują: przejęcia kont, exfiltrację IP/source code, kradzież środków, a także lateral movement do środowisk firmowych.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów developerskich (natychmiast)

  1. Nie ufaj repo „z rekrutacji” domyślnie: jeśli VS Code pyta o Workspace Trust — traktuj to jak prompt bezpieczeństwa (tak jak ostrzeżenie o makrach).
  2. Przeglądaj .vscode/tasks.json zanim otworzysz projekt
    • Szukaj runOptions + runOn: "folderOpen" oraz zadań o mylących nazwach (lint, eslint-check, build).
  3. Otwieraj nieznane repo w izolacji: VM / kontener / osobny profil użytkownika bez dostępów do firmowych sekretów (kluczy SSH, tokenów chmurowych). (To wynika bezpośrednio z wektorów i celów kampanii opisanych w źródłach.)
  4. Polityka zależności: instaluj pakiety npm tylko z weryfikowanych źródeł i unikaj „npm install” na niezweryfikowanych repozytoriach.

Dla SOC / Blue Team (detekcja i hunting)

  • Telemetria procesów: wzorce typu bash -c ... curl ... | node, nietypowe uruchomienia Node przy otwieraniu folderu w VS Code, oraz procesy potomne VS Code uruchamiające shell.
  • Polowanie po artefaktach: nietypowe pliki w .vscode/, zadania z runOn: folderOpen, podejrzane „zasoby” udające fonty uruchamiane przez node.
  • Egress/IOC: podwyższona czujność na krótkotrwałe domeny/hosting używany do stagingu payloadów (w obserwacjach pojawia się Vercel).

Różnice / porównania z innymi przypadkami

  • Wcześniej (2023–2024): częsty schemat to nakłonienie ofiary do instalacji/uruchomienia „aplikacji” lub kodu w ramach rozmowy rekrutacyjnej; BeaverTail i InvisibleFerret były rozwijane i przenoszone między platformami (macOS/Windows).
  • Teraz (2025–2026): nacisk przesuwa się na łańcuch dostawy przez repozytoria i IDE — otwarcie folderu w VS Code może uruchomić złośliwy task (folderOpen), a dodatkowe wektory (hook w runtime aplikacji, zależności npm) zwiększają „odporność” ataku na niepowodzenie jednego sposobu.

Podsumowanie / kluczowe wnioski

  • Mechanizmy automatyzacji w IDE (Tasks) są funkcją produktywności, ale w rękach APT stają się wektorem initial access — szczególnie gdy łączą się z socjotechniką „zadania rekrutacyjnego”.
  • Największe ryzyko wynika z „małego” kliknięcia: Workspace Trust i zgoda na automatyczne taski.
  • Organizacje powinny traktować nieznane repozytoria jak nieznane załączniki: izolacja, przegląd przed uruchomieniem, polityki zależności i telemetryka procesów.

Źródła / bibliografia

  1. The Hacker News – opis kampanii i najnowszego wariantu z VS Code Tasks (20 stycznia 2026). (The Hacker News)
  2. Jamf Threat Labs – analiza nadużyć VS Code i łańcucha infekcji (20 stycznia 2026). (jamf.com)
  3. Microsoft (VS Code Docs) – dokumentacja tasks.json, runOptions i runOn: folderOpen. (code.visualstudio.com)
  4. Security Alliance (Radar) – raport techniczny: „VS Code Tasks Abuse by Contagious Interview (DPRK)” (13 stycznia 2026). (Radar | Security Alliance)
  5. Unit 42 (Palo Alto Networks) – tło kampanii Contagious Interview oraz BeaverTail/InvisibleFerret (9 października 2024). (Unit 42)