GhostLock Linux: SMB-Lockout ohne Verschlüsselung erkennen

Stand: 18. Mai 2026 - zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Experte) – Six Eight Consulting, Fokus: Analyse, IAM, Security Engineering.

GhostLock ist eine unangenehme Erinnerung daran, dass Verfügbarkeit nicht erst durch Verschlüsselung verloren geht. Die Forschung beschreibt einen Lockout-Angriff gegen SMB-basierte Dateiablagen: Ein normaler Domain-User mit Zugriff auf eine Freigabe öffnet Dateien oder Verzeichnisse exklusiv. Andere Clients scheitern anschließend mit Sharing-Violations. Aus Sicht der Fachabteilung fühlt sich das an wie Ransomware, nur ohne verschlüsselte Dateien. [Research Site] [Whitepaper]

Wer nach GhostLock Linux sucht, sollte das Thema deshalb nicht als klassische Linux-Malware oder Kernel-Lücke verstehen. Relevanter sind Linux-Fileserver, Samba-basierte NAS und Appliances, die Windows-Clients per SMB bedienen. Dort entscheidet die operative Sichtbarkeit auf Sessions, offene Dateien und Locks darüber, ob ein Lockout schnell beendet werden kann.

Der wichtige Unterschied: GhostLock ist nach aktueller Einordnung keine klassische Software-Schwachstelle. Es gibt keine CVE, keinen Vendor-Patch, keine kompromittierte Bibliothek. Der Kern ist dokumentiertes Verhalten rund um CreateFileW, dwShareMode und SMB2 CREATE-Requests. Genau deshalb ist das Thema für Verteidiger spannend: Man kann es nicht einfach "wegpatchen", sondern muss Datei-Server-Betrieb, Rechte und Incident Response sauberer machen. [API Docs] [Protocol]

Kurzfazit

GhostLock ist kein klassischer Schadcode, der Dateien auf dem Server verschlüsselt. Die auf ghostlock.io beschriebene Technik nutzt legitime Windows- und SMB-Datei-Handles, um Dateien oder Verzeichnisse exklusiv offen zu halten. Bei CreateFileW mit dwShareMode = 0 kann eine Datei nicht erneut geöffnet werden, bis der Handle geschlossen ist; Microsoft dokumentiert dieses Verhalten ausdrücklich. [Research Site] [API Docs]

Ein Server-Restart kann helfen, ist aber eher Notfallmaßnahme. Besser ist: verdächtige SMB-Session identifizieren, Session oder Handles schließen, Client isolieren und danach die kompromittierten Zugangsdaten behandeln. GhostLock selbst beschreibt als Recovery, dass Storage- oder Fileserver-Admins die verursachende SMB-Session finden und terminieren müssen; danach sind die Dateien sofort wieder zugänglich, weil sie nicht verändert wurden. [Research Site]

Was GhostLock macht

GhostLock kann mit einem normalen Domain-User und Leserechten auf SMB-Shares Dateien sperren, ohne Dateien zu schreiben, umzubenennen oder zu verschlüsseln. Das macht klassische Ransomware-Detektion schwierig, weil viele Tools auf Massen-Schreibzugriffe, Dateiumbenennungen oder Verschlüsselungsmuster achten. [Research Site] [API Docs]

Die wichtigste Spur ist laut ghostlock.io nicht primär EDR oder Windows Event Log, sondern die Anzahl offener exklusiver Handles pro SMB-Session auf Storage- oder Fileserver-Ebene. Über SMB wird die Exklusivität an den File Server übertragen. Der Server verwaltet die geöffnete Datei oder das geöffnete Verzeichnis in seiner Session-Tabelle und blockiert konkurrierende Zugriffe. [Research Site]

GhostLock Linux: Samba, NAS und SMB-Shares

GhostLock Linux ist vor allem ein Betriebs- und Monitoring-Thema. Der öffentlich beschriebene Mechanismus bezieht sich auf SMB-Deny-Share-Handles und Windows-/SMB-Semantik, nicht auf eine Linux-Kernel-Lücke. Trotzdem sind Linux-Fileserver praktisch relevant, wenn sie über Samba SMB-Shares bereitstellen oder wenn NAS-Appliances intern auf Samba-ähnliche SMB-Dienste setzen. [Research Site] [Samba]

Für Verteidiger ist die wichtigste Frage nicht: "Ist Linux verwundbar?", sondern: "Kann mein Linux-/Samba-Storage schnell zeigen, welcher User, Client und Prozess auffällig viele offene Dateien oder Locks hält?" Samba stellt mit smbstatus Informationen zu aktuellen Verbindungen, Shares und Locks bereit; je nach Version ist auch eine JSON-Ausgabe für SIEM- oder Automations-Pipelines verfügbar. [Samba]

Die Abwehrlogik bleibt dadurch ähnlich wie auf Windows File Servern: ungewöhnliche SMB-Sessions erkennen, die blockierende Session oder den betroffenen Client zuordnen, kontrolliert trennen und anschließend Account sowie Endpoint behandeln. Pauschale Änderungen an Locking-Parametern in smb.conf sind keine saubere Sofortmaßnahme, weil sie legitime Anwendungen und Datenkonsistenz beeinflussen können. [Samba]

Warum ist das kritisch?

Viele Ransomware-Abwehrmaßnahmen starten bei Schreibmustern: hohe Änderungsrate, neue Dateiendungen, ungewöhnliche Entropie, Massen-Renames, verdächtige Prozesse oder bekannte Verschlüsselungslogik. GhostLock umgeht diese Denkrichtung, weil der Datenbestand unverändert bleibt. Die Datei ist nicht kaputt. Sie ist nur für die Dauer der Session nicht sinnvoll nutzbar. [Whitepaper]

In Unternehmen reicht das für echten Schaden. Wenn ERP-Exporte, Konstruktionsdaten, Vertragsablagen, Scanner-Workflows, Buchhaltungsläufe oder Teamshares plötzlich Sharing-Violations werfen, steht der Prozess. Backups helfen in diesem Moment nur begrenzt, weil es nichts zu entschlüsseln gibt. Die operative Aufgabe ist nicht Restore, sondern Identifikation und Beenden der richtigen SMB-Session.

Keine CVE, kein Patch: was das bedeutet

"Kein Patch" klingt schnell nach Hilflosigkeit, ist aber präziser: Die zugrunde liegende Funktion ist kein Bug, sondern Teil des Datei-Konsistenzmodells. Anwendungen wie Office, Datenbanken, Synchronisations-Tools oder Backup-Software nutzen exklusive oder restriktive Opens aus legitimen Gründen. Eine pauschale Blockade würde produktive Abläufe brechen. [Research Site]

Verteidigung verschiebt sich dadurch von "Patch installieren" zu "Betriebsmodell härten". Dazu gehören Least Privilege auf Shares, getrennte Abteilungsbereiche, kurze Reaktionswege zu Storage-Admins, verwertbare Telemetrie aus NAS- und File-Server-Management sowie klare Regeln, wann eine Session beendet werden darf.

Sofortmaßnahmen bei Verdacht

Nicht zuerst rebooten, sondern SMB-Sessions prüfen

Auf einem Windows File Server sollten Administratoren zuerst aktive SMB-Sessions nach vielen offenen Handles sortieren. Microsofts Get-SmbSession zeigt aktive SMB-Sessions inklusive Client, Benutzer und NumOpens. Danach lassen sich offene Dateien nach Session gruppieren und auffällige Sessions im Detail untersuchen. [PowerShell] [PowerShell]

# 1. Sessions mit vielen offenen Handles zuerst ansehen
Get-SmbSession |
  Sort-Object NumOpens -Descending |
  Select-Object -First 20 SessionId, ClientComputerName, ClientUserName, NumOpens, SecondsExists, SecondsIdle

# 2. Offene Dateien nach Session gruppieren
Get-SmbOpenFile |
  Group-Object SessionId |
  Sort-Object Count -Descending |
  Select-Object Count, Name

# 3. Details einer auffälligen Session prüfen
Get-SmbOpenFile -SessionId <SESSION_ID> |
  Select-Object FileId, SessionId, ClientComputerName, ClientUserName, ShareRelativePath

Für NAS-Plattformen wie NetApp, Dell, Qumulo, Synology, Windows Failover Cluster oder Cloud-SMB-Dienste sollten Teams prüfen, welche API oder Managementoberfläche offene Dateien, Sessions, Deny-Share-Status und Client-IP pro Session zeigt. Der wichtigste praktische Punkt ist, dass im Incident jemand innerhalb von Minuten sagen kann: Diese Session hält die blockierenden Handles.

Linux-/Samba-Server: Locks sichtbar machen

Auf Linux-Fileservern mit Samba ist smbstatus der erste Schnellcheck. Je nach Samba-Version lassen sich Prozesse, Shares und Locks getrennt oder als JSON erfassen. Wichtig ist auch hier die Korrelation: welcher User, welcher Client, welcher Share und welche offenen Dateien gehören zu einer auffälligen SMB-Session? [Samba]

# Aktuelle Samba-Verbindungen, Shares und Locks prüfen
sudo smbstatus --json

# Falls JSON nicht verfügbar oder für schnelle Sichtprüfung
sudo smbstatus -p
sudo smbstatus -S
sudo smbstatus -L

# Auffällige Clients/User anschließend über NAS-, SIEM- oder Samba-Logs korrelieren

Verdächtige Session beenden

Wenn Session, Client und User plausibel zugeordnet sind, kann die Session gezielt geschlossen werden. Alternativ lassen sich nur die offenen Dateien dieser Session schließen. Microsoft dokumentiert beide Wege; wichtig ist die Warnung, dass forciertes Schließen Datenverlust verursachen kann, wenn ein legitimer Client Änderungen noch nicht zum Server geschrieben hat. [PowerShell] [PowerShell]

# Verdächtige SMB-Session beenden
Close-SmbSession -SessionId <SESSION_ID> -Force

# Oder nur die offenen Dateien dieser Session schließen
Close-SmbOpenFile -SessionId <SESSION_ID> -Force

Das Beenden von Sessions ist ein Eingriff in laufende Arbeit. In Produktionsumgebungen sollte vorher geklärt sein, wer diese Entscheidung trifft. Bei einem echten Lockout zählt Geschwindigkeit, aber unkoordinierte Massen-Trennung kann zusätzliche Daten- oder Prozessprobleme erzeugen.

Angriffsclient sofort isolieren

Sobald ClientComputerName oder IP klar ist, sollte der Client aus dem Netz genommen und das verwendete Konto behandelt werden. Nur das Passwort zu ändern reicht nicht immer sofort: ghostlock.io weist darauf hin, dass bestehende SMB-Sessions nach Credential-Revocation weiterbestehen können, bis sie explizit beendet oder durch Timeout geschlossen werden. [Research Site]

• Host im EDR isolieren oder Switch-Port/VPN-Session trennen.
• SMB-Zugriff dieses Clients temporär blockieren.
• Betroffenen Domain-User deaktivieren oder Passwort zurücksetzen.
• Kerberos-/AD-Sessions, VPN-Sessions und ggf. Cloud-Sessions widerrufen.
• Prüfen, ob mehrere Clients dieselbe Userkennung verwenden.

Wann ein Server-Restart sinnvoll ist

Ein Restart des Fileservers oder NAS-SMB-Dienstes ist sinnvoll, wenn die verdächtige Session nicht schnell identifiziert werden kann, der Storage keine Session-/Open-File-Verwaltung anbietet, sehr viele Shares gleichzeitig betroffen sind oder der Business-Impact größer ist als der Reboot-Impact.

Aber: Reboot ist grob. Er trennt alle legitimen Nutzer, kann ungesicherte Daten verlieren und löst nicht die Ursache. Wenn der kompromittierte Client danach noch Zugriff hat, können Locks wieder aufgebaut werden. BleepingComputer berichtet ebenfalls, dass Handles nach Session-Ende, Prozessende oder Reboot verschwinden, der Angriff aber erneut gestartet werden kann. [News]

Dauerhafte Gegenmaßnahmen

GhostLock ist ein Rechte-, Telemetrie- und Betriebsproblem. Read-only verhindert GhostLock nicht automatisch, weil Leserechte reichen können. Es senkt aber den Blast Radius, wenn Nutzer nur die Shares lesen können, die sie wirklich brauchen.

1. Runbook bauen: SecOps und StorageOps brauchen einen festen Ablauf: Symptome erkennen, Session/User/IP finden, Session schließen, Client isolieren, Konto behandeln und Forensik starten.
2. Alarm auf auffällige SMB-Sessions: Praktischer Startwert sind Sessions mit ungewöhnlich vielen offenen Dateien oder Handles, etwa NumOpens stark über Baseline. GhostLock nennt als Primärsignal hohe per-session exclusive handle counts, beispielsweise Alerting bei mehr als 500 exklusiven Handles; Windows-Standardwerte zeigen aber nicht immer ShareAccess = 0, daher ist NAS-/Storage-Telemetrie wertvoll.
3. Rechte reduzieren: Least Privilege auf Share- und NTFS-Ebene prüfen. User sollten nur die Freigaben sehen und lesen können, die sie wirklich benötigen.
4. SMB-Zugriff segmentieren: SMB nur von verwalteten Clients/VPNs erlauben, flache Netze vermeiden, unnötige SMB-Routen zwischen Abteilungen entfernen und Admin-Shares restriktiv behandeln.
5. Applikationskontrolle auf Clients: Nicht autorisierte Python-Interpreter, Skripte und unbekannte Tools auf Endpoints blockieren oder zumindest alerten. Das stoppt die Technik nicht grundsätzlich, reduziert aber die Wahrscheinlichkeit, dass ein kompromittierter Standard-Client das PoC einfach ausführt.
6. Storage-Telemetrie ins SIEM bringen: Windows-EDR allein ist hier schwach. Ziel sind offene Files/Sessions, Client-IP, User, Share, Open-Count, Session-Dauer und, falls der Storage es liefert, ShareAccess-/exclusive-handle-Informationen.
7. Backups und Snapshots behalten: GhostLock verändert zwar keine Dateien, kann aber als Ablenkung für Exfiltration oder laterale Bewegung dienen. Backups sind wichtig, nur nicht die primäre Recovery-Methode für den Lock selbst.

Für Red Teams und interne Security-Tests gilt: GhostLock ist ein Availability-Test. Das gehört ausdrücklich in den Scope, idealerweise mit schriftlicher Freigabe, Testfenster, Nicht-Produktionsfreigabe und abgestimmtem Recovery-Plan. Das öffentliche Repository enthält bewusst Safety-Hinweise und ist für autorisierte Forschung gedacht, nicht für Experimente auf fremden oder produktionskritischen Shares. [PoC Repository]

Empfohlene Priorität

FAQ zu GhostLock

Was ist GhostLock?

GhostLock beschreibt eine Availability-Technik gegen SMB-basierte File Shares. Ein authentifizierter Benutzer hält Dateien oder Verzeichnisse über exklusive Deny-Share-Handles offen. Andere Clients erhalten Sharing-Violations, obwohl keine Datei verschlüsselt, umbenannt oder überschrieben wird.

Gibt es eine CVE oder einen Patch?

Nach der GhostLock-Veröffentlichung gibt es keine CVE und keinen klassischen Patch. Das Verhalten basiert auf dokumentierter Windows-/SMB-Semantik und wird von legitimen Anwendungen benötigt. Abwehr bedeutet deshalb Monitoring, Rechtebegrenzung und schnelle Session-Reaktion.

Welche Umgebungen sind besonders betroffen?

Relevant sind SMB-Freigaben auf Windows File Servern, Linux-/Samba-Fileservern, Enterprise-NAS, DFS-Namespaces, Abteilungs- und Home-Laufwerken, ERP-Dokumentablagen sowie Cloud-Dateidiensten mit SMB-Endpunkt. Kritisch wird es, wenn viele Nutzer breite Lese- oder Traversal-Rechte besitzen.

Ist GhostLock Linux relevant?

Ja, aber nicht als Linux-Kernel-Schwachstelle. Mit GhostLock Linux ist praktisch die Frage gemeint, wie Linux-Fileserver, Samba-basierte NAS und Appliances SMB-Sessions, offene Dateien und Locks sichtbar machen und wie Admins blockierende Sessions schnell beenden.

Warum erkennt EDR GhostLock nicht wie Ransomware?

Klassische Ransomware-Erkennung sucht oft nach Massenschreibvorgängen, Dateiumbenennungen, Entropieänderungen oder Verschlüsselungsmustern. GhostLock erzeugt diese Signale nicht. Der belastbarere Blick liegt am File Server: Sessions, offene Handles und ShareAccess-Verhalten.

Wie stellt man den Zugriff wieder her?

In der Regel müssen Storage- oder Windows-Admins die verursachende SMB-Session beziehungsweise offene Handles identifizieren und beenden. Nur das Passwort zurückzusetzen reicht nicht immer sofort, weil bestehende Sessions weiterleben können.