Vidar Stealer Evolves With Custom Virtual Machine and Stream Cipher Obfuscation

Vidar Stealer Introduces a More Complex Obfuscation Approach

The Vidar information stealer has introduced a new approach to hiding its internal strings, according to research from Zscaler ThreatLabz.

Vidar was first observed in 2018 and has continued to modify how it protects strings inside malware samples. Zscaler's latest analysis tracks this evolution from basic XOR-based obfuscation to ChaCha20 and, more recently, a combination of a lightweight virtual machine and custom stream cipher.

ThreatLabz tracked these changes from May through early September 2026 and examined internal Vidar versions ranging from version 2.0 through version 3.3. The researchers found that newer builds change the virtual machine instructions, constants, substitution tables, and cryptographic operations used to decode strings.

The objective is to make static analysis and automated detection more difficult while keeping the underlying functionality relatively consistent.

From XOR to ChaCha20 and Build-Specific Techniques

Vidar's string protection has changed considerably over time.

Earlier versions used single-byte XOR operations to obscure strings. The malware later moved to ChaCha20-based encryption. Beginning with internal version 1.8, the ChaCha20 implementation was modified to make detection and decryption harder.

The next major change appeared with internal version 2.0.

Instead of relying only on a conventional encryption routine, Vidar began combining a custom virtual machine with a custom stream cipher. These components can change from one build to another.

Zscaler's research identifies the following progression:

Early Vidar → Single-byte XOR → ChaCha20 → Modified ChaCha20 → Custom VM + Custom Stream Cipher

This evolution means analysts cannot necessarily depend on one fixed decryption routine or a stable collection of constants when examining different Vidar samples.

How Vidar's Virtual Machine Works

One of the most notable changes is the introduction of a lightweight virtual machine used for string deobfuscation.

The virtual machine operates through a bytecode interpreter. Rather than storing strings in a directly readable form, Vidar stores instructions that the interpreter processes to generate the final string.

The interpreter follows a basic fetch, decode, and execute process.

A byte from the bytecode is read and used to select an opcode handler from a dispatch table. The selected handler then performs an operation against an internal accumulator.

According to ThreatLabz, the dispatch table contains 14 opcode handlers, while other positions are unused and terminate execution.

The virtual machine does not use a conventional stack or multiple registers. Instead, it primarily works with an accumulator and a small context structure containing information such as the bytecode position, output position, previous decoded byte, and XOR key.

The operations performed by the handlers include common low-level transformations such as:

• XOR

• Addition

• Subtraction

• Bit rotation

• Bitwise negation

• Multiplication

• Substitution through a lookup table

• Operations involving previously decoded output

These operations are individually simple. The difficulty comes from how they are combined and changed between builds.

Build-Specific Opcodes Make Static Analysis Harder

ThreatLabz found that the virtual machine is not identical across Vidar samples.

The hardcoded XOR key changes with each build. The key is also used as a seed for the virtual machine's accumulator.

More importantly, the researchers observed changes to the opcodes, constants, and substitution tables.

This creates a problem for detection systems that depend heavily on stable byte sequences or fixed patterns.

A security analyst examining one sample may identify a particular sequence of instructions and constants. A later Vidar build can alter those components while maintaining the same general purpose.

The result is a moving target for static analysis.

The Virtual Machine Has Two Roles

Zscaler found that Vidar's virtual machine is used in two different ways.

First, it can directly process bytecode and produce a deobfuscated string.

Second, the VM can be used to recover cryptographic material needed by Vidar's custom stream cipher.

For internal Vidar versions 2.0 and 2.1, the first nine bytes generated by the VM form the cipher key. From version 2.2 onward, the first eight bytes are used as the key.

Across the versions examined by ThreatLabz, the final four bytes are used as a nonce.

The recovered key and nonce are then used by the custom stream cipher to decrypt another byte array containing the actual encrypted string.

A Custom Stream Cipher Adds Another Layer

Vidar's custom stream cipher provides another level of variation.

ThreatLabz describes the algorithm as using arithmetic, rotation, and XOR-style operations. The exact combination changes between builds.

The researchers observed different sets of operations and constants in different samples.

For example, one analyzed version used a sequence involving multiplication, XOR, addition, and state transformation before reducing the internal state to a single byte for use in decryption.

Another version used a different combination involving subtraction, addition, bit rotation, and XOR operations.

The important point is that the algorithm is not simply a fixed implementation reused unchanged across samples.

Instead, Vidar changes the underlying operations and constants while retaining the general purpose of producing a keystream for decrypting the protected data.

Why Per-Build Changes Matter

Changing cryptographic constants and low-level operations can make malware samples look different from one another even when they perform similar functions.

For defenders, this can complicate signatures based on exact byte sequences.

ThreatLabz describes the approach as keeping algorithms relatively simple and interfaces stable while randomizing constants and micro-operations that static signatures may depend on.

This distinction is important.

The malware does not necessarily need to introduce a completely new architecture for every build. It can modify the implementation details that security tools may use for identification.

That can increase the amount of work required to reverse engineer and classify newer samples.

What Vidar's Obfuscation Protects

The research provides examples of strings recovered from Vidar samples.

These include loader messages, browser-related information, HTTP header content, and strings associated with browser, wallet, plugin, and grabber functionality.

The examples demonstrate why string obfuscation matters during malware analysis.

Strings can provide useful clues about what a malware sample is designed to do. Hiding those strings forces analysts and automated systems to perform additional processing before they can interpret the malware's internal behavior.

In one analyzed sample, for example, the researchers recovered strings related to browser and wallet collection functionality after processing the VM and custom stream cipher.

Vidar's Evolution Is More About Evasion Than New Functionality

One of the key observations from the research is that Vidar's newer obfuscation techniques do not necessarily represent a completely different malware family.

Instead, the changes primarily affect how the malware hides information from analysis.

Zscaler describes the newer approach as maintaining stable interfaces and functionality while continuously changing the lower-level implementation.

This is significant because defenders may encounter samples that behave similarly but have substantially different internal representations.

For security researchers, the task therefore becomes less about identifying one permanent Vidar signature and more about recognizing the underlying behavior and relationships between different components.

What This Means for Security Teams

The Vidar research highlights several considerations for malware analysis and detection.

1. Static signatures can face changing implementations

When constants, opcodes, and lookup tables change between builds, exact byte-pattern signatures can become less reliable on their own.

This does not mean static analysis becomes useless. It means defenders may need to combine static indicators with other forms of analysis.

2. Behavioral indicators remain important

If the implementation changes while the malware's broader behavior remains similar, behavioral signals can provide additional context.

Network activity, process relationships, file modifications, and other observable behavior can complement code-level signatures.

3. Automated analysis needs to account for obfuscation

A lightweight virtual machine adds an interpretation layer between the stored data and the final string.

Automated systems that encounter such samples may need to account for this additional execution logic before useful strings become visible.

4. Malware families can evolve without changing their basic purpose

Vidar's case demonstrates how malware developers can repeatedly modify implementation details without completely redesigning the underlying malware.

This creates an ongoing challenge for defenders attempting to maintain detection coverage against changing samples.

These points are consistent with ThreatLabz's conclusion that network and endpoint detection systems need to keep pace with evolving obfuscation techniques.

Zscaler's Detection Coverage

Zscaler states that its cloud security platform detects indicators associated with Vidar at multiple levels.

The research identifies the threat name Win32.PWS.Vidar and lists several Zscaler MDR detection analytics associated with Vidar activity:

• WIN-BIN-NETCONN-TO-TELEGRAM-SHORTENED-URL

• WIN-WEBBROWSER-UNUSUAL-PARENT

• WIN-STEALER-FILEMOD

These are vendor-specific detection analytics reported by Zscaler and should not be interpreted as universal detection rules for every Vidar sample.

Indicators of Compromise

Zscaler also published SHA-256 hashes associated with several Vidar versions in the research.

Security teams can use the published IOCs as additional investigation references, while recognizing that hashes identify specific samples rather than every possible Vidar build.

What the Research Shows

The latest Vidar changes illustrate a broader cybersecurity pattern: malware developers increasingly modify implementation details to complicate detection and analysis.

In Vidar's case, the evolution moves from relatively straightforward XOR-based string protection to ChaCha20 and then to a combination of interpreted bytecode and build-specific stream-cipher operations.

The individual transformations remain relatively simple, but their combination and variation make automated analysis more complicated.

For defenders, this reinforces the value of using multiple sources of evidence rather than depending on a single static signature.

The research does not indicate that Vidar's latest techniques make the malware undetectable. Instead, it shows how the malware's developers are attempting to increase the difficulty of analysis by changing the way internal strings are protected.

Conclusion

Vidar continues to evolve its string obfuscation techniques.

According to Zscaler ThreatLabz, the malware has progressed from single-byte XOR and ChaCha20-based protection to a custom virtual machine and build-specific stream cipher.

The latest approach changes opcodes, constants, substitution tables, keys, and cryptographic operations across builds. While the underlying functionality can remain similar, these changes make samples less predictable from a static-analysis perspective.

For security teams, the development highlights the importance of combining static analysis with behavioral, endpoint, and network-based detection approaches when investigating evolving malware.

The research also demonstrates why malware analysis is an ongoing process. As attackers change implementation details, defensive detection techniques need to adapt alongside them.