From Inbox to Intrusion: Multi‑Stage Remcos RAT and C2‑Delivered Payloads in Network

Executive Summary

At Point Wild, our threat research continuously monitors evolving attacker techniques designed to bypass traditional security controls. Modern malware campaigns are no longer defined by a single file dropped onto disk; They are carefully orchestrated, multi-stage intrusions engineered for stealth, evasion, and persistence. This analysis uncovers a sophisticated fileless Remcos RAT attack chain that begins with a socially engineered phishing email and rapidly escalates into a fully in-memory compromise, leveraging native Windows components to evade conventional detection mechanisms.

The attack chain is initiated through a phishing email containing a ZIP attachment disguised as a legitimate business document. Upon execution, an obfuscated JavaScript dropper establishes the initial foothold and retrieves a remote PowerShell script, which acts as a reflective loader. This loader employs multiple layers of obfuscation, including Base64 encoding, Raw Binary manipulation, and rotational XOR encryption, to reconstruct and execute a .NET payload entirely in memory. By eliminating reliance on disk-based artifacts, the malware significantly reduces its detection surface while maintaining full control over the infected system.

A defining characteristic of this campaign is its abuse of trusted system binaries, specifically aspnet_compiler.exe, as a Living-off-the-Land Binary (LOLBin) to proxy malicious execution under the guise of legitimate processes. The final payload is not statically embedded but retrieved dynamically from a remote Command-and-Control (C2) server, enabling flexible payload delivery and further complicating detection. This layered execution flow( phishing → JavaScript dropper → PowerShell reflective loading → network-delivered) payload demonstrates how attackers combine scripting environments, obfuscation, and legitimate tools to operate covertly.

Notably, the use of encoded PowerShell (Base64/ASCII) alongside aspnet_compiler.exe for in-memory execution aligns with techniques observed in prior Remcos campaigns, reinforcing the reuse and evolution of proven attacker tradecraft. This campaign highlights the increasing sophistication of multi-stage, obfuscated, and fileless malware, where attackers rely on trusted binaries and encrypted execution chains to bypass security defenses.

Introduction

This research presents a comprehensive analysis of a malicious .eml sample that exemplifies this shift in attacker tradecraft. The investigated sample demonstrates a complete end-to-end infection chain, beginning with a socially engineered phishing email and progressing through multiple execution stages, ultimately resulting in the in-memory deployment of a .NET payload.

The study provides a detailed breakdown of each stage of the attack lifecycle, including:

• Initial Access: Delivery of a phishing email containing a ZIP attachment disguised as a legitimate business document
• Execution: Use of an obfuscated JavaScript file acting as a dropper via Windows Script Host
• Payload Delivery: Retrieval and execution of a remote PowerShell script using execution policy bypass techniques
• Multi-Layer Obfuscation: Decoding of embedded payloads using Base64 encoding and rotational XOR encryption
• Fileless Execution: Reflective loading and in-memory execution of a .NET Portable Executable
• Defense Evasion: Abuse of trusted Windows binaries such as aspnet_compiler.exe (LOLBin) to proxy execution
• Post-Exploitation Behavior: Command-and-control (C2) communication for tasking and data exfiltration, along with the creation of artifacts such as C:\ProgramData\remcos\logs.dat, indicating active data collection and staging.
• Network-Based Additional Payload Delivery: Retrieval of a secondary payload from a remote Command-and-Control (C2) server following initial in-memory execution, enabling extended functionality and dynamic capability enhancement

Overall, this research aims to provide both a technical deep dive into a real-world multi-stage malware campaign and actionable insights into how such threats operate, evolve, and can be mitigated in environments where traditional detection approaches face increasing limitations.

Attack Flow

Stage 1: Initial Access via Phishing Email

The attack begins with a malicious .eml file containing a ZIP attachment: MV MERKET COOPER SPECIFICATION.zip

This naming mimics a legitimate business document, leveraging social engineering to trick users into execution.

Stage 2: Malicious Attachment (JavaScript Dropper)

Inside the archive:

MV MERKET COOPER SPECIFICATION.zip contains MV MERKET COOPER SPECIFICATION.js

Analysis of MV MERKET COOPER SPECIFICATION.js :-

The extracted JavaScript file is heavily obfuscated, using string-mapping functions and encoded arrays to conceal its true behavior. This technique hides critical indicators such as URLs, commands, and object names, making static analysis difficult.

Upon deobfuscation, the script reveals the following core functionality:

• Creates ActiveX objects including:
  • WScript.Shell (command execution)
  • MSXML2.XMLHTTP (HTTP communication)
  • Scripting.FileSystemObject (file operations)
• Initiates an outbound request to download a remote PowerShell payload:

  https[:]//almacensantangel[.]com/ENCRYPT[.]Ps1

• Executes the payload using PowerShell with execution policy bypass (nop -ep bypass), ensuring unrestricted execution.

This stage is critical, as it transforms a simple phishing attachment into an active infection by retrieving and executing the next-stage payload without raising immediate suspicion.

Stage 3: PowerShell Obfuscation and Fileless Payload Execution Technique

The technique is not fully fileless, as the initial PowerShell loader exists as a file or artifact; however, the embedded payload is reconstructed, decrypted, and executed entirely in memory without being written to disk.

Analysis of Encrypt.ps1:

Step 1: Encrypted Data

This PowerShell snippet implements the first stage of a multi-layered obfuscation framework. The payload is stored as a large Base64-encoded string in the $securecontainer variable, concealing its actual content. This data is later processed through rotational XOR-based decryption in subsequent stages, making analysis difficult. Such techniques are commonly used in PowerShell malware to hide payloads and enable in-memory execution while evading detection.

Step 2: Base64 Reconstruction Module

The function $base64reconstruction removes newline characters from the encoded strings and converts them using [Convert]::FromBase64String, producing raw byte arrays for both the payload and the key.

Step 3: Rotational XOR Decryption Module

The function $xorrotational decrypts the payload by XORing each byte with a dynamically selected key byte. The key index is calculated using ($bytePosition + $rotationTracker) % $keyMaterial.Length, and the rotation state is updated as ($rotationTracker + keyByte) % 7, introducing a variable key progression.

Step 4: Decryption Orchestration Module

The $masterdecoder function invokes Base64 reconstruction for both payload and key, applies the rotational XOR decryption, and converts the resulting byte array into a UTF-8 string for execution.

Step 5:  Execution Handler Module

The $executionhandler executes the decrypted script using multiple methods: Invoke-Expression, inline script execution, and [ScriptBlock]::Create().Invoke(). It employs a try-catch fallback mechanism to ensure execution even if one method fails.

Decoded Script: In-Memory Execution of ALTERNATE.dll

After completing the decryption stages in ENCRYPT.Ps1, the recovered PowerShell script reveals a secondary execution layer responsible for loading and executing a .NET assembly entirely in memory.

The script contains a large Base64-encoded blob which, upon decoding and analysis using CFF Explorer, the embedded payload was identified as ALTERNATE.dll, confirming that the script functions as a loader for a compiled .NET binary rather than a standalone PowerShell payload.

Reflection-Based Assembly Loading

The decoded ALTERNATE.dll is loaded directly into memory using the .NET reflection API. This technique avoids writing the binary to disk, significantly reducing forensic artifacts and enabling stealthy execution, one of the core characteristics of fileless malware.

Dynamic Method Invocation

The script dynamically resolves and invokes a method within the loaded assembly. This approach allows flexible execution of the payload without hardcoding entry points, increasing adaptability and complicating static analysis.

Process-Based Execution Control

Execution of the assembly is conditionally triggered based on the absence of the Aspnet_compiler process. This likely serves as an execution guard or anti-analysis mechanism, ensuring controlled payload deployment.

Execution Behavior and Fileless Characteristics

The decoded script operates as a memory-resident loader that continuously evaluates execution conditions and triggers payload execution when criteria are met.

Notably, the malware demonstrates clear fileless execution behavior:

• The .NET assembly (ALTERNATE.dll) is loaded and executed directly in memory using reflection
• No intermediate files are written to disk during assembly execution
• The script leverages a trusted system binary (Aspnet_compiler.exe), blending malicious activity with legitimate processes
• Payload delivery and execution occur without creating traditional file-based artifacts

Second-Stage Payload Extraction: Cqeqpvzeia.exe

Further analysis revealed that the script embeds a secondary payload within a byte array assigned to $ExecutionPayload.

The byte sequence begins with 77, 90 (“MZ”), confirming that it represents a valid Portable Executable (PE) file. Unlike the initial stage, this payload is stored in its raw binary form, without additional encoding or encryption.

Although not explicitly dropped to disk by the script, this payload is passed during execution, indicating that it is likely executed via in-memory techniques such as reflective loading or process injection.

Manual Reconstruction

To analyze this payload, I manually reconstructed the byte array into a binary file:

• Converted the byte array into a binary stream
• Rebuilt the PE structure
• Validated the file using PE analysis tools

This process successfully recovered the final payload, identified as:

Observed Behavior: Living-off-the-Land Binary (LOLBins) Abuse

The use of Aspnet_compiler.exe, a legitimate Microsoft .NET utility, indicates a Living-off-the-Land (LotL) technique combined with fileless execution techniques. Instead of dropping and executing a standalone malicious executable, the attacker leverages a trusted system binary to facilitate payload execution.

Network Activity from aspnet_compiler.exe to External Host

The abused process aspnet_compiler.exe (a legitimate Microsoft .NET tool) is repeatedly performing:

• TCP Connect
• TCP Send
• TCP Receive

It is communicating from a local machine (DESKTOP-LHEVM3U on port 53352) to a remote host : 192-3-27-141.host.colocrossing.com:8087

All operations return SUCCESS, meaning the connections are active and data is being exchanged.The repeated send/receive entries indicate continuous communication, not just a one-time request.

Network Packet Analysis

The captured traffic confirms that aspnet_compiler.exe is initiating outbound communication from host to 192[.]3[.]27[.]141[:]8087, and the payload includes the path ProgramData\Remcos\logs.dat, which corresponds to an actual file present on the infected system.

Live Capture: Obfuscated Malware Delivered Across the Network

The packet capture shows a Windows PE (.EXE) file being transferred from an external host (192[.]3[.]27[.]141[:]8087) to an internal host system.

Key Points:

• PE Signature: Contains MZ header and .text / .data sections, confirming a Windows executable.
• Packed Binary: MPRESS1 indicates the executable is compressed/obfuscated, likely to evade detection.
• Transfer Pattern: Continuous TCP stream suggests full binary delivery in chunks.

The capture provides strong evidence of a maliciously packed executable being delivered in real time from an external host to a local system.

Detection and Mitigation

UltraAV, powered by Point Wild, helps defend against such threats by focusing on early-stage detection and known malicious indicators across the attack chain. This includes:

• Detection of malicious and obfuscated script files.
• Identification of encoded and packed payload patterns
• Blocking of known malicious files, URLs, and indicators of compromise (IOCs)
• Continuous updates driven by threat intelligence and malware research

While fileless malware reduces traditional disk visibility, it still depends on identifiable components such as malicious scripts, encoded payloads, and known infrastructure. By targeting these critical elements, UltraAV provides effective protection at early entry and staging points helping prevent compromise before full payload execution.

Indicators of Compromise (IOCs)

Md5/File name	Description
75b7ed9f524cdb1c6f044864c4d3353c	Initial eml file(Phishing email)
a739d0c4821d2bc1b8a226a5d8846c28	MV MERKET COOPER SPECIFICATION.zip
a5c70d896526146238a15a93dfdb2f97	MV MERKET COOPER SPECIFICATION.js
https[:]//almacensantangel[.]com/ENCRYPT[.]Ps1	Malicious payload delivery URL.
d79dbfab8af7a6f19b6abf934a90c1b7	ENCRYPT.Ps1
957b2710fef66141707064c76f1dd1a9	ALTERNATE.dll
508c092eaf1c1a178195aadfa1b7ecae	Cqeqpvzeia.exe
192[.]3[.]27[.]141[:]8087	C2 server
0a9728de22d85c6a2b375924bfb643dc	MPress Packed payload delivered from C2 server

Conclusion

This campaign follows a structured, multi-stage attack chain beginning with a phishing email delivering a ZIP attachment containing an obfuscated JavaScript dropper. The script executes via Windows Script Host and retrieves a remote PowerShell loader, which applies multiple layers of obfuscation (Base64 and XOR) to prepare the payload. The malware then performs fileless execution through reflective in-memory loading while abusing aspnet_compiler.exe as a Living-off-the-Land Binary to evade detection.

Following initial execution, the malware establishes C2 communication and performs additional network-based payload delivery, retrieving secondary components to extend functionality. Post-exploitation activity includes data collection and staging, evidenced by the creation of “C:\ProgramData\remcos\logs.dat”, confirming active exfiltration behavior.

Additional Resources

For readers interested in related Remcos research, how Remcos has evolved over time, and the latest attack techniques:

• Trojan.WinLNK/Powershell Runner – Analysis of a Remcos delivery chain leveraging LNK files and PowerShell-based staged execution https://www.pointwild.com/threat-intelligence/trojan-winlnk-powershell-runner/

• Remcos Revisited: Inside the RAT’s Evolving Command-and-Control Techniques – Overview of Remcos C2 communication patterns, modular payload delivery, and evasion techniques https://www.pointwild.com/threat-intelligence/remcos-revisited-inside-the-rats-evolving-command-and-control-techniques/