Archiwa: Security News - Strona 239 z 289 - Security Bez Tabu

Kategoria: Security News

Korea: aresztowania za sprzedaż nagrań zhakowanych z 120 000 kamer IP. Co to oznacza dla bezpieczeństwa IoT?

Wprowadzenie do problemu / definicja luki

Koreańska Policja Krajowa (NPA) zatrzymała cztery osoby podejrzane o zhakowanie ponad 120 000 kamer IP zainstalowanych w domach i przedsiębiorstwach, a następnie sprzedaż części pozyskanych nagrań na zagranicznej witrynie z treściami pornograficznymi. Według komunikatu rządowego dochodzenie obejmuje również operatorów serwisu oraz nabywców i widzów materiałów, a poszkodowanym zapewniono działania ochronne i instrukcje usuwania treści.

W skrócie

  • 4 podejrzanych, działających niezależnie, wykorzystywało kamery IP do pozyskiwania i monetyzacji nagrań o charakterze seksualnym; dwóch z nich sprzedało łącznie setki nagrań za kryptoaktywa o wartości kilkudziesięciu tys. USD.
  • Policja zidentyfikowała dziesiątki lokalizacji ofiar i zaleciła reset haseł; równolegle prowadzone są działania wobec operatorów strony oraz nabywców treści.
  • Sprawa nagłaśnia chroniczny problem słabej konfiguracji kamer i używania domyślnych/łatwych haseł.

Kontekst / historia / powiązania

W Korei Południowej cyberprzestępczość związana z „ukrytymi kamerami” (tzw. molka) od lat wywołuje napięcia społeczne. Media przypominają wcześniejsze afery z wykorzystaniem mediów społecznościowych i serwisów wymiany wideo, które skutkowały surowymi wyrokami oraz wzmożonymi działaniami organów ścigania. Obecna sprawa wpisuje się w ten szerszy trend, ale akcentuje słabości urządzeń IoT w środowisku domowym.

Analiza techniczna / szczegóły luki

Z informacji śledczych wynika, że atakujący przejmowali dostęp do kamer IP, a następnie produkowali i dystrybuowali setki materiałów. W komunikacie rządowym zestawiono skalę działań poszczególnych podejrzanych (od setek do dziesiątek tysięcy przejętych urządzeń), a płatności realizowano w kryptoaktywach. Organy ścigania wskazują, że duża część przesyłanych treści na jednym z zagranicznych serwisów pochodziła właśnie od dwóch z tych sprawców.

Kluczowym czynnikiem umożliwiającym ataki były słabe lub domyślne hasła, zdalny dostęp niepotrzebnie wystawiony do Internetu oraz brak aktualizacji firmware’u — to wektor nadużywany globalnie w segmencie kamer IP. Standard ETSI EN 303 645 wprost zakazuje uniwersalnych domyślnych haseł, zalecając unikalne poświadczenia per urządzenie i wymuszanie silnych haseł przy pierwszej konfiguracji.

Praktyczne konsekwencje / ryzyko

  • Prywatność i bezpieczeństwo fizyczne: wycieki z kamer domowych (sypialnie, salony, gabinety) skutkują trwałą utratą kontroli nad wizerunkiem i ryzykiem wtórnej wiktymizacji.
  • Ryzyko prawne: w tej sprawie policja prowadzi działania nie tylko wobec sprawców, ale też nabywców i widzów nielegalnych treści, co potwierdza rosnącą presję egzekucyjną.
  • Ryzyko korporacyjne: firmy korzystające z kamer IP (recepcje, magazyny, punkty usługowe) narażają się na naruszenia RODO/ustaw o ochronie danych oraz straty reputacyjne i regulacyjne. (Wnioski na podstawie praktyk branżowych i standardów.)

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników domowych i SMB:

  1. Usuń domyślne loginy/hasła; ustaw długie (min. 14+ znaków), unikalne hasła, najlepiej generowane i przechowywane w menedżerze haseł.
  2. Wyłącz zdalny dostęp (P2P/UPnP), jeśli nie jest konieczny; włączaj tylko przez VPN lub za NAT z kontrolą dostępu. (Dobry zwyczaj zalecany w wytycznych CISA/ENISA).
  3. Aktualizuj firmware i aplikacje mobilne kamer; wybieraj dostawców zapewniających wsparcie i biuletyny bezpieczeństwa.
  4. Segmentuj sieć domową (oddzielna sieć/SSID dla IoT), egzekwuj WPA2/WPA3, wyłącz dostęp urządzeń IoT do sieci firmowej.
  5. Monitoruj logi i powiadomienia kamer (nietypowe logowania, zmiany konfiguracji), okresowo resetuj poświadczenia i sprawdzaj listę kont. (Dobre praktyki wg CISA/ENISA).

Dla zespołów bezpieczeństwa w firmach:

  • Wymagaj zgodności z ETSI EN 303 645 (brak uniwersalnych haseł, bezpieczne aktualizacje OTA, minimalizacja usług wystawionych do Internetu).
  • Wprowadzaj politykę przyłączeń dla IoT (asset inventory, NAC/MAC allowlist, VLAN dla kamer, skanowanie pod kątem domyślnych/znanych poświadczeń). (Wnioski na bazie standardów ETSI/ENISA/CISA).

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

W przeciwieństwie do spraw, w których przestępcy wymuszają tworzenie treści (np. głośne śledztwa wokół kanałów na komunikatorach), tutaj oś ataku stanowiła techniczna kompromitacja IoT i pasywna obserwacja użytkowników przez przejęte kamery. Wspólnym mianownikiem pozostaje jednak monetyzacja treści poprzez serwisy zagraniczne i płatności krypto.

Podsumowanie / kluczowe wnioski

  • Skala (120 000 kamer) potwierdza, że niedostateczna higiena bezpieczeństwa IoT ma realne, masowe skutki dla prywatności.
  • Organy ścigania koncentrują się nie tylko na sprawcach, ale też na ekosystemie popytu (nabywcy/widzowie), co może mieć efekt prewencyjny.
  • Minimalne wymogi bezpieczeństwa (brak domyślnych haseł, aktualizacje, segmentacja) są dziś standardem — warto je formalizować w politykach i umowach z dostawcami.

Źródła / bibliografia

  1. Korea.kr – oficjalny komunikat Policji Krajowej (01.12.2025). (Korea.kr)
  2. BleepingComputer: „Korea arrests suspects selling intimate videos from hacked IP cameras” (02.12.2025). (BleepingComputer)
  3. The Washington Post: „Hacking scheme targeted 120,000 home cameras for sexual footage” (02.12.2025). (The Washington Post)
  4. The Korea Herald: „120,000 private cameras hacked…” (2025). (Korea Herald)
  5. ETSI EN 303 645 v3.1.3 – Consumer IoT Security (09.2024). (ETSI)

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)

MediaTek: grudniowy biuletyn bezpieczeństwa (grudzień 2025) — luki w module modemu i GPU, aktualizacje dostępne

Wprowadzenie do problemu / definicja luki

MediaTek opublikował December 2025 Product Security Bulletin (1 grudnia 2025 r.), opisując szereg podatności wpływających na wybrane układy SoC firmy. Trzonem są błędy w komponencie modemu (baseband) prowadzące do awarii (DoS), a także średniej wagi problem ujawnienia informacji w GPU pdma. MediaTek informuje, że brak dowodów na aktywne wykorzystanie zgłoszonych luk w środowisku produkcyjnym w momencie publikacji.

W skrócie

  • 13 luk wysokiej ważności (m.in. CVE-2025-20792, 20753–20759, 20750–20756, 20790–20791) — głównie błąd obsługi wyjątków, dereferencje wskaźników NULL i niepoprawna walidacja wejścia w modemie.
  • 17 luk średniej ważności (m.in. CVE-2025-20763–20777, 20788–20789) — w tym ujawnienie informacji w GPU pdma (CVE-2025-20789).
  • Biuletyn Androida z 1 grudnia 2025 r. potwierdza poziomy poprawek 2025-12-01 i 2025-12-05; najpoważniejsza w nim luka dotyczy Framework (RDoS), a Google sygnalizuje ograniczone, ukierunkowane wykorzystanie kilku CVE po stronie platformy — to kontekst dla harmonogramu łatek u producentów.

Kontekst / historia / powiązania

Comiesięczne biuletyny MediaTek korelują z Android Security Bulletin (ASB). Partnerzy Androida otrzymują zgłoszenia z co najmniej miesięcznym wyprzedzeniem, a finalne „poziomy poprawek” (ang. patch levels) pozwalają producentom OEM zadeklarować zakres załatanych podatności. W grudniu 2025 r. Google utrzymuje podwójny poziom: 2025-12-01 oraz 2025-12-05.

Analiza techniczna / szczegóły luki

Zakres dotkniętych komponentów

  • Modem (baseband): dominujące błędy to nieprzechwycone wyjątki (CWE-248), dereferencja wskaźnika NULL (CWE-476), osiągalne asercje (CWE-617) i błędy kontroli granic. Skutkują one głównie awarią systemu/komponentu przy przetwarzaniu niepoprawnych ramek/protokołów. Przykłady:
    • CVE-2025-20792 — Reachable assertion w modemie → możliwy crash systemu przez niewłaściwą walidację wejścia.
    • CVE-2025-20754 — uncaught exception wskutek błędu kontroli granic → DoS.
    • CVE-2025-20755, 20790 — NULL pointer dereference → awaria aplikacji/komponentu modemu.
  • GPU pdma: CVE-2025-20789 — ujawnienie informacji przez wysyłane dane (CWE-201), opisane jako brak sprawdzenia granic, co może ujawniać fragmenty pamięci. NVD potwierdza rejestr tego CVE.

Wpływ na platformy/SoC
MediaTek listuje szeroką pulę układów z rodzin 67xx/68xx/69xx/79xx/86xx/87xx/88xx, w tym popularne układy dla smartfonów średniej i wyższej klasy (np. MT6895/Dimensity 9000-series, MT6985/Dimensity 9300-series i inne). Lista różni się per-CVE; pełny wykaz SoC dla każdego wpisu znajduje się w biuletynie.

Praktyczne konsekwencje / ryzyko

  • Atak powierzchnią radiową (baseband): wiele błędów w modemie można wyzwolić zdalnie w warstwie sieci komórkowej (np. przez złośliwie sformatowane komunikaty/procedury), co nie wymaga interakcji użytkownika. W typowym scenariuszu skutkiem jest DoS/soft-reboot telefonu, utrata połączeń lub reset stosu radiowego. (Wnioski na bazie kategorii błędów i opisów DoS).
  • Ujawnienie informacji (GPU pdma): ryzyko wycieku fragmentów pamięci między procesami/komponentami graficznymi — zależne od kontekstu i konfiguracji sterowników.
  • Brak dowodów na aktywne exploitowanie według MediaTek, ale ASB 12/2025 sygnalizuje, że po stronie platformy Android niektóre CVE są wykorzystywane ukierunkowanie — to argument za szybkim aktualizowaniem urządzeń.

Rekomendacje operacyjne / co zrobić teraz

  1. Aktualizacje OEM: wdrożyć najnowsze firmware dla urządzeń z układami MediaTek. Dla Androida priorytetem jest osiągnięcie poziomu poprawek 2025-12-05, który „zamyka” komplet biuletynu z grudnia.
  2. Weryfikacja parku urządzeń: zmapować modele oparte na SoC z list w biuletynie i zaplanować rollout łatek (MDM/EMM), zaczynając od urządzeń o krytycznych rolach biznesowych i w środowiskach o wysokim ryzyku ekspozycji radiowej (np. podróże międzynarodowe, roaming).
  3. Hardening radiowy (tymczasowe):
    • W razie opóźnień z łatkami rozważyć ograniczenie 2G/3G (o ile polityka firmowa na to pozwala) i utrzymywać preferencję LTE/NR; monitorować nietypowe restarty modemu.
    • Włączyć systemowe logowanie zdarzeń i telemetrię MDM pod kątem nagłych utrat zasięgu/restartów. (Najlepsze praktyki defensywne — brak oficjalnego mitigacji vendorowej poza aktualizacją).
  4. Testy regresji: po aktualizacji wykonać testy połączeń (VoLTE/VoNR), roamingu, eSIM i obciążeniowe grafiki (dla GPU) pod kątem stabilności.
  5. Procedury CSIRT/SOC: dodać sygnatury i reguły detekcji nietypowych restartów basebandu w EDR/telemetrii mobilnej oraz playbook do szybkiej izolacji urządzeń z powtarzalnymi crashami.

Różnice / porównania z innymi przypadkami

  • W poprzednich cyklach (np. listopad 2025 w ASB) dominowały poprawki warstwy Framework/System; w grudniu 2025 r. akcent u MediaTek przesuwa się na baseband — co zwiększa znaczenie testów w warunkach sieci operatorów po aktualizacji.
  • W odróżnieniu od krytycznych RCE w stosie aplikacyjnym zdarzających się w ASB, luki MediaTek w tym miesiącu to głównie DoS/ID na poziomie sterowników i firmware’u — mniejsza szansa na pełne przejęcie, ale większy wpływ na dostępność i stabilność łączności.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj do patch level 2025-12-05 wszędzie, gdzie to możliwe.
  • Baseband w centrum uwagi: spora liczba błędów w modemie → ryzyko zdalnego DoS i utraty usług komórkowych.
  • Brak sygnałów o masowym exploitowaniu po stronie MediaTek, ale ogólny krajobraz Androida (ASB) potwierdza, że część luk bywa celowana — nie zwlekaj z rolloutem.

Źródła / bibliografia

  1. MediaTek — December 2025 Product Security Bulletin (opublikowano 1 grudnia 2025). (MediaTek)
  2. Google AOSP — Android Security Bulletin — December 2025 (poziomy poprawek 2025-12-01 / 2025-12-05, sygnały o ograniczonym exploitowaniu). (Android Open Source Project)
  3. NVD — CVE-2025-20789 (GPU pdma, ujawnienie informacji). (NVD)
  4. NVD — CVE-2025-20770 (w pakiecie luk średnich MediaTek; rekord dodany do NVD). (NVD)

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)

Albiriox: nowy trojan na Androida rozwijany przez rosyjskojęzycznych cyberprzestępców (MaaS, ODF, 400+ celów)

Wprowadzenie do problemu / definicja luki

Cleafy ujawniło nową rodzinę złośliwego oprogramowania na Androida o nazwie Albiriox – komercyjny RAT/banking trojan sprzedawany w modelu Malware-as-a-Service (MaaS) i zaprojektowany do On-Device Fraud (ODF), czyli wykonywania oszustw bezpośrednio na zainfekowanym urządzeniu ofiary. Albiriox łączy zdalne sterowanie (VNC/Accessibility) z nakładkami (overlay), by przejmować sesje w aplikacjach bankowych i kryptowalutowych. Autorzy i operatorzy mają być rosyjskojęzyczni.

W skrócie

  • Model biznesowy: subskrypcja MaaS; w październiku kosztował 650 USD/msc (okres promocyjny), następnie 720 USD/msc.
  • Zakres celów: ponad 400 twardo zakodowanych aplikacji (banki, fintech, płatności, giełdy, portfele, trading, a nawet gry).
  • Techniki: zdalny podgląd/sterowanie ekranem przez Accessibility VNC (AcVNC); nakładki systemowe i „czarny ekran” do maskowania aktywności; komunikacja C2 po niezaszyfrowanym gnieździe TCP; custom builder zintegrowany z Golden Crypt (anty-AV).
  • Dystrybucja: kampanie smishingowe, fałszywe strony Google Play (np. aplikacja dyskontu Penny), dropper → właściwy ładunek; wczesne cele w Austrii.
  • Status rozwoju: moduł zdalnego sterowania dojrzały; moduł overlay wciąż doszlifowywany.

Kontekst / historia / powiązania

Pierwsze ślady Albiriox pojawiły się we wrześniu 2025 r. w kanałach Telegram oraz na rosyjskojęzycznych forach, gdzie autor prowadził rekrutację do bety. W październiku projekt przeszedł w pełnopłatny MaaS. Doniesienia mediowe (SecurityWeek, The Hacker News, Malwarebytes) spójnie potwierdzają ODF-owy profil zagrożenia oraz masowy zasięg celów.

Analiza techniczna / szczegóły luki

Łańcuch infekcji i dystrybucja

  • Smishing z linkami skróconymi prowadzącymi do fałszywych stron Google Play, podszywających się m.in. pod „PENNY” (DACH). Użytkownik pobiera droppera, który żąda rozszerzonych uprawnień i dociąga właściwy ładunek. W nowszym wariancie ofiara podaje numer telefonu (akceptowane austriackie formaty), a link przychodzi przez WhatsApp; formularz wysyła dane do bota Telegram.

Ładowanie / ukrywanie

  • Zastosowanie technik pakowania (np. JSONPacker) i Golden Crypt w pipeline buildera, by utrudnić statyczną detekcję i wczesne wykrycie.

C2 i sterowanie

  • Kanał C2 to niezaszyfrowany TCP socket z handshake (HWID, model urządzenia, wersja Androida), heartbeat (ping/pong) i wymianą komend w JSON.

Zdolności ODF

  • AcVNC (Accessibility VNC) omija ograniczenia FLAG_SECURE i pozwala operatorowi oglądać elementy UI na poziomie węzłów, a także automatyzować dotknięcia, przewijanie, wpisywanie tekstu, uruchamianie/odinstalowanie aplikacji itd.
  • Nakładki: „System Update”, czarny ekran (maskowanie cudzych działań w tle) oraz targeted overlay dla wybranych aplikacji.

Zasięg celów

  • Lista hard-coded obejmuje 400+ aplikacji finansowych (bankowość, portfele, giełdy, płatności), ale też aplikacje towarzyszące (np. inwestycyjne) – co podnosi skuteczność przejęć i lateralnego ruchu w ekosystemie finansowym użytkownika.

Praktyczne konsekwencje / ryzyko

  • Omijanie MFA i fingerprintingu urządzeń: operacje wykonywane są na urządzeniu ofiary i w jej ważnej sesji, co utrudnia wykrycie anomalii wyłącznie po stronie serwera banku.
  • Real-time fraud: operator widzi ekran i akceptuje autoryzacje, inicjuje przelewy, zmienia beneficjentów, wyłącza powiadomienia – często przy włączonym „czarnym ekranie”.
  • Skalowalność (MaaS): niski próg wejścia (subskrypcja, builder, crypting) → szybka replikacja kampanii.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT:

  1. Zero sideloadingu: instaluj aplikacje wyłącznie z Google Play/Samsung Galaxy Store; nie klikaj linków z SMS/WhatsApp prowadzących do „Play”.
  2. Sprawdź uprawnienia – szczególnie Accessibility, instalowanie z nieznanych źródeł, nakładki na inne aplikacje.
  3. Google Play Protect + mobilny EDR/AV; aktualizacje Androida i aplikacji bankowych na bieżąco.
  4. Higiena kont: alerty dla nowych beneficjentów, dużych przelewów, logowań z nowych urządzeń; gdzie to możliwe preferuj MFA sprzętowe/aplikacyjne, nie SMS.
  5. Incident response: przy podejrzeniu infekcji – tryb samolotowy, odinstalowanie podejrzanych aplikacji, skan, zmiana PIN/hasła ekranu i haseł do banku z innego urządzenia; rozważ fabryczny reset po backupie.

Dla banków/fintechów:

  1. Detekcja ODF: korelacja sygnałów klient-side (np. anomalia Accessibility, black-screen, foreground service, nietypowe wzorce inputu) z behawioralną biometrią i telemetrią transakcyjną.
  2. Polityki wysokiego ryzyka: wstrzymanie/step-up auth przy wykryciu akcji „set_vnc_mode”, „blank_screen”/overlay-like behavior (sygnały wtórne po stronie aplikacji). (Wnioski na podstawie komend/opisów z analizy Cleafy).
  3. App hardening: egzekwowanie FLAG_SECURE + detekcja nadużyć Accessibility (heurystyki), ograniczenia dla WebView/overlay, kontrola integry aplikacji.
  4. Bot intelligence: listy IOC, telemetryczne wskaźniki kampanii (domeny phishing/WhatsApp/Telegram) i szybkie blokady w bramkach SMS.

Różnice / porównania z innymi przypadkami

  • W przeciwieństwie do wielu „klasycznych” trojanów bankowych, Albiriox od początku projektowano pod pełny przejęcie urządzenia i ODF (a nie tylko kradzież danych/uwierzytelnień). Jego AcVNC dookreśla trend obchodzenia FLAG_SECURE przez mechanizmy Accessibility.
  • Skala celów (400+) i komercyjny builder + crypting odróżniają Albiriox od wielu młodszych rodzin; to raczej „produkt” z zapleczem operatorskim i szybkim cyklem iteracji.

Podsumowanie / kluczowe wnioski

Albiriox to świeża, szybko rozwijająca się platforma MaaS dla oszustw na urządzeniu, która łączy zdalną kontrolę (Accessibility/VNC), nakładki oraz szeroki zestaw automatyzacji. W połączeniu z masowym katalogiem celów i niskim progiem wejścia (subskrypcja), ryzyko dla bankowości mobilnej i krypto jest realne – zwłaszcza tam, gdzie brakuje detekcji sygnałów ODF po stronie aplikacji i back-office.

Źródła / bibliografia

  1. Cleafy Labs: Albiriox Exposed: A New RAT Mobile Malware Targeting Global Finance and Crypto Wallets (27.11.2025). (cleafy.com)
  2. SecurityWeek: New Albiriox Android Malware Developed by Russian Cybercriminals (01.12.2025). (SecurityWeek)
  3. The Hacker News: New Albiriox MaaS Malware Targets 400+ Apps for On-Device Fraud and Screen Control (01.12.2025). (The Hacker News)
  4. Malwarebytes Labs: New Android malware lets criminals control your phone and drain your bank account (01.12.2025). (malwarebytes.com)

Europol zamyka Cryptomixer: zajęto ponad 25 mln euro w bitcoinach, serwery w Szwajcarii i domenę cryptomixer.io

Wprowadzenie do problemu / definicja luki

Europejskie służby wspierane przez Europol i Eurojust przeprowadziły wspólną akcję przeciwko usłudze Cryptomixer (cryptomixer.io) — platformie do miksowania bitcoinów, która miała ułatwiać pranie środków z przestępstw (m.in. ransomware, oszustw kartowych i handlu na darknetach). W ramach tygodniowych działań (24–28 listopada 2025 r.) zajęto trzy serwery w Szwajcarii, ponad 12 TB danych, domenę oraz >25 mln euro w BTC. Europol szacuje, że od 2016 r. przez usługę przeszło co najmniej ~1,3–1,5 mld USD w bitcoinach powiązanych z działalnością przestępczą.

W skrócie

  • Co się stało: Demontaż i zajęcie majątku usługi miksującej Cryptomixer w ramach operacji „Olympia”.
  • Skala przejęć: >25 mln euro w BTC, 3 serwery (Szwajcaria), 12+ TB danych, domena cryptomixer.io.
  • Znaczenie: Platforma „pierwszego wyboru” dla grup cyberprzestępczych; od 2016 r. ~1,3–1,5 mld USD przepływów w BTC.
  • Koordynacja: Niemcy, Szwajcaria, Europol, Eurojust; działania prowadzone z Centrum Koordynacyjnym w Zurychu.

Kontekst / historia / powiązania

Akcja wpisuje się w trwającą ofensywę organów ścigania przeciw infrastrukturze służącej praniu kryptowalut. W 2023 r. rozbito ChipMixer, wówczas jeden z największych mixerów; sprawa dotyczyła miliardowych przepływów i stanowiła sygnał, że służby są gotowe na działania techniczne wymierzone w usługi „anonimizujące” łańcuchy bloków. Cytowany przez CyberScoop komunikat Europolu porównuje aktualny demontaż do tamtej operacji.

Analiza techniczna / szczegóły luki

Jak działał mixer?
Model usług typu cryptocurrency mixer polega na przyjmowaniu środków od wielu użytkowników, „mieszaniu” ich w jednym „basenie” (ang. pool) i redystrybucji na adresy docelowe po losowych opóźnieniach i zróżnicowanych kwotach. Celem jest utratnienie heurystyk łańcuchowych (np. analizy przepływów, clusteringu adresów). Europol wskazuje, że w przypadku Cryptomixer depozyty były przetrzymywane przez „długi, randomizowany okres”, a wypłaty trafiały o różnych porach na różne adresy — klasyczna taktyka utrudniająca przypisanie środków do konkretnych źródeł.

Artefakty dowodowe i przejęta infrastruktura
Przejęcie >12 TB danych (prawdopodobnie logów operacyjnych, konfiguracji serwerów i kopii baz) może umożliwić:

  • korelację wpłat/wypłat mimo segmentacji portfeli (np. na bazie time-correlation);
  • odtworzenie mapy klastrów adresowych i tzw. „wyjść resztowych”;
  • identyfikację operatorów i VIP-klientów (np. z zapisów paneli admina/API).
    Skala przejętych danych i zajęcie domeny zwiększają szansę na wtórne śledztwa wobec powiązanych usług i giełd fiat/krypto.

Praktyczne konsekwencje / ryzyko

  • Krótkoterminowo: zakłócenie typowych łańcuchów prania środków (post-exfil) dla operatorów ransomware, grup oszustw inwestycyjnych i handlu towarami zakazanymi; wzrośnie presja na alternatywne miksery/bridges/DEX-y.
  • Średnioterminowo: migracja do innych usług miksujących (często mniej dojrzałych operacyjnie), do cross-chain bridges oraz layerów prywatności (CoinJoin, Chaumian, protokoły o niskiej przejrzystości). Wnioski z 12 TB danych mogą napędzić kolejne targetowane dochodzenia.
  • Ryzyko wtórne dla firm: wzrost prób cash-outu na giełdach i u brokerów OTC z większą obfuskacją śladu (np. peeling chains, hop-scotch). Zalecane zaostrzenie reguł AML/CTF i tuningu narzędzi EDD. (wniosek na podstawie ogłoszeń Europolu/Eurojust o przejęciach i celach dochodzeń).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SOC/CTI/DFIR

  1. Zaktualizuj wskaźniki zagrożeń (IoC): listy adresów powiązanych z cryptomixer.io i widokiem „post-mix” (np. czasy dyspersji, typowe patterny kwot). Monitoruj nowe klastry pojawiające się po 24–28.11.2025. (na podstawie daty „action week” podanej przez Reuters/Eurojust).
  2. Hunting w łańcuchu: wyszukuj randomized split payouts oraz różnicowane fee patterns charakterystyczne dla mixerów; koreluj z TTP-kami grup ransomware po wypłatach okupu (np. gwałtowny fan-out adresów). (kontekst: opis działania miksowania przez Europol/CyberScoop).
  3. Współpraca z dostawcami analiz blockchain (Chainalysis/TRM/Elliptic): poproś o świeże tagi adresowe dla klastrów powiązanych z Cryptomixer i o retro-tracing w oknach czasowych wokół aresztowań/seizure.

Dla działów AML/FinCrime (VASP, fintech, banki)

  1. Podnieś czułość scenariuszy AML dla: „mixer exposure”, „post-mixer deposits”, „rapid peeling”, „cross-bridge jumps”.
  2. EDD/KYC: ręczna weryfikacja klientów z ekspozycją na adresy powiązane z cryptomixer.io; wdrożenie „lookback review” min. 12–18 miesięcy.
  3. Blokady transakcyjne: tymczasowe progi alertowe dla transakcji z charakterystycznym time-randomized batchingiem.
  4. Zabezpieczenie dowodów: zgodnie z wymogami łańcucha dowodowego (hashy, snapshotów mempool/UTXO), bo w wielu jurysdykcjach spodziewane są wnioski o MLAT/pomoc prawną (na co wskazują zapowiedzi o „ongoing investigations”).

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

  • Cryptomixer (2025): 3 serwery (CH), >12 TB danych, >25 mln EUR w BTC, ~1,3–1,5 mld USD przepływów od 2016 r.; część Operacji „Olympia”.
  • ChipMixer (2023): jedna z największych usług w tamtym czasie; również wspierana przez Europol akcja z zajęciami serwerów i wielomilionowymi środkami — wskazywana przez CyberScoop jako precedens.

Podsumowanie / kluczowe wnioski

Demontaż Cryptomixer potwierdza, że „privacy-as-a-service” oparte na prostych mixerach ma coraz mniejsze szanse na długofalowe przetrwanie w świetle skoordynowanych działań międzynarodowych. Seizure domeny, infrastruktury i danych otwiera drogę do wtórnych identyfikacji sprawców oraz śledzenia funduszy na kolejnych etapach obiegu. Należy spodziewać się krótkoterminowych tarć wśród grup ransomware i przestępczej migracji do mostów cross-chain i bardziej złożonych technik obfuskacji. Dla firm oznacza to potrzebę wzmocnienia scenariuszy AML/CTF i detekcji on-chain właśnie teraz.

Źródła / bibliografia

  1. CyberScoop: Authorities take down Cryptomixer, seize $28M in Switzerland (01.12.2025). (CyberScoop)
  2. Europol: Europol and partners shut down ‘Cryptomixer’ – EUR 25 million in cryptocurrency seized during the operation (01.12.2025). (Europol)
  3. Eurojust: Cryptocurrency mixing service used to launder money taken down (01.12.2025). (Eurojust)
  4. Reuters: Swiss, German authorities shut down cryptomixer.io… (01.12.2025). (Reuters)
  5. The Record: Cryptomixer platform raided by European police (02.12.2025). (The Record from Recorded Future)

Android Security Bulletin – grudzień 2025: krytyczne luki w Framework i kernelu, 2 exploity „in the wild”

Wprowadzenie do problemu / definicja luki

Google opublikował Android Security Bulletin (ASB) – grudzień 2025. Najnowsze poprawki bezpieczeństwa mają dwa poziomy: 2025-12-01 oraz 2025-12-05. Najpoważniejsza usterka to krytyczny DoS w komponencie Framework (zdalny atak bez uprawnień), a w sekcji Kernel pojawiają się krytyczne EoP (m.in. pKVM, IOMMU). Google potwierdza też dwie luki wykorzystywane celowo (limited, targeted exploitation).

W skrócie

  • Poziomy poprawek: 2025-12-01 i 2025-12-05 (drugi obejmuje wszystkie wcześniejsze).
  • Najpoważniejsze błędy:
    • Framework: zdalny DoS (CVE-2025-48631) + liczne EoP/ID/DoS (wysoka ważność).
    • Kernel: kilka krytycznych EoP (pKVM, IOMMU).
  • Eksploatowane w praktyce: CVE-2025-48633 (ID w Framework) i CVE-2025-48572 (EoP w Framework).
  • Project Mainline (GPSU): w tym miesiącu brak poprawek bezpieczeństwa.

Kontekst / historia / powiązania

ASB dostarcza bazowe łatki dla całego ekosystemu Android, a producenci SoC i OEM-i publikują uzupełniające biuletyny (np. Pixel, Samsung, Qualcomm). Grudzień to jeden z kwartalnych „większych” dropów, kiedy część zmian trafia także do AOSP w 24–48 h po wydaniu.

Analiza techniczna / szczegóły luki

Framework (poziom 2025-12-01)

  • CVE-2025-48631 (DoS, Critical) – zdalne wywołanie awarii bez dodatkowych uprawnień.
  • Szereg EoP (np. CVE-2025-48572), ID (np. CVE-2025-48633) i DoS o wysokiej ważności, obejmujących Android 13–16.
  • Dwie pozycje (CVE-2025-48633, CVE-2025-48572) oznaczone jako wykorzystywane w ograniczonych, ukierunkowanych kampaniach.

System (poziom 2025-12-01)

  • Dominują EoP i ID o wysokiej ważności (m.in. historyczne CVE-2023-40130 utrzymywane w matrycy poprawek).

Kernel (poziom 2025-12-05)

  • Krytyczne EoP w pKVM (CVE-2025-48623, -48637, -48638) oraz IOMMU (CVE-2025-48624).
  • Dodatkowo EoP/ID o wysokiej ważności w subsystemach sieciowych, epoll i KVM.
  • Zaktualizowano także LTS 5.4 → min. 5.4.292 (zależnie od wersji startowej urządzenia).

Komponenty dostawców

  • Arm (Mali) i Imagination (PowerVR) – kilka podatności High.
  • MediaTek/Unisoc – liczne problemy głównie w Modem/IMS/Preloader (High).
  • Qualcomm (w tym closed-source) – pozycje High i Critical (m.in. kernel/bootloader).

Praktyczne konsekwencje / ryzyko

  • Atak zdalny (DoS) na Framework może powodować zawieszanie/wyłączenie usług i potencjalne okna dla dalszych wektorów.
  • Krytyczne EoP w kernelu (pKVM/IOMMU) to eskalacja uprawnień i izolacja VM zagrożona — istotne w kontekście work-profile/COPE i MDM.
  • Modemy (MediaTek/Unisoc): ryzyko przechwycenia/zakłócenia komunikacji lub RCE/EoP w warstwie baseband przy specyficznych bodźcach radiowych.
  • Dwie luki „in the wild” wymagają pilnego wdrożenia poprawek na urządzeniach wysokiego ryzyka (VIP, dziennikarze, sektor publiczny).

Rekomendacje operacyjne / co zrobić teraz

  1. Cel wdrożenia: patch level 2025-12-05 (zawiera kompletny zestaw). W MDM ustaw politykę „minimum patch level = 2025-12-05”.
  2. Pixel/Samsung i inni OEM: monitoruj biuletyny producentów; dla Samsunga grudniowy SMR Dec-2025 agreguje łatki Google + SVE.
  3. Priorytetyzacja floty:
    • Najpierw urządzenia z Android 15–16 używane do pracy z danymi wrażliwymi.
    • Następnie terminale z SoC MediaTek/Unisoc (ze względu na modem).
  4. Hardening tymczasowy (do czasu patcha):
    • Ogranicz uprawnienia i Background Activity Launch dla aplikacji o podwyższonym ryzyku.
    • W MDM włącz blokadę instalacji spoza Play i Play Protect skanowanie na żądanie.
    • W sieci mobilnej wymuś DNS filtrujący i tunnel split minimalny dla urządzeń z dostępem zdalnym/VPN.
  5. Detekcja/IR:
    • Koreluj crash-loop/ANR usług z nietypowym ruchem sieciowym (DoS w Framework może być symptomem rekonesansu).
    • Poluj na wskaźniki naruszeń izolacji VM/KVM (np. nietypowe błędy vCPU, logi pKVM).

Różnice / porównania z innymi przypadkami

  • Względem biuletynów z XI 2025 r., grudzień akcentuje kernel (pKVM/IOMMU) oraz większą liczbę poprawek dostawców SoC/GPU.
  • W odróżnieniu od części poprzednich miesięcy, Project Mainline w grudniu nie wnosi osobnych łatek bezpieczeństwa (tylko platforma/OEM).

Podsumowanie / kluczowe wnioski

  • Instaluj 2025-12-05 ASAP — pełne pokrycie luk, w tym krytyczne EoP w kernelu.
  • Zarządzaj ryzykiem do czasu aktualizacji: twarde polityki MDM, ograniczenia uprawnień, monitoring anomalii.
  • Śledź biuletyny OEM/SoC — część poprawek (Qualcomm/MediaTek/Unisoc/Arm/Imagination) jest publikowana poza AOSP.

Źródła / bibliografia

  1. Android Security Bulletin — December 2025 (AOSP), publikacja 1 grudnia 2025 r. (Android Open Source Project)
  2. Android Security Bulletins – Overview (AOSP): cykl wydawniczy, dostępność łatek w AOSP. (Android Open Source Project)
  3. Samsung Mobile SMR – Firmware Updates (Dec-2025): agregacja poprawek Google + SVE. (Samsung Mobile Security)