Virus infects a banking Trojan, leaving both operative

SpiderLabs discovers banking malware that became infected by a well-known virus

When malware infects a machine it usually goes after the system software. But in a rare case worked on by SpiderLabs, researchers found a Trojan that had been infected by a virus, leaving both still functioning as normal.

The two pieces of attack code were found on a single point-of-sale machine owned by a client of SpiderLabs, which removed them and put the machine back into use.

IN PICTURES: The 10 worst tech screwups of 2012 (so far) 

An investigation is ongoing into how the malware got there in the first place, says John Miller, a malware research manager at SpiderLabs, which is run by security vendor TrustWave.

The virus in question is a variant of the Sality family known as Win32/Sality or alternatively W32.HLLP.Sality - a well-known virus that most anti-virus platforms can detect and remove.

Win32/Sality is a polymorphic virus that infects Win32 PE portable executable files and has been around since 2003, according to a technical description of it that was posted by Symantec in August.

It replicates and infects other machines and can be used to create peer-to-peer botnets and can receive URLs from which it can download additional malicious files, Symantec says.

The second piece of malware was a banking Trojan placed on the machine to steal credit card information. Because of its placement within the point-of-sale machine system and because it was an executable, it was targeted by Sality. According to the Symantec description, Sality inserts viral code at the last section of the host file, and that viral code executes when the host is called upon to execute.

The banking Trojan was discovered because of its behavior - looking for credit card information - not through malware signature scanning, Miller says. But when it was scanned, it came up classified as a variant of Sality. But stealing credit card data was something Sality had never been seen to do, according to a SpiderLabs blog post detailing the case.

"That being said, there was one thing that this malware shared with the first one, both samples dropped the same library file (DLL) in the system32 directory, and proceeded to load it with a specific export name during runtime," the post says. In other words, the banking Trojan was acting just like Sality. It turns out that's because it had been infected by Sality, and Sality was behaving as it normally does in a host file.

The researchers used Kaspersky anti-virus to cleanse the banking virus of Sality, and wound up with a pristine version of the banking malware. Since Sality wasn't the primary concern and it was easily removed, SpiderLabs didn't investigate what Sality was up to.

It turns out the cleaned malware couldn't be detected by the anti-virus engines the researchers used, Miller says.

The banking Trojan itself doesn't replicate, so when it was removed, the host machine was clean. The ongoing work is making sure that the means by which it got there in the first place - some form of targeted attack - is shut down, Miller says.

Possibilities include that the Trojan was placed there by someone with unrestricted administrative access via a remote desktop platform or by an insider with physical access to the management system. "That's generally how they get on there," he says.

Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies