Scenariusz ataku na sklep internetowy — studium przypadku

Kontekst: profil atakowanego sklepu

MegaShop (nazwa zmieniona) to średniej wielkości polski sklep internetowy:

• Platforma: WooCommerce na WordPress 6.x
• 45 000 aktywnych klientów, 800 zamówień/dzień
• 12 wtyczek, w tym 3 premium (bramka płatnicza, ERP, marketing automation)
• Zespół IT: 2 deweloperów, 1 admin serwera (bez dedykowanego security)
• Obrót: 35 mln PLN/rok
• Brak dedykowanego SOC lub monitoringu bezpieczeństwa

Dzień 0: Rekonesans

Atakujący rozpoczyna od passive reconnaissance — zbierania informacji bez bezpośredniego kontaktu ze sklepem:

• Wappalyzer/BuiltWith ujawnia: WordPress 6.4.2, WooCommerce 8.5, PHP 8.1, serwer Nginx
• Subdomain enumeration odkrywa: staging.megashop.pl (kopia produkcji z danymi testowymi)
• Google dorking (site:megashop.pl filetype:sql OR filetype:log) — brak wyników, ale site:staging.megashop.pl ujawnia directory listing z plikami logów
• Shodan pokazuje otwarty port 3306 (MySQL) na serwerze staging
• LinkedIn — profile 2 deweloperów z informacjami o stosowanych technologiach

Atakujący wie już, że staging jest słabszym ogniwem. Zaczyna active recon.

Dzień 1-3: Exploitation serwera staging

Serwer staging ma:

• WordPress z domyślnym loginem admin/admin (niezmieniony po klonowaniu z produkcji)
• Wtyczkę WP File Manager w wersji 6.8 z krytyczną podatnością RCE (CVE-2024-XXXX)
• Bazę danych z kopią 45 000 rekordów klientów z produkcji (adresy, telefony, historię zamówień)

Atakujący:

1. Loguje się do panelu WordPress staging z domyślnymi danymi
2. Wykorzystuje podatność WP File Manager do uploadu web shella
3. Uzyskuje dostęp do bazy danych staging — kopiuje 45 000 rekordów klientów
4. Analizuje konfigurację wp-config.php — znajduje klucze API do bramki płatniczej (te same co na produkcji!)
5. Odkrywa, że SSH key na staging pozwala na dostęp do serwera produkcyjnego (współdzielony klucz)

Dzień 4-7: Lateral movement do produkcji

Z kluczem SSH atakujący uzyskuje dostęp do serwera produkcyjnego:

1. Instalacja persistence — backdoor w postaci zmodyfikowanego pliku functions.php motywu (trudny do wykrycia, bo wygląda jak legalny kod WordPress)
2. Eskalacja uprawnień — z konta www-data do root przez outdated kernel exploit
3. Instalacja web skimmera — złośliwy JavaScript wstrzyknięty do pliku WooCommerce checkout

Skimmer jest zaawansowany:

• Aktywuje się tylko na stronie checkout
• Przechwytuje dane kart w momencie wpisywania (przed tokenizacją)
• Dane wysyła do domeny cdn-analytics-megashop.com (wyglądającej jak legalna)
• Obfuskowany kod wygląda jak fragment analytics
• Nie aktywuje się dla IP z zakresu firmy (anti-detection)

Dzień 8-30: Eksfiltracja danych

Przez 22 dni skimmer działa niewykryty:

• 8 200 numerów kart płatniczych przechwyconych
• Dane osobowe (imiona, adresy, telefony) skradzione przy każdej transakcji
• Hashe haseł wyeksportowane z bazy (bcrypt, ale atakujący odzyska ~15% słabych haseł)
• Logi zamówień z pełnymi danymi klientów

Jednocześnie atakujący:

• Wykorzystuje skradzione klucze API do testowych refundów (małe kwoty, by nie wzbudzić podejrzeń)
• Instaluje cryptominer na serwerze staging (dodatkowy przychód)
• Sprzedaje bazę 45 000 klientów na dark web za 2 000 USD

Dzień 31: Wykrycie incydentu

Klient MegaShop zgłasza bankowi nieautoryzowaną transakcję. Bank identyfikuje MegaShop jako Common Point of Purchase (CPP) — wielu klientów sklepu zgłasza oszustwa.

Bank powiadamia procesora płatności, który:

1. Informuje MegaShop o podejrzeniu kompromitacji
2. Wymaga natychmiastowego PCI Forensic Investigation
3. Grozi wyłączeniem terminali płatniczych

MegaShop dowiaduje się o ataku nie z własnego monitoringu, a od banku — po 22 dniach aktywności skimmera.

Analiza: co poszło nie tak

Luka	Wpływ	Zapobieganie
Staging z danymi produkcyjnymi	Wyciek 45 000 rekordów	Anonimizacja danych na staging
Domyślne hasła admin na staging	Punkt wejścia ataku	Silne hasła + MFA wszędzie
Współdzielony SSH key	Lateral movement	Osobne klucze per środowisko
Brak monitoringu integralności plików	Skimmer niewykryty 22 dni	FIM + CSP + SOC
Brak segmentacji staging/produkcja	Pełen dostęp z jednego punktu	Izolacja środowisk
Nieaktualna wtyczka z RCE	Exploit na staging	Regularne aktualizacje + skanowanie podatności

Konsekwencje i koszty

Finansowe (łącznie ~2,1 mln PLN):

• PCI Forensic Investigation: 180 000 PLN
• Kary PCI DSS: 400 000 PLN
• Chargebacks: 320 000 PLN
• Notyfikacja 45 000 klientów: 90 000 PLN
• Kara UODO (RODO): 500 000 PLN
• Utracone przychody (3 miesiące obniżonej sprzedaży): 600 000 PLN

Operacyjne:

• 2 tygodnie pracy w trybie awaryjnym
• Wymiana całej infrastruktury serwerowej
• Przejście na tokenizację płatności
• Wdrożenie monitoringu bezpieczeństwa 24/7

Reputacyjne:

• Wielu klientów nie wróciło po incydencie
• Negatywne media i social media
• Utrata zaufania partnerów biznesowych

---

Cyberbezpieczeństwo w Twojej branży

Dowiedz się więcej o cyberbezpieczeństwie w Twojej branży:

• Cyberbezpieczeństwo dla branży: E-commerce i handel internetowy

---

Powiązane usługi i produkty

• Vectra AI ITDR
• Vectra AI NDR
• WALLIX Bastion