There are several binaries in the wild which try to install this RootKit. All the known variants are detected by Microsoft antimalware products using two generic signatures: PWS: Win32/Sinowal.gen!C and PWS: Win32/Sinowal.gen!D.
This Malware attempts to modify the MBR so that it can control what gets read from the disk into memory and execute very early in the boot process. After the modified MBR is executed, it reads additional malicious code into memory which modifies the NT kernel to force it to load a malicious driver that has been stored at the end of the physical disk (The driver will not be visible while the infected OS is running.). Once the driver is loaded into the kernel, it behaves just like a standard kernel mode RootKit, providing covert and stealth network backdoor functionality by hooking low level APIs to attempt to avoid detection. Here are some interesting things about this Malware:
First, the installer for this RootKit needs to modify the MBR in order to ensure that the RootKit can persist across reboots. It does this by using the CreateFile API attempting to open “\Device\Harddisk0\DR0” for write access. Using the CreateFile API in this way (for direct / raw disk access) requires administrative privileges. So if you are logged into Windows as a standard user or if you are using Windows Vista with UAC enabled, even if you accidentally run the Malware installer or it runs via some exploit code, it will be running with insufficient privilege to modify the hard disks MBR; thus it will not be able to persist a system restart.
Next, the perceived strength of this new RootKit, its lack of a visible footprint in the registry and file system due to the use of the MBR as the ASEP, is also a big weakness! If you suspect that you have a system that is infected with this RootKit, to prevent it from loading, all that is required is to write a known-good copy of a master boot record back to the disk to prevent the RootKit driver from being loaded on the next reboot! Fortunately, we have made that a fairly painless process with the Windows Recovery Console and the ‘fixmbr’ command!
Here are some instructions for using the Windows Recovery Console:
Windows XP instructions: http://support.microsoft.com/kb/314058 (just type ‘fixmbr’ in the console)
Windows Vista instructions: http://support.microsoft.com/kb/927392 (just type ‘bootrec.exe /fixmbr’ at the console)
After restoring a known-good MBR to the hard drive, you should be able to start Windows and perform an on-line antivirus scan to detect and remove any of the Malware components or any other Malware that may have been installed on the system and hidden by the RootKit.
The main driver makes outbound HTTP connections to a particular hard-coded IP address or domain. We presume this is so that it can receive instructions and/or register with its overseer. It may also be able to receive instructions which allow it to act as an HTTP proxy, or to download and execute further Malware. The Malware makes similar connections to a number of domains which appear to be pseudo-randomly generated.
Example:
VirTool: WinNT/Sinowal.A
--------------------------------------------------------------------------------------------------------------------------------------------- When the Malware is executed, it creates following files:
VirTool: WinNT/Sinowal.A creates an executable temporary file with the prefix 'ldo'
eg: "c:\Documents and Settings\User\Local Settings\Temp\ldo1.tmp". It then executes this file.
It launches itself, using another temporary file with the prefix 'cln' as the parameter
eg: --cp "c:\Documents and Settings\User\Local Settings\Temp\cln2.tmp".
This action creates a copy of the original file and "converts" the file to a DLL.
The newly created DLL is then loaded. It creates the following service:
ServiceName = "{7663B344-A474-4eff-A35D-F5BE7F6531B4}"
DisplayName = ""
StartType = SERVICE_DEMAND_START
BinaryPathName = "%SystemRoot%\System32\svchost.exe -k netsvcs"
It sets the following registry key so the DLL can run as a service:
Adds value: ServiceDll
With data: "c:\Documents and Settings\User\Local Settings\Temp\cln2.tmp"
To subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{7663B344-A474-4eff-A35D-F5BE7F6531B4}\Parameters
It starts the service; the service drops a driver to: "
and installs it via the following registry modifications:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{4C35FFDF-5669-4e96-8F6B-6CE0C16B4331}
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{4C35FFDF-5669-4e96-8F6B-6CE0C16B4331}\ImagePath=\??\C:\WINDOWS\System32\{4C35FFDF-5669-4e96-8F6B-6CE0C16B4331}
MBR Modification
The abovementioned mentioned file 'ldo1.tmp' is responsible for modifying the hard disk's MBR (Master Boot Record) and writing the main driver and driver loaders portion directly to disk.
It attempts to access the hard disk directly via a previously installed driver. If this fails, it then reverts to trying to access the hard disk directly via \\.\PhysicalDrive0.
The original MBR is then overwritten with malicious code. Additionally, the main driver is written to the end of the physical drive, from where it is loaded directly.
Once complete the Trojan sleeps for a random period of time between 15 - 30 minutes in length, after which it initiates a system shutdown. The dialog box displaying the countdown timer is hidden from the user.
Backdoor Functionality
The main driver makes outbound connections via HTTP to the following hard coded IP address: 74.86.208.140. Presumably this is to receive instructions and/or register with a remote attacker. Static Analysis suggests that the main component can receive instructions which allow it to act as an HTTP proxy, or to download and execute further Malware Currently, these domains resolve to the following IP address: 72.5.175.97.
____________________________________________________________________________________________________
Rootkit Installation 1 - Loads a driver in via ZwSetSystemInformation API. A very old, known and effective way to install a rootkit.
Rootkit Installation 2 - Loads driver by overwriting a standard driver (beep.sys) and starting it with service control manager (e.g. Trojan.Virantix.B).
DLL Injection 1 - Injects DLL into trusted process (svchost.exe) by injecting APC on LoadLibraryExA with "dll.dll" as a param. The string "dll.dll" is not written into process memory, it's from the ntdll.dll export table which has the same address in all processes. The APC is injected into second thread of the svchost.exe which is always in alertable state.
DLL Injection 2 - An old technique. The DLL is injected via remote thread creation in the trusted process, without using WriteProcessMemory.
BITS Hijack - Downloads a file from the internet using "Background Intelligent Transfer Service" which acts from the trusted process (svchost.exe)
____________________________________________________________________________________________________
No comments:
Post a Comment