Vidar Stealer Rewrites String Obfuscation Every Build With Custom VM and Per-Build ARX Stream Ciphers

Zscaler ThreatLabz shows Vidar 2.x/3.x decoding strings via a 14-handler bytecode virtual machine plus stream ciphers that evolved from XOR to modified ChaCha20 to a per-build ARX design, defeating static signatures while the stealer spreads through fake…

Zscaler ThreatLabz analysis of the Vidar infostealer, tracked since 2018, details how versions 2.x and 3.x hide embedded strings. A custom bytecode virtual machine uses a 256-entry dispatch table with 14 handlers that mutate a one-byte accumulator via XOR, addition, subtraction, rotation, bitwise negation, multiplication, and substitution. A per-build four-byte value seeds the accumulator and doubles as an XOR key, while opcodes, constants, and substitution tables change with every build — a shift Zscaler and Splunk say undermines static YARA matching and favors behavior-based detection. The VM either emits the plaintext string directly or recovers a key and nonce for a custom stream cipher: versions 2.0–2.1 used a modified ChaCha (ChaCha20) design, while 2.2 onward uses an ARX cipher incorporating FNV-1a and the constant 0x9E3779B9, with the key in the first eight bytes and the nonce in the last four. Zscaler tracking from May through early September 2026 shows the obfuscation evolving from basic XOR encryption to modified ChaCha20 routines to the per-build VM and cipher. Distribution continues via social engineering, including a fake Gemini installer and video-platform download lures, and stolen browser data exposes corporate apps, email, finance, and crypto accounts. Splunk also observed sandbox and endpoint-security checks, and four SHA-256 hashes were published for Vidar versions 2.0, 2.5, 3.1, and 3.4. The three reports do not conflict; they differ only in specificity.

• Vidar, tracked since 2018, decodes strings in versions 2.x and 3.x using a bytecode virtual machine with a 256-entry dispatch table and 14 handlers mutating a one-byte accumulator via XOR, addition, subtraction, rotation, bitwise negation,…
• A per-build four-byte value seeds the accumulator and is reused as an XOR key; opcodes, constants, and substitution tables change with every build.
• Versions 2.0-2.1 used a modified ChaCha (ChaCha20) design; version 2.2 onward uses an ARX cipher incorporating FNV-1a and the constant 0x9E3779B9.
• From version 2.2, the stream cipher key is the first eight bytes and the nonce is the last four bytes.
• Zscaler tracking from May through early September 2026 shows obfuscation evolving from basic XOR to modified ChaCha20 to the per-build custom VM and stream cipher.
• Zscaler and Splunk state behavior-based detection is more durable than string signatures, with per-build changes undermining static YARA matching; Splunk also observed sandbox and endpoint-security checks.
• Four SHA-256 hashes (IoCs) were published for Vidar versions 2.0, 2.5, 3.1, and 3.4.
• Distribution uses social engineering, including a fake Gemini installer and video-platform download lures; stolen browser data exposes corporate apps, email, finance, and crypto accounts.