Na pierwszy rzut oka Contagious Interview wygląda jak kolejna kampania phishingowa w nowym opakowaniu. Fałszywy rekruter, zadanie techniczne, złośliwe repozytorium, infekcja. To prawda — ale tylko na poziomie fabuły.
Na głębszym poziomie chodzi o coś znacznie ważniejszego: atakujący nie próbują już wyciągać ofiary z jej normalnego środowiska pracy. Oni wchodzą dokładnie w to środowisko i używają jego reguł przeciwko niej.
Microsoft opisał Contagious Interview jako zaawansowaną operację socjotechniczną aktywną co najmniej od grudnia 2022 roku, nadal obserwowaną w 2026 roku. Kampania celuje głównie w developerów i wykorzystuje zaufanie wpisane w nowoczesny workflow rekrutacyjny: kontakt od rekrutera, rozmowy techniczne, zadanie testowe, repozytorium z kodem i naturalny kontekst „sprawdź, uruchom, oceń”.
I właśnie dlatego ten temat jest tak ciekawy.
Bo tak naprawdę nie chodzi tu o samo malware.
Chodzi o to, że proces pracy stał się powierzchnią ataku.
Jak działa Contagious Interview
W opisywanym przez Microsoft schemacie napastnicy podszywają się pod rekruterów z firm z obszaru kryptowalut lub AI i prowadzą ofiarę przez pozornie normalny proces rekrutacyjny. W pewnym momencie kandydat dostaje zadanie techniczne i instrukcję, by sklonować repozytorium oraz uruchomić pakiet NPM hostowany na popularnych platformach, takich jak GitHub, GitLab czy Bitbucket. W tym momencie wykonywany pakiet uruchamia dalszy payload i instaluje backdoor.
Microsoft opisuje też nowszy wariant kampanii wykorzystujący workflow Visual Studio Code. Ofiara otwiera pobrane repozytorium w VS Code i widzi standardowy prompt z pytaniem o zaufanie do autora. Jeśli to zaufanie zostanie przyznane, VS Code może automatycznie wykonać task configuration z repozytorium, która pobiera i uruchamia backdoora.
To bardzo ważne.
Bo ten atak nie polega na tym, że ktoś wysyła podejrzany plik i liczy, że ofiara kliknie bezmyślnie.
Ten atak polega na tym, że ofiara wykonuje dokładnie to, co wygląda jak część jej pracy.
To nie jest socjotechnika obok pracy. To socjotechnika wewnątrz pracy
To fundamentalna różnica.
Klasyczny phishing zwykle próbował wyciągnąć użytkownika poza jego naturalny kontekst:
- dziwny załącznik,
- podejrzany link,
- fałszywa strona logowania,
- nietypowa prośba z zewnątrz.
Contagious Interview działa inaczej.
Tu cały mechanizm został osadzony wewnątrz profesjonalnego workflow developera.
Atakujący nie proszą ofiary o coś, co wygląda podejrzanie.
Proszą ją o coś, co wygląda jak:
- normalna rekrutacja,
- naturalne zadanie techniczne,
- zwykłe klonowanie repozytorium,
- testowy projekt do uruchomienia,
- zaufanie do autora w narzędziu, które i tak służy do pracy.
To właśnie dlatego kampania jest tak skuteczna.
Nie łamie rytmu pracy ofiary.
Ona podszywa się pod ten rytm.
Dlaczego akurat developerzy są tak dobrym celem
To nie chodzi tylko o to, że developer ma dostęp do cennych systemów.
Chodzi też o to, że jego normalna codzienna praca zawiera rzeczy, które dla innych użytkowników byłyby alarmujące.
Dla developera całkowicie zwyczajne są:
- klonowanie repozytoriów,
- instalowanie paczek,
- uruchamianie kodu,
- testowanie obcych projektów,
- praca w terminalu,
- używanie Visual Studio Code,
- szybkie podejmowanie decyzji o zaufaniu do środowiska czy autora.
I właśnie to sprawia, że Contagious Interview jest tak dobrze dopasowane do ofiary.
To, co dla zwykłego użytkownika wyglądałoby jak sygnał ostrzegawczy, dla developera jest częścią dnia pracy.
Microsoft pisze wprost, że kampania wykorzystuje zaufanie wpisane w nowoczesne procesy rekrutacyjne i obniża czujność ofiar właśnie dlatego, że działa w okresach dużej motywacji i presji czasu, typowych dla rozmów o pracę.
Prawdziwy wektor ataku: zaufanie do workflow
Najciekawsze w Contagious Interview nie jest samo złośliwe repozytorium.
Najciekawsze jest to, że wektorem ataku staje się workflow, a nie plik.
To bardzo ważne przesunięcie.
W tej kampanii cały łańcuch opiera się na zaufaniu:
- ufam rekruterowi,
- ufam kontekstowi zadania,
- ufam repozytorium,
- ufam pakietowi,
- ufam środowisku developerskiemu,
- ufam temu, że prompt w VS Code jest częścią normalnego procesu.
I właśnie dlatego atak działa tak dobrze.
Napastnik nie musi przełamywać zaufania siłą.
Wystarczy, że zbuduje wiarygodny kontekst, w którym wykonanie szkodliwego kroku wygląda jak zwykły element pracy.
To wzór, który widać dziś coraz częściej także w innych kampaniach:
- Teams jako „wsparcie techniczne”,
- fake CAPTCHA jako „normalna weryfikacja”,
- legalne RMM-y jako „narzędzia administracyjne”,
- repozytorium jako „zadanie rekrutacyjne”.
W każdym z tych przypadków atak nie wygląda jak atak.
Wygląda jak zwykły proces.
Co dokładnie uruchamia się po infekcji
Na poziomie technicznym Microsoft opisał kilka rodzin backdoorów wykorzystywanych w tej kampanii.
Najbardziej widoczny jest OtterCookie, rozwijany od co najmniej września 2024 roku JavaScriptowy backdoor, który z czasem ewoluował z prostego narzędzia do wykonywania komend i wyszukiwania kluczy kryptograficznych w modularny program zdolny do:
- sprawdzania środowisk VM,
- komunikacji C2,
- eksfiltracji danych,
- wykonywania arbitralnych poleceń powłoki,
- doładowywania kolejnych modułów zbierających wybrane informacje.
Microsoft opisuje też drugi wariant — lekki agent beaconingowy, który potrafi zbierać fingerprint hosta, regularnie kontaktować się z kontrolerem i wykonywać dostarczony przez atakującego kod przez lokalny runtime, a także uruchamiać procesy w tle i zarządzać nimi zdalnie.
Po uzyskaniu przyczółka napastnicy przechodzą do zbierania danych. Microsoft wskazuje, że na Windows atakujący enumerowali m.in. materiały uwierzytelniające, pliki konfiguracyjne, frazy seed walletów, bazy KeePass, artefakty 1Password i klucze kryptograficzne, a na macOS wydawali polecenia przeszukujące system plików pod kątem sekretów. Warianty OtterCookie zbierały również dokumenty, obrazy, source code i artefakty pakietów, eksfiltrując je przez zwykły ruch HTTP.
To wszystko pokazuje, że nie mówimy o pojedynczym „testowym dropperze”, tylko o pełnoprawnym wejściu do środowiska pracy ofiary.
VS Code nie jest problemem. Problemem jest automatyczne zaufanie
W tego typu kampaniach łatwo byłoby wyciągnąć błędny wniosek, że problemem jest samo narzędzie — GitHub, NPM czy Visual Studio Code.
To nie byłby dobry wniosek.
Problemem nie jest to, że developer używa VS Code.
Problemem jest to, że łańcuch zaufania w środowisku pracy może uruchamiać działania wykonawcze szybciej, niż człowiek zdąży zakwestionować kontekst.
W przypadku Contagious Interview VS Code jest ważne nie dlatego, że jest „niebezpieczne”, ale dlatego, że jest naturalnym miejscem, w którym:
- otwiera się obce repo,
- ufa autorowi,
- uruchamia taski,
- i wykonuje kod.
To pokazuje coś większego:
narzędzia pracy nie są już tylko neutralnym tłem. Coraz częściej stają się częścią łańcucha wykonania.
A to wymusza zupełnie inny sposób myślenia o bezpieczeństwie.
Czy to tylko kampania „dla crypto i AI”
Nie.
To tylko dobrze dobrane opakowanie.
Microsoft opisuje podszywanie się pod firmy z obszaru kryptowalut i AI, bo takie firmy:
- dobrze pasują do rynku rekrutacyjnego developerów,
- uzasadniają nietypowe zadania techniczne,
- i pozwalają osadzić malware w repozytoriach i paczkach bez natychmiastowego wzbudzania podejrzeń.
Ale prawdziwy mechanizm nie zależy od tej branży.
Sedno polega na tym, że każda branża może dziś stać się kostiumem dla workflow attacku, jeśli tylko:
- pasuje do ofiary,
- używa właściwego języka,
- i daje wiarygodny pretekst do wykonania kodu albo uruchomienia procesu.
Co ten incydent mówi szerzej o dzisiejszych atakach
Contagious Interview dobrze wpisuje się w większy wzór, który widać coraz wyraźniej.
Dzisiejszy atak coraz rzadziej wygląda jak atak.
Coraz częściej wygląda jak:
- rozmowa,
- wsparcie,
- zadanie,
- test,
- narzędzie,
- workflow,
- zwykła praca.
To zmienia wszystko.
Bo jeśli atak przestaje przypominać coś z zewnątrz, a zaczyna przypominać naturalny proces, to klasyczny model „uważaj na podejrzane rzeczy” przestaje wystarczać.
Teraz trzeba uczyć ludzi czegoś trudniejszego:
że najbardziej niebezpieczne rzeczy mogą wyglądać dokładnie jak normalna część ich pracy.
I to dotyczy już nie tylko użytkowników biurowych, ale także:
- administratorów,
- zespołów IT,
- developerów,
- rekruterów technicznych,
- i wszystkich środowisk, gdzie zaufanie do procesu jest wysokie.
Co z tego wynika dla firm i zespołów
Największy błąd byłby taki, żeby potraktować Contagious Interview jako „ciekawostkę o malware dla programistów”.
To nie jest ciekawostka.
To sygnał, że bezpieczeństwo musi wejść głębiej w procesy pracy.
W praktyce oznacza to co najmniej kilka rzeczy:
- rekrutacja techniczna też staje się powierzchnią ataku,
- repozytoria i zadania testowe wymagają ostrożności operacyjnej,
- środowiska developerskie nie mogą być traktowane jako strefa domyślnego zaufania,
- a świadomość zagrożeń musi obejmować nie tylko phishing mailowy, ale też phishing workflow.
Innymi słowy:
nie wystarczy już szkolić ludzi z tego, żeby nie klikali w dziwne linki.
Trzeba ich uczyć również tego, że:
wiarygodnie wyglądający proces zawodowy też może być wektorem wejścia.
Podsumowanie
Na poziomie technicznym Contagious Interview to kampania, w której napastnicy podszywają się pod rekruterów, wysyłają zadania techniczne i dostarczają malware przez repozytoria, pakiety NPM oraz workflow Visual Studio Code.
Na poziomie strategicznym chodzi jednak o coś większego.
To kolejny dowód na to, że współczesny atak coraz rzadziej polega na przełamaniu zabezpieczeń siłą. Coraz częściej polega na wejściu w normalny proces pracy i wykorzystaniu go dokładnie tak, jak korzysta z niego ofiara.
A jeśli workflow staje się powierzchnią ataku, to bezpieczeństwo nie może już kończyć się na pliku, załączniku i linku.
Musi objąć także:
- proces,
- kontekst,
- narzędzia pracy,
- i zaufanie wpisane w codzienny rytm działania zespołu.
Bo właśnie tam dziś coraz częściej zaczyna się incydent.
Źródła
- Microsoft Security Blog — analiza kampanii Contagious Interview, mechanizm działania, wykorzystanie fałszywych rekruterów, repozytoriów, pakietów NPM oraz workflow Visual Studio Code.
- Microsoft Threat Intelligence — opis rodzin malware i backdoorów powiązanych z kampanią, w tym OtterCookie, oraz technik utrzymania dostępu i eksfiltracji danych.
