Zum Inhalt springen
Beveiligingsnieuws

Offline-KI bei Kimsuky: RAG & Tools für Malware

offline AI-stack

Staatliche Hackergruppen verlassen sich zunehmend nicht mehr nur auf klassische Trickserien, sondern rüsten ihre Abläufe mit KI-Unterstützung auf. Ein neuer Befund zeigt, dass Offline-KI bei Kimsuky eine Rolle spielt: Die Gruppe betreibt offenbar lokale Sprachmodell-Umgebungen, koppelt sie mit einem Dokumenten-Index und nutzt zusätzliche Werkzeuge, um Phishing-Angriffe effizienter zu planen und nachgelagerte Schritte rund um Malware teilweise zu automatisieren.

Nach Recherchen einer südkoreanischen Sicherheitsfirma entstand die Einrichtung im Umfeld der bekannten Kimsuky-Strukturen. Die Hinweise basieren auf mehrmonatiger Überwachung sowie Auswertungen von Logdaten. Auffällig ist dabei vor allem die Zielrichtung: Es geht nicht nur um das Erstellen von Texten mit einem Chatbot, sondern um eine KI, die direkt im eigenen Betriebssystem- und Infrastrukturkontext arbeitet.

Von Chatbots zu eigenen Servern: Warum Offline-KI ein Vorteil ist

Bisherige KI-Nutzung in Angriffen wird häufig als „Prompt-and-go“ beschrieben: Angreifer geben Anweisungen in öffentliche Dienste ein und erhalten daraus schnell Text oder andere Ausgaben. Offline-KI bei Kimsuky verschiebt den Schwerpunkt. Wenn Sprachmodelle, Dokumentensuche und weitere KI-Bausteine lokal laufen, bleibt der Prozess stärker unter Kontrolle des Angreifers.

Im Bericht wird betont, dass die beobachteten Komponenten nicht den Eindruck erwecken, als hätte die Gruppe eigens ein neues Modell trainiert. Stattdessen wirkt es wie eine „Forschungs- und Wissensakquise“-Phase: vorhandene Tools werden zusammengestellt, getestet und so in die Operation integriert, dass sie an mehreren Stellen des Angriffspfads unterstützen können.

Lokale Sprachmodelle und RAG: Dokumente werden zur Wissensbasis

Das Herzstück der beobachteten lokalen KI-Landschaft sind Tools, mit denen sich Sprachmodelle offline betreiben lassen. Genannt werden Ollama, GPT4All und Msty. Laut den Forschern wurden diese nicht nur „heruntergeladen“, sondern offenbar tatsächlich gestartet oder konfiguriert.

Ein besonders starkes Indiz liefert dabei die RAG-Funktionalität (Retrieval-Augmented Generation). Bei RAG wird eine KI-Ausgabe nicht ausschließlich aus dem Modellgedächtnis erzeugt, sondern zusätzlich aus einer privaten Dokumentensammlung gespeist. Für GPT4All wurde ein lokal konfigurierter Datenbestand (localdocs_v3.db) gefunden, der für die LocalDocs-RAG-Funktion vorgesehen ist. Damit lässt sich nachvollziehen, dass der Akteur versuchte, vorhandene Dokumente in ein KI-gestütztes Antwortsystem einzubinden.

Wichtig: Der Befund belegt nicht automatisch, dass die Dokumente gestohlen wurden. Er zeigt vor allem, dass der Angreifer eine Verbindung zwischen seinen Unterlagen und einem KI-System herstellen wollte.

Was diese KI für Phishing und Malware-Workflows verändert

Für Verteidiger ist die Kernfrage: Was wird mit der lokalen KI „besser“ oder „schneller“? Der Bericht ordnet die Aktivität als Baustein in einem erweiterten Angriffsziel ein: Die Kombination aus Dokumentenwissen, textbezogener Ausgabe und nachgelagerten technischen Schritten könnte dazu beitragen, dass Angriffe schneller vorbereitet und schwerer als „weniger poliert“ erkannt werden.

Früher achteten Verteidiger oft auf typische Schwächen KI-generierter Köder: holprige Übersetzungen, unpassende Formatierung oder Rechtschreibfehler. Wenn KI-Ausgaben dadurch konsistenter werden, verlagert sich der Fokus. Der Bericht rät, die Bewertung von Lures nicht allein daran festzumachen, wie „fertig“ die Nachricht wirkt.

Stattdessen sollen Verteidiger Ereignisse und Prozessketten korrelieren. Dazu gehören unter anderem LNK-Ausführungen, der Einsatz von PowerShell, das Auftreten versteckter geplanter Tasks, GitHub-Verkehr sowie anschließend die Aktivitäten, die mit der eigentlichen Payload zusammenhängen.

Mehr als fertige Apps: Developer-Bibliotheken und KI-Komponenten

Die lokale KI-Umgebung beschränkt sich demnach nicht auf „fertige“ Programme. Parallel wurden Entwicklerbibliotheken auf derselben Infrastruktur gefunden, die beim Aufbau individueller KI-Funktionen helfen können. Genannt werden unter anderem LLaMaSharp sowie Komponenten wie Semantic Kernel und Microsoft.Agents.AI, die für die Integration von KI-Funktionen in C#– und .NET-Software genutzt werden können.

Auch bei Sprach- und Audioverarbeitung gab es Hinweise auf zusätzliche Werkzeuge. Erwähnt werden Dateien von Whisper inklusive einer Anleitung, wie sich aus Audiodaten Text extrahieren lässt. Zusätzlich fanden die Forschenden aktive Spuren eines Cursor-ähnlichen, KI-gestützten Code-Editors. Für sich genommen sind diese Tools keine exotischen Einzelstücke. Neu ist vielmehr, dass sie gezielt in einem nationalstaatlichen Operationskontext zusammengesetzt werden.

Operation GitPower: GitHub als Befehlskanal und verschleierte Payloads

Die Beobachtungen fügen sich in eine bestehende Kampagne ein, die in dem Bericht als Operation GitPower bezeichnet wird. Dabei wird GitHub als eine Art Command-and-Control-Kanal missbraucht, konkret in einer Infektionskette, die von LNK über PowerShell läuft.

Der Bericht beschreibt außerdem, dass im Rahmen dieser Kampagne AsyncRAT-Payloads verteilt wurden, die als Bilddateien getarnt sind. Die offline gefundene KI-Schicht ist damit Teil einer größeren technischen Routine, bei der sowohl Kommunikation als auch Datenverarbeitung in einem abgestimmten Ablauf erfolgen.

Was zusätzlich auffiel: Operator-Hinweise und mögliche KI-Checks

Ergänzend fanden die Forscher eine separat wiederhergestellte Operatoranfrage, die darauf ausgelegt war, einen Datensatz zu prüfen. In der Anfrage war die Rede von potenziell wertvollen Informationen wie Wallet-Details, Gmail-Zugangsdaten sowie Historien zur Site-Registrierung.

Die Anfrage endete sinngemäß mit dem Hinweis, dass eine detailliertere Auswertung besser sei und nicht „hals über Kopf“ erfolgen solle. Der Bericht kann jedoch nicht bestätigen, dass diese konkrete Anfrage tatsächlich an einen KI-Dienst geschickt wurde.

Einordnung und Grenzen der aktuellen Beobachtung

So beunruhigend der Befund ist: In den vorliegenden Informationen gibt es laut Bericht derzeit keinen Beleg dafür, dass die neu beobachtete Offline-KI bereits gegen einen realen Opfer-Workflow im Berichtskontext eingesetzt wurde. Ebenso wurde kein offizieller Umfang zur Zahl potenzieller Opfer der GitPower-Kampagne genannt.

Gleichzeitig ordnen die Forscher die Datenlage so ein, dass es sich eher um eine gezielte, kurzfristig greifbare Weiterentwicklung handelt. Zwar werden Grundlagen für Automatisierung gelegt, doch der Gesamtumfang und die konkrete Ausspielung gegenüber einzelnen Opfern bleiben offen.

Warum Verteidiger jetzt anders hinschauen sollten

Wenn Offline-KI bei Kimsuky wirklich Teil der operativen Kette ist, dann rückt die Erkennung stärker in Richtung Verhaltensmuster: technische Indikatoren, Prozessketten und Kommunikationswege sind entscheidend. Der Bericht stellt deshalb die Korrelation mehrerer Artefakte in den Vordergrund, anstatt einzelne Ködermerkmale isoliert zu bewerten.

Für Sicherheitsverantwortliche bedeutet das praktisch: Fokus auf das Zusammenspiel aus Dateiausführung, Command-and-Control-Mechanik, auffälligen PowerShell-Abläufen und dem Auftreten von Payload-Aktivitäten. Zusätzlich sollte man die lokalen KI-Umgebungen als möglichen „Unterbau“ im Hinterkopf behalten, gerade wenn es um ungewöhnliche Dokumenten-Indexierung oder Offline-Modellbetrieb in verdächtigen Umgebungen geht.

Fazit: Lokale KI wird zum Baustein, nicht zum Nebeneffekt

Der neue Befund macht deutlich, dass KI nicht nur als Werkzeug für Textkopien dient. Offline-KI bei Kimsuky deutet vielmehr darauf hin, dass eine Spionageeinheit eigene KI-Funktionen in ihren Angriffsprozess integriert: lokale Sprachmodelle, RAG-gestützte Dokumentenverknüpfung sowie zusätzliche Transkriptions- und Entwicklerkomponenten.

Für die Verteidigung heißt das: weniger allein auf den „Look“ des Köders vertrauen, mehr auf die technischen Abläufe dahinter achten. Wer LNK-, PowerShell-, Scheduling-, GitHub- und Payload-Indikatoren gemeinsam betrachtet, hat die besten Chancen, solche Angriffe frühzeitig zu erkennen — auch dann, wenn KI-Ausgaben deutlich stimmiger wirken als früher.

Quelle: https://thehackernews.com/2026/08/kimsuky-builds-offline-ai-stack-that.html