Zum Inhalt springen
0621 877 55 990

Das Journal des DAVINCI RechenzentrumsDonnerstag, 1. Oktober 2026139 Beiträge · 14 Ressorts

DAVINCI Journal

IT-Sicherheit & Cybersecurity

Dienstag, 2:40 Uhr: Protokoll einer Nacht, in der nichts passiert ist

Ein Maschinenbauer, siebzig Beschäftigte, ein Dateiserver, ein Dienstkonto, das plötzlich mehr will. Was in den dreißig Minuten danach geschieht – in einem Haus mit überwachter Erkennung und in einem ohne. Der Fall ist erfunden. Die Zeiten sind es nicht.

Arbeitsplatz in einem Sicherheitsleitstand mit Übersichtsanzeigen zur Angriffserkennung
Symbolbild, künstlich erzeugtStand der Angaben: Oktober 2026

Es gibt eine Art, über Angriffserkennung zu sprechen, die alles richtig sagt und nichts erklärt: Erkennung, Analyse, Reaktion, rund um die Uhr. Dieser Beitrag versucht es anders. Er nimmt eine Nacht und erzählt sie zweimal – einmal mit einem Analystenteam, einmal ohne. Der Betrieb ist erfunden, damit er sich genau beschreiben lässt. Die Abläufe und Zeiten sind es nicht: Die Reaktionszeiten nennt G DATA auf seiner Website, die Angaben zum Team stammen aus den Herstellerunterlagen, die Festlegungen aus dem Onboarding sind die, die wir mit jedem Kunden treffen.

Der Betrieb

Ein Maschinenbauer im Rhein-Neckar-Raum, siebzig Beschäftigte, zwei davon in der IT. Fünf Server tragen den Betrieb: Domänencontroller, Dateiserver, Warenwirtschaft, Konstruktionsdaten, Mail. Die Sicherung läuft nachts um ein Uhr auf ein Laufwerk, das danach getrennt wird. Beim Onboarding wurde festgelegt: Dateiserver, Mail und Domänencontroller dürfen ohne Rückfrage isoliert werden; Warenwirtschaft und Konstruktionsdaten nur nach Anruf, weil dort nachts Aufträge aus Asien einlaufen. Die Rufkette: IT-Leiter, Stellvertreter, Geschäftsführer.

Die erste Erzählung: mit Analystenteam

2:40 Uhr. Auf dem Dateiserver startet ein Prozess unter dem Dienstkonto der Sicherungssoftware und fordert höhere Rechte an. Der Agent meldet es an das Backend. Dort liegt bereits ein Ereignis von 2:31 Uhr: Dasselbe Dienstkonto hat sich interaktiv an einem Arbeitsplatz im Vertrieb angemeldet – einem Gerät, an dem seit 18 Uhr niemand getippt hat. Das Backend setzt beide Ereignisse in Beziehung und erzeugt einen Alarm. Vergangene Zeit seit dem Ereignis: unter einer Minute.

2:41 Uhr. In Bochum öffnet ein Analyst den Alarm. Erste Frage: Ist das die Sicherung? Nein, die läuft um ein Uhr und ist als Ausnahme hinterlegt; außerdem meldet sich die Sicherung nicht interaktiv an Arbeitsplätzen an. Zweite Frage: Ist das ein bekanntes Werkzeug der IT? Nein, der Prozess ist eine umbenannte Kopie eines Werkzeugs, das Zugangsdaten aus dem Arbeitsspeicher liest. Der Analyst bestätigt: Angriff, laufende Rechteausweitung, Ausgangspunkt der Arbeitsplatz im Vertrieb. Vergangene Zeit seit dem Alarm: unter drei Minuten.

2:43 Uhr. Der Dateiserver darf isoliert werden – das steht im Onboarding-Protokoll. Der Analyst trennt ihn vom Netz: Er bleibt an, erreicht aber nichts mehr und wird von nichts mehr erreicht. Der Prozess wird beendet. Der Arbeitsplatz im Vertrieb wird ebenfalls isoliert. Das Dienstkonto wird gesperrt. Dann prüft der Analyst, ob das Konto in den letzten Stunden noch anderswo aktiv war: eine Anmeldung am Domänencontroller um 2:38 Uhr, fehlgeschlagen. Der Domänencontroller wird vorsorglich isoliert; auch das ist erlaubt. Vergangene Zeit seit dem Alarm: elf Minuten.

2:50 Uhr. Das Telefon des IT-Leiters klingelt. Der Analyst nennt die Lage in vier Sätzen: Rechteausweitung vom Vertriebsarbeitsplatz aus, Dateiserver und Domänencontroller isoliert, Konto gesperrt, Warenwirtschaft und Konstruktion nicht betroffen und nicht angefasst. Empfehlung: Beide isolierten Server bis zur Prüfung am Morgen so lassen, Kennwort des Dienstkontos und aller Konten, die auf dem Vertriebsarbeitsplatz angemeldet waren, zurücksetzen. Der IT-Leiter stimmt zu und bittet, auch die Mail zu prüfen. Nichts gefunden. Er legt auf und schläft nicht mehr ein, aber er weiß, was los ist.

3:10 Uhr. Der Bericht steht in der Konsole: Zeitachse von 2:31 bis 2:50 Uhr, betroffene Systeme, ausgeführte Maßnahmen, offene Empfehlungen. Es ist das Dokument, das am Morgen die Besprechung trägt, das der Versicherer sehen will, und das – wäre der Betrieb eine erfasste Einrichtung – die Angaben für eine Meldung nach § 32 BSIG enthält.

7:30 Uhr. Die IT kommt ins Haus und weiß, was zu tun ist. Der Dateiserver wird aus der Sicherung von ein Uhr geprüft – unverändert, der Angreifer hatte sie noch nicht erreicht. Der Vertriebsarbeitsplatz wird neu aufgesetzt. Bis zehn Uhr ist der Dateiserver wieder im Netz. Die Beschäftigten haben zwei Stunden ohne Dateiablage gearbeitet. Das ist der ganze Schaden.

Die zweite Erzählung: ohne

2:40 Uhr. Derselbe Prozess, dieselbe Rechteausweitung. Der Virenschutz kennt die Datei nicht und meldet nichts. Niemand sieht die Anmeldung von 2:31 Uhr, weil niemand die Protokolle liest. Um 3:05 Uhr hat der Angreifer Domänenadministratorrechte. Um 3:20 Uhr findet er das Sicherungslaufwerk – getrennt, aber mit einem Zeitplan, der um ein Uhr verbindet. Er ändert den Zeitplan nicht; er wartet.

Das ist der Punkt, an dem die zweite Erzählung aufhört, eine Nacht zu sein. Der Angreifer hat Rechte, er hat Zeit, und er hat gelernt, wann die Sicherung verbindet. In den folgenden Wochen sammelt er Zugangsdaten, zieht Konstruktionsdaten ab und bereitet die Verschlüsselung vor. In der Nacht, in der er sie startet – vier Wochen später, einem Freitag –, verbindet sich das Sicherungslaufwerk um ein Uhr wie immer, und um 1:05 Uhr ist es leer. Um 7:30 Uhr am Samstag ruft der Pförtner den IT-Leiter an, weil die Kassenanzeige im Werkstor etwas Englisches zeigt.

Was folgt, ist aus Lageberichten des BSI bekannt und muss hier nicht ausgemalt werden: Wochen ohne Konstruktionsdaten, Warenwirtschaft aus Papier, Kunden, die Liefertermine verlieren, ein Versicherer, der nach dem Nachweis der Sicherheitsmaßnahmen fragt, und die Frage, die niemand beantworten kann: Seit wann war er drin?

Was die beiden Nächte unterscheidet

Nicht die Technik des Angreifers – sie ist dieselbe. Nicht die Größe des Betriebs. Nicht einmal die Sicherung, die in beiden Fällen lief. Der Unterschied ist, dass um 2:41 Uhr jemand hinsah, der wusste, was er sah, und etwas tun durfte, weil es vorher festgelegt war. Die Festlegungen aus dem Onboarding haben den Unterschied gemacht: Welche Server ohne Rückfrage isoliert werden dürfen, welche nicht, wer angerufen wird. Ohne sie hätte der Analyst um 2:43 Uhr fragen müssen – und um 2:43 Uhr nimmt niemand ab.

Deshalb ist die Stunde, die beim Onboarding in diese Festlegungen fließt, die wichtigste des ganzen Vertrags. Sie entscheidet, ob die erste Erzählung möglich ist.

Verwandte Themen: Wer hier weiterdenkt, liest bei Überwachung rund um die Uhr, Onboarding Angriffserkennung und Reaktionszeiten weiter.

Quellen

  1. G DATA MXDR – Managed Extended Detection and Response (Reaktionszeiten, Analystenteam) · G DATA CyberDefense AG
  2. Die Lage der IT-Sicherheit in Deutschland · Bundesamt für Sicherheit in der Informationstechnikamtlich
  3. § 32 BSIG – Meldepflichten · Bundesministerium der Justiz (gesetze-im-internet.de)amtlich

Verwandte Beiträge

Zur Titelseite →
IT-Sicherheit & Cybersecurity

„24/7“ steht in jedem Angebot. Was es bedeutet, steht in keinem

Rund um die Uhr kann heißen: Die Technik läuft durch. Es kann heißen: Ein Mensch bewertet nachts. Es kann heißen: Jemand ruft Sie an. Drei Dienste, dreimal „24/7“, drei völlig verschiedene Nächte. Woran Sie erkennen, welche Sie kaufen.

IT-Sicherheit & Cybersecurity

MTTD und MTTR: Warum zwei Anbieter mit derselben Zahl Verschiedenes verkaufen

„Reaktion in unter 30 Minuten“ – klingt vergleichbar, ist es nicht. Ob die Uhr beim Alarm oder bei der Bewertung startet, ob am Ende ein Skript oder ein Mensch gehandelt hat, ob der Mittelwert die schlechten Nächte verbirgt: Was hinter den Kennzahlen steckt und welche Fragen sie vergleichbar machen.

IT-Sicherheit & Cybersecurity

6.000 Rechner, 380 Filialen, eine Frozen Zone: Wie Thalia MXDR ausgerollt hat

Zwischen November und Januar ändert ein Buchhändler nichts an seiner IT. Thalia hat diese Zeit genutzt, um den Rollout einer überwachten Angriffserkennung auf 6.000 Rechner zu planen – und dabei ein Problem gelöst, das jedes Haus mit vielen Standorten kennt: Wie kommen Updates in die Filialen, ohne die Leitungen zu verstopfen? Nach einer von G DATA veröffentlichten Fallstudie.