Decrypting Embedded SMTP Exfiltration Configurations in a Phantom Stealer Variant

Introduction

Hi, I am Stephen. I have been working in SOC operations for over 5 years, mainly in an MSSP environment. My day-to-day role involves investigating multiple alerts coming from different SIEMs and EDR platforms.

I am sharing this blog post because not all SOC environments especially MSSPs have the privilege or time to reverse engineer malware found in emails. For anyone who has the same dilemma as I do, I strongly suggest practicing Blue Team scenario-based labs to further improve SOC, DFIR, threat hunting, threat intelligence, and reverse engineering skills.

All the content below is cumulative experience gained from my work and from playing these types of labs on platforms such as CyberDefender’s BlueYard, BTLO Labs, DFIRLabReport, HTB, and LetsDefend. I hope you find this write-up useful.

Tools Used

1. CyberChef — Different recipes for decoding and decrypting
2. DIE — For Static Analysis
3. Procmon — For Dynamic Analysis
4. DnSpy — For .NET Static Analysis

Incident Overview

About a month ago, our SOC team received a phishing email analysis request from one of our clients.

The email contained a PDF attachment. Inside the PDF was a specific embedded link which, when clicked, directly downloaded a ZIP file named “document_4568.zip”. Like most phishing emails, this campaign attempted to trick the victim into downloading and executing the contents of the ZIP file, often under the disguise of payment-related issues.

JavaScript Dropper Analysis

The zip file contains a JavaScript code.

Upon inspection, the file was heavily obfuscated with injected junk strings and meaningless words designed to complicate analysis. Once these unnecessary strings are removed, the actual JavaScript logic becomes visible.

Added words to make analyzing more difficult

Another injected words to obfuscate the real Java Script.

Between the lines of these injected characters, legitimate JavaScript code can be identified.

JavaScript with junk characters

Online JavaScript beautifiers and de-obfuscation tools can be used to reconstruct the code, although this can be time-consuming. Nevertheless, for analysts encountering similar scripts, using a JavaScript beautifier is often a quick way to regain readability.

Beautifying part of the JScript

To save time, I executed the JavaScript while monitoring system activity using Sysinternals ProcMon for dynamic analysis.

Snippet of Procmon

ProcMon revealed that execution of the JavaScript resulted in the following process chain:

WScript.exe → PowerShell.exe

Within the PowerShell execution, a Base64-encoded command was observed.

PowerShell Decoding and File Decryption

Decoding the Base64-encoded PowerShell command provided a clearer picture of what the JavaScript was actually doing. It is also worth noting that the PowerShell script itself contained logic explaining how the encoded content should be decoded.

Start of the PowerShell script

End of the PowerShell script

To totally decode the following, we need to replace the word “ZGXEXTFUQ” with a null or empty value.

Sample of the decoded base64 command (redacted the keys use for decryption)

The decoded PowerShell script was used to decrypt files created by the previous JavaScript dropper. It explicitly included the file paths, AES key, and IV required for decryption.

Screenshot of the PNG files

The files created were:

1. C:\Users\Public\Mands.png
2. C:\Users\Public\Vile.png

By following the decryption logic defined in the PowerShell script, these files were successfully decrypted.

Analysis of Mands.png

The first file, Mands.png, appeared to be an image based on its extension. However, inspection using a hex editor such as DIE showed that the file was actually plain text.

Format is showing as Plain Text

Opening the file will give us a base64 encoded content.

This Base64 blob was encoded and encrypted multiple times to delay investigation and evade detection.

Decoding sequence is as follows:

• Base64 decode
• AES decrypt
• Base64 decode
• Removal of null bytes

The AES key and IV were obtained directly from the decoded PowerShell script.

After decryption, another Base64 blob was revealed, along with additional decoding instructions.

By replacing the string pattern “AAAAAJAAAAAA” and “!” with an empty or null value, the final decoded script was obtained.

Main component of the decoded Mands.png

The decoded "Mands.png” script serves as a preparatory stage that disables ETW telemetry and AMSI scanning to facilitate stealthy execution of the final payload.

Analysis of Vile.png

The second file,“Vile.png”, was the actual payload. Similar to the previous file, it masqueraded as a PNG image but was in reality a text file containing Base64-encoded content.

Plain text of Vile.png

Decoded value of Vile.png

Once decoded, the output clearly indicated a Windows executable, confirmed by the string “This program cannot be run in DOS mode.”

Moreover, downloading the decoded file we can now further analyze the following payload.

The sample above is a .NET executable, enabling static and dynamic analysis through tools like dnSpy. This tool is well-suited for .NET malware analysis, as it supports de-compilation, debugging, and runtime inspection.

As I am less experienced with debugging, this write-up focuses on static analysis , specifically decrypting the SMTP configuration and attributing the malware to a known information-stealer family.

Malware Attribution via Static Analysis

By statically analyzing string artifacts, we can often get an initial idea of what the malware is doing. In many cases, this reveals C2-related artifacts such as IP addresses, URLs, or other useful keywords.

Filtering strings in DIE for keywords such as http immediately returned interesting results worth further investigation. A quick internet search for phantomsoftwares.site revealed its association with a malware family known as Phantom Stealer.

string section of DIE (filter: http)

Further filtering for the keyword phantom confirmed this attribution and helped narrow down the malware name.

string section of DIE (filter: phantom)

As a SOC analyst, I highly suggest researching the malware family early to save time. In many cases, security researchers already have high-quality write-ups that can help guide analysis. This is the same approach I followed here.

Because this is a .NET malware, static analysis becomes easier, as most functions and logic are human-readable.

When loading the malware in dnSpy, the executable name appeared as “Stub”. The stub architecture consists of multiple classes, each serving a different purpose.

The most important class to review is the Config class, as it represents the core functionality of Phantom Stealer. Its primary objective is to collect and exfiltrate sensitive data such as browser credentials, cryptocurrency wallets, banking information, local databases, and other valuable files.

Config class architecture

The .cctor() method summarizes the malware’s runtime configuration. Reviewing this section shows that multiple exfiltration methods are supported, including Telegram, Discord, SMTP, FTP, WinSCP, and FileZilla. In this variant, SMTP is the only enabled method (1 = enabled, 0 = disabled).

Exfiltration Configuration

The SMTP configuration is encrypted, understanding how to decrypt the following is the main focus of this write-up.

The “Config” class shows what types of sensitive data the malware attempts to collect and stage for exfiltration. This includes crypto-related artifacts, keyword lists used for keylogging (such as social media and other high-value accounts), banking data, specific document types by extension (PDF, DOC, XLS, etc.), databases, source code files, images, clipboard data, and even Wi-Fi credentials, depending on which modules are enabled.

Sample Snippet of data being exfiltrated

The malware also contains anti-analysis logic designed to evade dynamic analysis. Although disabled in this variant, it relies on predefined lists of sandbox indicators, suspicious GPUs, IP addresses, machine GUIDs, processes, and services. If the system matches any of these entries, the malware terminates execution and deletes itself.

Snippet of the Anti-Analysis Code

Snippet of SuspiciousProcess Code

This leads to a self-destruct feature called Melt, which kills the running process and deletes the executable to hinder post-analysis.

Snippet of Melt Code

Decrypting the SMTP Configuration

Within the same “Stub” class we can see the field named “StringsCrypt”. By reviewing the following we can understand the encryption logic behind malware’s SMTP configuration.

Snippet of the StringsCrypt Class

Inside the Decrypt field, the decryption process can be observed.

Decryption Logic

The configuration values are decrypted using AES in CBC mode. The AES key and initialization vector (IV) are derived at runtime using PBKDF2 (Rfc2898DeriveBytes) from hardcoded CryptKey and SaltBytes values defined in the StringsCrypt class.

Obtaining the Key and IV values

Under the StringsCrypt , both SaltBytes and CryptKey are stored as byte arrays. To derive the AES key and IV, these values must first be converted to their hexadecimal equivalents. Once obtained, the CyberChef “Derive PBKDF2 Key” recipe can be used to generate the required values for AES-CBC decryption.

Redacted SaltBytes

Redacted CryptKey

To correctly derive the key material, it is important to understand how PBKDF2 is implemented in the .NET framework. The Rfc2898DeriveBytes function uses HMAC-SHA1 as its underlying pseudo-random function.

The following parameters were used to derive the key and IV:

• Passphrase: Hex equivalent of Cryptkey
• Salt: Hex equivalent of SaltBytes
• Hash Function: SHA1
• Key Size: 384 bits (32 bytes for the key and 16 bytes for the IV)
• Iteration Count: 1000

Redacted Derive IV and Key values

The output consists of 48 bytes, where the first 32 bytes represent the AES key and the remaining 16 bytes represent the IV.

AES Key: 475f…86bd [Redacted]

IV: 54f5…bc81 [Redacted]

Decoding and Decrypting the SMTP Configuration

By obtaining the AES key and IV, the encrypted SMTP configuration was decrypted by performing Base64 decoding followed by AES decryption.

Encrypted SMTP Config

Decrypted SMTP Server

Decrypted SMTP Sender

Decrypted SMTP Password

Decrypted SMTP Receiver

To summarize we were able to obtain all the SMTP configuration.

1. SMTP Server [Redacted]
2. SMTP Sender [Redacted]
3. SMTP Password [Redacted]
4. SMTP Receiver [Redacted]
5. SMTP Port [Hardcoded to 25]

All decrypted values are redacted, as exposing them could allow malicious reuse.

Indicators of Compromise (IOCs)

The following hashes were extracted during the analysis and are provided as indicators of compromise for detection and hunting purposes:

C:\Users\Public\Mands.png — SHA256: b3f012d427c8b60998b7134e9183e813a22ff21560dc84771c15b6467fc58d7

C:\Users\Public\Vile.png — SHA256: 5094481266937ee8fbb04ffa19aa6b81b57c0c3ddeda498c07922b4e1660aa58

Final .NET payload (Stub) — SHA256: 4353606cc73e49985e3dbb028c3a33251193231d162ee75957c4874223090f21

These IOCs can be used to identify potential infections related to this campaign.

Summary and SOC Relevance

Phantom Stealer is an information-stealing malware designed to collect and exfiltrate a wide range of sensitive data from compromised systems. Its capabilities include harvesting browser credentials, cryptocurrency-related data, banking information, document files, clipboard content, and other valuable artifacts. In this variant, data exfiltration is performed through an encrypted SMTP configuration.

This write-up is not intended to be a standard reverse engineering walkthrough. Instead, it demonstrates how reverse engineering can directly support SOC operations during an investigation. By understanding the malware’s objective and behavior, SOC analysts can better identify what artifacts to look for and what indicators to hunt within the environment.

During the analysis, the extracted artifact, including the creation of the masqueraded PNG files, their hashes, and the decrypted SMTP configuration were searched across the client’s environment. This was done to verify whether any users who received the phishing email were compromised.

Fortunately, no hits were observed during this validation.

References: https://labs.k7computing.com/index.php/phantom-3-5-initial-vector-analysis-forensics/ https://www.proofpoint.com/us/blog/threat-insight/not-safe-work-tracking-and-investigating-stealerium-and-phantom-infostealers