Archiwa: Ransomware - Strona 62 z 87 - Security Bez Tabu

Tag: Ransomware

Wyciek danych w Aflac: 22,65 mln osób z narażonymi danymi osobowymi i medycznymi po incydencie z czerwca 2025

Wprowadzenie do problemu / definicja luki

Aflac (duży ubezpieczyciel w USA) potwierdził, że w wyniku cyberataku z czerwca 2025 r. doszło do kradzieży (ekfiltracji) wrażliwych danych powiązanych z ok. 22,65 mln osób. To istotne, bo zestaw wykradzionych informacji obejmuje nie tylko dane identyfikacyjne, ale też elementy danych zdrowotnych i ubezpieczeniowych, które w połączeniu są szczególnie atrakcyjne dla przestępców.

W skrócie

  • Aflac wykrył podejrzaną aktywność 12 czerwca 2025 r., a incydent publicznie ujawnił 20 czerwca 2025 r.
  • Po zakończeniu wielomiesięcznego przeglądu plików firma ustaliła, że naruszenie dotyczy ok. 22,65 mln osób.
  • Skala danych: m.in. imiona i nazwiska, adresy, daty urodzenia, numery dokumentów, numery SSN oraz informacje medyczne/roszczeniowe i ubezpieczeniowe.
  • Firma podkreśla, że ransomware szyfrujące pliki nie zostało wdrożone, a atak miał charakter kradzieży danych.
  • Aflac oferuje poszkodowanym 24 miesiące usług ochrony (monitoring kredytowy / ochrona przed kradzieżą tożsamości oraz elementy ochrony przed nadużyciami medycznymi).

Kontekst / historia / powiązania

W czerwcu 2025 r. Aflac komunikował, że incydent wpisuje się w szerszą kampanię wymierzoną w branżę ubezpieczeniową i że został zatrzymany „w ciągu godzin”. W grudniu (tuż przed świętami) firma przekazała, że zakończyła analizę potencjalnie naruszonych plików i rozpoczęła proces notyfikacji osób oraz regulatorów stanowych.

W doniesieniach medialnych pojawia się hipoteza o możliwych związkach sprawców z rozpoznawalną grupą cyberprzestępczą atakującą ubezpieczycieli (często wskazywana jest „Scattered Spider”), ale Aflac nie przypisał ataku jednoznacznie w swoich publicznych komunikatach.

Analiza techniczna / szczegóły incydentu

Z perspektywy „łańcucha incydentu” (bez wchodzenia w niepotwierdzone szczegóły TTP) mamy kilka twardych faktów:

  1. Wykrycie i reakcja
    Aflac wykrył podejrzaną aktywność na sieci w USA 12 czerwca 2025 r. i deklaruje, że incydent został szybko opanowany, z udziałem zewnętrznych ekspertów IR.
  2. Ekfiltracja danych zamiast szyfrowania
    Firma wskazuje, że nie doszło do uruchomienia ransomware szyfrującego, co w praktyce często oznacza scenariusz „data theft / extortion-ready”, gdzie główną wartością dla napastnika jest kopiowanie danych.
  3. Zakres danych (co wyciekło)
    W komunikatach i opisach dla regulatorów wymieniane są m.in.:
  • dane identyfikacyjne (imiona i nazwiska, adresy, daty urodzenia),
  • numery dokumentów (np. prawo jazdy, państwowe identyfikatory),
  • SSN,
  • oraz informacje medyczne i ubezpieczeniowe/roszczeniowe (claims/health/insurance).
  1. Skala ustalona po czasie
    W czerwcu 2025 r. Aflac raportował, że dopiero rozpoczyna przegląd plików i nie zna liczby osób dotkniętych incydentem. Dopiero po miesiącach potwierdzono poziom ~22,65 mln.

Praktyczne konsekwencje / ryzyko

Połączenie SSN + daty urodzenia + adresu + danych dokumentów oraz elementów zdrowotnych/ubezpieczeniowych podnosi ryzyko w kilku wymiarach:

  • Kradzież tożsamości i nadużycia finansowe: otwieranie kont/pożyczek, „account takeover”, wyłudzanie świadczeń.
  • Oszustwa „medyczne” i ubezpieczeniowe: np. podszywanie się pod ubezpieczonego w procesach rozliczeń/roszczeń (dlatego Aflac komunikuje komponent ochrony przed fraudem medycznym).
  • Phishing i socjotechnika wysokiej jakości: dane o relacji z ubezpieczycielem pozwalają budować wiarygodne scenariusze (wezwania do dopłaty, „weryfikacja roszczenia”, „zwrot składki”).

Rekomendacje operacyjne / co zrobić teraz

Jeśli jesteś osobą, której dane mogły wyciec

  1. Skorzystaj z oferowanych usług ochrony (jeśli otrzymasz list/notyfikację) i pilnuj komunikacji od firmy tylko oficjalnymi kanałami.
  2. Rozważ zamrożenie kredytu i/lub alerty w biurach informacji kredytowej (w USA to standardowy „next step” po wycieku SSN).
  3. Monitoruj: raporty kredytowe, korespondencję z instytucji finansowych, a także dokumenty/rozliczenia medyczne i ubezpieczeniowe (nietypowe roszczenia, „EOB” itp.).
  4. Uważaj na phishing: nie klikaj w linki z SMS/e-mail „o dopłacie do polisy” czy „potwierdzeniu roszczenia”; weryfikuj numer infolinii na oficjalnej stronie.

Jeśli jesteś organizacją (ubezpieczenia/finanse/ochrona zdrowia)

  • Traktuj scenariusz szybkiej ekfiltracji jako priorytet: DLP, segmentacja, minimalizacja uprawnień, monitoring anomalii dostępu do repozytoriów danych.
  • Wzmocnij procesy IAM: MFA odporne na phishing (FIDO2/WebAuthn), kontrola sesji, detekcja podejrzanych logowań i „impossible travel”.
  • Zadbaj o „breach readiness”: gotowe playbooki (IR), kanały komunikacji do klientów, szybka ścieżka do regulatorów oraz rzetelny proces ustalania zakresu (tak, aby nie ciągnąć niepewności miesiącami).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Warto zwrócić uwagę na różnicę między:

  • klasycznym ransomware (szyfrowanie + przestój operacyjny), a
  • incydentem typu “data theft”, gdzie firma może działać „normalnie”, ale skutki długoterminowe przenoszą się na klientów i ryzyko fraudów.

Aflac podkreśla brak szyfrowania i brak zakłóceń operacyjnych, co pasuje do drugiego scenariusza.

Podsumowanie / kluczowe wnioski

  • Incydent Aflac to przykład, że szybkie opanowanie ataku nie wyklucza kradzieży danych – zakres ustala się często dopiero po długiej analizie.
  • Wykradzione dane (w tym SSN i informacje zdrowotne/ubezpieczeniowe) tworzą bardzo „wartościowy pakiet” dla przestępców i zwiększają ryzyko długofalowych nadużyć.
  • Dla branży ubezpieczeniowej to kolejny sygnał, że trzeba projektować ochronę nie tylko pod kątem dostępności usług, ale przede wszystkim pod kątem ograniczania ekfiltracji.

Źródła / bibliografia

  1. SecurityWeek – „22 Million Affected by Aflac Data Breach” (SecurityWeek)
  2. SEC (EDGAR) – raport Aflac z 20 czerwca 2025 (wczesna faza oceny, możliwe kategorie danych) (SEC)
  3. TechCrunch – informacje o zgłoszeniach do regulatorów stanowych i kategoriach danych (TechCrunch)
  4. Associated Press – kontekst wykrycia i oferowane 24-miesięczne usługi ochronne (AP News)
  5. The Record (Recorded Future News) – potwierdzenie skali, brak ransomware, notyfikacje regulatorów (The Record from Recorded Future)

Atak ransomware na Marquis Software: jak incydent dostawcy uderzył w banki i klientów (przypadek VeraBank i Artisans’ Bank)

Wprowadzenie do problemu / definicja luki

Incydenty typu third-party breach (naruszenie u dostawcy) coraz częściej wywołują największe szkody nie tam, gdzie doszło do włamania, ale u klientów dostawcy. W końcówce 2025 r. dobrym przykładem stał się atak ransomware na Marquis Software Solutions – firmę świadczącą usługi marketingowe, komunikacyjne i analityczne dla banków oraz unii kredytowych. Dwie kolejne instytucje – VeraBank i Artisans’ Bank – oficjalnie poinformowały klientów, że ich dane mogły zostać skopiowane właśnie z systemów dostawcy, a nie z systemów banku.

W skrócie

  • Kiedy: wykrycie podejrzanej aktywności i potwierdzenie ataku ransomware – 14 sierpnia 2025.
  • Wektor: dostęp przez urządzenie SonicWall (firewall/VPN) i możliwa kradzież plików.
  • Skala: Marquis informował, że między 27.10 a 25.11 powiadomił co najmniej 74 instytucje finansowe o potencjalnym objęciu danych incydentem.
  • Rodzaje danych: m.in. imię i nazwisko, adres, telefon, SSN/TIN, data urodzenia oraz wybrane dane o rachunkach (bez kodów dostępu).
  • Downstream victims: Artisans’ Bank wskazał naruszenie danych (w tym SSN) ok. 32 344 osób, a w przypadku VeraBank zgłoszono łącznie 37 318 poszkodowanych (szczegóły danych nie zostały ujawnione w listach).

Kontekst / historia / powiązania

Marquis działa jako zewnętrzny dostawca dla sektora finansowego (marketing, komunikacja z klientem, analityka). To ważne, bo takie firmy zwykle przetwarzają „niepubliczne dane osobowe” (PII/NPI) w imieniu banków – często w formie eksportów, list mailingowych, segmentów marketingowych czy danych do personalizacji komunikacji.

W przypadku VeraBank wprost opisano rolę Marquis jako dostawcy „customer communication and data analysis vendor” – czyli podmiotu, który miał dostęp do danych klientów m.in. po to, by kierować komunikaty i dopasowywać ofertę.

Jednocześnie to typ relacji, w którym:

  • bank może mieć świetną ochronę własnej infrastruktury,
  • ale ryzyko przenosi się na dojrzałość bezpieczeństwa dostawcy i jego „perimeter” (firewall/VPN).

Analiza techniczna / szczegóły luki

Z dokumentów i doniesień wynika spójny łańcuch zdarzeń:

  1. Initial access przez SonicWall
    Marquis wskazał, że nieuprawniona osoba uzyskała dostęp do sieci przez ich firewall SonicWall 14.08.2025 i mogła pozyskać wybrane pliki.
  2. Ransomware + komponent exfiltracyjny
    W komunikacji regulatorom opisano incydent jako ransomware attack. To istotne, bo nowoczesne kampanie ransomware często łączą szyfrowanie z kradzieżą danych (double extortion), co tłumaczy późniejsze powiadomienia banków i klientów.
  3. Zakres danych i model „data owner”
    W dokumentach podkreślano, że Marquis występuje „w imieniu” klientów biznesowych (banków/credit unions) będących właścicielami danych. Potencjalnie objęte dane to m.in.:
  • identyfikatory osobowe i kontaktowe (imię, adres, telefon),
  • identyfikatory podatkowe,
  • SSN,
  • daty urodzenia,
  • pewne informacje o rachunkach bez kodów dostępu.
  1. Brak publicznego przypisania sprawcy
    Nie ma potwierdzonej grupy, która publicznie wzięłaby odpowiedzialność; Check Point Research wskazywał, że Akira mogła być potencjalnie powiązana z podobnymi nadużyciami dotyczących SonicWall, ale jest to ostrożna atrybucja („possibly”).

Praktyczne konsekwencje / ryzyko

Dla banków i unii kredytowych

  • Ryzyko tożsamościowe klientów: SSN/TIN + dane kontaktowe i daty urodzenia to zestaw, który sprzyja fraudom i przejęciom kont (także poza bankowością).
  • Koszty powiadomień i usług ochronnych: w materiałach pojawia się oferowanie monitoringu/ochrony tożsamości (np. modele „complimentary monitoring”).
  • Ryzyko regulacyjne i reputacyjne: nawet jeśli systemy banku nie zostały naruszone, klienci postrzegają incydent jako „wyciek z banku”.

Dla klientów

  • spear-phishing pod konkretny bank (atakujący zna instytucję, czasem segment klientów),
  • próby wyłudzeń kredytowych/pożyczkowych,
  • podszywanie się w procesach KYC.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie „domykają” klasę ryzyka widoczną w tym incydencie.

Dla instytucji finansowych (zarządzanie dostawcami)

  1. Inwentaryzacja danych u dostawców (data mapping)
    Które systemy, jakie eksporty, jaki zakres PII, jak długo przechowywane? (Szczególnie dla vendorów od marketingu/komunikacji).
  2. Minimalizacja danych i ograniczenia retencji
    Jeśli do kampanii marketingowej wystarczy segment i kanał kontaktu – nie wysyłaj pełnych identyfikatorów.
  3. Wymuszenie wymogów bezpieczeństwa w umowie (i ich audytowalność)
    • patch management na urządzeniach brzegowych,
    • MFA/conditional access do paneli i VPN,
    • EDR + centralne logowanie,
    • segmentacja sieci i separacja środowisk klientów.
  4. Plan na „vendor breach”
    Gotowe szablony komunikacji i procedury „kto, kiedy, jak” (regulator, klienci, call center, FAQ).

Dla dostawców technologii/usług (hardening perimeter)

  • Priorytet dla urządzeń brzegowych (firewall/VPN): szybkie łatki, ograniczenie ekspozycji, monitoring logów i anomalii. (W tym przypadku wprost wskazano SonicWall jako punkt wejścia).
  • Segmentacja i zasada najmniejszych uprawnień dla repozytoriów z danymi klientów.
  • DLP i kontrola exfiltracji (proxy, egress filtering, alerty na nietypowe transfery).

Dla klientów końcowych (jeśli dostali powiadomienie)

  • Włącz monitoring kredytowy/ochronę tożsamości, jeśli jest oferowana.
  • Ustaw alerty transakcyjne w banku, rozważ zamrożenie kredytu (credit freeze) i uważaj na „pilne” telefony/SMS-y o rzekomym incydencie.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Ten incydent dobrze pokazuje różnicę między:

  • włamaniem do banku (zwykle szybciej widać nadużycia kont, ryzyko operacyjne jest natychmiastowe),
  • a włamaniem do dostawcy (często opóźnione wykrycie wpływu, długi „ogon” powiadomień, trudniejsza ocena skali).

W praktyce „vendor breach” bywa bardziej destrukcyjny reputacyjnie, bo dotyka wielu instytucji naraz i tworzy efekt domina (jedna luka → dziesiątki banków).

Podsumowanie / kluczowe wnioski

  • Atak ransomware na Marquis Software to klasyczny przykład ryzyka łańcucha dostaw w finansach: pojedynczy dostawca przetwarzający dane klientów staje się wspólnym punktem awarii.
  • Wektor wejścia (SonicWall) przypomina, że perimeter nadal bywa najsłabszym ogniwem – zwłaszcza gdy łatki i kontrola dostępu nie są bezwzględnie egzekwowane.
  • Nawet gdy banki podkreślają, że ich systemy nie zostały naruszone, konsekwencje (powiadomienia, monitoring, ryzyko fraudów) są bardzo realne.

Źródła / bibliografia

  1. The Record (Recorded Future News): informacje o VeraBank i Artisans’ Bank oraz kontekście incydentu Marquis. (The Record from Recorded Future)
  2. Reuters: podsumowanie incydentu i opis wektora (SonicWall) na bazie zgłoszeń do regulatora. (Reuters)
  3. Washington State Office of the Attorney General – dokument (PDF) z opisem incydentu, zakresem danych i harmonogramem powiadomień.
  4. California DOJ (OAG) – wpis o próbce zgłoszenia incydentu (Marquis jako podmiot składający). (California Attorney General)
  5. Check Point Research – wzmianka w raporcie threat intelligence (kontekst i ostrożna atrybucja). (Check Point Research)

Atak ransomware na Marquis Software: kolejne banki ujawniają wyciek danych klientów

Wprowadzenie do problemu / definicja luki

Incydenty „supply chain” i „third-party breach” coraz częściej uderzają w sektor finansowy nie przez bezpośrednie włamanie do banku, ale przez dostawcę usług, który przetwarza dane klientów w imieniu instytucji. Dokładnie taki scenariusz rozgrywa się w sprawie Marquis Software (fintech/dostawca usług marketingowo-analitycznych i compliance dla banków oraz credit unions w USA), gdzie atak ransomware z sierpnia 2025 r. przełożył się na kolejne ujawnienia wycieków po stronie banków – już jako „downstream victims”.

W skrócie

  • Dwa kolejne banki – Artisans’ Bank i VeraBank – poinformowały o skutkach incydentu u dostawcy Marquis Software.
  • Atak wykryto 14 sierpnia 2025 r.; według ustaleń doszło do nieautoryzowanego dostępu do plików zawierających dane klientów instytucji finansowych.
  • Wątek techniczny prowadzi do urządzenia SonicWall i podatności powiązanych z CVE-2024-40766, która była traktowana jako realnie wykorzystywana w atakach (m.in. wpisy CISA/KEV i komunikaty SonicWall o aktywności SSLVPN).
  • Skala (wg zestawień z zawiadomień do urzędów stanowych) sięga ~788 tys. osób dotkniętych naruszeniem u Marquis.

Kontekst / historia / powiązania

Z perspektywy banków kluczowe jest to, że dostawca (Marquis) pełni rolę „procesora danych” dla wielu instytucji, m.in. w obszarze komunikacji z klientami oraz analizy danych i dopasowania produktów. VeraBank wprost wskazywał Marquis jako dostawcę „customer communication and data analysis vendor”.

W grudniu 2025 r. pojawiła się kolejna fala notyfikacji – tym razem od samych banków. The Record opisał m.in.:

  • VeraBank: łączna liczba osób z ujawnionymi danymi w tej sprawie to 37 318 (wg opisu w materiale).
  • Artisans’ Bank: bank wskazał, że dowiedział się o incydencie od Marquis w październiku 2025 r., a w jego przypadku chodzi m.in. o imiona i numery SSN (Social Security Numbers) 32 344 osób.

Co istotne komunikacyjnie (i prawnie): oba banki podkreślały, że ich własne systemy nie zostały zhakowane, a problem dotyczy danych „utrzymywanych przez Marquis”.

Analiza techniczna / szczegóły luki

1) Punkt wejścia: SonicWall i „znana” podatność

Reuters i inne źródła opisują, że intruz wykorzystał podatność w zaporze SonicWall 14 sierpnia 2025 r., uzyskując możliwość dostępu do wybranych plików w środowisku Marquis.

W ekosystemie SonicWall szeroko przywoływana jest podatność CVE-2024-40766:

  • CISA dodała ją do katalogu Known Exploited Vulnerabilities (KEV) już 9 września 2024 r., co jest mocnym sygnałem, że podatność była wykorzystywana „in the wild” i powinna być traktowana priorytetowo w patchingu.
  • SonicWall w komunikacie o aktywności SSLVPN (aktualizacje z sierpnia 2025) wskazywał korelację obserwowanych incydentów z aktywnością powiązaną z CVE-2024-40766 oraz rekomendował m.in. aktualizacje i reset haseł (zwłaszcza po migracjach Gen6→Gen7).

2) Co mogło zostać pozyskane

Zakres danych, które mogły zostać przejęte w wyniku dostępu do plików Marquis, obejmuje typowe atrybuty do kradzieży tożsamości i nadużyć finansowych: imię i nazwisko, adres, telefon, data urodzenia, SSN/TIN, a także wybrane informacje o rachunkach (w tym bez „security/access codes”).

3) Czas wykrycia i „długi ogon” notyfikacji

SecurityWeek wskazuje, że incydent wykryto 14 sierpnia 2025 r., a analiza dot. skradzionych danych trwała do końca października, po czym ruszyły formalne notyfikacje do osób i urzędów stanowych.
To klasyczny wzorzec: techniczny „blast radius” bywa jasny szybko, ale ustalenie dokładnej listy danych i podmiotów (kto, z jakiego banku, jaki zakres pól) potrafi zająć tygodnie.

Praktyczne konsekwencje / ryzyko

Dla klientów banków tego typu incydent jest groźny nie tylko ze względu na sam wyciek, ale ze względu na jakość danych (identyfikatory + dane kontaktowe), które:

  • ułatwiają phishing i vishing „pod bank” (oszust ma wystarczająco dużo atrybutów, by brzmieć wiarygodnie),
  • zwiększają ryzyko przejęcia kont (zwłaszcza gdy atakujący łączy wyciek z danymi z innych naruszeń),
  • otwierają drogę do kradzieży tożsamości (SSN/TIN + data urodzenia + adres).

Dla banków to także ryzyko:

  • regulacyjne (obowiązki notyfikacyjne, nadzór),
  • reputacyjne (klient widzi „to bank wyciekł”, nawet jeśli to vendor),
  • operacyjne (koszty monitoringu kredytowego, call center, obsługi incydentu).

Rekomendacje operacyjne / co zrobić teraz

Dla banków i instytucji finansowych (IT/Sec/Compliance)

  1. Natychmiastowa rewizja ryzyka dostawców: gdzie Marquis (lub podobni) ma dostęp do danych, w jakiej formie, na jak długo są przechowywane.
  2. Minimalizacja danych: przekazuj vendorowi tylko pola absolutnie niezbędne (data minimization), rozdzielaj zbiory (segmentacja).
  3. Wymogi techniczne w umowach: szyfrowanie „at rest”, logowanie dostępu, retencja danych, obowiązkowe MFA/SSO, audyty i SLA na zgłoszenie incydentu.
  4. Twardy patch management po stronie perimeter/VPN: CVE na urządzeniach brzegowych to „ulubiona” ścieżka ransomware; traktuj wpisy CISA/KEV jako sygnał do priorytetu P0.
  5. Weryfikacja SonicWall/SSLVPN: jeśli w organizacji używane są rozwiązania SonicWall, zastosuj zalecenia producenta dotyczące aktualizacji, resetów haseł po migracjach i dodatkowych zabezpieczeń (np. rekomendacje w komunikacie o aktywności SSLVPN).

Dla klientów (co realnie ma sens)

  • Włącz alerty transakcyjne i monitoruj wyciągi.
  • Zachowaj podwyższoną czujność na telefony/SMS-y „z banku” – zwłaszcza gdy rozmówca zna Twoje dane.
  • Rozważ zamrożenie/monitoring kredytowy (w USA jest to częsta rekomendacja w tego typu notyfikacjach; część podmiotów oferuje go w pakiecie).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Ten incydent jest podręcznikowym przykładem różnicy między:

  • breachem „w banku” (atak na core banking / kanały zdalne), a
  • breachem „u dostawcy” (vendor/supply chain), gdzie bank bywa „poszkodowanym pośrednio”, ale to on musi obsłużyć klienta i reputację.

W praktyce oznacza to, że same inwestycje w bezpieczeństwo banku nie wystarczą, jeśli łańcuch dostaw danych (outsourcing komunikacji, marketingu, analityki) nie ma równie wysokich standardów.

Podsumowanie / kluczowe wnioski

  • Atak ransomware na Marquis z 14 sierpnia 2025 r. nadal generuje skutki: kolejne banki ujawniają naruszenia klientów jako efekt incydentu u dostawcy.
  • Wektor wejścia wiąże się z SonicWall i ryzykiem związanym z podatnościami urządzeń brzegowych (kontekst CVE-2024-40766 + zalecenia CISA i SonicWall).
  • Skala jest znacząca: według zestawień z notyfikacji do urzędów stanowych mowa o ~788 tys. osób.
  • Najważniejsza lekcja dla sektora finansowego: zarządzanie ryzykiem dostawców musi być równie „produkcyjne” jak ochrona własnej infrastruktury.

Źródła / bibliografia

  1. The Record (Recorded Future News) – opis notyfikacji VeraBank i Artisans’ Bank oraz kontekst incydentu Marquis. (The Record from Recorded Future)
  2. Reuters – informacje o wektorze (SonicWall), dacie incydentu i typach danych. (Reuters)
  3. SecurityWeek – szacunki skali (~788 tys.), harmonogram dochodzenia i notyfikacji. (SecurityWeek)
  4. SonicWall – komunikat dot. aktywności SSLVPN i korelacji z CVE-2024-40766, zalecenia mitigacyjne. (SonicWall)
  5. CISA – alert o dodaniu CVE-2024-40766 do Known Exploited Vulnerabilities Catalog. (CISA)

Fortinet: 5-letnia luka w FortiOS SSL VPN nadal pozwala omijać 2FA (CVE-2020-12812)

Wprowadzenie do problemu / definicja luki

Fortinet ostrzega, że podatność CVE-2020-12812 w komponencie FortiOS SSL VPN – znana od 2020 r. – jest ponownie (lub nadal) aktywnie nadużywana w realnych atakach. Mechanizm błędu pozwala w określonych konfiguracjach zalogować się bez wywołania drugiego czynnika (FortiToken), czyli de facto ominąć 2FA/MFA na bramie VPN.

To ważny sygnał operacyjny, bo mówimy o klasie ataków na urządzenia brzegowe (VPN/firewall), gdzie pojedynczy błąd w uwierzytelnianiu potrafi otworzyć drogę do przejęcia kont VPN lub nawet administracyjnych.

W skrócie

  • CVE: CVE-2020-12812 (FortiOS SSL VPN)
  • Co umożliwia: ominięcie wymogu 2FA dla wybranych scenariuszy logowania
  • Warunek „w praktyce”: specyficzna konfiguracja z LDAP + lokalnym użytkownikiem z 2FA + politykami/grupami LDAP
  • Trik atakującego: zmiana wielkości liter w nazwie użytkownika (case) powoduje, że FortiGate nie dopasowuje wpisu lokalnego (z 2FA) i „spada” do innego mechanizmu uwierzytelnienia
  • Poprawki/mitigacje: dostępne od FortiOS 6.0.10 / 6.2.4 / 6.4.1 (lipiec 2020) + ustawienia username-sensitivity
  • Status ryzyka: CVE jest też odnotowane w NVD jako obecne w katalogu KEV CISA (historycznie dodane 2021-11-03)

Kontekst / historia / powiązania

Podatność została ujawniona i zaadresowana w połowie 2020 r., ale Fortinet wskazuje, że obecnie obserwuje „recent abuse” tej luki „in the wild” – przy czym skuteczne wykorzystanie ma dotyczyć konkretnych (często błędnie zaprojektowanych) konfiguracji uwierzytelniania opartego o LDAP.

Z perspektywy długiego ogona ryzyka to typowy problem: urządzenia brzegowe bywają rzadziej aktualizowane, a złożone konfiguracje IAM/LDAP potrafią „przetrwać” lata. W 2021 r. luka była łączona z realnymi kampaniami (w tym ransomware), a fakt jej umieszczenia w ekosystemie ostrzeżeń rządowych (KEV) jest sygnałem, że podatność miała już historię użycia w atakach.

Analiza techniczna / szczegóły luki

Na czym polega błąd?

Rdzeń problemu to niekonsekwentna obsługa wrażliwości na wielkość liter (case sensitivity) pomiędzy FortiGate a katalogiem LDAP.

  • FortiGate domyślnie traktuje nazwy użytkowników jako case-sensitive.
  • LDAP (np. katalogi w stylu AD) często działa case-insensitive.

W efekcie logowanie „jsmith” może trafić w lokalny wpis użytkownika, wymusić 2FA, ale logowanie „Jsmith” może już nie dopasować lokalnego użytkownika i uruchomić alternatywną ścieżkę uwierzytelnienia.

Jakie warunki muszą być spełnione (prerequisites)?

Fortinet opisuje dość konkretne wymagania, aby obejście 2FA było możliwe:

  1. Istnieją lokalne wpisy użytkowników na FortiGate z włączonym 2FA, które „odwołują się” do LDAP.
  2. Ci sami użytkownicy należą do grup w LDAP.
  3. Co najmniej jedna z tych grup LDAP jest skonfigurowana na FortiGate i użyta w polityce uwierzytelniania (np. dla adminów, SSL VPN lub IPsec VPN).

Jak wygląda scenariusz obejścia 2FA?

Mechanika (w uproszczeniu, ale technicznie wiernie) jest taka:

  • Użytkownik loguje się jako jsmith → FortiGate dopasowuje lokalny wpis → żąda tokenu 2FA.
  • Użytkownik loguje się jako Jsmith / jSmith / inna kombinacja → brak dopasowania wpisu lokalnego → FortiGate sprawdza inne polityki/grupy → jeśli jest „zapasowa” grupa LDAP, uwierzytelnienie może przejść bez 2FA.

Fortinet podkreśla też, że istotnym „katalizatorem” jest często błędna konfiguracja wtórnej (secondary) grupy LDAP, używanej jako mechanizm „failover”, gdy dopasowanie lokalne się nie powiedzie.

Ocena podatności: CVSS i rozbieżności

W NVD dla CVE-2020-12812 widnieje CVSS 3.1: 9.8 (Critical).
W części publikacji spotkasz jednak inne wartości (np. oceny vendor-owe lub historyczne), dlatego w praktyce warto patrzeć nie tylko na „cyferkę”, ale na kontekst brzegowego VPN + aktywną eksploatację + obejście 2FA.

Praktyczne konsekwencje / ryzyko

Jeśli warunki konfiguracji są spełnione, skuteczne nadużycie CVE-2020-12812 może prowadzić do:

  • Nieautoryzowanego dostępu do SSL VPN (z ominięciem 2FA), co ułatwia dalszą penetrację sieci.
  • Potencjalnego przejęcia uprzywilejowanych ról (np. dostęp administracyjny), jeśli grupy/polityki są tak zbudowane.
  • Konieczności traktowania konfiguracji jako potencjalnie skompromitowanej w razie wykrycia symptomów (Fortinet wprost sugeruje reset poświadczeń, także dla bindów LDAP/AD).

To szczególnie niebezpieczne, bo „ominięcie 2FA” często bywa postrzegane jako „niemożliwe”, przez co organizacje mogą mieć zbyt słabe monitorowanie ruchu i zdarzeń logowania przy VPN.

Rekomendacje operacyjne / co zrobić teraz

1) Zweryfikuj wersje i stan łatek

Minimalnie upewnij się, że środowisko nie tkwi na liniach podatnych i że wdrożone są mechanizmy z wersji naprawiających zachowanie:

  • poprawki/mitigacje od: 6.0.10 / 6.2.4 / 6.4.1

2) Włącz „uodpornienie” na różnice w wielkości liter (username sensitivity)

Fortinet wskazuje konkretne ustawienia, które mają zapobiec scenariuszowi „failover” do LDAP bez 2FA:

Dla starszych wydań (wskazanych przez Fortinet) na kontach lokalnych:

set username-case-sensitivity disable

Dla nowszych wersji (m.in. 6.0.13+, 6.2.10+, 6.4.7+, 7.0.1+):

set username-sensitivity disable

To powoduje, że FortiGate traktuje jsmith, JSmith, JSMITH jako ten sam byt i nie „przechodzi bokiem” do alternatywnej polityki/grupy.

3) Przejrzyj konfigurację grup LDAP – szczególnie „secondary/failover”

Jeśli masz wtórną grupę LDAP używaną, gdy lokalne dopasowanie nie wyjdzie, rozważ jej usunięcie, jeśli nie jest wymagana biznesowo. Fortinet wskazuje ten element jako istotny warunek umożliwiający obejście 2FA.

4) Załóż możliwość nadużycia i przygotuj playbook IR

Jeśli istnieją przesłanki, że administratorzy lub użytkownicy VPN logowali się bez 2FA, Fortinet rekomenduje traktować konfigurację jako skompromitowaną oraz wykonać reset poświadczeń, w tym kont/hasła używanego do LDAP/AD binding.

5) Monitoring: na co patrzeć?

Nawet bez pełnych IOC od vendora (Fortinet nie opisuje publicznie szczegółów kampanii), sensowne detekcje to m.in.:

  • logowania SSL VPN, gdzie nazwa użytkownika pojawia się w nietypowych wariantach case (np. „AdmIn”, „JSmiTh”), szczególnie gdy wiesz, że organizacja normalnie używa jednego formatu;
  • korelacja: udane logowanie VPN bez spodziewanej ścieżki 2FA (jeśli masz telemetrykę na flow 2FA);
  • nietypowa aktywność po VPN (nowe urządzenia, nowe geolokacje, enumeracje zasobów, skoki lateralne).

Różnice / porównania z innymi przypadkami

CVE-2020-12812 to dobry przykład, że „MFA wszędzie” nie kończy tematu, jeśli implementacja i polityki mają alternatywne ścieżki (fallback) albo niespójność w identyfikacji użytkownika. W praktyce podobny wzorzec widujemy w:

  • błędnie skonfigurowanych łańcuchach SSO/LDAP/SAML, gdzie jeden „warunek brzegowy” (tu: case) rozłącza logikę policyjną;
  • urządzeniach edge, gdzie lata „dziedziczonej” konfiguracji + brak audytu polityk uwierzytelniania tworzą nieoczywiste ścieżki obejścia.

A z punktu widzenia trendów eksploatacji: Fortinet sam w 2025 r. publikował ostrzeżenia o innych nadużywanych podatnościach w swoim portfolio – co potwierdza, że urządzenia tej klasy są stałym celem (szczególnie na styku internet ↔ sieć wewnętrzna).

Podsumowanie / kluczowe wnioski

  • CVE-2020-12812 nadal żyje operacyjnie: mimo wieku, Fortinet obserwuje jej nadużywanie w 2025 r.
  • Luka jest w praktyce błędem logiki uwierzytelniania wynikającym z różnic w obsłudze wielkości liter i z polityk/grup LDAP.
  • Jeśli masz SSL VPN + LDAP + lokalnych użytkowników z 2FA, koniecznie zweryfikuj konfigurację, ustaw username-sensitivity i przejrzyj „secondary LDAP group”.
  • W razie podejrzenia obejścia 2FA traktuj incydent poważnie: reset poświadczeń (także bindów LDAP/AD) i przegląd konfiguracji/polityk to minimum.

Źródła / bibliografia

  1. Fortinet PSIRT Blog: Product Security Advisory and Analysis: Observed Abuse of FG-IR-19-283 (24.12.2025) (fortinet.com)
  2. BleepingComputer: Fortinet warns of 5-year-old FortiOS 2FA bypass still exploited in attacks (29.12.2025) (BleepingComputer)
  3. NVD (NIST): CVE-2020-12812 Detail (opis, wersje podatne, CVSS, odniesienie do KEV) (NVD)
  4. SecurityWeek: Fortinet Warns of New Attacks Exploiting Old Vulnerability (29.12.2025) (SecurityWeek)
  5. The Hacker News: Fortinet Warns of Active Exploitation of FortiOS SSL VPN 2FA Bypass Vulnerability (25.12.2025) (The Hacker News)

Dlaczego Hakerzy 'Kochają’ Święta

Jak sezon urlopowy tworzy lukę operacyjną w cyberobronie (i co z tym zrobić)

Święta – dla większości z nas czas odpoczynku i wyciszenia. Dla hakerów? Wręcz przeciwnie – to okres żniw. Cyberprzestępcy dosłownie „kochają” długie weekendy i przerwy świąteczne, bo wtedy czujność obrony jest najniższa. Zespoły bezpieczeństwa (SOC, blue team) pracują często w okrojonym składzie albo pełnią dyżury zdalnie, podczas gdy atakujący nie biorą urlopu. Rezultat?

Czytaj dalej „Dlaczego Hakerzy 'Kochają’ Święta”

Atak ransomware na rumuńską Administrację „Apele Române”: ok. 1000 systemów zaszyfrowanych BitLockerem, infrastruktura OT bez zakłóceń

Wprowadzenie do problemu / definicja luki

W weekend 20–22 grudnia 2025 r. rumuńska państwowa instytucja odpowiedzialna za zarządzanie zasobami wodnymi – Administrația Națională „Apele Române” (Romanian Waters) – potwierdziła incydent typu ransomware, który objął ok. 1000 systemów IT. Mimo dużej skali zakłóceń w warstwie IT, władze podkreślają, że operacyjne technologie (OT) sterujące infrastrukturą wodną nie zostały naruszone, a kluczowe operacje hydrotechniczne są realizowane w trybie ciągłym.

W praktyce to klasyczny przykład kryzysu w infrastrukturze krytycznej, gdzie atak na IT (poczta, serwery, domena, aplikacje) może nie zatrzymać „fizycznego” procesu, ale znacząco utrudnić koordynację, logistykę i odzyskiwanie sprawności.

W skrócie

  • Co się stało: ransomware zaszyfrował ok. 1000 stacji i serwerów w centrali oraz 10 z 11 biur regionalnych.
  • Co ucierpiało: m.in. serwery GIS, bazy danych, poczta, usługi webowe, kontrolery domeny/DNS oraz stacje Windows.
  • Co nie ucierpiało: systemy OT i bieżące działania hydrotechniczne (zapory, zabezpieczenia przeciwpowodziowe, dyspozytornie).
  • Nietypowy element techniczny: sprawcy wykorzystali wbudowany mechanizm Windows BitLocker do szyfrowania („living off the land”), zamiast klasycznego droppera ransomware.
  • Stan na dziś (28.12.2025): śledztwo trwa, brak publicznej atrybucji i brak ujawnionego wektora wejścia.

Kontekst / historia / powiązania

Ataki na podmioty wodno-kanalizacyjne i zarządzające zasobami wodnymi to trend, który w ostatnich latach dotykał wiele państw (zwłaszcza w Europie i USA). Rumuński incydent wyróżnia się jednak dwoma czynnikami:

  1. Skala w warstwie IT (ok. 1000 urządzeń) przy jednoczesnym utrzymaniu procesów fizycznych dzięki procedurom operacyjnym i pracy „w terenie”.
  2. Użycie BitLockera jako narzędzia szyfrującego, co wpisuje się w szerszy wzorzec nadużyć legalnych komponentów systemu (LOLbins), utrudniających wykrycie ataku klasycznymi sygnaturami.

Analiza techniczna / szczegóły incydentu

Co wiemy o zakresie i środowisku

Z komunikatów wynika, że zaszyfrowane/objęte zakłóceniami zostały m.in.:

  • serwery aplikacyjne GIS,
  • serwery bazodanowe,
  • serwery pocztowe i WWW,
  • stacje robocze i serwery Windows,
  • elementy związane z domeną i DNS.

Z punktu widzenia odporności organizacji na incydenty w infrastrukturze krytycznej, szczególnie istotne jest to, że awaria IT wymusiła przejście na kanały alternatywne (np. telefon/radio) w koordynacji działań.

BitLocker jako „ransomware” (LOLbins) – dlaczego to ma znaczenie

Według wstępnych ustaleń śledczych, sprawcy nie musieli wdrażać klasycznego binarnego ransomware, tylko wykorzystali legalny mechanizm szyfrowania dysków BitLocker dostępny w Windows.

To podejście bywa skuteczne, bo:

  • uruchamiane są legalne procesy/narzędzia systemowe (mniej „podejrzanych” artefaktów),
  • część telemetrii może wyglądać jak działania administracyjne,
  • organizacje często mają niejednorodne polityki dot. BitLockera (kto może włączać, gdzie trafiają klucze odzyskiwania, jak wygląda monitoring).

W sprawie pojawiła się też informacja o nocie okupu i żądaniu kontaktu w ciągu 7 dni – standardowy mechanizm presji czasowej w cyberwymuszeniach.

Czego oficjalnie nie ujawniono

Na moment publikacji znanych informacji:

  • brak potwierdzonego wektora wejścia (phishing, VPN, RDP, nadużycie kont uprzywilejowanych itd. – to na razie tylko hipotezy),
  • brak atrybucji do konkretnej grupy.

Praktyczne konsekwencje / ryzyko

Nawet jeśli OT jest nietknięte, incydent tej klasy generuje realne ryzyka operacyjne:

  • Degradacja „układu nerwowego” organizacji: poczta, domena, systemy ewidencyjne, GIS i bazy danych wspierają decyzje operacyjne. Ich niedostępność spowalnia reakcję na zdarzenia (np. gwałtowne opady, wezbrania, awarie).
  • Ryzyko wtórne dla OT: w wielu środowiskach to IT jest „mostem” (tożsamość, zdalny dostęp, aktualizacje). Nawet jeśli dziś OT nie ucierpiało, to słaba segmentacja lub wspólne konta mogą tworzyć ścieżkę eskalacji.
  • Koszt i czas przywracania: użycie BitLockera komplikuje odtwarzanie, jeśli organizacja nie ma spójnego zarządzania kluczami odzyskiwania i procedur wycofania szyfrowania.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „z pola walki”, które mają sens przy scenariuszu szyfrowania BitLockerem w dużej organizacji (zwłaszcza krytycznej):

1) Kontrola szkód i triage

  • Odizoluj zainfekowane segmenty (zwłaszcza tożsamość: AD/AAD), zatrzymaj rozprzestrzenianie (blokady kont, wyłączenie podejrzanych sesji).
  • Zabezpiecz logi i artefakty (kontrolery domeny, EDR, SIEM, serwery zarządzające, urządzenia adminów).

2) BitLocker: odzyskiwanie i prewencja nadużyć

  • Zweryfikuj gdzie są klucze odzyskiwania (AD DS/Azure AD/Intune/MBAM) i czy proces ich wydawania jest kontrolowany.
  • Ogranicz możliwość włączania/zarządzania BitLockerem do wąskiej grupy (GPO/role), monitoruj użycie narzędzi administracyjnych związanych z szyfrowaniem.
  • Wprowadź alerty na nietypowe działania administracyjne (masowe operacje na dyskach, „hurtowe” zmiany polityk, aktywność z kont serwisowych).

3) Odtwarzanie usług IT bez „wciągania” infekcji z powrotem

  • Przywracaj krytyczne usługi warstwowo: tożsamość → DNS/DHCP → komunikacja → aplikacje biznesowe (GIS/bazy).
  • Waliduj backupy (integralność i brak mechanizmu ponownej aktywacji szyfrowania).

4) Długofalowo dla infrastruktury krytycznej

  • Wymuś twardą segmentację IT/OT i kontrolowany, monitorowany dostęp z IT do OT.
  • Opracuj i przetestuj procedury działania „na radiu i telefonie” (jak w tym przypadku) jako formalny tryb degradacji usług.

Różnice / porównania z innymi przypadkami

W porównaniu do „klasycznego” ransomware (gdzie atakujący wdraża własny szyfrator), ten incydent pokazuje rosnącą popularność podejścia LOLBins:

  • Mniej malware, więcej nadużyć narzędzi systemowych (np. BitLocker) → trudniejsze wykrycie oparte na sygnaturach.
  • Potencjalnie szybsze masowe szyfrowanie w środowisku Windows, jeśli napastnik uzyskał uprawnienia domenowe/administracyjne.
  • W literaturze branżowej pojawiały się już opisy kampanii i narzędzi nadużywających BitLockera (np. mechanizmy podobne do „ShrinkLocker”), co sugeruje, że to kierunek, do którego obrońcy muszą dopasować detekcję i polityki.

Podsumowanie / kluczowe wnioski

  • Rumuńska administracja wodna została dotknięta dużym incydentem ransomware w IT (ok. 1000 systemów), ale bez bezpośredniego wpływu na OT i krytyczne operacje.
  • Incydent jest ważnym sygnałem dla sektora infrastruktury krytycznej: utrzymanie procesów fizycznych nie oznacza braku ryzyka – IT bywa kluczowe dla koordynacji i bezpieczeństwa.
  • Użycie BitLockera jako narzędzia wymuszenia wzmacnia potrzebę: twardych polityk uprawnień, monitoringu działań administracyjnych oraz dojrzałego zarządzania kluczami odzyskiwania.

Źródła / bibliografia

  1. Security Affairs – Romanian Waters confirms cyberattack, critical water operations unaffected (22.12.2025). (Security Affairs)
  2. BleepingComputer – Romanian water authority hit by ransomware attack over weekend (22.12.2025). (BleepingComputer)
  3. The Record (Recorded Future News) – Romanian national water agency hit by BitLocker ransomware attack (ok. 22.12.2025). (The Record from Recorded Future)
  4. DNSC (Directoratul Național de Securitate Cibernetică) – komunikat prasowy nt. incydentu ransomware w „Apele Române” (notyfikacja 20.12.2025). (DNSc)
  5. Tom’s Hardware – 1,000 computers taken offline in Romanian water management authority hack… (ok. 23.12.2025). (Tom’s Hardware)

Gruzja: były szef służb zatrzymany za domniemaną ochronę „scam call centers” – co to mówi o nowoczesnych oszustwach inwestycyjnych

Wprowadzenie do problemu / definicja „luki”

Zatrzymanie byłego szefa gruzińskiej Służby Bezpieczeństwa Państwa (SSS) w sprawie domniemanej ochrony „scam call centers” nie dotyczy jednej podatności w oprogramowaniu – to przykład systemowej „luki” w ekosystemie antyfraudowym, gdzie przestępcza infrastruktura telemarketingowa może działać mimo formalnych kampanii zwalczania oszustw. Prokuratura ma twierdzić, że w zamian za łapówki zapewniano parasol ochronny dla call center, które miały okradać ofiary na wielu rynkach.

W praktyce „scam call centers” (często nazywane też boiler rooms) łączą socjotechnikę, fałszywe platformy inwestycyjne i sprawne pranie pieniędzy. Skala i „produkcyjny” charakter tych operacji powodują, że to dziś jedna z najbardziej dochodowych gałęzi cyberprzestępczości – nawet jeśli część elementów (telefony, reklamy, bankowość) wygląda „legalnie” na pierwszy rzut oka.

W skrócie

  • Gruzińskie organy ścigania zatrzymały Grigola Liluashviliego, byłego szefa SSS (kierował służbą od 2020 do kwietnia 2025), w sprawie wielowątkowych zarzutów korupcyjnych – w tym domniemanej ochrony oszukańczych call center.
  • Według relacji opartych o komunikaty prokuratury, wątek call center ma obejmować lata 2021–2023 i łapówki rzędu ok. 1,365 mln USD (przekazywane przez krewnego).
  • Sprawa mocno łączy się z dziennikarskim śledztwem „Scam Empire”, które opisywało m.in. call center w Tbilisi (ok. 85 osób, ok. 35,3 mln USD wyłudzeń od ponad 6,100 ofiar od maja 2022).
  • Mechanika oszustwa: fałszywe reklamy (czasem deepfake/„endorsementy” celebrytów), telefoniczne „prowadzenie” ofiary, fikcyjna platforma z „zyskami”, presja na dopłaty i finalnie blokada wypłat + pranie pieniędzy.

Kontekst / historia / powiązania

Wątek „scam call centers” w Gruzji nie pojawił się znikąd. Dziennikarskie materiały z 2025 r. opisywały operacje, które działały niemal „pod nosem” instytucji państwowych (w tym lokalizacje w Tbilisi w pobliżu siedziby służby).

OCCRP informowało też, że po publikacjach:

  • uruchamiano postępowania,
  • zamrażano aktywa,
  • a śledztwo obejmowało większy, międzynarodowy krajobraz wyłudzeń inwestycyjnych, bazujący na dużych wyciekach danych (rzędu terabajtów) pozyskanych przez partnerów medialnych.

Na tym tle obecne zatrzymanie byłego szefa służby ma znaczenie nie tylko „polityczne”. Dla świata cyberbezpieczeństwa to sygnał, że łańcuch oszustwa (reklamy → telekomunikacja → bankowość/finanse → pranie pieniędzy) może zostać „uszczelniony” albo… rozszczelniony decyzjami i nadużyciami ludzi, nie technologią.

Analiza techniczna / szczegóły „modelu” oszustwa

Poniżej uproszczony, ale bardzo typowy „kill chain” oszustw call center, zgodny z ustaleniami śledztw dziennikarskich:

1) Pozyskanie leada (wejście do lejka)

  • Reklamy w social media kierujące do „platform inwestycyjnych”, często podparte fałszywymi rekomendacjami (w tym deepfake lub kradzione wizerunki).
  • Lead sprzedawany przez afiliantów/marketerów (płatność „za skutecznego klienta” jest w tym modelu standardem).

2) Kontakt telefoniczny i segmentacja ofiary

  • „Juniorzy” dzwonią, badają podatność (dochód, presja czasu, poziom wiedzy), po czym przekazują ofiarę do „closerów/retention”.

3) Warstwa zaufania i manipulacji

  • Budowanie relacji, częste telefony, skryptowane rozmowy, presja społeczna i emocjonalna („to twoja szansa”, „działa, bo widzisz wyniki”).

4) „Dowód” w postaci platformy

  • Ofiara widzi „konto” z rosnącymi zyskami (najczęściej to UI, które symuluje rynki, a nie realny handel).

5) Eskalacja płatności i kontrola urządzenia

  • Dopłaty, „upgrade” konta, a przy trudnościach: prośby o zdalny dostęp (np. narzędzia typu AnyDesk pojawiają się w relacjach ofiar) – co daje przestępcom przewagę do transferów i obejścia zabezpieczeń.

6) Faza „wypłaty”, czyli pułapka opłat

  • Gdy ofiara chce wypłacić środki, pojawiają się „opłaty”: podatki, AML, prowizje, „uwolnienie środków” – płacone wielokrotnie, aż do wyczerpania możliwości.

7) Pranie pieniędzy

  • Przelewy do spółek–wydmuszek, pośredników, „dostawców” oraz miks kanałów płatności. Z perspektywy blue team/fraud team to trudne, bo transakcje często wyglądają jak standardowe płatności handlowe.

Praktyczne konsekwencje / ryzyko

  • Dla użytkowników: realne straty finansowe, utrata kontroli nad kontami (zwłaszcza przy zdalnym dostępie), wtórna wiktymizacja (kolejne „firmy odzysku”).
  • Dla banków/fintechów: rosnące koszty chargebacków, reklamacji i obowiązków AML/CTF, a także ryzyko reputacyjne, gdy schemat „przechodzi” przez ich systemy.
  • Dla państwa i rynku: gdy pojawia się podejrzenie „ochrony” infrastruktury przestępczej, spada zaufanie do instytucji i skuteczności egzekwowania prawa.

Rekomendacje operacyjne / co zrobić teraz

Dla osób i firm (higiena antyfraudowa)

  • Weryfikuj podmiot w rejestrach regulatorów (np. komunikaty FCA i innych nadzorów – oszuści często podszywają się pod „licencjonowane” marki).
  • Nigdy nie instaluj narzędzi zdalnego dostępu na prośbę „konsultanta inwestycyjnego”. To moment krytyczny, który często przełącza incydent z „oszustwa” na „pełne przejęcie kont”.
  • Traktuj „opłaty za wypłatę” jako silny wskaźnik oszustwa.
  • Jeśli już doszło do przelewu: natychmiast kontakt z bankiem, zgłoszenie incydentu i zabezpieczenie dowodów (numery telefonów, domeny, nagrania, korespondencja).

Dla SOC/Fraud team w bankach i fintechach

  • Koreluj sygnały: nowy beneficjent + nietypowy opis płatności + presja klienta + szybkie podniesienie limitów + świeżo założone konta docelowe.
  • Wzmocnij wykrywanie „scam journeys”: seria mniejszych wpłat → rosnące kwoty → nowe urządzenie/IP → kontakt klienta z infolinią w stylu „to inwestycja, proszę nie blokować”.
  • Usprawnij proces „scam intervention” (krótkie, stanowcze pytania + edukacja w czasie rzeczywistym, zanim pieniądze wyjdą poza możliwość odzysku).

Dla telekomów i dostawców usług głosowych

  • Analityka nadużyć (wzorce masowych połączeń, rotacja CLI, nietypowe trasy VoIP).
  • Szybkie kanały współpracy z bankami i platformami reklamowymi (takedown + blokady numerów/sieci).

Różnice / porównania z innymi przypadkami

  • Call center / boiler room vs „pig butchering”: oba modele bazują na długim „dogrzewaniu” ofiary i manipulacji zyskami, ale call center zwykle jest bardziej „fabryczne” (skrypty, role: lead → retention) i opiera się na głosie, podczas gdy pig butchering często startuje w komunikatorach i łączy romans/relację z krypto.
  • „Cybercrime bez malware”: tu nie musi pojawić się exploit ani ransomware, a mimo to skutki finansowe są ogromne – bo rdzeniem jest socjotechnika + infrastruktura płatnicza.

Podsumowanie / kluczowe wnioski

Zatrzymanie byłego szefa służb w sprawie domniemanej ochrony „scam call centers” pokazuje, że w 2025 r. walka z cyberprzestępczością to nie tylko EDR, IOC i CVE, ale też odporność instytucjonalna oraz szczelność współpracy między reklamą, telekomem i finansami. Równolegle śledztwa typu „Scam Empire” odsłaniają techniczne i operacyjne detale: od generowania leadów, przez skrypty rozmów i fałszywe platformy, po pranie pieniędzy.

Jeśli miałbym wskazać jeden najważniejszy praktyczny wniosek: zdalny dostęp + „opłaty za wypłatę” + presja na szybkie przelewy to triada, która w większości takich spraw powinna uruchamiać twardą blokadę i interwencję.

Źródła / bibliografia (wybrane)

  1. The Record (Recorded Future News) – „Georgia arrests ex-spy chief over alleged protection of scam call centers”. The Record from Recorded Future
  2. OCCRP – „Georgia Detains Ex-Security Chief Over Alleged Bribes Tied to Global Scam Call Centers”. OCCRP
  3. Civil Georgia – „Ex-State Security Chief Grigol Liluashvili Arrested on Bribery Charges”. Civil Georgia
  4. OCCRP – „Georgia Launches Criminal Probe Into Scam Call Center Exposed by Journalists” (Scam Empire / dane z wycieku). OCCRP
  5. The Guardian – „Deepfakes, cash and crypto: how call centre scammers duped 6,000 people”. The Guardian