English
The Internet threat alert status is currently normal. At present, no major epidemics or other serious incidents have been recorded by Kaspersky Lab’s monitoring service. Internet threat level: 1
Latest posting
By rating
By popularity

Join our blog

You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.

Incidents|Abused update of GOM Player poses a threat

Suguru
Kaspersky Lab Expert
Posted February 04, 14:58  GMT
Tags: x64
0.3
 

Several media reported the news on January 7th, 2014, that a PC associated with “Monju” (the Fast Breeder Reactor of the Japan Atomic Energy Agency) was infected by malware and there was a suspicion of information leaks. Some pointed out that the infection had possibly been led by the abuse of the legitimate update of "GOM Player", which made it big news. GOM Player is a free media player with popular video/audio codecs built-in, favored by many Japanese people. It is different from similar free media players in some notable points: it supports major file formats such as AVI, DAT, DivX, MPEG, WMV to name just some; and it officially deploys a Japanese version. Its users are said to be more than 6 million in Japan.

We received the sample file named “GoMPLAYER_JPSETUP.EXE”:

0.4
 

The more people switch to 64-bit platforms, the more 64-bit malware appears. We have been following this process for several years now. The more people work on 64-bit platforms, the more 64-bit applications that are developed as well. Sometimes these include some very specific applications, for example, banking applications.... If someone wants to hack into an application like this and steal information, the best tool for that would also be a 64-bit agent. And what’s the most notorious banking malware? ZeuS, of course – the trendsetter for the majority of today’s banking malware. Its web injects have become a fundamental must-have feature of almost every banking malware family. And it was only a matter of time until a 64-bit version of ZeuS appeared – but we didn’t expect it to happen quite so soon.

That’s because cybercriminals don’t actually need a 64-bit version. ZeuS is mostly intended to intercept data passing through browsers, and modify that data allowing the operator to steal information related to online banking, to wire transactions or to cover his tracks. But nowadays people still use 32-bit browsers – even on 64-bit operating systems. So, 32-bit versions of ZeuS have been sufficient to keep the thieves satisfied with their earnings.

Then, out of the blue, we spotted a 32-bit ZeuS sample maintaining a 64-bit version inside. And it’s turned out that this 64-bit version has already been recorded being present in the wild at least since June, 2013 and compilation date specified in the sample is April 29, 2013! Moreover, this ZeuS version works via Tor. The initial 32-bit sample injects malicious code into target processes. If the target process belongs to a 64-bit application, ZeuS injects its 64-bit version into the process; otherwise, it pushes the 32-bit version. We ran tests to see how the 64-bit ZeuS works inside a 64-bit Internet Explorer and it demonstrated the usual ZeuS functionality: in any case, the web injects functioned as usual.

Incidents|New 64-bit Linux Rootkit Doing iFrame Injections

Marta Janus
Kaspersky Lab Expert
Posted November 19, 20:15  GMT
Tags: Linux, Rootkits, x64
0.7
 

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.

Research|Federal Trojan's got a "Big Brother"

Tillmann Werner
Kaspersky Lab Expert
Posted October 18, 15:15  GMT
Tags: Rootkits, Targeted Attacks, x64, Keyloggers
0.8
 

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.

Events|TDSS loader now got “legs”

Sergey Golovanov
Kaspersky Lab Expert
Posted June 03, 14:40  GMT
Tags: Rootkits, x64, DNS, TDSS
0.6
 

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.

Incidents|Rootkit Banker - now also to 64-bit

Fabio Assolini
Kaspersky Lab Expert
Posted May 20, 12:58  GMT
Tags: Internet Banking, x64
0.8
 

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:

0.3
 

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.

Comment      Link
0.3
 

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.

Research|Different x86 Bytecode Interpretations

Georg 'oxff' Wicherski
Kaspersky Lab Expert
Posted July 22, 16:17  GMT
Tags: Proof-of-Concept, Linux, x64
0.2
 

Working on an efficient generic shellcode detection engine and verifying results with randomly generated input, I've effectively ended up fuzzing different open source disassembler libraries. The disassembler library of choice for my current project is libdasm because of its comparatively long history and public domain license. But writing a sound and complete x86 disassembler is obviously not a trivial task due to the complex nature of the x86 instruction set.

libdasm used to have issues correctly disassembling certain floating point instructions in the past, but this was simply caused by an off-by-three error in the opcode lookup tables (three NULL rows missing) and thus the fix was comparatively easy.

Opinions|Rootkits and Windows for x86-64

Yury
Kaspersky Lab Expert
Posted April 22, 15:32  GMT
Tags: Rootkits, x64
0
 

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

Comment      Link