Induc-trination: Malware under continuing development

For a grizzled, old-virus geek, you might assume that the main interest of the Win32/Induc family (apart from the fact that it's a real virus in an age where most malware is technically non-viral) is that it closely resembles a more-or-less proof of concept attack described by Ken Thompson in 1984, in a paper called Reflections On Trusting Trust (and, less obviously, a 1987 paper by Ian Whitten on Infiltrating Open Systems, that developed the theme). That's because the virus infects the Delphi compiler in such a way that programs subsequently compiled are also infected, which somewhat resembles in principle (if not in the exact mechanism) the way that Thompson demonstrated that he could gimmick a C compiler in order to generate a bugged binary.

Win32/Induc.A didn't really do much except generate infected binaries, however exotic the infection mechanism, though it's naive to assume that malcode with no real payload is harmless:

• As a Pascal programmer from way back, I quite like Delphi myself, so I won't say that Delphi is “surprisingly” popular, but it always surprises me slightly that quite a few malware authors continue to use it. Given that fact, however, it doesn't surprise me that there has been a steady stream of malicious programs compiled in Delphi and infected with Induc: the only defensive programming that malware authors consistently incline to is focused on avoiding direct detection by security programs, and multiple infections of single malicious binaries (we used to call them “cocktails”) have a long history in this game. 
• There is another issue that makes a nonsense of claims that Induc “doesn't matter because it's harmless” (yes, I did have discussions with the media a couple of years ago on this very point). Suppose an innocent, but infected program is installed and makes changes to the system. What are the implications if it is then discovered to be infected and has to be removed, but the changes aren't reversed?

Win32/Induc.B indicated some development activity: Though there was no additional payload, there were some “improvements,” including some anti-debugging tricks and XOR encryption.

Win32/Induc.C, which appeared last month, ups the ante. It has a more effective search-and-infect capability and basic botnet functionality. It has somewhat innovative downloader functionality (it conceals download URLs in the EXIF field of forum user avatars), and is already associated with a known password stealer.

And to take us back to where this article started, while the Delphi infection gimmick is still there, Induc.C is no longer restricted to compile-time infection, so it can infect any .EXE, increasing its potential spread dramatically. Well, you might say that just brings it up to the same potential spread as other .EXE infectors, which doesn't sound all that dramatic. But, that's actually the point: While Induc variant infections don't have the sheer volume of the top scorers in ESET's ThreatSense.Net® telemetry, they've been picked up in significant numbers over two years.

This is long past being an academic proof of concept exercise. It's malware under continuing development and has, I believe, a serious “commercial” agenda.