Archiwa: Windows - Strona 52 z 70 - Security Bez Tabu

CVE-2025-59299: luka w Delta Electronics DIAScreen (błąd walidacji plików wejściowych) – analiza, ryzyko i zalecenia

Wprowadzenie do problemu / definicja luki

CVE-2025-59299 to podatność w oprogramowaniu Delta Electronics DIAScreen (narzędzie HMI/SCADA z ekosystemu DIAStudio). Błąd wynika z braku prawidłowej walidacji danych z pliku dostarczonego przez użytkownika, co skutkuje zapisywaniem poza końcem bufora podczas parsowania projektu (CWE-787). Do wykorzystania konieczne jest otwarcie przez użytkownika specjalnie spreparowanego pliku – efekt to wykonanie kodu w kontekście bieżącego procesu. Wersje podatne to wszystkie przed 1.6.1; producent opublikował aktualizację podnoszącą DIAScreen do v1.6.1.


W skrócie

  • Produkt: Delta Electronics DIAScreen
  • CVE: CVE-2025-59299
  • Klasyfikacja: CWE-787 Out-of-Bounds Write (błąd parsowania plików projektu DPA)
  • Wymagania ataku: interakcja użytkownika (otwarcie złośliwego pliku)
  • Skutki: RCE w kontekście procesu DIAScreen (wysokie CIA)
  • Ocena ryzyka: CVSS v3.1 7.8 (High); v4.0 6.8 (Medium) wg CNA
  • Wersje podatne: < 1.6.1; remediacja: aktualizacja do v1.6.1
  • Zakres: środowiska OT/ICS, szczególnie stacje inżynierskie/HMI z DIAStudio

Kontekst / historia / powiązania

Luka została ujawniona w pakiecie czterech podobnych błędów DIAScreen: CVE-2025-59297, -59298, -59299, -59300, wszystkie o charakterze Out-of-Bounds Write w parserze plików projektu. Producent opublikował formalną notę bezpieczeństwa Delta-PCSA-2025-00018 z jednoznaczną rekomendacją aktualizacji do v1.6.1. Zero Day Initiative przypisuje odkrycie badaczowi Natnael Samson (@NattiSamson) i potwierdza wektor: złośliwy plik DPA → parsowanie → OOB write → RCE.


Analiza techniczna / szczegóły luki

Gdzie jest błąd?
W komponencie parsującym pliki projektu .DPA. Plik zawiera strukturę danych, która – przy braku rygorystycznej walidacji długości/pól – może spowodować zapis danych poza zaalokowaną strukturą. To klasyczny heap/stack OOB write (CWE-787), który umożliwia nadpisanie wskaźników/kontrolnych struktur pamięci i w konsekwencji przejęcie przepływu wykonania.

Warunki ataku:

  • Ofiara otwiera złośliwy plik w DIAScreen (wektor „file-based”).
  • Uprawnienia nie są wymagane ponad domyślne (PR:N), ale to atak lokalny z UI:R (użytkownik musi otworzyć plik).
  • Po udanym wywołaniu błędu możliwe jest RCE w kontekście użytkownika uruchamiającego DIAScreen.

Metadane CVSS (NVD):

  • CVSS v3.1: 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
  • CVSS v4.0 (CNA): 6.8 (UI:A, VA:H, itd.)
    W praktyce, na stacjach inżynierskich OT konsekwencje te często przekładają się na wysokie ryzyko operacyjne (kontekst HMI/SCADA).

Praktyczne konsekwencje / ryzyko

Scenariusze nadużyć w OT/ICS:

  1. Spear-phishing do inżynierów/techników – załącznik „aktualizacja projektu.dpa”; po otwarciu dochodzi do RCE i osadzenia implantu w środowisku HMI.
  2. Wymiana plików przez pamięci USB w strefach z ograniczoną łącznością – wektor popularny w fabrykach i na liniach produkcyjnych.
  3. Złośliwy projekt na serwerze wersji (np. share SMB) – podmiana pliku projektu, kompromitacja kolejnych stacji.

Skutek biznesowy: przejęcie stacji inżynierskiej/HMI może pozwolić na manipulację ekranami sterowania, zmianę receptur/parametrów, czy sabotaż procesu przy dalszym ruchu bocznym. Brak izolacji IT/OT i słaba segmentacja zwiększają prawdopodobieństwo eskalacji.

Źródła potwierdzają wektor i wpływ wprost (RCE po otwarciu pliku) oraz wskazują na pakiet czterech CVE w tej samej klasie błędów.


Rekomendacje operacyjne / co zrobić teraz

1) Patching i inwentarz

  • Zaktualizuj DIAScreen do v1.6.1 lub nowszej na wszystkich stacjach inżynierskich/HMI. To oficjalna i jednoznaczna rekomendacja producenta.
  • Zidentyfikuj instalacje (Windows) i sprawdź wersję aplikacji:
# Wykrywanie zainstalowanego DIAScreen i wersji w rejestrze (Apps & Features)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
                 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' `
| Where-Object { $_.DisplayName -match 'DIAScreen' } `
| Select-Object DisplayName, DisplayVersion, Publisher, InstallLocation

Jeżeli skrypt nie zwróci wyniku, przeszukaj dysk pod kątem katalogów DIAStudio/DIAScreen i sprawdź wersję plików binarnych (Właściwości → Szczegóły).

2) „Virtual patching” i twardnienie do czasu aktualizacji

  • Zabroń/ogranicz otwieranie plików .DPA z lokacji ryzykownych (Downloads, %TEMP%, nośniki wymienne) – reguła SRP/AppLocker (Path/Hash).
  • Polityki pocztowe: blokada lub kwarantanna załączników .dpa, tagowanie detekcji w bramce pocztowej (DLP/ATP).
  • Kontrola nośników USB: whitelisting urządzeń, skan AV/EDR, auto-kwarantanna plików .dpa zewnętrznych.
  • Segmentacja sieci OT: stacje z DIAScreen za zaporą, brak dostępu z sieci biurowej; zdalny dostęp tylko VPN i tylko z listy dozwolonych.

3) Monitoring i detekcja (przykłady)

Sigma (Windows) – podejrzane otwarcia plików DPA z lokalizacji wysokiego ryzyka:

title: Suspicious DIAScreen Project Open From Risky Locations
id: 1b1a1e0c-6f6b-4d40-b1e5-7d1f4f5a9da9
status: experimental
logsource:
  category: file_event
  product: windows
detection:
  selection_ext:
    TargetFilename|endswith: '.dpa'
  selection_paths:
    TargetFilename|contains:
      - '\Downloads\'
      - '\Temp\'
      - '\$Recycle.Bin\'
      - '\RemovableDrive\'
  condition: selection_ext and selection_paths
level: medium
tags:
  - attack.initial_access
  - attack.t1204.002  # Malicious File

Sysmon – nietypowe wywołanie DIAScreen po otwarciu projektu:

<!-- Sysmon Event ID 1: Process Create -->
<RuleGroup name="DIAScreen Suspicious Launch" groupRelation="or">
  <ProcessCreate onmatch="include">
    <Image condition="end with">DIAScreen.exe</Image>
    <ParentImage condition="contains">\Temp\</ParentImage>
  </ProcessCreate>
  <ProcessCreate onmatch="include">
    <Image condition="end with">DIAScreen.exe</Image>
    <CommandLine condition="contains">.dpa</CommandLine>
  </ProcessCreate>
</RuleGroup>

EDR/AV: stwórz watchlist na proces DIAScreen.exe otwierający .dpa z „niezaufanych” ścieżek i na crash/exception w procesie (częsty artefakt prób OOB write).

4) Procedury użytkownika / szkolenia

  • Nie otwieraj plików projektu otrzymanych e-mailem/IM bez walidacji źródła.
  • W środowiskach air-gapped – skan nośników przed importem projektów.

Różnice / porównania z innymi przypadkami (pakiet CVE dla DIAScreen)

Zarówno CVE-2025-59297, -59298, -59299, jak i -59300 dotyczą tej samej klasy błędu (CWE-787) w parserze DIAScreen i są naprawione w v1.6.1. Różnią się one lokalizacją w kodzie/ścieżką parsowania i mogą być wyzwalane przez odmienne pola pliku. Z punktu widzenia obrony operacyjnej: te same kontrole (aktualizacja, polityki plików, segmentacja, monitoring) redukują ryzyko dla całego pakietu.


Podsumowanie / kluczowe wnioski

  • To błąd „file-open → RCE”: wystarczy otwarcie złośliwego projektu .DPA.
  • Ryzyko realne w OT/ICS, bo DIAScreen działa na stacjach inżynierskich/HMI.
  • Patch do v1.6.1 jest dostępny i zalecany natychmiast.
  • Do czasu aktualizacji: blokuj .DPA z nieznanych źródeł, egzekwuj segmentację i monitoruj użycie DIAScreen.
  • Wprowadź procedury operacyjne: kontrola nośników, polityki pocztowe, szkolenia użytkowników.

Źródła / bibliografia

  1. Vendor advisory (PDF): „Delta-PCSA-2025-00018 – DIAScreen File Parsing Out-Of-Bounds Write Vulnerabilities” – wersje podatne < 1.6.1, CVSS v3.1=7.8, rekomendacja aktualizacji do v1.6.1. (PDF)
  2. NVD – CVE-2025-59299: opis „lacks proper validation of the user-supplied file”, metryki CVSS v3.1=7.8, wskazanie na wersje do <1.6.1 i link do advisory producenta. (NVD)
  3. ZDI-25-970: „DPA File Parsing Out-Of-Bounds Write RCE”, UI:R, RCE w kontekście bieżącego procesu, timeline i odniesienie do CISA. (zerodayinitiative.com)
  4. Ameeba Exploit Tracker – wpis o CVE-2025-59299: streszczenie luki (wektor plikowy, RCE po otwarciu). (Użyte jako źródło drugorzędne/uzupełniające). (Ameeba)
  5. Strona przeglądowa Delta – Product Cybersecurity Advisory: potwierdza istnienie advisory i politykę publikacji po dostępności poprawek. (deltaww.com)

Uwaga operacyjna: NVD i advisory producenta wprost wskazują v1.6.1 jako próg naprawy; utrzymuj ten numer jako twardy warunek zgodności w CMDB/OT asset management i audytach patch compliance.

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.

Jak Rozpoznać Atak Prowadzony Przez AI? Praktyczny Przewodnik Dla SOC I Blue Teamu

Dlaczego to ma znaczenie?

Ataki cybernetyczne ewoluują – napastnicy coraz częściej wykorzystują sztuczną inteligencję (AI) do automatyzacji i skalowania swoich działań. Dlaczego Blue Team powinien się tym przejmować? Przede wszystkim, AI pozwala atakującym na szybsze i bardziej złożone kampanie, które mogą przerosnąć tradycyjne metody detekcji. Amazon raportuje obecnie niemal miliard prób ataków dziennie, co częściowo przypisuje właśnie wykorzystaniu AI przez obie strony konfliktu.

Czytaj dalej „Jak Rozpoznać Atak Prowadzony Przez AI? Praktyczny Przewodnik Dla SOC I Blue Teamu”