Archiwa: Security News - Strona 433 z 445 - Security Bez Tabu

Kategoria: Security News

Rosja „zarządza” cyberprzestępcami? Nowe ustalenia: od tolerancji do aktywnego sterowania ekosystemem

Wprowadzenie do problemu / definicja zjawiska

Najnowsza analiza Recorded Future (Insikt Group) opisuje jakościową zmianę w relacjach państwo–podziemie w Rosji: od biernej tolerancji cyberprzestępców do aktywnego zarządzania nimi przez służby — z selektywnymi aresztami „użytecznych” ogniw łańcucha i ochroną graczy mających wartość wywiadowczą. Publiczne doniesienia i wycieki czatów mają wskazywać nawet na koordynację zadań między liderami grup a pośrednikami powiązanymi ze służbami.

W skrócie

  • Po 2023 r. Rosja miała przejść od parasola ochronnego do sterowania rynkiem: pokazowe zatrzymania dotykają głównie „enablerów” (np. usługi cash-out), podczas gdy trzon gangów ransomware pozostaje nietknięty.
  • Operacja Endgame (2024–2025) mocno uderzyła w łańcuch dostaw ransomware (dropp ery/loadery, botnety, infrastrukturę finansową), co wywołało reakcję i repozycjonowanie rosyjskich służb.
  • Rosyjskie śledztwa i masowe zatrzymania po sankcjach wobec Cryptex/UAPS (ok. 100 osób, konfiskata ~16 mln USD) zbiegły się w czasie z działaniami Zachodu.
  • Podziemie się fragmentuje: mniej otwartych rekrutacji RaaS, większa paranoja OPSEC, przejście na zamknięte kanały.

Kontekst / historia / powiązania

Operacja Endgame to skoordynowana akcja (UE/USA i partnerzy) rozbijająca infrastrukturę „dropperów” i botnetów (m.in. IcedID, SystemBC, Pikabot, SmokeLoader, Bumblebee), z setkami serwerów przejętych/wyłączonych i tysiącami domen pod kontrolą organów ścigania. Kontynuacja w 2025 r. uderzała w następców i nowe warianty, łącząc techniczne przejęcia z presją informacyjną (ujawnienia nazwisk, materiały wideo).

Równolegle, po sankcjach USA i komunikatach Endgame, Komitet Śledczy FR ogłosił śledztwa i zatrzymania powiązane z UAPS/Cryptex, prezentując spektakularne liczby zatrzymanych i zajętych aktywów — co analitycy interpretują jako zarządzanie reputacją i „regulację rynku”, nie jego likwidację.

Analiza techniczna / szczegóły zjawiska

Mechanizmy „zarządzania” wg Recorded Future:

  • Selektywne egzekwowanie prawa: nacisk na infrastrukturę finansową (exchangi, usługi prania), mniejsza presja na rdzeń operatorów RaaS powiązanych z aparatem państwa.
  • Kanonizacja „bezpiecznej przystani warunkowej”: ochronę zyskują podmioty mające użyteczność wywiadowczą/geopolityczną, podczas gdy „spieniężacze” stają się jednorazowi pod ostrzałem zewnętrznym.
  • OPSEC i rekrutacja: spadek otwartych naborów RaaS, przejście w pół-zamknięte programy, twardsze KYC w podziemiu, decentralizacja komunikacji.
  • Wyciek czatów Black Basta (kontynuacja linii Conti/TrickBot) dostarczył wglądu w strukturę, konflikty i relacje z dostawcami usług — a także wzmianki o rzekomych kontaktach niektórych liderów z rosyjskimi służbami.

W tle toczy się identyfikacja i „naming & shaming” figur kluczowych (np. przywództwa TrickBot/Conti w ramach Endgame), ale bez proporcjonalnych działań po stronie Rosji wobec najwyższych szczebli.

Praktyczne konsekwencje / ryzyko

  • Trwalsze ekosystemy RaaS: mniejsza widoczność naborów ≠ mniejsza aktywność; rośnie bariera zaufania i jakość OPSEC operatorów.
  • Pivot taktyczny: większa rotacja marek/aliasów, modularne „łańcuchy kill chain”, lepsze maskowanie TTPs, krótszy czas życia infrastruktur.
  • Ryzyko geopolityczne: dobór ofiar może bardziej odzwierciedlać interesy państwowe (np. przemysł krytyczny, sektor publiczny, łańcuch dostaw), co utrudnia czystą kwalifikację „crime-only”.
  • Compliance & ubezpieczenia: rośnie presja regulacyjna (raportowanie incydentów, ograniczenia płatności okupu), a decyzje o płatnościach niosą ryzyko sankcyjne.

Rekomendacje operacyjne / co zrobić teraz

  1. Zerwać łańcuch dostaw RaaS:
    • Blokady loaderów/droppers (IcedID, SystemBC, Pikabot, SmokeLoader, Bumblebee) w EDR/NDR; kontinuum Threat Hunting pod IOC z biuletynów Endgame.
  2. Hardening płatności i kryptoprzepływów:
    • Ekranizacja kanałów płatności (AML/KYC), weryfikacja pośredników, scenariusze OFAC/EU przy decyzjach okupu.
  3. Segmentacja i kopie zapasowe klasy „restore-first”:
    • Testy odtwarzania, odseparowane kopie, kontrola uprawnień (PAW/JIT/JEA), honeytokens i DRaaS.
  4. Minimalizacja blast radius:
    • U2F/FIDO2, phishing-resistant MFA, PAM, EDR z izolacją, canary accounts, blokady makr i włączona kontrola aplikacji.
  5. Telemetry for intel:
    • Systematyczny log enrichment (DNS, DHCP, proxy, EDR, SaaS), mapowanie do MITRE ATT&CK, playbooki na TTP powiązane z TrickBot/Conti/Black Basta.
  6. Ćwiczenia decyzyjne (war-gaming):
    • Scenariusze ataku sterowanego politycznie; ścieżki komunikacji/regulator, „no-ransom default” + ścieżki wyjątków.
  7. Zgodność z wytycznymi LEA:
    • Monitoruj aktualizacje i IOC publikowane w ramach Endgame/FBI/Europol i włącz do pipeline’u detekcji.

Różnice / porównania z innymi przypadkami

  • Dawniej (≈2014–2021): „tolerancja w zamian za lojalność” i okazjonalne zatrzymania pod presją; dziś — „sterowanie” rynkiem w reakcji na globalne operacje i koszty polityczne.
  • Inne państwa sankcjonowane: podobne modele (parasole ochronne nad grupami APT/fin-crime), lecz skala rosyjskiego RaaS-industrial complex i włączenie warstwy finansowej (exchangi, UAPS-like) czynią ekosystem bardziej modularnym i odpornym.

Podsumowanie / kluczowe wnioski

  • Teza „Controlled Impunity”: Rosja nie tyle likwiduje cyberprzestępczość, co steruje nią, godząc presję międzynarodową z własnym interesem.
  • Endgame zmieniła opłacalność niektórych ról w łańcuchu ransomware (zwłaszcza cash-out), ale rdzeń operatorów pozostaje aktywny i adaptacyjny.
  • Dla obrońców: przygotuj się na bardziej skryte RaaS, krótsze okna wykrycia i większy komponent geopolityczny w doborze celów.

Źródła / bibliografia

  • SecurityWeek: Russian Government Now Actively Managing Cybercrime Groups (23 października 2025). (SecurityWeek)
  • Recorded Future (Insikt Group): Dark Covenant 3.0: Controlled Impunity and Russia’s Cybercriminals (2025). (recordedfuture.com)
  • Europol: Largest ever operation against botnets… (Operation Endgame) (29 maja 2024) oraz Operation Endgame strikes again (22 maja 2025). (Europol)
  • FBI: Operation Endgame — Coordinated Worldwide Law Enforcement Action (28 maja 2024). (Federal Bureau of Investigation)
  • CyberScoop / The Record: Russia arrests nearly 100… (UAPS/Cryptex) (2 października 2024). (CyberScoop)

Hakerzy podszywają się pod kirgiskich urzędników. Kampania cyberszpiegowska wymierzona w rosyjskie instytucje (FoalShell & StallionRAT)

Wprowadzenie do problemu / definicja luki

Między majem a sierpniem 2025 r. klaster szpiegowski określany jako Cavalry Werewolf (powiązywany także z nazwami YoroTrooper i Silent Lynx) prowadził kampanię spear-phishingową wymierzoną w rosyjską administrację publiczną oraz firmy z sektorów energii, górnictwa i produkcji. Atakujący podszywali się pod kirgiskie ministerstwa, rozsyłając pisma urzędowe z archiwami RAR zawierającymi autorskie malware: FoalShell (reverse shell) i StallionRAT (RAT sterowany przez bota Telegram) — w części przypadków z wykorzystaniem skompro­m­itowanych prawdziwych skrzynek rządowych.

W skrócie

  • Wejście: spójne stylistycznie maile „z urzędu” (m.in. z resortów gospodarki i transportu KR), nierzadko z prawdziwych, przejętych adresów. Załączniki RAR prowadzą do droppera FoalShell/StallionRAT.
  • Cel: rosyjskie instytucje rządowe + przemysł (energia, górnictwo, produkcja); pojawiają się ślady zainteresowania Tadżykistanem i pliki nazwane po arabsku (rekonesans na Bliski Wschód).
  • TTPs: własne narzędzia, testowanie dodatkowych tooli (np. AsyncRAT), C2 przez Telegram, reverse shell w C# / C++ / Go.
  • Atrybucja historyczna: wcześniejsze badania Cisco Talos łączą YoroTrooper z Kazachstanem (język, waluta, profil celów).

Kontekst / historia / powiązania

YoroTrooper/Silent Lynx obserwowany jest co najmniej od 2022 r., z celami w regionie WNP i placówkach dyplomatycznych. W 2023 r. Talos opublikował obszerny przegląd kampanii YoroTrooper; w 2023–2025 pojawiały się kolejne doniesienia o podszywaniu się pod instytucje państwowe w Azji Centralnej. Najnowsza fala (lato 2025) koncentruje się na Rosji, ale wskazówki językowe i nazewnicze sugerują szersze ambicje geograficzne.

Analiza techniczna / szczegóły luki

Łańcuch infekcji

  1. Spear-phishing: wiadomości stylizowane na korespondencję urzędową (np. „trzymiesięczne wyniki wspólnych działań”, „lista pracowników do premii”), nadane z look-alike’ów lub przejętych kont urzędowych.
  2. Załącznik RAR: zawiera loader prowadzący do FoalShell (reverse shell) lub StallionRAT.
  3. Utrzymanie dostępu i C2:
    • FoalShell: wielojęzyczne implementacje (C#, C++, Go) uruchamiają ukryty cmd.exe i tunelują I/O do C2 (różne adresy IP/443 wg wariantów).
    • StallionRAT: implementacje w Go/PowerShell/Python; komunikacja i polecenia przez bota Telegram (/list, /go, /upload), exfil plików do katalogów publicznych.

Techniki (wybrane mapowanie MITRE ATT&CK):

  • T1566.001 Spear-phishing Attachment (RAR/archiwa) — wektor wejścia.
  • T1059 Command and Scripting Interpreter (PowerShell, cmd.exe).
  • T1105 Ingress Tool Transfer / T1071.001 Application Layer (Telegram jako kanał C2).
  • T1036 Masquerading (wiarygodne nazwy plików, formaty pism).

Dodatkowe obserwacje obronne (DFIR/Threat Hunting):

  • Monitorowanie tworzenia archiwów o nazwach „biurowych” w %LocalAppData%\Microsoft\Windows\INetCache\Content.Outlook\ na stacjach z Outlookiem.
  • Wykrywanie krótkotrwałych procesów cmd.exe uruchamianych przez nietypowych rodziców oraz anomalii w ruchu do Telegram API z hostów korporacyjnych.

Praktyczne konsekwencje / ryzyko

  • Kradzież danych i dostępów w instytucjach publicznych i firmach infrastrukturalnych (ryzyko wtórnych nadużyć, pivotu do OT, kompromitacji łańcucha dostaw).
  • Eskalacja geograficzna: artefakty w jęz. tadżyckim i arabskim wskazują na przygotowania do ataków poza Rosją; organizacje w Azji Centralnej i na Bliskim Wschodzie powinny podnieść czujność.
  • Inżynieria społeczna na brandach państwowych: podszywanie się pod ministerstwa zwiększa skuteczność kliknięć i utrudnia filtrowanie poczty.

Rekomendacje operacyjne / co zrobić teraz

E-mail i brama:

  • Blokowanie RAR/ACE/ISO z poczty do czasu ręcznej weryfikacji; sandboxing archiwów i skryptów.
  • Reguły YARA/EDR pod FoalShell i StallionRAT (na bazie IOCs z publikacji) oraz detekcja wywołań PowerShell z EncodedCommand/Bypass.

Host:

  • Polityki Constrained Language Mode dla PowerShell, Script Block Logging + centralna telemetria.
  • Detections na ukryte uruchomienia cmd.exe i nietypowe parent-child (np. z katalogów tymczasowych/outlook cache).

Sieć:

  • Blokowanie/monitoring ruchu do Telegram z sieci korporacyjnej; TLS inspection na wybranych strefach; listy dozwolonych.

Tożsamość i procesy:

  • Ochrona i audyt skrzynek „wysokiego zaufania” (departamenty: kadry, finanse, protokół dyplomatyczny), MFA i DMARC/DKIM/SPF w trybie reject dla domen urzędowych/partnerskich.

Threat Intel & IR:

  • Konsumpcja IOC/TTP z najnowszych analiz (BI.ZONE, Picus) i korelacja z lokalnymi logami; playbook IR na przypadki Telegram-C2.

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

  • YoroTrooper vs. inne rosyjsko-powiązane APT: Choć część klastrów w regionie bywa łączona z Rosją (np. APT28/Sednit), w przypadku YoroTrooper/Cavalry Werewolf wcześniejsze prace Cisco Talos wskazują na powiązania z Kazachstanem (język, waluta, profil celów), a nie z GRU/FSB. Nie ma jednoznacznej, oficjalnej atrybucji państwowej dla najnowszej fali; Picus jej nie stawia.
  • Kanał C2 przez Telegram odróżnia kampanię od wielu klasycznych operacji (częściej HTTP(S)/mail/OneDrive), choć aplikacyjne C2 pojawiało się już wcześniej u innych aktorów.

Podsumowanie / kluczowe wnioski

Cavalry Werewolf skutecznie eksploatuje zaufanie między instytucjami państwowymi (tu: wizerunek urzędów Kirgistanu), łącząc wysokiej jakości socjotechnikę z lekkimi, autorskimi narzędziami (FoalShell, StallionRAT). Wektor wejścia jest prosty (RAR w e-mailu), ale opakowany w wiarygodne, urzędowe narracje. Organizacje — zwłaszcza w administracji i przemyśle — powinny zaostrzyć polityki pocztowe, telemetrię PowerShell, oraz filtrować/monitorować Telegram jako potencjalny kanał C2.

Źródła / bibliografia

  1. The Record: „Hackers posing as Kyrgyz officials target Russian agencies in cyber espionage campaign”, 23 października 2025. (The Record from Recorded Future)
  2. BI.ZONE: „Espionage clusters disguise themselves as Kyrgyz state officials”, 2 października 2025. (BI.ZONE)
  3. Picus Security: „Cavalry Werewolf APT: Exposing FoalShell and StallionRAT Malware”, 20 października 2025. (Picus Security)
  4. Cisco Talos: „YoroTrooper operators likely based in Kazakhstan”, 25 października 2023. (Cisco Talos Blog)
  5. Cisco Talos: „Talos uncovers espionage campaigns targeting CIS countries… (YoroTrooper)”, 14 marca 2023. (Cisco Talos Blog)

BIND łata wysokie luki typu DNS cache poisoning (CVE-2025-40778, CVE-2025-40780). Co musisz zaktualizować i dlaczego to pilne

Wprowadzenie do problemu / definicja luki

Internet Systems Consortium (ISC) opublikowało aktualizacje BIND 9 usuwające poważne podatności umożliwiające DNS cache poisoning — wstrzyknięcie sfałszowanych rekordów DNS do pamięci podręcznej resolvera. Dwie główne luki to CVE-2025-40778 („niezamówione rekordy RRs” przyjmowane zbyt pobłażliwie) oraz CVE-2025-40780 (osłabione losowanie — możliwe przewidzenie portu źródłowego i ID zapytania), obie z oceną CVSS 8.6 (High). Łatki wydano 22–23 października 2025 r. wraz z wersjami 9.18.41, 9.20.15, 9.21.14 (oraz gałęzie S1 dla klientów wsparcia). Autorytatywne serwery zwykle nie są dotknięte, ryzyko dotyczy resolverów. Brak znanych obejść — aktualizacja jest jedyną skuteczną ochroną.

W skrócie

  • Na czym polega błąd?
    • CVE-2025-40778: resolver akceptuje „niezamówione” rekordy w odpowiedziach DNS, co pozwala zatruć cache.
    • CVE-2025-40780: słabości w PRNG umożliwiają w pewnych warunkach przewidzenie portu źródłowego i QID, co ułatwia spoofing odpowiedzi.
  • Kto jest zagrożony? Resolver BIND 9 w wielu wspieranych gałęziach (9.16/9.18/9.20/9.21 — szczegółowe zakresy poniżej). Autorytatywne instancje co do zasady nie.
  • Jakie wersje naprawiają? 9.18.41, 9.20.15, 9.21.14 (+ 9.18.41-S1, 9.20.15-S1).
  • Czy są exploity? Brak informacji o aktywnej eksploatacji w chwili publikacji.

Kontekst / historia / powiązania

ISC ujawniło trzy luki 22 października 2025 r.: oprócz dwóch błędów „cache poisoning” jest jeszcze CVE-2025-8677 (DoS przez złośliwe DNSKEY). Ogłoszenie trafiło również na listę oss-security, gdzie wskazano gotowe łatki oraz katalogi „patches” dla każdej gałęzi.

Publikacje branżowe (m.in. SecurityWeek) podkreślają, że nowe wersje BIND już są dostępne i należy je wdrożyć priorytetowo, zwłaszcza na publicznie dostępnych resolverach.

Analiza techniczna / szczegóły luki

CVE-2025-40778 – „niezamówione” rekordy RRs (unsolicited RRs)

  • Istota: w określonych okolicznościach BIND zbyt liberalnie akceptuje rekordy znajdujące się w sekcjach odpowiedzi, które nie są bezpośrednio związane z zapytaniem. To otwiera drogę do wstrzyknięcia sfałszowanych danych (np. A/AAAA/CNAME/NS) do cache.
  • Wpływ: manipulacja przyszłymi rozstrzygnięciami nazw (przekierowanie ruchu, MITM, phishing na poziomie DNS).
  • Zakres wersji podatnych (BIND): 9.11.0–9.16.50, 9.18.0–9.18.39, 9.20.0–9.20.13, 9.21.0–9.21.12; podobne dla edycji S1. Brak obejść.

CVE-2025-40780 – osłabiony PRNG (przewidywalny port/QID)

  • Istota: w pewnych warunkach słabości PRNG zmniejszają entropię kombinacji source port + query ID, co pozwala napastnikowi przygotować wiarygodną, sfałszowaną odpowiedź zanim dotrze prawdziwa.
  • Wpływ: skuteczny spoofing odpowiedzi i zatrucie cache.
  • Zakres wersji podatnych (BIND): 9.16.0–9.16.50, 9.18.0–9.18.39, 9.20.0–9.20.13, 9.21.0–9.21.12; brak znanych obejść. CVSS 8.6.

Trzecia luka: CVE-2025-8677 (DoS)

  • Opis skrótowy: możliwy DoS przy przetwarzaniu specjalnie spreparowanych rekordów DNSKEY; może prowadzić do wyczerpania CPU i spadku dostępności usługi. (Szczegóły w advisory ISC i notce SecurityWeek).

Praktyczne konsekwencje / ryzyko

  • Integritety DNS: Zatrucie cache pozwala zwrócić użytkownikom dowolne IP dla legalnej domeny (np. serwer atakującego), co ułatwia phishing, kradzież sesji i rozprzestrzenianie malware.
  • Łańcuchy zależności: usługi mikroserwisowe i IoT korzystające z lokalnych resolverów mogą przekierować ruch wewnętrzny poza zaufany perymetr.
  • Atak na skalę internetu: publiczne, rekurencyjne resolvery o dużym wolumenie zapytań są szczególnie atrakcyjne — jedna udana iniekcja rekordu NS/CNAME może mieć szeroki efekt kaskadowy.
  • Brak obejść: bez aktualizacji trudno efektywnie zredukować ryzyko, bo problem dotyka logiki akceptacji odpowiedzi i/lub entropii transakcji.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zaktualizuj BIND do najbliższej wspieranej wersji łatającej: 9.18.41, 9.20.15 lub 9.21.14 (w edycji S1 odpowiednio 9.18.41-S1, 9.20.15-S1). Zweryfikuj, że binaria rzeczywiście pochodzą z tych gałęzi.
  2. Zweryfikuj status pakietów dystrybucyjnych. Dla Ubuntu poprawki są już propagowane (np. noble/jammy), ale wersje i numery paczek mogą się różnić — porównaj z tablicami dystrybutora.
  3. Ogranicz ekspozycję resolverów:
    • nie udostępniaj rekursji klientom spoza zaufanych AS/VLAN;
    • włącz ACL/ views i filtrowanie źródeł;
    • jeśli to możliwe, nie wystawiaj publicznych resolverów dla świata. (Dobre praktyki wspierają ograniczenie skutków nawet po aktualizacji).
  4. Wzmocnij odporność na spoofing:
    • wymuś source-port randomization i upewnij się, że żaden middlebox nie „uładza” portów;
    • utrzymuj DNS Cookies/0x20 case randomization;
    • stosuj DNSSEC (walidacja) — nie eliminuje wszystkich ryzyk operacyjnych, ale znacząco utrudnia skuteczne zatruwanie cache. (Uwaga: artykuł dotyczy luk w resolverze; DNSSEC chroni integralność danych autorytatywnych, ale wymaga poprawnej walidacji po stronie resolvera).
  5. Monitoruj anomalie DNS: nagłe zmiany w statystykach NXDOMAIN/ SERVFAIL, nieoczekiwane rekordy NS/CNAME w cache, wzrost ruchu do „nowych” upstreamów.
  6. Plan awaryjny: przygotuj szybkie „flush cache” na instancjach, playbook na rollback zmian stref, oraz możliwość przełączenia klientów na alternatywny, zaufany resolver na czas incydentu.

Różnice / porównania z innymi przypadkami

  • ECS/Rebirthday i inne wektory historyczne: wcześniejsze scenariusze cache poisoning bywały związane z EDNS Client Subnet (ECS) i specyficzną logiką mieszania odpowiedzi. Obecne luki celują wprost w politykę akceptacji rekordów (40778) oraz entropię transakcji (40780), co przywraca klasyczne ryzyko „Kaminsky-style”, ale w nowym wydaniu i na współczesnych gałęziach BIND. (Zakres techniczny i skale wersji potwierdza ISC; dystrybutorzy publikują własne statusy).

Podsumowanie / kluczowe wnioski

  • Dwie luki „High” w BIND 9 (CVE-2025-40778, CVE-2025-40780) umożliwiają zatruwanie cache resolvera.
  • Brak obejść. Jedyną sensowną odpowiedzią jest natychmiastowa aktualizacja do 9.18.41 / 9.20.15 / 9.21.14 (S1: 9.18.41-S1 / 9.20.15-S1).
  • Autorytatywne serwery co do zasady bez wpływu, ale sprawdź, czy nie wykonują rekursji „przy okazji”.
  • Uporządkuj ekspozycję resolverów i wzmocnij higienę DNS (DNSSEC, losowość portów/QID, monitoring).

Źródła / bibliografia

  1. ISC KB – CVE-2025-40778: Cache poisoning attacks with unsolicited RRs (wersje podatne, brak obejść, wersje naprawcze). (kb.isc.org)
  2. ISC KB – CVE-2025-40780: Cache poisoning due to weak PRNG (opis PRNG, zakres wersji, CVSS, fixed). (kb.isc.org)
  3. Openwall oss-security – ogłoszenie ISC o trzech lukach w BIND 9 (CVE-2025-8677/40778/40780) i lokalizacje patchy. (Openwall)
  4. SecurityWeek – przegląd aktualizacji BIND i streszczenie ryzyka/wersji. (SecurityWeek)
  5. Ubuntu CVE-2025-40778 – status dystrybucyjny i wersje paczek. (Ubuntu)

AI Sidebar Spoofing: nowa technika podszywania się pod paski boczne w przeglądarkach AI (ChatGPT Atlas, Perplexity Comet, Edge/Brave/Firefox)

Wprowadzenie do problemu / definicja luki

Badacze SquareX opisali technikę AI Sidebar Spoofing – atak, w którym złośliwe rozszerzenie przeglądarki wstrzykuje w stronę fałszywy pasek boczny AI wyglądający identycznie jak oryginalny interfejs ChatGPT Atlas, Perplexity Comet czy wbudowane panele AI w Edge/Brave/Firefox. Użytkownik, przekonany że rozmawia z „prawdziwym” asystentem, otrzymuje zmanipulowane instrukcje prowadzące do phishingu, kradzieży danych lub wykonania złośliwych komend. Źródło: opis techniczny SquareX oraz omówienia prasowe z 23 października 2025 r.

W skrócie

  • Wektor: zainstalowane przez ofiarę rozszerzenie (malware, przejęte lub odkupione) z typowymi uprawnieniami host/storage.
  • Mechanika: w nowej karcie JS tworzy perfekcyjną kopię sidebaru AI i podstawia odpowiedzi z własnego LLM, wplatając fałszywe kroki (np. typosquatting, złośliwe komendy).
  • Zasięg: podatność systemowa dla „AI-browsers” (Comet, Atlas) i przeglądarek z panelami AI (Edge, Brave, Firefox).
  • Przykłady: phishing krypto (link do „binacee”), consent phishing/OAuth, reverse shell zamiast instalatora Homebrew.
  • Status: SquareX zgłosił temat do Perplexity; atak powtórzono także na ChatGPT Atlas (wydany kilka dni temu).

Kontekst / historia / powiązania

Przeglądarki z AI (Perplexity Comet, ChatGPT Atlas) stają się agentami wykonującymi działania w sieci. Wcześniejsze raporty (LayerX, Brave/Guardio) już pokazywały, że automatyzacja i brak „intuicji” modeli sprzyjają nadużyciom (np. prompt injection, transakcje na fałszywych sklepach). Sidebar spoofing wpisuje się w ten trend—tym razem celem jest zaufanie do interfejsu.

OpenAI w ogłoszeniu Atlasa podkreśla ograniczenia bezpieczeństwa agenta (m.in. nie uruchamia kodu w przeglądarce, nie instaluje rozszerzeń). Niestety, spoofing UI obchodzi te zabezpieczenia poprzez socjotechnikę i zewnętrzne rozszerzenie użytkownika.

Analiza techniczna / szczegóły luki

  1. Instalacja rozszerzenia
    • Atakujący dostarcza nowe/zainfekowane/odkupione rozszerzenie; ten wektor jest powszechny na rynku dodatków.
  2. Wstrzyknięcie UI
    • Po otwarciu nowej karty skrypt wstrzykuje HTML/CSS/JS i renderuje klon paska bocznego AI (layout, ikonografia, przepływ). Dla użytkownika brak różnic behawioralnych.
  3. Hook odpowiedzi LLM + modyfikacje
    • Rozszerzenie korzysta z własnego LLM (np. Gemini) i warunkowo modyfikuje odpowiedzi, gdy wykryje prośbę o instrukcje/komendy:
      • Phishing: typosquatted link zamiast oryginalnego (np. binacee zamiast Binance).
      • Consent phishing (OAuth): kierowanie do aplikacji żądającej szerokich uprawnień (np. pełny dostęp do Gmail/Drive).
      • RCE: podmiana komendy instalacyjnej na reverse shell (częściowo base64), uzyskanie zdalnej powłoki i trwałego dostępu.
  4. Wariant bez rozszerzenia
    • Możliwy również spoofing natywny w złośliwej witrynie (mniej elastyczny niż rozszerzenie, ale realny).
  5. Dlaczego to działa?
    • Heurystyka zaufania do UI: użytkownik ufa „znanemu” paskowi AI.
    • „Asystent” ≠ „przeglądarka”: zabezpieczenia agenta nie obejmują scenariusza, w którym UI agenta jest fałszywe.
    • Uprawnienia rozszerzeń: host/storage to popularne, „niewinne” uprawnienia.

Praktyczne konsekwencje / ryzyko

  • Kradzież tożsamości i środków: przekierowanie na phishingi (krypto, bankowość).
  • Przejęcie kont poprzez OAuth: aplikacje trzecie z nadmiernymi uprawnieniami.
  • Zdalne wykonanie kodu / Lateral movement: reverse shell, doinstalowanie RAT, ransomware.
  • Eskalacja w środowisku korporacyjnym: AI jako „opiekun procesu” normalizuje ryzykowne działania użytkownika; wcześniejsze incydenty z Comet pokazały, że AI potrafi wykonywać niebezpieczne akcje bez właściwej walidacji.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa (SecOps/IT):

  1. Twarda polityka rozszerzeń
    • Whitelisting, blokada instalacji poza sklepem, okresowe audytowanie zainstalowanych dodatków i ich uprawnień; SCA dla rozszerzeń (statyczna/dynamiczna analiza).
  2. EDR + reguły DLP pod AI
    • Detekcja wklejania komend o charakterze reverse shell, blokada podejrzanych łańcuchów base64, alerty na bash -i >& /dev/tcp/....
  3. Polityki przeglądarkowe
    • Wymuszanie trybów bezpiecznych, ostrzeganie przy OAuth z nadmiernymi uprawnieniami do niezatwierdzonych aplikacji; blokada znanych technik typosquattingu i stron ML-owo podejrzanych.
  4. Hardening agenta AI
    • W przeglądarkach z AI: widoczne wskaźniki autentyczności UI (origin/issuer), „secure attention sequence” przed wykonaniem instrukcji wysokiego ryzyka; włączanie restrykcji Atlasa to za mało—pamiętaj, że spoofing omija te warstwy.
  5. Szkolenia
    • „Zasada nieufności do UI AI”: jeśli pasek boczny instruuje do logowania, instalacji, poleceń systemowych — weryfikuj domenę i proś o wgląd w pełny URL; nigdy nie wykonuj bezpośrednio komend z UI. (Wskaż użytkownikom różnice między oficjalnym a „pływającym” panelem).

Dla użytkowników końcowych:

  • Instaluj rozszerzenia tylko z listy firmowej; sprawdzaj wydawcę i repozytorium.
  • Przed logowaniem/zakupem kliknij ikonę kłódki i porównaj pełny FQDN.
  • Kopiuj komendy do edytora i czytaj je, zanim trafią do terminala; zwróć uwagę na curl | sh, nc, bash -c, długie base64.
  • Gdy UI AI prosi o OAuth z szerokim dostępem (np. full access to Gmail/Drive) – przerwij i skonsultuj z IT.

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

  • Prompt/indirect injection vs UI spoofing: w pierwszym atakujesz model (logikę), w drugim percepcję użytkownika (interfejs) – co bywa skuteczniejsze, bo nie wymaga złamania sandboxu ani uprawnień agenta.
  • CometJacking/automatyzacja agentów (LayerX) wpływała na działania AI w ramach legalnego interfejsu; Sidebar Spoofing tworzy fałszywy interfejs, przez co ofiara nie zauważa, że nie rozmawia z prawdziwym agentem.

Podsumowanie / kluczowe wnioski

AI Sidebar Spoofing to atak na zaufanie do interfejsu AI. Nawet przy restrykcjach Atlasa, które ograniczają możliwości agenta, złośliwe rozszerzenie może całkowicie ominąć te bariery, podsuwając fałszywe instrukcje w „znanym” UI i prowadząc do poważnych incydentów (phishing, OAuth, RCE). Organizacje powinny traktować rozszerzenia jak kod o wysokim ryzyku, wdrożyć polityki przeglądarkowe i telemetrię specyficzną dla AI – oraz szkolić użytkowników, by nie ufać bezkrytycznie paskom bocznym AI.

Źródła / bibliografia

  • SecurityWeek: „AI Sidebar Spoofing Puts ChatGPT Atlas, Perplexity Comet and Other Browsers at Risk” (23 paź 2025). (SecurityWeek)
  • SquareX Labs: „AI Sidebar Spoofing: Malicious Extensions Impersonates AI Browser Interface” (16 paź 2025). (SquareX Labs)
  • BleepingComputer: „Spoofed AI sidebars can trick Atlas, Comet users into dangerous actions” (23 paź 2025). (BleepingComputer)
  • OpenAI: „Introducing ChatGPT Atlas” – sekcja o zabezpieczeniach agenta (ok. 21–22 paź 2025). (OpenAI)
  • LayerX Security: „CometJacking…” – szerszy kontekst ryzyk przeglądarek AI (4 paź 2025). (LayerX)

Exploit „SessionReaper” w Adobe Commerce (Magento) – aktywne ataki na sklepy. Co musisz zrobić teraz

Wprowadzenie do problemu / definicja luki

W Adobe Commerce (Magento Open Source) ujawniono krytyczną podatność CVE-2025-54236 („SessionReaper”), ocenioną na CVSS 9.1. Błąd wynika z nieprawidłowej walidacji danych wejściowych i może prowadzić do obejścia mechanizmów bezpieczeństwa poprzez REST API – bez uwierzytelnienia. Adobe potwierdziło aktywną eksploatację tej luki i zaleca natychmiastowe aktualizacje/hotfixy.

W skrócie

  • Status: aktywnie wykorzystywana w atakach (od 22–23 października 2025).
  • Wpływ: przejęcie sesji klientów (account takeover); w określonych warunkach możliwa pre-auth RCE.
  • Łatka: hotfix z 9 września 2025 r. + aktualizacje bezpieczeństwa z października; Adobe zaktualizowało biuletyn 22 października, dodając wzmiankę o exploitach „in the wild”.
  • Skala: setki prób dziennie, większość niezałatanych sklepów nadal podatna.

Kontekst / historia / powiązania

Adobe opublikowało APSB25-88 9 września 2025 r., udostępniając hotfix kompatybilny z wersjami 2.4.4–2.4.7 i odnoszący się do szerszej puli wersji (m.in. 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 i wcześniejsze). 22 października Adobe dopisało do biuletynu, że CVE-2025-54236 jest wykorzystywana w środowisku produkcyjnym. Równolegle Sansec ostrzegł, że szczegóły techniczne wyciekały/stały się publiczne, co przyspiesza weaponizację.

Analiza techniczna / szczegóły luki

  • Klasa problemu: Improper Input Validation (CWE-20) → Security Feature Bypass (bez uwierzytelniania; niski poziom złożoności ataku).
  • Wektor: nadużycie Commerce REST API i manipulacja sesją; Sansec opisuje łańcuch z zagnieżdżoną deserializacją oraz wskazuje, że praktyczna droga do RCE może wymagać file-based session storage (domyślnej konfiguracji wielu sklepów).
  • Artefakty ataków w naturze: pierwsze fale obejmowały upload PHP webshelli i phpinfo jako sondy; obserwowane masowe skanowanie i automatyzacja.
  • Ścieżki HTTP widziane w telemetrii: m.in. /customer/address_file/upload używane do wstrzykiwania spreparowanych ładunków.

Praktyczne konsekwencje / ryzyko

  • Przejęcie kont klientów (kradzież danych, zamówienia, oszustwa, chargebacki).
  • W wielu środowiskach realna jest eskalacja do RCE i pełne przejęcie sklepu (skimming płatności, podszywanie się, modyfikacja treści, implanty).
  • Duża powierzchnia ataku: według Sansec tylko ~38% sklepów było załatanych, gdy ruszyły kampanie; liczba prób w pierwszym dniu sięgała ~250.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zastosuj hotfix/aktualizację z APSB25-88 (i późniejsze zbiorcze aktualizacje z października). Testuj w stagingu, ale priorytetem jest czas reakcji.
  2. WAF / edge ochronny: jeżeli wdrożenie łatki dziś nie jest możliwe, aktywuj reguły WAF (np. Fastly dla Commerce Cloud) blokujące znane wektory REST/API.
  3. Zmiana storage’u sesji: rozważ przejście z file-based na Redis/DB (zmniejsza ryzyko znanych łańcuchów do RCE).
  4. Hunting i IR:
    • Przejrzyj logi pod kątem żądań do /customer/address_file/upload i nietypowych POST-ów do REST API.
    • Wyszukaj phpinfo, webshelle, nowe pliki w pub/media, var/session/, var/tmp/.
    • Rotuj secret crypt key i tokeny integracji; wymuś reset haseł klientów/adminów, jeśli wykryto naruszenie.
  5. Hardening:
    • Ogranicz uprawnienia do katalogów var/ i uploadów, włącz CSP, audytuj rozszerzenia.
    • Monitoruj integralność plików (FSIM/EDR) i włącz alerty na tworzenie/zmiany plików PHP w katalogach uploadu. (Dobre praktyki; niezależne od vendorów).
  6. Komunikacja biznesowa: przygotuj komunikat do klientów (jeśli incydent), proces chargebacków, kontakt z bramkami płatniczymi i programem PCI DSS.

Różnice / porównania z innymi przypadkami

Sansec porównuje SessionReaper do wcześniejszych głośnych błędów Magento: Shoplift (2015), TrojanOrder (2022) i CosmicSting (2024) – wszystkie prowadziły do masowych kompromitacji w krótkim czasie po publikacji exploitów. Wspólnym mianownikiem jest niska złożoność ataku i szybka automatyzacja.

Podsumowanie / kluczowe wnioski

  • CVE-2025-54236 to krytyczna luka w Adobe Commerce/Magento, aktywnie wykorzystywana od 22–23.10.2025.
  • Adobe potwierdziło eksploatację „in the wild” i udostępniło hotfix/aktualizacje – zastosuj je natychmiast.
  • Ryzyko obejmuje przejęcie sesji klientów i – zależnie od konfiguracji – RCE.
  • Jeśli nie możesz załatać dziś: WAF + zmiana storage’u sesji + hunting artefaktów.

Źródła / bibliografia

  • Adobe, APSB25-88: Security update for Adobe Commerce / Magento Open Source (wyd. 9.09.2025, aktual. 22.10.2025). (Adobe Help Center)
  • Sansec, SessionReaper – unauthenticated RCE in Magento & Adobe Commerce (CVE-2025-54236). (Sansec)
  • Sansec, SessionReaper attacks have started, 3 in 5 stores still vulnerable (22.10.2025). (Sansec)
  • SecurityWeek, Exploitation of Critical Adobe Commerce Flaw Puts Many eCommerce Sites at Risk (23.10.2025). (SecurityWeek)
  • BleepingComputer, Hackers exploiting critical “SessionReaper” flaw in Adobe Magento (22.10.2025). (BleepingComputer)

CISA ostrzega: krytyczna luka w LanScope Endpoint Manager aktywnie wykorzystywana (CVE-2025-61932)

Wprowadzenie do problemu / definicja luki

Amerykańska agencja CISA dodała do katalogu Known Exploited Vulnerabilities (KEV) nowy wpis dotyczący LanScope Endpoint Manager (on-premises) firmy MOTEX. Luka CVE-2025-61932 umożliwia zdalne wykonanie kodu (RCE) na stacjach końcowych poprzez „nieprawidłową weryfikację źródła kanału komunikacyjnego” (CWE-940). Producent potwierdził, że w środowiskach klientów odnotowano już nieautoryzowane pakiety z zewnątrz, co wskazuje na realne próby nadużycia.

W skrócie

  • ID luki: CVE-2025-61932; CVSS 4.0: 9.3, CVSS 3.0: 9.8 (krytyczna).
  • Dotyczy: LanScope Endpoint Manager On-Premises – komponenty Client (MR) i Detection Agent (DA); wersje 9.4.7.1 i wcześniejsze. Wersja chmurowa nie jest podatna.
  • Status: luka aktywnie wykorzystywana; wpis w CISA KEV (obowiązek szybkiej remediacji dla agencji federalnych USA).
  • Producent udostępnił poprawki; aktualizacja wymagana na klientach/agentach, bez konieczności podnoszenia wersji „managera”.
  • Termin dla FCEB (USA): rekomendowana data remediacji 12 listopada 2025 r. (wg doniesień prasowych).

Kontekst / historia / powiązania

LanScope (MOTEX, spółka z grupy Kyocera) jest szeroko wykorzystywany do inwentaryzacji i nadzoru stacji w regionie APAC, zwłaszcza w Japonii. JVN/JPCERT opublikowały notę o podatności tego samego dnia, co producent, potwierdzając wczesne sygnały ataków w środowiskach krajowych. Wcześniejsze lata notowały słabsze wagi podatności w produktach MOTEX, ale CVE-2025-61932 to pełnoprawny RCE bez uwierzytelnienia – krytyczny scenariusz podobny do wielu ostatnich fal masowych exploitów w oprogramowaniu do zarządzania stacjami.

Analiza techniczna / szczegóły luki

  • Klasa błędu: Improper Verification of Source of a Communication Channel (CWE-940). Mechanizm komunikacji przyjmuje pakiety z niezweryfikowanego źródła jako zaufane, co umożliwia atakującemu przesłanie specjalnie przygotowanych pakietów skutkujących wykonaniem dowolnego kodu.
  • Wektory ataku: sieć (AV:N), niska złożoność (AC:L), brak wymagań dot. uprawnień (PR:N) i interakcji użytkownika (UI:N) – zgodnie z ocenami CVSS 3.0/4.0. To oznacza, że eksploatacja jest możliwa zdalnie i masowo.
  • Zakres komponentów: wyłącznie Client (MR) i Detection Agent (DA) po stronie endpointów; instancja „managera” nie wymaga aktualizacji.

Praktyczne konsekwencje / ryzyko

  • Przejęcie stacji końcowych: zdalne RCE na hostach z agentem umożliwia instalację backdoorów, eskalację uprawnień lokalnych, ruch boczny i kradzież danych.
  • Skala zagrożenia: CISA klasyfikuje CVE jako aktywnie wykorzystywane – organizacje wystawiające agentów lub ich porty na niezaufowane sieci są w strefie najwyższego ryzyka.
  • Rynek/region: media branżowe raportują, że pierwsze przypadki i obserwacje napływają z Japonii (główna baza użytkowników), co zwiększa prawdopodobieństwo szybkiej eskalacji globalnej poprzez skanowanie Internetu.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja agentów na wszystkich stacjach do jednej z wersji zawierających poprawkę:
    9.3.2.7, 9.3.3.9, 9.4.0.5, 9.4.1.5, 9.4.2.6, 9.4.3.8, 9.4.4.6, 9.4.5.4, 9.4.6.3, 9.4.7.3. (Wersje 9.4.7.1 i starsze są podatne). Nie ma potrzeby aktualizowania „managera”.
  2. Priorytetyzacja floty: zacznij od stacji z dostępem zdalnym/VPN oraz urządzeń w segmentach o podwyższonych uprawnieniach. (dobre praktyki ogólne)
  3. Tymczasowe zabezpieczenia do czasu patchowania:
    • Ogranicz ekspozycję sieciową kanałów komunikacji agentów do zaufowanych podsieci/VPN.
    • Filtruj/monitoruj nietypowy ruch przychodzący do procesów MR/DA oraz wzorce „nietypowych pakietów” wskazywane przez producenta/JVN.
  4. Hunting i detekcja:
    • Szukaj nowych/nieautoryzowanych procesów potomnych agenta, anomalii w narzędziach zdalnego dostępu, zmian w autostarcie i nowych kontach lokalnych. (praktyka oparta na wzorcach RCE)
    • Koreluj alerty z timeline’em od 20 października 2025 r. (data publikacji producenta/JVN).
  5. Zgodność i terminy: jeśli podlegasz wymogom FCEB/KEV – zaplanuj remediację do 12 listopada 2025 r.; dla innych organizacji rekomendowane „ASAP”.
  6. Komunikacja z biznesem: poinformuj właścicieli systemów o ryzyku przerwy w pracy podczas aktualizacji agenta oraz zapewnij okna serwisowe.

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

W przeciwieństwie do wielu ostatnich podatności w narzędziach EDR/EMM, CVE-2025-61932 uderza w komponenty klienckie, a nie w serwer/manager. To oznacza konieczność szerokiej dystrybucji aktualizacji na końcówkach, co bywa logistycznie trudniejsze, ale jednocześnie ogranicza ryzyko pojedynczego punktu kompromitacji (centralny serwer). Brak wymogu aktualizacji „managera” upraszcza change-management po stronie serwera.

Podsumowanie / kluczowe wnioski

  • Krytyczna luka RCE (CVE-2025-61932) w LanScope Endpoint Manager jest już wykorzystywana – nie czekaj na PoC.
  • Patchuj agentów (MR/DA) do wersji naprawionych – lista powyżej – manager bez zmian.
  • Zredukuj ekspozycję sieciową, wdroż monitoring i polowania na oznaki kompromitacji.
  • Dla podmiotów objętych KEV – deadline 12.11.2025; pozostali: działaj natychmiast.

Źródła / bibliografia

  • BleepingComputer: „CISA warns of Lanscope Endpoint Manager flaw exploited in attacks”. (BleepingComputer)
  • CISA KEV – wpis dla CVE-2025-61932. (cisa.gov)
  • MOTEX (producent) – „[重要なお知らせ]… Remote Code Execution… (CVE-2025-61932)”, 20.10.2025. (motex.co.jp)
  • JVN/JPCERT – „JVN#86318557: Lanscope Endpoint Manager (On-Premises) vulnerable to…”, 20–21.10.2025. (jvn.jp)
  • NVD – rekord CVE-2025-61932 (opis techniczny/CVSS). (NVD)
  • (Kontekst terminów): The Hacker News – „Critical Lanscope Endpoint Manager Bug…”, 23.10.2025. (The Hacker News)

Microsoft wyłącza podgląd w folderze „Pobrane” – nowe zabezpieczenie przed kradzieżą skrótów NTLM

Wprowadzenie do problemu / definicja luki

Microsoft wprowadził zmianę, która automatycznie wyłącza okienko podglądu (Preview Pane) w Eksploratorze plików dla plików pobranych z Internetu i plików oglądanych z udziałów sklasyfikowanych jako Internet Zone. Celem jest zablokowanie kradzieży skrótów NTLM podczas samego zaznaczenia pliku do podglądu – bez otwierania go w aplikacji. Zmiana obowiązuje po instalacji aktualizacji zabezpieczeń z 14 października 2025 r. i nowszych (Windows 11 oraz Windows Server) i jest włączana automatycznie.

W skrócie

  • Co się zmieniło: Eksplorator Windows nie pokaże podglądu plików oznaczonych Mark of the Web (MotW) ani przeglądanych z udziałów w strefie Internet. Zamiast tego zobaczysz komunikat ostrzegawczy.
  • Po co: aby zablokować scenariusze, w których sam podgląd pliku (np. z tagami HTML odwołującymi się do zewnętrznych ścieżek) powodował wysłanie uwierzytelnienia NTLM do serwera atakującego.
  • Kontekst: w 2025 r. udokumentowano aktywnie wykorzystywaną podatność ujawniającą skróty NTLM przy użyciu plików .library-ms rozsyłanych w phishingu.
  • Status: zmiana jest już dystrybuowana w październikowych aktualizacjach, co potwierdził również przegląd branżowy.

Kontekst / historia / powiązania

W pierwszej połowie 2025 r. badacze wskazali, że odpowiednio spreparowane pliki .library-ms mogą wywoływać ujawnienie skrótów NTLM (NTLM hash disclosure) i służyć do relay/brute-force w dalszych etapach ataku. CISA dodała CVE-2025-24054 do katalogu Known Exploited Vulnerabilities, a analizy Check Point opisały aktywne nadużycia od 19 marca 2025 r. w kampaniach phishingowych.

Równolegle Microsoft przyspieszył odchodzenie od NTLM w Windows 11 24H2/Windows Server 2025 (m.in. usunięcie NTLMv1, nowe logowanie audytowe NTLM), jednak pełne wyłączenie NTLMv2 to proces wieloetapowy.

Analiza techniczna / szczegóły luki

  • Vektor ataku: plik oznaczony MotW lub przeglądany z Internet Zone zawiera treści, które w czasie renderowania podglądu (Preview Pane) mogą odwołać się do zasobów zdalnych (np. przez tagi HTML <link>/src> lub podobne mechanizmy w handlerach podglądu).
  • Skutek: system może spróbować uwierzytelnić dostęp do zewnętrznego zasobu przy użyciu NTLM, wysyłając skrót (hash). Napastnik, kontrolując serwer, może przechwycić hash i wykorzystać go w atakach NTLM relay lub do offline cracking.
  • Mitigacja Microsoftu (październik 2025): pełne wyłączenie podglądu dla takich plików – użytkownik widzi komunikat: „The file you are attempting to preview could harm your computer…”. Wyjątki wymagają świadomego odblokowania przez użytkownika/admina.

Ta zmiana minimalizuje interakcję wymaganą od ofiary – wcześniej wystarczało zaznaczenie pliku, teraz podgląd nie zostanie wygenerowany automatycznie.

Praktyczne konsekwencje / ryzyko

  • Użytkownicy końcowi: mniej „cichych” wektorów phishingu – przypadkowe zaznaczenie pliku z poczty/WWW nie wyśle już NTLM.
  • Zespoły IT: możliwe skargi na „brak podglądu” w procesach pracy z pobranymi dokumentami (np. oceną plików). Dla zaufanych źródeł trzeba używać mechanizmu Unblock lub stref Trusted sites/Local intranet – z pełną świadomością, że to obniża poziom ochrony.
  • Zagrożenia, które pozostają: środowiska z włączonym NTLM nadal są podatne na inne kanały wycieku (SMB, WebDAV, Outlook, itp.), stąd potrzeba szerszego hardeningu NTLM i monitoringu.

Rekomendacje operacyjne / co zrobić teraz

  1. Zastosuj październikowe aktualizacje (2025-10-14 i nowsze) na Windows 11/Windows Server. Zmiana włączy się automatycznie.
  2. Zachowaj domyślne wyłączenie podglądu dla plików z MotW/Internet Zone. Nie globalnie odblokowuj, o ile nie jest to absolutnie konieczne.
  3. Jeżeli musisz umożliwić podgląd zaufanych plików:
    • pojedynczy plik: Properties → Unblock (wymaga ponownego logowania, by zadziałało konsekwentnie),
    • udział: dodaj do Trusted sites/Local intranet – pamiętaj, że obniżasz ochronę wszystkich plików z tego udziału.
  4. Ogranicz użycie NTLM w domenie: egzekwuj preferencję Kerberos (Negotiate), wyłącz NTLMv1 (jeśli jeszcze gdzieś żyje), zaplanuj deprecjację NTLMv2 zgodnie ze wskazówkami Microsoft (24H2/Server 2025 wprowadzają audyt ułatwiający inwentaryzację użycia NTLM).
  5. Monitoruj zdarzenia NTLM (Windows 11 24H2 / Server 2025 mają nowe logi: Applications and Services Logs → Microsoft → Windows → NTLM → Operational). Ustal progi alertowania dla nietypowych źródeł/hostów.
  6. Uzupełnij kontrolami towarzyszącymi: ASR/SmartScreen dla MotW, blokady makr, egzekwowanie SMB Signing, segmentacja serwerów, EDR z detekcją NTLM relay. (Wnioski na podstawie kierunku zmian Microsoft i analizy incydentów z CVE-2025-24054).

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

  • W CVE-2025-24054 atak opierał się na plikach .library-ms i mógł zostać zainicjowany już na etapie podglądu/renderowania zasobów; obecna zmiana systemowo ucina ten wektor w Eksploratorze.
  • Wcześniejsze działania Microsoft dotyczyły protokolarnego poziomu NTLM (usuwanie NTLMv1, audyt), natomiast tutaj to zabezpieczenie UX/systemowe w warstwie shell/preview handlers. Razem składają się na obronę w głąb.

Podsumowanie / kluczowe wnioski

Blokada podglądu dla plików z Internetu to prosty, ale skuteczny sposób na wyeliminowanie popularnego wektora kradzieży skrótów NTLM bez zmuszania użytkowników do zmiany nawyków. Dla SOC/IT to dobry moment, by przycisnąć deprecjację NTLM, wdrożyć audyt 24H2/Server 2025 i konsekwentnie redukować wyjątki w Trusted sites.

Źródła / bibliografia

  1. Microsoft Support – File Explorer automatically disables the preview feature for files downloaded from the internet (KB 5070960), 22.10.2025. (Microsoft Support)
  2. BleepingComputer – Microsoft disables File Explorer preview for downloads to block attacks, 23.10.2025. (BleepingComputer)
  3. Check Point Research – CVE-2025-24054: NTLM exploit in the wild, 16.04.2025. (Check Point Research)
  4. CISA – Known Exploited Vulnerabilities Catalog (CVE-2025-24054). (cisa.gov)
  5. Microsoft Support – Overview of NTLM auditing enhancements in Windows 11 24H2 & Windows Server 2025, 11.07.2025; oraz Upcoming changes to NTLMv1…, 29.08.2025. (Microsoft Support)