Code of conduct phishing. Gdy fałszywa sprawa HR kończy się przejęciem sesji

2026-05-04
TL;DR
Microsoft opisał wieloetapową kampanię phishingową, w której atakujący podszywali się pod wewnętrzne komunikaty dotyczące code of conduct, compliance i rzekomych spraw pracowniczych. Code of conduct to firmowy kodeks postępowania: zestaw zasad dotyczących zachowania, etyki, zgodności z procedurami i odpowiedzialności pracowników.
Kampania była obserwowana między 14 a 16 kwietnia 2026 roku. Według Microsoftu objęła ponad 35 tysięcy użytkowników, ponad 13 tysięcy organizacji i 26 krajów. Nie był to prosty phishing z jednym linkiem. Użytkownik przechodził przez dopracowany komunikat, załącznik, CAPTCHA, stronę pośrednią i finalnie trafiał do przepływu adversary-in-the-middle, czyli AiTM. W takim modelu atakujący pośredniczy w logowaniu i może przechwycić token sesji po poprawnym uwierzytelnieniu.
Najważniejszy wniosek dla firm jest prosty: phishing coraz częściej nie wygląda jak wiadomość od zewnętrznego oszusta. Wygląda jak wewnętrzny proces HR, compliance albo bezpieczeństwa.
O co chodzi w tej kampanii
Według Microsoft Security Blog, Microsoft Defender Research zaobserwował kampanię phishingową wykorzystującą przynęty związane z wewnętrznymi zasadami postępowania, regulacjami i compliance. Wiadomości były wysyłane falami między 14 a 16 kwietnia 2026 roku.
Microsoft wskazuje, że kampania dotknęła ponad 35 tysięcy użytkowników, ponad 13 tysięcy organizacji i 26 krajów, przy czym zdecydowana większość celów znajdowała się w Stanach Zjednoczonych. Najczęściej wskazywane branże to healthcare & life sciences, financial services, professional services oraz technology & software, czyli ochrona zdrowia i nauki biologiczne, usługi finansowe, usługi profesjonalne oraz sektor technologiczny.
To ważne, bo nie mówimy o ręcznie przygotowanym ataku na jedną firmę. Mówimy o kampanii, która wykorzystała bardzo uniwersalny pretekst: wewnętrzną sprawę dotyczącą pracownika, zasad firmy albo rzekomego naruszenia polityki.
Dlaczego pretekst HR i compliance działa tak dobrze
Phishing na fakturę, paczkę albo Microsoft 365 jest już dla wielu osób czymś znajomym. Pretekst code of conduct działa inaczej. Uderza w emocje związane z pracą: obawę przed konsekwencjami, potrzebę szybkiego wyjaśnienia sprawy i poczucie, że wiadomość może dotyczyć czegoś poufnego.
Jeśli pracownik dostaje komunikat sugerujący, że otwarto wobec niego sprawę związaną z polityką firmy, regulaminem albo compliance, naturalna reakcja jest silna. Taki komunikat może wywołać stres nawet u osoby ostrożnej. Odbiorca chce sprawdzić, o co chodzi, zanim sprawa urośnie.
I właśnie na tym polega siła tego scenariusza. Atakujący nie musi obiecywać nagrody ani straszyć blokadą konta. Wystarczy, że zasugeruje wewnętrzny problem, który może dotyczyć reputacji, pracy albo relacji z przełożonymi.
To bardzo dobry przykład phishingu procesowego. Nie chodzi już tylko o logo na ekranie logowania. Chodzi o kontekst organizacyjny, który sprawia, że użytkownik chce działać szybko.
Jak wyglądał łańcuch ataku
Microsoft opisuje, że wiadomości udawały wewnętrzne komunikaty compliance lub regulacyjne. Wykorzystywały nazwy sugerujące komunikację wewnętrzną, raport zespołu albo sprawę dotyczącą zasad postępowania. Tematy wiadomości odnosiły się do rzekomych case logów, polityk firmowych i spraw non-compliance.
Treść wiadomości była dopracowana wizualnie i językowo. Zawierała elementy wzmacniające wiarygodność: informacje o autoryzowanym kanale wewnętrznym, bezpiecznym dostępie i poufnym charakterze sprawy. W części kampanii pojawiał się też motyw zaszyfrowanej komunikacji z użyciem zewnętrznej usługi, co miało uzasadniać nietypowy przepływ.
Po kliknięciu użytkownik trafiał na domenę kontrolowaną przez atakujących. Następnie pojawiała się CAPTCHA, później strona pośrednia informująca, że dokumentacja jest zaszyfrowana i wymaga uwierzytelnienia, a potem kolejne kroki prowadzące do finalnej strony logowania.
To nie był jeden ekran. To była sekwencja zaprojektowana tak, aby użytkownik coraz głębiej wchodził w rzekomo legalny proces.
CAPTCHA nie chroni użytkownika. Może chronić atak przed analizą
W kampanii opisanej przez Microsoft CAPTCHA pełniła ważną rolę. Dla użytkownika wyglądała jak zwykły element bezpieczeństwa. Dla atakującego była bramką, która mogła utrudniać automatyczną analizę, sandboxing i skanery bezpieczeństwa.
To ważna lekcja. Wiele osób odruchowo traktuje CAPTCHA jako sygnał, że strona jest bardziej bezpieczna. W phishingu bywa odwrotnie. CAPTCHA może być częścią scenariusza, który ma wyglądać wiarygodnie i jednocześnie opóźnić detekcję.
Ten sam trend widać szerzej w raporcie Microsoft Email Threat Landscape za Q1 2026. Microsoft opisał tam wzrost CAPTCHA-gated phishing, czyli kampanii, w których ekran weryfikacji jest używany jako bramka przed właściwym phishingiem. Dla firm oznacza to jedno: szkolenie użytkownika nie może kończyć się na radzie, żeby uważał na linki. Użytkownik musi rozumieć, że CAPTCHA, ekran weryfikacji i komunikat o bezpiecznej sesji mogą być częścią oszustwa.
Więcej o tym szerszym trendzie pisaliśmy w artykule Kwiecień 2026 w phishingu. Miesiąc, w którym kliknięcie przestało być największym problemem.
AiTM, czyli atak na sesję, a nie tylko na hasło
Najgroźniejszy etap kampanii pojawiał się na końcu. Microsoft wskazuje, że użytkownik był kierowany do przepływu adversary-in-the-middle. W skrócie: atakujący pośredniczy między ofiarą a prawdziwą usługą logowania.
Dla użytkownika taki proces może wyglądać normalnie. Widzi stronę logowania, wpisuje hasło, przechodzi MFA i ma poczucie, że zrobił wszystko poprawnie. MFA, czyli uwierzytelnianie wieloskładnikowe, to dodatkowy składnik logowania: kod, aplikacja, powiadomienie push, klucz sprzętowy albo passkey.
Problem polega na tym, że w modelu AiTM atakujący może proxy’ować sesję uwierzytelnienia i przechwycić token. Token sesji to cyfrowe potwierdzenie, że użytkownik jest już zalogowany. Jeśli napastnik go przejmie, może uzyskać dostęp do konta bez ponownego przechodzenia MFA.
To dlatego samo stwierdzenie mamy MFA nie zamyka problemu. MFA jest potrzebne, ale jeśli jest podatne na phishing i działa w przepływie, który można przechwycić, organizacja nadal ma ryzyko przejęcia sesji.
Microsoft podobny mechanizm opisywał wcześniej przy Tycoon2FA, gdzie atak zaczynał się od e-maila, prowadził przez wielowarstwowe przekierowania, a następnie kończył się przejęciem tokenów sesji. Wspólny mianownik jest ten sam: użytkownik nie musi tylko oddać hasła. Może nieświadomie oddać efekt poprawnego logowania.
Szerzej ten problem opisaliśmy w materiale Phishing omijający MFA AiTM.
To nie jest zwykły phishing na Microsoft 365
Łatwo byłoby uznać ten przypadek za kolejny wariant phishingu na Microsoft 365. To byłoby zbyt wąskie. Najważniejszym elementem nie jest tutaj logo Microsoftu ani samo logowanie. Najważniejszy jest pretekst, który doprowadza użytkownika do logowania.
Atak zaczyna się od sprawy organizacyjnej: regulaminu, compliance, wewnętrznego postępowania, zasad pracy. To zupełnie inna dynamika niż przy fałszywej fakturze czy wiadomości o paczce. Użytkownik może czuć, że sprawa dotyczy jego pozycji w firmie, reputacji albo obowiązków pracowniczych.
To sprawia, że takie kampanie są bardzo wartościowe jako scenariusze awareness. Pokazują, że phishing może wejść w obszary HR, prawne, compliance i komunikacji wewnętrznej. A to są kanały, którym pracownicy zwykle ufają bardziej niż przypadkowym wiadomościom marketingowym.
Co powinno zapalić lampkę ostrzegawczą
W tym scenariuszu podejrzany nie musi być sam wygląd wiadomości. Może być dopracowany i zgodny z językiem firmowym. Dlatego ważniejsza jest ocena procesu.
Użytkownik powinien zatrzymać się, jeśli wiadomość informuje o poufnej sprawie HR, compliance albo code of conduct, której wcześniej nikt nie zapowiadał. Tak samo podejrzana jest presja czasu, sugestia konsekwencji służbowych, załącznik z linkiem do strony poza znanym systemem firmy, CAPTCHA przed dostępem do rzekomo wewnętrznej dokumentacji, kilka przekierowań po drodze albo logowanie Microsoft rozpoczęte z nieoczekiwanego linku.
Sygnałem ostrzegawczym jest też sytuacja, w której dokumentacja ma być zaszyfrowana, ale nie została udostępniona przez znany firmowy kanał: intranet, system HR, portal compliance, SharePoint albo system zgłoszeń.
Najprostsza zasada jest praktyczna: spraw wewnętrznych dotyczących regulaminu, HR i compliance nie należy obsługiwać z poziomu nieoczekiwanego linku. Taką wiadomość trzeba zweryfikować znanym kanałem.
Co powinny uporządkować HR i compliance
Ten przypadek jest ważny nie tylko dla IT. Działy HR i compliance również mają tu swoją pracę do wykonania.
Jeśli firma komunikuje sprawy wrażliwe raz przez intranet, raz przez PDF, raz przez e-mail z linkiem, raz przez zewnętrzny formularz, a raz przez nieformalną wiadomość od przełożonego, sama tworzy przestrzeń, którą phishing może wykorzystać. Pracownik przyzwyczajony do wyjątków trudniej rozpozna kolejny wyjątek, który jest już atakiem.
Dlatego HR i compliance powinny jasno określić, jak wyglądają oficjalne komunikaty w sprawach wrażliwych. Pracownik powinien wiedzieć, czy takie sprawy pojawiają się w portalu HR, w systemie ticketowym, w intranecie, w SharePoint czy przez bezpośredni kontakt z konkretną osobą. Powinien też wiedzieć, czego HR i compliance nie robią nigdy: nie żądają logowania przez losowy link, nie ukrywają sprawy za podejrzaną CAPTCHA i nie wymagają podawania danych w nieznanym formularzu.
To prosta rzecz, ale bardzo podnosi odporność organizacji.
Co firmy powinny zrobić praktycznie
Po pierwsze, HR i compliance powinny jasno określić, jak komunikują sprawy wrażliwe. Jeśli firma używa określonego portalu, systemu ticketowego albo intranetu, pracownicy powinni to wiedzieć. Im więcej nieformalnych wyjątków, tym łatwiej o phishing.
Po drugie, trzeba dopisać scenariusze HR i compliance do programu awareness. W wielu firmach symulacje phishingowe skupiają się na fakturach, paczkach, resetach haseł i Microsoft 365. To za mało. Atakujący coraz częściej używają emocji zawodowych: obawy przed naruszeniem polityki, postępowaniem, skargą albo utratą dostępu.
Po trzecie, organizacje powinny wdrażać phishing-resistant MFA tam, gdzie ryzyko jest najwyższe. NIST wskazuje, że odporność na phishing wymaga metod, których nie da się łatwo przechwycić i odtworzyć przez fałszywy przepływ. W praktyce oznacza to między innymi FIDO2, WebAuthn i passkeys dla kont uprzywilejowanych, osób wysokiego ryzyka oraz dostępu do kluczowych aplikacji.
Po czwarte, po podejrzeniu AiTM nie wystarczy zmiana hasła. Microsoft już przy wcześniejszych kampaniach AiTM podkreślał konieczność unieważniania aktywnych sesji, usuwania podejrzanych reguł skrzynki i cofania zmian w MFA. Jeżeli atakujący przejął token, sama zmiana hasła może nie odciąć dostępu wystarczająco szybko.
Po piąte, trzeba monitorować nietypowe logowania, anomalie tokenów, nowe urządzenia, zmiany MFA, podejrzane reguły inbox i aktywność po kliknięciu. To jest atak na tożsamość, więc obrona musi widzieć więcej niż sam e-mail.
Dlaczego to ważne także w Polsce
Choć opisana przez Microsoft kampania była w większości wymierzona w użytkowników w USA, sam scenariusz jest uniwersalny. Każda firma w Polsce ma regulaminy, polityki, onboarding, szkolenia BHP, RODO, compliance, zgłoszenia wewnętrzne, komunikację HR i procedury wyjaśniające. To są naturalne punkty zaczepienia dla phishingu.
Wiadomość o rzekomym naruszeniu polityki bezpieczeństwa, wezwaniu do zapoznania się z dokumentem HR albo konieczności podpisania aktualizacji regulaminu może wyglądać bardzo wiarygodnie. Szczególnie jeśli firma faktycznie prowadzi dużo komunikacji wewnętrznej przez e-mail.
Dla polskich organizacji wniosek jest więc prosty: nie trzeba czekać, aż taki scenariusz pojawi się lokalnie w identycznej formie. Warto już teraz przygotować pracowników na phishing, który udaje wewnętrzne procesy firmy, a nie tylko znane marki zewnętrzne.
Jak taki scenariusz ćwiczyć w awareness
Dobry test nie powinien polegać wyłącznie na wysłaniu wiadomości z linkiem do fałszywego logowania. Ten scenariusz powinien mierzyć, czy użytkownik rozumie cały proces.
Najlepsza symulacja mogłaby zaczynać się od wiadomości udającej wewnętrzny komunikat HR lub compliance, ale bez przesadnego straszenia. Potem użytkownik trafiałby na stronę pośrednią z informacją o poufnej dokumentacji. W dalszym kroku pojawiałaby się decyzja: zalogować się z linku, przerwać proces, zgłosić wiadomość albo zweryfikować sprawę znanym kanałem.
To mierzy coś znacznie ważniejszego niż klikalność. Mierzy, czy pracownik potrafi zatrzymać się wtedy, gdy wiadomość wygląda profesjonalnie, dotyczy sprawy służbowej i wywołuje presję.
Właśnie taki kierunek ma sens w nowoczesnym programie security awareness. Nie chodzi tylko o rozpoznawanie błędów językowych i podejrzanych domen. Chodzi o zrozumienie, kiedy cały proces zaczyna odbiegać od normalnych zasad firmy.
Jak ćwiczyć odporność na taki scenariusz
Ten przypadek dobrze pokazuje, dlaczego symulacje phishingowe powinny obejmować różne role i różne konteksty. Inaczej reaguje pracownik finansów na fakturę, inaczej administrator social media na blokadę konta Meta, inaczej manager na wiadomość od helpdesku, a jeszcze inaczej zwykły pracownik na informację o sprawie code of conduct.
Dla organizacji wartością nie jest samo sprawdzenie, kto kliknął. Wartością jest odpowiedź na pytania: czy użytkownik przerwał proces po zobaczeniu nietypowej strony, czy zgłosił wiadomość, czy rozumie, że CAPTCHA nie oznacza bezpieczeństwa, czy wie, jak zweryfikować sprawę HR albo compliance, czy organizacja potrafi szybko zareagować po kliknięciu i czy konta wysokiego ryzyka mają mocniejsze mechanizmy ochrony niż zwykłe MFA.
To właśnie w tym miejscu awareness łączy się z realnym zarządzaniem ryzykiem.
Gdy firmowy proces staje się przynętą
Code of conduct phishing pokazuje, że współczesny phishing coraz mniej przypomina stary spam, a coraz bardziej przypomina firmowy proces. Atakujący nie musi pisać wiadomości pełnej błędów ani udawać egzotycznego nadawcy. Może przygotować profesjonalnie wyglądającą sprawę HR, przepuścić użytkownika przez CAPTCHA, stronę pośrednią i finalnie przejąć token sesji po poprawnym logowaniu.
To jest bardzo ważna lekcja dla firm. Jeśli szkolenie nadal uczy głównie tego, żeby nie klikać w podejrzane linki, to nie przygotowuje ludzi na sytuację, w której link wygląda jak element wewnętrznej sprawy służbowej.
W 2026 roku phishing nie atakuje już tylko skrzynki. Atakuje zaufanie do procedur, komunikacji HR, compliance i logowania. Dlatego trzeba ćwiczyć nie tylko kliknięcie, ale cały proces decyzyjny użytkownika.
Jeżeli chcesz sprawdzić, czy Twoi pracownicy rozpoznaliby taki scenariusz zanim zalogują się do fałszywego przepływu, dobrym początkiem jest quiz phishingowy PHISHLY.
Najczęstsze pytania
Czym jest code of conduct phishing?
To phishing podszywający się pod sprawę związaną z firmowym kodeksem postępowania, regulaminem, compliance albo postępowaniem wyjaśniającym. Jego siłą jest presja służbowa, obawa przed konsekwencjami i potrzeba szybkiego wyjaśnienia sprawy.
Czy MFA chroni przed takim atakiem?
MFA pomaga, ale klasyczne metody nie zawsze wystarczają. W modelu AiTM atakujący pośredniczy w logowaniu i może przechwycić token sesji po poprawnym uwierzytelnieniu.
Czym jest token sesji?
Token sesji to cyfrowe potwierdzenie, że użytkownik jest już zalogowany. Jeśli napastnik go przejmie, może uzyskać dostęp do konta bez ponownego wpisywania hasła i kodu MFA.
Dlaczego ten scenariusz jest ważny dla firm?
Bo każda organizacja ma procesy HR, compliance, regulaminy, polityki i wewnętrzne postępowania. Atakujący wykorzystują ten kontekst, żeby phishing wyglądał jak normalna komunikacja firmowa.
Źródła
- Microsoft Security Blog: Breaking the code: Multi-stage code of conduct phishing campaign leads to AiTM token compromise— Główne źródło techniczne opisujące kampanię code of conduct, CAPTCHA, strony pośrednie i przepływ AiTM.
- Microsoft Security Blog: Email threat landscape: Q1 2026 trends and insights— Kontekst wzrostu phishingu opartego na linkach, QR phishingu i CAPTCHA-gated phishing w Q1 2026.
- Microsoft Security Blog: Inside Tycoon2FA: How a leading AiTM phishing kit operated at scale— Kontekst dla ataków AiTM, przejmowania tokenów sesji i ograniczeń klasycznego MFA.
- Microsoft Security Blog: Resurgence of a multi-stage AiTM phishing and BEC campaign abusing SharePoint— Dodatkowy kontekst o wieloetapowych kampaniach AiTM, przejęciu kont i konieczności unieważniania sesji.
- NIST: Phishing Resistance – Protecting the Keys to Your Kingdom— Kontekst dotyczący phishing-resistant MFA i ograniczeń metod podatnych na phishing.