Git hooks jako przynęta. Gdy fałszywa rekrutacja uruchamia malware przy commicie

2026-05-12

TL;DR

Fałszywa rekrutacja developerska to nie jest zwykły phishing na CV. Atakujący potrafią dać kandydatowi repozytorium z zadaniem technicznym, które wygląda jak normalny etap rozmowy o pracę. Problem zaczyna się wtedy, gdy repozytorium zawiera złośliwe Git hooks, czyli skrypty uruchamiane automatycznie przy pracy z kodem.

W opisywanym wariancie mechanizm jest szczególnie podstępny: malware nie musi wystartować po kliknięciu w plik wykonywalny. Może uruchomić się wtedy, gdy developer wykona normalną czynność, na przykład spróbuje zrobić commit. To przesuwa phishing z poziomu wiadomości na poziom zaufanego workflow pracy programisty.

Ten przypadek jest ważny także dla polskich firm. Software house, startup, zespół DevOps, freelancer albo kandydat do pracy w IT może dostać zadanie rekrutacyjne, które wygląda rozsądnie, ale uruchamia kod w tle. Atak nie musi być wymierzony w firmę bezpośrednio, żeby firma poniosła skutki.

Fałszywa oferta pracy jako punkt wejścia

Kampanie z rodziny Contagious Interview od dawna wykorzystują fałszywych rekruterów i zadania techniczne. Atakujący kontaktują się z developerami, często przez kanały zawodowe, i proponują udział w procesie rekrutacyjnym. Następnie przekazują repozytorium z kodem, które kandydat ma pobrać, uruchomić albo poprawić.

To działa, bo kontekst jest naturalny. Developerzy regularnie klonują repozytoria, otwierają projekty, instalują zależności i wykonują testy. Zadanie rekrutacyjne nie budzi takiej samej czujności jak podejrzany załącznik w mailu.

Właśnie dlatego ten scenariusz jest groźny. Nie próbuje złamać procesu pracy developera. Wykorzystuje go dokładnie takim, jaki jest.

W polskim rynku IT taki atak mógłby wyglądać bardzo zwyczajnie. Kandydat dostaje wiadomość od rzekomego rekrutera, link do repozytorium, krótki opis zadania i prośbę o odesłanie zmian. Jeśli projekt jest wiarygodny, a firma brzmi znajomo, część osób przejdzie do pracy bez dodatkowej weryfikacji.

Git hooks są legalne, ale automatyczne

Git hooks mają sens w legalnej pracy. Mogą wymuszać formatowanie kodu, uruchamiać testy, sprawdzać jakość commitów, blokować sekrety albo synchronizować narzędzia. Ich siła polega na automatyzacji. I właśnie ta siła staje się ryzykiem.

Git hooks to skrypty uruchamiane automatycznie przez Git przy wybranych czynnościach. Pre-commit hook działa tuż przed zapisaniem commita. W legalnym projekcie może uruchamiać testy albo formatowanie kodu. W złośliwym repozytorium może uruchomić loader malware, rozpoznanie systemu, pobranie kolejnego payloadu albo kradzież danych.

Jeżeli w repozytorium znajduje się złośliwy pre-commit hook, skrypt może uruchomić się w chwili, która dla użytkownika wygląda rutynowo. Developer wykonuje standardową czynność, a w tle startuje proces przygotowany przez atakującego.

W opisanym wariancie malware jest cross-platform, czyli dostosowuje działanie do systemu operacyjnego. Inny payload może trafić na Windows, inny na macOS i Linux. To ważne, bo developerzy często pracują poza standardowym obrazem korporacyjnego Windowsa. MacBooki, Linux, WSL, lokalne środowiska i narzędzia open source są normalną częścią pracy.

Dlaczego to jest problem firmowy

Na pierwszy rzut oka ofiarą jest pojedynczy developer szukający pracy. W praktyce ryzyko może dotyczyć także jego obecnego pracodawcy. Stacja developerska często zawiera klucze SSH, tokeny do repozytoriów, dostęp do chmury, konfiguracje CI/CD, pliki .env, konta npm, PyPI, Docker Hub, GitHub, GitLab i narzędzia wewnętrzne.

CI/CD oznacza continuous integration i continuous delivery albo deployment, czyli automatyczne budowanie, testowanie i wdrażanie kodu. To jeden z najcenniejszych obszarów dla atakującego, bo dostęp do pipeline może oznaczać możliwość modyfikacji oprogramowania, kradzieży sekretów albo wejścia głębiej w środowisko firmy.

Jeżeli malware przejmie komputer developera, może nie interesować się tylko prywatnym portfelem kryptowalutowym. Może szukać dostępu do kodu, sekretów, pipeline, repozytoriów i środowisk testowych. To już nie jest prywatny incydent kandydata. To potencjalny incydent supply chain.

Supply chain w bezpieczeństwie oznacza łańcuch dostaw oprogramowania, narzędzi, bibliotek, zależności i procesów, które prowadzą od kodu do gotowego produktu. Jeśli atak zaczyna się na laptopie developera, może później przenieść się na repozytorium, pipeline albo produkt klienta.

Samo skanowanie linku nie wystarczy

W klasycznym phishingu często pytamy: czy link jest podejrzany. W tym scenariuszu to za mało. Link do repozytorium może prowadzić do legalnej platformy. Sam kod może wyglądać wiarygodnie. Projekt może się uruchamiać. Problem może siedzieć w miejscu, którego kandydat nie sprawdza: w hookach, konfiguracji IDE, skryptach instalacyjnych, zależnościach albo zadaniach automatycznych.

IDE, czyli integrated development environment, to środowisko programistyczne, na przykład Visual Studio Code, IntelliJ IDEA albo WebStorm. Wiele takich narzędzi może uruchamiać konfiguracje projektu, podpowiadać instalację zależności albo wykonywać zadania automatyczne. To wygodne, ale przy obcym repozytorium wymaga ostrożności.

Dlatego awareness dla developerów musi być inny niż awareness dla zwykłego użytkownika biurowego. Developerzy potrzebują checklisty dla obcych repozytoriów, a nie tylko instrukcji rozpoznawania fałszywych maili.

Przed uruchomieniem obcego repozytorium developer powinien sprawdzić szczególnie: .git/hooks, .githooks, .vscode, package.json, skrypty instalacyjne, pliki CI/CD, zależności oraz polecenia wykonywane przy starcie projektu.

Jak powinien reagować developer

Nieznane repozytorium z procesu rekrutacyjnego powinno być traktowane jak potencjalnie złośliwe. To nie znaczy, że każdy rekruter jest oszustem. To znaczy, że zadanie techniczne należy uruchamiać w środowisku, które może zostać utracone bez większych skutków.

Najlepsza praktyka to izolowana maszyna wirtualna albo kontener bez zapisanych sekretów, bez prywatnych kluczy, bez dostępu do firmowych repozytoriów i bez podpiętych menedżerów haseł. Przed uruchomieniem warto sprawdzić katalogi z hookami, konfigurację IDE, skrypty package managera, pliki instalacyjne i wszystkie miejsca, które mogą wykonywać kod automatycznie.

W firmach warto to ustandaryzować. Jeśli pracownik wykonuje prywatne zadania rekrutacyjne na służbowym sprzęcie, organizacja powinna wiedzieć, jakie obowiązują zasady. Brak zasad oznacza, że decyzja spada na użytkownika, a atakujący właśnie na to liczy.

Co powinien zrobić zespół bezpieczeństwa

Zespół IT i Security powinien potraktować developerów jako grupę wysokiego ryzyka. To osoby, które mają większy kontakt z obcym kodem, częściej pracują poza typowym zestawem aplikacji i często posiadają dostęp do sekretów o wysokiej wartości.

W praktyce warto monitorować nietypowe uruchomienia z katalogów projektowych, połączenia wychodzące po operacjach Git, wykonywanie skryptów z hooków, nowe procesy po otwarciu repozytorium w IDE i próby dostępu do plików z sekretami. Warto też ograniczać trwałe przechowywanie tokenów lokalnie oraz promować krótkotrwałe poświadczenia i segmentację dostępu.

To dobry kandydat na ćwiczenie awareness techniczne, inne niż klasyczny phishing dla całej firmy. Nie chodzi o to, czy developer kliknie link. Chodzi o to, czy rozpozna ryzyko repozytorium i uruchomi je w bezpiecznym środowisku.

Warto połączyć ten temat z wpisem o nadużywaniu legalnych platform w phishingu. GitHub, Git i środowisko developerskie same w sobie nie są problemem. Problem zaczyna się wtedy, gdy zaufany workflow staje się nośnikiem ataku.

Wniosek

Git hooks w kampanii rekrutacyjnej pokazują, że phishing dla developerów nie musi wyglądać jak phishing. Może wyglądać jak rozmowa o pracę, normalne zadanie techniczne i repozytorium z kodem. Atakujący nie walczy z nawykami developera. Wykorzystuje je.

Dobra obrona zaczyna się od prostego założenia: obcy kod to obce środowisko. Nie uruchamiamy go tam, gdzie mamy firmowe sekrety, prywatne klucze, tokeny i dostęp do produkcji. W świecie, w którym supply chain zaczyna się na laptopie developera, awareness musi obejmować także Git, IDE i rekrutacyjne zadania techniczne.