Emotet Abwehr

Jeden Tag lese ich neue Horrormeldungen über Behörden, Firmen, Kliniken u.a., die durch Emotet großen wirtschaftlichen Schaden zugefügt bekommen. Im gleichen Maße bewerben immer mehr Firmen ihre "Lösungen", um solche Angriffe zu erschweren. Dabei ist eine Abhilfe ganz einfach und meist mit Bordmitteln möglich.

Diese Seite versuche ich weiter zu schreiben, wenn ich neue Erkenntnisse habe. Beachten Sie dazu auch die Seite Ransomware - Fiktive Story

So "bekommen" Sie Emotet und Co

Das Einfallstor ist fast immer ein Anwender, der per Mail oder auf anderem Weg ein Office-Dokument bekommt und letztlich das darin enthaltene Programm ausführt. Ich bin sicher, das es zukünftig noch andere Wege gibt und diese Wege sind auch nicht neu. Letztlich startet der Anwender aber ein unbekanntes Programm.

In dem Zuge frage ich mal ganz plump: Wer kann mir einen Grund nennen, warum ein durchschnittlicher Anwender auf seinem Computer ein beliebiges Programm starten kann?

Genau genommen ist das doch nur der Fall, weil sich Firma und IT-Abteilung nicht die Mühe gemacht haben, den Arbeitsplatz und die damit erforderlichen Betriebsmitteln zu beschreiben und vorzugeben. Stellen Sie sich mal im produzierenden Gewerbe vor, wenn ein Mitarbeiter von zuhause ein Werkzeug mitbringt, weil die Firma nur eine schlechtere Variante bereitstellt?

Etablieren Sie einen Prozess, mit dem Mitarbeiter den Bedarf an einem Betriebsmittel melden können und nutzen Sie als Firma dies als Verbesserungsvorschlag. Oder sie erklären dem Mitarbeiter, warum sein Werkzeug gesamtwirtschaftlich die schlechtere Wahl ist.

  • Test zum Erkennen von Phishing-Mails (Englisch)
    https://phishingquiz.withgoogle.com/
    Ihr könnte auf der ersten Seite euren Namen und Mailadresse eingeben. Ihr bekommt keine Mail und das ist alles JavaScript auf dem Client. Zumindest bei mir hat Fiddler nichts nach "hinten" gesendet.

Zurück zur IT: Jeder Anwender kann Programme starten und die meisten Anwender müssen natürlich auch das Internet nutzen. Damit kann auch ein Schadcode den eigentlich böse Teil aus dem Internet nachladen. Der Angreifer reduziert so die Gefahr, dass das erste Programm schon als böse erkannt wird, den dieses lädt ja nur etwas aus dem Internet herunter. Der Angreifer kann so aber den Schadcode dynamisch und schnell anpassen. Vor allem kann er dies so oft machen, dass klassische Virenscanner gar keine reale Change haben, über ihre "Patterns" solche Muster zu erkennen.

Schutzprogramme können daher Schadprogramme nie zu 100% erkennen. Sie sind aber Teil einer Schutzstrategie aber manchmal leider selbst Teil des Problems. Sie sind aber nicht überflüssig und ohne Virenscanner ist jeder Betrieb leichtsinnig.

Der kritische Faktor ist der Mensch und selbst erfahrene Computerredakteure fallen auf solche Mails herein. Es kann also wirklich jeden Treffen und die Schadkomponente unterliegt auch einer kontinuierlichen Weiterentwicklung:

Die Strategie

Um sich bestmöglich gegen Emotet zu schützen, sehe ich primär eine Kombination aus folgenden Teilen:

  • Allowlist für Code
    Auch wenn es mühsam ist, sollten Anwender nur "zugelassenen" Code überhaupt starten dürfen. Das betrifft in der Windows Welt natürlich nicht nur Programme (EXE/COM/DLL) sondern auch Skripte (CMD, VBS, PS1) als auch Makros in Office Dokumenten. Die Allowlist muss nicht jedes einzelne Programm einhalten. Sie könnten auch sagen, dass alles in C:\Windows und C:\ProgramFiles verwendet werden kann, da ein normaler Anwender dort nichts schreiben kann.
  • Signatur von Makros
    Da die Nutzung von Dateienamen und Pfaden ziemlich unflexibel ist, sollten Sie die Signatur von Code forcieren. Die meisten "öffentlichen" Programme sind ja signiert und Sie können dann z.B. anhand des Signaturgebers die Ausführung erlauben. So kann auch das nächste Update von Word problemlos gestartet werden. Für selbst entwickelten Code, z.B. Skripte und Makros, müssen Sie natürlich die Plattform und einen Prozess zur Signierung einführen.
  • Daten schützen
    Sie glauben gar nicht, wie viele Personen auf Informationen schreibenden Zugriff haben, obwohl die Daten schon lange nicht mehr verändert werden sollten oder benötigt werden. Selbst Lesen ist zu viel, wenn eine Malware dann die Daten ausleiten kann. Entsprechend sollten Sie prüfen, welche Berechtigungen entfallen können und die Daten in einen "sicheren Bereich" verlagert werden können. Allerdings sind es ja gerade die aktiven aktuellen Daten, deren Verlust am meisten schmerzt.

Sie können natürlich zusätzlich die Übertragungswege schützen, indem Proxy-Server die Downloads überwachen, Spamfilter vor der Mailserver die Anlagen prüfen und sie auch noch OneDrive, Dropbox sperren und die USB-Medien beschränken. Es wird aber immer einen Weg geben, Informationen in das Unternehmen zu bekommen, z.B. indem der Code eben verschleiert wird. Irgendwann wird eine ausführbare Malware einen gut geschulten Anwender in einem unvorsichtigen Moment erreichen und das Unheil nimmt seinen Lauf.

Angst oder Aufgabe?

Wenn ich die Strategie bei Firmen vorstelle, dann bekomme ich natürlich Gegenwind, dass das Risiko eines Produktionsausfalls und der Aufwand viel zu hoch sind. Ich habe ja nicht gesagt, das es Sicherheit für "Lau" gibt aber oft reicht die Frage nach vergangenen Threads, um ein Umdenken anzustoßen. In den meisten Firmen gab es nämlich schon Fälle von Datenverlusten, Viren aber auch schon kostspielige CEO Fraud Vorfälle. Es ist natürlich verständlich, dass so etwas nicht beim ersten Mal schon öffentlich gemacht wird. Auch Vorgaben durch GDPR/DSGVO fördern ein Umdenken. Es ist keine Frage des OB, sondern eher des WANN eine Störung des Betriebs passiert.

Ein Schutz ist natürlich umso besser, je mehr Komponenten ineinandergreifen. Aber Ressourcen und Zeit sind beschränkt und natürlich hätte ich gerne Microsoft 365 mit DefenderATP, NetFlow auf allen Switches, Inventory aller Clients, Honeypots im Netzwerk u.a. Diesmal geht es aber darum, wie jede Firma mit überschaubarem Aufwand und vertretbarem Risiko die Grundsicherheit ihres Netzwerks verbessern kann.

Code Inventory

Zuerst müssen wir wissen, welche Programme wo gestartet werden. Die Liste muss anfangs gar nicht komplett sein, denn das spätere Durchsetzen wird pro PC erfolgen. Also können wir mit einer Baseline starten und die ersten "Standard-Clients" sichern. Vergessene Programme werden nachgerüstet und mit jeder Welle wird die Liste besser. Die Erfassung bedeutet aber, dass wir auf den Clients die Applikationen einsammeln.

Mit Applocker und SmartScreen ist das sehr einfach aber dazu benötigen Sie Windows 10 Enterprise oder Education. Andere Windows-Versionen haben diese Funktion nicht. Sie könnten aber z.B. mit bestimmten Verzeichnissen anfangen.

C:\Windows\
C:\Program Files\
C:\Program Files (x86)\
C:\Users\Administrator\
C:\Users\InstallDienst\

Ds ist erst mal nur ein Anfang der aber schon zuverlässig verhindert, dass später Programme von einem anderen Verzeichnis, insbesondere aus TMP oder den Datenverzeichnissen von Benutzern ausgeführt werden. Ausnahmen gibt es für den Administrator und z.B. ein Dienstkonto, welches Software installieren muss und dazu ein lokalen TEMP-Verzeichnis nutzt.

Das ist nur ein "Anfang" und sie können und müssen die Liste natürlich für ihre Anforderungen anpassen.

Wenn Sie Anmeldskripte, Inventory-Software o.ä. einsetzen, können Sie natürlich einfach die ausführbaren Dateien einmal inventarisieren

Es muss ja auch gar nicht eine Liste für alle Clients genutzt werden. Wenn Sie ihre Anwender in "Personas" eingeteilt haben, dann sollten sie viele Computer finden, die einen klar umrissenen Arbeitsauftrag erfüllen, z:B. "Buchhaltung, Mail, Office, Surfen" und abgesehen von zentralen Updates keine weiteren Veränderungen oder Erweiterungen durch den Anwender benötigen.

Eine kleine Ausnahme sind natürlich die Programme, die sich alle nach "AppData" des Anwenders installieren. Dazu gehört auch Teams. Die Ausnahmen werden dann schon etwas aufwändiger, wenn man nicht über die Signatur des Code gehen kann.

RootCA

Pfade und Dateinamen sind keine dauerhafte Lösung und speziell für eigene Skripte und Makros brauchen wir eine Signatur. Als ganz einfache Lösung könnten Sie natürlich nun ein "Selbst signiertes Codesigning-Zertifikat" erstellen und auf allen Clients über eine Gruppenrichtlinie verteilen. Das mag funktionieren, wenn Sie nur einen Admin haben und ihr Signaturzertifikat sicher ist. Aber besser ist hier schon der Aufbau einer eigenen RootCA.

Wir suchen uns also einen Server oder einen Admin-Client, um eine stark eingeschränkte CA zu installieren. Sie wird dahingehend eingeschränkt, dass Sie nur CodeSigning-Zertifikate ausstellt. Sie kann also keine SMIME-, PGP-, BitLocker-, SmartCard-, EFS oder andere Zertifikate ausstellen und "Key Recovery" fällt damit weg. Optional könnte man die CA auch noch "Computerzertifikate" ausstellen lassen, damit sie ihre internen WebServer und TerminalDienste für Administratoren besser absichert.

Sie können das mit OpenSSL machen. Ich plädiere in einer Windows-Welt aber besser auf eine WindowsCA auf einem Member-Server oder in ganz kleinen Umgebungen auch auf dem Domain Controller, so dass Sie automatisch "Trusted" auf allen Clients wird und "AutoEnrollment" für die Clients genutzt werden kann. Das ist dann auch der erste Weg zu 802.1x-Authentifizierung bei WLAN oder per Zertifikat gesicherte VPN-Zugänge. Das ist aber eine andere Baustelle.

Primär stellt die CA aber eine überschaubare Zahl an Codesigning-Zertifikate aus.

Makro Signatur

Da Makros die größte Einfallstür sind, möchte ich gerne in meiner Firma nur Makros ausführen lassen, die digital signiert sind. Ehe diese Einstellung per Gruppenrichtlinie aktiviert werden darf, müssen natürlich bestehende Makros signiert werden. Genau genommen muss der Makro-Entwickler das Makro zu einem Admin bringen, der das Makro dann signiert. Alternativ kann ein Admin auch zum PC hingehen und das Makro dort signieren. Wichtig ist, dass alle Teilnehmer wissen, worum es geht und dass Änderungen am Makro entsprechend erneut signiert werden müssen. Der Prozess dazu ist zu definieren.

In der ersten Stufe würde ich auf den kritischen Clients die Makros signieren und dann manuell die Einstellungen in Office "verschärfen"

Die Benutzer können so einige Tage lange bei Problemen den Schutz temporär wieder abschalten, bis eine permanente Lösung geschaffen wurde. Aber diese Übergangszeit sollte nicht zu lange dauern. Sie möchten nämlich schon einzelne oder Gruppen von Computern mit der Richtlinie versehen, dass alle VBA-Makros signiert sein müssen.

Ab Office 2016 können Sie übrigens weitere Einstellungen steuern, dass Makros für Dateien aus dem Internet unterbunden werden. Wenn ein Browser oder Outlook eine Anlage als Datei speichert, dann addiert er die Information über die "Zone". Das funktioniert aber nur auf NTFS-Speicherorten. Eine Datei per FAT32-USB-Stick ist nicht gekennzeichnet und ein Anwender kann die Kennzeichnung über den Windows Explorer einfach wieder außer Kraft setzen.

Wenn Sie Anmeldskripte, Inventory-Software o.ä. einsetzen, können Sie als extra Kontrolle natürlich die aktuellen Makro-Einstellungen auch aus der Registrierung auslesen.

Das Ziel ist, dass alle Clients keine signierten Makros mehr ausführen können und Geräte, die nicht "kontrolliert" sind dann nur sehr selektiv Zugriff auf Firmenressourcen bekommen. Über die installierte CA können Sie ja die Clients mit Computerzertifikaten ausstatten und mit 802.1x den Zugang zum Netzwerk steuern. Siehe auch 802.1x - Zugang zum Netzwerk steuern

 Office Home & Business 2013-2019 kann keinen GPOs, d.h. Benutzer können es wieder abschalten. Denkbar sind aber "Autostart"-Dokumente und Templates, die als signiertes Makro die Einstellung prüfen

Applocker oder Software Restriction Policies pro PC

Der nächste Schritt ist Umsetzung hinsichtlich Programmen und Skripts. Leider können heute quasi alle Mitarbeiter einer Software aus beliebigen Quellen herunterladen und ausführen. Jeder Anwender kann in seinem privaten "AppData"-Verzeichnis Programme ablegen und starten. Programme sollten aber nur von "Vertrauenswürdigen Quellen" kommen, z.B. entweder liegen Sie auf einer Stelle (C:\Windows, C:\Programme, etc.), an die Benutzer nichts schreiben können. Oder die Programme sind digital signiert. Signierte Malware ist natürlich möglich aber ein öffentliches Codesigning-Zertifikat ist teuer und kann zurückgezogen werden. Die Angreifer wären nicht mehr so flexibel.

Um solche Policies umzusetzen, benötigen Sie leider Windows 10 Enterprise oder Education

Allerdings gibt es auch ohne die Steuerung per Gruppenrichtlinien verschiedene Möglichkeiten

Mit der richtige Windows Version können Sie natürlich einfach AppLocker als einfache Blockade einsetzen.

Wenn all das nicht geht, könnte es auch eine Option sein, per CodeSigning einfach alle ausführbaren Programme, die bislang nicht signiert sind, mit ihrem eigenen Zertifikat zu signieren und dann pauschal "unsignierten Code" zu blockieren.

Dateien schützen

Vor vielen Jahren gab es ja schon "Crypto-Trojaner" als Vorfahren von Emotet und auch hier wollten die Schadprogramme möglichst lange unentdeckt ihr perfides Werk durchführen, indem Sie Dateien verschlüsselt haben. Das lässt sich nie ganz verhindern, da Anwender natürlich mit Dateien arbeiten und damit auch schreiben müssen. Aber Sie können sich schon dagegen absichern

  • Berechtigungen reduzieren
    Dateien, die nicht mehr beschrieben werden sollen oder müssen, können per ACLs dem Benutzer komplett entzogen oder zumindest ein Schreibzugriff unterbunden werden. Bei "ReadOnly" kann ein Schadcode beim Anwender die Datei nicht mehr verschlüsselt aber immer noch "lesen" und ausleiten.
    Vielleicht sind daher die Skripte rund um CryptoProtect für Sie interessant.
  • Versionen
    Viele Speichersysteme unterstützen eine Versionierung von Dateien, z.B. SharePoint, OneDrive aber auch GIT und andere Versionsverwaltungssysteme. Leider sind "Schattenkopien" kein adäquater Schutz, da eine Verschlüsselung sehr vieler Dateien sehr schnell den reservierten "Schattenspeicher" füllt und damit die vorherigen Versionen überschrieben werden. Hier könnten Sie maximal über die Schreibrate erkennen, dass es sehr viele Änderungen gibt.
  • Backup
    Datenverluste durch Emotet sind nur ein Risiko. Hardware-Defekte, menschliche Fehler, Softwarefehler u.a. können Daten unlesbar machen. Dafür gibt es "Offline"-Datensicherungen. Der Schwerpunkt liegt wirklich auf "Offline", denn ein Backup2Disk auf einen Server im LAN der ebenso erreichbar ist, ist kein Backup

Es gibt noch viel mehr Dinge, die ihr System besser uns sicherer machen können, Angefangen bei einem Admin-Konzept, ein abgestimmtes User Account Control und andere Dinge, die ich hier aber nicht alle noch anhängen möchte.

Unterstützung durch Net at Work:
Wenn ihnen diese Informationen so nicht genügen, dann können wir uns gerne über eine Unterstützung unterhalten.

Gibt es da nicht was von ATP?

Wenn Sie in der Microsoft-Welt unterwegs sind und z.B. den in Windows eingebauten Schutz durch "Defender" und "Firewall" etwas aufbohren möchten, dann können Sie sich ja mal Defender ATP anschauen. Hier ein paar Links

Allerdings sind diese Zusatzfunktionen natürlich nicht kostenfrei, sondern z.B. über Microsoft 365 E5 Security, Microsoft 365 E5, Windows E5 oder einzeln zu lizenzieren. Insofern können Sie hier natürlich auch einen Blick zu anderen Herstellern wagen, die ebenfalls Produkte zum Thema "Endpoint Protection" verkaufen.

Weitere Links