Every build of the Vidar stealer decodes its strings a different way

Zscaler ThreatLabz published an analysis on 21 September 2026 of how the Vidar stealer now hides its strings. The researchers followed that protection from May to early September 2026, from single byte XOR, through ChaCha20 in internal version 1.5 and on to a modified ChaCha20 from version 1.8. From internal version 2.0 a small virtual machine reads bytecode from the file and computes the strings while the malware runs. The bytecode either yields the string directly, or it yields the key and nonce that a custom stream cipher uses to decrypt the real string. Opcodes, constants and substitution tables differ from one build to the next.

The analysis covers internal versions 2.0 through 3.3, and four file hashes are listed as indicators. Zscaler sums up the obfuscation as built to look different from build to build while doing the same job. The algorithms and the interfaces are kept simple and stable, the researchers write, while the constants and micro operations that static signatures rely on are swapped out continuously.

Vidar was first observed in 2018. Malpedia describes it as a fork of Arkei, and suggests it was one of the first stealers to also collect information on two factor authentication software and the Tor Browser. Obfuscation is not the only part under development. Gen Digital described on 18 June 2026 how Vidar scans the memory of a Chromium browser for the master key behind App-Bound Encryption, then injects asynchronous procedure calls into the running browser to have that key decrypted. With the master key, cookies and saved passwords are readable.

What this means for you if you own the detection rules

Signatures that look for known text inside a file have little to hold on to here. The strings do not exist in the file until the malware computes them, and the recipe for computing them is new in every build. If your detection rests on text in the binary, the names of browsers, wallet paths or fixed HTTP headers, you lose the hit even though the behaviour is unchanged.

Our assessment is that this shifts the weight towards behaviour. What cannot be randomised away is that the malware has to open browser profiles, read the memory of another process and eventually send the loot off the machine. A rule that has gone quiet is no proof that the threat is gone, and nothing in the rule itself tells you whether it still matches.

Berigo recommends

• Test your detection rules against a fresh build of the same malware family, not only against the sample the rule was written on.
• Shift the weight from text in the file to behaviour, and alert on processes that open browser profiles or read the memory of the browser.
• Make a stolen cookie worth less: bind the session to the device, and shorten how long it lives.
• Require phishing resistant authentication with passkeys or FIDO2 where the account matters, so that a stolen password is not enough.
• Treat an infected client as an account incident: change the passwords and revoke the sessions, do not just clean the machine.