That quote comes from the recently published Prospective Analysis on Trends in Cybercrime from 2011 to 2020, by the French General of the Army, Marc Watin-Augouard.

This study was originally published in French by a panel of experts from the public and private sectors. I was one of them.

Our approach was based on the Delphi method, an iterative process of discussion based on a questionnaire developed by a scientific committee, with interim summaries drawn up by an ad-hoc committee. The paperless discussion method was effective and kept participant responses anonymous, which leveled the playing field. The 22 experts who contributed to this study underwent three rounds of individual interviews, allowing them to express their opinions and reformulate their responses based on the results of the group discussions. Their analyses and individual expertise have led to a blank document that outlines typical criminal trends of the 21st century. The process took one year to present the results in this summary.

The result of this work is not an end in itself, but rather a tool to encourage discussion among policy makers, business leaders, and representatives of civil society regarding strategies to maintain the best possible control in a digital world without borders.

McAfee has translated of the results of this new French study on computer-related crime. McAfee, and I, consider this methodical and original research invaluable in explaining the threats we face today and predicting what we might see in the years up to 2020. Armed with this expertise, we can more effectively protect ourselves against future cybercrime.

The English version of the document is available here.

We found a couple of such toolkits on the Internet. They are also available for sale on various forums over the net.

Each tool performs a specific function. For example, the folder Pinterest Content Locker contains a couple of scripts to set up scams. This particular one is a scam technique in which victims visit the website and get a “content locked” message stating that they need to click on the “Pin It” button to unlock the content. Here is an example:

In the php code we can see the following:

The code contains an array of links and it randomly selects one to post on Pinterest. It also uses an “unlocked” cookie to check whether a user has already visited the webpage and clicked on the pin button.

The scam requires that a victim click on the “pin it” button before seeing the content of the web page:

The code then calls a function Clicked. This function opens a new window and takes the user to Pinterest for pinning the content. Then it calls another function Remove_Overlay:

This function sets the cookie “unlocked” with value =1 and expiration date as the current date plus one. This is done so the next time users open the same URL, they will not get the content-locked message.

The code also has the folder viral script, which contains a php file used to display various scams:

The image asks the user to click on the “pin it” button, which posts the URL to Pinterest. Then it asks the user to perform the final step, which leads to an attacker-defined survey URL.

The trick is to get victims to click on the “pin it” button before clicking on “Final Step.” If users first click Final Step, then they see this message:

Let’s look at the code of “Click Here”:

It has a link element with id=”linkos” and whose value is javascript:window.alert(“Please Complete Step 1”).

This value can be modified at runtime after the user has clicked on the “pin it” button, shown in the next image:

When a user clicks “pin it,” it calls the function “PopupCenter, which will post the link to Pinterest and call the function “RevealLink.” This function changes the value of “linkos” as follows:

Another template employs the preceding technique with a different GUI, which seems like the actual Pinterest site:

The template contains an executable named Pinterest Amazon Product Submitter. This is a bot that scrapes Amazon for products based on given keywords and then submits them to Pinterest.

When victims click on a Pinterest post they are redirected to the scammer’s site, which will contain a “redirect script” or “cloaker script” that will simply redirect users to Amazon with the scammer’s affiliate ID. Amazon does not see the referral as Pinterest but rather as the scammer’s custom page–and the scammer can earn money:

There is also a mass bit.ly link generator, which will generate random links for the scam’s URL:

The trick here is to use “?” at the end of the URL so that tool will add a random string after “?” and get different URLs from bit.ly. This technique makes it possible for an attacker to generate as many random URLs as needed, with all pointing to same location.

Another script, “Detecting Mobile Phone Visitors,” can check the user agent of the web browser and determine the device from which a user visits the site.

Depending upon the device, a user can be redirected to a variety of URLs. We have observed that in the case of mobile devices, the redirection often leads to pornographic images which, upon being clicked, open a phone dialer with premium calling numbers. In the case of nonmobile devices, the redirection often leads to various survey scams.

The toolkit also includes “Pinterest follower bot,” which can be used for mass following on Pinterest:

We also find a tool for making mass comments on Pinterest posts:

Another tool generates Pinterest invites:

And would you believe that these tools even come with well-written documentation?

Such toolkits make it very easy for scammers to start their own scam sites and become functional cybercriminals with a minimum of skills and time. They need only change a couple of simple things, such as URLs, and they are ready to go. Almost all these steps–from creating mass Pinterest accounts to mass liking, commenting, and posting–have been automated.

Most of these scams try to lure users with titles such as “get free gift card,””Shocking Video,” “you can not believe it,” etc.:

When users click on such URLs, they will be:

• Redirected to a survey scam, where scammers earn money when users complete surveys
• Redirected to Amazon or another site, where scammers can earn money by referral
• Led to premium calling numbers of mobile devices

Please follow these guidelines to stay safe:

• Never share your password with anyone. Such tools make it very easy to mass-comment or post from any account.
• If any web page asks you to “Pin It” before you can see the content, most likely it is a scam
• If any web page offers you a “free gift card” and redirects you to surveys, most likely it is a scam
• Be careful while clicking links that have catchy titles like “shocking video,” ”you will not believe it,” ”free give away,” etc. Most of the time, they lead to scams and trouble!

As always, spammers like to take advantage of special occasions and festivals. Currently we see a trend in spam mails offering fake Rolex watches as the perfect gift on Mother’s Day. Should you buy one of these fake watches for your mother, or for anyone? Not from these people. Watch out for these emails and don’t click on the links in them.

Here are several common subject lines for Mother’s Day spam:

• Make your mother happy
• Mother’s day stock
• Mother’s Day inventory
• All about MOM
• Weekend Extension
• Trust me, they won’t know
• Ordering Extension
• All weekend
• New deadline date
• Extended deadline date
• Mother’s Day extension
• Do you love your mom? Show her by ordering beautiful flowers for 30% off
• Mother’s Day Flowers For Under $20.00? Yep, This Is For Real
• Hurry – Today is the last day to avoid rush delivery on Mother’s Day flowers

The preceding images are a few examples of Mother’s Day spam we’ve recently seen. The spam mail comes with an attachment and the image is of Rolex watches with some random text and the spammed URL is highlighted in bold as a part of the image.

Some example of spammed URLs:

• hxxp://www.watchesbylr.com
• hxxp://lrwatchco.com
• hxxp://lrwristwatches.com
• hxxp://lrluxurywatch.com

It’s interesting that all of these URLs have the obfuscated word watch/watches in them.

Another spam campaign we’ve seen promotes fake websites that offer flowers and gifts at discounted rates for Mother’s Day. These fake sites work as web redirects to legitimate websites. Have a look at one of these:

As always, we advise you to not open or click links in mail from unknown persons.

And don’t forget to wish your dear mom a very happy Mother’s Day.

Recently 17 suspicious applications, uploaded by the developer thasnimola, were found in the official Google Play market:

Most of them use a shield as an icon to show that they could be related to “protection” software but some of them also use non-AV names and descriptions with popular keywords like “free,” “Video Downloader,” “Call recorder,” and “sms” to attract users’ attention and encourage the installation of the app. One interesting app is Top Free, which claims “Fast and lightweight malicious app protection for your phone.” Looking at this one further, it is clear that Top Free pretends to be AV software because it uses the screenshots of legitimate AV software as its own:

Some of them also use an “Antivirus FREE” banner on the app’s web page:

However, unlike fake-antivirus software threats for PCs and Macs, these applications do not gain revenue from users by detecting nonexistent Android malware. Instead, these apps make money using a more legitimate method: advertisements. All the suspicious apps were created using the same free online service used to create the Android/DIYDoS hack tool. For this reason the behavior is nearly same: When the application is executed, a WebView component shows the contents of a URL that is stored in an XML file inside the res/raw folder:

One difference between these apps and Android/DIYDoS is that these include an advertisement module–provided by the online service–that creates the applications which send sensitive device information (IMEI, GPS coordinates) to a remote server:

Here is the complete list of the unwanted applications that we reported to Google:

All of these have already been removed from Google Play. If you have enabled  detection for potentially unwanted programs (PUPs, our default setting), then McAfee Mobile Security for Android will detect these apps as Android/DIYAds.

This malware binary is not a repackaged application as we have seen in the past. It masquerades as the game MADDEN NFL 12. The malware has three modules embedded into it: The main component is actually a dropper that drops a set of other components onto the compromised user device.

Figure 1: Android Malware Component

Upon installation, the malicious application drops these three malicious components:

• Header01.png: Rooting Exploit
• Footer01.png: IRCBot
• Border01.png: SMS Trojan

Figure 2: Files in asset folder of the main component

What’s It All About?

The files header01.png and footer01.png masquerade as PNG image files, although they are originally ELF files. Header01.png acts as a rooting exploit; we already discussed this in an earlier blog. The purpose of this component is to root the device and then elevate the device’s privilege. Once the device is rooted, footer01.png connects to a remote IRC channel. The final component, boarder01.png, acts as Trojan that sends SMS messages to premium numbers. The other *.png files in the package are just random image files to thwart hash-based detection. This can be seen in the details of the three components.

Main Dropper Component

The main dropper has a size of more than 5MB. The class file AndroidBotActivity is responsible for dropping the other three malicious components onto the device as well as for setting the highest permission to the directory in which it drops these component files. This Android manifest file gives us a vague idea of what this malware binary is capable of: Their package names and labels have been branded as com.android.bot and AndroidBotActivity.

Figure 3: Android manifest file of the main component

Figure 4: Malicious class file AndroidBotActivity dropper code

The malicious class file creates the directory /data/data/com.android.bot/files and drops the three component files, the root exploit, IRCBot, and SMS Trojan in the folder of the compromised device. It then gives chmod 777 permission to that directory. Each number in chmod represents the permissions given to different users such as owner, group, and others; here the malware binary sets the permission to chmod to 777 to give read, write, and execute permission for all users to this folder.

Figure 5 : Setting file permission to chmod 777

Root Exploit Component

The root exploit component is nothing new, as we have already discussed it in my previous blog. However, the malware authors have slightly modified the code. The root exploit component, in simple terms, roots the device to its highest privilege so that the attacker can gain admin privilege and can execute commands from a remote server. Once the device is rooted, it executes the IRCBot component file header01.png.

Figure 6: Code to execute the IRCBot component

IRCBot Component

This is basically a backdoor Trojan that acts as an IRCBot to connect to a remote server and receive and execute commands.

On analyzing this malware binary further, we find that once the system is rooted it sets a marker “1,” which means the system is already rooted. Thus the malware can skip attempting to exploit a device that is already rooted and also from again executing the file footer01.png.

Figure 7 : IRCBot component silently installs the SMS Trojan component

The malware then connects to the remote IRC server 199.68.<removed> and generates a random user name that is used to log into the remote IRC channel.

The malware joins the IRC channel #andros and waits for commands from the attacker.

Once it starts receiving commands from the remote site, it parses them and performs the actions. We found three commands:

• PRIVMSG #andros :[SH] – %s.
• PRIVMSG #andros :[ID] – %d
• PRIVMSG #andros :[EXIT] – exiting ordered.

SMS Trojan Component

The last component of the package is a regular SMS Trojan that sends SMS messages to premium numbers which charge the victim. This one also masquerade as a PNG image file but was originally an .apk file, an application package for Android. We have seen this type of premium SMS abuser many times in the past.

The difference in this malware binary when compared to others is, first, it retrieves the geo location of the SIM and based on the geo location it sends SMS to premium numbers corresponding to that geo location. This is carried out by the following snippet:

Figure 8: Snippet to get the geo location of the SIM

The Trojan sends SMS messages to the premium numbers if the SIM geo is found to be applicable.

Figure 9: Premium SMS numbers

The Trojan also has code to check the message body and sender of all SMS messages received. If the sender is found to be any of the numbers listed above, the malware aborts that message. This step is carried out by the abortBroadcast(); function.

The Trojan then broadcasts an SMS to a remote server along with the mobile number and the message body.

To sum it up, here is the flow diagram for this Android malware:

Figure 10: Flow diagram

Here’s an example of how dangerous this infection can be: If the victim receives a message from the bank that has a two-way authentication code, that message body–along with the mobile number–will be sent to the remote attacker, who can later compromise bank transactions. This alone tells us how serious this attack can be. However, we don’t know what the attackers do with this data, nor what their server-side code does.

In any case, this is a reminder that malware authors consider the Android platform their favorite mobile attack vector, and are coming up with new infection strategies to compromise users and their data. We expect this trend to continue thanks to the growing smart phone market as well as the continued increase of enterprise use, banking functionality, and other consumer usage.

We detect the main component of this malware as Android/Multi.dr, the root exploit component as Linux/Exploit-Lotoor.a, the IRCBot component as Android/IRCBot.a, and the SMS Trojan as Android/SMS.gen.

Several websites have been found with an injected hidden iframe, most of them based on an old version of WordPress and with a bad permission structure.

That piece of code redirects to another host, hxxp://android[censored]fix.info/fix1.php, that detects if the browser agent is Android. In this case, the server gives the device the URL that points to the Android install package, which will be automatically downloaded and saved onto the device’s SD card. The malware is downloaded, but not executed; it requires user assistance to activate. To accomplish that step, the application names the downloaded file Update.apk and the application com.Security.Update to trick the user into believing that the download is a legitimate Android system update:

As we see in the preceding images, NotCompatible will automatically start at boot. For this reason the application does not have an icon. It starts as a service running in the background only after reboot or when the device screen changes its state (between locked and unlocked). This service opens a backdoor to receive commands from a remote server.

The remote IP and port servers are encrypted with AES inside the .apk in /res/raw/data. During analysis, we decrypted this as notcompatibleapp.eu port 48976 and 3na3budet9.ru port 38691. These parameters can be changed via a remote command sent by the control server.

NotCompatible uses the New I/O Proxy API implementation, which is a low-level API that provides access to intensive input/output operations. This API provides attackers an effective method to send and receive commands in custom packages.

Once the service is started, NotCompatible communicates with its control server to send TCP data packages with customized commands. The first message sent by the infected device is the following (always sent via TCP port 8014):

04000001050000000007000000

The control server receives this message, confirming that the infected device is active, and it responds with a Ping message:

040000010100000004

To this the infected device responds with a Pong:

040000010100000005

After this initialization protocol, the control server asks the device to access a specific HTML web page to authenticate itself by validating the string A35T7G:

We have seen similar behavior in a Windows PC malware (detected by McAfee as Generic.dx!bd3j) that sends and receives the same data packages to the same port but with a different control server IP address. This suggests that the infected mobile devices and the PC malware probably belong to the same botnet.

These commands can be remotely executed by the control server:

• Send Error: Sends a custom packet with a specific byte when the command sent by the control server is invalid
• ConnectProxy: Obtains the IP address and port as parameters and tries to open a connection to that remote host, probably to forward the network traffic sent by the control server to another host
• ShutdownChannel: Closes a specific connection with a remote host
• sendPong: Sends a custom packet with a specific byte when a packet with the last byte “4” is received (the ping). It is used by the control server to test network connectivity with the infected device.
• setTimeOut: Sets a specific period during which the connection to a remote host is alive
• newServer: Updates the configuration (AES encrypted in data.bin file inside the device) with a new control server
• newReservServer: The same as newServer but with a backup control server

Based on our previous analysis, we conclude that NotCompatible is an unusual Android malware delivered to users using a drive-by attack that could represent a proof of concept for a targeted attack. The malware was designed to execute stealthy remote commands and act as a server proxy to redirect traffic through the device. This could be used to avoid the tracking of illicit acts by making the network traffic anonymous. Also, based on the network traffic similarities (commands, ports, strings), it is very possible that both the Android and PC malware belong to the same botnet. We will probably see more Android malware of this kind. McAfee Mobile Security detects this threat as Android/NotCompatible.A.

The code posted was fairly simple to understand, appearing fully tested and complete. The code provides insights to the coding skills and techniques used by the botnet author. This bot uses fairly standard installation, copying itself into the Windows\System32\ folder and then sending and receiving commands from a hard-coded control server. The source contains two interesting antianalysis functions, which check for the presence of a sandbox or tools such as OllyDbg or Wireshark. If it detects countermeasures, the bot terminates its process. Below are the two functions used for antianalysis:

BOOL bIsSandbox (void)

• Check GetModuleFileNameA() for presence of string “sample” in the PATH
• Or Check GetUserNameA() for presence of string like “HfreAnzr” or “sandbox” or “currentuser” or “vmware” or “nepenthes”
• Or Check GetComputerNameA() for presence of string like “ComputerName” or “COMPUTERNAME”
• Or Check GetModuleHandle() for presence of DLL like “SbieDll.dll” or “api_log.dll” or “dbghelp.dll” or “dir_watch.dll”
• If anything matches, terminate the bot process

DWORD WINAPI tScanner (LPVOID)

• Use FindWindowA() function to check for name “CommView”
• Or “TCPViewClass”
• Or “TCPView – Sysinternals: www.sysinternals.com”
• Or “PROCMON_WINDOW_CLASS”
• Or “OLLYDBG”
• Or “gdkWindowToplevel”
• Or “CommView – The Team ZWT 2008”
• Or “The Wireshark Network Analyzer”
• Or “SysAnalyzer”
• If anything matches, terminate the bot process

Both of the preceding function help a bot to terminate its process from being analyzed by researchers. The bot sends OS version, Username, botID, and other information to its hard-coded control server in the ns/clients.php?os=%s&name=%s&id=%i&loc=%s format and waits for other commands.

This bot supports the following commands, among others:

install: Download and install another binary

uninstall: Clears registry entries and exit()

open: Open a specified file

update: Update to a new bot binary

qkill: Exit

Examining the code gives us a fair idea of the network communications of this botnet and helps researchers easily write detections. The availability of the source also helps us understand different techniques or methods used by the botnet authors. It’s no surprise that Pastebin has become a communications channel for bad guys–not only for selling botnets but also for sharing code snippets.

ZeroAccess is one of the most talked and blogged,[1][2] about rootkits in recent times. It is also one of the most complex and highly prevalent rootkits we have encountered, and it is continuing to evolve. The ZeroAccess rootkit is distributed via both social engineering as well as by exploitation. A recent blog post by our colleagues at McAfee describes some of the odd methods this rootkit adopts to get installed on machines without getting noticed.

One of the goals of this rootkit is to create a powerful peer-to-peer botnet, which is capable of downloading additional malware on the infected system. This botnet is reportedly [3] involved in click fraud, downloading rogue antivirus applications, and generating spam.

This Google map of the United States shows McAfee VirusScan consumer nodes reporting unique ZeroAccess detections during the past week.

Our consumer data for the past month shows close to 4,000 unique systems detecting ZeroAccess daily. And the trend is continuing upward.

Installation

In my recent analysis of this rootkit, I wanted to understand its initial installation mechanism. The installation of ZeroAccess involves overwriting a legitimate driver on disk with the malicious rootkit driver. Usually Step 1 varies in different variants. Some variants directly overwrite a legitimate driver and others first inject the malicious code in trusted processes like explorer.exe and then, from the injected code, overwrite the driver (this is done to bypass various security products and to make analysis more challenging). During Step 1, the original driver code is kept in memory. The driver that is overwritten in Step 2 is randomly selected (details here[1]). In our discussion below we assume CDROM.sys is being overwritten. Step 2 to Step 8 are fairly static in variants of ZeroAccess. Once the driver is overwritten by malicious code, it is loaded in kernel space. The first task of the kernel mode code is to ensure that it sets up the malware to survive reboots and to forge the view of overwritten driver (CDROM.sys).

Lets move on to see how this scheme works in Step 5 through Step 8. In Step 5,  ZeroAccess intercepts disk i/o by hooking the DeviceExtension->LowerDeviceObject field in the \driver\disk DEVICE_OBJECT. So now any disk i/o would go through the rootkit’s malicious routine. In Step 6, the kernel mode code has access to a clean image of the CDROM.sys driver stored in memory. To survive reboots it flushes the file to disk using the ZwFlushVirtualMemory API. The request to flush the clean image is, interestingly, sent to the file CDROM.sys, which at first glance looks counterintuitive. Why would the rootkit want to write the clean image to the file it just infected in Step 2?  Looking more closely, the rootkit actually uses its disk i/o redirection framework. So, when this request to store the clean image of the file on disk travels through the virtual driver stack shown in Step 7, it is encrypted and redirected (Step to the rootkits “protected” folder that it created in Step 3, instead of going to the actual CDROM.sys.

Once the original encrypted image of CDROM.sys is stored in the protected folder, the infection becomes persistent and can easily survive reboots. Any attempt to read the infected CDROM.sys would have to traverse the hijacked i/o path, in which the rootkit on the fly decrypts the original file from its protected storage and presents the clean image, thus forging the view of the file to security tools. Also, during a reboot the infected file would first load the malicious code in kernel, which can refer to its “protected” folder, and load the original file in kernel, thus ensuring the uninterrupted functionality of the original device.

To clean this threat, security tools have to take several steps in repairing either memory or decrypting the file in its protected folder so that they can restore the original file. Also once the rootkit is active in kernel mode, it takes lot of evasive steps to kill or circumvent the security tools as described by our colleagues in this Virus Bulletin article. So repair becomes even more challenging and research more costly.

Impact of real-time kernel monitoring

I tested for more than a year many variants of this rootkit family against McAfee’s Deep Defender technology, which provides real-time protection against unauthorized kernel-memory modifications. The following screenshot shows Deep Defender blocking the DeviceExtension hijack attempt in Step 5, which was critical to the rootkit’s survival. Once this hook was blocked, the machine was cleaned after a reboot, without any fancy repairs. This move shaved off days of reverse engineering and writing custom repairs against this rootkit and its multiple variants. It seems Deep Defender has found the Achilles heel of this rootkit.

How did Deep Defender clean the machine?

You did not miss part of this article. The interesting point is that Deep Defender did not have to do any custom repairs to clean this threat. It just blocked in real time the core functionality of the rootkit. Let’s revisit the attack strategy to understand what happened.

When the rootkit attempted to hijack the DeviceExtension pointer in Step 5, Deep Defender’s real-time kernel-memory protection saw the attempted change and recognized it as a malicious attempt to modify a critical structure and blocked the hijack attempt. With the hook gone, the rootkit could not hijack the disk i/o path, which means it could not store any files in its “protected” folder and could not survive any reboots without getting noticed. It certainly cannot forge the view of the file anymore. But the most interesting part is that the attempted hijack block by Deep Defender actually redirected the rootkit’s write attempt in Step 7 to its original location. So Step 8 would actually overwrite the original file that it just infected from user mode, thus forcing the rootkit to clean up for us. After a reboot, the system will be back in the clean state.

This strategy from Deep Defender works against all the current  ZeroAccess variants. It would be challenging for the rootkit authors to fully bypass this defense without either leaving the system in a corrupted state or being noticed by security tools, which would catch them red handed if they could no longer forge the view of the file.

The following image shows an example of a crafted RTF file containing a vulnerable OLE file. You can see the signature of the OLE file in D0CF11E0. …

Malicious RTF file

Upon opening a crafted file with the vulnerable application, as in other document exploit files, we see an innocent file posing as bait, while in the background, the Trojan files are installed. Here are typical malware installation steps triggered by the vulnerable application, Word in this example:

1. The crafted document is opened by a Word process.

2. Exploiting the vulnerability triggers the shellcode in the OLE file.

3. The shellcode installs the Trojan(s) on the victim’s machine. Typically, the Trojan is installed in the following path:

%userProfile%\Local Settings\Temp\(filename).exe

4. The shellcode start a new process of Word and opens as bait an innocent document file embedded in the document. Typically the bait file is dropped at:

%userProfile%\Local Settings\Temp\(filename).doc

5. The shellcode terminates the Word process that opened the crafted document.

Because of steps 4 and 5, users will see Word quit and then immediately relaunch with the bait file. If you see this symptom, check with your system administrator.

These crafted documents typically arrive as email attachments. Users should always exercise caution when opening unsolicited emails. We also strongly recommend installing the latest fix, from April’s Patch Tuesday. (Refer to the Microsoft Bulletin for more information: http://technet.microsoft.com/en-us/security/bulletin/ms12-027)

McAfee detects these malicious document files as:

• Exploit-CVE2012-0158: Detection for MS Office files such as MS Word and MS Excel
• Exploit-CVE2012-0158!rtf : RTF files containing vulnerable OLE containers

Further research shows from multiple freelancing project websites shows price quotes of up to $1,500. Here are a couple of project entries found on those websites:

The source code for SpyEye Version 1.3.45 had already been leaked, and a lot of technical information about this botnet is available on the web. Fortunately, we obtained a live sample (with an active control server) created by the latest release (the version ID is hard-coded in the build and sent to the control server along with other information). We proceeded to reverse engineer the latest version to look for any differences.

After unpacking and reversing the latest sample, we found it behaved similarly to the description in the Prevx blog (so we will skip the full details). The only difference we found is the XOR key used to decrypt the config.bin file from the resource section. For this binary, the XOR key used is 0x4C. Here is the snippet of the decryption algorithm to decrypt config.bin:

Note the slight difference between the keys used by the sample we analyzed and the sample analyzed by the Prevx blog. (Was this intentional by the SpyEye author?) The decrypted config.bin file is nothing but a password-protected ZIP file whose password is stored in the C3 resource section in plain text. Here is the screenshot of the unzipped contents:

The unpacking/decryption routine of the ZIP files and the infection method of this bot are the same as in the prior version. We next searched network activity to look for variations. The binary, as expected, sends an HTTP POST request with encrypted data shown below:

As mentioned in a screenshot from the XyliBox blog, this version of SpyEye can be identified by the network capture. The packet can be decoded using a Base64-decoded string and the simple XOR key 0xDB. The sample PHP encoder/decoder created by XyliBox can be found here. Here is the converted sample Perl code to decode the traffic:

sub decode_spyeye

{

$encry_data = shift;

$decodeBase64 = decode_base64($encry_data);

$decodeBase64 =~ s/\+//g;

@charArray = split(“”, $decodeBase64);

$len = @charArray;

$decrypted = ”;

for($i = 0; $i < $len; $i++)

{

$num = ord($charArray[$i]);

if( $num != 219) #Key 0xDB = 219

{

$decrypted .= chr($num ^ 219);

}

}

return $decrypted;

}

$str = decode_spyeye($data);

The decoded string using the preceding routine is:

“guid=5.1.2600!XP-HOST01!D04EF662&ver=10348&ie=6.0.2900.2180&os=5.1.2600&ut=Admin

&ccrc=63B05A00&md5=25d37d161d0bc546429dc98185eca8c4&plg=ccgrabber;customconnecto

r;ffcertgrabber;ftpbc;Plugin_USBSpread;rdp;socks5&plgstat=0;0;0;0;0;0;0&wake=60&

stat=online”

The version information can be found in the preceding decoded string. The bot collects information about the infected machine and sends it to the control server. We have seen such traffic in plain HTTP GET requests in older versions of this botnet. The response is also decoded using the same routine, which was nothing but control commands to execute. Thus we find no major changes in encoding/decoding routines in the latest version.

SpyEye has definitely been buzzing on the Internet for the last few years and remains the top (in stealing money) banking botnet. Bad guys or script kiddies are willing to pay a lot of money for this popular botnet. With people selling this botnet for such low prices and with the availability of leaked code, we may see a rise in this botnet’s activities and control servers.