Am 19. Juli 2024 kam es bei CrowdStrike, einem globalen Cybersicherheitsunternehmen, zu einem schweren Ausfall, der durch ein fehlerhaftes Software-Update verursacht wurde. Dieser Incident betraf Millionen von Windows-Rechnern in zahlreichen Branchen, u. a. bei Transport, Verteidigung, Fertigung und Finanzen. CrowdStrike hat hierzu eine offizielle Erklärung abgegeben, aktuelle Informationen gibt es im Blog des Unternehmens. Microsoft hat ebenfalls eine Blog-Seite mit Abhilfemaßnahmen eingerichtet, die ihr euch ansehen solltet.
Der folgende Blog-Post ist für Unternehmen gedacht, die sowohl Kunden von Splunk als auch von CrowdStrike sind. Wir sagen euch, wie ihr euch Klarheit darüber verschaffen könnt, inwieweit euer Unternehmen vom CrowdStrike-Ausfall betroffen ist.
Unter dieser Prämisse möchten wir euch ein paar Erkennungen und zusätzliche Ressourcen vorstellen, mit denen besser erkennen könnt, wie sich dieses Event auf euer Unternehmen konkret auswirkt.
Splunk Security-Analysen
Diese Erkennungen sind für den Einsatz mit Splunk Enterprise Security konzipiert, der SIEM-Lösung zu unserer Plattform für einheitliche Sicherheit und Observability. Für technische Hilfestellung erreicht ihr uns über das Support-Portal.
Rechner mit fehlerhaftem Update identifizieren
Diese Suche erfordert das Splunk Add-on für CrowdStrike, das Daten aus dem Falcon Data Replicator verarbeitet. Genauere Informationen zu den Sourcetypes, die von dieser App erzeugt werden, findet ihr in der Splunk-Dokumentation.
Diese Suche identifiziert durch Abfrage der CrowdStrike-Sensor-Logs Dateidownloads des fehlerhaften CrowdStrike-Updates auf Windows-Systemen. Gesucht wird nach Events, bei denen der Zieldateiname den Substring C-00000291 enthält und auf .sys endet; dies könnte ein Hinweis auf eine fehlerhafte Update-Datei sein, speziell bei einem LFODownloadConfirmation-Event. Die Suche ist auf einen konkreten Zeitabschnitt eingeschränkt, den uns CrowdStrike mitgeteilt hat.
index=* sourcetype="crowdstrike:events:sensor" TargetFileName="*C-00000291*.sys*" event_simpleName=LFODownloadConfirmation event_platform=Win earliest=1721362140 latest=1721366820 | stats count min(_time) as firstTime max(_time) as lastTime by aid aip event_simpleName event_platform TargetFileName DownloadPath | rename aid as device_id, aip as src_ip , TargetFileName as file_name | convert timeformat="%Y-%m-%dT%H:%M:%S" ctime(firstTime) | convert timeformat="%Y-%m-%dT%H:%M:%S" ctime(lastTime)
Log-Beispiel für sourcetype="crowdstrike:events:sensor"
{
"event_simpleName": "LFODownloadConfirmation",
"ConfigStateHash": "3600681180",
"aip": "18.82.155.193",
"DownloadServer": "lfodown01-b.cloudsink.net",
"DownloadPath":
"metahash+/cfs/channelfiles/0000000291/bd9a5c40318869df823085f4449d4c9a/C-00000291-00000000-00000032.sys",
"DownloadPort": "443",
"ConfigBuild": "1007.3.0018408.1",
"event_platform": "Win",
"Entitlements": "15",
"name": "LFODownloadConfirmationV1",
"EventOrigin": "17",
"CompletionEventId": "Event_ChannelDataDownloadCompleteV1",
"id": "3aab720a-f12d-139d-883c-693105c5a42c",
"EffectiveTransmissionClass": "0",
"aid": "69483d8c3f0bb47758126f30921102e8",
"timestamp": "1721366804209",
"cid": "bd9a5c40318869df823085f4449d4c9a",
"TargetFileName": "C-00000291-00000000-00000032.sys"
}
Diese Daten stammen aus einer realen Produktionsumgebung. Aus Sicherheitsgründen haben wir die Felder aip, id und cid sowie den cid-Wert im Feld DownloadPath anonymisiert.
Rechner identifizieren, die noch keinen Kontakt zu CrowdStrike hatten
Diese Suche erfordert das Splunk-Add-on für CrowdStrike Falcon und das Splunk-Add-on für CrowdStrike-Geräte.
Diese Suche identifiziert Windows-Rechner, die ohne Kontakt zu CrowdStrike geblieben sind; anhand der Daten aus der Lookup-Tabelle crowdstrike_devices wird aus dem Datum des Ausfalls July 19, 2024, 04:09:00 UTC das Delta des Zeitpunkts berechnet, an dem die Geräte zuletzt gesehen wurden.
| inputlookup crowdstrike_devices | rex field="category" "os_name: (?[^\|]+)" | rex field="category" "dvc_type: (?[^\|]+)" | rex field="category" "cs_last_seen: (?[^\|]+)" | eval cs_last_seen=strptime(cs_last_seen, "%x %T %Z"), current_time=now(), delta=abs(cs_last_seen - current_time) | where match(os, "(?i)windows") AND cs_last_seen>=1721362140 AND cs_last_seen<=1721366820 | convert timeformat="%x %T %Z" ctime(cs_last_seen) ctime(current_time) | eval delta_days=floor(delta/86400), delta_hours=floor((delta%86400)/3600), delta_minutes=floor((delta%3600)/60), last_checked_in=mvappend(delta_days."d", delta_hours."h", delta_minutes."m") | eval last_seen=mvjoin(last_checked_in, " ") | rename nt_host as host, cs_last_seen as last_seen_by_crowdstrike | table host, mac, ip, os, dvc_type, city, country, last_seen_by_crowdstrike, last_seen | sort - delta
Weitere Apps und Ressourcen zum Tracking von Host-Check-ins
Zusätzlich zu diesen Erkennungen gibt es eine Reihe von Apps, die Mitglieder der Splunk-Community entwickelt haben, sowie (englischsprachige) Fachbeiträge, die euch beim Tracking von Host-Check-ins helfen können, was bei diesem Szenario besonders nützlich ist.
Splunkbase-Apps der Community
Fachbeiträge und Dokumentation
- Splunk Docs: Monitoring Console
- Splunk Docs: Deployment Server
- Lantern-Beitrag: Hosts logging data in a certain timeframe
- Beitrag von Duane Waddle: Proving a Negative
Zusammenfassung
Wir stellen diese Security-Inhalte bereit, damit unsere Splunk-Kundschaft sich Klarheit darüber verschaffen kann, inwieweit ihr Unternehmen vom CrowdStrike-Ausfall betroffen ist. Darin zeigt sich auch, ebenso wie in den Reaktionen der gesamten Community – durch Informationsaustausch, Bereitstellung von Lösungen und die Unterstützung betroffener Unternehmen –, die Stärke unserer Branche im Angesicht unerwarteter Herausforderungen.
Das CrowdStrike-Ereignis ist zwar als Warnung vor den Risiken von Software-Updates zu verstehen – insbesondere bei Produkten, die Agenten installieren –, es macht aber auch die prinzipiellen Vorteile automatischer Update-Prozesse für die Aufrechterhaltung robuster Sicherheitsvorkehrungen deutlich.
Mit Blick auf die Zukunft ist zu sagen, dass dieser Incident wohl dazu führen wird, dass die Update-Bereitstellung und die Prozesse der Qualitätskontrolle weiter verbessert werden. Der Vorfall macht überdeutlich, wie wichtig es ist, dass Unternehmen solide Incident-Reaktionspläne vorliegen haben – und wie wertvoll die gemeinschaftliche Zusammenarbeit der Community im Umgang mit Cybersicherheitsproblemen ist.
Autoren
Bedanken möchten wir uns bei Kevin Jarvis, Jonathan Heckinger, Emmanuel Jamison, Lou Stella, Bhavin Patel, Rod Soto, Eric McGinnis, Tyne Darke, Anne Ortel und Jose Hernandez, die diesen Beitrag verfasst haben, außerdem bei Zachary Christensen, der uns gezeigt hat, wie sich Rechner identifizieren lassen, die sich noch nicht bei CrowdStrike gemeldet haben.
