Tag: Phishing

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)