Programista też daje się złapać na phishing. 7 przynęt, które wyglądają całkiem normalnie

Część opisanych niżej mechanizmów była obserwowana w rzeczywistych kampaniach. Inne są realistycznymi scenariuszami treningowymi wynikającymi z codziennego sposobu pracy zespołów technicznych. Nie należy traktować wszystkich siedmiu punktów jako jednej kampanii ani jako listy ataków potwierdzonych obecnie w Polsce.

Dlaczego programista jest wartościowym celem

Programista może mieć dostęp do kodu źródłowego, repozytoriów, systemów zgłoszeniowych, chmury, sekretów CI/CD, kluczy API i środowisk deweloperskich. Samo przejęcie skrzynki pocztowej może być dla napastnika dopiero początkiem. Znacznie większą wartość może mieć możliwość wejścia do repozytorium, odczytania danych konfiguracyjnych albo uzyskania dostępu do narzędzia, które łączy wiele systemów.

Dlatego przynęta skierowana do zespołu technicznego powinna być oceniana nie tylko po domenie nadawcy. Trzeba też sprawdzić, czy żądane działanie pasuje do normalnego procesu i czy można je potwierdzić bez używania linku z wiadomości.

1. GitHub: zaproszenie, przegląd kodu albo „pilna” wiadomość

GitHub jest naturalnym elementem pracy wielu zespołów. Powiadomienie o pull request, prośbie o przegląd kodu, nowym repozytorium albo komentarzu nie wygląda jak coś wyjątkowego.

W kwietniu 2026 r. Cisco Talos, zespół analizy zagrożeń firmy Cisco, opisał kampanie wykorzystujące mechanizmy powiadomień GitHub do dostarczania phishingu. Napastnicy umieszczali własną treść w aktywności platformy, a wiadomość była później wysyłana przez legalną infrastrukturę GitHub. Oznacza to, że poprawne SPF, DKIM i DMARC nie muszą odpowiadać na pytanie, czy sama treść ma sens.

Szerzej ten mechanizm opisujemy w materiale o phishingu przez powiadomienia GitHub i Jira.

Co powinno zatrzymać odbiorcę? Nieoczekiwane repozytorium, nietypowa prośba finansowa albo administracyjna, link prowadzący poza zwykły workflow oraz komunikat, którego nie da się potwierdzić po samodzielnym wejściu do GitHub.

2. Jira: ticket P1, incydent i zaproszenie do projektu

Jira ma inny kontekst, ale wykorzystuje podobny odruch. Programista dostaje tickety, wzmianki i zaproszenia do projektów. Wiadomość o awarii produkcyjnej albo incydencie oznaczonym jako P1 może naturalnie wywołać presję czasu.

Talos opisał nadużywanie mechanizmu zaproszeń Jira. Napastnik może przygotować projekt lub zaproszenie tak, aby legalna platforma dostarczyła złośliwy przekaz do odbiorcy.

Sygnałem ostrzegawczym nie musi być więc fałszywa domena. Może nim być brak zgodności z kontekstem: projekt, którego zespół nie zna, osoba spoza organizacji, prośba o logowanie w nieoczekiwanym miejscu albo polecenie wykonania czynności poza zwykłym procesem obsługi zgłoszeń.

3. VS Code: „krytyczna podatność, zainstaluj poprawkę”

W marcu 2026 r. zespół Socket zajmujący się bezpieczeństwem łańcucha dostaw oprogramowania opisał masową kampanię wymierzoną w programistów przez GitHub Discussions. Wiadomości udawały alert o krytycznej podatności Visual Studio Code i kierowały do zewnętrznego pobrania, które miało dostarczyć złośliwe oprogramowanie.

Ten scenariusz działa dlatego, że aktualizacja narzędzia deweloperskiego nie jest dla programisty czymś niezwykłym. Problem zaczyna się wtedy, gdy „pilna poprawka” wymaga pobrania pliku z miejsca, którego zespół normalnie nie używa.

Na PHISHLY mamy osobny opis tej kampanii: fałszywy alert VS Code przez GitHub Discussions.

Bezpieczniejszy odruch: sprawdzić aktualizację w samym narzędziu, oficjalnym repozytorium albo dokumentacji producenta zamiast instalować plik z linku przesłanego w dyskusji lub wiadomości.

4. OAuth: prawdziwy ekran nie gwarantuje bezpiecznej operacji

OAuth służy do delegowania dostępu między aplikacjami. W praktyce użytkownik może zobaczyć prawdziwy ekran Microsoft lub innego dostawcy tożsamości i nadal uczestniczyć w niebezpiecznym procesie.

Microsoft opisuje phishing polegający na nakłonieniu użytkownika do zaakceptowania uprawnień dla złośliwej aplikacji. W takim wariancie napastnik nie musi poznać hasła, jeśli użytkownik świadomie lub nieświadomie nada aplikacji dostęp do swoich danych. W 2026 r. Microsoft opisał też kampanie nadużywające prawidłowych mechanizmów przekierowań OAuth, gdzie legalna domena dostawcy tożsamości była częścią ścieżki prowadzącej dalej do strony kontrolowanej przez atakującego.

Dlatego pytanie nie powinno kończyć się na „czy domena logowania jest prawdziwa?”. Trzeba jeszcze sprawdzić jakiej aplikacji nadajemy dostęp, jakie uprawnienia są wymagane i dlaczego ta operacja pojawiła się właśnie teraz.

Więcej o tym mechanizmie: OAuth consent phishing i device code.

5. npm, pakiety i tokeny: techniczny komunikat brzmi wiarygodnie

Ekosystem pakietów daje napastnikom kilka dróg działania. Dokumentacja npm wymienia przejmowanie kont przez kompromitację haseł oraz ryzyko złośliwych pakietów. Microsoft w maju 2026 r. opisał aktywny zestaw pakietów podszywających się nazwami pod popularne biblioteki. Po instalacji wykradały m.in. dane dostępowe do AWS, HashiCorp Vault, GitHub Actions i tokeny npm.

Sam złośliwy pakiet nie jest phishingiem. Dla security awareness istotny jest jednak kontekst, który można wykorzystać jako przynętę: „token npm wygasa”, „wymagana weryfikacja właściciela pakietu”, „krytyczna podatność zależności” albo „pakiet został zablokowany i wymaga logowania”.

Jeżeli taki komunikat pojawia się niespodziewanie, najlepiej otworzyć npm lub firmowy system zarządzania zależnościami bezpośrednio i sprawdzić stan konta, pakietu albo tokenu tam, gdzie zespół robi to na co dzień.

6. CI/CD: build failed, deployment blocked, secret expired

To jest przede wszystkim scenariusz treningowy, a nie opis jednej konkretnej kampanii z 13 września 2026 r.

Wiadomość „build failed” albo „deployment blocked” pasuje do codziennej pracy programisty. Podobnie komunikat o wygasającym sekrecie, niedziałającym runnerze lub konieczności ponownego połączenia konta z pipeline.

W takiej sytuacji celem symulacji może być sprawdzenie, czy użytkownik:

• wchodzi do panelu CI/CD samodzielnie zamiast przez link;
• rozpoznaje nietypową domenę lub aplikację OAuth;
• nie wpisuje tokenu ani sekretu do formularza otwartego z wiadomości;
• zgłasza nietypowe żądanie zespołowi odpowiedzialnemu za bezpieczeństwo.

Wartość danych CI/CD nie jest hipotetyczna. Opisana przez Microsoft kampania złośliwych pakietów npm była przygotowana m.in. do pozyskiwania sekretów GitHub Actions i danych dostępowych do usług chmurowych.

7. Helpdesk: „mamy problem z twoim MFA albo VPN”

Drugi scenariusz treningowy przenosi atak poza e-mail. Osoba podszywająca się pod administratora może zadzwonić lub napisać na komunikatorze i poprosić o zatwierdzenie MFA, uruchomienie narzędzia zdalnego wsparcia, zmianę ustawień VPN albo wykonanie polecenia na komputerze.

Techniczny charakter rozmowy bywa tu częścią przynęty. Programista może usłyszeć prawidłowe nazwy usług i procedur, ale nadal nie ma pewności, kto jest po drugiej stronie.

Jeżeli kontakt jest niespodziewany, warto zakończyć rozmowę i samodzielnie wrócić do znanego kanału helpdesku. Ten sam mechanizm omawiamy szerzej w materiale o fałszywym helpdesku w Microsoft Teams.

7 sygnałów, które powinny zatrzymać programistę

1. Nieoczekiwane zaproszenie do repozytorium, projektu lub organizacji, którego nie potwierdza bieżąca praca zespołu.
2. Presja na natychmiastowe logowanie po informacji o awarii, incydencie albo blokadzie wdrożenia.
3. Aktualizacja narzędzia z zewnętrznego linku, choć normalnie aktualizacje są instalowane z oficjalnego kanału.
4. Zgoda OAuth o zbyt szerokich uprawnieniach albo dla aplikacji, której użytkownik nie rozpoznaje.
5. Prośba o token, klucz API, recovery code lub kod MFA przesłana przez wiadomość, telefon albo formularz.
6. Żądanie ponownego logowania, którego nie widać po bezpośrednim wejściu do oficjalnej usługi.
7. Administrator prosi o narzędzie zdalnego dostępu lub wykonanie polecenia, ale kontakt nie został potwierdzony znanym kanałem.

Jak ćwiczyć zespół developerski

Zespół techniczny nie powinien dostawać wyłącznie tych samych scenariuszy, które kieruje się do całej firmy. Jeżeli jego codzienna praca opiera się na GitHub, Jira, pipeline CI/CD i usługach chmurowych, właśnie tam warto umieścić kontrolowaną symulację.

Przykładowe scenariusze:

• GitHub: „Zostałeś dodany do przeglądu krytycznego pull request”.
• Jira: „Incydent P1 — ticket przypisany do Ciebie”.
• CI/CD: „Deployment failed — ponowne uwierzytelnienie wymagane”.

Bezpieczny test nie powinien zbierać prawdziwych haseł, tokenów ani sekretów. Lepiej mierzyć, czy użytkownik kliknął, czy próbował wykonać działanie, czy zgłosił wiadomość i jak szybko to zrobił. Wynik daje podstawę do kolejnej kampanii i krótkiego szkolenia dokładnie w tym obszarze, który sprawił problem.

Jeżeli chcesz sprawdzić odporność zespołu na scenariusze związane z repozytoriami, OAuth i CI/CD, zobacz testy phishingowe dla firm oraz stronę dla software house i zespołów IT.

Podsumowanie

Phishing skierowany do programisty może wyglądać bardziej profesjonalnie niż klasyczna wiadomość podszywająca się pod kuriera. Im lepiej przynęta pasuje do codziennego procesu, tym mniej powodów odbiorca widzi, żeby się zatrzymać.

Dlatego zespołów technicznych nie warto szkolić wyłącznie na fałszywe paczki i faktury. W ich przypadku ćwiczenia powinny obejmować repozytoria, systemy zgłoszeń, OAuth, alerty narzędzi, pakiety, CI/CD i kontakt z helpdeskiem. To właśnie tam najłatwiej sprawdzić, czy użytkownik umie odróżnić normalny workflow od żądania, którego nie powinien wykonać.