Archiwa: SIEM - Strona 16 z 60

Itron ujawnia naruszenie wewnętrznej sieci IT. Incydent u dostawcy technologii dla infrastruktury krytycznej

Wprowadzenie do problemu / definicja

Itron, amerykański dostawca technologii dla sektora energetycznego, wodociągowego i inteligentnej infrastruktury, poinformował o cyberincydencie obejmującym nieautoryzowany dostęp do części wewnętrznych systemów IT. Sprawa budzi szczególne zainteresowanie, ponieważ dotyczy firmy działającej w obszarze infrastruktury krytycznej, gdzie nawet ograniczone naruszenie może mieć znaczenie wykraczające poza jedną organizację.

W tego typu przypadkach kluczowe znaczenie ma nie tylko sam fakt uzyskania dostępu przez intruza, ale także możliwość wpływu na łańcuch dostaw, systemy klientów oraz operacje biznesowe podmiotów korzystających z rozwiązań dostawcy.

W skrócie

Itron został 13 kwietnia 2026 roku powiadomiony o nieautoryzowanym dostępie do wybranych systemów.
Firma uruchomiła plan reagowania na incydenty, zaangażowała zewnętrznych ekspertów i powiadomiła organy ścigania.
Według przekazanych informacji złośliwa aktywność została usunięta, a w systemach korporacyjnych nie zaobserwowano dalszej obecności intruza.
Spółka poinformowała również, że część hostowana dla klientów nie wykazała oznak nieuprawnionej aktywności.
Operacje biznesowe były kontynuowane bez istotnych zakłóceń, jednak dochodzenie nadal trwa.

Kontekst / historia

Itron jest rozpoznawalnym dostawcą rozwiązań dla przedsiębiorstw użyteczności publicznej oraz inteligentnego opomiarowania. Obsługuje sektor energii, wody i szeroko pojętej infrastruktury miejskiej, co oznacza, że każdy incydent bezpieczeństwa w jego środowisku IT jest oceniany również pod kątem ryzyka dla usług krytycznych i partnerów biznesowych.

Informacja o zdarzeniu została ujawniona m.in. w raporcie bieżącym złożonym do amerykańskiej Komisji Papierów Wartościowych i Giełd. Taki tryb publikacji wskazuje, że incydent został uznany za na tyle istotny, by podlegał ocenie z perspektywy operacyjnej, finansowej i regulacyjnej. Jednocześnie firma zaznaczyła, że analiza nadal trwa, a pełny zakres zdarzenia nie został jeszcze ostatecznie potwierdzony.

Znaczenie sprawy podkreśla także skala działalności spółki. Itron raportował za 2025 rok przychody na poziomie około 2,4 mld USD, co pokazuje, że ewentualne skutki bezpieczeństwa mogą mieć znaczenie nie tylko lokalne, ale również szerokie biznesowo i sektorowo.

Analiza techniczna

Na obecnym etapie publicznie dostępne informacje nie wskazują jednoznacznie, jaki był początkowy wektor ataku. Nie wiadomo jeszcze, czy źródłem naruszenia był phishing, przejęcie danych uwierzytelniających, wykorzystanie podatności, błędna konfiguracja czy kompromitacja elementu zewnętrznego ekosystemu dostawcy.

Z komunikatów wynika jednak, że po wykryciu zdarzenia uruchomiono standardowe działania reagowania: izolację incydentu, wsparcie zewnętrznych doradców oraz analizę mającą na celu ocenę, ograniczenie i usunięcie nieautoryzowanej aktywności. Firma przekazała również, że po wdrożeniu środków zaradczych nie odnotowano kolejnych oznak obecności intruza w systemach korporacyjnych.

Z technicznego punktu widzenia ważne jest rozróżnienie pomiędzy środowiskiem korporacyjnym a systemami hostowanymi dla klientów. To istotny szczegół, ponieważ może wskazywać na skuteczną segmentację sieci, oddzielenie usług lub odpowiednio wdrożone mechanizmy detekcji i ograniczania ruchu bocznego. Brak widocznej nieautoryzowanej aktywności w środowiskach klientów nie eliminuje ryzyka całkowicie, ale sugeruje, że zasięg incydentu mógł zostać ograniczony.

Nie podano również informacji o przypisaniu ataku do konkretnej grupy ransomware lub innego aktora zagrożeń. Taki brak może oznaczać, że analiza artefaktów nadal trwa, nie doszło do etapu publicznego wymuszenia albo napastnik nie został jeszcze jednoznacznie zidentyfikowany.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko w podobnych incydentach dotyczy możliwości przejścia z warstwy IT do obszarów mających wpływ na usługi krytyczne. Nawet jeśli organizacja deklaruje brak istotnych zakłóceń, samo naruszenie systemów dostawcy działającego dla sektora utility wymaga podwyższonej czujności.

Drugim istotnym obszarem pozostaje ekspozycja danych. Jeżeli dochodzenie nadal trwa, oznacza to zwykle konieczność szczegółowej analizy logów, poczty, repozytoriów plików oraz systemów końcowych pod kątem tego, czy intruz uzyskał dostęp do informacji własnych spółki lub danych stron trzecich.

Wysokie jest także ryzyko dla łańcucha dostaw. Nawet przy braku potwierdzonego wpływu na klientów partnerzy i odbiorcy usług powinni przeanalizować zaufane połączenia, konta serwisowe, integracje API oraz relacje administracyjne. W środowiskach o dużym stopniu integracji zagrożenie nie musi ograniczać się wyłącznie do bezpośrednio naruszonej organizacji.

Nie można też pominąć ryzyka reputacyjnego i regulacyjnego. Firmy działające na styku technologii, usług publicznych i infrastruktury krytycznej podlegają rosnącym wymaganiom w zakresie przejrzystości, raportowania incydentów i utrzymywania odporności operacyjnej.

Rekomendacje

Incydent w Itron stanowi ważne przypomnienie dla organizacji z sektorów utility, smart infrastructure i OT, że skuteczna ochrona musi opierać się na segmentacji, kontroli tożsamości oraz ograniczonym zaufaniu między środowiskami.

Wdrożenie ścisłego rozdziału środowisk IT, OT i systemów dostępnych dla klientów.
Obowiązkowe MFA dla dostępu zdalnego, konsol administracyjnych i systemów krytycznych.
Monitorowanie kont uprzywilejowanych oraz serwisowych pod kątem anomalii i nadużyć.
Centralizacja logów i korelacja zdarzeń w SIEM z naciskiem na ruch boczny oraz nietypowe sesje.
Regularna aktualizacja reguł EDR/XDR pod kątem persistence, credential access i defense evasion.
Testowanie planów reagowania na incydenty z uwzględnieniem scenariuszy naruszenia dostawcy lub usług pośrednich.
Walidacja kopii zapasowych i procedur odtwarzania zarówno w środowiskach biznesowych, jak i operacyjnych.
Przegląd integracji zewnętrznych, połączeń B2B i zależności API zgodnie z zasadą minimalnego zaufania.

Dla klientów i partnerów biznesowych uzasadnione jest także przeprowadzenie własnej oceny ekspozycji. Powinna ona objąć federację tożsamości, tunele VPN, kanały wsparcia z podwyższonymi uprawnieniami, współdzielone repozytoria danych oraz wszelkie inne punkty styku z dostawcą.

Podsumowanie

Naruszenie ujawnione przez Itron pokazuje, że incydenty w środowiskach korporacyjnych dostawców technologii dla infrastruktury krytycznej mają znaczenie znacznie szersze niż tylko wpływ na pojedynczą firmę. Choć spółka informuje o braku istotnych zakłóceń operacyjnych i braku oznak nieuprawnionej aktywności w systemach hostowanych dla klientów, pełna ocena skutków nadal pozostaje w toku.

Z perspektywy cyberbezpieczeństwa najważniejsze wnioski są jednoznaczne: szybka detekcja, sprawne uruchomienie procedur reagowania, współpraca z zewnętrznymi ekspertami oraz ograniczenie zasięgu incydentu mają kluczowe znaczenie. Dla całej branży to kolejny sygnał, że odporność operacyjna musi obejmować nie tylko ochronę perymetru, ale również segmentację, monitoring tożsamości i gotowość na incydenty o charakterze łańcucha dostaw.

Źródła

BleepingComputer – American utility firm Itron discloses breach of internal IT network – https://www.bleepingcomputer.com/news/security/american-utility-firm-itron-discloses-breach-of-internal-it-network/
U.S. Securities and Exchange Commission – Itron, Inc. Form 8-K – https://www.sec.gov/Archives/edgar/data/780571/000119312526175249/d125229d8k.htm
Itron Investor Relations – Itron Announces Fourth Quarter and Full Year 2025 Financial Results – https://investors.itron.com/news-releases/news-release-details/itron-announces-fourth-quarter-and-full-year-2025-financial
Itron – Smart Energy and Water Solutions – https://na.itron.com/

Microsoft Entra Passkeys w Windows: nowe podejście do uwierzytelniania odpornego na phishing

Wprowadzenie do problemu / definicja

Microsoft rozszerza możliwości uwierzytelniania bezhasłowego w ekosystemie Entra, wprowadzając obsługę Entra passkeys na urządzeniach z Windows. To istotna zmiana dla organizacji, które chcą ograniczyć zależność od tradycyjnych haseł i jednocześnie objąć silniejszą ochroną scenariusze dostępu z urządzeń osobistych, współdzielonych oraz niezarządzanych.

Nowe rozwiązanie ma umożliwić logowanie odporne na phishing do zasobów chronionych przez Microsoft Entra także wtedy, gdy komputer nie jest przyłączony ani zarejestrowany w środowisku Entra. W praktyce oznacza to rozszerzenie modelu passwordless poza klasyczne, w pełni zarządzane stacje robocze.

W skrócie

Microsoft rozpoczął wdrażanie Entra passkeys na Windows pod koniec kwietnia 2026 roku, a pełną dostępność zapowiedziano do połowy czerwca 2026 roku. Mechanizm pozwala tworzyć klucze dostępu powiązane z konkretnym urządzeniem i przechowywane lokalnie w bezpiecznym kontenerze Windows Hello.

Uwierzytelnianie odbywa się z użyciem biometrii lub kodu PIN.
Rozwiązanie ma działać na urządzeniach firmowych, osobistych i współdzielonych.
Poświadczenia nie są przesyłane przez sieć w formie podatnej na przechwycenie.
Organizacja zachowuje kontrolę dzięki politykom Authentication Methods oraz Conditional Access.

Kontekst / historia

Od kilku lat sektor enterprise konsekwentnie odchodzi od haseł na rzecz modeli passwordless. Powód jest oczywisty: hasła nadal pozostają jednym z głównych wektorów ataku, zarówno w kampaniach phishingowych, jak i w scenariuszach credential stuffing, brute force czy wykorzystania danych uwierzytelniających po wcześniejszych wyciekach.

Microsoft od dawna rozwija ten kierunek poprzez Windows Hello for Business, FIDO2, MFA oraz funkcje związane z ochroną tożsamości w ramach Entra. Dotychczas jednak część scenariuszy, zwłaszcza w modelach BYOD i na urządzeniach współdzielonych, nadal wymuszała kompromis między wygodą a bezpieczeństwem. Entra passkeys na Windows mają ograniczyć ten problem, dostarczając silne uwierzytelnianie także poza standardowym profilem urządzenia korporacyjnego.

Analiza techniczna

Nowa funkcja opiera się na modelu FIDO2 i wykorzystuje lokalny kontener Windows Hello do przechowywania poświadczenia powiązanego z urządzeniem. Zamiast wspólnego sekretu, jakim jest hasło, wykorzystywana jest para kryptograficzna służąca do potwierdzenia tożsamości użytkownika. Sam proces logowania wymaga lokalnego odblokowania poświadczenia przy pomocy rozpoznawania twarzy, odcisku palca albo kodu PIN.

Kluczowa różnica względem Windows Hello for Business dotyczy zakresu zastosowania. Windows Hello for Business jest silnie związany z zaufaniem do urządzenia, logowaniem do systemu i scenariuszami single sign-on. Entra passkeys na Windows koncentrują się natomiast na uwierzytelnianiu wobec Microsoft Entra ID również wtedy, gdy urządzenie nie zostało wcześniej dołączone ani zarejestrowane w tenantcie.

Z perspektywy architektury bezpieczeństwa najważniejsze są cztery cechy tego modelu:

poświadczenie jest przypisane do konkretnego urządzenia,
jest przechowywane lokalnie i nie opuszcza hosta w formie podatnej na przejęcie,
aktywacja wymaga lokalnego czynnika użytkownika,
organizacja nadal może ograniczać dopuszczalne scenariusze logowania politykami dostępu.

W efekcie rozwiązanie zamyka istotną lukę w środowiskach mieszanych, gdzie dostęp do zasobów firmowych z komputerów niezarządzanych wcześniej często oznaczał konieczność pozostawienia haseł jako metody podstawowej lub awaryjnej.

Konsekwencje / ryzyko

Największą korzyścią jest ograniczenie ryzyka przejęcia kont przez phishing oraz ataki wykorzystujące skradzione dane logowania. Passkey nie jest sekretem wpisywanym do formularza, więc klasyczne techniki wyłudzania poświadczeń stają się znacznie mniej skuteczne. To szczególnie ważne w przypadku dostępu do usług SaaS i zasobów chronionych przez Entra.

Jednocześnie wdrożenie passkeys nie eliminuje wszystkich zagrożeń. Jeśli urządzenie końcowe zostanie skompromitowane, atakujący nadal może próbować przejąć aktywną sesję, wykorzystać tokeny dostępu lub nadużyć zaufanej stacji roboczej po zakończeniu procesu logowania. Oznacza to, że silniejsze uwierzytelnianie musi być uzupełnione ochroną endpointów, monitoringiem oraz analizą anomalii.

Ryzykiem pozostaje również błędna konfiguracja polityk. Zbyt szerokie dopuszczenie logowania z urządzeń osobistych lub współdzielonych bez odpowiednich warunków bezpieczeństwa może osłabić całościowy model kontroli dostępu, szczególnie w organizacjach działających pod presją wymogów regulacyjnych.

Rekomendacje

Organizacje planujące wdrożenie Entra passkeys na Windows powinny rozpocząć od kontrolowanego pilotażu obejmującego wybrane grupy użytkowników i precyzyjnie zdefiniowane scenariusze BYOD oraz shared device. Kluczowe jest powiązanie nowej metody logowania z Conditional Access, tak aby była dostępna wyłącznie tam, gdzie ryzyko zostało właściwie ocenione.

Warto również zaktualizować polityki Authentication Methods, procedury onboardingu oraz procesy helpdeskowe związane z rejestracją nowych poświadczeń, odzyskiwaniem dostępu i wymianą urządzeń. W praktyce wdrożenie powinno być traktowane jako element szerszej strategii ochrony tożsamości, a nie pojedyncza funkcja zastępująca wszystkie pozostałe zabezpieczenia.

uruchomić pilotaż dla wybranych użytkowników i aplikacji,
segmentować dostęp do systemów o podwyższonym ryzyku,
monitorować logowania z urządzeń niezarządzanych,
korelować zdarzenia Entra z danymi z EDR i SIEM,
utrzymywać silne kontrole sesji po uwierzytelnieniu,
szkolić użytkowników, że passkeys ograniczają phishing, ale nie chronią przed każdym skutkiem infekcji malware.

Dobrą praktyką będzie też porównanie roli Entra passkeys z już wdrożonym Windows Hello for Business. W wielu organizacjach oba mechanizmy będą się uzupełniać: pierwszy rozszerzy ochronę na scenariusze mniej zaufane, a drugi pozostanie podstawą logowania i uwierzytelniania na urządzeniach korporacyjnych.

Podsumowanie

Wprowadzenie Microsoft Entra passkeys na Windows to ważny krok w rozwoju uwierzytelniania bezhasłowego w środowiskach enterprise. Najistotniejszą zmianą jest możliwość objęcia odpornym na phishing logowaniem także tych urządzeń, które dotąd pozostawały poza pełnym modelem zarządzania Entra.

Dla zespołów bezpieczeństwa oznacza to szansę na realne ograniczenie ryzyka związanego z kradzieżą haseł i phishingiem, przy zachowaniu centralnej kontroli poprzez polityki metod uwierzytelniania i Conditional Access. Skuteczność wdrożenia będzie jednak zależała od właściwej segmentacji ryzyka, poprawnej konfiguracji oraz integracji nowego modelu z ochroną endpointów i monitoringiem sesji.

Źródła

Microsoft to roll out Entra passkeys on Windows in late April — https://www.bleepingcomputer.com/news/microsoft/microsoft-to-roll-out-entra-passkeys-on-windows-in-late-april/
Passkeys in Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2
Windows Hello for Business overview — https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/
FIDO Alliance – Passkeys — https://fidoalliance.org/passkeys/
Microsoft Secure Future Initiative — https://www.microsoft.com/en-us/security/business/secure-future-initiative

DORA i odporność operacyjna: zarządzanie poświadczeniami jako kluczowa kontrola ryzyka w sektorze finansowym

Wprowadzenie do problemu / definicja

Rozporządzenie DORA istotnie zmienia sposób, w jaki instytucje finansowe powinny patrzeć na bezpieczeństwo tożsamości oraz poświadczeń. Zarządzanie hasłami, kluczami, kontami uprzywilejowanymi i mechanizmami uwierzytelniania nie jest już wyłącznie domeną działów IT ani zbiorem dobrych praktyk cyberbezpieczeństwa. W realiach regulacyjnych Unii Europejskiej staje się formalnym elementem ograniczania ryzyka ICT, a tym samym ryzyka operacyjnego, biznesowego i zgodności.

W praktyce oznacza to, że kompromitacja poświadczeń może zostać potraktowana nie tylko jako incydent bezpieczeństwa, ale również jako zdarzenie wpływające na ciągłość działania podmiotu finansowego. To podnosi znaczenie kontroli dostępu do rangi mechanizmu nadzorczego.

W skrócie

DORA obowiązuje w Unii Europejskiej od 17 stycznia 2025 roku i nakłada na sektor finansowy obowiązki związane z ochroną, zapobieganiem oraz zarządzaniem ryzykiem ICT. Jednym z najważniejszych obszarów praktycznego wdrożenia pozostaje bezpieczeństwo poświadczeń, obejmujące silne uwierzytelnianie, zasadę najmniejszych uprawnień i ochronę zasobów kryptograficznych.

Przejęte konto może umożliwić atakującemu działanie pod wiarygodną tożsamością.
Ryzyko dotyczy nie tylko pracowników, ale także dostawców i partnerów zewnętrznych.
Zgodność z DORA wymaga nie tylko wdrożenia zabezpieczeń, ale też wykazania ich skuteczności.

Kontekst / historia

Atakujący od lat wykorzystują legalne konta użytkowników jako jeden z najprostszych sposobów wejścia do środowisk firmowych. W przeciwieństwie do klasycznych exploitów czy szkodliwego oprogramowania, skompromitowane dane logowania pozwalają poruszać się w infrastrukturze pod przykryciem poprawnej tożsamości. To utrudnia wykrycie incydentu, wydłuża czas obecności napastnika w sieci i zwiększa ryzyko eskalacji uprawnień.

DORA została zaprojektowana właśnie z myślą o odporności operacyjnej wobec takich zagrożeń. Regulacja wymaga od organizacji finansowych nie tylko tworzenia polityk, ale również praktycznej zdolności do ograniczania ryzyka związanego z dostępem logicznym do systemów, danych i procesów krytycznych.

Znaczenie tego problemu wzrosło wraz z popularnością kampanii phishingowych, infostealerów, brokerów initial access oraz nadużyć obejmujących środowiska dostawców zewnętrznych. Wspólnym mianownikiem wielu z tych scenariuszy pozostają właśnie poświadczenia.

Analiza techniczna

Z perspektywy technicznej i organizacyjnej kluczowe znaczenie ma osadzenie ochrony dostępu w szerszym modelu zarządzania ryzykiem ICT. W praktyce instytucje finansowe muszą ograniczać fizyczny i logiczny dostęp do zasobów wyłącznie do uzasadnionych i zatwierdzonych funkcji biznesowych. Oznacza to formalne wdrożenie zasady najmniejszych uprawnień, wraz z możliwością cyklicznej weryfikacji i odebrania dostępu.

Drugim filarem są silne mechanizmy uwierzytelniania. Samo hasło przestało być wystarczającą ochroną dla kont użytkowników i administratorów. Coraz większe znaczenie mają metody odporne na phishing pośredniczący, takie jak FIDO2, WebAuthn, passkeys czy klucze sprzętowe. Rozwiązania bazujące wyłącznie na SMS lub kodach TOTP nadal podnoszą bezpieczeństwo, jednak nie eliminują wszystkich współczesnych technik przejęcia sesji.

Typowy łańcuch kompromitacji poświadczeń wygląda podobnie w wielu incydentach. Najpierw dane logowania są pozyskiwane przez phishing, malware typu infostealer albo z wycieków danych. Następnie napastnik testuje je wobec usług zdalnego dostępu, poczty, VPN, paneli administracyjnych i aplikacji SaaS. Jeśli konto ma nadmierne uprawnienia, a organizacja nie stosuje segmentacji oraz kontroli sesji uprzywilejowanych, kolejnym krokiem może być ruch boczny, rozpoznanie środowiska i trwałe osadzenie się w infrastrukturze.

W tym kontekście szczególnego znaczenia nabierają systemy PAM, sejfy poświadczeń, rotacja haseł, konta JIT oraz pełne logi audytowe. Choć regulacje nie zawsze wskazują konkretne technologie z nazwy, właśnie takie rozwiązania najlepiej wspierają realizację wymagań dotyczących kontroli dostępu, rozliczalności i bezpieczeństwa uprzywilejowanych operacji.

Istotny pozostaje również aspekt dostawców zewnętrznych. Poświadczenia partnera, integratora lub operatora usługi mogą otworzyć drogę do systemów instytucji finansowej nawet wtedy, gdy jej własne środowisko jest relatywnie dobrze zabezpieczone. Dlatego kontrola tożsamości stron trzecich staje się częścią odporności operacyjnej, a nie wyłącznie klasycznym elementem zarządzania ryzykiem dostawców.

Konsekwencje / ryzyko

Największe zagrożenie związane z kompromitacją poświadczeń polega na tym, że incydent przez długi czas może wyglądać jak zwykła aktywność legalnego użytkownika. To przekłada się na późniejsze wykrycie, większą skalę naruszenia i wyższe koszty reakcji.

W sektorze finansowym skutki obejmują utratę poufności danych, ryzyko naruszenia integralności procesów biznesowych, zakłócenie działania usług oraz konieczność raportowania incydentów do właściwych organów. Z perspektywy DORA przejęte konto nie jest wyłącznie problemem IAM, ale potencjalnym naruszeniem odporności operacyjnej organizacji.

Jeżeli napastnik uzyska dostęp do systemów krytycznych, może wpływać na dostępność usług, procesy płatnicze, obsługę klientów, raportowanie lub zaplecze operacyjne. Im dłużej taki dostęp pozostaje niezauważony, tym większe prawdopodobieństwo równoczesnego kryzysu technicznego, zgodnościowego i reputacyjnego.

Dodatkowe ryzyko dotyczy łańcucha dostaw ICT. Słabe uwierzytelnianie po stronie dostawcy, brak MFA, niekontrolowane przechowywanie haseł czy opóźniony offboarding mogą przełożyć się bezpośrednio na ekspozycję danych oraz systemów instytucji finansowej.

Rekomendacje

Podmioty objęte DORA powinny traktować zarządzanie poświadczeniami jako odrębny program kontroli ryzyka, a nie jako zbiór rozproszonych ustawień w różnych systemach. Kluczowe działania obejmują zarówno warstwę techniczną, jak i organizacyjną.

Wymuszenie odpornych na phishing metod MFA, szczególnie dla administratorów, kont uprzywilejowanych, zdalnego dostępu i systemów krytycznych.
Wdrożenie zasady najmniejszych uprawnień w sposób mierzalny, z czasowymi dostępami uprzywilejowanymi i automatycznym wygaszaniem uprawnień.
Regularne przeglądy ról, eliminację kont osieroconych oraz natychmiastowe odbieranie dostępów po zakończeniu współpracy.
Przechowywanie haseł, kluczy API i sekretów aplikacyjnych w szyfrowanych repozytoriach z granularnym modelem uprawnień.
Całkowite wyeliminowanie przekazywania poświadczeń przez e-mail, komunikatory i pliki tekstowe.
Ciągłe monitorowanie użycia poświadczeń oraz integrację analityki logowań z SIEM, SOC lub innymi mechanizmami reagowania.
Budowanie warstwy dowodowej w postaci pełnych logów audytowych, historii zmian uprawnień i dokumentacji przeglądów dostępów.
Rozszerzenie tych samych standardów bezpieczeństwa na dostawców zewnętrznych i partnerów.

Podsumowanie

DORA podnosi zarządzanie poświadczeniami do rangi obowiązku z obszaru odporności operacyjnej. Dla sektora finansowego oznacza to konieczność traktowania haseł, MFA, kont uprzywilejowanych i sejfów poświadczeń jako mechanizmów kontroli ryzyka finansowego, operacyjnego i regulacyjnego jednocześnie.

Kompromitacja jednego konta może uruchomić łańcuch zdarzeń prowadzący do naruszenia danych, zakłócenia usług i obowiązków sprawozdawczych. Organizacje, które chcą ograniczyć to ryzyko, powinny połączyć silne uwierzytelnianie, zasadę najmniejszych uprawnień, centralne zarządzanie sekretami, monitoring i pełną ścieżkę audytową w jeden spójny model kontroli.

Źródła

CrowdStrike i Tenable łatają groźne luki w LogScale oraz Nessus

Wprowadzenie do problemu / definicja

Producenci rozwiązań bezpieczeństwa regularnie publikują poprawki usuwające błędy, które mogą prowadzić do przejęcia kontroli nad systemem, ujawnienia danych lub zakłócenia działania środowiska. Najnowsze komunikaty dotyczą dwóch istotnych podatności: krytycznej luki path traversal w CrowdStrike LogScale oraz podatności wysokiego ryzyka w Tenable Nessus i Nessus Agent dla systemów Windows.

Oba przypadki pokazują, że nawet narzędzia przeznaczone do ochrony infrastruktury same wymagają ścisłego nadzoru, szybkiego procesu aktualizacji i pełnego włączenia do programu zarządzania podatnościami.

W skrócie

CrowdStrike usunął krytyczną, nieuwierzytelnioną podatność CVE-2026-40050 w LogScale.
Luka mogła umożliwić zdalny odczyt dowolnych plików z systemu plików serwera.
Klienci korzystający z Next-Gen SIEM nie zostali objęci problemem, a ryzyko dla środowisk LogScale SaaS zostało ograniczone po stronie dostawcy.
Tenable opublikował poprawki dla CVE-2026-33694 w Nessus oraz Nessus Agent na Windows.
Podatność mogła pozwalać na usuwanie dowolnych plików z uprawnieniami SYSTEM, a w określonych warunkach także na eskalację uprawnień i wykonanie kodu.

Kontekst / historia

LogScale to platforma używana do centralizacji, przetwarzania i analizy logów, często wdrażana w architekturach SOC, SIEM oraz środowiskach telemetrycznych. Z uwagi na zakres gromadzonych danych i rolę operacyjną tego typu systemów, każda luka umożliwiająca dostęp do plików hosta ma bardzo wysoki potencjał wpływu na poufność i bezpieczeństwo całego środowiska.

Nessus pozostaje jednym z najczęściej wykorzystywanych skanerów podatności w przedsiębiorstwach. Narzędzie działa zwykle z wysokimi uprawnieniami, aby realizować lokalne kontrole bezpieczeństwa, audyt konfiguracji i ocenę hostów. To sprawia, że wszelkie błędy związane z obsługą plików i ścieżek mogą mieć szczególnie poważne konsekwencje, w tym prowadzić do lokalnej eskalacji uprawnień lub uszkodzenia systemu.

Choć path traversal i błędy związane z obsługą obiektów systemu plików w Windows należą do dobrze znanych klas podatności, nadal regularnie pojawiają się w praktyce. Wynika to z rozbudowanych wdrożeń, szerokich uprawnień procesów oraz złożoności kontroli integralności ścieżek i zasobów lokalnych.

Analiza techniczna

CVE-2026-40050 w CrowdStrike LogScale została opisana jako krytyczna, nieuwierzytelniona podatność path traversal. Tego rodzaju błąd pojawia się zwykle wtedy, gdy aplikacja niewystarczająco waliduje ścieżki przekazywane do komponentów obsługujących pliki. W efekcie atakujący może próbować uzyskać dostęp do zasobów znajdujących się poza dozwolonym katalogiem roboczym.

W przypadku platformy do analizy logów skutki takiej luki mogą być szczególnie poważne. Potencjalnie zagrożone są pliki konfiguracyjne, tokeny integracyjne, dane połączeń z usługami zewnętrznymi, lokalne sekrety aplikacyjne i inne artefakty operacyjne. Nawet jeśli podatność ogranicza się do odczytu, pozyskane informacje mogą umożliwić dalszą kompromitację środowiska.

Istotne znaczenie ma również fakt, że podatność określono jako nieuwierzytelnioną. Oznacza to, że potencjalny atak nie wymagał wcześniejszego logowania do aplikacji, co zwiększa ekspozycję instancji dostępnych z sieci.

Z kolei CVE-2026-33694 w Tenable Nessus dotyczy systemów Windows i mechanizmu junctions, czyli specjalnych obiektów systemu plików pozwalających przekierowywać operacje na inne lokalizacje. Jeśli aplikacja wykonująca działania z wysokimi uprawnieniami nie zabezpiecza poprawnie operacji na ścieżkach i obiektach pośrednich, lokalny użytkownik może wymusić działania na plikach spoza zakładanego obszaru roboczego.

W praktyce oznacza to możliwość doprowadzenia do usuwania dowolnych plików z uprawnieniami SYSTEM. W określonych scenariuszach taki problem może zostać wykorzystany również do lokalnej eskalacji uprawnień i uruchomienia kodu z wyższym poziomem dostępu. To szczególnie niebezpieczne w przypadku oprogramowania bezpieczeństwa instalowanego na ważnych hostach administracyjnych.

Konsekwencje / ryzyko

Dla użytkowników LogScale kluczowym zagrożeniem jest możliwość ujawnienia wrażliwych danych z serwera aplikacyjnego. W zależności od modelu wdrożenia mogą to być poświadczenia techniczne, dane konfiguracyjne, informacje o integracjach oraz metadane przydatne w dalszych etapach ataku. Jeśli instancja była wystawiona do internetu, luka mogła stanowić atrakcyjny wektor początkowego dostępu.

W przypadku Nessus i Nessus Agent ryzyko ma bardziej lokalny, ale nadal poważny charakter. Możliwość usuwania plików z uprawnieniami SYSTEM może prowadzić do destabilizacji systemu, uszkodzenia aplikacji lub przejęcia hosta przez lokalnego napastnika. W środowiskach wieloużytkownikowych lub tam, gdzie mniej uprzywilejowani użytkownicy mogą uruchamiać kod, zagrożenie to jest szczególnie istotne.

Warto pamiętać, że nawet brak publicznych doniesień o aktywnym wykorzystaniu nie oznacza braku realnego ryzyka. Po publikacji poprawek i komunikatów technicznych często pojawia się możliwość szybkiego odtworzenia logiki błędu i przygotowania skutecznych metod ataku.

Rekomendacje

Organizacje korzystające z CrowdStrike LogScale w modelu self-hosted powinny niezwłocznie wdrożyć wersję zawierającą poprawkę. Dodatkowo warto sprawdzić, czy instancja była dostępna z internetu, ograniczyć ekspozycję interfejsów administracyjnych oraz przeanalizować logi pod kątem nietypowych żądań wskazujących na próby odczytu nieautoryzowanych ścieżek.

Dobrym krokiem po stronie operacyjnej jest również weryfikacja, jakie sekrety mogły znajdować się na serwerze LogScale. W razie podejrzenia ujawnienia należy przeprowadzić rotację haseł technicznych, tokenów, kluczy API i innych poświadczeń przechowywanych lokalnie.

Użytkownicy Tenable Nessus i Nessus Agent na Windows powinni wdrożyć zalecane poprawki zgodnie z komunikatami producenta. Równolegle warto ograniczyć możliwość lokalnego logowania na hostach ze skanerem, monitorować operacje plikowe wykonywane przez procesy usługowe oraz stosować dodatkowe kontrole bezpieczeństwa na systemach administracyjnych.

Niezwłocznie aktualizować LogScale, Nessus i Nessus Agent.
Ograniczyć ekspozycję usług bezpieczeństwa do niezbędnych segmentów sieci.
Analizować logi pod kątem prób nadużyć i nietypowych operacji plikowych.
Rotować poświadczenia, jeśli istnieje ryzyko ich ujawnienia.
Uruchamiać narzędzia bezpieczeństwa na dedykowanych, utwardzonych hostach.

Podsumowanie

Najnowsze poprawki od CrowdStrike i Tenable dotyczą luk o istotnym znaczeniu operacyjnym. W jednym przypadku chodzi o zdalny, nieuwierzytelniony odczyt plików w LogScale, a w drugim o możliwość destrukcyjnych operacji plikowych i potencjalnej eskalacji uprawnień w Nessus na Windows.

To kolejny sygnał dla zespołów bezpieczeństwa, że platformy SIEM, skanery podatności i agenci bezpieczeństwa powinny być traktowane jak krytyczne komponenty infrastruktury. Szybkie aktualizacje, kontrola ekspozycji, przegląd logów oraz właściwe zarządzanie poświadczeniami pozostają podstawą ograniczania ryzyka.

Źródła

Kyber ransomware testuje kryptografię postkwantową w atakach na Windows i VMware ESXi

Wprowadzenie do problemu / definicja

Ransomware pozostaje jednym z najpoważniejszych zagrożeń dla środowisk korporacyjnych, zwłaszcza tam, gdzie równolegle działają serwery Windows i platformy wirtualizacyjne VMware ESXi. Najnowsze działania grupy Kyber pokazują dodatkowy trend: cyberprzestępcy zaczynają eksperymentować z mechanizmami określanymi jako postkwantowe, próbując wykorzystać je do ochrony kluczy szyfrujących i wzmocnienia presji psychologicznej na ofiary.

W praktyce nie oznacza to jeszcze rewolucji w samym modelu ataku, ale pokazuje rosnącą dojrzałość techniczną operatorów ransomware. Z perspektywy obrońców ważniejsze od samej terminologii jest to, że Kyber uderza jednocześnie w wiele warstw infrastruktury i celowo ogranicza możliwości odzyskania danych.

W skrócie

Kyber to operacja ransomware wymierzona w systemy Windows oraz hosty VMware ESXi. W analizowanych incydentach wykryto dwa warianty użyte równolegle w tej samej sieci: jeden do szyfrowania środowisk ESXi, drugi do ataku na serwery plików Windows.

Wariant dla Windows został napisany w Rust.
Do ochrony materiału kluczowego wykorzystuje Kyber1024.
Do szyfrowania danych stosuje AES-CTR.
Wariant dla ESXi nie realizuje faktycznego szyfrowania postkwantowego, mimo takich deklaracji.
Oba narzędzia mają maksymalizować skalę zakłóceń i utrudniać odzyskanie danych.

Kontekst / historia

Analiza incydentu przeprowadzona w marcu 2026 roku wykazała użycie dwóch odrębnych wariantów ransomware Kyber w ramach jednej kampanii operatorskiej. Obie próbki miały ten sam identyfikator kampanii i korzystały z tej samej infrastruktury wymuszeń, co wskazuje na działanie tego samego afilianta.

Taki model ataku dobrze wpisuje się w obecny krajobraz zagrożeń. Operatorzy ransomware coraz rzadziej ograniczają się do pojedynczych hostów, a zamiast tego równolegle atakują warstwę wirtualizacji, serwery aplikacyjne i repozytoria danych. Jednoczesne zaszyfrowanie maszyn wirtualnych oraz serwerów plików może sparaliżować całe środowisko produkcyjne i znacząco zwiększyć presję na organizację.

Istotny jest również wymiar marketingowy i psychologiczny. Odwołanie do kryptografii postkwantowej może budować wrażenie technologicznej przewagi sprawców, nawet jeśli realny wpływ na możliwość odzyskania danych pozostaje zbliżony do klasycznych schematów hybrydowych używanych wcześniej przez inne rodziny ransomware.

Analiza techniczna

Wariant przeznaczony dla VMware ESXi został zaprojektowany specjalnie pod kątem infrastruktury wirtualizacyjnej. Jego funkcje obejmują enumerację maszyn wirtualnych, szyfrowanie plików datastore, opcjonalne zatrzymywanie maszyn oraz modyfikację interfejsów zarządzających w celu wyświetlenia noty okupowej. To charakterystyczne dla nowoczesnych kampanii ransomware, które próbują uderzać bezpośrednio w warstwę hypervisora.

Mimo deklaracji o wykorzystaniu mechanizmów postkwantowych, wariant linuxowy dla ESXi nie używa Kyber1024 do faktycznej ochrony procesu szyfrowania plików. Z ustaleń analityków wynika, że próbka korzysta z ChaCha8 do szyfrowania danych oraz RSA-4096 do ochrony kluczy. Mechanizm ten został zoptymalizowany pod kątem wydajności: małe pliki szyfrowane są w całości, średnie częściowo, a duże obiekty mogą być szyfrowane przerywanie, zależnie od konfiguracji operatora.

Znacznie dojrzalej wygląda wariant dla Windows. Malware napisano w Rust, co wpisuje się w trend wykorzystywania nowoczesnych języków do tworzenia bardziej przenośnego i trudniejszego w analizie złośliwego oprogramowania. W tym wariancie Kyber1024 rzeczywiście służy do ochrony materiału kluczowego, natomiast właściwe szyfrowanie danych realizowane jest przez AES-CTR. Dodatkowo zastosowano X25519 jako element mechanizmu ochrony kluczy.

To ważne rozróżnienie: postkwantowy schemat nie szyfruje bezpośrednio zawartości plików, lecz zabezpiecza klucz symetryczny wykorzystywany przez szybki algorytm szyfrujący. Z technicznego punktu widzenia mamy więc do czynienia z modelem hybrydowym, w którym nowoczesny mechanizm KEM zastępuje bardziej tradycyjne podejścia oparte na RSA.

Wariant windowsowy zawiera również rozbudowane funkcje antyodzyskowe i antyforensyczne.

Dodaje nowe rozszerzenie do zaszyfrowanych plików.
Kończy działanie wybranych usług.
Usuwa kopie zapasowe i shadow copies.
Wyłącza mechanizmy naprawy rozruchu.
Zatrzymuje usługi związane z SQL Server, Exchange oraz rozwiązaniami backupowymi.
Czyści logi zdarzeń.
Opróżnia Kosz systemowy.
Zawiera eksperymentalną funkcję wyłączania maszyn wirtualnych Hyper-V.

Z perspektywy obrony szczególnie istotne jest to, że operatorzy próbują jednocześnie neutralizować wiele ścieżek odzyskania danych. Oznacza to, że standardowe procedury przywracania mogą okazać się niewystarczające, jeśli organizacja nie posiada odseparowanych i niemodyfikowalnych kopii zapasowych.

Konsekwencje / ryzyko

Najważniejszym skutkiem operacyjnym jest możliwość jednoczesnego uderzenia w dwa krytyczne obszary infrastruktury: hosty wirtualizacyjne ESXi oraz serwery Windows. Taki scenariusz oznacza ryzyko szerokiej niedostępności systemów, utraty dostępu do danych biznesowych, zatrzymania aplikacji oraz problemów z odtworzeniem usług.

Warto podkreślić, że użycie kryptografii postkwantowej nie zmienia praktycznej sytuacji ofiary. Jeżeli klucz prywatny pozostaje wyłącznie po stronie atakującego, odzyskanie danych bez jego pozyskania nadal jest nierealne. Dla organizacji różnica między RSA a Kyber1024 ma dziś znaczenie przede wszystkim techniczne i wizerunkowe, a nie operacyjne.

Dodatkowym ryzykiem jest wysoka skuteczność ataków na środowiska mieszane. Organizacje korzystające jednocześnie z VMware, Hyper-V, Windows Server, baz danych i platform pocztowych mają większą powierzchnię ataku, a ransomware wyposażone w funkcje wyłączania usług i maszyn wirtualnych może szybciej doprowadzić do pełnej przerwy operacyjnej.

Rekomendacje

Organizacje powinny traktować tego typu kampanie jako zagrożenie wielowarstwowe i wdrażać ochronę zarówno dla punktów końcowych, jak i dla warstwy wirtualizacji. Kluczowe znaczenie ma ograniczenie możliwości lateral movement, zabezpieczenie interfejsów administracyjnych oraz utrzymywanie niezależnych ścieżek odtworzenia danych.

Wdrożenie kopii zapasowych offline oraz niemodyfikowalnych backupów.
Segmentacja sieci między środowiskami użytkowników, serwerami plików, hostami ESXi i systemami backupowymi.
Ograniczenie uprawnień administracyjnych oraz stosowanie modelu least privilege.
Monitorowanie poleceń związanych z usuwaniem shadow copies, zatrzymywaniem usług i czyszczeniem logów.
Zabezpieczenie interfejsów zarządzających ESXi i Hyper-V przed bezpośrednim dostępem z sieci biurowej.
Stosowanie MFA dla kont uprzywilejowanych i dostępu zdalnego.
Regularne testy odtwarzania po awarii, obejmujące scenariusze utraty hostów wirtualizacyjnych.
Hardening systemów Windows Server, baz danych, Exchange oraz platform backupowych.
Centralizacja telemetrii z EDR, SIEM i warstwy hypervisora.
Szybkie izolowanie hostów wykazujących masowe operacje na plikach, zatrzymywanie usług lub nietypowe działania kryptograficzne.

W praktyce równie ważne jest przygotowanie procedur reagowania na incydenty dla ataku obejmującego wiele platform jednocześnie. Zespół bezpieczeństwa powinien dysponować gotowymi playbookami dla scenariuszy, w których ransomware uderza równolegle w serwery plików, hosty ESXi oraz infrastrukturę kopii zapasowych.

Podsumowanie

Kyber ransomware pokazuje, że operatorzy wymuszeń coraz chętniej eksperymentują z nowymi technikami i narracją wokół kryptografii postkwantowej. Najistotniejsze nie jest jednak samo użycie Kyber1024, lecz fakt, że atakujący prowadzą skoordynowane operacje przeciwko środowiskom Windows i VMware ESXi, jednocześnie niszcząc ścieżki odzyskiwania danych.

Dla obrońców oznacza to konieczność wzmacniania segmentacji, ochrony warstwy wirtualizacji, monitorowania działań antybackupowych oraz utrzymywania odseparowanych kopii zapasowych gotowych do szybkiego odtworzenia. To właśnie odporność operacyjna, a nie sama analiza użytej kryptografii, będzie miała kluczowe znaczenie w ograniczaniu skutków takich incydentów.

Źródła

BleepingComputer — Kyber ransomware gang toys with post-quantum encryption on Windows — https://www.bleepingcomputer.com/news/security/kyber-ransomware-gang-toys-with-post-quantum-encryption-on-windows/
Rapid7 — Analysis of Kyber ransomware variants — https://www.rapid7.com/
NIST — Post-Quantum Cryptography Standardization — https://www.nist.gov/pqcrypto

AVAST Antivirus 25.11: podatność Unquoted Service Path umożliwia lokalną eskalację uprawnień w Windows

Wprowadzenie do problemu / definicja

W AVAST Antivirus 25.11 opisano problem bezpieczeństwa związany z podatnością typu Unquoted Service Path w systemie Windows. Tego rodzaju błąd pojawia się wtedy, gdy ścieżka do pliku wykonywalnego usługi zawiera spacje, ale nie została poprawnie ujęta w cudzysłów. W efekcie system operacyjny może nieprawidłowo interpretować kolejne fragmenty ścieżki i próbować uruchomić inny plik niż zamierzony przez producenta.

Jeśli atakujący posiada lokalny dostęp do hosta i może zapisać odpowiednio nazwany plik wykonywalny w analizowanej lokalizacji, może doprowadzić do uruchomienia własnego kodu z uprawnieniami usługi. W praktyce oznacza to możliwość przejścia z poziomu zwykłego użytkownika do znacznie wyższego kontekstu bezpieczeństwa.

W skrócie

Zgłoszony przypadek dotyczy komponentu Avast SecureLine wchodzącego w skład AVAST Antivirus 25.11. Publiczny opis wskazuje na niecytowaną ścieżkę wykonywalną usługi działającej w środowisku Windows.

problem ma charakter lokalny i nie dotyczy zdalnego wykonania kodu,
usługa uruchamia się automatycznie,
proces działa z konta LocalSystem,
potencjalnym skutkiem jest eskalacja uprawnień do poziomu SYSTEM,
nie wskazano przypisanego identyfikatora CVE.

Kontekst / historia

Podatności wynikające z niecytowanych ścieżek usług Windows są znane od wielu lat i należą do klasycznych błędów konfiguracyjnych. Mimo dojrzałości platformy Windows oraz szerokiej wiedzy administratorów, problem nadal pojawia się w oprogramowaniu komercyjnym, narzędziach administracyjnych i dodatkowych komponentach instalowanych wraz z aplikacjami bezpieczeństwa.

W analizowanym przypadku opis dotyczy wersji 25.11 produktu AVAST Antivirus testowanej na Windows 11. Wskazano usługę Avast SecureLine, której ścieżka do binarki zawiera spacje i według publicznego opisu nie została prawidłowo objęta cudzysłowami. To szczególnie istotne, gdy usługa startuje automatycznie i działa z wysokimi uprawnieniami systemowymi.

Analiza techniczna

Mechanizm wykorzystania błędu wynika ze sposobu, w jaki Windows rozwiązuje ścieżki do plików wykonywalnych usług. Jeżeli ścieżka zawiera spacje i nie jest ujęta w cudzysłów, system może analizować ją etapami, traktując wcześniejsze segmenty jako potencjalne lokalizacje plików wykonywalnych.

Przykładowo ścieżka w rodzaju C:\Program Files\AVAST Software\SecureLine\VpnSvc.exe bez poprawnego cytowania może zostać zinterpretowana w sposób niezgodny z intencją producenta. Jeśli w jednej z rozpatrywanych lokalizacji znajdzie się złośliwy plik o odpowiedniej nazwie, system może uruchomić go zamiast właściwej binarki usługi.

W opisie podatności podkreślono, że usługa Avast SecureLine działa z konta LocalSystem. To kluczowy aspekt techniczny, ponieważ każda skuteczna podmiana lub przechwycenie ścieżki uruchomieniowej może doprowadzić do wykonania kodu z najwyższymi lokalnymi uprawnieniami w systemie Windows.

Aby atak zakończył się powodzeniem, napastnik musi zwykle spełnić kilka warunków operacyjnych:

uzyskać lokalny dostęp do systemu,
mieć możliwość zapisu do jednej z lokalizacji uwzględnianych przy rozwiązywaniu ścieżki,
umieścić odpowiednio nazwany plik wykonywalny,
doprowadzić do restartu usługi lub całego systemu.

Z tego względu nie jest to podatność służąca do bezpośredniego ataku zdalnego. Jej znaczenie rośnie jednak w scenariuszach po wstępnym naruszeniu hosta, kiedy atakujący szuka skutecznej metody podniesienia uprawnień.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest możliwość lokalnej eskalacji uprawnień do poziomu SYSTEM. W środowisku firmowym może to oznaczać pełne przejęcie stacji roboczej, wyłączenie części mechanizmów ochronnych, instalację złośliwego oprogramowania, utrwalenie obecności napastnika oraz przygotowanie gruntu pod dalszy ruch boczny w sieci.

Realne ryzyko wykorzystania zależy od lokalnej konfiguracji systemu i uprawnień do katalogów. Jeżeli użytkownik nieuprzywilejowany nie może zapisywać plików w newralgicznych lokalizacjach, a środowisko jest odpowiednio utwardzone, wykorzystanie błędu może być utrudnione. Mimo to sama obecność usługi działającej jako LocalSystem z nieprawidłowo zdefiniowaną ścieżką uruchomieniową powinna być traktowana jako istotny problem bezpieczeństwa.

zagrożone są przede wszystkim stacje robocze po wstępnym kompromitowaniu,
ryzyko rośnie w środowiskach z nadmiernymi uprawnieniami zapisu,
podatność może zostać użyta jako element większego łańcucha ataku,
skutki obejmują utratę integralności, poufności i kontroli nad hostem.

Rekomendacje

Organizacje korzystające z rozwiązań AVAST powinny przeprowadzić przegląd konfiguracji usług Windows pod kątem niecytowanych ścieżek binarnych. Warto przy tym potraktować problem szerzej i objąć audytem również inne aplikacje firm trzecich działające jako usługi systemowe.

zidentyfikować wszystkie usługi, których ścieżki zawierają spacje i nie są ujęte w cudzysłowie,
sprawdzić uprawnienia NTFS dla katalogów znajdujących się na drodze rozwiązywania ścieżki,
ograniczyć możliwość zapisu dla użytkowników standardowych w katalogach systemowych i aplikacyjnych,
monitorować tworzenie podejrzanych plików wykonywalnych w lokalizacjach pośrednich,
wdrożyć reguły EDR i SIEM wykrywające nietypowe uruchomienia usług oraz procesów z kontekstem SYSTEM,
zweryfikować dostępność poprawek producenta lub zmian konfiguracyjnych eliminujących problem,
uwzględnić audyt usług Windows w regularnych procedurach hardeningu.

Dobrą praktyką jest także przegląd usług uruchamianych automatycznie oraz kontrola, czy nie korzystają one z nadmiernych uprawnień. Ograniczenie powierzchni ataku na poziomie konfiguracji systemu często pozwala wyeliminować błędy, które w innym przypadku mogłyby zostać użyte do przejęcia hosta.

Podsumowanie

Przypadek AVAST Antivirus 25.11 pokazuje, że nawet oprogramowanie związane z bezpieczeństwem może zawierać klasyczne błędy wdrożeniowe prowadzące do lokalnej eskalacji uprawnień. Podatność typu Unquoted Service Path nie jest nową techniką, ale nadal pozostaje skutecznym wektorem nadużyć w systemach Windows, zwłaszcza gdy dotyczy usług uruchamianych automatycznie z konta LocalSystem.

Z perspektywy obrony kluczowe znaczenie ma szybka identyfikacja błędnie skonfigurowanych usług, weryfikacja uprawnień do katalogów oraz stałe monitorowanie anomalii związanych z uruchamianiem procesów o wysokich uprawnieniach. Nawet pozornie prosty błąd konfiguracyjny może stać się ważnym elementem skutecznego łańcucha ataku.

Źródła

Phishing znów dominuje w initial access w Q1 2026. AI przyspiesza tworzenie kampanii

Wprowadzenie do problemu / definicja

Phishing ponownie stał się najważniejszym wektorem uzyskiwania dostępu początkowego do środowisk organizacji. To technika oparta na socjotechnice, fałszywych stronach logowania i przechwytywaniu poświadczeń, której celem jest obejście zabezpieczeń oraz przejęcie kont użytkowników. W pierwszym kwartale 2026 roku zjawisko to zyskało dodatkowy impuls w postaci narzędzi AI, które upraszczają przygotowanie wiarygodnych kampanii.

Najważniejszy wniosek jest prosty: phishing nie tylko nie traci skuteczności, ale znów wyprzedza inne metody wejścia do organizacji. Dla zespołów bezpieczeństwa oznacza to konieczność ponownego skupienia uwagi na ochronie tożsamości, konfiguracji MFA oraz widoczności zdarzeń w całym środowisku.

W skrócie

W analizowanych incydentach z Q1 2026 phishing był najczęściej identyfikowaną metodą initial access. Odpowiadał za ponad jedną trzecią przypadków, w których udało się ustalić wektor wejścia. Szczególnie istotne jest to, że w części działań wykorzystano narzędzia AI do budowy stron wyłudzających poświadczenia.

Phishing wrócił na pierwsze miejsce wśród metod initial access.
Rosnąca rola AI obniża próg wejścia dla operatorów kampanii.
Problemy z MFA pozostają jedną z najczęstszych słabości obrony.
Nadal duże znaczenie mają podatne usługi internetowe i braki w logowaniu.
Najczęściej atakowanymi sektorami były administracja publiczna i ochrona zdrowia.

Kontekst / historia

W poprzednich kwartałach dominującym sposobem uzyskiwania dostępu bywało wykorzystywanie podatności w systemach wystawionych do internetu. Dotyczyło to zwłaszcza aplikacji korporacyjnych i usług utrzymywanych lokalnie, które stawały się celem masowej eksploatacji. W Q1 2026 widoczny był jednak powrót do klasycznego modelu ataku, w którym najważniejszą rolę znów odgrywa przejęcie danych logowania.

Zmiana ta nie oznacza, że ataki na podatne systemy przestały być groźne. Pokazuje raczej, że socjotechnika i kradzież poświadczeń nadal zapewniają atakującym bardzo wysoki zwrot przy relatywnie niskim koszcie operacyjnym. Gdy dodatkowo wsparcie zapewniają narzędzia automatyzujące budowę fałszywych stron, przygotowanie kampanii staje się szybsze i bardziej dostępne.

Raportowane incydenty częściej dotyczyły administracji publicznej i ochrony zdrowia. To sektory operujące na danych wrażliwych, często pod presją ciągłości działania i niekiedy na starszej infrastrukturze. Z punktu widzenia przeciwnika są więc atrakcyjnym celem zarówno dla działań nastawionych na zysk, jak i dla operacji o charakterze szpiegowskim.

Warto również odnotować, że udział incydentów typu pre-ransomware był niższy niż w pierwszej połowie 2025 roku. Nie należy jednak interpretować tego jako trwałego spadku zagrożenia ransomware, lecz raczej jako sygnał, że część kampanii mogła być skuteczniej wykrywana lub przerywana na wcześniejszych etapach.

Analiza techniczna

Jednym z najbardziej interesujących elementów trendu było wykorzystanie platformy Softr do stworzenia fałszywej strony logowania imitującej Microsoft Exchange oraz Outlook Web Access. To ważny sygnał dla obrońców, ponieważ pokazuje, że operator kampanii nie musi już samodzielnie przygotowywać kompletnego kodu strony, formularzy i mechanizmów zaplecza do zapisu danych.

W praktyce narzędzie AI może pomóc zbudować funkcjonalną stronę phishingową na podstawie krótkich poleceń. Dalej taka strona może zostać połączona z prostym backendem lub repozytorium danych, które automatycznie zapisuje przechwycone loginy i hasła. Dzięki temu cały proces tworzenia infrastruktury phishingowej staje się bardziej zautomatyzowany, szybszy i tańszy.

Technicznie szczególnie istotne jest zestawienie dwóch obserwacji: phishing był najczęściej wykrywanym wektorem initial access, a legalne konta stanowiły drugi z najczęstszych mechanizmów używanych w incydentach. Te dwa zjawiska są ze sobą bezpośrednio powiązane, ponieważ celem phishingu bardzo często jest właśnie zdobycie prawidłowych danych uwierzytelniających i wykorzystanie ich do logowania wyglądającego na zgodne z normalnym ruchem użytkownika.

Raport zwraca też uwagę na problemy związane z MFA. W części organizacji uwierzytelnianie wieloskładnikowe nie było włączone, w innych wdrożono je niepełnie albo z błędami. Atakujący potrafili obchodzić te mechanizmy między innymi przez rejestrację nowych urządzeń do wcześniej przejętych kont lub przez takie konfigurowanie klientów pocztowych, aby łączyły się bezpośrednio z serwerami Exchange poza standardowym przepływem logowania objętym MFA.

To bardzo ważna lekcja: samo włączenie MFA nie daje pełnej ochrony, jeśli organizacja nie kontroluje polityk dostępu, rejestracji urządzeń i wyjątków dla starszych protokołów lub klientów. Każda niespójność między polityką tożsamości a rzeczywistymi ścieżkami logowania może zostać wykorzystana jako obejście.

Dodatkowym problemem pozostają podatne lub nadmiernie eksponowane usługi internetowe oraz niedostateczne logowanie zdarzeń. Nawet gdy początkowe wejście następuje przez phishing, kolejne etapy ataku są ułatwiane przez otwarte interfejsy administracyjne, zbyt szerokie uprawnienia kont i brak centralnej telemetryki.

Konsekwencje / ryzyko

Powrót phishingu na pozycję dominującego wektora initial access zwiększa ryzyko prowadzenia masowych kampanii o niskim koszcie i dużej skali. Automatyzacja tworzenia stron phishingowych umożliwia szybkie generowanie kolejnych wariantów dopasowanych do konkretnych marek, portali logowania czy grup użytkowników.

Dla organizacji oznacza to większe prawdopodobieństwo skutecznego przejęcia kont, zwłaszcza tam, gdzie nadal występują luki w konfiguracji MFA, zbyt liberalne zasady rejestracji urządzeń lub brak segmentacji dostępu. Przejęte konto może zostać następnie wykorzystane do eskalacji uprawnień, dostępu do poczty, środowisk SaaS, usług chmurowych i danych wrażliwych.

Ryzyko operacyjne jest szczególnie wysokie w sektorach o niskiej tolerancji przestojów. W administracji publicznej i ochronie zdrowia kompromitacja tożsamości użytkownika może szybko przełożyć się na zakłócenie usług, wyciek informacji, nadużycia finansowe albo przygotowanie gruntu pod dalszy etap wymuszenia lub ransomware.

Z perspektywy strategicznej niepokoi także industrializacja phishingu. Nawet jeśli AI nie tworzy jeszcze całkowicie przełomowych technik, już dziś przyspiesza produkcję wiarygodnych przynęt i obniża wymagany poziom kompetencji technicznych. To zwiększa liczbę potencjalnych przeciwników zdolnych do prowadzenia skutecznych kampanii.

Rekomendacje

Organizacje powinny potraktować ochronę tożsamości jako jeden z głównych filarów cyberbezpieczeństwa. W pierwszej kolejności należy zweryfikować, czy MFA jest wymuszane dla wszystkich usług zdalnych, poczty, aplikacji SaaS i kont uprzywilejowanych. Równie ważne jest ograniczenie samodzielnej rejestracji nowych urządzeń oraz ścisła kontrola wyjątków od standardowych polityk logowania.

Wymusić MFA dla wszystkich krytycznych usług i kont uprzywilejowanych.
Ograniczyć lub centralnie zatwierdzać rejestrację nowych urządzeń.
Wyłączyć niepotrzebne starsze protokoły i niestandardowe ścieżki logowania.
Wdrożyć dostęp warunkowy oraz ocenę ryzyka logowania.
Monitorować nietypowe logowania z nowych lokalizacji, adresów IP i urządzeń.

Konieczne jest również dalsze wzmacnianie ochrony przed phishingiem. Obejmuje to filtrację poczty, detekcję stron wyłudzających poświadczenia oraz regularne szkolenia zwiększające świadomość użytkowników. Coraz większe znaczenie ma przy tym analiza zachowania po zalogowaniu, ponieważ użycie poprawnych poświadczeń często pozwala atakującemu ominąć klasyczne wskaźniki podejrzanego ruchu.

Nie mniej istotne pozostaje zarządzanie podatnościami i ograniczanie ekspozycji usług administracyjnych do internetu. Organizacje powinny szybko wdrażać poprawki, przeglądać zdalne interfejsy zarządzania i usuwać zbędnie wystawione usługi. Publicznie dostępna infrastruktura nadal stanowi bowiem ważny punkt zaczepienia dla napastników.

Z perspektywy wykrywania i reagowania kluczowa jest centralizacja logów w systemie SIEM lub równoważnej platformie telemetrycznej. Brak pełnych zapisów utrudnia odtworzenie przebiegu incydentu, potwierdzenie skali kompromitacji i ocenę, czy doszło do eksfiltracji danych.

Centralizować logi z poczty, systemów tożsamości, endpointów i usług chmurowych.
Wdrożyć monitoring anomalii logowania i aktywności po uwierzytelnieniu.
Stosować zasadę najmniejszych uprawnień dla kont użytkowników i serwisów.
Segmentować dostęp między użytkownikami, administracją i systemami krytycznymi.
Przygotować playbooki IR dla phishingu, przejęcia konta i obejścia MFA.

Podsumowanie

Pierwszy kwartał 2026 roku potwierdził, że phishing pozostaje jednym z najgroźniejszych i najbardziej opłacalnych sposobów uzyskiwania dostępu do organizacji. Kluczową zmianą jest rosnąca rola AI, która upraszcza budowę fałszywych stron logowania i przyspiesza przygotowanie kampanii.

W połączeniu z błędami we wdrożeniach MFA, podatną infrastrukturą internetową i brakami w logowaniu tworzy to środowisko sprzyjające skutecznym naruszeniom. Odporność na phishing zależy dziś nie tylko od świadomości użytkowników, ale przede wszystkim od jakości architektury tożsamości, egzekwowania polityk bezpieczeństwa oraz zdolności do szybkiego wykrywania i reagowania.

Źródła

Cisco Talos: IR Trends Q1 2026: Phishing reemerges as top initial access vector, as attacks targeting public administration persist — https://blog.talosintelligence.com/ir-trends-q1-2026/
Cybersecurity Dive: Phishing — sometimes with AI’s help — topped initial-access methods in Q1, Cisco says — https://www.cybersecuritydive.com/news/phishing-initial-access-ai-cisco/818185/