Wie ein Fake-Interview den Weg zu Binance öffnete

Wie sich der Angriff entwickelte

Bemerkenswert ist hier nicht das Phishing selbst, sondern wie ein gewöhnlicher Einstellungsprozess zu einer Kompromittierungskette wurde. In seinem Beitrag auf X beschrieb Binance ein mehrstufiges Vorgehen: Ein Ingenieur wurde über eine seriöse Jobplattform angesprochen, Vertrauen durch glaubwürdige Interviews und Profile aufgebaut und anschließend zum Download einer Codeaufgabe mit verschleierter Malware aufgefordert.

Zum Zeitpunkt der Veröffentlichung brachte Binance die weitere Entwicklung des Angriffs mit der Arbeitsumgebung in Verbindung. Der kompromittierte Laptop und ein internes KI-Tool wurden genutzt, um die Laptops von zwei weiteren Ingenieuren zu erreichen. Das ist ein wichtiges Detail: Der Angreifer bewegte sich nicht über einen exotischen Exploit weiter, sondern über vertraute Nutzer- und Entwicklerwege.

Danach tauchen ein Container-Deployment-Token, die Anmeldung an einem weiteren Engineering-Rechner und die Ausführung eines bösartigen Skripts auf. Anschließend wurde ein interner Signaturdienst eingesetzt, während der Ethereum-Mechanismus EIP-7702 einem kontrollierten Vertrag teilweise Befugnisse über ein Hot Wallet gab.

Aus Engineering-Sicht versagten mehrere Vertrauensgrenzen gleichzeitig. Auf dem Laptop konnte fremder Code ausgeführt werden, ein Deployment-Geheimnis war vom Endgerät aus verfügbar und ein kritischer Dienst akzeptierte Aktionen aus einer bereits kompromittierten Kette. Ein bloßes Verbot der App-Installation hätte das nicht verhindert.

Warum MDM allein nicht genügt

Im November 2026 ist die Schlussfolgerung einfach: MDM wird gebraucht, rettet aber nicht im Alleingang. Jamf kann Konfigurationen erzwingen, Software einschränken, dauerhafte Administratorrechte entfernen, Schutzagenten ausrollen und Remote-Reaktionen ermöglichen. Ein Terminal zu verbieten reicht jedoch nicht aus: Dieselbe Aktion kann über eine andere Binärdatei oder ein vertrauenswürdiges Tool ausgelöst werden.

Wirksame Erkennung basiert auf Verhalten. EDR muss Prozessbäume, Befehle, Dateiänderungen, Netzwerkverkehr und Token-Zugriffe sehen; SIEM muss dies mit Identitäts-, Repository-, Containerplattform- und Signaturdienst-Logs verknüpfen. Ein neues Repository, eine verschleierte Shell, das Lesen eines Tokens und ein ungewöhnliches Deployment wirken zusammen bereits wie ein Incident, nicht wie Rauschen.

Als Erstes würde ich die Secret-Architektur prüfen: Warum lag das Token auf einer Arbeitsmaschine, wie eng waren seine Rechte begrenzt und konnten sie schnell widerrufen werden? Ein ML-Modell kann bei seltenen Befehlsfolgen helfen, doch Regeln für Credential-Diebstahl und nicht autorisierte Deployments müssen sofort blockieren. Die unbequemste Erkenntnis: Gültiger Zugriff macht einen vertrauenswürdigen Ingenieur zum Teil des angreifbaren Perimeters, selbst wenn alle Agenten installiert sind.

Wir haben bereits erläutert, wie Unicode-Homoglyphen bösartige URLs und Befehle verschleiern können, um KI-Agenten zu täuschen. Dieselben Social-Engineering-Techniken hinter gefälschten Bewerbungsgesprächen zeigen, warum Teams Links, Identitäten und Ausführungsanfragen prüfen müssen.