A short history of Induc

There’s been a lot of fuss in the media lately, with news from all the major antivirus companies being printed and reprinted. And all the news is on the same topic – something we haven’t seen since Kido (Conficker) and the latest Adobe vulnerabilities. The source of all the fuss? Virus.Win32.Induc.a.

Induc was such an unusual case that initially we just published a short blog giving technical details about the virus. Now there’s time to step back, take a breath, and assess Induc’s real impact.

The name relates directly to the virus functionality. Once it’s on the victim machine, it checks to see if Delphi is installed – it targets versions 4.0, 5.0, 6.0 and 7.0. If it detects one of these versions of Delphi, it copies the .pas file it’s going to use (in this case, sysconst.pas) to Source to Lib and adds its code to the file. It makes a backup of sysconst.dcu, calling it sysconst.bak, and compiles the infected .pas file, which results in a new sysconst.dcu containing malicious code. The infected .pas file then gets deleted.So we’ve got a virus which adds its code to a file with a .dcu extension – you could say the code is “in dcu”. Swap a couple of letters around (which is what we usually do when naming viruses) and you get Induc. (Of course, sometimes viruses get given different names by different antivirus companies. Everyone calling this virus Induc is a sign that we really were the first to add detection and disinfection for this piece of malware – it’s usually the first name given that tends to stick.)

Once the virus has successfully injected its code into sysconst.dcu, any Delphi program compiled on the machine will be infected. There’s no other payload apart from the fact that Induc can spread itself. The interesting thing is the way in which it spreads – it’s doesn’t infect exe files, but programming language compilation files.

This isn’t a new approach. Some of you might remember a similar virus from the 1990s, a virus which targeted MS-DOS and infected Pascal files. There are other examples from the more recent past: Lykov, for instance, which appends its code to Visual Basic program source files, first appeared in 2003. Its successor, Lykov.b, which infects VB.NET program source files, showed up a couple of years later.

But as far as we know, no-one’s tried to directly infect the service files of a compiler before. This approach is so unusual that it doesn’t fit anywhere in our current classification system. Induc isn’t a virus in the strict sense of the word, because it’s doesn’t directly infect files. It modifies a single system file rather than every file which it finds. Induc can’t be called a worm, and it can’t be called a Trojan either, even though it does possess certain hallmarks of such types of malware. So Induc really is something new.

The second interesting point is how widely the virus has spread. The day after we added detection, data from Kaspersky Security Network showed Induc was one of the 70 most common malicious programs. It wouldn’t be any surprise if Induc appeared in our Monthly Malware Statistics in August. It’s possible that there are millions of copies of Induc around the world – maybe an epidemic no smaller than the one caused by Kido!

The third interesting point is the applications infected by Induc – the virus ended up on developers’ computers among others, and some of these developers were creating very popular applications. For instance, we’ve seen several infected versions of AIMP media player as well as QIP, the popular instant messaging client. Induc’s been detected in applications around the world, on software sites, and on magazine giveaway software CDs.

The fact that Induc’s been found in legitimate applications, many of which have been allowlisted by vendors, has created another problem. This time it’s a headache for the industry which offers allowlisting, in the main, via in-the-cloud technologies. Once infected files were detected in the databases of clean files, these databases had to be cleaned. This highlights the weakness of such databases, and if similar incidents happen in the future, trust in allowlisting will certainly start to suffer.

Disinfecting infected files isn’t a trivial matter. Although it’s possible, it can have negative results: a lot of programs (for instance, QIP) perform an integrity check on startup using a checksum. However, as QIP was infected at compilation stage, the checksum created includes the malicious component, so once disinfected, QIP won’t work correctly. However, programs which don’t perform this integrity check still run correctly after disinfection.

When we started to receive infected files, we noticed almost straight away that some Trojan programs designed to steal bank account data were infected with Induc. The authors of these Trojans had themselves fallen victim to a virus – they must have compiled their Trojan files using an infected version of Delphi. All the infected Trojans we saw came from Brazil, even though they’d been created by different groups of virus writers. None of this means that Induc itself was written in Brazil – it’s just that this country is one of the few where Delphi is the most widely used programming language (it’s pretty popular in Russia too).

But let’s leave these infected Trojans and move on to the very important question of how long the virus remained undetected in the wild – and why.
Just to be clear – the virus was initially identified on 12 August 2009 by a Russian programmer called Aleksandr Alekseev, who’s also known as Gun Smoker. He was the only person who came across this virus who wasn’t only able to get to grips with what was going on, but he also spread the news throughout the computing community and sent suspicious files to antivirus companies. Thanks, Gun Smoker!

Gun Smoker’s published a detailed article on his findings (over here, but in Russian only). According to him, infected files first appeared by January 2009. Our data shows infected files dating from November – December 2008, but unfortunately, when compiling files, Delphi doesn’t save the link date so we can’t tell exactly when these files were created. But we can say with some certainty that Induc has been in the wild for a year.

This means we’ve got an unprecedented situation – a malicious program which stayed ‘invisible’, undetected by antivirus companies for more than a year. This is even more impressive than Rustock, the rootkit which we covered last year. Before anyone starts pointing a finger, I’d like to defend the antivirus industry: Induc was around for so long because it doesn’t do anything which could be detected by current antivirus technologies.

Induc doesn’t steal data, establish any network connections, and doesn’t send spam – it doesn’t do anything detectable. If it had any real functionality, Induc would have been identified long ago.

And this leads us on to another question – “what will happen if this propagation routine becomes common?” Induc is clearly proof of concept code – maybe it was written to win a bet, or maybe it was created by accident. Of course, the idea used in Induc could be taken up by cybercriminals, but they’re not really interested in simple propagation; they want to be able to do something on the infected system. Everything that they can do gets detected by the technologies currently in use. Or, to take a slightly different view, nothing would go undetected for such a long period of time.

We’re pretty sceptical that Induc’s propagation routine will get taken up by cybercriminals – there are plenty of simpler ways to conduct attacks. Nevertheless, Induc’s taught us all some valuable lessons. It’s shown the antivirus companies that allowlisting isn’t perfect, and nor is early threat detection all it might be. It’s shown software developers that they need to understand how their programming languages really work. And finally, Induc’s shown everyone who uses a computer that even trusted applications may not be as clean as they look.