Die Kunst der Verschleierung: eine neue Magecart-Kampagne, die 404-Seiten missbraucht
Zusammenfassung
Die Akamai Security Intelligence Group hat eine Magecart-Web-Skimming-Kampagne entdeckt, die eine große Zahl von Websites zum Ziel hat, darunter große Unternehmen in der Lebensmittel- und Einzelhandelsbranche.
Diese Kampagne sticht durch drei fortschrittliche Verschleierungstechniken hervor, von denen wir eine noch nie zuvor gesehen haben – nämlich die Manipulation der Standard-404-Fehlerseite der Website, um bösartigen Code zu verheimlichen –, was die Erkennung und Schadensbegrenzung erheblich erschwert.
Die beiden anderen Verschleierungstechniken zeigen die Weiterentwicklung der Taktiken auf, die Angreifer nutzen, um die Erkennung zu vermeiden und die Angriffskette zu verlängern.
Da Web-Skimming-Angriffe immer ausgefeilter werden, müssen Unternehmen wachsam bleiben und fortschrittliche Ansätze zum Schutz vor diesen weiterentwickelten Bedrohungen erkunden.
Einführung
Eine neue, heimliche und ausgeklügelte Magecart-Web-Skimming-Kampagne nimmt Magento- und WooCommerce-Websites ins Visier. Einige der Opfer dieser Kampagne haben Verbindungen zu großen Organisationen in der Lebensmittel- und Einzelhandelsindustrie.
Die von uns gefundenen Beweise deuten darauf hin, dass diese Kampagne bereits seit einigen Wochen und in einigen Fällen sogar noch länger läuft. Diese Kampagne überraschte uns mit einer hoch entwickelten Verschleierungstechnik, die uns bisher noch nicht begegnet war.
Die neue Kampagne
Magecart-Angriffe beginnen in der Regel mit dem Ausnutzen von Schwachstellen in den entsprechenden Websites oder mit der Infizierung der Services von Drittanbietern, die diese Websites nutzen. Bei dieser Kampagne wurden alle betroffenen Websites, die wir entdeckten, direkt infiziert, indem das schädliche Code-Snippet in eine ihrer Erstanbieter-Ressourcen injiziert wurde.
In einigen Fällen wurde der schädliche Code in die HTML-Seiten eingefügt; in anderen Fällen wurde er in einem der Erstanbieterskripte verborgen, die als Teil der Website geladen wurden.
Wie bei vielen anderen Magecart-Kampagnen besteht die Angriffsinfrastruktur dieser Kampagne aus drei Hauptteilen: Loader, schädlicher Angriffscode und Datenextraktion (Abbildung 1).
Loader – kurze, versteckte JavaScript-Code-Snippets, die für das Laden des vollständigen Angriffs-Schadcodes verantwortlich sind
Schädlicher Angriffscode – der wesentliche JavaScript-Code, der den Angriff ausführt; er erkennt sensible Eingaben, liest die Daten, unterbricht den Checkout-Prozess und fügt gefälschte Formulare ein
Datenextraktion – die Methode, mit der die gestohlenen Daten an den C2-Server (Command and Control) des Angreifers übertragen werden
Der Zweck der Aufteilung des Angriffs in drei Teile besteht darin, den Angriff so zu verbergen, dass er schwieriger zu erkennen ist. Dies ermöglicht es, den vollständigen Angriff nur auf den speziell angegriffenen Seiten auszulösen, d. h., aufgrund der vom Angreifer verwendeten Verschleierungsmaßnahmen kann der vollständige Angriffsablauf gezielt nur dort ausgelöst werden, wo der Angreifer ihn ausführen wollte. Dadurch wird der Angriff unauffälliger und kann von Sicherheitsservices und externen Scanning-Tools, die die angegriffene Website gegebenenfalls überwachen, schwerer entdeckt werden.
Obwohl die meisten Magecart-Kampagnen Ähnlichkeiten in Bezug auf Ablauf und Phasen aufweisen, unterscheidet sich eine Kampagne von einer anderen durch die verschiedenen Verschleierungstechniken, die Angreifer anwenden. Diese Techniken werden verwendet, um die Infrastruktur des Angriffs zu verschleiern, Spuren zu verbergen, die Erkennung und das Reverse Engineering zu erschweren und letztlich den Angriff zu verlängern.
Drei Varianten der Kampagne
Wir haben drei verschiedene Varianten dieser Kampagne gefunden, die die Weiterentwicklung des Angriffs und die Verbesserungen zeigen, die die Angreifer im Laufe der Zeit vorgenommen haben, um die Entdeckung und Abwehr dieser Kampagne zu verhindern:
Die ersten beiden Varianten sind ziemlich ähnlich, mit nur geringfügigen Unterschieden im Loader.
Die dritte Version ist insofern außergewöhnlich, als die Angreifer die Standard-404-Fehlerseite der Website nutzten, um ihren Schadcode zu verbergen; dies ist eine kreative Verschleierungstechnik, die wir bisher noch nicht gesehen haben.
Werfen wir einen genaueren Blick auf die technischen Details der drei Varianten dieser neuen Kampagne.
Variante 1
Unsere Nachforschungen begannen, als wir auf der Website eines großen Unternehmens verdächtige Code-Snippets bemerkten, die von unseren Threat Intelligence-Überwachungstools entdeckt wurden. Bei der Analyse dieser Snippets stellten wir fest, dass es sich um böswillig codierte JavaScript-Loader handelte, die noch auf der Website vorhanden und aktiv waren. Diese Entdeckung veranlasste uns zu weiteren Nachforschungen, bei denen wir die gesamte Kampagne mit ihren Varianten und Auswirkungen auf zahlreiche Websites aufdeckten.
Loader der Variante 1: die Spitze des Eisbergs
Der Skimmer injizierte erfolgreich ein fehlerhaftes HTML-Bild-Tag mit einem onerror- Attribut in die befallene Website (Abbildung 2). Dieses Attribut enthält ein verschleiertes Base64-codiertes Code-Snippet des schädlichen Loaders. Das absichtlich leere src-Attribut des Image-Tags soll Netzwerkanfragen verhindern und die Ausführung eines Inline- onerror- Callbacks mit dem verschleierten schädlichen JavaScript-Code-Snippet auslösen.
Die Verwendung von Bild-Tags zur Ausführung von JavaScript-Code ist eine seltenere und ausgefeilte Technik. Auf diese Weise kann der Skimmer Sicherheitsmaßnahmen wie externe Scanner umgehen, die normalerweise den Netzwerkverkehr analysieren und in diesem speziellen Fall nicht ausgelöst werden. Der verschleierte Code wird im Kontext der Seite und so ausgeführt, als wäre er ein natives Erstanbieterskript, das von der Seite selbst aufgerufen wurde.
Fig. 2: Variation one loader — an improperly formatted HTML image tag with an onerror attribute containing malicious loader code
Decodierter Loader-Code – Laufzeit
Sobald der verschleierte Base64-codierte Code zur Laufzeit ausgeführt wird, wird er in JavaScript umgewandelt und veranlasst die Öffnung eines WebSocket-Kanals (Abbildung 3). Dieser Kanal dient als bidirektionale Kommunikationsverbindung zwischen dem Browser und dem C2-Server des Angreifers.
Die Verwendung von WebSockets bei Magecart-Angriffen wurde bei mehreren aktuellen Kampagnen beobachtet. WebSocket gilt als weniger auffällige und flexiblere Kommunikationsmethode, die es dem Angreifer ermöglicht, einen einzelnen Netzwerkkanal für verschiedene Zwecke zu nutzen. Dazu gehört das Senden verschiedener Teile des Angriffs vom C2-Server an den Browser (und umgekehrt) sowie die Erleichterung der Datenextraktion in bestimmten Szenarien.
Ein weiterer bemerkenswerter Aspekt des Codes ist die Bot-Erkennung, die prüft, ob der User Agent automatisiert gesteuert wird. Wenn dies der Fall ist, wird die Ausführung des Codes abgebrochen. Dies ist eine clevere Anti-Bot-Technik, um externen Sicherheitsscannern und Sandboxen zu entgehen, die den Angriff möglicherweise erkennen könnten.
Fig. 3: The runtime-decoded JavaScript code of the variation one loader
WebSocket-Kommunikationsfluss
Sobald der WebSocket-Kanal eingerichtet ist, wird die erste Nachricht vom C2-Server des Angreifers an den Browser gesendet. Diese Nachricht wird als Base64-codierte Zeichenfolge übertragen, die einen einzeiligen JavaScript-Befehl enthält, der den Browser anweist, die aktuelle URL der Seite zurückzugeben.
Mit diesem Schritt kann der C2-Server bestimmen, ob es sich bei der aktuellen Seite um eine Checkout-Seite (sensible Seite) oder eine beliebige Nicht-Checkout-Seite handelt. Auf diese Weise kann der Angreifer die nächsten Schritte entsprechend anpassen.
Diese unkomplizierte serverseitige Validierung ermöglicht es dem Angreifer, den Angriff nur auf den entsprechenden Zielseiten zu aktivieren und so eine potenzielle Entdeckung auf nicht sensiblen Seiten zu vermeiden. Dies ist ein weiteres Beispiel, das die Anstrengungen des Skimmers zeigt, um der Erkennung durch Sicherheitsservices und externe Scanner zu entgehen.
Wenn der C2-Server die URL einer Checkout-Seite erkennt, geht der Ablauf zur nächsten Phase über. In diesem Schritt wird eine weitere Nachricht an den Browser gesendet. Dabei handelt es sich um eine lange Base64-codierte Zeichenfolge, die den gesamten Angriffscode enthält. Die Dekodierung dieser Zeichenfolge ergibt einen langen, verschleierten JavaScript-Code (Abbildung 4).
Dieser Code ist für verschiedene schädliche Aktivitäten auf der sensiblen Seite verantwortlich, mit dem Ziel, die sensiblen personenbezogenen und Kreditkartendaten des Nutzers zu lesen und an den C2-Server des Skimmers zu übertragen.
Nachfolgende verschleierte Datenextraktionsnachrichten, die die vom bösartigen Code gesammelten sensiblen gestohlenen Daten enthalten, werden vom Browser an den C2-Server gesendet. Wie bereits erwähnt, wird der Prozess durch die Verwendung desselben WebSocket-Kanals sowohl zum Laden des vollständigen Schadcodes als auch zum Extrahieren gestohlener Daten unauffälliger und erfordert weniger Netzwerkanfragen als herkömmliche Kommunikationsmethoden wie XHR, FETCH oder HTML-Ressourcenanforderungen.
Fig. 4: WebSocket flow on checkout pages
Variante 2
Loader der Variante 2: neue Regeln, altes Spiel
Der Hauptunterschied zwischen Variante 1 und Variante 2 liegt in der Loader-Komponente. In Variante zwei fügt der Skimmer ein Inline-Skript mit einem Code-Snippet ein, das dem Meta-Pixel-Code-Snippet, einem bekannten Service zur Verfolgung von Facebook-Besucheraktivitäten, sehr ähnlich ist, jedoch einige zusätzliche Zeilen enthält (Abbildung 5).
Diese hinzugefügten Zeilen sind der eigentliche Loader-Teil, während der umgebende Meta-Pixel-Code eine irreführende Tarnung ist, um es so aussehen zu lassen, als handele sich um ein legitimes und unverdächtiges Codeschnipsel.
Diese Verschleierungstechnik, bei der die schädlichen Code-Snippets als bekannte Dienste wie Google Tag Manager oder Facebook auftreten, hat in den jüngsten Magecart-Kampagnen an Popularität gewonnen. Sie ermöglicht es Skimmern, statische Analysen durch externe Scanner und Forscher zu vermeiden.
Fig. 5: Variation two loader — inline script disguised as Meta PIxel code snippet with a malicious loader inside it
Anforderung eines Bildes
Als wir die verdächtigen Zeilen im gefälschten Meta-Pixel-Code-Snippet sorgfältig überprüften, schien es ein PNG-Bild aus dem eigenen Verzeichnis der Website zu holen. Die Netzwerkanfrage schien eine typische Anfrage nach einem harmlosen auf der Website gehosteten Bild zu sein. Bei der Untersuchung des tatsächlichen Inhalts dieses Bildes wurde jedoch deutlich, dass es nicht so harmlos war, wie es schien (Abbildung 6).
Fig. 6: Network image request for an image that has been tampered with by the attacker and contains malicious code
Schädliches JavaScript-Code-Snippet in einer Bild-Binärdatei
Die Binärdaten des PNG-Bildes enthalten eine Base64-codierte Zeichenfolge, die an das Ende der Bild-Binärdatei angehängt wird (Abbildung 7). Diese Zeichenfolge wird dann extrahiert, decodiert und vom Loader-Code-Snippet ausgeführt (Abbildung 8). Die decodierte Zeichenfolge stellt ein JavaScript-Code-Snippet dar, das mit jenem im onerror- Attribut des Loaders von Variante 1 identisch ist.
Die nachfolgenden Schritte des Ablaufs sind unverändert. Dieses Code-Snippet wird zur Laufzeit in einfachen JavaScript-Code umgewandelt, der Code stellt den WebSocket-Kanal zum C2-Server des Angreifers her, und der Rest des Ablaufs erfolgt wie zuvor beschrieben.
Fig. 7: The binary data of the image that contains the concealed malicious code
Fig. 8: The malicious code, which was initially encoded in Base64 and concealed within the image, becomes apparent after decoding
Variante 3
Kommen wir nun zum besten Teil. Obwohl wir ähnliche Angriffe gesehen haben, ist dieser hier einzigartig und hat uns wirklich überrascht.
Loader der Variante 3: gleich und doch völlig anders
Auf den ersten Blick sieht dieser Loader jenem in Variante zwei ähnlich, aber Sie werden (wie wir) sehen, dass es sich um ein völlig anderes Szenario handelt. In einigen Fällen ist dieser Loader als Meta-Pixel-Code-Snippet getarnt, wie in Variante 2 (Abbildung 9) zu sehen ist. In anderen Fällen wird er jedoch in zufälligen Inline-Skripten auf der Seite injiziert (Abbildung 10).
Der erste bemerkenswerte Aspekt dieses Loaders ist eine Abruf-Anfrage zu einem relativen Pfad namens „Icons“.
Fig. 9: Variation three loader — a malicious code snippet concealed within a code snippet that mimics the appearance of Meta Pixel
Fig. 10: Variation three loader —- a malicious code snippet concealed within an arbitrary inline script
Ein 404-Fehler? Wirklich?
Nachdem der Loader ausgeführt wurde, sendet der Angriff eine Abruf-Anfrage an /icons, einen relativen Pfad, der eigentlich nicht existiert. Diese Anforderung führte zu einem „404 Not Found“-Fehler (Seite nicht gefunden, Abbildung 11). Bei der Analyse des in der Antwort zurückgegebenen HTML-Codes schien es sich um die Standard-404-Seite der Website zu handeln (Abbildung 12). Dies war verwirrend, und wir fragten uns, ob der Skimmer auf den gefundenen angegriffenen Websites nicht mehr aktiv war.
Fig. 11: Request initiated by the loader to a nonexistent path that returns 404 error
Fig. 12: Default error page HTML
Niemals den Loader unterschätzen
Wir traten einen Schritt zurück und analysierten den Loader neu, und dabei fanden wir das fehlende Puzzleteilchen. Der Loader enthielt eine regex-Übereinstimmung für die Zeichenfolge „COOKIE_ANNOT“, die auf der 404-Fehlerseite ausgeführt werden sollte, die im Rahmen der „icons“-Anforderung zurückgegeben wurde.
Wir haben also nach dieser Zeichenfolge innerhalb des zurückgegebenen 404-HTML-Codes gesucht, und voilà! Am Ende der Seite entdeckten wir einen versteckten Kommentar, der die Zeichenfolge „COOKIE_ANNOT“ enthielt (Abbildung 14). Neben dieser Zeichenfolge war eine lange Base64-codierte Zeichenfolge verkettet. Diese codierte Zeichenfolge stellt den gesamten verschleierten JavaScript-Angriffscode dar. Der Loader extrahiert diese Zeichenfolge aus dem Kommentar, decodiert sie und führt den Angriff aus, mit dem die von Nutzern eingegebenen persönlichen Informationen gestohlen werden.
Wir simulierten weitere Anfragen an nicht existierende Pfade, und alle lieferten dieselbe 404-Fehlerseite, die den Kommentar mit dem verschlüsselten Schadcode enthielt. Diese Prüfungen bestätigen, dass der Angreifer die Standard-Fehlerseite für die gesamte Website erfolgreich geändert und den schädlichen Code darin verborgen hat.
Fig. 13: Loader variation 3 - regex match for the string "COOKIE_ANNOT".
Fig. 14: The malicious encoded comment that was hidden within the error page HTML
Datenextraktion
Gefälschtes Formular
Im Gegensatz zu den Varianten 1 und 2 verwendeten die Angreifer in Variante 3 eine andere gängige Datenextraktionstechnik – Injektion eines gefälschten Formulars (Abbildung 15). Diese Technik wird in der Regel verwendet, wenn der Skimmer keinen Zugang zu sensiblen Dateneingaben hat.
Dies kann auftreten, wenn eine Website einen Zahlungsdienst eines Drittanbieters verwendet, der das Zahlungsformular innerhalb eines Drittanbieter-iFrames oder einer externen Seite implementiert. Um solche Szenarien zu umgehen, erstellt der Angreifer ein gefälschtes Formular, das dem ursprünglichen Zahlungsformular sehr ähnlich ist und es überlagert – eine Technik, die immer beliebter wird. Und genau auf diese Weise werden in Variante drei gestohlene Daten extrahiert.
Fig. 15: The fake form injected by the malicious code
Wenn der Nutzer Daten in das gefälschte Formular des Angreifers überträgt, wird ein Fehler angezeigt, das gefälschte Formular wird ausgeblendet, das ursprüngliche Zahlungsformular wird angezeigt, und der Nutzer wird aufgefordert, seine Zahlungsdetails erneut einzugeben (Abbildung 16).
Fig. 16: The fake form is hidden and the user is prompted to re-enter their information
Bildanforderung mit gestohlenen Daten
Durch das Senden des gefälschten Formulars wird eine Anforderung des Bildnetzwerks an den C2-Server des Angreifers ausgelöst, die alle gestohlenen persönlichen und Kreditkarteninformationen als Base64-codierte Zeichenfolge im Abfrageparameter enthält (Abbildung 17). Wenn diese Zeichenfolge decodiert wird, zeigt sie den wahren Zweck der Anforderung an, und der gesamte Ablauf des Angriffs wird deutlich.
Fig. 17: Image network request with the stolen data included as a Base64-encoded string query parameter
Lehren aus Variante 3: das 404-Szenario
Diese Verschleierungstechnik ist sehr innovativ und etwas, das wir in früheren Magecart-Kampagnen noch nicht gesehen haben. Die Idee, die Standard-404-Fehlerseite einer betroffenen Website zu manipulieren, kann Magecart-Akteuren verschiedene kreative Möglichkeiten bieten, Schadcode besser zu verstecken und Schutzmaßnahmen zu umgehen.
In einigen der von uns identifizierten Fälle war der schädliche Loader zum Zeitpunkt des Schreibens dieser Zeilen bereits von den Seiten der betroffenen Websites entfernt. Der schädliche Kommentar auf der Standard-404-Fehlerseite blieb jedoch erhalten, sodass der Skimmer den Angriff leicht reaktivieren kann. Dies verdeutlicht die Komplexität der Erkennung und die Wichtigkeit der Abwehr dieser Angriffsart.
Die Anforderung an den Erstanbieter-Pfad, der zur 404-Seite führt, ist eine weitere Umgehungsmethode, mit der Content Security Policy-Header und andere Sicherheitsmaßnahmen umgangen werden können, die möglicherweise die Netzwerkanforderungen auf der Seite aktiv analysieren. Dies zählt zweifellos zu den ausgefeilteren Magecart-Strategien, die wir in letzter Zeit gesehen haben.
Akamai Client-Side Protection & Compliance gegen den Skimmer
Im Rahmen unserer Forschung zu dieser Kampagne haben wir eine Simulation dieses Skimmers gegen Akamai Client-Side Protection & Compliancedurchgeführt, unsere Lösung, die das Laufzeitverhalten ausgeführten JavaScript-Codes analysiert, um JavaScript-Bedrohungen abzuwehren und clientseitige Angriffe abzuwehren.
Die Lösung erkannte den ausgeklügelten Skimmer erfolgreich und löste ein Ereignis mit hohem Schweregrad aus, das umgehend behoben werden musste. In einem realen Szenario, in dem Client-Side Protection & Compliance auf einer bestimmten Webseite aktiv ist, zeigt Abbildung 18 die Warnung, die der Websitebetreiber erhalten würde, damit er die Bedrohung schnell untersuchen und in Echtzeit mit verschiedenen Abwehroptionen unschädlich machen kann.
Fig. 18: Client-Side Protection & Compliance simulation alert after detecting the skimmer
Fazit
Diese Kampagne unterstreicht die Tatsache, dass sich Web-Skimming-Techniken ständig weiterentwickeln. Sie werden immer ausgefeilter, was die Erkennung und Abwehr durch statische Analysen und externe Scans immer schwieriger macht. Bedrohungsakteure in dieser Domain finden immer bessere Methoden, um ihre Angriffe auf den betroffenen Websites zu verbergen und verschiedene Sicherheitsmaßnahmen zu umgehen, die sie enttarnen könnten.
Die in dieser Studie aufgezeigte Komplexität sollte Unternehmen daran erinnern, wachsam und aufmerksam gegenüber Web-Skimming-Angriffsvektoren zu bleiben und aktiv nach neuen und fortschrittlichen Ansätzen zu suchen, um diese Art von Angriffen abzuwehren.
IOCs
Pmdresearch[.]com
secures-tool[.]com
adsometric[.]com
cngresearch[.]com
