Ein zuvor nicht dokumentierter Windows-Loader, der als OXLOADER verfolgt wurde, liefert den CASTLESTEALER-Infostealer über bösartige Google Ads aus, mit niedrigen Erkennungsraten über statische Engines und Sandbox-Detonationen. Der Loader verwendet mehrere Verschleierungsschichten (Control-Flow-Flattening, opake Prädikate, gemischte Boolesche Arithmetik), selbstmodifizierende Entschlüsselungsstubs und nutzt den Windows- .reloc -Abschnitt aus, um Shellcode zu stufen.

Elastic Security Labs identifizierte OXLOADER in einer aktiven Kampagne, die sich gegen einen unserer Kunden richtete; Ausschlüsse der GUS-Region und russischsprachiger Sprache deuten auf einen finanziell motivierten, russischsprachigen Bedrohungsakteur hin. Wir haben keine vorherige öffentliche Berichterstattung über diese Familie gefunden.

Wichtigste Erkenntnisse

• Elastic Security Labs entdeckt neuen Loader (OXLOADER)
• OXLOADER beobachtet in Kampagnen, die CASTLESTEALER über bösartige Google Ads verbreiten
• Ausschluss der GUS-Region und russische Sprachprüfungen deuten auf einen russischsprachigen, finanziell motivierten Bedrohungsakteur hin
• Niedrige Detektionsraten bei statischen Triebwerken und Sandbox-Detonationen
• Elastic Defend stoppt die gesamte Angriffskette mithilfe fortschrittlicher Präventionsfunktionen

Wie Malvertising OXLOADER an Opfer lieferte

OXLOADER wird über bösartige Google Ads verteilt, die Node.js imitieren. Opfer werden über eine Zwischendomäne zu einem von Storj gehosteten Batch-Skript weitergeleitet, das OXLOADER herunterlädt und ausführt.

Die Infektion begann, als der Nutzer nach einem lts version of node.js suchte und auf ein gesponsertes Ergebnis klickte, das zu node-js[.]prentiva99[.]infoführte, einer bösartigen Landingpage , die sich als legitime Node.js Bereitstellungsplattform ausgeben sollte. Der Bedrohungsakteur betrieb eine Google-Ads-Kampagne, die sich an Opfer in den USA richtete; die Anzeige wurde zuletzt am 23. April 2026gezeigt, und die Seite ist nun offline. Der Werbetreibende war unter dem verifizierten Namen ВОЛОДИМИР ТЕРЕЩЕНКОregistriert, mit Sitz in der Ukraine. Ob dies den tatsächlichen Betreiber, ein Frontkonto oder eine gekaufte Identität widerspiegelt, bleibt unklar. Am 14. Mai 2026wurden der Werbetreibende zusammen mit den zugehörigen Werbekampagnen vollständig von Google entfernt.

Bei der Interaktion wurde der Nutzer über app[.]miloyannopoulos[.]com/download?subid1=downloadumgeleitet, das mit einer 302 Found auf die Nutzlast-URL link[.]storjshare[.]io/raw/jux4e4ky5mruo4jkxsssp42sau4q/ruslan/BATPackageBuilderSetup.batreagierte. Dies lieferte ein Windows-Batch-Skript, das auf Storjs legitimem Link-Sharing-Dienst gehostet wurde und das der Bedrohungsakteur ausnutzte, um domänenbasierte Reputationsfilterung zu umgehen.

Das Batch-Skript zeigt eine gefälschte Softwareinstallations-Wizard-Benutzeroberfläche an, lädt sofort die nächste ausführbare Datei von der Storj-URL link.storjshare[.]io/raw/jwwvr4oskkkjsgevt774ta62ehya/ruslan/aBsvwbdas.exe über PowerShell herunter und startet sie mit -Verb RunAs , um eine UAC-Elevation auszulösen.

Nach der Ausführung des Batch-Skripts erkannte Elastic Defend bösartiges Verhalten (die Richtlinie war auf Erkennung gesetzt), wodurch mehrere Verhaltensregeln ausgelöst wurden, darunter Microsoft Common Language Runtime Loaded from Suspicious Memory, was auf einen Hinweis hindeutete. NET-basierte Nutzlast, die mit CASTLESTEALERübereinstimmt.

Im Folgenden befindet sich das Ausführungsdiagramm der Angriffskette vom Payload-Download bis CASTLESTEALER Deployment.

OXLOADER-Malware-Loader: technische Analyse

Die erste OXLOADER-Sample, die unser Team analysiert hat, gibt sich als das beliebte Tool API Monitor von rohitab.com aus. Aufgrund der starken Präsenz legitimer Code- und Code-Verbergtechniken kann dieser Loader gegen statische Dateianalysatoren unauffällig bleiben.

Wie sich OXLOADER zur Laufzeit selbst entpackt

Die Malware beginnt während der CRT-Initialisierungsphase, bevor Benutzercode ausgeführt wird. Die CRT-Funktion cinit() ruft initterm()auf, die die C++-Initialisierertabelle (__xc_a → __xc_z) durchläuft, wobei jeder Eintrag aufgerufen wird. Der Malware-Entwickler hat einen dieser Einträge gekapert und zeigt auf eine Funktion, die einen RegisterClipboardFormatW() Aufruf macht, bevor sie in den ersten Entschlüsselungs-Stub springt.

Der Loader verwendet selbstmodifizierende Techniken mit mehreren Entschlüsselungs-Stubs, um sich selbst zu entschlüsseln. Im Folgenden ist ein Beispiel für ein Entschlüsselungs-Stub, der während der Laufzeit gepatcht wird, bevor man darauf springt.

Nachdem das Patchen erfolgt ist, entschlüsselt der Loader einen Bereich mit 28.233 Bytes. Jedes Byte wird mit einem einzelnen XOR-Schlüssel entschlüsselt, der nach jeder Iteration aktualisiert wird: Das gerade entschlüsselte Klartextbyte wird dem Schlüssel hinzugefügt, das dann zur Entschlüsselung des nächsten Bytes verwendet wird. Diese ähnliche Entschlüsselungsroutine läuft insgesamt dreimal, jeweils über einen anderen Bereich.

Verschleierungstechniken, die verwendet werden, um statische Erkennung zu umgehen

OXLOADER überbricht die automatisierte Funktionsgrenzerkennung in binären Analysetools wie IDA Pro mithilfe von vier Schichten der Verschleierung: Kontrollflussabflachung (CFF), gemischtes Boolesch-Arithmetisches (MBA), undurchsichtige Prädikate und Funktionschunks über nicht zusammenhängende Coderegionen. Funktionen werden durch bedingungslose Sprünge zusammengesetzt, und einige Regionen werden durch indirekte Sprünge erreicht, deren Zieladressen zur Laufzeit mittels MBA-Arithmetik berechnet werden. Das Ergebnis ist, dass IDA Pro keine Funktionsgrenzen zuverlässig rekonstruieren kann und manuelle Korrekturen erfordert.

Der Loader entschlüsselt verschiedene Strings zur Laufzeit mit folgendem String-Entschlüsselungsalgorithmus:

uint32_t obf_xor_a1_with_a2_plus_33FDA(uint32_t a1, uint32_t a2) { 
return a1 ^ (a2 + 0x33FDA); 
}

Nachdem der Code vollständig entpackt und entschlüsselt ist, kombiniert die Malware diese Entschlüsselungsfunktion mit einem Adler-32-API-Hashing-Algorithmus, um seine Importe dynamisch zu lösen.

Wie umgeht OXLOADER Sandbox- und VM-Erkennung?

Nach der Auflösung seiner APIs führt OXLOADER verschiedene Prüfungen durch, um sicherzustellen, dass die Maschine in einer sauberen Umgebung ausgeführt wird, und vermeidet so die Ausführung in Sandbox-Umgebungen.

Die erste Prüfung versucht, sich mit einer absichtlich fehlgeleiteten Netzwerkressource (*72s@1s) zu verbinden, indem mpr!WNetAddConnection2Wverwendet wird. Diese Technik scheint Emulation/Sandboxen zu verhindern, die eine erfolgreiche Verbindung bedingungslos anhängen oder zurückgeben können. Der Malware-Entwickler überprüft diesen Aufruf, indem er direkt auf das TEB zugreift und die LastErrorValueabruft. Der Loader erwartet, dass dieser Fehlercode ERROR_BAD_NAME (0x43)ist, falls der Fehlercode etwas anderes als dieser Wert ist, nimmt die Malware den Fehler-Branch und stoppt die Ausführung.

Der zweite Check ist ein Anti-Sandbox-Test basierend auf der Prozessoranzahl: Der Loader verlangt, dass der Host mindestens 3 CPUs hat, um fortzufahren. Viele Sandboxen und Analyse-VMs sind mit ein oder zwei CPUs ausgestattet, um Ressourcen zu sparen, sodass diese Schwelle diese automatisierten Analyseumgebungen herausfiltert.

Die nächste Prüfung verwendet GlobalMemoryStatusEx() , um zu überprüfen, ob der Host mindestens 3 GB physischen Speicher zur Verfügung hat.

Eine weitere Überprüfung verwendet WMI, um die Bildwiederholrate des Systemdisplays abzufragen, führt die WQL-Anweisung SELECT CurrentRefreshRate FROM Win32_VideoController aus und vergleicht den zurückgegebenen Wert (in Hertz) mit einem Schwellenwert von 20. Physische Monitore melden in der Regel etwa 60 Hz oder höher, während headless und standardvirtualisierte Konfigurationen typischerweise 0 oder 1 und Werte darunter 20 den Loader zum Abbruch bringen.

Geografische und sprachliche Ausschlüsse

Die letzten beiden Prüfungen stoppen die Ausführung, wenn sich der Host in einem CIS-Land befindet oder für die russische Sprache konfiguriert ist. Die erste Überprüfung in dieser Kategorie verwendet GetUserGeoID , um die geografische Region des Systems abzurufen und sie mit einer fest codierten Liste von GEOIDs des GUS-Landes zu vergleichen.

Die zweite Prüfung verwendet GetUserDefaultUILanguage und stimmt mit LANGID (0x419 - Russian, Russia), der Standardkonfiguration für eine russischsprachige Windows-Installation überein.

Shellcode-Staging über .reloc Abschnitt und OCX-Datei

Nachdem alle Prüfungen bestanden sind, erstellt die Malware eine Kopie der Windows DirectUI Engine DLL (C:\Windows\System32\dui70.dll), die sie an einem temporären Ort mit einem zufällig generierten Namen mit der .ocx -Erweiterung (PFHemkxVk.ocx) speichert. Diese Erweiterung inspirierte den Familiennamen OXLOADER.

OXLOADER erstellt dann einen neuen Abschnitt namens (.xtext) in dieser Ziel-DLL (PFHemkxVk.ocx).

Dieser neue Abschnitt (.xtext) ist mit RWX-(Lesen/Schreiben/Ausführen)-Schutzmaßnahmen konfiguriert, um die nächste Stufe des bösartigen Codes zu speichern und auszuführen.

Diese aktualisierte DLL (PFHemkxVk.ocx) wird dann über LoadLibraryAin den bestehenden Loader-Prozess geladen.

In einer normalen Windows-ausführbaren Datei enthält der Abschnitt .reloc eine Tabelle mit IMAGE_BASE_RELOCATION Blöcken, die der Windows-Loader anwendet, um absolute Adressen zu patchen, wenn das Image an einer anderen Adresse als seiner bevorzugten Basis geladen wird. In dieser Probe verwendet der Malware-Entwickler
Der .reloc Abschnitt zum Speicher von bösartigem Code statt der Basis-Umzugseinträge. Dies ist ein starkes Warnsignal in der statischen Analyse: Legitime Toolchains geben keinen Code in den .reloc -Bereich ein.

Dieser Shellcode aus dem .reloc -Abschnitt wird dann in den neu erstellten Abschnitt (.xtext) in der OCX-Datei kopiert, und der Loader ruft diesen Code auf.

Wie bereits beobachtet, wird ein weiterer Entschlüsselungsstub verwendet, um diese nächste Stufe zu entpacken.

Infostealer-Übertragung im Speicher über DonutLoader und .NET-Assembler

Dieser Next-Stage-Shellcode ist eine Nutzlast, die von DonutLoader konfiguriert wurde, einem Open-Source-Shellcode-Generator, der verwendet wird, um .NET-Assemblies, DLLs und EXEs in positionsunabhängigen Shellcode (PIC) für die In-Memory-Ausführung zu hüllen. Beim Entpacken entschlüsselt der Shellcode die eingebettete Konfiguration und den Ausführungskontext des Loaders mithilfe der Chaskey-LTS-Blockchiffre im CTR-Modus mit dem Schlüssel (6E0A1F8F77F7011561F6F9CA96B71B8F) und IV (956C6128E9362E075F8D006C93616A66).

Nach der Entschlüsselung wird die Nutzlast über aPLib dekomprimiert und dann über die RunPE() - Funktion von DonutLoader bootstrappt. Die letzte Nutzlast ist ein neu entdeckter Informationsdieb von Huntress namens CASTLESTEALER. Diese Zuordnung basiert auf demselben AES-Schlüssel, der für C2-Kommunikation verwendet wurde und zwischen 0xDEADBEEF Markern in einer vorherigen Probe gefunden wurde.

Zweite OXLOADER-Variante: derselbe Loader, anderes maskiertes Programm

Eine zweite OXLOADER-Variante gibt sich als Node.js-Installer aus, anstatt API-Monitor, verwendet jedoch denselben Loader-Mechanismus.

Am 13. Mai , 2026, entdeckten wir, dass der Redirektor-Endpunkt app.miloyannopoulos[.]com/download mit einem von zwei zufällig ausgewählten Location Headerfeldern antwortete:

• https://link.storjshare[.]io/raw/jv5uebuqwzfpmtahj34q753ptykq/node/BATPackageBulderSetup.bat
• https://link.storjshare[.]io/raw/jvsmdybqmvwep2oawbobp6ub7aza/node/node-v24.15.0-x64-86.exe

Das Batch-Installationsskript (BATPackageBulderSetup.bat, mit einem Tippfehler für "Builder") blieb weitgehend identisch. Der einzige Unterschied war, dass die Storj-Nutzlastverbindung nun auf ein anderes Binärprogramm namens node-v24.15.0-x64-86.exeverwies.

Die Nutzlast versucht, sich als harmloser CMake-Code auszugeben, während sie "Node" im Dateinamen beibehält, wahrscheinlich um das Lockthema zu erhalten. Wir glauben, dass die frühere "API Monitor"-Probe wahrscheinlich ein Verteilungsfehler des Betreibers war.

Bei der Ausführung bemerkten wir dasselbe Muster: indirekte Sprünge zur Selbstentschlüsselung im Speicher, gefolgt vom Laden von mpr.dll und einem Aufruf zu WNetAddConnection2W. Wir haben bestätigt, dass es sich um den identischen Lademechanismus handelt, der zuvor besprochen wurde, und diese Probe lädt ebenfalls CASTLESTEALER.

Unten ist ein Ausschnitt, in dem die Selbstentschlüsselung stattfindet. Dummy-CMake-bezogene Strings scheinen als Argumente an einen Funktionsaufruf übergeben zu werden, der unmittelbar nach dem Aufruf einen kleinen Entschlüsselungsstub in den Speicher patcht. Die Ausführung springt dann zum Stub, um nachfolgende Anweisungen zu entschlüsseln, und dieser Prozess wiederholt sich 2 weitere Mal, bis der Haupt-Malware-Körper entschlüsselt ist.

Fazit: Warum Verteidiger OXLOADER verfolgen sollten

OXLOADER befindet sich noch in einer frühen Betriebsphase, aber die dahinterstehende Technik legt nahe, dass diese Familie beobachtenswert ist. Die Code-Verschleierung, Anti-VM-Maßnahmen, harmlos wirkender Code, der zur Tarnung seiner Binärdateien verwendet wird, und die einzigartigen Staging-Techniken spiegeln bewusste technische Entscheidungen wider, um der Analyse zu entgehen. Diese Investition zahlt sich aus, was zu niedrigen Erkennungsraten bei statischen Triebwerken und Detonationsläufen führt und dem OXLOADER ein Zeitfenster zum Betrieb gibt, bevor es gejagt wird.

REF8372 über MITRE ATT&CK

Elastic verwendet das MITRE ATT&CK-Framework , um gängige Taktiken, Techniken und Verfahren zu dokumentieren, die Bedrohungen gegen Unternehmensnetzwerke einsetzen.

Taktiken

Taktiken stellen das Warum einer Technik oder Untertechnik dar. Es ist das taktische Ziel des Gegners: der Grund für die Ausführung einer Aktion.

• Ressourcenentwicklung
• Erstzugriff
• Ausführung
• Tarnung
• Discovery
• Command and Control
• Erfassung
• Exfiltration

Techniken

Techniken stellen dar, wie ein Angreifer ein taktisches Ziel erreicht, indem er eine Aktion ausführt.

• Infrastruktur erwerben: Malvertising
• Phasenfunktionen: Malware hochladen
• User Execution: Malicious File
• Befehls- und Skriptinterpreter: PowerShell
• Mechanismus zur Kontrolle der Rechteerweiterungen bei Missbrauch: Umgehen der Benutzerkontensteuerung
• Verschleierte Dateien oder Informationen: Verschlüsselte/codierte Datei
• Dateien oder Informationen dekodieren/entschlüsseln
• Verschleierte Dateien oder Informationen: Eingebettete Nutzlasten
• Maskierung: Übereinstimmung mit dem legitimen Namen oder Standort
• Hijack-Ausführungsablauf: DLL-Querladen
• Virtualisierung/Sandbox-Umgehung: System-Checks
• System Location Discovery: System Language Discovery
• Reflektierendes Laden von Codes

Sanierung REF8372

Verhütung

• Potenzielle Erkennung von Browserinformationen
• Mögliche Umgehung durch Hardware-Breakpoints
• Verdächtige Thread-Kontextmanipulation
• VirtualAlloc-API-Aufruf von einer nicht signierten DLL
• Verdächtige Remote-Speicherzuweisung
• Ausführung aus verdächtigen Stack-Trailing Bytes
• Microsoft Common Language Runtime Loaded from Suspicious Memory
• Suspicious PowerShell Execution (Verdächtige PowerShell-Ausführung)
• Modulstampfen aus einer kopierten Bibliothek

YARA

Elastic Security hat YARA-Regeln erstellt, um diese Aktivität zu identifizieren.

• Windows.Trojan.OxLoader
• Windows.Trojan.CastleStealer

Beobachtungen

Die folgenden Observablen wurden in dieser Studie diskutiert.