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:
- Like Win32/Induc.A, Win32/Induc.B affected Delphi versions 4.0 to 7.0. Induc.B is, however, a bit smarter in finding the directory into which the programming environment was installed and reflects some of the company-name changes that took place. It is now able to succeed even when the IDE is no longer simply called Delphi, and is also able to infect Borland Developer Studio (BDS) and Codegear BDS.
- Some anti-debugging techniques were introduced.
- Some simple XOR-encryption was used to obfuscate the code, making the analysis of the code a bit more difficult.
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:
- The algorithm for searching the Delphi installation folder has changed. Instead of getting the path from the Windows Registry, it performs a search of the hard drives.
- The target library for infection is no longer SysConst.pas, but SysInit.pas, and the infection mechanisms are more effective.
- Induc.C is able to infect even executables that weren’t compiled in the malignly-modified Delphi development environment. This infection vector is used against executables on removable drives (such as USB sticks), which might help the virus to spread much further than previous versions.
- The virus body contains three encoded URLs to which it tries to connect. The downloader is implemented in quite an unusual manner. The links point to JPG files (user avatars on discussion forums), inside which is an encrypted URL. The URL is hidden inside the EXIF section of the JPG image and points to additional malware. Induc.C downloads the malicious executable and runs it.
- One specific malware that we’ve seen Induc.C download is a password stealer that ESET detects as Win32/PSW.Delf.NQS. This can be used to gain access to private FTP servers, as it is capable of extracting passwords from various FTP applications.
- Induc.C also sends a unique ID of the infected PC to the remote computer. This enables the attacker to track the infections and create a botnet.
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
Leave a reply