Conficker/Downadup: Memory Injection Model

The worm Conficker/Downadup does not need a special introduction as it was pretty well described in various write-ups in great detail.

Nevertheless, considering it employs a set of unique techniques, a deeper analysis is needed.

One of such techniques is its memory injection model that will be discussed in this post. Note: as the analysis continues, more posts might be expected.

Conficker runs as a DLL file and unpacks itself on the heap of the host executable process, such as rundll32.exe. In order to bypass firewalls (and possibly HIPS too), its author has certainly thought of a proper memory injection model.

The worm calls its memory injection function with the following prototype:

InjectIntoProcess (DWORD TargetProcessID, LPSTR ConfickerDllFilename)

The function is called for the processes explorer.exe, svchost.exe, and services.exe.

For start, the worm will open the target process, allocate a small memory region in its virtual address space, and write in it the full path filename of its own DLL.

Next, it will obtain the address of LoadLibraryA() API imported from kernel32.dll.

The worm will then make an interesting trick: it will call CreateRemoteThread() API by passing it the handle of the targeted process. The thread start address it specifies is the virtual address of LoadLibraryA() API (imported from kernel32.dll). The specified thread parameter is the address of the allocated buffer within the process where the full path filename of the Conficker DLL has just been written.



This will force the target process to spawn a thread that will load the worm DLL file – pretty neat, considering there is no executable code physically injected.

But that’s not all.

Following this trick, Conficker will enumerate all threads running inside the targeted process, and for every thread it will add to its queue an Asynchronous Procedure Call (APC).

For this purpose it uses an undocumented API NtQueueApcThread() which has the following prototype:

NtQueueApcThread(HANDLE hThreadHandle, PIO_APC_ROUTINE lpApcRoutine, PVOID pApcRoutineContext, ...),

where hThreadHandle is a handle of the enumerated thread that receives an APC call into its queue, lpApcRoutine is the address of the entry point to the user APC routine, and pApcRoutineContext is the user defined parameter for APC routine.

Guess what address it uses for the user APC routine? That’s right, it’s the address of the API LoadLibraryExA() imported from kernel32.dll, and the parameter for this call is the name of the Conficker DLL, previously saved inside the process’s address space.



With the APC queued for the target process threads, as soon those threads are signaled, the routine that loads Conficker DLL will be invoked. Hence, the remote injection.

Removing Persistent Malware

This blog post is not for the technical guru!

While it's not for mums and dads either, its main purpose is to explain to an average user how to manually remove persistent malware that cannot be easily deleted otherwise.

A reader who starts shivering from hearing the words "Linux" or "Ubuntu" could find this post useful too – not only to be able to remove persistent malware, but maybe to get closer to Linux and start using it for Internet banking, as a safer alternative to Windows and Internet Explorer (arguably, of course).

Malware removal is a separate big discussion subject. There are many known methods that involve antirootkits, dedicated fixtools, kernel-mode drivers employed by antivirus products that allow to delete, wipe-out, or simply damage locked malware files.

Nevertheless, we keep receiving an overwhelming number of requests coming from various customers asking for help in deleting locked malicious files. This post started as an email template that we utilized in our response, but given the fact so many people ask the same question again, it sounds reasonable to post this information here for a better public exposure.

Let's say, a user accidently clicks an attachment and then realizes something wrong has just happened. The attachment file gets submitted to ThreatExpert. The returned report suggests that an additional malicious file might have been created – the user locates that file and attempts to delete it, but Windows denies access to such file as it's loaded in memory.

Quite often, all it takes is to kill a process to unlock a file, or reboot in safe mode and delete a file that is known to be malicious, or register such file for a delayed removal. But the reality is that in many cases it's not that simple. Malware can be loaded into the address space of a legitimate system process so that termination of such process will lead to system crash. In a different scenario, a file can be protected by a kernel mode driver, and that driver is protected by another watchdog thread running inside a legitimate process. The possibilities for malware authors to protect their files are endless. AV industry makes its best to break such protection, but in the end it's still a cat-and-mouse game.

A very simple method to delete malicious files is to boot from a different partition that is known to be clear of malware, and then delete malicious files that reside on an affected partition. This way, the files that reside on an affected partition are not obstructed from being seen or manipulated (e.g. any possible rootkits will be inactive at this stage).

There is nothing new in this method, and there are multiple ways to achieve this. But if you ever experienced locked malware file problem before, it might help to have a Linux start-up CD (LiveCD) in the pocket of your backpack, ready to fix a problem any time you need it.

Scenario

Let's say, a malicious file called malicious_file.exe resides in the %system% directory. This file cannot be deleted for some (unknown) reason.

Disclaimer

Please note that the following description does not cover scenarios when a legitimate file is reported to be malicious due to a false positive, or because a firewall/HIPS system reports a file as suspicious, or because the user thinks it's malicious; it only explains how to delete a truly malicious file, that is a file with a code that performs malicious actions.

If you're unsure about the purpose of the file that you intend to delete, please do not attempt this method. Removal of a system file or a file of a legitimate 3rd party software may lead to corruption of your operating system, any other software or your personal files.

The author of this post takes no responsibility for any data corruption that may happen should this method be chosen and tried out. If you decide to follow it anyway, please do so on your own risk!

Before you attempt this method, please back up your files and documents!

Step 1: Get Ubuntu.

For start, you'll need to visit Ubuntu website to download the latest version of this Linux distributive.

Once you download the ISO image, please follow these instructions on how to burn a boot-up CD or DVD.

Turn off you computer properly from Windows. Disconnect any USB devices you may have plugged in.

Boot your computer from the LiveCD. If you can't boot, please read detailed explanation on how to fix this problem here.

When you start the boot-up process, make your language choice:



then, choose menu option "Try Ubuntu without any change to your computer", as shown below:



Ubuntu will start booting up from your LiveCD. When it's done, you'll see the following screen:



Step 2: Locating and Mounting Affected Windows Partition

Next thing you'll have to do is to find your Windows partition that contains the malicious file(s). In our scenario, it's a file %system%/malicious_file.exe.

Click Menu item "Places", then "Computer" as shown below:



The File Browser will fire up and show a panel similar to the one below:



Your Windows partition will most likely be depicted with an icon of a hard disk drive titled as "[X] Gb Media", where X is the size of your partition in Gb. Most likely, the icon will be a bit different from the "Filesystem" one – it will not have a little green indicator in it because it is not mounted at this point yet.

In case of several partitions, there will be several "[X] Gb Media" icons; you will need to identify which one has Windows installed on it – it's not necessarily the first displayed one.

Right-click your mouse over the hard disk icon and select the "Mount Volume" option – its icon should get a green indicator on.

Step 3: Locate and Rename/Delete Malicious File(s)

In the File Browser, double-click an icon of the mounted partition to inspect the directories and file names on that partition. You should be able to recognize your Windows partition by its contents: navigate to %system% directory and find the file malicious_file.exe. From here, the file can be renamed or deleted, as shown below:



If the malicious file was renamed or deleted successfully, shut down Ubuntu (shown below), remove LiveCD, and power on your computer to start up Windows again – the system should be clean from the malicious file at this stage.



Troubleshooting: What to Do if Volume Mounting Fails

If Ubuntu fails to mount your partition, it will show the following error message:



If you get this error message, then most likely you did not power off Windows properly. A clean way is to shut down Ubuntu, remove LiveCD, start up Windows again, insert LiveCD, power off your computer from Windows in a clean way (e.g. by clicking "Turn Off Computer"), then boot up from the Live CD and repeat Step 2 above.

In some cases, shutting down Windows properly is not possible due to system corruption – e.g. Windows boots up then crashes before you have a chance to shut it down properly, but you still know what files you want to delete.

If powering computer off properly (from Windows) still does not help mounting your Windows partition(s) successfully, you will need to force Ubuntu to do that:

• Close all error messages.



• Start up the Terminal program – you will need to run a couple of commands in it:





• Run the following command to enlist your partitions:
  
  sudo fdisk –l
  


• From the output of this command, take a note on a partition that is marked as bootable (*) and write down its device name. For example, the output below shows that "/dev/sda1" is the device name of the bootable partition – most likely it's the Windows partition that needs to be mounted:
  
  
     Device Boot      Start         End      Blocks   Id  System
  /dev/sda1   *           1         519     2092576+   7  HPFS/NTFS
  /dev/sdb1               1        5099    40957686   2d  Unknown
  /dev/sdb2            5100        9725    37158345    7  HPFS/NTFS
  
  
  


• Now you'll need to mount your bootable partition and map it to a directory, e.g. "mydisk". But first, create that directory by running another command in Terminal window to create "/media/mydisk" directory (this step is optional):
  
  sudo mkdir /media/mydisk
  


• Finally, instruct Ubuntu to mount your bootable Windows partition:
  
  sudo mount -t ntfs-3g /dev/sda1 /media/mydisk -o force
  

If the partition was mounted successfully, the output will say:

$LogFile indicates unclean shutdown (0, 1)
WARNING: Forced mount, reset $LogFile.

You may now run File Browser again and check if any of your partitions has changed its icon to the one with a green indicator in it, as shown below:



Repeat Step 3 for the mounted partition to delete the malicious file(s).

"The Road to Hell Is Paved With Good Intentions", Part II

It's been a while since the previous post discussed commercial "intelligence gathering tool".

It would have seemed ridiculous, if this time it wasn't UK government who thinks it's acceptable to hack into home computers, spread malware via email, log users' keystrokes, or sniff users' traffic, if it "believes" that it is "proportionate" and necessary to prevent or detect serious crime.

Whoever came up with this idea is apparently the follower of Niccolò Machiavelli (1469–1527), a strong believer that "the ends justify the means". Especially when it comes to the fight with paedophiles and terrorists, as if the last two words were doing exceptional job in shutting down one's intellect.

Considering these news follow other ridiculous reports that the UK military will now run nuclear-missile submarines under Windows XP (no, it's not April 1st), one could fairly ask "What exactly is going on in that part of the world?".