Odido: vishing „kolega z IT” otworzył dostęp do danych

Odido opisuje wykorzystaną metodę jako voice phishing, czyli vishing — phishing prowadzony przez rozmowę głosową. Firma podaje, że cyberatak dotknął około 6,39 mln osób, w tym aktywnych i nieaktywnych klientów Odido oraz klientów Ben. Zakres danych różnił się między osobami i mógł obejmować dane kontaktowe, numer klienta, adres e-mail, IBAN, datę urodzenia oraz dane identyfikacyjne.

Nowy komunikat policji jest szczególnie przydatny dla security awareness, bo pokazuje coś prostszego niż deepfake czy techniczny exploit. Ekspert głosowy ocenił, że rozmówca używał prawdziwego głosu. Policja zwróciła natomiast uwagę na poprawny niderlandzki, znajomość informatyki i używanie wiarygodnie brzmiącego słownictwa. Dla organizacji oznacza to, że głos, pewność siebie i techniczny język nie mogą zastępować weryfikacji tożsamości rozmówcy.

Co policja ujawniła 7 września

W komunikacie holenderskiej policji z 7 września 2026 opisano rozmowę, która była jednym z kluczowych elementów dochodzenia. Mężczyzna mówiący po niderlandzku zadzwonił do obsługi klienta Odido i przedstawił się jako kolega z działu IT. Powiedział, że trzeba rozwiązać problem, a pracownik nieumyślnie dał mu dostęp do wewnętrznego systemu.

Policja łączy ten sposób wejścia z kradzieżą danych ponad sześciu milionów klientów. Po kradzieży napastnicy zażądali okupu. Odido odmówiło zapłaty, a dane zostały później opublikowane w dark webie, czyli części internetu wykorzystywanej również przez serwisy przestępcze i dostępnej za pomocą specjalnego oprogramowania.

Ten komunikat nie opisuje każdego technicznego kroku logowania ani pełnej ścieżki uwierzytelniania. Nie należy więc dopowiadać, że policja potwierdziła konkretny mechanizm MFA, device code albo określony produkt. Wcześniejsze raportowanie NOS zawierało dodatkowe szczegóły o phishingu i zatwierdzaniu logowania, ale są to informacje z innego źródła i trzeba je odróżnić od zakresu najnowszego komunikatu policji.

Prawdziwy głos zamiast deepfake

Policja podała jeszcze jeden szczegół. Do analizy nagrania zaangażowano eksperta głosowego, który ocenił, że był to prawdziwy głos, a nie głos wygenerowany przez AI.

To istotne, bo w dyskusji o vishingu łatwo skupić się wyłącznie na syntetycznych głosach i deepfake. W tym przypadku nie były potrzebne. Rozmówca miał mówić poprawnie po niderlandzku, używać dość szczegółowego anglojęzycznego słownictwa informatycznego i dzięki temu brzmieć wiarygodnie dla pracownicy centrum obsługi.

Nie wynika z tego, że AI nie stanowi ryzyka w rozmowach socjotechnicznych. Wynika jedynie, że ten konkretny atak nie potrzebował syntetycznego głosu, aby zbudować wiarygodność. Mechanizm był bardziej podstawowy: właściwy pretekst, znajomość środowiska i rozmowa prowadzona tak, aby wyglądała jak normalny kontakt wewnętrzny.

Szerszy opis tego kanału znajdziesz w poradniku co to jest vishing i jak działa w firmie.

Co Odido potwierdza o skali incydentu

Aktualny FAQ Odido dotyczący cyberataku podaje, że pierwsza próba voice phishing miała miejsce 5 lutego, a kolejna 6 lutego. Firma twierdzi, że w obu przypadkach wykryła nieuprawniony dostęp, zbadała zdarzenie i odebrała napastnikowi dostęp. Jednocześnie przyznaje, że konkretny atak prowadzący do wyprowadzenia danych był zaawansowany.

Odido podaje obecnie, że incydent dotknął około 6,39 mln osób. Byli wśród nich aktywni i nieaktywni klienci Odido oraz klienci Ben. Według firmy klienci Simpel nie zostali dotknięci.

Zakres danych nie był identyczny dla każdej osoby. Odido wymienia między innymi:

• imię i nazwisko oraz adres,
• numer telefonu i numer klienta,
• adres e-mail,
• numer rachunku IBAN,
• datę urodzenia,
• dane identyfikacyjne,
• narodowość i płeć.

Firma zaznacza zarazem, że incydent nie obejmował haseł do Mijn Odido, danych połączeń, danych lokalizacyjnych, danych bilingowych ani skanów dokumentów tożsamości. W ograniczonych przypadkach dotknięte mogły być również dodatkowe informacje przekazane wcześniej obsłudze klienta.

Pierwotny komunikat Odido z 12 lutego wskazywał, że dane pochodziły z systemu kontaktu z klientami i że usługi telekomunikacyjne nie zostały zakłócone.

Dlaczego „kolega z IT” brzmi wiarygodnie

Fałszywy dział IT jest skutecznym pretekstem, ponieważ pracownik spodziewa się, że osoba techniczna może pytać o nietypowe zachowanie systemu, prosić o sprawdzenie ustawienia albo prowadzić przez procedurę naprawczą. Sam charakter rozmowy rozszerza zakres działań, które mogą wydawać się normalne.

Ryzyko rośnie, gdy rozmówca:

• zna nazwę firmy i wewnętrzne słownictwo,
• rozumie sposób działania obsługi klienta,
• używa nazw systemów lub typowych terminów technicznych,
• tworzy wiarygodny powód pilnego kontaktu,
• mówi spokojnie i zachowuje się jak osoba, która „wie, co robi”.

W podobnych atakach celem nie jest zwykle przekonanie pracownika do czegoś jawnie absurdalnego. Napastnik próbuje wejść w istniejący proces i przesunąć granicę o jeden krok: zatwierdzić logowanie, zmienić dostęp, otworzyć stronę, zaakceptować urządzenie albo wykonać czynność administracyjną.

PHISHLY opisywało podobny problem procesu w materiale email bombing i fałszywy helpdesk w Teams. Tam kanałem był komunikator i telefon po wcześniejszym zalaniu skrzynki wiadomościami. W Odido istotny jest inny kontekst: połączenie do obsługi klienta i podszycie pod wewnętrzny dział IT.

Moment decyzji: rozmowa przychodząca nie potwierdza tożsamości

Najbardziej użytecznym pytaniem dla organizacji nie jest „czy pracownik rozpoznał oszusta po głosie?”. Lepsze pytanie brzmi: czy proces wymagał niezależnego potwierdzenia, zanim rozmowa mogła doprowadzić do zmiany dostępu?

Telefon przychodzący powinien być traktowany jako kanał kontaktu, a nie dowód tożsamości. Jeśli rozmówca podaje się za wewnętrzne IT i prosi o działanie związane z kontem, systemem lub dostępem, pracownik powinien móc bez konsekwencji:

1. zakończyć rozmowę,
2. znaleźć osobę lub zgłoszenie w znanym firmowym systemie,
3. oddzwonić na numer z katalogu wewnętrznego albo wznowić kontakt przez ustalony kanał,
4. dopiero potem wykonać czynność administracyjną.

Takie podejście jest szczególnie potrzebne w zespołach obsługi klienta, helpdesku, administracji i innych miejscach, gdzie pracownik ma dostęp do danych wielu osób albo może uruchomić działania wpływające na cudze konta.

Jak zabezpieczyć kontakt „IT do pracownika”

Pierwsza kontrola to zweryfikowany callback, czyli oddzwonienie przez numer pochodzący z firmowego katalogu lub systemu zgłoszeniowego. Numer podany przez rozmówcę nie powinien być źródłem tej weryfikacji.

Druga kontrola to powiązanie rozmowy z istniejącym zgłoszeniem. Jeśli dział IT rzeczywiście prowadzi interwencję, pracownik powinien móc zobaczyć numer sprawy, nazwę osoby prowadzącej i zakres planowanego działania w systemie, do którego napastnik nie może dopisać dowolnej historii przez sam telefon.

Trzecia kontrola to ograniczenie działań, których nie wolno zatwierdzić wyłącznie na podstawie rozmowy przychodzącej. Dotyczy to zwłaszcza resetów dostępu, zmian metod uwierzytelniania, dodawania urządzeń, akceptacji nietypowych logowań i działań umożliwiających szeroki odczyt danych.

Czwarta kontrola to ograniczenie uprawnień. Udane oszukanie jednej osoby nie powinno automatycznie otwierać dostępu do ogromnego zbioru danych. Segmentacja uprawnień, krótkotrwały dostęp administracyjny i limity eksportu zmniejszają skutki pojedynczej błędnej decyzji.

Piąta kontrola to monitoring zachowania po uzyskaniu dostępu. Nietypowy wolumen odczytu, masowy eksport, nowa sesja z nietypowej lokalizacji lub szybkie przeglądanie wielu rekordów powinny tworzyć sygnał do weryfikacji.

Dlaczego szkolenie nie może kończyć się na „nie podawaj hasła”

Wiele programów security awareness nadal koncentruje się na podejrzanych linkach i załącznikach. Przypadek Odido pokazuje, że pracownik może wejść w ryzykowną sytuację nawet wtedy, gdy rozmowa wygląda jak normalna pomoc techniczna.

Ćwiczenie powinno sprawdzać decyzję, nie pamięć definicji. Scenariusz może zaczynać się od telefonu od rzekomego IT i badać, czy pracownik:

• prosi o numer zgłoszenia,
• potwierdza osobę przez niezależny kanał,
• odmawia zatwierdzenia dostępu tylko dlatego, że rozmówca używa technicznego języka,
• zgłasza podejrzany kontakt,
• rozumie, które działania wymagają drugiej osoby lub dodatkowej autoryzacji.

W tym sensie przypadek Odido jest bliski temu, co pokazuje artykuł Levi Strauss: social engineering przeciw trzem pracownikom: napastnik nie musi oszukać całej organizacji. Wystarczy, że trafi na osobę osadzoną w procesie, który daje dostęp do wartościowego systemu.

Jeżeli chcesz sprawdzić takie zachowania w kontrolowanym środowisku, testy phishingowe dla firm powinny obejmować nie tylko e-mail, ale też scenariusze z telefonem, helpdeskiem i próbą obejścia normalnej weryfikacji.

Co zrobić po podejrzanym telefonie od IT

Pracownik nie powinien prowadzić własnego dochodzenia podczas rozmowy. Wystarczy kilka prostych działań:

• przerwać kontakt bez wykonywania żądanej czynności,
• nie używać numeru ani linku podanego przez rozmówcę do potwierdzenia jego tożsamości,
• sprawdzić sprawę w firmowym systemie zgłoszeń lub katalogu,
• skontaktować się z działem IT albo zespołem bezpieczeństwa przez znany kanał,
• zgłosić, co rozmówca wiedział i o co dokładnie prosił.

Jeśli pracownik zdążył już zatwierdzić logowanie, zmianę dostępu albo inną nietypową czynność, zgłoszenie powinno nastąpić od razu. Im wcześniej zespół bezpieczeństwa wie, co zostało wykonane, tym szybciej może odebrać dostęp, unieważnić sesję i sprawdzić aktywność konta.

Co z tego przypadku wynika dla organizacji

Odido nie jest przykładem „ataku bez technologii”. Po skutecznym kontakcie telefonicznym napastnicy nadal potrzebowali dostępu do systemu i możliwości wyprowadzenia danych. Punkt wejścia pokazuje jednak, że nawet rozbudowane środowisko techniczne może zostać otwarte przez decyzję podjętą podczas rozmowy.

Dlatego ochrona powinna łączyć trzy warstwy:

• tożsamość: kto naprawdę inicjuje kontakt i jak to potwierdzamy,
• proces: jakie działania są dopuszczalne po rozmowie przychodzącej,
• technologia: jak ograniczamy zakres dostępu i wykrywamy nietypowe użycie konta.

Policja ujawniła głos podejrzanego, aby zwiększyć szansę jego identyfikacji. Dla firm bardziej uniwersalny wniosek jest inny: nie trzeba rozpoznawać oszusta po głosie, jeśli proces nie pozwala niezweryfikowanemu rozmówcy otworzyć drogi do systemu.