Ein Beitrag von IT Forensic Consultant Tim Drobny

Cyberangriffe werden zunehmend professioneller, automatisierter und schwerer zu erkennen. Angreifer setzen heute auf ausgefeilte Taktiken wie Phishing, Living-off-the-Land-Techniken, legitime Remote-Tools oder verschleierte Malware, um unbemerkt in Netzwerke einzudringen und sich dort festzusetzen. Für Unternehmen bedeutet das: Klassische Schutzmaßnahmen allein reichen längst nicht mehr aus.

Genau hier setzt die Digital Forensics & Incident Response (DFIR)-Abteilung der SySS an. Durch die Analyse von Sicherheitsvorfällen und Malware werden Angriffsmethoden untersucht, Kompromittierungen rekonstruiert und Indikatoren sowie Taktiken der Angreifer identifiziert. Dieser Blogbeitrag analysiert eine aktuelle Malware, die die DFIR-Abteilung bereits dreimal auf Kundensystemen gefunden hat, und zeigt, wie moderne Schadsoftware aufgebaut ist und welche Erkenntnisse sich daraus für die Verteidigung ableiten lassen.

Easy2Convert (hxxps://www[.]easy2convert[.]com/) ist eine legitime Ansammlung an Programmen, die bereits seit 2008 existiert. Die Programme sind dafür da, diverse Dateitypen konvertieren zu können, unter anderem PCD zu TIFF, BMP zu JPG und RAW zu JPG.

Angreifer versuchen häufig, ihre Schadsoftware als legitime Software zu verstecken, um Detektierungen zu entgehen. In der zweiten Hälfte von 2025 erblickte dann die Easy2Convert-Malware (hxxps://www[.]ez2convertapp[.]com/) das Tageslicht. Die Angreifer verwenden also den Namen einer bereits existierenden legitimen Applikation, um ihre eigene Schadsoftware zu verbreiten. Der erste Eintrag in der Wayback Machine (eine Ansammlung archivierter Snapshots von Webseiten) geht bis in den Juni 2025 zurück.

Auf den ersten Blick wirkt es wie eine legitime Webseite. Leider ist das, was mitgeliefert wird, wohl kaum ein legitimes Tool. Auch wenn die tatsächliche Funktionalität existiert und auch in Teilen funktioniert, gibt es weitere äußerst verdächtige Funktionalitäten in der automatischen Updatefunktion.

Die Webseite verspricht die Möglichkeit, dass das heruntergeladene Programm ODT-Dateien zu PDF-Dateien konvertieren, PDF-Dateien zusammenfügen kann und dass der nachträgliche Download sofort stattfindet. Hier ergeben sich direkt mehrere Fragen:

Warum sollte man für eine Konvertierung auf ein externes Programm zurückgreifen, wenn Word auch von sich aus PDF-Dateien erstellen kann?
Macht die Webseite hier falsche Versprechen? (Spoiler: Ja, das tut sie!)
Warum muss man sich ein Programm herunterladen, nur damit man die damit verarbeiteten Dateien erneut herunterladen muss?

Die erste Frage ist am leichtesten zu beantworten: Viele Menschen, die in Bürojobs arbeiten und Word-Dateien zu PDF-Dateien konvertieren müssen, wissen sicher nicht, dass Word diese Funktionalität mitbringt. Wenn dann Google befragt wird, tauchen diverse Tools im "Sponsored"-Tab der Suchergebnisse auf. (Diese Funktion ist standardmäßig aktiviert für Google-Suchen.) Ein Programm, das alles macht, was ich möchte und sogar noch mehr? Na, immer her damit! Es ist also wahrscheinlich, dass die Verbreitungsstrategie der Angreifer auf das Unwissen der Menschen setzt, die sich wenig mit Computern auskennen.

Die anderen beiden Fragen sind aus dem Stegreif schwieriger zu beantworten. In diesem Blogbeitrag geht es zunächst um die legitimen Funktionen der drei gefundenen Samples, gefolgt von einer Analyse des maliziösen Teils. Das Faszinierende: Alle drei Instanzen haben Unterschiede in ihrer legitimen Funktion. Der maliziöse Teil ist bei allen drei allerdings genau gleich. Die Taktiken und Methoden der Malware werden mithilfe des Mitre Att&ck-Frameworks klassifiziert.

Sample-Überblick

Alle drei Samples sind unterschiedlich: in ihrer Funktion und teilweise auch in der verwendeten Sprache.

Sample	Wrapper-Sprache	Konvertierungsmethode	Payload	Payload-Sprache
Sample 1	C# .NET	Upload auf eine Online-Conversion-Webseite	Easy2ConvertUpdater.exe	C# .NET
Sample 2	Rust	Upload auf eine Online-Conversion-Webseite	Easy2ConvertUpdater.exe	C# .NET
Sample 3	Rust	Lokales Python-Environment	Easy2ConvertUpdater.exe	C# .NET

Es fällt sofort auf: Es gibt drastische Unterschiede bei den verschiedenen Implementierungen. Drei verschiedene Möglichkeiten, dasselbe zu erzielen, in zwei verschiedenen Wrapper-Sprachen.

High Level Injection Flow

Das Programm wird als Installer geliefert. Dieser Installer legt dann alle benötigten Dateien ins "AppData\Local"-Verzeichnis. Darunter befindet sich das Programm an sich, der Updater, eine einzigartige User ID, diverse DLL-Dateien und eine XML-Datei.

Das Programm bietet tatsächlich legitime Funktionen, auf die später eingegangen wird. Der Updater fungiert als Loader für Code, der nachgeladen wird. Er ist also die eigentliche Malware, die Code aus dem Internet nachlädt und ausführt. Mehr zum Updater später. Die einzigartige User ID wird vom Updater verwendet. Die DLL-Dateien bringen einige der Funktionalitäten mit, die der Updater und auch die legitime Anwendung benötigen. Die XML-Datei enthält Informationen für einen Scheduled Task. Mit diesem Scheduled Task persistiert sich die Malware und wird einmal am Tag ausgeführt.

Legitime Funktionen

Das Interessante an dieser Malware ist, dass die Funktionalität, die sie verspricht, tatsächlich existiert – zumindest teilweise. Die Konvertierung von ODT- zu PDF-Dateien ist da, aber die Merge-Funktion nicht. Die Behauptung, dass Downloads sofort stattfinden, trifft wahrscheinlich auf eines der drei Samples zu. Eines der drei Samples verwendet tatsächlich einen Onlinekonverter und lädt die konvertierte Datei dann wieder herunter.

Im Folgenden werden die legitimen Funktionen der Samples hinsichtlich ihrer Konvertierungsmethode beschrieben.

.NET-Konvertierung

Die erste Version verwendet .NET, um die Konvertierung durchzuführen. Diese Funktion kann sogar andere Dateien umwandeln (DOC, DOCX, PNG, JPG, PPT, PPTX, XLS, XLSX):

Von der Merge-Funktion ist immer noch nicht viel zu sehen. Interessant ist, dass die Datei hier einfach auf eine Webseite hochgeladen und dann wieder heruntergeladen wird. Hier ist sogar die Domain (hxxps://etco[.]gulivet[.]com/api/convert) und die zugehörige "Convert"-Funktion enthalten:

Hier ist zu sehen, dass diese Version doch nur DOCX-Dateien konvertieren kann. Es ist auffällig, dass im User Interface (UI) mehr Dateitypen angenommen werden als auf der Konvertierungsseite möglich sind. Was mit den anderen Dateitypen passiert, ist unklar. Der Download landet dann einfach im "Downloads"-Verzeichnis des aktuellen Benutzers:

ABER: Es gibt keine Merge-Funktion, dafür aber die Downloadfunktion.

Onlinekonvertierung

Die zweite Version nimmt die ODT-Datei und lädt sie bei einem Online-Conversion-Tool über dessen API hoch. Nachdem die Datei konvertiert wurde, wird sie in den "Downloads"-Ordner des Benutzers heruntergeladen. Es werden hier also zwei von drei Versprechen tatsächlich erfüllt. Dann setzen allerdings die Probleme ein: Die Methode ist nicht nur datenschutztechnisch nicht in Ordnung, sondern auch abhängig von einer Internetverbindung sowie davon, dass die Webseite tatsächlich erreichbar ist. Hier ließe sich einwenden, dass die lokalen Abhängigkeiten damit auf einem Minimum gehalten werden und die Gesamtgröße der Binary kleiner gehalten wird. Zusätzlich kann es sein, dass der Virenscanner diese Aktivität als verdächtig einstufen und das Programm allein deswegen entfernt wird.

Insgesamt stellt dies also keine gute Lösung für das Konvertieren von ODT-Dateien dar.

Python-Konvertierung

Die dritte Version enthält die Funktionalität, ein Python-Environment zu erstellen und dieses dann zu verwenden, um die ODT-Datei zu einer PDF-Datei zu konvertieren. Dabei wird die Python-Library "pandoc" verwendet. Diese kann diverse Konvertierungen von einer Mark-up-Sprache zur anderen durchführen. Eine deutlich elegantere Methode, um Dateiformate zu konvertieren. Aber auch hier kann es passieren, dass Antivirenscanner dies als verdächtig einstufen. Es ist eher ungewöhnlich, dass "normale" Programme selbst nochmal ein Python-Environment erstellen und verwenden. Wieder fehlt hier die Merge-Funktionalität und diesmal auch der "schnelle" Download.

Warum hat die Applikation so viele verschiedene "Wrapper" – also unterschiedliche legitime Funktionen in den Versionen, obwohl der Stager bei jeder Version derselbe ist? Hier kann nur spekuliert werden. Es liegt nahe, dass diese Änderungen gemacht wurden, damit sich der Hash des Installers ändert und er somit nicht mit statischer Detektierung vor der Installation aussortiert wird. Der Updater hat sich nicht geändert, also könnte dieser jedes Mal auf dieselbe Weise detektiert werden. Folglich gäbe es hier durchaus Verbesserungspotenzial für die Angreifer.

Malware Deployment

Der Stager wird von den Usern selbst heruntergeladen (MITRE T1204). Vermutlich hat die Webseite Anzeigen bei Google gekauft, wenn man z. B. "Word zu PDF" googelt. Da der Command and Control (C2)-Server zum Zeitpunkt des Schreibens dieses Blogbeitrags nicht mehr erreichbar ist, ist diese Annahme leider nicht mehr überprüfbar. Die eigentliche C2-Kommunikation findet über einen Updater in einem Scheduled Task statt (MITRE T1053).

Das Schöne an dieser Scheduled Task-Datei ist: Sie verrät einiges über die Malware.

Die Location des Updates aus dem Verzeichnis des Nutzers, der das Programm installiert hat.
Die "StartBoundary" ist auf den 8. Juli 2025 gesetzt; das bedeutet, dass das Programm an diesem Tag den Task angelegt hat (d. h. wahrscheinlich auch dann installiert wurde). Das lässt die gesamte Kampagne zeitlich besser eingrenzen. Bei Suchen im Internet Archive stellt sich heraus, dass die Kampagne um etwa diese Zeit gestartet wurde und ca. fünf bis sechs Monate lief, bevor die Infrastruktur heruntergefahren wurde.
Der Task wird auch im Kontext des aktuellen Nutzers ausgeführt mit einem interaktiven Login (Principals).
Der Task läuft nur einmal und wird bei erneutem Aufruf ignoriert, wenn eine andere Instanz bereits läuft.
Der Task startet und läuft, auch wenn das Gerät nur auf Batteriebetrieb läuft.
Der Task kann sofort beendet werden, ohne davor aufzuräumen.
Der Task startet sofort, wenn er verfügbar wird. Das heißt, auch wenn das System zu dem in der XML-Datei gegebenen Zeitpunkt ausgeschaltet ist, startet der Task, sobald das System startet.
Der Task läuft nur, wenn eine Internetverbindung verfügbar ist. (Später zeigt sich, warum.)
Die "IdleSettings" sind auch interessant:
1. Der Task läuft erst, wenn der Benutzer des Systems seit zehn Minuten inaktiv ist.
2. Der Task wartet bis zu einer Stunde, ob der Nutzer inaktiv wird.
3. Der Task läuft auch weiter, wenn der User während der Ausführung wieder aktiv wird.
4. "RestartOnIdle" lässt den Task eigentlich wieder starten, wenn er durch ein Wieder-Aktiv-Werden des Nutzers unterbrochen werden sollte. Das ist hier aber unnötig, weil "StopOnIdleEnd" auf "false" gesetzt ist.
Der Task ist nicht "hidden".
"RunOnlyOnIdle" ist auf "false" gesetzt. Also ist der gesamte Block davor mehr oder weniger unnötig.
Der Task kann bis zu 72 Stunden lang laufen.
Es wird zweimal versucht, den Task neu zu starten, wenn er fehlschlägt.

Es ist davon auszugehen, dass der Autor ein Template verwendet hat, dieses nicht aufgeräumt hat und deswegen einige unnötige Einstellungen bzw. Dopplungen vorhanden sind. Einige der Einstellungen können natürlich auch auf eine valide Funktionalität hinweisen, da die oben genannten Einstellungen auch in validen Updatern zum Einsatz kommen können.

Stager-Analyse

Da jetzt bekannt ist, wie der Updater aufgerufen wird, geht es nun um seine Funktionalität. Da dieser auch in .NET geschrieben ist, wurde dnSpy (ein .NET Debugger und Assembly Editor) verwendet, um den originalen Code sehen zu können. Dabei fallen folgende Funktionsnamen auf:

calculateMD5
serialize
deserialize
run
getSerializedTokenObj
post
decodeEncryptedContent
nameDomain
main

Der genaue Programmablauf ist folgender:

Die User ID, die bei der Installation festgelegt wird, wird zusammen mit dem Zeitstempel der Installation und dem Zeitstempel des aktuellen Zeitpunkts erst JSON-serialisiert und dann an den "/check-for-updates"-Endpunkt gesendet. Die Zeitstempel folgen dabei dem Muster yyyMM-d HH::mmss*. Es ist unklar, warum der Zeitstempel so aussieht. Dass es sich hierbei um eine Obfuskation handelt, ist unwahrscheinlich, da dies an keiner anderen Stelle der Fall ist. Es ist davon auszugehen, dass das nötig ist, weil der Zeitstempel für die AES Encryption benutzt wird. Eine weitere Möglichkeit wäre, dass dnSpy hier etwas falsch interpretiert hat.

Wenn der Request fehlschlägt, wird das Programm beendet. Wenn der Request glückt, werden dieselben Daten noch einmal an den "/get-update"-Endpunkt gesendet. Die Daten, die der Server zurücksendet, sind verschlüsselt. Um sie zu entschlüsseln, wird der Installationszeitpunkt gehasht und als Schlüssel verwendet. Der Now-Zeitstempel wird als Initialization Vector verwendet. Der entschlüsselte Content wird dann direkt in den Arbeitsspeicher geladen.

Zum Schluss wird an den "/status-ok"-Endpunkt der MD5-Hash der Nachricht gesendet – zusammen mit der User ID, damit überprüft werden kann, ob das "Update" erfolgreich war. Falls der "/get-update"-Endpunkt nicht antworten sollte oder der Request aus einem anderen Grund fehlschlägt, wird die Fehlermeldung zusammen mit der User ID an den "/status-bad"-Endpunkt gesendet.

Was liegt hier also vor? Eine ungewöhnliche selbst gebastelte Verschlüsselung; Code, der direkt in den Arbeitsspeicher geladen wird von einer eigenartigen URL, die nichts mit dem Namen der Applikation zu tun hat. Es gibt viele Überscheidungen mit tatsächlichen Updatern, aber die Indizien auf Malware überwiegen. Was genau in den Arbeitsspeicher geladen wird, lässt sich leider nicht rekonstruieren, da der C2-Server (hiko.lakienti) zum Zeitpunkt des Schreibens dieses Blogbeitrags nicht mehr existiert.

Detektion

Die Detektion fällt dann doch relativ trivial aus: Es gibt immer einen Scheduled Task und die Dateien im Verzeichnis "AppData/Local/Easy2Convert". Mit diesen Dateien sowie deren Hash kann man relativ schnell detektieren, ob man tatsächlich betroffen ist. In den Event Logs kann man häufig auch die Ausführung beobachten.

Interessanterweise wird die Ausführung in einigen Fällen einfach gestoppt, weil ein TLS-Fehler vorliegt. Seit einem Windows-Update im November 2025 schlägt jegliche Ausführung fehl. Es liegt nahe, dass Windows .NET verbietet, bestimmte TLS-Versionen für Web Requests zu verwenden. Bei einem zweiten Update im November 2025 wurde der Defender aktualisiert. Seitdem detektiert und entfernt er den Easy2ConvertUpdater.

Zusammenfassung und Fazit

Es gibt einige Indizien dafür, dass es sich hier tatsächlich um Malware handelt: Die sonderbaren Scheduled Task-Spielereien für Persistenz sowie die URL, von der die Updates abgeholt werden, die nichts mit dem Applikationsnamen zu tun hat und die es mittlerweile gar nicht mehr gibt. Außerdem stellt sich die Frage, warum man eine User ID mitschicken oder die Verschlüsselung neben TLS noch einmal mit Zeitstempeln durchführen sollte.

Ein weiterer Indikator ist diese Aussage in den Terms of Service auf der Webseite:

Screenshot der Webseite "The company cannot guarantee that the Service is free from viruses, malware, or other potentially harmful elements."

Hier versuchen die Angreifer, sich mit einem Haftungsausschluss vor eventuellen juristischen Folgen zu schützen.

Die Analyse zeigt, wie Angreifer legitime Softwarekomponenten und insbesondere Updatemechanismen missbrauchen können, um Kommunikation mit kompromittierten Systemen zu verschleiern. Da Updatedienste in vielen Umgebungen als vertrauenswürdig gelten, fällt verdächtiger Netzwerkverkehr häufig weniger auf als bei klassischer Malware.

Für die Verteidigung lassen sich folgende Erkenntnisse ableiten:

Vertrauenswürdige Anwendungen sind nicht automatisch vertrauenswürdig. Auch legitime Programme und ihre Komponenten sollten überwacht werden, insbesondere wenn sie eigenständig Netzwerkverbindungen aufbauen.
Verhaltensbasierte Erkennung ist entscheidend. Die Analyse zeigt, dass reine Signaturerkennung an ihre Grenzen stößt, wenn Angreifer bestehende Funktionen zweckentfremden.
Updateinfrastruktur sollte überwacht werden. Ungewöhnliche Verbindungen zu Updateservern, veränderte Kommunikationsmuster oder unerwartete Datenübertragungen können Hinweise auf Missbrauch liefern.
Netzwerktelemetrie bleibt ein wichtiger Baustein. Selbst wenn der Schadcode gut getarnt ist, können regelmäßige Beacon-Muster, ungewöhnliche DNS-Anfragen oder verdächtige HTTP-/HTTPS-Kommunikation auffallen.

Letztendlich verdeutlicht die Analyse, dass moderne Angreifer zunehmend auf den Missbrauch vorhandener Funktionen setzen, anstatt ausschließlich eigene Malware-Komponenten einzuschleusen. Für Verteidiger bedeutet dies, dass das Verständnis legitimer System- und Anwendungsprozesse genauso wichtig ist wie die Analyse klassischer Schadsoftware.

Indicators of Compromise

Im Folgenden werden die Indicators of Compromise, also die gefundenen forensischen Artefakte, aufgelistet:

hiko[.]lakienti[.]com
Easy2ConvertUpdater.exe
SHA256: 27262F4BF8096F04E53309D4CE603CFBEB27ED10ABDF1C461D3CCB14E012F61E

Malware in einem PDF-Converter – Analyse einer Schadsoftware