Pomagamy Zrozumieć i Wdrażać Bezpieczeństwo
Jeszcze do niedawna wiele firm spało spokojnie, wierząc, że regularne kopie zapasowe uchronią je przed każdym atakiem. W końcu, jeśli dane zostaną zaszyfrowane, zawsze można je odzyskać z backupu, prawda? Niestety, nowa generacja ransomware – tzw. Ransomware 2.0 – brutalnie weryfikuje to założenie.
Czytaj dalej „Dlaczego Tradycyjny Backup Kapituluje Przed Ransomware 2.0”
OpenAI poinformowało 26 listopada 2025 r., że na skutek incydentu bezpieczeństwa w firmie Mixpanel (dostawca analityki front-end) doszło do wycieku ograniczonych danych identyfikujących część użytkowników OpenAI API. OpenAI podkreśla, że nie był to atak na jej infrastrukturę i nie wyciekły: treści czatów, zapytania API, klucze API, hasła, dane płatnicze ani dokumenty tożsamości. Z integracji Mixpanel zrezygnowano i rozpoczęto notyfikację podmiotów dotkniętych zdarzeniem.
Mixpanel opisał zdarzenie jako skutek kampanii smishingowej z 8 listopada 2025 r., która doprowadziła do nieautoryzowanego eksportu zbiorów danych części klientów. Firma wdrożyła działania IR, m.in. reset haseł pracowników, unieważnienie sesji i rotację poświadczeń.
Według OpenAI, 9 listopada 2025 r. Mixpanel wykrył nieautoryzowany dostęp i eksport zbioru danych zawierającego ograniczone PII oraz metadane analityczne części klientów. 25 listopada Mixpanel przekazał OpenAI kopię dotkniętych danych, co umożliwiło notyfikacje i ocenę ryzyka. Następnego dnia OpenAI opublikowało komunikat i FAQ.
Równolegle Mixpanel opublikował własny wpis, wskazując na smishing (SMS phishing) jako wektor inicjujący incydent i opisując działania zaradcze (m.in. blokada IP, rejestracja IOC w SIEM, forensics).
Wektor ataku: kampania smishingowa wymierzona w pracowników/użytkowników Mixpanel doprowadziła do naruszenia części systemów i eksportu danych customers’ analytics. (To typowy scenariusz „initial access” przez socjotechnikę → eskalacja → eksfiltracja).
Zakres danych: metadane analityczne z warstwy front-end dla kont API, czyli: identyfikatory organizacyjne/użytkownika i podstawowe atrybuty profilu (imię/nazwa, e-mail), informacje o urządzeniu/przeglądarce/OS, referrery i przybliżona geolokalizacja z przeglądarki. Nie obejmuje to treści promptów, usage logs API ani sekretów.
Łańcuch dostawców (vendor risk): incydent ilustruje ekspozycję ryzyka przez integracje telemetryczno-analityczne w produktach SaaS, gdzie dane PII i identyfikatory techniczne są rutynowo przetwarzane przez podmioty trzecie. Niezależne doniesienia branżowe (SecurityWeek, The Register) potwierdzają timeline i działania OpenAI (odpięcie Mixpanel, notyfikacje).
Dla właścicieli kont OpenAI API (org/admin):
Dla zespołów SOC/IR: szybkie „hunt queries” (przykłady):
subject contains ("Mixpanel" OR "OpenAI") AND body contains ("security incident" OR "key rotation" OR "API") w ostatnich 14–30 dniach.openai.com, platform.openai.com, mixpanel.com.--disable-features=SafeBrowsing, „headless” itp. po kliknięciu w linki.W przeciwieństwie do głośnych wycieków treści czatów lub danych billingowych, tutaj mamy klasyczny „vendor breach” w łańcuchu dostaw: ekspozycja metadanych i PII o niskiej/średniej wrażliwości, ale o dużej wartości do socjotechniki. Schemat przypomina incydenty u zewnętrznych procesorów (MarTech/Analytics), gdzie realne ryzyko wynika z łączności identyfikatorów technicznych z danymi kontaktowymi — paliwo dla spear-phishingu. Relacje branżowe (SecurityWeek, The Register) potwierdzają, że reakcją OpenAI było odpięcie dostawcy i przegląd całego ekosystemu vendors.
Canon potwierdził, że incydent dotknął spółkę zależną firmy w wyniku niedawnej kampanii wymierzonej w instalacje Oracle E-Business Suite (EBS). Według oświadczenia przesłanego do redakcji SecurityWeek, wpływ został ograniczony do serwera WWW i przywrócono już jego działanie po wdrożeniu środków bezpieczeństwa. Na moment publikacji nie ujawniono wycieku danych Canon.
Na początku października 2025 r. Oracle i firmy badawcze opisały ukierunkowaną kampanię kradzieży danych i wymuszeń na klientach EBS. W krótkim czasie pojawiły się dwa pilne alerty bezpieczeństwa: najpierw dla CVE-2025-61882 (zero-day RCE), a następnie – poza zwykłym cyklem – dla CVE-2025-61884. Google Threat Intelligence wskazał, że ataki zaczęły się już w sierpniu, a do eskalacji służył łańcuch technik obejmujący m.in. SSRF i inne prymitywy webowe; e-maile z żądaniami okupu podpisywał Cl0p, lecz taktyki przypominały wcześniejsze kampanie FIN11.
CVE-2025-61882 (EBS – pre-auth RCE). CrowdStrike opisał zero-day umożliwiający zdalne wykonanie kodu bez uwierzytelnienia w komponentach EBS. Wektor ataku był dostępny z sieci (HTTP), co przekładało się na wysoką podatność środowisk wystawionych do Internetu.
CVE-2025-61884 (Oracle Configurator / Runtime UI – SSRF). Oracle wydał out-of-band Security Alert, podkreślając, że luka jest łatwa do wykorzystania, nie wymaga uprawnień ani interakcji użytkownika i może prowadzić do dostępu do wrażliwych zasobów (CVSS 7.5). CISA włączyła CVE-2025-61884 do KEV, co nakazuje federalnym agencjom szybkie wdrożenie łatek/mitigacji. Opisy w NVD i CISA klasyfikują problem jako SSRF w komponencie Runtime UI Oracle Configurator (EBS 12.2.3–12.2.14).
Łańcuch eksploatacji. Google Threat Intelligence odnotował, że publicznie wyciekły narzędzia/PoC łączyły SSRF, CRLF-injection, obejście uwierzytelnienia oraz wstrzyknięcia XSL do osiągnięcia wykonania kodu na serwerze EBS. W konsekwencji atakujący potrafili wydobywać pliki i przeprowadzać wymuszenia finansowe na ofiarach.
Kampania przypomina wcześniejsze „masowe wymuszenia po zero-day’u” znane z akcji Cl0p (MOVEit, Fortra), ale unikalny jest cel – system ERP Oracle EBS – oraz techniczny łańcuch obejmujący SSRF i elementy RCE. Atrybucja operacyjna wskazuje na FIN11, podczas gdy marka Cl0p służy jako „front” komunikacyjny w e-mailach do ofiar.
Salesforce poinformował o „nietypowej aktywności” dotyczącej aplikacji publikowanych przez Gainsight (partnera z AppExchange), która mogła umożliwić nieautoryzowany dostęp do danych części klientów poprzez zewnętrzne połączenie aplikacji z instancjami Salesforce. W reakcji Salesforce unieważnił wszystkie aktywne access i refresh tokeny powiązane z tymi aplikacjami oraz tymczasowo usunął je z AppExchange na czas śledztwa. Firma podkreśla, że nie chodzi o lukę w samym rdzeniu platformy CRM, lecz o wektor przez integrację z aplikacją zewnętrzną. Źródła branżowe wiążą sprawę z aktywnością grupy ShinyHunters, która miała wykorzystać poświadczenia powiązane z wcześniejszą kampanią Salesloft/Drift.
W sierpniu–wrześniu 2025 r. doszło do szerokiej kampanii kradzieży danych z instancji Salesforce przez kompromitację integracji Salesloft/Drift i kradzież tokenów OAuth. Wtedy ShinyHunters przypisywało sobie atak na setki firm. Obecny incydent z Gainsight ma podobny profil — wektor przez zaufane połączenie aplikacyjne, nie przez samą platformę Salesforce. Media odnotowują ciągłość taktyk: „przeskakiwanie” między SaaS-ami przez łańcuch integracji i nadmierne uprawnienia aplikacji.
Kluczowym elementem jest OAuth oraz refresh tokeny wydawane dla aplikacji zewnętrznych (Connected Apps). Gdy aplikacja ma szerokie zakresy (scopes) i długowieczne refresh tokeny, atakujący, którzy zdobędą którykolwiek z sekretów (token, client secret, zapisane poświadczenia w logach/zgłoszeniach), mogą:
Salesforce zareagował zgodnie z najlepszą praktyką: całkowita revokacja tokenów dla dotkniętych aplikacji i ich czasowe wycofanie z AppExchange, aby przerwać łańcuch odświeżania. To minimalizuje możliwość dalszego „mintowania” access tokenów z przejętych refresh tokenów.
Dla administratorów Salesforce / SecOps:
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).
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.
Najczęstsze przyczyny ekspozycji „legacy cloud file storage”:
GetObject, ListBucket, GetBlob, File.Read z rzadkich agentów i nietypowych ASN/VPN.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).
Poniżej gotowa checklista do użycia z zespołem IR/SecOps/Cloud (AWS/Azure/GCP analogicznie):
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 descGCP 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: highaws s3 ls --profile legacy-account / az storage account list / gsutil ls -p <ID>).az ad sp list --filter "appOwnerOrganizationId ne null" / przegląd IAM Roles bez rotacji).Synnovis – dostawca usług diagnostyki laboratoryjnej dla kilku londyńskich trustów NHS – został 3 czerwca 2024 r. zaatakowany przez grupę ransomware Qilin. Skutkiem były poważne zakłócenia świadczeń, a część danych pacjentów trafiła na stronę wyciekową przestępców. Po zakończeniu długiej analizy śledczej Synnovis rozpoczął teraz formalny proces powiadamiania organizacji NHS, których dane znajdują się w zbiorze wykradzionym i opublikowanym przez napastników. Zgodnie z brytyjskim prawem to poszczególni świadczeniodawcy mają informować konkretnych pacjentów.
Po ataku z 3 czerwca 2024 r. w regionie południowo-wschodniego Londynu odwoływano zabiegi i wizyty, szczególnie dotknięte były banki krwi oraz planowe operacje. W kolejnych tygodniach Qilin zaczął publikować próbki skradzionych danych, w tym rekordy badań dotyczących m.in. HIV i nowotworów. W 2025 r. – w miarę prac analitycznych – NHS na bieżąco publikował Q&A dla opinii publicznej. 10 listopada 2025 r. pojawiła się informacja, że śledztwo Synnovis zostało domknięte i rusza sekwencja powiadomień na poziomie organizacji (trusty, GP, inne podmioty).
Łańcuch ataku i TTPs (wysoki poziom): Qilin to ekosystem RaaS stosujący klasyczny model double extortion – szyfrowanie + publikacja danych na stronie wyciekowej. Po początkowym włamaniu (wektor nie został publicznie potwierdzony), atakujący uzyskali dostęp do systemów Synnovis, co doprowadziło do zakłóceń usług oraz eksfiltracji plików. Publikacja danych miała charakter stopniowy (samples → większe paczki), co jest typową taktyką zwiększania presji. (Wnioski na bazie raportów prasowych i komunikatów instytucji; brak pełnej publikacji IOCs przez Synnovis/NHS.)
Charakter danych: Najbardziej wrażliwą część stanowiły formularze patologia/histologia, które służą do przekazywania informacji między jednostkami medycznymi – zawierają opisy objawów i kontekstu klinicznego (np. podejrzenie STI, rodzaj zmiany nowotworowej). Zidentyfikowano także dane identyfikacyjne i, w części przypadków, dane kontaktowe. To dokładnie te typy informacji, które w kontekście RODO (UK GDPR) kwalifikują się jako szczególne kategorie danych osobowych.
Dlaczego analiza trwała tak długo? Synnovis informuje, że skradziony zestaw był „nieustrukturyzowany, niekompletny i fragmentaryczny”, co wymagało użycia specjalistycznych platform do korelacji i odtwarzania właścicieli danych (data controllers/processors). Dopiero po takim forensicu możliwe było mapowanie rekordów do konkretnych organizacji NHS i ich pacjentów. Ten etap zakończono i wyznaczono termin zakończenia powiadomień organizacji na 21 listopada 2025 r.
W porównaniu z typowymi incydentami w szpitalach, atak na dostawcę patologii generuje efekt domina: jeden LIMS obsługuje wiele trustów i GP, więc pojedynczy punkt awarii paraliżuje szeroki obszar. To tłumaczy tysięczne odwołania świadczeń w Londynie po czerwcu 2024 r. – skala zaburzeń była większa niż przy wielu pojedynczych atakach na szpitale, bo dotyczyła wspólnego węzła usługowego.
Systemy biometryczne wykorzystują cechy fizyczne lub behawioralne do identyfikacji i uwierzytelniania osób. Biometria obejmuje m.in. cechy fizjologiczne (twarz, tęczówka, odcisk palca, geometria dłoni, siatkówka oka) oraz behawioralne (głos, podpis odręczny, chód, sposób pisania na klawiaturze). W odróżnieniu od tradycyjnych metod (hasła, PIN-y, karty dostępu), cech biometrycznych nie da się zgubić ani zapomnieć, a próby oszukania systemu przez wykradzenie cech są trudniejsze – przynajmniej w teorii.
Czytaj dalej „Systemy Biometryczne: Architektura, Podatności i Zabezpieczenia”