Worauf es PrestaShop-Angreifer wirklich abgesehen haben: 1,1 Millionen reale Angriffe, analysiert

Die meisten Ratschläge zur „PrestaShop-Sicherheit“ entspringen der Vorstellungskraft des Verteidigers — einer Liste von Dingen, die schiefgehen könnten. Wir wollten das Gegenteil: eine Messung dessen, was einem Live-PrestaShop-Shop tatsächlich widerfährt, in freier Wildbahn, genau jetzt. Also haben wir unsere eigene Flotte instrumentiert und gezählt.

Wir betreiben und verteidigen mehrere produktive PrestaShop-Shops, und über mehr als ein Jahrzehnt hinweg haben wir einen umfangreichen Katalog an PrestaShop-Modulen entwickelt und gepflegt. Das verschafft uns etwas, das den meisten Sicherheitsartikeln fehlt: eine Reihe realer, stark frequentierter Shops und die Erlaubnis, jede feindselige Anfrage zu beobachten, die auf sie trifft. Sechs Wochen lang haben wir jede bösartige Anfrage aufgezeichnet — nicht nur die erfolgreichen und nicht nur die, die auf Software zielten, die wir tatsächlich einsetzen. Sondierte ein Bot ein Modul, das wir gar nicht installiert haben, protokollierten wir es trotzdem, denn das Ziel war ein ehrliches, vollständiges Bild des Drucks, dem ein normaler Shop ausgesetzt ist.

In Summe waren das rund 1,1 Millionen bösartige Anfragen von mehr als 13.300 verschiedenen IP-Adressen. Hier ist, worauf es die Angreifer wirklich abgesehen hatten — und, für jeden Befund, genau was dagegen zu tun ist.

Erste Wahrheit: Rund 99 % davon sind Rauschen

Das Wichtigste, das man verstehen muss, ist die Form des Traffics. Die überwältigende Mehrheit — weit über eine Million Anfragen — ist automatisierte Aufklärung: Massenscanner, die das Internet abgrasen und dieselben vorgefertigten Payloads auf jede erreichbare IP feuern, gleichgültig, ob Sie PrestaShop, WordPress oder eine Java-Anwendung betreiben.

Das ist zugleich beruhigend und gefährlich. Beruhigend, weil fast alles davon an einem gepatchten, gut konfigurierten Shop abprallt. Gefährlich, weil sich genau in dieser Rauschwand ein gezielter Versuch verbirgt. Das wirklich scharfe Ende ist real, aber klein — in der Größenordnung von 34.000 SQL-Injection-Sondierungen und ein paar tausend Versuchen, Code direkt auf dem Server auszuführen — eine dünne Scheibe, vergraben in einer Million Anfragen Hintergrundrauschen. Wer rohe Access-Logs mit bloßem Auge durchsieht, wird die eine Anfrage, auf die es ankommt, nie zuverlässig erkennen. Das ist das gesamte Argument für strukturierte Erkennung statt „Ich schaue in die Logs, wenn sich etwas komisch anfühlt“.

Hier dasselbe Bild, aufgeschlüsselt nach Zielsetzung.

Zuerst kommen sie für Ihre Geheimnisse

Nach schierem Volumen war das lauteste Einzelziel überhaupt keine Ausnutzung. Es war Diebstahl von Zugangsdaten im großen Stil: über 220.000 Anfragen, die Geheimdateien herunterladen wollten — .env und seine zwölf Varianten (.env.local, .env.production, .env.backup, /api/.env und so weiter), dazu .git/config, Framework-Konfigurationsdateien und zwischengespeicherte Zugangsdaten.

Die Logik ist brutal effizient. Warum einen Exploit schreiben, wenn ein falsch konfigurierter Server das Datenbank-Passwort, den Zahlungs-API-Schlüssel und die Mail-Zugangsdaten schlicht in einer Klartextdatei aushändigt? Eine einzige geleakte .env bedeutet oft das Aus — keine Schwachstelle nötig, nur ein Verzeichnis, das nie öffentlich sein sollte, es aber ist.

Was zu tun ist: Stellen Sie absolut sicher, dass Ihr Web-Server sich weigert, Dotfiles und Konfigurationsdateien auszuliefern. Diese sollten am Rand mit 403 oder 404 antworten, nicht mit ihrem Inhalt. Es ist eine Fünf-Minuten-Änderung, die das häufigste Ziel neutralisiert, das wir aufgezeichnet haben:

# Place these ABOVE your generic PHP handler - nginx matches location blocks in order
# Never serve dotfiles (except ACME) or config/secret files
location ~ /\.(?!well-known/) { deny all; }

location ~* \.(env|git|bak|old|dist|sql|log|lock)$ { deny all; }

location ~* /(composer\.(json|lock)|package(-lock)?\.json|yarn\.lock)$ { deny all; }

# PrestaShop config/credential files (all supported versions)
location ~* /(settings\.inc\.php|parameters\.(php|ya?ml))$ { deny all; }

# Block dotfiles and config/secret files
RedirectMatch 404 /\.(?!well-known)

<FilesMatch "\.(env|git|bak|old|dist|sql|log|lock)$">
    Require all denied
</FilesMatch>

<FilesMatch "^(composer\.(json|lock)|package(-lock)?\.json|yarn\.lock)$">
    Require all denied
</FilesMatch>

# PrestaShop config/credential files (all supported versions)
<FilesMatch "^(settings\.inc\.php|parameters\.(php|ya?ml))$">
    Require all denied
</FilesMatch>

Die Nummer 1 unter den gezielten Komponenten: ein verwaistes Modul

Als wir auf Angriffe filterten, die gezielt auf PrestaShop abzielten, stellte ein Ziel alles andere in den Schatten: eine Local-File-Inclusion-Schwachstelle in einem alten, nicht mehr gepflegten Blog-Modul — rund 32.000 Versuche, mehr als jede andere Modul-Schwachstelle zusammen.

Das ist das Muster, das Shops still und leise ruiniert. Fast nie ist es der PrestaShop-Kern, der Angreifer hereinlässt. Es ist das Drittanbieter-Modul, das Sie vor drei Jahren installiert, nicht mehr aktualisiert und dann vergessen haben. Angreifer pflegen kuratierte Listen davon — Modulname, verwundbarer Pfad, fertiger Exploit — und feuern sie in Endlosschleife über das gesamte Internet.

Weiter unten auf der Liste standen die üblichen Verdächtigen: SQL-Injection-Sondierungen gegen Kontaktformular- und Newsletter-Module, eine bekannte Schwachstelle in einem Wunschlisten-Modul und eine Handvoll Slider- und Such-Add-ons. Alle von Drittanbietern. Alle von der Sorte, die sich über die Jahre in einem Shop ansammelt und dann ungepatcht dort verharrt, lange nachdem sich noch jemand daran erinnert, sie installiert zu haben.

Was zu tun ist: Inventarisieren Sie Ihre Module und löschen Sie die, die Sie nicht nutzen — ein installiertes, aber ungenutztes Modul ist reine Angriffsfläche ohne jeden Nutzen. Patchen Sie die, die Sie behalten, und wenn der Entwickler verschwunden ist, ersetzen Sie das Modul, statt zu hoffen. Wenn Sie auf einer Version festsitzen, die Sie nicht gefahrlos aktualisieren können, führt unser Leitfaden zum Härten eines Shops, den Sie nicht aktualisieren können Schritt für Schritt durch das virtuelle Patchen genau dieser Art von Loch.

Das Einbruchswerkzeug: Webshells und Backdoors

Jenseits der Aufklärung und der Geheimnisjagd sitzt das scharfe Ende. Angreifer versuchten wiederholt, Webshells abzulegen oder aufzuspüren — die Werkzeuge, die aus einer einzelnen Schwachstelle volle Fernsteuerung machen. Die Dateinamen sind fast schon eine Signatur für sich: adminer.php, alfa.php, wso.php, vereinzelte phpinfo-Sondierungen und Datenbankmanager-Skripte, die von einer früheren Kompromittierung zurückgelassen wurden.

Wir haben auch etwas Gezielteres als generisches Scannen erwischt. Wird ein Shop in einer Gruppe kompromittiert, nehmen Angreifer genau das Payload, das dort funktioniert hat, und feuern es auf jeden verwandten Shop, den sie finden können, in der Wette, dass dieselbe Backdoor noch auf einem anderen sitzt. Beharrlichkeit zahlt sich aus: Eine Backdoor, vergraben in einer selten inspizierten Datei, kann mehrere oberflächliche „Bereinigungen“ überleben und einen Shop über Wochen immer wieder neu infizieren. Wenn Sie einmal eine Kompromittierung bereinigt haben, indem Sie nur das sichtbare bösartige JavaScript entfernt haben, und sie zurückkam, dann ist das der Grund — wir sind genau dieses Versagen in unserer Anatomie eines Magecart-artigen Skimmers durchgegangen.

Was zu tun ist: Verweigern Sie die PHP-Ausführung in jedem Verzeichnis, das ausschließlich Uploads, Bilder, Cache oder Werkzeuge enthalten sollte. Schafft es ein Bot, shell.php in Ihren Bilderordner zu schreiben, entscheidet allein darüber, ob der Server sie ausführt, ob es ein schlechter Tag oder ein vollständiger Einbruch wird:

# Put this ABOVE your existing "location ~ \.php$" block - nginx is first-match-wins
# A bot that writes shell.php into an image folder must never get it executed
location ~* ^/(img|upload|uploads|cache|var|download)/.*\.(php|phar|phtml|php[0-9])$ {
    deny all;
}

# Drop this .htaccess inside an uploads folder: turn PHP off for the whole tree
<FilesMatch "\.(php|phar|phtml|php[0-9])$">
    Require all denied
</FilesMatch>

Sie prüfen nicht einmal, was Sie betreiben

Ein bezeichnendes Beispiel dafür, wie automatisiert das alles ist: Wir haben Zehntausende Exploit-Versuche protokolliert, die auf völlig andere Technologie-Stacks zielten — Java- und JSF-Payloads, WordPress-Plugin-Exploits, ASP.NET-Tricks —, alle blind auf PHP-Shops gefeuert, die dafür niemals anfällig sein könnten.

Die Lehre ist nicht „Ha, daneben“. Sie ist das Gegenteil: Sie werden ununterbrochen angegriffen, von Angreifern, die weder wissen noch sich darum scheren, was Sie betreiben. Sie müssen kein Ziel sein, um Opfer zu werden. Sie müssen nur erreichbar und veraltet sein.

Prüfen Sie Ihren eigenen Shop jetzt

Darüber zu lesen ist eine Sache; hier sind vier Prüfungen, die Sie in den nächsten fünf Minuten an Ihrem eigenen Shop durchführen können. Sie zielen genau auf das ab, wonach die oben beschriebenen Angreifer suchen.

1. Sind Ihre Geheimnisse tatsächlich erreichbar? Fragen Sie von Ihrem eigenen Rechner aus genau die Dateien ab, die auch die Scanner abfragen. Jede Zeile sollte mit 403 oder 404 antworten — niemals mit 200 samt Inhalt:

# From your own machine: 403/404 = safe, 200 = exposed, 000 or 3xx = check by hand
for f in .env .git/config app/config/parameters.php composer.json; do
  printf '%s -> ' "$f"
  curl -s -o /dev/null --connect-timeout 5 --max-time 15 -w '%{http_code}\n' "https://your-store.com/$f"
done

2. Versteckt sich PHP dort, wo nur Assets hingehören? Suchen Sie per SSH ausgehend von Ihrem Shop-Root nach ausführbaren Dateien in Ordnern, die ausschließlich Uploads und Bilder enthalten sollten. Hier sollte nichts ausgegeben werden:

# PHP hiding in folders that should only hold assets (a clean store prints nothing)
find img upload uploads download -type f \
  \( -iname '*.php' -o -iname '*.php[0-9]' -o -iname '*.phtml' -o -iname '*.phar' \) \
  ! -iname index.php 2>/dev/null

3. Was hat sich kürzlich geändert? Eine frisch eingeschleuste Backdoor ist eine kürzlich geänderte PHP-Datei, die Sie nicht angefasst haben. Lassen Sie sich die Änderungen der letzten Woche anzeigen und nehmen Sie alles Unbekannte genau unter die Lupe:

# PHP changed in the last 7 days, cache excluded (GNU/Linux find) - review anything unfamiliar
find . \( -path ./var/cache -o -path ./cache \) -prune -o \
  -type f -iname '*.php' -mtime -7 -printf '%TY-%Tm-%Td  %p\n' | sort

4. Wer kann sich in Ihr Back Office einloggen? Jedes Konto ist ein Schlüssel zur Haustür. Überprüfen Sie jeden Mitarbeiter, den Sie nicht kennen, sowie jeden, der sich seit Monaten nicht mehr angemeldet hat:

-- Back-office accounts: investigate any you do not recognise
-- Run in phpMyAdmin or the mysql client; change the ps_ prefix if yours differs
SELECT id_employee, email, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;

Was wir auf unseren eigenen Shops tatsächlich tun

Weil das auch unsere Shops sind, ist die obige Verteidigungsliste nicht theoretisch. Auf den Shops in dieser Studie blockieren wir Dotfiles und Konfigurationsdateien am Rand, verweigern die PHP-Ausführung über jeden beschreibbaren Pfad, halten den Modul-Fußabdruck bewusst klein und entfernen alles Ungenutzte, erzwingen Zwei-Faktor-Authentifizierung im Admin und setzen das Ganze hinter eine Edge-Schicht, die Scanner drosselt und offensichtliche Injection-Payloads verwirft. Und wir lassen den Rekorder laufen — dieselbe Protokollierung auf Anfrageebene, die diesen Artikel hervorgebracht hat —, damit ein wirklich gezielter Versuch an die Oberfläche kommt, statt in den 99 % Rauschen unterzugehen. Nichts davon ist exotisch. Alles davon ist unspektakulär, und unspektakulär ist, was funktioniert.

• Blockieren Sie Geheimdateien am Rand. .env, .git, composer.json und Konfigurationsdateien müssen 403/404 zurückgeben — niemals ihren Inhalt.
• Lichten Sie Ihre Module aus. Löschen Sie alles, was Sie nicht nutzen; ein ungenutztes Modul ist reine Angriffsfläche.
• Patchen oder ersetzen Sie, was Sie behalten. Besonders Drittanbieter-Add-ons für Blog, Slider, Formulare und Suche.
• Verweigern Sie PHP in beschreibbaren Ordnern. Uploads, Bilder, Cache und tmp sollten niemals Code ausführen.
• Sichern Sie den Admin-Login. Starke, einzigartige Zugangsdaten und Zwei-Faktor-Authentifizierung.
• Bleiben Sie auf einer unterstützten Version. Eine abgekündigte Plattform kommt mit einem dauerhaften Satz bekannter Schlüssel.
• Setzen Sie Erkennung zwischen sich und das Rauschen, damit sich das eine Prozent, auf das es ankommt, nicht in den 99 % verstecken kann, auf die es nicht ankommt.

Häufig gestellte Fragen

Das Fazit

Lässt man das Volumen beiseite, ist das Bild einfach. Die Angriffe, die gelingen, verlassen sich fast nie auf einen exotischen Zero-Day. Sie verlassen sich auf das Unspektakuläre: eine lesbar belassene Geheimdatei, ein ungepatchtes oder verwaistes Drittanbieter-Modul, ein Verzeichnis, das eine hochgeladene PHP-Datei ausführt, ein Admin-Login mit einem schwachen oder wiederverwendeten Passwort, eine veraltete Plattform. Nichts davon ist schwer zu beheben. All das sind Dinge, die ein gepflegter Shop richtig macht und ein vernachlässigter nicht. Die Angreifer haben die Suche nach Vernachlässigung automatisiert — millionenfach in sechs Wochen. Die einzige echte Verteidigung ist, nicht vernachlässigt zu sein: patchen, ausmisten, die offensichtlichen Türen abschließen und echte Erkennung zwischen sich und diese Rauschwand setzen.

Methodik-Hinweis: Die Zahlen sind aus der Angriffsprotokollierung auf Anfrageebene über mehrere Live-Produktionsshops hinweg über ein rund sechswöchiges Fenster bis Juli 2026 aggregiert. Alle Daten sind anonymisiert; es sind keine Details zu Shops, Kunden oder Zugangsdaten enthalten, und es werden keine Exploit-Spezifika veröffentlicht.