CrowdStrike & BSOD – Erfahrungsbericht

Ereignisse wie die CrowdStrike-Panne, ein schlechter Security Patch oder auch der Ausfall eines Cloud-Systems können schlagartig zu einem echten Desaster für eure Firmen werden. Daher sind Desaster-Recovery-Prozesse, verlässliche Systeme und gut ausgebildete Mitarbeiter wichtig.

Wir haben mit einem Mitarbeiter eines betroffenen Kunden gesprochen, um zu erfahren, wie er diese Situation erlebt hat und welche Schlüsse er daraus zieht.

59s: Wie habt ihr festgestellt, dass eure IT Infrastruktur nicht lief?

Kunde: Ich wurde am Freitagmorgen gegen 07:30 direkt angerufen, mit der Information, dass alle Clients und Server ein Blue Screen Of Death (BSOD) haben. Ohne weitere Informationen war die Vermutung erst einmal „Cyberangriff“ oder MS-Patches. Wobei Patches nicht freigegeben werden, ohne diese vorher zu testen. Vor Ort stellte sich heraus, dass der BSOD auf den Clients und Servern als Fehlerursache die Datei csagent.sys anzeigte.  Bei jedem Neustarten der Geräte crasht das System kurz nachdem der Login-Bildschirm zu sehen war.

59s: Wie habt ihr intern das Troubleshooting koordiniert?

Kunde: Unser Management hatte eine Krisensitzung gestartet, während wir (IT) ungestört anfangen konnten, uns dem Problem zu widmen. Einige der Windows 10/11 Clients liefen noch, weil diese ausgeschaltet waren oder sich noch den Fix von CrowdStrike ziehen konnten.
Der Servicedesk informierte die ersten Anrufer. Später wurde eine Ansage geschaltet, um einen Überlauf beim Servicedesk zu verhindern.

Zu diesem Zeitpunkt gab es bei CrowdStrike keine Informationen oder Hinweise, die unsere Vermutung bestätigten, dass der CrowdStrike-Agent den BSOD verursacht hat.

Zuerst dachten wir, wir wurden Opfer eines Cyberangriffs, aber dann fanden wir schnell auf Subreddits (https://www.reddit.com) wie „r/crowdstrike“ oder „r/sysadmin„, dass andere Kunden, die von dem Problem ebenfalls betroffen waren. Spannend fanden wir, dass Beiträge auf „r/crowdstrike“ teilweise wieder gelöscht wurden.

Um 8:02 Uhr hatten wir versucht, Kontakt mit CrowdStrike aufzubauen. Leider erhielten wir erst nach einer gefühlten Ewigkeit eine Rückmeldung um 08:51 Uhr. In der Internet-Community Reddit hatten wir bereits um 8:39 Uhr die ersten Anleitungen gesehen, wie dieses Problem behoben werden kann.

Zuerst fixten wir unsere Domaincontroller. Die Azubis wurden voll mit eingespannt und kümmerten sich um die restlichen Server, während ich mich um den Ivanti EPM Core und die PXEs kümmerte. Denn ohne den Core und einen Preferred-Server Onsite, konnte kein Fix verteilt werden.

Während die Kollegen weiter machten, die Server per Hand zu fixen, arbeitete ich an einem OSD-Template um unsere Clients wieder produktiv zu bekommen.

59s: Bei der Behebung, was war da konkret die Herausforderung?

Kunde: Die Problembehebung erforderte die Durchführung mehrerer manueller Schritte direkt am Computer. Sprich neu starten, in den Recovery gelangen und die Fehlerhafte „C-00000291*.sys“ löschen. Besonders aufwändig war hierbei die Security. Denn unsre ca. 2600 Clients sind alle mit BitLocker verschlüsselt, sodass erst eine Entsperrung der Festplatte mit dem BitLocker-Key durchgeführt werden musste.

59s: Wie hat euch Ivanti bei der Problemlösung geholfen?

Kunde: Bei Server war der Fix recht einfach. Dabei habe ich mit dem Ivanti Endpoint Manager EPM ein OSD-Task erstellt, der auf jeder Festplatte nach der entsprechenden Datei sucht und löscht. Im Anschluss wurde der Server automatisch neu gestartet und funktionierte wieder. So konnten wir die restlichen ca. 200 von 400 Servern in kurzer Zeit fixen.

Bei den Clients war es durch BitLocker schwerer. Zumindest konnten wir die Computer über den EPM automatisiert in ein WinPE booten lassen. Von dort konnten die Admins die Festplatten entsperren und die Datei löschen. Somit haben wir die Endlosschleife des Reboots auf den Geräten unterbrechen können und den Admins Zeit gespart. Was uns auch gerettet hat, ist, dass der Ivanti Agent den Recovery Key sammelt. Wir benutzen noch Sophos zur Administration der BitLocker-Keys, allerdings hatten einige Clients ca. 3 % kein Recovery Key in Sophos hinterlegt. Ohne den Recovery Key im Ivanti-EPM hätten wir alle Daten auf den betroffenen Systemen verloren.

59s: Wie schnell habt ihr das Problem beheben können?

Kunde: Wir hatten 99 % unserer globalen Server um 12:00 Uhr wieder am Laufen. Pünktlich zum Mittag. Das war eine Punktlandung, da unser Kassen-System in der Kantine auch betroffen war. 🙂.
Wir haben somit ca. 3 Stunden vom Bekanntwerden des Workarounds bis zum Fixen der Server gebraucht. Alle Benutzer, die am Freitag gearbeitet hatten, waren dann wieder arbeitsfähig.

Am Folgen Montag gab es von Microsoft ein WinPE für Clients, welches automatisch startet, nachdem der BitLocker-Key fragt, dann die fehlerhafte Datei löscht und ein Neustart durchführt. Diese konnte ich dann unseren Admins fertig zur verfügung stellen.

59s: Was ist euer Fazit? 

Ohne Ivanti wäre es ein langer Tag geworden oder ein kurzes Wochenende gewesen. Es hat uns geholfen, den Workarround schneller in der Breite zur Verfügung zu stellen. Dass der EPM die BitLocker Keys ausliest, hat uns unerwartet bei einigen Computern gerettet.

Wir werden Sophos bei uns in Zukunft ablösen und die BitLocker-Keys im AD speichern und die five(9)s Console nutzen, um einfach und schnell an den Recovery Key zu kommen.

Unser Security-Team hat bald mit CrowdStrike ein Review-Meeting, indem über konkrete Konsequenzen gesprochen wird.

59s: Danke für die ausführlichen Informationen.