Archiwa: SIEM - Strona 39 z 46 - Security Bez Tabu

CVE-2010-2568 — Windows Shell LNK RCE (MS10‑046)

TL;DR

  • Luka w Windows Shell umożliwia zdalne wykonanie kodu przy samym wyświetleniu ikony spreparowanego skrótu .LNK/.PIF (bez kliku). Załatana w biuletynie MS10‑046 (KB2286198).
  • Realne zagrożenie: USB/udziały sieciowe/WebDAV → otwarcie folderu z LNK uruchamia kod napastnika. To był kluczowy wektor Stuxnet.
  • Mapowanie na ATT&CK: T1203, T1204.002, T1091 (replikacja przez nośniki).
  • Detekcja: Sysmon EID 7 (ImageLoad) z explorer.exe ładuje DLL z nośnika wymiennego, EID 1 (ProcessCreate) dla rundll32.exe z literą dysku USB; korelacja z USBDriveMounted w MDE.
  • Remediacja: Patch MS10‑046, blokady ASR/Device Control na USB, ograniczenie AutoRun/AutoPlay, polityki nośników.

Krótka definicja techniczna

CVE‑2010‑2568 to błąd w parsowaniu skrótów przez Windows Shell: podczas ładowania ikony skrótu (.LNK/.PIF) system może załadować i wykonać bibliotekę DLL wskazaną w polu zasobu ikony. Do eksploatacji dochodzi już na etapie renderowania ikon w Explorerze (i innych parserach), co daje RCE z uprawnieniami zalogowanego użytkownika.


Gdzie występuje / przykłady platform

  • Windows: XP SP3, Server 2003 SP2, Vista SP1/SP2, Server 2008 (w tym R2), Windows 7 — wszystkie dotknięte i ocenione jako Critical w MS10‑046 (serwer Core również podatny w niektórych scenariuszach).
  • Active Directory / DC: dotyczy, jeśli kontrolery domeny to ww. wersje Windows.
  • Chmury (AWS/Azure/GCP): Windows VM/WorkSpaces/VDI dziedziczą podatność do czasu aktualizacji.
  • ESXi/K8s/M365: sama luka dot. Windows; środowiska te są istotne jako źródła logów (Sentinel, Elastic, SIEM) i kontroli USB (MDE Device Control).

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

Atakujący tworzy skrót .LNK, którego metadane (np. zasób ikony) wskazują DLL położoną na nośniku wymiennym (USB), udziale UNC/WebDAV lub innym zasobie. Windows Explorer przy renderowaniu ikony odwołuje się do tej ścieżki i ładuje bibliotekę, co w wariancie podatnym daje arbitralne wykonanie kodu — bez interakcji użytkownika i bez uruchamiania celu skrótu. Skuteczność wynika z (1) powszechnego przeglądania folderów poprzez GUI, (2) faktu, że ikony ładowane są automatycznie oraz (3) łatwości wprowadzenia LNK na host (np. USB). Microsoft załatał błąd w MS10‑046/KB2286198, poprawiając walidację referencji do ikon.

Historyczny kontekst: Stuxnet używał CVE‑2010‑2568 do propagacji m.in. przez nośniki, co pozwalało pokonać segmentacje/air‑gap w środowiskach ICS.


Artefakty i logi (co i gdzie obserwować)

Źródło/produktZdarzenie / IDCo szukaćUwagi
SysmonEID 7 (Image loaded)Image = *\explorer.exe i ImageLoaded wskazuje na ścieżkę z literą dysku (np. E:\*.dll), brak podpisuEID 7 domyślnie wyłączony; włączyć selektywnie dla explorer.exe.
SysmonEID 1 (Process Create)rundll32.exe lub regsvr32.exe z argumentem do X:\*.dll; rodzic explorer.exeCzęsty łańcuch po wczytaniu złośliwej biblioteki.
Windows Security4688 (Process Create)Jak wyżej (jeśli brak Sysmon)Mniej kontekstu niż Sysmon.
MDE (Defender XDR)DeviceImageLoadEventsŁadowanie DLL przez explorer.exe z nie‑systemowych wolumenówTabela dla zdarzeń DLL.
MDE (Defender XDR)DeviceEventsActionType == "UsbDriveMounted"; AdditionalFields.DriveLetterKorelować z EID 7/EID 1 w krótkim oknie czasowym.
MDE (Defender XDR)DeviceFileEventsTworzenie/kopiowanie LNK na USBPrzy replikacji przez nośniki.
AWS CloudTrailN/D dla zdarzeń OSCloudTrail rejestruje API/AWS account activity, nie telemetrykę hosta. Używać CloudWatch Logs dla agentów zdarzeń Win/Sysmon.
K8s audit / M365 ops[brak danych / nie dotyczy]Luka dotyczy Windows Shell lokalnie.

Detekcja (praktyczne reguły)

Sigma (Sysmon ImageLoad + korelacja)

title: Possible CVE-2010-2568 Exploitation via Explorer DLL Load from Removable
id: 9d1f5c1f-9b0e-4f16-9d6a-ef7a3a2c2568
status: experimental
description: Detects explorer.exe loading an unsigned DLL from a non-system drive (often USB) – pattern linked to CVE-2010-2568 exploitation.
references:
  - https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-046
  - https://attack.mitre.org/techniques/T1091/
logsource:
  product: windows
  service: sysmon
  category: image_load
detection:
  selection:
    Image|endswith: '\explorer.exe'
    ImageLoaded|re: '^[A-Z]:\\.*\.dll$'
  unsigned:
    Signed: 'false'
  condition: selection and unsigned
fields:
  - Image
  - ImageLoaded
  - Signed
  - SignatureStatus
  - Hashes
level: high
tags:
  - attack.t1203
  - attack.t1091

Splunk (SPL) – 2 wzorce

A) DLL ładowana przez Explorera z dysku poza systemem:

index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
EventCode=7 Image="*\\explorer.exe"
| where like(ImageLoaded, "%:\\%.dll")
| stats count min(_time) as first_seen max(_time) as last_seen by host Image ImageLoaded Signed SignatureStatus

B) Próba rundll32 z literą dysku (po USB mount):

index=sysmon EventCode=1 Image="*\\rundll32.exe" ParentImage="*\\explorer.exe"
| where match(CommandLine, "[A-Z]:\\\\.+\\.dll")
| stats values(CommandLine) as cmd by host, ParentImage, Image

KQL (Microsoft Defender XDR / Sentinel)

Korelacja USB → ładowanie DLL przez Explorera (≤5 min):

let usb = DeviceEvents
| where ActionType == "UsbDriveMounted"
| extend DriveLetter = tostring(parse_json(AdditionalFields).DriveLetter)
| project DeviceId, DeviceName, MountTime=Timestamp, DriveLetter;
DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "explorer.exe"
| where FolderPath matches regex @"^[A-Z]:\\.*\.dll$"
| project DeviceId, DeviceName, LoadTime=Timestamp, FolderPath, InitiatingProcessFileName
| join kind=innerunique (usb) on DeviceId
| where LoadTime between (MountTime .. MountTime + 5m)
| order by LoadTime desc

Uwaga: nazwy tabel/kolumn zgodnie z referencją AH; dostępność zależy od wdrożenia MDE.

„CloudTrail query (AWS CLI/CloudWatch)” — uwaga praktyczna

CloudTrail nie rejestruje zdarzeń OS, więc detekcję opieramy o CloudWatch Logs Insights dla strumieniowanych dzienników Sysmon/Windows Event Log:

-- CloudWatch Logs Insights (grupa: /os/sysmon)
fields @timestamp, @message
| filter EventID=7 and like(@message, "\\explorer.exe") and like(@message, /:\\\\.*\.dll/i)
| sort @timestamp desc
| limit 100

(Aktywność CloudTrail zostaw do monitoringu API AWS).

Elastic / EQL

Proces z USB (rundll32) po Explorerze:

process where event.category == "process"
  and process.name == "rundll32.exe"
  and process.parent.name == "explorer.exe"
  and process.command_line regex "^[A-Z]:\\\\.*\\.dll"

Ładowanie biblioteki (ECS event.category: "library") przez Explorera:

any where event.category == "library"
  and process.name == "explorer.exe"
  and dll.path regex "^[A-Z]:\\\\.*\\.dll"

(ECS pola dll.* dla zdarzeń ładowania bibliotek).


Heurystyki / korelacje

  • USB mount → (≤5 min) → explorer.exe ładuje nienadzorowaną DLL z tej litery → (≤10 s) → rundll32.exe/regsvr32.exe z tą ścieżką.
  • Brak podpisu / SignatureStatusValid dla DLL ładowanych przez Explorera.
  • Nowe LNK pojawiające się na USB lub udziałach sieciowych; LNK wskazujące na nietypowe lokalizacje (\\server\share, \\?\GLOBALROOT\Device\...).
  • Zbieżność z politykami Device Control (odmowy/alerty MDE przy USB).

False positives / tuning

  • Legalne narzędzia portable na USB mogą dynamicznie ładować DLL (wyjątki po hashach/podpisach).
  • Środowiska dev/test uruchamiające biblioteki z nietypowych ścieżek — odseparuj po OU/Tagach i godzinach pracy.
  • Rozważ wąskie filtrowanie Sysmon EID 7 (np. tylko Image="*\explorer.exe"), by ograniczyć wolumen.

Playbook reagowania (IR)

  1. Triaging & containment
  • Odizoluj host w EDR/EDR‑NAC. Zanotuj literę/identyfikator USB.
  • W MDE sprawdź oś czasu: UsbDriveMountedDeviceImageLoadEvents/rundll32. (
  1. Zbieranie artefaktów
  • Zabezpiecz nośnik i kopię folderu z LNK. Oblicz hashe (SHA‑256).
  • Z Sysmon wyciągnij EID 7/1 i towarzyszące 4688.
  1. Analiza
  • Sprawdź podpisy DLL, nietypowe eksporty, ścieżki.
  • Koreluj z innymi hostami (ta sama litera USB, te same LNK).
  1. Remediacja
  • Wymuś instalację KB2286198 / MS10‑046 (dla systemów historycznych) i aktualizacje.
  • Włącz/egzekwuj ASR / Device Control dla USB, wyłącz AutoRun/AutoPlay.
  1. Higiena i komunikacja
  • Blokada podpisu/uruchamiania z USB w GPO/MDE.
  • Komunikat dla użytkowników nt. bezpiecznego użycia nośników.

Przydatne polecenia (na hoście podejrzanym):

# Szybki przegląd procesów powiązanych
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Where-Object {
  $_.Id -in 1,7
} | Select TimeCreated, Id, @{n="Exe";e={$_.Properties[4].Value}}, @{n="Path";e={$_.Properties[5].Value}} | Format-Table -Auto

# Sprawdzenie dostępnych dysków i typów
Get-CimInstance Win32_LogicalDisk | Select DeviceID, DriveType, VolumeName

Przykłady z kampanii / case studies

  • Stuxnet (2010–2011): wykorzystanie CVE‑2010‑2568 do propagacji m.in. przez nośniki wymienne (i do eksfiltracji na systemy air‑gapped); Microsoft opisał eksploatację w MS10‑046, a szczegółowy dossier Symanteca dokumentuje oś czasu i wektory.

Lab (bezpieczne testy) — symulacja detekcji, nie exploit

Cel: wygenerować telemetrię, która powinna uruchomić reguły bez realnego wykorzystania luki.

  1. Przygotuj: host testowy z Sysmon (EID 1 i selektywnie EID 7 dla explorer.exe) i MDE.
  2. Włóż czysty pendrive (zapisz jego literę; w MDE powstanie UsbDriveMounted).
  3. Uruchom próbę ładowania DLL z USB (bez powodzenia, ale z logiem):
# Stwórz pusty plik DLL (nie zostanie załadowany poprawnie)
New-Item -Path "E:\test.dll" -ItemType File | Out-Null
# Wywołaj rundll32 ze ścieżką na USB (wygeneruje EID 1 i próbę dostępu)
Start-Process -FilePath "$env:SystemRoot\System32\rundll32.exe" -ArgumentList "E:\test.dll,EntryPoint" -NoNewWindow
  1. Opcjonalnie: skopiuj zwykły skrót .lnk na USB (bez złośliwych właściwości) i obserwuj zapisy plikowe.
  2. Zweryfikuj alerty/reguły: Sigma/Splunk/KQL/Elastic z sekcji 7.

Nie twórz ani nie uruchamiaj spreparowanych LNK z osadzonymi DLL — lab ma charakter wyłącznie defensywny.


Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK):

  • M1051 — Update Software: stosuj aktualizacje (MS10‑046/KB2286198).
  • M1040 — Behavior Prevention on Endpoint: reguły ASR blokujące uruchamianie z nośników.
  • M1042 — Disable or Remove Feature or Program: wyłącz Autorun/AutoPlay; ogranicz użycie USB.

Powiązane techniki:

  • T1203 — Exploitation for Client Execution – Eksploatacja luki w komponencie klienckim (Windows Shell) dla uzyskania wykonania na hoście ofiary. Takt.: Execution; Wersja 1.5 (2025‑10‑24).
  • T1204.002 — User Execution: Malicious File -Skrót/LNK jako złośliwy plik wywołujący łańcuch wykonania; często po spear‑phishingu lub przez udostępnione zasoby. Takt.: Execution; Wersja 1.6 (2025‑10‑24).
  • T1091 — Replication Through Removable Media – Dystrybucja przez USB, w tym historyczny przypadek Stuxnet używający CVE‑2010‑2568 do propagacji. Taktyki: Initial Access, Lateral Movement; Wersja 1.3 (2025‑10‑24).
  • T1547.009 — Shortcut Modification – Nie ta luka, ale pokrewne użycie .LNK dla Persistence (autostart/Startup). Warto monitorować modyfikacje LNK w lokacjach autostartu.

Źródła / dalsza lektura

  • Microsoft: MS10‑046Vulnerability in Windows Shell Could Allow Remote Code Execution (2286198). (Microsoft Learn)
  • NVD / CVE Record: CVE‑2010‑2568 (opis, CVSS). (NVD)
  • MITRE ATT&CK: T1203, T1204.002, T1091 (wersje, zakres). (attack.mitre.org)
  • Symantec/Broadcom: W32.Stuxnet Dossier (szczegółowa analiza i oś czasu).
  • Unit42: Windows Shortcut (LNK) Malware Strategies (tło LNK, warianty). (Unit 42)
  • MDE AH referencje: DeviceImageLoadEvents, DeviceEvents (USB). (Microsoft Learn)
  • CloudTrail zakres/logi API (dlaczego nie OS): dokumentacja AWS. (AWS Documentation)
  • Sysmon: EID 1/7 — definicje i praktyka. (Microsoft Learn)

Checklisty dla SOC / CISO

SOC (operacyjne):

  • Zbierasz Sysmon EID 1/7 i masz selektory dla explorer.exe?
  • Masz reguły korelacji USB mount → ImageLoad/ProcessCreate?
  • Monitorujesz tworzenie/modyfikacje .LNK w autostarcie i na USB?
  • Utrzymujesz allow‑listy podpisów/ścieżek dla legalnych portable?

CISO (strategiczne):

  • Potwierdzone wdrożenie MS10‑046 na hostach historycznych / obrazach VM.
  • Polityki Device Control / ASR: blokada uruchamiania z USB, audyt wyjątków.
  • Wyłączone Autorun/AutoPlay i egzekwowane szyfrowanie nośników.
  • Procedury reagowania na incydenty z udziałem nośników wymiennych (izolacja, zabezpieczenie dowodów, komunikacja).

Uwaga końcowa: CVE‑2010‑2568 jest historycznie krytyczna i szeroko udokumentowana. Współczesne systemy Windows mają łatę, ale wektory LNK/USB pozostają popularne (np. jako malicious file w T1204.002). Detekcja zachowania i higiena USB są kluczowe nawet po załataniu luki.

Windows Commands Dla Analityków Bezpieczeństwa – Pełny Przewodnik Z Przykładami

Komendy Windows jako pierwsza linia analizy incydentu

W codziennej pracy analityka bezpieczeństwa (SOC) umiejętność szybkiego korzystania z wbudowanych poleceń Windows bywa bezcenna. Gdy liczy się czas – na przykład podczas triage incydentu lub szybkiego forensics – dostęp do graficznych narzędzi może być ograniczony, a instalacja dodatkowego oprogramowania niemożliwa.

Czytaj dalej „Windows Commands Dla Analityków Bezpieczeństwa – Pełny Przewodnik Z Przykładami”

Ustawodawcy proszą FTC o zbadanie praktyk cyberbezpieczeństwa Flock Safety. Chodzi o brak wymuszania MFA i ryzyko nieuprawnionego dostępu do danych z ALPR

Wprowadzenie do problemu / definicja luki

Grupa demokratycznych ustawodawców z senatorem Ronem Wydenem i kongresmenem Rają Krishnamoorthim wezwała Federalną Komisję Handlu (FTC) do wszczęcia postępowania wobec Flock Safety — dostawcy sieci kamer do automatycznego odczytu tablic rejestracyjnych (ALPR). Powód: rzekomo niedostateczne zabezpieczenia, w tym brak wymogu stosowania wieloskładnikowego uwierzytelniania (MFA) dla klientów z organów ścigania, co ma narażać wrażliwe dane o przemieszczaniu się obywateli na dostęp hakerów i obcych służb.

W skrócie

  • Ustawodawcy wskazują, że skradzione hasła co najmniej 35 kont klientów Flock krążyły w sieci, a firma nie wymaga MFA i nie zapewnia domyślnie „phishing-resistant MFA” (np. FIDO2/WebAuthn).
  • Sam Flock twierdzi, że MFA jest włączane domyślnie dla nowych klientów od XI 2024 r., a 97% klientów law enforcement ma MFA aktywne; ok. 3% wciąż nie.
  • Skala systemu: według dokumentów nadzoru i pism Wydena Flock współpracuje z tysiącami agencji i przechowuje miliardy skanów pojazdów miesięcznie.
  • Wcześniej firma tymczasowo wstrzymała pilotaże z federalnymi agencjami (CBP/HSI) po kontrowersjach o zakres i cel wykorzystania danych.

Kontekst / historia / powiązania

Flock Safety jest jednym z największych operatorów ALPR w USA; jego platforma umożliwia zapytania m.in. po numerze tablicy, marce/modelu auta, a nawet atrybutach wizualnych. W ostatnich miesiącach firma znalazła się pod ostrzałem za udostępnianie (w ramach pilotaży) dostępu agencjom federalnym oraz za praktyki, które – zdaniem krytyków – ułatwiają nadużycia w obszarach imigracji czy egzekwowania restrykcyjnych przepisów stanowych. Po medialnych doniesieniach i audytach stanowych Flock deklarował zmiany polityk i ograniczenia zapytań federalnych.

Analiza techniczna / szczegóły luki

Słabe wymuszanie kontroli dostępu

  • Brak obowiązkowego MFA dla kont organów ścigania tworzy krytyczną lukę: przejęte hasło = pełny dostęp do „law-enforcement-only” części portalu i zapytań w bazie z miliardami skanów. List do FTC podaje przykłady kompromitacji danych uwierzytelniających oraz wskazuje brak domyślnego wsparcia dla „phishing-resistant MFA”.

Ryzyko „przejęcia sesji przez sąsiada” i lateralne nadużycia

  • Doniesienia opisują sytuacje, gdy loginy były współdzielone lub kradzione, co potencjalnie pozwalało obcym użytkownikom wykonywać zapytania bez wykrycia. To klasyczny brak rygoru w A&A (Authentication & Authorization) i audycie zdarzeń.

Domyślne konfiguracje i spójność egzekwowania

  • Firma odpowiada, że od XI 2024 MFA jest domyślne dla nowych klientów, a 97% organów ścigania ma MFA aktywne. Pozostaje jednak „luka zgodności” (ok. 3%), która w ekosystemach o takiej skali oznacza wciąż dziesiątki agencji bez trwałej drugiej składowej.

Łańcuch zaufania i międzyjurysdykcyjny dostęp do danych

  • Według pism Wydena platforma łączy tysiące podmiotów, a funkcje typu „National Lookup Tool” ułatwiają szerokie udostępnianie danych między agencjami. Bez twardych reguł rozliczalności (case ID, uzasadnienie, RBAC, ograniczenia geograficzne) rośnie ryzyko nadużyć i trudność w dochowaniu wymogów stanowych.

Praktyczne konsekwencje / ryzyko

  • Ryzyko prywatności na poziomie populacyjnym: ALPR pozwala odtworzyć trasy do klinik, miejsc kultu, mityngów wsparcia czy protestów; wycieki lub dostęp bez kontroli mają realny efekt mrożący (chilling effect).
  • Ryzyko prawne i regulacyjne: FTC już wcześniej uderzała w firmy, które nie wymuszały MFA; podobne wątki w sprawie Flock mogą skutkować nakazami oraz zobowiązaniami do wdrożeń środków bezpieczeństwa (np. SSAE/ISAE, niezależne audyty).
  • Ryzyko dla gmin/miast: odbiorcy publiczni mogą naruszać prawo stanowe przy niewłaściwym udostępnianiu danych (przykład Illinois i kontrowersje wokół zapytań CBP/HSI).

Rekomendacje operacyjne / co zrobić teraz

Dla CISO/CIO w sektorze publicznym i prywatnym korzystającym z ALPR lub podobnych platform:

  1. Wymuś phishing-resistant MFA (FIDO2/WebAuthn) na wszystkich kontach; blokuj SMS/voice jako jedyną metodę. Wprowadź politykę „no-MFA, no-login”.
  2. SSO + IdP-enforced policies: integracja z IdP (Okta/AAD) z Conditional Access, geofencingiem, IP allowlistingiem i wymogiem certyfikowanych kluczy sprzętowych dla ról uprzywilejowanych.
  3. RBAC i zasada najmniejszych uprawnień: osobne role dla zapytań lokalnych vs. międzyjurysdykcyjnych; ograniczaj zakres (czas, geografia) i funkcje masowych wyszukiwań.
  4. Twarde metadane zapytań: wymóg obowiązkowego numeru sprawy + ustrukturyzowanego powodu (drop-down), walidacja w IdP/SIEM; odrzuć wolne pole tekstowe jako jedyną ścieżkę.
  5. Audyty i detekcja anomalii: koreluj logi dostępu z kontekstem sprawy; alertuj na logowania z nietypowych AS/ASN, nietypowe wolumeny zapytań, „pożyczone” konta czy współdzielenie poświadczeń.
  6. Segmentacja danych i retencja: minimalizuj retencję, domyślne „privacy by default”, szyfrowanie w spoczynku i w tranzycie; jasne DPA/DUA z klauzulami dot. podmiotów federalnych.
  7. Testy Red Team / tabletop: scenariusze „po przejęciu konta” (account-takeover) oraz „przeciek danych zapytań” – z ćwiczeniem ścieżek zgłoszeń i notyfikacji.

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

W piśmie do FTC parlamentarzyści wskazują na wcześniejsze sprawy, w których Komisja egzekwowała odpowiedzialność za brak MFA (m.in. Uber, Drizly, Blackbaud i inne wymienione w liście). Wspólny mianownik: brak wymuszenia podstawowych kontroli dostępu i niedostateczne zarządzanie ryzykiem kont skompromitowanych. Różnica na niekorzyść ALPR polega na skali wrażliwości danych ruchowych oraz na międzyinstytucyjnym modelu wymiany – co amplifikuje skutki pojedynczego przejęcia konta.

Podsumowanie / kluczowe wnioski

  • Sprawa Flock Safety to nie tylko spór o konfigurację MFA, lecz test dojrzałości całego ekosystemu ALPR: jeśli tożsamość nie jest silnie weryfikowana i rozliczana, to każdy inny kontroler zawodzi.
  • Niezależnie od wyniku potencjalnego dochodzenia FTC, organizacje korzystające z usług ALPR powinny już teraz podnieść poprzeczkę: phishing-resistant MFA, SSO, twarde metadane zapytań, ścisły audyt i minimalizacja retencji.

Źródła / bibliografia

  • The Record: „Lawmakers ask FTC to probe Flock Safety’s cybersecurity practices” (03.11.2025). (The Record from Recorded Future)
  • Biuro senatora R. Wydena: „Wyden, Krishnamoorthi Urge FTC to Investigate…” (03.11.2025). (wyden.senate.gov)
  • List Wydena dot. Flock (16.10.2025) – szczegóły skali i praktyk udostępniania.
  • TechCrunch: „Lawmakers say stolen police logins are exposing Flock…” (03.11.2025) – stanowisko Flock i dane o 97%/3% MFA. (TechCrunch)
  • AP News: „License plate camera company halts cooperation with federal agencies…” (VIII.2025) – tło dot. pilotów CBP/HSI i zmian polityk. (AP News)

Amerykańscy specjaliści ds. cyberbezpieczeństwa oskarżeni o ataki ransomware BlackCat (ALPHV)

Wprowadzenie do problemu / definicja sprawy

3 listopada 2025 r. media branżowe ujawniły akt oskarżenia wobec trzech obywateli USA — w tym dwóch byłych negocjatorów ds. ransomware i menedżera IR — którym zarzucono działanie jako afilianci gangu ALPHV/BlackCat oraz przeprowadzenie serii ataków na co najmniej pięć firm w USA (służba zdrowia, farmacja, inżynieria, UAV). Według śledczych sprawcy włamali się do sieci, wykradli dane, wdrożyli szyfrator BlackCat i żądali okupu w kryptowalutach. Jedna z ofiar — producent urządzeń medycznych z Tampy — miała zapłacić ok. 1,27 mln USD.

W skrócie

  • Kim są oskarżeni: Ryan Clifford Goldberg (były IR Manager w Sygnia), Kevin Tyler Martin (były negocjator w DigitalMint) oraz nieujawniony z nazwiska współsprawca.
  • Zakres działań: włamania, kradzież danych, wdrożenie ransomware ALPHV/BlackCat oraz wymuszenia (maj–listopad 2023; w dokumentach są też uzupełnienia procesowe z 2025 r.).
  • Kary: za zarzuty dot. wymuszeń i celowego uszkodzenia systemów grożą im dziesiątki lat więzienia; część podejrzanych przebywała w areszcie, inni nie przyznali się do winy.
  • Model przestępstwa: klasyczny Ransomware-as-a-Service (RaaS) — operatorzy ALPHV dostarczają narzędzia, a afilianci (tu: oskarżeni) prowadzą włamania i dzielą się zyskami.

Kontekst / historia / powiązania

ALPHV/BlackCat to jedna z najaktywniejszych rodzin ransomware od końca 2021 r., znana z ataków na podmioty ochrony zdrowia i infrastrukturę krytyczną oraz z podwójnego (a czasem potrójnego) wymuszania. W 2024 r. FBI, CISA i HHS publikowały wspólne ostrzeżenia techniczne z aktualnymi IOC i TTP.

Analiza techniczna / szczegóły sprawy

Wejście do sieci i eskalacja: Z aktu oskarżenia i doniesień wynika, że sprawcy uzyskiwali nieuprawniony dostęp do środowisk ofiar, eksfiltrowali wrażliwe dane, a następnie wdrażali szyfrator BlackCat. Ofiary obejmowały m.in. firmę medtech z Florydy (Tampa), producenta farmaceutycznego z Maryland, praktykę lekarską i biuro inżynieryjne w Kalifornii oraz wytwórcę dronów w Wirginii. Kwoty żądań mieściły się od 300 tys. do 10 mln USD.

Rola „insiderów branżowych”: Szczególnie alarmujący jest fakt, że oskarżeni pracowali w firmach świadczących usługi IR i negocjacji okupów. Według sądu i materiałów prasowych co najmniej jeden z podejrzanych miał pozostać w areszcie, a drugi nie przyznał się do winy; firmy, w których pracowali, podkreśliły współpracę z organami ścigania i brak wiedzy o przestępstwach.

Model RaaS w praktyce: Zgodnie z opisem TechCrunch, ALPHV/BlackCat funkcjonuje w modelu RaaS: operatorzy tworzą malware i infrastrukturę, a afilianci prowadzą penetrację i eskalację, dzieląc się okupem z operatorem. To klasyczny układ, który obniża barierę wejścia dla atakujących i utrudnia atrybucję.

Praktyczne konsekwencje / ryzyko

  1. Erozja zaufania do łańcucha dostaw bezpieczeństwa: gdy osoby z firm IR/negocjacyjnych stają się afiliantami RaaS, standardowe due-diligence dostawców przestaje wystarczać.
  2. Ryzyko nadużyć informacji wrażliwych: dostęp do artefaktów incydentów, procedur, runbooków i danych klientów może ułatwiać planowanie ataków „pod klienta”. (W sprawie padają przykłady celowania w sektory o wysokiej skłonności do płatności).
  3. Presja regulacyjna i ubezpieczeniowa: zgodność z wytycznymi #StopRansomware (FBI/CISA/HHS) i warunkami polis cyber stanie się bardziej rygorystyczna po tym precedensie.

Rekomendacje operacyjne / co zrobić teraz

Zarządzanie dostawcami i personelem:

  • KYE (Know Your Employee/Expert) i KYS (Know Your Supplier): ponowna weryfikacja kluczowych konsultantów IR/negocjatorów, kontrole konfliktu interesów, NDA z klauzulami o zakazie afiliacji z RaaS.
  • Segregacja ról: negocjacje okupowe i IR prowadzone przez oddzielne zespoły/firmy; dostęp „just-in-time” i „least privilege” dla zewnętrznych konsultantów.
  • Monitoring działań konsultantów: dzienniki EDR/SIEM obejmujące konta dostawców; wymóg sesji uprzywilejowanych przez PAM z pełnym nagraniem.

Higiena techniczna:

  • Hardening tożsamości: MFA niefiszowalne (FIDO2/Passkeys) dla VPN/RDP/M365; polityki Conditional Access i monitorowanie anomalii logowania.
  • Segmentacja i EDR: segmentacja sieci + EDR z regułami behawioralnymi dla znanych TTP ALPHV (np. Living-off-the-Land, exfil+encrypt). Wytyczne IOC/TTP patrz #StopRansomware.
  • Kopia „3-2-1-1-0”: kopie zapasowe offline/immutability + regularne testy odtwarzania scenariusza „exfil + wiper”.
  • DLP i egress control: kontrola wycieku (S3/SharePoint/SMTP), ograniczenia do domen zaufanych, szyfrowanie i tokenizacja danych wrażliwych.

Proces i prawo:

  • Runbook „bez płatności z zaskoczenia”: rada kryzysowa, ścieżka zgłoszeń do organów ścigania, ocena sankcyjna; minimalizuj rozmowy 1:1 z „negocjatorami z ulicy”.
  • Kontrakty: klauzule o audytowalności, „right-to-monitor”, odpowiedzialności i karach umownych przy naruszeniach etycznych.

Różnice / porównania z innymi przypadkami

Wcześniej głośne były sprawy „pośredników” i firm odzysku danych ukrywających płatności dla gangów. Tu jednak rdzeniem jest aktywna afiliacja RaaS przez osoby z branży IR/negocjacji, co stanowi jakościowo bardziej niebezpieczny precedens — wprost podważa to model zaufania do dostawców reagowania na incydenty.

Podsumowanie / kluczowe wnioski

  • Akt oskarżenia z 3 listopada 2025 r. pokazuje, że wektor „insider-affiliate” przestał być scenariuszem teoretycznym.
  • Organizacje muszą traktować dostawców IR/negocjacji jak użytkowników uprzywilejowanych, z pełną telemetrią i kontrolą.
  • Utrzymuj zgodność z najnowszymi wytycznymi #StopRansomware i stale weryfikuj partnerów bezpieczeństwa.

Źródła / bibliografia

  • BleepingComputer — „US cybersecurity experts indicted for BlackCat ransomware attacks” (03.11.2025). (BleepingComputer)
  • Reuters — „US prosecutors say cybersecurity pros ran cybercrime operation” (03–04.11.2025). (Reuters)
  • CyberScoop — „Prosecutors allege incident response pros used ALPHV/BlackCat to commit string of ransomware attacks” (03.11.2025). (CyberScoop)
  • TechCrunch — „DOJ accuses US ransomware negotiators of launching their own ransomware attacks” (03.11.2025). (TechCrunch)
  • CISA/FBI/HHS — „#StopRansomware: ALPHV BlackCat” (2024 – aktualizacje IOC/TTP). (cisa.gov)

SesameOp — backdoor wykorzystujący OpenAI Assistants API do ukrytego C2. Analiza i zalecenia dla SOC

Wprowadzenie do problemu / definicja luki

Microsoft Incident Response (DART) opisał nowy backdoor SesameOp, który wykorzystuje OpenAI Assistants API jako kanał command-and-control (C2). To nie jest podatność w OpenAI ani błąd konfiguracji — to nadużycie legalnego interfejsu API w celu ukrycia komunikacji atakujących w „szumie” ruchu do popularnej usługi chmurowej. OpenAI wraz z Microsoftem zidentyfikowali i wyłączyli klucz oraz powiązane konto wykorzystywane przez sprawcę; funkcja Assistants API i tak ma zostać wycofana w sierpniu 2026 r.

W skrócie

  • Odkrycie: lipiec 2025 podczas reakcji IR; w środowisku ofiary utrzymywano długotrwałą obecność (cel: utrwalenie i szpiegostwo).
  • Kanał C2: OpenAI Assistants API użyte jako „magazyn/relayer” poleceń i wyników, z kompresją i warstwowaniem kryptografii (sym./asym.).
  • Łańcuch: loader Netapi64.dll (obf. Eazfuscator.NET) + backdoor OpenAIAgent.Netapi64 ładowany przez .NET AppDomainManager injection.
  • Kontrola zadań: opis assistanta = SLEEP / Payload / Result; identyfikacja hosta, vector store per hostname, wątki i kasowanie wiadomości po użyciu.
  • Status platformy: to nadużycie funkcji, nie exploit; OpenAI/Microsoft skoordynowali wyłączenie klucza/konta.

Kontekst / historia / powiązania

Nadużywanie legalnych usług (tzw. LOLBAS/LOLCLOUD) do C2 to trend widoczny od lat (GitHub, Slack, Telegram, Pastebin). W 2025 r. ENISA raportuje nasilenie wykorzystywania narzędzi AI przez grupy APT i cyberprzestępców (od inżynierii społecznej, przez rozwój malware, po ukrywanie operacji). To raczej „turbo-doładowanie” starych technik niż zupełnie nowe zdolności ofensywne.

Analiza techniczna / szczegóły luki

Składniki i uruchomienie

  • Loader: Netapi64.dll (obfuskacja Eazfuscator.NET), znacznik uruchomienia C:\Windows\Temp\Netapi64.start, mutex jednosesyjny; dekoduje i uruchamia właściwy moduł z pliku kończącego się na .Netapi64.
  • Backdoor: .NET OpenAIAgent.Netapi64 — wbrew nazwie nie używa SDK agentów ani modeli, tylko Assistants API do pobierania poleceń i wysyłki wyników jako wiadomości. Konfiguracja z zasobów: OpenAI_API_Key|Dictionary_Key_Name|Proxy; obsługa proxy systemowego, B64 hostnamen. Mutex: „OpenAI APIS”.

Protokół C2 przez Assistants API

  1. Zapytanie listy vector stores w koncie; jeśli brak rekordu z hostname — tworzy nowy (wiąże hosta z artefaktami w OpenAI).
  2. Pobranie listy Assistants (paginacja do 100). Pola sterujące: description oraz instructions. description przyjmuje jedną z wartości:
    • SLEEP → odczyt timeSLEEP z wiadomości (po thread_id|message_id) i pauza wątku,
    • Payload → pobierz treść polecenia po thread_id|message_id, wykonaj w osobnym wątku, usuń wiadomość i assistanta,
    • Result → opublikuj wynik jako nową wiadomość (description=Result).
  3. Cała wymiana kompresowana i szyfrowana (warstwowo: symetrycznie i asymetrycznie).

Wejście do procesu i utrwalenie

  • Wektor uruchomienia: .NET AppDomainManager injection w komponenty Visual Studio za pomocą spreparowanego pliku .config; w środowisku ofiary działała dodatkowo siatka internal web shelli wspierających orkiestrację.

Detekcje Microsoft

  • Sygnatury AV: Trojan:MSIL/Sesameop.A (loader) i Backdoor:MSIL/Sesameop.A (backdoor).
  • Alerty EDR: m.in. „Possible .NET AppDomainManager injection”.
  • Przykładowe zapytanie huntingowe (Defender XDR) do wykrywania urządzeń łączących się z api.openai.com.

Praktyczne konsekwencje / ryzyko

  • Ukrywanie w legalnym ruchu: egress do popularnego API (OpenAI) utrudnia klasyczne IOC-based blocking i analitykę opartą wyłącznie o domeny.
  • Szyfrowanie + kompresja: minimalizuje telemetry „na drucie” i zwiększa koszt analizy NDR.
  • Ślad w chmurze dostawcy: użycie vector stores / threads / messages zostawia artefakty możliwe do skorelowania z kluczem API (pomaga po incydencie, jeżeli dostawca współpracuje).
  • Trend rynkowy: wg ENISA i OpenAI rosną próby nadużyć usług AI, ale zazwyczaj to przyspieszanie istniejących TTP — dlatego kontrola egress + tożsamości kluczy API staje się krytyczna.

Rekomendacje operacyjne / co zrobić teraz

Monitoring & hunting (SOC)

  • Widoczność egress do api.openai.com: koreluj proces → host → częstotliwość; zacznij od kwerendy Microsoft (lub odpowiednika w SIEM/NDR). Ustal listę dozwolonych procesów/serwerów korzystających z API OpenAI.
  • Reguły behawioralne: wykrywaj AppDomainManager injection, niespodziewane ładowanie DLL do procesów Visual Studio, tworzenie znaczników w C:\Windows\Temp\*Netapi64*.
  • Anomalie DNS/HTTP: długie okresy SLEEP, nietypowa paginacja Assistants i bursty wiadomości mogą tworzyć charakterystyczne wzorce czasowe (mimo TLS). (Wniosek na podstawie opisu protokołu.)

Kontrola dostępu i „egress governance” (IT/SecOps)

  • Allowlista egress dla AI: ograniczaj ruch do usług AI do zatwierdzonych podsieci/procesów; w proxy weryfikuj nagłówki autoryzacji i kontekst procesu (jeżeli wspiera). (Najlepsza praktyka zgodna z case’em Microsoft.)
  • Zarządzanie kluczami API: rotacja, skan tajemnic, ochrona przed wyciekiem; w razie incydentu — unieważnij klucze i wnioskuj u dostawcy o logi zasobów (threads/vector stores).
  • Wymuś PUA/EDR w trybie block i tamper protection w Defenderze; włącz cloud-delivered protection.

IR / odzyskiwanie

  • Artefakty na hoście: poszukuj mutexów „OpenAI APIS”, plików w C:\Windows\Temp\Netapi64.*, wpisów konfiguracyjnych .config wskazujących AppDomainManager.
  • Artefakty u dostawcy: listy Assistants, threads, messages, vector stores powiązane z kompromitowanym kluczem. (Współpraca z OpenAI/Microsoft okazała się skuteczna w tej sprawie.)

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

  • Względem „klasycznego” cloud-C2 (np. Slack/Telegram): SesameOp semantycznie mapuje logikę C2 na artefakty platformy AI (description = SLEEP/Payload/Result, threads, vector stores), co utrudnia pisanie prostych sygnatur i wymusza analizę zachowań aplikacji zamiast samych domen.
  • Względem generowania malware przez LLM: tu model nie jest wykorzystywany do generowania treści, a interfejs API – do transportu (stealth C2). To potwierdza obserwację OpenAI, że aktorzy głównie „dokładają AI do starych playbooków”.

Podsumowanie / kluczowe wnioski

SesameOp pokazuje, że governance nad ruchem do usług AI i bezpieczeństwo tożsamości API to nowe „must-have” w SOC. Należy inwentaryzować legalne użycia api.openai.com, egzekwować egress allowlisty, szukać behawioralnych anomalii .NET oraz artefaktów na hostach. Dobra współpraca z dostawcami (tu: Microsoft & OpenAI) przyspiesza neutralizację takich nadużyć.

Źródła / bibliografia

  1. ENISA Threat Landscape 2025 (TLP:CLEAR), październik 2025. (Trendy wykorzystania AI przez aktorów zagrożeń.)
  2. Microsoft Security Blog — „SesameOp: Novel backdoor uses OpenAI Assistants API for command and control”, 3 listopada 2025. (Podstawowa analiza techniczna, detekcje, hunting.) (Microsoft)
  3. OpenAI — „Disrupting malicious uses of AI: October 2025”. (Kontekst nadużyć usług AI, polityka egzekwowania.) (OpenAI)
  4. BleepingComputer — „Microsoft: SesameOp malware abuses OpenAI Assistants API in attacks”, 3 listopada 2025. (Zewnętrzne potwierdzenie i streszczenie.) (BleepingComputer)
  5. The Hacker News — „Microsoft Detects 'SesameOp’ Backdoor Using OpenAI’s API…”, 4 listopada 2025. (Dodatkowe omówienie, konsolidacja faktów.) (The Hacker News)

CVE – Kompleksowy Przewodnik Po Lukach Bezpieczeństwa

Co to jest CVE (Common Vulnerabilities and Exposures)?

CVE (Common Vulnerabilities and Exposures) to międzynarodowy standard nazewnictwa publicznie znanych luk bezpieczeństwa w oprogramowaniu i sprzęcie. Mówiąc prościej, jest to lista unikatowych identyfikatorów podatności oraz związany z nią system ich katalogowania. Dzięki CVE specjaliści ds. cyberbezpieczeństwa na całym świecie mogą mówić jednym językiem o konkretnych lukach – niezależnie od platformy czy producenta.

Czytaj dalej „CVE – Kompleksowy Przewodnik Po Lukach Bezpieczeństwa”

Rosyjska policja zatrzymała domniemanych twórców Meduza Stealer. Co to oznacza dla ekosystemu infostealerów?

Wprowadzenie do problemu / definicja luki

Rosyjskie Ministerstwo Spraw Wewnętrznych poinformowało o zatrzymaniu trzech „młodych specjalistów IT” w Moskwie i okolicach. Według władz, mieli oni rozwijać i sprzedawać Meduza Stealer – infostealera kradnącego dane logowania, informacje o portfelach krypto oraz inne wrażliwe dane z przeglądarek. Sprawa ma tło krajowe: śledczy łączą grupę z włamaniem do instytucji w obwodzie astrachańskim w maju 2025 r. oraz z dystrybucją płatnego narzędzia w modelu MaaS.

W skrócie

  • Kiedy: ogłoszenie zatrzymań – 31 października 2025 r. (czw.), relacje mediów: 31.10–1.11.2025.
  • Kto: trzech podejrzanych o rozwój i sprzedaż Meduza Stealer; to rzadki przypadek uderzenia rosyjskiej policji w rodzimą cyberprzestępczość.
  • Dlaczego teraz: śledztwo powiązano z kompromitacją instytucji w regionie Astrachania (maj 2025) i innymi incydentami.
  • Podstawa prawna: art. 273 §2 rosyjskiego KK („tworzenie, używanie i rozpowszechnianie złośliwego oprogramowania”).
  • Czym jest Meduza: infostealer obecny od 2023 r., oferowany na forach/Telegramie jako usługa abonamentowa.

Kontekst / historia / powiązania

Meduza pojawiła się w połowie 2023 r. i szybko dołączyła do grona popularnych infostealerów obok Lumma czy RedLine. Narzędzie obserwowano w kampaniach przeciw Ukrainie i Polsce, ale także ofiarom w Rosji. Aresztowania wpisują się w szersze – choć wciąż sporadyczne – działania rosyjskich służb przeciw grupom, które „zahaczają” o lokalne cele.

Media branżowe wskazują, że dystrybucja Meduzy była prowadzona w modelu malware-as-a-service (abonament). Władze mówią też o drugim komponencie (narzędziu do wyłączania ochrony AV i budowy botnetów), co sugeruje pakietowe „oferty” dla klientów.

Analiza techniczna / szczegóły luki

Badania techniczne (m.in. Splunk TR) pokazują, że Meduza:

  • stosuje anti-VM / anti-sandbox i sprawdza komponenty środowisk analitycznych (MITRE ATT&CK T1497),
  • szyfruje ładunek (m.in. ChaCha20) i enkoduje go w Base64 (T1027.013),
  • wykonuje kontrole geolokalizacji/GeoID i wyłącza się na systemach z wybranych regionów (m.in. RU, KZ, BY, UA itd.),
  • enumeruje rejestr i przeglądarki w celu pobrania sekretów (cookies, hasła, portfele),
  • w późniejszych wersjach wspierało techniki „ożywiania” (revival) wygasłych ciasteczek Chrome ułatwiające przejęcie sesji.

Wejście/rozprzestrzenianie: phishing, złośliwe pobrania oraz kampanie wykorzystujące exploity; ekosystem reklamował buildery i panele operatorskie dostępne przez Telegram/fora.

Praktyczne konsekwencje / ryzyko

  • Ryzyko kredencjałów i sesji: kradzież haseł + odtwarzanie cookies = realne ATO (account takeover) także bez 2FA w niektórych scenariuszach.
  • Ryzyko finansowe: portfele krypto i autofill kart płatniczych pozostają atrakcyjnym celem.
  • Ryzyko wtórne: dane z infostealerów są sprzedawane w „stealer logs”, napędzając oszustwa, lateral movement i RaaS. (Powiązania Meduzy z infrastrukturami bulletproof i rynkami MaaS były opisywane w materiałach dot. ekosystemu infostealerów).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów Blue/IT Sec:

  1. Higiena przeglądarek: wymuś automatyczne czyszczenie cookies/„persistent sessions”, ogranicz SSO-only cookies, włącz relog po restarcie przeglądarki.
  2. Polityka haseł i menedżerów: wymuś FIDO2/passkeys, wyłącz legacy SMS 2FA; segreguj hasła służbowe i prywatne.
  3. EDR/AV: sygnatury/YARA pod Meduzę i pochodne; wykrywaj T1497/T1027.013; monitoruj PowerShell/LOLBin-y służące do dropu loaderów. (Wskazówki TTP → Splunk TR).
  4. Proxy/DNS/Egress: blokuj panele znane z MaaS, TLD/ASN charakterystyczne dla bulletproof hostingu; filtruj Telegram CDN, jeżeli polityka na to pozwala (z wyjątkami).
  5. SIEM/UEBA: szukaj anomalii logowań po kradzieży cookies (nagłe zmiany UA/ASN/geo, przeskoki sesji).
  6. IR Playbook: po wykryciu logów ze stealerów – rotate tokens, revoke sessions, reset haseł, rekey portfele i API keys; notyfikuj użytkowników dotkniętych ATO.

Dla użytkowników/zarządów:

  • Nie instaluj „akceleratorów”/pluginów spoza sklepów, aktualizuj przeglądarki, trzymaj użyte rozszerzenia <10 i tylko z audytem.
  • Włącz passkeys, wrażliwe operacje wykonuj w przeglądarce bez rozszerzeń/w profilu tymczasowym.

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

  • Lumma: w maju 2025 r. międzynarodowa operacja (Microsoft DCU, DoJ, Europol itd.) rozbiła infrastrukturę Lumma (seizure ~2,3 tys. domen). To takedown infrastruktury, niekoniecznie areszt twórców. W przypadku Meduzy mówimy o aresztach domniemanych developerów na terytorium Rosji.
  • RedLine: starszy, szeroko dostępny, ale technicznie mniej „świeży”.
  • Aurora: doniesienia badaczy wskazują powiązania personalne/rodowód medialny z Meduzą; nie jest to jednak przesądzone i wymaga dalszej weryfikacji.

Podsumowanie / kluczowe wnioski

  • Aresztowania z 31.10.2025 r. to rzadkie uderzenie Rosji w lokalny MaaS – i sygnał: kto uderzy w krajowe instytucje, może stać się priorytetem organów ścigania.
  • Z perspektywy obrony niewiele się zmienia: podaż infostealerów (forki, nowe panele) szybko wypełnia luki rynkowe – patrz casus Lumma.
  • Organizacje powinny skupić się na utrudnianiu monetyzacji (passkeys, revokacja sesji, hardening przeglądarek) i szybkim IR na wycieki cookies/haseł.

Źródła / bibliografia

  1. The Record: „Three suspected developers of Meduza Stealer malware arrested in Russia” (31.10.2025). (The Record from Recorded Future)
  2. BleepingComputer: „Alleged Meduza Stealer malware admins arrested…” (31.10.2025). (BleepingComputer)
  3. BankInfoSecurity/ISMG: „Russian Police Bust Suspected Meduza Infostealer Developers” (31.10.2025). (bankinfosecurity.com)
  4. Splunk Threat Research: „Meduza Stealer Analysis: A Closer Look at its Techniques and Attack Vector” (23.12.2024). (Splunk)
  5. DataBreaches.net: „Russian Police Bust Suspected Meduza Infostealer Developers” (01.11.2025) – agregat/odsyłacz. (DataBreaches.Net)