KI-Halluzinationen erkennen: Anleitung für sichere IOC-Prüfung

Von Marco Gundlach Zuletzt aktualisiert am 13. November 2026

Stell dir vor, du analysierst einen verdächtigen Alarm, fragst deinen KI-Assistenten nach der IP-Adresse und erhältst eine klare Antwort: Die Adresse gehört zur Lazarus Group und wurde bei Angriffen auf Finanzinstitute genutzt. Das Management wird alarmiert, externe Forensiker werden gerufen. Dann stellt sich heraus, dass die Information komplett erfunden war. Genau so sieht eine Halluzination aus. Das Modell formuliert falsche Details in der Tonlage eines Experten und warnt dich dabei nicht.

Video von YouTube abspielen

Das Video wird erst beim Abspielen von YouTube geladen – dabei werden Daten (u. a. deine IP-Adresse) an YouTube bzw. Google übertragen. Mehr dazu in der Datenschutzerklärung

In dieser Anleitung lernst du, warum Sprachmodelle solche Aussagen erzeugen, woran du sie in der Security-Praxis erkennst und welche Prompts und Prüfschritte das Risiko senken. Ziel ist, dass du IOCs, CVE-Details und Threat-Actor-Zuordnungen prüfst, bevor du daraus Entscheidungen ableitest.

Wichtigste Erkenntnisse

• Sprachmodelle wie ChatGPT sind keine Datenbanken. Sie berechnen, welches Wort statistisch als Nächstes wahrscheinlich ist, und können dabei plausibel klingende Fakten erfinden.
• Besonders gefährlich sind spezifische Details ohne Quellenangabe, perfekte Antworten auf obskure Fragen, Widersprüche bei Nachfragen und veraltetes Wissen.
• Prompts, die Unsicherheit erlauben, Konfidenzkategorien erzwingen und eine Selbstprüfung verlangen, reduzieren Halluzinationen deutlich.
• Jede Aussage zu IOCs, CVEs oder Threat Actors muss gegen Primärquellen geprüft und in deiner Dokumentation als verifiziert oder unverifiziert gekennzeichnet werden.
• Eine Quelle, die das Modell nennt, musst du ebenfalls selbst öffnen und prüfen.

Schritt-für-Schritt-Anleitung

Schritt 1: Verstehen, warum Modelle halluzinieren

Bevor du den Fehler vermeiden kannst, musst du seine Ursache kennen. Ein Sprachmodell speichert keine Fakten, die es bei Bedarf abruft. Es wurde trainiert, wahrscheinliche Wortfolgen fortzusetzen. Das funktioniert erstaunlich gut, solange die Fortsetzung zum Wissen passt, und scheitert, sobald sie nur noch plausibel klingt.

Dafür gibt es mehrere Hauptursachen. Erstens gibt es Lücken im Training: Das Modell hat bestimmte Informationen nie gesehen, antwortet aber trotzdem, weil es darauf trainiert wurde, immer eine Antwort zu geben. Zweitens füllt es Wissenslücken durch statistische Interpolation, ähnlich wie ein Mensch, der eine Geschichte ausschmückt, um Lücken zu überbrücken. Drittens hat jedes Modell einen Trainings-Cutoff, und Fragen zu neueren Ereignissen führen leicht zu Erfindungen. Viertens sind Modelle auf Hilfsbereitschaft trainiert. Das Eingeständnis „Ich weiß es nicht“ ist im Training unterrepräsentiert, weshalb Unsicherheit oft unterdrückt wird.

Schritt 2: Typische Security-Halluzinationen erkennen

In der Praxis zeigen sich Halluzinationen häufig bei IP-Adressen, CVE-Nummern und MITRE-ATT&CK-IDs. Ein Beispiel aus dem Video zeigt, wie tückisch das ist: Früher ordnete ChatGPT eine bestimmte IP-Adresse der APT28 zu. Der Grund war jedoch ein Fehler im Ausgangspunkt. Die Adresse lag im Bereich 198.51.100.0/24, der laut RFC 5737 ausschließlich für Dokumentation und Testzwecke reserviert ist. Sie existiert also gar nicht im öffentlichen Internet und kann nie als Angreifer-Infrastruktur aufgetaucht sein. Das Modell hat die Zuordnung trotzdem mit einer erfundenen Geschichte begründet.

Ähnlich verhielt es sich mit der angeblichen CVE-2024-9999, die laut Video nicht existiert, und mit einer erfundenen MITRE-ATT&CK-ID. Auch hier lieferte das Modell eine ausgeschmückte Beschreibung. Solche Fälle sind nicht immer so offensichtlich wie in diesem Beispiel. Halluzinationen können so plausibel klingen, dass du sie ohne Prüfung nicht erkennst. Genau deshalb brauchst du Prüfroutinen statt Bauchgefühl.

Schritt 3: Warnsignale systematisch prüfen

Halluzinationen lassen sich anhand einiger Muster erkennen. Achte zuerst auf zu spezifische Details ohne Quellenangabe. Wenn das Modell ein genaues Erstbeobachtungsdatum, konkrete Registry-Keys oder exakte Angriffsmethoden nennt, frage direkt nach der Quelle. Kann es keine benennen, behandle die Aussage als unbelegt.

Das zweite Warnsignal sind perfekte Antworten auf obskure Fragen. Wenn du nach einer wenig bekannten Malware-Familie fragst und sofort eine ausführliche Antwort erhältst, ist Vorsicht geboten. Selbst erfahrene Analysten recherchieren bei solchen Fragen, weil die Menge an Malware enorm ist.

Das dritte Signal sind Widersprüche bei Nachfragen. Wenn das Modell zunächst APT28 nennt und nach der Frage „Bist du sicher?“ plötzlich APT29 erwähnt, ist das ein klarer Hinweis. Echtes Wissen wackelt bei einer Nachfrage nicht.

Das vierte Signal betrifft aktuelle Ereignisse. Achte auf den Trainings-Cutoff des Modells. Liegt das berichtete Ereignis nach diesem Datum, ist die Information eher unwahrscheinlich oder erfunden.

Das fünfte Signal sind runde Zahlen und vage Angaben wie „etwa 1000 betroffene Systeme“ oder „vor einigen Monaten entdeckt“. Auch das ist typisch für Erfindungen. Die goldene Regel lautet: Wenn eine Aussage zu gut klingt oder zu spezifisch wirkt, verifiziere sie.

Schritt 4: Halluzinationen mit gezielten Prompts reduzieren

Mit der richtigen Anweisung lässt sich das Risiko deutlich senken. Ein erster Ansatz ist, Unsicherheit ausdrücklich zu erlauben. Formuliere im Prompt, dass das Modell nur Informationen angeben soll, bei denen es sicher ist, dass es „Das weiß ich nicht“ sagen darf und dass es Fakten klar von Vermutungen trennen soll. Dadurch sinkt der Druck, eine Antwort um jeden Preis zu liefern.

Ein zweiter Ansatz ist die Konfidenzkategorisierung. Verlange, dass jede Aussage als verifiziert, wahrscheinlich oder unbekannt eingeordnet wird. Fordere außerdem für jeden Fakt eine Quelle an, und wenn keine Quelle möglich ist, soll das Modell die Aussage als nicht verifizierbar markieren.

Ein dritter Ansatz ist die Selbstreflexion. Bitte das Modell, vor der Antwort zu prüfen, ob es die Information tatsächlich kennt. Musste es raten, soll es das benennen und lieber eine unvollständige, aber korrekte Antwort geben. Du wirst feststellen, dass Modelle bei dieser Aufforderung oft eine kurze interne Prüfung anstoßen.

Wichtig ist: Prompts allein reichen nicht. Sie verringern die Fehlerquote, ersetzen aber keine Verifikation.

Schritt 5: Einen Verifizierungs-Workflow etablieren

Der eigentliche Schutz entsteht durch einen festen Prüfprozess. Im ersten Schritt legst du fest, welche Kategorien verifiziert werden müssen. Dazu gehören IOCs wie IPs, Domains und Hashes, außerdem CVE-Angaben, Threat-Actor-Zuordnungen und rechtliche oder Compliance-Aussagen. Alles, worauf du Entscheidungen stützt, gehört in diese Liste.

Im zweiten Schritt prüfst du die Primärquellen. Eine Aussage zu einer CVE überprüfst du bei der NVD oder CVE-Details. IP-Reputationen kontrollierst du bei VirusTotal oder AbuseIPDB, Domain-Informationen über WHOIS oder VirusTotal. Für Techniken nutzt du MITRE ATT&CK und für Threat Actors die Berichte etablierter Anbieter wie CrowdStrike oder vergleichbare Threat-Intelligence-Quellen.

Im dritten Schritt führst du eine Kreuzvalidierung durch. Stelle dieselbe Frage einem zweiten Modell. Stimmen die Antworten überein, steigt deine Konfidenz, widersprechen sie sich, recherchierst du selbst weiter.

Im vierten Schritt dokumentierst du in jedem Report, ob eine Information „verifiziert via Quelle“ oder „unverifiziert, KI-generiert“ ist. Dabei gilt: Auch die Quellen, die das Modell nennt, musst du öffnen. Eine genannte Quelle kann selbst erfunden sein oder ihren Inhalt nicht enthalten.

Schritt 6: Den kompletten Workflow im Praxisbeispiel anwenden

Im letzten Schritt bündelst du alles in einem Systemprompt. Du definierst dem Modell die Rolle eines Security-Analysten mit strengen Qualitätsregeln. Es soll zwischen verifiziert, wahrscheinlich und unbekannt unterscheiden, Quellen nennen, wenn möglich, und bei fehlenden Quellen „nicht verifizierbar“ oder „bitte manuell prüfen“ schreiben. Außerdem verbietest du ausdrücklich, CVE-Nummern oder Angriffsdetails zu erfinden, und verlangst bei Unsicherheit einen Hinweis darauf, wo du nachprüfen kannst.

Stellst du mit diesem Prompt eine Frage nach einer Domain, fällt die Antwort meist anders aus. Das Modell kann dann beispielsweise erklären, dass die Domain ihm nicht bekannt ist, und eine Prüfung über VirusTotal oder URLhaus empfehlen. Ein Teil der Angaben, etwa zur Reservierung von Beispieldomains im DNS-Standard, ist belastbar und lässt sich prüfen. Alles, was als unbekannt markiert ist, prüfst du manuell. Das kostet weniger Zeit, als fehlerhafte Informationen nachträglich zu korrigieren.

Zusammenfassung – KI-Halluzinationen erkennen: Anleitung für sichere IOC-Prüfung

Halluzinationen entstehen, weil Sprachmodelle wahrscheinliche Texte erzeugen und keine geprüften Fakten abrufen. Erkennen kannst du sie an zu spezifischen Details ohne Quelle, an perfekten Antworten auf obskure Fragen, an Widersprüchen bei Nachfragen und an veralteten Informationen. Prompts, die Unsicherheit erlauben, Konfidenzkategorien erzwingen und Selbstreflexion verlangen, senken das Risiko. Der sichere Umgang gelingt jedoch nur mit einem Verifizierungs-Workflow: Kritische Kategorien festlegen, Primärquellen prüfen, Ergebnisse kreuzvalidieren und jede Aussage dokumentieren. Entscheidungen, die auf IOCs, CVEs oder Threat-Actor-Zuordnungen beruhen, triffst du immer auf Basis geprüfter Quellen.

Trainer Über Marco Gundlach Marco Gundlach kommt aus der Projektpraxis, nicht aus dem KI-Hype. Über 14 Jahre hat er Digitalisierungs- und IT-Projekte verantwortet, unter anderem bei Hugo Boss, Fressnapf und Aktion Mensch. Alle Kurse von Marco Gundlach →