Archiwa: Firewall - Strona 5 z 22

Chińska grupa UNC6201 wykorzystuje zero-day w Dell RecoverPoint (CVE-2026-22769) od połowy 2024 r.

Wprowadzenie do problemu / definicja luki

W połowie lutego 2026 r. ujawniono, że podejrzewany o powiązania z Chinami klaster UNC6201 od co najmniej połowy 2024 r. wykorzystywał krytyczną lukę typu zero-day w Dell RecoverPoint for Virtual Machines (RP4VM) – rozwiązaniu do ochrony, replikacji i odtwarzania maszyn wirtualnych VMware.

Podatność otrzymała identyfikator CVE-2026-22769 i wynika z zastosowania twardo zakodowanych poświadczeń (hardcoded credentials). W praktyce oznacza to, że atakujący (po poznaniu stałego sekretu) może uzyskać nieautoryzowany dostęp do systemu operacyjnego urządzenia/appliance i utrwalić uprawnienia root.

W skrócie

Co? Hardcoded credentials w Dell RP4VM → potencjalny zdalny, nieautoryzowany dostęp i root persistence.
Kto? UNC6201 (chińsko-powiązany klaster śledzony przez Google/Mandiant).
Od kiedy? Wykorzystanie w atakach od mid-2024, ujawnienie publiczne: 2026-02-17/18.
Skutki? Instalacja backdoorów (m.in. BRICKSTORM, później GRIMBOLT), ruch boczny i długotrwała obecność w środowisku.
Co robić? Pilnie zaktualizować do 6.0.3.1 HF1 albo zastosować skrypt remediacyjny Dell oraz ograniczyć dostęp sieciowy do RP4VM.

Kontekst / historia / powiązania

Google Threat Intelligence Group oraz Mandiant opisują UNC6201 jako aktora wykorzystującego RP4VM do utrzymania dostępu i dalszej penetracji infrastruktury – w tym pivotowania do warstwy wirtualizacji. W raporcie zwrócono uwagę na powiązania/analogie do aktywności chińsko-nexusowych grup utrzymujących długi „dwell time” w sieciach ofiar.

Co istotne: podatność była eksploatowana „po cichu” przez wiele miesięcy, zanim trafiła do publicznych advisory (Dell opublikował DSA-2026-079 z datą 2026-02-17).

Analiza techniczna / szczegóły luki

1) Mechanizm podatności (CWE-798)

CVE-2026-22769 to przypadek CWE-798: Use of Hard-coded Credentials – w produkcie istnieje stałe poświadczenie/sekret, który (gdy zostanie poznany) umożliwia atakującemu dostęp w sposób niezgodny z modelem bezpieczeństwa. NVD wskazuje ocenę CVSS 10.0 (krytyczna) dostarczoną przez producenta (Dell).

2) Zakres podatnych wersji

Dotyczy Dell RecoverPoint for Virtual Machines w wersjach wcześniejszych niż 6.0.3.1 HF1. Dell w advisory opisuje ścieżki aktualizacji/remediacji także dla linii 5.3 (w tym zalecenie migracji/upgrade’u lub użycia skryptu naprawczego).

3) Wykorzystanie w kampanii i malware

W toku incydentów Mandiant znajdował na urządzeniach ślady BRICKSTORM, a następnie (od ok. września 2025) zastępowanie go bardziej zaawansowanym backdoorem GRIMBOLT. GRIMBOLT opisano jako narzędzie zapewniające zdalną powłokę; zwraca uwagę implementacja w C# i kompilacja Native AOT, co utrudnia analizę statyczną i bywa korzystne na „appliance’ach” o ograniczonych zasobach.

4) Utrzymanie dostępu (persistence) na appliance

Raport wskazuje m.in. nadużycie legalnych elementów systemu w celu przetrwania restartu – przykład: modyfikacja skryptu convert_hosts.sh, który jest wykonywany przy starcie przez rc.local. To klasyczny wzorzec „living off the land” na systemach linuksowych urządzeń brzegowych/backupowych.

5) Pivot do VMware i techniki „Ghost NICs”

Poza samym przejęciem appliance, obserwowano techniki ułatwiające ciche pivotowanie do infrastruktury wirtualnej, m.in. tworzenie „Ghost NICs” (tymczasowych interfejsów) oraz użycie iptables w scenariuszu Single Packet Authorization (SPA).

Praktyczne konsekwencje / ryzyko

Dlaczego to jest szczególnie groźne?

RP4VM ma wysokie uprawnienia i „widzi” krytyczną część środowiska: backup, replikacja, integracja z VMware – to idealny punkt do eskalacji i przetrwania.
Root persistence na urządzeniu backupowym to ryzyko zarówno dla poufności (eksfiltracja), jak i integralności (modyfikacja procesów odzyskiwania) oraz dostępności (sabotaż/„wiper”/utrudnienie DR). Opis skutków w advisory wprost mówi o nieautoryzowanym dostępie i utrwaleniu roota.
Długi czas niewykrycia (od połowy 2024 r.) zwiększa prawdopodobieństwo, że część środowisk mogła zostać skompromitowana przed wdrożeniem poprawek i zanim organizacje zaczęły aktywnie polować na IoC/TTP.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „od razu” (priorytet: ograniczyć ekspozycję, załatać, a potem sprawdzić, czy już nie jest za późno).

1) Patch/Remediacja – działania obowiązkowe

Zaktualizuj do 6.0.3.1 HF1 (preferowane) albo zastosuj oficjalny skrypt remediacyjny wskazany przez Dell.
Jeżeli jesteś na linii 5.3: postępuj zgodnie z zalecaną ścieżką migracji/upgrade’u lub remediacji wskazaną w DSA-2026-079.

2) Ogranicz dostęp sieciowy do RP4VM (minimalizacja powierzchni ataku)

Dell podkreśla, że RP4VM powinien działać w zaufanej, kontrolowanej sieci wewnętrznej z odpowiednią segmentacją i filtracją – nie jest przeznaczony do ekspozycji na sieci niezaufane/publiczne.
Checklist:

ACL/Firewall: dostęp administracyjny tylko z sieci zarządzającej / jump hostów.
Segmentacja: oddziel VLAN/segment dla appliance backup/DR.
Monitoring ruchu wychodzącego (egress): twarde reguły dozwolonych destynacji.

3) Threat hunting (co sprawdzać, gdy podejrzewasz kompromitację)

Na bazie opisanych TTP warto pilnie sprawdzić:

Nienaturalne żądania web/admin do appliance (w raporcie pojawiają się web requests z użyciem admin przed kompromitacją).
Zmiany w plikach/skryptach uruchamianych przy starcie, w szczególności ścieżki analogiczne do modyfikacji convert_hosts.sh i mechanizmów wykonywania przez rc.local.
Artefakty BRICKSTORM/GRIMBOLT i nietypowe połączenia C2 (Google opisuje wspólną infrastrukturę C2 dla obu rodzin).

4) Działania po naprawie

Po wdrożeniu poprawek: potraktuj appliance jak potencjalnie „dirty” i rozważ pełną weryfikację integralności (w skrajnych przypadkach – odtworzenie z zaufanego obrazu i ponowną konfigurację). To ważne, bo sama aktualizacja nie cofa persistence/backdoorów. (Wniosek oparty na typowym przebiegu IR dla appliance z root persistence, zgodny z opisanym celem atakujących).

Różnice / porównania z innymi przypadkami

Ten incydent wpisuje się w szerszy trend: ataki na „appliance” i komponenty infrastruktury (backup/DR, edge, virtualizacja), gdzie:

jeden błąd daje wysoki zwrot (uprzywilejowana pozycja w sieci),
detekcja jest trudniejsza (specyficzne systemy, rzadziej monitorowane),
a czas obecności atakującego bywa długi.

CVE-2026-22769 jest jednak szczególnie „brutalny” w naturze: to nie złożony błąd logiki, tylko hardcoded credential, czyli klasa problemów, której organizacje zwykle nie są w stanie zmitigować bez działań producenta (patch/remediation).

Podsumowanie / kluczowe wnioski

CVE-2026-22769 (Dell RecoverPoint for Virtual Machines) to krytyczna podatność hardcoded credentials, umożliwiająca nieautoryzowany dostęp i root-level persistence.
UNC6201 wykorzystywał ją jako zero-day od połowy 2024 r., instalując m.in. BRICKSTORM i nowszy GRIMBOLT, oraz wykorzystując appliance do dalszej penetracji środowisk VMware.
Najważniejsze działania: natychmiastowa aktualizacja do 6.0.3.1 HF1 / remediacja Dell + ograniczenie dostępu sieciowego + hunting pod persistence/backdoory.

Źródła / bibliografia

Google Cloud Blog (GTIG/Mandiant): „UNC6201 Exploiting a Dell RecoverPoint for Virtual Machines Zero-Day” (Google Cloud)
Dell Security Advisory: DSA-2026-079 (RecoverPoint for Virtual Machines Hardcoded Credential Vulnerability) (Dell)
NVD (NIST): CVE-2026-22769 (NVD)
BleepingComputer: „Chinese hackers exploiting Dell zero-day flaw since mid-2024” (BleepingComputer)
SecurityWeek: „Dell RecoverPoint Zero-Day Exploited by Chinese Cyberespionage Group” (SecurityWeek)

Zatrzymanie w Polsce osoby powiązanej z Phobos: co mówi CBZC i dlaczego to ważne dla obrony przed RaaS

Wprowadzenie do problemu / definicja luki

Zatrzymanie osoby powiązanej z Phobos nie jest „tylko” newsowym epizodem z kategorii cybercrime. To sygnał, że organy ścigania coraz częściej uderzają nie wyłącznie w „głośne” grupy ransomware, ale także w zaplecze usługowe i afiliantów – czyli osoby dostarczające narzędzia, dostęp, dane uwierzytelniające lub infrastrukturę, bez których model Ransomware-as-a-Service (RaaS) nie działa.

W modelu RaaS twórcy/administratorzy udostępniają „platformę” ransomware (panel, builder, wsparcie, czasem hosting i leak-site), a afilianci wykonują włamania i uruchamiają szyfrowanie u ofiar, dzieląc się zyskami. Taki podział ról utrudnia przypisanie odpowiedzialności, ale zarazem daje policji więcej „punktów zaczepienia” – szczególnie, gdy uda się przejąć urządzenia z danymi operacyjnymi (loginy, hasła, ślady komunikacji, listy hostów).

W skrócie

17 lutego 2026 r. CBZC poinformowało o zatrzymaniu 47-letniego mężczyzny w woj. małopolskim w działaniach prowadzonych przez zarządy CBZC w Katowicach i Kielcach. (
Na zabezpieczonych urządzeniach znaleziono m.in. loginy, hasła, numery kart płatniczych oraz adresy IP serwerów – dane potencjalnie użyteczne do dalszych włamań i ataków (w tym ransomware).
Według CBZC mężczyzna kontaktował się (przez szyfrowane komunikatory) z grupą Phobos.
Usłyszał zarzuty m.in. z art. 269b § 1 kk; śledztwo nadzoruje Prokuratura Okręgowa w Gliwicach, a maksymalna kara wskazana w komunikacie to do 5 lat pozbawienia wolności.
Zatrzymanie powiązano z udziałem CBZC w operacji Aether koordynowanej przez Europol.

Kontekst / historia / powiązania

Phobos działa od kilku lat jako jeden z najbardziej „produkcyjnych” ekosystemów ransomware: według komunikacji organów USA i działań międzynarodowych, kampanie przypisywane Phobos/połączonym podmiotom miały dotknąć ponad 1000 ofiar na świecie, a suma okupów miała przekroczyć 16 mln USD.

Ważny jest też kontekst presji międzynarodowej z 2024–2025:

w lutym 2025 r. informowano o skoordynowanych zatrzymaniach i przejęciach infrastruktury w sprawach powiązanych z Phobos/8Base;
wątek „rozbijania” sieci obejmuje zarówno operatorów/afiliantów, jak i elementy infrastruktury oraz osoby odpowiedzialne za utrzymanie i monetyzację ekosystemu.

Na tym tle polska realizacja z lutego 2026 wpisuje się w trend: uderzenie w komponent umożliwiający ataki (narzędzia, dane dostępowe, komunikacja), nawet jeśli nie ujawniono, by zatrzymany osobiście uruchamiał szyfrowanie u ofiar.

Analiza techniczna / szczegóły luki

Co jest „techniką” w tej sprawie?

Komunikat CBZC jest istotny z technicznego punktu widzenia, bo wskazuje na artefakty typowe dla etapów Initial Access / Credential Access / Discovery w łańcuchu ransomware:

zbiory poświadczeń (loginy/hasła) – często pochodzące z infostealerów, wycieków lub credential stuffing;
dane kartowe – mogą świadczyć o dodatkowej monetyzacji (fraud) albo o gromadzeniu danych z kompromitacji;
adresy IP serwerów – praktycznie: lista celów lub infrastruktury (C2, VPS-y, bramki), ewentualnie inwentarz już przejętych hostów.

Jak typowo działa ekosystem Phobos (RaaS) – warstwa TTP

W analizach bazujących na publicznie opisywanych zachowaniach Phobos (w tym odniesieniach do wspólnych advisory) powtarzają się następujące elementy:

Initial access: phishing oraz ataki siłowe/brute-force na wystawione usługi zdalnego dostępu (szczególnie RDP) i użycie przejętych kont;
post-exploitation: instalacja narzędzi zdalnego dostępu dla utrzymania dostępu; rozpoznanie środowiska;
narzędzia spotykane w kampaniach: m.in. BloodHound (AD), Cobalt Strike, SmokeLoader;
impact: usuwanie kopii zapasowych (np. Shadow Copies), wyłączanie mechanizmów obrony, a finalnie szyfrowanie zasobów i wymuszenie okupu.

Warto podkreślić: w tej polskiej sprawie nie opublikowano TTP z konkretnego incydentu u ofiary (np. logów, IOCs, czasu wejścia), ale sam zestaw danych zabezpieczonych na urządzeniach pasuje do „pracy afilianta” lub kogoś z łańcucha dostępu.

Praktyczne konsekwencje / ryzyko

Ryzyko dla MŚP i samorządów: Phobos historycznie bywa łączony z atakami o relatywnie „niższych” żądaniach okupu, ale na dużą skalę – co czyni go realnym zagrożeniem dla organizacji z ograniczonym SOC i słabszym hardeningiem zdalnego dostępu.
Ryzyko „sprzedaży dostępu”: zestawy IP + loginy/hasła to klasyczny towar w modelu initial-access-brokering. Nawet jeśli jedna grupa zostaje osłabiona, te same dostępy mogą trafić do innych operatorów ransomware.
Ryzyko łańcuchowe: dane kartowe i poświadczenia często oznaczają, że ktoś prowadził równolegle kilka strumieni cyberprzestępczych (fraud, infostealery, dostęp), co zwiększa szanse, że kompromitacja jednej organizacji „pociągnie” kolejne.

Rekomendacje operacyjne / co zrobić teraz

Jeżeli jesteś po stronie obrony (IT/SOC/administrator), potraktuj ten news jako checklistę priorytetów – szczególnie wokół zdalnego dostępu i tożsamości:

Zamknij ekspozycję RDP/VPN: ogranicz dostęp do zdalnych usług wyłącznie przez VPN/ZTNA, z allowlistą adresów i geofencingiem tam, gdzie to możliwe.
MFA wszędzie, gdzie się da (zwłaszcza: poczta, VPN, panele administracyjne, RDP gateway).
Kontrola haseł i kont: wymuś długie hasła, wyłącz konta nieużywane, usuń lokalnych adminów „na stałe”, wdrażaj LAPS/privileged access management.
Wykrywanie i reakcja: alerty na brute-force/credential stuffing, nietypowe logowania, nowe usługi/zadania harmonogramu, próby kasowania Shadow Copies i wyłączania firewall/EDR.
Kopie zapasowe: reguła 3-2-1 + testy odtworzeniowe; izoluj backup od domeny/produkcyjnego AD.
Higiena dostawców i zdalnych narzędzi: jeśli używasz zdalnych narzędzi wsparcia, ogranicz je politykami, loguj i monitoruj.

Te działania nie „załatwiają” problemu ransomware w 100%, ale znacząco podnoszą koszt wejścia – a w modelu RaaS koszt/opłacalność to często czynnik decydujący.

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

W porównaniu do spektakularnych „takedownów” infrastruktury lub zatrzymań liderów, polska realizacja wygląda jak klasyczne uderzenie w warstwę enablement:

nie ma informacji o przejęciu leak-site czy masowej infrastrukturze,
za to są bardzo konkretne dowody w postaci danych dostępowych, narzędzi i komunikacji, które w sądzie mogą lepiej „spiąć” udział w procederze.

To podejście jest spójne z międzynarodową strategią z 2024–2025: rozszczelnianie modelu RaaS przez identyfikację i neutralizację ról pomocniczych (afilianci, brokerzy dostępu, operatorzy usług).

Podsumowanie / kluczowe wnioski

Zatrzymanie z 17 lutego 2026 r. pokazuje, że ściganie ransomware wchodzi na poziom „operacyjnych trybików” ekosystemu – a nie tylko medialnych liderów.
Z perspektywy obrony, najbardziej „praktyczna” lekcja brzmi: poświadczenia + zdalny dostęp nadal są paliwem ransomware.
Nawet jeśli jedna grupa (lub jej afilianci) zostaje osłabiona, rynek RaaS jest płynny – dlatego kluczowe są: MFA, hardening zdalnego dostępu, monitoring anomalii i odporne kopie zapasowe.

Źródła / bibliografia

Komunikat CBZC: „47-latek związany z grupą Phobos zatrzymany przez policjantów CBZC” (17.02.2026). (cbzc.policja.gov.pl)
SecurityWeek: „Man Linked to Phobos Ransomware Arrested in Poland” (17.02.2026). (SecurityWeek)
U.S. Department of Justice: „Phobos Ransomware Affiliates Arrested in Coordinated International Disruption” (10.02.2025). (Department of Justice)
Reuters: „Four Russians arrested in Phobos ransomware crackdown, Europol says” (11.02.2025). (Reuters)
Picus Security (opracowanie TTP w oparciu o publiczne advisory): „Phobos Ransomware Analysis, Simulation and Mitigation – CISA Alert AA24-060A” (01.03.2024). (picussecurity.com)

Washington Hotel w Japonii ujawnia incydent ransomware: co wiemy i jak ograniczać ryzyko w branży hotelarskiej

Wprowadzenie do problemu / definicja luki

Ataki ransomware na sektor hospitality przestały być „okazjonalnym” incydentem – to dziś powtarzalny model biznesowy grup przestępczych: szybkie przejęcie środowiska IT (często przez słabości w dostępie zdalnym, phishing lub nadużycia kont), szyfrowanie systemów krytycznych oraz presja negocjacyjna związana z możliwym wyciekiem danych. Najnowszy przykład to ujawnienie incydentu przez japońską sieć Washington Hotel (WHG Hotels), która poinformowała o infekcji ransomware i nieautoryzowanym dostępie do części serwerów.

W skrócie

Kiedy wykryto atak: 13 lutego 2026, ok. 22:00 czasu lokalnego – wykryto nieautoryzowany dostęp i oznaki infekcji ransomware na części serwerów.
Reakcja: odcięcie serwerów od sieci zewnętrznej, powołanie sztabu kryzysowego, kontakt z policją i ekspertami zewnętrznymi.
Co mogło zostać naruszone: potwierdzono dostęp do „różnych danych biznesowych” na serwerach objętych incydentem; kwestia ewentualnego wycieku pozostaje w trakcie ustaleń.
Dane klientów: firma przekazała, że dane członków programu „Washington Net” są na serwerach zarządzanych przez podmiot zewnętrzny i nie potwierdzono tam nieautoryzowanego dostępu (na moment publikacji komunikatu).
Wpływ operacyjny: w części hoteli wystąpiły utrudnienia (m.in. czasowa niedostępność terminali kart płatniczych), ale bez „dużych” zakłóceń działalności.
Atrybucja: w chwili opisu sprawy nie było publicznego potwierdzenia, która grupa stoi za atakiem.

Kontekst / historia / powiązania

Washington Hotel działa w modelu sieci hoteli biznesowych (WHG Hotels) w Japonii, a incydent wpisuje się w szerszy trend wzmożonej presji cyberprzestępców na organizacje w regionie. Media branżowe odnotowują, że w ostatnim czasie atakowane były także inne japońskie firmy, choć nie oznacza to automatycznie wspólnego wektora czy sprawcy.

W tle pojawia się również wątek podatności aktywnie wykorzystywanej w Japonii: CVE-2026-25108 w Soliton Systems FileZen (OS command injection), gdzie japoński rejestr podatności (JVN/JVNDB) wskazuje, że zaobserwowano ataki wykorzystujące lukę. Nie ma dowodów, że ten konkretny wektor miał związek z Washington Hotel, ale warto go traktować jako sygnał o realnej aktywności ofensywnej wobec popularnych komponentów infrastruktury.

Analiza techniczna / szczegóły luki

Co wynika z komunikatu poszkodowanego

Z perspektywy IR (incident response) komunikat Washington Hotel jest dość typowy dla wczesnej fazy dochodzenia:

Detekcja nieautoryzowanego dostępu i infekcji ransomware na części serwerów.
Kontenerowanie poprzez odcięcie od sieci zewnętrznej (zwykle: internet/VPN/peeringi, czasem segmenty WAN).
Triaging z udziałem policji i ekspertów zewnętrznych (forensics, analiza logów, ustalenie skali naruszenia).
Wstępny zakres: potwierdzony dostęp do danych biznesowych na dotkniętych serwerach; wyciek – nadal weryfikowany.

Jak zwykle wygląda łańcuch ataku ransomware w środowisku hotelowym (model operacyjny)

Nawet bez ujawnionych IOC/TTP można wskazać najczęstsze punkty styku dla branży:

Dostęp początkowy: phishing (helpdesk/HR/finanse), nadużycie kont (hasło z wycieku + brak MFA), podatności w bramach zdalnego dostępu lub panelach administracyjnych, błędne konfiguracje.
Ruch boczny: enumeracja AD, zrzuty poświadczeń, wykorzystanie narzędzi administracyjnych (living-off-the-land), pivot do systemów operacyjnych i serwerów aplikacyjnych (PMS/CRM/ERP).
Wpływ: szyfrowanie zasobów, wyłączanie agentów bezpieczeństwa, niszczenie kopii zapasowych, często równolegle eksfiltracja danych do szantażu.

W tym incydencie szczególnie istotna jest deklarowana separacja danych programu członkowskiego („Washington Net”) na serwerach podmiotu zewnętrznego – to klasyczny przykład ograniczania „blast radius” przez segmentację/outsourcing, choć wymaga rygorystycznego zarządzania ryzykiem dostawcy (supplier risk).

Praktyczne konsekwencje / ryzyko

Ryzyko operacyjne (ciągłość działania): nawet częściowy paraliż systemów (np. terminale kart, recepcja, rozliczenia, systemy rezerwacji) szybko przekłada się na straty i chaos operacyjny – Washington Hotel potwierdził problemy z terminalami w części obiektów.
Ryzyko danych: potwierdzony dostęp do danych biznesowych oznacza co najmniej ryzyko ujawnienia informacji handlowych (umowy, rozliczenia, dane dostawców). Kwestia danych klientów jest „w trakcie” – na tym etapie kluczowe jest, czy doszło do eksfiltracji.
Ryzyko finansowe i prawne: organizacja wskazuje, że wpływ finansowy jest analizowany i mogą pojawić się dalsze komunikaty, jeśli zajdzie potrzeba ujawnień.
Ryzyko reputacyjne: w hospitality zaufanie jest krytyczne – nawet gdy dane klientów nie wyciekły, sam fakt ransomware zwiększa wrażliwość na odpływ rezerwacji i presję partnerów płatniczych.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „praktycznych”, typowych dla organizacji zbliżonej profilem do sieci hotelowej (wiele lokalizacji, rozproszone punkty sprzedaży, płatności, rezerwacje, integracje):

1) Pierwsze 72 godziny po wykryciu

Izolacja i kontrola rozprzestrzeniania: segmentacja, odcięcie kanałów administracyjnych, blokady kont uprzywilejowanych, rotacja kluczy/sekretów.
Forensics pod eksfiltrację: korelacja logów EDR/SIEM/Firewall/VPN, analiza ruchu wychodzącego, artefakty narzędzi do kradzieży danych.
Ochrona kopii zapasowych: fizyczna/logiczna separacja, „immutability”, test odtwarzania, zakaz łączenia backupów do potencjalnie skażonych domen.

2) Twarde kontrolki bezpieczeństwa (minimalny zestaw)

MFA wszędzie, gdzie się da (VPN, poczta, panele admin, narzędzia zdalne) + polityki odporne na MFA-fatigue (np. number matching).
Hardening AD: tiering, LAPS/Windows LAPS, ograniczenie RDP/WinRM, monitorowanie tworzenia usług/schedulerów, blokady narzędzi typu PsExec tam, gdzie zbędne.
EDR + izolacja hosta jako procedura: szybka kwarantanna stacji/serwerów z objawami szyfrowania.
Segmentacja płatności i POS: środowisko płatnicze traktować jak „strefę wysokiego ryzyka” (wymogi PCI DSS), minimalizować zależności z siecią biurową.

3) Zarządzanie ryzykiem dostawców

Skoro część danych jest po stronie podmiotu zewnętrznego, to trzeba regularnie egzekwować:

audyt dostawcy (SOC2/ISO 27001 lub ekwiwalent),
testy DR/BCP,
wymogi dot. logowania i retencji,
SLA na wsparcie IR i obowiązki notyfikacyjne.

4) Wnioski „na przyszłość”

Ćwiczenia tabletop ransomware dla recepcji/operacji/IT – bo w hotelach to nie tylko sprawa IT: to także płatności, obsługa gościa, komunikacja kryzysowa.
Minimalizacja zaufania między lokalizacjami (zero trust / least privilege): pojedynczy hotel jako punkt wejścia nie powinien umożliwiać przejęcia całej sieci.

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

Ten incydent wyróżnia się dwoma elementami, które często decydują o skali strat:

Szybkie odcięcie od sieci zewnętrznej – klasyczny, skuteczny krok na ograniczenie rozprzestrzeniania.
Separacja danych klientów (przynajmniej programu członkowskiego) od środowiska dotkniętego atakiem – potencjalnie ogranicza skutki naruszenia, o ile integracje i uprawnienia były dobrze zaprojektowane.

Jednocześnie fakt, że wystąpiły problemy z terminalami kart w części obiektów, pokazuje typową słabość branży: zależność od infrastruktury IT nawet w „prozaicznych” procesach obsługi gościa.

Podsumowanie / kluczowe wnioski

Washington Hotel potwierdził infekcję ransomware i dostęp do danych biznesowych; pełny zakres (w tym ewentualny wyciek) jest nadal badany.
Segmentacja i szybkie działania ograniczające (odcięcie od sieci, sztab, wsparcie ekspertów) to fundament ograniczania strat.
Branża hotelarska powinna traktować ransomware jako scenariusz „kiedy”, nie „czy”: priorytety to MFA, EDR, kopie niezmienialne, segmentacja POS/płatności i dojrzałe zarządzanie dostawcami.
Równolegle w Japonii obserwowane są ataki wykorzystujące podatności w popularnych produktach (np. FileZen / CVE-2026-25108), co wzmacnia potrzebę szybkiego patchowania i monitoringu ekspozycji.

Źródła / bibliografia

Komunikat Washington Hotel Corporation: „ランサムウェア感染被害のお知らせ” (2026/02/14). (ワシントンホテル〖公式〗総合サイト)
BleepingComputer: „Washington Hotel in Japan discloses ransomware infection incident” (Bill Toulas, 2026/02/16). (BleepingComputer)
JVNDB: informacja o FileZen i obserwowanych atakach (CVE-2026-25108). (jvndb.jvn.jp)
JVN (JVN84622767): FileZen OS command injection (koordynacja JPCERT/CC). (jvn.jp)
NVD: karta podatności CVE-2026-25108. (NVD)

Ninja Browser i Lumma Stealer: kampania malware nadużywająca Google Groups, Docs i Drive (luty 2026)

Wprowadzenie do problemu / definicja luki

CTM360 opisało szeroko zakrojoną kampanię, w której przestępcy „uzbrajają” zaufane usługi Google (Google Groups, Google Docs, Google Drive), aby przemycać linki do złośliwych plików i ominąć mechanizmy filtracji oparte na reputacji domen. Klucz jest prosty: użytkownik widzi „bezpieczny” ekosystem Google i obniża czujność, a organizacyjne zabezpieczenia często przepuszczają ruch do takich usług.

W tej operacji wykorzystano ponad 4 000 złośliwych grup Google oraz ponad 3 500 URL-i hostowanych w Google do dystrybucji dwóch rodzin zagrożeń:

Lumma Stealer (Windows) – infostealer kradnący dane uwierzytelniające i sesje,
Ninja Browser (Linux) – trojanizowana przeglądarka na bazie Chromium z mechanizmami trwałości i rozszerzeniami o złośliwej funkcjonalności.

W skrócie

Atak startuje od socjotechniki w Google Groups: posty udające realne wątki techniczne (problemy z siecią, błędy autentykacji, konfiguracje).
Linki prowadzą przez skracacze / przekierowania (Docs/Drive), które rozpoznają system operacyjny ofiary i podają inny ładunek dla Windows i Linux.
Na Windows: archiwum o ~950 MB po rozpakowaniu, w praktyce „napompowane” do omijania skanowania statycznego; uruchomienie prowadzi do rekonstrukcji i odpalenia payloadu Lumma m.in. przez komponenty AutoIt.
Na Linux: „Ninja Browser” instaluje po cichu rozszerzenia (np. NinjaBrowserMonetisation) oraz utrzymuje trwałość (harmonogramowane zadania, ciche aktualizacje).

Kontekst / historia / powiązania

Lumma Stealer (LummaC2) jest rozwijany i sprzedawany w modelu Malware-as-a-Service (MaaS) co zwiększa skalę i dostępność zagrożenia. MITRE klasyfikuje Lumma jako rodzinę infostealera używaną co najmniej od 2022 r. i opisuje jej typowe techniki (m.in. kradzież danych z przeglądarek, użycie AutoIt, komunikację po HTTP).

W 2024–2025 obserwowano wyraźny wzrost aktywności infostealerów, a ESET raportował silny wzrost detekcji Lumma (m.in. wskazując na różne wektory dostarczania – od phishingu po „sprytne” kampanie typu fake CAPTCHA).

Nowością w kampanii CTM360 jest szczególnie świadome wykorzystanie „zaufanej otoczki” Google jako infrastruktury dystrybucyjnej i „warstwy wiarygodności” dla linków.

Analiza techniczna / szczegóły luki

1. Etap 1 – wejście przez Google Groups (socjotechnika)

Atakujący publikują w grupach dyskusyjnych posty stylizowane na realne dyskusje IT. CTM360/BleepingComputer zwraca uwagę na dopasowywanie treści do branży i wplatanie nazw organizacji/keywordów, aby wyglądało to jak „wewnętrzny” problem lub rekomendowane narzędzie.

2. Etap 2 – przekierowania i selekcja systemu operacyjnego

Linki często idą przez:

skracacze URL,
przekierowania hostowane w Google (Docs/Drive),
które następnie serwują inny payload w zależności od OS (Windows vs Linux).

3. Windows – „napompowane” archiwum + łańcuch AutoIt → Lumma Stealer

Zaobserwowano mechanizm omijania skanerów: archiwum po rozpakowaniu ma ok. 950 MB, podczas gdy realny złośliwy komponent ma ok. 33 MB, a plik wykonywalny jest dopełniany „pustymi” bajtami (padding null bytes), co utrudnia skanowanie i analizę statyczną.

Dalej łańcuch obejmuje m.in. rekonstrukcję segmentów binarnych, uruchomienie komponentu kompilowanego w AutoIt i odszyfrowanie/wykonanie payloadu w pamięci. To jest spójne z obserwowanymi technikami Lumma opisywanymi także w ATT&CK.

Efekty działania (przykłady z obserwacji CTM360/BleepingComputer):

eksfiltracja haseł z przeglądarek,
kradzież cookies/sesji,
komendy powłoki,
POST-y HTTP do infrastruktury C2.

4. Linux – trojanizowany „Ninja Browser” (Chromium) + rozszerzenia + trwałość

„Ninja Browser” udaje przeglądarkę „privacy/anonymity”, ale:

instaluje złośliwe rozszerzenia bez zgody,
wdraża ukryte mechanizmy persistence.

Rozszerzenie NinjaBrowserMonetisation miało m.in. śledzić użytkownika, wstrzykiwać skrypty do sesji, manipulować kartami i cookies oraz ładować zdalną zawartość; kod JS był silnie obfuskowany (m.in. XOR / Base56-like).

Trwałość: wskazano na harmonogramowane zadania odpytywania serwerów atakującego, ciche aktualizacje i utrzymanie długoterminowego dostępu.

Praktyczne konsekwencje / ryzyko

Dla Windows (Lumma Stealer):

kradzież poświadczeń i tokenów sesyjnych → Account Takeover,
fraud finansowy,
wykorzystanie skradzionych danych jako „paliwa” dla IAB (Initial Access Brokers) i dalszych etapów (np. ransomware).

Dla Linux (Ninja Browser):

cicha kompromitacja przeglądarki i sesji webowych,
backdoor-like persistence oraz możliwość dogrywania funkcji/payloadów poprzez aktualizacje,
ryzyko przejęcia kont (SSO, panele admina, chmura) przez kradzież cookies i danych uwierzytelniających.

Dla organizacji jako całości:

„zaufana” infrastruktura SaaS zwiększa skuteczność socjotechniki i omijanie filtrów URL,
większe prawdopodobieństwo, że incydent zacznie się od „niewinnego” kliknięcia w wątek dyskusyjny.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h):

Monitoring i blokady IoC (EDR/NDR/Firewall/Proxy) wg list CTM360: domeny, IP, hashe powiązane z kampanią.
Wprowadź detekcje na:
- nietypowe łańcuchy przekierowań z Docs/Drive,
- pobrania dużych archiwów „software” z wątków publicznych,
- tworzenie scheduled tasks na stacjach roboczych (Linux i Windows), zwłaszcza z podejrzanymi ścieżkami/argumentami.
Przegląd przeglądarek i rozszerzeń: audyt instalacji, wymuszanie allowlisty rozszerzeń (gdzie możliwe), detekcja nieautoryzowanych profili/przeglądarek.

Średni termin (1–4 tygodnie):

Polityka „download hygiene”: zakaz instalacji narzędzi z forów/publicznych dyskusji bez weryfikacji, plus proces zatwierdzania.
Wzmocnij ochronę tożsamości:
- reautoryzacja sesji, skrócenie TTL dla sesji administracyjnych,
- wymuszenie phishing-resistant MFA (FIDO2) tam, gdzie to realne. (To rekomendacja praktyczna; nie wynika wprost ze źródeł, ale adresuje ryzyko kradzieży cookies/sesji.)
Rozważ reguły DLP/UEBA pod kątem masowej eksfiltracji danych uwierzytelniających z przeglądarek oraz nietypowych POST-ów HTTP do świeżo rejestrowanych domen.

Różnice / porównania z innymi przypadkami

Klasyczne kampanie Lumma często bazują na fake CAPTCHA / ClickFix i nakłanianiu do wykonania komend (np. Win+R) – taki trend opisywały m.in. Netskope i ESET.
Kampania CTM360 wyróżnia się tym, że mocno stawia na weaponizację ekosystemu Google (Groups/Docs/Drive) oraz na dwutorowość OS (Windows: infostealer, Linux: trojanizowana przeglądarka z trwałością).

Podsumowanie / kluczowe wnioski

To nie jest „kolejny stealer” – to kampania dystrybucyjna na masową skalę, wykorzystująca reputację usług Google, co podbija skuteczność i utrudnia blokady.
Windows jest celem dla Lumma Stealer, a Linux dla Ninja Browser z rozszerzeniami i mechanizmami persistence – w praktyce organizacja musi bronić obu ścieżek.
Największą przewagą obrońców jest szybkie wdrożenie detekcji na redirect chain, audyt rozszerzeń oraz monitoring scheduled tasks + blokady IoC.

Źródła / bibliografia

CTM360 – “Ninja Browser & Lumma Infostealer (Delivered via Weaponized Google Services)” (ctm360.com)
BleepingComputer – “CTM360: Lumma Stealer and Ninja Browser malware campaign abusing Google Groups” (15 lutego 2026) (BleepingComputer)
MITRE ATT&CK – “Lumma Stealer (S1213)” (attack.mitre.org)
ESET – “Lumma Stealer: A fast-growing infostealer threat” (31 stycznia 2025) (ESET)
Netskope – “Lumma Stealer: Fake CAPTCHAs & New Techniques to Evade Detection” (23 stycznia 2025) (Netskope)

CONPET (Rumunia) potwierdza kradzież danych po ataku Qilin – co wiemy i jak ograniczyć ryzyko

Wprowadzenie do problemu / definicja luki

Incydent w CONPET S.A. (operator krajowego systemu przesyłu ropy i produktów ropopochodnych w Rumunii) to klasyczny przykład ransomware z elementami podwójnego wymuszenia: atakujący nie tylko zakłócają dostępność systemów (np. szyfrując zasoby lub wyłączając usługi), ale również eksfiltrują dane, by zwiększyć presję szantażu i ryzyko wtórnych nadużyć (phishing, oszustwa, kradzież tożsamości).

W tym przypadku CONPET podkreśla, że systemy OT/SCADA nie zostały naruszone, a transport ropy funkcjonował normalnie – uderzenie dotknęło głównie infrastrukturę IT biznesową i serwis WWW.

W skrócie

03.02.2026: CONPET wykrył atak na IT biznesowe; serwis spółki stał się niedostępny; zgłoszono sprawę do DIICOT i rozpoczęto współpracę z krajowymi organami cyberbezpieczeństwa.
05.02.2026: grupa ransomware Qilin publicznie przypisała sobie atak (wpis na leak site) i zadeklarowała kradzież danych.
12.02.2026: CONPET potwierdził, że doszło do eksfiltracji danych, choć zakres kradzieży nadal jest ustalany; napastnicy twierdzą, że wykradziono ok. ~1 TB dokumentów i opublikowali próbki (m.in. skany paszportów i dane finansowe).

Kontekst / historia / powiązania

Atak ma znaczenie nie tylko reputacyjne, ale i strategiczne: CONPET jest spółką kontrolowaną przez rumuńskie Ministerstwo Energii i obsługuje ok. 3 800 km rurociągów.

Z perspektywy trendów, Qilin to jedna z głośniejszych operacji ransomware (model RaaS), a incydent CONPET został odnotowany również w raportach threat-intel jako przykład uderzeń w sektor krytyczny (choć z utrzymaną ciągłością OT).

Analiza techniczna / szczegóły luki

Co potwierdzono oficjalnie

Naruszenie dotyczyło korporacyjnej infrastruktury IT (business IT).
OT (SCADA + telekomunikacja) nie ucierpiały, a transport ropy i gazoliny działał bez przerw.
CONPET współpracuje z rumuńskimi instytucjami cyber i organami ścigania; złożono zawiadomienie.

Co twierdzą sprawcy (Qilin) – element weryfikowany

Deklarowana kradzież ~1 TB danych oraz publikacja próbek (m.in. informacje finansowe i skany dokumentów).
W próbkach mają pojawiać się dane wrażliwe/PII, m.in. adresy, identyfikatory osobiste i numery rachunków.

Dlaczego „IT vs OT” jest tu kluczowe

Utrzymanie ciągłości OT nie oznacza braku ryzyka: w wielu organizacjach infrastruktura IT jest bramą do:

kradzieży danych (HR/finanse/kontrakty),
sabotażu procesów biznesowych,
ataków łańcuchowych (phishing, BEC),
przygotowania przyszłego pivotu w kierunku środowisk przemysłowych (jeśli segmentacja jest słaba).

W tym incydencie CONPET komunikuje, że segment OT pozostał nienaruszony – to dobra wiadomość operacyjnie, ale nie zamyka tematu ryzyk dla ludzi i danych.

Praktyczne konsekwencje / ryzyko

Najbardziej prawdopodobne skutki wtórne, jeśli wyciek obejmuje PII i dokumenty:

spear-phishing i oszustwa „na pilne polecenie” (podszycia pod pracowników/partnerów),
BEC/CEO fraud (fałszywe dyspozycje przelewów, zmiany numerów kont na fakturach),
kradzież tożsamości (szczególnie jeśli w próbkach faktycznie są skany dokumentów),
ryzyko regulacyjne i reputacyjne (obowiązki notyfikacyjne, roszczenia).

CONPET wprost ostrzega, że skradzione dane mogą posłużyć do oszustw i zaleca wzmożoną ostrożność wobec „pilnych” kontaktów telefonicznych/mailowych.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz”, sensowny dla organizacji po incydencie ransomware z podejrzeniem eksfiltracji:

Dla CONPET/organizacji o podobnym profilu (blue team / IR)

Potwierdzenie zakresu eksfiltracji: korelacja logów EDR/NDR, proxy, firewall, SSO/VPN; analiza nietypowych transferów i archiwizacji danych.
Reset i rotacja poświadczeń (priorytet: VPN, konta uprzywilejowane, serwisy plikowe, konta serwisowe) + wymuszenie MFA tam, gdzie to możliwe.
Twarde rozdzielenie IT/OT: przegląd reguł routingu, ACL, jump hostów, dostępu zdalnego i kont uprzywilejowanych (nawet jeśli OT „nie ruszone”).
Hunting pod TTP ransomware/RaaS: persistence, narzędzia zdalnego zarządzania, nietypowe harmonogramy zadań, tunelowanie, kompresja/archiwizacja danych.
Backupy i odtwarzanie: weryfikacja kopii offline/immutable, test odtworzeń (nie tylko „zielone” statusy).
Monitoring wycieku: obserwacja leak site, paste site, monitorowanie kredensów i dokumentów w obiegu przestępczym (zespół CTI lub zewnętrzny dostawca).

Dla osób potencjalnie dotkniętych (pracownicy/kontrahenci)

Nie reagować na presję czasu w mailach/telefonach; zawsze weryfikować innym kanałem (numer z oficjalnej strony, a nie z wiadomości).
Włączyć alerty transakcyjne w banku, rozważyć zmianę haseł (unikalne) i MFA tam, gdzie się da.
Zachować czujność na „aktualizacje danych”, „dopłaty”, „korekty faktur” – to typowy wektor po wyciekach.

Różnice / porównania z innymi przypadkami

Ten incydent dobrze pokazuje różnicę między:

zakłóceniem usług publicznych/IT (np. niedostępny serwis WWW, problemy z systemami biurowymi),
a
realnym wpływem na ciągłość OT/SCADA.

CONPET twierdzi, że OT działało normalnie (co ogranicza ryzyko fizycznego wpływu na przesył), ale potwierdzona eksfiltracja przenosi ciężar incydentu w stronę ryzyk danych i fraudów – czyli często najbardziej kosztownej fazy „po ransomware”.

Podsumowanie / kluczowe wnioski

Incydent CONPET to atak ransomware Qilin z potwierdzoną kradzieżą danych (zakres nadal ustalany).
Utrzymanie ciągłości OT/SCADA to ważny pozytyw, ale ryzyko nadużyć na danych (phishing, oszustwa finansowe) pozostaje wysokie.
Najważniejsze działania po stronie obrony to: szybkie zawężenie wektorów wejścia, rotacja poświadczeń, hunting i monitoring wycieku oraz twarda segmentacja IT/OT.

Źródła / bibliografia

BleepingComputer (12.02.2026) – potwierdzenie eksfiltracji danych, deklaracje Qilin o ~1 TB i próbki dokumentów. (BleepingComputer)
BleepingComputer (05.02.2026) – pierwsza informacja o incydencie, OT/SCADA bez wpływu, zgłoszenie do DIICOT. (BleepingComputer)
AGERPRES (04.02.2026) – komunikat prasowy CONPET o ataku z 03.02.2026, brak wpływu na SCADA i telekomunikację, zawiadomienie DIICOT. (AGERPRES)
The Record / Recorded Future News (06.02.2026) – kontekst, potwierdzenie niedostępności WWW i brak wpływu na OT; wzmianka o roszczeniach Qilin. (The Record from Recorded Future)
Check Point Research (09.02.2026) – odnotowanie incydentu w tygodniowym raporcie threat-intel. (Check Point Research)

ICS Patch Tuesday (luty 2026): Siemens, Schneider Electric, AVEVA i Phoenix Contact łatają luki w OT/ICS

Wprowadzenie do problemu / definicja luki

„ICS Patch Tuesday” to praktyka cyklicznego publikowania biuletynów bezpieczeństwa dla systemów przemysłowych (OT/ICS) — sterowników, stacji inżynierskich, HMI/SCADA, narzędzi do zarządzania siecią przemysłową czy komponentów telemetrycznych. W lutym 2026 r. zestaw nowych komunikatów opublikowały m.in. Siemens, Schneider Electric, AVEVA i Phoenix Contact. Wspólny mianownik: podatności mogą prowadzić do DoS, nieautoryzowanego dostępu, eskalacji uprawnień i w części przypadków nawet wykonania kodu — a więc scenariuszy bezpośrednio wpływających na ciągłość procesów przemysłowych.

W skrócie

Siemens: 8 nowych advisory dla m.in. Desigo CC, Sentron Powermanager, Simcenter (Femap/Nastran), NX, Sinec NMS, Solid Edge, Polarion; dodatkowo osobny biuletyn o braku mechanizmów hardeningu (ASLR/DEP/CFG itd.) w legacy kliencie SIPORT Desktop.
Schneider Electric: 2 kluczowe komunikaty z 10.02.2026:
- EcoStruxure Building Operation Workstation/WebStation – m.in. XXE i potencjalne wektory prowadzące do DoS/ujawnienia informacji/wykonania kodu (CVE-2026-1226, CVE-2026-1227).
- SCADAPack / RemoteConnect – błąd „improper check…” (CVE-2026-0667), oceniony jako krytyczny w ujęciu komunikatu SecurityWeek (DoS lub code execution).
AVEVA:
- PI Data Archive – DoS przez „uncaught exception” (CVE-2025-44019).
- PI to CONNECT Agent – wyciek wrażliwych danych do logów (proxy URL/credentials) przy określonych uprawnieniach (CVE-2026-1495).
Phoenix Contact: problem w OpenSSL (TLS 1.3) powodujący nieograniczony wzrost cache sesji i ryzyko resetu urządzeń przez wyczerpanie pamięci — dotyczy m.in. FL MGUARD 1102/1105 < 1.8.0 (CVE-2024-2511).

Kontekst / historia / powiązania

W OT realne ryzyko rzadko wynika wyłącznie z „jednej podatności”. Częściej to suma: starych komponentów, długich cykli patchowania, ekspozycji interfejsów (web/HMI), zaufania do segmentów sieciowych oraz zależności od bibliotek osób trzecich (np. OpenSSL). Przykładami są:

legacy aplikacje (VB6, brak nowoczesnych mitigacji) — Siemens wprost opisuje, że SIPORT Desktop nie implementuje ASLR/DEP/CFG/itp., przez co rośnie ryzyko nadużyć po uzyskaniu dostępu lokalnego.
podatności w bibliotekach kryptograficznych — w urządzeniach brzegowych i firewallach przemysłowych DoS na TLS potrafi przełożyć się na utratę łączności z obiektami.

Analiza techniczna / szczegóły luki

1) Siemens: „klasyczne” podatności + twarde ostrzeżenie o hardeningu SIPORT Desktop

SecurityWeek raportuje, że scenariusze obejmują m.in. nieautoryzowany dostęp, XSS, DoS, RCE oraz eskalację uprawnień w różnych produktach.
Najciekawszy (operacyjnie) jest jednak osobny biuletyn SSB-491780: to nie „CVE i patch”, tylko informacja o braku zabezpieczeń binariów (ASLR/DEP/Authenticode/SafeSEH/CFG). Siemens wskazuje, że problem ma charakter lokalny (post-exploitation/insider), a długoterminowo strategią jest migracja do web client, a nie „utwardzanie” thick clienta.

2) Schneider Electric: EBO Workstation/WebStation oraz SCADAPack/RemoteConnect

Schneider w portalu notyfikacji wskazuje dla EBO m.in. XXE (CWE-611) i generowanie kodu (CWE-94), przypisując CVE-2026-1226 i CVE-2026-1227 oraz konkretne zakresy wersji wymagające aktualizacji.
Druga pozycja z 10.02.2026 dotyczy SCADAPack 47x/47xi/57x oraz RemoteConnect i jest powiązana z CVE-2026-0667.

3) AVEVA: PI Data Archive (DoS) + PI to CONNECT Agent (wrażliwe dane w logach)

CVE-2025-44019: NVD i biuletyn AVEVA opisują błąd „uncaught exception”, który może umożliwić zatrzymanie wybranych subsystemów PI Data Archive i DoS (z możliwością utraty części danych z cache/snapshots w zależności od timingu awarii).
CVE-2026-1495: zgodnie z opisem (m.in. Tenable), przy uprawnieniach Event Log Reader możliwy jest odczyt szczegółów proxy (w tym potencjalnie poświadczeń) z logów PI to CONNECT, co stwarza ryzyko nieautoryzowanego dostępu do infrastruktury pośredniczącej.

4) Phoenix Contact: OpenSSL/TLS 1.3 i DoS przez cache sesji

CERT@VDE opisuje podatność OpenSSL w implementacji TLS 1.3, gdzie cache sesji może rosnąć bez ograniczeń, a atakujący zdalnie może doprowadzić do wyczerpania pamięci i rebootu urządzenia poprzez zestawianie wielu połączeń TLS do web interfejsu. Dotyczy m.in. FL MGUARD 1102/1105 z firmware < 1.8.0 (CVE-2024-2511).

Praktyczne konsekwencje / ryzyko

W środowiskach produkcyjnych skutki bywają bardziej „fizyczne” niż w IT:

DoS w PI Data Archive lub na urządzeniach brzegowych (FL MGUARD/SCADAPack) może skutkować utratą telemetrii, alarmów, danych procesowych, a w skrajnych przypadkach zatrzymaniem procesu lub przejściem w tryby awaryjne.
XXE / komponenty webowe (EBO WebStation/Workstation) zwiększają ryzyko naruszeń poufności i „pivotu” do innych segmentów (szczególnie, gdy BMS/OT jest słabo odseparowane).
Brak hardeningu legacy klienta (SIPORT Desktop) oznacza, że po wejściu na stację operatorską/engineering workstation przeciwnik może łatwiej utrzymywać się w systemie i nadużywać zaufanego kontekstu aplikacji.
Wrażliwe dane w logach (PI to CONNECT) to realny „credential exposure” w praktyce — często logi trafiają do centralnych kolektorów, gdzie dostęp ma szersza grupa.

Rekomendacje operacyjne / co zrobić teraz

Triaging i priorytetyzacja (24–72h)

Najpierw systemy „na styku” (zdalny dostęp, bramy, web management): SCADAPack/RemoteConnect, FL MGUARD, WebStation/Workstation.
Osobno potraktuj systemy danych procesowych (PI Data Archive) — DoS w historianie często ma najwyższy koszt operacyjny.

Ogranicz ekspozycję zanim spatchujesz

Phoenix Contact wprost rekomenduje maksymalne ograniczenie dostępu sieciowego do web interfejsu (ACL/segmentacja).
Dla SIPORT Desktop: segmentacja, reguły firewall na hostach, uruchamianie na kontach bez uprawnień admina, oraz kontrola integralności/EDR — to dokładnie ten typ mitigacji, który wskazuje Siemens.

Higiena logów i poświadczeń (PI to CONNECT)

Zweryfikuj, kto ma dostęp do logów (lokalnie i w SIEM/centralnym logowaniu).
Rotuj poświadczenia proxy, jeśli istniała możliwość ekspozycji; traktuj to jak potencjalny incydent „secrets leakage”.

Walidacja po wdrożeniu poprawek

Sprawdź, czy po aktualizacjach nie zmieniły się wymagania dot. certyfikatów/TLS, integracji (OT potrafi „paść” nie od ataku, tylko od zmiany wersji komponentu).
Zrób szybki test: zestawianie połączeń, failover, restart usług PI i weryfikacja buforowania danych.

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

„Patch i CVE” vs „architektura/legacy debt”: Siemens SSB-491780 jest dobrym przykładem komunikatu, gdzie nie ma prostego „załataj i zapomnij” — ryzyko wynika z ograniczeń technologii (VB6) i decyzji o migracji, więc trzeba podejść do tego jak do ryzyka rezydualnego w modelu zagrożeń.
DoS w OT ma inny ciężar: podatność OpenSSL/TLS cache (Phoenix Contact) i DoS w PI Data Archive pokazują, że nawet bez kradzieży danych atak może „wygrać” przez przerwanie dostępności.

Podsumowanie / kluczowe wnioski

Lutowy ICS Patch Tuesday (11 lutego 2026) domyka kilka istotnych klas ryzyk: webowe wektory w narzędziach operatorskich, DoS w krytycznych komponentach telemetrii/historian, nadużycia wynikające z długu technologicznego oraz problemy w zależnościach (OpenSSL). Najbardziej praktyczne podejście: szybko ograniczyć ekspozycję (segmentacja/ACL), spatchować komponenty brzegowe i webowe w pierwszej kolejności, a następnie dopiąć porządek w logach i poświadczeniach (PI to CONNECT).

Źródła / bibliografia

SecurityWeek – ICS Patch Tuesday: Vulnerabilities Addressed by Siemens, Schneider, Aveva, Phoenix Contact (11.02.2026). (SecurityWeek)
Siemens ProductCERT – SSB-491780: Missing anti-tamper protection in SIPORT Desktop Client Application (10.02.2026). (cert-portal.siemens.com)
Schneider Electric – Security Notifications (pozycje z 10.02.2026: SEVD-2026-041-01 / SEVD-2026-041-02). (Schneider Electric)
AVEVA – Security Bulletin AVEVA-2025-001: PI Data Archive – Denial of Service vulnerabilities + NVD CVE-2025-44019. (aveva.com)
CERT@VDE – Phoenix Contact: Unbounded growth of OpenSSL session cache in multiple FL MGUARD devices (CVE-2024-2511). (certvde.com)
Tenable – opis CVE-2026-1495 (PI to CONNECT Agent, wrażliwe dane w logach). (Tenable®)

Malicious 7-Zip: fałszywa strona 7zip[.]com rozsyła instalator z „proxyware” i robi z PC węzeł proxy

Wprowadzenie do problemu / definicja luki

W lutym 2026 badacze opisali kampanię, w której cyberprzestępcy podszywają się pod projekt 7-Zip i dystrybuują trojanizowany instalator. Na pierwszy rzut oka aplikacja działa poprawnie (użytkownik faktycznie dostaje 7-Zip), ale w tle instalują się dodatkowe komponenty, które rejestrują komputer jako „residential proxy node” – czyli węzeł w sieci pośredniczącej ruch.

To nie jest „klasyczny wirus” nastawiony na natychmiastowe szyfrowanie plików – to cicha monetyzacja zasobów i reputacji Twojego adresu IP.

W skrócie

Fałszywa domena 7zip[.]com imituje wygląd i treść oryginalnej strony 7-Zip (prawidłowa to 7-zip.org).
Instalator jest podpisany cyfrowo certyfikatem (opisanym jako później cofnięty), co zwiększa wiarygodność w oczach użytkownika.
Malware dropuje pliki m.in. Uphero.exe, hero.exe, hero.dll, tworzy usługę Windows (SYSTEM) i modyfikuje reguły zapory.
Celem jest proxyware: ruch osób trzecich idzie „przez” komputer ofiary, często na nietypowych portach (np. 1000/1002) i z rotującą infrastrukturą C2.

Kontekst / historia / powiązania

Sprawa wyszła szerzej na jaw po relacji użytkownika, który pobrał „7-Zip” z błędnej strony, idąc za linkiem podanym w kontekście poradnika YouTube dotyczącego składania PC. To pokazuje, jak łatwo atakujący wykorzystują łańcuch zaufania: tutorial, komentarz, link, szybkie pobranie „popularnego narzędzia”.

Warto zauważyć, że podszywanie się pod legalne oprogramowanie i nazewnictwo to klasyczny wzorzec „masquerading” opisywany także w MITRE ATT&CK (dopasowanie nazwy/lokalizacji zasobu do legalnego).

Analiza techniczna / szczegóły luki

1) Warstwa „legit” – żeby ofiara niczego nie zauważyła

Trojanizowany instalator zawiera działający 7-Zip, więc użytkownik widzi oczekiwany efekt i często kończy na tym weryfikację.

2) Dropper i komponenty proxy

W trakcie instalacji zapisywane są dodatkowe pliki (w analizie Malwarebytes/BleepingComputer wskazywane jako):

Uphero.exe – menedżer usługi / loader aktualizacji
hero.exe – główny payload proxy
hero.dll – biblioteka wspierająca
Wskazywana ścieżka: C:\Windows\SysWOW64\hero\ (lokalizacja, której użytkownicy zwykle nie przeglądają ręcznie).

3) Persistencja: usługa Windows na uprawnieniach SYSTEM

Malware tworzy autostartową usługę Windows i uruchamia się z wysokimi uprawnieniami, co utrudnia wykrycie oraz usunięcie „na oko”.

4) Zmiany w zaporze i komunikacja

W opisie kampanii pojawiają się:

modyfikacje reguł zapory przez netsh (inbound/outbound),
pobieranie konfiguracji z rotujących domen „smshero”,
komunikacja na nietypowych portach (np. 1000, 1002) i lekkie zaciemnianie komunikatów (XOR).

5) Profilowanie hosta i telemetria

Wskazano profilowanie systemu przez WMI/API Windows (sprzęt, pamięć, dysk, sieć) oraz wysyłkę danych do zewnętrznego endpointu.

6) Szersza operacja

Badacze łączą tę kampanię z innymi „przynętami” (trojanizowane instalatory podszywające się pod różne aplikacje), co sugeruje powtarzalny pipeline dystrybucyjny i monetyzację infrastruktury proxy na większą skalę.

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla użytkownika i organizacji:

Reputacyjne i prawne: ruch przestępców może wychodzić „Twoim” IP (nadużycia, fraud, próby logowania, spam). To Ty możesz zostać pierwszym podejrzanym w logach usług.
Ryzyko eskalacji: proxyware bywa elementem większego łańcucha – dziś „tylko” węzeł, jutro doinstalowanie kolejnych komponentów (loader/aktualizacje).
Trudniejsze wykrycie: bo 7-Zip działa, a usługa w systemie wygląda jak „coś od narzędzia”. To dokładnie mechanika masquerading.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (endpoint)

Natychmiastowa weryfikacja źródła: 7-Zip pobieraj wyłącznie z 7-zip.org, a nie z domen „podobnych”.
Jeśli uruchomiłeś instalator z 7zip[.]com: traktuj system jako skompromitowany (takie ostrzeżenie pada w omówieniu sprawy).
Sprawdź:
- obecność katalogu C:\Windows\SysWOW64\hero\ oraz plików Uphero.exe/hero.exe/hero.dll,
- usługi Windows uruchamiane automatycznie jako SYSTEM,
- nietypowe reguły zapory dodane narzędziami systemowymi (np. ślady użycia netsh).
Wykonaj pełne skanowanie EDR/AV i rozważ reinstalację/odtworzenie z zaufanego obrazu, jeśli potwierdzisz infekcję (proxyware często jest projektowane tak, by utrzymać się długo).

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

Monitoruj tworzenie nowych usług i zmiany w regułach Windows Firewall (szczególnie na stacjach użytkowników).
Wykrywaj ruch na nietypowych portach i wzorce „proxy-like” (utrzymujące się połączenia wychodzące, rotacja domen, TLS/HTTPS do nietypowych hostów).
Edukuj: „pobieraj z oficjalnej domeny, bookmarkuj, nie ufaj linkom z tutoriali/komentarzy”.

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

Proxyware vs ransomware/stealer: tu monetyzacja nie polega na natychmiastowej kradzieży danych lub szyfrowaniu, tylko na „wynajęciu” Twojego IP/łącza. To sprawia, że incydent jest często później wykrywany (brak oczywistych objawów).
Lookalike domain + działająca aplikacja to szczególnie groźne połączenie: użytkownik ma „dowód”, że pobrał właściwe narzędzie, bo ono realnie działa.

Podsumowanie / kluczowe wnioski

Fałszywa strona 7zip[.]com to przykład skutecznej kampanii opartej o podszywanie się pod markę i minimalny „szum” na hoście. Instalator dostarcza prawdziwy 7-Zip, a równolegle wdraża proxyware (Uphero/hero), tworzy usługę SYSTEM i przygotowuje host do routowania ruchu osób trzecich.

Jeśli w Twoim środowisku ktoś pobrał 7-Zip z niewłaściwej domeny, potraktuj to jako incydent bezpieczeństwa: zidentyfikuj artefakty, sprawdź usługi, reguły firewall i ruch sieciowy oraz podejmij działania naprawcze.

Źródła / bibliografia

BleepingComputer – „Malicious 7-Zip site distributes installer laced with proxy tool” (10 lutego 2026). (BleepingComputer)
Malwarebytes Threat Intel – „Fake 7-Zip downloads are turning home PCs into proxy nodes” (9 lutego 2026). (Malwarebytes)
Help Net Security – omówienie ostrzeżeń Malwarebytes i kontekstu dystrybucji przez tutoriale (10 lutego 2026). (Help Net Security)
MITRE ATT&CK – Masquerading: Match Legitimate Resource Name or Location (T1036.005). (attack.mitre.org)