SConnect funktioniert wie andere Authentifizierungs-Middleware: Eine schlanke Browser-Erweiterung arbeitet mit einem nativen Desktop-Programm zusammen. Nutzer rufen eine eingebundene Webseite auf, stecken ihren Hardware-Token in den Rechner oder ein angeschlossenes Lesegerät, und die beiden Komponenten vermitteln die Kommunikation. Am Ende soll feststehen, dass sowohl Webseite als auch Token vertrauenswürdig und autorisiert sind.
Genau an dieser Stelle liegen laut Bay Area Labs zwei Fehler. Zum einen nahm die Erweiterung Nachrichten von jeder beliebigen Webseite oder eingebetteten iframe entgegen – ob es sich dabei um das SWIFT-System oder eine beliebige Angreiferdomain handelte, spielte keine Rolle. Jeder Angreifer konnte sich also in einen Authentifizierungsvorgang einklinken, sofern er ein Opfer auf die passende Seite lotste.
Zum anderen scheiterte die Autorisierungsprüfung selbst. SConnect verifizierte eine RSA-Signatur des Herstellers Thales und reservierte dafür einen Puffer für das Rechenergebnis. Die Prüfung hatten die Entwickler nach Einschätzung der Forscher selbst gebaut – ohne etablierte Bibliothek. Lieferte ein Angreifer eine ungültige, übergroße Signatur, schlug die Berechnung fehl, ohne etwas in den reservierten Speicher zu schreiben. Die Software prüfte nicht, ob die Berechnung überhaupt erfolgreich war, las den veralteten Pufferinhalt aber trotzdem aus.
Wer diesen Speicher zuvor per Heap-Spraying mit passend konstruierten Bytemustern füllte, konnte das Ergebnis einer gültigen Signatur vortäuschen. Bay Area Labs gelang das mit Unterstützung von KI-Agenten in etwa 18 Prozent der Versuche – fehlgeschlagene Anläufe erzeugten keinerlei sichtbare Fehlermeldung, die Nutzer gewarnt hätte.
„Letztlich haben sie eine kryptografische Prüfung implementiert, und zwar selbst", sagt James Arnott, Gründer von Bay Area Labs. „Sie haben keine Bibliothek verwendet – und es vermasselt." Im Ergebnis konnten bösartige Webseiten die Sicherheitsprüfung passieren und über den nativen Host eine Schad-DLL laden, was uneingeschränkte Codeausführung bedeutet. „Man besucht eine Seite mit einem bösartigen iframe, und schon ist man infiziert. Ehrlich gesagt kann man von da an so ziemlich alles machen", so Arnott.
Trivial sei der Angriff nicht, räumt er ein – ohne KI-Werkzeuge wäre dafür Aufwand auf Nationalstaatsniveau nötig gewesen. Bei der Entwicklung des Exploits habe er stark auf Agenten gesetzt, die mit Ghidra den nativen Host dekompilierten und mit Frida den Speicher analysierten, um erfolgversprechende Heap-Spray-Muster zu finden.
Für den Zugang zu SWIFT benötigen Beschäftigte mit weitreichenden Rechten einen „3SKey", einen USB-Sicherheitstoken. Jahrelang war SConnect die Standardsoftware, die diese Token mit dem System verband. Im September 2025 führte die SWIFT-Genossenschaft mit „Web Connect" einen Nachfolger ein und drängt ihre Firmenkunden seither zum Wechsel. SConnect hat seit dem vergangenen Monat das Ende seines Lebenszyklus erreicht – umgestiegen sind damit längst nicht alle. „Ich vermute, die meisten SWIFT-Nutzer haben es noch installiert, weil SConnect der Rückfallweg ist, wenn Web Connect noch nicht eingerichtet ist", sagt Arnott. Die tatsächliche Reichweite sei schwer einzuschätzen, da die Bankenbranche Details ihrer Sicherheitspraktiken zurückhalte.
Die Tests der Forscher waren begrenzt, weil sie weder einen 3SKey noch Token für andere Systeme wie Katars Identitätsportal erhalten konnten. Arnott hält Szenarien jenseits der reinen Codeausführung für denkbar: etwa das Weiterleiten von Challenges, um die Identitätskarte eines Nutzers Dokumente signieren zu lassen und anschließend dessen Sitzung zu übernehmen. „Sobald man Codeausführung in einem Bankensystem hat, könnte es recht einfach sein, sich umzusehen, herauszufinden, auf wessen Rechner man sitzt, und Geld zu überweisen", sagt er. „Ich kann es nur nicht beweisen, weil mir wenig überraschend niemand einen 3SKey schickt." Thales hat auf eine Anfrage von Dark Reading bislang nicht reagiert.