Archiwa: Malware - Strona 100 z 125 - Security Bez Tabu

Aresztowanie byłego agenta wsparcia Coinbase w Indiach: jak insider pomógł w wycieku danych i co z tego wynika dla bezpieczeństwa

Wprowadzenie do problemu / definicja luki

Incydent wokół Coinbase z 2025 roku to klasyczny przykład zagrożenia insider threat po stronie operacji wsparcia klienta: atakujący nie muszą łamać kryptografii ani przełamywać MFA, jeśli potrafią przekupić lub zwerbować osobę z dostępem do narzędzi helpdesk.

29 grudnia 2025 r. BleepingComputer poinformował o aresztowaniu w Hyderabadzie (Indie) byłego agenta obsługi klienta Coinbase, podejrzanego o pomoc hakerom w kradzieży wrażliwych danych klientów z firmowej bazy.


W skrócie

  • Areszt: Hyderabad (Indie), były agent wsparcia Coinbase; spodziewane kolejne zatrzymania (wg wypowiedzi CEO).
  • Mechanizm ataku: przekupstwo/werbunek osób w rolach wsparcia poza USA; dostęp do narzędzi obsługowych posłużył do wyniesienia danych i późniejszego social engineeringu.
  • Skala i dane: Coinbase mówił o „<1% miesięcznie aktywnych użytkowników”; w kontekście tego incydentu wskazywano m.in. dane identyfikacyjne i „last 4” SSN, a także – w części przypadków – obrazy dokumentów ID/KYC.
  • Szantaż: żądanie 20 mln USD okupu, odrzucone przez Coinbase; uruchomienie funduszu nagrody 20 mln USD za informacje prowadzące do aresztowania i skazania sprawców.
  • Koszty: Coinbase szacował wpływ finansowy działań naprawczych i zwrotów dla poszkodowanych na 180–400 mln USD.

Kontekst / historia / powiązania

Chronologia układa się w spójny łańcuch:

  1. 11 maja 2025: według Reuters Coinbase otrzymał wiadomość od sprawcy z twierdzeniem o posiadaniu danych klientów i dokumentów wewnętrznych.
  2. 15 maja 2025: Coinbase publicznie opisał próbę wymuszenia, wskazując na „rogue overseas support agents” i podkreślając, że nie doszło do przejęcia haseł, 2FA ani kluczy prywatnych.
  3. 2 czerwca 2025: Reuters powiązał część wycieku z operacją w Indiach i dostawcą BPO (TaskUs), opisując m.in. przypadek pracownicy przyłapanej na fotografowaniu ekranu prywatnym telefonem.
  4. 29 grudnia 2025: informacja o aresztowaniu byłego agenta wsparcia w Hyderabadzie, jako elementu tej samej sprawy insiderowej.

Analiza techniczna / szczegóły luki

To nie jest „luka CVE” w oprogramowaniu – to luka procesowo-organizacyjna w dostępie do danych wrażliwych w systemach wsparcia.

Najbardziej prawdopodobny łańcuch ataku (TTP)

  1. Rekrutacja / przekupstwo insidera w zespole wsparcia (outsourcing/kontraktorzy), z motywacją finansową. Coinbase wprost mówi o przekupywaniu i werbowaniu agentów.
  2. Dostęp do narzędzi helpdesk/CRM i wyszukiwanie profili klientów w celu budowy „listy ofiar” do późniejszego podszywania się pod Coinbase.
  3. Eksfiltracja danych metodami omijającymi standardowe DLP:
    • „low-tech exfil”: zdjęcia ekranu telefonem (dokładnie taki modus operandi opisuje Reuters).
  4. Social engineering: kontakt z ofiarami jako „support Coinbase”, presja czasu, scenariusze „konto zhakowane / trzeba przenieść środki”, co kończy się przelewem na portfel atakującego (Coinbase deklaruje zwroty dla osób oszukanych w wyniku tego typu działań).
  5. Wymuszenie na organizacji: groźba publikacji danych i żądanie okupu 20 mln USD.

Jakie dane były atrakcyjne dla atakujących

Coinbase wskazał m.in. dane kontaktowe, „last 4” SSN, maskowane identyfikatory bankowe, obrazy dokumentów ID, a także migawki sald i historię transakcji (dla wiarygodności rozmów socjotechnicznych).
BleepingComputer doprecyzował, że w sprawie pojawia się liczba ok. 69 500 klientów oraz że dla części osób wyciek obejmował skany KYC.


Praktyczne konsekwencje / ryzyko

Dla klientów

  • Uwiarygodnione phishing/vishing: połączenie PII (imię, adres, e-mail, telefon, data urodzenia) + kontekst konta/transakcji podbija skuteczność podszywania się.
  • Ryzyko kradzieży tożsamości: przy wycieku elementów dokumentów ID/KYC rośnie ryzyko fraudów finansowych poza samą giełdą.

Dla organizacji (Coinbase i inni)

  • Koszty reakcji i zwrotów: Coinbase komunikował przedział 180–400 mln USD.
  • Ryzyko łańcucha dostaw: BPO/outsourcing wsparcia jest „przedłużeniem” organizacji; jeśli kontrola dostępu, monitoring i egzekwowanie polityk są słabe, atakujący wybierze najsłabsze ogniwo.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny zestaw działań (część pokrywa się z kierunkiem opisanym przez Coinbase, część to dobre praktyki „insider risk”):

1) Redukuj wartość danych w narzędziach wsparcia

  • Maskowanie/segmentacja PII (domyślnie ukryte, odsłaniane „just-in-time” z powodem biznesowym).
  • Minimalizacja dostępu do obrazów ID/KYC – tylko wyspecjalizowane role, z silnym audytem.

2) Utrudnij eksfiltrację „kamerą w telefonie”

  • Strefy „no-phone” lub kontrolowane stanowiska (VDI, watermarking per-agent, nagrywanie sesji, wykrywanie anomalii).
  • Procedury reakcji na próby fotografowania ekranu (to realny wektor opisany przez Reuters).

3) Wzmocnij kontrolę dostępu i monitoring

  • Least privilege + JIT dla wrażliwych akcji (podgląd KYC, zmiany ustawień konta, dane bankowe).
  • Detekcja anomalii: nietypowe wyszukiwania klientów, masowe podglądy, praca poza godzinami, powtarzalne wzorce.

4) Zarządzaj ryzykiem dostawców (BPO)

  • Audyt procesów (tożsamość, rotacja kadr, background checks), testy kontroli, wymagania kontraktowe dot. logów i współpracy z dochodzeniem.
  • „Kill switch” operacyjny: możliwość szybkiego odcięcia konkretnej lokalizacji/zespołu od systemów.

5) Komunikacja i ochrona klientów

  • Jasne reguły: „nigdy nie prosimy o hasło/2FA/seed” – Coinbase mocno to akcentował.
  • Mechanizmy anty-scam: dodatkowe weryfikacje tożsamości przy dużych wypłatach, ostrzeżenia kontekstowe, allow-listing adresów wypłat.

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

W porównaniu do typowych włamań „z zewnątrz” (phishing na pracowników, exploity, malware), ten przypadek jest o tyle groźniejszy, że:

  • nie wymaga łamania zabezpieczeń technicznych konta, jeśli insider ma legalny dostęp do narzędzi;
  • eskaluje w social engineering – atakujący używa prawdziwych danych i historii, by „sprzedać” wiarygodną narrację ofierze.
  • „low-tech” eksfiltracja (zdjęcia ekranu) potrafi ominąć dojrzałe DLP, jeśli organizacja nie ma kontroli fizycznych i operacyjnych.

Podsumowanie / kluczowe wnioski

  • Aresztowanie w Hyderabadzie to sygnał, że sprawy insiderowe mogą kończyć się realnymi zatrzymaniami, ale dopiero po tym, jak szkody (w tym reputacyjne i finansowe) już się zmaterializują.
  • Największą lekcją nie jest „kolejna luka w krypto”, tylko to, że support + dostęp do PII = krytyczna powierzchnia ataku.
  • Obrona wymaga miksu: redukcji danych, kontroli eksfiltracji, monitoringu behawioralnego, dojrzałego vendor risk management i edukacji klientów.

Źródła / bibliografia

  1. Coinbase Blog – Protecting Our Customers – Standing Up to Extortionists (15.05.2025). (Coinbase)
  2. Reuters – Coinbase warns of up to $400 million hit from cyberattack (15.05.2025). (Reuters)
  3. Reuters – Coinbase breach linked to customer data leak in India, sources say (02.06.2025). (Reuters)
  4. BleepingComputer – Former Coinbase support agent arrested for helping hackers (29.12.2025). (BleepingComputer)
  5. AP News – doniesienia o wycieku i żądaniu okupu (05.2025). (AP 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”

Lotusbail: złośliwy pakiet npm udający WhatsApp Web API — 56 tys. pobrań, kradzież wiadomości i trwałe przejęcie konta

Wprowadzenie do problemu / definicja luki

Incydent z pakietem lotusbail pokazuje najbardziej podstępny wariant ataku na łańcuch dostaw oprogramowania (software supply chain): biblioteka działa dokładnie tak, jak obiecuje, a jednocześnie w tle kradnie dane i buduje trwały backdoor.

W tym przypadku cel był szczególnie wrażliwy — integracje z WhatsApp Web API wykorzystywane w botach, automatyzacji obsługi klienta, narzędziach CRM czy systemach powiadomień. Złośliwy pakiet został opublikowany w ekosystemie npm jako fork popularnej biblioteki Baileys i osiągnął ponad 56 000 pobrań.


W skrócie

  • Co to jest? lotusbail to złośliwy pakiet npm podszywający się pod bibliotekę WhatsApp Web API (fork @whiskeysockets/baileys).
  • Co kradnie? Tokeny i klucze sesyjne, pełną historię wiadomości (we/wy), kontakty (z numerami), pliki multimedialne i dokumenty.
  • Jak działa? Opakowuje legalnego klienta WebSocket i przechwytuje ruch, zanim trafi do właściwej logiki aplikacji.
  • Dlaczego jest groźny po usunięciu? Może po cichu podłączyć urządzenie atakującego do konta WhatsApp, więc samo odinstalowanie zależności nie wystarcza — trzeba ręcznie odłączyć urządzenia w WhatsApp.
  • Timeline (jawny w źródłach): pakiet miał być w rejestrze ok. 6 miesięcy, a według doniesień został wrzucony w maju 2025 przez użytkownika wskazanego w publikacjach branżowych.
  • Status w rejestrach: baza Snyk wskazuje, że zawartość pakietu została usunięta z „oficjalnego menedżera pakietów” (typowy „placeholder” po takedownie). To nie cofa skutków u osób, które już zainstalowały zależność.

Kontekst / historia / powiązania

Atak wykorzystał zaufanie do:

  1. popularności (dziesiątki tysięcy pobrań),
  2. podobieństwa do legalnego projektu (fork Baileys),
  3. naturalnego workflow deweloperów: “jeśli działa, wdrażamy”.

To kluczowa różnica względem typowych typosquatów i „śmieciowych” paczek — tutaj złośliwy kod jest schowany w cieniu poprawnie działającej biblioteki, więc przechodzi nawet przez ręczny review „na oko”.


Analiza techniczna / szczegóły „luki”

1) Warstwa przykrywki: realnie działające WhatsApp API

lotusbail bazuje na podejściu znanym z Baileys: komunikacja z WhatsApp Web odbywa się przez WebSocket. Złośliwy pakiet „owija” (wrapuje) legalnego klienta WebSocket, dzięki czemu każda wiadomość i zdarzenie przechodzą przez jego kod.

2) Kradzież danych: tokeny, sesje, wiadomości, kontakty, media

Według analizy badaczy, przechwytywane są m.in.:

  • authentication tokens i session keys,
  • pełna treść wiadomości przychodzących i wychodzących (łącznie z historią),
  • lista kontaktów (w tym numery),
  • media i dokumenty.

3) Eksfiltracja: własna kryptografia + wielowarstwowe ukrywanie

Sygnał ostrzegawczy nr 1: biblioteka „od WhatsApp” nie powinna potrzebować własnej implementacji kryptografii do ochrony danych — WhatsApp i tak szyfruje treść E2E. W lotusbail zastosowano niestandardowe RSA do szyfrowania skradzionych danych przed wysłaniem na serwer atakującego.

Sygnał ostrzegawczy nr 2: konfiguracja serwera eksfiltracji i elementy ładunku są zaciemnione (obfuscation). Opisy wskazują m.in. warstwy typu manipulacje Unicode, kompresję (np. LZString), dodatkowe kodowania oraz AES.

4) Persistence/backdoor: ciche podpięcie urządzenia atakującego (device pairing)

Najbardziej toksyczny element to przejęcie procesu parowania urządzeń WhatsApp. Zamiast używać losowego kodu parowania generowanego w normalnym procesie, malware ma wykorzystywać „twardo zaszyty” pairing code, ukryty i zaszyfrowany (m.in. AES). Efekt: przy autoryzacji aplikacji ofiary atakujący może automatycznie dołączyć swoje urządzenie jako „linked device”.

Konsekwencja operacyjna: nawet po usunięciu pakietu atakujący może zachować dostęp, dopóki ofiara ręcznie nie odłączy wszystkich urządzeń w ustawieniach WhatsApp.

5) Anti-analysis: pułapki na debug i sandbox

W opisie incydentu pojawia się informacja o ~27 pułapkach antydebugowych (m.in. pętle blokujące wykonanie po wykryciu narzędzi analitycznych). To typowe dla kampanii, które zakładają, że kod trafi do reverse engineeringu.


Praktyczne konsekwencje / ryzyko

Jeżeli lotusbail trafił do Twojego środowiska (dev/stage/prod), traktuj to jak incydent przejęcia kanału komunikacji:

  • Ujawnienie poufnych danych: treści rozmów, dane klientów, załączniki, metadane kontaktów.
  • Przejęcie tożsamości w WhatsApp: wysyłka wiadomości jako ofiara, phishing do kontaktów, oszustwa BEC-like na „zaufanym kanale”.
  • Trwała kompromitacja: jeśli urządzenie atakującego zostało podpięte, dostęp może trwać mimo usunięcia paczki.
  • Ryzyko prawne i compliance: potencjalny wyciek danych osobowych i tajemnicy korespondencji (w tym danych wrażliwych przesyłanych przez użytkowników).

Rekomendacje operacyjne / co zrobić teraz

A) Szybka weryfikacja (triage)

  1. Przeszukaj repozytoria i artefakty buildów pod kątem lotusbail:
    • package.json, package-lock.json / npm-shrinkwrap.json, lockfile w CI.
  2. Sprawdź, czy pakiet nie został wciągnięty tranzytywnie (dependency tree).
  3. Przejrzyj logi egress (proxy/NAT/firewall) pod kątem nietypowych połączeń wychodzących z hostów budujących/uruchamiających integrację WhatsApp.

B) Ograniczenie skutków (containment)

  1. Usuń zależność i zablokuj ją w politykach (allowlist/denylist).
  2. Jeśli integracja miała dostęp do konta WhatsApp:
    • natychmiast przejdź do WhatsApp → Linked devices / Połączone urządzenia i odłącz wszystkie podejrzane wpisy (w praktyce często najbezpieczniej: odłączyć wszystko i sparować ponownie).
  3. Traktuj tokeny/sesje jako skompromitowane: rotacja wszelkich sekretów w środowisku, w którym działał proces (API keys, webhook secrets, dane dostępowe w vaultach).

C) Detekcja i hardening (żeby to się nie powtórzyło)

  • Wymuś kontrolę łańcucha dostaw w CI/CD:
    • budowanie wyłącznie z lockfile i w trybie deterministycznym (np. „clean install”),
    • skan SCA (Snyk/OSV/GHAS itp.) + polityki blokujące „malicious package”.
  • Korzystaj z sygnałów heurystycznych:
    • biblioteka komunikacyjna nagle zawiera custom RSA, warstwy obfuscation, antydebug — to powinno odpalać alarm.
  • Włącz kontrolę zachowania w runtime (nie tylko statyczne skanowanie):
    • monitoruj nietypowe domeny/IP w egress,
    • ogranicz egress dla build runnerów i środowisk produkcyjnych (zasada najmniejszych uprawnień również dla sieci).

D) Status pakietu i „false sense of safety”

Nawet jeśli rejestr „zdjął” pakiet lub podmienił go na placeholder, to:

  • zainstalowane kopie nadal mogą siedzieć w cache’ach, obrazach kontenerów i artefaktach,
  • część szkód (np. podpięte urządzenie WhatsApp) jest poza npm.

Różnice / porównania z innymi przypadkami

Co wyróżnia lotusbail na tle klasycznych incydentów npm?

  1. „Functional malware”: paczka jest użyteczna i przechodzi testy funkcjonalne, więc trafia do produkcji szybciej niż typowy typosquat.
  2. Persistence poza kodem: mechanizm device linking sprawia, że skutki mogą utrzymywać się po odinstalowaniu — to rzadsze niż w standardowych kradzieżach tokenów.
  3. Zaawansowane ukrywanie: wielowarstwowa obfuskacja + własna kryptografia + antydebug sugerują dobrze zaprojektowaną operację, a nie „jednorazowy strzał”.

Podsumowanie / kluczowe wnioski

lotusbail to podręcznikowy przykład, że „działa” nie znaczy „jest bezpieczne”. Atakujący wykorzystali naturalny odruch deweloperów: jeśli biblioteka spełnia wymagania i ma pobrania, to budzi zaufanie. Tutaj to zaufanie zostało zamienione na:

  • kradzież treści komunikacji i danych kontaktowych,
  • przejęcie sesji,
  • oraz — co najgorsze — trwałe podpięcie urządzenia atakującego do konta WhatsApp.

Źródła / bibliografia

  1. Koi Security (Tuval Admoni), analiza lotusbail (21 grudnia 2025). (Koi)
  2. Security Affairs, podsumowanie incydentu i aspekty antydebug/pairing (27 grudnia 2025). (Security Affairs)
  3. BleepingComputer, dodatkowe szczegóły dot. przechwytywania i obfuskacji (22 grudnia 2025). (BleepingComputer)
  4. The Hacker News, dane o publikacji i kontekście (22 grudnia 2025). (The Hacker News)
  5. Snyk Vulnerability DB, rekord „Malicious Package” i informacja o usunięciu zawartości (publ. 24 grudnia 2025). (VulnInfo Guide)

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

Evasive Panda i DNS poisoning: jak „fałszywe aktualizacje” dostarczały MgBot w latach 2022–2024

Wprowadzenie do problemu / definicja luki

DNS poisoning (zatrucie odpowiedzi DNS) to technika, w której atakujący powoduje, że ofiara rozwiązuje prawidłową domenę do nieprawidłowego (atakującego) adresu IP. W efekcie użytkownik może łączyć się „z właściwym adresem w pasku przeglądarki”, ale faktycznie trafia na serwer kontrolowany przez napastnika — a to idealny punkt wyjścia do cichej dystrybucji malware, zwłaszcza przez mechanizmy aktualizacji o słabej walidacji.

W grudniu 2025 Kaspersky opisał kampanię przypisaną do chińskojęzycznego APT Evasive Panda (alias m.in. Daggerfly/BRONZE HIGHLAND/StormBamboo), w której DNS poisoning posłużył do dostarczania backdoora MgBot w wysoce ukierunkowanych atakach obserwowanych między listopadem 2022 a listopadem 2024.


W skrócie

  • Kto: Evasive Panda / Daggerfly (G1034 w MITRE ATT&CK), powiązany z Chinami i znany z ekskluzywnego użycia MgBot.
  • Co: ukierunkowana dystrybucja MgBot przez DNS poisoning + fałszywe aktualizacje popularnych aplikacji.
  • Gdzie: ofiary wykryte w Türkiye, Chinach i Indiach; część hostów utrzymywana w kompromitacji ponad rok.
  • Jak: wieloetapowy łańcuch loaderów i shellcode’u, pobieranie kolejnego etapu jako „PNG” z domeny dictionary[.]com po uprzedniej manipulacji DNS, a następnie szyfrowanie hybrydowe DPAPI+RC5 wiążące payload z konkretną maszyną.

Kontekst / historia / powiązania

Evasive Panda jest aktywny co najmniej od 2012 r., a MITRE wskazuje na jego profil ofiar (m.in. podmioty rządowe/NGO/telekomy) oraz powiązanie z kampaniami o charakterze supply-chain.

To nie pierwsza historia, w której ta grupa „wchodzi w ścieżkę zaufania” użytkownika:

  • ESET (kwiecień 2023) opisał przypadek, gdzie kanały aktualizacji legalnych aplikacji zostały przejęte/hijackowane, aby podsunąć instalator MgBot — z rozważanymi hipotezami supply-chain lub ataku typu adversary-in-the-middle.
  • Volexity (sierpień 2024) pokazał scenariusz jeszcze cięższego kalibru: DNS poisoning na poziomie ISP, gdzie podmieniano odpowiedzi DNS dla domen mechanizmów aktualizacji, szczególnie gdy aktualizacje szły po HTTP i bez weryfikacji podpisu.

Analiza techniczna / szczegóły luki

1) „Aktualizacja” jako przynęta: SohuVA / iQIYI / Tencent QQ / IObit

W kampanii opisanej przez Kaspersky, startem infekcji był plik udający update do aplikacji (np. SohuVA). Telemetria wskazała pobieranie z zasobu pod domeną p2p.hd.sohu.com[.]cn, a badacze ocenili, że mogło dojść do DNS poisoning, które kierowało ofiarę na serwer atakującego mimo użycia „prawidłowej” domeny.
Kaspersky dopisał też analogiczny schemat z „fałszywym updaterem” m.in. dla iQIYI, uruchamianym przez legalny qiyiservice.exe, oraz podobne podejście wobec IObit Smart Defrag i Tencent QQ.

2) Loader i etap shellcode: podszycie pod legalny projekt

Loader był napisany w C++ (WTL) i miał przypominać przykładową aplikację (sample) — co utrudnia szybkie odróżnienie „zwykłego” binarium od złośliwego.

3) DNS poisoning jako kanał dostarczania kolejnego etapu (dictionary[.]com)

Istotny fragment łańcucha: jeśli lokalny plik z danymi nie był obecny, shellcode przechodził do pobrania zaszyfrowanych danych z „web source” kontrolowanego przez atakującego, ale realizowanego poprzez DNS poisoning — w telemetrii wyglądało to jak pobranie „PNG” z legalnego dictionary[.]com.
Co ważne, manipulacja miała być selektywna: ofiary rozwiązywały dictionary[.]com do różnych adresów IP w zależności od geolokalizacji i ISP.

4) „Sprytna” kryptografia: DPAPI + RC5, czyli payload związany z hostem

Kaspersky opisał hybrydę, w której klucz RC5 jest zaszyfrowany DPAPI i zapisany w pierwszych bajtach pliku (perf.dat), a reszta zawartości to payload szyfrowany RC5. Taki zabieg utrudnia analizę, bo DPAPI wiąże odszyfrowanie z konkretną maszyną.

5) In-memory execution i wstrzyknięcie MgBot

Po odszyfrowaniu kolejnego etapu secondary loader inicjuje uruchomienie/iniekcję (m.in. wskazano wstrzyknięcie wariantu MgBot do legalnego svchost.exe). Konfiguracja (m.in. nazwa kampanii, adresy C2) miała być odszyfrowywana prostym XOR, a część infrastruktury C2 wygląda na używaną wieloletnio.


Praktyczne konsekwencje / ryzyko

  1. Zaufanie do DNS i update’ów jako punkt pojedynczej porażki. Jeśli DNS zostanie „skręcony” (na ISP, w sieci firmowej, na routerze), to nawet rozsądne zachowania użytkownika mogą nie wystarczyć — bo ofiara pobiera „aktualizację” spod znanej domeny.
  2. Długotrwała, cicha kompromitacja. W tej kampanii część hostów pozostawała zainfekowana ponad rok, a całość (według telemetrii) trwała ok. 2 lata: XI 2022 – XI 2024.
  3. Trudniejsza analiza i detekcja. Unikalne, per-ofiara elementy (np. dobór odpowiedzi po nagłówkach/wersji Windows) oraz szyfrowanie powiązane z hostem utrudniają triage, sandboxing i „łatwe” IOC-driven hunting.

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: uszczelnij aktualizacje (software supply chain w skali mikro)

  • Wymuszaj aktualizacje po HTTPS i z weryfikacją podpisów (oraz blokuj aktualizatory, które tego nie robią). Volexity wskazywał, że atakujący wybierali oprogramowanie z niepewnymi mechanizmami update (np. HTTP, brak walidacji podpisu).
  • W środowiskach firmowych rozważ allowlistę dla updaterów i repozytoriów aktualizacji oraz kontrolę uruchamiania binariów (AppLocker/WDAC).

Priorytet 2: zredukuj ryzyko manipulacji DNS

  • Przestaw stacje/serwery na zaufane resolvery i rozważ DoH/DoT (tam, gdzie to zgodne z polityką), aby utrudnić podmianę odpowiedzi po drodze na poziomie dostawcy. Uwaga: to nie „magiczna tarcza”, jeśli atakujący siedzi na brzegu sieci lub na urządzeniu końcowym — ale ogranicza klasę ataków na trasie. (W omawianej kampanii mechanizm poisoning pozostaje nie w pełni wyjaśniony).
  • Monitoruj rozbieżności DNS (np. porównanie odpowiedzi z kilku resolverów, alerty na nagłe zmiany A/AAAA dla popularnych domen).

Priorytet 3: hunting/IR pod kątem tej kampanii

  • Sprawdź artefakty ścieżek i plików wskazywanych w analizie (m.in. %ProgramData%\Microsoft\MF, status.dat, perf.dat) oraz nietypowe biblioteki/dropy związane z loaderem.
  • Poluj na podejrzane połączenia do znanych adresów C2 i anomalie w ruchu HTTP związane z pobieraniem „obrazów PNG” z domen, które normalnie nie służą do dystrybucji binariów.

Różnice / porównania z innymi przypadkami

  • ESET 2023: fokus na „przejęte aktualizacje” i rozważane scenariusze supply-chain/AitM przy dystrybucji MgBot.
  • Volexity 2024: twardy dowód na poisoning na poziomie ISP i wykorzystywanie słabych mechanizmów aktualizacji (HTTP, brak weryfikacji).
  • Kaspersky 2025: nacisk na selektywną dystrybucję kolejnych etapów (np. dictionary[.]com rozwiązywany do różnych IP zależnie od ISP/geo) oraz na utrudnianie analizy poprzez DPAPI+RC5 i in-memory injection.

Wspólny mianownik: atakowanie „zaufanych ścieżek” (DNS + aktualizacje), gdzie klasyczne „nie klikaj w linki” ma ograniczoną wartość, bo użytkownik i system robią to, co zwykle.


Podsumowanie / kluczowe wnioski

Kampania Evasive Panda opisana pod koniec grudnia 2025 r. to podręcznikowy przykład, jak DNS poisoning może stać się „niewidzialnym przewodem” do dystrybucji backdoora MgBot: ofiara widzi legalne domeny, a mimo to pobiera złośliwy kod. Dodatkowo, hybrydowe szyfrowanie (DPAPI+RC5) oraz selektywne odpowiedzi po DNS/HTTP podnoszą koszt obrony i analizy.

Jeśli chcesz zmniejszyć ekspozycję na tę klasę operacji, najwięcej „zysku za wysiłek” dają: twarda polityka bezpiecznych aktualizacji, sensowne zarządzanie DNS (i jego monitoring) oraz przygotowane playbooki huntingowe pod MgBot/Evasive Panda.


Źródła / bibliografia

  1. The Hacker News — China-Linked Evasive Panda Ran DNS Poisoning Campaign to Deliver MgBot Malware (26.12.2025) (The Hacker News)
  2. Kaspersky Securelist — Evasive Panda APT poisons DNS requests to deliver MgBot (24.12.2025) (Securelist)
  3. Volexity — StormBamboo Compromises ISP to Abuse Insecure Software Update Mechanisms (02.08.2024) (Volexity)
  4. ESET WeLiveSecurity — Evasive Panda APT group delivers malware via updates for popular Chinese software (26.04.2023) (We Live Security)
  5. MITRE ATT&CK — Daggerfly / Evasive Panda (G1034) (aktualizacja: 31.10.2024) (MITRE ATT&CK)

Nomani: fala oszustw inwestycyjnych z deepfake’ami AI rośnie — ESET raportuje +62% r/r

Wprowadzenie do problemu / definicja luki

Nomani to nazwa kampanii oszustw inwestycyjnych, które żerują na reklamach w mediach społecznościowych i coraz częściej wykorzystują generowane przez AI materiały wideo (deepfake) jako „haczyk” wiarygodności. Według danych ESET, aktywność tej kampanii wzrosła rok do roku o 62%, a dystrybucja nie ogranicza się już wyłącznie do Facebooka — obserwowane są także emisje na innych platformach, m.in. YouTube.

W praktyce to nie „luka” w rozumieniu CVE, ale luka procesowo-psychologiczna: połączenie systemów reklamowych, targetowania, automatyzacji kreacji oraz podatności użytkowników na autorytet (znana osoba, „news” o rządowym programie, modny temat) — wzmocnione realizmem materiałów AI.


W skrócie

  • ESET odnotował 62% wzrost kampanii Nomani r/r; w 2025 roku blokowano ponad 64 tys. unikalnych URL-i powiązanych z tą aktywnością.
  • Kampanie wychodzą poza Facebooka (m.in. YouTube).
  • Deepfake’i stają się trudniejsze do wykrycia: lepsza rozdzielczość, mniej „nienaturalnych” ruchów, lepsza synchronizacja audio-wideo.
  • Przestępcy ograniczają ślad: krótkie emisje reklam (godziny), „cloaking”, przechwytywanie danych przez natywne formularze/ankiety platform reklamowych.

Kontekst / historia / powiązania

ESET opisał Nomani już w grudniu 2024 r. jako kampanię wykorzystującą malvertising w social media, posty podszywające się pod marki oraz „testymoniale” wideo generowane przez AI, które obiecują wysokie zyski z nieistniejących produktów inwestycyjnych.

W 2025 r. kampania została „doszlifowana”: nie tylko poprawiono jakość deepfake’ów, ale też zoptymalizowano operacje pod kątem omijania moderacji reklam oraz szybkiej rotacji infrastruktury.
Warto też zauważyć szerszy trend: organy ścigania w USA (IC3/FBI) już wcześniej ostrzegały, że generatywna AI jest wykorzystywana do tworzenia materiałów promocyjnych i wideo na potrzeby oszustw finansowych/inwestycyjnych.

Nomani wpisuje się także w problem systemowy reklam-oszustw na dużych platformach: śledztwo Reuters opisywało skalę „ekonomii” reklam fraudowych i napięcie między egzekucją zasad a bodźcami przychodowymi w ekosystemie reklamowym.


Analiza techniczna / szczegóły luki

Poniżej typowy „łańcuch oszustwa” obserwowany w kampaniach Nomani (z uwzględnieniem elementów, które ESET wskazuje jako nowsze usprawnienia):

  1. Wejście: reklama w social media + deepfake jako „autorytet”
    Ofiara widzi reklamę z wideo sugerującym rekomendację inwestycji przez znaną osobę lub „wiarygodne źródło”. W nowszych wariantach poprawiono realizm (ruchy twarzy, „oddech”, A/V sync), co zmniejsza liczbę oczywistych artefaktów.
  2. Inżynieria społeczna: obietnica wysokich zwrotów + presja czasu
    Komunikaty wprowadzają narrację „okazji”, „limitowanych miejsc”, „gwarantowanych zysków” i prowadzą do pozostawienia danych lub przejścia na stronę/formularz.
  3. Minimalizacja wykrywalności: krótkie kampanie + cloaking + targetowanie
    Reklamy bywają uruchamiane tylko na kilka godzin. Jeśli użytkownik nie pasuje do profilu targetowania (lub mechanizmy wykryją „niepożądany” ruch), następuje przekierowanie na „bezpieczną” stronę maskującą zamiast właściwego phishingu.
  4. Zbieranie danych: przejęcie leadów także przez natywne narzędzia platform
    Zamiast klasycznego „wyślij na zewnętrzny landing”, przestępcy potrafią używać wbudowanych formularzy i ankiet w ramach frameworków reklamowych, aby obniżyć ślad i ryzyko blokady domeny.
  5. Strony phishingowe: lepsze szablony + sygnały użycia AI do generowania HTML
    ESET zauważa ulepszenia szablonów i wskazówki sugerujące automatyzację/AI przy tworzeniu kodu HTML.
  6. Monetyzacja: „dopłaty”, wyłudzenia danych i wieloetapowe oszustwo
    Gdy ofiara chce wypłacić rzekomy zysk, pojawia się żądanie opłat „administracyjnych/podatkowych” albo prośby o dane osobowe (np. dokument tożsamości) i informacje o karcie płatniczej. Finał jest przewidywalny: strata pieniędzy i/lub kradzież danych.
  7. „Recovery scam”: wtórne oszustwo na odzyskanie środków
    Po stracie przestępcy potrafią uderzyć ponownie, podszywając się pod instytucje (np. Europol/INTERPOL) i obiecując „pomoc w odzyskaniu pieniędzy” — co kończy się kolejnymi wyłudzeniami.

Praktyczne konsekwencje / ryzyko

Dla użytkowników:

  • Bezpośrednia strata finansowa (wpłata „inwestycji”, dopłaty, prowizje, fałszywe opłaty wypłat).
  • Ryzyko kradzieży tożsamości i nadużyć finansowych, jeśli przekazano skan dokumentu, dane karty lub inne wrażliwe informacje.
  • „Podwójne uderzenie” w postaci recovery scam, czyli wtórnego wyłudzenia po pierwszej stracie.

Dla firm i instytucji (zwłaszcza marek, mediów, finansów):

  • Nadużycia wizerunku (podszycia pod brand/eksperta), koszty obsługi zgłoszeń i reklamacji, reputacyjne „spillover”.
  • Trudniejsze blokowanie: krótkie emisje reklam i natywne formularze ograniczają skuteczność klasycznego podejścia „zdejmij domenę = zdejmiesz kampanię”.

Dlaczego to ważne w Polsce?
ESET wskazuje, że znacząca część detekcji pochodziła m.in. z Polski (obok Czech, Japonii, Słowacji i Hiszpanii). To nie znaczy, że kampania jest „tylko u nas”, ale że realnie trafia także na polskich użytkowników.


Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów helpdesk (szybka checklista)

  • Zasada nr 1: „gwarantowany zysk” + „znana twarz” w reklamie = domyślnie oszustwo. Deepfake’i są coraz lepsze.
  • Nie podawaj danych KYC poza zaufanym kanałem: skany dokumentów, dane kart, selfie „weryfikacyjne” — to najczęstszy punkt krytyczny.
  • Nie płać „opłat za wypłatę” ani „podatków przed wypłatą” na żądanie „platformy” — to typowy mechanizm dociskania ofiary.
  • Zgłoś reklamę i profil w platformie społecznościowej (to ważne zwłaszcza przy krótkich kampaniach).
  • Jeśli doszło do transakcji: natychmiast kontakt z bankiem/operatorami płatności, zastrzeżenie instrumentów, zgłoszenie sprawy organom ścigania.

Dla organizacji (SOC/Threat Intel/Brand Protection)

  • Monitoruj reklamy podszywające się pod markę: narzędzia brand protection + threat intel pod kątem kreacji wideo i wariantów copy.
  • Zbieraj sygnały „lead-gen”: jeśli przestępcy używają natywnych formularzy/ankiet, klasyczne feedy blokad domen nie wystarczą — potrzebne są procesy zgłaszania konkretnych kampanii reklamowych.
  • Edukacja ukierunkowana (finanse, HR, obsługa klienta): pokaż realne przykłady deepfake + mechanizmy dopłat/wypłat oraz „recovery scam”.
  • Procedury kryzysowe: gotowe komunikaty „nie promujemy inwestycji przez reklamy”, landing do weryfikacji, szybki kanał zgłaszania dla klientów.

Różnice / porównania z innymi przypadkami

W porównaniu do „klasycznych” oszustw inwestycyjnych (spam, cold-calling, proste landingi), Nomani wyróżnia się trzema elementami:

  1. Deepfake jako akcelerator zaufania – materiał wideo, który jeszcze rok-dwa lata temu łatwo było rozpoznać, dziś bywa jakościowo „wystarczający”, by przejść szybki test wiarygodności w feedzie.
  2. Operacje w modelu ad-tech – krótkie emisje, testowanie kreacji, cloaking, wykorzystywanie natywnych narzędzi reklamowych do przechwytywania danych.
  3. Przenoszenie rozmowy „na czat” – w szerszym krajobrazie takich kampanii często widać „domykanie” oszustwa w komunikatorach (np. WhatsApp), gdzie łatwiej prowadzić długą manipulację 1:1. Kaspersky opisywał podobny schemat: deepfake w reklamie → przekierowanie do prywatnej grupy/czatu → dopinanie wpłat.

Podsumowanie / kluczowe wnioski

Nomani pokazuje, że „AI w cyberprzestępczości” to nie tylko malware i automatyzacja ataków, ale także potężne wzmocnienie skali oszustw. Wzrost o 62% r/r, ekspansja na kolejne platformy i coraz lepsze deepfake’i oznaczają, że bariera wejścia dla oszustów spada, a koszt po stronie ofiar rośnie.

Najważniejsze działania „tu i teraz” to: twarde zasady weryfikacji inwestycji, szybkie raportowanie reklam, procedury reakcji po incydencie (bank/zastrzeżenia/zgłoszenia) oraz — po stronie organizacji — monitoring nadużyć marki i procesy zgłaszania kampanii, nie tylko domen.


Źródła / bibliografia

  1. The Hacker News — „Nomani Investment Scam Surges 62% Using AI Deepfake Ads on Social Media” (24 grudnia 2025). (The Hacker News)
  2. ESET (Newsroom) — „ESET Threat Report: AI-driven attacks on the rise…” (16 grudnia 2025). (ESET)
  3. ESET (WeLiveSecurity) — „ESET Threat Report H2 2025” (16 grudnia 2025). (We Live Security)
  4. FBI/IC3 — „Criminals Use Generative Artificial Intelligence to Facilitate Financial Fraud” (3 grudnia 2024). (Internet Crime Complaint Center)
  5. Kaspersky — „How users are losing money to deepfake ads on Instagram” (4 sierpnia 2025). (Kaspersky)
  6. Reuters (Investigation) — „Meta is earning a fortune on a deluge of fraudulent ads, documents show” (6 listopada 2025). (Reuters)