The massive infection rate described in the article presents just another reason why you need our quiet ThreatFire product protecting your workstation. On a weekly basis, thousands of updated ThreatFire-protected systems were attacked and protected from variants of the bots with a feature we call “behavioral recognition”. It is far superior to AV file scanner signatures and definitively identifies the behavior of malware families like the bots that were a part of the Mariposa botnet. Problems with signature based AV scanner recognition and various Mariposa variant bots were described in a technical paper here.

If you saw a red dialog from ThreatFire warning that it is protecting your system from “Worm.Palevo” or “W32.Pilleuz”, your system was protected from becoming another one of over 12 million Mariposa victims.

In what seems to be fairly unique to Cutwail (also described as Pandex and Pushdo), the initial Cutwail component delivered to a victim’s system is a downloader/dropper, and the spambot code itself doesn’t touch the disk. This scheme is by design. The spambot code appears to exist relatively unchanged over time, while that initial delivery component is re-developed, re-packed and re-distributed in a myriad of ways along with a set of other components. The end goal is to execute the spambot on the system without it touching disk and without maintaining its code in the downloader.

This particular Cutwail downloader connects to these hosts to download the spambot payload and data (domains modified for readability)…

75.126.159 .19:443
89.149.254 .213
89.149.244 .141
94.75.233 .173:443
94.75.233 .171
94.75.233 .172
89.149.244 .23
aaa.oduvanchic .com
aaa.news2days .ru
fireas*eye .com
f*ckbriankrebs .com
antisgetout .cn

It will attempt to connect to one of the above web severs every 20 seconds until a payload is available and downloaded. The sites are actively brought up and down and often do not respond to an infected host, stymieing research progress on the bot. The bot and data payload itself is served up from these hosts as one encrypted stream of data. Once the downloader completes retrieval, the downloader will deobfuscate/decrypt the payload and launch svchost.exe in suspended mode, injecting the payload into that newly spawned process’s memory. After modifying some the loader data structures inside the process via the GetThreadContext/SetThreadContext APIs, the injector redirects execution to the injected code causing the payload to be run instead of the svchost code.

Due to the complicated packing schemes and highly variable injector code, these initial injectors seem more difficult to detect than the relatively consistent spam payload.  Since the payload is injected directly into a real windows process and does not get written to disk, it proves to be quite elusive.

Once injected and run, the spambot code waits a prolonged period of time to begin its spam run. From our lab, after an eye-rollingly long wait, we collected image-based spam sent out to market prices to Russian readers for spam services:

The image advertises a Moscow based phone line for the “Email distributions. Affordable prices – high quality” touted across the top and the left panel. Price ranges are provided for both Moscow and Russia blasts below (we added the price conversions to USD):

Our price list:
——————————————————
Whole Moscow  =  5000 rubles  ($166 USD)
4 distributions in Whole Moscow  =  10000 rubles  ($333 USD)
——————————————————
Whole Russia = 10000 rubles  ($333 USD)
4 distributions in Whole Russia = 20000 rubles  ($666 USD)
——————————————————
Russia+CIS (Commonwealth of Independent States, the territory of the former USSR)  = 15000 rubles  ($500 USD)
4 distributions in Russia+CIS = 30000 rubles  ($1000 USD)
——————————————————
We have:
——————————————————
-The lowest prices on a market.
-The most present day software.
-Regularly updated databases.
-High response from distribution.

Vulnerable systems with out-of-date Adobe Acrobat installs are the main focus of the attacks involving the Tedroo spambot. The spambot commonly is being distributed via a set of canned attacks using what appears to be a version of the Liberty Exploit kit. The Liberty pack maintains an effective set of Acrobat attacks, and considering the thousands of Acrobat attacks prevented on ThreatFire systems since the beginning of Jan, the attacks themselves are well chosen — vulnerable versions of Acrobat Reader continue to be readily available, even in this new decade. 

Once the malformed pdf’s shellcode is passed control on a victim system, it attempts to download multiple components from another server. In our samples, a system hosted in China. There are several downloads to choose from on the server. The first of the files is a loader, carrying a packing stub somewhat similar to the recent Bredolab packed malware with an outer layer of encryption on top of a UPX packed inner layer. It drops a dll to an alternate data stream of a random file in the windows or system32 directory. It then registers that ADS in the AppInit_DLLs so that the dll is loaded at startup. The dll is loaded, and maintains a long list of paths and executables. Most are related to security solutions (examples are listed below) and system components. It terminates a group of them immediately. It then adds entries for security software to the Restricted Software Policy list in the registry, an AVKill method that we haven’t seen fully described as one elsewhere:  HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\<SID>

C:\Documents and Settings\All Users\Application Data\PC Tools
C:\Program Files\Common Files\PC Tools
C:\Program Files\Kaspersky Lab
C:\Documents and Settings\All Users\Application Data\Kaspersky Lab
C:\Documents and Settings\All Users\Application Data\Kaspersky Lab Setup Files
C:\Program Files\ESET
C:\Program Files\Panda Security
C:\Program Files\Avira
C:\Program Files\Norton AntiVirus
C:\Program Files\Alwil Software
C:\Program Files\Agnitum
C:\Program Files\Symantec

With that undetected (on the day of discovery) component loaded and AV processes killed, the Tedroo spambot is loaded. In the latest loader variants associated with the bot, we observe an interesting entry point with anti-debug and anti-emulator tricks that can be vaguely described as an abuse of “Modern” CPU Instructions. In this case, the packer implements an unexpected x86 VMX instruction — VMLAUNCH. Versions of reverser-friendly Ollydbg decode it to “sgdt edx” and cannot handle the instruction at runtime, reporting to the user that it does not know how to step into it, while some vendor emulators also have a difficult time decoding it. 

Windbg, on the other hand, decodes the vmlaunch command properly as specified by the Intel Reference material, seen below…

Following the malware entrypoint, a windbg deadlisting shows “mov ecx, 0×4fffh”, followed by the vmlaunch. On processors we observed, this setup thows an exception for an Illegal Instruction with ecx = 0×4fffh. The writers of this trick, however, took it upon themselves to force the code to trigger this exception 20,479 times (the decimal representation of 0×4fffh). It’s implemented by registering an SEH pointer to code that simply stores the counter, decrements it, and returns back into the ExcecuteHandler2 function within ntdll that’s within the standard flow of Windows exception handling. Each time, the exception “handler” code returns back into RtlDispatchException and eventually NtContinue, where CONTEXT.eip takes control directly back to the Illegal Instruction location, triggering yet another exception. When the counter finally is decremented to zero, the unpacking stub then modifies CONTEXT.eip on the stack so that flow passes out of this exception loop at ntdll.NtContinue and further into its unpacking stub. Tricky stuff indeed.

Decrement ecx value within the process CONTEXT struct

Continuing on its code path, the code first checks if it’s been run before on the victim system, looking for registry values it creates:

HKCU  “Software\Microsoft\Windows\CurrentVersion\Run”
 HKCU  “Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run”
 HKLM  “Software\Microsoft\Windows\CurrentVersion\Run”
 HKLM  “Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run”
    value: userini path: c:\windows\explorer.exe:userini.exe

It copies itself as an alternate data stream of explorer.exe
     c:\windows\explorer.exe:userini.exe

It sets this ADS to load at startup in the various autorun registry entries listed above, and then runs thru a series of sleeps/gettickcout to delay activity and cloak itself.

 After a long wait, the spambot calls InternetConnectA and HttpOpenRequestA to contact its hardcoded server and retrieves more spam templates. The resulting spam recently has all led to www . pharm directbook .com, another ”Canadian Pharmacy #1 Internet Online Drugstore”. This behavior is similar to that noted in our past post. The sites have been run for years by a group otherwise known as “Glavmed“, selling knockoff, illegal pills with shifty names like “Viagra Professional”…

In spite of the significant shutdowns over the past year, spam like Tedroo’s continues to mess it all up on the net. Don John couldn’t have tried to mess up a good thing any better himself.

Streamviewer.40050.exe (and other streamviewer + random version names) has been flying off the shelf at a server on 64.20.38.171. That ip hosts multiple badware domains:
go-exe-go.com
reverse38-170.reserver.ru
gruzzilla.com
hot-exe-area.com
last-exe-portal.com
main-exe-home.com
super-exe-home.com

Interesting about the downloader is the way in which additional malware is downloaded and dropped by this phony codec. It contacts a set of servers with encoded data about the system.
reportsystem32.com (216.240.146.119)
terradataweb.com (66.199.229.229)
dvdisorapid.com (64.27.5.202)
superimagesart.com (95.211.8.61)
thenewpic.com (66.148.80.4)

It then pulls out data from a decoded xml file containing a list of urls to contact for a variety of .gif images (titem.gif, qwerce.gif, 217.gif, etc).
superimagesart.com
thenewpic.com
stockshopimages.com
imagesoffline.com
theimagesphoto.com
imageheadphones.com

At the time of download, gif viewers will display titem.gif with a political message about french politician Christine Boutin:

Know that we do not endorse any political message with this post. But this gif image is no ordinary image. If it were, its size might reach 35 kb at the most. Embedded in the image is the encrypted payload, bloating the image out over a couple hundred kilobytes (~270 kb).
The downloader gathers the response information from the previous sites to find more urls to contact and finds its decryption key. It then uses its key to decrypt the code embedded within downloaded gifs.

Much like the recent (and possibly related) beladen downloader and the older Tibs downloaders, this malware delivery embedded image scheme attempts to evade gateway appliance based protection and optimized AV scans with gif-based encrypted payloads. It stymies automated web crawling based research efforts. No longer are we seeing simple xor decoding schemes with visible PE headers in downloaded image files. The encryption implemented for this attack was another previously commerical and proprietary encryption algorithm.
ThreatFire is preventing this downloader in fairly high prevalence.

Do not fall for IM messages or email claiming to warn you of a UPS delivery failure, carrying a zip archive (invoice_8612112.zip) and containing a filename like invoice_8612112.exe. If you do see such a thing, please make a copy of the text of the message and contact us in our comments section. It seems to be changing. Do not run the file.

A couple of the downloaded, packed files appear to carry with them tricks that continue to evade AV file scanning with VirusTotal results at 5/36.

For example, a chunk of the standard download and execute shellcode that we are currently seeing pulls a file from hxxp://ascoprguide. net/lel / load.php?xpl=pdf, renames it as c:\\U.exe, and runs it on the victim’s system. This “U.exe” then runs and installs other adware and spyware related components.
Other downloads are installing various Rogueware packages, like the ones we presented at Virus Bulletin 2008.

Be sure to visit the Adobe site and update your Acrobat Reader software.

He wanted to demonstrate AV shortcomings by providing competing teams with a set of AV-scanner detected malware samples, one after another. The samples would be tweaked by the participants in a way so that the core activity of the software would not be changed but the file would evade on-demand file scanners and remain undetected by 32 scanners. Eventually, one team would race to “zero detection” on all ten samples first. And he wanted it to be fun — “Reverse engineering and code analysis is fun.”

What he succeeded in demonstrating, from what I could tell, is that there are high levels of complexity involved in the setup, preparation, support and understanding of his “competition”.
Understanding malware, an environment for working with it, the variety of antivirus products and their uses, PE files, assembly level programming, network traffic, exploits and their delivery vectors, and the relevance of each to AV scanner effectiveness, are all beefy topics that the organizers and their helpers didn’t seem to either fully grasp, have the resources to adequately deal with, or both.
Running a handful of command line scanners across a handful of questionably selected (a MS-DOS variant, several widespread worms from several years ago, exploits against Word 2000 without any copies of Word 2000 to test against, etc) malware samples to be modified doesn’t really provide the amount of quantifiable results to make large claims for a cost/benefit analysis of security defense and the evaluation of AV scanners. Professional AV test and review groups themselves have a difficult enough time carrying out this sort of evaluation effort with hundreds and sometimes tens of thousands of samples with days or weeks of paid and competent effort, often without the limits of a group of volunteer organizers and speakers attempting the project.

While the subject of the AV evasion black market is always an interesting one for those pushing a behavioral-based technology like ThreatFire, this first “competition” didn’t seem to live up to the attention that it received (as the organizer seemed to expect). We’ll wait for a technical paper that was proposed to be delivered:
“We hope to be able to give a presentation of findings from Race to Zero at DefCon, a paper has been submitted but a decision on it has not yet been made. Following the contest, when further analysis has been conducted, a technical paper will be publicly released.”
Maybe the public paper or an event next year will bring more interesting results with it.

Homer’s Ulysses wanders for years, returning to his home and his family in disarray. Initially, the only witness to recognize Ulysses in his home is his old dog Argus, faithfully waiting for his master’s return over those 20 years: “As soon as he saw Odysseus standing there, he dropped his ears and wagged his tail, but he could not get close up to his master. When Odysseus saw the dog on the other side of the yard, dashed a tear from his eyes…But Argos passed into the darkness of death, now that he had seen his master once more.”

Edward Fitzgerald’s “The Rubaiyat of Omar Khayyam” speculates on the importance of understanding the inability to return:
“Then to the lip of this poor earthen Urn
I lean’d, the Secret of my Life to learn:
And Lip to Lip it mumur’d — “While you live
Drink! — for, once dead, you never shall return”

Unfortunately, in our last round of spambots, we find lots of return. However, these returns do not provide deep insight or wistful second comings. Instead, these returns serve to obfuscate the functionality of the rootkit driver component (”pgasghjd.sys”) that appears to be the newest project of one of the rustock creators:
C:\progz\NewWork2\driver\objfre\i386\driver.pdb

Return is a powerful computing concept, and an important part of any CPU instruction set. The “RET” or “Return from procedure” instruction “transfers control to a return address located on the top of the stack”.
These returns are used in an unusual way in the unpacking stub of the driver, avoiding making standard calls early in the routine. Here is the driver’s entry point.

Notice the push of a hard-coded offset and the immediate return. This unusual sequence of assembly instructions simply pushes a return address to the stack, only to take control when the “ret” or “retn” is executed and control flows to this new offset. This sequence can be used as an effective emulator evasion trick.

These returns do not provide anything all that valuable, instead, these returns help to produce the unwanted spam, clogging global network pipes and peddling “male enhancement” drugs. These are the messages that are crass and vain, including with them a link to a couple of these “drug” peddling web sites. Obscene messages are not reproduced here, but here are a few examples:
“Give your chick a night to remember”
“Make sure you don’t get left out of the action at parties”
“Fantastic results guaranteed”

Some returns come with really bad literature.

However, there is one construct that the developers behind the code seem to enjoy using. In almost every place where an event and sometimes registry value names are created, the name is generated by a function which is similar between variants.

The function derives this name from an attribute of the infected computer. The attribute is the serial number assigned to the “C:” drive volume when it was last formatted by the operating system. Then, the serial number is randomized by one or more bitwise cpu instructions against a number selected by the programmer. The result of these operations is converted into a string and returned for use.

The recognition of this function can help positively ID a Vundo sample. The source code representation of this function would look similar to this:

#include <windows.h>#define arbitrary_vundo_number 0xFDEC

int generate_number(char *output){    int return_value;    DWORD volume_serial_number;

    return_value = GetVolumeInformation("c:\\", NULL, 0,        &volume_serial_number, NULL, NULL, NULL, 0);

    volume_serial_number ^= arbitrary_vundo_number;

    return wsprintf(output, "%08x", volume_serial_number);}

Actual Vundo assembly code looks like this:

push    esi             ; nFileSystemNameSizepush    esi             ; lpFileSystemNameBufferpush    esi             ; lpFileSystemFlagspush    esi             ; lpMaximumComponentLengthlea     eax, [ebp+VolumeSerialNumber]push    eax             ; lpVolumeSerialNumberpush    esi             ; nVolumeNameSizepush    esi             ; lpVolumeNameBufferpush    offset RootPathName ; "c:\\"mov     [ebp+VolumeSerialNumber], 123hcall    ds:GetVolumeInformationAxor     [ebp+VolumeSerialNumber], 34D2121hpush    [ebp+VolumeSerialNumber]push    offset a08x     ; "%08x"push    [ebp+arg_0]     ; LPSTRcall    ds:wsprintfAadd     esp, 0Chpop     esileaveretn

A couple of previous posts provided insight into what clues strings provide when performing malware analysis, and a concise description of how to decrypt obfuscated strings in a static file using advanced IDA Pro functionality.

Here, we’ll use a debugger to step through a malicious file in the lab and observe data as it is decoded by the malware itself. Sometimes, when speed is a priority and not all that many strings are involved, stepping through the decryption loop prior to writing an IDA script is another good approach to have in the toolkit.
We’ve started the executable within Ollydbg. No human-readable strings are visible to the analyst here, but a quick look at the text section following some unpacking reveals multiple arrays of garbled text. Also suspicious is that each string of unreadable, or probably crypted, data is being passed by pointer to the same function. Most likely, this procedure includes the decryption loop that we are looking for. Each call to this same procedure being passed a pointer is highlighted in a red below:

We can review this loop, setting a breakpoint on the procedures that are passed these strings as a parameter. Somewhere along the way in here, the decrypted data is most likely written out to memory or as a hash. As we single step through the code (hitting F7), we’ll watch for pushes, pops, repeated movs intructions, and look for pointers to strings and data copies from esi to edi. We find an interesting loop here after the garbled text is pushed onto the stack. Notice that string data is being copied from esi to edi:

Following edi in the data dump displays the memory contents as they are written out and decrypted by multiple layers and loops. Setting a breakpoint here and running through the loop reveals the decrypted data. We can single step through this loop to evaluate the decryption algorithm.
Eventually this decrypted data is passed to another function via pointers on the thread stack. Now that we’ve run through the loops, we can identify a list of banks and web sites that our portuguese speaking friends in Brazil may recognize:

Having identified these strings within the malware, we craft few custom written empty web pages with these strings as title bar content. We then open the html pages with Internet Explorer. We’ll witness images stored within the malware being presented in the foreground of the browser, waiting for our login id’s and passwords. Here are a few related screenshots:

These strings helped lead us to identify another all too popular Brazilian banking password stealer. Done with these strings, off for a little samba and sun on the coast of Buzios!