Vidar Stealer Deploys Custom Virtual Machine, New Stream Ciphers to Evade Detection

Threat researchers have uncovered a significant leap in obfuscation sophistication within Vidar, the information-stealing malware family that has plagued victims since 2018.

According to new findings from Zscaler ThreatLabz, Vidar’s developers spent the months between May and early September 2026 overhauling how the malware conceals its internal strings, moving from simple XOR encoding to ChaCha20-based encryption, and finally to a custom-built virtual machine paired with per-build stream ciphers.

Vidar’s obfuscation journey illustrates a deliberate arms race against static analysis tools. Early builds relied on basic single-byte XOR operations trivial to reverse-engineer.

Vidar Stealer Deploys Custom Virtual Machine

By internal version 1.5, the developer pivoted to ChaCha20, then further modified the cipher in version 1.8 to resist decryption attempts.

The real inflection point arrived with version 2.0, when Vidar introduced a lightweight virtual machine driven by a bytecode interpreter, combined with a proprietary stream cipher that changes with every build.

This VM operates through a fetch-decode-execute loop, indexing a sparse 256-entry dispatch table where each opcode byte triggers a specific handler.

Researchers identified 14 populated opcode handlers performing basic operations: XOR, addition, subtraction, bit rotation, negation, multiplication, and lookup-table substitution, manipulating a single one-byte accumulator.

Critically, the opcodes, constants, and substitution tables are randomized across builds, meaning a signature that catches one sample won’t catch the next.

Beyond the VM, Vidar layers on custom stream ciphers to decrypt sensitive strings. ThreatLabz documented two distinct implementations. Versions 2.0 and 2.1 used a modified ChaCha-based cipher featuring a custom 128-bit state, an 8-byte key, a 4-byte nonce, and altered quarter-round rotations that shift between samples.

From version 2.2 onward, Vidar switched to an add-rotate-XOR (ARX) cipher. This approach initializes a 32-bit state using the FNV-1a hashing prime combined with key material, then folds in the nonce using the golden-ratio constant 0x9E3779B9.

The keystream generation itself varies significantly from build to build; one version 2.4 sample used multiplication and shift operations with constants like 0xC5C8C2C9, while a version 2.5 sample applied an entirely different sequence involving 32-bit rotation and distinct additive constants.

What makes this evolution notable isn’t complexity for complexity’s sake; it’s the strategic randomization of constants and micro-operations while keeping the overall interface stable.

That combination is specifically engineered to defeat automated deobfuscation scripts and static YARA-style signatures that hunt for fixed byte patterns.

The VM’s design remains structurally simple, without a stack or extended register set, yet its per-build variability creates a moving target.

Detection and Indicators

Zscaler reports that its Cloud Sandbox and multilayered platform detect Vidar activity under the threat classification Win32.PWS.Vidar, while Zscaler MDR flags related behavior through analytics such as WIN-BIN-NETCONN-TO-TELEGRAM-SHORTENED-URL and WIN-STEALER-FILEMOD.

Security teams tracking credential-theft campaigns should prioritize behavioral detection over static signatures, given Vidar’s demonstrated ability to rewrite its own cryptographic fingerprint with every release.

Site: Thecyberdef.com

Follow TheCyberDef on Google News, LinkedIn & X for the latest cybersecurity updates. Stay informed.

About the Author

Kiran

Author

Kiran is an independent cybersecurity researcher covering vulnerabilities, malware campaigns, and emerging threats in the cybersecurity landscape.

Visit Website View All Posts