Vidar Uses Custom Bytecode Interpreter and ARX Stream Ciphers for Per-Build String Obfuscation

Vidar information stealer has introduced a lightweight custom virtual machine and per-build stream-cipher variations to conceal its embedded strings, raising the cost of static detection and automated reverse engineering.

First observed in 2018, Vidar remains a widely tracked credential-stealing malware family.

Its operators continually alter internal protections without necessarily changing the malware’s broader operational purpose: harvesting browser data, cryptocurrency-wallet information, credentials, and other valuable victim artifacts.

The latest change matters because it targets a major analytical advantage defenders traditionally rely on: readable embedded strings such as API names, error messages, configuration fields, browser targets, HTTP headers, and command-and-control-related artifacts.

ThreatLabz refers to the versions in its research as internal Vidar versions. Earlier samples used a single-byte XOR scheme, while version 1.5 adopted ChaCha20.

Versions 1.8 onward modified that cipher to complicate routine identification and decryption.

Beginning with version 2.0, however, Vidar switched to a layered model that combines a custom bytecode interpreter with custom stream ciphers whose implementation details change from build to build.

The malware’s new virtual machine is deliberately minimal. It processes a bytecode array through a fetch-decode-execute loop, using each byte as an index into a sparse 256-entry opcode dispatch table.

Only 14 entries map to active handlers; an unmapped entry halts interpretation. Rather than implementing a full virtualized processor with a stack and multiple registers.

Vidar relies primarily on a one-byte accumulator, a previous-output-byte value, output indexes, and a changing XOR key.

Handlers perform compact operations including XOR, addition, subtraction, rotations, bitwise negation, multiplication, and substitution-table lookups.

One output opcode emits a decoded byte, preserves it as the previous output value, and feeds it back into the accumulator state.

This keeps the interpreter compact while making each protected string appear as opaque bytecode instead of recognizable plaintext or a conventional encrypted blob.

The VM’s hardcoded four-byte XOR key differs by build and doubles as the accumulator seed.

Opcode assignments, constants, and substitution tables also vary. Consequently, a script or signature designed to decode one sample cannot be assumed to work on the next one, even where the underlying deobfuscation objective remains the same.

Zscaler ThreatLabz tracked the evolution, documenting Vidar’s move from simple XOR protection to modified ChaCha20 and, ultimately, a VM-assisted design paired with changing cipher logic.

Custom Bytecode Execution

Vidar employs the VM in two modes: it can decode a string directly, or it can recover material used by a second decryption stage.

In the latter workflow, VM output supplies the key and nonce for a custom stream cipher that decrypts a separate ciphertext array.

In versions 2.0 and 2.1, the initial nine bytes supply key material; from version 2.2 onward, this changes to eight bytes. Across versions, the final four bytes are used as the nonce.

ThreatLabz identified two cipher families. Vidar versions 2.0 and 2.1 use a modified ChaCha-derived design with a custom 128-bit state, an eight-byte key, a four-byte nonce, and sample-specific quarter-round rotations.

From version 2.2, the malware moved to an ARX add, rotate, XOR stream cipher.

The ARX implementation incorporates the recovered key into a 32-bit state using the FNV-1a prime, then processes nonce bytes with the constant 0x9E3779B9, associated with the fractional part of the golden ratio.

Each build applies a distinct series of arithmetic and bitwise transformations and constants before folding the state into a single keystream byte used to XOR-decrypt ciphertext.

The design frustrates static YARA-style matching based on plaintext strings, stable decryptor patterns, or fixed constants.

It also pressures sandboxing and automated triage systems, which must either execute the malware far enough to observe decrypted values or accurately emulate its bytecode engine.

Defenders should prioritize behavior and telemetry over strings alone: suspicious browser-data collection, credential-store access, wallet targeting, archive staging, anomalous outbound transfers, and process execution chains remain more durable detection anchors.

Researchers can also instrument the interpreter, dump decoded output at runtime, or emulate the small opcode set to recover build-specific strings.

Splunk researchers similarly observed Vidar variants using custom virtualization and anti-analysis checks, including checks related to endpoint security products, sandbox indicators, CPU count, storage capacity, and RAM.

Vidar’s latest obfuscation does not introduce strong cryptography for data protection; instead, it operationalizes cheap per-build variation.

That trade-off is effective: stable interfaces let the malware remain maintainable, while changing opcodes, constants, seeds, and ARX sequences continuously erode the value of static signatures.

Indicators Of Compromise (IOCs)

IOC	Description
1628bb03db87f67661349e169d73ee14ed490bdbf22abfbda08ccc9ebe237974	Vidar v2.0
625a381981fc2d4c25c981d98b1d66bb2cf5da2dde2f590add0673a857d5b074	Vidar v2.5
2d43d592630ad1e012da63ef7279f95dd4a8e94964e12ca2f996051875574fa6	Vidar v3.1
979048a749d8f28d877c7068b1b336ecd1e349869dfb1d7c68118f90e4099bc4	Vidar v3.4

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC