Digitale Resilienz beginnt beim Menschen – und endet nicht bei der IT

Ein CAPTCHA soll legitime Nutzer von automatisierten Zugriffen unterscheiden. Es begegnet uns beim Einkaufen, beim Anmelden und beim Öffnen einer Webseite. Gerade diese Vertrautheit macht ein manipuliertes Fake-Captcha so wirkungsvoll: Ein Symbol für Sicherheit wird selbst zum Instrument des Social Engineering. Wer die vermeintliche Prüfung durchführt, glaubt zunächst, etwas Richtiges zu tun.

Dieser Mechanismus ist für die aktuelle Diskussion über den Cyberangriff auf Berlin relevant. Die Evidenzgrenze gehört jedoch an den Anfang: Es bestehen Hinweise auf einen Zusammenhang mit der TerminalFix-/ClickFix-Kampagne. Der konkrete Initialzugang des Berliner Vorfalls ist öffentlich bislang nicht abschließend bestätigt. Das BSI stellt in seiner öffentlichen Mitteilung einen Bezug zwischen Erkenntnissen aus der Berliner Vorfallbearbeitung und seinem TerminalFix-Hinweis her, nennt aber keine weiteren Details laufender Vorfälle.

Der Fall ist deshalb kein Anlass, vorschnell eine Person oder einen Klick zur Ursache zu erklären. Er ist ein Anlass, digitale Resilienz umfassender zu betrachten: vom Umgang mit Täuschung über technische Begrenzung bis zur Frage, wie eine Organisation nach einem Datenabfluss wieder zu belastbaren Entscheidungen kommt. Diese Verbindung ist der Gegenstand dieser Einordnung; eine forensische Rekonstruktion des Berliner Angriffs ist sie nicht.

Für ein belastbares Lagebild müssen Ereignis, Quelle und Bewertung getrennt bleiben. Eine offizielle Veröffentlichung bestätigt zunächst das, was die zuständige Stelle zu diesem Zeitpunkt mitteilt. Sie beantwortet nicht automatisch jede Frage nach Ursache, Umfang und möglichen Folgen.

1. 01
   7.–12. August · offiziell berichtet

   Die Berliner Datenschutzbeauftragte nennt diesen Zeitraum für den Angriff mit erheblichem Datenabfluss. Betroffen sind Bereiche der Senatsverwaltungen für Stadtentwicklung, Bauen und Wohnen sowie für Mobilität, Verkehr, Klimaschutz und Umwelt.

2. 02
   5. September · offiziell bestätigt

   Nach der Datenveröffentlichung meldet die Senatskanzlei eine zusätzliche Steuerungseinheit unter CDO-Leitung. Die forensische Aufarbeitung läuft weiter.

3. 03
   6. September · offiziell bestätigt

   Das Land bestätigt ein weiteres veröffentlichtes Datenpaket, darunter Zugangsdaten. Schutzmaßnahmen wurden nachgeschärft; dadurch können Fachverfahren der Bauverwaltung kurzfristig eingeschränkt sein.

4. 04
   7. September · Bewertung bleibt offen

   Die Datenschutzbeauftragte weist weiterhin auf die laufende Prüfung des Ausmaßes hin. Eine individuelle Betroffenheit lässt sich nicht pauschal aus der Veröffentlichung ableiten.

Microsoft beschreibt TerminalFix als ClickFix-Variante: Kompromittierte Webseiten zeigen eine nachgeahmte CAPTCHA-Prüfung. Die Täuschung bringt Besucher dazu, einen von der Seite vorbereiteten Inhalt zu übernehmen und außerhalb des Browsers auszuführen. Klassische ClickFix-Varianten nutzen dafür etwa eine Windows-Funktion, TerminalFix lenkt gezielt zur Kommandozeile. So kann der Nutzer unbeabsichtigt Schadcode starten.

Das sicherheitsrelevante Muster lässt sich ohne Befehle oder technische Nachbauanleitung verstehen. Eine Webseite beansprucht Autorität, setzt eine angeblich notwendige Sicherheitsprüfung vor den gewünschten Inhalt und fordert eine ungewöhnliche Handlung. Die vertraute Gestaltung soll den Bruch zwischen dem Besuch einer Seite und dem Ausführen einer Systemanweisung verdecken.

Technisch ausgefeilte Angriffe benötigen nicht zwangsläufig eine technisch ausgefeilte erste Interaktion. Vertrauen, Gewohnheit und Zeitdruck können genügen, um eine Handlung plausibel erscheinen zu lassen. Der Mensch wird dabei nicht zufällig Teil der Angriffskette. Seine Bereitschaft, ein vermeintliches Problem zu lösen, wird gezielt instrumentalisiert.

Die von Microsoft untersuchte Kampagne ermöglicht einen weitergehenden Zugang ins interne Netz. Microsoft trennt dabei beobachtete Fähigkeiten von möglichen Folgehandlungen: In der untersuchten Kette hat Microsoft keinen nachfolgenden Datenabfluss oder Ransomware-Einsatz beobachtet. Auch diese Unterscheidung darf bei der Übertragung auf Berlin nicht verloren gehen.

Menschen handeln unter Zeitdruck, wollen Arbeitsaufträge erledigen und begegnen ständig Sicherheitsdialogen. Gleichzeitig können Täuschungen professionell gestaltet sein. Human Risk bezeichnet in diesem Zusammenhang Risiken an der Schnittstelle von Verhalten, Arbeitsbedingungen und Sicherheitsprozessen. Es ist kein Etikett für vermeintlich ungeeignete Beschäftigte.

Die entscheidende Frage lautet deshalb: Warum konnte ein einzelner menschlicher Fehler, sofern er tatsächlich der Einstiegspunkt war, eine weitreichende technische und organisatorische Wirkung entfalten? Diese Frage muss eine Untersuchung offen beantworten. Sie setzt weder einen Fehler noch bestimmte Versäumnisse in Berlin als Tatsache voraus.

Der Mensch kann ein Angriffspunkt sein. Er darf aber nicht die letzte Verteidigungslinie sein. Awareness unterstützt das Erkennen verdächtiger Situationen. Technische Ausführungsbeschränkungen und Endpoint-Schutz müssen riskante Handlungen zusätzlich begrenzen. Least Privilege bedeutet, Zugriffe auf das tatsächlich Erforderliche zu beschränken. Segmentierung soll verhindern, dass ein kompromittierter Arbeitsplatz automatisch den Weg in weitere Bereiche eröffnet.

Detection muss ungewöhnliche Vorgänge sichtbar machen; vorbereitete Incident Response muss darauf reagieren können. Ebenso wichtig sind verständliche Meldewege. Wer einen Verdacht ohne Angst vor Bloßstellung melden kann, hilft der Organisation, schneller zu handeln. Eine Meldung nach einer bereits erfolgten Handlung kann besonders wertvoll sein. Das Sicherheitsmodell muss dafür Raum schaffen.

Eine fehlertolerante Architektur verbindet diese Ebenen. Keine einzelne Kontrolle ist ein Versprechen vollständiger Sicherheit. Entscheidend ist, dass die Schwäche einer Ebene durch andere aufgefangen wird und Hinweise tatsächlich eine Reaktion auslösen.

Dass mich dieser Aspekt besonders beschäftigt, ist kein Zufall. In meinem Vortrag beim Industrieclub Sachsen am 3. März 2026 ging es bereits um offene Daten, Social Engineering und Deepfakes. Die Unterlagen behandeln, wie öffentlich verfügbare Informationen eine Täuschung glaubwürdiger machen können, und nennen Sensibilisierung, Schulung sowie die unabhängige Überprüfung ungewöhnlicher Anforderungen als Gegenmaßnahmen.

Daraus lässt sich kein rückwirkender TerminalFix-Bezug ableiten. Die Verbindung liegt im Grundprinzip: Wer Namen, Rollen, Arbeitsbeziehungen oder laufende Projekte kennt, kann eine vermeintliche Anfrage passend gestalten. Verifikation bedeutet dann, nicht nur das Erscheinungsbild zu prüfen, sondern den behaupteten Auftrag über einen unabhängig bekannten offiziellen Kanal zu bestätigen.

Diese Perspektive prägt meine Security-Awareness-Formate, Vorträge und Workshops. Die fachliche Konsequenz daraus reicht über Schulung hinaus: Awareness ist keine jährliche Pflichtunterweisung. Sie ist ein Bestandteil operativer Sicherheitsarchitektur. Beschäftigte brauchen geübte Routinen, erreichbare Ansprechpartner und die tatsächliche Möglichkeit, eine ungewöhnliche Anforderung zu unterbrechen. Digitale Sicherheit verbindet Mensch, Information und Technik.

Nach einem Datenabfluss und einer Veröffentlichung erweitert sich die Aufgabe. Die technische Untersuchung bleibt notwendig. Gleichzeitig muss geklärt werden, welche Informationen außerhalb der Organisation verfügbar sind, welche Schutzgüter betroffen sein könnten und welche Folgerisiken daraus entstehen. Die Wiederherstellung von IT-Systemen und die Wiederherstellung von Entscheidungsfähigkeit sind zwei unterschiedliche Aufgaben.

Digital Exposure umfasst mehr als öffentlich auffindbare Einzelangaben. Entscheidend ist auch deren Verknüpfbarkeit. Eine Rolle, eine Kontaktbeziehung und ein interner Vorgang können zusammen eine überzeugende Täuschung ermöglichen. Nach einem Leak muss deshalb neu bewertet werden, welche vorhandenen offenen Informationen durch zusätzliche Daten eine andere Bedeutung erhalten. Diesen Zusammenhang erläutert auch mein Insight zu Digital Exposure und glaubwürdigen Angriffswegen.

Das BSI warnt im Kontext des Berliner Vorfalls vor Folgeangriffen mit gestohlenen Informationen sowie vor möglichen Hack-and-Leak-Operationen und Desinformation. Daraus folgt keine belegte politische Motivation des konkreten Angriffs. Es beschreibt einen Risikoraum, den verantwortliche Stellen berücksichtigen müssen.

Für die Bewertung stellen sich mehrere Fragen gleichzeitig: Was ist echt, vollständig und aktuell? Was ist sicherheitskritisch? Welche Personen oder Organisationen müssen informiert werden? Welche Informationen benötigen andere Ressorts, welche benötigt Führung? Ein authentisches Dokument kann zudem mit einer falschen Behauptung über seinen Kontext verbreitet werden. Verifikation prüft deshalb nicht nur die Datei, sondern auch die Aussage, die daraus gemacht wird.

OSINT kann die öffentlich sichtbare Verbreitung und Einordnung solcher Behauptungen unterstützen. Eine fachliche Analyse muss dafür keine gestohlenen personenbezogenen Daten erneut veröffentlichen. Betroffenheit und konkrete Schutzmaßnahmen gehören in die dafür vorgesehenen, geschützten Arbeitsprozesse.

Incident Response konzentriert sich unter anderem auf die betroffenen Systeme, die technische Untersuchung, die Eindämmung und die sichere Wiederherstellung. Information Resilience fragt zusätzlich, ob eine Organisation Informationen prüfen, priorisieren und zu einer gemeinsamen Lage zusammenführen kann. Beide Aufgaben laufen ineinander und können zeitgleich erforderlich sein.

Die Gegenüberstellung beschreibt Schwerpunkte, keine harten Zuständigkeitsgrenzen: Auch Incident Response braucht Koordination und Kommunikation. Die zusätzliche Perspektive verhindert, dass die Informationsfolgen eines Vorfalls zwischen technischen, fachlichen und kommunikativen Verantwortlichkeiten liegen bleiben.

Decision Support bedeutet, Führung rechtzeitig mit dem entscheidungsrelevanten Ausschnitt zu versorgen. Ein hilfreiches Briefing zeigt bestätigte Erkenntnisse, verbleibende Unsicherheit, betroffene Schutzgüter, Handlungsoptionen und den nächsten Prüfzeitpunkt. Es macht sichtbar, welche Entscheidung jetzt ansteht und welche von weiterer Verifikation abhängt. Ein umfangreicher Datenbestand allein leistet das noch nicht.

Am 25. März 2026 habe ich in einem Grobkonzept und einem Impulspapier den Ansatz eines Berlin Information Resilience Center, kurz BIRC, beschrieben. Der damalige Ausgangspunkt war ein anderer: Desinformation, Deepfakes, hybride Informationsangriffe und digitale Einflussoperationen, insbesondere mit Blick auf die Wahlen 2026.

Der Vorschlag sah eine strategische Verankerung in der Senatskanzlei, eine enge Anbindung an den CDO-Bereich und das Presse- und Informationsamt sowie Schnittstellen zu Inneres, Landeswahlamt, Polizei, Verfassungsschutz, ITDZ beziehungsweise IT-Strukturen und Bezirken vor. Der Kern war eine gemeinsame Arbeitslogik: erkennen, bewerten, verifizieren, priorisieren, die Lage einordnen und Kommunikation sowie Entscheidungen vorbereiten.

BIRC war keine Cyberabwehr- oder Incident-Response-Einheit. Es war als ergänzende Fähigkeit für digitale Informationslagen gedacht. Aus diesem Ansatz lässt sich weder ableiten, dass er den aktuellen Angriff verhindert hätte, noch dass die heute eingerichteten Strukturen darauf zurückgehen. Der übertragbare Gedanke ist die Informationsverdichtung über Zuständigkeitsgrenzen hinweg. Er gehört auch zum Aufbau belastbarer OSINT- und Analysefähigkeiten im Advisory.

Die Senatskanzlei beschreibt am 5. September eine zusätzliche zentrale Steuerung unter Leitung von Florian Hauer. Sie koordiniert die Prüfung des Datenbestands und unterstützt die betroffenen Verwaltungen. Eingebunden sind unter anderem LKA, Datenschutzbehörde und Informationssicherheitsverantwortliche. Die Bewertung erfolgt nach Risiko; relevante Erkenntnisse sollen die zuständigen Stellen erreichen. Bestehende Ermittlungs- und Krisenstrukturen arbeiten weiter.

Interessant ist daran ein Organisationsprinzip: Sobald eine digitale Krise mehrere Ressorts, Schutzgüter und Verantwortungsbereiche betrifft, braucht es zusätzlich zur Facharbeit eine gemeinsame Bewertungs- und Entscheidungsebene. Die folgende Gegenüberstellung ist meine analytische Einordnung der beiden unterschiedlich begründeten Ansätze.

Für die Praxis lässt sich die Verbindung in fünf Ebenen darstellen. Das ist ein eigenes Orientierungsmodell, kein zertifizierter Standard und keine nachgewiesene Chronologie des Berliner Vorfalls. Es führt vom menschlichen Umgang mit Täuschung über technische Schutzwirkung zur organisatorischen Entscheidungsfähigkeit.

Die Ebenen müssen zusammenarbeiten. Ein Hinweis aus der Datenbewertung kann neue technische Schutzmaßnahmen auslösen. Eine technische Feststellung kann die Kommunikationslage verändern. Eine Entscheidung kann weitere Verifikation erforderlich machen. Die dargestellte Richtung hilft beim Verständnis; in einer realen Krise entstehen Rückkopplungen und parallele Aufgaben.

Die folgenden Lehren sind übertragbare Gestaltungsfragen. Sie unterstellen keine konkreten Defizite in Berlin. Sinnvoll werden sie, wenn Organisationen sie vor einem Vorfall mit den jeweils Verantwortlichen durchgehen und in Übungen überprüfen.

1. 01
   Aktuelle Täuschungen trainieren

   Realistische Szenarien sollten auch vermeintliche Sicherheitsprüfungen und ungewöhnliche IT-Anweisungen umfassen. Trainiert wird die sichere Reaktion, nicht das Auswendiglernen einzelner Angriffsbezeichnungen.

2. 02
   Awareness mit Schutzmechanismen verbinden

   Eine Schulung ersetzt keine technischen Kontrollen. Zuständigkeiten müssen klar machen, wer erkannte Risiken in konkrete Schutzmaßnahmen übersetzt und deren Wirksamkeit überprüft.

3. 03
   Fehler auffangen können

   Berechtigungen, Endpoint-Schutz, Segmentierung und Detection sollten zusammenspielen. Die zentrale Übungsfrage lautet: Was geschieht, wenn eine Täuschung trotz aller Vorbereitung erfolgreich ist?

4. 04
   Digital Exposure kennen

   Prüfen, welche öffentlich sichtbaren Informationen glaubwürdige Angriffsansätze ermöglichen. Nach einem Datenabfluss die Bewertung aktualisieren und besonders relevante Kombinationen von Informationen berücksichtigen.

5. 05
   Krisenorganisation vorbereiten

   IT, Fachbereiche, Datenschutz, Kommunikation und Führung benötigen vereinbarte Kontakte und Übergaben. Meldewege müssen auch unter Zeitdruck funktionieren und Stellvertretungen einschließen.

6. 06
   Informationsbewertung verantwortlich zuordnen

   Festlegen, wer Herkunft, Aktualität und Relevanz einer Information prüft. Ein zentraler Eingang allein genügt nicht, wenn niemand über Bearbeitung und Weitergabe entscheidet.

7. 07
   Verifikation und Priorisierung verbinden

   Bestätigung, Hinweis und Hypothese sichtbar trennen. Nach möglichen Auswirkungen auf Schutzgüter priorisieren und offenhalten, welche neuen Erkenntnisse eine Bewertung verändern würden.

8. 08
   Ein gemeinsames Lagebild ermöglichen

   Fachliche Beiträge in einer nachvollziehbaren, zeitlich gekennzeichneten Übersicht zusammenführen. Dabei nur die Informationen weitergeben, die Empfänger für ihre Aufgabe tatsächlich benötigen.

9. 09
   Führung rechtzeitig entscheidungsfähig machen

   Kurze Briefings sollten Optionen, Verantwortliche und offene Fragen benennen. Nicht auf vollständige Gewissheit warten, wenn bereits begründete Schutzmaßnahmen entschieden werden können.

Moderne Cyberangriffe machen sichtbar, wie eng menschliches Vertrauen, technische Systeme und Informationsräume verbunden sind. Ein Social-Engineering-Moment kann am Anfang stehen. Darauf können technische Kompromittierung, Ausbreitung und Datenabfluss folgen. Mit einer Veröffentlichung entsteht zusätzlich eine Informationslage, die weit über den Betrieb einzelner Systeme hinausreicht. Diese mögliche Kette ist ein Denkmodell, keine bestätigte Ablaufbeschreibung für Berlin.

Für Organisationen bedeutet Resilienz deshalb, Fehler erkennen, begrenzen und beherrschen zu können und in der anschließenden Krise Entscheidungsfähigkeit zu erhalten. Genau deshalb beschäftige ich mich mit Social Engineering, offenen Informationen, Verifikation und Lageprozessen gemeinsam. Die Qualität einer Sicherheitsarchitektur zeigt sich nicht nur darin, wie viele Fehler sie verhindert, sondern auch darin, wie gut sie einen unvermeidbaren Fehler auffängt.