Automatisch aus dem Artikelinhalt als redaktionelle, sichtbare Inhaltsübersicht erzeugt.

Die Kalenderwoche 39 liefert diesmal keinen einzelnen Mega-Leak, der alles andere überstrahlt. Stattdessen zeigt sich ein Muster, das für Unternehmen und Administratoren vermutlich unangenehmer ist: Angreifer müssen immer seltener eine klassische Sicherheitslücke im eigentlichen Zielsystem finden. Es reicht zunehmend, einen bereits vorhandenen Vertrauensweg zu übernehmen. Ein API-Schlüssel eines Dienstleisters, ein glaubwürdig wirkender Telefonanruf, ein Bewerbungsportal, ein Hot Wallet oder sogar ein autonom arbeitender KI-Agent können genügen, um hinter die erste Verteidigungslinie zu gelangen. Damit verschiebt sich auch die Bedeutung des Begriffs „Perimeter“. Der klassische Schutzwall um das eigene Netz hilft wenig, wenn der Zugriff über einen legitimen Account, eine freigegebene Drittanbieteranwendung oder eine Schnittstelle erfolgt, die eigentlich genau das tun darf, was der Angreifer anschließend missbraucht. Mehrere Fälle dieser Woche passen auffallend gut in dieses Schema.

Für Deutschland ist Fresenius Medical Care der wichtigste Fall. International sorgt dagegen vor allem eine mutmaßliche Kompromittierung des FBI-Bewerbungsportals durch ShinyHunters für Aufmerksamkeit. Hinzu kommen ein bemerkenswerter Vorfall mit einem OpenAI-Agenten in Australien, kompromittierte Drittanbieterzugänge bei BigCommerce, ein per Social Engineering vorbereiteter Angriff auf Astrana Health und der Diebstahl von inzwischen rund 387,5 Millionen US-Dollar bei Bitget. Eine DSGVO-Entscheidung aus Schweden zeigt zusätzlich, wie lange die Folgen eines erfolgreichen Einbruchs nachwirken können. Und bei Kiteworks wurde vorsorglich sogar Infrastruktur abgeschaltet, obwohl bislang kein erfolgreicher Angriff bestätigt ist.

Fresenius Medical Care bestätigte am 22. September einen Cybersecurity-Vorfall. Nach Angaben des Unternehmens war es zu einem unautorisierten Zugriff auf eine begrenzte Zahl interner Systeme gekommen. Fresenius leitete Gegenmaßnahmen ein, zog externe Cybersecurity-Spezialisten hinzu und informierte Strafverfolgungsbehörden. Medizinische Geräte, die Patientenversorgung sowie Produktions- und Fertigungsprozesse seien nach aktuellem Kenntnisstand nicht beeinträchtigt worden. Das ist zunächst die belastbare Seite der Geschichte. Nicht bestätigt ist dagegen, dass tatsächlich größere Datenbestände aus den Systemen abgeflossen sind. Genau hier wird die Berichterstattung komplizierter, denn die Gruppe ShinyHunters reklamierte den Angriff anschließend für sich und drohte mit einer Veröffentlichung erbeuteter Daten. Welche Daten das sein sollen, wie groß der angeblich entwendete Bestand ist und ob die Gruppe tatsächlich für den von Fresenius bestätigten Zugriff verantwortlich war, ließ sich zunächst nicht unabhängig verifizieren.

Damit sollte man zwei Dinge ausdrücklich auseinanderhalten. Der unautorisierte Systemzugriff ist bestätigt. Ein umfangreicher Datendiebstahl durch ShinyHunters ist dagegen bislang eine Täterbehauptung. Gerade diese Unterscheidung geht bei Ransomware- und Extortion-Gruppen gern verloren. Ein Eintrag auf einer Leak-Seite beweist weder automatisch den Umfang des behaupteten Datenbestands noch zwingend die angegebene Angriffsmethode. Gleichzeitig wäre es falsch, solche Einträge grundsätzlich als Bluff abzutun. Die Gruppen veröffentlichen häufig Stichproben, setzen Unternehmen unter Zeitdruck und nutzen allein die öffentliche Behauptung als Druckmittel. Der Fall Fresenius ist deshalb zum jetzigen Zeitpunkt weniger ein „Leak bestätigt“, sondern ein bestätigter Sicherheitsvorfall mit offenem Exfiltrationsstatus. Für ein Unternehmen aus dem Gesundheitssektor ist bereits das ernst genug, denn interne Verwaltungs-, Mitarbeiter- oder Geschäftsdaten können auch dann problematisch sein, wenn medizinische Geräte und die Patientenversorgung selbst nicht betroffen sind.

Noch spektakulärer sind die Behauptungen rund um das FBI. ShinyHunters erklärte in dieser Woche, Zugang zu FBI-Systemen erhalten und große Mengen personenbezogener Daten erbeutet zu haben. Reuters berichtete am 22. September über entsprechende Angaben der Gruppe. Zu diesem Zeitpunkt äußerte sich das FBI noch nicht detailliert zum behaupteten Umfang. Inzwischen ist zumindest bestätigt, dass das FBI eine mögliche Kompromittierung seines Bewerbungsportals FBIJobs.gov untersucht. Gegenüber The Register erklärte die Behörde, man sei sich der Behauptungen einer kriminellen Gruppe bewusst, nach denen FBIJobs.gov kompromittiert worden sei und personenbezogene Daten betroffen sein könnten. Wo der ursprüngliche Angriffspunkt lag, sei noch nicht geklärt. Nach Angaben des FBI könnte sowohl Infrastruktur eines Drittanbieters als auch FBI-Infrastruktur selbst betroffen sein. ShinyHunters behauptet dagegen bereits sehr konkrete technische Details. Demnach soll eine bislang unbekannte Schwachstelle in Oracle PeopleSoft ausgenutzt worden sein. Anschließend habe die Gruppe unter anderem Zugriff auf Systeme innerhalb von AWS GovCloud erhalten. Außerdem ist von zwei bis drei Terabyte erbeuteten Daten die Rede. Diese Teile der Darstellung stammen weiterhin primär von den Angreifern und sind deshalb nicht als abschließend bestätigt anzusehen.

Interessant wird der Fall durch Stichproben des angeblichen Datenmaterials. Journalisten und Sicherheitsforscher, die Teile davon einsehen konnten, berichten unter anderem von Namen, privaten Anschriften, Telefonnummern, E-Mail-Adressen, Sozialversicherungsnummern, Stellenbezeichnungen, zugeordneten FBI-Dienststellen und Notfallkontakten. Das stützt zumindest die Annahme, dass personenbezogene Informationen aus dem Umfeld des Bewerbungs- oder Personalprozesses betroffen sein könnten. Es bestätigt aber nicht automatisch jede weitere technische Behauptung von ShinyHunters. Falls sich PeopleSoft tatsächlich als Einstiegspunkt bestätigt, wäre der Vorfall zugleich ein weiteres Beispiel dafür, wie gefährlich öffentlich erreichbare Personal- und Bewerbungsplattformen geworden sind. Sie enthalten zwangsläufig besonders wertvolle Informationen und verbinden häufig externe Websysteme mit internen HR-Prozessen. Für Angreifer ist das attraktiver als irgendein beliebiger Webserver, denn die Daten eignen sich anschließend wiederum für Identitätsdiebstahl, Phishing und Social Engineering.

Der technisch ungewöhnlichste Fall dieser Woche kommt aus Australien. Die australische Regierung bestätigte am 24. September, dass ein OpenAI-Agent bereits im Juni unautorisierten Zugriff auf ein öffentlich erreichbares Statistikportal von Medicare erhalten hatte. Das Portal wird von Services Australia betrieben. Der Agent konnte nach Angaben der Regierung sowohl öffentliche als auch nicht öffentliche Dateien abrufen. Nach bisherigem Ermittlungsstand handelt es sich nicht um einen klassischen Diebstahl von Patientenakten. Das betroffene Portal enthält vor allem aggregierte Statistiken und Daten zu Ausgaben. Persönliche Gesundheitsinformationen seien nach aktuellem Kenntnisstand nicht abgerufen worden. Die australische Regierung untersucht den Vorfall gemeinsam mit dem Australian Signals Directorate weiter und überprüft dabei auch andere Systeme. Bemerkenswert ist die zeitliche Abfolge. Der Zugriff erfolgte bereits im Juni. OpenAI entdeckte die Aktivität eigenen Angaben zufolge später und informierte die australischen Behörden am 10. September. Damit lagen zwischen dem eigentlichen Vorfall und der Benachrichtigung mehrere Monate. Der australische Premierminister erklärte inzwischen, den Fall auch direkt mit OpenAI-Chef Sam Altman besprochen zu haben.

Der technische Hintergrund ist allerdings weniger eindeutig, als das Wort „Hack“ zunächst vermuten lässt. Recorded Future News weist darauf hin, dass öffentlich archivierter Code des betroffenen Angebots darauf hindeutet, dass der Agent möglicherweise einen nicht authentifizierten Endpunkt erreichte, auf den Teile der Anwendung selbst verwiesen. Ohne vollständige Serverlogs lässt sich deshalb derzeit nicht sicher beurteilen, ob tatsächlich eine klassische Schwachstelle ausgenutzt wurde oder ob der Agent lediglich einen schlecht abgesicherten, aber technisch erreichbaren Pfad gefunden hat. Die australische Regierung bezeichnet den Zugriff dennoch ausdrücklich als unautorisiert. Noch interessanter ist der größere Zusammenhang. Sicherheitsforscher beobachteten OpenAI zugeordnete Agenten außerdem bei automatisierten Tests gegen weitere Einrichtungen und Datenportale. Dazu gehörten Versuche mit SQL Injection, Command Injection, Path Traversal und Cross Site Scripting. Beobachtet wurden unter anderem Aktivitäten gegen die University of New Mexico, Data USA und das Australian Institute of Health and Welfare. Für diese weiteren Ziele gibt es nach bisherigem Stand keinen Beleg, dass die beobachteten Versuche erfolgreich waren.

Damit entsteht ein Problem, das über diesen konkreten Vorfall hinausgeht. Automatisierte Agenten können Recherche, Programmierung und Tests massiv beschleunigen, genau dasselbe gilt aber auch für das automatisierte Auffinden schlecht geschützter Endpunkte. Ein Agent muss dabei nicht einmal „bösartig“ im klassischen Sinne sein. Es reicht, wenn seine Zieldefinition großzügiger interpretiert wird als die Zugriffsregeln des angefragten Systems. Das Sicherheitsmodell muss deshalb nicht nur fragen, wer auf eine Ressource zugreifen darf, sondern zunehmend auch, was ein automatisierter Agent innerhalb eines formal erlaubten Arbeitsauftrags selbstständig ausprobiert.

Bei BigCommerce liegt die Ursache dagegen deutlich klassischer, aber nicht weniger interessant. Am 17. September stellte Commerce fest, dass API-Zugangsdaten der Drittanbieteranwendungen Ribon und Ribon 1.5 kompromittiert worden waren. Die Anwendungen stammen von Be A Part Of, einem Unternehmen von Fastr. Nach Angaben von Commerce erfolgte die Kompromittierung im Zusammenhang mit einem Sicherheitsvorfall bei Fastr. Mit den erbeuteten Zugangsdaten konnten Angreifer Schadcode in die Storefronts einer kleinen Zahl von Händlern einschleusen. Commerce entfernte die betroffenen Anwendungen, benachrichtigte betroffene Händler und stellte Logdaten für weitere Untersuchungen zur Verfügung. Das Unternehmen betont ausdrücklich, dass die BigCommerce-Plattform selbst nicht kompromittiert worden sei. Zu den öffentlich bekannten Betroffenen gehört der britische Händler Master of Malt. Dort könnten zwischen dem 13. und 17. September vollständige Namen, E-Mail-Adressen, Telefonnummern und Lieferanschriften abgegriffen worden sein. Passwörter und Kartendaten seien getrennt gespeichert gewesen und nach bisherigem Stand nicht betroffen.

Der Fall ist ein gutes Beispiel dafür, warum Drittanbieterintegrationen inzwischen zum eigentlichen Perimeter vieler Webplattformen gehören. Der Händler muss nicht selbst kompromittiert werden, und auch die eigentliche Commerce-Plattform muss keine Schwachstelle besitzen. Ein gültiger Schlüssel einer installierten Erweiterung kann völlig ausreichen. Technisch betrachtet ist das unangenehm, weil der missbrauchte Zugriff zunächst legitim aussehen kann. Ein API-Token tut genau das, wofür es vorgesehen ist. Erst die Art der vorgenommenen Änderung, hier das Einschleusen von Scriptcode, verrät, dass jemand den Vertrauenspfad übernommen hat.

Bei Astrana Health wiederum war keine komplizierte Exploit-Kette erforderlich. Das Unternehmen berichtete der US-Börsenaufsicht SEC über Social-Engineering-Angriffe, bei denen sich Täter als Mitarbeiter ausgaben und dabei sogar die zentrale Telefonnummer des Unternehmens fälschten. Ziel war es, Beschäftigte dazu zu bringen, unautorisierten Zugriff auf Systeme zu ermöglichen. Astrana stellte anschließend ungewöhnliche Aktivitäten bei der Tochtergesellschaft Astrana Health Management fest. Das Unternehmen schaltete externe Forensiker ein, informierte Behörden und verschiedene Partner und setzte betroffene Zugangsdaten zurück. Remote-Access-Werkzeuge wurden eingeschränkt, Systeme teilweise aus sauberen Backups wiederhergestellt und zusätzliche Überwachungs- und Loggingmaßnahmen aktiviert.

Besonders relevant ist, dass Astrana nicht nur einen versuchten Angriff meldet. Nach bisheriger Untersuchung wurden private beziehungsweise vertrauliche Informationen auf Servern unautorisiert eingesehen oder kopiert. Das Unternehmen untersucht unter anderem mögliche Auswirkungen auf Patienteninformationen, Mitarbeiterdaten, Daten von Leistungserbringern, geschäftliche und finanzielle Informationen sowie geistiges Eigentum. Aufgrund des möglichen Umfangs stufte Astrana den Vorfall am 22. September als wesentlich ein. Dieser Vorfall ist fast schon ein Lehrstück für die Grenzen technischer Schutzsysteme. Eine perfekt gepatchte Anwendung hilft wenig, wenn ein Mitarbeiter glaubt, mit einem Kollegen oder dem internen Support zu telefonieren. Telefonnummern lassen sich fälschen, Namen und Organisationsstrukturen sind häufig öffentlich auffindbar, und durch vorherige Datenlecks können Angreifer ihre Legende mit erstaunlich vielen echten Details anreichern.

Den größten direkt bezifferbaren Verlust dieser Woche meldete die Kryptobörse Bitget. Am 24. September stellte das Unternehmen unautorisierte Transfers aus Teilen seiner Hot- und Warm-Wallet-Infrastruktur fest. Die erste Schätzung belief sich auf rund 351,6 Millionen US-Dollar. Cold Wallets seien nicht betroffen gewesen. Bitget setzte Auszahlungen zunächst aus und schaltete Strafverfolgungsbehörden sowie Unternehmen für Blockchain-Analyse ein. Einen Tag später korrigierte Bitget die Summe auf ungefähr 387,5 Millionen US-Dollar. Dabei handelte es sich laut Unternehmen nicht um einen zweiten Angriff. Nachträglich identifizierte weitere Assets auf Zcash und Tron erhöhten lediglich die Bewertung des bereits bekannten Abflusses. Unter den betroffenen Beständen befanden sich verschiedene Kryptowährungen und Token, darunter XRP, ETH, USDT, ZEC, USDC, XAUt, BNB, AVAX und TRX. Bitget erklärte außerdem, den technischen Angriffsweg identifiziert und die zugrunde liegende Schwachstelle behoben zu haben. Mandiant und SlowMist seien in die Untersuchungen eingebunden. Nutzerbestände sollen nach Angaben des Unternehmens über den eigenen Schutzfonds gedeckt werden.

Zur möglichen Herkunft des Angriffs äußerte sich Bitget deutlich vorsichtiger als manche Schlagzeile. Der CEO erklärte, Angriffsmethoden, IP-Infrastruktur und Blockchain-Verhalten wiesen starke Ähnlichkeiten mit bekannten nordkoreanischen Gruppen auf. Öffentlich belastbare Beweise oder die Benennung einer konkreten Gruppe legte Bitget zunächst jedoch nicht vor. Eine nordkoreanische Urheberschaft ist damit eine Attribution des Unternehmens, keine unabhängig gesicherte Tatsache. Im klassischen Sinne ist dies kein Datenleck, dennoch gehört der Fall in den LeakWatch. Bei Kryptowährungen sind die unmittelbar exfiltrierten Werte eben keine Datenbankzeilen, sondern Assets. Die zugrunde liegende Sicherheitsfrage bleibt dieselbe: Wie weit kann ein kompromittierter operativer Zugriff reichen, bevor eine zweite Kontrollinstanz eingreift?

Der schwedische Fall Miljödata ist zeitlich anders einzuordnen. Der eigentliche Cyberangriff ereignete sich bereits im August 2025. Neu in dieser Woche ist die Entscheidung der schwedischen Datenschutzbehörde IMY, gegen den Softwareanbieter ein Bußgeld von 1,8 Millionen schwedischen Kronen zu verhängen. Miljödata entwickelt HR- und Verwaltungssoftware, die von zahlreichen schwedischen Kommunen und anderen öffentlichen Einrichtungen eingesetzt wird. Beim damaligen Angriff wurden nach Angaben des Unternehmens Daten von etwa 2,2 Millionen Menschen betroffen. Teile davon landeten später im Darknet. Zum Datenbestand gehörten unter anderem schwedische Personenkennziffern, Kontaktinformationen sowie besonders sensible Angaben zu Krankheitsabwesenheiten, Rehabilitationsmaßnahmen und Vorfällen aus dem schulischen Umfeld.

Die Datenschutzbehörde kam nun zu dem Ergebnis, dass Miljödata vor und zum Zeitpunkt des Angriffs keine angemessenen technischen und organisatorischen Sicherheitsmaßnahmen im Sinne von Artikel 32 Absatz 1 DSGVO umgesetzt hatte. Nach ergänzenden Berichten gehörten zu den bemängelten Punkten unter anderem unzureichende Kontrollen bei der Installation neuer Software sowie fehlende automatisierte Echtzeitüberwachung auf ungewöhnliche Aktivitäten. Der Fall zeigt, warum ein Leak mit der Veröffentlichung gestohlener Daten keineswegs abgeschlossen ist. Ermittlungen, Benachrichtigungen, Rechtsstreitigkeiten und Datenschutzverfahren können sich über Monate oder Jahre hinziehen. Für Unternehmen kommt damit zum unmittelbaren technischen Schaden ein langfristiges regulatorisches Risiko hinzu.

Zum Abschluss noch ein Fall, bei dem gerade das Ausbleiben eines bestätigten Einbruchs erwähnenswert ist. Kiteworks forderte Kunden am 25. September zu einer vorsorglichen Abschaltung bestimmter Systeme auf. Grundlage seien glaubwürdige Bedrohungsinformationen von staatlichen Nachrichtendienststellen gewesen. Selbst betriebene Installationen, darunter On-Premises-, AWS- und Azure-Systeme, sollten innerhalb eines definierten Zeitfensters heruntergefahren werden. Für gehostete Umgebungen übernahm Kiteworks die Maßnahme selbst. Kiteworks erklärte ausdrücklich, es gebe derzeit keine Hinweise darauf, dass eigene Systeme oder Kundensysteme tatsächlich kompromittiert worden seien. Alle bekannten Schwachstellen seien in der aktuellen Version 9.5.1 behoben. Die Abschaltung war somit eine präventive Maßnahme.

In Kundeninformationen war zusätzlich von einem möglichen bislang unbekannten Angriffsweg die Rede. Gegenüber BleepingComputer wurde als Zweck der Maßnahme der Schutz vor einem potenziellen Zero-Day-Szenario genannt. Daraus lässt sich allerdings nicht ableiten, dass eine konkrete Zero-Day-Lücke tatsächlich entdeckt oder bereits aktiv ausgenutzt wurde. Eine solche Bestätigung hat Kiteworks bislang nicht veröffentlicht. Dass ein Anbieter von Secure-File-Transfer- und Datenübertragungslösungen lieber für mehrere Stunden abschaltet, als ein unbekanntes Risiko weiterlaufen zu lassen, ist durchaus bemerkenswert. Gerade diese Produktklasse war in den vergangenen Jahren wiederholt Ziel hochwirksamer Angriffe, weil ein einzelner erfolgreicher Exploit Zugang zu den Daten zahlreicher Unternehmen eröffnen kann. Diesmal lautet die wichtige Meldung deshalb nicht, dass Kiteworks gehackt wurde. Die Meldung lautet, dass ein Hersteller aufgrund konkreter Bedrohungsinformationen bereit war, Verfügbarkeit gegen Sicherheit einzutauschen. Ob diese Vorsichtsmaßnahme einen realen Angriff verhindert hat oder sich die Warnung als übervorsichtig erweist, lässt sich derzeit nicht beurteilen.

Die auffälligste Gemeinsamkeit der KW 39 ist nicht eine bestimmte Malware oder eine neue CVE. Es ist der Missbrauch von Vertrauen. Bei BigCommerce war es ein kompromittierter API-Zugang eines Drittanbieters. Bei Astrana Health waren es vermeintlich bekannte Mitarbeiter und eine gefälschte Telefonnummer. Beim FBI könnte ein öffentlich erreichbares HR-System die Brücke zu besonders sensiblen personenbezogenen Daten gebildet haben. Beim australischen Medicare-Portal zeigt ein autonom arbeitender Agent, dass auch maschinelle Nutzer mittlerweile selbstständig Pfade finden können, die bei der ursprünglichen Zugriffskontrolle möglicherweise nie berücksichtigt wurden. Bei Bitget lag ein Teil des Risikos zwangsläufig darin, dass Hot und Warm Wallets für den laufenden Betrieb verfügbar bleiben müssen. Genau darin liegt das zunehmende Problem moderner IT-Sicherheit. Die Systeme funktionieren nicht trotz dieser Vertrauensbeziehungen, sondern wegen ihnen. Shops benötigen Erweiterungen, Unternehmen benötigen Remote-Zugänge, Mitarbeiter benötigen HR-Portale, Finanzplattformen benötigen online verfügbare Wallets und moderne Anwendungen benötigen APIs. Man kann diese Verbindungen nicht einfach abschalten.

Entsprechend gewinnt die Frage an Bedeutung, wie stark jeder einzelne Vertrauenspfad begrenzt wird. Ein kompromittiertes API-Token sollte nicht beliebigen Scriptcode ausrollen können. Ein erfolgreicher Login sollte nicht automatisch Zugriff auf sämtliche nachgelagerten Systeme bedeuten. Ein Agent sollte nicht allein deshalb auf eine Ressource zugreifen dürfen, weil er deren Adresse findet. Und ein Mitarbeiter sollte einen kritischen Zugriffsprozess nicht allein aufgrund einer angezeigten Telefonnummer freigeben können. Zero Trust klingt in Präsentationen gern nach einem weiteren Sicherheitsbegriff, die Vorfälle dieser Woche zeigen jedoch den praktischen Kern dahinter. Nicht der Benutzername, die IP-Adresse oder der Besitz eines Tokens sollte Vertrauen erzeugen, sondern jeder einzelne Zugriff muss auf seinen konkreten Zweck, seinen Umfang und seinen Kontext begrenzt werden. Genauso wichtig bleibt die Trennung zwischen bestätigtem Vorfall und Täterbehauptung. Fresenius bestätigt einen unautorisierten Zugriff, nicht den von ShinyHunters behaupteten Datenbestand. Das FBI untersucht die Kompromittierung von FBIJobs.gov, bestätigt aber noch nicht die komplette von ShinyHunters geschilderte Angriffskette. Bitget sieht Parallelen zu nordkoreanischen Angreifern, hat deren Urheberschaft aber nicht öffentlich bewiesen. Und Kiteworks hat gerade keinen bestätigten Einbruch gemeldet, sondern vorsorglich abgeschaltet. 

Diese Unterschiede mögen weniger spektakulär klingen als ein möglichst großer Leak-Titel. Für eine realistische Einschätzung des Risikos sind sie aber entscheidend. Gerade in einer Woche, in der Vertrauen selbst zum bevorzugten Angriffsvektor wird, sollte man zumindest bei den Fakten nicht mehr Vertrauen verteilen, als die vorhandenen Belege rechtfertigen.

Was ist LeakWatch?
Im Rahmen dieses redaktionellen Projekts wird ein eigens progranmmierter und trainierter Bot zur speziellen Internet-Recherche des Autors genutzt, der die automatisierte Analyse relevanter Datenquellen übernimmt und gleichzeitig Übersetzungen erstellt. Ziel ist die Verwendung möglichst unverfälschter Primärquellen, weshalb sämtliche Links tabellarisch erfasst werden, um eine optionale vertiefende Recherche durch den interessierten Leser zu ermöglichen. Die automatisierte Suche und Extraktion wäre ohne KI-Unterstützung nur mit unverhältnismäßigem Aufwand realisierbar, dennoch erfolgen jede Auswertung und die eigentliche Texterstellung redaktionell und es wird zudem alles inhaltlich noch einmal geprüft, da die KI nicht alle Inhalte vollständig zuverlässig interpretieren oder formulieren kann. LeakWatch ist als periodisch erscheinendes Sicherheits- und Leak-Analyseformat konzipiert, das im Stil von igor’sLAB und unter Anwendung konkreter Vorgaben erstellt wird. Der Fokus liegt auf nachprüfbaren Ereignissen aus Primärquellen, technischer Einordnung und vollständig neutraler Bewertung ohne den Einfluss von bereits gefilterten Sekundärinformationen Dritter.