Phishing to podszycie się pod znaną instytucję po to, żeby człowiek sam oddał poświadczenie albo pieniądze. Po zgłoszeniu liczy się kolejność: najpierw odetnij aktywne sesje i tokeny przejętego konta, potem ustal z logów zasięg dostępu, a dopiero na końcu zmieniaj hasło i pisz podsumowanie.
Znajdziesz tu firmową procedurę, nie listę znaków ostrzegawczych w mailu. Zaczynasz od momentu, w którym ktoś już kliknął i już podał dane. Kończysz na tym, co da się o tym incydencie udowodnić z dziennika zdarzeń.
Co atakujący naprawdę zdobywa?
Chronisz konto, a nie skrzynkę. Podstawiona strona logowania zbiera hasło, a w tej samej rozmowie także kod jednorazowy, jeśli konto go używa. Atakujący przekazuje oba dalej do prawdziwej usługi i dostaje sesję. Od tej chwili ma dokładnie te uprawnienia, które ma zaatakowany pracownik.
Sesja jest ważniejsza od hasła. Po zalogowaniu usługa wydaje token, który żyje własnym życiem i nie pyta ponownie o poświadczenie. Zmiana hasła nie musi go unieważnić - to zależy od produktu i od ustawień. Dlatego pierwsze pytanie w incydencie brzmi „czy ta sesja jeszcze działa", a nie „czy hasło zostało zmienione".
Druga rzecz, którą atakujący zdobywa, to czas. Utrzyma dostęp regułą przekierowującą pocztę, dodanym własnym mechanizmem logowania albo tokenem aplikacyjnym wydanym na boku. Każdy z tych trzech śladów zostaje w koncie po zmianie hasła, jeśli nikt ich nie usunie.
Piątkowe popołudnie w biurze projektowym
Weź firmę projektową na dwadzieścia osób, z pocztą i dyskiem w jednej usłudze chmurowej. To fikcyjny przykład złożony z typowych błędów reakcji, nie opis konkretnego klienta.
Asystentka dostała w piątek wiadomość o wygasającym haśle do poczty firmowej. Strona wyglądała identycznie jak prawdziwy panel logowania. Wpisała hasło i kod z aplikacji. Zorientowała się po dwóch minutach, bo panel poprosił o dane drugi raz. Powiedziała o tym koleżance, a nie administratorowi, bo bała się, że zrobiła coś głupiego.
Administrator dowiedział się w poniedziałek rano. Zresetował hasło, kazał przeinstalować aplikację do kodów i uznał sprawę za zamkniętą. Nikt nie sprawdził aktywnych sesji. Token wydany w piątek działał dalej i nikt go nie unieważnił.
Przez weekend z konta wyszły trzy wiadomości do klientów ze zmienionym numerem rachunku. Kopie tych wiadomości nie zostały w folderze wysłanych, bo reguła w skrzynce kasowała je od razu. Firma dowiedziała się o tym od klienta, który zapłacił.
Żaden z tych kroków nie był głupi z osobna. Zawiodła kolejność i zakres. Reset hasła bez odcięcia sesji zamyka drzwi wejściowe przy otwartym oknie, a zgłoszenie w poniedziałek za pierwszą decyzję przyjmuje dwa dni ciszy.
Kto przyjmuje zgłoszenie i w jakim czasie?
Kanał zgłaszania ustala się przed incydentem, nie w jego trakcie. Pracownik ma znać jeden adres i jeden numer telefonu, pod którym zgłasza podejrzaną wiadomość, i ma wiedzieć, że zgłoszenie po kliknięciu też jest mile widziane. Firma, w której zgłoszenie kończy się rozmową dyscyplinującą, traci dostęp do informacji o własnych incydentach.
Zapisz w procedurze cztery rzeczy:
- Adres i telefon, pod który idzie zgłoszenie, oraz osobę, która odbiera je poza godzinami pracy.
- Zasadę, że pracownik zgłasza także wtedy, gdy podał dane, i że nie ponosi za samo zgłoszenie konsekwencji.
- Wymóg zachowania oryginalnej wiadomości razem z nagłówkami, zanim ktokolwiek ją skasuje.
- Nazwisko osoby, która podejmuje decyzję o odcięciu konta, i jej zastępcy.
Zgłoszenie zewnętrzne prowadzi w Polsce do zespołu CERT Polska, który przyjmuje zgłoszenia incydentów przez formularz na własnej stronie. Zgłoszenie fałszywej strony ma jeszcze jeden skutek poza twoją firmą, bo trafia do listy ostrzeżeń używanej przez operatorów. Jeżeli twoja firma jest operatorem usługi kluczowej albo dostawcą usługi cyfrowej w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa, obowiązują cię osobne terminy zgłoszenia. Katalog podmiotów i terminy zmieniają się wraz z nowelizacjami tej ustawy, więc sprawdzaj je w aktualnym tekście przepisów, nie w artykule.
Osobną ścieżką idzie ochrona danych osobowych. Rozporządzenie 2016/679 w artykule 33 wymaga zgłoszenia naruszenia organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w terminie 72 godzin po stwierdzeniu naruszenia. Artykuł 34 dokłada zawiadomienie osób, których dane dotyczą, gdy naruszenie może powodować wysokie ryzyko dla ich praw i wolności. Artykuł 33 ustęp 5 każe dokumentować każde naruszenie, także to niezgłoszone. Ocena konkretnego przypadku należy do administratora danych i jego inspektora, nie do tej strony.
Pierwsze trzydzieści minut
Kolejność poniżej wynika z tego, że atakujący traci dostęp dopiero przy kroku trzecim. Wszystko przed nim służy temu, żeby nie stracić dowodów.
- Zachowaj wiadomość i adres podstawionej strony. Wyeksportuj oryginał z nagłówkami do pliku. Zrób zrzut ekranu strony logowania, jeśli jeszcze działa.
- Ustal, co dokładnie zostało podane i o której. Hasło, kod jednorazowy, dane karty, potwierdzenie w aplikacji. Zapisz godzinę zdarzenia, bo od niej liczysz okno przeglądu logów.
- Odetnij aktywne sesje konta. Wymuś wylogowanie ze wszystkich urządzeń i unieważnij wydane tokeny, w tym te dla aplikacji mobilnych i klientów pocztowych.
- Zmień hasło i wydaj nowy mechanizm uwierzytelniania. Dopiero teraz, bo wcześniejsza zmiana wypycha atakującego, zanim zobaczysz, co robił.
- Przejrzyj ustawienia konta zmienione po godzinie zdarzenia. Reguły przekierowania i automatycznego kasowania poczty, nowe adresy odzyskiwania, dodane authenticatory, hasła aplikacji, klucze dostępu do interfejsu programistycznego.
- Sprawdź, czy z konta wyszły wiadomości do klientów i kontrahentów. Sprawdź też kosz i folder elementów usuniętych, bo reguła atakującego mogła sprzątać po sobie.
- Ostrzeż odbiorców, jeśli wyszła choćby jedna wiadomość o płatności. Zrób to innym kanałem niż zaatakowana skrzynka.
Krok trzeci ma jeden warunek techniczny. Konto musi mieć operację unieważnienia sesji dostępną dla administratora. Jeśli twoja usługa jej nie ma, sprawdź to teraz, a nie w dniu incydentu, bo bez niej zostaje ci wyłączenie konta jako jedyna szybka odpowiedź.
Jak zmierzyć zasięg incydentu z logów?
Zasięg to lista danych i systemów, do których przejęte konto miało dostęp w oknie od podania poświadczenia do odcięcia sesji. Sam fakt logowania niczego jeszcze nie kończy, bo pytanie brzmi, co się w tej sesji wydarzyło.
Przegląd ma odpowiedzieć na sześć pytań:
- kiedy nastąpiło pierwsze logowanie z nierozpoznanego adresu albo klienta;
- czy sesja korzystała z kanału omijającego politykę uwierzytelniania, na przykład starszego protokołu pocztowego;
- jakie pliki i skrzynki zostały otwarte, pobrane albo udostępnione na zewnątrz;
- czy zmieniono reguły poczty, adresy odzyskiwania i powiązane mechanizmy logowania;
- czy z konta wyszły wiadomości i do kogo;
- czy te same poświadczenia zadziałały w innej usłudze firmy.
Ostatnie pytanie decyduje o rozmiarze incydentu. Jedno hasło używane w kilku systemach zamienia przejęcie skrzynki w przejęcie firmy. Przy okazji przeglądu sprawdź, czy zaatakowane konto nie było kontem współdzielonym - w dzienniku widać wtedy rolę, nie człowieka, a ustalenie zasięgu robi się zgadywaniem.
Zapisz wynik jako zwięzłą notatkę z osią czasu, listą dostępów i decyzją, czy doszło do naruszenia ochrony danych osobowych. Ta notatka jest jedynym trwałym efektem incydentu i zarazem materiałem, z którego dokumentujesz sprawę. Ta sama kolejność stoi za klasycznym czterofazowym cyklem obsługi incydentu amerykańskiego NIST: przygotowanie, wykrycie i analiza, ograniczenie oraz odtworzenie, na końcu wnioski. Dokument, który go opisywał (SP 800-61 Rev. 2), został wycofany i zastąpiony wydaniem Rev. 3 z kwietnia 2025 roku, które porządkuje obsługę incydentu wokół zarządzania ryzykiem według Cybersecurity Framework 2.0. Kolejność kroków w praktyce operacyjnej zostaje ta sama, ale po wymagania sięgaj do nowego wydania.
Co zmniejsza liczbę udanych prób?
Szkolenie nie jest zabezpieczeniem, tylko elementem wykrywania. Uczy zgłaszać, a nie rozpoznawać każdy przypadek, bo podstawiona strona wygląda jak prawdziwa i osoba w pośpiechu jej nie odróżni. Sam ekran logowania też niczego nie dowodzi - certyfikat potwierdza tożsamość serwera, a nie uczciwość jego właściciela, o czym piszemy w tekście o tym, co potwierdza certyfikat TLS.
Realnie zmniejszają skuteczność ataku cztery rzeczy:
- Metoda uwierzytelniania odporna na phishing. Amerykański NIST definiuje tę odporność jako cechę protokołu, a nie czujności użytkownika. Poświadczenie związane z domeną usługi nie zadziała na podstawionej stronie. Wybór metody i plan wdrożenia rozpisaliśmy w poradniku o uwierzytelnianiu wieloskładnikowym.
- Uwierzytelnianie nadawcy poczty. Mechanizmy SPF, DKIM i DMARC utrudniają podszycie się pod twoją własną domenę i pozwalają odrzucać takie wiadomości po stronie odbiorcy. Chronią twoich kontrahentów przed wiadomością wyglądającą na twoją.
- Ograniczenie uprawnień pojedynczego konta. Przejęte konto działa w granicach swoich uprawnień, więc od nich zależy zasięg incydentu. Odmowa dostępu po poprawnym zalogowaniu jest osobną warstwą, a jej diagnostykę opisujemy w tekście o odmowie dostępu mimo poprawnego logowania.
- Kanał zgłaszania z krótkim czasem reakcji. Dwie minuty między kliknięciem a zgłoszeniem to inna sprawa niż dwa dni, i to jedyna zmienna, na którą wpływa sam pracownik.
Wszystkie cztery są zadaniami konfiguracyjnymi. Żadne z nich nie jest dokumentem ani zakupem.
Pytania o phishing w firmie
Zmieniłem hasło po kliknięciu, czy to wystarczy?
Nie wystarczy. Sesja wydana przed zmianą hasła może działać dalej, a token aplikacyjny bywa niezależny od hasła. Po zmianie hasła wymuś wylogowanie ze wszystkich urządzeń, unieważnij wydane tokeny i przejrzyj ustawienia konta zmienione po zdarzeniu. Reguła przekierowująca pocztę przetrwa reset hasła bez najmniejszego problemu.
Czy kod z aplikacji uchronił konto przed phishingiem?
Nie uchronił. Kod przepisany na podstawionej stronie działa na prawdziwej, bo atakujący przekazuje go dalej w tej samej próbie. Przed podstawioną stroną broni dopiero poświadczenie związane kryptograficznie z domeną usługi, czyli WebAuthn i oparte na nim klucze. Kod z aplikacji zatrzyma za to kogoś, kto ma wyłącznie hasło z wycieku.
Kiedy incydent phishingowy trzeba zgłosić do UODO?
Wtedy, gdy doszło do naruszenia ochrony danych osobowych. Rozporządzenie 2016/679 w artykule 33 wymaga zgłoszenia bez zbędnej zwłoki, w miarę możliwości nie później niż w terminie 72 godzin od stwierdzenia naruszenia. Ocena konkretnego przypadku należy do administratora danych i inspektora ochrony danych, a nie do działu technicznego.
Co zrobić z oryginalną wiadomością?
Zachowaj ją razem z pełnymi nagłówkami, zanim ktokolwiek ją skasuje. Nagłówki niosą drogę wiadomości i wynik weryfikacji nadawcy, więc bez nich analiza sprowadza się do domysłów. Kopię przekaż zgłoszeniem do zespołu CERT Polska. Sam adres podstawionej strony zapisz osobno w notatce z incydentu.
Czy szkolenie pracowników rozwiązuje problem phishingu?
Nie rozwiązuje. Szkolenie służy temu, żeby zgłoszenie w ogóle poszło i poszło szybko, i na tym kończy się jego rola. Rozpoznanie podstawionej strony przez człowieka jest zawodne, bo kopia wygląda jak oryginał. Problem zamyka się dopiero po stronie technicznej, gdy poświadczenie jest związane z domeną usługi i nie da się go przepisać gdzie indziej.
Od czego zacząć, jeśli nie mamy żadnej procedury?
Od dwóch rzeczy naraz. Napisz jedną stronę z kanałem zgłaszania i kolejnością kroków, a równolegle sprawdź w swojej usłudze, czy administrator ma operację wymuszenia wylogowania i unieważnienia tokenów. Reszta procedury jest bez tej operacji tylko opisem. Szersza mapa decyzji stoi w tekście o pierwszych krokach w bezpieczeństwie firmy.
Źródła
- Rozporządzenie 2016/679 (RODO), artykuły 33 i 34:
https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX%3A32016R0679 - NIST SP 800-63B-4, Authentication and Authenticator Management, odporność na phishing:
https://pages.nist.gov/800-63-4/sp800-63b.html - NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (kwiecień 2025, wydanie aktualne):
https://csrc.nist.gov/pubs/sp/800/61/r3/final - NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide (2012, wycofany, zastąpiony przez Rev. 3 - źródło czterofazowego cyklu):
https://csrc.nist.gov/pubs/sp/800/61/r2/final - RFC 7009, OAuth 2.0 Token Revocation:
https://www.rfc-editor.org/rfc/rfc7009.html - RFC 7208, Sender Policy Framework (SPF):
https://www.rfc-editor.org/rfc/rfc7208.html - RFC 6376, DomainKeys Identified Mail (DKIM):
https://www.rfc-editor.org/rfc/rfc6376.html - RFC 7489, Domain-based Message Authentication, Reporting and Conformance (DMARC):
https://www.rfc-editor.org/rfc/rfc7489.html - CERT Polska, zgłoszenie incydentu:
https://incydent.cert.pl/ - Ustawa o krajowym systemie cyberbezpieczeństwa:
https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20180001560