In einem Vorfall, der an die Prinzipien moderner Supply-Chain-Angriffe rührt, wurde ein von Adform bereitgestelltes JavaScript so verändert, dass im Browser Krypto-Wallet-Adressen durch andere ersetzt werden konnten. Die Folge: Wer am 27. Juli 2026 eine betroffene Seite aufrief und eine Bitcoin-, Ethereum- oder Tron-Adresse kopierte oder in ein Formular eintrug, konnte unbemerkt eine fremde Adresse in den Zahlungsfluss übernehmen.
Adform hat den schädlichen Code entfernt, betroffene Kunden informiert und die Angelegenheit Behörden gemeldet. Gleichzeitig veröffentlichte das Unternehmen Hinweise, was Nutzer und Kunden jetzt konkret tun sollten.
Was genau passierte mit dem Adform-Skript?
Auslöser des Problems war eine Manipulation eines JavaScript-Files, das durch die Werbetechnologie-Plattform auf Kundenseiten ausgeliefert wurde. Der Angriff verwandelte die Datei trackpoint-async.js in eine browserseitige Komponente, die Wallet-Adressen umschrieb.
Wichtig: Adform beschreibt den Code als nicht darauf ausgelegt, zusätzliche Software zu installieren oder dauerhaft im System zu bleiben. Stattdessen lief die Manipulation nur in dem Moment, in dem die betroffene Seite geöffnet war. Dennoch konnte sie in dieser Zeit zuverlässig genau das Ziel treffen, das für Zahlungen entscheidend ist.
So konnten Angreifer Wallet-Adressen austauschen
Die Schadfunktion bestand aus zwei zusammenhängenden Blöcken, die an die legitime Bibliothek angehängt waren. Adform und die Sicherheitscommunity berichten, dass die Ersetzungsstrings verschleiert waren und durch einen XOR-Mechanismus entschlüsselt werden mussten. Zusätzlich soll das Verhalten eng an typische Nutzerinteraktionen gekoppelt gewesen sein.
1) Ersetzen beim Kopieren und beim Zahlungszeitpunkt
Ein Teil der Schadlogik reagierte auf Kopierereignisse. Dabei versuchte das Skript in kurzen Intervallen, Inhalte aus der Zwischenablage (Clipboard) auszulesen und erkannte darin Adressen, die zu Bitcoin-, Ethereum- oder Tron-Mustern passten. Sobald eine Übereinstimmung gefunden wurde, ersetzte das Skript die Zieladresse durch eine vorbereitete Ersatzadresse.
Außerdem gab es einen Mechanismus, der beim Laden der Seite eine HTTP-Anfrage an eine externe Adresse auslöste. Diese Anfrage enthielt Informationen wie Hostname und Pfad der gerade aufgerufenen Seite. Ob die Anfrage tatsächlich beim Betreiber ankam, blieb anhand des gesicherten Samples offen.
2) Ersetzen auch in Formularfeldern
Ein zweiter Block griff nicht nur auf Kopieren zu, sondern arbeitete direkt mit dem DOM der Seite. Er durchsuchte Textknoten und tauschte Werte in Eingabefeldern aus, etwa in input-Elementen, textarea-Feldern sowie in Bereichen mit contenteditable.
Damit reichte der Schutzhebel „Ich habe die Adresse manuell nicht kopiert“ nicht aus. Das Skript setzte zudem die Cursorposition nach dem Ersetzen wieder korrekt, was die Manipulation für Nutzer optisch weniger auffällig machen konnte.
Zusätzlich sollten Hook-Mechanismen dafür sorgen, dass sowohl Nutzer-Interaktionen als auch programmatische Wertzuweisungen in Eingabefelder unterwegs umgeschrieben wurden. Auch Ereignisse rund um copy, cut, paste und input wurden abgefangen.
Laut dem Sicherheitsforscher Kevin Beaumont wirkten die Ersatzadressen nicht zwingend identisch; die konkreten Zielmuster könnten dabei variiert haben.
Warum ist das eine klassische Supply-Chain-Falle?
Der Kern des Problems lag weniger in einzelnen Kundenseiten, sondern in einer gemeinsam genutzten Ressource. Adform zufolge kann sein Tracking-Code je nach Implementierung auf einer einzelnen Seite, in mehreren Bereichen oder sogar „unbedingt“ über eine gesamte Website laufen. Genau das macht gemeinsame Skript-Ressourcen attraktiv für Angreifer: Wird eine solche zentrale Datei kompromittiert, erhalten viele nachgelagerte Seiten einen Angriffsweg, ohne dass jede Seite separat angegriffen werden muss.
Adform charakterisiert das als Lieferkettenkompromittierung, weil das betroffene Skript auf einer shared deployment path beruhte. Die kompromittierte Datei wurde über ein Adform-Serving-Domain bereitgestellt.
Was sagt Adform zur Datenübertragung?
Adform erklärte, es gebe keine Hinweise, dass das manipulierte Skript IP-Adressen oder Informationen darüber übertragen habe, welche Websites Besucher aufgerufen hatten. Gleichzeitig merkte das Unternehmen an, dass die technische Analyse darauf schließen lasse, dass eine solche Übermittlung möglich gewesen sein könnte.
Diese Formulierung ist wichtig: Sie trennt zwischen „nicht nachgewiesen“ und „grundsätzlich nicht möglich“. Für Betroffene heißt das vor allem, dass das Risiko primär in der Zahlungsmanipulation lag – also in der Änderung von Adressen –, während der Umfang möglicher Telemetrie-Aktivitäten weiter unklar bleibt.
Welche Nutzer waren betroffen?
Adform verweist auf einen konkreten Zeitraum: Der 27. Juli 2026 wird als betroffener Tag genannt. Das bedeutet: Wer an diesem Tag Seiten besuchte, auf denen das manipulierte Skript ausgeliefert wurde, und eine passende Krypto-Adresse kopierte oder eintrug, konnte ungewollt eine andere Adresse in die Überweisung übernehmen.
Allerdings ist die öffentliche Zeitleiste bislang nicht vollständig geklärt. Kevin Beaumont, ein unabhängiger Sicherheitsforscher, berichtete, dass er über eine längere Beobachtungsphase bösartige Aktivität im Zusammenhang mit Adform über eine Woche hinweg gesehen habe. Der Abgleich zwischen dieser längeren Sichtung und Adforms betroffenem Datum ist damit noch offen.
Hinzu kommt: Adform hat öffentlich keine Indikatoren für Kompromittierung (IoCs) veröffentlicht und auch nicht beziffert, wie viele Webseiten tatsächlich das veränderte Skript erhielten oder wie viele Besucher exponiert waren.
Welche Auswirkungen sind denkbar?
Aus funktionaler Sicht reichte ein einziger erfolgreicher Ersatz zur Schadwirkung: Wenn während der offenen Seite im Zahlungsprozess genau eine Wallet-Adresse am Punkt der Überweisung ersetzt wurde, konnte eine Transferauslösung an eine fremde Zieladresse gehen.
Ob dabei tatsächlich Gelder abflossen, lässt sich aus den bislang öffentlich verfügbaren Informationen nicht sicher ableiten. Ein weiterer Engpass ist die Dauer: Ohne einen konsistenten Zeitpunkt für den Beginn und das Ende der Manipulation ist eine belastbare Expositionsschätzung schwer.
Beaumonts Hinweis lässt zudem vermuten, dass das Skript hartnäckig blieb, solange die betroffene Seite geöffnet war: Selbst wenn Nutzer bemerkten, dass die Adresse „falsch“ war und sie erneut kopierten, konnte das Skript sie weiter ersetzen.
Was sollten Betroffene jetzt tun?
Adform empfiehlt, den Browser-Cache zu leeren. Hintergrund ist, dass das veränderte Skript trotz Fix weiterhin im Cache eines Browsers verbleiben könnte. Wer danach noch einmal dieselben Seiten aufruft, könnte sonst erneut mit der manipulierten Version interagieren.
Darüber hinaus rät Adform, jede Wallet-Adresse vor einer Überweisung zu prüfen. Gerade weil die Ersetzung sowohl beim Kopieren als auch in Eingabefeldern passieren konnte, ist eine Sichtprüfung des Zieltexts vor dem Senden entscheidend.
Für Betreiber von Websites, die Adform-Tracking eingebunden haben, gilt zusätzlich: Prüfen Sie, ob das Skript heute wieder in einer sauberen Version geladen wird und ob Sie in Ihrer Implementierung Zwischenspeicherungen oder CDN-Caches nutzen, die den Austausch verzögern.
Warum der öffentliche Status noch unvollständig ist
Mehrere zentrale Fragen sind weiterhin nicht abschließend beantwortet:
- Wie viele Websites wurden mit der manipulierten Datei ausgeliefert?
- Wie viele Besucher waren in der relevanten Zeit tatsächlich exponiert?
- Wie kamen die Angreifer an die Bereitstellungspipeline von Adform?
- Wurde durch die Adress-Ersetzung nachweisbar Geld umgeleitet?
- Existieren veröffentlichte Indikatoren, anhand derer man gezielt nach Spuren suchen kann?
Beaumont berichtet außerdem, dass die zu diesem Zeitpunkt gefundene Fassung keine Erkennungen in VirusTotal ausgelöst habe. Das spricht dafür, dass die Schadlogik gezielt verschleiert war und eventuell erst durch bestimmte Ausführungsbedingungen sichtbar wurde.
Fazit: Vorsicht bei Krypto-Transaktionen und gemeinsamen Skripten
Der Vorfall zeigt, wie schnell kompromittierte JavaScript-Ressourcen in die Nähe sensibler Abläufe geraten können: Wenn Adform-Skript Krypto-Adressen durch manipulierte Browserlogik ersetzt, reicht schon ein einziger falscher Moment im Zahlungsprozess. Selbst Nutzer, die adressgenau vorgehen, können durch automatisierte Ersetzungen aus dem Takt geraten.
Leeren Sie deshalb Ihren Browser-Cache, kontrollieren Sie Wallet-Adressen vor jeder Überweisung und lassen Sie bei Website-Betreibern die Skript-Integration sowie Caching-Mechanismen überprüfen. Gleichzeitig bleibt die Sicherheitslage hinsichtlich Angriffsweg, Reichweite und eventueller finanzieller Auswirkungen weiter Gegenstand der laufenden Aufklärung.
Quelle: https://thehackernews.com/2026/08/hackers-poison-adform-script-to-swap.html
