Contents
- Introduction
- Campaign Overview
- Initial Access
- Infection Chain
- Technical Analysis
- Stage 1: Initial Delivery (Archive→JavaScript)
- Stage 2: PowerShell Loader1 Analysis
- Stage 3: PowerShell Loader2 Analysis
- Stage 4 – Phantom Stealer v3.5.0: Data Harvesting and Exfiltration
- Campaign Attribution
- Conclusion
- IOC’s
- Seqrite Detection Coverage-
- MITRE Attack Tactics, Techniques, and Procedures (TTP’s)
Introduction
Phishing campaigns continue to evolve by disguising themselves as routine business communications that recipients are likely to trust. During our investigation, we uncovered a campaign that employs multiple phishing lures to distribute the malicious JavaScript files packaged within compressed archive attachments. Although the emails impersonate different trusted entities including a global logistics provider and a government tax authority, they ultimately lead to an identical multi-stage infection chain.
Once executed, the JavaScript downloader launches an obfuscated PowerShell script that performs the entire malicious workflow in memory, significantly reducing its on-disk footprint and making detection more challenging. The infection chain ultimately deploys Phantom Stealer v3.5.0, which harvests sensitive information from the compromised system and exfiltrates the collected data via SMTP using encoded content.
This campaign highlights how threat actors are increasingly combining convincing business themed social engineering with layered obfuscation and fileless execution techniques to bypass conventional security defenses and compromise enterprise environments.
Campaign Overview
The campaign relies on well-crafted phishing emails that imitate routine business communications to lure recipients into executing a malicious JavaScript file hidden inside compressed archive attachments. During our analysis, we identified two distinct phishing emails delivering the same malware through different social engineering themes.
The first email impersonates UPS Forwarding Hub, presenting shipment booking details and quotation information to entice users involved in procurement or logistics-related activities. The second masquerades as an official notification from the Malaysian Inland Revenue Board (LHDN), requesting documentation for a corporate tax audit to pressure recipients responsible for finance or regulatory compliance.
While the lures differ, both exploit familiar business workflows that demand timely attention. By leveraging trusted brands, realistic business scenarios, and a sense of urgency, the attackers increase the likelihood that recipients will open the attached archive and execute the embedded JavaScript.
Initial Access
The campaign begins with phishing emails crafted to resemble legitimate business communications. During our investigation, we observed two phishing emails built around different business scenarios, yet both followed the same attack chain.
· Email 1 – UPS Shipment Notification
The first phishing email impersonates UPS Forwarding Hub and presents itself as a routine shipment booking request. Addressed to a procurement mailbox, the email references a shipment number, quotation ID, delivery details, and consignee charges, making it appear consistent with legitimate logistics communications exchanged during day to day business operations. To reinforce its authenticity, the email includes branding, shipment information, and a compressed archive attachment that supposedly contains the related shipping documents.
Interestingly, the shipment details reference a quote dated June 25, 2025, despite the email being sent in June 2026, indicating that the phishing template was likely recycled from an earlier campaign or assembled without thoroughly updating all fields.
· Email 2 – Malaysian Tax Audit Notice
The second phishing email impersonates the Malaysian Inland Revenue Board (LHDN) and is written entirely in Malay, giving it the appearance of an official tax audit notification. It requests supporting documentation for the 2026 corporate tax assessment and imposes a 14-day submission deadline to create a sense of urgency. By referencing legitimate tax forms, government departments, and official contact information, the attackers attempt to establish credibility and persuade recipients to open the attached archive.
The localized language and regulatory context make the email appear consistent with routine business correspondence involving tax compliance.
A Common Delivery Mechanism
Although the social engineering themes differ, both emails distribute the same malicious JavaScript file packaged inside compressed archives. This indicates that the attackers reuse a consistent malware delivery chain while adapting the lure to different business scenarios.
Infection Chain
Fig -3 illustrates the complete infection chain observed during our analysis. The campaign employs a layered execution workflow in which each stage progressively reconstructs and launches the next component, ultimately deploying Phantom Stealer v3.5.0
Technical Analysis
Stage 1: Initial Delivery (Archive->JavaScript)
Both phishing emails deliver a compressed archive attachment. The contained JavaScript is disguised using filenames that closely match the theme of the phishing email. Across the observed samples, the attackers use business relevant names such as-
- UPS Docs_Shipment Number 3264010420-Quote ID 203263067.js
- Bank in slip for invoice of MAY’26 MBB531540 dd 20042026.js
- CKHT800A_RUJ ATC13529CWYE25M.js
By tailoring the filename to the social engineering lure, the attachment appears to be a legitimate shipping document, banking record, or tax related file, increasing the likelihood that recipients will execute it without suspicion.
Analysis of JavaScript File
Rather than immediately executing malicious activities, the script first conceals its functionality through multiple layers of string obfuscation and indirect function calls.
Function names, method calls, command strings etc. are replaced with numeric indices that reference hidden string arrays, making the script appear significantly more complex than it actually is.
The script contains numerous helper functions that simply perform basic arithmetic or comparison operations. These wrappers provide no functional benefit but substantially reduce readability by forcing analysts to trace multiple layers of indirection before reaching the actual execution logic. The encoded string arrays are initialized only once and subsequently reused further obscuring the execution flow.
JavaScript Loader’s Capabilities
While the obfuscation initially conceals the script’s behavior, recovering the embedded strings provides a clear picture of its intended functionality. The decoded strings reveal references to PowerShell, native Windows COM objects, file operations, and WMI, all of which point to a carefully designed loader rather than a standalone malware payload.
These artifacts indicate that the JavaScript is responsible for preparing the execution environment, reconstructing the next stage, and transferring control to PowerShell. This layered approach keeps the core payload hidden until runtime, making static analysis significantly more challenging.
Embedded Base64 Payload
One of the most notable characteristics of the loader is the presence of a large Base64 encoded blob embedded directly within the JavaScript source. Rather than downloading the next stage from an external source, the JavaScript loader embeds an entire Base64 encoded PowerShell script within its source code.
The encoded payload is stored as a JavaScript object property and is reconstructed only during execution, allowing the loader to remain self contained while concealing the actual PowerShell logic from static inspection.
After completing its initialization, the JavaScript retrieves the embedded Base64 encoded PowerShell payload stored within the encodedData object. Using native Windows COM components, the loader decodes the embedded content, reconstructs the PowerShell script, and writes it to a temporary .ps1 file. It then invokes powershell.exe with hidden execution parameters to transfer control to the next stage of the infection chain.
A typical execution sequence of JavaScript executing PowerShell is as follows –
Stage 2: PowerShell Loader1 Analysis
Rather than embedding the next stage directly in plaintext, the PowerShell loader stores it as an AES encrypted payload. The encrypted content, encryption key, and initialization vector (IV) are all embedded within the script as Base64 encoded strings. This allows the loader to remain completely self contained while ensuring that the actual malicious logic remains concealed until runtime.
Before the encrypted payload can be decrypted, the script removes whitespace and line breaks from the embedded Base64 strings to reconstruct a continuous data stream. It then converts the cleaned strings into byte arrays using the .NET Convert.FromBase64String() method. The same routine is reused to process the encrypted payload, AES key, and initialization vector.
AES Decryption Routine
Once the Base64 encoded components are converted into byte arrays, the loader reconstructs the hidden payload using the .NET AesCryptoServiceProvider class.
The script configures the cipher to operate in CBC mode with PKCS7 padding before creating a decryptor object that processes the encrypted data entirely in memory. By relying on native .NET cryptographic libraries instead of custom decryption routines, the loader achieves a reliable and compact implementation while concealing the next stage until execution.
The decrypted bytes are written to a MemoryStream through a CryptoStream, allowing the entire decryption process to occur in memory.
Execution
After successfully recovering the plaintext script, the loader immediately transfers execution using Invoke-Expression. This allows script to execute it directly from memory, allowing the next stage to begin without creating an additional files on the compromised system.
Stage 3: PowerShell Loader2 Analysis
Stage 3 in this infection chain is another Base64 decrypted blob resulted in PowerShell from stage 2.
Unlike the previous stage, which focuses on decrypting the embedded script, this loader is responsible for recovering a protected .NET assembly, monitoring the execution environment, and launching the assembly directly from memory without writing it to disk.
Preparing the Final Payload for Reflective Execution
Analysis of the secondary PowerShell script revealed that it embeds two distinct payloads, each serving a different purpose in the infection chain.
· Payload 1: Injector
The first payload is stored as a Base64 encoded blob protected with a simple XOR cipher. This assembly acts as an in-memory injector responsible for executing the subsequent stage.
Before execution, the PowerShell loader decodes the Base64 data and applies an XOR decryption routine using the hardcoded key “DEVILboy56@@” to reconstruct the original assembly in memory.
Successful XOR decryption of base64 blob result in .NET assembly, loaded directly into memory.
· Payload 2: Phantom Stealer
A second payload is embedded in PowerShell loader as a raw byte array stored in decimal format.
Examination of the byte array revealed the “MZ” DOS header (4D 5A), confirming that it is a valid Portable Executable (PE) image rather than shellcode or encoded data. Unlike the first payload, this PE is not decrypted by the PowerShell script. Instead, it is passed directly as an argument to the reflective .NET assembly together with the path to the legitimate aspnet_compiler.exe binary.
This design clearly separates the responsibilities of each component.
- The PowerShell script functions primarily as an orchestrator, recovering the reflective loader and supplying it with the target process and embedded PE payload.
- The actual injection and execution logic is delegated to the in-memory .NET assembly, significantly reducing the complexity of the PowerShell stage while concealing the final malware until the next stage of execution.
Stage 4 – Phantom Stealer v3.5.0: Data Harvesting and Exfiltration
After successfully executing the reflective .NET loader, the attack culminates in the deployment of Phantom Stealer v3.5.0. The stealer focuses on harvesting a broad range of sensitive information from the compromised system, including host information, installed applications, browser credentials, cookies, stored payment information, cryptocurrency wallets, and data associated with popular messaging applications. By collecting information from multiple sources, the malware aims to maximize the value of the compromised host before initiating exfiltration.
Information Harvesting
Phantom Stealer enumerates the infected system and gathers information from numerous applications and user profiles. The collected data includes system information, installed software, browser credentials, cookies, saved payment cards, browsing history, and files associated with cryptocurrency wallets and messaging applications. The harvested information is organized into separate files based on the application or data type, simplifying subsequent exfiltration.
Examples of harvested artifacts include:
- Chromium_passwords_<hostname>.txt
- Chromium_credit_cards_<hostname>.txt
- Chromium_cookies_<hostname>.json
- Gecko_passwords_<hostname>.txt
- Gecko_cookies_<hostname>.json
SMTP Authentication
After establishing a session, the malware authenticates with the SMTP server using the AUTH LOGIN mechanism. The username and password are transmitted in Base64 encoded form before the SMTP server grants access to relay outgoing email.
During our analysis, the following credentials were observed:
Username (Base64): cnVoaUBha3Rla21ldGFsLmNvbS50cg==
Decoded to: ruhi@aktekmetal[.]com[.]tr
The password is similarly transmitted in Base64 encoded form before authentication is completed successfully.
When we decoded base64 data harvested by threat actor (shown in Fig. 18), we found the actual data in below format.
SMTP Based Data Exfiltration
Phantom Stealer transmits the collected information directly through the Simple Mail Transfer Protocol (SMTP). Dynamic analysis revealed that the malware establishes an SMTP session over TCP port 587, the standard submission port for authenticated email delivery. After connecting to the mail server, the malware initiates an Extended SMTP (ESMTP) session using the EHLO command and subsequently upgrades the communication channel through STARTTLS, ensuring that the transmitted credentials and stolen information are protected by TLS encryption during transit.
Rather than combining all stolen information into a single archive, Phantom Stealer generates multiple files, each corresponding to a particular application or credential category.
After successfully transmitting the collected information, the malware gracefully terminates the SMTP session using the QUIT command. This completes the email transaction using standard SMTP semantics, allowing the malicious communication to closely resemble legitimate outbound email traffic.
Campaign Attribution
At the time of analysis, we found no conclusive evidence linking this campaign to a specific threat actor or intrusion set. While the final payload is identified as Phantom Stealer v3.5.0, the malware is widely available within the cybercriminal ecosystem and has been adopted by multiple operators.
Conclusion
This campaign demonstrates how modern phishing operations have evolved beyond simple malware delivery into carefully orchestrated, multi-stage attack chains. By impersonating legitimate business communications related to logistics, banking, and regulatory compliance, the attackers increase the likelihood of user interaction while concealing a sophisticated execution workflow behind seemingly routine documents.
Rather than exposing the final payload directly, each stage reveals only the next component in the infection chain significantly increasing the complexity of static analysis and reducing opportunities for early detection.
For organizations, this campaign serves as a reminder that convincing business-themed emails, even those appearing to originate from trusted logistics providers, financial institutions, or government agencies, should be treated with caution. Strengthening email security, educating employees to verify unexpected attachments, restricting unnecessary script execution, and monitoring for suspicious PowerShell activity, reflective memory loading, process injection, and unusual outbound SMTP traffic can significantly improve the chances of detecting similar threats before sensitive information is compromised.
This campaign highlights the importance of a defense-in-depth strategy, where email security, endpoint protection, behavioral monitoring, and network visibility work together to identify sophisticated, multi-stage attacks that may evade traditional signature-based detection.
IOC’s-
6BBFC88534D5D515DDDB0EC9BB618530
8A620E451E64F418BC21FD458E952F2E
5F238710A5EF4F6DDBBE7A118C822705
a30b628d0c087f305b35be3e3f5281b3
34bfa888695b9aaa41bd575245972043
Seqrite Detection Coverage-
Trojan.Injector.S39585891
Trojan.YakbeexMSIL.ZZ4
PS.Trojan.Loader.50921.GC
Js.Trojan.Loader.50922.GC
MITRE Attack Tactics, Techniques, and Procedures (TTP’s)
| Tactics (ATT&CK ID) | Techniques / Sub-technique (ID) | Procedure |
| Initial Access (TA0001) | Phishing: Spearphishing Attachment (T1566.001) | Delivers malicious ZIP attachment |
| Execution (TA0002) | Command and Scripting Interpreter: JavaScript (T1059.007) | Executes obfuscated JavaScript |
| Execution (TA0002) | Command and Scripting Interpreter: PowerShell (T1059.001) | Launches hidden PowerShell |
| Stealth (TA0005) | Obfuscated/Compressed Files and Information (T1027) | Uses multi-layer obfuscation |
| Stealth (TA0005) | De-obfuscate/Decode Files or Information (T1140) | Decodes Base64, AES, and XOR payloads |
| Stealth (TA0005) | Reflective Code Loading (T1620) | Loads .NET assembly from memory |
| Stealth (TA0005) | Masquerading (T1036) | Uses business-themed filenames |
| Stealth (TA0005) | Process Injection (T1055) | Injects payload into aspnet_compiler.exe |
| Stealth (TA0005) | System Binary Proxy Execution (T1218) | Abuses legitimate .NET binary |
| Discovery (TA0007) | System Information Discovery (T1082) | Collects host information |
| Discovery (TA0007) | Process Discovery (T1057) | Checks target process status |
| Credential Access (TA0006) | Credentials from Password Stores (T1555) | Extracts stored credentials |
| Credential Access (TA0006) | Credentials from Web Browsers (T1555.003) | Steals browser credentials and cookies |
| Collection (TA0009) | Data from Local System (T1005) | Collects local application data |
| Collection (TA0009) | Archive Collected Data (T1560) | Organizes stolen data into files |
| Exfiltration (TA0010) | Exfiltration Over Alternative Protocol (T1048) | Exfiltrates data via SMTP |
| Command and Control (TA0011) | Application Layer Protocol: Mail Protocols (T1071.003) | Uses SMTP protocol |
| Command and Control (TA0011) | Encrypted Channel (T1573) | Encrypts SMTP using STARTTLS |
Authors
- Prashil Moon
- Manoj Kumar Neelamegam
