Archiwa: Ransomware - 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.

79% firm w Indiach doświadczyło ataku ransomware. Co mówi nowe badanie Rubrik Zero Labs i co z tego wynika dla obrony?

Wprowadzenie do problemu / definicja luki

Według najnowszego badania Rubrik Zero Labs dotyczącego odporności tożsamości, 79% organizacji w Indiach doświadczyło w minionym roku ataku ransomware, a 91% z nich zapłaciło okup (często, by odzyskać dane lub zatrzymać intruzów). Artykuł „Deccan Herald” streszcza wnioski, podkreślając także, że 34% firm szacuje powrót do pełnej operacyjności dopiero po >2 dniach w przypadku ataku opartego o kompromitację tożsamości.

W skrócie

  • 79% badanych organizacji w Indiach miało incydent ransomware w ostatnich 12 miesiącach.
  • 91% ofiar zapłaciło okup.
  • Tylko 32% deklaruje zdolność do pełnego odtworzenia usług w ≤12h; ~34% potrzebuje >2 dni po ataku tożsamościowym.
  • Badanie wiąże wzrost ryzyka z eksplozją „tożsamości nie-ludzkich” (NHI) i agentów AI, czyli nowymi kontami/usługami działającymi automatycznie w środowiskach firm.

Kontekst / historia / powiązania

Dane Rubrika wpisują się w szerszy obraz: ransomware w 2024/2025 pozostaje dominującym wektorem szkód, a głośne incydenty w Indiach obejmowały także sektor bankowy (atak na dostawcę C-Edge, którego skutki odczuli klienci setek mniejszych banków; usługi przywrócono po izolacji i audycie). Z kolei zestawienia branżowe (Acronis/DSCI) wskazują, że Indie są jednym z najczęściej atakowanych rynków malware/ransomware globalnie.

Analiza techniczna / szczegóły luki

Nowy raport Rubrik Zero Labs („The Identity Crisis”) pokazuje, że tożsamość stała się główną powierzchnią ataku: napastnicy „żyją z zasobów” (Living-off-the-Land), nadużywając ważnych, ważnych i często uprawnień nadmiernych* kont – ludzkich i nieludzkich (usługi, boty, integracje, agenci AI). Kompromitacja poświadczeń pozwala ominąć klasyczne kontrole sieciowe i szybciej dotrzeć do kopii zapasowych, systemów MDM, chmur czy SaaS-ów. W tym modelu przywracalność (rapid recovery) staje się równie ważna, co prewencja.

Główne techniki napastników (z raportu i praktyki IR):

  • Kradzież/token hijacking (OAuth/OIDC), abuse refresh tokens.
  • „Password spraying” na Entra ID/Okta, następnie MFA bypass (MFA fatigue, token replay, fałszywe push-y).
  • Eskalacja uprzywilejowań w AD/Entra (misconfig, role assignment, stale app registrations).
  • Sabotaż kopii zapasowych: usuwanie snapshotów, wyłączanie retention/immutability.

Praktyczne konsekwencje / ryzyko

  • Wysoka skłonność do płacenia (91% w Indiach według Rubrika) utrzymuje rentowność grup ransomware i „double/triple extortion”.
  • Dłuższe RTO: tylko 32% firm jest gotowych na pełne odtworzenie ≤12h; duża część liczy >48h, co oznacza realne przerwy w przychodach i SLA.
  • Rozrost NHI i agentów AI zwiększa „blast radius”: każde konto/usługa wymaga cyklu kluczy, rotacji sekretów, kontroli skopów i krótkich TTL.

Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista nastawiona na Identity Resilience + Rapid Recovery:

  1. Twarde RPO/RTO oraz izolowalne kopie
  • Kopie w trybie immutable/WORM, air-gap lub logical gap; odrębne poświadczenia backup.
  • Testy odtworzeniowe runbook→automaty (np. Terraform/Ansible) z mierzeniem RTO co sprint.
  1. Least privilege i segmentacja tożsamości
  • Oddziel break-glass od SSO, z posiadaniem fizycznym (FIDO2).
  • Rotacje i short-lived tokens dla aplikacji/NHI; deny by default dla grantów „offline_access”.
  1. Hardening AD/Entra/IdP – szybkie kontrole techniczne
# (AD) Wykryj konta z delegacją nieograniczoną
Get-ADUser -Filter * -Properties TrustedForDelegation | ? {$_.TrustedForDelegation -eq $true}

# (AD) Znajdź członków grup uprzywilejowanych
Get-ADGroupMember "Domain Admins" -Recursive

# (Windows) Wykryj wyłączenia AV/EDR ustawione przez atakującego
Get-MpPreference | fl ExclusionPath,ExclusionProcess

# (Entra ID) Aplikacje z uprawnieniami wysokiego ryzyka
Get-MgServicePrincipal | ? {$_.AppRoleAssignmentRequired -eq $false} | 
  % { Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $_.Id }
  1. MFA odporne na phishing + polityki ryzyka
  • FIDO2/Passkeys dla uprzywilejowanych; blokady „impossible travel”; step-up przy wrażliwych akcjach (np. kasowanie snapshotów).
  1. Ochrona kopii i platform SaaS/Cloud
  • Wymuszaj 4-eyes i „time-delay” na kasowanie kopii; alarmuj na DeleteSnapshot, PutBucketVersioning, kms:DisableKey.
  • Wprowadź SaaS-backup z retencją niezależną od IdP.
  1. Detekcje gotowe do użycia (SPL/Sigma)
-- Splunk: podejrzane wyłączenie EDR/AV w Windows
index=win* EventCode=7036 Message="*stopped*" (Service_Name="*Defender*" OR Service_Name="*EDR*")
| stats count by host, Service_Name, _time

-- Entra ID: nietypowe tworzenie aplikacji/sekretów
index=azure_audit OperationName IN ("Add app role assignment", "Add service principal")
| stats count dc(host) by actor, target, location
  1. Runbook IR dla ransomware opartego o tożsamość
  • Natychmiast: zablokuj refresh tokens, wymuś reauth, rotuj klucze aplikacji (IdP/API/KMS).
  • Odtwarzaj najpierw IdP/PKI/backup-controller, dopiero potem workloady.
  1. Ćwiczenia krzyżowe
  • Co kwartał: purple team proti wektorom token theft/MFA bypass; pomiar MTTD/MTTR, RTO.

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

Rubrik pokazuje bardzo wysokie wskaźniki ataków i płatności w Indiach (79%/91%). Dla porównania, Sophos „State of Ransomware 2025” raportował globalnie niższe odsetki płatności (w Indiach ~53% ofiar deklarowało zapłatę; median ransom spadł do ok. 481 tys. USD), co pokazuje, że metodologie/okresy i dobór próby mocno wpływają na wyniki – ale trend „tożsamość w centrum” pozostaje spójny. CERT-In 2024 również akcentuje wzrost aktywności grup ransomware i zróżnicowanie TTP.

Podsumowanie / kluczowe wnioski

  • Ransomware w Indiach ma charakter tożsamościowy: atakujący celują w konta, tokeny i uprawnienia.
  • Odporność na poziomie tożsamości + szybkie odtwarzanie stają się krytyczne KPI cyber-odporności (RTO/RPO).
  • Firmy powinny automatyzować odtwarzanie (runbooki jako kod), zamykać luki w IdP i utwardzać kopie – bo to właśnie te obszary decydują, czy płacisz okup, czy wracasz do pracy bez płacenia.

Źródła / bibliografia

  • Deccan Herald: streszczenie badania Rubrik Zero Labs dot. Indii (15.11.2025). (Deccan Herald)
  • Rubrik Zero Labs – komunikat prasowy o „Identity Resilience” (13.11.2025) i strona raportu „The Identity Crisis”. (rubrik.com)
  • PDF raportu „The Identity Crisis” (Rubrik Zero Labs, 2025). (Rubrik)
  • Uzupełniające relacje o danych dla Indii (The Mobile Indian, ETTelecom). (The Mobile Indian)
  • Kontekst rynkowy: incydent C-Edge (Reuters, 31.07–01.08.2024). (Reuters)
  • Porównawczo: Sophos „State of Ransomware 2025” (Indie – płatności/median ransom). (SOPHOS)
  • CERT-In: „Ransomware Report 2024”. (cert-in.org.in)

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ę.

Checkout.com: incydent z „legacy” chmurą, próba szantażu ShinyHunters i nietypowa odpowiedź firmy

Wprowadzenie do problemu / definicja luki

Globalny operator płatności Checkout.com ujawnił naruszenie danych po próbie szantażu. Atakujący uzyskali dostęp nie do platformy przetwarzania płatności, lecz do dziedziczonego („legacy”) zewnętrznego systemu plików w chmurze, używanego w okolicach 2020 r. – zbiory dotyczyły m.in. dokumentów operacyjnych i materiałów onboardingowych dla merchantów. Firma podkreśla, że środki klientów ani numery kart nie były zagrożone. Checkout.com zadeklarował, że nie zapłaci okupu, a równowartość żądania przekaże na badania nad cyberprzestępczością (CMU i Oxford).

W skrócie

  • Data ujawnienia: 12–14 listopada 2025 r. (oświadczenie CTO + publikacje branżowe).
  • Wektor: dostęp do niewłaściwie zdekomisjonowanego zewnętrznego systemu plików w chmurze („legacy, third-party cloud file storage”).
  • Zakres: firma szacuje, że dotyczy to <25% obecnej bazy merchantów; brak dostępu do środków i numerów kart.
  • Sprawcy/brand: roszczenia przypisała sobie grupa ShinyHunters; sprawa osadzona jest w szerszym trendzie Scattered LAPSUS$ Hunters (federacja ShinyHunters/LAPSUS$/Scattered Spider).
  • Postawa firmy: brak płatności okupu + deklaracja darowizny na badania (CMU, Oxford).

Kontekst / historia / powiązania

ShinyHunters to znana grupa wymuszająca publikację danych (data extortion), która w 2025 r. bywa łączona w szersze przedsięwzięcie komunikacyjne określane jako Scattered LAPSUS$ Hunters (SLH) – luźna federacja łącząca TTPs kilku głośnych grup, nastawiona na wykradanie danych i szantaż medialny, niekoniecznie szyfrowanie środowisk ofiary. Ten paradygmat opiera się na szybkiej eskalacji PR (leaki, witryny DLS, Telegram) i wykorzystaniu błędów operacyjnych ofiar (np. niewyłączone integracje, stare zasoby chmurowe).

W przypadku Checkout.com, pierwsze doniesienia branżowe potwierdziły extortion attempt oraz to, że nie chodzi o „core” platformę (acquiring/processing), tylko o poboczny, historyczny zasób w chmurze.

Analiza techniczna / szczegóły luki

„Zombie w chmurze”: jak powstaje luka

Najczęstsze przyczyny ekspozycji „legacy cloud file storage”:

  1. Niepełna utylizacja zasobu – bucket / storage account pozostaje aktywny po migracji.
  2. Słabe tożsamości/aplikacje – zapomniane konta serwisowe, klucze dostępu, stare tokeny OAuth/refresh.
  3. Niewłaściwe ACL/udostępnienia – publiczne linki, szerokie „AllUsers/AllAuthenticatedUsers”.
  4. Brak SPM (Secret/Key Management) – klucze w repo, w starych CI/CD, na share’ach.
  5. Shadow IT / „3rd-party sprawl” – vendorowe konta w chmurach, poza centralnym zarządzaniem.

Typowe artefakty i ścieżki dostępu

  • Obiekty: PDF/DOCX onboarding, KYC/KYB, eksporty CSV, zrzuty konfiguracji.
  • Ślady w logach: GetObject, ListBucket, GetBlob, File.Read z rzadkich agentów i nietypowych ASN/VPN.
  • Kanały exfilu: bezpośredni zrzut przez API, czasem via skrypty Rclone/gsutil/azcopy.

Dlaczego „brak kart” i „brak środków” ma sens

System plików pomocniczych zwykle nie przechowuje PAN/CVV ani nie ma połączeń do środowisk PCI (segmentacja). Jeżeli tokenizacja i vault są w osobnych, „hardened” domenach, ryzyko się ogranicza do danych biznesowych/handlowych i PII merchantów – wciąż wrażliwych pod kątem fraudu B2B, spear-phishingu i supply-chain. (Potwierdzenie deklaracji firmy o braku numerów kart i środków: patrz oświadczenie CTO).

Praktyczne konsekwencje / ryzyko

  • Ryzyko łańcucha dostaw (TPRM): wyciek onboardingowych pakietów merchantów ułatwia impersonację (np. faktury, zmiana rachunku, BEC) i fraud na wypłatach.
  • Ryzyko compliance: potencjalne RODO/UK-GDPR (PII merchantów/osób kontaktowych), obowiązki notyfikacyjne wobec regulatorów finansowych.
  • Ryzyko operacyjne: wzrost SOC-volume (skany, próby logowania, phishing), konieczność reissuance kluczy API/sekretów, rotacja danych KYC.
  • Ryzyko reputacyjne: presja mediów i klientów; atakujący wykorzystują „narrację” brandu SLH do eskalacji żądań.

Rekomendacje operacyjne / co zrobić teraz

Poniżej gotowa checklista do użycia z zespołem IR/SecOps/Cloud (AWS/Azure/GCP analogicznie):

1) Natychmiastowe działania IR

  • Zamroź dostęp do zidentyfikowanego zasobu (deny-all / private endpoint / off-board).
  • Rotacja sekretów: klucze dostępu, SAS tokens, service principals, OAuth/refresh tokens, webhooks w integracjach.
  • Kontakt do podmiotów dotkniętych (merchanci/partnerzy), wstępne zawężenie atrybutów danych (zakres, daty, typy plików).
  • Zgłoszenia do regulatorów i organów ścigania (w UE: 72h RODO, w finansach – właściwi regulatorzy).

2) Telemetria i hunting (przykłady)

AWS S3 (CloudTrail Lake / Athena)

-- enumeracja podejrzanych operacji z rzadkich ASN
SELECT eventTime, userIdentity.sessionContext.sessionIssuer.arn AS principal,
       sourceIPAddress, requestParameters.bucketName, eventName, userAgent
FROM cloudtrail_logs
WHERE eventSource='s3.amazonaws.com'
  AND eventName IN ('GetObject','ListBucket','GetObjectAcl')
  AND sourceIPAddress NOT LIKE '10.%'
  AND from_iso8601_timestamp(eventTime) >= timestamp '2025-10-15';

Azure Storage (Log Analytics / KQL)

StorageBlobLogs
| where OperationName in ("GetBlob","ListBlobs","GetBlobProperties")
| where TimeGenerated > ago(60d)
| summarize cnt=count(), ips=make_set(CallerIpAddress) by AccountName, PrincipalId, OperationName, bin(TimeGenerated, 1d)
| order by cnt desc

GCP Cloud Storage (Audit Logs / BigQuery)

SELECT protopayload_auditlog.authenticationInfo.principalEmail AS principal,
       protopayload_auditlog.requestMetadata.callerIp AS ip,
       protopayload_auditlog.methodName AS method,
       resource.labels.bucket_name AS bucket,
       timestamp
FROM `project.logging.cloudaudit_googleapis_com_data_access_*`
WHERE protopayload_auditlog.serviceName = 'storage.googleapis.com'
  AND protopayload_auditlog.methodName IN ('storage.objects.get','storage.objects.list')
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY);

Sigma (uniwersalne) – masowe listowanie/eksfil plików przez „nietypowego” UA

title: Suspicious Cloud Object Bulk Access
logsource: category: webserver
detection:
  selection:
    cs-method|endswith:
      - GetObject
      - ListBucket
      - GetBlob
  filter_known_agents:
    cs-useragent:
      - 'aws-sdk/*'
      - 'Google-Cloud-Storage'
  condition: selection and not filter_known_agents
level: high

3) Twarde wyłączenie „martwych” zasobów w chmurze

  • Inwentaryzacja krzyżowa: CSPM + skanowanie API (np. aws s3 ls --profile legacy-account / az storage account list / gsutil ls -p <ID>).
  • Policy-as-code: globalne block public access, wymuszony KMS, lifecycle na auto-delete.
  • Kontrola tożsamości: znalezienie starych SP (az ad sp list --filter "appOwnerOrganizationId ne null" / przegląd IAM Roles bez rotacji).
  • „Third-party registry”: rejestr wszystkich zewnętrznych chmur/vendorów z cyklem życia i właścicielem (DPP – Data Processing Partners).

4) Komunikacja i PR bezpieczeństwa

  • Transparentne fakty techniczne (co, kiedy, czego nie obejmuje) – tak jak zrobił Checkout.com w swoim oświadczeniu.
  • Brak negocjacji na publicznych kanałach; zespół prawny monitoruje DLS/Telegram.
  • Oferta wsparcia dla dotkniętych partnerów (monitoring fraudu B2B, guidance dot. SPF/DKIM/DMARC, rotacja kluczy).

5) GRC i trwałe usprawnienia

  • Proces dekomisjonowania (runbook + kontrola dowodowa): owner → backup → wipe → tag „to-delete” → automatyczne zamknięcie IAM/Network → potwierdzenie (4-eyes).
  • TPRM: weryfikacja vendorów, szczególnie „third-party storage / file exchange”; audyty konfiguracji i SSO.
  • Table-top exercise dedykowany do data extortion bez szyfrowania.

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

  • Nie ransomware, a „pure data extortion”: brak szyfrowania, presja medialna + groźba publikacji.
  • Wejście przez „legacy third-party” vs. zero-day w core: ścieżka ataku omija „korowe” kontrole (PCI segment), wykorzystuje zapomniane peryferia.
  • Narracja SLH: federacyjny „brand” łączący TTPs i PR – widzieliśmy to przy kampaniach wymierzonych w integracje Salesforce w 2025 r. (publiczne „listy ofiar”, taktyki nagłaśniania).

Podsumowanie / kluczowe wnioski

  1. Największym ryzykiem nie był core processing, lecz „osierocone” zasoby chmurowe – klasyczny błąd operacyjny. 2) Dane onboardingowe i operacyjne mają znaczną wartość dla przestępców (fraud B2B, BEC, socjotechnika). 3) Model extortion-only wymaga osobnych playbooków IR (szybka inwentaryzacja danych, komunikacja, TPRM). 4) Decommissioning-by-design i centralny rejestr vendorów to obowiązkowy element higieny chmury. 5) Postawa „no-pay + darowizna” buduje narrację odporności, ale nie zastąpi twardych kontroli technicznych.

Źródła / bibliografia

  • Oświadczenie CTO Checkout.com (legacy 3rd-party storage, <25% merchant base, brak kart/środków, darowizna na CMU/Oxford). (Checkout)
  • SecurityWeek: podsumowanie incydentu i przypisanie do ShinyHunters, kontekst SLH. (SecurityWeek)
  • BleepingComputer: brak wskazania konkretnego dostawcy storage, potwierdzenie decyzji o darowiźnie zamiast okupu. (BleepingComputer)
  • The Register: relacja z cytatami deklaracji „We will not pay this ransom”. (The Register)
  • Trustwave SpiderLabs: analiza fenomenu Scattered LAPSUS$ Hunters i ich TTPs (kontekst kampanii 2025). (Trustwave)