Fileless Malware Intrusion — From a Phishing Lure to a Remcos RAT

This is a sanitized account of a real Managed Detection and Response (MDR) investigation. Account names and hostnames are placeholders; network indicators are replaced with RFC 2606 (example) domains and RFC 5737 (documentation) IP ranges, and file hashes are withheld. The malware behavior, tooling, and analysis are real and unchanged.

Executive Summary

On 4 April 2026, the MDR team alerted the client to a suspicious process on a user's workstation making an outbound connection to an external IP address. Incident response was initiated to determine the scope and impact of the activity. The investigation confirmed that a single user account on a single host was in scope; no lateral movement or additional affected systems were identified.

The root cause was a social-engineering lure. The user opened a link from within a trusted business application — a cloud case-management (CRM) platform — that downloaded a malicious JavaScript file disguised as a request-for-quotation (RFQ) document. Running that file launched a fileless infection chain: a hidden PowerShell dropper decoded a payload held entirely in memory, retrieved a second stage concealed inside a PNG image using steganography, and ultimately loaded Remcos 7.2.5 Pro — a commercial remote-access tool routinely abused for full remote control, credential theft, and surveillance. Almost nothing was written to disk, and the endpoint anti-virus raised no alert; it was network telemetry that exposed the command-and-control (C2) channel. Once the user ran the file, a live C2 connection was established in a matter of seconds.

Timeline

All times UTC on 4 April 2026, drawn from DNS, EDR process, and Sysmon network-connection telemetry.

Investigation & Analysis

Initial access

The client reported that the user had opened a support case in a cloud case-management platform and clicked an embedded link. Rather than arriving by email — where it would have been subject to gateway and attachment controls — the lure reached the user inside a trusted, authenticated business application, which is a large part of why it was clicked. DNS telemetry confirmed that at 13:04:39 UTC the host resolved and connected to the attacker-controlled URL hxxps://rfq-download[.]example/Request-for-Quotation.js, downloading a JavaScript file named to impersonate a request-for-quotation document — a common lure in business-email-compromise and malware-delivery campaigns.

The file landed at D:\Users\jdoe\Downloads\Request-for-Quotation.js. (The user profile residing on the D: volume is consistent with a cloud-hosted virtual desktop image.) A copy of the file was retrieved from the hosting URL in a controlled sandbox for analysis.

The dropper: Request-for-Quotation.js

Analysis showed that Request-for-Quotation.js is a fileless dropper. On execution it uses Windows Management Instrumentation (WMI) to launch a hidden PowerShell process, masking the activity as routine system-service behavior:

Figure 1 — Hidden PowerShell command launched by the dropper on WKSTN-01.

The dropper decodes its true payload using layered ROT13 and hex-to-ASCII transformations and writes the result into a user environment variable named INTERNAL_DB_CACHE — a deliberately mundane, database-sounding name chosen to blend into the environment. The PowerShell command above then reads that variable back and executes it directly in memory with [ScriptBlock]::Create(), so the malicious logic never lands on disk as a script file.

Fileless execution and payload staging

Sysmon network-connection logs showed the hidden PowerShell process connecting to the hosting infrastructure at 13:11:33, followed at 13:11:35 by execution of the INTERNAL_DB_CACHE payload — a heavily obfuscated PowerShell downloader. Two techniques stood out during analysis: variable and string names are randomized to defeat signatures, and the second-stage URL is split and reassembled at runtime to evade static extraction. In the example below, every s has been replaced with a # in the stored string and restored at runtime with a .Replace('#','s') call:

Figure 2 — Reconstructed logic from the INTERNAL_DB_CACHE payload (variable names normalized, indicators sanitized). The real payload was several kilobytes of randomized, base64-like text.

The downloader spoofs a browser User-Agent and pulls a file called 6363.png from a subdomain on Cloudflare's workers.dev platform. The specific subdomain incorporated the name of an unrelated developer account that had been abused to host the payload; that account name is redacted here.

Secondary payload: steganography in a PNG

The acquired 6363.png masquerades as a harmless image but uses steganography to conceal an obfuscated, Base64-encoded .NET DLL. That DLL is a trojanised build of Microsoft.Win32.TaskScheduler — a legitimate open-source .NET library for managing Windows scheduled tasks — repurposed to act as an in-memory loader. Because it executes directly in memory, no corresponding file-write was observed on the local disk.

Once initialised, the loader reaches out to a second hosting location — a Cloudflare R2 bucket at hxxps://[redacted].r2[.]dev/6363.png — to retrieve, inject, and execute the final payload.

Final payload: Remcos 7.2.5 Pro

The final payload is Remcos 7.2.5 Pro, a commercial remote-administration tool heavily abused by threat actors for surveillance, data theft, and full remote control of infected systems. Consistent with the fileless design, no Remcos binary or on-disk execution artifact was found; its presence was confirmed by network telemetry — an outbound connection from MSBuild.exe (a trusted Microsoft build utility abused here as a living-off-the-land injection host) to the C2 server at 203.0.113.91 on port 2026. That successful beacon confirmed the injection and command-and-control sequence had completed.

Anti-virus and third-party security logs were reviewed for any related detection or remediation events; none were found. No further suspicious activity was observed on the host after the C2 connection was established.

Why stage the payload?

A fair question about this chain is why the actor bothered with an intermediate stage at all — concealing a loader inside a PNG rather than having the first PowerShell command fetch and run Remcos directly. Every extra stage is, after all, another event a defender might catch. Several factors make the trade worthwhile from the attacker's side:

• It removes the most signature-able artifact. A script that directly retrieves a known remote-access trojan is the highest-confidence detection opportunity in the entire chain — the executable download, the disk write, and the known bytes in memory are all things endpoint anti-virus is built to catch. Split across stages, no single step carries a complete malicious executable for a scanner to match. The trade is a certain static detection for a possible behavioral one; in this incident, AV alerted on none of it.
• The PNG launders the content type. Retrieving an image from a high-reputation cloud platform looks unremarkable to a web proxy: image content types are commonly allowed, scanned lightly or not at all, and the hosting domains are used heavily by legitimate services. The same request for an executable would have taken a very different inspection path. The file was also a structurally valid PNG, so it passed file-type validation.
• The final payload is not in the delivered file. Because Remcos was fetched on demand, anything examining the dropper later — a sandbox, or an analyst working from the artifact alone — may find the hosting removed, geofenced, or serving something else, and never recover the final stage. That is not hypothetical here: no Remcos binary was found on the host, and its presence had to be established from network telemetry. On-demand retrieval also lets the operator gate who receives the payload and swap it without rebuilding the lure.
• Much of the design is bought, not authored. Remcos is commercial software, and loader chains of this shape are routinely sold as a service. The staging was likely built by that supplier for many customers rather than tailored to this victim, so its structure reflects the vendor's goals rather than a decision made about this environment.
• The fileless design requires a loader. To run a payload in memory and never write it to disk — where on-access scanning lives — something has to perform the loading, and that component has to arrive from somewhere. Dropper → in-memory .NET loader → RAT is close to the minimum number of steps that keeps the payload off disk entirely.

The counter-argument — that staging also hands defenders more opportunities to intervene — is correct, and it is exactly what happened here. The chain is behaviorally loud even though it is statically quiet: wscript.exe spawning hidden PowerShell through WMI, and MSBuild.exe opening an outbound connection on a non-standard port, are both strong signals. Staging is effectively a bet that the defender is oriented around disk and signatures rather than behavior and network telemetry. Against an anti-virus-only environment that bet pays; here it did not — though not before the C2 channel was live.

Findings & Root Cause

• Root cause — social engineering through a trusted channel. The intrusion began with a user clicking a malicious link delivered inside an authenticated business application, bypassing the email-security controls that would normally inspect such a lure.
• User execution was required. The .js dropper only ran because the user opened it; on Windows, .js files execute through wscript.exe by default — a long-standing delivery weakness.
• Fileless, in-memory tradecraft defeated disk-based detection. The payload lived in an environment variable and executed via [ScriptBlock]::Create(); the loader and RAT ran in memory. The endpoint anti-virus produced no alert.
• Living-off-the-land binaries (LOLBins). The chain abused wscript.exe, powershell.exe, WMI, and MSBuild.exe — all legitimate, signed Windows components — to blend malicious activity into normal system behavior.
• Detection came from the network. With almost no disk footprint, it was the outbound C2 beacon on a non-standard port that surfaced the compromise — underscoring the value of network and behavioral telemetry alongside endpoint AV.
• Scope. A single user and a single host were affected; no lateral movement, additional hosts, or data exfiltration beyond the C2 channel were identified.

MITRE ATT&CK techniques observed

Containment & Remediation

The following actions were recommended to contain the incident and restore the affected account and host to a trusted state:

• Rebuild the affected host from a known-good image. Because the malware ran in memory and abused trusted system binaries, manual clean-up or an AV scan cannot be relied on to fully restore integrity; re-imaging from a trusted baseline is the safe option.
• Reset credentials for the affected account. All passwords used by the account should be changed promptly — including any stored in credential managers — on the assumption they may have been captured. Users should choose genuinely new passwords rather than incrementing a single character (e.g. Example1! → Example2!), in line with NIST memorized-secret guidance, and multi-factor authentication should be enforced.
• Block the malicious domains and IP addresses at all appropriate network controls — firewalls, web proxies, and DNS — including the lure host, the payload-hosting subdomains, and the C2 address and port.
• Hunt for the indicators in the appendix across the estate to confirm the activity was isolated to the single host.

Response and blocking actions of this kind can be executed directly from the MDR platform's automation and response tooling.

Corrective actions

• User-awareness training. Deliver phishing-awareness training — stressing that malicious links can arrive through trusted business applications, not only email — and give users a simple way to report suspicious links or messages to security for analysis. Repeat at regular intervals.
• Restrict script execution. Consider changing the default handler for .js/.vbs files so they open in a text editor rather than executing, and constrain PowerShell (Constrained Language Mode, script-block logging, and execution policy) where operationally feasible.
• Egress filtering. Restrict and monitor outbound traffic — particularly connections to non-standard ports and to newly-registered or low-reputation domains and developer-platform subdomains (workers.dev, r2.dev and similar).

Lessons Learned

• Trusted channels are a blind spot. Email security did nothing here because the lure never touched email. Awareness training and detection logic have to account for links arriving through SaaS and business applications.
• Endpoint AV alone is not enough against fileless malware. Nothing meaningful was written to disk and AV stayed silent; the compromise was caught by network and behavioral telemetry. Defense in depth — EDR behavioral detection plus network monitoring — is what closed the gap.
• Watch the LOLBins. wscript.exe spawning powershell.exe via WMI, and MSBuild.exe making outbound connections, are high-signal behaviors worth alerting on regardless of the AV verdict.
• Speed matters. The automated chain went from execution to an established C2 channel in seconds. The window to disrupt an intrusion like this is short — which is exactly the case for fast, telemetry-driven detection and response.

Indicators of Compromise

Indicators are sanitized for publication: domains use the RFC 2606 example namespace, IP addresses use the RFC 5737 documentation ranges, and file hashes are withheld. Notation is defanged (hxxps, [.]). The structure and relationships between indicators reflect the real activity.

File indicators

Network indicators