Kontekst incydentu: dlaczego akurat pracownik HR?
Historia incydentu: profil firmy, rola pracownika, moment „zero”
Atak, który uderza w pojedynczego pracownika HR, bardzo rzadko jest przypadkiem. W analizowanym scenariuszu celem była średniej wielkości firma usługowa, działająca w modelu B2B, z kilkuset pracownikami w kilku miastach. Dział HR łączył klasyczną kadrowo-płacówkę z rekrutacją i employer brandingiem. Osoba zaatakowana była starszym specjalistą ds. rekrutacji i kadr – miała dostęp zarówno do systemu rekrutacyjnego, jak i do kluczowych systemów kadrowych.
Moment „zero” nastąpił w trakcie intensywnej rekrutacji na kilka stanowisk technicznych. HR otrzymywał dziennie dziesiątki CV przez różne kanały: formularz na stronie „Kariera”, portale z ogłoszeniami, LinkedIn i skrzynkę e-mail. Właśnie wtedy do skrzynki trafiła wiadomość od „idealnego kandydata” z bardzo dopasowanym do oferty opisem doświadczenia i linkiem do portfolio.
Atakujący nie próbował włamać się przez firewallowe „frontowe drzwi” czy szukać publicznie dostępnych podatnych serwerów. Skupił się na człowieku, który miał naturalny, uzasadniony biznesowo powód, by otwierać obce pliki, klikać w linki i korespondować z nieznajomymi. To właśnie połączenie: intensywnych procesów rekrutacyjnych, szerokich uprawnień HR i rutynowego „przerabiania” kandydatów stworzyło idealne warunki do powodzenia ataku.
Dział HR jako skarbnica wrażliwych danych
Działy HR są często postrzegane jako jednostki pomocnicze: rekrutacja, szkolenia, administracja kadrowa. Z perspektywy atakującego to jednak jedna z najbardziej wartościowych kopalni danych w organizacji. W jednym miejscu zbiegają się informacje, które umożliwiają zarówno kradzież tożsamości, jak i planowanie kolejnych ataków socjotechnicznych.
Typowe zbiory danych, które przechowuje HR, to między innymi:
- Dane osobowe kandydatów i pracowników: imiona, nazwiska, adresy zamieszkania, numery PESEL lub odpowiedników, numery dowodów osobistych i paszportów.
- Dane finansowe: numery rachunków bankowych, informacje o wynagrodzeniach, dodatkach, premiach, zajęciach komorniczych.
- Dane wrażliwe: informacje zdrowotne (zwolnienia lekarskie, orzeczenia o niepełnosprawności), dane o związkach zawodowych, dane o karalności tam, gdzie są przetwarzane.
- Dokumenty prawne: umowy o pracę, aneksy, umowy o zakazie konkurencji, porozumienia rozwiązujące umowę, oświadczenia majątkowe dla określonych stanowisk.
Wyciek takich informacji to nie tylko problem regulacyjny (RODO, krajowe przepisy o ochronie danych osobowych), ale też ogromne ryzyko wtórnych ataków. Na bazie jednego wycieku z HR przestępcy mogą potem prowadzić bardzo wiarygodne kampanie phishingowe, podszywając się pod pracodawcę, bank czy instytucje publiczne. Dla nich to inwestycja w „surowiec”, z którego można budować kolejne scenariusze nadużyć.
Uprawnienia HR jako punkt wyjścia do dalszej penetracji
Naturalną konsekwencją zakresu zadań HR są stosunkowo szerokie uprawnienia. Pracownicy kadrowo-płacowi i rekruterzy często mają dostęp do:
- systemów kadrowo-płacowych (HRM/HRIS),
- wspólnych dysków działowych z umowami, skanami dokumentów, raportami,
- poczty grupowej HR (np. kadry@, rekrutacja@),
- systemów benefitowych z integracją SSO,
- wewnętrznych baz wiedzy, instrukcji i procedur.
Jeśli atakujący przejmie konto pracownika HR, uzyskuje od razu zestaw narzędzi: dostęp do danych osobowych, list mailingowych, kontaktów menedżerów, struktury organizacyjnej. To pozwala planować dalszy lateral movement – przesuwanie się w głąb infrastruktury: do działu finansów, do zarządu, do systemów produkcyjnych.
Przykład: z przejętej skrzynki HR można wysłać do działu finansów prośbę o pilne potwierdzenie listy wynagrodzeń w nowym „bezpiecznym systemie”, który w rzeczywistości jest fałszywą stroną logowania. Dla księgowości taki mail z HR, w okresie zamykania miesiąca, wygląda całkowicie naturalnie.
Jak atakujący typuje ofiarę: LinkedIn, ogłoszenia, zakładka „Kariera”
Profilowanie ofiary w omawianym incydencie zaczęło się od publicznie dostępnych źródeł. Atakujący nie musiał łamać żadnych zabezpieczeń, by ustalić, kto będzie kluczowym celem. Wykorzystał to, co firma sama o sobie publikowała:
- LinkedIn – profile pracowników HR, informacje o ich stanowisku, odpowiedzialności, certyfikatach. Często pojawiają się tam posty typu „rekrutuję na stanowisko X – zgłoś się do mnie bezpośrednio”.
- Ogłoszenia o pracę – nazwy narzędzi rekrutacyjnych (ATS), szczegóły procesu rekrutacyjnego („zadanie techniczne w kolejnym etapie”), wskazanie osoby kontaktowej i jej adresu e-mail.
- Zakładka „Kariera” na stronie firmy – opis wartości, technologii, nazwy działów, niekiedy nawet schematy organizacyjne oraz maile rekrutacyjne typu recruitment@firma.pl.
Na tej podstawie przestępca stworzył mapę: kto prowadzi rekrutację na konkretne stanowisko, jaki ma e-mail, jakim ATS-em posługuje się firma, jakie narzędzia chmurowe są w użyciu (np. dedykowane platformy do zadań testowych). Im więcej takich okruchów informacji, tym łatwiej zbudować bardzo wiarygodny scenariusz kontaktu.
Działy HR zwykle nie myślą o sobie jako o „high value target”. Analiza incydentu szybko uświadomiła zarządowi, że HR jest w praktyce jednym z kluczowych elementów bezpieczeństwa informacji, a nie „miękkim” działem pomocniczym. To zmiana optyki, która potrafi zdecydować o tym, czy firma potraktuje ochronę HR serio, czy uzna ją za kolejne „miłe szkolenie z RODO”.
Jak rodzi się incydent: profilowanie i przygotowanie ataku
Analiza cyfrowego śladu pracownika HR
Atakujący rozpoczął przygotowania od szczegółowej analizy cyfrowego śladu głównej ofiary – rekrutera/kadrowca. Profil na LinkedIn ujawniał nie tylko historię zatrudnienia, lecz także:
- informacje o prowadzonych projektach rekrutacyjnych,
- udział w konferencjach HR-owych i webinariach,
- posty typu „szukam backend developera, stos technologiczny: X, Y, Z”.
Do tego dochodziły nagrania z webinarów, gdzie pracownik HR opowiadał o procesach rekrutacyjnych, stosowanych narzędziach, kulturze pracy. Nawet jeśli nie padały tam „sekrety techniczne”, dla przestępcy była to skarbnica wiedzy: słownictwo, którym posługuje się HR, typowa narracja, nazwy wykorzystywanych systemów. Wszystko to pozwalało później napisać e-mail, który brzmiał jak wiadomość od realnego kandydata, znającego specyfikę firmy i rynku.
Kolejnym elementem były ślady na innych portalach społecznościowych: krótkie wzmianki o nadmiarze pracy, „sezonie rekrutacyjnym”, deadlinach. Taki kontekst pomaga dopasować moment ataku – uderzyć w okresie, gdy HR jest najbardziej obciążony, więc najmniej uważny.
Jak ogłoszenia o pracę zdradzają strukturę i procesy
Treść ogłoszeń o pracę może ujawniać znacznie więcej, niż zakłada autor. Analiza ofert publikowanych przez firmę pokazała:
- używany system ATS (często wspomniany w sekcji „Jak wygląda proces rekrutacyjny”),
- liczbę etapów rekrutacji i ich formę (zadanie domowe, test online, case study w chmurze),
- formę kontaktu („preferujemy kontakt mailowy, nie dzwonimy do kandydatów przed pierwszym etapem”),
- strukturę odpowiedzialności („za proces odpowiada zespół Talent Acquisition, a za finalną decyzję – Head of Development”).
Z punktu widzenia atakującego to gotowe instrukcje: wiadomo, jakimi narzędziami HR obsługuje kandydatów, jakich treści może się spodziewać, jak wygląda język komunikacji. To ułatwia tworzenie legendy kandydata, który „idealnie” wpisuje się w proces: np. przesyła zadanie domowe w formacie wskazanym w ogłoszeniu i odwołuje się do nazwy narzędzia, które firma rzekomo używa.
Przykład: jeśli ogłoszenie wspomina, że kandydat w kolejnym etapie dostanie link do platformy z zadaniem technicznym, przestępca może wysłać taki link z wyprzedzeniem, podszywając się pod „zautomatyzowaną wiadomość systemu”. HR uzna to za normalny element procesu.
Tworzenie legendy: idealny kandydat, dostawca benefitów, audytor
Na bazie zebranych informacji atakujący tworzy konkretną rolę, w którą się wcieli. W omawianym incydencie były rozważane trzy warianty:
- „Idealny kandydat” – osoba z doświadczeniem bardzo spójnym z opisem stanowiska, referencjami z rozpoznawalnych firm, gotowym portfolio w chmurze.
- „Dostawca benefitów” – przedstawiciel firmy oferującej program benefitowy, znającej realia rynku HR, z propozycją „bezpłatnego audytu” lub „pilotażowego programu”.
- „Audytor BHP / audytor RODO” – ktoś, kto powołuje się na zmiany w przepisach i konieczność szybkiego uzupełnienia dokumentacji.
Każda z tych legend jest wiarygodna dla HR. W wybranym scenariuszu przestępca poszedł w kierunku „idealnego kandydata”, bo firma aktywnie rekrutowała i oczekiwała napływu aplikacji. E-mail był napisany naturalnym, branżowym językiem, zawierał odniesienie do konkretnych fraz z ogłoszenia, a link do portfolio prowadził do profesjonalnie wyglądającej strony imitującej znaną usługę chmurową.
Ta staranność w przygotowaniu przekazu sprawiła, że „czerwone flagi” były słabo widoczne. Dla rekrutera, który przez cały dzień przegląda CV, to po prostu kolejna, trochę lepiej niż zwykle przygotowana aplikacja.
Przykładowy e-mail kandydata z ukrytym złośliwym ładunkiem
Wiadomość, która zapoczątkowała incydent, wyglądała mniej więcej tak (skrócony, zanonimizowany przykład):
„Dzień dobry,
z dużym zainteresowaniem przeczytałem ogłoszenie na stanowisko Senior Backend Developer w Państwa firmie. Szczególnie zaciekawił mnie stos technologiczny (Java, Spring, Docker) oraz informacja o pracy w zespole produktowym, a nie w typowym „software house”.
Od 6 lat pracuję jako Backend Developer, w tym 3 lata na stanowisku Senior w firmie [rozpoznawalna nazwa]. Prowadziłem projekty dla klientów z branży finansowej i retail. Załączam CV w formacie PDF oraz link do krótkiego portfolio z opisem najważniejszych projektów: [link].
Z poważaniem,
Imię i nazwisko
Do wiadomości dołączony był plik PDF o nazwie „CV_Imię_Nazwisko.pdf” oraz link rzekomo prowadzący do katalogu w popularnym dysku chmurowym. W rzeczywistości link kierował do strony przygotowanej przez atakującego, która instalowała złośliwe oprogramowanie po otwarciu lub wymuszała zalogowanie się przez „konto firmowe” w celu rzekomego pobrania pliku.
Im lepiej HR rozumie mechanikę takich przygotowań, tym łatwiej wprowadzić zasadę: „im mniej detali operacyjnych ujawniamy publicznie, tym trudniej o skuteczne profilowanie”. Część informacji można podawać kandydatom dopiero na późniejszych etapach procesu, zamiast eksponować je w każdej ofercie i prezentacji.
Dzień ataku: pierwsze wektory i przełamanie „pierwszej linii”
Pierwszy kontakt: e-mail, LinkedIn i formularz na stronie
Incydent rozpoczął się od klasycznego kontaktu mailowego, ale analiza logów pokazała, że atakujący testował wcześniej inne kanały. Tydzień przed kluczowym mailem do skrzynki rekrutacja@ trafiło kilka wiadomości z prostymi załącznikami DOCX – prawdopodobnie „rozpoznanie bojem”, by sprawdzić, czy systemy bezpieczeństwa zablokują pliki z makrami.
Równolegle na LinkedIn wysłano InMail do tego samego rekrutera z krótką wiadomością: „Dzień dobry, czy mogę przesłać Pani/Panu bezpośrednio CV na stanowisko X? Chciałbym dopytać o szczegóły.” Taki kontakt miał dwa cele: potwierdzić, że konto jest aktywne, oraz skłonić HR do oczekiwania kolejnej wiadomości mailowej od tego samego „kandydata”.
Formularz na stronie „Kariera” został również przetestowany jednym zgłoszeniem z linkiem do portfolio. Brak reakcji automatycznych filtrów i brak zgłoszeń od IT sugerował atakującemu, że ten kanał też jest potencjalnie podatny. Ostatecznie wybrał jednak klasycznego maila, bo dawał większą kontrolę nad treścią, nagłówkami i załącznikami.
Dlaczego wiadomość wyglądała całkowicie normalnie
Z punktu widzenia pracownika HR wiadomość nie różniła się od dziesiątek innych. Analiza incydentu wykazała kilka czynników, które zwiększyły jej „normalność”:
- Branżowy język – odwołania do stosu technologicznego, kultury pracy i wartości firmy, zaczerpnięte bezpośrednio z ogłoszenia.
Subtelne sygnały, które zostały zignorowane
Po analizie incydentu okazało się, że jednak pojawiły się drobne sygnały ostrzegawcze – takie, które w spokojny dzień mogłyby wywołać czujność, ale w „sezonie rekrutacyjnym” po prostu zniknęły w tle:
- adres nadawcy różnił się jednym znakiem od domeny znanej firmy, na którą powoływał się „kandydat”,
- nagłówek „Reply-To” wskazywał na inną domenę niż „From”,
- link do portfolio prowadził do domeny łudząco podobnej do znanego dostawcy chmury, ale z inną końcówką krajową,
- e-mail został dostarczony poza standardowymi godzinami, a odpowiedź „kandydata” na automatyczne potwierdzenie spłynęła niemal natychmiast (typowy automat lub „czat” po stronie atakującego).
To nie były oczywiste, czerwone alerty, tylko drobne rysy na obrazie. Bez narzędzi, które wizualnie podświetlają takie różnice, HR musiałby je wyłapać „gołym okiem”. Gdy skrzynka „płonie” od wiadomości, taka czujność jest iluzją. Dlatego opłaca się łączyć świadomość użytkownika z technicznymi „paskami ostrzegawczymi”, które przejmą część pracy za człowieka.
Dobrym nawykiem jest prosta pauza: przed kliknięciem w link zatrzymać się na 3 sekundy i zerknąć na pasku statusu, dokąd faktycznie prowadzi adres. To niewielka zmiana, ale przy codziennej pracy z aplikacjami może realnie obniżyć ryzyko.
Jak systemy bezpieczeństwa „przepuściły” atak
Naturalne pytanie, które padło po incydencie: dlaczego ochrona nie zatrzymała tego e-maila? Analiza techniczna pokazała kilka elementów:
- Brak znanego sygnaturą malware – złośliwy ładunek był świeży, jeszcze nieopisany w popularnych bazach, więc klasyczne skanery antywirusowe nie reagowały.
- Rozproszenie ładunku – sam PDF był „czysty”, a właściwy atak odbywał się dopiero po wejściu na stronę i przejściu przez fałszywy formularz logowania.
- Zaufanie do kategorii treści – system filtrujący miał poluzowane reguły dla wiadomości z działu rekrutacji („żeby nie blokować aplikacji kandydatów”), co obniżało czułość detekcji.
- Brak izolacji przeglądarki – kliknięcie w link otwierało stronę bez żadnej piaskownicy czy mechanizmu „otwórz podejrzaną stronę w bezpiecznym kontenerze”.
Innymi słowy, technologia zrobiła to, do czego została skonfigurowana: nie przeszkadzała HR w pracy. Dopiero incydent uświadomił, że „nieprzeszkadzanie” nie może być jedynym kryterium, a procesy HR muszą mieć równie wysoki poziom ochrony jak działy finansowe czy IT.
Jeśli chcesz, by zabezpieczenia naprawdę działały, potraktuj HR jak krytyczną funkcję, a nie „miękki” punkt, którego nie można „zadręczać” dodatkowymi kontrolami.

Chwila nieuwagi: co zrobił pracownik HR i gdzie pojawił się błąd
Kliknięcie w link i „standardowa” próba zalogowania
Pracownik HR otworzył maila, przejrzał treść, sprawdził załączony PDF. Plik wyglądał poprawnie: zawierał zanonimizowane dane, sekcje „Doświadczenie”, „Umiejętności”, „Wykształcenie”. Nic nie wskazywało na problem. Chęć „zobaczenia więcej” popchnęła go do kliknięcia w link do portfolio.
Strona otworzyła się w przeglądarce, wyglądając jak dobrze znany panel logowania do popularnej usługi chmurowej. Logo, kolory, responsywny układ – wszystko wyglądało profesjonalnie. Pojawił się komunikat: „Aby uzyskać dostęp do udostępnionego katalogu, zaloguj się kontem firmowym”.
To był kluczowy moment. Rekruter, przyzwyczajony do korzystania z narzędzi w chmurze, bezrefleksyjnie wpisał swoje dane logowania domenowego: adres służbowy i hasło. Dopiero po drugim, „dziwnie długim” ładowaniu strony pojawił się błąd, a użytkownik zignorował go jako „typowe problemy z internetem”. Spróbował raz jeszcze, uznał, że „coś nie działa” i odłożył sprawę na później.
Tak naprawdę w tym momencie przestępca miał już pełne poświadczenia do konta domenowego HR, a próba ponownego logowania jedynie potwierdziła mu, że hasło jest poprawne.
Mechanizm „mikroutwardzenia” bezpieczeństwa, który zawiódł
W firmie obowiązywała prosta zasada: „nie podawaj hasła po kliknięciu w link z maila, zawsze wpisuj ręcznie adres systemu w przeglądarce”. Na szkoleniu brzmiało to logicznie, ale w praktyce było trudne do utrzymania. Główne problemy wyszły na jaw po incydencie:
- systemy chmurowe same w sobie często wysyłały linki do logowania (np. reset hasła, zaproszenia do folderów współdzielonych),
- HR codziennie pracował na kilku różnych linkach do tych samych aplikacji (platforma benefitowa, ATS, ankiety pracownicze),
- procedura „wpisz ręcznie adres” była postrzegana jako nieżyciowa przy dużej liczbie krótkich zadań.
W efekcie „zasada bezpieczeństwa” żyła głównie w dokumentach i prezentacjach, a nie w realnym zachowaniu. Atakujący idealnie wpasował się w istniejący, wygodny nawyk – klikania w link i logowania „po drodze”.
Szybka, praktyczna zmiana po incydencie? Wprowadzenie prostego zestawu: menedżer haseł z automatycznym uzupełnianiem tylko na zdefiniowanych domenach oraz wylogowanie automatyczne po określonym czasie bezczynności. Dzięki temu, gdy login pojawia się na „obcej” stronie, menedżer haseł po prostu milczy – i to jest konkretny, widoczny sygnał.
Jak presja czasu wyłączyła krytyczne myślenie
W rozmowach po incydencie rekruter opisywał ten dzień jednym zdaniem: „był totalny młyn”. Nowe ogłoszenie, kilkanaście maili od kandydatów, spotkania rekrutacyjne, pilne prośby managerów „o przyspieszenie procesu”. W takim środowisku każde dodatkowe kliknięcie, każdy eksperyment z „dziwnie wyglądającą stroną” jest automatycznie klasyfikowany jako przeszkoda, a nie sygnał alarmowy.
To ważna lekcja: nawet najlepiej przeszkolona osoba, pod stałą presją czasu, ma ograniczone zasoby uwagi. Procedury bezpieczeństwa muszą być zaprojektowane tak, by:
- nie wymagały skomplikowanych decyzji w krytycznych momentach,
- maksymalnie wykorzystywały automatyzm narzędzi,
- hamowały najgroźniejsze działania (np. wprowadzenie hasła domenowego) prostą blokadą lub dodatkowym komunikatem.
Warto wprowadzać krótkie, realne ćwiczenia z symulacją presji – lepiej popełnić błąd na „sucho”, niż w realnym incydencie.
Co ujawniła analiza techniczna: od infekcji do lateral movement
Przejęcie konta i pierwsze ruchy w sieci
Po zdobyciu poświadczeń przestępca nie rzucił się od razu na „skarbce danych”. Pierwszym krokiem było dyskretne zalogowanie się na konto pracownika HR przez VPN, imitując typowe godziny pracy. Logi pokazały, że:
- logowanie nastąpiło z nietypowej lokalizacji geograficznej, ale z adresu IP należącego do popularnego dostawcy VPN (domyślnie traktowanego jako „bezpieczny”),
- w ciągu kilku minut otwarto skrzynkę mailową i katalogi współdzielone z działem HR,
- następnie rozpoczęto „ciche” przeszukiwanie tematów i załączników w poszukiwaniu słów kluczowych (np. „umowa”, „lista”, „wynagrodzenie”, „PESEL”).
Ten etap trwał kilka godzin dziennie przez kilka kolejnych dni. Dla systemów bezpieczeństwa aktywność wyglądała jak zwykła praca użytkownika, tyle że „trochę bardziej intensywna”.
Dla przestępcy to był faza rozpoznania wewnętrznego – zrozumienie, gdzie leżą naprawdę wartościowe dane i jakie systemy trzeba będzie później zaatakować.
Wykorzystanie uprawnień HR do eskalacji dostępu
Konto pracownika HR miało więcej uprawnień, niż wynikałoby to z jego faktycznych obowiązków. Był to klasyczny efekt „tymczasowych” dostępów nadanych kiedyś „na szybko”, gdy trzeba było przejrzeć raporty, eksporty z systemu kadrowego czy listy płac.
Przestępca szybko to zauważył. Analiza logów pokazała następującą sekwencję:
- wejście do katalogu z eksportami z systemu kadrowego (pliki CSV/XLS z danymi pracowników),
- odkrycie arkusza z listą kont w systemach wewnętrznych, przygotowanego kiedyś przez HR wspólnie z IT (np. do audytu dostępów),
- wykorzystanie znalezionych tam informacji o strukturze ról i działów do dalszego planowania.
Na tym etapie nie doszło jeszcze do przejęcia kont innych użytkowników, ale przestępca zdobył mapę: kto ma dostęp do jakich systemów, jakie istnieją poziomy uprawnień, które działy są „bramą” do systemów finansowych czy produkcyjnych.
To cenne przypomnienie, że „niewinne” arkusze Excel z podsumowaniami dostępów lub strukturą kont są dla napastnika jak instrukcja obsługi całej organizacji.
Instalacja narzędzi zdalnego dostępu i unikanie detekcji
Równolegle z eksploracją danych napastnik zainstalował na stacji roboczej HR lekki agent zdalnego dostępu. Był on przebrany za popularne narzędzie do współpracy (nazwa i ikona nawiązywały do znanego komunikatora). Instalacja odbyła się poprzez wykorzystanie luk w konfiguracji przeglądarki i braku aktualizacji jednego z pluginów.
Agent komunikował się z serwerem C2 (command and control) w sposób trudny do odróżnienia od zwykłego ruchu HTTPS. Długość sesji, częstotliwość połączeń, nawet rozmiary pakietów – wszystko zostało dopasowane do statystycznych parametrów komunikacji typowego narzędzia biurowego.
Dzięki temu przestępca nie był już ograniczony do działań w przeglądarce. Mógł:
- podsłuchiwać ruch lokalny w sieci biurowej,
- mapować udziały sieciowe widoczne z perspektywy komputera HR,
- próbować automatycznego logowania do innych systemów za pomocą zapamiętanych poświadczeń w przeglądarce.
Tu zadziałał kolejny, często lekceważony mechanizm: przeglądarka przechowywała zapamiętane loginy do kilku wewnętrznych aplikacji. Część z nich była chroniona tylko hasłem, bez dodatkowego MFA. To otworzyło drogę do lateral movement.
Lateral movement: przejście z HR do innych systemów
Lateral movement to moment, w którym atak wychodzi poza początkowo zainfekowane konto lub stację roboczą. W tym incydencie przebiegał on etapami:
- Przejście do systemu ticketowego – dzięki zapamiętanemu loginowi w przeglądarce przestępca zalogował się do narzędzia służącego do obsługi zgłoszeń wewnętrznych.
- Podgląd zgłoszeń IT – wśród ticketów znalazły się opisy zmian kont, resetów haseł, konfiguracji VPN. To dało dodatkową wiedzę o infrastrukturze i zwyczajach działu IT.
- Podszycie się pod HR w korespondencji z IT – z przejętego maila wysłano jedno „niewinne” zgłoszenie o nadanie tymczasowego dostępu do raportów finansowych „na potrzeby audytu benefitów”.
- Uzyskanie dostępu do folderu z raportami – IT, nie widząc niczego podejrzanego (zgłoszenie z właściwej skrzynki, poprawny ton, zgodność z wcześniejszymi zadaniami HR), przyznało ograniczony dostęp.
Tak przestępca, startując z działu HR, docierał krok po kroku do systemów związanych z finansami i raportowaniem. Nie potrzebował przejmować kont administratorów – wystarczyło wykorzystać naturalny łańcuch współpracy między działami.
Dobra wiadomość jest taka, że każdy taki krok zostawia ślady. Jeśli firma gromadzi i analizuje logi z wielu systemów, anomalie – jak nagły wzrost aktywności HR w folderach finansowych – można wykryć relatywnie szybko.
Moment wykrycia i odcięcie ataku
Incydent został ostatecznie wykryty nie przez system antywirusowy, ale przez mechanizm UEBA (User and Entity Behavior Analytics). Narzędzie zauważyło, że:
- konto HR, które zwykle logowało się z jednego kraju, nagle wykazuje logowania z dwóch odległych lokalizacji w krótkim odstępie czasu,
- z tego konta wykonywane są działania nietypowe dla roli HR (przeglądanie raportów finansowych o określonych godzinach),
- liczba pobranych plików w krótkim oknie czasowym znacząco odbiega od normy.
System nadał wysoką ocenę ryzyka, co wywołało alert dla zespołu bezpieczeństwa. Zareagowano w klasyczny sposób: tymczasowe zablokowanie konta, odłączenie stacji roboczej od sieci, wymuszenie resetu haseł i przegląd ostatnich działań zalogowanego użytkownika.
Wymiar biznesowy: jakie dane wyciekły i jakie były skutki
Jakie dane faktycznie opuściły organizację
Analiza incydentu pokazała, że celem nie były „tajne algorytmy” czy własność intelektualna, ale bardzo konkretne, wrażliwe informacje o ludziach i strukturze firmy. Zidentyfikowano kilka głównych kategorii danych, które zostały pobrane lub przynajmniej otwarte przez przejęte konto HR:
- dane osobowe pracowników – imiona, nazwiska, adresy, numery PESEL, numery dokumentów tożsamości, dane kontaktowe,
- dane kadrowo‑płacowe – wysokość wynagrodzeń zasadniczych, premie, dodatki, historia zmian płac,
- dane rekrutacyjne kandydatów – CV, listy motywacyjne, przebieg dotychczasowego zatrudnienia, informacje o wypowiedzeniach,
- informacje o strukturze organizacyjnej – listy stanowisk, raportowanie służbowe, przypisanie do projektów,
- fragmenty danych dostępowych – nazwy użytkowników, identyfikatory ról, opisy poziomów uprawnień (bez pełnych haseł, ale z dużą wartością kontekstową).
Co ważne, nie wszystkie pliki zostały fizycznie skopiowane na zewnątrz. Samo ich otwarcie i przeglądanie przez napastnika stanowiło jednak naruszenie poufności. W części przypadków dopiero korelacja logów z serwera plików, VPN i systemu DLP pozwoliła odróżnić zwykłe „podglądanie” od faktycznego wypływu danych.
To dobry moment, aby przestać myśleć o „wycieku” wyłącznie jako o masowym zgraniu terabajtów plików. Czasem kilka arkuszy z danymi kluczowych osób w firmie jest dla atakującego znacznie cenniejsze niż cały serwer dokumentów.
Konsekwencje dla pracowników i kandydatów
W HR każda wpadka uderza najpierw w zaufanie ludzi. Tutaj skutki były bardzo namacalne. Po incydencie trzeba było:
- poinformować pracowników o potencjalnym ujawnieniu ich danych,
- powiadomić osoby, które brały udział w procesach rekrutacyjnych w ostatnich miesiącach,
- przygotować jasną instrukcję, jak reagować na możliwe próby wyłudzeń, podszywanie się czy fałszywe oferty pracy.
Dlaczego to tak dotkliwe? Bo w plikach HR znajdują się informacje, których ludzie nie spodziewają się „na ulicy”: szczegóły wynagrodzeń, powody odejść z poprzednich firm, czasem fragmenty korespondencji dotyczącej trudnych sytuacji (konfliktów, obniżenia wyników, problemów zdrowotnych). Nawet jeśli dane medyczne nie zostały formalnie naruszone, sam kontekst bywa delikatny.
W praktyce oznacza to rosnące ryzyko:
- ataków phishingowych celowanych – np. wiadomości do konkretnych menedżerów i specjalistów z odniesieniem do ich stanowiska i wynagrodzenia,
- szantażu lub nękania – groźby ujawnienia informacji o zarobkach lub komentarzy z procesów oceny okresowej,
- podszywania się pod rekrutera – wykorzystywanie realnych nazwisk i nazw rekrutacji, by uwiarygodnić oszustwo.
Firmy, które dobrze przepracowują taki incydent, nie ograniczają się do jednorazowego maila. Wprowadzają cykliczne przypomnienia, krótkie webinary dla pracowników i kandydatów oraz dedykowany adres kontaktowy do zgłaszania podejrzanych sytuacji. To konkretna inwestycja w odbudowę zaufania.
Obowiązki prawne i regulator: co trzeba było zgłosić
Skala i charakter danych sprawiły, że incydent nie mógł „zostać w firmie”. Z perspektywy RODO był to klasyczny przypadek naruszenia ochrony danych osobowych, wymagający formalnej reakcji. W praktyce oznaczało to kilka kroków pod presją czasu:
- Ocena ryzyka dla osób, których dane dotyczą – szybkie, ale solidne oszacowanie, czy wyciek może prowadzić do naruszenia praw i wolności (np. kradzież tożsamości, dyskryminacja, szkody reputacyjne).
- Zgłoszenie do organu nadzorczego – w ustawowym terminie, z możliwie szczegółowym opisem zdarzenia, podjętych środków i planu naprawczego.
- Powiadomienie osób, których dane dotyczyły incydentu – jasne, zrozumiałe komunikaty zamiast żargonu technicznego i prawniczego.
Organ nadzorczy zwykle zwraca uwagę na dwie rzeczy: czy firma miała adekwatne środki bezpieczeństwa przed incydentem oraz jak szybko i skutecznie zadziałała po wykryciu. Brak reakcji lub próba zamiatania sprawy pod dywan często kosztuje więcej niż sama luka techniczna.
Dobrą praktyką jest przygotowanie z wyprzedzeniem szablonów zgłoszeń i procedury współpracy między HR, prawnym, IT i security. Wtedy w momencie kryzysu zespół nie traci godzin na ustalanie „kto właściwie ma to podpisać” – tylko robi to, co trzeba.
Ryzyka finansowe: koszty bezpośrednie i ukryte
Bezpośrednie koszty incydentu zwykle są dość przewidywalne: praca zespołów, narzędzia, zewnętrzni konsultanci, ewentualne kary administracyjne. W tym przypadku lista wydatków objęła m.in.:
- wdrożenie i konfigurację dodatkowych narzędzi bezpieczeństwa (rozszerzenie UEBA, DLP),
- audyt powłamaniowy wykonany przez zewnętrzną firmę,
- kampanię informacyjną dla pracowników i kandydatów (w tym tłumaczenia, infolinię),
- przyspieszoną wymianę części sprzętu i licencji.
Znacznie trudniej policzyć koszty pośrednie. Tu pojawiają się m.in.:
- utrata produktywności – zamrożone systemy, ograniczenia w dostępie do danych HR, opóźnienia w wypłatach premii i rozliczeniach,
- wydłużone procesy rekrutacyjne – część kandydatów rezygnuje, słysząc o incydencie, trzeba intensywniej budować zaufanie,
- dodatkowe obciążenie HR – pytania pracowników, mediacje z menedżerami, wsparcie psychologiczne dla zespołu dotkniętego incydentem.
W wielu firmach dopiero taki incydent pokazuje, jak bardzo procesy kadrowe są „krytyczne dla biznesu”. Bez sprawnie działającego HR zatrzymuje się rekrutacja, płace, część rozliczeń z partnerami. To konkretny argument, aby inwestycje w bezpieczeństwo HR traktować jak inwestycje w ciągłość działania, a nie „opcjonalny dodatek”.
Uderzenie w reputację i markę pracodawcy
Firmy dużo inwestują w employer branding: ładne kampanie, obietnice kultury zaufania, programy well‑being. W chwili incydentu bezpieczeństwa w HR ta komunikacja zostaje od razu zweryfikowana w praktyce.
Skutki wizerunkowe można było jak zwykle zaobserwować w kilku miejscach:
- portale z opiniami o pracodawcach – pojawiły się komentarze byłych i obecnych pracowników o braku dbałości o dane,
- media społecznościowe – dyskusje kandydatów, dzielenie się informacjami o incydencie, pytania do rekruterów na LinkedIn,
- rynek rekrutacyjny – część kandydatów dopytywała podczas rozmów, jak firma zamierza chronić ich CV i dokumenty.
Nie chodzi tylko o „wstyd”, ale o realną przewagę lub stratę konkurencyjną. W branżach, gdzie walczy się o specjalistów, informacja o słabym bezpieczeństwie HR może być powodem, by wybrać innego pracodawcę. Z drugiej strony przejrzyste, dojrzałe zarządzanie incydentem potrafi zadziałać jak plus: ludzie widzą, że firma nie ucieka od trudnych tematów.
Dlatego w planie reagowania na incydenty powinno być miejsce na współpracę z zespołem employer brandingu i komunikacji. To oni pomagają przełożyć techniczne i prawne fakty na język, który buduje, a nie niszczy zaufanie.
Dlaczego HR stał się strategicznym celem – perspektywa „po burzy”
Po opadnięciu emocji i zakończeniu działań technicznych można było odpowiedzieć wreszcie na kluczowe pytanie: dlaczego napastnik wybrał akurat HR, a nie dział IT, sprzedaży czy finansów. Analiza pokazała zestaw czynników, które – niestety – często występują również w innych organizacjach:
- Dane o całej organizacji w jednym miejscu – HR widzi przekrój przez wszystkie działy, stanowiska, wynagrodzenia i struktury. To dla atakującego „atlas” firmy.
- Wielu zewnętrznych rozmówców – kandydaci, agencje rekrutacyjne, konsultanci, dostawcy benefitów. To otwiera wiele dróg do socjotechniki.
- Stała presja terminów – rekrutacje, rozliczenia, wdrożenia nowych pracowników. Mało czasu na weryfikowanie sygnałów ostrzegawczych.
- Rozbudowana wymiana dokumentów – CV, umowy, aneksy, zaświadczenia. Masa plików, linków, załączników, często z zewnątrz.
To nie jest wyrok na HR, ale bardzo jasny sygnał: ten dział musi być traktowany na równi z finansami czy IT, jeśli chodzi o ochronę. Nie „miękkie zaplecze”, lecz strategiczny węzeł informacji o ludziach i strukturze.
Jeśli chcesz realnie zwiększyć odporność organizacji, świetnym punktem startu jest wspólna sesja HR, IT i bezpieczeństwa: przejście krok po kroku przez typowy dzień pracy rekrutera czy specjalisty ds. kadr i narysowanie, gdzie dokładnie pojawiają się punkty styku z ryzykiem.
Przemyślenie procesów HR: od „papierologii” do odporności
Incydent zmusił firmę do spojrzenia na procesy HR nie tylko jako na sekwencję kroków „od ogłoszenia do zatrudnienia”, lecz jako na łańcuch potencjalnych wektorów ataku. W praktyce wyszło na jaw kilka luk organizacyjnych:
- brak jasnych zasad, jak i gdzie przechowywać dane kandydatów po zakończeniu rekrutacji,
- przyzwolenie na przesyłanie umów i skanów dokumentów prywatnymi skrzynkami, „bo szybciej”,
- „tymczasowe” dostępy do systemów, które nigdy nie były systematycznie odbierane,
- brak jednolitego standardu nadawania dostępów do raportów kadrowo‑płacowych.
To wszystko przełożyło się na plan uporządkowania procesów. Najbardziej efektywne okazały się zmiany, które łączyły prostotę z jasnym komunikatem dla użytkownika, np.:
- centralne repozytorium danych rekrutacyjnych z automatycznymi politykami retencji (np. automatyczne usuwanie po określonym czasie bez dodatkowych „ręcznych” decyzji),
- zablokowanie możliwości wysyłania wrażliwych dokumentów HR poza zdefiniowane domeny, z czytelnym komunikatem „dlaczego” dla użytkownika,
- cykliczny przegląd dostępów do systemów kadrowych i raportowych, prowadzony wspólnie przez HR i IT.
Z punktu widzenia ludzi kluczowe jest, by te zmiany nie były postrzegane jako „kolejna papierologia”. Gdy rekruter widzi, że nowe narzędzie realnie oszczędza czas (np. automatycznie usuwa stare dane i przypomina o kończących się zgodach), jest dużo większa szansa, że będzie z niego korzystał z przekonaniem, a nie z przymusu.
Jeśli chcesz wygrać z podobnym ryzykiem u siebie, wybierz jeden proces HR (np. rekrutację specjalistów) i wypisz wszystkie miejsca, w których pojawia się wymiana plików i danych – już sama ta mapa pokaże, gdzie warto wprowadzić małe, ale skuteczne zabezpieczenia.
Najczęściej zadawane pytania (FAQ)
Dlaczego pracownicy HR są tak atrakcyjnym celem ataków cybernetycznych?
Pracownicy HR mają codzienny, uzasadniony biznesowo powód, żeby otwierać obce pliki, klikać w linki i odpowiadać na wiadomości od nieznanych osób. To dla atakującego idealne środowisko: może udawać kandydata, dostawcę szkoleń czy partnera HR i w ten sposób „wnosi” złośliwy plik lub link prosto na służbowy komputer.
Dodatkowo HR często dysponuje szerokimi uprawnieniami do systemów kadrowych, skrzynek grupowych oraz współdzielonych dysków. Przejęcie jednego konta HR otwiera drogę do danych osobowych, list mailingowych, kontaktów menedżerów i struktury organizacyjnej. To doskonały punkt startowy do kolejnych ruchów w sieci firmy.
Jeśli pracujesz w HR – traktuj się jak „high value target” i żądaj od firmy odpowiednio wysokiego poziomu ochrony.
Jakie dane dział HR przechowuje i co może wyciec w wyniku ataku?
W jednym miejscu kumulują się informacje o kandydatach i pracownikach, których próżno szukać w innych działach. To nie tylko podstawowe dane osobowe, ale też szczegóły życia zawodowego i prywatnego, które dla przestępcy są jak mapa skarbów.
Typowe zbiory danych w HR obejmują m.in.:
- dane identyfikacyjne: imię, nazwisko, adres, PESEL, numery dokumentów,
- dane finansowe: numery kont, informacje o wynagrodzeniach, dodatkach, zajęciach komorniczych,
- dane wrażliwe: informacje zdrowotne, orzeczenia o niepełnosprawności, dane o związkach zawodowych czy karalności,
- dokumenty prawne: umowy, aneksy, NCA, porozumienia rozwiązujące umowę.
Wyciek takich danych to nie tylko kary z RODO – to paliwo do wtórnych oszustw, np. bardzo wiarygodnego phishingu podszywającego się pod pracodawcę czy bank. Zadbaj, by dostęp do tych zbiorów był naprawdę ograniczony i kontrolowany.
Jak wygląda typowy atak na pracownika HR krok po kroku?
Atak rzadko jest przypadkowy. Najpierw przestępca zbiera informacje: analizuje profile HR na LinkedIn, ogłoszenia o pracę, zakładkę „Kariera”, nagrania z webinarów. Na tej podstawie poznaje stos technologiczny, używane ATS, narzędzia chmurowe, język komunikacji i „sezonowość” rekrutacji.
Następnie buduje legendę „idealnego kandydata” lub partnera: dopasowane CV, portfolio w formie linku, odniesienia do technologii, których firma naprawdę używa. Atak uderza w momencie największego obciążenia HR, np. przy masowej rekrutacji, gdy czujność naturalnie spada. Jeden nieuważny klik w link lub załącznik pozwala zainstalować malware albo przejąć konto.
Dobrym nawykiem jest traktowanie każdego nietypowego pliku lub linku jak potencjalnego zagrożenia – szczególnie, jeśli przychodzi spoza standardowego systemu rekrutacyjnego.
Skąd atakujący wie, kogo dokładnie w HR zaatakować?
Kluczowa jest analiza publicznych źródeł. Profil pracownika na LinkedIn zdradza rolę, zakres odpowiedzialności, trwające projekty rekrutacyjne, a czasem nawet narzędzia HR i ATS. Ogłoszenia o pracę pokazują, kto prowadzi rekrutację, na jaki e‑mail wysyłać aplikacje i jak wygląda proces rekrutacyjny krok po kroku.
Uzupełnieniem są zakładki „Kariera” i aktywność w social media: posty o „sezonie rekrutacyjnym”, deadlinach, nowych projektach. Na tej podstawie atakujący tworzy mapę: konkretna osoba, konkretne stanowisko, konkretna skrzynka mailowa i idealny moment ataku.
Dlatego publikując informacje rekrutacyjne, przefiltruj je także „oczami napastnika” – usuń zbędne szczegóły o systemach, procesach i osobach kontaktowych.
Jak przejęcie konta HR pomaga atakującym w dalszym ataku na firmę?
Przejęte konto HR to gotowy „zestaw startowy” do dalszej penetracji sieci. Umożliwia dostęp do systemów kadrowo‑płacowych, wspólnych dysków z umowami, wewnętrznych baz wiedzy, systemów benefitowych oraz skrzynek grupowych. To z kolei pozwala budować bardzo wiarygodne scenariusze socjotechniczne wobec innych działów.
Przykład z praktyki: z przejętej skrzynki HR do działu finansów trafia prośba o „pilne potwierdzenie listy płac w nowym bezpiecznym systemie”. Link prowadzi do fałszywej strony logowania. Dla księgowości, która współpracuje z HR przy wypłatach, taka wiadomość wygląda jak normalny element procesu.
Chcesz utrudnić taki scenariusz? Wymuś MFA na kontach HR, ogranicz uprawnienia „na zapas” i wprowadź zasadę weryfikacji nietypowych próśb drugim kanałem (np. telefonem).
Jak dział HR może realnie zmniejszyć ryzyko udanego ataku?
Po pierwsze – procedury i narzędzia. Warto, by większość aplikacji przechodziła przez system ATS, a nie bezpośrednio na skrzynki personalne. Dodatkowo pomoga: sandboxy do otwierania załączników, ograniczone uprawnienia na współdzielonych dyskach oraz obowiązkowe MFA na wszystkich kontach HR.
Po drugie – nawyki. Zdrowy sceptycyzm wobec „zbyt idealnych” kandydatów, weryfikacja nietypowych formatów plików, nieklikanie w linki skrócone, reagowanie na podejrzane zachowania konta (dziwne logowania, autoodpowiedzi ustawione bez wiedzy użytkownika). Krótkie, regularne scenariuszowe szkolenia dla HR są tu znacznie skuteczniejsze niż jednorazowe „RODO-owe” prezentacje.
Wprowadzaj te zmiany stopniowo, ale konsekwentnie – każdy nowy bezpieczny nawyk w HR realnie podnosi poziom ochrony całej firmy.
Jak pisać ogłoszenia o pracę, żeby nie ułatwiać pracy cyberprzestępcom?
Ogłoszenia nie powinny zawierać zbędnych szczegółów o infrastrukturze i procesach. Dokładna nazwa systemu ATS, liczba etapów wraz z formatem zadań i pełny opis narzędzi chmurowych to gotowa instrukcja dla napastnika, jak podszyć się pod kandydata lub platformę rekrutacyjną.
Bezpieczniejszym podejściem jest opisywanie procesu w sposób ogólny, bez wymieniania konkretnych dostawców i technologii, o ile nie jest to kluczowa informacja dla kandydata. Adres do kontaktu możesz kierować do dedykowanego aliasu (np. praca@), a nie do imiennej skrzynki konkretnej osoby, co utrudni precyzyjne namierzanie ofiar.
Przejdź przez swoje ogłoszenia jak audytor bezpieczeństwa – usuń to, co niepotrzebnie odsłania kulisy działania HR i systemów firmowych.
Opracowano na podstawie
- ENISA Threat Landscape 2023. European Union Agency for Cybersecurity (ENISA) (2023) – Przegląd głównych wektorów ataków, w tym phishing i socjotechnika
- Data Breach Investigations Report. Verizon (2023) – Statystyki incydentów, rola phishingu i ataków na konta pracowników
- Human Factor in Security: Social Engineering Attacks and Defense Strategies. IEEE (2016) – Analiza ataków ukierunkowanych na pracowników i metody obrony
- ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection. International Organization for Standardization (2022) – Wymagania systemu zarządzania bezpieczeństwem informacji, także dla HR
- NIST Special Publication 800-53 Rev. 5: Security and Privacy Controls. National Institute of Standards and Technology (2020) – Kontrole bezpieczeństwa dot. dostępu, uprawnień i ochrony danych osobowych
- Guidelines on Data Protection Impact Assessment (DPIA). European Data Protection Board (2017) – Wytyczne DPIA dla procesów wysokiego ryzyka, w tym przetwarzania danych HR
- RODO. Ogólne rozporządzenie o ochronie danych. Komentarz. C.H. Beck (2018) – Komentarz do RODO, w tym przetwarzanie danych pracowników i kandydatów
- Wytyczne dotyczące przetwarzania danych osobowych w miejscu pracy. Urząd Ochrony Danych Osobowych – Polskie wytyczne UODO dla pracodawców i działów HR






