A few days ago, an interesting piece of Linux malware came up on the Full Disclosure mailing-list. It's an outstanding sample, not only because it targets 64-bit Linux platforms and uses advanced techniques to hide itself, but primarily because of the unusual functionality of infecting the websites hosted on attacked HTTP server - and therefore working as a part of drive-by download scenario.

About two weeks ago, the German Chaos Computer Club (CCC) has published an analysis report of a backdoor trojan that they claim had been used by German police during investigations in order to capture VoIP and IM communication on a suspect's PC. Our friends over at F-Secure published a blog post last week where they wrote about another file that, according to them, seemed to be the dropper component of the trojan. They were kind enough to share the MD5 hash of the file, so we could pull it from our collection. Stefan and I took a closer look.

The dropper carries five other binaries in its resource table, so there are six components in total – each with a different purpose – all of which have been analyzed by us. Amongst the new things we found in there are two rather interesting ones: firstly, this version is not only capable of running on 32 bit systems; it also includes support for 64 bit versions of Windows. Secondly, the list of target processes to monitor is longer than the one mentioned in the CCC report. The number of applications infected by the various components is 15 in total.

The TDSS loader, a malicious program that we wrote a lot about (e.g. here and here) now has legs, i.e. a tool for self-propagation. TDSS is a very complicated piece of malware and the cybercriminals have created an ingenious propagation tool for its loader.

Yesterday Kaspersky Lab detected the first rootkit banker created to infect 64-bit systems. It was detected in a drive-by-download attack made by Brazilian cybercriminals.

We found a malicious Java applet inserted in a popular Brazilian website. The attack was made using a malicious applet in such a way as to infect users running old versions of the JRE (Java Runtime Environment) and was prepared to infect users running versions of both 32 and 64 bits systems.

Inside this applet we found some interesting files:

The entire malicious scheme is simple yet interesting. The file add.reg will disable the UAC (User Account Control) and modify the Windows Registry by adding fake CAs (Certification Authorities) in the infected machine:

The Virus Lab recently came across a very interesting sample – a downloader containing two drivers and which downloads fake antivirus programs developed for both PC and Mac platforms. The malicious program is downloaded and installed using the BlackHole Exploit Kit. The latter contains exploits targeting vulnerabilities in JRE (CVE-2010-0886, CVE-2010-4452, CVE-2010-3552) and PDF.

Both drivers are standard rootkits with rich functionality. One of them is a 32-bit and the other a 64-bit driver. The 64-bit driver is signed with a so-called testing digital signature. If Windows – Vista and higher – was booted in ‘TESTSIGNING’ mode, the applications can launch the drivers signed with a testing signature. This is a special trap-door which Microsoft has left for driver developers so they can test their creations. Cybercriminals have also made use of this loophole: they execute the command ‘bcdedit.exe –set TESTSIGNING ON’ which allows them to launch their driver without a legitimate signature.

The following description refers to both rootkits because, apart from the platforms, their functionality is identical. Once the driver is successfully loaded and running on the system, it’s difficult to get rid of it. The rootkit blocks the launch of drivers belonging to anti-rootkit and antivirus products. This is done by using lists of file names for specific drivers and strings for which the rootkit searches the Security section of the DataDirectory array of the image being loaded. If the rootkit detects an “untrusted” driver being loaded, the bytes at the entry point of the image are changed, preventing it from loading correctly.

Fragment of the rootkit containing search strings used to block antivirus drivers

The rootkit protects the “main” application by hooking ZwOpenProcess / ZwOpenThread in SDT (only on 32-bit versions of Windows) and using object manager callbacks to access “trusted” applications. The file system is also monitored by connecting to file system stacks and the registry – by using registry callbacks.

This rootkit is yet more proof (after TDSS) that it’s unnecessary to bypass Patch Guard-а in order to implement rootkit functionality on 64-bit platforms.

The downloader is written in C++ and is itself not protected. Its main task is to install and launch the relevant driver (32- or 64-bit), then download and launch a list of files from URLs. Interestingly, one link leads to Hoax.OSX.Defma.f which we recently wrote about. Most importantly, the rootkit tries to run it…under Windows! It appears that the developers of the latest rogue AV program for MacOS are actively distributing it via intermediaries, who don’t really understand what it is they are supposed to install on users’ computers.

Fragment of the malicious code that downloads and launches the file

Kaspersky Lab products successfully detect and neutralize both Trojan-Downloader.Win32.Necurs.a and Rootkit.Win32.Necurs.a / Rootkit.Win64.Necurs.a.

The cyber-criminal groups behind fake anti-virus (scareware/rogueware) infections have run into some significant roadblocks over the last few years, but there is much more to the overall story.

Some groups have been arrested. Some have had their operations and entire call support centers shut down.
Some groups attracted too much attention, picked off the low hanging fruit and eventually walked away from their botnets.
In some cases, the groups just weren't very skilled at developing anti-anti-malware techniques, blackhat SEO, and malware distribution. They couldn't keep up with the changes in anti-malware technologies, weren't exactly dedicated to the effort, and simply fell off the map.

However, some of the remaining scareware distribution gangs upped the ante and are aggressively developing difficult-to-detect polymorphic installers and difficult-to-remove support components. And the newest of these malware components include some of the first ITW 64-bit malware components to be taken seriously. But, for the most part, the scareware program itself remains the same. The development continues to change and progress, all for the purpose of evading anti-malware solutions and helping coerce the end-user to pay for the fake product, including support/rootkit components like TDSS (and its extreme complexities) or the more recent Black Internet (also known as "Trojan-Clicker.Win32.Cycler") support/rootkit components. These complex Mbr infectors and other rootkit components meant to maintain money-making scareware on the system are signs of this somewhat extreme development effort.

There's recently been a great deal of talk about Windows for x86-64. One interesting feature of this operating system is that modifying the system structure is forbidden - this includes modifying:

• kernel system tables, such as KeServiceDescriptorTable
• the Interrupt Description Table (IDT)
• the General Description Table (GDT)

The stack cannot be used in kernel mode unless expressly permitted by the kernel. The operating system will also check certain parts of kernel code for integrity, and modifying these parts of code will cause a Blue Screen of Death.
This last check is performed only on native AMD64 systems (but not on Intels' EM64T clones).

The security measures applied in the new operating system which aim to protect the address space will make developing new rootkits very complicated, since many of them aim to modify the handler execution path (for instance, intercepting KeServiceDescriptorTable) and the system structures.

So the good news is that the majority of today's rootkits will be unable to function in kernel mode under this new operating system