Take a Product Tour Request a Demo Cybersecurity Assessment Contact Us


The latest cybersecurity trends, best practices, security vulnerabilities, and more

The Mechanics of ViperSoftX: Exploiting AutoIt and CLR for Stealthy PowerShell Execution

Threat Summary

In the dynamic landscape of cyber threats, ViperSoftX has emerged as a highly sophisticated malware, adept at infiltrating systems and exfiltrating sensitive information. Since its initial detection in 2020, ViperSoftX has undergone several iterations, with each version demonstrating increased complexity and advanced capabilities. Initially, it spread mainly through cracked software, luring users with pirated applications that secretly installed the malware. ViperSoftX was also distributed via torrent sites earlier, but now we have observed it being distributed specifically as eBooks over torrents.

A notable aspect of the current variant of ViperSoftX is that it uses the Common Language Runtime (CLR) to dynamically load and run PowerShell commands, thereby creating a PowerShell environment within AutoIt for operations. By utilizing CLR, ViperSoftX can seamlessly integrate PowerShell functionality, allowing it to execute malicious functions while evading detection mechanisms that might otherwise flag standalone PowerShell activity.

ViperSoftX also employs a strategy where attackers selectively adapt components from offensive security scripts, modifying only the necessary elements to align with their malicious goals, rather than creating new code from scratch. By leveraging these existing scripts, malware developers not only accelerate development but also focus on improving their evasion tactics, making ViperSoftX a formidable threat in the cybersecurity landscape.

Understanding these methods is crucial for developing effective defenses against such advanced threats. In this blog, we will delve deeper into the workings of ViperSoftX, exploring its infection chain, payload execution, and the various techniques it employs to remain undetected.

Infection Flow

Figure 1: Figure 1: Malware infection flow
Figure 1: Figure 1: Malware infection flow

Torrent Traps: ViperSoftX’s Malicious eBooks and Hidden Threats

Figure 2: eBook torrent link
Figure 2: eBook torrent link

The attack begins when users download an ebook from a malicious torrent link, thinking they are obtaining a legitimate file. However, there are concealed threats inside the downloaded RAR file, including a hidden folder, a cunning shortcut file that appears to be a harmless PDF, PowerShell script, AutoIt.exe, and AutoIt script that all skillfully pose as JPG files. The hidden folder contains a set of files identical to those in the current folder, with the exception of a PDF or ebook document, which serves as a decoy to hide its real purpose.

Figure 3: Rar folder content
Figure 3: Rar folder content

Figure 4: Lnk file command
Figure 4: Lnk file command

When the user executes the shortcut file, it initiates a command sequence that begins by listing the contents of "zz1Cover4.jpg”. Subsequently, it reads each line from this file and executes them as commands in the Command Prompt, effectively automating the execution of multiple commands. This tactic allows for streamlined and automated execution of potentially malicious commands without direct user interaction.

Figure 5: Concealed PowerShell code
Figure 5: Concealed PowerShell code

As mentioned above, the LNK file executes "zz1Cover4.jpg," which cleverly conceals PowerShell code within blank spaces, spread with several process logs.

This PowerShell code performs several actions:

  1. Unhide the hidden folder.
  2. The script calculates the total size of all disk drives and that size is used as the file name for the AutoIT script and task name. The script configures Windows Task Scheduler with two triggers: one at logon, which repeats every 5 minutes, and another every day, which repeats every 10 minutes.
  3. It copies two files (zz1Cover2.jpg and zz1Cover3.jpg) to the %APPDATA%\Microsoft\Windows directory, renaming zz1Cover2.jpg to <sum of disk drive sizes>.au3 and zz1Cover3.jpg to AutoIt3.exe.
  4. It deletes all .lnk files in the current directory.
Figure 6: Hidden folder content highlights the decoy eBook
Figure 6: Hidden folder content highlights the decoy eBook

Figure 7: Scheduled task to run AutoIT script
Figure 7: Scheduled task to run AutoIT script

From Defense to Offense: ViperSoftX’s Strategic Code Reuse

In examining ViperSoftX, a clear pattern emerges: attackers use AutoIt scripts to hide their malicious actions. Attackers meticulously obfuscate these scripts using various techniques, adding layers of complexity that challenge both researchers and analysis tools trying to decipher their functionality. Furthermore, our analysis has revealed the extensive use of code spanning a significant number of lines, indicative of the sophistication and depth of the ViperSoftX operation. Through decompilation of the source code, we were able to conduct a thorough analysis, gaining deeper insights into ViperSoftX's operations and shedding light on its functionality and operating methods.

Figure 8: Snippet of Obfuscated AutoIT script
Figure 8: Snippet of Obfuscated AutoIT script

PowerShell Execution within AutoIt Script

AutoIt transcends its benign origins and becomes a potent weapon for secretly executing PowerShell commands. The crucial part of AutoIt's harmful use is its ability to interact with the .NET Common Language Runtime (CLR) framework. AutoIt does not by default support the .NET Common Language Runtime (CLR). However, the language's user-defined functions (UDF) offer a gateway to the CLR library, granting malevolent actors access to PowerShell's formidable capabilities.

With the support of the .NET CLR, AutoIt gains the ability to harness the power of the PowerShell Automation Classes "System.Management.Automation.PowerShell." These classes facilitate interaction with PowerShell modules, cmdlets, and scripts within an unmanaged runspace. Using these classes, attackers can easily carry out various harmful activities undetected.

For more details, you can refer to the AutoIT forum and Official Microsoft documentation.

Figure 9: PowerShell Script within AutoIt using .NET CLR
Figure 9: PowerShell Script within AutoIt using .NET CLR

Explanation of the Code:

  1. Loading the Assembly:
    • The script starts by loading the System.Management.Automation assembly using _CLR_LoadLibrary
    • This step initializes a local variable $oAssembly to hold the loaded assembly object.
  2. Obtaining Type Information:
    • The script retrieves type information for the Management.Automation.PowerShell class using $oAssembly.GetType_2.
    • It initializes a local variable $pAssemblyType to store the type information.
  3. Creating Objects Dynamically:
    • An activator object $oActivatorType is created using ObjCreateInterface, based on the type information obtained earlier.
    • The purpose of this activator object is to dynamically create instances of PowerShell objects.
  4. Initializing PowerShell Object:
    • The script initializes a PowerShell object $pObjectPS using the activator object and the InvokeMember_3
    • This step effectively creates a PowerShell environment within AutoIt for executing PowerShell commands.
  5. Adding and Executing PowerShell Scripts:
    • A PowerShell script stored in $PSScript is added to the PowerShell object using $pObjectPS.AddScript.
    • The script is then executed asynchronously using $pObjectPS.BeginInvoke, which returns an asynchronous operation handle $objAsync.
  6. Handling Asynchronous Execution:
    • The script enters a loop to wait for the asynchronous operation to complete ($objAsync.IsCompleted = False).
    • Inside the loop, ContinueLoop ensures the script remains in the loop until the operation completes.
    • Once completed, the script retrieves the result using $pObjectPS.EndInvoke, storing it in $objPsCollction.

Before execution, AMSI empowers security products to scrutinize script content, including PowerShell scripts. This proactive approach adds a valuable layer of defense, thwarting malicious activities before they can wreak havoc on systems and networks. The _PatchAMSI() function in ViperSoftX serves a singular purpose: to neutralize AMSI's vigilant gaze before executing PowerShell scripts. By patching AMSI, ViperSoftX evades detection by security solutions that depend on AMSI for scanning and blocking malicious scripts, allowing it to operate undetected within compromised systems.

Figure 10: Attempt to bypass AMSI Detection
Figure 10: Attempt to bypass AMSI Detection

Let's break down the function _PatchAMSI line by line:

  1. Defining Patch Bytes:
    Figure 10: Attempt to bypass AMSI Detection
    • This line defines the patch bytes as a hexadecimal string. These bytes contain the opcodes that will be written to AmsiScanBuffer's memory location. These opcodes effectively alter the behavior of the function to return E_INVALIDARG.
  2. Loading DLL:
    • The _HexToString function converts the hexadecimal string into a readable string representing the DLL name (dll in this case).
    • The _WinAPI_LoadLibrary function loads the specified DLL into memory.
  3. Getting ASB Address:
    • Another hexadecimal string is converted to a readable string ("AmsiScanBuffer").
    • _WinAPI_GetProcAddress retrieves the memory address of the specified function (AmsiScanBuffer) within the loaded DLL.
  4. Patching Memory:
    • BinaryLen calculates the size of the patch bytes.
    • DllCall invokes the Windows API function VirtualProtect to modify memory protection attributes.
    • The function modifies the protection of the specified memory address ($asbLoc) to allow writing (0x40 represents PAGE_EXECUTE_READWRITE).
    • The original protection state is stored in variables for later restoration.
  5. Applying the Patch:
    • A dynamic structure ($patchBuffer) is created to hold the patch bytes.
    • The patch bytes are written to the allocated memory using DllStructSetData.
    • Finally, the memory protection is restored to its original state after applying the patch.

Exposing the Hidden PowerShell Payload:

The "PS payload" refers to a malicious PowerShell script that is executed as part of the infection process, as detailed earlier. It is stored in the variable $PSScript and remains concealed behind base64 encryption. The AutoIt function, _RUN_PSHOST_SCRIPT(), is responsible for loading and executing this PowerShell script.

Figure 11: Base64 encoded PS Payload
Figure 11: Base64 encoded PS Payload

This initial payload, once decrypted, unfolds to reveal another layer of complexity, as a blend of reverse base64 and AES encryption obscures a secondary PowerShell script.

Figure 12: Reverse base64 and AES encryption
Figure 12: Reverse base64 and AES encryption

Through this intricate decryption process, the final payload is eventually unveiled. AMSI Patch and this series of encryption methods serve to obfuscate the true nature of the payload, making it challenging for security solutions.

Figure 13: Decrypted final payload
Figure 13: Decrypted final payload

The ViperSoftX malware's final payload has the ability to carry out a variety of malicious actions:

  • It gathers system information and scans for cryptocurrency wallets via browser extensions:
Figure 14: Browser extension check
Figure 14: Browser extension check

The Plqopsjidoikoaqx PowerShell function scans for specific browser extensions within the Firefox profiles directory and checks for certain files defined in a JSON object. It creates a list of identified extensions and targets. If an extension like Metamask or Ronin Wallet is found, it adds a corresponding identifier to the list. It also checks if specific files exist in paths defined by the JSON data and adds their names to the list. Finally, the collected information is converted into a base64-encoded string and returned. This process helps in gathering and encoding system information for further use or transmission.

  • It sends gathered information to its Command and Control (C2) server:
Figure 15: Collecting and Sending System Data to C2 Server
Figure 15: Collecting and Sending System Data to C2 Server

ViperSoftX's network activity demonstrates sophisticated techniques to evade detection and blend in with legitimate traffic. The use of a deceptive hostname like security-microsoft[.]com observed in some samples is designed to appear trustworthy and mislead victims into thinking the domain is associated with Microsoft. Additionally, the suspicious Base64-encoded User-Agent, often used in malicious activities, reveals detailed system information. This User-Agent string includes data from PowerShell commands, such as logical disk volume serial number, computer name, username, operating system version, antivirus product information, and cryptocurrency details.

Figure 16: Use of deceptive hostname
Figure 16: Use of deceptive hostname

The pOPSKX function then sends this collected data to a remote server. It sets up a web client, configures headers with the custom user agent, and uploads the data. The unusual POST request with a Content-Length of 0 suggests an attempt to avoid detection by sending no body content.

After receiving a response, the pOPSKX function checks a header called "worker" in the server's reply. If this header's value is "0", it indicates no more tasks, and the global worker variable is set to false. If the value is not "0", it signifies more tasks to perform, and the global worker variable is set to true. This variable is crucial for controlling the malware's next steps, deciding whether it should stay idle or continue executing commands based on the server's instructions. Furthermore, the use of Cloudflare services can obfuscate the true origin of the malicious traffic, adding another layer of concealment to ViperSoftX's operations.

Together, these functions gather data from an infected system and send it to a command and control (C2) server for further instructions.

Below are other activities ViperSoftX can perform:

  • ViperSoftX stealthily captures clipboard contents, extracting potentially sensitive data.
  • It dynamically downloads and executes additional payloads and commands based on responses received from the C2 server.
  • It conducts reconnaissance by checking for the presence of anti-malware products using Windows Management Instrumentation (WMI).
  • The malware includes self-deletion mechanisms to evade detection and removal efforts.


By selectively leveraging existing offensive security scripts and modifying them to suit their malicious purposes, attackers behind ViperSoftX not only expedite development but also refine their evasion tactics, elevating the threat posed by this malware variant.

One of the hallmark features of ViperSoftX is its adept use of the Common Language Runtime (CLR) to orchestrate PowerShell operations within the AutoIt environment. This integration enables seamless execution of malicious functions while evading detection mechanisms that would typically flag standalone PowerShell activity. Furthermore, ViperSoftX's ability to patch the Antimalware Scan Interface (AMSI) before executing PowerShell scripts underscores its determination to circumvent traditional security measures. This evasion tactic, coupled with its multifaceted capabilities, including data exfiltration, reconnaissance, and self-deletion mechanisms, highlights the sophistication and agility of modern malware threats. Ultimately, by understanding the modus operandi of malware variants like ViperSoftX and adopting a comprehensive defense strategy that encompasses detection, prevention, and response capabilities, organizations can effectively mitigate the risk posed by these sophisticated threats, safeguarding their digital assets and preserving the integrity of their systems and networks.

Trellix Product Coverage

Trellix Email Security offers a multi-layered detection strategy for this campaign that includes checks on the URL, email, network, and attachment levels to ensure that any potential threat is discovered and stopped from doing harm to our customers. To remain ahead of new and changing threats, our product continuously monitors and updates its threat intelligence database to stay ahead of new and evolving threats. that includes the Trellix Multi-Vector Virtual Execution Engine, a new anti-malware core engine, machine-learning behaviour classification and AI correlation engines, real-time threat intelligence from the Trellix Dynamic Threat Intelligence (DTI) Cloud, and defences across the entire attack lifecycle to keep your organisation safer and more resilient.

MITRE ATT&CK® Techniques

Tactic Technique ID Technique Name
Initial Access T1189 Drive-by Compromise
Execution T1059.001
Command and Scripting Interpreter: PowerShell
Command and Scripting Interpreter: AutoHotKey & AutoIT
Malicious File
Scheduled Task/Job: Scheduled Task
Windows Management Instrumentation
Persistence T1053.005 Scheduled Task/Job
Defense Evasion   T1140
Deobfuscate/Decode Files or Information
Hide Artifacts: Hidden Files and Directories
Indicator Removal: File Deletion
Masquerading: Masquerade File Type
Obfuscated Files or Information: Encrypted/Encoded File
Impair Defenses: Disable or Modify Tools
Discovery T1518.001
Software Discovery: Security Software Discovery
Account Discovery: Local Account
Browser Information Discovery
System Information Discovery
File and Directory Discovery
Data from Local System
System Owner/User Discovery
Lateral Movement T1115 Clipboard Data
Command and Control T1071.001
Application Layer Protocol: Web Protocols
Encrypted Channel
Data Encoding: Standard Encoding

Trellix Protection

Product Signature
Endpoint Security (ENS) LNK/Agent.al
Endpoint Security (HX) Trojan.Generic.35755833
Network Security (NX)
Detection as a Service
Email Security
Malware Analysis
File Protect
Helix 1.1.2057 WINDOWS METHODOLOGY [Wscript JS] detects this behavior
1.1.1478 WINDOWS METHODOLOGY [Proc via WMI non-system]

Indicators of Compromise (IoCs):

AutoIt Scripts
LNK Files

Get the latest

We’re no strangers to cybersecurity. But we are a new company.
Stay up to date as we evolve.

Please enter a valid email address.

Zero spam. Unsubscribe at any time.