Phishing na developerów. Korea Północna, AI i złośliwe zadania rekrutacyjne

2026-04-24

TL;DR

Przypadek opisany przez firmę Expel pokazuje bardzo wyraźnie, jak zmienia się dziś phishing. Atakujący powiązani z Koreą Północną nie musieli opierać się na prostych mailach z linkiem do fałszywego logowania. Wystarczyło, że połączyli fałszywą rekrutację, złośliwe zadania techniczne i komercyjne narzędzia AI.

Najciekawsze jest to, że cały atak dobrze stapiał się z codziennym środowiskiem pracy developera. Node.js, Python, VS Code i zadanie rekrutacyjne nie wyglądają podejrzanie. I właśnie dlatego ten model jest tak niebezpieczny.

O co chodzi w tej kampanii

Expel opisał aktywność grupy nazwanej HexagonalRodent, którą z wysokim poziomem pewności wiąże z Koreą Północną. W źródłach czasem pojawia się też skrót DPRK, czyli Democratic People’s Republic of Korea — oficjalna angielska nazwa Korei Północnej.

Według badaczy grupa ta działa jak część szerszego ekosystemu północnokoreańskich operacji wymierzonych w sektor kryptowalut i projekty Web3. Warto to wyjaśnić wprost: Web3 to potoczne określenie projektów opartych na blockchainie, smart kontraktach, portfelach kryptowalutowych i zdecentralizowanych aplikacjach. To środowisko przyciąga atakujących, bo obraca cennymi aktywami cyfrowymi, a jednocześnie mocno polega na zdalnej pracy i zaufaniu do kodu.

Schemat kampanii był prosty, ale dobrze dopracowany. Napastnicy podszywali się pod firmy technologiczne, publikowali oferty pracy, kontaktowali się przez LinkedIn i budowali wiarygodne strony firmowe. Kandydat dostawał zadanie rekrutacyjne, które wyglądało jak normalny test umiejętności. Problem polegał na tym, że projekt był przygotowany tak, by uruchomić złośliwy kod.

To nie był więc klasyczny phishing z tanią stroną logowania. To był phishing schowany w procesie rekrutacji.

Fałszywa rekrutacja jako wektor wejścia

W wielu firmach słowo phishing nadal kojarzy się głównie z mailem, linkiem i podejrzanym formularzem. W kampanii HexagonalRodent punkt wejścia wyglądał inaczej. Najpierw oferta pracy. Potem rozmowa. Potem zadanie techniczne.

To ważne, bo cały proces mieści się w czymś, co dla developera jest zupełnie zwyczajne. Test rekrutacyjny, repozytorium, projekt do uruchomienia, poprawka do wdrożenia, review kodu. Nic z tego nie brzmi dziwnie. I właśnie dlatego ofiara ma dużo mniejszą gotowość do ostrożnej analizy niż przy typowym spamie.

To dobrze pokazuje szerszy problem, o którym pisaliśmy już we wpisie Industrializacja phishingu. Jak model PhaaS zamienia pojedynczy atak w pipeline oszustwa. Współczesny phishing coraz rzadziej jest jedną wiadomością. Coraz częściej jest całym procesem, który ma wyglądać jak coś codziennego i zawodowo uzasadnionego.

Jak wyglądał atak krok po kroku

Ten model ataku można rozpisać bardzo prosto.

Najpierw kandydat trafiał na fałszywą ofertę pracy albo był zaczepiany przez rzekomego rekrutera. Potem dostawał zadanie techniczne lub link do repozytorium. Następnie otwierał projekt na własnym komputerze i uruchamiał go tak, jak robi to przy zwykłej pracy. W tle aktywował się złośliwy mechanizm, którego celem było przejęcie danych, portfeli kryptowalutowych albo haseł.

To właśnie jest najmocniejszy element tej kampanii. Atak nie wymagał od ofiary niczego egzotycznego. Wystarczyło, że zrobiła to, co w jej pracy jest normalne.

Gdzie ukryto złośliwy element

Expel opisuje dwa bardzo praktyczne warianty.

Pierwszy wykorzystywał plik tasks.json w VS Code. VS Code, czyli Visual Studio Code, to jeden z najpopularniejszych edytorów kodu na świecie. W tym przypadku atakujący użyli ustawienia runOn: folderOpen, co oznacza, że samo otwarcie projektu mogło uruchomić złośliwe działanie.

Drugi wariant ukrywał backdoor bezpośrednio w kodzie projektu, tak aby uruchamiał się przy zwykłym starcie aplikacji.

Atak nie polegał na tym, że ktoś otwierał plik typu invoice.exe. Polegał na tym, że developer uruchamiał projekt, czyli robił coś logicznego. Otwierał repozytorium, odpalał kod, sprawdzał zadanie.

Jeśli chcesz zobaczyć podobny mechanizm, choć w innym środowisku, zobacz też nasz materiał SideWinder i fałszywy podgląd PDF. Kiedy zwykły dokument prowadzi do kradzieży webmaila. W obu przypadkach pierwszy krok wygląda niegroźnie, bo przypomina normalną pracę.

AI wspomaga ataki

Najmocniejszy wniosek z badania Expel dotyczy użycia narzędzi AI. Badacze potwierdzili aktywne wykorzystanie Cursor i ChatGPT, a także platform do budowy stron frontowych, takich jak Anima.

Tu też warto dopowiedzieć, czym są te nazwy. Cursor to edytor kodu i narzędzie do pracy z programowaniem wspierane przez AI. ChatGPT nie trzeba szeroko przedstawiać, ale w tym kontekście chodziło o pomoc przy pisaniu i poprawianiu kodu, a nie o samodzielne prowadzenie ataku. Anima to z kolei narzędzie do szybkiego tworzenia interfejsów i stron frontowych.

Z ustaleń Expel wynika, że grupa używała AI do budowy elementów malware, tworzenia fałszywych stron firmowych, dopracowywania przynęt i sprawdzania, czy przygotowane zadania nie wyglądają zbyt podejrzanie.

To dobrze pokazuje, jak AI działa w praktyce ofensywnej. Nie musi tworzyć genialnego exploita. Wystarczy, że przyspiesza dziesiątki mniejszych prac: stronę firmy, tekst ogłoszenia, komentarze w kodzie, loader, testy i poprawki.

To bardzo podobny trend do tego, który opisaliśmy we wpisie ATHR pokazuje, że vishing wchodzi w etap automatyzacji. AI nie przejmuje całego ataku. Ona po prostu sprawia, że mniej doświadczony operator może zrobić więcej, szybciej i taniej.

Dlaczego ten atak był trudniejszy do zauważenia

To najważniejszy praktyczny element tej historii. Według Expel i Help Net Security grupa nie skupiała się na klasycznym, głośnym ruchu bocznym wewnątrz dużych sieci korporacyjnych. Jej celem było raczej przejmowanie portfeli, haseł i danych z pojedynczych komputerów.

Dzięki temu ślad był mniejszy, a zachowanie mniej hałaśliwe. Do tego malware działał w Node.js i Pythonie, czyli w technologiach całkowicie normalnych na stacji roboczej developera. Jeżeli na komputerze programisty widać procesy Node albo Python, to samo w sobie nie wygląda podejrzanie. To codzienność.

Do tego dochodziła obfuskacja kodu przy użyciu obfuscator.io. Obfuskacja to po prostu celowe zaciemnianie kodu tak, żeby trudniej było zrozumieć, co naprawdę robi. Atak nie był więc magicznie niewidzialny. Po prostu dobrze mieszał się z tym, co na komputerze developera wygląda zwyczajnie.

Skala pokazuje, że to nie był jednorazowy eksperyment

Expel podaje, że w pierwszych trzech miesiącach 2026 roku z kampanii atakujący przejęli publiczne klucze portfeli o łącznej wartości do 12 mln dolarów. Badacze wskazują też na tysiące zainfekowanych systemów developerskich.

To nie wygląda jak jedna operacja przeciw jednej ofierze. To wygląda jak model działający seryjnie.

Warto też zwrócić uwagę na jeszcze jeden element. Według badaczy grupa prawdopodobnie wykonała ruch przypominający supply chain attack, czyli atak przez zaufany element łańcucha dostaw oprogramowania. W tym przypadku chodziło o kompromitację rozszerzenia VS Code fast-draft. To ważny sygnał, bo pokazuje, że podobne grupy mogą z czasem przechodzić od socjotechniki do jeszcze szerszych metod dystrybucji.

Na co powinien uważać developer przy zadaniu rekrutacyjnym

To jest sekcja, której często brakuje w takich materiałach, a właśnie ona bywa najcenniejsza.

Po pierwsze, nie warto uruchamiać obcego zadania rekrutacyjnego na głównej stacji roboczej, na której znajdują się prywatne klucze, zapisane sesje, tokeny dostępu albo firmowe konta.

Po drugie, trzeba sprawdzać nie tylko sam kod aplikacji, ale też pliki konfiguracyjne IDE, skrypty uruchomieniowe, zależności instalowane przy starcie oraz to, co dzieje się po otwarciu folderu.

Po trzecie, repozytorium z procesu rekrutacyjnego nie powinno być traktowane jako bezpieczne tylko dlatego, że wygląda profesjonalnie. Dziś właśnie profesjonalny wygląd bywa częścią przynęty.

Po czwarte, jeśli zadanie wymaga uruchomienia projektu, instalacji nietypowych pakietów, pracy na portfelach testowych albo logowania do zewnętrznych usług, to tym bardziej trzeba zachować ostrożność.

Co to oznacza dla firm zatrudniających developerów

Ten przypadek ma znaczenie dużo szersze niż tylko sektor krypto. Każda organizacja, która zatrudnia programistów, prowadzi zdalne rekrutacje, korzysta z GitHuba, VS Code, zadań domowych i testów technicznych, powinna potraktować ten scenariusz serio.

Największy błąd byłby prosty: uznać, że to problem wyłącznie Web3. Sam wektor wejścia jest znacznie bardziej uniwersalny. Fałszywa rekrutacja może dotyczyć backend developera, DevOpsa, QA, analityka bezpieczeństwa czy freelancera od aplikacji mobilnych.

W praktyce firmy powinny zadbać o to, żeby:

• nie uruchamiać zewnętrznych zadań rekrutacyjnych bez kontroli źródła,
• uczyć zespoły techniczne weryfikacji repozytoriów i zadań testowych,
• monitorować nietypowe zachowania na stacjach developerskich,
• ograniczać przechowywanie wrażliwych danych i kluczy na zwykłych stacjach roboczych.

To jest materiał dla awareness, nie tylko dla SOC

Łatwo uznać, że to temat wyłącznie dla zespołów technicznych, threat intelligence albo SOC. To byłby błąd. To jest również bardzo dobry materiał do awareness.

Pokazuje przecież coś, co warto tłumaczyć każdej organizacji technologicznej: phishing nie zawsze wygląda jak tandetny mail. Czasem wygląda jak atrakcyjna oferta pracy, dobrze zrobione repozytorium i zadanie techniczne, które trzeba po prostu odpalić.

W firmach technologicznych awareness powinien obejmować nie tylko skrzynkę mailową, ale też:

• rekrutacje,
• zadania techniczne,
• repozytoria,
• rozszerzenia IDE,
• fałszywe profile firm i rekruterów,
• presję związaną z atrakcyjną ofertą.

Jeśli firma szkoli ludzi wyłącznie z maili o paczce i fakturze, to nie przygotowuje zespołów technicznych na scenariusze, które naprawdę ich dotyczą.

Wnioski w kontekście ataku i fałszywego zadania rekrutacyjnego

Historia HexagonalRodent dobrze pokazuje, że AI nie musi uczynić atakującego genialnym, żeby uczynić go skutecznym. Wystarczy, że pomoże mu szybciej tworzyć wiarygodne firmy frontowe, lepsze przynęty, sprawniejsze malware i bardziej przekonujące zadania rekrutacyjne.

Jeśli Twoi ludzie pracują na kodzie, repozytoriach i zadaniach technicznych, to phishing może przyjść dokładnie tą drogą, która wydaje się najbardziej naturalna. Nie przez prosty formularz logowania, ale przez codzienną pracę.

Jeżeli chcesz budować odporność na takie scenariusze, nie wystarczy ogólny trening z podejrzanych maili. Trzeba ćwiczyć także te sytuacje, które wyglądają profesjonalnie, logicznie i zawodowo. Właśnie tam dziś najłatwiej ukryć skuteczny atak.

Jeżeli chcesz sprawdzić, czy użytkownicy zatrzymaliby się we właściwym momencie, zanim uruchomią projekt albo podadzą dane, dobrym początkiem jest quiz phishingowy PHISHLY.