Die erste der beiden von Gen Threat Labs herausgearbeiteten Kampagnen richtete sich gegen Nutzer in Tschechien, der Slowakei, Polen und Litauen. Die Köder wirkten wie gewöhnliche geschäftliche E-Mails, darunter Versandbenachrichtigungen, Rechnungsnachrichten und Hinweise auf gescannte Dokumente. In mehreren Fällen stammten die Nachrichten aus kompromittierten Postfächern von Unternehmen. Nach Gens Darstellung wurde die Absenderidentität also nicht nur nachgeahmt: Die E-Mails kamen aus legitimen Konten, die Angreifer bereits übernommen hatten.
Gerade deshalb können SPF und DKIM weiterhin erfolgreich geprüft werden, wenn die Nachricht über autorisierte Infrastruktur verschickt wird. Auch Reputationssysteme sehen dann womöglich einen Absender mit legitimer Vorgeschichte. Der eigentliche Angriffsweg begann mit einem Anhang, der einen JavaScript-Dropper startete. Danach lief die Kette über mehrere PowerShell-Stufen bis zu Shellcode und Banking-Funktionalität; die verfügbaren Indikatoren deuteten laut Gen auf GepyS hin.
Die Malware änderte Proxy-Einstellungen und installierte eine Browser-Erweiterung, um sich möglichst nah an die Banking-Sitzung des Opfers zu setzen. Vereinfacht beschrieb Gen die Kette so: kompromittiertes Postfach, JavaScript-Dropper, PowerShell-Stufen, Shellcode-Loader sowie Manipulation von Proxy und Browser. Eine Nutzlast der dritten Stufe verwendete demnach einen 32-Bit-Loader mit positionsunabhängigem Code. Die statische Analyse zeigte MMX- und SSE-Müllinstruktionen, Sprünge in die Mitte von Instruktionen sowie eine Entschlüsselungsroutine auf Basis eines per LFSR erzeugten Schlüsselstroms mit anschließendem XOR.
Neu seien diese Techniken einzeln nicht gewesen, schreibt Gen, zusammengenommen hätten sie aber eine schnelle statische Analyse deutlich erschwert. Vergleichbare Kampagnen im ersten Halbjahr folgten laut dem Bericht ähnlichen regionalen und operativen Mustern, allerdings mit anderen Nutzlasten. In Italien führten gefälschte Rechnungs-PDFs, darunter auch Köder im Stil von Booking.com, zu bei Vercel gehosteten Skripten mit opferbezogener JavaScript-Verschleierung, zu bei Blogspot gehosteten PowerShell-Stufen und schließlich zu XWorm. In Polen wurde über Phishing mit Rechnungsthema ein steganografischer .NET-Loader verteilt, der Remcos RAT installierte.
Die zweite Fallstudie betraf Zahlungen mit Kryptowährungen. Die finale Nutzlast war hier ein mit Rust kompilierter Clipboard-Hijacker. Er überwachte kopierte Inhalte auf Wallet-Adressen für 21 Blockchain-Typen, darunter BTC, ETH und LTC. Erkannte die Malware eine unterstützte Adresse, ersetzte sie diese durch eine vom Angreifer kontrollierte. Aus Sicht des Opfers konnte die Transaktion dennoch unauffällig wirken: Adresse kopieren, in Wallet oder Börse einfügen und Zahlung freigeben.
Gen betont, dass weder die Blockchain kompromittiert noch die Kryptografie der Wallet gebrochen wurde. Die Transaktion selbst blieb gültig, doch das Ziel war bereits lokal vor der Signatur geändert worden. Hinzu kam ein spezielles Kommando-und-Kontroll-Design: Die Malware nutzte die Binance Smart Chain im Rahmen ihrer C2-Auflösung über EtherHiding. Das vollständige Backend wurde nicht in der Blockchain abgelegt. Stattdessen las die Schadsoftware Infrastruktur-Verweise aus Daten in einem Smart Contract und nutzte diese, um angreiferkontrollierte Infrastruktur zu erreichen.
Der aufgelöste Domainname, die URL oder IP-Adresse konnten blockiert, abgeschaltet oder ersetzt werden. Die Daten im Smart Contract blieben dagegen öffentlich lesbar, eigneten sich als Anknüpfungspunkt für Untersuchungen und ließen sich nicht ohne Weiteres durch gewöhnliche Abschaltungsverfahren entfernen. Deshalb altere in diesem Aufbau eine einfache Liste mit Netzwerkindikatoren schnell, so Gen. Für die Untersuchung gehörten Vertragsadresse, die Methode zum Auslesen der Daten, der zurückgelieferte Wert und die danach erreichte Infrastruktur zusammen betrachtet.