Archiwa: Phishing - Strona 74 z 99 - Security Bez Tabu

Tag: Phishing

Wycieki danych w Marquis uderzają w ponad 74 banki i unie kredytowe w USA

Wprowadzenie do problemu / definicja luki

Marquis Software Solutions – dostawca oprogramowania i usług marketingowo-analitycznych dla sektora finansowego w USA – poinformował o naruszeniu bezpieczeństwa, które dotknęło co najmniej 74 banki i unie kredytowe. Do incydentu doszło 14 sierpnia 2025 r. po włamaniu przez urządzenie SonicWall, a atak miał charakter ransomware. W plikach skradzionych z systemów Marquis znajdowały się dane osobowe klientów instytucji finansowych (m.in. SSN/Tax ID, daty urodzenia, adresy, numery kont) – na razie bez dowodów na ich publiczne ujawnienie.

W skrócie

  • Skala: ponad 74 instytucje, >400 tys. klientów w różnych stanach USA.
  • Wejście: kompromitacja dostępu przez SonicWall (SSL VPN / firewall).
  • Wektor powiązany z trendem: od 2024/2025 gang Akira intensywnie nadużywa podatności CVE-2024-40766 i wykradzionych sekretów do logowania przez VPN, czasem mimo MFA.
  • Ryzyko dla klientów: kradzież tożsamości, fraudy finansowe, dalsze spear-phishingi.
  • Status: Marquis rozsyła zawiadomienia w imieniu klientów-instytucji; część pism AG (prokuratorów generalnych stanów) jest publicznie dostępna.

Kontekst / historia / powiązania

Marquis obsługuje >700 banków, unii i pożyczkodawców hipotecznych w USA jako zewnętrzny dostawca narzędzi CRM, analityki danych, zgodności i marketingu. Oznacza to klasyczny scenariusz ryzyka łańcucha dostaw (third-party risk): incydent u jednego vendora skutkuje seriami notyfikacji po stronie wielu niezależnych instytucji. W pierwszych publicznych materiałach pojawiły się wzmianki, że Marquis zapłacił okup (informacja z pisma jednej z unii; wzmianka następnie usunięta z publicznego notice, ale odnotowana przez media).

Analiza techniczna / szczegóły luki

Według zgłoszeń do urzędów stanowych, atak rozpoczął się 14.08.2025 od „nieautoryzowanego dostępu” przez firewall/VPN SonicWall, po czym napastnicy wynieśli wybrane pliki i wdrożyli ransomware. Zawiadomienia wymieniają typowe PII: imię i nazwisko, adres, telefon, SSN/ITIN, numery kont (bez kodów dostępu), daty urodzenia. Niektóre instytucje publikują własne listy typów danych i wielkości populacji objętej powiadomieniem.

Od strony „pierwszej bramy” do sieci wielu ofiar widzimy ciągłość z kampaniami Akira: wykorzystanie CVE-2024-40766 (błąd kontroli dostępu w SonicOS/SSLVPN, ogłoszony w VIII 2024 r.) oraz ponowne logowania przy użyciu wcześniej wykradzionych poświadczeń / nasion OTP, nawet przy włączonym MFA. Vendor potwierdzał korelację z CVE-2024-40766 oraz zalecał reset haseł i sekretów MFA po aktualizacji.

Praktyczne konsekwencje / ryzyko

  • Klienci banków/uni: realne ryzyko kradzieży tożsamości (otwieranie kont na cudze dane, zwroty podatkowe, wnioski kredytowe), account takeover oraz targetowane oszustwa (phishing na podstawie dokładnych danych).
  • Instytucje finansowe: koszty notyfikacji i monitoringu (często Epiq/inne pakiety 12–24 mies.), obsługa sporów KYC/AML, potencjalne postępowania regulacyjne, wzrost obciążenia SOC.
  • Ekosystem: kolejny dowód, że urządzenia perymetryczne i ich sekrety uwierzytelniania są dziś jednym z najsłabszych ogniw łańcucha bezpieczeństwa.

Rekomendacje operacyjne / co zrobić teraz

Dla banków/uni i innych klientów Marquis (i podobnych vendorów):

  1. IR & notyfikacje: zsynchronizować treści pism z vendor-em; ująć precyzyjny zakres danych i daty (od 14.08.2025). Zweryfikować, czy notice w danym stanie nie wymaga dodatkowych elementów.
  2. Zarządzanie dostępem do VPN/Firewalli:
    • Upewnić się, że SonicWall ma wersje eliminujące CVE-2024-40766 oraz pozostałe poprawki.
    • Zresetować: hasła VPN/Local Admin, seed/sekrety OTP i klucze API; wymusić MFA z phishing-resistant (FIDO2/Passkeys, gdzie możliwe).
    • Włączyć geo-IP filtering, lockout policy, dłuższą retencję logów oraz listy blokad C2 (zgodnie z praktykami opisywanymi w notyfikacjach).
  3. Telemetria i myślenie o „dwell time”: hunting pod kątem nietypowych logowań SSLVPN (również z legalnymi kredencjałami), korelacja ze zmianami konfiguracji, enumeracją AD i exfiltracją.
  4. Procesy vendor-risk: wymagać od dostawców: regularnego rotowania sekretów, planów „credential refresh” po każdej kampanii na urządzenia brzegowe, oraz testów odtworzeniowych kopii zapasowych pod scenariusze ransomware.

Dla klientów indywidualnych:

  • Założyć zamrożenie kredytowe (credit freeze) i alerty w biurach kredytowych; skorzystać z oferowanego monitoringu tożsamości.
  • Uważać na wiadomości podszywające się pod bank/unię – nadmiar wiedzy (SSN, data urodzenia) pozwala tworzyć bardzo wiarygodne spear-phishingi.

Różnice / porównania z innymi przypadkami

W odróżnieniu od incydentów czysto „aplikacyjnych”, tutaj o skuteczności ataku przesądził kompromitowany dostęp perymetryczny (SSLVPN) i sekrety MFA, co wpisuje się w ewolucję ransomware: logowanie jak „prawowity” użytkownik, szybki rekonesans/eskalacja, exfiltracja, a dopiero potem szyfrowanie/okup. Dodatkowo, z racji roli Marquis jako vendora dla setek podmiotów, powstał efekt kaskadowy – wiele odrębnych notyfikacji w stanach, choć incydent źródłowo dotyczył jednego środowiska.

Podsumowanie / kluczowe wnioski

  • Incydent w Marquis to kolejny case łańcucha dostaw – pojedynczy vendor = dziesiątki dotkniętych instytucji i setki tysięcy osób.
  • Wektor wejścia koreluje z kampaniami przeciw SonicWall (CVE-2024-40766) i przejętymi sekretami MFA, co potwierdza, że samo „MFA” nie wystarczy bez rotacji seedów i pełnego „credential hygiene”.
  • Priorytetem jest rotacja wszystkich sekretów związanych z perymetrem, twarde MFA (FIDO2), pełne logowanie i monitoring dostępu VPN oraz dojrzały program vendor-risk.

Źródła / bibliografia

  1. BleepingComputer: „Marquis data breach impacts over 74 US banks, credit unions”, 3 grudnia 2025. (BleepingComputer)
  2. Reuters: „Fintech firm Marquis notifies affected business after ransomware breach”, 3 grudnia 2025. (Reuters)
  3. Maine AG – rekord „Marquis Management LLC” (Data Breach Notifications). (maine.gov)
  4. New Hampshire AG – pismo CoVantage CU dot. incydentu u Marquis (PDF). (mm.nh.gov)
  5. SonicWall / NVD – CVE-2024-40766 (opis i zalecenia) oraz advisory o korelacji incydentów SSLVPN. (NVD)

Askul wznawia ograniczone przyjmowanie zamówień po ataku ransomware: co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

Japoński detalista i operator platform e-commerce Askul (m.in. Askul, Lohaco, Soloel Arena) 19 października 2025 r. padł ofiarą ataku ransomware, który wywołał szeroką awarię systemów i zatrzymał nowe zamówienia oraz wysyłki. Po ~6 tygodniach przestoju firma wznowiła limitowane przyjmowanie zamówień online, zapowiadając stopniowe przywracanie usług.

W skrócie

  • Data incydentu: 19 października 2025 r. (wykrycie i odcięcie systemów).
  • Skala zakłóceń: wstrzymane zamówienia, anulacje wysyłek, niedostępna obsługa klienta; tymczasowo przyjmowano zamówienia… faksem.
  • Aktualny status: ograniczone wznowienie przyjmowania zamówień online; pełne przywrócenie ma następować stopniowo, Lohaco dla klientów indywidualnych ruszy później.
  • Komunikaty spółki: oficjalne zawiadomienia giełdowe i raporty incydentowe (EN) potwierdzają ransomware i działania naprawcze.

Kontekst / historia / powiązania

Atak na Askul wpisuje się w falę destrukcyjnych kampanii ransomware wymierzonych w duże japońskie firmy w 2025 r. (np. Asahi). W efekcie łańcuchy dostaw i sprzedaż online w Japonii były w ostatnich tygodniach szczególnie podatne na zakłócenia.

Analiza techniczna / szczegóły incydentu

  • Wektor i efekt: w oficjalnych raportach Askul potwierdził infekcję ransomware i odcięcie systemów w celu ograniczenia propagacji. Skutkiem był paraliż zamówień, logistyki i części procesów back-office.
  • Zakres usług: wstrzymane zostały trzy główne serwisy (Askul – B2B, Lohaco – B2C, Soloel Arena – klienci korporacyjni).
  • Odbudowa: po 45 dniach firma zaczęła stopniowo odblokowywać funkcje zakupowe (najpierw B2B), utrzymując ograniczenia asortymentu i przepustowości.

Uwaga: na moment publikacji brak jednoznacznego, oficjalnego wskazania grupy odpowiedzialnej w komunikatach Askul; doniesienia branżowe o potencjalnej afiliacji traktujemy jako niepotwierdzone i dlatego nie opieramy na nich wniosków. (Stan na 4 grudnia 2025 r.)

Praktyczne konsekwencje / ryzyko

  • Operacje i przychody: długi przestój (ponad 6 tygodni) oznacza realne straty sprzedaży i koszty odtworzenia usług, a także ryzyko opóźnień dostaw do partnerów-sprzedawców.
  • Łańcuch dostaw: atak na dostawcę/logistykę uderza w marki zależne od infrastruktury Askul (efekt kaskadowy).
  • Ryzyko wtórne: możliwość wycieku danych i nadużyć (phishing na bazie historii zamówień/zwrotów) – brak jest jednak publicznych potwierdzeń skali wycieku w oficjalnych raportach giełdowych spółki w chwili obecnej.

Rekomendacje operacyjne / co zrobić teraz

Dla firm współpracujących z Askul (sprzedaż/zakupy/logistyka):

  1. Segmentuj ryzyko dostawcy: tymczasowo wprowadź podwójne ścieżki zamówień (drugi operator / manualne obejścia) i limity wolumenów do czasu pełnej stabilizacji.
  2. Weryfikuj komunikację: potwierdzaj zmiany kont płatniczych, terminy dostaw i RMA kanałem niezależnym (voice back).
  3. Monitoruj kompromitację: wdroż brand & supply-chain monitoring (np. wzmianki o Twojej domenie/markach w kampaniach phishing).
  4. Twarde SLA i runbooki: dopisz do umów z dostawcami RTO/RPO, zasady tabletopów i wspólne testy odtwarzania.

Dla zespołów bezpieczeństwa:

  • Segmentacja i „kill switch”: mikrosegmentacja sieci, listy blokad lateral movement (SMB, RDP), oraz gotowy do użycia playbook izolacji.
  • Backupy testowane pod presją czasu: polityka 3-2-1 + testy bare-metal restore i recovery aplikacji z zależnościami (DB, kolejki, pliki).
  • EDR + zasady blokady makr/skryptów: wzmocniona telemetria, kontrola PowerShell/WSH, ASR/WDAC, blokowanie wbudowanych narzędzi (LOLBins).
  • MFA/PAM dla kont serwisowych: rotacja tajemnic i just-in-time access dla adminów oraz integracji B2B.
  • Ćwiczenia z komunikacji kryzysowej: gotowe szablony do klientów/partnerów i spójny kanał statusowy.

Różnice / porównania z innymi przypadkami

  • Askul (handel, platformy e-commerce): silny efekt łańcucha dostaw (partnerzy, marki zależne), długi czas odbudowy funkcji sprzedażowych.
  • Asahi (produkcja FMCG): równoległy trend w Japonii – zakłócenia logistyki i potencjalne naruszenia danych na dużą skalę, ale inna branża i profil systemów OT/ERP. (Kontekst do fali ataków w kraju).

Podsumowanie / kluczowe wnioski

  • Atak ransomware na Askul potwierdza, że dostawcy logistyczno-e-commerce są dziś jednymi z najbardziej krytycznych „punktów nacisku” w łańcuchach dostaw.
  • Czas odtworzenia (RTO) liczony w tygodniach nie jest wyjątkiem – plany ciągłości działania muszą przewidywać manualne obejścia i alternatywnych operatorów.
  • Transparentne raportowanie i stopniowy powrót do pełni usług sugerują, że odporność operacyjna staje się równie ważna jak sama prewencja.

Źródła / bibliografia

  • The Record: wstrzymanie usług po ataku (20.10.2025) oraz wznowienie ograniczonego przyjmowania zamówień (04.12.2025). (The Record from Recorded Future)
  • Oficjalny raport ASKUL do inwestorów (EN), 20.10.2025 (ransomware i działania naprawcze). (Yahoo Finance)
  • The Register: powrót sprzedaży online po 45 dniach od ataku. (The Register)
  • The Japan Times: wznowienie przyjmowania zamówień i kolejność przywracania serwisów (B2B przed B2C/Lohaco). (The Japan Times)

Arizona pozywa Temu za „kradzież danych”. Co to oznacza dla użytkowników i firm?

Wprowadzenie do problemu / definicja luki

Prokurator Generalna stanu Arizona, Kris Mayes, złożyła pozew przeciwko platformie zakupowej Temu (Whaleco Inc., spółka PDD Holdings), zarzucając jej wprowadzanie konsumentów w błąd, nielegalne pozyskiwanie danych oraz handel podróbkami lokalnych marek. W pozwie i komunikacie prasowym podniesiono m.in. ukryte gromadzenie wrażliwych informacji z urządzeń mobilnych oraz praktyki mające utrudniać wykrycie takiej aktywności.

W skrócie

  • Co się stało: Arizona wniosła pozew na podstawie stanowej ustawy o oszustwach konsumenckich, wskazując na „kradzież danych” przez aplikację Temu oraz sprzedaż nieautoryzowanych produktów.
  • Dlaczego to ważne: Zarzuty obejmują potajemny dostęp aplikacji do danych i mechanizmy obchodzenia zabezpieczeń – to ryzyko zarówno dla prywatności użytkowników, jak i dla bezpieczeństwa organizacji (BYOD).
  • Stanowisko Temu: Spółka odrzuca oskarżenia i zapowiada obronę w sądzie.
  • Szerszy trend: Temu jest w USA przedmiotem rosnącej kontroli regulacyjnej i pozwów; o sprawie szeroko informują AP i media branżowe.

Kontekst / historia / powiązania

Według Associated Press i lokalnych mediów, Arizona dołącza do grona stanów pozywających Temu o naruszenia prywatności i wprowadzanie w błąd. Pozew złożono w Sądzie Najwyższym hrabstwa Maricopa. Wątek bezpieczeństwa łączy się tu z ochroną konsumentów i praw własności intelektualnej lokalnych firm (np. elementy odzieży z logotypami uczelni, sprzęt sportowy).

Analiza techniczna / szczegóły zarzutów

Treść pozwu oraz stanowisko Prokurator Generalnej wskazują na następujące praktyki przypisywane aplikacji Temu:

  • Nadmierne uprawnienia i ukryte gromadzenie danych: m.in. dostęp do lokalizacji GPS i listy zainstalowanych aplikacji oraz inne dane urządzenia, bez adekwatnej, uczciwej informacji dla użytkownika.
  • Mechanizmy utrudniające analizę bezpieczeństwa: w dokumentach procesowych pojawiają się sformułowania o funkcjach przypominających „spyware/malware”, mających pomagać w eksfiltracji danych i omijaniu kontroli. (Zarzut organu – nieprzesądzony przez sąd).
  • Utrzymywanie „zabronionego” kodu w części wersji aplikacji: wg materiałów stanowych – pozostałości po wcześniejszych wersjach. (Również zarzut, wymagający weryfikacji w toku procesu).
  • Wprowadzanie w błąd co do jakości/pochodzenia produktów oraz naruszenia IP: w tym sprzedaż podróbek marek powiązanych z Arizoną.

Uwaga redakcyjna: powyższe to twierdzenia strony powodowej i/lub ustalenia dochodzenia AG — nie zostały jeszcze potwierdzone prawomocnym wyrokiem. Stanowisko Temu jest odmienne.

Praktyczne konsekwencje / ryzyko

  • Użytkownicy (BYOD/remote): potencjalna eksfiltracja danych urządzenia może skutkować profilowaniem, śledzeniem aktywności i ekspozycją danych firmowych, jeśli telefon jest używany do pracy.
  • Organizacje: ryzyko przeniknięcia danych firmowych przez urządzenia osobiste pracowników, możliwe naruszenia polityk MDM/EDR, odpowiedzialność regulacyjna (np. RODO w UE w razie pracowników na terenie UE). (Wniosek na podstawie charakteru zarzutów dot. zbierania danych).
  • Łańcuch dostaw i IP: sprzedaż podróbek zagraża reputacji i przychodom lokalnych marek.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów bezpieczeństwa:

  1. Inwentaryzacja aplikacji na urządzeniach BYOD/COPE; wykrycie i oznaczenie Temu w MDM/EMM (blokada instalacji lub warunkowe użycie).
  2. Odbudowa zaufania urządzenia: deinstalacja aplikacji, reset uprawnień, przegląd profili MDM, skan pod kątem anomalii sieciowych i nadmiernych uprawnień. (Rekomendacja spójna z ostrzeżeniem AG).
  3. Segmentacja i DLP: ogranicz ruch aplikacji zakupowych do internetu, blokada dostępu do zasobów korporacyjnych z urządzeń niespełniających wymogów.
  4. Monitorowanie telemetrii: reguły detekcji na nietypowe żądania API, enumerację listy aplikacji, niejawne pozyskiwanie lokalizacji. (Wnioski na podstawie zarzutów technicznych).
  5. Edukacja użytkowników: kampanie phishing/marketplace hygiene – „darmowe okazje” a ryzyka prywatności.

Dla zespołów prawnych/zgodności:

  • Przegląd ryzyka dostawców aplikacyjnych (Third-Party Risk Management) i aktualizacja rejestru DPIA/RODO, jeśli dotyczy.
  • Weryfikacja naruszeń IP: procesy reagowania na podróbki produktów/znaków towarowych.

Różnice / porównania z innymi przypadkami

Sprawa Arizony wpisuje się w szerszy trend stanowych działań przeciw aplikacjom postrzeganym jako wysokiego ryzyka dla prywatności. Media branżowe (Dark Reading) podkreślają, że zarzuty wobec Temu wykraczają poza „typowe” śledzenie reklamowe — mowa o mechanizmach przypominających spyware oraz maskowanie aktywności aplikacji. To odróżnia sprawę od zwykłych sporów o przejrzystość polityk prywatności.

Podsumowanie / kluczowe wnioski

  • Pozew Arizony eskaluje presję regulacyjną wobec Temu w USA i może stać się punktem odniesienia dla innych stanów.
  • Organizacje powinny traktować aplikacje zakupowe na urządzeniach pracowników jako ryzyko operacyjne, a nie wyłącznie „kwestię prywatności”.
  • Techniczne tezy pozwu (ukryta eksfiltracja, obchodzenie analiz) wymagają sądowej weryfikacji, jednak już teraz uzasadniają środki ostrożności w firmowych politykach mobilnych.

Źródła / bibliografia

  1. Arizona Attorney General – komunikat prasowy i ostrzeżenia dla mieszkańców, 2 grudnia 2025 r. (azag.gov)
  2. Pozew (PDF): State of Arizona ex rel. Kristin K. Mayes v. PDD Holdings & Whaleco (Temu), grudzień 2025 r. (Courthouse News)
  3. Associated Press / SecurityWeek: relacja z wniesienia pozwu, 3 grudnia 2025 r. (SecurityWeek)
  4. Dark Reading: omówienie zarzutów technicznych, 3 grudnia 2025 r. (Dark Reading)
  5. Axios Phoenix: podsumowanie pozwu i stanowiska stron, 2 grudnia 2025 r. (Axios)

Uniwersytet Pensylwanii potwierdza kradzież danych po włamaniu do Oracle E-Business Suite (EBS)

Wprowadzenie do problemu / definicja luki

Uniwersytet Pensylwanii (UPenn) potwierdził naruszenie bezpieczeństwa wynikające z ataku na serwery Oracle E-Business Suite (EBS). Atakujący mieli wykraść dokumenty z danymi osobowymi, a incydent łączy się z niedawnymi kampaniami wykorzystującymi krytyczną podatność w EBS (CVE-2025-61882).

W skrócie

  • Co się stało: Z serwerów Oracle EBS należących do UPenn wykradziono dokumenty z informacjami osobowymi.
  • Kiedy: Włamanie dotyczyło aktywności z sierpnia 2025 r., a uczelnia potwierdziła incydent 2 grudnia 2025 r. (czasu lokalnego publikacji).
  • Jak: Wektor ataku wiązany jest z krytyczną luką CVE-2025-61882 w EBS, pozwalającą na RCE bez uwierzytelnienia.
  • Kto jeszcze zagrożony: Luki w EBS zostały wpisane do katalogów „Known Exploited”, a kampanie przypisywano grupom typu Clop.

Kontekst / historia / powiązania

Po serii ataków na instancje Oracle EBS w III–IV kw. 2025 r. organy rządowe i producenci alarmowali o aktywnym wykorzystywaniu zero-day w EBS oraz o konieczności pilnego patchowania. Wpisy do katalogów KEV (CISA) oraz alerty producenta potwierdziły, że komponenty EBS są celem ukierunkowanych kampanii kradzieży danych i wymuszeń. W doniesieniach branżowych wskazywano m.in. na grupę Clop, łączoną z agresywnymi kampaniami „smash-and-grab” wymierzonymi w EBS.

Analiza techniczna / szczegóły luki

CVE-2025-61882 dotyczy produktu Oracle E-Business Suite – Concurrent Processing (BI Publisher Integration), wersje 12.2.3–12.2.14. Podatność ma CVSS 9.8 i jest zdalnie wykorzystywalna bez uwierzytelnienia (RCE) przez HTTP. Skuteczny atak umożliwia przejęcie komponentu i wykonanie złośliwego kodu, co zwykle prowadzi do eskalacji uprawnień w obrębie EBS oraz do dostępu do danych przetwarzanych przez moduły finansowe/HR. Oracle opublikował dedykowany Security Alert i poprawki łatające wektor.

W praktyce obserwowano łańcuchy ataku obejmujące szybkie wejście, enumerację instancji EBS, eksport danych (np. przez joby/raporty BI Publisher) i natychmiastową eksfiltrację – wzorzec charakterystyczny dla kampanii ukierunkowanych na kradzież informacji, a nie na szyfrowanie infrastruktury.

Praktyczne konsekwencje / ryzyko

  • Ujawnienie danych osobowych (pracownicy, studenci, darczyńcy/kontrahenci) – w przypadku UPenn potwierdzono kradzież dokumentów z PII.
  • Ryzyko wtórnych oszustw: spear-phishing, BEC, social engineering oraz próby rekrutacji insiderów.
  • Ryzyko operacyjne: dostęp do modułów finansowych/HR EBS może umożliwiać manipulację danymi, tworzenie fikcyjnych dostawców/transferów czy „quiet quitting” złośliwych jobów.
  • Ryzyko reputacyjne i prawne: obowiązki notyfikacyjne, potencjalne pozwy i kary regulacyjne.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe patchowanie EBS do wersji zaleconych w Oracle Security Alert dla CVE-2025-61882 (i powiązanych biuletynów). Wymuś zero-tolerance dla nienajświeższych łatek na systemach produkcyjnych.
  2. Ogranicz ekspozycję EBS: brak publicznych endpointów (zwłaszcza ścieżek BI Publisher / xmlpserver), dostęp wyłącznie przez VPN/ZTNA, segmentacja sieci i WAF z regułami dla nietypowych metod HTTP i dużych payloadów. (Rekomendacje wynikają z charakteru luki i wektora HTTP.)
  3. Hunting/IR:
    • Przejrzyj logi EBS/Apache/OHS pod kątem nietypowych żądań do BI Publisher i anomalii w Concurrent Manager.
    • Szukaj nagłych wzrostów eksportów/raportów, nietypowych jobów oraz nowych szablonów BI Publisher.
    • Weryfikuj konta techniczne i klucze integracyjne; wymuś rotację haseł i tokenów.
  4. Telemetria i EDR na hostach aplikacyjnych i DB: monitoruj procesy powłoki/zaplanowane zadania wywoływane przez komponent EBS.
  5. DLP i kontrola eksfiltracji: blokuj podejrzane wyjścia (S3, GDrive, paste-serwisy), limity przepustowości na serwerach aplikacyjnych.
  6. Komunikacja i notyfikacje: przygotuj spójny komunikat dla interesariuszy, wsparcie dla potencjalnych ofiar (monitoring kredytowy, dedykowana infolinia).

Różnice / porównania z innymi przypadkami

Atak na UPenn wpisuje się w szerszy trend nadużyć względem Oracle EBS. W ostatnich tygodniach i miesiącach raportowano kampanie wymierzone w instytucje publiczne i prywatne (m.in. sektor zdrowia czy edukację), z przypisaniem do grupy Clop. CISA/sojusznicze centra cyber oraz media branżowe odnotowują, że celem jest szybka kradzież danych – w przeciwieństwie do klasycznego szyfrowania szerokiego wolumenu systemów.

Podsumowanie / kluczowe wnioski

  • Podatność CVE-2025-61882 w Oracle EBS to RCE bez uwierzytelnienia o CVSS 9.8, aktywnie wykorzystywana w świecie rzeczywistym.
  • Incydent w UPenn potwierdza, że skutkiem jest realna kradzież danych osobowych. Priorytetem jest patching + ograniczenie ekspozycji EBS.
  • Organizacje korzystające z EBS powinny wdrożyć twarde kontrole dostępu, monitoring i procedury IR ukierunkowane na BI Publisher/Concurrent Manager oraz na kanały eksfiltracji.

Źródła / bibliografia

  1. BleepingComputer – „University of Pennsylvania confirms new data breach after Oracle EBS hack”, 2 grudnia 2025. (BleepingComputer)
  2. Oracle – Security Alert dla CVE-2025-61882 (Oracle E-Business Suite). (Oracle)
  3. NVD – CVE-2025-61882 (opis produktu, zakres wersji, CVSS 9.8). (NVD)
  4. CISA – wpisy KEV dot. aktywnie wykorzystywanych luk w Oracle EBS (szerszy kontekst kampanii). (CISA)
  5. BankInfoSecurity – analiza kampanii Clop wymierzonych w Oracle EBS. (BankInfoSecurity)

Fałszywe zaproszenia „Calendly” podszywają się pod topowe marki. Celem: przejęcie kont menedżerów reklam (Google Ads/Facebook)

Wprowadzenie do problemu / definicja luki

Trwa ukierunkowana kampania phishingowa wykorzystująca fałszywe zaproszenia do spotkań w stylu Calendly, która podszywa się pod rozpoznawalne marki (m.in. LVMH, Lego, Mastercard, Uber, Unilever, Disney). Atak ma na celu kradzież sesji i haseł do Google Workspace oraz przejęcie kont menedżerów reklam (Google Ads MCC) i/lub Facebook Business — co umożliwia szybkie uruchamianie malvertisingu i dalsze łańcuchy ataków. Kampanię jako pierwsi rozebrali badacze Push Security; szczegóły opisał też BleepingComputer.

W skrócie

  • Wejście w relację: przestępcy zaczynają od profesjonalnie przygotowanego wątku rekrutacyjnego (podszycie pod realnego pracownika), dopiero potem wysyłają link do „umówienia rozmowy” (fałszywy Calendly).
  • Kradzież sesji: po CAPTCHA ofiara trafia na AiTM (Attacker-in-the-Middle) lub wariant Browser-in-the-Browser (BitB), który wyłudza dane/ciasteczka logowania do Google/Facebooka i obchodzi 2FA.
  • Cel finansowy i zasięgowy: przejęte MCC daje kontrolę nad wieloma kontami klientów i budżetami — idealne do malvertisingu i „watering hole” z precyzyjnym targetowaniem.
  • Obserwowane TTPs: blokady VPN/proxy, blokowanie DevTools, parametryzacja pod domenę ofiary, rotacja dziesiątek URL-i, hosting na Odoo/Kartra.

Kontekst / historia / powiązania

Wykorzystywanie legalnych usług (calendaring, formularze, SaaS) w phishingu nie jest nowe; podobne wektory z Calendly raportowano już wcześniej. Nowością jest skala podszywania pod marki i skupienie na ekosystemach reklamowych (MCC/Business Manager), co współgra z równoległymi kampaniami malvertisingu obserwowanymi przez Push Security w Google Search.

Analiza techniczna / szczegóły luki

Łańcuch ataku:

  1. Mail „od rekrutera” znanej marki → 2) „Zaproszenie Calendly” → 3) CAPTCHA → 4) AiTM strona logowania (Google/Facebook) → 5) przechwycenie sesji i eskalacja do kont reklamowych. W nowszych próbkach użyto BitB (fałszywe okno logowania, które sprawia wrażenie prawdziwego, wraz z „prawdziwym” URL-em w pasku pop-upu).

Techniki anty-analizy:

  • whitelisting domen e-mail ofiary (zablokowanie funkcji dla „nieautoryzowanych” domen),
  • blokowanie ruchu z VPN/proxy,
  • blokowanie otwarcia DevTools,
  • szybkie gaszenie i rotacja hostów (Odoo/Kartra).

Dlaczego BitB jest skuteczny: imituje natywne okno logowania (SSO) w przeglądarce, przez co ofiara często ufa wyglądowi i nie weryfikuje rzeczywistego origin/URL. (Patrz: materiały wyjaśniające BitB).

Praktyczne konsekwencje / ryzyko

  • Spalenie budżetów reklamowych w godziny, utrata dostępu do kont klientów/agencji, zły PR i chargebacki.
  • Malvertising w skali (precyzyjne targetowanie po kraju, domenie, urządzeniu) — „watering hole” do AiTM/malware/ClickFix.
  • Ryzyko wtórne: jeśli Google Workspace pełni rolę IdP/SSO, kompromitacja konta reklamowego może być trampoliną do danych i aplikacji całej organizacji.

Rekomendacje operacyjne / co zrobić teraz

Google Ads (MCC)

  • Włącz powiadomienia/alerty w Manager Account (np. gdy dodawane jest nowe konto/UZ), monitoruj nietypowe linkowania, ustaw reguły SIEM/SOAR na te zdarzenia.
  • Wymuś klucze sprzętowe (FIDO2/WebAuthn) dla kont o wysokiej wartości; AiTM obchodzi kody 2FA, ale hardware keys znacząco podnoszą poprzeczkę. (Rekomendacja także w materiałach branżowych).
  • Zasada „tylko z zakładek”: dostęp do Ads/Business Managera wyłącznie z firmowych zakładek/SSO portal, nigdy z reklamy czy wyników wyszukiwania. Blokuj sponsorowane wyniki dla słów typu „google ads login”.
  • Least privilege: zrewiduj role w MCC/Business Manager, włącz zatwierdzanie dodawania użytkowników/kont, logi zmian i dzienniki rozliczeń.

Higiena przeglądarki i hardening

  • Wykrywaj BitB/AiTM: szkolenia (przeciągnij okno pop-upu do krawędzi — jeśli to wciąż „wewnątrz karty”, to BitB), egzekwuj pokazywanie pełnych URL/origin, ostrzegaj przed pop-upami logowania w „nieoczekiwanych” domenach.
  • EDR/rozszerzenia bezpieczeństwa z detekcją anomalii w DOM i blokadą złośliwych skryptów; polityki blokujące uruchamianie DevTools nie powinny wyłączać telemetrii bezpieczeństwa.
  • Zasady sieciowe: blokuj kategorie hostingu współdzielonego używane w kampanii (np. Odoo/Kartra) jeśli nieużywane biznesowo; w przeciwnym razie — sandbox/isolated browsing.

Procesy SOC/IR

  • Playbook „MCC takeover”: natychmiastowe wylogowanie wszystkich sesji, reset kluczy/2FA, weryfikacja metod płatności, przegląd delegacji i linkowań kont, pauza wszystkich kampanii do czasu oceny szkód.
  • Threat hunting: szukaj świeżych logowań z nieznanych AS, nagłych zmian w kampaniach/limitach, dodanych użytkowników/aplikacji OAuth. (Push Security wskazuje, że IoC-based detections są tu mało skuteczne — liczy się TTP/behaviour).

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

W porównaniu z „zwykłym” phishingiem na konta reklamowe, obecna kampania:

  • Mocniej personalizuje socjotechnikę (podszycie pod konkretnego rekrutera, wieloetapowa rozmowa).
  • Używa AiTM/BitB do ominięcia 2FA i przejęcia sesji, a nie tylko hasła.
  • Łączy wektor e-mail (Calendly) z malvertisingiem w Google Search, co poszerza lejek ofiar.

Podsumowanie / kluczowe wnioski

  • To nie „kolejny” kalendarzowy phish — to spięcie socjotechniki z nowoczesnymi TTP (AiTM/BitB), ukierunkowane na kontrolę nad budżetami reklamowymi i zasięgami.
  • Agencje i działy performance powinny traktować konta MCC/Business Manager jak kontrolowane uprzywilejowane — z hardware MFA, alertami i ciągłym nadzorem zmian.
  • Zasada zero zaufania dla linków do logowania: tylko zakładki lub wewnętrzny portal SSO.

Bonus: mini-checklista dla SOC/IT (do wdrożenia dziś)

  • Wymuś FIDO2 na wszystkich kontach MCC/Business Manager.
  • Skonfiguruj alerty MCC i reguły w SIEM (dodanie konta, nowy user, zmiany płatności).
  • Zablokuj sponsorowane wyniki dla „login” w przeglądarkach firmowych/DNS.
  • Przeprowadź szkolenie BitB + procedurę „przeciągnij pop-up do krawędzi”.
  • Dodaj kontrolę odcięcia sesji i resetu 2FA dla incydentów Ads/Business.

Źródła / bibliografia

  1. BleepingComputer — „Fake Calendly invites spoof top brands to hijack ad manager accounts”, 2 grudnia 2025. (BleepingComputer)
  2. Push Security — „Uncovering a Calendly-themed phishing campaign targeting business ad manager accounts”, 2 grudnia 2025. (Push Security)
  3. Push Security — „Analysing a malvertising attack targeting business Google accounts”, 2 grudnia 2025. (Push Security)
  4. Google Ads Help — „About notifications in manager accounts (MCC)”. (Google Help)
  5. Bolster — „Browser-in-the-Browser (BitB) phishing attacks — wyjaśnienie”. (Bolster AI)

CodeRED wyłączony po ataku ransomware. Co się stało z amerykańnym systemem ostrzegania?

Wprowadzenie do problemu / definicja luki

Na początku listopada 2025 r. platforma powiadomień kryzysowych OnSolve CodeRED – wykorzystywana przez tysiące miast, hrabstw i służb w USA do wysyłania alertów o zagrożeniach – została zaatakowana przez gang INC Ransom. W efekcie operator (Crisis24/GardaWorld) zdekomisjonował (trwale wyłączył) starą, „legacy” wersję CodeRED, a klientów przenosi do nowego środowiska. Incydent uderzył w komunikację władz lokalnych m.in. w okresie Święta Dziękczynienia.

W skrócie

  • Atak ransomware uszkodził środowisko legacy CodeRED; operator wyłączył platformę i rozpoczął migrację klientów do „CodeRED by Crisis24”.
  • Dane użytkowników (imiona i nazwiska, adresy, e-maile, numery telefonów, hasła) zostały skradzione; część została opublikowana online.
  • Oś czasu: dostęp uzyskany 1 listopada, szyfrowanie 10 listopada; publikacja próbek danych 22–23 listopada.
  • Kopie zapasowe: odtwarzanie z backupu z 31 marca 2025 r., co oznacza luki w stanie kont i danych.
  • Systemy rządowe EAS/IPAWS nie ucierpiały; problem dotyczy komercyjnej platformy powiadomień opt-in.

Kontekst / historia / powiązania

CodeRED to popularny, komercyjny system „mass notification” dla samorządów i służb publicznych (pogoda, ewakuacje, przerwy w dostawach). W przeciwieństwie do federalnego Emergency Alert System (EAS), CodeRED wymaga rejestracji użytkownika i utrzymuje własną bazę danych kontaktowych. Atak nie dotyczył EAS; uderzył w bazę i infrastrukturę CodeRED, co wymusiło wyłączenie starej platformy i przyspieszoną migrację do nowej.

Analiza techniczna / szczegóły luki

Według oświadczeń i relacji mediów branżowych:

  • Wejście do środowiska: napastnicy mieli uzyskać dostęp 1 listopada 2025 r., a 10 listopada zaszyfrowali pliki (etap egzekucji ransomware), co spowodowało uszkodzenie środowiska legacy.
  • Ekfiltracja danych: skradzione rekordy obejmują dane identyfikacyjne i kontaktowe oraz hasła profili CodeRED; gang opublikował próbki i oferuje sprzedaż zestawu.
  • Backup i odtwarzanie: uruchomiono nowy „CodeRED by Crisis24”, odtwarzając dane z backupu z 31.03.2025, co skutkuje brakującymi kontami i lukami w historii subskrypcji.
  • Atrybucja i negocjacje: za atak odpowiada INC Ransom; według ich relacji odrzucono rzekomą propozycję 100 tys. USD, po czym dane wystawiono na sprzedaż. (Uwaga: to twierdzenie przestępców; operator nie potwierdził kwoty).

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla mieszkańców: narażenie na phishing/SMiShing/voice phishing z użyciem realnych danych kontaktowych i kontekstu lokalnych alertów; ryzyko przejęcia kont tam, gdzie hasła były recyklingowane.
  • Ryzyko operacyjne dla służb: utrata kanału powiadamiania w szczytowych okresach pogodowych, opóźnienia w migracji i rekonstrukcji list subskrybentów, możliwe błędy geotargetowania i niekompletne grupy.
  • Zaufanie publiczne: komunikaty wielu miast/hrabstw o przerwie i o wycieku wzmacniają negatywny efekt reputacyjny; część klientów rozważa wypowiedzenie umów.

Rekomendacje operacyjne / co zrobić teraz

Dla władz lokalnych i służb:

  1. Komunikacja wielokanałowa: natychmiastowe „failover” na alternatywne kanały (IPAWS/EAS, lokalne SMS-y, radio FM, social media) oraz powiadomienie o ryzyku phishingu. (Patrz: brak wpływu na EAS).
  2. Reset i wymuszenie haseł wszystkich kont operatorów i subskrybentów; wdrożenie MFA; sprawdzenie list dystrybucyjnych pod kątem braków po odtworzeniu z backupu.
  3. Higiena kopii zapasowych: polityka 3-2-1, testy odtworzeniowe, skrócenie RPO; izolacja backupów od domeny produkcyjnej.
  4. Segmentacja i zasada najmniejszych uprawnień w środowiskach notyfikacji (separacja tenantów, kont serwisowych, kluczy SMS/e-mail).
  5. Monitorowanie kompromitacji: obserwacja wycieków haseł i danych kontaktowych, blokady dla znanych kampanii SMiShing/robocalls; playbooki reagowania.
  6. Ocena dostawców (third-party risk): przegląd umów SLA/OLA, wymogi co do immutable backups, testów red team i audytów niezależnych; klauzule dot. raportowania incydentów i kar umownych.

Dla mieszkańców/subskrybentów:

  • Zmień hasło używane w CodeRED (i wszędzie, gdzie było recyklingowane), włącz MFA, uważaj na fałszywe alerty przez SMS/telefon/e-mail wykorzystujące lokalny kontekst.

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

W przeciwieństwie do incydentów wpływających na ogólnokrajowy EAS/IPAWS, atak dotknął komercyjnej platformy masowego powiadamiania. Skutkiem ubocznym jest utrata dostępności i integralności bazy subskrybentów, a nie naruszenie krajowej infrastruktury ostrzegania. Jednocześnie efekt operacyjny w skali lokalnej jest znaczący – podobnie jak w innych atakach na systemy usług publicznych, np. lokalne call-centra 911, gdzie utrata danych kontaktowych utrudnia szybkie dotarcie do mieszkańców.

Podsumowanie / kluczowe wnioski

  • Legacy CodeRED został trwale wyłączony po ataku INC Ransom; trwa migracja do nowego środowiska.
  • Wykradziono i częściowo opublikowano dane użytkowników, w tym hasła – krytyczne ryzyko recyklingu haseł i kampanii socjotechnicznych.
  • Odtwarzanie z przestarzałego backupu (31.03.2025) pogłębia problem braków danych i operacyjnego „długu”.
  • Priorytetem jest higiena tożsamości, wielokanałowa komunikacja awaryjna oraz dojrzały third-party risk management.

Źródła / bibliografia

  1. Dark Reading — „CodeRED Emergency Alert Platform Shut Down Following Cyberattack”, 1 grudnia 2025. (Dark Reading)
  2. CyberScoop — „Crisis24 shuts down emergency notification system in wake of ransomware attack”, 27 listopada 2025. (CyberScoop)
  3. SecurityWeek — „Ransomware Attack Disrupts Local Emergency Alert System Across US”, 26 listopada 2025 (aktualizacja). (SecurityWeek)
  4. BleepingComputer — „OnSolve CodeRED cyberattack disrupts emergency alert systems nationwide”, 26 listopada 2025. (BleepingComputer)
  5. GovTech — „Emergency Notification System Hit by Cyber Attack”, 26 listopada 2025. (govtech.com)

Lazarus (KR): urzędnicy łączą $30 mln kradzież z giełdy Upbit z północnokoreańskimi hakerami

Wprowadzenie do problemu / definicja incydentu

Po „nietypowej wypłacie” z gorącego portfela Upbit — największej giełdy krypto w Korei Południowej — urzędnicy państwowi wskazali na północnokoreańską grupę Lazarus jako prawdopodobnego sprawcę. Według doniesień, napastnicy wyłudzili lub przejęli uprawnienia administracyjne i wytransferowali ok. 44,5 mld KRW (~30 mln USD), po czym giełda zamroziła depozyty i wypłaty oraz przeniosła środki do cold walletów. Upbit zapowiedział pokrycie strat klientów.

W skrócie

  • Cel: Upbit (Korea Płd.), gorący portfel.
  • Skala: ~30 mln USD wyprowadzonych aktywów.
  • Atrybucja wstępna: TTP wskazujące na Lazarus (KR/DPRK).
  • Działania obronne: wstrzymanie operacji on-chain, migracja do cold wallet, próby zamrożenia części środków.
  • Tło rynkowe: dzień wcześniej Naver Financial ogłosił przejęcie operatora Upbit (Dunamu) za ~10 mld USD; w toku incydentu odnotowano „abnormal withdrawal”.

Kontekst / historia / powiązania

Upbit był już celem głośnego włamania w 2019 r. (342k ETH, ~42–49 mln USD wówczas), które południokoreańska policja w 2024 r. formalnie powiązała z północnokoreańskimi grupami Lazarus/Andariel. Bieżący atak ma „podobny podpis” do sprawy z 2019 r., co wzmocniło hipotezę o DPRK.

W skali globalnej DPRK-APT (m.in. Lazarus/APT38) odpowiadały w ostatnich latach za rekordowe kradzieże krypto – np. Bybit, luty 2025: ~1,5 mld USD, oficjalnie wskazane przez FBI jako operacja powiązana z „TraderTraitor”.

Analiza techniczna / szczegóły luki

Wektor wejścia. Według urzędników napastnicy „podszyli się pod administratorów” Upbit i zainicjowali transfery, co sugeruje kompromitację kont uprzywilejowanych (phishing/OAuth/SSO abuse, kradzież kluczy) lub obejście kontroli transakcyjnych w hot walletach. Ten modus operandi — nadużycie tożsamości adminów i szybkie odprowadzenie środków do mieszarek/chain hopping — był wielokrotnie obserwowany przy operacjach Lazarusa.

Łańcuchy prania. Historycznie Lazarus stosował segmentację przepływów, równe porcjowanie transakcji, cross-chain swapy i miksery (np. Sinbad / wcześn. Blender), co odnotowywały firmy analityczne i organy ścigania. W sprawie Upbit śledczy próbowali śledzić i zamrażać fragmenty środków już w pierwszej dobie.

Wskaźniki i TTP (przykładowe):

  • Impersonacja admina / kradzież sesji / złośliwe podpisy transakcyjne (blind-signing) – technika używana także w Bybit 2025.
  • Porcjowanie wypłat na powtarzalne kwoty i wielowarstwowe miksy.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla użytkowników: krótkoterminowe wstrzymania wypłat/depozytów, opóźnienia w rozliczeniach i możliwe skoki fee. Upbit deklaruje pokrycie strat, ale presja płynnościowa może utrzymywać się do czasu pełnej rekonsyliacji.
  • Ryzyko systemowe: ataki na warstwę operacyjną giełd (tożsamość i uprawnienia) omijają typowe zabezpieczenia smart-kontraktów.
  • Ryzyko regulacyjne: nowe wytyczne dot. kluczy admina, cold-/warm-wallet policy, obowiązkowe „withdrawal throttling” i adresy-dozwolone (allowlist) są coraz bardziej prawdopodobne po serii incydentów 2024–2025. Trend potwierdza skala Bybit 2025 i statystyki DPRK z raportów analitycznych.

Rekomendacje operacyjne / co zrobić teraz

Dla giełd i kustodianów

  1. Zerowy zaufanie dla operacji admina: U2F/WebAuthn + FIDO2 dla kont uprzywilejowanych, polityka „two-person rule” dla podpisów > X USD i obowiązkowe timelocki dla wypłat z hot/warm walleta.
  2. Segmentacja kluczy i horyzontów czasowych: dziel klucze na role (init/sign/approve), ogranicz okna ważności sesji i stosuj „just-in-time access”.
  3. Automatyczne reguły AML on-chain: blokady heurystyczne na znane węzły prania DPRK, eskalacja KYC i natychmiastowe freeze requesty do partnerów.
  4. Runbooki kryzysowe: gotowe playbooki z listą kontaktów (LEA, analityka blockchain, giełdy partnerskie), „war room” i wstępnie uzgodnione komunikaty.
  5. Monitoring nieinteraktywny kluczy: HSM + polityki nieopuszczania klucza, separacja środowisk podpisu, detekcja anomalii w patternach wypłat (równe porcje, cicliczne batch’e).
  6. Ćwiczenia red-team/blue-team z scenariuszem DPRK TraderTraitor.

Dla użytkowników

  • Trzymaj większe środki w self-custody (hardware wallet), włącz allowlisty adresów i limity dobowych wypłat.
  • Weryfikuj komunikaty giełdy wyłącznie w oficjalnych kanałach i wstrzymaj się z dużymi transferami, dopóki giełda nie zakończy pełnej rekonsyliacji po incydencie.

Różnice / porównania z innymi przypadkami

  • Upbit 2019 vs. Upbit 2025: wspólne elementy to atak na warstwę operacyjną giełdy i wzorce wypłat przypisywane DPRK; różni się skala (2019: ~42–49 mln USD, 2025: ~30 mln USD) oraz dojrzałość mechanizmów zamrażania środków.
  • Bybit 2025 (1,5 mld USD): inny profil — manipulacja procesem podpisu (blind-signing) i największa znana pojedyncza kradzież, oficjalnie przypisana DPRK przez FBI; pokazuje eskalację zdolności napastnika.

Podsumowanie / kluczowe wnioski

  • Wstępna atrybucja do Lazarus (KR) jest spójna z historią ataków na Upbit i globalną aktywnością DPRK w 2024–2025.
  • Wektor tożsamościowy/administracyjny pozostaje najsłabszym ogniwem dużych giełd — „smart” kontrola wypłat musi iść w parze z twardymi procedurami dla kont uprzywilejowanych.
  • Rynek powinien traktować runbooki incident-response i automatyczne freeze’y jako standard branżowy.
  • Statystyki z 2024–2025 (1,34 mld USD skradzione przez KR-APT w 2024; 1,5 mld USD w pojedynczym incydencie 2025) wskazują, że ryzyko systemowe nie maleje mimo spadku części wskaźników rynkowych.

Źródła / bibliografia

  1. The Record: „Officials accuse North Korea’s Lazarus of $30 million theft from crypto exchange” (01.12.2025). (The Record from Recorded Future)
  2. Reuters: „Naver’s payment arm to acquire Dunamu (Upbit) in $10 bln deal” + wzmianka o „abnormal withdrawal” (27.11.2025). (Reuters)
  3. Reuters (za Yonhap): „South Korea suspects North Korea behind hack of crypto exchange Upbit” (28.11.2025). (Reuters)
  4. Chainalysis: „Bybit hack… DPRK stole ~$1.34B across 47 incidents in 2024” (24.02.2025). (Chainalysis)
  5. FBI (IC3 PSA): „North Korea Responsible for $1.5 Billion Bybit Hack” (26.02.2025). (Internet Crime Complaint Center)