Warnung: Unerkannte Variante eines Verschlüsselungstrojaners im Umlauf

Ich stelle die Info, die mir die Tage von einem Blog-Leser zuging, einfach mal unkommentiert hier im Blog ein. Er hat mehrfach E-Mails mit einem verschlüsselten ZIP-Anhang erhalten, in der eine unerkannte Variante eines Verschlüsselungstrojaners oder der Emotet-Trojaner enthalten ist. Ergänzung: Inzwischen tauchen auch Warnungen von Sicherheitsforschern zu dieser Kampagne auf.


Anzeige

Blog-Leser Sandro P. ist Administrator in einem Unternehmen und mit dem Thema E-Mails mit Verschlüsselungstrojaner (Ransomware) konfrontiert. In seiner Mail schrieb er am 18. Sept. 2020 folgendes:

Uns erreichen seit heute Email-Nachrichten mit verschlüsselten ZIP-Dateien und folgendem Textschema:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Passwort für das Archiv: LgEwRVwqLm

Herzliche Grüße

Max Mustermann – Unternehmen GmbH

m.mustermann@unternehmen.de

—–Ursprüngliche Nachricht—–

> *Von:* "Email Empfänger"

> *Gesendet:* Freitag, 18. September 2020 um 12:06

> *An:* "Max Mustermann – Unternehmen GmbH"

Betreff: Re: Max Mustermann – Unternehmen GmbH

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Die Absenderinformationen „Max Mustermann – Unternehmen GmbH" (Angaben wurden aus Datenschutzgründen anonymisiert) variieren und entsprechen entweder den Unternehmensinformationen eines beliebigen Kollegen oder denen eines unternehmensfremden Mitarbeiters, z.B. sehr häufig "Martin Diesel – BEFA GmbH" (m.diesel @ befa-team.de).

Der Text der Mail ist laut Sandro in perfektem „Email-Deutsch" inklusive Umlaute, Klarnamen, etc. gehalten. Der Betreff ist entweder der Name des Empfängers oder „AW: {Name des Empfängers)". Es soll dem Empfänger also vorgegaukelt werden, er hätte eine Mail verschickt, auf die nun eine Antwort kommt, die der Empfänger zwar nicht erwartet aber eventuell verarbeiten wird.

Im Anhang zu diesen E-Mails befindet sich eine verschlüsselte ZIP-Datei, die sich mit dem in der Nachricht genannten Kennwort entpacken lässt. Dazu schreibt Sandro:

Im Anhang befindet sich eine verschlüsselte ZIP-Datei die sich mit dem genannten Kennwort entpacken lässt. Enthalten ist eine .DOC Worddatei nach dem Emotet-Schema (Information für den Anwender über ältere Version, enthaltene Macros).

Das perfide daran: Weder unser Trend Micro OfficeScan / ApexOne noch der Sophos AntiVirus auf unserem Sandbox-Scanner schlagen auf diese Datei an – Pattern und Engines sind (kontrolliert) aktuell.

Entweder ist hier eine „kaputte" Version eines Virus im Umlauf oder es gibt eine neue Encryption-Variante die uns die kommende Zeit bewegen wird.

An dieser Stelle mein Dank an Sandro für die Information. Zum Thema 'Erkennen durch Virenscanner' – ist eine schwierige Kiste. Mir liegt dieser Anhang nicht vor, sonst hätte ich mal bei VirusTotal geprüft, ob ein Virenscanner den Beifang erkennt.

Nachtrag: Sandro schrieb mir: Inzwischen erkennt Sophos AntiVirus (Linux) mit aktuellem Pattern die Datei als virulent. Bei VirusTotal sind aber noch nicht alle Engines/Patterns soweit, die Schadsoftware zu erkennen.

Beim Klinikum Düsseldorf war nach meinen Informationen Sophos Endpoint Protection im Einsatz, aber deren IT wurde per Ransomware lahm gelegt. Es deutet sich also an, dass die Cyber-Kriminellen häufiger das Katz-und-Maus-Spiel mit den Sicherheitslösungen gewinnen. Es gibt Leute, die eher auf die Lösungen zur verhaltensbasierten Erkennung von Angriffen setzen. Hier scheint Microsoft Defender ATP, Azure ATP und Office 365 ATP eingesetzt zu werden.

Ergänzung: Inzwischen tauchen auch Warnungen von Sicherheitsforschern zu dieser Kampagne auf. Microsoft Security Intelligence schreibt auf Twitter:


Anzeige

Emotet joined the password-protected attachment bandwagon with a campaign starting Friday. The campaign slowed down over the weekend (typical of Emotet) but was back today in even larger volumes of emails in English, as well as in some European languages.

Also die Bestätigung, dass seit Freitag eine Emotet-Kampagne mit gezippten Passwort-geschützten Anhängen läuft. Und @nextmorpheus gibt in diesem Tweet und in Folgetweets weitere Hinweise – z.B. dass die Mails teilweise verzögert zugestellt werden und dass Emotet bereits kurz nach der Infektion alle E-Mails durchforstet. Etwa 2 Stunden später ist mit ersten Antworten auf die E-Mails zu rechnen (selbst wenn das Passwort geändert wurde, wird eine vorgetäuschte Adresse verwendet). Dies lässt sich nicht mehr verhindern und kann einige Wochen andauern.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

26 Antworten zu Warnung: Unerkannte Variante eines Verschlüsselungstrojaners im Umlauf

  1. N. Westram sagt:

    Ich suche hierfür auch noch ein Tool, welches verhindert dass die Benutzer bestimmte Dateitypen z.B. *.doc, *.exe speichern dürfen.
    Man kann in vielen Antivirentools z.B. *.doc in E-Mails verbieten. Aber beim Download wird es schon schwieriger, da man dann bei verschlüsselten Seiten in die Verschlüsselung eingreifen muss.
    Meiner Meinung nach wäre die einfachste Variante einfach das Speichern zu verbieten, auch beim Entpacken von Archiven werden diese ja zuerst im Temp-Verzeichnis entpackt. Leider habe ich hierzu noch nichts gefunden.

    • No sagt:

      Wurde die zip-Datei bei Virustotal.com bzw Abuse.ch hochgeladen?

    • Mich@ sagt:

      GFI Mail Essentials ;)

    • Hör auf zu Suchen, verwende SAFER alias Software Restriction Policies; bei skript-interpretierenden Programmen deren dazu äquivalente Einstellungen (die beispielsweise bei Microsoft Office bereits ab Werk gesetzt sind)!

      • 1ST1 sagt:

        Oder gleich richtig, die Applocker-Richtlinie, sofern man auf eine Enterprise-Lizenz zurückgreifen kann.

        Es macht auch Sinn, der Anleitung auf schneegans.de zu folgen, gleich oben "Windows mit SAFER absichern". Denn sowohl SRP als auch Applocker haben per Default ein Problem: Unter c:\windows gibt es ein paar tief vergrabene Verzeichnisse, auf die Benutzer schreiben können. Aber sowohl SRP als auch Applocker werden per se so konfiguriert, dass der Benutzer alles in diesem Verzeichnis und darunter ausführen kann, also auch das was er in diese Verzeichnisse rein gelegt hat. Auf der Seite gibt es ein Script, welches diese Verzeichnisse aufspürt und eine Reg-Datei für SAFER/SRP erstellt, die man zusätzlich in die Policy aufnehmen oder per Rechtsklick im System verankern muss. Bei Applocker kann man die in der Reg enthaltenen Pfade als Ausnahme in die c:\windows\-Regel aufnehmen.

        Da bei Schneeganz gibts im selben Artikel auch eine Reg um SRP Logging einzuschalten, und praktischerweise schreibt Windows selbst dann mit in diese Log-Datei seine Aktivitäten, wenn statt SRP Applocker aktiv ist. Und da gibts noch ein paar nützliche Zusatzsachen in Form von kleinen Scripts.

        Erst dann ist das Ding wasserdicht.

        (Ja, ich kenne die S.Kanthak-Anleitung zu Safer, ich finde die von Schneegans aber einfacher nachzuvollziehen!)
        (Von heise gibts noch das Tool "Restric'tor", was auch SAFER aktiviert, aber leider auch ohne diese Ausnahmen unter c:\windows zu sperren, muss man also trotzdem nach der Anleitung von Schneegans nachholen.)
        (Leider wird SRP von MS nicht mehr weiter entwickelt und irgendwann vielleicht sogar ganz abgeschaltet, zugunsten von Applocker. Ist grundsätzlich ja nicht verkehrt, nur muss dann MS Applocker für alle Windows-Lizenzen, nicht nur für Enterprise, freischalten)

        • Sidespin sagt:

          Berücksichtigt die Safer-Konfiguration von Stefan Kanthak diese für Benutzer beschreibbaren Verzeichnisse nicht?
          Das kann ich mir fast nicht vorstellen.

          • 1ST1 sagt:

            Nein, diese Verzeichnisse finden dort leider keine Berücksichtigung. Dafür dort wird tiefer auf andere Aspekte eingegangen, um die Funktion besser zu verstehen ist das natürlich nützlich. Zur Implementierung reicht aber das, was bei Schneegans zu finden ist.
            Wichtig ist aber zu wissen, dass wenn man der Anleitung von Kanthal oder Schneegans folgt, dass man zusätzlich (zu c:\windows und den beiden c:\program files) noch den Ordner "C:\ProgramData" freigeben muss, denn dort verstecken leider diverse legitime Anwendungen ausführbare Dateien, z.B. der Sophos AV macht das, oder der Updater von Google Chrome, usw. Das ist großer Mist, aber wenn man das vergisst, funktioniert einiges an Software nicht mehr wie vorgesehen.
            Nützlich ist auch, da wird bei Kanthak deutlich drauf hingewisen, dass man möglichst zwischen Benutzeraccount und Admin-Acconut trennen soll.

          • Sidespin sagt:

            Also das mit dem Program Data ist mir bekannt. Macht ja selbst der Defender seit dem Update KB4052623 (?). Das ist wirklich großer Mist, wenn sich selbst Microsoft sich nicht an die eigenen Regeln hält.
            Auch das mit dem Nutzeraccount / Admin ist mir bewusst und ich handhabe das auch strikt so. Aber gerade diese für Beutzer beschreibbare Verzeichnisse unter den an sich über Safer geschützten ist ja schon wichtig. Das hebelt ja den Schutz doch schon aus.

          • SELBSTVERSTÄNDLICH sind diese berücksichtigt, inklusive ihrer "alternate data streams" … wo AppLocker erbärmlich versagt!

          • sidespin sagt:

            Danke für die Info! :-) Es hätte mich auch gewundert! Ihr guter Ruf, was Rechnersicherheit angeht, ist auch zu mir durchgedrungen, daher konnte ich mir das fast nicht vorstellen.

      • 1ST1 sagt:

        Herr Kanthak, bitte entfernen Sie bitte mal das EICAR Testfile von Ihrer Webseite! Sonst kann man auf Ihre Seite über diverse Proxies, die solche Spielereien garnicht mögen, nicht mehr ansehen!

        Die übertragene Datei enthielt einen Virus und wurde daher blockiert.
        URL: https://skanthak.homepage.t-online.de/SAFER.html
        Medientyp: text/plain
        Virusname: EICAR test file

    • Sven Fischer sagt:

      Man könnte da auch einen Proxy (Bsp. Squid) dazwischen klemmen und per ACLs bestimmte Dateitypen ausfiltern.
      https://constey.de/2011/01/squid-proxy-blockieren-von-bestimmten-dateitypen/
      Da ist aber Voraussetzung, das die Clients nur via Proxy ins Netz dürfen/können.

  2. Jörn Walter sagt:

    Am Besten wäre doch grundsätzlich ein Redirect der lokalen Verzeichnisse auf einen File-Server und da aktiviert man dann den File Server Resource Manager und setzt entsprechende Richtlinien die das Speichern von xyz Dateien verbieten. Wäre das eine Idee?

    • Carsten sagt:

      Wir gehen da noch einen Schritt weiter und blocken solche Anhänge schon an unserer UTM. Wenn eine EXE, ZIP etc. Datei im Netz landet ist mMn schon der ersten Fehler passiert. Man muss die Kunden nur dazu erziehen, sich an die eigenen Regeln zu halten. Klappt bei uns zumindest ziemlich gut.

      Es sollte aber auch erwähnt sein, dass bei uns 99% nur Schriftvekehr per Email versendet wird. Natürlich haben andere Firmen andere Anwendungsgebiete. Trotzdem würde ich hier immer das Prinzip "Alles blocken und einzeln freigeben" einer Symptombekämpfung vorziehen.

      Gruß

    • Tom sagt:

      Das bringt aber nicht soviel. Die Dateien werden trotzdem verschlüsselt. Einfach der Teil mit umbenennen der Endung schlägt fehl.
      Da man die Transportkette niemals 100%ig absichern kann und der Benutzer immer die grösste Gefahr ist, setzen wir auf Sandboxing auf (3th Party). Alles was von ausserhalb kommt wird in der Sandbox geöffnet.

    • masterX244 sagt:

      Geht aber nur sinnvoll bei "stationären" Systemen im Firmennetzwerk. Netzlaufwerke mit hohem Ping und schmaler Bandbreite sind ätzend langsam und nervig. (Wenn man wegen dem Coronamist von zuhause arbeiten muss hat man diese Störfaktoren zwangsweise)

  3. Michael sagt:

    Ist doch völlig normal, dass AV sich schwer tun bei verschlüsselten Anhängen, das ist nix Neues und den Trick gibt's schon lang. Meine Vermutung ist, dass der AV die Datei also das verschlüsselte Archiv nun einfach über die Datei Signatur des Archivs blockt.

  4. MOM20xx sagt:

    seit wir alte microsoft dokument typen am mailgateway sperren, ist es ziemlich ruhig geworden. zudem arbeiten applocker rules mit. und wir werden demnächst mal application policies in der symantec endpoint protection aus probieren. sprich word, excel, powerpoint und co. dürfen kein powershell.exe oder ähnliches anwerfen.

  5. Sommersonne sagt:

    exe, doc, xls schon beim Mail-Gate blocken und die Nutzer automatisiert per Mail informieren (der kann mit dem Absender dann Kontakt aufnehmen). Sollte das Scannen einer ZIP im Mail-Anhang vom Gate nicht möglich sein, dann bleibt die Datei in Quarantäne solange bis sich ein Admin die Mail angesehen hat.
    Das Speichern von doc / xls auf dem Fileserver grundsätzlich mit dem Ressourcen-Manager verbieten.
    Seitdem wir so arbeiten ists recht ruhig geworden

  6. der name sagt:

    bitte virustotal payload URLs und interne file URLs posten, bzw SHA1 SHA256 summen zum selber suchen. danke mfg.

Schreibe einen Kommentar

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

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.