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.

Not exactly “hacked drones”, but poorly secured at the least.

SkyGrabber by SkySoftware

On a day to day basis, malware researchers locate a sample of interest, which can seem similar to isolating a grain of sand on a beach, and investigate it in the lab.  Some tools are utilized to capture information generated by the sample which typically include changes to what Windows runs at startup, browser default page settings, newly installed programs or libraries, generated network traffic, and, if neccesary, unpacked/decrypted copies of the sample.  With most samples, this information collection process is straight forward, but Zbot is smarter than your average malware.

These tools are very effective for analysis because it can be easy to determine which changes came from which programs.  After unpacking a regular malware sample, it is possible to control it using a debugger and walk through interesting sections of code to see how it works.  This ease of analysis is where Zbot separates itself from typical malware.

The first action recent zbot variants perform is to unpack themselves (sdra64.exe, F836BA2BA0CEE2B8F0CFEE31BB535515), and instead of performing any immediate botnet-related tasks, it injects this unpacked code into the winlogon.exe process and terminates itself.

This injection is interesting for two reasons. First, the winlogon process is very sensitive.  For instance, asking a tool like process explorer to terminate the winlogon process can cause a blue screen of death.  Even if an anti-virus scanner detects this payload in memory, it is tough remove because it has to be careful not to take down the winlogon process with it. So the selection of this process target in particular was carefully done.  Secondly, the payload of this injection requires running inside the actual winlogon process for initial activation.  The payload attempts to piggy-back off of a “non-IO worker” thread running uniquely within the winlogon process via the CreateTimerQueueTimer() function. If the payload is artificially injected into another process, the payload will not exhibit its malicious behavior. This runtime requirement makes it difficult to emulate the payload’s environment for research purposes.

A portion of the payload does not only execute from within the winlogon process, however. The activated code running within winlogon (described above) also injects a copy of itself into the first real svchost.exe process that it finds.  It uses the same thread piggy-backing techniques employed in the winlogon process.  One of the first tasks that this newly injected payload performs is the downloading of the encrypted configuration file.  Later, after this configuration fetching task is complete, it injects this same payload into all other processes, which then engage API hooks to intercept the victims’ online banking web traffic.

These injection and information stealing tasks are all coordinated with the payload residing in the winlogon process via named pipe inter-process communication mechanism.  The pipe is typically accessed via the file name “\\.\pipe\_AVIRA_2108″ and uses a mutex with the same name (_AVIRA_2108) to guard against simultaneous access to this resource by multiple payloads in other processes.  This named pipe is watched for a series of number commands which perform particular actions, some of which are listed below:

05: opens local.ds
06: closes local.ds
07: opens user.ds
08: closes user.ds
09: closes sdra64.exe
10: opens sdra64.exe
14: intentionally causes a NULL pointer dereference (crashes the winlogon process, resulting in a BSOD)

In the screenshot provided below, we can see a piece of code that executes immediately after downloading the encrypted configuration data.  It sends the command “6″ to the named pipe which tells the winlogon payload to close the “local.ds” data file, which resides in the %SYSTEM%\lowsec directory.  It then writes a fresh “local.ds” file to this directory, and instructs the winlogon payload to re-open this data file with the “5″ command.

Svchost Example Zbot Commands

Separating the malware execution into code chunks that reside in different processes makes it difficult to analyze what this bot actually does. With each chunk camouflaged inside a real process, the separation also makes it difficult to properly clean off your system once infected, due to the infection being spread all over legitimate processes.

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.

Another technique and tool has just been posted to abuse stolen biscuits, much like the Koobface worm, and it supports changing a wall without the password. The author claims to have just completed “FBController – The Ultimate Utility to Control Facebook accounts without the Password”.

Be aware that downloading and executing code from untrusted sources is always a problem, and please do not fall for the ongoing phony video codec or software update ploys.

Update – a cnet writer finds the techniques interesting.

At worm runtime in the lab, we observed that one unpacked loop in particular was taking excessively long to execute prior to any identifiable malicious behavior from the worm, and this same loop is present in four of the five binaries that the Koobface flash_update component is dropping. So we took another look.

Within the common loop, GetTickCount() was called and bytes were moved and compared, but it seemed that no real decryption was occuring. Persistent data was not rewritten or modified. This sort of activity is suggestive of something called a time-lock: “A common anti-emulation trick is to introduce loops that take a relatively long time to compute. The loop may in fact take so long to emulate that the antivirus scanner gives up.”
However, what appears to be a Koobface time lock implementation is very simple, much more simple in its implementation than the ones formalized in the paper linked to above. But the concept is just as interesting in that it implements a variable length lock duration at runtime. The amount of time dedicated to spinning through the loop is in part dependent on the amount of time that the system has been running. And yet, the technique’s usage is uncommon in that there are not two timing calls and a hardcoded value to compare against to detect emulation. Instead, this unusual variability is due to its unique use of a singular GetTickCount() call and a comparison to a counter value that is also being incremented.

Here is the loop that we were interested in, as viewed through a debugger:

00401712 |> /83C9 FF /or ecx, FFFFFFFF
00401715 |. |33C0 |xor eax, eax
00401717 |. |8D7C24 10 |lea edi, dword ptr ss:[esp+10]
0040171B |. |F2:AE |repne scas byte ptr es:[edi]
0040171D |. |F7D1 |not ecx
0040171F |. |49 |dec ecx
00401720 |. |3BF1 |cmp esi, ecx
00401722 |. |73 18 |jnb short DA3FE57A.0040173C
00401724 |. |8BC6 |mov eax, esi
00401726 |. |99 |cdq
00401727 |. |B9 05000000 |mov ecx, 5
0040172C |. |F7F9 |idiv ecx
0040172E |. |8A4C34 10 |mov cl, byte ptr ss:[esp+esi+10]
00401732 |. |B0 FB |mov al, 0FB
00401734 |. |2AC2 |sub al, dl
00401736 |. |02C8 |add cl, al
00401738 |. |884C34 10 |mov byte ptr ss:[esp+esi+10], cl
0040173C |> |46 |inc esi
0040173D |. |FFD3 |call near ebx ; kernel32.GetTickCount
0040173F |. |83C9 FF |or ecx, FFFFFFFF
00401742 |. |8BD0 |mov edx, eax
00401744 |. |33C0 |xor eax, eax
00401746 |. |8D7C24 10 |lea edi, dword ptr ss:[esp+10]
0040174A |. |F2:AE |repne scas byte ptr es:[edi]
0040174C |. |F7D1 |not ecx
0040174E |. |49 |dec ecx
0040174F |. |03D1 |add edx, ecx
00401751 |. |3BF2 |cmp esi, edx
00401753 |.^\72 BD \jb short DA3FE57A.00401712

When the first location is jumped into, esi is already set to “0″.
It’s a nice loop — the last insruction takes you back to the first almost every time, but the loop is executed an unpredicatable number of times. Mostly all of the instructions within the loop are arbitrary in that they do not modify any data. For example, the “repne scas byte ptr es:[edi]” instructions simply read through a hard-coded string, looking for the null byte at the end of the string. That same string is read again and again, almost like a strlen() that doesn’t return a value:
void strlen (const char * str) {
const char *pstr = str;
while( *pstr++ ) ;
}
When GetTickCount is called, it returns the number of milliseconds that have elapsed since the system was started. Because this value changes on every system it is run and every time it is called, the duration of the time lock will be unpredictable. When edx (our TickCount) is sub’d from esi, the CF flag is set to “1″, and the jb instruction sees the value as “below”, so we jump back to the first instruction location. Every loop execution, both the esi and edx values are incremented and then compared. When they are equal, the loop is exited.

Therefore, the effect is that emulators may “give up” on this executable due to the loop, but the behavior is somewhat unpredictable. Sometimes, the lock duration will be short enough for an emulator to hang on and perform an erratic detection. This erratic detection may cause confusion for AV scanner vendors relying on emulation capabilities and create a false sense of effective detection.

Finally, it is interesting that the “worm” components and droppers contain this same loop, as though it were a macro simply copied and pasted into the source for the various executables. The final and money making adware payload, “tinyproxy.exe”, did not contain the loop. The adware/spyware component most likely was obtained from another party.

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.

One of the topics near and dear to our PC Tools hearts happened to be the focus of Joe Stewart’s presentation on reversing Storm titled “Protocols and Encryption of the Storm Botnet”. It was somewhat of a Virus Bulletin style presentation, but he added a lot of information regarding offensive techniques for joining the Bot network, disrupting it, and details of his findings about the bot network’s communications. It was great stuff.

Also interesting was Jonathan Rom’s talk on implementing a javascript based persistent rootkit. While it was somewhat stealth, I don’t know that it classified as a rootkit. However, the malcode was fairly well hidden in the plain text file he discussed. And while the design flaw that the code is dependent on for functionality has been patched in Firefox 3 and wasn’t as platform dependent as the intro suggested, the idea was well implemented against XP systems in their demo.

Off to another talk on the development and functionality of dns tunneling reverse shellcode.

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

First off, the Detours project out of Microsoft Research focuses on “Binary Interception of Win32 Functions“. In other words, when a developer or malware writer wants to hook a function inline and insert their own code, they can intercept a win32 function with code from the Detours library.
To use this code commercially, “Detours Professional 2.1 includes a license for use in production environments and the right to distribute detour functions in products…For information on licensing Detours Professional 2.1 contact Microsoft’s IP Licensing Group at iplg@microsoft.com”. Let’s assume either that Microsoft never provided the vundo developers with a license or that the vundo developers never attempted to obtain a license for their “commercial” use.

One of Vundo’s library components currently in the wild is injected into processes as a part of its attack. This component may in turn be detected by anti-spyware scanners using the EnumProcessModules api call, which would provide an anti-malware scanner using that call with a handle to the injected module. And this is where the abuse begins.
You can see the malicious Vundo hook in this screenshot, implementing the hook functionality from the Detours library. Basically, if a process calls EnumProcessModules, the vundo appropriated code will intercept the win32 function and report that the module enumeration procedure failed. When the EnumProcessModules call fails, certain security scanners are unable to detect the vundo component’s presence:

How can Detours code be identified in this dll? Well, the source of the detours library can be placed side-by-side with the unpacked and disassembled vundo component. In many places, the same sequence and order of instructions and data is unmistakably identical. For the sake of brevity, we’ll focus on just a couple that briefly illustrates our point in this post.

Here, the deadlisting for the vundo function is on the left, and the matching Detours source code on the right. This chunk of Detours code is at the core of the hooking functionality within disasm.cpp of detours.lib. The source from the Detours library here is determining the length of the currently evaluated instruction and then copying the instruction to the trampoline buffer (this location is the place where the inlined vundo rootkit function can call back into the original function without interception). The appropiated code on the left is compiler optimized, and it is a mirror image of the Detours logic on the right:

Here, in a similar fashion, we see vundo functionality that was stolen from the Detours library calling the DetourCopyInstructionEx() function and an inlined detour_does_code_end_function() function. In this reversing illustration, the vundo function is performing checks to ensure the target function’s eligibility for interception. In other words, vundo’s appropriated Detours code is checking to see if the target function contains a select set of instructions that would prevent hooking: