ESET has discovered a new version of the Delphi infector, Win32/Induc. Unlike its predecessors, however, this variant incorporates a seriously malicious payload and has acquired some extra file infection and self-replicative functionality.
Two years ago, we published comprehensive information (here , here, and here) about the virus Win32/Induc.A, which infected Delphi files at compile-time. Though not very advanced technically, the virus was nevertheless interesting, because instead of infecting executable files directly, it targeted a standard library in the very popular Delphi programming environment. As a result, every application compiled in this infected Delphi IDE was infected. Perhaps, the author was inspired by a 1984 paper by Ken Thompson that describes a somewhat similar infection method by modifying a C compiler.
And even though this malware really only affected installations with Delphi installed, it started spreading very successfully around the world by way of a number of applications written in Delphi (including, ironically, some examples of malware).
But apart from the eye-catching infection mechanism, the Induc.A virus had no other malicious payload. However, that changed 2 years later, with the appearance of new variants.
In July 2011, ESET first detected Induc.B. This version was still quite similar to the first one in that it lacked a genuinely malicious payload, but the code had been rewritten, and there were some noticeable improvements:
Otherwise, the infection mechanism remained the same – by recompiling the standard Delphi library SysConst.pas after writing the virus code to it.
The latest variant of the virus, Win32/Induc.C, featured much more dramatic changes. ESET discovered this version in August 2011. The code is completely different from its predecessors and the only functional similarity is that it infects Delphi. However the infection mechanism has changed and where before only Delphi applications were infected (i.e. at compilation), a new infection vector for infecting any .exe file has been added. The most significant change is the addition of downloader functionality. Induc.C creates a backdoor through which other malware can be downloaded and run, thus greatly expanding the capabilities of the malware.
Figure 1 – Malicious code inserted into SysInit.pas
To summarize some of the new features and changes in Win32/Induc.C:
Figure 2 – One of the downloaded avatars
By comparing the different versions of the virus, it becomes apparent that the first versions of Induc were some kind of Beta phase of development, where the author experimented with the (somewhat) innovative method of infection. On the other hand, the latest variant, Induc.C, is regular malware with clearly illicit ambitions.
Figure 3 – Debugging the Delphi infection code in OllyDbg
As we’ve mentioned above, the Induc malware family has been spreading actively, as confirmed by statistics from ESET Live Grid technology (an upgraded version of ESET's cloud-based ThreatSense.Net system):
Figure 4 – Detection statistics for all Induc variants
We can see that the virus has been spreading globally, with the most detections coming from Russia, followed by China, but with a significant number also recorded in the United States. With the latest variant, Win32/Induc.C, the numbers are different and very interesting:
Figure 5 – Detection statistics for Induc.C
The highest number of detections has been recorded in Slovakia and Russia, adding up to over 80% of worldwide detections of Induc.C. Note, however, that the two pie charts aren’t directly comparable, as detections of Induc.C constitute less than 1% of all Induc detections (which already run into the thousands daily). That’s not to say that Induc.C is not spreading rapidly, but it’s the new kid on the block: once it gains traction, the distribution statistics could look very different.
ESET will continue monitoring the evolution of this virus and provide protection as it develops. This latest variant represents a significantly more serious threat than its earlier incarnations.
 Given that the programmer didn’t manually exclude the library from the project.
 Ken Thompson: Reflections on Trusting Trust (1984), Communications of the ACM Vol. 27, No. 8