Remcos RAT Infection Chain Hides Behind Obfuscated Scripts and Trusted Windows Binaries

Cybercriminals are getting better at hiding their tracks, and a recently uncovered Remcos RAT campaign is proof of that. This attack does not rely on a single malicious file dropped onto a system.

Instead, it uses a carefully built, multi-stage chain that starts with a simple phishing email and ends with a full, in-memory system compromise — leaving almost no trace on the disk.

Remcos RAT, short for Remote Control and Surveillance, has been a known threat for years. Attackers use it to steal data, log keystrokes, and remotely control infected machines.

What makes this latest campaign stand out is how it reaches the victim. Rather than relying on easy-to-spot delivery methods, this operation strings together multiple layers of obfuscation, trusted Windows tools, and a live C2 server to deliver its payload with precision.

Analysts and researchers at Point Wild’s LAT61 Threat Intelligence Team identified this campaign after examining a malicious email file (.eml).

They found that the attack begins with a ZIP attachment named “MV MERKET COOPER SPECIFICATION.zip,” designed to look like a routine business document.

Once opened, it releases an obfuscated JavaScript file that quietly sets the attack in motion, all without triggering standard security alerts.

The campaign’s impact is serious. Once fully deployed, Remcos establishes a persistent connection to a remote C2 server at 192[.]3[.]27[.]141:8087, actively sending and receiving data.

Evidence of data collection was confirmed through the creation of a log file at C:ProgramDataremcoslogs.dat, which stores captured keystrokes and other system information. This indicates the malware was actively staging data for exfiltration.

What makes this threat particularly difficult to stop is its ability to hide inside the very tools Windows users trust every day.

By abusing legitimate system binaries and running entirely in memory, the attackers managed to bypass many traditional security defenses. This kind of attack shows how far threat actors have come in designing operations that blend into normal system activity.

Multi-Stage Infection Mechanism: From Phishing to In-Memory Execution

The infection begins the moment a user opens the phishing email and extracts the ZIP file.

Inside the archive is a JavaScript file — MV MERKET COOPER SPECIFICATION.js — that is heavily obfuscated using string-mapping functions and encoded arrays to hide its true purpose.

Upon execution via Windows Script Host, the script creates ActiveX objects to handle HTTP communication, command execution, and file operations, and then contacts almacensantangel[.]com to download a remote PowerShell script called ENCRYPT.Ps1.

The PowerShell loader applies multiple layers of obfuscation to rebuild the payload in memory.

The data is stored as a large Base64-encoded string inside the $securecontainer variable, which the $base64reconstruction function converts into raw byte arrays.

A rotational XOR function then decrypts the data using a shifting key mechanism, and the $masterdecoder function brings the full decryption together.

The $executionhandler finally runs the recovered script through Invoke-Expression with built-in fallback methods.

The decrypted script reveals a .NET assembly called ALTERNATE.dll, loaded directly into memory through .NET Reflection APIs with no file written to disk.

A secondary payload, Cqeqpvzeia.exe, is embedded as a raw byte array starting with the “MZ” PE signature and injected into aspnet_compiler.exe — a legitimate Microsoft .NET tool — through a Living-off-the-Land technique.

This abused process handles all outbound C2 communication, making malicious traffic appear as routine system activity.

Organizations should monitor PowerShell execution events, especially those involving Base64-encoded commands and execution policy bypass flags.

Outbound connections from system utilities like aspnet_compiler.exe to unknown external hosts should be treated as suspicious.

Security teams should also watch for the file C:ProgramDataremcoslogs.dat as a key indicator of compromise. Blocking known malicious URLs, hashes, and C2 infrastructure from the IOC table remains a critical step in containing this threat early.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.