Archiwa: VPN - Strona 66 z 81 - Security Bez Tabu

Akira ransomware: ponad 250 zaatakowanych organizacji, nowe techniki (SonicWall CVE-2024-40766, Nutanix AHV) i wskazówki obrony [aktualizacja XI 2025]

Wprowadzenie do problemu / definicja luki

Akira to operacja ransomware-as-a-service aktywna od marca 2023 r., stosująca podwójną presję (exfiltracja danych + szyfrowanie). Najnowsza, zaktualizowana 13 listopada 2025 r. porada #StopRansomware (FBI/CISA/DC3/HHS i partnerzy UE) ostrzega, że aktorzy Akira nasilili ataki na infrastrukturę krytyczną oraz rozszerzyli cele szyfrowania na Nutanix AHV (wcześniej: VMware ESXi i Hyper-V), często po włamaniu przez urządzenia brzegowe SonicWall z wykorzystaniem CVE-2024-40766 oraz luk w Veeam Backup & Replication. Porada szacuje też, że do końca września 2025 r. Akira zgarnęła ~244 mln USD w okupach.

W skrócie

  • Skala: od początku działalności >250 celów (stan na I 2024 r.; dziś licznik jest wyższy), a łączne wpływy z okupów sięgnęły ~244 mln USD (IX 2025).
  • Wejście: nadużycia SSL VPN / SonicWall (CVE-2024-40766), słabe/MFA-less VPN, wycieki/kradzież haseł i OTP seedów, luki w Veeam; okazjonalnie spear-phishing i RDP/SSH.
  • Nowości 2025: szyfrowanie Nutanix AHV VMDK, obejście ochron VMDK i kradzież NTDS.dit, częstsze użycie AnyDesk/LogMeIn i tuneli Ngrok do C2, BYOVD do wyłączania EDR/AV.
  • Kryptografia/warianty: ewolucja do Akira_v2 (Linux/ESXi), epizodyczny „Megazord” (Rust, rozszerzenie .powerranges), u części wariantów ChaCha8 dla szybkości.

Kontekst / historia / powiązania

W 2023 r. Akira startowała na Windows (rozszerzenie .akira), a od kwietnia 2023 r. pojawiły się warianty Linux/ESXi. W sierpniu 2023 r. obserwowano użycie Megazord (Rust). Raporty incident-response z 2023/2024 opisywały też „exfil-only” – wymuszanie okupu wyłącznie kradzionymi danymi bez ryzyka detekcji typowej dla masowego szyfrowania. W 2024 r. Cisco Talos notował przejście do ChaCha8 (pragmatyka: szybsze szyfrowanie). Akira ma też powiązania nomenklaturowe z kontynuacją ekosystemu Conti (AIV).

Analiza techniczna / szczegóły luki

Wektory wejścia (Initial Access)

  • VPN bez odpornych na phishing MFA oraz słabe hasła; password spraying narzędziami pokroju SharpDomainSpray.
  • SonicWall SSLVPN – CVE-2024-40766 (Improper Access Control) – dodane do CISA KEV IX 2024; nadal wykorzystywane w 2025 r. (niekiedy z błędami w konfiguracji LDAP/MFA i publicznym dostępem do Virtual Office).
  • Veeam Backup & Replication – m.in. CVE-2023-27532 i CVE-2024-40711 (deserializacja), używane do eskalacji i dostępu do backupów.
  • SSH / routery brzegowe (pivot po tunelowaniu), IAB (Initial Access Brokers).

Eskalacja, ruch boczny, C2

  • Tworzenie kont itadm i dodawanie do Administrators, zrzut NTDS.dit poprzez „podmianę” VMDK DC i montaż w nowej VM (następnie kradzież krbtgt/DA).
  • AnyDesk / LogMeIn dla utrzymania i maskowania; Ngrok do C2; Impacket (wmiexec).
  • BYOVD (np. sterownik Zemana AntiMalware) + PowerTool do zabijania EDR/AV.

Szyfrowanie i platformy wirtualizacji

  • ESXi i Hyper-V były celem od 2023 r.; w VI 2025 odnotowano Nutanix AHV (VMDK/AHV-disk). Ważne: nie jest to podatność Nutanixa – wektor to SonicWall, po czym atakujący szyfrują dyski VM.

Kryptografia / warianty

  • Akira (C++) – rozszerzenie .akira;
  • Megazord (Rust) – rozszerzenie .powerranges;
  • Akira_v2 / Linux – nowe rozszerzenia, optymalizacja (m.in. ChaCha8).

Praktyczne konsekwencje / ryzyko

  • Szybkie tempo ataków – w skrajnych przypadkach exfiltracja danych w kilka godzin od wejścia; dla SOC oznacza to krótkie MTTD/MTTR okna i konieczność monitoringu 24/7.
  • SMB pod presją – priorytetowe cele wg FBI/CISA to małe i średnie firmy, ale ucierpiały też duże podmioty z produkcji, edukacji, IT, ochrony zdrowia i finansów.
  • Ryzyko błędnej atrybucji – „Nutanix AHV” w nagłówkach to skutek, nie przyczyna; błędna komunikacja grozi nieadekwatnymi działaniami naprawczymi.

Rekomendacje operacyjne / co zrobić teraz

1) Redukcja ekspozycji

  • SonicWall: zweryfikuj i wdroż natychmiast poprawki CVE-2024-40766; ogranicz dostęp SSLVPN/Virtual Office do zaufanych sieci; wymuś phishing-resistant MFA (FIDO2/WebAuthn), wyłącz TOTP tam, gdzie to możliwe.
  • Veeam: załataj CVE-2023-27532 / CVE-2024-40711, odseparuj serwer kopii i repozytoria (air-gapped/immutable).
  • VPN: wymuś MFA odporną na phishing, deny-all na portale samoobsługowe, rotacja haseł/OTP seedów po incydentach (podejrzenie kradzieży tajników MFA).

2) Twardnienie AD / wirtualizacji

  • Kontrolery domen: LSA Protection, izolacja DC, monitoring dostępu do plików VMDK DC i prób montażu poza VM.
  • Hypervisor: audyt uprawnień do datastore, „two-person rule” dla operacji na dyskach VM, backupy immutable.

3) Detekcja (przykładowe reguły/Sigma i zapytania)

Windows (Sysmon/EDR):

title: Akira - BYOVD Zemana/PowerTool
logsource: { category: driver_load, product: windows }
detection:
  sel:
    ImageLoaded|endswith: '\zamguard64.sys'
  condition: sel
level: high
tags: [attack.defense_evasion,T1562.001]

Anomalie C2/Tunnel (Ngrok):

title: Suspicious Ngrok Tunnel
logsource: { category: network_connection, product: windows }
detection:
  sel:
    DestinationHostname|contains: 'ngrok'
  condition: sel
level: medium
tags: [attack.command_and_control,T1572]

WMI/Impacket:

title: Impacket wmiexec-like Behavior
logsource: { category: process_creation, product: windows }
detection:
  sel:
    CommandLine|contains|all:
      - 'wmic'
      - 'process call create'
  condition: sel
level: medium
tags: [attack.lateral_movement,T1021.001]

Splunk – szybki hunt „AnyDesk/LogMeIn po VPN”:

index=firewall (app=sslvpn OR app=vpn) | stats count by src_ip user
| join user [ search index=edr (process=AnyDesk.exe OR process=LogMeIn.exe) 
| stats earliest(_time) as firstSeen by user ]
| where firstSeen - _time < 3600

4) Reakcja i odzyskiwanie

  • Procedura „isolate-then-triage”, snapshoty/backupy offline, test odtwarzania co sprint.
  • Komunikacja kryzysowa, w tym analiza ryzyka publikacji danych (DLS) i notyfikacje prawne.
  • Zgłaszaj incydenty do CERT/CSIRT oraz IC3/CISA; stosuj listę kontrolną CPG.

Różnice / porównania z innymi przypadkami

  • LockBit: większy ekosystem i „franczyza”, ale obecnie pod presją organów ścigania; Akira nadrabia zwinnością, w 2024 r. była jedną z najczęściej spotykanych w IR/MDR (wg Sophos).
  • Clop: dominowało exfil-only na aplikacje web (MOVEit), Akira łączy exfiltrację z klasycznym „węzłem noża” (szyfrowanie VM i backupów).

Podsumowanie / kluczowe wnioski

  1. Edge first: SonicWall/SSLVPN i Veeam to w 2025 r. praktyczne „drzwi wejściowe”.
  2. Wirtualizacja pod ostrzałem: poza ESXi i Hyper-V atakujący skutecznie szyfrują dyski Nutanix AHV, co wymusza twardnienie warstwy hypervisora i datastore.
  3. Czas reakcji liczy się w godzinach – wdroż MDR/24×7 lub równoważne pokrycie.
  4. MFA odporna na phishing + rotacja tajników to dziś must-have.
  5. Nie wierz nagłówkom: „problem Nutanixa” to w istocie błąd/konfiguracja na brzegu, a dopiero potem wpływ na VM.

Źródła / bibliografia

  1. FBI/CISA/DC3/HHS – #StopRansomware: Akira Ransomware (aktualizacja 13.11.2025) – pełne TTP/IOC, nowe techniki (Ngrok, AnyDesk/LogMeIn), szyfrowanie Nutanix AHV, kwota okupu ~244,17 mln USD. (Internet Crime Complaint Center)
  2. Cisco Talos – „Akira ransomware continues to evolve” (ChaCha8, nowe rozszerzenia Linux). (Cisco Talos Blog)
  3. Sophos – „Akira, again: The ransomware that keeps on taking” (trend exfil-only jako presja bez szyfrowania). (Sophos News)
  4. Rapid7 – CVE-2024-40766 (SonicWall SSLVPN Improper Access Control) i ostrzeżenia dot. kampanii Akira na urządzeniach SonicWall. (Rapid7)
  5. Nutanix – wyjaśnienie: brak błędu w AHV; problem zaczyna się na urządzeniach brzegowych (SonicWall), a efektem jest szyfrowanie dysków VM. (nutanix.com)

Uwaga kontekstowa: liczba „>250 organizacji” pochodzi z raportów z początku 2024 r. (Arctic Wolf i komunikaty dot. pierwszej wersji porady FBI/CISA). Dzisiejsza skala jest większa; najnowszy dokument rządowy koncentruje się na kwocie okupu (~244 mln USD) i nowych technikach, zamiast podawać bieżący licznik ofiar.

SSA Holdings (Amarillo, TX) — incydent naruszenia danych z 15 września 2025 r.: co wiemy, ryzyko dla poszkodowanych i działania obronne

Wprowadzenie do problemu / definicja luki

SSA Holdings, LLC — podmiot z Amarillo (Teksas), działający jako apteka (m.in. „Amarillo Pharmacy”) — poinformował organy nadzorcze o incydencie bezpieczeństwa, w którym nieuprawniona osoba uzyskała dostęp do systemów i 15 września 2025 r. skopiowała pliki firmy. Analiza danych zakończyła się 24 października 2025 r., a zgłoszenie do prokuratora generalnego stanu Kalifornia opublikowano 13 listopada 2025 r. W listach do osób poszkodowanych spółka oferuje bezpłatny pakiet monitoringu tożsamości od Kroll. Źródła urzędowe potwierdzają daty i zakres reakcji, natomiast precyzyjny katalog atrybutów danych różni się w zależności od adresata powiadomienia.

W skrócie

  • Data zdarzenia: 15.09.2025 (skopiowanie plików po uzyskaniu dostępu do systemów).
  • Potwierdzenie obecności danych osobowych w plikach: 24.10.2025.
  • Zgłoszenie/regulatory: wpis w rejestrze naruszeń CA AG z datą publikacji 13.11.2025.
  • Profil firmy: podmiot medyczny/apteczny z Amarillo, TX (NPI z adresem 6010 S Western St, Amarillo).
  • Typy danych: listy notyfikacyjne używają placeholdera („<>”), co oznacza, że zakres różni się per odbiorca; źródła branżowe wskazują m.in. nazwiska i numery SSN (informacja wtórna, nie z listu urzędowego).
  • Wsparcie dla poszkodowanych: monitoring tożsamości Kroll (kredytowy, ubezpieczenie do 1 mln USD, konsultacje, odzyskiwanie tożsamości).

Kontekst / historia / powiązania

W 2025 r. sektor ochrony zdrowia i usług okołomedycznych pozostaje jednym z najczęściej atakowanych — z uwagi na wysoką wartość danych PII/PHI i rozproszoną infrastrukturę. Choć SSA Holdings formalnie nie ujawnił publicznie pełnej listy atrybutów, charakter działalności (apteka/świadczenia farmaceutyczne) i wzorce incydentów w branży zwiększają prawdopodobieństwo obecności w plikach danych identyfikacyjnych o wysokiej wrażliwości (np. SSN). Rejestr CA AG potwierdza harmonogram incydentu i notyfikacji, co jest zgodne z typowym cyklem IR (containment → forensics/triage → data mining → notyfikacje).

Uwaga o skali: serwis branżowy ClaimDepot podaje, że w samym Teksasie powiadomienia otrzymało 1 639 osób. To liczba wtórna (nie z dokumentu urzędowego) i może ulec zmianie w miarę aktualizacji rejestrów stanowych.

Analiza techniczna / szczegóły luki

List notyfikacyjny zdradza kilka kluczowych faktów o przebiegu incydentu:

  1. Nieuprawniony dostęp do „niektórych systemów” i aktywne skopiowanie plików jednego dnia (15.09). To silnie wskazuje na exfiltrację plikową po wcześniejszej kompromitacji konta/usługi (np. VPN, RDP, M365, serwer plików, EHR/PM). 2) Brak wzmianki o szyfrowaniu/ransomware w liście (co zwykle jest akcentowane), a nacisk na „acquired copies of certain files” sugeruje scenariusz data theft bez destrukcji. 3) Po zdarzeniu wdrożono monitoring tożsamości — organizacje często decydują się na tę ofertę, gdy w wektorze mogły znaleźć się SSN/PII.

Co mogło zawieść? (hipotezy IR oparte na wzorcach branżowych)

  • Kompromitacja poświadczeń (phishing MFA-fatigue, infostealer, reuse haseł) i pivot na zasoby plikowe.
  • Błędy w kontrolach DLP i brak reguł anomalii dla hurtowego kopiowania danych z udziałami SMB/SharePoint.
  • Niedomknięte EDR/telemetria dla serwerów plików (słabsza widoczność na NAS).
  • Brak segmentacji między strefą biurową a systemami przetwarzającymi dane wrażliwe.

Co sprawdzić w śledztwie (checklista Blue Team)

  • Korelacja logów AD/Entra ID (logon patterns, Impossible Travel, liczba tokenów refresh).
  • SMB telemetry/Windows Security/FSRM: duże wolumeny ReadFile/Create/Copy w krótkim oknie.
  • M365/Azure: FileDownloaded, SearchQueryPerformed, eDiscovery/Export.
  • VPN/NAC: niecodzienne ASN, profile urządzeń, brak zgodności postur.
  • EDR: procesy narzędzi do archiwizacji (7z, rar, winzip), skrypty PowerShell z Compress-Archive, nietypowe ścieżki temp.

Przykładowa reguła Sigma (wykrywanie masowego kopiowania do archiwum ZIP na hostach Windows):

title: Suspicious Bulk File Compression
id: 2b4a3f6c-8a1c-4f1f-9e3f-ssa-holdings-zip
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  sel_parent:
    ParentImage|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  sel_proc:
    Image|endswith:
      - '\7z.exe'
      - '\7za.exe'
      - '\winzip64.exe'
      - '\powershell.exe'
    CommandLine|contains:
      - 'Compress-Archive'
      - '.zip'
  condition: sel_parent and sel_proc
fields:
  - CommandLine
  - ParentCommandLine
  - Image
falsepositives:
  - Admin/backup tasks
level: high

Przykładowe kwerendy KQL (M365/Azure Audit)

AuditLogs
| where TimeGenerated between (datetime(2025-09-15) .. datetime(2025-09-16))
| where OperationName in ("FileDownloaded", "SearchQueryPerformed", "ExportCreated")
| summarize count(), FirstEvent=min(TimeGenerated), LastEvent=max(TimeGenerated) by UserId, OperationName, ClientIP

Praktyczne konsekwencje / ryzyko

  • Ryzyko kradzieży tożsamości (otwieranie kont kredytowych, fraud podatkowy), zwłaszcza jeśli wśród atrybutów były SSN — na co wskazują doniesienia branżowe.
  • Spear phishing/Smishing z użyciem prawdziwych danych identyfikacyjnych.
  • Wejście danych do obiegu brokerskiego (sprzedaż paczek PII w dark/neon).
  • Ryzyko wtórnych ataków na świadczeniodawców/ubezpieczycieli, jeśli w plikach znalazły się identyfikatory pacjentów (tu brak oficjalnego potwierdzenia typu PHI w rejestrze CA).

Rekomendacje operacyjne / co zrobić teraz

Dla osób poszkodowanych (praktyka + „gotowe komendy”)

  1. Włącz monitoring Kroll z listu notyfikacyjnego (adres portalu i numer członkowski w piśmie).
  2. Zamrożenie kredytu („security freeze”) w 3 biurach (Equifax, Experian, TransUnion).
  3. Alerty oszustwa (fraud alert) i ciągły przegląd raportów (AnnualCreditReport).
  4. Blokady kont w SSA („my Social Security”) i bankowości — jeżeli obserwujesz anomalię.
  5. Zachowaj kopię korespondencji — przydatne przy ewentualnych roszczeniach.

Przykładowe komendy do szybkiej weryfikacji wycieków haseł (lokalnie, bez ich ujawniania; Pwned Passwords k-Anonimity):

# Mac/Linux: sprawdź SHA1 hasła w k-anonimity (nie wysyłaj pełnego hash)
read -s -p "Hasło: " P; echo -n $P | shasum | awk '{print toupper($1)}' | \
  awk '{print substr($0,1,5)" "substr($0,6)}' | \
  while read prefix rest; do curl -s https://api.pwnedpasswords.com/range/$prefix | grep -i $rest; done

Dla zespołów bezpieczeństwa SSA Holdings (lub podmiotów podobnych)

  • EDR na serwerach plików / NAS telemetry + blokady exfilu (DLP, FSRM quotas, deny archive tools).
  • MFA odporne na phishing (FIDO2/Passkeys), kontrola sesji i re-autoryzacja przy dostępie do danych wrażliwych.
  • Segmentacja sieci (oddzielne strefy dla systemów z danymi wrażliwymi).
  • Honeytokens/Honeyfiles w kluczowych udziałach; alert na odczyt.
  • Playbook IR z krokami: izolacja hosta, rotacja tajemnic, przeszukanie wskaźników exfiltracji, retencja logów ≥ 180 dni.
  • Ciągłe testy scenariuszowe (purple team) pod kątem „stealth exfiltration” (SMB → archiwizacja → HTTPS put).

Przykładowa reguła Zeek (anomalie objętościowe SMB/HTTP) — szkic:

event file_over_new_connection(f: fa_file) {
  if ( f$source == "SMB" && f$info?$totalsize && f$info$totalsize > 500*1024*1024 )
    NOTICE([$note=Notice::INFO, $msg=fmt("Large SMB read: %s bytes", f$info$totalsize)]);
}

Różnice / porównania z innymi przypadkami

  • „Copy-out without crypto” vs. klasyczny ransomware: brak wzmianek o szyfrowaniu i przestojach produkcyjnych — scenariusz bliższy cichym kradzieżom danych (low-noise) niż głośnym kampaniom szyfrującym.
  • Sektor medyczny/apteczny — nawet gdy zgłoszenie nie mówi wprost o PHI, profil działalności zwiększa wagę danych i skutki regulacyjne. Zgłoszenie w CA AG potwierdza typowy cykl „data mining → notyfikacje”.

Podsumowanie / kluczowe wnioski

  • Incydent w SSA Holdings miał charakter exfiltracji plikowej 15.09.2025; 24.10.2025 potwierdzono obecność danych osobowych; 13.11.2025 opublikowano wpis w rejestrze CA. Firma oferuje monitoring Kroll. Zakres danych różni się per osoba; źródła branżowe sygnalizują m.in. SSN. Wdrożenie MFA odpornych na phishing, segmentacji i detekcji exfiltracji jest kluczowe, podobnie jak security freeze i monitoring kredytowy po stronie osób poszkodowanych.

Źródła / bibliografia

  • List notyfikacyjny SSA Holdings złożony u Prokuratora Generalnego Kalifornii (PDF). Potwierdza datę incydentu, datę zakończenia analizy i ofertę Kroll.
  • Rejestr naruszeń danych — Office of the Attorney General, California (pozycja „SSA Holdings, LLC” z datami 09/15/2025 i 11/13/2025). (California Attorney General)
  • Rejestr NPI (Centers for Medicare & Medicaid Services) — profil „SSA HOLDINGS LLC / Amarillo, TX”. Potwierdza naturę podmiotu i adres. (npiregistry.cms.hhs.gov)
  • ClaimDepot — notatka o naruszeniu SSA Holdings, w tym liczba 1 639 powiadomień w Teksasie oraz wzmianka o SSN (źródło wtórne, nieurzędowe). (Claim Depot)

Towne Mortgage potwierdza wyciek danych po ataku ransomware BlackByte (2025)

Wprowadzenie do problemu / definicja luki

Towne Mortgage Company (pełnoprofilowy pożyczkodawca hipoteczny z Michigan) poinformował o naruszeniu bezpieczeństwa danych po ataku ransomware przypisywanym grupie BlackByte. W wyniku nieautoryzowanego dostępu doszło do skopiowania plików z danymi osobowymi klientów, w tym m.in. imion i nazwisk, numerów Social Security (SSN), dat urodzenia, adresów, danych dokumentów tożsamości, informacji medycznych i finansowych. Spółka uruchomiła dla poszkodowanych 24-miesięczny pakiet monitoringu kredytowego przez Cyberscout (TransUnion). Źródła stanowe wskazują na formalne zgłoszenia do organów nadzorczych.


W skrócie

  • Atakujący: BlackByte (model „double extortion” – szyfrowanie + kradzież i publikacja danych).
  • Wykrycie nieautoryzowanego dostępu: 7 czerwca 2025 r. (UTC-5).
  • Potwierdzenie wycieku plików: 14 października 2025 r. po przeglądzie śledczym.
  • Zgłoszenie publiczne (m.in. MA AG): 14 listopada 2025 r.
  • Claim na „leak site”/darknecie: 30 lipca 2025 r. (BlackByte ogłosił żądania i próbki danych).
  • Zakres danych: PII + możliwe elementy medyczne i finansowe.
  • Wsparcie dla ofiar: 24 mies. monitoringu kredytu (Cyberscout/TransUnion).

Kontekst / historia / powiązania

W 2024–2025 r. sektor hipoteczny w USA był regularnie celem grup ransomware ze względu na bogate zbiory PII + dane finansowe oraz złożone łańcuchy dostaw (serwisowanie pożyczek, dostawcy IT, kancelarie, biura tytułów). BlackByte pozostawał aktywny także w połowie 2025 r., a 30 lipca 2025 r. na portalach śledzących wycieki odnotowano wpis o Towne Mortgage. Niektóre analizy wiążą aktywność BlackByte z nowszymi wariantami/ewolucją operacyjną (np. Crux jako afiliacja/odmiana z połowy 2025 r.), choć konkretne TTP w sprawie Towne nie zostały publicznie potwierdzone.


Analiza techniczna / szczegóły luki

Co wiemy oficjalnie:

  • Zidentyfikowano nieautoryzowany dostęp do sieci 7 czerwca 2025 r.
  • Po forensic + manual review spółka 14 października 2025 r. potwierdziła, że pliki z danymi klientów mogły zostać skopiowane (exfiltracja).
  • Zawiadomienia do organów – m.in. Massachusetts AG – od 14 listopada 2025 r.
  • Oferta 24 mies. monitoringu kredytu (Cyberscout) dla konsumentów.

TTP BlackByte (typowe, branżowe):

  • Podwójne wymuszenie: kradzież + szyfrowanie; publikacja „próbek” na blogu wycieków dla presji negocjacyjnej.
  • Techniki utrzymania/eskalacji (obserwowane w rodzinie/afiliacjach): wyłączanie mechanizmów odzyskiwania (np. bcdedit), uruchamianie szyfrowania po wstępnej enumeracji udziałów, czasem wykonywanie z procesów systemowych (np. svchost.exe), lateral movement po AD. Uwaga: te cechy opisują grupę/rodzinę, a nie są oficjalnie potwierdzone w sprawie Towne.

Potencjalne wektory (hipotezy branżowe, brak publicznych potwierdzeń dla tego incydentu):

  • Kradzież/stosowanie poświadczeń domenowych (phishing, stealer, RDP/VPN bez MFA).
  • Eksploatacja znanych podatności w edge (VPN, MDM, serwery plików, Veeam, VMware, Citrix).
  • Niewłaściwe segmentacje i brak EDR/NDR na serwerach pomocniczych.

Praktyczne konsekwencje / ryzyko

Dla klientów:

  • Wysokie ryzyko kradzieży tożsamości (SSN, DoB, adresy) i fraudów kredytowych/ubezpieczeniowych.
  • Możliwe targetowane smishing/phishing podszywające się pod Towne, TransUnion/Cyberscout czy biura kredytowe.
  • Ryzyko synthetic ID i nadużyć podatkowych.

Dla organizacji:

  • Koszty powiadomień i usług ochronnych, ewentualne postępowania AG dot. terminowości i treści notyfikacji, oraz przegląd zgodności z wymogami stanowymi (MA, TX, OR itd.).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników/klientów Towne Mortgage

  1. Zarejestruj monitoring kredytowy (24 mies.) w oknie wskazanym w liście – to bezpłatne.
  2. Zamróź kredyt (Credit Freeze) w Equifax, Experian, TransUnion – skuteczniejsze niż alerty.
  3. Włącz „fraud alert” i pobierz raporty kredytowe (co najmniej kwartalnie).
  4. Uważaj na phishing: korespondencja o „dopłatach”, „aktualizacji danych po incydencie” itp.
  5. Jeśli doszło do nadużyć: FTC IdentityTheft.gov (plan działań) + zgłoszenie na policję.

Dla zespołów SOC/IR w instytucjach finansowych (checklista hunt & hardening)

  • Hunting (Windows/AD)
    • Nietypowe użycia bcdedit, vssadmin, wbadmin (wyłączanie kopii w tle).
    • Wzorce exfiltracji (duży outbound, rclone, mega, curl na TOR/proxy).
    • Wstrzyknięcia/uruchomienia z svchost.exe, cmd.exe w nietypowych ścieżkach.
    • Nienormalne Kerberoasting/AS-REP i masowe LDAP/SMB enumeracje.
  • Kontrole prewencyjne
    • MFA wymuszona na RDP/VPN; blokada RDP z internetu; just-in-time admin.
    • EDR na serwerach plików/backup; NDR na segmentach serwerowych.
    • Segmentacja: serwery finansowe/serwisowania pożyczek odłączone od stacji biurowych.
    • Kopie zapasowe offline/immutability, testy przywracania co 30 dni.
    • DLP/monitoring egress i CASB dla chmur (wykrywanie nieautoryzowanych uploadów).

Przykładowe reguły/Sigma (skrót):

title: Possible Ransomware Preparation via Backup Deletion
logsource: { product: windows, category: process_creation }
detection:
  sel:
    Image|endswith: '\bcdedit.exe'
    CommandLine|contains|all:
      - 'recoveryenabled'
      - 'no'
  condition: sel
level: high
tags: [attack.defense_evasion, attack.impact]
# Szybki przegląd nietypowych transferów wychodzących (Windows)
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" |
  Where-Object { $_.Id -eq 3 -and $_.Properties[8].Value -gt 104857600 } | # >100MB
  Select-Object TimeCreated, @{n='DstIp';e={$_.Properties[5].Value}}, @{n='Bytes';e={$_.Properties[8].Value}}

Różnice / porównania z innymi przypadkami

  • W sektorze hipotecznym widzimy zarówno encrypt-and-exfiltrate, jak i pure-exfiltration (bez szyfrowania) z naciskiem na presję publikacji. BlackByte konsekwentnie stosuje publikację próbek – analogicznie do innych grup (LockBit, Akira), co zwiększa ekspozycję ofiar. W przypadku Towne istnieją publiczne wzmianki o próbkach na blogu wycieków z 30.07.2025, co potwierdza scenariusz „double extortion”.

Podsumowanie / kluczowe wnioski

  • Incydent w Towne Mortgage wpisuje się w szerszy trend ataków na finansowanie hipoteczne, gdzie PII + dane finansowe są kluczowym celem.
  • Oś czasu (06/07 wykrycie → 10/14 potwierdzenie → 11/14 zgłoszenie) oraz 24-miesięczne wsparcie kredytowe wskazują na klasyczny przebieg post-incydentowy.
  • Dla klientów najważniejsze są: freeze kredytu, monitorowanie oraz ostrożność wobec phishingu.
  • Dla firm – MFA wszędzie, twarde segmentacje, EDR/NDR, ochrona kopii i stały threat hunting pod TTP BlackByte.

Źródła / bibliografia

  1. „Towne Mortgage Confirms Data Breach Following Ransomware Attack” – przegląd incydentu, zakres danych, oś czasu, wsparcie Cyberscout. (Claim Depot)
  2. Halcyon – profil grupy BlackByte i potwierdzenia najnowszych ataków/claimów w 2025 r. (halcyon.ai)
  3. Ransomware.live – wpis o Towne Mortgage (claim na blogu wycieków 30.07.2025). (ransomware.live)
  4. Texas OAG / Oregon DOJ – wytyczne dot. obowiązków notyfikacyjnych i wzorców raportowania; kontekst regulacyjny. (Texas Attorney General)

Daily Ransomware Report – 15 listopada 2025: trend „data-theft extortion” i aktywność Qilin

Wprowadzenie do problemu / definicja luki

Dzisiejszy przegląd incydentów wskazuje na 9 nowych ofiar ujawnionych na stronach wyciekowych (DLS) w ciągu ostatnich 24 godzin. Wśród grup najaktywniejszy był Qilin (2 ofiary), a geograficznie najbardziej dotknięte pozostają Stany Zjednoczone. Sektory? Od usług profesjonalnych i edukacji po energetykę i ochronę zdrowia – czyli pełne spektrum, w tym infrastrukturę krytyczną. W warstwie TTP szczególnie istotna jest eskalacja modelu „data-theft extortion” (kradzież danych + wymuszenie), którą prezentuje nowa grupa Kazu operująca przez nadużycia aplikacji webowych zamiast klasycznego szyfrowania zasobów. Źródłowe dane statystyczne i syntetyczne zestawienie grup pochodzą z dzisiejszego raportu Purple Ops.


W skrócie

  • Skala: 9 nowych zgłoszeń/ofiar na DLS; rok-do-dnia: 6564, Q4: 1138.
  • Najaktywniejsza grupa: Qilin (2 ofiary / różne branże, w tym elementy infrastruktury krytycznej).
  • Nowy gracz: Kazu – pierwszy głośny przypadek w Ameryce Płn.: Doctor Alliance (TX, USA), groźba publikacji 353 GB / ok. 1,2 mln plików, żądanie 200 tys. USD.
  • Incydenty dnia (wybrane z monitoringu DLS): m.in. Brotherhood → Ninas Jewellery (AU); wzmianki o Kill Security → Force Brokerage (US); aktywność Qilin wobec podmiotów w Ameryce Płn.
  • Szerszy trend: Qilin utrzymuje wysokie tempo globalne w 2025 r., należąc do najbardziej prolificznych operatorów.

Kontekst / historia / powiązania

Rok 2025 przyniósł stabilnie wysoką aktywność ekosystemu ransomware, a Qilin – obecny od 2022 r. – pozostaje jedną z najprężniej działających operacji (Golang, elastyczne tryby szyfrowania, „double extortion”). W tle mamy ciągłe działania organów ścigania i sankcje wobec infrastruktur wspierających gangi, ale skuteczność odstraszania jest ograniczona – grupy szybko się rekonfigurują i/lub przełączają model biznesowy (np. data-theft bez szyfrowania).

Kazu wpisuje się w rosnący nurt grup, które porzucają ciężkie payloady na rzecz wyłudzeń po samej eksfiltracji, wykorzystując słabości w warstwie aplikacyjnej (portalach, usługach SaaS, hostingach). Pierwsze szeroko opisywane uderzenie w Ameryce Płn. to Doctor Alliance (inne publikacje także potwierdzają wolumen i deadline okupu).


Analiza techniczna / szczegóły luki

1) TTP „data-theft extortion” (Kazu)

  • Wejście: podatności w aplikacjach webowych / panelach (np. auth bypass, RCE w CMS/WAF, błędy uploadu, SSRF, SQLi, IDOR).
  • Ruch lateralny: ograniczony lub zerowy – priorytetem jest szybka eksfiltracja wprost z warstwy aplikacyjnej lub storage’u (S3/Blob/NAS).
  • Eksfiltracja: HTTP(S) do hostów kontrolowanych, czasem kanały chmurowe (niepozorne domeny, CDN), archiwa wieloczęściowe.
  • Wymuszenie: publikacja listingów, zrzuty ekranów, próbki (setki obrazów PDF/JPG z dokumentacją medyczną), licznik czasu i żądanie okupu – tutaj $200k i groźba publikacji 21.11.2025.

2) Qilin – model „double extortion”

  • Wejście: spear-phish + kradzież kredencjałów, RDP/VPN bez MFA, podatne urządzenia perymetryczne, n-day CVE (Fortinet, Ivanti, VMware), czasem łańcuchy supply-chain.
  • Faza przed-encryption: wyłączenie EDR, shadow copies, backup endpointów; kradzież danych wrażliwych (HR/finanse/projekty).
  • Szyfrowanie: wsparcie wielu trybów, sterowane przez operatora; nota okupu + komunikacja przez Tox/Chat. Skala 2025 – setki ofiar globalnie.

3) Inne grupy z dziennego podsumowania

  • Brotherhood → Ninas Jewellery (AU) – zgłoszenie na trackerach DLS.
  • Kill Security / KillSec → Force Brokerage (US) – wpisy w serwisach monitorujących DLS. (Uwaga: szczegóły mogą się zmieniać; w tej chwili brak szerokich, oficjalnych potwierdzeń poza ekosystemem DLS/OSINT).

Praktyczne konsekwencje / ryzyko

  • Ochrona zdrowia: incydenty typu Doctor Alliance oznaczają wysokie ryzyko RODO/HIPAA (pełne dane medyczne, numery ubezpieczeń, plany leczenia). Efekty: kradzież tożsamości, oszustwa ubezpieczeniowe, spear-phish kontekstowy (spoofing lekarzy/placówek).
  • Infrastruktura krytyczna: nawet gdy brak szyfrowania, ujawnienie konfiguracji OT/ICS, schematów, list kont zwiększa ryzyko wtórnych włamań i szantażu.
  • Łańcuch dostaw: wycieki danych dostawców (MSP, billing, dokumentacja) eskalują ryzyko pivotu na klientów.

Rekomendacje operacyjne / co zrobić teraz

1) Twardnienie frontów webowych (pod Kazu / „pure exfil”)

Szybkie kontrole:

# Sprawdź ekspozycję paneli (MFA/SSO) i podstawową powierzchnię:
nmap -Pn -sV --script http-auth,http-vuln* -p80,443 <Twoje_ADR_IP/CIDR>

# Wyszukaj nieautoryzowane uploady / webshell:
grep -R --include="*.php" -nE "(base64_decode|eval\(|shell_exec|assert\()" /var/www/html

# Poszukaj świeżych artefaktów w katalogach upload:
find /var/www/html/uploads -type f -mtime -3 -ls

WAF/Reverse proxy:

  • Włącz bot management / anomaly scoring (SQLi/XSS/SSRF/IDOR), rate-limit na endpointach upload/search.
  • MFA „enforce” na wszystkich panelach administracyjnych/helpdesk/portalach B2B. (Raport Purple Ops podkreśla ten wektor przy Kazu.)

Dzienniki i detekcje (przykłady):

Sigma (podejrzane archiwa wyprowadzane przez proces serwera www):

title: Suspicious Large Archive Exfil via Webserver Process
logsource:
  product: linux
  category: process_creation
detection:
  sel:
    Image|endswith:
      - /usr/sbin/apache2
      - /usr/sbin/nginx
    CommandLine|contains:
      - "zip"
      - "7z"
      - "tar"
  cond: sel
fields: [Image, CommandLine, User, ParentProcess, CurrentDirectory]
level: high
tags: [exfiltration, webserver, data-theft]

NGINX – anomalia rozmiaru odpowiedzi (potencjalna eksfiltracja):

# mapuj duże odpowiedzi >100MB do osobnego loga
map $body_bytes_sent $large_body {
  default 0;
  "~^[1-9][0-9]{8,}$" 1;  # >= 100MB
}
log_format exfil '$remote_addr $time_local "$request" $status $body_bytes_sent $http_referer $http_user_agent';
access_log /var/log/nginx/exfil.log exfil if=$large_body;

Splunk – spike dużych transferów z hostów www:

index=web sourcetype=nginx:access OR sourcetype=apache:access
| bucket _time span=15m
| stats sum(bytes) as out_bytes by src, dest, _time
| eventstats avg(out_bytes) as avg stdev(out_bytes) as std by src
| where out_bytes > avg + 3*std
| sort - out_bytes

2) Ransomware (Qilin i podobni) – hygiene + EDR

  • Dostępy zdalne: wyłącz RDP z internetu; VPN tylko z MFA + Device Posture.
  • EDR/AV: blokada LOLBins, monitoring vssadmin, wbadmin, bcdedit; polityki anty-tamper.
  • Backupy: 3-2-1, test odtwarzania, immutable w chmurze (Object Lock/WORM).
  • AppControl: Allow-listing (WDAC/AppLocker), blokada uruchamiania z %AppData%, Temp, udziałów SMB użytkowników.
  • AD tiering: konta uprzywilejowane z PAM, PAW (Privileged Access Workstation).

Windows – logika detekcji „pre-crypto”:

# Podejrzane polecenia dot. shadow copies i bootcfg
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} |
  Where-Object { $_.Properties[5].Value -match 'vssadmin|wbadmin|bcdedit|wmic.*shadowcopy' } |
  Select-Object TimeCreated, @{n='Cmd';e={$_.Properties[5].Value}}, @{n='User';e={$_.Properties[1].Value}}

Sigma – masowe operacje na plikach (renames/encryptors):

title: Ransomware-Like Mass File Rename
logsource:
  product: windows
  service: sysmon
detection:
  sel:
    EventID: 11  # FileCreate
    TargetFilename|endswith:
      - ".locked"
      - ".qilin"
      - ".crypt"
  timeframe: 5m
  condition: selection
level: high

3) Ochrona danych medycznych (PHI) – szybkie kroki IR

  • Segmentacja systemów billing/EMR i oddzielenie od frontów www.
  • DLP + egress control: bloki na uploady do „fresh” domen CDN/chmury poza allowlistą.
  • „Canary records” w bazach PHI (fałszywe, śledzone identyfikatory); alert na odczyt.
  • Notyfikacje prawne – przygotować szablony (HIPAA/RODO), lokalny regulator i klienci.

Różnice / porównania z innymi przypadkami

  • Ransomware klasyczne vs. „pure exfil” (Kazu):
    • Klasyczne: szyfrowanie + exfil; widoczne artefakty (wyłączanie VSS, noty okupu).
    • Pure exfil: brak szyfrowania, krótsze dwell time, mniejszy hałas na hostach – ciężar detekcji przenosi się na warstwę www/egress.
  • Qilin na tle 2025:
    • Skala i tempo – dziesiątki setki przypadków; celowanie w krytyczne sektory i Amerykę Płn.
    • Dowody z OSINT i opracowań branżowych potwierdzają jego czołową pozycję w tym roku.

Podsumowanie / kluczowe wnioski

  1. Dzień zdominowany przez Qilin, ale narrację zmienia Kazu – wymuszenia po samej kradzieży danych są coraz bardziej opłacalne i trudniejsze w detekcji.
  2. USA pozostaje głównym celem, lecz widoczna jest dywersyfikacja sektorowa (usługi, edukacja, zdrowie, energetyka).
  3. Dla SOC/CERT oznacza to konieczność wzmocnienia telemetrii web/egress, a nie tylko host-based anty-crypto.
  4. Organizacje powinny aktualizować playbooki IR o scenariusze „pure exfil” (bez szyfrowania) i mierzyć skuteczność: MTTA/MTTD dla anomalii ruchu wychodzącego, not tylko dla binarek szyfrujących.

Źródła / bibliografia

  1. Purple Ops – Daily Ransomware Report 11/15/2025 – statystyki dnia, zestawienie grup i sektorów. (Purple Ops)
  2. BankInfoSecurity – „Kazu expands reach; Doctor Alliance” – pierwszy głośny przypadek Kazu w Ameryce Płn., 353 GB danych. (bankinfosecurity.com)
  3. TechRadar Pro – Doctor Alliance: ~1,24 mln plików / 353 GB – szczegóły danych, skala i ryzyka dla ofiar. (TechRadar)
  4. HealthExec – żądanie 200 tys. USD, deadline 21.11.2025 – oś czasu i parametry wymuszenia. (Health Exec)
  5. Ransomware.live – „Brotherhood → Ninas Jewellery (AU)” – potwierdzenie wpisu na DLS. (ransomware.live)
  6. (Kontekst techniczny) Ransomware.live – Qilin (profil/TTP) – charakterystyka rodziny, double extortion. (ransomware.live)
  7. (Trend 2025) IndustrialCyber – aktywność Qilin w 2025 – pozycja w krajobrazie roku. (Industrial Cyber)

Uwaga o wiarygodności: część pozycji dziennych (np. Force Brokerage / Kill Security) pierwotnie pochodzi z agregatorów wpisów DLS/OSINT i może nie mieć jeszcze niezależnych, oficjalnych potwierdzeń poza stronami wyciekowymi. Zalecane jest bieżące „threat validation” przed eskalacją reakcji IR.

Logitech: incydent bezpieczeństwa z wykorzystaniem zero-day w oprogramowaniu firm trzecich. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Logitech potwierdził incydent cyberbezpieczeństwa polegający na wykradzeniu danych z wewnętrznych systemów IT. Według oświadczenia spółki, atakujący wykorzystali lukę zero-day w oprogramowaniu podmiotu trzeciego, a zdarzenie nie wpłynęło na produkty, produkcję ani bieżące operacje. Firma ocenia, że w dotkniętym systemie nie przetwarzano wrażliwych danych osobowych (np. numerów ID czy kart płatniczych).

W skrócie

  • Wektor wejścia: exploity na zero-day w zewnętrznej platformie programistycznej używanej przez Logitech.
  • Skutek: skopiowanie części danych z systemów wewnętrznych; zakres ma obejmować ograniczone informacje o pracownikach i konsumentach oraz dane klientów/dostawców.
  • Atrybucja medialna: równolegle grupa Cl0p przypisała sobie atak i opublikowała zrzut danych, co media łączą z kampanią wykradania danych z systemów Oracle E-Business Suite (EBS) poprzez CVE-2025-61882/61884. (Logitech nie nazwał dostawcy w swoim komunikacie).

Kontekst / historia / powiązania

Od końca września 2025 r. obserwujemy falę ekstorsyjnych kampanii wobec organizacji korzystających z Oracle EBS. GTIG Google i Mandiant opisały wzorzec: masowe e-maile do zarządów z żądaniami okupu i „dowodami” kradzieży danych EBS. Kilka tygodni później Oracle potwierdził zero-day CVE-2025-61882 oraz opublikował poprawki awaryjne; w październiku pojawiły się też kolejne łatki (m.in. CVE-2025-61884). Na stronach Cl0p wymieniono dziesiątki organizacji – w tym Logitech – jako domniemane ofiary kampanii.

W dniu 14 listopada 2025 r. Logitech złożył również raport 8-K do SEC, potwierdzając kradzież danych i brak wpływu na działalność operacyjną.

Analiza techniczna / szczegóły luki

Choć Logitech wskazuje jedynie „platformę zewnętrznego dostawcy”, wiele sygnałów zbiega się ze znaną już kampanią na Oracle E-Business Suite:

  • CVE-2025-61882 (EBS) – krytyczna luka RCE bez uwierzytelnienia osiągalna przez HTTP; umożliwia zdalne wykonanie kodu w kontekście aplikacji EBS (wektory przez komponenty Concurrent Processing/BI Publisher oraz przetwarzanie XSLT/SSRF). Oracle potwierdził aktywne wykorzystanie w atakach.
  • Taktyki Cl0p/FIN11 – znany schemat „data-theft-first”: eksfiltracja dużych wolumenów danych, a następnie wymuszenie (publish or pay). W przeszłości Cl0p nadużywał zero-day w Accellion FTA, GoAnywhere MFT i MOVEit Transfer. Najnowsze publikacje wskazują, że w kampanii EBS Cl0p wysyłał maile z szantażem do kierownictw spółek, a na stronie grupy pojawiały się listy ofiar.

Jak mogło wyglądać przejście od RCE do kradzieży danych? (modelowy łańcuch, zgodny z opisami społeczności):

  1. Initial Access: crafted HTTP request do endpointu BI Publisher/CP z payloadem XSLT/SSRF → RCE bez uwierzytelnienia.
  2. Execution & Discovery: zrzut zmiennych środowiskowych i konfiguracji EBS; enumeracja mountów NFS/ASM, poszukiwanie poświadczeń do baz/ERP.
  3. Credential Access: wykradanie plików konfiguracyjnych (np. tnsnames.ora, dbc), ewentualnie dump haseł aplikacyjnych.
  4. Collection: hurtowy eksport danych (HR, kontrakty, faktury) z baz EBS lub udziałów plikowych.
  5. Exfiltration: kanał HTTP(S)/SFTP z hosta pośredniego; w wątkach o Cl0p przewija się wolumetryczna eksfiltracja (TB).

Praktyczne konsekwencje / ryzyko

  • Ryzyko wtórne dla klientów i partnerów: dane kontraktowe, listy kontaktowe, ewentualnie dokumenty operacyjne mogą ułatwiać spear-phishing, BEC i nadużycia łańcucha dostaw.
  • Ryzyko ujawnienia danych pracowniczych: nawet jeśli brak numerów kart/ID w dotkniętym systemie, informacje „średniej wrażliwości” (np. służbowe e-maile, role, telefony) zwiększają powierzchnię ataku socjotechnicznego.
  • Presja ekstorsyjna i wyciek dużych wolumenów: media branżowe podały, że Cl0p opublikował do ~1,8 TB rzekomo skradzionych danych związanych z Logitech. (To twierdzenie pochodzi z doniesień prasowych – nie z komunikatu spółki).

Rekomendacje operacyjne / co zrobić teraz

Poniższe działania są aktualne dla każdej organizacji posiadającej EBS lub zależności od systemów partnerów:

  1. Natychmiastowa weryfikacja ekspozycji EBS
    • Sprawdź, czy jakiekolwiek endpointy EBS/BI Publisher są dostępne z Internetu. # Szybkie sprawdzenie z zewnątrz (podmień host) for p in 443 8443 8000 8001; do echo "[*] Port $p"; timeout 3 bash -c "echo > /dev/tcp/ebs.example.com/$p" && echo "open" || echo "closed" done
    • Jeśli EBS musi być dostępny publicznie: WAF + geofencing + allow-list adresów administratorów/VPN; terminowo wdrażaj poprawki CVE-2025-61882/61884.
  2. Patch & hardening
    • Zastosuj awaryjne biuletyny Oracle (CVE-2025-61882 i nowsze) oraz wskazówki producenta (IOCs).
    • Odseparuj EBS od sieci biurowej (segmentacja L3/L7), wymuś mTLS lub przynajmniej TLS z pinningiem certyfikatów między komponentami.
  3. Hunting i detekcja (przykładowe reguły/Sigma/Splunk)
    Sigma (HTTP logi reverse proxy / WAF) – podejrzane żądania do BI Publisher/XSLT: title: Oracle EBS BI Publisher Exploitation Attempt id: 1c8f2a0f-0b6b-4f6b-9a0d-ebs-bip-xsl-inject status: experimental logsource: category: webserver detection: sel1: cs-method|contains: POST sel2: cs-uri-query|contains: - 'xmlpserver/servlet' - 'xdo.servlet' sel3: cs-uri-query|contains: - 'template=' - 'xsl=' - 'URL=' # wzmianki o SSRF condition: sel1 and sel2 and sel3 level: high tags: - attack.initial-access - cve.2025-61882 Splunk – nietypowe duże odpowiedzi/transfer do jednego IP (eksfil HTTP): index=proxy OR index=waf | stats sum(bytes_out) as out by src_ip, dest_ip, dest_port | where dest_port IN (80,443) AND out > 500000000 /* > ~500MB w oknie */ | sort - out
  4. IR i kontrola szkód
    • Oddziel konto serwisowe EBS od reszty ekosystemu (rotate secrets, disable stale).
    • Przejrzyj logi współdzielonych systemów (SFTP, MFT, NAS, DLP).
    • Przygotuj komunikację do interesariuszy (klienci, dostawcy) oraz notyfikacje regulacyjne, nawet jeśli dane wrażliwe formalnie nie były przetwarzane (ryzyko phishing/BEC). Rekomendacje zgodne z praktyką NCSC/ind. alertów dla EBS.
  5. Kontrole prewencyjne na przyszłość
    • Assume breach” dla systemów ERP: Egress controls, tagowanie i klasyfikacja danych, DLP na repozytoriach projektowych i udziałach.
    • Table-top pod scenariusz „data-theft-first” (ekstorsja bez szyfrowania).
    • Wymóg SBOM/SoC2 i continuous assurance dla krytycznych dostawców SaaS/third-party.

Różnice / porównania z innymi przypadkami (Accellion, GoAnywhere, MOVEit)

Cl0p od lat wykorzystuje 0-day w popularnych platformach przetwarzania danych/plików. Wspólne elementy: brak potrzeby interakcji użytkownika, szybkie przejście do masowej eksfiltracji i presja na ofiarę publikacją „próbek”. Różnica w bieżącej kampanii: ERP (Oracle EBS) to bardziej wewnętrzny system biznesowy – kompromitacja nierzadko oznacza wyciek pełnego kontekstu operacyjnego (HR/finanse/łańcuch dostaw), a nie tylko pojedynczych plików transferowanych przez MFT.

Podsumowanie / kluczowe wnioski

  • Logitech potwierdził kradzież danych po wykorzystaniu zero-day w oprogramowaniu strony trzeciej; brak wpływu na produkty i działalność operacyjną.
  • Sygnały z ekosystemu wskazują, że jest to element szerszej kampanii Cl0p/FIN11 na Oracle EBS (CVE-2025-61882/61884) z naciskiem na eksfiltrację i wymuszenie.
  • Organizacje powinny natychmiast: załatać EBS, ograniczyć jego ekspozycję, wdrożyć hunting IOC/TTP, twardo kontrolować ruch wychodzący i przygotować komunikację kryzysową.

Źródła / bibliografia

  • Logitech – Cybersecurity Disclosure (14.11.2025) (press release). (ir.logitech.com)
  • BleepingComputer – “Logitech confirms data breach after Clop extortion attack” (14.11.2025). (BleepingComputer)
  • SecurityWeek – “Nearly 30 Alleged Victims of Oracle EBS Hack Named on Cl0p Ransomware Site” (10.11.2025). (SecurityWeek)
  • Oracle – Security Alert: CVE-2025-61882 (Oracle E-Business Suite). (Oracle)
  • NCSC (UK) – Active exploitation of vulnerability affecting Oracle E-Business Suite. (NCSC)

Uwaga redakcyjna: Artykuł bazuje na oficjalnym oświadczeniu Logitech oraz wiarygodnych publikacjach branżowych. Część elementów (np. wolumen rzekomo ujawnionych danych) pochodzi z doniesień mediów i/lub strony grupy przestępczej i nie została potwierdzona przez spółkę.

CVE-2025-64446: krytyczna podatność 0-day w Fortinet FortiWeb (path traversal) aktywnie wykorzystywana

W skrócie

  • Co: Path traversal prowadzący do zdalnego wykonania poleceń z uprawnieniami administracyjnymi na FortiWeb.
  • Kto: Atakujący bez uwierzytelnienia (z Internetu).
  • Status: 0-day – wykorzystywany zanim opublikowano advisory; obecnie dostępne poprawki. Wpis w CISA KEV.
  • Wpływ: Pełne przejęcie WAF-a, tworzenie kont admina, modyfikacja polityk, pivot w głąb sieci.
  • Co robić teraz: Natychmiastowy upgrade do wersji naprawionych, ograniczenie ekspozycji HTTP/HTTPS, monitoring logów, polowanie na ślady nadużyć.

Kontekst / historia / powiązania

Pierwsze sygnały o nieznanym exploicie na urządzenia Fortinet pojawiły się na początku października. 13–14 listopada niezależni badacze (m.in. watchTowr) zreprodukowali błąd i opublikowali wstępne ustalenia, po czym Fortinet wydał PSIRT FG-IR-25-910 oraz przypisał CVE-2025-64446. W tym samym czasie liczne firmy (Tenable, Rapid7, Arctic Wolf) ostrzegły o aktywnej eksploatacji; CISA dodała lukę do KEV.


Analiza techniczna / szczegóły luki

Wektor ataku. Błąd to relative path traversal w interfejsie HTTP/HTTPS FortiWeb, który umożliwia napastnikowi odwołanie się do niezamierzonych ścieżek i zasobów aplikacji/OS. Skutkiem jest ominięcie kontroli i możliwość wykonywania komend administracyjnych lub wywoływania wrażliwych funkcji. W praktyce to RCE/privilege abuse osiągalne bez logowania.

Wersje podatne / naprawione (Fortinet PSIRT):

  • Podatne: 7.0.0–7.0.11, 7.2.0–7.2.11, 7.4.0–7.4.9, 7.6.0–7.6.4, 8.0.0–8.0.1
  • Naprawione: 7.0.12+, 7.2.12+, 7.4.10+, 7.6.5+, 8.0.2+
    Fortinet zaleca także ograniczenie dostępu do interfejsu zarządzania HTTP/HTTPS wyłącznie do sieci wewnętrznej (nie wystawiać publicznie).

Starsze gałęzie (ustalenia badaczy). WatchTowr wskazuje, że 6.4 ≤ 6.4.3 oraz 6.3 ≤ 6.3.23 również wykazują podatność w podobnym łańcuchu błędów – co jest ważne dla środowisk, gdzie utrzymuje się EoL-owe wydania. (Traktuj jako dane badawcze; weryfikuj z PSIRT).

Ocena ryzyka (CVSS). NVD klasyfikuje lukę jako krytyczną: niski nakład atakującego, brak interakcji użytkownika, pełne naruszenie C/I/A.


Praktyczne konsekwencje / ryzyko

  1. Przejęcie FortiWeb – tworzenie/zmiana kont admina, zmiana polityk WAF (np. wyłączenie ochrony dla krytycznych aplikacji).
  2. Lateral movement – FortiWeb często „widzi” ruch do aplikacji biznesowych; kompromitacja może dać dane uwierzytelniające i ścieżki pivotu.
  3. Sabotaż bezpieczeństwa aplikacji – atakujący może tolerować własny ruch (np. wstrzyknięcia SQL, SSRF) przez manipulację regułami WAF.
  4. Utrata poufności i integralności logów – możliwość wyciszenia alertów/telemetrii.
  5. Ataki łańcuchowe – po FortiWeb możliwe ataki na CI/CD, ERP, bankowość internetową itp., które WAF chroni.

Rekomendacje operacyjne / co zrobić teraz

1) Patching – priorytet awaryjny

  • Zaktualizuj FortiWeb co najmniej do: 8.0.2 / 7.6.5 / 7.4.10 / 7.2.12 / 7.0.12. Zaplanuj restart/okno serwisowe i weryfikuj wersję po aktualizacji.
    CLI (na FortiWeb): # sprawdzenie wersji execute version get system status # (jeśli używasz HA) sprawdź stan klastra diagnose system ha status

2) Ograniczenie ekspozycji zarządzania

  • Nie wystawiaj HTTP/HTTPS management na Internet. Ogranicz do mgmt-VLAN/VPN (ACL/Firewall policy). Jeżeli musisz, użyj source IP allowlist i MFA w bastionie.

3) Szybka kontrola narażenia (bezpieczna)

  • Z zewnątrz: zweryfikuj, czy porty mgmt nie są dostępne: nmap -p 80,443,8443 <adres_FortiWeb> --script http-enum,http-title
  • Z urządzenia: upewnij się, że admin-scp, telnet, http są wyłączone na interfejsach publicznych.

4) Detekcja i polowanie na oznaki nadużyć

Logi FortiWeb (przykładowe wzorce):

  • Nietypowe żądania z „../” w ścieżce lub parametrach (path traversal).
  • Niespodziewane logowania admin z rzadkich AS/GeoIP.
  • Zmiany polityk/konfiguracji poza oknami serwisowymi.

Splunk (HTTP logs z FortiWeb/syslog):

index=network OR index=forti sourcetype=fortiweb:http
| rex field=uri_path "(?<dotdots>\.\.\/)"
| stats count by src_ip, http_method, uri_path, user, _time
| where dotdots!=""

Sigma (pseudoreg. do konwersji):

title: FortiWeb Suspicious Path Traversal
logsource:
  product: fortinet
  service: fortiweb
detection:
  selection:
    c-uri|contains: "../"
  condition: selection
level: high

Wskazówka: sprawdź tworzenie nowych kont admin w krótkim okresie po nieudanych/niestandardowych żądaniach HTTP. (Kilka raportów wskazuje, że atakujący potrafią tworzyć konta administracyjne po udanym nadużyciu.)

5) Twardnienie (hardening)

  • Wymuś TLS-only na mgmt i certificate pinning po stronie operatorów gdzie to możliwe.
  • Ogranicz dostęp do /api/ i endpointów administracyjnych wyłącznie z sieci zaufanych.
  • Włącz alerting na zdarzenia systemowe: tworzenie kont, zmiana polityk, restart usług, import konfiguracji.
  • W SIEM dodaj rule chain: „żądania z ../” → „event admin create/modify” → „policy change”.

6) Testy bezpieczeństwa (bez PoC exploita)

  • Skany zależności/wersji i porównanie z matrycą podatnych/nienarażonych.
  • Wykorzystaj skanery, które już dodały detekcję (np. wtyczki Tenable; sprawdzaj aktualizacje feedów).

Uwaga operacyjna: Z uwagi na aktywne kampanie i publiczne exploity, tempo skanów i prób nadużyć prawdopodobnie wzrośnie. Wprowadź czasowe reguły rate-limit/geo-block na IP spoza twojej strefy działalności.


Różnice / porównania z innymi przypadkami Fortinet

  • W porównaniu z wcześniejszymi głośnymi błędami (np. CVE-2024-21762 w SSL-VPN czy CVE-2022-40684 bypass autoryzacji) – tutaj wektor to GUI/API FortiWeb, a nie VPN. Jednak skutek jest równie krytyczny: niezalogowany napastnik może osiągnąć admin RCE.
  • Podobnie jak w poprzednich incydentach, luka trafiła do CISA KEV, co jest silnym sygnałem wymogu szybkiej remediacji w sektorze publicznym i komercyjnym.

Podsumowanie / kluczowe wnioski

  1. Krytyczna 0-day (CVSS 9.1) w FortiWeb, aktywnie nadużywana – działaj natychmiast.
  2. Zaktualizuj do 8.0.2 / 7.6.5 / 7.4.10 / 7.2.12 / 7.0.12; nie wystawiaj GUI na Internet.
  3. Monitoruj logi pod kątem path traversal i nieoczekiwanych zmian administracyjnych; rozważ polowanie na artefakty po 13–14 listopada.
  4. Zweryfikuj starsze gałęzie (6.3/6.4) – w części środowisk mogą być podatne wg badań; zaplanuj upgrade ścieżki życia.

Źródła / bibliografia

  • Fortinet PSIRT FG-IR-25-910 – „Path confusion vulnerability in GUI” (listy wersji naprawionych, zalecenia dot. ekspozycji HTTP/HTTPS). (fortiguard.fortinet.com)
  • NVD: karta CVE-2025-64446 (opis, wektor CVSS, wpływ). (NVD)
  • watchTowr Labs: techniczne wnioski i zakres wersji w starszych gałęziach; łańcuch prowadzący do nadużyć admin. (watchTowr Labs)
  • Tenable: przegląd incydentu, ostrzeżenie o aktywnej eksploatacji, odniesienia do wtyczek skanujących. (Tenable®)
  • CISA KEV: potwierdzenie statusu „known exploited”. (CISA)

Cyberatak na rosyjskiego operatora portowego Port Alliance: celem zakłócenie eksportu węgla i nawozów

Wprowadzenie do problemu / definicja luki

Rosyjski operator portowy Port Alliance poinformował o trwającym trzy doby cyberataku „z zagranicy”, obejmującym zmasowany DDoS oraz próbę włamania do elementów krytycznych infrastruktury cyfrowej. Według spółki, celem było zdestabilizowanie procesów biznesowych i zakłócenie eksportu węgla oraz nawozów z terminali na akwenach: Bałtyk, Morze Azowsko-Czarne, Daleki Wschód i Arktyka. Firma twierdzi, że atak został odparty i nie spowodował przerw w pracy terminali.

W skrócie

  • Typ ataku: wielowektorowy — DDoS + próba intruzji (intrusion attempt) w sieci IT/operatora.
  • Cel deklarowany przez ofiarę: zakłócenie eksportu węgla i nawozów (wpływ na łańcuchy dostaw surowców).
  • Czas trwania: ok. 3 dni.
  • Zasięg operacyjny Port Alliance: terminale w kilku rosyjskich basenach morskich (Bałtyk, Morze Czarne/Azowskie, Daleki Wschód, Arktyka).
  • Stan na dziś: operator utrzymuje, że działalność nie została przerwana. (Deklaracja spółki).

Kontekst / historia / powiązania

Od 2022 r. sektor morski w regionie notuje wzmożoną aktywność cybernetyczną — od ataków DDoS i włamań po zakłócanie systemów telekomunikacyjnych i nawigacyjnych. W ostatnich miesiącach na Morzu Czarnym i Bałtyku obserwowano także kinetyczne uderzenia w infrastrukturę portową; równolegle pojawiają się doniesienia o atakach informatycznych na operatorów terminali, co wpisuje się w schemat działań hybrydowych wobec transportu morskiego i energetyki. Bieżący incydent wobec Port Alliance to kolejny przykład presji na logistykę surowców (węgiel, nawozy), istotną dla bilansu handlowego Rosji.

Analiza techniczna / szczegóły luki

1) Warstwa IT (Enterprise)

Z komunikatów prasowych i depesz wynika przede wszystkim DDoS na warstwę aplikacyjną/sieciową oraz „próba włamania” do elementów infrastruktury cyfrowej. Realistyczny scenariusz obejmuje:

  • L7 HTTP(S) flood (np. mis-use przeglądarek/„proxy-botnetów” i sieci VPN do obejścia GeoIP/WAF), uzupełniony L3/L4 volumetric (SYN/UDP/ACK floods) w celu wyczerpania zasobów brzegowych.
  • Równoległe password-spraying/credential-stuffing na portale B2B (EDI/booking), bramki API i panele partnerów (TOS/slot booking), by utrudnić obsługę łańcucha dostaw (np. rezerwacje okien przeładunkowych).
  • Potencjalne próby wykorzystania podatności w popularnych komponentach portowych (reverse proxy/WAF, ERP TOS-adjacent, VPN gateways).

Wskaźniki obserwacyjne (przykładowe):

  • Nieregularne piki w metrykach nginx_ingress_controller_requests, 5xx_ratio, wzrost RTT na ścieżkach do upstreamów, równoległy spike w conntrack_count.
  • Nietypowe UA/JA3/JA4, nienaturalna dystrybucja ASN/Geo, low TTL i brak zgodności TCP option fingerprint z typowym ruchem klientów.

2) Warstwa operacyjna (OT/ICS) – ryzyko pośrednie

Brak publicznych danych o wejściu do systemów OT (SCADA/PLC). Jednak doświadczenie z incydentów portowych pokazuje, że największy wpływ osiąga się przez uderzenie w TOS (Terminal Operating System) i systemy towarzyszące (gate/yard planning, OCR/bramownice, EDI z armatorami), czyli IT, które steruje fizycznym ruchem. Nawet „tylko” DDoS na portale awizacyjne potrafi przenieść chaos na plac składowy i nabrzeża (kolejki ciężarówek, błędne zlecenia, opóźnienia holowników).

3) Wiarygodność deklaracji

Oświadczenia operatora i rosyjskich mediów potwierdzają DDoS + próby włamań i trzy doby aktywności; jednocześnie firmy często komunikują „brak wpływu”, gdy realny efekt ogranicza się do systemów peryferyjnych (np. public WWW, CRM) — tego publicznie nie zweryfikowano. Wersję o „braku zakłóceń” należy traktować ostrożnie, dopóki niezależne źródła nie pokażą danych operacyjnych (ETA statków, czas postoju, throughput).

Praktyczne konsekwencje / ryzyko

  • Krótkoterminowe: spadek dostępności portali klientowskich, utrudniona komunikacja EDI/API z operatorami kolejowymi i armatorami; ryzyko niezsynchronizowanych wypchnięć ładunków (coal/fertilizers) i opóźnień w rozliczeniach.
  • Średnioterminowe: jeśli intruzja wykraczała poza DDoS (np. dostęp do systemów planowania lub list ładunkowych), możliwe zakłócenia harmonogramów i eskalacja oszustw (np. manipulacje dokumentami, podszycia w łańcuchu EDI).
  • Systemowe: incydent wpisuje się w trend ataków na logistykę morską i energetykę; presja na porty ma efekt dźwigni — uderzając w kilka kluczowych węzłów, wpływa się na wiele sektorów (energetyka, rolnictwo, chemia).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw „szybkich wygranych” i działań średnioterminowych dla operatorów portowych, armatorów i firm logistycznych. Przygotowane pod kątem SOC/Blue Team/NetOps/OT.

1) Tłumienie DDoS (edge/WAF/DNS)

Warstwa L7 (HTTP/S) – NGINX / Envoy / WAF

# NGINX: prosta ochrona L7 (rate limiting + burst)
limit_req_zone $binary_remote_addr zone=rl_zone:10m rate=5r/s;
limit_req_status 429;

server {
  listen 443 ssl http2;
  # ...
  location / {
    limit_req zone=rl_zone burst=50 nodelay;
    # WAF header/JA3/JA4 anomaly check via lua/sidecar
    proxy_read_timeout 30s;
  }
}

Warstwa L4 – iptables/nftables (przykład szybkiego throttlingu)

# iptables: throttling SYN na interfejsie WAN
iptables -A INPUT -p tcp --syn -m limit --limit 50/second --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Anycast/DNS i „fronty” anty-DDoS

  • Rozważ Anycast + scrubbing (komercyjni dostawcy) dla krytycznych FQDN (EDI/API/booking).
  • Geo-fencing + ASN allowlist dla paneli B2B — zdejmuje sporą część szumu botnetowego.

2) Ochrona kanałów B2B (EDI/API/partnerzy)

  • mTLS + JWT z krótkim TTL, HMAC-sig na payloadach EDI.
  • „Positive security model” na API: allowlist metod, rate i schema-validation (np. OAS → spectral w CI).
  • Wymuś per-partner client cert i źródła IP; monitoruj odchylenia JA3/JA4.

3) Detekcja & reagowanie (SOC)

Szybkie reguły Suricata (L7 flood i anomalia UA)

alert http any any -> $HOME_NET any (msg:"L7 burst (URL hot)"; flow:established,to_server;
  detection_filter: track by_src, count 100, seconds 1; classtype:attempted-dos; sid:900001; rev:1;)

alert http any any -> $HOME_NET any (msg:"Suspicious UA massing";
  content:"User-Agent|3a| curl/"; http_header; threshold:type both, track by_src, count 50, seconds 60;
  classtype:attempted-recon; sid:900002; rev:1;)

Alerting (Prometheus/Grafana)

# Przykładowa reguła: skok 5xx i jednoczesny wzrost połączeń
- alert: PossibleL7DDoS
  expr: (sum(rate(nginx_ingress_controller_requests{status=~"5.."}[1m])) /
         sum(rate(nginx_ingress_controller_requests[1m])) > 0.2)
        and (sum(rate(node_netstat_Tcp_CurrEstab[1m])) > 2 * avg_over_time(node_netstat_Tcp_CurrEstab[30m]))
  for: 2m
  labels: {severity: "high"}
  annotations: {summary: "Podejrzenie L7 DDoS"}

4) Segmentacja i „blast radius”

  • Oddziel IT od OT (firewalle warstwowe, jump hosty, unidirectional gateways dla telemetry) oraz „crown jewels”: TOS, billing, gate OCR.
  • JIT-access do VPN/administracji; MFA z odpornością na phishing (FIDO2/Passkeys).
  • Backupy 3-2-1 kluczowych baz (TOS/EDI) z testami restore.

5) Procedury ciągłości działania (BCP) dla portu

  • Tryb degradacji: papierowe awiza, manualne plany yardu, komunikacja VHF/SMS awaryjna, offline-listy ładunkowe — ćwiczone co najmniej kwartalnie.
  • Ćwiczenia Red/Blue-Team z naciskiem na scenariusze: „DDoS + social + EDI fraud” i „TOS read-only”.

Różnice / porównania z innymi przypadkami

  • Ataki DDoS na operatorów portowych zwykle mierzą w widoczną warstwę web/API (krótkotrwały, ale głośny wpływ). Tu profil pasuje — duży ruch na L7/L4 i deklarowana próba intruzji.
  • Ataki kinetyczne na porty (np. ostatnie uderzenia dronowe na infrastrukturę w regionie Morza Czarnego) wywołują natychmiastowy efekt operacyjny; cyber bywa „niemy”, ale może zwiększyć tarcie i wydłużyć recovery po incydencie fizycznym. (Kontekst regionalny).

Podsumowanie / kluczowe wnioski

  1. Incydent wobec Port Alliance wpisuje się w trend presji na węzły logistyczne — nawet jeśli atak został „odparty”, już sama konieczność przełączenia na tryb awaryjny generuje koszty i opóźnienia.
  2. DDoS + próba włamania to klasyczny duet: huk informacyjny i zasłona dla cichszej intruzji.
  3. Operatorzy portowi powinni traktować portale EDI/API jak systemy krytyczne (mTLS, allowlist, Anycast, scrubbing), a TOS i bramy OCR segmentować jak OT.
  4. Ćwiczenia BCP i telemetria L3-L7 (w tym JA3/JA4, HTTP semantics) są dziś równie ważne jak firewalle.

Źródła / bibliografia

  • The Record (Recorded Future News): „Cyberattack on Russian port operator aimed to disrupt coal, fertilizer shipments” – 14 listopada 2025. (The Record from Recorded Future)
  • Reuters: „Big Russian port operator says its systems were targeted by foreign hackers” – 13 listopada 2025. (Reuters)
  • RBC (РБК): „«Портовый альянс» сообщил о масштабной хакерской атаке на сети портов” – 13 listopada 2025. (РБК)
  • PortsEurope: „Cyber attack against Russia’s Port Alliance” – 14 listopada 2025. (Ports Europe)
  • (Kontekst regionalny) Reuters: „Ukrainian drones damage ship… Novorossiysk” – 14 listopada 2025. (Reuters)