Neuste Artikel

Comments: 1 Comment

By: Sascha

Cryptolocker auf Fileservern

Ich habe mich die letzten Tage mal wieder ein wenig mit Cryptolocker beschäftigt und was der aktuelle Stand an dieser Front ist.
Da das Erkennen dieser schon sehr lästigen Zeitgenossen ja auch immer komplexer wird und auch der geschulte bzw. sensibilisierte Nutzer immer wieder auf Fake-Mails reinfällt rückt das Thema auch nie in den Hintergrund.

Zu meinem Glück kann ich „noch“ sagen, dass ich bis jetzt keine größeren Schäden durch solche Software davon tragen musste (auf Holz geklopft). Dieses lag aber vor allem an einer funktionsfähigen Backup-Infrastruktur und der bedingungslosen Speicherung aller wichtigen Daten auf einem oder mehreren Fileservern.
Leider aber auch nur aufgrund dieser beiden Punkte. Das Problem im Vorfeld zu erkennen und damit den Schaden zu minimieren ist mir bis jetzt noch nicht gelungen, soll aber Ziel in diesem kleinen Artikel sein.

Klar ist eine funktionierende Backup-Infrastruktur, eine passende Rollen- und Rechteverteilung sowie ein durchdachtes Freigabesystem weiterhin das A und O aber auch hier kann ein Cryptolocker sehr viel Schaden anrichten, da er ja in der Regel von den Clients ausgeführt wird, welche den Zugang auf die Freigaben haben.
Je nach dem aus welcher Abteilung der Nutzer stammt und welche Laufwerke er bearbeiten darf, kann es schon zu einem mittelschweren Desaster führen.

Durch einen interessanten Artikel auf Heise.de (link) habe ich eine alte Idee wieder aufgegriffen, das Problem direkt auf dem Fileserver zu erkennen und zu begrenzen.
Diese Idee hatte ich anfangs verworfen, da ja die Verschlüsselung und die damit verbundenen Prozesse von außen stattfinden und somit auf dem Fileserver nur Daten geändert werden.
Dieser o.g. Artikel beschreibt nun sehr schön was man alles in der Linux-Welt machen kann, was mir erstmal nichts bringt, da alle von mir betreuten Systeme in der Windows-Welt anzusiedeln sind.

Die Grundidee hier ist es zu erkennen ob Dateien angelegt werden die in unser Schema passen welches wir suchen. Also Dateien mit den bekannten Erweiterungen usw.
Hierzu bietet sich der Microsoft Ressourcen Manger für Dateiserver an.
Normalerweise setzt man diesen ein, um Kontingente durchzusetzen oder um Nutzern das Speichern von vordefinierten Dateien zu verweigern. Und genau dieses File Screening Management kann uns hier helfen, indem wir es auf Dateien und deren Endungen ansetzen, welche typisch für unsere Problemfreunde sind.

Als erstes wer ihn noch nicht installiert hat, muss nun Microsoft Ressourcen Manger für Dateiserver installieren.

Assistent zum Hinzufügen von Rollen und Features 2012R2

Hiernach kann nun noch der Emailversand konfiguriert werden, damit man zeitnah eine Meldung bekommt.
Ich habe hierzu einen Trigger in meiner Monitoring Software auf das Event gelegt, welches ausgelöst wird, wenn der Dienst zuschlägt. Dazu aber später noch ein Satz.

Als nächstes legt man mit dem CMDLet New-FsrmFileGroup eine neue Dateigruppe an. Natürlich kann man dies auch manuell machen aber es dauert halt länger :-).

New-FsrmFileGroup -Name"Ransomware" –IncludePattern @("*.1999","*.0x0","*.aaa","*.abc","*.aesir","*.bleep","*.ccc","*.crinf","*.crjoker","*.cryp1","*.crypto","*.crypt","*._crypt","_crypt","*.CTBL","*.CTB2","*.ecc","*.EnCiPhErEd","*.encrypted","*.encryptedRSA","*.ezz","*.exx","*.good","*.HA3","*.k","*.keybtc@inbox_com","*.LeChiffre","*.locked","*.locky","*.LOL!","*.magic","*.micro","*.OMG!","*.R16M01D05","*.r5a","*.RDM","*.RRK","*.SUPERCRYPT","*.thor","*.toxcrypt","*.ttt","*.vault","*.vvv","*.XRNT","*.XTBL","*.xxx","*.xyz","*.zzz"

Ich habe mich entschieden in der Dateigruppe erstmal alle typischen Endungen aufzunehmen und nach diesen filtern zu lassen.

*.1999
*.0x0
*.aaa 
*.abc
*.aesir
*.bleep
*.ccc
*.crinf
*.crjoker 
*.crypto 
*.crypt
*.cryp1
*._crypt
_crypt
*.CTBL
*.CTB2
*.ecc
*.EnCiPhErEd 
*.encrypted 
*.encryptedRSA 
*.ezz 
*.exx 
*.good 
*.HA3 
*.k 
*.keybtc@inbox_com 
*.LeChiffre 
*.locked 
*.locky 
*.LOL! 
*.magic 
*.micro 
*.OMG! 
*.R16M01D05 
*.r5a 
*.RDM 
*.RRK 
*.SUPERCRYPT 
*.thor 
*.toxcrypt 
*.ttt 
*.vault 
*.vvv 
*.XRNT 
*.XTBL 
*.xxx 
*.xyz 
*.zzz 

Ab dieser Stelle ist es mir nun auch sehr leicht möglich die Liste weiter zu pflegen, da wir diese Liste mit dem CMDLet Set-FsrmFileGroup sehr leicht aktuell halten können.
Auf diesem Weg kann ich jetzt ohne großen Aufwand durch die Scripteingabe im Monitoring System die neuen Regeln an alle Server verteilen.

Set-FsrmFileGroup -Name "Media Files" -IncludePattern @("Neue Regel_1", "Neue Regel_2")

Die letzte Aufgabe besteht nun nur noch darin das gesamte System scharf zu schalten und Aktionen zu wählen, welche ausgeführt werden sollen, falls unser Filter zuschlägt.
Dieses erledigen wir im Ressourcen-Manager für Dateiserver. Dort wählen wir Dateiprüfungsvorlage erstellen.

Dateiprüfungsvorlage anlegen

Unserer Vorlage geben wir nun einen Namen und weisen ihr unsere eben erstellte Dateigruppe zu.

Dateipruefungsvorlage-erstellen_1

Danach wählt man noch aus wie man benachrichtigt werden möchte. Ich nutze das Ereignisprotokoll, da ich hier automatisch via Mail durch die von mir eingesetzte Monitoring Software benachrichtigt werde.

dateipruefungsvorlage-erstellen_2

Eine weitere Idee, die ich in den nächsten Tagen umsetzten werde, ist es bei Befehlen ein Script auszuführen, welches dem Nutzer der das Event ausgelöst hat, die Rechte auf die Freigabe zu entziehen. Sobald ich das erledigt habe, werde ich hier ein kleines Update posten.
Zu guter letzt erstellen wir nun noch die Dateiprüfung. Hier legen wir nur noch den Pfad fest und unter Benutzerdefinierte Eigenschaften, dass wir unsere eben erstellte Vorlage benutzen wollen.

dateipruefungsvorlage-erstellen_3

Klar ist das Ganze kein Rundumschutz, kann uns aber vor bösen Überraschungen am Montag schützen und den Arbeitsaufwand bei einem möglichen Befall in einem betreuten System massiv verringern.

Schlagwörter: ,

Comments are currently closed.

One thought on “Cryptolocker auf Fileservern

%d Bloggern gefällt das: