MW-Blog

Virut is a weird freak amongst malware. It’s a file infecting virus with IRC capabilities. It doesn’t use exploits to spread, but rather relies on filesharing by infecting various .exe and .scr files.

Virut infects the executables by appending itself at the end of the file, and pointing the entrypoint for the file into the beginning of it’s own code. This adds approximately 5000 bytes to the filesize.

When the execution starts, the first thing Virut does is it saves the real entrypoint into the stack as the return address:

And this is what the stack looks afterwards:

Next, Virut locates the offset to the PE header of Kernel32.dll:

Once the offset for the PE header of Kernel32.dll is found, the stub goes into loop, trying to locate GetProcAddress from the export directory:

If the stub doesn’t find the GetProcAddress in the export table, it will return from the stub into the real entrypoint of the hostfile.

Once the offset is found, the stub will resolve few functions from the kernel32.dll, namely CreateEventA and CloseHandle. CreateEventA is then called with VT_3 as the event name. If the call fails, the stub will exit and return to the hosts entrypoint. This is to ensure that only one instance of Virut is active at any given time.

Now we’ve eaten the starters and get to the main course. Rest of the Virut body is decrypted in one simple loop:

All the rest of the imports that are needed are resolved afterwards:

The same loop is used a bit afterwards to resolve needed functions from ntdll.dll

What’s funny is that after the functions have been resolved, Virut will save the 2nd byte from each function:

For now this looks a bit retarded, but I hope we’ll find a reason for this later on :)

Next thing Virut does is it relocates itself. Usually malwares do this by calling VirtualAlloc and VirtualProtect, but this is not the case with Virut. What Virut does is it calls ZwCreateFileMapping with handle value of 0xFFFFFFFFh, which maps to INVALID_HANDLE_VALUE.
The MSDN library dictates the following behaviour in this situation:

“If hFile is INVALID_HANDLE_VALUE, the calling process must also specify a size for the file mapping object in the dwMaximumSizeHigh and dwMaximumSizeLow parameters. In this scenario, CreateFileMapping creates a file mapping object of a specified size that is backed by the system paging file instead of by a file in the file system.”

Also, Virut uses W32_Virtu as the lpName parameter:

And right after this, the actual relocation takes place and the execution is moved to the new memory page:

Right after relocation and the jump to the copied code ADVAPI32.DLL is loaded into memory. Virut then calls CreateToolhelp32Snapshot, and loops through the process table locating winlogon.exe and opens the winlogon.exe process:

Virut then writes off� itself into winlogon.exe (and into other processes as well), and executes� the remote code� by calling kernel32.CreateRemoteThread.

The remote thread that was created will carry on living inside winlogon.exe, disabling the Windows FileProtection (SFC_OS.DLL), and it also connects to the IRC server of the attackers choise, in this case proxima.ircgalaxy.pl (DNS might show up as zief.pl in netstat since they both share an IP address.� The zief.pl domain pops up in quite a many hacking sites and such, so I wouln’t be too surprised if there was a connection between the two.

I could’ve carried out a more detailed analysis of the IRC and SFC-disabling parts, but a cursory glance showed nothing new under the sun. If I get enough requests I might get back to them later on. Cheers

[Edit: 13.2.2009, updated 24.3.2009 (had the wrong link :(]

Virut is seeing a resurrection. Please, read this and consider if you would be willing to help the Law Enforcement to nab these guys. A few well placed criminal complaints can make a difference.

Penetration Testing
Fitsec Ltd - The Evil Eye Penetration Testing Service
http://www.fitsec.com/en

This entry was posted on Thursday, February 15th, 2007 at 2:23 pm and is filed under Malware FreakShow. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.