Archiwa: Cybersecurity - Strona 13 z 24 - Security Bez Tabu

Tag: Cybersecurity

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

Wprowadzenie do problemu / definicja luki

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

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

W skrócie

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

Kontekst / historia / powiązania

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

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

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

Analiza techniczna / szczegóły luki

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

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

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

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

Praktyczne konsekwencje / ryzyko

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

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

Rekomendacje operacyjne / co zrobić teraz

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

1) Natychmiastowe kroki IR (0–72h)

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

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

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

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

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

4) Utwardzenie po incydencie (2–8 tygodni)

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

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

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

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

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

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

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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

Biały Dom wycofuje „uciążliwe” zasady bezpieczeństwa oprogramowania: co oznacza memorandum OMB M-26-05 dla łańcucha dostaw IT

Wprowadzenie do problemu / definicja „luki” w polityce

Zmiana ogłoszona przez Office of Management and Budget (OMB) dotyczy nie klasycznej podatności technicznej, lecz „luki” na poziomie governance: sposobu, w jaki administracja federalna narzuca (lub nie narzuca) minimalne wymagania bezpieczeństwa dostawcom oprogramowania.

W styczniu 2026 r. OMB opublikowało memorandum M-26-05, które formalnie unieważnia wcześniejsze wytyczne z czasów administracji Joe Biden: M-22-18 oraz jego aktualizację M-23-16. Uzasadnienie: poprzednie wymagania miały być „nieudowodnione i uciążliwe” oraz skupione na biurokratycznej zgodności zamiast realnych inwestycji w bezpieczeństwo.

W skrócie

  • Co wycofano? Dwa kluczowe dokumenty polityki: M-22-18 i M-23-16 zostały „rescinded” (uchylone).
  • Co wchodzi w zamian? Podejście risk-based: większa odpowiedzialność po stronie kierownictwa każdej agencji za dobór metod weryfikacji bezpieczeństwa software i hardware w zależności od misji i profilu ryzyka.
  • Czy SBOM i atestacje znikają całkowicie? Nie. OMB wskazuje, że agencje mogą nadal korzystać z zasobów wypracowanych wcześniej (np. formularza atestacji praktyk wytwarzania) oraz mogą wpisywać do umów obowiązek dostarczenia SBOM „na żądanie”.
  • Nowy akcent: silniejsze uwzględnienie ryzyk sprzętowych (hardware supply chain) i odniesienia do HBOM.

Kontekst / historia / powiązania

M-23-16 (2023) było aktualizacją M-22-18 i wynikało z kierunku wyznaczonego przez Executive Order 14028 (poprawa cyberbezpieczeństwa państwa i bezpieczeństwa łańcucha dostaw). W praktyce te dokumenty miały doprowadzić do tego, aby agencje federalne używały wyłącznie takiego oprogramowania, którego producenci są w stanie poświadczyć spełnianie minimalnych praktyk bezpiecznego wytwarzania.

Mechanika wdrożenia była mocno „procesowa”: terminy, zakres oprogramowania, a także wspólny formularz (common form) przygotowywany z udziałem Cybersecurity and Infrastructure Security Agency (CISA). M-23-16 precyzowało m.in. harmonogram zbierania atestacji w zależności od zatwierdzenia formularza w reżimie Paperwork Reduction Act (PRA).

W 2026 r. OMB przechodzi na narrację: „mniej uniwersalnej checklisty, więcej dopasowania do ryzyka”, podkreślając, że nie ma jednego, „one-size-fits-all” modelu zapewnienia bezpieczeństwa dla wszystkich agencji.

Analiza techniczna / szczegóły zmiany

1. Co wymuszały M-22-18 / M-23-16 (w praktyce)

Z punktu widzenia inżynierii bezpieczeństwa i zakupów IT, sednem była atestacja praktyk SDLC przez producenta oprogramowania. M-23-16 opisywało, że agencje mają zbierać atestacje od producentów (w tym dla „critical software”) w określonych terminach po zatwierdzeniu wspólnego formularza.

Istotne było też doprecyzowanie, że odpowiedzialność za zgodność praktyk rozciąga się na sposób zarządzania komponentami third-party (w tym open source) na poziomie producenta produktu końcowego – a nie na poziomie każdej agencji.

2. Co mówi M-26-05: „risk-based” zamiast „universal compliance”

Nowe memorandum M-26-05:

  • stwierdza, że wcześniejsze wymagania narzucały „burdensome software accounting processes” i odciągały agencje od tworzenia dopasowanych wymagań assurance,
  • unieważnia M-22-18 i M-23-16,
  • utrzymuje oczekiwanie posiadania kompletnego inwentarza software i hardware, ale przenosi ciężar doboru mechanizmów weryfikacji na agencje.

3. Co zostaje jako narzędzia opcjonalne: atestacja, SBOM, HBOM

M-26-05 wprost wskazuje, że agencje:

  • mogą nadal używać zasobów „government-wide secure software development resources” (w tym formularza atestacji praktyk bezpiecznego wytwarzania),
  • mogą wprowadzać do kontraktów zapis o dostarczeniu SBOM na żądanie (w tym szczególna uwaga dla środowisk chmurowych – SBOM środowiska runtime/production),
  • mają też brać pod uwagę ryzyka sprzętowe oraz odwołania do HBOM.

4. Gdzie w tym wszystkim jest SSDF (NIST SP 800-218)

Nawet jeśli obowiązek „federalnej checklisty” zostaje cofnięty, sam rdzeń dobrych praktyk bezpiecznego wytwarzania nie znika. National Institute of Standards and Technology (NIST) opisuje SSDF jako zestaw fundamentalnych praktyk bezpiecznego wytwarzania, zorganizowany w cztery grupy (przygotowanie organizacji, ochrona software, wytwarzanie bezpiecznego software, reakcja na podatności). SSDF ma być „wspólnym językiem” dla producentów i nabywców, a nie wyłącznie checklistą do odhaczania.

W praktyce oznacza to, że SSDF nadal jest sensowną bazą do programów assurance — tylko presja regulacyjna może się przenieść z „musisz użyć dokładnie tego formularza” na „udowodnij adekwatność kontroli do ryzyka”.

Praktyczne konsekwencje / ryzyko

Dla agencji federalnych

  • Większa swoboda, ale i większa odpowiedzialność: skoro nie ma jednego schematu, rośnie ryzyko nierównego poziomu wymagań między agencjami (fragmentacja) i trudniejszego porównywania dostawców.
  • Ryzyko „wyścigu do dna” w zakupach: jeśli część jednostek potraktuje zmianę jako okazję do obniżenia wymagań, ucierpieć może spójność ochrony łańcucha dostaw. (To wniosek analityczny na podstawie kierunku polityki „opcjonalności” narzędzi).

Dla dostawców oprogramowania (software producers)

  • Mniej jednolitego compliance, więcej odpowiedzi na RFP-y „szyte na miarę”: zamiast jednego pakietu atestacji dla całego rządu, mogą pojawić się różne zestawy wymagań assurance zależnie od agencji.
  • SBOM „na żądanie” dalej ma znaczenie: to nie jest sygnał „SBOM niepotrzebny”, tylko „SBOM jako narzędzie kontraktowe i operacyjne, niekoniecznie jako twardy wymóg wszędzie”.

Dla bezpieczeństwa ekosystemu (systemowo)

  • Plus: lepsze dopasowanie kontroli do realnego ryzyka (szczególnie dla systemów o specyficznej misji i ograniczeniach).
  • Minus: utrata efektu skali i standaryzacji, który bywa kluczowy w łańcuchu dostaw (wspólny język wymagań, wspólny formularz, łatwiejszy due diligence).

Rekomendacje operacyjne / co zrobić teraz

Jeśli jesteś dostawcą (vendor / producent oprogramowania)

  1. Utrzymaj SSDF jako kręgosłup programu secure SDLC – nawet jeśli formularz atestacji nie jest już „must-have” wszędzie, SSDF pozostaje najlepszą bazą do rozmowy z nabywcą o kontrolach i dojrzałości.
  2. Przygotuj „pakiet dowodowy” (assurance evidence pack):
    • mapowanie praktyk SDLC do SSDF,
    • opis środowiska build i mechanizmów integralności,
    • procesy VDP/PSIRT, SLA na poprawki, polityka podpisywania artefaktów.
  3. SBOM/HBOM jako produkt uboczny procesu, nie „excel na koniec”: skoro SBOM może być wymagany „upon request”, warto mieć pipeline do generowania i aktualizacji (dla chmury także dla runtime).

Jeśli jesteś po stronie kupującego / security w organizacji publicznej

  1. Zdefiniuj minimalny baseline (nawet jeśli prawo nie narzuca jednego): bez niego risk-based łatwo przeradza się w ad-hoc. OMB podkreśla potrzebę inwentarza i dopasowania assurance do ryzyka – zacznij od klasyfikacji systemów i danych.
  2. Zbuduj wymagania kontraktowe warstwowo:
    • baseline (SSDF-ish),
    • rozszerzenia dla systemów krytycznych,
    • wymagania SBOM na żądanie + format + częstotliwość aktualizacji.
  3. Nie pomijaj hardware: M-26-05 wyraźnie rozszerza akcent na ryzyka sprzętowe – uwzględnij je w ocenie dostawców, logistyce, cyklu życia urządzeń i w monitoringu.

Różnice / porównania z innymi przypadkami

„Compliance-first” (M-22-18/M-23-16) vs „Risk-based” (M-26-05)

  • Compliance-first: jednolita forma atestacji i harmonogramy → łatwiejsza standaryzacja i porównywanie dostawców, ale ryzyko przerostu papierologii.
  • Risk-based: większa elastyczność i dopasowanie do misji → potencjalnie bardziej „inżynierskie” security, ale wyższe ryzyko niespójności wymagań i różnego poziomu dojrzałości w agencjach.

W praktyce dojrzałe organizacje kończą zwykle na modelu hybrydowym: baseline (SSDF) + risk-based rozszerzenia.

Podsumowanie / kluczowe wnioski

Memorandum M-26-05 to istotny zwrot w federalnym podejściu do bezpieczeństwa łańcucha dostaw: od centralnie standaryzowanych atestacji i terminów ku modelowi, w którym każda agencja ma sama dobrać mechanizmy assurance dla oprogramowania i sprzętu.

Najważniejsze: wycofanie wymogów nie oznacza, że SSDF, SBOM czy atestacje „przestają istnieć” — stają się narzędziami opcjonalnymi i kontraktowymi. Dla dostawców to sygnał, by budować dowody dojrzałości secure SDLC (SSDF), a dla kupujących — by nie gubić standaryzacji i utrzymać minimalny baseline w modelu risk-based.

Źródła / bibliografia

  1. SecurityWeek — artykuł: „White House Scraps ‘Burdensome’ Software Security Rules” (30 stycznia 2026). (SecurityWeek)
  2. Office of Management and Budget (OMB) — Memorandum M-26-05 „Adopting a Risk-based Approach to Software and Hardware Security” (23 stycznia 2026).
  3. OMB — Memorandum M-23-16 „Update to Memorandum M-22-18…” (9 czerwca 2023).
  4. National Institute of Standards and Technology (NIST) — strona projektu SSDF (SP 800-218) i opis struktury praktyk. (csrc.nist.gov)
  5. Federal Register — ogłoszenie dot. konsultacji publicznych nt. „2025 Minimum Elements for a Software Bill of Materials (SBOM)” (kontekst SBOM). (Federal Register)

CVE-2026-24061: krytyczne obejście uwierzytelnienia w GNU InetUtils telnetd daje zdalny dostęp root

Wprowadzenie do problemu / definicja luki

CVE-2026-24061 to krytyczna podatność typu authentication bypass w serwerze GNU InetUtils telnetd, która pozwala atakującemu zalogować się zdalnie bez hasła, uzyskując uprawnienia dowolnego użytkownika – w praktyce najczęściej root. Problem dotyczy mechanizmu uruchamiania /usr/bin/login przez telnetd i błędnego traktowania danych kontrolowanych przez klienta jako „bezpiecznych” argumentów wywołania.

W skrócie

  • CVE: CVE-2026-24061 (MITRE/NVD), klasa błędu: CWE-88 (argument injection).
  • Dotyczy: GNU InetUtils 1.9.3–2.7 (luka obecna od 2015 r.).
  • Skutek: obejście uwierzytelnienia i uzyskanie dostępu (często jako root).
  • Status: obserwowano aktywne próby wykorzystania krótko po ujawnieniu.
  • Naprawa: BleepingComputer wskazuje, że problem został załatany w GNU InetUtils 2.8; dodatkowo zalecane są mitigacje (wyłączenie Telnet/port 23).

Kontekst / historia / powiązania

Podatność została publicznie opisana 20 stycznia 2026 r. przez maintenera/kontrybutora GNU InetUtils, Simona Josefssona, wraz z historią wskazującą na commit z 19 marca 2015 r., który wprowadził ryzykowną ścieżkę przetwarzania danych.

Choć Telnet jest protokołem legacy, nadal bywa spotykany w środowiskach przemysłowych/OT i w urządzeniach „z długim cyklem życia”, gdzie modernizacja bywa kosztowna lub operacyjnie trudna. To właśnie tam takie „stare” podatności potrafią mieć nieproporcjonalnie wysoki wpływ.

Analiza techniczna / szczegóły luki

Sedno problemu: telnetd uruchamia /usr/bin/login (zwykle działający z wysokimi uprawnieniami), przekazując do niego wartość zmiennej środowiskowej USER, którą w tym przypadku może dostarczyć klient Telnet. Brak właściwej sanitacji powoduje, że odpowiednio spreparowana wartość USER zostaje potraktowana jako parametr dla login(1), co umożliwia obejście standardowego procesu logowania.

To klasyczny przypadek argument injection (CWE-88): dane, które powinny być „czystą wartością”, trafiają do kontekstu, gdzie znaki/ciągi mają znaczenie składniowe dla programu wywoływanego.

Dodatkowy, praktyczny aspekt ryzyka opisany w analizie SafeBreach: błąd ma charakter „oldschoolowy”, jest prosty do automatyzacji, a badacze pokazali root cause oraz mechanikę negocjacji Telnet/ustawiania środowiska w kontekście procesu usługi.

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyko to pełne przejęcie hosta (root) przy ekspozycji telnetd na sieć nieufną. W praktyce przekłada się to na:

  • kradzież danych i tajemnic (odczyt plików, konfiguracji, kluczy),
  • modyfikację konfiguracji i backdooryzację (np. trwałość poprzez klucze SSH),
  • uruchamianie złośliwego kodu, skanowanie sieci wewnętrznej, ruch boczny.

W obserwacjach telemetrycznych przytoczonych przez BleepingComputer (na bazie danych firmy monitorującej zagrożenia) próby ataków obejmowały automatyczne działania post-exploitation (rekonesans, próby persystencji i wdrożenia malware), przy czym część prób miała się nie powieść ze względu na braki w środowisku ofiar. To ważny sygnał: łańcuchy ataków będą optymalizowane, gdy tylko atakujący zidentyfikują „działające” kombinacje.

Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję Telnet (port 23)
    • Sprawdź, czy cokolwiek nasłuchuje na TCP/23 oraz czy usługa to faktycznie GNU InetUtils telnetd (nie każdy telnetd jest tym samym).
  2. Zaktualizuj / załatkaj
    • Jeśli używasz GNU InetUtils w zakresie wersji podatnych (1.9.3–2.7), priorytetem jest przejście na wydanie zawierające poprawkę (w doniesieniach: 2.8).
  3. Mitigacje, gdy patchowanie jest trudne (OT/legacy)
    • Wyłącz Telnet, jeśli to możliwe.
    • Jeśli Telnet jest „nie do ruszenia”: nie wystawiaj go do Internetu, ogranicz dostęp segmentacją, ACL na firewallu, oraz używaj kontrolowanego dostępu typu VPN / ZTNA.
  4. Detekcja i monitoring
    • Podnieś poziom monitoringu połączeń do telnetd (nietypowe źródła, skoki liczby sesji, nowe geolokalizacje).
    • Koreluj logi uwierzytelnienia i uruchamiania sesji (szczególnie „logowania”, które nie powinny przechodzić normalnej ścieżki).
  5. Hardening
    • Traktuj Telnet jako techniczny dług: planowo migruj na SSH lub dedykowane mechanizmy z silnym uwierzytelnianiem i szyfrowaniem.

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

CVE-2026-24061 jest dobrym przykładem podatności, które wracają w różnych formach od lat:

  • „Zaufane dane” przekazane do uprzywilejowanego procesu (tu: login(1) uruchamiany przez usługę),
  • błędy granicy zaufania: coś, co wygląda jak „zmienna środowiskowa”, w praktyce jest danymi z sieci,
  • argument injection zamiast klasycznego command injection — skutki mogą być równie krytyczne, gdy wywoływany komponent ma funkcje „pomijania” zabezpieczeń.

W odróżnieniu od wielu nowoczesnych podatności, tutaj nie ma skomplikowanej kryptografii czy deserializacji: to „prosty błąd kleju” między usługą a narzędziem systemowym — dlatego bywa tak łatwy do masowej automatyzacji.

Podsumowanie / kluczowe wnioski

  • CVE-2026-24061 umożliwia zdalne obejście logowania w GNU InetUtils telnetd przez błąd argument injection związany z przekazaniem kontrolowanej przez klienta wartości do login(1).
  • Podatność dotyczy wersji 1.9.3–2.7 i jest związana z kodem obecnym od 2015 r.; opisy wskazują na poprawkę w 2.8.
  • Mimo „legacy” charakteru Telnet, realne środowiska (zwłaszcza OT/embedded) nadal mogą być narażone, a próby wykorzystania były obserwowane wkrótce po ujawnieniu.
  • Priorytetem jest wyłączenie Telnet / ograniczenie dostępu / szybkie aktualizacje oraz podniesienie monitoringu.

Źródła / bibliografia

  1. BleepingComputer — „Hackers exploit critical telnetd auth bypass flaw to get root” (23.01.2026). (BleepingComputer)
  2. oss-security (seclists.org) — „GNU InetUtils Security Advisory: remote authentication by-pass in telnetd” (20.01.2026). (seclists.org)
  3. NVD/NIST — rekord CVE-2026-24061 (publikacja 21.01.2026). (NVD)
  4. SafeBreach Labs — „Root Cause Analysis & PoC… CVE-2026-24061” (22.01.2026). (SafeBreach)
  5. Centre for Cybersecurity Belgium (CCB) — advisory i zalecenia dot. telnetd auth bypass. (ccb.belgium.be)

LastPass ostrzega przed fałszywymi mailami „maintenance”: kampania phishingowa poluje na hasło główne

Wprowadzenie do problemu / definicja luki

LastPass opublikował ostrzeżenie o aktywnej kampanii phishingowej, w której atakujący podszywają się pod firmę i rozsyłają wiadomości o rzekomej „konserwacji” infrastruktury. Celem jest wyłudzenie hasła głównego (master password) – czyli „klucza” do całego sejfu z zapisanymi hasłami, notatkami i innymi danymi. Kampania bazuje na klasycznym socjotechnicznym triku: presji czasu („masz 24 godziny”).

W skrócie

  • Start kampanii: około 19 stycznia 2026.
  • Przynęta: „maintenance” i pilne polecenie utworzenia „lokalnej kopii” sejfu w ciągu 24h.
  • Łańcuch przekierowań: link prowadzi na zasób hostowany w Amazon S3, a następnie przekierowuje na fałszywą domenę imitującą LastPass.
  • LastPass podkreśla: nikt z LastPass nigdy nie poprosi o hasło główne; podejrzane maile można zgłaszać na abuse@lastpass.com.

Kontekst / historia / powiązania

Menedżery haseł są atrakcyjnym celem, bo przejęcie jednego konta może otworzyć drogę do wielu innych (poczta, bank, systemy firmowe, panele administracyjne). Atakujący świadomie uderzają w momenty, gdy czujność spada – LastPass wskazuje, że timing kampanii wypadł w okresie świątecznego weekendu w USA, co często utrudnia szybką reakcję zespołów bezpieczeństwa.

Analiza techniczna / szczegóły kampanii

Z perspektywy IR/SOC to dość typowy schemat „brand impersonation + redirector”, ale z kilkoma elementami, które zwiększają skuteczność:

1) Tematy i nagłówki wiadomości

LastPass opublikował przykładowe tematy, m.in.:

  • LastPass Infrastructure Update: Secure Your Vault Now
  • Important: LastPass Maintenance & Your Vault Security
  • Protect Your Passwords: Backup Your Vault (24-Hour Window)

2) Nadawcy / infrastruktura pocztowa (IOC)

W ostrzeżeniu LastPass pojawiają się m.in. nadawcy w stylu:

  • support@sr22vegas[.]com
  • support@lastpass[.]server8 / support@lastpass[.]server7 / support@lastpass[.]server3

Uwaga operacyjna: samo „From:” bywa łatwe do sfałszowania, ale to nadal przydatne IOC do korelacji (wraz z nagłówkami i ścieżką SMTP).

3) Łańcuch URL i przekierowania (IOC)

LastPass wskazuje, że link z maila prowadzi na:

  • group-content-gen2.s3.eu-west-3.amazonaws[.]com/5yaVgx51ZzGf (Amazon S3)
    …a następnie przekierowuje na:
  • mail-lastpass[.]com

W tym modelu S3 bywa użyte jako „pośrednik” (redirector), co potrafi utrudnić proste blokady oparte wyłącznie o reputację domen nadawcy.

4) Dodatkowe IOC (adresy IP)

LastPass dołącza także adresy IP powiązane z elementami kampanii (wraz ze stanem „w momencie publikacji”), m.in. IP serwujące zasób S3 oraz IP kojarzone z domeną phishingową.

Praktyczne konsekwencje / ryzyko

Jeśli użytkownik poda hasło główne na fałszywej stronie, konsekwencje mogą być natychmiastowe:

  • Przejęcie sejfu: dostęp do wielu loginów i haseł (w tym firmowych), notatek, danych kart, tokenów.
  • Ataki łańcuchowe: password reuse / credential stuffing, przejęcia skrzynek e-mail, resetowanie haseł w innych usługach.
  • Ryzyko dla organizacji: eskalacja do dostępu do VPN/SSO, paneli administracyjnych, repozytoriów kodu, chmury.

W praktyce jest to incydent typu „high impact / high blast radius”, bo stawką nie jest jedno konto, tylko „konto do wszystkich kont”.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (osób prywatnych i pracowników)

  1. Nie klikaj w linki z maili o „maintenance” i „backup w 24h”.
  2. Jeśli masz wątpliwości: wejdź do LastPass wyłącznie z zakładki / ręcznie wpisanego adresu (bez użycia linku z e-maila).
  3. Zgłoś podejrzaną wiadomość do abuse@lastpass.com (zgodnie z zaleceniem LastPass).
  4. Jeśli wpisałeś hasło główne na podejrzanej stronie:
    • natychmiast zmień hasło główne,
    • przejrzyj logowania / aktywne sesje i je unieważnij,
    • zacznij rotację najważniejszych haseł (poczta, bank, konto firmowe, SSO),
    • włącz/zaostrz MFA (preferuj metody odporne na phishing, jeśli dostępne).

Dla SOC/IT (organizacje)

  1. Dodaj IOC do kontroli: domeny/URL (w formie zdefangowanej), nadawców, tematy wiadomości; skoreluj z proxy/DNS/email gateway.
  2. Wprowadź reguły w secure email gateway: wykrywanie „24-hour window”, „backup your vault”, „maintenance” + brand keywords.
  3. Polityka przeglądarek: ostrzejsze blokady dla świeżych domen, izolacja linków, sandbox kliknięć.
  4. Szkolenie „just-in-time”: krótki alert do pracowników z przykładowymi tematami wiadomości i zasadą „LastPass nigdy nie prosi o master password”.

Różnice / porównania z innymi przypadkami

Ta kampania wyróżnia się tym, że nie straszy „wyciekiem”, tylko podszywa się pod „czynności serwisowe” i obiecuje „ciągłość dostępu” dzięki kopii lokalnej. To sprytne, bo brzmi jak działanie proaktywne, a nie jak panika po incydencie. Dodatkowo użycie pośredniego hostingu w chmurze jako etapu przekierowania jest typowe dla kampanii nastawionych na skalę i szybkie rotowanie infrastruktury.

Podsumowanie / kluczowe wnioski

  • Kampania (obserwowana od ok. 19 stycznia 2026) próbuje wyłudzić master password pod pretekstem „maintenance” i konieczności wykonania kopii sejfu w 24h.
  • Łańcuch prowadzi przez zasób w Amazon S3 i przekierowuje na domenę imitującą LastPass.
  • Najważniejsza zasada: LastPass nie prosi o hasło główne; podejrzane wiadomości należy raportować do abuse@lastpass.com.

Źródła / bibliografia

  1. LastPass (TIME team) – New Phishing Campaign Targeting LastPass Customers (20 stycznia 2026). (The LastPass Blog)
  2. The Hacker News – LastPass Warns of Fake Maintenance Messages Targeting Users’ Master Passwords (21 stycznia 2026). (The Hacker News)
  3. BleepingComputer – Fake Lastpass emails pose as password vault backup alerts (21 stycznia 2026). (BleepingComputer)
  4. SecurityWeek – LastPass Users Targeted With Backup-Themed Phishing Emails (21 stycznia 2026). (SecurityWeek)
  5. Cybersecurity Dive – LastPass warns backup request is phishing campaign in disguise (21 stycznia 2026). (Cybersecurity Dive)

UE chce obowiązkowo wycofać sprzęt „wysokiego ryzyka” z sieci i infrastruktury krytycznej – co to oznacza dla cyberbezpieczeństwa 5G i łańcucha dostaw ICT?

Wprowadzenie do problemu / definicja luki

Komisja Europejska zapowiedziała rozwiązania, które mają uczynić obowiązkowym podejście do ograniczania roli tzw. „dostawców wysokiego ryzyka” (high-risk suppliers) w kluczowych elementach infrastruktury cyfrowej – w tym w sieciach łączności (zwłaszcza 5G) oraz innych sektorach krytycznych. W praktyce jest to powszechnie interpretowane jako ruch wymierzony w chińskich producentów, takich jak Huawei i ZTE, choć propozycje nie wskazują firm ani państw wprost.

W cyberbezpieczeństwie nie chodzi tu o „jedną podatność CVE”, tylko o ryzyko systemowe łańcucha dostaw: możliwość wpływu państwa trzeciego na producenta, presję prawną, ograniczoną przejrzystość procesu wytwarzania, a także ryzyko zakłóceń dostaw, serwisu i aktualizacji. Komisja już wcześniej argumentowała, że utrzymywanie zależności od dostawców wysokiego ryzyka może mieć poważne skutki dla bezpieczeństwa użytkowników i infrastruktury krytycznej w całej UE.

W skrócie

  • Propozycja zakłada wycofanie komponentów/sprzętu od dostawców wysokiego ryzyka z elementów uznanych za krytyczne – w mediach przewija się horyzont ok. 3 lat / 36 miesięcy dla sieci mobilnych (po spełnieniu warunków formalnych).
  • Zmiana ma „utwardzić” dotychczasowe zalecenia (soft-law) i zakończyć nierówną implementację między państwami UE.
  • Równolegle Komisja opublikowała materiały dot. propozycji rewizji Cybersecurity Act w ramach szerszego pakietu – z akcentem na odporność i bezpieczeństwo łańcuchów dostaw ICT.
  • W tle pozostaje „5G Toolbox” oraz raporty/monitoring wdrożeń – już w 2020 r. podkreślano potrzebę przeglądu i wzmacniania zabezpieczeń 5G przez państwa członkowskie.

Kontekst / historia / powiązania

UE pracuje nad ryzykiem dostawców w 5G co najmniej od momentu uruchomienia EU 5G Security Toolbox (koordynacja w ramach NIS Cooperation Group). Celem było ograniczenie ryzyk technicznych i nietechnicznych (np. prawno-geopolitycznych), m.in. poprzez ocenę profilu ryzyka dostawców i ograniczanie roli tych uznanych za wysokiego ryzyka w kluczowych funkcjach sieci.

W czerwcu 2023 r. Komisja wprost wskazywała, że istnieje ryzyko utrzymywania zależności od dostawców wysokiego ryzyka w UE oraz że – na podstawie kryteriów z Toolboxa – decyzje części państw o ograniczaniu/wykluczaniu Huawei i ZTE są zgodne z podejściem unijnym.

W praktyce jednak wdrożenia były nierówne: jedne kraje ograniczały sprzęt, inne nadal dopuszczały go w większym zakresie, co utrudniało budowę jednolitego poziomu bezpieczeństwa rynku. Nowe propozycje mają tę „mozaikę” ujednolicić poprzez mechanizm wiążący.

Analiza techniczna / szczegóły „luki” (ryzyko łańcucha dostaw)

W sieciach 4G/5G i w systemach infrastruktury krytycznej ryzyko dostawcy nie sprowadza się wyłącznie do „czy urządzenie ma backdoora”. Kluczowe są punkty kontroli i zaufania:

  1. Płaszczyzna zarządzania (management plane)
    Kontrolery, systemy OSS/BSS, platformy NMS, zdalne utrzymanie i diagnostyka. Każdy mechanizm zdalnego dostępu, telemetrii, update’ów i logowania jest potencjalnym „kanałem” nadużyć – nawet bez celowego działania producenta (wystarczy kompromitacja łańcucha aktualizacji).
  2. Rdzeń sieci (5G Core) i funkcje krytyczne
    Elementy odpowiedzialne za uwierzytelnianie, routing, polityki QoS, network slicing czy sygnalizację. Usterki, błędne aktualizacje albo złośliwe modyfikacje mogą mieć efekt systemowy.
  3. Warstwa radiowa (RAN) i zależności operacyjne
    Nawet jeśli część państw koncentrowała się na „wyrzucaniu” dostawcy z rdzenia, to nadal pozostaje temat interoperacyjności, vendor lock-in, łańcucha części zamiennych oraz serwisu.
  4. Ryzyka nietechniczne, które materializują się technicznie
    • presja prawna w państwie pochodzenia dostawcy,
    • brak przejrzystości w procesach SDLC i wytwarzania firmware,
    • trudność audytu kodu i aktualizacji,
    • ryzyko sankcji/zakazu eksportu/serwisu → opóźnienia w patchowaniu.

Właśnie dlatego propozycje UE idą w stronę ramy oceny i ograniczeń dostawców (supply chain security), a nie „łatania” pojedynczych podatności.

Praktyczne konsekwencje / ryzyko

Dla operatorów i podmiotów infrastruktury krytycznej skutki będą głównie w trzech obszarach:

  • Koszt i złożoność migracji: wymiana elementów sieci/urządzeń, testy interoperacyjności, okna serwisowe, ryzyko degradacji SLA i opóźnień rolloutów (zwłaszcza 5G SA).
  • Ryzyko operacyjne w okresie przejściowym: równoległe utrzymywanie „starego” i „nowego” stosu technologicznego, większa powierzchnia ataku (więcej integracji), a także presja na zespoły bezpieczeństwa i NOC/SOC.
  • Wpływ na inne sektory: wg doniesień propozycje obejmują nie tylko telekomy, ale też elementy wykorzystywane np. w systemach kontroli granicznej, wodociągach, ochronie zdrowia/urządzeniach medycznych – czyli tam, gdzie awaria/kompromitacja ma realny wpływ na ciągłość działania usług publicznych.

Warto też zauważyć aspekt geopolityczny: ruch UE jest postrzegany jako część szerszego trendu ograniczania ryzyka związanego z dostawcami z państw trzecich w kluczowych technologiach.

Rekomendacje operacyjne / co zrobić teraz

Jeśli odpowiadasz za bezpieczeństwo sieci, OT/ICS albo zakupy ICT w sektorze krytycznym, sensowne „tu i teraz” to:

  1. Zrób inwentaryzację zależności dostawcy (bill of materials dla infrastruktury)
    • gdzie dokładnie działa sprzęt/oprogramowanie danego vendora (core/RAN/management/transport),
    • które systemy wymagają zdalnego utrzymania i jakie kanały dostępu istnieją.
  2. Oceń „blast radius” wymiany
    • co jest „key ICT asset” (krytyczne i wrażliwe zasoby),
    • jak wygląda plan migracji: kolejność, testy, kompatybilność, utrzymanie usług.
  3. Wymuś twarde wymagania supply chain security w zakupach i umowach
    • polityka aktualizacji (SLA na security patches),
    • wymagania dot. logowania, telemetrii, ograniczania zdalnego dostępu,
    • prawo do audytu, wymagania dot. transparentności cyklu życia produktu.
  4. Zabezpiecz okres przejściowy
    • segmentacja i kontrola dostępu do warstwy zarządzania,
    • monitoring anomalii (sieć + systemy zarządzania),
    • „break glass” dla zdalnego serwisu, MFA, bastiony, minimalizacja uprawnień.
  5. Przygotuj się na ujednolicenie wymagań w UE
    Skoro Komisja mówi o ograniczeniu fragmentacji rynku i budowie ram dla łańcuchów dostaw ICT, warto zakładać, że oczekiwania regulacyjne i audytowe będą bardziej spójne – szczególnie dla operatorów i sektorów krytycznych.

Różnice / porównania z innymi przypadkami

  • Wcześniej (Toolbox): nacisk na rekomendacje i wdrożenia krajowe → różna praktyka w państwach UE.
  • Teraz (propozycje 2026): przesunięcie w stronę podejścia obowiązkowego i bardziej centralnie koordynowanego, z docelowym harmonogramem wycofywania komponentów wysokiego ryzyka (w doniesieniach: ok. 36 miesięcy dla sieci mobilnych po spełnieniu warunków formalnych).

Podsumowanie / kluczowe wnioski

UE przechodzi od „miękkiej” koordynacji do twardszego modelu zarządzania ryzykiem dostawców w krytycznej infrastrukturze cyfrowej. Dla bezpieczeństwa oznacza to, że vendor risk i supply chain security stają się równorzędne z klasycznym vulnerability management.

Dla operatorów i organizacji krytycznych najważniejsze będzie: szybkie rozpoznanie zależności, plan migracji minimalizujący ryzyko operacyjne oraz wzmocnienie kontroli bezpieczeństwa w warstwie zarządzania i aktualizacji – bo to tam najczęściej materializuje się ryzyko łańcucha dostaw.

Źródła / bibliografia

  1. SecurityWeek / Associated Press – opis propozycji i kontekstu „high risk suppliers”, 20 stycznia 2026. (SecurityWeek)
  2. Reuters – szczegóły dot. planu, sektorów i horyzontu 36 miesięcy, 20 stycznia 2026. (Reuters)
  3. Komisja Europejska (DG CONNECT) – „Proposal for a Regulation for the EU Cybersecurity Act”, publikacja 20 stycznia 2026. (Digital Strategy)
  4. Komisja Europejska – „Implementation of the 5G cybersecurity Toolbox”, 15 czerwca 2023. (Digital Strategy)
  5. ENISA – informacja o raporcie dot. wdrożenia EU 5G Toolbox, 24 lipca 2020. (enisa.europa.eu)

42 tys. osób dotkniętych atakiem ransomware na Ingram Micro: co wiemy i jakie są konsekwencje dla łańcucha dostaw IT

Wprowadzenie do problemu / definicja luki

Ataki ransomware na podmioty „węzłowe” dla ekosystemu IT (dystrybutorów, integratorów, MSP, platformy licencyjne) są szczególnie groźne, bo łączą dwa wektory szkód: przestój operacyjny oraz kradzież danych (tzw. podwójne wymuszenie). Przypadek Ingram Micro jest podręcznikowy: po incydencie z lipca 2025 r. firma potwierdziła, że naruszenie danych dotknęło ok. 42 tys. osób, a wykradzione pliki mogły zawierać m.in. identyfikatory państwowe i dane pracownicze.

W skrócie

  • Skala: Ingram Micro zgłosił, że incydent dotyczy 42 521 osób.
  • Okno naruszenia: firma wskazuje na 2–3 lipca 2025 jako czas dostępu do repozytoriów plików.
  • Zakres danych: m.in. imię i nazwisko, data urodzenia, SSN (dla części osób), numery dokumentów (np. paszport/prawo jazdy) oraz informacje pracownicze / rekrutacyjne.
  • Wpływ na działalność: w lipcu 2025 nastąpiły szerokie zakłócenia usług; Ingram informował o przywróceniu globalnej operacyjności ok. 9 lipca 2025.
  • Działania wobec poszkodowanych: firma oferuje 24 miesiące monitoringu kredytowego i ochrony tożsamości.

Kontekst / historia / powiązania

Pierwsze oficjalne potwierdzenie „ransomware na części systemów” pojawiło się publicznie na początku lipca 2025 r.; spółka informowała o odłączeniu wybranych systemów, uruchomieniu dochodzenia z udziałem zewnętrznych ekspertów i powiadomieniu organów ścigania.

W kolejnych komunikatach statusowych Ingram Micro opisywał proces przywracania usług (m.in. wznowienie przetwarzania zamówień kanałami alternatywnymi oraz finalną informację o globalnym wznowieniu operacji 9 lipca 2025).

Na początku 2026 r. (w związku z wysyłką notyfikacji) ujawniono, że incydent miał też wymiar naruszenia poufności danych pracowników i kandydatów.

Analiza techniczna / szczegóły luki

Z dostępnych informacji wynika następujący, najbardziej prawdopodobny przebieg zdarzeń:

  1. Dostęp nieuprawnionego podmiotu do wewnętrznych repozytoriów plików – Ingram Micro wprost wskazuje, że „nieuprawniona strona” pobrała wybrane pliki z repozytoriów w przedziale 2–3 lipca 2025.
  2. Faza ransomware i działania ograniczające – firma potwierdza identyfikację ransomware na części systemów i podjęcie działań typu containment (m.in. odłączenie systemów).
  3. Zakłócenie usług i odtwarzanie – komunikaty statusowe pokazują etapowe przywracanie przetwarzania zamówień i wznowienie operacji globalnie do 9 lipca 2025.
  4. Wątek „double extortion” – SecurityWeek wskazuje, że grupa Safepay umieściła Ingram Micro na swoim leak site, deklarując kradzież 3,5 TB danych; publikacja tych danych na początku sierpnia ma sugerować brak zapłaty okupu (to wniosek redakcyjny oparty na obserwacji leak site).
    • BleepingComputer zaznacza, że Ingram Micro nie przypisał oficjalnie incydentu konkretnej grupie, ale odnosi się do doniesień łączących zdarzenie z Safepay.

Ważne ograniczenie: żadne z ww. źródeł nie publikuje (na ten moment) technicznych IOC (hashy, adresów C2, nazw narzędzi) pozwalających na precyzyjne polowanie w logach — dlatego rekomendacje muszą być bardziej „procesowe” niż sygnaturowe.

Praktyczne konsekwencje / ryzyko

1) Ryzyko dla osób, których dane wyciekły

Zakres ujawnionych kategorii (w tym identyfikatory państwowe i dane rekrutacyjne/pracownicze) zwiększa prawdopodobieństwo:

  • kradzieży tożsamości i nadużyć finansowych,
  • wyłudzeń socjotechnicznych (ukierunkowany phishing/SMiShing/voice),
  • oszustw „na HR” (podszywanie się pod rekrutera/pracodawcę, fałszywe oferty pracy).

2) Ryzyko dla partnerów i klientów w łańcuchu dostaw IT

Ingram Micro jako dystrybutor i operator platform transakcyjnych/licencyjnych to punkt krytyczny — nawet gdy dane klientów nie są wprost wymienione w notyfikacji, przestój i potencjalne skutki wtórne (np. opóźnienia dostaw, obejścia procesów zakupowych „bokiem”, presja na alternatywne kanały zamówień) tworzą podwyższone ryzyko operacyjne.

Rekomendacje operacyjne / co zrobić teraz

Jeśli jesteś osobą, która mogła zostać objęta incydentem (pracownik/kandydat)

  • Skorzystaj z oferowanych przez firmę 24 miesięcy monitoringu kredytowego/ochrony tożsamości (jeśli otrzymałeś(aś) powiadomienie).
  • Ustaw alerty na rachunkach i w usługach kredytowych, rozważ zamrożenie/monitoring kredytu (tam, gdzie ma to zastosowanie).
  • Traktuj jako podejrzane: prośby o „pilną weryfikację danych”, „ponowne przesłanie dokumentów”, linki do rzekomych portali HR.

Jeśli jesteś organizacją współpracującą (partner, reseller, vendor)

  • Włącz podwyższony monitoring socjotechniki: kampanie podszywające się pod działy zamówień/finanse/HR, fałszywe zmiany numerów kont (BEC).
  • Sprawdź, czy w okresie incydentu (lipiec–sierpień 2025) nie pojawiły się anomalie w: resetach haseł, tokenach API, nieautoryzowanych integracjach, nietypowych logowaniach do portali dystrybucyjnych.
  • Zaktualizuj oceny ryzyka dostawcy (TPRM): wymagaj aktualnych informacji o środkach naprawczych, segmentacji, MFA, monitoringu i procedurach odtwarzania (RTO/RPO).

Jeśli prowadzisz SOC/IR

  • Zbuduj scenariusze detekcji pod data theft + ransomware: duże wolumeny odczytu/archiwizacji, niecodzienne procesy kompresji, nietypowy ruch wychodzący, a równolegle aktywność szyfrującą (masowe rename/write, VSS shadow copy deletion).
  • Zweryfikuj gotowość do działania w warunkach wyłączeń systemów: procesy zamówień, obsługa klientów, kanały awaryjne (telefony/e-mail) — incydent Ingram pokazuje, że to realny tryb pracy przez kilka dni.

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

Ten incydent wyróżnia się tym, że:

  • uderza w podmiot o roli „hubu” logistyczno-transakcyjnego, więc zakłócenie usług może być równie dotkliwe jak sam wyciek,
  • zakres danych dotyczy głównie HR (pracownicy/kandydaci), co często skutkuje długim „ogonem” ryzyka (fraudy tożsamościowe pojawiają się miesiące później).

Podsumowanie / kluczowe wnioski

  • Ingram Micro potwierdził naruszenie obejmujące 42 521 osób i wskazał na 2–3 lipca 2025 jako okno dostępu do plików z danymi.
  • Zakres danych (w tym identyfikatory rządowe oraz informacje pracownicze/rekrutacyjne) oznacza podwyższone ryzyko oszustw i kradzieży tożsamości.
  • Incydent miał wymierny wpływ operacyjny — firma etapowo przywracała usługi i raportowała globalne wznowienie działań około 9 lipca 2025.
  • Dla organizacji w łańcuchu dostaw najważniejsze są teraz działania anty-phishing/BEC oraz przegląd zależności integracyjnych i procedur awaryjnych.

Źródła / bibliografia

  1. SecurityWeek – „42,000 Impacted by Ingram Micro Ransomware Attack” (19 stycznia 2026) (SecurityWeek)
  2. BleepingComputer – „Ingram Micro says ransomware attack affected 42,000 people” (19 stycznia 2026) (BleepingComputer)
  3. Ingram Micro – strona statusowa „Cybersecurity Incident” (aktualizacje lipiec 2025) (ingrammicro.com)
  4. Reuters – depesza o identyfikacji ransomware i działaniach zabezpieczających (6 lipca 2025) (Reuters)

UK ostrzega przed trwającymi atakami prorosyjskich „hacktywistów”: DDoS wraca na pierwszy plan (NoName057(16), DDoSia)

Wprowadzenie do problemu / definicja „luki”

Brytyjskie instytucje bezpieczeństwa cybernetycznego ostrzegają przed utrzymującą się falą działań prorosyjskich grup „hacktywistycznych”, których głównym celem jest zakłócanie dostępności usług – przede wszystkim poprzez (D)DoS wymierzone w serwisy publiczne, samorządy oraz elementy infrastruktury krytycznej. Istota problemu nie polega na „wyrafinowanej exploatacji”, tylko na odporności operacyjnej: nawet technicznie proste ataki mogą wymusić kosztowną reakcję, doprowadzić do przestojów i obniżyć zaufanie do usług cyfrowych.

W skrócie

  • Ostrzeżenia (styczeń 2026) wskazują na ciągłe, powtarzalne ataki DDoS wymierzone m.in. w brytyjskie jednostki samorządu i organizacje świadczące kluczowe usługi.
  • W centrum uwagi pojawia się NoName057(16) oraz projekt DDoSia – model „crowdsourcingu” mocy obliczeniowej do prowadzenia ataków (z elementami motywacji/rywalizacji w społeczności).
  • W tle są też szersze zjawiska: wspólne ostrzeżenia partnerów międzynarodowych pokazują, że prorosyjscy aktorzy potrafią łączyć „szum DDoS” z oportunistycznymi wejściami w środowiska OT/ICS (np. przez źle zabezpieczone VNC).

Kontekst / historia / powiązania

NoName057(16) jest aktywne co najmniej od marca 2022 r. i regularnie uderzało w podmioty w państwach NATO oraz innych krajach europejskich postrzeganych jako wrogie „interesom geopolitycznym” Rosji. Grupa działa w dużej mierze przez kanały komunikacji społecznościowej (np. Telegram) i wykorzystywała platformy takie jak GitHub do dystrybucji narzędzi oraz TTP.

W lipcu 2025 r. aktywność NoName057(16) była zakłócana przez działania organów ścigania (m.in. przejęcia infrastruktury i zatrzymania), ale – jak pokazują ostrzeżenia z początku 2026 r. – presja operacyjna wróciła, co jest typowe dla grup „rozproszonych”, działających w modelu społecznościowym i trudnych do trwałego „wyłączenia”.

Równolegle brytyjski NCSC zwraca uwagę, że konflikty geopolityczne (wojna Rosji przeciw Ukrainie, napięcia międzynarodowe) napędzają wzrost liczby prorosyjskich grup hacktywistycznych, których działania są mniej przewidywalne, bo cele dobierają często pod kątem „tego, co akurat jest podatne”.

Analiza techniczna / szczegóły działań

1) DDoS jako „tania” broń na dostępność

Opisywane kampanie koncentrują się na wyłączaniu stron i usług – szczególnie tych, które mają znaczenie społeczne (informacja publiczna, usługi samorządowe, systemy obsługi mieszkańców). DDoS jest atrakcyjny, bo:

  • łatwo go „skalować” (botnety, wynajęte usługi, wolontariusze),
  • trudno jednoznacznie przypisać sprawstwo,
  • efekt (niedostępność) jest widoczny natychmiast i świetnie działa propagandowo.

2) DDoSia i model „crowdsourced DDoS”

Wątek kluczowy to DDoSia – platforma/ekosystem umożliwiający zwolennikom dorzucanie zasobów do ataku (w praktyce: klient/agent + koordynacja + motywatory). Taki model obniża próg wejścia, zwiększa dynamikę kampanii i ułatwia „odrastanie” po działaniach służb.

3) Kiedy „hacktywizm” dotyka OT/ICS

Wspólne opracowania partnerów międzynarodowych podkreślają, że część prorosyjskich grup (w tym wymieniane: CARR, Z-Pentest, NoName057(16), Sector16) prowadzi także oportunistyczne działania przeciw infrastrukturze krytycznej, wykorzystując m.in. źle zabezpieczone, internetowo dostępne VNC do uzyskania dostępu do HMI/urządzeń OT. To nie musi być APT-owa finezja – często wystarcza:

  • skanowanie usług (np. Nmap/OpenVAS),
  • password spraying / brute force na słabych lub domyślnych hasłach,
  • typowe porty VNC (np. 5900 i okolice),
  • manipulacje w GUI HMI (setpointy/parametry) oraz „dowody” w postaci screenów i nagrań publikowanych w social media.

W tej perspektywie DDoS jest tylko jednym z narzędzi nacisku; ryzyko rośnie, jeśli organizacja ma jednocześnie słabą higienę zdalnego dostępu do OT.

Praktyczne konsekwencje / ryzyko

  • Koszt i przestój: nawet krótkie przerwy w dostępności usług publicznych generują koszty, eskalacje i obciążenie zespołów (analiza ruchu, komunikacja kryzysowa, przywracanie usług).
  • Efekt społeczny: ataki na serwisy samorządowe i usługi „pierwszej potrzeby” wzmacniają przekaz propagandowy („państwo nie działa”), nawet gdy technicznie to „tylko DDoS”.
  • Ryzyko OT/ICS: w scenariuszach oportunistycznych wejść przez VNC konsekwencje mogą wykraczać poza IT (zakłócenia procesów, a w skrajnych przypadkach szkody fizyczne).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie podnoszą odporność na DDoS i „tanią” presję operacyjną (szczególnie w sektorze publicznym i u operatorów usług kluczowych):

  1. Zmapuj punkty krytyczne usług
  • Co jest „single point of failure” (DNS, reverse proxy, WAF, łącze, upstream)?
  • Jak wygląda odpowiedzialność: ISP vs hosting vs dostawca aplikacji?
  1. Wzmocnij warstwę upstream
  • Uzgodnij z ISP procedury scrubbingu/blackholingu.
  • Rozważ usługi anty-DDoS oraz CDN dla serwisów publicznych.
  • Dla kluczowych usług: redundancja u wielu dostawców (tam, gdzie to uzasadnione).
  1. Projektuj pod skalowanie i degradację kontrolowaną
  • Autoscaling w chmurze, zapas mocy, cache, kolejki.
  • „Graceful degradation”: co ma działać zawsze (np. komunikaty statusowe, kanały alternatywne).
  1. Playbook i ćwiczenia DDoS
  • Kto podejmuje decyzje o przełączeniach, ograniczeniach funkcji, komunikacji do obywateli/klientów?
  • Jak utrzymujesz dostęp administracyjny podczas ataku?
  • Testuj regularnie (table-top + testy techniczne).
  1. Jeśli masz OT/ICS: potraktuj VNC jako „czerwony alarm”
  • Usuń ekspozycję VNC do internetu; jeśli absolutnie konieczne – tylko przez bezpieczny bastion/VPN, allowlisty, MFA, rotacja haseł.
  • Inwentaryzuj zdalny dostęp do HMI/SCADA, monitoruj skanowania i próby logowania.
  • Zastosuj twarde polityki haseł i blokady anty-bruteforce.

Różnice / porównania z innymi przypadkami

  • DDoS vs APT: DDoS bywa „mało wyrafinowany”, ale jego celem jest widoczny efekt operacyjny (niedostępność). APT częściej dąży do długotrwałej obecności i kradzieży danych. To inne metryki sukcesu i inny model obrony.
  • Hacktywizm IT vs OT: w IT presja to głównie dostępność i reputacja; w OT dochodzi ryzyko procesowe (parametry, bezpieczeństwo operacji). Wspólne ostrzeżenia pokazują, że część aktorów próbuje „grać” na obu polach, choć często robi to oportunistycznie i bez głębokiej wiedzy domenowej.

Podsumowanie / kluczowe wnioski

  1. UK (styczeń 2026) sygnalizuje, że prorosyjskie grupy hacktywistyczne nie zniknęły – kampanie DDoS nadal uderzają w organizacje publiczne i usługi kluczowe.
  2. NoName057(16) + DDoSia to przykład skalowalnego, społecznościowego modelu nękania usług, który potrafi wrócić nawet po działaniach służb.
  3. Obrona to przede wszystkim odporność (architektura, upstream, procedury), a nie „jeden magiczny produkt”.
  4. Organizacje z komponentem OT/ICS powinny zakładać, że „hacktywizm” może przerodzić się w oportunistyczne wejścia przez zdalny dostęp (np. VNC) – i zamknąć te ścieżki priorytetowo.

Źródła / bibliografia

  1. BleepingComputer – ostrzeżenie UK o trwających atakach i NoName057(16)/DDoSia (19 stycznia 2026). (BleepingComputer)
  2. The Register – kontekst i nacisk na ryzyko dla usług publicznych i CNI (19 stycznia 2026). (theregister.com)
  3. The Record (Recorded Future News) – podsumowanie ostrzeżenia NCSC i odniesienie do grudniowych advisory partnerów (20 stycznia 2026). (The Record from Recorded Future)
  4. Joint Cybersecurity Advisory AA25-343A (PDF, m.in. CISA/FBI i partnerzy) – TTP: VNC, skanowanie, password spraying, sektory: woda/żywność/energia, grupy CARR/NoName057(16)/Sector16/Z-Pentest. (ic3.gov)
  5. NCSC Annual Review 2025 (PDF) – trend wzrostu hacktywizmu powiązanego z napięciami geopolitycznymi i większa nieprzewidywalność celowania. (NCSC)