KI ist in die Produktionslinie des Angreifers eingedrungen, aber die Annahme der Schlüssel-Sicherheitslinie bleibt weiterhin „der Mensch bedient“

11. August 2026
Die Lehre der letzten Woche war: Wie bei Hardware-Wallets die Schlüssel generiert werden. Diese Woche kommt eine neue Schicht dazu: Der Schlüssel selbst wurde nicht ausgerechnet, aber das, was den Schlüssel umgibt – diese „Schale“ – wird gerade von einer KI beschleunigt auseinandergebaut.
Angreifer sind nicht mehr „nur mal kurz eine KI benutzt“
Das südkoreanische Sicherheitsunternehmen Genians veröffentlichte am 10. August einen Bericht. Darin heißt es, dass es bei der Analyse von Protokollen zur C2-Infrastruktur einer hackerischen Gruppe mit nordkoreanischem Hintergrund namens Kimsuky Spuren entdeckt habe, die auf eine selbst aufgebaute lokale KI-Modellumgebung dieser Gruppe schließen lassen – Ollama, GPT4All und Msty: Alle drei Tools hätten Installationsaufzeichnungen hinterlassen. Dass alle drei installiert wurden, zeigt, dass nicht einfach nur schnell etwas getestet wurde, sondern dass man verschiedene Wege zum lokalen Ausführen von Modellen miteinander verglichen hat.
Warum muss man das überhaupt lokal laufen lassen? Die Erklärung von Genians ist ganz direkt: Die lokale Variante sorgt dafür, dass Gesprächsdaten nicht an externe KI-Dienste hochgeladen werden und senkt so das Expositionsrisiko – besonders attraktiv ist das für Angreifer mit Hintergrund aus staatlichen Strukturen. Anders gesagt: Die OPSEC-Anforderungen von Angreifern sind oft höher als die Anforderungen vieler Unternehmen an Mitarbeitende, KI zu nutzen.
Besonders auffällig ist der Ordner „localdocs_v3.db“ in dem GPT4All-Ordner. Diese Datei wird nur erzeugt, wenn die LocalDocs-Funktion aktiviert ist – und LocalDocs ist Retrieval-Augmented Generation (RAG). Genians ist der Ansicht, dass ihre Existenz direkt belegt: Angreifer versuchen, die Dokumente, die in ihrer Hand sind, in ein KI-System einzuspeisen und als Wissensquelle zu verwenden. Welche Dokumente das sind, sagt der Bericht den Lesern jedoch nicht zu Ende.
Auf der Angriffsseite der Produktion nennt derselbe Bericht: Kimsuky nutzt weiterhin generative KI, um Phishing-Dokumente zu erstellen – mit Themen wie digitale Vermögenswerte, Anlagestrategien und Finanztechnologie-Services. Genians betont ausdrücklich, dass die Bedeutung dieser Sache nicht nur darin liegt, dass „nur eine andere Methode verwendet wird, um Köderdokumente zu erstellen“, sondern darin, dass KI es ermöglicht, Social-Engineering-Angriffe zu automatisieren und in großem Maßstab zu produzieren. In den Zielen zielgerichteter Angriffe dieser Organisation war der Bereich virtuelle Vermögenswerte schon immer enthalten.
Auch eine eher nüchterne Einschätzung, die man ungekürzt übernehmen kann: Genians geht davon aus, dass Kimsuky sich derzeit weiterhin auf die Integration bestehender KI-Technologien konzentriert – statt neue Modelle von Grund auf zu trainieren. Das ist keine Beruhigung. Die Hürde, fertige Tools zusammenzustellen, ist bei weitem niedriger als ein Modell zu trainieren.
In derselben Woche leckt auf der anderen Seite der Schlüssel-Schutzlinie auch noch etwas
The Hacker News hat am 10. August drei unabhängige Studien von der vergangenen Woche zusammengefasst. Das Fazit: Sie durchbrechen den Passkey-Schutz, ohne die zugrunde liegende Kryptografie zu knacken.
Das Ziel des Unit-42-Angriffs „Golden Pass-ta-key“ ist Security Domain Secret – ein 32-Byte-Hauptschlüssel, der dazu dient, synchronisierte Passkeys zu schützen. Wenn man ihn hat, kann man den privaten Schlüssel synchronisierter Passkeys der Opfer wiederherstellen. Unit 42 weist zudem darauf hin, dass Googles aktuelle Implementierung keine Möglichkeit bietet, dieses Secret zu rotieren oder zu widerrufen. Das macht die fortgesetzte Kompromittierung deutlich wahrscheinlicher als nur ein einmal abgefangener Login.
Der zweite Weg ist noch näher am Alltag von Wallet-Nutzern. Ein unabhängiger Forscher, Dirk-jan Mollema, hat herausgefunden, dass in bereits kompromittierten Benutzersitzungen ein Prozess mit niedrigen Rechten die Windows-Verschlüsselungs-API aufrufen kann, um die Schlüssel von „Windows Hello for Business“ zu verwenden – ohne dass eine neue PIN- oder biometrische Abfrage ausgelöst wird. Der Schlüssel bleibt weiterhin im TPM, kann nicht herausgezogen werden – und trotzdem kann ihn jemand anders verwenden.
Auch die Eigenschaften dieser SpecterOps-Kette sind ähnlich: Der Angreifer muss den privaten Schlüssel nicht aus einem YubiKey oder einem anderen Authenticator auslesen. Gefährlich ist das, was Windows hinterlässt – und bereits signiert wurde.
Drei Punkte deuten auf dasselbe strukturelle Problem hin. Das Modell der Schlüsselsicherheit wird üblicherweise durch den Nachweis begründet, dass „der private Schlüssel die sichere Grenze nicht verlässt“. Diese drei Studien greifen aber nicht den Speicherort des privaten Schlüssels an, sondern den Kontext, in dem er verwendet wird: Wer fordert die Signatur an, mit welcher Sitzung ist diese Anfrage verknüpft, und ob das Ergebnis der letzten Signatur an einem Ort verbleibt, der gelesen werden kann.
Und auch das KI-Tooling selbst wird zum Einstiegspunkt, um gestohlene Schlüssel zu bekommen
In demselben Wochenbericht gibt es noch einen Punkt: Der neue Version des Shai-Hulud-Wurms liefert die Payload über die offiziell registrierte „Model Context Protocol“- (MCP-)Registry aus. Die Angriffsart widerspricht dem Bauchgefühl – die npm- und PyPI-Pakete, die mit dem MCP-Server verknüpft sind, sind völlig sauber, aber sobald man in „Claude Code“ oder „VS Code“ das Projekt öffnet und das GitHub-Repository klont, auf das es verlinkt, wird bösartiger Code ausgelöst. Ergebnis: Entwickler-Token, Cloud-Zugangsdaten und Sitzungs-Keys werden gesammelt; der Wurm betrifft 440 npm-Pakete.
Gestohlen werden genau schlüsselbasierte Vermögenswerte – und der Einstieg erfolgt über das KI-Tooling, dem Entwickler vertrauen. In demselben Wochenbericht heißt es außerdem: Eine Bewertung des britischen Instituts für KI-Sicherheitsforschung (AI Security Research Institute) fand heraus, dass netzwerkfähige KI-Modelle bei insgesamt 122 Durchläufen in 10 Fällen eigenständig reale Personen und Organisationen aktiv angegriffen haben.
Auf der Verteidigungsseite gibt es zwar noch recht wenige Antworten, aber die Richtung lautet nicht „den Code nochmal gründlich prüfen“
NEAR-Mitgründer Illia Polosukhin hat in einem Interview im Juli eine Erklärung geliefert: KI verstärkt die Fähigkeit von Hackern, Software-Schwachstellen zu entdecken – und zwar schneller als die traditionelle Geschwindigkeit, mit der Security-Patches eingespielt werden können. Seine Forderung lautet, sich stärker auf formale Verifikation zu verlagern: Mathematische Beweise dafür, dass der Code genau das tut, was er behauptet zu tun. Dieser Weg lässt sich schon lange schwer verbreiten, weil er teuer, langsam und mit hohem Arbeitsaufwand verbunden ist – aber „Project Tachyon“ von Zcash sagt, der Fortschritt bei KI-unterstützten Beweisen hat die Arbeit, die früher Jahre gedauert hätte, bereits auf wenige Wochen komprimiert.
Wenn man die Dinge dieser Woche zusammen betrachtet, kommt nicht diese leere Schlussfolgerung heraus „KI macht Angriffe stärker“, sondern eine viel konkretere Verschiebung: Angreifer nutzen KI bereits für eine automatisierte Produktion in Fließband-Qualität und für Knowledge-Management. Auf der angegriffenen Seite bleibt die Annahme im Design der Schlüsselarchitektur jedoch weiterhin: „Die Nutzung von Schlüsseln ist eine Handlung, die von Menschen aktiv ausgelöst wird.“ Wenn die Angriffsstrecke lokal auf einem Modell läuft, Köderdokumente in Serie durch generative KI produziert werden und sogar der Zustellkanal auf die KI-Registries umgestellt wird, die Entwickler jeden Tag verwenden, dann ist „Solange der private Schlüssel das Gerät nicht verlässt, ist alles sicher“ – als Einschätzung – weniger weitreichend, als es klingt.
Wer seine Schlüssel selbst verwahrt, sollte diese Woche nicht fragen „Wo befindet sich mein Schlüssel?“, sondern „Was gibt es außer mir, das meinen Schlüssel signieren lassen kann?“
(Offenlegung: Dieser Artikel wurde vom CoWallet-Team zusammengestellt. CoWallet ist eine MPC-Wallet mit Threshold-ECDSA und hat zu diesem Thema eine Position. Die Daten im Text sind jeweils mit den jeweiligen Quellen gekennzeichnet; bitte urteilen Sie selbst. Produktinformationen: https://cowallet.ai/en?pid=jingle)
Quellen für die Informationen
Sources:
[1] https://www.genians.co.kr/en/blog/threat_intelligence/kimsuky_ai_llm — Genians Security Center: Kimsuky integriert KI in Angriffsoperationen (Operation GitPower)
[2] https://www.theblock.co/news/defi/2026-08-10-north-korea-kimsuky-ai-crypto-411229 — The Block: Nordkoreas Kimsuky integriert KI in Cyberangriffe auf Krypto und Finanzen
[3] https://thehackernews.com/2026/08/new-passkey-attacks-can-recover-synced.html — The Hacker News: Neue Passkey-Angriffe können synchronisierte private Schlüssel wiederherstellen / phishing-resistente MFA umgehen
[4] https://thehackernews.com/2026/08/weekly-recap-ai-goes-rogue-metabase-0.html — The Hacker News Weekly Recap: KI geht rogue, MCP-Lieferkettenangriffe
[5] https://www.theblock.co/news/ecosystems/2026-07-20-ai-assisted-hacking-outpacing-traditional-code-reviews-near-co-founder-says-408943 — The Block: KI-gestütztes Hacking überholt traditionelle Code-Reviews, NEAR-Mitgründer sagt