RecruitTrap: fałszywy rekruter chce firmowego konta. Jak działa phishing na telefonie?

CTM360 opisał ponad 3000 phishingowych adresów URL obserwowanych w ciągu dwóch miesięcy, podszywających się pod procesy rekrutacyjne ponad 50 organizacji. Kampania wykorzystuje fałszywe zaproszenia na rozmowę, strony do umawiania spotkań i technikę Browser-in-the-Browser. Zimperium pokazało dodatkowo, że na telefonie ten sam mechanizm może zmienić się w pełnoekranowy fałszywy ekran logowania.

Dla security awareness oznacza to konkretny problem. Pracownik może rozmawiać o zmianie pracy poza obowiązkami służbowymi, a mimo tego jego decyzja może narazić obecnego pracodawcę, jeżeli w zewnętrznym procesie rekrutacyjnym poda firmową tożsamość.

Czym jest RecruitTrap

CTM360 używa nazwy RecruitTrap dla dużej kampanii phishingowej opartej na fałszywych procesach rekrutacyjnych. Badacze opisują zaproszenia na rozmowy, podrobione portale do umawiania spotkań oraz fałszywe okna logowania.

W ciągu dwóch miesięcy CTM360 zidentyfikował ponad 3000 phishingowych adresów URL powiązanych z podszywaniem się pod rekruterów i procesy zatrudnienia ponad 50 organizacji. Według firmy wśród obserwowanych celów szczególnie często pojawiali się specjaliści marketingu.

Nie należy z tego wyciągać wniosku, że każda fałszywa oferta pracy jest częścią RecruitTrap albo że kampania odpowiada za określony odsetek wszystkich ataków rekrutacyjnych. Liczby opisują zbiór infrastruktury obserwowany przez CTM360.

Od wiadomości rekrutera do fałszywego logowania

Początek ataku jest wiarygodny właśnie dlatego, że nie wygląda jak typowy komunikat bezpieczeństwa. Użytkownik może dostać wiadomość od osoby podającej się za rekrutera, zaproszenie na spotkanie albo link do strony, na której ma wybrać termin rozmowy.

The Hacker News, opisując badanie CTM360, wskazuje dwa spotykane warianty. Jeden przypomina popularny portal do umawiania spotkań. Drugi wygląda jak strona rekrutacyjna konkretnej marki. W obu przypadkach celem jest doprowadzenie użytkownika do logowania.

To moment, w którym naturalny proces zawodowy zmienia się w phishing. Kandydat nie widzi komunikatu „twoje konto wygaśnie”. Widzi ciąg dalszy rozmowy o pracy i może uznać logowanie za zwykły element rezerwacji spotkania.

Mechanizm dobrze pokazuje, dlaczego phishing nie powinien być definiowany wyłącznie przez wygląd wiadomości. O skuteczności decyduje cała historia, którą napastnik buduje przed prośbą o dane.

Dlaczego prywatne adresy są odrzucane

Najbardziej charakterystycznym elementem opisanym przez Zimperium jest logika kwalifikacji celu.

Badacze wskazują, że phishingowa strona nie chce każdego konta. Potrafi odrzucać prywatne domeny e-mail i wymuszać podanie firmowej tożsamości. To odwraca intuicję użytkownika: ktoś może pomyśleć, że wymaganie adresu służbowego zwiększa profesjonalizm procesu, choć w rzeczywistości pomaga napastnikowi odsiać mniej wartościowe konta.

Firmowe konto może być połączone z pocztą, dokumentami, komunikacją wewnętrzną, aplikacjami SaaS, reklamami, profilem marki lub innymi zasobami organizacji. Zimperium opisuje te możliwości jako konsekwencje potencjalnego przejęcia firmowej tożsamości. Nie oznacza to jednak, że badacze udokumentowali w RecruitTrap konkretny przypadek pełnego przejęcia sieci czy lateral movement po każdym wpisaniu hasła.

Dla pracownika można z tego wyprowadzić prostą regułę: zewnętrzny rekruter nie powinien potrzebować danych logowania do konta obecnego pracodawcy, aby umówić rozmowę o innej pracy.

Browser-in-the-Browser: fałszywe okno, które udaje przeglądarkę

Na komputerze RecruitTrap może używać techniki Browser-in-the-Browser, w skrócie BitB. Strona phishingowa rysuje wewnątrz własnego interfejsu okno przypominające prawdziwe okno logowania.

Takie okno może zawierać pasek adresu, ikonę kłódki i elementy znane z legalnego procesu Google lub Facebook. Problem polega na tym, że nie jest to osobne okno przeglądarki. Całość jest częścią strony kontrolowanej przez napastnika.

To osłabia prostą poradę „sprawdź adres w oknie logowania”, ponieważ użytkownik może patrzeć na adres narysowany przez atakującego. Lepszą kontrolą jest sprawdzenie, czy proces w ogóle powinien wymagać firmowego logowania, oraz otwarcie właściwej usługi niezależnie, zamiast kontynuowania sesji z linku przesłanego przez rekrutera.

Dlaczego telefon zmienia sytuację

24 sierpnia 2026 Zimperium zLabs opisało warianty powiązane z RecruitTrap, które dostosowują widok do urządzenia.

Na desktopie strona może pokazać fałszywe okno Browser-in-the-Browser. Na mniejszym ekranie taki element jest mniej naturalny, dlatego kampania może przełączyć się na pełnoekranowy fałszywy ekran logowania. W takim widoku użytkownik ma mniej typowych wskazówek pozwalających szybko ocenić, gdzie naprawdę się znajduje.

Zimperium opublikowało też 46 wcześniej niepublikowanych IOC związanych z analizowaną aktywnością i wskazało, że domeny rekrutacyjne korzystały z infrastruktury rozproszonej między popularnymi dostawcami hostingu, chmury i parkowania domen. Część domen pozostawała poza publicznymi listami ostrzegawczymi przez dłuższy czas.

Z tego powodu sama odpowiedź „nasz filtr URL jeszcze tego nie blokuje” nie powinna być traktowana jako potwierdzenie bezpieczeństwa. Nowa domena może działać zanim zostanie oznaczona przez dostawców threat intelligence.

A co z MFA

CTM360 opisuje bardziej zaawansowane warianty RecruitTrap, które mogą przekazywać wyzwania MFA w czasie rzeczywistym. Nie oznacza to, że każde wdrożenie MFA jest nieskuteczne ani że każda strona z tej kampanii miała taki mechanizm.

Istotna jest różnica między metodami uwierzytelniania. NIST SP 800-63B wskazuje, że rozwiązania wymagające ręcznego wpisania kodu OTP nie są phishing-resistant, ponieważ użytkownik może przekazać taki kod fałszywemu serwisowi, a napastnik może go użyć wobec prawdziwego dostawcy.

WebAuthn działa inaczej. Uwierzytelnienie jest związane z właściwą domeną usługi, dzięki czemu fałszywa strona nie może po prostu poprosić użytkownika o sekret i przekazać go dalej w taki sam sposób.

Dla organizacji wniosek jest dwuwarstwowy: szkolić użytkowników, ale jednocześnie ograniczać skutki błędu przez metody uwierzytelniania odporne na phishing, warunki dostępu i monitoring nietypowych logowań.

RecruitTrap to nie Operation Dream Job

PHISHLY ma już opisane kampanie, w których fałszywa rekrutacja prowadzi do uruchomienia malware. Najbliższym przykładem jest Operation Dream Job, gdzie atrakcyjna oferta pracy służy jako przynęta do dostarczenia złośliwego pliku lub aplikacji.

RecruitTrap opisuje inny punkt ataku. Tutaj centralnym mechanizmem jest kradzież poświadczeń przez fałszywy portal logowania i potencjalne przejęcie firmowego konta.

Nie należy też automatycznie przypisywać RecruitTrap grupie Lazarus czy innemu aktorowi tylko dlatego, że inne kampanie wykorzystują temat rekrutacji. W analizowanych źródłach CTM360 i Zimperium nie ma podstaw do takiej atrybucji.

Rozróżnienie ma znaczenie dla szkoleń. W przypadku Operation Dream Job użytkownik powinien zatrzymać się przed uruchomieniem obcego pliku lub zadania. W RecruitTrap punkt decyzji pojawia się wcześniej: czy zewnętrzna strona rekrutacyjna ma jakikolwiek uzasadniony powód, aby poprosić o firmowe dane logowania?

Polski kontekst: rekrutacja jest już scenariuszem bezpieczeństwa

RecruitTrap nie jest tym samym zjawiskiem, które opisuje CSIRT KNF. Polski dokument pokazuje jednak, że kontekst rekrutacji jest wykorzystywany także w innych zaawansowanych operacjach socjotechnicznych.

W raporcie z kwietnia 2026 CSIRT KNF przypomina o wcześniejszych ostrzeżeniach dotyczących fałszywych rekrutacji i opisuje między innymi kampanie wykorzystujące strony phishingowe podszywające się pod platformy do wideokonferencji, przejmowanie komunikacji oraz długotrwałe budowanie wiarygodności.

Nie jest to dowód na obecność RecruitTrap w Polsce. Jest to natomiast argument, aby procesy rekrutacyjne i kontakty zawodowe uwzględniać w modelu human risk, również wtedy, gdy zaczynają się poza pocztą służbową.

Co powinien zrobić pracownik

Pierwszym zabezpieczeniem nie powinno być rozpoznawanie każdego wariantu graficznego phishingu. Skuteczniejsza jest kontrola sensu żądania.

Jeżeli osoba podająca się za rekrutera wysyła link do portalu i proces nagle wymaga firmowego konta, warto przerwać i odpowiedzieć sobie na kilka pytań:

• dlaczego rekruter z innej organizacji potrzebuje tożsamości mojego obecnego pracodawcy;
• czy tę samą rozmowę można umówić bez logowania;
• czy domenę rekrutera można potwierdzić na oficjalnej stronie firmy;
• czy kontaktująca się osoba rzeczywiście pracuje w organizacji, pod którą się podaje;
• czy prywatny adres e-mail jest odrzucany bez sensownego powodu;
• czy po kliknięciu linku pojawił się nietypowy ekran „Continue with Google” albo inny proces SSO.

Szczególnej ostrożności wymaga telefon. Jeśli nie można łatwo ocenić adresu strony lub przepływ wygląda jak pełnoekranowa aplikacja, warto zamknąć link i samodzielnie wejść na oficjalną stronę firmy.

Jeżeli dane zostały już wpisane, zdarzenie powinno zostać zgłoszone do IT lub zespołu bezpieczeństwa. Nie warto czekać na potwierdzenie, że doszło do przejęcia. Organizacja może szybciej zresetować poświadczenia, unieważnić sesje i sprawdzić nietypowe logowania.

Co powinna zrobić organizacja

Technologia i szkolenie powinny się uzupełniać.

Po stronie tożsamości warto stopniowo przechodzić na metody uwierzytelniania odporne na phishing, ograniczać dostęp z nieznanych lub niezgodnych urządzeń i monitorować nowe sesje oraz nietypowe lokalizacje. Sama ochrona hasła nie wystarcza, jeżeli użytkownik zostanie przekonany do wpisania go na stronie atakującego.

Po stronie procesów organizacja powinna jasno powiedzieć pracownikom, że prywatne poszukiwanie pracy może tworzyć ryzyko służbowe, jeśli używane są firmowe konta lub urządzenia. Nie chodzi o kontrolowanie życia zawodowego pracownika. Chodzi o prostą granicę: firmowa tożsamość nie jest kontem do logowania w zewnętrznych portalach rekrutacyjnych.

Po stronie edukacji warto ćwiczyć właśnie takie scenariusze. Program security awareness powinien obejmować nie tylko faktury, przesyłki i wygasające hasła, ale również pozytywne przynęty: ofertę pracy, zaproszenie na spotkanie czy propozycję współpracy.

W testach phishingowych dla firm można bezpiecznie odtworzyć moment, w którym fałszywy rekruter prowadzi użytkownika do kontrolowanego ekranu logowania. Celem nie powinno być samo policzenie kliknięć. Warto mierzyć, czy pracownik rozpoznał brak sensu żądania firmowego konta, przerwał proces i zgłosił zdarzenie.

Co z tego wynika dla security awareness

RecruitTrap pokazuje, że granica między aktywnością prywatną a ryzykiem firmowym jest coraz mniej oczywista. Pracownik może korzystać z własnego czasu i odpowiadać na ofertę pracy, ale napastnika interesuje konto należące do jego obecnej organizacji.

Dlatego szkolenie nie powinno kończyć się na haśle „sprawdzaj linki”. Użytkownik potrzebuje również prostych reguł decyzyjnych:

• zewnętrzna rekrutacja nie wymaga danych logowania obecnego pracodawcy;
• prywatny proces nie powinien być prowadzony z użyciem firmowego SSO bez wyraźnej potrzeby biznesowej;
• ekran na telefonie może ukrywać część sygnałów, na których użytkownik zwykle polega;
• MFA nie jest jedną technologią i nie każda metoda zapewnia odporność na phishing;
• podejrzane logowanie należy zgłosić od razu, nawet jeśli nie ma jeszcze dowodu na przejęcie konta.

To dobry przykład human risk, w którym bezpieczeństwo zależy zarówno od zachowania człowieka, jak i od architektury tożsamości. Gdy oba elementy działają razem, pojedyncza pomyłka ma mniejszą szansę zamienić się w pełny incydent.