How SHADOW#REACTOR uses harmless looking text files to deliver Remcos RAT

Threat Group – Unattributed, activity consistent with an initial access broker model
Threat Type – Multi stage loader chain delivering remote access capability
Exploited Vulnerabilities – None publicly confirmed, primary access relies on user execution and script based lures
Malware Used – Remcos RAT delivered via SHADOW#REACTOR staging and loader framework
Threat Score – 🔴 7.6 High
Last Threat Observation – 14 January 2026

Overview

The modern threat landscape is increasingly shaped by the sophistication of delivery mechanisms rather than novelty of the final payload. SHADOW#REACTOR illustrates this shift clearly. The end payload is Remcos RAT, a widely abused remote access trojan. The defining risk is the infection chain that delivers it.

This campaign uses a complex, multi layered text only staging pipeline designed to make perimeter inspection and static file analysis less effective. It chains together obfuscated Visual Basic Script launchers, resilient PowerShell downloaders, in memory reconstruction via reflective .NET loading, .NET Reactor protected loader logic, and trusted Windows tooling such as MSBuild.exe. The result is a modular and resilient kill chain that reduces early on disk indicators and blends malicious execution into normal looking operating system activity.

Targeting is broad and opportunistic across enterprise and small to medium business environments. The operational intent aligns with an initial access broker workflow. The objective is persistent stealthy access that can be monetised through follow on activity such as data theft or resale of access to downstream operators. This makes even a seemingly generic RAT outcome a credible precursor to a later high impact incident.

Threat Landscape and Risk Context

SHADOW#REACTOR reflects a strategic pivot towards living off the land techniques. Operators increasingly prefer legitimate pre installed system tools over custom binaries because it complicates detection, reduces friction, and often bypasses simplistic allow listing approaches.

In this campaign, the tool chain is a deliberate traversal of trust boundaries.

• Windows Script Host is trusted to run scripts through wscript.exe
• PowerShell is trusted to automate administrative workflows through powershell.exe
• MSBuild is trusted to compile and execute build tasks through MSBuild.exe

Security programs that rely on the assumption that signed Microsoft binaries are safe can be undermined by this chaining. The execution context becomes the key detection signal, not the vendor signature.

This campaign also highlights the weaponisation of benign file formats. Text files are used as transport containers for encoded binary content. This technique aims to reduce scrutiny from network controls that prioritise executable formats. It also increases the chance that a payload can traverse environments where deep inspection of text responses is limited.

Risk is further elevated by the initial access broker model. Once a foothold is established, the same infected endpoint can be used to assess organisational value and to enable follow on operations. This can include credential theft, internal reconnaissance, lateral movement, and delivery of secondary payloads by other operators.

Strategic Context and Victimology

Operational shift to living off the land

Living off the land activity is not new. What is changing is how cleanly adversaries chain these tools into cohesive pipelines that mimic legitimate workflows.

In SHADOW#REACTOR, the progression from script host to automation engine to build engine is a calculated path through common enterprise trust zones. Each stage is a plausible process in isolation. When chained together, it becomes a high confidence malicious sequence.

This has practical implications for detection engineering.

• Alert on unusual parent child relationships, not only on process names
• Alert on tool usage that deviates from workstation norms, such as MSBuild running on non developer endpoints
• Increase the value placed on script telemetry, including PowerShell script block logging and command line capture

Victimology and the initial access broker model

Targeting is described as broad and opportunistic with no single vertical focus. This aligns strongly with initial access broker behaviour, where the objective is portfolio growth rather than a single mission outcome.

In this model, compromised endpoints are assessed for:

• access to valuable systems or credentials
• network topology and reachability
• presence of privileged accounts and administrative tooling
• potential for lateral movement and persistence

High value environments can be monetised through resale to ransomware affiliates or other criminal operators. Lower value environments may still be used for botnet aggregation, spam infrastructure, or opportunistic data theft.

Operationally, this means that a confirmed Remcos foothold should be treated as an incident response priority even if no immediate ransomware activity is observed.

Technical Architecture

Campaign design principles

SHADOW#REACTOR is modular and resilient. Malicious logic is fragmented across stages, formats, and execution environments. This reduces single point failures and allows rapid stage replacement without redesigning the full chain.

Core design principles observed in the campaign include:

• staging through text intermediates rather than direct binary downloads
• self healing download logic that validates retrieved content
• in memory reconstruction to reduce on disk executable artefacts
• protective wrapping of loader logic using commercial .NET protection tooling
• trusted binary proxy execution using MSBuild

Table 1. High level stage map

Infection Lifecycle

Stage 1 Obfuscated VBS launcher

The chain typically begins with a user initiated event. This is commonly execution of a script delivered via social engineering. The entry artefact is an obfuscated VBS file using generic naming such as win64.vbs or win32.vbs.

A key behavioural marker is error suppression. The launcher is designed to minimise user visible symptoms and to continue execution despite minor errors. This improves success in real world environments and reduces user reporting.

The VBS launcher does not implement the full malicious workflow. Its core job is to spawn PowerShell with an encoded payload. To evade static inspection, the launcher uses string manipulation and runtime reconstruction. One documented technique is deliberate corruption of the base64 encoded PowerShell command using placeholder characters that are normalised at runtime. This ensures the fully valid malicious command is not present in clear form on disk.

Defender focus points for stage 1:

• wscript.exe spawning powershell.exe
• unusually long command lines, especially those consistent with encoded command usage
• execution from user writable locations such as TEMP or Desktop

Stage 2 Resilient PowerShell stager

Once PowerShell is launched, the staging phase begins. The PowerShell component is responsible for reaching out to remote infrastructure and retrieving the next stage as a text file rather than a binary.

A defining feature is the download and validate loop. The stager repeatedly attempts to download the next stage until basic integrity conditions are satisfied. Validation checks include file existence and a minimum size threshold.

This is a sophisticated operational resilience pattern.

• It reduces the impact of transient network disruption.
• It reduces the chance that interception block pages or partial responses break the chain.
• It can wait out temporary enforcement or inconsistent filtering behaviour.

This also provides defenders with a strong behavioural signal. Repeated retrieval attempts from PowerShell to the same host and path pattern can be correlated with local staging file writes.

The stager commonly drops an additional PowerShell script into TEMP with a seemingly random name such as jdywa.ps1. This script performs transformation and decoding of the staged text content, then transitions execution into a .NET assembly loaded directly in memory.

Stage 3 Text only staging pipeline

This campaign uses text files as transport containers for payload bytes. Common naming patterns include qpwoe32.txt, qpwoe64.txt, teste32.txt, teste64.txt, and config.txt.

The qpwoe pattern appears intentional. It resembles a keyboard walk sequence on a standard QWERTY layout. The naming appears random enough to blend into noise while still being easy for operators to track.

The security significance is in the transport method.

• Text files do not contain standard executable headers.
• Network controls often apply different inspection strategies to text responses compared to binaries.
• File based controls may not treat the download as an executable event.

The content within these text files is not plain text. It is structured encoded data that represents binary payload content after transformation. Documented transformation techniques include placeholder substitution and string manipulation that must be reversed before base64 decoding yields usable bytes.

This layering can reduce detection by basic pattern matching and can complicate quick triage.

Stage 4 In memory reconstruction and reflective loading

After decoding the staged text, the PowerShell script holds the resulting bytes in memory. Rather than writing an executable to disk, it uses .NET reflection to load the bytes directly as an assembly within the PowerShell process memory space.

This fileless approach shifts defensive emphasis.

• Traditional file scanning sees less.
• EDR telemetry and memory visibility matter more.
• Script block logging becomes critical for reconstructing execution behaviour.

A common method here is reflective assembly loading through an Assembly.Load style call. After loading, a specific method is invoked as the orchestrator entry point. At that point, control passes from script into managed code running in memory.

Stage 5 .NET Reactor protected loader

The in memory loader is protected with .NET Reactor. This is a legitimate commercial protection tool that applies obfuscation and other defensive techniques to .NET code. In malware operations, it increases analysis cost and slows reverse engineering.

Protections typically associated with this style of packer include:

• control flow obfuscation that reduces readability
• string encryption where indicators only exist at runtime
• anti tamper measures that frustrate decompilation
• partial native compilation that breaks straightforward managed code analysis

The protected loader functions as the brains of the chain. It orchestrates further staging, handles configuration retrieval and decryption logic, and prepares for final payload execution.

Stage 6 MSBuild abuse as a trusted execution proxy

The campaign uses MSBuild.exe as a living off the land binary to execute final stage logic within a trusted process context.

MSBuild is widely present on Windows endpoints and is digitally signed by Microsoft. It is commonly whitelisted by default in environments that apply allow listing rules focused on unknown executables.

The security problem is not that MSBuild exists. It is that MSBuild can be abused to compile and execute embedded tasks. Malicious operators can execute code through project file constructs that appear legitimate to simplistic controls.

In SHADOW#REACTOR, the practical outcome is that the final stage can run under MSBuild.exe. This can obscure the true payload process name in routine process inspection and can influence host firewall rules that implicitly trust Microsoft tooling.

Defender focus points for stage 6:

• MSBuild running on endpoints that are not developer workstations
• MSBuild launched from suspicious parents such as PowerShell
• outbound network activity originating from MSBuild
• unusual build task file creation in TEMP or user writable paths

Stage 7 Remcos RAT payload execution

The final payload is Remcos RAT. It provides interactive remote access and the ability to manage files, processes, and follow on tools.

Configuration is typically handled via a remotely retrieved encrypted blob referenced as config.txt and decrypted in memory into a binary configuration object. This configuration is a critical incident response artefact because it can contain controller endpoints, ports, and authentication values.

Operationally, the use of a commercial RAT provides stability and rich functionality without the cost and risk of custom malware development. It also means defenders may encounter known Remcos behaviours, but delivered through an unfamiliar staging chain.

Remcos RAT Capabilities Relevant to Organisational Risk

Remcos is often described as a remote administration tool. In adversary hands, it provides full control over the infected endpoint and supports broader intrusion objectives.

Key capability groupings relevant to incident response include:

Interactive control and operator presence

• remote desktop style interaction with live user sessions
• keyboard and mouse input control
• screen capture functionality

Data access and exfiltration support

• file system browsing and file transfer
• staged collection and packaging of sensitive documents
• credential and token access through follow on tooling

Surveillance and credential collection

• keylogging capability
• clipboard monitoring
• potential webcam and microphone abuse depending on deployment configuration

Post compromise enablement

• process listing and termination
• execution of additional tools
• persistence support and re entry capability

These capabilities explain why an initial access broker foothold is highly dangerous. The immediate infection may appear limited. The follow on leverage can be extensive.

Indicators of Compromise

Operational note
Indicators are provided for detection and retrospective hunting. This campaign is modular. Hashes and file names can vary. Behavioural sequences are often more reliable than static indicators.

File artefacts and naming patterns

Table 2. Common file artefacts and locations

Hash indicators

Table 3. Verified SHA256 sample indicators

Table 4. Verified MD5 and SHA1 for win32.vbs sample

Network intelligence

To align with a defender first posture, indicators are presented in defanged form and without live linking.

Table 5. Infrastructure indicators

Table 6. URL path patterns to hunt in proxy logs

Behavioural signatures

Table 7. High fidelity behavioural sequences

Detection and Hunting Strategy

Effective detection for SHADOW#REACTOR requires behavioural correlation. Hash based blocking should be treated as a short term accelerant, not the foundation.

Detection engineering focus areas

WScript to PowerShell handover

This is a high confidence signal. Legitimate workflows rarely require wscript.exe to spawn PowerShell with obfuscated encoded content.

Prioritise telemetry fields:

• parent image and child image
• full command line for PowerShell
• working directory and source path for the VBS file
• user context and integrity level

PowerShell plus text staging anomalies

Hunt for PowerShell network retrieval of text files that are followed by base64 decoding and reflective loading behaviours. The combination is much rarer than any single signal alone.

If you have script block logging, focus on:

• base64 decode routines
• string replacement patterns used to normalise placeholders
• use of WebClient and DownloadString or DownloadFile methods
• reflection and assembly load calls

MSBuild network activity

MSBuild should almost never talk to the public internet from non developer endpoints. Treat any outbound connection initiated by MSBuild.exe as a high priority triage item unless it is clearly explained by a controlled build system.

Correlate MSBuild activity with:

• parent process identity
• user logon session context
• presence of suspicious project files in TEMP
• outbound destinations and timing relative to earlier staging events

Threat hunting approach

Table 8. Practical hunting workflow

Mitigation and Prevention

Mitigation checklist

User Awareness
Educate users that scripts delivered as updates are high risk. Reinforce that update workflows should be validated through official channels and internal IT processes.

Email Filtering
Quarantine or block script attachments where business allows. Apply link protections that detonate and classify script downloads. Prioritise inspection for messages that encourage running scripts or enabling macro like behaviour.

Execution Control
Restrict Windows Script Host on standard user endpoints. Where feasible, change default file associations for VBS and JS files to open in a text editor rather than execute. Use application control policies to prevent unsigned and untrusted script execution from user writable locations.

Antivirus Protection
Ensure EDR is configured to capture full process trees and command lines. Alert on wscript spawning PowerShell. Alert on PowerShell launching MSBuild. Alert on PowerShell reflective loading patterns where your EDR supports it.

Two Factor Authentication 2FA
Enforce MFA for remote access and privileged operations. Treat session tokens and cookies as credentials. Prioritise phishing resistant MFA for administrative accounts where possible.

Log Monitoring
Enable and centralise PowerShell logging, including script block logging. Enable process creation logging and consider Sysmon where appropriate and tuned. Monitor outbound connections from PowerShell and MSBuild.

Regular Updates
Maintain operating system patching and keep endpoint security agents current. While no specific CVEs are confirmed for initial access, patching reduces alternative footholds and post compromise escalation options.

Control recommendations that disrupt this chain

Restrict Windows Script Host

If standard users do not require VBS and JS execution, block wscript.exe and cscript.exe for those user groups. If blocking is not feasible, restrict execution to signed scripts and approved directories.

Harden PowerShell execution context

Apply Constrained Language Mode for non administrative users where feasible. Enforce script signing for administrative scripts. Reduce the ability to run encoded commands by policy and monitoring.

Control MSBuild execution

Apply application control to limit MSBuild to developer machines and controlled build contexts. Block MSBuild execution on user workstations that do not require it. Where business constraints require MSBuild presence, block outbound network connections from MSBuild via host firewall policy and alert on any attempted egress.

Inspect text responses for encoded payload indicators

Tune web proxy content inspection to flag unusually high entropy base64 like content in text responses from untrusted destinations. This can create an early choke point for text only staging pipelines.

Risk Assessment

Threat Score alignment
A 7.6 High score is driven by the delivery chain sophistication and the operational model, not by novelty of Remcos.

Drivers of elevated risk

Resilient self healing staging
Download validation logic increases success rates in noisy networks and reduces the chance that partial blocking stops the chain.

Benign format weaponisation
Text staging reduces the likelihood of deep inspection compared to binary retrieval and can bypass simplistic content controls.

In memory reconstruction
Reflective .NET loading reduces on disk artefacts and weakens purely file based detection strategies.

Protection tooling
.NET Reactor protected loaders increase analysis time and reduce the ease of extracting indicators from static review.

Trusted binary execution proxy
MSBuild abuse can bypass allow listing assumptions and can conceal the true payload execution context.

Initial access broker monetisation path
Even if immediate impact appears limited, the foothold can become the entry point for later severe activity, including ransomware deployment by downstream operators.

Likely impacts in enterprise environments

• persistent unauthorised remote access on endpoints
• credential and session token exposure risk
• internal discovery and reconnaissance activity
• increased likelihood of follow on payload deployment
• potential data theft and operational disruption depending on downstream operator objectives

Incident response posture

Treat confirmed SHADOW#REACTOR activity as a full incident response event.

• isolate affected endpoints
• collect volatile data where possible to preserve in memory artefacts
• identify and remove persistence mechanisms
• rotate credentials and invalidate sessions from a known clean device
• perform environment wide hunts for the process chain and staging artefacts

Conclusion

SHADOW#REACTOR is a strong example of how commodity malware becomes high risk when paired with a sophisticated delivery mechanism. Its text only staging pipeline, resilient PowerShell logic, in memory reflective loading, .NET Reactor protected loader design, and MSBuild abuse demonstrate operational maturity that can outpace simplistic controls.

Defence should prioritise execution governance and behavioural correlation. Focus on the abnormal sequences that reveal the chain. Script host spawning PowerShell. PowerShell retrieving staged text payloads from external hosts. MSBuild running outside developer workflows and reaching the internet. These are the reliable detection anchors that can disrupt the kill chain before Remcos establishes durable access.

Sources

Securonix – Threat Research SHADOW#REACTOR Text Only Staging .NET Reactor and In Memory Remcos RAT Deployment – https://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/
The Hacker News – New Malware Campaign Delivers Remcos RAT Through Multi Stage Windows Attack – https://thehackernews.com/2026/01/new-malware-campaign-delivers-remcos.html
Dark Reading – Shadow Reactor Uses Text Files to Deliver Remcos RAT – https://www.darkreading.com/endpoint-security/shadow-reactor-uses-text-files-to-deliver-remcos-rat
Infosecurity Magazine – SHADOW#REACTOR Campaign Uses Text Only Staging to Deploy Remcos RAT – https://www.infosecurity-magazine.com/news/shadowreactor-text-staging-remcos/