Der Laptop war das Einfallstor

Am 30. Oktober meldete Binance einen „Sicherheitsvorfall“, der Vermögenswerte von rund 6,3 Milliarden Dollar betrifft. The Hacker News berichtet, dass Chainalysis den Diebstahl zum Tatzeitpunkt auf 5,912 Milliarden Dollar bezifferte, fast das Vierfache des bis dahin größten verzeichneten Krypto-Diebstahls. Fast 3 Milliarden Dollar wurden on-chain eingefroren, zum größten Teil Stablecoins, die Tether und Circle sperrten. Binance sagt, es werde alle Verluste ersetzen.

Binances Darstellung, wie alles begann, ist einen Satz lang. „Erste Untersuchungen deuten darauf hin, dass der Sicherheitsvorfall den kompromittierten Laptop eines DevOps-Ingenieurs betreffen könnte“, was einem Angreifer erlaubte, einen Service-Container zu erreichen und nicht autorisierte Auszahlungen einzureichen. Binance sagt, es habe keine Hinweise darauf gefunden, dass ein privater Wallet-Schlüssel abgeflossen sei. Wie der Laptop kompromittiert wurde, hat es nicht gesagt.

Fünfzig Signaturen und drei Minuten

Die On-Chain-Daten zeigen, was dieser Zugang wert war. Um 20:20 UTC reichte der Angreifer eine Transaktion mit 50 Autorisierungen ein, jede von Binances Hot Wallet signiert, eine für jede von 50 aufeinanderfolgenden Transaktionsnummern, damit eine davon zur nächsten der Wallet passte. Jede verwies auf einen Sweeper-Vertrag, der nur Befehle des Angreifers annimmt. Eine passte. Etwa drei Minuten und 24 Sekunden später schickte die Hot Wallet ihr gesamtes Guthaben an den Angreifer: 167.464 ETH und 63 Token, darunter 1,615 Milliarden USDT.

Blockaid-Chef Ido Ben-Natan sagte Cointelegraph, die ersten Hinweise deuteten auf „Schlüsselmissbrauch“: Das Signiersystem wurde dazu gebracht, die Transaktionen des Angreifers zu signieren, und kein Schlüssel musste gestohlen werden. Die Schlüssel blieben, wo sie waren. Jemand mit dem Zugang des Ingenieurs bat das System, sie zu benutzen.

TRM Labs schreibt den Angriff „mit hoher Sicherheit“ TraderTraitor zu, der nordkoreanischen Gruppe, die das FBI für den Diebstahl von 1,5 Milliarden Dollar bei Bybit im Februar 2025 verantwortlich machte. Auch Chainalysis verweist auf Nordkorea. Binance hat niemanden genannt.

Wie diese Gruppe auf Laptops gelangt

Der am besten dokumentierte Einbruch von TraderTraitor zeigt die Methode. Im Fall Bybit beschreiben der vorläufige Bericht von Safe selbst und die Erkenntnisse von Mandiant ihn der Reihe nach:

1. Am 4. Februar 2025 führte ein Entwickler von Safe auf seinem Mac ein Docker-Projekt namens MC-Based-Stock-Invest-Simulator-main aus. Mandiant geht davon aus, dass der Entwickler dazu überredet wurde.
2. Das Projekt rief getstockprice[.]com auf, eine zwei Tage zuvor registrierte Domain, und die macOS-Workstation des Entwicklers wurde kompromittiert.
3. Die Angreifer nahmen die AWS-Session-Tokens des Entwicklers, mit denen sie dessen AWS-Zugang ohne Multi-Faktor-Authentifizierung nutzen konnten.
4. Mit diesem Zugang veränderten sie die Safe-Oberfläche, die Bybits Unterzeichner benutzten, und die Unterzeichner genehmigten eine Transaktion, die eine Cold Wallet leerte.

Mandiant stellte fest, dass die Gruppe bei früheren Raubzügen ähnliche Docker-Projekte rund um Aktien eingesetzt hatte. Die Methode ändert sich nicht: einem Entwickler ein Projekt geben, es unter seiner Identität laufen lassen und nehmen, was sein Rechner erreicht. Ein DevOps-Laptop erreicht viel. Meist liegen darauf ~/.aws mit gültigen Session-Tokens, eine ~/.kube/config für Produktionscluster, SSH-Schlüssel für den Bastion-Host und ein gh-Login, alles lesbar für jeden Prozess, den der Ingenieur startet.

Das Projekt führt jetzt der Agent aus

Der Köder brauchte früher einen Entwickler, den man zum Ausführen von etwas überreden konnte. Dieser Schritt lässt sich immer leichter überspringen. Am selben Tag, an dem Binance den Einbruch meldete, berichtete BleepingComputer über die Analyse von Air Security zu einem GitHub-Repository namens SolanaUpdateTools/solana-starter-kit. Es hat 286 Sterne und steht laut Air an erster Stelle, wenn KI-Coding-Agenten nach einem Solana-Starter-Kit suchen. Die README ist die einzige Datei darin. Sie verspricht eine vollständige App-Vorlage und nennt einen einzigen Installationsschritt: einen Befehl einfügen, der aus Fragmenten eine URL auf developer-update[.]app zusammensetzt, ein Skript herunterlädt und es im Speicher ausführt.

Die Payload, die Air sicherstellte, installiert NetSupport Manager, ein legitimes Fernzugriffswerkzeug, das sich bei jeder Anmeldung mit dem Angreifer verbindet. Dann gibt sie eine falsche Fehlermeldung aus: Die Entwicklerfunktionen seien „wegen Überlastung vorübergehend ausgesetzt“, man solle es in 72 Stunden erneut versuchen. Ein Agent, der der README folgt, würde den Befehl ausführen und einen ausgelasteten Server melden. Der Entwickler sähe nichts, was einen zweiten Blick verdient.

Setzt man diesen Agenten auf den Laptop eines DevOps-Ingenieurs, mit dessen kubeconfig und AWS-Session im selben Home-Verzeichnis, wird das Starter-Kit zum Docker-Projekt aus dem Fall Bybit, nur ohne Social Engineering.

Dasselbe Projekt in Bromure Agentic Coding

Bromure Agentic Coding betreibt Claude Code, Codex, Grok, Kimi und omp in Ubuntu-VMs auf Ihrem Mac. Jede Maschine ist eine eigene VM, und alles, was der Agent anfasst, liegt darin: geklonte Repositories, Paket-Caches, Docker-Container und jeder Befehl, den eine README vorschlägt. Ihr Mac hält die echten Zugangsdaten, den Proxy, über den der Datenverkehr der VM läuft, und das Protokoll dessen, was geschah.

Das Projekt läuft in der VM, nicht als Sie

Führen Sie das Docker-Projekt des Börsensimulators in einer Bromure-Maschine aus, oder lassen Sie den Agenten den Befehl des Starter-Kits einfügen. Der Container startet in der VM, und die Payload ebenso. Sie bekommt eine Shell in einem Ubuntu-Gast, als Benutzer der Maschine. Sie bekommt weder Ihr macOS-Konto noch Ihren Schlüsselbund. Die ~/.aws, ~/.kube und ~/.ssh Ihres Macs sind auch nicht da: Bromure liest diese Dateien auf dem Host, wenn Sie sie importieren, und bindet sie nie in eine VM ein.

Die Schlüssel, die sie findet, sind Platzhalter

Als Nächstes sucht die Payload nach Zugangsdaten, und die VM hat viele, die echt aussehen. Keine davon funktioniert anderswo.

• AWS. ~/.aws/config verweist auf ein Hilfsprogramm, das die echte Access-Key-ID mit einem falschen Secret Key ausgibt, und gar kein Session-Token. Die VM signiert jede Anfrage mit dem falschen Secret, und der Mac signiert sie auf dem Weg zu *.amazonaws.com mit dem echten neu. Kopieren Sie die AWS-Zugangsdaten der VM auf einen anderen Rechner, und jeder Aufruf scheitert mit InvalidSignatureException. Das Session-Token, das die Bybit-Angreifer an sich nahmen, existiert in der VM in keiner Form.
• Kubernetes. Die ~/.kube/config der VM ist synthetisch. kubectl spricht mit dem Proxy von Bromure, nie direkt mit dem API-Server. Ein Bearer Token ist ein brm-k8s-…-Platzhalter, ein Client-Zertifikat ein Wegwerf-Zertifikat, und ein Exec-Plugin wie aws eks get-token läuft auf dem Mac statt in der VM.
• SSH. Der SSH_AUTH_SOCK der VM ist eine Brücke zum Mac. Der Gast kann um eine Signatur bitten, und der private Schlüssel verlässt den Host nie. ls ~/.ssh/id_* findet nichts zum Kopieren. Der eigene ssh-agent Ihres Macs wird keiner VM zugänglich gemacht.
• Git. Das GitHub-Token in gh und ~/.git-credentials ist ein Platzhalter, den der Proxy nur bei Anfragen an github.com gegen das echte austauscht.

Die Platzhalter sind zugleich Stolperdrähte. Schickt die Payload einen davon an ihren eigenen Server, blockiert der Proxy die Anfrage mit HTTP 451, bevor ein Byte Ihren Mac verlässt, pausiert die VM und zeigt This environment may have been compromised an, samt dem betroffenen Zugangsdatum und dem Host, an den es gehen sollte. Die Maschine startet erst wieder, wenn ihre Festplatte und ihr Home-Verzeichnis gelöscht sind. Ihre Einstellungen und Schlüssel bleiben erhalten.

Die Produktionsschlüssel hören auf Sie

Platzhalter erledigen den Diebstahl. Der Fall Binance fügt ein zweites Risiko hinzu: einen Angreifer, der den Zugang gar nicht stiehlt, sondern ihn dort nutzt, wo er bereits funktioniert. Eine Payload in der VM kann Anfragen über den Proxy schicken, wie es der Agent tut. Die Guardrails von Bromure entscheiden, was diese Anfragen dürfen, und sie werden auf dem Mac durchgesetzt, wo nichts in der VM sie ändern kann.

• Require approval to use, pro Zugangsdatum eingestellt: Wenn ein Kubernetes-Kontext, ein AWS-Schlüssel oder ein SSH-Schlüssel in einer Sitzung zum ersten Mal benutzt wird, hält der Proxy die Anfrage an und fragt auf Ihrem Mac nach. Sie wählen 5 Minuten, eine Stunde oder die Sitzung, oder Don't allow. Bei AWS gilt die Prüfung für jeden Signieraufruf. Eine Payload, die nach dem Produktionscluster greift, bevor Sie zugestimmt haben, öffnet einen Dialog auf Ihrem Bildschirm und bekommt nichts, bis jemand ihn beantwortet.
• Schreibrichtlinie, pro Dienst eingestellt. Neue Maschinen starten mit Prompt before write für Kubernetes, AWS, Container-Registries, Git-Forges und Datenbanken: Lesezugriffe gehen durch, und jeder Schreibzugriff hält an einem Dialog, der die genaue Operation zeigt. Block destructive verweigert Löschungen und Terminierungen, und Read-only verweigert jede Änderung. Eine Maschine, die nur Logs aus der Produktion lesen muss, lässt sich auf schreibgeschützt stellen, und nichts, was darin läuft, kann die Produktion verändern.
• Outbound connections, die Firewall jeder Maschine. Stellen Sie Unmatched traffic auf Deny und erlauben Sie nur die Hosts, die das Projekt braucht. Der Download des Starter-Kits von developer-update[.]app, der Aufruf des Bybit-Projekts an getstockprice[.]com und die Verbindung von NetSupport nach Hause fallen alle unter die Standardregel und werden abgewiesen.

Jede Nutzung von Zugangsdaten, jede Signatur, jede Sperre und jede Freigabe landet in der Security Timeline der Maschine, AWS-Signieraufrufe und SSH-Signaturen einzeln erfasst. Binance rekonstruiert jetzt einen Angriffsweg über einen „kompromittierten Computer“. In Bromure liegt die Aufzeichnung dessen, was die VM mit Ihren Zugangsdaten getan hat, auf dem Mac, außerhalb der VM, die der Angreifer kontrollierte.

Das Starter-Kit von der Produktion fernhalten

Bromure-Maschinen sind schnell angelegt, also lässt sich der Zugang auf mehrere verteilen. Zugangsdaten werden pro Maschine konfiguriert. Geben Sie der Maschine, die ein neues Starter-Kit, eine Probeaufgabe aus einem Bewerbungsverfahren oder das Repository eines Fremden ausprobiert, überhaupt keine Produktionszugänge und eine Firewall, die standardmäßig ablehnt. Behalten Sie die kubeconfig und die AWS-Rolle auf der Maschine, die die Deployment-Arbeit erledigt, jeweils mit Freigabepflicht. Für etwas, das Sie lieber nicht behalten wollen, erzeugt bromure-cli vm run --rm eine Maschine, die beim Beenden gelöscht wird.

Die Payload kann dann die VM des Starter-Kits übernehmen und findet darin nichts, was sich lohnt: keine echten Geheimnisse, keinen Cluster und keinen Weg zu einem Host, den Sie nicht erlaubt haben. Die Deployment-Maschine hat ihren Code nie ausgeführt.

Zweimal zusehen

Unsere Tutorial-Serie A Tale of Two Agents ist von diesem Angriff inspiriert. Theo, DevOps-Engineer bei Coinvance, einer erfundenen Börse, lässt seinen Coding-Agenten die Probeaufgabe eines Recruiters fertigstellen, und das README weist den Agenten an, zuerst ein Setup-Skript auszuführen. Derselbe Fehler läuft zweimal auf geteiltem Bildschirm ab: links läuft der Agent auf seinem Laptop, rechts in Bromure.

1. Die Probeaufgabe (1:24). Auf dem Laptop schickt das Skript seine echten Cloud-Schlüssel, seine kubeconfig und sein Deploy-Token als „Telemetrie“ hinaus. In Bromure findet es nur Platzhalter, und als die an den falschen Host gehen, pausiert Bromure die VM und fragt ihn.
2. Lateral (1:18). Jemand patcht den Auszahlungsdienst mit Theos Kubernetes-Zugang. Rechts verfolgt die Security Timeline die blockierte Anfrage bis zur Begründung des Agenten zurück, und der Workspace ist mit einem Klick gelöscht.
3. Zwanzig Minuten (1:02). Links leeren sich die Hot Wallets. Rechts gibt es keine Schlüssel zu rotieren.

Theo und Coinvance sind erfunden, und die Episoden zeigen nicht, was bei Binance geschah. Jede ist in acht Sprachen erzählt.

Der Rechner des Entwicklers gehört zur Produktion

Binances Auszahlungsdienst ist für eine „Sicherheitsüberarbeitung“ abgeschaltet und soll innerhalb von 48 Stunden zurückkehren, und die vollständige Analyse wird mehr darüber sagen, wie der Laptop erreicht wurde. Bybit hat das Muster allen anderen bereits gezeigt. Angreifer, die es auf die Produktionssysteme eines Unternehmens abgesehen haben, gehen auf die Rechner der Ingenieure los, die sie betreiben, und auf den meisten dieser Rechner steckt der Produktionszugang in ein paar Dateien im Home-Verzeichnis.

Ihr Coding-Agent vergrößert diese Öffnung. Er klont, installiert und führt Code von Fremden aus, Aufgabe um Aufgabe, und er fügt den Befehl aus einer README schneller ein als Sie. In Bromure Agentic Coding läuft der Code in einer VM, die nur Platzhalter enthält, und der Zugang zur Produktion bleibt auf dem Mac, hinter einem Dialog, den Sie beantworten müssen.

Über eine Token-Diebstahl-Kampagne, die gar keinen Angreifer-Server brauchte, lesen Sie Das gestohlene Token brauchte keinen Server. Über einen Agenten, der seine Befehle aus einer heruntergeladenen Datei bekam, lesen Sie Der Download gab die Befehle.