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”:
- Niepełna utylizacja zasobu – bucket / storage account pozostaje aktywny po migracji.
- Słabe tożsamości/aplikacje – zapomniane konta serwisowe, klucze dostępu, stare tokeny OAuth/refresh.
- Niewłaściwe ACL/udostępnienia – publiczne linki, szerokie „AllUsers/AllAuthenticatedUsers”.
- Brak SPM (Secret/Key Management) – klucze w repo, w starych CI/CD, na share’ach.
- 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.Readz 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 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: high3) 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
- 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)
