Kontekst firmy i tło incydentu – gdzie rodzi się podatność
Profil organizacji i środowisko pracy
Opisywany atak phishingowy dotknął średniej wielkości firmę usługową działającą w modelu B2B. Zatrudniała około kilkuset osób, miała kilka oddziałów w Polsce i część zespołu pracującą w modelu hybrydowym. Codzienność biznesowa kręciła się wokół poczty e‑mail, komunikatorów, systemu CRM oraz systemu finansowo‑księgowego dostępnego z przeglądarki.
Organizacja miała formalnie spisane polityki bezpieczeństwa, regulaminy korzystania z poczty i dostępu zdalnego. Dokumenty powstały podczas wdrożenia systemu ISO kilka lat wcześniej. W praktyce trafiły do szuflady: większość pracowników nie potrafiła wskazać, gdzie je znaleźć, a nowo zatrudnieni dostawali jedynie krótki PDF „do zapoznania się”. Pomiędzy tym, co „na papierze”, a codziennym używaniem systemów istniała wyraźna luka.
Środowisko pracy sprzyjało pośpiechowi. Dużo projektów, częste „wrzutki na wczoraj”, napięte terminy rozliczeń i raportowania. Komunikacja mocno rozproszona: kilkanaście kanałów na komunikatorze, kilka skrzynek funkcjonalnych, prywatne numery telefonów w obiegu z klientami. E‑mail pełnił rolę formalnego „nośnika zleceń” – wszystko, co przychodziło z adresu służbowego, było traktowane jako ważne i warte szybkiej reakcji.
Kluczowe systemy i realny poziom bezpieczeństwa
Firma korzystała z popularnej chmurowej platformy poczty e‑mail, która oferowała dwuskładnikowe uwierzytelnianie, zaawansowane filtry spamu i mechanizmy wykrywania podejrzanych logowań. Opcje te były jednak słabo skonfigurowane. Uwzględniono „domyślne” ustawienia, a MFA było wymagane jedynie dla administratorów IT i wybranej kadry zarządzającej. Większość pracowników biurowych logowała się wyłącznie hasłem.
System finansowo‑księgowy nie był wystawiony bezpośrednio do Internetu, ale umożliwiał dostęp zdalny przez VPN. Dostęp do systemu mieli pracownicy księgowości, kontrolingu oraz zarząd. W praktyce kilka osób używało tego samego konta roboczego dla „bezpieczeństwa” i „wygody”, bo „tak jest szybciej”. To już na starcie tworzyło chaos odpowiedzialności – trudno stwierdzić, kto faktycznie wykonywał dane operacje.
IT funkcjonowało raczej reaktywnie niż proaktywnie. Zajmowało się „gaszeniem pożarów”: awarie, brak dostępu, nowe konta, reset haseł. Regularny monitoring logów, testy phishingowe czy przegląd uprawnień były odkładane, bo „nie ma na to ludzi i czasu”. Formalnie istniał inspektor ochrony danych oraz roczne audyty, ale skupiały się one bardziej na dokumentacji niż na realnych praktykach w organizacji.
Kultura bezpieczeństwa – poczucie odpowiedzialności czy przerzucanie winy
W firmie panowało silne przekonanie, że bezpieczeństwo to domena działu IT. Pracownicy biurowi oczekiwali, że system „sam odfiltruje” wszystko niebezpieczne. Jeżeli coś przechodziło przez filtr spamu i trafiało do skrzynki, było z automatu traktowane jako bezpieczne. Na szkoleniach wstępnych o phishingu wspominano, ale w sposób teoretyczny, bez realnych case study i bez pokazania, jak łatwo ulec socjotechnice pod presją czasu.
Nie istniała jasna, krótka i znana wszystkim procedura zgłaszania podejrzanych wiadomości. Część osób dzwoniła do informatyka, inni wysyłali screena na komunikatorze, jeszcze inni po prostu kasowali maila i zapominali. Brakowało jednego kanału do raportowania, śledzenia zgłoszeń i szybkiej reakcji. To ważny kontekst, który później mocno skomplikował kontrolę nad sytuacją.
Firmę dotykały wcześniej drobniejsze incydenty: pojedyncze fałszywe wiadomości od „kurierów”, zgłoszenia od klientów, że ich poczta pokazuje ostrzeżenia przy wiadomościach z domeny firmy, czy nieudane próby logowania z egzotycznych lokalizacji. Traktowano je jako „użytkowy szum”, a nie sygnały ostrzegawcze, że ktoś aktywnie testuje obronę organizacji.
Im lepiej rozpoznany jest realny kontekst firmy, tym łatwiej odczytać pierwsze sygnały nadchodzącego ataku phishingowego i zareagować, zanim przerodzi się on w pełnowymiarowy kryzys.
Pierwsza iskra: jak zaczyna się atak phishingowy
Zbieranie informacji – rekonesans napastnika
Atak phishingowy w firmie rzadko jest przypadkowym „strzałem w ciemno”. W tym przypadku napastnik przeprowadził kilka dni rekonesansu. Wystarczyło przejrzeć publiczny profil firmy na LinkedIn, strony z ogłoszeniami o pracę, zakładkę „O nas” na stronie www oraz profile kluczowych pracowników w mediach społecznościowych. Z tych źródeł zbudował całkiem szczegółowy obraz organizacji.
Ze strony firmowej można było odczytać strukturę działów, imiona i nazwiska części menedżerów, adresy e‑mail w formacie imię.nazwisko@domena, nazwy stosowanych narzędzi (wspominane w ogłoszeniach o pracę: Office 365, Slack, popularny system CRM). Z ogłoszeń rekrutacyjnych wynikał także model pracy (hybryda) i używanie prywatnych urządzeń do pracy zdalnej. Z perspektywy atakującego to cenna wiedza: oznacza większą różnorodność środowisk i często słabszą kontrolę nad urządzeniami końcowymi.
Analiza publicznych postów pokazała, kto odpowiada za finanse, kto pełni rolę dyrektora operacyjnego, a kto jest kierownikiem zespołu księgowości. Napastnik mógł je łatwo powiązać z adresami e‑mail i utworzyć listę celów pierwszego kontaktu. To klasyczny etap OSINT (Open Source Intelligence) – zbieranie informacji wyłącznie z ogólnodostępnych źródeł.
Dobór celu i motywacja atakującego
Na podstawie rekonesansu atakujący zdecydował się uderzyć w osoby z działu finansów oraz menedżerów średniego szczebla odpowiedzialnych za zatwierdzanie płatności. Motywacja była typowa dla ukierunkowanego phishingu w firmie: szybki zysk finansowy poprzez przejęcie konta e‑mail, a następnie zmianę danych do przelewów lub wysyłkę fałszywych faktur do klientów.
Cel ataku phishingowego był więc dwuetapowy. Po pierwsze: zdobyć login i hasło do konta e‑mail osoby z dostępem do danych finansowych i procesów. Po drugie: użyć tej skrzynki jako „konia trojańskiego” – z jej poziomu prowadzić dalszą socjotechnikę wobec innych pracowników i kontrahentów. Takie przejęte konto jest wyjątkowo wartościowe, bo cieszy się zaufaniem odbiorców.
Atakujący mógł też liczyć na „podsprzedanie” dostępu, jeśli natrafi na szczególnie atrakcyjne konto. Na czarnym rynku dostęp do skrzynek w firmach finansowych, medycznych czy technologicznych jest towarem wymiennym. Dla części napastników to osobny model biznesowy – zbierają dostępy, a później odsprzedają je innym grupom zajmującym się już np. ransomware.
Oś czasu: od rekonesansu do wysyłki pierwszej fali maili
Od pierwszego wejścia na stronę firmową do wysyłki pierwszej partii e‑maili przeszły zaledwie 3–4 dni. Rekonesans zajął około kilku godzin rozłożonych na dwa dni – przeglądanie profili, notowanie nazwisk, tworzenie listy adresów e‑mail. Kolejny dzień to przygotowanie domeny łudząco podobnej do firmowej, skonfigurowanie serwera pocztowego i stworzenie szablonu wiadomości phishingowej podszywającej się pod dział IT.
W czwartym dniu atakujący wysłał pierwszą falę kilkunastu wiadomości do osób z działu finansów i kilku menedżerów. Mail informował o „pilnej aktualizacji zabezpieczeń konta e‑mail” w związku z „wzmożoną falą ataków”. Temat był dobrany perfekcyjnie: budził niepokój, odwoływał się do autorytetu IT i sugerował, że opóźnienie wykonania czynności może skończyć się blokadą konta.
W tym momencie atak phishingowy w firmie wszedł w fazę widoczną dla użytkowników. Od tego, jak zareagują na pierwsze maile, zależał dalszy przebieg zdarzeń. Kilka kliknięć lub ich brak miało zdecydować o tym, czy incydent da się zamknąć w ciągu godzin, czy przerodzi się w wielodniowy kryzys z realnymi stratami finansowymi.
Prosty eksperyment OSINT: poświęć 30 minut i spróbuj z zewnątrz zebrać informacje o własnej firmie – lista wniosków potrafi otworzyć oczy na to, jak łatwo jest dobrać się do odpowiednich osób.
Wiadomość phishingowa pod lupą: konstrukcja, język, pułapki
Anatomia tematu wiadomości – pilność, autorytet, emocje
Temat wiadomości był krótki i uderzał w poczucie odpowiedzialności odbiorcy: „Pilna aktualizacja zabezpieczeń konta – wymagane działanie do 14:00”. Słowo „pilna” budziło natychmiastowy niepokój, a określony deadlinem czas tworzył presję. W natłoku zadań wielu odbiorców nie analizuje, czy faktycznie było zapowiadane jakieś działanie IT – widzą termin i chcą „odhaczyć” zadanie.
Odwołanie do zabezpieczeń konta wzbudzało skojarzenie z bezpieczeństwem danych i potencjalną odpowiedzialnością. W działach finansowych strach przed konsekwencjami wycieku lub utraty dostępu jest realny. Temat nie mówił nic o zmianie hasła wprost, ale sugerował „aktualizację zabezpieczeń”, co brzmiało technicznie i wiarygodnie.
Taki dobór słów to socjotechnika w czystej postaci. Połączenie pilności, strachu przed negatywnymi skutkami i odwołania do niejasnej, technicznej procedury, za którą stoi rzekomo dział IT. Dla wielu pracowników to wystarczający powód, aby otworzyć maila natychmiast, nawet kosztem przerwania aktualnego zadania.
Nadawca, domena i stopka – jak wygląda dobrze sfałszowany mail
Adres nadawcy wyglądał na pierwszy rzut oka przekonująco: it-support@domena‑firmy.pl. Atakujący zarejestrował domenę różniącą się od prawdziwej jednym znakiem (zmiana jednej litery na podobną wizualnie). W większości klientów poczty, w widoku „szybkim”, wyświetlana była tylko nazwa nadawcy „IT – Wsparcie techniczne” oraz początek domeny. Pełny adres widoczny był dopiero po rozwinięciu szczegółów.
Stopka wiadomości została starannie skopiowana z autentycznego maila otrzymanego kiedyś przez jednego z klientów firmy i dostępnego w publicznym zgłoszeniu (np. w wątku na forum zrzutu ekranu). Zawierała logo, adres siedziby, numer telefonu do recepcji, link do polityki prywatności. Taki poziom szczegółowości sprawiał, że mail na pierwszy rzut oka wyglądał „jak wszystkie inne” firmowe komunikaty.
Jednym z nielicznych sygnałów ostrzegawczych była drobna różnica w formie powitania („Drogi Użytkowniku” zamiast „Dzień dobry, Imię”), co odbiegało od standardu komunikacji IT w firmie. Jednak w praktyce wielu użytkowników traktuje takie różnice jako efekt „szablonu systemowego” i nie przywiązuje do nich wagi – szczególnie pod presją czasu.
Treść maila i typowe „haczyki”
Treść wiadomości phishingowej była krótka i konkretna, bez rozwlekłych wyjaśnień, które mogłyby zwrócić uwagę. Kluczowe elementy:
- odwołanie do „najnowszych wytycznych bezpieczeństwa dostawcy poczty”,
- informacja o „zidentyfikowanych próbach nieautoryzowanego logowania do części kont”,
- podkreślenie, że „aby uniknąć blokady konta”, konieczne jest potwierdzenie danych logowania,
- odsyłacz opisany jako „Bezpieczny panel weryfikacji IT”,
- termin wykonania czynności (do godziny 14:00) oraz sugestia, że brak reakcji może skutkować „czasowym wstrzymaniem dostępu”.
Napastnik nie próbował tłumaczyć szczegółów technicznych. Uniknął specjalistycznego żargonu, który mógłby go zdradzić. Zamiast tego postawił na prosty komunikat biznesowy: jest problem z bezpieczeństwem, jest proste działanie do wykonania, jest termin i konsekwencje. To dokładnie ta forma, którą w pośpiechu większość ludzi przyswaja bez głębszej refleksji.
Podobne „haczyki” pojawiają się także w innych scenariuszach phishingu w firmie: prośby o pilną płatność, informacja o zmianie rachunku bankowego kontrahenta, wezwanie do podpisania dokumentu w systemie elektronicznego podpisu czy powiadomienie o paczce kurierskiej. W każdym przypadku wykorzystywana jest kombinacja: pilności + autorytetu + prostego działania.
Elementy graficzne, linki i załączniki – gdzie czai się techniczna pułapka
Wiadomość nie zawierała załączników, co samo w sobie zmniejszało szansę na podejrzenia ze strony systemów antywirusowych i filtrów. Kluczowym elementem był link prowadzący do fałszywego panelu logowania. Tekst linku brzmiał „Otwórz panel weryfikacji”, a po najechaniu na niego kursorem pojawiał się adres w domenie bardzo podobnej do firmowej, z dopiskiem „‑secure” w subdomenie.
Strona phishingowa została przygotowana z użyciem darmowego szablonu imitującego interfejs popularnej chmurowej poczty. Logo firmy zostało wklejone w górnym rogu, a w tle widniało standardowe tło przypominające oryginalny panel logowania. Różnica leżała w adresie URL oraz braku certyfikatu EV (rozszerzonego), ale strona wciąż miała podstawowy certyfikat SSL – kłódka w przeglądarce była widoczna.
Ukryte mechanizmy śledzące i testowanie „jakości” ofiar
Mail zawierał również niewidoczny dla użytkownika piksel śledzący osadzony w obrazku stopki. Dzięki temu atakujący wiedział, kto otworzył wiadomość, z jakiego adresu IP oraz z jakiego klienta poczty korzysta dana osoba. Na tej podstawie mógł priorytetyzować ofiary – np. najpierw skupić się na komputerach w siedzibie głównej lub na użytkownikach korzystających z przeglądarki, którą łatwiej obejść.
W treści linku zastosowano parametry identyfikujące konkretnego odbiorcę. Dzięki temu po wejściu na stronę phishingową napastnik wiedział, które konto firmowe próbuje się logować. Gdy któryś z użytkowników popełnił błąd przy wpisywaniu hasła, strona wyświetlała komunikat o „nieprawidłowym haśle”, zachęcając do ponownego wpisania. Pozwalało to wychwycić literówki i pozyskać poprawne dane logowania.
Takie techniki są rutynowo używane przez grupy phishingowe. To nie jest chaotyczne „łowienie na ślepo”, ale systematyczne sprawdzanie, kto reaguje, kto się loguje i które konta mogą być najbardziej opłacalne do dalszej eksploitacji. Im lepiej zrozumiesz, jak wygląda „zaplecze” takiej kampanii, tym szybciej rozpoznasz później podejrzane schematy u siebie.
Pierwsze błędy po stronie pracownika: gdzie człowiek przegrywa z socjotechniką
Presja czasu i wielozadaniowość – idealne warunki dla napastnika
Kluczowa ofiara w tej historii – specjalistka ds. rozliczeń – otrzymała wiadomość phishingową w środku napiętego poranka. Trwało zamykanie miesiąca, kilka faktur oczekiwało na pilne zatwierdzenie, a telefon nie przestawał dzwonić. W takiej atmosferze mail z tematem „Pilna aktualizacja zabezpieczeń konta – wymagane działanie do 14:00” nie trafił na spokojne, analityczne spojrzenie.
Pracowniczka otworzyła maila niemal odruchowo, między jednym a drugim zadaniem. Nie przejrzała go od początku do końca; skupiła się na pogrubionych fragmentach, terminie i przycisku „Otwórz panel weryfikacji”. Taki „skan wzrokiem”, zamiast uważnego czytania, jest standardem w natłoku korespondencji – i właśnie na to liczą atakujący.
Kilka drobnych sygnałów ostrzegawczych przeszło niezauważonych: minimalnie inna forma powitania, lekko zmieniona domena, brak wcześniejszej zapowiedzi tego typu działań ze strony IT. W normalnych warunkach mogłaby to zakwestionować. W trybie zadaniowego „odhaczania” priorytetem było jedno: „zrób to, żeby się odczepił problem z mailem”.
Brak weryfikacji kanału – wiara w to, co „pisze w mailu”
Największym błędem nie było samo otwarcie wiadomości, tylko brak próby potwierdzenia jej autentyczności innym kanałem. Wystarczyłby jeden telefon do działu IT: „Dostałam takiego maila, rzeczywiście mamy jakąś pilną aktualizację?”. Takie proste nawyki budują barierę nie do przeskoczenia dla większości masowych kampanii phishingowych.
W tej firmie kultura komunikacji była jednak inna. IT kojarzyło się z „zajętymi ludźmi, których lepiej nie zawracać drobiazgami”. Pracownicy nie mieli jasnego przekazu, że lepiej zgłosić dziesięć fałszywych alarmów niż pominąć jeden prawdziwy. To powodowało, że zamiast zapytać o maila, woleli „po prostu zrobić, co trzeba” i mieć spokój.
Podobny scenariusz powtarza się w wielu organizacjach: brak łatwego kanału do szybkiej konsultacji (np. dedykowany Teams/Slack „#podejrzane‑wiadomości”) sprawia, że pracownik zostaje sam z decyzją. A samotny użytkownik, niepewny, ale zabiegany, bardzo często wybierze „kliknij i miej to z głowy”.
Ignorowanie małych niezgodności – „pewnie system tak ma”
Po kliknięciu linku pracowniczka trafiła na stronę wyglądającą jak znajomy panel logowania. Zauważyła, że adres w pasku przeglądarki jest trochę inny niż zwykle, ale szybko to zracjonalizowała: „pewnie nowy adres serwera” albo „IT coś zmieniło”. To typowa reakcja – jeśli wizualnie wszystko pasuje, mózg dopasowuje resztę do oczekiwanego obrazu.
Nie zwróciła też uwagi na brak standardowego banera powitalnego, który zwykle pojawiał się przy logowaniu (np. krótki komunikat o zasadach bezpieczeństwa). Interfejs był wystarczająco podobny, żeby nie wywołać alarmu, a minimalne różnice zostały zignorowane. Socjotechnika działa tu jak „szumierz”: im bardziej jesteś skupiony na zadaniu (w tym przypadku – „wpisz login i hasło”), tym mniej widzisz otoczenie.
Gdy za pierwszym razem wpisała hasło z literówką i pojawił się komunikat „Nieprawidłowe hasło, spróbuj ponownie”, uznała to za normalne zachowanie systemu. Wpisała więc hasło jeszcze raz, staranniej. Tym samym przekazała napastnikowi dwie wersje hasła – z błędem i bez – ułatwiając mu potwierdzenie poprawnej kombinacji.
Szkolenia odhaczone „dla kary” zamiast budowania nawyków
Co istotne, ta pracowniczka brała udział w firmowym szkoleniu z bezpieczeństwa kilka miesięcy wcześniej. Rozpoznałaby wiele elementów tego ataku, gdyby miała czas i przestrzeń, żeby się nad nimi pochylić. Problem polegał na tym, że szkolenie odbyło się w formie jednokrotnego webinaru i testu końcowego – bez regularnych przypomnień i ćwiczeń praktycznych.
W pamięci zostało ogólne hasło „nie klikaj w podejrzane linki”, ale nie konkretny zestaw kroków: sprawdź domenę, potwierdź innym kanałem, zgłoś wątpliwość. Bez przełożenia na codzienną rutynę cała wiedza została w teorii. To tak, jakby nauczyć kogoś zasad pierwszej pomocy tylko na slajdach, a potem oczekiwać spokojnej reakcji w prawdziwym wypadku.
Jeśli bezpieczeństwo w organizacji ma działać, musi być ćwiczone, a nie tylko „przepowiedziane”. Krótkie, regularne scenariusze „co byś zrobił, gdyby…?” robią większą różnicę niż najdłuższy coroczny webinar. Ten przypadek doskonale pokazał, jak szybko teoria rozpływa się pod presją codziennej pracy.
Prosty krok na dziś: ustal w swoim zespole zasadę „zawsze możesz zapytać” – lepiej pięć razy rozwiać czyjeś obawy, niż raz gasić duży pożar.
Eskalacja incydentu: co dzieje się po skutecznym kliknięciu
Natychmiastowe przejęcie sesji – logowanie z innego kraju po kilku minutach
W momencie, gdy pracowniczka wpisała poprawne dane logowania, zostały one natychmiast przesłane na serwer kontrolowany przez napastnika. Zwykle od tego momentu do pierwszego nieautoryzowanego logowania mija tylko kilka minut – czasem zautomatyzowany skrypt loguje się wręcz w tej samej sekundzie.
W tym przypadku atakujący zalogował się na przejęte konto z adresu IP przypisanego do zagranicznego dostawcy VPN. System bezpieczeństwa firmy zarejestrował nietypowe logowanie, ale nie przekroczyło ono progu alarmowego (ktoś mógł być przecież na delegacji). Brak wymuszonego MFA na każdym logowaniu z nowej lokalizacji sprawił, że bariera była zbyt niska.
W ciągu kilkunastu minut napastnik:
- sprawdził skrzynkę pod kątem słów kluczowych typu „faktura”, „płatność”, „przelew”, „umowa”,
- zidentyfikował najczęściej używanych kontrahentów i wewnętrzne adresy do działu finansów,
- przejrzał folder „Wysłane”, żeby poznać styl komunikacji przejętej osoby.
Na tym etapie nie dokonywano jeszcze żadnych widocznych zmian. Z punktu widzenia użytkownika wszystko działało normalnie – logowała się, wysyłała maile, nie widząc, że równolegle ktoś inny czyta jej skrzynkę jak otwartą książkę.
Ustawienie reguł skrzynki – ciche przejęcie kontroli nad korespondencją
Kolejnym krokiem było skonfigurowanie reguł poczty. Napastnik dodał ukrytą regułę, która automatycznie przekazywała kopie wszystkich przychodzących wiadomości na zewnętrzny adres e‑mail kontrolowany przez grupę atakującą. Dodatkowo ustawił filtr przenoszący konkretne typy wiadomości (np. z potwierdzeniami przelewów) do mało używanego folderu.
Dzięki temu mógł śledzić całą bieżącą korespondencję, nawet jeśli później dostęp bezpośredni do konta zostałby zablokowany. To częsta praktyka – pozostawić „tylne drzwi” w postaci reguł, które potrafią przetrwać nawet częściowe działania naprawcze IT, jeśli te skoncentrują się tylko na zmianie hasła.
Równolegle włączono funkcję automatycznego przekierowania wybranych wiadomości do innej osoby w organizacji. Pozwala to tworzyć bardziej zaawansowane scenariusze socjotechniczne, np. wplatać treści w toczące się wątki i udawać szybką „przysługę” kolegi z innego działu. Im głębiej napastnik jest w strukturę maili, tym bardziej wiarygodne ma „tło” do swoich dalszych działań.
Rozpoznanie środowiska finansowego – szukanie miejsc, gdzie płynie pieniądz
Po zabezpieczeniu dostępu do skrzynki napastnik zajął się mapowaniem procesów finansowych. Skupiał się na:
- odnalezieniu numerów rachunków bankowych kontrahentów,
- identyfikacji osób zatwierdzających przelewy i ich przełożonych,
- ustaleniu rutyny – w jakie dni i godziny zwykle wykonywane są płatności.
W historii e‑maili szybko wyłonił się schemat: przejęta pracowniczka wysyłała prośby o zatwierdzenie płatności do konkretnego menedżera, często w określonym okienku czasowym pod koniec dnia. Pojawiły się nazwy konkretnych projektów, numerów umów, szablony faktur. Taka wiedza pozwala później przygotować fałszywą instrukcję zmiany rachunku bankowego, która „wtopi się” idealnie w codzienną rutynę.
Co ważne, napastnik nie spieszył się z pierwszym ruchem finansowym. Przez kilkanaście godzin był jedynie „cichym obserwatorem”. Im dłużej mógł podglądać realne procesy, tym mniejsze ryzyko popełnienia gafy, która wzbudziłaby podejrzenia. To podejście stoi w kontrze do wyobrażeń o hakerach działających w pośpiechu – tutaj mamy do czynienia z cierpliwą, metodyczną pracą.
Podstawienie fałszywej korespondencji – mała zmiana, duże konsekwencje
Pierwszym aktywnym działaniem napastnika było podmienić jeden z wątków z kontrahentem. W historii znalazł trwającą właśnie dyskusję na temat rozliczenia dużej faktury. Kontrahent dopytywał o termin płatności, a przejęta pracowniczka czekała na wewnętrzne zatwierdzenie.
Napastnik skopiował styl wypowiedzi i wysłał z przejętego konta wiadomość z grzeczną prośbą o „aktualizację danych do płatności” z powodu rzekomej zmiany rachunku bankowego firmy. Jako „nowy numer konta” podał rachunek należący do tzw. słupa – osoby podstawionej, której konto zostanie szybko wyczyszczone i zamknięte.
Z perspektywy kontrahenta wszystko wyglądało normalnie: korespondencja odbywała się z tego samego adresu co zawsze, w tym samym wątku, z zachowaniem dotychczasowego tonu. Zaufanie było już dawno zbudowane. Dlatego mail o zmianie rachunku nie wywołał alarmu – trafił do osoby księgującej po stronie kontrahenta jak każda inna wiadomość.
Równoległe działania wewnątrz organizacji – podszywanie się pod dział IT
Napastnik nie ograniczył się do jednego wektora. Z przejętego konta wysłał do kilku współpracowników ofiary krótką prośbę o „nieudostępnianie informacji o trwających pracach nad aktualizacją systemu poczty z uwagi na politykę bezpieczeństwa dostawcy”. Ten zabieg miał uprzedzić ewentualne pytania i uwiarygodnić wcześniejszą narrację o „pilnej aktualizacji zabezpieczeń konta”.
Pojawił się również mail do helpdesku: zgłoszenie błahego problemu z dostarczaniem jednej z wiadomości. Taki „szum komunikacyjny” ma za zadanie zająć uwagę działu IT mało istotną sprawą, podczas gdy prawdziwy incydent rozwija się w tle. To rzadziej omawiany, ale bardzo skuteczny trik – rozproszyć tych, którzy mogliby zbyt wcześnie coś dostrzec.
To właśnie połączenie socjotechniki zewnętrznej (wobec kontrahenta) i wewnętrznej (wobec własnych pracowników) powoduje, że ataki BEC (Business Email Compromise) bywają tak trudne do wykrycia w pierwszej fazie. Wszystko dzieje się „wewnątrz zaufanych kanałów”, bez typowych czerwonych flag z zewnątrz.
Pierwsze sygnały ostrzegawcze – ślad w logach i czujność jednej osoby
Plan napastnika mógł zakończyć się pełnym sukcesem, gdyby nie kilka drobnych, ale kluczowych sygnałów. Jeden z administratorów zauważył w logach nietypowy wzorzec: logowanie na konto z zagranicznego IP, a kilka minut później – z sieci firmowej, bez żadnego wymuszenia dodatkowej weryfikacji. Było to nietypowe dla tej konkretnej użytkowniczki, która wcześniej niemal zawsze pracowała z biura.
Reakcja administratora – szybkie hipotezy zamiast długich analiz
Administrator nie zignorował anomalii, ale też nie wpadł w panikę. Najpierw założył kilka możliwych scenariuszy: prawdziwa delegacja, korzystanie z prywatnego VPN albo kradzież sesji. Zamiast od razu blokować konto (co mogłoby przerwać ważne procesy), sięgnął do dodatkowych logów: sprawdził typ urządzenia, godzinę logowania i zachowanie po uwierzytelnieniu.
To, co go zaniepokoiło, to sekwencja zdarzeń: kilka minut intensywnej pracy na skrzynce (przegląd wielu folderów, zmiany ustawień), przerwa, a potem powrót do „normalnego” wzorca użytkowniczki z biura. Taki „ząb” w aktywności często zdradza zewnętrznego aktora.
Administrator wykonał jeszcze jeden prosty, ale skuteczny ruch: zadzwonił do przełożonego pracowniczki z pytaniem, czy jest ona faktycznie na wyjeździe służbowym. Krótkie „nie, od rana jest w biurze” przesunęło hipotezę z „dziwna konfiguracja VPN” na „możliwy incydent bezpieczeństwa”.
Prosty krok na dziś: upewnij się, że Twój zespół IT ma prawo „zapytać u źródła”, zamiast tylko patrzeć w logi – telefon często skraca drogę do prawdy.
Zamrożenie ryzyka – blokada sesji zamiast natychmiastowego „twardego resetu”
Kiedy ryzyko stało się realne, podjęto decyzję o natychmiastowym wylogowaniu wszystkich aktywnych sesji użytkowniczki i wymuszeniu zmiany hasła przy następnym logowaniu. To był kompromis między natychmiastową blokadą a próbą zachowania kontekstu do analizy.
Równolegle ograniczono uprawnienia konta w systemie pocztowym – m.in. zablokowano możliwość tworzenia nowych reguł oraz włączono wymuszone MFA przy każdym logowaniu spoza sieci firmowej. Dzięki temu ewentualne kolejne próby atakującego nie miały mieć łatwej drogi powrotu.
Co kluczowe, administrator nie usunął od razu wszystkich modyfikacji poczynionych na koncie. Zamiast „wyczyścić” skrzynkę do zera, wykonał zrzut ustawień i logów, żeby zrozumieć pełen zakres działań napastnika. To pozwoliło później odkryć m.in. reguły przekierowujące i ich dokładne parametry.
Prosty krok na dziś: spisz z zespołem krótką procedurę „zamrożenia” konta – co blokujesz od razu, a co archiwizujesz do analizy.
Kontakt z użytkowniczką – rozmowa ważniejsza niż szukanie winnego
Gdy tylko techniczne zabezpieczenia zostały wstępnie wdrożone, do akcji wszedł przełożony wraz z osobą z zespołu bezpieczeństwa. Zaprosili pracowniczkę na krótką rozmowę, nie zaczynając od oskarżeń, tylko od prostego komunikatu: „Wykryliśmy nietypową aktywność na Twoim koncie, musimy to razem przejrzeć”.
Taka forma ma ogromne znaczenie. W atmosferze lęku i „szukania winnego” pracownik będzie minimalizował swój udział, zapominał szczegóły lub – w najgorszym wariancie – próbował coś ukryć. Tu postawiono na model partnerski: wspólnie odtworzyć przebieg dnia, przypomnieć sobie, jakie maile były otwierane, jakie formularze wypełniane.
Podczas rozmowy szybko wyszło na jaw, że była „aktualizacja bezpieczeństwa” i logowanie do rzekomego panelu dostawcy. Co ważne, pracowniczka była w stanie mniej więcej wskazać godzinę i opisać wygląd strony. To dało IT punkt zaczepienia do przeszukania logów proxy i odtworzenia ruchu sieciowego.
Prosty krok na dziś: jasno zakomunikuj w firmie, że zgłoszenie pomyłki w obszarze bezpieczeństwa nie jest powodem do kary – to jest powód do pochwały za odwagę.
Śledzenie skutków – gdzie mogły już „pójść” pieniądze
Techniczne zabezpieczenie konta to dopiero połowa gry. Druga część to odpowiedź na pytanie: co napastnik zdążył już zrobić? Zespół bezpieczeństwa, razem z działem finansów, zmapował ostatnie 24–48 godzin komunikacji i operacji płatniczych.
Przeanalizowano w pierwszej kolejności:
- wątki z kluczowymi kontrahentami, szczególnie tam, gdzie toczyły się rozmowy o płatnościach,
- wysłane wiadomości zawierające załączniki z fakturami lub instrukcjami przelewu,
- wszystkie maile wysłane w krótkim oknie czasowym po podejrzanym logowaniu z zagranicznego IP.
W jednym z wątków od razu rzuciła się w oczy wiadomość o „aktualizacji danych do płatności”. Co znamienne, jej kopii nie było w folderze „Elementy wysłane” – była ukryta dzięki wcześniej ustawionej regule. Dopiero analiza pełnych logów serwera pocztowego pokazała, że taka wiadomość jednak wyszła.
To był moment, w którym incydent z poziomu „potencjalnego” wszedł w fazę realnego ryzyka finansowego. Zadziałała tu czujność księgowej po stronie kontrahenta, która… zadzwoniła do opiekuna z pytaniem, czy faktycznie zmienili rachunek. Ten telefon uratował realne pieniądze.
Prosty krok na dziś: z działem finansów i kluczowymi kontrahentami ustal jedną, prostą zasadę – każda zmiana rachunku bankowego musi być potwierdzona drugim kanałem.
Szybka komunikacja z kontrahentem – szczerość zamiast „prania na sucho”
Gdy tylko potwierdzono, że kontrahent otrzymał fałszywą wiadomość, firma podjęła decyzję o natychmiastowym i otwartym kontakcie. Zamiast udawać, że „to drobny błąd systemu”, przedstawiono sprawę jasno: doszło do incydentu bezpieczeństwa, konto pracowniczki zostało przejęte, a częścią ataku była próba podmiany rachunku.
Kontrahent otrzymał:
- jasny opis, które konkretnie wiadomości są fałszywe i nie powinny być brane pod uwagę,
- potwierdzenie poprawnych danych bankowych wraz z ustaleniem kanału do weryfikacji w przyszłości,
- prośbę o przesłanie pełnej korespondencji dotyczącej prób zmiany rachunku w celu dalszej analizy.
Taki sposób działania, choć wymagający przyznania się do błędu, w długim terminie wzmacnia relację. Kontrahent widzi, że firma nie zamiata incydentów pod dywan i dba nie tylko o własne interesy, ale też o bezpieczeństwo partnera.
Prosty krok na dziś: przygotuj gotowy szablon maila do kontrahentów na wypadek podobnego incydentu – w kryzysie liczy się czas, nie kreatywność.
Dogaszanie „tylnych drzwi” – reguły, delegacje, integracje zewnętrzne
Po zabezpieczeniu najbardziej krytycznych obszarów przyszło czas na sprzątanie. Tu wyszło, jak bardzo perfidne potrafią być drobne, „niewidoczne” zmiany.
Zespół IT przeskanował konto pod kątem:
- wszystkich reguł skrzynki – zarówno aktywnych, jak i wyłączonych,
- delegowanych dostępów do kalendarza i poczty,
- połączeń zewnętrznych, np. aplikacji mających dostęp do poczty przez API.
Znaleziona została nie tylko reguła przekierowująca maile na zewnętrzny adres, ale też kilka pozornie „niewinnych” filtrów przenoszących wybrane wiadomości do rzadko używanych folderów. W normalnym trybie pracy użytkownik mógłby ich nie zauważyć tygodniami.
Usunięto wszystkie podejrzane reguły, a następnie nałożono dodatkową kontrolę: przez kilka tygodni logi zmian ustawień poczty tej użytkowniczki były analizowane z większą uwagą. Równolegle przeprowadzono przegląd uprawnień innych kont w dziale finansów – ataki rzadko ograniczają się do jednego celu, często jest to wstęp do szerszej kampanii.
Prosty krok na dziś: poproś IT o raport wszystkich reguł pocztowych na kontach z dostępem do finansów – to szybki sposób, by wyłapać podejrzane „automatyzacje”.
Od pojedynczego incydentu do programu zmian – lekcje dla całej organizacji
Mapowanie słabych punktów – gdzie naprawdę bolało
Po opanowaniu sytuacji zespół nie zatrzymał się na odhaczeniu zgłoszenia w systemie ticketowym. Zorganizowano krótką sesję post‑mortem z udziałem IT, bezpieczeństwa, finansów i HR. Celem nie było „rozliczenie winnych”, tylko odpowiedź na pytanie: które elementy systemu zawiodły, a które zadziałały dobrze.
Na liście słabości znalazły się m.in.:
- brak wymuszonego MFA dla logowań z nowych lokalizacji,
- szkolenie z cyberbezpieczeństwa w formie jednorazowego webinaru bez utrwalania nawyków,
- brak jasnej polityki potwierdzania zmian rachunków bankowych dwoma kanałami,
- zbyt niskie progi alarmowe dla nietypowych logowań, niepowiązane z indywidualnym profilem użytkownika.
Jednocześnie odnotowano elementy, które zadziałały na plus: czujność administratora patrzącego w logi „kontekstowo”, odwaga pracowniczki w przyznaniu się do błędu oraz rozsądek księgowej po stronie kontrahenta, która zadzwoniła przed wykonaniem przelewu.
Prosty krok na dziś: po każdym incydencie zrób krótką sesję „co nam pomogło, co nam przeszkodziło” – bez protokołu, za to z konkretnymi wnioskami do wdrożenia.
Zmiana polityk technicznych – MFA, alerty, segmentacja
Najbardziej oczywistym obszarem zmian były ustawienia systemów. Organizacja wprowadziła kilka konkretnych modyfikacji:
- wymuszone MFA dla wszystkich użytkowników przy każdym logowaniu spoza sieci firmowej,
- podniesienie czułości alertów na logowania z nietypowych krajów oraz zderzenie ich z profilem pracy użytkownika,
- ograniczenie możliwości tworzenia przekierowań na zewnętrzne domeny z kluczowych kont (np. w finansach),
- dodatkową segmentację uprawnień – żeby pojedyncze konto nie miało pełnego „obrazu” wszystkich procesów finansowych.
Przy okazji przeprowadzono przegląd integracji zewnętrznych. Okazało się, że kilka starszych aplikacji miało szerokie uprawnienia do skrzynek pocztowych, mimo że od dawna nie były realnie używane. Takie „zapomniane” dostępy to idealne miejsce na późniejsze nadużycia.
Prosty krok na dziś: zrób listę systemów, które mają dostęp do firmowej poczty – wykreśl te, których już nie potrzebujesz.
Trening zamiast jednorazowego szkolenia – krótkie ćwiczenia „na żywo”
Największą zmianą nie były tak naprawdę techniczne ustawienia, tylko podejście do edukacji. Zdecydowano, że zamiast jednego, długiego szkolenia rocznie, pracownicy będą dostawać krótkie, regularne „zastrzyki” wiedzy – często w formie dwuminutowych scenariuszy do przegadania na zebraniu zespołu.
Wdrożono m.in.:
- cykliczne, krótkie kampanie phishingowe z omówieniem wyników na poziomie zespołów,
- proste checklisty „co zrobić, gdy dostaniesz podejrzaną wiadomość” przypięte w firmowym intranecie,
- mini‑warsztaty dla działów wysokiego ryzyka (finanse, zakupy, sprzedaż B2B), prowadzone na ich realnych przykładach.
Co istotne, wyniki testów phishingowych nie były wykorzystywane do ocen rocznych. Zamiast tego skupiono się na tym, żeby każdy pracownik wiedział, co zrobić, gdy coś go niepokoi – do kogo napisać, gdzie kliknąć „zgłoś podejrzaną wiadomość”, jak zareagować bez wstydu.
Prosty krok na dziś: zaplanuj z menedżerami 10‑minutowy „cyber‑kącik” raz w miesiącu na spotkaniu zespołu – jeden scenariusz, jedna lekcja, jedna zmiana nawyku.
Wzmocnienie procedur finansowych – potwierdzenia i limity zaufania
Incydent pokazał, że nawet najlepiej zabezpieczona poczta nie zastąpi zdrowych procesów w finansach. Dlatego wspólnie z działem księgowym wprowadzono kilka prostych, ale mocnych zasad:
- każda zmiana rachunku bankowego kontrahenta wymaga potwierdzenia telefonicznego lub w dedykowanym portalu,
- instrukcje płatności przychodzące e‑mailem są traktowane jako „robocze” do momentu potwierdzenia innym kanałem,
- pod dużymi przelewami musi podpisać się co najmniej jedna osoba spoza działu bezpośrednio zaangażowanego w dany projekt.
Wprowadzono też krótką tabelę „czerwonych flag” przy płatnościach: nagła zmiana rachunku, pośpiech w wiadomości, brak spójności z dotychczasowym sposobem komunikacji. Księgowi dostali prawo wciśnięcia „pauzy” przy każdej transakcji, która budzi choćby minimalny niepokój.
Prosty krok na dziś: razem z finansami spisz listę 3–5 sytuacji, w których przelew musi zostać automatycznie wstrzymany do wyjaśnienia.
Kultura „niskiego progu zgłoszenia” – lepiej przesadzić niż zignorować
Jedną z najcenniejszych lekcji był wniosek, że organizacja musi nagradzać nadwrażliwość na podejrzane sygnały, a nie skłaniać do „nie zawracania głowy IT”. Wprowadzono prosty komunikat: jeśli cokolwiek w mailu, linku czy prośbie finansowej wydaje się choć trochę „dziwne” – zgłoś, nawet jeśli później okaże się to fałszywy alarm.
Najczęściej zadawane pytania (FAQ)
Jak w praktyce zaczyna się atak phishingowy na firmę?
Najczęściej od cichego rekonesansu. Atakujący przez kilka godzin przegląda stronę www firmy, LinkedIn, ogłoszenia o pracę i profile pracowników. Zbiera nazwy działów, imiona i nazwiska, format adresów e‑mail, informacje o używanych systemach (np. Office 365, CRM, komunikatory) i modelu pracy (np. hybryda, własne urządzenia).
Na tej podstawie wybiera grupę celów – np. finanse, księgowość, menedżerów zatwierdzających płatności – i przygotowuje wiarygodnie wyglądającą wiadomość, często „od IT” lub „od dostawcy usługi”. Dopiero potem rusza pierwsza fala maili, często z tematem typu: „Pilna aktualizacja zabezpieczeń konta”. Dobrym ruchem jest regularne sprawdzanie, jak wiele o twojej firmie można wyczytać publicznie – i usuwanie zbędnych szczegółów.
Dlaczego firmy z formalnymi politykami bezpieczeństwa nadal padają ofiarą phishingu?
Bo polityki często żyją tylko na papierze. Dokumenty powstają przy wdrożeniu ISO, lądują w intranecie lub w szufladzie, a pracownicy dostają ogólny PDF „do zapoznania się”. Bez praktycznych szkoleń, przypominajek i przykładów z życia, większość ludzi nie łączy zapisów z codzienną pracą.
Phishing wykorzystuje pośpiech i rutynę, a nie brak dokumentów. Jeśli w firmie dominuje kultura „byle szybciej”, a bezpieczeństwo jest „zadaniem IT”, nawet najlepsze procedury nie zadziałają. Zacznij od ożywienia tego, co już istnieje – krótkie warsztaty, ćwiczenia na realnych mailach, proste checklisty do wydrukowania przy monitorze.
Jakie elementy środowiska pracy zwiększają ryzyko skutecznego phishingu?
Ryzyko rośnie tam, gdzie łączą się pośpiech, rozproszona komunikacja i słabo skonfigurowane zabezpieczenia. Przykład: kilkanaście kanałów na komunikatorze, kilka skrzynek wspólnych, prywatne numery w obiegu z klientami i przekonanie, że „mail służbowy = zawsze bezpieczny”. W takiej mieszance łatwiej przeoczyć coś podejrzanego.
Drugim mocnym czynnikiem są luki techniczne i organizacyjne: brak obowiązkowego MFA dla wszystkich, wspólne loginy do systemów (np. finansowo‑księgowego), brak przeglądu uprawnień i reaktywny dział IT, który tylko „gasi pożary”. Jeśli rozpoznajesz ten obraz u siebie – to dobry moment, żeby krok po kroku go posprzątać, zanim zrobi to za ciebie napastnik.
Jakie sygnały ostrzegawcze mogą zapowiadać większy atak phishingowy?
Często pojawiają się małe, bagatelizowane incydenty: pojedyncze fałszywe maile od „kurierów”, ostrzeżenia u klientów przy wiadomościach z twojej domeny, nietypowe próby logowania z egzotycznych lokalizacji, powtarzające się prośby o reset hasła. To nie „szum”, tylko testowanie obrony.
Jeśli takie zdarzenia powtarzają się, potraktuj je jak próbny alarm przeciwpożarowy. Sprawdź logi, włącz lub zaostrz filtry bezpieczeństwa, przeprowadź krótką kampanię edukacyjną i ustal jasny sposób zgłaszania podejrzanych wiadomości. Im wcześniej zareagujesz na „drobiazgi”, tym większa szansa, że duży atak się nie powiedzie.
Co wchodzi w skład dobrze zaplanowanej wiadomości phishingowej w firmie?
Skuteczny mail phishingowy jest skrojony pod realia organizacji. Odwołuje się do znanych narzędzi (np. „aktualizacja Office 365”), autorytetów („dział IT”, „dyrektor finansowy”) i bieżących problemów („wzmożona fala ataków, konieczna weryfikacja zabezpieczeń”). Kluczem jest presja czasu i strach przed konsekwencjami, np. groźba blokady konta.
Atakujący często używa domeny łudząco podobnej do firmowej i kopii ekranu logowania. Maile trafiają do osób z dostępem do finansów lub do menedżerów, którzy mają wpływ na przelewy. Dobrym nawykiem jest odruch: „dwa oddechy, zanim kliknę” – sprawdzenie adresu nadawcy, domeny linku (na najechaniu myszką) i ewentualne potwierdzenie innym kanałem, np. krótkim telefonem do IT.
Jakie błędy organizacyjne najbardziej utrudniają reakcję na atak phishingowy?
Największy chaos tworzy brak jednej, prostej procedury zgłaszania podejrzanych wiadomości. Gdy każdy robi coś innego – dzwoni do informatyka, pisze na przypadkowy kanał, wysyła screena albo po prostu kasuje mail – dział IT nie ma pełnego obrazu sytuacji i reaguje z opóźnieniem.
Błędem jest też brak jasnej odpowiedzialności (np. wspólne konta w systemach finansowych), przez co trudno ustalić, kto co zrobił i kiedy. Ustal jeden kanał zgłoszeń (np. specjalny adres mailowy lub przycisk „Zgłoś phishing” w kliencie poczty) i komunikuj go wszystkim tak często, aż wejdzie im w nawyk.
Co realnie można zrobić, żeby zmniejszyć ryzyko podobnego ataku w swojej firmie?
Nawet w średniej firmie da się wdrożyć kilka prostych, a skutecznych kroków: włączenie MFA dla wszystkich kont, zakaz współdzielenia loginów, przegląd uprawnień w systemach finansowych, lepsza konfiguracja filtrów bezpieczeństwa poczty. To techniczne minimum, które mocno podnosi poprzeczkę dla napastnika.
Drugą nogą jest codzienna praktyka ludzi: krótkie, cykliczne szkolenia z przykładami prawdziwych maili, wewnętrzne kampanie testowego phishingu (bez karania, za to z natychmiastową informacją zwrotną) oraz klarowna procedura „co robię, gdy coś mnie niepokoi”. Zacznij od jednego działania w tym tygodniu – nawet mały krok w stronę świadomego bezpieczeństwa już obniża szanse udanego ataku.
Najważniejsze punkty
- Formalne polityki bezpieczeństwa bez realnego wdrożenia są martwe – jeśli dokument leży w szufladzie, to w krytycznym momencie nikt nie wie, jak się zachować.
- Pośpiech, „wrzutki na wczoraj” i rozproszona komunikacja obniżają czujność – w takim środowisku dużo łatwiej kliknąć w spreparowany link lub załącznik „bo trzeba szybko załatwić sprawę”.
- Niewłaściwa konfiguracja narzędzi (MFA tylko dla wybranych, domyślne ustawienia bezpieczeństwa, współdzielone konta) tworzy złudne poczucie ochrony i utrudnia późniejsze ustalenie, kto faktycznie zrobił daną operację.
- Reaktywny dział IT i brak proaktywnych działań (monitoringu logów, testów phishingowych, przeglądu uprawnień) sprawiają, że organizacja widzi problem dopiero wtedy, gdy atak jest już w toku.
- Kultura „bezpieczeństwo to sprawa IT” zdejmuje odpowiedzialność z pracowników – skoro ufają, że filtr spamu odsieje wszystko niebezpieczne, to każdą wiadomość w skrzynce traktują automatycznie jako bezpieczną.
- Brak jednolitego, prostego kanału zgłaszania podejrzanych maili prowadzi do chaosu – część osób dzwoni, inni wysyłają screeny, jeszcze inni kasują wiadomość, więc firma traci szansę na szybkie wykrycie i opanowanie incydentu.
- Napastnik potrzebuje tylko ogólnodostępnych danych (LinkedIn, strona „O nas”, ogłoszenia o pracę), by precyzyjnie dobrać cele i przygotować wiarygodny phishing – ograniczenie ekspozycji takich informacji i świadomość pracowników realnie utrudnia atak.
Opracowano na podstawie
- NIST Special Publication 800-61 Revision 2: Computer Security Incident Handling Guide. National Institute of Standards and Technology (2012) – Ramy reagowania na incydenty, w tym ataki phishingowe w organizacjach
- NIST Special Publication 800-63B: Digital Identity Guidelines – Authentication and Lifecycle Management. National Institute of Standards and Technology (2017) – Zalecenia dot. uwierzytelniania, w tym MFA w systemach korporacyjnych
- ENISA Threat Landscape 2023. European Union Agency for Cybersecurity (ENISA) (2023) – Przegląd trendów zagrożeń, z naciskiem na phishing i socjotechnikę
- ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection – Information security management systems. International Organization for Standardization (2022) – Wymagania dla systemu zarządzania bezpieczeństwem informacji w firmach
