„PREZESIE, PROSZĘ PILNIE ZATWIERDZIĆ PRZELEW”. GŁOS BRZMI DOKŁADNIE JAK GŁOS CZŁONKA ZARZĄDU. TO DEEPFAKE.

Telefon.

Znany numer.

Znajomy głos.

Pilne polecenie:

„Proszę natychmiast zatwierdzić przelew. Nie mamy czasu.”

Jeszcze kilka lat temu znajomy głos mógł być dodatkowym potwierdzeniem tożsamości rozmówcy.

Dziś już nie.

Deepfake w banku może być wykorzystany do stworzenia bardzo przekonującego nagrania głosu, obrazu lub wiadomości imitującej Prezesa, Członka Zarządu, pracownika albo kontrahenta.

W praktyce oznacza to jedno:

głos, obraz i poprawnie napisana wiadomość nie mogą być jedynym dowodem autentyczności polecenia.

Bank powinien traktować deepfake nie tylko jako zagrożenie techniczne, ale również jako ryzyko operacyjne związane z autoryzacją decyzji, płatności i dostępu.

Deepfake w banku zmienia zasady socjotechniki

Klasyczny phishing często zdradzał się błędami językowymi, nietypową treścią albo podejrzanym adresem.

AI coraz częściej eliminuje te sygnały.

Atak może być:

• poprawny językowo,
• dopasowany do stanowiska pracownika,
• oparty na prawdziwych nazwiskach,
• osadzony w kontekście bieżących spraw banku,
• wykonany głosem przypominającym konkretną osobę.

Najważniejsze pytanie nie powinno więc brzmieć:

„Czy ten głos brzmi prawdziwie?”

ale:

„Czy polecenie zostało potwierdzone zgodnie z procedurą?”

Presja czasu to jeden z najważniejszych sygnałów ostrzegawczych

Atakujący chce ograniczyć czas na zastanowienie.

Dlatego pojawiają się komunikaty:

„Pilne.”

„Zrób to teraz.”

„Nie dzwoń do nikogo.”

„To decyzja Zarządu.”

„Sprawa jest poufna.”

Połączenie autorytetu i presji czasu może spowodować, że pracownik ominie standardową procedurę.

Właśnie dlatego procedura powinna działać również wtedy, gdy polecenie pochodzi rzekomo od Prezesa.

Drugi kanał powinien być standardem

Jednym z najskuteczniejszych mechanizmów obrony jest potwierdzenie polecenia niezależnym kanałem.

Przykład:

Pracownik otrzymuje telefon z poleceniem pilnego przelewu.

Nie oddzwania na numer podany przez rozmówcę.

Kontaktuje się z osobą wydającą polecenie przez wcześniej znany i niezależny kanał.

Dopiero wtedy wykonuje dalsze działania.

Prosta zasada:

ważne polecenie → drugi kanał → potwierdzenie → wykonanie

może zatrzymać bardzo zaawansowany atak.

Zasada czterech oczu nadal ma ogromne znaczenie

Im większe ryzyko operacji, tym trudniej powinno być jej wykonanie przez jedną osobę.

Warto stosować:

• limity kwotowe,
• podwójną autoryzację,
• rozdział obowiązków,
• niezależne potwierdzenie nietypowej dyspozycji,
• dodatkową weryfikację zmian rachunku odbiorcy.

Deepfake nie powinien umożliwiać obejścia tych mechanizmów.

Jeżeli procedura jest zawieszana tylko dlatego, że „Prezes dzwoni osobiście”, to właśnie tę słabość może wykorzystać atakujący.

Co powinien zrobić pracownik?

Jeżeli pojawia się choć cień wątpliwości:

zatrzymać operację.

Następnie:

• zweryfikować polecenie drugim kanałem,
• nie wykonywać kolejnych instrukcji atakującego,
• zabezpieczyć wiadomość lub dane połączenia,
• zgłosić zdarzenie zgodnie z procedurą,
• przekazać informację do IT, SOC lub ABI.

Najważniejsza zasada:

lepiej zatrzymać prawidłową operację na kilka minut niż wykonać fałszywą dyspozycję nieodwracalnie.

Co robi SOC, IT i ABI po zgłoszeniu?

Zgłoszenie nie powinno kończyć się stwierdzeniem:

„to był tylko podejrzany telefon”.

Należy sprawdzić:

• czy podobne próby otrzymali inni pracownicy,
• czy doszło do przejęcia skrzynki pocztowej,
• czy atakujący posiada informacje wewnętrzne,
• czy używany jest prawdziwy numer lub spoofing,
• czy pojawiły się podobne wiadomości,
• czy należy ostrzec innych pracowników.

Jedna próba może być elementem większego ataku.

Najlepszy test? Spróbować oszukać własną procedurę

Krótki test socjotechniczny może pokazać więcej niż wielostronicowa instrukcja.

Scenariusz może być prosty:

„Członek Zarządu pilnie prosi o wykonanie nietypowej operacji.”

Następnie sprawdzamy:

• czy pracownik zatrzymał działanie,
• czy zastosował drugi kanał,
• czy uruchomił zasadę czterech oczu,
• czy zgłosił próbę,
• czy informacja trafiła do właściwych osób.

Nie chodzi o „złapanie” pracownika.

Chodzi o sprawdzenie, czy procedura działa pod presją.

Podsumowanie

Deepfake zmienia jedną z podstawowych zasad zaufania:

znajomy głos nie oznacza już pewnej tożsamości.

Bank powinien więc budować bezpieczeństwo na procesie, a nie na intuicji pracownika.

Najprostszy model:

STOP → WERYFIKACJA → DRUGI KANAŁ → POTWIERDZENIE → DECYZJA

Jeżeli procedura działa również wtedy, gdy rzekome polecenie wydaje Prezes, bank jest znacznie trudniejszym celem.

Pytania i odpowiedzi

Czy deepfake głosowy może brzmieć jak konkretna osoba?

Tak. Technologia pozwala tworzyć nagrania naśladujące głos konkretnej osoby, dlatego sam głos nie powinien być traktowany jako wystarczające potwierdzenie tożsamości.

Jak najlepiej potwierdzić podejrzane polecenie?

Przez niezależny, wcześniej znany kanał kontaktu, np. osobny numer telefonu lub inny zatwierdzony kanał komunikacji.

Czy zasada czterech oczu chroni przed deepfake?

Znacznie ogranicza ryzyko, ponieważ wykonanie operacji wymaga udziału kolejnej osoby i dodatkowej weryfikacji.

Co powinien zrobić pracownik, gdy podejrzewa deepfake?

Zatrzymać operację, zweryfikować polecenie drugim kanałem i zgłosić zdarzenie zgodnie z procedurą banku.

Czy deepfake dotyczy tylko przelewów?

Nie. Może być wykorzystywany do uzyskania danych, zmiany konfiguracji, resetowania haseł, zatwierdzania dostępu albo nakłaniania pracownika do wykonania innych działań.

Jak sprawdzić, czy bank jest gotowy na taki atak?

Najlepiej przeprowadzić kontrolowany test socjotechniczny i sprawdzić, czy pracownicy stosują procedury także pod presją czasu i autorytetu.

Czy pracownik Twojego banku zatrzymałby taki przelew?

To pytanie warto zadać zanim zrobi to atakujący.

Jeżeli chcesz sprawdzić, czy procedury weryfikacji poleceń, zasada czterech oczu, ścieżka zgłoszenia oraz reakcja SOC, IT i ABI rzeczywiście działają, skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

• przygotowaniu scenariuszy deepfake i phishing AI,
• testach socjotechnicznych,
• weryfikacji procedur zatwierdzania operacji,
• projektowaniu drugiego kanału potwierdzenia,
• budowie zasad eskalacji,
• szkoleniach pracowników i Zarządu,
• ocenie reakcji SOC, IT i ABI.

Servus Comp Kraków
Bezpieczeństwo • Odporność • Ryzyko ICT • Zgodność

Polecane wpisy dla banków spółdzielczych

Zapraszamy również do zapoznania się z innymi materiałami przygotowanymi z myślą o Zarządach i pracownikach banków spółdzielczych, osobach odpowiedzialnych za bezpieczeństwo informacji, ICT, DORA, zgodność i zarządzanie ryzykiem.

1. 1. AUDYT ZA PARĘ SREBRNIKÓW CZY AUDYT, KTÓRY WYTRZYMA PYTANIA SOZ, KNF I BIEGŁEGO REWIDENTA?
   2. SOC nie widzi wszystkiego. Czy bank zna swoje ślepe punkty?
   3. Awaria już trwa – co bank odtwarza jako pierwsze i kto o tym decyduje?
   4. Zostałeś ABI. I co teraz?
   5. „ATAKUJĄ BANKI”. THREAT INTELLIGENCE OSTRZEGA – CO ROBI BANK?
   6. DORA, RTS, EBA, KNF – Jak nie pogubić się w wytycznych i wiedzieć, co naprawdę wdrożyć?
   7. Bank ma procedury. Audytor pyta: „proszę pokazać, że one działają”.
   8. Dostawca nie działa. Bank też. Czy tak miało być?
   9. Exit plan dostawcy a exit plan banku – czy strategia wyjścia naprawdę chroni interes banku?
   10. Umowa chroni dostawcę. A kto chroni bank?
   11. Backup mówi „SUCCESS”. Ransomware mówi „SPRAWDZAM”
   12. Podatność jest critical. Ale czy naprawdę jest najważniejsza?
   13. SOC widzi alert. Ale czy wie, co jest ważne dla banku?
   14. Prezesie, proszę pilnie zatwierdzić przelew. Głos brzmi dokładnie jak głos członka zarządu. To deepfake.
   15. Ocena ryzyka ICT przez KNF wypadła słabo. Co teraz?
   16. Ransomware w banku i inne kryzysy – testy stolikowe i scenariuszowe: czy bank naprawdę potrafi działać?
   17. INCYDENT O 15:47. PREZES PYTA: „CO ROBIMY?” – KTO W BANKU ZNA ODPOWIEDŹ?
   18. DORA I RTS bez BIA to nie wdrożenie. To chaos bez priorytetów.
   19. BIA w banku spółdzielczym – jak przygotować analizę krok po kroku?
   20. Zarząd pyta IT: „Czy jesteśmy bezpieczni?” – czy odpowiedź „tak” cokolwiek znaczy?
   21. PAM w banku spółdzielczym – JumpServer, DORA i kontrola dostępu uprzywilejowanego
   22. Bank bez systemu PAM? JumpServer – bezpłatna ochrona dostępu uprzywilejowanego dla banków spółdzielczych
   23. Skan to za mało. Jakie testy penetracyjne powinien zlecić bank spółdzielczy, żeby nie usłyszeć tego na audycie?
   24. Wysadzenie bankomatu to nie tylko szkoda. To test procedur Banku
   25. 10 wybranych najważniejszych zaleceń KNF po ocenie ryzyka ICT 2025 — praktyczne podsumowanie dla banków spółdzielczych
   26. Dokument jest? KNF zapyta o dowód, że działa
   27. Znalazłeś podatność? KNF zapyta, kiedy ją usunąłeś
   28. Raport ICT do Zarządu — KNF pyta, kto nadzoruje ryzyko ICT w Banku
   29. Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT
   30. Skan podatności to nie test odporności. KNF zapyta, czy Bank naprawdę testuje ICT

Zadzwoń lub napisz do Servus Comp, aby omówić temat.

• Strona główna: https://premiumbank.zadbajobezpieczenstwo.pl

Servus Comp Data Security, Świętokrzyska 12/403, 30-015 Kraków

tel. +48 608 407 668, +48 12 631 91 22 • biuro@servus-comp.pl

PODEJMIEMY DLA PAŃSTWA KAŻDE WYZWANIE!

JESTEŚ ZAINTERESOWANY? ZADZWOŃ, NAPISZ DO NAS

#Deepfake #DeepfakeWBanku #PhishingAI #BankSpółdzielczy #Socjotechnika #SztucznaInteligencja #Cyberbezpieczeństwo #FałszywePolecenie #BezpieczeństwoPrzelewów #ZasadaCzterechOczu #DrugiKanałWeryfikacji #SOC #ABI #ASI #DORA #BezpieczeństwoBanku #ServusCompKraków