# Emotet mit Rspamd und Oletools bekämpfen - Emotet 2020 (Teil 3)
Leider sind seit dem Teil 1 & 2 doch nicht nur ein paar Tage ins Land gegangen.
Wir haben in der Zeit die nächsten 2-3 Emotet-Wellen mit neuen Ideen seitens der Malware Autoren gesehen und durften feststellen, dass Oletools auch auf der bösen Seite gefürchtet genug geworden ist, um ignoriert zu werden.
Was bisher geschah: Wir haben im Teil 1 gezeigt, was Office-Dateien mit Makros so gefährlich macht und wie es möglich ist, potenziell schädliche Makros zu erkennen. Das klappt mit Rspamd und Oletools sogar Pre-Queue, d.h. während der Annahme der Mail. Damit umgehen wir das Risiko ggf. als Backscatter gebranndmarkt zu werden und ebenso einige rechtliche Unwägbarkeiten.
Emotet mit Rspamd und Oletools bekämpfen
Im Teil 2 haben wir beschrieben, wie die Plugins Antivirus und External Services im Inneren von Rspamd funktionieren und wie es möglich ist, nur ganz bestimmte Teile einer E-Mail durch einen Virus Scanner oder einen anderen externen Service prüfen zu lassen, sowie die Rückgaben der Scans im Rspamd zu kategorisieren. Im Falle von Oletools betrifft das natürlich alle Dateien, die potenziell durch Microsoft Office geöffnet werden können bzw. VBA-Code enthalten können.
Emotet mit Rspamd und Oletools bekämpfen (Teil 2)
Kennt ihr die Erweiterungen .wri oder .word oder .w6w, .slk, .frx, .mht, xml, vba? Potenziell lassen sich diese Dateien durch Office verarbeiten. Weiß mensch wirklich so genau, wie die Dateien dann verarbeitet werden und wo VBA-Code vielleicht theoretisch ausgeführt werden könnte?
Eine ganze Weile analysierte nun unsere Lösung still und zuverlässig im Hintergrund, auch wenn einige besondere Exemplare auf ein paar Implementierungsfehler unsererseits aufmerksam machten, die wir in den folgenden Rspamd-Versionen behoben haben.
Zum Beispiel haben wir nicht damit gerechnet, dass der Analyse-Report der Oletools viele Kilobyte groß werden könnte. Dass dann Makro-Viren auftraten, die einen 50-100KB großen Report mit scheinbar willkürlichen IOCs (Indicators of Compromise: URLs, IPs etc.) auslösten – Zufall?
Weitere betroffene Dateiformate: .xls und .ppt
Ab August/September 2020 fielen uns vermehrt Office-Dokumente auf, die zuverlässig Oletools mit einem Fehler zum Absturz brachten. Und die Bandbreite der Dateiformate vergrößerte sich. Neben den obligatorischen .doc Dateien sahen wir vermehrt auch wieder .xls und .ppt. Das hatte seinen Grund.
Die Excel-Dateien sind eigentlich am Spannendsten - berühren sie doch ein aktuelles Problem, dass vor bald 30 Jahren erfunden wurde: XLM-Makros in Excel-Dateien. XLM-Makros sind ein Vorläufer von VBA-Makros und wurden eben 1992 mit Excel 4.0 für Windows 3.1 eingeführt. Und sie funktionieren heute immer noch. Teilweise konnte ihre Ausführung nicht einmal verhindert werden.
(https://www.heise.de/news/Makro-Malware-fuer-macOS-Forscher-warnt-vor-unterschaetzter-Gefahr-4864148.html)
Hier hatten die Malware Autoren auch einen blinden Fleck in Oletools gefunden. Oletools benutzt oledump für die Analyse von XLM-Makros und hier fehlten schlicht aktuelle Keywords und die integrierte Version hinkte der aktuellen Entwicklung hinterher.
Bei den .doc und den .ppt Dateien kam es zu Fehlern, die ganz speziell aufgebaute Makros auslösten. Genauer gesagt:scheinbar lösten die Makros bewusst Fehler in Oletools aus - ein Schelm wer Böses dabei denkt.
Ich möchte an der Stelle eine Lanze für den Oletools-Entwickler Philippe Lagadec brechen, der mit seiner Tool-Sammlung ein außerordentliches Framework zur OLE Analyse geschaffen hat. (Um kurz abzuschweifen kann ich Phillipes letzten Black Hat Vortrag sehr empfehlen: http://www.decalage.info/en/bheu2019)
Natürlich hängt die Entwicklung stabiler SIEM-Software immer ein wenig im Katz und Maus Spiel zwischen Malware-Autoren und Sicherheitstools hinterher. Wusstet ihr, dass mensch im VBA mit ActiveX, Worksheet.SelectionChange oder MouseOver als Trigger zum Auslösen von Aktionen arbeiten kann? ;-)
Auf welche Ideen die böse Seite oder auch White-Hats sonst noch so kommen, kann mensch sich meistens schön im Issue-Tracker von Oletools oder auf zahlreichen Twitter Channels oder Blogs ansehen: https://github.com/decalage2/oletools/issues.
Um den Releases von Oletools im Hinblick auf das Oletools-Plugin für Rspamd ein wenig voraus zu sein, haben wir uns entschieden, einen eigenen Oletools-Branch für olefy zu pflegen, bei dem wir aktuelle Commits und PR's aus der Oletool-Entwicklung zusammen mit eigenen Patches bereit stellen, um Mail-Infrastrukturen besser vor aktuellen Gefahren schützen zu können: https://github.com/HeinleinSupport/oletools.
So könnt ihr unsere Variante neben der offiziellen Version in olefy nutzen:
git clone --recurse-submodules https://github.com/HeinleinSupport/oletools.git
pip3 install -r /opt/oletools/requirements.txt
Dann muss in olefy.conf nur noch der Pfad zum olevba.py Skript angpasst werden:
#/etc/olefy.conf
...
OLEFY_OLEVBA_PATH=/opt/oletools/oletools/olevba.py
Im nächsten Blogartikel zu Emotet beschäftigen wir uns mit den vielen kleinen Tricks der Malware Autoren.
Autor: Carsten Rosenberg, Linux-Consultant, Heinlein Support
Emotet mit Rspamd und Oletools bekämpfen (Teil 1)
Emotet mit Rspamd und Oletools bekämpfen (Teil 2)
Emotet mit Rspamd und Oletools bekämpfen - die vielen kleinen Tricks (Teil 4)
Weitere Beiträge zum Thema
Enterprise Mail-Security mit Open-Source?
Enterprise Mail Security with Open Source?
Kommentare