Archiwa: Phishing - Strona 82 z 98 - Security Bez Tabu

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)

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

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

Wprowadzenie do problemu / definicja luki

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

W skrócie

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

Kontekst / historia / powiązania

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

Analiza techniczna / szczegóły luki

1) Warstwa IT (Enterprise)

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

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

Wskaźniki obserwacyjne (przykładowe):

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

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

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

3) Wiarygodność deklaracji

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

Praktyczne konsekwencje / ryzyko

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

Rekomendacje operacyjne / co zrobić teraz

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

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

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

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

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

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

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

Anycast/DNS i „fronty” anty-DDoS

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

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

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

3) Detekcja & reagowanie (SOC)

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

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

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

Alerting (Prometheus/Grafana)

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

4) Segmentacja i „blast radius”

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

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

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

Różnice / porównania z innymi przypadkami

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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

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)

Washington Post: wyciek danych prawie 10 tys. pracowników po ataku przez lukę w Oracle E-Business Suite

Wprowadzenie do problemu / definicja luki

„The Washington Post” poinformował o naruszeniu danych obejmującym 9 720 obecnych i byłych pracowników oraz kontraktorów. Atakujący uzyskali dostęp do środowiska ERP gazety wykorzystując wtedy nieznaną (zero-day) podatność w Oracle E-Business Suite (EBS), a następnie wykradli dane i podjęli próbę wymuszenia okupu. Do incydentu doszło w okresie 10 lipca – 22 sierpnia 2025 r., a jego potwierdzenie nastąpiło po dochodzeniu zakończonym 27 października 2025 r.. Wykradzione informacje obejmują imiona i nazwiska, numery kont i routingu bankowego oraz numery Social Security / NIP-y.

Według zgodnych relacji mediów branżowych, za kampanię stoi grupa Cl0p, znana z masowych ataków na łańcuch dostaw i operacje typu data theft + extortion.


W skrócie

  • Kogo dotyczy: prawie 10 tys. osób powiązanych z Washington Post (pracownicy, byli pracownicy, kontraktorzy).
  • Co wyciekło: dane tożsamości + wrażliwe dane finansowe (kont bankowych) oraz SSN/Tax ID.
  • Wektor ataku: pre-auth RCE w Oracle EBS wykorzystywana jako 0-day (CVE-2025-61882) i powiązana luka CVE-2025-61884 (przerwanie łańcucha eksploatacji).
  • Taktyka przeciwnika: cicha infiltracja, eksfiltracja danych HR/finansowych, następnie szantaż mailowy kierowany do kierownictwa.
  • Czas wykrycia: sygnałem były wiadomości od „bad actor” z 29 września; organizacja powiązała je z podatnością ujawnioną przez Oracle w październiku.

Kontekst / historia / powiązania

Kompromitacja Washington Post to element szerszej kampanii wymierzonej w klientów Oracle EBS. Oracle opublikował Alert bezpieczeństwa dla CVE-2025-61882 (pre-auth RCE) 4 października 2025 r., a następnie kolejną łatę dla CVE-2025-61884, co miało utrudnić łańcuch nadużyć. W tle firmy zgłaszały zmasowane maile z żądaniami okupu i groźbami publikacji danych. Analizy Google Cloud Threat Intelligence wskazują, że aktywność napastników zaczęła się najpóźniej na początku sierpnia, a ślady sięgają 10 lipca 2025 r.—czyli zanim patch był dostępny.


Analiza techniczna / szczegóły luki

Co to za podatności?

  • CVE-2025-61882zdalne wykonanie kodu bez uwierzytelnienia w komponencie Oracle E-Business Suite / Concurrent Processing (BI Publisher Integration). Eksploatacja możliwa z poziomu sieci bez konta użytkownika. CVSS wysoki/krytyczny.
  • CVE-2025-61884 – kolejna krytyczna luka w EBS, również pre-auth, opublikowana po wzmożonych atakach, aby zatrzymać łańcuch exploitów wykorzystywany przez przestępców.

Niezależne raporty badaczy (Google Cloud) łączą kampanię z Cl0p i opisują etapową eksploatację: wejście do aplikacji EBS przez 0-day, zagnieżdżenie w warstwie aplikacyjnej, eksfiltrację plików HR/finansowych oraz mailową eskalację żądań do kadry kierowniczej. W wielu organizacjach napastnicy działali tygodniami, zanim Oracle opublikował poprawki.

Dlaczego EBS jest tak atrakcyjnym celem?

EBS scala krytyczne procesy (HR, kadry-płace, finanse, łańcuch dostaw). Dostęp aplikacyjny = dostęp do baz danych z danymi płacowymi i identyfikatorami podatkowymi. To „złoto” dla operacji kradzieży tożsamości i przejęć wynagrodzeń (payroll diversion).

Jak mogła wyglądać ścieżka ataku (model uproszczony)?

  1. Wejście: zdalny exploit (pre-auth RCE) w EBS.
  2. Utrwalenie: artefakty w katalogach aplikacji / jobach „Concurrent Processing”, ew. zmiany w szablonach raportów.
  3. Eksfiltracja: bezpośrednio z serwera app/DB lub przez zadania raportowe (BI Publisher).
  4. Szantaż: e-maile do C-level/Legal z próbką danych i żądaniem okupu.

Praktyczne konsekwencje / ryzyko

Dla osób, których dane wyciekły:

  • Ryzyko kradzieży tożsamości (SSN/Tax ID), fraudów finansowych (numery kont/routing), ataków socjotechnicznych (targeted phishing). Washington Post oferuje 12–24 mies. monitoringu tożsamości (IDX).

Dla organizacji korzystających z Oracle EBS:

  • Ryzyko masowe: identyczny wektor dostępny przeciwko setkom instalacji (character of 0-day + szerokie wdrożenia).
  • Ryzyko regulacyjne: obowiązki notyfikacyjne (AG, regulatorzy sektorowi), możliwe pozwy zbiorowe.

Rekomendacje operacyjne / co zrobić teraz

Poniższe kroki można potraktować jako checklistę IR/defense dla zespołów SecOps/IT-ERP.

1) Natychmiastowe łatanie i twardnienie

  • Zastosuj łatę Oracle dla CVE-2025-61882 oraz CVE-2025-61884 (właściwy alert + CPU Oct 2025). Zweryfikuj poziom łat w każdym środowisku (prod/UAT/dev).
  • Włącz WAF/IPS z regułami wirtualnego łatania dla znanych wzorców żądań do komponentów EBS (BI Publisher/Concurrent Processing).
  • Ogranicz dostęp z internetu – EBS powinien być publikowany wyłącznie przez bramę z kontrolą tożsamości/segregacją i DLP.

2) Okno dochodzeniowe i triage

Oracle oraz niezależne analizy wskazują na aktywność napastników od lipca–sierpnia 2025. Przejrzyj logi od 1 lipca 2025 r. do dziś.
Minimalny zestaw artefaktów do sprawdzenia:

  • Logi HTTP/app serwera EBS (nietypowe błędy XSL/XDO, wywołania raportów, uploady szablonów).
  • Harmonogram „Concurrent Manager” – nowe/zmodyfikowane joby, zwłaszcza te uruchamiane przez konta techniczne.
  • Ślady eksfiltracji (duży outbound z app tier, połączenia do nietypowych hostów).
  • Konta uprzywilejowane – świeże dodania / zmiany haseł / eskalacje ról.

3) Szybkie reguły detekcyjne (przykłady)

Splunk (HTTP access – anomalie względem BI Publisher / XDO):

index=web OR index=ebs_logs sourcetype=access_combined
("xmlpserver" OR "xdo" OR "bipublisher")
| stats count avg(bytes) sum(bytes) values(status) by src, uri_path, http_method
| where count > 50 OR sum(bytes) > 50000000

Elastic/KQL (egress z hostów app EBS):

host.name : ("ebs-app-*") and
destination.bytes >= 10485760 and
not destination.ip in (internal_ranges)

Sigma (modyfikacja szablonów/artefaktów EBS – przykład ogólny):

title: Oracle EBS Suspicious BI Publisher Template Change
logsource:
  product: linux
  service: auditd
detection:
  selection:
    evt.type: "PATH"
    file.path|contains:
      - "/xmlpserver/" 
      - "/xdo/" 
  condition: selection
level: medium

Uwaga: ścieżki/artefakty dopasuj do konkretnej instalacji EBS (nazwa instancji, katalogi custom). Celem jest szybkie wyłapanie nietypowych modyfikacji.

4) Ochrona danych osobowych (HR/Payroll)

  • Rotacja tajemnic: hasła DB, konta integracyjne, klucze API do systemów płacowych.
  • Zamrożenie zmian płatniczych i weryfikacja na dwóch kanałach dla dyspozycji dot. kont wynagrodzeń.
  • Notyfikacja i wsparcie: zaoferuj monitoring kredytowy/kradzieży tożsamości – tak, jak zrobił Washington Post (IDX).

5) Długofalowe kontrole

  • Segmentacja: EBS w osobnej strefie, minimalny ruch do/z Internetu, egress ograniczony listami FQDN.
  • SBOM/asset inventory dla ERP i proces „patch SLO” z testowaniem off-cycle (poza CPU).
  • Kontrola zmian EBS – śledzenie szablonów BI Publisher, jobów „Concurrent Processing”, ról EBS (alerting na odchylenia).

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

Atak na EBS przypomina kampanię Cl0p na MOVEit (2023)ten sam wzorzec: 0-day w popularnym produkcie, szybka eksfiltracja, szantaż masowy. Różnica: w EBS stawką są pełne rekordy HR/finansowe (SSN + konta bankowe), co eskaluje ryzyko w porównaniu z wieloma „typowymi” wyciekami PII. Doniesienia mówią także o żądaniach do 50 mln USD, co podkreśla presję finansową na ofiary.


Podsumowanie / kluczowe wnioski

  • Wysoka krytyczność: pre-auth RCE w systemie klasy ERP = natychmiastowy priorytet łatania i monitoringu.
  • Długi dwell time 0-day: aktywność trwała przed publikacją łat, więc okno dochodzeniowe musi być szerokie (min. od lipca 2025).
  • Konsekwencje realne, nie hipotetyczne: wyciek SSN i danych bankowych zwiększa ryzyko fraudów – wdrożyć procesy anty-fraud w HR/Payroll.
  • Nie tylko jedna ofiara: kampania ma charakter seryjny – jeśli masz EBS, załataj, przeszukaj, utwardź.

Źródła / bibliografia

  1. BleepingComputer – szczegóły incydentu, skala, typy danych, przebieg czasowy. (BleepingComputer)
  2. Pismo notyfikacyjne Washington Post do poszkodowanych (CA OAG) – daty, zakres danych, działania naprawcze.
  3. Oracle Security Alert – CVE-2025-61882 (pre-auth RCE w EBS). (Oracle)
  4. Google Cloud Threat Intelligence – oś czasu ataków na EBS i atrybucja kampanii. (Google Cloud)
  5. CyberScoop – kontekst kampanii Cl0p wobec klientów Oracle i zakres wycieku w WP. (CyberScoop)

#StopRansomware: Akira – aktualizacja 13.11.2025. Nowe TTP, wektory wejścia przez SonicWall i ataki na Nutanix AHV

Wprowadzenie do problemu / definicja luki

13 listopada 2025 r. opublikowano zaktualizowaną wspólną poradę (#StopRansomware) dot. grupy Akira. Dokument (AA24-109A) ostrzega o pilnym zagrożeniu dla infrastruktury krytycznej, nowych technikach oraz wskaźnikach kompromitacji (IOC). Najistotniejszy wątek: wejście przez urządzenia VPN (szczególnie SonicWall, CVE-2024-40766) i rozszerzenie szyfrowania na maszyny wirtualne Nutanix AHV, obok już znanych ataków na VMware ESXi/Hyper-V.


W skrócie

  • Wejście: nadużycie urządzeń VPN (m.in. SonicWall, CVE-2024-40766), podatnych usług/urządzeń brzegowych, nie-MFA, spearphishing, hasła wyciekłe/wypryskiwane (password spraying).
  • Rozszerzenie celu: pierwsze potwierdzone szyfrowanie dysków Nutanix AHV (czerwiec 2025).
  • TTP: nltest do odkrywania domen, Impacket/wmiexec, zdalne narzędzia (AnyDesk/LogMeIn), wyłączanie EDR, BYOVD/terminowanie AV.
  • Skala zysków: ~244,17 mln USD do IX 2025 r. (zgłoszenia śledcze FBI).

Kontekst / historia / powiązania

Akira działa co najmniej od marca 2023 r., początkowo Windows + rozszerzenie .akira, potem Megazord (Rust, rozszerzenie .powerranges) oraz Akira_v2; cele na wielu kontynentach i sektorach (produkcja, edukacja, IT, zdrowie, finanse, F&A). Autorzy łączą Akirę z aliasami Storm-1567/Howling Scorpius/Punk Spider/Gold Sahara i możliwymi koneksjami do upadłej Conti.

Od połowy 2025 r. obserwowano kampanię przeciw SonicWall SSL VPN – potwierdzoną też przez CERT-y/branżę (ACSC/ASD, vendor SonicWall, analizy Darktrace/Arctic Wolf).


Analiza techniczna / szczegóły luki

Wejście (Initial Access)

  • VPN bez MFA i znane CVE w produktach sieciowych, w tym Cisco (np. CVE-2020-3259, CVE-2023-20269), oraz SonicWall CVE-2024-40766. Dodatkowo Veeam (CVE-2023-27532, CVE-2024-40711). Często password spraying (np. SharpDomainSpray), RDP, kradzież poświadczeń, a także SSH przez router z publicznym IP.

Przykładowe zapisy do detekcji (Sigma, logon VPN SonicWall – event nieudany/udany z nietypowego ASN/geo):

title: SonicWall SSLVPN Suspicious Geo ASN Login
logsource:
  product: sonicwall
  service: sslvpn
detection:
  selection:
    outcome: success
  filter_geo:
    src_country|contains:
      - 'CN'
      - 'RU'
      - 'BR'
  condition: selection and filter_geo
level: medium
tags: [attack.t1110, initial-access]

Wykonanie (Execution)

  • Częste użycie VBScript do wykonywania poleceń i automatyzacji.

Trwałość / Ruch rozpoznawczy

  • Tworzenie nowych kont domenowych (spotykana nazwa itadm), Kerberoasting, zrzut LSASS (Mimikatz/LaZagne), skanowanie (SoftPerfect/Advanced IP Scanner/NetScan), polecenia net oraz nltest /dclist, nltest /DOMAIN_TRUSTS.

Szybki „hunt” w Windows (PowerShell):

# Nowo utworzeni członkowie Domain Admins w 7d
Get-ADGroupMember "Domain Admins" |
  ForEach-Object { Get-ADUser $_ -Properties whenCreated } |
  Where-Object { $_.whenCreated -gt (Get-Date).AddDays(-7) } |
  Select-Object Name, SamAccountName, whenCreated

# Artefakty net/nltest w PowerShell Operational (ID 4104/4103) i Security 4688
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5000 |
  Where-Object {$_.Message -match 'nltest|net.exe'}

Unikanie obrony / Lateral Movement

  • PowerTool + podatny sterownik (BYOVD) do zabijania procesów AV/EDR (m.in. wyłączenie Defendera), nadużycie AnyDesk/LogMeIn, Impacket wmiexec.py, odinstalowanie EDR przed szyfrowaniem.

Szyfrowanie / Wpływ na wirtualizację

  • Po ESXi/Hyper-V, czerwiec 2025: szyfrowanie dysków VM Nutanix AHV – istotna zmiana dla środowisk HCI.

Praktyczne konsekwencje / ryzyko

  • Urządzenia brzegowe (SonicWall) stają się „jednym kliknięciem” do sieci wewnętrznej – nawet z MFA (doniesienia o przejętych seedach OTP/artefaktach pozwalających omijać MFA). Uderza to w model „MFA-i-po-sprawie”.
  • Wirtualizacja: przejście z ESXi/Hyper-V na Nutanix AHV rozszerza powierzchnię ataku i podnosi koszt RTO/RPO przy incydencie.
  • Utrudniona detekcja przez nadużycie legalnych narzędzi, wyłączanie EDR i użycie Impacket w ruchu bocznym.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast załataj i utwardź SonicWall (CVE-2024-40766), zresetuj poświadczenia SSL VPN, rozważ rotację/ponowną rejestrację sekretów OTP/MFA; zaktualizuj do najnowszego SonicOS 7.3.x, zastosuj zalecenia producenta.
  2. Wymuś phishing-resistant MFA (FIDO2/WebAuthn) oraz blokady po wielu nieudanych próbach; ogranicz wskazówki haseł, nie wymuszaj zbyt częstych zmian (zgodnie z NIST), ale wymuś rotację po incydencie VPN.
  3. Segmentacja i zasada najmniejszych uprawnień (kontrola przepływów, izolacja serwerów zarządzania hipernadzorcą/backupem).
  4. Kopie offline + testy odtwarzania (szczególnie VM AHV/ESXi/Hyper-V i repozytoria Veeam).
  5. Monitoring anomalii sieciowych i EDR: wykrywaj nltest/net, wmiexec/Impacket, instalacje AnyDesk/LogMeIn, próby deinstalacji EDR. (Patrz sekcja „hunt”.)
  6. Blokuj narzędzia BYOVD (wdrożenia HVCI/Blocklist sterowników Microsoft, AppControl), monitoruj ładowanie nietypowych sterowników (Sysmon ID 6).
  7. Dodatkowe źródła IOC i ATT&CK mapping – pobierz STIX z aktualizacji AA24-109A i wprowadź do SIEM/SOAR.

Przykładowe reguły (Sysmon/Sigma) – Impacket & nltest:

title: Impacket WMIExec Child Of Python
logsource: { product: windows, service: sysmon }
detection:
  sel1: { EventID: 1, ParentImage|endswith: '\python.exe', Image|endswith: '\wmic.exe' }
  sel2: { EventID: 3, DestinationPort: 135 }  # DCOM
  condition: sel1 or sel2
level: high
tags: [attack.t1047, lateral-movement]

---
title: Domain Discovery with nltest
logsource: { product: windows, service: security }
detection:
  sel: { EventID: 4688, NewProcessName|endswith: '\nltest.exe' }
  condition: sel
level: medium
tags: [attack.t1018,t1482]

Przykładowe zapory/SDN – ogranicz RDP/SMB/WMI do stref adminów:

# Linux nftables - blokuj SMB z podsieci użytkowników do serwerów
nft add rule inet filter forward ip saddr 10.20.0.0/16 ip daddr 10.30.10.0/24 tcp dport {445,139} drop

Różnice / porównania z innymi przypadkami

  • LockBit/ALPHV długo stawiały głównie na ESXi/Hyper-V; Akira jako jedna z pierwszych operacji potwierdzenie ataków na Nutanix AHV, co wymusza aktualizację playbooków IR/BCP dla HCI.
  • Akcent na SonicWall SSL VPN – rzadziej spotykany tak skoncentrowany wektor u konkurencyjnych grup w 2025 r.; zbieżne ostrzeżenia rządowe (ACSC) i vendor.

Podsumowanie / kluczowe wnioski

  1. Brzeg (VPN) to główna brama – łataj i rotuj sekrety. 2) AHV jest już na celowniku – ćwicz odtwarzanie VM poza hipernadzorcą. 3) Detekcja TTP (Impacket/nltest/AnyDesk) i ochrona przed BYOVD muszą być obowiązkowym elementem. 4) Wdróż MFA odporne na phishing i egzekwuj najmniejsze uprawnienia. 5) Pobierz i wprowadź IOC z AA24-109A (STIX).

Źródła / bibliografia

  1. FBI/CISA/DC3/HHS/EC3/NCSC-NL i in., #StopRansomware: Akira Ransomware – aktualizacja 13.11.2025 (AA24-109A). Zawiera TTP/IOC, MITRE ATT&CK i zalecenia.
  2. CISA – strona poradnika AA24-109A (mirror + opis aktualizacji). (CISA)
  3. ACSC/ASD – alert dot. aktywnej eksploatacji CVE-2024-40766 (SonicWall) i powiązania z Akirą. (Cyber.gov.au)
  4. SonicWall – komunikat producenta nt. zagrożeń dla Gen7 i SSLVPN oraz działań naprawczych. (SonicWall)
  5. BleepingComputer – wzmianka o szyfrowaniu Nutanix AHV przez Akirę (potwierdzenie trendu z AA24-109A). (BleepingComputer)