Detecting Malware Script Loaders using Remcos: Threat Research Release December 2021

Nowadays, malware used to have several stages before it fully compromised the targeted host or machine. The very well-known initial stager is the “phishing email” that contains a malicious macro code or malicious URL link that will download either the actual loader or the next stager to download the actual payload. 

This particular sample makes the detection and analysis of the adversary behavior more challenging. The most prevalent loaders seen in the wild are window scripting languages, JScript (.js), and VBScript (.vbs). These scripts are easy to obfuscate and encrypt in order to bypass detection and preventative controls, therefore many adversaries use this methodology. In this blog, Splunk Threat Research (STRT) will discuss a Remcos loader that utilizes DynamicWrapperX (dynwrapx.dll) to execute shellcode and inject Remcos RAT into the target process. Ultimately STRT covers what Splunk Security Content detections find behaviors and TTPs that apply to the DynamicWrapperX Loader. 



The Initial Downloader

This Remcos sample loader starts with a simple VBScript that attempts to download the second VBScript from The script on is the main loader of Remcos. Below is the screenshot of the initial downloader script. STRT has witnessed the script stay online up to a few weeks between major campaign changes. offers multiple options to automatically take down code between hours up to a year.  The full VBScript loader may be found here.

The VBScript Main Remcos Loader

Detection Evasion

STRT found the script loader interesting in how it tries to evade inspection by preventative controls by embedding a large amount of normal script code and comments at the beginning and end of the loader. For example, the screenshot below shows its code in lines 120-150 pertains to Microsoft “pubprn.vbs”, a script designed to publish printers within active directory domain services. Skimming over the code quickly gives it away that shellcode is embedded inside. 

Preparation of Payload

Now that the loader has downloaded the next stage from, this VBScript will prepare several payloads and eventually load the actual Remcos malicious software. First, it will decode the actual Remcos RAT, then extract the dynwrapx.dll (used to load the shellcode), and finally the shellcode. It will also initialize the file path of (c:\windows\winhlp32.exe) which is the target process  to inject Remcos RAT.

Below is a screenshot of each payload decoded:

VBScript Execution in x64 Bit

This script also has a function to check what OS architecture type the infected host has using WMI (Windows Management Instrumentation - T1047) if it is an x64 host, it will run the VBScript using the following command format “wscript /b /e:vbscript <vbscript filename>” like what is shown in the screenshot below. Also you can find the raw attack data sysmon.log for this technique.

The Shellcode - Process Injection

The decoded shellcode uses pre-computed API hashes to dynamically resolve its API import in order to inject the Remcos malware into a targeted process on the host. The screenshot below shows the last WriteProcessMemory API and the ResumeThread API calls get used to write and subsequently execute the Remcos RAT in the target process where it injects its code.

DynamicWrapperX - ShellCode Execution

To execute the shellcode for Remcos via process injection, it first decodes and drops “dynwrapx.dll” in the %temp% folder and loads/installs it using Regsvr32 install silent parameter (“regsvr32 /I /S”). This DLL will give the VBScript access to the “DynamicWrapperX'' Object to load 2 more windows DLL modules named user32.dll and kernel32.dll to allocate memory and execute the shellcode. 

Using VirtualAlloc API call, it will allocate a region of memory for the Remcos malware and shellcode. This memory address will be passed as an argument in CallWindowProcW API to load the shellcode to inject Remcos RAT to the target process, which is WinHlp32.exe. The screenshot below shows the code of this technique.

Where is Remcos Going?

Using VirusTotal behavior to analyze this sample further STRT searched for a pattern of behavior that spawned winhlp32.exe and used regsvr32.exe to load dynwrapx.dll. STRT crafted this VirusTotal behavior query:

behavior:"\"%windir%\\System32\\regsvr32.exe\" /I /S \"%TEMP%\\dynwrapx.dll\"" behavior:"\"%windir%\\winhlp32.exe\""

This uncovered an interesting pattern that began 9/12/2021 from Argentina which matched the same behavior as our original sample. Each upload contained a different section of the final sample (reviewed above). STRT speculates the adversary was testing their code against antivirus engines. After the first few “testing” uploads occurred, it was followed up with actual active campaigns with complete Remcos loaders. 

The pattern of behavior we queried for looks like this in VTI - 

Following using winhlp32.exe, STRT noticed it shifted to using installutil.exe. With installutil.exe, the pattern is very similar. The biggest difference STRT noticed was, during the VBScript execution, unlike winhlp32.exe, installutil.exe did not load dynwrapx.dll. 

VirusTotal behavior query:

behavior:"\"%windir%\\System32\\regsvr32.exe\" /I /S \"%TEMP%\\dynwrapx.dll\"" behavior:"\\installutil.exe\""

STRT, generated a few additional queries that helped us to holistically look for other samples, these provided insight into further behaviors, but also the visibility into how much interaction and changes go into each campaign. 

behaviour_processes:"\"%windir%\\SYSWOW64\\WSCRIPT.EXE\" //b //e:vbscript \"%SAMPLEPATH%\""

VT Correlation Graph of Remcos:

The following VT Correlation Graph shows us the affected countries by this Remcos campaign, the number of C2 servers connections it made to download other malware or its components. Even some interesting infection chain vectors like dropping .lnk file and downloading components from its C2. 

Remcos Analytic Story

The update on the analytic story introduced 21 new and 5 modified detections. In this section, we describe some of these analytics.

Suspicious Process DNS Query Known Abuse Web Services

Detects a suspicious process making a DNS query via known abuse text paste web services, or VoIP, instant messaging, and digital distribution platform to use to download external files. This technique is abused by adversaries, malware actors, and red teams to download a malicious file on the target host. This is a good TTP indicator for possible initial access techniques. A user will experience false positives if the following instant messaging is allowed or common applications like telegram, discord are allowed in the corporate network.

`sysmon` EventCode=22 QueryName IN ("*pastebin*", "*discord*", "*telegram*", "**") process_name IN ("cmd.exe", "*powershell*", "pwsh.exe", "wscript.exe", "cscript.exe")
| stats count min(_time) as firstTime max(_time) as lastTime by Image QueryName QueryStatus process_name QueryResults Computer
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)`

Loading Of Dynwrapx Module

DynamicWrapperX is an ActiveX component that can be used in a VBScript to call Windows API functions, but it requires the dynwrapx.dll to be installed and registered. With that, registering or loading dynwrapx.dll to a host is highly suspicious. In most instances when it is maliciously used the best way to triage is to review parallel processes and pivot on the process_guid. Review the registry for any suspicious modifications meant to load dynwrapx.dll. Identify any suspicious module loads of dynwrapx.dll. This detection will return and identify the processes that invoke vbs/wscript/cscript.

`sysmon` EventCode=7 (ImageLoaded = "*\\dynwrapx.dll" OR OriginalFileName = "dynwrapx.dll" OR  Product = "DynamicWrapperX")  
| stats count min(_time) as firstTime max(_time) as lastTime 
by Image ImageLoaded OriginalFileName Product process_name Computer EventCode Signed ProcessId 
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`

System Info Gathering Using Dxdiag Application

Detects a suspicious dxdiag.exe process command-line execution. Dxdiag is used to collect the system info of the target host. This technique was seen used by Remcos RATS, various actors, and other malware to collect information as part of the recon or collection phase of an attack. This behavior should be rarely seen in a corporate network, but this command line can be used by a network administrator to audit host machine specifications. Thus in some rare cases, this detection will contain false positives in its results. To triage further, analyze what commands were passed after it pipes out the result to a file for further processing. Examples of anyrun remcos analysis that shows its behavior before and after this technique was executed.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
  as lastTime from datamodel=Endpoint.Processes where `process_dxdiag` AND Processes.process
  = "* /t *" by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process
  Processes.process_name Processes.process Processes.process_id Processes.parent_process_id
  | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Possible Browser Pass View Parameter

Detects a suspicious process that contains command-line parameters related to a web browser credential dumper. This technique is used by Remcos RAT malware where it uses the Nirsoft webbrowserpassview.exe application to dump web browser credentials. Remcos use the "/stext" command line to dump the credential in text format. This Hunting query is a good indicator of hosts suffering from possible Remcos RAT infection. Since the hunting query is based on the parameter command and the possible path where it will save the text credential information, It may catch normal tools that are using the same command and behavior.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
  as lastTime from datamodel=Endpoint.Processes where Processes.process  IN ("*/stext*", "*/shtml *", "*/LoadPasswordsIE*", "*/LoadPasswordsFirefox*", "*/LoadPasswordsChrome*","*/LoadPasswordsOpera*", "*/LoadPasswordsSafari*" , "*/UseOperaPasswordFile*", "*/OperaPasswordFile*","*/stab*", "*/scomma*", "*/stabular*", "*/shtml*", "*/sverhtml*", "*/sxml*", "*/skeepass*") AND Processes.process IN ("*\\temp\\*", "*\\users\\public\\*", "*\\programdata\\*")
by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.original_file_name
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`


Technique ID



Suspicious Process DNS Query Known Abuse Web Services



Detects a suspicious process having a DNS query on known abuse text paste web services, or VoIP, instant messaging, and digital distribution platform to download some files.

Loading Of Dynwrapx Module


Defense Evasion, Privilege Escalation

Detects loading of dynwrapx.dll in a process

Wscript Or Cscript Suspicious Child Process


Defense Evasion, Privilege Escalation

Detects suspicious child process of wscript and cscript process.

Winhlp32 Spawning a Process


Defense Evasion, Privilege Escalation

Detects winhlp32 spawning another process

Process Writing DynamicWrapperX



Detects dropping of dynwrapx.dll to use DynamicWrapperX which is an ActiveX component that can be used in a script

  to call Windows API functions.

Vbscript Execution Using Wscript App



Detects execution of vbscript using wscript.exe.

Jscript Execution Using Cscript App



Detects execution of jscript using cscript.exe.

Regsvr32 Silent and Install Param Dll Loading


Defense Evasion

Detects install silent parameter of regsvr32.exe

Regsvr32 with Known Silent Switch Cmdline


Defense Evasion

Detects silent switch of regsvr32.exe.

System Info Gathering Using Dxdiag Application



Detects dxdiag process for possible system info collection parameter /t

Possible Browser Pass View Parameter


Credential Access

Detects possible web browser credential dumper process



Hashes - sha256









Stage1.vbs (download stage2 in pastebin)


Automating with SOAR Playbooks

The following community Splunk SOAR playbooks mentioned below can be used in conjunction with some of the previously described analytics:



Malware Hunt And Contain

This playbook hunts for malware across managed endpoints, disables affected users, shuts down their devices, and blocks files by their hash from further execution via Carbon Black.

Email Notification for Malware

This playbook tries to determine if a file is malware and whether or not the file is present on any managed machines. VirusTotal "file reputation" and PANW WildFire "detonate file" are used to determine if a file is malware, and CarbonBlack Response "hunt file" is used to search managed machines for the file. The results of these investigations are summarized in an email to the incident response team.

Block Indicators

This playbook retrieves IP addresses, domains, and file hashes, blocks them on various services, and adds them to specific blocklists as custom lists

Why Should You Care?

This blog shows how vbscript and jscript are leveraged by all sorts of offensive actors including penetration testing consultants, cybercrime actors, and cyber espionage actors in process injection and shellcode execution. Unlike binary malware loaders, malware loader scripts are very flexible in terms of updates, encryption and also code obfuscation to bypass detections. According to unit42’s 2020 article, Script base malware is one of the new attacker trends and it keeps on evolving and improving as part of the malware tooling ecosystem. Cyber Defenders need to design and deploy effective monitoring capabilities that allow them to detect and respond to: suspicious script execution, process injection and suspicious use of text paste web service in their corporate or server networks.

Learn More

You can find the latest content about security analytic stories on For a full list of security content, check out the release notes on Splunk Docs.




Any feedback or requests? Feel free to put in an issue on Github and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.


We would like to thank the following for their contributions to this post.

  • Teoderick Contreras
  • Michael Haag
  • Jose Hernandez
  • Lou Stella


The Splunk Threat Research Team is an active part of a customer’s overall defense strategy by enhancing Splunk security offerings with verified research and security content such as use cases, detection searches, and playbooks. We help security teams around the globe strengthen operations by providing tactical guidance and insights to detect, investigate and respond against the latest threats. The Splunk Threat Research Team focuses on understanding how threats, actors, and vulnerabilities work, and the team replicates attacks which are stored as datasets in the Attack Data repository

Our goal is to provide security teams with research they can leverage in their day to day operations and to become the industry standard for SIEM detections. We are a team of industry-recognized experts who are encouraged to improve the security industry by sharing our work with the community via conference talks, open-sourcing projects, and writing white papers or blogs. You will also find us presenting our research at conferences such as Defcon, Blackhat, RSA, and many more.

Read more Splunk Security Content