Vidar Adds Virtual Machine and Custom Stream Ciphers For String Obfuscation

Introduction

Vidar is an information stealer that was first observed in 2018. Across its iterations, Vidar has continued to improve its string obfuscation to make detection and analysis more difficult by changing deobfuscation algorithms, constants, and primitives. From May through early September 2026, Zscaler ThreatLabz tracked Vidar’s string obfuscation as it evolved from basic XOR to ChaCha20, and more recently, to a custom virtual machine (VM), which is executed via a lightweight bytecode interpreter that is combined with a custom stream cipher that changes with each build.

In this blog post, ThreatLabz covers Vidar’s string obfuscation methods from version 2.0 to the latest version 3.3.

Key Takeaways

• Vidar is an information stealer that was first observed in 2018 that initially obfuscated strings with XOR-based encryption.
• The Vidar developer later migrated to more advanced string encryption algorithms based on ChaCha20.
• In June 2026, ThreatLabz observed Vidar introduce a virtual machine to protect the malware’s strings with different opcodes that change per build. 
• In addition to the virtual machine, a new custom stream cipher algorithm was added with operations that vary across builds. 
• These per-build string obfuscation techniques are designed to hinder static and automated analysis.

Evolution Timeline

Earlier versions of Vidar used single-byte XOR operations to obfuscate strings. Beginning with internal version 1.5, the developer adopted ChaCha20. Starting in versions 1.8, the ChaCha20 cipher was modified to make detection and decryption harder. Starting with internal version 2.0, Vidar shifted to a different approach that combines a custom virtual machine and custom stream cipher per build. The figure below shows a timeline of these changes.

Figure 1: Evolution of Vidar’s string obfuscation from early May to early September 2026. 

ANALYST NOTE: The version number used in this analysis refers to internal versions identified by ThreatLabz.

Technical Analysis

The following sections examine Vidar’s string deobfuscation process, including a lightweight virtual machine and custom stream cipher.

Virtual machine deobfuscation

In order to obfuscate the malware’s strings in versions 2.x and 3.x, the Vidar developer introduced a simple virtual machine that is executed via a bytecode interpreter. The bytecode interpreter consists of a fetch–decode–execute loop with the VM code provided as a byte array. Each opcode byte indexes a sparse 256-entry dispatch table. The matching handler mutates a one-byte accumulator and emits an output byte when a specific opcode is encountered. The dispatch table is initialized on first use and populated with 14 opcode handlers. All other slots in the dispatch table are null and terminate execution. The bytecode interpreter is relatively simple and does not implement a stack or use registers beyond an accumulator. Each handler uses simple primitives such as XOR, addition, subtraction, rotation, bitwise negation, multiplication, and substitution via a lookup table.

The interpreter uses a context structure that is passed to each handler and executes until the bytecode or the output buffer is exhausted as shown in the code below.

typedef struct bytecode_context {
   uint8_t         acc;        // accumulator
   uint8_t         prev_out;   // decoded byte 
   const uint8_t * code_ptr;   // bytecode         
   uint32_t        code_len;   // bytecode_length 
   uint32_t        index;      // instruction_pointer
   uint8_t*        out_ptr;    // output         
   uint32_t        out_len;    // output buffer size
   uint32_t        out_index;  // output_position  
   uint32_t        xor_key;    // accumulator seed and used as an xor key
} bytecode_context;
void vidar_bytecode_intrepreter(
   const uint8_t *input_bytes,
   uint32_t input_len,
   uint8_t *output_bytes,
   uint32_t output_len)
{
   bytecode_context ctx = {0};
   init_vm_dispatch_table();
   ctx.acc        = get_seed_value();
   ctx.prev_out   = 0;
   ctx.code_ptr   = input_bytes;
   ctx.code_len   = input_len;
   ctx.code_index = 0;
   ctx.out_ptr    = output_bytes;
   ctx.out_len    = output_len;
   ctx.out_index  = 0;
   ctx.xor_key    = get_seed_value();
   while (ctx.code_index < ctx.code_len &&
          ctx.out_index < ctx.out_len)
   {
       uint8_t opcode = ctx.code_ptr[ctx.code_index++];
       void (*handler)(bytecode_context *) =
           opcode_handlers[opcode];
       if (handler == NULL)
           break;
       handler(&ctx);
   }
}

The hardcoded XOR key is a 4-byte value that changes with each build. The key also serves as a seed for initializing the bytecode interpreter’s accumulator. The opcodes, constants, and substitution tables change across builds, making automated analysis more difficult.

The following table provides examples of Vidar’s VM opcodes and their corresponding operations.

Table 1: Examples of VM opcodes and corresponding operations from a Vidar version 3.1 sample.

Vidar’s VM is used in two different ways:

• For direct deobfuscation: The bytecode is interpreted to create the final deobfuscated string.
• To decrypt a key and nonce for a string encrypted with a custom stream cipher (described later): For Vidar versions 2.0 and 2.1, the first 9 bytes form the key. From version 2.2 onwards, the first 8 bytes are used as the key. In all versions of Vidar, the last 4 bytes are used as the nonce. The custom stream cipher then uses the key and nonce to decrypt an additional byte array containing the actual encrypted string.

The table below provides examples of the VM bytecode that is interpreted to produce deobfuscated strings.

Table 2: Examples of Vidar’s bytecode and the resulting deobfuscated strings.

Deobfuscation using custom stream ciphers

In addition to the VM-based obfuscation, Vidar implements a custom stream cipher to decrypt some of the malware’s strings. Although the stream cipher interface remains consistent across builds, the underlying implementation varies. ThreatLabz identified two general custom stream cipher implementations: a modified ChaCha-based cipher and an add-rotate-XOR (ARX) based cipher.

ChaCha-based cipher

Vidar versions 2.0 and 2.1 use a ChaCha-based cipher with a number of modifications that include a custom 128-bit initial state, 8-byte key, 4-byte nonce, and different quarter-round rotations that change between samples.

ARX-based stream cipher

Vidar version 2.2 and later use a custom stream cipher that initializes the state, followed by ARX transformations to produce a keystream that is initialized using the previously decrypted key and nonce (from the VM). The initialization and decryption steps are described in the following subsections.

State initialization with the key and FNV-1a

The cipher first incorporates the key material into a 32-bit state value using multiplication with the FNV-1a prime constant, as shown in the example below.

state = SEED_CONSTANT;  // Per-build 32-bit seed.
for (i = 0; i < key_length; i++) {
   state ^= key[i];
   state *= 0x01000193;  // 32-bit FNV-1a prime.
}

The per-build seed, SEED_CONSTANT, is the only element of this initialization step that changes between builds.

State initialization with the nonce and golden ratio-related constant

The second phase incorporates the nonce material into the state using the fixed constant 0x9E3779B9 (the 32-bit representation of the fractional part of the golden ratio), as shown in the example below.

for (i = 0; i < nonce_length; i++) {
   state ^= nonce[i] * 256;
   state += 0x9E3779B9;
}

Keystream generation and decryption

Every build uses a different set of ARX based transformations with unique constants to construct the keystream, which is then used to decrypt the ciphertext. The example below shows the algorithm observed in a Vidar version 2.4 sample, which applies various ARX operations. After these operations are executed, the state is folded into a keystream byte that is then used to decrypt the corresponding byte from the input array to produce the output byte, as shown in the example below.

for (i = 0; i < input_length; i++) {
   // Transform the 32-bit state.
   state *= 0xC5C8C2C9;
   state ^= state >> 16;
   state += 0xE476B81E;
   state ^= 0x907A30A0;
   state *= 0xC967295D;
   state ^= 0xA72A764F;
   // Fold the 32-bit state into a single keystream byte.
   keystream_byte =
       (state ^ (state >> 8) ^ (state >> 16) ^ (state >> 24)) & 0xFF;
   // XOR the keystream byte with the input.
   output[i] = input[i] ^ keystream_byte;
}

The example below shows a different implementation of the ARX algorithm that uses a different combination of operations and a new set of constants. This implementation was extracted from a Vidar version 2.5 sample.

for (i = 0; i < input_length; i++) {
   state -= 0x43ACCA67;
   state += 0x871A3B01;
   state += 0x1D24B66B;
   state = ROL32(state, 22);
   state ^= state >> 16;
   state += 0x9EC4A92E;
   state ^= state >> 16;
   state += 0x9DDE39F6;
   keystream_byte =
       (state ^ (state >> 8) ^ (state >> 16) ^ (state >> 24)) & 0xFF;
   
   output[i] = input[i] ^ keystream_byte;
}

The table below provides examples of strings decrypted using Vidar’s VM together with one of Vidar’s custom stream ciphers from a version 3.1 sample.

Table 3: Example of strings decrypted using Vidar’s VM and custom stream cipher from a version 3.1 sample.

Conclusion

The Vidar family is constantly evolving, with new changes and functionality along with additional obfuscation to make analysis and detection more difficult. The obfuscation is designed to look different across builds, while performing essentially the same function. Vidar keeps the algorithms simple and the interfaces stable while continuously randomizing the constants and micro-operations that static signatures rely on. This highlights the need for network and endpoint detection systems that can keep pace with these innovative techniques.

Zscaler Coverage

Zscaler’s multilayered cloud security platform detects indicators related to Vidar at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for Vidar.

Figure 2: Zscaler Cloud Sandbox Report for Vidar.

In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Vidar at various levels with the following threat names:

• Win32.PWS.Vidar

Zscaler MDR detects Vidar using these detection analytics:

• WIN-BIN-NETCONN-TO-TELEGRAM-SHORTENED-URL
• WIN-WEBBROWSER-UNUSUAL-PARENT
• WIN-STEALER-FILEMOD

Indicators Of Compromise (IOCs)