Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 369 z 487

Autor: Wojciech Ciemski

Fałszywe odnowienia subskrypcji „cloud storage” zalewają skrzynki: jak działa kampania i jak się chronić

Wprowadzenie do problemu / definicja „luki”

W ostatnich miesiącach rośnie skala kampanii oszustw e-mailowych udających powiadomienia o problemach z płatnością za „chmurę” lub brakiem miejsca. Mechanizm jest klasycznym phishingiem/„subscription renewal scam”: wiadomość straszy utratą danych (zdjęć, backupów, dokumentów), wymusza pośpiech i prowadzi do stron podszywających się pod portale usług chmurowych, aby skłonić ofiarę do zapłaty lub podania danych karty.

W skrócie

  • Wiadomości są masowo wysyłane z wielu (często losowo wyglądających) domen i potrafią przychodzić kilka razy dziennie.
  • Linki w mailach prowadzą przez adresy na storage.googleapis.com (infrastruktura Google Cloud Storage), gdzie hostowane są proste pliki HTML pełniące rolę przekierowań (redirectorów).
  • Strony docelowe udają „panel chmury”, pokazują fałszywy „skan” (zawsze „pełno”) i obiecują np. „lojalnościowy” rabat 80%.
  • Dalej ofiara bywa przekierowana na oferty partnerskie (affiliate) niezwiązane z chmurą (VPN-y, „security software”), a finalnie na formularze płatności zbierające dane karty.
  • Kluczowa zasada obrony: nie klikaj linku z maila — stan konta weryfikuj wyłącznie w oficjalnej aplikacji/serwisie dostawcy.

Kontekst / historia / powiązania

To nie jest „nowa technologia ataku”, tylko bardzo skuteczna socjotechnika: oszuści uderzają w realny lęk użytkowników przed utratą zdjęć i kopii zapasowych. Podobne alerty przed tego typu „kończącą się chmurą” publikowała m.in. Federal Trade Commission, podkreślając, że nawet gdy wiadomość „wygląda legitnie”, link do „upgrade” może prowadzić do phishingu lub malware.

Analiza techniczna / szczegóły kampanii

1) Warstwa e-mail (delivery + treść)

Według analizy BleepingComputer, kampania używa:

  • wielu domen nadawczych (często wyglądających jak generowane losowo),
  • tematów wiadomości budujących presję czasu i strach (np. „Payment Declined”, „Account blocked”, daty usunięcia danych),
  • personalizacji (imię/adres e-mail, „ID konta”, „numer subskrypcji”), aby podnieść wiarygodność.

2) Warstwa linków: „zaufany” pierwszy skok

Wszystkie badane wiadomości zawierały link do https://storage.googleapis.com/, gdzie atakujący umieszczali statyczne pliki HTML robiące przekierowanie na domeny kontrolowane przez oszustów. To ważny detal: część filtrów traktuje domenę dużego dostawcy jako „mniej podejrzaną”, co poprawia dostarczalność i klikalność.

3) Landing page: fałszywy portal + „skan”

Strony docelowe:

  • podszywają się pod „cloud portal”, używają brandingów „cloud” (w tym logotypów kojarzonych z chmurą),
  • straszą, że backupy nie działają i dane zostaną usunięte,
  • po kliknięciu „Continue” wykonują „scan”, który zawsze pokazuje przepełnienie (np. Photos/Drive/Mail).

4) Monetyzacja: affiliate → checkout → dane karty

Po „aktualizacji planu” użytkownik nie trafia do prawdziwego panelu usługi, tylko na strony partnerskie promujące inne subskrypcje (np. VPN) i finalnie na formularze płatności zbierające dane karty, co generuje zysk z afiliacji i/lub bezpośredniego wyłudzenia.

Praktyczne konsekwencje / ryzyko

  1. Utrata pieniędzy – opłata za produkt, którego nie potrzebujesz (lub który nic nie „naprawi”), i potencjalne obciążenia cykliczne.
  2. Kradzież danych karty – przechwycenie numeru, CVV, danych rozliczeniowych i późniejsze transakcje fraudowe.
  3. Ryzyko dalszej kompromitacji – jeśli ofiara użyje tych samych haseł gdzie indziej, poda dane logowania lub zainstaluje „polecane” oprogramowanie, atak może eskalować (konto e-mail → reset haseł → przejęcia usług).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i helpdesku (SOHO / SMB)

  • Nie klikaj linków z maila. Zamiast tego wejdź wprost do aplikacji/serwisu dostawcy i sprawdź status subskrypcji.
  • Zgłaszaj phishing: w UK rządowa ścieżka to przekazanie podejrzanego maila na adres wskazany przez GOV.UK (oraz zgłoszenie SMS na 7726).
  • Jeśli wpisałeś dane karty: natychmiast kontakt z bankiem, zastrzeżenie/zmiana karty, monitoring transakcji i rozważenie chargeback.

Dla organizacji (SOC / SecOps / IT)

  • Reguły antyphishingowe pod motyw „cloud storage full/payment failed” (subject + frazy + presja czasu + „account ID”).
  • Analiza URL-chain: sandbox/detonacja, rozpakowanie przekierowań, reputacja domen końcowych (często losowe/świeże).
  • Polityka płatności: każda „pilna” płatność/subskrypcja musi przejść weryfikację poza kanałem e-mail (np. portal dostawcy, ticket + approval).
  • Edukacja + symulacje: krótkie playbooki „co zrobić po kliknięciu” i szybkie kanały zgłoszeń do SOC/IT.

Różnice / porównania z innymi przypadkami

Najprostszy test wiarygodności to porównanie „straszaków” z realną polityką dostawców:

  • Google (Google One/Drive): po anulowaniu/wygaśnięciu planu tracisz „dodatkową” przestrzeń, ale treści są kasowane dopiero po dłuższym okresie przekroczenia limitu (Google opisuje próg „2 lata lub dłużej” over-quota). To nie jest „usuniecie jutro”.
  • Microsoft (OneDrive): po przekroczeniu limitu konto może przejść w tryb ograniczony (read-only), a dostawca wskazuje, że po 6 miesiącach może usunąć OneDrive i pliki, jeśli nic nie zrobisz — nadal nie jest to jednak „natychmiastowe skasowanie w 24h”, jak sugerują scam-maile.

W praktyce scamy bazują na „natychmiastowej katastrofie”, podczas gdy realne procesy zwykle obejmują okresy karencji, ograniczenia funkcji i dłuższe okna na reakcję.

Podsumowanie / kluczowe wnioski

  • To masowa kampania phishingowo-affiliate’owa: presja czasu + strach o dane + „zaufany” pierwszy link (hostowany na infrastrukturze dużego dostawcy) + fałszywy „skan” + wyłudzenie płatności.
  • Najskuteczniejsza obrona to procedura: zero klikania w linki z maila → weryfikacja w aplikacji/na oficjalnej stronie → zgłoszenie phishingu.
  • „Twoje pliki zostaną usunięte dziś/jutro” jest typowym czerwonym alarmem — polityki dostawców są znacznie bardziej rozciągnięte w czasie.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii, mechanika linków i monetyzacji. (BleepingComputer)
  2. Federal Trade Commission – ostrzeżenie konsumenckie dot. fałszywych komunikatów o braku miejsca w chmurze i zasad weryfikacji. (Consumer Advice)
  3. GOV.UK – kanały raportowania phishingu (e-mail/SMS) i podstawowe zasady bezpieczeństwa. (GOV.UK)
  4. Google – zasady Google One (m.in. konsekwencje over-quota i horyzont usuwania danych). (Google Help)
  5. Microsoft – zachowanie OneDrive przy przekroczeniu limitu i informacja o możliwym usunięciu po 6 miesiącach. (Microsoft Support)

Ransomware w mieście New Britain: co wiemy o ataku na systemy urzędu i jak minimalizować ryzyko w samorządach

Wprowadzenie do problemu / definicja luki

W drugiej połowie stycznia 2026 r. samorząd New Britain poinformował o poważnym incydencie cyberbezpieczeństwa, który zakłócił działanie miejskich systemów IT i łączności. Z perspektywy bezpieczeństwa to klasyczny scenariusz „zakłócenia ciągłości działania” wywołanego ransomware: złośliwym oprogramowaniem, które szyfruje zasoby i wymusza okup, często łącząc to z groźbą publikacji danych (tzw. data extortion).

W tym przypadku władze podkreślają, że służby bezpieczeństwa publicznego funkcjonowały, ale część usług urzędu była ograniczona (m.in. telefonia i systemy komputerowe).

W skrócie

  • Atak ransomware uderzył w systemy miejskie od wczesnej środy (28 stycznia 2026), powodując przestoje w telefonii i systemach komputerowych wielu wydziałów.
  • Burmistrz Bobby Sanchez informował o pracach naprawczych prowadzonych także w weekend, przy wsparciu organów stanowych i federalnych oraz zewnętrznych specjalistów.
  • Władze zaznaczają, że zakres szkód i ewentualny wyciek danych wciąż jest ustalany (brak wiążących publicznych informacji o skali eksfiltracji).
  • W sprawę zaangażowano Federal Bureau of Investigation.

Kontekst / historia / powiązania

Incydenty ransomware w administracji publicznej są trudne z dwóch powodów:

  1. wysoka wrażliwość danych (mieszkańcy, podatki, świadczenia, sprawy urzędowe),
  2. zależność od usług cyfrowych (telefonia, obieg dokumentów, systemy zgłoszeń).

W New Britain komunikacja władz wskazuje na równoległe prowadzenie dwóch strumieni prac: przywracanie usług oraz dochodzenie (ustalenie wektora wejścia, zakresu kompromitacji, ewentualnej kradzieży danych). To standard w dojrzałym IR – odtworzenie „na siłę” bez zrozumienia źródła incydentu często kończy się reinfekcją.

Analiza techniczna / szczegóły luki

Na dziś publicznie dostępne informacje (z komunikacji miasta i relacji medialnych) potwierdzają ransomware oraz zakłócenia usług – bez ujawnienia nazwy grupy, wykorzystanej podatności czy poziomu dostępu napastników.

W takich zdarzeniach w samorządach najczęściej spotyka się kilka wzorców (poniższe punkty to typowe scenariusze, a nie potwierdzone dla New Britain):

  • Kradzież poświadczeń (phishing, password spraying, wycieki haseł) i wejście przez VPN/RDP lub usługi zdalne.
  • Eksploatacja podatnych urządzeń brzegowych (firewall/VPN, serwery dostępu, systemy pocztowe).
  • Ruch boczny i eskalacja uprawnień (np. przejęcie kontrolera domeny), a następnie masowe szyfrowanie.
  • Coraz częściej: podwójne wymuszenie – szyfrowanie + eksfiltracja, co podnosi presję negocjacyjną. (To powszechny trend opisywany w materiałach rządowych dot. ransomware).

W praktyce, dopóki nie ma publicznego raportu powłamaniowego (albo chociaż IoC/TTP), kluczowe jest podejście „assume breach” podczas przywracania środowiska: odtwarzać usługi warstwowo, z segmentacją i dodatkowymi kontrolami.

Praktyczne konsekwencje / ryzyko

Nawet jeśli „dla mieszkańców” zakłócenia są minimalne, ryzyko operacyjne może być istotne:

  • Przestoje usług: ograniczona łączność i systemy obsługi spraw wydłużają czas realizacji procesów.
  • Ryzyko wycieku danych: przy ransomware nie można zakładać, że skończyło się na szyfrowaniu – brak potwierdzenia eksfiltracji to nie to samo co jej brak.
  • Koszty odtworzeniowe: forensics, wymiana/rekonfiguracja infrastruktury, nadgodziny, komunikacja kryzysowa.
  • Ryzyko wtórne: oszustwa i phishing „na incydent” (podszywanie się pod urząd, zmianę numerów kont, dopłaty, itp.) – klasyczny efekt uboczny głośnych incydentów w sektorze publicznym.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które wprost wynikają z oficjalnych checklist i zaleceń rządowych dla ransomware – przydatne zarówno w trakcie incydentu, jak i po nim.

1) Natychmiastowe kroki IR (0–72h)

  • Izolacja zainfekowanych segmentów / hostów, wstrzymanie „niepewnych” kanałów zdalnych, kontrola kont uprzywilejowanych.
  • Zabezpieczenie dowodów (obrazy dysków, logi, EDR) zanim środowisko zostanie „wyczyszczone”.
  • Praca według checklisty reakcji na ransomware (#StopRansomware) – to pomaga nie pominąć krytycznych etapów (triage → containment → eradication → recovery → lessons learned).

2) Zgłoszenia i współpraca z organami

  • Zgłaszanie incydentów do organów właściwych: kontakt z lokalnym biurem FBI Internet Crime Complaint Center i egzekwowaniem prawa jest rekomendowany wprost przez FBI.
  • W modelu USA często dochodzi też współpraca z Cybersecurity and Infrastructure Security Agency oraz partnerami stanowymi; miasto wskazało wsparcie służb stanowych i federalnych.

3) Odtwarzanie usług „bezpiecznie, nie tylko szybko”

  • Odtwarzaj z kopii offline/immutable, uprzednio skanowanych pod kątem malware (żeby nie odtworzyć infekcji).
  • Wymuś reset poświadczeń (priorytet: konta uprzywilejowane), włącz MFA wszędzie, gdzie to możliwe.
  • Przywracaj krytyczne usługi w odseparowanych strefach (segmentacja), z tymczasowo zaostrzonym monitoringiem.

4) Utwardzenie po incydencie (2–8 tygodni)

  • Segmentacja sieci (oddzielenie stacji roboczych, serwerów, OT/SCADA, kopii zapasowych).
  • Minimalizacja uprawnień i twarde zasady dla adminów (PAW, oddzielne konta, JIT/JEA).
  • Zbieranie i korelacja logów (SIEM), telemetria EDR, retencja logów do celów forensics.
  • Ćwiczenia tabletop + testy odtwarzania (DR) – w samorządach to często najsłabsze ogniwo, a najszybszy „boost” odporności.

Ważne: FBI konsekwentnie podkreśla, że płacenie okupu nie daje gwarancji odzyskania danych i wzmacnia model przestępczy. W praktyce decyzje są złożone, ale warto opierać je o ryzyko, prawo, ubezpieczenie i twarde dane z forensics – nie o presję czasu.

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

W komunikacji New Britain widać element, który odróżnia część dojrzałych reakcji od „chaotycznego recovery”: nacisk na równoległe dochodzenie i ostrożność w formułowaniu wniosków co do zakresu incydentu.

Typowa różnica między incydentami o małej i dużej skali to:

  • czy doszło tylko do szyfrowania ograniczonego segmentu,
  • czy napastnicy osiągnęli domenę/backup i wykonali eksfiltrację,
  • jak szybko organizacja potrafi odtworzyć usługi z kopii odpornych na modyfikację.

Na dziś – bez publicznych IoC i bez informacji o grupie – nie da się wiarygodnie sklasyfikować zdarzenia w New Britain do konkretnego „klastra” kampanii.

Podsumowanie / kluczowe wnioski

  • Incydent w New Britain to potwierdzony przypadek ransomware z zauważalnym wpływem na systemy urzędu, przy deklarowanym utrzymaniu działania usług bezpieczeństwa publicznego.
  • Kluczowa niewiadoma to zakres kompromitacji i ewentualna kradzież danych – miasto sygnalizuje, że ustalenia trwają.
  • Dla samorządów najważniejsze „lekcje” są powtarzalne: odporne kopie (offline/immutable), segmentacja, MFA, monitoring oraz ćwiczenia IR/DR zgodnie z checklistami CISA/FBI.

Źródła / bibliografia

  1. CT Insider – informacje o incydencie i działaniach miasta. (CT Insider)
  2. WFSB – potwierdzenie charakteru ataku i kontekstu operacyjnego. (https://www.wfsb.com)
  3. Cybersecurity and Infrastructure Security Agency – #StopRansomware Guide / checklisty reakcji. (cisa.gov)
  4. Federal Bureau of Investigation – strona informacyjna o ransomware i raportowaniu. (Federal Bureau of Investigation)
  5. FBI Internet Crime Complaint Center – zalecenia dot. reakcji (w tym stanowisko ws. płacenia okupu). (Internet Crime Complaint Center)

Mandiant: ShinyHunters eskalują vishing i „kradzież MFA”, by przejmować SSO i okradać SaaS z danych

Wprowadzenie do problemu / definicja luki

Opisany przez Mandiant przypadek nie dotyczy „magicznej” podatności w chmurze ani błędu w samych platformach SaaS. To klasyczna, ale coraz lepiej „uzbrajana” socjotechnika: vishing (voice phishing) + strony podszywające się pod firmowe portale logowania, które wyciągają od ofiary jednocześnie hasło/SSO i kody MFA lub doprowadzają do zarejestrowania nowego urządzenia MFA kontrolowanego przez atakującego.

Atak działa, bo „człowiek w pętli” potrafi zatwierdzić wszystko, jeśli uwierzy, że rozmawia z IT/Helpdeskiem — a nowa generacja phishing kitów potrafi w czasie rzeczywistym dopasować to, co widzi ofiara w przeglądarce, do scenariusza rozmowy.

W skrócie

  • Google Threat Intelligence Group śledzi aktywność pod kilkoma klastrami: UNC6661, UNC6671 oraz UNC6240 (powiązywany z marką ShinyHunters).
  • Kampanie (wczesny–połowa stycznia 2026) polegają na podszywaniu się pod IT i kierowaniu pracowników na „victim-branded” strony kradnące SSO/MFA.
  • Po wejściu do środowiska atakujący „pivotują” do aplikacji SaaS i masowo wyciągają dane (m.in. dokumenty i komunikację), a następnie przechodzą do wymuszeń/ekstorsji.
  • Kluczowy wniosek obronny: MFA odporne na phishing (FIDO2/passkeys/FastPass) znacząco ogranicza skuteczność tego modelu ataku.

Kontekst / historia / powiązania

Wg Mandiant obserwujemy „rozszerzenie i eskalację” taktyk kojarzonych z wymuszeniami ShinyHunters: rośnie zakres atakowanych platform chmurowych, a presja na ofiarę obejmuje nie tylko e-maile z żądaniem okupu, ale też nękanie personelu i (w niektórych przypadkach) elementy presji operacyjnej.

Ważne jest też rozdzielenie „marki” od wykonawców: GTIG podkreśla, że śledzi aktywność jako kilka klastrów m.in. po to, by uwzględnić różne partnerstwa i możliwość podszywania się pod wcześniej znane TTP.

Równolegle Okta opisuje ewolucję phishing kitów „pod rozmowę telefoniczną” (vishing), które realnie zwiększają skalę tego typu ataków, bo pozwalają atakującemu sterować przebiegiem logowania ofiary niemal jak operatorem „z pulpitu”.

Analiza techniczna / szczegóły luki

1) Łańcuch ataku (high level)

  1. Recon + wybór celu (użytkownicy, aplikacje, numery infolinii/IT).
  2. Vishing: telefon „z IT” z pretekstem aktualizacji ustawień MFA / bezpieczeństwa.
  3. Victim-branded phishing: ofiara trafia na stronę przypominającą firmowy portal i wpisuje dane.
  4. Synchronizacja w czasie rzeczywistym: atakujący na bieżąco wprowadza przechwycone dane do prawdziwego loginu, wywołuje wyzwania MFA i instruuje ofiarę, co ma zatwierdzić/wpisać.
  5. Utrwalenie: rejestracja urządzenia MFA kontrolowanego przez atakującego lub przejęcie sesji/OAuth.
  6. Drenaż SaaS: dostęp do danych zależny od uprawnień skompromitowanej sesji SSO (często oportunistycznie).
  7. Ekstorsja: żądanie okupu, groźby publikacji, dowody kradzieży danych.

2) Klastry i różnice w TTP

  • UNC6661: wczesny–połowa stycznia 2026; domeny phishingowe często w formacie <companyname>sso.com / <companyname>internal.com; rejestracje często u NICENIC; widoczny „post-exploitation” w SaaS oraz przypadki wykorzystania przejętej poczty do dalszego phishingu (np. do podmiotów z branży kryptowalut).
  • UNC6671: podobny model vishing + „victim-branded” strony, ale domeny częściej rejestrowane przez Tucows; dodatkowo Mandiant widział użycie PowerShell do pobierania wrażliwych danych z SharePoint i OneDrive; ekstorsja bywała niebrandowana i z innym Tox ID, a nękanie personelu pojawiało się jako element presji.

3) Co konkretnie jest celem w SaaS?

Mandiant opisuje wykradanie danych i komunikacji z różnych usług SaaS (w przykładach i logach pojawiają się m.in. ekosystem Microsoft 365, Salesforce oraz DocuSign). W części przypadków atakujący wykonywali też wyszukiwania pod kątem „cennych słów kluczowych” (np. „confidential”, „proposal”, „vpn”), co sugeruje selekcję danych pod presję/ekstorsję.

4) Maskowanie śladów i „living off the land”

Ciekawy detal operacyjny: w co najmniej jednym incydencie, po przejęciu konta klienta Okta, atakujący autoryzował dodatek ToogleBox Recall w Google Workspace i usuwał wiadomości mogące ujawnić rejestrację nowego sposobu MFA („Security method enrolled”). To typowy przykład „ciszy po zalogowaniu” zamiast klasycznego malware.

Praktyczne konsekwencje / ryzyko

  • To nie jest „zwykły phishing”: prawdziwym przełomem jest sterowanie sesją ofiary w czasie rzeczywistym, co zwiększa skuteczność nawet przeciwko „lepszemu MFA”, jeśli nie jest ono phishing-resistant.
  • Ryzyko eskalacji przez SSO: pojedyncza udana rozmowa + SSO potrafią dać „szeroki wachlarz” aplikacji do przeszukania i eksportu danych.
  • Ekstorsja bez ransomware: model „data theft + szantaż” omija część klasycznych zabezpieczeń endpointowych, a presja czasu (np. ultimatum 72h w opisywanych przypadkach) wymusza szybkie decyzje kryzysowe.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” wprost pod ten typ kampanii (priorytetyzacja zgodna z rekomendacjami Mandiant + wnioskami Okta):

1) Natychmiastowe działania (containment)

  • Odwołaj aktywne sesje i tokeny: wymuś wylogowanie, unieważnij tokeny sesyjne i autoryzacje OAuth w IdP oraz kluczowych SaaS.
  • Zablokuj operacje wysokiego ryzyka: ogranicz (czasowo lub politykami) reset haseł, rejestrację nowych urządzeń MFA i zmiany metod MFA — to dokładnie te procesy, które vishing „podrabia”.
  • Przejrzyj rejestracje urządzeń/MFA i uprawnienia adminów w IdP (szczególnie niespodziewane przypisanie ról, anomalie geolokacji, logowania z sieci anonimizujących).

2) Utwardzenie (hardening) pod vishing

  • Wymuś phishing-resistant MFA: FIDO2/passkeys lub rozwiązania typu FastPass (tam, gdzie to ma sens). Push/SMS/OTP są podatne na „przegadanie” ofiary przez telefon.
  • Zasady sieciowe i strefy zaufania: tam gdzie możliwe, ogranicz logowania i akcje administracyjne do znanych lokalizacji/stref (allowlist), a ruch z usług anonimizujących traktuj jako sygnał do polowania (hunting), niekoniecznie automatycznego blokowania „w ciemno”.
  • Proces „call-back” dla IT: jeśli pracownik dostaje telefon „z IT”, powinien oddzwonić na numer z firmowej książki/portalu, nie na numer z wyświetlacza. To proste, ale nadal ekstremalnie skuteczne przeciw vishingowi (a często pomijane).

3) Detekcja i monitoring (SOC)

  • Poluj na wzorce: „MFA device enrolled”, nietypowe logowania do konsoli admina IdP, masowe pobrania z SharePoint / OneDrive, użycie PowerShell do pobierania plików, autoryzacje podejrzanych aplikacji OAuth (np. ToogleBox Recall).
  • Kontrola domen podobnych do marki: rejestracje w stylu my<company>sso[.]com, <company>support[.]com, <company>okta[.]com, literówki typu acess.
  • Zweryfikuj, czy Twoje alerty obejmują nietypowe wolumeny pobrań i wyszukiwania po „wrażliwych słowach” w SaaS.

Różnice / porównania z innymi przypadkami

  • „MFA fatigue” vs. „MFA steering”: tu nie chodzi o zalewanie pushami aż ofiara kliknie — chodzi o pełną reżyserię logowania, gdzie kit phishingowy zmienia ekrany w idealnym tempie pod rozmowę. To jakościowo inny poziom „wiarygodności” ataku.
  • Ransomware niepotrzebne: jeżeli organizacja ma dojrzałe backupy i EDR, atakujący nadal może wygrać, kradnąc dane z SaaS i stosując presję reputacyjną/prawną.
  • Brak CVE jako „punktu wejścia”: to kampania oparta o procesy (helpdesk, reset MFA) i zachowania ludzi, dlatego testy podatności aplikacji nie wystarczą — potrzebne są ćwiczenia i polityki IAM.

Podsumowanie / kluczowe wnioski

  1. Kampanie przypisywane klastrom powiązanym z marką ShinyHunters pokazują, że vishing stał się pełnoprawnym wektorem initial access do SSO i SaaS — często skuteczniejszym niż klasyczny e-mailowy phishing.
  2. „Zwykłe MFA” nie wystarcza, jeśli nie jest odporne na phishing: FIDO2/passkeys/FastPass realnie podnoszą poprzeczkę.
  3. Obrona musi koncentrować się na sesjach, tokenach, rejestracji urządzeń MFA, logowaniu i detekcji anomalii w SaaS — a nie na poszukiwaniu „jednej podatności”.

Źródła / bibliografia

  • Mandiant – „Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft” (30 stycznia 2026). (Google Cloud)
  • Mandiant – „Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS” (30 stycznia 2026). (Google Cloud)
  • Okta – „Phishing kits adapt to the script of callers” (22 stycznia 2026). (Okta)
  • BleepingComputer – omówienie kampanii i wątków dot. vishing + MFA/SSO (31 stycznia 2026). (BleepingComputer)
  • The Hacker News – streszczenie ustaleń Mandiant (31 stycznia 2026). (The Hacker News)

Coupang: policja przesłuchuje p.o. CEO w śledztwie po wycieku danych — w tle zarzuty utrudniania dochodzenia

Wprowadzenie do problemu / definicja luki

Sprawa wycieku danych w Coupang pokazuje dwa równoległe ryzyka, które coraz częściej splatają się w incydentach cyber: (1) sam incydent naruszenia poufności danych oraz (2) ryzyko „post-incident”, czyli błędy w obsłudze dowodów, logów i komunikacji z organami nadzoru/ścigania.

Według doniesień medialnych południowokoreańska policja przesłuchiwała p.o. CEO firmy, Harold Rogers, w ramach dochodzenia dotyczącego możliwego utrudniania państwowego śledztwa po masowym naruszeniu danych ujawnionym publicznie w listopadzie.

W skrócie

  • Skala incydentu jest raportowana na poziomie ok. 33,7 mln kont klientów; ujawnione dane miały obejmować m.in. identyfikatory i dane kontaktowe oraz wybrane informacje o zamówieniach (bez danych kart i bez haseł/logowania — wg komunikacji firmy przytaczanej przez media).
  • Policja bada podejrzenia manipulacji lub ukrywania dowodów w toku wewnętrznego dochodzenia i współpracy z organami.
  • Wątek dowodowy koncentruje się m.in. na laptopie powiązanym ze sprawą oraz na tym, czy i jak firma prowadziła własną analizę forensyczną przed/obok działań organów.
  • Media w South Korea informowały o wielogodzinnym przesłuchaniu oraz o rozbieżnościach między szacunkami władz a wynikami „samodzielnego” dochodzenia firmy (np. liczba 3 tys. vs dziesiątki milionów).

Kontekst / historia / powiązania

Kluczowa oś czasu (na podstawie relacji cytowanych przez media):

  • Czerwiec (rok poprzedzający ujawnienie): naruszenie miało rozpocząć się wcześniej niż moment jego wykrycia/ujawnienia (media wskazują na czerwiec jako potencjalny start).
  • Listopad: sprawa wycieku danych została upubliczniona; od tego czasu narasta presja regulacyjna i reputacyjna.
  • Grudzień: policja uruchamia dedykowane działania/TF; w tle pojawiają się doniesienia o pozyskiwaniu i zabezpieczaniu nośników (w tym laptopa).
  • Styczeń: przesłuchania kierownictwa i spór o rzetelność i wpływ wewnętrznego dochodzenia na śledztwo.

Dodatkowym, wrażliwym kontekstem jest komponent „governance”: czy organizacja podjęła działania, które mogły utrudniać postępowanie (np. brak pełnej transparentności co do tego, jakie analizy zostały wykonane na kluczowym nośniku i kiedy).

Analiza techniczna / szczegóły luki

Z publicznie dostępnych informacji (na dziś) wynika, że rdzeń incydentu dotyczył wycieku danych klientów na masową skalę. Media cytujące ustalenia/komunikaty wskazują, że miały wyciec m.in.:

  • imiona i nazwiska,
  • adresy e-mail,
  • numery telefonów,
  • adresy dostaw,
  • wybrane elementy historii zamówień.

Wątek, który czyni tę sprawę szczególnie istotną dla praktyków IR/DFIR, to kontrowersje wokół postępowania z dowodami:

  • Organy miały badać, czy firma kontaktowała się z podejrzewaną osobą i prowadziła własną analizę forensyczną nośnika bez konsultacji z prowadzącymi sprawę, a następnie przekazała sprzęt policji bez ujawnienia pełnego kontekstu działań.
  • W relacjach prasowych pojawia się również opis odzyskania uszkodzonego laptopa z rzeki, co sugeruje możliwą próbę fizycznego zniszczenia materiału dowodowego (to istotne, bo nawet „smashed” sprzęt bywa częściowo odzyskiwalny, ale łańcuch dowodowy staje się krytyczny).

Warto podkreślić: na tym etapie doniesienia koncentrują się bardziej na procesie obsługi incydentu i dowodów (obstruction/evidence handling) niż na pełnym, publicznym opisie wektora ataku (np. exploit, malware, błąd konfiguracyjny).

Praktyczne konsekwencje / ryzyko

Dla użytkowników i organizacji podobnych do Coupang realne skutki są wielowarstwowe:

  1. Ryzyko nadużyć tożsamości i phishingu
    Zestawy danych typu: imię/nazwisko + e-mail + telefon + adres + historia zamówień są paliwem dla ataków dopasowanych (spear phishing, smishing, vishing) i oszustw logistycznych („dopłata do przesyłki”, „weryfikacja adresu”).
  2. Ryzyko prawne i regulacyjne
    Nawet jeśli wrażliwe dane płatnicze nie wyciekły, skala naruszenia i sposób reakcji mogą prowadzić do dotkliwych konsekwencji finansowych i nadzorczych. Reuters wskazuje też na możliwość wysokich kar w reżimie lokalnym oraz presję polityczną na zaostrzenie podejścia do zaniedbań.
  3. Ryzyko „secondary incident” w organizacji
    Gdy pojawiają się zarzuty dot. niszczenia/ukrywania dowodów, organizacja wchodzi na pole wysokiego ryzyka: utrata wiarygodności, utrudnione negocjacje z regulatorami, większa skłonność organów do środków przymusu (przeszukania, zabezpieczenia), a także dług techniczny w obszarze logowania i retencji.

Rekomendacje operacyjne / co zrobić teraz

Jeśli prowadzisz SOC/CSIRT, bezpieczeństwo aplikacji albo compliance, ta sprawa jest dobrą checklistą „czego nie przegapić” po incydencie:

  1. Legal hold + twarda retencja logów od pierwszej minuty
    Natychmiastowe wstrzymanie rotacji/retencji dla logów krytycznych (IAM, API gateway, WAF, CDN, DB audit, systemy zamówień, narzędzia CI/CD, EDR). Zrób to formalnie (ticket + zatwierdzenie + ślad audytowy).
  2. Zarządzanie dowodami jak projektem forensycznym, nie jak „IT taskiem”
    • łańcuch dowodowy (chain of custody),
    • izolacja nośników i obrazowanie (bit-by-bit),
    • kontrola dostępu do artefaktów,
    • dziennik działań (kto/co/kiedy).
      Kontrowersje w tej sprawie pokazują, że „wewnętrzne śledztwo” bez rygoru DFIR może stać się problemem samym w sobie.
  3. Rozdziel role: komunikacja kryzysowa ≠ analiza techniczna ≠ relacje z organami
    W praktyce potrzebujesz „incident commander”, niezależnego DFIR lead oraz osoby odpowiedzialnej za interfejs prawny/regulacyjny.
  4. Transparentne, weryfikowalne szacunki skali
    Rozbieżności typu „3 tys. kont” vs „dziesiątki milionów” niszczą zaufanie i podbijają koszty (kary, pozwy, odpływ klientów). Jeśli nie wiesz — komunikuj przedziały i metodologię.
  5. Monitoring nadużyć po stronie klientów
    Wymuś/zalecaj MFA, wykrywanie logowań anomalii, alerty o zmianie adresu dostawy, mechanizmy anty-ATO (account takeover). Nawet bez wycieku haseł, dane kontaktowe + OSINT dają atakującym przewagę.

Różnice / porównania z innymi przypadkami

W wielu wyciekach największym problemem jest sam wektor ataku. Tu równie istotny jest „drugi akt”: obsługa incydentu i dowodów. To różnica, która często decyduje o:

  • skali kar i środków nadzorczych,
  • tempie zamknięcia sprawy,
  • możliwości przypisania winy,
  • wiarygodności organizacji wobec klientów i regulatora.

Podsumowanie / kluczowe wnioski

  • Sprawa Coupang jest przykładem incydentu, w którym ryzyko prawne i reputacyjne może zostać spotęgowane przez nieprawidłową obsługę dowodów.
  • Przy wyciekach na poziomie dziesiątek milionów rekordów sama kontrola szkód nie wystarczy — liczy się proces: retencja logów, łańcuch dowodowy, niezależna forensyka i spójna komunikacja.
  • Dla zespołów bezpieczeństwa to mocny argument, by mieć gotowe procedury DFIR „na papierze” (i przećwiczone), zanim wydarzy się incydent.

Źródła / bibliografia

  • The Record (Recorded Future News) — opis przesłuchania i wątku potencjalnego ukrywania/niszczenia dowodów. (The Record from Recorded Future)
  • Reuters — kontekst skali wycieku, zakres ujawnionych danych, tło regulacyjne. (Reuters)
  • KBS World — streszczenie zarzutów dot. utrudniania dochodzenia i wewnętrznego „self-probe”. (world.kbs.co.kr)
  • The Korea Times — szczegóły dot. przesłuchania (czas, wątki dowodowe, rozbieżności w liczbach). (The Korea Times)
  • Korea JoongAng Daily — potwierdzenie kluczowych elementów relacji (12 godzin, 2:22 a.m., wątki laptopa i wewnętrznej analizy). (Korea Joongang Daily)

Bumble i Match Group badają incydenty po deklaracjach ShinyHunters: co mogło wyciec i jakie są realne ryzyka

Wprowadzenie do problemu / definicja luki

Końcówka stycznia 2026 r. przyniosła doniesienia o incydentach bezpieczeństwa u operatorów aplikacji randkowych: Bumble i Match Group. Sprawa jest o tyle istotna, że usługi randkowe gromadzą dane szczególnie wrażliwe w ujęciu „kontekstowym”: preferencje, opisy profilu, historię dopasowań, komunikację oraz metadane aktywności – a to świetny materiał do szantażu, nękania, doxxingu i kampanii socjotechnicznych.

W tym przypadku nie mówimy o jednej „luce CVE” w aplikacji, tylko o klasycznym scenariuszu naruszenia dostępu (intrusion / unauthorized access) po stronie organizacji (lub jej dostawców), gdzie skutki zależą od tego, do jakich systemów i repozytoriów uzyskał dostęp napastnik oraz jakie dane zdążył wyeksportować.

W skrócie

  • ShinyHunters przypisała sobie ataki i zaczęła publikować/teasować próbki danych na swoim „leak site”.
  • Bumble wskazało na phishing konta kontraktora i „krótkotrwały” nieautoryzowany dostęp do fragmentu sieci; firma twierdzi, że baza członków, konta, aplikacja, wiadomości i profile nie zostały naruszone.
  • Match Group potwierdził incydent dotyczący ograniczonej ilości danych użytkowników i rozpoczął proces powiadomień; jednocześnie komunikował, że brak przesłanek o dostępie do loginów, finansów i prywatnej komunikacji.
  • Niezależni badacze (m.in. Cybernews) deklarują, że widzieli próbki zawierające m.in. dane klientów i artefakty wewnętrzne; w jednej z próbek dla Hinge miały się pojawić wpisy dot. dopasowań i elementy profili.
  • The Register opisał, że wątek „10 milionów linii” danych Match miał wskazywać na możliwe powiązanie z AppsFlyer jako potencjalnym źródłem ekspozycji (na poziomie ekosystemu marketing/analityka, niekoniecznie core aplikacji).

Kontekst / historia / powiązania

Wg The Record from Recorded Future News incydenty u Bumble i Match zostały „podpięte” pod narrację ShinyHunters – grupy znanej z kampanii o wysokim zasięgu i presji na ofiary po kradzieży danych.

W tle przewija się też wątek przejścia części ekosystemu cyberprzestępczego w model „pure data theft” (kradzież danych bez szyfrowania) oraz nasilone nadużycia phishing/vishing w środowiskach korzystających z SSO.

Analiza techniczna / szczegóły incydentu

Bumble: kompromitacja konta kontraktora (wejście przez tożsamość)

Z przekazów wynika, że punkt wejścia to konto kontraktora przejęte phishingiem, które zapewniło napastnikowi „brief unauthorized access” do fragmentu sieci. Bumble twierdzi, że dostęp został szybko wykryty i odcięty, a newralgiczne obszary (member DB, konta, wiadomości, profile) nie zostały dotknięte.

Jednocześnie ShinyHunters przypisał sobie wykradzenie „tysięcy dokumentów”, w tym oznaczonych jako restricted/confidential, rzekomo głównie z zasobów chmurowych i narzędzi współpracy (np. dyski i komunikatory firmowe). Cybernews opisuje nawet rozmiar paczki jako „30GB danych”.

Technicznie to spójny wzorzec: gdy przejęte konto ma dostęp do zasobów współdzielonych (pliki, wiki, zgłoszenia, kanały), napastnik może wynieść dokumenty wewnętrzne bez wchodzenia do systemów produkcyjnych przechowujących dane użytkowników.

Match Group: „limited user data” i spór o skalę

Match potwierdził incydent i powiadamianie użytkowników, podkreślając brak oznak dostępu do loginów, finansów i prywatnych wiadomości.

Równolegle ShinyHunters twierdził, że uzyskał dostęp do „10 milionów rekordów/wierszy”, a Tinder, Hinge i OkCupid pojawiają się w kontekście usług Match Group.
Ważny detal z opisu The Register: wskazanie na AppsFlyer jako „apparent source” sugeruje scenariusz, w którym wyciek może dotyczyć danych telemetryczno-marketingowych / atrybucyjnych (np. identyfikatory kampanii, zdarzenia, parametry profilu w zakresie potrzebnym do analityki), a nie bezpośrednio pełnych baz aplikacji. To nadal może być bolesne, ale innego typu niż np. dump wiadomości prywatnych.

Praktyczne konsekwencje / ryzyko

Nawet jeśli core bazy użytkowników nie została ruszona (wersja Bumble), a „private communications” nie wyciekły (deklaracje Match), w praktyce ryzyka pozostają wysokie, bo dokumenty i próbki danych mogą umożliwić:

  1. Spear-phishing i przejęcia kont – dokumenty wewnętrzne (procedury, wzory maili, nazwy systemów, schematy SSO) podnoszą skuteczność ataków na pracowników, partnerów i dostawców.
  2. Doxxing / nękanie / szantaż kontekstowy – już fragmenty profili + fakt dopasowania (match) + opis bio mogą wystarczyć do identyfikacji osoby w realu, szczególnie w mniejszych społecznościach. (To wynika z natury danych, a nie z deklarowanej skali wycieku).
  3. Ryzyko „wtórnych wycieków” – jeśli wektor obejmował narzędzia współpracy lub repozytoria plików, często pojawiają się tam: klucze API, tokeny, eksporty danych testowych, logi, zrzuty ekranów, konfiguracje. Jeden „niegroźny” dokument potrafi stać się pivotem do kolejnych systemów.
  4. Oszustwa romantyczne i podszycia – incydenty dotyczące branży randkowej często zwiększają falę scamów „na gorąco”, bo przestępcy wykorzystują nagłówki („Twoje konto wyciekło, kliknij aby odzyskać”).

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji (operatorów aplikacji i ich dostawców)

  • Phishing-resistant MFA (FIDO2/WebAuthn) dla kont uprzywilejowanych i wszystkich integracji SSO; ograniczyć SMS/OTP jako „fallback”. (W opisach pojawia się phishing/vishing i SSO jako motyw przewodni).
  • Twarda segmentacja i zasada najmniejszych uprawnień dla kontraktorów: osobne tenanty/role, time-bound access, JIT/JEA, restrykcje geolokalizacji, device posture. (Tu wejście było przez kontraktora).
  • Ochrona narzędzi współpracy i repozytoriów dokumentów: DLP dla plików, watermarking, alerty na masowy eksport, kontrola udostępnień, regularne audyty linków publicznych, CASB.
  • Detekcja eksfiltracji: korelacja logów (IdP + narzędzia plikowe + komunikatory + EDR) i reguły na nienaturalne wzorce pobrań.
  • Urealnione środowiska testowe: eliminacja danych produkcyjnych z datasetów testowych i ograniczanie „debug logs” zawierających PII. (The Record wspomina o danych zduplikowanych/testowych w próbkach).

Dla użytkowników aplikacji randkowych

  • Zmień hasło, jeśli było współdzielone z innymi serwisami; włącz MFA, jeśli aplikacja oferuje.
  • Uważaj na „pilne” wiadomości o wycieku (SMS/mail/DM) – wchodź do aplikacji tylko przez oficjalny kanał, nie przez link z komunikatu.
  • Zminimalizuj dane w profilu (np. unikalne detale identyfikujące miejsce pracy, uczelnię, niszowe hobby), bo przy częściowym wycieku ułatwiają identyfikację.

Różnice / porównania z innymi przypadkami

  • Bumble komunikuje scenariusz „dostęp ograniczony, brak naruszenia danych członków”, ale wciąż realny jest wyciek dokumentów wewnętrznych, jeśli kompromitacja dotknęła narzędzi współpracy.
  • Match Group potwierdza dotknięcie „limited user data” i powiadomienia – czyli konsekwencje potencjalnie bliższe klasycznemu naruszeniu danych użytkowników, choć bez przesłanek o kompromitacji komunikacji prywatnej czy finansów.
  • Wątek AppsFlyer (jeśli trafny) pokazywałby typowy problem łańcucha dostaw danych: aplikacje → SDK / analityka → partnerzy → ryzyko ekspozycji danych na styku integracji.

Podsumowanie / kluczowe wnioski

  • Incydenty z końca stycznia 2026 r. mają wspólny mianownik: tożsamość i dostęp (phishing, SSO, uprawnienia kontraktorów) oraz ryzyko wyniesienia danych z narzędzi współpracy, nawet bez „włamania do bazy użytkowników”.
  • Deklaracje firm ograniczają zakres najgorszego scenariusza (brak oznak dostępu do wiadomości prywatnych/loginów/finansów), ale próbki opisywane przez badaczy sugerują, że przynajmniej część danych (użytkownicy/pracownicy/dokumenty) mogła zostać skopiowana.
  • Operacyjnie kluczowe są: phishing-resistant MFA, restrykcyjna kontrola dostępu kontraktorów, monitoring masowego eksportu z narzędzi chmurowych oraz ograniczenie „toksycznych” danych w plikach i logach.

Źródła / bibliografia

  1. The Record (Recorded Future News) – „Dating-app giants investigate incidents after cybercriminals claim to steal data” (30 stycznia 2026). (The Record from Recorded Future)
  2. Reuters – „Bumble, Match, Panera Bread and CrunchBase hit by cyberattacks…” (29 stycznia 2026). (Reuters)
  3. TechRadar – „Dating apps Bumble and Match reportedly hit in cyberattack…” (29 stycznia 2026). (TechRadar)
  4. The Register – „ShinyHunters claims it stole 10M records from dating apps” (29 stycznia 2026). (The Register)
  5. Cybernews – „ShinyHunters claim 30GB of Bumble data stolen…” (29 stycznia 2026). (Cybernews)

Microsoft naprawia błąd w klasycznym Outlooku blokujący dostęp do szyfrowanych e-maili („Encrypt Only”)

Wprowadzenie do problemu / definicja luki

Na przełomie grudnia 2025 i stycznia 2026 część organizacji korzystających z klasycznego Outlooka dla Microsoft 365 natrafiła na uciążliwy błąd: odbiorcy nie mogli otwierać wiadomości zaszyfrowanych polityką „Encrypt Only”. Zamiast treści e-maila pojawiał się załącznik message_v2.rpmsg, a w okienku podglądu komunikat sugerujący konieczność weryfikacji poświadczeń.

To nie była „luka” w sensie wycieku danych, ale błąd funkcjonalny dotykający krytycznego procesu bezpieczeństwa: poufnej komunikacji e-mail (szyfrowanie wiadomości w ramach Microsoft 365).

W skrócie

  • Problem pojawiał się po aktualizacji do Current Channel Version 2511 (Build 19426.20218).
  • Dotyczył wiadomości szyfrowanych jako „Encrypt Only”; odbiorca widział message_v2.rpmsg zamiast treści.
  • Status w oficjalnym komunikacie: FIXED – poprawka jest już dostępna w kanałach testowych i ma trafić szerzej zgodnie z harmonogramem aktualizacji.
  • Workaroundy: zmiana sposobu szyfrowania po stronie nadawcy (użycie szyfrowania z poziomu wstążki Options) albo cofnięcie pakietu Office do wcześniejszego builda.

Kontekst / historia / powiązania

W tle mamy dwa równoległe zjawiska:

  1. Migrację użytkowników do „nowego Outlooka” (który ma inną architekturę i inne zachowanie niż klasyczny klient Win32).
  2. Coraz większą zależność organizacji od mechanizmów typu Microsoft Purview Message Encryption / IRM (szyfrowanie i ograniczenia uprawnień), szczególnie w workflowach compliance.

Błąd opisywany przez media branżowe pojawił się po aktualizacji i został oficjalnie opisany przez producenta, a następnie oznaczony jako naprawiony.
Relację z wdrożeniem fixu opublikował m.in. BleepingComputer.

Analiza techniczna / szczegóły luki

Co oznacza „Encrypt Only” i skąd message_v2.rpmsg?

  • „Encrypt Only” to tryb, który szyfruje wiadomość, ale (w założeniu) nie narzuca restrykcji typu „Do Not Forward” – czyli nie blokuje automatycznie drukowania/kopiowania/przekazywania (w zależności od konfiguracji polityk).
  • Plik *.rpmsg (Rights Protected Message) jest „opakowaniem” treści chronionej mechanizmami IRM/OME. W normalnych warunkach Outlook powinien ten kontener zrenderować i pokazać treść użytkownikowi. W scenariuszu błędu użytkownik widział jedynie załącznik, czyli aplikacja „nie przeszła” poprawnie ścieżki odszyfrowania/renderowania.

Kiedy problem występował?

Producent wskazał konkretnie, że problem pojawia się po aktualizacji do Current Channel Version 2511 (Build 19426.20218).

Jak wygląda naprawa (wersje/kanały)?

Według komunikatu wsparcia, fix jest dostępny / zaplanowany w następujących buildach:

  • Beta Channel Version 2602 (Build 19720.15160) – dostępny w kanale Beta,
  • Current Channel Preview Version 2602 (Build 19725.20000) – początek lutego 2026,
  • Current Channel Version 2602 (Build 19725.20000) – 24 lutego 2026.

To ważne: jeśli organizacja jest na Monthly Enterprise / Semi-Annual, to termin dostępności może się różnić od Current Channel – dlatego w praktyce trzeba sprawdzić przypisany kanał aktualizacji M365 Apps. (Lista buildów i ich dat występuje w tabelach historii aktualizacji).

Praktyczne konsekwencje / ryzyko

Największe ryzyko to utrata dostępności informacji (availability), nie poufności:

  • użytkownicy nie są w stanie odczytać zaszyfrowanej korespondencji (np. dane osobowe, dokumenty prawne, incydenty, informacje handlowe),
  • potencjalne opóźnienia w procesach: HR, prawny, SOC/CSIRT, zakupy, obsługa klienta,
  • rośnie presja na „obejścia”, które mogą obniżać bezpieczeństwo (np. rezygnacja z szyfrowania lub przerzucenie danych do mniej kontrolowanych kanałów).

Jednocześnie sam fakt, że wiadomość „nie daje się otworzyć”, nie oznacza kompromitacji szyfrowania – to problem kompatybilności/obsługi w kliencie po aktualizacji.

Rekomendacje operacyjne / co zrobić teraz

1) Zweryfikuj, czy jesteś w grupie ryzyka

  • Sprawdź wersję Outlooka / Microsoft 365 Apps (np. w Outlook: File → Office Account → About Outlook).
  • Jeśli widzisz Version 2511 (Build 19426.20218) i symptomy pasują (komunikat w Reading Pane + message_v2.rpmsg) – problem jest bardzo prawdopodobny.

2) Najlepsza ścieżka: aktualizacja do builda z poprawką

  • Jeżeli możesz, zaplanuj aktualizację do wersji wskazanej jako naprawiająca problem (docelowo Current Channel 2602 / Build 19725.20000 – 24 lutego 2026).
  • Dla środowisk zarządzanych: wypchnij update najpierw na pilot, potem szerzej.

3) Gdy nie możesz od razu aktualizować: workarounds (krótkoterminowo)

Producent wskazał dwie praktyczne opcje:

  • Zmiana sposobu szyfrowania po stronie nadawcy: zamiast używać File → Encrypt, użyj szyfrowania z poziomu wstążki Options → Encrypt (wprost wskazane jako obejście).
  • Cofnięcie Office do wcześniejszego builda (gdy to dopuszczalne polityką IT): Microsoft podaje przykład cofnięcia do 16.0.19426.20186 poleceniem officec2rclient.exe /update user updatetoversion=... (wymaga uprawnień i kontroli zmian).

Uwaga operacyjna: rollbacki wersji Office potrafią mieć skutki uboczne (zgodność dodatków, zmiany bezpieczeństwa, rozjazd z polityką patch management). Jeśli już – to najlepiej jako kontrolowana akcja tymczasowa, z jasną datą powrotu na wspierany build.

4) Komunikacja do użytkowników (prosty komunikat IT)

  • Nie „naprawiajcie” problemu przez wyłączanie szyfrowania dla poufnych danych.
  • Jeśli musicie wysłać szyfrowaną wiadomość „tu i teraz” – użyjcie Options → Encrypt, a nie File → Encrypt (do czasu aktualizacji).

Różnice / porównania z innymi przypadkami

  • Ten incydent przypomina klasę problemów, w których zmiana w kliencie (Outlook) psuje obsługę mechanizmów ochrony informacji (IRM/OME) – często objawia się to kontenerem rpmsg zamiast treści.
  • W odróżnieniu od podatności bezpieczeństwa (CVE), tutaj mówimy o regresji funkcji bezpieczeństwa: szyfrowanie działa „w teorii”, ale klient nie potrafi poprawnie wyświetlić treści.

Podsumowanie / kluczowe wnioski

  • Jeśli Twoja organizacja korzysta z klasycznego Outlooka i szyfrowania „Encrypt Only”, upewnij się, że nie utknęłaś na Version 2511 (Build 19426.20218).
  • Microsoft oznaczył problem jako naprawiony, z jasnym wskazaniem buildów i dat rollout’u (w Current Channel: 24 lutego 2026).
  • Do czasu aktualizacji: zmień UX szyfrowania po stronie nadawcy (Options → Encrypt) albo rozważ kontrolowany rollback – ale tylko jako tymczasowe obejście.

Źródła / bibliografia

  1. Microsoft Support – „Classic Outlook recipients are unable to open ‘Encrypt Only’ emails” (status, objawy, wersje z fixem, workarounds). (Microsoft Support)
  2. BleepingComputer – opis wdrożenia poprawki i kontekst incydentu. (BleepingComputer)
  3. Microsoft Learn – „Update history for Microsoft 365 Apps (listed by date)” (historia wersji/buildów i dat). (Microsoft Learn)
  4. TechRadar – omówienie problemu i obejść (kontekst użytkowy). (TechRadar)

Microsoft wyłączy NTLM domyślnie w przyszłych wydaniach Windows – co to oznacza i jak się przygotować

Wprowadzenie do problemu / definicja luki

NTLM (New Technology LAN Manager) to stary mechanizm uwierzytelniania w ekosystemie Windows, który przez lata był „kołem ratunkowym” tam, gdzie Kerberos nie działał (legacy aplikacje, brak łączności z kontrolerem domeny, użycie adresów IP zamiast nazw/SPN, lokalne konta na maszynach w domenie). Problem w tym, że NTLM ma wbudowane ograniczenia bezpieczeństwa: nie zapewnia pełnej walidacji serwera i sprzyja klasom ataków typu relay oraz pass-the-hash, co w praktyce często przekłada się na realne przejęcia tożsamości i ruch lateralny w domenie.

W styczniu 2026 Microsoft oficjalnie ogłosił przejście „od deprecjacji do wyłączania NTLM domyślnie” w nadchodzących wydaniach Windows. Klucz: „wyłączone domyślnie” nie oznacza natychmiastowego usunięcia NTLM z systemu – chodzi o zablokowanie sieciowego NTLM jako domyślnej ścieżki uwierzytelniania i wymuszenie świadomego „opt-in”, jeśli organizacja nadal go potrzebuje.

W skrócie

  • Microsoft realizuje 3-fazową ścieżkę dochodzenia do stanu, w którym network NTLM będzie wyłączony domyślnie w kolejnym dużym wydaniu Windows Server i skorelowanych wydaniach klienckich.
  • Faza 1: rozszerzony auditing NTLM jest już dostępny (Windows 11 24H2, Windows Server 2025) i ma pomóc wykryć zależności.
  • Faza 2 (2. połowa 2026): nowe mechanizmy ograniczające „wymuszone fallbacki” do NTLM, m.in. IAKerb i Local KDC (pre-release) oraz przebudowy komponentów, które dziś potrafią używać NTLM „na sztywno”.
  • Faza 3: blokada sieciowego NTLM domyślnie, możliwość ponownego włączenia przez polityki oraz dodatkowe mechanizmy ograniczające „twarde” przypadki (np. nieznane SPN, logowanie po IP, lokalne konta na maszynach domenowych).

Kontekst / historia / powiązania

Microsoft od dłuższego czasu komunikuje, że NTLM jest „na wygaszaniu”:

  • W dokumentacji Microsoft Learn wskazano, że wszystkie wersje NTLM (włącznie z LANMAN, NTLMv1 i NTLMv2) są zdeprecjonowane i nie są już rozwijane funkcjonalnie; rekomendacja dla programistów to przejście na Negotiate (Kerberos jako preferencja, NTLM tylko jako fallback).
  • W Windows 11 24H2 i Windows Server 2025 NTLMv1 został usunięty, a Microsoft prowadzi rollout dodatkowych kontroli/audytu oraz docelowo zaostrzenia domyślnego zachowania dla scenariuszy „NTLMv1-derived”.

To ważne rozróżnienie: wyłączenie NTLM domyślnie (network NTLM) to szersza zmiana strategiczna (roadmapa), a równolegle idą bardziej szczegółowe kroki „po kawałku” (np. eliminacja NTLMv1 i twarde blokady określonych pochodnych mechanizmów).

Analiza techniczna / szczegóły luki

Dlaczego NTLM jest ryzykowny (z perspektywy 2026)

Microsoft wprost wskazuje zestaw problemów, które w praktyce tworzą „powtarzalny wzorzec incydentów” w środowiskach AD: brak silnego uwierzytelnienia serwera, podatność na replay/relay, podatność na pass-the-hash, słabsza kryptografia i historycznie słaba widoczność diagnostyczna (auditing).

Co zmienia „NTLM disabled by default”

W komunikacji Microsoft: „disabled by default” oznacza, że Windows będzie dostarczany w stanie „secure-by-default”, w którym sieciowe NTLM jest blokowane i nie jest używane automatycznie, a system preferuje nowocześniejsze alternatywy oparte o Kerberos. NTLM nadal ma pozostać w systemie w okresie przejściowym i da się go ponownie włączyć polityką, jeśli organizacja ma uzasadnione zależności.

Dlaczego w ogóle dochodzi do fallbacku na NTLM

W praktyce NTLM „wraca” gdy:

  • klient/serwer nie potrafi poprawnie dogadać Kerberosa (np. brak łączności z DC),
  • aplikacja używa adresu IP zamiast nazwy (problemy z SPN),
  • są lokalne konta w scenariuszach domenowych,
  • komponent/aplikacja ma „hardcoded NTLM”. Microsoft zapowiada modernizacje właśnie pod te punkty (IAKerb, Local KDC, zmiany w komponentach Windows).

Praktyczne konsekwencje / ryzyko

Co może się „zepsuć”

Gdy zacznie obowiązywać faza 3 (network NTLM off by default), najszybciej zaboli tam, gdzie:

  • macie legacy usługi autoryzujące po NTLM,
  • istnieją zależności od logowania do zasobów po IP,
  • funkcjonują urządzenia/usługi nieobsługujące Kerberosa (często stare NAS/printery/appliance),
  • część środowiska jest poza domeną albo ma nietypowe topologie sieci (DC „niewidoczny” z segmentów).

Microsoft deklaruje, że w fazie 3 mają dojść mechanizmy ograniczające breakage w typowych „NTLM-only cases”, ale to nadal nie zastępuje testów w realnym środowisku.

Co zyskujecie bezpieczeństwowo

Eliminacja NTLM znacząco ogranicza klasy ataków bazujące na przechwytywaniu i przekazywaniu uwierzytelnień (relay) oraz na wykorzystaniu hashy (pass-the-hash). Microsoft Learn podkreśla, że redukcja/wyłączenie NTLM wymusza użycie bezpieczniejszych protokołów (Kerberos v5) i usuwa wektor ataku tam, gdzie serwery/DC nie przyjmują już żądań NTLM.

Rekomendacje operacyjne / co zrobić teraz

Poniżej plan, który da się wdrożyć „bez heroizmu”, ale konsekwentnie.

1) Zbuduj widoczność: audytuj NTLM zanim zaczniesz blokować

  • Włącz i zbierz dane z enhanced NTLM auditing (Windows 11 24H2, Windows Server 2025).
  • Zrób mapę: kto (konto/usługa), skąd (host), do czego (serwer/usługa), dlaczego (brak SPN? po IP? brak DC? hardcoded?).

2) W domenie: zacznij od trybu audit i list wyjątków, dopiero potem deny

W AD masz do dyspozycji polityki „Restrict NTLM”. Dobre praktyki Microsoft są proste: najpierw audit, potem analiza logów i wyjątki, dopiero potem deny.
W skrócie:

  • ustaw politykę audytu NTLM w domenie,
  • przejrzyj logi operacyjne NTLM,
  • dodaj niezbędne wyjątki (serwery, których nie da się jeszcze zmigrować),
  • eskaluj restrykcje (deny) stopniowo.

3) Usuń typowe przyczyny fallbacku do NTLM

  • Napraw SPN i nazewnictwo (unikaj IP w konfiguracjach usług/monitoringu).
  • Wymuś użycie Negotiate/Kerberos w aplikacjach (tam, gdzie masz wpływ na konfigurację lub kod).
  • Zaplanuj wykorzystanie nadchodzących mechanizmów (2H 2026): IAKerb i Local KDC w scenariuszach, gdzie dziś „brak linii wzroku” do DC wymusza NTLM.

4) Uporządkuj NTLMv1 i „pochodne” scenariusze legacy

Jeśli gdzieś jeszcze występują mechanizmy ocierające się o NTLMv1:

  • Microsoft już uruchomił audyt użycia NTLMv1-derived (Event ID 4024 w trybie Audit), a w październiku 2026 planuje domyślne przejście w tryb Enforce dla wskazanego klucza (jeśli organizacja go sama nie ustawi).
    To dobra „datownikowa” kotwica do planowania: nawet jeśli macie większy projekt „NTLM-off”, warto równolegle dopiąć wątki NTLMv1.

5) Testy „NTLM-off” w kontrolowanym środowisku

Microsoft wprost zachęca do testowania konfiguracji bez NTLM w non-prod oraz do przygotowania zespołów identity/security/app owners.
Minimum praktyczne:

  • pilotaż na wybranym OU / segmencie,
  • lista usług krytycznych + testy regresji,
  • scenariusze awaryjne (jak szybko przywrócić wyjątek/politykę).

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

NTLM „disabled by default” vs „NTLMv1 removed”

  • Usunięcie NTLMv1 (Windows 11 24H2 / Windows Server 2025) to konkretna eliminacja starej wersji protokołu.
  • Wyłączenie network NTLM domyślnie to szersza zmiana platformowa, która dotyka również NTLMv2 jako mechanizmu sieciowego fallbacku i ma wprowadzić stan „bezpieczny domyślnie” w przyszłych wydaniach.

Restrict NTLM w AD vs globalna zmiana domyślna w Windows

  • Restrict NTLM to narzędzia domenowe, które możesz wdrażać już teraz (audit/deny + wyjątki).
  • Zmiana domyślna Microsoft (faza 3) oznacza, że nawet bez twoich GPO nowe systemy będą „skręcać” w stronę Kerberosa i blokady NTLM, a NTLM stanie się świadomym wyjątkiem.

Podsumowanie / kluczowe wnioski

  • Microsoft przyspiesza wygaszanie NTLM: faza 2 w 2H 2026 ma ograniczyć najczęstsze powody fallbacku do NTLM, a faza 3 wyłączy network NTLM domyślnie w kolejnym dużym wydaniu Windows Server i powiązanych wydaniach klienckich.
  • Największe ryzyko dla organizacji to ukryte zależności (legacy, logowanie po IP, błędne SPN, lokalne konta, hardcoded NTLM).
  • Najlepsza strategia na 2026: audyt → mapa zależności → naprawa Kerberosa/Negotiate → stopniowe deny z wyjątkami → testy NTLM-off.

Źródła / bibliografia

  1. (TECHCOMMUNITY.MICROSOFT.COM) – Microsoft TechCommunity: Advancing Windows security: Disabling NTLM by default (Jan 29, 2026)
  2. (BleepingComputer) – BleepingComputer: Microsoft to disable NTLM by default in future Windows releases (Jan 2026)
  3. (Microsoft Learn) – Microsoft Learn: Deprecated features in the Windows client (sekcja NTLM)
  4. (Microsoft Support) – Microsoft Support: Upcoming changes to NTLMv1 in Windows 11 24H2 and Windows Server 2025
  5. (Microsoft Learn) – Microsoft Learn: Network security: Restrict NTLM… (best practices, audit/deny, ryzyka)