{
	"id": "03439a16-7f43-424d-bbbc-acda2a6981a6",
	"created_at": "2026-04-06T00:16:24.466127Z",
	"updated_at": "2026-04-10T03:21:28.485287Z",
	"deleted_at": null,
	"sha1_hash": "efb1874613efb4270f22dcb824fe31db4bc0f4c2",
	"title": "SHADOW#REACTOR – Text-Only Staging, .NET Reactor, and In-Memory Remcos RAT Deployment",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5376755,
	"plain_text": "SHADOW#REACTOR – Text-Only Staging, .NET Reactor, and\r\nIn-Memory Remcos RAT Deployment\r\nArchived: 2026-04-05 22:51:21 UTC\r\nBy Securonix Threat Research: Akshay Gaikwad, Shikha Sangwan, Aaron Beardslee\r\nJanuary 12, 2025\r\ntldr:\r\nThe Securonix Threat Research team has analyzed a multi-stage Windows malware campaign tracked\r\nas SHADOW#REACTOR. The infection chain follows a tightly orchestrated execution path: an obfuscated VBS\r\nlauncher executed via wscript.exe invokes a PowerShell downloader, which retrieves fragmented, text-based\r\npayloads from a remote host. These fragments are reconstructed into encoded loaders, decoded in memory by\r\na .NET Reactor–protected assembly, and used to fetch and apply a remote Remcos configuration. The final\r\nstage leverages MSBuild.exe as a living-off-the-land binary (LOLBin) to complete execution, after which\r\nthe Remcos RAT backdoor is fully deployed and takes control of the compromised system.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 1 of 31\n\nOur analysis confirms that the ultimate payload is Remcos RAT, a commercially available remote administration\r\ntool widely repurposed as malware. In this campaign, Remcos is delivered through an unusual text-only staging\r\npipeline, protected by .NET Reactor and reflective loading techniques. This approach significantly complicates\r\nstatic detection and sandbox analysis while still providing attackers with persistent, covert remote access.\r\nIntroduction\r\nThis advisory breaks down the SHADOW#REACTOR intrusion chain from the initial VBS execution through\r\nthe Remcos backdoor being fully staged, configured, and executed. The campaign is notable for its reliance\r\non plain-text intermediates (qpwoe32.txt/ qpwoe64.txt, teste32.txt/ teste64.txt, config.txt) to transport binary\r\ndata, its heavy use of PowerShell for in-memory reconstruction, and a .NET Reactor–protected loader that\r\ndecodes, reflects, and orchestrates subsequent stages.\r\nWe walk through each phase of the attack—VBS launch, PowerShell download and reconstruction logic,\r\nencoded text loaders, in-memory .NET execution, MSBuild-assisted handoff, and\r\nfinal Remcos configuration—to demonstrate how the actors combine older commodity scripting techniques with\r\nmodern obfuscation, fileless execution, and LOLBin abuse to evade detection and analysis.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 2 of 31\n\nFigure 1 Process flow using Procmon\r\nKey Findings:\r\nMulti-stage loader architecture chaining VBS, PowerShell, encoded text loaders, .NET\r\nassemblies, MSBuild, and a commercial RAT (Remcos).\r\nText-only staging pipeline using files such as qpwoe32/63.txt, teste32/64.txt, and config.txt to carry\r\nbase64-encoded and further obfuscated payload fragments.\r\nResilient PowerShell download loop that repeatedly fetches remote content until a minimum size\r\nthreshold is reached, ensuring payload integrity before execution.\r\n.NET Reactor–protected loader (MyLibrary.Helper) that performs seeded XOR string decoding\r\nand reflective in-memory loading of additional .NET code.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 3 of 31\n\nUse of MSBuild.exe as aLOLBin during late-stage execution, enabling trusted execution context and\r\nfurther defense evasion.\r\nFinal payload identified as Remcos RAT, configured via an encrypted binary configuration blob\r\n(config_dec.bin) retrieved from a remote server.\r\nPersistence and stealth mechanismsincluding wscript.exe-launched VBS/JS,\r\nPowerShell ExecutionPolicy bypass, repeated self-relaunch from %TEMP%, and benign-looking filenames\r\nsuch as Update32.exe and update.exe.\r\nTaken together, these behaviors indicate an actively maintained and modular loader framework designed to\r\nkeep the Remcos payload portable, resilient, and difficult to statically classify. The combination of text-only\r\nintermediates, in-memory .NET Reactor loaders, and LOLBin abuse reflects a deliberate strategy to frustrate\r\nantivirus signatures, sandboxes, and rapid analyst triage.\r\nSTAGE 1: Initial Execution – Obfuscated VBS Loader:\r\n1. Stage 1 Overview:\r\nThe infection chain begins with the direct retrieval and execution of an obfuscated Visual Basic Script hosted\r\nat:\r\nhttp://91.202.233[.]215/win64.vbs\r\nThis script is typically delivered via user interaction (for example, clicking a link or opening a dropped file) and\r\nexecuted using wscript.exe. Observed command-line patterns include:\r\nwscript.exe //b //nologo C:\\Users\\\u003cuser\u003e\\Desktop\\win64.vbs\r\nwscript.exe //b //nologo %TEMP%\\win64.vbs\r\nActing as a lightweight launcher, the VBS file suppresses errors, records its execution path, and constructs a\r\nheavily obfuscated base64-encoded PowerShell payload. This payload is normalized, decoded, and executed in\r\nmemory, transferring control entirely to the PowerShell stager. From an endpoint perspective, this stage is\r\ncharacterized by wscript.exe spawning powershell.exe with unusually large inline commands and minimal static\r\nindicators in the VBS itself.\r\n2. VBS Loader Behavior:\r\nThe VBS loader is designed to function as a minimal, resilient execution bridge between the initial script and the\r\ndownstream PowerShell stager.\r\nIt begins by enabling On Error Resume Next, suppressing all runtime errors to ensure silent execution and\r\nprevent visible failures that could interrupt the chain.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 4 of 31\n\nFigure 2 Win64.vbs\r\nThe script records its own execution path using WScript.ScriptFullName, which is later reused by subsequent\r\nstages for relaunch and staging logic.\r\nRather than embedding malicious functionality directly, the loader constructs a large, obfuscated PowerShell\r\npayload stored in a variable (for example, fcxugomjv). This payload is base64-encoded with deliberate\r\ncorruption, using % characters as placeholders to evade straightforward decoding.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 5 of 31\n\nFigure 3 fcxugomjv varibale contains Large obfuscated PowerShell payload\r\nUsing WScript.Shell, the VBS script launches powershell.exe—typically with hidden window execution—passing\r\nan inline command that first normalizes the encoded string (replacing % with C), then decodes it into a Unicode\r\nPowerShell script and executes it immediately in memory.\r\nThis approach creates a multi-layer bootstrap, where the VBS stage never executes malicious logic itself and\r\ninstead hands off control entirely to PowerShell. From an endpoint perspective, this behavior is characterized\r\nby wscript.exe spawning powershell.exe with unusually large inline command strings, execution from user-writable directories such as Desktop or %TEMP%, and minimal static indicators within the VBS file beyond error\r\nsuppression and WScript.Shell usage.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 6 of 31\n\nSTAGE 2: PowerShell Stagers and qpwoe Pipeline:\r\n1. Stage 2 Overview:\r\nFollowing execution handoff from the VBS loader, the decoded PowerShell stager establishes a resilient, text-based payload delivery mechanism. The script first normalizes the inherited obfuscated content by\r\nreplacing % characters with literal C values, then decodes an additional layer of PowerShell logic into memory. It\r\nuses System.Net.WebClient to communicate with attacker-controlled infrastructure at 91.202.233[.]215 and\r\ncreates a staging file, qpwoe64.txt, within the system %TEMP% directory.\r\nRather than retrieving a single payload, the stager implements a controlled download-and-validate loop,\r\nrepeatedly fetching remote content until the downloaded data reaches a predefined minimum size. This approach\r\nallows payload updates to be managed remotely and independently of the initial VBS script, while also providing\r\ntolerance against partial or failed downloads.\r\n2. Download Loop and qpwoe.txt:\r\nThe PowerShell stager selects its remote resource based on process architecture:\r\nhttp://91.202.233[.]215/t/qpwoe64.txt for 64-bit processes\r\nhttp://91.202.233[.]215/t/qpwoe32.txt for 32-bit processes\r\nDownloaded content is written to %TEMP%\\qpwoe.txt using UTF-8 encoding.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 7 of 31\n\nFigure 4 qpwoe64.txt (UTF-8 Encoded Version)\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 8 of 31\n\nFigure 5 qpwoe64.txt (UTF-8 Decoded Version)\r\nThe script then enters a loop where it validates the file’s existence and size. If the file is missing or below the\r\nconfigured length threshold (minLength), the stager pauses execution and re-downloads the content. If the\r\nthreshold is not met within the defined timeout window (maxWait), execution proceeds without terminating,\r\npreventing chain failure.\r\nThis mechanism ensures that incomplete or corrupted payload fragments do not immediately disrupt execution,\r\nreinforcing the campaign’s self-healing design.\r\n3. jdywa.ps1 and Secondary PowerShell Layer:\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 9 of 31\n\nOnce qpwoe64.txt meets the expected size criteria, the stager dynamically constructs a secondary PowerShell\r\nscript, jdywa.ps1, within %TEMP%. This script is assembled from string fragments and is responsible for\r\nadvancing execution into the .NET stage.\r\nFigure 6 jdywa.ps1\r\ndywa.ps1 performs the following actions:\r\nReads the contents of qpwoe64.txt\r\nApplies a custom transformation (for example, replacing $$ with A)\r\nBase64-decodes the transformed content into a byte array\r\nReflectively loads the resulting .NET assembly using:[System.Reflection.Assembly]::Load(byte[])\r\nInvokes the central orchestrator method MyLibrary.Helper.Ruseysn()\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 10 of 31\n\nParameters passed to Ruseysn() include a base64-encoded URL for additional configuration data (aurie), the path\r\nto the original VBS loader (byuri), a campaign identifier such as updateCheck (cafix), and a mode string (dazuf)\r\nthat governs execution behavior.\r\nThe primary PowerShell stager launches jdywa.ps1 with ExecutionPolicy Bypass and removes intermediate\r\nartifacts on error, maintaining both execution resilience and reduced forensic visibility.\r\n \r\nSTAGE 3: .NET Reactor Loader (MyLibrary.Helper):\r\n1. Stage 3 Overview:\r\nOnce the PowerShell stager has validated and processed the contents of qpwoe64.txt (or qpwoe32.txt), the\r\ntransformed text resolves to a .NET assembly protected with .NET Reactor. Before we continue, let’s discuss\r\nthe significance and use of .NET Reactor in malware.\r\nA .NET assembly protected with .NET Reactor is a compiled .NET application (DLL or EXE) that has been\r\nprocessed through .NET Reactor, a commercial code protection and licensing tool. .NET Reactor is legitimately\r\nused by commercial software vendors to protect proprietary algorithms, business logic, and enforce licensing/trial\r\nperiods, particularly in specialized vertical markets like CAD, scientific, or industrial control software. Financial\r\nand trading applications commonly use it to safeguard algorithmic trading strategies and sensitive calculations.\r\nThe gaming industry employs it for anti-cheat mechanisms and DRM implementation. Some enterprises also use\r\nit when distributing proprietary automation tools or custom business applications to clients or partners.\r\nWhat .NET Reactor Does\r\nPrimary Protection Mechanisms:\r\n1. Native Code Compilation – Converts IL (Intermediate Language) code to native x86/x64 machine code,\r\nmaking it much harder to decompile with tools like dnSpy or ILSpy\r\n2. Code Obfuscation – Applies various obfuscation techniques including:\r\nControl flow obfuscation\r\nString encryption\r\nMethod name mangling\r\nAnti-tampering checks\r\n3. Anti-Analysis Features:\r\nAnti-debugging protections\r\nAnti-VM detection\r\nIntegrity checks to prevent modification\r\nDetection of analysis tools (debuggers, memory dumpers)\r\n4. Intellectual Property Protection – License management and trial period enforcement for legitimate\r\nsoftware\r\nMalware Connection:\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 11 of 31\n\nThreat actors frequently use .NET Reactor to protect malware payloads from reverse engineering\r\nCommon in info stealers, RATs, loaders, and cryptominers\r\nMakes static analysis significantly more difficult\r\nComplicates automated sandbox analysis\r\nIn our case, we have the following .NET Reactor behaviors and strategies: After applying lightweight\r\ntransformations—such as string reversal and placeholder replacement—the content base64-decodes into a .NET\r\nbinary that is loaded entirely in memory. Decompiling reveals a namespace MyLibrary containing a Helper class\r\nthat exposes several core methods, including ReverseString(), Decode(), and Ruseysn().\r\nFigure 7 .NET Reactor Loader functions\r\nThis Reactor-protected assembly functions as a mid-stage execution controller, responsible for coordinating all\r\nsubsequent actions in the infection chain. Its responsibilities include cleaning up residual artifacts in\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 12 of 31\n\nthe %TEMP% directory, performing optional anti-analysis checks, generating additional PowerShell and VBS\r\nscripts, retrieving further remote payloads, and orchestrating late-stage execution and persistence mechanisms.\r\n2. Decode(): Seeded XOR String Decryption:\r\nAll human-readable strings within the .NET loader are concealed using a custom string decryption routine\r\nimplemented in the Decode(string base64Input, int seed) method. This function first base64-decodes the supplied\r\ninput, then XORs each byte using a rolling key derived from a static value (275937114) combined with a per-string seed. The resulting byte array is interpreted as UTF-16LE (Unicode) text.\r\nFigure 8 Decode function\r\nThis mechanism hides all sensitive values—including file paths, URLs, process names, and embedded PowerShell\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 13 of 31\n\ncommands—behind runtime decryption, significantly reducing the effectiveness of static analysis. Decoded\r\nexamples include common virtualization artifacts such as vmtoolsd and VirtualBox, as well as path delimiter\r\nsubstitutions used later in execution.\r\n3. Ruseysn(): Central Orchestrator:\r\nThe primary entrypoint of the Reactor-protected loader is the Ruseysn(string aurie, string byuri, string cafix,\r\nstring dazuf) method, which is invoked directly from jdywa.ps1. This method governs execution flow based on\r\nsupplied parameters and decoded configuration values.\r\nFigure 9 Ruseysn function start\r\nThe parameters serve the following purposes:\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 14 of 31\n\naurie – A base64-encoded, reversed URL used to retrieve remote configuration or payload data.\r\nbyuri – An obfuscated path to the original VBS loader, where $ characters are substituted for \\.\r\ncafix – A campaign or functional identifier (for example, updateCheck).\r\ndazuf – A mode string controlling conditional behavior branches.\r\nDecoding of dazuf reveals individual flags that enable or disable specific features. In the observed configuration\r\n(“02”), the loader enables temporary staging and relaunch logic while skipping both anti-virtualization checks\r\nand Startup shortcut persistence.\r\nAs part of initialization, the loader de-obfuscates file paths by restoring directory separators, resolving the true on-disk location of the VBS loader for reuse in subsequent stages.\r\n3.1. Path de-obfuscation:\r\nEarly in execution, the loader de-obfuscates file system paths that are intentionally encoded to evade static\r\ninspection. Using the Decode() routine, specific characters are restored at runtime—for example,\r\ndecoding “RmM=” with seed 8 resolves to $, while “B1w=” with seed 1 resolves to \\.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 15 of 31\n\nFigure 10 Path de-obfuscation function\r\nAs a result, an obfuscated path such as:\r\nC:$Users$usere$AppData$Local$Temp$win64.vbs\r\nis reconstructed into its true form:\r\nC:\\Users\\usere\\AppData\\Local\\Temp\\win64.vbs\r\nThis decoded value (byuri) represents the actual on-disk location of the primary VBS loader and is reused by\r\nsubsequent stages for staging, relaunch, and persistence-related operations.\r\n3.2. dazuf Mode “1”: Anti-analysis (optional, when dazuf contains “1”):\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 16 of 31\n\nWhen enabled via the dazuf mode flag (“1”), the loader performs basic anti-analysis checks by enumerating\r\nrunning processes on the host. If indicators associated with virtualized or sandboxed environments—such\r\nas vmtoolsd or VirtualBox—are detected, execution is immediately terminated.\r\nFigure 11 dazuf function contains “1”\r\nIn the observed sample, the dazuf value is set to “02”, meaning this anti-virtualization branch is disabled. As a\r\nresult, the loader proceeds directly to staging and execution logic without performing environment checks.\r\n3.3. dazuf Mode “2”: Temporary Staging and Script-Based Relaunch:\r\nWhen the dazuf mode flag includes “2”, the loader enables an additional staging layer built around temporary\r\nPowerShell and VBS scripts. In this mode, the loader dynamically constructs PowerShell commands using\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 17 of 31\n\ndecoded strings and writes them to one or more .ps1 files within the %TEMP% directory. These scripts are then\r\nexecuted using Process.Start() to spawn powershell.exe with carefully controlled command-line arguments.\r\nFigure 12 dazuf function contains “2”\r\nAt a high level, the generated PowerShell scripts perform the following actions:\r\nCopy the primary VBS loader (win64.vbs) into a temporary directory\r\nRelaunch the copied script using wscript.exe with silent execution flags (//b //nologo)\r\nSuppress visible windows and user interaction\r\nIn addition, decoded strings indicate that some scripts may implement persistence-related logic, such as creating\r\nRun-key entries or scheduling execution via Windows task mechanisms (for example, references\r\nto HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run).\r\nCollectively, Mode “2” establishes a self-reinforcing execution chain, ensuring that the VBS loader is quietly re-executed from temporary locations and that the infection can recover if earlier stages are interrupted or removed.\r\n3.4. dazuf Mode “3”: WSH Shortcut persistence:\r\nIf the loader is executed with the “3” mode flag, it enables persistence by creating a Startup-folder shortcut\r\n(.lnk). The .NET component uses the WScript.Shell COM object (WScript.Shell → CreateShortcut) to write\r\na .lnk into the current user’s Startup directory.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 18 of 31\n\nFigure 13 dazuf function contains “3”\r\nThe shortcut’s TargetPath is set to wscript.exe, and Arguments point to the staged VBS\r\n(commonly %TEMP%\\win64.vbs) so the loader is re-run automatically on logon. It also configures optional fields\r\nlike WorkingDirectory, IconLocation, and WindowStyle to reduce user visibility, then calls Save() to persist the\r\nshortcut.\r\nBecause your observed flag is “02”, this branch does not execute—meaning no Startup LNK persistence is\r\nexpected from that specific run.\r\n3.5. C2: Stage .NET assembly download (teste64.txt / teste32.txt):\r\nIn the later portion of the .NET Reactor loader, the malware pivots to retrieving the next in-memory .NET\r\nstage from the attacker’s infrastructure. It selects the download URL based on architecture — teste64.txt for 64-\r\nbit and teste32.txt for 32-bit — and pulls the content as plain text. The returned blob is then reversed and\r\nlightly de-obfuscated via a character replacement, after which it is treated as Base64-encoded assembly bytes.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 19 of 31\n\nFigure 14 .NET assembly download function\r\nOnce reconstructed, the loader performs reflective\r\nloading using AppDomain.CurrentDomain.Load(Convert.FromBase64String(…)), resolves MyApp.Program,\r\nand invokes wibqqw via reflection. We’ll look at the decoding process a little later. This call passes in\r\na LOLBin execution path (MSBuild) along with a second decoded byte array (typically sourced from the\r\nconfig-driven download path), effectively handing off execution to the next stage while keeping the\r\npayload memory-resident and minimizing direct on-disk artifacts.\r\n3.6. Config C2 via aurie (Remcos config retrieval):\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 20 of 31\n\nThis stage is controlled by the aurie argument passed into MyLibrary.Helper.Ruseysn() from the PowerShell\r\nstager. The loader first Base64-decodes aurie, which produces a reversed/obfuscated URL string, then applies\r\na reverse-string step to recover the real endpoint.\r\nFigure 15 Remcos config download function\r\naurie (Base64): dHh0LmdpZm5vYy81MTIuMzMyLjIwMi4xOS8vOnB0dGg=\r\nBase64 decode result: txt.gifnoc/512.332.202.19//:ptth\r\nReverse string → URL: http://91.202.233[.]215/config.txt\r\nAfter deriving the URL, the loader:\r\nDownloads the content from config.txt into text2\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 21 of 31\n\nReverses the downloaded string (matching the campaign’s “text-only” staging pattern)\r\nBase64-decodes it with Convert.FromBase64String(text2) to obtain a binary blob\r\nPasses that decoded blob as the second argument into the next-stage method\r\n(MyApp.Program.wibqqw(…))\r\nStructurally, this creates a clean separation of responsibilities:\r\nteste32/64.txt: delivers the next in-memory .NET stage (the “runner/controller” that exposes wibqqw)\r\nconfig.txt (resolved via aurie): delivers the payload/config blob that wibqqw consumes (commonly\r\nthe Remcos config or an encrypted payload/config package)\r\n3.7.  Final handoff: using MSBuild as LOLBin:\r\nIn the final phase of the loader chain, execution is handed off to MSBuild.exe, which is explicitly referenced\r\nusing its full framework path:\r\nFigure 16 MSBuild as LOLBin launch function\r\nAs we explained earlier with the Decode() method, the strings are XOR’d using a rolling key derived from a static\r\nvalue (275937114) combined with a per-string seed. AppDomain.CurrentDomain.Load loads the assembly (from\r\nC2), then uses the decoded strings to locate and invoke MyApp.Program.wibqqw within that assembly. Below is\r\nthe decoding/decrypting process for one of these strings.\r\nString 1: EV0nXyFhEmMUZUhnOGkYawNtCW8CcRNzGXU= (seed=2)\r\nStep 1: Base64 decode then to Hex\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 22 of 31\n\nWe derive the following value: 115d275f21611263146548673869186b036d096f027113731975\r\nStep 2: XOR decrypt each byte\r\nByte[0]: 0x11 XOR 0x5c = 0x4d\r\nByte[1]: 0x5d XOR 0x5d = 0x00\r\nByte[2]: 0x27 XOR 0x5e = 0x79\r\n… continues, ending up with this full XOR Hex key: 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f\r\n70 71 72 73 74 75\r\nUsing this key to decrypt we derive the following Hex value:\r\n4d0079004100700070002e00500072006f006700720061006d00\r\nStep 3: Decode as UTF-16 LE\r\nThe final value is “MyApp.Program”\r\nThe loader also constructs the full path C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\MSBuild.exe by\r\nconcatenating several decoded strings. This path, along with the decoded configuration or payload blob\r\nretrieved via aurie (from text2), is passed as parameters to MyApp.Program.wibqqw(…),  leveraging MSBuild as\r\na living-off-the-land binary (LOLBin) to execute the final payload under the guise of a trusted Microsoft-signed\r\ncomponent, reducing suspicion and bypassing application control policies.\r\nThis handoff marks the transition from the custom loader framework into the final payload execution phase,\r\nwhere MSBuild provides a legitimate execution context for launching Remcos RAT or performing additional\r\nmalicious actions under the guise of normal system activity.\r\nSTAGE 4: Extra Layers: Auxiliary Orchestration and Resilience Components:\r\nThe execution tree reveals additional orchestrator components, including:\r\n1. xx1.ps1 and xx2.vbs – Execution Wrappers:\r\nThe scripts xx1.ps1 and xx2.vbs function as lightweight execution wrappers designed to maintain continuity of\r\nthe infection chain.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 23 of 31\n\nFigure 17 Temp folder dropped components\r\nThese components are responsible for copying or renaming the primary VBS loader (win64.vbs) into\r\nthe %TEMP% directory and relaunching it using:\r\nwscript.exe //b //nologo\r\nExecution is typically performed with hidden window styles to suppress user visibility. By re-invoking the VBS\r\nloader from temporary locations, these wrappers enable the malware to reconstruct or re-trigger the execution\r\nchain if earlier stages fail or are interrupted, forming a self-healing loop.\r\n2. Update32.exe and update.exe – Helper Executables:\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 24 of 31\n\nAdditional helper executables, named Update32.exe and update.exe, are observed under:\r\nFigure 18 Update32.exe in PublicData folder\r\nThese binaries appear to function as late-stage helpers, potentially compiled via MSBuild or invoked\r\nduring Remcos initialization. Their generic naming and placement in a public directory are intended to blend into\r\nthe host environment and avoid raising suspicion during casual inspection or automated scanning.\r\n3. Repeated “Junk” PowerShell Invocations:\r\nThe execution chain also includes repeated PowerShell invocations with nonsensical or randomly generated\r\narguments, for example:\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 25 of 31\n\npowershell.exe yhe8qw8yq8adsfasf…\r\nThese commands serve no functional purpose in payload execution and instead act as a form of log pollution and\r\nsignature evasion. By introducing noise into command-line telemetry, the malware disrupts rule-based detections,\r\nobscures meaningful PowerShell activity, and frustrates regex-driven threat hunting techniques.\r\nTogether, these auxiliary components strengthen the campaign’s operational resilience and stealth, ensuring the\r\ninfection can persist, recover from disruption, and evade simplistic detection mechanisms even after the primary\r\nloader stages have completed.\r\nRemcos RAT Backdoor:\r\n1. Identification of Remcos\r\nNow let’s look at the config.txt blog which was downloaded via the aurie argument of the Ruseysn orchestrator\r\nmethod entry point in the Reactor-protected loader. Analysis of the decrypted configuration data retrieved\r\nfrom config.txt confirms that the final payload delivered by the SHADOW#REACTOR framework\r\nis Remcos RAT. Remcos is a commercially available remote administration tool that has been widely repurposed\r\nby threat actors for malicious use. The decoded binary configuration (config_dec.bin) which is consumed\r\nby MyApp.Program.wibqqw() method closely matches documented Remcos configuration structures,\r\nincluding characteristic field ordering, encoding patterns, and module flags.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 26 of 31\n\nFigure 19 config_dec.bin hash validation using CFF explorer\r\nTypical configuration elements observed within config_dec.bin include:\r\nCommand-and-control (C2) address and port (for example, 91.202.233[.]215)\r\nCampaign or client identifiers\r\nInstallation paths and mutex values\r\nFeature flags controlling persistence, keylogging, screenshot capture, and additional modules\r\nOptional DNS-based communication, reconnaissance, and auto-propagation settings\r\nWhile these elements are consistent with prior Remcos campaigns, in this case they are delivered through\r\na significantly more complex and evasive loader chain than is commonly observed.\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 27 of 31\n\n2. Remcos Capabilities:\r\nOnce fully deployed, Remcos provides the operator with complete remote control over the compromised system.\r\nCore capabilities include:\r\nInteractive remote desktop access\r\nFile system management (browse, upload, download, and delete files)\r\nArbitrary command execution and interactive shell access\r\nOptional keylogging and clipboard monitoring\r\nPersistence configuration and startup control\r\nProxying and tunneling features that can facilitate lateral movement\r\nWithin the SHADOW#REACTOR campaign, the entire preceding loader framework exists solely to reliably and\r\nstealthily deliver Remcos. The staged design ensures that the payload is:\r\nDelivered in an environment-aware manner, using repeated downloads and size validation to guarantee\r\nintegrity\r\nTransported via text-only intermediates that are harder for static scanners to classify\r\nExecuted from in-memory .NET assemblies, leaving minimal on-disk artifacts\r\nConfigured using an encrypted binary configuration blob, rather than a plain-text or INI-style file\r\nThis approach highlights how a relatively common RAT can be operationalized within a modern, modular loader\r\nstack to significantly increase stealth, resilience, and defender friction.\r\nWrapping up…\r\nSHADOW#REACTOR demonstrates how a commodity remote access tool such as Remcos can be\r\noperationalized within a modern, highly modular loader framework. By chaining together obfuscated VBS\r\nlaunchers, resilient PowerShell stagers, text-only payload delivery, and a .NET Reactor–protected in-memory\r\nexecution layer, the campaign significantly raises the bar for both static detection and automated sandbox analysis.\r\nEach stage—VBS execution, PowerShell reconstruction, Reactor-obfuscated .NET loading, and encrypted\r\nconfiguration handling—adds incremental friction for defenders while giving attackers flexibility to update or\r\nreplace individual components without reworking the entire chain.\r\nTo detect and disrupt campaigns of this nature, defenders should prioritize visibility into script-based execution\r\npaths, particularly wscript.exe and powershell.exe, as well as outbound HTTP activity originating from\r\nscripting engines to untrusted infrastructure. Additional focus on reflective .NET loading, text-based staging\r\npatterns, and LOLBAS abuse (including wscript.exe, powershell.exe, mshta.exe, and MSBuild.exe) will\r\nmaterially improve the likelihood of identifying these threats before the final Remcos payload is fully deployed\r\nand operational.\r\nVictimology and attribution:\r\nObserved activity associated with SHADOW#REACTOR suggests a broad, opportunistic targeting\r\nmodel rather than a focus on any specific industry or geography. The campaign primarily targets general\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 28 of 31\n\nenterprise and small-to-medium business environments, with initial access achieved through user execution of\r\nmalicious VBS scripts delivered via socially engineered lures.\r\nInfection vectors include malicious or compromised web resources, direct script downloads, and file-based\r\ndelivery that relies on user interaction, such as executing a VBS file disguised as a legitimate update or document\r\nartifact. The absence of tailored decoys or sector-specific themes indicates a spray-and-pray approach aimed at\r\nscale rather than high-value targets.\r\nFrom an attribution standpoint, the tooling and tradecraft are consistent with financially motivated operators,\r\nincluding potential initial access brokers. The use of a commercial RAT (Remcos) delivered through a modular\r\nVBS-, PowerShell-, and .NET-based loader aligns with common access-broker techniques focused on establishing\r\nresale-ready footholds.\r\nAt present, there is insufficient evidence to attribute this activity to a known threat group or nation-state\r\nactor. The infrastructure is transient, and no distinctive code overlaps or operational markers have been identified.\r\nSHADOW#REACTOR is therefore best assessed as an unattributed, financially motivated loader\r\nframework designed to deliver Remcos RAT at scale while evading detection through in-memory execution\r\nand LOLBin abuse.\r\nDefensive Recommendations:\r\nIncrease user awareness of script-based threats\r\nEducate users on the risks of executing downloaded scripts and emphasize caution around unexpected files,\r\n“update” prompts, or document-related artifacts received via web downloads or untrusted sources.\r\nValidate script execution sources\r\nRestrict or monitor execution of VBS, JS, and PowerShell scripts—particularly those originating from\r\nuser-writable locations such as %TEMP%, browser cache directories, or downloaded file paths.\r\nHarden endpoint detection and response (EDR)\r\nEnsure EDR solutions are capable of detecting suspicious script interpreter behavior, including anomalous\r\nparent-child process chains such as:\r\nwscript.exe → powershell.exe → msbuild.exe\r\nand reflective .NET assembly loading patterns.\r\nLeverage advanced PowerShell and scripting telemetry\r\nEnable enhanced PowerShell logging (ScriptBlock logging, Module logging, command-line auditing) to\r\nsurface heavily obfuscated, multi-stage payload reconstruction activity.\r\nMonitor forLOLBin abuse\r\nActively hunt for misuse of trusted binaries such as wscript.exe, powershell.exe, mshta.exe,\r\nand MSBuild.exe, especially when invoked from non-standard execution paths or user contexts.\r\nWatch for persistence artifacts\r\nMonitor for suspicious Startup folder shortcuts, scheduled task creation, and benign-looking executables\r\nwritten to %TEMP%, ProgramData, or user profile directories.\r\nSecuronixcustomers can leverage targeted threat hunting queries to identify endpoints exhibiting the\r\ncharacteristic multi-stage execution patterns via process creation telemetry, creation of text-based staging\r\nfiles (qpwoe*.txt, teste*.txt) with Sysmon EventID 11 or other FIM data sources, and in-memory .NET\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 29 of 31\n\nloading behavior (via powershell logging) associated with SHADOW#REACTOR and Remcos RAT\r\ndelivery.\r\nMITRE ATT\u0026CK Mapping:\r\nThe SHADOW#REACTOR campaign spans multiple MITRE ATT\u0026CK tactics and techniques, reflecting a\r\nlayered approach to execution, evasion, and command-and-control:\r\nTactics Techniques\r\nInitial Access T1204: User Execution\r\nExecution\r\nT1059.005: Visual Basic\r\nT1059.001: PowerShell\r\nT1620: Reflective Code Loading\r\nT1047: MSBuild Abuse / Signed Binary Proxy Execution\r\nPersistence T1060: Startup Folder / Shortcut\r\nDefense Evasion\r\nT1027: Obfuscated/Encrypted Payloads\r\nT1112 / T1116: Execution Policy Bypass and LOLBAS Abuse\r\nCommand and Control\r\nT1105: Ingress Tool Transfer\r\nT1219: Remote Access Tools\r\nRelevant Securonix detections\r\nPotential LNK Persistence File Creation Analytic\r\nUnusual process adding a file in Startup Menu-EMS\r\nPossible Stealthy Malicious Payload Assembly Unusual MSBuild Use Analytic – CEDR\r\nPossible Stealthy Malicious Payload Assembly Unusual MSBuild Use Analytic By a Rare Account –\r\nAVEDR\r\nPossible Stealthy Malicious Payload Assembly Unusual MSBuild Use Analytic – EMS\r\nPossible Stealthy Malicious Payload Assembly Unusual MSBuild Use Analytic – Microsoft Windows\r\nPotential Malicious Payload Execution Msbuild Analytic\r\nRare Powershell Destination Port For Host Analytic – EMS\r\nSuspicious Powershell Child Process Creation Analytic – EMS\r\nVbscript Execution Using Wscript App\r\nSuspicious wscript Child Process Creation Analytic\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 30 of 31\n\nRelevant hunting Queries:\r\n(remove square brackets “[ ]” for IP addresses or URLs)\r\nindex = activity AND rg_functionality = “Web Proxy” AND (destinationaddress = “91.202.233[.]215” )\r\nindex = activity AND rg_functionality = “Microsoft Windows Powershell” AND message CONTAINS\r\n“ExecutionPolicy Bypass” AND message CONTAINS “FromBase64String“ AND message CONTAINS\r\n“WebClient”\r\nindex = activity AND rg_functionality = “Endpoint Management Systems” AND deviceaction = “File\r\ncreated” AND filename IN (“win64.vbs”, “xx1.ps1”, “xx2.vbs”, ”jdywa.ps1”)\r\nC2 and infrastructure:\r\nIP\r\n91.202.233[.]215\r\n193.24.123[.]232\r\nIndicators of Compromise (IOCs):\r\nFile Name SHA256\r\nwin64.vbs 90d552da574192494b4280a1ee733f0c8238f5e07e80b31f4b8e028ba88ee7ea\r\nqpwoe32/64.txt a35a036b9b6a7baa194aef2eb9b23992b53058d68df6a4f72815e721a93b8d41\r\nteste32/64.txt 507c97cc711818eb03cfffd3743cebb43820eeafa5c962c03840f379592d2df5\r\nconfig.txt 1106b820450d0962abf503c80fda44a890e4245555b97ba7656c7329c0ea2313\r\nconfig_dec.bin (Remcos RAT) 1fd111954e3eefeef07557345918ea6527898b741dfd9242ff4f5c2ddceaa5e9\r\nUpdate32.exe 985513b27391b0f9d6d0e498b5cec35df9028a5af971b943170327478d976559\r\nSource: https://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nhttps://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/\r\nPage 31 of 31\n\nEarly in execution, inspection. Using the loader the Decode() de-obfuscates file routine, specific system paths that characters are are intentionally restored at runtime—for encoded to evade example, static\ndecoding “RmM=” with seed 8 resolves to $, while “B1w=” with seed 1 resolves to \\.\n   Page 15 of 31",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.securonix.com/blog/shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment/"
	],
	"report_names": [
		"shadowreactor-text-only-staging-net-reactor-and-in-memory-remcos-rat-deployment"
	],
	"threat_actors": [],
	"ts_created_at": 1775434584,
	"ts_updated_at": 1775791288,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/efb1874613efb4270f22dcb824fe31db4bc0f4c2.pdf",
		"text": "https://archive.orkl.eu/efb1874613efb4270f22dcb824fe31db4bc0f4c2.txt",
		"img": "https://archive.orkl.eu/efb1874613efb4270f22dcb824fe31db4bc0f4c2.jpg"
	}
}