Vidar, a well-known information-stealing malware family first seen in 2018, has introduced new string-obfuscation methods designed to slow down security researchers and automated malware-analysis systems.
Researchers at Zscaler ThreatLabz tracked Vidar samples between May and early September 2026 and found that the malware moved from basic XOR string encryption to modified ChaCha20 routines, and later to a custom virtual machine combined with a changing stream cipher.
The updates make each Vidar build look different at the code level, even when it performs the same functions. This approach can reduce the effectiveness of static signatures, which often rely on predictable strings, constants, or byte patterns to identify malware.
Vidar is commonly used to collect browser data, cryptocurrency wallet information, stored credentials, plugins, and other victim-system data.
The malware’s latest protection layers aim to hide operational strings such as error messages, browser collection details, and HTTP headers until runtime.
Vidar VM Cipher Evasion
In Vidar versions 2.x and 3.x, the malware uses a lightweight custom virtual machine to decode protected strings. The VM runs a bytecode interpreter that follows a fetch-decode-execute process.
Each byte in the embedded bytecode acts as an opcode. The opcode selects a handler from a sparse 256-entry dispatch table.
Only 14 entries contain valid handlers, while unused entries stop execution. This design gives Vidar a compact and flexible way to transform hidden data into readable strings.
The virtual machine uses only a one-byte accumulator and does not include a traditional stack or multiple registers.
Its instructions carry out simple operations, including XOR, addition, subtraction, rotations, multiplication, bitwise negation, and substitution-table lookups.
For example, an opcode may XOR the accumulator with a constant, rotate it by several bits, or combine it with a previously decoded byte. Another opcode writes the decoded value into an output buffer.
Vidar also uses a four-byte XOR key that changes with every build. The same value seeds the VM accumulator, making it harder for analysts to reuse a single decoder across samples. Opcode values, constants, and substitution tables also vary between builds.
The VM can directly decode a string or decrypt a key and nonce used by a second encryption layer. Alongside the virtual machine, Vidar uses custom stream ciphers to decrypt selected strings.
Earlier versions used a modified ChaCha-based design with a custom 128-bit state, an eight-byte key, a four-byte nonce, and altered quarter-round rotation values, Zscaler said.
Indicators of Compromise
| IOC Type | Indicator | Description |
|---|---|---|
| SHA-256 | 1628bb03db87f67661349e169d73ee14ed490bdbf22abfbda08ccc9ebe237974 | Vidar v2.0 |
| SHA-256 | 625a381981fc2d4c25c981d98b1d66bb2cf5da2dde2f590add0673a857d5b074 | Vidar v |
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.
Join 16,000+ SOC teams using ANY.RUN to streamline threat investigations and reduce manual effort. Explore for your team
