Archiwa: Security News - Strona 231 z 297

HPE łata krytyczną lukę RCE w OneView. Co muszą zrobić administratorzy już dziś?

Wprowadzenie do problemu / definicja luki

Hewlett Packard Enterprise (HPE) opublikowało poprawki dla krytycznej luki zdalnego wykonania kodu (RCE) w oprogramowaniu HPE OneView – centralnej platformie do zarządzania infrastrukturą (serwery, pamięci, sieć). Luka otrzymała identyfikator CVE-2025-37164 i ocenę maksymalną CVSS 10.0 (bez uwierzytelnienia, atak zdalny, pełny wpływ na poufność/spójność/dostępność).

W skrócie

Produkt: HPE OneView (wielowydaniowe wersje poniżej 11.0).
CVE: CVE-2025-37164, CVSS: 10.0 (maks.).
Wektor: zdalny, bez uwierzytelnienia, prowadzi do RCE.
Status: poprawki dostępne; brak obejść/mitigacji poza aktualizacją.
Działanie: natychmiastowa aktualizacja do najnowszej wersji/instalacja hotfixów HPE.

Kontekst / historia / powiązania

HPE OneView bywa krytycznym elementem w środowiskach data center i chmur prywatnych. W 2025 r. HPE publikowało już kilka istotnych biuletynów bezpieczeństwa (m.in. StoreOnce oraz komponenty OneView), jednak CVE-2025-37164 jest pierwszym przypadkiem w tym roku z maksymalnym scoringiem dla tego produktu. O luce poinformowały równolegle renomowane serwisy i dostawcy usług bezpieczeństwa.

Analiza techniczna / szczegóły luki

Charakter podatności: błąd umożliwiający zdalne wykonanie dowolnego kodu w kontekście usługi aplikacyjnej OneView. NVD klasyfikuje go w kategorii CWE-94 (Improper Control of Code Generation).
Zakres wersji: zgodnie z analizą branżową, narażone są wydania < 11.0, w tym linia 5.20–10.20, o ile nie zastosowano dedykowanych hotfixów (dla wirtualnego appliance i HPE Synergy). Dokładny zakres i linki do łatek znajdują się w biuletynie HPE.
Warunki ataku: atak zdalny, bez interakcji użytkownika i bez uwierzytelnienia; skutkuje pełnym kompromisem aplikacji zarządzającej, a w konsekwencji potencjalnie całej infrastruktury podłączonej do OneView.

Praktyczne konsekwencje / ryzyko

Udane wykorzystanie CVE-2025-37164 może pozwolić napastnikowi na:

przejęcie panelu zarządzania OneView;
eskalację do operacji na serwerach, zasobach pamięci i sieciach zarządzanych przez OneView;
pełny dostęp do danych konfiguracyjnych oraz możliwość wstrzyknięcia złośliwych obrazów/konfiguracji w skali całego klastra.
Ze względu na brak wymogu uwierzytelnienia, luka jest wysoce robakowalna w środowiskach o odsłoniętym interfejsie.

Rekomendacje operacyjne / co zrobić teraz

Natychmiastowa aktualizacja do HPE OneView 11.0 (lub nowszej, jeśli dostępna) albo instalacja najnowszych hotfixów dla posiadanej gałęzi (appliance / HPE Synergy) zgodnie z biuletynem HPE.
Brak obejść: HPE i niezależne źródła wskazują, że nie ma skutecznych mitigacji poza patchowaniem.
Higiena ekspozycji: natychmiast ogranicz dostęp do interfejsów OneView (segmentacja, ACL, VPN, IP allowlist), zablokuj dostęp z sieci publicznej.
Detekcja/IR:
- przegląd logów OneView i systemów zależnych pod kątem nietypowych żądań/akcji administracyjnych;
- w razie opóźnionej aktualizacji – rozważ reset zaufania (zmiana poświadczeń, regeneracja certyfikatów, weryfikacja integralności obrazów firmware).
Skany aktywów: użyj skanera zasobów/VM do identyfikacji hostów z wersjami < 11.0 i automatyzuj remediację (np. playbook Ansible). Wskazówki dot. detekcji wersji i zgodności publikują również firmy security.

Różnice / porównania z innymi przypadkami

W 2025 r. HPE łatało także inne krytyczne błędy (np. w StoreOnce), ale nie wszystkie miały wektor PR:N/UI:N/AV:N prowadzący do natychmiastowego RCE bez uwierzytelnienia. CVE-2025-37164 jest przez to priorytetem 1 – porównawczo bardziej ryzykownym niż luki wymagające uwierzytelnienia czy interakcji.

Podsumowanie / kluczowe wnioski

CVE-2025-37164 (CVSS 10.0) w HPE OneView to krytyczna podatność umożliwiająca zdalne RCE bez logowania.
Jedyną skuteczną obroną jest aktualizacja/hotfix – działaj natychmiast w środowiskach produkcyjnych.
Ogranicz ekspozycję interfejsów zarządzających i przeprowadź przegląd logów/konfiguracji pod kątem nadużyć.

Źródła / bibliografia

SecurityWeek: „HPE Patches Critical Flaw in IT Infrastructure Management Software” (18 grudnia 2025). (SecurityWeek)
HPE Security Bulletin: „HPE OneView Software – Remote Code Execution (CVE-2025-37164)” (grudzień 2025). (support.hpe.com)
NVD (NIST): karta CVE-2025-37164, CVSS, CWE-94. (nvd.nist.gov)
Rapid7: „CVE-2025-37164 – unauthenticated RCE affecting HPE OneView” (grudzień 2025). (Rapid7)
BleepingComputer: „HPE warns of maximum severity RCE flaw in OneView software” (grudzień 2025). (BleepingComputer)

UEFI: błąd w płytach głównych Asrock, Asus, Gigabyte i MSI umożliwia ataki DMA we wczesnym rozruchu

Wprowadzenie do problemu / definicja luki

W płytach głównych wielu wiodących producentów (ASRock, Asus, Gigabyte, MSI) wykryto podatność umożliwiającą ataki DMA na bardzo wczesnym etapie rozruchu (pre-boot). Choć firmware sygnalizuje aktywne zabezpieczenie DMA, w rzeczywistości IOMMU nie jest poprawnie inicjalizowane do momentu tuż przed przekazaniem kontroli systemowi operacyjnemu. W efekcie złośliwe urządzenie PCIe z dostępem fizycznym może czytać/pisać pamięć przed startem OS i jego mechanizmów ochronnych.

W skrócie

Dotyczy: wybranych modeli płyt głównych ASRock, Asus, Gigabyte, MSI. Inni dostawcy firmware (AMI, Insyde, Phoenix), producenci CPU (Intel, AMD) i Supermicro zgłaszają „nie dotyczy” w ramach tego problemu.
Identyfikatory: m.in. CVE-2025-11901, CVE-2025-14302, CVE-2025-14303, CVE-2025-14304 (różne warianty u poszczególnych vendorów).
Wektor ataku: fizyczny dostęp i wpięcie złośliwego urządzenia PCIe (np. karta z DMA).
Skutki: odczyt/zapis pamięci w fazie pre-boot, możliwość pozyskania tajnych danych i wstrzyknięcia kodu przed rozruchem.
Odkrycie i koordynacja: badacze Riot Games; koordynacja przez CERT/CC (Carnegie Mellon).
Status poprawek: producenci publikują aktualizacje BIOS/UEFI; w przypadku Gigabyte dostępne dla wielu rodzin (Intel 600/700/800; AMD 600/800; TRX50 zapowiedziane na Q1 2026).

Kontekst / historia / powiązania

CERT/CC opublikował notę VU#382314 17 grudnia 2025 r., dokumentując problem i status dostawców. Wpisy producentów płyt oraz wpisy NVD/CVE uszczegóławiają, które serie są objęte (np. Asus: Z490–Z790 i W790) oraz jakie CVE przypisano poszczególnym wariantom (np. MSI: CVE-2025-14303). Wykrycie przez zespół Riot ma także konsekwencje dla antycheatów – dziura podważała zaufanie do „Pre-Boot DMA Protection”, a Riot zapowiedział egzekwowanie aktualizacji firmware u graczy.

Analiza techniczna / szczegóły luki

Mechanizm Pre-Boot DMA Protection polega na użyciu IOMMU do izolacji urządzeń DMA już podczas rozruchu. W dotkniętych implementacjach UEFI występuje rozjazd między raportem a stanem faktycznym: firmware twierdzi, że ochrona DMA jest aktywna, ale IOMMU nie jest w pełni skonfigurowane aż do bardzo późnego etapu rozruchu. Ta „luka czasowa” pozwala urządzeniu PCIe na dostęp do pamięci fizycznej (R/W) przed inicjalizacją zabezpieczeń OS, co klasyfikowane jest jako CWE-693: Protection Mechanism Failure.

W przypadku MSI błąd ujęto właśnie jako Protection Mechanism Failure (CVE-2025-14303) – niepoprawne włączenie IOMMU umożliwia nieautoryzowany DMA w fazie pre-boot.

Praktyczne konsekwencje / ryzyko

Wymóg fizycznego dostępu ogranicza skalę ataków, ale ryzyko jest realne w środowiskach o podwyższonym zagrożeniu (colo, laboratoria, stanowiska serwisowe, stanowiska VIP), gdzie złośliwe peryferia mogą zostać dyskretnie podłączone.
Pre-boot code injection podważa integralność łańcucha rozruchu i może umożliwić trwałe ominięcie kontroli bezpieczeństwa na poziomie OS/hypervisora, a w środowiskach wirtualnych wpływać na izolację i delegację zaufania.
Ekosystem gier/anticheat: luka otwierała drogę do sprzętowych cheatów działających poza zasięgiem typowych detektorów; wydawcy mogą wymagać aktualizacji BIOS/UEFI.

Rekomendacje operacyjne / co zrobić teraz

Aktualizuj BIOS/UEFI do wersji oznaczonych jako naprawiające problem (sprawdź tabelę/biuletyn producenta swojej płyty).
- Gigabyte: poprawki opublikowane dla licznych rodzin (Intel 600/700/800; AMD 600/800), TRX50 – Q1 2026.
- MSI: śledź doradztwa bezpieczeństwa i wpis CVE-2025-14303.
- Asus: zaktualizuj BIOS dla serii Z490–Z790/W790 i w BIOS ustaw IOMMU DMA Protection na „Enable with Full Protection”.
Zweryfikuj ustawienia IOMMU/VT-d po aktualizacji (nie „Auto”). Jeśli producent przewiduje tryb „Full Protection” / „Enable during boot”, włącz go ręcznie.
Zarządzaj dostępem fizycznym: ogranicz możliwość podpinania urządzeń PCIe/Thunderbolt, stosuj plombowanie obudów, kontroluj porty w strefach o podwyższonym ryzyku.
Higiena łańcucha rozruchu: weryfikuj Secure Boot, rejestry zdarzeń rozruchu, integrację z EDR/HVCI; po krytycznych aktualizacjach przeprowadź rekonsyliację stanów bezpieczeństwa. (Zalecenie ogólne na bazie dobrych praktyk.)
Środowiska VDI/hiperwizora: po poprawkach wykonaj testy izolacji urządzeń passthrough i vIOMMU, bo błąd dotyczył właśnie wczesnej fazy inicjalizacji.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do wcześniejszych problemów Secure Boot/UEFI (np. klasyczne obejścia Secure Boot czy „Hydroph0bia”), obecna podatność nie polega na złamaniu podpisów czy list zaufania, lecz na oknie czasowym w inicjalizacji IOMMU – czyli ochrony przed DMA. To ataki sprzętowe z fizycznym wektorem, które uderzają w fundament izolacji pamięci zanim OS wystartuje.

Podsumowanie / kluczowe wnioski

Błąd w implementacjach UEFI sprawia, że IOMMU nie chroni pamięci wystarczająco wcześnie, co otwiera drogę do pre-boot DMA.
Ryzyko dotyczy wybranych płyt Asrock/Asus/Gigabyte/MSI; inni kluczowi dostawcy zgłosili brak wpływu.
Aktualizacje BIOS/UEFI już są dostępne (publikowane sukcesywnie) – po aktualizacji wymuś tryb pełnej ochrony IOMMU.
W środowiskach o niższym zaufaniu fizycznym priorytetem jest patching i polityki kontroli dostępu do portów/slotów.

Źródła / bibliografia

SecurityWeek: „UEFI Vulnerability in Major Motherboards Enables Early-Boot Attacks” (18 grudnia 2025). (SecurityWeek)
CERT/CC VU#382314: „Vulnerability in UEFI firmware modules prevents IOMMU initialization…” (17 grudnia 2025). (kb.cert.org)
Riot Games (Vanguard): „Security Update: Closing the Pre-Boot Gap” (grudzień 2025). (Riot Games)
Gigabyte – Security Advisory „Vulnerability in UEFI Firmware Modules Prevents IOMMU Initialization…” (17 grudnia 2025). (GIGABYTE)
NVD – CVE-2025-14303 (MSI) – opis i metryki. (nvd.nist.gov)

Zmasowane ataki password spraying na bramy VPN Cisco i Palo Alto (GlobalProtect)

Wprowadzenie do problemu / definicja luki

W połowie grudnia 2025 r. GreyNoise odnotował skoordynowaną kampanię automatycznych prób logowania (password spraying / credential stuffing) wymierzoną w bramy uwierzytelniania VPN dwóch producentów: Palo Alto Networks GlobalProtect oraz Cisco SSL VPN. Wnioski badaczy i doniesienia prasowe potwierdzają, że mamy do czynienia z falą zautomatyzowanych żądań logowania, a nie z wykorzystaniem konkretnej podatności w samym oprogramowaniu VPN.

W skrócie

Skala: ~1,7 mln sesji w ciągu 16 godzin przeciwko portalom GlobalProtect (11 grudnia), z ponad 10 tys. unikalnych adresów IP. Następnego dnia wzrost prób na Cisco SSL VPN do 1 273 unikalnych IP (znacznie powyżej typowej bazowej <200).
Infrastruktura sprawców: niemal cały ruch pochodził z zakresów 3xK GmbH (Niemcy); spójny odcisk TCP i identyczne wzorce ruchu wskazują na jedną kampanię pivotującą między platformami VPN.
Technika: powtarzalne kombinacje login/hasło, jednolity user-agent (Firefox / Windows 10), prawidłowe przepływy uwierzytelniania (w tym CSRF), co potwierdza automatyzację i brak exploitów.
To NIE jest AsyncOS 0-day: GreyNoise nie widzi związku z ujawnioną 17 grudnia kampanią na urządzenia Cisco Secure Email Gateway/SEWM (CVE-2025-20393).

Kontekst / historia / powiązania

Skoki ruchu na GlobalProtect obserwowano już wcześniej — m.in. 14–20 listopada (2,3 mln sesji skanowania) oraz 2 grudnia (7 000+ IP), przy czym w obu przypadkach źródłem była ta sama infrastruktura 3xK GmbH. Obecna fala z 11–12 grudnia wpisuje się w tę sekwencję i wygląda na kontynuację/inwentaryzację na większą skalę.

Analiza techniczna / szczegóły luki

Wejście: Publicznie dostępne portale uwierzytelniania GlobalProtect oraz Cisco SSL VPN.
Łańcuch żądania: żądania HTTP na endpointy logowania, obsługa tokenów CSRF, parametry login/password, silnie powtarzalne nagłówki i treści. Dla Cisco dominujący UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64); dla Palo Alto częsty UA Firefox — oba nietypowe dla zwykłych skanerów tego operatora.
TTPs:
- Password spraying / credential stuffing z użyciem puli standardowych/wyciekłych haseł.
- Jednolita sygnatura TCP/JA4t i ta sama przestrzeń IP → wysoka spójność narzędziowa.
- Pivot: po fali na GlobalProtect szybkie przełączenie na Cisco SSL VPN (w 24 h).
Brak oznak exploitów zero-day/n-day na bramach VPN; żądania imitują legalną ścieżkę logowania.

Praktyczne konsekwencje / ryzyko

Ryzyko przejęcia konta (zwłaszcza kont bez MFA, kont serwisowych, starszych kont SSO, kont z recyklingiem haseł).
Ryzyko DoS logicznego (lockouty i „wybicie” okienka logowania przy masowych próbach).
Ryzyko eskalacji: po jednorazowym wejściu przez VPN możliwe przełamanie segmentacji i lateral movement.
Fałszywe poczucie bezpieczeństwa: brak CVE ≠ brak incydentu — to kampania uwierzytelnieniowa, a nie exploitowa. Doniesienia branżowe i prasowe zgodnie to podkreślają.

Rekomendacje operacyjne / co zrobić teraz

Priorytet — edge & tożsamość:

Wymuś MFA (najlepiej phishing-resistant: FIDO2/Passkeys, WebAuthn) na portalach VPN/SSO; wyłącz fallbacki SMS/TOTP tam, gdzie to możliwe.
Blokuj źródła znane z kampanii (zakresy 3xK GmbH i konkretne IP z list GreyNoise; aktualne bloki/„tags” są publikowane przez GN).
Twarde polityki haseł + sprawdzanie przeciw wyciekom (HIBP/CrackStation, itp.), rotation tylko ryzyko-based, zakaz recyklingu.
Ogranicz powierzchnię:
- dostęp do portali wyłącznie z zaufanych AS/geo/VPN klienta (geo-fencing, allow-list),
- CAPTCHA / rate-limiting / tar-pit na formularzach logowania,
- ukryj portale za IdP z federation only i conditional access.
Monitoring i detekcja:
- reguły UEBA/behavioral na anomalne login bursts i UA fingerprint opisany przez GN,
- alerty na wiele nieudanych logowań z wielu IP do jednego konta,
- korelacja z logami GlobalProtect/Cisco SSL VPN i SIEM.
Higiena kont: wyłącz/stale audytuj konta serwisowe, narzuć MFA i długie hasła; minimalizuj scope i privs.
Playbook IR: gotowe runbooki blokad, wymuszenia resetów po próbach spraying, komunikacja do użytkowników.
Oddzielny wątek: AsyncOS (CVE-2025-20393) — jeśli masz Cisco SEG/SEWM, zastosuj tymczasowe obejścia i zalecenia Cisco, bo to niezależna, aktywnie wykorzystywana 0-day na inny produkt.

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

Obecna kampania (VPN): zautomatyzowane loginy bez exploitów; cel — odkryć słabe hasła/konta bez MFA w GlobalProtect/Cisco SSL VPN.
AsyncOS 0-day (CVE-2025-20393): wykorzystywana luka RCE z persystencją (AquaShell/AquaTunnel/Chisel) na Secure Email Gateway/SEWM, wymagająca specyficznej konfiguracji (Spam Quarantine wystawione do Internetu). Inny wektor, inne systemy.

Podsumowanie / kluczowe wnioski

Ataki na warstwę uwierzytelniania bram VPN znów przyspieszyły — tym razem w formie skoordynowanej kampanii, która w 24 godziny przestawiła się z GlobalProtect na Cisco SSL VPN. Nie potrzebujesz CVE, by zostać zhakowanym: MFA, polityki haseł, geofencing i monitoring to dziś „must-have” na brzegu sieci. Jednocześnie nie mylmy tej fali z incydentami wokół AsyncOS — to dwa różne problemy, oba wymagające działania.

Źródła / bibliografia

GreyNoise: „Coordinated Credential-Based Campaign Targets Cisco and Palo Alto Networks VPN Gateways”, 17 grudnia 2025. (GreyNoise)
BleepingComputer: „New password spraying attacks target Cisco, PAN VPN gateways”, 18 grudnia 2025. (BleepingComputer)
Cisco Security Advisory: „Reports About Cyberattacks Against Cisco Secure Email and Web Manager” (CVE-2025-20393), 17 grudnia 2025. (Cisco)
Cisco Talos: „UAT-9686 actively targets Cisco Secure Email Gateway and Secure Email and Web Manager”, 17 grudnia 2025. (Cisco Talos Blog)
Cybersecurity Dive: „Surge of credential-based hacking targets Palo Alto Networks GlobalProtect portals…”, 18 grudnia 2025. (Cybersecurity Dive)

University of Sydney: wyciek danych studentów i pracowników – co wiemy [grudzień 2025]

Wprowadzenie do problemu / definicja luki

Uniwersytet w Sydney (University of Sydney, USYD) poinformował 18 grudnia 2025 r. o naruszeniu ochrony danych dotyczących obecnych i byłych pracowników, studentów oraz innych interesariuszy uczelni. Według pierwszych doniesień nieautoryzowany dostęp dotyczył plików przechowywanych w internetowym repozytorium kodu używanym do celów testowych IT, które zawierało informacje osobowe. Incydent został oficjalnie zakomunikowany społeczności akademickiej przez USYD.

W skrócie

Wektor: dostęp do online’owego repozytorium programistycznego (code repository) z plikami zawierającymi dane osobowe.
Zakres: różne szacunki – w doniesieniach medialnych pojawiają się liczby rzędu ~13 tys. oraz ~27 tys. rekordów/ osób; wstępne komunikaty uczelni wskazują na „historyczne dane” części społeczności. W chwili pisania trwają powiadomienia osób objętych incydentem.
Rodzaj danych: dane identyfikacyjne (np. imię, nazwisko, kontakt), potencjalnie informacje kadrowe i afiliacyjne; brak dowodów na publikację danych w sieci w momencie publikacji pierwszych materiałów.
Data ujawnienia: 18–19 grudnia 2025 (czasu lokalnego).

Kontekst / historia / powiązania

USYD zmagał się już wcześniej z kwestiami bezpieczeństwa informacji – w przeszłości raportowano incydent dotyczący podmiotów trzecich i wybranych studentów zagranicznych (charakter inny niż obecny). Również inne australijskie uczelnie doświadczały poważnych wycieków w 2025 r., co wpisuje się w trend rosnącej presji na sektor edukacji.

Analiza techniczna / szczegóły luki

Z dotychczas dostępnych informacji wynika, że atakujący uzyskali dostęp do „historycznych plików” w repozytorium kodu używanym przez IT do testów. Tego typu repozytoria – jeśli nie są rygorystycznie „odchudzane” z danych i właściwie kontrolowane (ACL, tokeny, rotacja kluczy, zasady CI/CD) – często zawierają:

zrzuty danych (fixtures) z realnymi rekordami,
pliki konfiguracyjne z danymi PII,
archiwalne paczki używane w testach regresyjnych,
pozostałości po migracjach i proof-of-concept.

Z punktu widzenia bezpieczeństwa aplikacji jest to klasyczna ekspozycja „test data / sample data leakage”. Najczęstsze błędy operacyjne to: brak klasyfikacji informacji w repozytoriach, słaba segmentacja oraz brak przeglądów zawartości przed publikacją do chmury/hostingu SaaS (np. publiczne mirrory, zbyt szerokie uprawnienia zespołów, tokeny developerskie). Doniesienia branżowe wskazują właśnie na nieautoryzowany dostęp do takiego repozytorium.

Praktyczne konsekwencje / ryzyko

Ryzyko ukierunkowanego phishingu i vishingu: kombinacja imion, nazwisk, ról/stanowisk, numerów kontaktowych i afiliacji ułatwia tworzenie wiarygodnych kampanii socjotechnicznych (np. „od IT/HR”, „dziekanat”).
Krzyżowanie z innymi wyciekami: dane z repozytoriów często zawierają historyczne zakresy (tu raportowane jako „historyczne dane”), co zwiększa szansę dopasowań w bazach przestępczych i rekonstrukcji profili.
Ryzyko dla procesów uczelni: wyciek danych kadrowych/historycznych może ułatwiać podszywanie się pod pracowników (BEC w uczelni), a także nadużycia uprawnień w systemach, jeśli ekspozycja obejmowała metadane techniczne.

Rekomendacje operacyjne / co zrobić teraz

Dla uczelni (SOC/IT Sec/Privacy):

Natychmiastowy purge zawartości testowych repozytoriów i wdrożenie data minimization for testing (syntetyczne dane, narzędzia typu TDM).
Przegląd tajemnic (secret scanning) i rotacja kluczy/ciasteczek serwisowych w całym łańcuchu CI/CD.
Repo hardening: prywatność domyślna, granularne ACL, wymuszenie SSO/MFA, branch protection, skan SAST/IAST dla artefaktów testowych.
Data discovery & classification także w systemach „pobocznych”: wiki, backlogi, dyski współdzielone, platformy kolaboracyjne.
Proaktywna komunikacja i wiarygodne powiadomienia, z jasnym zakresem danych i oknem czasowym, zsynchronizowane z organami nadzoru.

Dla osób potencjalnie dotkniętych (studenci, pracownicy, alumni):

Włącz/zweryfikuj MFA i resetuj hasła w usługach powiązanych z uczelnią;
Zwiększ czujność na phishing (szczególnie „IT/HR/Payroll”), weryfikuj prośby o dane lub przelewy dwoma kanałami;
Rozważ monitoring tożsamości / alerty kredytowe, jeśli oferowane;
Zgłaszaj podejrzane wiadomości do zespołu bezpieczeństwa uczelni;
Sprawdź dedykowane FAQ i kanały wsparcia USYD publikowane po incydencie.

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

Repozytoria kodu coraz częściej stają się źródłem wycieków PII – w przeciwieństwie do „klasycznych” naruszeń systemów produkcyjnych, ekspozycja wynika tu z błędnych praktyk Dev/Test.
W sektorze edukacyjnym w 2025 r. obserwowano kilka głośnych incydentów; skala raportowana przez media dla USYD (13–27 tys. osób) mieści się w widełkach zauważalnych w ostatnich kampaniach wymierzonych w uniwersytety, ale wektor „test repo” jest szczególnie pouczający operacyjnie.

Podsumowanie / kluczowe wnioski

Rdzeniem problemu nie był „zeroday” w systemie produkcyjnym, lecz niewłaściwe zarządzanie danymi w środowisku dewelopersko-testowym.
Największą dźwignią ograniczenia ryzyka będzie eliminacja realnych danych z testów, klasyfikacja informacji i egzekwowanie polityk bezpieczeństwa w repozytoriach.
Zakres incydentu jest wciąż doprecyzowywany – oficjalne komunikaty i kanały USYD należy traktować jako źródło referencyjne w sprawie powiadomień i oferty wsparcia.

Źródła / bibliografia

BleepingComputer: „University of Sydney suffers data breach exposing student and staff info” (19 grudnia 2025). (BleepingComputer)
University of Sydney – Notification of cyber and data breach (18 grudnia 2025). (sydney.edu.au)
University of Sydney – Cyber incident: support and FAQs (18–19 grudnia 2025). (sydney.edu.au)
CyberDaily: „Sydney University hacked, over 13,000 impacted” (grudzień 2025). (Cyber Daily)
The Australian (paywall): „University of Sydney cyber hack exposes 27,000 personal records” (grudzień 2025). (The Australian)
Bitdefender HotforSecurity: wcześniejszy incydent (innego typu) dotyczący USYD. (Bitdefender)

Uwaga redakcyjna: Różne media podają odmienne liczby osób dotkniętych incydentem. W tekście zaznaczyliśmy rozbieżność (ok. 13–27 tys.).

113 tys. osób dotkniętych wyciekiem danych w Richmond Behavioral Health Authority (Virginia)

Wprowadzenie do problemu / definicja luki

Publiczna jednostka ochrony zdrowia psychicznego Richmond Behavioral Health Authority (RBHA) z Richmond w stanie Wirginia poinformowała o poważnym naruszeniu bezpieczeństwa danych. Atakujący uzyskali nieuprawniony dostęp do systemów, wykradli dane ponad 113 000 osób i wdrożyli ransomware, co mogło zakłócić dostępność usług. Ujawnione informacje obejmują m.in. imiona i nazwiska, numery Social Security, dane finansowe oraz informacje medyczne (PHI).

W skrócie

Skala: 113 232 osób objętych naruszeniem (RBHA).
Linia czasu: nieautoryzowany dostęp wykryto około 30 września 2025 r.; następnie rozpoczęto dochodzenie i powiadomienia.
Zakres danych: PHI, SSN, możliwie numery paszportów i informacje o kontach finansowych.
Taktyka: kradzież danych + wdrożenie ransomware w sieci RBHA.
Podstawa prawna: obowiązki notyfikacyjne wg prawa Wirginii dla naruszeń danych medycznych.

Kontekst / historia / powiązania

RBHA to agencja publiczna świadcząca usługi z zakresu zdrowia psychicznego, leczenia uzależnień i wsparcia osób z niepełnosprawnościami na terenie miasta Richmond. W sektorze ochrony zdrowia w USA ataki ransomware i wycieki PHI pozostają trendem rosnącym – wpis RBHA pojawia się w doniesieniach branżowych oraz zestawieniach incydentów zdrowotnych.

Analiza techniczna / szczegóły luki

Wektor i przebieg: według RBHA i relacji branżowych, incydent polegał na nieautoryzowanym dostępie do systemów, następnie ekstrakcji danych i uruchomieniu ransomware. Taki łańcuch (data theft → encryption/impact) odzwierciedla obecny model „double-extortion”, gdzie wyciek jest dźwignią do wymuszenia okupu.

Kategorie danych objętych ryzykiem:

identyfikacyjne: imię i nazwisko, SSN, czasem numery paszportów;
finansowe: informacje o kontach;
medyczne: chronione informacje zdrowotne (PHI).
Te klasy danych znacząco zwiększają ryzyko kradzieży tożsamości i nadużyć finansowych, a w przypadku PHI – długotrwałego narażenia prywatności.

Skala: 113 232 rekordów – liczba raportowana w komunikatach i powiązana z wpisem na portalu naruszeń HHS (OCR).

Praktyczne konsekwencje / ryzyko

Ryzyko finansowe: wykorzystanie SSN i danych kont do fraudów (kredyty, wnioski podatkowe, przejęcia kont).
Ryzyko prywatności: ujawnienie PHI może prowadzić do stygmatyzacji, szantażu i naruszenia poufności leczenia.
Ryzyko operacyjne: ransomware może powodować przestoje w systemach rejestracji, EHR i teleopieki, wpływając na ciągłość usług publicznych.

Rekomendacje operacyjne / co zrobić teraz

Dla osób poszkodowanych:

Zamrożenie kredytu (credit freeze) w głównych biurach kredytowych oraz włączenie alertów oszustw.
Monitorowanie kont bankowych i polis; skonfigurowanie powiadomień transakcyjnych.
Weryfikacja wyciągów medycznych (Explanation of Benefits) pod kątem fikcyjnych świadczeń.
Zmiana haseł/rotacja, włączenie MFA wszędzie, gdzie to możliwe.
Zachowanie listów notyfikacyjnych i skorzystanie z oferowanego monitoringu tożsamości, jeśli zapewniono.

Dla organizacji zdrowotnych i JST (w tym RBHA i podobnych):

Segmentacja sieci oraz separacja systemów klinicznych od biurowych; wprowadzenie MFA + FIDO2 dla kont uprzywilejowanych.
Zarządzanie podatnościami: EDR/XDR z detekcją kradzieży danych (DLP), monitoring ruchu egress i blokady exfiltracji.
Kopia zapasowa 3-2-1 + testy odtwarzania; przechowywanie offline i immutable.
Plan IR zgodny z HIPAA Security Rule i NIST 800-61; przygotowane playbooki na double-extortion.
Zgodność i notyfikacje: raportowanie zgodnie z Va. Code § 32.1-127.1:05 (AG, Commissioner of Health, podmioty danych, rezydenci), dokumentacja działań naprawczych.

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

W ostatnich miesiącach odnotowano wiele incydentów w ochronie zdrowia (laboratoria, sieci klinik, dostawcy usług). Wspólny mianownik to ekfiltracja PHI i presja okupu. Przypadek RBHA wpisuje się w ten trend, łącząc kradzież danych z ransomware, ale wyróżnia się charakterem instytucji publicznej świadczącej usługi zdrowia psychicznego – co zwiększa wrażliwość wycieków i potencjalny impact społeczny.

Podsumowanie / kluczowe wnioski

Atak na RBHA to klasyczny scenariusz double-extortion: dostęp → exfiltracja → ransomware.
Ujawnione PHI + SSN + dane finansowe tworzą wysoki, długofalowy profil ryzyka dla obywateli.
Jednostki publiczne muszą wdrożyć kontrole „zero-trust”, silną segmentację, DLP i gotowość IR.
Z perspektywy compliance, kluczowe są sprawne notyfikacje zgodnie z prawem Wirginii i HIPAA oraz transparentna komunikacja z pacjentami.

Źródła / bibliografia

SecurityWeek: „113,000 Impacted by Data Breach at Virginia Mental Health Authority” – główne fakty o kradzieży danych i wdrożeniu ransomware. (SecurityWeek)
Comparitech: zgłoszenie 113 232 osób i kategorie danych, odniesienie do rejestru HHS. (Comparitech)
HIPAA Journal: oś czasu zdarzeń (~30 września 2025 r. wykrycie) i rekomendacje dla poszkodowanych. (hipaajournal.com)
Prawo Wirginii: Va. Code § 32.1-127.1:05 – Breach of medical information notification. (law.lis.virginia.gov)

Nowa grupa hakerska powiązana z Chinami szpiegowała rządy w Azji Południowo-Wschodniej i Japonii

Wprowadzenie do problemu / definicja luki

Badacze ESET ujawnili nową, wcześniej nieudokumentowaną grupę APT powiązaną z Chinami, którą nazwali LongNosedGoblin. Zespół ten ma prowadzić ukierunkowane operacje cyberszpiegowskie wobec instytucji rządowych w krajach Azji Południowo-Wschodniej oraz w Japonii. Charakterystyczną techniką napastników jest nadużywanie Zasad grupy (Windows Group Policy) do rozsyłania i utrzymywania narzędzi szpiegowskich w zainfekowanych domenach. Informację potwierdziły branżowe media, w tym Recorded Future News (The Record).

W skrócie

Ofiary: instytucje rządowe w regionie ASEAN oraz w Japonii.
Atrybucja: grupa APT LongNosedGoblin, powiązana z ekosystemem cyberoperacji ChRL.
Kluczowa technika: dystrybucja złośliwych komponentów przez Group Policy (GPO) w domenie Windows.
Aktywność: co najmniej od 2023 r.; aktywna kampania potwierdzona w grudniu 2025 r.

Kontekst / historia / powiązania

Cyberszpiegostwo sponsorowane przez państwo chińskie od lat koncentruje się na administracji publicznej i sektorach strategicznych w Azji. W 2025 r. odnotowano szereg operacji PRC-nexus wymierzonych w administrację i dyplomację regionu, co potwierdzają m.in. bieżące raporty i przeglądy trendów (Mandiant/Google Cloud oraz publikacje branżowe). Na tym tle pojawienie się LongNosedGoblin wpisuje się w szerszy wzorzec stałej presji wywiadowczej.

Analiza techniczna / szczegóły kampanii

Wejście i rozprzestrzenianie: według ESET, po uzyskaniu wstępnego dostępu napastnicy wykorzystują mechanizmy Group Policy do zautomatyzowanego wdrażania ładunków w całej domenie. Taki model umożliwia trwałą i „cichą” dystrybucję komponentów, zgodną z legalnym przepływem administracyjnym w środowiskach Windows.

Komunikacja i utrzymanie dostępu: doniesienia branżowe wskazują, że w niektórych przypadkach wykorzystywana jest infrastruktura chmurowa i techniki utrzymywania C2 typowe dla operacji APT z regionu Chin, co utrudnia blokowanie i atrybucję. (Wniosek syntetyzowany na podstawie materiałów o kampanii i szerszych przeglądów PRC-nexus w 2025 r.).

Celowanie: priorytetowo traktowane są resorty rządowe (ministerstwa, urzędy centralne) w wybranych państwach Azji Południowo-Wschodniej oraz w Japonii, co sugeruje cele czysto wywiadowcze (kradzież dokumentów, planów, notatek dyplomatycznych).

Mapowanie do MITRE ATT&CK (wybrane techniki):

T1484.001 – Domain Policy Modification (GPO) – modyfikacja/wykorzystanie zasad domenowych do egzekucji payloadów.
T1059 / T1053 – Command & Scripting Interpreter / Scheduled Task – egzekucja i utrzymanie harmonogramu na hostach (typowy wzorzec przy GPO). (Wniosek na bazie opisu nadużycia GPO).

Praktyczne konsekwencje / ryzyko

Szybka, domenowa propagacja: nadużycie GPO pozwala w krótkim czasie objąć zasięgiem całą organizację – bez wzbudzania podejrzeń użytkowników.
Trudna detekcja: działania są wykonywane w ramach „normalnych” mechanizmów AD, co utrudnia wykrywanie sygnaturowe i sprzyja długotrwałej obecności napastnika.
Ryzyko wycieku wrażliwych danych (korespondencja dyplomatyczna, dokumenty rządowe), co może mieć skutki geopolityczne i negocjacyjne.

Rekomendacje operacyjne / co zrobić teraz

Włącz i egzekwuj auditing GPO/AD: szczegółowy monitoring zmian w Group Policy Objects (kto/ kiedy/ co) + alertowanie na tworzenie/edycję skryptów logon/logoff, startup/shutdown.
Zasada najmniejszych uprawnień dla GPO: ogranicz administracyjne uprawnienia do tworzenia/edycji GPO, segmentuj role, stosuj „just-in-time” i „just-enough admin”.
Telemetria hostowa i Sysmon: rejestrowanie procesów wyzwalanych przez GPO (np. powershell.exe, cmd.exe, mshta.exe), korelacja z czasem aktualizacji zasad. (Good practice wynikająca z opisanego TTP).
Kontrola wykonywania skryptów: AppLocker / WDAC dla skryptów i binariów LoLBin, polityki ASR blokujące uruchamianie podejrzanych interpreterów przez GPO. (Wniosek operacyjny na bazie techniki).
Hunting w AD: przegląd niedawno zmienionych GPO i powiązanych sysvol (szczególnie skrypty, pliki MSI/EXE/DLL), analiza nietypowych uprawnień na obiektach.
Zewnętrzny traffic & C2: inspekcja ruchu do usług chmurowych i nietypowych domen jako potencjalnego C2, z uwzględnieniem wzorców PRC-nexus opisywanych w 2025 r.
Playbook IR pod GPO-abuse: przygotuj procedury szybkiego „roll-backu” złośliwych zasad, izolacji kontrolerów domeny oraz rotacji poświadczeń.

Różnice / porównania z innymi przypadkami

Nadużywanie Group Policy było dotąd rzadziej opisywanym wektorem masowej dystrybucji w ramach operacji APT – częściej widzieliśmy techniki takie jak side-loading czy złośliwe aktualizacje oprogramowania. LongNosedGoblin wyróżnia się systemowym wykorzystaniem GPO jako kanału wdrożeniowego, co upodabnia atak do wewnętrznej operacji administracyjnej i znacząco utrudnia detekcję oraz triage.

Podsumowanie / kluczowe wnioski

LongNosedGoblin to świeżo udokumentowana, China-aligned APT, która celuje w rządy regionu ASEAN i Japonię.
Jej znakiem rozpoznawczym jest nadużywanie Windows Group Policy do dystrybucji narzędzi szpiegowskich w domenie.
Obrona wymaga precyzyjnego monitoringu i kontroli zmian GPO, łączenia telemetrii AD/host/C2 oraz gotowych playbooków IR.

Źródła / bibliografia

ESET WeLiveSecurity: „LongNosedGoblin tries to sniff out governmental affairs in Southeast Asia and Japan” (19 grudnia 2025). (welivesecurity.com)
Help Net Security: „Group Policy abuse reveals China-aligned espionage group targeting governments” (18–19 grudnia 2025). (Help Net Security)
The Record (Recorded Future News): „New China-linked hacker group spies on governments in Southeast Asia, Japan” (18–19 grudnia 2025). (The Record from Recorded Future)
The Hacker News: „China-Aligned Threat Group Uses Windows Group Policy to Deploy Espionage Malware” (19 grudnia 2025). (The Hacker News)
Google Cloud Threat Intelligence (kontekst PRC-nexus 2025): „PRC-Nexus Espionage Campaign … targets diplomats” (25 sierpnia 2025). (Google Cloud)

Cisco ostrzega przed aktywnie wykorzystywanym 0-dayem w AsyncOS (CVE-2025-20393) — ataki na Secure Email Gateway/SEWM

Wprowadzenie do problemu / definicja luki

Cisco poinformowało o krytycznej luce dnia zerowego w AsyncOS dla urządzeń Cisco Secure Email Gateway (SEG) oraz Cisco Secure Email and Web Manager (SEWM). Błąd oznaczony jako CVE-2025-20393 ma CVSS 10.0 i umożliwia zdalne wykonanie komend z uprawnieniami roota na podatnym urządzeniu. Wykorzystanie jest obserwowane „na żywo” w ograniczonej puli urządzeń o nietypowej (niestandardowej) ekspozycji do Internetu.

W skrócie

Co: zdalne RCE przez niewłaściwą walidację danych wejściowych w AsyncOS (CWE-20).
Kogo dotyczy: urządzeń SEG/SEWM z włączonym i do Internetu wystawionym modułem Spam Quarantine (nie jest domyślnie aktywny).
Kto atakuje: grupa o powiązaniach z Chinami śledzona jako UAT-9686.
Status łatek: brak patcha w momencie publikacji; CISA dodała CVE do KEV z terminem działań do 24 grudnia 2025 dla agencji federalnych USA.

Kontekst / historia / powiązania

Kampania została zauważona przez Cisco 10 grudnia 2025 r., a aktywność atakujących sięga końca listopada. Równolegle GreyNoise zarejestrował zautomatyzowane kampanie logowań (password spraying/credential stuffing) wymierzone w VPN-y (Palo Alto GlobalProtect i Cisco SSL VPN) — to inny, niezależny wątek niż 0-day w AsyncOS, ale pokazuje presję na urządzenia brzegowe.

Analiza techniczna / szczegóły luki

Identyfikator: CVE-2025-20393
Wektor: zdalny, bez uwierzytelnienia, niski nakład pracy; wpływ na C/I/A: High (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).
Warunki eksploatacji:
- Funkcja Spam Quarantine jest włączona.
- Interfejs Spam Quarantine jest osiągalny z Internetu (ekspozycja).
- Dotyczy zarówno wydań fizycznych, jak i wirtualnych SEG/SEWM.
Łańcuch po włamaniu (observed TTPs):
- Wgranie lekkiego backdoora „AquaShell” (Python) podsłuchującego pasywnie na żądania HTTP POST i wykonującego zakodowane polecenia w powłoce systemu.
- Użycie narzędzi tunelujących AquaTunnel/ReverseSSH oraz Chisel w celu trwałego dostępu i pivotu, a także AquaPurge do „czyszczenia” logów.
- W Talosie odnotowano osadzenie AquaShell m.in. w pliku /data/web/euq_webui/htdocs/index.py.

Praktyczne konsekwencje / ryzyko

Przejęcie pełnej kontroli nad urządzeniem SEG/SEWM (root), a więc ryzyko podmiany polityk, manipulacji pocztą, eksfiltracji danych, pivotu do sieci wewnętrznej oraz ukrywania śladów (AquaPurge).
Urządzenia SEG/SEWM często pełnią centralne funkcje zarządcze i kwarantanny — ich kompromitacja ma ponadprzeciętny wpływ na łańcuch dostarczania poczty i bezpieczeństwo całej organizacji.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast:

Oceń ekspozycję: sprawdź, czy Spam Quarantine jest włączony oraz czy interfejs jest osiągalny z Internetu; jeśli tak — odetnij go od Internetu (ACL/WAF/VPN), najlepiej umieść za firewallem i ogranicz ruch do zaufanych hostów.
Oddziel interfejsy: rozdziel interfejsy mail i management; wyłącz HTTP dla portalu administratora (pozostaw wyłącznie HTTPS z mTLS/VPN).
Twarde uwierzytelnianie: wymuś silne metody SSO/MFA (np. SAML/LDAP), wyłącz konta domyślne, zmień hasła adminów.
Higiena usług: wyłącz nieużywane usługi, przeglądnij konfigurację AsyncOS pod kątem niestandardowych ustawień i ekspozycji.
Monitoring i IR: przeanalizuj logi WWW/SSH pod kątem nieoczekiwanych żądań POST oraz tuneli; skorzystaj z IOC-ów Talosa (hashe, IP) i gotowych reguł/telemetrii w EDR/NDR. W razie potwierdzenia kompromitacji przeinstaluj/odbuduj urządzenie (jedyna pewna metoda usunięcia trwałości).

W najbliższych dniach:

Śledź aktualizacje Cisco PSIRT i wdrożenie ewentualnych łat natychmiast po publikacji; agencje federalne w USA mają termin działań do 24 grudnia 2025 r. (KEV).
Jeśli Twoja organizacja widzi korelację z aktywnością brute-force na VPN-ach, zastosuj ochronę kont (MFA, blokady, geo, prędkości), ale pamiętaj, że to oddzielna kampania od 0-daya w AsyncOS.

Jak sprawdzić ustawienie Spam Quarantine (skrót): w GUI przejdź do Network → IP Interfaces → [interfejs] i sprawdź, czy Spam Quarantine jest zaznaczony (SEG); analogicznie dla SEWM. Jeśli zaznaczony, nie powinien być dostępny z Internetu.

Różnice / porównania z innymi przypadkami

AsyncOS 0-day (CVE-2025-20393) wymaga specyficznej konfiguracji (włączony i wystawiony Spam Quarantine). To odróżnia go od wielu „remote-by-default” błędów w brzegowych urządzeniach.
Kampania GreyNoise na VPN-y to automatyczne próby logowania (credential-based), a nie exploit luki — inna technika, inny cel, choć ofiary mogą się pokrywać (organizacje z dużą ekspozycją usług).

Podsumowanie / kluczowe wnioski

Mamy do czynienia z aktywnie wykorzystywanym 0-dayem o maksymalnej krytyczności, wykorzystywanym przez UAT-9686.
Brak łat oznacza, że architektura i ekspozycja decydują dziś o bezpieczeństwie: odetnij Spam Quarantine od Internetu, wzmocnij dostęp administracyjny, monitoruj pod kątem AquaShell/AquaTunnel/Chisel.
Potwierdzona kompromitacja ⇒ rebuild urządzenia.
Śledź komunikaty Cisco/Talos i wpis w KEV; działaj przed terminem compliance.

Źródła / bibliografia

Cisco Talos: „UAT-9686 actively targets Cisco Secure Email Gateway and Secure Email and Web Manager” (szczegóły AquaShell/AquaTunnel/Chisel, IOC). (Cisco Talos Blog)
NVD (CVE-2025-20393): opis CVE, wektor CVSS, odnośnik do KEV i advisory Cisco. (NVD)
Cisco PSIRT Advisory (AsyncOS / SEG / SEWM; warunki eksploatacji, zalecenia). (sec.cloudapps.cisco.com)
The Hacker News: podsumowanie, warunki „Spam Quarantine + ekspozycja”, zalecenia tymczasowe. (The Hacker News)
GreyNoise: „Coordinated Credential-Based Campaign Targets Cisco and Palo Alto Networks VPN Gateways” (kampania loginów, niezależna od 0-daya). (greynoise.io)