Clients vor Infektion mit Ransomware schützen (Locky, Cryptolocker)

Wir sollten so langsam der Ransomware den Stinkefinger zeigen, Fileserver können wir schon schützen, verseuchte Clients ebenfalls identifizieren:

Auch an den Clients kann etwas getan werden um einer Infektion vorzubeugen. Es gibt hier allerdings kein Pauschalrezept, aber mit GPOs hat man ein mächtiges Werkzeug zur Hand um zumindest auf aktuelle Situationen reagieren zu können.

Hier sind 3 GPOs die Windows Clients vor Infektionen mit Ransomware schützen können. Natürlich gelten _IMMER_ die folgenden Grundsätze:

  • Der Benutzer ist KEIN lokaler Administrator
  • Die Windows Firewall ist aktiviert
  • Der Virenschutz ist aktuell (Aktuell heißt in diesem Fall, die Signaturen sind nicht älter als 12 Stunden)
  • Die Windows UAC ist aktiviert

Man kann über einen oder alle der oben genannten Punkte streiten? Gern, nur nicht mit mir :-) Diese Maßnahmen als zusätzliche Stufe anzusehen, im Idealfall schafft es die Ransomware erst gar nicht bis zum Client. Da es aber so viele Infektionen gibt, beuge ich auch lieber vor…

Makros deaktivieren

Derzeit verbreitet sich Locky hauptsächlich über Word Dokumente die via E-Mail zugeschickt werden, Das Word Dokument enthält dann ein Makro, welches den eigentlichen Schadcode nachlädt. Mittels GPOs lassen sich Makros deaktivieren. Dazu müssen die entsprechenden Vorlagen für Office runtergeladen werden:

Hier mal das Beispiel für Office 2016:

Die EXE-Datei entpackt nur die Vorlagen, diese müssen jetzt noch an den entsprechenden Ort kopiert werden. Also entweder in dem lokalen Policy Store auf dem DC oder dem Central Store.

In diesem Fall werden die Verzeichnisse und Dateien aus der entpackten EXE nach C:\Windows\PolicyDefinitions (lokaler Speicher) kopiert:

image

In der Gruppenrichtlinienverwaltung kann jetzt eine neue GPO angelegt werden und die Computerkonfigurationseinstellungen deaktiviert werden:

Markos

Innerhalb der GPO können nun die Makros abgeschaltet werden:

Markos

Sobald die GPO mit einer gewissen Anzahl an Benutzern getestet wurde, kann die GPO an alle Benutzer zugewiesen werden.

Markos

Hier gilt es die GPO vorher zu testen, vieleicht brauchen ja bestimmte Benutzer oder Abteilungen Makros für Ihre tägliche Arbeit. Das lässt sich dann entsprechend filtern.

Java Script im Internet Explorer deaktivieren

Während ich diesen Artikel schreibe, habe ich gelesen, dass sich die Ransomware Teslacrypt auch über infizierte Webseiten (Hauptsächlich wohl auf Joomla basierend) verbreitet. Dies geschieht via JavaScript:

Um Java Script zu deaktivieren, kann eine weitere GPO erzeugt werden, diesmal mit deaktivierten Benutzerkonfigurationseinstellungen:

Java Script

Jetzt kann die GPO bearbeitet und zu folgendem Punkt navigiert werden:

  • Computerkonfiguration
  • Richtlinien
  • Administrative Vorlagen
  • Windows-Komponenten
  • Internet Explorer
  • Internetsystemsteuerung
  • Sicherheitsseite
  • Internetzone

In der Zone „Internet“ lässt sich jetzt „Active Scripting“ deaktivieren:

Java Script

Jetzt kann die GPO wieder getestet werden, und danach mit der Domain verknüpft werden:

Java Script

Softwareeinschränkung konfigurieren

Viren und Trojaner gehen oft nach dem gleichen Muster vor, irgendeine Schwachstelle wird ausgenutzt, der Virus/Trojaner wird nachgeladen und ausgeführt, häufig geschieht das Ausführen aus einem temporären Ordner oder aus den APPDATA Ordern, daher kann man auch hier ansetzen.

Wieder eine neue GPO erzeugen, Benutzerkonfigurationseinstellungen deaktiviert

Softwareeinschränkung

Die GPO kann jetzt editiert werden und die Softwareeinschränkung aktiviert werden:

Softwareeinschränkung

Jetzt können unter zusätzliche Rgelen die Einschränkungen aktiviert werden:

Softwareeinschränkung

Wie oben werden nun die folgenden Pfadregeln konfiguriert:

  • %appdata%\*.exe
  • %appdata%\*\*.exe
  • %localappdata%\*.exe
  • %localappdata%\*\*.exe
  • %temp%\*exe
  • %temp\*\*.exe

Softwareeinschränkung

Anwendungen aus den Verzeichnissen werden nun nicht mehr ausgeführt:

Softwareeinschränkung

Auch hier gilt wieder, GPO testen und erst dann an die Domain oder OU zuweisen.

27 Replies to “Clients vor Infektion mit Ransomware schützen (Locky, Cryptolocker)”

  1. Hi Frank,

    danke erst mal für deine Infos. Beim zweiten Link für die Office 2013 Administrative Template files hat sich ein Fehler eingeschlichen. Der Link scheint falsch zu sein. Leider hab ich auf die Schnelle auch keinen richtigen Link gefunden.

    VG
    Hendrik

  2. Hi Hendrik,
    ich bin da auch drauf reingefallen, die Links passen. Versuch es mal mit Chrome oder Firefox… (IE klappt bei mir auch nicht)
    Gruß, Frank

  3. Guten Abend,

    danke Frank, mal wieder :)
    Da sich der Tojaner auch in Excel Dateien wäre ggf. diese Einstellung ebenfalls sinnvoll.
    Bei der Excel 2010 GPO gibt es eine Einstellung „Geschützte Ansicht für aus Outlook geöffnete Anlagen deaktivieren“. Auch gibt es die o.g. Einstellung von Makros deaktivieren in Office 2010 nicht, das wird über die „Geschützen Ansichten“ geregelt.

    Gruß

  4. Hi Franky,

    wie verhält sich das bei Installationen, wenn ich EXE-Dateien im Temp sperre? Gibt ja einige, die Ihre Installationsdateien automatisch ins %temp% extrahieren und von dort aus starten?

    Gruß

  5. Heyho,

    Vielleicht nur ein Gerücht, aber ich habe gehört, dass es sinnvoll sein kann, wenn man auch das Vorschaufenster deaktiviert (Falls der Anhang runtergeladen, aber nicht ausgeführt wurde):
    http://imgur.com/2gys9Y0

    Greets
    Simon

  6. Hallo zusammen,

    bezüglich Software Restriction Policies, also die Softwarebeschränkungen, die Frank hier gezeigt hat, sollte man IMHO mit Whitelists arbeiten, ist einfacher und kürzer als mit Blacklists alles mögliche und unmögliche zu sperren.

    Whitelist:
    %programfiles%
    %programfiles (x86)%
    %windir%
    Damit ist alles andere außen vor. Und dorthinein darf eh nur der Admin installieren. Einfach mal mit ein paar Testclients und Testbenutzern ausprobieren.

    Servus
    Winfried

  7. Hi Frank,
    danke für die Tipps. Ich habe bezüglich Makros sperren für Office-Dokumente schon vor ein paar Tagen angefangen eine GPO zu basteln. Wie du schreibst, brauchen in Unternehmen leider manche Mitarbeiter doch die Makros. Ich wollte das aber nicht auf OUs respektive Mitarbeiter beschränken, sondern wollte einstellen „generell Öffnen / Speichern für ‚Makroaktivierte Arbeitsmappen und Vorlagen im Format Excel 2007 und später‘ verbieten, außer die Datei liegt in einem ‚Vertrauenswürdigen Speicherort'“. Das Öffnen der Dateien in diesen Verzeichnissen klappt so auch, allerdings lässt sie sich nach Änderungen dort nicht mehr speichern. Nach etwas rumprobieren mit verschiedenen Kombinationen der Einstellungen habe ich nun resigniert. Es sieht so aus als erlauben die ‚Vertrauenswürdigen Speicherorte‘ nur ein Öffnen. Muss man also zwei GPOs machen und es somit mitarbeiterspefizisch konfigurieren?

    Grüße

  8. Hi, ich bin immer noch auf der Suche nach einer ordentlichen Konfiguration der GPOs. Leider ist die von die aufgezeigte Richtlinie mit den Makros offenbar nur in Office 2016 GPOs verfügbar und nicht für Office 2010, welches sicherlich aber noch sehr viele Leute benutzen. Man kann natürlich noch sehr detailiert die Einstellungen für den Zugriffsschutz definieren, aber eben nicht so, dass die User trotzdem noch mit Makros arbeiten können. Das Ziel sollte ja sein, Makros erst einmal zu verbieten, bis auf bestimmte Ausnahmefälle. Ich hätte ja versucht, das über die Vertrauenswürdigen Speicherorte zu regeln, jedoch scheint die GPO nur bedingt zu greifen. Zwar wird das Öffnen und Ausführen von Makros in den vertrauenswürdigen Ordnern nun erlaubt, nur das Speichern leider nicht. Das liegt an den Einstellungen für den Zugriffsschutz. Dort kann man für „Makroaktivierte Arbeitsmappen und Vorlagen im Format Excel 2007 und später“ mehrere Dinge konfigurieren, aber nur wenn man „nicht blockieren“ wählt, also Makros für XLSM generell zulässt, kann der User ein Makro-File weiterhin bearbeiten. Schön wäre natürlich, wenn das Öffnen, Ausführen und Speichern von Makro-Dateien in vertrauenswürdigen Speicherorten erlaubt wäre, in allen anderen Ordnern aber gesperrt würde bzw. in der Geschützten Ansicht ohne Ausführungsmöglichkeit geöffnet werden würde. Dieses Szenario lässt sich aktuell nicht umsetzen, soweit ich das sehe. Sobald die die „2007er und später“ Makro-Dateien konfigurieren möchte, muss ich sie entweder komplett zulassen (nicht blockieren) oder zumindest das Speichern verhindern. Dabei ist ja der Witz, dass das Speichern eigentlich nicht der gefährliche Vorgang ist, sondern das Ausführen. DAS wird aber an vertrauenswürdigen Orten jederzeit ermöglicht (logisch, dazu sind sie auch da, aber warum wird speichern dann dabei verhindert?).

    Hat dafür jemand eine Lösung? Kurz gesagt: ich möchte an vertrauenswürdigen Speicherorten das Öffnen, Ausführen UND vor allem das Speichern von XLSM erlauben, an allen anderen Orten aber verbieten … Lösung?

  9. Hi Toby,
    das genau ist auch mein Problem (siehe mein vorherigen Post). Ich habe keine Lust Markos über OUs und Sicherheitsgruppen für vereinzelte Mitarbeiter komplett freizuschalten und für alle anderen komplett zu verbieten. Ich will definieren können, dass alle Nutzer an Speicherort X Officedateien mit Markos verwenden und Speichern dürfen. Dadurch hat man ja indirekt auch eine Beschränkung auf einen Personenkreis, da auf Verzeichnis X nur die Personen einer bestimmten Sicherheitsgruppe zugreifen dürfen…
    Sollte das wirklich so nicht funktionieren wären die ‚vertrauenswürdigen Speicherorte‘ aus meiner Sicht totaler Schwachsinn?

    Grüße

  10. Korrigiere:
    „also Makros für XLSM generell zulässt, kann der User ein Makro-File weiterhin bearbeiten“, heißen muss es: „also Makros für XLSM generell zulässt, kann der User ein Makro-File weiterhin abspeichern“

  11. Hallo Franky, erst einmal vielen Dank für den tollen Blog Eintrag! Hätte da mal eine Frage zu den Softwareeinschränkungen. Und zwar wir hier nicht auf der Client-Seite eine Enterprise bzw. Ultimate Lizenz benötigt?! Da es sich um Applocker handelt? Gruß

  12. Hi Franky, großartig Deine Hilfe!
    Kleiner Hinweis: In der letzten Pfadregel fehlt ein %-Zeichen.
    Es sollte %temp%\*\*.exe heißen.
    Gruß und weiter so!!!

  13. @Henning,

    im Beispiel von Frank werden Software Restriction Policies vewendet, und die funktionieren an jedem Client in der Domain. Applocker spielt nur mit Enterprise bzw. Ultimate zusammen.

  14. Danke für die interessante und gute Anleitung! Ich habe versucht, die GPOs nachzubauen. Hier ist Office 2013 im Einsatz. Das sperren von Makros funktioniert scheinbar nicht. Ich sehe zwar die Leiste ‚Makros sind deaktiviert‘. Dann kommt aber der Button ‚Aktivieren‘. Drücke ich den, geht alles. :-(

    Was ich möchte: Makros sperren. Für alle und auf allen Wegen.

  15. @Richard, dann guck dich in den Zugriffsschutzeinstellungen mal um, das komplette Sperren von Makros ist über die GPOs gar kein Problem. Das muss man je Anwendung (Word/Excel/Powerpoint usw) einzeln machen. Z. B. Admin. Templates > MS Excel 2013 > Excel Optionen > Sicherheit. Alles was sich darunter befindet würde ich mir mal durchlesen und ggf. aktiveren oder deaktivieren und konfigurieren.
    Wenn du Makros deaktivieren möchtest, würde ich zunächst im Trust Center bei „Einstellungen für VBA-Makrobenachrichtigungen“ konfigurieren, dann in den Einstellungen für den Zugriffsschutz zunächst generell einstellen: Standardverhalten für den Zugriffsschutz aktivieren und hier etwas auswählen, ich empfehle in geschützter Ansicht öffnen und nicht bearbeiten. Das kannst du dann je Dateityp nochmal genauer festlegen, für „Makroaktivierte Arbeitsmappen und Vorlagen im Format Excel 2007 und später“ kannst du so z. B. nochmal genauer definieren, was zu tun ist. Wie in meinem vorherigen Beitrag aber erwähnt: wählst du hier etwas anderes als „nicht blockieren“ wird das Speichern der Datei unmöglich (genaueres entnimm meinen anderem Post ein paar Einträge über dir). Guck dir die Sicherheitsoptionen ALLE mal durch und konfiguriere sie dann auch für Word usw. (Locky geht ja z. B. hauptsächlich über Word raus, wie ich das gelesen habe). Bitte wähle auch zu JEDEM Makrodateityp eine Option aus, sonst wird er, soweit ich das lesen kann, nicht gesperrt! Hast du das Standardverhalten wie gewünscht oben festgelegt, kannst du dann in der Regel immer „Öffnen/Speichern blockiert, Richtlinie für Öffnen verwenden“ auswählen, dann greift die Regel für das Standardverhalten.

    Grüße

  16. Ach und nicht zu vergessen: das Ganze auf dem Client mal testen, dort in der CMD mal „gpupdate /target:user“ durchlaufen lassen und dann Excel (oder was auch immer du eingestellt haben möchtest) öffnen, Datei > Optionen > Trustcenter (bis 2010 Sicherheitscenter) > Einstellungen f. Trustcenter und dort dann unter „Einstellungen für den Zugriffsschutz“ gucken, ob die Makrorelevanten Files gesperrt werden, dafür sollte bei Öffnen und Speichern der Haken drin sein, der User sollte den nicht entfernen können. Das ist etwas verwirrend, man könnte ja meinen, wenn ich den Haken bei Öffnen und Speichern drin habe, darf ich ebendas, es ist aber anders herum, was auch in der Beschreibung über den Haken zu entnehmen ist.

    Was mir auch aufgefallen ist: wenn du eine Home & Business Version (oder darunter) verwendest, scheint die GPO nicht zu greifen, zumindest nicht bei Office 2013 und höher. Du benötigst also bei Office 2013 und Office 2016 mindestens die Standardversion (oder Pro. oder Pro Plus), um Office mit GPOs steuern zu können. Bei Office 2010 ging das noch mit den Home and Business Versionen. Nur für den Fall, dass es DESWEGEN nicht bei dir gegriffen hat.

    Grüße

  17. Hallo,

    und bei Office 365 Paketen muss man auch gut suchen, nicht jedes Paket verarbeitet GPOs. Auch die click2run Installation dürften GPOs ignorieren. Damit hätte man an der falschen Stelle gespart.

  18. Hallo Toby,

    danke für den Hinweis mit H&B 2013 (setzen wir natürlich ein). Ich habe es über eine .reg Datei gelöst, die bei Anmeldung durchläuft und Makros deaktiviert. Der Benutzer könnte es zurückstellen, ist aber, denke ich, für unser Netz ausreichend. Die Kollegen „geimpft“, mich bei seltsamen Emails zu benachrichtigen.

    Gruß Sven

  19. Hallo Sven, kannst du das bitte etwas genauer erklären wegen .reg Datei, die Idee ist klar aber die Lösung :) ?

    @Franky

    Vielen Dank für deine Arbeit und Hilfe! ich bin mir sicher du hast vielen Menschen das Leben erleichtert!

  20. Die Softwarerestriktionen sind leider vollkommen wertlos.
    Ich habe jetzt 2 Tage damit rumgespielt.
    %userprofile%\*.exe bewirkt das eine exe Datei im %Userprofile% geblockt wird, nicht aber in einem Unterordner %Userprofile%\test

    Der Eintrag %userprofile%\*\*.exe bewirkt dann das die exe auch im Unterordner %Userprofile%\test geblockt wird, nicht aber in weiteren unterordner des Profiles.

    Dann habe ich versucht exe Dateien zu blocken die jemand im Outlook in einem zip Archiv öffnet.
    Die liegen in einem Ordner wie C:\Users\benutzername\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\xxxxx
    Auch hier kein Erfolg mit einem Restriktionseintrag wie
    %userprofile%\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\*\*.exe

    Die Softwareresttriktionen sind zwar nett gemeint aber von MS sehr schlecth umgesetzt. Oder ich mache etwas falsch. Aber was?
    %userprofile%\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\*\*\*.exe

  21. Die Software-Restriktions mit Whitelisting funktionieren einwandfrei.
    Was mich gerade beschäftig ist das whitelisting für das deaktivierte active-scripting im IE.
    Geht das nur über die Vertrauenswürdigen Sites?

  22. Ich bin leider nicht so fir was GPO betrifft.
    Die Beispiele lassen sich ja nicht 1:1 auf Office 2010 übertragen.
    Was also genau muss ich für 2010 aktivieren?
    Den Punkt „Ausführung von Makros in Office-Dateien aus dem Internet blockieren“ gibt es ja nicht.
    Kann mir da Jemand helfen?

  23. Bzgl. Whitelist & exe Files in %Appdata%: OneDrive werden hier auch abgelegt
    Beispiel: \AppData\Local\Microsoft\OneDrive\17.3.6386.0412\

  24. Halloechen, vielen Dank fuer die Idee der User %temp% Ordner. Schon lange mir ein Dorn im Auge. Vielleicht erwaehnenswert, das Zutritt fuer Console auch gesperrt sein sollte, sonst koennte jemand auf die Idee kommen, mittels eigener SET-Befehle, obige Bemuehungen auszer Kraft zu setzen. Ich hoffe, jetzt keine Eulen nach Athen gtragen zu haben ;-) Vielen Dank fuer diese Tips. O.E. aus Potsdam.

  25. Kurz, noch ein Eintrag. Wir verwenden openExchange und der ‚Oxtender‘ wird (leider) auch ueber %AppData% des angemeldeten Users (40 an der Zahl) ‚gemanagement‘. Ergo mal openExchange bescheid geben, ab sofort keine (‚personifizierte‘) exe-Dateien aus’m %AppData%-Ordner des Users x. Oder, wie bei Adobe, gleich ins %system32% rein … :-/ (Sarkasmus) Letzteres ist mir auch ein Dorn im Auge. Denn, wenn ein ‚User/Browser/Adobe-Kram‘ oeffnet und es in diesem Prozess zu einer ‚Rechteeskalation‘ durch DOS oder sonstwas, kommt, stehen die ganzen Betriebssystems-Ordner ‚unter Beschuss‘ … Unsere Ransomware-Erfahrung nutzte (zum Glueck …) ’nur‘ die Zeitspanne zwischen zwei Antiviren-DB-updates aus … Aber bei einer bewuszten -Zero-Day-Attacke auf … Sicher Schlimmeres. In 19 Minuten knapp 6.580 Dateien +- … :-/ O.E. aus Potsdam PS.: vielen Dank fuer Tips und dieses ‚Forum‘ …

  26. Noch loswerden: Microsofts Ordner-Strukturen. Extrem heikel. Ich weisz. Seit MS XP setze ich ausschlieszlich nur noch AngloAmerikanische-Installs ein, wo, es eben nicht heiszt: C:\Dokumente und Einstellungen … sondern nur C:\Users … und wurstle meine OEM/VLC rein.

    Aber eben noch nicht mal UNC-faehig. Und es kam noch Schlimmer. Seit MS Vista herrscht scheinbar ein Ordner-Chaos – weit jenseits von Gut und Boese. Gut, drum bin gleich zu Win 7 pro (engl.). Denn gewisse MS Vista Ordner errinerten mich doch zu sehr an das altertuemliche X11-Problem (weit vor „Windows 3.11“) unter UNIX, etwas spaeter auch unter Linux. Mir wurde uebel.

    Ich bin jedenfalls mit der folgenden, einfachen Regel grosz geworden (UNIX/Linux):
    export home no_root_squash bzw. all_squash, womit beteiligte home- bzw. %USERNAME%-Verzeichnisse erst mal keine Möglichkeit haben, auch bei einer User-Rechteeskalation, aus ihren user-verzeichnissen in Systembereiche hinein zu kommen. Punkt! Durch eine geeignete chroot – Umgebung kann der Admin relativ leicht, auch ‚Angriffe‘ auf systemkritische Anwendungen abfangen (Sandbox-Prinzip). Nichts destro trotz, kann man auch einfach abschalten – bzw. zu Bett gehen :-) Ne, aber im Ernst, Microsoft MUSZ extrem hart an seiner Ordner-Strukur feilen. Immerhin will ja diese Firma auch noch Geld dafuer … Liebe Gruesze aus Potsdam / Brandenburg — not USA :-)

    Quelle 1:
    RFC 1813 – NFS Version 3 Protocol Specification – IETF Tools

    Quelle 2:
    NFS › Wiki › ubuntuusers.de

    Quelle 3:
    21.7. The /etc/exports Configuration File – Red Hat Customer Portal

    Habt vielen Dank. Ich war wirklich leicht schockiert, mit welch‘ einer Effizienz „diese RansomSau“ bei uns zuschlug … Jutes Nächtle. Und Danke fuers „Luft rauslassen“. Bei Fragen, bitte, gerne. OE.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.