GhostLock Linux: SMB-Lockout ohne Verschlüsselung erkennen

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.

Wer nach GhostLock Linux sucht, sollte das Thema 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 kann man das Thema nicht einfach wegpatchen, sondern muss Datei-Server-Betrieb, Rechte und Incident Response sauberer machen.

Was GhostLock macht

GhostLock 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.

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.

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 relevant, wenn sie über Samba SMB-Shares bereitstellen oder wenn NAS-Appliances intern auf Samba-ähnliche SMB-Dienste setzen.

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.

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.

Warum das kritisch ist

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.

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.

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

Windows File Server: Sessions und Handles prüfen

Auf einem Windows File Server sollten Administratoren zuerst aktive SMB-Sessions nach vielen offenen Handles sortieren. 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.

# 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

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 die Korrelation: welcher User, welcher Client, welcher Share und welche offenen Dateien gehören zu einer auffälligen SMB-Session?

# 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. Das ist ein Eingriff in laufende Arbeit: Bei legitimen Clients kann forciertes Schließen Datenverlust verursachen, wenn Änderungen noch nicht zum Server geschrieben wurden.

# 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

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: Bestehende SMB-Sessions können nach Credential-Revocation weiterbestehen, bis sie explizit beendet oder durch Timeout geschlossen werden.

• 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.

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.

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 Safety-Hinweise und ist für autorisierte Forschung gedacht, nicht für Experimente auf fremden oder produktionskritischen Shares.