Checkout.com: incydent z „legacy” chmurą, próba szantażu ShinyHunters i nietypowa odpowiedź firmy

securitybeztabu.pl 6 godzin temu

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, ale 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, iż środki klientów ani numery kart nie były zagrożone. Checkout.com zadeklarował, iż 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, iż 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, iż 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.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). o ile 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 – adekwatni 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 / najważniejsze wnioski

Największym ryzykiem nie był core processing, ale „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)