The evolution of Rovnix: new Virtual File System (VFS)
Last July, we published a blog about Rovnix’s private TCP/IP stack.
We recently discovered another evolution in Rovnix – a variant that introduces a new Virtual File System (VFS).
With our latest signature update we detect this Rovnix dropper as TrojanDropper:Win32/Rovnix.L and the infected VBR (Volume Boot Record) as Virus:DOS/Rovnix.gen!A.
Unlike older Rovnix variants that store their components as raw disk sectors at the end of the disk, TrojanDropper:Win32/Rovnix.L stores its components in a binary file: %system32%<hex>.bin. Note that this file won’t be accessed normally (see figure 1). This VFS uses RC4 to encrypt the stored data at the disk sector level (see figures 2a and 2b).
Figure 1: TrojanDropper:Win32/Rovnix.L VFS binary file
Figure 2a. RC4 encrypted disk sector data stored in VFS
Figure 2b. Plain text disk sector data
To prevent this file from being accessed, TrojanDropper:Win32/Rovnix.L installs a mini-filter and also hooks kernel APIs (e..g NtCreateFile( ) and NtDeleteFile( )) to protect this file.
This new variant also contains a user-mode bot code, which uses the VFS to store the data such as keylog and stolen passwords (see figure 3).
Figure 3: (Rovnix variant) uses VFS to store stolen data
Clearly, this is another step in Rovnix evolution for stealth and reliability purposes. This VFS can be used not only for storing Rovnix’s components, it can also be accessed from user-mode component (the bot) for data storage.
Fortunately, this new variant doesn’t pose any more of a challenge for detection and remediation. As always, the best way to stay protected is with an up-to-date real-time security product such as Microsoft Security Essentials or Windows Defender.