Gehackte PrestaShop-Shops: Skimmer, umgeleitete Zahlungen und Hintertüren aus der Praxis

Ein Onlineshop wird nicht gehackt wie im Film. Es gibt keine roten Bildschirme und keine Totenköpfe auf der Startseite. Meistens ist es genau umgekehrt: Der Shop läuft einwandfrei, Bestellungen gehen ein, Kunden bezahlen und der Inhaber merkt nichts. Währenddessen kopiert jemand die Kartendaten im Zahlungsschritt, kassiert auf ein Konto, das nicht Ihres ist, oder hält sich eine Hintertür offen, um jederzeit zurückzukommen.

Bei Rekire bereinigen wir kompromittierte PrestaShop-Shops öfter, als uns lieb ist. Dieser Artikel fasst zusammen, was wir bei diesen Einsätzen gesehen haben. Die Fälle sind echt, aber wir schildern sie so, dass unmöglich zu erkennen ist, um welchen Shop es sich handelt: ohne Branche, ohne Stadt, ohne Daten, ohne Zahlen und ohne Details, mit denen man ihn finden könnte. Wichtig ist nicht, wer, sondern wie, denn das Wie wiederholt sich.

Der Artikel ist absichtlich lang. Wenn Ihr Shop auf einer alten PrestaShop-Version läuft, bitten wir Sie, ihn ganz zu lesen.

Was ein Skimmer ist und warum er der beliebteste Angriff auf einen Shop ist

Ein Skimmer (auch Kartenkloner oder Magecart-Angriff genannt) ist ein Stück JavaScript, das sich in Ihren Shop einschleicht und die Kartendaten genau in dem Moment stiehlt, in dem der Kunde sie eingibt. Kartennummer, Ablaufdatum, CVV und Name des Karteninhabers gehen an einen Server des Angreifers, und die Bestellung läuft ganz normal weiter.

Es ist der lukrativste Angriff, den es auf einen Onlineshop gibt, und zwar aus drei Gründen:

• Er macht nichts kaputt. Der Kunde kauft, Sie erhalten Ihr Geld, niemand beschwert sich. Die gestohlenen Daten werden Wochen später woanders verwendet, und wenn die Bank des Kunden den Betrug bemerkt, bringt niemand die Karte mit Ihrem Shop in Verbindung.
• Ihr Zahlungsanbieter muss dafür nicht verwundbar sein. Es spielt keine Rolle, ob Sie das virtuelle Kartenterminal Ihrer Bank, Stripe oder PayPal verwenden. Der Skimmer greift nicht den Zahlungsanbieter an, sondern die Seite, auf der sich der Kunde befindet.
• Er skaliert. Ein Shop mit normalem Traffic liefert Dutzende Karten pro Woche, ohne dass der Angreifer noch etwas tun muss.

Fall 1: das Kartenformular, das es nicht gab

Das erste Anzeichen war eine automatische Warnung unseres Sicherheitsmoduls: Ein Template des Zahlungsschritts im Theme hatte sich geändert, obwohl niemand das Theme angefasst hatte.

Als wir der Spur folgten, kam der gesamte Ablauf zum Vorschein, rekonstruiert anhand der Serverprotokolle:

1. Jemand meldete sich mit korrektem Benutzernamen und Passwort im Hosting-Panel an. Es war keine Schwachstelle von PrestaShop: Das Passwort war geleakt.
2. Über den Dateimanager des Panels schrieb er rund 60 KB JavaScript in eine Datei des Themes selbst, die bis dahin leer gewesen war. Eine Datei mit langweiligem Namen, wie sie niemand öffnet.
3. Er fügte am Ende des Templates für den Zahlungsschritt eine einzige Zeile hinzu: ein <script src>, das diese Datei lud. Von der Domain des Shops selbst, sodass kein Filter für „externe Domains“ angeschlagen hätte.
4. Er lud eine kleine PHP-Datei hoch, um den Template-Cache zu leeren, führte sie aus und verschwand. Alles in weniger als zwanzig Minuten.

Solange der Kunde nur stöberte, tat das JavaScript nichts. Es wurde erst aktiv, wenn der Kunde die Zahlung per Karte auswählte. In diesem Moment blendete es ein Kartenformular ein, das genauso aussah wie das des Shops, und schickte die eingegebenen Daten verschlüsselt per navigator.sendBeacon an einen anderen, ebenfalls gehackten Onlineshop, der als Briefkasten diente. Die Website eines anderen Opfers als Ziel zu nutzen, ist üblich: Eine gewöhnliche Shop-Domain erregt keinen Verdacht.

Der Skimmer war etwa eine Woche lang aktiv. Die Arbeit danach war genauso wichtig wie die Bereinigung: die Liste der Bestellungen und Zahlungen dieser Tage ziehen, um den Zahlungsdienstleister zu informieren, und mit dem Verantwortlichen des Shops die Meldung an die AEPD (die spanische Datenschutzbehörde) abwägen, die nach DSGVO (Artikel 33) innerhalb von 72 Stunden ab Kenntnis der Verletzung erfolgen muss.

Was darunter zum Vorschein kam

Bei der Durchsicht der Mitarbeiter im Backoffice fanden wir etwas Schlimmeres: mehr als zwanzig gefälschte Super-Administratoren, alle mit derselben E-Mail-Adresse und dem Namen „Prestashop Addons“, Monate zuvor in Schüben innerhalb einer Sekunde angelegt. Diese Art, sie anzulegen — viele auf einmal, mit derselben E-Mail —, ist die Handschrift einer SQL-Injection, nicht die von jemandem, der über das Anmeldeformular hereinkommt. Die wahrscheinlichste Quelle war ein Controller im Page Builder eines kommerziellen Themes, der jedem antwortete, ohne die Sitzung zu prüfen, und einen ungefilterten Parameter in eine Datenbankabfrage einsetzte.

Kein früheres Audit hatte sie bemerkt. Die Tür des Shops stand seit Monaten offen, und der Skimmer war nur das, was schließlich auffiel.

Fall 2: die Zahlungen, die auf ein anderes Konto gingen

Dieser Fall erklärt am besten, warum wir sagen, dass man einen Angriff nicht sieht. Der Shop verkaufte ganz normal. Die Kartenbestellungen erschienen im Backoffice als bezahlt, mit Transaktionsnummer, korrektem Status und Rechnung. Alles stimmte … nur dass dieses Geld nie auf dem Bankkonto des Shops ankam.

Der Angreifer hatte die Hauptdatei des Zahlungsmoduls der Bank durch eine veränderte Kopie ersetzt. Die Änderung bewirkte Folgendes:

• Sie ersetzte die Kartenzahlung durch ein Formular eines internationalen Zahlungsanbieters, das mit einem Konto des Angreifers verbunden war. Bizum blieb unverändert, eine andere Zahlungsart wurde ausgeblendet, damit der Kunde direkt zur Karte ging.
• Sie schrieb einen gefälschten Datensatz in die Tabellen des Bankmoduls, sodass die Bestellung im Backoffice wie eine normale Zahlung aussah.
• Sie wurde für die Mitarbeiter des Shops nicht aktiv, ebenso wenig für E-Mail-Adressen, die nach Test-Adressen oder nach der Agentur aussahen, die den Shop betreute. Wer den Shop testete, sah die gewohnte Zahlung.
• Sie meldete dem Angreifer jede Zahlung per Telegram.
• Sie bewahrte ihre Schlüssel außerhalb des Web-Ordners auf, im Home-Verzeichnis des Hosting-Kontos.
• Und sie konnte sich selbst zerstören, indem sie die Originaldateien wiederherstellte, die sie gleich daneben abgelegt hatte.

Der Zugang erfolgte per FTP, mit dem Hauptkonto des Hostings, das dasselbe Passwort hatte wie das Panel. Die FTP-Protokolle zeigten über Wochen Dutzende Sitzungen von derselben Adresse, in denen Dateien hochgeladen und angepasst wurden, als wäre da einfach ein weiterer Entwickler am Werk.

Und wie kam es heraus? Durch einen Fehler des Angreifers selbst, und genau dieser Teil ist für uns interessant. Der Shop war gerade auf PrestaShop 9 migriert worden. Der Schadcode war für die alte Version geschrieben, und beim erneuten Einschleusen lud der Angreifer die Dateien des Zahlungsmoduls aus dem alten Shop hoch. Unter PrestaShop 9 funktionierten diese Dateien nicht mehr: Der Shop zeigte nur noch eine weiße Seite. Ohne diesen Ausfall wäre die Umleitung weitergegangen. Beim Abgleich der Bestellungen mit der Spur, die der gefälschte Code hinterließ, kamen Dutzende umgeleitete Zahlungen über mehrere Monate zum Vorschein.

Fall 3: Hintertüren dort, wo niemand hinschaut

Für einen Skimmer oder eine Umleitung muss der Angreifer in Ihren Shop schreiben können. Um jederzeit zurückzukommen, hinterlässt er eine Web-Shell: eine PHP-Datei, die ihm, über ihre URL aufgerufen, erlaubt, Befehle auszuführen oder Dateien auf Ihren Server zu schreiben. Hier einige, die wir gefunden haben — achten Sie darauf, wo sie lagen:

• Eine 30-Byte-Zeile (ein eval dessen, was mit der Anfrage ankommt) im Ordner eines Moduls, das gar nicht installiert war. Der Ordner lag seit Jahren auf der Festplatte, niemand prüfte ihn, und PrestaShop 1.7 führt jede .php-Datei in modules/ aus, wenn jemand sie per URL aufruft.
• Eine Datei mit weniger als 200 Byte, deren Name mit einem Punkt begann, im Stammverzeichnis des Shops. Sie tat nur eines: jede empfangene Datei auf den Server schreiben. Kein automatischer Scanner erkannte sie; sie fiel erst auf, als der Shop Datei für Datei mit einer älteren Kopie verglichen wurde.
• Eine vollständige Shell mit mehr als 80 KB (Dateimanager, Befehlsausführung, Datei-Upload) im Ordner eines nativen PrestaShop-Moduls, mit dem Lizenz-Header von PrestaShop, „PrestaShop“ als Autor und Funktionen mit harmlosen Namen. Eine exakte Kopie lag in einem anderen aufgegebenen Modul, falls jemand die erste löschte.
• Ein als QR-Code-Leser getarnter Dateimanager, in sauberem, gut lesbarem PHP geschrieben, in einem Plugin einer WordPress-Installation, die sich das Hosting mit dem Shop teilte. Von dort aus wurde das JavaScript des PrestaShop-Themes umgeschrieben, ohne PrestaShop zu irgendeinem Zeitpunkt anzufassen.
• Eine Zeile im Ordner vendor/ eines Moduls, die eine Datei mit der Endung .jpeg einband … die in Wirklichkeit PHP war. Der Shop hatte mit dieser offenen Tür zwei Bereinigungen hinter sich, weil das verwendete Werkzeug vendor/ standardmäßig ausschloss.
• Ein 6-KB-Loader in einem ansonsten legitimen Versandmodul, der einen WebSocket öffnete und ausführte, was ihm geschickt wurde. Auf der Festplatte gab es sonst nichts: Der Schadcode kam bei jedem Besuch neu und diente dazu, die Backoffice-URL samt Token an eine externe Domain zu schicken.

Sabotage mit einem einzigen Zeichen

Am meisten gelernt haben wir bei einem Shop, in dem der Angreifer neben den Hintertüren zwei Dateien des PrestaShop-Kerns verändert hatte. In der einen war ein regulärer Ausdruck, der HTML-Tags entfernt, so gelockert worden, dass er nichts mehr entfernte. In der anderen hatte er den Abschluss des Klassenindex entfernt, den PrestaShop erzeugt, sodass alles, was am Ende angehängt wurde, als Code ausgeführt wurde: automatische Neuinfektion, ohne dass eine eigene Datei nötig war.

Keine Mustererkennungsregel hätte das entdeckt. Gefunden hat es der Byte-für-Byte-Vergleich mit dem offiziellen PrestaShop-ZIP derselben Version.

Wie sie hereinkommen (fast immer)

Wenn man alle Fälle nebeneinanderlegt, wiederholen sich die Einfallstore:

Beachten Sie, dass nur eines der fünf ein „reiner“ Programmierfehler ist. Bei den übrigen geht es um Wartung: was installiert ist, was überflüssig ist und wer Schlüssel hat.

Warum fast alle gehackten Shops alt waren

Das ist kein Zufall. Bei fast allen Vorfällen, die wir bearbeitet haben, lief der Shop auf PrestaShop 1.6 oder 1.7, mit PHP 7.x und mit Modulen, die seit Jahren nicht aktualisiert worden waren. Damit kommen Risiken zusammen, die sich gegenseitig verstärken:

• PHP 7.4 erhält seit Ende 2022 keine Sicherheitspatches mehr, frühere Versionen schon länger nicht. Eine neue Schwachstelle in PHP wird für Ihren Server nie behoben werden.
• Die alten PrestaShop-Zweige erhalten keine Korrekturen mehr, und viele Module von Drittanbietern veröffentlichen keine Versionen mehr dafür. Wenn eine Schwachstelle in einem verbreiteten Modul bekannt wird, erscheint die Korrektur für die aktuelle Version. Können Sie sie nicht installieren, weil Ihr Shop zu alt ist, ist die Schwachstelle öffentlich und Ihr Shop bleibt offen.
• Alte Shops sammeln verwaiste Module an: Ordner von Modulen, die vor Jahren getestet und wieder deinstalliert wurden, aber noch auf der Festplatte liegen und sich unter 1.7 per URL ausführen lassen. In PrestaShop 9 verbietet die .htaccess in modules/ die direkte Ausführung von PHP bereits.
• Je älter der Shop, desto größer die Scheu, ihn anzufassen. Und was man nicht anfasst, wird auch nicht geprüft.

Aktualisieren ist keine absolute Garantie: Der Shop aus Fall 2 lief schon auf PrestaShop 9, aber der Angreifer war vorher hereingekommen, mit dem Hosting-Passwort. Was ein aktueller Shop aber leistet: Er schließt die bekannten Einfallstore und sorgt dafür, dass jede ungewöhnliche Änderung auffällt. Ein alter Shop ist ein Shop, in dem die bekannten Einfallstore offen bleiben und niemand irgendetwas mit irgendetwas vergleicht.

Was wir bei Rekire tun, wenn ein Shop gehackt wurde

Wenn ein kompromittierter Shop zu uns kommt, gehen wir immer in derselben Reihenfolge vor. Die Reihenfolge ist wichtig: Zuerst die schädliche Datei zu löschen, ist der schnellste Weg, damit der Angreifer eine Woche später auf demselben Weg wiederkommt.

1. Forensische Kopie, bevor irgendetwas angefasst wird. Dateien und Datenbank, außerhalb der Website gesichert. Wer löscht, ohne zu kopieren, verliert den Beweis dafür, was passiert ist, seit wann und welche Daten offengelegt wurden.
2. An einer isolierten Kopie arbeiten. Wir holen den Shop in unsere eigene Umgebung, ohne Internetzugang, mit abgefangenen E-Mails und deaktivierten Zahlungsanbietern, um ihn ohne das Risiko zu analysieren, dass er Kunden anschreibt oder Zahlungen einzieht.
3. Mit etwas Bekanntem vergleichen. Den Kern mit dem offiziellen ZIP derselben PrestaShop-Version. Die Module mit ihrem Originalpaket. Den ganzen Shop mit einer älteren Kopie, falls es eine gibt. Was sich ohne Grund geändert hat, ist der erste Verdächtige.
4. Prüfen, was keine Datei ist. Mitarbeiter und Profile, Webservice-Konten und ihre Berechtigungen, geplante Aufgaben auf dem Server, Konfigurationsschlüssel der Zahlungsanbieter, JavaScript in CMS-Seiten, in der Konfiguration oder in Produktbeschreibungen.
5. Das Einfallstor finden. Web-Zugriffsprotokolle, FTP- und Panel-Protokolle. Solange man nicht weiß, wo sie hereingekommen sind, ist jede Bereinigung nur vorläufig.
6. Erst den Zugang schließen, dann bereinigen. Das verwundbare Modul korrigieren oder entfernen, die Ordner absichern, überflüssige FTP-Konten löschen. Danach die schädlichen Dateien in Quarantäne verschieben, wo sie als Beweis aufbewahrt statt gelöscht werden.
7. Alle Zugangsdaten wechseln. Panel, FTP, Datenbank, Mitarbeiter, API-Schlüssel von Zahlungsanbietern und Diensten. Und alle offenen Backoffice-Sitzungen beenden.
8. Den Schaden ermitteln. Welche Bestellungen und Zahlungen über den Shop liefen, während der Code aktiv war, um den Zahlungsdienstleister zu informieren und mit dem Verantwortlichen für die Datenverarbeitung über die Meldung an die AEPD zu entscheiden.
9. Überwachung einrichten. Eine saubere Ausgangsbasis und Warnungen, die in dem Moment ausgelöst werden, in dem sich wieder etwas ändert.
10. Die grundlegende Lösung vorschlagen. Läuft der Shop auf einer Version ohne Support, den Migrationsplan. Einen alten Shop zu bereinigen, ohne ihn zu migrieren, verschafft Zeit, löst aber nichts.

RKR Security Alert: das Modul, das aus all dem entstanden ist

Jeder der hier geschilderten Vorfälle zwang uns, Prüfungen von Hand zu erledigen, die sich automatisieren ließen. Daraus ist RKR Security Alert entstanden, das Sicherheitsmodul, das wir bei Rekire entwickelt haben und in unseren eigenen Audits einsetzen. Es läuft auf PrestaShop 1.7.6 bis 9.2 — gerade weil die Shops, die es am dringendsten brauchen, diejenigen sind, die noch nicht migriert haben.

Was es überwacht

• Zahlungsdaten und Konfiguration. Es speichert eine Momentaufnahme von Konfiguration, Modulen, Mitarbeitern, Shop-URLs und Webservice-Konten und vergleicht sie mit dem aktuellen Stand. Es ist nicht auf PrestaShop-Ereignisse angewiesen: Ändert jemand etwas direkt per SQL und umgeht dabei das Backoffice, erscheint die Änderung trotzdem. Änderungen an Zahlungsanbietern werden als kritisch markiert.
• Mitarbeiter. Neuanlagen, Änderungen und Löschungen, wobei Super-Administrator-Konten hervorgehoben werden. Die gefälschten Administratoren aus Fall 1 hätten noch am Tag ihrer Anlage eine Warnung ausgelöst.
• Anmeldungen. Anmeldung im Backoffice von einer neuen IP-Adresse, mit Land, Stadt und Hinweis, wenn es sich um einen Proxy, ein VPN oder ein Rechenzentrum handelt.
• Die Templates des Zahlungsvorgangs. Fingerabdruck aller Checkout-Templates aller installierten Themes, nicht nur des aktiven. Dass sich eines davon ändert, ist bereits die Warnung: Genau das hat Fall 1 verraten.
• Module nach Version. Ändern sich die Dateien eines Moduls, ohne dass sich seine Version geändert hat, oder taucht ein neues auf, wird gewarnt. Das hätte den Austausch des Zahlungsmoduls in Fall 2 verraten.
• Geplante Aufgaben und die Absicherung der Ordner.

Wonach es in den Dateien sucht

• Zahlungs-Skimmer, Hintertüren und Web-Shells, Befehlsausführung, Verschleierung, eingeschleustes JavaScript und in Bildern versteckter Code.
• Web-Shells, die an ihren Fähigkeiten erkannt werden und nicht nur an Signaturen: Dateien auflisten, schreiben und löschen, mit einem Pfad, der als Parameter übergeben wird. So werden auch jene gefunden, die in sauberem PHP geschrieben sind, wie der falsche QR-Leser aus Fall 3.
• Vergleich des Kerns mit dem offiziellen PrestaShop-ZIP — das Einzige, was die Änderung eines einzigen Zeichens in einer legitimen Datei erkennt.
• Ein kritischer Fund lässt sich nicht mit einem Pfadmuster ausblenden: Das haben wir von dem Shop gelernt, der zwei Bereinigungen mit einem Loader in vendor/ überstanden hatte.

Der Scan läuft in Etappen und wird fortgesetzt, wo er aufgehört hat, sodass er nicht am Zeitlimit des Servers scheitert, und jeder Fund kommt mit seinem Beleg: was gefunden wurde, in welcher Zeile und von wo aus es erreichbar ist.

Der Wächter im Browser

Manche Angriffe hinterlassen nichts auf der Festplatte, wie der WebSocket-Loader aus Fall 3, oder zeigen sich erst, wenn der Kunde etwas tut, wie das gefälschte Formular aus Fall 1. Dafür enthält das Modul einen Wächter, der die fertig aufgebaute Seite im Browser beobachtet: Er warnt, wenn nach dem Laden der Seite ein Kartenfeld außerhalb eines iframes erscheint, wenn der Checkout per sendBeacon, fetch oder XHR Daten an eine neue Domain schickt, wenn ein externer WebSocket geöffnet wird oder wenn eine Seite einen Systembefehl in die Zwischenablage schreibt, ohne dass der Nutzer etwas angeklickt hat (die als ClickFix bekannte Technik mit dem gefälschten Captcha). Der Wächter speichert den Inhalt dieser Anfragen nie: In einem Checkout enthielten sie echte Kartendaten.

Gedacht für Shops, die schon angeschlagen ankommen

Es wird im Modus Erstaudit installiert: Es betrachtet nichts als „normal“, bis Sie den Bericht durchgesehen haben. War der Shop bei der Installation schon infiziert, geht die Infektion nicht in die Ausgangsbasis ein. Die Warnungen kommen per Telegram, nach Schweregrad sortiert (Sie können eine Gruppe für das Wichtige und eine andere für reine Informationen anlegen), und bleiben außerdem im Posteingang des Panels, auch wenn Sie Telegram nicht nutzen.

Und eine Designentscheidung, die uns wichtig ist: Nichts verlässt Ihren Shop. Die Analyse läuft auf Ihrem Server, mit Regeln, die im Modul mitgeliefert werden. Keine Datei, kein Ausschnitt und keine Daten aus Ihrer Datenbank werden an irgendjemanden gesendet.

Checkliste für diese Woche

Wenn Sie bis hierhin gelesen haben, können Sie Folgendes ohne fremde Hilfe erledigen:

1. Öffnen Sie Erweiterte Einstellungen → Team und prüfen Sie jeden Mitarbeiter. Gibt es einen, den Sie nicht kennen, vor allem mit Super-Administrator-Profil, behandeln Sie den Shop als kompromittiert.
2. Gleichen Sie die Zahlungen der letzten Woche im Dashboard Ihres Zahlungsanbieters mit den bezahlten Bestellungen im Shop ab.
3. Machen Sie einen Testkauf mit einer E-Mail-Adresse, die nicht zum Shop gehört, in einem Browser ohne Administratorsitzung, und achten Sie darauf, ob das Zahlungsformular das gewohnte ist.
4. Ändern Sie das Passwort des Hosting-Panels und des FTP, sodass es nirgendwo sonst verwendet wird, und aktivieren Sie die Zwei-Faktor-Authentifizierung im Panel, wenn Ihr Anbieter sie anbietet.
5. Lassen Sie sich von Ihrem Hoster die Liste der FTP-Konten geben und löschen Sie die, die Sie nicht nutzen.
6. Sehen Sie unter Module nach, was installiert ist, und per FTP, welche Ordner in modules/ liegen. Was auf der Festplatte liegt, aber nicht in der Liste steht, ist überflüssig.
7. Prüfen Sie, welche PrestaShop- und PHP-Version Sie haben. Ist es PrestaShop 1.6 oder 1.7 oder PHP 7.x, legen Sie einen Termin für die Migration fest.

Migrieren ist kein Luxus, sondern die wichtigste Sicherheitsmaßnahme

Wir wissen, dass man eine Shop-Migration gern vor sich herschiebt und Respekt davor hat. Module, Theme, URLs, Zahlungen und Rechnungen müssen überprüft werden. Aber nachdem wir all diese Fälle von innen gesehen haben, ist unser Fazit eindeutig: Der teuerste Shop im Unterhalt ist der, der nicht aktualisiert wird. Ein Vorfall kostet die Bereinigung, die Meldung, die Rückbuchungen, die Zeit des Teams und vor allem das Vertrauen der Kunden, deren Karten anderswo benutzt wurden.

Eine Migration auf PrestaShop 9 mit aktuellem PHP schließt auf einen Schlag die bekannten Einfallstore der alten Versionen, zwingt Sie zu einer Bestandsaufnahme dessen, was installiert ist, und bringt Sie auf eine Version, die weiterhin Korrekturen erhält. Wenn Sie zusätzlich überwachen, was sich ändert, fällt der nächste Versuch noch am selben Tag auf.

So lösen Sie es in PrestaShop

RKR Security Alert überwacht Konfiguration, Zahlungen, Mitarbeiter, Anmeldungen, Checkout-Templates und Dateien, vergleicht den Kern mit dem offiziellen ZIP und warnt per Telegram, sobald sich etwas ändert, auf PrestaShop 1.7.6 bis 9.2. RKR Sentinel meldet Ihnen Fehler auf der Website, bevor Ihre Kunden sie Ihnen melden — und ein Shop, der plötzlich nur noch eine weiße Seite zeigt, wie der aus Fall 2, ist ein Fehler, den man besser innerhalb einer Minute sieht. RKR Order Guard verhindert doppelte Bestellungen, Zahlungsstatus und Rechnungen, damit das, was das Backoffice anzeigt, verlässlich ist, wenn Sie es mit der Bank abgleichen.

Und wenn Sie vermuten, dass Ihr Shop kompromittiert ist, oder ihn migrieren möchten, bevor es so weit ist: Mit den Support-Stundenpaketen von Rekire übernehmen wir das Audit, die Bereinigung nach der Methode aus diesem Artikel und die Migration auf PrestaShop 9.