Schatten-KI im Netz finden — was die DNS-Logs verraten

/01Schatten-KI im Netzverkehr: was sichtbar ist und was nicht

Schatten-KI lässt sich im Firmennetz am zuverlässigsten über die DNS-Abfragen erkennen, die jedes Endgerät vor dem Aufruf eines KI-Dienstes stellt. Läuft der Resolver auf der Firewall — bei OPNsense ist das Unbound —, genügt es, die Abfragen mit Client-Adresse zu protokollieren und gegen eine Liste bekannter KI-Domains zu filtern.

Gemeint ist mit Schatten-KI hier etwas Enges: die Nutzung öffentlicher KI-Dienste mit Firmendaten, ohne dass die IT davon weiß und ohne Vertrag, der die Verarbeitung regelt. Nicht gemeint sind Agenten mit Werkzeugzugriff, Prompt Injection oder MCP-Server — diese Angriffsfläche und den organisatorischen Rahmen dafür beschreibt KI-Agenten im Unternehmen: Die neue Angriffsfläche.

Was eine DNS-Auswertung liefert, ist begrenzt und muss so benannt werden. Sie zeigt, dass ein Gerät zu einem bestimmten Zeitpunkt einen Namen aufgelöst hat. Sie zeigt nicht, wer davor saß, was eingegeben wurde und ob überhaupt jemand bewusst etwas getan hat — ein offener Browser-Tab, eine Erweiterung oder eine Desktop-App fragen auch im Hintergrund nach. Das Paketfilter-Log der Firewall hilft hier kaum: Es enthält nur Adressen, und chatgpt.com wie www.perplexity.ai lösten am 22.10.2026 auf Adressen des CDN-Anbieters Cloudflare auf — eine solche Adresse steht nicht für einen einzelnen Dienst. Inhalte sieht man über DNS nie, und über die Firewall nur mit TLS-Aufbruch, den die meisten Mittelständler aus guten Gründen nicht betreiben. Für die Frage „Welche KI-Dienste sind im Haus im Einsatz, und wie verbreitet?" reicht das aber völlig.

/02Welche Domains gängige KI-Dienste nutzen

Die folgende Liste deckt die Dienste ab, die in Mittelstandsnetzen erfahrungsgemäß am häufigsten auftauchen. Sie trennt zwischen Weboberfläche, die Menschen im Browser nutzen, und Programmierschnittstelle, die Skripte, Plug-ins und Fremdsoftware ansprechen. Die zweite Spalte ist oft aufschlussreicher: Ein API-Aufruf von einem Arbeitsplatz heißt meist, dass dort ein Werkzeug mit eigenem Schlüssel läuft — ein Office-Add-in, ein Editor-Plug-in, ein selbst gebautes Skript.

DeepL taucht erfahrungsgemäß in fast jeder Auswertung auf, weil Übersetzen niemand als „KI nutzen" empfindet; dort landen aber Verträge, Reklamationen und Personalunterlagen im Volltext. Und Mistral steht bewusst in der Liste, obwohl der Anbieter aus Europa kommt: Schatten-KI ist keine Frage des Firmensitzes, sondern ob es eine Freigabe und einen Vertrag zur Auftragsverarbeitung gibt. Ohne beides ist auch ein europäischer Dienst ein ungeregelter Datenabfluss im Sinne der DSGVO.

Die Liste veraltet — chat.openai.com etwa leitet nur noch auf chatgpt.com weiter. Pflegen Sie sie als Datei mit Datum. Fertige „KI"-Kategorien von DNS-Filteranbietern legen ihre Zusammensetzung selten offen; für eine Bestandsaufnahme brauchen Sie eine Liste, die Sie erklären können.

/03Unbound auf OPNsense: Abfragen protokollieren

OPNsense bringt zwei Wege mit, die sich ergänzen. Der erste kostet keine Konfiguration: Unter Reporting › Unbound DNS zeigt die Firewall seit Version 23.1 eine Übersicht mit den meistabgefragten Domains und einen Reiter Details, in dem jede abgeschlossene Abfrage mit Client, Domain, Eintragstyp, Aktion und Antwortquelle steht. Die Daten bleiben laut Dokumentation sieben Tage auf dem System.

Für eine Auswertung über mehrere Wochen oder eine Weiterleitung an ein SIEM braucht es das Textlog. Dafür sind unter Services › Unbound DNS › Advanced zwei Schalter zu setzen:

• Log Queries — eine Zeile je Anfrage mit Client-Adresse, Name, Typ und Klasse.
• Tag Queries and Replies — setzt das Wort query: vor jede Zeile und macht das Filtern eindeutig.

Die OPNsense-Dokumentation warnt ausdrücklich, dass „Log Queries" den Resolver deutlich verlangsamt. In der Praxis, als Erfahrungswert ohne Messreihe: Auf einer Firewall mit vierzig Arbeitsplätzen merkt man davon nichts, bei mehreren hundert Clients und hohem Abfragevolumen sollte man den Schalter für einen definierten Zeitraum setzen — etwa zwei Wochen Bestandsaufnahme — und danach wieder herausnehmen oder die Last beobachten. Das Log landet über syslog-ng in /var/log/resolver/, eine Datei je Tag nach dem Muster resolver_JJJJMMTT.log. Die Aufbewahrung richtet sich nach den allgemeinen Log-Einstellungen der Firewall.

Eine Voraussetzung wird gern übersehen: Die Auswertung sieht nur Geräte, die Unbound tatsächlich als Resolver nutzen. Verteilt der DHCP-Server eines Netzsegments einen anderen DNS-Server, etwa den Domänencontroller, der dann direkt nach außen auflöst, taucht dieses Segment im Log nur als eine Adresse auf — die des Domänencontrollers. Dann gehört die Weiterleitung des DC auf Unbound zur Vorarbeit, sonst misst man das falsche Gerät.

/04Die Auswertung: welche Geräte KI-Dienste ansprechen

Mit aktivem Query-Log lässt sich die Frage direkt auf der Firewall beantworten. Der folgende Aufruf läuft in der Shell von OPNsense (Menüpunkt 8, dann sh, weil die Standard-Shell keine Bourne-Syntax spricht). Er zieht aus allen Tagesdateien Client und Domain, filtert gegen die Liste aus Abschnitt zwei und zählt:

# sh
$ export KI='(^|[.])(chatgpt[.]com|openai[.]com|oaiusercontent[.]com|claude[.]ai|anthropic[.]com|gemini[.]google[.]com|generativelanguage[.]googleapis[.]com|copilot[.]microsoft[.]com|perplexity[.]ai|deepseek[.]com|mistral[.]ai|grok[.]com|x[.]ai|deepl[.]com)[.]$'
$ cat /var/log/resolver/resolver_*.log \
    | awk '{for(i=1;i<=NF;i++) if($i=="query:") print $(i+1), $(i+2)}' \
    | awk '$2 ~ ENVIRON["KI"]' \
    | sort | uniq -c | sort -rn | head -15

 412 192.168.20.31 chatgpt.com.
 188 192.168.20.31 ab.chatgpt.com.
  97 192.168.20.47 www.deepl.com.
  64 192.168.30.12 api.openai.com.
  41 192.168.20.18 claude.ai.
   9 192.168.20.55 chat.deepseek.com.
   2 192.168.40.5  gemini.google.com.

Die Befehlskette haben wir am 22.10.2026 gegen Musterzeilen im Dateiformat von OPNsense geprüft (mit gawk, mawk und BusyBox, nicht mit dem awk von FreeBSD). Die Ausgabe oben ist ein Beispiel mit erfundenen Adressen. Die Muster bedeuten:

• Hohe Zahlen an einem Client, mehrere Subdomains (192.168.20.31): regelmäßige Nutzung im Browser. Über die Intensität sagt die Zahl wenig, weil Endgeräte unterschiedlich lange cachen.
• API-Domain aus einem Server- oder Entwicklernetz (192.168.30.12): Das ist der interessanteste Fund. Ein Skript oder Werkzeug spricht die Schnittstelle direkt an, vermutlich mit einem privat bezahlten Schlüssel — Daten fließen automatisiert und ohne Oberfläche, die jemand sieht.
• Einzelne Treffer (192.168.40.5): ein Link in einer Mail, ein Neugier-Klick. Für sich kein Befund.
• Dienste mit Sitz außerhalb der EU ohne Vertrag (192.168.20.55): unabhängig von der Häufigkeit ein Punkt für das Gespräch mit dem Datenschutzbeauftragten.

Die Zuordnung von Adresse zu Gerät liefern DHCP-Leases oder Inventar. Wer die Netze in VLANs nach Abteilungen trennt, bekommt die Verdichtung geschenkt: „Vertrieb nutzt DeepL, Entwicklung die OpenAI-Schnittstelle" ist wertvoller als eine Rechnerliste — und datenschutzrechtlich entspannter.

/05Wazuh-Regel: KI-Zugriffe als Ereignis statt Stichprobe

Die Shell-Auswertung ist eine Momentaufnahme. Wer das Thema dauerhaft im Blick haben will, schickt das Resolver-Log per Remote-Syslog an Wazuh und lässt dort eine Regel zählen. Wir haben das am 22.10.2026 mit dem offiziellen Container-Abbild von Wazuh 4.14.9 und /var/ossec/bin/wazuh-logtest durchgespielt. Drei Dinge waren anders als erwartet:

• Wazuh bringt einen Unbound-Decoder mit (0345-unbound_decoders.xml). Er zerlegt aber nur ungetaggte A- und AAAA-Zeilen und legt den Namen im Feld url ab. Zeilen mit query: erkennt er als Unbound, zieht aber keine Felder heraus.
• Ein eigener Kind-Decoder muss unbound-a heißen, wie der mitgelieferte. Unter anderem Namen wurde er im Test nie ausprobiert, und eine eigene Basisregel auf decoded_as kam nie zum Zug, weil die mitgelieferten Regeln 500000 ff. vorher greifen. Die Regel hängt sich deshalb an deren IDs.
• Das Remote-Ziel auf OPNsense braucht das klassische Syslog-Format, also ohne Haken bei „RFC5424". Zeilen im RFC-5424-Format erkannte Wazuh im Test mit keinem Decoder.

<!-- /var/ossec/etc/decoders/local_decoder.xml -->
<decoder name="unbound-a">
  <parent>unbound</parent>
  <regex type="pcre2">info: query: (\S+) (\S+?)\.? (\S+) IN$</regex>
  <order>srcip,dns_query,dns_qtype</order>
</decoder>

<decoder name="dnsmasq-query">
  <program_name>^dnsmasq$</program_name>
  <regex type="pcre2">^query\[(\S+)\] (\S+) from (\S+)$</regex>
  <order>dns_qtype,dns_query,srcip</order>
</decoder>

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="local,dns,schatten_ki,">
  <rule id="100510" level="0">
    <decoded_as>dnsmasq-query</decoded_as>
    <description>Dnsmasq: DNS-Abfrage</description>
  </rule>

  <rule id="100511" level="3">
    <if_sid>500002, 500101, 500102, 100510</if_sid>
    <field name="dns_query" type="pcre2">(?i)(^|\.)(chatgpt\.com|openai\.com|oaiusercontent\.com|claude\.ai|anthropic\.com|gemini\.google\.com|generativelanguage\.googleapis\.com|copilot\.microsoft\.com|perplexity\.ai|deepseek\.com|mistral\.ai|grok\.com|x\.ai|deepl\.com)$</field>
    <description>KI-Dienst angefragt: $(dns_query) von $(srcip)</description>
  </rule>

  <rule id="100512" level="7">
    <if_sid>100511</if_sid>
    <field name="dns_query" type="pcre2">(?i)^(api(-free)?\.|generativelanguage\.)</field>
    <description>KI-Schnittstelle direkt angesprochen: $(dns_query) von $(srcip)</description>
  </rule>
</group>

Das Ergebnis von wazuh-logtest mit Musterzeilen, gekürzt auf Eingabe und ausgelöste Regel:

info: query: 192.168.20.31 chatgpt.com. A IN
  id: '100511'  level: '3'  KI-Dienst angefragt: chatgpt.com von 192.168.20.31
info: query: 192.168.30.12 api.openai.com. AAAA IN
  id: '100512'  level: '7'  KI-Schnittstelle direkt angesprochen: api.openai.com von 192.168.30.12
info: query: 192.168.20.31 notchatgpt.com. A IN
  id: '500101'  level: '0'  Unbound: DNS A request.
info: 192.168.20.47 www.deepl.com. A IN           (ohne Tag-Schalter)
  id: '500101'  level: '0'  Unbound: DNS A request.
dnsmasq[7712]: query[A] api-free.deepl.com from 192.168.20.47
  id: '100512'  level: '7'  KI-Schnittstelle direkt angesprochen: api-free.deepl.com von 192.168.20.47

Die vierte Zeile zeigt, dass ähnlich klingende Domains nicht anschlagen, die fünfte, warum der Schalter „Tag Queries and Replies" Pflicht ist: Ohne ihn landet der Name im Feld url, und die Regel bleibt stumm. Den Dnsmasq-Decoder brauchen nur Firewalls, die Dnsmasq mit „Log the results of DNS queries" als Resolver betreiben. Die IDs liegen im Bereich 100000 bis 120000, den Wazuh für eigene Regeln vorsieht.

Die Stufen sind bewusst niedrig: Stufe 3 legt ihn als Ereignis ab, das sich im Dashboard nach Domain und Netz auswerten lässt. Stufe 7 hebt den Schnittstellen-Fall aus Abschnitt vier hervor. Eine CDB-Liste unter /var/ossec/etc/lists statt des regulären Ausdrucks ist möglich, aber match_key vergleicht exakt: Jede Subdomain müsste einzeln in der Liste stehen.

Wie aus Regeln gepflegte Erkennungen mit Testfällen werden, beschreibt Detection Engineering: Von Sigma-Regeln zum Wazuh-Alarm. Faustregel aus dem Betrieb: erst vier Wochen sammeln, dann die Stufen nach dem festlegen, was tatsächlich auftaucht. Eine Regel mit Hunderten Treffern am ersten Tag wird am zweiten ignoriert.

/06Wo die Erkennung blind ist

Eine DNS-Auswertung, die als vollständig verkauft wird, schadet mehr als keine. Fünf Lücken gehören in jede Ergebnisvorlage an die Geschäftsführung.

DNS over HTTPS im Browser

Firefox, Chrome und Edge können Namen verschlüsselt über HTTPS bei einem externen Anbieter auflösen und damit am Firmenresolver vorbei. Firefox prüft vorher die Canary-Domain use-application-dns.net: Liefert der Resolver dafür eine negative Antwort, schaltet Firefox das standardmäßig aktivierte DoH ab — aber nicht, wenn ein Nutzer DoH selbst eingeschaltet hat. Unbound kann diese Domain per Blocklisten-Eintrag mit NXDOMAIN beantworten. Verlässlich wird es erst mit Browser-Richtlinien, die DoH zentral abschalten, und mit Firewall-Regeln, die ausgehendes DNS an andere Resolver unterbinden.

Smartphones und Mobilfunk

Ein Bildschirmfoto, hochgeladen in die ChatGPT-App auf dem privaten Telefon, erzeugt keinen Eintrag im Firmennetz — der naheliegende Ausweg, sobald etwas sichtbar gesperrt wird.

KI in bereits freigegebenen Diensten

Copilot in Microsoft 365, KI-Funktionen in Notion, Zoom, Canva oder dem CRM laufen über die Domains des Hauptdienstes. Im DNS-Log sind sie von der normalen Nutzung nicht zu unterscheiden. Ob dort Daten in ein Modell gehen, entscheidet die Konfiguration des Mandanten — bei Microsoft 365 die Lizenzzuweisung und die Richtlinien in Entra ID —, nicht die Firewall.

VPN, Privatgeräte, Homeoffice

Ein Gerät mit eingeschaltetem privatem VPN-Dienst tunnelt alles am Resolver vorbei. Firmenlaptops im Homeoffice ohne Zwangstunnel lösen über den heimischen Router auf. Für diesen Teil liefert nur ein Agent auf dem Endgerät Daten, oder ein Fernzugang nach dem ZTNA-Prinzip, der den Verkehr ohnehin über eine kontrollierte Stelle führt.

Caching und gemeinsame Adressen

Terminalserver, Citrix-Farmen und Proxys bündeln viele Nutzer hinter einer Adresse. „Der Terminalserver nutzt DeepL" ist wahr, aber für die Frage nach Abteilungen wertlos. Mehr liefern nur Protokolle auf dem Server selbst — und damit wird die Mitbestimmungsfrage noch schärfer.

/07Protokollauswertung, Datenschutz und Betriebsrat

DNS-Logs mit Client-Adressen sind personenbeziehbar, sobald sich eine Adresse einem Arbeitsplatz zuordnen lässt — und genau dafür werden sie in Abschnitt vier ausgewertet. Das ist kein Grund, es zu lassen, aber einer, es sauber aufzusetzen. Keine Rechtsberatung, sondern die Punkte, die vorher geklärt sein sollten.

• Mitbestimmung: § 87 Abs. 1 Nr. 6 BetrVG gibt dem Betriebsrat ein Mitbestimmungsrecht bei technischen Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung der Arbeitnehmer zu überwachen. Eine Auswertung, die einzelne Rechner benennt, fällt nach gängiger Lesart darunter. Ohne Einigung ist sie in Betrieben mit Betriebsrat angreifbar — und der Fund im Zweifel unverwertbar.
• Zweck und Umfang: Schriftlich festhalten, wofür ausgewertet wird (Bestandsaufnahme der genutzten KI-Dienste), wie lange Rohdaten aufbewahrt werden und wer sie sieht. Für die Dokumentation eignet sich das Verzeichnis der technischen und organisatorischen Maßnahmen.
• Verdichten statt benennen: Für die Entscheidung, ob ein internes Angebot gebraucht wird, genügen Zahlen je Netzsegment oder Abteilung. Rechnernamen braucht es nur für den API-Fall, und auch dort reicht oft „ein Server im Entwicklungsnetz".
• Ankündigen: Eine angekündigte Bestandsaufnahme ändert das Verhalten — hier erwünscht. Ziel ist zu wissen, wofür die Leute KI brauchen, nicht jemanden zu erwischen.

Ehrlich: Der häufigste Fehler ist nicht die zu lange Aufbewahrung, sondern die Einzelfall-Mail an einen Abteilungsleiter mit einer Liste von Rechnern. Danach ist das Thema politisch verbrannt, und die eigentliche Frage — welches Werkzeug brauchen die Leute — stellt niemand mehr.

/08Warum Sperren allein scheitert — und was an ihre Stelle tritt

Technisch ist die Sperre der kleinste Schritt. Unbound auf OPNsense nimmt unter Services › Unbound DNS › Blocklists eigene Domains an, mit „Wildcard Domains" samt aller Subdomains. Über „Destination Address" lässt sich statt einer leeren Antwort die Adresse eines internen Webservers zurückgeben, auf dem eine Hinweisseite steht. Bei HTTPS-Diensten sieht der Nutzer allerdings zuerst eine Zertifikatswarnung, weil der interne Server kein Zertifikat für chatgpt.com hat — die Hinweisseite funktioniert also nur halb, und man sollte das vorher wissen.

Entscheidend ist, was danach passiert. Die PagerDuty-Umfrage vom Juni 2026 — 1.250 Bürobeschäftigte in Unternehmen ab 500 Millionen US-Dollar Umsatz in den USA, Großbritannien, Australien und Japan, Deutschland war nicht dabei — liefert dazu drei Werte, die sich gut übertragen lassen: 66 Prozent haben KI-Tools bei der Arbeit genutzt, obwohl sie annahmen, die Richtlinie erlaube das nicht. 88 Prozent haben Arbeitsinformationen mit öffentlichen KI-Tools geteilt, 34 Prozent nennen dabei Kundendaten. Und 89 Prozent sind zuerst privat mit KI in Kontakt gekommen. Die Nutzung wird mitgebracht — eine DNS-Sperre ändert die Gewohnheit nicht, sie verlagert sie aufs Telefon.

In der Praxis funktioniert eine Reihenfolge, die sich in drei Schritte fassen lässt:

• Messen wie in den Abschnitten drei bis fünf, zwei bis vier Wochen, verdichtet nach Abteilungen.
• Anbieten, was die Messung als Bedarf zeigt: Übersetzen, Zusammenfassen, Fragen an interne Dokumente. Eine freigegebene Plattform im eigenen Netz, für die es eine Anmeldung per Single Sign-on und eine kurze Nutzungsregel gibt.
• Dann sperren, und zwar gezielt: Dienste ohne Vertrag und mit Sitz außerhalb der EU zuerst, die Schnittstellen-Domains aus Server- und Entwicklungsnetzen sofort. Mit Hinweis, wo das freigegebene Werkzeug zu finden ist.

Die Reihenfolge ist keine Formsache. Wer zuerst sperrt, lernt in der zweiten Messung nur noch, wer DoH oder das Telefon nutzt. Wer zuerst anbietet, sieht in der zweiten Messung, wie viel Nutzung von außen nach innen gewandert ist — und hat damit eine Kennzahl, die sich der Geschäftsführung zeigen lässt. Die Schulung, die der EU AI Act mit der KI-Kompetenzpflicht ohnehin verlangt, ist der natürliche Ort, um das neue Werkzeug einzuführen; was dort hineingehört, beschreibt KI-Kompetenzpflicht Art. 4: Was Schulung im Mittelstand heißt.

/09Wann sich der Aufwand lohnt und wann nicht

Nicht jede Umgebung braucht eine Wazuh-Regel. Die Tabelle ordnet nach Ausgangslage:

Irrelevant wird das Thema, wenn ein freigegebener KI-Dienst mit Vertrag tatsächlich genutzt wird und die Messung nur noch Restverkehr zeigt. Dann genügt eine jährliche Stichprobe. Und wenn Ihre Mitarbeiter überwiegend mobil oder im Homeoffice ohne Firmentunnel arbeiten, misst die Firewall schlicht zu wenig — dann gehört das Geld in Endgeräteverwaltung und Richtlinie, nicht in Resolver-Logs.

Die meisten KMU, die wir in dieser Frage begleiten, landen in der Mitte: OPNsense ist da, ein SIEM nicht. Für sie ist die zweiwöchige Bestandsaufnahme mit Shell-Auswertung der richtige Umfang — erfahrungsgemäß ein halber Tag Arbeit, ohne dass daraus ein Dauerprojekt wird. Ob danach eine SOC-Anbindung sinnvoll ist, entscheidet sich an anderen Themen als an der KI-Nutzung.

/10Häufige Fragen